2013年11月26日

yapc hackathon の後の飯で「最近 perl のイベント少ないからもうちょっと頑張ろうぜ！」って話になって、とりあえず plackcon やろうぜ！ってなったので開催しました。

やろうと決めたのは9月末だったけど、実際動き出したのは2週間前でとりあえずダブル基調講演の fujiwara さんと kazeburo さんの予定抑えて会場抑えて1週間前にスピーカー全員決まって募集した感じでございました。
fujiwara さんに ISUCON3 で新たに得られた知見を話してもらおうと思ってたのに実際の ISUCON3 は HTTP レイヤーの問題は殆どなくてまったくアテが外れてしまって fujiwara さんに多大な苦労を書けてしまって申し訳ありませんでした！１事前に出題内容さえしっていれば。。！

80人くらい集まる勉強会的なのやった事無かったけど、なんか知らないけど事故も喧嘩もなく終わって良かったです。 soozycon くらいのノリでも何とかなるんですね。
受付してくれたり門番してくれたり、帰りのカード回収してくれたりトイレまでの経路が無いの教えてくれたりした方々やスピーカーの方々や、ゆるふわな進行に耐えてくださった皆様並びに会場を貸してくれた LINE さんありがとうございました！

トイレのとこのドアはなんか僕でも解放出来たらしいので次あったらちゃんと生きようと思います。

ぼくの成果


教訓

「タイムキーパー重要」
つぎなんかやる時にタイムキーパーするひと探してからやります。。

Posted by Yappo at 17:48 | Comments (0) | TrackBack (0) | Perl

2013年11月19日

追記 2014/11/20 14:00:00

わりと JSON やら XML やら各種フォーマットで API を運用している環境がある場合に JSON API の時だけ X-JSON-Status にすると XML とかの時と整合性取れないし、 X-XML-Status みたいのを量産するのは困る的なレビューを頂いたので X-JSON-Status をやめて X-API-Status にしました。

へたに JSON に限定するから REST とか JSON-RPC とかいわれるんや！ X-API-Status にしたら全部解決したし MessagePack な API でも使い回せるって songmu さん言ってた！ XML とかからどうやって引っこ抜くかまで僕考えられないけど！

ちなみに Amon2 の方も X-API-Status にしたのを merge 済み。

始めに

ここ最近の Web 制作の現場ではスマホアプリが主流になってきており、 server side の開発も従来の text/html が主要な content type では無くなり application/json を主に返す server side application を実装する人も増えてきたのではないでしょうか。
いわゆる JSON API ですが、現状これらの仕様は各者それぞれが自由に(ある程度メジャーなサービスの模倣はあるにせよ)行っています。それが良い事か悪い事か僕にはわかりませんが、今回は皆が捗る一つの提案をしたいと思います。

現状の JSON API

一般的な JSON API を作る事を考えた時に、その API が error を発生させる時と言うのは API を使う client の request 内容に不備がある時や、関連する他の API が error を返す時はたまた IO 等がエラーを返した時になると思います。

基本的にはそれらの error 全ては JSON API を開発する人がハンドリング出来る内容なので、適切な JSON を response body として返してる事でしょう。当然 API を利用する client は server side が返す物は全て JSON であるという仮定で実装されてしまってるのかも知れないので(そういう開発者は良く無いけど)、意図しない例外も全て捕まえて JSON にして返す実装もあるでしょう。

HTTP status code

ここまでは割と普通の内容ですね。正常にリクエストが完了する事もあれば error を返す物があります。

これから本題なのですが、もしも認証が必要な JSON API があるとして client からの request が認証を満たさなかった場合の HTTP status code はどうするのが適切でしょうか?
普通に考えると

401 Unauthorized
等を返して {"errorMessage":"unauthorized"} みたいに返してしまうのかもしれません。
そしてちょっと前提が変わりますが、あなたが作っている JSON API が更に他の API を使っていたとします。その API への request が timeout してしまった場合も、同じ方式で行くと
504 Gateway Timeout
を返してしまうのではないでしょうか?

