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

> Google Hangout のログが、いつの間にか Data Export サービスの対象から外れていた。 なんでやねん。 Hangout のサービス終了の布石かなんかかね? いや、サービス終了なら逆にログのダウンロードはできるようになってないとアカンよなあ…。 一応、Gmail のラベル (カテゴリ?) の「チャット」だけ選択してメールログをダウンロードすればテキストデータに関してだけは拾えるが、 なぜか時系列に沿ってなくて順番がめちゃくちゃになってるし、 おまけに複数のチャット相手とのやりとり (チャンネル) がぜんぶ一緒くたにひとつの mbox に入っちゃってるし、 なんだこれっていう。
以前は Hangout のログもサービス対象に入っていて、チャンネル毎に JSON 形式でダウンロードできたんだが。 いつの間に劣化したんだろう。 Gmail の UI から見られることは見られるんだが、元々あまり見やすくなかったのが、 少し前の Gmail UI 改変以降もンのすごく使いづらく見づらくなっちってほぼ役に立たない状態なんだよな。 以前、仕事手伝い先の某氏と Hangout でやりとりしていて、 過去ログの検索とかが不自由なんで slack に移ったものの、 slack の iOS 用アプリが電池食いで電池がもたないからヤダ、と言うので 1ヶ月もたたずに Hangout に戻ったりしたんだが。 最近また slack に変えたりしている。 電池の持ちはどうなったのかは聞いてないが改善されたんだべか。
とりあえず古いログを浚渫してきてデータを整えて SQLite の DB に突っ込んで、 閲覧と検索だけ軽い UI からできるようにと表示用の CGI 書いた。 毎度お馴染みの泥臭い作業で工夫もアタマのよさもなんもないけどな。 でもこんな程度の規模のコードを書いてるのが一番シアワセだなー。 あれ、Google の仕様改悪から恩恵受けてんのかこれ…? いやさすがにこれは恩恵とは言わんよな…。

> 仕様変更後の Twitter の個別ツイートページ (の URL) から画像を引っこ抜くスクリプトは、 とりあえず問題なく動いているので、 次は Twitter の moment ページの更新を検知するスクリプト。
node.js + puppeteer で html を手元にダウンロードしてエディタでバラしたりしていろいろ調べてみたところ、 Twitter の個別ツイートページ (の上の方) から拾うのと違い、 moment のような縦にずる長いページは、スクロールさせないとページの下の方の構造がちゃんと DOM に構成されない (つまりそこからのリンクなども拾えない) らしいことが分かった。 さらに、ページをスクロールさせただけではダメで、 いったん全ページの画面キャプチャを撮ってやらないと、なぜか DOM がちゃんと構成されないことも分かった。 ようわからんが、なんともメンドクサイことだけは確かだ…。遅延表示とか誰が考えたんだか知らんけどほんと面倒。 まあ自動的にやるんだから少々メンドくさくても大丈夫だけど。
手順としては、チェック対象の moments ページの URL (と見出し) をファイルに用意しておき、 それを元に順ぐりにページを読み込んで、 個別ページの URL と生成日時と本文 (あれば) を拾って、 ぜんぶまとめてひとつの feed (RSS 2.0) に吐き出す。 それを別途ローカルのフィードリーダで拾って読む。 新着があればフィードリーダが拾うのですぐ分かる。 なお node.js が Windows 版だが、Windows のタスクスケジューラではなく cygwin の cron で走らせてる (1日 1回)。 とりあえず cygwin cron でキックしてる他のやつらの分とログをまとめたかったので…。
これも記念にコード置いとこう。 たぶんまだバグ残ってると思うが…エラー処理周りとか。 あと Twitter の仕様が次に変わるまでの寿命だな。それは仕方ないけど。 なおページスクロールする部分なんかはほぼ お手本 のまるうつし (ただ個人的にキャメルケースは見慣れてなくて見づらいので可能な限りスネークケースにムダに書き直している)。 console.log() のかわりに console.error() を使っているのはなんとなく。

'use strict';

// momentsから個別ページのURLをピックアップし、フィード生成する
// 使用する node.js はwindows版なので、ファイルのパスは例えば c:/～ などドライブレターから始まる
// なんとpage scrollしてもscreenshotを撮らないとhtmlも完全なのが得られない…
// そして長すぎるページはscroll後に上の方の画像表示が消えちゃって全体screenshotがうまく撮れないという罠 (今回の処理には関係ない)

const puppeteer = require('puppeteer');
const fs = require('fs');
const rss = require('rss');
require('date-utils');

const load_wait = 5000;
const conf_file = 'c:/moments_url.lst';
const feed_file = 'c:/www/feed/moments_local.rss';

const now = () => {
    return new Date().toFormat('YYYY-MM-DD HH24:MI:SS');
};

