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

2022年 1月

(最終更新:2022-1-27)


2022-1-1 (Sat)

> 今年も、古い友人から年賀状をもらった。ありがたい。 毎年ネタが楽しみなんである…。今年もいいネタだった…! 何度か見返して、何度か笑ってしまった…。 そして自分は返信しない奴… (お礼メールはあとで出す)。
> ここ 1~2年くらい、餅はだいたいレンチンして食ってるんだけど、 さっきレンチンしてつゆに投入したが冷めて徐々に固くなってきちゃった餅をもちゃもちゃ噛んでいてふと、 餅の焦げを懐かしむキモチが突然わいてきた。 久々に、焼いた餅をつゆに入れた雑煮が食いたいな、的な。 つゆはめんつゆでいいし、なんなら具がなくてもいいし (己れの手抜きを許す広い心)。 前に使ってた餅焼き網は錆びてだめになって捨てちゃったんだが、また買ってくるかなあ…。 またすぐ錆びちゃうだろうけど。
> ふと、ここのサイトの「リンク集ページ」からのリンク先をザツにチェックしたら、 リンク切れ (リンク先消滅) がいくつもあった…。 うわー。ほったらかしにもほどがあるわね。 ちなみに STUDIO KAMADA の gTLD が .com から .net に変わっていて (全然気づかんかった…)、 元のドメインはなにやらアヤしい機械翻訳な日本語の、カジノがどうのこうのいうヘンなサイトに取られていた…。あらま。 こういうことがありがちなんで、個人的には独自ドメインを取得する気になかなかなれないんだよなあ。 一度取得したら死ぬまで使うくらいのつもりでいないとイカンような気がして (死んだ後のことまではさすがに個人レベルではちょっと手に余る)。 まあ、ほとんどの人は (個人法人公的機関問わず) そんなことまで考えずにわりと気軽に取ったり放棄したりしてて(*1-1)、 でもってそれに伴うこの手のヤな感じな事象もそういうもんと諦めたり特にヤとも思わなかったりで受け入れてるんだろうけど。 あとアレだ、後からドメインを取られてヘンなサイト作られるのがリスクになるかどうかは、 元のドメイン (のサイト) がどれだけ広く利用・認知されてきていたかにもよるだろうから、 ウチなんかの場合はそのへんほとんどリスクにもならないだろうなとは一応思うんだけど。
というわけで、気まぐれリンク集を久々に、ザツに修正した。 完全に全てのリンク先が健在か確認してない…。 利用者もほぼいないだろうから実害もほぼなかろうしザツでいいや、という。
Twitterはアカウントがなければつぶやくことはできませんが、アカウントがなくても公開されているつぶやきは見ることができます。しかし、2021年8月からツイートの表示にログインを義務付ける仕様が導入されており、アカウントがないとスムーズにTwitterを閲覧することが難しくなりました。

蛇足的脚注

*1-1 : 気軽に
もちろん、全部が全部気軽にやってるとは思ってないけど。 止むを得ない事情なんかもいろいろあるだろうし…。 でもせめて公的機関はもう少し、ドメインや URL を一度決めたらコロコロ変えないように気を配って欲しいなと思ったりする。

2022-1-2 (Sun)

> 「本番環境でやらかしちゃった人 Advent Calendar」とか読んでると精神削られますな…。 先月下旬あたりから読み始めていた Qiita の Advent Calendar (のうち自分で Feed チェックしてたやつ) をやっとぜんぶ読み終えた。 かなりの量読み飛ばしちゃったけど…。 世の中、ワシのアタマでは理解がむちかちい難易度のぎじゅちゅがこんなにいっぱいあるんだなー。と思いながら。
> Google の連絡帳と連動しない電話番号簿とダイアラー、 はその後、F-Droid を探してみたら他にもいくつかみつけた。 …が、しかしいずれも個人的にこれは許容できないなーという部分がどうしてもあって、 乗り換えに至らず。 発着信履歴の表示を横になでたら勝手に即座にダイヤルしちゃうとか (事前に確認求めろやボケが。夜中だからよかったけど某銀行のカスタマセンターに 2回も電話しちゃってたよすぐ切ったけど)。 日時表記のフォーマットが欧米型 (「日/月/年 時/分」) に固定で読みづらいのに変更できないとか、 Contact List も日本語の名前順やよみがな (順番並べ替えに必要) に完全非対応とか。 まあねえ、Open Source なんだから自分で改造して使うとかさー (ライセンス的に OK なら。ていうかたぶん OK じゃろ)、 あるいは作者に要望出すとかするのがスジなんだろうなーとは思うんだけどさ。 どっちも難易度高そうだしねえ。英語できねえし。
> で、なんとなくあちこち情報を漁ってたら、 スマホの Android の「連絡帳」(Google 製アプリ、連絡先データ管理) のデータ (これは実際には Android 内に保持された連絡先 DB の内容であり (たぶん)、 「電話」(Google 製アプリ、電話発着信管理) の発着信履歴表示とも連動している) を、その Android で使っている Google アカウントのコンタクトリスト (「Googleコンタクト」または「連絡先」、Google アカウントに紐付けされた連絡先データ) とは同期させない設定にできるっぽい…。ええ…? ホントに? つまりスマホ内で使う「連絡帳」 (のデータ) はスマホ内で閉じた状態のまま使えるってこと? ホントに? ワシ、Android の Google 製アプリの「連絡帳」のデータは、 どう頑張っても Google アカウントの「連絡先」(Google コンタクト) と一心同体・表裏一体で、 切り離して使うことは原理的に不可能なシロモノだと思っとったよ…。 つーか…。 そもそも機能が違う (らしい) もの同士の名称が似てたり、同じ機能なのに違う呼び方がついてたり、 分かりにくすぎるんじゃ、それぞれ違いが分かりやすい名前にした上でサービスごとに名称を統一せいやボケが。 と言いたい。 ついでに言うと英語での各サービスやらアプリやらの名称と日本語表記との対応もいまいちはっきりわからんしなあ…。 まあそうは言っても、スマホ内で閉じた状態で使っているつもりの「連絡帳」のデータが、 実は裏で Google によって巧妙に勝手にドコカ知らないところへコピーされてたり同期されてたりする可能性は、 あるんじゃねーかという疑いはどうしても捨てきれないが。Google あんまし信用してないから個人的に。 しかし表向きだけでも (少なくともユーザや第三者の目から見て) スマホ内に閉じ込めた (独立した) データとして扱えるってんだったら、 もうこの際 Google 標準の「連絡帳」と「電話」で済ませちゃってもいいかな…という気にちょっとなってきた…。 いつまでたってもワシ的に理想的なダイアラーや発着信履歴管理 (表示) や連絡先リスト管理のツール (アプリ) が見つかる見込みも立たないし。 つっても Google 製の「連絡帳」や「電話」もいまいち個人的にはビミョウ感が拭えないシロモノではあるんだが… (同一番号相手の発着信履歴の表示をかってに 1行にまとめちゃっていちいち 2タップして表示させないとバラの表示が確認できないとかさ… だからユーザに選択させろっての。 日時表示も、年表記をヘンに略そうとするから「何年の」何月何日なのかぱっと見分かりづらいし…そしてこれまた設定で変更できないし。 発着信履歴のバックアップやエクスポートの機能もついてないし…)。 それでもそもそも使用頻度ゼロに等しいんで、それでストレスが蓄積する心配はほとんどないし。 まあメーラに関してはもうイイ奴をいくつも見つけてるんで Gmail アプリは使わんけど。 メーラも決まった送信元からのメールの受信しかしてないから、それこそ「連絡帳」のデータなんかと連動させる必要も皆無だしね。
しかし、そうかー…。
これはなかなかの地獄。そしてあるある…。
二分探索。動的計画法 (DP)。グラフアルゴリズム。ソート。データ構造。数理最適化。数学的アルゴリズム。
まず普通に apt でパッケージの nodejs と npm をインストールする。
sudo apt install -y nodejs npm
次にこれで n package をインストールする。
sudo npm install n -g
そして n package で node をインストールする。(↓以下では最新安定版を指定)
sudo n stable
最初に入れた nodejs と npm を消す。
sudo apt purge -y nodejs npm
そして再ログイン。
exec $SHELL -l
いちおうバージョンを確認。
node -v; npm -v
自前で立てる feed reader (RSS reader)。Go で書かれていて要 PostgreSQL。debian (ubuntu) 系ならパッケージでインストール。
きめえ。
加害者、被害者、観衆、傍観者、いじめの四層構造。 主催の DOMMUNE のちょっとふわふわしたアレさ具合。

2022-1-3 (Mon)

> でん六ポリッピーは…悪魔の豆じゃあ… (スモークベーコン味と 4種のチーズ味)。
> Android では「連絡帳」(のデータ) をデフォルトで使うとして… 「電話」の方の発着信履歴のバックアップ (というかエクスポート) 機能がないんで、なんかいいアプリないかな、とあれこれむやみに検索してみた。 Google Play ストアとか… F-Droid とか… Web で情報漁りとか…。 しかし、必要十分な仕事をするアプリがなかなか見つからん…。そんなに高難度な仕事でもないと思うんだが…。 バックアップ取ったら、そのアプリ専用の外から見えないディレクトリにデータ書き込んでオワリのやつとか (そのアプリを使って“リストア”する以外に、バックアップデータを取り出す方法を用意してない)。 履歴内の電話番号と名前の対応が取れてなくて別人の名前になってるやつとか… (動作チェックしてないんだろうか)。 広告が限度を超えて鬱陶しいやつとか… (ちょっとなにか操作するごとに 15~30秒の動画広告表示 + [×] ボタン押され待ち×複数回 + 押す箇所が [×] ボタンからちょっとずれたら速攻でインストール画面へ寄り道、の繰り返し)。 いろんなモンのバックアップをあらいざらい面倒みるヨンつってありとあらゆるアクセス権限を要求してくる (バックアップ対象を選択できない、ひとつでも権限を無効にするとそのまま終了する) やつとか…。
そういえば termux:api で通話履歴の取得コマンドがあったかも、と思って見てみたら、 termux-call-log というのがあった。 しかしアクセス権限を与えて実行してみたが、なにも表示されない。 Android 側の仕様が変わったかなんかで履歴が取れなくなってんのかね…よくわかんないや。 これが使えれば一番ラクにコントローラブルに履歴の取得と保存ができたんだが。
結局、「SMS Backup & Restore」という、SMS 履歴の他に発着信履歴にも対応している広告付のバックアップアプリで、 定期的に Dropbox へ投げる設定にして使うことにした。 広告もただ操作画面にバナーで表示されてるだけでそんなに邪魔でもないし。
なお、出力されるデータは UTF-8 (BOM なし) の XML ファイル。 実際の出力は 1コール分につきこんな感じ。
<call number="117" duration="9" date="1605500000608" type="2" presentation="1" subscription_id="xxxxxxxx" post_dial_digits="" subscription_component_name="com.android.phone/com.android.services.telephony.TelephonyConnectionService" readable_date="2020/11/16 13:13:20" contact_name="(Unknown)" />
(subscription_id は実際には数字 19文字 + アルファベット 1文字だったけど念のため伏せといた)
属性意味備考
number電話番号非通知着信の場合は空
duration通話時間
date通話(開始)日時UNIX時間 : ミリ秒
type発着信種別
1着信
2発信
3不在着信
presentation
1番号通知
2番号非通知
subscription_id不明
post_dial_digits不明通話開始以後の DTMF 操作の記録?
subscription_component_name通話した回線(サービス)の種別?
readable_date人間に読みやすい日時秒単位まで
contact_name通話相手の名前「連絡帳」と連動、不明の場合は "(Unknown)"
たぶんこんな感じだろうと思う (書式の説明ももしかしたらアプリのヘルプかサイトにあるかもしれないけど見てねえっす)。 とりあえず number、date (readable_date)、duration、type、contact_name が分かれば十分。
> そもそも、手元の端末から通話履歴を保存する、なんてのは PHS 使ってた頃は不要だったんだよな。 毎月分の通話履歴明細を Web サイトから PDF でダウンロードできてたから。 それがスマホに切り換えたとたんに、詳細な通話履歴のログがまったくダウンロードできなくなった。 ダウンロードメニューみたいなページまではたどりつけるが、 明細を取得しようとしても、仮にどんなに電話した月でも「ご提供可能な通話明細書はございません。」と表示されるのみ。 なんなんだこれ。 元々 PHS の方のユーザサービスのシステムはどうやら Willcom のシステムをそのまま引き継いで使っていたらしく、 今の、ソフトバンクで作ったらしいスマホの方のユーザサービスのシステムと比べて細かいところで出来がよかった…。 ような気がする。 スマホ (ソフトバンク系) に切り替わったとたんキャリアメールの使い勝手とかも劣化したしな。いやホント。 こんなんだったらもうキャリアメール (MMS) アカウント要らねーやと思っちゃうくらいには。
> 今日もぶつぶつ言って終わった。よし。

