いまさら五等分の花嫁の感想

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

2025-05-17

勉強時間を記録するWebアプリを開発した

概要 最近転職をした。 転職先では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の勉強にもなったので良かった。

2025-05-15

Isso製のコメント欄を日本語化する

概要 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 ネスペ!

2025-05-11

俺が思いつく程度のことはみんな思いついているんだな - 神の存在について

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

2025-05-11

formタグは入れ子にできない

概要 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が実行されるようになる。 ...

2025-05-08

Reactのコンポーネントを使い回すのってムズい

Reactを使い始めて5年くらい経つ。 最近「上手くコンポーネントを使い回すのって人類にはムズいんじゃね?」って思ってきた。 一番ベーシックなコンポーネントといえばボタンが思いつくけど、経験上見た目が同じでも内部での処理が異なるボタンってかなり多い。 AボタンとBボタンを頑張って抽象化したとしても、後からCボタンがやってきて抽象化をやり直したことが何度もある。 めちゃくちゃ簡単に使い回せそうなボタンですら使い回すのがムズいって絶望するわ!! で、最近は個人開発のときにコンポーネント化するのをやめて愚直にソースコードをコピペしているけど、今のところ別に問題が起きてないんだよなあ…。 むしろどうやって抽象化しようか悩む工程がなくなっている分だけサクサク書けるようになっている気がする。 まあ超小規模な個人開発だから問題が起きていないだけの可能性もあるけどね。 というわけで最近は 長いソースコードを切り分けて読みやすくしたいとき 同じ画面内にデータ部分が違うだけの部品を複数表示したいとき だけコンポーネント化している。 前者はコードが長くなりそうなときに使っていて、これは別に使い回すためにコンポーネント化しているわけではない。 Reactはコード量が増えがちだし、「どのHTMLがどのuseStateと関係あるんだっけ?」みたいなレイアウト部分とデータ部分の結びつきで混乱しがちなので、こういうときはコンポーネント化して、いい感じにソースコードを切り分けて読みやすいコードになるように工夫している。 後者の代表的な例はmapとかで配列を回して複数の要素を表示するようなときだ。例えばテーブルとかリストとか。 テーブルの行が1行目と2行目で仕様が変わることってほぼ無いから抽象化は雑で良いし、将来的に抽象化をやり直す可能性も低い。 こういうときは躊躇なくコンポーネント化している。 個人的に違うページに現れるパッと見似ている要素をコンポーネント化するのは罠だと思っている。高確率でその後に後悔している気がするんだよな。 ただ、ヘッダーとかフッターみたいに全ページで全く同じものを使うことが多い要素についてはコンポーネント化してもあんまり問題が起きないことが多い気がする。 これは例外かなー。 10年後の自分はこの記事を読んでどういう感想を抱くのかね?

2025-05-06

VSCodeでJavaのコードを保存したときに自動でビルドする(Gradle)

やりたいこと VSCodeの『Language Support for Java(TM) by Red Hat』という拡張にはjava.autobuild.enabledというオプションがあり、これはデフォルトでtrueになっている。 つまりVSCodeではjava.project.sourcePathsやjava.project.outputPathやjava.project.referencedLibrariesなどの設定を適切に行っていれば、Javaのコードの保存時に自動でビルドが走る。 ところがGradleを使っているプロジェクトでは自動ビルドが走らなくなる。 試してはいないが恐らくMavenを使っている場合も同様だと思われる。 要するにjavacには対応してくれているが、./gradlew buildには対応してくれていないということなんだろうと思う。 Gradleを使っているプロジェクトでも素のJavaプロジェクト同様に自動ビルドが走るように設定をしていく。 方法 1. Run on Save拡張をインストール Run on Saveという、保存時に指定したコマンドを実行してくれるVSCode拡張があるのでインストールする。 2. settings.jsonを編集 VSCodeの設定ファイルであるsettings.jsonを編集して、コードの保存時に./gradlew buildを実行するように設定する。 .vscode/settings.json { "java.home": "/Users/zurukumo/.jenv/versions/21", "java.import.gradle.java.home": "/Users/zurukumo/.jenv/versions/21", "java.import.gradle.enabled": true, "java.project.sourcePaths": ["src/main/java"], "emeraldwalk.runonsave": { "commands": [ { "match": "\\.java$", "cmd": "JAVA_HOME=/Users/zurukumo/.jenv/versions/21 ./gradlew build" } ] } } "match": "\\.java$"と書くことで、ファイル名が.javaで終わっているファイルの保存時にのみコマンドが実行されるようになる。 ちなみにjava.homeを指定していてもRun on Saveからは読み込まれていないっぽく、仕方がないのでコマンドの前にJAVA_HOME=/Users/zurukumo/.jenv/versions/21と環境変数を記述した。 二重に書いている感じが気持ち悪いが、今の自分の実力ではこれが限界…。 まとめ 絶対にもっと良い方法がある気がする。 もっと良い方法を知っている方はコメントで教えて欲しい。 EclipseとかIntelliJ IDEAとかだったらこんなに面倒なことをしなくても自動でビルドしてくれるんだろうか?

2025-04-24

lycheeでHugoのデッドリンクを検出する

