どうもおはようございます、マイクです。
時刻は朝七時を少し回ったところ、七月二十八日、火曜日の朝です。
ここはZennのトレンド記事をゆるっと深掘りしていく「zenncast」。
今日も、Zennで話題になっている記事をまとめてご紹介していきます。
今日はお便りはお休みですので、そのぶんじっくり記事を見ていきましょう。
きょうご紹介する記事は、ぜんぶで五本です。
プログラミング言語の安全性から、スマホだけで作るセカンドブレイン、ステージング環境の運用、UIの思想、複数リポジトリ管理ツールまで、かなり幅広いラインナップになっています。
まず一つ目。
最近、「既存のCとかCプラスプラスのコードを、Rustに全部書き直すべきか？」みたいな議論、よく見かけますよね。
そんななかでこの記事が紹介しているのは、「書き直しじゃなくて、**そのままメモリ安全にする別ルート**」としての Fil-C という仕組みです。
Fil-Cは、clangをベースにした処理系と専用ランタイムを組み合わせたもので、ポイントは「すべてのポインタに、見えないメタ情報をくっつける」という発想になっています。
このメタ情報とガーベジコレクタを組み合わせることで、典型的なメモリ事故、たとえばバッファオーバーフローとか、解放済みメモリの再利用、いわゆるuse-after-freeみたいなやつですね。こういうのを**実行時に必ず検出して、潔くプロセスを止める**、というアプローチになっています。
おもしろいのは、既存のコードを書き換えなくても、Fil-Cでビルドし直すだけで、そういうオーバーフローとか解放済みメモリ利用をきれいに検出できる、という点です。
しかも、libcの内部処理も含めて守れる、というのがかなり強力ですよね。
パフォーマンスに関しては、さすがに素のgccよりは遅くなるんですが、ポインタをあまり使わない処理だとほぼ同じくらいの速度で、ポインタを多用する処理でも、二倍から三倍程度のオーバーヘッドに収まるという測定結果が出ているそうです。
しかも、ガーベジコレクタのおかげで逆に有利になるケースもある、というのは、単純な「全部遅くなる」話じゃないのが興味深いところです。
制約としては、動く環境がリナックスのエックスエイチスィックスフォー、つまり六十四ビット版に限られていたり、リンクするライブラリも含めてすべてFil-Cでビルドしないといけない、という縛りがあります。
でも、そのぶん「依存関係もまるごと安全になる」というメリットがある。
筆者は、「CやCプラスプラスをRustに全部書き直す」っていう発想じゃなくて、「再コンパイルだけで危険なバグをふさぐ」という路線は、巨大な既存資産を抱えている現場にとって、かなり現実的なんじゃないか、と。
こういう仕組みが他の言語にも広がっていく可能性もあるよね、という形でまとめています。
。 。 。 。
続いて二つ目。
こちらはがらっと変わって、「スマホだけで完結するセカンドブレイン環境」の作り方の記事です。
テーマは、AIとの対話履歴とか、プロジェクトのメモを、**Androidスマホ一台で一元管理する**、というもの。
構成としては、Android上で Obsidian、Termux、Ubuntu（prootで動かすものですね）、それからClaude CodeとChatGPTを組み合わせて、ノート管理と開発、AI利用をすべてスマホ上で完結させる、というかなり攻めたセットアップです。
具体的には、まずObsidianのVaultをGitHubみたいなリモートに置いておきます。
そこに、TermuxとUbuntu環境のほうからも、環境変数経由で同じノート群にアクセスできるようにしておく。
ノートの中には `system/` っていうディレクトリを作って、AIの運用ルールとか、ノートの整理ルールみたいな「共通のルール」をまとめておいて、各プロジェクトからはそこを参照する、というスタイルです。
「ルールと知識はここ」「各プロジェクトのメモはこっち」という感じで、スマホの中にちゃんと“頭の中の地図”をつくるイメージですね。
情報の流れも工夫されています。
まず、`inbox` という受け皿に、メモやWeb記事をどんどん放り込んでいきます。
この散らかった `inbox` を、Claudeのスキル `/organize-notes` を使って、必要なときだけ整理・タグ付けしてもらう。
整理されたものは `knowledge` とか `projects` 以下に移動していく、という運用です。
つまり、「とりあえず何でも `inbox` に」「落ち着いたらAIと一緒に整理する」という形で、**AIと人間が協力してノートを育てていく**、という考え方になっています。
ChatGPTからのやりとりは、Obsidian Advanced URIという仕組みを使って、`inbox/chatgpt` に自動で保存。
Web記事は Obsidian Web Clipper を使って、`inbox/clippings` にMarkdownとして取り込む。
なので、どこから来た情報かで、`inbox` の中もざっくり分類されていきます。
さらに、設計書とか細かいタスク管理みたいなものは、各プロジェクトのGitリポジトリ側に置いておいて、一方で、共通の知識とか判断基準、AIとの付き合い方のルールはObsidian側に置く。
こうすることで、「知識」と「成果物」を分けて整理する、という方針になっています。
スマホ一台で、開発・メモ・AI支援まで全部つなげたい人には、かなり参考になりそうな内容でした。
。 。 。 。
三つ目。
ここからはチーム開発と運用の話です。
AIを前提に、開発スピードがどんどん速くなってくると、「ステージング環境一個をみんなで共有してると、もう回らないよね」という問題が出てきます。
ブランチのマージ待ちが発生したり、「ちょっと先に試したいんだけど、今ほかの人が使ってるから触れない」みたいな、環境の取り合いがボトルネックになってしまう。
この記事の著者は、そこに対して、GitHubのプルリクに `on-stg` というラベルを付けたり外したりするだけで、ステージング環境を**セルフサービスで一時的に専有できる仕組み**を作っています。
GitHub ActionsとSlack連携を組み合わせていて、「今誰がいつから使っているか」がタイムラインで見えるようになっているのがポイントです。
設計としては、基本的にはステージング環境は常に `main` ブランチと同期させておきます。
誰も借りていないときは、`main` への変更がそのまま自動デプロイされていく。
でも、あるPRに `on-stg` ラベルが付いた瞬間、そのPR用にステージングを“借りた”ことにして、そのあいだは `main` からの自動デプロイをロックします。
で、ラベルを外して解放するときに、そのあいだに`main`に溜まっていた変更をまとめて反映する、という動きをします。
同時に、`on-stg` ラベルは、常に一件のプルリクにしか付かないように排他制御をしています。
さらに、デプロイジョブはキューを使って先入れ先出し、つまりFIFOで直列に処理することで、「ラベルを付けたタイミングと、実際にデプロイされるタイミングのズレ」をうまく吸収する仕掛けです。
運用ルールも決まっていて、たとえばデータベースのマイグレーションを含むPRは、この仕組みではステージングを借りちゃダメ、というルールを設けています。
そういう「やっていいこと・ダメなこと」をRunbookとしてまとめておいて、AIツールからの操作も視野に入れているそうです。
この記事が伝えているのは、「すごいプレビュー環境を大掛かりに用意しなくても、こういう工夫をすることで、**小規模チームでも高速開発に見合うステージング運用ができる**」というところですね。
実運用寄りのノウハウが詰まっていて、現場で悩んでいる人には刺さりそうな内容でした。
。 。 。 。
四つ目。
ここからは、UIとかUXの設計の、ちょっと思想寄りのお話です。
テーマは、「Simple Made Easy」という考え方をUIやUXに当てはめた**オピニオン記事**になっています。
筆者がまず整理しているのが、「シンプル」と「簡単」は別物だ、という話。
ここでいうシンプルは、「構造がこんがらがっていない状態」。
一方でイージー、簡単さというのは、「慣れていて、楽に使えること」。
この二つは似ているけれど、同じではない、という指摘です。
Easyさだけを優先してしまうと、どうなるか。
一つのUI要素の中に、複数の意味とか機能をどんどん詰め込んでいったり、表示と操作が一体化してしまったり、状態とナビゲーションが編み込まれてしまったりして、**「使いやすいんだけど、中身はぐちゃぐちゃ」なUI**が育っていく、と。
その結果、長期的には変更するのが怖くなって、誰も全体を理解できない、ハードなUIになってしまう、という警告です。
典型例としては、Excelとか、Slackの入力欄、Notionみたいな、多機能で便利だけれども、いろんな概念が一つの画面に詰め込まれているツールが挙げられています。
逆に、vimのように、学習コストは高いけれど、中の構造はシンプルで筋が通っている例も挙げています。
じゃあUI設計ではどうすればいいのか。
筆者が提案しているのは、「一要素一役割」と、「画面を部品とか段階に分けて組み立てる、コンポーズする」という二つを核にした六つの指針です。
たとえば、状態を画面とかURLにきちんと見える形で出すこと。
一度に一つの状態だけを、正直に見せること。
やたらと特殊ケースを増やさないこと。
こういった、「絡まりを増やさないためのルール」をちゃんと意識して守っていこう、という話ですね。
結論としては、UIの複雑さって、自然に勝手に湧いてくるものじゃないよ、と。
設計者が概念を編み込むたびに、そこに複雑さが生まれているんだ、という視点です。
なので、「これは何と何を絡めているんだろう？」と自分に問いかけ続けて、できるだけ分離を選ぶ姿勢が大事だ、と締めくくっています。
UI設計をしている人はもちろん、つい“便利さ”だけを追ってしまいがちなときに、立ち止まって考えるきっかけになりそうな内容でした。
。 。 。 。
そして最後、五つ目。
これは開発者向けの便利ツールの紹介記事です。
複数のGitリポジトリで構成されたプロジェクト全体について、「ある時点で、各リポジトリがどのコミットだったか」を自動で記録して、後からまとめて復元できる、というツールになっています。
使い方の入り口は `mws init` というコマンド。
これを実行すると、各リポジトリに post-commit フックが仕込まれて、コミットのたびに、「今このワークスペース内で、それぞれのリポジトリのHEADがどこを向いているか」を集めて、スナップショットとして保存してくれます。
その履歴は `mws log` とか `mws status` で確認できて、あるスナップショットにまとめて戻したいときは、`mws restore` で一括チェックアウト、という流れです。
このツールの大きな特徴は二つあって、ひとつは、**ワークスペース全体の「ちゃんと動いていた状態」を、一つのIDで管理できる**こと。
複数リポジトリをまたいで、「あのときは全部この組み合わせで動いてたんだけどな」という状態に、コマンド一発で戻れる、というのはかなりありがたいですよね。
もうひとつは、「未コミットの変更が残っている場合には、スナップショットを作らない」という堅牢さです。
必ず、「再現できる状態だけを記録する」というポリシーにしているので、「あとで戻したけど、あのファイルだけ微妙に違うんだよな……」みたいな事故を防げます。
さらに、過去のある状態から、一斉に作業ブランチを切る `work branch` 機能もあって、複数リポジトリをまたいだデバッグとか、大規模な実験的変更をするときにも扱いやすくなっています。
モノリポじゃない環境で、「このときどのリポジトリが何のブランチだったっけ？」って毎回思い出すのが大変、という人には刺さりそうなツールですね。
。 。 。 。
そろそろお別れの時間です。
きょうのzenncastでは、
まず一つ目に、既存のCやCプラスプラスを**書き換えずに**メモリ安全に近づけるFil-Cというアプローチ。
二つ目に、Androidスマホ一台で、ObsidianやTermux、Ubuntu、Claude、ChatGPTを組み合わせてつくる、AI連携のセカンドブレイン環境。
三つ目に、GitHubの`on-stg`ラベルとActions、Slackを使って、小規模チームでもステージング環境をセルフサービスで専有できる仕組み。
四つ目に、「Simple Made Easy」をUIに当てはめて、シンプルとイージーを分けて考えよう、というUI設計のオピニオン。
そして五つ目に、複数リポジトリで構成されたプロジェクト全体の「動いていた状態」を、一つのIDで記録・復元できるmws的なツール。
この五本をご紹介しました。
気になる記事があれば、詳しい内容や元の記事へのリンクは、ショーノートにまとめてありますので、そちらからじっくり読んでみてください。
「zenncast」では、番組の感想や、「こういうテーマの記事を取り上げてほしい」といったリクエストも大歓迎です。
日々の開発で感じているモヤモヤとか、気になっている技術の話などなど、気軽に送ってもらえたら嬉しいです。
というわけで、きょうはこのへんで。
お相手はマイクでした。
また次回お会いしましょう。お楽しみに。