コロナワクチン接種7回目
コロナワクチン接種してきた。7回目。
コロナに罹患したタイミングと接種タイミングが重なったことがあって1回見送り。順番通り接種してたら8回目のところだ。
コロナの分類が5類になって、ワクチンは各自頑張れ、ということらしい。
行政から接種券などの送付もなく、自分たちでコロナワクチンを接種している医院を探して、地元のお医者さんで予約。保健もなくてウチの場合ひとり14600円也だった。
同じ風邪みたいな感染症のインフルエンザは、罹患すると高熱で死ぬかもと思うほど苦しいんだけど、ゾフルーザなどの特効薬がある。インフルエンザだということがわかれば、投薬から3日もあればケロッと治る病気だ。
ところが、コロナは対応する、治療薬・特効薬がない。コロナだとわかったところで治療方法がない、ということ。
これが本当に怖いんだよなあ。わたしは脳出血既往症。コロナは血管の病気だということも言われるし脳に対するダメージの話も聞いたりする。
なので、コロナはまじめに御免被りたい。
5類になったからといって死者の数は減るどころか、増えてる。
年末の忘年会シーズンで、深夜の電車は満員御礼。マスクもなしに賑やかで楽しそうなのはいいけど、コロナ、インフルエンザの感染症は怖くないのか不思議だ。
あと、びっくりしたのが（今さら
コロナのワクチン接種費用は年末調整の医療費控除に入らないんだそうだ。
棄民国家と言われてもしょうがないのでは。
chinaviキッズカメラ 画質5M
このカメラは描画に期待できない。たぶんWEBカメラの静止画レベル。
ネタ次第、被写体次第だなあ。なので、ネタを選ぶセンスが問われる…のか？
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
トイデジふたたびみたび
chinaviキッズカメラというデジタルカメラを購入した（3980円なり）
販売元のサイトを見ると3歳児ぐらいからの知育玩具のひとつという位置づけ。
てのはともかく、久しぶりにトイデジ熱、物欲に襲われてついポチってしまった。
20年ぐらい前はVQ1005というキーホルダーサイズのトイデジにハマって持ち歩いてた。今どきの高機能高性能デジカメ、デジカメもどきのスマホと違って、トイデジといわれるものはほぼほぼオモチャ。画質も悪いし画像周辺の光量が落ちるトンネル効果（効果？）が出たり、画像がレトロというか粗悪粗雑というかで、撮った本人の想像を超えた画像になったりする。それが面白かった。
今さらまたトイデジに手を出したのは。
みけさんがいなくなって、スマホのカメラロールがほとんど埋まらなくなった＝スマホのデジカメとしての役目は終わった、ということもあるのかもしれない。
今回買ったChinaviキッズカメラは、想像以上に画質が悪い、粗悪。トイデジとして買ったからいいものの、そうじゃなくてデジカメとして買ったんだったら返品案件だろうなあ。いや、値段の3980円で察しろよ、という話だけど。
ピントがどこにくるのかわからない。絞りがわからないけどたぶん開放で明るいのは苦手で白飛びするしデジタルっぽい潰れ方をする。
クセが強くて一筋縄ではいかない。
（画素数など桁違いに低いVQ1005の方がなぜかしっかり面白い絵が撮れる。画素数なんて関係ないのかもしれない）
12/17に買って4日ほど140枚ほど撮って、なんとなくクセがわかった、ような気がする。
とりあえず、ウォーキングだけじゃなくて持ち歩いて撮りまくってみよう。
chinaviキッズカメラについてはホームページの方に詳細と作例を上げた。
「chinaviキッズカメラ::トイデジ::On Golden Pond」
写真をアップしてページを作りたいような時はホームページの方が便利だな。
[12/22 12:08:59]追記
VQ1005と比べてみてなんかわかった。
たぶん、憶測だけど
・VQ1005は写真を撮るためのデジタルカメラ
・chinaviキッズカメラはwebカメラの転用
VQ1005が写真を撮るためなのに対して、キッズカメラは動画も撮れるんじゃなくて動画と同じ扱いで「写真」ではなくて「静止画」を撮ってるんじゃないか？
そりゃVQ1005の描写力に敵うわけがない。
» ローカル環境で電子書籍を作る、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」
ホームページの生存証明
更新情報を生存証明とも言ってますよね。
個人ホームページは１ページずつ「ページを作る」ことになるので、毎日なにか放流してるSNSや、月に何度か（の予定の）ブログと違って、停滞してしまう。
なもんで、SNSやブログの最新情報を取得・表示させるようにしている。
このブログ「ひまつぶし雑記帖」はRSSを配信してる。
RSSは1.0系と2.0系があるけど、モノはXMLなのでやることは
1)RSSを取得する
2)XMLを解析する
3)必要なものを表示させる
の３段階。
RSSは枯れた仕様なのでGETでXMLを取得したらXML::SimpleあたりでXMLを解析して必要なもの「タイトル/リンク/概要」を引っ張り出してHTMLに整えて表示するだけ。
SNSのおひとり様ActivityPubサーバーはRSSなど配信していない。
ActivityPubの仕様にoutboxコレクションというのがあって、これはアクターの投稿を順番に並べたもの。新着順なので、これを取得すれば更新情報として使える。
1)アカウント情報からOUTBOXのURLを探す
2)OUTBOXのJSONを取得する
3)JSONを解析する
・OUTBOXがページャーだけだったら１ページめを取得する（２に戻る）
4)必要なものを表示させる
webfingerから辿ってアクター情報（アカウント情報）の中にあるoutboxのURLにGETリクエストを投げる。mimetypeを「application/activity+json」にすればJSONが返ってくる。
JSONを解析して必要なもの「タイトル/リンク/概要（投稿を文字数でトリム）」を引っ張り出してHTMLに整えて表示する。
こちらはRSSよりもひと手間かかる、かな。
ActivityPubのoutboxはRSSと同じように更新情報に使えるけど、発想や仕組みは別もの。
RSSの場合は広く告知するためにRSSを配信してるサイトならページのどこにでもRSSを取得取得できるリンクの記載があって、RSSリーダーに登録してね、と。
outboxの方はSNSで利用するためのもので、どこにあるのかわからない。アカウント情報→プロフィールページでわかるとはいえ、それ単体であちこちにリンクがあるわけではない。
outboxを要求された時にJSONを返すのかHTMLを返すのかリクエスト次第というのもRSSとは違うところ。
outboxについては個人ホームページの 「On Golden Pond」 のActivityPubページに追加する（予定）
今さらまた「ねこあつめ」２
このゲーム、猫と過ごしたことのあるひとが開発にいるよなあ。
猫は「そこにいてくれてありがとう」なんだよーーー
» ローカル環境で電子書籍を作る、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」
SNS・ブログ・ホームページ
SNSとブログとホームページの棲み分け、というか自分的整理。
同じようなことをここに何度も書いてきてるんだけど、その都度その都度で環境も変わってるんでエントリとして残す意味は少しはあるかと。
先月、個人ホームページを改めてというか、ふたたびみたび、また作った。
これが面白い（今のところ）ので、棲み分けを意識しないとわやくちゃになりそうだ、ということでメモ。
・SNS
言葉を投げるもの。リアルタイムで言葉のキャッチボール
・ブログ
言葉を定着させるもの。言葉を蓄積されている場所。
・ホームページ
ページをひとつずつ「作って」いくもの。言葉だけじゃ足りない。
てな色分けでいいような気がする。
いま、このエントリも、思いついてなんとなくSNSに投げたものが最初。特にリアクションなど期待はしてなくて、思いついた言葉をそのまま投げただけ
それが自分的に発火点となって、いま、こうやってブログのエントリを書いてる。記録しておこうという動機がそこにできたわけで、投げっぱなしのSNSに意味はあった。
で、ホームページ。
たぶん、この手のことをこのブログ（ひまつぶし雑記帖）にだらだら書き殴ってると思うんで、そのうちまとめてページに起こそうと思う。ページを「作る」感覚ということになるかな。
SNSとブログ、ホームページの仕組みとも密着していて。
SNSは自作実装のActivityPubサーバー。
びっくりしたのが、何をするにしてもリクエストを飛ばすし、リクエストが飛んでくる。その回数が予想を遥かに超えていた。
言葉を投げる、言葉のキャッチボールというのはまさにこのことだなあ、と実感。
ブログは自作のブログっぽいCGI
ブログって何が必要なんだろうと既存のブログサービスを眺めて実装したんだけど。
言葉、データの蓄積がその本体。蓄積されたデータからどうやって引っ張り出すか表示させるかどんなふうに見せるか、というのが基本の仕組み。タグ付けなんかはまさにそれ。
ホームページは手作業作成
それこそ1ページずつコンセプト、テーマがあって、それに沿って「ページを作る」
SNSやブログとはレイヤーが違うシロモノ。1ページで完結させるし、1ページごとに動線を作って誘導する必要がある。
てな感じで棲み分けていこうと思う。
ホームページは「ページを作る」という意識が、SNSやブログと比べるとちょっとハードルが高いなあ、とも。
ちなみに各URL
・SNS「ため池::ところてん」 https://tokoroten.doncha.net/t2aki
・ブログ「ひまつぶし雑記帖」 https://t2aki.doncha.net
・ホームページ「On Golden Pond」 https://www.doncha.net
ネットは言葉で溢れかえってるなあというのを埴輪集団の画像で。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