// 主処理
(async () => {
    console.error(`check moments: ${now()} start`);
    const browser = await puppeteer.launch({headless: true});
    //   targets[n].url   … moment page url
    //   targets[n].title … moment page title (自前でつけたやつ)
    const targets = load_conf(conf_file);
    const vp_width = 1600;  // このへんはてきとう
    const vp_height = 1200; // 同上
    const feed_entries = [];
    for (const target of targets) {
        console.error(`check moments: ${now()} target: ${target.title}`);
        const page = await browser.newPage();
        page.setViewport({width: vp_width, height: vp_height});
        await page.goto(target.url);
        // ↓ここともう1箇所の page.waitForNavigation() は毎回必ず timeout になるが、
        //   timeout になってもただ処理を継続するのみなので、対処は特になにもしない
        await page.waitForNavigation({waitUntil: 'networkidle2', timeout: load_wait})
            .catch((e) => {});
        await scroll_to_bottom(page, vp_height);
        await page.screenshot({fullPage: true});    // 保存しないダミーscreenshot
        const entries = await pickup_entries(target, page);
        feed_entries.push(entries);
        await page.close();
    }
    // あまり意味のないsortかも
    feed_entries.sort((a, b) => {return a.moment_title < b.moment_title ? -1 : a.moment_title > b.moment_title ? 1 : a.datetime < b.datetime ? -1 : a.datetime > b.datetime ? 1 : 0});
    const feed = make_feed(feed_entries);
    fs.writeFileSync(feed_file, feed.xml({indent: true}));
    await browser.close();
    console.error(`check moments: ${now()} end`);
})();


