2016年 05月 30日

Chrome の brotli 圧縮アルゴリズム対応がデフォルトで有効に

https://chromium.googlesource.com/chromium/src.git/+/52b672b2462d6a3751a13187a1003e6fffdfbfbd

手元で確認した限りだと、バージョン 51.0.2704.63 (64-bit) で accept-encoding:gzip, deflate, sdch, br が送信されるようになっていました。

フラグとしてはバージョン49で実装されていたみたいですが、51 (2016-05-25)でようやくデフォルトでも有効になりました。リリースノートには書いてませんが、「log」をたどると上記コミットで有効になったことがわかります。

他のブラウザだと Firefox は 44 (2016-01-26)から有効になっています。

なお、Chrome でも Firefox でも brotli 対応は HTTPS 限定です。

感想

「Chrome が新圧縮アルゴリズム対応!」みたいなニュースが流れてからだいぶ経っています。しばらくは Firefox だけ有効な状態だったので「まだかまだか」とちょくちょくチェックしていたのですが、ついにデフォルト有効になりました。これによって劇的にパフォーマンスが改善するわけではないと思いますが、accept-encoding に新しいのが加わるとわくわくします。

なおこのサイトは全体的に brotli 対応にしてあるので、開発者ツールとかで眺めてニヤニヤしています。

h2o で特定のファイルがオンザフライ圧縮されないとき

h2o は compress: ON にすると、レスポンスに accept-encoding に応じたオンザフライな圧縮が有効になります。ただしデフォルト状態ではcontent-type が text/ から始まる場合と +xml で終わる場合に限られているようです

この条件に一致しない application/json などに対しても圧縮をかけたい場合、file.mime.settypes で設定すれば良いようです。すなわち

    file.mime.settypes:
      "application/json":
        extensions: [".json"]
        is_compressible: yes 
        priority: normal

このようにすれば application/json でも自動的に圧縮してくれます。

これは file. で始まるディレクティブですが、バックエンドサーバから送るレスポンスに対しても(リバースプロキシとしても)これで圧縮がかかるようになります。

2016年 05月 29日

SQLite で「PRIMARY KEY」を《真のプライマリキー》とするには

http://www.sqlite.org/withoutrowid.html WITHOUT ROWID 最適化について

SQLite は常に暗黙的な rowid カラムを持っていることになっている。これはカラムとして明示することもできるし、interger primary key として定義されたフィールドは暗黙的な rowid の代わりにすることができる。SQLite ではこの rowid が基本のプライマリキーになっている。

適当な数値をプライマリキーにしたい場合はこれで全く問題ないが、複合キーだったり文字列をプライマリキーにしたい場合、その表面上のプライマリキーとは別に rowid カラムができる。このケースでは表面上のプライマリキーを使って SELECT しようとすると、表面上のプライマリキーのインデックスを探したうえで、さらに rowid のインデックスを探すことになる。つまり、このケースのプライマリキーとは単に UNIQUE なインデックスでしかない。

そこそこ最近(3.8.2・2013年)からは WITHOUT ROWID をテーブル定義時に指定することで、暗黙的な rowid 生成を抑制して、プライマリキー指定した定義を「真のプライマリキー」とすることができる。

これによって

  • インデックスを辿る回数が減るのでパフォーマンスがあがる
  • 表面上のプライマリキー→rowid のインデックスがなくなるのでDBサイズが減る
  • インデックスが減るので挿入時の負荷が減る

と良いことがある。一方デメリットで気になるのは

  • 古い SQLite (3.8.2 より前) で該当DBを読もうとすると malformed database schema で怒られて読めない
  • sqlite3_last_insert_rowid() が使えない
  • インクリメンタルblob I/Oが使えない (大きなカラムを少しずつ読める低レベルな仕組み)

TF-IDFとコサイン類似度による類似エントリー機能の実装

TF-IDFによる類似エントリー機能の実装をしてみました。ほぼSQLiteですませるような構成です。

やっていることの概要

  1. エントリーのHTMLを適当なワード単位に分割
    • タグ削除とか記号削除とかしつつ、簡単な形態素解析で分割
  2. エントリごとのワード出現回数をSQLiteに全て入れる (テーブル構造的には転置インデックスとして機能)
  3. エントリ・ワードごとにTF-IDF の計算
  4. エントリごとにTF-IDFのベクトルとして正規化
  5. エントリごとに共通語が一定数を超えるエントリ複数に対しコサイン類似度でスコアを計算

