20年ほど前、2006年4月1日から公開しているweb本棚がある。

ブログブームがひと段落して、mixiなどのSNSが話題になって、次はSNSですよという頃だった。

既読/未読がわかって、本をダブって買わないために、という本棚を作ってたところで、それなら本棚の共有サイトを作ってサービス公開してみようというのが始まり。

『趣味は読書2』

図書館で本を借りて図書カードを見て
「あれ？あのコもこれ読んだのかぁ」とか「おっあいつこんなの読むんだ」と、ニマニマしたり
ひとんちに呼ばれたら、まず本棚を覗いて
「これ、わたしも読んだよ」と言いたくなったり
図書館とか本屋で、どの棚の前に立っているかで、そのひとの属性がわかって、うれしかったり
なんだか「ありきたり」な趣味なので履歴書にも書けない気がしたり
本を読んでも難しいことを考えたり感想文は面倒くさかったり
ヲタクだと思われそうで嫌だったり

でもって、だけど本好きとか本読みですが、なにか？

というようなことを、思ったことはありませんか？ ぼくは、あります。なので、そんな本棚のようなサイトを作ってみました。

たぶん、WEB本棚サービスとしては早い方だったと思う。500人弱のユーザーのかたの登録で、アクティブなユーザーさんは20人弱ほど。

最初は自宅のPCでサーバーを立てて公開して、311の震災をきっかけにレンタルサーバーに引越し。

現在もまだ稼動中なんだけど、新規登録を中止して、いま利用してるかただけの運用になっている。

ただ、わたしの還暦を過ぎた年齢的にもうそんなに長く続けられない。

んなこんなで、レンタルサーバーの契約が切れるタイミングでサービス終了することにした。

利用しているユーザーさん向けにサービス終了の告知とバックアップのお願いを表示。

とはいえ、せっかく登録・利用してもらってる本棚だし、バックアップではなくて本棚の復元ができるようにスクリプトを改修した。

ローカルPCでやるにはapacheやperlが必要だったり、web版(レンタルサーバー)だと有料だろうし、ハードルが高くなってしまったけど、復元手段を用意できたので案内と手順書も告知した。

どのぐらいのユーザーさんが使ってくれるか、難しいところだけど、これでひと安心。けっこう気になってたんだよね。

もともと、ユーザーさんの行動を見ると、本棚にアクセスして、登録したら離脱、というのが90%以上。

ほかのユーザーさんの本棚を見にいくとかお気に入りに登録するという「交流部分」はほぼほぼ使われてなかった。

上記したように、もともと「未読/既読」の確認のための本棚というのがスタート。

電子書籍なんかだと「購入履歴」が残るので、当初の役割がなくなってわたし自身があまり使わなくなっていた。

だいたい、老眼が酷くなってきて文字を読むのがつらくて読書量が激減してるんだけど。

とはいえ、シングル利用向けに作り直してみたら面白いんで、また使ってみようかと。

本棚なんて個人情報をネットで晒すのもどうなのと思われそうだけど、好きな本や映画のタイトルを並べて自己紹介がわり、ということもあるだろうし。

閲覧するだけならログイン不要の本棚ということにした。

『web本棚』

↑わたしの本棚…ほんとろくに読んでない(登録してない本もあるけど)

この際、せっかくだし「老眼鏡」を作ろう。

ちなみに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

2026年あけましておめでとうございます。

もう毎年のこと、今年もやっぱりだし、さらに健康でありますように!

毎年初詣でお参りする地元の神社で、今年もお願い二礼二拍手一礼

(昔はこんな作法はなかったということらしいけど、気持ちの問題気持ち押しつけでいいんだ、こういうのは)

健康でありますように

健康でありますように

健康でありますように

ひたすらこの一点

昨日の「2025年ふりかえり」に書いたように、我が家の去年は健康面で大ピンチだった。

ほんとうに何はなくとも「健康でありますように」

今年は65歳。

老齢年金と厚生年金の満額需給。

…て、これだけで食っていけないので、在宅仕事も継続できますように、だ。

健康でありさえすれば、仕事も＝生活もどうにかなるしね。

皆さんにとっても、今年2026年、健康で良い年でありますように！

今年はいろいろあった。

家人の手術入院が一番大きかった。

幸い、手術も無事済んで入院も予定通り。

これには正直かなりびびった…本人はもっとびびってた。あたりまえ。手術決定〜手術〜入院中、いろいろ考えさせられた。

ほんと、つくづくしみじみ「健康第一」を実感した一年だったなあ。

【生活・仕事】

今年64歳になって「特別支給老齢年金」の需給が始まった。65歳からの満額ではないけど安定収入だ。40年以上働いて保険料を支払い続けてきて、今度は受けとる側。

「年金請求手続きに行ってきた」

もちろんこれだけで食っていけるわけもない。

でも、これでライスワークを辞めることができたのは本当に助かった。