わりとちゃんとしてるサービスの運用をしている人達は全ての HTTP status code を監視して 50x が多く出たら何かの障害がある? 40x が出たらリンク先が切れてておかしいんじゃね?みたいな格闘を日々しています。もし、あなたが書いた JSON API のエラーコードを HTTP status code で表現した場合に運用者にとってのノイズになるかもしれません。ようするにアプリケーションが正しくハンドリングしてレスポンスを返している場合は正常系としておいて本当に問題があった時だけ異常系の status code にする！とかですね。若しくは深遠な理由で通常の HTML application や static contents と同じ host で JSON API をサービスするとかそういう状況も泥臭い世の中には存在するので、そういう時はノイズになりやすいですね。

また、通常 HTTP status code では表現不能な error response を仕様に組み込まれる事も多々あります。そういった場合は結局 JSON の中で {"status":415,"errorMessage":"foo"} とか {"errorCode":415,"errorMessages":["foo","bar"]} などのような表現をするのでは無いでしょうか。

RESUful な人達には怒られるけど、そもそも HTML based な Web Application においては、 client からの入力データの不備は

200 OK
で返した上でエラーの状態を HTML の中に記載して返してるではありませんか。
そういう発想のもと上記の問題を解決する為に「基本的には 200 OK を返して、それとは別に JSON の中で status code を与えて client に処理してもらう」みたいな実装も一つの手段として使われます．

JSON status code の問題

一つ目の問題点としては、ここ最近僕も JSON API を沢山書くようになってきて感じてる事として一般的な web server が書き出す access log に JSON の中の status code が入らない、入れる為には apache の中で JSON をパースするか、 response body 全部をログにつっこむしかない！そんなの現実じゃない！
なぜ欲しいかというと、どの API に大してどんな error を返してるのかを tail log とかして問題解決したい時があったりするんです。現状だと別にログ履くとかしないし一応ログは吐いてるけど通常の access log 以上の情報量のログを常に吐ける程ぼくは人間が出来ていない。

二つ目としては、 response で送られた JSON をパースする必要がないレベルの error があった時に、 client 側に無駄な負担をかけさせちゃう。
これはだいぶ後付けの理由である。

X-API-Status header

そこで導きだされた解決策として JSON の中野 status code を X-API-Status というヘッダで出力するという事。

response header として出力すれば apache の log とかでも

%{X-API-Status}o
とかで出力できるし、 client 側の実装でも header を見るだけで処理の分岐が可能になる。

そして access log に application layer status code が吐き出されるという事は、モリス作の紀香とかを使って直近1分以内に以上系のレスポンスが増えたのでアラートを出すみたいな運用基盤が新たに構築出来る！すべての人類が幸せになるじゃないか！

という事で、皆さんに嬉しいお知らせとして Amon2 で X-API-Status を簡単に出力出来る patch が先ほど merge されたので、これがリリースされればお気軽にこの運用が可能になります。
以下のような簡単な感じで使えます。

    __PACKAGE__->load_plugins(
        'Web::JSON' => { status_code_field => 'status' }
    );
    ...
    $c->render_json({ status => 200, message => 'ok' })
    # send response header 'X-API-Status: 200'

503 などの致命的なエラーはどうする?

それでもやっぱり致命的なエラーは HTTP status code 側で表現されて然るべき、ただし response body は JSON を必ず返す。という感じになってしまうので、 server side で美味しい事だらけなんですが、 client side の実装が負担増える気がしています。
ただ今までも HTTP status code をみてから json.status やら json.error やら、正常系だとそもそも status code がないよ！みたいなカオスだったんで、それが HTTP status code と X-API-Status をみるだけで respnse の状態がわかる感じになっていくから、まだマシになるのかなーとおもいます。

まとめ

  • 近年の JSON API での status code の実装についてまとめました
  • それらにまつわる面倒ごとを改善する X-API-Status header の提案をしました

追記

  • Access-Control-Expose-Headers: X-API-Status は、アプリケーション開発者が状況に応じて返してあげればすむ感じっぽいから、現状大丈夫そうだった