ワード分割

MeCab を使った形態素解析などでもいいのですが、お手軽にやりたかったので以下のようにしています。

my $text = ...;
$text =~ s{<style[^<]*?</style>}{}g;
$text =~ s{<script[^<]*?</script>}{}g;
$text =~ s{<[^>]+?>}{}g;
$text =~ s{[^\w]+}{ }g;
my $words = reduce {
	$a->{$b}++;
	$a;
} +{},
	map {
		s/^\s|\s$//g;
		$_;
	}
	map {
		if (/[^a-z0-9]/i) {
			Text::TinySegmenter->segment($_);
		} else {
			$_;
		}
	} split /\s/, $text; 

不必要なHTML要素及びタグを削除し、記号類を全てスペースに置換したうえでスペースで分割し、日本語が含まれていそうな部分だけ TinySegmenter による簡易形態素解析をしています。

自分しか書かない日記の類似をとるので、表記揺れが殆どないことを前提に、アルファベットだけで構成される部分に関してはそのまま特徴語としたいためです。また、プログラムについて書くことが多いので日本語部分は比較的重要度が低いという見立てがあります。

転置インデックス

転置インデックスはあるワードがどのエントリに含まれるかを記録したデータ構造です。エントリー中の文章を適切な粒度で分割して、ワードからエントリーをひけるインデックスをつくります。

転置インデックスだけでも、あるワードが含まれるエントリーのリストを得るのは簡単になるので、例えば「共通ワードが多いエントリ同士は類似している」というスコアリングを採用するなら、転置インデックスのみで実現できます。

DBとしてSQLiteを使っているので、簡単な定義の単一テーブルだけを作ってなんとかしています。

CREATE TABLE tfidf (
	`id` INTEGER PRIMARY KEY,
	`term` TEXT NOT NULL,
	`entry_id` INTEGER NOT NULL,
	`term_count` INTEGER NOT NULL DEFAULT 0, -- エントリ内でのターム出現回数
	`tfidf` FLOAT NOT NULL DEFAULT 0, -- 正規化前の TF-IDF
	`tfidf_n` FLOAT NOT NULL DEFAULT 0 -- ベクトル正規化した TF-IDF 
);
CREATE UNIQUE INDEX index_tf_term ON tfidf (`term`, `entry_id`);
CREATE INDEX index_tf_entry_id ON tfidf (`entry_id`);

見ての通りですがターム(ワード)とエントリIDでユニークなテーブルです。

エントリ内のHTMLを適当な粒度で分割したのち、このテーブルに入れています。この段階では term, entry_id, term_count だけ埋めます。

INSERT INTO tfidf (`term`, `entry_id`, `term_count`) VALUES (?, ?, ?);

TF-IDF

TF-IDFは特徴語抽出のアルゴリズムです。文書中のワード出現頻度 (Term Frequency) と、全文書中のワード出現頻度の逆数( Inverse Document Frequency) から、ある文書のあるワードがどれぐらいその文書を特徴付けているかをスコアリングできます。

転置インデックスから「共通ワードが多いエントリ同士は類似している」というスコアリングを使ってエントリを抽出すると、ワード数の多いエントリ同士は類似していなくても類似しているとスコアリングされてしまいます。

TF-IDF を使って各ワードに重み付けをすれば「特徴語の傾向が似ている文書は類似してる」というスコアリングにすることができます。

まずは後述する正規化を考えずにテーブルの tfidf カラムを埋めます。

-- SQRT や LOG を使いたいので
SELECT load_extension('/path/to/libsqlitefunctions.so');

-- エントリ数をカウントしておきます
-- SQLite には変数がないので一時テーブルにいれます
CREATE TEMPORARY TABLE entry_total AS
    SELECT CAST(COUNT(DISTINCT entry_id) AS REAL) AS value FROM tfidf;

-- ワード(ターム)が出てくるエントリ数を数えておきます
-- term と entry_id でユニークなテーブルなのでこれでエントリ数になります
CREATE TEMPORARY TABLE term_counts AS
    SELECT term, CAST(COUNT(*) AS REAL) AS cnt FROM tfidf GROUP BY term;
CREATE INDEX temp.term_counts_term ON term_counts (term);

