■ ruby の開発リポジトリを git にした RubyKaigi 2019 の開催中に @k0kubun 君が「発表が終わったら会期中に残りのタスクは全部やりますよ」と勢いのあるやる気をみせていたので、準備は広範囲にちまちま進めていた、という Ruby のリポジトリの Git 以降に必要な自分に割り振られているものをバンバン直していた。 https://www.ruby-lang.org/en/news/2019/04/23/move-to-git-from-svn/ 細かい部分は色々あるんだけど、大体は以下のようなチームプレイで進めていった。 @hsbt が現状をヒヤリングしたり、サーバーにログインして調べつつ、2019年の今風の開発でバンバン開発できるように構成を変更したり github に切り出したり、なんかやりたいという人にバンバン権限を渡していった。具体的にはサーバーにログイ

■ Ruby の新しいバージョンのリリースでやったことまとめ Ruby 2.2.10, 2.3.7, 2.4.4, 2.5.1 がリリースされました。 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/86370 ブランチメンテナではないけど、HackerOne や security at ruby-lang.org に報告がきた脆弱性リポートの一次トリアージをやったりしてるので今回やったことをまとめときます。 CVE 番号を発行した http://cve.mitre.org/ からこういう脆弱性見つかったんで CVE 番号発行しておくれというリクエストを何軒かやりました。 PGP キーと雑な英語がかければ誰でも取れるので、CVE に過大な権威みたいなもの、例としては「CVE が発行されている!重要な脆弱性だ!」みたいな

■ エンジニアリング組織論への招待を読んだ 最近話題になっているので二日くらいでシュシュっと読んだ。 エンジニアリングの本質を「不確実性の削減」と位置付けて、それをテーマにエンジニアが常々大事だと感じているプロダクト開発やコミュニケーションの中の様々なプラクティスや考え方について、何故これらのエンジニアリングが重要なのか、ということを幅広く取り扱っている大変良い本だった。 不確実性コーンであるとか、経験主義やスクラムであるとか、技術的負債などプロダクト開発が特に難しいとされている昨今だと前提知識となっているようなトピックをよくこれだけ全部詰め込むことができたなあと感心するくらいちゃんとストーリー立てているのがすごかった。 個人的に良かったトピックは 認知フレームとリフレーミング 内心は見ることができないが、行動は見ることができる OKR による目標の透明化 というあたりかなあ。最近の仕事の

■ zsh から fish にした 春というのと MacBook Pro を置き換えたということもあって、この機会にシェルを zsh で引き継ぎ付け足しし続けていた環境から fish を 0 から設定して生きることにした。bash や zsh で読み込んでから fish で、という話もあったけどそれなら bash や zsh でいいじゃないかと思うので、無から fish で環境を作るというのを目的に進める。まずは homebrew で fish をインストール。 $ brew install fish そもそも fish をわかってないので、ゆるく調べてみると以下のような感じらしい。 エンドポイントとなる設定は ~/.foorc などではなく ~/.config/fish/config.fish にかく その他設定や function は ~/.config/fish/functions

■ GMO ペパボ株式会社の執行役員 CPO(Chief Productivity Officer) に就任しました 本日開催された株主総会にて専任された取締役による取締役会にて、執行役員 CPO(Chief Productivity Officer)に専任されました。日本語に訳すのが難しいのですが、生産性担当執行役員、と呼ぶのが今のところ一番しっくりくるので当面はこう呼ぼうと思います。 なお、GMO ペパボは指名委員会等設置会社ではないので、執行役員は「執行役」とは異なります。もちろん「取締役」ではないので、一般的に使用される「役員」とも異なります。執行役員は、取締役会または経営会議での議決事項の業務執行を行う経営幹部という位置付けになります。 思い起こせば、1 月中旬に k8s の構築と検証を何気なくやっていた昼時に突如 CEO である佐藤社長に呼び出されて、何の用事だろうと社長室に行

■ 新卒エンジニア向けに品質の話をした slideshare だと keynote から書き出した日本語が消えてしまうので speakerdeck で。 https://speakerdeck.com/hsbt/yatutemiyou-tqc ペパボでは新卒エンジニアの研修の一環で座学という形で60min何かを講義するという取り組みをここ数年続けているので、自分も品質というキーワードにまつわるあれこれを講義してきた。こういう話、社内では自分くらいしかしないだろうから丁度いいだろうというレベルで若干ふわっとした話をしてきた。 資料だけだと、「ちょっとこれは雑すぎない?」というのがあるとは思うんで、この辺もう少し詳しくということがあったら、是非ディスカッションしましょう → https://pepabo.com/recruit/pepaluncheon/ ■ Asakusa.rb 第368回

