完全にナチュラルな文章については、書くことも読むことも減ってしまった。近頃は比較的整形されたフレーズが世に蔓延っていて、そこから血の匂いを感じない。自分自身のそれについてもそう。非AI時代の文章は過去のものとなる。すこしのさみしさや恐れが発生している。

プロジェクト・ヘイル・メアリーを観てきた。太陽を蝕む微生物を、たった一人の地球人がやっつける話だった。主人公が船長でもなく、技術者でもなく、科学者で教師であったから、物語は良い方向に進んだのだと思った。インターステラーほど驚きはないし、オデッセイほどワクワクはしない。それでも鑑賞後は人間の尊厳というか希望で満たされた。良い。

私の人生に対しては、複数のシナリオが同時に進行している節がある。昨年末からさらに加速した。自分がやりたいことをやる。それだけの気持ちだった。

昔やってたウィザードリィというゲームでは、ビショップという職業がある。魔法使い系と僧侶系の呪文両方を取得することができるし、謎のアイテムの鑑定もできてしまう。非常に優れた上位職だが、それらを覚えるまでに必要なレベルが他の職業とは違ってかなり高い。いろいろできるようなるが、成長が遅い。

私も成長が遅い。遅いというか、ハードもソフトも中途半端にいろいろ手を出してしまって、成長を実感できないまま三十代前半を過ごしてしまった。それが昨年プログラミングスクールを卒業したあたりで、ようやく自身のスキルが定着した感覚を抱くようになった。ウェブプログラマーの下地が身についた気がする。本職では、3DCADを用いた機械設計も手に馴染んできて、これはこれで設計の速度が上がった。そして、なぜか第二種電気工事士の資格も取得した。

家庭の事情で学習に時間をかけられないこともあって、理解の歩みは遅かった。それでも続けたらここまで来れた。あとは気持ちというか気概の問題な気がする。

プロジェクト・ヘイル・メアリーに登場する彼の思想をぜひ手本としたい。日本語変換された言葉は語彙力に欠けるが、それでも課題をエンジニアリングによって解決する姿勢は良い。良い、良い、良い。感傷的にならず、何をすれば良いか、自分が何ができるかを知的好奇心をエンジンとして取り組んでいる。

肉体は衰えるばかりだが、知識はまだ入る。というより、知識面の成長は加速している気がする。やれることは全部やるぞ。表明。

Unsplash Marek PiwnickiMarek Piwnicki

何かを書き残そうとして、気づいたら二月が過ぎようとしていた。危ない。先月の終わりから家族全員で風邪を回し、ハサウェイを観るのが二週間ほど遅くなった。その後、いくつかのプレゼンをしたり、機械装置を組み付けたり、コードを書いたりしていた。いろんなことがあった。何も覚えていない。

自分の中の文章は枯渇していて、なにか原材料を摂取しないといけないという感覚はずっと抱いている。けれどすでに本を読む気力も薄れているためどうしようもない。経験たる経験が必要なのだが、それを経験してもここに書けないことが増え過ぎた。

技術書典20に申し込んだら当選した。またオンラインで出展することにした。今回もAIでなにかをつくっていく。少し前から考えていた、「どんどんアホになるAI」を実装してみたい。何か判断を誤り続けると彼らはどこへ向かってしまうのか。そんなことを表現したい。

いつかgithubにアップロードした個人的な理念を振り返った。つくることでこの世を理解したいのだな私は、と思った。でもつくるだけではだめ。つくり続けなくてはいけない。

ここの記録も同じ。

Unsplash ki Zhang

何もない日常などないはずもなく、私はふるさとの御神渡りを期待したり、工作機械の中で配管をばらしたり、コードの差分を読み取りかれらを理解しようとしていた。長男の熱が長引き、次男の予定が色々あったため私は久しぶりに会社を休んだ。もう彼の具合は落ち着き、隣で肉まんをほおばっている。すべて一月のことである。

答えをすぐにAIに聞かず、自分の中でとどまらせておくのも良いと気づき出した。問いを発酵させるイメージ。頭にもやがのこるけれど、そうやって脳にストレスをかけておくことで、何かが充足していく気がする。全部気のせいかもしれない。

あしたからガンダムの映画がはじまる。アマプラで前作を復習しておかないといけない。正月に逆シャアを初めて観て、ハサウェイの生い立ちを知った。ちょっと順序が良くない。

脳髄の搾りかすから文章を練り出している気がする。さいきんものを書くのもひどく遅くなっている。これでは良くない。AIに負けたくない。

経験たる経験から文章を生成しよう。

Unsplash Marek Piwnicki

　「ゆっくりするといいよ」と言われ急に自由な時間が二日ほど生まれ取り乱した私は、好きなナポリタンをつくる際に生のシーチキンを投入した箸のまま調理をして見事に腹を下した。年末である。2025年の末はここ五年ほど情熱を注いでいた事項がほどよく埋まり、また新しい窓口が開設された雰囲気もある冬だ。

　生成AIのパワーが日毎に強くなっているし、きっとシンギュラリティは起きちゃっている。それで作ることといえば呟きに添える画像の差し替えとは。やれやれですね。AIがバズワードではなくITレベルで浸透しちゃってるころには、ググれではなくチャッピーに聞いた？がそれになるんだろう。

　この一ヶ月程度の感覚だけど、AIを使いこなすよりも自分の脳をパワーアップさせる方が効率が良い気がする。脳は良い。省エネでハイパワー。なによりインターフェースがいい。念じればいいから。AIを使うとは、それっぽいことを喋る野郎を相手にすることだ。だから文章を整えてあげないといけない。文脈を整え、スコープを揃え、方法要領を正しく伝える。なんて面倒くさいんだ。アジャイルを目指していたらウォーターフォールになるんですね。そんなことはないか。

　脳をパワーアップさせるにはどうするか。

note.com

　この人の記事を読んだ。「脳に負荷をかける」。それだ。なんか言いたいことがまとめられていた。最近は目にばかり負荷がかかっていた。スマホで不要不急な動画を漁るばかり。脳は疲れてないのに目が疲れる。よくないな。あとは、すぐにメモを書くのはよくないらしい。昔、「メモの魔力」なんて本が売れていたのに。

　それなら目以外のインターフェースを使ってメモらずにアウトプットをすれば最強になれるのでは。そう感じた。そういった理屈で音声配信を始めることにした。

以前もnoteでやってはいたが、今回は目的が違う。脳を強くする！そんなかんじに生きることにした。音声配信の良いところはその文章量である。2000字程度のブログなんて、五分程度あれば喋り切ってしまう。だから20分くらい喋るとなると、もっとたくさんのことを仕入れて話す。そして台本は読まずに頭の中に全部入れておく。結構脳が鍛えられる気がしてきた。

二週間に一回程度の頻度で投稿できたらいいな、と思う。

UnsplashMarek Piwnicki

子供がCOSMOSという合唱曲をよく歌っている。１００億年という単語が出てくるが相当長い時間であるためあまり感覚がつかめない。彼はさらりと流してしまうが、途方も無いスケールの歌だなと聞いていた。それに比べてこの数年なんて塵にも満たないはずなのに、本当にいろんなことがあった。

フィヨルドブートキャンプ Advent Calendar 2025 | Fjord Calendar

そう。これはフィヨルドブートキャンプアドベントカレンダー2025の記事だった。

今年の七月にオンラインのプログラミングスクール、フィヨルドブートキャンプを卒業した。二年かかった。当初はITエンジニアに転職するために入ったのだが、勉強していくなかで年をとり、もう転職は無理かなと思った。それでも退会しなかったのは、単なる意地である。あとは卒業できればいつでもブートキャンプアプリを閲覧することができるというのも大きい。なんかもったいなかった。

もう半年経ったので、難しかったプラクティスの思い出や、記憶に残っているイベントなどはなにひとつない。すでに忘れた。過去のことはコードが覚えているはずなので、私は前を向き続けないといけない。そういった理由でAIと一緒に個人開発をしたり、その体験談をまとめて技術書典に出したりした。まだやることは多い。

AIがなんでもやってくれるようになり、私たちはプロンプトをうつマシンになりさがったか。そんなことはない。彼らは文脈を適切に所有しない、賢いバカだ。ターミナルを閉じるとすべてのコンテキストが消し飛ぶこともあった。これは私の使用方法に誤りがあった。自分の脳みそに情報を詰め込む方がSDGsの面で優っている。脳は非常にエコな構造。マシンはまだ私たちの脳を模倣できていない。

私はコードを書くときに人生の良さを感じる。コードと共に生きるのがしっくりくるのだ。特別好きと言うわけでもないけれど、嫌いでは無い。フィヨルドブートキャンプを卒業できたのは、このような消極的意欲のおかげに他ならない。

これからのことは、これからの私が考えることで、今の私は考えない。というのはタイトルと不一致なので少しだけ想像する。来年もおそらくコードを書いていると思う。判断をAIに委ねるのはなるべくしないようにする。それには彼らより賢くなくてはだめで、賢さをあげるには文章や言葉によって思想を具体化したほうがいい。

常に発信活動をしていこう。常時。

UnsplashMarek Piwnicki

