まっしろけっけ

めもてきなやーつ

Rails に contribute する実績を解除した記念

はじめに

Rails を使い始めて 8 ~ 9 年くらい?経つのだけれど、なかなか機会が無く contribute 出来ていなかったがやっと出来たので記念に残しておく

内容について

github.com

こちらの PR なのですが、このバグを踏んだ経緯から説明します。

副業でお仕事をしているのですが、dalli の version up を行った時のことです。
dalli は v3.0 から大幅な変更が加えられており、独自で実装していた DalliStore という session store から Rails 標準の MemCacheStore 経由で Dalli::Client が呼ばれるという方式に変わりました。

PR をみてもらえればわかりますが、このバグは Dalli を v2.x から v3.x にあげたときに DaliStore(dalli v2.x) で memcached に格納されたデータを MemCacheStore 経由で read_multi を使って取得するときに発生するものになります。副業の方では read_multi で指定している key が 2 つしかなかったことから fetch で取得する方法に変更してこのバグを回避したのでお仕事としてはこれで終わりだったのですが、どうしてもこの解決方法に納得できず昼くらいに解決したけど夜までモヤモヤが残っていました。

モヤモヤの原因は Rails と Dalli どちらを修正するべきなのか?の判断が難しいものだったからで判断しかねていたので MemCacheStore の過去の PR で Dalli 関連のものってないのかな?と思い調べました。

それで辿り着いたのがこの PR でこの PR が取り込まれているということは Rails でもある程度 Dalli を利用した際の挙動について担保しておくということなのでこの PR を参考に test を書いて、該当箇所を修正したという感じ

最後に

最近は OSS 活動バグがあったら PR 出す程度しかしてないけれど Rails へ contribute できて嬉しかったので記念カキコ

最終出社

はじめに

本日 12/28 日が 6 年 6 ヶ月勤めた GMO ペパボの最終出社になります。とかいてますがこの記事を書いてるのは 27 日で公開したのは 28 日 0 時なのでまだ最終出社してません。1,2 月は有給消化になり 3 月から次の会社で働きます。

ペパボでの 6 年半の話

やったことなど

EC の API を開発するところから始まり 2 ヶ月ほどで minne に異動してきた後は、カオスだった API 開発に秩序をもたらしたり Solr から Elasticsearch への移行を行なった。その後検索周りの改善などもしていたら Apple Pay のローンチパートナーになったのでそれ関連の開発をしていた。

Apple Pay が落ち着いたあたりで EM に任命され EM 業をやりながらマイクロサービス化や k8s への移行、その他にもインフラとバックエンドを軸に様々な改善をしつつフロント周りも少し開発したりなど楽しく開発してきた。(正直多すぎて覚えていない...)
minne のメインとなるリポジトリの追加行数より削除行数の方が 1.4 倍くらい多かったのは割と気に入っている。

やってきたことはこのブログや SlideShare / Speaker Deck にも書いてあるので詳細はそちらを

おもしろイベントなど

(URL は載せませんが)企画でお見合いをしたりジョージアの web CM に出たりと色々なおもしろ体験をさせて貰った。
また、上でも書いたが Apple Pay のローンチパートナーになったおかげ(?)でちょっと特殊な状況で開発したり Apple の製品ページで minne の画面を継続的に使って貰えたりなどもあった。
普通に生きてたら(?)体験できないことだったので良かった。

評価など

(今は知りませんが)前職が新卒超優遇評価だったので、フラット且つオープンな評価制度で良かった。
入社する時は(誰にも言ってなかったが) 1 年でシニアエンジニアになれなかったら辞めるという強い気持ちで入社し、ありがたいことに評価していただき 1 年でシニアエンジニアになることができた。
その後も半年後には CTL となり、等級と名称が変わり SEL になるなどちゃんと評価されてきたと思う。数年前に評価制度が変わってからは(相対評価ではないものの)密かに SEL の中で一番いい評価を取り続けるんや!という気持ちを持ちながら仕事をしていたし実際に辞めるまでそういう評価を貰った。(バリューを出せばちゃんと評価してくれるので同じ職位の中で一番バリューを出すというような意味で)

今年 5 月くらいからはシニア・プリンシパルとして活動していた。

お金など

