「はてなダイアリー」から「はてなブログ」に移行してみた。

help.hatenablog.com

書かれている通り、3ステップで終わり。

記事数が35しかないのに、記事のインポートは3分くらいかかった。 なにをするとそんなに時間がかかるのだろうか?

そのほかの、はてなブックマークとかスターの移行は一瞬。移行する対象がないためと思われる。 リダイレクトの設定も一瞬。

移行したのは、Markdownで書きたかったから。

移行してみてこの記事を書き始めたら、洒落たリンクの埋め込み機能があってびっくり。 この記事の一番上の引用がそれだ。

はてなもちょっとずつ進歩しているんだねぇ。

潜在的なディスクエラー………恐ろしい子!

Windows の次世代ファイル システム: ReFS」を読んだ。

私にとって、ReFSでいちばん欲しい機能は、潜在的なディスク エラーを防ぐディスク スクラブ処理だ。
気づかないうちにデータが回復不能になるかもしれないというのは不安だ。
ReFSではこれへの対策が入るという。
だから今すぐにでもReFSが欲しいのだが、いつ使えるようになるのか分からない。

「ディスクの 一部が経時的に破損していき、読み取りが頻繁に行われないためにそのことが検出されない事態」は、ときどき全ファイルを読み込んでみれば防げるのでは? と思い、cygwin で以下のようなコマンド*1を実行してみた。

/bin/find d:/ -type f -exec cat {} \; > /dev/null

一応これで全ファイルを読むことができるはず。読み取りエラーが発生すればわかるので、バックアップがあるファイルは回復できる。

この方法の問題点はシステム全体の性能が低下することだ。おそらくディスクキャッシュの中身がすべて役に立たないものにされてしまうからだろう。操作に対する応答が、使い物にならないほどに遅くなってしまった。

というわけで、キャッシュを汚さずにファイルの中身を読み込むコマンドを作ることにした。CreateFile のフラグに一つ追加するだけなので難しくはない。大した大きさじゃないので、なくさないようにここにメモっておくことにした。ファイルにコピペして、cl.exe でコンパイルすれば使える。第一引数がファイル名だ。

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#define READ_BYTES (100 * 1024 * 1024)

int main(int argc, char* argv[])
{
  void* buf;
  DWORD totalBytesRead = 0;
  DWORD numberOfBytesRead;
  HANDLE hFile = CreateFile(argv[1],
                            GENERIC_READ,
                            FILE_SHARE_READ,
                            NULL,
                            OPEN_EXISTING,
                            FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING | FILE_FLAG_SEQUENTIAL_SCAN,
                            NULL);
  if (hFile == INVALID_HANDLE_VALUE) {
    fprintf(stderr, "CreateFile failed(%d): %s\n", GetLastError(), argv[1]);
    return 1;
  }

  buf = _aligned_malloc(READ_BYTES, 4 * 1024);
  if (buf == NULL) {
    fprintf(stderr, "_aligned malloc failed.\n");
    return 2;
  }

  while(1) {
    if (ReadFile(hFile, buf, READ_BYTES, &numberOfBytesRead, NULL)) {
      if (numberOfBytesRead == 0) {
        // printf("total %u bytes\n", totalBytesRead);
        break; // 読み終わりました。
      }
      totalBytesRead += numberOfBytesRead;
    } else {
      fprintf(stderr, "ReadFile error (%d): %s\n", GetLastError(), argv[1]);
      break;
    }
  }

  _aligned_free(buf);
  CloseHandle(hFile);
  return 0;
}

これをhoge.exe などの名前でPATHの通ったところにおいて、

/bin/find d:/ -type f -exec hoge {} \;

とすればきっと目的が達成できるにちがいない。

今のところ、システム全体が遅くなるようなこともなく、快適に動いている。
ReFSが使えるようになるまで、ときどきこれで全ファイルを読み込んでみようと思っている。
ディスクのエラーを発見できるかどうかは、テストデータを用意できないので、出てみてからのお楽しみなのだけど。

*1:/bin/find とするのは、WindowsのFINDが実行されないようにするため。

JavaScriptの文字って馬鹿なの?死ぬの?

何か大げさなタイトルだが、ホッテントリメーカーが出したのをそのまま貼ることにしているので。

JavaScript’s internal character encoding: UCS-2 or UTF-16?」を読んだ。

JavaScriptでいう文字というのは、16ビットの数値のことなのだそうだ。
つまり、サロゲートペアは2文字として扱われる。

普段はあまり意識しなくていいだろうけど、要注意だ。

しかし、Unicode、なぜこんなことになってしまったのかねぇ。

jQueryをページの最後にロードのススメ

Stop paying your jQuery tax」を読んだ。

スクリプトをページの最後で読み込むべき理由

Best Practices for Speeding Up Your Web Site の Put Scripts at the Bottom によれば、
ページの読み込み速度を重視するなら、スクリプトはページの最後に配置すべき。スクリプトは、並列ダウンロードの妨げになるらしい。
複数のホスト名から画像を読み込むようにすれば、ダウンロードの並列度を上げることができる。しかし、ブラウザはスクリプトを読み込んでいる間は、それ以外のダウンロードを開始しない。

だから、スクリプトはページを表示し終わった後に読み込むべきというわけだ。

jQueryをヘッダからフッタに移動する方法

.ready() を使うためだけに jQuery をヘッダで読み込んでいる場合は、その機能だけを自分で作ってしまえばいい。

方法は、Stop paying your jQuery tax で紹介されている。簡単なので、試してみてはどうだろうか。

Webアプリ高速化を一行で説明する

Webページのレスポンスタイムのうち、フロントエンドが80〜90%を占める。

the Performance Golden Rule」にそう書いてあった。

この記事では、クライアントがWebサーバから最初の1バイトを受け取るまでの時間をバックエンドの時間、それ以外をフロントエンドの時間と言っている。フロントエンドには、CSSや画像を読み込む時間も含まれる。

いくつかのサイトついてバックエンドとフロントエンドの比率が掲載されている。
フロントエンドの比率はほとんどのサイトで80%を超えており、残り20%をがんばって速くしても、効果が薄いことが分かる。

まあ、納得の結果ではある。

Amazon CloudFrontでDOS攻撃を受けたら破産するの?

心配なのでググってみたら、AWS Developer Forumsのこのページが見つかった。

AWSの中の人の回答は、そんなのは時と場合によるという、つれないもの。
一応、DOS攻撃の対策はしているらしいのだけど、セキュリティ上の理由により詳細は公開できないそうだ。

こわいこわい。
Amazon CloudFront、こわくて使えないわ。

みんな大好き3倍速いC++

sorting in C++: 3 times faster than C.」を読んだ。

何が3倍かと言うと、ソートの速度。
何に対してか? Cで書いた場合に対して、です。
速い理由は、そりゃそうだよ、という内容。
インライン展開ですな。

自分で測ったことはありませんでしたが、
3倍も速いのですね。

C++テンプレートの、オーバーヘッドなしの抽象化は
本当にありがたいものです。