Noratetsu Lab

　基本的には見た目に変化はないことですが、サイトのデータの管理方法を大きく変えました。

　これまではDynalist上で書いてDynalistからAPIでデータを取得してサーバーサイドでサイト用データに変換していましたが、全てmdファイルにしてローカルに置き、そこからサイト用データを生成する形にしました。
　Dynalistの構造を利用して表現していた記法を機械的にMarkdownとHTMLに置き換えてmdファイルを生成しているため、一部表示が変化したり乱れたりしている箇所があり得ます。軽くチェックした限りでは概ね大丈夫だとは思いますが、リンクの置換ミスが稀にあったりするので、しばらく「あれ？」と思うような部分が残るかもしれません。
　お知らせは以上です。

---

　ここからは変更の経緯などを記録として書いていく。
　当初、自分の文章の公開方法はBloggerというサービスを利用してのブログだった。Bloggerはブログサービスとしては編集もしやすく昔から使っていたもので馴染みもあって気に入っていたが、やはりデータが自分の手元にないということが不便だった。記事を編集するとなればいちいちその記事の編集画面を開いて編集して保存してということをやらなければならないし、複数の記事について一括で置換する的な処理はできない。何もかも手動でやらなくてはならない。
　そこで全て自分の裁量でデータを扱えるように自分でサイトを作ることにして、現在はDeno Deployというサービスを使って公開している。記事データについては最終的にサイトを開いた時に読み込まれるJSONができていればいいので、どういう経路でそのJSONに至るかはなんでも構わない。今回の変更もJSONを生成する手前の話なので、サイト自体のコードはなんにも変わっていない。
　今の形式でエディタとして利用できる手段は「APIで自分のデータを自由に取得・編集できるアプリケーション」または「ローカルファイルを編集できるアプリケーション」ということになる。前者の例がDynalistやNotionで、後者の例がObsidianや一般的なテキストエディタである。

　Dynalistは文章エディタとして非常に優秀だ。それは「文章のアウトラインが作れるから」という意味ではない（それも重要な要素ではあるが、私にとってはさほど大事なことではない）。それ以上に、行単位で子要素を持てたりノート欄を持てたりすることによって、自分向けの情報も機械用の処理の指示も自由自在に文に付属させられることが大きなメリットである。
　たとえばMarkdownに専用の記法がない折りたたみなども、「この記号で始めたノードは子要素を中身としたdetails要素にせよ」ということを（コーディングの知識があれば）柔軟に定義できて、detailsタグなどを文中に記述する必要はない。自分が文章を書く上でそのような異物が混じらないことは重要だ。
　最終的に文章に反映させない、いわゆるコメントなどもノート欄や子要素で表現できる。加えて、没にする部分についてはプログラミングと同様の形でコメントアウトの記法も定義している。
　行単位でメタデータや構造を持てることによって、アイデアを思いつきさえすればなんでもできるのだ。

　ただしDynalistでは不自由な面もある。それがネットワークの作りにくさだ。
　Dynalistにもノードリンクという機能があるのでそれを使えば「この記事へのリンク」ということは表現できるが、サジェストを使おうとすると全てのノードが対象になってしまうがゆえにノイズだらけでまともに機能しない。ノードリンクについては以前書いたが（ノードリンクを活用し全てのノードに意味のあるアウトラインを作っていく）、ノードリンクを機能させるには使い方に注意を払う必要がある。
　全てのデータが上から下に並んでいなければならないというのもネックだ。データが全て時系列のブログ的記事なら公開日順に並んでいればそれでいいのだが、例えばキーワード単位で作るデータ（当サイトでは「用語集」としている）については、順番に並ぶことに必然性がないので、自分の認識とDynalist上で表現されているデータの並びとが一致しない。
　それゆえに用語集部分だけ先にネットワーク型の管理方法に移転していたのだが、そうするとツールが別になるので記事とリンクが直接繋がらない。これまでどうしていたかというと、Dynalistのタグを用語集に含むキーワードと一致させることで、JSON生成時にサイト上でリンクになるよう処理を可能にしていた。サイトのデータを作るという意味ではそれでも良いのだが、自分の手元でリンクになっていないので作業が直感的にならないという問題があった。