-- エントリごとの合計ワード数を数えておきます
CREATE TEMPORARY TABLE entry_term_counts AS
    SELECT entry_id, LOG(CAST(SUM(term_count) AS REAL)) AS cnt FROM tfidf GROUP BY entry_id;
CREATE INDEX temp.entry_term_counts_entry_id ON entry_term_counts (entry_id);

-- TF-IDF を計算して埋めます
-- ここまでで作った一時テーブルからひいて計算しています。
UPDATE tfidf SET tfidf = IFNULL(
	-- tf (normalized with Harman method)
	(
		LOG(CAST(term_count AS REAL) + 1) -- term_count in an entry
		/
		(SELECT cnt FROM entry_term_counts WHERE entry_term_counts.entry_id = tfidf.entry_id) -- total term count in an entry
	)
	*
	-- idf (normalized with Sparck Jones method)
	(1 + LOG(
		(SELECT value FROM entry_total) -- total
		/
		(SELECT cnt FROM term_counts WHERE term_counts.term = tfidf.term) -- term entry count
	))
, 0.0)

一時テーブルを使いまくっています。何度も同じ TF-IDF 計算をするなら効率化のため保存しておけそうなテーブルもありますが、更新処理が複雑になるためTF-IDF更新時に作っては消しています。修正が頻発するような開発初期段階では特に一時テーブルは設計変更などに強くて便利です。

TF-IDF のベクトル正規化

TF-IDF を計算して、エントリごとにエントリ中の単語数次数を持つ特徴ベクトルを作ったことになります。このあとコサイン類似度をとるわけですが、その際にはベクトルの大きさが不要なのでこれを正規化します。

ベクトル正規化はあるベクトルを方向(角度)をそのままに長さを1にするとこを言っています。コサイン類似ではエントリごとの角度だけを比較したいので、あらかじめ文書ごとのベクトルを正規化することで計算を簡単にできます。

-- エントリごとのTF-IDFのベクトルの大きさを求めておきます
CREATE TEMPORARY TABLE tfidf_size AS
	SELECT entry_id, SQRT(SUM(tfidf * tfidf)) AS size FROM tfidf
	GROUP BY entry_id;
CREATE INDEX temp.tfidf_size_entry_id ON tfidf_size (entry_id);

-- 計算済みの TF-IDF をベクトルの大きさで割って正規化します
UPDATE tfidf SET tfidf_n = IFNULL(tfidf / (SELECT size FROM tfidf_size WHERE entry_id = tfidf.entry_id), 0.0)

コサイン類似

コサイン類似はベクトル長さを無視しての角度の差を求めるためのアルゴリズムです。2つのベクトルの角度の差のコサインを求めます。例えば、2つのベクトルの角度差が0(一致している)場合、 = 1、90度(直交・相関関係なし) なら 、180度(負の相関)なら と、なります。

前もってベクトル正規化をしているのでかけ算と足し算だけで計算できます。

ただ計算が簡単とはいえ、候補エントリ数*関係するワード(ターム)の数だけレコードをひいてくる必要があるので結構大変になってしまいます。

ここの効率化方法があまり思いつかず以下にようにしています

  • エントリの特徴語を50語取得する(TF-IDF順にソートして大きいほうから50件)
  • 特徴語を含むエントリを共通語が多い順に100エントリ取得する (コサイン類似前に足切り)
  • それぞれのエントリ同士でコサイン類似度を計算してスコアを算定してソートする

特徴語の共通語が多い順で足切りをしているので、長いエントリほどここでは有利となってしまいます。また、極端に短いエントリに関しては100エントリ以上が同一数の共通語を持つ状態になる場合があり、このケースではスコアをつける前に「類似」と判定すべきエントリが確率的に足切りされてしまうので正確ではありません。

TF-IDF の大きい順に50件だけを採用しているので、正確なコサイン類似度ではありません (ベクトル正規化のときに使った次数と違う) が、無視しています。

うまくいった場合はスコアリングで上位に類似エントリが集まるようになります。

-- 類似していそうなエントリを共通語ベースでまず100エントリほど出します
CREATE TEMPORARY TABLE similar_candidate AS
	SELECT entry_id, COUNT(*) as cnt FROM tfidf
	WHERE
		entry_id > ? AND
		term IN (
			SELECT term FROM tfidf WHERE entry_id = ?
			ORDER BY tfidf DESC
			LIMIT 50
		)
	GROUP BY entry_id
	HAVING cnt > 3
	ORDER BY cnt DESC
	LIMIT 100

