<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>mahata.or blog</title>
        <link>https://blog.mahata.org</link>
        <description>A blog about software engineering, programming, and life</description>
        <lastBuildDate>Mon, 02 Nov 2026 00:05:28 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <language>en</language>
        <copyright>© 2026 mahata.or</copyright>
        <item>
            <title><![CDATA[『自分とか、ないから』]]></title>
            <link>https://blog.mahata.org/posts/2026-02-16-jibuntoka-naikara</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2026-02-16-jibuntoka-naikara</guid>
            <pubDate>Mon, 16 Feb 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[『[自分とか、ないから](https://www.sanctuarybooks.jp/book/detail/1462)』を読みました。去年ちょっとメンタル的につらい時期があり、そのときに話題になってて気になっていました。ようやく読めた。

世界に境界は存在せず、すべてはつながっている。例えば、山と川も明確な境界はなく、たまたま水が流れやすいところが川になっているだけで、ここまでが山でここからが川という線引は明確ではない、という話は面白かったです。国境も人為的に線を引いているだけで、日本は島国だけど、海外とも実際には海の底で地続きになっているという話もあり、たしかに、と思いました。海は陸地の大きな水たまり、という旨の表現がされていました。

世界はすべてフィクションであるという主張も面白かったです。おじさんの写真に「総資産5000兆円」というキャプションをつけるとイケオジに見えるとか。同じおじさんでも、言葉の力でイメージが変わるというのは面白いです。恋人も「彼女」や「妻」とラベルづけすることで、違う印象で見えるというのも同様です。ネタバレですが、ファミチキを「鶏の死体」と表現している記述もありました。確かに、同じものでも言葉で印象がガラッと変わるのはフィクション的だと思いました。

同様に、家族もフィクション、会社もフィクション...という話がありました。「兄と弟、どちらが先に生まれるか？」という問いかけがあります。答えは「同時」です。普通に考えると兄が先に生まれるわけですが、関係としては「弟」ができたことで、はじめて「兄」になるでしょ、とのこと。たしかに。そういうのって言葉遊びだし、逆に言えば人間は言葉のせいで関係性を強制されます。

自分自身もフィクションです。自分にどういうラベルが付こうが、自分には関係ないと思うことが重要です。仮に、誰かに「だめ人間」の烙印を押されたとしても、それで自分が変わるわけではなく、それはその「誰か」のフィクションです。自分の管轄外です。そう思うことで、他人の評価に振り回されずに済むと思いました。]]></description>
        </item>
        <item>
            <title><![CDATA[2026年のブログ]]></title>
            <link>https://blog.mahata.org/posts/2026-01-29-blog-in-2026</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2026-01-29-blog-in-2026</guid>
            <pubDate>Thu, 29 Jan 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[かつて[Vercelogというブログ](https://github.com/mahata/vercelog)を作って、その名の通りVercel上でホスティングしていたことがありました。このときは、Next.jsを勉強したいモチベーションから作ったのですが、結局のところNext.jsを深く理解することはできず、クリティカルな脆弱性があるときだけアップデートをするような運用になっていました。

ちょっと気持ちを変えて、Next.jsは置いておき、自分に馴染みのある素のReactをGitHub Pages上でホスティングすることにしました。サーバーサイドがないことで気楽に運用できるのではないかと考えています。今の立場ではNext.jsを深く学ぶ必要性もあまり感じていないということもあります。

これを機会に、もう少し頻繁に記事を書いていこうと思います。]]></description>
        </item>
        <item>
            <title><![CDATA[2025 年の振り返り]]></title>
            <link>https://blog.mahata.org/posts/2025-12-26-retrospective</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2025-12-26-retrospective</guid>
            <pubDate>Fri, 26 Dec 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[今年の振り返り記事です。毎年の恒例行事です。

## 去年までの振り返り

- [2024年のまとめ](https://vercelog.mahata.org/posts/2025-01-21-retrospective)
- [2023年のまとめ](https://mahata.vercel.app/posts/2023-12-22-retrospective)
- [2022年のまとめ](https://mahata.vercel.app/posts/2022-12-23-retrospective)
- [2021年のまとめ](https://mahata.gitlab.io/post/2021-12-25-retrospective/)

## 「去年までの振り返り」の振り返り

2024年は「2025年はコミュニティ活動に精を出したい」ということを言っていました。しかし、その気持はすっかり薄れてしまいました。言い換えると、「所属先の企業がコミュニティ」という気分になりました。ここには尊敬する同僚も多いし、この場所で切磋琢磨することの方が優先度が高いと思うようになりました。

使っているツールも基本的に2024年と大差なく、相変わらずメモ書きは[Obsidian](https://obsidian.md/)で、ソーシャルメディアは[Bluesky](https://bsky.app/)で、という感じです。ペアプログラミングは[Tuple](https://tuple.app/)で、ランチャーには[Raycast](https://www.raycast.com/)を使っています。あ、パスワードマネージャに1Passwordを使い始めました。転職先が1Passwordを配布していて、[Businessアカウントが無料で使える](https://blog.jxck.io/entries/2025-11-09/family-paln.html)と知ったからです。1PasswordでSSH鍵や環境変数の管理をするようになり、手元のマシンから秘密情報をほぼ一掃できました。

あとは[IntelliJ](https://www.jetbrains.com/idea/)はもう使わないかもしれないと思ったけど、色々あってまだ現役です。でも[Kotlin](https://kotlinlang.org/)は書いていないです。IntelliJ、全体的な出来はとてもいいけど、GitHub Copilotプラグインを使おうとすると粗が目立つ、というのが今の感想です。

## 2025年のできごと

### 転職

所属していたチームがレイオフで丸ごとなくなり、転職先を探す羽目になりました。たまたまポジションが空いていた外資系企業に転職しました。

新しい職場では、まだ8~9ヶ月程度しか過ごしていないですが、すでに「色々あったな」という気持ちです。率直に言えば「つらい」経験もあり、今後どうしたものかと思います。今は尊敬できる素晴らしいチームメイトに支えられて「何とかやれている」という感じです。

どの企業もそうだけど、良いところと悪いところがあり、悪いところが極まると「つらい」状態になります。このままだと2026年もどこかのタイミングでつらい状態になりそうです。「わかってるなら何とかするべき」という話はもっともで、そうあるべきだと思います。しかし、そこの是正にモチベーションが持てないのは、ポジションのミスマッチを感じていることから来ていそうです。なので、ポジションの方を「何とかしたい」というのを2026年前半の目標にしたいです。

### 英語

2011年にカナダに引越して現地企業で働き、2015年に帰国しました。その後も英語環境で揉まれてきています。とはいえ、帰国してから、上司が全く日本語を話せない環境は初めてなので、英語をブラッシュアップしようかと思いました。

ブラッシュアップするにも、自分のベンチマークを取るのが先だろうと思い、英検1級を取ろうと思いました。しかし、夏頃に試験を受けた結果は不合格でした。英検を侮っていました。自分の周囲で同じようなキャリアを歩んでいる友人らは、英検1級をさしたる苦もなく取得しているように見えていました。残念ながら、自分にはそのような実力がないという事実を突きつけられました。

英検1級の合格は2026年に持ち越しの目標となりました。古典的だけど、[Anki](https://ankiweb.net/)を使って語彙を増やす訓練を今はしています。来年の夏くらいに試験を受けようと思っており、その直前には難しめの長文を読む練習もしようと思っています。

### 子育て

難しさを感じた一年でした。

長男が発達障害児で、次男が定型発達です。長男とのコミュニケーションは難しいけど、次男は諦めずに長男に話しかけてくれるので、ありがたく思っていました。しかし、次男は長男の影響を強く受けてしまいました。彼もぶつぶつ独り言を話したり、奇声を上げるようになってしまいました。

結果として、次男も幼稚園で友だちを作るのに苦労していて、今後どうしたものかという感じです。

次男の知性が高い分、彼が長男を煽って喧嘩になってしまうことも多々あります。結果として兄弟を一緒に扱うのが難しく、別々に行動させることも増えてしまいました。

2026年も引き続き子育てに悩むことでしょう。

### 健康

#### 右膝痛

2015年にジョギング中に右膝を痛めてから、ずっと右膝に「重さ」を感じていました。とはいえ、生活に支障はないので、特に病院にもかからず過ごしていました。これが2025年の秋くらいから「痛み」を感じるレベルになったので、重い腰をあげて整形外科にかかりました。

近所の整形外科では、レントゲンを撮られて「問題ないですね」と帰されてしまいました。ちょっと消沈しましたが、痛いものは痛いので、MRIのある病院にセカンドオピニオンを求めに行きました。

MRIを撮ってもらった結果も「基本的には問題なし」という扱いで、強いていえばちょっと腫れてるかも、くらいでした。湿布をもらって様子見、というステータスです。まだ劇的な効果は感じられていなくて、来年も痛むようであれば次のステップを検討する、というステータスです。

### リモートワーク @ 軽井沢

2024年に続いて、2025年も夏に軽井沢でリモートワークをしました。6月中旬から9月下旬くらいの期間です。

家族が冷房に弱いので、冷房がなくても過ごせる場所に行きたい、というのがモチベーションでした。ただ、二年の経験を経て「軽井沢でのワーケーションはきつい」という結論にいたりました。

軽井沢は確かに涼しいです。しかし、仕事をするには不便でした。まず、インターネット回線が貧弱です。選んだ物件は「モバイルルーター利用できる」という触れ込みでしたが、遅い上に安定しないのでオンラインミーティングが困難でした。Povoでテザリングをしてみたものの、これも安定せず、地方のセルラーネットワークの厳しさを感じました。なお、[風越公園](https://www.kazakoshi-park.jp/)の近くの物件に住んでいたのですが、ここでイベントをしているときは顕著にネットワークが遅くなりました。

電源も安定せず、何度も停電しました。停電の復旧に4~5時間かかることもあり、ろうそくを灯して夜を過ごすこともありました。後で知ったのですが、現地では自家発電設備を持っているご家庭も多いそうです。

細かいことを言うと、仕事用に椅子や机を準備しなかったため、長時間の仕事で体が痛んだり、仕事用の個室がないため子どもたちに気軽に邪魔されてしまうという問題もありました。

東京の良さを再確認しました。2026年は軽井沢でのリモートワークはやらないと思います。

### 趣味

#### B'z

2025年はB'zのライブに二度行きました。UNITEとFYOPです。どちらも良かった。

UNITEはOne Ok Rockとの対バンの日程に当選しました。One Ok Rockは未知のバンドだったので、当選後はOne Ok Rockのヒット曲を意識的に聴いてライブに備えました。事前の感想は「結構いいじゃん」程度でしたが、ライブに行ってからは「かなりいいじゃん」に変わりました。「完全感覚ドリーマー」や、B'zの稲葉さんが参加した「The Beginning」は結構お気に入りです。

ところで、UNITEはB'z松本さんが体調不良で欠場だったため、いつもとは様子が違いました。実際にはアンコール曲だけ登場して演奏をしてくれましたが、彼は明らかにいつもより痩せてしまっており、無理を押している感じが伝わりました。

FYOPツアーは東京ドームの公演に参加しました。語彙に乏しいですが「とても良かった」です。楽曲以外にもMCにぐっと来ました。細かいところは間違えているかもしれませんが、

> Follow Your Own Passionというタイトルでツアーをやってきました。何事も最初はパッションに突き動かされて進むわけだけど、やっていくと選択肢が増えてきて、雑念も増えてきて、迷いが生じることもあると思います。そういうとき、自分のパッションが何なのか、そこに立ち返ることが大事だと思っています。

...という旨のことを言っていました。まさに自分がパッションを無視して生きているように感じていたので、響く言葉でした。

松本さんもMCで話していて、彼は「（ギターを弾くという、自分にとって）当然のことが、普通にできて嬉しい」という旨の発言をしていました。これはUNITEのときの体調不良から来ている言葉でしょう。自分はまだ大病を患ったことはないけど、彼のようなキャリアの持ち主からの言葉だと思うと重みを感じます。

楽曲としては、東京、声明、Still Aliveあたりが特に心に響きました。

#### 星のカービィ

次男が「星のカービィ」に興味を持ったので、いくつかNintendo Switchのタイトルをプレイしました。具体的には「星のカービィ Wii デラックス」、「星のカービィ ディスカバリー」、「星のカービィ スターアライズ」あたりです。

星のカービィ、僕が小学生の頃からずっと第一線で人気があってすごいなあと思いました。そこだけ切り取るとB'zみたいだ...。しかも、よく考えると、吸い込んで飲み込んで、という演出は残酷な気がするけど、流血表現も一切なくて、ゲームとして楽しいというのがすごい、という感想です。カービィ、とてもかわいい。

#### 資格

毎年ちょっとずつ資格を取っていて、資格取得が趣味になりつつあります。自分は資格取得を通じた勉強の仕方が得意かもしれないとも思います。

今年はGitHubに関する資格を取りました。具体的にはGitHub Foundations, GitHub Administration, GitHub Advanced Security, GitHub Actions, GitHub Copilotの5種類です。現時点でGitHubが提供している技術系の資格はすべて取りました。

これらは仕事で役立てたいというモチベーションで取ったのですが、2026年は自分の興味関心にもとづいたものを狙っていこうと思います。

#### 3Dプリンタ

新しい趣味として3Dプリンタを購入しました。Bambu Lab A1 miniです。まったくの初心者ですが、すでに印刷を楽しく感じています。パズル、タオルかけ、タブレットスタンド、フィジェットなどを作ってきました。もっと活用したいです。

現状は自分でモデリングしていないし、部品の名前やスペックなどもわからないことが多いです。伸びしろだらけです。なお、3Dプリンタを稼働させていない時間を「もったいない」と思うような感覚が出てきたので、沼の一歩手前だな...という気持ちもあります。

#### 漫画

過去に読んだ漫画を再読していて、いかにも脳が老化している感じです。「ナルト」とか「ヒカルの碁」とか、今読んでも面白い。

新しめのタイトルだと「カモのネギには毒がある」や「ウィッチウォッチ」を楽しく読んでいます。どちらも著者の過去作が好きで、すっと手に取れました。

ジャンプ関連の本はゼブラックで読んでいて、一話ごとに漫画本のレコメンドがあるけど、この推薦結果が自分にヒットすることがほとんどなくて、マンガ本のレコメンドエンジンは伸びしろがある市場なのではないか、と思っています。自分がその市場に飛び込む可能性は低いけど。]]></description>
        </item>
        <item>
            <title><![CDATA[『Tidy First?』]]></title>
            <link>https://blog.mahata.org/posts/2025-02-08-tidy-first</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2025-02-08-tidy-first</guid>
            <pubDate>Sat, 08 Feb 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[『[Tidy First?](https://www.oreilly.co.jp/books/9784814400911/)』を読みました。残念ながら、僕にはあまり響きませんでした。

著者は Kent Beck です。僕は彼のファンです。彼が執筆した『[エクストリームプログラミング](https://www.ohmsha.co.jp/book/9784274217623/)』や『[テスト駆動開発](https://www.ohmsha.co.jp/book/9784274217883/)』は何度も読み返しました。Kent Beck の新作なので期待値も高かったのですが、あまり楽しく読めず、残念です。

この本は物理的に薄い本で、章が細かく分割されています。なので、各章が数ページで終わります。さらに、章がほぼ独立しているので、気になる章だけ読むこともできます。

これはメリットでもありますが、僕にとっての「響かなさ」の要因のひとつでもあります。たとえば『テスト駆動開発』は「通貨の実装」を100ページ以上かけて行います。一歩一歩コードを書き進めていく様はライブ感たっぷりでした。しかも実際のプログラミング言語 (= Java) で書いているので、Kent Beck の思考プロセスを追体験できます。これは良かった。

一方『Tidy First?』は短い章が連なっているので、「あれ? 今の話これで終わり?」と思うことが多かったです。サンプルコードも疑似言語で「これは実際にはどういうコードを想定してるんだ?」というのを読み解きづらくもありました。

知識を得る本というより、問いかけを得られる本という趣です。良く捉えれば「考えさせられる本」と言えます。その意味では、多人数でわいわい読書会をするネタとしては、良い本なのかもしれないです。]]></description>
        </item>
        <item>
            <title><![CDATA[『小さな習慣』]]></title>
            <link>https://blog.mahata.org/posts/2025-02-07-mini-habits</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2025-02-07-mini-habits</guid>
            <pubDate>Fri, 07 Feb 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[『[小さな習慣](https://www.diamond.co.jp/book/9784478065778.html)』を読みました。良い本でした。

かねてより人間は「習慣」と「環境」で形成されていると感じています。環境は選べる範囲で選んできました。進学先しかり、就業先しかり。しかし、習慣はコントロールしづらいものです。良い習慣を身につけたいと一念発起してもモチベーションが続かず、いつもの生活に逆戻りする。これが、お決まりのパターンでした。

習慣をコントロールしたいという気持ちから、本書を手に取りました。読後の高揚感もありますが、ある程度はコントロールできるかも、と思えるようになりました。

まず、本書は目標設定の指針が独特です。「ばかばかしいくらい小さい目標」が良いとしています。具体例として「腕立て伏せ1回」という目標があります。これは、数秒で達成できる簡単な目標です。なお「腕立て伏せ1回」が目標ですが、別に1回以上やっても構いません。

この「目標を超えてもペナルティがない」というのが重要です。目標に向かって進むとき、最初の一歩が最も大変です。「ジムで1時間汗を流す」という目標だと、なかなか最初の一歩に踏み出せません。ところが「腕立て伏せ1回」であれば、最初の一歩が重くありません。というか、最初の一歩でゴールです。

この考え方は応用が効きます。例えば200ページの本を執筆したいとします。一日あたり半ページ書くという目標はどうでしょう。興が乗って10ページ書く日もあるかもしれません。でも、それを目標にしてはいけません。ペンを持ち、半ページ書く。それが続けば、習慣になります。「毎日10ページ書く」というのが目標だと、最初の一歩が重いかもしれません。半ページなら、そうでもないはずです。

なお、この本は「モチベーションに頼ってはいけない」と言っています。同意します。モチベーションは管理が難しいものです。「ばかばかしいくらい小さい目標」は、モチベーションなしでも達成できる目標です。そうすることで、モチベーションに依らず目標をクリアし続けられ、良い習慣を作れるということです。]]></description>
        </item>
        <item>
            <title><![CDATA[『TAKE NOTES!――メモで、あなただけのアウトプットが自然にできるようになる』]]></title>
            <link>https://blog.mahata.org/posts/2025-01-29-take-notes</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2025-01-29-take-notes</guid>
            <pubDate>Wed, 29 Jan 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[『[TAKE NOTES!――メモで、あなただけのアウトプットが自然にできるようになる](https://www.amazon.co.jp/dp/4296000411)』を読みました。

メモを [Obsidian](http://obsidian.md) に集約するようになって、数年が経ちました。未だに Obsidian を使いこなせていないように思います。しかし、Obsidian の機能がわからないというより、Obsidian を使ったメモ書きのベストなワークフローがわからない、という感覚です。少し前に流行った本書に Obsidian に対する言及があると聞き、手にとってみました。

この本は、ニクラス・ルーマンという社会学者が採用したツェッテルカステンというメモ術を紹介しています。身も蓋もないことを言うと、ツェッテルカステンの細かい実践方法は理解できないまま読了しました。ルーマンは 20 世紀に活躍した人物なので、彼は紙とペンによるメモを採用していました。これが僕の Obsidian のワークフローとメンタルモデルが乖離していて、ピンと来ませんでした。「紙のメモに一意の数字を振り、関連するメモ同士をリンクする」という旨の説明があった (と理解している) のですが、「どうやって?」の部分がクリアになりませんでした。僕の読解力が不足している可能性も大いにあります。

メモを書くときの心構えとして紹介されている内容は面白かったです。まず、メモは何かを書き写したものではいけない、ということです。たとえば読んでいる本の内容をメモするとき、本の内容を抜粋するのではなく、内容を自分の言葉に置き換えて書く、ということです。「自分の言葉に置き換える」ことは、内容を理解しなければできない。つまり、自分の言葉でメモを取ることこそが学習である、と著者は主張しています。

また、走り書きのメモと永久保存するメモは明確に区別せよ、と述べられています。走り書きのメモは、数日以内に永久保存用のメモに昇華するべきで、そうできないメモは残しても価値がありません。読み返されないから。

ここで自分の Obsidian の使い方に思いを馳せます。僕は Obsidian で、走り書きのメモばかり書いてきました。一日の最初に [Daily Notes](https://help.obsidian.md/Plugins/Daily+notes) を作り、その日にやりたいタスクを書き出します。それをマークダウンでチェックボックスにしておき、終業のタイミングですべてチェックされていることを目指す、という使い方です。タスクごとに一時的なメモが必要なことがあり、それも Daily Notes に含めていました。この使い方だと Daily Notes を見返すことは稀だし、知識が積み上がりません。これは「なんちゃって [Getting Things Done](https://ja.wikipedia.org/wiki/Getting_Things_Done)」で、仕事をこなす意味では良いけど、知識と理解を深めて大きな仕事に取り組むには不十分です。

本書を読んだ上で、とりあえず次のように Obsidian の使い方を変えようと思いました。

1. Daily Notes は引き続き使う
2. Daily Notes の中で積極的にページを作り、その中でもページをリンクさせる

たとえば Daily Notes で「Spring Security による認証機能を実装する」というタスクを作るとき、Spring Security を個別ページとし、そのページの中で、例えば OIDC や Kotlin などのキーワードをまた個別ページとし、リンクさせる...というイメージです。

このようにワークフローを変えて起こる変化がポジティブかどうか、しばらく後に振り返ろうと思います。]]></description>
        </item>
        <item>
            <title><![CDATA[2024 年の振り返り]]></title>
            <link>https://blog.mahata.org/posts/2025-01-21-retrospective</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2025-01-21-retrospective</guid>
            <pubDate>Tue, 21 Jan 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[遅ればせながら、2024 年の振り返りを書きます。

これまでの分はこちらの通りです。

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

## 「去年までの振り返り」の振り返り

> Obsidian はかなり良い。MarkText は 2022 年の時点でも不満を感じながら使っていたけど Obsidian には不満がほぼないです。強いて言えば、僕自身が Obsidian の機能を使いこなしてないように感じるくらいです。機能そのものには大満足なので 2024 年も使い続けていると思います。

はい、これは変わらずです。[Obsidian](https://obsidian.md) は大好きなソフトウェアのひとつになりました。毎日メモを Obsidian で書いています。

> Mastodon から離れて [Bluesky](https://bsky.app/) へと移りました。 Bluesky の UI がほぼ Twitter で、自分はそこに心地よさを感じています。...略...。まだ「Bluesky 一択」と言えるところまでではないです。

もう「Bluesky 一択」と言っていいくらい、ソーシャルメディアの中では Bluesky ばかり見ています。もう少し気軽にポストできるようになりたいんだけど、「これはさすがにくだらなすぎるかな」と思って自重しちゃうのを何とかしたい。

> ダイエットは無事に成功しました。

これは食事の記録をつける習慣が一瞬なくなってしまい、そのときだけリバウンドしかけました。その後、習慣を取り戻し、トータルではキープできています。

> 最近は英語をずっと聞いていても疲れなくなったので、もっぱら [Syntax](https://syntax.fm/) を聞いています。

はい、聞き続けています。[Syntax は動画も配信するようになった](https://www.youtube.com/@syntaxfm)ので、これも観ています。音声だけのときとはまた違う印象を受けます。

> 情報収集といえば、携帯に [Artifact](https://artifact.news/) を入れて時折ニュースを読むようになりました。これは「僕が欲しかった SmartNews」という趣きです。

[2024 年中に Artifact がサービス終了してしまった](https://artifact.news)のは衝撃でした。やっぱりニュースビジネスは難しいんだなあ。

> 自分より若い世代がよく使っているツールは積極的に試そうと思っており、その意味で [Arc](https://arc.net/) を使うようになりました。

残念ながら Arc は手になじまなくて、やめてしまいました。今は Safari をメインのブラウザにしています。なるべく OS に付属しているソフトウェアだけで生活したいという気持ちが強まったので。

> はじめて献血を体験しました。...略...。今後も続けていこうと思います。

2024 年も何度か献血に行きました。来年も続けると思います。

> 仕事関連では Kotlin プログラミングに時間を投資したい気持ちがあります。

この気持ちは薄れてきています。どちらかと言えば、2024 年は TypeScript をたくさん書きました。GitHub Copilot が流行り、VSCode をクローンして生成 AI を組み込んだ IDE が 2024 年中はたくさんリリースされたわけですが、Kotlin は IntelliJ と運命共同体なので、今後が少し心配です。

## 読んだ技術文書

勤務先が買収されたことにともない、2024 年の途中から [O'Reilly Online Learning](https://www.oreilly.com/online-learning/) のサブスクリプションがなくなりました。よく O'Reilly の本や動画を視聴していたので、これは痛手です。

このような理由から、オンラインの技術文書を読むことが増えました。たとえば [React の公式ドキュメント](https://ja.react.dev)や [MDN](https://developer.mozilla.org/ja/) などです。最終的には「これはこれで悪くないな」と思うようになりました。しかし、電車内でこれらのドキュメントを読んでいると、電波の弱いところで記事が読めなくなったりするので、O'Reilly コンテンツを (あらかじめダウンロードして) 視聴する体験には勝てないな、とも思いました。

オンラインの資料とは別に、オフラインでは図書館で本を借りて読むことが増えました。2024 年は次のような本に目を通しました。

- [スタッフエンジニアの道 - 優れた技術専門職になるためのガイド](https://www.oreilly.co.jp/books/9784814400867/)
- [手を動かしてわかるクリーンアーキテクチャ - ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発](https://book.impress.co.jp/books/1123101096)
- [関数型ドメインモデリング - ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう](https://tatsu-zine.com/books/domain-modeling-made-functional)
- [ドメイン駆動設計をはじめよう - ソフトウェアの実装と事業戦略を結びつける実践技法](https://www.oreilly.co.jp/books/9784814400737/)
- [なぜ依存を注入するのか DIの原理・原則とパターン](https://book.mynavi.jp/ec/products/detail/id=143373)

「目を通した」という表現には複雑な気持ちを込めています。実はこれらの本は読み切れていません。図書館で借りて読むというスタイルであるため、年内に出版された本は取り合いになることが多く、読了に 2 週間以上かかるものは一度返す必要があります。そのため、一気通貫で読みづらい、という感じです。

また「図書館で借りて読む」というスタイルが主流になったため、[ブクログ](https://booklog.jp)で読書の進捗状況を管理するようになりました。時間を置いてから本を読み返すことが多くなるので、ブクログの記録が役立っています。

## 読んだ漫画本

- [葬送のフリーレン](https://websunday.net/work/708/)
- [COSMOS](https://www.sunday-webry.com/episode/4856001361087694972)
- [僕の心のヤバイやつ](https://championcross.jp/series/899dda204c3f2/)

いずれも有名な漫画ですね。

### 葬送のフリーレン

これは二周しています。最初は実は「そこまで面白くないな」と思ったのですが、あまりにも評判が良いので、再度読み直したら「めちゃめちゃ面白いじゃん」となりました。物語の展開が、しっかり前半の記述を踏まえた内容になっているので、逆に展開を理解してから前半を読み直すことで「これがつながってたのか...」という感動がありました。特にセリフまわり。

あとは「[サンデーうぇぶり](https://www.sunday-webry.com)」で読む体験が良くて、各話についたコメントを読むことで自分が理解できていなかった描写に気づき、それもまた感動、という感じでした。

### COSMOS

これも「サンデーうぇぶり」で連載を読んでいます。フリーレンと似たような感想ですが、これも周回で読んで「おぉー、これがこう繋がってたのか」と思うことが多々ありました。主人公が「嘘を見抜ける」というスキル持ちで、それそのものは「よくある設定」なのですが、画力と構成力の高さからチープな設定がよく活かされていて読み応えがあります。なんか偉そうなことを書いてしまいましたが、シンプルに言うと「面白い」です。今後も楽しみ。

### 僕の心のヤバイやつ

ラブコメです。最初は「下ネタがきついな」と思ってギブアップしそうになりました。途中から下ネタが減ってきて、すっと感情移入しながら読めるようになりました。まさに「感情移入」がこの漫画の肝だと思っていて、いわゆる陰キャの主人公が悶々と考え込んでいる様をみながら「あぁー、ちょ、おまえー」みたいな感じで読みました。

冷静に考えると 40 を超えたおじさんが中学生の恋愛模様を感情移入しながら読むというのはちょっと...というところではあるのですが、なにせ面白いんで...。

## その他

### Spring Certified Professional

[Spring Certified Professional](https://www.credly.com/badges/9af6e708-c552-48af-87aa-e4cc4cec30f3/public_url) を取得しました。「難しいな」という手応えだったので、無事に合格できてホッとしました。勉強していて Spring について理解が深まったのはもちろんのこと、Spring の細かい部分はまだまだ理解できていないということにも気づけました。時間を割いて勉強した甲斐があります。

### 仕事

2024 年の前半は、各国オフィスのチームメンバーと一緒に仕事ができました。楽しかった。具体的にはシンガポール、インド、韓国、日本という感じでした。クライアントにも恵まれ、自分自身が日頃からよく使うアプリケーションの新バージョンを開発する、というものでした。やりがいがありました。

後半は... (後日追記予定)

コードは概ね Kotlin / Java でバックエンド (Spring Boot) を書き、TypeScript (react) でフロントエンドを書きました。CSS は SASS だったり Tailwind CSS だったり。インフラは AWS を Terraform でいじったり CDK でいじったり。

### はじめての Note

[Note の記事をいくつか書きました](https://note.com/ymahata)。[ktlog](https://github.com/mahata/ktlog/) というブログエンジンを作っていたものの、なかなか公開までたどり着けず、公開できないうちに書きたいことが増えたため Note に手を出しました。良いウェブサービスだと思います。ktlog に対する気持ちが下がってきているので、もしかしたら 2025 年も記事を公開するかも。

### 海外株 (個別銘柄) への投資

資産形成として「インデックス連動型の投資信託を毎月積み立てる」というのをしています。よくあるやつです。

ところで、僕は「2005 年前後に Google の株を買わなかった」というのを後悔しています。当時、僕は Google は「すごい会社だ」と思っていて、「伸びるに決まっている」と思っていました。でも、その頃に読んだ本に「素人がファンドマネージャーに勝つことは難しい。生半可な知識で株を選んでもカモになるだけ」とあり、そういうものなのか、と諦めました。

ここで 20 年前を振り返ると、「ひょっとして、金融機関のファンドマネージャーより自分の方が、Google の将来性を "わかっていた" のではないか」という気持ちになります。ファンドマネージャーは広い視野が必要だけど、こと「技術」に特化すれば、自分の方が見る目があるのではないか。ファンドマネージャーは短期的に成果を出す必要があるけど、僕は長期的な視点に立てるのではないか。そのような気持ちが芽生えました。

そういう気持ちから、僕は個別株として「Cloudflare」と「Microsoft」を選定し、購入しました。

結果。大した利得を得ずに、これらを売却してしまいました。損こそしていないものの。

個別銘柄を買うことのダウンサイドは、それらの銘柄の株価に一喜一憂せずにはいられない、ということです。当たり前のことですが、買ってみるまで気づけませんでした。毎日、これらの銘柄のニュースを追い、株価をチェックしていたのですが、自分のアテンションが「しょうもないこと」に奪われている気持ちになりました。また、これらの銘柄には「期待が持てる」と思っていたものの、円ドルレートの乱高下は自分には想像しづらく、トータルで利得を考えることは想像よりも難しかったです。

そうして、個別銘柄を選定するという試みは 2024 年にはじめ、その年の内に終えてしまいました。実はまだ売り切れていない部分があるものの、買い増すことはないと思います。

## 2025 年の展望

2025 年は TypeScript に投資したいです。

2023-2024 年は「Kotlin に投資していたい」と言っていたのですが、仕事で Spring Boot を使う機会が少なくなりそうで、そうであれば積極的に Kotlin を選ぶケースは減ると思っています。そしてフロントエンド開発で TypeScript を触るので、それならバックエンドも特別な理由がなければ TypeScript でおおむね賄えるのではないかと思います。そして TypeScript でフロントとバックが地続きなウェブサービスを作るとしても、まともに CSS が書けなければ「フルスタック」にはなりません。僕は CSS およびウェブデザイン一般を「なんちゃって」でやってきているので、腰を据えて勉強したいと思っています。

もうひとつは、コミュニティ活動です。コミュニティ活動、実に曖昧な言葉ですね。とりあえず、平日開催のミートアップやカンファレンスに足を運ぶようにしようと思います。うっすらわかっていたのですが、[Kent C. Dodds 氏による「AI があなたの仕事を奪う」という記事](https://zenn.dev/mahata/articles/ai-is-taking-your-job)を読み、「コミュニティと疎遠では将来がない」という気持ちになりました。そして「書くこと」を習慣にしたいです。コニュニティ活動において、まず自分が何者なのか知ってもらわなければ、コミュニティで役に立つことは難しいと思っています。継続的にブログなりなんなりにテキストを残す習慣を作り、自分のやっていること、知っていることを公開していきたいと思っています。]]></description>
        </item>
        <item>
            <title><![CDATA[『疲労とはなにか すべてはウイルスが知っていた』]]></title>
            <link>https://blog.mahata.org/posts/2024-10-30-hiroutohananika</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2024-10-30-hiroutohananika</guid>
            <pubDate>Wed, 30 Oct 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[『[疲労とはなにか すべてはウイルスが知っていた](https://bookclub.kodansha.co.jp/product?item=0000385169)』を読みました。

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

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

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

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

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

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

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

だそうです。

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

それにしても、かつて『[デザインされたギャンブル依存症](https://mahata.gitlab.io/post/2021-10-16-addiction-by-design/)』を読んだときは「効率よくゾーンに入りたい」という気持ちで本を手に取ったものでした。今回も「疲れ知らずになりたい」という気持ちであったわけですが、いつも「楽な道などない」と思わされる結果に終わります。中々うまくいかないものです。]]></description>
        </item>
        <item>
            <title><![CDATA[ギブアップ: Software Engineering at Google ]]></title>
            <link>https://blog.mahata.org/posts/2024-01-05-giving-up-software-engineer-at-google</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2024-01-05-giving-up-software-engineer-at-google</guid>
            <pubDate>Fri, 05 Jan 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[途中まで読んだ『[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/)のありがたみも目減りします。

企業ブランドは水物であり、コンテンツがそれに依存するようでは歴史の重みに耐えかねるな、と感じました。]]></description>
        </item>
        <item>
            <title><![CDATA[運良く生きている]]></title>
            <link>https://blog.mahata.org/posts/2024-01-04-sad-new-year</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2024-01-04-sad-new-year</guid>
            <pubDate>Thu, 04 Jan 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[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)の折には東京にいたので直接的な被害は被っていないものの、事態が落ち着いた後で仙台市に戻ったときには災害の爪痕の大きさを感じずにはいられませんでした。

自分は「運良く生きているだけ」だと感じます。災害に好んで巻き込まれたい人はいないでしょう。これまで運良く、自分は幸せに生きてこられらたと思っています。これを「当然のこと」と思い上がることなく、一日一日を大事に生きなければならないと思う年始でした。]]></description>
        </item>
        <item>
            <title><![CDATA[2023 年の振り返り]]></title>
            <link>https://blog.mahata.org/posts/2023-12-22-retrospective</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-12-22-retrospective</guid>
            <pubDate>Fri, 22 Dec 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[今年のまとめを書きます。

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

- [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) についての知見を深めてほしいと上司に言われているので、重い腰を上げて真面目に取り組もうと思います。]]></description>
        </item>
        <item>
            <title><![CDATA[近況報告 - ktlog]]></title>
            <link>https://blog.mahata.org/posts/2023-12-13-yet-another-blog-engine</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-12-13-yet-another-blog-engine</guid>
            <pubDate>Wed, 13 Dec 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[最近は [ktlog](https://github.com/mahata/ktlog) というサービスを作っています。これは Spring Boot (Kotlin) と React (TypeScript) で作られているブログサービスです。...というのは言い過ぎで、ブログサービスに **なる予定のもの** というのが正しいです。

これを作っているせいで、今はブログ記事をどこに書くべきか迷子になっているのですが、もうしばらくは ktlog がまともに動くようにはならなそうなので、ちょっとここで再び記事を書いてみるか、という気持ちになりました。書きます。]]></description>
        </item>
        <item>
            <title><![CDATA[ChatGPT と Google Bard の比較、または再度の ChatGPT への課金]]></title>
            <link>https://blog.mahata.org/posts/2023-06-09-chatgpt-again</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-06-09-chatgpt-again</guid>
            <pubDate>Fri, 09 Jun 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[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 を楽しもうと思います。]]></description>
        </item>
        <item>
            <title><![CDATA[「体作り」の進捗、または「初めての懸垂」]]></title>
            <link>https://blog.mahata.org/posts/2023-05-12-kensui</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-05-12-kensui</guid>
            <pubDate>Fri, 12 May 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[最近、懸垂ができるようになりました。まだ一回だけだけど。

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

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

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

道は長い...けど、最初のステップは超えられたな...という感じ。引き続きがんばろう。]]></description>
        </item>
        <item>
            <title><![CDATA[「〜です」「〜ます」調への転向]]></title>
            <link>https://blog.mahata.org/posts/2023-04-25-japanese-style</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-04-25-japanese-style</guid>
            <pubDate>Tue, 25 Apr 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[唐突ですが「〜だ」「〜である」調での文章をやめて、「〜です」「〜ます」調に転向したいと考えています。少なくともこのブログにおいては。

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

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

[少し前から過去のブログ記事を読み返す生活をしていて](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)、そこで断定調の自分の文体を読んで「この人、ちょっと圧が強いな...」と感じたことがきっかけです。やわらかい雰囲気の人間になりたいので、がんばります。がんばるぞ。]]></description>
        </item>
        <item>
            <title><![CDATA[『ベタープログラマ』の感想]]></title>
            <link>https://blog.mahata.org/posts/2023-04-20-better-programmer</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-04-20-better-programmer</guid>
            <pubDate>Thu, 20 Apr 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[ベタープログラマ](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/)』とは真逆の主張がされていました。三項演算子は可読性を下げることが多いと感じているため、この主張には同意しかねました。]]></description>
        </item>
        <item>
            <title><![CDATA[『Reactハンズオンラーニング 第2版』の感想]]></title>
            <link>https://blog.mahata.org/posts/2023-04-10-react-hands-on-learning-2nd</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-04-10-react-hands-on-learning-2nd</guid>
            <pubDate>Mon, 10 Apr 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[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)、セクションごとに動くサンプルが提供されている点にも好感を持ちました。少し時間をおいて、サンプルを動かしつつ読み直そうと思っています。]]></description>
        </item>
        <item>
            <title><![CDATA[B'z ファン歴]]></title>
            <link>https://blog.mahata.org/posts/2023-04-08-bz-fan-history</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-04-08-bz-fan-history</guid>
            <pubDate>Sat, 08 Apr 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[チームメイトへの自己紹介で「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 才のユニットが変わらずにカッコよく居続けてくれたら、ファンとしては幸せなことだと思う。]]></description>
        </item>
        <item>
            <title><![CDATA[過去に記事を書いた企業ブログ（など）]]></title>
            <link>https://blog.mahata.org/posts/2023-03-14-company-blogs-where-i-contributed-articles</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-03-14-company-blogs-where-i-contributed-articles</guid>
            <pubDate>Tue, 14 Mar 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[先日 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)]]></description>
        </item>
        <item>
            <title><![CDATA[Zenn に技術ブログを書く話]]></title>
            <link>https://blog.mahata.org/posts/2023-03-13-zenn</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-03-13-zenn</guid>
            <pubDate>Mon, 13 Mar 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[最近は多くのソフトウェアエンジニアが Zenn に記事を書いているようです。[僕も使い心地を試す目的で Zenn を使ってみることにしました](https://zenn.dev/mahata)。技術的でない記事は、引き続きこのドメインでホストしようと思っています。]]></description>
        </item>
        <item>
            <title><![CDATA[マラソン大会の思い出]]></title>
            <link>https://blog.mahata.org/posts/2023-02-16-youthful-days</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-02-16-youthful-days</guid>
            <pubDate>Thu, 16 Feb 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[僕は小学生の頃とても太っていた。そして、肥満児は足が遅い。

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

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

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

自分は「人に優しく接するためには、自分自身が元気であることが必要だ」と思っている。だから、なるべく元気でいようと思っている。でも、この子のように「自分がきつい状況にあっても、相手のことを考えられる」ことが真に目指すべき到達点なのかもしれない。]]></description>
        </item>
        <item>
            <title><![CDATA[Software Engineering at Google: Chapter 3 - Knowledge Sharing]]></title>
            <link>https://blog.mahata.org/posts/2023-02-14-software-engineering-at-google-chapter3-knowledge-sharing</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-02-14-software-engineering-at-google-chapter3-knowledge-sharing</guid>
            <pubDate>Mon, 13 Feb 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[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 方位を教えるため、まず東西南北について話そうとした。僕が「こっちが北だとすると、反対側は何かな?」と生徒に聞いたら、その子が「東...かな?」と答えた。僕は驚いて「えっ!」と声をあげてしまった。東西南北を知らない中学生がいるなんて...というのは、当時の僕には驚きだった。

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

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

さて、他に本章で面白かったことと言えば「質問をすることで、他の人も質問しやすくなる」という話だ。僕は場が静まり返っているときほど質問をする傾向がある。まさに他の人の質問しやすさのためである。こういう所作を本の中で肯定してもらえるのは嬉しく思う。]]></description>
        </item>
        <item>
            <title><![CDATA[Software Engineering at Google: Chapter 2 - How To Work Well On Teams]]></title>
            <link>https://blog.mahata.org/posts/2023-02-10-software-engineering-at-google-chapter2-how-to-work-well-on-teams</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-02-10-software-engineering-at-google-chapter2-how-to-work-well-on-teams</guid>
            <pubDate>Fri, 10 Feb 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[この記事は『[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 ...` の辺りは「あなたのコードが読みづらい」ではなく「わたしの理解が追いつかない」という感じで謙虚さを感じる。

正しければ何を言っても構わない、という考え方もあるだろう。しかし、それはソーシャルゲームにおけるシステムを無視しており、損をしている。何より、そういう人とはチームメイトとして一緒に働きたくない。]]></description>
        </item>
        <item>
            <title><![CDATA[Software Engineering at Google: Chapter 1 - What Is Software Engineering]]></title>
            <link>https://blog.mahata.org/posts/2023-02-06-software-engineering-at-google-chapter1-what-is-software-engineering</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-02-06-software-engineering-at-google-chapter1-what-is-software-engineering</guid>
            <pubDate>Mon, 06 Feb 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[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% の差」という数字の根拠は特に書かれていなかったけど、少なく見積もってもその程度の差はあるだろう。]]></description>
        </item>
        <item>
            <title><![CDATA[外部ドメインでホストされているリソースをみだりに読み込むべきではないという話]]></title>
            <link>https://blog.mahata.org/posts/2023-01-27-dont-use-libraries-hosted-elsewhere</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-27-dont-use-libraries-hosted-elsewhere</guid>
            <pubDate>Fri, 27 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[IIJ Engineering Blog の「その証明書、安全ですか？」という記事](https://eng-blog.iij.ad.jp/archives/17668)を読んだ。小難しい話をユーモアをまじえて解説する、良い記事だと思った。

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

> この事例でハイジャックされたのはKLAYswap自体ではなく、KLAYswapが利用するJavaScriptのライブラリが置かれていた外部のサイトでした。KLAYswapにアクセスしたユーザは、偽の外部サイトから改竄されたJavaScriptファイルをダウンロードし、それを実行して仮想通貨を奪われました。

これは個人的には古傷をえぐられる事例で、過去にコードレビューで「みだりに外部ドメインのリソースを読むべきではなく、可能な限り自分たちで管理できるドメインにリソースを移動して使うべきである」と主張したものの「考えすぎだ」と却下されたことがある。僕の言葉遣いがいたらなかったのかもしれないし、いわゆる信頼残高が足りなかったのかもしれない。しかし、具体的にそういう事例を例示できれば説得力も増すものだし、記憶に留めておこうと思った。]]></description>
        </item>
        <item>
            <title><![CDATA[Don't Lead by example の日本語訳]]></title>
            <link>https://blog.mahata.org/posts/2023-01-24-dont-lead-by-example</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-24-dont-lead-by-example</guid>
            <pubDate>Tue, 24 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[この記事は 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)_ だとも言えます。よいリーダーは分かりやすくコミュニケーションし、適切な期待値を設定し、チームメンバーが能動的に動けるように指導します。ぐっとこらえて、ロールにしたがいましょう。

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

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

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

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

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

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

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

### まとめ

"お手本になる" ことでリードしてもうまくいきません。「何がよい振る舞いなのか」を規定することは重要ですが、強いリーダーシップには不十分です。テックリードとして振る舞うというのは、明確な期待値の設定をし、忌憚ないコミュニケーションを重視することです。ただし、思い上がってはいけません。あなたはチームメンバーであって、ボスではないのです。]]></description>
        </item>
        <item>
            <title><![CDATA[『プログラミングTypeScript』 第四章 - final 修飾子のエミュレート]]></title>
            <link>https://blog.mahata.org/posts/2023-01-23-programming-typescript-chapter5-emulate-final</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-23-programming-typescript-chapter5-emulate-final</guid>
            <pubDate>Mon, 23 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[プログラミング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()` によって得られるようになった。]]></description>
        </item>
        <item>
            <title><![CDATA[RSS リーダーへの回帰]]></title>
            <link>https://blog.mahata.org/posts/2023-01-20-back-to-rss-reader</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-20-back-to-rss-reader</guid>
            <pubDate>Fri, 20 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[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 から流れてくれば、とても嬉しい 🤗]]></description>
        </item>
        <item>
            <title><![CDATA[MarkText から IntelliJ への移行]]></title>
            <link>https://blog.mahata.org/posts/2023-01-19-marktext-to-intellij</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-19-marktext-to-intellij</guid>
            <pubDate>Thu, 19 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[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)

テキストファイルをいじるのに専用のソフトウェアは不要である。オーバーエンジニアリングしない。そういう気持ちをあらたにした。]]></description>
        </item>
        <item>
            <title><![CDATA[GitHub でスターをつけたプロジェクトを定期的にリマインドする話]]></title>
            <link>https://blog.mahata.org/posts/2023-01-18-github-actions-for-github-stars-reminder</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-18-github-actions-for-github-stars-reminder</guid>
            <pubDate>Wed, 18 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[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 に投稿してもらい、記憶を掘り起こしてもらうようにした。]]></description>
        </item>
        <item>
            <title><![CDATA[定期的な処理を GitHub Actions で行う話]]></title>
            <link>https://blog.mahata.org/posts/2023-01-17-github-actions-as-a-cron-server</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-17-github-actions-as-a-cron-server</guid>
            <pubDate>Tue, 17 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[何かの処理を定期的に実行したい、そんなこともあるでしょう。プログラマであれば。

[過去には `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 をトリガーしようと思ったが、うまくアクションが動かずに「あれーなんでだろう...」となってしまった。]]></description>
        </item>
        <item>
            <title><![CDATA[『プログラミングTypeScript』 第四章 - is メソッドの実装]]></title>
            <link>https://blog.mahata.org/posts/2023-01-16-programming-typescript-chapter4-is-method</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-16-programming-typescript-chapter4-is-method</guid>
            <pubDate>Mon, 16 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[プログラミング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)。

こういうケースには自分で気づけないといけないな。]]></description>
        </item>
        <item>
            <title><![CDATA[『プログラミングTypeScript』 第四章 - ジェネレーターとイテレーター]]></title>
            <link>https://blog.mahata.org/posts/2023-01-13-programming-typescript-chapter4-generator-iterator</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-13-programming-typescript-chapter4-generator-iterator</guid>
            <pubDate>Fri, 13 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[『[プログラミング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` の両方を持つことがわかる。したがって、これは反復可能なイテレーターだと言える。]]></description>
        </item>
        <item>
            <title><![CDATA[SadServers - "Saskatoon" の解説]]></title>
            <link>https://blog.mahata.org/posts/2023-01-11-sadservers2-saskatoon</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-11-sadservers2-saskatoon</guid>
            <pubDate>Wed, 11 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[前回](/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` 後にもっとも後ろに来る行を取得する]]></description>
        </item>
        <item>
            <title><![CDATA[SadServers - "Saint John" の解説]]></title>
            <link>https://blog.mahata.org/posts/2023-01-10-sadservers1-saint-john</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-10-sadservers1-saint-john</guid>
            <pubDate>Tue, 10 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[[こちらの記事の内容は Zenn に移しました](https://zenn.dev/mahata/articles/f3b758c96fe698) (この記事そのものも、後で消すかもしれないです)。]]></description>
        </item>
        <item>
            <title><![CDATA[ブログの読み返しが好きな話]]></title>
            <link>https://blog.mahata.org/posts/2023-01-05-read-my-own-blog</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-05-read-my-own-blog</guid>
            <pubDate>Thu, 05 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[いかにもナルシストっぽい発言だけど、僕は自分の過去のブログ記事を読み返すのが好きだ。[以前もそのような趣旨の記事を書いたことがある](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` が生成される。]]></description>
        </item>
        <item>
            <title><![CDATA[お酒のない生活]]></title>
            <link>https://blog.mahata.org/posts/2023-01-04-no-alcohol-life</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-04-no-alcohol-life</guid>
            <pubDate>Wed, 04 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[最近、お酒を飲まなくなった。

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

お酒を摂取しない生活は快適だ。夜に小難しい本を読めたり、集中を要するタスクをこなせたりするため、今では積極的にお酒を飲まない習慣を守ろうと思っている。]]></description>
        </item>
        <item>
            <title><![CDATA[アウトプットのためのインプット]]></title>
            <link>https://blog.mahata.org/posts/2023-01-03-input-for-output</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2023-01-03-input-for-output</guid>
            <pubDate>Tue, 03 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[単に「意識が変わってきた」という話なのだが、最近はアウトプットを意識してインプットをするようにしている。たとえば本を読むときは、ブログに感想を書く前提で読んでいる。

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

しかし、今の自分には時間が足りない。自由な読書を楽しむよりは、単位時間あたりの学習効率を高めたい。そういう気持ちの変化が、アウトプットを意識してインプット効率をを上げたいというモチベーションにつながっているのだと思う。]]></description>
        </item>
        <item>
            <title><![CDATA[2022 年の振り返り]]></title>
            <link>https://blog.mahata.org/posts/2022-12-23-retrospective</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2022-12-23-retrospective</guid>
            <pubDate>Fri, 23 Dec 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[[去年に続き](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 に更新しておきたい。

仕事と関係ないところでは、家族ともども健康でいたいということと、子どもたちのために少し外出を増やしたいと思っている。ただし、こればかりは流行り病の状況次第になってしまうけど...。]]></description>
        </item>
        <item>
            <title><![CDATA[大企業内の小規模チームでのお仕事]]></title>
            <link>https://blog.mahata.org/posts/2022-12-01-startup-like-big-tech</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2022-12-01-startup-like-big-tech</guid>
            <pubDate>Thu, 01 Dec 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[今年の中旬に、いわゆる外資系大企業に転職した。そこからずっと、楽しく仕事ができている。

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

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

未来でも同じことを言っているかはわからないけど、今は「こういう環境こそ、自分が長らく求めていたものだな」と感じている。]]></description>
        </item>
        <item>
            <title><![CDATA[ブログの引っ越し - うん、「また」なんだ。済まない。]]></title>
            <link>https://blog.mahata.org/posts/2022-11-30-yet-another-blog-migration</link>
            <guid isPermaLink="false">https://blog.mahata.org/posts/2022-11-30-yet-another-blog-migration</guid>
            <pubDate>Wed, 30 Nov 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[またブログの引っ越しをした。

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

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

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

今後も元気にメモを書き散らかしていこうと思う。]]></description>
        </item>
    </channel>
</rss>