　また、Dynalist（というかアウトライナー）に情報を蓄積させ続けるのが果たして妥当かということもある。Dynalistは仕組み上データベースであるし、検索機能が充実していることもあって主観的にもデータベースらしく使うことは不可能ではないが、しかしデータベースとしての活用が向いているかというととてもそうは言えない。無限に増え続けるタイプの情報を扱うなら他に相応しいものがある。

補足（クリックで開く）

　以前Dynalistのデータベース化について書いたが（アウトライン型データベースとしてのDynalist）、それは今話していることと少しレイヤーの異なる話である。というのは、データベースと言ってもひたすらに情報を蓄積していく種のデータベースと、何かを表現するにあたってそれを構成するデータの集まりとして必要なデータベースとがあって（データベースというものに詳しい訳ではないのでふわっとした言い方になってしまうがご容赦願いたい）、前回は後者のためにデータベース然とした形式から解放され自由に文脈を添えられる有機的なデータベースを考えることが有効だという話をした。 　サイトの記事データというのもある程度までの規模は「サイトを構成するためのデータの集まり」という性格が強かったが、やはり何百件も蓄積して更に今後も増え続けるとなると（既に800件近くある）、これらは単にサイトの構成のためのデータではなく自分の歴史と一体になった情報であり、データベースとしての性格も変わったと言える。 　最初から増え続けるタイプのものだというのはわかっていたわけだから限界は予見できたはずのものだが、やってみなくては「向いてなさ」の形が見えてこなかった。 　実際、今後もDynalistに蓄積させ続けるのも無理なことではない。もしデイブ・ワイナー氏のようにアプリケーション自体を自分で作っていてDynalistに不足している要素を自力で完全にカバーできるのであれば、アウトライナーという形態自体が欠点になることもない。アウトライナーであるというのは単にデータの表現形態のひとつに過ぎないからだ。 　ただ現状、Dynalistのシステムでは何千件のような単位の膨大な件数を管理することに特段のアドバンテージはない。データの読み込みのタイミングからしても、何千ノード程度ならいいとしても一件が何十から何百のノードで構成され得るデータが何千件となるとかなり厳しい。画像を多く含めば通信量が嵩むし、ノード数が増えすぎると差が認識できる程度に挙動も重くなる。

---

　Dynalistのノードはどうとでも解釈して使えるという利点があると同時に、自力で解釈を加えないと特定の範囲を一件のデータとして扱えないという難点がある。個別のデータとして形が定まったならば、それはNotionやObsidianのようなデータベースらしく使えるツールの方が扱いやすいし、年月が経った後でも未来の自分が認識しやすい。 　アウトライナーは情報を流動的に扱えるのが武器であり、基本的には「今ホットなもの」のための場であった方がよいと思う。過去のものになった情報、つまり情報として固定的になったものは、流動性の乏しさの代わりにデータとしての扱いに長けている種のツールを使った方が後々便利だろう。

　そのようなわけで、サイトのデータはmdファイル化し、Obsidianを用いて管理することにした。
　ただしDynalistで書くのが楽なので、Dynalistで初稿を書くというのは継続する。一通り書いたらプログラムでmdファイルに変換し、以降はmdファイルを編集する。
　書き終わったものの管理はObsidianを使えるmdファイルの方が楽だが、これから書くものはアウトライナーの方が良い。形が定まっていない曖昧な状態で置いておけるからだ。
　

　新年度ということで、自分の投稿スタイルをこの四月から少し変えようと思っている。

　Cosense（Scrapbox）で、倉下忠憲さんのPodcast「うちあわせCast」のノートを取ることにした。

• うちあわせCastノート by Noratetsu | Cosense

　聞きっぱなしでは次の日にはもう半分以上忘れてしまうしそれでは勿体ない。何も残らなければ聞く意味も減ってしまうので、ノートを取らなくてはと前々から思っていた。
　そう思いつつどこにどうやるのがいいかと考えてしばらく迷走していて、最終的にCosenseがよかろうという結論に至って新たにプロジェクトを作り、どうせなら公開するかということになった。
　基本は文字起こしにタイトルを付けてページを作り、テーマ毎のまとめページを用意してページリンクを組み込みながら短文を作って「何の話をしていたか」の概要を作るという形を取っている。

