メモ

2013年6月18日火曜日

Feedeen使い始めた(けどまだインポートだけしかしてない)

申し込んでおいたFeedeenの招待が来たので、早速Google Readerからフィードをインポートしてみたところ、インポート結果のメールを見ると、そこそこの数の失敗があった。

メールにはタイトルが書いてあるので、そのタイトルをもとにOPMLからURLを探して、

存在しているかどうか・移動先があるかなどをチェックしながら、失敗したのを追加していたら、3件目ぐらいで面倒くさくなったので自動化したくなったので、とりあえず手始めにメールとOPMLからフィードのURLだけ取り出すのを作ってみた。

結局それではいろいろ面倒なので、インポートするのに使ったOPMLから、インポート結果のメールでエラーがあったと言われたフィード以外は削除、さらにurllib.request.openでアクセスしてみてアクセスできなければ削除して、取り込めそうなフィードだけ残すようにしてみた。

Gistに貼ったスクリプト

2013年6月16日日曜日

Emacs環境を久しぶりに見なおした

dual bootにした結果Linuxを使う時間が増えて、Emacsを使う時間も増えたので、ちょっと環境を整理してみた。

まずフォントの設定。9ptだとちょっと小さく感じることがあるので大きくしたいが、half width:full width=1:2にならないと気になるので、ptではなくpxで指定して

(set-default-font "VL Gothic:pixelsize=16")

とした。pixelsizeが偶数なら1:2になるはず。

野良で.emacs.dに突っ込んでいた幾つかのelispをMELPAのパッケージで置き換えた。

次にPythonのauto-completionをJedi.elにした。設定は簡単だし軽いと思う。これはMELPAのパッケージリストを見ていた時に思い出した。以前見かけて使ってみようと思っていたのにすっかり忘れていた。

ついでにhelmも使ってみたけど、なれるまで大変そうなのでやめておいた。
C-x bにhelm(anything)-for-files割り当ててるのを見たので試しに、やってみたら遅くてなかなかつらい。一個前(previous-bufferではなく)に戻るのにC-x b(switch buffer)使うのが悪いのかもしれないけど、C-x b RETみたいに入力するとbuffer作成中に切り替え先を確定してしまうので期待通りに動かないことが多かった。

C-x b周りをいじってる時に、前から使っているiswitchbとidoで迷ったものの、idoにしてみた。ただ、idoはido-find-fileが素のfind-file+session(+minibuf-isearch)みたいに過去に開いたファイルを開けないのが辛いので、find-fileはそのままにした。最近開いたファイルだけを開くのであればrecentf+idoでやってる例が幾つか見つかったけど、ファイルを開くという操作に対して別のキーを割り当てるのは厳しい。ido-find-file自体は使いやすいんだけど…。

2013年6月8日土曜日

Linux環境をVMからdual bootに移行した

しばらくWindows上でArch LinuxのVMを動かしていましたが、メモリ使う処理をするのに不便なので、dual boot化しました。Thinkpad x201sのUltra Baseに増設した1TBのHDDにWindows 8と一緒に入れてWindows 7,8, Arch Linuxを起動できる状態です。Windows 7/8は普通に起動するだけですが、Arch Linuxは手を抜いて起動デバイス選択メニューから起動させるようにしました(grubを増設ディスクのMBRに入れられるので)

VMに物理ディスクをマウントできるようにしてrsyncでコピー、あとはgrub2を設定しなおしぐらいでできたので特に書くことはない感じだった。
しばらくはVMからも起動できるようにしておいたけど、必要性がない感じがしてきたのでVMware関係(open-vm-toolsとかxf86-video-vmware/xf86-input-vmmouse)は削除。

dual boot化で入れたのは無線LAN、電源管理、Bluetooth関係のパッケージくらい。無線LANはnetctl(wifi-menu)ですませることにしました。
Windows 8だとやり方がわからないバッテリ充電レベルの調整(40%まで減ったら充電開始、80%で充電止めるとか)もできて満足です。

KVMとかが遊びやすくなりました。

btrfs send/receive

いつの間にかbtrfs send/receiveができるようになっていたらしい。zfsのやつと使い方は基本的に同じ。

自分の環境(Arch Linux)で試しにbackupをとる手順をやってみた。

[root@archbox ~]# uname -a
Linux archbox 3.9.4-1-ARCH #1 SMP PREEMPT Sat May 25 16:14:55 CEST 2013 x86_64 GNU/Linux
[root@archbox ~]# btrfs --version
Btrfs v0.20-rc1-253-g7854c8b

手順は簡単

snapshotをとる(readonlyじゃないとsendできないので-rをつける)
btrfs subvol snapshot -r /home/ /home/backup (/homeがsubvolume)
snapshotをbackup
btrfs send /home/backup/ | btrfs receive /backup

