にょろ、

Rails 4の特集と、Ruby 2の特集が一度に読めるというので久しぶりに読んでみたところ、評判通りだった。

「Rails 4に移行するために必要なこと」を概観できるのを期待して「詳解Rails 4」を読み始めた。だが、読み進めていくと「こんなふうに書くためにはどう移行の話をつけるといいかなあ」てなことを考え始めていた。

「Ruby 2.0最速入門」は「るびま」の記事をより詳しくしたような内容。Rails 4がRuby 2.0を推奨していることを考えれば「詳解Rails 4」と合わせて読みたい。

RailsやRubyに興味がある人にはもちろんのことだが、Railsを「使わなきゃならない」人々にこそお推めな記事ではないかと思う。

(自分のTumblrから転載; 置き場所を迷い中)

小さな修正とRuby 2.0.0での(簡単な)動作確認をして前にバージョンを1.0.0にした。あとライセンスを変えた。(Ruby 1.9.3〜に合わせた。)

• ダウンロード

(自分のTumblrから転載・加筆; 置き場所を迷い中)

久しぶりに技術系の雑誌を読んだ。(拾い読みだけど。)

WEB+DB PRESS Vol.72の特別企画「XP再入門」は、古典といっていいのかどうか分からないけど「エクストリーム・プログラミング入門」を、長年のXP実践者である筆書の規世やよいさんが業務を振り返りながら読みなおすという内容。

XP、あるいはアジャイルとはどういう考え方なのかというのを再確認するとともに、「本」の中身は実社会にいかにフィットさせてきたかという実例を示し、さらにそこで行われたカスタマイズをその「本」を通して見つめなおすことにより「エクストリーム・プログラミング入門」が何を述べているのかを煮つめていく。私自身はXPの実践者ではないけれど、それだけに事例の一つに触れられるという点で興味深かったし、なにより読み物として単純に面白かった。 同様の企画をぜひまたやってほしい。

(自分のTumblrから転載; 置き場所を迷い中)

仕事が少し落ち着いてきて、それも良いんだか悪いんだかというところでもあるのだけど、ともかくようやく外出できるようになってぼちぼちと出掛けてみている。話に聞いた寒川神社あたりの桜というのを眺めに行ってみた。

あいにくの雲り空に、ピンクはともかく緑が映えなくてならないが、川辺にあった黄色の発色はぐっときた。

せっかくなのでその道中のトンカツやさんで昼食をとった。平日ランチ、あさりの実がちゃんと入った味噌汁がついて880円はなかなかお得な値段だと思う。

入口のある一階は煙もくもくで白くもやがかっているほど。入ってすぐに、これは食事できる程度をぶっちぎっているなと思ったが、座敷になっていてわりと広めの二階が全面禁煙だった。

今回の引っ越しでは、当初、同じ横浜市内での移動を考えていた。もっというと直線距離で数km程度の範囲を考えていたのだった。ところがいざ探してみると厳し現実と向き合うことになった。……近所では、難しい、と。

そんなわけで範囲を横浜の山側、それから湘南へと広げていった。どちらも訪れたことのないエリアなので、それぞれに歩いてみて絞り込むことにした。ただ見てまわるだけで済ませるのももったいないし、やはり近所にカフェの一つくらいは欲しい。時間をちょっと割いてあちらこちらのカフェに立ち寄ってみた。

三ツ境のYaJI&KITa CaFEは紅茶のおいしいお店で、値段的にもリーズナブル。いっしょにたのんだチーズケーキやスコーンもおいしくて、三ツ境に引っ越していたら通っていたのではないかと思う。今後、三ツ境に行くことはそうそうないと思うのだけど、もしも行ったらぜひともまた立ち寄りたい。

センター北のSONJINはホットケーキで有名なお店。ここもなかなか用事のないエリアなのでこんなときでもなければ行かないだろうし、一度くらいは見てみたいということで行ってみた。ちょうどにぎやかでした。

辻堂ではOMOTE COFFEEとlama coffee、それから27 coffee roastersに立ち寄った。27 coffee roastersは店名からも分かる通り、コーヒー豆の販売がどちらかというとメイン。ただし、店内でコーヒーなどを飲むこともできるし、コーヒー豆を買うとお試しコーヒーのサービスがある。(少なくともこのときはあった。) お試しといってもきちんとその場でいれてもらえるもので、しかもこれがうまかった。湘南に引っ越すことになったら行くぞーと思っていたのだが、はちゃめちゃな忙しさのせいでまだ行くことができていない。でも、ぼちぼち行こうと思っている。

あとの二つはどちらも小さなカフェで、コーヒーもおいしかったけどケーキがおいしかった。二店ともまた行くつもり。

茅ヶ崎の黒糖茶房はコーヒー、紅茶というのではなく黒糖がメインのお店。販売もしていて、店頭には黒糖がごろごろと。とはいえカフェメニューもいろいろとあるし、店内はおおむねカフェスペースなので人の出入りがあって落ちつかないというようなこともないと思う。ここもおいしかった。

山賊ダイアリーというまんが。これがすごい。ウサギ、ハト、カラス、イノシシ、シカ、ヒヨドリ。こういった動物が獲物。空気銃や罠を使って狩る。

食べるところまで描かれるが、広い意味での食糧調達の手段として。教育的とかそういう切り口ではなくて、ずっと続く日常の一部としての猟を題材としている。経験のある範囲でいうと魚釣りのような。銃を竿に、獣を魚に、それぞれ置き換えると作者のこの作品における立ち位置に近付けると思う。(作中では釣りもしているし、蜂をとったりもしている。) カラスの駆除を依頼されることがあるなど、現代の猟師のいろんな面が見られるのも面白い。