　まずお話の内容を切り出してページ化するフェーズと、それらを見渡して自分なりにリンクしたり解釈を記述したりするフェーズとがあり、今のところ前者に偏っているのでただ引用だけ書いたページが多い状態だが、手入れを繰り返して自分なりの「ノート」として意味あるものにしていくつもりでいる。
　一回分のページを作って整理するのにもかなり時間がかかるので、理想を言えば全部の回作りたいとは思いつつもなかなかできないかもしれない。しかし一部しかできなくても得られるものは十分多いはずなので、やれる範囲でちまちまやっていこうと思う。

Q. 共同編集にしてみんなで作ったほうが早いのでは？
A. とりあえず私は私のノートを作りたくてやっているので、「うちあわせCastWiki」みたいにしたい場合は誰か別に作ってください。
　

　毎年の年末に倉下忠憲さんが発行なさっている『ライフハックの道具箱』の2024年版が発売されました。

• 『ライフハックの道具箱2024』が発売されました | R-style

　私も参加しております。「ネットワークファーミングツール」セクションのCapacitiesの項です。コンパクトにまとめるのに骨が折れましたが、気合を入れて書いたのでCapacitiesのことが気になっている方はお読みいただけたら嬉しいです。Kindle Unlimitedで読めます。
　私も他の方の記事はこれから読むところなので楽しみです。

　さて、告知だけというのも当サイトの記事としては寂しいかなと思ったので、Capacitiesの使用風景の紹介を兼ねてこの原稿を書く際に使ったツールの話でも書いておこうかと思います。
　原稿を書くとなってまず最初にしたことは、CapacitiesでProjectオブジェクトを用意することです。タイトルは「ライフハックの道具箱2024にCapacitiesの記事を寄稿する」でした。そのままですね。（厳密には「寄稿」ではないのですがそれはさておき。）

　やるぞ～という気持ちを表すものとしてアイコンに炎を設定しました。そしてこのページをピン留めしておきます。
　このページには、締切等の決まり事や字数の目安などのメモ、どういう工程で何をするかの検討、やり取りのログといったことを書き込んでいきました。内容そのもの以外の情報を全部ここで扱うという形です。
　作業を進める時はデイリーノートにトグル項目としてこのページへのリンクを貼り、下位項目に個別のToDoやログを記述します。するとこのページのバックリンク欄に作業ログが並びます。

　次に、Dynalistに専用のファイルを作りました。ファイル名は「ライフハックの道具箱2024」です。ここでは内容に関わることを扱います。

　公式の情報、他の方が書かれた記事のリンク、自分が思うツールの特徴、文章の構成などを全部ここに集約しました。本文もここで書きます。
　自作のChrome拡張機能によってDynalistで文字数カウントできるようにしてあり、普段からごく普通のテキストエディタのようにしてDynalistを使っています。あちこちに情報を分散させずに済むので取り扱いが楽です。（Chrome拡張機能を自分で作って活用する（Dynalist））
　また、今回書くにあたって公式ドキュメントとブログはほぼ全部に目を通しました。といっても私は英語をすらすらとは読めないので、ChatGPTの力を借りました。元の英文を全部Dynalist内にコピーし、ChatGPTによる訳をノート欄にペーストし、英文と和訳を照らして誤訳や省略などがないか気をつけながら読んでいきます。ChatGPTのおかげでドキュメントを読むだけなら英語が不自由でもほとんど困らなくなりました。ありがたいことです。
　本文はMarkdown書式で書いていて、書いたものはGitHub Gistで確認しました（もちろんSecret設定です）。バージョン管理ができること、コメントをつけられることから、原稿を扱う形式として便利だと思ったからです。

　原稿提出後はその後のやり取りのログをCapacitiesに記録し、全部終わってからCapacitiesとDynalistの内容を整理して、後で見て一目瞭然な形に整えてこの件については完了ということになりました。
　書くにあたっていつもの数倍神経を使いはしましたが、短い記事を一本提出するだけなので、そんなにきっちりしなくてもできたことではあります。しかし敢えて雑にやる意味もないので、意識的に情報をきちんと整理しながらやりました。元々几帳面な質ではなく油断するとすぐ雑然とするので「どうせなら綺麗にやっていこう」と意識しています。
　Capacitiesはその「どうせなら綺麗に」という気持ちを惹起してくれるので、ズボラ人間でも恰も几帳面な人かのように情報を整えられます（個人の感想かつ当社比の話です）。

