RubyKaigiのLTがペパボに来てから初めての発表だったんだけど、そのときに作ったKeynoteのテーマを公開していたのだった。
ポイントとしては、
というくらい。さすがデザイナーさんが選んだ配色だけあって、それっぽく見えるのでおすすめです。
ペパボ after school っていうLT大会があるとのことで、せっかくなので見積りと計画づくりについてLTをしてきた。
資料は置いておくけど、だいぶ雑な感じなのでつっこみはおてやわらかに……
ちなみに、脈略のない写真がはさまっているのは、いきなり最初の人がブロッコリーについての話をはじめたので、真面目トーンだとだめか！とあわてて入れたでこんなかんじになっている。
各プロジェクトで、見積りや計画づくりをするときのヒントになればよいなーと思っております。
unicornに代表されるprefork(する)サーバでは、DBへのコネクションのような各プロセスで共有してはいけないリソースをbefore_forkとafter_forkで適切に管理する必要がある。
ふつうのRails Applicationは以下のように、ARのコネクションをはりなおしていると思う。
before_fork do |server, worker|
ActiveRecord::Base.connection.disconnect!
end
after_fork do |server, worker|
ActiveRecord::Base.establish_connection
end
しかし、Octopusを使っている場合はこれだけでは不十分で、このままだと再起動直後にエラーが大量に出ることになる。今関わっているプロジェクトではNoMethodError: undefined method 'query' for nil:NilClassというかんじで、ARの@connectionがnilになるという問題が多発していた。
after_fork do |server, worker|
ActiveRecord::Base.connection_proxy.instance_variable_get(:@shards).each {|k,v| v.clear_reloadable_connections! }
end
というかんじでafter_forkでだけclear_reloadable_connections!というメソッドを呼べばいいよ、ということになっていた。
@shardsというインスタンス変数に、すべてのAR::ConnectionPoolがはいっている
というかんじである。
で、実際はこれだけでも例外はでなくなったのだが、再起動が異様にもっさりするようになったので
before_fork do |server, worker|
ActiveRecord::Base.connection_proxy.instance_variable_get(:@shards).each do |_, c|
c.disconnect!
end
end
というかんじでbefore_forkでdisconnectはするようにして様子を見ている。(これだとストレスがなかった)
Octopusの動作を完璧に理解するには、沢山のスパイクをしたり、ソースコードを読みまくらないといけない。(つらい)
みんながそんなことをしなくてもいいとは思うので、よくある問題の一つである「意図しているDBにクエリが飛んでいない」というのをデバッグするために、DBの接続先を判断している部分のポインタを置いておく。
原因がよくわからないときは、最小の再現コードを書いてこの部分にbinding.pryして動きを追ったりしている。
tchandy/octopus lib/octopus/proxy.rb#L260
def method_missing(method, *args, &block)
binding.pry # ココをひっかける
if should_clean_connection_proxy?(method)
conn = select_connection
self.last_current_shard = current_shard
clean_connection_proxy
conn.send(method, *args, &block)
elsif should_send_queries_to_shard_slave_group?(method)
send_queries_to_shard_slave_group(method, *args, &block)
elsif should_send_queries_to_slave_group?(method)
send_queries_to_slave_group(method, *args, &block)
elsif should_send_queries_to_replicated_databases?(method)
send_queries_to_selected_slave(method, *args, &block)
else
select_connection.send(method, *args, &block)
end
end
なんと、Octopusは実際にクエリ投げるメソッドを横取りするためにmethod_missingを使っている。だいたいのSQLの実行はここを通るので、ここをひっかけるのが一番楽だと思う。
逆にここにひっかからない場合は、Octopusが独自に実装している何らかのメソッドを経由しているのでそれはそれで調査が捗る。
このif-elseの条件のどこにはいって、その先のDB接続先の判定をするメソッドがどう振る舞うかを見ると、「あーなるほどね」となることがけっこうある。
複数DBとの戦いの記録 で見つけたラウンドロビンに関する意図しない挙動も、これで見つけたのであった。
今夜の 複数DB Casual Talks 、盛り上げてこ!!1
WEB+DB PRESS Vol.83を一通り読んでみた。
Zshの特集とRubyのアプリケーションサーバの選択が身近で勉強になったのと、画像認識とWebP、負荷テストの話は長い目で勉強したいトピックなのであとでゆっくり読み直そうかなという感じ。
特集1のチームの話は目新しい話はそれほどなかったけど、多能工星取表とI messageのところがよかった。
最近のチームビルディングでは、毎回ドラッカー風エクササイズをやっているんだけど、それに近い話ではあるけど、より具体的にメンバーのスキルが把握できて、かつ勉強したいポイントがわかるというのはよさそう。
I messageは、本書の中でもあるようにまどろっこしい所があるので、実際に使うというよりはネガティブなフィードバックをする前に、一度おちつくためのツールくらいで使うのがよさそう。
今号もすぐに使える物から、末永く使える基礎的なトピックまで勉強になりました。
(11/8に公開しました)
無事3ヶ月の試用期間が終わり、正式採用となりました。
そんなこともあり、今日はあんちぽさんと最近どうっすかのお話をしたりしたのでした。
先月くらいからは、大きめの新規開発の立ち上げを支援を中心に、昔取った杵柄を活用して原因がわかりにくいバグの修正とか、革新的ソフトウェアのアイデアが振ってくるのを待っていたりしてる。
リーンキャンバスの作成、見積りと計画作りに口を出しながら、チームビルディングの支援や、アーキテクチャを一緒に考える、ふりかえりやディスカッションのファシリテート、というあたりをやっています。
今までは1参加者としてやっていたのを一歩引いてやるってのは思ってた以上に大変ですね。
コードをばりばり書いて問題を解決するって感じではないのだけど、今までの経験を生かして、開発チームが自信を持ってリリースできるように支援しております。
これはあとでちゃんとまとめたいな。
上記の新規プロジェクトに関連している既存のアプリケーションで、Octopusを使ってレプリケーションに対応しているものがある。
このアプリケーションに、パフォーマンスの問題があったり複数DBに関連するバグがあったりするのでこれを直したりしている。
ここは、完全に某プロジェクトでOctopusをプロダクション投入するために色々調べた経験が生きて、Octopusの影響がありそうなところ潜って原因となるメソッドを特定して、ドメインの知識を他の人に補完してもらって直す、みたいな感じで進めている。
imlib2は高速で省エネなんだけど、画質という観点からはおせじにも褒められたものではないので、パフォーマンスを落さずにImageMagickに移行できないかと挑戦している。
おかげで、ImageMagickのオプションにはだいぶ詳しくなったし、本番に出してからサーバのロードアベレージが急上昇してすぐRevertするという通過儀礼を受けた。
そういえば、前職でもMySQLのクエリがいけてなくて辛い思いをしたのを思いだした。
サーバのプロビジョニングとかは、今までせいぜいローカルのVMを作るとか、借りてるVPSで遊んだりしていただけだったので、始めて本番サーバまで含めたサーバの運用というのを間近に感じられている。
自分にとては未知の分野だし、さらにホスティングをやっているという会社ということもあって、インフラエンジニアの教科書に載っているようなことを実際にやっている同僚がいるすごく刺激的な環境だと思う。
AEP読書会 - 第十五章「イテレーションの長さを決める」に参加して15章のまとめを発表してきた。
資料はこちら AEP読書会:15章「イテレーションの流さを決める」
いい議論がたくさんあったんだけど、いかんせん乾杯からスタートなので殆ど覚えていないのであった。(用語がブレているのは御愛嬌)
こんなかんじで、どんどん突っ込みや、自分たちはこうしてる、みたいなのが議論されながらすすんでいくので、雰囲気があう人はすごくたのしい読書会だと思うし、だいぶ勉強になると思う。
次回は忘年会の季節では?という感じなのでまた参加しよう。
新人向け座学で、ひさいちくんがコードレビューの話をするとのことだったので隣で聞いていた。
資料はこちら > コードレビューの話 by hisaichi5518
言語化しにくいところがよく言語化されていて勉強になりました。
終わってからの、hsbtはどうやってんの？という話が興味深かった。(だいたいこんな話だったと思う)
:-) こういうやつはニュートラルだからおすすめふむふむーたしかに大事だなーと思って聞いていた。
で、不意にこっちにも振られたので、最初は「これ以上はとくにないっす」と答えたんだけど、考えなおして最後に言わせてもらったのは
これは、特に転職してすごく思ったんですよね。(昔は各所にご迷惑かけたかと思いますが…)
ひさいちくんのスライドにもあるように、文字ベースのコミュニケーションでは感情の表現が欠落してしまうので、お互いが余計なダメージを受けないように、各自自衛しないといけないと思うのですよ。
とはいえ、やっぱり意識高い状態じゃないとそういう配慮や意識もできないので、まずは意識を高めてがんばろうということになってしまうんだけど、最低限、レビュアーとレビュイーは対等であり、そのコメントやコードの向こうには血の通った人間がいるのだ(そしてその人は仲間である)、ということを忘れなければなんとかなると思う。
HRT大事！みたいなポエムになってきたのでここで終わり。
Rails 複数DB Casual Talks が一瞬で定員になるほど世の中は複数DBの知見に飢えているようなのですが、登壇を若者にまかせることができてよかったと思っていたのも束の間、お仕事では複数DBではまっていた。
ようやく問題の一つを解決できたので共有しておきますぞ。
Octopusには複数のslaveをラウンドロビンで使う機能があるんだけど、これがちょっと理解できない挙動をしていて
Octopus.using(slave_group: :my_slave_group) do
User.count # my_slave_groupのslaveに行く
User.count # masterに行く!!1?
end
というかんじで、2つ目以降のクエリがmasterのDBに行ってしまうのであった…
さすがにこれは多くの人が期待する動きではないと思うんのでうまいこと直したいなぁ。だいたいの原因はわかってるんだけど、どう修正したもんかなーという気持ち。
とりあえずすぐ再現させられるので、我こそはという人は直してくれるとすごく嬉しいです!
ミラーレス一眼買ったはいいけど、ほぼ本体だけ買った状態だったのでいろいろ調べたり、有識者に意見を頂いて、メンテナンス道具を購入した。
買ったのは
の3種類で、とりあえずこれだけあればいいよって感じみたい。
液晶保護フィルム撲滅運動をやっている自分としては、レンズプロテクタの意味についてかなり懐疑的ではあったんだけど、一番外側のレンズのコーティングを保護するというのと、掃除が楽になるというところで納得して購入したのであった。(有識者の皆さんありがとうございました)
で、本体以外もいろいろ買うものがあるのでだいたい5,000円くらいは余分に見ておいたほうがいいなぁというのが感想です。
朝から場所とりをしたり、写真をとったり、長縄の縄を回したりしていた。
肝心の写真の方は、一番肝心な「かけっこ」の写真はほぼブレていて、社会の厳しさを感じた。
正面から向かってくる被写体を撮るの難しいです…
年長さんの競技を練習台にいろいろ撮ったので、たぶん来年はいけるはず！
一日の中でも少しずつは上達したような気がするのでよかった。
ひどい写真を忘れないようにインターネットに置いておこうかと思ったんだけど、後ろの方の人に完全にピントがあってしまっているので心の中だけにしまっておきます。