熊崎 宏樹:正直どっちをやっても全然いいと思います。C++はツールチェインが複雑すぎてまともなコードを書くようになるまでが遠いですが、メモリを直接いじくり回す醍醐味と高度なテンプレートプログラミングの両方が楽しめるいい言語ですし潰しが効きます。ただしエラーメッセージが不親切すぎてSEGVからのエスパーが要求されたりと厳しい事ばかりです。ですがシステム開発方面の特に深いところまで入り込んでいくならCは避けては通れないのでC++を経由するのは理にかなっています。 Rustは慣れるまでが大変ですがツールチェインは安定してて高度で今風なコードが書けますし、何よりエラーメッセージがわかりやすいので独学するにはC++よりも優しいかも知れません。しかし世間の需要で言うとRustを現場で使ってるところはそんなに多くないし、コードもそんなに多くないですしLLMすらもRustの例が少ないせいかコード品質がいまいちという話もあります。 どちらにせよLLMの助けを得ながら高速道路を走れるのでいい時代になりましたね。

熊崎 宏樹:「何か動くもの」に対する見解の相違かなと思います。 「コンパイルが通る程度に正しいものが書ける」というのと「実用的なソフトウェア」の間にはめちゃくちゃ遠い距離があって、その間には無数の「途中まで書いたけど筋が悪くて捨てたソフトウェア」があってどれも無名すぎてgithubの隙間に転がっています。 ソフトウェアの格言に「3回作り直した時に一番良い設計になる」というのがありますが、一人のソフトウェアエンジニアがまともに知見を揃えるまでの間にも無数の書き捨てソフトウェアがあります。歩き始めた1歳児が転ばずに歩けるようになるまで無数の転倒を経験するのと同様に、書きたいソフトウェアに向けてとりあえず書き始めてみて何もかも動かないので他人のを参考にして、自分の書いたコードすら時間が経つと意味がわからなくなるので整理すべきであると身をもって学んで、他人の環境で動かないので移植性の大切さを学んで、そういう長い道のりの果てにいっぱしのソフトウェアエンジニアができあがります。 もちろん試行錯誤で学ぶのはおすすめですが、先人が敷いてくれた高速道路に乗るのもおすすめで、最近読んだ中だと「良いコードの道しるべ」がその過程での学びを圧縮して教えててくれてよかったです。 https://book.mynavi.jp/ec/products/detail/id=147381 https://book.mynavi.jp/ec/products/detail/id=147381 ただし、こういう本を読んでも自分ごとであると理解して血肉にするにはある程度は手を動かして痛い目をみないと身が入らないという話もあるので、その辺の匙加減は自分でバランスをとりながらとにかく毎日何かしらコードを書くようにしていくのがいいと思います。

熊崎 宏樹:いいですね。LLMに聞いてもそれなりな答えは返ってきそうですが敢えて僕に訊くという事は僕の偏見を期待している物として回答します。 僕の基本的な志向としては、潰しが利き、金になりそうで他では学べない物を学ぶべきと思ってて、逆にCS関係ないドメイン知識やアプリが主題となってるところは就職してからでも嫌でも触る事になるから学生のうちから無理してやらなくていいと思っています。 > エネルギー効率の良い電子回路を設計するソフトウェアツールを開発。C++やPythonを使った本格的なソフト開発が可能。オープンソースや企業との連携もあり。(教授の評価　1.7/5.0) 電子回路設計というアプリケーションに特段興味があるわけでないならおすすめしません。コードを書けるだけという話であれば他でもできるしオープンソースなんてコードを転がしているだけのこともままあります。企業と連携して企業側の都合で研究対象がブレるぐらいならソフトウェアの研究をすべきだと思っています。 > 組込み向けのOS開発やハードウェア制御を学べる。C/C++を使ってOSやドライバを開発。国際学会での発表機会も。(教授の評価　3.7/5.0) 良さそうです。OS開発やハードウェア制御はよく学んでおくとソフトウェアを書く際のさまざまな所に潰しが聞きます。こういうところでぐちゃぐちゃなコードにまみれた経験を血肉として育って大成したソフトウェアエンジニアというのは割とよくいます。 > IoTやスマートデバイスの実装とプログラミングが中心。Arduinoなどのマイコンでハード＋ソフト開発を体験。(教授の評価　4.7/5.0) 内容次第です。IoTもスマートデバイスも割とミーハーな分野なのでCSの深みよりもアプリとして革新的みたいな方向で推してるタイプだったら僕は敬遠します。IoTとして意義のあるアプリケーションが世の中に出せたからと言ってそれはアプリを考えた人の功績であってその裏で働いた人間には分前しかありませんし学生の身分なら卒業してしまえばもう無関係です。 > 大規模ネットワークやサイバーセキュリティのシミュレーションツール開発が中心。実践的なネットワーク設定とセキュリティ設計が学べる。(教授の評価　3.5/5.0) いいですね、ネットワーク設定やセキュリティ設計は独学よりも人に師事した方が学びが早いですしどこでも学べる物ではありません。希少価値があります。ツール開発っていう点がちょっと引っ掛かりますけど希少性と換金性の高いCS知識がドバドバありそうな研究室かどうか見極めに行く価値があります。 > AIやディープラーニングを画像認識や医療などに応用。PyTorchやTensorFlowを使ってプロジェクト型開発ができる。(教授の評価　4.25.0) 行かないです。アプリのための労働力として駆り出されるだけでAIについてもDNNについても一ユーザーとしての知見しか得られそうにありません。趣味で触るのは好きにしたら良いですが自分のメインウェポンとして据えるには深さにも将来性にも疑問が残ります。 > 顔認識、医療画像、農業AIなど応用コンピュータビジョンに特化。国際的な共同研究も多く、オープンソースコードへの貢献が可能。(教授の評価　4.3/5.0) 同じく行かないです。アプリとして優れた物を世に出しているかも知れないけれどAIをやるならその内部の仕組みの方に深入りしていかないと希少性の高い知識は得られません。AIを使わせてもらうだけの立場であれば新参者がたくさん飛び込んできてて既にレッドオーシャンです。オープンソースコードも実態としてコミュニティの運営のような話ですらなくただコードを転がしてるだけのほうが大半ですから要確認です。 > 公平性・プライバシーを守るAIやデータ処理ソフトウェアを開発。Pythonを使いアルゴリズムを実装。研究成果はオープンソースで公開することも。(教授の評価　2.7/5.0) プライバシー系は常に一定の需要はあるんですがCSの主題から外れますし、差別化要因としてマーケティングの文脈で使われることがよくある一方でプライバシー自体が経済的優位性を持ってお金を産むわけではないのであまり面白そうだとは思っていません。データ処理ソフトウェアというので準同型暗号か秘密分散あたりかなと思うんですが、ちょっと業界研究して本当に世間からそれらが必須の物として要求されているか実態を見てきた方が良いのではと思います。みんな口々に大事だねとはいうんだけどそれだけを理由に何千億というお金を払うつもりもない、みたいな地平が広がっています。 > ハードウェアとソフトウェアを組み合わせた実験的セキュリティ開発。RFIDやスマートグリッド向けの実装も経験可能。(教授の評価　3.3/5.0) セキュリティ開発の深い闇に突撃している感じが良いですね。セキュリティ開発のイロハをきちんと学んでちゃんとした学会に出しているようであればかなりの換金性がありますし技術的な希少性も高そうです。 以上、僕の偏見をお届けしました。参考になれば幸いです。

熊崎 宏樹:自身の志向をきちんと言語化していて偉いと思います。さて外資エンジニアの他に商社を選択肢に入れている理由が「報酬が良い事」であるなら、業界研究をもう少し深掘りしたほうがいいと思います。 https://talentsquare.co.jp/career/mitsubishi-corp-salary/ https://talentsquare.co.jp/career/mitsubishi-corp-salary/ https://talentsquare.co.jp/career/sumitomo-corp-salary/ https://talentsquare.co.jp/career/sumitomo-corp-salary/ https://talentsquare.co.jp/career/mitsui-co-salary/ https://talentsquare.co.jp/career/mitsui-co-salary/ 軽く検索して出てくる商社の数字はもちろん日本の平均と比べるとトップ3%とかの範疇である事ことは正しいですが、これと比べると外資エンジニアの方が給料がいいです。国内サービスに年収を登録している人は大体若手や非SWE職が多いので上のサービスで外資の平均年収を見積もると大きく外れる事になります。 アメリカでは頻出のlevels.fyiは僕の見ている数字と矛盾がなくて https://www.levels.fyi/?compare=Google,Facebook,Apple,Microsoft,Amazon&track=Software%20Engineer 例えばGoogleのソフトウェアエンジニア職なら、アメリカでのドル年収を日本円換算するとL3（新卒レベル）で3042万、L4（一般SWE、僕もここ）で4317万、L5（シニアSWE）で6105万。ただしこの数字はアメリカで働いてる場合の数字なので日本で働いている僕は流石にこの年収ではないですけれど、商社系と比べると客観的に見ても大きな伸び代があることがわかると思います。特にL7より上なんかは年収の上昇幅がすごくて、商社だと部長ですら4000万は行かないのに外資ソフトウェアエンジニア職は部長ぐらいのグレードなら億を超える事は珍しくなくなります。ですから「給与面では商社の方が有利なのでは」というのは誤りです。現に僕自身もアメリカで働いてる水準ではないにせよ平社員グレードのまま三菱商事の部長代行みたいな給料をいただいております。 キャリアの話に戻ると、商社としての実務経験を何年積もうがソフトウェアエンジニアとしての経験としては数えませんし、アメリカのCSの大学院を出た同僚が「Googleに勤めれているから結果的に元は取れているが学んだ内容が学費に見合うとは言い難いので万人にはおすすめできない」と言ってたのが示す通り、外資SWEのキャリアを志向するならそれらを経由するのは最善ではないと思います。日本のトップ大学のCSの授業は十分にレベルが高くてアメリカに行かないと開けれない悟りは特にありません（もちろんコネ作りと英語習熟の為と割り切るならそれでいいと思いますが）。ですので「商社として働いてアメリカでCSの極意を学んでつよつよになってから外資SWE」というのは割と回り道をしています。 初めからソフトウェアエンジニアを志向してそういうスキルセットに寄せていく方が、最終的に外資ソフトウェアエンジニアにならないにしてもこの先30年ぐらいは潰しが効く人材として生きていけるのではないかと考えていますが、まぁこれは一介のソフトウェアエンジニアによるポジショントークだと思って聞き流してください。

熊崎 宏樹:この質問が来た当時ぐらいなら、コード書いてて頻繁にある「この目的の為にはこのライブラリを引っ張り出してきてこうしないといけない、面倒だけどみんなやってるんだよなぁ」というパワポレベルの解像度でしか脳内にないコードを具体化してコピペ元として使わせてもらうような使い方をしていました。コピペ元は探せばいっぱいありそうだけど具体的にはない、っていうケースに対して特に便利でした。 エージェントにコンテキストを結構な量で叩き込まないと気の利いたコードを出してくれないと思っていたのですが昨今のLLMのコンテキストなら雑に入れても割といいやつを書いてくれますね。これには驚きました。一年後にはまた風景がガラッと変わっていそうですが、少なくとも今はまだ完全にコードを任せれる感じではないので、本業のプログラミング作業とは別の作業ディレクトリで独立したパッチをすでに一通り実装が終わった箇所のユニットテストの拡充とかの優先度が低いところにバックグラウンドで書かせてたまに様子を見に行って詰まってたら手作業で直して続行する、みたいな方法で自分自身のLLM経験値を積みながら成果物の最大化を図っています。 あと良いのがパッチのレビューですね。書いたパッチをLLMに全部読ませてレビューコメントもらうの、的外れな点もあるけどなぜか褒めてくれたりするので気分が良いしtypoとかコード更新の一貫性漏れ（javadocが古くなってるとか）を高精度で拾ってくれるので注意力が散漫な僕の欠点をうまい具合に補ってくれて助かります。LLMレビュワー自身は別に何人いても良いので、観点や美学が違うLLMレビュワーを複数用意して並行レビューさせてコメントをこちらで取捨選択してその反映自体も別のLLMにやらせる、とかできたらだいぶ嬉しいだろうなと思っています。

熊崎 宏樹:公開されている情報を元に話しますね。2016年の記事ですが「Why Google stores billions of lines of code in a single repository」というのがあって当然ながら英語ですか要所をかい摘んで説明します。 これは有名な話ですが、Googleは社内で使われるほとんどのソースコードを単一のリポジトリ（Mono Repository、モノリポ）に入れています。日頃お使いのGoogle検索エンジンも当然その中に入っていますがそれ以外の諸々も同じリポジトリの中に入っています。おかげで「とりあえず最新版にアクセスすれば個々のソフトウェア間のバージョン互換問題は基本的にない」というシンプルさが保てます（unified versioningと記事内では呼ばれています）。なんらか特定の機能が必要になっても隣のチームのコードをgit cloneなどすることなくすぐにアクセスできたり、複数のリポジトリから依存しているライブラリを非互換に書き換える事も依存している側のコードを全部書き換えて回るパッチを作れば良いので原理的には可能です（リリースタイミングなどの話は別として）。メリットは大きいのですが、この規模に対応できるツールが必要になるというデメリットもあります。 どうやら2015年の時点で約10億個のファイルと3500万コミット歴があり86TBのデータが含まれていると書かれています。 確実に言えるのはこんな巨大な物をホイホイと扱う市販ソフトやOSSは存在しないという事で、Googleはそれらのために必要なツールを自作しました。この巨大なコードが入っているリポジトリはGitではなくPiperというシステムに保管されています。Piperは10を超えるデータセンターをまたがってPaxosで一貫性を保ちながら複製されています。それ以前はPerforceというバージョン管理システムのキャッシュ機構をカスタムしながら使っていたようですがコードが膨らむに連れてPiperに移る動機になったと書かれています。 Piperにアクセスする際はgit cloneのように手元に複製するのではなくて、LinuxのFUSE(Filesystem in Userspace)を利用したクラウドベースのClient in the Cloud 略してCitCというクライアントをマウントします。これによって開発者はリポジトリー全体があたかも手元にあるかのようにcd/lsなどでディレクトリ内を移動できます。マウントしても当然86TB全体は物理的にダウンロードはできないのでFUSE的に適宜部分的に参照して解決する形をとります。そしてファイルを更新すると更新したファイルだけを自動的にそのワークスペースのファイルとして保存するので、個々のワークスペースが消費するストレージコストはごく僅かで済みますし、別のマシンから同じクライアントをマウントすれば自分の更新の続きが読み書きできます。コミットされていないコードが常にクラウド側に保存されるので、そのコードが自動テストを通るかなどのチェックはローカルのマシンの力に頼らなくても実施できますし、パッチを作る時もそこから生成されてスムーズです。 隣のチームのコードも基本的に常に見えているので、原理的には依存関係で大変なことになりそうですが、ビルドターゲットごとにvisibiiltyを指定する事で外部からコードが依存できる範囲を絞れます。これによって公開API以外のコードをincludeされる事はないですし、公開しているファイルを更新してそれに依存する他チームのビルドが壊れる時などは自動テストによってコミット前に差し止められるのでコミットによって事故が起きるケースは可能な限り減らされています。また、公開APIだけでなくその裏のコードまで読めるので基本的にはチーム間での連携においても挙動の細部について詳しいドキュメントを必要としないという利点もあります。 Hyrumの法則（公開されているAPIは想定外の使われ方をされ尽くすものであり、それが仕様となる）に対するビヨンセルール（外部APIの特定の挙動に依存するならその挙動専用のユニットテストを書いておけ）によって誰かのパッチがコミットされる事で製品が壊れるならばユニットテストが足りなかった側が基本的に悪いという前提があって、モノリポジトリーの上では独自の文化圏が築かれています。この辺りの事はGoogleのソフトウェアエンジニアリングという本に書かれているので興味があったらぜひ読んでください。

