Islands in the byte stream

Technical notes by a software engineer

4ヶ月の育休をとる

2022年の6月に第二子であるrfxを受け入れました。それに伴い、この12月から4月第1週いっぱいまで、約4ヶ月の育休をとることにしました。

第一子であるmfxのときは育休はとらなかったので、はじめての育休です。なんならプログラマーとして働き始めてから十余年、1ヶ月以上休みをとるのは初めてです。

rfxが産まれてからこのかた、認知的に高負荷な状態が続いていて、そのわりには仕事にも全然集中できなくてけっこうしんどい思いをしていたので、ここで育休をとって育児に専念できるようになるのは正直ほっとします。一方で、育休給付金を踏まえても収入が激減すること、4ヶ月の間キャリアを休止することについては不安もあります*1

とくに収入については結構苦しいところです。育休給付金は雇用保険でまかなっていて、年々改善はしてきていますが、支払い上限が1ヶ月約30万円までとなってるからです。一方で、夫婦どちらも育休を取らないという選択肢はありません。0歳児の世話をしながら夫婦ともにフルタイムの仕事をこなすことはできません。

一方で、第一子の時と比べると、すでに乳児の育児を一度経験していること、また家庭というチームの結束は第一子の時よりもずっと高まっていることから、やるべきことの膨大さに対して全体としてのストレスは低く抑えられているような気はします。さらに、せっかくの育休なので普段仕事でできないような個人プロジェクトを進められるといいな、という野望でもって計画だけはたてています(これについては当初の計画の1/10もできれば及第点でしょう!)。

そういうわけで不安も期待も両方ありますが、いずれにせよ数ヶ月にわたってフルタイムで育児に専念するのはおそらくこれが一生に一度のことです。せっかくなので実りある時間にできればいいなと思っています。

*1:ぼくはわりと "仕事 is 人生" というくらい、人生における仕事の充実度を重視しておりますので…。 参考: https://engineer-lab.findy-code.io/gfx

BPF CO-RE は GitHub Actions の Ubuntu 20.04 インスタンスでテストできそう

BPF CO-RE (CO-RE: Compile Once , Run Everywhere) を実行するにはLinux kernelがBTF (BPF Type Format) つきでビルドされている必要があります。

Ubunt 20.04 の最初のリリースではBTFは有効になっていませんでしたが、アップデートで配信されているカーネル 5.13.0-39-generic ではBTFが有効なのでカーネルのアップデートをするだけでBPF CO-REが使えます。

GitHub Actionsの場合、デフォルトのカーネルではなくAzureのためのカスタムカーネルですが、こちらも最近のインスタンスBTFが有効になっているので、特別なことをしなくても BPF CO-RE をテストできそうです。

github.com

  • ci.yml - workflow file、ただし実際には make を呼ぶだけ
  • Makefile - 依存関係のインストールやビルドなど

これで BPF CO-RE を使ったツールも開発し放題ですね!

Firefoxの「プライバシーとセキュリティ」の設定を変えたらアプリの再起動が必要

追記: これをしてもはてなブログのヘッダでログイン状態にならない現象が起きてしまうようです。もはやFirefoxのバグなのかはてなブログのバグなのかわかりませんが…。


Firefoxの「プライバシーとセキュリティ」を変えると次のようにタブの再読み込みを行うUIが出ますが、少なくともFirefox v98現在はタブの再読み込みだけではなく Firefox自体の再起動が必要です

「これらの変更を適用するにはタブを再読み込みする必要があります」「すべてのタブを再読み込み」

そうしないと少なくとも一部のクッキーの挙動などが変わり、「はてなブログ」のヘッダではてなアカウントがログイン状態にならないようです(はてなブログFirefoxのプライバシー設定が「厳格」だとヘッダがログイン状態になりません)。

このせいでずっとはてなブログFirefox未対応だと勘違いしていたのですが、実際にはどうもFirefoxのバグっぽいなということがわかった次第です。

GitHub Pull-ReqでCIの完了をデスクトップ通知するChrome拡張 "WatchRaptor" を作った

Chrome Web Store

chrome.google.com

使い方ですが、GitHub PR pageに次のようにCI statusにcheckboxが現れるので、完了通知がほしいCI statusにチェックをつけるだけ。

f:id:gfx:20220118214310p:plain

チェックされたCI statusが完了(success or failure)になると、次のようなデスクトップ通知が出ます。この完了したときの通知をクリックすると該当のGitHub PR pageのタブをアクティブにします。

f:id:gfx:20220120093634p:plain

tab idごとにcheck状態をもっているので、リロードしてもtabごとのcheck状態は維持されます。

