読んだ動機 ロシアによるウクライナへの侵攻が2月末頃からはじまった。 すぐその後にCOTEN RADIOで【緊急収録】ウクライナとロシア 1/6　～ウクライナとロシアの歴史～が公開された。 それを聴いて全体像を浅く把握できたかなと思うと同時に、これを全て鵜呑みにしてしまってもそれはそれでバイアスだなという課題感を持った（この見方自体も Podcast 内で警告があった）。 なので、COTEN RADIO が提供している引用書籍で紹介されているかつ、読みやすそうなものを手に取ってみた 今回読んだ物語 ウクライナの歴史―ヨーロッパ最後の大国もそうだけど、COTEN RADIO を支える COTEN CREW 然り、資料を読んで発信してくれる方々全て感謝したいし尊い取り組みだなぁと改めて感じた。 こういう方々の活動全てが、今後の歴史を積み上げて作っていくんだなと思った。 （なるべく書籍に書かれてある事実と自身の意見は分けて書こうと努力はしてますが、間違いなどある場合はご容赦ください）。 引用とノート ウクライナ史の権威オレスト・スブテルニーは、ウクライナ史の最大のテーマは、「国がなかったこと」だとしている。すなわち、多くの国において歴史の最大のテーマがネーション・ステート（民族国家）の獲得とその発展であるのに比し、ウクライナでは国家の枠組なしで民族がいかに生き残ったかが歴史のメーン・テーマであった (p. 5) 序文からとても印象的で、ウクライナに関連する人々は国家という枠組み無しでどうやって生きてきたかの歴史になるというのが驚きだった。 1. スキタイ文明と日本神話 王権を正統化する黄金の鋤、軛、戦斧、盃が天から降ってきたとの話に関して、神話学者の大林太良氏、吉田敦彦氏らが、スキタイ神話が朝鮮半島を経由して日本まで伝播した可能性を指摘し、スキタイの器物が日本の皇統を正統化する三種の神器に対応するのではないかと推測しているのは興味深い。 (p. 19) 元々黒海北岸に住んでいたのはキンメリア人らしいが詳細が分かっていない。 その人々を追い出して土着したのがスキタイ人、彼らの建国伝説の中で金属製の器が4つあるがそれが日本神話の3種の神器とリンクしている、なんなら輸入されている可能性もあるのでは？という推察。 そんなことあったら素敵な推論だなと思った。 我々が気づくのは、このユーラシア大平原ではその後二〇〇〇年以上たってもほぼ同じことが繰り返されている点である (p. 26) 騎馬術が高く戦闘能力の高かったスキタイ人のペルシャ帝国の遠征からの防衛の話。 そこから1800年代のナポレオン遠征、1900年代のナチス・ドイツのソ連への侵攻、そして直近のロシア侵攻と何度も侵攻に晒されている。 中国で王権の象徴になるのは黄金ではなく「玉」であるのに、朝鮮半島の金冠塚（韓国慶州市）、我が国の藤ノ木古墳（奈良県斑鳩町）から見事な黄金（または金色）の冠が発見されたことについて、これは黄金崇拝の観念が「玉の国」である中国本土を通らずに、北方草原から回して伝播した可能性があると指摘している。 (p. 31) こちらもスキタイ文明と日本のリンクの推察。 こんな繋がりがあったとしたらワクワクする。 2. キエフ・ルーシは誰のもの ロシア側の言い分はこうである。キエフ公国の滅亡後、ウクライナの地はリトアニアやポーランドの領土となり、国そのものが消滅してしまって、継承しようにも継承者がいなくなってしまった。これに対し、キエフ・ルーシ公国を構成していたモスクワ公国は断絶することなく存続して、キエフ・ルーシ公国の制度と文化を継承し、その後のロシア帝国に発展していった。これからみてもロシアがキエフ・ルーシ公国の正統な継承者であることにはいまさら議論の余地はない。 (p. 40) ウクライナのナショナリストの言い分はこうである。モスクワを含む当時のキエフ・ルーシ公国の東北地方は民族・言語も違い、ようやく一六世紀になってフィン語に代わってスラヴ語が使われるようになったほどであった。一五世紀のモスクワは、キエフ・ルーシ公国の支配下にあった非スラヴ諸部族の連合体であり、キエフ・ルーシ公国の後継者とはとても言いがたい。また過酷な専制中央集権のロシア・ソ連のシステムはキエフ・ルーシ公国のシステムとはまったく異なり、別系統の国である (p. 40) 今までキエフ・ルーシ公国はロシア（ソ連）史の文脈で出てくることが多かったのは、ウクライナは独立さえしていなかったから。 しかし独立したことでウクライナも一つの独立国、として考えるとこのキエフ・ルーシ公国は誰のものか、という議論になってきた。 この辺りは現状なかなかセンシティブな話題になりうるので、改めて事実とそれぞれの認識をノートとして書いておく。 キエフ・ルーシ公国を作ったのは東スラブ人 東スラブ人は現在のロシア人、ウクライナ人、ベラルーシ人の先祖となる 8世紀頃ヴァイキングの登場 ヴァイキングは自身のことをルーシと呼んだ リューリクがルーシの首長になる ルーシの継承方式が曖昧（兄弟相続と父子相続のmix）で衰退 その中でヴォロディミールは各地の制服の成功、キリスト教を国境にし聖公と呼ばれる ヤロスラフはキエフ大公、内政に長けており賢公とも呼ばれる キエフ・ルーシ公国はキリスト教化 ビザンツ文化を吸収 ギリシャ正教を選択したことが後世ロシアや西欧諸国・ポーランドとの断絶を生むきっかけの一つ 12世紀頃から衰退の時期 諸公国の連合体のような形になる 代表的なのがモスクワ公国, ハーリチ・ヴォルイニ公国 モンゴルによる制服と「タタールのくびき」が始まる 「タタールのくびき」はロシア史視点なので盛られている可能性があるらしい？ モスクワ公国はタタールに統治された ハーリチ・ヴォルイニ公国 キエフ陥落後も1世紀近く存続、現在のウクライナにとっても重要 ウクライナはキエフ・ルーシ公国の直系と主張している根拠がこれ ここからタタールはじめ各国の干渉を防ぐが、最終的にリトアニアとポーランドに並行される 13世紀半ば~17世紀半ばは空白 リトアニアとポーランドがキエフ・ルーシ公国だったところを支配 モスクワ大公国、ポーランド公国、リトアニア公国と分けた ウクライナという地名が生まれたのもこの時期 ウクライナの地は、古代からクリミアを通じてギリシア・ローマ（その後のイタリア）世界および海の世界とつながっているのである。この開放性は、他のスラヴ諸国の歴史が内陸的な印象を与えるのとは対照的に、ウクライナの大きな特色である。 ...