評価の項目にも書いた通り、割と順調に職位を上げてきたのと数年前に 200 万アップの件もあり入社当初から比べると倍以上になった。

総合的に

総合的な話をすると、ペパボで働いて正解だったなと思う。優秀で尊敬できるエンジニアも多いし、某ライバルのエンジニアとは同い年ということもあってか切磋琢磨してこれたのではないかなと思う。また既にやめてしまっているが同じ部署で CTL を一緒にやっていたエンジニアと一緒に仕事をしていた時期が僕は一番楽しかった + 色々な面で学びが多かったと感じれる時だった。

居るだけで成長できる環境をうたっていますが(今もうたっているっけ?)正確には居るだけで(皆に平等にチャンスがあり、それを掴みにいき成果を出せれば)成長できる環境があるっていうのが正解なのかな?ってのが個人的な気持ち。なのでちゃんとチャンスで手を挙げる勇気と覚悟を持て、それを放り出さずに周りの力も使いながら成果を出す自信がある人にはオススメかなって思います。


それじゃ、なんで辞めるんや?という話ですが特に面白い話でもないので直接聞いてくれれば答えます。

さいごに

はじめにも書きましたが、3 月から次の会社になります。どこか?は働き出して少ししたら書くと思います(が給料は 2 割くらい上がりますとだけ書いておきます)

1,2 月は有休消化で暇なので最後に例のリストを貼っておきます。

Amazon.co.jp

ISUCON に初参加

はじめに

ISUCON is 何?という人は下記を参照

isucon.net

過去も何度か出たい〜と思っていたのだけれど、だいたい予定と被ってて無理じゃん...となること数回...初参加を果たしたのであった。
チームは社内で募集している人々がいたのでその人々と参加した。

反省など

初参加だったので事前準備などはせずに臨んで見るか〜と思って過去問などはやらずに挑んでみた。

初めて触るアプリケーションってなんであんなに楽しいのか...楽しすぎて夢中になってしまい本来の目的を忘れてしまっていた感も若干ある...

反省としては

  1. レギュレーションは最初にちゃんと読んで理解すること
  2. チームメンバーの役割を明確にする

あたりが大きいやつかな〜という感じ
ベンチマーカーの仕様とかを理解する以前にあーでもないこーでもないみたいなの初めてしまったのは本当に失敗...朝だったので日本語から逃げたかったというのもあるけど... 15 ~ 16 時くらいに理解し出してなるほど〜(完全には理解していない)となり、イジっていったらスコアが伸び出したという感じでここからや〜というところで終わってしまったのであった...

最後に

次回も出たいし、今回の解説とかはまだみてないので見ないでもう一回自分でアレコレやってみてから解説などを見てアレコレしたい。

楽しかったので出てよかった。

GMO アワード 2021 にノミネートされてた話

はじめに

だいぶ時間が経ってしまったのですが GMO アワード 2021 というものにノミネートされていました。
is 何?という人は下記を参照

hr.pepabo.com

感想など

前職でも似たようなものは存在していて自分とは無縁と思っていたのでこういうのにノミネートされるのは素直に嬉しいという感想

また、ペパボからの過去のノミネート者を見ても @hsbt@matsumotory など尊敬するエンジニアが名を連ねているので選んでいただけたのはありがたいな〜という感想とまだ自分は先にあげた二人と肩を並べるほどのエンジニアではないので頑張っていかんとな〜と思うなどした。

最後に

という記念カキコでした

DeployGate のアカウントを PullRequest ベースで管理したい

はじめに

DeployGate is
deploygate.com

会社で使ってたりするとアカウント管理とかが大変ですよね。退職したらその人のアカウント消したり、気づかないうちにカオスになってしまうことも....

そんなカオスな事を出来るだけ回避したいので Github などで PullRequest ベースでアカウントの追加/削除ができるとちょっと嬉しい気がします。Enterprise プランであれば SAML が使えるのでそれでも良いと思います。

yaml でユーザを管理する

使う gem はこちら

gem install deploygate-client

これは元同僚の Android エンジニアがまだ一緒に働いてた時に「API とかあるならコードで管理するようにしたら?」と言ったら作ってたやつ。結局コード管理するまで至らずに退職しちゃったんですけどね...

