2012-02-12

rbenvで複数バージョンのRubyを切り替える。

Ruby 読書

勉強用の環境に入ってるRubyが、以前、Redmineを入れたときの都合でRuby Enterprise EditionというカスタマイズされたRuby 1.8になっていた。

$ ruby -v
ruby 1.8.7 (2011-02-18 patchlevel 334) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2011.03

Redmineは試しに入れたままほぼ触っていないが、動作環境を壊すのも避けたいので、複数バージョンのRubyを切り替えて仕組みを入れてみた。

以前は「rvm」という名前を見かけたが、速さや使い勝手から最近は「rbenv」が人気なようなので今回はそちらを試す。

rbenvのインストール

githubで公開されているレポジトリを複製（clone）する。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

.bash_profileを編集

ログイン時に~/.rbenv/binにパスを通し、rbenvの初期化らしき処理を実行させる。

export PATH="$HOME/.rbenv/bin:$PATH:$HOME/bin"
eval "$(rbenv init -)"

※ 個人的に$HOME/binにもパスを通してるがこれは必須ではない。

rbenv-buildのインストール

任意のバージョンのRubyをビルドするrbenv-buildというのも入れる。
/usr/local/share/ruby-buildを作ろうとしてエラーになったのでsudoをかけたけど、ウェブで見かける情報だと一般ユーザのまま実行している例が多い。どういうことだろう？

$ cd
$ git clone git://github.com/sstephenson/ruby-build.git
$ sudo ./install.sh

rbenvを使ってRubyをインストール

http://www.ruby-lang.org/ja/downloads/に記載された1.8系と1.9系の最新の安定版を入れてみる。

$ rbenv install 1.9.3-p0
$ rbenv install 1.8.7-p357

安いVPSだからなのかインストールには数分かかった。インストールが終わったら下記の操作が必要らしい。

$rbenv rehash

インストール済みのバージョン一覧を見るとちゃんと追加されているのがわかる。

$ rbenv versions
  1.9.3-p0
  1.8.7-p357

Rubyのバージョンを切り替える。

rubyと打ったときに実行されるバージョンを切り替えるには下記のようにする。

$ rbenv global 1.9.3-p0

現在設定されているバージョンを確認する。

$ rbenv version
1.9.3-p0 (set by /home/keme/.rbenv/version)

特定ディレクトリ以下で使うRubyのバージョンを指定する。

また、ディレクトリを指定してバージョンを切り替えられるらしい。ナニソレスゴイ！

$ mkdir use_1.8
$ cd use_1.8/
$ rbenv local 1.8.7-p357

rbenvによるバージョン指定が有効な状態でバージョン一覧を表示させると使っているバージョンに*が付く。

$ rbenv versions
∗ 1.8.7-p357 (set by /home/keme/use_1.8/.rbenv-version)
  1.9.3-p0

サブディレクトリを掘るとそこもちゃんと指定したバージョンになっている。

$ mkdir sub
$ cd sub/
$ ruby -v
ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

rbenv globalを実行したディレクトリにはバージョンを示すドットファイルが作られていた。どういう仕組みなんだろ？

$ cat .rbenv-version
1.8.7-p357

一時的にRubyのバージョンを切り替える。

一時的にバージョンを切り替える場合にはrbenv shellを使う。

$ rbenv shell 1.9.3-p0

このrbenv shellの効力はrbenv localより強いらしい。shell ＞ local ＞ globalでいいのかな？

$ cd use_1.8/
$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]

ちゃんと仕組みは調べていないけど、シェル変数RBENV_VERSIONにバージョン情報を持たせていたので、試しにその変数を削除したらrbenv shellの効果が消えた。

$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
$ unset RBENV_VERSION
$ ruby -v
ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

"ruby"と打った時にドットファイルやシェル変数を見て実行するバイナリを切り替えてるようなので、高頻度で実行されるような場面ではオーバーヘッドがどの程度出るのか気になった。

ただ、コマンドの数も少ないし、動きもわかりやすいので普通に使う分には便利だわー

2012-02-10

「初めてのRuby」 2章配列とハッシュ ※今日は配列

Ruby 読書

2.1.1 配列の構築

配列は数字オブジェクトや文字オブジェクトへの参照を順に詰められるコンテナ。
要素を並べて作るときはPerlの()（丸括弧）とは異なり、[]（角括弧）を使う（無名の配列を作るときと同じ）

さくらVPSの上で対話インタフェースのirbを使ってみた。