NORIKA―藤原紀香写真集
NORIKA―藤原紀香写真集
posted with amazlet at 13.11.19
大沢 尚芳
ワニブックス
売り上げランキング: 34,355
Amazon.co.jpで詳細を見る
Posted by Yappo at 15:04 | Comments (0) | TrackBack (0) | tech

2013年10月07日

ISUCON 3 っていう、インターネット系エンジニアが全ての技量を試されるガチンコバトルなイベントがあって、kamipoさんとgfxが「あと1人チームメンバー募集！」って言われたのでふらっとパーティに入って参加してきました。

暫定順位みると、大体11位っぽい?

前日

僕は金曜の深夜に飲みすぎ+生ものに当たって土曜日は寝込んでて日曜も朝からダメだった、gfxもなんか体調悪かった、kamipoさんもなんかあれらしかった。

当日合流前

kamipoさんだけ、素晴らしいオフィスで有名なフリークアウト入り。僕とgfxは最初から遅刻宣言。

開始直後

kamipoさんだけawsアカウントの準備してて現地ついてたらしい。僕らは遅刻って言ったからおにぎり食べてたらしい。

合流前

おなかおかしいから、フリークアウトのビルの前でやってた丸しぇに玄米リゾット売ってたので買おうとするも、店員さんがコンビニ言ってたらしく10分くらいまってからリゾット買って合流した。

合流後

10:49 <@kamipo> いまの時点まででやったこと
10:49 <@kamipo> percona-toolkitいれた
10:49 <@kamipo> apacheをnginxに入れ替えた
10:59 <@kamipo> webapp以下をgit pushした https://github.com/kamipo/isucon3

ていうログみたから、とりあえず checkout してみる。

すでに nginx にして800くらいのスコアから2000くらいになったとか言ってた。

ポリシー

他の人がどう思ってたか知らないけど

  • どうせ予選なので決勝進めれば順位にこだわらない
  • 普通の仕事と同じ事をする
  • 運用可能な変更だけする
  • ベンチが早ければいいじゃなくて、引き継いだ人が使える物にする
  • プロセスが落ちてデータロストとかしない
  • 余計なミドルウェアとかいれない
  • というか、元々のシステム作った人が逃亡して仕様書が無い状況で、現状のコードから意図を汲み取って同じ挙動で早く動かす
  • そもそも仕様がガチで reject するレベルで糞だけど友達のサービスを助けると思って目をつぶる
  • さっさと帰って寝たい
みたいなポリシーで進めていこうとおもいました。
というか、二人とこれといって打ち合わせとか意識合わせとか何もしてない。

やったこと

foreach (userid IN memos.userid) { db.execute("SELECT * FROM users WHERE id=?", userid) }みたいな糞みたいなクエリを1個に纏めた
たぶん20%くらい早くなった。

アクセスするたびに users テーブル見る糞実装してるので、直すついでに変更が一切発生しないデータをキャッシュに保存してqueryを減らした

kamipoさんが「ORDER BY created_at DESC, id DESC の created_at は自明過ぎて不要だし index ないから ORDER BY id DESC だけにして」って言ったからした
ここで

13:17 <@Yappo> Result:   SUCCESS 
13:17 <@Yappo> RawScore: 3828.3
13:17 <@Yappo> Fails:    0
13:17 <@Yappo> Score:    3828.3
くらいだった。

memos.is_private で、全体公開とプライベート用のメモのリストの出し分けを辞める
memos.is_private=0 かどうかで、メモ一覧を出し分けると is_private には index が貼られていない、そして 0 or 1 なのでカーディナリティが低すぎる。ということで、パーティションにしようかとも思ったんですが、パーティションにすると自分自身のメモを見るときは is_private の値が関係無くなってコストかかってしまうので、 public な memo_id だけを保存しておく public_memos というテーブルを作りました。
このテーブルは後にも活きてきます。

メモ全件数を保存しとくテーブルを作った
public_memos に呼応した kamipo さんのアイディアでメモの全件を保存しとくテーブルを作りました。 trigger 周りは全部 kamipo さんが言ってた奴で僕の中ではすっかり存在忘れてました。
gfx がメモの全件数を cache にぶっ込んで、メモを追加したら incre するやつ入れてたけど INSERT と incre の間に GET がくるとベンチマークが FAIL するような現象があったのでキャッシュ辞めました。

