コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

RubyKaigi 2026に行ってきましたメモ

RubyKaigi2026に参加してきました。

RubyKaigi自体の参加は今回が2回目で、初参加は2024年でした。(そのときの感想はこちら)

セッションについて

いくつか印象に残ったセッションを書き残しておこうと思います。

The Journey of Box Building

speakerdeck.com

今回のRubyKaigiのオープニングキーノート、 Ruby::Box に関してのお話です。

ぼんやり Ruby::Box の機能を知っているレベルだったので、やれることが色々広がるなという気持ちを抱きました。が、その反面これは律するものがないとチームであつかうのは難しいなとも感じたので、今後の発展とユースケースを見ていきたいなと思いました。

また後半のRuby::Boxに取り組もうと思った流れも「作りたい人の原動力が昇華されていく」というようなものを感じて色々と考えさせられました。

なお私はRuby::Box ダイジェスト紹介(Ruby 4.0.0 新機能) - STORES Product Blogを見て改めて理解を深めました。こういう情報がすぐ出てくるのもRubyのよいところ。

Back to the roots of date

speakerdeck.com

Date にまつわる話とそれをどうにかしようとして動かれた話だったのですが、いろいろな面で刺激になりました。

  • TimeとDateが誰も触られていない場所だったということ
  • 元があるならそれを再現すればいいじゃないのマインドを成立させる生成AIの凄さ
  • 生成AIとの付き合い方を間違えると手戻りが起こるさま

今後も継続していく話だと思うのですが、このようなが課題感としては感じているが触れられていない問題をコミュニティが解決していくというのはすごく良い話だなと感じました。

mruby on C#: From VM Implementation to Game Scripting

speakerdeck.com

mrubyをC#でで動かして扱えるようにしてみたよという話。

浸透したらめっちゃ使えるのでは?とゲーム制作素人でも思うところはあり、例えばシナリオパート作るものだとや などあると思うのですが、ちょっとオリジナルの記法とか入れようとすると出来合いのものはマッチしなくて、でもカスタマイズしたなにかをつくるのは腰が重い、みたいなときにmrubyで何か用意できるのは大きいんじゃなかろうかと思っています。

個人的にはLuaがゲーム制作でよく使われる背景がわかってよかったです。

From Formal Specification to Property Based Test

speakerdeck.com

形式仕様からプロパティベーステストを生み出すアプローチに関しての話。

昔から形式手法に関して夢を感じていつつも、あまりちゃんと突っ込んだ調査などはしたことがない人間だったのですが、この発表を聞いてしっかりと学んでみようと思うきっかけになりました。

The Less-Told Story of Socket Timeouts

speakerdeck.com

Socketのタイムアウトについての話。

限られた時間で歴史に関してテンポよく語っていくのはすごい。スライド数もべらぼうな数になっていますが、この数をあの時間に収めたのは本当にすごいと思います。

内容としてもRubyKaigi歴が浅い人にもやさしく順を追って説明していただけるのでたいへん良かったです。

RubyKaigiという場について

他のカンファレンスではあまり感じられない祝祭空間の感じが強く、ブース、発表、参加者どれをとっても非日常感が紡ぎ出されていました。 あんまりカンファレンスでブースを回るというこをしないのですが、休憩時間の間隔の長さや、ブース全体の空間のゆとりの多さもありかなりストレスフリーで回ることができました。

個人的に思うこと

どうしても英語セッションに関しては「なんとなくこういう話をしている気がする」という感覚から脱せず、またC言語の実装の話をされるとなおのこと理解がぼやけるのですごくもったいない感じを受けてしまいました。とはいえこのあたりのリスニング能力を養う時間やスキルがないので、アクション起こせてないのですが、何かしら起こしたい気もします。

また、提供されるお弁当などが美味しかったのですが、本編の感想からはそれる気がするので別のところにしたためました

最後に

RubyKaigiにいくと、いろいろな刺激をもらうことができるなと思うので、Rubyを業務で使う使わないにかかわらず行けるときには行きたいと思う場所でした。

『設計ナイト2026』に行ってきたよメモ

設計ナイト 2026 』に参加してきたのでそのメモです、

各発表の感想

※資料スライドは見つけたら貼ります。


アーキテクチャモダナイゼーションとは何か-技術・事業・組織で大事なこと

感想

  • 技術、事業、組織を3つ同時に動かすことをコンセプトにした話。
  • いずれかを単独で行うと、局所最適が起きるというのはそのとおりだなと感じた
  • 情報量が多かったのでスライドを見ながら見返したい。

関連リンク


悪い設計 <やつ> ほどよく残る ー 「なんでこうなっちまうんだ?」を掘り下げる

スライドは見つけたら貼ります

