Pokemon GOのレイドで、ダークライを無事にゲット。倒すことはできても、その後に取り逃がすことがあるので、ダークライをゲットすることができてよかった。
そして、レイドのダークライだが、なかなか手強い。人数が10人くらい集まってしまえば、余裕だが、７人とか８人だと時間切れになることがあるので、かなり厳しい。まぁ、人が集まるかどうかはタイミング次第なわけだが。
年: 2019年
-
ベレーザの試合を見にいってきた
今日は、日テレ ベレーザの試合を見にいってきた。ハラハラドキドキしながら、試合を見ていたけれど、その分、とても面白い試合だった。Tシャツもいいデザインだった。
前半3分に１点入れられたときには、ヤバイという感じ。前半のうちは、パスカットをされることが多く、うまく攻められていない感じで、嫌なムードが若干あった。それでも、前半が終わるくらいには攻めまくっていたので、見ていると楽しかった。後半になって、選手交代があった後は、動き方も変わっていいムード。そして同点に追いついて、ちょっと安堵。そのまま、引き分けで終わるかと思ったのだけど、後半終了ぎわからアディショナルタイムの激しい攻撃で決勝点。見ていて楽しい展開でした。勝ってよかった。相手チームもうまいし、いい試合だったと思う。
ちょっと残念だな、と思ったのは、相手チームのサポーターが自チームの選手にヤジを飛ばしているところ。そんなに言わなくてもいいんじゃないかと思う。結果が全てではあるけれど、もっと穏やかに見ればいいんじゃないかと思う。１試合戦ったあとの罵声はきついと思う。
-
vCenter Serverアプライアンスの管理サイトのポート番号
vCenter Serverアプライアンスの管理サイトのポート番号のメモ。ポート番号は、「5480」。vCenter Serverのバージョンは、6.7で確認。
https://ホスト名:5480/
これで、vCenter Server アプライアンスの設定ページを開くことができる。IPアドレスを変更したり、DNSサーバの設定を変更したり、vCenterのサービスの状況を確認したりなどが行える。忘れるので、メモ。
-
ローカルユーザーとグループをコマンドで開く
Windows Serverでローカルのユーザを調べたり、グループの確認を行うときに使う「ローカルユーザーとグループ」を探すのがめんどくさいので、コマンドで開く方法。
「ファイル名を指定して実行」（Windowsキー+R）で、下記を入力する。
lusrmgr.msc
一発で開くので楽。
-
Veeamのライセンスの数え方
https://www.veeam.com/jp/universal-licensing.html
Veeamのライセンスは、ある意味シンプルなんだが、数え方が特有。最低購入が10インスタンスとか、10ライセンスなどの表記がある。
1ライセンス = バックアップ対象サーバの１台
気を付けなければならないのは、仮想サーバの場合は、ホスト（親機）ではなく、ゲスト（子）1台につき、1ライセンスが必要。
そのため、物理サーバ1台で15台の仮想サーバが稼働中の場合は、15ライセンスが必要。ただし、10台しかバックアップをしない場合は、10ライセンスでよい。
-
アイアントをゲット
Pokemon GOで、5kmのたまごから、アイアントが出てきた。
-
月見そば
小諸そばの月見そば 今日は、風邪っぽくて食欲があまりなかった。小諸そばで、暖かい月見そばを食べてきた。出汁と柔らかいそばが、食欲がない中でも、美味しくいただけた。毎日でも食べられる味なのが、立ち食いそば系のいいところだ。
-
台風19号が過ぎて。
台風19号は、運良く被害を受けることなく、過ぎていった。
運良くというのは本当にその通りで、台風のコースが西寄りになったので、市川市は思ったよりも雨が降らなかった。それでも、派系大柏川と春木川は洪水のぎりぎりまでいっていた。治水対策で、遊水池がいくつかあったのと、雨量がかさまなかったので氾濫せずに済んだのだろう。今回の雨は、多摩川なども氾濫しているくらいなので、コースによっては本当にひどいことになっていたはずだ。今日、周囲を散策したところ、付近の家は壊れたところもあった。1ヶ月前の台風といい今回の台風といい、今年も災害続きだ。
台風対策の買いだめで、コンビニもスーパーも軒並みインスタントラーメン系は売り切れ、パンなどもほぼ残らず。そのほかに養生テープも無くなっていた。備えは必要だけど、震災直後のパンデミックみたいな様相になっていたのが今回の台風の印象的な部分だ。使わなくよかったのは、不幸中の幸いだった。
台風で思うことは、改めて行政の行う治水対策は重要であるということ。数十年前の水害の対策工事を、災害が起きていないからといって中止してしまうと、同規模の自然災害がおきたときに水害につながってしまうということ。賛否あるダムも役にたったわけで、それなりに機能しているのだと気が付かされた。
余談だが、約2日も引きこもりだった。なので、改めてゼルダの伝説Bless of the Wildを始めた。2回目だが、最初の大地を抜けるのがきつい。最初からやり直してみると、やはり面白い。
-
江戸川でハゼ釣り
ブログに書こうとして早2週間、江戸川にハゼ釣りに行ってきた。昨年とその前も、なぜか天気との相性が悪く、ハゼ釣りにいけず、数年ぶりにハゼ釣りに行ってきた。
ボートを使ったので、釣果はまずまず。というよりも、入れ食いまでは行かないが、なかなかよいペースで釣れたので、食べきれる数だけ釣った。だいたい70匹強だろうか。それ以外にも、針を飲み込んでいない小さなハゼは、結構リリースしたので、釣った数はもっと多い。それから、ハゼに混じってセイゴを1匹釣った。セイゴを釣ったは、20年ぶりくらいだろうか。楽しくハゼを釣ることができてよかった。
-
読了：IT負債
まとめると、IT負債とは、ITシステムの技術的な負債のこと。古い技術を使っていること、DB中心でシステムが密結合しているために、保守や改修にとても工数がかかる。これが日本ではITシステムのコストの8割、アメリカだと6割を占める。DXに対応していくために、密結合の巨大システムから、もっと小さい単位のマイクロサービス化して、１つの改修がシステム全体に影響を及ぼさないようにすることで、開発速度をあげていく。マイクロサービス化することで、システム間を疎結合にしていく。また、マイクロサービスの利用にあたり、API化していく。マイクロサービス化、API化は、アメリカでは潮流であり、不可逆な流れになっている。そのとき、クラウド化（シフト）するのではなく、クラウドに最適化（リフト）していくことが求められている。
マイクロサービス化は、わからなくもない。ただ、どこまでマイクロサービス化するのかは議論の余地がありそうだ。いまどきの技術者の場合のマイクロサービス化だと、本当に細かい単位で、かつサーバレスでの動作というイメージがある。でも、レガシーシステムを抱える企業の場合は、そこまで小さくしたいわけでなく、ある機能の単位でわけていくくらいがちょうどいいと思う（単機能のシステム）。そして、それを疎結合させるだけでも、足枷がゆるくなるはず。あと、マイクロサービス化するとき、開発をするときの言語選びやフレームワーク選びも重要。流行りに合わせていると、結局、保守しないといけない開発言語や環境の数がふえていく。だからといって、固定にしてしまい、選ぶものを間違えると、人は集まらない。どっちかっていうと、常に新しくしつづけていく必要があり、そこにコスト（人など）をかけるということが大事だと思う。それが一番重要。
以下は、気になったところを抜粋。
P.5 本書のタイトルである「IT負債」とは、「ITシステムの技術的負債」のことを指している
IT負債P.5 技術的負債が重いほどIT費用は「ランザビジネス」（現在のシステムを維持していくため）に使われ、その割合は日本では8割、米国では6割という統計値がある。
IT負債P.23 IT技術者の視点で見ると、DXの本質はデジタル化にある。デジタル化とはデータ化であり、データはソフトウェアで処理するため、「ソフトウェア化」と言うこともできる。
IT負債P.44 従来のシステム設計の根本思想は、データベースを中心として、トランザクションを活用しながら他システムと連携するというものだ。これが密結合のシステムを生む根本原因である。そして、密結合であることが様々な問題を引き起こしている。
P.69 2019年にエストニアを訪問した際、彼らの国のシステムの中核にある「X-Road」について説明を受けた。X-Roadでは、個人の情報を分けてデータベース化し、分けたデータベース単位でサービス化していた。新たなサービスを立ち上げる場合は、そのサービスを提供する企業に対して厳しいセキュリティ要件を確認するとともに、必要なデータをすべて提供するのでは無く、最低限必要な情報に限定し、API接続にて提供している。
P.135 大きな問題として、DXレポートでも指摘されているが、アジャイル型開発の場合の契約形態がある。常駐型でユーザー企業を支援していく場合、ユーザー企業の社員とITベンダーの社員が、適切な指揮命令系統に従って活動しないと派遣法に抵触する恐れがあるからだ。通常、ITベンダーとユーザー企業は、準委任契約を締結して業務を行うので、法的には受託契約の形態をとっている。
P.186 特に2018年は「マイクロサービス」をキーワードに有識者へのヒアリングを行った。クラウドベンダーは「リフト」（クラウド移行）よりもコスト削減効果の著しい「シフト」（クラウドネイティブ化＝マイクロサービス化）に重点を置き始めている。この点は2017年に訪問したときと相当変わってきている。
P.193 米国では、モノリスシステムからマイクロサービスへの移行は、SoEやSoRに関係なく、ソフトウェア開発技術の基本技術の変化として捉え、急速な変革が進んでいる。また、新たな技術の適応に関して、不可逆な方向転換が起こっていると思う。
P.223 米国の企業にマイクロサービスの規模について尋ねると、異口同音に「テストケース数」という答えが返ってきた。確かに、新たなマイクロサービスを開発する場合、追加された論理パターンの数（テストケース）が実際に必要な開発量やテスト量と強い相関を持つことは想像に難くない。