OFFSET が糞みたいな感じだったので OFFSET 無くてもサーチ出来るようにした
わりと LIMIT 100 OFFSET 13200 みたいなあり得ない感じのクエリが飛んでて、僕とか Senna+MySQL ハックで OFFSET のこういう感じなのやばいの知ってたんですが、どうこう言ってる間に kamipo さんが前述の新規テーブルを組み合わせて良い感じのクエリ作ってました。

前後のメモのリンクの為のIDを効率よくとる
もとの実装が「そのユーザの作ったメモの全レコードとカラムを全部メモリに読み込んでプログラム側でループを回して前後関係を取る。」みたいな信じられない実装だったので KEY(user_id, memo_id) 的な index を追加して1個のクエリで解決しました。いちおう「自分自身の場合は is_private やつをだして、他人のだったら public なのだけ出す」みたいなロジックだったけど、すでに public_memos ってテーブルが別に作ってたのに UNION して解決でした。

既存の users テーブルの内容を cache に乗せる
うっかり忘れてたけど、初期化 SQL でユーザレコードが結構作られていて、この部分のログイン処理とかでキャッシュが聞いてなかったので、ベンチマーク初期化スクリプトでキャッシュあっためるようにしたら2000位スコア上がって11200くらいになった気がします。

考えた事

割と「どーせ SQ Lがダメで IO おかしくなるだろから、まともな SQL にして様子みよう」みたいなノリで DB schema みてから、ざっとアプリケーションコードみて無駄なクエリとか消してました。無駄なループの中で無駄な重複クエリ消すとかそういうのですね。

kamipo さんは逆に slow query log を実直に解析して僕とかに問題点報告してて「これこれこうしたらいいよ！」みたいに言われてたけど、大体僕もアプリ側のコードみて問題把握してて実装してたりするので「そうそう、かんぺき！」ってかみぽさん言ってました。

gfxは普通にプロファイリング取ってたりとかそれの対応とかしてたけど、どっちかというと僕と kamipo さんの見てる問題領域が近くて gfx の方まで見れてなかった感満載だったのが本線での反省点だった。 gfx は xslate まわりのチューニングとか markdown 周りとか starman/starlet あたりしてたのだけは把握してる。

二人とも「想像するな、計測しろ」を自で生きて来た人間だから、僕はそういうのとくにしないでコード見て常識的な事を常識的にやってました。

最初のほうでザックリ作業終わってからベンチとりながら top してたら mysqld があり得ないくらい120%くらいCPU食ってるし io 全然幸ってないから、こりゃありえんって感じで SQL 頑張ってたな。ある程度回復するとようやく CPU が正常になってきて「これから本番」って感じがしてきてよかった。この辺りから --workload 2 とかが意味でてきたし。

どたばた的なの

インスタンス1個でやってたからベンチ回すのに、アナログな queue が発生してたりとか、開発環境ないがしろにしてて git の作業が各人バラバラでおかしくなってたので本戦でれたらどうにかしよう。

とちゅうのどうでもいいこと

あんま意味ないけど plack process に strace してベンチ回してたら js ファイルとかを app server が処理してたから kamipo さんに「なんで static file をバックエンドに飛ばしてるの！」っていったら、 nginx でそのファイル開けない！とか言い出しててよくよくきいたら /home/isucon が 0777 になってたせいで ssh login できないから 0700 にしてから open できなくなったとかだったので「それ 0711 でできるよ」って言って解決した。切羽詰まるとわりとありがちだなーっていう出来事でした！

おわってから

最後の1時間くらいは、割とデッカいリファクタリングしつつキャッシュしてスコア伸ばそうとしてたけど、なんかエラーでちゃったし焦る場所だったけど、焦ったらアウトだからゆるふわにやってて間に合いませんでした。
いちおう間に合わせようとして、酷いコードで実装始めてたら FAIL がでちゃってて kamipo さんがレビュー始めたけど、よく見るレビューしてる時の kamipo さんみたいになってて大変そうだったw

