オレオレMarkdown
わたしはMarkdownなんちゃらが大嫌い。
そもそも、Markdown記法など、みっともないし綺麗じゃない。宗教上の理由とか生理的嫌悪と同じ。異論は受けつけない。
というのが今回のエントリ。
Markdownという記法で記述されたものはHTMLに変換される…え？ だったら最初っからHTMLで書けよ、だ。
シンプルな記号で文章構造（見出し、リスト、強調など）を簡単に表現でき、特別なソフトなしで読み書き可能で、HTMLへの変換も容易なため、議事録、ブログ、仕様書作成など幅広い用途で生産性が向上することです。
ということらしい。
嘘をついちゃいけない。Markdownを覚える学習コストもHTMLを覚える学習コストも大きな差はない。
HTMLは30年以上前に完成された記述方法で今でも使える。これが原点で原典。
仕様やタグが追加されたりしながらも、記述方法そのものは変わらない。
それに対して、MarkdownはＨＴＭＬの被せものなので、その書きかたに、いつどんな変更が入るかわからない。
どこかのプラットフォームの都合で使いものにならなくなることが十分考えられる。つまり、今、Markdownに学習コストをかけたところで無駄。
だいたい、テキストを書いていて半角記号が文書構造の一部を指定することになるなんて、見た目からして気持ち悪くないか？
なにその意味不明な「#」「**」「-」
「えぇ…っと、ここでこの半角記号書いちゃっても大丈夫なんだっけ」だよね。
文章、テキストを書いていて余計な気をつかう必要があるってどゆこと？
その点HTMLのタグは「<タグ開始>」テキスト「</タグ終了>」という記述で、タグに記入されている半角英数字は文書指示ですよ、というのが明確。
今日の予定
最優先は 特売の豚こま 忘れないように!
#今日の予定
最優先は **特売の豚こま** 忘れないように!
<h1>今日の予定</h1>
最優先は <strong>特売の豚こま</strong> 忘れないように!
文章、テキストを書いてる時は「書いている内容」に集中したいし、集中できるようになっていてしかるべき。
文書の指定なんて後から入れればいいだけの話だ。
見た目についても、Markdownを使いこなしてレイアウトデザインも凝った表現ができたとして、それはそれでどうなんだ？
そんなに方眼紙エクセルが好きか？
レイアウトデザインで多彩な表現をしたいならHTMLとCSSを使うべき。
Markdownで書かれたテキストはそのままテキストとしても見える/読める/使える、というメリットがあるらしい。
日本語の文章で？ それはない。くり返しになるけど、書いてる時の混乱と同じ。
読む時も「なにその「#」とか「**」とか？ タイプミス？ 誤植？ 校正漏れ？」にしか見えないから使えない。
みっともないと思わないんだろか。
本文の余計なものを削除する場合。
HTMLのタグなら簡単なのに、Markdownの記号は本文中に紛れこむから面倒なだけ。
書く時も邪魔なら、読む時も邪魔なのがMarkdownというしかない。
↓ Markdownの問題点がわかりやすい
日本語でのマークアップ記法としては「青空文庫記法」が1998年ぐらいからあって、小説などの日本語テキストを書くには、たぶんこれが最強。
https://www.aozora.gr.jp/aozora-manual/index-input.html
日本語の文章に混じりこんでいて「注釈」＝意味として成立していて読める。Markdownの半角記号類より違和感も少ない。
てことで？ このブログ『ひまつぶし雑記帖』で、入力されたテキストを適当に変換するオレオレMarkdown。
入力されたHTMLタグは素通し。
(フォームデータの入力経路にちょっとした振り分けを仕込んでいて、振り分けられた側の入力データは洗浄してる。そもそもエントリ入力はログイン状態が前提なのでセキュティ的に特に問題はない)
ルールは簡単で
「入力されたテキストは一行ごと(改行ごと)に「pタグ」で包まれる」
だけ。
このルールを適用されると困るものは一時的に退避して復元する。
素通しで入力されるHTMLタグなんかもこの対象として扱う。
$to_hexでタグ文字列を16進数に変換して
$to_strで元のタグ文字列に戻す
my $to_hex = sub{ my $s = shift;
return unpack("h*", Encode::encode('utf8'， $s));};
my $to_str = sub{ my $s = shift;
return Encode::decode('utf8', pack("h*"， $s));};タグを抽出して退避
$flg->{'html-tag'} = ( $body =~ s!<([^>\p{Han}\p{Hiragana}\p{Katakana}]+)>!sprintf(qq{_LT_%s_GT_},$to_hex->($1))!eg );退避されたタグを抽出して復元
if( $flg->{'html-tag'} ){
$body =~ s!_LT_([0-9a-f]+)_GT_!sprintf(qq{<%s>},$to_str->($1))!eg;
}最優先は <strong>特売の豚こま</strong> 忘れないように!
↓タグを退避 ↑タグを復元
最優先は _LT_374727f6e676_GT_特売の豚こま_LT_f2374727f6e676_GT_ 忘れないように!
結局HTMLで書くのが早いし確実。
Markdownで解決/実現できない表示についての対処方法が「生のHTMLを書く」となっているのは何の冗談なんだか。
まずHTMLありき。Markdownが滅んでもHTMLが滅ぶことはない。
とはいえ。
マークアップがどーしたとか言ったところで、肝心の文章がつまらないんじゃしょうがないですね。すみません。
HTTP Signatureの署名対象文字列
2023年にActivityPubを自作実装した時に、うまく意図通りにいかなくて悶絶したのがHTTP Signatureの作成と認証確認。
検索しまくって何度も何度も試行錯誤した。
RSAというかCryptは今もよくわからないまま。
「Crypt::Perl - Cryptography in pure Perl」
↑META::CPANで公開されているモジュールをありがたく使わせてもらっている。
「HTTP Signatureをlolipopレンタルサーバーで作成」 にも書いたけど、このモジュールはpure perl、すべてperlだけで書かれている。
perlを使えるサーバーだったらどこでも、誰でもインストールして使えるのが素晴しい。
phpやruby、pythonを使えるサーバーも増えてきてるとはいえ、たぶんまだ全部のサーバー、特にレンタルサーバーで使えるとは限らない。
だけど、perlが使えないサーバーなど存在しない、はず。
で、ここからが今回のエントリ…本題に入るまでが長いのは老人特有の症状。
・HTTPヘッダに署名をつけてリクエストをする必要があるのはわかった。
・署名するためのモジュールも使い方はわかった。
わからなかったのが「んじゃそれって、いったい何を対象に署名するの？」というところ。
結局、HTTPヘッダなど、環境変数で取れるもので署名の対象を作るんだけど、今度はそれをどんな形で検証生成のモジュールに渡せばいいのかがわからない。
具体例を探して右往左往。
必要とされる環境変数の「キー」と「値」を「コロンと半角空白」で繋いだ文字列にして集めて、その文字列を最後に「改行」で繋いだ文字列にしたものが、署名の対象となる。
署名の生成認証は対象となる文字がひとつでも違ってたら通らない。
厳密厳格なのが当たり前。
余計な空白やダブルクオート、セミコロンなんかが入ってることに気づかない自分の雑な性格を呪う日々だった。
なもんで、あまり触りたくない、のが本音。
web本棚をActivityPub対応した時に、このSignatureまわりをすっかり忘れてたので復習。
具体的なコードはホームページに掲載した。
「HTTP Signatureの解析::On Golden Pond」
[更新]2026-02-01 09:03:21
web本棚のActivityPub対応
web本棚のネタが続いてます。今回はweb本棚のActivityPub対応ネタ。
フェディバースからアカウントとして認識されて、フェディバースに投稿できるようにした。
以前、ツイッターだった頃、APIがまだ使えた頃、web本棚をツイッター連携対応させていた。
web本棚アカウントにタイトルや著者名をツイートすると、本棚を検索して結果を返信ツイートする、というもの。
web本棚はちゃんとしたスマホ対応をしてない。本の重複購入を避けるため、というのが一番の目的で、街の本屋さんをぶらぶら眺めていて、ツイッターに検索を投げて本を確認する、というのが思った以上に便利だった。
てことで、ツイッターでやってたことと同じことをActivityPubに対応させてフェディバースでもできるようにした。
まずはフェディバースからアカウントとして認識させる。
・nodeinfo
・nodeinfo/2.1
・host-meta
・webfinger
・アカウント情報のJSON
以上5つのファイルを静的に作成。アクセスされた時にmimetypeのヘッダを付与する必要があるので、perlで読みこんで返すことにした。
すでに稼働中のおひとり様AcitvityPubで使ってるファイルをちょっと編集して配置するだけなのでそんなに大変でもなかった。
どっちかというとプロフィール画像とカバー画像を選ぶのに2時間以上かかってる…て、そんなものだろう。
スクリーンショットはmastodon.socialでweb本棚のアカウント「@librarian@bookshelf.doncha.net」(司書)を検索して表示したもの。
このアカウントは自分の本棚を検索してその結果を返すのが役割。自分の本棚専門、自分専属の司書さんみたいなものだ。
なので、ローカルのタイムラインなども不要だし、投稿内容を保持する必要もない。フォローもフォロワーもない。
フェディバースを経由すると言っても、本棚にDMをリクエストするだけ、リクエストを受けとったら本棚を検索して結果をDMで返すだけで、ほかのサーバーに余計な手間・負荷もかけない。
フェディバースを利用する意味があるのか、ということかもしれないけど。
HTTP Signatureで署名してActivityを投げて、そのActivityにいちいち意味があって、という「仕組み」が用意されているのがありがたい。ゼロから考えてなにかを作るのはやっぱしんどい。せっかくよくできた仕組みがあるんだから乗らない手はない、ということ。
↑実際に司書さんにDMをリクエストして、返信のDMをもらったところ
おひとり様のAcitivityPubとは違って、実装も考えるところが少なくて済んだ。
通信する相手が自分だけなんだから当たり前。がっつりいろんなところを省いた。botなんかもこんな感じで作れるんだろなあ。
老眼鏡も作ったことだし、今回改めて本棚の体裁も整ったし、また紙の本を読もう。
[2026/01/10 08:01:33] 追記
フェディバースにアカウントとして認識されると、
「新入りがおるみたいやな、情報を送ったる」
と、リクエストが飛んでくるようになる(actorのDeleteなど)
web本棚はSNS的な利用を考えていない、わたし専属。
なので、わたし以外からのリクエスト(POST)に対しては404(ここにはいません)を返すようにした。
web本棚のソースコード公開
今まで、スクリプトのソースコードを晒すことはしてなかった。
いや、ぶっちゃけ、自分で見ても酷いありさまで、とてもひと様に見せるようなシロモノじゃないから。
そんなものを公開したところで、誰のためにもならない・誰の役にも立たない。
…ということなんだけど。
還暦も過ぎるといろいろ終活を考えなきゃいけない。
先日のエントリ 「web本棚」 でも終活の一環でサービス終了ということを書いていて、ちょっと考え直した。
書き散らかしてきたスクリプトを晒したところで誰のためにもならないけど
「晒すことで自分のやってきたことを自分でふりかえることになる」
のは、自分のためになる。単純に面白い。
ということでちょっとずつ晒してみようかとホームページに新コーナーを作った。
まずはweb本棚のソースコードを公開
「web本棚のソースコード::On Golden Pond」
もう20年ほど前に作って、改築増築改修をしてきたもの。
SQLもまだ覚えたてみたいな時で、今だったらjoinしてgroupingしてとかSQLだけで済ませられるようなことも、ひとつずつ抽出して、抽出した結果をperlで処理してる。
なかなか恥しいシロモノなんだけど、怪我の功名というかSQLが単純なので処理の切り分けがperlのところで済むので簡単に改修できる。
とはいえ問題がjavascriptとスタイルシート。
javascriptはjQueryなんか使っててそのままだし、スタイルシートがjQueryべったりで、スマホ対応が無理。これは諦めた。
・本棚を眺めてるというのにページ遷移なんかで読みこみが入るとうっとーしーからアクションを起こしてもその場から極力動かずに済むように
・没頭してると時間を忘れそうだから時計表示は必須だろうし
などなど、どうしても(当時としては)jQueryが必要だったんだよなあ。失敗だった。
ソースコードを公開するなら、今どきなら、プログラマ御用達のgithubやcodebergを使うんだろうけど、わたしはただの素人でプログラマではない。
それに不具合やリクエストが飛んできても対応できない…というか、その気もない。
文字通り、素人のクソコードを本職のプログラマが利用するようなサイトに掲載する度胸もないしね。
なので、自分のホームページでそっと公開することにした。
自分のホームページなら、何をするにしてもすべて自分の管理下、ほかの誰かに迷惑をかけることもないという気楽さもあるしね。
[更新]2026-02-02 13:33:28
web本棚
20年ほど前、2006年4月1日から公開しているweb本棚がある。
ブログブームがひと段落して、mixiなどのSNSが話題になって、次はSNSですよという頃だった。
既読/未読がわかって、本をダブって買わないために、という本棚を作ってたところで、それなら本棚の共有サイトを作ってサービス公開してみようというのが始まり。
『趣味は読書2』
図書館で本を借りて図書カードを見て
「あれ？あのコもこれ読んだのかぁ」とか「おっあいつこんなの読むんだ」と、ニマニマしたり
ひとんちに呼ばれたら、まず本棚を覗いて
「これ、わたしも読んだよ」と言いたくなったり
図書館とか本屋で、どの棚の前に立っているかで、そのひとの属性がわかって、うれしかったり
なんだか「ありきたり」な趣味なので履歴書にも書けない気がしたり
本を読んでも難しいことを考えたり感想文は面倒くさかったり
ヲタクだと思われそうで嫌だったり
でもって、だけど本好きとか本読みですが、なにか？
というようなことを、思ったことはありませんか？ ぼくは、あります。なので、そんな本棚のようなサイトを作ってみました。
たぶん、WEB本棚サービスとしては早い方だったと思う。500人弱のユーザーのかたの登録で、アクティブなユーザーさんは20人弱ほど。
最初は自宅のPCでサーバーを立てて公開して、311の震災をきっかけにレンタルサーバーに引越し。
現在もまだ稼動中なんだけど、新規登録を中止して、いま利用してるかただけの運用になっている。
ただ、わたしの還暦を過ぎた年齢的にもうそんなに長く続けられない。
んなこんなで、レンタルサーバーの契約が切れるタイミングでサービス終了することにした。
利用しているユーザーさん向けにサービス終了の告知とバックアップのお願いを表示。
とはいえ、せっかく登録・利用してもらってる本棚だし、バックアップではなくて本棚の復元ができるようにスクリプトを改修した。
ローカルPCでやるにはapacheやperlが必要だったり、web版(レンタルサーバー)だと有料だろうし、ハードルが高くなってしまったけど、復元手段を用意できたので案内と手順書も告知した。
どのぐらいのユーザーさんが使ってくれるか、難しいところだけど、これでひと安心。けっこう気になってたんだよね。
もともと、ユーザーさんの行動を見ると、本棚にアクセスして、登録したら離脱、というのが90%以上。
ほかのユーザーさんの本棚を見にいくとかお気に入りに登録するという「交流部分」はほぼほぼ使われてなかった。
上記したように、もともと「未読/既読」の確認のための本棚というのがスタート。
電子書籍なんかだと「購入履歴」が残るので、当初の役割がなくなってわたし自身があまり使わなくなっていた。
だいたい、老眼が酷くなってきて文字を読むのがつらくて読書量が激減してるんだけど。
とはいえ、シングル利用向けに作り直してみたら面白いんで、また使ってみようかと。
本棚なんて個人情報をネットで晒すのもどうなのと思われそうだけど、好きな本や映画のタイトルを並べて自己紹介がわり、ということもあるだろうし。
閲覧するだけならログイン不要の本棚ということにした。
↑わたしの本棚…ほんとろくに読んでない(登録してない本もあるけど)
この際、せっかくだし「老眼鏡」を作ろう。
ちなみにweb版のスクリプト一式はこちら
https://bookshelf.doncha.net/arc/bookshelf.zip
ファイル、ディレクトリ構造そのまま。perlの実行属性を705か755にすれば動くと思います。
v1.0.1[[2026/01/05 15:57:31]]
・kindle本の登録ができなかったのを修正
・本の情報に取得できなかった場合のcache設定修正
ひとを巻き込んでサービスを公開するのはいいけど、終了させる方がいろいろ大変。
これもまた終活の一環だなあ。
[更新]2026-02-02 09:22:01