　ObsidianのWebクリッパーの話をしましたが（ObsidianをWebクリップ用ツールにすることにした）、自分のサイトの記事に試してみたところプロパティが歯抜けになっていました。メタデータについて何も気を使っていなかったので当たり前です。
　ということで、これを機に最低限の情報は取得できるように設定しました。

　と言っても、そもそも何をどうすればいいのか全然知らなかったので（Web検索で引っかからないようにしているので気にする必要がなかったのです）、検索して調べました。authorはmetaタグを使えばいいのですが、公開日の指定はそう単純ではないようでした。
　いくつか方法はあるようですが、簡単で代表的な手段が「構造化データ」をJSONの形で書いてscriptタグで埋め込むというものでした。「JSON-LD」という方式です。

• 構造化データ マークアップとは | Google 検索セントラル  |  ドキュメント  |  Google for Developers
• 構造化データの基本・仕組み・書き方まとめ｜Webマーケティング・SEO相談はデジ研

　ということで、記事のデータから以下のようにJSONを生成して埋め込むようにしました。場所はどこでもいいようです。

　とりあえずObsidianのWebクリッパーで取得する必要があるデータがあればいいので、こんなもんでいいかという感じです。
　あと関連リンクの部分も本文としてクリップしてしまう状態だったのを、本文だけになるようにしました。他のサイトの構造を参考にして、本文が入っているdiv要素のclassに「body」を足したらそこが本文だと判定されるようになりました。

　より詳細で正確な情報を知りたい方は上記のリンク先その他でお調べください。

　個人サイトを新しく作り直しました。

• Noratetsu House

　前のバージョンは普通にHTML＋JavaScript＋CSSで作っていましたが、新バージョンはDenoのFreshで構築しています。Freshはpreactを使って書くWebフレームワークで、多分Next.jsと近いものです（Next.jsに触ったことはありませんがおそらく）。前バージョンほど表示は爆速ではなくなってしまいましたが、管理はずっと簡単になりました。

　サイトのお引っ越しに伴い各投稿場所の運用の変更がいくつかあります。

• Blogger（Noratetsu Lab）の更新を終了します。
• のらてつの雑記帳 - zawazawaの活用は終了しました。
• ScrapboxのNoratetsu Lab Dict.プロジェクトの再公開はしないことにしました。

　Bloggerというサービスは気に入っているのですが、なんであれブログサービスを利用するとどうしても「投稿しに行く」という形式になるため、記事の管理はかなり面倒です。後から加筆修正するのが億劫だったので、自前のデータを反映させて簡単に更新できる形態を採用することにしました。

　以下はサイトについての語りです。

Labモード

　Bloggerを更新終了する代わりに、Bloggerに作ったデザインとほぼ同じデザインでコンテンツを見ることができるLabモードを用意しました。トップページ及び各記事の「Labモードへ」のリンクから移動することができます。このデザインは元々Bloggerにあったものではなく、自分でCSSを書いて原型を留めないレベルにアクロバティックに変更して作ったものなので、自分のサイトに移しても問題ないだろうと。
　機能の追加もしてあります。例えばバックリンクです。ブログサービスの多くで難点になるのは、リンクを貼っても貼られた側にそのことが反映されないことです。その場合、貼られた側にリンクを反映させるには手動でリンクを貼りに行く必要があります。非常に面倒で、大変に阿呆らしい作業です。なので自動で取得して反映するようにしました。

BBS風雑記帳

　以前ひとり掲示板で自由に呟くで書きましたが、zawazawaというサービスに自分だけが投稿する掲示板を作っていました。最近は専らPodcastの感想を書くのに利用していました。ひとりで掲示板を使うメリットは色々ありますが、SNSと同様にタイトルなしに発信できること、そして「過去レス」「過去ログ」を参照できることが特に大きな利点です。
　zawazawaに不満は全然ないのですが、どうせならこれも自前で賄おうと思い、それっぽいものを作ってみました。トップページの「BBS風雑記帳」のリンクから閲覧できます。自前だと投稿データの最新版を自分の手元に置けるというのも安心感があります。
　今現在はzawazawaに投稿していたものを引っ越したくらいでそんなに充実感はありませんが、スレッドを作るのは超簡単にしてあるので、まあ何か思いついたら気楽に書いていきたいと思います。

