表題の通り、Rubyにおけるランタイムでのdeprecated methodの自動修正についてRubyKaigi 2025で発表してきました。スピーカーとしての参加は昨年に続いて2度目ですが、昨年とは違った経験ができました。
2024年読んで印象に残った技術書
2024年に読んで印象に残った本を振り返る。
万人におすすめしたいものではなく個人的な印象深さで選んだ本です。
実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう
プロパティベーステスト手法の巧みな紹介や実例といった内容が面白いのもある。それ以上に、プロパティベーステストのRuby版のライブラリを作り、2024年のRubyKaigiに登壇するきっかけとなった本なので実に印象深い。2024年初めからRubyKaigiにかけては何度も読み直した。
（ツール開発はしばらく手を止めていたが、最近不要な機能を落とすcommitsを積んだりした）
プロパティベーステスト手法は面白い。しかしながら自分の練度の問題もあり、なかなか実践の機会を得るのが難しいと感じている。多少試してみたこともあるが「いや、これは使いどころではないな」「通常のexample based testingや他のテスト手法で問題ないな」となってしまう。
これはおそらく普段の自分が書いているコードの性質にもよると考える。特に最近の業務で書くWebアプリケーションコードであればproperty based testingに頼らずとも型やスキーマ、ビジネス要件の整理といった入力値の空間や次元の極小化のほうが効率的かつ経済的な課題解決であると感じる。逆に言えば、世界中のあらゆるプログラマが無造作に使いうるようなOSSを書くとか、不特定多数のクライアントからコールされるWeb APIを保守するとか、そういった場面でスッと持ち出せる切り札として引き続き研いでおきたい。
プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ
昨今よく使われる "認知負荷" についての整理、コードにおける混乱の種類の整理等々、経験を通じて獲得される暗黙知のようなものを認知科学的なアプローチで言語化されていてよかった。単なるコーディングやコードリーディングそのものにおける問題以外についても多く触れられていたのが良かった。
たとえば最も貴重で有限な資源である集中力を妨げる割り込みについて、専門的な研究が紹介されていた。
プログラミング作業にはウォームアップ、困難な作業、クールダウンの段階があり、いわゆるゾーンに入るというのはウォームアップを終えることを意味する。割り込みとは、これらのステップのいずれかにおいて発生し、再開時にコードに関するコンテクストを再構築するために意識的な努力を必要とするもの。割り込みは他人からのアクションで起きるものだけでなく、コーディングで詰まったときにGoogle検索するとか、ChatGPT等に相談して返答を待つとかそういった行動も含まれる。
「完璧に覚えなくてもインターネットで調べればいい」という助言はよく使われるし自分も用いてきた記憶があれば、本書によればあまりよい解決策ではない。記憶している知識があるほうがコードリーディングにおける効率性と理解の促進において圧倒的に有利だし、先述の割り込みによる作業の中断が起きにくいためである。（Webブラウザを開いてメールを見たり、チャットツールを見たり、関連する別のページを見てしまったりする経験が誰しもあるはず）
また、なんらかの初学者が概念を獲得する過程について説明する"意味波"について知ることができて良かった。一般的で抽象度の高い概念を知り、具体的な事例を見て理解を深め（アンパッキング）、異なる文脈や言語に適用するために抽象化する（リパッキング）という交互浴が必要である、と。
このアイデアは自身が今後何かを習得するときにも有用だし、オンボーディングプロセスやジュニアの育成といったタイミングでも意識したいところである。
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣
製造工学と設計工学の違いを自分の中に取り込むことができたのが大きかった。
ソフトウェア開発における製造とはビルドボタンのクリックである
我々はソフトウェア産業に製造現場の思考法を応用しようとしてきたが、それが誤りで、ソフトウェアにおいて製造は問題ではないと言い切っている。
真のソフトウェア工学は、私たちの創造力と、高品質で役立つものを自信を持って作る能力を引き上げます。アイデアを掘り下げ、創造力を伸ばせるようになり、大規模で複雑なシステムを構築できるようになります。
工学と聞くと鈍重なプロセス、平均的な人々をうまく働かせる方法、といった「製造工学を無理にあてはめようとするイメージ」を持たれることもある。しかし設計工学、とりわけソフトウェア工学はもっと個を引き上げるためにあるものだという主張に説得力を感じている。
ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。
せっかく2025年に生きているのだから、すでに見つかっている効率的/経済的な解を積極的に採用していきたいし、後進に対して高速道路を案内できるようなエンジニアでありたい。このことについてはYAPC::Hakodate 2024に参加して、個人技と工芸と工学について考えた - valid,invalidでも少し触れている。
マネジャーの実像
マネジメントは専門技術ともいわれているので技術書枠。だが同書によれば、「マネジメントはサイエンスでもなく専門技術でもなく、実践の行為であり、主に経験を通じて習得されるもの」とのことで、レギュレーション違反かもしれない。
エンジニアリングマネジメント関連の書籍も充実してきているが、より源流というか、より大きく一般的かつ大局的なマネジメントのインプットも重要だと実感した一冊。
本書ではマネジメントをアート・サイエンス・クラフトのミクソロジーと捉えており、面白いことに読者を診断するちょっとしたワークシートがある。試したところ自分はほとんどクラフト寄りであり、自己の経験の範囲内に閉じこもる恐れがあるというフィードバックも得られた。マネジャー個人がすべてを兼ね備える必要はなく、チームにおいて不足する領域を特定して補うようなアプローチが有用とのことで、チームを見つめるときの1つの観点として用いている。
この本と直接は関係ないものの読了後の思索と併せて書いた記事が以下であり、本書を少しだけ引用した。本記事が多くの人に読まれたのも印象深さにつながっている。
今なら『ミンツバーグの組織論』のほうが新しくて良いのかもしれないがこちらは未読。
まとめ
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の話はRubyとRailsがスケールすることを証明してきた会社ならではでありました。脚注でたくさん記事リンクが付いていたので、あとでそれぞれのテクニックやツールを深掘りしてみたい。eagletmtさんのRustは案外Rubyと近いというのも、面白かった。ifが式であるとかの式志向な言語は僕も好みなので2025年はRustもっと知ってみようという気持ちになれた。
イベントの感想
前回の11は僕がRubyを始めた頃で当時は存在すら知らなかった...。osyoyuさんがリブートする形で開催をキメてくれたのが12。
地域Ruby会議も地域によって規模はさまざまだと思いますが、300人規模はさすが東京。さまざまな企画やスポンサーブースや海外から招聘されたキーノートスピーカー等々、半端ない労力が透けて見えるすごいイベントでした。オーガナイザーズの労力が大変感じられる作り込みがされていて良かったです。
ニッチなポイントかもですが前夜祭のソフトドリンクに伊良コーラがあって感動しました。高田馬場から少し歩いた下落合に伊良コーラ本店があり、そちらでいただいたコーラがあまりに美味しく、僕がクラフトコーラを自作しようと思ったきっかけでもあります。アルコールに弱くクラフトビールは飲めない者としてクラフトコーラを応援しています。
また、ランチも懇親会も初めましての方々と交流できたり、お久しぶりですが出来たりした。
改めて運営や関わった皆さんお疲れ様でした！
他の大型カンファレンスとは一味違った"色"を感じるとても良いイベントでした、オーガナイザーズのみなさん運営お疲れ様でした
— ohbarye (@ohbarye) 2025年1月19日
色とは何かでいうと、若者のすべて、駆け抜けた青春の煌めき的な"何か"があった (プリ機のせいか?) #tokyorubykaigi
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した。が、調査したら思ったよりも差分がなくてびっくりした記憶がある。
4月: B/43 Tech Talk 〜「お金の使いすぎ」を防ぐ新しい家計管理機能開発の裏話〜
プロトタイピング、もっとやっていきたい気持ちで話した。諸事情あり、まだやれていないかもしれない。
5月: RubyKaigi 2024
RubyistとしてRubyKaigiの舞台に立てるとは長らく思っていなかったので、何よりも印象深かった。その他の感想は別記事にて書いたのでここでは省略する。
10月: Kaigi on Rails 2024
Data migration手法のレールがないよね、という話をした（なのでタイトルの on Rails にやや違和感を持ちつつ話していた）。4年前に調査して導入した手法を振り返る、4年前と今でのコミュニティの現状差分を見る、自分が知らないことは詳しい人にインタビューする、といった新しい要素を持ち込んだのがだいぶ好評だったようで嬉しい。
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のこと。
たった一つのシンプルな理由、見やすいから。
- https://ohbarye.hatenablog.jp/entry/2017/07/04/234737
- https://ohbarye.hatenablog.jp/entry/2025/01/11/105436
のように並んでいるよりも
- https://ohbarye.hatenablog.jp/entry/2024/10/30/kaigi-on-rails-2024
- https://ohbarye.hatenablog.jp/entry/2024/12/14/isucon14
としたほうがわかりやすい。公開時期もちょっとした概要も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年始に移行を試み、今も手探り中。
きちんと評価するために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年始に移行した。年始はお試し期間のつもりだったけど永住できそう。
- 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年の早い時期にリリースされるそう。
- https://www.pocket-lint.com/chrome-over-arc-browser/
- The Browser Company teases Dia, its new AI browser | TechCrunch
iTerm2 → Warp
macOSをメインにしてからiTerm2を長らく使っていた。が、あまり使いこなしている感じはなかったので同僚が使っていたWarpを試した。
数日使った結果、非常に気に入ったので使用し続けている。Free planだが今のところ大きな不満なし。
- ターミナルでやりたいこと、あると便利の大部分が基本機能として実現されている
- コマンドの補完
- コマンドの履歴表示と検索
- Zshをカスタマイズして実現していたことのいくつかが不要になった
- コマンド入力と出力がブロックという単位でまとめられていて便利
- 調査結果を貼り付けたり、コマンド実行結果をcommit logに入れる時などに使う
- カスタマイズしなくても見た目が良い感じ
- AI機能はちょいちょい使っている
- やりたいターミナル操作のコマンドがパッと出てこないときに聞く
- ターミナルとインテグレーションされているだけあり、Copilot CLIよりも良い所感
招待リンクはこちら https://app.warp.dev/referral/MPQYRJ
Alfred → Raycast
長らくお布施してきたがお別れした。これも同僚からの薦めによる。
- クリップボードあるので専用のアプリ (Clippy etc.) が不要になった
- ウィンドウ配置できるので (Magnet, BetterSnapTools etc.) が不要になった
- アプリ横断したグローバルなSnippets置き場もついてる
- Night Shiftのon/off toggleができる
- 賑やかしコマンド
Confettiがあって画面共有時に一段"有利" - Free planで今のところ十分
- AI機能はぜんぜん使わない
- cloud syncだけ欲しいかもと思ったことはあったが無くてもやれてる
余談：もう卒業したがDHHもmac時代はRaycastユーザーだったようす。
Two macOS apps I wish I'd known about earlier: https://t.co/mOdaSYCFdu and https://t.co/rtmJdxUG1g. Together they make navigating the computer via keyboard so much easier and faster. Very good. Both are free.
— DHH (@dhh) 2023年12月16日
Bartender → Ice
macのメニューバーを綺麗に整理・カスタマイズできるアプリケーション。
Bartenderを長らく使っていたが開発元が変わった時の問題をうけ、代替アプリに乗り換えていた。
(なし) → NearDrop
乗り換えではなく新規導入
AndroidからmacOSにファイルを共有するときにiPhoneのAirDropみたいにできるやつ。便利
類似の目的で、過去の同僚に教えてもらったPushbulletも併用している。
Docker for mac → OrbStack
速すぎる。当初はいろいろスカスカな状態だからか？と疑っていたが1年以上使っている今でも圧倒的に速いし、省リソースで安定して動く。
独自のファイルシステムでシステムコールを削減していたり、賢い動的メモリ管理によって必要な分だけメモリを割り当てたり未使用メモリを自動的にmacOSに返却しているらしい。
Pro planを使っているがDocker for macの代替以外の機能はほとんど使っていない
上記の移行したツールの中でも最も新鮮に感動したのはやっぱりCursorだった。
開発関連のツールについてはレイトマジョリティの自覚ありで、同僚の推薦などによりtrial開始することが多い。昨今の技術的進歩の中、フットワーク軽く色々試していかないといけない気持ちはある。
ISUCON14 ソロで参加して19131点 (50位) だった
ISUCON14 ソロで参加して50位 (19131点) でした。
はじめに、開催してくださった運営の皆さんありがとうございました。解きがいのある素晴らしい作問、当日までの案内・サポート、ベンチマーカーのスムーズな実行など全てを通じて一切の不満なく楽しめました。
結果
- 最終スコア: 19131 (50位)
- 最高スコア: 21394
- 使用言語: Ruby (言語別ランキングでは4位)
- ソロ参加だと何位ぐらいなんだろう
ISUCON11ぶり、3回目のソロ参加。まだまだ伸びしろはあるものの最もまともに戦えた回だった。
使用したツール
- Vim
- サーバで直接編集するとき
- RubyMine
- コード編集するとき
- DataGrip
- データ見たりSQL書いたり
- alp
- 今回初めて使ってみた
- mysqldumpslow
- top
- git / GitHub
テーブルやカラムにコメントがちゃんと付いていてありがたい。DataGripマジで良くて、Copilot等がスキーマから補完を効かせてくれたり、Copilot Chatでクエリ相談を投げたりしていた。
戦略
1人なので時間は絶対に足りない、という前提のもとフォーカスするポイントは決めておいた。
- 1台構成でできるところまでやり、行き詰まったら複数台構成に挑戦
- アプリケーションのすべての仕様を理解しようとしない
前回は素振りしてないツールや技術は使わない方針でやったが、失敗しても誰に迷惑かけるわけでもなし、好きにチャレンジしても良いだろうということにした。
振り返り
Good
- top, mysqldumpslow, alpを見ながらやるべきことの優先度をつけられた
- ベンチマーカー走行結果のユーザーの不満を見ながら改善のアイデアを検討できた
- 午前中の早い時間にスコアが伸びなくても焦らずに進められた
- 15:00ぐらいまでは順調に伸びて10位以内につけた
More
- 1台構成でスコアが伸び悩んだ後、複数台構成への切り替えが最後までできなかった
- isucon_matcher.serivceの停止忘れでベンチマーカーが落ちるようになっていた
- 感想戦でアプリ1台、DB 1台に切り替えただけで34556まで伸びた。これは悔しい
- テーブル構造をまったく変えずにやったが、非正規化で頑張っても良かった
- よく使うコマンドをsnippets登録しながら実行したがMakefileにすればよかった
[おまけ] 競技時間内にやったこと
[10:00-11:00] 環境構築: 999
[11:00-11:50] 状況把握
アプリを触って仕様を把握したり、ボトルネックがDBぽいなとか、notifications APIへのリクエスト数やばいなとか
コードの構成をざっくり把握
[12:18] インデックス追加: 2193
テーブルの関係が把握できたので、mysqldumpslowから判断して明らかにインデックスが足りてないところに追加
一般に外部キーがあるべきところとか
[12:43] retryを1000msに: 5811
変更箇所が漏れていてretryが30msのままだった。ちゃんと1000msにした
2000とか1500とかいろいろ試したが1000がこの時点では妥当と判断。27位
[13:24] owner/chairのクエリを微改善: 7660
一番重いクエリの改善。キャッシュしてもよかったな
[13:29] マッチングのポーリングを500msから100msへ変更: 10679
マッチングに不満があるという走行結果に着目し、設定を変更
ここからしばらくマッチング改善
[14:00] マッチングアルゴリズムを改善したはずがdown: 4502
[14:49] いろいろマッチング改善: 15810
- speedも考慮して最短でピックアップできるisuを優先してマッチング
- マッチングAPIコール時に1件だけ処理するのではなく、待っているrides全てを処理するようにした
[14:55] いろいろマッチング改善: 15810
目的地までの到着が最も速いisuをマッチングするようにしたがあまり変わらず。ボトルネックがここじゃない感がでてきた
[15:13] /api/app/nearby-chairs を改善: 14582
API内のN+1やクエリ性能を改善したがあまり変化なし
このあたりでDBを別の台にしようとしたりアプリの複数台構成を試したが、ベンチマーカーが通らずダメだったので諦める
[16:28] マッチングのクエリがちょい重いのを改善するためindex追加: 16178
[16:43] nearbyのN+1を潰したがマイナス。revertする: 13763
2時間近くスコアが動かず手詰まり感が出てくる
[17:32] pumaの設定を5:5スレッドにした: 18248
曖昧に試して回る
- 0:8だと16000
- 3:3だと11688
[17:49] mysql log, nginx log, sinatra logをオフ: 19251
[17:52] notificationsのretryを1000ms -> 500ms: 19950 -> 19131
250msにしたら17000ぐらいにさがったので500msが最適と判断
このときのベンチ結果が採用されてたらRuby 3位だったので悔しい
Note
- 作業メモ ISUCON14 - ohbarye
- alpの設定は ISUCON初心者向け講習会 | ISUCON初心者向け講習会 を競技中に見ながら学んだ
