ISUCON10 に続き今回の ISUCON11 でも初期実装の Rust 移植を担当したのでそのへんの話を書いてみます。 ISUCON とのかかわり ISUCON4 から ISUCON7 までは選手として参加していて、何度か本選にも出場しました。ISUCON8 以降に参加しなくなった理由はいくつかあるんですが、Web のインフラやバックエンド界隈を盛り上げて学生の興味を惹く素晴らしいイベントだと思っています。そんなわけで ISUCON からはしばらく離れていたんですが、ISUCON10 では同僚が作問するということと新たな試みとして初期実装に Rust を加えると聞いて、Rust 移植担当に応募して採用されました。そして今回の ISUCON11 でも Rust か Ruby の移植に応募し Rust の移植を担当しました。 言語移植を担当するモチベーション 自分の場合は ISUCON が

まとめ netlify_lambda を使う Lambda の Docker イメージサポートを利用する aws-lambda-rie-gateway を使う この構成で Slack の interactive message や block kit で遊んだサンプルがこれ https://github.com/eagletmt/misc/tree/master/rust/slack-slash-command-sample Rust 向けの Lambda Runtime lambda-runtime という準(?)公式の crate がある https://github.com/awslabs/aws-lambda-rust-runtime が、リリースが滞っている。 現在リリースされている中での最新版では async/await の対応すら入っておらず、現在の Rust では正直使い物

自分の中でなんとなく納得がいっただけでとくに結論は無い。 そして今年ここに全くエントリを書いてなかったことにいま気付いた。 ふとしたきっかけで発表するのを好む人の気持ちが気になった。その人は発表スライドだけ見ても話の内容が十分に伝わらず、その場のトークと資料が合わさって初めて成り立つような発表をするタイプのように僕には見えた。その人に限らず、こういうタイプの人はまぁ普通によくいると思う。 一方僕は真逆のタイプで、スライドだけを見てもそれなりに伝わるものを作りがちだ。スライドを読み上げてるだけじゃんという意見も目にしたことがあるけど、実際その通りで口頭で発表するよりドキュメントやブログ記事を書いて公開したほうが良いと思っていて、発表というのはまぁ宣伝効果があるとかそれくらいにしか思っていないところはある。 で、なんで自分はそう思ってるんだろうと考えてみると、受け手側が参照するコストをできるだ

ISUCON7 予選に†空中庭園†《ガーデンプレイス》として @ryot_a_rai、@mozamimy と参加して2日目1位で通過することができた http://isucon.net/archives/50956331.html 。 リポジトリは https://github.com/ryotarai/isucon7q 当日まで 例年 Ruby で参加していたけど、今年は発表された初期実装に Ruby が含まれていなかったこと (※後から追加された) もあり、@ryot_a_rai から Go で参加したいという話が出て Go を選択した。 僕と @mozamimy は Go はまぁまぁ書いたことはあるくらいの状態だったので、事前に一度 Go で練習したり pprof の使い方を教えてもらったりしていた。 Go は個人的にはあんまり好きになれなかった言語ではあるんだけど、ISUCON で

params の中身のように入っているオブジェクトのクラスが事前に分からないものに対して空っぽい文字列の場合と存在しない場合を区別したくないときに限って blank? を使うのは分かるけど、 nil チェックをするために blank? を使ったり、配列が空かどうかをチェックしたいだけなのに blank? を使ったりすると、 blank? の挙動を正確に理解して nil と空配列を区別したくないから使っているのか、それとも nil がくるかどうか分からないので適当に防御的に blank? を使っているのか、 あるいは blank? しか知らないのかが読みとれずにめんどくさいと思うことがよくある。 かわりに empty? を使っていれば empty? を持っているオブジェクトは blank? を持っているオブジェクトより少ないので読み手に伝わる情報量が大きくなるし、 かわりに nil? を使っ

前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら