nownab.log

ブログのデザインを変えた (2026 年版)

Sun, 20 Sep 2026 04:01:23 GMT

ブログのデザインを一新しました。前回変えたのは2023年なので、3年ぶりのデザイン刷新です。だいぶ見やすくなったのではないかと思います。

前回変えてから書いた記事が5件しかなかったので、もう少し記事を増やしたい。

開発環境式年遷宮 (2026年)

Mon, 23 Feb 2026 13:45:00 GMT

ローカル開発環境を式年遷宮しようと思い、既存の設定をすべて見直して一から作り直した結果、以前とほぼ同じになった。あまり変わらなかったが記録として残しておく。

今まで開発環境について記事を書いたことがなかった気がするので、今までの開発環境の変遷も思い出せる限り振り返ってみようかと思う。

きっかけ

複数の同僚から WezTerm や Nix の Home Manager を勧められていたところに、貸与 PC のリプレースのタイミングが重なり、SRE Kaigi でもらった熱量を活かして開発環境を見直すことにした。

OS

WSL (Ubuntu) のまま。特に移行はなし。

OS についてはこんな感じの変遷のはず。

Windows XP ～ 7
Mac OS X
Ubuntu
WSL (Ubuntu)

Windows 時代から Dual Boot で RedHat 系の Linux を入れて、開発ではそちらを使っていた。CentOS や Fedora が多かったと思う。他にもドラゴンがテーマでやたら GUI がぐりんぐりんするオレオレディストリなんかも使ってみたりしていたが、結局はメジャーかつ標準で使いやすいものということで Ubuntu に落ち着いた。Docker で Debian が使われることが多かったのもある。WSL2 が安定してからは、Dual Boot もめんどくさかったのでやめて WSL 一本でやっている。

Mac は勤務先から貸与される PC が Mac だったので個人でも買って使ってみてた事はあるが、Linux 以上の魅力が感じられずに Linux に戻った。

本当は WSL ではなく素の Ubuntu を使いたいが、ゲームをするために Windows を使っている。

dotfiles

dotfiles というか、ローカル開発環境の構築というか。Chezmoi から Nix Home Manager に移行した。

Chezmoi は 2 年前ぐらいから使い始めたが、Home Manager のほうが AI と相性が良さそうと感じて乗り換えた。

今までの方法を思い出せる限り時系列順で並べてみるとこんな感じ。

シェルスクリプト
itamae-go
mitamae
Chezmoi
Home Manager

mitamae 時代が一番長く気に入っていたが、ほぼ OS の差を考えることもなくなったのでよりシンプルな Chezmoi に移行して、今回 Home Manager に移行したという流れ。

エディタ

Neovim から Neovim になった。AstroNvim v4 を使っていたのが v5 になった。

以前は AstroNvim v4 をカスタマイズして使っていて、Telescope を snacks.picker に置き換えたいなど変えたいところがちょこちょこあり最初は自分でコンフィグをすべて書こうと頑張っていたが、面倒すぎたのと AstroNvim v5 で十分なことに気付いたので AstroNvim バージョンアップに落ち着いた。ただ、コンフィグは使い回さずに一から書き直した。

AstroNvim v4 時代は Cline や Cursor の盛り上がりで一瞬 VS Code を頑張って使ってみたりもしたが、Claude Code のおかげで Neovim に戻ることができた。感謝。

メインで使っていたエディタをだいたい時系列順に並べると多分こんな感じ。

メモ帳
TeraPad
サクラエディタ
Emacs
秀丸 (Tex、プログラミング)
Aptana Studio (Ruby)
NetBeans (Ruby)
Vim
Neovim

Vim をメインにし始めたのは、サーバーで作業することが増えて Vim で揃えるか、というのがきっかけだったと思う。Atom や Sublime Text、VS Code なども試しつつ、Vim (Neovim) を使い続けている。

ターミナル

基本は OS デフォルトのターミナルを使っている。今は Windows Terminal。

今回、WezTerm を試してみたが結局 Windows Terminal に落ち着いた。WezTerm は Lua で設定できるのが魅力的かつ、マルチプレクサの機能も持っていて tmux のレイヤーなくせるんじゃね、と野望を抱き結構頑張って設定したが、表示がバグる問題が致命的で本格採用できなかった。しばらく WezTerm を使ってみたが、マルチプレクサの機能が tmux に慣れていたためかしっくりこなかったので、落ち着くところに落ち着いた気はする。

これはバグった WezTerm 上の Neovim でファイルの保存を試みているところ。

ターミナルマルチプレクサ

今まで tmux wrapper の byobu を使っていたが、byobu をやめて素の tmux に移行した。

以前から byobu はやめたいと考えていたが、WezTerm の経由がきっかけでやめられてスッキリした。

byobu 以前は screen を使っていた。

シェル

zsh から変わらず。ただし、AI と Home Manager によって zplug が不要になった。

Vim を使い始めた頃に zsh を使い始めて、それ以前は bash を使っていた。

AI Agent

Claude Max を契約して Claude Code をメインで使っている。使い方としてはシェルで起動して使うのがメイン。Neovim から sidekick.nvim 経由で呼び出すこともある。

あとがき

AI のおかげで開発環境を一から構築し直すというのもだいぶ楽だった。開発環境構築のような作業もなくなっていくんだろうか。

2024 年の抱負

Thu, 04 Jan 2024 02:02:08 GMT

バナー画像は Stable Diffusion と Canva で作った。

やるぞ

上から優先順位が高い。

1. 健康になる

自分の健康。健康がないとなにもできない。今は肉体がボロボロなので回復したい。

リングフィットアドベンチャーをクリアする
整体に通う
- 2 週間に 1 回のペースをキープしたい
時間外労働を 10 時間/月に抑える
- 残業は健康の敵
- そもそも自分が何時間働いてるかよくわからない問題なんとかしなきゃ

2. 家族の健康を守る

妻と犬の健康。3 人とも虚弱体質で不健康なので健康でいられる術を模索中。

労働時間を減らしつつ収入を上げる
- 最も家族の健康に寄与するのは自由な時間と金
- 具体的には残業しない、プロモーションする、ぐらいしか思いついてない
- 本業以外に何かもう一軸欲しい
夕方に散歩する
- 2023 年後半は仕事で犬の散歩が遅くなった日が多かったので日が沈む前に散歩する

3. ずとまよのライブに行く

貴重な生命力源。

忘れずチケットに応募する
- 当たれ 🙏

4. 仕事を頑張る

1 と 2 のために必要。とはいえ今のところは意外なことに仕事に対するモチベは高い。

プロモーションする
- 以前は全く興味なかったけど、より大きな責任と裁量を持って大きな結果を生み出したいという欲が芽生えてきた
開発者体験がよさそうな会社としてナレッジワークが認知されるようにする
- 外から見える Platform Engineering の結果のひとつかな、と

5. 英語の勉強を再開する

生きていく上で圧倒的に有利。

1 月から毎日勉強再開する
- 勉強内容はなんでも。1 秒以上やれば OK
DUO 3.0 を 5 周する
英文解釈教室をやりきる
Busuu を毎日やる
ELSA Speak を毎日やる
カランメソッドを週 2 でやる
- 自分にあってそうなら年間通してやる
- 1 年で Stage 4 終わるぐらいだろうか
- あってなかったら他になにかやる。英語のハノン初級、英語のハノン中級とかかな
A Philosophy of Software Design, 2nd Edition を読む
- 英語の本を 1 冊通して読み切ったことないので読み切りたい
- 興味のある分野かつ読みやすそうな本

6. スプラトゥーンを頑張る

経験上ゲームをしないと息が詰まって死ぬことがわかってる。長くやってる趣味なのでせっかくなら目的を持ってやってみようかと。

サーモンランで全ステージカンストする
- 土日でよっぽどひどい編成じゃないときにやる
- 残りは~~アラマキ砦~~、シェケナダム、トキシラズいぶし工房
X パワー2500
- X マッチやる
- 今の最高 XP はガチホコの 2306.3
- どうやって 200 あげようか。配信とかして喋りながらやると上がるだろうか

7. 本を読む

本を読む習慣がないので本を読むをしたい。

なんでもいいから 2 ヶ月に 1 冊ペースで読む

8. 攻めの株を始める

労働以外から収入を得たい。

新 NISA の年間投資枠を埋めてから信用取引をやってみる
- スイングトレード想定

やらないこと

だらだら YouTube
だらだらスマホゲーム
だらだら X マッチ
だらだら SNS
義務シャケ
無駄遣い
なんとなくものを増やす
夜更かし
競プロ
- やりたかったけどできそうにない

おわりに

目標立てすぎて何もできなかったにならないように頑張る。根を詰めすぎると健康を損なうということもわかったので優先順位に従って頑張る。

とりあえず、記事書き始めてから書き終わるまでにアラマキ砦でカンストしたので幸先はよさそう。

2023 年を振り返る

Sat, 30 Dec 2023 18:13:00 GMT

はじめに

2023 年の振り返りです。とりとめなく、雑に時系列で振り返って感想を書いています。まったくまとまってないです。

仕事パートは「元 Googler が Knowledge Work に入社して2ヶ月経った」の続編でもあり「マンタローに勇気をもらって Google Cloud を辞めた話」へのアンサー記事でもあります。

仕事

ざっくり振り返る

2022 年末ごろから転職活動を始めました。第一候補は Google 社内での Software Engineer 職への異動でしたが、それに限らず他の会社のカジュアル面談などもやっていました。

2023 年 1 月、今所属しているナレッジワークの選考を始めました。Google 社内での職も変わらず探していて、社内転職サイトで良さそうな open position を見つけて応募しようとレジュメを用意していたんですが、次の日見るとその position の hiring manager はレイオフされていました。大規模レイオフにより社内転職サイトは機能しなくなり、日本ではいつあるんだ誰が対象なんだと不安な空気が漂い始めました。

2 月はそんな空気の中淡々と仕事をしていました。Google の採用に関してはいろんな噂があったものの、2 月中も採用はしておらず、計画もまったく不明という状態でした。

3 月、日本でのレイオフも始まりました。アメリカのようにチームメイトが急にいなくなるということはないですが、チームメイトがいなくなるという噂が届き始めました。パフォーマンスも行動も問題なく、むしろいつも頼りにしていた同僚との今後について相談する 1 on 1 でレイオフ対象になったと聞いたときの衝撃は今でも覚えています。 30 分のミーティング時間「まじすか」と言い続けて終わりました。事前に様々な材料からの推測で自分たちにそこまで大きな影響はないだろう噂されていたこともあり、自分のすぐ近くで相当数の同僚がレイオフ宣告されたことは非常にショックでした。結構ガチ目にショックを受けてガチ沈みしてました。仕事関係で生じた感情の大きさでいうと圧倒的な歴代一位ですね。完全にキャパオーバーでこんな状態で仕事と転職活動と一緒に続けられないということで、通っていた英語教室は辞めてしまいました。

自分が他人のことでこんなにショックを受けるのかというのは発見でもありました。レイオフってつらいんですね。外資で働き続けるとそのうち慣れるんでしょうか。

4 月、チームメイトもレイオフされ、採用もいまだ再開する気配がないということで、気持ちは Google 社外への転職にかなり傾いていました。ナレッジワークの選考は着々と進んでいて、オファーをもらい、ゴールデンウィーク明けに返事をしなければいけないという状態でした。それでも「Google で今得られていてこれからも得られるであろうもの」と「Google では今は得られてないけどナレッジワークでこれから得られるであろうもの」を天秤にかけて結論を出せないでいました。

来る 5 月 6 日、スプラトゥーン 3 でゼルダの伝説とのコラボフェスが始まりました。そしてマンタローの「エイエイエイ！エイ！」というセリフに感銘を受けてナレッジワークへの転職を決意しました¹。

6 月、転職を決める前にやると言っていたことはやりきろうということで、有給消化もほとんどなく、最終出社日までお客さんとのワークショップをやっていました。有給日数はだいぶ残ってたので休んでおけばよかったという気持ちもありつつ、なんとなくフェードアウトするのではなく最終日もがっつり仕事して辞めたのは自分らしくもあったし、やり切った満足感もあります。

最終出社して入社するまでの間に、社会人になってから初めて金髪にしました。これの背景には転職に伴う 2 つの決意がありました。この 2 つの決意は今までの自分の行動とナレッジワークでの自分の行動を明確に隔てているものでもあります。

1 つ目は、今まで培ったものすべてを賭して次の会社のビジネスアウトプットに貢献しようという決意です。あまりうまく言語化できてません。今までももちろん本気で仕事をしていたし、比較的オーナーシップを持って結果を出してきたとは思いますが、ビジネスとしてのアウトプットを見ていた訳ではないし、やりたくないことはできるだけやりたくなかったし、組織やマネージャーに甘えていた部分もありました。 Google という最高の環境からスタートアップという刺激的な環境に移るんだから、せっかくならそういう甘えを捨てて自分が持つ武器すべてを使って目線を上げて闘ってみよう、という決意です。下手な仕事ができないように追い込むという意味で目立つ外見にしました。金髪で下手な仕事してると「Google から来たやつがろくに仕事もできないのにイキってる」となるじゃないですか。

2 つ目は、1 つ目とも関連するんですが、顔と名前をインターネットに出して仕事をするという決意です。顔を出すなら、トレードマークになるようなものがあるといいなぁということで金髪にしました。今までなんで名前を出してなかったのかというと、インターネットに個人情報出してはいけないという強迫観念があるからでした。顔と名前を出すというのは金髪と同じで 1 つ目の決意を実行するために自分を追い込むためでもあります。顔と名前を出して下手な仕事はできないですよね。個人情報出してはいけない強迫観念は今でも全然あるんですが、出して失敗してもやり直しきくっぽいことはなんとなくわかってきたしこの機にやってやるか、という感じです。

今まで自分の名前を出すことはもちろん、会社の名前を出すことも人脈を使うこともかなり嫌いだったんですが、今は使えるもんは全部使うという方針でやっています。名前も会社名も積極的に出すし、元同僚に頼りまくってるし、堂々と元 Google というブランドを使い倒しています。

仕事のやり方も変わりました。自分のやりたいことではなく、今の会社に必要なことを考えて優先順位をつけるようにしています。また、できるだけ他の人が拾わない、拾えないボールを拾って、実行して、やり切ることを意識しています。こう書くと、別に以前からやっていたことではあるんですが、何かが変わっています。なんなんでしょうね。

7 月、ナレッジワークに入社しました。初月はオンボーディングということで社内に用意されているラーニングをやったりオンボーディングタスクをやったりしていました。 Google はもちろん今までの会社と異なるところも多く、なかなか慣れずにいた 1 ヶ月でした。ただオンボーディング期間にあぐらをかいてボーッとしてるわけにもいかないので、自分にできることを見つけてやるようにしてました。会社のメンバーとスプラトゥーンを一緒にやったりもしました。

8 月、本格的に仕事が始まった気がします。仕事を任されるようにもなり、Design Doc を書いて実装するということを一通りやったり、業務プロセスを改善したりしました。あと入社 2 ヶ月でインターンシップのメンターを 2 週間やるというのもありました。インターンシップは学生がみんな優秀で自分の刺激にもなったし楽しかったですね。

9 月、認証基盤を刷新するための Design Doc を書いてたりした気がします。また、今は Platform Group という社内の基盤を整えるようなチームに所属しているんですが、9 月頃は社内の様々な課題や会社が目指しているところなんかがわかってきたのでプラットフォームの将来像を描いたりもしていました。

10 月、社内向けに SRE のトレーニングを主催したり、Encraft #7 AppDev with Google Cloud というイベントで登壇したりしました。会社のカジュアル面談を担当するようにもなりました。

11 月、設計した新認証基盤の実装が本格化して、とにかく Terraform と Go を書いてた気がします。

12 月、新認証基盤の仕上げや別のバックエンドサーバー刷新プロジェクトの実装をしました。また、デプロイに大きくメスを入れ始めました。

ざっくり振り返るつもりが長くなったなぁ。非常に濃い 1 年でした。

転職してよかった？

よかったです。よくなかったこともありますが、圧倒的に良かったです。

ナレッジワークでは自分が今までの会社で経験したすべてを出せている気がします。データセンターでの運用、Platform as a Service の新事業開発、SaaS 開発、新規 SaaS プロダクトの立ち上げとそれに関わる Platform 構築、AWS から GCP へインフラの完全移行、データプラットフォームを構築運用、ML モデルの学習や ML システムの構築、エンタープライズ企業への営業活動、エンタープライズ企業へのクラウド導入支援、顧客への Enablement、顧客・パートナー・自社を巻き込んだプロジェクトマネジメント、これらすべてが今の仕事に活きています。これらの経験のおかげでレベルが高いナレッジワークのエンジニアチームの中でも自分にしか出せない価値を出せています。

経験を活かすだけならナレッジワークでなくても良いと思いますが、ナレッジワークだからこそ良かった点もあります。まずナレッジワークには自分の能力すべてを活かせる組織と事業があり、それを評価してくれます。また、今後まだまだ挑戦があり、各スペシャリストが揃っていることで自分の成長を促してくれることも確信しています。書くとシンプルですが、なかなか他の会社では得られないものだと感じています。

転職して 6 ヶ月、自分の中である結論がでています。営業活動は Software Engineering に活きる。Software Engineering に必要な新たな視点が自分に加わったという実感があります。Software Engineering が好きだけど何か新しいことをやってみたいという人や行き詰まりを感じている人には、もしかすると Pre-sales Engineer というのは良いキャリアパスの経由地なのかもしれません。Software Engineering だけでは得られない学びを得られることは間違いないです。ただし、Software Engineering が好きであれば好きなだけ厳しいことも間違いないので手放しでのおすすめはしません。

良くなかったこととしては、給料が下がったことぐらいですね。ナレッジワークも決して給料が低いわけではないので不満はないんですが、どうしても数字として明確に現れてしまうので Google と比べると低いなーと思ってしまったり、家計のやりくりが今までに比べると厳しくなっているという事実はあります。今までの退職・入社エントリでは避けていたんですが気になっている人も多いと思うので正直に書いておきます。

プライベート

プライベートに関する振り返りも記録として書いておきます。

車を買い替えた。前の車を、5 年後には自動運転できるようになってるやろ、と残価設定ローンを組んで買ったのでその買い替え。 5 年前の自分に 5 年後も自動運転は実現されてないことを教えてあげたい。

キャンプを始めた。うちはルビーという名前の柴犬を飼っていて、ルビーとも気軽に行けるんじゃないかってことでテントを始めキャンプグッズを揃えた。グッズを揃えたはいいもののいざ行ってみたらルビーはキャンプ嫌いっぽいのでどうしたもんかと悩んでる。

結婚指輪をなくして新しいペアリングを買った。まさか自分が失くすとは…。悲しかったけど、妻が一緒に新しいのを買いに行ってくれてよかった。どこに行ったんだろう。

ずっと真夜中でいいのに。のライブに 5 回行った。本当に全公演全曲最高だったけど、その中でも一番を選ぶとしたら 1 月の叢雲のつるぎの残機かな。炎によるライブ演出とライブ感あふれる演奏と圧倒的なハイトーンボイスが合わさってぶち上がって昇天した。

(動画じゃ全然伝わらないんだよなぁ)

