最近はtmuxを使っています。
長いことscreenを使っていましたが、依存するほど使いこなしてもいなかったので好奇心でtmuxに乗り換えてみました。
とりあえず使ってて気になった部分から設定を書き足していって、開発環境用と本番環境用の配色が落ち着いたのでメモ。
- Prefixキーはvimと干渉せず、bashのstop(出力停止)も使わないのでC-sに変更。
- ちゃんと.bashrcに「stty stop undef」を設定して無効化するべきか・・・
- 配色は「黒＋カラー」の2色で、開発環境（地味）と本番環境（派手）で反転風に。
- カラーはcyan以外にも、サービス別にred, greenなど使い分けてます。
- ワイドディスプレイを使っていないのでペインは生かしきれずだいぶ適当（汗
開発環境（地味なステータスバー）
~/.tmux.conf
# change Prefix set -g prefix C-s unbind C-b # enable UTF-8 setw -g utf8 on # Copy-and-Past keys setw -g mode-keys vi # History set -g history-limit 5000 # reload config bind r source-file ~/.tmux.conf # make pane bind h split-window -v bind v split-window -h # Panes to Windows bind b break-pane ##### status bar design ##### # Base set -g status-interval 5 set -g status-fg cyan set -g status-bg black set -g status-attr bold # Left : like `hostname -s` set -g status-left-length 16 set -g status-left '#[fg=white]#h#[default]' # Right : [2012/05/12(Sat) 02:18] set -g status-right '#[fg=white][%Y/%m/%d(%a) %H:%M]#[default]' # Windows setw -g window-status-fg cyan setw -g window-status-bg black setw -g window-status-attr none setw -g window-status-current-fg cyan setw -g window-status-current-bg black setw -g window-status-current-attr underscore
本番環境（派手なステータスバー）
~/.tmux.conf （配色設定の差分のみ）
##### status bar design ##### # Base set -g status-interval 5 set -g status-fg black set -g status-bg cyan set -g status-attr bold # Left : like `hostname -s` set -g status-left-length 16 set -g status-left '#[fg=black,nobright]#h#[default]' # Right : [2012/05/12(Sat) 02:18] set -g status-right '#[fg=black,nobright][%Y/%m/%d(%a) %H:%M]#[default]' # Windows setw -g window-status-fg black setw -g window-status-bg cyan setw -g window-status-attr dim setw -g window-status-current-fg cyan setw -g window-status-current-bg black setw -g window-status-current-attr underscore
YAPC::ASIA Tokyo 2012に行ってきた。
各トークの内容はスライドや動画が上がると思うので、記憶が新しいうちに感想をまとめてみました。
0日目(前夜祭)
- Officeで使うPerl Excel編（risouさん）
MS-Officeの生成物は不透明でとっつき辛い印象だっただけに、手軽に操作する手段があったことが衝撃。「うわ、TSVにでもしてLinux環境で処理してぇ。。」的なExcel作業が舞い込んだ時のために是非憶えておきたい。
- UV - libuv binding for Perl（typesterさん）
Node.jsはおろかAnyEventも触ったことないけど、Node.jsと共に実績を作っているバックエンド部分を使っちゃおう！というアプローチはいいなぁ。
トークとは全く関係ないけど、先日、初めてJSON扱って数百個の $num =+ 0 を仕込み終えた直後にJSON::Typesがリリースされて衝撃的でした。是非使ってみたい。
- Sqale の裏側（mizzyさん）
レンサバにしろクラウドにしろ、自由度の高い環境を提供しつつ大量のユーザを収める技術って、一般のWebアプリには無い独特な部分が多かったりするだけに、リリース直後のサービスについてそういう部分を見せてしまうあたりに「囲い込まない文化」みたいなものを感じた。
1日目
- What Does Your Code Smell Like?（Perlのお父さん）
Rubyにあるような"何でもオブジェクト"的なスタイルや、function（関数指向？）を強調してのを聞いていて、「Perl6はPerl5がある（＝存続する）お陰で、自由で面白いものになりそうだなぁ」という印象を受けた。あと、片手でサクサク編集してて俺の使ってるVimと違う＞＜
# 英語わからんのでLarry Wallの伝えたかったことはたぶん汲み取れてないけどね。。
- Web::Security beyond HTML5（hasegawayosukeさん）
DevSumiと重複する部分も多かったんだけど、最近、慣れないJSを意識してサーバサイドを書いたこともあって、すごくリアリティのある内容だった（汗
動作環境をブラウザベンダーや利用者に握られてるクライアントサイドの苦労もひしひしと・・・
- リアルタイム通知システムの舞台裏（しんぺい@猫型技研さん）
スマホアプリとか扱ったことが無いんで新鮮な内容が多め。少しずつ欠点を潰していく過程（考え方）が説明されていて良かった。
- 大きくなったシステムの疎結合化への取り組み（星野さん）
自分で書いて自分で直していてもだんだんとコードベースの全体が掴めなくなっていく感覚があるだけに、長年Perlの会社として蓄積し、色んな人の手が入った資産ともなるとその複雑さは想像もできない感じ・・・。同規模の状況に直面する機会がこの先どれだけあるかはわからないけど、「計る」「特定する」「悪化させない」「改善する」のアプローチは憶えておきたい。
- GitHubを使った開発とデプロイ（まつけんさん）
Githubうんぬんの前にPerlぼっち開発から脱却できたストーリーが泣けた。ぼっちでもテスト書いてるって話してて素晴らしい。
- Distributed Job System. Clutch（nekokakさん）
JobQueueとMessageQueueの解説が勉強になった。毎度ながらnekokakさんのプロダクトは既存のものとの違い（特徴）がハッキリしていて面白い。
- 続・Mobage を支える技術（xaicronさん）
笑いすぎて肝心の内容が（ｒｙ というのは冗談で、XS使ったモジュールがシグナル受け取った時の挙動とか初めて知った。シグナル奥が深い。。
トークとは関係ないけど、API書いたりしててPerl Hackers Hubの記事などすごく参考にしてたので今期（ひっそりと）一番お世話になった感があります。
- スマートフォン向けサービスにおけるサーバサイド設計入門（hatacobaさん）
つい最近、平凡な要件ではあるけどミドルウェアの選定からWebAPIの設計まで一人で試行錯誤する機会があって、結果、知識・経験不足でどうにもレガシーから脱却できてない部分がたくさん残ってしまい、このトークはそういう背景もあって「あぁ、そういう手があるのかぁ」とすごく勉強になった。大規模な話やディープな話も勉強にはなるけど、こういう一人～少人数で全体を見て作っていく話は結構好き。
- 半リアルタイム・分散ストリーム処理をperlで（tagomoris）
指定時刻のログを処理する例を用いたリアルタイム処理のニーズの説明が大変わかりやすく、会場からの質問で答えていたPerlで機能特化の擬似エージェント（？）を作ることを選択した理由も考え方の参考になった。
- Lightning Talks Day 1
安心の爆笑くおりてぃでしたｗ
Furl気になる, お姉さん救ってて大変ジェントル, その一方でお姉さんが若干下ネタ, tunecoreはボカロPにもオススメみたい, etc
- 懇親会
いつもながら入り込める輪が無くてうろうろしてたけど、刺身さんと話すことができたのでリリースを見て思ってた「Sqaleのここがイケテル！」的なことを色々話したら、こういうプロダクトを出すに至った下地とか、個人的にどんなチャレンジがあったとか、色々聞けてなんだか意識が高まった。ありがとうございました！
2日目
- 「新しい」を生み出すためのWebアプリ開発とその周辺 （ゆーすけべーさん）
複数の切り口からこれから作るサービスを明確にする流れや、下手に飛びつかず技術の採用基準を設ける話が大変参考になった。
会場からの質問で答えてた、ぱっと見が似たサービスであっても、どこか目指すところが違っていることは多い、って話が良かった。なるほどなー
先人の知恵としてデザパタは勉強しないとなぁ、と思いつつ、使う予定のないJavaベースの情報が多くて手を付けていなかったので大変良かった。
言語そのものにも興味のある「Rubyによるデザインパターン」も買ってあるけど、これ読んだ後に普段使ってるPerlに適用する際には「モダンPerl入門」も読んでるみと良さそう。
Lean, Scrum, XPの範囲を階層化した図から入っていく流れがわかりやすく、「なんか流行ってるから試す」ではなく「この層にある課題を解決すべく○○を試す」という選択のヒントになった。
関わっていてターゲットがぼやけていくのを感じたり、関係者の頭の中に共通のコンセプトが無いことに悩むことは多いので、今回のYAPCの中ではあんちぽさんとゆーすけべーさんのトークが一番得るものが多かった気がする。
- Perl 今昔物語
後から入った自分には神話の時代の伝説のような出来事も、当時その場にいた人にとっては今と変わらない好奇心や楽しみが言動力だったんだなぁ。
YAPC::ASIAが始まった当時には無かった道具やサービスがある現在なら、今までに無かった"新たな場"は生まれていくだろうし、このタイミングでエンジニアやってるなら、傍から見てるのではなく少しでも関わっていけるといいなぁ、とぼんやり思う。
色々あってMyISAMに触れてた期間が長く、最近になってInnoDBを生DBIで使うようになって悩んでた部分のヒントが貰えた。
- ウェブアプリケーション開発の現状・課題とJSX（kazuhoさん）
JSはがっつり取り組んだわけではないけど、ブラウザ上の唯一の選択肢であるが故の「仕方ない部分」に切り込んでるのが素晴らしい。
あと、R&Dというポジションから見た分析結果が今回のYAPCでも希少な部類で興味深い。
個人的に関心の高い小～中規模におけるノウハウが得られた点も大きいが、時折語られた「関わるサービスを選ぶ上での葛藤」や「外から見た印象と実際に関わった感じたことのギャップ」も将来の参考になりそう。
- Lightning Talks Day 2
笑いとガチが入り乱れた混沌とした世界再び。一緒に行ったうちの新卒にもうけてたｗ
- How Perl Changed My Life（mizzyさん）
語り方に派手さは無いけれど、当時を振り返って「本当に良かった」という雰囲気が伝わってきた。色々な機会を得た背景が語られていたが、全てに共通するのは「実際に手を動かした」という点だと思う。
最後の方で「みなさんに取って自分を変えたきっかけは？」という問いがあったので考えてみると、エンジニアなった頃に出会った「目標にできるエンジニア（だいたいはPerl書く）」と「知恵の詰まった自社開発プロダクト（こっちもPerlいっぱい）」でした。
誕生祝いにクッキー作った話。
ふと思い立って誕生祝いにクッキーを作ってみました。
COOKPADを参考に3種類分のバター＋砂糖＋卵を作り、計り分けたら個別に混ぜ混ぜ（これはココア）
抹茶缶のプルトップが壊れるなどしつつ・・・
なんとか抹茶の生地も完成。
冷蔵庫で寝かせた後、170度のオーブンに入れること20分弱。
できたクマー！！（午前１時過ぎ）
と、みせかけて・・・
実はカエルでした！！！ ※ 型はクマです。
作り過ぎたので用意した箱に小細工して持って行きました。
＜大変だったこと＞
- 暑かったのでバターの生地はだいぶベトついた。（ココアと抹茶は平気でした）
- 配分の違う複数のレシピを参考にしつつ、さらに全体を2/3に調整していたので粉類を混ぜる前に電卓を叩くことに。
- デコペン（チョコのペン）は地味に難しい。
- 楽勝と思って晩御飯後に作り始めるたら深夜になったの巻。
- はてな記法を完全に忘れてたでござる。。（クッキー関係ない）
上記以外はサクサクできました。
ちなみに、参考にしたレシピはこちら。
http://cookpad.com/recipe/1625934
http://cookpad.com/recipe/421292
せっかくなのでCOOKPADのアカウントを作って「つくれぽ」を試してみました。
（表示は承認制みたいなのでそのうち載るかも？）
MySQLのSSLレプリケーションを試みるがSlave_IO_RunningがConnectingのまま変わらない。
下記の公式バイナリを使ってSSLレプリケーションを試みたら嵌った話。（解決済み）
mysql-5.5.24-linux2.6-x86_64.tar.gz
症状
もろもろの設定を終えてスレーブ側でSTART SLAVE
mysql> START SLAVE; Query OK, 0 rows affected (0.00 sec)
SHOW SLAVE STATUSで確認すると、Slave_IO_Running（★）が「Connecting」のまま変わらない・・・
mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Connecting to master Master_Host: xxx.xxx.xxx.xxx Master_User: slave_one Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 539 Relay_Log_File: hostname-relay-bin.000003 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Connecting ★ Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 255 Relay_Log_Space: 107 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Yes Master_SSL_CA_File: /path/to/ca.pem Master_SSL_CA_Path: Master_SSL_Cert: /path/to/server-cert.pem Master_SSL_Cipher: Master_SSL_Key: /path/to/server-key.pem Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 2026 Last_IO_Error: error connecting to master 'slave_user@xxx.xxx.xxx.xxx:3306' - retry-time: 60 retries: 86400 Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 0 1 row in set (0.00 sec)
mysqldのログを見るとマスターに接続できないとのエラーが出ている。
120531 24:00:00 [ERROR] Slave I/O: error connecting to master 'slave_user@xxx.xxx.xxx.xxx:3306' - retry-time: 60 retries: 86400, Error_code: 2026
原因が見えてこないので手動で接続しようとすると・・・ん？プロトコルのバージョンが合わない？
# mysql -u slave_user -p -h xxx.xxx.xxx.xxx --ssl-ca=/path/to/ca.pem \ --ssl-cert=/path/to/server-cert.pem --ssl-key=/path/to/server-key.pem Enter password: ERROR 2026 (HY000): SSL connection error: protocol version mismatch
解決
証明書を作成する際に使ったOpenSSLを 1.0.0 から 0.9.8e に変更したら直った。
「紙の本？電子書籍？」本を買うときに迷ったら（Kindle編）
自炊セット（裁断機＋ページスキャナ）を買って暫くはザクザクと手持ちの本をPDF化していましたが、最近はO'Reilly Japan Ebook Storeやオーム社eStore(β)、 達人出版会 など、自炊しなくても欲しい本がPDFで買える場が増えてきました。
しかし、自炊するにせよ電子版を買うにしろ、「あー、これは紙で読んだ方が良かったなぁ」と軽く後悔することもあります。
そこで今回は「電子書籍リーダーで読むに向いていない本（個人の感想です）」をまとめてみました。
※ 以下の内容は私の環境（Kindle 3）を使っていることが前提です。
本のサイズが大きい（＝1ページあたりの文字数が多い）
書籍の版が大きいとKindleの画面サイズに合わせたときに文字が小さくなります。
O'ReillyのB5変型版（ラクダ本など）は、Ebook Storeで買ったものであればなんとか読めますが、自炊した場合にはdot-by-dotや色の階調、PDF出力時の設定など、にじみを抑えパリッと表示する工夫を加えた方がよいと思います。
文字の背景色が真っ白ではない
背景色が白色以外になるとKindleでは極端に文字を識別しづらくなります。
Kindle上では16階調のグレースケールで表示されるので・・・
- ソースコードや設定ファイルが枠ではなく網掛けで表現されている。
- 構成図や概念図のオブジェクトがカラー背景の上に文字
- 全ページについて紙に濃い目のグラデーションがかかってる。
・・・などが該当します。
ただ、上記に該当する部分が含まれる本を避けると選択肢が格段に減ってしまうので、「読みづらいそうな部分に重要な情報が載っているか」「読みづらそうな部分が占める割合はどれぐらいか」を基準に多少なりとも妥協は必要です。
この点においてO'Reillyはかなり優秀です;)
スクリーンショットや写真に重要な情報が載っている
前述の背景色にも関連しますが、アプリケーションやブラウザのスクリーンショットに含まれる文字は小さくなりがちで、場合によってはアンチエイリアスのかかったフォントに何度かの画像圧縮を経ることで極端に判別しづらくなることもあります。また、ターミナルなど黒地に白の部分もにじみがでることで周囲の色(黒)に文字が侵食され、白黒2色であっても読みづらくなります。
写真の場合はどうしても光の加減や素材など天然の"ムラ"が含まれるため、グレースケールに変換されることで読む際にそれらがノイズとなって邪魔をします。
ランダムなページ移動が多い
この先は"見た目"ではなく"構成"の話です。
結論としては、Kindleは下記のような読み方は苦手のように感じられます。
- リファレンスのようにもくじ・索引を起点に、本文との間を何度も行き来する。
- もくじ・索引へのジャンプをサポートしていても、ページ数が多いとどうしてもボタン操作が多くなります。
- 「正規のPDF版(あるいは高いOCR精度)＋日本語もサポートした検索機能」であれば状況は変わるかも？
- 「詳細は○章(XXXページ)」のような別ページへの参照が多い。
- 紙の本であれば指を挟んで両ページ間を行き来するのは簡単ですが・・・
- 必ずしも参照先を読む必要が無い、あるいは既に読んだページを参照している場合は除く。
- 「～みたいな図が載ってたページ」「あのサンプルコード」など曖昧な検索
「初めてのRuby」 4章 文字列（その3）
4.5 文字列操作
文字列の結合、反復、分解、比較、反転、空白削除、長さ取得。
# -*- coding: utf-8 -*- print "abc" + "def" #=>abcdef(結合) oyatsu = "いちご" oyatsu << "大福\n" print oyatsu #=>いちご大福(破壊的結合) oyatsu2 = "ねる" * 2 + "ねるね\n" print oyatsu2 #=>ねるねるねるね(反復) p "a,b, cc, ddd, eeeee".split(/,\s*/) #=>["a", "b", "cc", "ddd", "eeeee"](分解) p "aaa" == "aaa" #=>true p "aaa" != "aab" #=>true p "aaa" < "aab" #=>true p "aaa" < "aaa" #=>false p "aaa" <= "aaa" #=>true p "aaa" <=> "aab" #=>-1 p "aab" <=> "aab" #=>0 p "aab" <=> "aaa" #=>1 p "today=3/8".reverse #=>"8/3=yadot"(反転) p " <-Space,Return->\n".strip #=>"<-Space,Return->"(先頭,末尾の空白削除) p "moji".length #=>4(文字の長さ) p "文字".length #=>2(マルチバイトもいける)
4.6 イテレータ
文字列をbyte単位、行単位で扱うイテレータ。
Ruby 1.9ではマルチバイト対応のeach_charも使える。
Perlだと切り出す処理を書くからここまでさらっとは書けないか・・・
"moji".each_byte do |byte|
p byte
end
#=>109
111
106
105
"文字列".each_char do |moji|
print moji + "\n"
end
#=>文
字
列
lunch = <<"EOS"
3/5 ラーメン
3/6 スープカレー
3/7 タンタン麺
EOS
lunch.each_line do |line|
print line
end
#=>3/5 ラーメン
3/6 スープカレー
3/7 タンタン麺
4.7 フォーマット
C言語でもPerlでもお馴染みのアレ。
String#%メソッドを使った方が書くのは楽そうだけどまだパッと読めない。。
p sprintf("%04d", 123) #=>"0123"
p sprintf("%03.2f", 42.195) #=>"42.20"
p sprintf("hex=%x HEX=%X oct=%o bin=%b", 10, 10, 10, 10)
#=> "hex=a HEX=A oct=12 bin=1010"
# 同じ処理を String#% メソッドで書いた
p "%04d" % 123
p "%03.2f" % 42.195
p "hex=%x HEX=%X oct=%o bin=%b" % [10, 10, 10, 10]
4.8 シンボル
比較を高速に行うために作られたもので「内容が同じなら同一オブジェクト」という性質をもつ。
なるほど、ハッシュのキーとして文字列オブジェクトの代わりに使うことが推奨されてたのはそのためか。
p :"hoge" #=>:hoge(:に続けて文字列を指定するとシンボルになる) p :hoge #=>:hoge(識別子として妥当なら""を付けなくてもOK) p :123 #=>syntax error(数字始まりは妥当な識別子ではない) p :"ほげ" #=>:"\u307B\u3052"(マルチバイトもいけた) str1 = "nemui" str2 = "nemui" p str1 == str2 #=>true p str1.equal? str2 #=>false(内容が同じでも別のオブジェクト) symbol1 = :nemui symbol2 = :nemui p symbol1 == symbol2 #=>true p symbol1.equal? symbol2 #=>true(内容が同じなら同じオブジェクト)
以降はマルチバイト文字列の話になるのでここで一区切り。
フレームワークやモジュールのRuby 1.9対応状況ってどうなんだろうなー。
近いうちにRuby 1.9が主流になる状況ならRuby 1.8の仕様はさらっと流す程度にしたいｗ
あみぐるみ作った。～codeを書かず、cordを編んだ話～
ふと思い立って人生初の編み物とかやってみた。
（とは言ってもかぎ針編み。棒２本のやつは難しそう・・・）
やっぱり物理的な"ものづくり"も楽しいなー
本は昼休みに紀伊国屋で買ってきた。
材料と道具は本に載ってるのと同じものをユザワヤで調達。
編み始めはこんな感じ。
だんだんと立体に。
頭のパーツできたー！
他のパーツもできたー！！
わたを詰めて目を付けたとこ。
口を縫いつけて、頭と体を合体！
手とお腹を付けたとこ。小さくて結構大変（汗
脚も付けたら完成！！！
こんにちは！
はじめまして！
さらっと書いてるけど練習に1時間、パーツ作りに4時間、仕上げに2時間、といった感じ。次やれば4,5時間で作れるかも？
おしまい。