諸君らが愛してくれた秋は死んだ。なぜだ。暑いばかりの夏はとうに過ぎ去り、凍えるだけの季節になってしまった。少しだけ朝起きるのが苦手になって、私はコードや文書を書けないことに悲しくなった。そのようなものだ。

もう12月となったのでアドベントカレンダーを書いていかないといけない風潮である。今年もエンジニアと人生アドベントカレンダーに参加した。エンジニアとしての日常を生きる。

エンジニアと人生 Advent Calendar 2025 - Adventar

エンジニアとは何か

コミュニティの人たちの属性はITエンジニアが多い。私はITではなく、メカニカルな機械系のエンジニアだが、「エンジニアになりたいな」などと思っていた。しかし、そんな線引きはまったく幻想のまぼろしの虚であって、自分で適当に区分を設けただけだった。エンジニアを覗く時、エンジニアもまたこちらを覗いているのだ。まったく訳がわからない。

昔技術士の勉強をしていたとき、技術士の本分とは技術的な課題を解決することなんだよ、ということを知った。そうだった。みんなが困っていることを解決すればいい。その手段としてITを駆使したり、メカニカルなからくりをつくったりしているだけだった。やっぱり私もエンジニアだった。

自分の像がそれとなくわかってきた2025年であり、ある程度決心というか諦めがついたのも2025年。しかし、諦めたときに思わぬ方向からいいかんじの風がやってきて、それに持ち上げられつつあるのも2025年なのだ。詳細を書くのは難しいが、今年は自分のキャリアの方面でいろいろと変化があった。

理念の設定

私のキャリアや課題についてChatGPTと壁打ちを続けていた。彼はあたりさわりのないことを言ってくる。私が望む答えしか言ってこない気がしてきたので、「忖度するな、お世辞を言うな、真実を言え」というプロンプトを設定した。まったく答えが変わった。ClaudeCodeも開発方針や指針によっていかようにでもコードが変わる。これは私自身のなかにもブレない理念を持つ必要があるなと思った。

github.com

理念

つくる。より良くつくる。

詳細

• 考える。言葉によって考える。
• 動く。行動は機会を導く。
• 休む。余白は自身を補完する。
• 伝える。他者の視点に立つ。
• 良さ。良さはすべてを越える。

このようにした。理念があって初めてその後の実装が出来上がるのだろう。

理念に基づいた行動

理念を設定することで見えてくるものがある。私は他者にそこまで興味がないが、イベントは積極的に参加しようと考えていたり、登壇駆動・締切駆動をこよなく愛する人物であった。変なの。そういったわけで、技術書典19にオンライン参加して書籍を売ってみた。オンライン販売なので原価はゼロだ。

AIと共に強くなる—はじめてのClaude Code体験記—：kyokucho1989

そして何冊か売れたのでわたしは「嬉しいな」と思った。味を占めたので今後は毎回参加することにした。

結局はつくるのが好きな人間だった。つくることで未来を実装してしまえ。そんな雰囲気もある。

今後の私を妨げるもの、制約と誓約

今年もかなりの動きがあったが、来年もひどそうだ。しかしこれが毎回うまくいくわけではなく、障害は多い。一番は子供か。彼の性質上、加齢によって落ち着くとかそんなレベルではない。「もう育児のフェーズは終わって、（子供の）介護になったね」と妻と話している。朝の2時に起きてくる子とやりあったり、6年目のトイレトレーニングをしたりして日々を生きている。

しかし彼がいたからこそ、より集中して物事に取り組めるようになったのも事実だ。頭の中で実装したり文章を整えたり分解して、空いた時間で一気に形に仕上げる。制約と誓約である。

「逃げるな、生きる方が戦いだ」とカガリは言ったが、エンジニアとして現実と向き合わなくてはいけない。常に健康で、どこにも敵はおらず、時間と金はいくらでも使える！そんなことはない。予算納期品質社内外家族友人それらを天秤にかけながら、どれを選んでも正答となる4つの選択肢を持ち、一つを選ぶ！そんな感じで生きていく。これが現実。

やっていこう。

UnsplashMarek Piwnicki

環境は変わっていないくせに、自分がやりたいことがどんどん実現していく様はさながら魔法である。Githubの自己紹介ページに掲げた理念においては、思考は文章であると述べている。新しい知識が脳内に増えていくが、どこかでそれを書き留めておかなくてはいけない。今日はDockerについて少しだけまとめる。

Dockerとはなにか。

What is a Container? | Docker

Docker入門（第一回）～Dockerとは何か、何が良いのか～ | さくらのナレッジ

コンテナ型の仮想環境を作成、配布、実行するためのプラットフォームです。

なるほど。開発環境をローカルではなく仮想環境上に構築し、それを配布・実行するための仕組みということか。

Dockerのコンテナと比較されるのが仮想マシンという概念である。仮想マシンはホストマシン上にHypervisorという司令塔を入れて、複数のゲストOSらに指示を出して、アプリ等を動かしていた。ゲストOSは独自のカーネルを持つため、ホストとは別のOSが1つのマシン上で動いている状態になる。しかしこの構成ではゲストOSの分サイズが大きく、処理も遅くなってしまうという難点があった。

一方、Docker コンテナは、独自のカーネルを持たない。カーネルはホストOSのものを共有して利用する。そのためサイズが小さく処理が早いというメリットがある。

なぜコンテナがでてきたか

ChatGPTにききながらすこしまとめた。なぜ最初からコンテナが出てこなかったのか。技術的問題と社会のニーズによるところが多かったようだ。コンテナを実装するにはカーネルのなかに隔離技術がないとダメだった。名前空間やリソースの制御が必要だった。社会的にもカーネルの共有は危険とかリスクが高いとかそんな懸念があった。

技術は一足とびではない

調べていくと一つの技術がポンと出たわけではなく、社会事情や技術革新とかがあって新しいものができてきたのだなと知った。これはハードウェアと一緒か。紡織から自動車業が発展したように。私もがんばろう。

UnsplashMarek Piwnicki

11月も始まったばかりだと思っていたが、もう中旬になっていた。先日はポッキーとプリッツの日だったが特に何事もなく過ぎていく。そういえば小学生の頃にだれかがその日が11月11日だと気づいて、みんなで11時11分の時に「ポッキー！」と叫んだ記憶がある。先生は困惑していた。

技術書典19にむけて書いていた原稿が完成し、今週末から販売できるようになった。オフラインでの出品はせずに、オンラインのみ。すこしさびしいけど、本を出すのは面白いなと思った。

techbookfest.org

これ。ClaudeCodeをつかった開発記録をせきららに書く。生成AIはこの数年ですごい勢いでみなが使うようになり、ChatGPTに関しては生活に溶け込みつつある。コーディングとAIは本当に相性が良く、彼らは既存のコードを調査し、適切な設計をしてくれる。はず。でもそうじゃないかも。

便利な使い方や、最強のプロンプトを紹介する本ではなく、本当に自分が感じたことを淡々とまとめている。でも頑張って書いたのでぜひ買ってほしい。

やり方がだいぶわかってきたので、来年も出すぞ。

Unsplash Marek Piwnicki

　通勤電車のルートでスマホが圏外になるエリアがあって、その時だけは皆が遠くを見つめている気がした。けれど既に外は暗くなっていて、私はガラスに映る私を把握するほかはなかった。10月も終わりである。

　前回の記事のアンサー記事になるような構成だが、技術書典19に出す原稿が完成した。物理本は出さないのでデータだけ登録して、いまは審査待ち。問題なければ来週末くらいには電子マーケット上に並べることができるだろう。そうしたらもう少し宣伝する。わりと気軽に本が出せるのは良い。オンラインなら費用をかけずに出店することができるし。

　最近つくった自分の理念の中に、「考える。言葉によって考える。」というフレーズがある。思考とは言葉というのはウィトゲンシュタイン的なあれだけど本当にそう。考えるにはとにかく言葉にしなくてはいけないし、言葉がないと考えることにはつながらない。締め切り駆動開発で毎年二回は強制的に本を出せるので、これからも毎回出そうと思う。

　電気工事士二種の実技試験に向けて練習をしている。図面を読み取って配線図をかき、それに従ってケーブルの被膜をとったり配線したりしないといけない。道具は一通り揃えたのでいざやってみようとしたが、まったく意味がわからない。Youtubeにあった解説動画の通りにやってみる。

www.youtube.com

　難しいが、なんとなくわかってきた。針を知らない人間がいちから裁縫を習うとしたらこんな感じなんだろうな。一連の作業を分解し、さらにそれぞれの要素作業がある。体に覚え込ませるのが最適だろうが、果たして私にそのような時間があるだろうか。工具を10分でも机に広げていたら、たちまち子供が寄ってきて邪魔をする。長男はちょっかいを出してくるし、次男の前では見せないことにしている。いろいろ口に入れそうだ。

　時間が足りないなぁ。足りないなかやればいいか。

UnsplashMarek Piwnicki

今年もまたりんご狩の季節となった。一時間ほど車を走らせて山あいの畑に行くと、すでにたくさんのりんごが実っていた。私たちはきれいな形のものをいくつかもぎ取って、そのまま口に入れた。今回は次男は逃げ出さず、みなといっしょにりんごを堪能していた。

第二種電気工事士という資格試験を受けることにした。この資格を手に入れれば、低圧の電気工事が可能となる。家庭のコンセントの付け替えや、エアコンの工事もできそうだ。それもいいが、会社から資格手当が出るのが良い。参考書を買って、よくわからない知識を詰め込んだ。記号や使われる条件を覚える。計算問題もあるが、それほど難しくない。筆記試験をこの間受けて、合格した。よかった。次は実技を受ける。

試験が終わったので、次は技術書典の原稿を書かなくてはいけない。内容も考えないといけないが、執筆環境を作る必要がある。以前コミュニティで本を出した時はRe:Viewというツールを使っていた。あれを導入しよう。AIに聞きながら手順をさぐっていく。どうやっても時間が足りない気がするが、それはその時の自分がなんとかするはずだ。私は知らない。

りんごの話だが、持っていたiPhoneが壊れた。SIMを認識しなくなったのだ。修理屋に持って行くと、どうも物理的にSIMを読み取れないようになっちゃったらしい。以前から認識できないことがあったので、そうなのだろう。基盤のどこかがやきついたとかそんなこのか。背面システムの全交換が必要になるようで、ちょっとしたスマホが買えるくらいの金額だった。一旦は家に落ちてた昔のケータイにSIMを入れて生活しているが、やはりiPhoneが欲しいなと思う。

最近は仕事が落ち着いてしまって、忙しくない。忙しいのは良くないけど、忙しくないのも良くない。自分をある程度忘れている方が、余計な悩みも少なくなる。自己実現とか。難しいですね。

iPhoneか。新しいスマホがあれば全て解決するのか。技術書典に本を出して、その収益でもってiPhoneを買おう。小さな願いですね。

Unsplash Marek Piwnicki

　朝起きて作業をし始めると、自分が自由に扱える時間は今しかないのだなと気づいた。平日でも休日でも子供が起きてくれば全ての作業は中断され、そこからバタバタと一日が始まってしまうのだ。それは一時的なものではなく、最低でもあと五年は続く恒久的なものであるから、自覚しよう。

　集中するとかしないとか、それ以前の話で、まずはやらないといけない。

　技術書典への出版用にClaudeCodeとともにコードを書いているが、面白い感覚ではある。記憶障害を持っている研究者を相手にしているようだ。「博士の愛した数式」という小説にでてくる博士のようだが、ターミナルを閉じればその記憶は無くなってしまう。ではなにを参照しているのかというと、仕様書とも呼べるCLAUDE.mdや成果物であるコード自体である。だから、「昨日のあれ、やっといて」では伝わらない。この辺りはChatGPTとは異なるところだ。

　可能な限りコンテキストが続くように、データを保存していけばいいのかもしれない。たとえ私がすぐに忘れるような人間になったとしてもAIがそれを覚えていられるくらいに。

　AIを使ったコーディングを通して、私もAIと共に成長したいと思っていたが、彼らは成長しないのかもしれない。私がコンテキストを渡すのが上手くなればそれでいいだけの話か。

　結局は自分の頭に知識を詰め込んでいかないといけない。手は増えたが、頭は増えない。AIに渡せるのは仕様書のみであって、根本となる考え方や正しさはすべてこちらが持とう。彼らは神ではなく先生でもなく、優秀な部下である。

　タイトルに言及してなかった。チェンソーマンの映画を観てきた。非常に良かった。アクションシーンが芸術的でもあり、かっこよかったけど、原作ではどんな絵の構成になっていたか思い出せない。読み直そうかな。

　サメの魔人であるビームは、ちょっと頭弱いけど今回はかなり活躍していた。ひとえにデンジへの忠誠心によるものだと思う。彼はAIとは違うので、デンジが明確に方針を示さなくてもいい感じに戦ってくれ、彼の意思を汲み取って行動してくれる。全然死なないし、やっぱり強い。

　AIはもちろん強いけど、より強いのはサメの魔人なのかな。でも頭のネジが外れまくっているデンジみたいなやつが最強なんだろう。コーディングも。

UnsplashPhilipp Düsel

　文章を書く気力が湧かない、というのは気のせいであって、ワンセンテンスを捻り出せばあとはどうにでもなることがある。朝は少しだけ涼しい時間もできてきて、駅のホームで待たされても汗をかくことが少なくなった。

　プログラミングスクールを卒業してから、かなり時間が余るようになった。PCに触れる時間帯は常に課題のためのコーディングをしていたため、それがなくなるとびっくりするほど暇になった。このまま遊び呆けるのも良いけれど、せっかくだから何か別のことをしたい。

　締切駆動開発、イベント駆動開発という言葉がある。成果物のない状態で創作関係のイベントにエントリーしてしまい、そこからものを作ることだ。私は何かに追われていないと生を実感できないのだろう。そういった理由で、技術書典19に参加登録をした。

techbookfest.org

　これは技術系の書籍を作って売る同人イベントだ。コミケの技術書バージョン。以前、FarmtoryLabやエンジニアと人生コミュニティで合同で本を出した記憶がある。自分は原稿を出しただけだったが、あとで物理本を送ってもらえて、それは今でも本棚に残っている。楽しかった。

　まだ当落状況は未確定だが、本の内容はだいたい決めた。AIのことを書く。文章はいきなりたくさん書けないので、ここのブログに少しずつ投下していって、あとでまとめるようにしたい。

　漫然とAIを使うのではなく、主体的に使ってともに成長できるようになりたい。それには言語化が必要だ。自分が何をしたいのか、なぜそのコードを選択したのか。表現できるようになれば強い。そういったわけで、開発記録をログに残し、それをAIが読み込んで追記してくれるような開発スタイルを試みることにした。

github.com

こんな感じ。

記録

開発記録 (by Claude)

各フェーズの進捗は /history-by-claude/yyyymmdd.md 形式で記録し、技術的な決定の根拠と学習内容を明確に文書化します。

どのようなプロンプトを与えられ、何を生成したかを残します。 また、「こうすればより効果的だったのに」というプロンプトがあれば、それも合わせて教えてください。

開発記録 (by 人間)

開発者が学習したことを /history-human/yyyymmdd.md 形式で記録します。内容は以下の通り。

# 人間による記録
~~~~

# Claudeによる指摘

~~~~

「人間による記録」は人間が書きます。そこに過不足があれば「Claudeによる指摘」を書いてください。記載するタイミングはこちらが指示します。

人間が書き、AIが指摘する。足りないところはAIが補い、AIが見落としたところは人間が拾う。二人三脚のように、コードも文章も育てていく。

小さなログが積み重なり、やがて一冊の本になる。そう思うと、今から少し胸が高鳴る。

UnsplashMarek Piwnicki

課題

自作サービスであるlytnoteはRender.comを利用してデプロイしている。しかし月額料金がかかっているため、これをなくしたい。Fly.ioはレガシーHobyyプランの状態であるため、月の合計金額が$5までなら無料で利用できる。こちらに移行する。

データのバックアップ

Render.comでデプロイしたアプリケーションのデータのバックアップをとる。こちらのQ&Aが参考になった。

Backup Postgresql database using pg_dump? - Render

This worked for me.

PGPASSWORD=<YOUR_DB_PASS> pg_dump \
-h postgres.render.com \
 -U <YOUR_DB_USER> \
 --format=custom --no-acl --no-owner \
<YOUR_DB_NAME> > <YOUR_DUMP_NAME>.dump

なるほど。

まずはRender.com にアクセスして、サービスのダッシュボードから「PSQL Command」のコマンドをコピーする。

Render · The Easiest Cloud For All Your Apps

ターミナルでこのコマンドを入力すると、Render.comにデプロイしたアプリのサーバーへアクセスすることができる。ここでさきほどのpg_dump コマンドを実行し、データベースのバックアップファイルをローカルにダウンロードする。

PGPASSWORD=<PASSWORD> pg_dump -h <自分のサーバーのアドレスrender.com> -U <アプリ名> --format=custom --no-acl --no-owner <dbの名前> -f <任意のファイル名.dump>

これでファイルをダウンロードできた。

データの移行

1. 状態の確認

取り出したバックアップデータを今度はfly.ioへデプロイしたアプリへ投入する。

カレントディレクトリをデプロイしたプロジェクトに移動させてから以下のコマンドを打つ。

fly status

 $ fly status
App
  Name     = <app名>                                        
  Owner    = personal                                                        
  Hostname = <app名>.fly.dev                                
  Image    = xxxxxx

Machines
PROCESS ID              VERSION REGION  STATE   ROLE    CHECKS  LAST UPDATED         
app     xxxxx  2       nrt     stopped                 2025-08-30T01:29:09Z
app     yyyyy  2       nrt     stopped                 2025-08-20T19:57:11Z

2. Machineの起動

Machinesは停止していた。これを起動させておく必要がある。以下のコマンドを打つ。

　fly machine start <マシンID> -a <app名>

マシンIDは複数あるがどれを指定しても良い。

再度 fly status コマンドによってステータスを表示させ、Machineがstoppedからstartedになっていることを確認する。

Machines
PROCESS ID              VERSION REGION  STATE   ROLE    CHECKS  LAST UPDATED         
app     xxxxx  2       nrt     started                2025-08-30T01:29:09Z
app     yyyyy  2       nrt     stopped                 2025-08-20T19:57:11Z

3. 環境変数から接続情報を確認

Fly.ioが動いているコンテナにログインし、サーバー上に保管されている環境変数を確認する。

$ fly ssh console -a <app名>

 Connecting to xxxx... complete 

root@xxxx:/rails# echo $DATABASE_URL 

postgres://<ユーザー名>:<DATABASE_PASSWORD>@<ホスト名>:5432/xxxxxx..

環境変数DATABASE_URLから、DATABASE_PASSWORD　やホスト名などを確認できる。

4. プロキシを張る

データベースへバックアップデータを投入するために、ローカルからfly.ioのデータベースへ接続する。そのためにはfly proxy　をつかう必要がある。

新しくターミナルウィンドウを開き、以下のコマンドを打つ。

fly proxy 5433:5432 -a <postgres-app-name>

このとき、5433はローカル側のport番号の指定。5432をローカルで使用していないなら以下でも問題ない。

fly proxy 5432 -a <postgres-app-name>

Connect With flyctl · Fly Docs

このターミナルウィンドウはそのままにしておく。

5. データの投入

以下のコマンドを打つ。

PGPASSWORD=＜DATABASE_PASSWORD＞ pg_restore \
  -h localhost  \
  -U ＜ユーザー名＞ \
  -d ＜データベース名＞ \
  ＜ファイル名.dump＞

ユーザー名とデータベース名は同じだった。fly.ioの<app名>でできた。ファイル名はターミナルでコマンド打った場所からのパスを入力する。私の場合はDesktop/ファイル名.dump だった。

成功するとSQLの実行ログがぶわぁーっと出る。

おわりに

データの移行は初めてだったがなんとかできた。少しずつ個人開発を頑張っていこう。

UnsplashMarek Piwnicki

文章を書くのが苦手になってしまった。しかし、それは慣れによって解決されるかもしれない。説明したいことが頭の中に入っていても、それらをどうやって一つの道に置いていくかはきっとコツがあるのだろう。短いに越したことはないが、なにも書けないよりはダラダラと連ねた方がいい場合もある。

オープンセミナー2025 @広島というイベントに参加した。長い歴史のあるIT系のイベントで、前から行きたいとは思っていた。長丁場なので、家を空けることに気が引けたのだが、妻が快く了承してくれた。ついでに懇親会も行って良いとのこと。ありがたいことだった。

オープンセミナー2025@広島 − 君はどこで動かすか？ - connpass

来場者は六十名ほどで、知らない人がほとんどだった。ナカミチさんの隣が空いていたのでそこに座った。しばらくするとイノウエさんもきた。JBUGのような感じになった。色々話したがあまり思い出せない。

自分もLTで発表した。今回のテーマは「君はどこで動かすか？」というものだが、私はただただ現職で頑張っていくぞということを伝えた。

www.docswell.com

この5、6年ほどキャリアについて悩んでた。どうしてもITエンジニアになりたくて、でも家庭の都合もあってなれなくてずっとモヤモヤしてた。単純に技術力を上げれば克服できるものではないのに、学習することによって現実から逃げていた。

転機などというものはなかった。ジワジワと環境が変わり、いつしか「別にここでも夢を実現できるのでは？？」と考え始めた。結局は今ある手札で戦っていくしかないんだろうなぁ。誰かもそう言っていた。

会場が変わって懇親会となった。各自が飲み物を持ってきていて、食事も豪華だった。たこ焼きを食べそびれたのが悔やまれる。懇親会のときもLTを少しだけした。「これから私はどう動くか」ということだけ話した。自分の興味のあることはいろいろあるけど、業務内でもそれらができるようにやっていくぞ、という決意を述べた。

LTの終了後、オザキさんが「kyokuchoさんは、、すごいですよ」と声をかけてくれたのが嬉しかった。今回のセミナーの実行委員長だったカネヤスさんからも「応援しますよ！！」というエールを頂いた。

帰り道は日が暮れたのにまだジメジメと暑かった。しかし足取りは軽かったし、体の奥から燃えてくるものがあった。呪いというか、縛りがとれた気がする。キルアが自身の頭に刺された針を取り除いた感覚に近い。これからもコードを書くし、作りたいものを作るし、やりたいことをやる。ここで。

UnsplashMarek Piwnicki

要約

Rails v6アプリをFly.ioを用いてデプロイを試みた。MissingKeyErrorが発生したが、Dockerfileを--precompile=deferというオプションをつけて再度生成することによって、無事にデプロイができた。

背景

前回の続きで、RailsアプリをFly.ioへデプロイすることを試みた。しかし、fly deployを実行すると以下のようなエラーが発生していた。

ActiveSupport::EncryptedFile::MissingKeyError: Missing encryption key to decrypt file with. Ask your team for your master key and write it to /rails/config/master.key or put it in the ENV['RAILS_MASTER_KEY'].

これを解消することにした。

調査

このエラー文はなぜ発生するのか調べた。どうもfly deployを行う際にDockerfileで実行するRUN SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile　部分でエラーが出ているようだ。DUMMYの箇所が気になったので調べた。以下の記事を見つけた。

【イベントレポート】Railsアプリで秘匿情報を環境変数からCredentialsに移行した話 - Timee Product Team Blog

Rails 7.1から SECRET_KEY_BASE_DUMMY が導入されました。これは、SECRET_KEY_BASE の代わりにダミー値を自動的に設定する SECRET_KEY_BASE_DUMMY です。assets:precompile 実行時に SECRET_KEY_BASE が必要ない場合でも、エラーが発生することを防げます。

そう。SECRET_KEY_BASE=DUMMY はRails 7.1から使える記法であった。私のアプリはRails6.1だ。このため、SECRET_KEY_BASEがない状態のままプリコンパイルが実行されたためエラーとなっていた。

解決策

このエラーの解消方法は公式のドキュメントに記載されていた。 Existing Rails Apps · Fly Docs

bin/rails generate dockerfile --precompile=defer

これはDockerfileを生成する際にprecompileをdefer これを実行して再度deployするとできた。

Rails 6系ではアセットプリコンパイル時に SECRET_KEY_BASE が必要になる場合がある。これは、プリコンパイル処理の中で暗号化キーを利用してcredentialsやencryptedファイルにアクセスする可能性があるためだ。 今回のように環境変数をデプロイ後に設定できる構成では、ビルド時にプリコンパイルを避ける（defer）方針が有効となる。

はじめに

ずっと前に開発したWebサービスがある。lytnoteといって、目標設定機能のついた日報アプリだ。デプロイにrender.comを利用しているが、月に1,000円ほど月額料金がかかっている。サービスを永続的なものにしたいので、運営コストはなるべく安いものにしたい。

lytnote.com

そういうわけでfly.ioへ移行することとした。しかし移行する前にひさしぶりにアプリをローカルで立ち上げようとするもエラーが発生する。どうやらupdateが必要なgemがあったり、依存性の問題があるようだ。

これを解消しよう。

AIと共に生きる

もうAIと共に生きることにしたのでGithub Copilotの年間プランに入会した。VScodeに彼を入れることで、現在のソースコードを読み取ってくれて、こちらからの質問にもうまく対応してくれる。ChatGPTだと自分がコードを貼り付けて質問する必要があるが、情報量が足りずに齟齬が起きる場合があった。

発生したエラー

ターミナルでrails s　と実行するとエラーが発生した。

/Users/xxx/lytnote/node_modules/node-sass: Command failed.
Exit code: 1
Command: node scripts/build.js
Arguments:
Directory: /Users/kondoukou/lytnote/node_modules/node-sass
Output:
Building: /Users/xxx/.nvm/versions/node/v18.1.0/bin/node /Users/kondoukou/lytnote/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
gyp info it worked if it ends with ok

node-sassとNode.js に問題があるようだ。

node-sassとはなにか

node-sass - npm

Node-sass is a library that provides binding for Node.js to LibSass, the C version of the popular stylesheet preprocessor, Sass. It allows you to natively compile .scss files to css at incredible speed and automatically via a connect middleware.

node-sassとはWebpackerのバージョン4で使用されているライブラリである。SassをCSSに変換する際に使われている。しかし、ライブラリのベースとされているLibSassの開発が停止となり、node-sass自体も現在は非推奨である。そのため、Node.jsのバージョンを上げると不具合が起こる。

WebpackerとRails

Rails 6では、JavaScriptやCSS、画像などのフロントエンド関係の要素を管理しやすくするため、Webpackerという仕組みが導入されている。WebpackerはJavaScriptモジュールバンドラーであるWebpackのラッパーライブラリである。Railsの皮を着せたwebpackだ。

Rails7以降ではWebpackerは廃止されたため、エラーを回避するためにRails7にアップグレードするという選択肢もあった。しかし、これはこれで変更箇所が多すぎるので今回は見送った。

修正箇所

バージョンの不整合を避けるため、以下のように修正した。

Gemfile

- gem 'webpacker', '~> 4.0'
+ gem 'webpacker', '~> 5.4', '>= 5.4.4'

package.json

-    "@rails/webpacker": "4.3.0",
+   "@rails/webpacker": "^5.4.4",

Gemfile とpackage.json の両方ともバージョンを書き換える。

そうして

bundle install 
yarn install

を実行した。無事にエラーは解消された。

おわりに

技術的負債は久々に触ると手間がかかるが、CopilotやChatGPTのようなツールがあると、心理的なハードルがかなり下がる。

また続きを書く。

UnsplashTroy Olson

最近話題になっているClaude CodeをWEB開発に導入することとした。ClaudeCodeとはターミナル上で動作する、AIコーディング支援ツールである。Cursorとは異なり、CLI上で動くツールだ。対話型でコーディングを進めるため、画面の向こうの別の人物とやりとりしているようだ。

AIの利用についてはいまだに賛否両論があるかもしれない。しかし食わず嫌いになってはいけない。

Claude Codeの導入

さて、まずはinstallしよう。

docs.anthropic.com

✻ Welcome to Claude Code!                         │
│                                                   │
│   /help for help, /status for your current setup  │
│                                                   │
│   cwd: /Users/(name)/lytcycle                  │
╰───────────────────────────────────────────────────╯

 Tips for getting started:

 1. Run /init to create a CLAUDE.md file with instructions for Claude
 2. Use Claude to help with file analysis, editing, bash commands and git
 3. Be as specific as you would with another engineer for the best results
 4. ✔ Run /terminal-setup to set up terminal integration

いったいなにからやればいいんだ。

WATASHI.md をつくる

Claude CodeはCLAUDE.md というファイルを参照し、開発方針や注意事項を確認しているらしい。マークダウンファイルなので日本語で書ける。設計仕様書のようなものか。

彼を参考にして、わたしもWATASHI.mdをつくる（宣言する）ことにしよう。

# 理念
1. 常に考える
2. 考えるとは論じることである
3. 余白は論じることを補完する
4. 良さは結果を超える


# 方針
1. 課題を明らかにする
2. なぜその課題を解決するかを論じる
3. 課題解決の手法として複数の選択肢を挙げ、違いを論じる
4. 手法を選択した理由を論じる
5. 用いた手法によって課題が解決されたかを論じる
6. 第三者が出力したコードを扱うときは十分に理解して使う
7. 「十分に理解」とは、自分の言葉で説明ができるということである
8. 方針はアップデートされる

理念について

理念は私の中の大きな枠組みである。理念に基づき方針が決定された。何事も文章にすることで、理解は進むし、コーディングの腕も上がるはずだ。

思考とは言語。これはウィトゲンシュタインが同様のことを述べている。

matoyomi.hatenablog.com

余白と良さについては私の過去の記事を参考にした。常に考えるには、余白というか休息も必要だ。そして最後に決定を下すのは自分の心であり、良さである。これは道徳的観点や単純な趣味嗜好も含まれる。

matoyomi.hatenablog.com

方針について

実際にコードを書く上での方針である。開発とは課題解決である。そのため課題を明らかにし、ほんとうにその課題は解決される必要があるかも考えないといけない。コーディングはそれからの話だ。

方針に基づいた開発

課題と選択肢の提示

今回はERBファイルのlintツールを導入することとした。今までもlintは行っていたが、erbファイルは対象にしていなかった。コードの保守性を向上させるため、導入する。

手法はいくつかある。無難にerb-lint gemを導入する。他の選択肢を含めた表を以下にまとめた。

フォーマッタは使えそうだ。また次回にしよう。

実装

まずは以下のgemをGemfileに記載し、bundle install を行う。

GitHub - Shopify/erb_lint: Lint your ERB or HTML files

Gemfile

group :development do
  gem 'erb_lint', require: false
# 略
end

設定ファイルである.erb_lint.yml を作成する。readmeに記載している better_html_config: .better-html.yml は消す。これは別のgemであるbetter_htmlを用いる設定だ。

.erb_lint.yml

---
EnableDefaultLinters: true
linters:
  ErbSafety:
    enabled: true
   #  better_html_config: .better-html.yml　ここは削除
  Rubocop:
    enabled: true
    rubocop_config:
      inherit_from:
        - .rubocop.yml

lintから除外するファイルの設定

$ bundle exec erb_lint --lint-all を実行すると、700件以上の修正箇所が発見された。多すぎると差分がわからなくなるので、いくつかのファイルをerb-lintの対象から除外する。例えば /app/views/simulations/ 以下のerbファイルは数が多いので今日はやめる。 様子を見ながら、除外の対象を減らそう。

---
EnableDefaultLinters: true
exclude:
  - '**/vendor/**/*'
  - '**/node_modules/**/*'
  - '**/app/views/simulations/*'
  - '**/app/views/layouts/*'
  - '**/app/views/devise/*'
  - '**/app/views/terms/show.html.erb'
linters:
  ErbSafety:
    enabled: true

# 略....

erbタグが消える

lintを実行すると、必要なerbタグ自体がなくなっていた。もう一度ドキュメントを読むと、以下の記述があった。

Note: Each ruby statement (between ERB tags <% ... %>) is parsed and analyzed independently of each other. Any rule that requires a broader context can trigger false positives (e.g. Lint/UselessAssignment will complaint for an assignment even if used in a subsequent ERB tag).

https://github.com/Shopify/erb_lint?tab=readme-ov-file#rubocop

<% などは独立したコードとして解析されるようだ。.erb_lint.yml　に除外するルールを追加して対処する。

linters:
  ErbSafety:
    enabled: true

  Rubocop:
    enabled: true
    rubocop_config:
      inherit_from:
        - .rubocop.yml
      Layout/InitialIndentation:
        Enabled: false
      Layout/LineLength:
        Enabled: false
      Layout/TrailingEmptyLines:
        Enabled: false
      Layout/TrailingWhitespace:
        Enabled: false

bundle exec erb_lint --lint-allを実行し、指摘事項を確認したら、bundle exec erb_lint --lint-all -a を実施する。

できた。

Github Actionsへ適用

erb-lintをGithub Actionsに適用する。リポジトリにpushすると、他のlintやテストと共に実行されるようになる。

.github/workflows/testandlint.yml

name: "Ruby on Rails CI"
on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]
jobs:
  test:
# 略
      - name: erb lint
        run: bundle exec erb_lint --lint-all

これでできた。

終わりに

導入するだけしたが、結局今回はClaude Codeを使っていなかった。しかしこの記事でもって、私の開発方針というか理念が定まった。これを軸としてAIと共にコードに向き合うこととする。

Unsplash Peter Thomas

　本当に文章が書けなくなってしまった。それもこれもAIのせいである。彼らが出力するセンテンスはそれなりに必要十分なものであり、それを見定めてNO/GOするだけで満足してしまっていたのだ。このブログもAIに読み込ませてやれば、似たような記事をいくらでも公開することができるだろう。

　危機感を抱いた。たしかにこれからはAIを使えば文章作成などあらゆる作業が楽になる。けれども、考えることをやめたくはない。考えることによって、私自身の能力は向上するし、実際そうだ。

　中島聡さんの「結局、人生はアウトプットで決まる」を読んだ。アウトプットを継続的に行うことで自分の価値を高めて、AIに負けないようにしよう。という内容である。ブログの執筆や配信など、最近は自分の考えをアウトプットするのが簡単になった。容易いので、みんなも頑張ろう、と。

　アウトプットの手法はいくつか記述があったが、私に刺さったのは以下の言葉。

それは、あなたが「この情報を伝えたい」という「熱」さえ持てば、文章のテクニックうんぬんを抜きにしても十分さまになるということです。

　熱はたしかに重要だ。私が投稿した記事の中で反響が大きかったのは、自分が好きな気持ちが入っていたり、感情がこもっているものが多い。これとか。

matoyomi.hatenablog.com

　はてブをもらいやすい記事はなんとなく把握している。タイトルがノッている記事だ。炎上を狙っているというかそんなではなく、自分の気持ちが文章だけでなく、タイトルにも滲み出ているもの。悔しさとか嬉しさとか悲しさとか。中島さんが語っている「熱」もそれと同じものなのだろう。文章の技術や精度にとらわれていた気がするが、情熱が先にくるのだなと思った。

　自作サービスをリリースし、フィヨルドブートキャンプも卒業した。本来なこの流れでITエンジニアに転職する流れなのだが、それはやめた。今の会社でまだまだやりたいことがあるためだ。やりきったときに世間がどうなっているか分からないが、自分の気持ちに正直に生きる。AIに負けないようにアウトプットは続けていこう。

UnsplashWolfgang Hasselmann

結局、人生はアウトプットで決まる　自分の価値を最大化する武器としての勉強術

• 作者:中島 聡
• 実務教育出版

Amazon

　梅雨は思ったよりも早く終わることになった。隣の家のアジサイが、中途半端な加減で枯れていく。雨が多いのは嫌いだけど、ないならないで寂しい気持ちもある。

　今月はなにも記事を書いていなかったので、六月の最終日にこうして文章をまとめている。いろいろあったはずだけど、何も覚えていない。

　FBCの課題を進めていた。自作サービスはデザインレビューが終了し、残りはコードレビューだけになった。しかし、指摘事項が多く、まだまだ完成しそうにない。

JacaScriptのファイルをいくつか書いているが、それぞれが互いに参照し合う状態になっていて、あまりよろしくない。依存関係を整えてあげる必要があった。ただ、それをしようにも互いの関数を参照しあっているので、うまく分割してあげないといけない。

