SVX日記

　 はっ!!　あー、よかった。夢かよ……。先日に引き続いて、再び愛用のナビホークがエラい状態で修理から戻ってくる夢を見た。前回は文字盤がノッペリとグレーになってしまっていたが、今回は計算尺がツルンとチタンカラーになっていた。あー、早く戻ってこないものか。何度もこんな夢を見るなんて、自分が思う以上にあの腕時計に執着しているのだろうか。そのうち腕時計の「妄人」になってしまったらどうしよう。

　 以前に何度か「冷蔵庫」にされてしまったコトがあったしなぁ。

　 仕事から帰ってうどんを食う。＜かきかけ＞

　 話は替わって、問題はGoogleなのである。このSVX日記も1年近くになろうとしており、自分でもあきれるほどの駄文を毎日のように大量に排出しているが、内容が以前の話題に関連するときは過去の日記へのリンクを積極的に貼ろうと心がけている。しかしながら、もう自分でも管理しきれないほどの量に達しており、リンクするべきポイントを見つけるのがイヤになるほど面倒なのである。

　 このSVX日記を開設した当初はtdiaryをそのまま利用していたが、title要素に日記のタイトルを入れたり、サイドバーを付加したり、Google検索のフォームを入れたり、全日記一覧機能をつけたりして徐々に機能増強を図ってきた。というのも、すべてリンクを貼るのをラクにしたいタメなのである。

　 でもってGoogleのサイト内検索だ。これが引っかけられないのなんの。あの神と崇められるGoogle様をしてなんだこのテイタラクは。明らかに書いたはずの単語を入れているのに出てこない。でもって、出てきたと思ったら「本日のリンク元」に引っかかっていたりする(コレはGoogleのせいではないが)。これじゃ役に立たないのである。

　 仕方ないのでココにきてさらに機能追加である。独自に検索機能を立てるのだ。オープンソースの検索エンジンといえば「namazu」である。tdiaryにnamazuを組み込む方法は既に確立されているので簡単である。オイラの場合、サーバがdebianなのでインストールもラクだ。＠everybody apt-get! apt-get!　なのである。

　 まずはnamazuのインストール。人によってはkakashiやchasenのインストールも必要だろう。オイラは漢字かな混じり文をfestivalに読み上げさせたり、カタカナしか出ないディスプレイに出力させたりしたコトがあったのでkakashiもchasenもインストール済みである。

apt-get install namazu2
apt-get install namazu2-index-tools

　 間髪いれず、tdiary環境へnamazuのcgiと設定ファイルをコピー。

cp /usr/lib/cgi-bin/namazu.cgi /home/svx/public_html/diary/
cp /etc/namazu/namazurc /home/svx/public_html/diary/.namazurc

　 設定ファイルをチョコチョコとイジる。

Index		/home/svx/diary/index
Template	/home/svx/diary/index
Replace		/home/svx/diary/cache/html/(\d\d\d\d)/(\d\d)(\d\d).html http://www.itline.jp/~svx/diary/?date=\1\2\3
Lang		ja
EmphasisTags	"<strong class=\"keyword\">"   "</strong>"
ContentType	"text/html;charset=EUC-JP;"

　 tdiaryは日記のhtmlをcgiで動的に生成するので、静的なhtmlファイルが存在しない。それではnamazuが検索インデックスを作れないので、tdiaryに標準添付のsqueeze.rbというプラグインを使って、日記をhtml化する。

./squeeze.rb -p /usr/share/tdiary -c /home/svx/public_html/diary -x .html /home/svx/diary/cache/html　

　 html化できたら、namazuにインデックスを生成させる。

mknmz -c /home/svx/diary/cache/html --output-dir=/home/svx/diary/index

　 tdiaryのサイドバーにnamazuの検索窓を追加。

<CENTER><FORM method='GET' action='http://www.itline.jp/~svx/diary/namazu.cgi'>
サイト内をnamazuで<BR>
	<INPUT type='text' name='query' size='16' maxlength='255'>
	<INPUT type='submit' value='検索'>
</FORM>
</CENTER>

　 tdiaryの.htaccessには.rbしかCGIとして定義されていないので、イカの行を加え、namazu.cgiがCGIとして動くように定義を追加する。

AddHandler cgi-script .cgi

　 最後に、これから毎晩namazuにインデックスを更新させる設定をして、完了である。

5 3 * * * mknmz -c /home/svx/diary/cache/html --output-dir=/home/svx/diary/index

　 これでヨソのGoogle様を利用せんでも、自前でバリバリと検索できるnamazu様で日記の利便性もさらに向上じゃ!!　……と、思ったのだが……うむ、まだチューニングの余地はあろうが、あまり結果はカンバしくないようだ。Google様と併用すればなんとか、というレベル。

　 むー、この日記、文章中に妙なカタカナ表記が多いからだろうか。漢字の単語が並ぶのがキライなのと、漢字は見た目の密度が濃いのがイヤなのと、なによりフォントを変更せずにライトに強調できるのがスキでワザとやっているのが……ウラメっとるのかな。ま、なんにせよsqueeze.rbがhtmlにまでリンク元を生成してしまうのは、なんとかして回避させるとしよう。今晩はここまでじゃ。

