valid,invalid

関心を持てる事柄について

Vibe Coding: The Future of Programming (2025-04-17 Early Release) 読んだ

2025年8月にO'Reillyから出版される『Vibe Coding: The Future of Programming』のEarly Release版として2つの章が公開されていたので読んでみた。

  1. The 70% Problem: AI-Assisted Workflows That Actually Work
  2. Beyond the 70%: Maximizing Human Contribution

learning.oreilly.com

タイトルとは裏腹に"Vibe Coding"の話は少なく、むしろ副題の"The Future of Programming"やこれから AI を活用していくエンジニアに求められるスキルに焦点が当てられているのが興味深かった。実際には"AI-assisted Coding: The Future of Programming"という言葉のほうがタイトルにふさわしいように思うし、そういう期待で読むとよさそう。*1

タイトルにVibe Codingを使ったのはマーケティングのためかもしれないし*2Andrej Karpathy氏が元々提唱したVibe Codingに過剰な期待を持って読みにきた人に説教するみたいな感じかもしれない。

まだ Early Releaseということなので印象に残った点をいくつかピックアップする程度の感想に留める。

70% Problem

繰り返し出てくる"70% Problem" という言葉。これは現代の AI ツールが基本的なコードの約 70%(boilerplate、浅いドメイン、easy bug fix)を生成できる一方で、残りの 30%(エッジケース、アーキテクチャ改良、保守性、深いドメイン)は依然として人間が介入・補完して解決しないといけないという問題。

addyo.substack.com

デモを一発で作れて感動〜!しつつもデプロイなどのラストワンマイルでつまづいたり、機能拡張ができずにスタックしたり、一歩進んで二歩下がることの繰り返しばかり...といった話。まぁそれはあるよねという感じなのだが、本書は「残り 30%のためにエンジニアリングの専門知識が引き続き必要であり、その重要性はむしろますます高まっている」という点を強調している。

In essence, while agentic AI offers powerful tools for software development, it also amplifies the importance of foundational knowledge. To harness these tools effectively and responsibly, users must cultivate a deep understanding of software principles, ensuring they remain in control of the development process rather than becoming passive observers.

Software development is more than writing code, after all – it’s a whole workflow that includes planning, collaboration, testing, deployment, and maintenance.

ソフトウェア開発は単にコードを書くプログラミングだけでなく、「計画、コラボレーション、テスト、デプロイ、メンテナンスを含むワークフロー全体」という視点を持つことが重要だと。

In other words, while AI can generate code, it often struggles with engineering.

現時点では AIはプログラミングは得意だがエンジニアリングは苦手であるとか、『人月の神話』でいう「偶発的な複雑さ」の処理に優れているが「本質的な複雑さ」にはまだ対処できない*3、とも表現している。

ちなみにこの本の著者は Google Chrome のシニアエンジニアリングリーダーである Addy Osmani 氏。ソフトウェア工学やコンピューターサイエンスの専門性を十分備えているであろうエンジニアによる言説である点を付記しておく。

AI-assisted Coding の 3 類型

AI ツールを使ったソフトウェア開発のスタイルは 3 つに分けて説明されていた。

  1. First Drafter: AI モデルが初期コードを生成し、開発者がそれを改良、リファクタリング、テストする。「もういい、あとは俺がやる」スタイル。
  2. Pair Programmer: 開発者と AI が常に対話し、緊密なフィードバックループ、頻繁なコードレビュー、最小限のコンテキストで協働するスタイル。
  3. Validator: 開発者が最初のコードを書き、その後 AI を使って検証、テスト、改善するスタイル。

今の自分は主に First DrafterとしてAIを活用しており、Pair Programmer としては少しだけ、あまり Validator としては活用していない。それぞれのスタイルをもう少し実験してみたい。

AI-assisted Coding Golden Rules