ジークアクスは終わってしまった。よく分からない場所が多かったのは、きっとよく分からないということなんだろう。もっと他の作品を観て予習しておけばよかった。そういう理由で、ファーストを観終わり、いまはZガンダムを観ている。OP曲が素晴らしかった。

来月はもう少しアウトプットを多くしよう。言いたいことがたくさんあるはずだけれど、そのままになっている。

　日々の文章のよりを貯めすぎるのも考えものだ。どうでも良いことはどうでも良い時に書いておかないと、忘れてしまうし、風味が逃げてしまう気もする。AIが登場し、それらで文章を出力する機会が増えてから、町中に散らばっている言葉たちは「あれは人間が考えたセンテンスではないのでは」と身構えるようになった。正しい日本語、整った日本語、と言っていた時代が懐かしく思える。

　久しぶりにWiredという雑誌を読んだ。宇多田ヒカルが表紙だった。量子コンピュータについて書かれていた。あまり意味がわからなかったけれど、自然界が量子力学で動いているというのはしっくりきた。

自然界は量子力学の法則で動いている。例えば、なぜ水は0度で凍り、100度で沸騰するのか。これらは水分子中の電子の振る舞いという量子力学的な効果から説明され、残念ながら0と1の掛け算と足し算という法則では動いてない。

“世界の箱庭”たる量子コンピューティングは、何を変えるのか | WIRED.jp

　現実世界が処理落ちしない理由を考えたことがある。量子力学で実装されているなら、処理落ちしないのかもしれない。計算量うんぬんではなく、計算・表現の仕方がいままでのコンピューターと違うのだろう。

　そうなってくるとAI、情報工学のつぎは有機化学が主流になりそうだ。AIによって計算するパワーは増えた。量子コンピュータがもっと量産されたら、必要な計算量自体がぐっと減る。そして、情報工学を自然界にうまいことドッキングさせるのが流行ってくるだろう。あと二十年後にはAIは死語になっているかもしれない。

　フィヨルドブートキャンプの課題を進めていた。やっと自作サービスがひととおり完成した。コードレビューの依頼を行った。これで指摘された事柄を修正し、リリースブログの下書きを書けば卒業できる。長い長い戦いだ。

　しかし卒業しても、なにも変わらないかもしれない。今まで通りの生活を送るだけかもしれない。それはそれ。

UnsplashDaniil Silantev

WIRED（ワイアード）VOL.56

• 作者:Condé Nast Japan (コンデナスト・ジャパン)
• コンデナスト・ジャパン

Amazon

子供が今日の宿題として国語の文章の音読を始めた。「ケルルンクック」という単語が出てきて、私は自身の過去を思い出した。担任の先生は若いお兄さんで、「ケルルンクック」とはどう言えばいいのかなどと授業でとりあげていた。私が「ケルルン→クック↑！！」と威勢よく言うと、クラスメイトたちは笑っていた。バカにされた気がして、自分で言っておきながら私は泣いた。どうでも良い記憶。

若いお兄さんは当時29歳だったはずだ。

私は今日36歳になった。

　36歳になっていた。なんの感慨もない。去年はずっとコードを書いていた。フィヨルドブートキャンプのカリキュラムのうち、チーム開発を修了した。思ったよりずっと長かった。コードを書くよりも読む方が時間がかかり、そしてレビューを待つことや他のIssueによって問題が解決されるのを待つ時間はそれよりずっと長かった。そのようなものだ。

　自作サービスはやっとデザインレビューを依頼できた。それによって指摘された箇所のデザインをいまは修正している。これが終わればコードをレビューを依頼して、それで修了。リリースブログを書けば卒業できる。

　去年はその合間に資格試験を受けて、合格した。IPAのプロジェクトマネージャ試験。もう何も覚えていないレベルなので、合格体験記など書けるわけがない。この資格を取ったことのメリットは今のところない。資格手当が増えるわけでもなく、いまの業務で適用できる知識はない。でも勉強自体は面白い。資格はまた落ち着いたらなにかとりたい。数学検定とか。

　子供は大変。長男は小学四年生になった。立派に成長したけどそれは体だけで、まだまだ幼い。昆虫、城と興味の対象が移り変わり、こんどは釣りときている。ダイソーのサイトを開いて「これとこれを買って」と呟いている。将来は小学校の先生になりたいのだとか。まじか。

　次男はもっと大変。四月から支援学校に入学し、なんとか頑張っている。今月に入ってから五月病になったのか、ちょっと荒れている。疲れもあるのだと思うし、座学は退屈なのだろう。年末年始に風邪をひいてから腎炎もどきにかかり、運動が制限されている。尿検査の値が正常になるまで、トランポリンも満足にできない。ベッドのマットレスでめっちゃ飛んでるけど。それでもトイレで用を足せる回数が増えてきたし、フォークやスプーンも使えるようになった。成長している。

　妻は毎日忙しそうにしている。次男をバス停まで送ったり、病院へ通院させたり、役所に行って手続きをやったりしている。お疲れ様です。去年から推し活が再開され、ガンダムSEEDやコナンを観ている。楽しいらしい。それは良いことだ。

　この一年はどんな歳になるか。わからない。わからないまま過ぎていくのだろう。まだまだコードを書いていたい。これが仕事になればいいのになあ。

UnsplashZetong Li

　長い長い春休みは先週終わった。次男はいままでより二回りほど大きい鞄を背負い支援学校へ通うようになった。なにも話さないためそこの様子は連絡帳でしか把握することができないが、割と元気にやっているらしい。放課後デイも週一で利用するようにしたが、そこでも楽しくやっている。「これなら私もバイトできるかな」と妻。それがいいかもしれない。

　仕事の強度が少しずつ弱まっていき、本当に暇になってきた。いよいよやることがない。しかしこうして暇をしていると、よその部署に異動になるかもしれないので、定期的にやることを生み出さないといけない。ここでの生活は面白いものだ。どこかで書いたかもしれないが、日々の業務は具現化そのものだ。自分が思い描いた装置やラインを図面に起こし、製作する。理想と実際ではかならずギャップが生じるが、そのギャップをなるべく少なくする。ものづくりとかいう作業はこうして行われる。

　コードをいまだに書いている。作成途中のウェブアプリケーションもようやく終わりが見えてきた。細かいデザインをいれていき、そこで一旦終わり。レビューをいただきながら並行してテストを書いたりしていこう。

　そろそろ紙の文字を読まないといけない。久々にWIREDという雑誌でも買おうか。

UnsplashJean Carlo Emer

　次男が卒園した。短い式だった。彼が通っていた療育園では二十数名の園児たちが式に参加し、それは自由に証書を受け取っていた。皆で歌を歌っている間、次男は終始体を前後左右に振っていた。

　帰りの車内で、もうあの園に行くことはないのだよと伝えると、急に泣き出した。私は話がわかったのか、と驚いたが何のことはなく、空腹になっただけだった。昼食を食べると元に戻った。それでも卒園時の歌をうたおうとすると、自分の頭を叩き出したため、なにか悲しいことは理解しているようだった。そのようなものだ。

　長男は小学校の先生になりたいらしい。数年前は虫博士で、この前までは歴史学者だった。小学校の教員免許は取得できる場所が限られている。少しずつ将来の幅が狭まっているというか確定していくというか、彼もひとりの人間になっている。私の預かり知らぬところで。

　この間学校の工作物を持ち帰ってきて、私に自慢してきた。豆電球を使った懐中電灯らしいが、なんとスイッチがついている。板バネのような厚紙を押すと、電球が付くのだ。厚紙の両端にプラスとマイナス極の電線が取り付けられ、それぞれがアルミホイルで巻かれている。なるほど。学校では習わず、この機構は独自に考えたものらしい。

　彼は先生というより研究者向きだよね、でもドクターまで行かせると学費がかかるしなあ、などと妻と話した。次男は寝て、長男は団体の宿泊研修に向かったためその日は静かな夜だった。ここまでゆっくり会話できるのは珍しい。

　仕事はよく分かんないけどなんか分かってきた。役職もあと一つ上がったら、それで定年まで終わるのかもしれない。でもそれは嫌だなあと思っていた。もう少し偉くなりたい。偉くなると自由にできる。もっと自由に好き勝手やって生きていきたい。

　脈絡のない文章だ。

Unsplash Steve Gribble

　思い出したように本棚から文庫本を出してきてはすきまの時間を見つけて読んでいた。しかしそれも長くは続かない。好奇心というか物事に対する興味が薄れいているような気がする。なにかが蓋をしているという言い方もある。結局はいま作成中のWebサービスを作りきらないと前に進めない。そういうことなのか。

　Backlogのユーザーコミュニティの勉強会に参加した。今回のテーマはドキュメント。どの業界でも職種でも、ドキュメントには向き合う必要があるようだ。

jbug.connpass.com

speakerdeck.com

　中野さんの発表。良かった。構造化とは伝えたい項目をもれなくダブりなくまとめることである。「網羅的かつ誤解なき言語化」という言い方がしっくりきた。しかし、単純にそれだけではない。ドキュメントは問題解決のために作るもの。「誰に何を伝え、最後にどうなれば良いのか」を見据えて書くのだと。問題が解決できるのであれば枠組みからはずれても構わない。なるほど。