だけ

sendしたstreamをとっておくだけでもいいし、基準のsnapshotと新しいsnapshotを使ってincremental backupもできる

incremental backupは、前の手順の続きで

新しいsnapshotをとる
btrfs subvol snapshot -r /home/ /home/backup2
親(基準)を指定してsend
btrfs send -p /home/backup/ /home/backup2 | btrfs receive /backup

しばらくブラウザで遊んだあと試してみた結果

[root@archbox ~]# btrfs send /home/backup | wc -c
At subvol /home/backup
4609013921
[root@archbox ~]# btrfs send /home/backup2 | wc -c
At subvol /home/backup2
4610672892
[root@archbox ~]# btrfs send -p /home/backup /home/backup2 | wc -c
At subvol /home/backup2
59143976

2012年7月28日土曜日

whooshのインデックス

whooshのMLを見ていたら、言語毎にanalyzerを使い分けたいという話の流れの中で、自分でtokenizeして書き込む例(test)が紹介されていました。
その例は、Schemaの定義にはanalyzerを設定せずにインデックスを構築するものでした。igo-pythonを使うとtokenizerがインデックスにpickleされて保存されるので、インデックスが大きくなるのが悩みだったのですが、この方法なら肥大化を避けられます(pickle時に細工して回避する手段は入れてありますが)
なので、実際にどのくらい変わるか確認してみました。tocファイルのサイズが全然違う(41186237 vs 996)ことがわかります。

ソース(gist)

結果(gist)

2012年7月22日日曜日

chrome.tts(text-to-speech)で日本語よみあげ

少し前ですが、chrome.ttsを使って日本語の読み上げが出来ました。試作のchrome extensionのソースはtest-chrome.tts(github)に置いてあります。Chrome Tech Talk Night #3に参加したことですし、せっかくなのでManifest Version 2のbrowser actionで実装してみました。ダウンロード後、chromeの拡張機能設定のところで、

デベロッパーモード on
パッケージ化されていない拡張機能を読み込む

とやれば登録できます。

以下メモ

Microsoft Speech Platform 11+HarukaをSAPI5登録した64bit版のWindows7で試しました。はまりどころは、Chromeが32bitアプリなので、HarukaのSAPI5登録を32bit環境(WOW64)にもすることぐらいでしょうか。なので、ちゃんとSAPI5に対応している日本語読み上げ環境があればはまりどころは無さそうです。
HarukaのSAPI5登録の方法は

x86版のSpeech Platform 11をインストール
Harukaをインストール
レジストリのコピー reg COPY "HKLM\SOFTWARE\Wow6432Node\Microsoft\Speech Server\v11.0\Voices\Tokens" "HKLM\SOFTWARE\Wow6432Node\Microsoft\Speech\Voices\Tokens" /s /f

勘違いで、


chrome.tts.getVoicesがSAPI5の音声を全て列挙してくれる
lang属性でja-JPで指定すれば日本語対応のを選んでくれる


と思っていたのですが、ttsEngineレベルで列挙してくれるだけであって、SAPI5のものはnativeとして1つだけ出てくるだけです。また、lang属性はnativeなものでは見てくれない＋提供されない(undefined)ようなので(複数言語に対応するttsEngineが切替に使うもの)、コントロールパネルの音声認識→音声合成で選択した音声をHarukaにしておく必要がありました。Macだとどうなのかは不明。

2012年7月16日月曜日

MoinMoin2.0で日本語コンテンツを検索する

MoinMoin2.0 は検索機能に Whoosh を使っています。なので、日本語用のAnalyzerを使ってやれば検索出来るはず。ということでやってみました。
日本語が検索出来るだけのとりあえずのものですが https://bitbucket.org/hideaki/moin-2.0 にあります(変更点) 日本語用のAnalyzerには以前作った whoosh-igo のTinySegmenterTokenizerを使いました。

セットアップの記録(フォークしたやつからcloneするなら変更は不要です):

hg clone http://bitbucket.org/thomaswaldmann/moin-2.0 moin-2.0
cd moin-2.0/
DIR=env-pypy PYTHON=/opt/pypy/pypy-c ./quickinstall
. ./env-pypy/bin/activate
pip install whoosh-igo # TinySegmenterTokenizer用
wget https://mhagiwara.googlecode.com/svn/trunk/nltk/jpbook/tinysegmenter.py
vi MoinMoin/storage/middleware/indexing.py
# ↑indexを作る前に使うanalyzerを指定する必要がある
moin index-create -s -i
moin load --file contrib/serialized/items.moin
moin index-build
moin # サーバ起動