　 とりあえず

　 長らくチマチマと作業を進めてきた、家庭用電源の50Hzで時計を作るプロジェクトであるが、とりあえず50Hzをカウントして時刻を表示する、というところまできた。ずっと疑問に思っていた電源の50Hzの精度であるが、脇に腕時計を置き、秒単位のズレを目視で確認した限りでは、1時間で0.5秒程度のズレが生じるようだ。

　 予想よりもかなり正確だという印象だが、もしかしたら完璧な精度を持っているかもしれない、とも思っていたので、その意味では予想を裏切られた。

　 しかし、1時間で0.5秒ということは、24時間で12秒、5日で1分、1ヶ月で6分……うーむ、100円で売っている腕時計でも、平均月差は30秒程度だろうから、ちょっとイマドキの時計としては使い物にならない感じだ。でも、敢えてコレで行ってみようかな、と思う。日や季節によっても多少は違ってくるかもしれず、それを体感してみたいという気持ちもあり……

　 ……こっちの「コレ」で容易に時刻修正ができるようにしてあるなら、それはそれで修正作業自体がちょっと楽しめるんじゃないか、と思ってのことだ。

　 その「コレ」とは、ロータリーエンコーダ。ふたつのパルスを読み取ることで、回転方向と速度を検出するセンサだ。かなり前にアルカノイドのパドルコントローラを作ろうと思って実験用に購入しつつ、放置してあったパーツだ。

　 扱いは難しいんじゃないか？　秋月ではそれだけのキットも出ているくらいだし……と、ちょっと腰が引けていたのだが、実はムチャクチャ簡単である。実は、以下の十数行のコードでハンドリングできるのだ。

RotaryDecode
	SWAP	(GPIO)>A
	AND	A, 0000_0011b
	LD	(BUF), A
 
	RR	(BUF)>A			; 観測値を正規化
	AND	A, 0000_0001b
	XOR	(BUF), A>A
	SUB	(LAST), A		; 前回 - 今回
 
	BIT	0, (LAST)
	JP	Z, RotaryDecode1	; 不動 or 無効
 
	SKIPRES	1, (LAST)
	INC	(VAL)			; 正転
	SKIPSET	1, (LAST)
	DEC	(VAL)			; 逆転
RotaryDecode1
	LD	(LAST), A

　 珍しく電車の中で組んだコードがそのまま動いた。先日完成した7セグモジュールに値を出力させてみる。クリクリクリ。おぉー、気持ちいい。

　 ロータリーエンコーダは、ボタン等のスイッチに比べると、非常に人間のフィーリングにマッチするインタフェイスだ。これから積極的に使っていこう。

　 さて、ハードウェア工作とは何の関係もないが、最近、ウチのサーバがよく落ちる。

　 messagesをみると、OOM-Killerが動いているので、何かのプロセスのリークか何かだろうと判断し、たいして気にもせず強制再起動で回避してきたが、最近、落ちる頻度が増してきて、リセットボタンを押すのがうっとおしくなってきた。特に設定をイジっていないのに頻度が増すということは、内部要因ではない可能性が高いということだ。どうにかせねばなるまい。

　 それ以前に、お客のLinuxサーバをどうにかすることで飯を食っているのに、自分のサーバをボコボコと落としているというのは、カッコ悪い。まさに医者の不養生なので、どうにかするコトにする。まずは、ロギングツールを稼動……した途端、都合よく、すぐ再現した。どれどれ。

　 なんと、バカみたいにhttp要求を連続(秒間20とか)で投げ続けるアホがいた。rubyのcgiプロセスが溢れかえっていて、落ちる寸前にはロードアベレージは数百に達している。tdiaryはかなり重く、メモリも食うので、秒間1アクセス程度にしてもらわないと困るんだがなぁ。どうしようかなぁ。いくつか案を考える。

1. アホのIPをハジく
2. Apacheに負荷制御モジュールを入れる
3. ユーザの同時プロセス起動数を制限する
4. iptablesに連続アクセス防御ルールを書く

　 1はアホが複数現れるとイチイチ面倒。2はモジュールを入れるのが面倒。4は画像が多いウチのサイトには適応しづらい。というわけで、3がいい。連続でCGIにアクセスされた場合、CGIの起動を故意に失敗させ、Apacheには内部エラーとして処理させる。結果としては負荷制御になるワケだ。

　 ユーザの同時プロセス起動数といえばulimit -uのmax user processesなのだが、これは環境変数みたいなものなので、CGIが起動してから設定しても遅い。そもそも、CGIの起動を抑制するという目的に合わない。Apacheの起動時に指定してしまう手もあるが、Apache自身に制限が加わるのは困る。

　 とりあえず、現在の設定値を確認しよう。CGIの中に以下の1行を追加する。

print `/bin/bash -c 'ulimit -a'`.gsub(/\n/, "<BR>\n")