熊崎 宏樹:正直僕もgitを最近は個人開発用にしか使っていないので世の中の一般的なプログラマよりはコマンドを知らないですがそこまで非直感的だとも思っていません。これは質問者さんがgitが問題をどう定義して解決しようとしているか脳内モデルができていないだけで、そのモデルがある程度できれば割と直感に沿っていると感じれるようになると思います。 gitはリポジトリを大量のパッチとメタデータのペアの山であると定義して、そこの中のどのメタデータを指しているかのポインタをブランチと呼ぶ、という考え方をしていてローカルとリモートを分けないとLinuxほどのシステムになるとすぐ破綻するという問題を解決しています。 なのでLinusに取っては提供したい価値に対してあの形にならざるを得なくなったというのが正解に近いと思います。それでもcheckoutだけだと分かりにくいからswitchとかrestoreとかコマンドを再度整理したりは随時やっているようなので「今さら変えれない」という類の物ではないはずです。なんならGUIツール経由で使っても良いわけですし。 正直gitのコマンドをドキュメントの隅々まで読んで丸暗記しても日頃の開発では使わないのでChatGPTなりGeminiなりに「今の手元の長いブランチをgithub側の最新版の上に乗せる単一のパッチとして再整理するgit手順として教えて」みたいに適宜聞いて学びながら脳内モデルを組み立てていけば十分だと思います。1人開発なら何もわからなくなったら.gitディレクトリを削除してgit initするなんて荒技をしても誰も困らないので好きなだけリポジトリを壊しながら学んでみるのが良いと思います。僕はこのwebサービスでgitのコマンドに入門しました。 https://learngitbranching.js.org/?locale=ja https://learngitbranching.js.org/?locale=ja 学習曲線は思ったより急峻なので苦手意識さえなくなれば割とすんなり身に付くはずです。

熊崎 宏樹:ほとんど読まないです。そもそも「公式ドキュメントを読みましょう」と色々なところで言われてるのはバイアスがかかってて、みんな読まずにコードを書いてるうちに運悪く痛い目を見て詳細を調べたら公式ドキュメントに書いてあったじゃんと気付いた後にだけその警句を述べるので、逆に公式ドキュメントを読まずに済んでる大半のケースにおいてその警句を発するべきタイミングが発生していないだけです。 新しく買ってきた包丁で料理をする際、その包丁の取り扱い説明書を隅々まで読むでしょうか？よほど特殊な物ならともかく、包丁の使い方なんてどれも大差ないので目すら通さないのが大半です。頭の中で「これはこうやって使う物だ」という脳内モデルが構築されている物は深入りしないのは誰しも同じです。そして何か問題が起きてから原因究明して自分の脳内モデルが不正確であったことを痛感し、その反省の言葉を要約し尽くすと「公式ドキュメントを読みましょう」という言葉に収束するだけです。 包丁の喩えではうっかり屋の素人という感じですが、最先端の研究分野ですらこれに近いような現象は常に起きていて「構築したモデルと現実との不一致を探求する」というのは科学の常です。仮に公式ドキュメントを隅々まで読んだところで誤りのない完璧な脳内モデルが完成するわけでもないので「読んでわかった気になる」→「痛い目を見る」→「脳内モデルの精度を上げる」のサイクルを回し続けることで次第にそのライブラリの細部まで脳内にジワジワ浸透するのを期待します。 なので質問に対する答えは「わかったと感じた所で読むのをやめる。痛い目を見るまで読まない」になります。読んでも読まなくてもそのうち痛い目は見ます。もちろん、わかったと感じれないのであればドキュメントや他人の使い方やテストコードなど読めるものはなんでも読み漁ります。

熊崎 宏樹:C++で初心者がポインタを扱う際の引っ掛かりポイントは * newとdeleteとコンストラクタ・デストラクタの関係 * アロー演算子やそのオーバーロード * constポインタ * 暗黙のthis あたりでしょうか…他にもあった気がしますが何処からが基礎だったかよく思い出せないです。 とりあえずCでも共通なポインタの基礎からおさらいすると int x = 10; // スタック上に置かれるローカル変数x int* x_ptr = &x; // そのxのアドレスをx_ptrという別のローカル変数に代入 int** x_ptr_ptr = &x_ptr; // さらにそのx_ptrのアドレスを別のローカル変数に代入 **x_ptr_ptr += 1; // ダブルポインタを解決した先のxに1を加算 printf("x = %d\n", x); // 11が出る printf("*x_ptr = %d\n", *x_ptr); // これも11が出る printf("**x_ptr_ptr = %d\n", **x_ptr_ptr); // これも11が出る printf("%d\n", *&*&*&*&*&*&*&*&x); // *と&は逆の演算なのでこれも11が出る この7行で何をやってるか追いつかない場合はまずC言語からやり直してくるのが良いです。 typedef struct { int x; .....} hoge_t; // hoge_t型構造体の宣言 hoge_t* hoge = (hoge_t*)malloc(sizeof(hoge_t)); // 動的メモリの確保 hoge->x = 10; // アロー演算子による構造体のフィールドアクセス (*hoge).x = 10; // 1つ上の行と全く同じ意味のコード free(hoge); // 動的確保したメモリの解放 これもC言語でかなり典型的なコードなのでこれがわからないなら何度も手元で動かしたり壊したりして意味を理解してください。そもそもC言語で線形リストや木構造を作って任意の要素を追加削除したりするのは慣れてないと結構泥沼なコードになるのですが、当然それは乗り越えてきた上でC++での質問をしていると仮定してC++の話を続けます。 newとdeleteとコンストラクタ・デストラクタの関係 C++での動的メモリの確保は簡単で、newを呼ぶとメモリ確保とコンストラクタ呼び出しが両方行われ、deleteを呼ぶとデストラクタとメモリ解放が順番に行われる、とまで理解していれば問題ないです。上の例をクラスを使って書き換えるとこんな感じになります。 struct hoge_t { int x; ... }; hoge_t* hoge = new hoge_t(); hoge->x = 10; (*hoge).x = 10; delete hoge; 初期化と解放の見た目が変わっているだけで、コンストラクタとデストラクタを暗黙のうちに呼ぶようになったぐらいの違いしかありません。試しにprintfをコンストラクタとデストラクタで書いて手元で動かしてみてください。余談であり実用コードでは使っては行けませんが、mallocとコンストクタ、deleteとfreeはこうやって分けて書くことも一応できますし、内部でやっている事はおよそこういう事だと理解しても差し支えありません。 void* hoge_ptr = malloc(sizeof(hoge_t)); hoge_t* hoge = new(hoge_ptr) hoge_t(); // ポインタを与えてplacement new hoge->x = 10; hoge->~hoge_t(); // デストラクタを明示的に呼び出し free(hoge_ptr); まぁこの手の話で一番ややこしいのは上の2つのコードは最近のC++ではやっちゃ行けなくて std::unique_ptr<hoge_t> hoge = std::make_unique<hoge_t>(); hoge->x = 10; のようなコードしか許されないという事なのですが、C++の基礎を学ぶ過程においては全部知っておくべき事です。 アロー演算子とそのオーバーロード さてstd::unique_ptrとかいう見慣れない物が出てきましたがこれはポインタを保持しているだけの構造体に過ぎません。なるほどだから構造体のアロー演算子経由でその構造体のフィールドにアクセスできるんだね？とならないあたりから話がややこしくなってきます。 このコード上でhogeはstd::unique_ptr<hoge_t>型の変数ですがこの型はメンバー変数にxを持ち合わせません。そもそもunique_ptr型はhoge型と同じ構造体に過ぎなくてポインタではありません。その内部ではおよそこんな感じになっています。 class unique_ptr { .... hoge_t& operator*() const { return *ptr_; } hoge_t* operator->() const { return ptr_; } private: hoge_t* ptr_; } これはオペレーターオーバーロードと言って「このクラスのインスタンスに対して演算子を使う場合は意味を上書きするためにこの関数を呼んでくれよな」とするC++の賛否分かれる言語機能の一つです。文字列同士の連結が + で直感的にできるようになったりと便利ですが、何がいつ呼ばれているのか見つけにくくなるので賛否が別れています。 これによって*hogeとかhoge->が呼ばれた時に適宜内部で持っている構造体のフィールドに参照が飛ぶように細工がしてあります。なのでC言語で慣れ親しんだ*や->は細工済みである可能性に気をつける必要があります。と言っても*や->で何か悪さをするとコードがとんでもないことになるのでよっぽどの場合このunique_ptrのように「ほとんどポインタだと思って扱えるようにしよう」という方向にすることしかないはずです。 constポインタ プログラムを書いてると思った通りに動いてくれていない事の方が多いと思いますが、その「思った通りに動いてくれない」のほとんどは「変数が書き変わってくれない」と「変数がいつの間にか書き変わっていた」です。その「変数がいつの間にか書き変わっていた」というケースの犯人はポインタの暴発を除くと大体犯人は自分自身なのでコンパイルの段階で拾えるケースがあります。なので「自分はこの変数を書き換える気がないよ」というのをコンパイラに教えるのがconst修飾子の役割です。 const int x = 10; x += 1; // コンパイルエラー error: assignment of read-only variable 'x' x += 1; ~~^~~~ ただしポインタに対するconst修飾に関していうと話が複雑で int x = 10; const int* x_ptr = &x; // int const* x_ptr = &x; も全く同じ意味 x_ptr += 1; // コンパイル通る！ *x_ptr += 1; // コンパイルエラー constをつけた場合はそのポインタの指している先がconst修飾され、ポインタ自体が指す先を変える事はいくらでもできます。ポインタ自体が指す先を変えたくない場合はconstの場所を変える必要があります。 int x = 10; int* const x_ptr = &x; // constの位置が違う x_ptr += 1; // コンパイルエラー error: assignment of read-only variable 'x_ptr' x_ptr += 1; ~~~~~~^~~~ int const * const x_ptr = &x; // 両方にconstつけるとポインタ自身もその先も変更不能になる これはややこしくて参照の&を使う時も同様です。文法的には多段のポインタであればconstの位置はポインタの数だけ増やす事もできてダブル以上のポインタと合わせるとint const ** const * const x; のような物も定義できます。あんまり複雑な物を使う機会がないというかあまりに複雑なものはプロでも扱いきれないのでポインタに慣れないうちはあまり深掘りしなくて大丈夫です。 このconstの良いところは、ただの整数ではなくてオブジェクトのインスタンスに対しても宣言できる所です。 const hoge_t hoge = ...; hoge.FooBar(); // FooBar()関数がconst修飾されていないとコンパイルエラー メンバー関数にもconst修飾がされているかがコンパイル時にチェックされるのでインスタンスの中身を書き換えうる関数かどうかを走らせる前にチェックできます。 class hoge_t { public: void FooBar() const { ... } // const修飾されているメンバー関数の例 void Baz() { ... } // const修飾されていないメンバー関数の例 } 暗黙のthis さてconst修飾されている関数がなぜインスタンスの中身を書き換えないと言えるのか、それはクラスのメンバー関数がメンバー変数に触る際にthis->が暗黙のうちに補完されるが、const修飾子の付いた関数ではconst修飾されたthis->が補完されるからです。 void hoge_t::FooBar() const { x += 1; // this->x += 1; と解釈され、thisがconst hoge_t*型なのでコンパイルエラー } void hoge_t::Baz() { x += 2; // this->x += 2; と解釈され、thisはhoge_t*なのでコンパイルは通る } メンバー変数が全てconst保護されるのがconst修飾付き関数という理解で良いです。(mutableを使うと例外的にメンバー単位でconst修飾を外せるけど話がややこしくなるので必要になるまで忘れててください） そうやってconstを付けるとコード中のさまざまな箇所にconstが伝搬していって、バグった時の被疑箇所を大幅に減らす事ができます。 C++のクラスでポインタ周りの事を説明してたらconstの話まで脱線(?)しましたが、線形リストをC++で実装しないと行けない事は実用上そんなになくて（lock-free stackのような物を書くならともかく）仮に必要になってもC言語で普通に睨めっこしながら格闘する他ないと思います。そしてドキュメントやLLM片手に3時間ぐらい格闘していればパズルのようにわかるようになりますし、その3時間はあなたのプログラマ人生で屈指の有意義な時間となるであろうことを予言します。C言語でのSEGVとの戦いは割と不毛になりがちなのでvalgrindとかgdbとかを適宜調べてから挑むことをお勧めします。

熊崎 宏樹:プログラムの世界は本当に自由で、動くまで直し続ければいずれどんなメチャクチャな書き方をしても動くのがソフトウェアの素晴らしさであり、恐ろしさでもあります。結論からいうと質問者さんの例は純粋にコードの読み書きの物量が足りていないだけですが、せっかく僕に質問してくださったので僕の個人的主張に基づいてお返事したいと思います。 オブジェクト指向が原理上不可欠な処理は存在しない 授業で何を教材にしているかは知らないですが、何かしらの処理を何かしらのオブジェクト指向のテクニックで記述した例が数多く載っている教材だろうと思います。その例のどれ一つをとっても(保守性に目を瞑れば)オブジェクト指向抜きで記述できます。もちろんそのままコード規模を拡大するといずれ保守不能に陥るのでそういう意味では記述できたと呼べるかは怪しくなってきますが…。 「概念がわかっていても(オブジェクト指向の)コードにすることができない」という順序ではなくまず目的とする処理内容をオブジェクト指向関係なく書き下してみる事をお勧めします。それができないのであればオブジェクト指向以前の問題につまづいています。 オブジェクト指向はただの整理術である 初心者がオブジェクト指向を無視して力技で書いたコードは、おそらく1週間も目を離していれば自分自身にとってすら保守しきれない代物になっているはずです。そうでないならおそらく問題が簡単過ぎます。保守できるコードというのは読む際に頭に入れておかないといけない知識量が頭に収まるコードです。 プログラミングの世界でも「三回作り直すと一番いい設計になる」という格言があります。個々の部品が何を目的としたものなのかを整理整頓しなおす事で明快かつ頑健な構造を実現する事が可能になります。ただし整理ばかりが正義でもありません、家の中だって整頓されているに越したことはありませんがそのために部屋の間取りをひたすら細かく区切ったり目的もなく棚を増やしても生活しやすいとは限りません。 先ほどオブジェクト指向関係なく書き下したコードをどう整理すべきかでオブジェクト指向を学ぶ、という順序で実践的に学ぶことをお勧めします。 再利用性は設計の良さの指標 プログラミングに慣れれば同一の処理にも様々な書き方ができることがわかってきます。それらの中でどの書き方が一番優れているかというのは自明ではなく、シニアなプログラマ同士でも意見の対立が起きることは珍しくありません。人によって何を重視するかはそのコードの先に何を見据えているかでも変わりますが、僕個人は「再利用の予定が皆無でも再利用を意識せよ」という意見を持っています。プログラムから任意のコード辺を切り取って別の目的で流用しようとすると、まずそのコードが何を目的とした物か理解した上で、その目的に合致する部分を適切に切り出せる必要がありますし、そのコード辺が変数や関数に依存している場合は依存先もコピーしてくる必要があります。つまり、機能単位で独立したコード辺にして、更にそのコード辺が外部に依存する量を必要最小限に抑える事が再利用性に繋がる事がわかります。 その観点で見るとグローバル変数なんてものは邪魔でしかなく「このコードは何を入力として何を記憶して何を出力するのか」を考え直す必要があります。そこに対する答えとしてオブジェクト指向のいち側面であるカプセル化が大いに役立つ場面もある事でしょう。好き勝手にコードを書き散らす観点においてはあらゆる変数が見えていた方が最短で物事を記述できるのですが(僕が育ったHSPという言語では全てがグローバル変数でした)逆に必要以上に見えないように制限する事でコードの品質を高める事ができるのが設計の世界です。 ちゃんと動く限り見えなければ見えないほど良い オブジェクトの中身が見えないという事はその先に対して責任を負う事ができなくなります。それによって自然と責任を分解するという観点でコードを整理する事を強いられます。例えばあなたが犬を散歩に連れていく場面であれば、首輪に繋がったリードが犬から露出したインタフェースです。あなたが飼い主として散歩でするべき事はリードを引く事であって、その詳細（犬の四肢や心臓や肺をどう動かすか）はすべて犬側の責任として委ねられています。こうして責任を分解することによって、リードさえ伸びていればあなたが犬の肉体の詳細について詳しくなくても散歩が完遂できます。 デジタルの世界は1次元のメモリ空間に0と1が大量に並んでいるだけの無味乾燥な世界なので、あらゆるプログラマはさまざまな物に喩えて物事や責任関係を整理しようとします。オブジェクト指向はその典型例の一つであって、責任の所在を整理するために物事に「あちら側」と「こちら側」を設けようというメタファーの塊であり、犬の散歩であればリードに繋がった犬が「あちら側」です。原理的にはアクセスできるメモリでもプログラム上の制約として隠蔽することによって「あちら側」に対して要求する仮定を減らしてコードの抽象度や再利用性を高めようというオブジェクト指向の思想を体感できれば細かいテクニックは覚えなくてもオブジェクト指向を理解できたと言って差し支えないです。 書き直しはプログラマの基礎トレーニング 一度書き下したコードをオブジェクト指向で書き直してみる、という作業を実際にしてみるとわかるのですが、どういう粒度で整理すると非の打ちどころがないコードになるかという点で様々な選択肢が浮かび結論が定まらない時も出てきます。学校の美術の時間にデッサンをやった時の「ここからどう描き換えても不正解な気がするけど離れて見ると改善の余地しかない」みたいな気持ち悪さでしばらくもがいている時にこそ基礎となる設計力が伸びている気がしています。デザインパターンもその一例として参照するのも良いでしょう。 質問者さんがプログラマとして大成する事を祈っております。

