2012年も延長制限あり

開幕まで知らなかったけど、今年も延長戦は3時間30分を経過したら次のイニングに入らないルールだったのね。
この特別ルール。窮余の策だった割にはクリーンヒットだった。確かに引き分けは増えたけれど、それを補って余りある継投の面白さがあった。今シーズンも、惜しげも無く切り札を投入していく展開が見られるのは嬉しい。

涌井しっかりせい！

Exoplanet

面白いiOS用アプリを見つけた。
http://itunes.apple.com/jp/app/exoplanet/id327702034
改めて視覚化されると、宇宙は広いなぁ。
visual database of all discovered extrasolar planetsと詠うだけのことはあって、新しい情報もきちんと反映されている。

2012パリーグ順位予想

チラシの裏。
パリーグ開幕間近ということで、2012年レギュラーシーズンの順位予想をしてみる。

1. 埼玉西武ライオンズ
2. 福岡ソフトバンクホークス
3. オリックス・バファローズ
4. 北海道日本ハムファイターズ
5. 千葉ロッテマリーンズ
6. 東北楽天ゴールデンイーグルス

優勝はライオンズ。相変わらず中継ぎ以降が心配だけど、願望補正をかけると優勝以外ありえない。
2位と3位は迷ったけれど、ホークスを上にした。先発がごっそり抜けたのは痛いけれど、ほどほどの投手でもあの打線が勝たせてくれるんじゃないかな。順当に補強できたバファローズも手強そう。許銘傑を取られたのは痛いなぁ。
貧打のチームを勝たせてくれる大エースを失ったファイターズは、正直言って苦しいと思う。出戻りスレッジの活躍に期待か。
残るはマリーンズとイーグルスだが、帰ってきたサブローと元燕組に期待して、マリーンズを上にした。岩隈の抜けたイーグルスは、今年も打線が怖くなさそうだなぁ。流れ者ホセが確変に入ったときだけ、ちょっと上向く感じとみた。

メールのアーカイブ

これまでGmailでは全メールを受信ボックスに置きっぱなしだったのだが、今更ながらアーカイブ機能を使い始めた。

基本的には読んだらアーカイブ。でも、後で返信しようと思ったら受信ボックスに残しておく。こんな程度の使い分けでいいのかな？
受信ボックスの未読フラグだけで管理としては十分だったから、今ひとつアーカイブ機能のありがたみが分からん。そのうち分かるのか？

Makeの暗黙のルール

意外と把握していないことシリーズ。手元のGNU Make 3.81の暗黙のルールを調べてみた。以下、主なルールを抜粋。COMPILE.cとかはその定義で置き換えているので、再定義したら下のルールも変わる。