感想

  • ダメなコードはどんどん広がっていくという話
  • ダメになったコードが大きく広がっていく過程が綺麗に言語化されていた。
  • 「汚れた聖域」「善意の割れ窓」などワードチョイスが秀逸だったのでどこかで活かしたい

関連リンク


制約を設計する - 非決定性との境界線

感想

  • AI時代に備えるべき非決定線との境界線の話
  • AIが入力に対して一定ではない出力をするのは人間と同じなので、人間と同じ方法論は適用できるというのは確かにという気持ち
  • ここから考えるべきはどれだけ人間が生み出してきたガードレールの作り方をAIに転用できるかどうかかなと感じた
  • 質疑応答でAI時代の挑み方として「新しいものが来たら捨てられる」という観点が語られているのは学びがあった。

関連リンク


感情を設計する

感想

  • 人は感情の生き物なので、感情の対立を避けるためにはという話
  • 人は感情の生き物であるというのは様々なところで語られているので理解できる
  • 感情の対立が起こるモデルケースを話してくれたので、組織などのことで悩んだら読み直したい
  • もっと現場の実例とか聞ければよかったんですが、うまく話す機会が作れず残念...

関連リンク


AIがコードを書く時代のジェネレーティブプログラミング

感想

  • モデルを検証可能にするという試みの話
  • このように昔語られた議論がAI時代で再燃したり、再評価される話は色々ありそうだなと感じた。

関連リンク


あるアーキテクチャ決定と、その結果

感想

  • オフレコ多めのADRの振り返りの話
  • ADRをやってみたけどその結果どうなのという話はありがちなので、ADR決定その後の話は有用な知見。

関連リンク


プロダクト粒度設計でも基礎となるコンポーネントの凝集原則

スライドリンクは見つけたら貼ります

感想

  • 凝集原則をベースにどうやって整理するかという話
  • ウォードリーマップという単語は初めて聞いたのでそういう意味でも収穫がありました。

関連リンク


全体を通しての感想

  • 設計という話を軸に置いてもバラエティに富んだ話が多くてよかったです。
  • こと生成AI時代に於いては、AIの出してくるものの良し悪しを確認することになるので、下地としての設計力は大事だなと思いました。
  • アーキテクチャモダナイゼーションは新時代の取っ掛かりになりそうなので、切に読みたいと思いました。
  • 懇親会に始めて参加したのですが、バラエティに富んだ話が聞けてよかったです。ただいろんな人に話を聞きたかったがうまく立ち回れずなので次回はもっと動きたい...

『EM Meetup 特別会 〜EMこそソフトウェア設計を学ぼう〜』に行ってきたよメモ

EM Meetup 特別会 〜EMこそソフトウェア設計を学ぼう〜』に参加してきたのでそのメモです、

各発表の感想


開発組織の戦略的な役割と設計スキル向上の効果

感想

  • IT開発が事業の中核になりつつあり、事業の高業績にどう関われるようにするかというお話
  • 事業の変化に対応できるようになっていることが大事で、中核を対応可能になっていないと高業績をつくる足かせになるというのは本当に肌で感じる
  • 特に差別化要素に関しては丁寧に説明されており、マイケル・ポーター差別化戦略を読んでみたくなった。
  • 逆に中核はなにか、事業として中核でない部分まで自らの手で作ろうとしてないか?というのは常に考えておきたいトピック
    • 内製開発やっているとなんでも作りがちになるので、SaaSに委ねて問題ない部分はどんどんアウトソースするべき

関連リンク


ワークショップ

「事業理解から始めるソフトウェア設計道場」の導入部分に関して体験させてもらいました。

levii.co.jp

自社が持つ特性、特に差別化できるような要素を考えみようというものだった。自分が置かれているプロダクトでもセールスポイントとしておいているものとは別にどのようなところが差別化要素なのだろうと考える機会になった。

本題とは関係ないのですがBalus というツールがモデリングのために特化したツールですごく面白かった。miroでもできるが、miroではやれることが多いので削ぎ落とされているあたりが差別化なんだろうなと感じた。


OSTの感想

OST自体初参加だったのでわたわたしながらも参加しました。

私は「ドメイン知識の他人への橋渡し、どうしてる?」というテーマでOST参加しました。

オンボーディング的な話もあったのですが、興味深かったのが「ドメイン知識としてわからなかったことや解決したいことの内訳を書いて、それを解決したことをPullRequestで表現し、最後にそれを生成AIにドキュメント化してもらう」というもの。

何かしらのシステムやプロダクトに手を入れる瞬間にドメイン知識が欲しくなり、それを踏まえて手直しを加えるので、そこで得た教訓をサマリーにしてまとめてもらうのは瞬間の記録としては優秀だなと思いました。おそらくこれを貯めていくことで整理された情報も出力されそうでうまいなーと思いました。

