
ハロウィンが近いということで、思いつきでハロウィンに関するクイズのサイトを作った。

[https://halloween.umigame.app](https://halloween.umigame.app)

技術以外の面については note に書いた。

[https://note.com/newnakashima/n/nd2a0354630db](https://note.com/newnakashima/n/nd2a0354630db)

ここでは技術面について書く。

## Bun

Bun 1.3 を試す意味で Bun を使った。概ね快適に動くし開発できたが、ところどころまだこなれてないところはあった。例えば `bun run build` してもそのままでは通らないとか。

`bun init --react=shadcn` でプロジェクトを作った。最初はReact抜きで素の `bun init` でプロジェクトを作って後付でReactを入れようとしていたのだが、設定が難しく断念した。特に画像類などのアセットが本番で参照できない。

多分、 `bun init --react` だと build.ts というファイルが作られるが、このスクリプトでTSをバンドル化しているようで、ここでファイルをゴニョゴニョして dist ディレクトリに格納しているようだ。

また、 Cloudflare Workers にデプロイしたが、そちらは Bun 1.2 系のようでエントリーポイントが想定通りに動作しないっぽかった。そのため Claude が勝手に 1.2 系対応のエントリーポイントを作ってくれた。

[Bun 1.3 の公式ブログ記事](https://bun.com/blog/bun-v1.3)を見ると、SPAでもMPAでも簡単に作れそうな雰囲気に見えるが、割とそういうことはなくて、MPAだと雛形になるindex.htmlに当たるHTMLを複数ページ分作る必要がありだるかったので、やはりフロントエンドは基本SPAで作ってルーティングライブラリを別途インストールするのが良さそうだ。公式ブログ記事で複数のパスでフロントエンドをサーブしているのはあくまでユーザー向けフロントエンドと管理画面とで別々のSPAがある、みたいなケースっぽい。

## テスト、Lintとか

今回はテストを全く追加しなかった。LinterもFormatterも設定しなかった。CIも設定してない。手動テストのみ。本当に Vibe Coding という感じだった。そして、やはりAIで開発するならこのスタイルの方が速いと思った。もちろん長期的にもこのやり方のほうが速いかと言われたらわからない。そのうち全体的な整合性が容易に壊れるのは確実と思う。しかし、人の手による開発のように、初期からCIのセットアップとかテストとかLinterとかFormatterを設定してしまうと、AIがコミットのたびにそれらの修正のために手を止めるようになり、人が開発しているのとたいして変わらない速度になってしまうと思う。プロトタイプをとにかく速く作って世に出して検証する、という目的のためには、思い切って品質管理の自動化をバッサリ切り捨てることが間違いなく有効だと感じた。アプリが「いける」とわかってから環境を整えても遅くない。売れるかわからないものの品質を担保するのは無駄な投資になる可能性が高い。知見が得られるという意味では完全に無駄ではないにせよ。

## AIレビュー

普段は CodeRabbit を使っているが、今回は全く使わなかった。これが開発速度に最も「寄与」していると思った。CodeRabbitのレビューは最近はなかなか鋭く、レビューコメントを見ると「確かにここは修正しないとな」とか思って修正してしまうのだが、この作業のせいで人間が書いているのと変わらない速度にまで遅くなってしまう。しかも CodeRabbit 自体も精度のために速度を犠牲にしているフシがあり、一時期よりもかなりレビューに時間がかかるようになっている。コードベースが成熟してきたら CodeRabbit などのAIレビューはほぼ必須だと思うが、プロトタイピングの段階でAIレビューは必要ない。必要ないというよりも無い方がいい。オーバーキルというやつだ。

このあたりの「技術的負債」に対する考え方は、AI時代以前とあまり変わらないように見えて大きく違うような気がする。人間の時代においては「借り入れも時には必要」という考えはあったにせよ、テストが全く存在しないコードベースやレビューが全く無い作業フローなどは論外という雰囲気があったと思う。なぜなら、最低限の品質担保の仕組みがなければ後のフェーズにおけるテスト拡充やリファクタが非常に難しくなり、プロダクトの寿命に直結してしまうからだ。しかし、AI時代においては品質担保自動化を下手にセットアップすると、AIがそれを「やり過ぎ」てしまう。テストをあまりにも簡単に書かせることができるため、テストケースが最初からめちゃめちゃ網羅されてしまい、簡単な変更でもテストがFailするようになり、その都度AIが修正してくれる。一見良いことのように見えるが、AIを使った開発の最も大きな恩恵である開発速度が犠牲になるし、AIにとって死活的なリソースであるコンテキストを大量に消費してしまう。

AI時代の新規開発においては、いくら不安であってもAIを信頼し、任せて、速度の恩恵をうけることが最も重要な気がする。そこでコードを人間が詳しく見てしまうと、汚いコードや無意味なコードが大量に作られているのを目にすることになり、修正したい衝動に駆られてしまうと思うが、開発初期からそちらに気を取られるとユーザーに届けるべき機能がなかなか届けられなくなるということだ。きれいなコードやバグの無いアプリは、機能と価値を届けた後で整えたほうがいい。AI時代においては価値を届けることのコストは非常に小さく、きれいなコードとバグの無いアプリを届けることのコストが圧倒的に大きい。

## Zed

今回から Zed を使ってみた。その前までは Cursor を使っていた。使い勝手は Cursor や VSCode とだいぶ違う感じがするので、なれるまでは1週間とかかかる気がする。VSCodeにあった拡張がZedにもあるとは限らないし、VSCodeで自動化できてたものが自動化できない可能性もある。

ただ、ファイル検索はやはり速いような気がする。コードベースが大きい場合は Zed の優位性が効いてくると思う。しかし現在の自分の開発ではそこまで恩恵を感じられない。

Claude Code が Zed 内で使えるのは良い機能だと思う。Zed のAIエージェントじゃなくて自分のサブスクしてる Claude Code が使えるようだ（多分）。Claude Code が修正したコードの差分を見ながら Cursor ライクに Reject するか Keep するか判断できるのはなかなか良い。ただ、先述の通り人間がコードを見すぎるのは良くなく、AI開発の最大のメリットを殺してしまうことになると今のところ考えている。


ハロウィンクイズのサイトを作った


以前は https://blog.umigame.tech というドメインでWordPress製のブログをホストしていましたが、https://www.umigame.tech に統合することにしました。

理由は、記事を投稿することがめちゃくちゃ稀なのと、ホスティング費用が地味に高いからです。円安やインフレのせいで大した事ないサーバーでも月に1000円くらいかかったりします。これを静的ホスティングに移行するだけでほぼタダでホストできるようになります。1000円浮けばAIデッキに新しいサービスを組み込めます。今はWebに金をかける時代ではないのです。


会社のブログを移行しました


『最強チームをつくる方法』という本を読んだのでメモ。

*   腐ったリンゴ
    *   チームに一人でも「性格が悪い」「怠け者」「周りを暗くする」人がいると、チームのパフォーマンスは30〜40％下がる
    *   チームのメンバーは腐ったリンゴの振る舞いを真似するようになる
    *   まさに悪貨は良貨を云々
*   腐ったリンゴを中和する振る舞い
    *   腐ったリンゴが嫌な雰囲気を出すと、それを中和する人がいる
    *   中和する人は「おいしいリンゴ」
    *   嫌な雰囲気になると笑顔を振りまいたりする
    *   おいしいリンゴは、ここが安全であるというメッセージをメンバーに伝える
*   チームのパフォーマンスを決めるのはメンバーの優秀さではない
    *   強いリーダーでもない
    *   ちょっとした行動がチームのパフォーマンスを決める
    *   チームに「安全」や「安心」を感じさせる行動
*   良いチームの特徴
    *   物理的距離が近い
    *   アイコンタクトが多い
    *   肉体的接触がある
    *   短い言葉のやり取りが多い
    *   仲良しグループを作らず、メンバー全員が仲が良い
    *   人の話を遮らない
    *   質問が多い
    *   人の話を熱心に聞く
    *   ユーモアと笑いがある
    *   ありがとうと言う
*   安心と安全をつくるのは帰属のシグナル
    *   帰属のシグナルの特徴
        *   エネルギー
            *   目の前の交流を大切にする
        *   個別化
            *   メンバーを独自の存在として尊重する
        *   未来志向
            *   関係がこの先も続く
*   帰属のシグナルは何度も送られる必要がある
*   チームのパフォーマンスの計測可能な指標
    *   メンバー全員が話し、話す量も同じ、一回の発言は短い
    *   アイコンタクトがあり、話に熱量がある
    *   リーダーだけでなくメンバー同士でコミュニケーションをとる
    *   メンバー間で個人的な雑談がある
    *   メンバーが定期的にチームを離れ、戻ってきたときに新しい情報を共有する
*   自分のことを気にかけてくれる人がいる、という認識がパフォーマンスを向上させる
*   脳は安心よりも危険の方を重視する
    *   安心を感じるためには帰属のシグナルが継続的に何度も送られる必要がある
*   帰属できる環境の基準
    *   以下に全てイエスと答えられる場所
    *   「私たちはつながっているか？」
    *   「私たちは未来を共有しているか？」
        *   チームとしての成長が予想できない環境はダメ
    *   「ここは安全な場所か？」
        *   ミスを責められる環境は安全ではない
*   帰属意識を育てるには
    *   物理的に近くにいること
    *   遠慮なく指摘したり褒めたりする
    *   一緒にメシを食う
    *   チーム外の世界のことも話す
    *   チームがつらい思いをしたときに絆は深まる
    *   衝突の時間を作る
        *   ある人同士が偶然に出会うこと
        *   仲良しグループで固まるのはダメ
    *   働く場所の距離が8メートルより近くなるとコミュニケーション頻度が急激に高くなる
    *   近くで働く人同士はメールの頻度が4倍になる
    *   近くで働くチームは進捗スピードが32%上がる
    *   メンバーの話を遮らない
    *   リーダーが早い段階で自分の弱さを見せる
        *   自分が間違っている可能性を認める
    *   将来の話をする
    *   ありがとうとしつこく言う
        *   ありがとうは単なる感謝の言葉ではなく、帰属のシグナルとして機能する
        *   ありがとうが多いチームはパフォーマンスが優れている
    *   メンバー選びを慎重に厳しくやる
        *   悪貨は良貨を云々だから
    *   腐ったリンゴを取り除く
        *   要するに有害な人は容赦なくクビにする
    *   いいコーヒーマシンやラウンジや食堂を作る
        *   衝突の機会になるから
    *   すべての人に発言の機会を与える
    *   サンドウィッチフィードバックをしない
        *   褒め言葉で批判を挟むやつ。褒め言葉しか伝わらない
*   弱さを見せる
    *   メンバーに弱さを見せると、相手も弱さを見せてくれる
    *   弱さを互いに開示すると帰属意識が強まる
    *   互いの弱さを認めると、協力が生まれる
    *   自分が主役になりたい気持ちをいましめる
    *   何度も弱さを見せる
*   運命共同体
    *   帰属意識が強まると、失敗を恐れなくなる
    *   他のメンバーが助けてくれることを確信できるから
*   質問する
    *   質問することで問題を発見する
    *   普段は隠している本心を話すようになる
    *   相手の話を聞くことに専念すると、絆が深まる
*   ネガティブなフィードバックはテキストではなくて直接話して伝える
    *   お互いに気まずさを受け入れることで誤解がなくなる
*   何を言うかではなく、何を言わないか
    *   何か良いことを言おうとする気持ちがチームの文化を壊す
*   時々リーダーが敢えて不在になり、メンバーだけで意思決定できるようにする
*   チームで共通の目標を持つ
    *   現実のチームと理想のチームを物語として認識する
    *   ピグマリオン効果
    *   カスタマーの喜びの声を聞かせるだけでパフォーマンスが上がる
    *   何を優先にするのか、優先順位を決める
        *   客が大事なのか、メンバーが大事なのか

『最強チームをつくる方法』読書メモ


思うところあって『Team Geek』という本を読んだので自分が気になったところだけメモ。

*   HRT
    *   Humility（謙虚）
        *   自分を改善する態度
    *   Respect（尊敬）
        *   相手を思いやる
    *   Trust（信頼）
        *   自分以外の人は有能であると信じる
    *   あらゆる人間関係の衝突は、HRTの欠如による
*   影響を受けやすくする
    *   影響を受けやすくなれば、それだけ影響を与えやすくなる
    *   弱いところを見せれば、それだけ強い人だと思われる
    *   つまり頑固なのはダメ
*   チームの文化を尊重する
    *   文化を破壊する振る舞いをする人は追い出すための手間がかかる
    *   敵対的で意地悪な文化のチームにはそういう人が集まる
*   優秀なエンジニアを増やすには、優秀なエンジニアを採用する必要がある
    *   優秀な人は優秀な人がいるところに集まる
*   同期コミュニケーションを減らして非同期コミュニケーションを増やす
    *   ミーティングをなるべく減らす
    *   ドキュメントをなるべく増やす
*   ミッションステートメント
    *   チームの目標
    *   メンバーの向いている方向を揃える
*   ミーティングは5人以下にする
    *   一日のうち3-4時間は「予定」を入れて作業の時間として確保する
*   対面で一緒に働くのが一番いい
    *   対面は一番帯域が太い
    *   リモートで働くのは難しい
*   マネージャーではなくサーバントリーダーになる
    *   執事や召使のようにチームに奉仕する
    *   HRTの精神
*   パフォーマンスの低い人は早めにクビにする
    *   パフォーマンスの低い人が1人いるだけでチーム全体のパフォーマンスが下がる
    *   本人のためにもならない（他のチームでなら活躍できる可能性がある）
*   採用を妥協しない
    *   採用基準以外の理由で採用してはならない
        *   応募者全員採用基準に満たなかったが応募者の中では最も優秀だった人を採用、みたいなのはダメ
*   リーダーは作業を奪わない
    *   新人が3時間かけてやる作業を自分が20分でやったりするのはダメ
    *   メンバーの学習の機会を奪うことになる
*   メンバーに対するフィードバックでオブラートに包まない
    *   HRTの精神を発揮しつつ正直に批判的な意見を述べるのが良い
    *   褒め言葉の中に批判を混ぜる伝え方は伝わらない（褒め言葉の方しか伝わらない）
    *   ユーモアをまじえて伝えるのは問題ない
*   事は荒立てる
    *   スキルが低いエンジニア、頑固なエンジニア、働かないエンジニアなどがいたときに、そのうち改めてくれるだろうと思ったらダメ
    *   指摘して、それでも治らなければ、早めにクビにする
*   有害な人
    *   有害な人は、そのふるまいが悪いことだと気づいていないので、面接で見つけることは難しい
    *   有害な人は、プロジェクトのことに考えが及んでいない
        *   過去の経緯を無視する
    *   有害な人は頑固である
        *   自分が正しいと譲らない
        *   実際に正しいこともあるが、有害な人の正論よりはチームのほうが大事
    *   有害な人は、権利を要求しがち
    *   有害な人は、被害妄想を抱きがち
    *   有害な人は、完璧主義者である
*   有害な人への対処法
    *   感情的にならない
        *   感情的になって返信に時間を費やすのは無駄
        *   返信しなければいい
        *   事実だけに基づいてやりとりする
    *   追い出す
        *   丁寧な言葉づかいで追い出す
*   **有能なプログラマは交換可能だが、チームの文化は交換不可能**
    *   短期的なメリットのために文化を犠牲にする必要はない
        *   つまり、テコ入れで変なプログラマをチームに入れてはダメ
*   無能で十分説明されることに悪意を見出すな
    *   「有害な人」は単純に無能である
    *   「有害な人」には悪意はない
    *   普通に無能な人に対するように処理すれば良い
*   組織で昇進することは良いこと
    *   自分がコントロールできる範囲が広がるから
    *   難しいプロジェクトにも手を上げてリスクをとってやるべき
    *   会社の評価制度もハックしてのし上がるべき
*   リファクタリングしすぎない
    *   リファクタリングやテストを書くことは会社的には成果にならない
    *   仕事の半分以上はユーザーに見える部分の実装をして自分の評価を上げるべき
*   小さく約束して、大きく届ける
    *   見積工数を多めに出しておいて、予定より進捗しましたみたいに報告するアレ
*   怠けない
    *   怠惰はプログラマの美徳ではない
    *   ユーザーの使いやすいアプリはプログラマにとって面倒なアプリ
    *   それでも怠けずに実装する

Team Geekメモ


ハイデガーは技術について独特の見方をしていました。普通は技術が作り出すものは、できなかったことできるようにする何か、と考えられていると思います。別の言い方をすれば、今までになかった新しい物を作り出すのが技術だと思われているのではないかと思います。最初にハンマーを作った人は、これで手を傷めずに物を砕くことができると思ったでしょうが、それはそれまでに無かったものです。近代的な工場は、それまでにできなかったような大量生産を可能にしました。ソフトウェアは情報のやり取りが発生するあらゆる領域でそれまでは不可能だった効率化を進めました。最近ではAIが「今まで無かったもの」「今までできなかったこと」を次々と実現しているのを私達は目の当たりにしています。それはまるで無から有が生まれたかのように一般の人びとの目には映ります。

しかしハイデガーはそういうふうには捉えていないようです。ハイデガーにとって技術とは、隠れているものを現前させるものであり、無から有を生み出すような類のものではありません。

> では、自然においてであれ、手仕事や芸術においてであれ、こちらへと前にもたらして産み出すことは、どのように生ずるのでしょうか。始動のきっかけとなる四重のあり方が演じられる、こちらへと前にもたらして産み出すことは、何でしょうか。始動のきっかけとなることは、こちらへと前にもたらして産み出すことにおいてそれぞれ出現に至るものが現前的にあり続けることに係わり合っています。こちらへと前にもたらして産み出すことは、隠されたさまのほうから、隠れなき真相〔Unverborgenheit〕へと、前にもたらします。

新しく生み出されたように見えるものは、隠されていたのであり、それが眼前に表れてくるようにさせるのが技術だというのがハイデガーの考えのようです。一見荒唐無稽にも思えますが、「ガンダム」を作りたいと真面目に情熱を持って考えている人が少しでもガンダムに近いものを作ろうと奮闘して徐々に形になりつつあることを思うと、あながちデタラメとも言えない説だと感じます。もちろんこれは人の心にすでに描かれたものについての話なのでハイデガーの言っていることとは次元が異なるとは思いますが、技術とは、無いものを作り出す行為というよりは有り得るものを眼前に表す行為という意味でわかりやすいたとえなのではないかと思います。人の心に思い浮かべることすらできないものは人間が作りだすことはおよそ不可能だろうからです。

また、ハイデガーは技術、つまり顕現させることを、大きく２種類に分けて論じています。一つは手仕事や芸術として物事を顕現させること＝ポイエーシスです。もう一つは自然や人を挑発してかり立てて徴用することです。「徴用」という言葉からは搾取的なニュアンスが感じられます。徴用の例として、機械化された食糧産業が挙げられています。「現代の動力機械技術」に基づいた技術や生産は徴用ということになります。徴用は連鎖的で、一つの徴用は別の徴用に依存しています。工場は原材料や別の工場に依存していますし、できあがった商品は流通に依存します。また、徴用は人間自身に対しても行われています。「挑発してかり立てる」という言葉が非常によく表していますが、大してお金を持っていないのに欲望に抗えず条件反射的に不要な物を次々と消費していく現代人はまさしく「徴用」されています。特に広告業は直接的に人間から徴用する産業なので目立ちやすいですが、それ以外の様々な業界もエンドユーザーである消費者から徴用することで成り立っています。消費にかり立てるためには所得が必要なので、消費者は労働者としてもかり立てられ、より良い待遇を求めて就職市場で四苦八苦することになります。

すでにこの徴用の体系にガッチリと組み込まれてしまった人間は、搾取され続けるだけで一生を終えるほかないのでしょうか。これについてハイデガーは以下のように述べています。

> 顕現させることがたんに人間の作ったものではないとすれば、それはどこで、またいかにして生ずるのでしょうか。私たちは遠くまで探しに行く必要はありません。必要なのは、人間をつねにすでに要求してしまっている、かのものを、先入観にとらわれずに聞き取ることだけです。その要求の断固たるさまたるや、そのように要求された者であるかぎりでしか、そのつど人間は人間でありえないほどです。人間が自分の眼と耳を開き、自分の心を開き、努力に努力を重ね、造形化や作品化にはげみ、懇願と感謝を惜しみなくささげるところでは、どこであろうとあまねく人間はもう、隠れもなく真であるものへと自分が導かれていることに気づきます。その隠れもなく真であるものの隠れなき真相は、人間を呼び覚ましては人間にふさわしい顕現させるあり方をとらせるそのたびごとに、すでに出来事としておのずと本有化されているのです。現前的にあり続けるものを、隠れなき真相の内部で人間なりの仕方で顕現させるとき、人間が応答して語っている唯一の相手こそ、隠れなき真相の言い渡しにほかなりません。たとえ、人間がその言い渡しに反対して語るときでさえ、そうです。

つまり「人間が人間でありえ」るのは「自分の眼と耳を開き、自分の心を開き、努力に努力を重ね、造形化や作品化にはげみ、懇願と感謝を惜しみなくささげる」ときだけなのです。真摯に技術に向き合えば、徴用の体系に組み込まれてしまった現代人でも、単なる徴用ではない技術の一部となることができるような気がしてきます。これは技術者＝人間を元気づける文章のように感じました。人間はそもそも自然から「自然を探求する」ということを本能的にプログラムされていて、もとより自然から徴用されています。その本能に真摯に向き合いながらかり立てられるがままに探求すればより良い未来に到達しうるというビジョンが、この文章から感じ取れます。

プログラミングの世界でも、偉大なプログラマーはプログラミングジャンキーとでも形容すべき人びとで、起きている間はずっとプログラミングしています。仕事でプログラミングするのはもちろん、家に帰ってから寝るまでもプログラミングしているし、余暇もプログラミングをしています。そのような人は確かにかり立てられていると表現するのが正しいですし、そういう人が偉大な発明をしてきたと思います。芸術についてもきっと事情は似ていて、寝食を忘れて没頭できる人が優れた作品を産み出すのだろうと推測できます。

現代の高度に産業化した技術について、ハイデガーは両義的な評価をしているように思います。人間の制御の手を離れて自立したかのように見える搾取の体系は、それに飲み込まれるままでいれば人間を不幸にしそうですが、しかし搾取の体系が人間を何かに「かり立てる」ときに、敢えて本気で搾取されてみれば何か新しい未来が待っているのかもしれません。どのみち現代人は搾取されるほかないのだから、同じアホなら云々の理論で、前向きに積極的にかり立てられたほうが心の安定にも繋がりそうです。そのような前向きな現代人の好例の一つが、この数十年はプログラマーだったのではないかと思います。プログラマーは産業社会＝搾取の体系の結晶であるパソコンなくしては何もできません。プログラマーはまさに搾取の体系の先端に立って創造的な仕事を行う人びとでした。今後はAIを使って新しいことを考える人がそうなるのかもしれませんし、VR空間で何かを作る人がそうなるのかもしれません。技術に対して「身を開く」というのはそういうことなのではないかと、私は読みました。

業界に対して失望したり腐ったりせずに、新しい技術に興味を持ち続けることが大切だなと改めて感じました。

マルティン・ハイデガー『技術とは何だろうか』読書メモ２


\*nix系のターミナルでの作業に慣れている人だと、改行させたい場合にEnterキーじゃなくてCtrl+mを使う人が多いと思います。右手をEnterキーまで動かす必要が無いので作業が速くなるし楽です。

しかし、その感覚のままVSCodeのVim拡張を有効化して作業するとイラッと来るのが、挿入モード時のCtrl+mの挙動です。例えば、

```typescript
const hoge = {
```

まで書いてCtrl+mを押したら、以下のようになってほしいはずです。（インデントがスペース4個の場合）

```typescript
const hoge = {
    ■ // <-ここにカーソルが来てほしい
}
```

しかし、実際には以下のようになってしまいます。

```typescript
const hoge = {
■ // <- ここにカーソルが来てしまう
}
```

毎回Tabキーを押してインデントを合わせるのはだるいです。オートフォーマットがあるじゃないかと一瞬思いましたが、インデントのために毎回セーブするのもだるいです。

これを解決するために、Ctrl+mをEnterにマップしました。settings.jsonに以下のように書きます。

```json
{
    // ...省略
    "vim.insertModeKeyBindingsNonRecursive": [
        {
            "before": ["<C-m>"],
            "after": ["<Enter>"]
        }    
    ],
}
```

これでめでたく期待通りの動きをするようになりました。

ホストOSの方ですでにCtrl+mをEnterの挙動にマップしている場合はもしかしたら不要かもしれません。ホストOSのキーバインディングは、あまりいじるとアプリ固有のキーバインディングが食われるのであまりやりたくない派です。

VSCodeのVimでCtrl+mで改行したときにインデントがおかしい問題


[![](/blog-images/177-71AhdjbHJGL-729x1024.jpg)](https://amzn.asia/d/5yaT1RN)

ハイデガーの技術論の、新しい翻訳です。新しいと言っても、この本自体は2019年に出版されています。以前に平凡社ライブラリーから出ている『技術への問い』は読んだことがありましたが、こちらは日本語がかなりわかりやすく、大幅に読みやすくなっている気がします。かといって、訳者も言う通り「超訳」されているわけではなく、内容は普通に難しいです。

技術者として面白かったのは、因果の四原因について具体的に解説している箇所です。四原因とは物事が起こる原因を「質料因」「形相因」「目的因」「作用因」の４つに分類する考え方です。大学の論理学の講義などでは、現在では「作用因」だけを考えればよく、特に「目的因」などというものは原因に含めないと教わるのですが、であればなぜ昔のギリシア人が目的因なるものを考えだしたのか不思議でした。ハイデガーによる具体例を聞くと納得できます。少し長くなりますが引用します。

> 銀は、それをもとに銀の皿が製造される原料です。銀は、このような素材（ヒュレー〔hylē〕）として、皿に関して、ともに責めを負っています。それをもとに皿が成り立っている原料が、皿にもたらされるのは、銀が責めを負うからであり、つまり銀のおかげです。しかし、お供え用の器具を引き起こした責めを負うのは、銀だけにとどまりません。銀が責めを負うことで引き起こされた当のものが、皿として現れるのは、皿という姿かたちにおいてであり、ブローチや指輪という姿かたちにおいてではありません。つまり、お供え用の器具は、皿らしいものの姿かたち（エイドス〔eidos〕）が同時に責めを負うことで引き起こされるのです。銀は、皿という姿かたちがそこに放ち入れられる原料であり、姿かたちは、銀色のものがそのように現れる形態であり、この両者が、それぞれの仕方で、お供え用の器具に関して、ともに責めを負っているのです。
> 
> しかしながら、お供え用の器具に関して、ともに責めを負っているものとしては、とりわけ三番目の要因がまだ残っています。これは、皿を予め限定して、奉納と供物の領域に配する要因です。これによって、その皿は限定されて、お供え用の器具という協会に囲われます。境界を限定するものは、物を終わらせます。この終わりでもって、ものは終止するのではなく、この終わりのほうから、物は、制作後にはできあがった完成品として始まるのです。この意味で終わらせるもの、完成させるもののことを、ギリシア語でテロス〔telos〕と言います。この語は、「目標」や「目的」と翻訳されることがあまりに多かったため、誤解されています。テロスは、お供え用の器具を引き起こした責めをともに負う素材および姿かたちを、引き起こした責めを負うのです。

つまり物事が引き起こされるからには人称的な主体が関わっているというようなケースが主に想定されていたのだと思います。これをWeb開発に置き換えると以下のように考えることができるのではないかと思います。

1.  質料因: インターネットのプロトコル、データベース、Webサーバー、Linux、TypeScript、ブラウザ、など。
2.  形相因: ブラウザとインターネットを使って使用できるアプリケーション。ブラウザから画面操作を行うことでショッピングができる。
3.  目的因: 実店舗に行くことなく、自宅にいながらにしてショッピングができるようにしたい。

このように対置していみると、それぞれが綺麗に「質料因＝技術選定」、「形相因＝基本設計」、「目的因＝要件定義」に対応していることがわかります。そこから先の詳細設計、実装、テスト、受け入れなどのレイヤーは残る一つの「作用因」にまとめることができそうです。

目的因はソフトウェア開発において最上流に位置するものだと考えることができます。それもそのはずで、ハイデガーの解説によれば「目的因」が示しているものは「目的」ではなくて「終わり」だからです。ソフトウェアをその最終形から考えれば、何を作るべきなのかが見えてきます。

形相因はどのような形で実現するかであり、基本設計だとか外部設計と言われる工程にあたると思われます。

質料因は何を使って実現するかであり、技術選定や技術検証と言われる工程にあたるのではないかと思います。

単にAが原因でBが起こった、というような純粋な因果関係のみを論じるのであれば作用因しか必要ありません。人を沢山投入したからソフトウェアが完成した、というような言い方しかできません。しかし前近代的な四原因説に敢えて戻って考えてみると意外にももっと複雑な背景が見えてくるかもしれません。そんなに人を投入しなければならない理由は何だったのか。バグを生みやすい言語を使っているから？　そもそも設計に問題があったから？　要件定義があいまいで無駄な機能を実装してしまったから？

ハイデガーのこの本についてはもう少し書きたいことがあるので、次の記事でも別の点について書いてみようと思います。

マルティン・ハイデガー『技術とは何だろうか』（森 一郎 編訳）読書メモ１


スティーブン・ブディアンスキー著『クルト・ゲーデル』を読みました。

![](/blog-images/170-4627082614.01.S001.LXXXXXXX.jpg)

[https://amzn.asia/d/5MKzTnw](https://amzn.asia/d/5MKzTnw)

タイトルの通りクルト・ゲーデルについて書かれた本で、評伝です。

ゲーデルについては有名な「不完全性定理」を証明した人物という知識しかありませんでした。なぜこの本を読もうと思ったかと言うと、コンピューターに関わって仕事をしている者としてアラン・チューリングのチューリングマシンと数学的に同じことを証明したと言われることも多いゲーデルの不完全性定理に単純に興味があったというのもありますが、定理についてはよく聞くものの人間としてのゲーデルについては全く何も知らなかったので、本屋で見かけて気になって購入しました。

本書は衝撃的なプロローグから始まります。晩年のゲーデルは天才としての名声を手に入れていながら精神は妄想に蝕まれており家族とも衝突していたといいます。最期には食事すらも拒否していたそうです。数学・論理学の天才というイメージからは遠いものがあります。

本書には人間としてのゲーデルが描かれています。二十代半ばという若さで数学・論理学・哲学上の二十世紀最大級の発見をした紛う方なき天才なのですが、その天才が他人から見たらどうでもいいようなことにクヨクヨ悩んだり陰謀論にハマってしまったりするのです。ナチズム吹き荒れる故郷オーストリアから逃れ出たアメリカでは、賃貸で入居した先の大家と言い争ったり、職場での立場や給料に悩んだりしています。晩年にはライプニッツの哲学に傾倒し、死後の世界を信じ、自身の健康については医師を全く信用せず自己判断で薬を服用していたようです。まるで定年退職後に突然暇になりYouTubeを観始めて陰謀論やネット右翼的言説に目覚めてしまった田舎のお父さんのようです。天才にも我々凡人と変わらない一面があったことがわかります。

ゲーデルの完璧主義の性格がよく現れている逸話があるので、引用します。ゲーデルがアメリカ市民権を得るための試験を受けるときの話です。

> その日が近づくにつれ、彼は地方行政の組織についてモルゲンシュテルンにしつこく質問し始めた。モルゲンシュテルンはこう回想している。
> 
> > 彼は特に自治区と町村の境界はどこにあるのか、私に教えてほしいと迫った。もちろんそんなことはまったく必要ないと説明したが、彼は耳を貸さなかった。……次は自治区議会がどうやって選ばれるのか、町村議会はどうか、市長は誰か、町村議会がどのように機能しているのかを知りたがった。そういうことを聞かれるかもしれないと思ったらしい。自分が住んでいる町のことを知らないとわかれば印象が悪くなる。
> > 
> > そんな質問は絶対にされない、質問はほとんど本当に形式的なもので、簡単に答えられる。せいぜいこの国の政府はどのようなものか、上級の裁判所は何と呼ばれているかといったことしか聞かれないと説得しようとした。
> > 
> > 何にせよ、彼は憲法の勉強を続けた。調べているうちに、困ったことにいくつかの内部矛盾を発見し、独裁者が完全に合法的にファシスト政権を樹立することは可能だと、かなり興奮気味に私に話した。私はそのようなことが起こる可能性はほとんどないと言った。たとえ彼の考えが正しかったとしてもあるわけがないし、彼が正しいとは思えなかった。しかし彼は頑として譲らなかったので、この点について何度も話し合った。私はトレントンの法廷での審査では、そのようなことを持ち出さないように説得し念を押し、アインシュタインにもそのことは話しておいた。彼はゲーデルがそんな考えを思いついたことにあきれ、やはりそのようなことをきにしたり、議論したりしないように告げた。

> 審査の当日、モルゲンシュテルンはゲーデルを車に乗せて、アインシュタインの家まで行き、三人でトレントンへ向かった。アインシュタインは、いつものようにいたずら心を起こして、後部座席のゲーデルに「さあ、ゲーデル君、この試験の準備は**_本当に_**万端かね？」と厳めしく問いかけた。これがまさにアインシュタインの狙いどおりの効果を発揮し、ゲーデルは一瞬パニックに陥った。
> 
> 法廷に入ってきたフォーマン判事はアインシュタインの来訪を喜び、著名な訪問者と少し話をしたのち、ゲーデルのほうを向き、訪ねた。
> 
> 「さてゲーデルさん、あなたの出身はどちらですか？」
> 
> 「私の出身ですか？　オーストリアです」
> 
> 「オーストリアの政府はどのようなものでしたか？」
> 
> 「共和制でしたが、憲法の不備により独裁制に変わってしまいました」ゲーデルは答えた。
> 
> 「それはとてもまずいですね」と判事は言った。「この国で当然そんなことはありえません」
> 
> 「いいえ、ありえます」とゲーデルは叫んだ。「私はそれを証明できます！」
> 
> フォーマン、アインシュタイン、モルゲンシュテルン三人がかりで、ゲーデルが自分の自慢のアイデアについて、それ以上は話をしないよう黙らせた。その後の式は何事もなく終了した。

また、ライプニッツに傾倒していることを友人に諌められた際のエピソードも面白いので紹介します。

> いつものことだが、彼の考えを変えさせることはできなかった。メンガーは一度それをやろうとしたことがあった。「君はライプニッツの側につくのと引き換えに迫害コンプレックスを負わされているんだ」とからかうように言い、ライプニッツの業績を台無しにしようとしているのは誰なのかと皮肉交じりに尋ねた。
> 
> 「もちろん、人間がもっと賢くなることを望まない人たちだ」とゲーデルは答えた。
> 
> それよりもむしろ、権力者がヴォルテールのような急進的な自由思想家の著作を破壊する可能性のほうが高いのではないかとメンガーは反論した。
> 
> するとゲーデルは、その反論を寄せつけない見事な論理で返した。「ヴォルテールの著作を読んで、もっと賢くなった人がいるか？」

彼が青春時代を過ごした時代のウィーンは色々な言語が飛び交う多国籍的な都市だったようです。学術的にも先端的な都市で、色々な天才が集まり、日夜大学やコーヒーサロンで議論をしたり勉強会を開いたりしていたようです。

結局、ナチズムと反ユダヤ主義の跋扈が原因で、天才たちはイギリスやアメリカに流出します。近年は学問の世界では英語で論文を書くのがスタンダードとなっていますが、言い換えれば英米が世界の学問を主導しているという状況なわけです。こういう状況を作ったのは、先端的な研究を「ユダヤ的」と言い迫害した、科学的に蒙昧で反知性主義的だったナチズムなのではないでしょうか。本書にも登場するゲーデル、フォン・ノイマンを始めとする数多の天才がアメリカにわたり、現代のコンピューターの理論的な基礎を作りました。アメリカがITの世界で未だに覇権を握っているのも納得できます。逆に言えば、ナチスが存在しなければ天才たちはオーストリア＝ハンガリーやドイツにとどまっていて、プログラミング言語はドイツ語をベースに作られていたのかもしれません。

現代ではロシアがナチスと同じようなことを行っています。ロシアからはエリート層が脱出しているというニュースも聞いたことがありますが、そうすると優秀な頭脳はますます英米圏に集中することになります。仮に中国がロシアに融和的な態度を崩さない場合、中国の優秀な頭脳も流出する可能性があります。ITの世界では優秀な頭脳こそが新しい技術を開発しおカネを動かします。日本でビジネスを行う人々も、引き続き優秀な頭脳が世界のどこに集まっているのか注意してみておく必要がありそうです。

スティーブン・ブディアンスキー著『クルト・ゲーデル』読書メモ


![](/blog-images/160-picture_large978-4-87311-565-8.jpeg)

[https://amzn.asia/d/7vOWxeZ](https://amzn.asia/d/7vOWxeZ)

私はプログラミングを始めてしばらく経ちますが、今更『リーダブルコード』を読みました。新人におすすめされることが多い本なのですが、評判の通り新人に知っておいて欲しいことが多く載っていました。

反面、現役のプログラマーとして仕事をしている人が読むとちょっと今更感が漂う知見が多いかもしれません。邦訳が出版されて10年以上経っていますので、当時はまだ常識じゃなかったプラクティスが今では常識になってしまっているというのもあるかもしれません。変数を使わず再代入不可な定数を使おうというアイデアなどは、関数型言語が流行ってJavaScriptにconstが導入された今ではみんな当たり前にやってることになった感があります。

とはいえ、読んで全く無駄だったのかというとそんなことはありません。ためになることもたくさんあり、中でも豆知識的なやつで覚えておきたいものが何個かあったのでメモ代わりにブログに残しておくことにします。

# Getは使うな

APIからデータを取得する処理とかを書いているときに、思わず `getData()`とかいうメソッドを定義してしまいがちです。しかしこの本では get〇〇 はやめろと書いてあります。getでは意味が広すぎる上に、アクセサの接頭辞としても使われることが多いからです。こういう場合は `fetchData()`とかのほうが適しているということになります。

同様に、sizeという単語も意味が曖昧すぎて避けるべきということになります。せめて何のサイズなのかとか、単位は何なのかとかも明らかにしたほうが良さそうです。例えば `sizeKB()`とかになるでしょうか。

# 以上・以下はminとmaxで表現する

変数名で値の範囲を表現したい場合に、例えば1以上10以下という境界値を含む場合は、minとmaxを使えば表現できます。startとstopとかfromとtoとかだと曖昧ですが、minとmaxなら境界値を含むということがはっきりわかります。

似たような考え方として、リストがあったとしてリストからある範囲のサブセットを取り出したいときに関数の引数名として何が適切かというと、firstとlastだとわかりやすいみたいです。これもstart・stopとかfrom・toのペアだと曖昧ですが、firstとlastならそれら自身を含むサブセットを返すということがはっきりわかります。

# 名前付き引数が使えない言語で名前付き引数みたいなことをやる方法

今どき名前付き引数が使えない言語とか使いたくないわけですが、巨大企業の作った某言語とかでは名前付き引数を使った関数呼び出しができません。そんなときどうするかと言えば、以下のような書き方をすると良いみたいです。

```go
func hoge(x int, y int) int {
	return x + y
}

h := hoge(/* x = */ 1, /* y = */ 2)
```

ちょっと独特な書き方で読みづらいし、docコメント書けば良いだけの話かもしれませんが、慣れたらいい感じなのかもしれません。

## ２つの範囲に重複部分があるかどうかを判定する方法

例えば、{1, 2, 3, 4} という配列と、{3, 4, 5, 6} というような配列があった場合、２つの配列の中に重複部分があるかどうかをプログラムで判定したくなったとします。どういうコードを書けばいいかというと、それぞれの始点と終点を使って判定するのが良さそうなのですが、何も考えずに実装すると読みづらいコードになります。

```javascript
const list1 = [1, 2, 3, 4];
const list2 = [3, 4, 5, 6];

function areOverlapped(list1, list2) {
  const list1_first = list1[0];
  const list1_last = list1[list1.length - 1];
  const list2_first = list2[0];
  const list2_last = list2[list2.length - 1];

  // list1の始点がlist2の始点と終点の間にある場合
  if (list1_first >= list2_first && list1_first <= list2_last) {
    return true;
  }

  // list1の終点がlist2の始点と終点の間にある場合
　if (list1_last >= list2_first && list1_last <= list2_last) {
    return true;
  }

  // list2についても同様の判定...

  // どの条件にも合致しなかった場合
  return false;
}

console.log(areOverlapped(list1, list2));
```

しかしこのコードは下記のような単純なコードに書き換え可能です。

```javascript
const list1 = [1, 2, 3, 4];
const list2 = [3, 4, 5, 6];

function areOverlapped(list1, list2) {
  const list1_first = list1[0];
  const list1_last = list1[list1.length - 1];
  const list2_first = list2[0];
  const list2_last = list2[list2.length - 1];

  // 一方の始点が他方の終点より後にある場合は重複しない
  if (list1_first > list2_last) return false;
  if (list1_last < list2_first) return false;

  // それ以外の場合は必ず重複部分がある
  return true;
}

console.log(areOverlapped(list1, list2));
```

これは日付範囲の比較とかでよく使うロジックです。管理画面を作ることが多い人なら一度は作ったことがあるのではないでしょうか。ゴリゴリ書くよりも一度図などを書いて原理的に考えてコードを書いたほうがシンプルになる良い例だと思いました。

## 読みやすいテストコードを書く

個人的に一番盲点だったのがこれで、テストコードは読みづらくてナンボだと思っていました。なぜなら、関数定義や制御構造の入った読みやすいテストコードを書くことによって、「テストコードのテスト」が必要になってしまうからです。配列で入ってきた入力値と期待値のセットを、インデックスもベタ書きで一個一個検証していくのが正義だという考えのもと、1000行近くあるほとんどCSVファイルみたいなテストコードを書いたこともあります。

しかし、言われてみれば読みづらいテストコードには以下のデメリットがあります。

*   テストコードで何をやっているかわからないので、テストが書かれなくなる
*   テストコードを触るのが怖くなり、テストがメンテされなくなる
*   間違ったテストコードが追加されることにより、テストの意味がなくなる

場合によっては「テストコードのテスト」を書いてでもテストを読みやすくしたほうが良いかもしれません。今度から実践してみようと思います。

## 『リーダブルコード』は新人におすすめか？

この本は新人におすすめされることが多く、実際新人に知っといて欲しいことがたくさん書いてあるのですが、いざ新人がこれを読んだからといって書いてあることをすぐ体得できるわけでもないし、そもそもなぜこういう書き方をしないといけないのか理解できないのでは？　と思いました。

なぜ読みやすいコードを書くべきかは、書いた人間（すでにプロジェクトからいなくなってる）を呪いたくなるような思いとともに複雑に絡まりあったどこを触っても壊れるようなコードと戦った経験がないと身にしみてわかることはないのではないかと思います。

そういった意味で本書はおっさんプログラマーが「あるある」と深く頷きながら溜飲を下げるための本なのではないかと思いました。新人プログラマーにこれをおすすめするのは一種の無意味なマウンティングかもしれないと言ったら言いすぎかもですが、なぜ読みやすいコードを書かねばならないのかは現場で一緒にク○コードを読みながら教えるのが一番だと思います。

『リーダブルコード』の豆知識拾い


プロジェクトが炎上し始める兆候には色々あると思うのですが、今回あらためて気づいた点があるので書いておこうと思います。

プログラマーとしてプロジェクトに関わっていると、ある日PM（＝プロジェクトマネージャー≠プロダクトマネージャー）が「現在着手しているタスクの進捗状況を箇条書きにして報告してください。何％進んでいて、いつまでに完了するかを数字で教えて下さい」と言ってくることがあります。

プログラマーとしては若干「めんど」と思いながらも、コードを書く手を止めてチャット欄に報告事項をまとめ始めるわけですが、これはよく考えたらおかしなことで、PMというのはプロジェクト全体のタスク状況をそもそも把握しているはずです。でなければプログラマーに次の作業の依頼をしたり、プロダクトオーナーに報告したりということができないし、状況を把握した上でプログラマーに対し「このタスクはどうなっていますか？　大丈夫ですか？」と突っつくのが仕事なわけです。

さらに、プログラマー自身に進捗をまとめさせることの問題は、プログラマーが上げてくる報告が主観に過ぎないという点にもあります。「もう90%できているので、明日にはプルリクができます」と良いながら２日、３日、一週間と過ぎていくのはあるあるです。プログラマー自身に悪気はなく、本当に予想もできなかったハマりどころのせいであと10%がなかなか完成しないということもあります。PMは、そういう状況を外から客観的に見て「これはもうしばらくかかりそうだな」という判断を早めにしなければなりません。

なんでPMは「状況をまとめろ」と言ってくるのでしょうか。端的に言えば、楽をしたいからです。状況を把握するのはそれなりに骨が折れる仕事です。集中力が要ります。その作業をプログラマー自身にオフロードすることで自分の負荷を下げたいわけです。

単純にPMが怠け者だったり性格が悪い人間である場合もあるでしょう。しかし、怠け者でない勤勉なPMがそういうことを言い出した場合は、PMの処理能力を超える負荷がかかってきているということの徴（しるし）だと思われます。

PMの処理能力が限界を超えるとどうなるでしょうか。まず、PMがプロジェクトの状況を把握できなくなります。PMの預かり知らぬところで機能が実装され、マージされ、デプロイされます。リリースされた機能にバグがあった場合、そのバグの原因となった機能がいつ誰によって作られ、誰に修正依頼をすれば良いのかわからなくなります。その都度関係者に訪ね歩き、どうテストしたら良いのかもよくわからずに雰囲気で修正をリリースします。テストの観点が不十分なのでデグレが混入し、また同じことを繰り返します。

また、関係者からPMへの依頼がどんどんとキューに積まれていきます。依頼したことが開発チームに認識されるまで一ヶ月かかるようになります。キューだったはずなのにスタックみたいに依頼事項がLIFOで処理され出します。当然最初に依頼した人は不機嫌になり、チーム内に不信感が生まれます。悪い雰囲気は蔓延し、一人また一人とチームを去っていきます。足りなくなった人手を補充するために高値掴みも厭わず新しい人を入れるのですが、根本的な問題が解決していないので新しいメンバーは自分のことを「火消しで投入されたのだな」と認識します。なんとか消火活動は成功しますが、火が消えた段階で「火消し屋」もチームを去ります。そうこうしているうちに順調に資金が底をつき、めでたくゲームオーバーとなります。

PMとはプロジェクトの消化器官のようなものだなあと思います。ビジネスサイドがユーザーからの要求を「食べ」て、PMが「消化」して、プログラマーが「吸収」して現実のプロダクト＝「身体」が成長します。消化器官が疲弊すると、食べ物を受け付けず、栄養を吸収できず、プロダクトは停滞します。それどころか、ユーザーの要望を食べ続けなければプロダクトがユーザーのニーズを満たせなくなり、どんどん身体はやせ細っていき、プロダクトは死を迎えます。

伝統的な受託システムインテグレーション企業では、プログラマー1人に対しPM5人というような、プログラマーの人数に比して異常なほどPMを補充することでこの問題を乗り切ろうとします。これは明らかにバランスが悪いため費用対効果が低く、ビジネスサイドから入ってくる要望を過剰に解釈することで誰も使わない機能がリリースされてしまいます。人間の身体に例えれば脂肪が付きすぎた状態と言えそうです。

スタートアップではビジネスに共感するメンバーのみを集めることで「全員PM」のような状態を作り出そうとします。全員が自発的にプロジェクトの状況を把握することで単一障害点を無くそうと言うわけです。しかしこれは夢物語であり、現実問題としてそのような外観は誰かの犠牲の上に成り立っています。それで楽ができるのは役員だけで、実際にはPM業を中心的に担わされている人物が必ずいます。「リーン」と言えば聞こえは良いですが、弱りきった胃腸では満足に機能をリリースできません。下痢を繰り返している痩せ型人間と同じです。

プロダクトが本当に欲しかった筋肉質な身体を作るにはどうすれば良いのでしょうか。人間と同様に「胃腸を健康に保つ」ことが大事だと思われます。PMの負荷を下げ、必要ならアシスタントを付けたいところです。

PMの負荷が高まるのは関係者が増えすぎてコミュニケーションのオーバーヘッドが発生しているからだと推測できるので、チームのメンバーを減らすというのもある程度有効だと思います。少ないメンバーで生産性を維持するためには、優秀なメンバー（プログラマー）で布陣を固める必要があります。

プログラマーも人間の身体に例えるなら、この場合は腸内細菌ということになろうかと思います。少数精鋭のプログラマーを雇用することは、腸内フローラを整えることと似ています。この場合の「悪玉菌」は「ダメなコードを書くプログラマー」と言えそうです。

結論としては、ダメなコードを書くプログラマーをチームから減らすというのが解決策になるんじゃないかなと思います。単にチームから追放するのではなく、ダメなコードを書くプログラマーに成長する機会を与えるチームであるのが理想ですが、そうも言っていられない懐事情もあると思われますので実際にはダメなコードを書くプログラマーにクビを宣告することになるんじゃないかなと思います。悲しい話ではありますが。

プロジェクトが炎上し始める兆候について


最近スタートアップと言われるような企業に務めている人でもソフトウェア開発で必要になる大体の全工程を把握してないことが多いということに気づきました。こういうのは案外SIで働いていた人とかはしっかり把握していたりします。スタートアップだと深いことは何も考えずに横文字のかっこよさげな単語とかPMFだかPSFだかの略称を連呼することでプロジェクトのヤバさを糊塗しようとする傾向にある気がします。スタートアップだと出資者に対して如何にプロジェクトがいい感じであるかという外観を装うことが重要なのでそのようになるのかもしれませんが、非常に危ういなと思います。

そこで今日は簡単にソフトウェア製品開発（特にWeb）で必要になる全工程をざっくり箇条書きしてみたいと思います。ビジネスサイドではなく、あくまで開発者目線です。

## 提案

まずはいきなり提案から始まります。ビジネスサイドの人（受託開発の場合は顧客）は、「技術のことはわからんからいい感じの提案をくれ」ということが多いです。提案をするにしても材料がなければ提案できませんので、やりたいことや欲しいもの、困っていることなどを聞き出すことが大事になります。

大体の雰囲気がつかめたら、「こういうのが欲しいんですよね？」といった要求事項をまとめた提案資料をつくります。

## 要求の聞き出し

提案資料をベースに要求を一つ一つ洗い出していきます。提案資料というたたき台があるとビジネスの人もあれが欲しいこれが欲しいという意見を具体的に述べてくれるようになります。それらの要求を箇条書きにして整理します。

## 要求から要件を書き起こす（要件定義）

要求を聞きだしたら、それを要件として書き起こします。例えば「日記が書ける機能がほしい」という要求があったら、「日記の作成画面、編集画面、プレビュー画面、一覧画面が必要」といった要件として書き起こせます。要件の段階では画面単位だったり機能のまとまり単位でざっくり書き出すだけでだいたいOKです。

上記は「機能要件」と言われるものですが、「非機能要件」も必要になります。ただ非機能要件はもっと後のフェーズで定義することが多いです。なぜなら作りたいものの解像度がこの段階では低すぎて、非機能要件まで決められないからです。

## 基本設計

現場によっては論理設計と言ったり外部設計と言ったりして、あまり統一されているわけではありません。またその詳細度も現場によって違います。論理設計の段階でデータの属性やフローチャートまで決めてしまう場合もあります。

ただ、通常はこの段階ではサーバー構成や大まかなデータの流れを決めることが多いです。ミドルウェアに何を使うかとかもこの段階で大体決めます。やりたいことの技術検証などもこの段階で行います。

なのでインフラの人とかは別に優秀な人でなくてもこの段階から割と仕事があって、上流に食い込めたりします。

## 詳細設計

現場によっては物理設計と言ったり内部設計と言ったりします。いわゆる「仕様書」を作り始めるのがこの段階です。最近のスタートアップ的な開発だと仕様書なんてないのではと思われるかもしれませんが、Figmaとかで作られたモックが仕様書にあたるのではないかと思います。「何を作るべきか」がはっきりしてないと何も作れないという点はウォーターフォールもアジャイルも同じです。ただ「詳細設計→実装」のサイクルの長短が違います。

SIの現場ではこの段階で一番エンジニアの工数を使います。なぜなら仕様書には責任が詰まっているからです。仕様書がマズかったりすると顧客の要求を満たせないソフトウェアを作ったということになり、最悪お金がもらえなくなったりします。にもかかわらず仕様書通りに作ってくれたプログラマにはきちんとお金を払わなくてはなりません。仕様書を作って、顧客やプログラマと一緒にレビューして、みんなが満場一致でOKを出してから（＝みんなの責任）実装に取り掛かります。

現実にはそこまで頑張って合意したにも関わらず仕様は覆ります。そして責任のなすりつけ合いが始まります。

## 実装

現場によっては開発と言ったり製造と言ったりします。手を動かして実際に動くものを作っていく段階です。並行してインフラの構築や周辺ツールの導入も行います。PMの人はこの期間中にビジネス側の要求がひっくり返ったりしないように気を使わないといけません。それができないPMはPM失格です。PMの仕事はそこに尽きると言っても過言ではありません。できなければプログラマからの信頼を失います。

この段階ではよくスケジュール管理とか工数見積の話が出てきますが、正直言って正確な工数見積もりは不可能です。不可能だと割り切って見積もったほうが建設的なので、直感的に「これくらいかな？」と思った工数の3倍を見積もり工数とするのを心がけるのが良いと思います。盛りに盛った3倍の工数をビジネス側に言うのは案外勇気が必要だったりしますが、結果的にそうなることがほとんどなので理解してもらうしかありません。

## テスト

試験と言うことも多いです。テストの中にもいくつか段階があって、代表的なのは

*   単体テスト
*   結合テスト
*   総合テスト
*   受け入れテスト

とかじゃないかなと思います。テストも現場によって何を指すかが大きく違ってたりするので、臨機応変に言葉を使うのがいんじゃないかなと思います。

一般的には単体テストはスプレッドシートに細かく手順と期待値を書いて、「〇〇ボタンを押したら〇〇に遷移」みたいな細かい挙動を確認するやつです。結合テストはクライアント・サーバー間の連携や、外部サーバーとの連携とかを含めて確認します。総合テストはユースケースに則ったシナリオを作成してテストします。受け入れテストは実際のユーザーに使ってもらってテストするやつで業務アプリとかで多いです。

ようやくこの段階で非機能要件が定義できるようになることも多く、同時接続数とかレスポンスタイムとかバックアップとかセキュリティとかの話を詰めていきます。

非機能要件が決まったら、障害時を想定した復旧試験（最低一回はやっといたほうがいい）とか、性能テストをやります。おカネがあるプロジェクトでは外部のWAFとかを入れてセキュリティを担保しますが、そのせいで本番環境だけ機能が動かなくなるなどという椿事が発生するのもあるあるです。

## リリース・運用・次のフェーズ

リリース時は夜まで待機みたいなことも結構あると思います。リリース直後の障害は起こるものと考えたほうがよいと思います。そのへんの障害対応の体制は予め組んでおいたほうがチーム内に余計な禍根を残さずに済みます。PMはそのへんをちゃんとやりましょう。

運用に移っていくとチームからどんどん人が抜けます。そこでサクッと抜けてまた新しいプロジェクトに行ければエンジニアとしては飽きなくて良いのですが、運用にある程度長く付き合うのもそれはそれで知見を得られます。特にバッチ処理関連とかパフォーマンスチューニングとか監視とかについての経験は一つの製品に長く付き合うことでしか得られないことが多いです。

次のフェーズが決まってるプロジェクトなら粛々と機能開発を続けていくことになります。新機能単位で「要件定義→仕様作成→実装→テスト」のサイクルを回します。

## 終わりに

スタートアップで働くことになったはいいが、実は手を動かすプログラマとしての経験しかなく、雰囲気でプロジェクトを進めてるという人もたくさんいると思います。そういう人はCTOだのテックリードだのとかっこいい肩書を考える前に、謙虚になって一度開発工程の全体像を把握しとくと良いのではないかと思いました。

ソフトウェア製品を開発する上での一連の流れについて


めちゃくちゃ初歩的な話だと思うんですが最近改めて理解したことがあるので記事にします。

Rust の公式解説書な存在である The Rust Programming Language のチャプター17の3章には途中に演習問題が用意されています。

その章では簡単なブログ投稿ロジックもどきを作成するのですが、一通り作った後に機能追加の問題めいたものが出題されます。

[https://doc.rust-lang.org/stable/book/ch17-03-oo-design-patterns.html#trade-offs-of-the-state-pattern](https://doc.rust-lang.org/stable/book/ch17-03-oo-design-patterns.html#trade-offs-of-the-state-pattern)

> *   Add a `reject` method that changes the post’s state from `PendingReview` back to `Draft`.
> *   Require two calls to `approve` before the state can be changed to `Published`.
> *   Allow users to add text content only when a post is in the `Draft` state. Hint: have the state object responsible for what might change about the content but not responsible for modifying the `Post`.

> *   記事の状態を`PendingReview`から`Draft`に戻す`reject`メソッドを追加する。
> *   状態が`Published`に変化させられる前に`approve`を2回呼び出す必要があるようにする。
> *   記事が`Draft`状態の時のみテキスト内容をユーザが追加できるようにする。 ヒント: ステートオブジェクトに内容について変わる可能性のあるものの責任を持たせつつも、 `Post`を変更することには責任を持たせない。
> 
> 翻訳は非公式日本語訳版より [https://doc.rust-jp.rs/book-ja/ch17-03-oo-design-patterns.html#%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%E3%81%AE%E4%BB%A3%E5%84%9F](https://doc.rust-jp.rs/book-ja/ch17-03-oo-design-patterns.html#%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%E3%81%AE%E4%BB%A3%E5%84%9F)

この問題について本の中では具体的な正解が書かれていません。なのでフォーラムでも話題になっていたようです。

[https://users.rust-lang.org/t/asking-for-help-with-chapter-17-3-in-the-book/48295](https://users.rust-lang.org/t/asking-for-help-with-chapter-17-3-in-the-book/48295)

最初の２つの機能追加は割と簡単なのですが、３つ目を実装しようとするとハマる人はハマるようです（私もそうです）。

ヒントに「 `have the state object responsible for what might change about the content but not responsible for modifying the <code>Post`.」とあるのでcontentだけを変更してPostのstate自体は変えないようにすれば良いのかなと思い、最初に以下のように書いてみました。

```rust
impl Post {
    // snip
    pub fn add_text(&mut self, text: &str) {
        let text = self.state.as_ref().unwrap().add_text(text);
        self.content.push_str(text);
    }
}

trait State: std::fmt::Debug {
    // snip
    fn add_text(self: Box<Self>, text: &str) -> &str {
        ""
    }
}

// Draft のときだけ content に文字列を追加する
impl State for Draft {
    // snip
    fn add_text(self: Box<Self>, text: &str) -> &str {
        text
    }
}
```

しかし、これだと以下のようなコンパイルエラーが出ます。

```
error[E0507]: cannot move out of a shared reference
  --> src/lib.rs:15:20
   |
15 |         let text = self.state.as_ref().unwrap().add_text(text);
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--------------
   |                    |                            |
   |                    |                            value moved due to this method call
   |                    move occurs because value has type `Box<dyn State>`, which does not implement the `Copy` trait
   |
note: this function takes ownership of the receiver `self`, which moves value
  --> src/lib.rs:52:17
   |
52 |     fn add_text(self: Box<Self>, text: &str) -> &str {
   |                 ^^^^

For more information about this error, try `rustc --explain E0507`.
```

Post のほうの add\_text で state のメソッドを呼ぶことはできないらしいということで、色々悩んだ結果以下のように修正すると動くことは動きました。

```rust
impl Post {
    // snip
    pub fn add_text(&mut self, text: &str) {
        if let Some(s) = self.state.take() {
            self.state = Some(s.add_text(self, text));
        }
    }
}

trait State: std::fmt::Debug {
    // snip
    fn add_text(self: Box<Self>, post: &mut Post, text: &str) -> Box<dyn State>;
}

impl State for Draft {
    // snip
    fn add_text(self: Box<Self>, post: &mut Post, text: &str) -> Box<dyn State> {
        post.content.push_str(text);
        self
    }
}

impl State for PendingReview {
    // snip
    fn add_text(self: Box<Self>, post: &mut Post, text: &str) -> Box<dyn State> {
        self
    }
}

impl State for Published {
    // snip
    fn add_text(self: Box<Self>, post: &mut Post, text: &str) -> Box<dyn State> {
        self
    }
}
```

しかしこれだと「`not responsible for modifying the <code>Post`」を満たしていないような気がします。add\_text で state を変更する必要は全く無いにも関わらず、`self.state.take()` をしてわざわざ state を一度 None に変えて代入し直しています。その上 dyn State は何が入ってくるか実行時までわからないので安全性のために State を実装している Struct は Trait 側のデフォルト実装ではなく必ず自分自身の具体的な add\_text を実装しておく必要があります。

色々とコードをいじってみた結果、最初の `cannot move out of a shared reference` がなんで発生していたのかわかりました。初歩的な話なのですが、State 側の add\_text の引数 self が `&` 無しになっているからです。この書き方だと、self 自体を他のインスタンスに作り変えてしまうメソッドであるべきということになります。

> Having a method that takes ownership of the instance by using just `self` as the first parameter is rare; this technique is usually used when the method transforms `self` into something else and you want to prevent the caller from using the original instance after the transformation.
> 
> [https://doc.rust-lang.org/stable/book/ch05-03-method-syntax.html#defining-methods](https://doc.rust-lang.org/stable/book/ch05-03-method-syntax.html#defining-methods)

そのため、必然的に所有権はそのメソッドに移動してしまうということのようです。

修正の方針としては、State 側の add\_text 呼び出し時に自身の mutable reference を使わないようにすれば良いということになります。

```rust
impl Post {
    // snip
    pub fn add_text(&mut self, text: &str) {
        let text = self.state.as_ref().unwrap().add_text(text);
        self.content.push_str(text);
    }
}

trait State: std::fmt::Debug {
    // snip

    // 参照の引数が２つなのでスコープを付ける必要がある
    fn add_text<'a>(&self, _text: &'a str) -> &'a str {
        ""
    }
}

impl State for Draft {
    // snip
    fn add_text<'a>(&self, text: &'a str) -> &'a str {
        text
    }
}
```

これで元々やりたかったことができたし、コードの重複も減らせました。

色々とコードを弄りながら調べていくうちに、他にも気づいたことがありました。Box<T> の性質についてです。Box<T> について解説している章を改めて読み直すと、Box<T> を使うのは以下のような場合だと書いてあります。

> *   When you have a type whose size can’t be known at compile time and you want to use a value of that type in a context that requires an exact size
> *   When you have a large amount of data and you want to transfer ownership but ensure the data won’t be copied when you do so
> *   When you want to own a value and you care only that it’s a type that implements a particular trait rather than being of a specific type
> 
> [https://doc.rust-lang.org/stable/book/ch15-01-box.html#using-boxt-to-point-to-data-on-the-heap](https://doc.rust-lang.org/stable/book/ch15-01-box.html#using-boxt-to-point-to-data-on-the-heap)

２つ目の記述に、「you want to transfer onwership」とあります。Box<T>はスタックじゃなくてヒープにデータを保存してそれを参照する、という漠然とした理解をしていましたが、動きとしては take ownership な感じになるというのも覚えといたほうが良さそうです。

そもそも Box<T> や Rc<T> について概説した Smart Pointers についての記述でも以下のようにありました。

> Rust, with its concept of ownership and borrowing, has an additional difference between references and smart pointers: while references only borrow data, in many cases, smart pointers _own_ the data they point to.
> 
> [https://doc.rust-lang.org/stable/book/ch15-00-smart-pointers.html#smart-pointers](https://doc.rust-lang.org/stable/book/ch15-00-smart-pointers.html#smart-pointers)

このあたり難しいので何回も読み直すことになりそうです。復習は大事ですね。

Rust の the book の17.3の演習の解答例とBox<T>が mutable reference であること


dyn Trait に derive(Debug) する方法がわからなかったので調べました。普通にTraitを実装したStructとかに derive(Debug) しても実際に `println!("{:?}", struct)`とか書くとエラーになってしまうようです。

以下のリンク先が参考になりました。

[https://stackoverflow.com/questions/64298436/how-to-get-an-implementation-of-fmtdebug-for-a-vec-of-dyn-trait-objects](https://stackoverflow.com/questions/64298436/how-to-get-an-implementation-of-fmtdebug-for-a-vec-of-dyn-trait-objects)

以下のようにしたらコンパイルが通ってデバッグ出力できるようになりました。

```rust
trait State: std::fmt::Debug {
  // 省略
}

// ↓↓↓dyn State で入る可能性のあるstructたち

#[derive(Debug)]
struct Draft {
  // 省略
}

#[derive(Debug)]
struct PendingReview {
  // 省略
}

#[derive(Debug)]
struct Published {
  // 省略
}
```

どんなに勉強しても Rust がわかる気がしませんが、がんばります。

Rustでdyn Traitにderive(Debug)をつける方法


LaravelのEloquentの機能だけでは実現できないSQLクエリを書きたい場合に、サブクエリを使ったりすると思います。

```php
$sub = Hoge::select(['fuga_id', 'piyo'])
    ->複雑なフィルター();

$subRaw = Str::replaceArray('?', $sub->getBindings(), $sub->toSql());

DB::from("foo, ({$subRaw}) as hoge")
    ->where('foo.fuga_id', 'hoge.fuga_id')
    ->update(['foo.bar' => 3]);
```

そんなとき、以下のような謎のエラーに遭遇することがあります。

```
Invalid datetime format: 1292 Truncated incorrect DECIMAL value: 'hoge.fuga_id'
```

これは where() の２個目の引数にテーブル名カラム名を文字列として使っているのが原因です。Laravelのクエリビルダーは２個目の引数をそのまま値として（’hoge.fuga\_id’ という文字列として） `foo.fuga_id` と比較しようとするので、型が違うので怒られているという感じです。

直すには以下のように `DB::raw()` を使います。

```php
DB::from("foo, ({$subRaw}) as hoge")
    ->where('foo.fuga_id', DB::raw('hoge.fuga_id'))
    ->update(['foo.bar' => 3]);
```

LaravelでDB::raw使ったWhere句


tmuxを使って複数のプロジェクトのセッションを開きっぱなしにしていると、いつの間にか新しいターミナルを開いたときの初期ディレクトリが変な場所で固定されてしまうことがあります。

これの戻し方を毎度毎度ググっているのでここに書いておこうと思います。

## :attach -c /path/to/dir

上記がコマンドです。詳しくは下記が参考になりました。

[https://unix.stackexchange.com/questions/268386/how-to-change-default-new-window-directory-from-within-the-tmux](https://unix.stackexchange.com/questions/268386/how-to-change-default-new-window-directory-from-within-the-tmux)

なので、`:attach -c ~` とかやれば初期ディレクトリをホームに戻すことができます。

tmuxの初期ディレクトリが変なところに固定されてしまった場合の戻し方


GitHub Actions の set-output というコマンドが非推奨になりました。

[記事](https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ "記事")

上記にも書いてありますが、今まで

```yaml
- name: Set output
  run: echo "::set-output name={name}::{value}"
```

というふうに書いていたのですが、以下のような書き方に変えないと将来的に動かなくなるらしいです。

```yaml
- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT
```

変数に入れる方法が変わってるのが罠で、気づかずに以下のような書き方をしていて正しく動いていませんでした。

```yaml
- name: Set output
  id: hoge
  run: echo "name=hoge::fuga" >> $GITHUB_OUTPUT
```

使うときは今まで同じように、${{ steps.hoge.outputs.hoge }} みたいな感じで取得できます。

GitHub Actions 出てきた直後とかすごい流行ったけどイマイチなぜ流行ったのかわかりません。使い心地はTravisとかCircleCIとかと変わらない気が、、、タダで使えるものにとりあえずタダ乗りしたという感じなのでしょうか。

GitHub Actions の set-output がdeprecated になった件


Vue3のプロジェクトを作成して、そのままだとコマンドラインで `npm run lint` しないとできませんでした。

VSCode側の `editor.formatOnSave` ってやつもあるんですが、そっちで自動フォーマットするとVueのほうで設定してある ESLint とは違った形でフォーマットされてしまいます。

頑張ってかなりググった結果、以下のようにVSCodeのsetting.jsonを書けば実現できました。

```json
{
  "editor.codeActionsOnSave": {
    "source.fixAll": true,
  },
}
```

[https://www.digitalocean.com/community/tutorials/workflow-auto-eslinting](https://www.digitalocean.com/community/tutorials/workflow-auto-eslinting)

この辺の設定、ぐぐると昔の記事がたくさん出てきて、ことごとく現在の設定方法と異なっているので地味に時間かかりました。

Vue3でVSCodeのformatOnSaveみたいなのをESLintの設定でやる


ワクワクしながらVue3プロジェクトを作って`src/components/__tests__`フォルダを除くと`HelloWorld.vue`なるファイルがあります。それを開くと赤い波線が見えます。

[![](/blog-images/99.png)](/blog-images/99.png)

ムカつくので消したいのですが、色々試しても消えません。ググったらstackoverflowのページを見つけました。

[https://stackoverflow.com/questions/54839057/vscode-showing-cannot-find-module-ts-error-for-vue-import-while-compiling-doe](https://stackoverflow.com/questions/54839057/vscode-showing-cannot-find-module-ts-error-for-vue-import-while-compiling-doe)

`tsconfig.json`を編集しろというトップの回答はなんかちょっと違うっぽい感じがしたので二個目の回答を見ると、以下のような `src/shims-vue.d.ts`というファイルを作れと書いてあります。

```typescript
declare module "*.vue";
```

すると赤い波線は消えました。TypeScriptの機能で `declare module '*.yaml'` とかやるとyamlファイルが（見かけ上は）普通にロードできてるかのような感じになるあれですね。

[https://typescript-jp.gitbook.io/deep-dive/project/modules/external-modules#nowokisuru](https://typescript-jp.gitbook.io/deep-dive/project/modules/external-modules#nowokisuru)


Vue3の.spec.tsファイル内のimportがVSCode上でエラー出してる場合


最近 find コマンドを使う機会がめっきり減りました。多分VSCodeで作業することが多くなったからだと思いますが、ビルドスクリプトをシコシコ書いているときなどにはやっぱりfindコマンドを使います。

久々にfindコマンドを使っていて、アスタリスクを含む文字列を -name オプションに付けたら以下のようなエラーが出ました。

```
$ find . -name *ts 
find: env.d.ts: unknown primary or operator
```

は？と思いましたが、以下のように実行すれば期待通りの結果が帰ってきます。

```
$ find . -name '*ts'
```

そういえばこういうのあったな〜と思いつつも、なぜ引用符が必要なのか気になったのでググりました。考えてみれば当たり前のことですが、どうやらシェル（bashやzshなど）が先にアスタリスクを展開して使ってしまうからのようです。つまり最初の例は以下のコマンドを最初に実行する形になってたものと思われます。（hoge.ts と fuga.ts はカレントディレクトリにあるファイル）

```
$ find . -name hoge.ts env.d.ts fuga.ts
```

シェルのほうの親切機能のせいで起こっていたエラーということですね。細かい挙動はシェルによって違ってきます。スクリプト書くときは引数には引用符つけるのをクセにしておくのが良さそうな感じです。

参考: [https://unix.stackexchange.com/questions/369419/when-and-why-do-i-need-to-quote-asterisks](https://unix.stackexchange.com/questions/369419/when-and-why-do-i-need-to-quote-asterisks)

findコマンドでアスタリスクを使うときに引用符でくくらないといけない理由


ちょっとおしゃれなホームページによくある、画面をスクロールして画像が画面の表示領域に入るとふわっと浮き上がるように表示されるエフェクトあると思います。

ああいうやつを実装したい場合、いわゆる「Web制作」界隈では jQuery を使っているようです。

ですがもちろん今日び jQuery など死んでも使いたくありません。試してみたら素のHTML/CSS/JSでも簡単にそれっぽいものが実装できました。ふわっと出てくるやつは画像に限るわけでもありませんので、今回は適当なdivをふわっと出してみます。

まずは今回できたものを貼っておきます。

See the Pen [Untitled](https://codepen.io/newnakashima/pen/RwJJwqq) by newnakashima ([@newnakashima](https://codepen.io/newnakashima)) on [CodePen](https://codepen.io).

何をやっているかというと、特定のDOM要素が画面の表示領域に入っているかどうかの判定を scroll イベントで発火させて、ふわっと表示させるためのクラスを付与しています。

```javascript
const pops = document.querySelectorAll('.pop')
pops.forEach(p => {
  const { top } = p.getBoundingClientRect()
  if (top < window.innerHeight) {
    p.classList.add('popped')
  } else {
    p.classList.remove('popped')
  }
})
```

top が window.innerHeight より小さいときというのは要素の上端が画面の中に入っているとき、ということを意味します。いきおいbottomの方は判定しなくて良いのか、とか考えてしまいそうですが、上にスクロールしたときにふわっと出すことはあまりないのでbottomでの判定は入れていません。

このコードでは一度アニメーションを表示して上にスクロールしてから再度下にスクロールして要素を表示させるとまたアニメーションします。それが煩わしい場合は `p.classList.remove('popped')` の行を消せばよいかと思います。

CSSのアニメーションはごく簡単で、小学生でも書けます。

```css
.pop {
  height: 60px;
  align-items: center;
  background-color: yellow;
  opacity: 0;
}
.pop.popped {
  opacity: 1;
  animation: 2s pop;
}

@keyframes pop {
  from {
    opacity: 0;
    transform: translateY(30px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}
```

何をするにもすぐjQueryやら最終コミットが3年前の謎Reactライブラリを使おうとするプログラマーにはなりたくないものです。

Reactでこういうのをやりたいときはどーするんだ！という話はありますが、Reactらしい方法でアニメーションを使うのはちょっとだるいので、ただ見ばえのためにふわっとエフェクトを付けたいだけならCSSファイルにアニメーション用のクラスを定義しておいてuseEffectでJSの処理を実行する感じが良いのかなと思います。

画像がふわっと出てくるやつをjQueryを使わずに実装する


プログラミング言語には一般的にループ構文があることが多いですが、ループ構文でなるべくネストを浅くする方法について考えてみました。多次元配列をループさせて要素を取得したい場合にループを重ねていくとネストが深くなっていってダサく読みづらいコードになりがちです。

例えば以下のようなオブジェクトがあったとします。

```json
{"companies": [
  {
    "name": "hoge商事",
    "departments": [
      {
        "name": "営業部",
        "groups": [
          {
            "name": "販売促進グループ",
            "members": [
              "山田太郎",
              "田中二郎"
            ]
          }
        ]
      }
    ]
  }
]}
```

この中の `members` をプログラム内で取得したい場合、素朴な方法としては以下のような感じで書けます。

```
for (let i = 0; i < companies.length; i++) {
  const company = companies[i]
  for (let j = 0; j < company.departments.length; j++) {
    const department = company.departments[j]
    for (let k = 0; k < department.groups.length; k++) {
      const group = department.groups[k]
      for (let l = 0; l < group.members.length; l++) {
        const member = group.members[l]
        // memberに関する何がしかの処理
      }
    }
  }
}
```

しかしこれは今日び正気とは思われないコードです。  
やっていることは大したことないのに認知的負荷の高い書き方で、読み手を疲れさせる独りよがりなコードと言えるでしょう。

flatMap や flatten のような関数が組み込まれているプログラミング言語であればそれを活用してネストを浅くすることができます。

```
const members = companies
  .flatMap(c => c.departments)
  .flatMap(d => d.groups)
  .flatMap(g => g.members)
```

あとパッと思いつくのは、名は体を表す関数を作ってしまうことでしょうか。定義は省略しますが、以下のように書けたらわかりやすそうです。

```
const company = companies[i]
const members = membersOf(company)
const groups = groupsOf(company)
const departments = departmentsOf(company)
```

しかしわざわざ関数を定義するのがめんどくさい場合もあります。定義したは良いけど一回しか使われないしトータルの行数も倍ぐらいに増えた、ということになってしまったら関数化するのが良いことなのかどうかわからなくなります。

オブジェクト指向な言語であればモデルクラスみたいなのを作ってそこにメソッドを生やすのも良いかと思います。

```
const company = new Company(companies[i])
const members = company.getMembers()
```

あるいは、本当に全社のメンバーが欲しいのかどうかも考え直してみたほうが良いことが多いです。companiesをドカッと渡して、その中からmemberを全員取得する、というような処理が本当に必要なのか？ということです。ロジックを雑に考えているからそうなっているケースが結構あります。本当は各社の広報メンバーだけが欲しかったりするはずです。

* * *

いくつか方法を考えてみましたが、検討する中で以下のようなことを感じました。

*   for文とかでゴリゴリ書くのは読み手に不親切なのでやめたほうがいい
*   なるべく自然言語に近い表現ができるコードにすると読みやすさが向上する。読みやすいコードは自然とネストが浅くなってることが多い
*   コードが読みやすいとロジックの拡張がしやすいので高度な機能を実装しやすくなると思われる

あとはパフォーマンスがどうなのかという話があると思いますが、経験上こういった書き方の問題でパフォーマンスが大幅に犠牲になることはないです。普通にfor文で書いたほうが速い場合は確かにありますが、それが問題になったときに初めて書き直せば良いかなと思います。そしてRustならゼロコスト抽象化のパワーによりパフォーマンスの問題すら考えなくて良いということになります。Rustを使っていきましょう。

ループのネストをなるべく浅くする


RDS には取得したスナップショットをクロスリージョンでコピーする機能があります。今年の3月に追加された機能のようで、割と新しめの機能のようですがすごく便利で、災害時を想定した非機能要件を簡単に満たせるようになるので使っていきたいところです。

マネージメントコンソールでの使用方法は、Sunny Cloud さんのブログ記事に詳細に書かれているので御覧ください。https://www.sunnycloud.jp/column/20210308-01/

弊社でもこの機能を使っていこうと思い、自動化のためにAPIを調べて実装していたのですが、幾つかハマりポイントがあったので共有致します。説明の前に、まずはうまくいったケースの AWS CLI と PHP の SDK のサンプルを載せておきます。CLIの例です。

```bash
aws rds copy-db-cluster-snapshot \
--source-db-cluster-snapshot-identifier arn:aws:rds:ap-northeast-1:************:cluster-snapshot:snapshot-1 \
--target-db-cluster-snapshot-identifier snapshot-copy-1 \
--kms-key-id ********-****-****-****-************ \
--source-region ap-northeast-1 \
--region us-east-1
```

成功すると以下のようなJSONが返ってきます。

```json
{
    "DBClusterSnapshot": {
        "AvailabilityZones": [],
        "DBClusterSnapshotIdentifier": "snapshot-copy-1",
        "DBClusterIdentifier": "database-1",
        "SnapshotCreateTime": "2021-10-18T10:52:08.803000+00:00",
        "Engine": "aurora-mysql",
        "AllocatedStorage": 0,
        "Status": "copying",
        "Port": 0,
        "ClusterCreateTime": "2021-10-11T09:35:31.780000+00:00",
        "MasterUsername": "admin",
        "EngineVersion": "5.7.mysql_aurora.2.07.2",
        "LicenseModel": "aurora-mysql",
        "SnapshotType": "manual",
        "PercentProgress": 0,
        "StorageEncrypted": true,
        "KmsKeyId": "arn:aws:kms:us-east-1:************:key/********-****-****-****-************",
        "DBClusterSnapshotArn": "arn:aws:rds:us-east-1:************:cluster-snapshot:snapshot-copy-1",
        "SourceDBClusterSnapshotArn": "arn:aws:rds:ap-northeast-1:************:cluster-snapshot:snapshot-1",
        "IAMDatabaseAuthenticationEnabled": false,
        "TagList": []
    }
}
```

次はPHPの例です。

```php
<?php

require 'vendor/autoload.php';

use \Aws\Rds\RdsClient;

$rds = new RdsClient([
    'region' => 'us-east-1',
    'version' => '2014-10-31',
]);

$result = $rds->copyDBClusterSnapshot([
    'SourceDBClusterSnapshotIdentifier' => 'arn:aws:rds:ap-northeast-1:************:cluster-snapshot:snapshot-1',
    'TargetDBClusterSnapshotIdentifier' => 'snapshot-copy-1',
    'SourceRegion' => 'ap-northeast-1',
    'KmsKeyId' => '********-****-****-****-************',
]);

var_dump($result);
```

成功したら以下のようなデータが返却されます。

```php
class Aws\Result#214 (2) {
  private $data =>
  array(2) {
    'DBClusterSnapshot' =>
    array(21) {
      'AvailabilityZones' =>
      array(0) {
        ...
      }
      'DBClusterSnapshotIdentifier' =>
      string(15) "snapshot-copy-1"
      'DBClusterIdentifier' =>
      string(10) "database-1"
      'SnapshotCreateTime' =>
      class Aws\Api\DateTimeResult#230 (3) {
        ...
      }
      'Engine' =>
      string(12) "aurora-mysql"
      'EngineMode' =>
      string(11) "provisioned"
      'AllocatedStorage' =>
      int(0)
      'Status' =>
      string(7) "copying"
      'Port' =>
      int(0)
      'ClusterCreateTime' =>
      class Aws\Api\DateTimeResult#231 (3) {
        ...
      }
      'MasterUsername' =>
      string(5) "admin"
      'EngineVersion' =>
      string(23) "5.7.mysql_aurora.2.07.2"
      'LicenseModel' =>
      string(12) "aurora-mysql"
      'SnapshotType' =>
      string(6) "manual"
      'PercentProgress' =>
      int(0)
      'StorageEncrypted' =>
      bool(true)
      'KmsKeyId' =>
      string(75) "arn:aws:kms:us-east-1:************:key/********-****-****-****-************"
      'DBClusterSnapshotArn' =>
      string(67) "arn:aws:rds:us-east-1:************:cluster-snapshot:snapshot-copy-1"
      'SourceDBClusterSnapshotArn' =>
      string(67) "arn:aws:rds:ap-northeast-1:************:cluster-snapshot:snapshot-1"
      'IAMDatabaseAuthenticationEnabled' =>
      bool(false)
      'TagList' =>
      array(0) {
        ...
      }
    }
    '@metadata' =>
    array(4) {
      'statusCode' =>
      int(200)
      'effectiveUri' =>
      string(35) "https://rds.us-east-1.amazonaws.com"
      'headers' =>
      array(4) {
        ...
      }
      'transferStats' =>
      array(1) {
        ...
      }
    }
  }
  private $monitoringEvents =>
  array(0) {
  }
}
```

## ポイント

### 1\. コピー先のリージョンにカスタマー管理型のKMSキーを作成しておく

クロスリージョンのスナップショットコピーでは、コピー先のスナップショットの暗号化にカスタマー管理型のキー(CMK)が必要なようです。KMSで予め作成しておきましょう。作れたらKMSの画面で以下のように表示されるはずです。

![](/blog-images/65.png)

画像内の赤枠で囲っている部分が \`–kms-key-id\` で必要なパラメータになります。

### 2\. –source-db-cluster-snapshot-identifier にはIDではなくARNの値を入力する

パラメーターのキー名に identfier とあるのでスナップショット名のことかと思ってしまいますし、実際同じリージョン内でコピーする時はスナップショット名をここに入力するのですが、クロスリージョンの場合はARNとなります。ここは結構罠だと思います。おそらくスナップショット名はリージョン内でしか一意でないので、ARNを入力する必要があるのでしょう。

### 3\. コピー先リージョンからCLIやSDKの操作を実行する

これもハマりどころでした。例えば東京リージョンからバージニア北部にコピーしたい場合、普通の感覚だと東京リージョンで操作を実行するものだと考えると思います。実際、マネージメントコンソールだとコピー元リージョンのスナップショットからコピー先リージョンを選んでコピーします。

しかし、CLIやSDKからスナップショットをクロスリージョンコピーする場合は**コピー先のリージョンでコマンドを実行する必要があります。**この場合はバージニア北部から操作を実行するのが正解となります。最初に掲載したサンプルでも、いずれもコピー先のリージョン（us-east-1）からコマンドを実行しているのが見て取れるかと思います。

コツが分かれば大したことない話なのですが、こんなつまらないことで数時間も費やしてしまったので、同じ問題で他の人が時間を浪費しないように記録させていただいた次第です。

APIやSDKのリファレンスを読むと `PreSignedUrl` というパラメーターにコピー用のWeb API呼び出し用のURLを渡す必要があるようなことが書いてありますが、よく読むとそのすぐ後に `SourceRegion` を渡せばAPI or SDK側でよしなにやってくれるという記述があります。

殆どの場合では `PreSignedUrl` を作るよりは `SourceRegion` を設定した方が簡単なのではないかと思います。


AWS の RDS でスナップショットをCLI や SDK を使ってクロスリージョンでコピーする方法


PHPには配列の結合方法として [array\_merge()](https://www.php.net/manual/ja/function.array-merge.php) 関数と、配列同士を [\+ 演算子](https://www.php.net/manual/ja/language.operators.array.php)でつなぐ方法の２種類があります。単純な添字配列（整数をキーとした配列）同士の結合をする場合に、タイプ数が少ないからと + 演算子を使って失敗したのでメモしておきます。

以下のような２つの配列を結合して、一つの配列にしたいと思いました。

```php
$one = [
    'hoge',
    'fuga',
];

$two = [
    'piyo',
    'foo',
];
```

今までは、array\_merge() は、結合する配列同士で同じ添字を持つ場合は２つ目の引数の配列が１つ目の配列を上書きする、+ 演算子の場合は上書きしない、という雑な覚え方をしていました。いわゆる連想配列しか使わない場合はそれでも問題なさそうなのですが、添字を明示的に指定しない「普通の配列」を結合したい場合はかなり異なる結果になります。具体的には以下のような違いが出ます。

```php
$merged = array_merge($one, $two);
var_dump($merged);
/*
array(4) {
  [0]=>
  string(4) "hoge"
  [1]=>
  string(4) "fuga"
  [2]=>
  string(4) "piyo"
  [3]=>
  string(3) "foo"
}
*/

$merged = $one + $two;
var_dump($merged);
/*
array(2) {
  [0]=>
  string(4) "hoge"
  [1]=>
  string(4) "fuga"
}
*/
```

array\_merge() のほうは意図した結果が出ているのに対し、+ 演算子のほうは意図しない結果になってます。全然結合できてません。

この仕様は公式のドキュメントでは以下のように説明されています。

>  両方の配列に存在するキーについては左側の配列の要素が優先され、 右側の配列にあった同じキーの要素は無視されます。
> 
> https://www.php.net/manual/ja/language.operators.array.php

そして、PHPでは整数をキーとした「普通の配列」と文字列をキーとした「連想配列」に本質的な違いはありません。

> PHP においては添字配列と連想配列の間に違いはなく、配列型は 1 つだけで、 同じ配列で整数のインデックスと文字列のインデックスを同時に使えます。
> 
> https://www.php.net/manual/ja/language.types.array.php

つまり、今回の例でいうと $one も $two も「0」「1」という整数のキーのみを持つ配列なので、「左側の配列」である $one の要素が優先され「右側の配列」である $two の要素は無視されてしまったというわけです。

しかし、ここがPHPの摩訶不思議なところなのですが、配列の項で「PHP においては添字配列と連想配列の間に違いはなく」と言っておきながら array\_merge() は「普通の配列」と「連想配列」を区別して扱います。

> 入力配列が同じキー文字列を有していた場合、そのキーに関する後に指定された値が、 前の値を上書きします。しかし、配列が同じ添字番号を有していても 値は追記されるため、このようなことは起きません。  
> 入力配列の中にある数値添字要素の添字の数値は、 結果の配列ではゼロから始まる連続した数値に置き換えられます。
> 
> https://www.php.net/manual/ja/function.array-merge.php

つまり、文字列をキーとする「連想配列」であれば後に指定された配列の要素が優先されて前の配列の要素を上書きするのに対し、整数をキーとする「普通の配列」であれば、たとえ添字が同じであっても前の配列の要素を上書きせず、要素を追加して返す、ということになります。厳密には文字列のキーも整数のキーも持っている配列があり得るので、キーの型によって挙動が変わるということになります。

一貫性という点からすると array\_merge() のほうが「PHPにおいては配列型は一つだけ」という原則を破っている（ように見える）ので変なことをしているということになりそうですが、直感に近い結果を返してくれるのは + 演算子ではなく array\_merge() の方です。他のプログラミング言語に慣れている人の場合はなおさらそうだと思います。

\+ 演算子はタイプ数も少ないし、見た目的に「普通の配列」同士を結合するときに使えそうな感じなのですが、事実は全く逆でした。むしろ array\_merge() のほうが大抵の場合において意図通りの結果を返してくれます。

\+ 演算子を使う場合は、その振る舞いをよく把握した上でないとバグを仕込みそうな感じがします。弊社では基本使わない方針にしていこうかと思います。。。

PHPの配列結合演算子で気をつけること


最近 Next.js を使用することが増えました。一年くらい前は勢いで言えば Gatsby.js のほうが強そうだと思っていましたが、近頃はまた Next.js の人気が高まってきたような印象を持っています。

弊社でも Next.js を積極的に使っていくことにしているのですが、 Next.js では画像を表示させる場合には <img> タグの代わりに <Image /> コンポーネントを使います。 <Image /> コンポーネントを使うことによって Next.js が画像をいい感じに最適化してくれるようです。具体的には自動でリサイズしてくれたり、 WebP フォーマットを使ってくれたり、しかも外部ドメインの画像であっても最適化してくれたりと良いことずくめです。

しかし、<Image /> にスタイルを当てたい場合に <img> タグと同じようにやってみてもうまくいかない場合があります。理由は、ブラウザの開発者ツールを見てみればわかりますが、 <Image /> コンポーネントが単に画像を最適化して <img /> タグを出力しているのではなくて、以下のようなHTML要素を出力するからです。

```markup
<div style="display:inline-block;max-width:100%;overflow:hidden;position:relative;box-sizing:border-box;margin:0">
  <div style="box-sizing:border-box;display:block;max-width:100%">
    <img style="max-width:100%;display:block" alt="" aria-hidden="true" role="presentation" src="data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjAwIiBoZWlnaHQ9IjIwMCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB2ZXJzaW9uPSIxLjEiLz4=">
  </div>
  <img alt="森の画像" src="/_next/image?url=%2Fimages%2Fforest.png&w=640&q=75" decoding="async" style="visibility: visible; position: absolute; inset: 0px; box-sizing: border-box; padding: 0px; border: none; margin: auto; display: block; width: 0px; height: 0px; min-width: 100%; max-width: 100%; min-height: 100%; max-height: 100%;" srcset="/_next/image?url=%2Fimages%2Fforest.png&w=256&q=75 1x, /_next/image?url=%2Fimages%2Fforest.png&w=640&q=75 2x">
</div>
```

これは、 React 上のコードとしては以下のようなものです。

```jsx
<Image
  src="/images/forest.png"
  alt="森の画像"
  width={200}
  height={200}
/>
```

<div> で囲われていたり <img /> が２つあったりと、普通にスタイルを定義するだけでは意味がなさそうということがわかります。実際、素直に <Image /> に className を設定しても position などはうまく反映されません。

しかし、レイアウト上 <Image /> のposition などを変えたい場合もあると思います。そのような場合、以下のようなコードを書いて対応しています。

MyComponent.tsx

```jsx
import Image from 'next/image'
import styles from './MyComponent.module.css'

export default function MyComponent() {
  return (
    <>
      <div className={styles.image_wrapper}
        <Image
          src="path/to/image"
          alt="my image"
          width={200}
          height={100}
          className={styles.image}
        />
      </div>
    </>
  )
}
```

MyComponent.module.css

```css
.image_wrapper {
  position: absolute;
  top: 0;
  left: 0;
}

.image {
  object-fit: cover;
}
```

<Image /> コンポーネントをさらに <div> でラップして、その <div> に position の設定をしています。この方法で画像の位置を調整できました。多少苦肉の策感はありますが、、、せっかくならばフレームワークの最適化の恩恵にあずかりたいので以上のようなコードで対応しています。

<Image /> や Next.js の画像最適化の詳細については下記を御覧ください。

*   [https://nextjs.org/docs/basic-features/image-optimization](https://nextjs.org/docs/basic-features/image-optimization)
*   [https://nextjs.org/docs/api-reference/next/image](https://nextjs.org/docs/api-reference/next/image)

Next.js の Image にスタイルを当てる


今年2021年の1月4日に会社を設立しました。合同会社うみがめと申します。

最初の投稿ということで、この会社がどのような会社かを簡単にご説明したいと思います。

## 何をする会社か？

主にWebサービスの開発やスマートフォンアプリ等の開発を行う会社です。

熊本県八代市というところにある会社で、地方都市にありますので大都市にあるIT企業と比べると人材・情報・お金などのあらゆる面で大きなハンデがあります。しかし敢えて地方都市で仕事を請け負うことによって、大都市にはいない人材やアイデアを提供できるのではないかと思っています。また、地方都市に今欠けているものを仕事を通じて埋めていくというのも会社の大きなミッションの一つです。

具体的にどういうことをやっているかというと、お客様から「こういうサービスが作りたいんだけど」というご相談を頂いてから実現する方法をご提案したり、そのための工数・工期・費用を見積もったり、プログラミングでそれを実現したり、ということを行っています。

ITの業界では「上流工程」「下流工程」という言葉がよく使われますが、ざっくりいえば「上流工程」はアイデアを具体的に固めていく工程で、「下流工程」はそれを動くものとして実現させていく工程です。弊社合同会社うみがめは「下流工程」を担当させていただくことが多い会社です。

「下流工程」を担当する人は文字通り下にみられることがどうしても多くなりがちなのですが、地方に所在している会社は「上流工程」を担当するのは苦手です。直接お客様に会って話を聞いたり打合せを重ねたりということが必要となるからです。しかし、「下流工程」ならそのようなことは必要ありません。遠く離れた場所でも働けます。

地方都市にある会社だからこそ、実際に手を動かす職人として良いもの作る技術を集中的に鍛えることができるのではないかと考えています。

現在は主にお客様から請け負って開発を行うことが多いですが、自分たちで考えたアイデアを元に商品開発を行い、自社製品で売上を立てていくことも目標です。

その他にはWebコンテンツ制作やコミュニティスペースの運営などもやっていけたら良いなと思っております。

## どんな会社が顧客なのか？

ITコンサルティング企業や、個人であってもアイデアを温めている人からは仕事を請け負います。プログラマーを必要としている人のお話であればとりあえず伺おうと思っています。

ただ、会社がまだ小さいということもあり大企業のお仕事はあまり得意ではないかもしれません。会社のミッションとしても、中小企業や新規事業部やスタートアップ・ベンチャー企業と積極的にパートナーシップを作っていきたいと考えています。

地方都市の会社とはいえ、ご縁さえあれば全国・全世界のお客様と取引させていただきたいと思います。

## 会社の規模は？

いまはまだ代表社員一人の小さな会社ですが、少しずつ従業員を増やしていきたいと思っています。

## 設立の経緯は？

これを書いている代表社員が昨年個人事業主として独立して仕事を請けていましたが、一人ではどうにも手が回らなくなってきて人材を雇用する必要性を痛感しました。今後健康的に仕事を続けていくためには一人では無理なので会社を設立したという次第です。

IT技術者は最近の若者に人気の職業であり、自分が仕事を多くいただけているのであればそのノウハウや仕事のチャンスを若い世代に提供したいというのも動機の一つです。

## 今後の予定

今年やっていきたいことを以下箇条書きにします。全部やれるかはわかりませんが頑張っていきたいと思います。

*   従業員を一人雇用し、その人が自分の技術力で売上をあげられるようにする。
*   週休3日、1日6時間労働、残業禁止を一年間続ける（従業員のみ）
*   自社製品の開発に着手する。年内にβ版を世に出す。
*   ゲーミングPCや最新ガジェットを触れるコミュニティスペースを作る。

以上です。今後とも何卒よろしくお願い致します。

Blog

ハロウィンクイズのサイトを作った

会社のブログを移行しました

『最強チームをつくる方法』読書メモ

Team Geekメモ

マルティン・ハイデガー『技術とは何だろうか』読書メモ２

VSCodeのVimでCtrl+mで改行したときにインデントがおかしい問題

マルティン・ハイデガー『技術とは何だろうか』（森一郎編訳）読書メモ１

スティーブン・ブディアンスキー著『クルト・ゲーデル』読書メモ

『リーダブルコード』の豆知識拾い

プロジェクトが炎上し始める兆候について

ソフトウェア製品を開発する上での一連の流れについて

Rust の the book の17.3の演習の解答例とBox<T>が mutable reference であること

Rustでdyn Traitにderive(Debug)をつける方法

LaravelでDB::raw使ったWhere句

tmuxの初期ディレクトリが変なところに固定されてしまった場合の戻し方

GitHub Actions の set-output がdeprecated になった件

Vue3でVSCodeのformatOnSaveみたいなのをESLintの設定でやる

Vue3の.spec.tsファイル内のimportがVSCode上でエラー出してる場合

findコマンドでアスタリスクを使うときに引用符でくくらないといけない理由

画像がふわっと出てくるやつをjQueryを使わずに実装する

ループのネストをなるべく浅くする

AWS の RDS でスナップショットをCLI や SDK を使ってクロスリージョンでコピーする方法

PHPの配列結合演算子で気をつけること

Next.js の Image にスタイルを当てる

会社を設立しました。

ハロウィンクイズのサイトを作った

会社のブログを移行しました

『最強チームをつくる方法』読書メモ

Team Geekメモ

マルティン・ハイデガー『技術とは何だろうか』読書メモ２

VSCodeのVimでCtrl+mで改行したときにインデントがおかしい問題

マルティン・ハイデガー『技術とは何だろうか』（森 一郎 編訳）読書メモ１

スティーブン・ブディアンスキー著『クルト・ゲーデル』読書メモ

『リーダブルコード』の豆知識拾い

プロジェクトが炎上し始める兆候について

ソフトウェア製品を開発する上での一連の流れについて

Rust の the book の17.3の演習の解答例とBox<T>が mutable reference であること

Rustでdyn Traitにderive(Debug)をつける方法

LaravelでDB::raw使ったWhere句

tmuxの初期ディレクトリが変なところに固定されてしまった場合の戻し方

GitHub Actions の set-output がdeprecated になった件

Vue3でVSCodeのformatOnSaveみたいなのをESLintの設定でやる

Vue3の.spec.tsファイル内のimportがVSCode上でエラー出してる場合

findコマンドでアスタリスクを使うときに引用符でくくらないといけない理由

画像がふわっと出てくるやつをjQueryを使わずに実装する

ループのネストをなるべく浅くする

AWS の RDS でスナップショットをCLI や SDK を使ってクロスリージョンでコピーする方法

PHPの配列結合演算子で気をつけること

Next.js の Image にスタイルを当てる

会社を設立しました。

マルティン・ハイデガー『技術とは何だろうか』（森一郎編訳）読書メモ１