2022-1-4 (Tue)

> スマホ (Android) の「連絡帳」アプリが、 Google のサービスの「Google コンタクト」(または「連絡先」) と同一のもので切り離せない、 と思い込んでいた理由がわかった。 Google Play ストアで「連絡帳」を見ると、アプリ名が「Google コンタクト」になってたわ。これのせいだわ。 これを最初 (1年ちょっと前) に見て、同じモノと思っちゃったんだな。たぶんそう。 そういや Google 製のアプリ名って Google のサービスの名前そのまんま使ってたり使ってなかったりするが、 サービス名とアプリ名が同一でも挙動は分離してたりしてなかったりするんだよな…。 Google Photos とか。そんな感じで、アプリのなにをどう操作するとどこのなにがどうなるのか、が極めて分かりにくい。 分かりにくいっていうか分からない。そもそも仕様変更で挙動もわりと無節操に変わるし。 それで Google サーバのデータと手元 (ローカル環境、PC やスマホ内) のデータの関係性もいまひとつようわからんのだ。 「連絡帳」もその類だったのか。 いやーそうか。ワザとやってんのかねこれ…?
インボイス制度の「インボイス」は、普通の請求書ではない
その「普通」でなさがひどい。 どんだけ絞り取りたいんだ。
今ドラム式洗濯機高いのね…。 ずっと昔に買った時は、これから先どんどん安くなっていくだろうなーとか思ってたのに。 逆に高くなってるのか。

2022-1-5 (Wed)

> そういえばさいきん、 「サチコと神ねこ様」 のタイトルの「第○○回」の表記と実際の回数 (話数) が、ずれなくなったなあ。 過去には時々かなり盛大に途中を抜かしたり、ダブったり、飛んだり、してたんだが…。 やっと、回数カウントを正しく補正する (もしくは事前にチェックする) 仕組みを入れたのかな。
> 10万前後くらいでメモリ 16GB かできれば 32GB 積んでて SSD は最低 500GB…できれば 1TB…まあ自分で換装すればいいか… で接続端子いっぱいついてて (USB は特に) できたら NVIDIA あたりの GPU 積んでるノート PC はないかな。 値段的にムリか。 モニタは外付使うからそんなに高品位でなくていいけど (じゃあノート PC でなくてもええんでは、とも思うが瞬断とか考えると…)、 CPU まわりの性能は GPU 使わないでも 4K あたりがぬるぬる再生できてくれるのがいいな。 今のやつは 4K あたりでちょっと高ビットレートだとつっかえるんだよね… (MPC BE 使用)。 CPU 性能のせいかどうかはわからんけど…。 OS は今からだと Win 11 あたりになるんだろうけど… Win はもういいかなあ…なんとなく。 Linux で使うんでもいいような気もするんだよなあ…もう。 Arch Linux あたりとか。まだ使ったことないんだけど。

購入記録

  • 雑誌「まんがホーム」2022.2 芳文社
    • らいか・デイズ (むんこ)
    • 若王子主任は後輩ボイスに抗えない! (おりがみちよこ)
    • 孔明のヨメ。 (杜康潤)
    • 天下分け目の小早川くん (真田寿庵)
    • 恋はリベンジのあとで (辻灯子)
    • 天国のススメ! (宮成樂)
    • 座敷童子あんこ (エミリ)
    • 先輩に推されて仕事になりません! (あしや雅浩)
    • ヲトメは義母に恋してる (桐原小鳥)
    • 幽霊さんのための科学的新仮説 (いわとびひろ)
    • 俺と式神の主従契約 (都ウト)
    • オレの愛で世界がヤバい (井上とさず)
    • ラブアマ (有村唯)
    • ぼくの上目遣い (市川なつを)
    • 魔界の愛されCEOは元勇者 (さーもにずむ) (新連載)
    • 菓子男リノベーション (胡桃ちの)
    • スナックあけみでしかられて (松田円)
    • 歌詠みもみじ (オオトリキノト)
    • うちの秘書さま (ミナモ)
    • ウメボシオニギリ (よるどん)
    • もんもん (熊野みみ)
    • 目次4コマ:お屠蘇 (杜康潤)
  • 雑誌「まんがタウン」2022.2 双葉社
    • 新クレヨンしんちゃん (臼井儀人&UYスタジオ)
    • コミックエッセイ特集~2022年への意気込み~ (ÖYSTER/おりはらさちこ/小坂俊史/大場玲耶/ふじた渚佐/瀬田ヒナコ)
    • 押しかけギャルの中村さん (おりはらさちこ)
    • 猫またはごはんを。 (湖西晶)
    • 新婚のいろはさん (ÖYSTER)
    • ルナナナ (小坂俊史)
    • ねこ上司といぬ部下くん (原作:DK/橙夏りり) (新連載)
    • あさひ大家族 (ふじた渚佐)
    • 野原ひろし 昼メシの流儀 (塚原洋一)
    • かりあげクン (植田まさし)
    • 食欲しか勝たん! (えきあ)
    • 兎なりのウサギさん (野広実由) (ゲスト)
    • 勇者様!? こ…これってそういう意味ですかっ!?♥ (大場玲耶)
    • 相方が俺を好きすぎる (パン崎まろやか) (新連載)
    • 大越春太郎は黙れない! (瀬田ヒナコ)
    • 恋がわからぬ大人共 (赤のキノコ)
    • かのんとぱぱ (おーはしるい)
    • 鎌倉ものがたり (西岸良平)
    • あの世で猫になる (東屋めめ) (ゲスト)
    • 淑女の笑顔は崩れません (佐野妙)
    • ママはパートマスター (田中なつ) (シリーズ連載)
    • んじゃま、ここらでお茶にしましょうか。 (胡桃ちの)
なつかしの Super MZ。グガーグガー (←オーナならわかる)。 Super MZ や X68000 の広告写真を見ると、Oh!X の紙のにおいとパリパリ感まで思い出すね。 CPU が高速版の Z-80B (6MHz) で、 ソフトウェア (搭載 BASIC) も 8bit CPU のくせに (クロック差を考えても) かなり高速だったが、 DMA を積んでおらず FDD 制御はぜんぶ CPU がやる仕様だったので、 FDD アクセスするたびに一瞬 CPU の他の処理が止まる、という面白い欠点があった (このへん認識がちょっとザツかもしれない)。

2022-1-6 (Thu)