Git を細かく使えとかジュニアとして扱えとかよく言われるものも含めて12個ぐらい。巷のブログではまばらに紹介されていることが多いが、本書に述べられている内容をメモしておくとよいのではなかろうか。

全部引用すると長いので特に良いなと思ったもの。

  • 常に検証する: AI 生成コードを意図と照らし合わせて検証/テストする。意図をテストとして書き起こすのをサボらない
  • 思考の拡張として活用する: AI は思考を置き換えるのではなく、能力を拡張するツール。考えることまで任せてはいけない
  • すべてのコードをレビュー: 人間が書いたものでも AI が書いたものでも同じ基準でレビューする
  • 理解できないコードの排除: 機能と影響を完全に理解していないコードは絶対にマージしない
  • 効果的なプロンプトの共有: 高品質な出力につながるプロンプトを文書化・共有する

レベル別アドバイス、成長戦略

シニア・ミドル・ジュニアそれぞれのエンジニアに合わせたアドバイスは実践的な内容だった。こちらもボリュームがそこそこあったので面白いなと思った点を 2 つだけ。

1つ目は、AI-assisted coderであっても定期的なAI デトックスをするとよいとのこと。時には AIのブースターを外して素のコーディングスキルの研鑽を定期的に行うというアイデアコアスキルの学習を省略してしまうとメタスキルが磨かれないという考え方に基づく。Vibe Coding の本なのに遠ざけているのは少し面白いが、本書の主張に照らし合わせれば納得感がある。

2 つ目は、AI時代にジュニア開発者が身につけられる最良の習慣の一つはコードのテストを書くことであるというアドバイス。テストを通じてシニアエンジニアのような審美眼を磨けるだけでなく、バグ発見ができたらそれはAIにできない付加価値としてチームに貢献できたことになる。ソフトウェアがどう振る舞うべきかの判断から入り、テストを書くことで AI-assisted Coding による成果物の品質と理解度も向上するとのこと。

総じて

冒頭にも書いた通り、現時点で読める2つの章ではvibe codingの話よりもAI-assisted codingが主流になっていく世界でどのようなスキルが必要なのか、どうスキルを磨いていくのかが中身であった。

技術革新が激しいので正式版が出る頃には世間の状況も一変していそうではあるが、普遍的なエンジニアリングスキルに焦点をあてるのであれば長く読まれる本になるかもしれない。

個人的には正式版と読み比べることで、Early Releaseで抱いた印象が変わるかどうかを楽しみにしている。

*1:余談だが昨今のAI codingという言葉に曖昧さを感じており、本書が用いるAI-assisted codingは指すものが明瞭でよい

*2:Simon Willisonは苦言を呈している https://simonwillison.net/2025/May/1/not-vibe-coding/

*3:関連: Out of the Tar Pit

ランタイムでのdeprecated method callの自動修正についてRubyKaigi 2025で発表しました

表題の通り、Rubyにおけるランタイムでのdeprecated methodの自動修正についてRubyKaigi 2025で発表してきました。スピーカーとしての参加は昨年に続いて2度目ですが、昨年とは違った経験ができました。

続きを読む

2024年読んで印象に残った技術書

2024年に読んで印象に残った本を振り返る。

万人におすすめしたいものではなく個人的な印象深さで選んだ本です。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう

プロパティベーステスト手法の巧みな紹介や実例といった内容が面白いのもある。それ以上に、プロパティベーステストのRuby版のライブラリを作り、2024年のRubyKaigiに登壇するきっかけとなった本なので実に印象深い。2024年初めからRubyKaigiにかけては何度も読み直した。

ohbarye.hatenablog.jp

ohbarye.hatenablog.jp

github.com

(ツール開発はしばらく手を止めていたが、最近不要な機能を落とすcommitsを積んだりした)

プロパティベーステスト手法は面白い。しかしながら自分の練度の問題もあり、なかなか実践の機会を得るのが難しいと感じている。多少試してみたこともあるが「いや、これは使いどころではないな」「通常のexample based testingや他のテスト手法で問題ないな」となってしまう。

