お散歩デジカメ日記2025年3月号
個人ホームページのお散歩デジカメ日記に月刊デジカメ徘徊老人日記3月号追加した。
今年はウォーキングを頑張るのがひとつの目標。
還暦すぎると健康第一。その健康維持とボケ防止のため。年初から3ヶ月続いていて、ウォーキングがほぼ習慣化してる。デジカメでパシャパシャ撮るものを探して歩いて、同じコースでもちょっとした発見があるので飽きない。
そうして撮りためた写真をホームページに掲載する、という成果物を得られるんで、一石二鳥。
お散歩デジカメ日記::On Golden Pond
https://www.doncha.net/toydigi.html
1月2月は撮ったものを、なんの加工もせずそのまんま。
今月、3月は縦横比こそそのままだけど、少しトリミングをしてみた。
KODAK PIXPRO FZ45はデフォルトのワイドの画角は50mm換算27mmとかなり広い。ズームすればいいんだろうけど、ぱっと撮りたい時にいちいちズームして〜とかやってられない。
そもそもウォーキングの記録、みたいなもんだしあまりこだわってもなあ、と。
とはいえ、ホームページに掲載するにあたって、写真を選んでると、ここもっと寄りたいよなあ、こっちに詰めてこっちは広がりを残したよなあ、とか欲が出てくる。
色味の調整とかフォトショでやりだすとキリがない。そもそもFZ45で写真の保存形式はjpgなのでそれをいじると劣化することになるし。
ただ、構図については、少しいじってみようと、今回はいくつかの写真でやってみた。
昔、新卒で入った底辺エロ出版社で写真集のために写真のトリミングはさんざんやってたことを思い出す。見せたいものを見せたいように見せるのも編集者の仕事、ということだったなあ。
まあ、還暦すぎの趣味、続かないと意味がないんで気楽にやっていこう。
個人ホームページ 『On Golden Pond』 はオレオレMovableTypeが生成する静的ページ。それってのは、表示速度最優先のため。
なので、1ページに表示させる写真は1枚限定。
ページ遷移してもらう＝クリックしてもらう、というのはかなりコストが高くてほとんどのひとはクリックしないもの、というのは理解してるけど、それでも、それ以上に表示速度はだいじだ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ActivityPubサーバーのバグ修正メモ
ここんとこ時間もあるので、おひとり様サーバーの機能追加やバグ修正。
忘れないようにメモしておこう。
・仏語アクサンや独語ウムラウトまじりの投稿で文字化けを起こしてJSONのdecodeで失敗していた。
JSON.pmは文字コードというかutf8フラグの扱いにクセがあって。
decode_jsonに渡すJSONはutf8フラグがついていてはいけない/事前にutf8フラグを外す必要がある。
なので、事前にEncode::is_utf8でutf8フラグの有無を調べて、utf8フラグがついてたらEncode::encode('utf8',JSON)などと、utf8フラグを外して渡してた。
アクサンやウムラウトは見た目1文字
「â」「ë」
だけど、コードポイントは２バイト使う（日本語などは3バイト）ので、スクリプトではutf8フラグをつけて扱う（検索などにそのまま使えるから）
これをEncode::is_utf8でうまく検知できてなかったっぽい…「ぽい」というのは、まだしっかり特定できてないから。
evalでdecode_jsonを括って$@でエラーを捕捉してるところ、エラーが出たらもう一度同じ処理を入れることにした。原因追求をさぼって結果オーライ、というのは昔からの得意技（技？
・お相手サーバーの生存確認を追加した。
応答の確認に時間がかかるサーバーがあった。セッション切れを起こしてしまうのは致命的。
「LWPでtimeout指定が効かない」
https://t2aki.doncha.net/?id=1731205503
↑この対応で解決したはずなのに、このtimeoutの処理が効いていないサーバーがあった。
同じ500番代なのになんでだろ…。
てことで、投稿を配送する前にお相手サーバーが応答してるかどうかの確認することにした。
lwpでリクエストを投げてもたぶん同じことだろうし、Net::Pingを使うことにした。
今のところ意図通りに捕捉できてる。
・アナウンスした時にフォロワーさん以外に通知が飛ばない。
Activityの配送先は自分のフォロワーさん。なので「自分のフォロワーさんじゃないアカウント」の投稿をAnnounce（ブースト、リポスト、リノート）したら、そのアカウントにも配送する必要がある、ということをすっかり忘れてた。
AnnounceするActivityの投稿者をフォロワーリストで確認。
フォロワーリストに入ってなかったら、配送先に追加。
細々というか、2年近く使ってるというのに、いろいろ出てくるもんだ。
けっこうなスピードで疾走感があった。楽しそうでいいよねえ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
自作ActivityPubサーバーにリプライを実装
当初からリプライを実装するつもりはなかったんだけど、今日とりあえずリプライを実装した。
どうしてリプライを実装しなかったのか。
タイムラインの投稿の返信（リプライ）ボタンをポチッとクリックして、画面の向こうのたぶん面識のないひとに安直に話しかけることの距離感があやういから（わたしの場合）
返信するケースというのは、ほとんどの場合がマウント合戦だと思っていて、
「それ、おれ/わたしも知ってるー！」とか
「おれ/わたしはもうやってきたことだ」とか
「おれ/わたしの方が詳しい/当事者だよ！」とか
そこまでの関係性のない、あかの他人に話しかける動機というのはやっぱり、親近感とか共感だけではなくて、なにかが少し混じってビミョーに違ってると思う。
なので、SNSでやらかすのはこんな局面だろうと思ってるし、わたしもやらかしの返信をしてきたこともあり、リプライは危ないから実装をしない、とActivityPubサーバーを作り始めた時点で決めていた。
なんだけど。
Mentionをいただいて返事をする時に、ウチはリプライに未対応なのでリプライ要素のないJSONを返していた。投稿に対するリプライ要素があればツリー表示となるけど、リプライ要素がないJSONだと単品のMentionとして表示されるだけ（だと思う）
お相手にしてみると「あれ？なんだっけ？これ」ということになるだろうしなあ。
てことで、リプライ要素を付与したActivity（JSON）を返すように実装した。
ただし、返信（リプライ）ボタンを表示するのはMentionをいただいた投稿限定。
ホームタイムラインに流す投稿には表示しない。（わたしの場合）やらかす危険しかないから。
昨日実装した「転送」と今日実装した「リプライ」について、別サーバーの別アカを使って確認したところ、「意図通り」反映してるっぽい。
転送もリプライも、いろいろちょっと危ういんで、様子を見てながら運用する、ということで。
昨日、今日と2日続けてActivityPubサーバーをいじっててしみじみ。
やっぱ、ActivityPubも、それを実装するperlもめっちゃ面白い！
還暦過ぎの趣味、ボケ防止の趣味としては文句のつけようがないよなあ。
通り抜けた向こう側に光がある、という絵面。定番だし、やっぱ好きだわ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
自作ActivityPubサーバーに転送を実装
Activityの転送という仕組みがあって、それはActivityPub的には必須（MUST)とされている。
ずっと未対応だったのはFORMデータ本文＝ActivityのJSONに対する署名のやりかたがわからないから。
…今もまったくわかってない。
・Activityを転送する
受け取ったActivityを、受け取ったサーバーがそのまま自分のフォロワーに配送する。
この時、もしもActivityが改ざんされていても受け取ったサーバーはわからないし、わかりようがない。とりあえず、そのまま転送するだけ。
なので、この問題を解決するのが、Activity本文について署名をする＝JSON-LD（JSON Linked Data）署名。
この署名をActivityに付与することで、Activityの改ざんなどを検知できる、ということ（らしい）
ただ、このJSON-LD（JSON LinkedData）署名は、AcitivityPub的には必須（MUST）ではない。実際、今日時点で確認したらCreateのActivityにJSON-LDの署名がついているのはMastodon系のサーバーで、ほか、Misskey系やAkkoma系のサーバーではJSON-LDの署名はついていない。
それならば。
ActivityPub的に転送はMUSTなので、JSON-LD署名は未対応のままでも実装だけはしてしまおうと（今さら
どうして転送なんてのがMUSTになっているかというと。
https://argrath.github.io/activitypub/#inbox-forwarding
注: ゴーストリプライ問題を避けるための転送
以下の節は、連合ネットワークで時々問題を引き起こす、 「ゴーストリプライ」問題を緩和するためのものである。この問題を例で示す。
Alyssa は、会議での論文の発表が上手くいったことを投稿し、 友人である Ben を含む彼女のフォロワーコレクションに送りました。Ben は祝福する内容を Alyssa のメッセージに返信し、 宛先に彼女のフォロワーコレクションを含めました。しかし、Ben は Alyssa のフォロワーコレクションの内容にアクセス出来ないので、 Ben のサーバは彼のメッセージを彼らの inbox に転送できません。次の機構がない場合、その後 Alyssa が Ben に返信すると、 彼女のフォロワーは、Ben の返信を見ることなく Alyssa が Ben に返信するのを 見ることになります。これはとても混乱します!
わたしがお相手とMentionで会話をした時に
・わたしは自分の投稿をフォロワーさんにも配送してるのでわたしのお相手への投稿は見える。
・でも、お相手からのわたしへの投稿はわたしのフォロワーさんに見えるとは限らない。
・わたしが壁に向かってなにか喋ってるようにしか見えない、ということになる。
なので、お相手からわたしへの投稿を、わたしのフォロワーさんにも見えるように転送する、ということが必要。
必要かどうかは全面的に賛成ではない、というか必須にする理由としては弱いと思ってるんだけど、仕様的にMUSTとされちゃってるからには対応せざるを得ないよなあ。
で、転送を実装しちゃったんで、転送したNoteに対するDeleteも実装。
・転送したNoteのIDをリストで保存
・Deleteが飛んできたらNoteの転送履歴を確認して転送した投稿が該当してたらDeleteを転送する
ということにした。
転送がMUSTなのは仕様で見てたけど、実装してなかったのは。
JSON-LDに対する署名のやりかたがわからない、というのが一番問題で、次に、それとはまた別レイヤーでの話もあって。
わたしは、自分の投稿がどう扱われようが、割とどうでもいいと思ってる。
だけど。ひと様の投稿については、わたしが関わることでご本人の意図しない形で扱われるのはめちゃくちゃ困るしそれは避けたい。
ActivityPubの仕様上、Delete（削除）、特にリモートサーバーでの削除が意図通りにならない。ご本人は削除したつもりでも転送された別サーバーでは残ってることがないとは言えない。
https://argrath.github.io/activitypub/#delete-activity-inbox
あるアクティビティが発信元サーバからリモートサーバに転送された後、 オブジェクトの表現をリモートをリモートで削除することを 強制する 方法は、ActivityPub プロトコルにはないということに注意すること
なもんで、ひと様のデータを転送することには抵抗があった。
ちなみに転送するNoteは
わたし宛のメンションで、宛先（「to」や「cc」）に「public」や「わたしのfollowers」が指定されているもの。
（DMなんかはもちろん除外）
何かをたった「ひとつ」実装するだけとはいえ、考える/考えなきゃいけないことがいろいろあるよなあ。
足立やっちゃ場の旧日光街道に佇む松尾芭蕉…って、こんなだったんか。初めてみた。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
年金請求手続きに行ってきた
今日、初めての年金請求手続きをしてきた。
エントリにするほどではないんだけど、いつなにをやったか自分で見返すためのメモ。
地元の年金事務所。相談に行くにあたっては事前に予約が必要で、2/7に電話相談窓口に電話して予約が取れたのが今日3/14。1ヶ月以上先の予約でびっくり。それだけ混み合ってる。
電話をしたときに年金請求申請書の記入箇所でわからないこと聞きまくってとりあえず埋めておいた。
当日、というかまさに今日、請求手続きに必要なものは
・マイナンバーカード
・振込先銀行の通帳かキャッシュカード
・雇用保険番号の記載された紙
の、３つ。
事前に調べてたら戸籍謄本が必要だとか住民票が必要だとか言われてたけど、
・本人のマイナンバーカードがある
・申請書の配偶者のマイナンバーを記入する欄が埋まっている
であれば、謄本も住民票も不要。
わからなかったのが配偶者加給だったけど、とりあえず記載しておいたらそれもOKだった。
…ていうか、相談窓口に予約を入れて来所すれば、そこで事細かく説明があって、その場で記入して完成するから杞憂だった。
ということで、満額じゃないけど64歳からの特別支給老齢年金の受給が始まることとなった。
40年以上働いていて、厚生年金、国民年金を払い続けてきたんで、今度は受け取る側になった、ということだ。
支給されるという、そこに示されてる金額、
を！すげー！40年も働いただけはあったな！と一瞬思ったんだけど、それは「月額」じゃなくて「年額」という現実。
アルバイト、パートもやってかないとなあ。
金額はともかく。
一定した収入が確保できる状況というのはいろいろありがたいもんだなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
デジカメ散歩のページを作った
3月だというのに雪でびっくり。
そういえば、ホームページの方にデジカメ散歩のページを作ったのでこちらでもお知らせ。
ウォーキングのモチベーションにと思ってデジカメを持ち歩き。パシャパシャ撮ってる。
だいたい1日1万歩を目安にして隣駅のスーパーまで歩いたり、川沿い、土手のウォーキング/サイクリングコースを歩いたり、1月からかなり歩くようになった。
写真の絵になりそうなのがないかキョロキョロしながら歩いてるので、歩く速度はまったり。
ホームページに月イチで撮った写真を公開するページを作った。
お散歩デジカメ日記::On Golden Pond
https://www.doncha.net/toydigi.html
1ページに写真1枚。日付順。
それなりに考えて
・1ページに表示するのは1枚だけ。
・写真は長辺1080pxに縮小。
と、表示が重くならないようにしたつもり。
多い日だと一日で50枚ぐらいで、0枚の日もある。写真を撮らなければならない、と義務感で撮ると続かないし、気楽手軽にウォーキングのついで、というスタンスで。
撮った写真をPCに移して、後日まとめて掲載する写真の選択とキャプションつけ。
ほぼほぼKODAKのPIXPRO FZ45で撮った写真で、噂どおり色が湿気を帯びて濃厚に見える写真もあって、ページに掲載する写真を選ぶ時間が楽しい。
撮ったままの無編集、水平垂直が取れてないものや露出オーバー/アンダーなものもあるけど、それでもそのまま掲載してる。フォトショあたりでいじり始めるとキリがないしねえ。
ウォーキングというか徘徊の記録なので、あまりそこはこだわらない。
「タ、タスケテ」と聞こえたので駆けつけたけど手遅れだった。なにかに樹に変えられてしまった人間がそこに立ち尽くしていた。
てなキャプション。こんなのを見つけるのもカメラを持ち歩いてるから。いつもの景色の中にいろんなものが潜んでる、発見があるよねえ。
還暦過ぎたらウォーキングと写真ですなー。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
