駄日記 (未完結間欠日記)

2021年 11月

(最終更新:2021-11-25)


2021-11-1 (Mon)

> ずっと入れっぱなしたまま起動もせずホッタラカシにしていた Mozilla Thunderbird をふと思い出して、アンインストールした。 ついでに Profile ディレクトリもすっきり削除。 最近はほんとに起動してなかったし、おそらくもう二度と使う (インストールする) こともなかろうな…。 最後に起動したのがいつだかもう覚えてないが…フォントレンダリングがきったなくなっちゃって対処不能だったり、 作成メールの文字コードが UTF-8 デフォルト (& Subject などは変更不可) になっちゃってたり (個人的にこれは致命的)、 あと Firefox と同じように拡張機能を切り捨てたり…。 なんかもうすっかり、いろいろとダメだこりゃになっちゃったしねえ…。 いや~、メーラは Thunderbird ができたからもうこの先いろいろ悩まなくて済むかなーとか思っていたんだが。 まさかこんなんなるとはなァ… (そもそも、その大元のブラウザの Firefox が以下同文)。
ちょっとおもしろそう。こういうの好き。まあ買わない (買えない) けど。 腕時計は光発電 + 電波補正 + 防水のをもういくつも持ってるので… (使わないのに!っていう)。
日本共産党は今まで非実在児童ポルノ規制に反対してきており、今回の総選挙政策の別の箇所でも「「児童ポルノ規制」を名目にしたマンガ・アニメなどへの法的規制の動きに反対します。」と明記してあり、共産党への問い合わせでは非実在児童ポルノの規制を意図したものではないと回答をしている。日本共産党の方針が変わったわけではなく、日本共産党の中にも表現規制派フェミニストに影響を受けた人々がいると言う程度の話だと思うが、日本共産党内部での表現規制派フェミニストの影響力をそぐために、批判はしっかり加えておこう。
クララ、って龍角散の会社で出してたんだ…。そしてもうなくなってたんだ…。

「クララ」自体は顆粒で、水なしでもサッと溶ける、飲みやすい商品で40年以上販売してきました。しかし当時の会社の状態で2つのブランドにマーケティングコストをかけることはできませんでした。

また「クララ」にはノスカピンという成分が含まれていて、効き目はあるものの、妊産婦や他の処方薬を飲んでいる人など、誰でも気軽に使えるわけではありませんでした。誰でも安心して使えるブランド価値を醸成していくためには、医薬品としては異例ではあるものの、ノスカピンを外す、つまり効果を下げた製品をつくるという決断をしなければなりませんでした。

当然、営業からは猛反発を受けましたが、テレビCMを投下しても「クララ」の売り上げを回復することはできませんでした。こうして「龍角散」と同じ成分で誰でも飲めて、かつ「クララ」のように顆粒で飲みやすく、携帯性を担保した「龍角散ダイレクトスティック」という製品を「龍角散」ブランドのひとつとして発売しました。

2021-11-2 (Tue)

> 昔、といっても大昔ではなくこの数年以内に自分で書いた Perl のスクリプトの中に、
for (0) {
    …(処理)…
}
とゆーコードを発見した。なんじゃこれ? 自分で書いたくせにどういう動作をするのか、咄嗟に分からなかった…。 試しに
perl -le '$c = 0; for (0) {print "x"; last if ++$c > 2}'
などと書いて走らせたら、"x" が 1回だけ表示された。 あ~そうか…。 これ、
  • 処理のある部分をブロック内に閉じ込めたかった
  • 何度もループするんでなく 1回だけ処理したかった
  • 条件によっては処理の途中でブロックを抜けたかった (後続する処理を飛ばしたかった)
  • 別関数にして呼び出す形にすると変数をぞろぞろ渡さないといけなくてメンドくさかったのでインラインでブロック化したかった
でこんな書き方をヒネり出したかどこかで探し出したかしたんだな…。 で、例えば for (0 .. 10) { … } などとするところの、 0 .. 10 の代わりに 0 を 1コだけ置いておいたと。 この 0 は for (foreach) ブロック内の $_ に渡されるが、 ブロック内ではこの $_ を使ってないんで、つまり 0 でも 1 でも 100 でもなんでもよかったんだった…。 というところまで推測できた。 それにしても分かりにくい書き方だわ…。 もうちっと自分ですぐ分かるように書けなかったんかい > ワシ。 for ('once') { … } とかにしとけば思い出しやすいかな…。まあいいか。

購入記録

  • 雑誌「まんがホーム」2021.12 芳文社
    • らいか・デイズ (むんこ)
    • 若王子主任は後輩ボイスに抗えない! (おりがみちよこ)
    • ヲトメは義母に恋してる (桐原小鳥)
    • 天国のススメ! (宮成樂)
    • 菓子男リノベーション (胡桃ちの)
    • オレの愛で世界がヤバい (井上とさず)
    • 先輩に推されて仕事になりません! (あしや雅浩)
    • 座敷童子あんこ (エミリ)
    • スナックあけみでしかられて (松田円)
    • 孔明のヨメ。 (杜康潤)
    • ぼくの上目遣い (市川なつを)
    • 恋はリベンジのあとで (辻灯子)
    • ラブアマ (有村唯)
    • 天下分け目の小早川くん (真田寿庵)
    • 幽霊さんのための科学的新仮説 (いわとびひろ) (ゲスト)
    • めい be love (いちかわ壱) (最終回)
    • 吸血鬼くんと死体ちゃん (さーもにずむ) (最終回)
    • ウメボシオニギリ (よるどん)
    • 歌詠みもみじ (オオトリキノト)
    • うちの秘書さま (ミナモ)
    • 新人まんが展:僕は学園生活を守りたいんじゃー! (あやのたぬき)
    • 目次4コマ:周瑜と音楽 (杜康潤)
MZ-700 版をやったなー。「不思議の森のアドベンチャー」もあわせて。

2021-11-3 (Wed)

> 一昨日の Thunderbird に続いて…でもないが、 起動もせずにずーっとホッタラカシだった Skype のアカウントを削除した。 Skype アプリを起動してメニューから (Skype と紐付けされてる) MS アカウントを削除して (確認用メールの送信先になぜか現在登録しているメアドではなく、 初期に登録したメアドしか選択できないウンコな挙動だったがなんとかクリア)、 これで 60日 (もしくは 30日、どちらか選べる、というかどちらかしか選べない) 再度ログインせずにじっとしていれば、 完全にアカウント削除される。
初めて Skype インストールしたのが 16年前か…。 あまりちゃんと覚えてはいないが、当時は無料でネットで音声会話するためのめぼしい選択肢がほぼなかったんだよな。 でも結局使う機会そんなになかったかな…。 そのうち運営が MS に乗っ取られて MS アカウント紐付け強制になっちゃってアカウント管理とかいろいろメンドくさくなっちゃったし。 Skype のメリットとしては、料金プリペイド式で固定電話回線に (国内にも海外にも) 格安で電話かけられるっつーのがあったが、 現在はおそらく他に使えるサービスがいろいろ出てきているであろうし (よくは知らない)、 ワシの場合国内なら「スだれ」使えるし (無料にならない番号もあるけど)、 海外に知り合いいないし、 そもそも電話自体もうぜんぜんしないし、 で現状メリットはなにもない。 今までアンインストールしないでいたのも、 ただホッタラカシにしているだけなら特になにもデメリットがなかったから、だったので…。
しかし Process Hacker でふと Bluetooth 用のプロセス (BTServer.exe) の下に SkypePlugin.exe なんてのがぶら下がって走ってるのを見つけてしまった…。 起動もしてないのになんでこんなのが走ってんだおい、っていう。 まあ Bluetooth デバイスとしてヘッドセットを登録してあるからその関係だろうけど。 メモリも CPU リソースもほとんど食ってはいないものの、 CPU リソースの箇所に 0.02 という数値がぺかぺかついたり消えたりしてるんで、 これ Windows が動いている間ずっと延々とポーリングかなんかしてんのか… と思ったらなんか急に閾値を超えて邪魔くさく思えてきたのでアンインストールが決定した (いつものパターンだな)。 しかし Skype をアンインストールした後もこのプラグインはそのまま残って動き続けている。 ゾンビか。 まあ Windows 再起動したら消えるだろう。
Quick Charge (および類似の高速充電) は USB 規格的にはすべて禁止されている。 規格的に禁止されてはいるが、ちゃんと対応して{設計|製造}されている製品であれば実際は必ずしも危険ではない。 らしい。
「ジャヒー様はくじけない!」考察。 ちなみにワシは見てない (テレビ自体)。