NTA-DIYレポート

　去年、Noratetsu Labにて「ノートテイキングアプリDIY体験記」と称してシリーズ記事を書いていましたが、途中でやめて書き方を模索していました。ひとつの案として、フォーマットを決めたレポート形式にすることを思いついたので実験的に掲載してみることにしました。
　そもそも文章の形で書く必要もないことを無理やり文章化しようとしていたのが問題の根にあるので、箇条書きでぽんぽんぽんと書く形にしています。そして各月のレポートを横方向に並べることで流れが見えるようにしました。
　場は整えましたがまだ中身がぺらぺらなので、気が向いた時に進めていこうと思っています。

データの構築方法

　コンテンツのデータは相変わらずDynalistに書いて作っています。Dynalist APIを使ってコマンド一発で記事データがビシッと作られるわけです。BBS風雑記帳もNTA-DIYレポートもそれぞれドキュメントを作って書いています。
　最近ひとつやり方を変えたのが、用語集部分のデータの作り方です。前まではこれもDynalistに書いていましたが、先日からScrapboxに変更しました（Noratetsu Lab Dict.として公開していたものです）。元々Scrapboxに書いていたのを、サイト用データを構築できるようにするためにDynalistに引っ越していたのですが、やはり用語的なものをアウトライナーで管理するのは非常に違和感があって更新が捗らなかったので、そういう用途に最も向いているScrapboxに戻すことにしました。
　Scrapboxのデータは外部からAPIで取得することはできないので、更新したらjsonをエクスポートし、それをスクリプトでサイト用のデータに変換しています。若干面倒ですが、Dynalistでやろうとするよりかは遥かに編集の流れが自然です。
　このScrapboxプロジェクトについては、先日「しばらく非公開にします」と書きましたが（Noratetsu Lab Dict.の改修作業をします）、サイト内で同じ内容を公開するわけなので、Scrapboxプロジェクトの方は公開しておく必要はないなと思い再公開はしないことにしました。

予定

　Freshを使うようにしたことでコンテンツの追加が極めて簡単になったので、自作ツールのサンプルやその他思いついたことを増やしていけたら楽しいだろうと思っています。
　

　このブログの用語集として作っているScrapboxプロジェクトがあります。

• Noratetsu Lab Dict.

　訪問者もそういないと思いますが、ちょっと使い方を変えるための更新作業をしようと思うのでしばらく非公開にします。（個人サイトに表示するデータを構築するデータベースとして機能するようにしようと目論んでいます。）
　

　前から作ろうと思っていた個人サイトができました。

• Noratetsu House

　　
　いやあ頑張った。
　見た目はどシンプルでしょぼい感じがすると思いますがかなり頑張っています。この先に進む前にちょっとでいいので触ってみてください。^[1]

ブログ、用語集、茶の間の統合

　これまで以下の場所にアウトプットしていました。

• 記事：このブログ（Noratetsu Lab）
• 用語集（フレーズや概念などの切り出し）：Noratetsu Lab Dict.
• ちょっとした短文：茶の間（のらてつの茶の間）→のらてつの雑記帳

　ブログを書いていてすごく気になるのが、続きとして書いた記事に前の記事へのリンクを貼っても前の記事からはそれが分からないこと、そして単語やフレーズを対象とした記述（つまり事典風の記述）を書きにくいことです。元々日記に適した形態なので仕方ないことでしょう。
　一応そのやりにくさを補うために、用語集と称した場をScrapboxに作ってちょこちょこ更新していました。Scrapboxの更新は簡単で楽しいのですが、ブログ記事とリンクするには手動で頑張る必要があります。ブログに書いたものを後から概念として名付けたりした時、元のブログ記事にリンクを貼りに行くのはなんだか非常に面倒で、結局いまいち一体感はないままになってしまいました。用語集を作る前と比べたら気分的にものすごくスッキリしてはいるのですが、実用的にはもう一歩というところです。
　そういうわけで、記事と記事あるいは用語集とのリンクを大した手間なく実現できる仕組みを作ろう、と思ってこのサイトができました。