memcached じゃなくて mysql memcache plugin とか言われて、あわてて memcached のポート使うようにしてテストしてみたけど、特に計測値かわらなかった。 mysql すごい。

ログインした時に最終ログイン時刻を記録する為に UPDATE してるとこあるけど、見えない要件で必要かもしれないしパフォーマンスに大差ないと見込んでスルーした。
もう kamipo さんの slow query プロファイルでも SQL で問題全部潰し終わったの確認してたし。

まとめ

他のチームは、バリバリキャッシュ頑張ったりアプリケーションのメモリの中に全部入れてたりミドルウェア追加したりとか頑張ってたらしいけど、割と最初の構成から殆ど変えないで、普通の仕事のノリで実直に軽いノリでやってても11位くらいの順位になったのは割と満足いく感じだと思います。

言葉では語られない fujiwara さんの苦労が色々と見える題材でほんと fujiwara さん凄いとおもいますが、本戦はもっとがんばってください＾＾

Posted by Yappo at 02:03 | Comments (0) | TrackBack (0) | tech

2013年09月30日

for cpanm 
$ cpanm --look Imager::File::PNG
$ perl ./Makefile.PL --libpath=/usr/local/opt/libpng/lib --incpath=/usr/local/opt/libpng/include
for carton 
$ cd /usr/lib
$ sudo ln -s /usr/local/opt/libpng/lib/libpng.dylib
$ cd /usr/include
$ sudo ln -s /usr/local/opt/libpng/include/png.h
$ sudo ln -s /usr/local/opt/libpng/include/pngconf.h
$ sudo ln -s /usr/local/opt/libpng/include/pnglibconf.h
普通だと Makefile.PL にオプション与えれば済むけど、 carton だとそういうの出来ないので手っ取り早く symlink でできるよ。
Posted by Yappo at 18:40 | Comments (0) | TrackBack (0) | Perl

2013年09月24日

今日みた夢が「blog 書かないと干すぞ！」ってがちぎれる941さんとlestrratさんがでてきたので書く事にした Yappo です。みなさん週末はいかがお過ごしでしたか?僕はカート大会いって箱根で温泉と美味しいご飯食べてきました。

本編発表資料

社内開発簡単化と世界で戦う開発を考える技術
明らかに会場でかくていっぱい人見に来る、裏発表の DeNA の人が Yappo に負けないクオリティにする！的な宣言してて泣きそうになったのでささやかな反撃でタイトルぱくりました。

1日目の午後一から40分の枠をもらったので、仕事向けのアプリケーション開発で考えなきゃいけない事と、雛形スクリプトを作る時に便利なKsgkの紹介をしました。基本的にはコピペ脳は害でしか無いのでいかにしてコピペを排除するか、ちゃんと自分の頭で考えていくか。のような話をしました。

わりとぐにゃらくんの発表内容に近い。というか作ってる雛形の思想が MobaSif に近い物があるので、雛形で生成されるコード(=WAF)は既存の有用なモジュールのグルーを提供する。みたいな事を僕も言ってたのですがぐにゃらくんも言ってたらしいですね。 GunyaSif のプレゼン見にいこうと思ってたら時間がすぎてたので何かでみようと思います。

割と最近僕はアウトプットしてなかったので、ここ一年で僕がやってきてた事の紹介をする。というテーマの裏には、同僚の人達へのプレゼンもついでに行うつもりでやってた、というか後者の目的が大きかったのですが、YAPC開催週に入社したての人が僕のを見てて実際にうんうんうなずかれると逆に照れて緊張するというのを発見した。

僕の発表が少しでも参考になって皆が楽になると嬉しいです。

LT: HTTP::Body::Builder

I NEEEEEEEEEEEEEED HTTP::Body::Builder !!!!!!1111

いっつも multipart/form-data の API を叩く時にまともに処理できる CPAN module が無くていらっとしてたんですが、まぁわりと〆切追われたりしてる時だから適当に乗り越えてたんですね。
ここ最近もそれやる必要になって mala に「いい方法しらない?」って聞いたら自分で作るしかないねって言われた事が発端となってやった LT です。

