記事リンクずれ。。。

せっかくipfs用に起こしたマークダウン記事リンク bafyreighellwstevjhzeow5ktf3sn3sdgivscqdebbu5i6375xzlilhcle の日付データがずれてることが判明。日付がずれると 後々URLがずれる。。。

生成パス
/2020/10/02/dockerdocker-for-windows-でディスク共有したいならwsl2をオフにした
実際のパス
/2020/10/03/dockerdocker-for-windows-でディスク共有したいならwsl2をオフにした

まぁツールを加工して、起こし直しかねぇ。

ipfsブログ、その後のその後

マークダウンで記事を書いたときの記事追加を単純化するためのツールを組ながら、記事のルート切替を作ろうとしたとき、単純にipfsへのファイルアップロードではなく、直にノードとリンクを操作する必要があることに気づいたので、いろいろ検討していたのだ。

記事そのものは直にテキストと画像ファイルを書くのが楽だし、記事更新を行ってルートノードを切り替える操作はファイルが存在するのは面倒なので、記事そのものはipfsのファイルシステム互換機能(ipfs files ,UnixFS)を使い、まとめるルートノードの操作はDAGノード/DAGリンクで行う形にした。

記事書き出しツールも大枠は動いたけど、もうちょい調整がいるところ。でもほどほどには動いているので、記事の同期ももう少し早めにできるかも。

最新記事を同じURLでアクセスできるようにするためのDNSLinkも少し調整してみてとりあえず http://ipfs.akibakokoubou.jp/ に設定。ああ、そういえば静的サイトでのhttps設定がなにかいるな。ちょっとそっちも調べないといけない。

静的にビルドすると動的部分が全部プリレンダになるのでかなりでかくなり1GB越えてしまった。。。個人サーバーにデプロイしてもよいのだが(前回はラズパイにデプロイしたし)、ちょっと安定度の確認も含めてpinataのほうを有料アカウントにしてデプロイした。自分の回線がCATV系の回線で、その他の作業も含めて上りが大きすぎとこの前文句が来たのであまり上りが大きくなる可能性のあることは今は抑えておきたいところ(まぁここのアクセス量はたいしたことないが)。回線は近々光に変える予定ではある。

最終的に今のwordpressをリプレースできればpinata側が有料でも割安にできるはず。wordpressはGCPのvm無料枠でやれるかもという記事を参考に動かしていたのだが、wordpressのphpを7系に上げたときのメモリ消費増加で有料枠になってしまったのだ。無料にこだわって5系のままでもよかったのかもしれない。この際いろいろ最新にアップした上でコスト削減するのもありかもしれぬし。

ipfsブログの検討、その後

先日考えていたipfs対応新ブログについては本文をマークダウン記述でipfs上に階層構造で保存して、それとは別に静的ブログに変換したキャッシュを同じくマークダウンに置くというのが形上はよいと思ったので、いろいろ試してみた。

記事個々は小ディレクトリに置いて、本文はindex.mdで書く。各記事の画像は小ディレクトリの中に配置することで個々の記事にcidを設定できる形にする。

それ全体をまとめたディレクトリをルート記事ディレクトリとする。

それとは別にそれらの記事mdを読み込んで静的サイトをビルドしてそれをまたipfsに配置する。

すでにあらかたできてたNuxt/Contentベースのプロジェクトで上記を実現するのに、Nuxt/Contentをカスタマイズして、ipfsから直接mdのツリーを読み込んで静的サイトをビルドするように修正。とりあえずは動くところまで行ったと。

現時点 https://bafybeigkbcll4kizopo5v7wtbnvcouttreb6aptql74aapnruxhwo5dvca.ipfs.dweb.link/ に公開中。ipfsマークをクリックすると基のipfsディレクトリやマークダウンを表示します(ラズパイ上のデプロイなので外部からは遅いかも。。。)

とりあえずごそごそやってここまでは出来たものの、まだipfs直書き出しや履歴の自動管理まではまだまだ。

html部分はiframeとかでipfs側に保存したマークダウンを直接表示できるとコンテンツ的には整合した話になるのだが、今の時代にReact的ツールを使わないとかいう形はそぐわないので、キャッシュhtmlが冗長になってもこういうスタイルのほうがよいような気がする。

遅いとか冗長とかいう問題は技術改善によってどうにでもなる話なのでそこは気にしないのだが、md部分の編集管理/履歴管理はシンプル化しないとつらい部分があるな。

