おいぬま日報

2009/9/10,11に開催されたYAPC::Asia 2009に参加しました。今年はフレームワークやORM系のセッションがとても豪華で全部聞きたいなと思っていたので、迷うことなく有給を取って参加。というわけで殴り書きですがメモと感想を徒然に書いてみます。

PSGI – Perl Server Gateway Interface

スライド

tokuhiromさんとmiyagawaさんのコラボレーション。PSGIは仕様でPlackは実装。HTTP::Engineには仕様とAPIと実装が全て入っていたのでこれを分離しましたよ、というお話。YAPCの1週間前ぐらいから開発し始めていてすごい勢いで実装されているらしいです。PlackはいわゆるReference Implementationですが、かなり速いという話でした。Reference Implementationという用語を聞いて、JavaのServlet APIをなんとなく思い出しました。

シックスアパートフレームワーク

shigetaさん
スライド

Six ApartではMTフレームワーク, ArcheTypeの2種類のフレームワークがある。
MTではMTオブジェクトがData::ObjectDriverを継承している。Data::ObjectDriverはSix ApartのCTOの人が作っているORマッパ。memcachedによるwrite-throughキャッシュが実装されてたり、shardingもサポートされている。たしか2年前ぐらいのYAPCでセッションやってたと思います。

驚きだったのは、TypepadではHTML::Templateを使っているということ。普通はTTとか最近だったらText::MicroTemplateのような高機能なものを使うと思うのですが、ななぜあえてHTML::Templateなんでしょうか。っていうのを質問すれば良かったと今になって後悔。

API Design

sartak – Shawn M Mooreさん。Mooseのコミッター。
スライド

• Moose
• Path::Dispatcher
• HTTP::Engine
• Dist::Zilla
• IM::Engine

今日はこれらのプロジェクトが持つクールなAPIの話をします。大事なのはテストをたくさん書くこと！なぜならテストを書けば使いやすいAPIかどうかわかる！あとはMooseなどの話。HTTP::Engineは新しいサーバのInterfaceが出てきても一行書き換えれば対応可能なところが素晴らしい、と言っていました。
英語だったので話の内容の半分も理解できなかったのが無念…

Modern Catalyst

hidekさん。最近DeNAに転職した? らしい。スライド

• Catalyst 5.8について
• Mooseベースになった
• M,V,Cの名前空間がdepreatedになった
• NEXTが…
• Catalyst::PluginなnamespaceのプラグインをCPANにあげるとmstにおこられるw

他のセッションでも「Catalyst 5.8使ってます」という話をちらほら聞いたのですが、Mooseベースになったら速度が遅くなったりしてないのかな、というのが気になっています。

ark – framework inspired by Catalyst

KAYACのtypesterさん。スライド

• KAYACでは大量に自社サービスを作っている。
• Catalystでもいいんだけど、もうちょっとライトなWAFがよかったのでHTTP::Engineをベースに作った。
• CGIモードでも割とサクサク動くようになってる。
• CGIの場合はクラスはlazy loadingするように工夫
• あとdispatch tableのキャッシュもしている
• テンプレートはText::MicroTemplate::Extendedというものを使うのが推奨されている。もともとはMojo::Templateをokuさんが切り出したもので、それを拡張している。
• Ark::Models – CLIスクリプトからでもModelを使える仕組み。あとlazy loadingをやったり。
• Ark::Form – HTML::Shakanベース
• KAYACのArkで作られたサービスの一部はなんとソースコードが公開されている！
• いなめなヶ崎
• im.kayac.com

Ark、Catalystとほぼ互換っていうのがいいなぁというのと、日本のモバイル対応版が早くリリースされないかな、って思いました。モバイル対応はもう必須になりつつあるような世の中なので、そのあたりのベストプラクティスを積み上げていってほしいなぁと。

優しいモダンなWAFの作り方

dannさん。スライド

• モダンなWAFとは？
  • プラガブル – Plagger
  • サーバ抽象化 – PythonのWSGI
  • フルスタック – Rails
