概要 自分はさくらのVPS上でKonbuやNBAMashのようなWebアプリを運用している。 最近、ローカルで操作しているつもりが実はVPS上で操作をしていて、うっかりコンテナを落としてしまうというミスを多発させてしまった。 そこで本番環境にSSHログインをした際にはターミナルの配色を変更して、視覚的に本番環境とローカル環境を差別化することで本番環境での誤操作を防ぐことにした。 方法 .bash_profileに以下のコードを追加した。 # ssh接続時に文字色と背景色を変更する関数 function ssh() { if [[ "$TERM_PROGRAM" == "vscode" ]]; then DEFAULT_COLOR="#CCCCCC" DEFAULT_BG_COLOR="#171717" elif [[ "$TERM_PROGRAM" == "Apple_Terminal" ]]; then DEFAULT_COLOR="#000000" DEFAULT_BG_COLOR="#FFFFFF" fi # SSH接続時に文字色と背景色を変える echo -ne "\033]10;#FFFFFF\007" echo -ne "\033]11;#330000\007" # 実際にsshを実行 command ssh "$@" # 接続終了後に元の文字色と背景色に戻す echo -ne "\033]10;${DEFAULT_COLOR}\007" echo -ne "\033]11;${DEFAULT_BG_COLOR}\007" } コードを順を追って説明する。 まずは以下のようなsshの関数を書くことで、デフォルトのsshコマンドを上書きする。 引数は$@で取得できるので、ssh 引数1 引数2 ...のように実行したら、関数の内部でもちゃんとssh 引数1 引数2 ...のように実行される。 # ssh接続時に文字色と背景色を変更する関数 function ssh() { (...中略...) # 実際にsshを実行 command ssh "$@" (...中略...) } 次にデフォルトの文字色と背景色を変数に格納する。 ...

