こんにちは、地元が北海道の おがた (@xtetsuji) です。
このブログを書いている今が2012年5月11日なので急といえば急なのですが、2012年5月11日から15日まで北海道に行きます。
札幌や帯広で上記日時周辺で都合が付いて会いたいという方がいらっしゃったらぜひ連絡下さい。遊び語りましょう。
こんにちは、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 さんによって会場設営が完了していました。
主催者の @ytnobody さんに「写真撮ってね！ブログでレポート書いてね！雰囲気伝えてね！」と発破をかけられていたのですが、あまりたくさんの写真を撮ることができませんでした。場慣れしていない初参加イベントだと、どうも動きが鈍る…。
以下、当日のタイムテーブルが書かれたホワイトボードです。
この「ビギナーズセッション」というのは、発表者が自分が今取り組んでいることを発表しつつ、聴衆に向けて「もっと良いやり方がありますか？」と問いかけるというもの。主催者とゲストの知識人が答えてくれるという面白い試みです。
まずは @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の使用は現状は事実上できない状況です。このあたりは開発部署主導というよりもインフラ部署主導なので私には意見を出せる部分ではなくて…。このあたりは、世間の会社とはちょっと違うところかも。
そしてちょっと早い休憩。
@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(Japan Perl Association)からゲストで来られた @zigorou さんより、今後のJPAの活動まわりのお話がなされました。本人曰く「技術系以外のプレゼンは初めて」とのこと。内容も、JPAという組織の活動といったことが大部分で、Perlのコードは一行も出てきませんでした。
まずは組織と新しい理事のお話。
@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」。ゲストは以下の豪華メンバー。
その他「IRC(freenode)に入ろう」「ボランティア募集中(Join #yapcasia-staff@irc.freenode.org)」といったお話で締めくくられました。
昨年2011年から私の会社もYAPC::Asiaのスポンサーになることができましたが、今年も会社と相談をして、スポンサーを継続できるように働きかけていきたいと思いました。また今までperldoc.jpの情報にお世話になった恩返しとして、新perldoc.jpサイトの和訳等のボランティアで協力できることがあればしていきたいと思った次第です。
みんなで片付け。
片付け最中に、懇親会には出られないという @zigorou さんと少しお話させて頂きました。Hokkaido.pmでちょくちょく発表している私を伝え聞いていたとのことで、著名な方に知っていただいているとは本当に嬉しい限りでした。
懇親会の会場は水道橋駅の近く。文京シビックホールの春日駅近辺からしばらく歩きました。
懇親会への参加は12人。全員男性でしたが、本体のほうには女性の参加も数名いました。
個人的にIT業界で男性女性をことさら分ける意義は特に無いとは思うんですが、大学や専門学校等で最近は扱われる機会の少ないPerlを勉強していこうという方が男性女性問わず増えていくことは、とても好ましいことだと思います。
懇親会では酒が入った熱い話が続きましたが、途中からついつい私の偏ったPerlの知識の総決算でもある mod_perl について熱く語ってしまいました。同席の方、申し訳ありませんでした。私がここまで mod_perl に傾倒することになった経緯については、どこかでまとめて紹介できればと思います。
各自色々な話で盛り上がった後、終電が迫っている方から順に解散していきました。
次の開催は2ヵ月後、6月29日(金)を予定しているとのことです。隔月開催なのかな。非常に有意義な勉強会でしたので、次回もぜひ参加させていただこうと思います。
こんにちは、「情報はなるべくオープンな場所に」をモットーにTwitterを活用している おがた (@xtetsuji) です。
先日、4月24日になりますが、「Twitter API勉強会」に行ってきました。今回からタイトルに回数が入らなくなりましたが、前回が第5回なので、今回は第6回ということになります。毎月月末開催の活発な勉強会の一つです。
私は今回を含めて3回連続の参加。前回は(グダった)トーク(Slideshare)をしましたが、今回は純粋に聴衆側として参加してきました (今回のfoursquareチェックイン)。
前回同様、公式サイトは無いようですが、Zusaarのイベント開催ページや、Togetterのまとめがあります。
今回の会場は、前々回(第4回)に行われた御茶ノ水のデジタルハリウッド東京本校さんでした。
最初のトークは、@yusukeyさんによる2012年5月12日に変更されるとアナウンスがあったAPIのお話。
このトークは多くのTwitterを使ったサービスの開発者に興味深い事柄ですが、幸いなことにSlideshareで公開してくださっています(2012年5月14日のAPI改訂 概要、Twitter API利用規約概要)。また@yusukeyさんによるブログ記事「第6回Twitter API勉強会を開催いたしました – ビデオ・スライドまとめ #twtr_hack」にてこのトークを含む当日のビデオがとスライドがまとめて観られます。
大きく分けていくつかのセクションに分けて解説をされていました。
とりあえず「II. Principles」を読んでおけばOKだそうです。憲法のようなもの。
詳細は、上記リンクからたどってください。以下は自分の手元のメモより。
「I. Twitter Content」のメモ。
「II. Principles」のメモ。
「憲法のようなもの。これを読んでおけばひとまずOK」
「III. Twitter Functionally in your Service」のメモ。
「IV. Commercial Use」のメモ。
「V. Other Legal Terms」のメモ。
これはよくある免責事項のようなものですね。いちおうポリシーとしては1ヶ月前までには変更はアナウンスされるとのことです。
「アプリ/サービスローンチチェックリスト」のメモ
「5月のAPI改訂」の概要メモ。
具体的なAPI改訂については、一覧 https://dev.twitter.com/docs/deprecations/spring-2012 を参照するか、上記スライドorビデオを参照いただけると分かると思います。メモの転記に疲れた？いや、ここは開発に関わる部分なので公式に近い情報を当たって欲しいという理由です(言い訳？)。
当然の流れかと思いますが、今後のTwitter APIはJSON中心になっていき、今回でAtom形式のエンドポイントが無くなります。今後、XML形式も無くなるかもしれない、とのお話もありました。
@kn さんによるTwitterの国際化のお話。
現在のTwitterは28ヶ国語。50万人のボランティアが翻訳をしているそうです。その翻訳の受理の流れなどを解説してくださいました。
twiccaの作者 @R246 (アオヤマテツヤ)さんによる、AndroidのTwitterクライアント「twicca(ついっか)」の話。
もともとはPHPやJavaScriptやももクロ(?)等のサーバサイドエンジニアだったそうですが、Android初期のTwitterクライアントのあまりの出来の悪さに「つい、カッ」となってつくったのが「twicca」だそうです。「当時はJavaとか知らなかった」という発言もありましたが、「つい、カッ」となった勢いはすごいなと思いました。
ネタが無いので、Twitterで「twiccaについて聞きたいこと」というツイートを流してみたとのこと。
twiccaを開発しようと思ったのは2009年7月当時、満足いくTwitterクライアントがなかったから。前段のお話です。
twiccaではユーザに「色」を割り当てることができるのが特長。クラスタごとに色分けをしたりすることで、タイムライン上の視認性をあげることができる。これは大事なツイートを見逃さないためのツイートなので「カラーラベルのご利用は計画的に」とのこと。
バックアップ/同期を実装しない理由→クラウド同期がかっこいい→クラウド同期ができない理由→サーバ料金を賄えない。
「twiccaサポーターズ」というのがあるそうで、twiccaの開発支援プログラムのようです。シェアウェアではないけど、twiccaを金銭面で応援したい人のための制度。目立つ告知はしていないそう。これに参加するとアプリ内の「twiccaについて」に名前が掲載されるらしい。「twiccaは儂が育てた」と言ってよいそうです。
「例の脆弱性」JVN#31860555 についてもお話がなされました。
「お金を積まれたら売る？」という質問には「売りません」とハッキリ発言。「サポーターズが居る限り」。カッコイイ。
最後にtwiccaアイコンの変遷を解説されて終わりました。
私も寝かせているAndroid端末があるので、ぜひそれでtwiccaを使ってみたいと思いました。
@i2key さん。リクルート(MTL?)の中の人。
「 マイクロコンテンツ化」という仮説を打ち立てて「3文字の絵文字」で情報を伝達できないか、というサービス「さんもじ絵文字できもち伝わる！Happy Balloon」の紹介をされました。
これはタイトルからも分かるようにネタLTの傾向もあって、動画のほうが場の面白さの雰囲気があるので、時間に余裕のある方は動画のほうをご覧いただくと良いと思います。
@tkawa (川村徹) さんによる、返信と@ツイートのTwitter仕様に対する提案のお話。
真面目なお話でしたが、個人的にこれはかなり有意義なトークでした。返信というメタデータと、返信と扱われるか扱われないか現状曖昧な「@ツイート」の仕様について、もっと明確に良い方向になっていって欲しいと思わされました。
詳しくは当該スライドをご覧いただくといいかと思います。
@yut148 さんによるdotCloudを使ったウェブアプリ開発のお話。クラウドを大量に使っているゲーム会社 or エンタテインメント会社に所属して、普段はPHPやPythonを使う方らしいです。
dotCloudを使えばとりあえずドメイン名は振られるので、Twitterのアプリ開発に必要なドメイン名を確保することができるとのこと。それに最初はFree！
Freeアカウントの制限は「登録できるアプリは2つまで」「ディスク容量」とのこと。
dotCloudはPHPやPythonだけでなく、様々な言語の様々な環境が選べるので、今後PaaSの環境として要注目かもしれません。2サービスまでなら無料で作れますし、より複数のサービスを作るのであればディレクトリ構成を工夫したりすることでやりくりできるらしいです。
@yut148 さんは本当にdotCloudが好きな方なようで、dotcloudユーザ会(仮称)を作って活動をしはじめているとのことです。
「困ったら@yut148 に質問送っていただければベストエフォートで答えるよ。」という心強いお言葉も。
私も以前、無料だったのでdotCloudにアカウントを登録したっきり使っていなかったので、これを機会に今度時間を作っていじってみたいと思いました。
情報源
今まで一通りAPIやったので、次回は「Twitter API勉強会」から違う名前に衣替えをする予定だそうです。名前募集中。
スピーカー常に募集中!
今回は貸し会議室での「立食パーティ」形式ではなく、会場すぐ近くの居酒屋での開催となりました。
当初自分が懇親会に申し込んだ時には定員割れになって開催されないのではないかと危惧していましたが、駆け込みで多くの方が参加されて、居酒屋の予約席は満席状態になりました。
Twitter API勉強会といいつつ、私の席ではTwitterの話よりもコンピュータ昔話に花が咲いていた気もしますが、それもまた一興でしょう。
定期的にTwitter開発の旬な話が聞けたり、著名なTwitterクライアントの作者の方のお話が聴ける、この勉強会。非常に有意義でして、私もかれこれ3回の参加をしていますが、今後も予定と体調が許す限り、参加して勉強させていただきたいと思いました。