スノボには雪での通行止めもあって 2 回しか行けなかったかな。今シーズンはもっと行きたい。

ゲームは相変わらずスプラトゥーン 3 ばっかりやってる。他にはティアキンを結構やった。Overwatch 2 なんかもやったな。

東北に一人旅した。普段は一人旅なんてしたいとも思わないけど、転職の有休が 1 週間ぐらいあって普段絶対にやらないことをやろう思って急遽決めて車で行った。青森まで行きたかったけど日程的にも運転的にもきつかったので宮城と岩手。御朱印帳を買ってお寺を巡ってみたり洞窟に行ったりした。岩手で泊まった今年 50 周年の宿ではめちゃくちゃうまい海鮮料理を食べてオーナーや他の宿泊客から昔話を聞いたりして、一人旅もたまにはいいかもななんて思った。

PC を新調した。3 年半営業職として頑張った自分へのご褒美として見た目も中身もこだわった最高グレードのものを買った。この記事の OGP 画像も新調した PC を使って Stable Diffusion で生成してみた。

いい歯医者を見つけた。かなり嬉しい。今の家に引っ越して 5 年経ってもいい病院が見つけられてなかったけど、ついにいい歯医者を見つけて安心した。眼科と耳鼻科も見つけないとなぁ。

ワタミの宅食を使い始めた。Nosh は美味しくなくて辞めたけど、ワタミの宅食は美味しくて続いてる。おばちゃんが毎日届けてくれて、そのおばちゃんもいい人でそれも含めてサービスとして満足してる。

親戚の葬式に行った。子供の頃に祖父が亡くなって以来のお葬式。悲しかったけど久しぶりに親戚で集まれた。

Golink という OSS を作った。Google の社内システムのクローン。Ex-Googler が多くの会社に持ち込んでる有名なシステムで、ナレッジワークでも使えないかなーと思って作った。

Pixel 6 Pro から Pixel 8 Pro に買い替えた。特に感想がないぐらいどこか変わってるのかいまいちわかってない。

久々な友達に会った。コロナで 3 年以上会ってなかった友達と会ったりした。

ドラム。今年はまったく叩いてない。Google 辞める前に社内のスタジオでちょっと叩いたぐらい。ほそぼそ続いてたバンドが休止になって機会がなくなったので、一人で個人練しようかなぁ。

漫画で今年印象に残ったのはなんだろう。妻が読み始めて一気に沼にハマってしまったワンピース、黄泉のツガイ、めっちゃ流行ってる気がする葬送のフリーレンが印象に残ってる。

おわりに

2023 年はとにかく濃かったです。サクッと書くつもりが結構なボリュームになってしまった。2024 年も濃い 1 年にしたいですね。

また、多くの人へ感謝した年でもありました。今年お世話になった方々、もっと前にお世話になった方々、本当にありがとうございました。来年からもお世話になるのでよろしくおねがいします。

最後に、今年かなり頑張った自分もお疲れ様。

それでは良いお年を。

マンタローに勇気をもらって Google Cloud を辞めた話 - nownab.log ↩

元 Googler が Knowledge Work に入社して2ヶ月経った

Wed, 06 Sep 2023 11:26:22 GMT

はじめに

6 月末に Google Cloud のカスタマーエンジニアを辞めるときに退職エントリを書いたのですが、思っていた以上に「共感した」という反響を頂きました。これは転職して実際どうだったかという結果も書かないといけないなと思い、Knowledge Work への入社エントリを書いています。

長くなってしまうので 2 つの記事に分けて書きます。本記事では Knowledge Work ってどんな会社なの？ということを、次の記事では退職エントリへのアンサーを書きます。

本記事:

Knowledge Work に入社を決めた理由
この 2 ヶ月 Knowledge Work で何をしていたのか
Knowledge Work に入社して実際どうだったか

2 ヶ月経って Knowledge Work へ SWE として転職した判断は正解だったのか
これから何をしたいか

Google Cloud を辞めた理由については退職エントリに書きました。

NOTE: 本記事には、この記事を読んで Knowledge Work に興味を持ってくれる人が増えたらいいなというささやかな願いが大胆に込められていますが内容はすべて本音です。

TL; DR と宣伝

Knowledge Work はとてもいい会社です
もし興味を持ってくださった方がいたら Encraft やカジュアル面談で気軽に話しましょう

10 月 6 日に Knowledge Work 主催の Encraft #7 というオフラインイベントに登壇します。懇親会もあるので興味がある方はぜひいらしてください。 YOUTRUST のカジュアル面談も作ってみました。X (Twitter) の DM でも大丈夫です。

Knowledge Work に入社した

改めて、7 月に Software Engineer として Knowledge Work に入社しました。

Knowledge Work は「できる喜びが巡る日々を届ける」をミッションとして掲げるプロダクトカンパニーです。現在はセールスイネーブルメントに特化したナレッジワークというプロダクトを開発・提供しています。

Knowledge Work に決めた理由

入社した理由について、入社前に転職活動をしていたときの目線で書きます。あくまでも入社前の転職先を探している時点・立場での内容です。

入社理由を一言で説明すると、転職活動時に考えていた Criteria を満たしてさらに加点ポイントがあったからです。 Criteria をどうやって決めたかですが、いろいろありつつ多くは「荒波に揉まれながらも楽しくソフトウェアエンジニアとして成長できる」がテーマになっています。

転職活動では以下のような基準で会社を選んでいました。多いです。Knowledge Work が満たしていると判断した Criteria には✅をつけています。

技術観点 - ソフトウェアエンジニアとして成長できる環境があるか
- (MUST) Google Cloud と Go を使っている ✅
  - 好きなものであり、これからスキルアップしたい技術でもあるため。
- (MUST) スピードと質の両立を目指している ✅
  - 開発生産性、セキュリティ、長期目線などを妥協なく両立しようとしている。これができること、重要であることを知っているということはチームが優秀なエンジニアで組織されていると考えているため。
- (MUST) 妥当な技術選定ができる ✅
  - 根拠がない判断で技術選定されたり、こちらの技術選定を理由なく拒否されると改善しようとする思考を停止させてしまうため。
- (MUST) CTO もしくはリーダーに技術力・バランス感がある ✅
  - 技術選定にも関わってくるし、CTO によって組織全体の技術レベルをどこまで引っ張り上げられるかが変わってくるため。
- (SHOULD) Design Doc を書く文化がある ✅
  - Google の Design Doc 文化がよかった、かつ、自分も Design Doc ベースの開発を身に着けたかったため。
組織観点 - ビジネスを成功させる再現性があるか
- (MUST) 採用に妥協していない ✅
  - 組織の人材レベルを高く維持しようとしている。妥協するとどんどん社内の様々な仕組みや基準が低くなっていってしまうため。
- (MUST) Value の Priority が高く、その Value に共感できる ✅
  - 行動指針や行動基準といったりするもの。Value に共感できてメンバー全員がその Value を発揮しているときストレスなく心理的安全で HRT に仕事ができるため。
- (MUST) 経営者がプロの経営者である ✅
  - CEO がただの創業者ではなくプロの経営者として会社を経営している。再現性があるビジネスの成功や健全な組織の維持のためには、経営者が会社の目指すべきところを定めてそこまでの道筋を設計して示したり、社員に必要な情報をしつこくインプットし続ける必要があると感じていたため。
ビジネス観点 - 自分が楽しめるか
- (MUST) ビジョン・ミッションに共感できる ✅
  - 大きな時間を費やすからには共感できるミッション達成のために働きたいため。
- (MUST) 中長期のゴールがあり、道筋が設計されている ✅
  - ないと行き当たりばったりで長期的な目線を持てず楽しくもなく成長できないため。
- (MUST) 安定したビジネスモデルがある ✅
  - お金を稼げるビジネスかどうか。例えば不安定な広告モデルよりは BtoB のサブスクリプションモデルのほうが好ましい。お金が稼げないと良い組織も作れないし、上場もできないし、エンジニアとして成長できる環境も維持できないため。
- (MUST) 自社プロダクトを作っている ✅
  - プロダクトを作るのが好きなため。
- (SHOULD) プロダクトが Web に閉じない
  - 現実世界に物理的に影響があるサービスなりプロダクトなりをやってみたかったため。
- (SHOULD) ビジネスが日本に閉じない
  - Google で働いて Global なビジネス、環境、働き方に良さを感じていたため。
その他 - 報酬や働き方
- (MUST) ある程度の報酬が出る ✅
  - 生活するため。(下がっても良い)
- (MUST) 出社必須ではない ✅
  - 犬の散歩 (ライフワーク) ができなくなるため。
- (SHOULD) スタートアップである ✅
  - 大きな裁量で働きたかったため。自分の成長のため。
- (SHOULD) 週 1 出社、週 4 リモートぐらいのハイブリッド ✅
  - ほぼ丸 5 年フルリモートやって、たまに他の社員と顔合わせると仕事に好影響があったり、楽しかったり、メンタルに良かったりすることがわかってきたため。
- (SHOULD) 英語を使える環境がある
  - 英語を身につけたかったため。
- (SHOULD) フルリモートも可 ✅
  - 隙あらば東京から移住したいと考えているため。

Google からの転職ということで基準は高く設定しました。Knowledge Work がこれらの基準を満たしていることを入社前にどうやって判断したかいくつか紹介します。

妥当な技術選定ができる
- GKEからCloud Runに移行した点や Modular Monolith を採用している点でかなり好印象でした。ここ数年はとにかく必然的な理由がなく Kubernetes だ、Microservices だ、というアーキテクチャが多かったので。
- スキル面接での CTO とのディスカッションも根拠になっています。
採用に妥協していない
- 採用プロセスがガチでした。面接もそうですが、プロセス全体を通して誠実さと本気を感じました。
Value の Priority が高く、その Value に共感できる
- Knowledge Work では Value ではなく、スタイルというものがあります。スタイルは Act for People、Be True、Craftsmanship の 3 つで構成されています。この 3 つには共感しかないし、自分がこうありたいと思えるスタイルだと感じました。
- スタイルを徹底してるなと感じたのは、カジュアル面談、スタイル面接、社長面接でした。それぞれ別の人が相手でしたが、一貫してスタイルを重要視していて、社員全員がスタイルを体現していると言っていました。
経営者がプロの経営者である
- これを間接的に感じたのはカジュアル面談、CTO への質問でした。転職活動中は必ず「社長どう？」と聞くようにしてましたが、総じてポジティブかつプロフェッショナルであるエピソードを聞けました。
- 直接的に感じたのは社長面接です。社員、組織、ミッションにどのように取り組んでいるのかを聞かせていただきました。

このように基準として考えていたものの他に次のような加点ポイントがありました。

リファラルしてくれた人が楽しそうだった
CTO が Google 出身だった
選考中に参加させてもらった社内ミーティングが良かった
プロダクトのテーマがセールスイネーブルメントで、カスタマーエンジニア時代に感じていた課題の解決に取り組める
オファーレターの “Why you” が良かった

この 2 ヶ月なにしてたの？

所属は Platform Group というプロダクトの基盤となる部分を開発したり、開発生産性を高めたり、インフラを整備したり、SRE したりするチームです。ざっくり言うと Team Topologies における Platform team ですがより広い範囲に責任があります。プロダクトの基盤を整えつつ Stream-aligned team から溢れたボールを積極的に拾いに行くようなイメージが近いかもしれません。

最初の 1 ヶ月はオンボーディングでした。7 月は四半期の始まりだったため 2 日間に渡る Quarterly の全社集会があり、セルフラーニングによる学習、ペアプロを経て、いくつかの簡単な機能を開発しました。

2 ヶ月目はオンボーディングも終わり独り立ちし始めたかなという感じです (まだまだですが)。この 2 ヶ月間でこんなことをやってました。

いくつかの機能開発 (表に出ない地味なやつ)
いくつかの Design Doc レビュー
データ分析基盤の設計・開発
認証基盤改善
アプリログ改善
Go のエラーまわり改善
Encraft の企画
インターンシップのメンター
運用フローの改善

最初の四半期はいろいろ手を出してみるという感じでやっています。

で、入社してどうだった？

で、実際入社してどうだったかというと、入社前と入社後でギャップがほとんどなかったです。Design Doc はしっかりと運用されているし、本当に全員がスタイルを行動指針としてミッションを実現しようとしています。

いくつか Knowledge Work の好きなところを紹介します。

スタイルがガチ
- Act for People、Be true、Craftsmanship が行動指針です。全員がこの ABC の実現を徹底的に目指しているので共感できる人はかなり働きやすいと思います。
社員全員優秀
- 前職の Google も周りはみんな優秀でしたが Knowledge Work も Google に負けないぐらいの優秀な人材しかいません。エンジニアだけではなく、HR、PdM、営業など全職種です。本当にすごい。
四半期の全社集会がアツい
- まだ 1 回しか参加してませんが、四半期ごとに全社の方針と各チームのゴールが共有される全社集会があります。社員の向く方向を揃えてモチベーションを高めるようないい場になっていると感じました。
Thanks を送る機会が多い
- Google にも gThanks という仕組みがあって好きだったんですが、Knowledge Work は感謝を送る機会が多いです。Slack で送る仕組みもあるし、直接伝える機会も設けられています。
Good & Opportunity フィードバック
- いい部分を Good、改善できる部分を Opportunity としてフィードバックする文化が定着しています。本当に Feedback is a gift で、フィードバックを受け取る機会が多いのは素晴らしいです。モチベーションになる Good と成長につながる Opportunity がセットになっているのもさらに良いです。
プロダクトシェアデイが良い
- セールス側とプロダクト側の情報交換をするための全社員が参加するミーティングを毎週開催しています。プロダクト側からは開発の方針や新機能の紹介、セールス側からはお客様からの Good & Opportunity の紹介をします。プロダクト側として参加してますが作っているもののフィードバックを毎週もらえるのがありがたいです。

おわりに

というわけで、まだ入社 2 ヶ月ですが Knowledge Work はいい会社だと感じています。本当にまわりの人全員が優秀で毎日ディスカッションするのが楽しいです。

いいことしか書いてなくて完成された組織に思われるかもしれませんがスタートアップらしくまだまだやることは山積みです。社員も絶賛募集中なので興味がある方はぜひお気軽にご連絡ください。素晴らしい環境の中で一緒に成長しましょう！　💪

また、10 月 6 日に Encraft #7 AppDev with Google Cloud というイベントを開催します。ぜひ遊びにきてください。

ブログのデザインを変えた (2023 年版)

Sun, 09 Jul 2023 08:24:34 GMT

2016 年から大きく変わってなかったブログのデザインを変えた。前からこういう感じにしたいなーと思いつつ放置してたけど、最近よくブログ書いてるのでやってしまおうということで。

全体的にスッキリさせつつ細かいところを調整した感じ。色を選ぶセンスがないのでできるだけ色は使わず、そうするとかなり味気無くなるのでカードグリッドで記事一覧を表示して画像でなんとかするという方針。

あとダークモードに対応した。

Before

After

Todo

以前の HTML/CSS を移植したわけじゃないので、多分記事によっては表示が崩れてるものがあるはず。最近の記事は大丈夫だと思うんだけど、見つけたらその都度修正する。

HTML/CSS が汚いのでなんとかしたい。と言いつつなんとかしなさそう。

PC を新調した (2023 年版)

Sat, 08 Jul 2023 09:32:54 GMT

6 月に新しくデスクトップ PC を買ったのでその記録。

新調した理由

今使ってるのもう 5 年ぐらい前のだし (調べたらちょうど 2018 年の 6 月ぐらいに買ってた)
円安だし 3年半働いた自分への褒美に RSU ちょっと売ってなんか買うかー
Generative AI 動かすために強い GPU ほしい
今 1 台で Linux (普段使い) と Windows (ゲーム) のデュアルブートしてて運用だるい
もっと古いデスクトップ PC の下取りしたい

BTO にした理由

今までのデスクトップ PC はすべて自作で組んできたけど、今回は自作じゃなくて BTO にした。パーツは選びたいけど組み立てはもういいかな、ってのとパーツの箱いらねってのが理由。

ブランドは arkhive にした。まずはこんな感じの基準で選んで arkhive と Sycom が候補になった。

RTX 4090 でつよつよ PC が組める
パーツが柔軟に選べる (マザボやケースも)
水冷

arkhive か Sycom で arkhive を選んだ理由はこんな感じ。

RTX4090 だと Sycom デュアル水冷はいらなそう
arkhive だと白色ベースでいい感じにカッコよくできる

パーツ

パーツ選定の基本方針はこんな感じ。

GeForce RTX 4090
Intel
できるだけ白
できるだけ光る
できるだけ最強
信頼してるメーカー(ASUS、WD)

選んだパーツはこんな感じ。今コンシューマー向けで選べるほぼ最強の構成になったと思う。

CPU: Intel Core i9-13900KF
M/B: ASUS ROG MAXIMUS Z790 HERO
メモリ: G.Skill DDR5-5600 32GBx2
GPU: ZOTAC GAMING GeForce RTX 4090 AMP Extreme AIRO
ストレージ 1: Western Digital WD_BLACK SN850X NVMe SSD
ストレージ 2: Samsung 980 PRO 4.0 NVMe SSD 2TB
ケース: Fractal Design Torrent White RGB TG Clear Tint
CPU クーラー: ASUS ROG STRIX LC II 360 ARGB White Edition
電源: SilverStone HELA 1200R Platinum
OS: Windows 11 Pro 64bit

メモリだけは欲しいのが BTO の選択肢としてなかったので自分で買って挿し換えた。

箱

考えたらわかるんだけど、これだけ自由にパーツ選べる自作好き向けの BTO が箱や付属品やマニュアルを送ってこないわけがなかった。というわけで PC とともにパーツの箱が大量に来たんだけど、RTX 4090 以外の箱は処分する予定。グラボは買い替えることもあるかなーってことで。

こんな感じのでっかいダンボールが 2 つ届いて、本体とパーツの箱だった。

感想

🌟大🌟満🌟足🌟 スペックはもちろん文句ないし、なにより見た目がカッコいい。見てるだけで癒やされる。

ゲームは最高画質がサクサク動くし、LLM や Stable Diffusion もそれなりにいい感じで動く。

BTO ということで組み立ては他人にやってもらったわけだけど、非常に丁寧でその点もよかった。これはマザボ裏の配線の様子。

今回デュアルブートはせずに Windows オンリーにしたけど、それもいい選択だったなと思ってる。まだ本格的に開発端末としては使ってないものの、WSL が優秀で今のところ困ってない。Windows じゃ開発できないよなぁって理由で渋々 Mac 使ってる人は Windows を検討してみてもいいかもしれない。少なくとも Linux を使ってた人は Mac より WSL の方が使いやすいんじゃないかな。

Windows 11 の WSL で GPU を使って rinna InstructGPT

Sun, 25 Jun 2023 04:06:47 GMT

はじめに

最近、念願のつよつよ GPU がついた PC を新調して WSL で環境構築を頑張っている。今回は GPU を使った LLM の推論を試した。

ここでの GPU は NVIDIA のもので、GPU の環境構築は WSL で CUDA を使えるようにすることを意味する。また、WSL の Distribution は Ubuntu-22.04。

LLM としては rinna 社の日本語特化 InstructGPT を使った。

