タグ別アーカイブ: perl

Hachioji.pm#20 に参加してきました #hachiojipm

こんにちは、東京在住なので東京の勉強会にも顔を出し始めた おがた (@xtetsuji) です。

今回、平日開催となった Hachioji.pm#20 に参加してきました。Hachioji.pm は今住んでいるところから比較的近い地方PMなので、頻繁に通ってPerl Mongerの皆さんと交流したいと思っていたのですが、特に春先から眠れないやら激しく腹を壊したりやらすこぶる病気がちだったもので、Hachioji.pm#15 以来の久々の参加となりました。

今回は平日開催ということもあって、参加者は9名と普段より少なめ(当初は定員と同じ10人)。

今回もHachioji.pm公式ページのレポートがアップされていますので、そちらをご覧になると雰囲気が分かると思います。

ちょうど帯広から東京に出張にきていた @masiuchi さんがいらっしゃっていて、Hokkaido.pm 以来の久々の再会が嬉しかったです。

会場は吉祥寺のevinoという名前通りのエビ料理の店。北海道生まれ北海道育ちにも関わらず、エビの皮むきが苦手で服に汁を飛ばしたりしたハプニングもありましたが、料理はどれも美味しいものばかりでした。エビのハンバーグが特に印象的でした。ビールもワインも美味しかった。ちょうど私が座った席の周辺が、自分を含めて北海道出身という状態で、@masiuchiさんと@ytnobodyさんの函館ディープトークやら、ここはHokkaido.pmかと錯覚するような光景も繰り広げられました。

自分も含め、今回の参加者の9人のうち約半数が、9月末の YAPC::Asia Tokyo 2012 のスピーカーだったこともあって「トーク採択おめでとうございます」「期待しています」といった会話が飛び交いました。

今回の Hachioji.pm がなぜ急遽平日開催になったかというと、YAPC::Asia Tokyo 2012 の会場の一角で LTthon (エルティーソン) という LT (Lightning Talk) のマラソンのようなものを行おうというイベントの予定を立てるためとのことでした。トークどころか5分間LTすらしたことのない人にも YAPC::Asia Tokyo 2012 という大舞台の一角で話す機会を与えたい、といった趣旨だったかな。「どんなことを話してもらうんですか?」と質問したら、「家で飼っているメダカの話とかでもいいよ」とのことでした。要するに公序良俗に反しなければ何でもありのLTのようです。気楽ですね。YAPC::Asia Tokyo 2012 に来る人で心当たりのある方に、ぜひともLTthonでのトークデビューを勧めてみたいと思いました。企画の骨格がさらに固まっていくことを待ち望んでいます。

Hachioji.pm恒例の「1枚LT」。今回もお酒を飲みながらパソコンを持ち出してPerlなどを熱く語るという光景が繰り広げられました。今回こそはと、私もLTスライドを準備して念願のHachioji.pm「1枚LT」デビュー。場の反応はそこそこだったこともあって安心しました。

他の「1枚LT」は、@uzullaさんによるLTthonの話、@ytnobodyさんによる新しいWAF「Nephia」を作ってみた話(詳しくは@ytnobodyさんのブログエントリをどうぞ)、合計で3LTでした。最近学習のためにMojoliciousの中身を見て、その巨大さと複雑さに「中身を見て理解するのは相当な根気と努力が要るわー」と挫折しかかっていたところだったので、生まれたての小さなWAFがどのように育っていくのか、「Nephia」をウォッチすることでWAFの成長というものも含めて勉強させてもらおうと思った次第です。

私の「1枚LT」である「すごいmod_perl」は、当初の発表資料に多少の修正を加えた上でSlideshareにアップしました。半分はネタトークです。当初はこんなに YAPC のトーク採択が早いとは思っていなかったので、ここで宣伝して「いいね!」してもらおうと思って準備していたものでしたが、期せずして YAPC で採択されたトーク「モダンmod_perl入門」の宣伝になって良かったです。「すごいmod_perl」はネタトークでしたが、本番の「モダンmod_perl入門」はどこまでネタや笑いどころを入れるかはまだ考えていません。20分はやはり語るに短い。それでも興味深い内容を話して皆さんに興味を持ってもらえるよう、入念に準備したいと考えています。

23時ごろお開き。中野区在住にとって、中央線で中野に近づいてくれるとより足を運びやすいので、今回の吉祥寺開催はとても行きやすかったです。平日開催でしたが、会社が杉並区だったので、荻窪まで行って少し西に行くだけで会社帰りでも簡単に行けました。今後も名前通り八王子での開催が中心となるでしょうが、たまにはもうちょっと中央線の東寄りで開催していただけるといいなぁと贅沢な事を思った夜でした。

Apache上のPerl FastCGIはCustomLogにデータを書くことができるか?ついでにmod_perlでのお話

こんにちは、Apache mod_perl が大好物の おがた (@xtetsuji) です。

そういえば、2012年に開催されるYAPC::Asia Tokyo 2012にトーク「モダンmod_perl入門」を応募しました。この記事が気に入りましたら、ぜひとも「イイね!」お願いします。

mod_perlに偏執的なのも良くないなと思って、最近はFastCGIやPSGI/Plack以降のWAFも勉強しています。Perlから外に出られていないのがまだまだといったところですが…;。

それでも好きが講じて、Twitterを使って日々mod_perlの情報を収集しているのですが、今日こんな会話を見つけました。