これはおそらく普段の自分が書いているコードの性質にもよると考える。特に最近の業務で書くWebアプリケーションコードであればproperty based testingに頼らずとも型やスキーマ、ビジネス要件の整理といった入力値の空間や次元の極小化のほうが効率的かつ経済的な課題解決であると感じる。逆に言えば、世界中のあらゆるプログラマが無造作に使いうるようなOSSを書くとか、不特定多数のクライアントからコールされるWeb APIを保守するとか、そういった場面でスッと持ち出せる切り札として引き続き研いでおきたい。

プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ

昨今よく使われる "認知負荷" についての整理、コードにおける混乱の種類の整理等々、経験を通じて獲得される暗黙知のようなものを認知科学的なアプローチで言語化されていてよかった。単なるコーディングやコードリーディングそのものにおける問題以外についても多く触れられていたのが良かった。

たとえば最も貴重で有限な資源である集中力を妨げる割り込みについて、専門的な研究が紹介されていた。

プログラミング作業にはウォームアップ、困難な作業、クールダウンの段階があり、いわゆるゾーンに入るというのはウォームアップを終えることを意味する。割り込みとは、これらのステップのいずれかにおいて発生し、再開時にコードに関するコンテクストを再構築するために意識的な努力を必要とするもの。割り込みは他人からのアクションで起きるものだけでなく、コーディングで詰まったときにGoogle検索するとか、ChatGPT等に相談して返答を待つとかそういった行動も含まれる。

「完璧に覚えなくてもインターネットで調べればいい」という助言はよく使われるし自分も用いてきた記憶があれば、本書によればあまりよい解決策ではない。記憶している知識があるほうがコードリーディングにおける効率性と理解の促進において圧倒的に有利だし、先述の割り込みによる作業の中断が起きにくいためである。(Webブラウザを開いてメールを見たり、チャットツールを見たり、関連する別のページを見てしまったりする経験が誰しもあるはず)

また、なんらかの初学者が概念を獲得する過程について説明する"意味波"について知ることができて良かった。一般的で抽象度の高い概念を知り、具体的な事例を見て理解を深め(アンパッキング)、異なる文脈や言語に適用するために抽象化する(リパッキング)という交互浴が必要である、と。

このアイデアは自身が今後何かを習得するときにも有用だし、オンボーディングプロセスやジュニアの育成といったタイミングでも意識したいところである。

継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣

製造工学と設計工学の違いを自分の中に取り込むことができたのが大きかった。

ソフトウェア開発における製造とはビルドボタンのクリックである

我々はソフトウェア産業に製造現場の思考法を応用しようとしてきたが、それが誤りで、ソフトウェアにおいて製造は問題ではないと言い切っている。

真のソフトウェア工学は、私たちの創造力と、高品質で役立つものを自信を持って作る能力を引き上げます。アイデアを掘り下げ、創造力を伸ばせるようになり、大規模で複雑なシステムを構築できるようになります。

工学と聞くと鈍重なプロセス、平均的な人々をうまく働かせる方法、といった「製造工学を無理にあてはめようとするイメージ」を持たれることもある。しかし設計工学、とりわけソフトウェア工学はもっと個を引き上げるためにあるものだという主張に説得力を感じている。

ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。

せっかく2025年に生きているのだから、すでに見つかっている効率的/経済的な解を積極的に採用していきたいし、後進に対して高速道路を案内できるようなエンジニアでありたい。このことについてはYAPC::Hakodate 2024に参加して、個人技と工芸と工学について考えた - valid,invalidでも少し触れている。

マネジャーの実像

マネジメントは専門技術ともいわれているので技術書枠。だが同書によれば、「マネジメントはサイエンスでもなく専門技術でもなく、実践の行為であり、主に経験を通じて習得されるもの」とのことで、レギュレーション違反かもしれない。

