アルバムサイトを更新する技術

うちのサイトの中で1番更新を楽にするための色々が施されてるのが写真サイトである。ということで何をしてるのかをご紹介～～。

構成など

フレームワークはastro。単純に『いつもの』でもあるが、『静的サイトを作るならこれが最適解』だと思っているのもある。他のフレームワークでも静的サイトは作れるが、やや多機能すぎるという印象。

写真は全部Githubに直置き。いつか容量足りなくなりそうだが、足りなくなるほど更新を続けられたらその頃にはまた違う策がとれるようになってると思う。

デプロイ先はCloudflare Pages。これは単純にドメインがCloudflareにあるので。ドメイン更新の時期が近いが値段はあまり変わってなかった。ありがたや。

ページ内容

下記のようになっている。

photo/src/pages/photo/2024/10/22/index.astro at main · thetalemon/photo · GitHub

ぱっと見でわかる通り丁寧にひとつひとつやったらめっちゃめんどいやつである。

もちろん丁寧に1行1行書いてはいない。AIに生成させてもいない。ある程度自動化しているだけである。写真のピックアップと実際に記事レイアウトは人がやっているが、importや写真をhtmlにベタベタするのはScriptを書いている。

自動化していること

実は同じリポジトリに自動化スクリプトが置いてある。これでだいぶ楽している。

photo/script at main · thetalemon/photo · GitHub

rename.py - 名前変更

これはiCloudが謎なのだが、iCloudからダウンロードすると『JPG』というファイル名で吐き出してくることがある。XXX.jpgではなく『JPG』である。まあiCloudが微妙に不親切なのはいつものことなので良い。

なのでexif情報を見て撮影日順に並べてから採番している。採番する理由は大抵時系列で公開したいことが多いので、後の工程で写真が時系列に並ぶようにするため。

output.py - importとかHTMLタグとかを吐き出す

ここでimportやhtmlをファイル数分吐き出すようにしている。これをコピペするだけで、ページに写真が並ぶ！ってことである。

なので写真の大きさの調整とか、コメントとか、そういうのが要らなければこれだけでページが完成する。絶望的にやる気が出ないけど写真を公開したい日がきたらそうする日もあるかもしれない。ないと思うが。

resize.py - 画像をリサイズする

これは後で追加したのだが、そのままの画像サイズだとGithubにあげる時にめっちゃ重い。というか普通にそんなデカいサイズ要らないので、両方の辺が1200px以上の画像は半分以下に縮小している。写真も全画面表示してないからね。

自動化していないこと

写真を選ぶのと、自動化の後に写真の順番を並べたりコメントをいれたりとかは人間がやっている。そこは自動化できないのもあるし、『私がやりたい』作業なので残している。

つまり自動化っていうのはやりたくない単純作業をラクにする技術だと思うんですよ。ちなみに私はPythonは遠く昔にやっただけで現在はやっておらず専門外。今回の自動化ScriptはAIに『こういうことやるコードをPythonで書いてくれ』と頼んで出てきたものを私が調整しただけで、8割はAIが書いてます。そう、AIによって自動化スクリプトを書く難易度はぐっと下がっているのである。

ってことで皆さまも個人サイトなり何なりをぜひ自動化してみてくださいませ！

あざらしいっぴき Advent Calendar 2024 - Adventar 10日目の記事でした。おわり

自分的個人サイトの作り方

これはひとりアドベントカレンダーあざらしいっぴきの4日目の記事です。

今年は個人サイトをいっぱい作ったかもってことでいろいろな個人サイトの作り方をおさらいします。

メインで管理してる個人サイトは4つ。

• ポートフォリオとしてのメインサイト
• 小説サイト
• アルバムサイト
• らくがき倉庫

どれもフレームワークはastro、デプロイ先はCloudflare Pagesを利用しています。 構成は大きくわけて3種です。

• コンテンツは基本CMS管理
• コンテンツの一部をCMS利用
• すべてGithub管理

というわけで選択理由やメリデメについて語っていきます。

半期ふりかえり

会社のふりかえりついでにプライベートもふりかえるかってことでふりかえってみる。半期という名の1月～9月振り返り

やってたこと

2023年にメンタルを崩してたこともあってあえて『開発をがんばらない』をしていた。ちょうどよくTwitterも辞めたので開発情報源はたまに見るZennとRSSリーダーだけ。