$ irb
irb(main):001:0> str = "hoge"　#=>文字オブジェクトを用意
=> "hoge"
irb(main):002:0> num = 123     #=>数字オブジェクトを用意
=> 123
irb(main):003:0> p hako = [str, num] #=>並べて配列を作成
["hoge", 123]
=> nil
irb(main):004:0> str[2] = 'm'  #=>元の文字列オブジェクトを変更
=> "m"
irb(main):005:0> p hako        #=>参照だから反映される！
["home", 123]
=> nil
irb(main):006:0> num += 10     #=>数字も変えてみる。
=> 133
irb(main):007:0> p hako        #=>あれ？ｗ
["home", 123]
=> nil

おや、+=を使うと別のオブジェクトが複製されちゃうのかな？演算子の説明に期待。
ちなみにPerlでも標準入力を渡せば対話インタフェース風にはなる（親切ではないけどｗ）

$ perl
my $str = "hoge";
my $num = 123;
my @hako = ($str, $num);
print @hako;
(Ctrl-dを押下)
hoge123

2.1.2 添字参照

...（三点リーダじゃないよ！）はタイポじゃなくて"末尾を含まない"の意味。

irb(main):001:0> hako = ["a", "b", "c", "d"]
=> ["a", "b", "c", "d"]
irb(main):002:0> p hako[0...2]
["a", "b"]
=> nil

Perlで試したらこうなった。許されるのか（汗

my @list = ("a", "b", "c", "d");
print $list[0...2]; #=>b

そして配列もオブジェクトなので、見た目は他の言語と同じように操作してるけど実はArray#[]メソッドの別表記とのこと。

irb(main):001:0> hako = ["a", "b", "c", "d"]
=> ["a", "b", "c", "d"]
irb(main):002:0> p hako.[](0..2)
["a", "b", "c"]
=> nil

2.1.3 添字代入

代入の範囲に対して要素数が足りないと配列が短くなる。

irb(main):001:0> hako = ["a", "b", "c", "d"]
=> ["a", "b", "c", "d"]
irb(main):002:0> hako[0..2] = "x"
=> "x"
irb(main):003:0> p hako
["x", "d"]
=> nil

Perlだとこうなった。どういう動きなんだ・・・

my @list = ("a", "b", "c", "d");
$list[0..2] = "x";
print @list; #=>axcd

2.1.5 様々なメソッド

ソートと重複削除もメソッド。これ気に入った！

irb(main):001:0> hako = ["A", "z", "@", "a", "Z", "a"]
=> ["A", "z", "@", "a", "Z", "a"]
irb(main):002:0> p hako.sort
["@", "A", "Z", "a", "a", "z"]
=> nil
irb(main):003:0> p hako.uniq
["A", "z", "@", "a", "Z"]
=> nil

↑はソートや重複削除をかけた新しい配列オブジェクトを返してて、hako.uniq!みたいに"!"を付けると元の配列オブジェクトが書き換わる。

2.1.6 ブロック付きメソッドとイテレータ

Perlで言うところのforeachやmapを書くにもメソッドがある。

irb(main):001:0> hako = ["A", "z", "@", "a", "Z", "a"]
=> ["A", "z", "@", "a", "Z", "a"]
irb(main):002:0> hako.each do |nakami|
irb(main):003:1*   print nakami + " "
irb(main):004:1> end
A z @ a Z a => ["A", "z", "@", "a", "Z", "a"]

do ～ endを{ ～ }だと思えば割りと自然に読めるかも。個人的にはif～fiよりは好きだｗ

doと波括弧

実は他の言語でよくある{ ～ }も使えるけどdo ～ endとは結合強度が違うとのこと。
処理を目立たせるために両者を使い分けると言うベストプラクティス的な提案の記述も。

眠いからハッシュは明日にしよう。。

2012-02-09

「初めてのRuby」 1章ようこそ、Rubyのある生活へ

Ruby 読書

1.1.1 オブジェクト指向言語

Rubyではなんでもかんでもオブジェクトらしい。

1             #=>ぱっと見ただの数字だけどFixnumクラスから生成された"1"って名前のオブジェクトらしい。
str = "hoge"
str.object_id #=>オブジェクトごとに固有IDが取れる。Perlでオブジェクトの比較って考えたことないかも・・・
str.class     #=>所属クラスを調べる。

1.1.3 動く擬似コード

言語固有の記述が少なくてコード例にも向いてるらしい。

実はデザインパターンをつまみ食いや真似じゃなく、ちゃんと本で勉強しようと思いつつも、サンプルがJavaばかり選びかねていたときに「Rubyによるデザインパターン」を見つけたのもRubyに手を出したモチベーションの一つ。

1.1.4 ALGOLの皮をかぶったLisp

ALGOLもLispもわからんよ・・・でもRakeはMakefileに代わる～みたいな文脈で一時期見かけたな。ああいうのをDSLと呼ぶのか。