今年3月で契約を終了。実質2月でシフト仕事から足を洗った。

「手取り金額」も減ってきていて、このぐらいなら年金で補填になるかな、と。

そもそも、仕事自体、IT軽作業で自分のスキルアップになるものでないし、なんらかの知見・経験に繋がるようなものでなくて、食うための仕事と割り切ってた。

ただ、たかが10人ぐらいのチームだというのに、ヒエラルキーにしがみつく会社ごっこ大好きの猿山がストレスでしかなかった。

ありがたいことに、電子書籍制作の在宅仕事は継続中。

こっちは、もともと仕事も面白いし、ひとの入力が相手ということもあって、毎回イレギュラーが発生したりその対応でスクリプトを書いてたりで充実感もある。

年金と在宅仕事でどうにか食えるぐらいはなんとかなった一年だった。

今年はまだ社会保険などライスワークでまかなえてたところもあるけど、来年になると全部負担になるんで、どうなることやら、というところかな。

ネットの方は相変わらず、この通り。

SNSでは今年2025年は今日今時点で

→投稿日数365日/投稿数2929回/一日平均8.0回

と入り浸り状態。

「ところてん」

ここ、ひまつぶし雑記帖はこのエントリで今年40件め。

mac miniやノパソに linux Mintをインストールして復活させた記事が、アクセスログを見てみたらちょっとバズってた。

「10年以上前のMac miniをlinuxで復活」

「元WINDOWS10のノパソにlinux mint」

ホームページ「On Golden Pond」

デジカメ日記を毎月更新。

ActivityPub実装記事を追加。

ヨタ小話を追加。

と、そこそこちゃんと更新できてた。

シフト仕事を辞めてからリアルで他人との関わりがまったくない。話し相手は家人ぐらい。

ストレスのない生活はいいんだけど、さすがにこれってボケるのに50cmぐらいまで来てるんじゃないか疑惑も。

それもあって、ネットに入り浸りなのかもしれんなあ。

【健康】

家人が大変だったんだけど、わたしは3月に頚椎の異常と肋骨の骨折が判明。

背中に激痛が走るし、なんか姿勢の都合でビキっと痛むし内臓の問題かと思ったら骨の問題だった。

どちらも原因不明で、どちらも治療は特になく自然治癒待ち。

…結局なんだったんだろう、だなあ。

年初はデジカメを持って毎日ウォーキングで1万歩だったのに、夏の暑さに負けて4000歩程度になり、秋になったらと思ってたら秋が短かくていきなり冬の寒さ。

部屋で踏み台昇降をちょっとやってみたものの、これは飽きる。続かない。

身体を動かすことを考えないと、歳も歳だし、かなりまずい。

【映画館で観た映画】

15戦 12勝2敗1分

『羅小黒戦記2』

『九龍城砦 トワイライト・ウォリアーズ』

この2本が問答無用のツートップ。

あと、オススメしにくいけど

『アンデッド』

は、観たひとと答え合わせをしたくなる映画だったなぁ。

・以下、今年観た順番

お坊さまと鉄砲

ビーキーパー 養蜂家

トワイライト・ウォリアーズ

アンデッド

ザ ルーム ネクスト ドア

鹿の國

教皇選挙

ミッションインポッシブル ファイナル レコニング

鬼滅の刃 無限城編 第1章

スーパーマン

バレリーナ

プレデター バッドランド

羅小黒戦記2

KILL 超覚醒

悪魔祓い株式会社

以上、老人特有。

無駄に長くてとりとめもない「2025年ふりかえり」記事となりました。

来年2026年、健康で良い年でありますように!

タイトル通り、perlと長いつきあいになったなあ、というのが今回のエントリ。

還暦過ぎの爺さんの無駄に長いだけのネタですみません。

シンボリルドルフのダービーから競馬を始めた。1984年がわたしの競馬元年。

1991年にJRA PAT、馬券をパソコン通信で購入できるというので申し込み、たぶん2回めの募集で滑り込み、モデムやら回線、銀行口座やら揃えて、その延長でPC-VANに登録してパソコン通信を始めた。

すべては競馬ありきだった。

どっぷり競馬、馬券にハマって当時PC-VANの競馬SIGのひとたちと競馬データを分担して収集加工整形するようになった。

この競馬データいじりが、perl歴の始まりとなる。だいたい1990年代はパソコンをいじり倒してたと思う。

当時の仕事(エロ本エロ漫画編集)にはパソコンなんて1mmも関係がないし、1円にもならないことにほとんどの時間を使っていて、そんなことして何になるの？と言われると謝るしかない。

そもそも、競馬データを集めて解析分析したところで馬券には繋がらない。競馬に限らず、ギャンブルの本質は「気合と根性」だということがわかった。自分にどれだけのものを賭けられるか、その快感がギャンブルの麻薬的魅力。

最初はMS-DOSでawkを使っていて、次にjperlを使うようになって現在に至る…なので、30年ぐらいperlを使ってることになる。