概要 社会人になって気づいたのだが、会社の中には安全圏からやたらと口出しをしてくる人がいる。 自分自身は特にリスクを背負うこと無く、その場の思いつきのアイデアを他人に投げかけて、他人のリソースを消費させてしまう人がこの社会には少なくない数存在しているのだ。 この記事ではそういった人に対する対処法を紹介する。 口出しを受け入れるかどうかの判定法 まずは口出しを受け入れるかどうかの判定法を紹介する。 口出しする人は基本的に「クライアントのために〜」とか「社会への貢献を〜」のようなきれいでカッコいい言葉を使ってこちらを説得しようとしてくる。 表面上は良いことを言っているので気を抜くと説得されてしまいそうになるのだが、事前に口出しを受け入れるかどうかの基準を設けておくことによって、言葉のきれいさに惑わされることなく冷静に判断を下すことができるようになる。 自分の場合は2つの判断基準を設けている。 1つめは「口出ししてくる人が精神的な負担を背負うのかどうか」だ。 要するに、口出ししてきた人が最終的な責任を負うのかどうかということだ。 口出しによって発生したタスクであなたが失敗した時に、口出ししてきた人が矢面に立って顧客に頭を下げるのならば、その口出しは受け入れても良いと思う。 なぜなら最終的に責任を取ってくれる人の口出しは本気で現状を良くしようとしている可能性が高いからだ。 逆に放任主義で「お前のミスはお前のミス」のようなスタンスをとる上司の口出しは無視しても良いだろう。 2つめは「口出ししてくる人が物理的な負担を背負うのかどうか」だ。 口出しした本人がそれによって多少なりともリソースを消費するのであれば、先程と同様にその口出しの本気度は高くなる。 逆に口出しした本人が一切のリソースを消費しない場合は、カッコつけたくて口出ししているだけの可能性も高い。 そのような口出しは本気度が低い可能性が高いので無視しても良い。 以上が個人的な口出しを受け入れるかどうかの判定法だ。 「精神的負担」も「物理的負担」も背負ってくれない人の口出しは基本的に無視するように基準を設定している。 逆にどちらか一方でも満たす人の口出しであれば、受け入れるかどうかは一考の余地があるのではないだろうか？ 口出しする人への対処法 次に上記の基準を用いて口出しを「受け入れない」と判定した場合に、どうやって対処するかを紹介する。 これも大きく2つの方法があると思う。 1つ目は「適当に返事だけしておいて無視する」という方法だ。 両方の基準を満たさないような人はその場のノリで適当にカッコつけて口出ししていることも多い。 信念のない場当たり的な口出しは本人の中でも上手く落とし込めていないことが多いので、時間の経過とともに自然と忘れてくれる可能性が非常に高い。 口出しする人が普段から適当な人なのであれば、忘れることに賭けて無視するというのは有効な手段だ。 2つ目は「相手を巻き込む」という方法だ。 つまり口出ししてきた相手に精神的負担か物理的負担を強いることで、相手を基準を満たす人間に変化させるということだ。 これは使用方法を間違えると関係が悪化しかねないが、上手く使うと効果は絶大だ。 例えば「あなたがそのタスクに本気で取り組むのなら私も手伝います」というように「あなたがやる」→「私がやる」という物理的負担の矢印を作ることで相手に圧をかけることができる。 この時点で大半の人は口出しを引っ込めてくれる。 もし相手が圧に屈せず「やってやらあ！」となった場合もどうせ長続きはしないので、事前に「あなたがやる」→「私がやる」という構図を作って置くことで、相手がサボり始めたタイミングで自分も堂々とサボってフェードアウトできるようになる。 1つだけ注意点があり、それは「一緒にやる」と言ってはいけないということである。 「一緒にやる」という構図を作ってしまうと、相手は「ちょっと今回だけ忙しいから先にやっておいて」などと言って、徐々にフェードアウトしようとしてくる。 なので「あなた」→「私」という構図はくどいほどに徹底することが重要だ。 ちなみに精神的負担を背負わせるのは難しいと思う。 「精神的負担を背負わせる」ということは大抵の場合は「最終責任を負わせる」ということを意味し、これは「あなた」→「私」という矢印を構築することが難しくなるからだ。 精神的負担を背負わせたつもりが、知らぬ間にフェードアウトされている…というオチになるのが関の山だ。 「あなたが今までの〇〇倍の契約金で案件を取ってくるならやってもよいですよ」ぐらいが精神的責任を負わせる限界だろうか。 したがって、個人的には物理的負担を背負わせるほうが成功率が高いと思う。 口出しする人がきれいでカッコいい言葉を使うタイプの場合に巻き込む手法は特に有効だ。 相手もカッコつけてしまった手前、自分が巻き込まれそうになった場合に「いや、俺は君と違って忙しいんだ…」のようなダサい言い訳で逃げることが難しくなるのだ。 面と向かって言うのは勇気が必要だと思うが、経験上この手法はかなり有効だ。 まとめ 精神的負担も物理的負担も背負っていない人の口出しは必ずしも受け入れる必要はない。 受け入れたくない場合は「分かりました」と言いながら無視するか、相手を巻き込むことで大抵の場合は面倒事を回避できる。 中島みゆきも「その船を漕いでゆけ おまえの手で漕いでゆけ 精神的にも物理的にも負担も背負わぬ者に おまえのオールをまかせるな」と歌っている。 俺達には中島みゆきがついているんだ。 勇気が出るだろう？