エンジニアリングマネジメント関連の書籍も充実してきているが、より源流というか、より大きく一般的かつ大局的なマネジメントのインプットも重要だと実感した一冊。

本書ではマネジメントをアート・サイエンス・クラフトのミクソロジーと捉えており、面白いことに読者を診断するちょっとしたワークシートがある。試したところ自分はほとんどクラフト寄りであり、自己の経験の範囲内に閉じこもる恐れがあるというフィードバックも得られた。マネジャー個人がすべてを兼ね備える必要はなく、チームにおいて不足する領域を特定して補うようなアプローチが有用とのことで、チームを見つめるときの1つの観点として用いている。

この本と直接は関係ないものの読了後の思索と併せて書いた記事が以下であり、本書を少しだけ引用した。本記事が多くの人に読まれたのも印象深さにつながっている。

ohbarye.hatenablog.jp

今なら『ミンツバーグの組織論』のほうが新しくて良いのかもしれないがこちらは未読。

まとめ

2024年は特定の言語やノウハウを深掘りするような書籍はほとんど読まなかったようす。ここに載せていないもの、非技術書も含めると能力の獲得や学習に関する本が多かったように思う。特に意識していたわけではないのだが自身の現在の課題意識や興味関心がそのあたりにあるのかもしれない。

非技術書も気が向いたら紹介したい。

東京Ruby会議12に参加しました & 前夜祭で発表しました

表題の通り東京Ruby会議12に参加しました & 前夜祭で発表してきました。

発表

僕の発表は前夜祭の10分枠だったのでライトなネタとしてGit scrapingについて話しました。

Git scrapingとは単にスクレイピングをするだけでなく、定期的に実行し、結果をgit repositoryに記録していくことで時系列データが得られるというものです。詳しくはSimon Willison氏の2020年の記事 Git scraping: track changes over time by scraping to a Git repository をご参照ください。

東京Ruby会議12のテーマは "Rubyと暮らす" だったわけですが、日々の生活の中にどうやってRubyが入り込んでくるかどうかは人によってまちまちです。特に、初学者であったり、業務でRails書いているだけのような感覚の方だとなかなか "Rubyと暮らす" 最初の一歩を見出しにくいのかもなと思います。その一歩目としてGit scrapingを選んでみるのはどうか、という提言をしたつもりです。

他の方の発表

前夜祭も本編に劣らず面白トークが連発していて良かった。特にokuramasafumiさんの「Rubyで書いたらRuby-ishになってる」は最高にキマってる感じがしていたのと、makicamelさんのErdMapは知らないアルゴリズムの話が出てきて興味が湧きました。

本編ではキーノートの2本が印象深かった。jhawthornさんのGitHubの話はRubyRailsがスケールすることを証明してきた会社ならではでありました。脚注でたくさん記事リンクが付いていたので、あとでそれぞれのテクニックやツールを深掘りしてみたい。eagletmtさんのRustは案外Rubyと近いというのも、面白かった。ifが式であるとかの式志向な言語は僕も好みなので2025年はRustもっと知ってみようという気持ちになれた。

イベントの感想

前回の11は僕がRubyを始めた頃で当時は存在すら知らなかった...。osyoyuさんがリブートする形で開催をキメてくれたのが12。

regional.rubykaigi.org

地域Ruby会議も地域によって規模はさまざまだと思いますが、300人規模はさすが東京。さまざまな企画やスポンサーブースや海外から招聘されたキーノートスピーカー等々、半端ない労力が透けて見えるすごいイベントでした。オーガナイザーズの労力が大変感じられる作り込みがされていて良かったです。

ニッチなポイントかもですが前夜祭のソフトドリンクに伊良コーラがあって感動しました。高田馬場から少し歩いた下落合に伊良コーラ本店があり、そちらでいただいたコーラがあまりに美味しく、僕がクラフトコーラを自作しようと思ったきっかけでもあります。アルコールに弱くクラフトビールは飲めない者としてクラフトコーラを応援しています。