2021-11-4 (Thu)

> vim でファイルを開いた時、カーソルを前回編集終了時の位置に移動する (カーソル位置を覚えておく)、 という設定のやり方を検索して調べて、.vimrc に設定を追加したのはいいが、 いくつかある Linux 系環境のうち、どうしても設定が反映されない (カーソル位置を覚えてくれない) 環境がひとつあった。 原因がわからないまま半日ばかりあーでもないこーでもないといじくり回したが、どうやっても有効にならない…。 いい加減イヤになってきた頃、 ふと ls -la でホームディレクトリのファイル一覧を見たら、 .viminfo の所有者がなぜか root に、タイムスタンプが去年になっていた…。 ひょっとしてこれか?と思って当該 .viminfo を削除したら、なんともあっけなく設定が利くように…。 なるほどこれだったかァ~…。 vim のカーソル位置ってこれに記録されてたんだな。 でも所有権がなくって上書きできなかったもんでいつまでたってもカーソル位置の記録が反映されなかったというオチだった。 なんでそんなところに root の .viminfo ができていたのかは分からんが…。
2017年の記事で若干古いけどちょっと参考に。

2021-11-5 (Fri)

> 画像をまとめて加工処理するのに perl のモジュール Imager を愛用しているんだが、 もっと速く処理する方法 (というかモジュール) があったりしないかな…?とふと思って検索してみたら、 Image::Imlib2 というモジュールの情報を見つけた。 速くなるかどうかは試してみないと分からんな…と思ってとりあえずインストールしようとしたんだが。 メイン作業環境の cygwin 上に cpanm で入れようとしたら、どうもライブラリがいろいろ足りなくてダメっぽい (正確なエラーメッセージは覚えて & 記録してない)。 ウチの cygwin は諸事情により久しくアップデートしてなくて、 うっかりアップデートかけると現在いろいろと頼っているいろんなモンがマトモに動かなくなる危険がとてもヤバいので、 cygwin 経由でライブラリを補うのは諦めた。 しかし他に Linux 環境がいくつかあるんで、まあ試すだけならそっちでもいいじゃろ、と思ってめぼしい環境に片っ端から入れてみた。 Linux mint と ubuntu (20.04) には cpanm からサクッと入った (Imlib2 ライブラリを要求されたが、apt でするっと入ったので問題なし)。 スマホ (android 11) 上の termux には入らないかなあ…と思いつつも試したらこっちもすんなり入った。 メイン作業環境の cygwin で (だけ) 使えないっていう。もうぼちぼちメイン作業環境の見直しも必要だんべなァ…。 仕方ないので ssh でテキトウな環境にログインして、ログインした先で普段使ってない vim でスクリプトの編集作業を行なう。 SftpNetDrive っつーユーティリティを使えば、 ssh で接続した外部マシンのディレクトリを仮想的に Windows のドライブに割り当てて (nfs の ssh 版の Windows 版な感じ?)、 遠隔ファイルを普段使ってるエディタ (xyzzy) で編集できなくもないんだが、 どうしても反応に遅延が生じたりしてかえって使いづらかったりするので…。 という関係で昨日 .vimrc の設定でまごまごしたりしたんであった。 続く。
「時給はいつも最低賃金、これって私のせいですか? 国会議員に聞いてみた。」(立憲民主党小川淳也議員との対話の本) の著者和田靜香氏と、 「オードリー・タンの思考 IQより大切なこと」(オードリー・タン氏の評伝) のライター近藤弥生子氏との対談。
Perl の Image::Magick モジュールの資料。 うまく使えれば高速処理が可能かもしれないが…なにしろ複雑怪奇で手をつけるにはちょっと覚悟が必要だなこれ…。

2021-11-6 (Sat)

> 昨日の続き。
Image::Imlib2 をインストールできたので、どんくらい Imager と処理速度が違うのか試した。 現在使っとる画像処理用自前スクリプトのひとつを、Imager 使用から Image::Imlib2 使用へ書き直して、 走らせて所要時間を見たんだが、思っていたような高速化にはならず。 つーかむしろめたくそ遅くなってしまった…。 遅くなった元凶は、画像の指定座標の色を拾う処理。 やろうとしているのは、スマホでキャプチャした漫画の各ページの、 縦向き画面なら上下、横向き画面なら左右の、余分な部分を切り落とすこと、なんだが(*6-1)。 これらの画像は png (可逆圧縮) で余計なノイズなども乗っておらず、「余分な部分」の色 (背景色) は綺麗に 1色に揃っているので、 単純に「その座標の色が背景色とまったく同色かどうか」を端から比較していけば背景色の範囲を確定できるんだけど。 その画像の色を拾う処理に Imager も Image::Imlib2 もめっちゃ時間がかかる。 Imager の場合、getpixel (や getscanline) という色を拾うメソッド (激遅 (getscanline はやや速いが使い勝手はいまいち)) の代わりに、 getcolorcount という画像データ内の色数をカウントして返すメソッド (高速) を使って、 元画像を 1ライン分ずつ端からクロップしていき、そのクロップ範囲内の色数が 1 で、 なおかつそのうちのどれか 1点の色が背景色と同色であれば、そのラインは背景部分、という判別法で処理速度を多少上げられた。 しかし Image::Imlib2 では画像の情報を拾う query_pixel というメソッドはあるが、指定座標のピクセル単位でしか使えないっぽい。 そしてやっぱり遅い。 なんか他に方法はないかと思って探したら、 背景色 (画像の周辺の色 = ボーダーカラー) を自動で判定して切り落とす autocrop というメソッドと、 実際の切り落とし処理はせず、範囲の座標だけを返す autocrop_dimensions というメソッドがあった。 Imager の getcolorcount と同様、autocrop (autocrop_dimensions) も内部でのみ処理をするらしく、さくっと高速で完了する…。 というわけで、自力で色比較するかわりにこれを使ったら処理速度が上がった。 といっても試してみたスクリプトに限って言えば、 Imager 使用で 8秒台のところが Image::Imlib2 使用で 5秒台になった程度で、爆速というほどではなかったが…。 画像 (ピクセル) を走査する必要がなく、単に決め打ちの処理加工をするだけならもう少し差はつきそうかな。 でも perldoc でぱっと見た感じでは、Imager の方がだいぶ高機能っぽくはあるんだな…。 自前の画像加工用スクリプトはいろいろ作ってるんで、Image::Imlib2 で置き換えるのが難しいのもあるかもしれない。 けっこう、画素を調べてそれに応じて加工、みたいなことをやってるんで…。 まあ適宜使い分ければいいんだが。 問題は Image::Imlib2 が現在、メインの作業環境では使えない (インストールできない) ことだよな…。