概要 デザインパターンの勉強をしたいと思ったので『Java言語で学ぶデザインパターン入門 第3版』を購入した。 転職先で未経験のJavaを扱うことも決まっていたので、Javaとデザインパターンを同時に学べるのは一石二鳥だと思い即決。 今回はその感想を書いていく。 #PR Java言語で学ぶデザインパターン入門 第3版 楽天 Amazon 良かった点 1. わかりやすい 本書は説明が豊富で、章ごとに考え方のヒントやクラスの役割などが丁寧に解説されている。 特に豊富なUMLが理解を大幅に手助けしてくれた。 余談だが、自分は新卒1年目のときに『オブジェクト指向設計実践ガイド』という書籍を読んで、その内容の難しさに挫折してしまったことがある。 本書と『オブジェクト指向設計実践ガイド』は趣旨の異なる書籍だが、テクニック自体は共通している点も数多くある。 本書はかなり説明が分かりやすく、Javaの継承やインタフェースさえ理解していればスラスラと読み進めることができるので、本書を中間セーブポイントとして利用することによって『オブジェクト指向設計実践ガイド』の内容も理解できるようになるのではないかという気がしている。 また機会があれば『オブジェクト指向設計実践ガイド』にも挑戦してみたい。 #PR オブジェクト指向設計実践ガイド 楽天 Amazon 2. 演習がある 本書では各章の末尾に演習問題が用意されている。 本文を目でなぞっていただけのときには気付けなかったことに演習を通して気づくことが何度もあり、かなり学びになった。 演習内容も設定がシンプルかつ面白くて、飽きずに取り組めた。 特に第23章の演習は骨太でかなり楽しかった。 デザインパターンの難しさ 本書に対する不満点は特に無いので、ここからはデザインパターン自体の難しさについて個人的に思ったことを書いていく。 1. 使い道がわからない 「これって本当に使い道あるのか？」と思ってしまうようなデザインパターンがいくつかあった。 Wikipediaのデザインパターンの記事を見ると、本書でも紹介されているGoFによる23のデザインパターンが『Code Complete』という他のデザインパターンの書籍で紹介されているのかどうかを一覧することができる。 そして、直感的に「これって使い道あるのか？」と感じたデザインパターンの大半は『Code Complete』では紹介されていなかった。 『Code Complete』は後発の書籍なので、GoFのデザインパターンの中でも特に使用頻度が高いものだけを厳選したのだと思う。 つまり『Code Complete』で紹介されていないデザインパターンは、使用頻度が低いものだと考えても問題はないだろう。 なので、本書を使ってデザインパターンの勉強をするときは、使う頻度が多そうか少なそうかでメリハリを付けて学ぶのが良いと感じた。 2. 違いがよくわからない デザインパターンの中には違いがよくわからないものがあり、「あれ、これさっきも勉強したような…」となることがあった。 そういうときは前のページに引き返して復習すればいいんだろうが、「とはいえコード自体はスラスラ読めてちゃんと理解できているし、デザインパターンのそれぞれの違いを言語化できるレベルまで理解する必要もないか」みたいに面倒くさがっている自分も存在した。 冷静に考えると、デザインパターンの凄さというのは暗黙知に境界線を引いて「この暗黙知にはこういう名前をつけます！」とラベリングし、暗黙知をエンジニア共通の知識に変えたことにある気がするので、デザインパターンの名前と内容が紐づいていない今の自分の状態は本末転倒な気もする。 これはデザインパターンのせいと言うより自分の怠惰さの問題なのだが、とはいえそもそもデザインパターン自体がMECEではない印象があり、自分以外にも違いが曖昧になっている人はかなり多い気がする。 違いが分からなくなったときに前のページに引き返せるかどうかが、私とあなたを差別化するポイントになるのではないかと思う。 まとめ かなり分かりやすく、演習も豊富で、デザインパターンの入門書としては非常に良い書籍だった。