ohbarye.hatenablog.jp

また、ランチも懇親会も初めましての方々と交流できたり、お久しぶりですが出来たりした。

改めて運営や関わった皆さんお疲れ様でした!

2024年の登壇発表についてまとめと振り返り

2024年の登壇発表をまとめる。

一覧

1年間で6本、だいたい2ヶ月に1本ペース。

CFPへの応募形式が3本、YAPC::HiroshimaとRubyKaigiとKaigi on Rails。出したプロポーザルは4本で、落選したのはYAPC::Hakodate 2024。

また、所属会社主催のイベントでの発表が3本。

2月: YAPC::Hiroshima 2024

Idempotency-Key Headerについて2回目の発表。前回はKaigi on Rails 2021だったので、プロトコル策定にあたっての数年分のdiffを見られたら面白いと思いsubmitした。が、調査したら思ったよりも差分がなくてびっくりした記憶がある。

ohbarye.hatenablog.jp

4月: B/43 Tech Talk 〜「お金の使いすぎ」を防ぐ新しい家計管理機能開発の裏話〜

プロトタイピング、もっとやっていきたい気持ちで話した。諸事情あり、まだやれていないかもしれない。

5月: RubyKaigi 2024

RubyistとしてRubyKaigiの舞台に立てるとは長らく思っていなかったので、何よりも印象深かった。その他の感想は別記事にて書いたのでここでは省略する。

ohbarye.hatenablog.jp

10月: Kaigi on Rails 2024

Data migration手法のレールがないよね、という話をした(なのでタイトルの on Rails にやや違和感を持ちつつ話していた)。4年前に調査して導入した手法を振り返る、4年前と今でのコミュニティの現状差分を見る、自分が知らないことは詳しい人にインタビューする、といった新しい要素を持ち込んだのがだいぶ好評だったようで嬉しい。

ohbarye.hatenablog.jp

11月: After Kaigi on Rails 2024

なんとなく経験と勘でやっている部分が多いプロポーザル執筆について、今ならある程度固めた発信ができるのではないかと上期が終わる頃に考えていた。その直後に機会をもらえてまとめることができ、良い思考の整理となった。

12月: やりたいことに対して「エンジニア」が足らんです!LT座談会

僕の過去記事で最も読まれているものの一つに状態、結合、複雑性、コード量の順に最適化する - valid,invalidがある。業務でも折りに触れてこの指針を参照したり議論したりしているので、何かしらの実例を紹介したいと思っていた。

完璧に意図したわけではなかったが2024年に開発した機能について振り返ったとき、この設計指針に絡めて話せそうということでテーマとした。

同僚のnakamuuuと共同発表という新しいスタイルも面白かった。

振り返って見ての感想

今年は昨年よりも多くプロポーザルを書いた年だったが採択率もほぼ下がらず満足できた。生成AIレビューなどを活用してみんなどんどんプロポーザル執筆が上手くなっていくはずなので、僕もさらに上手くなっていきたい。


自分の登壇発表を並べてみるとやはり、というかずっと思っていることではあるが、一貫したテーマがない。

ある時期に一番興味があることについて目標を立て、登壇発表のようなわかりやすいマイルストーンを置いて、実行する。達成したあとも同じテーマで延伸可能とは思いつつも、前目標に向かっている間に抑圧していた別の興味を抑えられず、そちらを次なる目標として軽率に置いてしまう。

楽しんでやれる範囲でやる、と決めているのでさほどネガティブには捉えていないが、一貫したテーマや代名詞のような作品を持つ方々の眩しさは今でも感じ続けている。

ブログ記事のカスタムURLは year/month/day/slug 形式にしている

ブログ記事のカスタムURLは year/month/day/slug 形式にしている。つまり 2025/01/13/my-awesome-article のようなカスタムURLを指定する。