　 CGIをリロード……うむ。max user processesは数千だ。これじゃ、負荷制御にはならない。

　 ただ、これをApacheから変更させるのは難しそうだ。ほかの方法を探すか……あったぞ、RLimitNPROC。Apacheの設定パラメータだ。これをhttpd.confに書けばいいのか……

RLimitNPROC 20

　 ……っと。Apacheを再起動。これで設定は有効になったはず……なのだが、確かめようがないな。ん？　もしかして？　と、思って、さっきのCGIをリロードしてみる……

max user processes (-u) 20

　 ……なんと。RLimitNPROCって、内部的にはulimitを設定しているだけじゃないの。

　 実際の効果のほどは、まだわからないが、これでしばらく落ちなければ効果あり、としよう。では。

　 そっ、そんなにシリーズ化するつもりはなかったのだが、思いついたらやりたくなってしまった。見てのとおり「艦これ学習帳」である。やりたくなったら、やっちゃいなー、やっちゃいなさいなー。

　 ジャポニカ学習帳とプリンタ用シール用紙を買ってきて、学習帳の表紙をスキャンして、スクリーンショットを貼り込んで、ちょいちょいして、印刷して、表紙に貼って、切って、完成。最近、オレ的ブームだが、クリアの水性ニスを塗ると、印刷面保護になってイイ。

　 編集した画像(300dpi)を置いておく。

　 中身のノートは、ガキがいま使っているモデルに合わせてあるので、ガキが欲しがったらあげてしまうつもりなのだが、これは学校に持って行っていいノートなのだろうか……さて、次は五月雨学習帳でも……。

　 結果

　 自分の職場では、なんやかんやとPC環境の締め上げが続いている。どうもワードエクセルな仕事しか想定していない方策のように見えて、開発系エンジニアの不満は増大しているんじゃないだろうか。なんつうか「セキュリティ事故防止のためならどれだけ効率が下がってもいい」という「健康のためなら死んでもいい」みたいな指向を感じる。まぁそれは上が決めることなのだけれど、上は開発系エンジニアの気持ちを理解していない、もしくは、重要でないと考えている、と受け取られても仕方ない。例え業績が下がろうと、事故の責任を取らさせる可能性を下げたいのだろう。

　 そして遂には「机上のデスクトップPCも全廃」ということらしいのだが……そこで「こんなこともあろうかと」である。フフン。ちょっと前に準備しておいた「リモートデスクトップコンテナ」の出番である。要するに自製の「クラウドデスクトップ」だ。

　 以前に作った「crd」は、それはそれとして完成形なので、日本語対応＋オレカスタムは「crdplus」として「crd」を継承する形でチューニングしていく。とりあえずrubyやemacsやgcc程度を入れたら、アッサリと自製のメーラであるmaveが動き出し、割と普通に仕事環境として使えるようになってしまった。/homeはPVに出してあるので、FirefoxやIMの設定も残るし、コンテナを再起動した場合の影響は想像以上に少なかった。

　 ユーザの登録と英語キーボードの設定は手持ちのノウハウで解決した。困ったのは、時間の経過でTCPセッションが切れる問題と、ブラウザでタブが増えるとページを開く動作が不安定になる問題。しかし、前者は無駄にプロキシを経由していたことが原因で、コンテナ環境側の問題ではなかった。後者はまさかのリソースの問題で、docker-compose.ymlのdeployにresourcesの設定を加えたら、ウソのように安定して動くようになった。最後、言語とタイムゾーンの設定の問題が残ったが、それも起動直後に/etc/localtimeと/etc/locale.confを修正する形で解決。特段、不満のない環境になってしまった。既に数週間程度は使っているが、一度も落ちたりしていない。

　 しかし、だ。完全に原因を特定したわけではないが、頻繁にシフトやコントロールの押下を取りこぼすんだよね。タイプミスを直そうとすてhh……ってなる。上記の環境につなぐ時にはWindoze環境を経由しなければならなんだが、その環境でも起きるってことは、要するにその品質が悪いってことだ。手元の環境では起きないし……TCP使ってて取りこぼす理由がわからない。さらには、また別の環境への移行を求められているんだが、そっちに移行すると輪をかけて遅延が大きくなる。挙句には、センタークリックをすると8秒近く固まってしまう症状もある。控えめにいっても、クソをコネ上げたような環境だといえよう。

　 今に始まったことではないんだが、歳を取るにつれ「作業中に思いついたアイデアを瞬時に忘れてしまい、直前の作業をトレースしたりして思い出す」という頻度が増えてきている。で、そこにデスクトップ環境の遅延が加わると、この頻度を倍増させてしまうのだ。結果、極端な効率低下が起きるので、モチベーションはダダ下がりである。自分は、趣味だろうが、仕事だろうが、基本的には高回転でコトを進めたいのだ。

　 同じ金をもらえたとしても、気分良く仕事ができない環境で作業するのは不満だ……とはいえ、マズローの5段階欲求ではないが、それ以下がある程度は満たされているから感じる不満、と言えなくもないんだよな。うぅむ……。