サイトの更新は定期的にやっている。コンテンツ更新だけでなくコード更新もしている。

新規の個人開発とかはしていない。新規のコミュニティとかにも行っていないし、今年は社会人になってから1番静かな年だったかもしれない。

仕事はそれなりにこなしてた。アプリを初めてやったのだが、OSによっては動かない機能を調べながらやるのはかなり楽しかった。公式のありがたみ感じる日々だった。

結果

がんばらなくてもいいんだなと思った。

がんばれるに越したことはないのだろうけど私の場合はがんばろうとした結果メンタル壊したのが2023年なので、がんばらずに生きていけるところを探した方がいいんだろうと思う。がんばらなくても技術記事は読むし。この技術今度素振りしてみようという技術も見つかるし。AtCorderとかやってみようかなとかも思うし。

たまにはがんばった方がいいのかもしれないけど、2024年前半関しては、2023年後半メンタルズタボロだったので休んで良かったと思う。おかげですっかり回復した。たぶん。

この先やりたいこと

このままやりたいことやりつつ生きてく。元々『UIをどうするか』みたいなことに興味が強いので、色んなUIを眺め探りつつ、たまに作りつつやっていければいいなと思う。何やるかは具体的に考えてないけど。気になる技術も出てきたのでそろそろ素振りしたいし、何か思いついたら作るかも。

あと最近Copilotに頼り切りでアルゴリズムとか書く筋力が衰えてる気がするので、AtCorderとかに手を出してみたいなと思う。脳みそ動かしたい。

date-fns v4.0が出てた

きまぐれ日課のnpm outdatedをやっていたら、date-fnsが4.1.0になっていた。
メジャーバージョン系はbreaking changeが怖いので基本公式の情報を見てから上げるようにしている。結論から言うと私に影響するbreaking changeはないので上げちゃうことにした。

ちなみにv4.0.0が出たのは2024/9/16で、v4.1.0になったのは6 hours agoだそうだ。日本時間の2024/9/17の14時くらいかな。

で、公式のアプデ報がこれ↓ 

blog.date-fns.org

今までtime-zoneサポートしてなかったっけな～と思って読み進めると、どうやらサードパーティによって実現されていた模様。なるほどね。

で、Time zones supportのサポートの章をChromeの翻訳の力を借りて読むと。かっしこ！めっちゃかしこいやん！！！って気持ちでいっぱい。特に違うTZで定義した時間の差を算出するのにinでTZ定義して正しく差を出せるようにするところめ～～っちゃかしこい。これ閃いた時は絶対自分のことめっちゃ天才だと思ったと思う。思ってほしい。正直めっちゃ天才だと思う。

Breaking Changesの章でも『大抵のメジャーリリースはBreaking Changeするもんだが我々はできるだけしないつもり』と言ってて好印象。これからもついていきます！！

NILTOを使ってみようとした

フェンリルのCMS、NILTOをちょっと試してみました。 結論として自分の用途にはアンマッチだったので止めたのですが、そこまでの感想をば。

NILTOとは

• 公式はこちら → NILTO (ニルト) - チームの理想を実現するヘッドレスCMS
• フェンリルが出している新しいCMSです。UIがかなり面白そうなので触ってみることにしました。

やろうとしたこと

• 自サイトの『制作物』のセクションをCMS化しようとしてました。なのでフィールドは下記のような感じでした
  • [必須]タイトル
  • [必須] 画像
  • [任意] ひとことコメント
  • [任意] URL（制作物サイトがある場合）
  • [任意] URL（Github）

結論

• 画像のスキーマから『src, alt』のみで、astroのImageタグで使うImageMetadataの生成が困難だったので止めました。
  • ImageMetadataは『src, width, height, format』が必須です。

気になるポイント

フィールド作成がドラッグアンドドロップ

• 横につなげたりとかできるのかな？と思ったらそうでもなさそう？今回はシンプルなフィールドしか作成しなかったので、あんまり恩恵を受けられませんでしたが、複雑なフィールドを作る場合は役に立つのかもしれません。

ライブラリはなさそう

• それはそれでシンプルで良い気もします

画像フィールドがwebpを受け付けてくれない

• たまによくありますよね

公開ボタンを押して『保存していない変更は削除されます』旨が出たことがあった

• 『まあ飛んでもいいや』ってデータなったのでそのままGOしたら、普通に保存されてました
• 自動保存なので、自動保存のタイミングと公開ボタン押したタイミングが悪かったのかも

