タッチペン 【2025年革新版 全機種対応】タブレット ペン スタイラスペン スマホ Type-C充電 超高精度 極細 12g超軽量 3つ交換用ペン先付き 互換ペン 電量表示/磁気吸着機能対応 軽量 耐摩 耐久 iPad・iPhone・Android・スマホ・タブレット用ペンシル 日本語取扱説明書付き
¥2,099 (2025年4月25日 13:05 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
RubyKaigi2025に参加しました。
引き続きDay3に参加したセッションのレポートです。
認識漏れなどがあるかもしれませんがご容赦ください1
またDay1、Day2のレポートもございますので合わせてお願いします
Ruby Committers and the World
Rubyコミッターによる座談会
- static barrierについてどう思う?
- RubyConf 2020で構想が紹介された機能
- コードの途中で変数をfreezeする機能
- namespaceに対する率直な意見
- Ruby4.0に上げる場合deprecateしたい機能
- 後方互換性を無視してでも変えたい機能
- AIを使ってRuby処理系のコードを書こうとしたことはある?
-
SHARABLE_MIDDLE_SUBSTRING
をデフォルトに組み込む価値はあるか?- ※string.cでoptionalになっている機能らしい?
Running ruby.wasm on Pure Ruby Wasm Runtime
- PureRubyによるwasm実装「
Wardite
」を作ってみた - Rustによるwasm実装を参考にした
- 画像のグレースケール化するサンプルを作成した時に苦戦した点
- メモリ確保が意図通り動作しない
- rustのエラーハンドリング挙動がrubyと異なる
- パフォーマンスが悪くなっているのが今後の課題
Analyzing Ruby Code in IRB
- irbでのコード解析の精度を向上させる案を考えた話
- irbでの機能
- シンタックスハイライト、ブロック内の表記、オートインデントなど
- →これらは概ね問題なく動作するか、いくつかのエッジケースで意図通りの挙動にならないものもある
- 現在コード解析に使われている
Ripper::Lexer
に加えてPrism.parse_lex
によるパース処理と併用することで改善できないか?- Tokenによる構文解析だけでなく、構文木によるコード解析を行うようにする
- 現在対応中
On-the-fly Suggestions of Rewriting Method Deprecations
- ライブラリでDeprecation Warningが出るメソッドについて自動的に修正する仕組みを考えた話
- 現状の場合は以下の3パターン
- YARDなどのコメントとしてdepricatedであることを記述
- 対象メソッド実行にwarnログを出力する
- rubocopなどで指摘されるようにする
- 他言語でも概ね上記通りであるがpharoという言語では別の仕組みがある
- プログラム実行時に対象メソッドを呼び出す場合、自動的にコードを書き換える
- →これをRubyにも適用させてみた
- Deprewriter in Ruby
- 課題
- テスト時にコードを書き換える処理が安全ではない
- 安全な実行モードを追加
- log mode・・・warningのログを出すだけ
- diff mode・・・patchファイルを吐き出す
- 安全な実行モードを追加
- ライブラリ開発者に置き換えルールを記述してもらうのが負担になる
- ライブラリを使う側がモンキーパッチを当てる形で記述することになりそう
- コードの修正処理が効率的でない
- すでに修正済みのコードであっても舐める挙動であるため
- 実装が他のgemに依存している
- テスト時にコードを書き換える処理が安全ではない
Matz Keynote(Programming language for AI age)
- セッションでAIに関する話がなかった(らしい)のでその辺の話
- なお「Programming language for AI」だとpythonでいいじゃん、ってなる模様
- AIによってプログラマの仕事がなくなるんじゃないか、という話があるがそうはならないはず
- おそらくAIが苦手とする分野は人間が引き続き対応することになるはず
- 要件から仕様を決める部分とか
- 上記のような大抵楽しくないことをやらざるを得なくなる状態になるのはAIに使われているようなものでは?
- 「reverse alpha syndrome」
- それは「楽しくプログラミングする」というRubyの在り方からもはずれてしまう
- おそらくAIが苦手とする分野は人間が引き続き対応することになるはず
- AIが発展するにあたりどのような言語が望ましいか?(自然言語も含めて)
- 記述が簡潔、多様な表現力、拡張性がある
- →それってRubyだよね?(予定調和)
- これから必要なもの
- データ
- AIに食わせる学習データとしてはモダンかつ質の良いコードが必要になる
- ツール
- 開発を補助するツール
- Rubocop、Steepなど…
- パフォーマンス
- やっぱり速いほうがいいよね
- データ
- まだまだやれることはある
- Rubyは今の段階では他言語に勝てない部分もあるがのちのちは・・・?
- 今のコミッターだけでなく一人一人が参画してくれればRubyはもっと良くできるはず
余談
- Rubyは今年でリリース30周年
- 初期版(v0.95)のリリースが1995年
- 今年のクリスマスはRuby4.0をリリースする(・・・予定)
- 下記機能が試験的に導入される予定
2026/04/22 〜 2026/04/24
自分自身が大変シャイであったこともあり今までこのような場を避けていましたが、これほどたくさんのエンジニアの方々とお話することができたことは大変良い刺激となりました。
語弊を招く言い方になるかもしれませんが、Rubyコミッターが直に会えることも「Rubyのコミュニティが(良い意味で)狭いコミュニティなんだな」ということを強く実感できました。
来年は他のエンジニアと一緒に行きたいなー(願望)