C, C++のコンパイル
%.o: %.c	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@ $<
%.o: %.cc	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@ $<
%.o: %.C	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@ $<
%.o: %.cpp	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@ $<
リンク
%: %.o	$(CC) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
C, C++ソースから実行バイナリまで一気通貫
%: %.c	$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
%: %.cc	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
%: %.C	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
%: %.cpp	$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
おまけ1
%.ln: %.c	$(LINT) $(LINTFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -C$* $<
おまけ2
%.p: %.web	$(TANGLE) $<
%.tex: %.web	$(WEAVE) $<
%.c: %.w	$(CTANGLE) $< - $@
%.tex: %.w	$(CWEAVE) $< - $@

lintチェック用のルールがあることと、WWWじゃないKnuth先生のWEBのルールがあることは、知らなかった。
ちなみに、これらのルールで使用するデフォルトのツールは以下の通り。

CC = cc
CXX = g++
LINT = lint
TANGLE = tangle
WEAVE = weave
CTANGLE = ctangle
CWEAVE = cweave

Simple is better.

結論。iCloud Mailのサーバ上に振り分けた状態でメールを置くのは諦めた。
大量のメールの振り分けは、どうもうまく行かないばかりか、失敗した結果、せっかく重複メールを削除したのに、また複製ができてしまう(メールの移動という作業がアトミックではない(コピーしてから元メールを削除)から、途中で止まるとコピーだけが残るのだろう)。色々試行錯誤しているうちに、とうとうiCloudから容量オーバーの通知が来る始末。もう諦めて、単一のメールボックスで単純に運用することにした。

…とは言え、全く振り分けないのも不便なので、Mail.appのスマートメールボックスを使ってみようと思う。検索結果はそれなりにキャッシングしてくれる…、よね？ 馬鹿正直に検索するようなら、もう他のMUAに浮気する。

なんだか、Gmailの偉大さを再認識するのに2日かけたような気がする。

mboxから重複メールを削除

昨日見つけたツールは捌ける数が

max a few hundred at the time

とのことなので、4万通以上のメールが誤操作で更に4倍ほどに膨れ上がった今となっては、とても使えない。なので、エクスポートしたmbox形式のメールアーカイブから、重複メールを取り除くフィルタをRubyで書いた。

#!/usr/bin/ruby
require 'digest/md5'
class Msg
  def initialize
    @str = ''
    @id = nil
    @eoh = nil
  end
  def <<(line)
    @str << line
    unless @id or @eoh
      if line =~ /^$/
        @eoh = true
      elsif line =~ /^Message-ID:\s*(.+)$/i
        @id = $1
      end
    end
  end
  def id
    if @id
      @id
    else
      Digest::MD5.digest(@str)
    end
  end
  def to_s
    @str.dup
  end
end
ids = {}
msg = nil
while line = gets
  if line =~ /^From /
    if msg
      id = msg.id
      unless ids.include?(id)
        ids[id] = true
        print msg
      end
    end
    msg = Msg.new
  end
  msg << line if msg
end
print msg if msg and (not ids.include?(msg.id))

これをmbuniqという名前でパスの通ったところに置いて、実行属性を与えてから

% mbuniq <original mbox file(s)> > <new mbox file>

と実行すると、<original mbox file(s)>から重複メールを取り除いた<new mbox file>ができる。これを適当なMUAでインポートすればOK。

メールの同一性はMessage-IDでが同じかどうかで確認している。Message-IDが見つからない場合は、代わりにハッシュ(MD5)値を用いる。当然ながら、大事なメールはバックアップを取ってから使うべし。

Bloggerってファイルを添付できないのかいな？

Mail.appで過去メールのアップに失敗

同じ過ちを繰り返さないために、失敗の記録を残しておく。

やろうとしたことはこれだけ。

1. mbox形式の過去メールをMail.appにインポート
2. インポートした過去メールをiCloudのメールボックスへ振り分けながら移動

インポートはOK。Mail.appがローカルに作成した適当な名前の新規メールボックスに、問題なく取り込まれた。
失敗したのは振り分け。まずはインポート先の全ての過去メールに現在の振り分けルールを適用したのだが、さすがに40,000通以上を捌くのは骨が折れるようで、全く終わりそうな気配がない。そこで、ただ待っているのもつまらないからと、振り分けルールを編集し始めたのが失敗の元。「ルールを編集する→適用するか聞かれる→はい」を何度も繰り返していたら、振り分けによるiCloudへのコピーが何度も適用されて、かなりの数のメールが重複してしまったのだ。

重複メールを削除するというツールを見つけるには見つけたのだが、何せ物量が半端でない上にインターネット越しのIMAPなので、とんでもなく遅い。なので

1. iCloudの全メールを一旦ローカルに引き揚げ
2. ローカルで重複メールを削除
3. iCloudに再アップ

しようと、まずは全メールのダウンロード中。これまた時間がかかるけれど、今度は余計なことをせず、寝ながら待とう。

MacでKeychainにアクセス

まずKeychainとは、GNOME KeyringのMac版のようなもの。
…と思ったら、KeychainってOS Xより前からあったのか。

え〜、何がやりたいかというと、iCloudとGmailの送信済みメールボックスを自動で同期したい。それにはまず、ログインできないと始まらない。そこで、Keychainが覚えているパスワードを取得しようと考えて、ググってみた。

結論としては、このブログにあるように、securityというコマンドでKeychainにアクセスできる。まだKeychainの概念を把握できていないが、とりあえず

% security -i

でインタラクティブに操作できる。

security> help

で列挙されるコマンド(のうち実害がなさそうなもの)を、とりあえず色々触ってみよう。長いコマンド名は、最後まで入力しなくても大丈夫な模様。

とりあえず

% security find-internet-password -s imap.gmail.com -g

でGmailのパスワードは表示できた。iCloudのはどこだ？

長野なのに短いの

長野の公立高校入試問題の数学が難しくて文句タラタラという話をスラドで読んで、受験から遠ざかって久しい30代のおっさんが、問題の問題を仕事の片手間にチラ見しながら解いてみた。

これでもまあ、一応はエンジニアの端くれ。さすがに中学生向けの問題が分からないことはないが、これを50分で全部答えろと言われると、結構しんどいかな。ただ、簡単な問題をそつなくこなす能力ばかりを測りたいわけではないだろうし…。

結局のところ、入試問題を県内で統一することに無理があるんじゃないか？ どうせ

採点コスト >>>>> 問題作成コスト

なんだろうから、松竹梅の3段階くらいの問題を用意して、高校側に選択させてやれよ。

IMAP移行計画〜振り分けこうしよう編〜

まず結論。
当面はiCloudのメールをMacとpalm(を襲名したiPod touch)からIMAPで閲覧。振り分けはiCloudサーバ側ではなく、MacのMail.appで行なおう。

palmへのプッシュ通知と振り分けの手間を考えたら、現状ではこれが最適解かな。palmで読んだメールをMacで振り分け直すのが面倒だけど。iCloud側の機能が充実するのを待とう。

…機能的にはGmailは素晴らしいのだけれど、ある串を通れないのよね。

出先でiPod touch充電

USBポートが付いてるPCなんてどこにでもあるから、100均のUSB-Dockケーブルがあれば十分だろう。…と思って出掛けたら、意外と困った話。
palm(を襲名したiPod touch)のバッテリーが減ってきたので、いざ充電しようと思ったら…、出来ない!
ケーブルの初期不良? とも思ったけれど、PCがドライバのインストールを要求してきたので、ドライバがないのが原因なのかな? 今までMacとKindle付属のUSB電源のみで充電してきたから気付かなかったけど、PCはドライバがないとバスパワーの要求に応えないのではないかと推測。

勝手にドライバを入れるのはあまりよろしくないが、現にバッテリーは危なくなってきている。さて、どうする？
…と言うところで、結果としてはWiiのUSBポートで充電。
Wii「ディスクリプタ? いいんだよ、こまけぇこたぁ」

IMAP移行計画〜105円が惜しい編〜

@niftyのIMAP。有料会員なら使えて当然だと思っていたら、追加料金が必要なんかい。
過去メールをアップしたら、POPのみに戻そうかなぁ。

IMAP移行計画〜振り分けどうしよう？ 編〜

procmailみたいな振り分けソフトのIMAP版がないかなぁ。ないなぁ。RubyにIMAPのライブラリがあるようだから、書いてみるか？
…そんなことを考えたというだけの話で、実際に手を動かしたわけではない。

IMAP移行計画〜そもそも論編〜

メールをIMAPに移行したくなってきた。
実運用はGmailべったりながらも、フリーメールに100%依存するのはやっぱり怖い。なのでこれまで、@niftyからのPOP受信を併用していたのだけれど、@niftyの改善を知って面倒なPOPをやめたくなったのだ。

とりあえず、2003年から溜め込んできたメールのディスク消費量を見てみると、1.2GB。そのうち630MBがspam。容量的には全く問題無し。

…ところで、そもそもIMAPってどんなもんよ？ これまで真面目に使う気がなかったので、漠然とメールをリモート管理するのためのサーバー＆プロトコルくらいにしか認識してなかった。まあ、これからもコマンドレベルでどうこうすることは無いと思うけど、せっかくだから機能的な面くらいはさらっとなめておこう。

適当にググってみると、肝はサーバー側でメールボックスを管理できることのようだ。メールボックスというのは、言わばメールを置いておくサブディレクトリのようなもの。POPだとサーバー側のメールボックスは1つしか無くて、手元に受信してからローカルのサブディレクトリに振り分けていたのが、IMAPだとサーバー側に振り分けた状態で置いておける。

メールボックスは作ったり消したりリネームしたりできる。要するに、ローカルのディレクトリに対してよく行う基本的な操作はできる。
メールに対しては、読んだり削除したりできるのはもちろんのこと、あるメールボックスから別のメールボックスにコピーすることも出来る。加えて、メールボックスに新規のメールを追加するコマンドもある。過去のメールをサーバーに保存するには、これを使うのだろう。
メールの検索をサーバーにやってもらうコマンドもある。まあ確かに、検索の度にメールをダウンロードする仕様だったら、結局ローカルにキャッシュしてしまいそうだしね。

ところで、大事な機能が見当たらない。そう、メールの振り分け機能はIMAPの領分ではないようだ。好きなように整理整頓可能な書庫は提供するけど、どう整理するかを考える司書は適当に調達してくれ、ということか。

@niftyのメールが進化していた

iCloudへの転送設定をするために久々に@niftyのWebメールにログインしたときに、@niftyメールの基本仕様を読んで知ったこと。

メールボックス容量5GB/保存期間無期限で一生使い続けることのできる充実のメールサービス

保存期間無期限！ 昔は2週間だった。…と言うか、今日の今日まで2週間のつもりで、転送先のGmailをメインに使いながらも、@niftyからもPOPでこまめにローカルに保存してたヨ。
@niftyとGmailとiCloud。3つもコピーがあれば、もうローカルに取っておかなくてもいい気がしてきた。

今日は何の日？ πの日

スラドで読んだのだが、今日はπの日だそうな。ホワイトデーを本気で忘れてたことは置いといて、スラドのストーリーの本題は「πではなくτを使おうぜ」とのこと。
定義はズバリ

τ = 2π

ぐるっと1周で2πと言うより、1周で1τの方がいいでしょ。

…と言われても。πをτ/2に置き換えるだけなら、別に既存の定義と矛盾するものではないけど、もうπになじんでしまっているからな〜。

e^iτ/2 + 1 = 0

1/2がダセェ。

e^iτ - 1 = 0

角度は違うけど、こっちの方が綺麗か。

Subversionで作業コピー中のディレクトリのリネーム

チェックアウトした作業ディレクトリの中に、新たなSVN管理下のディレクトリfooを作る。

% svn mkdir foo
% svn commit -m ‘made foo’

次に、新たなディレクトリfooの中に新たなファイルをfoo.txt追加する。

% echo foo > foo/foo.txt
% svn add foo/foo.txt
% svn commit -m created foo.txt’

この状態で、作業コピーの中のfooをbarにリネーム。

% svn mv foo bar

そして、このリネームをコミットしようとすると…

% svn commit -m renamed
svn: Commit failed (details follow):
svn: Directory ‘xx/foo’ is out of date

怒られる。怒られてコミットできない。

結論から言うと、mvする前にupdateしておけば怒られない。
まず、コミットできなかったリネームは無かったことにしてから、アップデート。

% svn revert -R foo bar
% rm -fr bar
% svn update

それから再びリネーム。

% svn mv foo bar
% svn commit -m renamed

今度は通る。

要するに、何となくupdateしたら何とかなったのだけれど、そもそも駄目だった訳を理解していない。mvではなくcpなら問題は起こらないので、移動元の指定がおかしいことは無いと思うんだが…。
とりあえず対処療法的にupdateするか、mvするときはレポジトリのURLを指定しよう。

エイリアス小ネタ

今日の日付を出力するだけのエイリアス。

% alias today='date +%y%m%d'
% alias Today='date +%Y%m%d'

大したものではないけれど、ちょっとしたファイルやディレクトリの名前に、日付を入れたいときに便利。

% mkdir `today`
% tar zcvf backup-`Today`.tar.gz target

まあ、きちんとバージョン管理した方が良いのは、言うまでもない。

あれから1年

なんだか、無力感に振り回されていた1年だったような気がする。
天災は言わずもがな。その後の大人災どころか、弱小企業の中の下らない社内政治ですら、どうにもならない。はぁ〜。

で、結局悟ったことは、自分の力でどうにか出来るかどうかと、自分がどうにかしたいと望んでいるかどうかを意識すると、割と生きやすいということ。
本当にどうにも出来ないことに対して心をすり減らしても、何の解決にもならない。また、抱えている問題が本当に自分自身に取って大事なことなのか、胸に手を当てて考えてみると、意外とどうでもいい場合が多い。そんなこんなは、適当にスルーしてしまうのが心身の健康のためだ。

限りある金・暇・情熱は、自分が望むことを実現するため、実現する力を身に付けるために費やそう。

Spirit of Zen

チラシの裏。
もう、いくら待っても新しいPalmは出ない現実を認めて、とうとうiPod touchを購入。10年くらい連れ添ったPalmにも、ついに退役の時が来た。

新しいiPod touchにはpalmと命名。禅の精神を引き継ぐには、ちと華美な気もするけど。

extended attributeって何だ？

ls -lしたときに表示されることがある@。何となく気になっていたので、いい加減lsのmanを見てみた。

If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a '@' character.

extended attributeって何だ？ 振り向かないことさ。
…いや、違う。ググってみると、rwxやタイムスタンプのような定型の属性ではない、言わば定形外の属性らしい。ほぼ任意の名前と値のペアを保持できる、と。機能的には、1つ1つのファイルに専用DBを付けられるような感じか。もちろん、ファイルシステム自身はextended attributeを見てどうこうすることはないそうだ。

さて、早速ls -l@hしてみると、何やら数十バイト程度の情報が付いているファイルが結構ある。しかも、ls -lでは0バイトのファイルに付いてたりもする。0バイトと言いながら、実はディスクを消費してることもあるのか。

消費電力を測定してみた〜器用貧乏編〜

日常的に使用している汎用の計算機の消費電力を測定。

自作機(Athlon X2 4850e, AMD780G+SB700, メモリ6GB)
旧メイン機、OSは64ビットのUbuntu 10.4。
電源オフ状態で3.8W。電源オンでアイドル時は51W。stressコマンドでCPUに最大負荷をかけたときのピークが109W。待機電力が意外と高かったのがプチショック。

Mac mini (Mid 2011, 2.3GHz, メモリ8GB換装済み)
現メイン機、OSはLion。
まず、電源オフ状態だと0.0W。電源オンでスリープ状態だと1.1〜1.2W。自作機の待機電力より、Mac miniのスリープの方が省電力なのか。
電源オンでアイドル時は10W。stressコマンドでCPUをいじめながら、半透明のウィンドウを手動でガチャガチャ動かしたときのピークが38.9W。まあ、よほど人為的に負荷をかけない限り、20Wを超えることすらなかなかない。

Dell Inspiron 11z(最小構成)
2009年秋のCULVノート、測定時のOSは64ビットのWIndows7。
ACアダプタのみだと、さすがに0.0W。そこに電源オフの本体を接続すると、充電ランプが消灯した状態で0.5W。まあ、普段はコンセントに繋いでいないから、気にしない。
電源オンだとアイドル時が10W、ピークが17.1W。ピークは低いのは遅さ故か。

液晶モニタ Dell ST2420L
24インチ、1920x1080、LEDバックライト。
電源オフ状態では0.0W〜0.3W。電源オンでスリープ中だと0.3〜0.4W。たまに電源を落とし忘れるけれど、まあ気にするほどでもなかったのか。
電源オンでHDMI(1080P+オーディオ)のソースを表示中は19.7W。まずまず優秀かな。

消費電力を測定してみた〜電脳遊戯編〜

今回の測定対象はWii。発売日に飛びついたので、完全な初期型。…だったのだが、2011年6月に修理に出したら、セーブデータをコピーされた別個体が返ってきたので、内部的にはかなり新しいバージョンだと思われる。

まず、電源オフ時(赤ランプ)の待機電力は0.8〜0.9W。Bluetoothの待ち受け分かな。スタンバイ中のWiiConnect24を有効にした場合の電源オフ(オレンジランプ)では5.3〜5.4W。初期型は結構、オレンジランプだと側面が暖かくなっていたのだが、ここはかなり改善された模様。

電源オン時の消費電力は、ソフトによってまちまち。ディスクを挿入せずWiiメニューを表示しているだけだと11.9Wだが、ディスクを挿入した状態のWiiメニューは12.0〜12.9W。消費電力がふらついて安定しないわけではなく、この範囲内の値にほぼ収束する。光ディスクドライブの制御はよく知らないけど、最後に読み出したときの回転速度を保つようになっていて、その速度によって値がばらついたりするのだろうか？
さて、ようやくゲームプレイ中の話。ディスク媒体のどうぶつの森は、非ロード中が安定して12.9W、ロード中のピークが13.2W。ディスクレスの魂斗羅ReBirthだと、10.7〜10.8W。2Dとはいえ、見た目はド派手な魂斗羅が、ディスク無しWiiメニューより省エネとは。

おまけ。GC互換機能使用中も測定してみた。ソフトは、再販記念ガチャフォース。繰り返そう、(例のメロディーに乗せて)♪さーいーはーんーきーねんー、ガチャフォース！

結果は非ロード中が9.9〜10.0W、ロード中のピークが10.4W。さすがにWiiネイティブのソフトより低かった。

もうひとつおまけのコンポジット-HDMIコンバータ。動作モードはコンポジット入力、映像は1080P出力、音声もHDMI出力。
結果は、入力が無い(NoSignalと映像のみ出力している)とき5.0〜5.1W。入力変換中は5.4〜5.5W。ついでに、変換はしているが絵がほとんど真っ黒なとき5.0〜5.1W。HDMIトランスミッタが常時5W近く食らってるのかな。
ちなみにこの製品、HDMI出力の音が悪い。高音が割れる。しかも、HDMI音声出力中はAMラジオにかなりノイズが乗る。オーディオをアナログのままスルーする機能を使えば、音は悪くならずノイズも無いので、どうしてもスピーカを集約したいのでなければ、映像のみの変換器として割り切った方がいいかも。

ワットモニター TAP-TST8 レビュー

ワットモニター TAP-TST8を、ここ数日おもちゃにした感想など。

まずは、基本的な機能のおさらい。

• 消費電力測定
• 1秒毎にサンプリングした消費電力[W]
• 測定開始からの積算電力量[kWh]
• 測定開始からの経過時間[hh:mm]
• 電気料金換算
• 測定開始からの累積電気料金[円]
• 1日あたりの電気料金[円/日]
• CO2排出量換算
• 測定開始からの累積排出量[kg]
• 1日あたりの排出量[kg/日]

意外にも、累積値は不揮発。ワットモニター自身をコンセントから外しても、それまでの累積値は記憶されている。いい加減な接続で測り始めたらコンセント周りが邪魔くさくて仕方ないけど、これまでの記録が惜しくて外すに外せない、なんてことは避けられる。その代わり、測り始めに手動で累積値のリセット操作が必要だけど。
秒単位で変化する値の記録にフラッシュメモリは使っていないと思うけど、でかいコンデンサでも積んでいるのだろうか？ 1日放置した程度では忘れない。

ちなみに、覚えておいてくれるのは累積値だけ。ピーク値とか、過去n分の履歴とかは無し。消費電力の推移を見るには定点監視カメラが欲しい。実際、炊飯器の記録には3DSのインターバル撮影機能を用いた。

料金とCO₂排出量は、電力に何かしらの定数を掛けてるだけでしょ。大体、311以前の値なんて当てにならないだろうし。…と、購入前は思っていたけれど、これらの係数は調整可能。

積算電力は0.01kWhが最小単位。これはせめて、もう1つ下の桁まで対応して欲しかった。内部的にはもっと精度が高いんじゃないの？

オス、メスともにプラグの位置は悪くないけれど、オスのプラグは出っ張ったまま。よくある充電機のように引っ込むようにして欲しかった。非常に片付けづらい。

総合的に見て、まあ買って損は無かったかな。元々、契約アンペア数見直しのために買ったのだけれど、基本料金を下げられそう＆結構遊べたので。

消費電力を測定してみた〜Rice is beautiful編〜

今度は炊飯だ！

炊飯器 象印 NS-NB05
白米を3カップ炊いた際の消費電力を測定。炊飯終了まで1分毎にチェックした。結果は以下の通り。

280Wという表記に対してピークは372W、これは要注意だ。積算消費電力は0.13kWhだったので、平均は約150W。
ブラックボックスだった炊飯器の火加減を可視化できたのは、ちょっと面白い。

消費電力を測定してみた〜爆熱地獄編〜

ワットモニターを購入。まずは消費電力が高そうな電熱モノを測ってみた。

アイロン Panasonic NI-S33
1000Wという表記に対して、最高温度設定で実測のピーク電力は990W。ただし、十分に暖まると0.0Wに下がる。アイロンは今でも、昔ながらのバイメタル制御なのか？
ユースケースの平均電力も知りたいので、同設定で1週間分のシャツにアイロンをかけてみた。結果、48分間で0.28kWh、平均350W。意外と休んでいる時間が長いのね。

続・ERBを使おう

汎用のテンプレートエンジンであるerb。そのままでも十分便利なのだけれど、この機能はRubyの標準ライブラリERBとして切り出されており、ちょっとした自前のRubyスクリプトの中でも使えるのだ。

require 'erb'
Template = <<END
foo is "<%=foo%>".
END
foo = 'foo1'
erb = ERB.new(Template, nil, '%')
erb.run

これを実行すると、

foo is "foo1".

と表示される。
ERB.newの第2匹数はsafe_level、第3引数はtrim_mode。デフォルトのtrim_modeでは行頭の%が効かないので注意。実は第4引数もあるが、まずデフォルトでOK。
runにも実は1つ引数があり、bindingを渡すことができる。デフォルトはTOPLEVEL_BINDING。定義したはずの変数がテンプレートの中で参照できないときは、bindingを疑おう。

def override_foo
  foo = 'foo2'
  binding
end
erb.run(override_foo)

この例だと、テンプレートの中からはoverride_foo内のfoo、すなわちfoo2が見える。一方、

def not_override_foo(erb)
  foo = 'foo3'
  erb.run
end
not_override_foo(erb)

この例だと、テンプレートの中からはnot_override_fooの中のfoo3ではなく、トップレベルのfoo1が見える。

ERBを使おう

eRubyとは、乱暴に言えばPHPのRuby版みたいなもの。道なりにRubyをインストールしていれば、eRubyの一実装であるerbというコマンドが既にインストールされている場合が多い(Debian系は別パッケージだったかも)。
さて、PHPに例えておいてなんだが、erbは決してHTML専用ジェネレータではなく、汎用テンプレートエンジンなのだ。単調な記述を繰り返さねばならないとき、ささっと使うと非常に便利。
例えばVerilogの6ビットのアドレスデコーダを記述すると、こんな感じ。

% 64.times do |a|
assign w_dec_addr[<%=a%>] = (w_addr[5:0] == 6'd<%=a%>);
% end

これをerbに食わせるとこうなる。

assign w_dec_addr[0] = (w_addr[5:0] == 6'd0);
assign w_dec_addr[1] = (w_addr[5:0] == 6'd1);
(中略)
assign w_dec_addr[62] = (w_addr[5:0] == 6'd62);
assign w_dec_addr[63] = (w_addr[5:0] == 6'd63);

FPGAならgenerate forとか使って気軽に冒険できるけど、どこでも確実に合成できるようにしようと思うと、ベタ書きになっちゃうのよね。

erbは引数にファイル名を与えなければフィルタとして動作するので、Vimのvisual modeと非常に相性が良い。編集中のファイルにeRubyのコードを混ぜ込み、vで範囲指定した状態で

:'<,'>!erb

と実行すれば、選択した行のみerbに通すことが出来る。失敗してもuでアンドゥできるので、ガンガン試してみよう。

Googleの新プライバシーポリシーについて

今回は完全にチラシの裏。
最近、方々でブーブー言われているGoogleの新プライバシーが、とうとう適用開始された。だからと言って、特別なことをするつもりは無い。だってね、信用してますよ、Googleさん。少なくとも、今いる会社の駄目幹部とか、今いる国の駄目年金とかよりはずっと。
ただし、これからもエロ絡みの検索はYahoo!でする予定。

Vimのバッファの状態

Vimを日常的に使っている割に、まじめに把握してなかったシリーズ(?)第2弾。Vimのバッファについて、helpを読んでみた。
バッファには3つの状態がある。

1. ウィンドウに表示しながら編集中(active)
2. 非表示だが編集内容は保持中(hidden)
3. 編集を終えた(inactive)

普通に編集しているファイルはactive。これはまあ、特に意識せずとも使っている。
編集を終えて閉じたファイルはinactive。これもまた、特に意識するものではない。あるファイルを表示しているウィンドウを全て閉じても、そのバッファ自体が消滅するのではなく、inactiveで残っているわけだ。最もメモリは解放するようなので、残っていても特に害はない。
あまり使いこなしていないのがhidden。まだディスクに保存はしたくないが狭い端末を分割したくないとき、hiddenにすれば編集中のまま他のファイル(バッファ)を編集できる。カレントウィンドウで表示中のバッファは

:hid

でhiddenにできる。また、:hidの引数に他のコマンドを与えれば、カレントバッファをhiddenにしながらそのコマンドを実行できる。例えば

:hid e foo.txt

でカレントバッファhiddenにして、代わりにfoo.txtのバッファをカレントウィンドウに表示する。