GPU on WSL

基本的にこの手順に従って進めれば WSL で GPU が使えるようになる。具体的には、Windows 11 へ WSL 対応 NVIDIA ドライバのインストール、WSL 内で CUDA Toolkit インストールの 2 点。

NVIDIA ドライバのインストールは NVIDIA のドライバダウンロードサイトで Windows 11 のものを選んでダウンロードしてインストールする。最新のものであれば WSL 2 の CUDA サポートが入っている。自分の環境だとこんな感じ。

Windows 側でドライバをインストールすると、WSL 側でマウントしている /usr/lib/wsl/lib に CUDA の共有ライブラリなどが見えるようになる。

CUDA Toolkit はダウンロードページから WSL 用のものをインストールする。これは、Windows 側でインストールした NVIDIA ドライバが提供するファイルを上書きしないように配慮されている。自分の環境だとこんな感じ。

ただし、表示されたコマンドのまま進めると PyTorch が対応していない最新の CUDA (今だと CUDA 12.2) がインストールされてしまうので、こんな感じで対応しているバージョンをインストールする。

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.0-1_all.deb
sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda-11-8

nvidia-smi コマンドも使えるようになっているはずなので確認ができる。

❯ nvidia-smi
Sun Jun 25 12:15:35 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.04              Driver Version: 536.23       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 4090        On  | 00000000:01:00.0  On |                  Off |
|  0%   45C    P8              39W / 450W |   1184MiB / 24564MiB |      5%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

InstructGPT

今回コンテナは使わず Poetry の仮想環境で JupyterLab を起動して、Windows のブラウザからアクセスして rinna InstructGPT を使用した。

Poetry のインストールは asdf で。

asdf install poetry 1.5.1
asdf global poetry 1.5.1

適当にディレクトリを作って poetry init。

mkdir ~/jupyter
cd ~/jupyter
poetry init

pyproject.toml の dependencies はこんな感じ。url の cp310 は Python のバージョン。

[tool.poetry.dependencies]
python = "^3.10"
jupyterlab = "^4.0.2"
torch = {url = "https://download.pytorch.org/whl/cu118/torch-2.0.1%2Bcu118-cp310-cp310-linux_x86_64.whl"}
transformers = "^4.30.2"
sentencepiece = "^0.1.99"

依存ライブラリをインストールして起動する。

poetry install
poetry run jupyter lab

Windows 側のブラウザから http://localhost:8888/にアクセスする。トークンは JupyterLab を起動したコンソールにログとして表示されている。

まずはサンプルをそのまま動かしてみた。

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("rinna/japanese-gpt-neox-3.6b-instruction-ppo", use_fast=False)
model = AutoModelForCausalLM.from_pretrained("rinna/japanese-gpt-neox-3.6b-instruction-ppo")
model = model.to("cuda")

prompt = [
    {
        "speaker": "ユーザー",
        "text": "コンタクトレンズを慣れるにはどうすればよいですか？"
    },
    {
        "speaker": "システム",
        "text": "これについて具体的に説明していただけますか？何が難しいのでしょうか？"
    },
    {
        "speaker": "ユーザー",
        "text": "目が痛いのです。"
    },
    {
        "speaker": "システム",
        "text": "分かりました、コンタクトレンズをつけると目がかゆくなるということですね。思った以上にレンズを外す必要があるでしょうか？"
    },
    {
        "speaker": "ユーザー",
        "text": "いえ、レンズは外しませんが、目が赤くなるんです。"
    }
]
prompt = [
    f"{uttr['speaker']}: {uttr['text']}"
    for uttr in prompt
]
prompt = "<NL>".join(prompt)
prompt = (
    prompt
    + "<NL>"
    + "システム: "
)

token_ids = tokenizer.encode(prompt, add_special_tokens=False, return_tensors="pt")

with torch.no_grad():
    output_ids = model.generate(
        token_ids.to(model.device),
        do_sample=True,
        max_new_tokens=128,
        temperature=0.7,
        repetition_penalty=1.1,
        pad_token_id=tokenizer.pad_token_id,
        bos_token_id=tokenizer.bos_token_id,
        eos_token_id=tokenizer.eos_token_id
    )

output = tokenizer.decode(output_ids.tolist()[0][token_ids.size(1):])
output = output.replace("<NL>", "\n")
print(output)

ちゃんした日本語が出力される。

わかりました。コンタクトレンズを長時間つけっぱなしにしている場合は、目の周りに水ぶくれができやすくなります。また、コンタクトレンズを長時間つけたままにしておくことで、目にゴミやほこりが入りやすくなり、それらが刺激となってかゆみを引き起こすことがあります。そのため、コンタクトレンズを付ける前には必ず手を洗って、清潔な状態にすることが大切です。</s>

こんな関数を作っていろいろ遊んでみた。

def chat(prompt):
    prompt = f"ユーザー: {prompt}<NL>システム: "
    token_ids = tokenizer.encode(prompt, add_special_tokens=False, return_tensors="pt")

    with torch.no_grad():
        output_ids = model.generate(
            token_ids.to(model.device),
            do_sample=True,
            max_new_tokens=128,
            temperature=0.7,
            repetition_penalty=1.1,
            pad_token_id=tokenizer.pad_token_id,
            bos_token_id=tokenizer.bos_token_id,
            eos_token_id=tokenizer.eos_token_id
        )

    output = tokenizer.decode(output_ids.tolist()[0][token_ids.size(1):])
    return output.replace("<NL>", "\n")

Windows 11のWSL2でRTX4090使ってLLM動かせた！ pic.twitter.com/FsbVMZ0toe
— ぎっくり腰太郎 (@nownabe) June 24, 2023

メタルはあんま詳しくなさそう https://t.co/GTLceXCPek pic.twitter.com/PtkBdkLXUB
— ぎっくり腰太郎 (@nownabe) June 24, 2023

推論してるときのリソースはこんな感じ。

おわりに

ローカルで LLM 動くの楽しい！

マンタローに勇気をもらって Google Cloud を辞めた話

Sat, 17 Jun 2023 05:25:46 GMT

はじめに

昨日、Google Cloud のカスタマーエンジニアとしての最終出社日でした。退職日は 6 月末になります。いわゆる退職エントリです。

次はソフトウェアエンジニアとしての転職が決まっています。入社エントリはまた別で書ければと思っています。

本記事は、

Google Cloud で何をしたか
Google に入社してよかったこと
ソフトウェアエンジニアから営業職をやってよかったこと
辞めた理由
悩んだこと

という話を書きます。

Disclaimer

私が所属していたのは会社でいうとグーグル・クラウド・ジャパン合同会社になります。Google は非常に大きい会社で、本記事はあくまでも一事業部に所属した一人の退職エントリです。

また、時期的に近いですがレイオフとは無関係です。

Google Cloud で何をしたか

2020 年 1 月に入社して 3 年半 Google Cloud のカスタマーエンジニアをやっていました。カスタマーエンジニアはプリセールスエンジニアとも呼ばれるロールで、Google Cloud をお客さんに使ってもらって売上を増やすことが責務です。つまりは営業職です。

その中で日本の大手製造業を担当するチームの一員として、日本に住んでいれば誰でも名前を聞いたことがあるような会社を複数担当しました。担当したお客さんや営業メンバーの特色もあり、カスタマーエンジニアチームの中では活動内容の営業色が強いようなチームだったと思います。

カスタマーエンジニアとして具体的には次のようなことをやりました。

スライドを使った Google Cloud の紹介、各プロダクトの紹介、事例紹介など
事業内容、ビジネス課題、技術課題などのヒアリング
ソリューションやアーキテクチャの提案
PoC 計画立案、プロジェクトのスケジュール管理、ミーティングのファシリテーションなどのプロジェクトマネジメント
アーキテクチャレビュー、Q&A、トラブルシューティングなどの技術支援
ハンズオンやプロトタイピングなどのワークショップの準備・実施
社内の各種調整

書いていないことも含めると本当に様々なことをやったと思います。また、こうした営業活動以外にもサイドプロジェクトとして次のようなことをやりました。

社内用ツールの開発・運用
社内のデータ分析・可視化
ブログ記事の執筆
Google Cloud 関係の OSS への貢献

2022 年から最終出社日 (farewell message 投げながらワークショップしてました) までは TAP (Tech Acceleration Program) を中心に活動していました。TAP は 3 日間のワークショップで、お客さんのビジネスをヒアリングして課題やユースケースを明確にすることから始まり、その場でアーキテクチャを検討し、実際に動作するプロトタイプを構築します。TAP に関しては製造業チームでのリードやプログラム自体の運用改善をしていました。ワークショップ中にはファシリテーションをしつつ瞬時に最適なアーキテクチャを導き、アジェンダを動的に最適化して、瞬発的なデバッグをすることが必要でした。この活動が最も自分の良さを発揮できていたと思います。

Google に入社してよかったこと

所属は日本のクラウドチームでしたが、福利厚生や各種制度、社内ツールなどは Google Japan や Google 本社と同じでした。3 年半と長くはない期間でしたが、Google で働いてみてよかったことはたくさんありました。いくつか紹介します。

Google と言えば、という良さ。Google と言えば働きたい企業ランキング上位で、多くの人が働きやすく待遇が良いというイメージを持っていると思います。その点はイメージ通りでした。世界最高の会社の 1 つなんだろうと思います。報酬は高く、福利厚生は充実していて、オフィスはオシャレで機能的、サラリーマンとしては最高の環境で働くことができました。
優秀な同僚が多い。びっくりするほど同僚が優秀で、みんな尊敬できる人たちでした。多くの同僚に共通して感じたことは、しっかりと会話ができ、難題を解決するために思考し自発的に行動し、向上心があるという点です。これがベースにあり、さらにそれぞれが専門性を持っています。彼ら彼女らと出会って一緒に仕事ができたことは本当によかったと思います。
Google の技術はすげぇ。Google の技術はやっぱりすごいです。Google Cloud の中身もすごいです。それらの技術を知ったり触る機会があったのは最高にエキサイティングでした。
DEI。Google は DEI (Diversity、Equity、Inclusion) に非常に力を入れています。Google に入社するまであまり意識することはなかったのですが、社会にとって大事な要素だと考えるようになりました。

営業職をやってよかったこと

ソフトウェアエンジニアとしては得られなかったであろう貴重な経験ができました。

最も良かったと感じているのは「ヒトを動かす」ことを明確に意識できるようになったことです。3 年以上やってみて営業はヒトを動かすことが仕事だと考えるようになりました。Win-Win の結果を達成するために社外と社内のヒトを動かす過程をデザインし、地道にコツコツ実行し、良い人間関係を構築して、背中をひと押しする、それが営業で大切なことかなと。ソフトウェアエンジニアの仕事がソフトウェアを作って動かし続けることだとすると、営業の仕事は人間関係を作ってヒトを動かし続けることです。

このヒトを動かすというのは考えてみればソフトウェアエンジニアにとっても重要です。今まで無意識にやっていた部分はありますが、意識できるようになったことでより大きな成果を出せるような気がしています。

他にも良かったことがあります。例えば、様々なお客さんと会話し、様々なビジネスを知り、関われたことは非常に良かったです。視野が広がったのはもちろん、日本はこの人たちがこうやって支えていたのか、と聞いていてワクワクすることもありました。営業といえば気難しいお客さんを接待して何かあれば平謝りするみたいなイメージがありましたが、実際はいいお客さんが多く、楽しく建設的なディスカッションもできました。

また、そんな名実ともに日本を支えているお客さんの役に立つことで、日本という国の役に立っていると実感することもできました。特に TAP は内製化支援がテーマであり、日本の GDP の 20% を占める製造業の内製化を進めることで大きく日本に貢献できる可能性があると考えています。まだまだ道半ばでこれからというところではありましたが、その活動の立ち上げに大きく貢献できたことは誇りです。

辞めた理由

辞めた理由は大きく 2 つです。1 つ目はソフトウェアエンジニアに戻るため。2 つ目はレイオフの影響で社内異動が難しくなったためです。

入社エントリにも書いていますが、入社したときから 2、3 年やってみて次のキャリアを考えるというのは決めていました。そして考えた結果、ソフトウェアエンジニアとして再度チャレンジすることを決断しました。

その理由としては、カスタマーエンジニアではソフトウェアエンジニア的なスキルがほとんど伸びないからです。Google Cloud の幅広い知識や社内のコネクションを活かした対応力は向上したかもしれませんが、自分自身のソフトウェアエンジニアとしてのスキルは入社時に比べてむしろ下がっています。自分のカスタマーエンジニアとしての強みはソフトウェアエンジニアのスキルがベースにあったので、この 3 年半はまさに貯金を切り崩している状態でした。

ソフトウェアエンジニアがやりたいのであれば Google 社内でポジションを探せばいいのでは、という疑問はまったくそのとおりで、社内のソフトウェアエンジニアのポジションも探していました。それと同時に、スタートアップの混沌の中で物事を解決していくのも好きだったので、社外でも色々と話を聞いていました。

そんな中、社内のちょうどいいポジションを見つけて応募しようとレジュメを書いているときにレイオフがあり、そのポジションはなくなり、採用も全社的にストップしました。今回のレイオフは本当に何もわからず、第 2 波がある、来月採用が再開する、いや採用は 1 年後になる、などいろんな噂があり、先行きが全く見えず社内異動のモチベーションもなくなってしまい、社外への転職一本に絞りました。

とは言え転職先を妥協したということはまったくなく、ここに行きたいと思える会社からオファーをいただけたのは本当に良かったです。

悩んだこと

Google を辞めるかどうかは本当に悩みました。早くソフトウェアエンジニアとしてのキャリアを再出発させたい、次の会社でチャレンジしたいという気持ちは強かったのですが、とにかく手放すものが多かったです。高い待遇、福利厚生、世界最高のオフィス、おしゃれで美味しい社内食堂、優秀な同僚、社内の便利ツール、Google の素晴らしい技術、英語環境、DEI と心理的安全性が前提の環境、これらを手放す必要がありました。オフィスに行って美味しいランチを食べたり、これから Vest される株の金額を見るたびに辞めたくない気持ちが高まるということを繰り返していました。離職率に悩んでいる会社はぜひ参考にしてください。本当に効果があります。

話が逸れましたが、ぐだぐだ悩んでいる中オファーをもらい決断を迫られました。そんなとき、スプラトゥーン 3 のゼルダの伝説コラボフェスが始まりました。

『ゼルダの伝説ティアーズオブザキングダム』の発売に合わせて、「ゼルダの伝説」シリーズとのコラボフェスが開催されることになったぞ！
お題は「汝、何を求める？力 vs 知恵 vs 勇気」。
期間は、5月6日(土)9:00～5月8日(月)9:00の48時間だ。
どれか一つ手に入るなら、キミは何を望むだろうか？pic.twitter.com/8L2V4YIoyI
— Splatoon（スプラトゥーン）(@SplatoonJP) April 14, 2023

そのときのマンタローのセリフがこちらです。

悩んでいたときにフェスというライブ感のあるイベントでこれを見て、割とガチで心に響いて辞めることを決意しました。自分のスキルやキャリアの停滞を感じていたところでもあったので勇気を持って前に出ようと。

今では僕の座右の銘は「エイエイエイ！エイ！」です。

ちなみにティアキンはまだクリアできていません。

おわりに

3 年半、comfort zone から抜け出し慣れないことに挑戦してなんとかやりきった自分を褒めたいです。本当によく頑張った。一緒に僕のことを褒めてくれる方はこちらからお願いします。

読み返すまですっかり忘れてたんですが入社エントリでは次のような意気込みを書いていました。

やるからには本気でやります！💪 🔥

今はまだ何もやってないのでカスタマーエンジニアって名乗るのに抵抗があるんですが、早く何か成し遂げて自信を持って名乗れるようになりたいです。

向いてなかったらソフトウェアエンジニアに戻るとは書きましたが、数年はやってみようと思ってます。もしやめるとしても、カスタマーエンジニアやってましたと堂々と言えるようになっていたいです。

3 年半経った今、胸を張ってカスタマーエンジニアやってましたと言えます。

3 年半の間、いつも助けてくれて相談に乗ってくれたカスタマーエンジニアのメンバー、一緒に苦労し這いずり回った営業のメンバー、同期入社でサポートし続けてくれたマネージャー、そして Google Cloud を使って何かを成し遂げようと一緒にチャレンジしてくれたお客さんの皆様、みなさんのおかげで貴重な経験をさせていただき成長できました。本当にありがとうございました。Google Cloud に入社してカスタマーエンジニアができてよかったです。

次もがんばるぞい💪 🔥

自分のウェブサイトを GitHub のプロフィール README と同期させた

Wed, 03 May 2023 14:21:28 GMT

GitHub のプロフィールの Markdown をレンダリングして個人サイトと同期するようにした。

個人サイトあるけど、内容は薄いしデザインも凝ってないし、ちょっと前に作った GitHub の profile README で内容ほぼカバーできてるしそっから同期させたい、ってのがモチベ。

個人サイトを廃止していいのではという気もするが、GitHub というサービスに依存するのではなく自分のドメインをインデックスとしておきたいし、いろんな場所から既にリンクしてしまっているのでこういう方法を取ることにした。

デザインに関しては、時間かけて考えたくないし、マスターは GitHub にあるんですよということがわかりやすいように GitHub のデザインを~~パクっ~~参考にした。

同期の方法は単純で、nownabe/nownabe.com リポジトリの GitHub Actions のワークフローを定期的に実行して、ワークフローでサイトの生成と GitHub Pages へのデプロイをしている。README の Push をトリガーにしていないのは、README が別リポジトリにあって連携がめんどくさいのと、同期に数時間や数日の遅延があっても構わないというのが理由。Pages を README のリポジトリに移行するというのも考えたけど、個人サイトはなんだかんだ変遷があってまたいつ別の方法を取るかわからないのでプロフィールから切り離しておいた方がいいだろうということでこの構成にした。

ワークフローの中では次のように処理を行っている。

最新のプロフィール README を Actions のローカルに持ってくる (プロフィールリポジトリはパブリックなので簡単に持ってこれる)
Ruby スクリプトで README を HTML にレンダリングして、ERB のテンプレートに差し込み、dist/index.html に出力する (dist/ には予め必要な画像や CNAME ファイルが入っている)
actions/upload-pages-artifact で dist/ をアーティファクトとしてアップロードする
actions/deploy-pages でアーティファクトを GitHub Pages にデプロイする

また、これをするために、リポジトリの Settings で Pages のソースを GitHub Actions に設定しておく。

詳しく知りたいという人がもしいたら、nownabe/nownabe.com を見てもらうのが一番わかりやすいと思う。なにせワークフローの YAML と簡単な Ruby スクリプトしかない。

今回 Markdown パーサーに Redcarpet を使ったが、GitHub のパーサーと互換性がなくて、少し README を書き換えた。具体的には、次のような <details> の中の Markdown を解釈してくれなくて、<details> の中をすべて HTML に書き換えた。

## Articles

<details>
  <summary>Other articles</summary>

* list item 1
* list item 2
</details>

というわけで、個人サイトのことを考えなくてよくなってとてもスッキリしました。

ob_start についての補足

Thu, 21 Apr 2022 13:55:21 GMT

はじめに