購入記録

  • 雑誌「まんがタウン」2021.12 双葉社
    • 新クレヨンしんちゃん (臼井儀人&UYスタジオ)
    • コミックエッセイ特集~私の大好きなスイーツ~ (東屋めめ/大場玲耶/とく村長)
    • 押しかけギャルの中村さん (おりはらさちこ)
    • 派遣戦士山田のり子 (たかの宗美)
    • 新婚のいろはさん (ÖYSTER)
    • ルナナナ (小坂俊史)
    • 勇者様!? こ…これってそういう意味ですかっ!?♥ (大場玲耶)
    • あさひ大家族 (ふじた渚佐)
    • 野原ひろし 昼メシの流儀 (塚原洋一)
    • かりあげクン (植田まさし)
    • 大越春太郎は黙れない! (瀬田ヒナコ)
    • SUPER SHIRO コミック版 (原作:臼井儀人/作画:相庭健太/原案:湯浅政明/制作:SUPER SHIRO制作委員会) (最終回)
    • 恋するスマホちゃん (橙夏りり) (ゲスト)
    • 恋がわからぬ大人共 (赤のキノコ)
    • かのんとぱぱ (おーはしるい)
    • 猫またはごはんを。 (湖西晶)
    • 鎌倉ものがたり (西岸良平)
    • 君と銀木犀に (相澤いくえ) (最終回)
    • 淑女の笑顔は崩れません (佐野妙)
    • 食欲しか勝たん! (えきあ)
    • んじゃま、ここらでお茶にしましょうか。 (胡桃ちの)
  • 雑誌「週刊漫画TIMES」2021.11/19 芳文社
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • ごほうびごはん (こもとも子)
    • 神客万来! (ねむようこ)
    • パスタの流儀 (原作:花形怜/才谷ウメタロウ)
    • 経理の夏谷さんはガマンできない (財政ろろ)
    • 村祀り (原案協力:木口銀/山口譲司)
    • 瓜を破る (板倉梓)
    • ヘルズボート136 (前田治郎)
    • ダンナの童貞もらいます (神山とく)
    • ヤバい女に恋した僕の結末 (沖田龍児)
  • 雑誌「まんがタイム」2021.12 芳文社
    • おとぼけ部長代理 (植田まさし)
    • 花丸町の花むすび (むんこ)
    • レーカン! (瀬田ヒナコ)
    • ラディカル・ホスピタル (ひらのあゆ)
    • 大家さんは思春期! (水瀬るるう)
    • ローカル女子の遠吠え (瀬戸口みづき)
    • 百合のあいだは悩ましい (森井暁正) (ゲスト)
    • この契約は恋まで届きますか? (雪尾ゆき) (ゲスト)
    • 軍神ちゃんとよばないで (柳原満月)
    • 冷めないふたりのひとりご飯 (きたむらましゅう)
    • テレパス皆葉と読めない彼女 (諸田トモエ)
    • 六畳一間の憑き物石 (西岡さち)
    • 茨城ってどこにあるんですか? (真枝アキ)
    • 瀬戸際女優! 白石さん (櫻井リヤ)
    • 良倉先生の承認欲求 (G3井田)
    • 秘密のお姉さん養成ノート (トフ子)
    • お天気おねえさんの晴れ舞台 (きなこ)
    • お酒は20日になってから!! (えのまなみ)
    • 午前0時のおねだりごはん (あきさと)
    • 女神に胃袋つかまれた! (町田すみ)
    • 目次4コマ:つながれ! 黒電話ちゃん (瀬田ヒナコ)

蛇足的脚注

*6-1 : 余分な部分を切り落とす
正確には、同一作品のキャプチャ画像の複数枚セットから、 全画像に共通して背景とみなせる領域を調べる処理。 たとえば作品画像の紙色が白で背景色も白だった場合、 画像を個別に切り落とし処理すると、 ページごとに枠線などの位置のバラつきがあるから、 それぞれサイズや形状がバラバラになってしまったりする可能性がある。 説明ヘタクソだな。

2021-11-7 (Sun)

> もうとっくにネタ切れ。
> 先月買った柿の、皮を包丁で剥くのは実が滑って剥きづらいなあ…と思っていたんだが。 剥く (刃を進める) 方向と垂直に刃を微妙に動かしながらだと刃を進めやすい、ということに超今更ながら気づいた。 引き切り、と同じ原理かな…。 ただしこれ、コントロールがむずかしい…。 たぶん場数を踏めば無意識にできるようになっていくんではないかという気がするが…。 そもそも果物だの野菜だのの皮を剥く機会自体ほぼないからなー今や。 自分で調理をほぼしなくなっちゃったし…。 細かく | 粗く、切り刻むことはあるが、基本的に野菜類の皮は剥かないし。 果物も大体皮ごと食えるものばっかし買ってるし (梨は剥きやすいので剥いて食うけど最近梨ぜんぜん買ってないけど)。 というわけで柿の皮を包丁で上手に剥けるようになる日はワシの場合おそらく死ぬまで訪れないであろう。 なお、皮剥き器の類は過去に使ったことはあるが、 何度かうっかり指を切ってから、あれは使いづらいもの、と認識してその後は使ってない。 まあ、防刃手袋とセットでならあるいは… (やらないけど)。
先代 (二代目) 古今亭圓菊師匠は、友人がファンだった。
複数の動画を、グリッド状に並べて同時に再生する!「GridPlayer」。

2021-11-8 (Mon)

> ゲーミングスマホ、なんてあるんだな…。 高性能 CPU (SoC) に大容量メモリに大容量バッテリに高精細高リフレッシュレートディスプレイに冷却機構と。 もうそれ“スマ”でも“ホ”でもないんでは…。 つーか電話機能ついてなくってもいいんじゃん。むしろゲーム中に電話かかってきたら邪魔じゃん?
> 太田淑子 (よしこ) さんの訃報。10.29、89歳。

2021-11-9 (Tue)

> メモ。十二支の音読み。
十二支
音読み ちゅう いん ぼう しん しん ゆう じゅつ がい
訓読み うし とら たつ うま ひつじ さる とり いぬ
「し」と「しん」はダブっちゃうんだな…。
> ssh でレンサバとか周囲の Linux 環境とかに接続するのに、 これまで接続先ごとにそれぞれ個別の鍵ペアを作って使っておったんじゃが。 全部が全部じゃないけど…ほとんど…。 これ、接続元で鍵ペアをひとつ作ったら、そこから接続する先に公開鍵の方をコピーして…っていうのを、 接続元ごとにやればいいだけだったんだな。 まあ、鍵ペアをいっぱい作ってもそれでなにか不都合が起きる訳ではないんだが… (管理がメンドくさくなるだけで)。
あと鍵の強度ってどう計ればええんじゃろ、と思ってそれも調べてみた。
ssh-keygen -l -f id_rsa.pub
などとやって公開鍵のフィンガープリントを表示させた時の、最左項が鍵長 (ビット数)、最右項が暗号化方式で、 暗号化方式が RSA かつ鍵長が 2048 (いずれも現在の ssh-keygen のデフォルト) 以上ならまあ大丈夫、らしい。 ワシが使ってる中で一番古い鍵もこの条件は一応クリアしていた。よかった…。
とゆーわけで、作業環境で使ってる ssh の鍵ペアをこの一番古くからのやつに統一して、あとはさくっと整理した。
> ssh の鍵ペアをちょっと気にしたキッカケは、 SftpNetDrive (*9-1) というやや古い (2016年製) ユーティリティで、 新しく作った秘密鍵を指定したら、 「key algorithm is not supported」とかなんとかで弾かれちゃって設定できなかったところから。 昔作った鍵なら受け付けるのに、鍵長も暗号化方式も同じなのになぜ…よくわかんない… 古い鍵なら受け付けるんだからそれ使ってればいいか… でも鍵の使い回しってどうなんだろう…あと強度も (昔作ったんで作成時のパラメータも覚えてないし) 十分かどうか確認するには… というあたりで超今更ながら情報を漁ってみた次第。
ちなみに SftpNetDrive は最新のバージョン 2 もあるんだが、 これはダウンロードするにもインストールするにもその都度メアドだの名前だのをいちいち入力させられたり、 インストール中になにやら勝手にサービスを別途仕込まれたり (システム再起動を要求される)、 そのへんをガマンして走らせてみたけど結局最近作った鍵はなんやらエラー出ちゃって受け付けなかったり、 それ以前に設定画面の挙動がなんかビミョウにヘン (buggy) だったり、 と踏んだり蹴ったりだったので速攻で削除した。二度と使わない。 たしかこれだいぶ以前に一度インストールして、イヤな目にあった記憶 (というか印象) が残ってたんだけど…。 もしかしてその後ちょっとマシになってるかもしれないし…というダメ元の一縷の望みはやっぱりダメだった。 いやまあ、なんかオープンソースで探せば同じようなことのできるユーティリティは (いくらでも) ありそうではあるんだけどな。 根気よく探したりしてないけど…。
以上なんとなくメモ。
ちょっと間違ってた。