熊崎 宏樹:おぉ…。僕より詳しい人は世の中にたくさんいますが僕が回答しないとこのレターは表に出ないので知っている範囲でお答えします。 > 17や18などでもっと良い結果が出ることを否定できていないのでは？ 仰る通り、16や32が数学的に最良であるという確固たる証拠を持って採用しているケースはみたことがありません。しかしやってみるとわかるのですが16で良い結果が出なかったものが17にしたら突然ものすごくよくなったり18にしたらものすごく悪くなったりする事は経験的にありません。「32にしたら少し良くなったけど増加する計算量やメモリ量に見合わないからやっぱり16にしておきます、16と32の間の任意の数字は大体その中間ぐらいの結果になるはずです」ぐらいのノリでハイパーパラメーターを決めることが大半です。この過程の事を「構築的でない」と評するのは筋が通っていると思います。 > CNN層の後はプーリング層が続く事が多いが、別の層を挟むことでより良い結果が出ることを否定できていないのではは そうですね、こういった構造もおよそ経験に基づいてやってるだけで厳格な証明に基づいて数学的に最良の構造を決定した物は見た事がありません。これは数学的な研究対象の一分野という認識で、そのうち何か興味深い研究成果が出てくるかも知れません。 > モデルAよりもモデルBの方が精度が高いという論文が多いが、全てのパラメータの通りを全探索して比較しないと厳密に証明できないのでは？ 全てのパラメータの通りといっても複数の64bitの浮動小数を全部探索なんてやってたら世界中のスパコンを使っても終わりません。ただ経験則として「最適なパラメータがあるとしたらそこに近い数値はそれなりに良い結果を出すはず」という仮定の元、10倍や100倍区切りで組み合わせ探索（グリッドサーチと呼びます）して良さげな数字を見つけて採用、更にそこからズラしながら探索、みたいなノリでやっています。僕は詳しくないですが「目的関数がどういう形をしているかはブラックボックスであるとして立ち入らないが入力値を変えると出力の良し悪しが変わるので効率的に出力値を良くする入力値を効率よく見つける事」という最適化をやるBO（Blackbox Optimization）と呼ばれる研究分野もあり論文も実装も複数積まれています。ただ、探索空間が凸関数である保証がないのでそうやって見つけた最適パラメータが局所最適に陥ってる可能性は普通にあります。 また、これは機械学習に限らないのですが、提案手法を既存手法と比較する際に本当に比較がフェアなものとなっているかというのは常に論じられるテーマであって「この手法が必ず数学的に優れている」などと厳格に証明している論文は多数派ではないと思います。 少し探して出てきた論文「Fit without fear: remarkable mathematical phenomena of deep learning through the prism of interpolation」には面白い一節がありました。 > The practice of machine learning was compared to “alchemy”, a pre-scientific > pursuit, proceeding by pure practical intuition and lacking firm foundations. > On the other hand, a counter-charge of practical irrelevance, “looking for > lost keys under a lamp post, because that’s where the light is” was leveled > against the mathematical theory of learning. > > 機械学習の実践は、「錬金術」に例えられることがある。錬金術は科学以前の探求であり、純粋に実践的な直感に頼り、しっかりとした理論的基盤を欠いていた。一方で、学習の数学的理論に対しては、「街灯の下で鍵を探すようなものだ。なぜなら、そこだけが明るいからだ」という批判がなされている。これは、実際の問題解決にはあまり役立たないという指摘である。 専門家がこう言っているのであれば、機械学習の先端領域において理論と実践の間に乖離があるのは確かなのだろうと思います。もちろん、この論文のように数学的側面から追いかける流派も存在しますので興味があるのであれば参考文献やこれを引用した論文も漁ってみると良いと思います。例えばカーネル回帰は理論面もよく研究されていて、それとニューラルネットとの比較を論じているニューラルタンジェントカーネル（NTK）周りの議論なんかはChatGPTを問い詰めてみるのに良い題材かと思います。

熊崎 宏樹:いいですね。毎日コードを書くのが特にお勧めですが、普通は毎日書きたい題材なんて持っていないので、AtCoderの過去問を全部埋めるつもりで毎日解いていくのが良いです。AtCoder Problemsというサイトで自分がまだ解いていない問題を一覧できます。ABCのA問題からなら教科書を見ながらでも書けますし、最初の10問ぐらいは他人の正答を書き写して理解するだけでも構いません。 https://kenkoooo.com/atcoder/#/table/ https://kenkoooo.com/atcoder/#/table/ Githubでアカウントを作って、そのアカウントでAtCoder Problemsと連携してUserタブにあるRecommendation問題を順に解くというのを毎日しばらく続けていくのがいいと思います。多分途中から簡単すぎるように感じると思うのですが、いくらでも難しい問題はそのうち出てくるので日課だと思ってこなしてください。考えてわからなければドンドン答えを見ても構いませんが必ず最後には理解してください。 さて、C++を書くならクラスやテンプレートを理解しないと一人前とは言えませんが、AtCoder ABC過去問をどれだけやり込んでもそれらを書かないと解けない問題にぶち当たる事はまずありません。ですのでそれらはEffective C++やC++ポケットリファレンスやC++テンプレートテクニックあたりの本を読んで自分で手を動かしながら学んでください。C++をわざわざ使う場合はシステム周りに触ることが多いのでソケットとかファイルとかネットワークに関連する事を学ぶことになりますがその辺りは大学の教科書を中心にやった方が良いと思います。どんな本を買ったら良いかわからない場合、和訳された技術書は洋書の段階で和訳する価値があると誰かが信じた本ですので現著者が翻訳者と別にいる本は品質が良いです。 手元にC++をコンパイルする環境がない場合はオンラインのコンパイラがおすすめです。 https://wandbox.org/ wandboxは書いたコードをシェアできるので「どう頑張ってもコンパイルが通らないおかしい」という場合なんかにSNSでURLごと共有すれば誰かが助けてくれるかも知れません。 https://godbolt.org/ https://godbolt.org/ このgodboltはC++やRustなどで書いたコードがどんな中間言語や機械語にコンパイルされるかをリアルタイムに表示してくれるオンラインサービスです。よく知らないうちは「こう書いた方が高速な機械語になるって聞いた」みたいな都市伝説に惑わされながらコードを書くような人もいるそうですが、機械語で確認すると大差ないコードが出力されることも珍しくありません。（コンパイラ開発者は常にどうすればコードの意味を変えずに高速化できるかを探し続けているので初学者が実践できるような書き換えは内部化される事も珍しくないです） 何にせよ一番のボトルネックはやる気です。「誰にでもできるキーボードのタイピングを通して誰にでもはできないコードを書き上げる事でメシを食っていくんだ」という覚悟を忘れずにこの業界を楽しんでください。

熊崎 宏樹:それは僕こそが知りたい知識です。 土地勘がないコード群の中に突然投げ込まれて問題を解決せよと言われる状況というのは実は大きいソフトウェア企業では割と日常茶飯事に分類され、みんなどうにか血反吐を吐きながら解決している筈です。もちろん自分の担当するコードから出ずに仕事ができたら楽ですが、世の中そううまくは行きません。 僕が過去にそういう事態に直面した時にどう足掻いたか列挙しますので参考になれば幸いです。 バグの再現環境をまず作る 再現できないバグは、仮に神がかった直感に基づいたコード修正で解決できたとしても、解決に成功した証拠が得られないため修正できたという証明ができません。ビルドに1時間かかろうがタイムリミットが短かろうがデプロイ先でしか走らなかろうがどうにかして再現する状況を作るのが必須です。運良くユニットテストなりE2Eテストなりで再現する仕組みを作れたらその問題は半分解決できたようなものです。しかし現実は厳しく、手作業かつ低確率でしか発生しないようなバグには涙を堪えながら毎回手作業で再現させていたりもします。 作業メモは必ず残す 問題解決までの道筋は常に複数考えられます。結局のところ試みている道筋は何らかの理由で頓挫する事が多いので、何故この道筋を選んでどこまで進んで何故頓挫したのかをメモします。これは自分の思考を整理するためにも後で他の人に助けを求めるためにも有用です。もしくはなぜ不可能なのかを最終的に説明する際の下書きにもなるというか、むしろ不可能であることを客観的に証明するためにやってるんだぐらいの気持ちで作業している方が気が楽です。やっている事の実態は科学的な実験であるので、仮説を立てて検証するサイクルを意図的に回し、自分が何をしているのかを自分自身に説明するよう意識しないとわけのわからない試行錯誤に陥りがちなのが僕の悪い癖です。 コードを容赦なく壊す コードを斜め読みして今回のバグと関係がありそうな箇所を名前で決めつけてコメントアウトします。それでもバグが再現するなら今回行うであろう修正とは関係がないはずなのでその細部の探索は後回しにできます。コードが複雑に絡み合ってると関数呼び出し一つスキップするだけで色んな所に波及してしまうので日頃から自分だけでもそういうコードを書かないよう心がけるばかりです。あと「この箇所を通っているかどうかすら分からない」「何故かこのコードが実行されているがどこから呼び出されたのか追いきれない」なんて事もザラにあるので、クラッシュしてスタックトレースを吐くように細工するのはコードを頭に押し込む手助けにもなります。ありがちなのが「問題箇所と全く関係ないところを被疑箇所にしてしまっていた」パターンなので、自分が常に狙った通りの箇所を観測できているかは疑い続ける必要があります。更にはこれを言ってしまうと力量を疑われると思いますが、わかりきっている事でもログ出力に足してみたり自分の脳内トレースと出力が一致しているかを確認するだけでもだんだんと目の前のコードが自分ごととして考えられるようになってきて心理的な抵抗感が薄れていきます。 なお巨大なコードは余りに巨大でありデバッガをアタッチしたらそのまま固まってしまうので僕はデバッガに頼りません。 ドキュメントに目を通す いやもうこれ最初にやれよと後になって思うのですが、巨大なコードとは得てしてドキュメントも巨大である事が多いのでいきなり頭から全部ドキュメントを読んでいたらそれだけで一生が終わってしまいます。しばらくコードに浸かっていれば問題箇所に関係がありそうな固有名詞がいくつか目星がつくのでそれらで検索をかけて関係がありそうなドキュメントを掻き集めます。特に英語だと「ほげほげ101」とか「Life of ほげほげ」みたいなタイトルのドキュメントはそのドメインでの目的や問題意識を初歩から説明してくれるので特に役に立つことが多いです。 例えばChromiumのコードと格闘しているなら Life of a Pixel なんかは有用なドキュメントと言える筈です。 https://docs.google.com/presentation/d/1boPxbgNrTU0ddsc144rcXayGA_WF53k96imRH8Mp34Y/edit そして、ドキュメントに目を通してからソースコードに戻ってくるとなんと驚くことに相変わらずわけがわかりません。もっと頭が良い人ならドキュメントを見て理解できるのかも知れませんが、僕のように凡庸なプログラマはドキュメントとコードを交互に眺めて氷塊を少しずつ溶かすように実装者の気持ちを理解していく必要があります。この過程は時には週単位での時間を必要とします。 土地勘のある人の発信をよく読む 自分ではとても難しそうに見える事をいとも容易くやっている人たちの脳内には目的のコードに対する自分より精巧な脳内モデルが完成しており、そのモデルに基づいて行われる発言は意識的にも無意識的にも自分とは異なる物になっているはずです。ドキュメントに限らずチャットやブログなどのログにも目を通して、自分との差分に着目しながら何を思いながら該当箇所のコードを書いたかを想像することで現状のコードを理解する助けになることがあります。運良く開発者と会話できるのであれば、どういうつもりでコードと接しているのかを観察する事が時折自分の理解の助けにもなります。と言ってもやはり何がなんだか分からない状態をしばらく続ける事になりますし巨大なコードはどう折りたたんでも巨大なので認知能力の差に絶望するだけの事もままありました。 さて書き並べてみるといよいよもってただ藻掻いているだけですね…。もっと経験の深いソフトウェアエンジニアの方々がどのようにこの問題を解決しているのか、ぜひ広く意見を伺いたいです。

熊崎 宏樹:ML系のインターンで内定が出たなら普通に行けば良いと思います。「MLでの採用」が各社幅があるので僕の想定しているものと違うかも知れませんが、ソフトウェアエンジニアとしての仕事とMLエンジニアとしての仕事は距離が結構近くて両方を行ったり来たりしている人もいます。最終的にML研究者やシステム系ハッカーを目指す段階なら話は変わってくると思いますがキャリアの第一歩としてどちらかを選んだら不可逆という事はありません。 そして専門性はもちろん大事ですがそれ以上にMLエンジニアでもソフトウェアエンジニアでもお金を貰って働くということは報告・連絡・相談がちゃんとできるとか問題の論理的な構造と文脈を理解するとか、共通として必要になるスキルがありますのでそれらを意識して磨いていけばどちらでも通用するエンジニアになれると思います。どの道数年後にはそれらのカテゴライズに大した意味が無くなっていたり新しいカテゴリができていたりするでしょうから。

熊崎 宏樹:すばらしい。完璧な理解です。お察しの通り、C++でのポインタの取り扱いはセンシティブなトピックです。関数のシグネチャに参照がある場合、結局機械語に落ちたときはただのポインタによる値渡しとしてコンパイルされるので原理さえ理解していれば生ポインタを関数シグネチャに使用することを一切禁じても動くコードが書けます。ですのでC++におけるポインタの存在意義は機械語を吐くための実現手段ではなくコンパイル前のコードに意図を残すための手段として再定義されています。 ポインタ渡しは参照渡しと比べて自然にNULLを渡すことができるので、それを利用して必須でない引数であるということを明示する目的で使われる事もあります。しかしそういうケースではstd::optionalで渡す方が「必須でない」という意図を表現するために適切であるという意見もあります。 またポインタで渡されたオブジェクトは関数の内部でdeleteする事が自然にできます。ですので所有権ごと渡すという意図をシグネチャに与えるために敢えてポインタで渡す事もあります。しかしそういうケースではstd::unique_ptrやstd::shared_ptrで渡す方がコードから意図が読み取れるしコンパイラが後始末の行方を見守ってくれるので安全です。 ポインタとして渡された変数はそのポインタを書き換えて別の値を参照するようにコードを書き換える事ができますが、参照は別の参照先を指すように書き換える事はできません。しかしそもそもの話として参照先を差し替えるようなコードは複雑になりやすいのでその目的でシグネチャをポインタにするのは推奨されません（どうしても必要なら int* a = &b; のようにしてローカル変数にポインタを移して書き換える方がわかりやすい）。 寿命が別の手段で管理された所有権のないデータに対する参照情報をクラスのメンバーとして保持して適宜そのオブジェクトを作り直すことなく参照先だけすげ替えたい…みたいなケースぐらいしかポインタをポインタとして利用している状況が思い当たりません。しかもこれすらも適切なクラスでラップするほうが安全でしょう。 ですので、生ポインタ(shared_ptrやunique_ptrでないポインタという意味です)に関しては一切使わないというポリシーも充分ありえます。

