勤務先で『あなたの知らない超絶技巧プログラミングの世界』の書籍紹介をした

勤務先のおすすめ書籍の紹介イベントで、『あなたの知らない超絶技巧プログラミングの世界』を題材にした話をした。

当日のスライドは以下。

全体としては、鍋谷さんなどが行われている『どう書く』ならぬ、『どう読む』といった体裁での Quine の読み方例を話した。

スライドを作る過程で、ChatGPT に "Quine を Ruby でどう書く?" としたところ、禁じ手の puts File.read(__FILE__) 的なコードを提示したり、そもそも Quine になっていないコードを提示したりして面白かった。まったく別軸では、COBOL で書かれたものはあるだろうかと調べたら c2.com のページ がヒットしたりと、脇道に行ってもちょっとした発見があった。

今回の話は TRICK 2018 の動画 でも確認できる、以下の kinaba さんの言葉が素晴らしくて、それを社内にも伝達したいというのがモチベーションだった。

成熟した文化、例えば音楽でも楽譜を逆さにしても弾くことができる音楽とかそういうものがあって、 (中略) 成熟した文化にはこういったお遊びが発展していて、プログラミングという分野も
成熟した文化になっているといえる...んですかね

そんな超絶技巧プログラミングの世界はこんなイメージ。

ふだんのお仕事とは、ちょっと価値観の異なるプログラミングのおもしろさが広まるきっかけになると良いなと思う。

エンジニアリングマネージャー研修を社内開催した

勤務先の 岡島 CTO から社内の組織としてエンジニアリングマネージャー (の考え方や役割) を増やしたいという話を受けて、セミナーを設計して開催しました。勤務先で自分が所属しているのは Ruby x Agile をビジネスの中核にしている部署ですが、今回はクラウド x Agile や組み込み、金融 DX などといった自分とは別の部署からの参加者ということで、事業部ごとに異なる事業テーマと事業課題に合わせて向き合えるよう、異文化交流を前提にデザインしてみたものです。公開版のスライドは以下 (ハンズオンのナビゲーションを中心に15枚くらいオリジナルからスライドを削っています) 。

マネジメントに関しては一方通行の座学で聞くよりも、当事者自身で考えた方が持ち帰ってもらえるものが多いと思ったので、ハンズオン形式での開催にしています。ちょうど XP 祭り 2022 での発表 が、エンジニアリングマネージャーとして考えてきたことを整理する機会になっていたので、思考トレースを反映した流れで組んだものになっています。本編では「something else = 事業課題 - 事業マネージャー」という公式で導出した隙間をどのように埋めるか考えるきっかけを作ると同時に、事業メンバーとの 1on1 からの導出はそれぞれに持ち帰ってもらうという締め括りにしています。

事業を少しづつ良くしていくという考え方を伝えられたんじゃないかなと思うのと、自分としても事業ごとのメンバーの考え方を知る良い機会になりました。

SlackへのGitHub通知先をスレッドからチャンネルにする

SlackへのGitHub通知先をスレッドからチャンネルにする方法です。

最初にまとめ。先月2022年10月下旬に、Slack への GitHub 通知がスレッド宛てになったのを、/github settings と Slack チャンネルで入力してチャンネル宛ての通知にできるといったものです。

ここからはもう少し詳しく書いてみます。スレッド宛ての通知というのは以下のようなものです。例えば GitHub イシューにコメントをつけると、イシューを開いた大元の Slack 通知へのスレッドコメントとして繋がっていくものです。

個人的には「人間の対話」と「機械的な通知」を同一視してスレッドにまとめるというこの変更は、かなりユーザー体験が悪くなったもので、Slack 公式がスレッドでの対話を薦めているのに便乗している風な感じでしたがちょっとこれは、、、というものでした。

勤務先で話題にしていたところ、同僚の @ima1zumi に以下の GitHub イシューでお気持ちがフィードバックされていることを教えてもらったので、せめてオプトアウトがないとつらいという気持ちについて自分もコメントをしました。この件については強いお気持ちがあったので、当初リアクションだけで済まそうとしたけれど、意見はきちんと述べておこうとコメントしたものです。スレッド通知に反対する似たような応援コメントがいっぱい付いていることが確認できます。

github.com

それから半年、この度、待望のオプトアウトが入りました

チャンネル通知への切り替え方法ですが、オプトアウトしたいチャンネルへのチャット入力で /github settings と入力すると以下の設定が表示されます。

これらを無効にすることで、旧来のチャンネル通知に切り替えることができます。

無効化したあとの Slack への GitHub からの通知は以下のとおり。チャンネルに通知されています。

ただ、現状のデフォルトでは依然として以下のようにチャンネルに通知されます。

他にもこのオプトアウトが入るまで対応していた /github subscribe org/repo comments:"channel" というチャンネル通知への切り替え方法もありますが、いまだと /github settings でシュッと対応できると思います。

