作業ログ

タロットカード辞典を追加する 今日はタロットリーディングのアプリを手直し。 カードを選んで画像とキーワードを表示できる辞典機能をつけたい。 たとえばテーブルにカードタイトルを表示して、どれかの文字を押すと画像とキーワードがポップアップで出るとか。 Geminiに聞いてみるとスマートフォンで見やすいようにするならドロップダウンリストのほうがよさそう。 これもStreamlitに入っている道具「カード一覧から選ぶ」st.selectboxを使ってできるようだ。ちなみにポップアップもst.popoverまたはst.dialogでできるみたい。 すごいな。みんな思いつきそうなことは、だいたい誰かがつくってくれている、便利機能。その中身がちゃんとわかるようになりたいんだけど、先は長いなあ。 でもまずは、使いたいものをつくるということで、タイトル画面下に、ドロップダウンリストからカードタイトルを選んで画像とキーワードを表示するようなプログラムを追加した（書いたのはGeminiだ。何度も言うけど）。 ローカル環境で動きを確かめるためには、ターミナルでstreamlit run app.pyを実行。これで、リンク先のファイル名とかがまちがっていないかといったことを確かめられる。 ファイル構造の整理 先日、このHugoでつくったサイト自体のファイル構造も整理をしたけれど、タロットリーディングアプリのほうも整えることにした。 __pycashe__フォルダはPythonが自動で生成するキャッシュ（一時的なコンパイル結果）なので、削除してもよい（また勝手にできる）。 .devcontainerとdevcontainer.jsonは、VSCodeとかで「誰でも同じ開発環境（Dockerコンテナ）を再現するための設定ファイル」とのこと。触らないでよい（自分で書き換えたりはしないもの）。ただ、削除してもアプリは問題なく動く（自分でつくったアプリ本体のコードとは独立している）ので、消しちゃってもいい。 この2つは、自分でなんとかしなくてよいもの。 __pycashe__フォルダはGitHubにプッシュするときには含めないのが一般的とのこと。そこで、アプリのフォルダ内に.gitignoreファイルをつくって、次からこれを含めないでプッシュして！という指示を書き込んだ。 でも、GutHubにはすでに__pycashe__も含めてアップロードしてしまっている。 まずは、ターミナルでgit rm -r --cached __pycache__を実行してGitHubのリポジトリから__pycashe__を削除。--cachedをつけることで、手元のパソコンにある実際の__pycache__フォルダは削除されず、Gitの管理対象からだけ外れるのだとのこと。 これでプッシュしなおしたらきれいになった。 そして、大事なのは以下の3つ。 app.py メインとなる処理や画面デザインを書いた書類。画面にボタンを作ったり、ランダムにカードを引いたり、画面の遷移をコントロールするアプリのメインプログラム。 cards_data_py カードの順番・名称・キーワードなどをまとめた書類。カードの名前、番号、意味などのデータが整然と並んでいるデータ専門のファイルです。app.pyから呼び出して使う。 images タロットカードの画像が入ってるフォルダ。 だから、アプリの処理や画面デザインを変えたいときは、app.pyを修正すればいい。 Streamlitの画面表示などは（st.〜とかって、これはStreamlitの道具をつかうよ、ってこと）Markdown記法がつかえるので、Hugoでこのテキストサイトをつくったのとけっこう同じとこもある。キャプションとかを複数行にしたいときは"""（トリプルクォート）をつかうとか。 そしてStreamlitでは、特別なデザイン指定ファイル（CSSなど）をつくっていなければ、「文字の大きさやフォントはStreamlitの標準デザイン（デフォルト）が適用される」のだって。おお、これも、Streamlitの標準てのがあるのか。 st.title("...") 一番大きなタイトルサイズ st.header("...") 大見出しサイズ st.subheader("...") 中見出しサイズ st.write("...") / st.markdown("...") 通常の本文サイズ st.caption("...") 補足説明用の小さめのサイズ どこか一部を変えたいならapp.pyにst.markdownを書き込む。そういえば最初につくったときにその設定した気がする（してあった）。 もし全体を一括で変えるなら.streamlit/config.tomlファイルをつくって設定するとのこと。TOML形式もHugoでつかった。へえ。 ……ちょっと、あまりやってると頭が痛くなるのでこのあたりにしておこう。GitHubにプッシュして、Streamlit Cloudでリブートしたら完成。 今日はここまで。

記事を書くのには慣れてきたけれど、そうするとウェブサイトを構成するフォルダや書類の名前とかファイル構造とかが気になってくる（中身の外側、というか）。 そもそもVScode上でターミナルを起動できることにさっき気づいた……。 アンタ（VScode）ってただのエディタじゃなかったんだね。ポテンシャルを生かせてなかったよ。なんかごめん。 というわけでちょっとおさらい、そして気になっていたことを修正（例によっていちいちGeminiに質問しつつ）。 まず、Hugoサイトの構成について復習 layoutsというフォルダは「ウェブサイトの見た目を定義する」もので中身は.htmlファイル。 archetypesというフォルダは「新しく作る記事の初期設定を決める」もので中身は.mdファイル。 hugo.tomlは、サイト全体を規定する一番重要な書類で、サイト名、URL、使用テーマ、メニュー、言語設定などをここで設定する（トップページの表示内容を[params]などとして供給することもあるが、見た目そのものを整形するのはlayouts内のindex.html）。 content > postsフォルダ内のMarkdown書類や画像が、自分でつくるサイトの中身。ちなみに、この「content」だけは単数形！　Hugoの内部システムで厳密に定義されているため、スペル変更はできない仕様なんだって。「情報やコンテンツという抽象概念（不可算名詞）の集まり」という意味でこの単語が採用されたとのこと。 themesは主に外観のきせかえパーツ。いろんな人がつくってくれているのをさしかえできる。この中身は更新されることがあるので触らない！　どこかカスタマイズしたいときはlayoutsフォルダにここから必要なHTML書類をコピーしてそれを変更する。 publicはHugoを起動すると自動で生成されるから触っても意味なし。ごちゃついてきたら捨ててもよい（すぐに新しいのができる）。 Hugoには「特定のフォルダ名を見て、自動でその役割を判断するルール（ディレクトリ構造の約束事）」があるとのこと。だから、こういう決まった書き方があるのだね。自分で勝手に直したりつくったりしちゃいけないんだな。あたりまえか。 Hugoのファイル構造の整理とアーキタイプ設定 ファイル構造の整理。フォルダ名postをpostsに。hugo.tomlのナビゲーションメニューのリンク名を直しただけだと、エラーに。個別記事内に、別記事へのリンクがはってあってそこにフォルダ名の指定があったのを忘れていた。 個別記事ページで、タグが記事より下に表示されていたのを、タイトル、日付の下に入れたい。theme > layoutsからコピーしたsingle.html内でタグの位置を修正。どこまでタグの指示に関することなのかがわかりにくいので難しかった。 新規記事作成は手動でMarkdown書類を作成していたけど、テンプレートを整えておけばよいのだった。TOML形式（+++区切り、キーと値を=で結ぶ）だったのをちょっと書き慣れてきたYAML形式（−−−区切り、キーと値を:で結ぶ）にして、今使っているフォーマットになるように。Archives用に年月を設定するのだけわからなかった。これでhugo new posts/20XX-XX-XX.mdと入力すればpostフォルダ内に新規記事が作成されるみたい。 ちょっと、なるほどと思ったのは、「数字」の扱い方。単に文字列とみなすこともできるけれど、数字にはいろいろ機能がある。「数」「値段」「気温」「日付（年月日）」「時間」「角度」「緯度経度」などいろんなことを表せる（今、あたりまえのことを言っています）。 コンピュータに数字を与えるとき、何も指定しないとただの記号で、ほかの文字と同じ扱いになってしまう。だから「これはいずれかのデータ（型）、固定の文字列ではなく、決まった動き方（増え方減り方、上限下限などの決まりがある）をするものだよ！」と指示しないいけないということだ。 指定するとなにが変わるかというと、それに従った法則で動くようになる。日付だよと指定すれば、「2026/16/35」とかにはならず、日付専用の動きをする。 ……なんだか、なにもかもが、誰かが発明して、整理して運用して「普通のこと」にしてきたんだな。とても勉強になっている。 「今やった作業を他人に説明するときにはなんて言ったらいいのだろう」ということからして、疑問ばかりだ。言葉が合っているか、他人に伝わるか（相手のレベルにもよるし、自分がわかるかもあるし）、説明できるか。ひっかかりがちな性格のせいでなかなか進まないけど、おもしろくはある。 やったことをPushしようとしたらリポジトリにあるデータとちがうよ！とエラー。あれ……Pullしたはずなのになあ。 hint: Updates were rejected because the tip of your current branch is behind, hint: its remote counterpart. If you want to integrate the remote changes, hint: use ‘git pull’ before pushing again. hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details. ...

タロットカードのキーワード更新 GeminiとつくったタロットリーディングのPythonアプリ、カードのキーワードをChatGPTで更新した。Geminiが拾ってくれた一般的なキーワードを採用していたけれども、「重複がある気がするがどうか」「よい意味に振りすぎているのではないか」ということが気になっていたのだ。 そこで、Geminiによるキーワード一覧をChatGPTに提示し、修正提案を頼んだ。 ChatGPTはここのところ、私の考えてること、すきな本、仕事の仕方、言葉の遣い方とか言い回しとかに沿っただいぶ違和感ない返答をするようになったので、ちょっと他のLLMより一歩抜きん出た感じ。今回の提案も納得できるものだったのでそのままさしかえようかなと思ったら、「全体の抽象度やレベルをそろえたほうがよい」とのこと。確かにそれも整理したかったことだ。 それに、一部を修正をすると全体のバランスが壊れると。それもそのとおりだね。 ま、ほんとうは自分でやるべきなのだが、78枚もあるのでちょっと大変。あと、タロットカードの意味はいまさら私が考えてつくりだすでもないのでご勘弁いただきたい。 ということで、以下の方針でキーワードをそろえてくれ、と指示することに。 苦難や停滞、崩壊などの、厳しい意味も残す。 全体のバランスを再検討して整える。 言葉のレベルをそろえる。逸脱する場合はそれが効果的であるようにする。 原則として、別のカードにまったく同じキーワードを当てない。 とはいえ、一気に全部できるわけではないみたい。 文字数制限もあるので、3回に分けて全体をそろえてからさらに調整をするという。 大アルカナ 小アルカナ：ワンド、カップ 小アルカナ：ソード、ペンタクル 重複語の除去 派生語の整理 抽象度の統一 カード固有性の強化 AIが扱いやすい語彙への最終調整 ChatGPT1といえども、これを一度で処理するのは難しいんだって（課金してないからかもしれないけど）。まず全部をそろえてから、微調整するほうが確実だと。一覧する段階が必要みたいだ。ふーん。そこはなんか、人間と一緒のような。 結局、少し近接するキーワードも残ったけれど、カードには絵があるから、受ける印象はそこでも差別化できるだろう。 カードのキーワード一覧を更新して、プッシュし直したら完成だ。2 私のタロットリーディング 私のリーディングは、米光一成先生に倣って「具体的な占いの結果は、キーワードから当人が思い当たる」という方式を採用している。具体的な質問や状況や感情やなんやかんやは、結局、自分しか知らないし。 で、そのためにはこういう、「カード総体としてバランスがとれていること」は重要だと思う。 レベルの違うものが混じっているのは、私はあまりすきじゃない。見出しのレベルが合ってないと気持ち悪いのと同じだ。そのへんは、編集者っぽい癖だなと思ったりもする。 そもそも、私のタロットリーディングのアプリはとてもシンプルなものだ。 画面上で大アルカナのみかフルデッキ（大アルカナ＋小アルカナ）かを選ぶ。 シャッフルする（実際には、したつもりになる）。 一枚ずつ引く（正位置のみ採用／最後の1枚になるまで重複なし）。 ほんとうはスプレッドを再現できたらよかったけど、そこまでは難しいし、スマートフォンの画面じゃよく見えない。 だから開いたカードが何を示すかは、自分であらかじめ決めてから引く。 たとえば、「今の状況は？」「それに対する対処法は？」「対処するとどうなる？」「しないとどうなる？」と、いちいち自分で設問を立てる。 これで、わりとどんなQにも対応できると思う。 私はこう読んだけどあなたどう思う？ それで、AIだ。 LLMは、 相談者の文章 質問 カード名 キーワード カード画像 をまとめて読んで、その場で意味を組み立てるのが得意なのだ……と、ChatGPTが言っていた。 でも、私は勝手になにか言ってほしいわけじゃなくて、引いたカードから最初に「思いつく」のは私。 それについて示してから、＋αは聞いてみてもいい。 こういう問いでこういうカードが出て、私はこう読んだ。 「で、あなたどう思う？」と、“第ニの読み手”の役割を振る。 これをちょっとやってみた。 今日引いたカード、質問はこんな感じ（▼が私）。 ▼今のうちの会社の状態、どうなんだろう？ 🏷️ 1枚目のカード ワンドの9 (Nine of Wands) 【このカードが示すメッセージ】 警戒、備え、持久、防備 ▼「なんとか持ちこたえてる」って感じなのかな。 ▼これからどうしていったらいい？ 🏷️ 2枚目のカード ペンタクルの8 (Eight of Pentacles) 【このカードが示すメッセージ】 精進、熟練、鍛錬、継続 ...

最初は、Hugo Bear Blogというテーマ（外観）で、トップページから中に入ったところに、記事が並ぶだけのサイトにした。サイドバーとかがない、とにかくシンプルなタイプ。月ごとの記事数をまとめられるようアーカイブの設定はしてみたけれど、結局日付とタイトルだけがズラズラ並んでしまうのでちょっと目が疲れる。 10日くらい書いてみて、やっぱり、タイトル日付と冒頭数行が見えるようなテーマの方がよい気がした。そこで、Hugoのテーマを眺めてみて、PaperModというのに変更。これもシンプルなデザインで、記事の一覧とアーカイブだけじゃなくて、検索機能もついているみたい。 PaperModのテーマをダウンロードしてきて、hugo.tomlの中の設定を変更して……みたけれど、Hugo Bear Blogのときの設定のままじゃうまくいかない。Geminiは「そのまま使えますよ！」って言うけどそんなことない。これだけのことがなんて大変なんだ。いろんな人の解説を見て、あちこち直して、なんとか希望通りになった。 のだが！ そこから何回Git Pushしても、ブラウザ上では変わらない。なんで？ GitHubのリポジトリを見たら赤い×印がついている。Cloudflareでエラーが起きているみたい。なによもう。エラーログがきちんと出ていた。それによると、Cloudflare Pagesで設定しているHugoのバージョンが合っていない？　ということのようだ。そうなの。知らなかった、ごめん。ここは手動で指定するようだ。何でも勝手に整えて合わせてくれるわけじゃないのだね。 Cloudflare Pagesにあるサイトのデータを開き、settingの中のEnvironment variables（環境変数）にあるHUGO−Versionを変更。やっとデータをきちんと読んでくれた。 エンドユーザーというのは勝手なもので、いつも、誰かが整えて維持管理してくれている便利なものを、ただそういうものとして使うだけ。毎回感謝するわけでもなく、でもうまくいかないときにはすぐに他人のせいにする。いかんな。 おじいさんみたいなことを言ってしまったけど、他人のせいにする前に、ちょっと調べよう。大事なことだよ。 あと、山本貴光さんが「自分でプログラムを書いてみるとわかるけれど、『そのとおりにやってるのに動かない！』となった場合、結構な割合で人間の入力ミスだったりする」と言っていた。ほんとにそう。打ち間違い、入れてはいけない改行やスペース、記述する場所の間違い。……気をつけよう。

自分専用のタロットリーディングアプリがほしい 以前、ゲーム作家の米光一成氏の講座に参加したとき、タロットカードのウェブアプリケーションをつくってくれたエンジニアの人がいた。そのときの講座内容は、米光先生作のカード（大アルカナのみ22枚）を手本に、受講生それぞれが自分なりのテーマでタロットカードをつくるというもの。そこで各自が作成したカードも、画像つきでひけるようにしてくれたのだ。講座が終わってからもけっこう使っていたのだが、リンク切れになってしまった。 自分用に、シンプルなタロットリーディングのウェブアプリケーションがほしい。ただカードを1枚開いて、キーワードを表示してくれるだけでいい。すきな枚数、重複なしでカードが尽きるまで並べたい。 こういう動きのあるウェブアプリケーションもGeminiに聞きながらつくれるかもしれない。尋ねてみると「ボタンを押したらなにか動作が起こるしくみ」を構築するには、このサイトをつくるために使ったHugoとは違い、動的なものをつくるためのプログラミング言語を選ばなくてはいけないようだ。方法はいくつもあるみたいだけど、動的なしくみを動かせて、つくった後でファイルの中身を見て勉強するのもしやすそうなPythonでつくることにした。 動きの設計 つくりかたはよくわからないが、手順や動きを言葉で説明するのは得意だ。というわけで、動作の要件を伝えた。 準備 大アルカナ小アルカナあわせて78枚のタロットカードの画像（裏は柄、表がそれぞれの絵のカード／重複なし／カードそれぞれに意味のテキストデータが付随している）を用意する。 実際の動き 画面上に「大アルカナ小アルカナあわせて78枚」もしくは「大アルカナのみ22枚」のカードの山（デッキという）が現れる。いずれかを画面上でクリックして選ぶ。次の画面へ。 画面上に「シャッフル」ボタンが現れる。ボタンをクリックすると、画面上で象徴的な画面（動かなくてよい。心理的にシャッフルしたと納得できるような画像）が表示される。その画像をクリックして次に進む。 画面上に「カードを引く」ボタンが現れる。ボタンをクリックすると、選んだデッキからカードが1枚表示され（ランダム）、カードの下に、カードに紐づいた意味が表示される。そのさらに下に「もう一枚カードを引く」ボタンと「終わる」ボタンが表示される。 同じ画面上で「もう一枚カードを引く」ボタンをクリックすると、1枚目に出たカードの下にもう1枚カードが表示され（ランダム／重複なし）、カードの下に、カードに紐づいた意味が表示される。そのさらに下に「もう一枚カードを引く」ボタンと「終わる」ボタンが表示される。 「終わる」を押すまで、選んだデッキ内のカードの枚数（78枚、もしくは22枚）が尽きるまで、カードがランダム／重複なしで表示される。 追加の条件 正位置のみ採用、逆位置はなし。 代表的な意味（キーワード）のみ記載する（Geminiが拾ってくれた）。 カードの画像はウィキメディア・コモンズから、すでにパブリックドメインになっているパメラ・コールマン・スミスのライダー＝ウェイト版を使用する（これは結局、手動でDL）。 複数のPC、iPhoneから使えるようにしたい。 ダークモードでもライトモードでも見えるようにしたい。 「実際の動き」のうち「開いたカードはそのままに、残りのデッキから別のカードを開く」という部分はGeminiによると「履歴管理」という操作になるようだ。カード全体からどれを抜いたかを記憶して、残りから選ぶ、ということだね。そういう言い方をするのか。 どうやって、なにでつくる？ Geminiによると、ウェブアプリケーションをつくるとき、通常は「裏側の処理（Pythonなど）」と「画面の見た目（HTML/CSS/JavaScriptなど）」を別々につくる必要があるとのこと（なるほど、動かすためのルールの部分をPythonでつくるのかな？）。 切り分けると、次のようになるらしい。 Pythonがやること＝裏側の処理：「78枚のカードからランダムに1枚選ぶ」「過去に引いたカードを記憶しておく」といった、頭脳にあたる計算やルールの処理。 HTML/CSSがやること＝画面の見た目：「選ばれたカードの文字を画面の真ん中に、白い四角の枠線をつけて表示する」といった、目に見えるデザインの処理。 でもこれを一からつくるのは初心者にはハードルが高い。それはそうだね。そこで、「Streamlit」という「Pythonライブラリ」を採用した（のだってさ、Geminiがね）。 ……なるほ、ど？ あれ？　Streamlitは「Pythonでウェブアプリケーションを構築できるフレームワーク」という説明をどこかで見たのだけど、ライブラリとフレームワークってどう違うんだろう。 ライブラリ：特定の便利な機能が詰まった、使い回せる部品の詰め合わせ（道具箱）。ゼロからプログラムを書くと大変な処理（「ランダムにカードを選ぶ」「画面にボタンを表示する」など）を、ほかのプログラマがすでに作成してパッケージ化してくれている。 フレームワーク：アプリケーションの土台や骨組み、開発全体のルール（テンプレート、設計図）。 Streamlitは「ライブラリ」に分類されてはいるが、画面全体の動きを制御してくれるので、「フレームワークに近い性質を持ったライブラリ」といえるらしい。 Streamlitを使うことで「画面の見た目」から「裏側の判定処理」まで、すべてPythonだけで一括で記述できる。Pythonのコードを上から下へ実行するだけで裏側で勝手にウェブ画面を構築する「レール」を用意してくれているので、作成者がウェブのしくみ（HTMLやサーバーの通信など）を意識せずにアプリケーションを完成させることができる。 うん。なんとなくわかった（としよう）。 PythonとStreamlitをインストール Mac miniにPythonは入っていたから、Streamlitをインストールした。途中で「メールアドレスいれてよ」っていってくるけど無視していい（ターミナルで勧誘するのやめてよ）。 Geminiの作業は早い。ためしに3枚くらいのカードでささっと動作を確認し、おかしな挙動を修正して（するのはGemini）、「大アルカナだけ」「小アルカナも追加」と段階的にカードを増やしてテスト。うーん、すごい。なんて簡単にできるんだ。部品をつくってくれた人ありがとう。 最後にカード裏面画像と全カード表面の画像を用意して、番号をつけ直してimagesフォルダにまとめる。ダークモード・ライトモードをきりかえると文字が消えてしまうところがあったり、表示された画像が枠とずれていたりセンタリングにならなかったり、小さな問題を修正してもらい、完成！ どこからでも使えるよう、サーバーにデータを置く 自分のMac miniというローカル環境で動きは確認できたけれど、まだほかのPCやiPhoneでは動かない。どこからでも動かせるようにしたいなら、動的なしくみを動かせるサーバーにデータを置かないといけないようだ。ふむ。「サーバーにデータを置く（公開する）」ことをデプロイ（Deploy：展開する）というのだな。 サイトを公開するときに使った「Cloudflare Pages」は基本的には静的なデータしか扱えないみたいなので、今回は「Streamlit Community Cloud」にアカウントをつくった。 そして、GitHub（このサイトを公開するためにも使っている）のリポジトリに、タロットリーディングアプリケーションのデータをプッシュ。これをStreamlit Community Cloudと連携し、アプリをデプロイした。 サーバーに公開したとはいえ、リポジトリ自体は非公開だからアプリ自体も非公開。サインインした自分だけが使えるものになった。 ほしいものはつくることができた、けれど おお！ 恐るべきはやさでできあがった。動きも軽くていい感じだ。「カードを1枚ひきたい」「余計な解釈はなしで、絵とキーワードだけほしい」「追加ですきなだけカードをひきたい（この次どうなる？とかこれに対処するには？とか自分で決める）」という、要望に応えてくれる。 正直に言えば「自分でつくった」という感じはあんまりない。Pythonライブラリは便利だが、これに頼っているだけでは、自分ではよくわかっていないままかもしれない。動くことはわかったから、書類の中身を見て勉強することにしたい。 ただ、そもそも「どういう動きをさせるか」、その条件なんかもあらかじめきちんと意図して組み立てができていないと、こんなにスムーズには完成しないみたい。 そもそも、普通はこういったアプリケーションの開発は、しくみを考える人と、製品として動くものをつくる人と、外観をきれいにする人は別なのかもしれない（よく知らないのだが）。零細企業のかなしさで、なんでも自分でやろうとしてしまうけれど。 とりあえず、次は自分のオリジナルタロットのアプリケーションをつくってみようと思う。

iPhoneじゃなくて普通にブラウザ上でもGitHubの中で更新できるんだな。それはそうか。iPhoneアプリだけってことはないか。うーん。 基本は「履歴保持済みの倉庫」だけど、ここで作業もしたいだろ、てそりゃ思うよね。 この記事はChromeのGitHubで書いた。便利だ。 便利はいいけれど、常に「便利なんだから黙ってそれを使っておけばいい」とは思わない。なぜだろう？ そんなこと考えない人もいるんだろうけど、なんだか少し引っかかってしまう。ちょっとバックヤードをのぞいただけで、自分になにかすごいことができるわけではないことは知っている。でも、「この後ろってどうなってんのかな？」と思うし、その作業を知らないところで誰かあるいは何かがかわりにやってくれているならそれを知りたい。 勉強だって、思っているけど、……いや、単なる趣味かな。

ローカルで確認しながらつくったウェブサイトを、GitHubのリポジトリとCloudflare Pagesを接続して公開までできた。 途中でGeminiが言ってる画面にならなくて接続先をまちがってたりしたけども、なんとかできたー！ 最後に、hugo.tomlの中のURLを修正したら、個別のページもちゃんと開けるように。 おお、達成感。 今はウェブ上にいろいろプラットホームが整えられて、アカウントをつくれば簡単に写真も文章も載せられる。でも、いちいち「トップページに画像をつけると見られやすいですよ！」「人気のタグをつけると検索で見つけられやすいですよ！」とか言ってきて、もういいのやめてよ、ってなってしまう。うんざり。 それに、誰かがゼロからつくったものに乗っかるだけなのも、なんだか嫌だなと思うようになっていた。 ……まあ、とはいえGeminiに聞きながらだし、静的サイトジェネレーターとかGitHubとかをつかっているのでまったくゼロからではないが。 こんなシステムをつくった人たちはすごいよね。アイデアもすごいし、実現したのもすごい。だからせめて、わたしも手を動かして、「どこが合ってる／間違ってる」「簡単そうに見えてそんなことない」といったことを体感したいと思ったのだ。 体感て大事だよね。体感するからこその達成感。 それから、Gemini（生成AI）の出力した内容をを「いちいちチェックする」ということもちゃんとやろうと思った。 おしゃべりの文字面だけだとそれらしい感じで納得させられてしまうけれど、実作業がともなうと、途端に「あなたの言ったとおりにならないよ？」ってことがいっぱいあると気がつく。もちろん自分が入力間違えたり違うファイルに書きこんでたりする場合もあるが、AIが間違っていることもけっこうある。スクリーンショットを見せたりエラーメッセージを示したりして「あなたが想定したようになってない。実際はこうなってるよ？」とつっこんだら、Geminiが「ああ、わたしの勘違いでした！」とか言ってくる。相談しながら進めていく感じ。 「AIにやらせておけばいい」「人間より間違いが少ない」なんてことは言えないんだな、と“わかる”。 どうしても書きたいことがあるわけではないが、誰にも邪魔されずに書ける場所をつくることができたかな。 っていうのを真夜中に書いて更新したつもりだけど、反映されない！　なんでだ。と思ったらもしかして、日付か？　えっ、真夜中はまだ前日のカウントなの？ 明日に続く。 時間の設定ってどうなってるんだっけ？ トップページが寂しいからなにか増やしたい。 iPhoneから更新するの、どうやる？ 一日に2つ以上の記事はつくれないの？ 個別記事の中に別の記事のリンクを貼るにはどうする？

なんと、GitHubは作業場じゃないのに、iPhoneのGitHubアプリでは記事の作成ができるのだってさ。便利だねえ。 ⁠hugo.tomlにtimeZone = "Asia/Tokyo"を入れて日本時間の設定をした（日本の時間で、日付が変わったら次の日！）。 GitHubのiPhoneアプリから投稿するために、iPhoneのショートカットアプリで投稿のためのテンプレートの設定をした。 個別の記事の中に自分のサイトの別記事へのリンクを貼るときはrelrefというショートコードを使うとのこと。過去記事はこちらみたいな感じ。 ■ 大事なことがひとつ！ iPhoneで更新した内容はMac miniもMacBook Airも知らないから、帰ったときに必ずプルすること！

昨日、思い立ってテキストだけの、すごくシンプルなウェブサイトをつくってみた。 VScodeを使いこなせるようになりたいから、Markdownでテキストを書いて、それをアップロードするシンプルなものにしたい。 GitHubとかターミナルとかコマンドプロンプトとか勉強したいから、適宜、使ってみたい。 最初は、読んだ人の反応とかコメントとかもらうのはつけなくていい。 それでGeminiに聞いたら、HugoとAstroという静的サイトジェネレーター（SSG）を勧められた。 どっちも高速でさくさく動くけど（Hugoは作業速度が早い、Astroは端末での表示速度が早い）、Hugoは最初からブログむきの機能がいろいろはいってるのが特徴みたい。 なるほど、じゃあそれでやってみよ。 というわけで、紆余曲折ありながらもいちおう完成！　Hugoはすでにいろいろなテーマ（画面構成・デザインのパッケージ）がつくられているから、最初はそれを使ってセッティングすればよいとのこと。 とはいえ、選んだテーマが古かったりして（リンク先がないとか）うまく反映されなかったけど、【hugo-bearblog】というテーマでなんとか作成。それから順次整理していった。 サイトのタイトルを変更するにはどうしたら？ 新しい記事を作るのはどうする？ 各記事にタイトルを表示したいけど、どこに何を書けば？ 最初に作成したMac miniだけじゃなく、MacBook Airでも作業するためにGitHubに保存したい。どうやる？ MacBook Airにはどうやってデータを持ってくる？ 記事にタグをつけたい、各記事にもタグを表示したい。どうするの？ Hugoの基本は、 記事作成はcontent > postフォルダ内にmd書類を置くことでできる。 publicフォルダは、Hugoを起動したときに自動的にできるもの。中身を触っても意味はない（失敗タグとかが残るから気になったら削除しちゃってOK）。 themesフォルダの中身は触らない！　ページの見た目を変更したいときはlayoutフォルダの中で行う。 予期せぬエラーが多々あったけれども、ひととおり完成。 ■ フォルダ一式をgitに保存したりgitから持ってきたりする 以下の手順（で、ターミナルで作業）。 ターミナルで使う場所を確定　cd 使う場所（フォルダ名） add　git add . commit　git commit -m "保存段階に名前つける" push　git push origin main pull　git pull origin main clone　git clone https://github.com/ユーザー名/サイト名.git クローンは、サイトのフォルダ一式を丸ごと新規にDLすること。まだPC上にフォルダ一式がないときだけじゃなく、なんか作業がうまくいかなくなったときとか問題を切り分けたいときには有効。作業中の書類は残しておいて、うまくいったところまで戻して試してみるとかできる。 この `git push origin main`とかのインラインコードの表現を変えたいんだけど（文字を小さくしたくない、背景色をつけたい）、何をやってもうまくいかず。なかなか全部思い通りにならないな……。 カスタムはここまでにして、プッシュして終わりにする。 そして次はCloudflare Pagesを設定しようかな。 MacBook Airにプルしてみたら、やっぱりmd書類の中を更新しても反映されない問題が。で、昨夜クローンしたフォルダの中を見てみたら、themes > hugo-bearblogの中がからっぽだった。 ……これ、昼に同じことやったよ？　Geminiよ、たぶん、昨夜うまくいかなかったのもここだよきっと。 ...

このブログの最初から、さかのぼった日付で作業中（だから実際にはこれも6/21に作成したもの）。 ふむふむ。ターミナルから新規記事作成の指示をしなくても、content > post の内に直接mdファイルを作ったっていいんだよね？ そしたらターミナルでデスクトップ上のquickstartフォルダ（ウェブサイトデータ一式があるところ）に移動してhugo server -DでHugoを起動する、と。 そしたらローカルで表示するためのURLが出るから、それをChromeに貼って表示する。 うむ。とりあえず、そういうことで合ってるみたい。