-- 該当する100件に対してスコアを計算してソートします
SELECT
	entry_id AS eid,
	SUM(a.tfidf_n * b.tfidf_n) AS score
FROM (
	(SELECT term, tfidf_n FROM tfidf WHERE entry_id = ? ORDER BY tfidf DESC LIMIT 50) as a
	INNER JOIN
	(SELECT entry_id, term, tfidf_n FROM tfidf WHERE entry_id IN (SELECT entry_id FROM similar_candidate)) as b
	ON
	a.term = b.term
)
WHERE eid != ?
GROUP BY entry_id
ORDER BY score DESC
LIMIT 10

これによって求められた類似エントリは別途テーブルに保存しておいて、表示時にはこのテーブルのみをひいてくる構成にしました。

2016年 05月 25日

SQLite で LOG や SQRT を使うには

SQLite にはかなり基本的な算術演算関数しかない。追加で何かしらやるためには拡張 (Run-Time Loadable Extension) を使う必要がある。

LOG や SQRT などはオフィシャルの Contributed Files のextension-functions.c をコンパイルして使う。 http://www.sqlite.org/contrib

Ubuntu でのコンパイル。当然ながら SQLite のヘッダファイルなどが必要なので入れておく。

sudo apt-get install libsqlite3-dev

そのうえで以下のようにコンパイルする。apt-get で入れてる場合 -I などは指定しなくてもデフォルトで良さそう。必要なら pkg-config sqlite3 とかして引数を得る。

gcc -fPIC -shared extension-functions.c -o libsqlitefunctions.so -lm

extension-functions.c の冒頭にもコンパイル方法が書いてある。ただし、今はそれだと上手くいかなくて、-lmは最後につけないとダメ。罠があって、リンクに失敗しても load_extension するまで気付かない。

使うときは以下のように load_extension() を使う

select load_extension("/path/to/libsqlitefunctions.so");

Perl の DBD::SQLite で使うには

Perl から DBD::SQLite 経由で使う場合、

$dbh->do('SELECT load_extension("/path/to/libsqlitefunctions.so")');   

とする。が、実はこれだけだと動かず、以下のように謎のエラーが出る。

DBD::SQLite::db do failed: SQL logic error or missing database
not authorized 

ドキュメントにも書いてあるが、sqlite_enable_load_extension を前もって呼ぶ必要がある。

$dbh->sqlite_enable_load_extension(1);
# または
$dbh->func(1, "enable_load_extension"); 

備考

拡張の開発方法については Run-Time Loadable Extensions を見る。

2016年 05月 24日

逆作用ピンセットは便利

電子工作などのときに、一時的に部品を挟んでおきたいときとかの道具として何を使っているかといえば標題にある通り逆作用ピンセットというもので、これはすなわちノーマリークローズなピンセットである。力を加えていないときはピンセット自体のバネで閉じており、挟んでおいておくことができる。

便利な特徴がいくつかある

  • ピンセット形状なので、基板の中央付近の部品など、少し遠い位置を一時的におさえたりできる
  • ほどよいバネ圧

この手の逆作用ピンセット(反作用ピンセットや逆作動ピンセットなど、用語が揺れてる)は100均でも売ってることがある。自分が使っているのも100均でたまたま買ったものだけど、ものすごく活用している。

goot(グット) 逆作用ピンセット 大 TS-17 - 太洋電機産業(goot)

太洋電機産業(goot)

5.0 / 5.0

余談:ヒートクリップ

だいぶ前に便利かと思ってヒートクリップというのを買ったことがあるが、結局ほとんど使っていない。

goot(グット) ヒートクリップ 放熱用クリップ 2種類セット H-2SL - 太洋電機産業(goot)

太洋電機産業(goot)

2.0 / 5.0

ヒートクリップはリード付き半導体のはんだ付け時に熱から守るために使うというのが本来の用途だが、そもそもそんなに熱に弱い半導体って今時使うことがない。

そして汎用のクリップの用途で考えるとこの商品はバネ圧が強すぎて使いにくい。ので、この手の用途でも逆作用ピンセットのほうが圧倒的に使いやすい。

2016年 05月 23日

時計の電池を変えた

[シチズン Q&Q] 腕時計 フォルコン V722-850 ブラック - CITIZEN

CITIZEN

5.0 / 5.0