// 対象url(と自前title)が書かれたconfigファイルを読み込む
// (あらかじめ別途作成済のこと)
const load_conf = (file) => {
    const buf = fs.readFileSync(file, 'utf8');
    const result = [];
    for (const line of buf.split(/\n/)) {
        if (line.match(/^\s*(?:#.*)?$/)) {
            continue;
        }
        const dt = line.split(/\t/);
        result.push({url: dt[0], title: dt[1]});
    }
    return result;
};

// ページ最下までスクロールする
const scroll_to_bottom = async (page, vp_height) => {
    const get_scroll_height = () => {
        return Promise.resolve(document.documentElement.scrollHeight);
    };

    let scroll_height = await page.evaluate(get_scroll_height);
    let position = 0;

    while (position < scroll_height) {
        position += vp_height;
        await page.evaluate((scroll_to) => {
            return Promise.resolve(window.scrollTo(0, scroll_to))
        }, position);
        await page.waitForNavigation({waitUntil: 'networkidle2', timeout: load_wait})
            .catch((e) => {});

        scroll_height = await page.evaluate(get_scroll_height);
    }
};


// moment の page から個別ページの情報を拾って返す
// 基本構造(例):
// <body …>
//  :
//   <article …> /* 個別ページ (個別ページ以外のarticleの場合あり) */
//     :
//      <a href="/{user-account}/status/\d+" … title="午後12:34 ・ 7月10日" …>
//        <time datetime="2020-07-10T12:34:56.000Z">7月10日</time>
//      </a>
//     :
//      <div lang="ja" …> /* 本文テキストが空の場合はこのブロックはない */
//        <span …>{各ページ本文テキスト}</span>
//      </div>
//     :
//   </article>
//  :
// </body>
const pickup_entries = async (target, page) => {
    const articles = await page.$$('article');
    let counter = 1;
    const result = [];
    for (const article of articles) {
        if (! await article.$('a[href*="/status/"][title]')) {
            console.error('a element not found');
            continue;
        }
        const href = await article.$eval('a[href*="/status/"][title]', (el) => {return el.href});
        const datetime = (await article.$eval('time[datetime]', (el) => {return el.getAttribute('datetime')})).replace(/\.000/, '');
        let desc = '';
        if (await article.$('div[lang="ja"]')) {
            desc = (await article.$eval('div[lang="ja"] span', (el) => {return el.innerText})).replace(/\n/g, '<br />');
        }
        console.error(`${counter} - href: ${href} / datetime: ${datetime} / desc: ${desc}`);
        counter++;
        result.push({
            moment_title: target.title,
            moment_url: target.url,
            page_url: href,
            datetime: datetime,
            desc: desc,
        });
    }
    return result;
};


// feedを生成する titleとかいろいろ決め打ちでentryをくっつけるだけの単なるサブルーチン
const make_feed = (feed_entries) => {
    const feed = new rss({
        title: 'moment local check',
        feed_url: "http://localhost/feed/moment_local.rss",
        site_url: "https://twitter.com/",
    });
    for (const entries of feed_entries) {
        for (const entry of entries) {
            try {
                const dt = (entry.datetime).split(/\D+/);
                feed.item({
                    title: `${entry.moment_title} - ${dt[0]}.${dt[1]}.${dt[2]}`,
                    guid: entry.page_url,
                    url: entry.moment_url,
                    description: entry.desc,
                    date: new Date(entry.datetime),
                });
            }
            catch (e) {
                console.error(e);
                console.error(`entry: ${JSON.stringify(entry)}`);
            }
        }
    }
    return feed;
};

↑ついでにここの拡がったり縮まったりする仕掛けのコードもちょいと書き直した…いや jQuery でだけど。 話は逸れるけど、最近、妙に「脱jQuery」みたいなのに躍起になってる勢力を見かけるが、なんだろうねえ。 流行なのか宗教なのか。 ナマ JavaScript コード、昔に比べりゃ確かにマシになってると思うが、 jQuery を急いで廃するに足りるほど良くなってもいない気がするんだがなあ。 まあ好きずきだけどさあ。 こちとらやっと jQuery の便利さの端っこを堪能できるようになり始めたくらいなんでヘンに水差されてるみたいでちっとヤな感じだよ。

> 4年半ほどほぼ休みなく体重をかけっぱなしだった座布団 (銘仙判 (55×59cm) 木綿綿 100%) がぼちぼちダメになったので新調した。 カバーは擦り切れの穴あきで 2回ほど交換したが…中身の状態までちゃんとチェックしてなかった。 干しも洗いもしないで酷使したのによくもってくれたよ。 ありがとう楽天経由の通販で送料込 1800円だった座布団。 実はダメ元のつもりで近所のクリーニング屋に持って行ってみたんだが、 クリーニングではほぼ間違いなく綿が寄ってでこぼこになるのでやめといた方がいい、 専門の業者に打ち直ししてもらえば別だが料金を考えると買い換えた方が安いし早い、 とすンげえ渋い顔 & なるべく引き受けたくない声色でプレゼンされてしまったので諦めた。 まあ、綿の打ち直しが必要というのはなんとなく分からんでもないけど。 そして手間と料金を考えたら買った方が早いし安いだろ、というのも…。 同じくダメ元で、自分で洗ってみるのもどうかな…とも思ったんだが…。 ウチ、洗う場所がないんだよなー。 風呂桶は栓がバカになっていて水が抜けるし… (風呂桶自体もう使ってないんで栓もそのまんま)。 あと洗う場所だけでなくて干す場所もないんだよな…。
そしてうちの区では廃棄座布団は粗大ゴミ扱いなのだった。 まあ他の自治体でも大体粗大ゴミ扱いらしいが、 細かく切ったら可燃ゴミで OK、な自治体も見かける中、 わざわざ「分解しても粗大ゴミです」などとドヤ顔で (←想像) 付記してある。 理由はわからない。なんも書いてないから。 資源ゴミの分別にしてもゴミ関連の行政は昔からこんな感じだな…ここは。 炭酸カルシウム含有の袋を指定したり、それがいつの間にか無しになってたりとか。 それは東京都全体だったか。 そういや今月入って以降のレジ袋有料化とやらもロクに事態の想定も現状の分析もしてねえ感というか気まぐれ臭がプンプンしてるしな関係ないけど。 ペットボトルの回収も、フタは分けるよう指定してる自治体もあれば、 フタも本体と一緒に捨てるよう指定してる自治体もあるし (うちの区は後者)。 フタは PET 製じゃないと思うんだが。 なにしろ指示だけは細かくあるが、その目的や理由はことごとく書いてない。 書いてないからどういう理由なのか、そもそもマトモな理由があるのかどうかすら分からんという。
というわけで細かく切り分けて少しずつ燃やすゴミに混ぜて廃棄する方針。 “古座布団を材料にして作成した小さい手芸品を捨てる”のと結果的にまったく変わらんしな (“(粗大ゴミの規定サイズ以下の) クッションやぬいぐるみ”は燃やすゴミ指定)。 なんなら実際になんか作ってから捨ててもいいな。だいぶ汚れて異臭もしてるけど…。

> Twitter の個別ページに貼られた画像の取得と、 moments ページの更新チェックに続いて、 コミックウォーカーの作品の画面キャプチャ保存も node.js + puppeteer で半自動化した。 好きな作品はあとから読み返せるように、ブラウザ表示画面のキャプチャ (スクリーンショット) をとってちまちま保存してきていたんだが、 毎回、マウスクリックでページをめくりつつ画面キャプチャ用のアドオンのショートカットキーでキャプチャしつつ… という作業が、まあそれなりにメンドくさかったのだった。 しかしコミックウォーカーは Twitter の仕様変更後画面と同じく JavaScript で動的に画像表示や遷移を行なう仕様で、 画像の情報もスタティックには埋め込まれていなくて perl + Web::Scraper で半自動的には拾い出せなかったので、 仕方なくちまちま手作業で保存していたのだった (キャプチャ後の画像の余分な部分の crop とかファイルのリネームとかは別途スクリプトで半自動化済)。 まあ、やってることは単純で、読み込みやページめくりにたまに遅延がマバラに生じるのでたっぷりと待ち時間を挟みつつ、 page.mouse.click() でページめくりをしながら画面キャプチャを取っていきつつ、 DOM 内の特定の要素を見張って最終ページまで行き着いたら終了する、というだけのお仕事。 ページめくり時の画面遷移完了のタイミングを puppeteer から取得しづらく、 仕方なく状態遷移待ちのインターバルをたっっっぷり取ったので全行程手作業の時よりも時間はかなりかかるようになってしまったが、 ページ URL のコピー以外に人力作業 (単純作業) がなくてあとは放っとけば終わるのでぜんぜん問題なし。 これも記念にコードを貼り付けておこうかな…と一瞬思ったんだけど、あんまし芸もないしやめとくか…。 やってることは以前貼ったコードと大体一緒だし。
puppeteer でのキャプチャのいいところは、 ViewPort のサイズを (実モニタの表示サイズに制約を受けず) 自由に設定できるので、 好きな画像サイズで保存が可能なところかねー。 あんまし欲張って拡大してもボケちゃうしファイルサイズもかさばるんで、 まあほどほどのところに留めておくのが吉だけど。

> 例によって益体もないボヤキだが。
腕時計を 2年ほど前からなんとなく時々物色している…。 買える範囲の価格で、 防水 + 電波時計 + ソーラーバッテリ + 針式 (秒針有り) で、 できれば耐衝撃で、あまりごつくなくて、 ぱっと見で時間の確認がしやすいやつ…。 条件の前半から、どうしても CASIO の BABY-G (G-SHOCK 系の女性向けブランド) あたりが主な物色先になってしまうんだが。 古い製品 (中古で入手可能なくらいまでの) から最近の製品まで、 上記の条件にあてはまる範囲でわりとまんべんなくチェックしていて思ったんだが、 BABY-G のデザインって針の視認性がおしなべてイマイチなんだな。 特に色味…。 白っぽい地に白っぽい針とかがやたら多い。 ただでさえサイズがちっちゃい分見やすさが犠牲になってんだからコントラストとかもっと気を配ればいいのに…。 たまに黒っぽい地に白っぽい針の (視認性がそこそこよい) デザインもあるんだが、中古品ではほとんど見かけない。 女性向けのラインアップだからその手の色味の製品は数を出してないんだろうな…たぶん。 わりと最近、真っ黒な地に白い針の新製品 (MSG-W300CB-1AJF) が出ていたのに気づいて、 これは時間も見易そうだしデザインもシンプルだしちょっとよいかも…と思ったんだが。 拡大写真をよく見ると、長針の尻尾側がムダに長くて、 位置によっては短針の白い部分を半分近く隠してしまう (ことがある) ことが分かった。 なんでじゃー。肝腎の時計のキモである時間の確認機能をデザインで阻害してどうすんだ。 BABY-G のデザイナーってなに考えてんだろうなあ… (デザイン考えた奴だけじゃなくて指示出してる奴や許可出してる奴も含めて)。 “女性向けデザイン”はこんな感じでいい (こんな感じがいい) っていう掟でもあるんかしら…。 まあ“アノブドウハスッパイ”式に購入の検討を回避できているので個人的には助かってたりするんだが。 それ以前に懐具合の都合で手が出ないから、余計な御利益だな…。 そして近所への買い物以外ほぼ外出する機会のない奴がなに腕時計なんぞ物色してんだ、という根本的なところへのツッコミ (自分で)。

> 4年ほど前に中古で買った日商簿記 3級の本 (2012年改訂) がぽろっと出てきたのでぱらぱらめくってみたが、 やはりほぼ頭に入ってこない。 なんで買ったんだったかなこれ…。 以前仕事手伝いに行った先で誰かが簿記受けるみたいな話をしてたのの影響だったかな…? で、そういえば簿記の試験ていつやってるんだろ、と Web で検索してみたら、 2019年度から 3級の試験範囲が変更されました、とかいう情報が出てきた。 変更範囲を見てみるとちまちまとありそう…。追加される項目もけっこうあるっぽい。 なんだよ中古とはいえせっかく買った本がムダになっちまったじゃねーか、 と自分でムダにしたくせにちょっと憤る。 まあ中古で 500円も出してないんだけど…。
簿記ってなんか独自の用語と概念と設定をアタマに叩き込まないと使えるようにならない感じがするんだな。 体系に、リクツの部分とリクツじゃない (っぽい) 部分があるみたいな。 まず専門用語を目にした時に違和感が取れて、次に各用語に個別のイメージ (scheme?) が紐付けされるまで、 繰り返し読んでみるのがよさそうかなーと思ったところで止まってる。

> 自営業の知人が仕事の取引用に作っていた楽天銀行の口座が、 ある日突然凍結されて使えなくなったらしい。理由は不明。 そして「楽天銀行 凍結」で検索するとけっこうな数ヒットするが、 窓口の対応 (態度) が非常に悪く、いつまでたっても凍結解除されず、 という、たくさんある事例とほぼそっくりそのままの状況に陥ったらしい。 例えば取り引き先の口座のひとつが犯罪や事件などにからんでいた (巻き込まれた) などの理由で (捜査などの目的で?) 口座が凍結されるようなことは、 楽天銀行に限らずあるらしいが、 しかし楽天銀行の場合はヒットする記事のほとんどが、 凍結後の顧客への対応の悪さ、なのが特徴的な感じ。 その知人の場合も、なにしろ担当者の態度がよくない (しゃべり方が軽薄かつ妙に見下した口調な) 上に 折り返し連絡すると言いつつ連絡してこなかったり (再三)、 連絡してきてもその時間帯がでたらめ (夜中近くとか) だったり、とのことで、 しかし粘って交渉した結果、開業届の写しを送れというので (時間を作って税務署まで行って取得して) 送ったら態度がコロッと変わって腰が低くなったらしい。 なぜだ。 そして口座の金もそれから割とすぐに返ってきたらしい。 しかしなぜか口座は楽天銀行側から解約されたらしい。 しかし解約した理由は聞いても言わなかったらしい。 元々対応の悪さに憤っていたくらいなので、金を引き出したら速攻で解約するつもりでいたから、 手間が省けてよかった、とは言っていたが。 結果的になんの落ち度もなかった顧客の口座 (預金全額返金してきたんだからなにも問題なかったのだろう) を、 凍結…は仕方なかったとしても不自由を強いたあげくに銀行側から理由も告げず解約するのってどうなんかね…? 知人は半分は楽天ポイント目当てに作った口座だったらしいけど、ポイントにつられるんじゃなかった、失敗した…とだいぶこぼしていた。 まあね。コンプライアンスとかあんまし (ぜんぜん) 考えてなさそうだしなああの系列は…。 楽天モバイルも最近端末の認証がらみでやらかした上にまったく反省してる様子も見えないし (楽天モバイルのサイトを探したが件のやらかしに関する顧客向けのコメントも記事もなにもなかった。 「なかったこと」もしくは「ささいなこと」扱いらしい)。 会議中に上司に暴行されて頚椎損傷して訴えた元社員の裁判でも、 楽天は終始「社員同士のケンカ」なのでウチには関係ない、という態度を変えずじまいらしいしなあ。 どんなヤクザ事務所だよ。

> デスク用の照明スタンドを買った。 山田照明の Z-80PRO II というやつ。 けっこういい値段するんだが (ワシの懐具合的に)、ちょっと思い切ってしまった。
机上での作業時用に、これまでは Amazon で買った安い可搬型の LED ライトを使っていたんだが、 これだとちょっと手元が暗いな…と思うことがたまにあった。 まあ可搬型の小振りな LED ライトだから、どうしても低い位置から (つまり比較的横から) 照らす形になるので、 手元に影なんかができやすかったのもあるんだな。 それより以前に、背の高い LED スタンドも (やはり格安で) 買って使ってはいたんだけど、 タッチセンサー式の電源スイッチがだんだん調子悪くなってきて、何度触っても電源が入らなくなったり、 やっと点灯してもしばらくしたら触ってもいないのに勝手に消えたりと、使い物にならなくなってしまったので強制引退。 一応国産メーカー品らしいんだけどね…まあヤマダ電機のワゴンセール品だったやつだしね… (それでも 2K くらいしたんだっけ)。 AC アダプタを引っこ抜いて数日ほど放置すると直ったりもしたんで、 どっかに電荷がたまって静電スイッチが誤作動する、みたいな感じの原因だったのかな…と想像したが、確かなところは不明。 スイッチ周りの不具合か回路の設計ミスとかだったのかも。 まあそれは置いといて。
そんな感じで、横からでなく上方から (できれば照射元の位置をある程度の範囲で調整しつつ) 照らせるデスクライトがやはり欲しいなあ…と以前からぼちぼち物色していたんだった。 つっても明かりが必要な実作業をする機会なんか現状ではほとんどないっちゃないんで、 それほどせっぱ詰まった問題でもなく、ずっと半保留状態だった。
で、なんで今、買う気が閾値を超えたのかというと。 ここ数年来ほぼ家に居っぱなしなので、ずっと毎食のご飯の写真を撮ってるんだけど (あくまで定点観測的に)。 以前中古で買った IXY410F をご飯記録専任カメラとして使っておるので、 こいつだけ撮影枚数がダントツに多くなってしまった (実は購入物記録専任にしている XZ-10 の撮影枚数がぼちぼちそれに追い付きそうな勢いではあるが)。 で、買うだけ買っておきながら (誰かと会う機会もどこかに行く機会もなくなり) 使う機会がないままに死蔵している中古カメラの面々を、 ご飯撮影に便乗して順ぐりに少し使ってみようかな、使い方がある意味もったいない気もするが、ただ死蔵させとくよりはマシだろうし、と思いつき、 今年の頭あたりから、1～2ヶ月交替で IXY410F の他に 1～2台、 ご飯撮影に参加させるようにしてみはじめた。 そしたら…複数機種による同じご飯の写真を見比べてみると、 機種によっては、部屋の LED 照明の強い青成分の影響を受けてホワイトバランスが青みがかって写るものもけっこうあることが分かってきた。 実は IXY410F も (部屋の LED 照明下では) 青みがかって撮れる傾向があるのは以前判明していたんだが。 世の中どんどん LED 光源に乗っ取られていってる昨今、LED 光の青みの影響を受けちゃうカメラはちょっと悲しいな… とかなんとか思いつつ、 とりあえず自分のご飯撮りに関しては、作業卓 (食卓兼用) を照らす用の、もっと太陽光に近い色味の照明がひとつあれば、 青みご飯写真は解決するんじゃね? と気づいたのだった。
…もうひとつ、最近 DP2 Merrill もご飯写真に参加させてみたんだが、 こいつはちょっとでも増感すると途端にノイズがダダ乗りに乗る上に手ぶれ補正なんぞ積んでなくて、 しかもある程度絞って撮る必要があるので (被写界深度的に)、 絞り優先 + ISO 100 固定で三脚とタイマーを頼りに撮ってみていたんだけど、 それにしたってもうちょっとシャッター速度を稼ぎたいよな… もうちっと明るくして撮らないとやっぱアカンよなあ…と思った、というのもある…相変わらず説明がへったくそだな…。
という訳で色味 (光の色成分) が太陽光に近い LED 照明の物色をし始めて、 「平均演色評価数 (Ra)」というあたりの用語や、Ra じゃ指標としては不十分、とかの蘊蓄などを拾いつつ、 ふと、そういや昔ゼットライトってのがあったなあ…と何気なく検索してみたら、メーカーもブランドもばりばりの現役だった。 山田照明のゼットライト、って、使ったことはないんだけど… (十代の頃使ってたのはナショナルの白熱電球の電気スタンドだった。夏は白熱球の熱で暑くてしょうがないやつ。 成人後は一時蛍光管の電気スタンドを使っていたが、引っ越す時に人にあげてしまったな…)。 使ったことない割には、このブランドにはちょっと郷愁込みの思い入れ的なモノもあり、 アームのバネ式の位置制御機構もちょっとよさげであり、 このクラスの電子機器は安物買いの銭失いになりやすいことが過去の実績からもなんとなく分かっており、 LED 照明は (故障さえしなきゃ) それなりに長持ちする (ことが期待できる) 代物なので、 多少の一時的な出費も将来的に十分償却できる見込みもあり、 値段も調べてみたらまあ払えないこともないくらいの範囲でもあり、 演色性も (カタログスペックでは) 他の選択肢と比べても十分上位に位置する製品と言えそうでもあり、 と自分の中で口実バッファが満杯になったので、ちょっと思い切ってみたのだった。
なお電球型 LED 照明では goodgoods の製品が割とあちこちで高評価な上に価格もけっこう安い方なようなので、 部屋の照明器具用にちょっと買って試してみようかな…と思っているところ。 つーか、goodgoods の LED 照明と、電球型 LED を使える安いデスクスタンド (用アーム) の組み合わせなら、 Z-80PRO II の半分以下 (1/4 以下?) の値段で入手できてたっぽいんだよな。 今回は、価格よりもブランドに対する郷愁的思い入れの分の差で決めたと言えるかもしれん…。 あ、あとあれだ、型番の「Z-80」にちょっとつられた面もわずかにあるな。 なんでやねん、と自分でも思わなくもないが。 合理性は二の次な判断でこれまで生きてきて、この先も生きていく予定の生物なので、 このへんはまああんまし理屈関係ないんだよな…。
これでご飯写真の色味 (のデジカメ機種によるバラつき) 問題もひとまずは解決し、 あとこれまで使っていた可搬型 LED 照明より光量もあるので、まあいろいろと見やすくもなった。 光量不足は老眼の大敵だね! ちなみにこれまで買った LED 照明 (すべて一応昼白色なので色温度 5000K 近辺なはず) と比べて、 光がわずかに赤みがかっている感じがする。 あと、ある程度光量調整ができるんだが、 光量を落とすとデジカメによってはモニタに縞模様が出る。 これは LED が PWM (Pulse Width Modulation) という形式で、 点灯と消灯を高周期で繰り返すその点灯時間・消灯時間の比率を変化させることで明るさを変えているので (LED での調光では一般的な方法らしい)、 その変化をデジカメのモニタでとらえちゃうんだな。 モニタには出るが撮影には影響ないので無問題。

> そして、Z-80PRO II をポチった後で知ったのだが、 世の中には LED ではなく、有機EL を使った照明器具なるものも存在するらしい…。 演色性では、高演色タイプの LED 照明の性能をしのぎ、 寿命の面も最近では LED に匹敵するくらい改良されているとか。 しかし唯一の欠点は、値段が高い…。 あと一般家庭向けの製品がほとんどない。 デスクスタンドなどはほとんど見つからない (探した範囲では、色温度低めの 4000K くらいの製品しか見つからなかった)。 そしてプロ用となれば元々値段が高いめのものがさらに高いめになるという。 現状では手を出せそうにない。 まー、プロのカメラマンやデザイナーでもないし…。 将来はもっと安くなるかもしれないので、そのへんに期待しつつ。

> 先月作った、 Twitter の個別ページ (の URL) を元にページ内の画像を適宜ローカルへ保存するスクリプトだが、 ついさっき、このスクリプトでは保存できない画像に出くわした。 また Twitter のヤロウがフォーマットいじったんか!! と一瞬血相を変えそうになったが (いちいち血相変えんな)、 Twitter にログインしてない状態のブラウザから見てみたら原因が判明。 「センシティブな内容が含まれている可能性のあるメディアです。」などという警告付で、 画像表示が隠された状態だったため、 DOM をさらっても画像へのリンクを取得できなかったのであった。 なるほどこういうパターンもあったか。 早速スクリプトに改造を追加…。 ついでにあちこちの小バグも直し。 今後もおそらくこんな感じでちまちま改変を続けていくであろう。 でもってその都度いちいち載せてんなよっていうね。

'use strict';

// クリップボードを見張り、twitterのアドレスだったら個別ページとして開いて、そのページの画像を自動保存する
// node.js 版
// 使用する node.js はwindows版なので、ファイルのパスは例えば c:/～ などドライブレターから始まる

// cygwin のコンソールから起動して走らせておき、
// ブラウザ側などからTwitterの個別ページのURLをクリップボードにコピーしてやる形で渡す

// 2020.7.26  … 「センシティブな…」云々で画像が表示されてないケースに対応
// 2020.8.5   … タイトルからユーザ名取得失敗したら成功するまでpage.reload()してからやり直す

const puppeteer = require('puppeteer');
const clipboardy = require('clipboardy');
const fs = require('fs');
const https = require('https');
const chalk = require('chalk');
const ctx = new chalk.Instance({level: 2});
require('date-utils');

const save_dir = 'c:/tw_imgs';

const url_queue = [];
const pic_queue = [];

const sleep = async msec => new Promise(resolve => setTimeout(resolve, msec));


// 0.5秒ごとにクリップボードを見張って変化していたら拾って対象となるurlだったらqueueに入れる
// clipboardy.read() ごとに外部プログラム(プロセス)が起動されるのでせわしない
// clipboardの内容(量とか?読み出すタイミングとか??)によっては clipboardy.read() がエラーになる
// clipboardの内容の変化により clipboardy.read() のエラーは解消されるので、
// clipboardy.read() がエラーの間はひたすらスルーする
(async () => {
    let old = '';
    let errstat = false;

    const cread = async () => {
        const buf = await clipboardy.read()
        .then((r) => {
            if (errstat) {
                errstat = false;
                process.stdout.write('\x1b[G\x1b[K');  // 行頭へ移動→カーソル位置から行末までを消去
            }
            return r;
        })
        .catch((e) => {
            if (! errstat) {
                errstat = true;
                process.stdout.write(ctx.red('cread err'));  // clipboard読み出しエラー中の表示
            }
            return '';
        });
        if (! errstat && old != buf) {
            old = buf;
            if (buf.startsWith('https://twitter.com/')) {
                url_queue.push(buf);
            }
        }
        setTimeout(cread, 500);
    };

    cread();
})();


// 0.5秒ごとにqueueのurlを見張って、拾ってscrapeして画像のlinkを抽出して整えて画像用queueに突っ込む
// (twitterの個別ページ以外のurlのパターンだったらスキップ)
(async () => {
    const browser = await puppeteer.launch();

    const checkurl = async () => {
        if (url_queue.length) {
            const url = url_queue.shift();
            do {
                if (! url.match(RegExp('^https://twitter\\.com/[^/]+/status/\\d+'))) {
                    break;
                }
                const page = await browser.newPage();
                await page.goto(url, {waitUntil: 'networkidle2'}).catch((e) => {
                    console.error(`checkurl():page.goto error. url=${url}`);
                    process.exit(1);
                });
                let user = '';
                // タイトルからユーザ名取得成功するまでリロードを試みる
                while (user == '') {
                    const title = await page.$eval('title', (el) => {return el.textContent});
                    user = (() => {
                        let u = title.match(/(.+)さんはTwitterを使っています/);
                        if (! u) {
                            console.error(`identifying user failed: title: ${title}`);
                            return '';
                        }
                        return u[1];
                    })();
                    if (user == '') {
                        await page.reload({waitUntil: 'networkidle2'}).catch((e) => {
                            console.error(`checkurl():page.reload error. url=${url}`);
                            process.exit(1);
                        });
                    }
                }
                // 「センシティブな内容が…」云々のページだった場合、画像表示を開く前処理 (ちょっと適当)
                {
                    const articles = await page.$$('article');
                    for (const atcl of articles) {
                        const t = await atcl.evaluate((el) => {return el.textContent});
                        if (t.match(/^センシティブな内容が含まれている可能性のあるメディアです。/)) {
                            console.log('warn: sensitive contents included.');
                            const btn = await atcl.$(':scope div[role="button"]');
                            await btn.click({button: 'left', delay: 100});
                            await sleep(1000);
                            break;
                        }
                    }
                }
                const alinks = await page.$$('a[data-focusable="true"][role="link"]');
                const piclinks = [];
                for (const aa of alinks) {
                    const href = await (await aa.getProperty('href')).jsonValue();
                    if (href.endsWith('/likes')) {
                        break;
                    }
                    let no = [];
                    if (no = href.match(RegExp(`${url}/photo/(\\d)$`))) {
                        const img = await aa.$(':scope img');
                        let src = await (await img.getProperty('src')).jsonValue();
                        src = src.replace(/name=[-a-z_\d]+/, 'name=large');
                        piclinks.push({no: no[1], url: src, user: user});
                    }
                }
                if (piclinks.length) {
                    piclinks.sort((a, b) => a.no - b.no);
                    for (const pl of piclinks) {
                        pic_queue.push(pl);
                    }
                    console.log(ctx.red(piclinks.length) + ` url added -> ${new Date().toFormat('MM-DD HH24:MI:SS')}`);
                }
                await page.close();
            } while (0);
        }
        setTimeout(checkurl, 500);
    };

    checkurl();
})();


// 2秒ごとに pic_queue からurlを拾って画像として保存する
// (タイムスタンプが画像の順番になるよう、前のダウンロードが終わるまで次を開始しない)
(async () => {
    const dlpic = async () => {
        if (pic_queue.length) {
            const picdata = pic_queue.shift();
            const user = picdata.user
                .replace(/:/g, '：')
                .replace(/\?/g, '？')
                .replace(/\//g, '／')
                .replace(/\\/g, '＼')
                .replace(/</g, '＜')
                .replace(/>/g, '＞')
                .replace(/\*/g, '＊')
                .replace(/\|/g, '｜');
            const url = picdata.url;
            let fnm = url.match(/([^/]+)\?.*format=(.+?)\&/);
            const fname_body = `${fnm[1]} (${user})`;
            const fname_ext = fnm[2];
            let fname = `${fname_body}.${fname_ext}`;
            {
                let bnum = 1;
                while (fs.existsSync(`${save_dir}/${fname}`)) {
                    fname = `${fname_body}-${bnum}.${fname_ext}`;
                    bnum++;
                }
            }
            const req = await https.get(url, (res) => {
                const sfile = fs.createWriteStream(`${save_dir}/${fname}`);
                res.pipe(sfile);
                res.on('end', () => {
                    sfile.close();
                });
            });
            console.log(ctx.blue(pic_queue.length) + `: saved ${save_dir}/${fname}`);
            req.on('error', (e) => {
                console.log(`err: ${e.message}`);
            });
        }
        setTimeout(dlpic, 2000);
    };

    dlpic();
})();

> 「嗚呼!! 花の応援団」は、むかーしラジオで一部流してたのを (録音して) 聞いて覚えていたんだが。 メインボーカルの人、こんなうまかったんだなあ…。 今はどちらでなにをやってらっさるんだろうな。 ちなみに映画は 3作あるらしいがまったく見たことない。 なぎら健壱氏が薬痴寺役で出てるらしい…ハマリ役らしい…。 一度見てみたいけどレンタル落ちの中古 DVD でも“見てみたい度”の割にちょっと値段が張るのでまだ手が出てない (レンタルやネット配信で探す、という発想はない)。 古い B級映画って、今見たら懐かし面白い作品てけっこういろいろありそうな気がするんだよな。 でもまあたぶんほとんど見られないだろうなあ…腰の重さと余命の兼ね合い的に考えて。
「おやじ太鼓」は放映が 1968年。「ウルトラセブン」の翌年か。 全 39話、TBS で毎週火曜 21:00～21:30 の放映だったらしい。 あおい輝彦氏が歌う主題歌をうろ覚え (多少の記憶違いあり) ながらも覚えていたので、 たぶん親が熱心に視聴していてそれを脇で見ていたんだろうと思う。 実際、内容の方は実はほとんど覚えていない。 まあ、アニメや特撮番組などと違って、後年の再放送などで記憶強化する機会がなかったせいもあるだろうけど。 そして Wikipedia などによると、この翌年 (1969年) に「おやじ太鼓2」という続編が全 26話で放送されたらしい。 そうなのか…。 なお続編の方は DVD 化などはされていない模様。そのうち出たりするのかな?

> この数年、自前のスクリプトで定期的にヤフオクの出品物検索 (scraping) をやっているんだが。 28日以降突然、検索結果一覧ページの取得 (GET) に失敗するようになってしまった。 コケる URL とコケない URL があり、コケる URL にブラウザでアクセスすると、 いつものヤフオク検索結果一覧ページのレイアウトで「条件に一致する商品は見つかりませんでした。」と普通に表示される。 しかし試しに wget でアクセスしたら、404 Not Found エラーで内容が拾えない…。 なんだこれ…? どうやら 28日以降、「検索結果が 0件の時に HTTPステータスコード 404 (Not Found) を返す」仕様にいきなり変更したらしい。 ええぇ…? なに考えてんだ…? その URL にアクセスして「ヤフオクの出品物の検索結果は 0件」という結果 (情報) がちゃんと得られてる、 つまり HTTP のやりとりは正常に終了して“コンテンツ”をきちんと返せているんだから、 HTTP STATUS を 404 (Not Found) にするのはぜんぜん違うだろうが。 “見つからないモノ”のレイヤーがまったく別だろ…。 ホントなに考えてんだ…。つーか、なんも考えてないのか…? …なんか、作ってるヤツのアタマの悪さにげんなりするわ…。
ヤフオクはすこし以前、やはり検索結果が 0件の時 「勝手に」検索カテゴリを変えたり似た語に置き換えて再検索した結果を「大量に」返す仕様にいきなり変更しやがったことがあったが。 この時は検索結果に異常な (探してない) 出品データが大量に紛れ込んだり、スクリプトが処理しきれずにあっぷあっぷになったりしたので分かった。 “検索結果 0件の時は、その旨を表示すると同時に別の検索語やカテゴリをサジェストする” くらいのマットウな仕様を考えつくアタマもないのか、っていうね…。 その、ユーザの求めている結果とはぜんぜん違う「大量」のゴミ情報を、 ユーザがそれと気づかずに (自分の検索した結果そのものとして) 受け取ってしまい、 その中からムダに欲しいモノを (ないのに気づかず) 探して時間をムダにしてしまう、 みたいな可能性とかゼンゼン考えてないんだよな…。 この仕様はとりあえずオプションで無効にできるようになっていたからまだいいものの (といってもオプトアウトだったのがクソだけど)。 その後ブラウザからの検索ではこのクソ仕様は無しになったらしい。いつなったのかは知らないが。 その代わりに今回の 404 返すクソを追加したのかもしれん…。 一応「条件に一致する商品は見つかりませんでした。」の下に、 「同じ条件で商品説明から検索」「同じ条件であいまい検索」とサジェストが表示されてるし。
しかし…いつぞやのログイン時パスワードの文字種・文字数のアタマ悪すぎるフインキだけで決めたっぽい非合理性満点な制約といい…。 yahoo! の技術力 (というか技術者ドモのドタマ) って…ホンット…。

> スラドのアカウントって抹消 (削除) できないのか。まあ放置しとけばいいか…。というかそれ以外どうしようもない。

> なんのかんので、アイスなぞを時々買ってきてしまう…。 けっこうカロリー高いのにっていう。 ここ 1～2年、冷たいモノが歯に響くようになってしまってアイスからはしばらく遠去かっていたんだが、 なるべく歯に当てないようにして、舌の真ん中で溶かすようにして食えばなんとか食えることが分かったので、 かじる必要のないカップアイスから再開。 そうまでして食わんでもええやろ、っていうね。 そして最近ではたまに棒つきアイスも買ってみたりなんかして (これもかじらずに極力舌で溶かす…なんなら皿に乗せて端からスプーンでとか)。 で、先日棒つきアイスをいくつか買ってきた時に今更ながらに気づいたんだが。 こいつのパッケージングも、右利き基準なんだな。 横向きに印刷されたパッケージのアイスを文字が読める向きに置くと向かって右側に持ち手の棒がくるように包装されてんだわ。 まあこの世界はよくも隅々まで、細々 (こまごま) と、右利きに便利なように便利なようにと整えられてるもんだ。 ちょっと感心するくらい (感心はしてない)。 左利きは文化・時代を問わず全体の一割くらいいるらしいが。 まあ、全体の半分いる女性の権利待遇がいまだにこんだけ蔑ろのままな世界なんだから推して知るべしな話かもしれないけど。

> なんだろうね、益体もないボヤキばっかしだね…。 月末のシメがこんなんでいいのか。 …まあいいか。

> 「ノストラダムスの大予言」の通称サソリのベンこと五島勉が 90歳で亡くなったらしい。 よく“人類滅亡の年”から 20年以上も生き延びたなあ。

> 弘田三枝子さんの訃報。21日、心不全で。73歳。

> 以下、ためこんだ URLメモを吐き出し。