この会話、要約するに

  • ApacheのFastCGI(mod_fastcgi)を使ってPerlスクリプトを動作させている
  • PHPのapache_note()関数のようにApacheでデータをログに乗せたい → たぶん LogFormat ディレクティブで “%{Foobar}n” 書式を使って CustomLog ディレクティブに指定したログにデータを書きたい
  • mod_perlは使いたくない → 嫌わないで(´Д⊂ヽ

FastCGIの仕様書や、FastCGIを使ったプログラムを書いたり読んだりしたことはありますが、私はそれほどFastCGIの仕様はわかっていません。ただ、当初これはFastCGIでは無理ではないかと思いました。

  • FastCGIは永続環境であるもののCGIの思想を踏襲しているわけで、Apacheとは独立した仕様であり(Nginxやlighttpdでも動きますし)、Apache HTTPリクエストフェーズでの情報交換を目的としたApache独自の「Apacheノート」にアクセスすることは出来ないだろう
  • FastCGI、今回はApacheのmod_fastcgi自体がこの要望を叶えられないのであれば、各種CGIとなるプログラム言語のライブラリレベルで努力しても、少なくとも普通の実装では無理だろう

環境変数ならと考えてはみたものの、perldoc FCGI を読んでみても実際に試してみても、use FCGI; して得られた my $request = FCGI::Request(); を試行錯誤していじってみても、環境変数をApacheリクエスト処理の後続に位置しているログ処理フェーズに伝えることはできませんでした。…;というかそんなのは当たり前ですね。詳しく説明できない程度の知識しかないのがもどかしいですが、FastCGIはApache本体とは独立したコンテナのようなデーモン(サーバ)を作るわけですから。気の利いたソケット(詳しくないけど言ってみたかっただけ)で両者が繋がっていれば話は変わってくるかもしれませんが、最初から勝算はありませんでしたし、うまくもいきませんでした。

perldoc FCGI をさらに読んでも、環境変数はまだしも、Apacheノートに関する記述は完全にありませんでした。敗北が見えはじめました。

基本に戻ってLogFormatのカスタムログ書式を復習してみました。ApacheのサイトにあるLogFormatのカスタムログ書式のマニュアルを読んでみると、任意データを受け取れそうな “%{Foobar}?” といった書式はこれだけありました。

  • %{Foobar}i:入力ヘッダ “Foobar” の内容
  • %{Foobar}n:Apacheノート “Foobar” の内容 (公式サイト上では「メモ」と書いていますが、この記事では「Apacheノート」で統一します)
  • %{Foobar}o:出力ヘッダ “Foobar” の内容

入力ヘッダはいじりようがない(FastCGIが動作するリクエストフェーズのずっと前の、Apacheのヘッダ解釈フェーズで既に処理されている)ので除外。Apacheノートも、上記考察から除外。

最後に残ったのは出力ヘッダ。「あ、出力ヘッダはFastCGIからApacheを通るし、もしかしたらいけるんじゃね?」と思って試してみました。

custom-output-header.fcgi

#!/usr/bin/perl
# ogata 2012/08/03

use strict;
use warnings;

use FCGI;

my $request = FCGI::Request();

while ( $request->Accept() >= 0 ) {
    print "Content-type: text/plainrn";
    print "X-Tetsuji: Hello! World.rn";
    print "rn";
    print "It is fine.rn";
}

LogFormatの設定

LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i" "%{X-Tetsuji}o"" combined_xtetsuji

手元のApache2+mod_fastcgiにVirtualHostを作って、この combined_xtetsuji を CustomLog で使うようにして、custom-output-header.fcgi を叩いてみました。

以下がそのアクセスログ(IPアドレスは何となく伏せました)

xxx.xxx.xxx.xxx - - [03/Aug/2012:00:08:28 +0900] "GET /custom-output-header.fcgi HTTP/1.0" 200 245 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.57 Safari/537.1" "Hello! World."

お、最後に “Hello! World.” 出てる!

結果的に、出力ヘッダ “%{Foobar}o” を LogConfig ディレクティブに使えば、記録したいデータを出力ヘッダに含めることで、FastCGI でも Apache CustomLog ディレクティブに指定したログにデータが記録できることがわかりました。

…;が、この方法は、わざわざヘッダを見るユーザには記録したいデータが丸見えという明らかな欠点がありますね。これはちょっと…;

Apache FastCGIを使う限り、会話に登場した方が本当に満足する方法があるのか。もしくは上記で良いのか、ちょっとわかりません。私にはこれが限界でした。

あと一つ!mod_perlはPerl CGIの高速化環境として見ても、それほど悪いものではないですよ。FastCGIもmod_perlも永続環境という意味では同じような魅力と問題を合わせ持っていると思います。インフラエンジニアの専門家の方には「Apache自体はスリムであれ」等、鋭いご指摘等があるかもしれませんが。そういったご意見もぜひご教示いただきたいです。

ちなみに、Perl CGIの高速化環境 (PerlHandler Apache::Registry (mod_perl1) / PerlResponseHandler ModPerl::RegistryPrefork (mod_perl2)) のmod_perlでAapcheノートにデータを読み書きする方法は、ざっくり以下です。

  • use CGI; # CGI.pm は Perl CGIの高速化環境下のmod_perl{1,2}をサポートしている
  • my $cgi = CGI->new(); # 普通にインスタンス作成
  • $cgi->r というメソッドが用意されていて、これでmod_perlリクエストオブジェクト(Apache::Request (mod_perl1) / Apache2::RequestRec (mod_perl2)) を取得することができる
  • $cgi->r->notes->get(“BuzzMemo”); # Apacheノート “BuzzMemo” の値を取得
  • $cgi->r->notes->set(“BuzzMemo” => “This is fine”); #  Apacheノート “BuzzMemo” の値を設定

実際にmod_perlハンドラを生で書く場合には幾つかの注意点があったりしますが、今回は割愛(需要あるかな?)。CGI.pmではその部分をなんとなく吸収してくれています。ただひとつ注意点は、CGI.pmのドキュメント perldoc CGI では r というメソッドには一切触れていない、つまり非公開メソッドであること。とても歴史の古いモジュールですので、突然次の日に使えなくなる可能性は限りなく低いとは思いますが、使う場合はその点ご留意ください。

そんな部分も含め、mod_perlの興味深い世界に興味を持っていただいた方は、しつこいですがトーク「モダンmod_perl入門」にぜひ「イイね!」よろしくお願いします!YAPC::Asia Tokyo 2012 会場でのトークや(トーク動画とともに後日公開もされる)資料で、もっと興味深い世界をご紹介します。

Hokkaido.pm#7 に行ってきました

こんにちは、遅筆癖を直したい おがた (@xtetsuji) です。

2012年5月13日に行われた Hokkaido.pm#7 に行ってきました。

…;と、このブログを投稿している7月末になって「何をゴールデンウィーク明2ヶ月前の話をしているんだ!」とお叱りを受けるかもしれません。ごめんなさい。遅筆な上に、ついつい文章を書き始めると長文になってしまって時間がかかるので、書き始めるまでの心理的障壁が大きいんです。

あとブログ記事が遅れた要因として

  • 会社が「おまえよく発表後に体調崩すから発表しちゃダメ」と言われたのに飛び入りLTした事を会社に律儀に報告して許しを乞う(5月中旬)
  • 発表に使ったMyApache2::Sinatraticに大バグ発見。Apache上の複数のVirtualHostで使っただけで崩壊なのには自分ながらガッカリした。修正開始。(5月下旬)
  • 体調を崩す。元々弱い腹に胃腸炎が襲来。(6月上旬から中旬)
  • 胃腸炎の後遺症で戻りかけていた睡眠リズムが崩壊して体調が中々戻らない(6月下旬)
  • MyApache2::Sinatraticさらに修正(7月上旬)
  • 忙しかったり体調不良が続いたり(7月中旬)

といった事情もあります。言い訳。MyApache2::Sinatraticはなんとか「動くように見える」レベルまで修正しました。後述。

今回は簡潔に行きます!要約大切!(いまのところの意気込み) → …;と思って書き始めましたが、結構な長文になってしまいました…;とばし読み流し読み大歓迎!もしくは「あとで読む」に放りこんで、時間のあるときにどうぞ!

Hokkaido.pmは #5 から連続3回目の参加です。今回も東京から札幌へ遠征をしました。

このブログの過去記事より過去のHokkaido.pm。

今回は公式サイトの開催報告が良くまとまっていて見やすいです。動画もスライドも開催概要もここからたどることができます。私もトゥギャッターで協力しました。今回のテーマは「Webアプリ「再」入門」。特にWAF(Web Application Framework)の話が多くをしめました。

今回も各トークの私なりの感想を簡潔に書いてみたいと思います。

「ゼロからはじめるAmon2」@akiymさん

Hokkaido.pmの高校生Perlハッカー@akiymさん。「WAF初心者」とのこと。

「WAFとは?」という問いかけから、Amon2の基本的な使い方を紹介。

「Perl WAF といえば Catalyst?」という時代もあったけど、「なるべく学ぶことは少なくしたい。再入門に時間なんてかけてられない」。確かにそうです。

Perlにおける軽量WAFとして、「Amon2」「Dancer」を例示。Amon2がjQueryやTwitter Bootstrapを同梱していたり、Text::Xslateを標準テンプレートに採用しているといったメリットを提示。

スケルトン生成からデモへ。

flavorとしてBasic(デフォルト)とLarge、Liteがある。Amon2::Lite # Mojolicious::Liteっぽい。

コード例から、コンテキストオブジェクト $c からの基本を解説してくださいました。RequestやResponseはPlackからのシンプルな継承。設定ファイル config/{development,deployment,test}.pl を紹介して、これを PLAC_ENV で切り替えられるというお話。

% plackup -E deployment app.psgi

dispatcherはRouter::Simple。

詳細はスライドを見ていただければよくわかりますが、基本的なスケルトンコードを例示。いわゆるSinatraライクですね。

プラグインも紹介。

  • Web::CSRFDeefender → CSRF対策(トークンを埋め込む)
  • Web::FillInFormLite → $c->fillin_form(); # HTML::FillInForm::Lite
  • Web::JSON → $c->render_json();
  • Amon2::Auth → Twitter, Github, Facebook, Loctouch をサポート
  • Amon2::DBI → $c->dbi

実際にウェブアプリを作ってみるというデモもありました。

まずは「オレオレGyazo」を 「% amon2-setup.pl Gyazo」 として生成。FillIn や CSRF は要らないので削除、dispatcher にべた書き(このあたりはスライドが詳しいです) → 短縮URLの実装もやる → SQLite

ネタ的なおまけとして「KENT WEB」をAmon2で書きなおそう!なんてのもあって会場は爆笑。

  • Amon2::DBI
  • Teng
  • Form::Validator::Lite

素材はこれら。「KENT WEB」が最先端の技術で蘇りました。スゴイ。

まとめ:

  • Amon2は非常にシンプルなWAFで、使い勝手がいいのでおすすめ。
  • WAFは好み e.g. Catalyst, Mojolicious
  • Amon2はコードも読みやすいし複雑なことをしていないのでオススメ

簡単なWAFと呼ばれたAmon2のことが概観できて楽しかったです。

「DancerでWebアプリ再入門」 @aloelightさん

こちらもHokkaido.pmの顔ともいえる@aloelightさんのお話。札幌の会社でPerlの開発やインフラまわりをお仕事にされている方です。

今回のHokkaido.pm#7のテーマ「Webアプリ「再」入門」ということでDancerを使ってみた話。

先行の発表者が宣言したWAFを除いて、残ったものがCatalyst、CGI::Application、Kossy あたり…; その中で一番簡単そうで世界で知名度が高かったのが Dancer だったとのこと。

早速ウェブアプリを作ってみたとのことです。文字通りの機能を持つ「AWS Health Info」

  • Twitterアカウントでログイン
  • AWS Service Health をチェック
  • 登録者にお知らせ

次の一声「間に合いませんでした!」惜しい!業務でAWS触り始めた私も「AWS Health Info」に興味津々だったのに…;。

次にDancer の紹介と特色を紹介。特徴としては以下のようです。

  • Sinatra系のPerl整WAF # 最初から
  • すっごくシンプル
  • 豊富なプラグイン
  • 意外と豊富なドキュメント

インストールは簡単「$ cpanm Dancer」。依存 CPAN モジュールも少ないのだそうです。

Sinatraライクな文法なのは前述で触れられましたが、まさかサブルーチンリファレンスで文字列を返却するだけでレスポンスが書けるとは…; → use Dancer; get ‘/’ => sub { return “Hello, world”; }; dance; # これだけのスクリプトで 5000 番ポートで待ち受けるdaemonの完成。

もう少し複雑なアプリケーションの場合は「$ dancer -a MyApp」とするとスケルトン雛形が作成されるのでMyApp/lib/MyApp.pm にアプリを書くとよいそう。シンプル。基本は use Dancer; するだけ。

豊富なプラグインもあります。現時点で Dancer::Plugin 系が 94件。

メジャーなPluginのご紹介。

  • Dancer::Plugin::Database
  • Dancer::Plugin::DBIC
  • Dancer::Plugin::Email
  • Dancer::Plugin::Thubnail
  • Dancer::Plugin::Facebook

もっと知りたい方は「Dancer plugins ecosystem」http://advent.perldancer.org/2011/17 へGo!、だそうです。

Pluginの作り方も簡単とのこと。

ドキュメントも豊富。

  • Dancer::Introduction
  • Dancer::Tutorial
  • Dancer::Cookbook
  • Dancer::Plugins
  • Dancer::Deployment

Dancerの基本文法をご紹介。ここらへんは上述のように簡単。詳しくはスライドや動画を御参照いただけると良いと思います。Config、Cookie、Session、Templateにもそれぞれ独特のDSL構文(所定のオブジェクトを返す0以上の引数サブルーチン)があって、簡潔さを目指しているなぁというところが伝わりました。

ちなみに標準のテンプレート Dancer::Template::Simple には IF,LOOPが無いので Dancer::Template::TemplateToolkit を代わりに使いましょう、とのことでした。

データベースもやっぱりシンプル。use Dancer::Plugin::Database; をすると database というDSL構文が使えるようになってシンプル。前述の Config 等についても、use Dancer::Config をすると config 構文が使えて同様、等々。

これも前述のようなDSL構文が徹底されたリダイレクトやロギングといった部分を解説し終えた後、AWS Health Info のソースコードを読みながら、その雰囲気を味わいました。

やはり前述のような構文が多様されているため「MojoliciousやAmon2と違って $ が少ない」のが特長とのこと。

Twitter連携についてアドバイス。

  • Net::Twitter は Moose 依存
  • Net::Twitter::Lite はそうじゃないのでそっちを使おう

テストには Dancer::Test というのが用意されているので、それを調べて使いましょう、とのことでした。

感想としては、インポートされるDSL構文(詳細を説明すればオブジェクトを返すサブルーチン型のシンボルようなもの)が多くなるものの、メモリ等のコストとしては大したこと無いでしょう。こういうコンセプトのWAFも興味深い。ただ、日本での使用者人口がまだそれほど居なさそうで、何か困ったときの拠り所や頼れる人が不足しているのではないかという一点のみが懸念点でした。それ以外については、これほどシンプルさを目指したことに感心しきりでした。

「Mojoliciousをウェブ制作現場で使ってみてる」@jamadamさん

前回の Hokkaido.pm#6 の二次会で「初対面」して熱いトークをしたのが @jamadam さんでした。その時は全然知らなかったのですが、氏は Mojolicious のヘビーユーザ。英語のMojolicious ML へのコミットや、GitHub に自作の Mojolicious アプリケーションを精力的にアップしている方でした。私も @jamadam さん作だと知らずに使っていた Mojolicious アプリケーションもあって驚いたくらいです。北海道、Hokkaido.pmは、知れば知るほど猛者の集まりです。北海道出身の私は当然北海道ひいきですが、東京の人は地方を見くびっちゃいけない!

Mojolicious は現在の Perl WAF の中でも情報がいっぱいあります。

  • Mojoliciousアプリを簡素に記述できるMojolicious::Lite
  • MojoliciousというWAF
  • Mojoというモジュール群

このあたりの話をまずざっくりと解説されました。モジュール群の継承関連図の美しさ(本人作)には会場も息を飲みました。

最小のMojoliciiousアプリの例示「use Mojolicious::Lite; app->start;」

話はMojoliciousのモジュールMojoの構造の話へ。このあたりは内部設計まで踏み込んで解説されました。そしてMojoやMojolicious関連クラス群の親クラスMojo::Baseの使い方へ。

Mojoliciousはバージョン2.0からPerl5.8サポートが切られ、Perl5.10以上を必要とするようになってしまい、困ったのでmojo-legacyを作ったとのこと。レガシーな環境へのデプロイの仕事を多く持つ @jamadam さんならではの作品ですが、その原動力には感心するばかりです。ただし、本家Mojoliciousのいくつかのテストが失敗するのが困っているとのこと。それでもmojo-legacyは実践投入されているようです。mojo-legacy の話は紹介で終わり。

本題は「ウェブ制作の現場ではデザイナー主導で組みあがったサイトに動的コンテンツを後付けすることが多い。」「それってPHPが最適解」「でもPerlでやる」という一連の流れ。やっぱりPerl!

実践コードをいくつかご紹介されました。紹介された処理をプラグインにまとめたりもしたそうです。詳細はスライドや動画を御参照ください。

感想としては、WAF素人の私としては、今使うなら日本でも使用者人口が増えてきた Mojolicious かなぁ…;と考えていたので、非常に参考になるトークでした。@jamadam さんが内部設計に詳しくそこにフォーカスをあてたトークだったため、前2つのAmon2やDancerのトークよりも難解さを感じはしましたが、まずは Mojolicious::Lite からコツコツとためしてみようと思います。

「Ops Tools with Perl」@riywoさん

東京から招待されたDeNAの @riywo さんによる Ops (運用) 関連のトークです。

Ops に役立つ Perl 製ツールの紹介をしてくださいました。

まずは有名な @kazeburo さんによる作品 CloudForecast。中身のウェブインターフェースはWAFなのですが、Kossyの元祖であるShirahata.pmというものを使っているのだそうです。Shirahata.pm、名前すら聞いたことありませんでした。

次は GrowthForecast の紹介。こちらのウェブインターフェースは WAF Kossy とのこと。

話はウェブから離れつつ、「はかどる系」のお話へ。

Alien::RRDtool の紹介。名前の通り RRD のモジュール。

chase-tail というツールの紹介。@hirose31 さん作。tail をしながら、指定したものがあればお知らせしてくれる系(だったかな)。これはシンプルなツールゆえ、すぐに活用ができそうです。以下のようなコマンドラインですぐに使えるそうです。

$ tail -f error_log | chase-tail -l 10 -t various_error

そして App::Ikachan のお話。@yappo さん作。これは私も使っています。簡単なHTTPでしゃべらせることができるIRCボット。障害が起こった時等、curl 等のよくあるHTTPクライアントツールで ikachan を叩けば、ikachan が IRC 上ですぐに教えてくれるといった使い方。

@riywo さんは「Touryo」というツールを作っているそうです。コンフィグ管理ツール。ただ、まだソースコードを出すことができないそう。会社でコンフィグ管理の必要性が発生した際に、ChefやPappetでは収まらない要求があったために自作したとのこと。基本はCLIツールだが、ウェブ管理画面もあって、それはAmon2中心に作っているのだそうです。

コンフィグはサーバごとに微妙に違ってくるケースがあって、それが既存ツールでうまくできない部分なのだそう。Touryo、公開が待たれますね!

内部的にはサーバにSSHしているけど、Net::SSH は ~/.ssh/config を読まないので使わなかったとのこと。そういう制限があるんですね。IPC::Cmd で ssh を呼び出すというスタイルを取っているそうです。これなら ~/.ssh/config も反映される。

最後に「どんな言語を使えば良いか?」という問いかけ。色々なスタイルの言語がある。スクリプト型、コンパイル型といった分類。手続き型、オブジェクト指向、関数型言語といった分類。普及しているか否かといった分類。

やはり選ぶとしたら普及している言語を選ぶべきという話。ライブラリが充実していることと、みんなが読めることがその理由

そしてTouryo等でPerlを採用したのは「I love Perl」だから。早く書けるし、なにより自分の周りにPerl Mongerがたくさんいたこと、そしてCPANの存在。

感想としては、私の会社ではインフラや運用はプログラマや開発とは部署が完全に分かれていて、インフラや運用で専用ツールを作るといった発想が無かったです。インフラ部署に行くとプログラムからは離れてしまって寂しいのではという印象すら持っていた。もちろん、既存ツールを使うという選択肢はインフラ部署で取られてはいますが(Nagiosとか)。私も元々インフラ志望だったこともあり、プログラムで「はかどる系」を促進していく、@riywo さんのようなインフラ運用を担うプログラマに憧れを抱きました。

LT

ここはメモが欠落しているのですが、記憶では1枠のLTがあったのみで今回は枠が2つ余っていました。冒頭で書いた通り、会社から「発表すんな」と言われていたのですが、こっそり秘蔵ものを持っていたので、空いているLT枠の話を聞いた時に休憩時間の10分間で簡単なスライドを作って「飛び入りLT」をやってのけました

このLTには動画がありません。会社にバレたときに怒られる可能性があったので、Ustreamを切ってもらったのでした。その後、会社から「それくらいいいんじゃない」と言われたので安堵しましたが…;。また、当初のスライドは10分で作った15枚くらいのスライドで、実際は後半3分ほどは拡大したEmacsにコードを移してカーソルを動かしながら解説したのでした。

私は mod_perl Hacker (Baka) として Hokkaido.pm で前2回トークをしているので「今回もmod_perlで無茶しやがって…;」といった笑いを頂くことができて嬉しかったです。テーマに従って、素の mod_perl を WAF っぽくするという無茶ネタ。興味ある方はぜひスライドをご覧ください。

その後

それでも余ったLT枠の時間で @onagatani さんが Hokkaido.pm についてのお話をされて、さらにそれでも余った時間のため、いつも押し押しになるにも関わらず時間を余しての終了。

懇親会までの時間も必然的に余るわけで「もう懇親会の会場に行っちゃおうか」という声が自然と沸き起こり、普段は19時あたり開始の懇親会をが17時45分に始まることになりました。

懇親会

居酒屋の座敷部屋での懇親会でした。東京からいらっしゃった@riywoさんのために、北海道の海の幸が存分に振舞われました。「カニの刺身が食べられるのはHokkaido.pmだけ」。美味しいものが食べたい方はぜひHokkaido.pmへ行きましょう!トークの質も(私は置いといて)みんな濃い!今最も熱い地方.pmのひとつと断言して良いのではないでしょうか。

二次会

バーのようなところに入ったのですが、すし詰め部屋に押し込まれてトイレに行くだけで大混乱、しかも外野が騒々しい(ダーツやってた?)という中々の環境でしたが、懇親会で入ったアルコールで皆さん打ち解けて話ができました。

三次会

三次会恒例のラーメン。@onagatani さん自信のコースです。東京からいらっしゃった方々も札幌ラーメンに舌鼓を打っていました。

そして、開始が早かったことで、Hokkaido.pm にしては異例の23時解散となりました。結果的に開始が早かったことで解散も早く、身体への負担も減った感じです。次回も懇親会は17時45分開始くらいにしても良いのではないでしょうか。

まとめ

結局長文になってしまいましたね…;。ここまで熟読してくれた方、飛ばしながらも読んでくださった方、ありがとうございます

当日リアルタイムにEvernoteにメモを取っていたので、トークの概要の大方はコピペ修正で編集しています。それでも執筆時間は2時間ほど。遅筆…;(なのかな)。でもせっかくの熱いHokkaido.pmの活動、なるべく活字として残しておきたいという思いをどうか汲みとってやってください。

Hokkaido.pm#5 で初pm参加 + 初トークをしてPerl仲間が劇的に増えました(YAPC::Asia Tokyo は2007年から参加しているけどいつもぼっちでした)。東京在住ですが北海道出身の私にとって、Hokkaido.pmは文字通り私の故郷でありパワースポットであり、意欲や情熱などの大切なものを色々頂いている本当に素晴らしい場所です。主催の @onagatani さん、@aloelight さん、その他常連の皆さん、本当にいつもありがとうございます。次回も都合をつけて絶対に参加します!今から本当に楽しみです。

Perl Beginners#2 に参加してきました #perlbeginners

こんにちは、Perlビギナーの おがた (@xtetsuji) です。

2012年4月27日に、東京の文京シビックホールでPerl初心者向けのイベント「Perl Beginners #2」が行われ、参加してきました。

当日の実況等はTwitterでも #perlbeginners ハッシュタグで流されていて、私がそれを以下にトゥギャりました。Twitterに流されていない感想ブログについても、見つけたものは末尾に載せました。当日の雰囲気を把握する上では、こちらをザッと読んでみると良いかと思います。

以下は、私から見た Perl Beginners #2 です。

あまり皆さんとは関係ない事なのですが、2012年3月1日に当社の開発部署にも新人さんが入社。ようやく、開発部署が1〜2人というごく僅かな事態が改善されつつあります。ただ、新人さんは実は前職がIT業界ではないこともあって「ここにいる1〜2人の人間が開発者の象徴だと思われると困るな、もっと広い世界のたくさんの開発者像を知ってほしいな」という思いがあり、ビギナー向けと呼ばれるこのイベントに参加してみることにしました。強制参加にはしたくなかったので、最初は都合が良くて気が向けば…という感じで誘ってみたところ、好意的に参加してくれることになったのでとても良かったです。意欲が高いその姿勢は素晴らしい。その後、会社からも公式に勉強してきてね(交通費が出て勉強会の時間中は出勤扱いになる)ということになって、最近は会社の理解もあるなぁ、と色々ありがたく思ったのでした。

私もPerl歴というかPerlを本気で書き始めてから9年ほど経過しましたが、偏った知識ばかりが蓄積して一般的な知識という意味での成長が見られないので、このイベントでいろいろ勉強させてもらえればという気持ちで参加しました。

初参加のイベントだったので、緊張しつつも会場入り。

既に主催者である @ytnobody さんによって会場設営が完了していました。

PerlBeginners#2 会場の様子

JPAさんの補助により、会場代はタダ、すなわち参加費もタダ!JPA++。また、JPAからのゲストに @zigorou さんがいらっしゃっていました。

主催者の @ytnobody さんに「写真撮ってね!ブログでレポート書いてね!雰囲気伝えてね!」と発破をかけられていたのですが、あまりたくさんの写真を撮ることができませんでした。場慣れしていない初参加イベントだと、どうも動きが鈍る…。

以下、当日のタイムテーブルが書かれたホワイトボードです。

PerlBeginners#2 当日のタイムテーブル

ビギナーズセッション

この「ビギナーズセッション」というのは、発表者が自分が今取り組んでいることを発表しつつ、聴衆に向けて「もっと良いやり方がありますか?」と問いかけるというもの。主催者とゲストの知識人が答えてくれるという面白い試みです。

まずは @c_tyo さんによる質問。ajax.cgiというPerl CGIをjQueryの$.ajax()で叩いてFacebookのような(画面遷移の少ない)ページを作っているが、もっとよい方法があるか、というもの。

知識人からの回答としては、やはりCGIよりもPSGI/PlackベースのWAFを使ったほうがいいのではないか、JSONの扱いならJSON.pmでやったほうがいいのではないか、という回答でした。

次は @i4djunichi さんによる質問。開発環境で作ったものをどのように本番環境にデプロイすればよいか、という話だったと思います。ただ、開発環境と本番環境でOS環境やCPANモジュールのバージョンが違うと…という話から、話題はバージョンを保持するといった話へ。

知識人からの回答としては、DarkPANやOrePANの話が出てきました。私もOrePANは知っていましたが、DarkPANのことは良くわかっていなかったのですが「DarkPANの実装の一つがOrePAN」ということでいいのかな。DarkPAN⊃OrePANという包含関係。

local::libというキーワードも出てきましたが、cpanmの登場によりそういうこともあまり気にしなくなりましたよね。ちなみに私が勤める会社では主にDebianを商用環境に採用していて、自社開発モジュールに関しては、適当な場所にバージョン管理システムから落としてくる、または rsync で転送したモジュールのトップディレクトリを、perl -le ‘print for @INC;’ して出てきた include-path のうちのどこか、大抵は /usr/local/lib/site_perl/ 以下に symlink を作るという方法で解決しています。コアのPerlやCPANモジュールについては、基本的にDebianパッケージになっているものしか使えず、そうでないものはインフラ部署にお願いしてDebianパッケージを作ってもらう流れなので、local::lib や lib などといったプラグマのお世話になることは皆無ですね。ちなみに、商用環境でのcpanmの使用は現状は事実上できない状況です。このあたりは開発部署主導というよりもインフラ部署主導なので私には意見を出せる部分ではなくて…。このあたりは、世間の会社とはちょっと違うところかも。

そしてちょっと早い休憩。

LT

@ytnobody さんによるLT。「PSGIへの誘い」というようなお題で、無名サブルーチンと配列リファレンスがあるだけの、非常に簡単なPSGIアプリを書いて、PSGIが簡単でこれからウェブアプリケーションを書く人にPSGIがオススメであることを分かりやすく解説していました。ちょっとしたハプニング(?)からか「ライブコーディング」が見られたのは、結果的に面白かったと思います。

「PSGIは難しくない」というメッセージ。ただ環境には、トークの中で触れられていた「SSH等でシェルを実行出来る環境であること」「プロセスを常駐させても怒られないこと」「必須じゃないけどperlbrew+cpanmが使えること」の3条件を満たす必要があるのは要注意。そのために、VPS等の環境をご紹介されていました。自宅サーバは色々敷居が高いにしても、「さくらのVPS」の最小構成であれば月額980円でこれが手に入りますし、ちょっと癖があるにしてもdotCloudを使えるようになるとある程度の範囲までは無料で作れるようになるので、良い時代になったなと思います。むしろdotCloudはPerl CGIのデプロイは無理で、PSGI/Plackアプリしかデプロイできなかったんじゃなかったな(この前見たけど調査サボり)。

「Twitterでハッシュタグ #perl を付けて「教えてください」っていうと意外に偉い人が教えてくれる。」という心強い話も。あんまり教えて君になるとdisられそうなので、困ったときの奥の手として使いたいところです。

このプレゼンテーション資料は @ytnobody さんによるページにて公開されています。PSGI/Plackが良く分からっていない人(自分含む)にとってとても参考になる導入資料ですので、一度目を通してみるとよいと思います。

私の会社では、以前は半分くらいCatalystを模倣した自社WAFがあったことがありましたが、現在は世間で言われているようなWAFといったものでの開発がなされていない状況です。ただ、PSGI/Plackの基盤がだいぶ固まった今だからこそ、今後新規で立ち上げるプロジェクトでは、何らかのWAF(Mojoliciousあたりを検討中)でPSGI/Plackの恩恵にあずかりたいと考えています。

次は @pohtarou さんによるLT。WAF(Webアプリケーションフレームワーク)「Kossy」によるWebアプリケーション作成のトークでした。Kossyは@kazeburoさん作のWAFでSinatra(RubyのWAF)風、簡単にWebアプリケーションを作ることができるというものです。

トークの中で「ストーカー力」という言葉が出てきたのが興味深かったです。「とりあえず書く」「ネット上をくまなく探す」そしてその作者に質問をぶつけるという意味だったかな。

とにかく疑問・質問・賛辞は作者にどんどんぶつける。多くは返答が返ってこないかもしれないけど、その中からバグが発見できたり自分の疑問が解決できたり、作者が喜んだり、色々良い事があるのかなと改めて思わされたトークでした。

質問タイムに「Kossyで作った商用サービスはありますか?」という質問をしてみました。まだ、社内サービスでの投入の段階とのことでした。

次は @irmr_log さんによるLT。「Perl歴2年ちょいで、LTもパワポも初めて」だそうです。その割には場慣れしている感じでした。

トークの内容は、HTTPヘッダ、W3C、MIMEタイプなどを解説した後、Webスクレイピングをするという話に到達。LWP::UserAgentが基盤としているモジュール、HTTP::{Response,Headers,Message} 辺りを解説した後で、この中にある文字コード判定コード $res->decoded_content() に着目してひたすらそのコードを解説するというガチンコトークでした。

たぶん、プレゼン資料に細かい字で書かれたコードをここで読めというわけではなく、雰囲気としてスゴイ大変なことをしているんだということが分かること、あと実際に動いているCPANモジュールのコードの中には色々なエッセンスが入っていてソレを読むことは勉強になる、という理解でよいのかもしれません。

文字コード判定といえば、Perl5.8から登場したEncode::Guess、またスクレイピングモジュールとして有名なWeb::ScraperやWWW::Mechanize等については割愛とのこと。自前でWeb操作系クラスを書くときにはdecoded_content()のコードをうまく活用するとよいかも、とのことでした。また、LWP::UserAgentを用いたコードを使うとき「コンテンツ取得部のデコード処理が適切か」といったことを抑えておくと良いという話もありました。

JPAセッション

JPA(Japan Perl Association)からゲストで来られた @zigorou さんより、今後のJPAの活動まわりのお話がなされました。本人曰く「技術系以外のプレゼンは初めて」とのこと。内容も、JPAという組織の活動といったことが大部分で、Perlのコードは一行も出てきませんでした。

まずは組織と新しい理事のお話。

PerlBeginners#2 JPAのスライド

@shakuji さん、@nekokak さん、@ktat さんが新しい理事に迎えられたというご紹介。

その次は活動報告について。JPAは首都圏や地方のPerlコミュニティの勉強会やイベントを支援しているという内容。私もこの制度のお陰で、札幌のHokkaido.pmで著名な方にお会いできたりして、非常にありがたいです。

さらにperldoc.jpのお話。個人所有だったものをJPAが買ったとのこと。今はperldocの和訳が読めるというサイトだけど、今後は日本のPerl情報が集約されて読めるきちんとしたサイトにしていきたい、そのためにデザインもid:nagayamaさんにお願いすることが正式に決まったとのことです(このあたりの話は先日Ustreamで拝見したKyoto.pmでもid:nagayamaさんが直々にお話していた気がします)。

そしてみんな気になる「YAPC::Asia Tokyo 2012」の話。テーマは「Take Another Step Forward」。ゲストは以下の豪華メンバー。

  • Gosuke Miyashita (a.k.a. mizzy)
  • Tim Bunce
  • Adam Kennedy
  • Larry Wall

その他「IRC(freenode)に入ろう」「ボランティア募集中(Join #yapcasia-staff@irc.freenode.org)」といったお話で締めくくられました。

昨年2011年から私の会社もYAPC::Asiaのスポンサーになることができましたが、今年も会社と相談をして、スポンサーを継続できるように働きかけていきたいと思いました。また今までperldoc.jpの情報にお世話になった恩返しとして、新perldoc.jpサイトの和訳等のボランティアで協力できることがあればしていきたいと思った次第です。

撤収

みんなで片付け。

片付け最中に、懇親会には出られないという @zigorou さんと少しお話させて頂きました。Hokkaido.pmでちょくちょく発表している私を伝え聞いていたとのことで、著名な方に知っていただいているとは本当に嬉しい限りでした。

懇親会

懇親会の会場は水道橋駅の近く。文京シビックホールの春日駅近辺からしばらく歩きました。

懇親会への参加は12人。全員男性でしたが、本体のほうには女性の参加も数名いました。

個人的にIT業界で男性女性をことさら分ける意義は特に無いとは思うんですが、大学や専門学校等で最近は扱われる機会の少ないPerlを勉強していこうという方が男性女性問わず増えていくことは、とても好ましいことだと思います。

PerlBeignners#2 懇親会

懇親会では酒が入った熱い話が続きましたが、途中からついつい私の偏ったPerlの知識の総決算でもある mod_perl について熱く語ってしまいました。同席の方、申し訳ありませんでした。私がここまで mod_perl に傾倒することになった経緯については、どこかでまとめて紹介できればと思います。

各自色々な話で盛り上がった後、終電が迫っている方から順に解散していきました。

最後に

次の開催は2ヵ月後、6月29日(金)を予定しているとのことです。隔月開催なのかな。非常に有意義な勉強会でしたので、次回もぜひ参加させていただこうと思います。