蛇足的脚注

*9-1 : SftpNetDrive
ssh (sftp) で接続したリモートのディレクトリを、特定のドライブまたはフォルダに割り当てて、 ローカルにあるかのごとく操作できるようにする Windows 用ユーティリティ。

2021-11-10 (Wed)

> いつぞや作った Twitter 画像の半自動ダウンロードスクリプト、 その後 Twitter 側の仕様変更にもめげずに手を入れ手を入れ使っていたが、 最近、想定した通りのダウンロード順にならないケースがたまに混じるようになった…。 なんで順序が入れ替わるのか。ナゾだ。 原因をいろいろ考えているが、まだよくわからん。仮説はいくつか立ててはみたが…。 たぶん、このところずっとネットワーク接続があんまし安定してないのも原因のうちなんだよな…。 もしかすると排他処理が必要になるかも、と思って検索して async-lock というのを見つけて、試してみる直前のところで止まっている。 処理全体の流れを書き直した方が結果的にラクな可能性もあるしな~。 まあ仕事じゃないから結果が出なくても誰も (自分以外) 困らないんでしばらくあれこれ試してみるか。

購入記録

  • 雑誌「ヤングコミック」2021.12 少年画報社
    • 31歳地味眼鏡OLさん (新居さとし) (新連載)
    • ゾンビだらけのこの世界ではセックスしないと生き残れない (実倉なる)
    • ツボネノツバメ (zen9)
    • イケナイ菜々子さん (あさぎ龍)
    • ヤンキー娘になつかれて今年も受験に失敗しそうです (ジェームスほたて)
    • 神様にはナイショ! (桂よしひろ)
    • はかりしれない計子さん (大沢ういち)
    • スカートの裾掴むボクの手が今も震えてるのは…… (佐野タカシ)
    • 元女勇者35才 (蛇光院三郎)
    • かみくじむら -ぬめりロワイヤル- (大見武士)
    • 見たいもの見せましょう (たまはがね)
    • 少年画報社版 人物日本の歴史 三峯徹 (金平守人/監修:稀見理都)

2021-11-11 (Thu)

> 昨日の続き。
件のスクリプト、画像のダウンロード & 保存のところをこんな風に書いていたんだが。 なお perl 書きなので基本行末 ";" つける派。
(async () => {
    const dlpic = async () => {
        if (pic_queue.length) {
            (…略…)
            const req = await https.get(url, (res) => {
                const sfile = fs.createWriteStream(`${save_dir}/${fname}`);
                res.pipe(sfile);
                res.on('end', () => {
                    sfile.close();
                });
            });
            req.on('error', (e) => {
                console.log(`err: ${e.message}`);
            });
            (…略…)
        }
        setTimeout(dlpic, 2000);
    };
    dlpic();
})();
たぶんどこかからコピペしてきたコードをちょっと書き換えて作ったんだと思う (すでに覚えてない)。 で、 https.get() に await をつけてあるから、 ファイルの保存が完了するまで待ってから (同期的に) 次の処理に移るだろうと思い込んでいたんだった。 でもこれたぶん pipe() に渡してる時点でそっから先は非同期処理なんだな…。 で、この関数 (dlpic) は、処理の末尾で 2秒後に自分自身を呼び出すよう setTimeout をセットする形で、 約 2秒に 1回のペースでループ動作させてるんだが。 でもファイルを保存し始めてから完了するまでの動作が非同期じゃ、 そこでもし何らかの原因でもたついたら次の (dlpic 内の) ファイル保存の方が先に終わっちゃう場合もそりゃ出てくるわな…。 で、最近ネットワーク接続が時々妙に不安定になりだしたもんで、そのへんが露呈したと。
そもそもこの関数自体は同時並行的に複数走る (呼び出される) 必要はまったくないので…。 でもって約 2秒の間隔は上限 (遅れ禁止) ではなく最低限 (確保必須) なので…。 ファイル保存が終わるまできっちり待ってから次の自分自身呼び出しをするようにすればいいんじゃん、と思って、 コードを書き加えてみた。 もっと根本的に書き直す方法がありそうな気がしつつの、小手先 (フラグ) での対処。 でもこれでたぶんファイルの保存順入れ替わりは解消するハズ。前述の推測が正しければだが。あとデッドロックも起きないハズ。
const sleep = async msec => new Promise(resolve => setTimeout(resolve, msec));
(…略…)
(async () => {
    const dlpic = async () => {
        if (pic_queue.length) {
            (…略…)
            let now_writing = true;         // ←追加
            const req = await https.get(url, (res) => {
                const sfile = fs.createWriteStream(`${save_dir}/${fname}`);
                res.pipe(sfile);
                res.on('end', () => {
                    sfile.close();
                    now_writing = false;    // ←追加
                });
            });
            req.on('error', (e) => {
                console.log(`err: ${e.message}`);
            });
            (…略…)
            while (now_writing) {           // ←追加
                await sleep(100);           // ←追加
            }                               // ←追加
        }
        setTimeout(dlpic, 2000);
    };
    dlpic();
})();
結局、昨日探してきた排他処理ライブラリ (モジュール) async-lock は使わずじまいだった。 まあそのうち活用する機会もあろう…。 いや別になくてもいいけど。
> 瀬戸内寂聴氏の訃報。11.9、99歳。

購入記録

  • 雑誌「まんがライフオリジナル」2021.12 竹書房
    • のみじょし (迂闊)
    • 晴れのちシンデレラ (宮成楽)
    • リコーダーとランドセル (東屋めめ)
    • ちぃちゃんのおしながき (大井昌和)
    • ずぼら先輩とまじめちゃん (東385)
    • しょうもないのうりょく (高野雀)
    • 雑兵めし物語 (重野なおき)
    • ねこようかい (ぱんだにあ)
    • 森田さんは無口 (佐野妙)
    • はかせの未来 (せかねこ)
    • ばつ×いち (おーはしるい)
    • おんぼろ花ハイム (むんこ)
    • ここは鴨川ゲーム製作所 (スケラッコ)
    • よそじとふたごのメシ事情 (小坂俊史)
    • ぼのぼの人生相談 (いがらしみきお)
    • 黒影夜子の駐在日誌 (唐草ミチル)
    • セトギワ花ヨメ (胡桃ちの)
    • となりの席の同居人 (神仙寺瑛)
    • ネコぐらし (深谷かほる)
    • 中年女子画報 (柘植文)
    • もぐもぐガーデン (宇仁田ゆみ)
    • 鬼桐さんの洗濯 (ふかさくえみ)
    • ハッピーアワーガールズ (揚立しの)
    • そしらぬディスタンス (松田円)
    • とーこん家族 (よしもとあきこ)
    • ギャル医者あやっぺ (長イキアキヒコ)
    • 異世界にマンガ家が転生したらどうなるのか、描いてみた件 (上田敦夫)
    • 全ての映画は、ながしかく (施川ユウキ)
    • 目次4コマ:ポポ時評 (施川ユウキ)

2021-11-12 (Fri)

> 引き続きとっくにネタ切れ。
> 室温 21~22℃から 19~20℃へ。 たった 2~3度下がるだけでずいぶん体感温度が違う…。 つまり寒い。かなりしみじみ冷える。 なんて脆弱なんだ…生命ってモロイな…とか考えちゃう… (この場合の生命とはワシだが)。
今冬はラニーニャだかで厳冬になるかもしれないとか。 寒いのヤだなー。 まあエアコンが (時々あまり寒くなると利きが悪くなるとはいえ) 一応まだ壊れずにいるから、いざとなったら頼れるけど。 物理的以外にも精神的にも支えだけど。電気代がアレだけど。
…またハクキンカイロ買っちゃおうかな…。 といっても前回買ったのは値段が安いめのパチモンだったか。 もうどっかいっちゃったけど。 9年ほど前の引っ越し作業は毎日すごく寒かったのに、 使った記憶がないんで…たぶんその頃には使えなくなっていたか捨てていた可能性が高い。 ハクキンカイロはいいけど点火するのにマッチかライターが必要なんだが、どっちも持ってない…。 マッチは燃えカス始末すんのが毎回面倒だし…ライターを導入するつっても使い捨ては捨てる時が厄介だし…。 燃料充填式にしても燃料の扱いとかもまたそっちはそっちで面倒が増えるし…。 いずれにしても出費が上乗せでかさむし。 いろいろ悩ましい。
あるいはハクキンカイロやめて充電式の電気カイロみたいなのにしてみるか…? 使ったことないんでどれくらい使えるモンかは知らんけど。 ちょっと情報を探すだけ探してみよう。
…いや、そんなことよりまず先になにか着るものを買い足すべきだったか。 室内用のボロ防寒装備を、今年あったかくなってきた頃にすっかり捨てちゃって、 着るモノがない状態なんで…。そりゃ寒さも身にしみるわ。 まずはそこからか。