熊崎 宏樹:LLMの出力が「情報技術を深く理解していること」に取って代わるような気がまだしてこないというのが僕の感覚です。 文章の繋がりから情報工学を理解しているかのように見せかける事は病的に上手いのが近年のLLMですが、例えば今書いているソフトウェアがどうあるべきかという議題に対してまるで役に立たないからです。ある程度巨大になったコードはモジュール単位で責務が別れており、プログラマは適宜「このコンポーネントはAを食わせるとBを返す責務がある」のような脳内モデルを構築してホワイトボード上でポンチ絵を共有したりデバッグに役立てたりしています。今の所LLMはそういう脳内モデルを構築するのが致命的に下手というかそういう能力がまだ搭載されていない気がします。そのモデルに沿って「ここにデバッグ出力入れたらわかるんじゃないか」とか「その新機能はこっちのコンポーネントに実装するべきでしょ」といった話をしたいのにそのレベルには人間しかついてきてくれません。 こういう常識の欠如を「世界モデル」なんて言葉で今のLLMに足りない機能として説明している人も見かけますがそれに近いかも知れません。 https://note.com/masayamori/n/n34df50d83489 https://note.com/masayamori/n/n34df50d83489 ですのでLLMが来れない部分、つまりソフトウェアやハードウェアの内部をモデル化して抽象的な話をする事について価値を出していけるよう学習内容を考えていくのが良いと思います。 それはそれとしてコードレビューを通過するようなまともなコードというのは大体パターンがあるので（配列全体を回るときは範囲イテレート文を使え、とか）模様のような決まりのあるコードパターンを書くときはLLMが大いに助けになるときはあると思います。「ブロックごとコード補完が来た」という話は今もcopilotでよく見かける話でこういうのは早期から使い慣れておくのがおすすめです。

熊崎 宏樹:僕の過去ツイートの話ですね。 ソフトウェアに限らずパイプライン処理を組むと処理がステップごとに並列化できて、皆さんお使いのCPUのALUの内部では10段以上のハードウェアパイプラインが組まれている事が普通です。 ソフトウェアパイプラインというのは例えばとても計算量が重くデータ並列性の低い処理があってもA→B→C→Dという4ステップに分割できたのなら4コアのCPUでコア1がA担当、コア2がB担当、コア3がC担当、コア4がD担当という形にしてやってくるデータをバケツリレーしながらステップごとに担当を分ける事で定常的にデータがやってくる限り4つのコアの計算力をフルに活用した処理ができるので1コアでやるより4倍のスループットが出るようになります。基本的には段数を増やすほどに並列度は上がるのでスループットの増大も期待できます。 そしてここからが面白いのですが、大抵のケースではそんな簡単にスループットは上がりません。というのもCPUのキャッシュというのは実は直感の数倍速くて、CPU間のデータ通信は直感の数倍遅いからです。ナイーブにソフトウェアパイプラインを実装すると通信のオーバーヘッドが並列化の利得を上回ってしまってトータルでは性能が落ちてしまうということはザラで、どの程度の粒度のパイプラインに分割すると性能が最大化できるかというのはいろんな要素で変動する読みにくいパラメータです。 クラウドが一般的になった現在、クラウドで使える仮想マシンには200Gbpsとか出るすごいNICがつながっています。 https://docs.aws.amazon.com/ec2/latest/instancetypes/hpc.html#hpc_network https://docs.aws.amazon.com/ec2/latest/instancetypes/hpc.html#hpc_network これほどの帯域があればソフトウェアパイプラインを組む際のスイートスポットも変わってくるんだろうなという気持ちで眺めています。

熊崎 宏樹:そ、そんなにこき下ろしているでしょうか…？ プログラミングにおいて教条的に何らかの思想を上から振り下ろす事に対して違和感を持っているだけのつもりで、代わりに何らかの思想を振り回す事が良いとも思っていません。 クリーンアーキテクチャの書籍では「データベースなんかは玄関のドアノブのパーツぐらいの重要度しか無いのでいつでもドアノブを取り替えれるようにだけしておいて本題に集中しろ」みたいな事を書いていたので流石にそれは無茶というか巨大プロジェクトがエアプなのかって感じる事はありました。改めて主張を整理したいと思います。 まずDBとドメインロジックをベッタリさせて書いているか？という問いですがYESです。特にGoogleの場合は「SpannerからMySQLに移行しよう」みたいな話はまず出てこないですし、仮に移行するならそういう独立したプロジェクトとしてチームで取り組む規模の話になることでしょう。またユニットテストでも可能な限り本物に近い環境を使うように努力せよという指針も公開されています。 https://testing.googleblog.com/2024/02/increase-test-fidelity-by-avoiding-mocks.html https://testing.googleblog.com/2024/02/increase-test-fidelity-by-avoiding-mocks.html ドメインロジックがベッタリしていると困るケースとしては他にロジック自体の意味がわかりにくくなるというケースがあります。ただこちらは純粋にコードの抽象度の話であって、不慣れな人がコードを書いたら抽象度の高い業務ロジックとDB実装側の都合から来る個々のコードが入り乱れて読みにくくなるのは「DDDを適用しなかったせい」ではなくて「コードの再利用性が低いせい」です。 オブジェクト指向や他のパラダイムの事を神格化して聖典のように崇める人もいますが、一介のコード書きから見たらそれらすべて「コード整理術」の一部でしかありません。膨れ上がり続けるソースコードと向き合って増加し続ける複雑さをどう整頓するかがすべてです。整頓することの恩恵を部屋の掃除程度にしか思ってない人もいますが、コードが整理されるとバグ修正も機能追加も「ここのモジュールが本来ではこうするべきだったから」という形で責任が分割されるのでプログラミングの難度が大幅に下がるという効能があります。言い換えれば、将来のプログラミングの難度を下げる事ができるのが良い抽象化、そうでないならどんなプラクティスも自己満足です。究極的には例えば通販なら注文ロジックの最上位が「店舗.発注(注文票)」ぐらいになっていれば「これからはこういう条件の注文が来た時は却下したい」等と仕様追加があった時にどこに手を加えるべきか自明になって便利、ぐらいの簡単な話です。 ここにおいてすべての値を値オブジェクトにラッピングするのは例えるなら整頓用の箱を大量に用意する事で部屋が整頓できると信じるようなものであって有害ですらあります。 クリーンとかオニオンとかそれぞれの言葉でロジックを階層化することで複雑さを閉じ込めたと主張する人は多いです。中にはただ単に教典にある形に近くなった事を喜ぶ人もいるかも知れません。僕がプログラミング初心者に何度も強調して伝えているのは「再利用する予定のないロジックでも再利用性を重視したコードを書け」という指針です。レイヤーを分ける事自体は善にも悪にもなりますが、そのレイヤー分けの良し悪しを決めるのは「直交性」です。レイヤーごとに責務が明らかで凝集性が高いコードを…などと説明してもピンと来ない事が多いですが「仮にこの部分だけを別の目的で使いまわすならどんなインタフェースが露出していれば使いやすいか、を考える事が自ずと責務の分割と凝集性を高めてくれます（最後はセンスの問題になりますが…）。再利用性を優先することが直交性を高める為の近道である、というのはプログラミングを始めたばかりの自分にも繰り返し伝えたい直感に反する経験則です。 再利用性を優先した結果、リポジトリパターンと呼べる形にコードが落ち着く事自体はそんなにおかしな話ではありません。アプリロジックという究極的には再利用性皆無の極北からグラデーションのように段階を経てOSやDBのAPIという普遍性の塊までの間をどのように整理区分するかがプログラマに課せられた仕事であって、聖典を振り回すような場所ではないと僕は考えています。 アプリのコードの優れたアーキテクチャには究極的には未来予知が必要になります。例えば「将来的にここに仕様変更が来ると思うので拡張余地を残した」といったドメイン知識の注入が効くケースは大いにあります。ただしそれが当たったからといってそのプラクティスがどこでも通用する物であることは意味しません。重要なのは将来の変更に対して頑健であることで、将来の変更を助ける方法は小難しいテクニックを使う事とは限りません。特に最近始まったばかりのサービスというのはプロダクトマネージャにすらどこに何が起きるかわからないものですから、その内部は煮え滾る溶岩のように柔軟であるべきです。拡張性やエンバグのしにくさ(セキュアコーディングとか言いますよね)よりもコードの書き直しやすさと消しやすさに重点を置いています。拡張性ではない書き直しやすさというのは説明がしにくい指標ですが、およそ消しやすさとほぼ同義です。アプリ側の都合で数千行のコードがまるっと要らなくなることはザラに起きますが、本当にその数千行を消して良いかを判断するパッチを作るとしてその複雑さが低いほど消しやすいコードです。やたらとインタフェースを切って拡張余地を量産する場合、実際に不要だった拡張余地自体を消すのはどこから依存されているかわからなくて追加の数倍の神経を使うので、そうならないように自信を持って消し飛ばしていけるようなコードを心がけて書いています。ある程度サービスの概形が固まってきてから内部を冷え固まらせていく作業は新機能追加やデバッグのタイミングでコードの再利用と称してゴリッと書き換えて行けばよくて、人によってはこれをリファクタリングと呼ぶ人もいるでしょう。 長くなったのでまとめると * あらゆる教条主義は基本的に嫌いだけど最終的に似るのは別に良い * 凝集とか難しい言葉を使うより再利用性を意識する方が直交性に効く * 依存が少なくて消しやすいコードは正義、コードが若い時ほど消しやすさを優先 こんな感じになります。プログラマごとに違う考えがあると思うので他の意見も聞いてみたいですね。

熊崎 宏樹:C++を使うならポインタをいじる必要がある、というのは誤解です。C++はよく出来た言語なので実体と参照さえ混同しなければポインタに悩まされることはありません。競技プログラミングにおいても「ポインタなしでは解けない」という問題に出くわしたことはありません（そもそもほとんどの問題はC++以外の言語でも解けるように設計されているので当然といえば当然ですが）。 さて、ではなぜポインタが必要なのかというと「OSが要求してくるから」です。OSの提供するAPIは大抵の言語から触れますが最後はC言語で書いた抽象化層を経由することが多いです。OSがアプリと対話する手段は意外と限られていて、特にデータをやり取りしようと思うとreadとかwriteといった処理が典型的で、メモリ経由つまりポインタ操作で行うことになります。OSに近いレイヤーをオーバーヘッド無しで書ける事を指向しているC++を敢えて使うのであればポインタ操作に慣れ親んでこそ恩恵を受けられるし、OSに近づく気がなければいくらでもポインタの無い言語を使えばよいと思います。

熊崎 宏樹:出題側からはAIを使っているか頼れる友達と一緒に受けているかもわからない状況で出ている課題でしたら(明示されていない限り)検索でもAIでも友人でも使って提出しても構わないと思います。つまり「ただ解けるかどうか」を見ているわけではありません。 その手の課題は例外なく「この人物は一緒に働いていけそうか」を見極めるために出していますし、正解するかどうかよりも何を考えてその回答を提出したかが本題です。提出後にどう考えてこれを書いたかという面接があるはずですので、そこで「AIに書いてもらったので何もわかりません」と答えたら大きく失望させることになると思います。 自分の頭で問題を理解し、同僚の疑問にも適切に答え、長期安定や運用面での課題にも目配せをして、自信を持って正しい回答として提出するのであればそれが最終的にはAIで出力されたコードであっても出題者は気にしません。 さて、コーディング面接の勉強法という物は思い当たらないですが、Cracking Coding Interview(和訳:世界で闘うプログラミング力を鍛える本) https://www.amazon.co.jp/dp/4839960100は面接する側が何を見ているか舞台裏を書いているのでおすすめです。模擬面接を何度かやってみるのが肌感覚を得る近道ですので、面接官としてのトレーニングをした本職の人に模擬面接を依頼するのがおすすめです。そういうオンラインサービスも探すといくつか出てきます。

熊崎 宏樹:軽く検索するとS3のレイテンシは1桁ミリ秒、帯域はクライアント側のネットワークがボトルネックになるまで(つまり100Gbpsレベル)出るようですね。しかも99.999999999%(11ナイン)の耐久性という数字は生半可な努力で出せる数字ではありません。 なぜそんな高速なストレージがこんなに安いのかというのは一言では「経済の力」となりますがもう少し噛み砕くといくつかの要素があります。 S3はまき餌かも知れない クラウドビジネス各社ではオンプレミスやコロケーションで顧客自身が契約している物理ハードウェアからサービスそのままで自社のクラウド上に引っ越して貰うこと、通称リフトアンドシフトが基本戦略の一つです。その中でデータ置き場を顧客が自社管理しているNASなどからS3に引っ越してもらうのは重要なマイルストーンです。S3に置いて貰ってそこから煮るなり焼くなりしてもらうのはクラウドを使い込んでもらうために重要な起点となりますのでAWSはそのアップロードの敷居を下げるためにSnowballなどのサービスを整備しています。またS3にアップロードしたペタバイトクラスのデータを外に改めて持ち出すのはとても大変なので、AWSにロックインさせる事を目的としてS3は原価以下の価格で提供してもサービス全体では投資が回収できるという目論見でいわゆる逆ザヤをやっているのではないかという説もあります（実際の所どうなっているかは知りません）。とにかくそれぐらいやってもおかしくない戦場がクラウドのオブジェクトストレージです。 帯域は金で買える S3を運用する側が一体何台のコンピュータを使ってサービスを回しているかはまるでわかりません。ですがクラウド事業者の持つデータセンター内データ帯域は市販品とは別のライフサイクルで強化され続けており、EC2で借りれるマシンの中には100Gbpsのネットワーク帯域が出る物もあります。そしてハードディスクなどのストレージデバイスはクラウド事業者は途轍もない規模で買うのでいわゆる電気屋で一般人が買う価格と比べると圧倒的に安くなると言われています。ですので「とにかく大量のデータを保存したいから大量のマシンを調達して横に並べて負荷分散してするぞ！」と覚悟さえ決めればハードウェア的には25ドル/TB/月は実現可能な範囲にあると感じます。もちろんソフトウェアや運用のコストが掛かるのでゼロからクラウド事業を初めた人がお金だけでどうにか解決できるとは思いません。何にせよ、大量調達による仕入れ原価の削減は重要な要素です。そしてサービスのインタフェースとしてはオブジェクトストレージなのでサーバ台数を増加させることによる帯域幅の拡大は比較的自然に行うことができます、いわゆるシャーディングですね。HDDはヘッドシークに10ms程の時間が掛かってしまうのでそこが支配項にならざるを得ません、ですので可能な限り内部では並列化して帯域を稼いでいます。 レイテンシは知恵でしか買えない S3は公開情報によると複数のAZ（例えば同じ地域の別の建物など）に常に複製し終わってから初めてクライアントに完了と返事をする仕組みでその完了レイテンシは10ms前後に有るようです。S3 Express One Zoneというストレージクラスを明示的に選ぶことで一時的な耐久性を少し犠牲にしてレイテンシを1桁ミリ秒へと短縮することができると書いてあるので、その辺りがアルゴリズム的な上限に引っかかる境界なのだと見受けられます。つまり顧客から受け取ったデータを複数のAZに複製し終わるのを待つかどうかで数msの遅延が有るか無いかが変わってくるので最初に書き込み依頼を受けたサーバはローカルに書くかすぐ隣のマシンにも送るか等をして自身が即クラッシュしてもデータが永続化された状況を作り出す事で高い耐久性を実現していると考えられます。 データを複製すると言ってもナイーブな方法では故障に弱いのでちゃんとアルゴリズム的に強く検証したものを使用する必要があり、形式手法を用いて確認を行ったという話などは探すといくらか出てきます。アルゴリズムやサービスのバリエーションなどの側面でもレイテンシを縮める工夫を凝らしているようです。 僕は以下のブログを流し読みしかしていませんが、実態は絶え間ないエンジニアリングの努力の果てにできているサービスであることをしみじみと感じました。 https://highscalability.com/behind-aws-s3s-massive-scale/ https://highscalability.com/behind-aws-s3s-massive-scale/