獲物のさばき方や調理方法にもページが割かれていて、これが実にうまそう。作者自身の経験に基づく「日記」とのこと。もろもろ含めてそういう生活にはちょっと憧れる。いや、怪我とかプチ遭難とかもしてて楽しいばかりではなさそうだけど。

(自分のTumblrから転載; 置き場所を迷い中)

ひさしぶりにキャラメルトを買った。特徴的な口あたりは変わりなく、コーヒーによく合う。

今は味のバリエーションがいくつかある。普通のとチョコ味を購入。今日のは普通の。

今回はこちらから。

前回はＣafe de Ｐouから。

引っ越しました。

どうにも部屋の広さが足りなくなったため。

私は学校を卒業して関東に移ってきたのだけど、その最初に住んだのが横浜市緑区だった。会社の寮がその当時あった。その寮を出て、短い期間、埼玉、東京に住んだことがあり、また、数年ほど松江に住んだ。そしてまた関東に戻って住んだのがやっぱり横浜だった。

横浜に住みたかったというようなことはまったくなかった。というか地方の外れの者にとって東京はまだしも横浜っていうのは意識に上ってくることがなくて、移ってきて初めて認識したようなところだった。だが、なんとなくそういう感じで気付けば地元以外で最も長く住んだ地域となった。地域に愛着的なものを感じたのも横浜が初めて。

当初は横浜市内で小さく移動するつもりだった。が、やっぱり横浜は高かった。まる一か月と少しかけて横浜市内をめぐったりもしたが、部屋を広くしようとするといろいろ無理が出てくる。それならいっそと土地勘もない湘南まで範囲を広げて、その結果、茅ヶ崎でいいところが見付かった。

決まるときはあっさり決まる。とはいってもあっちが〜こっちが〜と悩みはしたが、あの横浜めぐりはなんだったのかとちょっと思ったりもした。ただ、めぐっている中でいいカフェに立ち寄れたりもした。こんなことでもなければ行けないお店でもあったので、ま、あれはあれでよかったんだろう。(というか、近かったら通うのにーっていうカフェとかパン屋とかあったんだけど。横浜に住んでいてさえ行きにくいところが引っ越してほとんど行けそうになくなったのだった。)

そういうわけで、私にとっては新たな街、茅ヶ崎には先月末に引っ越してきた。まだ箱が積み上がっているっていう意外にもいろいろあって実は今だに引っ越し作業を引きずっている。それでも部屋が広くなるとなんとなくゆとりが出てくるのか、ピークが重なってしまった仕事が大変なことになっているなか、以前とは違った気分で過ごしている。

仕事がそんな具合いなので茅ヶ崎の街をみてまわるどころか、近所をひとまわりというのすらまだできていない。それでも、所変わればというものなのか、横浜よりもゆるい雰囲気があるような気はしている。都内から横浜に帰ってくるとホッとしていたものだが、それよりもなお。仕事をなんとか乗りきるころには気候もゆるんできているだろうから、またあちこちまわってみたい。コーヒー屋さんとかカフェとか。鎌倉とか寒川とかにも足をのばしてみたいな。

(Hack Cafeやるぞーとかって言ってたんですけど、ごめんなさい。)

先日、iMacを修正した。症状は表示の異常で、ディスプレイ一面、ドット柄になってしまった。

修理内容はビデオカードの交換であった。修理内容を記した書類に、この部品は熱を持ちやすいのでうんぬんとのコメント。何かで覆って使っているわけでもないし、部品を変えるわけにもいかない。でも熱が原因ならまた起こるかもしれない。

なんとかならないかなと少し検索したところiMac Fan Controlというのがよく使われているようだ。さっそくインストールし、ファンの回転数をやや高めに設定した。ビデオカードの温度はインストール前と比べて10度近く下がったところで安定しているようである。

だが、温度は使用状況によって大きく変わる。継続的なモニタリングと調整が必要になる。(次の春から夏にかけて、忘れたころに、という心配がある。)

そういったツールがないものかと探してみたのだが……どうやら有償のものばかり。有償でもいいのだが、どうもオーバースペックというかなんというか。裏裏でそっと動いていてくれれば十分なのに、という印象。

どうしたものかなと考えていたところ、iMac Fan Controlにsmcというコマンドが付属しているのに気付いた。

$ ./smc -h
Apple System Management Control (SMC) tool 0.01
Usage:
./smc [options]
    -f         : fan info decoded
    -h         : help
    -k <key>   : key to manipulate
    -l         : list all keys and values
    -r         : read the value of a key
    -w <value> : write the specified value to a key
    -v         : version

実行すると、ファンの回転数を調べられるのが分かった。

$ ./smc -f
Total fans in system: 3

Fan #0:
    Actual speed : 2801
    Minimum speed: 2800
    Maximum speed: 3800
    Safe speed   : 0
    Target speed : 2800
    Mode         : auto

[...]

また、その他のセンサーから値を取ることもできる。たとえばCPU温度は「TC0H」というキーで読み取れるらしい。そこでそのように実行してみる。

$ ./smc -r -k TC0H
TC0H  [sp78]  (bytes 2a 40)

このときのCPU温度はシステム設定上の表示によれば42.1℃であった。上のコマンド実行を繰り返すと「bytes」の部分が変わることから、何かしら読み取れているのはたしか。そして、システム設定の表示は、このようにして読み取られた内容に基いているはずだ。