　AIが台頭する昨今、ドキュメントを書く意味を考え直さないといけない。彼らもドキュメントを作成してくれるのだが、こちら側の指示も大事だ。答えだけを尋ねるのではなく、答えにたどりつくために必要そうな項目を考え、それらを適切な粒度・順序でまとめてから指示を出す。そうすると良い。

そうか。

www.docswell.com

　私も少しだけ話をした。ドキュメントはあまり整備されず使われることはないが、それでも現場の声を聞けば少しは良いものにはなるだろうということ。「じゃあどうやってやるか」を考えていたけど、今回の勉強会でなんとなく見えてきた。Backlogのドキュメント機能を使ったらいいのではないか。

　Backlogの新機能である「ドキュメント」はWikiとは異なり、リッチテキストをそのまま使うことができる。非IT系の人間にとってMarkdown記法は馴染みがないからやりやすそうだ。変更管理、差分管理もできるようだ。単純なエクセルだと「誰がなにをいつ変えたか」がわからない。これはできる。良い。

　あとは機械設計書、ライン設計書をドキュメントでつくるのも良い。図面管理とはまた別の考えだ。その仕様にいたった経緯が後任にも伝わりやすい。別途で「過去の不具合リスト」をつくっておき、それを参照させるというやり方もできそうだ。

　Backlogはプロジェクト管理のツールという認識だったが、ドキュメントの運用・管理のツールとしても使えそうだ。ちょっと社内で使えるように調整しないといけない。

　所用で帰ることになってしまい残念だった。次は最後まで参加したい。

Unsplash Benaja Germann

　我が家が増えすぎた家財を空き部屋に移すようになって、既に半世紀が過ぎていた。分解されたボールプールは第二の遊び場となり、子供らはそこで球を投げ、おやつを食べ散らかし、（叱られて）死んでいった。

どうでもいいことだった。

　気がついたら年が明けていた。時代に取り残されている。私は相変わらずコードを書いている。グラフとして描かれているノードとリンクが、異常なものかを検出するメソッドを考えていた。結局それは深さ優先探索と呼ばれるアルゴリズムを使うことで実装できた。

新しいガンダムの映画を観た。話は良くわからなかったけど、絵はきれいだった。音楽も良い。ここからまたアニメが始まるようなので、それも観ていきたい。

来月久しぶりに勉強会に参加する。

https://jbug.connpass.com/event/342193/

家族の体調が皆良いことを祈るばかり。だいたい誰かの調子が悪くなるので。

今回はどんなことを話そうか考えよう。

Unsplash Andrei R. Popescu

午後十時。抗生剤入りのジュースを次男は疑り深そうに眺めていた。しばらくして、ストローの先をそれにつけてぺろぺろ舐める様を、私たちは笑いを堪えながら見守っていた。それだけの年末である。

長男だけさきに妻の実家に配送し、我々三人はあとから向かう。次男が熱を出していたというのもあるし、そのほうが義母の負担も少ないだろうというものだった。

諦めるのを諦めた一年だった。ウェブエンジニアになりたいなならなくちゃ絶対なってやる、という風潮もあったが到底無理な話だった。時間が取れない。次男は二月に一回発熱し、二日に一回夜中に起き出し、一日一回は暴れまわる。腰を落ち着けて、まとまった時間を使って勉強することはできなかった。それでもコードを書くのは嫌いではなかったので少しずつやることにした。工夫も何もなかった。彼が起きる前にコードを書き、起きてくればそれは終了された。

仕事はものすごい暇になったので、ほんとに暇を出されるのではと不安になったりした。社内の顧客から依頼された細々としたものごとを片付けて、その結果を社内でお知らせすることにした。（そういう風習があった）　わりと好評らしく、評価が上がった。評価が上がるということは給与が上がるということだ。そのようになった。

その調子で社内での自由度を高める活動にシフトした。自分がやりたいことと会社が求めていそうなことを合わせるようにして、提案する。許可されたので私は業務でコードが書けるようになった。なんということだ。

IPAのプロジェクトマネージャ試験を受けることにした。応用情報を取得して早二年。今年受けないと、一次免除の資格がなくなってしまうためだ。この学習はそれほど時間をかけていない。これは専門知識を問われることはあまりなく、国語の試験だった。準備しておいた経験談のみを書くのではなく、設問に対してちゃんと述べるように、調整した。そして合格した。

目標とか夢というものは、どこか遠くにあって、それに向かって走っていく。そうイメージしていた。しかし実態は違って、見方を変えると急にそれが隣にいたり、頭から降って湧いたり、背中をつんつんされる。そういうものだったのか。理解した。

来年はフィヨルドブートキャンプを卒業する。これは何があっても必ずやる。あとのことはどうでもいい。自分がやりたいことをやる。それさえできればいい。

UnsplashArt Institute of Chicago

凍えそうな季節ではある。少し間前でHotLimitで悩んでいたのが嘘のようだ。長男はすでに起きていて、そばでYoutubeを観ている。以前は無音あるいは作業用BGMを流さないと文章が書けない私だったが、今はそうも言ってられない。

Hotwireという概念を学んでいる。これはJavaScriptを書きすぎずに、モダンなウェブアプリケーションをつくるための手法である。Railsのバージョン7以降からデフォルトに搭載されるようになっており、Railsで書ける。他の言語を学ぶ必要がなくなるため、一人で開発をする私にはあっている。はず。

HotwireはTurbo/ Stimulus/ Native　という三つの機能というかパーツというか概念がある。Turboは画面遷移を司り、Stimulusは状態管理を行う。Nativeは今ひとつわからないが、モバイルアプリを作る際につかうようだ。ここではStimulusだけを紹介しよう。

公式ドキュメントの紹介によるると、Turboでは既存のJavaScriptが必要な処理のうちの80%をカバーしている。部分的にレンダリングを行うことなど、いろいろできるようだ。残りの20%をStimulusがカバーできる。

Stimulusのドキュメントを追う。StimulusはJavaScriptのフレームワークである。核心なのはdata-controllerか。それはJavaScriptのオブジェクトであって、その中の要素を変化を監視し、変化によって様々な処理を行う。

そのなかにaction,target, valueがある。すこしわかってきた。

Stimulusのはじまり

stimulusの環境構築が終わったら、divタグの中にdata-controllerという属性を設けて、コントローラーを宣言する。コントローラーの名前によってファイル名を参照するようだった。

 <div data-controller="simulationmode" id="simulation-controller">
</div>

app/javascript/controllers/simulationmode_controller.js

import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
}

初期状態の設定

https://stimulus.hotwired.dev/handbook/managing-state#lifecycle-callbacks-explained

コントローラーの中で connect() メソッドを宣言することで、コントローラーがDOMに接続された状態（この表現が正しいかわからない）ときの処理を書くことができる。今回は状態を管理させたいので、その値を設定させる。

import { Controller } from "@hotwired/stimulus";

export default class extends Controller {

  STATES = {
    SELECT: "select",
    ADD_OPERATOR: "add-operator",
    ADD_FACILITY: "add-facility",
  };

  connect() {
    this.State = this.STATES.SELECT;
    console.log(this.State);
  }

イベントとの紐付け

　ラジオボタンをつくり、それが押された時のイベントを設定させたい。data-action という属性でもって、メソッド名と紐付けを行う。今回は以下のように状態を管理するようなメソッドを作った。

 <div data-controller="simulationmode" id="simulation-controller">
    <fieldset>
        <span>
          <input
            type="radio"
            name="mode"
            id="editMode"
            checked
            data-action="simulationmode#edit">
          <span>編集</span>
        </span>
      </label>
        <span>
          <input
            type="radio"
            name="mode"
            id="simulateMode"
            data-action="simulationmode#checkSimulate">
            <span>実行</span>
        </span>
    </fieldset>
</div>

app/javascript/controllers/simulationmode_controller.js

import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  STATES = {
    SELECT: "select",
    ADD_OPERATOR: "add-operator",
    ADD_FACILITY: "add-facility",
  };

  connect() {
    this.State = this.STATES.SELECT;
    console.log(this.State);
  }

  edit() {
    this.State = this.STATES.SELECT;
    console.log(this.State);
  }

}

まとめ

このくらいのコード量なら純粋なJSを書いた方がはやい。しかし、もう少し複雑になってくるとHotwireのほうが管理がしやすくなる。フロントエンドのコードを新しく覚える必要がなく、少しずつ適用できるので個人開発には向いている。

Hotwireを積極的に使っていこう。

UnsplashMarek Piwnicki

　午前二時。一息で書き切らないといけない。子供が起きてひどいかんしゃくを起こし、妻が彼をつれてドライブに向かった。今日の予定は詰まっており、この時間帯でないと私は文章を書けない。そういうことになっている。

フィヨルドブートキャンプアドベントカレンダー 2024の7日目の記事である。

　昨年よりフィヨルドブートキャンプというスクールに入会している。カリキュラムが難しい、という話も聞くが、私にとってはそれほど問題にはならない。一番の問題は時間の確保である。

普通にフルタイムで仕事をしていて、家に帰ると子供らの相手をしている。休日も同様。そうなってくると彼らが寝ている時間でしかカリキュラムを進めることができない。一日に使えるのは一時間程度。運が良ければ二時間できる。