購入記録

  • 雑誌「週刊漫画TIMES」2021.11/26 芳文社
    • 瓜を破る (板倉梓)
    • 妻、小学生になる。 (村田椰融)
    • 信長のシェフ (梶川卓郎)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
    • ごほうびごはん (こもとも子)
    • 村祀り (原案協力:木口銀/山口譲司)
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • うそびっち先輩 (音井れこ丸)
    • ユラギ♂ノ♀カラダ (奥森ボウイ)
    • ヤバい女に恋した僕の結末 (沖田龍児)
    • かわうその自転車屋さん (こやまけいこ)
む。
太陽電池 (USB 充電可)。WLAN。IP65 防水。赤外線暗視 (自動切替)。視野角 120度。双方向通話対応。microSD カードに録画可。ふーむ。
近所のスーパーのどこかで類似のものを見かけた気がする…。これより高かった気がするが…。
ばらまき型メールを監視・分析・共有するサイバーセキュリティー技術者の集まりである「ばらまきメール回収の会」は2021年11月11日時点で既に1000件を超えるメールアカウントが盗まれているとみる。
そんな会があるのか。
xID 社の基本的な方向性 (目指せ! 超監視国家・超監視社会) 自体が × なので、 どんなに手を変え品を変えようと結果は × にしかならない。 ここは会社としてのなりふりもいろいろアレっぽい…。 こういうロクでもない会社 (や経営者) がけっこう生き残っちゃったりするんだろうなあ。ヤダヤダ。

2021-11-13 (Sat)

> ヤフオクで、「大塚康生」で検索すると… どこからどう見てもニセモノの、 「サイン 肉筆 手描き 真作 本物保証販売」と堂々とぶちかましたニセサイン入りニセイラスト色紙をいくつも売っている奴がいる。 どう見ても大塚さんの絵じゃねえだろそれ、っていう… (なんなら時々別の原画家の絵柄のマネも混じっている)。 いや、一応イラストの嗜みはあるっぽい描線ではあるんだが。 あと、しばらく観察してたら少~しずつそれなりに上達してるっぽい気配はあるにはあるんだが。 でもどう見てもニセモノなんだよなあ…。 これがまた次々手頃な (数千円程度の) 値段で落札されてたり、落札者から高評価を入れられてたりするんだが…。 これなんなんだろうな? なにかそういうニセモノなのを分かった上で落札して楽しむヘンな文化みたいなのが一部にあったりするんだろうか? むかーし、2ch あたりでそんな感じの悪ふざけ (もうちょっと悪趣味な、なんなら犯罪に足踏み入れてるようなやつ) を好んでやってる連中がたむろしてたのは見たことあるけど…。 とりあえず見つけ次第ヤフオク運営に一応報告してはいるが、運営はほぼ放置で基本スルー。 もともとだがヤフオクの運営はあんましやる気ないっぽい。 もしくは圧倒的に人手が足りてなくて、それが分かった上でその状態を続けてるのかもしれないが。 それらの出品からいもづる式にたどって、さらに見るからにヘッタクソな「手塚治虫」のサイン入り色紙とかも見つかったり…。 さすがに最近手塚治虫のは画力が違いすぎてバレバレなせいか、 それとも違反報告の量が多いからなのか、速攻で運営から強制終了させられているようだが、 アカウントは無傷なままなので何度でも延々と再出品し続けている。 手塚治虫作品は現在も著作物管理している人なり団体なりがたぶんあると思うけど、 大塚さんの場合はそういう管理団体みたいなのはなさそうだし…。 どうすればええんかいねこういうのって…。
 ご紹介するのは、2015年の1月に「日経ビジネスオンライン」(←当時)の連載コラムのために書いたテキストだ。
 さきほど検索してみたところ、あらまあびっくり、消えている。
 どうやら、あの媒体は、古い記事を削除する方針を貫いている。悲しい。
 あんまり悲しいので、ブロクにテキストをアップすることにした。
そうなんだよ端から消えてくんだよな日経系は。
腕が寒いなー、と思って「アームウォーマー」で検索してたら引っかかった。 冬の外作業は防寒必須だもんな。

2021-11-14 (Sun)

> 以前からだけど、普段の食事に割り箸を愛用している。 出先ではなく家で。 最近では機会が減ったけど、コンビニやスーパーで惣菜や弁当を買うと何も言わなくても割り箸をつけてくれることが以前はよくあって、 まあ事前に要不要を確認されたら大抵は要りませんと言うんだけど、 渡されてから返すのもナンだし使えばいいだけだしと思って持ち帰って貯めといて順繰りに使っている。 貯まりすぎてたまには古いやつ (ホコリかぶりかけてるようなのとか) を捨てたりしてもいるんだが、それでもまだけっこう備蓄がある。 ひとつには、竹製の割り箸は長持ちするもんで洗い洗いけっこう長いこと使い回したりするのと、 竹製じゃない割り箸も、とりわけ洗わずに乾かし乾かしでけっこう長いこと使い回したりしてるので、 なかなか消費が進まないんである。 なおちゃんと乾かして保管すれば、洗わずとも案外使い続けても大丈夫だったり。 少なくとも割り箸が原因でお腹壊したりしたことはない (と思う)。 改めて考えるとばばっちいな。 でもどうせ自分しか使わないし自分しか見てないんで、自分が気にしなきゃ OK。 人前ではたぶんやらない。
割り箸のいいところは、箸先がすべらない (すべりにくい) ところ。 気軽に使い捨てできるところ。洗わなくていいので生活排水の量を減らせるところ (微々たる影響。というかゴミとして燃やすのと洗剤で洗って排水を出すのと環境負荷はどっちがでかいんだこれ?)。 難点は、ささくれがありがち…というか、 ささくれのないようないい割り箸は使ってないので、必ずどこかしらささくれているところと、 塗り箸などと比べて角が立っているので (安物は特に)、指に優しくないところ(*14-1)。 なので最近は割り箸を割ったら、 まずカッターなどで角を削いで、ささくれも取りつつちょっとなめらかにしてから使っている…。 大袈裟に表現すると、断面を四角から (ほぼ四角な) 八角形にする感じ。 角を削ぎながら、昔はこうやって鉛筆も削ったなあ、あの頃は叔父にもらった年季の入った肥後守で削ってたけど、とか思い出したりして (鉛筆削りなら肥後守におまかせ。あの肥後守どこにやっちゃったかなあ…)。 角を削ぐと割り箸も持ちやすくさらに使いやすくなるので、おヒマな向きにはおすすめしたいところだが…。 まあでも出先で使う割り箸の角を削ぐ用の小刀持ち歩くくらいならマイ箸でも持って歩いた方がいいか。 ことに今の日本は法律と警察が歪んでいて、 ちょっとした刃物を持ち歩いただけで逮捕されたり罪人にされたりするディストピアだしなあ…。 といって紙やすりなんかで研ぐのも木粉が出て削りかすより始末が微妙に厄介そうだし。 …紙やすりか…こんどちょっと試してみるか…。

蛇足的脚注

*14-1 : 指にやさしくない
最近箸はすっかり左手で持つように習慣づいたんだが、 右手に比べて年季が浅いせいか、 力が入り過ぎているか持ち位置がよくないかその両方かで、 薬指に箸だこができてきた。 そしてその箇所に割り箸のとがった角が当たると余計にたこが育ってしまうんであった。

2021-11-15 (Mon)

> メモ。jetson nano。jetson nano で waifu2x。
> termux で sftp サーバを動かすにはどうすればいいのか…。 基本がわかってないとこういう時困る。 もう起動してるのかなこれ…?
SftpNetDrive が新しく作った鍵ペアをもうぜんぜん受け付けなくなってるので (なんでか分からないが)、 SftpNetDrive の代替になんかないかなーと思って探したやつ。 しかしなぜかスマホや Raspberry Pi 2 (ubuntu) には接続ができない…。なぜだ。 →その後接続できた。よくわからないが設定する際になにかコツみたいなのがあるのかもしれない (つまりちょっと buggy?)。
あと、cloud drive 関連 (google drive とか dropbox とか) もマウントできるらしいけど、 そっちはそっちで現状だとあんまし使い道ないんだよなあ。

2021-11-16 (Tue)

> termux で sftp サーバは動いていた。sshd と一緒に。 昨日インストールしてみた RaiDrive からの接続が何度か弾かれ続けたんで、 sftp サーバが立ち上がってないせいじゃないかとなんとなく思ってたんだが。 なんか RaiDrive の設定画面にクセがあって、 設定する順番によっては既に入力済なはずの項目が勝手にクリアされたりしちゃってたっぽい…ような感じ。 設定の様子を記録していた訳ではないのでいまいち確かなことは言えんのじゃが。 まあいいや…。接続できたから…。
RaiDrive でローカルのドライブにマウントした (ssh で接続した先の) 環境は、 パーミッションとか所有者とかの取り扱いに気をつける必要があるファイル以外は、 普通にアクセスできるし変更も削除も追加もできる。 ただどうしても若干の遅延は生じる。 つまり、今まで使ってた SftpNetDrive となにも変わらん。 常用するためというより、いざという時用。 あー、メモリ消費は機能の割にちょっと多めな気はしなくもないかな…。
なお RaiDrive は google drive や mega や dropbox や one drive などのクラウドストレージにも対応。 接続先の設定の保存は 8コが上限。 管理画面の上部には常にバナー広告が表示されている (音は出ない)。 その他の制約は特になし。
ちなみに SftpNetDrive はもう用済みということでアンインストールしたら、 アンインストールシーケンスが終わったとたんにシステムがリブートし始めた(*16-1)。 ファッキンな最後っ屁だった…。 うちの環境は常駐物がテンコ盛りで、終了の途中で必ず、 終了を妨げているプロセスだかタスクだかがあります、とかなんとかの確認画面が出るので(*16-2)、 ここで一旦終了処理をキャンセルすれば一応いろいろと後始末をしてから改めて終了処理には入れるんだが、 どっちみち強制的に再起動を強いられて後始末させられるだけで相当メンドくさいんだよ。 うちは特に再起動開始から完了まで 30分くらいかかるから余計いろいろメンドいんだよ (SSD に換装したい)。
> 昨日 URL メモった文春オンラインの畑正憲 (ムツゴロウ) インタビュー記事からリンクされていた、 (記事中に使われたものも含めた) 全撮影写真の閲覧ページの写真データを、 全部手元にダウンロードしようと思ったんだが、 ここのサイトはセッション的な仕掛けで動的に画像へのリンク URL を生成しているらしく、 現に表示されているページの HTML ソースの <img src="~~.jpg"> から 画像へのリンク URL を拾って直接他の手段でアクセスしても、 401 (Unauthorized) で弾かれてダウンロード (GET) できない (なおこの画像リンクの URL はブラウザを立ち上げるごとに変化する)。
こういう時は仕方がないので node.js + puppeteer。 最初は自動で画面キャプチャ (screenshot) を撮って保存して済ませてたんだが、 どうもサイズが微妙に小さい…。横幅 750px しかない。 できれば元画像データを保存したい。 しかし puppeteer 内の DOM から <img src="~~"> を拾っても、 その URL に別途アクセスしようとすればやっぱり 401 で弾かれるので…。 既にブラウザ (puppeteer) がダウンロード (GET) して表示用に展開し終えている画像データを、 そのままファイルに保存できればいいだけなんだけど…と思ってちょっと検索してみたら、 目当ての情報に行き当たった。以前探した時は見つからなかったんだが、今回は検索語がたまたまよかったのかな? この情報を参考にスクリプトを書いて、自動でページを移動しながら全画像 (202枚) を取得でけた。 ちなみに元画像の横幅は 1500px だった。表示時に半分まで落としてたんだなあ。 もっとも環境によっては表示サイズがさらに変わる可能性もあるけど。
しかし、こういう不自由なコンテンツの表示 (提示) の仕方ってのはどうしても好きになれんなあ…。 剽窃・盗用 (よそからの勝手リンク含む) の防止が目的なんだろうとは思うが。
今更…とかつい思っちゃうけど。 制限をいろいろ緩和する予定らしい。ポリシーとかも。 OpenTween 復活につながるかな…?
「ページ内の画像等のリソースを保存する」。 これが知りたかった。

蛇足的脚注

*16-1 : リブート
アンインストールの途中で英文のダイアログが出てきて、reboot 必要だっせ? みたいな説明と、YES と NO のボタンがあったので、 NO にしておけば勝手にリブートし始めることはたぶんないだろう、と急いで NO を押したのが実はワナだった可能性はある。
*16-2 : 確認画面
windows のバージョンによるんだろうとは思うが。

2021-11-17 (Wed)

> ヤマト運輸の追跡サービスのページがいつの間にかリニューアルして URL と HTML 構造が変わっていた。 ヤマト、郵便、佐川あたりの主な配送会社の追跡サービスについては、 ブラウザをいちいち開かなくても確認できるよう、自前でスクリプトを書いて使ってるんだが、 HTML を自前で解析してる関係で、 ページの構成が変わると取得する側もロジックを合わせて変えないといけない。 サイトの仕様変更は滅多にないとはいえ毎回ちょびっと面倒だよなあ…などと思いつつ修正したらさくっと終わった。そんなに大変でもなかった。 最近は公式系サイト各方面も、解析の手掛かりを得やすい構造構成に作ってくれるので、昔よりもラクになってるかも…。 なお確認したいブツの荷物番号や配送業者などは別途、決め打ちの設定ファイルに記述しておく。 あとはコマンド一発 (一部伏せ字)。
~$ delivery
ニッセン (yamato) 29****18****
商品名:          ****
お届け予定日時:  -
--------
荷物受付  11月16日 16:32  ニッセン出張所
発送済み  11月16日 16:32  ニッセン出張所
配達完了  11月17日 12:31  EC上池袋センター
--------------------------------
~$
なんのこたァない、POST 投げて返ってきた HTML からテキスト部分を抽出してコマンドラインに出してるだけなんだけどさ。 でもブラウザ起動したり (もしくは新しくタブを開いたり)、 マウス (トラックボール) に手を伸ばしたりクリックしたりキーボードに手を戻したり入力したり、結果表示を見るために画面をスクロールしたり、 という手間がかからないだけでも、ラクチンなんである。 そして確認回数に比例してラクチン感の蓄積がどんどん上がるんである。
ちなみに Amazon の配送情報はスタティックな HTML では取得できず、 puppeteer 使えばいけるかもだけど、 元々あまり細かい情報も拾えないので、 大体の配達予定日だけ把握してあとは確認してない (その配達予定日もたまにアテにならなかったりするし…まあ置き配でいいんだけど。置き配の環境が現状ないけど)。
> 考えてみると Web::Scraper にかなり頼って生活してるなーワシ。 あと puppeteer と。どんな生活だ。

2021-11-18 (Thu)

