あるいは Kanazawa.rb meetup #9 は「意識高いもくもく会」です。
はい、まぁ最近じゃ今さらの話ですね。
Chef って興味あったんですよというか正確には Puppet に興味があって、でも大げさだなと思ってたんですよね。あと当時は Puppet は外部DSLだったので、「Rubyの文法でもなんでもない設定って、どうやってエディタでハイライトするの?」というのが最大の心理的ハードルでした。
で、時は流れて Software Design の Chef 特集を読んでやる気になったけど、本家のリファレンスと格闘しているうちに仕組みの大掛かり感が増長されて挫折。その後ビッグウェーブに乗って達人出版会で買った『入門Chef Solo』を読み、そこでようやく
「サーバの状態を管理し収束させるためのフレームワーク」
という表現がグサッと刺さって、分かった気がしたのでもう一度やってみました。で、一応動くところまで来たので、今回改めて感じたことをまとめておこうと思います。
Vagrantのメリットよく分かってなかった
VirtualBox は以前から使っていたのでなんでわざわざ Vagrant なんか使うの?ってずっと思っていたんです。今も自分で使う分には Vagrant である必要はないよなーと思いつつ、以下のようなところがメリットかなと今は思っています。
- 手作業での設定を必要としないので VirtualBox をよく分かっていない人にも同じように VM を配布することができる
- ある程度設定の完了した VM を box として package して共有しやすい
- 生の VirtualBox で VM の使い回しをやろうとするともっと手間が掛かる
※ vagrant 1.1 から単なる VirtualBox の wrapper ではなくなったのでそこにメリットがある人はぜひ使いましょう。
Vagrantの扱いにくさをよく分かってなかった
- Vagrant は gem install もできるが基本的には配布パッケージが最新
- 特に今(2013年初夏)は 1.0/1.1/1.2 の過渡期で設定ファイルのフォーマットが違ったりいろいろややこしい
- Windows で動かすことを思うと1.2がよいが gem の最新は 1.0.x
- でも Bundler で扱えた方が周辺ツールも含めて管理できるので本当はそっちがよい
org-binbab/gem-vagrant-wrapper · GitHub
という神 gem があります。これを入れると最新の package 版 Vagrant を使いつつ Bundler 管理できるようになって超絶便利。
Chef Solo + Knife Soloという構成はWindowsに厳しすぎる
Chef を使うにあたって『入門Chef Solo』を参考にしたので当然のように全体の作業は Knife Solo ベースでやっていました。
Knife は慣れてくると cookbook を作り実行するというサイクルの中心に置いたときにすごく使いやすいことが分かってきます。それは間違いないんですが、いかんせん
ssh + rsync で cookbook を転送する
というその仕組み上、Unix 系の開発者でない人が使っている(いわゆる普通の)Windows とは相性が悪すぎます。
結局WindowsではVagrant + chef-solo provisoningに落ち着いた
knife solo で cookbook を練っていって、最後は
config.vm.provision :chef_solo do
...
end
に反映されるようにしました。まだこの部分の Vagrantfile の生成やバージョンの管理方法はきれいにまとまってないのですが、方針としてはそういう形で行こうと思ってます。 Windows 用の手順をまとめると
- VirtualBox をインストール
- Vagrant をインストール
- vagrant plugin install vagrant-vbguest
- Putty + vagrant-multi-putty plugin の準備
- vagrant box add <BOX URI>
- vagrant up
といった感じ。実際には
- Putty 周りの設定が慣れてない人はやや面倒(PATH が通ってなきゃいけない)
- vagrant putty でなぜかパスワードを聞かれる(なんでかよく分かってない)
- 例えば Rails の環境を作るためには vagrant putty したあとに bundle install とかお約束の作業は必要
- そのうえで rails server 立ち上げるなども必要
てな感じで2回コマンド叩いたら何もかも完了、みたいなことは実現できないんですが、初回の待ち時間はともかく、サーバの設定が全自動で済んでいるというのはやはり大きいと思います。少なくともサーバ構築とかまったく目的ではない人にとっては書かれた通りに作業するだけでいいというのは魅力的なんじゃないかな。
VagrantのChef Solo Provisioningで思い込んでいたこと
Chef を実行するのは VM 上なんだからどうにかして VM 内に cookbook 運ばなきゃいけないですよね。で、VirtualBox の共有フォルダに置くとかしなきゃいけないのかなと思ったけど、そんな必要はありませんでした。なんか自動でうまいこといってた。
ChefのCookbookを育てる環境とそうでない環境
上の vagrant-wrapper 頼みで cookbook を育てる環境の Gemfile は以下のようにしました。
# -*- mode: ruby -*-
source 'https://rubygems.org'
gem 'rake'
gem 'vagrant-wrapper'
gem 'chef'
gem 'knife-solo', '> 0.2', :git => 'https://github.com/matschaffer/knife-solo.git', :tag => 'v0.3.0.pre3'
gem 'sahara', :git => 'https://github.com/ryuzee/sahara.git'
gem 'vagrant-vbguest'
これで git と gem と ssh の使える環境では knife solo でもりもり cookbook を作ったり実行したりできます。provisioning にしか興味のない環境では bundle install はしないで package の Vagrant を直接叩いて作業してもらいます。
Chefでようやくつかめてきたこと
すべてはリソースと見つけたり
Chef って語る要素がすごく多いんですが、要は
- ホストの状態を収束させる
- そのためにリソースをキーにしてコードブロックを与える
- その中で only_if, not_if でちゃんと状態をチェックする
- 楽して execute リソースを選ぶと実行の終了をきちんと待てずに2回実行しないと安定しないといったことも起きるので注意
の大きく2点が大事かなということに気づき始めました。
正直言うと sh script の方が楽じゃないのと思うポイントはまだ多いし、生のコマンドでできることが chef の resource に落とし込んだ段階で制限されて変に手間の多い recipe になるといったことはあります。でもやはりそこは手間と思っても分けておいた方が段階的に実行する/しないをチェックでき、最終的には早く収束される方向に振ってあって、試してるうちにうまいなぁと思うようになってきます。
- 特に条件分岐を sh script で書き始めるとコードがすぐややこしくなる
- なにより sh script では再利用しにくい
- Chefでちゃんとリソースを意識してrecipeを書いていればrecipe単位, cookbook単位での再利用しやすさがある程度自然と確保される
辺りが感心するポイントでした。
recipeの分け方
今のところ以下のような方針でやってます。
- とりあえず 1アプリ:1 cookbook
- cookbook には default recipe があるんだけど、とりあえず cookbook と同名の recipe を作って明示的に呼ぶようにしてる
- 特に何らかの設定が必要だったり事前準備の必要なアプリのインストールの場合はこの分け方がいい
- 設定が不要でただインストールすればいいものはいくつもまとめてしまっちゃってok
- cookbook が分かれていなくても recipe が分かれていれば include_recipe で再利用できるので、分けて再利用する
recipe の再利用は
include_recipe "#{cookbook}::#{recipe}"
で記述するんですが、recipe 内では #{cookbook_name} で自身の cookbook の名前を知ることができる1ので、同じ cookbook 内の recipe も違う cookbook 内の recipe も自在に再利用できます。
再利用を前提にあれこれやっているうちに
- とりあえず何をするときにどこを見ればいいか
- 何が分かっていないか
がだんだん分かってきたので、以前よりはだいぶ recipe を書くのは早くなってきました。
次の課題
例えば複数の Rails 環境を用意したい場合、『入門Chef Solo』方式で hostonly で IP アドレスを固定していくのがいいのかどうか、迷っています。Vagrantfile を組み立てる rake タスクを用意して2、用途に応じて Vagrantfile を生成したのち vagtant up するのが手間も少ないし、見通しもいいのかなぁという感じのことを考えています。
でもそのうちまた違うこと言ってるかもしれないです。
chef というか vagrant を使ったホスト管理の話ですね、これは。
[20130729 追記]
Ruby 1.8 前提の書き方になっていたのと、Ruby 1.9 以降を使っている場合に Capybara-mechanize 1.0 前後で挙動が変わる記述を追加。
scrapeはmechanizeらしくUTF-8のままでok
click_on( '次へ>>' )
みたいな記述は UTF-8 で書いたものがそのまま動く。
テスト時はUTF-8への変換が必要
Ruby 1.8 では
body.toutf8
でよかった。
it {
body.toutf8.should include('ほげげげ')
}
みたいな感じ。
kconv を require した覚えがないのに kconv が動いてるのはなんでだろう。
まーいっか。
もし&#xxx;形式になってたら
(Ruby 1.8で動かしている場合は $KCODE = 'u' したうえで)
CGI.unescapeHTML(body)
でいいみたい。
ちなみにSelenium WebDriverの場合
全部 UTF-8 で扱える。Selenium で書いていって Mechanize で CI に乗せる、といった運用を考えている場合はここが食い違うので注意が必要。
Ruby 1.9+ の場合
いずれも Mechanize 2.7.1 で試した。
HTTP Response Header に charset がない場合の挙動が Capybara 1 と 2 の間、あるいは Capybara-mechanize 0.x と 1.x の間で異なっているので注意が必要。
たぶんイマドキは charset UTF-8 に統一してあれば response header に入ってそうな気はするけど、古い日本のサイトだとダメな気がする。
'capybara-mechanize', '< 1.0'
自動で正しく encoding を判別できていたので
.encode('UTF-8')
で OK
'capybara-mechanize', '> 1.0'
HTML の中に charset 指定があってもダメで HTTP Response の charset だけをアテにして encoding の判別に失敗するようになってしまい Encoding::UndefinedConversionError: … from ASCII-8BIT to UTF-8 エラーが出る。
仕方ないので
.toutf8.force_encoding('UTF-8')
を挟んだらうまくいった。
bind 9.4 以降の allow-* の設定
Debian を etch から lenny に上げた関係で bind のバージョンが上がった1。そしたら別セグメントのネットワークから forward 先の DNS を引けなくてちょっとハマったので覚え書き。
acl "allowed-hosts" {
.. ;
.. ;
};
options {
allow-recursion { "allowed-hosts"; }; // <- added
allow-query-cache { "allowed-hosts"; }; // <- added
};
こんな感じみたい。
default が localhost.localdomain なのでこの設定を明示しておかないと別セグメントのネットワークからは DNS が引けないとか forward されないといった問題が起きる。2
allow-recursion, allow-query, allow-query-cache 辺りは互いに補完するような関係らしく、ややこしいのであまり突っ込む気なし。
今回のケースはサーバのそばにいる自分の環境からは検証できない現象なので、気づくまで時間が掛かってしまった。うーん反省反省。
bind-announce のチェック
※ ここから先は実は5月26日の話
bind のアップグレードはいつも気を使うんだけど、日常的にはちゃんと情報を追いかけてなくて、たいていちょっとトラブる。(そんな長い時間じゃないんだけど。)
なんで bind の情報に追いついていないのかなと思ったら案の定 feed を購読していないから。そもそも bind は本家がどこかもよく分かっていないような状態で、そらいかんわなと反省。
で、feed を探すが見つからず。こういう古いアプリはサイトの作りも情報の告知方法も古いのが世の常。bind-announce という ML があるのは分かったが ML にはもう入りたくない。
そこで Nabble という ML アーカイブサービスを思い出した。これは ML のアーカイブを独自に作れて、かつそれを rss にも変換してくれるサービスなのだ。sign up して…えーとオレが思い描いているのとすでに画面が違うっ。使ってないのバレバレ。
あれこれ試行錯誤したが違うサービス上ですでに bind-announce の feed が配信されているのを発見。あーじゃあこれでいいじゃん。
Gmane – Mail To News And Back Again
ということで FLDR で subscribe 完了。よしよし。
cf.
先日、ようやくアジャイルプラクティス読了 で
コミットされる前のコードをどうやってレビューするの?という初歩的な話。だってコミットされていないコードは基本的に開発者のローカルの環境にあるわけでしょ?
と書いていたけど、そう言えば reviewboard なんてものがあったなぁと思い出して動かすことを試みた。しかし
monospace blog オンラインソースコードレビューツールのReviewBoardをインストールしてみた
にしたがって Debian etch で作業してみたがあえなく失敗。(Python Image Library が入らなかった。Django も経験ないし。)
気分を替えて Trac に PeerReviewPlugin - Trac Hacks - Plugins Macros etc. - Trac をインストール。こっちは Trac の plugin 特有のクセを把握できてなくてちょっと手間取ったけどなんとか動いた。
※ Trac 0.10.4 with Apache 2.2 + mod_fastcgi on FreeBSD 6.3R と Trac 0.10.3 with Debian etch + Apache 2.2 + mod_python 3.2.10 で確認。
やったことは以下の通り。
- PeerReviewPlugin を Python モジュールとしてインストール
- Webサーバの方へ EGG 周りの設定を追加
- trac.ini で Trac インスタンスについて有効に
- trac-admin で権限を付与
- trac-admin PATH upgrade
plugin を Python モジュールとしてインストール
TracPlugins The Trac Project Trac のまま。
- setuptools( easy_install ) をインストール
- easy_install で PeerReviewPlugin をインストール(EGG として Python の site-packages に入る)
Trac のバージョンによって対応するものが違うのでそれに合わせてインストールすること。easy_install に慣れていなかったのでどこで何を指定して easy_install を起動すればいいのか分からなかったけど、エラーメッセージや back trace を読みながらよちよち作業を進めたらなんとかなった。こういうとき Python や Ruby で書かれたツールは助かる。
しかしあとになって実は下の Google Group のリンクをたどれば何をすればいいかが分かった。今回インストールしたのは 0.10 用のものなので
sudo easy_install http://trac-hacks.org/svn/peerreviewplugin/0.10
でよかった1。
WebサーバにEGG用の設定を追加
以前 WebAdminPlugin を入れたときにももしかしたらやってたのかもしれないけど、あれは別な環境でやっていたのですっかり忘れていた。EGG は cache を指定しなければいけないらしく、FastCGI で動いているうちの環境では
FastCgiConfig -initial-env TRAC_ENV=/var/lib/trac
+ -initial-env PYTHON_EGG_CACHE=/var/lib/trac/plugin-cache
を書き足した2。(パスはサンプルに載っているまんまなので適宜書き換えること。)
使いたい Trac インスタンスについて有効に
この部分の記述が全然不十分で手間取った。
trac.ini の中で
cannot install peerreview (not picked up) - trac-peerreview-dev | Google グループ
に従って
[components]
codereview.* = enabled
で plugin を有効にする。また
/peerreviewplugin/trunk/README.txt - Trac Hacks - Plugins Macros etc. - Trac
に従って
[trac]
mainnav = ..,peerReviewMain,..
を編集してメニューに組み込む3。
権限の付与
trac-admin PATH permission list
とすると
- CODE_REVIEW_DEV
- CODE_REVIEW_MGR
が追加されているのでこの割り当てを行う4
使用感
ほんとに試しただけだけど、
- Trac の plugin なので当然 review 対象は reviewboard とは違って5 repository に commit 済みのコードの一部
- review の作成は 3 step か 4 step で、Ajax を使っていて難しいところはほぼない
という感じ。1 は運用ルールによっては問題になるけど、現状自分が関わっている部分では大丈夫かなと。
とりあえず Django のセットアップとか慣れないことをやらずに記録の残るレビューができそうなのはよさげだなと思っているところ。メール飛ばしたりなんだり、本格的には使っていないのでその辺は分かりません。
え? Retrospectiva はどうしたのかって? どうしましょうね。こうして plugin を使い始めると移行するのは難しいよねぇ。でもやっぱこういうプラグインのセットアップも Trac インスタンスごとにやらなきゃいけないのはイヤなんだよな。
[2008-06-02 追記] Review の様子が timeline に出ないぞ? timeline に出なかったら Review の追加はどうやって知るのだ? メールとか飛ばす設定があるのか? うーん、そりゃあどうだ。不便じゃないか?
Ticket みたいに Search の結果の feed を吐けるのかな、と思ったけどそんなこともない。というか自分宛に依頼のあった Review という条件では検索はできない。(まぁ My Code Reviews で出てはくるんだけど。)なんだかな。なんだかなぁ? 0.10 だからかい?
[2008-06-04 追記] あれ? Wiki の [source: link] 形式の記述が Source Browser じゃなくて peerReviewBrowser への link になって怒られるぞ? えーー。なんだよー。ダメじゃんよー。何乗っ取ってんだよー。
キヤノンも銀塩カメラ開発停止か? (/.-j)
35mm については銀塩はあんまり期待してないんですよ。現役で銀塩写真撮ってた時期からいずれ消えるなとは思ってたんで。ただフィルムや印画紙といった乳剤そのものの供給がかなり厳しくなってるんで、そのうち「カメラをはじめ機材は手に入るけど何もできない」という状況になっちゃうんだよな。カメラは中古でどうにでもなるけど、乳剤は生ものだから中古ってあり得ないし。そのうち「ビンテージ乳剤を使った半世紀ぶりの銀塩写真」とかいうよく分からない作品とか出てくるのかな? やだなぁ。困ったなぁ。
おれデジタルで写真楽しめるかなぁ? 不安だ。モノクロ派としてはやっぱ乳剤の力は圧倒的だもの。
※ このあと私はデジカメとろいし電池食うし値段の割にたいした描写力ねーしうざいんだよな、と暴言を吐いたのだった。駆逐するなら凌駕してくれ、頼む。
JavaScript の for ( i in array ) は i が添字だと。うーん、ちょっと書き出してみよう。
言語 | 書き方 | i にくる値 |
JavaScript | for ( i in array ) | 添字 |
awk | for ( i in array ) | 添字 |
sh | for i in array っちゅーか list? | 要素 |
Ruby | for i in array | 要素 |
Perl | foreach $i ( @array ) | 要素 |
PHP | foreach( $array as $key => $value ) | 添字も要素もどっちも |
Ruby は for も each も書き方が違うだけっぽいですが、for は awk 方式、each が shell 方式でもよかったかなとか勝手なことを思ったりした。
PHP 4 以降の foreach は要素を取り出すのと添字と要素の組み合わせを取り出すのと、両方の書き方
foreach(array_expression as $value) 文
foreach(array_expression as $key => $value) 文
が可能なんだけど、これ結構邪魔くさい。foreach ってのが長いくせに as とか => とか妙にタイプ量を上げるトラップが仕組まれてる。まぁ PHP 3 で使っていた
while ( list( $key, $value ) = each( $array ) )
よりはマシなんだけど。
mod_perl2 が出たらしい。(リンク先は /. なんだけど、オリジナルのリリース文書はないのかな?)
tdiary.net の稼働環境を見ると mod_ruby も Apache2 との間で深刻な問題はないだろうと判断できるので、あとは PHP かな? PHP5 への移行を伴わずに Apache2 で安定動作するようならそろそろ Apache2 にいっちゃってもいいかなぁ。(文字コードとか PHP の動作で悩んだのは2年も前の話か。)
- Pear をあれこれ
- Ming でグラフとか
以前は Linux → cygwin(Linux 側で rsync を起動)の方が安定していると思っていたんだけど、今やってみると cygwin → Linux(cygwin 側で起動)の方が安定しているみたい。なんでだ?
cygwin 1.5.9 | rsync 2.6.0 |
Debian 3.0 | rsync 2.5.6 |
でもやっぱ実行途中で break すると shell ごとおかしくなるのは一緒なのね。
上の話で 2ch にダイブしてて見つけた。ちょっと使ってみよう。
……。cat は日本語が出るが less や lv では化ける。Emacs では ok. なんか設定が足りない感じ。rxvt-j のように行間を確保してくれないので詰まりまくり。情報量は増えるがちょっときついかなぁ。行間設定できるようになったりするとすげー嬉しいが。。。
地味に期待。
※ その後掲示板で確認したところ、jis を表示できないためと判明。jless は基本的に jis 系のコードしか出力できないので、このままでは使えない。lv の場合は出力オプションを指定してビュワーとして起動すれば問題ないことを確認した。
※ jless の設定で euc-jp を吐くようにしても対処可能。
FDclone はとにかくインストール手順がかったるい。./configure 使えないし、machine.h とか config.h 読めとか言うし。まぁメジャーなフリー OS の場合は何も考えずに make; make install で ok なんだけど、それがドキュメントのあとの方に書いてあったりするのがまたどうも。
2.04c で Cygwin に対応したというので make してみたが select(): Bad file descriptor でうんともすんとも。期待したらいかんか。
from http://pc5.2ch.net/test/read.cgi/sec/1081426213/4
保全コピペ
Q.updateフォルダにあるファイル消していい?
A.avg6info.ctfと最新のアップデータ以外は削除してもok
Q.自動アップデートできない(繋がらない、重いetc)
A.後日行うか、手動アップデート
Q.手動アップデートの仕方は?
A.ttp://www.grisoft.com/us/us_updt6.php?avg6=fe
上のサイトからAVG Free Edition Update Fileを落として
Program Files/grisoft/AVG6/UPDATEに置いて
タスクトレイからRun AVG Anti Virusか、スタートメニュー、プログラムからAVG 6.0 for Windows
自動でアップデートが開始されない場合は、メニューのService→Update→Form a folder
Q.駆除できないんだけど?
A.隔離は出来るが、駆除は出来ない
無償ウイルス駆除ツールは、コチラ↓
Symantec
ttp://www.symantec.com/region/jp/sarcj/tools.list.html
Trendmicro
ttp://www.trendmicro.com/jp/security/tool/overview.htm
Grisoft
ttp://www.grisoft.com/us/us_ts_removers.php
基本的には AVG の update フォルダ内に *.bin ファイルを突っ込んで Control Center とか立ち上げると自動的に内容を読み取ってアップデートを始めてくれる。
現時点(2004-05)で、AVG 6 は2回大きなアップデートが加わっている。差し当たり
http://free.grisoft.cz/softw/60/fe/ から
- d6032lhj.bin
- u61540k0.bin
を落としておいて、アップデートするとよい。ナローバンド環境でインストール際に使える。……と思ったらアップデート済みのバイナリがここにあんじゃん。がーん。
url.ini を書き換えればローカルに update 用のサーバを用意するのも不可能じゃないな。