日本の LT とかだと割とこういう「俺の欲しいモジュール誰か作ってくれ！」プレゼンって少ないのですが、具体的な仕様を提示してお願いする感じにすると割とちゃんとした反応があるので有用かなと思います。今回もみんな HTTP::Body::Builder の必要性感じてくれましたし。

LT終わった後ひろむが資料よこせって言ったから、多分明日の LT で実装するだろうなと思って資料 pushして放置してたら二日目のLT直前にリリースしててましたね。
僕はその時 HUB してたのですが、慌てて缶ビール買いにいってました(作った人にビール奢るって宣言してた)。

ひろむのLTで最初 Test::Power やりだして焦ったけど、ちゃんと作ったよっていったので安心して壇上にあがりこんでビール渡せましたね！
941さんが近くにいたから、絶対止められるからどうすり抜けるかとかシミュレーションしてたのですが、そのへん意図汲み取ったのか忙しかったのか疲れてたのかでガードされずにすり抜けられた。
ビール渡して満足そうに帰ってる間にひろむがビール開けて追い出されてたらしいのを見逃したのが残念でした！缶ビール直接渡すと200%飲みだすだろうから裏を読んで服数本買ってコンビニの袋に入れて渡したのに意味なかった！１

こういう、誰かが発表してた内容をカンファレンス会期中に別の人の発表でレスポンスを返す。みたいな奴はもっとみんなやった方がいいですね！
人の発表中に上がり込むのは海外でも事例あんま聞かないけどw

あとはねこむに懇談会で HTTP::Body::Builder 作ってくれる?って聞いたらお腹ぽんぽんされてマッチョの方のボディビルダーと同じ言葉だったって気づいた。

前夜祭

わりとYAPCで発表した人って感想なにも書いてないから、たまには感想も書こうとおもったからこっから書く。

ビール飲みながら資料書いてたら終わってた。

現実逃避として拍手するサイトの DOS とかしてたけど、あれ皆でやってるから本当に自分が攻撃してるやつ成立するかわかりずらいので改善が必要だと思った。

前夜祭おわって適当に HUB に集まってみんなで飲んでたけど何話してたかだいぶ記憶にない。 bonnu さんが凄かったのだけ覚えてる。

1日目

朝一でいこうと思ってたけど深遠な理由により30分おくれて出発したけど、途中で特急待ちとかで次の電車が30分後くらいのエキセントリックな状況になったので東京駅から成田エクスプレスにのって武蔵小杉まで行った。乗り換えだるくて死にそうだった。

前日のうちから資料が出来てて余裕だったので kazeburo さんの話から参加して聞いてた。 kazeburo さんと一緒に ptrace した事あるから読めた。

kazeburo さんの終わってから昼飯までの記憶が無い。

ひるは学食。 overlast が「学食なんてどんなメニュー頼んでも全部同じ味だから一緒」とか酷い事言ってた。 miyagawa さんが持ち運び無線充電器の話してた。

自分のトーク終わってから、ぼーっと takesako さんの話みてたら会長から急遽今日の LT でれるか？！？って聞かれたので、今から作るでれるって応えた。

習字が飾ってある所で寝ながら資料作る。

ねるの秋田から BoF スペースで資料作ったら makamaka さんが Acme 大全の要望募集してまーすって言ってたから dan.pm 入れてっていったら「！？！？」ってされた。なんてこったい。

思量出来たからお店で飲食して休憩してから LT に行った。

準備とか資料公開であんま聞いてなかった。

懇親会

techno_neko さんに「本当は Plack::Middleware::ServerStatus::Audio 作って LT したかったんすよー」とか話してたら、それに近い話さっきしてたっていわれて、実際に作った人いた。けど、やっぱり全部 Perl で完結させたいからアイデア上げるから作って下さい！って言ったので完成楽しみ。あと Hokkaido.PM に呼んでくれるって言ってくれたのでそれも楽しみ。(ちなみに去年の懇談会で Fukuoka.PM 呼んでくれるって言ってくれて今に至るので嫌な予感しかしてない)