メタプログラミングは必要に迫られたことが無いからわからないが、「メタプログラミングRuby」とかいう本になるぐらい奥が深いんだろうな、と思いつつ先へ進む。

1.2 処理系と実行環境

本のタイトルだから見かけた「JRuby」の"J"ってJavaのことだったんだ。なんとなくJapaneseかと思ってたよ。jvimみたいなｗ
とりあえず色々あるらしいことはわかったので当面はMRIのことだけ考える。

1.2.1 バージョン体系

http://www.ruby-lang.org/ja/を見に行ったら去年の10月末に1.9.3の正式版が出てた。もう流れは1.9系とみていいのかな？

1.2.2 構成

使いたい機能を探すコツについて書いてあった。こういうの助かる。
RubyGemsってのはCPANみたいなものらしい。

1.3 実行モデル

実行されるまでの過程の説明。知ってるとデバッグのヒントになりそう。Perlのここへんよく知らないや（汗

1.4.2 対話的実行環境

1～3行程度を試すのにちょうどいいかも。行数増えたらエディタのハイライトに頼りたいがｗ

ただ、それ以前にまだRubyの実行環境を用意してないという・・・

1.4.3 コマンドライン・デバッガ

デバッガって普段あんま使わないんだよなぁ。これを機にちゃんと使ってみようかな・・？

riコマンド

perldoc的なものらしい。本にすると凶器になるぐらい厚かったりするのかな？ｗ
http://www.ruby-lang.org/ja/documentation/との関係がよくわからないけど、ウェブには日本語のドキュメントも多そう（助かる）

1.5.1 式と区切り

行末の;(セミコロン)は不要らしい。普段のPerlコードも基本的に１行１処理で書いてるから正直必須ではないなぁ、と思っていたところ。

1.5.4 制御式

{}(波括弧)の代わりにendで閉じる。視覚的にスコープを掴みづらそうだけどちゃんとインデントしてれば慣れの問題？

型変換

オブジェクトの型は勝手に変わらないけど変数には型が無いらしい。初めてPerl触ったときはここら辺がルーズで驚いたな。
しかし、だとすると下記で文字列型の"123"オブジェクトを代入されてるのはstrって名前の変数？でもstr.classってメソッド呼べるよね・・・

num = "123"
num  num.to_i

1.5.5 ブロック付きメソッド

foreach的なものもメソッドが用意されてるらしい。CとPerlぐらいしか触ってこなかったら結構新鮮！

メソッド命の表記法

インスタンスメソッドとクラスメソッドの表記。これで最初にコード見たときに比べるとちょっと読めるようになったかも？

リソース管理

ファイル操作のopenとcloseの区間を{}のブロックで書けるらしい。でも「ファイルAを開いてファイルBから得た情報を入れる」とかどうするんだろ。。

ざっくりとした機能紹介の章だったので、疑問点なんかもこの先で明らかになるんじゃないかと。

ところでエントリーに[Ruby]とか[読書]ってタグ付けるにはどうしたらいいんだろう。

あと、コードをハイライトして貼る方法も調べないと。

2012-01-28

エンジニアサポート新年会2012 CROSSに行ってきた！

勉強会

f:id:KeME:20120128014811j:plain

今の仕事からは業界は近いようでスキルセット的にはちょっと遠く、だけどここ最近気になってしょうがない「Webサービス」側の人たち向けに大規模なイベントがあると聞き参加してきた。

仕事でWebの技術的な課題を抱えている訳ではないので、セッションの内容ではなく感じたことを感覚が鮮明なうちに記録しておこうと思う。

次世代LAMP CROSS

セミナーセッション次世代LAMP CROSS これからのWebアプリケーション開発

近頃、自分でWebサービスを作ってみたい欲に駆られつつも、LAMPどうこう以前にWebアプリケーションを作ったことが無いので、「どうせならイマドキな感じを経験したいな」と思い参加してみた。

期待通りNode.jsやMongoDB、Coffee Scriptの良さや懸念などをたくさん聞くことができたが、それを上回るといってもいい収穫があって・・・

「この人たち、変化することに躊躇が全然ない。すげぇ・・・」

日々の仕事ではWebUIを持たないPerlスクリプトを書いてることもあり、何かWebサービスを作るなら漠然とPerlかなぁ、と思っていた。そう、「多少なりとも慣れている」という一点が先行していて、名村さん（@snamura）の話していたアメーバピグでNode.jsとMongoDBを採用した経緯にあったような「目的を達成するには何を使えばいいか？」という基準ではない。また、個人的な勉強と見ても、この先のWebサービスの変化を意識して他の技術と比較したか、というとそれも無い。

