2021-12-1 (Wed)
あと、ローカルでリンクがつながるよう修正済のこのサイトのコンテンツ一式を入れた zip ファイルって、 どれくらいダウンロードされてんのかなあ。 自由に手元にダウンロードしてブラウザで開いて閲覧してもらえれば、 なんならこのファイルを元にしてさらにミラーサイト作ってもらっても、 と思って載せといたんだが、 超今更だけど、そういえばそういう主旨とかぜんぜんなにも書いてなかったわい。 そのへんもあとで追記しておこう。ほんとに今更だけど。
2021-12-2 (Thu)
購入記録
- ●雑誌「まんがホーム」2022.1 芳文社
- らいか・デイズ (むんこ)
- 孔明のヨメ。 (杜康潤)
- 若王子主任は後輩ボイスに抗えない! (おりがみちよこ)
- 天国のススメ! (宮成樂)
- ぼくの上目遣い (市川なつを)
- ヲトメは義母に恋してる (桐原小鳥)
- 俺と式神の主従契約 (都ウト)
- ラブアマ (有村唯)
- オレの愛で世界がヤバい (井上とさず)
- スナックあけみでしかられて (松田円)
- 菓子男リノベーション (胡桃ちの)
- 座敷童子あんこ (エミリ)
- 幽霊さんのための科学的新仮説 (いわとびひろ)
- 先輩に推されて仕事になりません! (あしや稚浩)
- 天下分け目の小早川くん (真田寿庵)
- 恋はリベンジのあとで (辻灯子)
- 魔界の愛されCEOは元勇者 (さーもにずむ) (新連載)
- 歌詠みもみじ (オオトリキノト)
- うちの秘書さま (ミナモ)
- ウメボシオニギリ (よるどん)
- もんもん (熊野みみ)
- 目次4コマ:大掃除 (杜康潤)
2021-12-3 (Fri)
以前百均で買った、レンジでポーチドエッグ作る調理器具 (プラ製) をしばらく使ってみていたんだが、 バクハツを防ぐためにあらかじめ卵の黄身にフォークなどで穴を開けてください、 という注意書きに従って黄身に穴を開けておいても、 加熱の加減によってはバクハツする。 これは黄身の周囲の白身が固まってしまい黄身が封じ込められるため、とバクハツ現場の検証により判明した。 つまり結局のところ、加減を見ながら休み休み加熱しないとバクハツは免れないんであった。 この加減を見るのがけっこうメンドくさく、 またレンジでの加熱なので、加減によっては白身より先に黄身が固まっちゃうパターンもけっこう多く、 ワシの食いたいポーチドエッグ感が損なわれてしまうという欠点も露呈した。
で、レンチンはやめて伝統的な (フツーの) 作り方で何度か作ってみたんだけど。 長年愛用しているアルミの小鍋で湯を沸かして、 食酢をちょっと入れて (酢はあんまし好きじゃないのでニオイが立ちこめてちょっと不快…)、 卵を割り落として弱火で少し加熱して…。 しかしこれ掬うのがメンドくさいんだよな。 百均で穴開きお玉も買ってみたけど、 穴に白身の固まりの破片が詰まって湯が切れにくかったり…。 そのへんの、掬い切れなかった周辺の白身の破片も流しに流してしまわざるを得なくて、 なんかモッタイナイ感があったり。 そしてどうしても鍋にちょっとこびりつくので、洗うのがメンドくさかったり。 ポーチドエッグって、なんか非合理的な調理方法な気がどんどんしてくるんであった…。丸元淑生一押しな調理法なんだけどさ。 もしかしてコツがつかめたらもうちっと綺麗に作れるようになるかも、という一縷の望みで、もうしばらく続ける予定だが。 とりあえず、こびりつきにくい調理器具がひとつ欲しいな、 そういえばもう 10年ほど使っているフッ素樹脂加工のフライパン (26cm) もだいぶいろいろこびりつくようになってきたし、 一人分の調理にはやはりちょっと大きすぎることが多いし、 小さいめのフッ素樹脂加工のフライパンがひとつ欲しいな、と思っていたので…。 なお 26cm のフライパンもまだ捨てない。 フッ素樹脂加工品は数年ごとに買い換えるのが正解、みたいな話を見たこともあるけど、 なかなか捨てられないんだよねえ。また劣化のしかたもビミョウなんでさ…。 これの前に使っていた中国製のヒドいシロモノみたいにどうしようもない状態になっちゃったらもう諦めてスパッと捨てられるんだけど。
購入記録
- ●雑誌「まんがタウン」2022.1 双葉社
- 新クレヨンしんちゃん (臼井儀人&UYスタジオ)
- コミックエッセイ特集~BBQへ行こう!~ (市原ヒロシ/ボマーン/小池定路)
- 押しかけギャルの中村さん (おりはらさちこ)
- 派遣戦士山田のり子 (たかの宗美)
- 新婚のいろはさん (ÖYSTER)
- 相方が俺を好きすぎる (パン崎まろやか) (新連載)
- 勇者様!? こ…これってそういう意味ですかっ!?♥ (大場玲耶)
- かのんとぱぱ (おーはしるい)
- 野原ひろし 昼メシの流儀 (塚原洋一)
- かりあげクン (植田まさし)
- あさひ大家族 (ふじた渚佐)
- 兎なりのウサギさん (野広実由) (ゲスト)
- あの世で猫になる (東屋めめ) (ゲスト)
- 恋するスマホちゃん (橙夏りり) (ゲスト)
- 猫またはごはんを。 (湖西晶)
- 淑女の笑顔は崩れません (佐野妙)
- ルナナナ (小坂俊史)
- 鎌倉ものがたり (西岸良平)
- 大越春太郎は黙れない! (瀬田ヒナコ)
- 恋がわからぬ大人共 (赤のキノコ)
- 食欲しか勝たん! (えきあ)
- んじゃま、ここらでお茶にしましょうか。 (胡桃ちの)
- ●雑誌「週刊漫画TIMES」2021.12/17 芳文社
- めぐる未来 (辻やもり) (新連載)
- 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
- ごほうびごはん (こもとも子)
- 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
- 法廷のファンタズマ (荒川三喜夫)
- 神客万来! (ねむようこ)
- 瓜を破る (板倉梓)
- 経理の夏谷さんはガマンできない (財政ろろ)
- ヘルズボート136 (前田治郎)
- ダンナの童貞もらいます (神山とく)
- ヤバい女に恋した僕の結末 (沖田龍児)
2021-12-4 (Sat)
拙作の写真サイト作成ソフトを使っている父から、打上花火等の画像の色が冴えないとの指摘が。
不審に思って両画像をJPEGsnoopで調べてみると、Chroma subsampling値が2x2 (4:2:0)になっていました。JpegBitmapEncoder及びGDI+で生成したJPEG画像は、たとえ品質を最高に設定しても、かなりのダウンサンプリングが行われていることが分かりました。これはいかん…。
仕方ないので、libjpegを以下のように初期化して、1x1 (4:4:4)のJPEG画像を生成することにしました。
cinfo.comp_info[0].h_samp_factor = 1; cinfo.comp_info[0].v_samp_factor = 1; cinfo.comp_info[1].h_samp_factor = 1; cinfo.comp_info[1].v_samp_factor = 1; cinfo.comp_info[2].h_samp_factor = 1; cinfo.comp_info[2].v_samp_factor = 1;
2021-12-5 (Sun)
Jpeg のアレは「クロマ サブサンプリング」と言うらしい (バクゼンとした把握)。 libjpeg のデフォルトはこの「YCbCr のサブサンプリング比率」が 4:2:0 で、これだと色がボケて変色する。 劣化させんようにするには 4:4:4 に設定する必要がある、と。 で、あれ?ひょっとして…と思ってテストしてみたら、 perl の Imager モジュールも、node.js の sharp モジュールも、 jpeg 書き出し時の YCbCr サブサンプリング比率はいずれもデフォルトで 4:2:0 になっており、 カラー画像を jpeg 書き出しすると (画質設定を最高にしていても) 色褪せとボケが発生することを確認…。 そうだったかあ…ぜんぜん気づかなかった…。 ちなみに ImageMagick (convert) による変換ではデフォルトでサブサンプリングが 4:4:4 で書き出されていて劣化はなかった。 さすがに古株かつ専門のツールだけのことはあるな (なお明示的に変更・指定する場合は -sampling-factor オプションを使用する模様)。 GIMP での書き出しでも同様だった。 ただし、いずれも画質設定がデフォルトで割と高い状態で、 画質設定を変えた場合にどう変化するかとかは確認していない。
なお、sharp の方は jpeg 化する際、
.jpeg({chromaSubsampling: '4:4:4'})
などとオプションをつけてやることで劣化を防げる。
ただ、その都度つけないといけないので若干メンドくさい…。
Imager の方は、このへんのパラメータを指定する方法が今のところ見つかっていない…。
やりようはありそうな気もするし、なさそうな気もするし…。
検索してみたが情報は見つかってない。
元々ユーザ人口があまり多くなさそうな Perl の、割とマイナーな (?) モジュールだからな
(思いっきしダメ元でソースを見てみたんだがさっぱりワカランかった)。
しかし、Imager は個人的にいろいろと使っている割に、
大体 png で吐き出していて jpeg 出力はあまりやってないんで、
実害は今までのところあんましない (あっても気づいてなかった程度なのでよし)。
ただまあ、なるべく劣化させない方がよさそうな処理については、
一旦外部ファイル (png) に書き出してから ImageMagick で jpeg 変換するように変更した。
しかし、そうかァ…。Imager 便利なんだが残念だなあ…。
2021-12-6 (Mon)
2021-12-7 (Tue)
それにしてもいつも思うんだが、なんでワインて大抵どれもやけに苦いんだろう…。 白はそうでもないが、赤系はロゼでもけっこう苦い。 メルシャンビストロ赤甘口 (ほとんどぶどうジュース)、くらいがちょうどいい感じなんだがなあ。 いやまあ、イヤなら飲まなきゃいいだけの話か。
2021-12-8 (Wed)
2021-12-9 (Thu)
2021-12-10 (Fri)
数十~数百枚セットの PNG 画像 (スクリーンショット) の、共通のクロップ (切り抜き) 範囲を調べて、全画像同じ位置でクロップして、 JPEG に変換して保存する、というだけの処理なんだが。 まず共通のクロップ範囲を調べるために 1回、 実際にクロップして JPEG に変換して吐き出すために 1回、 つまり各画像 1枚につき 2回ずつ PNG ファイルの読み込みとデコードをやらないといけない。 一連の読み込み処理は関数呼ぶだけだから別に手間ではないんだが、 ファイル読み込みと PNG のデコードの処理時間のオーバーヘッドがどれくらい影響あるのかなあ…とちょっと気になっていた。 1回目に読み込んだ画像データをそのままメモリに保持しておければいいんだが、 デコード後のバッファに展開した状態だと、 アルファチャンネルを削除した RGB データでもピクセル数×3 バイトの容量を食う。 元画像サイズが 3120×1440 なので、1画像あたり 13MB 程度…。 まとめて処理するファイル数が、多い場合は 400枚とかなのでおよそ 5GB (もっと多い場合もたまにある)。 メモリがいつもカツカツ状態なウチの環境だとちとキビシイ…。 やりたい仕事の割にリソース食いすぎ感がある。 だが PNG をデコードせずに元画像のままメモリ上に読み込めば、 各画像 2回ずつデコードするオーバーヘッドは防げないが、 遅い物理ストレージアクセスを 1回ずつで済ませられて多少は処理が速くなるんではなかろうか(*10-1)。 その場合必要な合計サイズは実際の元画像達をざっくり調べたところ、数百 MBから多くてもせいぜい 1GB 程度…。 それでもけっこうでかいはでかいけど、これくらいならメモリ食い潰してシステムをハングさせるようなことはたぶんない (システムハングより先にメモリ確保処理がエラー吐くかもしれんけど)。
で、libpng でファイル (FILE 構造体) 経由のかわりにメモリ上の PNG (ファイルイメージ) そのものを直接読み込む方法がないかな…と思い、 libpng の英文ドキュメントを DeepL に突っ込んで翻訳して(*10-2) 途中まで読みかけたところでふと、 そもそも C のライブラリに、メモリ上に置いたファイルをオープンするみたいな関数がありそうだよな…と気づいた。 で、ザツに検索してみたところ、mmap() でメモリ上にファイルを展開し、 fmemopen() で展開先をファイルとしてオープンしてやれば、 直接 fopen() でファイルをオープンするのと同様に扱えそうなことが分かった。 なるほど…。 テストで書いてみたコードも cygwin 上で問題なく動作したので、今更だけどまたちょっと手を加えてみている…。 ヒマ人だね…。
2021-12-11 (Sat)
なんでメールアプリいくつもインストールしてんだよ、と自分でも思わなくもないが…。 同じカテゴリ内のアプリでも、それぞれの機能が微妙に補完し合うので複数インストールしてるような場合もあるけど。 メールアプリはそういう性質のモンでもないから、複数並行して使うメリットはまあないんだわな。 いやーでもソフトウェアっていろいろあるからさ…。 バージョンアップでダメになったりとか、 逆にバージョンアップ止まっちゃって (プラットフォーム側の仕様変更に追随できずに) 使えなくなったりとか。 イザって時に切り換える用の予備がないと、なんとなく心許ないと思っちゃうんだよねえ…。 つっても現状スマホでメールは受信にしか使ってないし、 メールアプリの重要度は実際はそんなでもなかったりするんだけど。
購入記録
- ●雑誌「まんがタイム」2022.1 芳文社
- おとぼけ部長代理 (植田まさし)
- レーカン! (瀬田ヒナコ)
- 花丸町の花むすび (むんこ)
- ラディカル・ホスピタル (ひらのあゆ)
- 大家さんは思春期! (水瀬るるう)
- 軍神ちゃんとよばないで (柳原満月)
- 百合のあいだは悩ましい (森井暁正) (ゲスト)
- 六畳一間の憑き物石 (西岡さち)
- ローカル女子の遠吠え (瀬戸口みづき)
- この契約は恋まで届きますか? (雪尾ゆき) (ゲスト)
- 瀬戸際女優! 白石さん (櫻井リヤ)
- お酒は20日になってから!! (えのまなみ)
- テレパス皆葉と読めない彼女 (諸田トモエ)
- 冷めないふたりのひとりご飯 (きたむらましゅう)
- 茨城ってどこにあるんですか? (真枝アキ)
- 良倉先生の承認欲求 (G3井田)
- 秘密のお姉さん養成ノート (トフ子)
- 女神に胃袋つかまれた! (町田すみ)
- お天気おねえさんの晴れ舞台 (きなこ)
- 午前0時のおねだりごはん (あきさと)
- 目次4コマ:つながれ! 黒電話ちゃん (瀬田ヒナコ)
- ●雑誌「まんがライフオリジナル」2022.1 竹書房
- おんぼろ花ハイム (むんこ)
- ちぃちゃんのおしながき (大井昌和)
- 森田さんは無口 (佐野妙)
- のみじょし (迂闊)
- リコーダーとランドセル (東屋めめ)
- しょうもないのうりょく (高野雀)
- 雑兵めし物語 (重野なおき)
- ねこようかい (ぱんだにあ)
- ずぼら先輩とまじめちゃん (東385)
- 黒影夜子の駐在日誌 (唐草ミチル)
- 鬼桐さんの洗濯 (ふかさくえみ)
- ここは鴨川ゲーム製作所 (スケラッコ)
- はかせの未来 (せかねこ)
- ギャル医者あやっぺ (長イキアキヒコ)
- ばつ×いち (おーはしるい)
- ハッピーアワーガールズ (揚立しの)
- なごみクラブ (遠藤淑子)
- ネコぐらし (深谷かほる)
- となりの席の同居人 (神仙寺瑛)
- 中年女子画報 (柘植文)
- もぐもぐガーデン (宇仁田ゆみ)
- セトギワ花ヨメ (胡桃ちの)
- そしらぬディスタンス (松田円)
- とーこん家族 (よしもとあきこ)
- よそじとふたごのメシ事情 (小坂俊史)
- ぼのぼの人生相談 (いがらしみきお)
- 異世界にマンガ家が転生したらどうなるのか、描いてみた件 (マツオカヨシノリ)
- 全ての映画は、ながしかく (施川ユウキ)
- 目次4コマ:ポポ時評 (施川ユウキ)
- ●雑誌「ヤングコミック」2022.1 少年画報社
- おねーさんが侵略中!? (さんりようこ)
- イケナイ菜々子さん (あさぎ龍)
- ヤンキー娘になつかれて今年も受験に失敗しそうです (ジェームスほたて)
- ゾンビだらけのこの世界ではセックスしないと生き残れない (実倉なる)
- 13Fの秘蜜 (桂よしひろ)
- 見たいもの見せましょう (たまはがね)
- まぐわい部屋の管理人さん (東雲龍)
- 31歳地味眼鏡OLさん (新居さとし)
- けろよい新潟弁酒場 (花見沢Q太郎)
- スカートの裾掴むボクの手が今も震えてるのは…… (佐野タカシ)
- いいわけも出来ない -姉彼- (水島空彦)
- 元女勇者35才 (蛇光院三郎)
- エロ漫の星 補習編 (金平守人)
- ●雑誌「週刊漫画TIMES」2021.12/24 芳文社
- 雑貨店とある (上村五十鈴)
- 信長のシェフ (梶川卓郎)
- 妻、小学生になる。 (村田椰融)
- 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
- めぐる未来 (辻やもり)
- 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
- ぼっちの僕に強制彼女がやってきた (栗ののか) (コミックトレイル出張掲載)
- 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
- ヤバい女に恋した僕の結末 (沖田龍児)
2021-12-12 (Sun)
なお現在。記憶が揮発しながらも C のポインタ周りはおおよそは把握できてたつもりでいたんだけど、 ポインタと配列と構造体がいくつも入れ子になってるような時にどう領域を確保してどう保持してやればいいのかとかで、かなり混乱している。 主に文法的なあたりで。 エイヤで書いて、コンパイラ (-Wall) がエラーや警告を吐くかどうかでチェックして、 試しに実行してコアダンプ吐いたら見直す、みたいな (ヒドい)。 C のポインタ周りがメンドウなのは、文法がちっとばかしアレなせいだよな…。主に。 Perl の参照の書き方の方が個人的にはわかりやすい。気がする。慣れの差もあるだろうけど。
蛇足的脚注
- *12-1 : 連続した文字列リテラルはひとつながりに扱われる
-
こんな感じのやつ。特に意味のないサンプルだが。
#define XX "def" char *str = "abc " XX "+ghi" "-jkl-"; printf(str); // "abc def+ghi-jkl-"
2021-12-13 (Mon)
複数 PNG 画像ファイルを、ストレージから 2回ずつ読み込まずに、 1回めの読み込みで (mmap で) まるごとメモリ内に保持しておき、2回めは (fmemopen で) メモリから読み出すことで、 ストレージアクセスのオーバーヘッドを軽減して処理時間を稼げないか、という実験。 やってみたところトータルの処理時間はほぼ変わらなかった。というか、ぜんぜん変わらなかった…。 つまり、ファイルの読み込みよりも PNG のデコード (展開) の方がはるかに処理時間がかかるってことだな。 で、次に PNG を読み込んでデコードしてバッファに展開済のデータを、都度削除せずそのままメモリ上に保持する方法で、 どれくらいトータルの処理速度が上がるか実験してみた。 これはファイル数があまり多いとメモリ食い潰す可能性があるんだが… (もしくはメモリを確保できず異常終了するか。システムがハングアップアップしない分そっちの方がいい)。 とある一組のデータ (ファイル数 67) で実験したところ、2回読み込み & デコードだと 25秒かかるところを 15秒で完了した。 けっこう高速化できとる。そして JPEG のエンコードは PNG のデコードに比べてかなり速いらしいこともわかった。 そのかわり実行中にメモリを 700MB くらい食ってたが、まあこれくらいのメモリ使用量ならなんとか大丈夫かな…。 ファイル数にもよるだろうけど。
影響を受ける最初のバージョン(2.0-beta9)のリリース日は2013年9月14日である」。ほー。 2013年にもなって…。
蛇足的脚注
- *13-1 : 限界
- これ、よくよく考えてみたらたぶんウチの cygwin が 32ビット版だからだな。 だから 4GB で頭打ちになったんだ (最初は 64ビット版をインストールしたんだが、うまく動かなかったもんで、やむなく 32ビット版を入れ直したような記憶がある…。 なんでうまく動かなかったのかはいまだにナゾだが)。
2021-12-14 (Tue)
で、知りたかったのは画面の向き、縦向きか横向きか、だけなんだけど。 スマホの向きを知るのに、どのセンサーのどの値をどう見ればいいのか、よく分からない…。 なんか、地磁気センサーと重力センサーの値を行列演算して求める、的なフンイキなんだけど…。 でもワシのスマホ (X5-LG) で見てみると、 (検索結果で見る限りでは Android 2.2 で廃止されたとかいう) Orientation Sensor ってのがあって、 問題なく機能してるみたいなんだよな…。 でもってこれだと返ってきた JSON データ内の 3つめのパラメータが 0 付近だと縦向き (上下問わず)、 90 付近だと画面上部が向かって左側に来る横向き、-90 付近だとその逆の横向き、とすこぶる分かりやすい (画面が地面に対して鉛直に近い向き前提での検証結果)。 どーせ自分専用のスクリプトなんだしこれ使っとけばいいや、と日和ることにした。 そのうち、他のセンサーでスマホの向きを調べる方法も、一応ちゃんと調べておこう…。まあ機会があったら。 画面の縦横だけ調べるなら重力センサーだけ見とけばいい気もするし。
~$ termux-sensor -n1 -s "orientation sensor" { "LGE Orientation Sensor": { "values": [ 4.6875, -59.08214569091797, -2.5268800258636475 ] } } ~$スマホの画面のスクリーンショットを連続処理するスクリプトで、 縦向きの時と横向きの時で処理内容 (クロップ座標) が違うので、 これまでは各向き用に別々のスクリプトを作っておいて、 人間 (ワシ) の方で使い分けてたんだけど。 スクリプトからスマホの向きが判別できるようになったんで、 スクリプトを一本化して修正とか管理がちょっとラクになった。
2021-12-15 (Wed)
個人的には 2015年に円谷が公開した映像が好きだな。 ちょっと筋肉むきむきすぎる気もするけど。
なおリバーライトという別メーカー製でこれと似たような素材の「極JAPAN」という商品もある模様。
2021-12-16 (Thu)
Support oAuth providers? (#49) ・ Issues ・ Dystopia Project / Simple Email ・ GitLab によると、
Support oAuth provider would help user to have an easy way to setup the email provider with oAuth by default such as Yahoo/Gmail etc, but it require have dev account on each of those non-free provider in order to get the client_id authorization. must e a generic oAuth authentication without provider libs.
oAuth プロバイダをサポートすることで、Yahoo/Gmail などのメールプロバイダをデフォルトで oAuth に設定する簡単な方法をユーザに提供することができますが、client_id 認証を取得するために、これらの非フリーなプロバイダのそれぞれで開発者アカウントを持つ必要があります。プロバイダライブラリを使わない、一般的なoAuth認証である必要があります。最新版 version 1.4.0 (2020-11-09) の Change Log には
(DeepL による自動翻訳 : 原文中の「e」はおそらく「be」の typo なので「be」に直した上で翻訳した)
Bug Fixesとあるので、敢えて対応してないっぽい(*16-1)。 まあ Open Source だし、ライセンスは GPL v3.0 だしね。
- gmail authentication over non-oAuth (15cc220)
蛇足的脚注
- *16-1 : 敢えて
-
SimpleEmail で Gmail の設定画面を開くと、
Requires have non-oAuth authentication enabled. More info.
と表示されていて、More info がリンクになっているのでタップすると、Since January 2020 Gmail restricted the OAuth scopes, now requires authorization to be able to authenticate, we are looking the best way to fix oAuth authentication without privative libraries.
As a temporary solution you need to allow normal authentication or how Google says "less secure apps".
2021-12-17 (Fri)
つーか Gmail (Google) が OAuth はアンゼン、未対応はキケン、ってしつこいのは、 そもそも Gmail の ID (アカウント) とパスワードがあればメール以外の全サービスにアクセスできちゃうからだよな…。 Google の場合…。 だからメールクライアント (アプリ) に ID とパスワードを使わせたく (渡させたく) ないと。 Google のサービスでログインが必要なものって、 最初の頃は Gmail くらいしかなかったと思うんだが (あまりちゃんと覚えてないけど)、 それが後からいろんなサービスを追加していって、 それら全部にひとつのアカウント (ID + パスワード) でアクセスできるようにしちゃったのがイカンのじゃないのかね。 だから「ID とパスワードでメールを利用するのが危険」なのはどっちかつうと Google の勝手事情の方が大きいんではないか。
メールサービスを利用するためのプロトコルは昔から今に至るまで SMTP や POP や IMAP がスタンダードだし (暗号化とかいろいろ変化はあるけど)、 Gmail も現在でもこれら SMTP や IMAP などのアクセス手段は (渋々、といった感じではあるが(*17-1)) 提供し続けてるんだから、 Gmail は専用のログインパスワードを (Google アカウント共通のパスワードと排他的に) 設定して使えるようにすれば、 つまり OAuth の強要か Gmail だけパスワードを変えるか、選択させてくれれば、 Google の OAuth に対応しない一般的なメールクライアントもキケンキケンと目の色変えずに使えると思うんだがな。 でもたぶんそれは Google 側の事情や都合でできないか、あるいはできてもやりたくないんだろうな。 で、ユーザはメールクライアントの選択の*不*自由を強いられ続ける、と。 でもこれを特に不自由と感じないユーザの方がたぶん多いんだろうなあ…。 Google の方向性を考えると、将来的に OAuth オンリーに制限する可能性もあるっぽいし…。 まあもしそうなったら Gmail 使うのヤメればいいだけの話だけど。 メアドが必要なだけなら、現状、借りてるメールサービスの方で無限に作れるし… (ドメインがユニークになるから匿名性はないけど)。 フリーメールサービスも他にたぶん探せばありそうだし。 aol.jp ってこれまで使ったことなかったな…。 AOL ってあんましいいイメージはないけど…。機会があったら試すだけ試してみようかしら。 あれ、今は米 Yahoo! が運営元なのか。
蛇足的脚注
- *17-1 : 渋々
- Google Workspace (旧名 G Suite) とかいう有料サービスのユーザは、 現在 OAuth 非対応のクライアントからは (メールに限らず Google のサービスに) 一切アクセスできなくなっているらしい…。
2021-12-18 (Sat)
2021-12-19 (Sun)
Gmail は、受信メールの転送と、その際受信メールをメールボックスに残すかどうかと、 IMAP や SMTP や POP でアクセスできるようにするかどうかをそれぞれ別個に設定できるが、 Yahoo! の場合、受信メールを他アドレスへ転送する設定にすると、Yahoo! のメールボックスにはメールを残せず、 当然 SMTP や IMAP などでのアクセスもできない。 Yahoo! のメールボックスでの受信か、全面的に他アドレスへの転送か、の二者択一。 理由は不明。
Yahoo! のメールボックスで受信する設定の場合、 Yahoo! 製メールクライアント (アプリ) のみ使用できるモードと、 一般的なメールクライアントから SMTP や IMAP などでアクセスできるモードを選択できる (というより選択させられる) ようになっている。 フツーに一般的なメーラから使いたいのであれば、 後者のモードに設定しておけばいいだけじゃん問題ないじゃん、と思っちゃうわけだが、実はこいつが罠で、 以前スマホでメールアプリをいくつか試していた時に、 Yahoo! お得意のワケわかんねえチェックシステムが炸裂して、 異常なアクセスがあったとかなんとかで勝手にアカウントをロックされ、 パスワードを強制的に再設定させられたことがあった。 Google や Twitter なんかは「普段とは違う環境 (IP、クライアントなど) からのアクセス」があるとその旨通知してきて、 正常なアクセスかどうか確認を求める、という仕組みが動いているが、 確認を求めるもへったくれもなく強制的に無効化するところがいかにも Yahoo! らしいクソなやり口。 ちなみに Yahoo! からアヤしいアプリと決めつけられたのは Google Play ストアから一千万以上ダウンロードされて評価も 4.2 と高評価のメールアプリだった。 そんな調子で、Yahoo! のメールボックスに SMTP や IMAP や POP でアクセスしてると、 いつまた Yahoo! お得意のワケわかんねえチェックシステムが炸裂するか分からんので、 結局専用の転送先アカウントを外にひとつ作って、 現在はそっちへ全部転送する設定にしている。 外部のマトモなメールサービスなら普通に SMTP や IMAP や POP でアクセスできて勝手にアカウントロックとかもしないからね。 メールは転送する運用だと本来の送信先と実際に受信するアドレスが一致しなくなって、 送信や返信の時にちょっとだけ面倒になるんだが、 この Yahoo! アカウントからは送信する機会が皆無なのでその点は問題ない。 読む方もどうせ広告とお知らせしか来ないし。 でもって外部へ転送させるだけなら Yahoo! システム側でもお得意のワケわかんねえチェックが炸裂する機会もないだろう、と。 思うんだがどうだろうな…。 どういう隙を突いてくるか分かんないからなあ…油断は禁物かもしれんな。
2021-12-20 (Mon)
無料の Dynamic DNS サービスをいくつか試していたのは、 現在ワシの借りてるレンサバに人様のコンテンツを預かって置いているんだが、 これを先行き別サーバに引っ越しする時に備えようと思ったため。 今のうちに Dynamic DNS のドメインに切り換えておけば、 将来サーバ (置き場所) を引っ越す時、またはコンテンツを元の持ち主のコントロール下 (サーバ) に返還した時、 その移動先が Dyrnamic DNS に対応していたならドメイン (アクセス URL) をそのまま維持できて、 URL 変更をいちいちアナウンスしなくてもいいし便利かな、と思ったもんで。 結局、コンテンツ返還はまだだいぶ先になりそうな感じだし、 返還した暁には無料の Web サーバに置く予定みたいなので Dynamic DNS への対応はムリそうだし、 ウチのサーバ (置き場所) も移動せずにそのまま置き続けることにしたので、 まああんまし意味なかった。
引っ越すのをヤメた後も Dynamic DNS のお試し利用を続けていたのは、 将来的に別ドメインを使いたくなった時用にちょっと、 各サービスの長期使用時の使い心地とか知っておけたらいいかな、というスケベ根性 (?) で。 ただ実際に (当事者を除き) 通知も告知もしてないから、誰にも利用されてない状態でほったらかしになっていて、 これじゃ検証にはなんないよなー。
購入記録
- ●雑誌「週刊漫画TIMES」2021.12/31 芳文社
- まどろみバーメイド (早川パオ)
- 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
- 神様のバレー (原作:渡辺ツルヤ/西崎泰正)
- パスタの流儀 (原作:花形怜/才谷ウメタロウ)
- ごほうびごはん (こもとも子)
- 巨匠 (Gたかし/高橋一仁)
- 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
- めぐる未来 (辻やもり)
- ヤヌス -鬼の一族- (琥狗ハヤテ)
- ヘルズボート136 (前田治郎)
- うそびっち先輩 (音井れこ丸)
- ヤバい女に恋した僕の結末 (沖田龍児)
2021-12-21 (Tue)
購入記録
- ●雑誌「主任がゆく!スペシャル」Vol.166 ぶんか社
- 主任がゆく! (たかの宗美)
- 金髪女将綾小路ヘレン (たかの宗美)
- 精肉部門の未藤さん (市村) (ゲスト)
- 隣のショタがまるで嫁 (道野ほとり) (短期集中連載)
- 企画:北見主任&ヘレン女将 大解剖!!
- 企画:漫画家さんがかつて経験したお仕事を告白! 吉野がゆく! (そめい吉野)
- 企画:主任作家陣が描く「私のオススメ都道府県」 (千石のりお/袴田めら)
- あい・ターン (おーはしるい)
- マチ姉さんのポンコツおとぎ話アワー (安堂友子)
- 嫁姑は仲良くケンカする (大江しんいちろう)
- 若奥様は侵略中 (佐野妙)
- モノズキ散歩、お茶して癒やし♥ (胡桃ちの)
- 花野さんとの縁結びは難しい (野広実由)
- 双子コンプレックス (おりはらさちこ)
- ファニーランドの鬼ババア (むんこ)
- それいけ! せっぷく丸 (大塚みちこ)
- ゆるふわと情熱のあいだ (袴田めら) (最終回)
- おるすばんごはん (王嶋環)
- 群馬犬! (安西理晃)
- くそじいじとカメラと私 (うず)
- 農学女子 (そめい吉野) (最終回)
- きっこと申します。 (海野倫) (最終回)
- カメのまんねんさん (千石のりお) (最終回)
- 目次4コマ:ゆるゆる4コマ (たぁぽん)
2021-12-22 (Wed)
でも包丁の赤茶けた汚れ (?) ってメラミンスポンジで綺麗になるんだなあ。 磨き始めて早々に指を切っちゃったから中途半端なところで終わっとるけど。 またそのうち、手を切らないようになんか工夫して続きをやろう。
2021-12-23 (Thu)
console.log(0.1 + 0.2);
」は「0.30000000000000004
」と表示されるのか。
JavaScript では全ての数値が内部的には 64ビット浮動小数点数 (IEEE 754 倍精度浮動小数点数) で扱われているらしい。
Perl でやったら「
perl -E 'say 0.1 + 0.2;'
」は「0.3
」と表示された。
「perl -E 'say 0.1 + 0.2 - 0.3;'
」だと「5.55111512312578e-17
」と表示された
(つまり 0.0000000000000000555111512312578?)。
ある程度の誤差は表示時にまるめてくれるのかな…。
その閾値が JavaScript と Perl でちょっと違うってことか。
ちなみに「
perl -E 'say 1 + 2 - 3';
」だと「0
」になる。
Perl は整数は整数として扱うので。
→YouTube の feed を取得してそれを加工して…という手順だったっぽい。 そうか YouTube でチャンネル別に feed が取得できるなら feed reader でチェックすればいいや (個人的には)。
channel の feed → https://www.youtube.com/feeds/videos.xml?channel_id={CHANNEL_ID}
user id の feed → https://www.youtube.com/feeds/videos.xml?user={USER_ID}
内容とは関係ないけど、github.io の吐き出す (?) HTML ってなんかむっちゃくちゃだな…。
kenokabe先生のヤバさについては https://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b とかも参考に。」 とあったレビュー記事。 つーか著書があったのかこの人。出してるの秀和か…秀和も昔 (だいぶ昔) はいい方にトンガった本出してたんだけどな…。 ヤバさ、というのは記事や主張の内容だけでなく、 自記事 (自著) への批判批評に対する (別名をいくつも駆使した) 執拗に執拗を重ねた粘着的攻撃や荒らしなど、のあたりっぽいな… (コメントの方が本記事よりはるかに分量が多い。しかも荒らしアカウントの書いた分はほとんど運営に削除されてるにもかかわらず、という…)。
2021-12-24 (Fri)
購入記録
- ●雑誌「週刊漫画TIMES」2022.1/7-14 芳文社
- ヤバい女に恋した僕の結末 (沖田龍児)
- 信長のシェフ (梶川卓郎)
- 妻、小学生になる。 (村田椰融)
- 解体屋(こわしや)ゲン (原作:星野茂樹/石井さだよし)
- まどろみバーメイド (早川パオ)
- ごほうびごはん (こもとも子)
- 法廷のファンタズマ (荒川三喜夫)
- パスタの流儀 (原作:花形怜/才谷ウメタロウ)
- 第三内科外来の魔女 (原作:宇治谷順/後藤圭介)
- 瓜を破る (板倉梓)
- こいくちルームシェア (ハルミチヒロ)
- ダンナの童貞もらいます (神山とく)
GC は日本語ではよく「ガベージコレクション」と書かれているが、 「ガーベジコレクション」「ガーベッジコレクション」「ガーベージコレクション」などの表記もある。 個人的には「ガーベジコレクション」が一番しっくりくる。 たぶん元の発音を一番よくなぞってるんじゃないかという気がするので (非ネイティブによる勘)。
ぜんっぜん関係ないけど「居残りガベージ」って駄洒落をさっき思い付いたのでメモっとく。 GC と落語の「居残り佐平次」を両方知ってないと通じない…両方知ってても通じないかも…。
なお、現時点ではBASIC言語だが、JSやFORTH、Python、Rubyライクな4言語でプログラミングできるIchigoLatte版もリリース予定としている。おお FORTH。Lisp もあるとええな。Perl は? Ruby ライク、ってどんなんだ。
2021-12-25 (Sat)
購入記録
- ●雑誌「まんがタイムオリジナル」2022.2 芳文社
- ラディカル・ホスピタル (ひらのあゆ)
- らいか・デイズ (むんこ)
- おしかけツインテール (高津ケイタ)
- となりのフィギュア原型師 (丸井まお)
- ネコがOLに見えて困ります (鳴海アミヤ)
- 冷めないふたりのひとりご飯 (きたむらましゅう)
- 可愛い上司を困らせたい (タチバナロク)
- おだまき君の道草ごはん (佐倉色)
- おひとり好きの富士宮さん (イチノセ)
- ミッドナイトレストラン7to7 (胡桃ちの)
- 小森さんは断れない! (クール教信者)
- 夏っちゃんはととのわせたい (らぱ☆) (ゲスト)
- 鈴宮さんのダジャレをスルーできない (ため)
- Dr.こよりの美味カルテ (按図よしひろ)
- 負け恋。 -ずるい恋の始め方- (近衛桜月)
- 止まった世界の歩き方 (おたき)
- カントリー少女は都会をめざす!? (鬼龍駿河)
- 敷金礼金ヤンキー付き (namiki)
- 葉山さんのまんがの泉 (Aki-ra)
- 通勤通学クエスト (金田ライ)
- 氷室君は板野さんの事が覚えられない (かわのゆうすけ)
- オネェの恋のはじめかた (真木たなひ)
- 目次4コマ:やくみつるのズバリ!!一発勝負!! (やくみつる)
2021-12-26 (Sun)
Simple シリーズは過去にカメラとか住所録とかダイアラーとかいくつかインストールして試してみたものの、 どれもいまいちピンと来なくて結局ぜんぶアンインストールしちゃって使ってなかったんだが。 このシリーズの住所録 Simple Contacts にデータを入力しても Google の連絡帳には反映されなかった。 当然、一般的な (Google の連絡帳と連動する仕様の) 他のダイアラーの履歴にも反映されない。 ただし、この Simple シリーズのダイアラー Simple Dialer にだけはちゃんと反映される。 つまり、Google の連絡帳と連動させずに電話番号 DB を使いつつ電話をかけたり受けたりしたい場合は、 Simple Contacts と Simple Dialer を組み合わせて使えばいいという訳だ。
…ただ、これらのシリーズは過去にいまいちピンと来なくてどれもアンインストールしただけのことはあって、 住所録はともかくダイアラーの方は履歴表示の着信と発信の見分けがすげえつきづらい。 そのへんの表示のカスタマイズもできるようにはなっていないようで、 これは常用はむずかしいな…という個人的な感想。 うーん惜しいなあ。 惜しいけど結局アンインストールした。 …基本無料なんだけど、よく使われそうなアプリに関してだけちまちまと機能に制約をつけて、 カネ払ったら解除するよ、という姿勢なところも、ちょっと忌避感を催させてくれて、アンインストールの後押しになった面は否めない… (個人的嗜好の問題)。
Google の連絡帳と非連動な (そこんところが一番大事)、無料で (安価で、でも可) 広告表示のない、 デザインがよくて見やすくて使いやすい住所録とダイアラーのセットは他にないだろうか…。 まあデザインは二の次でもいいや。見やすくて使いやすければ…。
自分で作れれば自分で作るんだけど大変そうだしなあ…。
2021-12-27 (Mon)
発端は…たぶん、さかのぼって昨日かそこらに、node.js で動く htmllint (html の文法チェッカー) がある、という記事を見かけたところから。 いつものように、 Windows のコマンドプロンプトから node.js のインストール先ディレクトリに移動して、 なにもオプションをつけずに「npm install {モジュール名}」でインストールを試みてみたが、 その後 htmllint と打っても htmllint-cli と打ってもなんの反応もなく…。 なんだ? インストールされてないのか? 特にエラーの表示も出なかったんだけどな…ヘンだな…まあいっか、とそのまま放ったらかした。 たぶんこれが関係あるんじゃないかなあとは思うんだが。確証はないんだが。
今日になって、毎日のルーチンである某無料コミックスサイト (公式) から無料で拾える (& 自分が読みたい) 範囲のコミックスを、 いつものスクリプトでダウンロードしよう、としたところ、 なんと、起動した早々スクリプトがエラーを吐いて動作しない。 node.js は英文でいちいち丁寧に原因の説明ドキュメントを吐くんだけど、 英文なんでいまひとつピンと来ねえもんで、 そしてシロートなもんで、こういう時にむやみやたらと再インストールしたりアップデートをかけようとするんである。 そういえば昨日も htmllint のインストールができてなかったみたいだし、 バージョンが古かったりして不整合でも起きてるのかな… もういっそ、node.js 本体を最新のに入れ替えちゃおうか、と 16.* のインストーラをダウンロードして実行したら、 node.js 16 は Windows 8 以降でないと対応しねえよ、と言われてインストーラが勝手に中断してしまった。 ちなみにそれまで動いていた node.js は 12.18 なんで、まあ version 12 台の最終版なら入るだろうと 12.22 を拾ってきて、 本体のインストールは無事終わったものの、次にコマンドプロンプトが (実際は Powershell だったっぽいが) 起動して、 なにやら追加インストールしようとして盛大に赤い字でエラー (英文) を吐いて落ちた。 そして 12.22 の node.js で npm がエラーを吐いてマトモに動かない。 再度 node.js 12.22 のインストールからやり直してみたが結果は変わらず。 ちなみにバッチファイルが powershell を立ち上げて導入しようとしていたのは node.js 環境用の python と、 chocolatey とかいう Windows 用のパッケージマネージャだったらしい… (あとで chocolatey を単独でインストールしようとしてみたが、 これも最新版あたりは Windows 8 以降でないとダメらしくインストールできなかった…そして古いバージョンは拾えなかった…ので捨てた)。
その後、いろいろ検索してみた過程で、version 14 が (本来 Windows 8 未満では動作の保証はされないが) インストーラからではなく zip から直接ファイル展開でインストールできないこともない、 というような記事を見かけたので、試してみた。 しかし npm や node.js を起動しようとすると、 「プロシージャエントリポイント GetHostNameW がダイナミックリンクライブラリ WS2_32.dll から見つかりませんでした。」 とダイアログが出て起動もできない。 検索してみてもあまりちゃんとまとまった情報も得られなかったが、 たぶんこれは Windows 8 以降には標準で入ってるやつとかなんだろうな…。
次に、それならと 12.22 をインストーラからでなく zip を展開して入れてみたところ、 node.js のインストールも、npm での インストールもできたものの、 chalk をインストールしてスクリプトから require するとエラーが出る。 このへん調べてみてもあんましよくわかんなかったんだが、 node.js のモジュールに CJS という require で読み込むやつと、ESM という import で読み込むやつの 2通りがあって、 どうも chalk は以前にインストールした時と仕様が変わって import で読み込まないといけなくなったっぽい。 しかし、node.js 12 は import による読み込みには対応してないっぽい…。 詰んじゃったじゃん…。 import に対応するようになったのが 13.* (忘れた) 以降から、とのことなので、 またまた zip から version 13 の最終版をインストールし直したが、 エラーの出る状況は変わらず…。 chalk は文字表示時の色づけにしか使ってないので、もう他のモジュールなり、いっそ自前のエスケープシーケンスでもいいや、と捨てることにした (colo、というモジュールで代替)。
次に、自前のスクリプトでは欠かせないモジュールの clipboardy がこれまた、import で読み込むように仕様が変わってやがった…。 これも読み込ませ方を (英文のエラーメッセージやら、検索して探した関連記事やら見つつ) いろいろやってみたがダメ。 クリップボードとのやりとりといってもクリップボードの内容をチェックする、つまり読み出すだけなので、 これは自前でクリップボードの内容を標準出力に吐くだけの外部ツールを作って、 そいつを呼び出すようにすりゃええか…と思って(*27-1) clipboardy も捨てることにした…。 クリップボードの読み出しは、cygwin からなら /dev/clipboard を読めばいいだけなのでとてもカンタンなんである。 で、cygwin 上で C でちょこっとテキトウなツールを書きーの (自分しか使わないので安全性とかわりとテキトウ、バッファあふれさえなければよし)、 これをスクリプトから読みだしーの、でなんとか代替。
よし! これで元のスクリプトが動くようになったわい…なったかな…? たぶん大丈夫だよな。 と思って某サイトのコミックスの画面キャプチャを取り始めたら、…なんとこれがうまく動作しない…。 このタイミングでよもや、サイトの仕様変更でもあったのか…!? (まあよくあるパターンだけど) と思って、ページの HTML 構造を確認する用のテストスクリプトを走らせてみたが、 こっちも (やってる仕事はさらに単純なハズなのに) なんだかちゃんと表示されてないしページめくりもできてない。 ナゾすぎる…。 なにが原因か分からんまま、延々とあれこれテストをしてみたが、 そもそもそんなヘンな動作になるハズがないようなところがヘンになっているんであった。 横スクロールでページめくる仕様のサイトで、次のページがある方の画面端 (のあたりの座標) をクリックすれば、 するっと次ページに表示が切り替わるはずなんだが。 そして手でクリックしてやるとちゃんと思ったとおりにページ遷移するんだが。 puppeteer で自動でやるとうまくいかない…。 つーかなぜか逆向きにスクロールしたり、行ったり来たりを繰り返したり、という…。 マウスの座標をちゃんと移動できてないっぽく見える。 よもや puppeteer のバグじゃねえだろうなあ…。 でも挙動を見る限りではそれが一番疑わしいんだわな…。 ちなみに puppeteer の当該バージョン (33.0.1) のドキュメントを見て、 マウスクリックあたりの仕様に変更がないことも確認した。 もう、どうしようもないんで、ぶっこわれた方の古い node.js のディレクトリ (消さずに残してあった) から、 それまで使っていたバージョンの puppeteer (3.3.0) と関連 (依存) モジュールを直接、 ディレクトリごと今の node.js (12.22) の方へコピーする形で移植してみたところ、 自前スクリプトは今までどおり、なんの問題もなくページをめくりつつ画面キャプチャを完了した。 …これやっぱりバグだよな… puppeteer の…仕様の変更じゃなく…。 あるいは node.js のバージョンが古い (12.22) ゆえに相性かなんかでうまく動かねえ、とかの可能性の方がでかいか…。 いわゆる「おま環」てやつだな。 でもなあ…基本的には動いてるんだし、インストールする時も拒否もされなかったし警告も出なかったのに、 でもって 3.3.0 ならなんの問題もなく動く箇所なのに、 そして仕様ドキュメントにも変更はなかったのに、 33.0.1 なんてすげえバージョンの上がり方してるのに、 page.mouse.click() の挙動だけオカシイんだもんなあ。 なんなんだろうなこれ。
という訳で node.js 周辺は仕様の後方互換性とかゼンゼン考えてなさげなパターンが多そう、というのをキモに銘じて、 今後はむやみに新しいモジュール入れたりアップデートしたりしないよう、重々気をつけながら使うことにしよう…。 なにも考えずぜんぶまとめて最新版にアップグレードすりゃオッケー、みたいなことのできる環境ではないので、余計にだな。
いやーしかし互換性が維持されていて安心して使えるという点でやっぱり Perl はピカイチだよなー。ほんとに。 その互換性維持に足引っ張られて使いづらい、みたいなこともないしなー。 ほんと、よくできた子だわ…。
購入記録
- ●雑誌「まんがライフ」2022.2 竹書房
- めんつゆひとり飯 (瀬戸口みづき)
- だもんで豊橋が好きって言っとるじゃん! (佐野妙)
- 動物のおしゃべり♥ (神仙寺瑛)
- 晴れのちシンデレラ (宮成楽)
- チート転生した猫は嫁の膝で丸くなりたい (樹るう)
- 憬れの騎士様が、じいやだなんて言えない (まどろみ太郎) (ゲスト)
- 毒を喰らわば皿までも? (松阪)
- 俺だけは八木坂さくらを好きにならない (季野このき)
- 奥さまはアイドル♥ (師走冬子)
- 恋愛感情のまるでない幼馴染漫画 (渡井亘)
- スパロウズホテル (山東ユカ)
- 有閑みわさん (たかの宗美) (最終回)
- リコーダーとランドセル (東屋めめ)
- 毒を喰らわば皿までも? (松阪)
- 高尾の天狗とミドリの平日 (氷堂リョージ)
- ぼのぼの (いがらしみきお)
- 他人には見えないお料理の先生 (榊こつぶ)
- 醍鹿館のシェアメイト (おーはしるい)
- 旅するように暮らしたい (胡桃ちの)
- 新フリテンくん (植田まさし)
蛇足的脚注
- *27-1 : 外部ツールから
- clipboardy でクリップボード読み出しをする時も、Windows ネイティブの小さい実行ファイル (たぶん) をその都度呼び出していて、 そいつ経由でやりとりしていた様子なので (process hacker で見てると呼び出すごとに出たり消えたりしてるのがわかる)、 それをただ自前でやればいいだけだった。
2021-12-28 (Tue)
…ていうかね、転居届も有効に機能しているのかよく分かんないんだよね。 秋口にその同窓会報が久しぶりに転送されてきたんだが、 通常、転送郵便物には元の宛名の部分に上から現住所のシールが貼られた形で届くんだけど、 その会報の封筒は宛名以外の箇所にも白紙のシールが貼られてなにかを覆い隠してあった。 で、光に透かして見てみたところ、「あて所に尋ねあたりません RETURN UNKNOWN {郵便局名}」という赤のゴム印が押されていたんだった。 これって間違って返送される寸前だったんじゃ…っていう。 まあ発送元へ返送される分にはまだいいんだけどさ…。
というわけで、郵便局への転居届はもうやめてもいいかな…という気になった (とりあえず全校同窓会の方は住所変更の連絡だけして…積極的に参加する気はまったくないので連絡すんのも若干悩ましいけど…)。 まあでも、旧住所に実際に住んでいたことの証明というのは、 むしろ今までずーっとやってなかった方が逆に不思議なくらい、必要な手続きだったろうとは思う。 悪用しようと思えばわりとラクにできそうだし…。 その一方で要件のうちの、郵便局から旧住所への問い合わせ必須、っていうのは、 たとえば DV などから逃げてきた人とか、そういうんではなくても旧住所の関係者と間接的にも接触を持ちたくない人とか、 人によってはいろいろと事情がありそうなモンなのに、 そのへん考慮する気がゼンゼンなさそうだなあ…とも思うのだった。 なんつーか、無神経というか、想像力足りねえなというか、悪い意味での“お役所”的なニオイというかね。 今の役所の (というか法律のか) いろんなシステムや決まり事が、片っ端から「世帯単位」で、 かつ同一世帯内ではみな人間関係良好でなんの問題もない、という前提で構築されてるのに通じるような。
2021-12-29 (Wed)
ワシが生きていごいている間はこんな形で公開を続けるつもりだが、 ワシがこの世から消えてしまうとこのサイトも早晩消失してしまうので、 コンテンツを残しておきたいと思われる人にはどんどん zip を手元に保存して、 なんならどこか別の場所で形を変えてでも公開してもらえると、 ありがてえなあとか思ったりする。 といっても、積極的な宣伝とかアピールとかなんにもしてないからな…。 まあオノレが死んだ後のことまで今からコントロールしようとしてもしょうがないかもしれんけど。
現在の日本史教科書を開くとびっくりします。知らないことがたくさん載っているのです。どこがどんなふうに変わったのか。時代順にわかりやすく記します。歴史以外でも、いろんな分野で自分が昔教わった内容は古くなってるんだろうなー。
2021-12-30 (Thu)
2021-12-31 (Fri)
追記: 簡単確実な方法。
「従業員がスタンガンを当てたのは酒の席で、社長はその場にいなかった」と反論スタンガンは使ってんのか。
「保護者からも賛同を得た」 練馬区中学校の「SNSパスワード」提出問題、教育委員会に聞く
事務局は素直に反省する一方、SNSやインターネットの利用をめぐる「いじめ・トラブル」を念頭に、場合によっては子どものパスワードを親がいつでも見られるようにする家庭内の約束も必要だとの考えを示した。
ベトナムで貯蔵されるアルミニウムは2019年にアメリカ政府主導で行われた不当廉売の調査で中国の億万長者から押収されたものです。アルミニウムは中国からベトナムのアルミ製造業者であるGlobal Vietnam Aluminium(GVA)の手に渡って貯蔵されていたとみられていますが、GVAへの初期調査は失敗しており、また調査も続行中であるため、180万トンのアルミニウムが手つかずのまま当局の監視下で保管されているわけです。
新型コロナウイルスのワクチンは打ちたくないが、接種証明書が欲しいというイタリア人の男性が、「偽物の腕」を使って医療従事者を騙そうとした。
レイシャル・プロファイリングとは、警察などの法執行機関が、人種や肌の色、民族、国籍、言語、宗教といった特定の属性であることを根拠に、個人を捜査の対象としたり、犯罪に関わったかどうかを判断したりすることを指す。あと、反抗しそうにない、アキバあたりを歩いてる奴とかも。昔狩られてたことがあったっけな。
研究チームは、今回の研究はあくまで「シルデナフィルの使用」と「アルツハイマー病の発症率低下」の間に関連性があることを示したに過ぎず、両者の間の因果関係が証明されたわけではないことを強調しています。
この調査員のデッチアゲセクハラ調査についての法的な責任はどうなんだろう…。たとえば痴漢デッチアゲみたいなのはたぶん犯罪なんじゃないかと思うが…。調査結果がデッチアゲであることが理由の解雇は不当なんだろうか? そもそもなぜこの人はセクハラをデッチアゲようとしたのか。というあたりが気になる。女性の代理人弁護士は「尋問等を踏まえ、裁判所から解雇無効を前提として、解決金の支払による和解の提案がなされ、最終的に、会社が実質的に原告の定年までの給与相当の解決金を支払う形で退職和解が成立した。原告の解雇無効の主張が認められる形になったことを弁護団としては肯定的に評価している」と話した。
龍角散は「当社としては、訴訟において、原告により被害者だとされている女性従業員が、 法廷にて宣誓をした上、証人として証言し、社長によるセクハラはなかったと明確に述べていたこと、及び、社内ヒアリングの前に原告から複数回の接触を受けセクハラだと言うよう求められたこと等を証言したこと、2018年12月には当社と利害関係を有しない大手法律事務所に依頼して調査を行い、その後セクハラの事実は認められなかったとの報告を受けていることなどから、当社の主張は従前より一貫して変わっておりませんが、諸般を考慮し今般の和解に応じました」とコメントした。
芳野氏は巨大企業出身ではなく、「ものづくり産業労働組合(JAM)」という中小の労組出身だったから、これまでの大企業労組中心の連合の改革を担う会長としておおいに期待された。
だが、その芳野会長は、実は一般労働者としての経験がほとんどなかった。ミシンメーカーJUKIに入社後、間もなく組合の専従となり、会社の仕事ではなく労組活動に専念してきたという経歴である。30年以上にも及ぶ労組活動の中で、次第に労組内の地位の階段を上り、ついには連合会長という最高位に辿り着いた。
カナダ議会では2021年12月、LGBTの人々を治療して異性愛者に矯正しようとするセラピー(転向療法)を禁止する法案が可決されました。「LGBTの治療」だけじゃなんのことか分かんないだろ > GIGAZINE
免許の更新はオンラインだけでは完結せず、免許センター等での更新手続が必要。免許センターでは、申請書等と運転免許証を提示し、職員が端末で受講を確認(顔画像による本人確認を含む)。適性検査や写真撮影の後、新運転免許証を受け取る。意味ないわ。ゴールドの講習なんてビデオ 30分見るだけだぞ。他の手続きと往復時間考えたら手間が余計にかかるだけだろ。
Double Octopusは末尾で、「この問題を解決するには、パスワードを手放すしかありません」と述べて、自社のパスワードレス認証の有効性を強調しました。けっきょく自社サービスの宣伝目的か。
ワクパスは民営のワクチン接種証明で、ワクチン接種記録と顔写真付き身分証明書(運転免許証、パスポート、マイナンバーカード、在留カードのいずれか)をアプリに登録すると、賛同企業の対象店舗などで優待を受けられる。マイナンバーカードゴリ押しでない。それが当然のはずなのにね。
来年以降、黄体ホルモンの注射は困難に。
卵胞ホルモンは継続可能。
テストステロン製剤も特に中止の動きなし。
「ヴィーガン給食」を監修したのは日本ヴィーガン協会の理事長で「ビューティーフード協会」会長
富野由悠季さんが会長を務めるアニメツーリズム協会いつの間にそんなモンが。
アニメツーリズム協会は国内外のファンに聖地巡礼を訴求することを目的にKADOKAWAや日本航空などが2016年に設立。KADOKAWAが噛んでる時点でちょっとヤな予感が… (勝手に)。
WTAや国際人権団体は、彭帥さんの状況について「検閲のない完全で透明な調査」を求めている。 WTAはこの記事について「重大な懸念の解消にはつながっていない」としている。ロイター通信が伝えた。
指の長さの比率を指す「指比」、特に人さし指(2D)と薬指(4D)の長さの比である「2D:4D比」はさまざまな特性を示すものとされそんなのがあるのか。ワシ薬指だいぶ長いんだけど。
今回のアプリは、マイナンバーカード持ってて便利だなと思える体験を提供したという意味で意義があったと思います。むしろ、マイナンバーカードをムリヤリ必須にして (ゴリ押しのため)、持ってないと使えない不便なサービスしか提供してないんでは。
メルカリは12月21日、ディーゼル車用の脱硝材に使う「AdBlue」(尿素水)について、「メルカリ」アプリ上での取引に対して注意を呼び掛けた。トラックや除雪車などのエンジンの浄化に尿素水は使われるが、市場では尿素水が不足している。そんな中、メルカリでは通常価格の倍以上の値段での取引が増えているという。シロウト (自称含む) の高額転売行為って法的に取り締まれないのかなあ…。
共産党の橋本繁樹氏はこう述べた。
「今回の武蔵野市の住民投票は諮問型で、結果に法的拘束力はない。住民投票と参政権を混同してミスリードするのはやめるべき。住民投票は意見表明であり、請願権の行使と言える。対象から外国人を排除することの方が不自然で、日本憲法にかなうものである」
コーデュラと呼ばれる特殊なナイロンの存在を知った。この糸はアウトドア用のバックパックにも使われるほど耐久性が高い。
12月5日、宮崎駅へ連なる大通りの高千穂通りにて、交通規制を伴う大規模な実証実験が行なわれた。通りの南側のみ、通常は歩道にある自転車道を車道内に移し、歩行者と自転車の通行空間を分けることで、安全性や利便性を検証する狙いだ。宮崎市内では、交通規制を伴う大規模実証実験は今回が初めてだという。
安倍政権時代に配布され、在庫の管理費が問題視されていた布マスク、いわゆる「アベノマスク」の廃棄が決まった。来春までに約8200万枚がすべて処分されるという。
納得できなければ、連絡先を明かして、「今日は帰ります」と主張して、本当に帰ってください。プチぼったくり店に限らず、不正請求に対する対処は、一つしかありません。その場では「絶対に払わない」ことです。払ってしまったものを、取り返すことは本当に大変です。
- 絶対に払わないこと
- 警察を呼んででも、なんとか払わないかたちで切り抜けようとすること
- 払ってしまったら取り返すのは大変なので、とにかく決着を後回しにもっていくこと
- 身分を明かしてでも、当日の支払いを拒否すること
- 女性が飲んだ分は、女性が払うもので、「私は関係がない」と言い張ること(どうせ女性はグル。店が女性を追い詰めることはしないし、トラブル後、女性は100%音信不通になる)
- ただし、手の込んだ事例だと、女性も誰かに助けを求めてその人間が現場に駆けつけて、一部のお金を払ってくれるようなケースもある
- もちろんその人物もグルであり、被害男性に少しでも多く払わせるための寸劇の一部なので、知っておくとよい
元厚労官僚の千正康裕さんの新刊『官邸は今日も間違える』(新潮社)は、なぜ「迷走」が生まれたのか、霞が関に身を投じ、20年過ごした経験から分析した新書だ。
代表的な論点をあげると、▼国民ウケを狙い、「やれ」と言うだけで、実務の流れやリソースに無配慮な「官邸主導」の意思決定▼国民に対する政策意図や内容の説明不足――といった課題があるという。
「野党が提案型で行くのであれば、メディアは与党と野党、どちらの提案が良いかを報じないといけなくなる。だから、メディアは政策分析に相当力を入れないとダメですよ。対立構造がないと『違いが分かりにくい』なんて言っている場合じゃない。そこを分かりやすく伝えるのがメディアの仕事だと思います」
電子帳簿保存法の改正に際しては、書類の保管方法が注目されがちであるが、全てがデジタル上でキレイに流れる業務プロセスを構築した結果としてのデータ保存でなければあまり意味がないのである。
ニュースサイトのBloombergによると、ボーナス支給対象となっているのはシリコン設計やハードウェア、一部のソフトウェアや運用グループのエンジニアで、エンジニア全体の10%から20%にあたるとのこと。
支給されるボーナス株式の額には5万ドル(約570万円)から18万ドル(約2100万円)の幅があるものの、多くの人は8万ドル(約920万円)、10万ドル(約1150万円)、12万ドル(約1380万円)のいずれかだそうです。
こうした異例のボーナス支給を行う背景とみられるのが、過去数カ月の間にAppleのエンジニアを100人単位で引き抜いているMetaの存在です。メタバースに注力し、さらなる躍進を目指すMetaは「大幅な昇給」で攻勢をかけており、Appleでは自動運転車部門などに影響が出ているとのこと。