この時やってたことが30年以上経ったいまになって使えるんだから、何が役にたつかなんて、わからないものだ。

perlを使うために

・MS-DOSではメモリも足りず、PANIXやFreeBSDといったPC-UNIXを使い

・perlはCGIに使われることもあってWEB(ホームページ)を作るようになり

競馬から離れたところでperlを使うようにもなっていた。

unixを構築したり、CGIを使うようになると、webやデータベース、メールサーバーなどのサーバー類も構築するようになった。

FreeBSD、apache、postgresql、mysql、sqlite、sendmailなどなど、どれも独学独習の素人芸。

IT業界未経験、ただの元エロ本編集という私立文系一本道の穀潰しでもそれっぽい仕事にありつくことができて、どうにか食えるようになってるのはperlのおかげだ。

perlとエロ本編集時代の知識でepub3電子書籍の制作もできてるし。

21世紀のいま、perlは終わった言語という扱いらしい。

いまどきのrubyやpython、GOなんかは精力的に開発されていて、バージョンアップ、アップグレードも頻繁で改善されている。その点perlは音沙汰もない。ほとんどのunix系OSにはデフォルトで入ってるんだけどね。

でも、今も昔も変わらない、枯れた言語だからこそわたしは助かってる。

どのIT現場でも30年前の知識が通用するわけだから。perlひとつでどうにかしてきた。

ほかの言語だとアップグレードについていくのが大変で投げてたと思う。

いやいや、perlがいま何か貢献してるわけ？とか言われるとわからないし、時代の進歩にあんまり貢献してないと思う。

けど、わたし個人、還暦過ぎ爺さんにはとても役に立ってくれてることは確か。それはそれでいいんじゃないのかなあ。

爺さんが説教くさいことをひとつだけ言うとしたら

コスパとかタイパとか効率などというのは、その時じゃわからない、いつ何が身を助けることになるかわからない。だったら好きなことを一生懸命やった方が面白いんじゃないかなあ、ということかな

ActivityPubの投稿を削除するには2つ必要で。

・自分んち、ローカルは

→データベースから該当の投稿を削除する。

・他所んち、リモートには

→「Delete」のActivityをリクエストする。

今回のネタはこの2つ。

1)なんでautoincrementを設定してなかったんだ!？

2)Mastodon系とMisskey系で削除したNoteのIDの扱いが違っていた？

この投稿のうち、真ん中の2つ「6453」と「6454」は一度削除後に再投稿したもの

・一度データベースから削除

・DeleteのActivityをリモートにリクエスト

・削除されていることを確認して

・削除後に新たに別の内容を投稿したもの

ローカルから消すために、データベースからの削除はスグできる。

リモートには、対象の投稿はもう「墓石」です、というのを「Delete」のActivityに入れてリクエストする。

{
  "id":"https://tokoroten.doncha.net/t2aki/items/03881-20250208"，
  "url":"https://tokoroten.doncha.net/t2aki/items/03881-20250208"，
  "type":"Tombstone"
}

「投稿を削除する::On Golden Pond」

https://www.doncha.net/activitypub/activitypub007.html

お相手は削除のリクエストが飛んできたのを見て、対象のNoteは墓の下になったということで、タイムラインからも削除する。

そのIDはもう使えない。

削除後に新しく別のものを投稿すると

データベース的には、primarykeyにautoincrementを設定してないもんだから、IDの最大値を使う。

つまり、一度使用した・削除されたIDをまた使うことがある(IDの使い回しなどあってはいけない自業自得案件)

削除したIDを使い回して新たに投稿

mastodon.social

misskey.io

そもそも、IDの使い回しなどあってはいけない、というのが大前提なので、わたしのポカなんだけど。

mastodonは削除IDの復活はない、misskeyは削除IDを墓の下から復活する。

同じIDの使い回しというと「Update」(投稿の編集更新)があるけど、これもサーバーによって対応がビミョーに違ってた、かなあ。

IDの使い回しなどあってはなりません(教訓

SQLiteはAlterなんちゃらでautoincrementを後付けできない。

改めてテーブルを作って、そこに既存データをコピーすることになる…ので、いろいろ危険だなあ。これは「運用でカバー」という腐った対応にしておこう。そのためのメモだ。

[12/10 20:30:37] 追記

言い訳をしておくと。

mastodonの仕様は把握していた。miskkeyが意外だった。

autoincrementをつけるかどうかは、データベースを作る時にちょっと迷った。

投稿作成フローで、うちはまず「下書き」状態でデータベースに登録。この時点でIDがふられる。下書きを確認した後、問題がなさそうだったらリモートに配送する。

ということは、実際に配送に至らなかった投稿でもIDを消費してしまう。これを嫌ってautoincrementを見送ったという経緯。配送IDとか別建てにしておけば良かったんだろうけど…手抜きしちゃったなあ。