まずは既存のアカウント一覧を yaml に吐き出す。

require 'deploygate/client'
require 'json'
require 'yaml'

org_name = "管理したい org"

client = Deploygate::Client.new(token: ENV['DEPLOYGATE_TOKEN']) # 環境変数の DEPLOYGATE_TOKEN にトークンを設定する
response = client.organization_members(org_name: org_name)
members = JSON.parse(response.body)["members"].map { |val| val["name"] }

YAML.dump({members: members}, File.open('members.yaml', 'w'))

これで members.yaml に既存のアカウントが書き出される

次は yaml に書いてあるアカウントを DeployGate 側に反映される。

require 'deploygate/client'
require 'json'
require 'yaml'

org_name = "管理したい org"
dryrun = ENV['DRY_RUN'] # 環境変数で DRY_RUN を設定するとアカウントの増減はしないで変更予定の出力だけ得られる

client = Deploygate::Client.new(token: ENV['DEPLOYGATE_TOKEN']) # 環境変数の DEPLOYGATE_TOKEN にトークンを設定する

response = client.organization_members(org_name: org_name)
api_members = JSON.parse(response.body)["members"].map { |val| val["name"] }

yaml_members = YAML.load_file('members.yaml')["members"]

add_members = yaml_members - api_members # yaml に書いてあるのに DeployGate に存在しないアカウントは追加したいアカウント
delete_members = api_members - yaml_members # yaml に書いてなくて DeployGate に存在するアカウントは消したいアカウント

add_members.each do |member|
  puts "add #{member}"
  client.add_organization_member(org_name: org_name, user_name: member) unless dryrun
end

delete_members.each do |member|
  puts "delete #{member}"
  client.delete_organization_member(org_name: org_name, user_name: member) unless dryrun
end

こんな感じでこのコードと members.yamlGithub で管理して Actions などで master に merge されたタイミングで実行するようにすれば PullRequest ベースで管理できるようになります。

エラー処理とかは特に行なっていない(ネットワークエラーとかで更新失敗しても再実行すれば yaml と同じ状況にできるので)

最後に

deploygate-client よくできてる。

Istio を利用して HTTP Request 時に問題があったら retry してもらう

はじめに

Istio is
istio.io

service mesh の一種で色々な事ができるので上記参照(雑)
内部的に envoy を使ってたりする。

今回やる事

特定の pod から別の pod にアクセスする際に稀にネットワーク的な問題で繋がらなかったり、アクセス先の pod が高負荷でたまたま処理に失敗するなどが発生する時がある。

そういう時に pod で動いているアプリケーション側で retry の機構を実装する事も可能なのだけれど、外部との通信で毎回書くのはダルかったりコードが複雑になったりするわけなのでそれを service mesh 層でやってもらおうという作戦。

Retry してもらう

istio の install などは省きます。

設定方法はここにそのまま書いてあるのですが実際に動作確認したいよねとなるので動作確認用のアプリケーションを書いたのがこちら

main という web アプリケーションから sub というアプリケーションに Request を送るだけの簡単なもの

deployment にはまだ istio-proxy 等が追加されていないので apply する際は追加してあげる必要がある

$ istioctl kube-inject -f manifests/deployments.yaml | kubectl apply -f -
$ kubectl apply -f manifests/services.yaml
$ kubectl apply -f manifests/virtual-services.yaml

これで準備終わり。別の pod から curl http://istio-example-app-main-svc:9080/ を打つとこの設定だと普通に Response が受け取れるはず。

sub のアプリは 2s sleep 後に Response を返す実装なので VirtualService の設定の timeout を 2s 以下に変更する。
変更箇所はここ

$ kubectl apply -f manifests/virtual-services.yaml

この状態で curl http://istio-example-app-main-svc:9080/ すると upstream request timeout となり Response が受け取れません。
なぜかというと istio-proxy が VirtualService で設定されている perTryTimeout で設定されている時間で一旦接続を切り attempts の回数分再度同じ Request を行なっているからです。

この様子をログで確認する方法は下記

$ kubectl logs -f main-pod istio-proxy
$ kubectl logs -f sub-pob istio-proxy