そこがうまく回るようになったらDNSLinkの管理方法も考えた上でブログ移行かな。

ipfsでブログを作ってみてわかったこと

NUXT/contentで試しの変換ブログはそのまま作り込み続けているのだが、ipfs対応について作ってみて、わかってきた。

最初ブログを一括変換して一つのcidを作って、残りはそこからの相対コンテンツという形にしてみたが、ipfsはコンテンツがわずかでも変わると別のcidに変わってしまう。

つまりボタンのgifを少しいじるだけでも別のコンテンツという扱いになってしまう。

例えば「ある1つの記事の内容を少しでも書き換えたら別のコンテンツとして新しいcidを発行します」という話であれば、記事の永続性の保証という意味で分かるのだが、「ある1つの記事の内容を少しでも書き換えたら、そのブログに含まれている他の記事も含めてすべて別のコンテンツとして新しいcidを発行します」では記事の永続性としてはちょっと使いにくい。ブログ全体としては確かに以前とは異なりますという意味では正しいが、そこを保証されても何が変わったのかが訳分からなくなってしまう。たとえばマニュアルのサイトとしてVer.1.0のサイトのcidを起こして、これがVer.1.1になったら次のcidを起こすという使い方は有用なのだが、個人サイトでデイリーな記事を追加したら毎日cidが変わりますという使い方は面倒なだけだし保存容量の無駄遣いにしかならないし。。。

つまり個人ブログみたいなものでやるなら「ブログ全体」→「1cid」ではなく、「1つの記事」→「1つのcid」にしてブログシステムがその記事のcid群を管理するという形にするのがよさそう。そうすればブログシステムそのものは書き換えてもcidが更新されない(ボタン画像を貼り替えてもcidは変わらない)という形にできる。1日のログを後で書き換えることはめったにないから発行したcidを永続しても問題ないし、技術記事などで内容を追記したときに新cidが発行されるという話なら、それは更新履歴として管理できると便利な話になる。

そうなってくると

一番単純には「保存した各単一記事cidのhttpゲートウェイurlをブログシステム側でiframeで埋め込む」とか「記事そのものはmdのままホストしてcidを発行して、jsとかで取得してレンダリングする」(corsをどうするのがよいかな?)とかいう形になるんじゃないかな。

iframeが復権するのかな?

ちょっと工夫しないとおいしくなさそうなので、少し再検討中。

縮小版をpinataにピン止め中

ipfsのピン止め=webでいうファイルをホスト

サブドメインゲートウェイ版(cidv1b32)

https://bafybeidecboxdn52mlchzgzhahezrsrztbg3sfkuq3isbpfflousf44xw4.ipfs.dweb.link/

パスゲートウェイ版

https://ipfs.io/ipfs/QmV5FxCrkA9fAFVd1Ckn2wtKQWi66Hp4CUKcSGRSQYqc4E

パスゲートウェイだとガチの相対パスになるので、結構むずいな。。。SPAにでもしないといけないのか。

こういうコンテンツは変動していくものなので、コンテンツ指向だけでなくロケーション指向と織り交ぜないといかんねぇ。

(1バイトでも変わるとパスが変わるので、上記リンクは予告なく消えてますのでご了承を)

2021/04/29追記
ipfsのピン止め=webでいうファイルをホスト とは言えなかった。
そういうケースが現実的には多いものの、ピン止めは論理的な話なのでcidが発行済み(つまりどこかでipfsに保存済み)のファイルを別のipfsクライアントからピン止めすることも操作としてはできる。ただピン止めが保証されるためには実体ファイルが必要なので結局はピン止めしたクライアントにコピーされてくることになる(コピー完了後にピン止め成功)。○×というより△くらい?

ブログを改築中

最近何をやっているかというと、ブログシステムの改築をかんがえてる。

ipfsの話を知って、なるほどねーと思ったのだが、さてipfsに何かのっけてみるとして自分の持ってるコンテンツで最も当たり障りがないものというと、ブログかなーと思った訳です。

ipfsでブログということになると、DBを使ったサービスではなく静的コンテンツにする必要があるので、おお、今風の静的ブログだなと思って、ならついでに最近作っているMiツールとかで問題なさそうなアクティブコンテンツ(Mi-runnerとか)も合わせて乗っけられるくらいモダンに作ろう、と。(アクティブコンテンツとかいうと、短冊とか麻雀牌崩しとかSilverLightとかUnityとかで作って置いていたな。いろいろ引っ越ししているうちに動かなくなっているが。。。そういえばSilver Lightとか懐かしい。。。)

