2024-11-17外部脳考える
https://gyazo.com/3917ba7c677367b442dfd29ecda7f8af
翻訳が止まってるのではなくimportでコケてるのか
振り返り
が、これはデータを持つのではなく、アクセス時にScrapboxのAPIを叩いてレンダリングしているだけ
良い特徴:
Vercelでカスタムドメインで配信
UIの設計が自由
悪い特徴:
DBを持たずScrapboxのAPIでデータを取得しているのてScrapboxから得られないデータを用いた処理ができない
読んだ
2022-02-24 「Scrapboxのコンテンツを元に、ビューをカスタマイズして、カスタムドメインでVercelを使って配信しているもの」といちいち言うのは面倒なのでmemと呼ぶことにした 複数のプロジェクトをまたぐことの問題/ニーズ
複数のサービスをまたぐことのニーズ
自動英訳している
良い特徴
言語の壁をまたいでる
悪い特徴
ViewがScrapboxなのでUI上で翻訳であることを示したりすることが困難
自動的にデータを取ってembedしている
実験的に複数のプロジェクトをまたいで検索できるようにしている
embeddingのデータから先日やったような濃い塊の抽出をすることができるはず これはprivateなのか
embed側
omoikane-embedを作ってからそれを/nishioに適用したのだった
サーバサイドはprivate repos: nishio/vecsearch-service にある
周辺探索
静的レンダリング
拡張可能性、他者とのコミュニケーション、Webサイト公開の三つが論点
いい整理だ、自分でもここまで書きながら「解決すべきニーズが複数混ざってるな」と思っていた
僕のニーズがこれとイコールであるとは限らないので自分でちゃんと考えなければならない
考察
考えてみた結果nishio.icon
ObsidianかScrapboxかは誤った二者択一
「拡張の自由度が高い」は曖昧なので、どういう拡張をしたいかをもう少し明確にする
Viewを拡張したい
バックエンドはScrapboxのままで良い
日本語リアルタイム部分は引き続きScrapboxでよい
元々1日1回ペースで英訳して公開していたものの置き換えなので変換ディレイは問題ではない
今までScrapboxにインポートしてた
けど、そうするとそもそも英語がネイティブ言語ではない人にとっては単に「なぜか機械翻訳できないサイト」になる？
翻訳である旨をUIに足すことができないのが不満
インポートがコケるようになったので、もう「書き込みAPIのないサービスをインポートで書き換える」というハックに頼るのはやめたいなーという気持ち
同じ仕組みで日本語版もホストできるのではとか、ついでに新しい機能をつけることができるのではとか考えている
やりたいことが色々あるせいで、全部をできるように抽象度を高くしてしまい、その結果具体的な要件から離れすぎて意思決定の手がかりが減ってしまう問題
一旦英語版ホストに絞るべきか
実際にやるとわかることも多い
Viewを置き換える上でObsidian経路を通るべきかどうかは未知数
2023-08-20 にv4がリリースされていて構成が大きく変わっている
Hugoのテンプレートに書き慣れていなかったので、JSXでフロントエンドのカスタマイズができるのは助かる
おっ、React的にJSXでカスタマイズできるようになってるぞ
ネクストアクション
external-brainとかで新しく作る
JSONを保存
Quartz v4でGithub Pagesにする
(/nishio-en や mem.nhiro.org は一旦消さずに並行運用)
想像
/nishio-enはこのままだと更新されないし、GitHub Pagesで動くようになったら「こちらをみてね」的ページをピン留めして終了
memはまた別の話
長期的には合流したらいいけど現時点では別にいいか
embeddingのデータを使った面白いことはomniから派生したらいい