これで Response Time によって Retry を設定する方法がわかったので次は HTTP status などによって Retry する設定です。
これはここの retryOn で設定ができます。

どういう設定を書けばいいのかは envoy の docs に書いてあります。

動作確認をしたい場合はこちらを使用して上記と同じ手順を辿れば確認できます。

最後に

今回紹介した機能以外にも istio にはいっぱい機能がある(ありすぎる)ので何かしらの課題を解決する為に導入してみるのも良いかと思います。

シン・エヴァンゲリオンの感想と自分語りと(ネタバレあり)

ネタバレがあるよ気をつけて










3/10(水)仕事の深夜メンテが終わり 2 時間半ほど寝た後にエヴァの最後を見に行った。あまり寝てないので途中で寝ないかすごく心配だったがそんな心配は杞憂だった。エヴァを見始めてから二十数年TV/旧劇/漫画版と見てきたが今ではうろ覚えな部分もある。終わってしまうのか〜悲しいなという気持ちが強かった気がする。

映画館に座り、上映が始まるまでにフォースチルドレンを首になった彼は死んでまったのかな?(妹はでてきたけど)などど考えながらまっていた。真っ暗な画面から歌謡曲が聞こえすぐにマリだと気づく坂本真綾ファンなのでこれを聴くためにシンエヴァを見にきたと言っても過言ではない。冒頭10分は一年半前くらいに公開された時にすぐ見たので記憶が曖昧だったもののこんな感じだったな〜という感想。

その後シンジたちに場面が切り替わるが、すぐに上映前に死んだのかな?とか思ってたトウジが出てきてなんかすまん...となった。トウジ/ケンスケ共に 28 にしては考えがしっかりしすぎていて見た目的にも老けすぎでは?とも思ったが、トウジが言っていた「お天道様に顔向けできないこともした」という発言からもいろいろな苦労をして実年齢以上に精神年齢が上なのだなと思った。後ケンスケのキャラデザなんか加持さんに似てないか?とも思った(加持さんのような見た目と加持さんのような大人の余裕からアスカは惹かれたのかなと終盤のぬいぐるみから出てくるところで気づいた)

ここからはアヤナミレイが人間性を得ていく場面、綾波が周りの影響を受けて成長(?)していく場面は他のシリーズでもあったいい場面だよなと思ったがちょっと長いなとも思った。その間シンジくんはずっといじけてるし、アスカはそんなシンジくんに冷たい態度をとりつつ心配していてほんとツンデレで可愛い。
その後アヤナミレイが消えたことでシンジくんは立ち直るのだが今まで散々いじけてたのに急すぎないか?とは思った。その後もケンスケは相変わらず優しすぎるしいい男すぎないか?

ケンスケに連れられてミサトさんの子供の加持くんに会うことになるのだけれど、ここら辺から割とずっと泣いていた気がする。ミサトさんと加持さんの過去作での関係とかも思い出したら一時でも幸せな時があったんだなと思ってしまった。

シンジくんはヴィレに戻りヴィレの面々は南極に向かうわけですが、ここで出てくるのが冬月先生。冬月先生毎回損な役回りばかりじゃないですかね...いい人すぎるでしょ...

アスカとマリが出撃する直前にシンジくんの元に寄ることになるんですが、この時のマリの行動がそのままエンディングに出てくるんですよね。アスカはシンジくんと答え合わせをして好きだったと伝えるんですがここでやっと Q のときにキレていた理由を視聴者は知ることができるわけです。好きだった男が自分を助けようともせずに駄々こねてたらそりゃ切れるよな〜。
更に出撃後にはなぜ 3 号機と一緒に使徒に侵食されたはずのアスカが人として存在できているか?という謎も判明しましたね。変な棒便利!

その後リツコさんがゲンドウを撃ったり(いいぞもっとやれと思った)、ミサトさんがシンジくんを庇って打たれたりがあり皆んなやっぱりシンジくんを心配してる(もちろん心配している反面憎んでもいる)優しい世界だったんだよかったとなった(じゃなきゃ Q 時点でミサトさんがシンジくんのこと殺しててもおかしくないしね)シンジくんのプラグスーツを保存しておくくらいだしね。ヴィレの皆んなも新しい槍をシンジくんに届けるために協力してくれるのが良い。これだから若い男はって言われたい(若くないけど)

その後シンジくんは初号機に戻るんですが、そこで髪の長い綾波レイが座っているんですよね。この髪が伸びているというのはシンの中盤でアスカの髪をマリが切ってあげる場面と通じていると思っていて、この時アスカは「こんな体になっても髪は伸びてうざい」と言った愚痴を言うんですが、マリは「まだ人間であることの証拠だよ」的なことを言って諭すというやりとりがあります。アスカのように綾波もあんな姿ではあるものの人間としてシンジくんを待ち続けたということなのかなと...ニアサーのときに救えなかったと思っていた綾波をちゃんと救えていたんだねよかったねと思って泣いた。

終盤はスタジオを撤収していく演出によって世界をいったん畳んで作り直すというのを表しているはずで、その中でシンジくんとゲンドウは初めて向き合って会話をすることになるんですが、この時のゲンドウの内面にとても共感してしまった。さらに僕自身が親のことを好きではなく、特に親父のことはとても嫌いで昨年亡くなったのだが葬式もいかなければ、その後一度も帰っていない。正直他人レベルだと思っている。そんな僕の親父もゲンドウと同じく子供とどう接すればいいかわからなかったのか?(だからと言って嫌いじゃなくなるわけではないが)とシンジくん(子供側の)目線でも考えさせられた。ゲンドウは最終的に夢が叶ってよかったね。

最後は砂浜で(シンの世界では白いプラグスーツだったけど)はち切れた赤いプラグスーツ(だったよね?)をきた大人アスカに好きだったと伝えるシンジくん。この時のアスカの照れ顔がめっちゃ可愛かった。そしてマリ end で終わるわけです。

マリ end に関しては冒頭でも書いた通り坂本真綾ファンなので全く問題ないのですが、漫画版で保管されているとは言え謎の多い女性のまま終わったなという気持ち(監督の奥さんがモデルになっているというのは考察などを読んで知った)アスカファンはケンケン事件も含め大変そうなどと思った。

One Last Kiss を聴きながらスタッフロールを見てエヴァが終わってしまった喪失感を噛み締めていたがスタッフロールが長いのでこれ途中で曲変わるのかな?など考えていたら Beautiful World (Da Capo Version) が流れ始めたのだが One Last Kiss の CD を買ってはいたが Da Capo Version を聞いてなかったので最初はなんの曲かわからなかった。
しかし、もしも願い一つだけ叶うならの歌詞で Beautiful World と理解し、宇多田ヒカルの歌声の前に歌詞の内容が脳内で浮かんできた瞬間にこれはゲンドウとユイの歌なのだと気づき号泣してしまった。ゲンドウに感情移入してしまっていたというのがあり声を我慢しなければならないほど泣いた。スタッフロールなので完全に油断していた。新劇の最後のスタッフロールが新劇の最初の序のテーマソングで終わるというのはエヴァというループを最後まで表していて(解放されたはずなのに)エヴァっぽいと思った。

Q に引き続き鈴原サクラの関西弁は可愛かった。

Q に引き続きマリとアスカのイチャイチャはよかった。マリがアスカを「姫」と呼ぶのも好き。尊い

シンを見たら視聴者とシンジくんを置き去りにし Q ってなんだよ!と言われた Q も必要だったのかな?とちょっと思う。

成長したシンジくんを見れてよかった。いつまでもいじけてたり、アスカの裸を見てオナニーして「最低だ、俺って」って発言するシンジくんをまた見たいなんて思ってなかったからな!

シン・エヴァンゲリオンは感想とか見てても賛否あるようですが、否側の人々が見たかったり俺が考えた最高のエヴァンゲリオンもカオルくんが何十(?)何百(?)と繰り返してきた 1 回の中にはあったんだと思うよ。そう思えば多少救われるんじゃないですかね?(知らんけど)
だけど監督が最後として選んだのは今回のシン・エヴァンゲリオンだっただけなんだよきっと。


あと何回か映画館に見に行きたいし新劇の BD-BOX を出してくれるなら買うので頼む。

ありがとう、全てのエヴァンゲリオン
ありがとう、大好きな宇多田ヒカルが全テーマソングを担当した新劇。

さらば、全てのエヴァンゲリオン