puppeteer 13.0.0

puppeteer 13.0.0がリリースされました。

今回のリリースノートは以下のとおり。

BREAKING CHANGES

・typo in ‘already-handled’ constant of the request interception API

Features

・expose HTTPRequest intercept resolution state and clarify docs
・implement Element.waitForSelector

Bug Fixes

・handle multiple/duplicate Fetch.requestPaused events
・revert “feat(typescript): allow using puppeteer without dom lib”
・typo in ‘already-handled’ constant of the request interception API

https://github.com/puppeteer/puppeteer/releases/tag/v13.0.0

目立った変更はありませんが request interception に関するドキュメントがアップデートされてます。

request interceptionとは

puppeteerの強力な機能の1つとして、HTTP requestをinterceptすることができます。具体的には以下のようなコードで、’request’メッセージをonで拾います。この例ではGoogle Analyticsへのリクエストをブロックしています。

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setRequestInterception(true);
  page.on('request', (request) => {
    if (/www\.google-analytics\.com/.test(request.url())) {
      return request.abort();
    }
    return request.continue();
  });
  await page.goto('https://example.com');
  await browser.close();
})();

これまではこのような記述でよかったのですが、Cooperative Interception Modeが実装されたことにより、少し書き換えが必要になりました。具体的には以下のように変わります。

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setRequestInterception(true);
  page.on('request', (request) => {
    if (/www\.google-analytics\.com/.test(request.url())) {
      return request.abort('failed', 0);
    }
    return request.continue(request.continueRequestOverrides(), 0);
  });
  await page.goto('https://example.com');
  await browser.close();
})();

Cooperative Interception Modeとは

page.on(‘request’)はイベントリスナーですので、同じ’request’メッセージをlistenするイベントリスナーを複数定義することができます。ところがNodeJSは非同期です。そうすると、どのイベントリスナーから順番に実行すればいいのか分からなくなります。

上の例ではGoogle Analyticsをブロックするように書きました。でも、もしかしたらその前にGoogle Analyticsに対して処理するイベントリスナーを定義したいかもしれません。そうなると、どの順番で実行すればいいか保証されなくなってしまいます。

そこで、Cooperative Interception Modeが実装されました。従来の abort() や continue() の第2引数にpriorityを設定できるようになりました。これにより、プライオリティが高い順番にイベントリスナーが処理されるようになります。

なお、引数が指定されていない場合はLegacy Interception Modeとして実行されます。普通の用途では’request’メッセージに対するイベントリスナーは1つしか定義しないことがほとんどだと思いますので、基本的には第1引数、第2引数を設定することをお勧めします。

FreeBSD 12.3-RELEASE

FreeBSD 12系の最新リリース 12.3-RELEASE がリリースされました。

FreeBSD 12.2-RELEASEを運用している環境では、以下のコマンドで簡単にアップグレードできます。make worldをするまでもなくバイナリアップデートできるようになったのは大変便利ですね。

# sudo freebsd-update -r 12.3-RELEASE upgrade
# sudo freebsd-update install
# sudo reboot

ところで12.3-RELEASEからの変更点ではないのですが、リリースノートに興味深い記述がありました。

Starting with FreeBSD-13.0, the default CPUTYPE for the i386 architecture will change from 486 to 686.

https://www.freebsd.org/releases/12.3R/relnotes/

つまり、今後は686以降のCPUでしか動作しないということです。まあ、今時486/586の環境はないに等しいので確かに問題ないアップデートだと思います。そういえば、何年か前に386から486に変わったということがありましたね。あの頃も今時386はないだろう、みたいに思ったことを思い出しました。

ちなみになぜ686に変えるのかというと、上記のリンクから説明分を読んでもらえば分かりますが、686以前のCPUではkernelでエミュレートできない機能があるからです。昨今は64bitバイナリが主流で32bitバイナリを使うことも減りました。その64bitバイナリも486では動かない、といった事情もある訳です。

ダメ着:寒い季節のテレワーク

テレワークしてますか?