slugとは何か?については ソフトウェアの世界での slug / スラグ / スラッグの意味 - valid,invalid を参照。かんたんにいうと my-awesome-article のように、人間が読めるような記事IDのこと。


たった一つのシンプルな理由、見やすいから。

のように並んでいるよりも

としたほうがわかりやすい。公開時期もちょっとした概要もURLに含まれており、情報量が多い。

今どきURLだけで記事一覧を見ることもほとんどないかもしれないが、何らかのツールで記事一覧URLを操作したり分析したりするようなとき、URLだけを見て判別可能であるほうが助かる。また、時折slugだけのURLも見かけるが公開時期がわからないのは不便である。


(余談)SEOなどは詳しくはないがカスタムURLがPV等に与える影響はほとんどないと考えている。この観点を気にするぐらいなら内容を磨くか拡散に力を入れるほうが遥かにリーチしやすくなるのは間違いない。

たとえば、先日公開した記事『2024年に乗り換えた or 乗り換えつつある開発関連ツール - valid,invalid』は久々の執筆すぎてカスタムURLをつけ忘れてしまった。 https://ohbarye.hatenablog.jp/entry/2025/01/11/105436 という許し難いURLなのだが2日で6,000PVがつき、はてなブックマーク数は500を超えた。一例ではあるものの、この事実が"カスタムURL"と"バズ"の無関係さを表しているように思う。

2024年に乗り換えた or 乗り換えつつある開発関連ツール

2023年か2024年か記憶が怪しいものもあるが自分の中で"最近乗り換えたもの"ぐらいのノリで書いていく。レイトマジョリティの自覚あり。

JetBrains系エディタ(RubyMine etc.) → Cursor (移行中)

一番大きい移行。2024年末〜2025年始に移行を試み、今も手探り中。

www.cursor.com

きちんと評価するためにPro planを契約した。

  • Cursor Tabの体験が圧倒的に良い
    • コード補完は古くはTabnine、2022年からGitHub Copilotを経験してきたが段違いに感じる
    • シンプルに補完内容が優れているだけでなく
    • 複数行の変更、変更後の次の変更の提案などが高速で賢く "ワカっている" 感がすごい
  • Composer (normal mode. not agent) がかなりまともなコード出力や修正提案をしてくれる
    • 年始に新しいツールを書き始めたときブートストラップにかなり役にたった
    • READMEをある程度しっかり書いてプロジェクトの参照させたのが良かったか
  • Chatは使い込んでいないがCopilot Chatと大差ないように感じる

どこかの感想記事で見かけた、 コーディングが速くなることよりも、細部にこだわりすぎずハイレベルのことを考え続けられるようになることが価値 というのが理解ってきた気がする。

一方、ベースとなるVS Code自体のカスタマイズも並行しており、まだ"馴染み"を感じきれていない。主に書いているRubyについてはRubyMineの"勝手に良い感じにしてくれる力"はゼロなのでRuby LSPをなんとかしたり、良い感じのthemeを選ぶ必要がある。themeは地味に悩んでおり、IntelliJ Darculaに相当するextensionを試したら再現度がイマイチで、今はShopifyのRuby extension packインストール時についてくるSpinel Darkを使っている。慣れるだろうか。

コーディングだけでなく職務経歴書を⌘K / Cursor Tab / Composerを使いつつ更新してみたり、技術カンファレンスのプロポーザル磨き込みのために過去のPASSしたプロポーザルを参照させてみたり、ライティングツールとしても良い感じになってきている。

もう少し試用したら感想をまとめてみたい。

Google Chrome → Arc (移行中)

2024年末〜2025年始に移行した。年始はお試し期間のつもりだったけど永住できそう。

