mame

この話かなmame/ai-coding-lang-bench 現段階では仕事のシステムのコード書くなら静的型付けだけど、それ以外は必要ない気がしている。 今後このLLMの進化+型チェック以外のテスト手法の確立で一気にひっくり返る気もしているので慎重に見た方がいい。

Kaigi on Rails 2026 に、参加者として参加してきました はじめに こんにちは！しげるです。 2026 年 10 月 16 日・17 日に開催された Kaigi on Rails 2026 に参加してきました。 会場の看板 昨年まで、Kaigi on Rails の中の人をしていたので、はじめて参加者側としての参加です。 今年は、DHH が日本で話をするのは、2006 年以来、20 年ぶりとのことでした。 「DHHに会いに来たぜ！！」って感じですね。 びわこ.rb で予習会をやった 今年開催された　関西Ruby会議09 をきっかけに びわこ.rb を開催しています。 10月のびわこ.rbでは、Kaigi on Railsの予習会を実施しました。 2-3ヶ月に一回ゆるく、滋賀の方々がつながる場として企画しています。 x.com 予習会でお話ししたメンバーと会場でも無事合流できました。 x.com 予習会で各セッションについてキャッチアップをしていたので、セッションへの期待値と事前にインプットができたので、楽しむことができました。 聴いたセッション 基調講演 2 本と、特に気になったセッション 3 つを、聴いた順に紹介します。 DAY1 基調講演：DHH「Where the tracks go next」 DHH の話を聞く前は、Rails World 2026 のキーノートで「Rust 最高！」みたいな話をしていたので、Ruby / Rails の話はないんだろうなー、と思っていました。 講演は「おはようございます！」から ところが今回の話では、Ruby への愛が熱く語られていて、安心しました。 20 年ぶりの日本での講演は、「2025 年から全てが変わった」という話でした。何十年分の変化が数週間で起きていて、今はカオスの真っ只中の時代になっています。 同じものを書いたときの行数（Ruby 5,000 / Rust 30,000 / C 100,000） 「Rubyness（Ruby らしさ）」は、いい言葉だなと思いました。AI 時代になって、読むコードの量が一気に増え、1 行ずつレビューするやり方では立ち行かない。コンテキストや意味を理解した上で読むことが大事で、なので、コードの読みやすさや行数の少なさが大事になってきている、という話でした。 一番印象に残ったのは、DHH は Ruby を捨てたと思っていたけど、思ったより Ruby 愛があって、いいなって思ったことです。 DAY1：現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜 登壇者：Emiko Ando さん セッションページ / スライド 英語塾で、校舎ごとにバラバラだったスプレッドシートを、まず全校舎共通のシンプルなシートに寄せて、半年運用してから Rails へ移行した話です。 GAS から Rails のエンドポイントを呼んで、スプレッドシートの使い心地を変えず手作業を減らしていました。半年運用を行い、モデルを進めていきました。 個人的に BizOps に異動してから、現場の声の重要性に気づいています。スプレッドシートで運用している現場も多いです。その中で、どう業務やシステムを理解して進めたのかが気になっていました。 利用者の方にメリットを重視して段階的に移していく様子で学びが多かったです。 DAY2 基調講演：Matz「人間に優しい言語は AI にも優しい」 AI がコードを書く時代に、人間が書くのに快適な言語は必要なのか。 小さな git を 15 言語で AI に作らせる mame さんの実験（記事 / リポジトリ）では、Ruby が一番速く、一番安く書けたようです。ただ、計測は半年以上前のモデルで、最近のモデルでは言語による差はなくなっているようです。 「人間に優しい言語」は人工言語としての Ruby は、他の言語と比べたときの違いだな、認識しました。製品としてメンテナンスしていく上では、可読性はやっぱり大事です。プロググラミング言語 = 人工言語って表現がされて、妙に腹打ちしちゃいました。 DAY2：Web Framework Benchmark Battle 2026, Any% 登壇者：Akira Matsuda さん セッションページ / スライド 前半は、Rails を速くする話でした。オブジェクトの生成数を目安に、Claude に「最適化パッチ書いてくれない？」と頼んだら 33 本の PR ができ、最大 15% 速くなったそうです。 松田さん「何も頭使ってません、AIが全部やりました 笑」 後半は、Rails World での DHH の発言を受けて、Matz に頼まれた Spinel on Rails への挑戦の話。Active Support は動いたものの、Active Record はコンパイルに 10 時間かかり、ベンチマークは間に合わなかったそうです。締めは「DHH と Matz のせいで、プロポーザルと全然違う内容になりました」 DHH と Matz とAIの変化の間に挟まれる松田さんという構図が面白かったです。 エッジケースのパフォーマンスチューニングをしている場合じゃねぇ！と松田さんに思わせるほど、時代が激しく動いているのを実感できました。 参加してみて 参加してみて、Ruby のコミュニティってやっぱり好きだな、と改めて思いました。 懇親会でも、いろんな人と話しました。#Rubyfriends のタグで数年後も見返せるのもエモいですね。 x.com 会社の同僚と！ 関西の #Rubyfriends と！ やんちゃフェス DAY1 の夜は、渋谷 La.mama で開かれた やんちゃフェス Vol.001 に行きました。Ruby コミュニティの人たちが出演するライブで、Kaminari のライブに間に合いました。 カンファレンスは、こんなイベントへ参加できるのもいいですね。 おわりに どの発表を聞いていても AI 時代による変化を大きく受けているなという印象でした。 ですが、ユーザーが困っている声を聞いて解決する。わかりやすくシステム設計をする二点は変わらず重要だなと気づきました。 最近は Ruby Kaigi にもいけていなくて、 Ruby の養分が少なかったのですが、一気に補充することができました。来年は 2027/11/26-27 のようです！！ x.com 運営のみなさん、登壇者のみなさん、2 日間ありがとうございました！

- My own Robot Simulator entry for one of the contests on BadCode.rocks. I fulfilled the prompt of “the worst working implementation to the challenge that [I could] devise” and won an Honorable Mention. - Along the same lines, the better-known FizzBuzzEnterpriseEdition satirically uses a large framework to solve a simple problem. - Quine Relay does something useless but complex in a way that was obviously hard to build. - The winners of the Underhanded C Contest contain hard-to-find bugs that undermine the program’s purpose but look like accidents after they’re found. More generally, Improv Everywhere’s 2009 Subway Art Gallery demonstrated to me that “art” is a perspective with which one can view any object, so I think it’s never wrong to call something “art”. But I find more artistic value in works that satisfy challenging contraints. The most common source of artistic value in programs is the way their code was optimized to be easily readable and maintainable by a human while still implementing the required behavior.

@SebAaltonen @BenjDicken These links basically say you're wrong: mame/ai-coding-lang-bench link.springer.com But even benchmarks are mostly theory. Nanosecond-level performance is theory for most real-world products too. In practice, you need that kind of optimization only in rare and very specific cases.