勤務先で『ソフトウェア職人気質』の書籍紹介をした

勤務先のおすすめ書籍の紹介イベントで、『ソフトウェア職人気質』を題材にした話をした。

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

当日のスライドは以下。

『ソフトウェア職人気質』は『エクストリームプログラミング』の第一版 (たぶん 2023 年現在の世間で広まっていない方) のような、ゼロ年代に台頭していた尖った書籍のうちの一冊。書籍そのものの内容というよりは、その内容と現実世界の仕事とのリンクについて取り上げなどしていた。 発表の話としては前半パートと後半パートで分かれていて、前半パートは自分の前の発表者だった @fkino と話していることが色々と被っていて、なんなら自分の 5 ページ目のスライドはだいたい同じデザイン構成で「示し合わせもなく、なんだこれ？w」展開で面白かった。

後半はいま話題の GPT に関連する話としていて、GPT との共生への展望みたいなことを書いているものの、本編では時間が足りず結構端折って話していた。

個人的には今後パラダイムシフトが起きるとしても、いまの仕事で行っている熟練度がゼロリセットされるものではないと見ているので『ソフトウェア職人』として研鑽していきましょうという感じで締めくくり。アジャイルマニフェストには署名がないものの、XP のシリーズ書籍の著者のひとりであるピート・マクブリーンさんのソフトウェア開発への考え方について、知られる機会になっているといいなあと思っている。

XPエクストリームプログラミング懐疑編―XPはソフトウェア開発の救世主たりえるのか (The XP Series)

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

Bliki (ja) の翻訳チームに加わった

Martin Fowler's Bliki (ja) を管理しているリポジトリのコミット権を @kdmsnr さんからもらったことで、翻訳チームに加わった。

github.com

勤務先の永和システムマネジメントでは、『マーチン・ファウラーの会』という Bliki (ja) を読んでディスカッションする会があって、そこで気に掛かったものをプルリクエストにしていたところコミット権をもらった流れになる。Bliki (ja) はタイムレスな記事も多く、自分としてもゼロ年代に本当にたくさん読んで過ごしてきたもので、近代ソフトウェア開発に対する考え方の基礎の多くは eXtreme Programming とこの Bliki (ja) に影響されたものだと思っている。ぼちぼち見ていく気持ちです。

エクストリームプログラミング

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

Ruby 30周年記念イベントにLT登壇した

プログラミング言語Ruby 30周年記念イベントに LT 登壇した。

30.ruby.or.jp

当日のスライドは以下。

RuboCop をメンテナンスしている日常の中からの話をピックアップしようと思っていたところ、RuboCop の哲学とかそのあたりを話の背景に入れたり、レビューに参加させてもらっている 角谷さん訳の研鑽 Ruby を元にした『哲人と詩人への自己分析』のスライドがローカルマシンから発掘されて入れてしまおうになったところ、まあ 5 分に収まりませんよね。

元々、銅鑼の音色に散ろうと思っていたので、全スライド到達を目指していはおらず『MatzCop』が最初に出たスライドで終わるといいなあと思っていたところ、王手も掛けることができなかったという。現地登壇だと、銅鑼と同時にスライドを目標ページまで数枚めくって終わるという裏技があるので、無意識にそれを狙っていたところオンラインだと難しいですね。みんな 5 分に収まっていてすごい。

イベントとしては、角谷さんオープニング〜高橋会長の Ruby 30 年の歴史から Matz のクロージングキーノート (プレゼン楽しそう！) まで終始楽しかったです。Ruby 30 周年おめでとうございます！

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

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

あなたの知らない超絶技巧プログラミングの世界

当日のスライドは以下。

全体としては、鍋谷さんなどが行われている『どう書く』ならぬ、『どう読む』といった体裁での 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 のしくみ』で、表紙はこのパロディになっています。

Rubyのしくみ -Ruby Under a Microscope-

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

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 関係の発表の締めにもなるかなというのもあって選んだもの。テキスト自体は書籍帯にも使われていて印象に残っているものの引用でした。

Code Reading　プレミアムブックス版　オープンソースから学ぶソフトウェア開発技法

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

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