2018年10月16日に初出の投稿

Last modified: 2018-10-16

最近、開発で非常に困るのがブラウザの表示だ。ふだんは Firefox (Quantum) で表示しながら簡易のユニットテストをするのだが、スーパーリロードはおろか、about:config など詳細なオプションでディスクキャッシュやメモリキャッシュを無効にしても、だいたい数分くらいは表示が変わらない。つまり、処理の途中に exit; を挿入してプログラムコードを保存しても、ぜんぜん途中で停止しないのである。そのため、何かボタンを押してファイルを上書きするような処理を書くと、既に消してしまったファイルを改めて消そうとしてエラーになるとか、配列の数がページに表示されているデータの数と異なってエラーになるといった、予想不能なエラーが頻繁に起きるため、ブラウザの表示を全く信用できなくなる。正しく設計・プログラミングしたことでそういう画面になっているのか、それとも数分が過ぎてページを更新するとエラーになってしまうようなコードなのかが、予想できないのである。

おおよそ他のブラウザでも似たような様子なので、これはもしかすると他の原因があるのかもしれない。考えられるのは、

・Atom Editor のバッファリングが実際のファイルに反映されていない。

・Windows 10 Professional のファイルシステムに異常がある。

・VeraCript のような仮想ドライブを使っているので、そのファイルシステムに異常がある。

といったところだ。しかし、VeraCrypt の仮想ドライブではなく C ドライブに置いてあるファイルを編集していても同じように酷いキャッシュが残るので、仮想ドライブは関係なかろう。そもそも、仮想ドライブは 50 GB のバイナリファイルなので、これの「キャッシュ」とか「バッファリング」などという概念は、パフォーマンスの点から言っても設計思想として馬鹿げている。また、Windows 10 のファイルシステムに異常があるなら、他のファイルを他のアプリケーションで編集していても起きる筈だ。たとえば、 Photoshop CC 2018 で画像を編集して赤い矩形を青に換えても実際には赤いままとか、そういう困った事態に陥る筈だが、そういうことは起きていない。テキストファイルを編集してブラウザで表示確認するときだけの現象だ。

ということで、やはり以前にも書いたように Atom Editor のバッファリング機構に問題があると言わざるをえない。そもそも、最近のマルチプラットフォームのアプリケーションは Node.js のようなサーバを使って、マルチプラットフォームという特性を実装する環境の開発を丸投しているため、8ビットのコンピュータでアセンブラを打ち込んでいた中学生当時の僕ていどの才能、つまりプログラミングの基礎的な素養さえあればマルチプラットフォームのアプリケーションが開発できるようになっている。その代償として、Node.js のようなプラットフォームがブラックボックス化してしまい、恐らく Atom Editor の開発者の大半は Node.js がどういう動作設計なのか殆ど知らずに API を叩くだけで「開発」しているのだろう。そして、これも恐らく致命的なことに、こんな誰でも気づく障害にすら何年も気づかないのだから、Atom Editor を開発している GitHub の人々は、実際には Atom Editor を自分たち自身のコーディング作業で使ってもいない可能性がある。

もちろん、大半の開発者とはそういうものを開発し納品している。自分の自宅でも弥生や奉行シリーズを使っている、それらのソフトウェアのプログラマなど殆どいないだろうし、いわゆる勘定系アプリケーションを(設計はともかく)開発しているのは、会社法や法人税法も知らない人々だ。ということで、とりあえずは仕方のないこととして容認せざるをえないし、ページの表示確認は頻繁にできないものと思っておく方がよいだろう。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook