Gemini

記事を書くのには慣れてきたけれど、そうするとウェブサイトを構成するフォルダや書類の名前とかファイル構造とかが気になってくる（中身の外側、というか）。 そもそも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. ...

最初は、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ライブラリは便利だが、これに頼っているだけでは、自分ではよくわかっていないままかもしれない。動くことはわかったから、書類の中身を見て勉強することにしたい。 ただ、そもそも「どういう動きをさせるか」、その条件なんかもあらかじめきちんと意図して組み立てができていないと、こんなにスムーズには完成しないみたい。 そもそも、普通はこういったアプリケーションの開発は、しくみを考える人と、製品として動くものをつくる人と、外観をきれいにする人は別なのかもしれない（よく知らないのだが）。零細企業のかなしさで、なんでも自分でやろうとしてしまうけれど。 とりあえず、次は自分のオリジナルタロットのアプリケーションをつくってみようと思う。

ローカルで確認しながらつくったウェブサイトを、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よ、たぶん、昨夜うまくいかなかったのもここだよきっと。 ...

なるほど。手を動かしてみないとわからないんだな。 ここまでGeminiに相談しながらやってみた。 言うとおりにやるだけじゃなくて、うまくいかないときの「とりあえず」の対処を考えたり、こう言ってるってことはこうかな、とか考えたりしながら作業。Geminiよ、あんたはこう言ってるけど、「ホントはこうじゃないの？」とか。 何でも、自分の手元で試してみるしかないね。 ただのテキストサイトといっても、紙に書いて壁に貼るのとはわけが違う。たのしいな。