にこにこしながら dan さんがやってきて LT 資料の英語に凄いどや顔でつっこみ入れられてる時に makamaka さん通りがかったので捕まえて dan.pm ちゃんとみたかどうか聞いたけど dan さんがキョトンとしてどっかへ去った。

dan.pm って下らない事やってるけど、わりと皆のしらない Perl の機能つかってすごい頑張ってるから良いよ！って説明してて、今度はまた皆しらない機能使って Acme module 作るって宣言しといた。

あと Amon2::Plugin::L10N のお陰で仕事が凄く速くおわってたすかった！って言われたのでこんな僕でも生きてる価値が1mmくらいあるってわかった。

1日目夜

だんじょうさんが飲み屋に来た

2日目

最初のセッションから余裕で参加。 ikasama さんの見た。女の子の写真みて ikasama さんが癒されてた。

hidek さんの見ようと思ったけど gossy product 追っかけてなかったから、 hidek さん干しで見にいった。 PerlMotion 動くとこまでいっててよかった。みんなもこの辺のやるといいよ。

昼は LINE の会社の人事の人が弁当余らせてこまってたから、みんなでもらって適当に外でて地べたに座って食べた。

ruby session は mput さんが暴れないというサプライズがあった。

ruby session おわってから皆で HUB いった、 mput さんが Ruby 1.9.x からインデントが狂ってると警告を出すオプションが追加された、コアの方で実装されてる。って言ってて、これ便利そうだから Perl に持ってきたらいいと思った。あとは miyagawa さんが持ち運び無線充電器の話してた。

LT はじまるまでずっと HUB に居ててわりと本編みてない。わりと ruby session の続きの話を延々としてました。

barimi さんが言ってた初心者で twitter bot 作るってやつ。初心者は chat 的なやつの bot 作ると割とインタラクティヴ性あって楽しいので皆も初心者に与える題材として bot とか教えるといいですよ。

perl クイズで近藤さんが勝つの本当にチート過ぎて酷かったw

ikebe さんのアンコールセッションでサプライズ発表があると思ってたけど、本当にサプライズ卒業発表しててびびりましたね。

後夜祭

始まるまで適当な店入って時間潰してたら、超満員とか言ってたので gfx しました。さんまの刺身美味しかった。

わりともうみんな疲れてた

hackathon

こんかいみんな cookie とか言ってて良くわからないからググって cookie clicker hack してた。

javascript:setInterval(function () { $("#bigCookie").click(); }, 1);
javascript:setInterval(function () { if ($("#goldenCookie").style.display == "block") { $("#goldenCookie").click() }; }, 100);

こんな感じで捗る事を理解した。

あとは makamaka さんと話してた Acme の実装作る為に perlguets の読み直しとか、実装の mock を作ったりとかしてたけど、だいぶ疲れてるからスローペースでしたね。

打ち上げの店のキュウリがおいしかった。

race

50msec で一周するカート大会にいってきた。道中の電車で心臓ばくばくしすぎてて死にそうだったけど、運転したらそういう疲れが全部吹き飛んだので、単純に室内にこもりすぎてて不健康になってっただけだったという結論になった。次 YAPC やる人は運動とか取り入れた方がいいですよ。

レース結果は僕のチームBが3位で、ベストラップの順位が2位だったので、うっかりトロフィー貰っ贈呈禁止規定に引っかかって処分されなくてよかった。

かえりは箱根ちかいから温泉いって、渓流沿いの飯やでうまいめしをくった。特に YAPC 中はちゃんと和食食えてなかったのでめちゃうまかったは。

next event

hackathon の後に、わりとイベント少なすぎるから皆気合い入れてあつまるからコンスタントにイベントやろう見たいな話をしてて、 Shibuya.pl という Plack のイベントをやる事にした。とりあえず fujiwara さんとか ISUCON3 で忙しいので、それが終わった後の11月の平日にでもやりましょう。
ikasama さんも11月くらいに Testing Casual やるって言ってるから要調整

「YAPC::Asia もう終わりって言ってるけど、やってほしいなでも自分はやりたくないな」とか思ってたら本気でもう開催されないってのを皆は認識した方が良くて、別に1000人とか集めなくていいので300人規模とかで来年からやるとかでもいいですね。僕も開催しないから適当だけど。