前回 の続き Scaling Slack’s Mobile Codebases: Modernization 当初は Modularization と Modernization は分けてフェーズとして考えていた Modularization を取り組むうちに、二つを分けて考えて進めるのはコードの書き換えなど重複する作業が多いことに気づいた 2021年2月から初めて1年かかった Modularization は Stabilization を進めていたcoreメンバーだけでは無理で、各 product team からのヘルプが必要だった Modularization PJ 以前からいくつかの module はあったが、機能などは全て app target に入っていた iOS module に分ける際に、module がどのようなストラクチャで何が入るかなど細かく定義した 3 types Features アプリ内の機能 1画面や画面の1部、画面の集合など Feature architecture に従う 各 Feature module は I/F module と実装 module を持つ　I/F module は protocol と data class 実装 module は上記の protocol に準拠した実装と内部で使うヘルパーなど これによって feature 同士の結合が少なくなり、内部実装を変えても依存を壊さないことが可能になった Services API call, データ永続化など何かしら専用の機能を持つコードの集合 UI コードを含まない Service も同様に I/F と実装で module を分ける Service の実装 module は他の Service や Feature module とリンクできないルールがある Libraries I/Fと実装をわざわざ分ける必要のない、データ構造や簡単なクラスや関数の集合 システムのAPIの extension など dependency graph の一番下にあるイメージ Bazel とてもいい影響を与えた 導入以前はmoduleを作るたびにprojectのコンフリクがあり辛かった target, module それらの依存関係を定義することがdけいた Basel build graph から XcodeGen 経由で Xcode でビルドもできるし、Bazel からビルドもできる Bazel 以前は dynamic library として module を link していたので起動時間が伸びたが、導入したことで static link にできた module 化したことで、Bazel の remote shared cache がとても良かった Code generation 新モジュール作成時のファイルテンプレートを使った script による自動作成 CoreData のモデルの更新も script でやって boilerplate 削減 feature flag の作成削除も自動化 Android iOS に似ているが詳細がいくつか違う スキップ その他感想など Slack の Principal Engineer でも XCode って書くんだなって思った Scaling Slack’s Mobile Codebases: Modernization Modernization モダン化はこのPJが終わったからといって終わるわけではない 将来の新しい技術やデザインパターンなどにも適合できるような余地が必要 このPJではさまざまな理由で SwiftUI は不採用としたが、将来的には取り入れるような状態にした iOS architecture 独自のVIPERを採用 Feature, View, Interact, Presenter データフローを強制できる 開発者を楽にさせるために generics やテンプレートを使っている 詳細は別でまたblogにしたい stricter linting 新しいmodule下では、以前より使っていた SwiftLint より強力な linting を入れた static let shared などの global singleton global object でも、依存関係を明示的にしてmockingを簡単にするためにI/F からの注入を促した Notifications/NotificaitonCenter Combine の publishers/subscribers の使用を促した UIViewController.topPresented .topMostPresentedViewControllerInStack的なやつ UIKit の使用 内製の SlackKit というUIコンポーネントを使うようにした Combine 既に限定的な場所で inhouse の Reactive Programming ぽい RxSwift みたいなものは使っていた なのでそこから Combine へのマイグレーションは割と自然にできた PJ当初はbackportがなかったかつSlackはiOS12もサポートしていたので、CombineX を使っていた SlackKit 内製のUIコンポーネント PJの結果 PJ通して1.5年で2022年1月に終了 iOS コードベース中 68% Modernized 81% Modularized 280モジュールが作られた CIの安定性が77%->90% CI実行時間が64%に developer survey も良好 Next steps module 間の依存関係 module 数の増加は意図した結果だったが、すぐに元々のルールが十分ではないことに気づいた 当初のルールは Features もしくは Services は他の Features / Services の I/F モジュールとだけ依存できる、というものだけ なので Library は他のそれと依存できるし、Features / Services とも依存できてしまった これが低レベルもしくは上の階層でおこり、すぐに module 間の循環参照が起きてしまった これを解決するために Layer を導入し、あるモジュールが属するレイヤーがあってそのモジュールはそれより下のレイヤーにのみ依存できるようなルールを作って修正中 dependency injection module 化したことで整理されて依存するコードが module から作成できるようになって mocking も可能になった ただ app target は多数のコードが注入され、簡単に循環参照やメモリリークするようになってしまった injection の方法をいろいろ調査して、標準の initializer injection を使うことに決めた dev friendly, compile 時に決定されるなどの理由 Features / Services の実装 module だけが app target に link されている そしてそれらの依存関係はそれらの module が作成される時に一緒に組み込まれないといけない つまりこれだと app target が大きいままで、扱いづらくなってしまう Needle という DI framework の導入を考えている これで module 間の依存を明確化でき、app target の全ての実装 module を link しなくてもビルドできるようになる