　また、ブログに書くほどじゃないけどSNSに投稿するのもなんか違う、みたいな短めの記述を置く場所として「のらてつの茶の間」と名付けたサイトを以前作りました[^2]。
　本当にめちゃくちゃ頑張って作って、ページ間リンクの仕組みは個人的には会心の出来だったのですが、如何せん更新作業が面倒で、とても「ブログに書くほどじゃない」程度の軽さの記述をほいほい公開できる感じではありませんでした。そもそも、そういう軽い記述と「縦横無尽のネットワーク」みたいな仕組みの相性が良くなくて、自分で作ったものを自分が活かせないという状態に陥ってしまいました。
　その後、反省を踏まえて簡易版を作ってもみたのですが、自作サイトという形態である以上更新作業の面倒臭さの低減には限度があり、手間が「ブログに書くほどじゃない」程度のものを書けるレベルより下回らなかったので、結局いくらもしないうちにやめてしまいました。
　最終的に掲示板サービスをひとりで使うというところに至りました[^3]。これは全然不満はなく面倒でもないのですが、なんとなく書くタイミングを掴めないというか存在を忘れがちというかで、そんなに活発には使っていません。Podcastや記事の感想を書くのには重宝しています。
　で、後述しますが、今回のサイトは投稿内容のメンテナンスが非常に簡単になる仕組みを作ったので、今度こそと思って「茶の間」の欄を設けています。超単純なブログ風のビューになっています。記事更新のタイミングで一緒にまとめて更新できるので、茶の間の記述のためにわざわざ更新作業をするということをしなくてよくなりました。

Dynalistをエディタにする

　訪問者には特に関わりのないことですが、このサイトの肝心なところは、Dynalistをエディタにしていることです。
　記事も用語集も茶の間もAboutも全てDynalist上に書いています。それをサーバーサイドでDynalist APIを使って取得して諸々加工し、データとして取り扱える形にしてからHTMLに読み込んでいます。
　この仕組みは、先月突如としてDynalistに目覚めて（？）活用法を怒涛のように思いついたことにより実現しました。ノート機能、タグ機能、ノードリンク機能をフル活用しています。
　Dynalistでやることの利点は、過去の記述に手を入れることが非常に楽になることです。一般的なブログではおそらく過去記事の編集は面倒極まりないものではないかと思いますが、アウトライナーならとても簡単です。後からリンクを追加したいという時も作業は一瞬で終わります。
　また、Dynalist APIで取得したデータはその後好きなように加工できます。正規表現を駆使してHTMLにしているわけですが、例えばNoratetsu Labの記事へのリンクをこのサイト内のリンクに変換するとか、#で始まるタグを用語集へのリンクとして解釈するとか、さまざまなことをやっています。つまり、Dynalist内ではDynalist上で扱うものとして自然な書き方で書いて、それをサイト仕様にコンバートすれば、投稿先の仕様に合わせて無理をする必要がなくなるのです。
　具体的にはDeno^[2]のスクリプトで取得・加工してjsonファイルを作っておき、　GitHubの専用リポジトリにプッシュして、それをサイトのロード時に読み込む流れです。データの加工（サーバーサイド）とサイトでの実行（クライアントサイド）は完全に切り離されているので、加工にはどれだけ時間がかかっても構いません。やろうと思えばいくらでも複雑な処理ができます。

Drummerを思い出した

　Dave Winer氏が開発したアウトライナーに、Drummerというものがあります。UIが独特過ぎて本人以外がこれに慣れるのはちょっと容易でないでしょうが、搭載している機能は非常に画期的だと思います。最大の特徴は、直接ブログとして公開できることと、JavaScriptを拡張したスクリプトを使えることです。
　Drummerを知った当初は「スクリプトを使える」と言われても何をすればいいのかよくわからなかったのですが、その後二年弱が経った今、結局私はDynalistに対してブックマークレットやらChrome拡張機能やらDenoやらでスクリプトを使いまくって自分専用の機能を拡張しています。やっと意味がわかった、という心境です。
　そしてDrummerと同様に、Dynalistに書いた内容をそのままブログやサイトのコンテンツとして公開するに至りました。この形式を思いついてコードを大方書いてから、ふとDrummerのことを思い出して、そういえばあれはつまりこういうことだったのではと思いました。
　Drummerはずっと「わかりたいけどわからない」ものだったので、自分にとって良い形を追い求めた先に答えが待っていたことには感慨深いものがあります。