静的サイト生成ツールでとりあえずお勧めされていたいくつかのツールを試してみるためnpmからWordPress→マークダウン変換ライブラリを持ってきて( https://www.npmjs.com/package/wordpress-export-to-markdown )変換抽出してみる。結構うまくエクスポートできたので、HugoとかVuePressとかに食わせてみたのだがどうもしっくりこない。

  • Hugo
    テーマが豊富なのでWordPressなみに気楽に使えそう。→相対設定してもカテゴリとかの相対設定が崩れるケースがあった。
  • VuePress
    Vueはある程度触ったのでアクティブコンテンツを置くときに知見が使えて便利かな→相対変換ツール(all-relative)を使ってもカテゴリとかのリンクがずれる。それでも結構作り進めたのだが、現在の2000ページを越える記事(よく書いたものだ。。。)を出力変換しようとするとjsがメモリオーバーでクラッシュしてしまった。。。(–max-old-space-size=16384 でも出力不可。。。)

でちょっと悩み混みながら結局この間検証に1~2ヶ月くらいはかかっていて、ああ、もう無理かも、と思ったときにNuxtを思い出した。

Nuxtがサーバーサイドでもクライアントサイドでもhtmlレンダリングが出来るとかいう話をふと思っていたので、当初少し考えた。でも以前他の人がやってたNuxtの案件を手伝ったときにNuxtが何をやっているのかがよく把握できなかったのでちょっと苦手感があったのだ。

VuePressが無理っぽくなった時点で、Nuxtでブログと探し直すと、最近は Nuxt contentというツールがあるという話がたくさん出てきて、ちょっと調べてみた。

「マークダウンで作るブログ(静的もOK)」まんまの話だった。

Vuetify+Nuxt/contentというジェネレーターもあるらしいし、そのまんまで起こしたらわりとさくっと動いてしまった。2000ページ越えもさほどの負荷もなく変換できた。Miツール類もフロントエンドはVuetifyだしそのままいける。

という訳で暇々に基本機能を作成中。

ある程度まともになったらWordPressからリプレースしようと思う。

ここ最近は

ちょっとMiのコーディングではなく、お家linuxサーバーの調整をごそごそいじっているところ。がっつりやるとなかなか大変。。。

それとは別にMiで組み立てたネックスピーカー&ToDo管理ツールはわりと便利に使えている状態。お家linuxサーバーをがっつり立ち上げようと思ったあたりも、Miツールが思ったよりうまく動いて便利だったことや、ToDoの管理やネックスピーカーでの通知管理などで時間管理効率が上がったからかもしれぬ。もう少し手を入れたい部分は多々ありはするのだがとりあえずはサーバーの調整のほうを当面やってみる。まぁそっちに飽きたらまたMiツールのほうに手を入れるのがよかろう。

miのニュース機能に英語ニュースを追加

元々miのネックスピーカーには仕事開始などの定時時報機能を入れているし、定時に合わせてメール件数やニュースサマリーを読み上げる機能はつけていて、それなりに便利に使っている。ただ最近やっぱり英語は慣れていくべきだなと思い立って、英語ニュースのヘッドラインの読み上げも機能に追加した。まぁ単純に英語ニュースヘッドラインの無料APIを呼び出して、今の読み上げ機能に送り込む形なので難しくはないのだが、どのタイミングで流すのがよいのかはちょっと検討中。

日本語ニュースヘッドライン読み上げとランダムで切り替えるとかもありだけど、ちょっと悩み中。どちらにしても音に慣れるべきだろうとは思うので。

将来的には現在のマウス/キーボード状態の検出で、手が空いたときや集中をかいているときに流れるようにするのが理想ではあるのだが。

ToDoその後

野暮用をしつつToDoのツールは細かく改良は続けてる。属性フィルタを付けたりすると結構朝のToDo選択/整理もついたりしてよい状態。

最新の改良はToDo分割とTrelloとの連動。ToDoは粒度が粗くなったり細かくなったりするものなので、細分機能は必要に思えるのだが、そこまで管理するとToDoがまとまらなくなって面倒くさくなる。なので細分時にTrelloと連動させて問題解析にフォーカスを与えるとともに、細分タスクを完了したら自動で元タスクが復活する仕組みを組み込み中。面倒さを減らす動的部分を入れたのでおそらく面倒にはならないと予想しているが、まぁチューニングしてみる。