ところでiMac Fan Controlの配布物(iMacFanControl1.2.dmg)には、ソースコードが含まれている。それならシステム設定の表示をしているところで何をしているか調べればよさそうだ。「sp78」や「temperature」をキーにして検索する。「2a 40」のような生の読み取り値を「温度」に変換しているのはどうやらsmc.cにあるSMCGetTemperatureらしい。具体的には以下の部分である。

1
2
3
4
5
6
7
8

// read succeeded - check returned value
        if (val.dataSize > 0) {
            if (strcmp(val.dataType, DATATYPE_SP78) == 0) {
                // convert fp78 value to temperature
                int intValue = (val.bytes[0] * 256 + val.bytes[1]) >> 2;
                return intValue / 64.0;
            }
        }

val.bytes[0]とval.bytes[1]には読み取った値、つまり上の実行例なら「2a」と「40」が入っている。それら二つの読み取り値を、一つめ→二つめの順にくっつける。くっつけたものを2ビット右にシフトする。最後に64で割る。これが温度に変換した結果となる、はずだ。実はナナメ読みしかしていないが、おそらくそうだ。(val.bytesあたりのことはsmcのソースコードにもあたるとだいたいそんな感じだろうと分かる。)

実際、どういう変換結果になるかやってみる。ここではRubyを使う。

$ ruby -e 'p ((0x2a*256 + 0x40)>>2)/64.0'
42.25

システム設定で表示されていた「42.1度」とは少しズレがあるが、それらしい結果のように思える。

読み取りのタイミングにズレがあるはずなので、そのあたりを含めて、システム設定の表示と見比べながら何度か繰り返し実行してみたい。だが上のように毎度数式を書いていたのでは間に合わない。そこで次のようにしてみる。

$ ./smc -r -k TC0H | ruby -pe '
  $_.sub!(/(\[sp78\]  \(bytes (..) (..)\))/) {
    $1 + " %4.1f"%(([$2, $3].pack("H2H2").unpack("n").first>>2)/64.0)
  }
'
  TC0H  [sp78]  (bytes 2a 40) 42.2

ちょっと長くなってしまったが、smcの出力に温度を付け加えている。smc.hによれば、CPU温度はTC0H、HDD温度はTm0P、DVD温度はTO0P、GPU温度はTG0Hとなっている。次のようにすれば他の温度もまとめて変換して表示させられる。

$ (for k in TC0H Tm0P TO0P TG0H; do ./smc -r -k $k; done) | \
  ruby -pe '$_.sub!(/(\[sp78\]  \(bytes (..) (..)\))/) { $1 + " %4.1f"%(([$2, $3].pack("H2H2").unpack("n").first>>2)/64.0) }'     
  TC0H  [sp78]  (bytes 2a a0) 42.6
  Tm0P  [sp78]  (bytes 2f e0) 47.9
  TO0P  [sp78]  (bytes 2d e0) 45.9
  TG0H  [sp78]  (bytes 34 80) 52.5

なお、HDD温度のTm0Pについて以下を参照のこと。Tm0Pはメモリコントローラの温度ではないかという話もあるようで、正確なところはよく分からない。

• iMac Fan Controlでinternal HDが0.0℃と表示される場合の対処法 - TH0PをTm0Pに書き換えて回避する
• MacRumors - iMac Fan Control - Mar 4, 2012, 06:16 PM #71 - バイナリエディタでTH0PをTm0Pに書き換えている
• MacRumors - iMac Fan Control - May 20, 2011, 05:28 PM #1 - Tm0PではなくTLCVにしている
• TFMonitor - Tm0Pはメモリコントローラの温度ではないか

ふと思いついて、作業用のPCの環境をDebian stable(squeeze)からtesting(wheezy)に更新した。uimのバージョンが古いのがちょっと辛くなってきたなと、最近そう思うようになったのもあるが、やはりなんとなくの思いつき。

ともかくaptitude dist-upgradeだと始めた。が、さすがはtesting。パッケージの依存関係の整理がつかず、うまく実行できなかった。そこで特に問題になっていそうなパッケージをねらって更新しようしたところ、これまた失敗。いくつかのパッケージが中途半端な状態になってしまった。

仕方ないのでapt-get dist-upgradeでできるところからパッケージを更新することにした。十いくつかのパッケージが削除されてしまうが、また必要になったときにインストールし直せばいいだろうと思うことにして無視。そのまま進めた。

経過を見守ることしばし。意外と順調に進んでいるなと思っていた。しかし、エラーが発生してあえなく中断。調整して再トライしようとしたのだが、なんと、sudoパッケージの更新が途中止めになっていた。/etc/sudoersが退避されていて、sudoが使えないという。なんてこった!

……というほどのこともなく。実は、この環境は作業するときにだけ使うものであるため、普通にsu rootできるようにしており困ったことにはならなかった。もちろん、久しぶりの大更新であったとはいえ、rootシェルをキープしておかなかったのはうかつだったが。

そんなこんなでdist-upgradeを完了した。二、三のトラブルはあったものの、予想外にすんなりアップグレードできた。

パッケージ更新はうまくいったものの、数か月もリブートしていないマシンである。kernelが大きく変わっているわけで、毎度のことながら果たして再起動してきてくれるであろうかと思いつつshutdownをかける。

ドキドキしながら見守っていたところgrubの起動からLinuxの起動へとスムーズに進行する。ほっとしたところで、そうだったと思い出すのがfsck。ああ、そうだなあ、と思いつつ、fsckが終わるのを待った。妙に遅いディスクを使っている関係で、たいした容量でもないのだけど30分かそこらかかった。