概要 Hugoで作成したブログにGoogle Analyticsを導入する方法を解説する。 まずPaperModに導入する方法を紹介する。 その後にPaperModに導入した際の思考の過程を紹介することで、他のテーマにも応用できるようにする。 環境 Hugo 0.146.6 PaperMod (commit 7cf752f8644fea1fc3dc7299352718d492c55182) PaperModに導入する方法 1. Google Analyticsのスクリプトタグを取得 Google Analyticsの管理画面でスクリプトタグを取得する。 タグ発行の手順は色々な方が書いてくれていると思うので今回は省略。 2. /layouts/partials/google_analytics.htmlにスクリプトタグを追加 /layouts/partials/google_analytics.htmlに取得したスクリプトをコピペする。 /layouts/partials/google_analytics.html <!-- Google tag (gtag.js) --> <script async src="https://www.googletagmanager.com/gtag/js?id=G-HTNQ9KZXWH" ></script> <script> window.dataLayer = window.dataLayer || []; function gtag() { dataLayer.push(arguments); } gtag("js", new Date()); gtag("config", "G-HTNQ9KZXWH"); </script> <!-- End Google tag (gtag.js) --> 3. テスト 管理画面からテストボタンを実行してテストする。 緑のチェックマークが出れば成功。 以上。 思考過程 自分がどのようにして上記の手法にたどり着いたか、その思考過程を紹介する。 考え方はどのテーマでも共通していると思うので、他のテーマでGoogle Analyticsを導入する際のヒントになると思う。 1. ドキュメントを探す まず「PaperMod Google Analytics」のようなキーワードでGoogle検索をした。 PaperModの場合は適切なドキュメントを見つけることができなかったので、テンプレートをコードリーディングすることにした。 ...

