
『[疲労とはなにか すべてはウイルスが知っていた](https://bookclub.kodansha.co.jp/product?item=0000385169)』を読みました。

「疲れ知らずになりたい」という邪な気持ちで手に取ったわけですが、得られた結論は「疲れは必要であり、疲れ知らずになることはできない」ということでした。

本書は「疲労」と「疲労感」を分けて捉えるところからはじまります。「疲労感」を軽減する方法はいくつかあり、たとえばエナジードリンクに含まれる抗酸化成分によって疲労感は抑えられる、ということでした。しかし、これは単なる疲労感の抑制であり、内蔵や体の筋繊維は通常通り疲労を蓄積するそうです。したがって、エナジードリンクの過剰摂取によって真の疲労に気づかず、体組織の障害や突然死にいたる可能性もあるとのこと。

また、疲労そのものはビタミンB1が欠乏すると解消しない、とありました。「eIF2α」という酵素にリンがくっつくことが疲労であり、それを剥がす働きをする酵素を出すには軽い運動が必要、ということが書かれていました。重い疲労を回復するため、軽い疲労が必要というのは興味深い話でした。

しかし、残念ながら「疲れ知らず」になるために役立つ知識としてはここまででした。

後半では「病的疲労」としてうつ病やコロナウイルス後遺症の話がありました。僕の興味の範疇ではなかったのですが、いずれも原因についてクリアに説明されており「そこまでわかっているものなのか」と思いました。

余談ですが、会社の人事は「ストレス耐性の高い人 (= うつ病になりにくい)」を選り好みすべきでない、という話がありました。ストレス耐性の高い人は「対人関係に極めて鈍感で戦力にならない」とのこと。

> そんなことをしたら、真面目で、仕事熱心で、献身的で、責任感が強い、おおいに会社のためになってくれる人が入ってこなくなるからです。

だそうです。

ところで、本書は「講談社ブルーバックス」のシリーズだけあり、内容に手抜きがなく、記述の随所に科学的な裏付けがありました。これは読み応えがあると同時に、自分の知識不足を痛感させられることでもありました。正直に言えば、書籍で語られている内容の一部は「よくわからないな...」と思いながら目を通しました。一方で、小難しい話によって「煙に巻かれている」という感覚もなく、著者の専門領域の語彙で、この内容を正確に表現しようとすると、このようなテキストになるのだな、という感想です。いつか化学および生物学の知識を仕入れ直して再挑戦したい本の一冊となりました。

それにしても、かつて『[デザインされたギャンブル依存症](https://mahata.gitlab.io/post/2021-10-16-addiction-by-design/)』を読んだときは「効率よくゾーンに入りたい」という気持ちで本を手に取ったものでした。今回も「疲れ知らずになりたい」という気持ちであったわけですが、いつも「楽な道などない」と思わされる結果に終わります。中々うまくいかないものです。


【読書メモ】『疲労とはなにか すべてはウイルスが知っていた』


途中まで読んだ『[Software Engineer at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』をギブアップしました。この本は去年の内に半分くらいまで読み、その後で放ったらかしにしていたものです。何章か感想を書いたりもしました。

* [Software Engineering at Google: Chapter 1 - What Is Software Engineering](https://mahata.vercel.app/posts/2023-02-06-software-engineering-at-google-chapter1-what-is-software-engineering)
* [Software Engineering at Google: Chapter 2 - How To Work Well On Teams](https://mahata.vercel.app/posts/2023-02-10-software-engineering-at-google-chapter2-how-to-work-well-on-teams)
* [Software Engineering at Google: Chapter 3 - Knowledge Sharing](https://mahata.vercel.app/posts/2023-02-14-software-engineering-at-google-chapter3-knowledge-sharing)

第三章を読んだ後、気になる章をピックアップして読むスタイルに変えて、最終的に興味を失った、という感じです。

## "at Google"

もともとは『Software Engineering at Google』というタイトルの "at Google" という言葉が発する魅力に惹かれて読み始めました。Google といえばエンジニアリングの会社であり、そこで培われている技術には特別なものがあるのでは、と思っていました。

ところが、最近は Google に対するリスペクトを強く持てなくなりました。特に 2023 年の Google は、外部の者としては「ダサい」とすら感じました。Google 社員の 6% に相当する 12,000 人がレイオフされ、一方で [CEO の Sundar Pichai 氏は $226M の報酬を受け取ったと報じられて](https://www.cnbc.com/2023/05/03/google-employees-complain-about-ceo-sundar-pichais-pay-raise.html)います。これは [Apple の Tim Cook 氏が自身の役員報酬を減らし](https://www.cnbc.com/2023/01/12/apple-ceo-tim-cook-receives-a-40percent-pay-cut-after-shareholder-vote.html)つつ、レイオフを行わなかったこととの対比で、さらにダサさが際立ちました。

Google 製のプロダクトも、近年は魅力に欠けます。ChatGPT の後追いで登場した Bard からは ChatGPT ほどの賢さを感じられません。Google 検索にはノイズが増え続けています。Google Home は簡単な会話すらままなりません。Gmail へのスパムも増え続けています。[AWS の後を追っていたはずの GCP は Azure ほど伸びていません](https://www.publickey1.jp/blog/24/publickeyit2024azureaws_it.html)。

"at Google" が魅力的でないのに、なぜ『Software Engineering at Google』を読み続けるのか...。そういう気持ちになり、読み進める気持ちをなくしてしまいました。

ところで昨年末には [Spotify が 17% の従業員をレイオフするというニュース](https://www.cnbc.com/2023/12/04/spotify-to-lay-off-17percent-of-employees-ceo-daniel-ek-says.html)も飛び込んできました。こうなると、[過去に読んだ『ユニコーン企業の秘密』](https://mahata.gitlab.io/post/2021-06-18-unicorn-kigyo-no-himitsu/)のありがたみも目減りします。

企業ブランドは水物であり、コンテンツがそれに依存するようでは歴史の重みに耐えかねるな、と感じました。


ギブアップ: Software Engineering at Google 


2024 年は年初から悲しいニュースを多く目にしました。元日には[令和6年能登半島地震](https://ja.wikipedia.org/wiki/%E4%BB%A4%E5%92%8C6%E5%B9%B4%E8%83%BD%E7%99%BB%E5%8D%8A%E5%B3%B6%E5%9C%B0%E9%9C%87)が発生し、倒壊した建物や、燃え上がる家屋の様子などが東京都内の全てのテレビチャンネルで流れました。

その翌日には羽田空港で炎上する飛行機の様子が流れました。報道によれば、前述の[能登半島地震の救援に向かう海上保安庁の航空機と日本航空の旅客機が衝突した](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E8%88%AA%E7%A9%BA516%E4%BE%BF%E8%A1%9D%E7%AA%81%E7%82%8E%E4%B8%8A%E4%BA%8B%E6%95%85)とのことです。この事故で海上保安庁の職員 5 名が亡くなられたそうです。

地震に関しては、この記事を書いている時点でも「落ち着いている」状態とは言い難いです。被災地の一日も早い復興を願っています (少額ながら「[能登半島地震災害義援金](https://www.jrc.or.jp/contribute/help/20240104/)」への寄付を行いました)。

僕は東北の出身で、実家が宮城県仙台市にあります。[東北大震災](https://ja.wikipedia.org/wiki/%E6%9D%B1%E6%97%A5%E6%9C%AC%E5%A4%A7%E9%9C%87%E7%81%BD)の折には東京にいたので直接的な被害は被っていないものの、事態が落ち着いた後で仙台市に戻ったときには災害の爪痕の大きさを感じずにはいられませんでした。

自分は「運良く生きているだけ」だと感じます。災害に好んで巻き込まれたい人はいないでしょう。これまで運良く、自分は幸せに生きてこられらたと思っています。これを「当然のこと」と思い上がることなく、一日一日を大事に生きなければならないと思う年始でした。


運良く生きている


今年のまとめを書きます。

なお去年までの分はこちらの通りです。

* [2022年のまとめ](https://mahata.vercel.app/posts/2022-12-23-retrospective)
* [2021年のまとめ](https://mahata.gitlab.io/post/2021-12-25-retrospective/)

## 去年のまとめを振り返る

> 今年の中旬まで、技術メモは Dropbox Paper に書いていたけど MarkText にスイッチした。このブログ記事も、下書きは MarkText に書いている。

[MarkText](https://www.marktext.cc/) は使わず、代わりに [Obsidian](https://obsidian.md/) を使うようになりました。Obsidian はかなり良い。MarkText は 2022 年の時点でも不満を感じながら使っていたけど Obsidian には不満がほぼないです。強いて言えば、僕自身が Obsidian の機能を使いこなしてないように感じるくらいです。機能そのものには大満足なので 2024 年も使い続けていると思います。

> 僕は (中略) Twitter からは距離を置きたいと思うようになった。
> 
> 何が代替として優れているのかよくわからないながら、代替手段としておそらく最も選ばれているであろう Mastodon に僕も移行した。Mastodon にも思うところはあるけど、今のところは便利に使えている。

さらに Mastodon から離れて [Bluesky](https://bsky.app/) へと移りました。 Bluesky の UI がほぼ Twitter で、自分はそこに心地よさを感じています。それだけに「過去の Twitter は素晴らしいものだったな」とも思うようになり、Bluesky への不満もあります。たとえば検索機能が貧弱であったり DM が送れなかったり。多くの友人が Bluesky に来ておらず、Mastodon や Threads、Misskey や LinkedIn などに分散していることもあり、まだ「Bluesky 一択」と言えるところまでではないです。

> 今年はついに、定期健康診断時に「少し体重を落とした方が良いです」と医師に言われてしまった。その言葉を受けて、ダイエットをはじめた。

ダイエットは無事に成功しました。だいたい 5~6 kg の減量です。「[あすけん](https://www.asken.jp/)」と、後述する Anker の体組成計で達成できました。よかったよかった。

> 実は懸垂を 1 回もできないのだが、近所の公園でぶら下がることからはじめている。2023 年には 2-3 回くらい自分自身を持ち上げられるようになりたい。

自重を 1 回だけ持ち上げられるようになった...のが初夏の頃です。僕は帰宅時に公園の懸垂台を使うことが多いのですが、夏になると人が遅くまでたむろするようになり、あまり懸垂をすることがなくなりました。僕の成長はここまで...。ただ、人目を気にせず懸垂の練習をできるメンタルも欲しいので 2024 年こそはやるぞ、という気持ちです。

> 英語をずっと聴いていると疲れるので、日本語で頭を使わずに消費できるコンテンツがほしく、たまたま発見したドングリfmというポッドキャストもたまに聴いている。主にホストが雑談しているだけの番組だけど、ちょっと「ふふっ」となることが多く、癒やされている。

最近は英語をずっと聞いていても疲れなくなったので、もっぱら [Syntax](https://syntax.fm/) を聞いています。ほどよく技術的なトピックがカバーされていて楽しいです。ホストの二人の人柄にも好感を持っています。

> オンライン大学院にも少し興味がある。ただ、かなり時間を取られそうなので、手が出ない可能性もある。本当に手が出ないかどうか確かめるため MOOC でいくつか大学院レベルの講義を受講するくらいが現実的なラインかもしれない。

これは興味が薄れました。アカデミックなことよりも、もっと実践的なことを学ぶ方が今の自分には有意義だと感じています。たとえば僕は Spring Boot や React についての理解を深める方が仕事に役立つだろうと思います。

とはいえ、大学院でのコースワークは「仕事に役立てたい」という気持ちよりは「知的好奇心を満たしたい」というところから来ていたので、仕事にもっと余裕が出てきたら改めて検討するかもしれないです。しかし 2024 年中には手をつけられないだろうとも思っています。

> あとは CKA が2023年10月に期限切れしてしまうので、その前に CKS に更新しておきたい。

無事に [CKS (Certified Kubernetes Security Specialist) を取得しました](https://zenn.dev/mahata/articles/93225ad5a4d3d7) 😉

## 読んだ本

### 技術書

2023 年は技術書はあまり読めませんでした。まともに読めたのは『[Reactハンズオンラーニング 第2版](https://www.oreilly.co.jp//books/9784873119380/)』と『[プログラミングTypeScript](https://www.oreilly.co.jp//books/9784873119045/)』、『[ベタープログラマ](https://mahata.vercel.app/posts/2023-04-20-better-programmer)』くらい。特に『Reactハンズオンラーニング 第2版』と『プログラミングTypeScript』は仕事に役立てられたので良かったです。

今読んでいる本は『[Kotlin Design Patterns and Best Practices - Second Edition](https://learning.oreilly.com/library/view/kotlin-design-patterns/9781801815727/)』です。これは Kotlin を書く人には強くオススメできる本で、僕自身も複数回読むと思います。

### 漫画本

2023 年に読んだ漫画本で印象に残っているタイトルを挙げます。

* ONE PIECE
* スキップとローファー
* ザ・ファブル The second contact
* スピリットサークル
* 結界師

『ONE PIECE』は誰もが知っているタイトルだと思うのですが、僕は過去に何度か「読みかけ」て離脱していました。改めて読むと「これは人気が出るわ...」と思うストーリーラインで楽しめています。まだ途中なので今後も読みそう。

『スキップとローファー』はこのブログを書いている時点では未完ですが、読むと穏やかな気持になるところがいいです。純然たる「嫌なやつ」が登場せず、読後感がとても良いです。

『ザ・ファブル The second contact』はファーストシーズンと同様に安定して面白いです。

『スピリットサークル』は同僚に勧めてもらって、一気に読みました。一気に読めるくらいに引き込まれます。

『結界師』は古い作品で、これも過去に読みかけて離脱したタイトルなのですが、改めて読んで面白さに気づきました。作中で「親子関係」に関する描写があり、自分自身が親になった今は、かつてとは違う面白さを感じるようになりました。

## 買い物

2023 年に購入したものの中から、気に入っているものを紹介します。

* [エチケットカッター ER-GN70](https://panasonic.jp/mens/p-db/ER-GN70.html)

電動カッターに対する謎の不信感があったのですが、こちらを使うようになってハサミには戻れなくなりました。短時間で綺麗に仕上がるので、もっと早くから使えば良かったと思います。

* [ぶんぶんチョッパー](https://k-and-a.jp/bbc/bbctop.html)

かなり地味な商品ですが、野菜のみじん切りをするときの時短に役立っています。特に玉ねぎをみじん切りしようとすると目が痛みますが、これを使うと玉ねぎの催涙成分をカットできるので、涙を流すことなく調理できて便利です。よく使っています。

* [Anker Eufy Smart Scale P2 Pro](https://www.ankerjapan.com/products/t9149)

体組成計です。最初はダイエット目的で購入しました。使い勝手の良さから今も使い続けています。記録が iPhone アプリに自動で転送されること、家族全員のデータを集約できること (アプリが自動で誰の情報か振り分けてくれる) などが気に入っています。

## ソフトウェア / ウェブサービス

X (Twitter) から離れたので、情報の収集には [Feedly](https://feedly.com/) を使うようになりました。もともと 2000 年代後半から 2010 年代前半までは RSS リーダージャンキーだったので「これこれ、これだよ」という感じで使えています。しかし、昨今は RSS フィードを出力しないウェブサイトが増えているため、昔ほど「これで情報を集約できる」という感じではなくなっているとも思います。

情報収集といえば、携帯に [Artifact](https://artifact.news/) を入れて時折ニュースを読むようになりました。これは「僕が欲しかった SmartNews」という趣きです。想像ですが Artifact を作っている人たちも SmartNews をベンチマークにしていると思います。時おり「これは SmartNews のアレだな...」と思うような UI やレイアウトに出くわします。記事の推薦がゴシップくさくないことや、鬱陶しい広告が嫌なタイミングで出てこないところが特に気に入っています。

また、自分より若い世代がよく使っているツールは積極的に試そうと思っており、その意味で [Arc](https://arc.net/) を使うようになりました。過去に Brave や Edge を試すこともあり、そのときは「うん、これは 90 %くらい Chrome だな」と思っていました。一方 Arc を使うときはマインドセットを切り替える必要があり、だいぶ新しいパラダイムをもたらしています。今のところ順調に Arc に馴染んできているので 2024 年も Arc を使いそうです。 

ところで ChatGPT は 2023 年に使うようになったサービスとしては革命的に便利だと感じているのですが、これについては今さら僕が語れることも少ないので、割愛します 😛

## その他もろもろ

### 勤務先の買収

[去年転職したばかりの会社](https://mahata.vercel.app/posts/2022-12-01-startup-like-big-tech)が買収されました。また新入社員です。

公開情報だけを書こう (...というか非公開情報を知らない) と思うのですが、買収にともなう悲しい出来事の最たるものは同僚たちレイオフです。自分自身もレイオフされる可能性はあったし、同僚たちもある程度は覚悟していたと思うのですが、やはり実際に起きると悲しいものです。

大企業同士の合併は文化的にも中々む... (日記はここで途切れている)

### ライブ

今年も B'z のライブ (B’z LIVE-GYM Pleasure 2023 -STARS-) に行きました。久しぶりにマスクを外して声を出しながら鑑賞しました。相変わらず B'z のライブは楽しいし元気をもらえるので、とても良いです。今年のツアーは「デビュー 35 周年」のライブツアーでしたが、今後も長く続けてもらいたいものだと思いました。

ところで僕は B'z のファンクラブ会員であるにも関わらず、今回はファンクラブ会員向けのチケット販売期間にチケットを予約できず、一般向けチケット販売でチケットを購入しました。スケジュール管理ミスです 😢 次回は気をつけようと思いました。

### 献血

はじめて献血を体験しました。これといったキッカケはなかったけど「なにか世の中に貢献したい」欲求があったように思います。今後も続けていこうと思います。今年がはじめてだった割に、今年 3 回ほど献血をしたので、割といいペースだと思います。

### 歯医者

今まで「歯医者いらず」で、子どもの頃から歯医者にはほぼ行かずにいたのですが、ここにきて奥歯が痛むようになったので歯医者にかかるようになりました。

がりがりとドリルで歯を削られ、樹脂の詰め物をしてもらいました。こういう体験をすると「体を大事にしよう」と思うようになります。だいたい気づくときには既に遅い...というやつです。

いちど詰め物をしてしまった以上、歯医者には定期的に行く必要がありそうです。せめてこれ以上は悪くしないようにしたいです。

### 2024 年の展望

今年のダイエットはうまくいきました。リバウンドはさせず、体重をキープしたまま体脂肪率を落として筋肉量を増やしたいです。前述の Anker の体組成計を見ながら頑張ります。また、軽い腰痛持ちなのでストレッチをルーチンに含めて体の可動域 (特に腰回り) を広げたいです。

仕事関連では Kotlin プログラミングに時間を投資したい気持ちがあります。Kotlin を書いている割に Java っぽさが出てしまったりして、自分の未熟さを感じます。また [Kotlin/Wasm がアルファ版になる](https://blog.jetbrains.com/ja/kotlin/2023/12/kotlin-for-webassembly-goes-alpha/)など、Kotlin そのものを取り巻く環境も進化しており、ここへの投資は仕事の幅を広げる意味でも良いだろうと感じています。

あとは [Tanzu Application Platform](https://tanzu.vmware.com/application-platform) についての知見を深めてほしいと上司に言われているので、重い腰を上げて真面目に取り組もうと思います。


2023 年の振り返り


最近は [ktlog](https://github.com/mahata/ktlog) というサービスを作っています。これは Spring Boot (Kotlin) と React (TypeScript) で作られているブログサービスです。...というのは言い過ぎで、ブログサービスに **なる予定のもの** というのが正しいです。

これを作っているせいで、今はブログ記事をどこに書くべきか迷子になっているのですが、もうしばらくは ktlog がまともに動くようにはならなそうなので、ちょっとここで再び記事を書いてみるか、という気持ちになりました。書きます。


近況報告 - ktlog


[5月11日に Google Bard が日本語をサポート](https://japan.googleblog.com/2023/05/bard.html)してから、Google Bard (LaMDA) を利用してきました。ChatGPT の代わりを務めてもらった、ということです。

しかし、いくつかの点で不満を感じたため、涙を飲んで ChatGPT へ戻ろうと決意しました。ただいま ChatGPT。浮気してごめんな...。

まず最初にに Google Bard の「良いところ」を挙げてみようと思います。

1. すべての機能が無料で使える
2. 回答の生成が (ChatGPT の GPT-4 モデルより) 速い
3. (ChatGPT と比較して) 新しい情報も教えてくれる
4. 知らないことを「知らない」と伝えられる

`4. 知らないことを「知らない」と伝えられる` について補足します。Google Bard は答えられないことは「それについては答えられない」という旨の返答をします。これはハルシネーション (= 情報を捏造してしまうこと) よりも好ましいです。しれっと嘘をつかれると検証に時間がかかるからです。

とはいえ、これにはデメリットもあります。生成 AI を情報ソースとしてではなく対話相手として利用している場合、「それには答えられない」と返されると、そこで会話が止まってしまうのです。たとえば生成 AI が嘘をついたときに「でも、それだと xx と矛盾するよね」と言える方が **対話** としては面白いと思います。むしろ、ChatGPT はそういう使い方ができるのでウケているのだと思います。また ChatGPT に間違いを指摘すると「自分が間違えていました」と認めることもあります。このような誤りを認識し、認める能力こそ、AI における知性を感じる瞬間だと僕は思います。

さて、次は ChatGPT の方が優れていると感じる点です。

1. 履歴に「質問と回答のセット」が残る
2. (GPT-4 の場合) 生成されるテキストが Google Bard (LaMDA) より信頼できる **(要出典)**
3. スレッド形式で質問可能で、コンテキストをスレッド内でまとめられる
   * 各々のスレッドにタイトルをつけられる (最初のタイトルは ChatGPT 自身がつけてくれる)
   * (Web UI の場合) サイドバーに過去のスレッドのタイトル一覧が表示されている
     * 過去のスレッドから会話を再開することで前提を再入力する手間が省ける
4. iOS アプリがある

「生成されるテキストの質」について、僕は ChatGPT の方が優れていると感じています。しかし、実際には UI/UX に関してこそ ChatGPT を高く評価しています。

僕は技術的なトピックに関するディスカッションの相手として生成 AI を活用することが多いです。たとえば AWS で VPC/Subnet の設計をしているときに「この IP アドレスレンジでサブネットAを運用したいんだけど...」とスレッドをはじめて、一通り満足のいく会話をしたとしましょう。新しい要件が出てきたとき、このスレッドに戻ってきて「ところで VPC ピアリングもしたくなったんだけど...」と続けられるのは便利です。これは Google Bard などでは実現しがたい点です。

また、サービス履歴に「質問と回答のセット」が残っていると壁打ちしてもらった内容を一覧できて便利です。Google Bard は (デフォルトでは) 質問のみが残るようになっています。これは意図的な設計だと思うのですが、その質問から再び回答を得ようとすると時間がかかるし、そもそも同じ内容を得られるとも限りません。やはり、質問と回答がセットで残るメリットは大きいです。

最後に iOS アプリの存在も、地味に嬉しいポイントです。携帯のブラウザで同等のことを行えるものの、やはり専用アプリのユーザー体験には及ばないと感じています。

...というような理由から、Google Bard に一旦の見切りをつけて、また ChatGPT の課金ユーザーに復帰しました。半年くらいしたら、また別の生成 AI にスイッチする可能性は残っているけど、しばらくは ChatGPT を楽しもうと思います。


ChatGPT と Google Bard の比較、または再度の ChatGPT への課金


最近、懸垂ができるようになりました。まだ一回だけだけど。

「懸垂で体を持ち上げられるようになること」は今年の目標の一つでした。[去年の振り返り](/posts/2022-12-23-retrospective)で、次のように書きました。

> 単に体重を落とすという目標だとあまりモチベーションが湧かないので、並行して懸垂の練習をしている。実は懸垂を 1 回もできないのだが、近所の公園でぶら下がることからはじめている。2023 年には 2-3 回くらい自分自身を持ち上げられるようになりたい。

半年かかったけど、ようやくできて一安心。このまま「2-3 回くらい」できるようになるといいな。ところで、現時点では実は「手を伸ばした状態から」は懸垂できていなくて、最初に鉄棒をつかむためにジャンプをして、そのままの勢いで (肘が既に少しだけまがった状態から) ぐぐっと頭を鉄棒より上に出す、ということができる程度です。

道は長い...けど、最初のステップは超えられたな...という感じ。引き続きがんばろう。


「体作り」の進捗、または「初めての懸垂」


唐突ですが「〜だ」「〜である」調での文章をやめて、「〜です」「〜ます」調に転向したいと考えています。少なくともこのブログにおいては。

直近のブログ記事で色々と実験して、いけそうだなという感覚を得ています。

「そんなに大層なことか?」と思われそうですが、確認できる範囲でも [2012
年くらいからずっと「〜だ」「〜である」で文章を書いてきた](https://mahata.gitlab.io/post/page/10/)ので、意識しないとできない変化でした。

[少し前から過去のブログ記事を読み返す生活をしていて](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)、そこで断定調の自分の文体を読んで「この人、ちょっと圧が強いな...」と感じたことがきっかけです。やわらかい雰囲気の人間になりたいので、がんばります。がんばるぞ。


「〜です」「〜ます」調への転向


『[ベタープログラマ](https://www.oreilly.co.jp/books/9784873118208/)』を読了しました。 面白い部分もありましたが、同意できない点も多々ある本でした。

「謙虚な姿勢で、継続的に学ぶ」というメッセージや、「優れたプログラマを目指すということは、心地よい場所にとどまることと対極にある」という主張は納得できるものでした。

しかし、テストに関しては記述が粗いように感じました。

例えば、「単体テスト」の定義について、最小単位のテストであることを強調しながら、「順序を入れ替えて実行しても結果に影響を与えない」という点に関する記述が欠けていました。「（製品コードの他の単位が関係せずに）テストしていないのであれば、単体テストではありません」と書いてあるので、好意的に解釈すれば同等のことを言っているようにも思いますが、明確にしてほしいと感じました。

テストダブルの例として、「ダミー」、「スタブ」、そして「モック」について書かれていますが、ここでのダミーとモックの定義は誤解を招くものだと感じました。より良い定義は [Choosing the Right Test Double](https://tanzu.vmware.com/developer/guides/test-doubles/) に書かれいているものだと思います。つまり、ダミーはコールするとクラッシュするテストダブルであり、モックはスタブとスパイの機能を持ちつつ、そのオブジェクトの中でアサートまでできるものだという定義です。本書では、ダミーを「テストはそれら (= ダミーオブジェクト) を呼び出しませんが、パラメータのリストを満たすために存在しています」としており、モックに関しては要領を得ない説明になっています。

また、第3章の「少ないコードを書く」では、「使っている言語が三項演算子を提供しているなら、三項演算子を使ってください」と、『[リーダブルコード](https://www.oreilly.co.jp/books/9784873115658/)』とは真逆の主張がされていました。三項演算子は可読性を下げることが多いと感じているため、この主張には同意しかねました。



『ベタープログラマ』の感想


『[Reactハンズオンラーニング 第2版](https://www.oreilly.co.jp/books/9784873119380/)』を読了しました。 React 歴の浅い自分には、得るものが多い良い書籍でした。

この本は序盤で [Create React App](https://create-react-app.dev/) でプロジェクトの雛形を作る例を紹介しつつ、付録で Create React App 相当のことを手作業で実現する方法も扱っています。JavaScript まわりのツールチェインに疎い自分としては、Create React App の内側を理解する役に立ちました。React 本体と直接の関係はないけど、あわせて理解しておきたい「Jest」「GraphQL」「ESLint/Prettier」などについてもカバーされており、内容が実用的である印象を持ちました。

[ソースコードが GitHub で公開されており](https://github.com/oreilly-japan/learning-react-2e-ja)、セクションごとに動くサンプルが提供されている点にも好感を持ちました。少し時間をおいて、サンプルを動かしつつ読み直そうと思っています。


『Reactハンズオンラーニング 第2版』の感想


チームメイトへの自己紹介で「B'z のファンです」と話した。再確認のため、自分の B'z ファン歴を振り返ろうと思う。

「[Love Phantom](https://ja.wikipedia.org/wiki/LOVE_PHANTOM)」あたりから存在を意識し、何かの機会に兄が「[B'z The Best Treasure](https://ja.wikipedia.org/wiki/B%27z_The_Best_%22Treasure%22)」を聴かせてくれた辺りから、B'z にハマった。1998~2005 年くらいの間は、ほぼ毎日聴いていた気がする。たぶん 2000 年くらいにファンクラブ会員になった...はず。うっすらした記憶だけど、2001 年の「[B'z LIVE-GYM 2001 -ELEVEN-](https://ja.wikipedia.org/wiki/B%27z_LIVE-GYM_2001_-ELEVEN-)」が最初の B'z ライブ参加体験だったような気がする。

2005 年に社会人になってから、徐々に B'z を聴く機会が減っていった。プログラミングしながら B'z の曲を聴くと注意が散漫になった。B'z だけではなく、歌詞のある曲は集中力を削ぐので、だんだん環境音 (雨音) やボーカルレスの曲を好むようになった。

2011 年にバンクーバー (カナダ) に引っ越したタイミングで、ファンクラブ会員ではなくなった。会報誌を受け取れなくなるからだ。この頃はジョギングが趣味であったので、ジョギング時に B'z を聴いていた。「B'z」と「走ること」は相性が良かった。なお 2012 年にバンクーバーで「B’z LIVE-GYM 2012 -Into Free-」があった際には地元民として参加した。狭い会場で B'z を間近に見れて感動した。

2015 年に帰国した後は、あまり B'z を聴いていない。というか、音楽をほぼ聴いていない。膝を痛めて走れなくなってしまったため、ジョギングしながら B'z を聴くこともなくなった。プログラミング (= 仕事) しながら聴く音楽といえば、環境音や lo-fi 系のものばかりだ。移動時にはポッドキャストかオーディオブックを視聴している。残念ながら B'z の入り込む隙間がほぼない。

とはいえ、ファンクラブ会員には復帰した。新曲がリリースされると、曲を口ずさめるようになる程度には聴いている。「B'z のライブに行きたいから」だ。そんなわけで、今でもツアーには参加している。先日も「B'z LIVE-GYM 2022 -Highway X-」に参加してきた。

B'z はライブがいいな、と思う。ライブに行くために曲を聴く、という感じだ。B'z の二人は僕よりだいぶ年上で、彼らが往年の名曲から最新の曲までカッコよく元気に演奏してくれる様を鑑賞するのがたまらない。自分もかくありたい、という気持ちにさせられる。

一歩ひいて考えると、僕は「生涯現役」的なものに惹かれているんだろうな、と思う。たとえば僕は野球選手ではイチローが好きだけど、その理由のひとつは彼が長く現役選手でいてくれたからだ。彼は 45 才までメジャーリーグで活躍した。日米で 28 年間の選手生活だ。すばらしい。

反対に、名指しは避けるけど、過去に解散したバンドが「再結成」してしょぼい演奏をしたりすると、とてもがっかりする。現役を続けて、続けて、続けた先にあるものを見せてほしい、という気持ちが自分は強い。

そういう気持ちから、B'z のライブには今後とも参加したいと思う。これを書いている時点で B'z の稲葉浩志は 58 才で、松本孝弘は 62 才だ。あと 10 年は元気でやっていてほしい。68 才 と 72 才のユニットが変わらずにカッコよく居続けてくれたら、ファンとしては幸せなことだと思う。


B'z ファン歴


先日 VMware Tanzu Labs の東京オフィスが運営する [Product Run に記事を公開しました](https://medium.com/product-run/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-tanzu-labs-%E3%81%AE%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E4%BD%93%E9%A8%93-ca0599856234)。久しぶりに企業ブログへ寄稿しました。

今でもアクセス可能な、僕が寄稿した企業ブログの一覧をメモしておこうと思います。

* 2023年03月 - [ソフトウェアエンジニア @ Tanzu Labs のオンボーディング体験](https://medium.com/product-run/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-tanzu-labs-%E3%81%AE%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E4%BD%93%E9%A8%93-ca0599856234)
* 2018年05月 - [社内勉強会 @ スマートニュース with 寿司](https://developer.smartnews.com/blog/2018/05/internal-meetups-at-smartnews/)
* 2010年06月 - [重たい処理を華麗にスルーして、アプリケーションの体感速度をぐっと向上させる方法](http://tech.voyagegroup.com/archives/495474.html)

これとは別に、自分の仕事が記事になったものは次の通りです (なお、たまたま自分がしゃべっただけで、成果そのものはチームメイトと一緒に作り上げたものです。言うまでもないことだけど)。

* [スマートニュース、動画チャンネルでのMLサービス活用を語る](https://weekly.ascii.jp/elem/000/001/799/1799136/)
* [【後編】６社の事例から学ぶ──ユーザー体験を磨き、サービスを支える技術力とは？](https://techplay.jp/column/988)

また、AWS Summit Tokyo で話した内容を動画にしてもらっています。

* [アカツキ、スマートニュースがご紹介！AWS運用を支えるエンタープライズサポート活用事例 | AWS Summit Tokyo 2019](https://www.youtube.com/watch?v=vtv3fPJaXvo)


過去に記事を書いた企業ブログ（など）


最近は多くのソフトウェアエンジニアが Zenn に記事を書いているようです。[僕も使い心地を試す目的で Zenn を使ってみることにしました](https://zenn.dev/mahata)。技術的でない記事は、引き続きこのドメインでホストしようと思っています。


Zenn に技術ブログを書く話


僕は小学生の頃とても太っていた。そして、肥満児は足が遅い。

足の遅い僕にとって、年次イベントのひとつである「マラソン大会」は気が滅入るものであった。マラソン大会は、男子児童が先にスタートして、5 分後に女子児童がスタートする、という感じで行われた。

僕は少し走ると脇腹が痛み出し、もともと欠けていたやる気も尽き、とぼとぼ歩きはじめた。皆に追い抜かれ、ついには女子児童にも追い抜かれはじめた。

このとき、女子児童の一人が僕を「歩くなー、がんばれー」と言いながら追い抜いていったことを、たまに思い出す。彼女だって、余裕綽々でマラソンをしていたわけではない。自身も顔を真赤にしながら息を切らしつつ声をかけてくれた。思い出すと、少し感動してしまう。

自分は「人に優しく接するためには、自分自身が元気であることが必要だ」と思っている。だから、なるべく元気でいようと思っている。でも、この子のように「自分がきつい状況にあっても、相手のことを考えられる」ことが真に目指すべき到達点なのかもしれない。


マラソン大会の思い出


『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第三章「Knowledge Sharing」を読んだ。以下は感想文である。

知識共有は重要だ。しかし **善意によって** 知識共有が妨げられることがあるというのは、面白いと思った。たとえば、エース級の人材が難しいタスクを「僕がやっておきます」と手を挙げるのは善意からの行動だ。しかし、知識がチームに根付かないという意味ではまずい行動である。

知識共有のためにドキュメントを書けばいいのだろうか。必ずしも、それが最善の手段ではない。[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)には「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」という節がある。それぞれをあわせて、僕は「**ドキュメントよりも、対話しながらソフトウェアを一緒に動かす**」ことが知識共有にはベストだと考えている。この「**一緒に動かす**」というのは、ペアプログラミングを通じて、である。つまり、エクストリーム・プログラミングが知識共有に最も効くのでは、ということだ。

この意見に反論があるとすれば、スケールメリットに関するものだろう。ドキュメントは一度書いたら何度も読んでもらえる。一方で、ペアプログラミングはペアにしか知識が伝播しない。とはいえ、ペアをローテーションすることもプラクティスに含まれる。ローテーションさせ続けることで必要な人に知識を行き渡らせることは難しくない。なんなら **ペアでドキュメントを書いても良い**。

本章では質問者の無知に対して「feigned surprise (驚いたふり)」をしてはならない、とある。心理的安全性を低めるからだ。スタックについて質問しても「えっ、スタックを知らないの?」と返されてしまうような環境では安心して質問をすることは難しい、という例が紹介されている。もし現職で「スタックを知らない」と同僚から言われたら「ふり」じゃなくて、普通にびっくりしちゃう気がするけど、言葉や態度には出さないように気をつけたい。

ところで、心理的安全性について、若かりし頃の苦い思い出がある。僕は 20 才頃は学習塾でアルバイトをしていた。中学生向けの理科の授業のとき、16 方位を教えるため、まず東西南北について話そうとした。僕が「こっちが北だとすると、反対側は何かな?」と生徒に聞いたら、その子が「東...かな?」と答えた。僕は驚いて「えっ!」と声をあげてしまった。東西南北を知らない中学生がいるなんて...というのは、当時の僕には驚きだった。

その後、彼を塾で見ることはなかった。退塾したとのことだ。

この件に関して苦情を受けたわけではない。彼の退塾の本当の理由はわからない。でも、僕自身はこのときの自分の態度を悔いている。たまに思い出して反省もしている。なんにせよ、僕が彼の心理的安全性を低めたことに変わりはないだろう。

さて、他に本章で面白かったことと言えば「質問をすることで、他の人も質問しやすくなる」という話だ。僕は場が静まり返っているときほど質問をする傾向がある。まさに他の人の質問しやすさのためである。こういう所作を本の中で肯定してもらえるのは嬉しく思う。


Software Engineering at Google: Chapter 3 - Knowledge Sharing


この記事は『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第二章「How To Work Well On Teams」を読んだ感想である。

(以下、本書の主張と自分の意見をあえて混ぜて書いている)

## コードを隠したくなる気持ちと、その悪影響

まだ [Google Code](https://code.google.com/) が稼働していたころ、機能要望には「コードを隠す手段」に関するものが多かった。「コードを見られる "不安" は根深い」と本章の著者は主張している。なお、著者の Brian Fitzpatrick さんは [Subversion](https://subversion.apache.org/) の作者の一人である。

Linus Torvalds や Guido Van Rossum などの偉大なプログラマーが「またたく間に、たった一人で世界を変えた」というのは誤解である。ソフトウェア開発はチームプレイだ。彼らでさえ、コミュニティの力がなければ、ここまで広く使われるソフトウェアは作れなかった。

本章には「多くのエンジニアは "天才" と思われたい」とある。そして「おそらく、あなたは天才ではない」とも書かれている。

コードを隠したい気持ちは、未完成の仕事を見られたくない気持ちと一緒だ。未完成の仕事を見られると、自分が天才ではないことがバレる。しかし「自分は正しい方向に進んでいるのか?」「同じようなことをしている人はいないのか?」という疑問は、仕事を衆目に晒さないと答えを得られない。

## 謙虚、尊敬、信頼

次の言葉は Richard Hamming さんのエッセイからの引用である。

> The moral is this: do not underestimate the power of playing the social game.
> 
> (抄訳: ソーシャルゲームの力を見くびらないことです)

彼は秘書に対して愛想よく振る舞う「努力」をしていた。のちに彼が仕事でトラブルを経験したとき、その秘書は身を粉にして彼を助けるべく動いてくれた。この人間関係の力学を「ソーシャルゲーム」と表現している。情けは人の為ならず、ということだ。

また、同氏による「カジュアルな服装のせいで重要人物だと認知してもらえない」エピソードも紹介されている。ソーシャルゲームにおいて「外見」は重要である。ソーシャル「ゲーム」なのだから、ルール内で自分が有利になるような装備をすれば良い。

この「友好的に接することで、相手の協力を得られる」ことや「適切な格好をすることで、相手からの評価を得られる」ことを Richard さんは「システム」と呼んでいる。

> By realizing you have to use the system and studying how to get the system to do your work, you learn how to adapt the system to your desires. Or you can fight it steadily, as a small, undeclared war, for the whole of your life.
> 
> (抄訳: システムを使わなければならないことを自覚し、システムに仕事をさせる方法を研究して、システムを自分の要望に適合させる方法を学びましょう。そうしないと、一生をかけて些細な戦争を繰り返すことになります)

まったくその通りだ。

ところで、本章では [Team Geak](https://www.oreilly.co.jp/books/9784873116303/) にも登場する「Humility (謙虚), Respect (尊敬), Trust (信頼)」の 3 つの言葉が登場する。エンジニアリング文化の根幹である。

これをコードレビューに反映させるとどうなるか、という話は面白い。つまり「自分が正しくて、相手が悪い」という態度は謙虚ではないし、「(自分には無駄に思えるコードだけど) 相手はドメインに対する造詣が深いから、そう書いているのかもしれない」という態度は尊敬である。

そのような態度をコードレビューに反映すると、次のようなコメントになる。

> “Hey, I’m confused by the control flow in this section here. I wonder if the xyzzy code pattern might make this clearer and easier to maintain?”
> 
> (抄訳: ここの制御フローで混乱してしまいました。xyzzyのコードパターンを使えば、この部分がより明確になり、メンテナンスが楽になったりしないでしょうか?)

攻撃的ではないし、フィードバックも与えられている。`I'm confused ...` の辺りは「あなたのコードが読みづらい」ではなく「わたしの理解が追いつかない」という感じで謙虚さを感じる。

正しければ何を言っても構わない、という考え方もあるだろう。しかし、それはソーシャルゲームにおけるシステムを無視しており、損をしている。何より、そういう人とはチームメイトとして一緒に働きたくない。


Software Engineering at Google: Chapter 2 - How To Work Well On Teams


『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第一章「What Is Software Engineering」を読んだ感想をメモしていく。

## Hyrum's Law (ハイラムの法則)

この章では「[Hyrum's Law](https://www.hyrumslaw.com/)」という言葉が導入される。本書の後の方でも何度か言及されるキーワードである。「Hyrum...誰...??」と思ったけど、これは著者の Hyrum Wright さんのことのようだ。

本には次のように書かれている。

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
> 
> (抄訳) 十分な数の API 利用者がいれば、契約で約束した内容は重要ではありません。あなたのシステムで観測できる挙動はすべて、誰かに依存されることになります。

これはどういうことを言っているのだろうか。書籍ではハッシュコンテナを例に説明しているけど、もう少し具体的に Python で Hyrum's Law に該当する例を示してみよう。

かつて Python では dict オブジェクトのデータ挿入順は保持されなかった。しかし [バージョン 3.7 からは dict オブジェクトの挿入順序が保存される](https://docs.python.org/ja/3/whatsnew/3.7.html)。それでは、`dict` がデータの挿入順を保持することに依存するコードを書いて良いのかというと、そうとは言い切れない。未来のバージョンでは、この振る舞いが変わる可能性もある。

そして「**システムで観測できる挙動はすべて、誰かに依存される**」というのは、過去の Python では dict を疑似ランダマイザーとして使うプログラマーがいた、という意味だ。**たまたま** 未定義の振る舞いを観測したプログラマーが、それに依存したコードを書いてしまうのである。

プログラミング言語の未定義な振る舞いを活用したプログラムは「賢い」プログラムである。しかし、このような「賢さ」はソフトウェアエンジニアリングの文脈では褒められるものではない、とある。

## Trade-offs and Costs (トレードオフとコスト)

組織の健全性はキャッシュフローだけの問題ではない。次の一節は素晴らしい話だと思った。

> Efficiency gains from keeping engineers happy, focused, and engaged can easily dominate other factors, simply because focus and productivity are so variable, and a 10-to-20% difference is easy to imagine.
> 
> (抄訳) エンジニアが幸せで、集中し、仕事に打ち込むことで得られる効率性は、他の要因を圧倒します。なぜなら、集中力と生産性は非常に変わりやすく、10～20%の差は簡単に想像できるからです。

組織がエンジニアの幸福に投資することは、福利厚生ではない。組織の成長のための戦略である。

「10~20% の差」という数字の根拠は特に書かれていなかったけど、少なく見積もってもその程度の差はあるだろう。



Software Engineering at Google: Chapter 1 - What Is Software Engineering


[IIJ Engineering Blog の「その証明書、安全ですか？」という記事](https://eng-blog.iij.ad.jp/archives/17668)を読んだ。小難しい話をユーモアをまじえて解説する、良い記事だと思った。

この記事の「事例3: KLAYswap」のところに次のように書かれている。

> この事例でハイジャックされたのはKLAYswap自体ではなく、KLAYswapが利用するJavaScriptのライブラリが置かれていた外部のサイトでした。KLAYswapにアクセスしたユーザは、偽の外部サイトから改竄されたJavaScriptファイルをダウンロードし、それを実行して仮想通貨を奪われました。
 
これは個人的には古傷をえぐられる事例で、過去にコードレビューで「みだりに外部ドメインのリソースを読むべきではなく、可能な限り自分たちで管理できるドメインにリソースを移動して使うべきである」と主張したものの「考えすぎだ」と却下されたことがある。僕の言葉遣いがいたらなかったのかもしれないし、いわゆる信頼残高が足りなかったのかもしれない。しかし、具体的にそういう事例を例示できれば説得力も増すものだし、記憶に留めておこうと思った。


外部ドメインでホストされているリソースをみだりに読み込むべきではないという話


この記事は Dropbox で Principal Engineer をされていた James Cowling さんによる [Don’t lead by example](https://blogs.dropbox.com/tech/2019/02/dont-lead-by-example/) というページの翻訳です。この記事が最初にリリースされたとき、強く感銘を受けたことを覚えています。ふと個人的なメモを漁っていたところ、この記事を過去に翻訳したことを思い出し、ここで公開しようと思いました。

## "お手本になる" ことでリードしてはならない

はじめて Dropbox でテックリードの役職についたとき、ふたつの手強い仕事を請け負うことになりました。

1. 数エクサバイトの分散ストレージシステムを作り、S3 にあるデータを置き換えること。しかも、厳しいリソースとタイトなスケジュールの中で。
2. テックリードというよくわからない仕事を理解すること。

後者の方は想像よりもずっと難しいことでした。

チームが少ない内はなんでもうまくいきますが、成長とともに痛みがはじまります。チームメンバーが、するべき汚れ仕事をきちんとしているように思えませんでした。いつも少数の決まったメンバーが緊急事態に対応し、アラートを受け取り、ダッシュボードを修正し、サービスを継続させているように思えたのです。わたし自身もその「少数のメンバー」のひとりであり、イラつきはじめていました。この事態に対して "どう対処すべきか模範となって示そう" と考えました。

わたしは一層がんばって、チームのお手本になろうとしました。どのアラートにも即座に対応し、メールに誰よりも速く返信し、チャットで流れてくる質問にも頻繁に答えました。一日に16時間も働き、チームのオンボーディングに四苦八苦しましたが、いささか度を越していました。この後に何が起こったか、ご想像がつくでしょう。

わたしが首を突っ込むほど他のメンバーは萎縮し、わたしの方が問題を簡単に解決できるのではないかと思うようになりました。メンバーはマイクロマネージされていると感じ、自信をなくしました。メンバーが「彼は一日中働くのが好きなのかも」と思うほど、わたしは「みんながついてきてくれない」と悩むようになりました。わたしが努力するほどにチームメンバーは不幸せになり、わたしは燃え尽き、仕事の進捗も悪くなりました。より経験のあるテックリードに **「お手本になることでリードするのは止めよう」** と言われるまで、これは続きました。

この言葉の意味を理解するには、しばらくの時間が必要でした。

### リーダーシップには適切な期待値の設定が必要である

「何がよい振る舞いなのか」を規定することは必要だけど、お手本になることでリードをするのはうまいやり方ではないし、受動的攻撃行動 *(passive-aggressive)* だとも言えます。よいリーダーは分かりやすくコミュニケーションし、適切な期待値を設定し、チームメンバーが能動的に動けるように指導します。ぐっとこらえて、ロールにしたがいましょう。

とりわけ重要なのは、チーム内でオンコールのメンバーに対する期待値と責任範囲を明確に話しておくことです。最初は億劫に思えましたが、チームメンバーは期待値設定を明確にすることに好感を持ちました。わたしは少し冷静になることを求められました。メールに即座に反応する必要はないし、いつも大問題が起こっているわけではないのです。期待値を明文化することで、何が価値のある仕事で、何がマイクロマネジメントなのかを考えさせられるようになりました。

期待値設定はアカウンタビリティの概念とよく合います。つまり、人々を期待に応えるように導けるのです。これは大きなトピックで、これだけでブログ記事をひとつ書けるほどです。重要なことは、優秀なエンジニアは監視ではなくアカウンタビリティのある場所でもっとも能力を発揮するということです。人々が期待に応えたくなるよう仕向けるために必要なものは何でしょうか?

ずばり、期待値を設定することです。

### 誰もが等しく汚れ仕事をする

素晴らしい。期待値を設定することで、全員の気持ちが "引き上げられ" ましたね。それではふかふかの椅子にゆったりと座って、チームが機能するところをじっくり眺めましょうか。...おっと、それはよくない。さあ、よそ行きの服を脱ぎ捨てて現場に戻りましょう。

モダンな技術者は控えめに言っても反権威主義です。あなたがテックリードというロールを「ボスとして振る舞うこと」だと考えているのであれば、チームからの信用を即座に失うことでしょう。

期待値設定はテックリードの仕事のひとつですが、あなた自身もチームメンバーのひとりであることを忘れてはいけません。あなたも現場で実際の仕事をする必要があるのです。現場でチームメンバーと仕事をすることが品質を高めることにつながり、システムを理解し、チームメンバーの気持ちを理解し、チームが目的を達成するための助けになります。あなたはチームでもっともハードワーキングなメンバーとなるでしょう。おめでとう。テックリードの世界へようこそ。

### まとめ

"お手本になる" ことでリードしてもうまくいきません。「何がよい振る舞いなのか」を規定することは重要ですが、強いリーダーシップには不十分です。テックリードとして振る舞うというのは、明確な期待値の設定をし、忌憚ないコミュニケーションを重視することです。ただし、思い上がってはいけません。あなたはチームメンバーであって、ボスではないのです。


Don't Lead by example の日本語訳


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第五章では、Java などのプログラミング言語における `final` キーワードを TypeScript で実現するアイディアについて紹介されている。面白いと思った。

Java の `final` は色々なところに書けるが、ここではクラスに対する `final` について考える。クラスに対して `final` をつけると、そのクラスは継承できなくなる。

TypeScript で継承不可能なクラスを定義するにはどうすれば良いだろう? [コンストラクタを `private` にすれば継承は不可能になる](https://www.typescriptlang.org/play?#code/MYGwhgzhAECyYFsFhNA3gKGtADgJwEsA3MAFwFNpgB7AOwlLwFdhTq8AKASnQF8N+GUJBgARagHNo5AB4VaAExjwkKPhiF0G0BZOgBeaLXIB3aOIncMQA)。

```typescript
class Mammal {
  private constructor() {}
}

class Dog extends Mammal {}

const dog = new Dog()
```

このとき `class Dog extends Mammal {}` に対するエラーメッセージは `Cannot extend a class 'Mammal'. Class constructor is marked as private.(2675)` である。また `const dog = new Dog()` については `Constructor of class 'Mammal' is private and only accessible within the class declaration.(2673)` と言われる。エラーメッセージがすべてを言い表している。

ところで Java の `final` は継承を禁止するだけで `final` のついたクラスのインスタンス化を禁止するものではない。この修飾子をエミュレートするのであれば `const dog = new Dog()` 相当のものは許したい。`private` なコンストラクタを外から呼べない、という制約があるので `Mammal` クラスの中でインスタンスを作れば良いだろう。[具体的には次のようにする](https://www.typescriptlang.org/ja/play?#code/MYGwhgzhAECyYFsFhNA3gKGtADgJwEsA3MAFwFNpgB7AOwlLwFdhTq8AKASnQF8toDMgWBU85MuW7oB2caSZ5a0WuQDucRMhDcB-fhhr1S0ZEhTQAvJvMgAdMHGTdQA)。

```typescript
class Mammal {
  private constructor() {}
  static create() {
    return new Mammal()
  }
}

const mammal = Mammal.create()
```

これで Mammal は継承不可であり、そのインスタンスは `Mammal.create()` によって得られるようになった。





『プログラミングTypeScript』 第四章 - final 修飾子のエミュレート


[2022 年の振り返り記事](/posts/2022-12-23-retrospective)で Twitter 離れしたことを書いた。

> ソーシャルメディアに対する熱はだいぶ冷めてしまっており、Twitter にもぽつぽつとしか投稿していなかったところ、イーロン・マスクにより Twitter が買収された。買収に関する見方は様々あると思うけど、ニュースや (元) 社員 のツイートを読む限り、僕はネガティブなイベントだと捉えており、Twitter からは距離を置きたいと思うようになった。

今なお Twitter に対する不信感は募る一方だけど、Twitter から離れたことによる弊害も感じるようになった。何かというと、技術的なトレンドを把握する方法を失った、ということである。Twitter で僕がフォローしていた人たちの多くはギークであり、彼らが発信するものを追うだけでトレンドがわかった。

Twitter を使わずに同じ体験をするために RSS リーダーを使うことにした。**2023 年に、RSS リーダー、だ**。僕と同世代の人であれば、Livedoor Reader や Google Reader などの優れた RSS リーダーが 2010 年代にサービス終了したことを覚えているだろう。外野からは想像しかできないけど、それらの RSS リーダーを追いやったものこそが Twitter などのソーシャルメディアだと思う。

この仮定が正しければ、Twitter から離れた今こそ RSS リーダーで情報収集をするべきではないか。そう思い、今は [Feedly](https://feedly.com/) を試している。Feedly を一日に数回開くことで、技術トレンドはそれなりに追えている。Twitter がフォローする人次第で体験が変わるように、Feedly も登録する RSS フィードでだいぶ体験が変わる。Feedly に好きなブロガーやニュースサイトの RSS フィードを登録すると、似たフィードをレコメンドしてくれるので、満足できる記事が出ている。

ところで、小ネタとして [Feedly Background Tab](https://chrome.google.com/webstore/detail/feedly-background-tab/gjlijkhcebalcchkhgaiflaooghmoegk) という Chrome Extension を推したい。これをインストールすると `;` で Feedly を離れずに URL を新規タブで開ける。`j` と `k` でフィードをスクロールしながら `;` でタブをどんどん開き、最後にタブをまとめて消化する、というスタイルで記事を読める。

もし願いが叶うのであれば、僕の友人にはブログ記事 **も** 書いてほしい。Twitter 上で仲良くさせてもらっていた方々のブログは Feedly に登録しているので、彼らのテキストが Feedly から流れてくれば、とても嬉しい 🤗


RSS リーダーへの回帰


[2022 年の振り返り記事](/posts/2022-12-23-retrospective)でマークダウンエディタとして [MarkText](https://marktext.app/) を使っていると書いた。

> MarkText は手元で (ほぼ) 処理が完結するので、さくさく動いて今のところ重宝している。実は細かな挙動で不満があるにはあるけど、我慢できる範囲である。

ところが、ここに来て「細かな挙動による不満」が溜まってしまい、MarkText を使うのをやめた。具体的にはリストを書いているときに Emacs キーバインドが効かなかったり、URL をコピペしたときにタイトルを展開する挙動が一貫していない (...ように見える) ことである。ひどいときには undo と redo の挙動が変 (...に見える) ときもあった。たとえば undo を数回くりかえした後で redo してもテキストを元の状態に戻せない、など。

自分で問題解決を試みようかとも思ったけど、そもそもビルドが手元の環境ですんなりできず、ここで頑張るくらいなら何かに乗り換えようという気持ちになってしまった。

乗り換え先だけど、単に IntelliJ でマークダウンファイルを編集するので十分だと気づいてしまった。きれいな WYSIWYG 機能はないけど、リアルタイムプレビューは可能だし、IntelliJ のファイル編集機能は手に馴染んだものである。

![IntelliJ での初稿のプレビュー](/images/20230119-markdown-to-intellij.png)

テキストファイルをいじるのに専用のソフトウェアは不要である。オーバーエンジニアリングしない。そういう気持ちをあらたにした。


MarkText から IntelliJ への移行


GitHub プロジェクトにスターをつけるとき、だいたいはブックマーク目的である。しかし、この運用には根本的な問題がある。スターをつけたプロジェクトを忘れてしまうのだ。

そこで、[スターをつけたプロジェクトを取得してきてランダムに Slack に通知するプログラムを書いた](https://gist.github.com/mahata/88ec9f7d4ca7eed9f9c6aa9e2147ee1c)。これを動かすと、次のようなメッセージが Slack に投稿される。

![GitHub にスターをつけたリポジトリ](/images/20230118-github-stars.png)

先日、[GitHub Actions を cron サーバーとして運用する話](/posts/2023-01-17-github-actions-as-a-cron-server)を書いた。これと同じように、GitHub Actions にスターをつけたプロジェクトを定期的に Slack に投稿してもらい、記憶を掘り起こしてもらうようにした。


GitHub でスターをつけたプロジェクトを定期的にリマインドする話


何かの処理を定期的に実行したい、そんなこともあるでしょう。プログラマであれば。

[過去には `Launchd` で MacBook から定期的に Slack メッセージをポストしたりしていた](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)。これには概ね満足していたけど、いくつか気になる点もあった。

1. 手元の MacBook で `Launchd` が動いているため、マシンを落としていると処理を実行できない
2. 複数の MacBook があると、どこの `Launchd` に何を設定したか管理しづらい

これを克服するため GitHub Actions を cron サーバーのように運用することにした。

[GitHub Actions は `on.schedule.cron` で起動タイミングを設定できる](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)。この機能を使い、任意のタイミングで任意のコマンドを実行できる。GitHub Actions は (障害が起きていない限り) 常に利用可能なので、MacBook の `Launchd` より高い可用性を期待できる。

ひとつ設定時にはまったのは、GitHub Actions の最短の実行間隔が 5 分だということだ。ドキュメントにはこう書かれている。

> The shortest interval you can run scheduled workflows is once every 5 minutes.

つまり `cron: '*/2 * * * *'` のようには書けない。僕は試行錯誤のために毎分 GitHub Actions をトリガーしようと思ったが、うまくアクションが動かずに「あれーなんでだろう...」となってしまった。


定期的な処理を GitHub Actions で行う話


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第四章の練習問題に次のようなものがある。

> 5. 型安全なアサーション関数、isを実装してください。型で概略を記述することから始めます。これは、完成したら、次のように使えるものです。
>
>   ```typescript
>   // stringとstringを比較します
>   is('string', 'otherstring') // false
>   
>   // booleanとbooleanを比較します
>   is(true, false) // false
>   
>   // numberとnumberを比較します
>   is(42, 42) // true
>   
>   // 異なる型同士を比較すると、コンパイル時エラーになります
>   is(10, 'foo') // エラー TS2345: 型 '"foo"' の引数を型 'number' の
>                 // パラメーターに割り当てることはできません。
>   ```

よしよし、そんなに難しくはなさそうだ。この章の後半で出てきたジェネリック型を使えばできるのだろう。こうかな?

```typescript
function is<T>(first: T, second: T) {
  return first === second;
}
```

[動いているようだな](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIoCmECAJmRgJSIDeAUIogTVCAJJ8RKIgC8k6nUYBuTgF9OnemBRwANjQB0GuAHMcqHAHJiBGGH0mqJuFAAWNURasmWLWYgD03xMABDDVoVBHUtXQMjFBwoAhAaKkDgmg8vX38gkNVwnT1DYwAWACYqErSfPziEzgzjAEYABltgODh3SsRACoZAS4ZAH4ZyAGVigGZCgFYyQGj1RBMAIla4OZNEQDsGQFR9QAdTQCSGGZMwEABbACNnFdXARYYewEOGPsB+hj7AawZAJyVAKIZAZX1AMwZAaIZAZQZACwZAPYMgHMGQCyDIA-BkA2gyAZIZAEAMnCAA)。おっ、この問題には続きがあるようだ...

```typescript
// ［難問］任意の数の引数を渡せるようにします
is([1], [1, 2], [1, 2, 3]); // false
```

ふむふむ、何個の引数が渡されるかわからないのであれば、レストパラメーターを使えばいけるだろう。俺は詳しいんだ。

```typescript
function is<T>(first: T, ...rest: T[]) {
  return rest.every(_ => _ === first);
}
```

うんうん、[これも期待通りに動くな](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIB0tBApsWRgNoC6AlIgN4BQiiBlBAEkDYtXoA3egQCeOAPqIAvFkTKVWxPiJQOAbl4BfXrwgIUcADb1q1uAHMcqHAHJiBGGEduqbuCgAC1lPb18OQ0QAemidAENrFHpzSxs7B2dXKAIQeipgROTIgxi4wqSUizArW3snFxQcABYAJio2krLEHLzeWOQmgEYABn9gODg3LgHACoZAS4ZAH4ZyAGVWgGZmgFYyQGj1RDcAIgm4Q7dEQDsGQFR9QAdTQCSGfbcwEABbACNZc4vARYZ5wEOGRaAfoZFoBrBkATkqAKIZAMr6gDMGQDRDIBlBkAFgyAewZAOYMgFkGQB+DIBtBkAyQyAIAZUjV0vUsk0WEM2FRKVRWtTELTEO1EOtOFEBhVkkA)。ここで本の解答を眺めると...あれ、ちょっと僕の書いたものとは違う。

```typescript
function is<T>(first: T, ...rest: [T, ...T[]]): boolean {
  return rest.every(_ => _ === first)
}
```

...あっ、なるほど。もとの `...rest: T[]` だと `is('foo')` のような入力も許されてしまうのか...これは失態だ。`rest` が少なくともひとつの要素をもつことを保証するためには `...rest: [T, ...T[]]` [のように書く必要がある](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABDAzgHgCoD4AUwYBOKUAXIhgDSIB0tBApsWQNqU20bMC6XAlGQCM4cADb0AhkgDeAKESIGUEASQNi1egDd6BAJ44A+ogC8WREeOXE+IlF4yAvjJkQEKUfWoi4AcxyocAHJiAhgwH0CqQLgoAAsdELCI3l4AbkQAegzrcREUehc3Dy9ffxQcKAIQeipgXPyU9KycvILXMHcxEr8AgBYAJioBxszsyuqZZoCARgAGKOBhQN5RxEAKhkBLhkAfhnIAZX6AZl6AVjJAaPVEQIAiRbgrwMRAOwZAVH1AB1NAJIYLwLAQAFsBHQPR6ARYYNoBDhi2gH6GLaAawZAE5KgCiGQDK+oAzBkA0QyAZQZABYMgHsGQDmDIBZBkAfgyAbQZAMkMgCAGQodYreHrlZjTLhURlUfrMxCsxCDRAHPhpVZ1VqTbIBQK3ZarACiAA8AA70aD0AAmiHEUEQYnExG5aoIPj+9DAUBQVAEIA1PhiiGm1BkQA)。

こういうケースには自分で気づけないといけないな。


『プログラミングTypeScript』 第四章 - is メソッドの実装


『[プログラミングTypeScript](https://www.oreilly.co.jp/books/9784873119045/)』の第四章ではジェネレーターおよびイテレーターに関するセクションがある。そこではフィボナッチ数を生成するジェネレーターを返す関数 (ジェネレーター関数) が例示されている。

本記事では「素数を生成するジェネレーター」を返す関数を書いてみよう。素数は無限に存在するので、**次の**素数を返せるというのはジェネレーターの用途として適切だろう。

[全体のコードは次の通り](https://www.typescriptlang.org/ja/play?#code/GYVwdgxgLglg9mABAKggJwKYEMoYApowC2GA4hmBmjnGgBQCUiA3gFCKIQIDOUiADoRLdEAXkSUA7ogDKGKAB4wIIgCMqAPkat2iADbzOINJjB9xAJl2SAFjAOI6UNCAxM2HDrfsZHz1+66nvqGMNwExL7i-hhBnsC0jlxgvAJCvnDAaZHcgcHBMFl0EMamfACk2SRiouIADHn5BeHpYojAWHrcsU3BqphYANZxwQC+I4jjE4WOAIRhESSNTSUmFFAA1BsA3BMcybDKPflTTYI5AHRYACbXxaXrDBP92MNjOsEAnjAYetdGazMW104ymyVS5xI5Eo1CgiXE6GwuEWZAoVBo9CeCTQjgMfBgbTq20QBIUiAAjHUiSSto1wXADBc9HAAOZ0SGomEYi6UAAeUEYT3GQA)。

```typescript
function *createPrimeGenerator() {
  const primes = new Set<number>()

  let current = 2
  while (true) {
    while (true) {
      let isPrime = true
      for (const prime of primes) {
        if (current % prime === 0) {
          isPrime = false
          break
        }
      }

      if (!isPrime) {
        current++
        continue
      }

      primes.add(current)
      break
    }

    yield current++
  }
}

const primeGenerator = createPrimeGenerator()
for (let i = 0; i < 100; i++) {
  console.log(primeGenerator.next())
}
```

関数名の前に `*` をつけることでジェネレーター関数を定義できる。ジェネレーター関数はジェネレーター (`Generator`) を返し、その値は `yield` キーワードで生成される。利用者は `next()` をコールすることでジェネレーターに次の値を要求できる。

## ジェネレーターとイテレーター

`createPrimeGenerator()` が返す値はジェネレーターだが、イテレーターでもある。もっと言えば、反復可能なイテレーターでもある。

『プログラミングTypeScript』から「反復可能オブジェクト」と「イテレーター」の定義を引用しよう。

> **反復可能オブジェクト**: `Symbol.iterator` と呼ばれるプロパティを含んでいるオブジェクト。このプロパティの値は、イテレーターを返す関数。
>
> **イテレーター**: `next` と呼ばれるメソッドを定義しているオブジェクト。この `next` メソッドは `value` および `done` というプロパティを持つオブジェクトを返す。

ここで IDE (IntelliJ IDEA) は先ほどの例での `primeGenerator.` の補完を次のように表示してくる。

![IntelliJ IDEA が表示するジェネレーターの補完候補](/images/20230113-iterator.png)

`System.iterator` と `next` の両方を持つことがわかる。したがって、これは反復可能なイテレーターだと言える。


『プログラミングTypeScript』 第四章 - ジェネレーターとイテレーター


[前回](/posts/2023-01-10-sadservers1-saint-john)に続いて SadServers の ["Saskatoon": counting IPs.](https://sadservers.com/newserver/saskatoon#) を解いてみよう。概要は次の通りだ。

`/home/admin/access.log` に Web サーバーのアクセスログがあり、1 行が 1 リクエストに相当する。ログの先頭はリクエスト元の IP アドレスであり、アクセスログの中で最も多くのリクエストを発行している IP アドレスを特定したい。当該 IP アドレスは `/home/admin/highestip.txt` に保存するものとする。

まずはログファイルの中から IP アドレスを抽出しよう。僕なら次のようにする。

```
$ cat /home/admin/access.log | cut -d ' ' -f 1
```

`cut` に渡している `-d` と `-f` は、それぞれ「区切り文字」と「何カラム目が欲しいか」を指定するオプションである。これを実行すると次のような結果が得られる。

```
$ cat /home/admin/access.log | cut -d ' ' -f 1
83.149.9.216
83.149.9.216
83.149.9.216
...
```

これをソートするために `| sort` でつなげよう。さらに `| uniq -c` でつなげると重複行を数えてくれる。ここまでパイプでつなげると、結果が次のようになる。

```
$ cat /home/admin/access.log | cut -d ' ' -f 1 | sort | uniq -c
      6 1.22.35.226
      6 100.2.4.116
     84 100.43.83.137
...
```

問われているのは「最も多くのリクエストを送信している IP アドレス」なので、ここで結果を `sort` し直して最後の結果だけを取得すればよい。したがって `| sort | tail -n 1` を追加する。

```
$ cat /home/admin/access.log | cut -d ' ' -f 1 | sort | uniq -c | sort | tail -n 1
    482 66.249.73.135
```

ここまで来たら後は前後の空白をトリムした上で IP アドレスが表示される 2 カラム目を取得すればよい。

```
$ cat /home/admin/access.log | cut -d ' ' -f 1 | sort | uniq -c | sort | tail -n 1 | sed 's/^ *\| *$//' | cut -d ' ' -f 2 > /home/admin/highestip.txt
```

`| sed 's/^ *| *$//'` は行頭から始まる空白 **もしくは** 行末まで続く空白を除去する。

この内容で正答としてジャッジされる。

## 補足

次のような書き方でも問題ない。

- `cut -d ' ' -f 1` のようにする代わりに `awk '{print $1}'` として 1 カラム目を取得する

- `| sort | tail -n 1` のようにする代わりに `| sort -r | head -n 1`として `sort` 後にもっとも後ろに来る行を取得する


SadServers - "Saskatoon" の解説


[こちらの記事の内容は Zenn に移しました](https://zenn.dev/mahata/articles/f3b758c96fe698) (この記事そのものも、後で消すかもしれないです)。


SadServers - "Saint John" の解説


いかにもナルシストっぽい発言だけど、僕は自分の過去のブログ記事を読み返すのが好きだ。[以前もそのような趣旨の記事を書いたことがある](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)。

今までは、この自作ブログには `sitemap.xml` が存在しなかったので、先の記事のように定期的にランダムな記事を取得して Slack にポストすることができなかった。

少しずつ記事も増えてきたので、このブログでも `sitemap.xml` を生成するようにした。

この `sitemap.xml` の生成は [sitemap という npm モジュール](https://www.npmjs.com/package/sitemap)で半自動的に生成している。具体的には次のようにする。

```sh
$ ls posts | xargs -I {} echo "https://mahata.vercel.app/posts/{}" | sed 's/\.md$//' > urls.txt
$ npx sitemap < urls.txt > public/sitemap.xml
```

ブログ記事ファイルが `posts/` に存在するとき、上記のコマンドで `public/sitemap.xml` を生成できる。

最後にこれと同等の内容を Vercel の `Build Command` の設定に忍ばせた。これで Vercel に更新があるたびに最新の `sitemap.xml` が生成される。


ブログの読み返しが好きな話


最近、お酒を飲まなくなった。

妻が僕の飲酒を嫌うので、数年前から「仕事のつきあい」でしか飲まないようにしていた。しかし、昨今はコロナウイルスの流行のため「仕事のつきあい」そのものがなくなり、成り行き的に断酒することになった。

お酒を摂取しない生活は快適だ。夜に小難しい本を読めたり、集中を要するタスクをこなせたりするため、今では積極的にお酒を飲まない習慣を守ろうと思っている。


お酒のない生活


単に「意識が変わってきた」という話なのだが、最近はアウトプットを意識してインプットをするようにしている。たとえば本を読むときは、ブログに感想を書く前提で読んでいる。

このようなインプットは、かつては意識的に避けていた。森博嗣さんの『[自由をつくる 自在に生きる](https://shinsho.shueisha.co.jp/kikan/0520-c/)』には「後で感想をまとめる」という意識で読書をするのは「自由ではない」という旨の記述があったように思う。手元に書籍がないのでうろ覚えなんだけど...。これは、感想を書くという意識があることで、引用しやすい部分を求めてしまったり、キャッチーな言葉を追ってしまうので、自由な読書とは程遠いという主張であった...はず。この本は一貫して「自由とはなにか」というのを問いかける内容なので、この読書のくだりは単なる一例なのだが、自分にも少し影響を与えていると思う。

しかし、今の自分には時間が足りない。自由な読書を楽しむよりは、単位時間あたりの学習効率を高めたい。そういう気持ちの変化が、アウトプットを意識してインプット効率をを上げたいというモチベーションにつながっているのだと思う。


アウトプットのためのインプット


[去年に続き](https://mahata.gitlab.io/post/2021-12-25-retrospective/)、今年の出来事を振り返ってみようと思う。

## 読んだ本

### 技術書

今年の前半は図書館やオンライン書店で評判のよい本を選んで読んでいた。具体的には次のような本を読んだ。

* [第2版 ゼロからはじめるデータベース操作](https://www.shoeisha.co.jp/book/detail/9784798144450) ([感想ブログ記事](https://mahata.gitlab.io/post/2022-05-16-zerokara-hajimeru-database/))
* [テスト駆動開発](https://www.ohmsha.co.jp/book/9784274217883/)
* [エクストリームプログラミング](https://www.ohmsha.co.jp/book/9784274217623/) ([感想ブログ記事](https://mahata.gitlab.io/post/2022-06-10-extreme-programming/))

今年の中旬に転職した後は、転職先の福利厚生の一環で [O'Reilly Learning Platform](https://www.oreilly.com/online-learning/) のアカウントを取得できたので、O'Reilly の本や動画ばかりを眺めていた。

O'Reilly Learning Platform ではコンテンツの消化率がパーセントで表示される。50% 以上の消化率であったコンテンツは次の通りである。

* [A Beginner's Guide to Creating iPhone Apps for iOS 15 Using Swift UI](https://learning.oreilly.com/videos/a-beginners-guide/9781803241111/)
* [CSS for Everybody: From Beginner to Boss](https://learning.oreilly.com/videos/css-for-everybody/9781801071949/)
* [Spring and Spring Boot Fundamentals, 3E](https://learning.oreilly.com/videos/spring-and-spring/0636920620938/)
* [Certified Kubernetes Security Specialist (CKS) Study Guide](https://learning.oreilly.com/library/view/certified-kubernetes-security/9781098132965/)

iOS や CSS は仕事で必要なので読んだ (観た)。Spring (Boot) や CKS は単に技術的な興味で読んだ。

### 漫画本

今は娯楽といえば漫画本を読むくらいしかしていない。かつてはゲームをプレイしたり、スポーツ観戦したり、小説やノンフィクションを読んだりしていたけど、それらを楽しむための空き時間が今はない。なので、ふとした空き時間で楽しめる漫画本がほぼ唯一の娯楽である。

だいたいの場合は出版社のアプリで漫画を読んでいる (たとえば「[ゼブラック](https://apps.apple.com/jp/app/id1487411615)」や「[サンデーうぇぶり](https://apps.apple.com/jp/app/id1252920795)」)。気に入ったものは Kindle でも購入することがある。

2022年に読んで面白かったのは次のタイトルである (2022 年に連載されていたものとは限らない)。

* ザ・ファブル
* 進撃の巨人
* 嘘喰い
* キングダム
* スナックバス江
* Hunter x Hunter
* 葬送のフリーレン

「流行っているものが好き」という感じのリストになってしまった...。流行っているものには理由があるんだなあという感想。

## 買い物

2022 年に購入したもので「買ってよかったなあ」と思うものと、その理由を挙げてみる。[僕は広告が好きではない](https://mahata.wordpress.com/2018/06/07/%E3%80%8C%E4%BF%A1%E9%A0%BC%E3%80%8D%E3%81%8C%E5%80%8B%E4%BA%BA%E3%81%AB%E5%B8%B0%E5%B1%9E%E3%81%99%E3%82%8B%E6%99%82%E4%BB%A3/)ので、各々のアイテムのアフィリエイトリンクを貼るのは避けておく (なお、各企業の商品紹介ページへのリンクは貼る (あれば))。

### [快適ガードマスク](http://www.hakugen-earth.co.jp/products/medical/mask-refreshing/)

これまでドラッグショップで手に入る最も安価なマスクを選んでいたけど、長時間つけていると内側が毛羽立ったり、耳の後ろが痛くなったりして不快であった。

快適ガードはパッケージに「毛羽立たない」と明示的に書いてあるだけあり、ずっとつけていてもごわごわしないし、ゴムも幅広で耳が傷まないので気に入っている。

### [FlexiSpot (スタンディングデスク)](https://flexispot.jp/eg1.html)

職場にスタンディングデスクがあり、僕は一日に何度もデスクの位置を昇降している。これに慣れた結果、家でもスタンディングデスクを導入したくなり FlexiSpot を購入した。僕が購入したのは EG1 というモデルである。

組み上げの最終工程で机をひっくり返す必要があり、そこだけ力が必要であったものの、組み上げた後は非常に快適に使えている。

僕が不在のときは、小さい子どもに触られたくないものを一時的に置く場所としても使われているようだ。この使い方は想定していなかった。

仕事中にずっと座っていると体がこるので、2023 年以降も FlexiSpot のお世話になると思う。

### [Povo 2.0 (携帯キャリア)](https://povo.jp/)

楽天モバイルユーザーであったけど、Povo 2.0 に移行した。

もともと 4G ネットワークでデータ通信をすることはほとんどなく、いざというときに電話を受けられたり SMS 認証が通せればよい、という立場であった。SMS 認証そのものをなるべく避けたい、というのはまた別なお話としてあるけれど。

そういう意味ではかつての「繋がりにくいけど無料」の楽天モバイルはありがたい存在であった。残念ながら今年の中旬に楽天モバイルが有料になってしまったため、代替となるサービスを探す必要があった。探してみたところ Povo 2.0 が同じようなサービスを無料で提供していたため、こちらに乗り換えた。

結果として手に入ったのは「繋がりやすいけど低速、そして無料」のネットワークである。僕のユースケースでは楽天モバイルより快適である。たとえば Suica アプリで残額をチャージするような、大したデータをやり取りしないようなことは Povo 2.0 の低速ネットワークでも何の問題もなくできる。

O'Reilly Learning Platform や YouTube Music であらかじめ視聴したいコンテンツをダウンロードしておくことで、コンテンツを楽しむという意味でも、何の問題もなく携帯電話を使えている。最高である。

### MacBook Pro (M1 チップ)

これは正確には「買ったもの」ではなく、会社から貸与されているものである。

前職では Touch Bar のついた Intel チップの MacBook Pro を使っていて、可も不可もないと思っていた。しかし、転職先で与えられた M1 チップの MacBook Pro を使うようになり、もう Intel チップの MacBook は使えないな、と思うようになった。

単純に「速い」というのが最も良いところだけど、その他にも熱がこもらないからファンが回らず、そのことが静音性や内蔵マイクのノイズの少なさにつながっていたり、様々な点で順当にグレードアップしている。キーボードは Touch Bar のない過去の MacBook Pro に近い仕様だが、むしろそれ良い。

M1 チップにまつわる悪評の中に、Docker を使うと遅いとか不安定だという話がある。個人的な経験では、きついワークロードを Docker コンテナの中で動かさない限り、そこまでつらくはないと思う。僕は Postgres や MinIO を Docker で起動して Spring Boot アプリの開発をしていたけど、特に何の問題もなく開発できた。

### AirPods Pro（第2世代）

AirPods Pro は初代も持っていて満足していたけど、日常的にリモート環境でペアプログラミングをしていると一日バッテリーが持たない。仕方がないのでもう 1 セット買おうと思い、第2世代の AirPods Pro を購入した。消極的な理由から購入した第2世代の AirPods Pro だが、想像以上に初代より進化していた。今は第2世代ばかり使っている。

[公式の情報](https://www.apple.com/jp/airpods-2nd-generation/specs/)では、バッテリーは通話だと連続で3時間まで保つと書かれている。そして 15 分充電すると、また 2 時間通話できる、としている。

これはリモートでのペアプログラミングに十分耐えられる水準だ。2 時間ペアプログラミングして 15 分休憩というリズムは現実のユースケースともぴったりマッチする。余談だが「ペアプログラミングは疲れるので、マメに休憩を取りましょう」というのは業界でも広く同意されているプラクティスである。たとえば [VMware Tanzu Labs の「5 Tips for Effective Remote Pair Programming While Working from Home」というブログ記事](https://tanzu.vmware.com/content/blog/5-tips-for-effective-remote-pair-programming-while-working-from-home)にも次のようにある。

> Do what you can to avoid distractions. Close or minimize other app windows, find a work-only workspace if you can, and take breaks often, to keep both parties energized.

第2世代の AirPods Pro はマイクの性能も向上していてありがたい。これもリモート環境でのペアプログラミングにはメリットが大きい。[iPhone Mania というブログに、初代と第2世代のマイク性能を比較した記事がある](https://iphone-mania.jp/news-492232/)ので、確認してみても面白いかもしれない。

## ソフトウェア

今年、試してみて気持ちよく使えたソフトウェアをいくつか挙げてみよう。

### Intellij IDEA Ultimate

前職では JavaScript/TypeScript を多く書いており、そのときは VSCode でコードを書いていた。転職後は Kotlin もそれなりに書くので、Kotlin の開発者が多数在籍する JetBrains 社の IntelliJ IDEA にスイッチすることにした。会社がライセンスを購入しているので、有償版の Ultimate エディションを使っている。IntelliJ の Kotlin サポートは流石にこなれている。やりたいことが直感的にぱぱっとできる感じだ。

実は前々職でも IntelliJ IDEA の Ultimate エディションを使用していて、そのときも便利だと思っていたけど、あらためてこれを使うと「VSCode にはもう戻れないな」という気持ちになる。

特に現職ではペアプログラミングが仕事の大半を占めるので [IntelliJ の Code With Me の機能](https://www.jetbrains.com/ja-jp/code-with-me/)が必須である。ペアプログラミングするとペアから IntelliJ の便利ショートカットや、あまり知られていない機能も教えてもらえるので、ますます手放せなくなっている。

### [MarkText](https://marktext.app/)

今年の中旬まで、技術メモは Dropbox Paper に書いていたけど MarkText にスイッチした。このブログ記事も、下書きは MarkText に書いている。

[Dropbox Paper の主な不満は、動作の遅さにある](https://twitter.com/mahata/status/1519502960656777217)。 MarkText は手元で (ほぼ) 処理が完結するので、さくさく動いて今のところ重宝している。実は細かな挙動で不満があるにはあるけど、我慢できる範囲である。

### Mastodon

ソーシャルメディアに対する熱はだいぶ冷めてしまっており、Twitter にもぽつぽつとしか投稿していなかったところ、イーロン・マスクにより Twitter が買収された。買収に関する見方は様々あると思うけど、ニュースや (元) 社員 のツイートを読む限り、僕はネガティブなイベントだと捉えており、Twitter からは距離を置きたいと思うようになった。

何が代替として優れているのかよくわからないながら、代替手段としておそらく最も選ばれているであろう Mastodon に[僕も移行した](https://mstdn.jp/@mahata)。Mastodon にも思うところはあるけど、今のところは便利に使えている。

## その他もろもろ

### 転職

上の方でも少し触れているけど、2022年7月に転職をした。今回は外資系の大企業に移った。この転職には、今のところ満足している。はじめて数万人規模の社員がいる環境に身を置いているけど、大企業病っぽさを感じない部署にいるのでモチベーション高く働けている。

転職先の雰囲気については、[別途ブログ記事にしている](/posts/2022-12-01-startup-like-big-tech)。

### 体づくり

2015 年にカナダから帰国した後、じわじわと体重が増加してきている。ならすと年に 1kg くらい増えている。今年はついに、定期健康診断時に「少し体重を落とした方が良いです」と医師に言われてしまった。その言葉を受けて、ダイエットをはじめた。2023 年中には帰国時と同じくらいの体重にしようと思っている。

しかし、単に体重を落とすという目標だとあまりモチベーションが湧かないので、並行して懸垂の練習をしている。実は懸垂を 1 回もできないのだが、近所の公園でぶら下がることからはじめている。2023 年には 2-3 回くらい自分自身を持ち上げられるようになりたい。

### 音声メディア

前述の通り O'Reilly Learning Platform のアカウントを取得したので、そこで聞ける Audiobook を通勤時間などに消費するようになった。

ただ、英語をずっと聴いていると疲れるので、日本語で頭を使わずに消費できるコンテンツがほしく、たまたま発見した[ドングリfm](https://donguri.fm)というポッドキャストもたまに聴いている。主にホストが雑談しているだけの番組だけど、ちょっと「ふふっ」となることが多く、癒やされている。

### イベント

コロナ禍で色々と控えているけど、さすがにいつまでも閉じこもっていられず、いくつかの外出イベントをこなした。

まずはコロナ禍がはじまってから初めて、実家に帰省した。次男を両親に会わせたのは初めてである。[この件についてはブログ記事にも少し書いた](https://mahata.gitlab.io/post/2022-06-03-sendai/)。

この他には B'z のライブを観るため、横浜まで出かけた。僕はファンクラブ会員になる程度には熱心なファンだけど、B'z 自身が客を入れてライブをすることがここ数年は稀であったため、2019 年の「Whole Lotta NEW LOVE」ツアー以来のライブ参加だ。今年のライブは控えめに言っても素晴らしかった。観るたびに思うけど、B'z の二人はだいぶ若い...が、サポートメンバーがさらに若いので、さすがに老いのようなものは感じる。ちょっと B'z の二人の動きがサポートメンバーに比べて小さめだったりして。ただ、演奏そのものには老いをまったく感じさせないのはすごい。ちなみに、僕が参加したのは最終日であった。

### 資格

[Oracle Certified Java Programmer, Gold SE 11 を取得した](https://catalog-education.oracle.com/pls/certview/sharebadge?id=ED8DBE66191DE9E72D2E70FF0A8DBFC7FAA6E98DF6FC83C4F65C8A77BEFF2DEE)。転職先に Spring のコミッターが多数在籍しているので、僕も Java を書けないとまずいだろうと思って入社前に勉強をはじめた。...んだけど、仕事がはじまってからは TypeScript と Kotlin ばかりを書くことになり、あてが外れてしまった。

とはいえ、せっかく勉強したのだから忘れる前に受験しておこうと思い、年末のプロジェクトの合間の期間に試験を受け、無事に合格できた。

## 2023年の展望

技術者としてはフルスタックさに磨きをかけたい。仕事の一部としてモバイルアプリを作る機会にも恵まれるかもしれないし、もしかしたら機械学習にも触れるかもしれない。そういう仕事を楽しんでいきたい。

その他、オンライン大学院にも少し興味がある。ただ、かなり時間を取られそうなので、手が出ない可能性もある。本当に手が出ないかどうか確かめるため MOOC でいくつか大学院レベルの講義を受講するくらいが現実的なラインかもしれない。

あとは CKA が2023年10月に期限切れしてしまうので、その前に  CKS に更新しておきたい。

仕事と関係ないところでは、家族ともども健康でいたいということと、子どもたちのために少し外出を増やしたいと思っている。ただし、こればかりは流行り病の状況次第になってしまうけど...。


2022 年の振り返り


今年の中旬に、いわゆる外資系大企業に転職した。そこからずっと、楽しく仕事ができている。

グローバルにはウン万人の社員がいるけれど、僕が所属している部署は全体でも 20 名強だし、各プロジェクトはほんの数名だけで回している。僕の部署には全社的な縛りがほとんどなく、独立部隊のように動いている。さながら、ベンチャー企業のような雰囲気だ。自律性が求められる一方で、裁量は大きいし、個々人が及ぼせるインパクトも大きい。単純に、楽しい。

一方で福利厚生を考えると、そこはさすが大企業という感じである。3 ヶ月間 100% 給与が出る育児休業であったり、自学自習のための年間 X 万円の予算、Well-being のための年間 Y 万円の予算、通常のボーナスとは別のストック型のボーナスなどなど。こういうところの手厚さは、いわゆる働きやすさであったり愛社精神につながる。

未来でも同じことを言っているかはわからないけど、今は「こういう環境こそ、自分が長らく求めていたものだな」と感じている。


大企業内の小規模チームでのお仕事


またブログの引っ越しをした。

[引っ越しの経緯は前ブログに書いた](https://mahata.gitlab.io/post/2022-12-01-new-blog-on-vercel/)。コンテンツそのものは引っ越さず、前ブログに書いたものは前ブログに残しておくことにする。

なお、[前々ブログは WordPress にある](https://mahata.wordpress.com)。

それより前に書いたものは残念ながら消えてしまった。

今後も元気にメモを書き散らかしていこうと思う。

投稿記事