次に危惧していたのが果たしてXは立ち上がるだろうかということ。こちらは、残念ながら立ち上がってくれなかった。というのもRADEONドライバが失われていたためで、これはある程度事前にわかっていた。

これまでfglrx-driverパッケージを使っていたのだが、同パッケージ(のupstream)の更新により古いATIカードがサポートされなくなったそうだ。パッケージ更新中にもそのことは検知されていて、xserver-xorg-video-radeonパッケージのドライバを使えと通知があった。そこでその通りにした。

が、これがうまくいかない。Xが起動しないわけではないのだが、アクセラレーションが有効にならず、ログイン時にGNOME Shellが実行できないと言われる。

GNOME Shellでなければならないということもないが、ダメと言われると一応はがんばってみたくなる。そこであれこれ調べてみたところfglrx-legacy-driverが用意されていることがわかった。そこで同パッケージをインストールしたところ、無事にGNOMEが起動するようになった。(fglrx-legacy-driverは現時点ではexperimentalにしかない。)

さてそのGNOME Shell。実のところ名前を聞いたことがある程度にしか知らず、立ち上がってきたはいいものの、はてどう使えばいいのやら。「アクティビティ」をクリックすればアプリケーションランチャが現れることは分かったが、いかにもまどろっこしい。

調べずにtwitterでつぶやいたところwindowsキーでいけると教えてもらえた。そこからたぐってGNOME Shell CheatSheetを発見し、最低限必要なキーバインドは分かった。(まずはAlt-F1とAlt-F2。)

ちょっと困ったのがウィンドウフォーカの移動で、Alt-Tabによる切り替えの際に、どのウィンドウが選択されるのかがわかるようなスタイルにならない。作業中には端末を複数起動するのが常である。そのためAlt-Tabで表示されるアプリケーションのリストには同じアイコンがずらっと並ぶばかり。いったいどれがどの場所にある=どの用途のためのウィンドウかの見分けがつかない。

そこで、ウィンドウタイトルに実行したコマンドやカレントディレクトリが表示されるようにすることにした。これにはおすすめzsh設定をほぼそのまま使わせてもらった。ここでの目的に限定するならオーバースペックでもあるが、この種の設定はよく吟味、メンテナンスされている設定集を使わせてもらうのが一番。この機会に設定を変更することにした。