全体を通しての感想

  • 増田さんの話が面白そうだったのもあり聞きにいったのですが、OSTも面白く大変参考になりました。
  • 各社生成AIはガシガシ導入しているので、もっと効果的に使いたいなと思わされました。
  • 私自身最近直接EM的な業務はやっていないのですが、みなさんが考えていることはAI時代でもそこまで劇的に変化していないので色々な意見交換ができてよかったです。

Railsで大文字が連続するクラス名をつけるときは統一感を損なわないように気をつける

すごい抽象的なタイトルだが実際困った事があったのでメモ

例えば拡張現実(Augmented Reality)のモデルを表現するクラスを作るとする。そうするときにar_model.rbというファイル名で、中身を以下のように書く。

class ARModel
  include ActiveModel::Model

  attr_accessor :name, :type

end

ただ、以下のようにもかける

class ArModel
# 後略

これはクラス名だけではなくモジュール名でも同じことが起きるので、ディレクトリ設計やファイル命名では気をつけること。

起きうる問題

例えば

  • app/model/ar_model/tree.rb
  • app/model/ar_model/house.rb

などとおいた場合に class ARModel::Treeclass ArMode::House というような書き方が混在可能なので、一見するとわかりにくい問題を生む。ただちに実害はないが、コードが成長するにつれてわかりづらさは増すので最初のうちにどちらで実装するかは決めておくほうがよい。

参考リンク

マネジメントをすることで不安を感じたときに見たい資料「Two Blades, One Journey: Engineering While Managing」

リーダーとしても、プレイヤーとしても動きたくなったときに見返したいのでメモとして

対象のスライド

speakerdeck.com

みどころ

マネジメントレイヤーが訪れる、不安に関しての言語化とそれに対する登壇者なりの解があるところがみどころ。かなり多くの人が遭遇するであろう不安に対してのヒントになりそうな部分はあり、私は少なからずここから色々と思い返す部分が多かった。

関連リンク

アサーティブコミュニケーションの原典をざっくり整理する

よくわからなかったので色々整理しながらまとめる

アサーションコミュニケーションの原典

アサーティブコミュニケーションの話の祖となっているのはAndrew SalterのConditioned Reflex Therapyとされている。この書籍の中ではアサーティブコミュニケーションというフレーズは登場しないが、概念自体は昨今語られているものに通じる内容となっている。

Salterの考え方

Salter は、人の行動には大きく分けて 「抑制的反応(inhibition)」と「興奮的反応(excitation)」 があると考えました。

反応タイプ 特徴 具体例
抑制的反応 感情や欲求を抑える・回避する 「言いたいけど黙る」「断れない」「自分の意見が言えない」
興奮的反応 感情や欲求を正直に表現する 「私はこう思う」「嫌です」「それは嬉しいです」などを適切に口にする

この興奮的反応を繰り返し訓練して学習することにより、「パブロフの犬」の考え方と同じように意識せずとも条件反射的に行えるようにするというアプローチです。

Salter が提示した代表的な訓練技法

原著からかなり時間が経過しているのですが、当時語られていた技法には以下のようなものがあります

1.アイ・トーク(I-talk)

自分の感情や欲求を「I(私は)」を主語にして表現する。「私は今、疲れているので少し休みたいです」など、「私」をちゃんと入れて喋る。

2.感情の言語化(Feeling-talk)

感じていることをそのまま言葉にする。「それを聞いて、私は驚きました」や「あなたの提案、うれしく感じました」など、感情を“思考”ではなく“体験”として伝えることを促す。

3.表情・身体での表現(Facial-talk・Body-talk)

表情や姿勢など非言語コミュニケーションを行う。感情と身体表現の一致するのが大事なので、ちゃんと意識して行えるようにする。

4.賞賛の受け入れ訓練(Accepting Compliments)

抑制的反応を多くする人は、褒められると否定したり曖昧にするため、それを改善する。「いやいや、大したことないです」ではなく「ありがとう、そう言ってもらえて嬉しいです」というようにし、自尊感情・自己効力感の基礎を作る。

5.即興的対話(Spontaneous Behavior Training)

計画せずに思ったことをその場で言う。即興で話す訓練を多くし、完璧に考えてから話す癖(抑制)を減らし、自然で柔軟な自己表現を促す。

6.宿題(Homework)

これまでに紹介したことを日常的に生活でやることを意識付けることが大事としている。

Salterの訓練で重視された観点

Salterは精神的な不調が「抑制的反応」が強く出てしまうことが要因と考えていたので、そこを訓練する事によって興奮的反応に変えようとするアプローチになっています。