コロナ感染が広がって以降、日本でもテレワークが一般化したように思う。

爆発的な感染が減った昨今、テレワークから出社に戻す企業も増えてきているようだが、自分のようなIT職の場合はそのままテレワークのままのところも多い。むしろ、オフィスを縮小してしまっていたり、もはや満員電車による出勤や、始業時間5分前よりも早く起きることができない身体になってしまった人もいるだろう。

ところが、夏と冬はテレワークにとっては実は大敵である。それは室温だ。

オフィスはそれなりに快適な(寒がりや暑がりがいる場合は別)気温に固定されているのだが、自宅の場合はそうはいかない。いや、エアコンなり暖房なりをきちんとつければいいのだが、オフィス等にある業務用…というかオフィスビルの集合管理の空調設備と、一般家庭のエアコンではやはり質が違う。顕著なのが乾燥と室内の温度ムラだ。冬場は特に乾燥がひどい。そして頭ばかりぼーっとして、足は寒い、みたいなことにもなりがちである。

そんな状態でテレワークをするのは結構きびしい。エアコンを酷使しないでも快適な気温で仕事をしたいものだ。そこで考えたのは、暖房設備をあまり使わずとも暖かく過ごすことができる方法である。

テレワークにはゲーミングウェア

IT職のテレワークは主にパソコンに向かっての作業が中心だ。デスクから動くことは稀で、基本的にキーボードとマウスの操作しかしない。この動作、何かと同じではないだろうか? ゲーマーと同じだ。つまり、ゲーマーが暖かく過ごせる格好は、IT職がテレワークで快適に過ごせる格好と同じなのだ。(暴言)

そこで目をつけたのが ダメ着 だ。

「着る毛布」というか「歩ける寝袋」みたいな感じをイメージするといい。8000円弱とそんなに高いものでもないので、物は試しと買ってみたのだが…これがびっくりするほど暖かい。それなりに気密性のあるマンション(室温17〜19度)であれば、ぶっちゃけ寝間着の上にダメ着をきた状態でも暖房なしで過ごすことができる。つまり、始業の直前に起きたとしてもダメ着を上に着るだけですぐに仕事を開始できるのだ。やばい、これは便利すぎる。

難点を上げるならば、やはりトイレに行くのが少し面倒である。一応脱がずに行けるようなチャックが用意されているが、自分の身体にちょうど合うくらいのサイズだと少し難しい。もしも快適にトイレに行きたいなら、一回り大きいサイズを買うのをお勧めする。あと、ダメ着のまま寝ることもお勧めしない。ぶっちゃけ寝間着として使うには少し暑く、朝になったら汗をかいていることになる。

最後にもう1つ。これを着たままうっかりZoom会議に出ないように気を付けよう。

WordPressを始める

使えるものは使ってみる

昔はだらだらと HyperNikkiSystem で日記などを書いていたのだが、ある時からネタもなくなって全く書かなくなってしまった。しかし、今回Webサイトを移設したのを機会にまた日記というか、備忘録的なものを書いてみるのも悪くないと思ったのである。

では、何を使って日記を書くかということになる。

幸いなことにさくらのレンタルサーバには簡単にWordPressをインストールする方法が用意されている。そして、実はWordPressととても関わりが深い仕事をしていたりする。自分でWordPressを使うことは今までなかったのだが、せっかくの機会だし使ってみるのも悪くないだろう。

という訳で、この備忘録はWordPressで書き始めることになったのだ。

まずはテーマ

WordPressを書き始める前に、最初にやっておきたいことがある。それがテーマ選びだ。

2021年11月現在、まっさらなWordPressをインストールすると TwentyTwenty-One というテーマがデフォルトで使われる。テーマ名を見れば分かるように、これは2021年の「2021 (Twenty Twenty-One)」のことだ。軽量で悪くないテーマなのだが、ちょっと味気なさすぎる。ゴリゴリとカスマイズする訳でもなればこれでも悪くないのだが、レイアウトやメニューがちょっと物足りない。