また、今書いていて私が就職活動をしていた2005年頃には「Javaをやっておけば食いっぱぐれない」なんてことも一部では言われていたことを思い出した。（今もそういうのあるのかな？）

これらはいずれも「慣れた道具で何でも片付けたい」「新しく憶えるのは大変だし・・・」という、過激なほどに技術進歩が早いこの業界には馴染まない考え方だ。しかし、ふと油断すると簡単に陥ってしまう。なんといっても楽だから。

また、伊藤さん（@naoya_ito）が言っていた「新しい技術（イベント駆動など）はまずコミュニティが盛り上がっている新しい言語で実装される。Rubyが盛り上がってきた時にPerlを使っていて出遅れを感じた。」（意訳）という話が印象的だった。この話が十年以上にわたってPerlで誰もが知ってるWebサービスを作ってきた伊藤さんから出たことは軽いショックでもあり、同時に最近グッときた下記のエントリーと同様に"技術をキャッチアップしていくコツ"を教わった気がした。

"プライドに傷がつくことは、山頂からの景色を眺めるためであれば取るに足らない" - naoyaの寿司ブログ

LT大会

パーティーセッション大宴会+LT大会

えーと、こっちは酔ってて色々面白い感じでした。以上！

そうそう、最近刺さった下記のスライドも含め特徴的なスライドを書いてる塩谷さん（@kwappa）の生トークを始めて見れた！予想通り面白い感じだったので来月のデブサミ2012も楽しみです。

お前の芝生は青い

2011-10-18

初参加！YAPC::Asia Tokyo 2011参加したら元気出た！

Perl イベント