現在(v0.9.2)の機能はこれだけです。既知のバグとして、GitHubのPR画面で差分をみたりdiscussionに戻ったりしているとcheckboxが出ないことがありますが、そういう場合はリロードするとcheckboxが出ると思います。そのうち直します。

Repository

github.com

実装はTypeScript、UI(といってもcheckboxだけですが)はReact、パッケージングはwebpackを使ってます。構造がちょっと面白い、そのあたりの詳細の話もそのうち書きます。

なお、この "WatchRaptor" (ウォッチラプトル)という名前ですが、子供が恐竜にハマっているので "watchdog" (「番犬」)をもじって恐竜っぽい名前にしてみたという感じです。

M1 Mac + Intel NUC (mini PC) で快適AMD64 Linux生活

2021年現在、M1 MacでDockerを使うのが大変という話がちょいちょいあります。

個人的な事情でいうと、私は現在、AMD64 Linuxでしか動かせないソフトウェアを開発していて、Dockerもちょいちょい使う、という感じです。なのでAMD64 MacVMWareを使ってUbuntu VMを使って開発しています。

一方で、新規で購入できるMacbook ProがM1しかない、デスクトップマシンとしてWindowsUbuntuを使うことにまだ踏ん切りがつかない(なんだかんだで10年Macで仕事をしてきているので…)ということもあり、どうしたものかと思っていましたが、会社が開発機としてIntel NUCを用意しているというので申請して導入したことで、一気に諸問題が解決しそうだなというところに至りました。

Intel NUCはIntelが作っているmini PCで、サイズ的には幅12cm、 奥行き12cm、高さ4-6cm(具体的な大きさなモデルによる)くらいなのであまり物理的な場所をとりません。この中に開発環境を作ってSSHなりvscode remoteなりで入ればいいというわけです。私の場合はかれこれ2年ほどVMWareUbuntu VMを作ってその中にSSHして開発していたので、開発体験的にもあまり変わらないはずです。

今回は NUC10i5FNH (NUC 第10世代 with Core i5)をセットアップしました。

Intel NUC 10 Performance kit NUC10i5FNH Product Specifications
(Recommended Customer Price: $414.68 - $417.14)

この筐体はSSDもRAMもついてないので、適当に入手して自分でつける必要があります。

Ubuntuを入れるときはUbuntuのサイトにIntel NUCを使うときのやり方や、必要な周辺機器があります。ただし、私はUbuntu DesktopではなくUbuntu Serverを入れました。どのみちSSH経由でしか使いませんからね。

Install Ubuntu Desktop on the Intel® NUC | Ubuntu

起動ディスクの作り方が最初わからなくてハマっていましたが、上記サイトのインストラクションをよく読んでいないだけでした…。Macで起動ディスクを作る場合はこれまた下記のとおりUbuntuのサイトにやり方が書いてあります。

Create a bootable USB stick on macOS | Ubuntu

なお、セットアップ時に日本語キーボードを認識できずUSキーボードと検出されてしまったのですが、どうせSSHするだけなので特にがんばって日本語キーボード対応したりはせずスルーしました。

まだセットアップしたばかりなので本当のところはよくわかりませんが、会社が開発機としてIntel NUCを支給できるならこれはベストの開発環境といえるのではないかと思っています。

set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット

課題編

シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。

set -e

# グローバルな状態を変える操作を行う
git merge --no-ff --no-commit $main_branch || true

# 結果をチェックしてexit codeを変数に入れる
git diff --cached --exit-code --quiet ; code=$?

# グローバルな状態をもとに戻す
git merge --abort

# 上位プロセスに結果を渡す
exit $code

スクリプト全体には set -e (コマンドが失敗するとシェルスクリプトが即座に終了する)を効かせていると、このままだと git diff --exit-code ... で差分があるときに終了ステータス1を返してシェルスクリプトが終了してしまいます。これをシェルスクリプトを終了させるに終了ステータスを得たいというわけです。

解答編

やりかたは色々ありました。

-e の挙動はポータブルではなくシェルによって挙動が違うので set +e での無効化が必要

どれでも正しく動くのでいいと思いますが、 code=$(set +e ; command ; echo $?) はポータブルで比較的メジャーな構文のみ使い、グローバルの状態に依存したりグローバルの状態を一時的にでも変えたりせず、意図が明確なので今回はこれでいこうかと思います。

Findy Engineer Labに Individual Contributor の話を寄稿しました

engineer-lab.findy-code.io

詳細は記事を読んでいただきたいのですが、おかげさまで「ICという役割を初めて知った」「自分もIC的な働き方をしたいのだと分かった」という感想が複数みられたので、この記事を書いた甲斐はあったなあと思います。