Client Consistency at Slack: Beyond Libslack Slack アプリでのC++によるコード共通化をやめたという記事 multi-platform の恩恵が減った(iOS/Androidのみ)、C++が"できる"モバイルエンジニアがあまりいないこと、PF毎の結合・ビルド・テストのオーバーヘッドなどがstopした背景 ライブラリのリリースも各PFでsync upしないといけないとかもあるあるだなと思った やめただけでなく、そこからの何を学んで何を始めたかまで書かれていて良かった 2014年に書かれた Dropbox の C++ によるコード共通化と、2019に書かれたそれをやめた記事も合わせて読むと理解が深まる How Dropbox Uses C++ for Cross-Platform iOS and Android Development The (not so) hidden cost of sharing code between iOS and Android Stabilize, Modularize, Modernize: Scaling Slack’s Mobile Codebases Slack アプリのリファクタリングPJの長編ブログ第一弾 書かれていることは大体良くある話でどれも納得できた rapid growth が訪れると、今までは一度に返せていたデータも server/client どちらも捌けなくなってくる 合わせて組織的に人数も増えるので、数人では成り立っていたレイヤーもあるようでない一貫性のあまり無い architecture も too complex になり限界を迎える growth に伴って機能追加もどんどん増えるので、complexity が様々な角度で上がる Rewrite/Refactor の議論 Rewrite はリスクが高すぎるという良くある指摘 並列で走る既存の機能追加の追従、時間とコストの度合いなど Slack は既存の refactor を選択した 以下は驚いた点 Android は2015年に一度 rearchitect しただけ、iOSに関しては2013年のリリース以来ずっとそのまま 過去にコード共通化も試したが残念なところが多くて失敗 Client Consistency at Slack: Beyond Libslack 2020年夏にPJが開始 ゴールは明確で、技術負債の返済と今後5年の開発に適応できる程度のモダンな architecture IC ドリブンな PJ というのが面白かった executive stakeholders に対して、長期的にどのようなリターンがあるかを将来的にあるかを継続して propose していたらしい その proposal の主な観点は3つで どうやって今ある問題を解決するか ビルド時間、テスト失敗率、マイグレーション率、モバイル開発者からのフィードバックなどのデータから どうやって進捗を計測するか ゴールまでの進捗をダッシュボード化 ビルド時間の減少、main app target のコード行数など PJの各フェーズにおいて、失敗した場合にどのようなバックアッププラン(failure mode)があるか 期待しない結果になった場合に、とりうる選択をあげる これがリスクを和らげるための良いデモ材料にもなった PJにおける最終的な3つのテーマにしてそれぞれフェーズに分けて進めた Stabilization 一番ヤバい技術負債やアンチパターンを取り除いて、pendになっていた一番重要なマイグレーションを終わらせる Modularization モノリスになってるappをコンポーネント化、それによって相互依存性やビルド時間の減少、並列での開発を可能にさせる Modernization より forward-looking な技術やデザインパターンを採用する この進め方を読んでとても良いなと思ったのと同時に、進め方を分けると大きくhorizontal/vertical あるなと思った。これは horizontal 対して vertical はある機能に対して、一気にこのフェーズを進めてそれを横展開してアプリ全体に広げるというパターン 以前経験した大規模なリファクタなどはこれに当たるなと思った これのメリットもあって、1つの機能で限定的にはじめるので影響も軽微、かつ全て行うのでこれが成功すれば横展開の確度も高い デメリットとしては失敗した時のコストが高い Stabilization フェーズ 6ヶ月続いた developer による worst な codebase に対する「止血」作業 iOS は既存のObjC の Swift 移行、ネットワークとデータアクセス library の移行