先日 ZUTOMAYO FACTORY「鷹は飢えても踊り忘れず」で表示されていたプログラムについてという記事を書きました。この記事ではずっと真夜中でいいのに。のライブで現れた PHP のプログラムをずっと真夜中でいいのに。の世界観で解釈することを試みました。その際に、ライブのタイトルにもなっている ob_start という関数にはどう解釈すればいいか悩まされました。本記事は先日の記事の補足記事であり、先日の記事での解釈に PHP 素人が何を調べてどう至ったかという過程をメモしておきます。

本記事ではある程度の Web プログラミングの知識を前提とします。もしエンジニアでない方がこの記事を読んでいたら、ob_start の特徴まとめまで読み飛ばしてください。

PHP という言語

ob_start を理解するためにはまず PHP (PHP: Hypertext Preprocessor) の特徴を知っておく必要があります。 PHP は今では汎用言語として利用されていますが、元々はただの HTML 用のテンプレートツールであり、今でも HTML に埋め込むような構文を特徴としています。

例えば、現在の日付を HTML で表示したい場合、次のような PHP スクリプトで実現できます。

<!DOCTYPE html>
<html>
<head>
  <title>My Website</title>
</head>
<body>
  <h1>My Website</h1>
  <p>
<?php
  echo "今日の日付は";
  echo date("Y/m/d");
  echo "です。";
?>
  </p>
</body>
</html>

<?php ... ?> の部分が PHP のプログラムであり、これを実行すると次のような出力が得られます。

<!DOCTYPE html>
<html>
<head>
  <title>My Website</title>
</head>
<body>
  <h1>My Website</h1>
  <p>今日の日付は2022/04/21です。</p>
</body>

このように、<?php ... ?> で囲まれていない部分が PHP プログラムとして valid でありかつそのまま出力されるという仕様は、PHP の起源でもあり ob_start が必要となる重要な仕様でもあります。

ob_start とは

ob_start関数は出力のバッファリングを有効にする関数です。 ob_start() で有効化したバッファに書き込んだ文字列を利用するには、ob_get_contents() で文字列として取得するか、 ob_end_flush() で出力します。また、ob_start によるバッファはスタックができます。

ob_start() を使うと、上記のプログラムは次のように書けます。

<?php
  ob_start();
  echo "今日の日付は";
  echo date("Y/m/d");
  echo "です。";
  $date = ob_get_clean();
?>
<!DOCTYPE html>
<html>
<head>
  <title>My Website</title>
</head>
<body>
  <h1>My Website</h1>
  <p><?php echo $date; ?></p>
</body>
</html>

これぐらいの例だと使うメリットはないように思えますが、例えば Wordpress では多用されています。 WordPress では部分テンプレートの描画に使っていたり、複雑に HTML と PHP が混在するような描画処理を変数へ格納するのに使っていたりするようです。

WordPress では「ブラウザのエディタでユーザーが HTML + ちょっとしたスクリプティングで View を自由に書ける」ようになっています。その実態は単純にユーザーが PHP スクリプトを書いているだけであり、それは PHP が HTML のテンプレートとして振舞い ob_start がそれを柔軟に扱うことで実現しています。

また、ob_start で PHP の出力を全部キャプチャーできるため、テストで使われることもあるようです。

ob_start の特徴まとめ

このように調べたところ、ob_start は以下のような説明が可能であることがわかりました。

出力をバッファリングする
バッファリングした出力は文字列として取り出したり、出力せずに消去したりできる
バッファはスタッカブルである
HTML テンプレートの柔軟な構造化に用いられる
HTML と PHP が複雑に混在するような描画を処理するときに用いられる
テストで用いられる

ob_start の解釈

今回のプログラムを解釈する上で「HTML と PHP が複雑に混在するような描画を処理するときに用いられる」という特徴に注目しました。これはつまり、ob_start が HTML と PHP という 2 つの世界を橋渡しする役割を担っています。

このことから、鷹踊プログラムに出てくる ob_start も何か 2 つの世界をつなげるという意味を持っているかもしれないと考えました。鷹踊プログラムでは ob_start の直前でも 2022 年の $we と 2122 年の $we2 をつなぐようなプログラムとなっています。

$we2 = Worker::getWorking(); // 私達は生きている。
assertFalse($we->place == $we2->place); // たとえ生きる居場所が違くたって
assertFalse($we->period == $we2->period); // たとえ生きる時代が違くたって
assertSame($we->enthusiasm, $we2->enthusiasm); // 私達の熱を決して奪うことは出来ない
/* 2122.04.17 */
ob_start();

もうひとつ重要なポイントとして、ob_start が「PHP の世界ではメインの処理であり存在目的でもある HTML の描画を今から初めますよ」という宣言であることにも注目しました。成り立ちや使われ方、言語仕様からみても PHP は HTML を描画することが存在目的です。もちろん PHP のプログラムは全体を見ると HTML を描画する以外にも多くの処理をこなしていますが、やはり主役であり最終目的は HTML の描画と言っていいでしょう。そして、ob_start はその存在目的である HTML 描画の合図になっています。

このことから、鷹踊プログラムの ob_start も「自分の存在を開始する」というような意味がこめられているのではないかと考えました。

おわりに

熱が冷めないうちに、考えたことを忘れないうちに、補足を書いてみました。

ob_start() 以外の部分は比較的ストレートに解釈できる部分が多かったのですが ob_start に関してだけはこの記事に書いたようなプロセスで調べて考える必要がありました。なかなかプログラマーじゃないと伝わらない ob_start のニュアンスや感覚はあるとは思いますが、何かの参考になれば幸いです。

先日の記事の感想と同じですが、プログラムをこのように読み解いていくのは非常に楽しい作業でした。ずとまよには普段から素晴らしい音楽を提供してもらってるのに、こんな完成度が高く読み応えのあるプログラムまで提供してもらって感謝の念に堪えません。プログラミングにこんな楽しさもあるんだというのは新しい発見でした。

それでは。

ZUTOMAYO FACTORY「鷹は飢えても踊り忘れず」で表示されていたプログラムについて

Mon, 18 Apr 2022 14:41:48 GMT

はじめに

ずっと真夜中でいいのに。のライブ Z FACTORY「鷹は飢えても踊り忘れず」に参加してきました。ライブはもうただただ最高だったので感想も書きたいところですが、この記事ではライブに関連して現れたプログラムについて調べてみようと思います。また、できるだけプログラマーではなくてもわかるように噛み砕いて説明します。

注意点

私は歌詞や MV の考察はできないので、本記事で取り扱うのはあくまでもプログラムや ZTMY LEAKS から読み取れる内容だけです。また、PHP については素人同然なので的外れな部分があるかもしれませんがご了承ください。

ライブで現れた 3 つのプログラム

私が確認できた範囲では今回のライブで 3 つのプログラムがあったようです。

バナー画像のプログラム
[day1 “memory_limit = -1”] のプログラム
[day2 “ob_start”] のプログラム

以下ではそれぞれについて調べてみます。[day1 “memory_limit = -1”] のプログラムと [day2 “ob_start”] のプログラムは非常に似ていますが、おそらくずとまよにおけるストーリーや世界観の中で重要な役割を持つ変更が追加されているので別のプログラムとして取り上げます。

バナー画像のプログラム

1 つ目は「バナー画像のプログラム」です。このプログラムはずとまよの公式サイトやグッズパンフレットの画像の中に登場しています。

バナーのプログラムは JavaScript というプログラミング言語で書かれています。 JavaScript は Web サイトでよく使われるプログラミング言語で、バナーのプログラムも実際にずとまよ公式サイトで使われている JavaScript プログラムから引用されています。例えば公式サイトのトップページでは再生ボタンをクリックしたら YouTube の動画を再生できたり、お知らせウィンドウを移動できたりしますが、そういった部分の制御にこのプログラムが利用されています。

公式サイトで使われている JavaScript プログラムの一部に次のような部分があります。(プログラム全文はこちらから確認できます)

var TopAnim = (function () {
  const topObj = $("#articletop");
  const _menu = topObj.find(".ztmy-top--nav li a span");
  const _news = topObj.find(".ztmy-top--news");
  const _mv = topObj.find(".ztmy-top--mv");
  // const _rule = CSSRulePlugin.getRule(".ztmy-top--nav li a:before");

  return {
    Init: function (url) {
      const tl = gsap.timeline();

      // tl.staggerTo(_rule, 0.3, {cssRule: {width: "100%"},delay: 0.5,stagger: 0.3});
      // tl.staggerTo(_rule, 0.2, {cssRule: {left: "100%",width:0},delay: 0.2,stagger: 0.3});
      gsap.to(_menu, 0.2, {
        width: "100%",
        delay: 1,
        stagger: 0.1,
        ease: Power2.easeInOut,
      });

      if (isSmartPhone()) {
        gsap.to(_news, 0.5, {
          opacity: 1,
          scale: 1,
          delay: 0.5,
          stagger: 0.3,
          ease: Sine.easeOut,
        });
      } else {
        gsap.to(_news, 0.5, {
          opacity: 1,
          scale: 1.5,
          delay: 0.5,
          stagger: 0.3,
          ease: Sine.easeOut,
        });
      }

      gsap.to(_mv, 1, { right: 25, delay: 2.5, ease: Power2.Back });

      // var tl = gsap.timeline({ repeat: -1, yoyo: true });

      // tl.staggerTo(_rule, 1, {
      //   cssRule: { left: 100 },
      //   ease: Power2.easeInOut
      // }, 0.5);
    },
  };
})();

このプログラムはバナー画像の左列のプログラムと一致します。真ん中の列、右の列も同じプログラムの別の箇所が引用されています。

ただし、公式サイトのプログラムとまったく同じではなく、バナーのプログラムには 3 つの英文と 2 つのことわざが追加されています。これらは引用元のプログラムにはなく、JavaScript の文法にも違反していることから画像のために追加されていることがわかります。

[左列] Every second is of infinite value. (一秒一秒には無限の価値がある)
[中列] Forever is composed of nows. (永遠は多くの今で構成される)
[右列] It is not that we have a short time to live, but that we waste a lot of it. (生きる時間が短いということではなく、多くの時間を無駄にしているのである)
[右列] 雀百まで踊り忘れず
[右列] 鷹は飢えても穂を摘まず

ことわざは今回のライブタイトルの元ネタでしょう。 3 つの英文は後述する [day1 “memory_limit = -1”] のプログラムと [day2 “ob_start”] のプログラムの内容とも一致します。そのため、ライブのテーマとして重要な意味を持つことが推測できます。 ACA ねさんの MC とも関連しているように思えます。

[day1 “memory_limit = -1”] のプログラム

私が参戦したのは 2 日目だったので直接確認したわけではありませんが、ライブ開始前のディスプレイに表示されていたようです。また、ZTMY LEAKS にも 1 日目 (2022 年 4 月 16 日) に memory_limit = -1 というタイトルで、ディスプレイと同じものと思われるプログラムが投稿されています。

ZTMY LEAKS から引用したプログラムの全文はこちらです。

$we = Worker::getWorking(); // 私達は存在している。
define(People::lifetime()->every_second, INFINIT_VALUE); // 1秒1秒には無限の価値がある。

if ($we->think(People::lifetime()->length > $we->lifetime()->expected)) { // 私達の生きる時間が短いのではなく、
  while (!$we->die()) { $we->setRole(Role::MACHINES); } // 私達がその多くを無駄にしているのだ。
}

$forever = (new Forever([ // 永遠は、いくつもの現在から成り立っている。
  "params" => array_map(function ($someone) {
    return $someone->lifetime()->now;
  }, $we)
]))->compose();

while ($forever->night()) { // どんな夜も、私達は踊り続ける。
  $we->dance(Mode::DIGINIFIEDLY); // 尊厳を持ち、
  $we->dance(Mode::COURTEOUSLY); // 礼節を重んじ、
  $we->dance(Mode::TENACIOUSLY); // 粘り強く。
}

assertSame(TONIGHT, $forever->night()); // この夜もそうでなければならない。

/** 2022.04.16 */
memory_limit = -1;

このプログラムは PHP というプログラミング言語で書かれています。 PHP は Web サイトでよく使われる言語で、ずとまよの公式サイトや ZTMY LEAKS でも PHP が使われているようです¹。例えば ZUTOMAYO PREMIUM のログイン処理などで使われていると考えられます。

また、この ZTMY LEAKS の記事に John Titer が次のように返信しています。

時代は末期。そこは「灰版電機工業㈱」が権威を奮う世界。抑圧され感情が乏しくなった工場職員が労働を続けている。――。ふと電撃が走る。それに呼応して現れた見た事のない機械を構える職員、時空の歪み、別世界線との交差。工場のレーンにはこの世界にないものが流れ、やがて混ぜられた。そこには感情(bug)を持つ”人間”という種が生成された。

memory_limit = -1

感情(bug)の連鎖が始まる。工場職員たちも自分のメモリを開放し、世界に抗う。

――。

灰版電機工業は勘ぐれい、Ham、袖のキルトなどの MV に登場しています。

プログラムの解説

ここからプログラムを読み解いていきたいと思います。

前提

まず、大きな前提として、プログラムとプログラムではない部分について理解しておく必要があります。例えば、1 行目は次のように // で区切られています。

$we = Worker::getWorking(); // 私達は存在している。

// より右側の部分は「コメント」と呼ばれ、プログラム的な意味は持ちません。左側の PHP プログラムを読む人が理解しやすいように、日本語で補足をするコメントが書かれています。また、下から 2 行目の /** 2022.04.16 */ もコメントです。

プログラムの内容

では 1 行ずつ見ていきます。

$we = Worker::getWorking(); // 私達は存在している。

$we は変数と呼ばれ、データを格納します。例えば、$pi = 3.14; とすれば $pi 変数には 3.14 という数字が格納されます。

Worker::getWorking() は、全 Worker のうち動いている (working な) Worker を取得 (get) します。そのため、$we 変数には現在動作している Worker 全員のデータが格納されます。

define(People::lifetime()->every_second, INFINIT_VALUE); // 1秒1秒には無限の価値がある。

define(A, B) は A を B として定義します。例えば、define(PI, 3.14) とすれば PI が 3.14 として定義されるので、その後のプログラムでは PI を 3.14 と同じ意味で使うことができるようになります。

ここでは、People::lifetime()->every_second (人間の一生の一秒一秒) を INFINIT_VALUE (無限の価値) として定義しています。

if ($we->think(People::lifetime()->length > $we->lifetime()->expected)) { // 私達の生きる時間が短いのではなく、
  while (!$we->die()) { $we->setRole(Role::MACHINES); } // 私達がその多くを無駄にしているのだ。
}

こちらはこのブロックでひとつの意味を成すプログラムですが、少し複雑なので日本語で表現してみます。

もしも (私達はこう考えるならば (人類の一生の長さ より 私達の一生の期待 が短いと)) {
  死ぬまで繰り返す { 私達に役割を与える 機械であるという }
}

ここで、「私達」と表現しているのは $we であり、現在動いている Worker 全員を意味します。これをさらに日本語として意訳するとこんな感じでしょうか。

もし、私達が人類の一生より自分たちの一生が短いと考えるならば、死ぬまで機械であることを繰り返す。

プログラムの解釈としてはこうなりますが、意味したいところは「もし、自分たちの一生が短いと感じるのであれば、それは機械のように過ごすことを繰り返しているのだ」ということかなのかもしれません。こう解釈すると、コメントの「私達の生きる時間が短いのではなく、私達がその多くを無駄にしているのだ。」が理解できる気がします。

$forever = (new Forever([ // 永遠は、いくつもの現在から成り立っている。
  "params" => array_map(function ($someone) {
    return $someone->lifetime()->now;
  }, $we)
]))->compose();

こちらも複雑なのですが、キーとなるのは中心にあるこの部分です。

array_map(function ($someone) {
  return $someone->lifetime()->now;
}, $we)

こちらは、$we のそれぞれ、つまり、それぞれの Worker の「今」を列挙するというプログラムになっています。これを使いつつ、意味が変わらないようにわかりやすくプログラムを書き換えると次のように成ります。

$forever = (new Forever(それぞれの Worker の今))->compose()

さらに日本語で書き換えるとこうなります。

$forever = 「それぞれの Worker の今」から永遠を構成する

つまり、$forever 変数には現在動いている Worker それぞれの今から構成された永遠が格納されます。

while ($forever->night()) { // どんな夜も、私達は踊り続ける。
  $we->dance(Mode::DIGINIFIEDLY); // 尊厳を持ち、
  $we->dance(Mode::COURTEOUSLY); // 礼節を重んじ、
  $we->dance(Mode::TENACIOUSLY); // 粘り強く。
}

while (条件) { プログラム } は条件が正しい限り {} で囲われたプログラムを繰り返すという意味になります。

$we->dance(モード) は指定されたモードで Worker 達が踊るという意味でしょう。モードには少なくとも DIGINIFIEDLY (dignifiedly のミススペル？威厳のある、高貴な)、COURTEOUSLY (礼儀正しく)、TENACIOUSLY (粘り強く)という 3 つのモードがあるようです。

なのでこのブロックは「永遠に夜がある限り高貴に踊り、礼儀正しく踊り、粘り強く踊ることを繰り返す」という意味になります。 $forever->night() が具体的には何なのかによりますが、別の言い方をすると Worker 達は夜が来る限り踊り続けることを止められないということになります。これより後ろにプログラムが続いていることから $forever->night() には終わりが来るということが推測できます。

assertSame(TONIGHT, $forever->night()); // この夜もそうでなければならない。

assertSame(A, B) は A と B が等しいことを確認するためのものです。もし A と B が異なればエラーを報告します。つまりこのプログラムは TONIGHT と $forever->night() が等しいことを確認しています。

/** 2022.04.16 */
memory_limit = -1;

ようやく最後のパートです。 /** 2022.04.16 */ はコメントでありプログラム的な意味はないのですが、memory_limit = -1 というプログラムを書き足した日付、もしくはこのプログラム全体を書いた日付ではないかと思います。プログラミングの世界では、プログラムを書いたときにその時の日付をコメントとして残す文化が存在します。

memory_limit = -1 はプログラムに割り当てるメモリの上限を外す、つまり無制限にメモリを使えるようにするという意味です。

パソコンやスマホのメモリがいっぱいになって動作が重くなったという経験を持つ人もいると思います。あるプログラムがメモリを使いすぎるとコンピュータ全体が重くなったり、他のプログラムが動作しなくなったりします。それを防ぐためにプログラムが使えるメモリの最大値を設定できるようになっているのですが、このプログラムではその制限外しています。

気になるポイント

John Titer の記事に対する返信を再度引用します。

時代は末期。そこは「灰版電機工業㈱」が権威を奮う世界。抑圧され感情が乏しくなった工場職員が労働を続けている。――。ふと電撃が走る。それに呼応して現れた見た事のない機械を構える職員、時空の歪み、別世界線との交差。工場のレーンにはこの世界にないものが流れ、やがて混ぜられた。そこには感情(bug)を持つ”人間”という種が生成された。

memory_limit = -1

感情(bug)の連鎖が始まる。工場職員たちも自分のメモリを開放し、世界に抗う。

――。