ではお勧めは何かというと GeneratePress である。デフォルトのTwentyTwenty-Oneに負けないくらいの軽さを持ちつつ、様々はhookを用意していて後でカスタマイズがやりやすくなっている。というわけで、まずはテーマを変更してみる。

プラグインの断捨離

次にプラグインの整理。さくらのレンタルサーバからかんたんWordPressをインストールすると、結構な量のプラグインがデフォルトでインストールされる。もちろん有効にはなっていないのだが、インストールされているれば、それだけの量のPHPコードが読み込まれる訳で、必然的にオーバーヘッドになる。使っていないならば削除するにこしたことはない。必要になった時にまた入れればいいだけなのだから。

という訳で、プラグインをきれいさっぱり削除してしまう。もしも、残したいプラグインがある場合は自動更新を有効にしておくことをお勧めする。WordPress本体もそうだがプラグインもセキュリティホールの温床になりがちである。常に最新を維持できるように更新を心掛けたい。

・・・

そして、書き始めたのがこのblogというわけだ。

移行の手順

ドメイン名の移管

まず最初に始めたのは時間がかかるドメイン名の移管である。

前回書いたように、PSI Japan管理であった magisystem.net をさくらのドメインに移管することから始めた。さくらのDNSはドメイン移管するまでは使えないが、自宅サーバで動いているDNSのレコードを整理することも平行して始める。もう使っていないホスト名を消したり、廃止予定のウェブサイトのドメインも消しておく。

メールボックスの移行

続いて、さくらのレンタルサーバの利用を申し込み。

こちらも2週間は試用が可能である。複数のドメイン名を使うことができるが、標準のプランではどちらもメールボックスは同じである。逆に言うと、移行予定のドメイン名(magisystem.net)とデフォルトでさくらから付与されるドメイン名(XXXXXX.sakura.ne.jp)を共有できるということでもある。

そこで、先に XXXXXX.sakura.ne.jp でメールアカウントを作成。メールクライアント側からもこのドメイン名でアカウントを作成し、自宅サーバのメールを作成したアカウントにコピーする作業を始める。ちなみに、自宅サーバの IMAP のディレクトリ容量をサーバ側で調べてみたが1GB弱程度であった。ゴミを消したりしてシュリンクするともう少し減るのではないだろうか。

実はこの作業はそこそこ時間がかかった。というのも、自宅サーバはADSL回線の先にあり、それも下りならともかく、上りは1Mbpsも出ない回線だからである。

ウェブの移行

・・・はしなかった。

サークルで管理しているサイトの移行は行ったが、自分のウェブサイト www.magisystem.net のコンテンツは全て捨てることにした。静的なHTMLは大したことは書いていないし、掲示板(懐しい!)はスパムの温床となるため動作させていなかったし、新しく動作させる気もない。唯一アクセスがあった HyperNikkiSystem による日記は数年どころか10年近く前から更新していない。PerlのCGIはさくらのレンタルサーバで動作するとは思うが、記事の内容的には古すぎるのでGoogle検索の対象から消える方がよいだろう。

ちなみにChiBUGのサイト www.chibug.magisystem.net も静かに閉鎖しておいた。書いていなかったが、メーリングリストも廃止した。

DNSの移行

最後にドメイン移管の報を受けて、DNSのレコードを自宅サーバ(BIND)からさくらのDNSに移行。Whoisに設定されているDNSサーバをさくらのDNSに書き換えて、移行は完了したのである。

  • 2000年12月14日 www.magisystem.net 自宅サーバで運用を開始
  • 2021年11月22日 www.magisystem.net 自宅サーバでの運用を終了
  • 2021年11月22日 www.magisystem.net さくらのレンタルサーバで運用を再開

一応、自宅サーバはIPアドレスは生きているのでまだ稼動している。自宅(とはいっても自分は既に住んでいない実家の方だが)でインターネットにつなげる際に、自宅内のDNSだったりするのでルーター等の設定を変えるまでは止められないのである。そのうちデータをサルベージしたら停止させようと思う。