Sharing our Engineering Career Framework with the world Dropbox のエンジニアリングチームのキャリアラダー それぞれのレベルで期待される Impact が定義されている What is Impact? あえて Impact はある程度曖昧な定義になっているが、これに対しての方針と Impact を出すための lever が書かれていたのが面白かった Impact は Consistency, Velocity, Accountability が無いといけない 例えば一時的に出た結果や、長期間かけて出した累積の結果ではいけない またシニアレベルになるにつれて、自身の決定がビジネスへの Impact につながることが求められる Impact を出すためのレバー ドメインエキスパート ここでいうドメインとは技術的なもので、Windows / iOS など イノベーション プロダクトエキスパート プロジェクトリーダーシップ テクニカルリーダーシップとメンター 過去の自分の経験を振り返っても、このようなレバーのようなアドバイスがもらえる・できると next step が見えやすいなと思った How Facebook Builds Products (以前保存した時は確か url の通り “Execution at Facebook” だったがタイトル変わった？) 入社1年弱の Facebook PM が Twitter にまだ JIRA チケットも書いてないし sprint もやってないよ、と書いたことをきっかけに色々な人があぁだこうだ言ってるのを Facebook のシニアなPMがまとめた記事 Uber でも開発系の Project Management は EM/Engineers が行っているらしい この記事では Facebook PM の責任は2つで great strategy and great execution 「どのゲームで遊ぶのか、どうやってそれを遊ぶのか」を決めるのが役割 だからと言って結果はどうでも良くはなくて、むしろ100%責任がある execution にも順位付けがあると書かれていたのが面白かった