arc.net

  • Chromeほどメモリを使わないという噂は本当だった
  • Chromeからの移行はまあまあスムーズ
  • 現代の横長ディスプレイに適応していてWebページを"広く"感じる
  • ウィンドウ2枚用意しなくても複数タブを分割して表示できる
  • bookmarkletが使えないという課題がある
  • Boostという機能で特定ページにCSS, JSを挟める。Chrome extensionとして入れていたTampermonkeyを無くせそう

Space, Profileあたりの使い分けが分からず、最初はChromeからprivate / workそれぞれのProfileをインポートするたびに設定が崩壊して導入大失敗していたのだが、なんとか使えるようになった。

招待リンク: https://arc.net/gift/d7d515a5

(2025/01/17 追記)

記事公開後に知ったのだが早くもArcの開発は終了していた...。開発元のThe Browser Company社は次のproductとして、"Dia" なる新しいブラウザを開発中とのこと。Diaは2025年の早い時期にリリースされるそう。

iTerm2 → Warp

macOSをメインにしてからiTerm2を長らく使っていた。が、あまり使いこなしている感じはなかったので同僚が使っていたWarpを試した。

www.warp.dev

数日使った結果、非常に気に入ったので使用し続けている。Free planだが今のところ大きな不満なし。

  • ターミナルでやりたいこと、あると便利の大部分が基本機能として実現されている
    • コマンドの補完
    • コマンドの履歴表示と検索
    • Zshをカスタマイズして実現していたことのいくつかが不要になった
  • コマンド入力と出力がブロックという単位でまとめられていて便利
    • 調査結果を貼り付けたり、コマンド実行結果をcommit logに入れる時などに使う
  • カスタマイズしなくても見た目が良い感じ
  • AI機能はちょいちょい使っている
    • やりたいターミナル操作のコマンドがパッと出てこないときに聞く
    • ターミナルとインテグレーションされているだけあり、Copilot CLIよりも良い所感

招待リンクはこちら https://app.warp.dev/referral/MPQYRJ

Alfred → Raycast

長らくお布施してきたがお別れした。これも同僚からの薦めによる。

www.raycast.com

  • クリップボードあるので専用のアプリ (Clippy etc.) が不要になった
  • ウィンドウ配置できるので (Magnet, BetterSnapTools etc.) が不要になった
  • アプリ横断したグローバルなSnippets置き場もついてる
  • Night Shiftのon/off toggleができる
  • 賑やかしコマンド Confetti があって画面共有時に一段"有利"
  • Free planで今のところ十分
    • AI機能はぜんぜん使わない
    • cloud syncだけ欲しいかもと思ったことはあったが無くてもやれてる

余談:もう卒業したがDHHもmac時代はRaycastユーザーだったようす。

Bartender → Ice

macのメニューバーを綺麗に整理・カスタマイズできるアプリケーション。

github.com

Bartenderを長らく使っていたが開発元が変わった時の問題をうけ、代替アプリに乗り換えていた。

(なし) → NearDrop

乗り換えではなく新規導入

AndroidからmacOSにファイルを共有するときにiPhoneAirDropみたいにできるやつ。便利

ohbarye.hatenablog.jp

類似の目的で、過去の同僚に教えてもらったPushbulletも併用している。

www.pushbullet.com

Docker for mac → OrbStack

orbstack.dev

速すぎる。当初はいろいろスカスカな状態だからか?と疑っていたが1年以上使っている今でも圧倒的に速いし、省リソースで安定して動く。

独自のファイルシステムシステムコールを削減していたり、賢い動的メモリ管理によって必要な分だけメモリを割り当てたり未使用メモリを自動的にmacOSに返却しているらしい。

Pro planを使っているがDocker for macの代替以外の機能はほとんど使っていない


上記の移行したツールの中でも最も新鮮に感動したのはやっぱりCursorだった。

開発関連のツールについてはレイトマジョリティの自覚ありで、同僚の推薦などによりtrial開始することが多い。昨今の技術的進歩の中、フットワーク軽く色々試していかないといけない気持ちはある。