とりあえず来年は東北で YAPC::Asia が開催らしいから、いまから東北旅行楽しみです。

Perl徹底攻略 (WEB+DB PRESS plus)
Perl徹底攻略 (WEB+DB PRESS plus)
posted with amazlet at 13.07.18
大沢 和宏 cho45(さとう) 小林 篤 和田 裕介 嶋田 裕二(xaicron) 牧 大輔(lestrrat) 奥 一穂 広木 大地 伊藤 直也 長野 雅広 藤原 俊一郎 伊藤 智章 まかまか般若波羅蜜 小飼 弾 近藤 嘉雪 中川 勝樹 宮川 達彦 tokuhirom 藤 吾郎(gfx) 村瀬 大輔
技術評論社
売り上げランキング: 7,279
Amazon.co.jpで詳細を見る
Posted by Yappo at 12:59 | Comments (0) | TrackBack (0) | Perl

2013年09月19日

今日は YAPC の前夜祭ですね！
今年の YAPC の前夜祭は、去年の YAPC で好評を博した 前夜祭 が 慶応大学が会場 となって開催されます！
僕は 前夜祭 には参加者として参加していて、楽しい催しになるように努力しますので是非是非ご参加下さいませ！
前夜祭 - YAPC::Asia Tokyo 2013

さて、明日のYAPC1日目、13:00〜13:40 では僕が「社内開発簡単化と世界で戦う開発を考える技術」と題して発表致します。
が、なんかスライド書いてたら「amon2-setup.pl を俺色に染める」というよりは「僕の一年間の Open & Share」みたいな感じになってしまったので、
多分そういう感じの話になると思います。僕の一年間 に詳しい方は既に知っている情報が多い感じなので、そこら辺ご注意下さい！
本トークでは具体的に言うと以下の様な話をする予定です。

- ありがちな開発初期に行う呪文のコピペ
- コピペを無くす為に考える事
- それの失敗談
- アプリ開発で便利な最近僕が作ったモジュール
- ops のヒトから椅子飛んでこない為にやってる事
- 雛形で作ったアプリのテストを Ukigumo 連携する事についての所感

ただ、最後の Ukigumo の所はどうでしょうか、もしかしたら無理かもわかりませんね！
なぜならまだスライドが完成していないのです。ハラハラ。

アプリケーションのディレクトリ配置や、標準でセットアップされるべき機能から deploy 初期設定全般 の情報は非常に便利だと思っているんですが、その情報は最近表にでてこないので、そのあたりの知識の共有や議論なんかも出来ると素晴らしいと思っております。
「こんなことやってるぜ！」という知見をお持ちの方は talk 中に話割り込んできていいので是非教えてください！

それでは皆様、YAPC 会場でお会いしましょう！

参考文献

Posted by Yappo at 16:11 | Comments (0) | TrackBack (0) | Perl

2013年09月05日

社内ツールなどで Perl スクリプトを配布する時にいちばん気になるトピックとしては、スクリプト中で依存しているモジュールをどうやってインストールさせるか?
という所ですね、最近は toolchain が強まってきて cpanm --installdeps . とか carton install をやってもらえば良いのですが、たかだかちょっとしたツールだったら git clone してもらってすぐにスクリプト叩いてもらいたんじゃんすか。

ってことで、スマートかつクールにこの問題に対処するスクリプトの雛形を書いてみました。 core module 以外には Carton を予め入れておく必要があるのがまだまだ敷居高いですが、エンジニア向けのツールだったらだいぶ手間は下がるでしょう。

ポイントとしては、コードで使うモジュールを use する前の BEGIN ブロックで必要なモジュールを既に入れておくので、 Acme::Hidek が未インストールな状態でもエラーにならずに実行可能という点と、 carton を使って依存モジュールをインストールしているので carton exec で起動した相当の処理を行っている点です。

ここから話を広げた話題を YAPC::Asia 2013 TOKYO で発表するので興味のある人は来るといいです。

Posted by Yappo at 17:43 | Comments (0) | TrackBack (0) | Perl