熊崎 宏樹:例えば「じゃがいもと人参を受け取ってカレーを作って返す関数」というものを例にお話します。 その関数はコードで書くとこんな感じになりますよね。 typedef struct { ... // じゃがいも構造体の中身 } Potato; typedef struct { ... // 人参構造体の中身 } Carrot; Curry CookCurry(Potato p, Carrot c) {...} Cではこの関数は実は問題がある可能性があります、なぜならCでの関数は「値渡し」しかできないからです。つまりこの関数を呼び出すときには、内部的にはこの関数のためだけにPotato構造体とCarrot構造体を複製して渡す事になります。複製にかかるコストは構造体の大きさに比例しますから潜在的にものすごい量のコピーが起きる可能性があります。 ところでJavaではオブジェクトは関数に対して参照渡しされるので、構造体のコピーが起きる事はありません。関数に対して「人参は冷蔵庫の野菜室にあるもの、じゃがいもは足元の箱に入ってるものを使ってね」のように材料の実体ではなく、材料の場所の情報そのものを渡すので材料の複製を行う必要がなくなります。ただしこれは良い事ばかりではなく「シチューに使うつもりで冷蔵庫に入れておいた人参なのに無くなってる！」みたいな行き違いが起きる事もありえます。ですのでImmutableパターンという物で「見るだけにしか使わないなら参照経由、実際に書き換えを行うときには複製する」みたいに迂回することもあります。これが値渡しと参照渡しの違いです。 ところでCでは値渡ししかできないのですが「場所の情報」を表現する方法があって、それをポインタと言います。 Curry CookCurry(Potato* p, Carrot* c) {...} こんな感じで「じゃがいもの在り処と人参の在り処」を渡す関数として定義すれば、その在り処が書かれたメモ自体は値として複製され渡されますが、実体としては参照渡しと同じことが行われます。参照で渡すのですからそこでの注意点はJavaと同様です。

熊崎 宏樹:僕の意見は「役に立たないとは思うが、殊更に役に立たないと主張する人のほうが役に立たない」です。 競技プログラミングと業務の関係は例えるなら100メートル走とサッカーのようなもので、どちらかに優劣があるわけでもなく、どちらかのトップアスリートがもう片方でも必ずしもトップアスリートとは限りません。 サッカーの試合中に瞬発的に短距離走の速度が重要となるシーンもありますが、サッカーの試合結果は足の速さのみでは決まりません。業務でも時々競技的なコードを書く必要に迫られることもありますが、もちろんそれのみでは業務は終わりません。その割合に関しては現場に依存するので一概なことは言えません。 ここで重要なのは「100メートル走がちゃんとできる人間はサッカーも人並みにできる」という事です。100メートル走で一人の競技者としてやっていくには靴をちゃんと履いて左右の足を交互に動かして地面を蹴って狙った方向に前進する必要があります。サッカー選手でこれが必要でないと言う人は一人もいないはずです。競技プログラミングでトッププレーヤーになる必要はありませんが、人並みにやっていくために身につける基本動作は業務でも共通します。 言い換えると「競技プログラミングは業務で役に立たない」と得意げに言っている人で、競技プログラミングの基本動作ができていない人は、まるで自分の足で走れないのに「100メートル走はサッカーの役に立たない」と言っているようなもので両方やっている人からすると滑稽に見えます。 まずは靴紐を結んで自分の足で自在に移動できるようになる事が試合で役立つには必要で、競技プログラミングのために舗装された様々な学びの高速道路はそれを獲得するためにかなりコスパの良い道であると考えています。100メートル10秒を切るまでやり込まなくていいので怪我なくタイム計測ができる程度までやる価値は大いにあります。 競技プログラミングはコードを書く競技ではありますが、書いたコードがいきなり正解である事はほとんどなく、どこでバグが混入したかを素早く見つけて解決する必要があります。これはコード規模に違いこそあれ業務でも重要なスキルであり決してバカにできるものではありません。僕もレッドコーダーと一緒に仕事をしたこともあり、彼は途方もなく巨大かつデバッグ困難なコードベースを相手にしていましたが、その場でも筋道を立てて問題を解決に向かわせる力は確かなものだと感じました。

熊崎 宏樹:基礎を学びましょう。 CPUやOSの仕組み、そしてそれを利用して動くRDBMSはどういう原理なのかを学べば「なぜインデックスを張ると速くなるのか」などは自明に感じられるようになります。 何がわからないのかがわからない場合、経験上では対象物に対する脳内モデルが完成していません。脳内モデルというのは常に完璧でなくても構いません、これまでに学んだ知識と実際の挙動について自分なりに納得の行く説明をつけられるようにすることでモデルの精度を高めていく事ができます。そして眼の前のソフトウェアが自分のモデルから乖離した動きをするたびにそのモデルを修正する、そのサイクルをアマチュアもプロも回し続けています。 脳内モデルといっても大仰なものではなく、例えば自動車を運転していれば「ハンドルを回せば前輪の向きが変わる」とか「走るにはガソリンが必要」とか「アクセルを深く踏むと速くなる」ぐらいの挙動に対して説明がつく程度の解像度でなら誰しもが無意識に脳内に持ち合わせているはずです。自動車の中身を生業にする人でないなら深入りする必要はありませんが、自動車のエンジニアとして生きていくのであればそこから深入りしていく必要があります。 ここでまた僕の好きな本である「禅とオートバイ修理技術」から一節を引用します。 > そもそも彼らがオートバイに乗り始めた動機というのも、新鮮な空気と陽光に満ち溢れた田舎へ出かけてゆくことによって、テクノロジーから逃れることであった。ようやく逃げのびたと思っているそのときに、再びその場でテクノロジーを持ち出されることは、二人にとってひどく意気をくじかれることになるのだ。だからテクノロジーに関する話になると、いつも会話が途切れて、冷たい空気に包まれることになるのだ。（中略）明確には定義し難いが、テクノロジーを生み出すある種の力、いわば非人間的なもの、機械的なもの、生命を持たないもの、目に見えないモンスター、死の力、といったものがその正体であろう。彼らは決して逃れられないと知っていながら、何かそうしたぞっとするようなものから駆け足で逃げているのである。 テクノロジーとの向き合い方ひとつとっても、この二人（ジョンとシルヴィア）のようにテクノロジーの詳細からは逃げ続ける生き方もあります。しかし、ソフトウェアエンジニアとして生きていくのであればテクノロジーという非人間的で機械的な目に見えないモンスターと戦う覚悟を持ち合わせる必要があります。幸いなことにこのモンスターとの戦い方については定石があります。 「どうすれば自分がわからない部分を言語化して自分で解決して理解できるようになるか」という問いに対してですが、わからない部分を言語化する為のフォーマットを持ち合わせてないに過ぎないのではないかと思います。つまり物事がわからない時に「わからない」とだけ言うのではなく例えば「今の私の理解が正しければ○○になるはずなのに、実際のところは△△していて変だ。私の理解のどこからが間違っているのかがわからない」と言い換えるように努力してみてください。そうする事でその「理解」のどこから現実とのズレがあるかを探索するステップに進む事ができます。 ソフトウェア開発中に遭遇する謎挙動のほとんどは経験上使っているライブラリやフレームワークや言語に対する理解の欠如であることが多く、それらを深堀りしていくと遅かれ早かれOSなどの低レイヤーな問題にぶつかります。そこに対してもさらに深堀りを重ねていけるエンジニアこそが質問者様のいう「限界」がより高いエンジニアです。その低レイヤーを学ぶためにはつい最近発売されたBinary Hacks Rebootedが大変おすすめなので是非手にとってみてください。

熊崎 宏樹:ソフトウェアエンジニアの仕事について誤解があるようです。 確かに書けと言われた題材を動くまで持っていく力は大切ですが、それよりもっと大切なのは動いている物を思い通りにする力です。ソフトウェアエンジニアの仕事の9割以上は既に書かれているコードに対して何らかの変更を加える事であって、どこをどう書き換えるべきかという疑問に対して生成AIが具体的かつ正確な答えを返す事は稀です。 敢えて主語を大きくしますが、エンジニアの仕事というのはだいたい「既に何か動いている物があって、それが思い通りではないので何とかしたい」がスタート地点であり、生成AIが得意とする「自然言語で指示が与えられた物をゼロから作る」ではありません。 エンジニアとして働きたい者としては生成AIを敵視するのではなく、エンジニアの仕事の解像度を高め、生成AIが苦手とする分野を理解してうまく付き合っていきましょう。 「禅とオートバイ修理技術」という本から僕が特に気に入っている部分を引用します。 > (3)は、実験と呼ばれる科学的手順であり、ロマン的な人間は、時としてこれを科学そのものであると思い込んでしまう。というのは、科学的な方法のなかで、唯一視覚によって捉えられるものが実験だからである。彼らが見ているものは、数多くの試験管や、妙な形をした器具や、数々の発見を成し遂げるために忙しく動きまわっている人々だけで、その実験を雄大な知的プロセスの一環としては見ていない。だから実験と証明を混同して、それらが同じものだと思ってしまうのだ。五万ドル相当に及ぶフランケンシュタインの実験器具を陳列して、世間をあっと言わせるような科学ショーをやってのけるような人物は、たとえその結果がいかなるものになろうとも、決して科学的な実験行為を行っているとは言えない。だが一方、バッテリーの具合を調べるために、ホーンを鳴らして確かめようとするオートバイの修理工は、正式とは言えないが、実際科学的な実験を行っていると言える。すなわち生じた問題点をもとに、一つの仮説をテストしているのである。「実験は失敗に終わった。期待通りにはいかなかった」というせりふは、テレビドラマに登場する科学者がよく口にする不幸なせりふだが、実はこの不幸の原因は、お粗末な台本作家にあるのだ。予想した結果が得られなかっただけでは、決して実験が失敗したことにはならない。実験が失敗に終わったと言えるのは、さらに、問題となっている仮説が十分にテストされなかったり、また実験によって得られたデータが何ひとつ立証に値しない場合に限られる。 生成AIによってたちどころに何らかの生成物が得られても、それは科学ショーに過ぎません。科学を構成する仮説の立案と検証を繰り返す雄大な知的プロセスの中においては生成AIがサポートできるのは一部に過ぎません。特にプログラミングに限って言うとブライアン・カーニハンによるこんな名言もあります。 > “The most effective debugging tool is still careful thought, coupled with > judiciously placed print statements.” — Brian Kernighan, “Unix for Beginners” > (1979) > > 最も優れたデバッグツールとは依然として注意深い思考と組み合わせて慎重に配置されたprint文である。 ブライアン・カーニハン, "初心者のためのUnix" > (1979) この本は古いですが依然としてソフトウェアエンジニアリングにおける重要なポイントを示唆しています。眼の前のプログラムが自分の思った通りに動いてくれない事はプログラマにとっての日常です、そこで何故思った通りに動いてくれないのかを具体的に立証する方法を立案する過程を生成AIは教えてくれません（デバッグに関する一般的な事は教えてくれますが）。たくさん学習させたら帰納的にできるようになるかも知れませんが、それを学習させようにも製品コード自体がそもそも膨大ですし、仮説と被疑箇所に基づいたprint文なんて製品コードには残っていないので学習する為のデータセットを集めるだけでも一苦労です。よって「眼の前のプログラムを望む仕様通りにしてくれる」という生成AIが登場するのはずっと先ですし、仮に仕様通りに動いてもそれを確認するテストやQAの仕事が生成AIに取って代わられるのは更に先の話です。 まとめると、僕の意見は「科学的手法(仮説立案・実験・考察)を身につければ少なくともしばらくは生成AIにとって代わられない仕事ができる」です。

熊崎 宏樹:そもそもインターンが目標というのが少し立ち止まって考えて欲しい所です。ここで僕の好きな記事を一つ紹介します。Joel on Softwareという有名なブログの「Finding Great Developers」です。英文に抵抗があるならページごと機械翻訳に投げ込んでも構いませんが、僕の文脈でピックアップして伝えたい部分だけ掻い摘んで伝えます、僕によるバイアスを含むので興味を持ったら是非原文も読んでください。面白くておすすめです。 * 世の中には「優秀」「無能」の2種類の人材がいて転職市場に出回っている人材のほとんどは後者 * 何故なら前者は重用されて出回らないからその人の生涯で4度程度しか転職市場に現れない * 転職市場は期待できない人間ばかりだが、優秀な人材は学生の中には社会と同程度には居るはずなので学生の中で探すほうが優秀な人材と巡り会える期待値が高い。それを市場に出てくる前に捕まえるのがインターン * ソフトウェアの世界での優秀さはその気になれば学生のうちの数年でも育つが、全く育てていない人が多すぎるので仕事の中での成長よりも才能で採る方が良い * つまり青田買いと相性が良い * インターンの中で真剣な仕事を与えて働きぶりをみれば面接よりも高い解像度で採るべき人材かどうか見極められる * 優秀であると確信した後でなら新卒より高い待遇でオファーをしても割にあう * なぜならそもそも新卒の普通の給料は人材が無能だった場合の保険を乗せて額面が削られているから これは米国の話ですが大筋では日本の労働市場でも通用します。インターンとは慈善事業でも子供向け人気集めイベントでもなく、企業がより優秀な人材を高い打率で掘り当てるための真面目な採用サイクルの一部です。「経験者を求めているインターン」というのは錯覚で、学生の中で有望そうな人をスクリーニングした結果、複数社の結論がたまたま一致したに過ぎないのではないかと思います。 さて「インターン獲得」という観点の話ですが、新卒市場に出回るような学生の履歴書は基本的には学歴+α程度しか載っていないものですから、それを見た時に人事部の社員が「この学生は高い解像度で比較してみても良いかも知れない」と思えるような学生という観点で考えるとそんなに難しい話ではありません。 * 関連の深い学科で高いGPAを獲得する * 努力で超えられない才能を持っている事をアピールする * 独学で調べて何かを作って発表していると良い、自主的に何かクールなことをやっている人間はコンピュータの才能があるかも知れない * 「やる気だけは誰にも負けません」という口先だけなら誰でも言えるのでやる気を客観的に証明できる経歴を残す * そう言えば昔こんな記事を書きました https://qiita.com/kumagi/items/62ec259ea86bdac1db4c https://qiita.com/kumagi/items/62ec259ea86bdac1db4c * ただしこの指標はハックしようとするほどボロが出た時に痛いのでやる気が無いなら無理にやらないこと。ボロが出た話を風のうわさに聞いて書いたのがこの記事です。 https://kumagi.hatenablog.com/entry/career-hack https://kumagi.hatenablog.com/entry/career-hack * ブログやSNSや学会でポジティブな方向に目立つ * その会社が使用している技術の名前で検索した時に上位に出てくると理想的 * 採用担当だって候補者のフルネームやアカウント名で検索ぐらいします 注意点として、入賞歴やその他の華々しい活動は基本的にポジティブに受け取られますが「インターン経験」は学生の直感に反して警戒されます。3日程度の職業体験的なインターンならともかく、まともなインターンシップであれば優秀であると判明した学生はその会社の採用パイプラインに乗せて外に出なくなるようガッチリとホールドされて表に出てこなくなるはずです。それなのに表に出てきていて長期インターンの経歴が複数並んでいる履歴書は、それらの会社の採用パイプラインに乗り損ねた可能性があります。学生観点で見ると有名企業でのインターン歴が並んでいると勲章やトロフィーが並んだ履歴書のように見えるかも知れませんが、採用担当の観点で見ると多ければ多いほど良いと一概に言えるものではありません。ですので僕からできる確実なアドバイスは「学業を頑張りながら目立て」です。 日本の労働市場における「新卒カード」は充分強くてインターンに行かなかった位で絶望するような物ではないので、いっそ夏季休暇を全部趣味の開発に叩き込む方がキャリアに有利に働くかも知れません。 読み返すとありきたりな事しか言って無くてあまり役に立った気がしないので、有志が随時アップデートし続けている「インターン情報が集まる魔法のスプレッドシート」を共有します。既にご存知かも知れませんが。 https://magic-spreadsheets.github.io/ https://magic-spreadsheets.github.io/

熊崎 宏樹:キャリアのために今から学位を獲得すべきか？という質問ですね。短い答えは「ノー」です。なぜならビッグテックは学位を採用条件にしていません。実際の求人をいくつか見てみましょう。ソフトウェアエンジニアリングの求人を適当にピックアップしたのであなたがこの文章を読む頃にも同一の求人がアクティブかはわかりませんが、傾向は変わらないはずです。 ビッグテックの求人例 まずはGoogleはこうなっています。 > 学士号を取得していること（同等の実務経験でも可） 次にAppleは学歴に関する言及すら無くMinimum Qualificationsには > * 2+ years of experience in web application development with an in-depth > understanding of data structures and algorithms. とあります。つまり実務経験ということで他の項目は言語やフレームワークの経験ですね。 次にFacebookことMetaは > * Bachelor's degree in Computer Science, Computer Engineering, relevant > technical field, or equivalent practical experience コンピュータ・サイエンスやコンピュータ・エンジニアリングやそれに関連する技術領域の学士、もしくは同等の実務経験と書いています。実務経験が説明できれば学歴での足切りはありえません。 そしてAmazonはPreferred Qualification (=あると望ましい資格)の所に > * Bachelor's degree in computer science or equivalent とあります。コンピュータ・サイエンスの学士号もしくは同等の学位、と言っているようですがあくまでPreferredなので足切りではなく加点ポイントですね。 Netflixの求人も見てみましたがrequirementに関する言及すらありません。 Microsoftのソフトウェアエンジニアリングは > * Bachelor's Degree in Computer Science or related technical field AND 2+ > years technical engineering experience with coding in languages including, > but not limited to, C, C++, C#, Java, JavaScript, or Python > > * OR equivalent experience. とあって、同等の経験(equivalent experience)があれば学位は無くても良いと明記しています。 書類選考について 実例を並べても「暗黙の条件が別にあるんじゃないの？」と疑うのもわかりますが、僕の知る限り求人票におけるこういった条件は本当に文字通りの解釈をするために用意されています。「ソフトウェア開発の2年の経験」と書いてあれば2年間ソフトウェア開発部署でただ椅子に座っていただけでも一応満たしますし、逆にNext.jsやDockerやクラウド技術をバキバキに使い倒したアプリとかOSとかコンパイラとかDBを1人で作りましたとポートフォリオに並べても実務経験を書いていなければ「実務経験1年同等」とすら解釈されず落とされます。 テック各社、書類選考のレイヤーでは候補者が多すぎるので機械的に該当しない人をminimum requirementsに照らしてその後の選考に進む人を選びます、ここに関しては落ちたらそういうフィードバックが貰えることもあるのでリクルーターに聞いてみると良いです。満たしているのに書類で落ちた場合は運です、学位を持っていても運悪く書類落ちすることはザラです。書類選考に対しては学位よりもリファーラルを受ける方が有効に働くと思います。 そして二次選考は主に（特にソフトウェアエンジニア職は）面接を通して行うのでそこで高評価が出せるかがとても大事です。最終決定の際に複数の候補者の間で決め兼ねた時に何を手がかりに決定するかは会社によっても違うので学歴も見るかも知れませんが、大抵は別のシグナルを用いて決めるはずです。ですのでビッグテックにおいては学歴にこだわるよりは同等の実務経験を積むほうが就職に対して合理的であると思います、学費も掛からないし給料も貰えます。 また、年齢についても各社の求人ページをよく読んでみると気にする必要がないことがわかります。例えば上のGoogleのページだと > また、人種、信条、肌の色、宗教、性別、性的指向、性同一性またはその表現、国籍、障がい、年齢、遺伝情報、従軍経験、配偶者の有無、妊娠またはそれに関連する状態（授乳を含む）、親になる予定、犯罪歴（法的要件に一致する場合）、法律によって保護されるその他の状態にかかわらず、均等な雇用機会を提供すべく尽力しています。 Metaだと > We do not discriminate based upon race, religion, color, national origin, sex > (including pregnancy, childbirth, reproductive health decisions, or related > medical conditions), sexual orientation, gender identity, gender expression, > age, status as a protected veteran, status as an individual with a disability, > genetic information, political views or activity, or other applicable legally > protected characteristics. ほぼ同じような事を書いています。わざわざ書きませんがAmazonもAppleもNetflixもMicrosoftも同様の文言が書いてあります。 なぜこれらを明記しているかと言うと、もし仮に年齢による足切りが暗黙にでも行われていた場合、それはアメリカでは人種差別や性差別と同様に違法だからです、場合によっては性別や年齢入りの履歴書を提出した際にリクルーターから消すよう依頼される事すらあります。ですので「進学したら年齢が高くなり過ぎてしまうのではないか」という懸念も不要なものです。むしろOver Qualified（過剰資格）の方が先に問題になるかも知れません。 ただし、研究職に就くのが目的である場合は論文投稿・発表実績などが加味されるため大学の研究室に所属するのが正攻法になる事もあるかと思います。 コーディング力と面接対策 AtCoder黄というのでアルゴリズム力に関しては特に不安は無いですが、コーディング面接で問われる能力はアルゴリズム力だけではありません。面接は面接でコツが要るので米国では定番の「Cracking the Coding Interview」（邦訳: 世界で闘うプログラミング力を鍛える本 ）を読んでおく事をおすすめします。オンラインで有料で面接練習ができるサービスも幾つもありますし、知り合いの経験者と模擬面接をして練習するのもおすすめです、僕に直接コンタクトをとっても歓迎です。知り合いが運営している「Engineer Guild」も何かの力になれるかと思いますし無料です。暖色コーダーでも落ちる一方で灰色コーダーでもコツさえ掴めば通るのが面接ですので入念に準備することをおすすめします。 どの会社も「仕事ができる人を採りたいが直接それを測れないので面接でアルゴリズム問題を出して近似している」が実態であって、面接では仕事ができる人であることを示す事が大事です。例えば難問に直面した時の理想的な仕草は「ダメ元でセグメント木を取り出して振り回す事(AtCoderでは意外と有効)」ではなくて「何が問題の核心でどんな道具があったら解決できるか自分の考えを整理して説明する事」だったりします。その差を理解するために場数を踏む以上の方法を僕は知りません。 進学の是非 もちろんコンピュータ・サイエンスの基礎から体系立てて学ぶ事自体は有益ですので熱意が持つのならぜひ進学すると良いと思います。ただし入社に向けての準備ではなく、入社後のキャリア形成の一環として会社から補助を受けながら進学するのがおすすめです。多くのビッグテックがそのような社員特典を用意しています。 https://www.levels.fyi/benefits/Tuition-Reimbursement/ もちろん働きながらの学業は忙しくなりますがそれだけの価値はあります。

熊崎 宏樹:アメリカの大学でCS。すごいですね、アメリカでもCSの人気は高まってて競争が激しいと聞いています。 数学を勉強していなくてセンスに自信が無いとの事ですが、大丈夫です。僕も数学は実はからっきしで、高校で3Cまで習いはしたのですが合成関数の積分あたりからテストでまともな点が取れなくなりました。大学の微積やら線形代数の授業なんかも参考書の付け焼き刃で乗り切ったに過ぎず、どこまで身についているか怪しいものです。 GAFAMで活躍している人にセンスがある、というのは正しいかも知れませんが、働いている全員にセンスがあるとは限りません。少なくとも僕自身は日々コードを書きながらセンスの無さに打ちひしがれているからです。何かすごいフレームワークとライブラリで動いているのはわかるけれどそのフレームワークの気持ちがまるでわからない、Dependency Injectionされた値がどこで取りこぼされているのか、出力したはずのエラーログが出てこない理由は何か、さっきと同じ手順で投げた同一のクエリの結果がまるで異なるのは何故か、connection refusedというログの裏の理由とは？コンフィグ内の識別子と自動生成された変数とフレームワークの引数が複雑なビルドの向こうで空中合体していることはわかるがそこで起きたコンパイルエラーは何が不満なのか、わからないことだらけの脱出ゲーム状態で試行錯誤しながら日々過ごしています。これは合成関数の積分ができれば理解できるタイプの問題ではなく、フレームワークの仕様や挙動を忍耐強く学んで活用していく事が王道です。これに対して才能がある人というのはおそらくゲームが得意な人なんだろうと思います。僕自身もゲームは人並みに得意なつもりでしたが脳の情報処理能力の限界を日々まざまざと見せつけられるような気持ちです。そうして毎日仕事終わりには「向いてないな…」とか嘆きながら席を立ちます。 さて、才能が無いなら諦めるか、という話に戻すと「才能を理由に諦めるなんてとんでもない」が僕の答えです。僕が持っていると堂々と言えるような才能は「毎日12時間はディスプレイに齧りついていられる視力含む身体的強度」ぐらいのもので、センスとか頭の良さといった観点では常時ついていけなくて悶絶しております。アメリカの大学でCSを学ぶ程に根性があるのであればその時点で僕の学生時代より遥かにアドバンテージを取れています。 微分積分の授業は参考書に齧りついていれば誰でも点が取れるようになりますが、人が後天的に「自分が書いたコードが動いた時に快感を得る」ように鍛錬することはまず無理であり、立派な才能です。「好きな事を仕事にできたら良さそうだし深堀りしてみよう」ぐらいのモチベーションでしばらく没頭し、目安的には10000時間ぐらい使ったあとで改めて考え直しても充分な程にまだまだあなたの人生には時間があります。あなたが就活する頃にはひょっとしたらもうGAFAMではなくもっと魅力的な会社が台頭しているかも知れませんし時代の流れに上手く乗れたらもっと素敵な仕事ができると思います。学んだCSの知識があと50年は無駄になることは無いでしょう。 就活は一期一会ですし現在の情勢でGAFAMに入るには単純な能力ではなくてタイミング良く狙ったポストに空きがあるかのほうが遥かに重大です。僕が入社できたのもひとえにタイミングのお陰でした。時流の流れに積極的に目を向けていきましょう。

熊崎 宏樹:RDBMSが流行った理由はトランザクションのお陰ではありません。何故ならリレーショナルモデル登場前からトランザクションをサポートしたデータベースは複数あったからです。 リレーショナルモデルの提唱者であるEdgar F. Codd氏がその当時勤務していたIBMが売っていた製品がInformation Management System(以下IMS)というデータベースで、階層型データモデルというデータ型でデータを表現していました。これは例えるならファイルシステムのディレクトリ構造とファイルのようなもので、同一の物を複数の階層から参照することすらままなりませんでした(その欠点を改善したネットワーク型モデルというのもあります)。また、データにアクセスする際にはそのデータのフルパスに相当する情報をプログラマが管理した上でアクセス手順をプログラムする必要がありました、そうやってアクセス手順を案内する必要があるという点でナビゲーショナルデータベースシステムという呼び方をされることもあります。 データベースのリカバリ戦略を特徴付ける4つの観点「複数ページの更新を一括で行えるか(≒シャドーページング等の有無)」「トランザクション実行途中のDirtyなページのディスク書き戻しを許すか」「コミット時に全ページの書き込みを強いるか」「チェックポイント戦略」において分類木を作ると左端に『ページはその場で更新・Stealあり・Forceする・コミット時に全部ディスクに強制的に書き出すから明示的なチェックポイントは要らないよね(=Transaction Oriented Chcekcpoint)戦略』IMSが分類されています。またIMS Fast Path (FP)は「ページはその場で更新・Stealなし・Forceしない・チェックポイントを取ると決めたら新規トランザクションを全部止めて今居るトランザクション全部終わるのを待って全ページFlushしたら良いよね(Transaction Consistent Checkpoint)戦略」で現在で言うIn-Memoryデータベースの源流と呼べる場所にいます。 右から3つ目の『複数ページ一括更新する・Stealあり・Forceなし・書き込みが無いタイミングで全ページFlushしたらリカバリが速い(Action Consistent Checkpoint)戦略』のところにSystem Rが居て、これはシャドーページングを使っている事でも有名なRDBMSです。 RDBMSのリレーショナルデータモデルがCodd氏から提唱されたのが1969年(論文が外に出たのは1970年)とされている中で1960年代からIMSを始めとして多くのシステムがトランザクションの永続化と一貫性について試行と改善を繰り返して来ていました。RDBMSのトランザクションの仕組みは既存の研究の一種に組み入れて論じることができる程度には一般的なものとなっていたと言えます。 さて「なぜRDBMSが主流になったか」という当初の疑問に対してよく言われているのは「OptimizerとIndexの進化」です。最初期の頃のRDBMSは研究もそこまで進んでおらず、速度面で大きなビハインドがあったためナビゲーショナルデータベースシステムの地位を脅かす物だとは思われて居なかったのですが、関係代数を基盤にした様々な最適化やインデックスによるアクセス高速化によって、手作業で職人芸めいたアクセス高速化をしなくてはならなかったナビゲーショナルデータベースシステムよりも市場に受け入れられ、最終的にナビゲーショナルデータベースシステムの最大手だったIBMがRDBMSに本腰を入れ始めたあたりから市場の大勢が固まったと認識しています。開発にかかる経済コストはこの話題における重要な要素です。 リレーション(いわゆるテーブル)の形でデータを保持すると直感的だから受け入れられたというのもそれなりに説得力があると思いますが、それでも外部キーによってテーブル間の連結関係を表現する際に整数を用いているのは印象的です。「データ独立を実現したことにより変更容易性が高くなり生産性が上がった」という点で思い出したのですが、誰かが「キーが整数ならバイナリの塊からでも人力でデータが復旧できる」という仮説を提唱しているのを聞いたことがあります。外部キーとは他のテーブルの特定の行に対する参照なのだから原理的にはポインタとかオフセット値とかもっと物理的な情報をkeyとしたほうが間接参照の回数が減るので高速化するのは確実なのですが、それをやってしまうと物理的な故障が起きた際にデータをダンプして目視で復旧する際の難度が跳ね上がってしまうので敢えて整数値による間接参照によってそのレイヤーでの柔軟性を保持することでシステム更新時のコストを抑えているという仮説です。歴史に埋もれているだけで実はハードディスクの更新などを契機に壊れてしまい復旧に多大なコストを払うことになったシステムもあったのではないかと想像しています。

熊崎 宏樹:ペアプロ・モブプロは楽しいですね。特に慣れないコードベースや言語やエディタでの習慣や作法についてコードそのものからはわからない情報が得られる点に最大の利得があると感じています。 しかしコードを属人化させないという観点ではレビューを徹底する事でも解消できますし、設計の議論を深めたいのであれば共有でオンラインなドキュメント上でコメントを応酬しながらやりあったほうが最後に記録が残り第三者が見返す事もできます、更には物理的に近い場所にいる必要もなくタイムゾーンが合わない人とすら時間的な拘束なく協力ができるので結構な利点があります。 逆に言うとペア・モブプロは記録が残らない上に時間的な拘束が発生するので最強とまでは言えないのではないかと思います。プログラマ同士で実力差がある場合のキャッチアップには便利ですが、全員それなりにシニアならそれぞれ別のコードとドキュメントを書いて他人がレビューする体制を回す方が全体としてのスループットは高いと感じます。

熊崎 宏樹:普通のプログラマとしての素直な感覚ではむしろその「奔放な変数宣言」の方が良いです。 コードを読む時は未知の識別子が出てくるたびに認知負荷が高まっていく訳ですからグローバル変数を始めとして内部から参照できる変数は少ないに越したことはありません。関数が1画面に収まるサイズならスコープの開始位置という決まった場所にあれば変数の宣言もすぐに確認できるというのは一理ありますがシリアスなコードを書いていれば1画面に収まらない関数というのはザラに出てきます。 特にC++のようにオブジェクトの生成自体に意味を持たせる事がある言語（例えばscoped_lockなど）においては宣言と生成を分ける方がアンチパターンでありRAII(Resource Acquisition Is Initialization)という言葉にも現れています。C99を策定する頃はJavaなども台頭してきておりそれらの良い所を適宜取り入れていくノリでスコープの先頭以外での宣言も許されたのだと思います。forループのカウンタのiなんかはループの外で触ってしまったら事故の元ですし、ループ外で触ったらコンパイルエラーで教えて欲しいです。スコープを細かく区切れるようにしてそこでの変数宣言は上に寄せたほうが良いというのは確かにそうだと思いますが、宣言が初期化を兼ねている方が読みやすいコードである以上は宣言位置をブロックの先頭に限定しないほうが柔軟な活用ができます。 そもそもがC89においてスコープの先頭でしか変数を宣言できなくしていたのは、その関数が使用するスタックのフレームサイズを早期に確定したいとかコンパイル中の識別子テーブルの実装を簡単にしたいといった実装依存の理由が強く、書かれるコードの品質の側面では特にメリットはありませんでした。 一方で「奔放な変数宣言」を許すと画面内のコードの塊の中で依存関係が完結しているケースにおいて読みやすくなりますしコピペしたらそのまま動くことも多いです。コードのコピペと言うと急に素人のやっつけ仕事っぽい印象がありますが、プロだって必要に応じてどんどんコピペを活用します。コード片のモジュール性が高い事の恩恵というのは日頃からデカいコードの上で仕事をしている人のほうが有り難みを感じるのではないかと思います。

熊崎 宏樹:和訳されているC++本はだいたいどれも大きなハズレではないのですが、僕がC++を学んだ時は定評のあるEffective C++から入りました。基本的な言語機能は適宜検索すればわかるので、どういうコードを書くべきでないかという観点から入れたのは自信を持ってコードを読み書きするには良いスタート地点でした。 https://www.amazon.co.jp/dp/4621066099 https://www.amazon.co.jp/dp/4621066099 Effective C++の中には今（C++11以降）となっては必ずしも通用しないベストプラクティス（使える場所ではconstにしよう、など）もあるのですが、なぜ過去は推奨されておりなぜ現在は推奨されていないかを把握したほうがより良いコードが書けるので古典から入るのはおすすめです。特にJVMもV8もBlinkもC++11以前から続いているプロジェクトなので古いベストプラクティスを学ぶ事はそれらの理解の助けになります。 この原著者のスコット メイヤーズ氏の著作はどれもとても良くて、C++11/14以降でアップデートされた本（Effective Modern C++）も書いています。こちらもとても評判が良いようです。 https://www.amazon.co.jp/dp/4873117364/ https://www.amazon.co.jp/dp/4873117364/ Exceptional C++はC++で例外を使うのがいかに難しいかを本一冊かけて滔々と説いています。C++は言語レベルでガベージコレクションを持たない言語ですが、そこの上では例外を使うといかに発見が困難なバグを埋め込むかという事をこれでもかというほど書いています。人によってはこれを絶対読むべき本として挙げる人もいます。 https://www.amazon.co.jp/dp/4894712709 https://www.amazon.co.jp/dp/4894712709 C++テンプレートテクニックは上記の本ではあまり解説されていないテンプレートの技法をたくさん説明していて良かったです。SFINAEとかType ErasureとかCRTPあたりのテクニックはそれなりに大規模なC++プロジェクトでは常識のように使われているので、自分でゼロから書けなくても「なんか上手いこと行ってこうなるらしい」という事だけわかっていれば読む際にはどうにかなります。 https://www.amazon.co.jp/dp/4797376686 https://www.amazon.co.jp/dp/4797376686 本に限らずともC++を学ぶために有益なリソースはオンラインに無料で転がっていてGoogle C++ Style GuideはGoogle社内でC++を書く際の決まりごとです。ただのルールが列挙されているだけではなく、何のためにこうするのかという目的も逐一簡潔に書いてあるので勉強になります。またV8はGoogle C++ Style Guideに準拠して書かれているはずなので学んでおくと理解の助けになります。有志による日本語訳もありました。オンラインで全部読めます。 https://ttsuki.github.io/styleguide/cppguide.ja.html https://ttsuki.github.io/styleguide/cppguide.ja.html 最近僕が読んでいる物でいうとC++ソフトウェア設計という本がかなり良いです。デザインパターンというものがいかに誤解されているか、そしてC++20時代に於いてなお重要なパターンとその効用に絞って説明している稀有な本です。特に良いのが、パターンや言語仕様の説明のようなテクニカルな要素ではなく、大規模コードとその拡張可能な設計に焦点を当てる事を意識した本であるという点であり、これは血の通った知見であると感じています。SOLID原則について良くある誤解を例を挙げながら解説し、一つのデザインパターンでも実装上の選択肢があり、逆にほぼ同じコード構造でもプログラマの意図によって別のデザインパターンたりうる事を説明しています。駆け出しのプログラマがデザインパターンを使いこなすのは至難の技ですが、質問者様が挙げられているプロジェクトはそれらを使っているので読む際に何を意図したコードなのかを把握する手助けになります。 https://www.oreilly.co.jp/books/9784814400454/ https://www.oreilly.co.jp/books/9784814400454/ C++にはRAIIとかRTTIとか略語が大量にあって僕も未だに知らないものがいっぱいあってこれを眺めているだけで面白いなぁと感じています。 https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/ https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/

熊崎 宏樹:まずログ構造化ストレージというのはアルゴリズムの一種であって特定のハードウェアやデバイスの事を指しません。また、ログ構造化というテクニックに関して言うとSSDの内部でフラッシュメモリのコントローラが利用するケースやブロックデバイスが使うケース（e.g. Log-Structured Block Device）やファイルシステムが使うケース（e.g. RFS）やデータベースライブラリが使うケース（e.g. LevelDB）など様々あります。 永続性と応答速度を両立しようと思った時に一旦書ける場所（ログ）に書いてしまって完了を報告し、後で正しい場所に書き直そうという戦略はジャーナリングなどとも呼ばれ、様々なレイヤーで古くから活用されてきました。しかしそれだと最低でもWrite Amplifier（論理書き込み1回に対して物理書き込みが何回起きるかという倍率）が常に2を超えてしまってスループットが犠牲になります。なのであわよくばログに書いたまま書き移す事なくメタデータを工夫して参照の際にうまく取り回す事（構造化）でどうにか性能のバランスを取ろうというのがログ構造化ストレージの基本思想です。 しかし前述したようにあらゆるレイヤーで似たような事を多重に行うのはあからさまに無駄が多いのでそれを解決するためにはアプリケーションからデバイスまでで一貫した戦略をとったら良いんじゃないか等と研究（e.g. Don’t stack your Log on my Log）されており目が離せない分野です。例えば必ずSSD上でしか動かさない前提のシステムであればファイルシステムやアプリのレイヤーで書き込みをシーケンシャルにするよう拘る意義が薄れますし、DBアプリから見たストレージシステムの方で書いたデータがフラッシュメモリに書かれるまでを垂直統合して最適化したら良いんじゃないかなんて過激な研究もあります。 https://dl.acm.org/doi/10.1145/3514221.3526188 https://dl.acm.org/doi/10.1145/3514221.3526188 さてストレージのヘッドの話に興味があるようなのでHDDの話をしたいのだと思います。複数のプラッタを持つHDDはプラッタの枚数に比例して読み書きヘッドが増えるので「読み書きヘッドが複数ある」とは言えますがそれらは独立して動くことはないのでスループットには関係ありません。 HDD上のLSM-Treeの上で読み込みが発生して問題ないかというと、もちろん悪影響があります。ちなみに書き込み命令と読み出し命令が複数個キューに積まれた時、それをどの順序で最終的に実行するかは下のレイヤーでうまくディスクヘッドのシーク量が少なくなるよう並べ替えて実行されます。なので最終的に読み書きがどういう順序で実行されるかに付いてはアプリのレイヤーからは制御しきれません。 https://en.wikipedia.org/wiki/Native_Command_Queuing https://en.wikipedia.org/wiki/Native_Command_Queuing シーケンシャルな領域への書き込み命令自体が連続している場合はヘッドの移動は最小になるためもちろん最良の性能が出ますし、readが入るとヘッドシークに約10msかかるので書き込みのスループットにも悪影響は出ます。と言ってもLSM-Treeの書き込みのスループットは最良ケースであってもマージ操作の際にガタ落ちするのでReadによる外乱はそこまで致命的ではないと思っています。SSD等であればなおさら影響は減ります。 LSM-TreeのReadに関してはメモリを使ってキャッシュするのが基本戦略です。メモリ内の問い合わせによってヘッドシークの回数を減らせば減らすほど良いのでBloom Filterを用いて不在判定を高速に行うのが定番です。LSM-Treeの各レベルごとにBloom Filterを取り付けておき、不在判定に失敗した場合はそのレベル内のペイロードの実スキャンを行うのですが低レベルでの不在判定ミスは高レベルでの不在判定ミスよりペナルティが大きいので低レベルのBloom Filterサイズに傾斜をつけて大きめの容量を振っておけば全体としてスループットが上がるというMonkeyなんかは面白かったです。 http://daslab.seas.harvard.edu/monkey/ 他にも、キャッシュする際にはkeyに対するvalueのポイントクエリの結果をLRUキャッシュなどに入れておいてもレンジスキャンの際にそのキャッシュ内容をうまく活かせれないのでレンジスキャン用キャッシュとポイントクエリ用キャッシュを適応的にバランスさせながらキャッシュメモリの有効活用を試みるAC-Keyなんて研究もあります。 https://www.usenix.org/conference/atc20/presentation/wu-fenggang https://www.usenix.org/conference/atc20/presentation/wu-fenggang 何にせよメモリを使えば使うほどRead性能が上がるという点で難しいトレードオフがあります。LSM-Treeに興味があるのであれば僕のブログ記事もあなたの知的好奇心をくすぐるかも知れません。 https://kumagi.hatenablog.com/entry/end-of-freezing-lsm-tree https://kumagi.hatenablog.com/entry/end-of-freezing-lsm-tree 以上参考になりましたら幸いです。

熊崎 宏樹:できます。 むしろ「データ指向アプリケーションデザイン」ではそういった方向性を推奨しています。Redoログだけ何らかの手段で強固に永続化されていれば、そのログの永続完了を分水嶺にして個別のトランザクションのロールバック・ロールフォワードを決定できるようになり、分散DB全体の原子性を実現する事ができます。 MicrosoftのSocratesはこの方向で詳しく書いているので参考になると思います。 https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf システム図を引用すると以下です。 このXLOG SERVICEと書いてあるブロックの部分でログを永続化し、ページサーバーで必要なログを分配してページ情報をXStoreに置いています。このXLOG ServiceのLanding Zoneは3多重で複製を作り続けるAzure Premium Storage serviceを利用していると論文中で明記しています。Raftが実現するReplicated State Machineはまさにこの点でぴったりマッチします。このようにRaftで複製して永続性を保証したログはリカバリに利用できます。 ただし、リカバリという観点では正しくACIDを実現したページがアプリケーションから見える事が大切であり、そのためにはログのRedoやUndoを適切に実装する必要があります。これはRaftで自明に解決できる話ではありません、部品として使うことはできても完全な答えにはなりません。 少し衒学的になりますと、多くの人はWALという言葉を使っていますがWrite-Ahead-Logが「何が何に対してAheadしているのか」という事を説明できる人は意外と少ないという肌感覚があります。正解は「ログの永続化がページの永続化よりも必ず先行する」という意味であり、ログの永続化完了までページのpinを*必ず*維持するといったせせこましい一貫性保証の細かい実現手段を表現しているのですがただのバイナリログの事をWALと呼ぶ人が多い気がしています。このSocratesの論文ではWALという単語は使われていませんし、上のFigure 2から見てもわかるようにPrimary側のページは永続ストレージに向かって直接保存される事はありません。つまり「ページの永続化」という操作自体は存在しなくて、単に永続化されたログから一方通行でページのイメージを練り上げるという操作を行っているので先行するも何もなく、この手のアーキテクチャの分散DBにおいてはWALという言葉を使わないのが適切です。これはAuroraに関しても同じことが言えます。

熊崎 宏樹:僕の専門領域ではないですがプロの方の回答が出るまでの間、門前の小僧が習わぬ経を読んでみます。 トランジスタを小さくする事はそれ自体が目的ではなく、安く高性能なトランジスタを追い求める過程でとる手段の一つに過ぎません。微細化競争ばかりが槍玉に挙げられますがそれでなくても半導体開発は（光学に限らず）現代の科学の結晶の一つです。 まず大前提として仮に原子一個レベルにまでプロセスが微細化しても一つのチップの上に何億規模でトランジスタを載せる以上はその故障率や歩留まりに関してはトランジスタ一つあたり99.999999%の良品率でも足りません。微細化が終わっても歩留まりとの戦いはほぼ終わらないことでしょう。半導体の製造過程自体を改善して良品率を上げることもあるでしょうし、一部に不良なトラジスタが入っても完全に動くように回路に冗長性を持たせる技術も改善の余地があります。 他に挙げられるのが素材の改善です。もう10年以上前になりますが高誘電率材料によってゲート絶縁膜を厚くすればリーク電流が減るというHigh-Kメタルゲートはintelの45nmプロセスのときには既に量産に入っていたとされています。 https://www.jstage.jst.go.jp/article/oubutsu/76/9/76_1006/_pdf https://www.jstage.jst.go.jp/article/oubutsu/76/9/76_1006/_pdf https://pc.watch.impress.co.jp/docs/2007/1212/iedm03.htm https://pc.watch.impress.co.jp/docs/2007/1212/iedm03.htm 他にも例えばトランジスタの形自体にも工夫の余地があります。 https://ascii.jp/elem/000/000/884/884429/ https://ascii.jp/elem/000/000/884/884429/ これらの研究は終わったという事は無く、業界の人々はより良い素材をより良い形で量産に適した製法で製品化できるよう今も研究を重ねています。 CPUそのもののアーキテクチャも日夜改善が繰り返されており、ほぼ同一個数のトランジスタを使いながらもより高い処理性能を実現する分岐予測とか投機的実行とかSIMDとかやることは山ほどあります。 まとめると、微細化が仮に終わってもトランジスタの性能改善はまだまだ研究余地があるし、トランジスタの有効利用法に関しても大きな研究余地があります。

熊崎 宏樹:前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Failureであり、これはデータベース本体を保存しているストレージがまるごと使えなくなった場合の事ですがそれでもログから復旧できると言っておりログ自体は故障の議論の範疇外です。仮に信頼できる永続ストレージが世の中にあるならそこに全DBデータを保存すれば復旧にまつわるめんどくさい議論の大半がスキップできるのにと思っているDB研究者は多いと思いますが、実情としてはログの永続化は運用レベルで歯を食いしばって実現しているようです。運用レベルでログが信頼できるとしているのでDB開発者はログ以外の部分をアルゴリズムで守るように努めています。 さてログのフォーマットをどういう形にするかというのは広大なデザインスペースがある話題ですが、アクセスしたいと思った該当ログに対しては全探索せずとも見つけられるようにするのが定番です。破損は無いにしてもΘ(N)よりは高速に任意のログを見つけたいものです。ここに関してはPostgreSQLと(僕の理解が正しければ)MySQLが採用している定番の方法があって「ログのオフセット自体をIDとして扱う」という方法です。ログに振られるLSN(Log Sequence Number)は被りが無くて単調増加さえしていれば歯抜けがいくらあっても構わないのでファイルの先頭にあるログはLSN=0だし、その一個後のログは前のログが42バイトあってその直後をスタートとしているのでLSN=42である、といった具合です。これはLSNが与えられた時にそのファイル箇所までシークすれば読めるので圧倒的に高速です。各LogにLog長を埋め込む必要もありません。 奇しくもこの方法はrecordの一部が破損してもそこから後ろのオフセットまでは壊れないという点でも頑健です、もっというと各ログにCRC32のようなチェックサムを埋め込んでおく事でログの破損を検知することができます（そこからどう復旧するつもりかは知りませんが…）。

熊崎 宏樹:これは長年いろんな研究が積まれながら結果としてあんまりパッとしていない分野です。 例えばOracleは自社のDB専用のサーバやチップを作れる会社ですし、更に高速なDBを求める顧客にハードウェアまで垂直統合させたアプライアンスのような製品を用意するのは順当な戦略に思います。SPARC M8というCPUはまさにOracleがDB用に拡張したプロセッサ機能を搭載しています。 https://www.oracle.com/technetwork/jp/server-storage/sun-sparc-enterprise/documentation/t8m8-architecture-wp-20170914-ja.pdf https://www.oracle.com/technetwork/jp/server-storage/sun-sparc-enterprise/documentation/t8m8-architecture-wp-20170914-ja.pdf > SPARC M8 プロセッサには、特定のソフトウェア機能またはプリミティブを高速化するハードウェ > ア・ユニットが組み込まれています。これらオンチップのデータ・アナリティクス・アクセラレータ（DAX）ユニットは、データベース・クエリ処理をオフロードし、リアルタイムでデータ圧縮解凍を実行し、Java > ストリームを加速化します。インメモリ・クエリ・アクセラレーションは、他の プロセッサに比べて最大 7 > 倍の性能を実現します。インライン圧縮解凍機能により、パフォーマンスを低下させることなく、同じメモリ・フットプリントで最大 2 倍の量のデータを保存できます。 > SPARC M8 プロセッサの新しいコアには、Oracle Database での実数処理を高速化する Oracle Number > ユニットも組み込まれています。 非エンジニア向けの資料なので詳細は書いていませんが大まかに雰囲気は掴めます。要するにDBの内部で行われる動作の一部をハードウェア処理にオフロードする方向性のようです。DAXユニットというストリーム処理を行うコプロセッサのような物の他は特定用途のSIMD命令かアドレス自動チェック機構あたりであって、専用プロセッサだからといってあらゆる処理が桁違いに速くなるたぐいの物では無さそうです。これに需要があることは否定しませんが、DBMS専用プロセッサをゼロから作るに値する程の恩恵が万人にあるとは思いません。クラウドで安く強いx86系のCPUが使えれば大抵の用途には合致するはずです。 オフロードする、という観点でいうと今どきの大規模なデータベースはストレージとエグゼキュータが別のホストになっていることが定番で、エグゼキュータ側でトランザクション処理を実行する傍らでストレージ側でチェックポイントや永続化や簡単なフィルタ処理の一部などをオフロードされて処理する事が一般的です。DBMS専用プロセッサにその一部がオフロードできるにしても汎用プロセッサの方ができることが多いですし、充分な通信帯域さえあればオフロード先が隣のノードで構わないという戦略が経済的に勝利したと認識しています。 データベースの処理は分析処理のOLAP、トランザクション処理のOLTP、後はストリーミング等の特殊用途の3つがメインとされます。 OLAPに関してハードウェア的なリミットはほぼ無く、基本的にCPUやマシンを並べて並列度を高めれば高めるほど高速化する事が多く、その観点においてボトルネックはタスクをデータの偏りに対処しながら上手く分配するアルゴリズムや実装上の問題の方が大きいです。強いていうとソート・ジョイン・リミットなどの並列化に関してはインターコネクトで工夫をしているようです。従来はMPIが得意としていた集合通信を用いた並列処理ですが大規模なデータを巨大なクラスタの中で合理的に並列化しようと思った際にはネットワークのハードウェアのレベルから手を入れRDMAなどの力を借りて高速化する余地はまだまだあります。 例えば以下の論文はTop-KクエリをMPIを用いて高速化するというものです。 https://arxiv.org/abs/1709.05183 https://arxiv.org/abs/1709.05183 OLTPに関してはワークロードとしてトランザクションが衝突しまくるケースに対する根本的な解決策は見つかっておらずとにかくCPUクロックを上げるしかありません。トランザクションの衝突が問題にならないケースにおいては内部の永続化アルゴリズム自体の方がボトルネックになることが多いようです。ここについては僕のブログ記事での論文紹介もご覧ください。 https://kumagi.hatenablog.com/entry/finding-storage-glitch https://kumagi.hatenablog.com/entry/finding-storage-glitch 永続化アルゴリズムの問題が解決した場合には恐らくディスク帯域がネックになりますが、M.2のSSDをストライピングするなどによって容易に10GB/sec以上の帯域は出せるので不揮発メモリが真に輝く時はディスクの永続化レイテンシが問題になるケースに限られ、そこへの道のりはまだまだ遠かろうという論文もあります。 https://dl.acm.org/doi/10.14778/3603581.3603586 https://dl.acm.org/doi/10.14778/3603581.3603586 ストリーミング処理に関しては僕はほとんどサーベイしていないので有識者の意見を待ちたいところです。

熊崎 宏樹:質問ありがとうございます。いくつか質問の内容がわからない所があったので少し考えていました。 TiDBの記事を読みましたが2PLとは書いておらず2PCとその内部での挙動に関する話でレイヤーが異なるようです。2 Phase Lock (2PL)と2 Phase Commit (2PC)は字面こそ大変良く似ていますが2PLはロックのComposabilityを応用したトランザクションの実現手法である一方で、2PCは故障を度外視したまま設計されたデータ複製に過ぎず、適用する対象も導入する目的もまるで異なるものです。 このTiDBの記事では事前書き込みリクエストを対象ノードすべてに送った後にコミットを改めて対象ノードすべてに送る2フェーズからなるので正しく2PCであるようです。そしてこれはロックの成長相と縮退相の2つから成るという点でも2PLでもあります。そして問題はこれがS2PLであるかどうかです。 > Raftの層である程度の Durability やConsistency を保証しているから2PSで十分 Raft自体にDurabilityを保証する機能はありません。Raft自体がデータを永続化し続けるステートマシンを前提としているからです。2PSというのが何なのかわからないですが2PLだとしても2PCだとしてもRaftだから十分という話にはなりません。 > 実際にはS2PLだが2PLと説明している これはこの文書に限らずとても良くあるパターンです。Strict 2PLと2PLをわざわざ分けて論じる必要がある時は永続性と一貫性に焦点を当てた話をする時であって、2PLと書かれている文章はおよそS2PLの事を指している事が多いです。 > Durability を一部諦めている（考えにくいですが） これは無さそうです。 TiDBの記事を読む限り「事前書き込み」が全部成功した場合に限り次のフェーズに進むそうですし、事前書き込みを永続化していないケースは無いのではないかと思います。S2PLはロックの解除前に永続化を済ませている事が条件なので「事前書き込み」が永続化されているならばこれは広義のS2PLと呼んで差し支えありません。 ここで問題になるのが何をもって「永続化」と呼ぶかという話で、直感的にはディスク書込の事を言うことがほとんどですが、もう少し考え方を拡張すると「システムが想定する範囲の障害があってもデータを失わない事」と言い換える事ができます。そもそもディスクに書き込んでもディスクごと吹き飛んだ（これはシステムが想定していない範囲の障害）ら意味がないですし、これまでは電源断からの復旧に耐えることをもって永続化と呼ぶケースが主でした。 Raftを用いた分散システムにおける「永続化」とはRaftが想定する範囲の障害つまり少数ノードの故障や離脱に耐える事であって必ずしもディスクに書き込むことを想定していない可能性もあります。TiDBはRaftで複製され永続性が保証されたストレージ(TiKV)の上に2PCなどのプロトコルを用いて複数データにまたがる一貫性を実現する構造になっていて、上下で役割を分担しています。そしてこの記事を読む限りは永続性に関してはTiKV側に任せていると取れるので実際の所S2PLに近いことが行われていると思われます。

熊崎 宏樹:技術面接の際にGo言語を選ぶ事はできますので、可能不可能という話だけで言うと可能です。 ただ「Go言語だけがめちゃくちゃ書けるけどC/C++やJavaはできない」という人間をこれまで一度も見たことがありません。もっと言うとコンピュータ・サイエンスの高い素養を持ち合わせながらC/C++もJavaもできないという人もお目にかかった事がありません。そもそも何か一つの事を突き詰めようとすると自ずとその周辺分野もある程度理解する必要があります、なぜなら理解しないと自分の分野にどの程度関わっているかすら切り分けられないからです。周辺分野に一度も興味を向けた事もなく高みに登ったつもりでいたらそれは視野が狭いだけです。Go言語もある程度以上の高みに至るとC言語と完全に無縁ではいられません。 Googleの採用の仕組みはCracking Coding Interviewにも書いてありますが、Hiring Committeeを通過した後に部署とのマッチングがあります。部署によってはJavaしか使わなかったりC++しか使わなかったりする所も珍しくないので、そういう所のマネージャは自然と「Javaが得意な人に来て欲しいな」ぐらいの事は考えます。そうしてマッチング先が一つも現れなかったら「今回はあなたに合うポストがありませんでした」として落ちる事は起こりえます。もちろん運良くGoを使っている部署とマッチングを果たすことも理論上はありうるでしょう。 これはGoogleに限らず言える事ですが、就活する際には「必要とあらば何でも学んでみせる」という覚悟を示すことは常に重要です。ですのでキャリアをGo言語と心中させにいくスタイルを貫くのはあまり賢明ではないと思います。 ここから先は完全に余談なのですが、GoogleはC++用のライブラリのabseilを公開しています。 https://github.com/abseil/abseil-cpp https://github.com/abseil/abseil-cpp これは社内でC++を使い込むうちに常用されている部分を切り出してライブラリ化して公開されたものなのですが、例えばabsl::StatusOr<T>型は「成功時はT型の値、失敗時はエラー詳細を内部に持つ」という直和型でそれを返す関数をいくつも宣言して失敗時にはエラー詳細を早期リターンする、という感じのコードを absl::StatusOr<Foo> out = Bar(hoge); if (!out.ok()) { return out; } こんな風に延々と書いていると、Go言語で out, err := Bar(hoge) if err != nil { return err } と書いている時と書き味は大差ないです（個人の感想です）。Javaを使っても言語の文化としてCOBOLを書くことができるのと同様に、abseilを高度に使い込んだC++コードは文化としてGoを書いているように感じるときが度々あります。そもそもGo言語はGoogle社内でのシステム開発上での問題を解決するために作られた言語ですので、それらに類似点があるのは自然な話でもあります。 他の言語やライブラリも好き嫌いせず学ぶうちにGoの真髄に辿り着く事もあるかと思いますので是非幅広く勉強してみてください。

熊崎 宏樹:ARIESの本質、これは僕も疑問でした。Algorithms for Recovery and Isolation Exploiting Semanticsの頭文字を取ってのARIESですが何がSemanticsをExploitしているのかという点について考えるたびに別の答えが思いつくのでまるでわかりませんでした。 そこで去年、大阪に訪問していたC. Mohan先生（ARIESの著者）に直接聞いてみました。（Mohan先生の右後ろで目を閉じているのが僕です） 少し考えた後に彼は「ページのインクリメンタルな操作の中にすべての動作を畳み込んだ事こそがExploitである」と答えました。僕の理解はこうです。 * DBにおけるページとはただのディスクの断片ではなく、それぞれが独立したステートマシンである * 複数のステートマシンに対する操作（=ログ）に対してLSNという全順序関係を持った横串を刺してトランザクションレベルでの一貫性を設けた * ページごとにそのページに対して最後に操作を行ったログのLSNを記録し、それより小さいLSNのログはいついかなる時も無視する事で片方向の冪等な遷移しか起きない状況をロジカルロギング上でも達成した * リカバリ時においてはLSNの任意の断片の箇所に対して全トランザクションの成否が確定し、そこから続くインクリメンタルなRedoと更にそれに続くUndoの内容が確定する * UndoもCompensation Logを伴ったRedoというインクリメンタルな操作に畳み込んだのでAbort操作とリカバリUndoが共通化された データベースのロギングプロトコルの話を出発点にしてページをステートマシンに見立てる視座の高さに至るのは一種の悟りのようでありますが、ARIES自体はACIDにおけるAとDしか相手にしておらずトランザクションの並行制御についてはロックテーブル等に任せている事などを理解していくにつれてすんなりと理解できる事と思います。これが理解できたら発展形の一つであるInstant Recoveryについても調べてみてください。 ARIES/KVLとかARIES/IMはARIESで一貫性制御を行っている上でSerializableな分離レベルを実現するためのファントム避けのロックの話等をしているのですが個人的にはロックテーブルの側で対処すべきであってその辺の研究の流れはGoetz先生のOrthogonal Key-Value Lockingの研究の中でも説明されています。以下に引用します。 様々な試行錯誤を経た果てに地獄のように大きなロック互換表が出来上がっていますがこれはやむなしでしょうか…。以上参考になりましたら幸いです。

熊崎 宏樹:Pointer Swizzlingについて詳しくない人のために概要を説明しますと、これはメモリに乗り切らないデータの断片をメモリに乗せて処理している際に、データ内での参照関係を表す論理的なポインタをメモリ上でのみ物理的なポインタへと侵襲的に上書きする事で同じくメモリに断片的に乗っている宛先データへのショートカットを提供し高速化するテクニックです。上手くいっている時は速度面では申し分無いのですがディスクに書き戻す際に再び論理ポインタに書き戻す必要があるのと、ポインタを被参照されているすべてを書き戻さないと知らずに物理ポインタにアクセスしてSEGVという事故が起きうるのが難点です。 初期のPointer SwizzlingはMMUなしで仮想メモリっぽいものを実装したり、巨大データを扱うプログラミング中での活用を目的としており、RDBMSへの貢献というよりはOSやプログラミング言語に対するテクニックとして提案されていたようです。特にOSのレイヤーでサポートするならページフォールトをトラップしてメモリを侵襲的に書き換えるなんてかなり夢のようでかっこいい技術です。しかしOSという観点では仮想メモリでやったほうが筋が良いのと、ファイル側を書き換えることさえできてしまえばCPUに任意のメモリアドレスを読みにいかせる攻撃が可能という欠点があり、プログラミング言語でいうとUnswizzlingの管理のために言語レベルのガベージコレクションに頼ったりする必要があったりしてイマイチ広く使われるには至りませんでした。 そこでGoetz先生らが出した2014年に出したIn-memory performance for big dataの論文の中で * Swizzlingは簡単には使えないけどRDBMSのB+treeにおけるブランチノードのポインタに限ってだけ使うとかなり上手くハマるわ * でもB+treeの逆参照を管理する必要があるからただのB+treeじゃダメでFoster B-treeが良いと思う * 複数の逆参照をマルチスレッド対応まで考えて上手く回すのは難しいけどFoster B-treeは全ノードは常に一つしか親を持たないから安全 * 逆参照を上手く取り回すためには物理ポインタはページに直結じゃなくてページ固有メタデータに直結すると上手く行くわ という形で再導入されLeanStoreとかでも採用するに至った、という流れがあると認識しています。

熊崎 宏樹:良いですね。日曜大工でRDBMSを作るのはもっと市民権を獲得しうる趣味だと確信しています。 分散システムを作る際に気をつける事を語ると毎度長くなってしまうのですが、データ指向アプリケーションデザイン、通称イノシシ本に書いてある事をベースラインに説明すると明快であると気づきました。 * レプリケーションされるのはトランザクションログだけで良いです。それ以外の一切のものはトランザクションログから再構成できます * ユーザに完了を報告する際に必ず永続化されるべき情報と、ユーザから読み出しが起きた時に何らかの加工をすべき情報との間に線引きが必要です * 加工をいつどこでやるかは分散DB側の裁量に委ねられています。ログの複製と同時にページへのApplyを行うのがAurora式ですが、ログの永続化と報告だけ先に済ましてしまい、Applyに関しては適宜暇な時に流すのがSocratesとかAlloyDB、という違いがありますがどちらを選んだからといって大きな間違いは無いです。 * 通信プロトコルは枯れてるものならどれを使っても劇的な違いはありません。僕ならgRPCを選びます * 故障直前にメッセージを正しく送れる保証がないので、生き残っている側が定期的に生存報告を送る事で死活確認するしかありません。RaftのプロトコルはAppendLogのRPCの中に生存報告が含まれており無駄が少ないです * RaftであればLeaderからの生存報告が途絶えたと判定するまでのタイムアウト時間を各Candidatesが乱数で決定し、その時間が経過したらLeaderに立候補します。Leaderの生存報告待ちだった他のCandidatesは一番最初に観測した（充分最新の）立候補に投票するので、乱数で決定する事になります。Paxosベースだと実装の幅があるのですがRaftのこの乱数タイムアウト立候補方式の方が引き継ぎが速いという利点があります * インスタンス同士のメンバシップはLeaderがステートマシンの中で管理するべき情報の一部です。つまり参加や離脱に関してはLeaderが認識してそのメンバシップ状態をアプリの情報とは別のレイヤーで共有し続けます。ですのでLeaderと通信できる限りは漏れなく認識できています * CockroachDBの論文の中で報告されていた事によると、障害やノード追加によるメンバシップ変更に伴うリバランス時には障害への耐性が弱まってしまうのでJoint Consensusという方法でメンバシップ変更前後のそれぞれの状態に対するメッセージの通信を独立して行う事で解決したと言っています。曰くシンプルで堅牢なアルゴリズムとの事ですがちょっと説明は難しいです Raftの挙動については英語ですがこのアニメーションの図解が一番わかり易いと思っています。 https://thesecretlivesofdata.com/raft/ https://thesecretlivesofdata.com/raft/ もっと質問がありましたらどんどん聞いてください。

熊崎 宏樹:levels.fyiの情報を見るに中央値での年収199kドル（1ドル151円で約3000万円）というのは日本企業の中では破格と言って良いと思います。Googleと比べても劣らないと言えますが同一の職グレードに至るための難度が各社で当然違うので人によってどちらでより高く評価される事もありえますし比較は難しいです。 https://www.levels.fyi/companies/woven-planet-group/salaries/software-engineer https://www.levels.fyi/companies/woven-planet-group/salaries/software-engineer 友人との噂話を総合すると、環境や待遇は申し分ないがソフトウェアカンパニーとして色んな意味でやるべきことがいっぱいあって人を選ぶかも知れない、という印象があります。と言ってもこんな事を言うとどこの会社もだいたい多かれ少なかれその通りなんですけれど…。