r7kamura/nippoのリポジトリを作り直した。

r7kamura/gialogの設計を　大幅に見直したためである。一応既存ユーザー用にmigrationスクリプトも書いてみたが、コードの方も新しいものに変えたりしないといけなくて、正直データ移行は諦めて作り直した方がはやい、と思い作り直した。

旧バージョンのデータ構造でもまあ別に問題無く使い続けられるので、既存ユーザーはそのまま使い続けてもらっても全然OK。古いままでいると特に不利益を被るとかは無い。新しい版では、ファイルの保存形式が新しい版ではMarkdownになったので、dataブランチの再利用性が高くなって将来的に何か別のMarkdownを使うブログに移行したくなったときにファイルのコピーだけで済んで手軽たり、diffが少し見やすくなったりという利点がある。

ghコマンドを利用して、日本時間でその日のnippo用のIssueをブラウザで開く、なければついでにつくる、というのをやりたい。

Issueのタイトルを元に検索するにはこうする。

$ gh issue list --search "2022-05-09 in:title"

Showing 1 of 1 issue in r7kamura/nippo that matches your search

#1  2022-05-09    about 1 minute ago
/home/r7kamura/ghq/github.com/r7kamura/nippo main
$ gh issue list --search "2022-05-09 in:title" --json number
[
  {
    "number": 1
  }
]
/home/r7kamura/ghq/github.com/r7kamura/nippo main
$ gh issue list --search "2022-05-09 in:title" --json number --jq "first"
{"number":1}
/home/r7kamura/ghq/github.com/r7kamura/nippo main
$ gh issue list --search "2022-05-09 in:title" --json number --jq "first.number"
1

日付を得るにはこう。

$ date +%Y-%m-%d
2022-05-09

任意のタイトル空のbodyでIssueを作成するにはこう。

$ gh issue create --title "2022-05-10" --body ""

Creating issue in r7kamura/nippo

https://github.com/r7kamura/nippo/issues/2

なんやかんやして全てやるにはこう。

title=$(date +%Y-%m-%d)

number=$(gh issue list --search "${title} in:title" --json number --jq "first.number")

if [ -z "${number}" ]
then
  number=$(gh issue create --title "${title}" --body "" | sed --null-data --regexp-extended --expression "s;.*issues/([0-9]+);\1;")
fi

gh issue view "${number}" --web

YouTubeの登録者数が100人を超えた 🎉

確か100人からチャンネルのカスタムURLを発行できるようになるらしいので、有効化されるのが楽しみ。

世間がSSGという概念を獲得してきたので、Next.jsの next export みたいに、Rubyでも rack export とやると静的サイトが生成されると良いのではと考えたのだけど、それって前につくったrack-captureだなと思い直した。既にあったな…

Next.jsはエンドポイントごとに getStaticPaths, getStaticProps を定義する場所が用意されているのが良い。静的ファイルを配置する場所も決まっているから、特に困ることは無い。

Rackでやろうとすると、自由過ぎてそうはいかない。

Railsでやろうとすると、静的ファイルについては規約があるので上手くいきそう。getStaticPaths, getStaticPropsを書く良い場所はない。Railsが1 action 1 classという設計だったら良かったのにね。N actions 1 classになっているのは、Railsの本当に設計が悪いところだと思う。

config/initializers/rails_exporet.rbのような設定用のRubyコードが書ける場所を用意して、rails exportというサブコマンドを追加するようなrails-export gemを用意して、rails export --initで設定用コードの雛形が生成されるようにして、というのをやると良いかも。でもRailsアプリを静的サイトに使って誰が嬉しいのかという話もある。

Luaの使い方を見ていると、Perlや初期のJavaScriptのことを思い出す。

  • この辺の言語の軽い書き味を備えている
  • それなりに高速
  • それなりに移植性が高い

というのは良いことだ。実際、OBSがLuaの実行エンジンを持っていて (詳細は不明なので雰囲気で言っている) Luaで書いたスクリプトをサクッと動かせるのだから、利点が上手く活きていると思う。

この例には幾らか驚かされた。

u = {[{}] = 1729}
b = u[{}]     -- We might expect 1729, but it's nil:
-- b = nil since the lookup fails. It fails
-- because the key we used is not the same object
-- as the one used to store the original value. So
-- strings & numbers are more portable keys.

ハッシュの計算方法に、素朴にテーブルというオブジェクトのIDを利用しているという感じなのかな。

Luaのメタテーブルとかいうの見てひっくり返りそうになった。まあリクライニングチェアで作業してるので既にひっくり返ってるんですが……