Worker は灰版電機工業の感情が乏しくなった工場職員のことか？
People は感情(bug)を持つ“人間”のことか？
$forever->night() に終わりは来るのか？来るとしたら終わりとは何か？
感情を持ち“人間”になった結果、2022 年 4 月 16 日に memory_limit = -1 を設定して世界(灰版電機工業？)に抗ったのか？

[day2 “ob_start”] のプログラム

私が参戦したのは 2 日目だったんですが、ディスプレイは遠くて見えなかったのでこれも直接確認したわけではありません。 day1 と同じく ZTMY LEAKS にプログラムが投稿されています。

ZTMY LEAKS から引用したプログラム全文はこちらです。

$we = Worker::getWorking(); // 私達は存在している。
define(People::lifetime()->every_second, INFINIT_VALUE); // 1秒1秒には無限の価値がある。

if ($we->think(People::lifetime()->length > $we->lifetime()->expected)) { // 私達の生きる時間が短いのではなく、
while (!$we->die()) { $we->setRole(Role::MACHINES);} // 私達がその多くを無駄にしているのだ。
}

$forever = (new Forever([ // 永遠は、いくつもの現在から成り立っている。
“params” => array_map(function ($someone) {
return $someone->lifetime()->now;
}, $we)
]))->compose();

while ($forever->night()) { // どんな夜も、私達は踊り続ける。
$we->dance(Mode::DIGINIFIEDLY); // 尊厳を持ち、
$we->dance(Mode::COURTEOUSLY); // 礼節を重んじ、
$we->dance(Mode::TENACIOUSLY); // 粘り強く。
}

assertSame(TONIGHT, $forever->night()); // この夜もそうでなければならない。

/** 2022.04.16 */
memory_limit = -1;

--- 2022-04-16T19:00:00+0900
+++ 2122-04-17T19:00:00+0900

$we2 = Worker::getWorking(); // 私達は生きている。
assertFalse($we->place == $we2->place); // たとえ生きる居場所が違くたって
assertFalse($we->period == $we2->period); // たとえ生きる時代が違くたって
assertSame($we->enthusiasm, $we2->enthusiasm); // 私達の熱を決して奪うことは出来ない
/* 2122.04.17 */
ob_start();

day1 のプログラムに 8 行が追加されています。

また、この記事には John Titer が次のように返信しています。

――。

100年が経過し、世界は様相を変えた。いつしか権威は崩落する。朽ち果て緑覆われた工場、そこにはかつての活気はない。しかし、限界を突破し感情(BUG)を得た職員達は過去の遺物を手に持ち演奏を続けていた。世界が変わったとしても。体、形が変わったとしても。誰にもその熱を奪うことはできなかった。

“ob_start”

――。ふと電撃が走り、工場は再び稼働を始める。新たな歪みが生まれ、それは何処かへ向かった。

プログラムの解説

day2 は追加された部分のみ調べます。

表示について

まず、ZTMY LEAKS では追加された部分は次のように表示されています。

しかし、元のテキストは次のようなものだったのではないかと予想しています。

--- 2022-04-16T19:00:00+0900
+++ 2122-04-17T19:00:00+0900

+ $we2 = Worker::getWorking(); // 私達は生きている。
+ assertFalse($we->place == $we2->place); // たとえ生きる居場所が違くたって
+ assertFalse($we->period == $we2->period); // たとえ生きる時代が違くたって
+ assertSame($we->enthusiasm, $we2->enthusiasm); // 私達の熱を決して奪うことは出来ない
+ /* 2122.04.17 */
+ ob_start();

これは diff というもので、プログラムの修正前後の差分を表現する方法です。もしかしたらライブ会場のディスプレイにはこれに近い形で表示されていたのかもしれません。

なぜ ZTMY LEAKS ではこのような形で表示されてしまったのかは定かではありませんが、ZTMY LEAKS で使われている WordPress というブログツールのエディタが勝手に変換してしまったのではないかと考えています。

day2 のプログラムが diff 形式で表現されていたとすると、これは「2022 年 4 月 16 日のプログラムに対して、2122 年 4 月 17 日に 6 行が追加された」ということを意味します。以下はその仮定の元で内容を見ていきます。

内容

day1 のプログラムと同様にひとつずつ見ていきます。

--- 2022-04-16T19:00:00+0900
+++ 2122-04-17T19:00:00+0900

diff では --- の後ろには変更前のプログラムが作成された日付、+++ の後ろには変更した日付が書かれます。つまり、2022 年 4 月 16 日に作成されたプログラムに対して 2122 年 4 月 17 日に変更を加えた、ということになります。 2022 年 4 月 16 日は memory_limit = -1 を書き加えた日、2122 年 4 月 17 日はその 100 年と 1 日後ですね。

$we2 = Worker::getWorking(); // 私達は生きている。

day1 のプログラムにもありました。これを書き加えたのが 100 年後なので、$we2 には 100 年後に生きている Worker 全員が格納されるイメージでしょうか。

assertFalse($we->place == $we2->place); // たとえ生きる居場所が違くたって
assertFalse($we->period == $we2->period); // たとえ生きる時代が違くたって

assertFalse(A == B) は A と B が等しくないことを確認します。なので、ここでは次の 2 つの事実を確認しています。

$we と $we2 の place (場所) が違うこと
$we と $we2 の priod (時代) が違うこと

assertSame($we->enthusiasm, $we2->enthusiasm); // 私達の熱を決して奪うことは出来ない

assertSame は一度でてきましたね。ここでは $we と $we2 の enthusiasm (熱意) が等しいことを確認しています。

/* 2122.04.17 */
ob_start();

/* 2122.04.17 */ は memory_limit = -1 のときと同じように追加した日付をコメントしたものと考えられます。

ob_start() は本来の PHP では少し複雑な意味を持つのですが、簡単に説明すると「今からアウトプットを初めますよ」という宣言になります。

気になるポイント

再度 John Titer の返信を引用します。

――。

100年が経過し、世界は様相を変えた。いつしか権威は崩落する。朽ち果て緑覆われた工場、そこにはかつての活気はない。しかし、限界を突破し感情(BUG)を得た職員達は過去の遺物を手に持ち演奏を続けていた。世界が変わったとしても。体、形が変わったとしても。誰にもその熱を奪うことはできなかった。

“ob_start”

――。ふと電撃が走り、工場は再び稼働を始める。新たな歪みが生まれ、それは何処かへ向かった。

時系列を整理するとこんな感じ？
- 灰版電機工業が権威を奮う世界
- 感情(bug)を持つ“人間”が現れ、2022 年 4 月 16 日に memory_limit = -1 して世界に抗う
- なんだかんだで灰版電機工業の権威が崩落して向上は朽ち果てる
- 2122 年 4 月 17 日に工場が再稼働して ob_start() する
袖のキルトの MV が 2122 年 4 月 17 日だろうか？
ob_start() にはこれからアウトプットを始めるよ、活動を始めるよ、という意味が込められている？

おわりに

以上です。

本記事ではプログラムをプログラムとして理解するということを試みましたが、厳密にプログラムとして解釈するのではなくこのプログラムはどういう意図があって書かれたのか、ということを考えることが重要だと感じました。

実はプログラミングという作業はプログラムを書く時間より読む時間の方が多いです。そして、読むときには表面上の意味だけでなく、どういう背景があり、書いた人がどういう意図で、どういう気持ちで書いたのか、という情報を収集・推測しながら読むことが非常に重要になります。今回はその対象がずとまよの世界観であり、非常に楽しくプログラムを読むことができました。

もしこの記事を最後まで読んでくれた方で(いるのか？)、この MV を見ればこういうことも考えられるかも、とかこういう解釈があるかも、という情報があればぜひ教えてください。

あと最後にもう一度、ライブ最高でした！！！！！ありがとう！！！

テクノプアのチケットも当たってくれ〜〜〜〜 🙏 🙏 🙏 というわけで ZUTOMAYO PREMIUM に入会しました。

PHP の場合は JavaScript と違って直接プログラムを確認することはできません。しかし、URL や HTTP のレスポンスを手がかりにして PHP が使われていることが推測できます。 ↩

おうち k3s - クラスタ構築編

Wed, 06 Apr 2022 12:06:40 GMT

概要

以前作った Kubernetes 用のラズパイクラスタが埃をかぶっていたので k3s クラスタとして蘇らせた。ラズパイの初期設定も楽にできたし、k3s のインストールも感動するぐらい楽だった。

この記事ではラズパイのセットアップから k3s のインストールまでの手順を紹介する。

やったこと

ラズパイに OS インストール
ラズパイの初期設定
k3s のインストール

前提知識とか

ラズパイについて

最新 (と言っても出たのは 2 年以上前) の Raspberry Pi 4 Model B を 4 台使っている。詳細は前回の記事を参照してほしい。ラズパイ 4 はクアッドコアで最大 8GB のメモリが積めるのでそれなりに遊べるスペックを持っていて、4 台使えば 16 コア、32GB メモリのクラスタになるので Kubernetes クラスタとして個人で遊ぶには十分なものになる。

今回は以前組んだものがあったので 4 台のラズパイでクラスタを組んだが、k3s は軽いので 1 台でも動作するし十分遊べる。¹とりあえず試してみたいって人は 1 台で試してみてほしい。

K3s

K3s は Rancher が立ち上げた軽量 Kubernetes ディストリビューションで、今は CNCF のサンドボックスプロジェクトになっている。以下の特徴を謳っている。

High availability (を達成するためのオプションがある)
認定 Kubernetes ディストリビューション
IoT やエッジコンピューティングのための軽量 Kubernetes
50MB に満たないシングルバイナリ
ARM に最適化されている

K3s はバイナリサイズを削るために本家 Kubernetes からレガシーな機能やアルファ・ベータ機能、k3s が想定しているユースケースに不要な機能を削除している。とはいえ、Ingress Controller がデフォルトでついてきたり、インストールがシングルバイナリでめっちゃ楽だったりで、普通に Kubernetes として使う分には本家 Kubernetes より手軽に使うことができる。

構成

今回はこんな感じの構成で k3s クラスタを組んだ。

構築したとき、 k3s では control plane や worker node ではなく、server、agent と呼ぶということを知らなかったのでホスト名が間違っているが特に問題はないのでこのままにしている。

この図では有線 LAN も存在しているが、有線 LAN を設定する必要はなく WiFi 接続があれば構築できる。元々組んだときに Wifi 環境がなくてもクラスタが動作するように物理ケーブルで接続していたためこのようになっている。

Raspberry Pi OS インストール

ここからは実際の手順。まずはラズパイに OS をクリーンインストールする。

ラズパイの OS インストールは SD カードに OS イメージを書き込むという作業になる。今回はイメージ書き込みに Raspberry Pi Imager という公式ツールを使った。これが非常に楽で、umount コマンドや dd が不要かつ SSH までの初期設定を書き込み時にやってくれるため、GUI でポチポチとイメージを書き込んでラズパイに SD カードを挿せば SSH で接続できるようになる。

次のような設定で 4 枚の SD カードに OS イメージを書き込んだ。

Operating System
- Raspberry Pi OS Lite (64-bit)
Storage
- 各 SD カード
Advanced options
- Set hostname
  - controlplane.k3s, worker-1.k3s, …
  - ここだけ SD カードごとに変更
- Enable SSH
  - Use password authentication
  - SSH 公開鍵を複数登録したかったができないっぽかったので一旦パスワードで
- Set username and password
  - 初期ユーザーは pi になっているので、nownabe に変更
- Configure wireless LAN
  - 自宅の WiFi を設定

SD カードにイメージを書き込んだら、それを各ラズパイに挿して起動。

Raspberry Pi OS の初期設定

すでに SSH でログインできるようになっているので、ラズパイの IP アドレスを調べて設定したユーザー名とパスワードでログインする。IP アドレスは WiFi のルーターを見ればわかるはず。

まず、k3s の起動に必要な iptables のインストールと cgroup の有効化を行う。²

sudo apt upgrade

# iptables をインストール
sudo apt remove nftables
sudo apt install iptables

# /boot/cmdline.txt に `cgroup_memory=1 cgroup_enable=memory` を追加する
sudo nano /boot/cmdline.txt

/boot/cmdline.txt はこんな感じになる。

nownabe@controlplane:~ $ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=xxx rootfstype=ext4 fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory

k3s の起動に必要な設定はこれだけなので次の設定は飛ばしてもらっても構わない。これらの必須設定以外では前述の通り有線 LAN と SSH を次のように設定した。

sudo apt upgrade
sudo apt install vim

# 静的IPアドレスの設定

cat <<EOF >> /etc/dhcpcd.conf
interface eth0
static ip_address=192.168.3.1/24
EOF

# SSH鍵の設定: 公開鍵をGitHubからダウンロード

mkdir .ssh
curl -o .ssh/authorized_keys https://github.com/nownabe.keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

# sshdの設定: パスワードログインとrootログインを無効化

cat <<EOF | sudo tee -a /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
EOF

# /etc/hostsの設定: ラズパイ間で通信しやすいように

cat <<EOF | sudo tee -a /etc/hosts
192.168.3.1 controlplane controlplane.k3s
192.168.3.2 worker-1 worker-1.k3s
192.168.3.3 worker-2 worker-2.k3s
192.168.3.4 worker-3 worker-3.k3s
EOF

k3s インストール

いわゆるコントロールプレーン的な k3s server とワーカーノード的な k3s agent でインストール手順が微妙に異なるので、k3s server から順にインストールする。

1 台で試す場合は k3s server だけインストールすれば OK。

K3s server インストール

controlplane.k3s に k3s server をインストールする。

curl -sfL <https://get.k3s.io> | sh -

以上。めっちゃ簡単。controlplane.k3s に kubectl もインストールされているので、すぐに試すことができる。

sudo kubectl get nodes
sudo kubectl get services
sudo kubectl get pods

また、kubeconfig が /etc/rancher/k3s/k3s.yaml にあるので、これをローカルに持ってきてリモートで kubectl することもできる。

# ローカル (not ラズパイ) で

# kubeconfig とってくる
ssh ${controlplan.k3sのIP} sudo cat /etc/rancher/k3s/k3s.yaml > k3s-kubeconfig

# serverのアドレスを書き換える (clusters.0.cluster.server)
vi k3s-kubeconfig

# kubectlする
kubectl --kubeconfig=k3s-kubeconfig get nodes

K3s agent インストール

残り 3 台は同じ操作。

まず、controlplane.k3s から agent を追加するためのトークンを取得する。

# in controlplane.k3s
sudo cat /var/lib/rancher/k3s/server/node-token

取得したトークンを使って、残りのラズパイに agent をインストールする。と言っても、環境変数で k3s server とトークンを指定する以外は k3s server のインストールと同じコマンドを使う。

# in worker-*.k3s
curl -sfL https://get.k3s.io | \
  K3S_URL=https://${k3s server のIPアドレス}:6443 \
  K3S_TOKEN=${token} \
  sh -

これで k3s agent のインストールとクラスタへの参加が完了する。kubectl get nodes 等で確認するとノードが増えていることがわかる。

おわりに

本当に 1 回もエラーに遭遇することなく、前回苦労したのはなんだったのかというぐらい簡単に Kubernetes がセットアップできてしまった。

本記事の手順だけでも Pod を作って Service で公開ということはできる。それだけだと LAN 内に閉じた話になるので、インターネットへサービスを公開したいとか外出先から kubectl したい、というニーズにはまだ応えられない。

モチベが湧けば、次回は Cloudflare を使ってクラスターをセキュアにインターネットへ公開する記事を書きたいと思う。

GitHub のリポジトリを一括で整理するツールを作った

Sun, 13 Mar 2022 14:27:09 GMT

GitHub のリポジトリを一括で整理するための ghrepos-organizer というツールを作りました。元々は整理が目的でしたが、全リポジトリに対して自動ブランチ削除機能を有効化するみたいな使い方もできるようになりました。

できること

ある Owner (user or organization) のリポジトリのうち、選択したリポジトリに対して一括で以下の操作を適用できます。

削除
すべての Issue を Close
すべての Pull Request を Close
属性の変更
- Visibility (Public/Private)
- Wiki 機能の On/Off
- Project 機能の On/Off
- マージした時に自動でブランチを削除する機能の On/Off
- アーカイブ
他の Organization への Transfer

使い方

ghrepos-organizer を使うためには GitHub の Personal Access Token が必要に成ります。repo スコープがついていれば OK です。リポジトリの削除を実行するためには delete_repo スコープも必要です。

npx コマンドで実行できます。

npx ghrepos-organizer

コマンドを実行すると対話式に色々聞かれるので、適用する操作を選んだり、操作対象のリポジトリを選んだりします。

操作 (Action) を選ぶ様子:

リポジトリを選ぶ様子:

最後に最終確認のプロンプトが出るので、Yes (y) を入力すると実行されます。

環境変数

環境変数で一部の挙動を設定できるようになっています。

GH_PAT - Personal Access Token を環境変数で設定できます。
CONCURRENCY - 操作の並列数を設定できます。デフォルトは 5 です。
ENABLE_DELETE - 削除機能を有効化します。

おわりに

昔のリポジトリをまるっとアーカイブしたい時や、ブランチ自動削除機能を一括で有効化したいときなんかにぜひ使ってみてください。

今回初めて Node で CLI を作ってみたので、そのことについての記事もまた書きたいと思います。

5年前に書いた React/Redux アプリから Redux を処した

Sat, 26 Feb 2022 08:17:16 GMT

もっと気軽にブログを書いていこう記事第一弾。第二弾もあってほしい。

やったこと

5 年前に作った React と Redux で書いたウェブアプリを Next.js と Hooks と Recoil で動くようにほぼ全て書き換えた。 Brainfuck Board という Brainfuck を実行できるウェブアプリで、Dependabot がうるさかったり、完成度が中途半端だったりでずっとなんとかしたいとは思っててようやく手を付けることができた。

nownabe/brainfuck-board: Brainfuck Platform

やったことを時系列に羅列するとこんな感じ。

ソースコード見て当時の振り返り
最新のナウい状態管理の調査。Recoil がいいらしい
Redux から Hooks/Recoil にどうやって移行するか検討
ちまちま変えていくのはだるそうだったので、スクラッチで書き換え
プルリクをマージ
Vercel にデプロイ
細かいところ整えたり、バグ修正したり、新機能つけたり
Renovate で automerge な設定

感想

時代の進化を感じることができてとても良かった。 Web フロント界隈は流れが早いだの落ち着かないだの言われてたけど、5 年前の実装を思い出しながら書いてると正当に進化してるなーと改めて思った。

Redux をやめて Hooks ベースになっただけでめっちゃスッキリしてさすがのこんまりもびっくりすると思う
単純にファイル数・コードが減るし、レイヤードなアーキテクチャのまとまりがよくなる気がする
Redux 関係だけじゃなくて、自分の窓から投げ捨てたくなるようなコードも捨てられて最高
Suspense 使いたかったけど使いどころがなくて残念
Firebase まわりの実装はまだ納得いってない
内面だけじゃなくてアプリ自体も良くなってよかった
今回はスクラッチで書き直したけど、地道な移行もできなくはなさそう (技術的には可能)

おわりに

メンテは計画的に。

勉強を続ける技術

Sat, 25 Sep 2021 07:41:22 GMT

はじめに

継続も勉強も苦手な自分が英語の勉強を毎日 1 年以上続けられているので、そのためにやったことを紹介します。