概要 kago-utilsというPython製の麻雀OSSを作っている。 将来的にはこいつを拡張して強化学習を行うことが目標だ。 強化学習をするとなると速度は命だ。 そこでpytest-benchmarkを使って逐一ベンチマークを行い、その結果をGitHub Pagesにデプロイし、パフォーマンスを改悪するようなコミットをしてしまっていないかどうかを可視化することにした。 最終的には以下のようなGitHub Pagesができる。 Benchmarks 基本的にはgithub-action-benchmark(GitHub)に書いてある通りにやればよいのだが、意外と行間を補完する必要があって手間取ったので、この記事にまとめておく。 サンプルプロジェクト というわけで、kago-utilsにpytest-benchmarkを導入して上手くいったのだが、色々とコミットがごちゃごちゃしてしまった。 そこで今回は新しくこの記事用のリポジトリを作成したので、説明ではこちらを使う。 リポジトリは以下。 pytest-benchmark-with-github-actions-example GitHub Pages用のブランチを作成 とりあえずコードを書く前にGitHub Pages用のブランチを作成しておく。 今回はベンチマークの結果を保存するだけなので空のブランチを作成する。 空のブランチを作成する方法が以下。 git switch --orphan gh-pages git commit --allow-empty -m "Initial empty commit for gh-pages branch" git push origin gh-pages git switch main git switchやgit checkoutで新しいブランチを作成する際に--orphanオプションをつけることで空のブランチを作成できる。 通常のコミットは何らかの変更点が必要だが、--allow-emptyオプションをつけることで、変更点なしの空のコミットを作成できる。これは今回四苦八苦する中で初めて知った。 あとはプッシュして終了。 これ以降は手動でgh-pagesブランチに変更を加えることはないので、うっかりgh-pagesブランチで作業をしてしまわないようにgit switch mainでmainブランチに戻っておく。 GitHubの管理画面でGitHub Pages用の設定を行う Settings > PagesのBranchにgh-pagesを選択する。 自分の場合は自動でgh-pagesが選択されていたが念の為。 mainブランチでの作業 ディレクトリ構成 ├── Pipfile ├── Pipfile.lock ├── README.md ├── src │ ├── __init__.py │ └── prime.py └── tests ├── __init__.py └── test_prime.py Pipfileの作成 Pipfile [[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [packages] [dev-packages] pytest = "*" pytest-benchmark = "*" [requires] python_version = "3.12" [scripts] test = "python -m pytest --benchmark-skip" benchmark = "python -m pytest --benchmark-only --benchmark-json output.json" 自分はPipenvに慣れているのでPipenvを使っているが、pipやpoetryやuvなど各々の環境に併せて適宜読み替えてほしい。 ...

概要 いまさら『五等分の花嫁』を読んだ。 その感想を書いていく。 結論だけ先に言うと、途中まではめちゃくちゃ面白くて途中からは微妙だった。 盛大にネタバレも含むので注意。 #PR 五等分の花嫁 (1) 楽天 Amazon 1行で分かる五等分の花嫁 見た目がそっくりな五つ子のヒロイン達とその家庭教師である主人公の風太郎によるラブコメ。 途中までは面白い 途中まではかなり面白かった。具体的に言うと二乃の告白まで。 特に林間学校編と二乃の告白はすごく良かった。 林間学校編ではラブコメにミステリー要素を加えるという試みが行われていて斬新で面白いし、二乃の告白のシーンも今までのラブコメの常識をあえて破壊するものになっていて意表を突かれた。 調べてないけどこの2つは世間でも特に人気が高いエピソードなんじゃないだろうか？すごく面白かった。 後半は個人的には微妙 二乃の告白以降は無理にミステリー要素を入れようとして展開がちぐはぐになっているように感じた。 代表例としてスクランブルエッグ編がある。 スクランブルエッグ編では五つ子の誰かが五女の五月に変装して、主人公の風太郎に家庭教師をやめるように言い捨てる。 風太郎はなぜ家庭教師をやめてほしいのかその理由を問うために五月に変装していた犯人を突き止めようとする。 スクランブルエッグ編のミステリー要素は「誰が五月に変装していたのか」ということだ。 作中で読者に提示されたヒントは2つ。 偽物の五月の足にはあざがあった 長女の一花の足にもあざがあった 賢い皆さんならもう誰が偽物の五月なのかお分かりかと思う。 そう、偽物の五月の正体は〜〜〜〜？ … … … 三女の三玖でした。 いや、こんなん分かるか！！！ 一花が偽五月でない根拠 三玖が偽五月である根拠 この両方は特に描かれることなく、スクランブルエッグ編は終了してしまう。 百歩譲って三玖が偽五月である根拠は無くても良しとしよう。 一旦ミステリー要素を忘れてただのラブコメだと割り切れば、いちいち起こった出来事に対してその根拠など必要ないからだ。 ただ、ラブコメだと割り切ったとしても「一花が偽五月ではない根拠」は必要だろう。 これが無いと一花のあざの描写は何だったんだ？となってしまう。 批判ばかりしていても芸がないので、ここで創作の才能ゼロの自分が納得できるストーリーを提案してみよう。 風太郎が偽五月の右足にあざを発見する 風太郎が鏡越しに一花の右足にあざがあるのを発見する 風太郎が「偽五月は一花だ」と思い込む よく考えると鏡で反転してるから一花のあざは左足だと気づく どうだろうか？ めちゃくちゃベタだし改善の余地は大量にあると思うが、要するにこういう描写があれば一花のあざの描写もミスリードとして許容できるということを言いたいのだ。 「偽五月にはあざがあります」 「一花にもあざがあります」 「ただし、偽五月は三玖です」 これだけだとちょっと厳しいんじゃないかなあ…。 その後もチグハグな描写は続く… 一花のあざに代表される「一見するとミステリーを解くヒントになりそうで特に意味のない描写」はこれ以降も頻繁に現れる。 二乃の告白以降は終始ミステリー要素を無理に足そうとしてちぐはぐになっている印象だ。 作者はとっくにネタ切れしているのに読者が考察要素を要求し続けた結果、こういう感じになってしまったのではないかと推察する。 こういう意味のないミスリードを楽しめる人もいるんだろうが、個人的にはノイズに感じてしまった。 いっそミステリー要素を捨てて純粋なラブコメに振り切ってくれる方が楽しめた気がする。

概要 最近転職をした。 転職先ではJavaを使うのだが自分のJava経験は完全に0だ。 入社まで2ヶ月ほど期間があったので、せっかくだからJavaを使った個人開発でもしてJavaの勉強をしようと思った。 というわけで勉強時間を記録するWebアプリを作ることにした。 なぜ勉強時間を記録するWebアプリかと言うと、自分が欲しいからだ。 自分は怠惰な人間なので「〇〇時間勉強する」みたいな目標をビシッと決めないと勉強をするモチベーションの維持ができない。 社会人になってからは「毎四半期〇〇時間勉強をする」と目標を立てて、そこに向かって頑張るという作戦を取っている。 今のところは上手く機能している。 今までは勉強時間の管理にExcelを使っていて、正直Excelでも十分ではあったが、「Javaの勉強にもなるし、まあいっか」という感じでWebアプリを作ってみることにした。 アプリ名 アプリはその名も「Konbu」だ。 利用したい人がいるのかどうかは甚だ疑問だが、一応URLを載せておく。 https://konbu.zurukumo.dev なぜKonbuという名前なのかというと、大学の韓国語の授業で韓国語で「勉強」は「コンブ」と言うと習って、なんか可愛いなと思ったからだ。 どんな機能があるの？ 機能はめっちゃ少ない。 勉強時間を記録する 目標を立てる この2つだけ。 Excel時代も結局この2つで十分だったので、個人的にはこれでいいかなと。 レスポンシブ対応もしていない。なぜなら自分があまりスマホを使わないから。 いきなり機能を盛り沢山にしても開発のモチベーションが維持できないし、とりあえず最低限の機能だけ実装した。 万が一にもユーザー数が増えて新機能の要望が来るようなことがあればその時に機能を追加するかどうかは考えようかな。 使い方 勉強時間の記録 勉強記録のページでは画像のような感じで上部のフォームから勉強時間を記録できる。 フォームの下には記録した勉強時間の一覧が表示される。 最近はずっとKonbuを開発しているので個人開発ばっかりだ。 更新や削除もできる。 目標の設定 目標のページでは画像のような感じで上部のフォームから目標を作成できる。 目標の下には作成した目標の一覧が表示される。 更新や削除もできる。 目標の分析 目標一覧のページから個別の目標をクリックすると個別の目標分析ページに移動できる。 いろんな指標や集計されたデータを見ることができる。 コンブくん なんらかの操作をすると右下にいるコンブくんが反応してくれる。 ChatGPTに作ってもらった画像だけど、最近は普通に愛着が湧いてしまっている。 感想 機能は少ないけど逆にそこが分かりやすくて良いのかなと思っている。 プロトタイプが完成した時点でExcelからKonbuに移行したので、なんだかんだもう1ヶ月くらい使っている。 自分で言うのも何だけど、結構使いやすいんじゃないかな？ 個人開発は自分のためのツールを開発するのが一番楽しいですな。 JavaやSpringの勉強にもなったので良かった。

概要 IssoとDockerでHugoのコメント機能を実現するという記事でIssoを使ってコメント機能をHugoに導入する方法を紹介した。 今回はそのUIを日本語化する方法を紹介する。 方法 方法は簡単で、IssoとDockerでHugoのコメント機能を実現するで紹介したcomments.htmlのscriptタグにdata-isso-lang="ja"を追加するだけだ。 /layouts/partials/comments.html <script src="https://blog-api.zurukumo.dev/js/embed.min.js" data-isso="https://blog-api.zurukumo.dev/" data-isso-vote="false" data-isso-lang="ja" ></script> <section id="isso-thread" data-isso-id="{{ .Page.Path }}" data-title="{{ .Page.Title }}" > </section> 実は… 実はこの日本語化のPRを作成したのが自分だ。そのPRがこちら。 記事は日本語なのにコメント欄だけ英語で気持ち悪かったので、せっかくだからPRを出してみた。 はじめてのOSSコントリビュートに引き続き、2回目のOSSコントリビュートだ。 やはり自分が普段お世話になっているOSSにコントリビュートするのは気持ち良いですな。 翻訳系のPRは迷惑になる可能性が低いし簡単だしで敷居が低いので結構おすすめ。需要もそこそこある。 ちなみにコメント件数はいまだに0なので、PR出してまでコメント欄に凝る必要があるのかは謎である。 余談 ちなみに、最初はdata-isso-lang="ja"を追加しても日本語化されなくて15分ほど悩んだのだが、それはCloudflareが以前の翻訳データをキャッシュしていたのが原因だった。 お名前.comからCloudflareに切り替えてまだ1、2ヶ月くらいだったので、マジでこの原因は盲点だった。 Cloudflareの管理画面からキャッシュを手動で削除したらちゃんと日本語化された。 バグが起こると基本的にはコードに原因があると思ってしまいがちなので、早めに(当社比)外部要因に目を向けることができたのは偉かったかな。 正直ネットワークスペシャリストの勉強をしていなかったら、自分の出したPRに問題があるんじゃないかという観念に囚われてしまっていたと思う。 ネスペのお陰で新たな視点を得ることができた。 Viva ネスペ!

昨日、「ゆる哲学ラジオ」なるYouTubeの番組を見ていたのだが、そこででてきた「宇宙論的証明」という話を聞いて衝撃を受けた。 なぜ衝撃を受けたかと言うと、この「宇宙論的証明」という奴が自分が高校生のときに考えていたことと完全に同じだったからだ。 宇宙論的証明とは「何かが存在する以上それには原因があり、その原因をたどっていくと最終的に『最初の原因』に行き着く。それが神である」という考え方のことである。 自分は高校の物理の授業で「運動方程式 F = ma はデータを取ったらそうなるということが経験的に分かっただけで、数学的に証明されているわけではありません」という説明を教師から受けた。 物理エアプの自分は「それってありなの！？」と思ってしまった。 「なんでそうなるかは説明できないけど、とにかくそうなるんだから仕方がないよね」みたいなことがこの世にはたくさんあるんだと知った。 その後、「もし仮に運動方程式を説明できるようなAという法則が発見されたとしたらどうなるんだろうか」と高校生の自分は自問自答を開始した。 「運動方程式を説明するAという法則が見つかったとして、そしたらAという法則を説明するためのBという法則が必要だよな…。」 「そしたらBという法則を説明するためにCという法則が必要で…。」 「あれ？そしたらこれって無限に続いちゃうから、どこかで神のような超常的な存在が世界を規定したとしないと終わらないんじゃね？」 以上のような思考を経て、高校生の頃の自分は誰に教えられるでもなく自力で「宇宙論的証明」に辿り着いた。 正直に言うと「こんな斬新なことを思いついてしまう自分って天才なんじゃね？」とすら思っていた。 その幻想は昨日打ち砕かれた。 俺が思いつく程度のことはみんな思いついているのだ。 まあ、自分が天才ではないと自覚するのは辛いが、とはいえ良いこともあった。 ある意味自分がまともだと分かったからだ。 というのも、この「独自宇宙論的証明」について2回ほど人に話したことがあるのだが、2回とも「何言ってんだこいつ？」という感じでド滑りしたのである。 上司に話したときは「まあ、人間そういうのを信じたくなることもあるよね…」という返答をされた。 自分がここで言う「神」とは「この世界を矛盾なく説明するための超常的な存在」のことを指しているのであって、別にキリストとかムハンマドとか釈迦とか麻原彰晃とか大川隆法とかのことを言っている訳では無いのだが、上司には自分が宗教にハマっているやばいやつだと思われたらしい。 まあ、このエピソードに関しては上司の読解力の問題な気もするが、とはいえ2回もド滑りすると「もしかして俺ってやばいやつなのか？」みたいな気持ちは生まれてくる。 実際2回目のド滑り以降は人に話さなくなってしまった。 ただ、このYouTube番組を見て自分の発想が案外普遍的なものだったんだと自覚できたので、少しは自信が回復したな。

概要 HTMLのformタグは仕様上入れ子にできない。 例えば以下のようなHTMLを書いてみる。 form.html <form id="outer"> <form id="inner"></form> </form> これをChromeで開いてDevToolsを開くとこうなる。 内側のformタグが消えた。 HTMLの仕様なので仕方がないが、とはいえformタグを入れ子にしたい局面もある。 たとえば、今自分は以下のようなUIを個人開発で書いている。 日付や科目などを登録するための親フォームと、科目名の変更を行うための子フォームがある。 子フォームのフォーカス時にエンターキーを押したら科目名の変更を行いたいし、親フォームのフォーカス時にエンターキーを押したら日付や科目などの登録を行いたい。 Notionのセレクトとかもこんな感じのUIなので、そこまで特殊なシチュエーションではないかなと思う。 これをHTMLの仕様に怒られないように実装しようと思うと以下のような方法があるらしい。 フォームを親子関係ではなく並列の関係にして、位置調整はJSで頑張る submitボタンだけをformで囲み、その他の要素はform属性を使って属するフォームを指定する 方法1はイメージしやすいと思う。 例えばAフォームの下にBフォームを出したいなら、Aフォームの座標をDOMなどを利用して取得し、その値を利用してBフォームの表示場所を調節するのだ。 ただJSで位置計算のロジックを書くのは少し面倒だし、Reactなんかを使っていると並列になっているコンポーネント間でステートの共有をするのが少し面倒だ。 例えば並列関係にある2つのコンポーネントの両方で利用するステートがあるとしたら、2つのコンポーネントの共通の祖先のコンポーネントにステートを定義するかuseContextなどを使ってグローバルなステートを定義する必要がある。 親子のままならposition: relative;とposition: absolute;で簡単に位置調整ができるし、ステートの共有もpropsのバケツリレーをするだけで良いから簡単だ。 以上の理由から今回は方法1は見送り。 ちなみに、Notionはおそらく方法1を採用しているっぽいので、これも全然悪くはないと思う。単純に自分の好みではなかっただけ。 方法 というわけで今回採用した方法2の紹介。 以下のコードはformが入れ子になっているので現状はアウトだが、これをHTMLの仕様に反しないように成立させたい。 今からOuter Inputをフォーカス時にエンターキーを押したらOuter Submitが実行され、Inner Inputをフォーカス時にエンターキーを押したらInner Submitが実行されるようにしていく。 ng-form.html <form id="outer" onsubmit="alert('Outer Submit')"> <input type="text" value="Outer Input"/> <form id="inner" onsubmit="alert('Inner Submit')"> <input type="text" value="Inner Input"/> <button type="submit">Inner Submit</button> </form> <button type="submit">Outer Submit</button> </form> この方法で利用するのはHTML5で追加されたformという属性だ。 この属性をinputやselectに指定すると、それらの要素が属しているform要素を指定することができる。 つまり直接formタグで囲まれていないinputやselectを、さもformタグで囲まれているかのように振る舞わせることができる。 そこで外側のformタグの範囲をギューッと狭めて、Outer Submitボタンだけを囲むようにし、formの入れ子関係を解消する。 そして各inputやselectにform属性を指定して、属するformを指定する。 ok-form.html <input type="text" value="Outer Input" form="outer"/> <form id="inner" onsubmit="alert('Inner Submit')"> <input type="text" value="Inner Input" form="inner"/> <button type="submit">Inner Submit</button> </form> <form id="outer" onsubmit="alert('Outer Submit')"> <button type="submit">Outer Submit</button> </form> こうすることで、Outer Inputフォーカス時にエンターキーを押したらOuter Submitが実行され、Inner Inputフォーカス時にエンターキーを押したらInner Submitが実行されるようになる。 ...