> さみいと思ったら雪降ってますがな…。
> そういやー、MS が Windows 10 用に Linux 環境を用意してたんだっけ…。 あれってどんな仕様なんだっけ…? と (Windows 10 以降のダーティな情報以外に関心がわかなくて完全スルーしてたのを今頃) さくっと検索してみた。 なるほど WSL (Windows Subsystem for Linux) か。 WSL と WSL2 があって実装方法 / 動作方法が違うのか。 プロセスフォークやファイルアクセスは cygwin よりは速い、と (遅かったらびっくりだけど)。 枯れ具合は cygwin に一日の長があるっぽい (この場合の「枯れ」とは安定して変化がないこと。良い意味)。 ほんとかな… cygwin でアップデートかけると動かなくなったりおかしくなったりけっこうしてたんだよな…。 それでウチの環境はある時期からアップデートすんのやめちゃったんだけど (Perl や ImageMagick なんかがアップデートするとマトモに動かなくなってにっちもさっちもいかなくなってた。 そして延々と放置されてた。そして次のアップデートでもぜんぜん直らなかった。etc.)。 まあ 32bit 版なせいの可能性もあるからなんともいえん。
ちなみに cygwin の目的というかキモは、Windows 上で unix/linux (互換の開発環境) を使うこと、ではなく、 unix/linux 互換の (CUI) ツール類で Windows (上のファイル) を操作すること、なんだが、 WSL の用途は後者 (cygwin) に近いが WSL2 は前者の方らしい。なるほど。 もし機会があって試すなら WSL か。 さもなければ cygwin を選択、でよさそう。
> ストロング小林 (引退後、ストロング金剛) 氏の訃報。12.31、81歳。のう肺。
なるほどー (っていまごろ言ってる cygwin 使用歴 20年の奴)。
WSL2 は Windows Subsystem じゃなく軽量VM。
たとえば css-mode の場合、インデントをスペース 2文字にするには、lisp/css-mode.l の中に
(defvar *css-indent-tabs-mode* nil)
を (しかるべき箇所にてきとうに) 追加し、
(defun css-mode ()
内に、
(make-local-variable 'indent-tabs-mode)
(setq indent-tabs-mode *css-indent-tabs-mode*)
を追加し、.xyzzy (か site-lisp/siteinit.l) に
(set *css-indent-level* 2)
と記述。その後 *.wxp などのダンプファイルを削除したり byte-compile をやり直したりしておく。
個人的にインデントはスペースじゃなくタブ派だが、参考のメモ。

2022-1-7 (Fri)

> うちの近所は雪が降ってもごく一部の家を除いてみんな道路の雪掻きしないんで (しない奴筆頭による証言)、 昨日の積雪が夜のうちに凍って道路がいつもどおりパリパリのガチガチのツルッツルになった。 これは歩くとあぶない。しばらく外出は控えた方がいいかもしれん。 まあ降り止んだのが日が暮れてからで、雪掻きしてる間もなかったしね…。 でもって日当たりもよくないんで一度凍ると溶けないんだよなこれがまた。 道路用砕氷靴とかがもしあったら、そこらじゅうの路面の凍結を割って歩いて回っちゃうんだけどなあ。 …と思って試しに検索してみたが、滑りにくい靴はあってもさすがに砕氷靴ってのは見当たらなかった。 あるいは鉄のかんじき履いて歩くとか…。でもそれで舗装路歩いたら道路が傷むか…。 それに、かんじきとかはそもそも滑らないようにするためのもんだから、氷を割って歩くのは難しいか。 やってみたことがないんで分からんが。 しかしどうしたもんかなーこの凍結路面。 舗装路とはいえ、むやみに塩を撒いたりするのもナンだしねえ…。 夜中にこっそり撒いたらバレないかな? (そういう問題じゃない)

購入記録

  • 雑誌「まんがタイム」2022.2 芳文社
    • おとぼけ部長代理 (植田まさし)
    • ローカル女子の遠吠え (瀬戸口みづき)
    • 花丸町の花むすび (むんこ)
    • ラディカル・ホスピタル (ひらのあゆ)
    • 大家さんは思春期! (水瀬るるう)
    • レーカン! (瀬田ヒナコ)
    • 軍神ちゃんとよばないで (柳原満月)
    • 百合のあいだは悩ましい (森井暁正)
    • 六畳一間の憑き物石 (西岡さち)
    • 冷めないふたりのひとりご飯 (きたむらましゅう)
    • テレパス皆葉と読めない彼女 (諸田トモエ)
    • 茨城ってどこにあるんですか? (真枝アキ)
    • 女神に胃袋つかまれた! (町田すみ)
    • この契約は恋まで届きますか? (雪尾ゆき)
    • お酒は20日になってから!! (えのまなみ)
    • 瀬戸際女優! 白石さん (櫻井リヤ)
    • 秘密のお姉さん養成ノート (トフ子)
    • 午前0時のおねだりごはん (あきさと)
    • 良倉先生の承認欲求 (G3井田)
    • お天気おねえさんの晴れ舞台 (きなこ)
    • 新人まんが展:うちの猫なんですっ!! (梯図ミキヤ)
    • 目次4コマ:つながれ! 黒電話ちゃん (瀬田ヒナコ)
  • 雑誌「週刊漫画TIMES」2022.1/21 芳文社
    • 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • まどろみバーメイド (早川パオ)
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • ごほうびごはん (こもとも子)
    • 経理の夏谷さんはガマンできない (財政ろろ)
    • 神客万来! (ねむようこ)
    • ヘルズボート136 (前田治郎)
    • 王子とこじき -転生したら名作の主人公でした- (原案:マーク・トウェイン/風町ふく)
    • 夜空のふたりキャンプごはん (春露彗) (短期新連載)
    • ヤバい女に恋した僕の結末 (沖田龍児)

2022-1-8 (Sat)

> この寒さで…今冬は電気代がちょっと心配…。 あれ、毎年心配してるかな…?
> コクヨのひっつき虫、というのを試してみた。 練り消しみたいな感触の、ソフトタイプの粘着剤。 適度な量をちぎってこねて、貼り付けたい部分に押しつけて、その上から貼りたい物を貼る。 ざらざら・けばけば・でこぼこ・汚れている箇所には使えないが、 なかなかちょうどいい粘着力っぷりで紙など勝手に剥がれないし、ひっつき過ぎない。 剥がそうとしたら紙が破ける、なんてこともない。 …というか、少し前に両面テープ使って貼り付けたら剥がす時に紙が破れたので、 これは両面テープではイカンわ、と思って今回試しに買ってみたんだけど。 あとは、長期間使った時に粘着剤がどう変化するかだな…。 これも実際にしばらく試してみないとわからんな。 紙だの布だのにはシミがつく (場合がある?) らしいけど。
ところでこれ、2016年の時点で日本発売 40周年だったらしい。 そんなに昔から売ってたんか…。
たまたま、久々に vivaldi のサイトを開いたら、なんかずいぶんにぎやかでとんがったサイトに様変わりしていた…。 なんかすげえな。若干のヤケクソ感を感じなくもない。 こういう心意気 (?) とノリは嫌いじゃないけど、 vivaldi は起動があまりにもクッッッソ重いんで使わなくなって結局アンインストールしたんだよなあ。 バージョンが上がってあれからそのへん改善してたりするんだろうか。

2022-1-9 (Sun)

> Android の Google 製「連絡帳」で、Vcard 形式ファイルのデータをインポート・エクスポートすると、 電話番号のハイフンの位置が勝手に入れ替わることがある。 たとえば、
BEGIN:VCARD
VERSION:2.1
N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:=E3=83=AA=E3=82=AB=E3=81=A1=E3=82=83=E3=82=93=E9=9B=BB=E8=A9=B1;;;;
FN;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:=E3=83=AA=E3=82=AB=E3=81=A1=E3=82=83=E3=82=93=E9=9B=BB=E8=A9=B1
X-PHONETIC-FIRST-NAME;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:=EF=BE=98=EF=BD=B6=EF=BE=81=EF=BD=AC=EF=BE=9D=EF=BE=83=EF=BE=9E=EF=BE=
=9D=EF=BE=9C
TEL;WORK:033-604-2000
END:VCARD
これは「連絡帳」(の「共有」) からエクスポートした「リカちゃん電話」の番号のデータだが、 「03-…」で始まる (ように書いていた) はずの番号が「033-…」になっている。 これをエディタで「03-3604-2000」に直して、 「連絡帳」の該当データを削除しておいてから、改めてこのデータをインポートすると、 「03-」に直したはずの番号がまた「033-604-2000」に戻っている。 なお、元は PHS 機のアドレス帳から Vcard 形式でエクスポートしたものをインポートする形で登録したんだが、 元のデータでもちゃんと「03-…」となっていた。 それをインポートした時点で「033-…」に勝手に変わっていたのを、スマホ上で修正してあった。
文字化けならまだ分かるが、なぜハイフンの位置を「勝手に」変えるのか? それも必ずではなく、変わるデータと変わらないデータがある (法則性は今のところ不明)。 バージョン 11 にもなろうという Android の標準搭載の、 電話やメールというスマートフォンの基本中の基本な機能に言わば必須なアプリの、 データのインポートやエクスポートというこれまた基本中の基本な機能でこんなクソバグが放置されてるって、 ある意味すげえよな…。 もちろん、発呼時にハイフンは単に無視されるだけなので、どこについていても電話するのに支障はないといえばないが。 逆に、電話するのに必要ないハイフンをなぜわざわざ、人間が「その位置に」入れている、と思ってるんだろう。 このインポート / エクスポート機能の設計・実装者は。
という訳で発着信履歴のログ保存時に相手の情報 (名前) を反映させようと、 「連絡帳」にひととおりデータを流し込んであったんだが、 なんかもうイヤになったので (いつものようにイヤになる閾値を瞬間突破したので) スマホ内の「連絡帳」データは結局さくっと全削除した。 どうせ電話する時の操作はぜんぶ PHS 機 (Bluetooth 子機) でやるから問題ないわ。 PHS 機からは発着信履歴を外部へ保存できないのが難点だけど。 履歴データは Android からエクスポートして、 別途用意した自前の電話番号データと照合して相手の名前情報を埋めればいいや。 ちょっと手間だけど… (つっても手間と感じるほど電話使わないからぜんぜん大丈夫だけど。むしろ頻度が低すぎて逆にメンドくさいくらいな)。
いやーしかし、なんでこんなことになるんかね…? 他のユーザのところではこんな現象は起きてないのか? ちょっと検索してみたけどよくわかんなかったんだけど (ハイフンの位置がおかしくなる、という質問めいた書き込みに誰も答えてないとかそんなのがちらほら程度)。 こういう現象は稀にしか起きてないのか (いわゆる「おま環」なのか)、 あるいはある程度頻繁に起きてはいてもみんな、そーゆーモンだと思って特に何も言ってないだけなのか…。 それともまったく気づいてないのか。あるいはハイフンとかぜんぜん使ってないのか…?
> というか、 なんでハイフンの位置が勝手に変わるのかのメカニズム (原理) がゼンゼン見当つかないのがかなり気持ち悪いんだよな…。 国によって電話番号の並び (区切り) のパターンに違いというか特徴というかクセがあるあたりが原因なんだろうか。 それにしたってなぜ「勝手に」変えるんだ。Google だからか? それとも開発者の意図してない挙動なのか? うーんわからん…。 普遍的現象なのかどうかもわからんからなあ…。
あと、現時点でちゃんと照合チェックしてないんだが、 電話番号のハイフン以外の箇所のデータも「勝手に」書き換わっている可能性はないだろうか…? こんな分かりやすい箇所が勝手に書き換わってるくらいだから、 「電話かけるのに支障がない」範囲の勝手な書き換えを他でもやってるかもしれない、 というイヤな予感がなんとなくしなくもないんだよな…。 フツウはそんなバカなことはやらないだろうと思いたいところなんだけど、 そのフツウじゃないことを電話番号のハイフン位置の勝手な書き換えで実際にやってる訳だからなあ…。
> で、スマホ上で発着信履歴をニンゲン (ワシ) に分かりやすい形で表示するだけなら、 先日導入した履歴の自動バックアップツール (の出力データ) を自前で適宜表示調整して、 ローカルで閲覧できる形のデータに整えてやる仕組みは、termux 上でなんとでもできるだろうとは思う。 最大、丸 1日 (バックアップ間隔) の遅延は生じるが。 発呼の方も、自前で HTML か CGI あたりで電話番号リスト一覧でも作って、 そこから電話することもできるし (これは実験済)。 ちょい不自由かつ不便かつ面倒ではあろうが、いわゆる「アプリ」を開発するまでもない。 という訳で、気が向いたらそのうちぼちぼちやろう。 今はどうせ電話の使用頻度低すぎて自分で恩恵を感じる機会も来そうにないのでモチベーションがわかない (まあ結局そんな程度の影響なんだけどな…個人的には)。
> こういう時、Android を使っている知り合いなり友人に、同じ現象が起きてるかどうかちょっと聞いてみる、ということをしないのは、 現在そんな風に気軽にちょっと聞いてみることができる状態の知り合いなり友人なりがいないからなんだな。 ということも改めて確認した。 なお、スマホ方面は日本人の場合 Apple 率がやたら高い、というのはこれに関してはあまり関係ない。

2022-1-10 (Mon)

> 成人の日。フォッフォッフォッフォッフォッ (生誕 56年目)。
> スタティックな Web ページを無料で (初期費用・維持費なしで) 公開できるサービスをぼちぼち探している。 できれば広告とかがつかないやつがあれば、と思うが無料だとなかなかそうもいかないだろうな。 と、思っていたんだが。 今は GitHub の GitHub Pages なんていうサービスがあったんだな。 引きこもりジジイ脳なんで、FC2 とかあっち系しか思い付かなかった…。 これってでも、変更履歴もそのまんま公開されちゃうのかしら…。 そうだとすると若干潜在的なキケンがなきにしもあらずかな… たとえばうっかり個人情報を上げちゃったなんて時に困りそう…。 いやたぶん、履歴から特定の範囲を完全に削除する方法もあるんだろうと思うけど、 Git のシステムをあまりよく把握してないもんで…。 それはあとで調べよう。
同様のサービスで Netlify なんてのもあるのか…これもあとで調べよう… (後回し名人)。 探せばもっとあるかも…。
他には Google Sites あたりも利用できそうかなあ。 と思ったんだが、これで生成したサイトをまとめて保存 (エクスポート) するのに Google の Data Export サービスを利用するんだけど、 手元にダウンロードして見てみたところ、 HTML が 1ページあたり最低でも 1MB 食うような、わけわからんタグで膨れ上がった代物になってしまっていたので、 ここで作ったサイトをよそへ引っ越す時には往生しそう…。
あとは、サービスの持続性 (継続性) だなあ。 数年後には終わっちゃったり有料化しちゃったり仕様や規約が変わって使い続けられなくなっちゃったり、はなるべく避けたいんだけど。 そういう点では Google のサービスはあんまし信用できないんだよな…。
> あとはスタティックな Web サイトを自力で構築するのに、 GUI にこだわらなければ使えそうなツール類がいろいろあるっぽいなあ。 Static Site Generator (SSG) とかいうジャンルで。 そうかー。 もうちょっといろいろ探してみよ。
Ruby 製。
これは Python。
これは Perl ベース React ベース (つまり JavaScript ベース)。
Perl ベースの SSG 各種。

2022-1-11 (Tue)

> じわじわとゆるゆるになってきていたジーンズの腹まわり、 ふと気づくとゆるゆる度がじわじわと減ってきている…。 まあ、冬だからね… (と暖房がんがん利かせつつ)。

購入記録

  • 雑誌「ヤングコミック」2022.2 少年画報社
    • 淫魔乙女の胸のうち (ぷらぱ) (新連載)
    • まぐわい部屋の管理人さん (東雲龍)
    • おねーさんが侵略中!? (さんりようこ)
    • ヤンキー娘になつかれて今年も受験に失敗しそうです (ジェームスほたて)
    • よいこは見ちゃダメ (佐伯)
    • いいわけも出来ない -姉彼- (水島空彦)
    • 31歳地味眼鏡OLさん (新居さとし)
    • ツボネノツバメ (zen9)
    • スカートの裾掴むボクの手が今も震えてるのは…… (佐野タカシ)
    • 湯けむり慕情・必殺掌! (桂よしひろ)
    • 元女勇者35才 (蛇光院三郎) (最終回)
    • 見たいもの見せましょう (たまはがね)
    • 少年画報社版 人物日本の歴史 三峯徹 (金平守人/監修:稀見理都)
  • 雑誌「まんがライフオリジナル」2022.2 竹書房
    • リコーダーとランドセル (東屋めめ)
    • ちぃちゃんのおしながき (大井昌和)
    • 晴れのちシンデレラ (宮成楽)
    • のみじょし (迂闊)
    • 雑兵めし物語 (重野なおき)
    • しょうもないのうりょく (高野雀)
    • ずぼら先輩とまじめちゃん (東385)
    • ねこようかい&ねこもんすたー (ぱんだにあ)
    • よそじとふたごのメシ事情 (小坂俊史)
    • ここは鴨川ゲーム製作所 (スケラッコ)
    • となりの席の同居人 (神仙寺瑛)
    • なごみクラブ (遠藤淑子)
    • 黒影夜子の駐在日誌 (唐草ミチル)
    • 森田さんは無口 (佐野妙)
    • おんぼろ花ハイム (むんこ)
    • 鬼桐さんの洗濯 (ふかさくえみ)
    • ハッピーアワーガールズ (揚立しの)
    • ネコぐらし (深谷かほる)
    • ばつ×いち (おーはしるい) (最終回)
    • 中年女子画報 (柘植文)
    • もぐもぐガーデン (宇仁田ゆみ)
    • ギャル医者あやっぺ (長イキアキヒコ)
    • セトギワ花ヨメ (胡桃ちの)
    • そしらぬディスタンス (松田円)
    • とーこん家族 (よしもとあきこ)
    • ぼのぼの人生相談 (いがらしみきお)
    • 異世界にマンガ家が転生したらどうなるのか、描いてみた件 (柏木香乃)
    • 全ての映画は、ながしかく (施川ユウキ)
    • 目次4コマ:ポポ時評 (施川ユウキ)
けっこう長いこと連載してたんだなあ…。
2008年の記事。 さくらのレンサバ (スタンダード)、契約した頃 (2005年 5月) の容量ってどんくらいだったんだっけ…と思ってちょっと検索してみた。 2008年に 1GB が 3GB に増量、になってるな…。てことは当初は 1GB だったか。 当時のライトプランの容量 (300MB) だと「俺ニュース」アーカイブのコンテンツ置くのにちょっと足りなくて、 仕方なくスタンダードプランにしたのは覚えていたんだが。 今のスタンダードプランは 100GB なんで容量余りまくってるんだよな。 でもってライトプランも容量 10GB あるから、今ならそっちに移行してもぜんぜん足りるわ。 でもライトプランは ssh でログインできないから使うのに不便なんだよね…。 あと、契約で容量だけ変えるってのができないから、一旦解約して改めて契約し直すことになって、 使えるドメイン (サブドメイン) も変わっちゃうしね…。 さくらはこういう不便なところがちょくちょくある…。

2022-1-12 (Wed)

> 20年くらい前に作って 10年くらい前からほったらかしだったとおぼしき自前の小物 Perl スクリプトを、 久々に引っ張り出してちょっと手直ししてるんだが…。 いやーなんだこれ。なんか、ヘンに分かりにくいよ…。 申し訳に use strict; を入れてるけど、モジュールもほぼ使ってないなあ。 これは全面的に直しを入れてやらねば… (読みづらくていじりづらい)。 “ファイルをうっかり同名別ファイルで上書きしないようチェックしながら一方から他方へコピーする (階層ディレクトリ対応)” ってだけのしろものなんだが…。 モジュール Path::Tiny だけでほぼ用が足りてしまうなこれ…。
my $mode = (stat $filepath)[2];
if (($mode & 0140000) == 040000) { … }
よりも
if (path($filepath)->is_dir) { … }
の方がわかりやすいよな…。 …ていうか、なんで -d $filepath 使ってないんだろ。 もしかしてこれ書いた頃は -d だと遅いとか思ってたのかな…? (既によく覚えていない)

2022-1-13 (Thu)

> 輪ゴムの備蓄がなくなってきた。 これまではスーパーや惣菜屋や弁当屋で買った惣菜類の、パックを括ってあった輪ゴムを溜めておいて使ってたんだが。 たぶんコロナ以降くらいからだと思うが、 この輪ゴムで括る (だけの) パッキングをすっかり見なくなって、 備蓄の輪ゴムが自然と補充されなくなってきてたんだった。 あと以前より弁当屋の利用頻度が減ったのもあるかもしれない (弁当屋は割と輪ゴム止めのパッキングが多い印象)。 そういえば、惣菜をトレイからパック容器に自分で詰めるタイプの販売方法もすっかり見なくなったな…。 まあアレはずいぶん前から、衛生的にどうなんだろうなーと思ってあんまし利用したことはないけど… (同様の理由でコンビニのおでんもほぼ買ったことがない。 売り手にはそれなりに性善説を期待しつつ買い物はしているが、 買い手側の不特定多数に性善説は比較的期待できないと思っているんで…。 なにしろうちの近所のスーパーあたりは、 子連れの買い物客の、親同士が会話に夢中になってる間に子供が鼻をほじりまくりながら、 そこらのものをわざわざひとつひとつべたべた触って歩いてるのを見たこともあるしなあ…そんな感じの民度…。 閑話休題)。 輪ゴムも時間がたつだけでどんどんぼろぼろになるんで、使えるうちに使っちゃわないといかん、と思って、 カップ麺のカップを捨てる時に、ゴミ袋の中でかさばらないようバキバキと小さく折り畳んで輪ゴムでぎちぎちに止めて捨てたりしてたら、 ふと気づくといつの間にか残り数本になっていたという。 バランス悪い使い方だな。 まあ使って捨てるか、使わずに (ダメになってから) 捨てるか、捨てる時に使うか、 いずれにしても使うすなわち捨てる、みたいな宿命のシロモノだけど。
なければないで困ることもあるし、これはもう自腹で買うしかないか…。 と思ってネットショップで輪ゴムを検索していたら、 劣化しない輪ゴム、というのを発見した。 モビロンバンドという、天然ゴム素材じゃなくてポリウレタン製の、 普通の輪ゴムみたいに脆化したり溶けてくっついたりしないというのがウリのやつ。 探してみたら他にも同じポリウレタン製で別名 (別メーカー) の製品もあった。 輪ゴムは輪ゴムで使うけど、こういうのもあったらちょっといいかも、と思って買ってみた。 ちなみに 1袋で千円くらいするんだが、千本以上入ってるんでそう高いもんでもない。 輪ゴムよりちょっと伸びは少ない気もするが、といっても元の 2倍程度なら余裕で伸びるし、引っぱるのをやめれば元に戻る。 ゴム臭さもない。 でもウレタン樹脂って経年劣化する (しやすい) 的なイメージがあったんだけど、そのへんはどうなのかな。 加工方法なんかでも変わってくるんだろうけど、シロートなのでよくわからん。 まあ少なくとも普通の輪ゴムより持つんなら問題ないか。

購入記録

  • 新書「頼朝の武士団 鎌倉殿・御家人たちと本拠地「鎌倉」」細川重男、朝日新聞出版(朝日新書) ISBN978-4-02-295147-2 (2021)
実使用レビュー。 性能の割にやたら値段が高いのはオリジナルバンドルソフトの開発に想定外に費用がかかったため、というアレか。

2022-1-14 (Fri)

> ちょっと前にネットの記事で見かけた、ローソンストア100 の「ウインナー弁当」と「ミートボール弁当」 (いずれも税別 200円) が 30円引で並んでいたのをたまたま見つけて、 試しに買ってみた。
ウインナー弁当は、ご飯に黒ごま、スパゲティ少量を敷いた上に小さいウインナーが 5本並んで、ケチャップがかかっている。447kcal。 ウインナーが赤いやつだと思い込んでいたが、ちゃんとした味のある (燻製の香りもちょっとある) ウインナーだった。
ミートボール弁当は、やはりご飯に黒ごま、スパゲティ少量を敷いた上に小さいミートボールが 6個並んで、ソースがかかっている。410kcal。 上にかかっていたソースが、よくレトルトや安い惣菜のミートボールにかかっているような甘酢風味のではなく、デミグラスソースだった。 デミグラスソースは好きなのでこれはちょっと良し。
いずれも野菜成分は足りてないので適宜自前で補わんといかんが、 値段にもまあまあ見合った内容ではないか、と思う (ローソンストア100 の 100円おせちとか 2年くらい前に一度買ったきりだけど、けっこうガッカリ感にあふれてたからなあ…)。 それぞれウインナーやミートボールが具のおにぎり 2個分、と考えればかなり具沢山。 リピ買いはたぶんしないけどね。
> いよいよ書くことがなくなって、内容の“どーでもいい”度がだいぶ上がってきたな。

購入記録

  • 雑誌「週刊漫画TIMES」2022.1/28 芳文社
    • 妻、小学生になる。 (村田椰融)
    • 信長のシェフ (梶川卓郎)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
    • 瓜を破る (板倉梓)
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • ごほうびごはん (こもとも子)
    • 法廷のファンタズマ (荒川三喜夫)
    • 村祀り (原案協力:木口銀/山口譲司)
    • 王子とこじき -転生したら名作の主人公でした- (原案:マーク・トウェイン/風町ふく)
    • ヤバい女に恋した僕の結末 (沖田龍児)
cVim からの乗り換え可能とのことなので一応メモ。 まあ cVim 動いてるんで当分は cVim 使うけど。
cVim は以前 chrome 側の仕様変更で hints が動かなくなったが (1.2.99)、 今は修正版の 1.3 が出ている。
Hugo は SSG (Static Site Generator) のひとつ。Go で書かれている。チョッパヤ、らしい。

2022-1-15 (Sat)

> SSG (Static Site Generator) を手元でいくつか試し中…。 Perl 好きなもんで Perl ベースのやつにどうしても興味が行って、端から試してみたんだが、 どれも依存モジュールがやたらめったら多くて、 インストールがメンドウ…というかうちの (イビツな?) cygwin 環境だとエラーでまずコケる。 結局 --force オプション必須になってしまう。 そして触ってみた範囲だと、どうもどれもいまいちなんだよなあ…。残念。 どこがどういまいちだったのかは面倒なのでここには書かないけど (気が向いたらあとで書く。たぶん書かない)。 先に Jekyll (Ruby ベース) とか MkDocs (Python ベース) とかを試して、挙動をちょっと見てみていたので、 それらと比べてしまうせいもあるかもしれない…。 つっても Jekyll はウチの cygwin には入らなくて Raspberry Pi2 (ubuntu) に入れたらくそ重かったが、元々 Jekyll は重いらしい。 それに比べると MkDocs は重さもさほどでなくわりといい感触だったが、ワシ Python がそもそもあんまし好きじゃないんだよな…。 もちろん MkDocs 使う分には Python のコードなんぞぜんぜん触らなくっていいんだけどさ…。
でまあ、チョッパヤだという Go ベースの Hugo を触ってみているんだが、これは確かに速い。と思う。 そしてインストールも Windows 版なら exe ファイルいっこダウンロードして、PATH の通ったところに置くだけという簡便さ。 機能や挙動も Jekyll や MkDocs に近い。 うーん…。いまんところこれが優勝かなあ。 hugo server 中の挙動にちょっと怪しいところがある気がするけど… (更新されたりされなかったりとか… でも適用してる Theme によって挙動が変わるっぽい感触もある)。 SSG 物色してるのは、実は自分で使う用じゃなく人に勧める用なので、 勧める予定の相手が使えそうかどうかも考えないといかんのだが (その割に Perl ベースのやつをまず端から試してたりしてるあたりブレてるが)、 インストールがラクチンなのはかなりメリットかも。 まあでもその後の設定だの使い方の把握だのを、たぶん自分一人でいろいろぜんぶはできないだろうなあ…。 GUI だとそのへん、あちこち触っているうちになんとかなっちゃう (と思い込みやすい) んだろうけど…。 当方もできる範囲で手伝う気はもちろんあるんだが。 まずは勧め相手が気に入らなかったらそれまでだしなー。 まあそん時ゃそん時か。
> Hugo の設定ファイルが TOML っていう見たことない書式で (拡張子も .toml)、 なんか YAML 的なやつかな?と思って検索してみた。 書式は INI ファイルに近く、表現できる内容は JSON に近い、らしい。 JSON よりは人間寄りっぽい (コメントが書けるとか。そうなんだよな JSON てコメントが仕様にないんだよな…)。 よし覚えとこう。
なお Hugo の設定ファイルには TOML の他に JSON や YAML も使えるらしい。
SSG のめぼしいところ一覧…。 なにこれ。やたらたくさんあるんですけど。えー多過ぎない?
とりあえず Perl ベースのだけ選って拾ってみた…。 少ないっすな。 なおこれらはまだ触ってみてない (これから)。

2022-1-16 (Sun)

> ウチの電子レンジがどうやらついに寿命を迎えたらしい…。 つっても、直そうと思えば (自力でも) 直せる可能性はある感じの“寿命”なんだけど…。
ある時スイッチ入れたら「ブロロロオー」と騒音がするように、いきなりなってしまっていた。 つい数時間前には何事もなく、今までどおり使えていたのに突然、という。 音量的にも音質的にも、電気回路の発してる音ではなく、中の冷却ファンが他のパーツに接触するなりして発してる感じの音なので、 自分で直せる余地がありそうで、その状態で (修理を試みずに) 捨てるのはなんとなくもったいない気が…。 しかし、弱電も強電もほぼシロウトなので、 電子レンジの筐体を自分で開けるのはたぶんやめといた方がいいんだろうと思う…。 どこがどの程度高電圧で、なにをどうすれば危険を回避できるか、とかがほぼ分からんので。 といって、業者に修理に出してお金払うのもちょっとなあ…という。 修理費用にもよるだろうけど、たぶん手間賃だけでもそんなに安くはないだろうし (あんまり安かったら逆にヤバいよな)。 そもそもこの異音の原因は直せても、 他のパーツの劣化もあるだろうからこの先どれくらい使い続けられるかも分からんしなあ…。 もう 20年選手だし。メーカー (SANYO) ももうなくなっちゃってるしねえ…。
> というわけで、半ば諦めの境地で新しい電子レンジを買った。 TOSHIBA ER-WS17、約 18K。 SHARP の同価格帯の機種と迷ったんだが (隠れ SHARP シンパなので)、 取説と製品写真と仕様を比較して、操作の分かりやすさ、最大出力、ドアの突起部の多少、などからこちらになってしまった…。
今まで使ってたやつはいわゆるオーブンレンジというやつだが、今度のは単機能電子レンジ。 先代は中堅機種ながら多機能で、専用の調理ボタンもいっぱいついていて、 お料理レシピ冊子みたいなもんまで同梱されていたんだが、 これら機能ボタンも、オーブンも、もちろん冊子も、この 20年ほぼ使わなかった。 もしかすると初期の頃に 1~2回、試しに使ってみたことはあるかもしれないが覚えてない…。 くらいな感じ。 つまりワシ的には単機能レンジでまったく用が足りるということを 20年かけてだらだらと確認した訳だな。 この先代機は庫内がフラット (ターンテーブル式じゃないやつ) でドアが縦開きなところは気に入っていたので、 新機種選定時はこの 2点で条件を絞ったが、 先代のドアは開いた状態でほぼ水平になる上、内側もほぼフラットで (枠と中央の窓部分の段差がほとんどない)、 開扉した状態でなにかを載せたりするのに都合がよかったんだけど、 今度のはドアの内側は中央の窓部分がちょっと凹んで段差があるんだよな…。 いろいろ製品写真を見てみたが大体どれもそんな感じだったんで、先代機のドア (内側) 形状がちょっと特殊だったのかも。 まあ使っているうちに慣れるだろうけどたぶん。
ところで先代の処分は、 …リサイクルに出すとお金たくさん取られそうなので粗大ゴミかなあ… 400円くらいで済むっぽいんで…。 捨てる前にプラグ抜いてしばらく (1ヶ月くらい) 放置して放電してから、自分で開けて直せるかどうか見るだけ見てみるかな? でも万一直っちゃったらどうしよう…? 電子レンジ 2台も要らないよな…。
> さて、洗濯機も死んで (だいぶ前だけど)、 電子レンジも死んで、 次は冷蔵庫か。冷蔵庫もレンジと同時期導入だから、まあぼちぼち覚悟はしておいた方がいいんだろうなー。
VeraCrypt (TrueCrypt の後継。OSS?)、 gocryptfs (Windows 非対応)、 GnuPG (大量のファイルを一括には向かない)、 CryFS (gocryptfs 類似、遅い)。
Boxcryptor、Cryptomator、VeraCrypt。前者 2つはクラウド向け。

2022-1-17 (Mon)

> 久々にヤフオクで落札して、 取引ナビっつー専用の画面から取引開始して、 情報入力して、確定しようとしたら、
入力内容に誤りがあります。
現在、ヤフネコ!パックでの受取りをご利用いただけません。他のお届け方法を選択してください。
※「ヤフネコ!」以外の選択ができない場合は、お手数ですが取引メッセージからお届け方法について出品者と相談してください。
とかなんとか真赤っかな色で表示されてそこから処理を先に進められない。 他のお届け方法といっても匿名配送に設定してあるし、そもそもオークション終了してる時点で他の発送方法を選び直しようがないと思うんだが。 こういうところ、ほんっっっっっっっとに間抜けなんだよな… Yahoo! というかヤフオクというか…。
(→なお後日、この障害の原因が判明した)
ヤフオクは障害情報とかに年がら年中新しいお詫びだのなんだのが上がってる状態なので、 このトラブルもしばらく待ったら直るかもしれん、と思って様子を見ることにしたんだが。 半日くらいたってから再度試してみたら、今度は決済するところまで遮られずに完了して、 口座から引き落とされたのも確認したものの、 取引ナビ画面に
引き続き、支払いを行なってください
と表示され、「Yahoo!かんたん決済で支払う」ボタンが表示されたままの状態になった。 何度か再読込してみたが直らない。 カネを取られておきながら、ヤフオクのシステム側にそれが認識されてない (可能性のある) 状態なままなのはさすがにいかんと思って、 例によって「よくある質問」のリンクをたどってたどって一番奥までたどってそこからの「問い合わせ」フォームへのリンクをたどって、 フォームからプリプリ半怒りまじりの問い合わせを送っておいたが、 これまた半日ほどしてから状態が画面表示に正常に反映され、出品者から発送連絡もされ、 ヤフオク運用からおわびメールも届いた。 金払った時点でシステムの状態がおかしくなるってのはほんとにやめて欲しいわ…。 他にも、適用できるはずのクーポンが決済画面で選択できなくなるとか、 特定の決済方法が一時的に使えなくなるとか、 ほんとに年がら年中「ヤフオクからのお知らせ」にお詫びメッセージが並んでるんだよなあ…。 なんでそんなに頻繁にトラブってんだろ…。 これが銀行あたりだったらお知らせでお詫びして済む話じゃないよなー。 たぶん毎週のようにカメラのフラッシュの放列の前で偉いさんや担当者が一斉に頭下げる写真が載るだろうな Yahoo! ニュースに。
> それはそれとして、昼前頃一時的にさくらインターネットが広範囲にトラブルを起こしてアクセスできなくなった。 Web サーバもメールサーバも両方だめになっていた。 といってもワシの借りてる範囲のサーバはせいぜい 1~2時間で復旧したみたいだけど…。 全体が復旧するまでだいぶかかった模様。 クラウドサービスが特に影響範囲が広かったみたいだな…。 原因はなんだったのかな。
トンガの海底火山の噴火も被害状況すらまだよくわからん状態みたいだし…。
ついでにウチの電子レンジも寿命を迎えちゃったし…。
なんかあっちもこっちも大変だよ…。
電子レンジだけちょっとレイヤーが違うか…。
> 水島新司氏の訃報。10日、82歳。肺炎のため、と。
午前中の 1~2時間ほど、借りてるレンサバが反応してくれなくなってた。 けっこう広範囲だったっぽいな。

2022-1-18 (Tue)

> 電子レンジ届いたので設置した。 先代よりも値段 (クラス) が安いだけのことはあって細かいところが安っぽい。 ドアの内側の枠部分があからさまにプラスチックとか。ドアの開閉の音がちと雑でうるさいとか。 ボタンが押しづらいとか (力を込めて押し込まないと ON にならない。 でもって筐体が軽めなので本体ごとずるっと後ろにすべったりする…滑り止めシートでも敷くか…)。 フラットな庫内底面も、前のは隅までぜんぶフラットだったが、 今度のは周辺をちょっと残してゴムっぽいもので土手ができていて (もんじゃ焼く時に作るような…いやちょっと違うか)、 全面的にフラットにはなっていない。 まあ、電子レンジとしてちゃんと使えればそれでええんじゃ。 ところで先代もアース接続しないで使ってたんだけど。アースつなぎたいんだけどつなぐ先がないんだよなあ…。 うーんどうしよう。

購入記録

  • 同人誌「大塚康生のおもちゃ箱 別冊(1) O's File - Jeep! Jeep? Jeep♥」大塚康生/パノラマ堂、空想工房パノラマ堂
> 同人誌なのか自費出版なのか。同じか?
メモ : CATEYE VOLT200 (HL-EL151RC) (充電式:3.7V 1000mAh) / VOLT400 (HL-EL461RC) (充電式:3.7V 2200mAh:バッテリ交換可) | PANASONIC NSKL152 (電池式:単3×2)
メモ : GENTOS 閃 455 (SG-455B) (電池式:単4×3) (自転車専用ではないが点滅モードもあるヨ)
ただ問題は、オフレコを前提で聞いた話を暴露したり、官房長官の記者会見では質問を控えてその後の単独取材で本音を聞き出したりといった手法の是非である。
↓これの件。

2022-1-19 (Wed)

> 寒い。寒いよ。
> 引き続き SSG の物色。 なーんとなく分かってきた…。 結局、SSG を導入しても、サイト構築自体はそんなにラクはできないんだ。少なくとも立ち上げの時点では。 全体の構造とか構成とかがかたまって以降、内容の更新とか追加の際はちょっとラクにはなるにせよ。 WordPress みたいに動的に構築するかわりに、 静的に構築してからアップロード (公開) するだけだから、 似たような複雑さのサイトを作ろうとしたらどうしても手数は必要になる道理で。 そして SSG ツールによっては、 WordPress みたいに独自の暗黙のルールとか独自の書式とかがいっぱいあるんで、 まずそのへんを把握しないとどうにもならなかったりする。結局大変さはあんまし変わらないという。 まあ改めて考えたら当たり前なんだけど。 動的に構築するのと比べてセキュリティ的な心配事が少ないだけでも利点ではあろうけど。

購入記録

  • 雑誌「主任がゆく!スペシャル」Vol.167 ぶんか社
    • 主任がゆく! (たかの宗美)
    • 金髪女将綾小路ヘレン (たかの宗美)
    • 精肉部門の未藤さん (市村) (ゲスト)
    • 隣のショタがまるで嫁 (道野ほとり) (短期集中連載)
    • 貧乏神ちゃんは愛されたい (魔神ぐり子) (移籍新連載)
    • あい・ターン (おーはしるい)
    • 春川さんは今日も飢えている (おりはらさちこ) (移籍新連載)
    • 嫁姑は仲良くケンカする (大江しんいちろう)
    • ウチのパグは猫である。 (ひぐちにちほ) (移籍新連載)
    • 群馬犬! (安西理晃)
    • モノズキ散歩、お茶してうまし♥ (胡桃ちの)
    • 花野さんとの縁結びは難しい (野広実由)
    • ファニーランドの鬼ババア (むんこ)
    • マチ姉さんのポンコツおとぎ話アワー (安堂友子)
    • 若奥様は侵略中 (佐野妙)
    • おるすばんごはん (王嶋環)
    • くそじいじとカメラと私 (うず) (最終回)
    • それいけ! せっぷく丸 (大塚みちこ)
    • 双子コンプレックス (おりはらさちこ) (最終回)
    • 目次4コマ:ゆるゆる4コマ (たぁぽん)

2022年01月18日06時05分

 【ロンドン時事】英国のドリース・デジタル・文化・メディア・スポーツ相は17日、公共放送BBCの受信料(ライセンス料)制度を見直すと表明した。動画配信サービスのように、視聴に対して課金する仕組みを軸に検討する見通し。日本のNHKなど世界の公共放送のモデルとなったBBCの動きは、今後の日本の議論にも一石を投じそうだ。

 ドリース氏は下院での演説で「技術の変化とともに、特に若い世代の視聴者の間で習慣も変化している」と指摘。BBCの長期的な資金調達の在り方、罰則規定を伴う受信料支払い義務について「適切かどうかを今こそ真剣に問うべき時だ」と述べ、近く制度見直しに向けた議論を始める考えを示した。

NHK はもういろいろとがんじがらめだろうから動かねーだろうな。と予想しておこう。 ワシはどっちみちもう見ないけど (テレビ自体)。

2022-1-20 (Thu)

> 家電量販店でつくポイント (ポイント還元)、は実際にはどれくらいオトクなのか、 というのをちょっと計算してみた。 といってもちゃんとした計算式を立てられないので (数学の素養がなくて式の立て方がわかんないので)、 JavaScript で条件を適当に設定しつつ複数回の買い物のシミュレーションを行なう。 モンテカルロ法 (の一種?)。 なお実際のシステムと同様、ポイントは現金で支払った金額分にだけつく。 ただし計算の都合上、ポイント率はすべて 10% とする (実際には商品によって率が多少違う。書籍類は原則 3% とか、電子書籍は逆に多くて 20% だったりとか)。
パラメータをちょこちょこ変えつつ総額 100万円くらいまでの仮想的な買い物を繰り返してみたところ、 実際にポイントで支払われる率 (= 現金を使わずに済んだ率) は、 トータル購入額の約 9% になることがわかった。 “10% 還元”もトータルで見ると実際には“9% 還元”くらいなんですなー。 計算が合ってればだけど。たぶん合ってるじゃろう。 10% ポイント還元の正味はおよそ 9% 還元、てどこかで見た記憶もあるし (見たんかい)。
'use strict';

// 家電量販店のポイント還元が、トータルで実際にはいくらの値引きになるのかの検証シミュレーション(てきとう)
// ※ポイントは現金で払った分にしかつかない
// ※必ず現金支払額の10%(端数切り捨て)ポイントがつくとして計算
// ※ポイントは買い物の時点で持ってる分使えるだけ使う(なるべくためない)戦略 計算面倒なので

// 購入額累積上限 (ここまで買ったら計算終了)
const paid_total_limit = 100_0000;
// 購入額 (累積) 支払い手段問わない合計額
let paid_total = 0;
// ポイント残額(状態保持)
let point = 0;
// 使用ポイント累積値 (最終的な累積購入額-累積使用ポイント=実際に払った金額)
let point_used_total = 0;
// 買い物1回あたりの支払額下限
const price_bottom_limit = 100;
// 買い物1回あたりの支払額上限
const price_top_limit = 10000;
// 買い物1回あたりの支払額の刻み単位(必要ないっちゃないけど)
const price_step = 50;

// from~to の間(from、to含む)のstep刻みの整数をランダムに返す
const rndspan = (from, to, step) => {
	return Math.floor(((to - from) / step + 1) * Math.random()) * step + from;
}

let count = 0;
while (paid_total < paid_total_limit) {
	const price = rndspan(price_bottom_limit, price_top_limit, price_step);
	let cash = price;
	paid_total += cash;
	if (cash >= point) {
		cash -= point;
		point_used_total += point;
		point = 0;
	} else {
		point -= cash;
		point_used_total += cash;
		cash = 0;
	}
	point += Math.floor(cash * 0.1);
	count++;
}

const cash_paid_total = paid_total - point_used_total;
const cash_ratio = cash_paid_total / paid_total;

console.log(`
買い物1回あたり支払い額: ${price_bottom_limit}~${price_top_limit}円(ランダム、${price_step}円刻み)
買い物回数    : ${count}
総支払額      : ${paid_total}
総使用ポイント: ${point_used_total}
総現金支払額  : ${cash_paid_total}
残ポイント    : ${point}
現金使用率    : ${Math.round(cash_ratio * 10000) / 100}%
ポイント還元率: ${Math.round((1 - cash_ratio) * 10000) / 100}%
`);
出力例↓
買い物1回あたり支払い額: 100~10000円(ランダム、50円刻み)
買い物回数    : 195
総支払額      : 1004000
総使用ポイント: 90539
総現金支払額  : 913461
残ポイント    : 721
現金使用率    : 90.98%
ポイント還元率: 9.02%
> コインハイブは最高裁が無罪判決出したんだな。よかった。
消費者庁は、大幸薬品の「クレベリン スティック ペンタイプ」、「クレベリン スティック フックタイプ」「クレベリン スプレー」「クレベリン ミニスプレー」に対して景品表示法に基づく措置命令を行なった。
大幸薬品は、措置命令に対し、「速やかに必要な法的措置を講ずる」と反論している。
対抗薬品…。退行薬品…。
警察、検察、高裁 (二審) 判事の処遇が宙ぶらりんだな…。

原判決について、「不正指令電磁的記録の解釈を誤り、その該当性を判断する際に考慮すべき事情を適切に考慮しなかったため、重大な事実誤認をしたものというべきであり、これらが判決に影響を及ぼすことは明らか」として、「破棄しなければ著しく正義に反する」と述べた。

自判(じはん)とは、上訴を扱う裁判所が、原審の判決を不当として取消または破棄したうえで、差戻しをすることなく判決すること。取消自判と破棄自判の2種類がある。

破棄自判

民事訴訟の上告審、及び刑事訴訟の控訴審・上告審で原審を破棄して判決を下すこと(民事訴訟法第326条、刑事訴訟法第400条但し書、同第413条但し書)を破棄自判という。

刑事訴訟の控訴審において破棄事由(第377-382条、第383条)に該当する場合は判決で原判決を破棄しなければならず(第397条第1項)、裁判所の取調べの結果原審を破棄しなければ正義に反する場合も原判決を破棄することができる(同条第2項)。この場合、直ちに判決を言い渡せる場合は自判することができる(第400条)。

刑事訴訟の上告審では第410条に破棄すべき事由、第411条に破棄可能である事由が列挙されており、これに該当する場合は原審に差し戻すか移送することになるが、直ちに判決を下せる場合は自判もできる(第413条)。

最高裁の自判は例外

上記の規定によれば、民事訴訟法では破棄自判できる範囲が限定されており、それ以外の場合で原判決を破棄する場合は、第325条により原審または第一審に差し戻すか、移送することが原則となる。

刑事訴訟法では差し戻しまたは移送を原則とする。刑事訴訟で最高裁が破棄自判をすることは、高裁での破棄自判の例に準ずる。

2022-1-21 (Fri)

> ただいま keepass を試し中。 まだ使い方がよくわかんない…。
今までパスワードの管理は、特定のテキストファイルにベタ書きで記録しておいて、 普段は GPG で暗号化しておき、 参照や編集をする時だけデコードして、終わったら削除ないしは再度暗号化、という運用でやってきた。 今後もこれはこれで変えない予定だが…。 スマホ (単体) で同じことをやろうとすると、 パスフレーズの入力がかなりメンドくさくてちょっとダメだな、と思ったもんで…。 せっかくなんでスマホと PC とで同じ DB ファイルを使える (同期させて共用できる) パスワード管理ツールを試してみようと。 まだ使い方がよくわかんない段階なくらいなので、評価もまだわからない。
> 先日ヤフオクで、決済の手続きが一時進められなくなった件、の原因が判明した。 ヤフオク運営に、事象の報告を一応しておいたところ、返信メールから、 「ヤフネコ!パックでは、毎週月曜日午前3時から午前5時頃まで、ヤマト運輸の定期メンテナンスが行われており」、 「メンテナンス中は、取引情報の送信や配送コードの発行を行うことができ」ない、という情報が。 月曜午前 3時から 5時ごろ…まさにその時間帯だったんだよねえ。 でもヤマト運輸の定期メンテナンスの情報も、その間は手続きが進められないという情報も、 サイトの該当ページや、「よくある質問」や、「よくある質問」ページのチャット bot による「考えられる原因」一覧には、 ひとかけらも表示されてなかったんだよなあ…。 なんでそんな肝腎なことを、ちゃんと表示しておかないんだろう…。 何が原因か、どうすれば回避できるか、情報をユーザにちゃんと提示してくれればいいだけなのにな。

購入記録

  • 雑誌「週刊漫画TIMES」2022.2/4 芳文社
    • めぐる未来 (辻やもり)
    • 妻、小学生になる。 (村田椰融)
    • 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
    • 巨匠 (Gたかし/高橋一仁)
    • 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
    • パスタの流儀 (原作:花形怜/才谷ウメタロウ)
    • 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
    • 村祀り (原案協力:木口銀/山口譲司)
    • ヘルズボート136 (前田治郎)
    • うそびっち先輩 (音井れこ丸)
    • ヤバい女に恋した僕の結末 (沖田龍児)

NVIDIAで処理する場合
waifu2x-caffe
※cuDNNの使用を推奨

NVIDIA/AMD/CPU(内蔵GPU)で処理する場合
waifu2x-ncnn-vulkan
※waifu2x-caffeより速い。AMD利用者はこれを使うしか無い!

caffe は倍率設定が (比較的?) 自由 (×2、×2.5、×3 など)。
ncnn-vulkan は ×2n 刻み。でも高速。そして石を問わない。ふむ。

2022-1-22 (Sat)

> keepass に続いて…でもなんでもないけど。 Signal をインストールした。個人情報保護を重視したチャットツール (という認識)。 エンドツーエンドで暗号化されるので運営も第三者も通信内容を把握できない、というやつ。 インストールはしたが、試す相手がいないのでまだ使ってない。 世の中は (特に日本は) LINE 全盛だが、インストールも利用もする気になれないので…。 LINE の使用をもし強要された時に、それよりこっち使いましょうと提案するための準備。 まあそんな機会はたぶん永久に訪れない。
> そして、Docker ベースでないと扱いがメンドくさくなっちゃった tt-rss のかわりに、 LAN 内の Raspberry Pi 2 (ubuntu) に Miniflux (Miniflux2) をインストールしてみた。 サーバで走らすタイプの Feed リーダで、 インストールには root 権限が必要だが、 Go ベースで速いので、非力な Raspberry Pi 2 には向いてそう (Go ベースが速いというのは先日 Hugo をちょっといじった時に実感している)。 導入作業は、いろいろと、検索した記事からほぼわけもわからずコピペのつぎはぎというヒドいやり方だったが、 まあなんとか動くところまではたどりつけた…。 もっとイッパツでインストールできたらよかったなーと思いつつ、そう思う時点でだいぶ軟弱になったなーとも思いつつだな。 手順はひととおりあとでメモっとこう…。忘れないうちに… (すぐ忘れる)。 まだ立ち上がっただけの段階で、細かい設定とか feed (OPML) のインポートとかはこれからやるところ。
> 一応、Docker ベースの tt-rss も試してみようかな、と、 Docker を Raspberry Pi 2 にインストールはしてみたんだけど。 そして Docker ベースの tt-rss も入れてはみたんだけど。 設定の方法がよくわかんないまま、 なんとなくそれ以上調べるキモチがわかずに削除してしまった…。 もうだめだ。 とりあえずこいつは保留とする。
「公式レポジトリをセットした上でインストール」、 Raspberry Pi 2 の場合は 32ビットアーキテクチャなので、 文中「arch=arm64」のところは「arch=armhf」とする。 とりあえずインストールと動作確認 (Hello World) まではできた。

2022-1-23 (Sun)

> Windows 版 keepass と DB を共用できる Android アプリ版の KeePassDX、 インストールするだけして放ってあったのをちょっといじってみたんだが、 使い方がよくわからん…。 試しにあれやこれやの他アプリのパスワード入力画面を出してみるんだが、 入力の補助がなにやらままならない…。 うまくいったりいかなかったり。 入力時のキーボード (アプリ) 切り換えも固定されずにすぐ Gboard に戻っちゃうし…。 そして KeePassDX 自体の起動時のログイン (じゃなくて DB のロック解除か) も、 なんかもたついてスムースに入力できん。 なぜだ。
とあれこれ調べてたら、 KeePassDX よりも前から作成配布されている Keepass2Android っつーアプリが割と評価が高いようだったので、 試しにそっちを使ってみたら、操作もスムースにいくし、 他アプリのログイン画面での入力補助もスムースにできるし (若干試行錯誤はしたが…表示が分かりやすかったので操作方法を推測しやすかった)、 Keepass2Android 自体の起動時もクイック解除で生体認証 (指紋認証) を使うことなく、なおかつあまりもたつかずに解除できる。 なんだ、最初からこっちを使えばよかった。 まあ KeePassDX も評価はそれなりに高いみたいなんだけどさ…。 あの使い勝手でなぜそんな高評価なのかがよくわからん。 Keepass2Android より上っていう。 みんな使いづらくないのかな…?
なお keepass アプリで生体認証を使った DB ロック解除をしないのは、 元々生体認証でログインできるタイプの他アプリの、ログインの簡便さをなるべく損なわずに (つまり使いづれえ Android のキーボード入力から長々とパスワードの入力をすることなく) 生体認証でのログインをしない設定に切り換えるために keepass を導入しようと思ったからで、 つまり生体認証はベンリだけどちとアブネエという認識でいたものの、 簡便さに引きずられてついつい設定してしまっていたのを反省して、 なるべく使うのをヤメようと思ったからなので、 その生体認証を、生体認証を排除するために導入した keepass アプリで使ったら本末転倒というか元も子もないからなんである。 説明ヘタクソ。
まあ、スマホ本体の画面ロック解除には使ってるけどね生体認証。 そんなに スッ と素早く解除しなければならないような状況は年に 1回もないけど。
ちょっといいかしら…。 でもなあ。PC は中古はなるべくやめといた方がいい気もするんだよな…。 あと今更だけど AMD の石のやつも使ってみたいし…。 さてどうすっぺ…。 と迷っているうちに売り切れるのでもうしばらく迷う。
性能上がってきているのかと思ってたがまだそれほどでもないのか。そうか…。 まあゲームとかはぜんぜんしねえから、 4K の動画が余裕でなめらかに再生できる程度の能力が (CPU か GPU に) あればそれでいいんだけど…。

2022-1-24 (Mon)

> Keepass2Android をしばらくいじった後、KeePassDX をいじったら、使い方が分かってきた。 ような気がする…。 なるほど…。 つーか入力用キーボードの UI があんましよくない。 アイコンしか表示されてなくてどれが何のためのアイコンなのか説明もないんで、どれ押したらいいか分かんねえんだもん。 これは Keepass2Android の UI からの移行を前提に設計してるような気がするな。 たぶん作者はそのへんあんまし意識しないで作ってんだろうけど、一見のユーザにはわかりづらいと思う…。 どうなんかなそのへん。ワシだけかしれんけど…。
> メンソレータム薬用ハンドベールうるおいさらっとジェル、がぼちぼち終わりそうだな、と思って、 ヨドバシドットコムでハンドクリーム検索したらちょっとよさげなのがいっぱい出てきたんで、 ポチポチとポチってカゴに突っ込んでったら総額 3300円、総量 500g を超えた。 バカかワシは。そんな量を使い切れるほど手の本数も面積もないわ。 いやもちろんそのまま全部買ったりしないがな。…たぶんな。
なんかしらんけど最近、手の甲全体 (指含む) が、がっさがさなんだよな…。 わさびをすり下ろすのにちょうどいいなこれ、ってくらい。 ひょっとしてよくこすったらがさがさが落ちないかな、 と思って手を洗う時によくこすったら垢っぽい感じに落ちたが、乾いてから余計にがっさがさになった。 たぶん加齢のせいはあるんだろうけど、それだけではないかもしれないし…。 こういうのってハンドクリーム物色してないで医者に一度見てもらうのがいいのかもしれんけど。 でもなー血がにじんで痛くて手仕事ができないとかぜんぜんそんなレベルじゃないからなあ…ただがっさがさなだけで…。

2022-1-25 (Tue)

> miniflux2 のインストール手順をメモっておこうとして、 すでにうろ覚えになっていて細かいところがメモれないことに気づく。 記憶の揮発が早すぎる…。
せっかくなので、一旦アンインストール (sudo apt purge postgresql miniflux) して、 コピペでなく自分なりに手順を把握してインストールとセットアップをやり直してみよう、と思い、 何度か試してみたが、どうもうまくいかない…。 こうやればこうなるハズなんだけど、と思ってもちゃんと起動するように設定できない (詳細は略)。 DB 周りの設定で引っかかっとるんだろうとは思うものの。 5~6回ほどパターンを変えてやってみたがアカンかったので、 結局メンドくさくなってコピペ手順でやり直したらちゃんと動いた。 DB (PostgreSQL) の仕様とか挙動とかいろいろ細かいところをしっかり把握する必要があるなあ…。 とりあえず探究はまたの機会ということにして、 セットアップを済ませてインストール手順のメモも書いた。 まあ、公式 (miniflux 配布元) のドキュメントや、参考にしたサイトなんかが、 ユーザ ID やパスワードや DB 名を片っ端から“miniflux”にしてたりして、 最初のインストール時にはどの“miniflux”が何を指してんのかちょっと混乱してたんで、 そのへんが把握できただけでもいいや。 …またそのうち機会があったら、どこの記述はどう変更できるか、とかもうちょっと検証してみよう…。
で、インストール終わってやっとスタート地点な訳で、これから miniflux 自体の評価と検証をせにゃーいかんのだな。 問題なくまるっと tt-rss と置き換えられるのか、というあたり。 なんか、インストール方法を検索して漁ってたら、巨大“便所の落書き”掲示板に、 複数の feed リーダ使ってるけど miniflux は取りこぼしが一番多い、とかなんとか書いてる奴がいたので…。 取りこぼしってアンタ。そりゃ設定のせいじゃなくて?
> ムロタニツネ象氏の訃報。11.22、87歳。「ファイトだ!! ピュー太」DVD まだぜんぜん視聴終えてない…。
目移り対象追加。
目移り対象追加。
2.18~6.6、明治大学米沢嘉博記念図書館。

前田恒彦 元特捜部主任検事 1/24(月) 9:54

 ゆうちょ銀行が硬貨の取扱手数料を徴収するようになったことを受け、「税金を納める場合には無制限に貨幣を使えます」という日本銀行新潟支店のコラムがSNS上で拡散されている。問題はその法的根拠だ。

古い「通達」がある

 すなわち、「通貨の単位及び貨幣の発行等に関する法律」では、「貨幣は、額面価格の20倍までを限り、法貨として通用する」と規定されている。500円、100円、50円、10円、5円、1円硬貨は、一度の取引でそれぞれ20枚までしか使えない決まりだ。

 大量の硬貨は計算や保管に手間がかかるからであり、受け取る側が了解するのであれば構わないが、同意できなければ受け取りを拒否できる。しかも、この法律には「納税の際はこの限りでない」といった例外規定も設けられていない。

 しかし、この枚数制限はあくまで民間の取引に限られ、納税など「公納」の場合には適用されないというのが財務省の見解だと思われる。1937年に当時の大蔵省理財局長が発出した「補助貨ヲ無制限ニ公納受領ノ件」という通達がその根拠だ。

 すなわち、この通達は現行法の前身となる「貨幣法」に存在していた銀貨幣(50銭、20銭、10銭)、白銅貨幣(5銭)、青銅貨幣(1銭、5厘)の通用制限に関し、公的な解釈に基づいて注意喚起を行っている。

 これによると、銀貨幣は合計10圓まで、白銅貨幣と青銅貨幣は1圓までといった規定は民間取引上の通用制限を定めたものにすぎないから、租税その他の「公納」に際して小額の貨幣が使用されたとしても、無制限で受領すべきだという。

 この通達やそこで示された見解はいまでも有効だし、旧貨幣法から現行法に移行しても通用制限の趣旨には変わりがないから、財務省はこれに沿った事務を行うことになる。現に国税庁は、税務署の窓口で所得税などを現金納付する際、使用する硬貨の枚数を制限していない。地方自治体に対する法的拘束力はないが、この通達の趣旨に沿い、地方税などについて同様の取り扱いをしている市区町村なども多い。

受け取り拒否が問題になった例も

 2008年には、福岡の税務署で400枚の500円硬貨を使って滞納消費税などの一部を納めようとした市民に対し、硬貨を数える機械があったにもかかわらず、担当の税務署員が「間違ったらいけない」「それくらい払っても仕方がない」などと受け取りを拒否し、徴収課の幹部ともども謝罪に追い込まれる事態となっている。

 ただし、この通達は収納代行をしている民間の銀行やコンビニエンスストアまで拘束するものではない。税務署の窓口ではなく、銀行で大量の硬貨を使って納税しようとしたら、「通貨の単位及び貨幣の発行等に関する法律」に基づいて受け取りを拒否されたり、所定の硬貨取扱手数料を徴収されるかもしれない。

 このように、税務署の窓口で硬貨を使って納税すること自体は適法であり、日本銀行新潟支店のコラムで触れられている話は本当だ。それでも、あまりに大量だと確認のための待ち時間がそれだけ長くなるし、事務も停滞して迷惑となる。

 全国的に頻発するようであれば、財務省が先ほどの通達を廃止し、枚数制限をかける事態に発展するかもしれない。(了)

2022-1-26 (Wed)

> 新しい電子レンジが届いて 1週間、 実際まだそんなに使ってはいないんだが、前機種とのクセの違いがちっとずつ分かってきた。
前の機種は稼働中に電磁波が出ている時と出ていない時の区別が、 機械のうなり音、庫内灯の明るさの変動、オンオフ時のリレー音などでつきやすかった。 しかし今度の機種はそのへんの区別が若干つきにくい。 まだ音の違いとかに慣れてないせいもあるかもしれない (慣れたら区別つくようになる可能性はある)。 確実に知るには、隣に置いてある TANITA の電子式キッチンスケール (はかり) をオンにしておくと、 電磁波が照射されている間は目盛の値がふらふら (数g の範囲で) 変動するので分かりやすい (これは前機種今機種とも)。 …これでキッチンスケールが故障することもないだろうけど。たぶん大丈夫だよな…。
あとは加熱パターンというか、運転動作の違い。 前機種今機種とも、スタートボタン一発 (with 温度センサー) のオートモードと、 出力や時間を設定してから加熱開始するマニュアルモードを備えているが、 前機種はいずれの場合も運転開始から電磁波照射開始までのタイムラグが 2秒くらいだった。 一方今機種は、マニュアルモードの時はやはり 2秒くらいのタイムラグだが、 オートモードの時は運転開始から実際の電磁波照射までなんと 20秒くらい間がある。 冷却ファンは即座に回り始めるので、温めも始まっていると思いきや、 この 20秒ほどの間は中のものは温度変化しないまま、という。 おそらく、センサーのキャリブレーション的なことをしているんではないか、と推測しているが…。 それにしても 20秒前後はちょっとかかり過ぎな気もするけど…。
で、前機種では、冷蔵庫から出したばかりの冷え冷えな生卵とか、まとめてゆでておいて冷蔵庫にキープしておいたゆで卵なんかを、 ボタン一発で加熱開始→数秒加熱→手動で停止→数秒待つ、を 2~3回繰り返して室温近くまで温めるというのをよくやっていたんだが (“卵をレンチンすると爆発”するのは延々と加熱して内圧が高まるからで、ごくごく短時間の加熱なら問題ない)、 今度の機種は前述のとおり、ボタン一発のモードだと加熱が始まるまで 20秒前後待たないといけないため、 この用途には使い勝手がすこぶる悪い。 しかしマニュアルモードでは出力と時間の設定ボタンをあらかじめ余計に押さないといけないんで、 ほんのちょびっとメンドくささが増してしまった…。 ささっと使いたい、という時に一番目立って押しやすい大きいボタン 1コだけ押すのと、 たくさん並んでる同じサイズの小ぶりのボタンの中から目視で確認しつついくつか押してから大きいボタン 1コ押す、のとでは、 確実に手間が違う。 1回 2回ならともかく、今後、何十回も何年も続けることを考えるとバカにできない差なんだな…。 おまけに、前にも書いたようにこの機種のボタンは押しにくい。 一番大きいスタートボタンですら、 押す箇所 (位置) が悪いとか力が弱いとかだと押しても検知されないんで、何度も押し直すこともあるくらい押しづらい。 そんな訳でさらに利便性が落ちるという。 スタートボタンはまだいいけど、停止ボタンが押しにくい & 押しても検知されないことがある、のはホントに面倒…。 まあ、そのうち慣れていってあまりストレスにならなくなることを期待しよう…。
> …あれ、なんか新機種へのダメ出しになっちゃったな。

2022-1-27 (Thu)

> フィードリーダ Miniflux、 2日ほど動かしてちょっと feed 取得具合が安定してきた。 その後設定値を変えてみたり、ちょくちょくいじってはいるが…。 ちなみに取りこぼしが発生しているのかどうかまだよく分からない (ちゃんとチェックしてない)。
なお現在の設定値↓ (/etc/miniflux.conf)
# See https://miniflux.app/docs/configuration.html

RUN_MIGRATIONS=1
DATABASE_URL=postgres://miniflux:minifluxpass@localhost/miniflux2?sslmode=disable
PORT=8080
BATCH_SIZE=10000
CLEANUP_ARCHIVE_READ_DAYS=-1
CLEANUP_ARCHIVE_UNREAD_DAYS=-1
POLLING_PARSING_ERROR_LIMIT=0
BATCH_SIZE のデフォルトは 100 なので、大幅に増量。 登録してる feed がやたら多いんで、これが少ないとなかなか読みに行かなくなっちゃう…っぽい。 あと POLLING_PARSING_ERROR_LIMIT のデフォルト値は 3 で、 エラーがこの回数続くと feed を読みに行くのを止めちゃうっぽいんだが、 エラーが出るその feed だけ止めるのか (たぶんそうだろうと思うが)、 全体を止めちゃうのか、よくわかんなかったので、とりあえず無制限にしておいた。 この 2点は、しばらく (何時間たっても) 未読が増えなくなる挙動を見せたので、その対策として変えてみたんだけど。 なんか行き当たりばったりな調整だな。 そのうちちゃんと見直さないといかん。
他に、画面上でそのフィードがどのサイトのものなのかがパッと見分かりづらいので、 目立たせるために Web 側の設定画面からカスタム CSS を↓のように足した。
.item-meta-info a {color:#360; font-size:115%; font-weight:bold}
.entry-website a {color:#360; font-weight:bold}
> で、Miniflux を実際にちょっと使ってみて分かったこと。 未読一覧のトップ画面では、ttrss みたいにサイトごとに分けて表示できず、 時間順にぜんぶごっちゃに表示されるので、 見づらいし使いづらい…。 サイトによって、一応チェックはするけどほとんど読まずに飛ばしていいところと、 記事の内容次第では読んだり読まなかったりするところと、 更新されてたら必ず目を通しておきたいところと、いろいろあるんだが、 これらがぜんぶ混ぜこぜに表示されると、対応分けが超やりづらいんだよな。 あと ttrss では各フィードの見出し一覧に内容の冒頭もくっつけて表示される (できる) が、 miniflux では一覧画面では見出ししか表示しない (できない) ので、 パッと見で各フィードの内容を把握しづらい…。 フィード生成する側があんまりお利口でなかった場合、見出しの文章だけでは内容が把握しづらいことがままあり、 某 Web コミックスサイトなんかはフィードの見出しにサブタイトルと話数しか入れず、作品タイトルは本文に入れてるマヌケな仕様なので、 こうなると一覧表示画面だけでは、なんの作品の第○話なのかサッパリ分かんなかったりする。 なお見出しの文言がちゃんとしている場合でも、 本文の冒頭だけちらっと足して表示されているとその分、一覧画面で内容を把握しやすいんだな。 しかし Miniflux ではそのへんカスタマイズできるようにはなってないっぽい (ソースを自分でいじって改造するなら別だろうけど)。 というわけで、現在使ってる (レンサバにインストールしたやや古い版の) ttrss の完全な置き換えにはちょっとならないかも。 という、今のところはそんな感触なんだった。うーんそうか…。 動作が軽いのはいいんだけどなあ…。
> で、ttrss (TinyTiny RSS)。 Docker ベースでのリリースに移行してそっちしかサポートしないと宣言してるやつ、 これを Raspberry Pi 2 の ubuntu にインストールを試みたんだが。 ワシ、Docker の使い方とか概要とかまだあんまし理解できてないんだよな…。あんまりというかぜんぜんというか。 いや、ぼんやりした概念はわかるんだけど。ぼんやりどまりで。なんか、脳が理解拒否してる感じなんだな…。 で、この Docker 版 ttrss を Raspberry Pi 2 の ubuntu にインストールしようとしてみた訳だが。 考えてみると Docker ってアーキテクチャが違ったら入れられないんだったような…。 どうせ PHP なんだしアーキテクチャもへったくれもねえだろ、とかなんとなく勝手に思ってたんだが。 PHP コードはともかく処理系もまとめて Docker で入れるんだから、そりゃ動くわけがないのか。 よく見たら、ttrss のサイトにも Docker 版は x64 ベースしか対応しねえよって書いてあった。 積極的に間口を狭めていく Docker 開発陣。
仕方がないので、サポート対象外っつうホスト版の方のインストールを試みてみた。 これは別途 Web サーバやデータベースを自分で用意する必要があるんだが、 まあ PostgreSQL は動いてて設定もアカウントと DB 作るだけだし、 Web サーバも個人的に (Docker ベースの方の) nginx より分かりやすい Lighttpd で OK だし、 PHP ともども apt install でさくっと入るし、 大した手間ではない。 といいつつ Lighttpd の導入でちょっぴりてこずったが… (PHP 動かすのに。検索したら PHP のサイトのマニュアルに導入の仕方が載ってた)。
ttrss 側の事前の config.php 設定も公式のドキュメント見ながらつつがなく終えて、 ブラウザから初期設定するべくログインしたら、 JavaScript のなんとかいうメソッドが動かねえ、とかなんとかエラー表示のダイアログが出て、初期画面が出ないというオチ。 ワシがメインで使ってるブラウザは都合により若干 (だいぶ) 古いバージョンで、 最近になってぼちぼちと、JavaScript まわりが機能しなくてマトモに表示されないページが出てきていたんだが…。 といってもバリバリに JavaScript 依存の Twitter や Google 系サイトなんかはひととおりちゃんと表示されるんで、 JavaScript 駆使した画面表示に必須の機能が欠落している訳ではないんだよな。 なんでも新しけりゃ新しいほどいいと思ってる (かどうかは知らんが)、 後方互換とかそういうのをナニも考えてないバカな技術者が世の中にはけっこういるもんなんだな、と思って、 どうしても表示が必要な場合は他のブラウザで表示し直して済ませていたんだが。 実際この ttrss も他の最新版ブラウザではエラーもなくフツウに表示された。 いやーまさかメインのブラウザで常用する (予定の) フィードリーダがそんなバカ技術者の手によるものだったとは。っていう。
現在使ってるレンサバインストール版 ttrss はだいぶ前にアップデートを止めてたので (アップデートするとどこかバグっぽいヘンな挙動になったり、そのバグが長期間直らずホッタラカシだったり、 しまいにはエラーで動かなくなってやむなく rollback、がしばらく続いてイヤになった)、 今の ttrss がそんなことになっているとはぜんぜん気づかなかった。 というわけでインストールは成功して動作もとりあえず問題なかったものの、 ワシの環境では二重の意味で「使えない」シロモノだった。 まあ、かつて味わわされた不安定っぷりとか最近になっての Docker 版移行旧版切り捨てとかも考え合わせると、 この先も安心して使い続けられるかわからんので、 ttrss もぼちぼち捨て時だったのかもしれない (個人的に)。 最初の頃は実にいい感じで使えていたんだけどなあ。 まあしょうがないか。
> ttrss は捨てるとして、Miniflux だけでは心許ないので、 他の選択肢も引き続き物色中。 今のところ softoss と FreshRSS あたりを検討してみる予定。