今まで何度も何度も三日坊主を経験してきましたが、意外と小手先のテクニックを駆使して続けることができています。同じように何かを続けようとして失敗している人の参考になれば幸いです。

もちろんこんなことをしなくても継続できる人はいると思います。僕のような意志が弱く継続が苦手でだらしない人間が、なんとか継続するためにやった工夫として読んでください。

また、この記事では続けるということに焦点を当てます。特に、毎日何かをやり続けるということが話の中心になります。英語の上達や目標の達成や何かをやり抜くということはスコープ外になります。

きっかけと結果

まず英語を勉強しようと思ったきっかけは、Google に入社して今以上にパフォーマンスを発揮するためには英語が必要と感じたことです。それまで何度も英語を勉強しようと思ったことはあるものの続いたことはありませんでした。そのため、今までどおりではいかん、ということでとにかく「続ける」ということを意識して勉強してみました。

結果として以下のようなものが得られました。

567日連続での英語勉強
毎日英語の勉強をするのが苦ではなくなって当たり前になった
1 日の平均勉強時間は 47 分
ほんのちょっと英語が上達した気がする
これからどういうプロセスを踏めば英語が上達しそうかちょっと見えてきた

自分にとって言語としての英語¹は非常に苦手分野で、苦手意識も大きいし、何をどうすれば英語で読み書き聞く話すができるようになるのかさっぱりわかりませんでした。まだまだ人並みにもなってないし、ここまで来るのに 1 年以上かかったのには才能ないなぁと感じますが、「どうすれば上達できるか」がぼんやりとでも見えてきたのは非常に大きい進歩だと思います。継続は力なり、ですね。(まだ力にはなってない)

続ける技術

ここからは続けるために僕が実践してきた技術を紹介します。

目標設定

まず目標設定です。何かを続けるためには「続ける」ことを目標にするといいです。

自分の英語勉強の目標は「毎日 1 分以上英語を勉強する」でした。

なぜこうしたかというと、次のような目標は上手く機能しないことが経験上わかっていたからです。

TOEIC xxx 点を取る
この本を一ヶ月で終わらせる
毎日 xx ページ勉強する
毎日 1 時間勉強する

なぜこういった目標がうまく機能しなかったかを考えた時、目標のハードルが高すぎたのではないかという結論に至りました。ハードルが高いと飛び越えるために膨大な意志と集中力が必要です。そして、ハードルが高いため失敗しやすく、1 回でも失敗するとモチベーションが急低下して三日坊主に終わります。

なので目標は最低まで低くして、まずは続けるということに集中することにしました。 継続しないことにはTOEICの点も上がらないし一冊の本も読めないからです。

今でもこの目標設定は変えてませんが、新たな目標を追加したり、勉強量を増やしたりということはできています。新しい目標は達成できなくても、この「毎日一分やれば OK」というベースの目標がガードレール的に達成されるので気が楽です。

可視化

続けるという目標を設定した後すぐに可視化の仕組みを整えました。目標が達成できているか確認できるし、達成感を得られるし、なにより綺麗に可視化されているとモチベーションに繋がります。

個人的に毎日の活動を可視化する最強ソリューションは GitHub の草²だったので、英語の勉強でも草を生やしたいと考えました。

実現には GitHub と同じような芝生を育てられる Pixela というサービスを使っています。 Pixela がなかったらここまで勉強を続けられていなかったと思います。こんな感じの GitHub そっくりの芝生が作れます。

Pixela だけでは勉強時間の入力が難しいので、勉強時間の記録には Toggl Track を使っています。 Toggl はモバイルアプリもあるので手軽に勉強時間のトラッキングができます。

また、Toggl と Pixela でデータを連携するために Google Cloud の Cloud Functions と Cloud Scheduler を使っています。Toggl も Pixela も API があるので簡単に連携できます。 README すら書いてませんがソースコードはこちらです。需要があれば整えます。

図にするとこんな感じです。ありがたいことにすべて無料で使わせてもらっています。

始めてから一年以上経ちますが、いまだにしょっちゅう草を確認してモチベーションを維持しています。芝生に穴を開けたくないがために毎日勉強しています。

監視される

「人に見られているとサボりにくいだろう」ということで勉強時間を Twitter に投稿するようにしました。

On 2020-09-09, I studied English for 26 minutes.https://t.co/7N4uLAE4rO pic.twitter.com/HAGzsjLGtl
— ぎっくり腰太郎 (@nownabe) September 9, 2020

実際はこんなツイートをチェックする奇特な人はいないと思いますが、人に見られていると意識するだけでも多少の効果があります。ツイッター以外でも、一緒に勉強してくれる人を探して進捗を確認し合う、進捗を管理してくれる教室に入会する、というのも効果的だと思います。

手動で勉強時間をツイートするのは面倒なので、上述の Cloud Function で Pixela へのデータ投入と同時にツイートするようにしました。

今はもう習慣化できているので、TL を荒らしがちなこの機能は停止しています。

お手軽ネタの用意

「毎日 1 分勉強する」をお手軽に達成するためのネタを複数用意しました。これは、モチベーションがなくても時間がなくても「続ける」ための工夫です。

例えば、次のようなネタを準備していました。

単語帳を必ず目に入る場所に置いておく
英語学習の Podcast を登録しておく
英語学習アプリをインストールしておく
LINE の英単語クイズ bot を登録しておく

こういう手軽なネタを用意しておくことで手軽に「毎日 1 分勉強」が達成できます。最低限の 1 分を達成するだけでも「失敗によるモチベーションの低下」という状況を防ぐことができるので重要になってきます。

ここで重要なことは、時・場所を選ばず、ハードルが最も低い方法を用意しておくことです。上述の例だと、それぞれこのようなハードルを設定しておきます。

単語帳は 1 単語でも読めば OK
Podcast はどこから初めてどこで終わっても OK
英語学習アプリは 1 エピソードの一部でもやれば OK
英単語学習ボットは 1 単語でもクイズすれば OK

例えば次のようなネタしかないと、ハードルが高くて毎日勉強を達成できない可能性が出てきます。

Netflix で海外ドラマを見る (まとまった時間が必要)
シャドーイングする (まとまった時間と音を聞けて声を出せる場所が必要)
文法書を読む (ある程度まとまったかたまりで読まないと気持ち悪い)

上述の例でも単語帳、Podcast、アプリはほぼ問題ないのですが、状況によって時・場所を選ぶため単語クイズができる LINE bot を作りました。

こちらの LINE bot は Google Apps Script で実装しています。テンプレートをコピーして、エンドポイントを LINE Developers で登録すれば使えると思います。

習慣に相乗りする

上述のお手軽ネタはあくまでも「続ける」ことを最低限続けるためのバックアップです。お手軽ネタだけをこなしていても勉強としての効果は小さいです。

そこで、次はいかにして毎日の勉強時間を確保するかが重要になってきます。

時間を確保する最も簡単な方法は、既存の習慣に相乗りすることです。

通勤時間、歯磨き、お風呂、食事、などなんでもやりやすい習慣でいいと思います。

僕の場合は毎朝の犬の散歩に相乗りすることにしました。毎朝散歩をしながらシャドーイングしたり、英語学習 Podcast を聞いたりしていました。そうすることでほぼ毎日 30 分は勉強時間を確保できました。

今はさらに増やして、次のような習慣で毎日勉強しています。

毎朝の散歩でシャドーイングやリスニング
朝・昼・晩、歯磨きしながら単語学習
寝る前に文法学習
20 時〜21 時は勉強時間

残業したり台風が来たり外出したりすると習慣が崩れてしまうこともあるので、そういうときはお手軽ネタでお茶を濁します。

適切な教材を選ぶ

難しすぎず、簡単すぎず、成長を実感できる教材を選ぶことも重要です。

成長の実感はモチベーション維持・向上に大きな効果があります。モチベーションがあれば継続にも繋がり、さらに継続の先の目標達成にも繋がります。

教材が難しすぎると成長を実感するまでにモチベーションが下がってしまいます。逆に簡単すぎると成長幅が小さくて実感できません。

適切な教材を選ぶには自分の今のレベルを知る必要があります。客観的なテストがあるならそれを参考にしてもいいし、詳しい人にアドバイスをもらうのもありです。自分で教材を見て選ぶ場合は、わかる部分もあるしわからない部分もある、ぐらいがいいと思います。

僕の場合は最初は高校生レベルの単語帳をメインの教材としていました。

残業しない

重要です。残業すると時間とエネルギーを浪費してしまって勉強できません。

勉強してなくても当然ですが、極力効率良く仕事をこなしてだらだら仕事をしないようにする必要があります。

僕の場合はそれ以外に、残業時間帯に不必要なミーティングの招待がよく飛んできていたので、重要性の低いものは自動で辞退するような設定をしたりしました。残業減らせねーよという方も諦めずに、残業を減らす仕組みを考えたり、誰かに相談したり、転職したりしてください。

いろいろ手は尽くしても残業が発生することはあると思いますが、そういうときはお手軽ネタでお茶を濁します。

時間の浪費からの脱出

おまけです。今までの方法からさらに勉強時間を増やすときのヒントになるかもしれません。

特に疲れているときとか、永遠に YouTube を見続けたり、無限にソシャゲポチポチしてしまったりして時間を浪費してしまうことがあると思います。そういう時間から脱出するためのスイッチ、トリガーを探しておくと勉強時間を増やすことができます。

僕の場合は色々試してみた結果、なぜかわかりませんが、「前頭前野頑張れ！前頭前野負けるな！」と前頭前野を応援するとだらだらから脱出できることがわかりました。なので最近は勉強したいときには積極的に前頭前野を応援するようにしています。

ちなみに前頭前野は脳みその部位の名前で、人間の理性的な活動や、行動を切り替える機能を持っているそうです。また、瞑想すると鍛えられるらしいです。

前頭前野はヒトをヒトたらしめ，思考や創造性を担う脳の最高中枢であると考えられている。この脳部位はワーキングメモリー、反応抑制、行動の切り替え、プラニング、推論などの認知・実行機能を担っている。また、高次な情動・動機づけ機能とそれに基づく意思決定過程も担っている。さらに社会的行動、葛藤の解決や報酬に基づく選択など、多様な機能に関係している。前頭前野 - 脳科学辞典

おわりに

最近は勉強を続けられるようになったので、新しく「アメリカで仕事できる英語力を身につける」という目標を持って勉強しています。こういう目標を持てるようになったり、そのために何をすればいいか見当がついたりしたのも、ここまで続けてきたからこそだと思います。

継続することで初めて見える世界があるということがわかっただけでも続けてみた価値はありました。何か目標がある人、逆に何かに行き詰まってる人、とりあえず何かを続けてみてはいかがでしょうか。

テストとしての英語はクイズとしてある程度対策すればそこそこ点が取れるのでたちが悪い ↩
参考: 冴えない草(コントリビューション)の育てかた - Speaker Deck ↩

我が家の BigQuery による台所事情分析

Sat, 12 Dec 2020 15:00:00 GMT

弊家では銀行やクレジットカードの明細を BigQuery に取り込んでダッシュボードを作ったりしています。また、そのために作った BigQuery 向けの Go 製 ETL フレームワークを OSS として公開しました。本記事ではざっくりどんなもんかを紹介して、どう作るのかを説明します。

Google Cloud Platform Advent Calendar 2020 の 13 日目の記事です。

Google Cloud Japan の Customer Engineer の Advent Calendar もぜひご覧ください。

TL; DR

明細が BigQuery にあると、可視化もできるしアラートも出せるし、まぁなんでもできて便利
銀行明細レベルのデータならほぼ無料で保存、ETL、分析できる
ETL フレームワーク bqloader を OSS として公開したから使ってくれよな 💪

説明しないこと:

我が家の台所事情
BigQuery のクエリの書き方

対象読者

GCP を触ったことがある人
お金まわりを分析したいと思っている人
身近な題材で BigQuery を触ってみたい人

ざっくり紹介

何が嬉しいの？

BigQuery でできることができるようになります。で終わらせるのもアレなので、弊家でのユースケースを列挙します。

ダッシュボード
- 資産推移
- 出費分析
- でかい出費ランキング
アラート (銀行残高、クレジットカード)
予算管理

例えばダッシュボードはこんな感じです。(記事用に加工してます)

BigQuery を使うことで、手動でやってたことを自動化できるようになったり、今までできなかったことができるようになったりしました。 SQL を書けばほしいデータをほしい形ですぐに手に入れることができて、それを簡単に様々なシステムと連携できるので超便利です。おかげで自動化もできたし、良い感じのダッシュボードも作ることができて節約を頑張れそうです。

Money Forward でええんちゃうの？

いいです 😂

本記事の内容は劣化版 Money Forward の再実装と言える部分もあります。

Money Forward はとてもいいサービスなので弊家でも使っていますが、かゆいところに手が届かなかったり、使いたい機能が有料だったりしたので自分でも作りました。

自分で作ると手間はかかりますが Money Forward 以上のやりたいことがだいたい実現できるようになります。 BigQuery でクエリを書いて好きな結果を得られるというのは大きいですね。

アーキテクチャ

こんな感じです。

課題

大きな課題が 2 点あります。

CSV のダウンロード/アップロードが手動
- 銀行やクレジットカードの明細の CSV を手動でダウンロードしてアップロードしています¹
リアルタイム性がない
- CSV を月イチで手動アップロードしてるので、リアルタイム性がありません

以前はスプレッドシートに手入力していた部分もあったので自分としては手間は減ってるし、できることは増えたし、お金はかかっていないしでハッピーなんですがめんどくささは残ります。銀行が API 公開してくれたらいいんですけどね。

無料なの？

無料ではないです。毎月 1 円請求が発生しています。 Cloud Functions のコンテナイメージを管理している Container Registry のバックエンドの Cloud Storage に料金がかかっています。²

下の画像は実際に弊家で使っているプロジェクトの Billing Report です。 (Subtotal は 4 ヶ月分が加算されて 4 円と表示されています)

Cloud Storage や Cloud Functions や BigQuery は無料枠におさまっています。もし既に無料枠を使い切っている場合は料金が発生します。それぞれ以下のように無料枠があります。

Cloud Storage: 5GB-月 (us-east1, us-west1, us-central1)
Cloud Functions: 200 万回/月
BigQuery: 1TB クエリ/月

Cloud Storage の無料枠はリージョンが限定されています。リージョンが異なると余計なネットワーク料金が発生したりするのでリージョンを揃えておくのもポイントです。弊家ではすべてを使えるリージョンとして us-east1 を選択しました。

銀行の明細は 1 ヶ月分でせいぜい数 KB、クエリもたかがしれてるのでなかなか無料枠を超えることはなさそうです。

ETL フレームワーク bqloader

bqloader 概要

bqloader は Go 製のシンプルな ETL フレームワークです。弊家の ETL をフレームワークとして切り出したものになります。以下のような特徴があります。

1 行を 1 行への変換に特化
ユーザは行単位の変換ロジックのみ実装
簡単な設定で文字コード変換、不要な行のスキップ、成功・失敗通知が可能
今のところ Cloud Storage、Cloud Functions、BigQuery 専用³
1 つの Function で複数種のデータに対応

Go で実装することになるので Go の知識はあった方がいいですが、なくても Hello, world ぐらいできればサンプル見ながら実装できるんじゃないでしょうか。

以下のような利点があります。

ほぼ無料で使える
必要最低限の機能しかない
Go で書ける
複数種のデータの ETL を一箇所で管理できる

bqloader 使い方

サンプルプロジェクトを見てもらうのがはやいです。このサンプルの中で Service Account の作成や Function のデプロイ、BigQuery への ETL まで一通りカバーしています。

以下ではフレームワークのさわりだけ丁寧に説明していきます。詳しくは godoc やサンプルを見てください。

まず import します。

import "go.nownabe.dev/bqloader"

保存先テーブルごとに bqloader.Handler を設定します。 Cloud Storage にアップロードされたファイルが Handler の Pattern に一致する場合に処理されてテーブルにロードされます。 Handler を複数定義すればひとつの Pattern に複数の Handler を対応させることもできます。

handler := &bqloader.Handler{
  Name:     "main_bank",          // 通知などで使われる
  Encoding: japanese.ShiftJIS,    // 入力ファイルをShiftJISとして扱う
  Parser:   bqloader.CSVParser(), // 入力ファイルをCSVとして扱う

  // 先頭から1行を無視する (ヘッダのスキップ)
  SkipLeadingRows: 1,

  // この正規表現にマッチするパスのファイルを処理する
  Pattern: regexp.MustCompile("^main_bank/"),

  // ロード先のBigQueryテーブル
  Project: "my-project",
  Dataset: "my_dateset",
  Table:   "main_bank",

  // 後述
  Notifier:  notifier,
  Projector: projector,
}

変換のコアは projector です。projector は行単位の変換を実現する関数です。

/*
  例えば次のようなCSVの各行をBigQueryが理解できる形式に変換する。

  日付,内容,出金金額,入金金額,残高
  2020年12月13日,お賃金,0,"180,000","200,000"
  
  rowに1行が入る。上記の例だと次のようになる。
  row == []string{"2020年12月13日", "お賃金", "0", "180,000", "200,000"}
*/
projector := func(_ context.Context, row []string) ([]string, error) {
  // 日本語の日付から、BigQueryが解釈できる日付に変換する
  t, err := time.Parse("2006年01月02日", row[0])
  if err != nil {
    return nil, fmt.Errorf("time parse error: %v", err)
  }
  row[0] = t.Format("2006-01-02")

  // 数値列のカンマを削除する
  row[2] = strings.ReplaceAll(row[2], ",", "")
  row[3] = strings.ReplaceAll(row[3], ",", "")
  row[4] = strings.ReplaceAll(row[4], ",", "")

  return row, nil
}

notifier は通知です。

notifier := &bqloader.SlackNotifier{
  Token:   "xxxx",
  Channel: "#bqloader",
}

この Handler を利用して Cloud Functions のエントリーポイントとなる関数を実装します。³

func MyFunc(ctx context.Context, e bqloader.Event) error {
  loader, _ := bqloader.New()

  // 上述のmain_bank Handler
  loader.MustAddHandler(ctx, handler)

  // 別のHandlerも登録できる
  loader.MustAddHandler(ctx, creditCardHandler)

  // イベントを処理する
  return loader.Handle(ctx, e)
}

Cloud Storage へのファイルアップロードなどのイベントで実行されます。⁴

こんな感じで bqloader による関数を Cloud Functions にデプロイして、対応するバケットにファイルをアップロードすればデータが BigQuery にロードされます。

BigQuery による台所事情分析の始め方

では銀行の明細を BigQuery にロードする ETL システムを構築してダッシュボードを作ってみましょう。

銀行の明細はこのサンプルを利用します。このデータを多くの銀行に倣って ShiftJIS の CSV として扱います。

前提として、Google Cloud のプロジェクトが必要になるので用意してください。以下ではプロジェクト ID が GCP_PROJECT 環境変数にあるものとして説明します。また、Go 環境と Google Cloud SDK はセットアップ済みとします。

作成するリソースはそれぞれ次の名前を使用します。

Service Account: bqloader
BigQuery Dataset: bqloader_dataset
BigQuery Table: main_bank
Cloud Storage Bucket: gs://$GCP_PROJECT-source
Cloud Functions: bqloader-func