> 一昨日、文春オンラインからの「ページ内に表示されている画像の保存」が puppeteer でうまくいったので、 現在画面キャプチャの形で保存している某漫画閲覧サイト (というかコミックウォーカー) も、 元画像ファイルを直接ダウンロード (GET) する形に変更できないかな、と思ってちょっといろいろ試し中。
とりあえず、画像の保存自体はできるようになった。 ただ、ムツゴロウさんインタビューの場合、保存したい写真は各ページごとに 1枚ずつの表示だったので、 ページを移動しながら目当ての画像を 1枚ずつ保存していけば表示順と取得順が自動的に一致したんだが、 漫画閲覧サイトの場合は、見開き表示で 1ページあたり最大 2枚表示な上、 先読みで次のページの画像なんかもどんどん非同期で読み込まれるんで、 各ページの表示順と画像データの取得順は必ずしも一致しない (特に最初の方)。 そしてこの表示順を確認する手掛かりが、HTML 内には存在しない…。 いや、ひょっとしたら存在するのかもしれないけど解読すんのがとてもダルい。 ワシのアタマでは、結局別途キャプチャ画面を (ページめくり操作をしながら) いままでどおり取得して、 個別に取得したオリジナル画像データをこれと照合して、 一致していると思われる順に並べ替える、くらいの方法しか思い付かなかった…。
という訳でひきつづき画像照合の実験をこれからする予定 (まだやってない)。

購入記録

  • 雑誌「主任がゆく!スペシャル」Vol.165 ぶんか社
    • 主任がゆく! (たかの宗美)
    • 金髪女将綾小路ヘレン (たかの宗美)
    • 不浄を拭うひと (沖田×華) (ゲスト)
    • 隣のショタがまるで嫁 (道野ほとり) (短期集中連載)
    • 企画:漫画家さんがかつて経験したお仕事を告白! むんこがゆく! (むんこ)
    • 主任作家陣が描く「私のオススメ都道府県」 (佐野妙/おりはらさちこ)
    • 花野さんとの縁結びは難しい (野広実由)
    • 双子コンプレックス (おりはらさちこ)
    • 若奥様は侵略中 (佐野妙)
    • ファニーランドの鬼ババア (むんこ)
    • 群馬犬! (安西理晃)
    • あい・ターン (おーはしるい)
    • マチ姉さんのポンコツおとぎ話アワー (安堂友子)
    • おるすばんごはん (王嶋環)
    • 農学女子 (そめい吉野)
    • 嫁姑は仲良くケンカする (大江しんいちろう)
    • きっこと申します。 (海野倫)
    • ゆるふわと情熱のあいだ (袴田めら)
    • くそじいじとカメラと私 (うず)
    • モノズキ散歩、お茶してうまし♥ (胡桃ちの)
    • それいけ! せっぷく丸 (大塚みちこ)
    • カメのまんねんさん (千石のりお) (ゲスト)
    • 目次4コマ:ゆるゆる4コマ (たぁぽん)
sharp とあるから、シャープネス専用のモジュールなのかと思ったらぜんぜんそんなことはなかった。
まるい。240×240 px。6万色 (ほう)。IPS 液晶。
アーキサイト。 なお価格は 23K あたり…。ややお高いっすな…。 ちょっと試してみたいけど。
ほう。

2021-11-19 (Fri)

> 本日夕方から夜にかけての「ほぼ皆既月食」は予定どおり見そびれた。 最近の睡眠サイクルではそのへんの時間帯には熟睡しているもんで…。 子供の頃と比べて、天体天文に対する興味関心がものすごーく薄れちゃってるな、とさっきしみじみ思った。 ま~、夜空はおろか昼間の空もほぼ見ずじまいな生活になって久しいしなあ。
> スマホ (等) の予測変換をアテにしてとんでもない文章になっちゃった (それをうっかりメールしちゃった)、 とゆーネタをたまに見かけるが、 ワシの場合予測変換をほぼアテにしてないので、 入力がたいへん遅いかわりにその手のトンデモ変換とは今のところ無縁だなあ。 かたくなに使わないというよりは普段 PC の方でまったく使ってないから、 たまにスマホでテキスト入力する時も、 次のフリックはどのキーをどっち向きにすればいいのか、という方にほぼ集中力を奪われて、 予測変換の選択一覧の方に目が行かない…。 そのうち入力に慣れてきたら、予測変換でうっかりトンデモ文章作る機会も増えてきたりするんだろうか。 いやしかしホント使いづれえよなフリック入力… (それ以外も使いづらいけど。結局マトモな配置の物理キーボード以外はどれも使いづらい)。

購入記録

  • 雑誌「週刊漫画TIMES」2021.12/3 芳文社
    • 法廷のファンタズマ (荒川三喜夫)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • パスタの流儀 (原作:花形怜/才谷ウメタロウ)
    • 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • ヘルズボート136 (前田治郎)
    • 村祀り (原案協力:木口銀/山口譲司)
    • 王子とこじき -転生したら名作の主人公でした- (原案:マーク・トウェイン/風町ふく)
    • 拘置ショ! (原作:あしめぐみ/サトウ黒豆)
    • かよちゃんの駄菓子屋 (東元)
    • ヤバい女に恋した僕の結末 (沖田龍児)
跳ね上げ式眼鏡、ってどうなのかなあ。 老眼鏡って、近くを見る時だけ必要なケースが多いし、 近くの物は大体目線が下向きになるから、 むしろずり下げ式の方が…。 でもそんなら自分で眼鏡をずり下げるし。っていう。 そういえば遠近両用タイプって最近のはどうなのかなあ。 昔と比べて進歩してたりするのかな。 いや、一度も使ってみたことないから体感の比較はできないけど。
千石電商 50周年か~。 買い物するとステッカー、5K 以上の購入でマグカップ。ただしなくなり次第終了。 絵柄がなかなかしぶい。50年前のデザインと言われても違和感ないぞ。 そして、絵の向きがやっぱり右利き用…。まあ致し方ないか。

2021-11-20 (Sat)

> 先日、スマホで ffmpeg 走らせるとバッテリががんがん減っちゃうので連続使用はムリ、 と諦めたんだが。 充電ケーブルを換えたら、バッテリ残量がびくともしなくなった。
今まで使ってたのは、Amazon で買った中国メーカー製の、 スマホ側コネクタが磁石でジョイントされてる、360°+ 180° 2軸回転式になっていて脱着と取り回しがラクチンなやつ。 これ一応 Quick Charge 3.0 だかの急速充電にも対応しているらしいんだけど、 どうもいまひとつ接触がよくないかなんかで、しばしば充電がうまくいってない感じになることがあった。 なんかねえ、ちゃんと接続されてるサインも出てるし充電もされてるハズなんだけど、いつの間にかバッテリが減ってるんだよね時々…。 で、それより前に買った、これも急速充電対応の、 ケーブル自体がちょっと固くて (折り曲げ耐久性の関係らしい)、 おまけにスマホ側コネクタが L字型で若干取り回ししづらいケーブル、 どっかやっちゃったと思ってたらちゃんと (普段目にしないところに) 保管してあったのを先日発見したので、 充電状態が安定しないかなあ、と思いつつ、試しにこれに差し替えてみた。 そしたらなんと、というか、案の定というか、 バッテリ残量がいつの間にか減ってたりすることもなくなり、満充電後はケーブルがつながっている限りずっと 100%。超安定。 で、電源供給がこれだけ安定したら、CPU 酷使するような使い方をしてもバッテリ消耗に充電が追い付かなくなるようなこともなくなるのでは…? とふと思って、ffmpeg ぶん回して実験してみたところ、やはりバッテリ残量はびくともしなかった。 そうかーやっぱりあの磁石着脱式ケーブルはイマイチだったか…。 USB Type-C コネクタを何度も抜き差ししてると端子が傷んだりしないかな…という懸念 (杞憂) もあって買ったんだが。 まあ脱着がワンタッチで力もほとんどいらない (着脱時にコネクタにムリな力がかかる可能性が低い) のはよかったんだけど。 やはり利便性よりは安定性だな…。 コネクタの耐久性については…おそらく Type-C 規格策定時に折り込み済だろう。きっと。たぶん。ということにしよう (希望的推論)。
…でもスマホで ffmpeg とかずっと走らせてると本体ものすごく熱くなるなこれ…。 やっぱり現役スマホに連続高負荷作業はあんましやらせない方がいいかな…。