■ rails の pull 型デプロイへの質問 昨日の発表直後は時間がなくて質問への受け答えがあまりできなかったんですが、発表後にぶらぶらしていた時にもらった質問が鋭い内容だったので紹介します。 No SSH ポリシーは反発もでたり、チームへの浸透は難しいのではないか minne チームは選任のインフラエンジニアがおらず、アプリケーションの開発チームが兼務してインフラを作っていたので、コードでインフラを作るというのはすんなりと受け入れられた(と思う) pull 型デプロイだと、更新漏れが起こったり、あるサーバーだけが調子わるくてデプロイが失敗したということが起こった時の検知が難しいと思うんですがどうやってますか その通りで問題は把握しているがまだ具体的な解決策は作れてない状態。デプロイ後にコードのリビジョンなどを kvs に突っ込んで、サーバーすべてが更新されたことを検知してアラート、と

■ devise をあまりオススメしない理由 いまいち使うのに気が乗らない理由はこんな感じ コントローラレイヤ以降に作用する gem は inspect が物凄くやりにくい、params ないし、必要なコンテキストを全て揃えた上で、コントローラを new して action を呼んで、みたいなこと、考えただけでもだるい テストを書いていたとしても、環境要因、特にセッションとクッキーに影響して挙動が変わる箇所が多すぎるので、全ての環境で正しく再現することが難しい フルスタックすぎることから Rails よりも devise にロックインされることの方が多くなって負債化する そもそも devise で便利になることの多くは、自分で作ってもわけない物が多い 使うからには、devise のコードも全部読むし、PR も投げるしという前提かつ、上のようなことを全て乗り越えるつもりなら僕は止めません!

■ 楽天 TechTalk で Ruby と Rails の話をしてきた 楽天の河口さんから Ruby と Rails を使ってビジネスを回しているという話をしてくれという依頼がきたので、2日前の 12/10 に楽天オフィスまで言って何か話してきた。当日は遅刻してしまって申し訳ありませんでした...品川シーサイド難しい... 話の内容は、今年の RubyConf Taiwan と RailsPacific で話した内容を足して2で割ったような内容を1時間弱という感じ。 散々聞いた話だと思うけど 使い捨てじゃないプロジェクトやサービスで Rails 使うなら継続的にバージョンアップして技術的負債を返し続けるのが良い。一気にビッグジャンプしようとするととてもコストがかかるし、そもそも出来るかどうかわからない。 Rails 使うなら、Rails が良いとしているテクノロジーや方向性に積極的に乗っ

■ 来月から開始する新卒向けの研修内容を公開しました 新卒研修では実際のサービスの業務内容的な内容は一切するつもりがなくて、エンジニア(デザイナーも一部)として必要な教養や今から新しく物を作るなら、これくらい知らないといかんだろという項目ばかりなので公開してみました。 https://gist.github.com/hsbt/5318109 実際には、今からデザインパターン話してもしょうがないだろとか、全文検索の基礎くらいは入れた方がいいんじゃないという感じにもう少し入れ替える予定。皆さんの会社の研修内容も頂けると各社捗ると思うのでご検討をお願いいたします。

■ 人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について 去年 @pyama86 さんが読みやすくて面白かったと話していたので買ってシュッと読んだ。 確かに面白くて、コンピテンシーという考え方はなるほどなって感じだった。いろんな立場の人が組織にはいるけど、より管掌や責任の範囲が広い人は狭い人ができることは当たり前とした上で、立場にあった評価の基準が重なっていくという話で、自分も含めて「わかるー」という感じだった。 後、この本では評価を決めるのは影響力というくだりがあって、これは特に専門職に分類される人には読んでもらいたいところなんだけど、エンジニアの場合だとシニアエンジニアは「技術力が高い」から評価されるのはなく「技術力が高いので結果として生み出されるアウトプットの影響力が高い」から評価されると置き換えるとわかりやすいと思う。 「アウトプット」と言われると OSS であ