• Angelos::PSGI::Engine
• Plack::Requestを使ってる
• HTTP::Routerを使ってる
• シンプルなWAFなら2,3時間あれば作れちゃう！
• 次、WAFの拡張部分の作り方(プラグイン)
• コアは小さく
• 拡張可能な箇所を限定(Controller, View, Middleware, Request, Response)
• Hookポイントを明確にする
• プラグインの種類は大きく分けると2種類
• RequestやResponseのライフサイクルへのHook系
• メソッドはやす系
• 適切なデフォルトセットの提供することが重要
• そうしないとUnicode化するためのTIPSが乱立したり、Inflate/Deflateするための(ry
• HTTP::EngineやPlack、HTTP::RouterなどのモジュールのおかげでWAF作りがかつてないほど簡単になっている！

Arkの話も聞いてて思ったのですが、Sinatraみたいなレベルであれば本当に2,3時間で作れそうな気がしました。これからフレームワーク戦国時代の幕開けですね。そして懇親会でも直接dannさんに言ったのですが、Angelosを早くリリースしてほしいです… (切実)

Booking.com & Perl

Cristina Nunesさん(from リスボン,ポルトガル)。スライド

Class::DBI(frozen version)
HTML::Mason
HTML::Template (forked version)
• Perl 5.8.8
• Class::DBI
• HTML::Mason
• HTML::Template(forked version)
• なぜPerl? –> 簡単で速い
• なぜHTML::Template? –> 簡単
• なぜClass::DBI? –> 聞き取れず(一番聞きたかったのに)
• Apache + mod_perl
• MySQL
• memcached
• git
• Jabber
• 将来のゴール
  • Perl upgrade
  • Modules upgrade
  • Apache + mod_perl upgrade (to 2.x)
  • MySQL upgrade (to 5.1 or 5.4)
• フロントエンドのWeb Server: 100台以上
• MySQLサーバ: 100台以上
• データセンターにあるサーバは700台以上
• IT at Booking.com
  • Perl developers
  • Java developers
  • Network engineers
  • Sysadmins (社内SEみたいなものかな)
  • Web designers
• 世界に25オフィスある
• 1900人の従業員
• 71000L hosts over 70 countries
• 4500+ distribution partners
• 24 languages available on website

Booking.comって初めて知ったのですが、ヨーロッパのホテルはかなり網羅されているという情報がIRCで流れてました。なんでいまだにClass::DBI使ってるんだろう、と思いましたが、mod_perlのバージョンも1.x系なので、やっぱりサーバの台数が多いとアップグレードも大変なのでしょうね。「Booking.comという会社は著名なPerl hackerを何人も抱えている会社なのです」という牧さんの補足がありました。

Key Value Store with O/R Mapper

yappoさん。スライド

• Key Value StoreとO/R Mapperの合わせ技 –> Data::Model
• Data::ModelはいわゆるO/R Mapper
  • DBI, memcached protocol, Perl hash, Perl code, Gearman
  • Q4Mにネイティブ対応
  • 透過キャッシュ
  • MixinによるSchemaクラスの拡張
  • ちょっとなういイテレータ
• なんで既製品では駄目だったのか？
  • Class::DBI – DBICに移行する方向になってる。偉大なる先輩に感謝
  • DBIx::Class – 過去に使っていたがあまりいい思い出がなかった
  • Rose::DB, Jifty::DBI – 見る時間があまり取れず…
  • DBIx::Moco – ドキュメント少ない。実際にサービスで投入されているものと公開されているモジュールの差異が激しい
  • Data::ObjectDriver – Six Apart謹製。意外とテスト少ない＆document少ない。ただしコードは大分参考にさせてもらった
  • DBIx::Skinny – 日本のPerl ORM専門家のもの。シンプルなスキーマに対して「生SQL書けます」はあまり魅力的じゃなかった。
• 結局調べているうちにORM作成のポイントがわかってきたので自分で作ることにした
• ORMはSchema, Iterator, Row, SQL, DBの5つのものがあればよい
• Data::Modelのデモ(詳しくはスライドを参照)
• TokyoCabinetをストレージとして使う場合、データを小さくした方がキャッシュにのったり色々嬉しいので、データは圧縮して小さくするべし。
• Perl標準のStorableはデータ効率が悪いことで有名 –> 代わりにMessagePackを使用(これがすごいらしい)
• KVSがストレージならALTER TABLEが必要なくなる。FriendFeedの例のようにすれば、スキーマなくても大丈夫
• MessagePackがとにかくすごいらしい

まずスライドがFiciaだったのが驚きでした。なるほど、そういう使い方できるんですねー。途中のData::Modelのチュートリアルでは、その高機能さ(透過キャッシュやMasterSlave、column_sugar)に驚きました。自分でもオレオレORM作ってるのですが、相当レベル違うなと感激しましたです。その他、MessagePackがすごい使えそう、というのがよくわかりました。圧縮のアルゴリズムがカリカリ過ぎです。

simple or mapper DBIx::Skinny

nekokakさん。スライド

• なぜ自分でORMapperを作ったか？
• DBIx::Classが微妙…
  • 便利だけど発行されるSQLが微妙
  • パフォーマンスが出なかったりする
  • 生成されるオブジェクトがでかすぎるため重い
  • カスタマイズしようにもソースがでかすぎる
  • DBICで速度でない場合は生SQL書くことがあるが、Inflateとかしてくれない
• 生SQL書いてinflate/deflateしてくれるライトなものでいいんじゃないか、というところにたどりついた
• DBIx::Skinnyのデモ
• relationshipは特に何もしない
• コアは小さく、がモットーなので、拡張したい人はラッパーを書けばいい
• 何人かの人に興味持ってるみたいなので、Skinnyみたいな方向性はありなのだなと思った。

ちょいと前にSkinnyのバグを見つけたのでメールでパッチ送ったりしていて、ちょうどYAPC当日にnekokakさんと直接お話させてもらう機会があったのですが、いやー非常に嬉しかったです。懇親会でもお話しさせてもらったのですが、やっぱり生SQL全然ありだよね、と思いました。もともと自分がSkinnyに興味を持ったのは、自分が3年前ぐらいに会社で作ったO/R Mapperと非常に設計思想が似ていて、「へー」と思ったのがきっかけです。(もちろんSkinnyの方がAPI的にも非常に洗練されているのですが…)

というわけで、自分もDBIx::Thinというのを作っているのですが、早く安定板をリリースしないと。とにかくエンジニアとしてはとても刺激になったセッションでした。

『Ficia』インフラとPerlにまつわるエトセトラ

hirose31さん＠えとらぼ。スライド

• Linux 2.6, Apache2, mod_perl 2.0
• mod_perl 2のメモリ関連のチューニング
• 推測するな計測するべし(ps, top)
• fork(2) – Copy On Write
• /proc/PID/smaps (kernel >= 2.6.14) – 共有領域: Shared_Clean + Shared_Dirty
• いわゆる親プロセスと子プロセスの共有メモリ領域の話
• id:naoyaさんの日記が詳しい
• 使うモジュールは親プロセスで起動時に(startup.plなどで)ロードする –> 子プロセス独自のメモリ領域にロードしないので節約になる
• Apache起動直後は共有率99%。時間が経つと共有率が40%ぐらいになり、プロセスのメモリ消費量が多くなる
• 使用しているモジュールの一覧をどうやって取得するか？
• Apache2::Status –> Loaded Modules で一覧を確認
• あと親プロセスでモジュールをロードしておくと、コンパイル済みで即戦力になるのでオーバヘッドが少ないらしい
• サイズがもりもり太っているモジュールを探す方法 – Apache2::Status + B::TerseSize
  。Memory Usageで一覧を確認
• nagiosで少しでもswapしたらメールを飛ばすようにしている
• 以降、httpd.confの話
• StartServers != {Min,Max}SpareServers
• 忙しい時はMaxに。ヒマになったらStartServersの数に戻る –> forkするのがむだ？だったら最初から全プロセス起動しておいた方がいい
• /etc/init.d/httpd stop
• stopしたのに新規リクエストが来ちゃう(ロードバランサーのヘルスチェック後とか)
• start – 起動時からフルでプロセスを起動するので、start直後にリクエストが来ると負荷が高くなってしまう。一定時間おいてからロードバランサーに入れる必要がある。
• ロードバランサーのヘルスチェックのURLを動的なものにしておき、フラグファイルがあったら200を返すようにするとか。
• あとはmatrixの話

mod_perlのチューニングのような話は、最近はみんなFastCGIに移行しているのかあまり聞かないので、非常にためになりました。あと、StartServersで最初から一気にプロセス立ち上げておく技は昔考えたことあったのですが、LBのヘルスチェックとか面倒だなぁと思って挫折した経験があります。なるほど、ヘルスチェックのURLを動的にしてフラグファイルで管理っていうのは全然ありだなと思いました。というかRubyのpassengerとかはそんな感じの実装になってますね。

一日を通しての感想

おそらく初めて丸一日ぶっ通しでセッションを聴いたのですが、最後の方はやはり集中力がもたなくていいセッションでもあまりちゃんと聴けなかったのが残念です。ただ、エンジニアとしてのモチベーションは上がりまくりで、懇親会中も「早く家帰ってコーディングしたい」と実は思ってました。あと酔った勢いでDBIx::Skinnyのポスグレ対応とかしたのですが、バグとかテストを sfujiwara さんに面倒見てもらったようで、非常に恐縮でした…

個人的に非常に参考になったのは、Ark、Data::Model、DBIx::Skinny、Ficiaのインフラでした。WAF, ORMapper, インフラの話が聴けて大満足です。

すごい今更ですが、記憶が残っているうちに9.11のYAPC::Asiaのレポートをば。2日目も色々セッションに参加したのですが、特に記憶に残っている最初の2つだけ。

DeNA loves Perl

notoさん。スライド

• DeNAはエンジニアは100人ぐらいで半分ぐらいはモバゲー
• 今回のYAPCでも3人がセッションで発表している。(hidek, zigorou, matsuda)
• 最初のbiddersはJava+Oracleだった
• モバオクを川崎さんが作る時に初めてPerlをつかった
• Perlは読みやすい、実行速度も速い
• 最近はmyDNSのDNS RRの代わりにLVSを使うようになった
• memcachedも使っている
• MySQLのshardingもしている。モバゲーでは90個ぐらいに分割されている
• mobamail
• モバイルのメール配信 – キャリアの都合で接続がdenyされることがある。大量に送り続けるとdenyされる
• キャリアのMXレコードは異様に少ない
  • docomo.ne.jp – 4IP
  • ezweb.ne.jp – 1IP
  • softbank.ne.jp – 1IP
• キャリアのメールサーバが少ないから、送信側で送信先を分散できない
• mobamail – Perlで実装したモバイルメール向けの配信サーバ。配信するだけなのでMTAじゃない(SMTP受ける方は実装してない)
• コネクションを貼るところでIO::Selectを使っている
• キャリアの制限の範囲内でなんとか最速で配信できるようにする。キャリアごとに細かい設定ができるように。
• SIELLA Engine – より速い。さらに自分たちで設定しなくても楽。最近はこっちを使っている(ズコー)
• (話は変わって)モバゲーのオープン化について
• OpenSocial + Game API 法人に解放
• 10/5 にフォーラム。来年1月以降に一般公開
• DeNAのエンジニアのポリシー – ビジネスの成功にコミットすること
• お金で解決しない。技術で「安く、早く」
• ビジネスの成功を重視しているので、きれいな技術が二の次になっているのは否めない
• 100人近くPerlエンジニアがいるのにCPANコミットがない
  • 他社の特許侵害のリスク(一部上場しているので目をつけられてしまう)
  • やりたい人がいたら推奨しようとしているが…
• DeNAのPerlでの開発方針
  • 「一筆書き文化」：再利用せいや汎用性の設計に時間をかけるくらいならそういうことは考えずに書く方が速い
  • サービス単位の独自性・機動性重視＝モジュールの共有なし
  • 割り切りの思想、逆転の発想、これでサービスを速くリリースしてきた面も
• 今後の展望
  • 大きな開発チームでのポリシー
  • more test code
  • MobaSiFの次のバージョン
• DeNAで一緒にコードを書きましょう!
  • as DeNA software engineer / architect
  • as developer of moba-ga town
  • as CPAN author

携帯向けのメール配信でSIELLA Engineを使っているのが驚きでした。ああいうモバイル向けのパッケージ製品って他にもKlabのアクセルメールとか良さそうなのいっぱいあるし、やっぱり餅は餅屋にって感じなのでしょうか。

モバゲーのAPIがオープン化されるということは、PC向けにFlashでゲームも作れるのかな？というのが気になりました。現状モバゲーのPCサイトってモバイル版のはりぼてみたいなものなので、これを機にPCサイトも盛り上がるといいのかなぁと。

endeworksでのWeb Appの作り方

33rpmさん(船木太郎さん)。スライド

• 牧さんが代表の会社です。
• 特別なことはやっていない
• 開発サーバは用意していない(個人のMac上で開発)
• Test::FITesque が最近の流行り（読み方よくわからない）
• ディプロイ – git pullするだけ。ディプロイツールといったものは使用していない
• Apache+FCGI – daemontoolsでFCGIのプロセスを管理
• Catalystを使用
• Mooseを使用 – Catalyst 5.8をプロダクション環境で使用
• APIモジュール
• CatalystのModelを使用しない
• CatalystのModelは当たり前だけどCatalyst依存
• ModelはWebという枠組みの外、たとえばCLIやWorkerからも呼び出したいことが多い
• MyApp::API::* という名前空間
  • 中身はORM+アプリケーションロジック
  • キャッシングのロジックもここ
• DIコンテナは？ – アプリケーション全体で共有されるインスタンスはRegistryというモジュールに格納
• Registry – メモリ上のKVSに保存するだけのsingleton object
• Formの作成はHTML::FormFuを使用
  • 生成されるHTMLに不満
  • HTML::FormFuのValidatorはとてもよくできているので、レンダリングはさせないでValidatorだけ使うというのが最近の流行
• pixis(フレームワーク)の説明(githubで公開されている)
  • WebサービスやSNSでありがちなメッセージ管理などのソーシャル機能をまとめたフレームワーク
  • Catalyst 5.8依存
  • 依存モジュールが多い

明日はPerl Mongersの祭典YAPC::Asia 2009です。明日と明後日は仕事を休ませてもらって(!)、フルに参加したいと思ってます。というのも、今年のYAPCは本当に聴きたいセッションばっかりなのです。

というわけで、当日なるべくスムーズにセッションに参加できるようにめぼしいものをメモしておきます。はー、やばい楽しみ過ぎる！

9/10(木)

• 10:50 PSGI – Perl Server Gateway Interface
• 11:40 シックス・アパート・フレームワーク‎
• 13:45 API Design‎
• 14:30 modern Catalyst‎か分散ファイルストレージ‎
• 14:50 ark – framework inspired by Catalyst‎
• 15:20 優しいモダンなWAFの作り方‎
• 15:40 Booking.com & Perl‎
• 16:10 Key Value Store with O/R Mapper‎
• 16:30 simple or mapper DBIx::Skinny‎
• 17:00 『Ficia』インフラとPerlにまつわるエトセトラ‎
• 17:20 Perl database test using MySQL::Sandbox‎
• 18:00 Lightning Talks (1)‎
• 19:30 懇親会(たぶん)

9/11(金)

• 9:45 DeNA loves Perl‎
• 10:35 endeworksでのWebAppの作り方‎
• 11:25 ‎大規模画像配信を支えるPerl‎
• 11:55 Asynchronous Database Queries with Perl‎
• 13:30 Asynchronous Programming for (A)synchronous Communication‎
• 14:20 ‎Perl? Which Perl?‎
• 15:10 ‎はてなブックマークのシステムについて‎
• 16:00 記憶
• 16:50 Lightning Talks (2)‎
• 17:25 基調講演
• 18:15 Closing Ceremony‎

Ubuntu 9.04にはMySQL 5.1のパッケージが用意されているのですが、バージョンが5.1.31であり最新ではないので(現時点で最新は5.1.37)、最新版のdebパッケージを作成する方法を紹介します。debを作成するといっても、開発中のUbuntuに入っているmysql-server-5.1のソースを持ってきてビルドするだけなので、比較的お手軽にできます。

debを作成するための準備

まずはビルドする人間のメールアドレスと名前を環境変数で設定しておきます。

$ export DEBEMAIL="hogehoge@foo.com"
$ export DEBFULLNAME="Your Name"

次にパッケージをビルドするために必要なものをインストールします。

$ sudo aptitude install dh-make devscripts debhelper fakeroot lintian sudo pbuilder piuparts dpatch

ソースの取得

“mysql-dfsg-5.1” source package in Ubuntuよりdevelopmentのkarmicの方のリンクをクリックして、その先の画面で以下の3つのファイルをダウンロードします。

• mysql-dfsg-5.1_5.1.37.orig.tar.gz – ソースtarボール
• mysql-dfsg-5.1_5.1.37-1ubuntu2.diff.gz – debを作成するためのdiff
• mysql-dfsg-5.1_5.1.37-1ubuntu2.dsc – パッケージングのルールを記載したファイル

今回は ~/deb というディレクトリを作成してその中で作業するので、debディレクトリにダウンロードしておきます。

mysql-dfsg-5.1のビルド

mysql-dfsg-5.1のビルドに必要なパッケージをインストールしておきます。

$ sudo aptitude build-dep mysql-server-5.1

次にソースを展開します。dpkg-source -x を実行するとソースを展開するだけはなく、パッチも自動的に当ててくれます。

$ dpkg-source -x mysql-dfsg-5.1_5.1.37-1ubuntu2.dsc
dpkg-source: warning: extracting unsigned source package (mysql-dfsg-5.1_5.1.37-1ubuntu2.dsc)
dpkg-source: extracting mysql-dfsg-5.1 in mysql-dfsg-5.1-5.1.37
dpkg-source: info: unpacking mysql-dfsg-5.1_5.1.37.orig.tar.gz
dpkg-source: info: applying mysql-dfsg-5.1_5.1.37-1ubuntu2.diff.gz

そしていよいよビルドです。(私はAthlon X2 5050eの環境で約2時間かかりました)

$ cd mysql-dfsg-5.1-5.1.37
$ debuild -us -uc

場合によっては「”hardening-wrapper”というパッケージがないよ」というエラーになってビルドできないかもしれないので、このパッケージをaptitudeでインストールしておきます。

完了すると .deb パッケージが~/deb/配下に作成されているので、必要なものをdpkg -iしてインストールします。ただし、依存関係が若干複雑なのでエラーが出たら依存しているものを先にインストールすると良いでしょう。

$ sudo dpkg -i mysql-common_5.1.37-1ubuntu2_all.deb ¥ 
 libmysqlclient16_5.1.37-1ubuntu2_amd64.deb ¥
 mysql-client_5.1.37-1ubuntu2_all.deb ¥
 mysql-client-5.1_5.1.37-1ubuntu2_amd64.deb
 
$ sudo dpkg -i mysql-server-core-5.1_5.1.37-1ubuntu2_amd64.deb ¥
 mysql-server-5.1_5.1.37-1ubuntu2_amd64.deb ¥
 mysql-server-5.1_5.1.37-1ubuntu2_amd64.deb

なお、5.0から5.1にアップグレードするような場合、my.cnfに使えなくなったオプションを書いていたりするとmysqldの起動に失敗するので、エラーログを見て適切に対処しましょう。例えば私の場合は –skip-bdb というオプションが使えなくなっていてエラーになっていました。

無事にインストールできれば、これでmysql-server-5.1が最新版になっています。mysqlコマンドでSQLを発行して動作を確認してみて下さい。

$ mysql -uroot -pxxxxx
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 68
Server version: 5.1.37-1ubuntu2-log (Ubuntu)

補足

今回はUbuntu 9.04で試しましたが、Debianでも同じ手順でパッケージを作成することができるはずです。また、debパッケージの作成にあたってDebianパッケージ60分クッキング(PDF)を参考にさせて頂きました。

毎年やっているLL系のカンファレンスであるLLTVに今年も行ってきました。といっても今回は時間の都合で参加したのは渡る世間は雲ばかりだけでしたが… というわけで簡単ながらレポートします。

Windows Azure – 荒井省三さん(マイクロソフト)

MSの人なのにMacBook使っていたのが印象的。いろいろ図を用意してくれていたのですが、Windows Azure自体が複雑そうであまり深く理解できなかったのが正直なところ。ストレージとしてはTable(Key Value Store)とSQL Azure(RDBMS)というものがあるのが興味深かったです。AmazonはSimpleDB、Google App EngineはBigTableと、Key Value Storeは用意しているものの、スケール可能なRDBMSを用意しているところがないのですが、AzureではTable(Key Value Store)とSQL Azure(RDBMS)を用意しているとのことで、そこがユニークだなぁと感じました。(RDBMSはそのうちOracleもクラウド環境に参入したら提供しそう)

Slim3 – ひがやすをさん

Slim3はTDDベースでの開発をサポートしているのが一番の特徴、とのこと。簡単にSlim3を説明した後は、twitterライクなサービスをSlim3で作るデモをコードを書きながら淡々と行なってました。時間過ぎてたんですが、「あと5分下さい」とかなりフリーダムな雰囲気。

最後に作ったアプリをGoogle App Engineにディプロイしていたのですが、Eclisepのボタン一つでディプロイが完了していて、あれはすごい便利だなぁ！と思いました。

JRuby on GAE – 高井直人さん

• JRuby – JVMによる高い性能
• RubyのWAF – rails, merb, sinatra etc…
• JRuby-Rack – JRuby + Railsだと多層構造過ぎるので、JRubyとRack層を統合したものを作った
• wabler – railsアプリをWARファイルにパッケージングするための自動化スクリプト
• appengine-jruby – GAE APIのJRubyラッパー。Googleの人が作っているらしい
• GAEでrailsアプリを動かすのはけっこうしんどい
• Engine Yardでもクラウドみたいなことをやるだろうから、そっちでやるほうが時間を有意義に使えるんじゃないか。

Kay Framework – 松尾貴史さん

• GAEのPython APIについては日本で一番詳しいかも
• GAEで動くPythonフレームワークは色々あるけど、無駄が多かったりパッチ当てなくてはいけなかったりで、GAEに特化したFrameworkを作った
• 息子の名前をつけたかった
• sphinx – pythonのドキュメント生成ツール。これでドキュメントを作っている
• GAEのAPIはHTTPで叩けるので、wxPythonでGUIアプリからもAPIを叩ける

発表の中で「Pythonistaとしては」と言っていて、Python使いのことをPythonistaっていうんだなぁと学びました。PerlはPerl Monger、RubyはRubyistというように、言語によって言い方違うんだなぁと。

まとめ

Amazon EC2は有料でサーバ1台を丸ごと貸してくれるので自由にできる一方、Google App EngineはRDBMS使えないとか言語の制限(今のところPython, Java)があったりでかなり性質が違うのかなと。ただ、GAEは500万リクエストまでは確か無料なので、画像やスタティックなファイルを置いたりして、CDN的な使い方してもいいんじゃないかなぁと思いました(ただし、データセンターがどこにあるのか次第)

bashには過去に実行したコマンドを履歴として残しているので、CTRL+pなどでその履歴をさかのぼり過去に実行したコマンドをそのまま実行したり、ちょこっと直して実行することができます。しかし、この便利な機能は一方で、 rm などのファイルを削除したりするような危険なコマンドを、履歴からいとも簡単に実行してしまい、結果として大切なファイルを消してしまったりするようなミスを誘発する恐れがあります。

そんなことを考える人に「特定のコマンドだけ履歴に残したくない(=.bash_historyに残さない)という技を紹介したいと思います。具体的には

export HISTIGNORE='rm*:mv*'

のように、環境変数HISTIGNOREに履歴に残したくないコマンドを設定します。:(コロン)でコマンドを区切ることで複数のコマンドを設定することが可能です。上記の例では rm と mv を履歴に残さないようにしています。

実際に試してみると

$ touch hoge
$ rm hoge
$ history
   ...
   98  touch hoge
   99  history

のようにrmコマンドはhistoryには残っていません。実行前にコマンドを確認しないで、うっかり履歴からrmコマンドで必要なファイルを消してしまった、というようなオペレーションミス対策になると思うので、重要なサーバではぜひ設定してみると良いと思います。

ジョン・グリシャムの最新作が文庫本で発売になっていたので、すごく久々に小説を読みました。今回のこの小説は法廷モノというよりかは裁判の外での駆け引きがメインなので、いわゆる「弁護士と検事の闘い」というものではありません。

しかし、発癌性物質を垂れ流した企業の責任を問うための裁判に、原告として関わると一体どういうことになるのか、ということが赤裸々に表現されていてその切り口が素晴らしいと感じました。

一つ気になったのは、企業のトップが裁判の和解について、マスコミを情報操作して株価を操作し、株を買い漁る描写があるのですが、これってインサイダーになったりしないのかなという点。日本だったら確実にインサイダー取引で捕まってそうですが、どうなんでしょう…