やりたいこと lycheeというRust製のリンク検査ツールがある。 今回はHugoで作成したブログのデッドリンクをlycheeで検出するためのシェルスクリプトを作る。 環境 Hugo 0.146.6 PaperMod (commit 7cf752f8644fea1fc3dc7299352718d492c55182) lychee 0.18.1 lycheeのインストール 詳細は公式のGitHubを参照。 自分はbrewでインストールした。 brew install lychee シェルスクリプト まずは実際に作成したシェルスクリプトを見てみる。 lychee/check.sh #!/bin/bash rm -rf public/ hugo server -p 13131 & HUGO_PID=$! while ! nc -z localhost 13131; do sleep 0.5 done lychee public/ --base="http://localhost:13131" --exclude="amzn.to" --exclude="a.r10.to" kill $HUGO_PID 一行ずつ見ていこう。 1. rm -rf public/ public/ディレクトリを削除する。 Hugoはビルドした結果をpublic/に格納する。 もし記事を削除しても、public/にビルドファイルが残っている可能性がある。 そのような記事はリンク検査の対象にしたくないので、一旦public/を削除してから次のステップ2でもう一度ビルドする。 2. hugo server -p 13131 & ポート13131でHugoのサーバを起動する。このとき同時に再ビルドも行われる。 &をつけることで処理をバックグラウンドで実行することができる。 ...

2025-04-21

はじめてのOSSコントリビュート

初めてOSSにコントリビュートした!うれしい!! 概要 tcardgenというHugo用のOGP画像を生成するツールがある。 tcardgenを使ってHugoでOGPを設定するでもこのツールについては紹介した。 実際にこのブログのOGP画像もtcardgenを使って生成している。 tcardgenはデフォルトでタグをタイトルケースに変換する。 Hugo自体もデフォルトでタグをタイトルケースに変換するので、tcardgenはHugoの仕様に合わせたのだと思う。 ただHugoでtagの先頭文字が大文字になるのを回避するでも紹介したように、Hugoにはタグのタイトルケースへの変換を無効化するオプションがある。 Hugoに無効化するオプションがあるのだから、tcardgenに同様のオプションを追加してもさして問題はあるまいと思い、タイトルケースへの変換を無効化するオプションを追加した。 そのPRがこちら。 そしてこのPRが昨日無事にマージされた。 感想 OSSにコントリビュートするのは初めてだったので、結構ドキドキした。 フォークしてPRのベースブランチを指定したりするときに、ミスったらやばいことになるんじゃないかとヒヤヒヤしたが、特に問題なくPR作成までできたので良かった。 GitHub自体は業務でも個人開発でも利用しているが、意外とフォークとかしたこと無かったなと気付かされた。 今回で大体の流れは掴めたので、次回からはもう少しスムーズにコントリビュートできると思う。 あと、自分的には必要な機能だと思って実装したが、他の人からすると無駄な機能だと思われているんじゃないかと不安だった(別に今もこの不安が解消されたわけではない)。 今回はIssueを立ててから一息でPRまで作成したが、とりあえずIssueを作成して作者や他人の反応を見るのもありなのかもしれない。 とにもかくにも無事にマージされてよかった。 自分がよく使うツールにコントリビュートできるってのは気持ちが良いもんですな。

2025-04-19

IssoとDockerでHugoのコメント機能を実現する

Hugoはデフォルトでコメント機能を持っていない。 公式ドキュメントにはDisqusを使ってコメント機能を実装する方法などが紹介されているが、有料だったり広告が出たりであまり評判は良くないようだ。 色々調べたところIssoというPython製のコメント用サーバを使うことで、無料かつ広告なしでコメント機能を実現できると分かった。 今回はその方法をご紹介。 Issoとは IssoとはPython製のコメントサーバである。 SaaS系のコメントツールと違って自前でサーバを動かす環境を用意するという手間はかかるが、その反面Hugoに限らずあらゆるwebコンテンツにコメント機能を実装することができる。 機能に関してもメールでのコメント通知、連投防止、管理画面など一通りのものは揃っている。 環境 Hugo 0.145.0 PaperMod (commit e2e1011bdecaf84d59c70fa42ff3d2c29c537b65) IssoのDockerイメージ latest(2025-04-16時点) 方法 0. 前提 今回はHugoで作成したブログをhttps://blog.zurukumo.devに、Issoのコメントサーバをhttps://blog-api.zurukumo.devにデプロイすることを想定している。 ブログはVercel上にデプロイし、コメントサーバはさくらのVPSにコンテナデプロイした。 1. Issoでコメントサーバを作成する コメントサーバの構成は以下の通り。 . ├── config │ └── isso.cfg ├── db │ └── comments.db └── docker-compose.yml └── .env config/isso.cfgにIssoの設定を書き、docker-compose.ymlにコンテナの構成を書く。 db/comments.dbはコンテナを立ち上げると自動で作成されるので、用意するのはdbディレクトリだけでOK。 docker-compose.ymlは以下のように書いた。 docker-compose.yml services: isso: image: ghcr.io/isso-comments/isso:latest env_file: .env ports: - "8080:8080" volumes: - ./config:/config - ./db:/db Issoは公式がDockerイメージを配布してくれているので、それを使えば上記のような簡素な設定で問題なく動く。 次にconfig/isso.cfgにIssoの設定を書く。 config/isso.cfg [general] dbpath = /db/comments.db host = https://blog.zurukumo.dev notify = smtp [server] listen = http://localhost:8080/ [moderation] enabled=false [smtp] username = (自分のメールアドレス) password = ${SMTP_PASSWORD} host = smtp.gmail.com port = 587 security = starttls to = (自分のメールアドレス) from = "isso comments" <(自分のメールアドレス)> timeout = 10 [guard] enabled = true ratelimit = 2 direct-reply = 3 reply-to-self = false require-author = false require-email = false [hash] salt = ${HASH_SALT} algorithm = pbkdf2 [admin] enabled = true password = ${ADMIN_PASSWORD} Server Configulationを参考にしながら書いた。 ...

2025-04-16