2019@博多(#4)最適化、パターンマッチング、mruby、ブランチメンテナンスほか|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社エンジニアの「?」を「!」に。2019の発表資料がだいぶ揃ったようです。YouTube誤りや追加情報などがありましたら@hachi8833までお知らせください。「最適化」やはり最適化が最も多いですね。2019(@jeremyevans0)残念ながら現地で見られませんでしたが、ko1さんの発表は「Cで書かれているRubyの組み込みメソッドのうち、単にCのライブラリを呼んでいる程度のものはRubyで書けるならRubyで書こう」という趣旨でした。interface)を用いて、RubyコードからCのコードを呼び出す形で組み込みメソッドを書き、それに応じてVMにinvokecfuncwparamなどのインストラクションを追加したことで、Cネイティブのメソッドより高速にできたというものです。上述のご本人のブログが最もわかりやすいと思います。optimisation」のスライドを見直しました。頻繁に実行されるpopの呼び出し回数を減らすという、VMの内部に切り込む最適化でした。Evanさんのキーノートは、そのまま業務に使ったらやばそうなRubyコード最適化を怒涛の勢いで紹介していました。morimorihogeさんの所感は「すべてを理解しなくてもいいけど、パフォーマンスチューニングに慣れていない人が『こういう書き方は遅い臭いがする』という感覚を養うのにいいと思う」でした。2019(@Hir0_IC)(見に行けず?)気がつけばmruby関連のセッションは見られずでした?。2夜にmrubyのワークショップ(先着50名様)↓が開催されていたことも今になって気づきました。Ishii遅ればせながら、最近ゆっくりゆっくりmrubyの構成を追っています。mrubyのコンパイラがmrbgemsの形式になっていてなぜ?と思っているレベルです。mrubyのparser.yは7000行とRubyよりは小さいものの、コードがぎっしりでビビりました。2019(nagachika)安定版ブランチメンテナーの@nagachikaさんが、バグフィックスをバックポートするかどうかをジャッジすることの難しさについて発表しました。原則は「バグフィックスはバックポートする」「パフォーマンス改善や新機能や仕様変更はバックポートしない」なのですが、きれいにトリアージできるとは限らずに悩んだり、ときにはバックポートすべきでないものをバックポートしてしまったりというさまざまな経験談に、ブランチメンテナーにのしかかるプレッシャーを実感しました。「個人的にはエッジを効かせたいけど、安定したRubyを届けたい」という言葉が思い出されます。2019(見に行けず?)少々無理やりですが、@joker1007さんのモナドパターン話と、@joker1007さんを含め多くの人が期待を寄せているパターンマッチングをここに置きました。モナドむずい...パターンマッチングのスライドを見返すと、特にJSONのようなネストしたパターンをそのままinで扱えるあたりがスゴいと思いました。今までなかったのが不思議な機能ですね。2.4から入ったコード実行されたどうかを調べるIseqLoggerを使ったり、2.6のcoverage機能を使って『コードはあるけど実際には実行されていないコード』を抽出・削除していく話。完全自動化まではいかないけれども、膨大なコードからアタリを付けて消していくのに十分な情報が得られているように見えた」でした。changesなどが紹介されていました。2019」はこれにて一区切りいたします?。コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。enno.jpを運営。実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。Storageを使ってはいけない(翻訳)#Tags#会社紹介#自社サービス#勉強会#Rails#PHP#デザイン#実績#週刊RailsウオッチCONTACTお気軽にご相談ください。(翻訳)CONTACTTechRachoでは、パートナーシップをご検討いただける方からのご連絡をお待ちしております。お気軽にご意見・ご相談ください。