今後の予定

　さて、作って公開に至ったことで若干燃え尽き気味な感がありますが、やらなきゃいけないこと、やりたいことは色々あります。
　まず過去記事の引っ越し（というかDynalistへの追加）です。どう頑張っても全自動にはならないので、それなりの手間をかけて作業する必要があります。時間がかかるのを覚悟してちまちまやっていきます。
　あとはスタイルの改良です。最低限は整えましたが、細かい部分の調整や、複数のビューモードの用意を考えています。
　このサイトを自分の拠点として自分的に面白いことができたらいいなと思っています。

---

1. 表示されない、挙動がおかしい、という場合はTwitter（X）（@Foam_Crab）かBluesky（@noratetsu.bsky.social）かお問い合わせからご連絡ください。ブラウザ毎に異なる仕様に対応できていないということなので、使用しているブラウザを教えていただければ対処できるかもしれません。
   のらてつの茶の間とは
   ひとり掲示板で自由に呟く ↩︎

2. 私はDenoを大変気に入っているのでDenoを使っていますが、もちろんその前身のNode.jsでも、あるいはPythonでもいいはずです。他のサーバーサイド言語のことはわかりませんが、おそらく多様な手段があるでしょう。 ↩︎

　用語集というのは先日書いた（Noratetsu Lab Dict.（記事リンク））、Scrapboxの公開プロジェクトのことです。

• Noratetsu Lab Dict.（Scrapboxへのリンク）

　このブログに登場する名詞・概念の類を「あれ」と指せるように作っているものです。ブログの記事は「あれ」を単位として書いていないため、「前にも書きましたが」と言って記事をリンクとして貼ってもわかりにくい、という問題の解消が目的です。読み手のためという気持ちもありますが、自分がブログを書く際の不便をなくしてすいすい進みたいということの方が重要かもしれません。

　今のところ90ページ弱作成していますが、ただ並んでいると雑然とし過ぎていて不親切な感じがするので索引ページを作ることにしました。

• 索引

　ページとページの間の繋がりはScrapboxの得意なリンク機能で示すとして、「つまるところ何があるのか」を可視化するにはやはり書籍にあるような索引が必要だなと。
　何より自分自身が「つまるところ何があるのか」をわかっていなかったので、索引を作る過程で随分認識が整理されました。どういう切り口で整理して索引にすればいいのかも自明ではありませんでした。整理する過程はいわゆるアウトライン・プロセッシングだったのだろうと思います。

　あとCSSをちょっと整備しました。このブログの付属品として存在しているものなので、なるべくデザインが近い方が良いだろうと。元々使っていた公開プロジェクトのNoratetsu's Room（のらてつ研究所）のようには細々とこだわってはいませんが、このくらいで十分だろうという感じです。
　索引的なページはそのNoratetsu's Roomでも作ろうとしたのですが、その時はあまり有意義には感じませんでした。多分、ページの単位が名詞ではなかったからだと思います。
　

　ごく細かい部分ですがいくつか修正を加えました。

1. 上部のリンク集の内容を変更
2. 上部のリンク集をクリック時に新規タブを開くように修正
3. 記事ページの下部に前後の記事へのリンクを表示

　リンク集には各投稿先へのリンクを並べていましたが、先日ホームページ的なものを作ったので（Noratetsu's page）、それを「マイページ」としてそこから各地に飛べるようにしてリンク欄は整理しました。
　リンク集クリック時の挙動は変え方がわかっていなかったのでそのままになっていたのですが、久々にHTMLのカスタマイズ画面を見たら普通に「ここを変えればいいな」とわかったので変更しました。（BloggerのHTMLは見慣れない記法が多くて初学者にはちょっと難易度が高い…。）
　前後の記事へのリンクはなぜか非表示にしていたので復活させました。なぜ非表示にしていたのか。