スレッド通知だと、過去のスレッドへのコメントがつく形で見落としてしまうことがつらいというユーザー体験の人は、 /github settings からの変更でチャンネルへの通知に切り替えると捗ると思います。

また、このオプトアウトでチャンネル通知に切り替えられるものの「全チャンネルでこれやるのまじで?」みたいなコメントもあって、今後もう少し振る舞いが変わるかもしれません。お気持ちのある人はイシューにフィードバックしてみると良いと思います。

github.com

Lint Night #1 に登壇した

Lint Night #1 に登壇した。

lintnight.connpass.com

当日のスライドは以下です。

今回は Kuniwak さんの方でそもそも「Lint とは?」といった前段の話をしていただけるというのと、"Lint" を冠したイベントを考えて、ここなら事前に求める前提知識をいくつか端折って話して良いだろうと RuboCop の内部構造に踏み込んだ話にしてみました。

今回内部のしくみに踏み込もうと思った時に思い出したのが『Ruby のしくみ』で、表紙はこのパロディになっています。

私の発表の構文解析パートで出てきた書籍はこちら。YaccRuby 版である Racc については『Ruby 256 本 無道編』が構文解析のしくみもろもろと一緒に紹介されていて、文体も読みやすくお薦めです。

本題の静的解析パートですが、RuboCop の内部を表現するのに久しぶりに UML のクラス図を使おうと思ったのですが、相互作用も表現したくなってコラボレーション図的なものも混ざった感じのものになり、Unified されていない Modeling のダイアグラムになったのがこちら。厳密性よりも伝えることが重視ということで、まあいいかとした。こういった RuboCop 内部のまとめをしている図は知る限りないと思うので、おもしろいものかなと思います。

本編では伝えたのですが、構成の設定や自動修正周りは割愛していますが、このあたりのクラスを中心に読んでいけると思うので、今後 RuboCop をソースコードリーディングしてみたいときの手がかりなんかにご活用ください。

RuboCop の内部構造を知ると、RuboCop というプロダクトの内部構造が警察のお仕事をメタファーにしたモデリングをしているのがわかり、RuboCop という作品名が映画のタイトルのように映る。そんなコードリーディングの景色もあわせて伝えられると良いかなと思って話したところ、Twitter の反応を見た限りだと良い感じに伝わったようでよかったです。

最後に付録的に書いている Ruby と RuboCop のサポートマトリックスは当初今年の RubyKaigi 2022 向けに作って入れていたものだったものの、ストーリーの流れで外したスライド。今回少し強引ではあるものの流れで伝えられそうなので足し込んでおいた。ついでに言うと、表紙パロディの元ネタである『Ruby のしくみ』のサブタイトルは『An Illustrated Guide to Ruby Internals』で、図を使った説明を意識してされていたことから、今回の私の発表は図を多めにと意識していたので、このマトリックスも入れてしまおうといった部分もある。

最後のスライドに使ったの引用元書籍である『Code Readng』は、監修にまつもとさんも入っているので、Ruby 関係の発表の締めにもなるかなというのもあって選んだもの。テキスト自体は書籍帯にも使われていて印象に残っているものの引用でした。

イベント全体としては、さすが Lint Night というテーマがくっきりしているイベントだけあって、発表を通しても Kniwak さん、azu さんとの 3 人の話で大きな緩いストーリー性が出ていて面白かったです。今回はオンライン登壇を選んでいたので、azu さんに JS 周辺の情報をいつもありがとうございますと直接伝えられなかったのが心残りですが、それは今後の人生のまたの機会ということで。

お誘いいただいた Kniwak さん、運営いただいた DeNA スタッフのみなさんありがとうございました!

Ruby 3.2 (dev) のビルドに Bison 3 以上が必要になる

Ruby 3.2.0-dev のビルドで、手元の Bison が古いと以下のようなエラーになります。

% rbenv install 3.2.0-dev
rbenv: /Users/koic/.rbenv/versions/3.2.0-dev already exists
continue with installation? (y/N) y
To follow progress, use 'tail -f /var/folders/6j/5l8q3y250b97529_tcssrwlm0000gn/T/ruby-build.20221116140826.18556.log' or pass --verbose
Installing openssl-3.0.7...
Installed openssl-3.0.7 to /Users/koic/.rbenv/versions/3.2.0-dev

Cloning https://github.com/ruby/ruby.git...
dateInstalling ruby-master...
Building with YJIT by default because rustc 1.61.0 (fe5b13d68 2022-05-18) is installed; add RUBY_CONFIGURE_OPTS='--disable-yjit' to disable explicitly
ruby-build: using readline from homebrew
ruby-build: using gmp from homebrew

BUILD FAILED (Mac OS X 10.15.7 using ruby-build 20220324-102-g0080511)

Inspect or clean up the working tree at /var/folders/6j/5l8q3y250b97529_tcssrwlm0000gn/T/ruby-build.20221116140826.18556.oLJDwU
Results logged to /var/folders/6j/5l8q3y250b97529_tcssrwlm0000gn/T/ruby-build.20221116140826.18556.log