感想

• ぼっち開発なので実験できませんでしたが、共同編集機能のあるCMSは中々珍しくて良いんじゃないかな、と思います
• ただ私はひとりな上にwidth/heightがどうしても必要だったので、自サイトへの導入は見送りにしました
• 共同編集が必要になったりしたらまた再チャレンジしようとおもいます！おわり

Cloudflare PagesのサイトをGithub Actionsを使って定期デプロイする

ある日、GtihubActionsからエラー通知が届いた。 私のサイトはRSSで自分のブログの記事を表示しているのだが、これをVercel→Cloudflareに移したことで落ちてた模様。修正する。

結論

• 完成品
• scheduleで"0 0 * * *"にすれば毎日0時0分にデプロイされるのでそれを利用
• Vercelとは異なり、GithubAcitons内でBuildコマンドを叩く必要がある

name: deploy website
on:
  workflow_dispatch:
    inputs:
      ref:
        description: deploy website
        default: "main"
        required: true
  schedule:
    - cron: "0 0 * * *"
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build
        run: npm install && npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@1
        with:
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          projectName: ${{ secrets.CLOUDFLARE_PROJECT_NAME }}
          directory: dist
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

やっていく

• 元々Vercelな部分をCloudflareに置き換えていく
• Use Direct Upload with continuous integration · Cloudflare Pages docs の Use GitHub Actionsの章に書き方は書いてあるのでこれをコピペ
  • コメントアウトされているBuildの部分は利用するのでコメントアウトを外す
• Settings > Secrets and variables > Actions > Repository Secretsに下記を設定していく
  • CLOUDFLARE_ACCOUNT_IDはCloudflareダッシュボードのURLのhttps://dash.cloudflare.com/***の***部分
  • CLOUDFLARE_API_TOKENはダッシュボード右上のユーザーマーク > My Profile > API Tokensから作成可能。
    • GitHub ActionsでビルドしてCloudflare Pagesにデプロイする の Cloudflareのトークンの作成が画像つきでわかりやすい
  • CLOUDFLARE_PROJECT_NAMEの部分は公式ではsecretsされてないのでsecretsにする必要はないかもしれないが、GithubActionsにべた書きしたくないのでsecrets化した

補足

• 今回はpushではなく定期実行なので、workflow_dispatchはをつけておくとWEB上からGithubActionsを発火させられてデバッグが楽。むしろつけないと定期実行タイミングにしか動かないのでデバッグが大変。

おわり

• VercelではBuildをいれてなかったので、最初Buildをすっとばして『distがないよ』というエラーが出て、あれ？distじゃなかったっけ？と何度か確認してしまった
• VercelもCloudflarePagesも定期再デプロイがﾎﾟﾁﾎﾟﾁでできるようになったらいいなあとは思うが、まああまり需要はないのだろうな
• Cloudflare Workersを使った方法もあったが、cron用に1つリポジトリを作った方が良さそうな雰囲気になったところで止めた。

cloudflareの*.pages.devを閉じる

astroで作っているサイトをcloudflareに移動した。ドメインはcloudflareで管理しているので、独自ドメイン設定も楽々完了。

設定画面を見ていて気付く。独自ドメインを設定したのに、Cloudflare Pagesのデフォルトである『*.pages.dev』が生きている。同じページが違うドメインにあるのは避けたいので閉じたいが、Settingsにそれっぽいボタンがない。

行き当たったのがDevelopersIOの下記の記事。

dev.classmethod.jp

私が求めてるのは上の記事の『2. バルクリダイレクト』の方法だが、普通にページ自体をデプロイしない方法があるはずだと思ってもう少し検索。公式を発見。

developers.cloudflare.com

『Disable access to *.pages.dev subdomain』の項の2つ目。

Redirect the *.pages.dev URL associated with your production Pages project to a custom domain. You can use the account-level Bulk Redirect feature to redirect your *.pages.dev URL to a custom domain.

公式でもBulk Redirectの手法が説明されていた。*.pages.devの公開自体をオフにする手段が何らかあると思ってたのだが、公式の説明がこうなら多分ないのだろう、ということでDevelopersIOの記事と同じ手段を実行した。

独自ドメインセットした時にBulk Redirect設定もサジェストしてくれてもよさそうに思うが、違うドメインに同じサイトがあることを特に気にしなくてもいいのだろうか。悩。