今回ダッシュボードには無料で簡単に使える Data Studio を使います。

Service Account 作成

Cloud Functions 用の Service Account を作ります。

gcloud iam service-accounts create bqloader --project $GCP_PROJECT

後で何回か使うので、Service Account の環境変数も設定しておきます。

SERVICE_ACCOUNT=bqloader@$GCP_PROJECT.iam.gserviceaccount.com

BigQuery の Job を実行する権限が必要になるので roles/bigquery.jobUser Role を付与します。

gcloud projects add-iam-policy-binding $GCP_PROJECT \
  --member serviceAccount:$SERVICE_ACCOUNT \
  --role roles/bigquery.jobUser

BigQuery Table 作成

スキーマの JSON を作成します。

cat <<EOF >schema.json
[
  {
    "name": "date",
    "type": "DATE",
    "mode": "REQUIRED"
  },
  {
    "name": "description",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "withdrawal_amount",
    "type": "NUMERIC",
    "mode": "NULLABLE"
  },
  {
    "name": "deposit_amount",
    "type": "NUMERIC",
    "mode": "NULLABLE"
  },
  {
    "name": "balance",
    "type": "NUMERIC",
    "mode": "REQUIRED"
  }
]
EOF

BigQuery の Dataset と Table を作成します。

# Dataset作成
bq --location us-east1 mk --dataset $GCP_PROJECT:bqloader_dataset

# Table作成
bq mk --table $GCP_PROJECT:bqloader_dataset.main_bank schema.json

先程作った Service Account に書き込み権限を付与します。⁵

bq add-iam-policy-binding \
  --member serviceAccount:$SERVICE_ACCOUNT \
  --role roles/bigquery.dataEditor \
  $GCP_PROJECT:bqloader_dataset.main_bank

Cloud Storage Bucket 作成

生データを保存する Bucket を作成します。 Cloud Functions のトリガーとなるイベントを発行するソースにもなります。

gsutil mb -p $GCP_PROJECT -l US-EAST1 gs://$GCP_PROJECT-source

Service Account に読み込み権限を付与します。

gsutil iam ch \
  serviceAccount:${SERVICE_ACCOUNT}:roles/storage.objectViewer \
  gs://$GCP_PROJECT-source

Cloud Functions 実装

まずは Handler を実装します。今回は 1 つですが、Handler が増えたときにメンテしやすいように Handler ごとにファイルをわけておきます。

// main_bank_handler.go

package myfunc

import (
        "context"
        "fmt"
        "os"
        "regexp"
        "strings"
        "time"

        "golang.org/x/text/encoding/japanese"

        "go.nownabe.dev/bqloader"
)

func cleanNumber(n string) string {
        n = strings.ReplaceAll(n, "￥", "")
        n = strings.ReplaceAll(n, ",", "")

        return n
}

func mainBankHandler() *bqloader.Handler {
        projector := func(_ context.Context, r []string) ([]string, error) {
                t, err := time.Parse("2006年01月02日", r[0])
                if err != nil {
                        return nil, fmt.Errorf("time.Parse error: %v", err)
                }

                r[0] = t.Format("2006-01-02")
                r[2] = cleanNumber(r[2])
                r[3] = cleanNumber(r[3])
                r[4] = cleanNumber(r[4])

                return r, nil
        }

        return &bqloader.Handler{
                Name:            "main_bank",
                Pattern:         regexp.MustCompile("^main_bank/"),
                Encoding:        japanese.ShiftJIS,
                Parser:          bqloader.CSVParser(),
                Projector:       projector,
                SkipLeadingRows: 1,

                Project: os.Getenv("GCP_PROJECT"),
                Dataset: "bqloader_dataset",
                Table:   "main_bank",
        }
}

エントリーポイントとなる関数を実装します。

// func.go

package myfunc

import (
        "context"

        "go.nownabe.dev/bqloader"
)

var loader bqloader.BQLoader

func init() {
        loader, _ = bqloader.New()
        loader.MustAddHandler(context.Background(), mainBankHandler())
}

func MyFunc(ctx context.Context, e bqloader.Event) error {
        return loader.Handle(ctx, e)
}

Cloud Functions は Go Modules を理解してくれるので go.mod を作ります。

go mod init
go mod tidy

Function デプロイ

必要な API を有効化します。

gcloud services enable \
  --project $GCP_PROJECT \
  cloudfunctions.googleapis.com \
  cloudbuild.googleapis.com

デプロイします。

gcloud functions deploy bqloader-func \
  --project $GCP_PROJECT \
  --region us-east1 \
  --runtime go113 \
  --trigger-resource $GCP_PROJECT-source \
  --trigger-event google.storage.object.finalize \
  --entry-point MyFunc \
  --service-account $SERVICE_ACCOUNT \
  --set-env-vars "GCP_PROJECT=$GCP_PROJECT"

CSV アップロード

CSV ファイルをアップロードして、Cloud Functions にデプロイした bqloader を起動します。

curl https://blog.nownabe.com/files/2020/12/13/sample.csv \
  | gsutil cp - gs://$GCP_PROJECT-source/main_bank/sample.csv

BigQuery 確認

うまくいけば、ShiftJIS の銀行明細 CSV がいい感じに変換されて BigQuery にロードされています。 bq コマンドで確認します。

bq --project_id $GCP_PROJECT \
  query --nouse_legacy_sql \
  "SELECT * FROM $GCP_PROJECT.bqloader_dataset.main_bank LIMIT 5"

ダッシュボード作成

最後に Data Studio⁶でダッシュボードを作成します。が、Data Studio は操作が GUI で説明がめんどくさいのでフィーリングでやってみてください。画面をポチポチやっていけば、なんとなく BigQuery の銀行明細データを読み込んでグラフが作れそうな雰囲気は感じてもらえると思います。

適当ですがこんな感じのダッシュボードを作れます。

おわりに

やってみると意外と簡単で楽しいのでぜひやってみてください。弊家では今後もどんどんデータを増やして Data Driven な家庭を目指していきます。

あ、nownabe/go-bqloader に Star くれると嬉しいです！⭐

アップロードはコマンド一発 gsutil rsync なので楽なんですが。 ↩
コンテナイメージは Cloud Functions によって古いものは自動で削除されるので、何回デプロイしても 1 円で済むと予想しています。 ↩
Pull Request お待ちしています！ ↩ ↩²
イベントについての詳細は Cloud Functions のドキュメントを参照してください。 ↩
bq add-iam-policy-binding でエラーが出る場合は gcloud components update してみてください。 ↩
大人の事情で日本語だとデータポータルになってます。 ↩

おうちKubernetes構築日記その2 Kubernetes構築編

Sun, 19 Jul 2020 10:26:56 GMT

前回からだいぶ時間があいてしまいましたが、その 2 の Kubernetes 構築編です。前回組み立てたマシンたちに Kubernetes をインストールしました。

あらすじ

前回は Worker ノード用の Raspberry Pi 4 8GB を 4 台組み立てました。今回、それとは別のサーバを 1 台 Control Plane としました。

構築には kubeadm を使いました。

Control Plane 構築

基本的にドキュメントに従って構築していきます。 kubeadm を使って簡単に構築できました。 kubeadm は Kubernetes クラスタを構築するためのツールです。

公式ドキュメント的にはこの辺の内容になります。

今回 Control Plane として使うサーバの OS は Debian Buster です。

ネットワーク設定

Kubernetes から iptables でブリッジのトラフィックを制御できるようにします。

modprobe br_netfilter
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl --system

Dockerインストール

コンテナを実行するために Docker をインストールします。最初は cri-o でやってみたんですが、Kubernetes の最新バージョンに対応していなかったのと、構築でエラーが出たのでさっさと諦めて Docker にしました。

ドキュメントに従ってインストールしていきます。

Container runtimes | Kubernetes

# 普通のDockerインストール

apt remove docker docker-engine docker.io runc
apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"
apt update
apt install docker-ce docker-ce-cli containerd.io

# Dockerデーモンの設定

cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

mkdir -p /etc/systemd/system/docker.service.d
systemctl daemon-reload
systemctl restart docker

/etc/docker/daemon.json の cgroup driver は kubelet と同じにする必要があります。 Docker のデフォルトは cgroupfs ですが、kubeadm で構築すると kubelet は systemd に設定されるので systemd にあわせます。

systemd の Unit ファイルにはいろいろ書いてありますが、kubelet の cgroup driver を変更する場合は /var/lib/kubelet/config.yaml での設定が推奨のようです。

kubeadmインストール

kubeadm、kubelet、kubectl をインストールします。

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
echo 'deb https://apt.kubernetes.io/ kubernetes-xenial main' > /etc/apt/sources.list.d/kubernetes.list
apt update
apt install -y kubeadm kubelet kubectl
apt-mark hold kubelet kubeadm kubectl

Control Plane初期化

kubeadm で Control Plane を初期化します。

kubeadm init \
  --dry-run \
  --control-plane-endpoint=kube-master.cf.nownabe.in \
  --pod-network-cidr=10.4.0.0/14 \
  --service-cidr=10.2.0.0/15 \
  --service-dns-domain "kube.cf.nownabe.in"

これは dry run コマンドなので、大丈夫そうなら --dry-run を消して実行します。うまくいったら次のようなメッセージが表示されます。

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:

  kubeadm join kube-master.cf.nownabe.in:6443 --token XXXX \
    --discovery-token-ca-cert-hash sha256:XXXX \
    --control-plane

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join kube-master.cf.nownabe.in:6443 --token XXXX \
    --discovery-token-ca-cert-hash sha256:XXXX

Control Plane は今回この 1 ノードだけなので、次にやることはこの 3 つですね。

設定コピーして kubectl 使えるようにする
Pod ネットワーク add-on デプロイ
Worker ノード追加

設定を /etc/kubernetes/admin.conf からコピーして、別のマシンから kubectl get po してみました。

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:43:34Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                         READY   STATUS              RESTARTS   AGE
kube-system   coredns-66bff467f8-7sr7t                     0/1     ContainerCreating   0          21h
kube-system   coredns-66bff467f8-sh24v                     0/1     ContainerCreating   0          21h
kube-system   etcd-sv-1.cf.nownabe.in                      1/1     Running             0          21h
kube-system   kube-apiserver-sv-1.cf.nownabe.in            1/1     Running             0          21h
kube-system   kube-controller-manager-sv-1.cf.nownabe.in   1/1     Running             0          21h
kube-system   kube-proxy-t4hgb                             1/1     Running             0          21h
kube-system   kube-scheduler-sv-1.cf.nownabe.in            1/1     Running

おおー、動いてますね！！　🎉 クライアントの kubectl がやたら古いのが気になりますが、ちゃんと apiserver は動いてそうです。

Workerノード構築

Control Plane ができたので、Raspberry Pi を Worker ノードとして構築してクラスタに追加していきます。

Raspberry Pi にインストールした OS は Raspberry Pi OS Buster です。

Swap無効化

Raspberry Pi OS ではデフォルトだと Swap が有効になっているので無効化します。

dphys-swapfile swapoff
systemctl stop dphys-swapfile
systemctl disable dphys-swapfile

いろいろ

Docker インストールしたり kubeadm インストールしたりします。ここは Control Plane とほぼ同じなのでコマンドだけ。

modprobe br_netfilter
modprobe overlay
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
sysctl --system

apt remove docker docker-engine docker.io runc
curl -fsSL get.docker.com | sh
cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF
systemctl restart docker

apt install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt update
apt install -y kubeadm kubelet kubectl
apt-mark hold kubelet kubeadm kubectl

Workerノード初期化

kubeadm で初期化し、クラスタに参加します。 Control Plane を kubeadm で初期化したときに表示されたコマンドを実行するだけです。

kubeadm join kube-master.cf.nownabe.in:6443 --token XXXX \
    --discovery-token-ca-cert-hash sha256:XXXX

もしトークンの期限が切れていてエラーになる場合は、Control Plane でトークンを再発行します。

kubeadm token create --print-join-command

トークンの一覧もコマンドで確認できます。

kubeadm token list

kubeadm token | Kubernetes

無事実行できたら、kubectl で確認してみましょう。ちゃんと追加されてますね！やった！　👏

$ kubectl get nodes --output wide
NAME                          STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION   CONTAINER-RUNTIME
kube-worker-1.cf.nownabe.in   Ready    <none>   31d   v1.18.5   10.0.1.101    <none>        Raspbian GNU/Linux 10 (buster)   4.19.118-v8+     docker://19.3.12
kube-worker-2.cf.nownabe.in   Ready    <none>   30d   v1.18.4   10.0.1.102    <none>        Raspbian GNU/Linux 10 (buster)   4.19.118-v8+     docker://19.3.11
kube-worker-3.cf.nownabe.in   Ready    <none>   23d   v1.18.4   10.0.1.103    <none>        Raspbian GNU/Linux 10 (buster)   4.19.118-v8+     docker://19.3.12
kube-worker-4.cf.nownabe.in   Ready    <none>   23d   v1.18.4   10.0.1.104    <none>        Raspbian GNU/Linux 10 (buster)   4.19.118-v8+     docker://19.3.12
sv-1.cf.nownabe.in            Ready    master   31d   v1.18.3   10.0.1.1      <none>        Debian GNU/Linux 10 (buster)     4.19.0-9-amd64   docker://19.3.11

flannel インストール

最後に Network Add-on として flannel をインストールしました。最初に Calico、次に Cilium をインストールしようとしたんですが上手く行かずに flannel になりました。調べてからインストールすればよかったんですが、Arm の 64bit に対応できてませんでした。

flannel のインストールは公式で用意されているマニフェスト YAML を apply で OK です。

curl -O https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
kubectl apply -f kube-flannel.yml

するとこんな感じで Daemon Set として flannel がデプロイされます。

$ kubectl get po --output wide --all-namespaces
NAMESPACE     NAME                                         READY   STATUS    RESTARTS   AGE   IP           NODE                          NOMINATED NODE   READINESS GATES
kube-system   coredns-66bff467f8-8dspl                     1/1     Running   0          20d   10.4.4.2     kube-worker-3.cf.nownabe.in   <none>           <none>
kube-system   coredns-66bff467f8-vfx8d                     1/1     Running   0          30d   10.4.2.2     kube-worker-2.cf.nownabe.in   <none>           <none>
kube-system   etcd-sv-1.cf.nownabe.in                      1/1     Running   0          31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>
kube-system   kube-apiserver-sv-1.cf.nownabe.in            1/1     Running   0          31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>
kube-system   kube-controller-manager-sv-1.cf.nownabe.in   1/1     Running   193        31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>
kube-system   kube-flannel-ds-amd64-dpw88                  1/1     Running   10         31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>
kube-system   kube-flannel-ds-arm-mld8c                    1/1     Running   0          23d   10.0.1.104   kube-worker-4.cf.nownabe.in   <none>           <none>
kube-system   kube-flannel-ds-arm-q2z9v                    1/1     Running   0          31d   10.0.1.101   kube-worker-1.cf.nownabe.in   <none>           <none>
kube-system   kube-flannel-ds-arm-qfqcs                    1/1     Running   2          23d   10.0.1.103   kube-worker-3.cf.nownabe.in   <none>           <none>
kube-system   kube-flannel-ds-arm-wgg4d                    1/1     Running   2          30d   10.0.1.102   kube-worker-2.cf.nownabe.in   <none>           <none>
kube-system   kube-proxy-429jm                             1/1     Running   0          31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>
kube-system   kube-proxy-55tgl                             1/1     Running   0          23d   10.0.1.104   kube-worker-4.cf.nownabe.in   <none>           <none>
kube-system   kube-proxy-f4msl                             1/1     Running   0          23d   10.0.1.103   kube-worker-3.cf.nownabe.in   <none>           <none>
kube-system   kube-proxy-fp6d2                             1/1     Running   0          30d   10.0.1.102   kube-worker-2.cf.nownabe.in   <none>           <none>
kube-system   kube-proxy-hntn9                             1/1     Running   0          31d   10.0.1.101   kube-worker-1.cf.nownabe.in   <none>           <none>
kube-system   kube-scheduler-sv-1.cf.nownabe.in            1/1     Running   190        31d   10.0.1.1     sv-1.cf.nownabe.in            <none>           <none>

1 ヶ月ブログ書くの先延ばしにしてたこともばっちりわかって素晴らしいですね 🙌

おわりに

Kubernetes 構築編は以上です。無事に Kubernetes が構築できて満足です 😆

Network に関しては flannel だけだと Network Policy が使えないので、またそのうちなんとかしたいと思います。

次からはいろいろ機能追加していきたいので、まずは GitOps ですかねー。

CoreDNS で DNS サーバたてた

Sat, 11 Jul 2020 11:30:44 GMT

CoreDNS を使って自宅のネットワークに DNS サーバをたてました。

Kubernetes を構築して¹プライベートのサービスを動かそうと思ってたんですが、そのときにサービスにもドメインつけたいし、サーバごにょごにょするときのもドメインほしいしってことで DNS サーバをたてました。

そもそもたてる必要あるの？

SSH するときも Web でアクセスするときも IP よりはドメインの方がいいので、なんらかの DNS サーバは必要でした。 DNS サーバの選択肢として、他にはパブリッククラウドの DNS サービス、ルータの DNS 機能がありました。

簡単に比較するとこんな感じです。

項目	クラウド	自前CoreDNS	ルータ	コメント
料金	😷	😆	😆	有料か無料か
反応速度	😷	😆	😆	やっぱりローカルは圧倒的に速い
運用	😆	😷	😷	オンプレはだるい
設定	😆	😆	😷	/etc/hosts書き換えればOK
自動化	😆	😃	😷	etcdプラグインとか使えば簡単にできる
機能	😄	😆	😷	まあいろいろできる

速くて無料で必要な機能が実現できる、ということで自前で DNS サーバたてることを選択しました。運用に関しても、データぶっ飛んでもすぐ復旧できるレベルでしか使わないだろうし、なんか問題でてきたらクラウドに移せばいいぐらいの感覚です。

なんでCoreDNS？

CoreDNS っていうのは CNCF にホストされている、Go で書かれた DNS サーバです。

CoreDNS を選んだのはこのへんが理由です。

CNCF のプロジェクトということで以前から使ってみたいと思ってた
dnsmasq 的な /etc/hosts での設定ができる
DB (etcd) をバックエンドにできるのでバックアップとか自動化とかが楽
プラグインが簡単に書けるので楽しそう
設定がシンプル
機能が全部プラグインで実現されてるって思想が良い
Go で書かれている

今まで Bind、dnsmasq、PowerDNS を構築、運用したことあるんですが、今の所一番気に入ってます。使用感もいいし、わくわく感もあります。

構築手順

Kubernetes のマスターとなるサーバにインストールしました。以下 root での実行コマンドです。

# ダウンロード、インストール

curl -LO https://github.com/coredns/coredns/releases/download/v1.6.9/coredns_1.6.9_linux_amd64.tgz
tar xf coredns_1.6.9_linux_amd64.tgz
mv coredns /usr/local/bin/
chown root. /usr/local/bin/coredns


# CoreDNS用ユーザの追加

useradd -l -r -s /usr/sbin/nologin -m -d /var/lib/coredns -c 'CoreDNS user' coredns


