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 のタイムラインはちょっとしたサーバーログのスピードでしたね。

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

勤務先で『NO HARD WORK』の書籍紹介をした

勤務先の社内イベントにある『DE ラジオ』の『DE の手書きポップ』という書籍紹介コーナーで話すことになり、『NO HARD WORK』を題材にした話をしました。

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

この話の超拡大版というか、もっと多岐に渡った話を、今週末の 2022年10月1日(土) に開催される、XP祭り 2022 で『組織のアジリティを向上させるエンジニアリングマネージャーの仕事』というタイトルで登壇します。

confengine.com

私の登壇は 15:00-15:45 の F Track です。

xpjug.connpass.com

余談ですが勤務先の全社では『ディスティングイッシュト・エンジニア』という肩書き、事業部では『エンジニアリングマネージャー』の肩書きでの仕事をしていて、XP 祭りでは後者の日常のお仕事に関する話をします。おたのしみに。

CircleCIのGitHub連携でPermission denied (publickey)が起きたときの対処

CircleCI を使った GitHub リポジトリの CI で、ある日突然以下のようなエラーが起きるようになりました。

現象

CircleCI のログを見たところ、GitHub からソースコードをチェックアウトする際に、以下のようなエラーになっていました。

if [ "$existing_repo" = 'true' ] || [ 'false' = 'true' ]; then
  echo 'Fetching from remote repository'
  if [ -n "$CIRCLE_TAG" ]; then
    git fetch --force --tags origin
  else
    git fetch --force origin +refs/heads/master:refs/remotes/origin/master
  fi
fi

if [ -n "$CIRCLE_TAG" ]; then
  echo 'Checking out tag'
  git checkout --force "$CIRCLE_TAG"
  git reset --hard "$CIRCLE_SHA1"
else
  echo 'Checking out branch'
  git checkout --force -B "$CIRCLE_BRANCH" "$CIRCLE_SHA1"
  git --no-pager log --no-color -n 1 --format='HEAD is now at %h %s'
fi

Using SSH Config Dir '/home/circleci/.ssh'
git version 2.35.1
Cloning git repository
Cloning into '.'...
Warning: Permanently added the ECDSA host key for IP address '140.82.112.3' to the list of known hosts.
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

exit status 128
CircleCI received exit code 128

https://app.circleci.com/pipelines/github/rubocop/rubocop-performance/811/workflows/536d4094-27ac-4714-9686-0c63887fdf50/jobs/5386

原因

GitHub 上の設定を見たところ、なぜか Deploy Keys が空になっていました。

対処方法

CircleCI 側のプロジェクト設定を「Project Settings」で開きます。

SSH Keys」を開いて、 (連携できていない) 既存の Deploy Key を削除します。

"Add Deploy Key" を押して SSH Key を追加します。

GitHub 側にも Deploy Keys への設定がされますので、ソースコードのチェックアウト可能になっていると思います。CircleCI のテストを Re-run してみましょう。

この問題が起きるようになった原因はわかりませんが、不特定のリポジトリで起きているようです。

現象に遭遇したとき参考までにどうぞ。

RubyKaigi 2022 に登壇した

RubyKaigi 2022 に登壇した。

rubykaigi.org

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

今回はリアルタイムでのリモート登壇でした。

本編

概ねサーバーモードなしの RuboCop のブートと、サーバーモードありの RuboCop のブートの違いと中身の概略について話せたかと思います。

今回話した高速化は、rubocop のブートに関わるモジュールローディング部分であり、解析自体が速くなったわけではないですが、起動時間の高速化ということで繰り返し起動することの多いツール特性に対しては有用な高速化だったかなと思います。

ふつうに使っている分には rubocop --server としてオプションありで使って問題ないと思いますが、RuboCop Performance や RuboCop Rails といったサードパーティー gem への bundle update があると、現状ではそれらを検知できないので rubocop --restart-server が必要になります (RuboCop 本体のアップデートは検知して、自動再起動するようにしています) 。Spring のように起動しているとハマったときに面倒みたいなことを減らせるよう、このあたりは早めに対応しようかなという気持ち。

ちなみに .rubocop.yml の構成を変えた場合は rubocop --restart-server は不要です。これは現状だとサーバー側で実行のたび設定読み込まれ、構成変更が都度反映されるためです。ただ、これは予期せず実装がそうなっていたというもので (!) 、将来的にこのあたりへのキャッシュ導入 (と変更検知導入) とのベンチマーク次第で少し動きが変わるかもしれません。

サーバーモードの実装で一番どうするか悩んだのはコマンドラインインタフェースをどうするかでした。そのあたりの話はコードとしては残っていませんが、決定を下した経緯として話しておこうと思って私の頭の中にしか残っていないことと、プルリクエストで行った議論をベースにしてコンテンツに含んでおきました。完全にうなすけくんの言ってくれているこれ。

また、本編で話していないプロセスの基礎的な話は『なるほどUnixプロセス ― Rubyで学ぶUnixの基礎』がおすすめなので、参考図書として記しておきます。

tatsu-zine.com

サーバーモードについては公式ドキュメントにも記載していますので、どうぞお試しください。

docs.rubocop.org

(おまけ) 放送事故

バーチャル会場の音声をつけっぱなし (というのにあとで気づいた) のままヘッドホンをしていたので、話すのに集中するためヘッドホンを外したら同期されていたらしいマイクも切れて、無音放送になるという放送事故の登壇実績を解除してしまいました。読唇術の技術を求めてしまってすみません。

タイムキープ用に手元に置いていたスマホに、勤務先の事業部長の @m_pixy から電話があって気づきました。おかげで本題では音声復旧できました (無音になった導入部分は時間の都合であきらめて先に進みました) 。音声トラブルで電話をくれた @m_pixy は m_pix "y" だったので、まさか matz のキーノートが自分にとってこういった伏線になるとは。@m_pixy ends with "y".

放送事故中、メンションしてくれた方々ありがとうございました。のちのリアルタイムリモートスピーカーに伝えられる教訓としては、ヘッドホン、イヤホンを外すときは連動してマイクオフにならないか気をつけましょう (気を付けます) 。

最後に、RubyKaigi チームのみなさん、通訳のみなさんありがとうございました。また、@yahonda さんに、昨年に引き続き事前に英文や構成レビューをしていただきました。いつもありがとうございます。

そして、miwa さんのツイートによると、だいたい満席だったようでありがとうございました!RubyKaigi はドラマがあって良いですね。

2022年9月12日(月) 追記

同僚で登壇者でもある @fugakkbn が、Togetter でこの登壇のまとめを作ってくれていました。ありがとうございます!

togetter.com

2022年9月13日(火) 追記

さっそく VS CodeServer モードの連携を試してくれた結果を文書にまとめていただけたようです。cumet04 さん、ありがとうございます!

zenn.dev

RubyKaigi 2022 に登壇します

RubyKaigi 2022 に『Make RuboCop super fast』というタイトルで登壇します。

私の登壇は2日目である 2022年9月9日(金) の 11:30-12:00 です (昨年と同じ日時だった) 。

rubykaigi.org

最近 RuboCop に追加した server mode の話です。server mode 導入のはじまりの PR は以下。

github.com

server mode の導入に至った課題点とその解決の仕組み。現状での弱点や今後の展望といった利用者として知っておくと良さそうな話なんかも含めて話す予定です。server mode は絶賛開発途上でもあるので、割りと鮮度高めの話になるのではと思っています。

また、今年の RubyKaigi には勤務先の永和システムマネジメントから同僚の @ima1zumi@fugakkbn も登壇します。お楽しみに。