How @MainActor works @MainActor property wrapper がどういう動きになっているのか、スクラッチで実際に作ってみている記事 job と executor の2つくらいで、かなりシンプルに作られていることを知れた Weak Self – Closure Rules of Thumb [weak self] 時の escaping closure の扱いについて よく言われるやつだけど、どれにも落とし穴があるので注意という良い記事だった What are Swift Concurrency’s task local values? Task.init {} を使っているとたまにエラーになる Task local value の話 @TaskLocal property wrapper を使えば、task のスコープ内でのみ有効なプロパティが定義できる それを Task を識別できる id などにすれば、非同期処理のデバッグもしやすい An introduction to synchronizing access with Swift’s Actors DateFormatter のキャッシュを例にして、スレッド跨いだアクセスでクラッシュさせながら GCD、Actor とステップに分けて分かりやすく解説している Thoughts on Combine in an async/await world async/await が出た当時の記事 Combine との差別化や意図などが書かれている 記事にも書かれている通り、Combine は値やイベントの同期や操作が目的で async/await が出ても無くならないとは思う かつ Combine は SwiftUI に密に関わっているので

組織デザイン という本を SNS などで何人かが読んでいたので気になって手に取ってみた。 全体通しての感想 今までの EM などの実務を通して断片的に感じてきた事が改めて整理されていた。 また、それについて新しい角度で書かれていたりなど発見がいくつかあった。 特にソフトウェアエンジニアリングに特化した本ではないものの、共通する事がたくさんあるということに気づけた。 読書メモ (メモの見出しと添字は適当に付けていて書籍とは関連無いです) 1. 調整と分業について 役割を分化させることを分業と呼び、それらの多様な役割の時間的・空間的連動を確保する努力のことを調整と呼ぶ p.14 どのような組織であろうと、合理的に運営されようと意図されているのであれば、これら二つの要素を備えようと努力しようとしているはずである p.17 分業を行うメリットについて書かれていて、主に以下の2つがあった。 各タスクを完了させるためのパラメータがそれぞれにあるとして、全てを満たす人材はほとんどいない。いても賃金が高い それぞれ1つのパラメータを満たす人材であれば現実的、かつ賃金も前者に比べて安い。なのでスケールアウトが現実的 これが「組織」を形成するモチベーションの元なんじゃないかなと感じた。 これを考えついたのはコンピュータの父とも呼ばれるチャールズ・バベッジというのも面白かった。 アルゴリズムでも分割統治法という考え方があるので、似たような発想なのかなと思った。 2. プロフェッショナルについて プロフェッショナルや熟練工を活用することでもたらされるマイナスもある。基本的にはプロフェッショナルの雇用は重要な競争源とはなりにくいという問題と、かえってプロフェッショナルと他の人々との間の統合・調整が難しくなる p.116 直感とは真逆で意外な視点だった、少しソフトウェア産業とは違う視点かもしれないと思った。 その一方で、スケールアウトや仕組み化・標準化しづらいという点から考えると理解しやすいかもと感じた。 そしてプロフェッショナルは自分の所属する組織よりも、自分の専門領域やそのコミュニティに対して忠誠心を持つので他の組織に移籍しやすいという点もあり納得感があった。 余談だけど、産業革命時にイギリスの熟練工のせいで工業化が遅れ、一方歴史の浅いアメリカは熟練工がいないので自動化に頼らざるを得ず、一気にライジングしたのと似てるのかなと思った。 3. ヒエラルキーを使った管理について ヒエラルキーには「上司による部下の支配」といったマイナスのイメージがつきまとうこともあるが、例外に対する対応に関していえば、辿るべきコミュニケーションの経路が固定されているだけで対応の内容は幅広く選択可能であるため、本来、ある程度の柔軟性を備えた調整メカニズムだと評価されるべき p.167 ｀調整に際して発生する例外に対しての処理機` という言語化に、改めて管理者の役割を再認識できた。 そしてそのためにある程度の Slack が必要で、それが調整弁として機能する。 調整にも予め可能なものとできないものがあって、前者に関しては標準化などで可能。 ただ、後者は監督者による例外処理などで対応するしかない。 管理者は例外処理の catch の方。 「なるほど、フラットな組織を設計したい場合には管理の幅を広くとれば良い」と考える人がいるかもしれないが、物事はそれほど簡単ではない。p.174 よくある 2-pizza rule や span of control などのマネジメントできる限界数の話がいくつかの指標で納得感ある説明がされていた。 例外の数が多い、例外の分析が難しい、例外の処理にかけられる時間が少ない、などのいくつかの制約条件があってその定数（人数）が決まってくるんだなと思った。 自分が忌み嫌っているタイプの秩序の下でやる気をみなぎらせられる人間は、滅多にいないだろう。だから本当はヒエラルキーの特徴そのものに問題があるわけではなくても、ヒエラルキーをみんなが嫌ってるが故に、みんなのモチベーションが低下し、ヒエラルキーのパフォーマンスが悪くなる可能性がある p.216 ヒエラルキーという言葉や概念自体が影響しているという話、トートロジーぽくて面白かった。 確かに例外処理の機構やコミュニケーションパスの固定化などメリットの方が多い気もするのに、なぜか嫌われていると感じるのはそういった背景もあるのかもしれない。 「スラック」とは「ゆるみ」とか「たるみ」のことである。組織ユニット同士が緊密に結びつけられているよりも、若干「ゆるみ」が設けられている方が、調整の仕事は楽になる。 p.223 An Elegant Puzzle: 2 Organizations のメモ でも似たような Slack についての話があった。 ...

三体 の作者でもある劉慈欣の短編集 円 劉慈欣短篇集 を読んだ。 収録されてるものは 三体 より前に発表されたものもあれば後のもあって、 いくつかが 三体 へのエッセンスと感じられるかもしれない。 感想 各作品どれも作者特有のSFギミックやデバイスを絡めた設定が入っていて、三体ロスな人にはとても良い短編集だと思った。読みやすいし。 その中で一つだけお気に入りを選ぶとすると ‘郷村教師’ が抜群に良かった。 田舎の死が近い教師を中心に話が進んでいき、方向性が見えない途中から一気に世界観が広がっていく感じは作者ならではだと思った。 他にも未来のオリンピックを描く ‘栄光と夢’、 小さい頃の夢がそのまま世界を変えていく割とポジティブめな’円円のシャボン玉’ も良かった。

DARK SOULS REMASTERED を2021年のSteam オータムセールで割引されていたので購入した。 ソウル系シリーズプレイ歴 以下のような感じで、Bloodborne、 Sekiro あたりからしっかり取り組めるようになってきたので それ以降少しずつ過去作品を再度プレイしている。 以下シリーズ発売日順 Demon’s Souls 2009年発売当時はおそらく未プレイ PS5リマスターでクリア DARK SOULS REMASTERED 2011年発売当時は早々に離脱、おそらく牛頭のデーモン前後 2021年末にSteamでクリア ー DARK SOULS II 2014年発売当時は序盤で断念、古い竜狩りに瞬殺されるくらいまでは記憶あり 2022年現在プレイ中 Bloodborne 2015年発売当時に(何故か)クリア DLC は購入したが30fpsが現在辛くてプレイ断念… DARK SOULS III 2016年発売当時は序盤で断念 セールで購入したので再プレイ予定 Sekiro 2019年発売当時にPS4でクリア 感想 他ソウルシリーズ作品との比較 先にプレイしていたDemon’s SoulsやSekiroで, パリィやバックスタブなどのゲームシステムに慣れていたおかげで、初見の時とは違い楽にプレイすることができた。 それらは一応ゲーム内でも説明はあるが、あまり理解はしておらず、当時は積極的に使うことはなかった。 他にも生者の時のみ呼び出せる白霊NPCなども詰んだ時に助けられた。 Sekiro と違いソウルシリーズのゲームシステム的に、ソウルを使ってステータスを振れたり武器防具のレベル上げができる点も難易度を下げてくれていた。 (プレイヤー自身のメンタル面でもソウルシリーズに慣れてきていたおかげで折れずに進めることができた。) ゲームバランス ゲームバランスは中盤頃まではとても良かったと思う。 特にアノールロンドの屋根の上の槍や、そこでのスモウ・オーンスタインというボス戦は白熱死闘だった。 ただ、上記の比較にも書いた通り後半にいくにつれて武器や防具、ソウルが溜まっていき比較的楽に敵が倒せたり浴びるダメージも減っていって緊張感が徐々に薄れていった感じがした。 同様にボス戦もそこまで苦労しなかったり、似たようなボスが多かった気もした。もしかしたら慣れの問題もあるかもしれない。 と言いつつ、ラスボスの薪の王グウィンは10回以上死んだ… (倒した時のプレイ動画) 操作性 Bloodborne や Sekiro などと比べるとモッサリ感はどうしてもあるが、特段気になることはなかった。 リマスターということもあって、グラフィックも綺麗かつ60fpsでモダンなゲームと遜色なく遊べた。

課題感 1年以上前にGatsby + Netlify の新しいブログを作ったけれど、 Gatsby を理解していないせいでカスタマイズが難しいなどの問題があって課題を途中から感じていた。 その中で @wapa5powさんのブログをNext.jsへ移行しましたをみて、課題感もかなり似ていたので、いつか移行したいなと思っていて、年末ということもあり移行することにした。 概要 テンプレート blog-starter-typescriptのテンプレートを使ってブログを作成した。 これで Markdown をベースに SSG で静的なブログが作れる。 Deploy Deploy とホスティングはVercelを使っている。 体感だが以前より表示が速くなった気がする。 OGP OGPもnode-canvasを使っていて、 yarn build 時に自動生成されるようにした。 Canvas は最新バージョンだとVercelのnodeのバージョンが対応しておらずビルドできなかったので以下を参考にした。 【Next.js × Vercel】OGP画像を動的生成してみた Next.js + Vercel で OGP の画像を動的に生成する 【動的OGP】Next.js + TypeScript + Vercelデプロイで動的OGPを実現する 動的と言っても静的ビルド時にMarkdownからタイトルを持ってきてpngとして書き出しているだけなので、リクエスト毎に生成されるわけでは無いので優しい。 CSS Tailwind CSSというのがバンドルされていたのでそれを使っている。 適当に検索して書くと良い感じのpaddingやmargin、リサイズしてくれるので便利。 正直雰囲気で書いている感は否めない。

今まで一度も PC を自分で組んだことは無かったけれど、いつかはやってみたい気持ちはあった。 それを後押ししたのが、 MS による Bethesda (ZeniMax Media) の買収だった。 具体的には2022年11月11日発売予定の Starfield が、噂通り PC/Xbox exclusive になることが決定してしまったから。 これを機に自分で PC を組んで、より良い環境でゲームをプレイしながらそれに備えることにした。 部品 組み立てに使った部品一覧はこちらの pcpartpicker にまとめた。 このサイトは自分にとっては必須で、部品間の compatibility をチェックしてくれたり、他の build を参考に部品を選ぶことができる。 PC Case NZXT H510 Elite 他の部品も NZXT 製品が多いのと、デザイン的にも無難だったのが主な理由 Motherboard ROG STRIX Z590-F GAMING WIFI GPU を ASUS にする予定だったので、その流れでなんとなく mobo も ASUS から選んだ。 種類に関しても11世代Intelまでサポートしている位しかみていなかった。 買って気づくのは思った以上に光っていたりドラゴンなどの模様が結構書かれていること。 CPU INTEL 第10世代CPU Comet Lake-S Corei9-10900KF Intel か Ryzen かで悩んでいたが、どちらも品薄だったので GPU のボトルネックにならない程度のそれなりに高い性能であれば何でもいいと思った。 結果として満足に動いてるので全く問題ないが、もし在庫があったら第11世代にしても良かったなとは思う。 CPU Cooler NZXT KRAKEN Z63 水冷のパフォーマンスはよく知らなかったけど、モニターが付いていたり水冷が単純にかっこよかったのでこれにした。 これの組み立てが一番難しかった。 ...