腕時計は普段しないのだが、某国家試験をうけるときに時計が必要だったのでこれを買っていた。最近はしばらく妻が使っていたが、電池切れで動かなくなってしまった。妻用には別の時計を買ったが、動かない時計だけ放置しておくのもなんなので電池を変えることにした。

元々入っていたのは SR626SW だが、100均で売ってたのが SR621SW だけだったため、こちらで代用した。この2つは厚みが違う。よって入らないことも予想されたが、100円なので試してみることに。結果的にはうまくいった。ただし、やはりすこしゆるい。

元が1000円の時計を時計屋で電池交換してもらうのもかなりアレなので、自分でやった。

この時計の場合特に特殊な工具はいらず、小さめのドライバーがあれば裏蓋をはずせる。裏蓋さえはずせば電池が見えるのでとりかえるだけだった。

余談:ボタン電池・コイン電池の型番

Wikipedia のIEC_60086の項にも書いてあるけど、型番によって化学構造(電圧や電流などの決定要因)と寸法がわかるようになっている。

SR626SW は

2016年 05月 19日

モバイルHFトランシーバKX2。KX3 と比較

KX2
http://qrznow.com/new-elecraft-kx2-announced-this-thursday-at-the-dayton-hamvention-2016/

アメリカの Elecraft から KX2 という無線機が出たらしいです。KX3 よりも小さい! バンドはCW/DATA/SSB 80m〜10m と、KX3 からは 50MHz と AM/FM がオミットされています。出力も KX3 が最大15Wに対しKX2 は 10Wのようです。KX3 のオプションにあったルーフィングフィルタはKX2ではなし。I/Q 出力もなし。

肝心の重さは 13oz (369g) と、KX3 よりもさらに半分ぐらいの軽さのようです。

本体 $749。ATU が $179.95、Li-ion のバッテリーパックが $59.95。モバイルの HF トランシーバとしては競合するものがもともと殆どないんですが、KX2 は完全に競合するものがなく、コストパフォーマンスは良さそうです。とはいえ I/Q 出力がないのがちょっと時流からするとキツい感じがします。回路図みながら辿ればとれそうな気はしますが。

2016年 05月 15日

Google Search Console のページのダウンロード時間


sitemap.xml を送信した翌日ぐらいに Googlebot からの連続したアクセスがくるようになる。Googlebot は HTTP/1.1 で Keep-Alive が有効なため、普段にパラパラくるアクセスよりも、このときのように連続してアクセスされる場合、多くの場合でコネクション時間がなくなるために高速にレスポンスを返せる。

連続したアクセスの場合、2分ぐらい Keep-Alive している。

これは結果として Search Console の「クロールの統計情報」に表示されている「ページのダウンロード時間 」のグラフにも反映されているような感じで、sitemap.xml を追加した次の日あたりで平均ダウンロード時間がかなり少なく表示される。

2016年 05月 14日

Server::Starter を node.js のサーバ起動に使う

Server::Starter は hot deploy 用の汎用スーパーデーモンで、Perl で書かれています。h2o の起動にも使われているのでみなさんおなじみでしょう!

Server::Starter がやってることは、Server::Starter 側で listen したソケットの fd を環境変数につっこんで子プロセスを起動というものです。子プロセス側では渡ってきた環境変数を読んで、fd について accept すれば良いことになります。

これを node.js でやるには以下のようにすれば良いようです。

//#!/usr/bin/env node
"use strict";

const http = require('http');

const server_starter_port = process.env['SERVER_STARTER_PORT'];
if (!server_starter_port) {
	console.log('SERVER_STARTER_PORT is not set');
	process.exit(1);
}
const fds = server_starter_port.split(/;/).map( (i) => i.split(/=/) );

const server = http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
	res.end('Hello World\n');
});

process.on('SIGTERM', () => {
	console.log('server exiting');
	server.close();
});

for (let fd of fds) {
	console.log('listen', fd);
	server.listen({ fd: +fd[1] });
}

起動はたとえば以下のように

start_server --port=5001  -- node server.js 

http.Server の listen() のドキュメントには fd を渡せるバージョンが書いてありませんが、net.Server の listen() がサポートしているので、同様に渡せるようです。

これだけで node.js のプロセスの hot deploy が簡単にできます。

余談:cluster

node.js には cluster というのがあります。これは node.js を複数プロセスで動かすための仕組みなんですが、これの woker プロセス側の listen() は master プロセスと ipc してうまいことやるみたいな感じのようです。