これ以上時間を確保するのは難しい。睡眠時間を削ることもできるが、やりすぎると体調を崩し、パフォーマンスが下がる。（何度かそういうことがあった）

しかし、解決策がないわけではない。頭の中でコードを書くことにした。カリキュラムを進めるには、方法を考えて実装するを繰り返すだけ。考えることはPCに向かわなくてもできるのだ。

思考とは言葉である。フィヨルドブートキャンプの日報に実装方針やエラーの原因を書き残す。そうすることで、何をやるかが明確になり、少ない時間でコードがかける。

そういう感じで進めていった。

裏技がないわけではない。会社でフィヨルドブートキャンプを取り組めればいいわけだ。現在自作サービスのカリキュラムを進行中だが、この成果物を会社で公開するよう調整できた。つまりは業務時間内に自作サービスが進められるのだ。

二拠点開発が可能となった。自宅でバックエンドをやり、会社でフロントエンドをやる。ブランチを切りながらやれる。かけられる時間は倍になる。

このように、常に時間とたたかっている。

おわり。

Unsplash Marek Piwnicki

　大学時代の夢を見た。サークルのメンバーが書いていたノートが部室にあって、私はその表紙だけちらと確認していた。そのサークルは文章を書くのが主な活動だったが、私はほとんど幽霊のように存在していた。なぜそこに入ったのか、あまり覚えていない。目覚めてからそのサークルを調べてみたが、いまも実在しているようだ。すこし安心した。

　まったく関係のない話をしていた。これはエンジニアと人生 Advent Calendar 2024の一日目の記事。タイトルだけ決まっていたから、あとは好きに書こう。

　数年前に「未経験エンジニア転職を諦めた」という話をした。

matoyomi.hatenablog.com

現職では図面を書いたり機械の修理をしたり、ものをつくったりしている。機械系エンジニアと呼ばれる職種である。記事に対するコメントで「すでにエンジニアでは？」「エンジニアをITエンジニアの意味合いで使うな」という内容をいただいた。確かにそうだった。

　それでもコードが書きたかった。寝食を忘れるほど好きと言うわけではなかったが、嫌いではなかった。なんというか、しっくりきた。毎朝趣味のリポジトリにコミットを積んだり、ロジックの中身を考えたり、エラーの原因を考えたり。そういうふうに時間を使うのが自分の中で非常に自然で楽であった。

　好きなことを仕事にしたい。コードを書くことを業務でできればどんなに良いか。

　以前に「なぜ あなたの仕事は終わらないのか」という本を読んだ。「好きなことを仕事にすれば集中力を上げる必要もなく、仕事を早く終わらせることができる」という趣旨だった。著者は好きなことを仕事にしようぜ、という人間らしかった。これは意見が分かれるところなので、絶対そのほうがいい、とはならない。でも私は好きなことを仕事にしたい人だった。なるほど。

　やりたいならやろう。社内で少しずつIT系の仕事をとっていくことにしていた。とるというより、自分で率先して仕事をつくっていた。マイコンを使って設備の稼働状況を表示させたり、あるセンサーが閾値を超えたらメールでお知らせが届くようにした。そんな俺俺システムをつくっては、社内で発表した。

　しかし進捗は良くなかった。本業の合間をぬって作業をしているから仕方ない。これが本業であればどんなに良いか。あともうひと押しなにかあれば変わりそうな空気ではあった。

　そこで社内の体制が変わった。具体的なことは書けないが、今の職種のまま社内でコードを書けるようになった。機械設計の傍ら、Githubのリポジトリにpushができる。これはもうITエンジニアのようなものだ。現在作成しているシステムがどのような運用になるかわからない。わからないが、やりたいことに近づいたのは確かだ。

　本当のことをいうと、この経歴が社外からみても実務経験とみてもらえたらありがたい。そのためにはもっとコードを書く必要があって、それを発信する場所も必要だ。現職はかなり自由だ。自由なうちに会社で使えるものはすべてつかっていこう。そしていつかは宇宙に行く。

Unsplash Marek Piwnicki

前書き

　午前中ずっと降り続いていた雨は突然として止み、子供らが庭にわらわらと集まってきた。最近はけん玉がブーム用で、お互いが技を繰り出している。空気中のちりほこりが雨で洗い流されたためか、空気澄んでいる。平和な世界だ。

Webサービスの話

　WEBサービスを引き続きつくっている。JavaScriptのテストを書いていた。入力フォームに値を入れて保存を押すと、任意のJavaScriptのオブジェクトの値が変わる。実際にはしっかりと動作していているが、これをテストするのに少し苦労した。忘れても良いように、ここに書いておく。

　JavaScriptのテストツールはJestを導入した。ドキュメントも日本語のものがあり、参考になるページが多くありそうだったためだ。JestだけでなくTesting Libraryというツールも導入する。

Jest · 🃏 Delightful JavaScript Testing

Testing Library | Testing Library

コードの紹介

　はじめにテストしたい関数をexportする。今回はapp/javascript/src/simulation.js　の一部である。

//略
export function setObjectparams(e, params, facilities, facilityDialog) {
  e.preventDefault(); 
  let id = params.id;
  let name = params.name;
  let processingTime = params.processingTime;
  let selectedFacility = facilities.find((facility) => facility.id == id.value);
  selectedFacility.name = name.value;
  selectedFacility.processingTime = processingTime.value;
  facilityDialog.close;
}

// 略
export function setFacilityDataToModal(facility) {
  let id = document.getElementById("hidden-id");
  let name = document.getElementById("name");
  let processingTime = document.getElementById("processingTime");

  id.value = facility.id;
  name.value = facility.name;
  processingTime.value = facility.processingTime;
}

　次にテストファイルを作成する。app/javascript/test/savesimulation.test.js とした。

import { fireEvent, screen, waitFor } from "@testing-library/dom";
import "@testing-library/jest-dom";

import { setObjectparams } from "../src/simulation.js";
import { setFacilityDataToModal } from "../src/simulation.js";
let facilities;
let facilitiesInitial;

beforeEach(() => {
//略
  facilities = facilitiesInitial;
});

test("button click and set params", async () => {
//　ここにテストを書く
});

解説

　import { fireEvent, screen, waitFor } from "@testing-library/dom"; で　@testing-library/dom　から fireEvent などのオブジェクトを扱えるようになる。

　import { setObjectparams } from "../src/simulation.js";　でローカルのファイルからexportされた関数 setObjectparams が使える。

　beforeEach は各テストが実行される前に処理される部分。 test(.. はテストだ。今回は非同期処理を含むので、引数の指定に非同期処理の関数 async が入っている。

テストを書く

1. テスト用にDOMをセットアップ

　実際のサービスで使うDOMでなく、テスト用のDOMを準備する。

test("button click and set params", async () => {
  const div = document.createElement("div");
  div.innerHTML = `
    <dialog id="facilityDialog">
      <div id="hidden-id" hidden></div>
      <div>
        <label for="name">設備名</label>
        <input type="text" id="name" name="name" maxlength="16" size="15" />
      </div>
      <div>
        <label for="processingTime">加工時間</label>
        <input type="number" id="processingTime" name="name" min="0" max="400" />
      </div>
      <div>
        <button id="confirmBtn" value="default">保存</button>
      </div>
    </dialog>
  `;
  document.body.appendChild(div); 

2. 値のセットと値の取得

　実際の作成した関数 setFacilityDataToModal() を使って、テスト用のDOMの入力フォームに値をセットしておく。それができたら次はDOM上から名前と加工時間を取得する。

　fireEvent.change を使うことでフォームに値を入力させることができる。

　あとはボタンを押した時のイベントを追加する。

  document.body.appendChild(div); 
  setFacilityDataToModal(facilities[0]);

  const nameInput = screen.getByLabelText("設備名");
  const processingTimeInput = screen.getByLabelText("加工時間");

  fireEvent.change(nameInput, { target: { value: "Test Facility" } });
  fireEvent.change(processingTimeInput, { target: { value: 30 } });

  const button = screen.getByText("保存");
  button.addEventListener("click", (e) => {
    let params = {};
    params.id = document.getElementById("hidden-id");
    params.name = document.getElementById("name");
    params.processingTime = document.getElementById("processingTime");
    let facilityDialog = document.getElementById("facilityDialog");

    setObjectparams(e, params, facilities, facilityDialog);
  });

3. DOM操作が終わったあとに差異をみる

　テストコードの中でボタンを押し、そのイベントによってDOMが操作される。（今回はモーダルウィンドウが閉じる）さらにはJavaScriptの変数の中身が変わる。それをテストする。

//上のコードのつづき
  await fireEvent.click(button);

  await waitFor(() => expect(screen.queryByText("設備名")).not.toBeVisible());
  let selectedFacility = facilities.find((facility) => facility.id == "n0");
  expect(selectedFacility.processingTime).toBe("30");
  expect(selectedFacility.name).toBe("Test Facility");

waitFor... を使うことで、モーダルが閉じてからそれ以降のアサーションを実行できる。モーダルウィンドウが閉じるのはDOMがなくなるわけではなく、見えなくなるだけである。だからnot.toBeVisible() を使っている。

以上。だいぶ長くなってしまった。 　

Unsplash Marek Piwnicki