一方でやや誤解というか説明が不十分だったかなと思うのが、「ICを役割としておいている企業では、ICはプレイヤーのデフォルトの役割である」ということです。Fastlyではそうですし、たぶんICを置いている他の企業でもそうです。ICはスタープレイヤーだけに許された特別な働き方では決してありません。私はIC的に働いてきて今後もICで行きたいと思いますが、ICと管理職(ピープルマネージャ)を行き来するという選択をとってもいいですし、むしろICとピープルマネージャを行き来するほうがICとしての成長に繋がりますよという主張もあります。

ともあれ私としてはIC ladder(ICという出世の階段)を置いてくれたほうが働きやすい(=今後の転職の選択肢になり得る)し、そういう会社が増えてくれると良いなと思う次第です。

Fastlyに入社して2年たちました

在職エントリってやつです。

gfx.hatenablog.com

2019年9月9日に現職に転職して今月で2年たちました。ウェブ系でRailsやReactなどをやっていた前職から活動分野を大きく変えて、C言語などでミドルウェアを開発する現職にきて、さらに英語が共通語の環境ということでうまくやっていけてるか心配でしたが、なんとかギリギリやっていけてるという感じです。

IC(Indivisual Contributor; マネージメントをしない専門職)としては、技術力が高ければ高いほど、専門知識があればあるほどダイレクトに仕事の成果に直結する会社なので、そのあたりは非常に楽しいです。「毎日楽しく開発したい」というのが私が仕事にもっとも期待することであり、それが達成できているかぎりは現職にいるでしょう。

2017年9月に生まれた子供(ハンドルネーム: mfx)もいまや4歳になり、どんどん口達者になってきました。またコロナ禍によって生活スタイルも激変し、オフィスが閉鎖されて100%自宅作業となって1.5年経ちました。仕事面でも生活面でも、振り返ると大変な2年間だったなあと思います。禍福は糾える縄の如し…。

ともあれ、次の一年も無事に過ごせますように🙏

GitHub ActionsからGitHub wikiを更新する

GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。

今回は、GitHub repoで管理する原稿の文字数(など)を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。

リポジトリはこんな感じです。

github.com

基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpushするだけです。 actions/checkout を使うことで適切なGitHub access tokenが生成されて使われるので、private repoでもcloneしたりcommitしたりできます。

git configの user.email が次のようになっており、少しトリッキーに見えるかもしれません。

git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"

しかし、このように設定することで実際のアカウントのメールアドレスを使うことなくGitHubのユーザーと適切にひも付きます。まあ、これはGitHub wikiに限らずGitHub Actionsからcommitするとき常に有効なハックですが。あとはまあ、YAMLに書いてあるとおりです。

Enjoy GitHub Actions!

Kindle Fire HD 10" が固定レイアウト書籍やPDFを読むのにとてもよい件

クリスマスプレゼントで妻からもらったKindle Fire HD 10"が思いの外よくて快適だなという話です。

Kindle Fire HD 10" (amazon.co.jp)

これまで電子書籍リーダーとしてはE-InkのKindleをここ数年ずっと使っていて、それはそれで軽量&電池長持ち&目に優しい仕様で十分に満足しているのですが、E-Ink端末は画面が小さくて固定レイアウトの書籍がとても読みづらいのです。というか、あまりに読みづらいので買っても読まないし、だんだん買わなくなってきたというのが実情でした。

物理書籍にはペラペラめくりやすいなどのいい面があることは重々承知しているのですが、とにかく物を増やしたくないし、手軽に手に取れる端末とちがって物理書籍を読む心理障壁もだんだん上がってきたなかで、(統計はとってませんが感覚として)電子書籍のほうが読了する率が上がってきていました。ここ数年は、物理書籍を年間10冊も買わないみたいな生活です。かといって固定レイアウトの書籍が読みづらいため読めないということをよしてとして受け入れているわけでもなく、ずっと心に引っかかっていたのでした。

そんな折に今回手に入れた Kindle Fire HD 10" は、E-InkのKindle端末を補間するデバイスとしてとてもよいです。大画面で固定レイアウトでも十分に読みやすいし、値段も約2万円で、これはほぼ同サイズのiPad (8th gen) の 3.5万円よりはるかに安価。Android OSがベースなのにGoogle Play storeが使えないせいで利用できるアプリには制限がありますし、1passwordアプリもありません。でも書籍しか読まないので制限があるのはそんなに大きな問題ではないんですよね。

これは久しぶりに使いでのある端末を手に入れたなあということで、大変満足しています。