また、GNOME Shellでは同じプログラムの間でだけウィンドウ切り替えができるようになったことを前掲のGNOME Shell CheatSheetで知った。これは結構便利なはずなのだが、今まで使っていたrxvtではうまく動かず、それぞれ別のグループに分かれてしまう。そこでrxvtを止め、gnome-terminalに移行した。これによりAlt-`でgnome-terminal間だけでの切り替えができるようになった。

ウィンドウ切り替えに関連では、ワークスペースをまたいだウィンドウ切り替えが可能になったのもよい。ここしばらくはMac上で作業することが多かったため、これが可能になったのはうれしい。

と、プログラミング作業以外はあまりしない環境であるため、このあたりでひと段落。

ざっと見たところ、このアップグレード(GNOME Shellへの移行)によってデスクトップ環境としてかなり使いやすそうな状態になったと感じている。もう少し使ってみないとなんとも言えないのかもしれない。だが、それほど使いこむ環境でもないので、今後使っていても印象はそう変わらないのではないかと思っている。(従来のGNOMEをさほど使いこんでいなかったおかげで違和感が小さいためで、そうでない人にとってはGNOME Shellが使いにくいのかもしれない。また、初見で戸惑ったのもたしかである。)

今回、rxvtを止めてgnome-terminalにしたことでビットマップフォントを使わなくなった。これは自分としては大きな変化で、数年前なら考えられないことだった。(その頃にはその頃の事情もあったのだが。) だが、これはこれで悪くない。思っていたよりなんとかなりそうだ。一部の記号幅の問題がちょっと気になってはいるので、そのあたりでさらに別の端末に乗り換えが必要になるかもしれないが、もう少し様子をみよう。

まぎらわしい文字に悩まされないフォントを求めていくつかのフォントを比較してみた。

• へべぺ(ひらがな)ヘベペ(カタカナ)
• 二(漢字)ニ(カタカナ)、口(くち)ロ(ろ)
• 一(漢字)ー(音引き)―(ダーシ)－(全角ハイフン)-(半角ハイフン)
• 1lI|(半角)１ｌＩ｜(全角)

比較したのはIPAフォント、VLゴシック、Ricty、OS XのOsaka、タイプラボのセプテンバー、アニト、ニタラゴルイカ(それぞれ無料お試し版)。

用途を限定しているRictyは判別のためにいくつかの字形を変えていることがわかった。漢字の「二」も「一」と同じようになっているとさらによさそう。

IPA明朝は漢字・カタカナ・記号を判別しやすいが、解像度が十分に高くないと辛い。あとASCII文字の字形にどうしてもなじめない。その点で言うとセプテンバーがなかなかよさそう。ただしこれは有償フォント。

「へ」のひらがな・カタカナの判別は難しい。慣れるしかないか。

なお、ここでの比較はプログラミングと、日本語で長めの文章を書くことを主な用途して行った(つもり)。そのため等幅は必須。フォントとしてきれいであるにこしたことはないが、判別しやすさの優先度のほうが高い。他にもいろいろなフォントがあるのだろうけど探すのが意外と難しい。有償フォントを含めると単純な数もかなりのものになりそう。というわけでおすすめのフォントがあったら教えてください。

OS X Lionにしたときにもひとしきり悩んだのに、Mountain Lionにしたらまた悩んでしまったので自分用のメモ。

• Xcodeの設定のDownloadsからCommand Line Toolsをインストールする
• brew updateする(必要に応じて)
• brew tap homebrew/dupesする(一度だけやっておく)
• brew install apple-gcc42する
• brew install libksbaする

LLVMでないGCCがgcc-4.2というコマンド名で使えるようになっているので、これを使ってrvm installする。

CC=gcc-4.2 rvm install 1.9.3

記憶にたよっているけど、だいたいこんなステップを踏んだはず。

あれ、ぼちぼちLLVMでいけるのかな?

Groonga 2.0.2から類似文書検索機能が使えるようになった。GroongaのRubyバインディングであるRroongaでは2.0.3で同機能への対応がなされている。

Groongaレベルではselect ... --filter カラム名 *S "テキスト"により類似文書検索ができる。このときに指定するカラムは全文検索できるようインデックスを作っておかなければならない。

Rroongaからの使い方は以下のようになる。(Article.bodyに抽出対象のテキストがあるとする。)

1
2
3
4
5
6
7
8
9

records = Groonga['Article'].select do |record|
  record.body.similar_search(article_body)
end

records.sort([
      {key: '_score', order: 'descending'},
    ], limit: 10).each do |record|
  ... # 見付かった文書を使った処理
end

この機能をJekyllやOctopressから利用できるようにしてみた。試行錯誤の様子が残っているけどgistに置いておいた。

Gemfileにgem 'rroonga', '>= 2.0.3'を加えること。また、この中ではMecabを使っているのでMecabを有効にしたGroongaを構築するか、Mecabを使わないようにすること。

Octopressならsource/_layouts/post.htmlに以下を加えるなどすれば類似文書へのリンクを表示できる。

1
2
3
4
5
6
7

{% if page.similar_posts.size > 0 %}
  <p class="meta">Similar posts:
    {% for sp in page.similar_posts limit: 5 %}
      <span class="similar-post"><a href="{{ root_url }}{{ sp.url }}">{{ sp.title }}</a></span>
    {% endfor %}
  </p>
{% endif %}

なお、Jekyllには類似文書検索をするための機能がもとからあって、--lsiオプションにより利用できる。ただ、手元の環境ではこれがうまく動かなった。0割り算エラーが発生したりしてしまって手に負えそうにないため、上のGroongaを利用する方法を考えた。

勉強会やそれに似た催しよりも、もっとゆるやかな集まりがとしてHack Cafeというのが行われている。私の周囲でいうとDebian Hack Cafeやハックカフェ in 姫路がある。

数年前から行われているもので、ずっと興味があったものの、開始当時の仕事の状況では都合をつけられそうになかった。やってるな、そのうち行けたらいいな、と思うだけであった。残念ながら最近は集まる回数が減ってしまっているようだが、その「ゆるさ」には今でもひかれるところがある。つまり:

話題や課題を決めず、平日の夜に二時間ほど、カフェで、基本的には自分の作業を行う。途中参加も、途中退場もあり。気にしない。

そこで、これを横浜でやってみようと考えている。コードを書いたり、調べものをしたり、本や雑誌を読んだり、写経をしたり、小声でだべったり、気が向けば相談したり、など、なんでもアリ。個人的には、仕事以外で何かを作ろうとしているとき、ちょっとほかの人の意見を聞いてみたいことがある。「これでいいのかな?」とか「もっと何かないのかな?」といったやりとりをできたらいいなと思う。

とはいえ、本当になんでもアリだとぼんやりしすぎていて参加しにくいかもしれない。一応のテーマをOSS関係としよう。私自身はRuby/Rails/Debianあたりに関する何かをするつもりでいる。今だとアルゴリズムを学ぼうをRubyで写経(?)なんてのもよいかな。

まずは六月中に一度。開催場所はまだ決めていないが、ひとまずはタリーズなどを想定している。無線LAN環境や電源のあるところがよいだろうけど、それはおいおい。(Wi-Fiルータを使うとか。) せっかく集まるのだがら四人掛けのテーブル席なんかがあるとよいのかな。

まあ、あまり考え込んでもしかたないので、なんなら一人でぽつんとやっててもいいや、くらいの気持ちで始めてみよう。(ずっと一人だったら適当にカフェめぐりでもしよう。ま、最初くらいはサクラをお願いしたいところではあるかもだけど。)

hackcafeやるとしたらどうやるといいんだろう。とりあえず無線LANは必要として、電源があるといいな、くらい? あとは四人掛けとかのテーブル席を確保したほうがいいのかな?

— akira yamada (@arika) June 3, 2012

追記(2012-07-27)

六月中には〜と言っておいてすいません。いろいろごたごたでうまく時間をとれずにいます。もう少しなんとかしてからですが、やってみたいなとは考えています。

この数年、直接的なOSS活動から遠ざかっていた。けれど、ちょっと気持ちの変化があり、また何かしら活動できないかなと考えるようになった。そこで、近く開催される大統一Debian勉強会に参加することにした。

できるだけたくさんの人の顔と名前を一致させられるよう、いろいろ見聞きしたいと思っている。

また、twitterでつぶやいた通り、どこかで場を作って(会場のすみで立ち話とかかも)最近のDebianでのRubyの事情について教えてもらおうと勝手に考えている。

最近のDebianでのRubyの事情をここしばらくさぼりすぎなメンテナ(=私)に教えてあげよう会とかどうだろうか。などとと居場所を確保しようとしてみたり……。 #gumdebianjp gum.debian.or.jp

— akira yamada (@arika) June 1, 2012

ちょうどよいタイミングでBits from the Ruby team: switching to Ruby 1.9 and trasition to new policyというアナウンスが出ているので、このあたりも含めて。他に何人かでも人が集まるようなら、パッケージメンテナンスのこと以外の、もっと広い範囲で意見交換などできればいいなと思う。

(gem2debのコードリーディングというあたりから手を動かすと面白いのかも?)

ScanSnapのような両面を一度に読み取るスキャナを使っていると、まんが雑誌などで裏側の陰影が透けてしまうことがある。雑誌だけでなく、少年まんがや少女まんがでも同じように透けることが多い。

こういうのはあきらめが肝心だろうと思う。

ふり返ってみると、紙のまま読んでいるときでも裏写りしていることが少なくない。似たような状態を画像として見ると気になるのは、スキャン後のチェックをしているからのように思う。実際、通して読む段になると、チェック時には気になったはずのところをひっかかりなく読み進めていたりする。

とはいうものの、あまり手間をかけずにできることがあるならばとも思う。

多くのまんがは白・黒の二色で印刷されていて中間色はない。よって理想状態のヒストグラムでは両端に二本の線が立つことになる。ところが実際の印刷物には汚れ、折れなどの変形、インクのかすれ、紙そのものの凹凸があり、さらに印刷そのものの質の影響もある。それを読み取るスキャナには解像度の限界がある。そうしてヒストグラムには二つの山ができる。

そうしてみると、ヒストグラムの偏りが大きく、山が鋭く切り立っているほうがよりよい画像といえるのではないだろうか。そこで少し試してみた。

普段はグレースケールでスキャンしているのだが、間違えてカラーでスキャンしてしまった画像がある。その中から比較的はっきりと裏写りしているものを一つ選んだ。(こうした紙面の場合、裏写りがまったくない画像はほとんどない。)

ヒストグラム(RGB)を見ると、青か緑の山が赤よりも細身であることがわかる。通常のグレースケール化(明度)、赤チャネル、緑チャネル、青チャネルのそれぞれに対してレベル調整を行った。(gimpスクリプトによりいずれも同程度の調整結果となるようにした。)

白地の部分に違いはないが、トーンがかかった部分については青チャネル(右端)の程度がもっともよい。同じ紙面の他のページについても同様に確認してみたところ、やはり青チャネルの程度が他と比べてよいようだった。

黄ばみのある紙面についても同じように確認してみた。この例では赤チャネルがもっともよく、逆に青チャンネルが残念な結果となっている。(これは単行本であり裏写りはほとんどない。)

今回のお試しの結果からすると、裏写りがきついものや黄ばみのあるものについてはカラーでスキャンしておいたほうが後処理での調整をきかせやすいといえる。

ただし今回確認した範囲はたかだか数ページのみ。一部を切り出して比較するだけではなく、一冊まるごと、あるいは複数からある程度の量を処理して読み比べてみたほうがよいだろう。また、裏写りがそれほどきつくない場合には通常の明度からのグレースケールに対するレベル調整で十分な処理ができることも少なくない。

サンプルに使わせてもらったまんが

TEI OH-! - 庄司二号さん
まんがタイムきららミラク2012年3月号から (3〜5月号でゲスト掲載、現在発売中の6月号から連載開始)
楽天市場でミラクを探す
7ネットショッピングでミラクを探す

ももいろシスターズ(2) - ももせたまみさん

ScanSnapで検索可能なPDFにしたとする。このとき、せっかくだから検索可能なまま画像の調整をしたくなる。だが、その種のことができるツールというのをどうもうまく探せない。いかにも何かありそうなものなのだけど。

それなら作ればよい。PDFを扱うライブラリはたくさんある。最終的にできるかどうかはともかくとして、ちょっと試すくらいならやりようがあるだろう。

そう思ってあれこれやっていたのが2010年12月くらいのこと。その当時の環境ではこれが意外にめんどうで途中までやりかけたものの放ってしまっていた。その時使っていたライブラリのバージョンが上がってリリース版が出たというのを先日知って、もう一度やってみることにした。すると意外にもこれが結構簡単にできてしまった。

当時でもPDFを扱うライブラリは簡単にいくつも見付かった。代表的なのはPDF::WriterやPrawn。その他のいくつかのライブラリとともに試してみた。しかし、それらにはPDFファイルを新たに作成する機能はいろいろとあるものの、既存のPDFファイルを改変する機能がほとんどなかった。

しかたないのでPDFファイルを直接編集するものを作り始めたのだが、すぐにPDFの自由さ知ることになる。というのはScanSnapが出力するPDF、Acrobatで編集したPDF、Preview.appで編集したPDFと、みな構造が異なっていたのである。これではまともにPDFを解析しなければ対応しきれない。

そうして改めて探し直して見付けたのが、開発中だったOrigamiである。

現在までにバージョン1.0がリリースされ、gemでのインストールも可能となっている。現時点でのバージョンは1.2.3。2010年末の時点ではドキュメントもサンプルもほとんどなかったが、このバージョンにはいくつかの有用なツールが含まれている。手軽にPDFをいじりたいというときにはすぐに手本にできるものが揃っているといえるだろう。

• pdf2graph - Generates a Graphviz DOT or GraphML file out of a PDF document
• pdf2pdfa - Enforces a document to be rendered as PDF/A
• pdfcop - PDF document filtering engine using Origami
• pdfdecompress - Uncompresses all binary streams of a PDF document
• pdfencrypt/pdfdecrypt - Encrypts/Decrypts a PDF document (Supports RC4 40 to 128 bits, AES128, AES256)
• pdfextract - Extracts various data out of a document (streams, scripts, images, fonts, metadata, attachments)
• pdfmetadata - Prints out the metadata contained in a PDF document
• pdfsh - OrigamiによるPDF操作にカスタマイズしたirb
• pdfwalker - PDFの構造を表示するGUIツール(Ruby/Gtk2)

このうちのpdfextractを参考にして、PDFに含まれる画像をImageMagickで編集するスクリプトを作ってみた。PDFの仕様は公開されているものを拾い読みした程度なので適切ではない部分があるかもしれないが、evinceやPreview.app、i文庫で参照できることを確認した。

動作確認には、紙が薄いことがよく知られている角川スニーカー文庫をスキャンしたものを使ったた。同文庫は紙のまま読んでいてもよく透ける。スキャン結果もそれに応じたものとなる。下は生成されたPDFと処理したPDFをi文庫で参照したときのスクリーンショットである。

このように文章ページではスッキリしたものとなった。ところが、ちょうどこの裏のページにある挿絵では以下の切り抜きのようにやりすぎてしまっている。なかなか難しい。(なお、動作確認に使ったのは以前紹介(?)したことのある「子ひつじは迷わない 泳ぐひつじが3びき」の15〜17ページ。)

手元では挿絵ページやカラーページはエクセレントで、それ以外はスーパーファインでスキャンして、Preview.appでマージしている。よってdpiをキーに調整内容を変えればもう少しよい結果を得られるだろう。また、ページの内容に応じて処理を変えるようにしたり、ページを指定しての画像差し替えを可能にすればツールとして実用的になるかもしれない。ただ、そのためにはページ構造を扱えるよう作り込まなければならない。

ともあれ、2010年当時には、こういう単純なコードだとメモリをどんどん食いつぶしていってくれたのだが、リリース版で改善されたのか、Ruby 1.9.3を使っているからなのか、200ページちょっとの文庫本を特に問題なく処理できた。なかなかよい。

昨日の記事はブックマークのつもり書き始めた。しかし脱線していって自分でやってみたことのほうが多くなってしまったので記事を分けることにした。

きっかけは以下のページ。

Desire for wealth : ScanSnap の自炊 pdf を自動で美白化（レベル補正）する

convert -density 150x150 -type GrayScale \
  -linear-stretch 10%x35% \
  -geometry 512x -compress jpeg -quality 80 a.pdf b.pdf

このページや他のページで解説されているのはconvertの-linear-stretchの使い方である。だが、似たようなオプションに-levelというのがあって、これらの関係がよくわからない。そこでいろいろと試してみた。

結果を言うと-levelもこの目的では同じように利用できる。

どちらもまっ黒、まっ白にする水準を指定して画像加工を行う。ただしパラメータの指定には違いがある。-levelは入力画像の明度で指定するのに対し、-linear-stretchでは入力画像の明度に対するヒストグラムの値で指定する。(……ということで合っているだろうか?)

明度の値は0〜255(0〜100%)である。たとえば0〜51(0〜20%)を黒く、230〜255(90〜100%)を白くしてしまおうと考えたとする。

-levelを使うなら-level 20%,90%のようにパラメータを指定する。このような方針に対して-linear-stretchを使うのは難しいが、あえて使うなら明るさレベルが二つの範囲に収まる画素数をカウントして指定してやることになる。

たとえば、下の「元画像」とした画像には明るさが0〜51の範囲の画素が676、230〜255の範囲の画素が106,169ある。よって-linear-stretch 676,106169とすれば-level 20%,90%とおおむね同じ結果が得られる。

与えたパラメータの値から分かる通り、-levelは数直線上の位置を指定するのに対して-linear-stretchは白黒それぞれの端からの範囲を指定するという違いもある。これらをGimpのレベル調整との対応させると、三つならんだ「▲」の位置を指定するのが-levelであり、ヒストグラム中の面積(図中で赤くした部分と青くした部分)を指定するのが-linear-stretchである。

なお、ここで示したヒストグラムの生成もconvertで行った。元画像からのヒストグラムの抽出は次の通り。

convert orig.jpg -format %c histogram:info:-

そしてレベル補正後のヒストグラムのグラフ生成は次の通り。せっかくなので出力ファイル名の展開を使ってみた。

convert orig.jpg level.jpg linear-stretch.jpg \
  -set filename:bn %t \
  'histogram:%[filename:bn]_histogram.jpg'

ヒストグラムについてはこちらを参照した。

ここでは例示のためにあえて甘めの白飛ばしにしたが、レベル補正だけでもconvert -level 20%,80%くらいにすると(この画像の場合には)かなり読みやすくなる。ついでなので以前作った、というより作りかけのまま放置しているGimpスクリプトで加工した結果もならべておく。

ところで、大本の一ページまるまるの画像は4,183×6,154ピクセルある。上の例で示しているのはそこから切り抜いて加工し、その結果を約1/6に縮小したものである。大本画像を同じ要領で縮小すると684×1,006ピクセルとなり、これはiPad1/2を横向きにして見る場合のサイズとほぼ同じ。そう考えると、レベル補正だけでもわりあいいいところまでいけそうな気がする。

よく見るとGimpでいろいろやったもののほうがいくらかきれいなのだけど、その差以上の処理時間の違いがある。我が家のPCで大本画像を処理しようとすると数十秒かかってしまい――ちょっと使いものにならない。Gimpでがんばるのもなかなか楽しいのだが、別の方法を考えたほうがよいのかなという気がしている。

ここで大切なお話: 上の例でとりあげているのはまんがタイムきららミラクで連載中の柊ゆたか著「Good night! Angel」第一話の一コマ(ミラク創刊号75ページ)。きらら系他誌とはちょっと毛色が違っていて、この作品をはじめ他作品も含めて面白い。

どこがどう違うのかというのは難しいのだけど、物語が重視されている作品が多いこと、だろうか。

日々の中の一日をちょこちょことつまんで全体的な物語を構成するのは他4コマ作品でもみかける。ミラクではもう少し長めにとられることが目立つように感じる。点を連ねるのに対し、線とまではいかないかもしれないけれど線分ではあるかな、というところ。

それから絵の書き込みが他誌よりも細かい気がする。みなさん妙に気合いが入っているというか。読み返していて「おっ」というところをみつけることがしばしば。

まあ、うまく言えないんだけど、ともかくおすすめ。

楽天市場でもっと探す
7ネットショッピングで探す

スキャンした画像を読み易くするための後処理が世の中でどのように行われているか調べてみた。自分用のブックマークでもある。

jarp,より

150 dpiでスキャンするより300 dpiでスキャンして16階調にしたほうがサイズが小さい - jarp,

convert in.png -deskew 40% -level 30%,100% -sharpen 5 \
  -density 150x150 -colorspace gray -resize 514x751\! -depth 4 out.png

-deskewにより傾き補正をかける。その際にぼけるため-sharpen 5でぼけ補正もしておく。

スキャンは横向きで - jarp,

r=90
for i in *.png;do convert $i -rotate $[r*=-1] r90-$i; done

縦長の紙面を横向きでScanSnapにかけるとスキャンにかかる時間が短くなる。このときの画像は横向きかつ互い違いとなるため、これを縦向きに変換するためのコマンドライン。

ImageMagick convertで連番処理 - jarp,

convert '*.png' -type grayscale -depth 4 d4/%03d.png

ImageMagickには独自のワイルドカード処理がある。また、出力ファイル名にprintfに似た形式の文字列展開ができる。この例のように出力ファイル名に%dがあれば、その部分は0から始まる連番に展開される。たとえば*.pngにマッチするファイルが三つあればd4/000.png、d4/001.png、d4/002.pngに変換結果が出力される。

-scene 1のようなオプションを付加すると連番が指定した値(この場合は1)から始まる。

この他、画像自身の属性値からファイル名を構成するなどいろいろなことができる。参考:

• Filename Percent Escapes - 画像の属性情報も使える
• -setオプション
• Writing a Multiple Images - Adjoin Techniques - 入力ファイルのワイルドカード展開はシェルにやらせてもよい

Desire for wealth : ScanSnap の自炊 pdf を自動で美白化（レベル補正）する

convert -density 150x150 -type GrayScale \
  -linear-stretch 10%x35% \
  -geometry 512x -compress jpeg -quality 80 a.pdf b.pdf

PDF中の画像データに対して、いわゆる白飛ばしをかける方法が紹介されている。ここで-linear-stretchのパラメータの意味が重要となる。このパラメータについての詳細はUbuntu Weekly Recipe 第102回 ImageMagickでコマンドラインから画像加工で解説されている。(二ページ目へのリンクだが一ページ目から読んだほうが分かりやすい。)

これらの記事で解説されている-linear-stretchの他に-levelというよく似たオプションがある。両者の違いと適用した結果がどうなるかについてもう少し調べた内容を別記事にしてみた。

スキャンした書籍や書類の余白をImageMagickで除去する | anobota

convert \
  \( -size 320x400 xc:white \) \
  \( -level 0%,75%,0.8 -fuzz 50% -trim original.jpg \) \
  -gravity center -composite out-5.jpg

344×292の余白のある画像から文字部分だけを切り抜いて、それを320×400の中央に配置するためのコマンドライン。

-trimによる文字部分の切り抜きの際、-fuzzを指定することで紙質によるムラなどの影響を小さくすることができる。小説などではかなり使えそう。技術書でも、といいたいところだが、ページ端にマークがついていたりするので最初に-cropしないとならないかも。

Kindle3向けdot by dotな自炊PDFを(真面目に)作成する - ただのにっき

様々に調整された手順をパッケージ化されている(kindlizer)。私自身は同端末を持ってはいないのでそのまま使うことはないが、その内容は参考にさせてもらえるのではないかと思う。と、いいつつ、まだあまり内容を読んでいないけれど。

scansnapで自炊した本をkindleで読めるように補正する(2)

ImageMagickがよく使われるなか、OpenCVで後処理を行っているという話。OpenCVを使った処理に興味があるので時間をとって試してみたいと思っている。が、これまたなかなか手をつけられをいままでいる。

しばらく開発が止まっていたRuby/OpenCVが動き出しているようであり、手を出すのにちょうどよい時期かもしれない。(参考: 第5回 Ruby/OpenCV進捗報告、ruby-opencv)

Gimp Script-Fuによる処理

ここからGimp関係の記事になる。

Script-fu: 矩形選択範囲からImagemagick crop用のgeometry表現を得る

これは直接的なものではないが、GimpのScript-Fuを使っていて興味をひく。Script-Fu自体の情報がなかなかないので参考になる。(参考: Gimp記事のもくじ)

Gimp Pythonでスキャンした画像を一括修正

GimpからPythonスクリプトにより画像処理をするという話。トリミングやトーンカーブ調整などが行われていて、詳しく読んではいないが参考になるのではないかと思っている。

• Gimp Pythonでスキャンした画像を一括修正２
• Gimp Pythonでスキャンした画像を一括修正３
• Gimp Pythonでスキャンした画像を一括修正４