# systemdのユニットファイル

cat <<EOF > /etc/systemd/system/coredns.service > /etc/systemd/system/coredns.service
[Unit]
Description=CoreDNS
Documentation=https://coredns.io
After=network.target

[Service]
LimitNOFILE=1048576
LimitNPROC=512
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
User=coredns
WorkingDirectory=/var/lib/coredns
ExecStart=/usr/local/bin/coredns -conf=/etc/coredns/Corefile
ExecReload=/bin/kill -SIGUSR1 $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF


# CoreDNSの設定

mkdir /etc/coredns
cat <<EOF > /etc/coredns/Corefile
(common) {
  cache
  errors
  loop
}

. {
  forward . 8.8.8.8 1.1.1.1
  health :1053
  import common
  prometheus :9153
  reload
}

nownabe.in {
  hosts /etc/coredns/nownabe.in
  import common
}
EOF

# nownabe.inのレコード設定

cat <<EOF > /etc/coredns/nownabe.in
10.0.0.2   rtx.cf.nownabe.in
10.0.1.1   sv-1.cf.nownabe.in dns.cf.nownabe.in kube-master.cf.nownabe.in
10.0.1.101 kube-worker-1.cf.nownabe.in
10.0.1.102 kube-worker-2.cf.nownabe.in
10.0.1.103 kube-worker-3.cf.nownabe.in
10.0.1.104 kube-worker-4.cf.nownabe.in
EOF


# CoreDNS有効化、起動
systemctl enable coredns
systemctl start coredns

バイナリひとつで動くのがいいですよね。Go プロダクトって感じです。

systemd のユニットファイルは、coredns/deployment というリポジトリにある coredns.service を参考にしました。ちょっと古かったり余計な権限がついてたりしたので、少し修正しています。

今の所レコードは/etc/hosts 形式で設定しています。

DHCPの設定

ルータ RTX830 を DHCP サーバに使っているので、構築した DNS サーバを設定しました。

no dns server pp 1
no dns server dhcp lan2
no dns server select 500000 dhcp lan2 any .
no dns server select 500001 pp 1 any . restrict pp 1
dns server 10.0.1.1 8.8.8.8 1.1.1.1
dns notice order dhcp server
dns domain cf.nownabe.in

クライアントの設定

DHCP を使っていないサーバにはそれぞれ手動で設定しました。いろいろあるのでそれぞれの設定は省略しますが、 /etc/resolv.conf はこんな感じです。

nameserver 10.0.1.1
nameserver 8.8.8.8
nameserver 1.1.1.1
domain cf.nownabe.in
search cf.nownabe.in nownabe.in

試してみる

$ dig kube-worker-1.cf.nownabe.in

; <<>> DiG 9.11.5-P4-5.1ubuntu2.2-Ubuntu <<>> kube-worker-1.cf.nownabe.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39530
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 10fad6c1cf5760b3 (echoed)
;; QUESTION SECTION:
;kube-worker-1.cf.nownabe.in.   IN      A

;; ANSWER SECTION:
kube-worker-1.cf.nownabe.in. 2288 IN    A       10.0.1.101

;; Query time: 0 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: 土  7月 11 21:35:29 JST 2020
;; MSG SIZE  rcvd: 111

いいですねー。0ms で答えが返ってきてます。

外部ドメインでもキャッシュされてると 0ms で返ってきます。

$ dig google.com

; <<>> DiG 9.11.5-P4-5.1ubuntu2.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61410
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 1fc6abfd8e8a2b9d (echoed)
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             298     IN      A       172.217.24.142

;; Query time: 0 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: 土  7月 11 21:38:23 JST 2020
;; MSG SIZE  rcvd: 77

パブリック DNS サーバに問い合わせると 4ms とかかかります。

$ dig google.com @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1ubuntu2.2-Ubuntu <<>> google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             203     IN      A       172.217.27.78

;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: 土  7月 11 21:38:38 JST 2020
;; MSG SIZE  rcvd: 55

ただ、キャッシュにのってない場合はめちゃくちゃ遅くなります。うーんなんでだろう。²

$ dig google.com

; <<>> DiG 9.11.5-P4-5.1ubuntu2.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       172.217.24.142

;; Query time: 84 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: 土  7月 11 21:38:22 JST 2020
;; MSG SIZE  rcvd: 65

おわりに

以上です。無事に ssh kube-worker-1 ができるようになって満足です。キャッシュにのってない外部ドメインのクエリがめっちゃ遅いのは不便なのでなんとかしたいですね。²

今後は、簡単な Web UI とかを作りたいなーと思ってます。

おうちKubernetes構築日記その1 Raspberry Pi編 - nownab.log ↩
記事書いた直後に調べたら、単純にサーバから外に出る回線(PPPoE)が遅いだけだった ↩ ↩²

Raspberry Pi 4 のベンチマーク

Sat, 04 Jul 2020 10:43:02 GMT

Raspberry Pi 4 の各種ベンチマークを取ってみました。 UnixBench と fio です。雑にほぼデフォルト設定で計測ました。チューニング等もまったくしてません。

Raspberry Pi 4 の生の結果は最後にまとめて貼っておきます。

比較対象

何かしら比較対象がほしかったので、この辺りを使いました。

マシン	CPU	Memory	Disk 1	Disk 2	OS	Kernel
Raspberry Pi 4 Model B	Arm Cortex-A72 1.5GHz 4 cores	8GB	Samsung EVO Plus 512GB microSDXC	-	Raspberry OS buster	Linux 4.19.118
Raspberry Pi 3 Model B	Arm Cortex-A53 1.2GHz 4 cores	1GB	Kingston microSDHC 16GB	-	Raspberry OS	?
Server	Core i3-2100T 2.5GHz 2 cores 4 threads	16GB	WD SATA 1TB	-	Debian buster	Linux 4.19.0
Desktop PC	Core i7-8700K 3.7GHz 6 cores 12 threads	64GB	CFD SATA3.0 NAND SSD 240GB	WD Blue SATA3.0 5400rpm 4TB	Ubuntu 19.10	Linux 5.3.0

注意点として、Raspberry Pi 4 は多分電力が足りてません。¹

UnixBench

セットアップ

sudo apt install git
git clone https://github.com/kdlucas/byte-unixbench
cd byte-unixbench/UnixBench
./Run

結果

Raspberry Pi 3 に比べるとだいぶ良い結果が出てますね。 System Call Overhead だけなぜか負けてます。

一番お金かかってるデスクトップ PC が圧倒的に勝ってて安心しました。

グラフは Index Score です。

fio

セットアップ

sudo apt install libaio-dev fio

fio のバージョンは 3.12。

設定

[sequential_read]
rw=read
size=1g
ioengine=libaio
direct=1
group_reporting

[sequential_write]
rw=write
size=1g
ioengine=libaio
direct=1
group_reporting

[random_read]
rw=randread
size=1g
ioengine=libaio
direct=1
group_reporting

[random_write]
rw=randwrite
size=1g
ioengine=libaio
direct=1
group_reporting

結果

今回 Evo Plus というそこそこいい SD カードを使ってますが、Seqeuntial、Random ともに Read が 2500IOPS、Write が 600IPS 程度でした。

Raspberry Pi 3 は遅すぎたので計測してません。

ログ

以下、Raspberry Pi 4 の計測ログです。

UnixBench

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: raspberrypi: GNU/Linux
   OS: GNU/Linux -- 4.19.118-v8+ -- #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
   15:04:13 up  1:53,  1 user,  load average: 0.15, 0.04, 0.04; runlevel Jul

------------------------------------------------------------------------
Benchmark Run: Fri Jul 03 2020 15:04:13 - 15:32:03
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       10044316.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2384.8 MWIPS (9.6 s, 7 samples)
Execl Throughput                               1475.8 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        181135.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           53422.1 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        482507.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                              315057.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  50713.4 lps   (10.0 s, 7 samples)
Process Creation                               2397.1 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3494.7 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1011.6 lpm   (60.0 s, 2 samples)
System Call Overhead                         276956.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   10044316.9    860.7
Double-Precision Whetstone                       55.0       2384.8    433.6
Execl Throughput                                 43.0       1475.8    343.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     181135.5    457.4
File Copy 256 bufsize 500 maxblocks            1655.0      53422.1    322.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     482507.3    831.9
Pipe Throughput                               12440.0     315057.3    253.3
Pipe-based Context Switching                   4000.0      50713.4    126.8
Process Creation                                126.0       2397.1    190.2
Shell Scripts (1 concurrent)                     42.4       3494.7    824.2
Shell Scripts (8 concurrent)                      6.0       1011.6   1685.9
System Call Overhead                          15000.0     276956.8    184.6
                                                                   ========
System Benchmarks Index Score                                         413.0

------------------------------------------------------------------------
Benchmark Run: Fri Jul 03 2020 15:32:03 - 15:59:55
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       40160712.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     9531.8 MWIPS (9.5 s, 7 samples)
Execl Throughput                               4203.8 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        288344.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           85784.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        707436.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1255488.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 196997.0 lps   (10.0 s, 7 samples)
Process Creation                               7350.2 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   8076.0 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1090.8 lpm   (60.1 s, 2 samples)
System Call Overhead                        1070133.2 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   40160712.8   3441.4
Double-Precision Whetstone                       55.0       9531.8   1733.0
Execl Throughput                                 43.0       4203.8    977.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     288344.1    728.1
File Copy 256 bufsize 500 maxblocks            1655.0      85784.9    518.3
File Copy 4096 bufsize 8000 maxblocks          5800.0     707436.9   1219.7
Pipe Throughput                               12440.0    1255488.7   1009.2
Pipe-based Context Switching                   4000.0     196997.0    492.5
Process Creation                                126.0       7350.2    583.3
Shell Scripts (1 concurrent)                     42.4       8076.0   1904.7
Shell Scripts (8 concurrent)                      6.0       1090.8   1818.0
System Call Overhead                          15000.0    1070133.2    713.4
                                                                   ========
System Benchmarks Index Score                                        1056.0

fio

$ fio sequential_read.fio
sequential_read: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=11.5MiB/s][r=2938 IOPS][eta 00m:00s]
sequential_read: (groupid=0, jobs=1): err= 0: pid=2885: Fri Jul  3 17:40:44 2020
  read: IOPS=2980, BW=11.6MiB/s (12.2MB/s)(1024MiB/87960msec)
    slat (usec): min=33, max=171, avg=64.53, stdev=12.05
    clat (usec): min=173, max=20162, avg=260.20, stdev=42.60
     lat (usec): min=245, max=20201, avg=326.99, stdev=46.23
    clat percentiles (usec):
     |  1.00th=[  229],  5.00th=[  241], 10.00th=[  245], 20.00th=[  249],
     | 30.00th=[  253], 40.00th=[  258], 50.00th=[  262], 60.00th=[  265],
     | 70.00th=[  269], 80.00th=[  269], 90.00th=[  281], 95.00th=[  281],
     | 99.00th=[  285], 99.50th=[  293], 99.90th=[  326], 99.95th=[  334],
     | 99.99th=[  355]
   bw (  KiB/s): min=11272, max=14344, per=100.00%, avg=11920.73, stdev=485.76, samples=175
   iops        : min= 2818, max= 3586, avg=2980.18, stdev=121.44, samples=175
  lat (usec)   : 250=21.51%, 500=78.48%, 750=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 50=0.01%
  cpu          : usr=4.45%, sys=14.76%, ctx=524478, majf=0, minf=23
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=1024MiB (1074MB), run=87960-87960msec

Disk stats (read/write):
  mmcblk0: ios=261954/17, merge=0/4, ticks=77219/147, in_queue=76448, util=86.89%

$ fio sequential_write.fio
sequential_write: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=2530KiB/s][w=632 IOPS][eta 00m:00s]
sequential_write: (groupid=0, jobs=1): err= 0: pid=2906: Fri Jul  3 17:47:38 2020
  write: IOPS=643, BW=2573KiB/s (2635kB/s)(1024MiB/407490msec); 0 zone resets
    slat (usec): min=41, max=3885, avg=90.60, stdev=12.75
    clat (usec): min=234, max=30675, avg=1450.39, stdev=687.41
     lat (usec): min=706, max=30723, avg=1543.73, stdev=688.03
    clat percentiles (usec):
     |  1.00th=[  701],  5.00th=[  775], 10.00th=[  791], 20.00th=[  857],
     | 30.00th=[  947], 40.00th=[ 1270], 50.00th=[ 1336], 60.00th=[ 1418],
     | 70.00th=[ 1811], 80.00th=[ 1876], 90.00th=[ 1909], 95.00th=[ 1975],
     | 99.00th=[ 3884], 99.50th=[ 3884], 99.90th=[ 3949], 99.95th=[ 7570],
     | 99.99th=[12649]
   bw (  KiB/s): min= 2480, max= 3616, per=100.00%, avg=2573.18, stdev=128.26, samples=814
   iops        : min=  620, max=  904, avg=643.29, stdev=32.06, samples=814
  lat (usec)   : 250=0.01%, 750=3.62%, 1000=26.62%
  lat (msec)   : 2=65.39%, 4=4.28%, 10=0.05%, 20=0.04%, 50=0.01%
  cpu          : usr=1.30%, sys=4.11%, ctx=525790, majf=0, minf=26
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=2573KiB/s (2635kB/s), 2573KiB/s-2573KiB/s (2635kB/s-2635kB/s), io=1024MiB (1074MB), run=407490-407490msec

Disk stats (read/write):
  mmcblk0: ios=0/262249, merge=0/81, ticks=0/392373, in_queue=388416, util=95.27%

$ fio random_read.fio
random_read: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=0): [f(1)][100.0%][r=9849KiB/s][r=2462 IOPS][eta 00m:00s]
random_read: (groupid=0, jobs=1): err= 0: pid=2948: Fri Jul  3 17:50:27 2020
  read: IOPS=2453, BW=9813KiB/s (10.0MB/s)(1024MiB/106851msec)
    slat (usec): min=36, max=451, avg=70.23, stdev=11.65
    clat (usec): min=132, max=1188, avg=324.00, stdev=13.82
     lat (usec): min=245, max=1429, avg=396.66, stdev=22.00
    clat percentiles (usec):
     |  1.00th=[  289],  5.00th=[  302], 10.00th=[  310], 20.00th=[  314],
     | 30.00th=[  318], 40.00th=[  322], 50.00th=[  326], 60.00th=[  326],
     | 70.00th=[  330], 80.00th=[  338], 90.00th=[  343], 95.00th=[  343],
     | 99.00th=[  347], 99.50th=[  351], 99.90th=[  371], 99.95th=[  383],
     | 99.99th=[  424]
   bw (  KiB/s): min= 9516, max=11528, per=99.96%, avg=9808.85, stdev=357.16, samples=213
   iops        : min= 2379, max= 2882, avg=2452.24, stdev=89.29, samples=213
  lat (usec)   : 250=0.11%, 500=99.89%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%
  cpu          : usr=4.29%, sys=13.33%, ctx=524445, majf=0, minf=22
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=9813KiB/s (10.0MB/s), 9813KiB/s-9813KiB/s (10.0MB/s-10.0MB/s), io=1024MiB (1074MB), run=106851-106851msec

Disk stats (read/write):
  mmcblk0: ios=261589/0, merge=0/0, ticks=94558/0, in_queue=91684, util=85.93%

$ fio random_write.fio
random_write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=2574KiB/s][w=643 IOPS][eta 00m:00s]
random_write: (groupid=0, jobs=1): err= 0: pid=2952: Fri Jul  3 17:57:46 2020
  write: IOPS=632, BW=2530KiB/s (2591kB/s)(1024MiB/414491msec); 0 zone resets
    slat (usec): min=41, max=4332, avg=91.16, stdev=15.87
    clat (usec): min=579, max=88041, avg=1474.56, stdev=1151.84
     lat (usec): min=707, max=88136, avg=1568.45, stdev=1152.45
    clat percentiles (usec):
     |  1.00th=[  701],  5.00th=[  775], 10.00th=[  791], 20.00th=[  857],
     | 30.00th=[  963], 40.00th=[ 1270], 50.00th=[ 1336], 60.00th=[ 1418],
     | 70.00th=[ 1811], 80.00th=[ 1876], 90.00th=[ 1909], 95.00th=[ 1975],
     | 99.00th=[ 3884], 99.50th=[ 3884], 99.90th=[11469], 99.95th=[30802],
     | 99.99th=[32375]
   bw (  KiB/s): min= 2096, max= 3576, per=100.00%, avg=2529.50, stdev=147.52, samples=828
   iops        : min=  524, max=  894, avg=632.35, stdev=36.88, samples=828
  lat (usec)   : 750=3.66%, 1000=26.42%
  lat (msec)   : 2=65.52%, 4=4.25%, 10=0.02%, 20=0.05%, 50=0.07%
  lat (msec)   : 100=0.01%
  cpu          : usr=1.35%, sys=4.12%, ctx=525780, majf=0, minf=21
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=2530KiB/s (2591kB/s), 2530KiB/s-2530KiB/s (2591kB/s-2591kB/s), io=1024MiB (1074MB), run=414491-414491msec

Disk stats (read/write):
  mmcblk0: ios=0/262251, merge=0/83, ticks=0/398727, in_queue=393828, util=94.97%

おうちKubernetes構築日記その1 Raspberry Pi編 - nownab.log ↩

nownab.log

ブログのデザインを変えた (2026 年版)

開発環境式年遷宮 (2026年)

きっかけ

OS

dotfiles

エディタ

ターミナル

ターミナルマルチプレクサ

シェル

AI Agent

あとがき

2024 年の抱負

やるぞ

1. 健康になる

2. 家族の健康を守る

3. ずとまよのライブに行く

4. 仕事を頑張る

5. 英語の勉強を再開する

6. スプラトゥーンを頑張る

7. 本を読む

8. 攻めの株を始める

やらないこと

おわりに

2023 年を振り返る

はじめに

仕事

ざっくり振り返る

転職してよかった？

プライベート

おわりに

Footnotes

元 Googler が Knowledge Work に入社して2ヶ月経った

はじめに

TL; DR と宣伝

Knowledge Work に入社した

Knowledge Work に決めた理由

この 2 ヶ月なにしてたの？

で、入社してどうだった？

おわりに

ブログのデザインを変えた (2023 年版)

Before

After

Todo

PC を新調した (2023 年版)

新調した理由

BTO にした理由

パーツ

箱

感想

Windows 11 の WSL で GPU を使って rinna InstructGPT

はじめに

GPU on WSL

InstructGPT

おわりに

マンタローに勇気をもらって Google Cloud を辞めた話

はじめに

Disclaimer

Google Cloud で何をしたか

Google に入社してよかったこと

営業職をやってよかったこと

辞めた理由

悩んだこと

おわりに

自分のウェブサイトを GitHub のプロフィール README と同期させた

ob_start についての補足

はじめに

PHP という言語

ob_start とは

ob_start の特徴まとめ

ob_start の解釈

おわりに

ZUTOMAYO FACTORY「鷹は飢えても踊り忘れず」で表示されていたプログラムについて

はじめに

注意点

ライブで現れた 3 つのプログラム

バナー画像のプログラム

[day1 “memory_limit = -1”] のプログラム

プログラムの解説

前提