そのため訓練では繰り返しやることで習慣づけ、日常期に取り組み、アイトークとしてやることで責任と主体性をもたせることが念頭に置かれています。

このSalterの考え方をもとに行動療法として整理されていき、のちのアサーティブコミュニケーションにつながっていったとされています。

参考リンク

『Kaigi on Rails 2025』に行ってきたよメモ

Kaigi on Rails 2025に参加してきたので、見た登壇に関しての感想&メモです。

各発表の感想

dynamic!

感想

  • "動的"に関することをテーマにした発表
  • Rubyとしての話、Railsとしての話、開発の話とすべてにおいて"動的"というテーマで結んでくれる話はとてもよかったです。
  • irbの使い心地に感動した話はめちゃくちゃ共感度が高かったです
  • すべてはアジャイルソフトウェア宣言に戻っていく話など、一周回っているからこそ出てくる味のようなものを感じる話でした。

関連リンク


高度なUI/UXこそHotwireで作ろう

感想

  • Reactができた経緯をたどりながら、HotwireとReactを比較しつつHotwireでもかなりのことができることの話
  • 既存のプラグインもHotwireでとりこむ手法もあるのはあまり知らなかったので学び
  • Railsを使っているけど、Reactを一部取り込もうか悩んでいる人は1回見るとよさそうな話でした。

関連リンク


そのpreloadは必要?──見過ごされたpreloadが技術的負債として爆発した日

感想

  • N+1を防ぐためのpreloadを使った際の落とし穴の話
  • preloadを使うのは定石だが、ちゃんと使いどころを考えないとよくないことが起きる事例として、とても学びがある話だったと思う。
  • なんでもできるオブジェクトを作ろうとすると起きがちなので気をつけたい

関連リンク


Railsアプリケーション開発者のためのブックガイド

感想

  • Webアプリケーションを作るうえでの血肉になる書籍の紹介
  • 「チームが変わっても一貫したものを作る柱として文化が必要」「ドキュメントは時間を超える」など染み入るフレーズが多かったです。
  • 自分も読んだことのない書籍もあったので、積めるものは積んでいきたいなと思いました。

関連リンク


Web Componentsで実現する Hotwire とフロントエンドフレームワークの橋渡し

感想

  • Angularのコンポーネントをラッピングして使うためにWebComponentを使った事例の話
  • WebComponentを使うと良くも悪くも外界と遮断しやすいのでなるほどなーと思って聞いていました。
  • 実際のレンダリング速度がどうなるかは気になりつつも、手法としては知っておいて損はなさそうでした。

関連リンク


5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム

感想

  • 社内の運用事例大紹介、のような発表
  • 日々の運用で手が届かないところの改善ができていてすごくいい環境だなと感じました。
  • 同時にこれらの運用の解決策は割と環境によっても変わるので、事例としてもとてもいい話でした。

関連リンク


2分台で1500examples完走!爆速CIを支える環境構築術

感想

  • いろいろなテクニックでCIの時間を短くする話
  • 並列化の過程などはなるほどと思いつつ、最後は物理だったのはちょっと意外でした
  • ネタ的な部分もありつつもクラウドよりも物理の話はときたま聞くので、考えさせられる部分はありました。

関連リンク


Railsによる人工的「設計」入門

感想

  • 教わる側の世界観を通じて設計のノウハウを継承するための話
  • 初学者の解像度が高く、なるほどこういう発想になるのかという学びが多かったです。
  • 個人的には、キャリアの初期に画面遷移図からアプリケーションを作ることが多かったので、設計が身につきやすかったのかもしれないなどしみじみ思いました。

関連リンク


今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

感想

  • Serviceクラスの成り立ちと現在の向き合い方に関する話。
  • 個人的にはもととなったQiitaの記事を見てServiceクラスを作ったりしていた時代を経験しているので色々心打たれるものがあった
  • DDD文脈がわからないと理解できないかも、とも思いつつ良い資料だったので折を見て見直したい

関連リンク


2重リクエスト攻略HANDBOOK

感想

  • 2重リクエスト防止に関するパターン集
  • すぐに思いつくものから、HTTPの仕様的なものまで話していたので何かあったときに見返したい資料でした。
  • 取捨選択のパターンも話されていて、とてもよい発表でした。

関連リンク

全体を通しての感想

  • 1日目はかなり自由時間があったので、色々見て回ったりしましたが、2日目は自社のブースにいたので発表はあまりみてませんでした。
  • moroさんとjokerさんの話が本当に良くて、1日目だけでもすごくいいものが見れたなという気持ちになりました。
  • 最近正しくRailsを使える場面がないので、得たものをうまく咀嚼しつつ取り組んでいければなと思っています。