Last 10 log lines:
compiling regsyntax.c
compiling ruby.c
compiling scheduler.c
compiling shape.c
compiling signal.c
compiling sprintf.c
compiling st.c
parse.tmp.y:12.10-14: require bison 3.0, but have 2.3
make: *** [parse.c] Error 63
make: *** Waiting for unfinished jobs....

以下のように手元の Bison が古いようであれば、brew などで手元の Bison のバージョンを 3 以上にアップグレードしましょう。

% bison --version
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

macOS 標準の Bison が古くて遭遇することがあるかもしれません。この Bison バージョン更新に関して詳しくは以下をどうぞ。

bugs.ruby-lang.org

Lint Night #1 に登壇します

Lint Night #1 に登壇します。

lintnight.connpass.com

Lint というテーマに絞っているイベントであることに加えて、そもそも Lint とは何かなどといった話は Kuniwak さん が話されるということで、今回の話はマニア指向で作るつもりです。なので、エンドユーザーが聞いて明日からのお仕事の役に立つかどうかはあまり気にしない方向の話になると思います (が、RuboCop がどういった世界観のプロダクトなのか、より理解が深まると思います) 。

内容としては DeNA Tech さんでアナウンスしていただいている、以下のような方向で進めています (スライドは鋭意作成中) 。

余談ですが、登壇タイトルの『RuboCop のしくみ』は、『Ruby ソースコード完全解説』 (通称 RHG) 以降に Ruby の内部を説明されている良書『Ruby のしくみ』へのオマージュです。

中身的にも RuboCop の内部を紹介する珍しめの内容になると思います。そして、15 分の持ち時間でお話を頂いたところ、RuboCop の内部のしくみを話すのに 15 分では厳しかったことから 25 分に枠を拡張してもらいました。

私はオンラインでの登壇の予定です。Lint マニアの方もそうでない方も、よければご視聴ください。 azu さん との対バンイベントでもあり私もとても楽しみです。

XP祭り 2022 に登壇した

XP祭り 2022 に登壇した。

当日のスライドは以下です。昨年のような機材トラブルもなく無事に終えられて良かったです。

話としては今年の 6 月くらいの @beakmark との「エンジニアリングマネージャーの仕事」に関するやりとりをきっかけに、エンジニアリングマネージャーとして働いている2年目までと、そこに至った事業課題からの経緯をまとめたものです。XP コミュニティ向けもさることながら、同僚向けにも日頃の仕事でどんな考えで動いているかをある程度まとめる機会になって良かったです。

サブタイトルの『Practices of an Engineering Manager 
Working in The Real World』は『アジャイルラクティス』の原題『Practices of an Developer 
Working in The Real World』がベースでした。悪魔の囁きと天使の導きのような話ではないですが、個人的には in The Real Wold での "an" Engineering Manager の実践の話として、現在 45 分の登壇でまとめられる限りで話せたかなと思っています。

本編で話しましたが、エンジニアリングマネージャーの役割は「事業部経営 - 経営マネージャ = something else」という公式の something else を埋めるものだと思っていて、組織と人に応じて立ち位置も変わってくるものではと思っています。これは登壇後に気がついた余談だけれど、エンジニアリングマネージャーはバンド (チーム) でいうと、ヴォーカルやギター、キーボードのような上物と (色とりどりのエンジニア) とドラム (経営マネージャ) の間を担っているベースという役割が近そう。多くの曲全体の中では地味ながらベースの有無やスタイルで曲のイメージが変わるというのと、ドラムとのリズム隊という位置づけとしてもそんな感じ。

XP 祭りというイベントとしても、当日たくさんの同僚が登壇したり、勤務先の永和システムマネジメントに核といえる文化を残してくれた kkd がキーノートだったりしたので、登壇ギリギリまで聞いてピックアップできそうな講演をできるだけ話を内容に取り込んでいました。

とりわけ kkd のキーノートで挙がった『まさーるのページ』についてはこのタイミングで会社紹介で出さなければと思って、追記したものでした。弊社いいメンテナンスしている。

objectclub.jp

最後に、私の本編で引用していた書籍は以下です。特にキーノートの kkd からの遺伝情報である、クリストファー・アレグザンダーからの引用は、音楽と同じでキーのノート (音) に合わさった感じにできただろうか?といったところです。

また、スライド中の 24 ページの図の引用元はこちらです (ありがとうございます!) 。

qiita.com

登壇後にはキーノートの kkd から最高の賛辞をもらえたので、登壇冥利に尽きました。

最初から最後まで楽しい "祭り" で、特に LT では @fkino の 大人気ない 本気の LT は最高でした。

Discord のタイムラインはちょっとしたサーバーログのスピードでしたね。

スタッフのみなさん、今年もありがとうございました!また来年!