10/14(金),15(土)と東工大大岡山キャンパスで行われた「YAPC::Asia Tokyo 2011」(http://yapcasia.org/2011/) に参加してきました。

忘れてしまわないうちに二日間の興奮や後悔や反省をまるっと記録しておきます。

■印象に残ったトーク
移動が間に合わなかったり、時間が重なったりで断念したものもあったけど、印象に残ったトークをざっくりと。

Jesse Vincentさん「Perl 5.16 and beyond」
- 現役バリバリで活躍中のPerl5を開発しているマネージャーさん。
- 既存のコードを殺すことなく、"Perl5"としての進化を続けていく姿勢が頼もしい！
Dan Kogaiさん「A Language for getting the job done」
- 自分たちの成果をオープンソースとして公開しつつも収益を上げるスタイルが形になってきた？という話。
- ソースを公開することで業界の資源を豊かにし、コミュニケーションを増やし、人材も育つ。そんな好循環を感じた。
徳丸浩さん「Webアプリでパスワード保護はどこまでやればいいか」
- PSNの漏洩事件も、GPUを使ったパスワード解析もまだ記憶に新しくタイムリー。
- 仕組みの解説から実装例、実演と展開していて大変わかりやすい。
- PHPのサンプルコードを晒した上でちゃんとPerlに書き換えてきてるおちゃめっぷりｗ
FUJIWARA Shunichiroさん「Perlで構築された中規模サイトのDC引っ越し記録」
- ISUCONで優勝した藤原さん(@fujiwara)の考察〜調査、実行の過程が聞けた。これは貴重。
techno-catさん「perl meets beats」
- Perlでwav形式ファイルをバイナリのレベルで生成！？
- さらにシンセ相当の処理を実装して音色を作りGroove感まで。。
- 最後にはハウスやツーステップを披露した上で「こんな楽器、面倒で使えないですよね」と落とすという展開ｗ
hakobeさん「Enhance Anime wathing with programing」
- 人力更新のアニメ情報DB(カレンダー？)にAPIを介してアクセスするライブラリの紹介
- アニメ鑑賞はライフワークだ！と言わんばかりのトークが熱い！たぶん全LTで一番笑ったｗ
masahiro naganoさん「運用しやすいWebアプリケーションの構築方法」
- Opsにおけるトラブルシュートの実例と、Devが考えるべき運用を視野に入れた実装の話。
- 既存モジュールの足りない部分を的確に分析し、自作モジュールで補うという実装力。
- サービスの作り方や調査から実例、改善方法、結果とまとまっていて大変勉強になった。
aloelightさん「少人数でのWebアプリ開発 - CGIからPSGIまでの変遷」
- Webアプリケーションの開発環境や体制、手法をどう変えていったかという実体験の話。
- バージョニングやタスク管理、開発環境、DevOps、テストなどを少しずつ改善。
- 派手さやマニアックさは無いけど、最もリアリティがあり勇気付けられる内容だった。
- 初めてYAPCに参加したときの「みんな情報収集凄いしアウトプットもしてる」「俺、やばい（汗」がまさに今年の自分！！
Yappoさん「folkatdevs」
- 社内の様子を観察してちょっとしたツールを作り改善していく話。
- うちの職場ではこういうのノリ無くなってしまったなぁ。。
Naoki Tomitaさん「This session is funny modules」
- CPANモジュール本の冨田さん(@tomita)
- ヘビーCPANウォッチャーが見つけたネタモジュールの紹介。しゃべりうまいｗ
tokuhiromさん「File::Zglob」
- zglob('lib/**/*.pm')形式でfindできちゃうモジュールの話。
- でも、怒涛の20モジュール紹介の方がネタ満載でインパクトありすぎたｗ
TAKESAKOさん「Perlで無理ゲー攻略2」
- 凄まじい速度でマインスイーパーを解くAcme::MineChan(まいんちゃん)恐るべし。。
Hideo Kimuraさん「Managing A Band Of Hackers」
- 基調講演。Perl Hacker集団を率いる@hidekさんによるマネージメントの話。
- ダイソンばりの人材吸引力を誇るDeNAの力は垣間見た。。

ちょっとのつもりが結構な量になってしまった。いっぱい聞いたなー

■いい意味で裏切られたこと
YAPC::Asia Tokyoのことを知ったのは２年前。初参加のYAPCは想像と違って・・・

「Perlのお祭り」って言ってたのに何でもアリだった！
- Perlそのものの話、モジュールの話、DevOpsや現場の話、オープンソースの話、マネージメントの話、etc
Lightning Talkは何でもアリってレベルじゃなかったｗｗ
- 勉強になったり、励まされたり、爆笑したり、etc
有名Perl Hackerがいっぱい！
- いつもTwitterのTLを賑わす彼らが目の前に！ミーハーな俺歓喜！！

■後悔したこと/来年に向けて
ガチガチに力入れて参加する空気じゃなかったけどやり残したことはあって・・・

スピーカーや参加者と話す機会を作れなかった。
- 前夜祭も懇親会も都合をつけられなかったのが無念。。
- ２日目に王将で案内待ち中に偶然居合わせたすぎゃーんさん(@sugyan)に話かけたのが唯一の会話。
  - やたら緊張してしまった上にすんなり席に案内されちゃってちょっとしか話せなかったorz
- 「エクストリームくしいさん握手の会場に向かう！」とかツイートしたのに櫛井さん(@941)さんと握手してない。
  - 「行ってきたシリーズ見てます！」とか「炎のつけ麺、結構辛いですねｗ」とか言えば良かったorz

(YAPCに限らず)次回に向けて
- 会話のネタを作る！！
  - 緊張もするけど会話のネタが尽きる恐怖感が結構大きい。
  - 仕事で会話のネタが作れないのならプライベートで作ればいいのかも？
  - 会話のネタとして狙って取り組むんじゃなくて、興味持ったらすぐに手を動かすようにしたい。
  - できれば相手も知ってる知識じゃなくて、相手の役に立つ知識を！
- 基礎をちゃんと！
  - 実はリャマ本をざっくり、アルパカ本とPerlベストプラクティスをパラパラとしか読んでない（汗
  - ↑をちゃんと消化したらラクダ本も買ってみる。
  - パターン化した仕事のソースだけじゃなくて、githubとかでもっと色んな人のソース見てみたい。
- 職場の年齢分布もあって「好きでエンジニアやってる同年代」と話したいなー
  - ちなみに今年度で29歳なんで±1ぐらい？

■最後に
開催を支えてくださった皆様、スピーカーの皆様、ありがとうございました！！

2011-06-27

DevOpsカンファレンスの感想とか。

6/27(金)にサイバーエージェント株式会社のでっかい会議室で開催された「第1回 DevOpsカンファレンス」に参加してきました。

「Developers Summit 2011」に参加したとき、直後の感想やら関心所、モチベーションの高ぶりなどをちゃんと文字にして残しておかなかったことを後悔したので書いてみます。

■参加する前に考えてたこと
見つけて「やばい、面白そう！」と盛り上がったときに考えていたこと。

自分がDevなのか、Opsなのかわからない？
- 数年にわたってほぼ同じシステムを見てきました。（たまに他のも見るけど）
- データセンターにはほぼ行かず、物理的にサーバやNW機器を触ることはほとんど無い。
  - 障害になればNW構成図見て、トラフィックやリソース確認して、OSのログ見て、プロセス見て…はする。
  - 半端過ぎて「ネットワークエンジニアとかサーバエンジニアは名乗れんよなぁ」と思ってたり。。
- 外部システムとの連携部分の改修や、調査・メンテ用にプログラムは書くけど規模は小さめ。
  - こっちも半端過ぎて「プログラマは名乗れんよなぁ」と思ってたり。。

カンファレンスの宿題
- 長くDevとOpsの境界が曖昧だったので「DevとOpsの関係（対立！？」にあまり興味は無かった。
  - でも、参加してみたら一番の思うところが多かった。
- 「ツール！とにかくどんなツールをどう使ってるのか知りたい！」
  - 割と自前ツールでまかなっている部分を、イマドキなツールではどう実現できるのかな？とか。
  - 長く運用しているシステムでツールの新規導入や置き換えは難しいのかな？とか。
  - 対象は、デプロイ支援とかサーバ構成管理、ナレッジベース、課題管理、などなど。

勉強会への参加は２回目
- 恐らく大多数を占めるであろう「Webサービス屋さん」ではないアウェー感に((((；ﾟДﾟ)))ｶﾞｸﾌﾞﾙ
- DevもOpsも名乗るに半端が故に((((；ﾟДﾟ)))ｶﾞｸﾌﾞﾙ
- 初参加の「懇親会」でぼっちになるんじゃないかと((((；ﾟДﾟ)))ｶﾞｸﾌﾞﾙ
  - 参加前にTogetter - 「ぼっちが懇親会でするべき97のこと」を見てたｗ

■参加中に思ったこと
内容はSlideShareにもあるし、他の参加された方も書いてるので感想を中心に。

発表された各社の運用体制やポリシーが（いい意味で）バラバラ。
- 色んな試みの成果や課題を見れた！とてもお得！！
「とにかく早く機能をリリースする＞時間をかけてテストする」という考え方。
- ターゲット次第ではこういう考え方もありだな、と思った。
「サーバ数：スタッフ数」が結構ヘビーなバランスにあるとこが多い？
- 上位のアプリケーションも作り込んでて見る範囲も広いのに凄い。。
運用を外部に出した弊害から再び自社運用に切り替えた。
- 「原因追求が甘くなる」「ノウハウが蓄積されない」「当事者意識が下がる」…あれ、耳が痛いぞ
- 大号令で切り替えた、という思い切った判断が凄い。
どうしても24/365には泥臭い対応は付いてくるよね。
- 夜中に、出先で、ピークが来ると、過ぎ去るのを耐えて待つことも、などなど
- 「（週末を挟んで）２日間落ちていても大丈夫な構成にする」は非常にシンプルで明確だと思った。
一時切り分けがDevsの責任者に！？
- 兼務体制では経験あるけど、分業しててこれは新しい！
- 分業体制が時間経過や人の入れ替わりで"隔たり"を生み出すのを止める杭のような効果もありそう。
スタッフ間の何気ない情報共有が大事かも。
- メールはちょっと"硬い"よね。IRCとか使う文化が無かったけどありだと思った。
- DevとOpsが互いに"人"と意識できる環境が大事。
NagiosやZabbixで管理しているホスト数や監視項目が思っていたより多い。
- 規模的には使えそうだけど監視サーバの負荷軽減とか蓄積データの扱いは工夫が必要そう。
- ただし、何を選んでも閾値やアラート通知のチューニングは悩ましい。
笑い大事！
- 発表を聞いてて飽きない。印象に残る。
- 「年中障害対応とかしてて奥様の反応は…」の回答が面白かったｗ
懇親会おもろー！
- 職場に必ずいる「技術大好き！」「交流大好き！」な人がごそっと集まった感じ。

■参加して変わったこと/この先のこと
まとめ・・・なのかな？わからないｗ

以前からDevを強めていきたいと考えてはいるけど…
- Opsが全く無くなったら不安だったり、寂しかったりしてしまいそう。
- Devsが知っているべきOpsの領域が、全然カバーできていないと自覚した。
DevとOpsの隔たりが小さい環境を経験できて良かった！
- 今回のカンファレンスでその良さに気づけた。
- 規模が大きくなって分業化が進むのは仕方ないけど、DevOpsな意識があるか無いかは非常に大きい。
勉強会いいなー
- 知りたいことを予め考えておく。
- 印象に残ったことは記録しておく。"感じたこと"も大事。
- エクストリーム参加申し込みでも挫けないｗ
- 今度はもっと色んな人と話したい。
- いつかはネタを作って発表したいなー
- 次はShibuya Perl Mongersテクニカルトーク#16に参加予定（まだ補欠）

思うところはいくらでも書けそうなのでここら辺で。

開催を支えてくださった皆様、発表者の方々、懇親会で話していただいた方、ありがとうございました！

2010-11-26

Acrobatは持っていないけど、Kindle3でさくさく読める綺麗なPDFを作りたい！

自炊 Kindle

（このエントリーは別アカウントで書いた元記事に重要な「追加２」を加えた修正版です。）

長年積み続けた本をKindleで見るため、ドキュメントスキャナを購入した。

Canon ドキュメントスキャナ― imageFORMULA DR-150 A4対応 CISセンサー読取速度A4カラー10枚/分,A4白黒15枚/分給紙枚数20枚 USBバスパワー駆動ソフトウェア内蔵スタイリッシュ&コンパクトモデル

出版社/メーカー: キヤノン
発売日: 2009/10/16
メディア: Personal Computers
購入: 18人クリック: 166回
この商品を含むブログ (43件) を見る

スキャナそのものは場所もとらず、非常に快適に使えているのですが、「Kindleで表示が速く(≒サイズが小さい)、それなりに見やすいPDFファイル」を作ろうとすると、付属の「CaptureOnTouch」や「PaperPort 11」ではどうにも足りない。。

自炊した電子書籍（PDF）を iPad でサクサク表示する方法（サンプル動画あり） - 彼女からは、おいちゃんと呼ばれています

模索している際に上記のエントリーを見つけ「Adobe Acrobat付きの製品にしとけば（ＴＴ」と思ったが、Adobe Acrobatは単体で買うには高すぎるので、快適なOCRソフトを求めて下記の３製品の体験版を試してみました。

e.Typist Ver.13.0	読んde!!ココ Ver.13	読取革命 Ver.14

検証の素材には、ページ構成や図表の数が異なるものがよかろうと思い、手元にあった下記の技術書と雑誌を使ってみました。

SAN&NASストレージネットワーク管理
- IT系技術書の定番O'Reilly
- B5変則版
- 数ページに１つ程度図があるだけで、ほとんどは白地に黒文字の文章。
- 検証では表紙を含む50ページ分を使用(24bitカラー14p, 256階調グレースケール36p)
- 気づいたら本棚にあった。
WEB+DB PRESS vol.56
- IT系技術雑誌
- B5版
- 図や挿絵、スクリーンショットも多く、コードが網掛けの上に載っていることも多い。
- 検証では表紙を含む100ページ分を使用(24bitカラー1p, 256階調グレースケール99p)
- 結構好き

スキャンやOCRソフトの設定は、色々模索した結果、下記のような感じに。

スキャンにはDR-150付属の「DR-150 CaptureOnTouch」を使用。
解像度は400dpiを使用。
カラーページは「16bitカラー」、単色ページは「256階調グレースケール」を選択。
スキャン結果はBMP画像として保存し、OCRソフトはこれを読み込み処理する。
画像修正は行わず「レイアウト抽出(自動)→OCR処理(自動)→PDF生成」のみ実施。

で、早速、上記の条件で「生成したPDFファイルのサイズ」を調べたところ、予想以上にOCRソフトや出力形式によりファイルサイズに差が表れました。

Kindle上でのページ送りもファイルサイズが小さいものほど早いです。

	元データ (BMP画像)	e.Typist PDF画像 (透明テキスト付き)	読取革命 PDF(透明文字)	読取革命 PDF(高圧縮)	読んde!!ココ PDF(透明テキスト)
(雑誌) WEB+DB PRESS vol.56	856 MB (50ページ)	9.89 MB	82.4 MB	20.0 MB	80.6 MB
(O'Reilly本) SAN&NAS ストレージネットワーク管理	1003.5 MB (100ページ)	12.0 MB	61.0 MB	14.6 MB	62.8 MB

上の結果を見ると生成する（PDFファイルのサイズで言えば）e.Typistが圧倒的なように見えますが、Kindleで見た場合、「表示の綺麗さ」においてPCやiPadとは異なる特徴があることに気づきました。

　※以降、ファイルサイズが２番目に小さかった読取革命との比較。

まず、元データとなるBMP画像の一部と、Acrobat Readerで400%まで拡大表示したPDFの該当部分を比べてみると・・・

元データ (BMP画像)
e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

見ての通り、どちらもファイルサイズを抑えるため画像圧縮により劣化しています。

しかし、e.Typistには「白地部分にJPEG画像に見られるようなノイズ」が見られるの対し、読取革命は「アンチエイリアスを消すような階調の削減」となっています。

バックライトに照らされた真っ白な液晶上で見てる分には「好みの問題」と言えるほどの差ですが、自ら発光しないe-inkを使っていてコントラストも弱いKindle上で見ると事情が変わってきます。

e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

　※横向き表示, fit-to-width.

写真ではちょっとわかりづらいかもしれませんが、e.Typistでは「白地のノイズが目立ち文字が読みづらい」のに対し、読取革命は「文字色が薄くなっているが形状の崩れはない」という状態です。

どうでしょう…読取革命で生成したPDFの方が見やすくないですか？

「PDFファイルのサイズ」と「Kindle上での表示の綺麗さ」という上記の検証の結果をまとめると・・・

	e.Typist	読取革命
PDFファイルサイズ	とても小さい (雑誌では圧倒的！)	小さい
文字の画像劣化	文字の周囲にJPEG風のノイズが発生する。	グレースケールの階調が減り、アンチエイリアスが消える。
Kindle上での表示	白地にノイズが目立つ。	文字色が薄くなるが文字の表示はくっきり！

という感じになるでしょうか。

ざっくりとまとめると「ファイルサイズのe.Typist」と「Kindleの縮小表示でも綺麗な読取革命」なので・・・

「まぁ、用途に合わせて好きの方使ったらいいよ！Acrobatも含めてね！」

ということで両者を持ち上げつつ強引にまとめてしまいます。ではでは。

（追記１）

上記ではあくまで文字の表示を対象に比較していましたが、

図表や網掛けなどでは文字をくっきり見せていた読取革命の処理が、

悪い方向に働いてしまうケースもあるようです。

e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

　※横向き表示, fit-to-width

上記は網掛けの濃淡が強調されてしまい、文字が見づらくなった例です。

e-inkのKindleではそれほど重要ではないかもしれませんが、

カラー印刷物を読取革命でPDF化すると色の階調落ちが目立つ印象です。

結局「用途に合わせて」なんですね。

以上、参考までに。

(おまけ)
「結局、お前はどっち買ったんだよ！」という点をスルーしていますが、実際に買ったのはe.Typist NEO(日英のみVer.)の方です。しかも、後半で書いている「Kindle上での表示の綺麗さ」に気づいたのは買った後！完全に後の祭！もちろんe.Typistも快適に使えてるけど、正直、気づけなかったのが悔しい！

と言うわけで、いきなりはてなダイアリー始め、誰かの参考になればと書いてみました。はてな記法に慣れておらずだいぶ手間取りましたが、また何か思いついたら書いてみたいと思います。

（追記２）

（移転前のダイアリーで）コメントいただき「e.TypistのMRC圧縮」(高圧縮PDF)を試したところ、今までの検証が無意味なぐらいの優秀な結果が出てしまいました（汗

何はともあれ結果からご覧ください。

最初にPDFのファイルサイズですが・・・

	元データ (BMP画像)	e.Typist 高圧縮PDF画像 (透明テキスト付き)	e.Typist PDF画像 (透明テキスト付き)	読取革命 PDF(透明文字)	読取革命 PDF(高圧縮)	読んde!!ココ PDF(透明テキスト)
(O'Reilly本) SAN&NAS ストレージネットワーク管理	1003.5 MB (100ページ)	9.19 MB	12.0 MB	61.0 MB	14.6 MB	62.8 MB

続いて文字(画像)の拡大・・・

元データ (BMP画像)
e.Typist 高圧縮PDF画像 (透明テキスト付き)
e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

Kindle上で文字を表示すると・・・

e.Typist 高圧縮PDF画像 (透明テキスト付き)
e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

同じくKindle上で網掛を含む部分を表示すると・・・

e.Typist 高圧縮PDF画像 (透明テキスト付き)
e.Typist PDF画像 (透明テキスト付き)
読取革命 PDF(高圧縮)

以上のように検証した中で最小のファイルサイズを誇りながらも、

読取革命のような階調を削減する圧縮処理のためKindle上でも見やすい。

さらに懸念された網掛や図表への悪影響も非常に小さい。

正直なところ、よく調べずにe.Typist買ったけど後悔せずに済みそうですｗ

ただ、良いところばかりでもあれなのでe.Typistを使っていて嵌った点も軽くご報告。

500ページ以上のファイルを処理できない
（フリーのPDF結合ソフトを併用しています）
ソースコードなど網掛上の文字の認識精度はかなり残念
（Acrobatで作られたPDFと比べると差は歴然）
処理中に元ファイルに匹敵するサイズの一時ファイルを作るらしくたまに容量不足に（汗

もしかしたら上記についても解決策があるかもしれません。

また、扱う画像データ(本、漫画、写真集、etc)や閲覧環境(PC,e-ink端末,タブレット,etc)によって、

今回の検証とはまた違ったメリット・デメリットが出てくると思います。

なので、買う前に試用することを強く推奨します！

追記が続いて見づらい構成になってしまいましたが、最後まで読んで頂きありがとうございました。