お散歩デジカメ日記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」
年金請求手続きに行ってきた
今日、初めての年金請求手続きをしてきた。
エントリにするほどではないんだけど、いつなにをやったか自分で見返すためのメモ。
地元の年金事務所。相談に行くにあたっては事前に予約が必要で、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」
ライスワークの終了
年金受給も始まることだし、ライスワーク、食うためだけの仕事を辞めた。
本作りに関わる仕事をライフワークとしてやってるけど、それだけじゃ食っていけないので食っていくためだけのライスワークも並行してやるしかなかった。
そんなこんなで、いろいろライスワークをやってきて。
データベースの基礎や考え方を勉強する機会があったり、中学高校受験やイベントについて知らなかった世界があったり、障がいのあるひとたちの環境について初めて知ったり、自分のスキルや知見に繋がる・広がることは興味もつきなくて、面白かった。
だけど。
なにが目的なんだか。手順を守ることが仕事である、みたいな仕事現場があって呆れるしかなかった。
仕事としてそういうのも「あり」なんだろうけど。
たとえば「毎日9時に花壇にジョウロで水をやること」と言われて、雨の日でも傘をさしながら花壇にジョウロで水をやるような仕事。
頭が悪いだけでただただ阿呆くさい。
今日は雨だし花壇に水をまく必要もない、ということで水をまかなかったりするのは、それを勝手に判断しちゃいけないらしい。おれさまに判断を仰げ、というくだらないヒエラルキーのサルがそこにいる。それがITの仕事というんだからなんじゃそれ、としか。
その組織内のピラミッド構造にしがみつくしかない能無しがそれなりのポジションでふんぞり返る、文字通りのサル山だった。
そんなところにいても、1mmも自分のスキルアップ、レベルアップにならない。ただ時間の無駄。
そんなライスワーク現場もあった。
体力的にも時間で身柄拘束されてチームで仕事することがストレス。
この歳で身体を壊したらもろもろ終了だし、健康第一、ストレスのない環境を自分で選択・作ることが最優先。
てことで、ライスワークはもう止め。
今後、食っていけなくなったらそれでも考えなきゃいけないだろうけど、サル山な現場だけは勘弁してもらおう。サル山の会社ごっこには虫酸が走る、ストレスでしかないからなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
今年の検診：速報
つい先日、最後の人間ドック。
以前、2020年だから4年前のMRIで脳出血が判明して、その日予定の検査はすべて打ち切り、脳内科のある病院への紹介状を出されて早く行ってくださいとなったのもここ。
…て、後で知ったんだけど、脳出血（脳梗塞）は一刻を争う事象。脳内出血が認められたら救急車。
かかりつけの先生に経緯を話したら吃驚された。
なのに、この人間ドックではできるだけ早く行ってね（まったり）だったんで、あんまり信用できない。
てのはともかく。
詳細結果は後日PDFで受け取ることになっているけど、当日、診察終了後に結果説明があっていわば【速報】というやつ。
毎年引っかかる中性脂肪はしかたがないにしても、今年初めて肝機能の数値が基準値超。γ-GTPだ。
こいつはあきらかに酒の飲み過ぎ。
若い頃なら飲めていた量が、歳食ってから飲めなくなってる、すぐ酔っ払うにも関わらず、若い頃のイメージで飲んで記憶をなくして寝こけてしまう。
脳出血既往症なもんで、本当は飲み過ぎはよろしくない。なので、昔のようにおもて、飲み屋で飲む、なんてことはしないし、おもてで飲むような時は嫁さんや身内と一緒の時だけ、と決めている(身内に甘えてごめんなさい)
基本的に飲むのはウチにいる時だけ。この油断がいけなかった。
在宅の制作仕事がここんとこエラーもなくすんなり。元データがきれいになってきていて、スクリプトもほぼほぼ完成形で効率化MAX状態。
以前だと1本仕上げるのに実機で確認、元PDFとつきあわせて確認、いったん寝かせて再度確認…などなど確認作業だけで半日〜1日潰れたのが、いまでは1本につき1時間ほど。
てことは、ウチにいる時間、仕事をしていない時間が爆増した。1日かかってたのが1時間だからそりゃそう。
ウチで飲む時間も爆増、記憶をなくして寝こけるほど飲んでしまってた。
さらに、ここ数年、夏は焼き殺されそうな暑さだし、冬がガクブルの寒さ。ポケモンGOのモチベーションも下がっていて、ウォーキングも激減。
そんなこんなで今回検診の結果だ。生活習慣を見直す必要に迫られた。
休肝日を作る。毎週月曜。
ウォーキングを再開する。1日1万歩目標（1万歩は実はやり過ぎという説もあるので要検討）
さすがに63歳だというのに今さら肝機能障害・低下はヤバいという危機感もあり、急遽このエントリ。書き起こしておかないといけない。
あとはウォーキングのモチベーションをどうするか考える、か。
ひさしぶりにトイデジでも持ち出して写真撮ったりしてみるかなあ…。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
epub3電子書籍制作作業メモ
今やってるepub3電子書籍制作仕事、というか作業に使ってるperlスクリプト類のメモ。
どのクライアントさんも、元データをいただいて、こちらでepub3ファイルに梱包するという作業。自分で原稿を集めて編集して、ということではなくて文字通り「電子書籍制作」で実態はファイル変換作業。
扱うのは、ほぼほぼ小説なのでデザインやレイアウトはシンプルなものばかり。
（以下はNDAに抵触しない、わたしの作業と使用スクリプトについて）
作業フローとしては
・事前確認
・変換作業
・事後確認
このために作って使ってるスクリプトは、元データ次第なんだけど、
事前確認に5本、変換作業に4本、事後確認に11本
だいたいこんな感じ。
元がひとの入力だし、表記表現の揺れがあったり、タイプミスもあるので、それをスクリプトでひっかけるために、確認用だけで16本のスクリプトが必要となっている。
最終的に目視するにしても、ひとの目視確認は信用できないので、スクリプトで対応できそうなものはスクリプトに任せたい…気がついたら確認用が次々と増えてきた。
もう大丈夫だろうと思っても、ひとのすることは例外処理だらけで、毎回何かある。
1)
原本がPDFの場合、pdf2textを使ってPDFとテキストを比べて確認。
PDFで見た目を調整されてる場合、元データのテキストと違いが出てしまう。違う箇所を引っ張り出して、元データを編集する必要がある。
2)
元データにスタイルが指定されている場合、どんな指定をされているのか確認。
縦中横などの漏れを防ぐためのすべてピックアップして確認をする。
3)
絵文字のチェック。
今どきはutf8なので機種依存についてはあまり気にする必要もないハズだけど、絵文字はさすがにアウト。エッセイなんかだとたまに入ってることがある。レアなケースだから目視で見落とすので、スクリプトにした。
4)
ルビのチェック。
ルビの使い方がわりとフリーダムなこともあって、これをルビにするの？というのを確認しておく。
5)
元データを変換しやすくするために、使わない部分を削除。
必要なのは本文部分で、それ以外が入ってるケースがあるのでスクリプトでカット。
その後、改ページの指定など手作業を入れて事前整形して変換用のテキストデータを作る。
6,7,8,9)
epub3ファイル群に変換する。
10)
半角文字の確認。
縦中横に指定されるべき半角文字列の確認。ついでに、感嘆符や疑問符の後ろに空白がひとつあるかないかの確認。
11)
半角縦中横のタグについての確認。
10で確認した箇所に意図通りのタグが当たってるか、あるいは意図通りタグが当たっていないことの確認。
12)
メタ情報の確認。
epub3に梱包するに当たっては書誌情報ファイルが必要。スクリプトで自動生成させてるので、その確認用
13)
全てのタグの確認。
epub3電子書籍というのはHTMLの集まり。変換スクリプトで正しくタグが当たってるか、どんなタグが当たってるか確認用。
14)
無用な空行、必要な空行の確認。
PDFとの目視確認だと見落としがちなので怪しいところをピックアップ。
15)
目次の確認。
5で改ページ指定などを手作業していて、ここでミスが入り込む可能性がある。ので、epubにした後に原本と目次があってるか確認が必要。
16)
圏点やダーシの確認。
ものによって、原本ままだったり調整が必要だったりするので、確認。
17)
変換後のルビの確認。
4でチェックしたものと差異はないかの確認
18)
変換後の目次の確認。
15とはまた別。こちらは表示用目次の確認。正しく設定されているか。
19)
句読点で終わってないのに改行されている箇所の確認。
見た目の改行とデータ的の改行で違う可能性がある。特にワードなんかが元データの場合。
20)
epubファイルからHTMLタグを削除してただのテキストデータにする。
5で作った変換直前のテキストファイルと差分を確認するため。
列挙してみるとやっぱり確認作業だらけ。確認でなにかひっかかると元データに戻って編集して変換スクリプトで変換してまた確認、というループになる。
スクリプトでやっつけてるので、機械的流れ作業に見えるけど、本（小説やエッセイ、俳句なんか）が好きで読んでなかったら見逃す見落とすケースの確認作業。それらをepub3ファイルにすり合わせるのがキモということになる。紙本と電子書籍、両方のことを知ってないとわからない、というか勘が働かないところだろう。
そこが面白いところだし、わたしが仕事をもらえてるところだと思う（思いたい）。
まだ確認すべきトラップというかご新規さんが出てくるだろうから、確認用スクリプトと目視確認作業は増えるんだろなあ。
ひとの入力は予想がつかないし手強い。
[2024/11/29 10:07:01]追記
スクリプトでもろもろ確認後
kinoppyとkindle previewerでの実際の表示、動作の確認。これが最終形態なので、ここでの目視確認の負担軽減がスクリプト類での確認作業、てことになる。
トーハクは庭園もおすすめスポットだった。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