2021-11-21 (Sun)

> 前回の続き。
ブラウザ (puppeteer) から取得したオリジナル画像 (並び順と取得順が一致しない) を、 表示画面のスクリーンショットから別途取得した (順番が保証されている) 画像と比較して、 オリジナル画像の正しい表示順を確定する実験、の結果。 画像の照合は、まずグレイスケールにして、 サイズを 64×90 ピクセルくらいに縮小して (サイズは適当。計算負荷を下げるのとノイズや位置ずれの影響を減らすため)、 各画素ごとの差の絶対値の総和が一番小さかったペアが一致画像、というカンタンな方法で問題なく判定できた。 元々は同じ画像とはいえ取得方法 (取得経路) が違うのもあって、 たとえ同じアルゴリズムで同一サイズに縮小しても各画素の値 (明るさ) にどうしてもずれが生じるが、 それでも不一致な場合の値と比べて一桁小さい計算結果になるので、まあ誤判定の心配はまずなかろう。 拡大縮小以外の余計な加工がない画像同士なのでこんな単純な方法でも判定可能なんだな…。

2021-11-22 (Mon)

> そういえば三井住友銀行の Web サイトが、 今までは毎週日曜 19時から 月曜 7時までメンテナンスでログインもできなかったのが、 昨日 (11.21) から残高照会とか入出金照会とか振込予約とかは原則年中無休で対応するようになった。 やっとかー、という感じだけど。まあ便利になるのは助かる。
一方でゆうちょ銀行は年明けから ATM の入出金に硬貨が混じると手数料取るという絶望的なサービス改悪…。
> 先月タケノコ化が発覚したセロテープ、一度は重石で平らに近い状態まで戻したが、 その後じわじわとタケノコ状態がぶり返し、 結局すっかり元に戻ってテープディスペンサー (ケース) の中で幅いっぱいに突っ張って回らなくなってしまったので、 廃棄処分とすることにした。もったいないがしかたがない。 まあ粘着テープとして使われようが使われまいが、 どのみち最終的にはごみとなって (丸ごとか細切れかにかかわらず) 焼却される運命にあるシロモノではあるのだ…。 ただそれが早いか遅いかというだけのことだな…。 なんの言い訳だ。
…あっ。盛り上がりの幅がケース内に収まる程度までテープを引き出しちゃって捨てちゃって、 残りのテープだけ使うっていう手もあるな…。 というわけでやってみた。 だいぶムダにはなったが、まるごと捨てずに済んだ。 って、タケノコ状のまま使い切ろうと思えばできないこともなかったっちゃなかったんだけどさ…。 なんか、一人“三方一両損”みたいなことやっとるな… (よく分からん)。 ともあれ、これを使い切る前に新しい予備のテープを買っておこう。
一応メモっとこう…。 ワシが試してうまく行った (と思った) 方法…に近い方法は、この記事によるとうまく行かないケースが多くてアカンらしいが。 ダウンロードしたい対象にもよるのかな…。 そういえば目当ての画像データ以外だといろいろエラーとか警告とかたくさん吐いてたかも。 対象を絞れるなら大丈夫、とかかな。

2021-11-23 (Tue)

> 勤労感謝の日。蘇る金狼 (大薮春彦) もしくは金曜ロードショーに感謝。 勤労にも感謝。
> node.js の画像加工モジュール sharp で、 メソッドチェーンで画像の合成 composite に続けてクロップ処理 extract を施すと、 composite の結果のデータではなく元データをクロップした後に合成するっぽいことが判明。 「Composite image(s) over the processed (resized, extracted etc.) image.」 とあるから、resize やら extract やらは乗っけた (合成した) 後の画像に対してでなく強制的に元画像に対して (先に) 適用される、って仕様? 試してみると、.composite().resize() でも .resize().composite() でも、 composite 処理の前に resize がされちゃってるようだから、やっぱしそうなのかなあ。 でも処理がメソッドチェーンの記述順にならないのってなんかすごくキモチ悪いんだけど…。 サンプルコードを見ると、.composite().toBuffer().then((outputBuffer) => {}) みたいなことをしていて、 このようにすれば composite 後の画像を固定 (?) して後続の処理ができるっぽいんだが。 でもな~。とりあえず仕様としてはキモチ悪い感がある。 JavaScript のお作法とかもろもろに慣れてないせいもあんのかしら…。
石の世代はひとつ前。 性能は高いが発熱もすごいらしい。 高負荷をかけるとファンがびゅん回るらしい。 画像処理能力は 11世代 Core i5 の内蔵 GPU あたりとどっこいかちょっと落ちるくらいみたい。

2021-11-24 (Wed)

> javscript の const で宣言した配列は、 push、pop、shift、unshift、splice、やらのメソッドを使った変更なり、要素いっこずつの変更なりはできるが、 他の配列の内容をまるごとコピー (target_array = source_array) すんのはダメなのか。 なんかめんどくさいな仕様…。 単に要素を他の配列の内容で一気に置き換えるのを簡略に書きたいだけなんだが。
結局こんな書き方するしかないのか… (配列はどちらも const)。
target_array.length = 0;
for (const e of source_array) {
    target_array.push(e);
}
しかしこれの実行が OK なら、 target_array = source_array をこれのシンタックスシュガーにしちゃえばいいだけなのにな。 と思うんだが。 もしくはそのようにジブンで関数を書け、またはモジュールを探せ、って感じなんだろうか。 つーか let と const の違いみたいなところが、なんかこうチュウトハンパな気がするなあ…。 たぶん JavaScript の (内部 | 仕様) 事情をあんましよく知らんせいもあるんだろうけど。
Ryzen の型番とか見てもどれくらいの性能なのかとかまったくわかんないぜ。

2021-11-25 (Thu)

> ヨドバシドットコム (以下「淀」) で久々に買い物したら…また…。 debit 使ってクレジットカード払いで支払いをしたんだが。 合計額とか発送ごとの小計額とかが引かれたり戻されたり (なぜかエラーで) を何度か立て続けに繰り返された挙句、 結局購入金額よりも多い合計額が引き落とされたままの状態で放置という。 こんな感じ、前にもあったんだけど、 どうなってんのかね淀の決済システム (もしくは SMBC VISA debit の決済システム)。 前回は問い合わせんのメンドウで 2~3ヶ月ほったらかしてたら戻ったが…。 問い合わせ入れないとアカンかなこれは。メンドくさいんだけど。
実は先日も、淀で買った本が梱包から出した時点で帯が破損していたので (同梱の商品があったんだが、サイズ大きめのクッション封筒の中に、 互いに固定もせず、それぞれ保護もされず、まとめてハダカで放り込まれて送られてきていたので、 裂けた帯の状態から見て、おそらく配送途中で中で同梱品が帯に引っかかった状態で動いて押されて裂けたんではないかと推測)、 サイトトップページの最下 (footer) から「返品・交換」とあるリンクをたどったページの、 問い合わせ先と表示されてるメールアドレス宛に問い合わせメールを出したんだが、 まったくなんの反応もなく、数日後に再送した問い合わせメールにもやはりなんの反応もなく、 仕方なく別の問い合わせ先をサイト内をあちこち探して、 「よくある質問」のページからリンクをたどりたどった先の問い合わせフォームから、 問い合わせ先としてサイトに表示されてるメールアドレスにメールを 2回も出したけどなんの音沙汰もないんだけど、 あの表示されてるメールアドレスはなんなの、メールアドレス表示してるよりここのフォームページへのリンクにした方がいいんじゃないの、 と質問を投げたら、そんなメールは届いてない、ご意見は参考にさせてもらう、的な返事が (丁寧な事務的な文章で) 来たことは来たが、 それっきりだったりしたし…。 それを考えると決済のヘンな挙動も木で鼻をくくったような返事が来てそれでオワリになりそうでヤだな…。
なんか、もう淀で買い物すんのヤメようかなあ…。
> ココロがヨワヨワになってるのか、ちょっとヤなことがあるともうすぐくじける感じだなー。最近めっきり。