Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由

社内のコードレビューで、Params::Validateのuseの際に、

use Params::Validate qw//;

と後ろにおまけをつけてもらうようお願いしていました。


たまたま、「そういえばなんで qw//; をつけるんですか?」と質問されたので、口頭では簡単に説明したんですが、メモの意味でこちらにも書いておきます。


と言っても、コードがあった方が早いので、以下の3つのファイルを用意しました。

package YAPC::Asia2011;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT_OK = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2011 has already held  2011/10/13 - 15 \n";
}

1;
package YAPC::Asia2012;
use strict;
use warnings;

use Exporter qw/import/;
our @EXPORT = qw/ is_hold /;

sub is_hold{
    print "YAPC::Asia 2012 will hold 2012/09/27 - 29 \n";
}

1;
#!/usr/bin/perl 
use strict;
use warnings;
use lib "./lib";

use YAPC::Asia2011 qw/is_hold/;
use YAPC::Asia2012;

is_hold();

exit;


これで、最後のplを実行してみると、

YAPC::Asia 2012 will hold 2012/09/27 - 29

と出力されるはずです。use の順番を2011と2012で逆にすると、

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはず。


useしたモジュールが@EXPORTに関数を突っ込んでると、自動的にその関数を使えます。
そんなモジュールはたくさんあるし、必ずしもそれが悪い事ではないのですが、
Params::Validateの場合は 「validateとvalidate_pos」が@EXPORTに入ってるので、
特に前者は思わぬところでバッティングしたらイヤだなぁという思いから、これを抑止したかったため
冒頭のお願いに繋がりました。


サンプルのplでも

use YAPC::Asia2012 qw//;

と書くことで、useが後だとしても

YAPC::Asia 2011 has already held  2011/10/13 - 15

になるはずです。


モジュールを作る際には、@EXPORTと@EXPORT_OKどちらに突っ込むかは考慮して作成する必要があると思いますし、使う側としても、適切なもののみ選んでimportする方が良い派です。


そんなこんなで、YAPC::Asia今年も楽しみですね!

gitで別のリポジトリにpushする

通常git push は git cloneしてきたリモートリポジトリに対して打つ事が多いので、
git push
とか
git push origin master
くらいしか打ったことがありませんでした。


とある対応で、my/hoge.gitのリポジトリで作業したあと、最終的にpublic/moge.gitのリポジトリとして公開したいという
場面があり、git merge あたりを軽く眺めたんですが、結局
init commitなので手動コピー -> git add , commit , push でも
いいかというアナログ手抜き対応をしちゃいました。


すかさず突っ込みを貰い、非常にシンプルな正解を教わりました。。


my/hoge.git をcloneしたディレクトリで、↓の1行で一発

git push [リポジトリ名] master
( 前述の例だと git push git@repos.com:public/moge master)

今回だと、既にアナログpushをしたあとだったので、

git push git@repos.com:public/moge +master

で 強制的に上書きしました。


「別リポジトリにpushする」というのは多分あんまりないので、書き残しておきます

Qcon2012に行ってきた

会社の人に誘われたので、Qcon2012(http://qcontokyo.com/)に行ってきました。


カンファレンスもよく考えたらYAPCくらいしか行ってないので、そこそこ不思議な気分でした。
多分参加者は150人くらい。さすがに知り合いの人はいませんでした。。


クラウドがテーマの1つ、ということでそれ系の話が多かったかなと。自分がそういうセッションを選んだからかもしれませんが・・・


以降はだーっとメモったものが基本。要所を編集しました。


よくあるカンファレンスの流れなのか、みんな淡々とセッションを聞き・移動する。ということで淡々と過ぎて行きました。
席から電源が取れなくて、休憩時間の度に充電する必要があったのがちょっとマイナス。。でも、周りの人もノートPCより紙のノートの人のが多かった。
あとはお菓子と少しの飲み物が提供されて、同時通訳が凄かった。とかが印象。


Keynote 1 怪しい都市伝説
 cloudのメリット
  小規模でも使える
  NASAではギガピクセルデータをhadoopで分析して、ipadで確認 なんてのができる
  火星->S3->みたいな流れ
  機密のためにはaws double cloud
  NASAamazon,google,MSあたりを使ってるよ
  amazonの財務をどう見てる?
   2000年30億ドル規模だったものを今は毎日提供してる
   安定して提供してるよね。
   クラウドから別クラウドへ、データはどこででも保存されるべき
  情報漏洩で工夫した点
   データが漏れてないことの確認のしかた
   暗号化によって対応。鍵はクラウド側には投げない。
   クラウドに投げる前に暗号化。
 ======感想=========
途中から参加だったので、乗り遅れる
 ===================



Keynote 2 Androidに関わるエンジニアの視点
 simeji買われたバイドゥの足立さん
 ◎androidの歴史
 2007.11 android登場 Open handset aliance
 2007.12 blog書く。ターニングポイントだった
 2008.09 実機登場
  野良アプリ入れて動かしてもらう
  この時点でblog44本くらい
 2008.11 inJap登場 日本語入力機能
  この時からユーザビリティを考えていた
 2008.11 Simeji登場(翌日)
  スピード感が一番大事
  ニーズを検証するより、ニーズそのものがあるかわからない
 ※アプリ開発の壁
  3位:技術力の欠如
      やり続ける。調べる。わからないけど動く、でとめない
  2位:モチベーションの減退
      休憩大事。俺俺ミッションを作る。
  1位:ユーザーフィードバック
      正直キツい。お客こわい。
 個人のアプリ開発で大事な事
  技術/リード・マネジメント/デザイン/メンタルコントロール/語学力/その他
 2009.04 IMF Input Mehotd Framework
 2009.04 android1.5リリース
 2009.05 ハードウェアキーボード対応、フリック対応、ポケベル対応
 2009.06 iWnn登場
  ここから自分路線に切り替える
 2009.06 NDK登場 Native Development Tools AndroidでNativeコード開発ツール群
 2009.06 デザイナ矢野さんjoin
 ※デザイナーと働く
  お互いの認識の差を理解することから
 マッシュルーム
  インテント。アプリ間の連携。RPC的なこと。
  地図から住所の文字情報を引っ張ってくる
 2009.09 マッシュルーム公開
 2009.09 OpenWnn公開
 2009.09 冬眠
 2009.11 脱もっこ
 2009.12 WiFi経由でPCから入力
 2010.03 Android MIPS対応
 2010.05 上海
 2010.09 KDDI America NY講演
 2011.05 渡米
 2011.05 ADK Android open accessary kit
 2011.09 android x intel Multi-platform
 2011.12 売却
 ◎大事なこと
  完璧を目指すよりまず作る
  人間は先を見通す能力なんてない
  要するに、ちょっと考えて動いて試す
  考えすぎた想像より、経験から導かれる予測の方が精度が高い
 (Q)android以外のプラットフォーム開発について
  マルチプラットフォーム開発あるので、プラットフォームたくさんあるのでandroidにとらわれないほうがいいよ。
  マルチ開発は開発者のエゴ。ユーザーの要望実現が重要
 (Q)考え方はリーンスタートアップ
  本は先週注文しました!
 ======感想=========
androidとsimejiの歴史の話。
 とにかくスピードが早い、というのが印象的。機能リリース翌日に対応など。
 自分が欲しいもの、というコンセプトを崩さずに進めているのが理由とポイントなのだろうと感じた。
 逆に「冬眠」してたというのも大事なことなんだなと思った。
 リーンスタートアップは自分も先週注文しました!
 ===================



美しさは見る人の目の中に宿る
 いけてないコード
  略しすぎるコード
  タトゥーにいれたコード
 いけてない定義
  コードは芸術ではない。工芸的な職人ではない。機械の一部
  コードの見かけはどうでもよくて、ソフトが低コストで動くことが求められる
 開発は氷山の一角。あとはたくさんのメンテナンス。
 メンテしにくい、複雑、変更に弱い。いけてないのはリスクの高いコード

 いけてないのにはいくつか種類がある
  ぼろいコード。コメントで変更履歴がたくさんのコード
  複雑とぐちゃぐちゃは違う。
  maddening mishmash.ごちゃ混ぜなコード。依存が複雑。
  破滅的にかき乱れた状態。これも依存が複雑
  comprex & convoluted. 意味の分からない遠回りな処理
 いけてないのと古いのは違う。古いのはアリ
 freakishly foreign. 知らない珍しい言語とか。

 いけてない原因
  ・悪意はないけど、無知なエンジニア。本もblogも読まない人。関心がない。
  ・上司の親友。カウボーイコーダー。
  ・賢いエンジニア。マイケル・ジャクソン(という人が書いた本)が言ってる。

 いけないコードが現れない理由
 ・アジャイルもウォータフォールも関係ない
 ・テストの有無でもない
 ・言語でもない
 現れないために
 ・無知に知恵を授ける。昼飯をただで用意して、学ばせる。
 ・カウボーイにはプロセスで囲い込む。手順を踏ませる。
 ・賢い人、ソリューションが目の前にあるのに複雑化しようとする。セカンドオピニオンを求める。
 いけてないコードをなくすために
 ・ホントにいいのか?ホントにいいのか?見難いだけで?
 ・いけてないのはマイナスの一部。将来のメンテが楽になる「かも」。リスク導入を肝に銘じる
 コードは依存している。
 依存レベル
  プライベートメソッドとパブリックだと違う
  呼ばれ側を書き換えるのではなく、再実装する。
 deprecated,oboleteなどの警告を出す。移行を促す。
 (Q)どうやったら良いコードを書き吸収できるのか?
  こういうMTGに出るのも重要。勉強も重要。やる気がない奴らにはピザおごれ。昼飯来ないならMTG形式ですかねー
 パフォーマンスとコードの美しさの関連性
  コメントでhack , warningとか注意書きするといい
 ======感想=========
  コードの質とはメンテナンス性。
  ダメな人のコードも良すぎる人のコードも課題があるっていうのは、凡人として激しく同意。でも誰にも悪気はないんですよねー
  古いだけなのは悪い事じゃないけど、たくさんの人がいじってたり、その積み上げ方が悪かったりするといけてない、というのも納得。
  古いけど安定して動いててそんなに触る機会ないんなら放っておく、っていうのは現実解だと強く思う
  とりあえず取るべき策は
  ・deprecated警告しつつ、新しい方への移行促す。コンパチ大事。
  ・昼飯にピザをおごる余裕はないけど、勉強会に食事を持ち込むのは考えてみようと思った
 ===================




クラウドデザインパターン -AWSを用いたシステム設計のベストプラクティス-
 インフラストラクチャはソフトウェアになった
 APIでコントロールできる
 日本でAWSを使いこなしている人は少ない。世界に比べても。
 なのでノウハウを形式知化したい。CDP。cloud design pattern。48個。近々総選挙予定。
  froatingIPパターン
   IP のつけかえが簡単
  clone serverパターン
   初期のサーバーの設定値やデータをコピーする手法
  job observerパターン
   キューの処理もシステム化されてる
 実装シナリオ
  5個ある
  CGMシナリオ
   動画をあげたい。→S3を使う。 dropboxも使ってる
   アクセス増えた。入力を仮想サーバー -> 出力をS3から
   cache distributionパターン。CDN化して海外対応
  Eコマース
   route53で独自ドメイン
   ソフト更新->floatingIPパターンでテストインスタンス立ち上げ、テストがOKだったらIPつけかえる
   multiserverパターン。冗長化。DBもLBも設定可能なUI。
   DBrepricationパターン。DBのレプリも設定でやってくれる
   multidatacenterパターン。web+dbサーバのセットで1つのDC。
   nfsreplicaパターン
  クラウドアーキテクティング
   できるだけサービスを利用
   机上実験よりも実証実験
   スモールスタートからスケールアウト
   変化に対し全レイヤで対処
   故障のための設計
 (Q)見積もりしにくいんだけど?
  SMC simple monthly calcurator というのがある。データ量やIOの違いは誤差。
 (Q)ELBがよくわからないよ
  複数のDCに振り分けられるLBになってる
 ======感想=========
  AWS48。
  デザパタを用意するというのはクールだなーと思った。
  業務で運用している色んな手法がデザパタに採用されてて、網羅性に説得力があった。
  言った通り、インフラをソフトにした。という説明がしっくり来た。
  各所でプレゼンされている資料がたくさんあがっているようです。
 ===================



ソーシャル・コンピューティングをスケールさせるには(facebook)
 700万人->8億人
 フェイルオーバー、エラーハンドリングの話をします
 ソーシャルアプリ、ソーシャルデータとは
  繋がっているユーザーとやりとりをする=ソーシャル
  スケーリングはつながりのスケーリング
  容姿などの客観情報よりも興味=人のソーシャル性
  faceの写真アプリ、できは良くない。リサイズできない、順番替えられなかった。
  でもfaceが世界最強の写真サイト。なぜか、ソーシャルだから。タグづけができる。
  クラスタリングとパーティショニング
   友達のデータをどのクラスタにのせるかっていうのは制御不能
  小さなオブジェクト
   メッセージの小ささは対話に繋がる。
  高い更新頻度
   対話が繋がるので
  データの一貫性
   銀行や宇宙船じゃないけど、一貫性は必要。対話が成立しなくなる
   エンターテイメントでもいい加減なものではなく、大事なものであるという認識を我々は持ってる
  全てのデータは暖かい
   ホットなデータは人と時によって、違う。どれも重要。
 リアルタイムでオブジェクトを扱う
  パーミッションも同期処理。シンクロナスコールがたくさん。
 水平スケーリング
  システムのオブジェクト全てをマシンにのせる
  LB->AppServer->Cache->DB
   ユーザーが友達とインタラクションすると、キャッシュが膨らむ
  App
  Cache
   memcachedに注力してる。秒間10億read
   NWのボトルネック
  DB
   DBではなくストレージだと思う
   インデックス効かないと話にならない
  NoSQL
   いいか悪いかの宗教論ではない
   NoSQLもMySQLも使ってる
 スケーリング
  ボトルネックを取り除く
  エラーハンドリング
 NWボトルネック
  起こりやすい
  帯域の問題ではない。
  1つのAppからたくさんのCacheにリクエストをたくさん投げる。レスポンスで失敗するので、リトライを短くする。失敗するってことは多分過負荷。そんな時にリトライを短くすると助長する。
  ー>解決策は全てのキャッシュサーバーに同時にリクエストを投げない。分散する。

 「ミスをゼロにするのではなく、それにかけるコストを減らす」
 ミスをしないのはなにもしないこと。facebookはトライしてみる精神。
 スタートアップ企業の性質と一緒。

 小さな問題が大きな問題にかわるとき
 SPOF
  ソフト自体がSPOFという問題はあまりでてこないが、結構ある
  ハードの問題点という方が言われがち。
  ソフトのリリースを段階的にしていくことが重要
 increaseing load under load
  リトライをし続けないこと
 funnneling badness
  ある問題によって、別の問題が顕在化してしまうこと?
  問題のパーセンテージをトラッキングして、しきい値以上だったら対処する。
 everyone waitng
  一台が遅くなると、他のものも全部遅くなる?
  既に待っている状態で、行列を増やさない

 ◎大事なこと
 ・失敗をテストする。「夜も寝られない心配があるなら、そのソフトウェアは壊せ」
 ・全てを監視する
   平均値は無意味。分布を見る。故障は少数のマシンで起こる
 ・事後解析。何が起きたのかを十分時間かけて解析する。
   post-mortems

 MySQLの分散
  数学的なマッピング。たくさんのバケツを用意する。
  (要はマネージャ分散っぽい)
  全てのマシンにキャッシュがある
  細かくシャッフルしてるけど、問題ない
 (Q)ユーザーのアクティビティ性に応じて特殊対処してる?
  友人数の上限があるのでパンピーは一緒
  有名人アカウントは色々やってる
   更新頻度が高いので
 (Q)意図的になんかを壊すとは?
  IPテーブルルールを用意して、NWをおかしくする。電プチするとか。
  ツールがあったとかわけではない
  カーネルがおかしいとか起こる
 ======感想=========
  SNSを作られているFacebookさんのセッション。
  ソーシャルの説明もその通りですねと。
  >「ミスをゼロにするのではなく、それにかけるコストを減らす」
  >事後解析。何が起きたのかを十分時間かけて解析する。
  とにかくミスは起きるもの、と捉える。同意。検証と再発防止も大事。
  業務経験上、ミスの透明性が重要だと思っているけど、そこら辺の共有・周知のルールや考え方などどうしているのか気になった。
  ソフトウェアがSPOFはなるほど!そういうものを自分達は扱っているし、作っている。新しいハードはテスト検証しながら導入するくせに、自分のコードは豪快にリリースする、っていうのは確かにおかしいなぁと思った。段階リリース大事。
  NWのテストのために、電プチしてみるとか凄い。しかし、避難訓練としてやった方がいいかもしれないと感じた。お客のデータに障害が起きないようなレイヤならいいのかなと思う。
 ===================




Twitterの最新アーキテクチャ

 ツイッターのミッション。
 ツイッターSNSではない。リアルタイムコミュニケーションネットワーク
 7196tps なでしこ優勝時。tweet per second
 25088tps バルスの時。
  バルス準備は特に何もしてない
 1.4億アクティブユーザー。1日3.4億ツイート。約70%のアカウントは米国外
 
 ◎アーキテクチャ
 timelineDB、tweetDB,social graphDB,userDB
 
 最初はRailsでどかっと。
 問題点:1カ所に固まりすぎ。Rubyがそこまで爆速なわけではない。
 
 Modelを分割化。user service , tweet serviceなど。プロセスが別。実装が別。
 各serviceはJVMscalaで動いてる。
 SOA的なアプローチ。
 SPOFにならない

 リバースプロキシ -> Rails -> DB
 ハードウェアバランシング。だった。
 今:HTTP Proxy -> API -> service -> DBのルートも。Railsルートもまだある。
 HTTP Proxy -> WebI -> service -> DBのルートも構築中。
 JVM化 = Off the Rails.

 膨大な同時接続数
 多量のIO
 ごく少量の永続化対象データ
  ほとんどは読み込みデータ99%以上。readが鍵。
 ※「ツイッターはinterest graph」
 必要なのは
  サーバー負荷を適切にさばく。
  言語対応の柔軟性。現時点ではJava,Scala.
  成熟したコンカレンシーモデル
 javaコンポーネント
  検索周りでたくさん使ってる
  トレンド/キーワードクラスタリング
 javaによりもたらされるもの
  拡張可能な開発エコシステム
  成熟したJIT
  管理されたメモリモデル
 finagle
  非同期にRPCを実行できるフレームワーク
 タイムラインのトラフィック
  20万クエリ/秒
  レイテンシー
   中央値1ms
   99パーセンタイル4ms
 秒間4kツイート
 ピーク時10kツイート/秒
 配信: 秒間1800万ツイート
    100万のフォロワーに対して、3.5ms
 ツイート書き込みの流れ
  HTTP Proxy -> tweetAPI -> Queue -> tweet Daemon-> fanout =>delivery
-> timeline cache -> redis
  fanout : 4000人のフォロワーずつにわけて配信
      レディーガがレベルだと、RTのが早いとか
 ツイート読み込み
  Proxy -> timelineAPI -> timeline service -> timeline cache -> redis

 ======感想=========
 「twitterSNSではない、インタレストなぐラフ」を複数回繰り返していた。なるほど、そうですか。
 Railsでえいやで作ったものを、徐々に疎結合・別システム化していったとのこと。この辺は負荷とサービス規模が
 予想を遥かに超える感じで大きくなるサービスでよく進めていけているなぁと強く関心しした。
 サービスそのものの変化がそれほどない分リファクタ感覚が近いのかもしれないが。。
 1個前のfacebookのプレゼント比較して、技術者集団っぽいなという印象。良い意味でベンチャー気質があって、
 エンジニア主導で進めていそうな雰囲気を感じた
 ===================




現場で使えるドメイン駆動設計
 casandraのコミッタのエリックエヴァンスとは別人
 2003年出版の本。原著は。javagenericsがない時代。
 
 顧客の仕事を理解すること
 顧客の言葉で理解する事
 モデルを共有すること
 モデルを基にソフトウェアを作る
 
 設計思想と実装方式
 実装方式としてのDDD
  ユーザーインターフェースを通じて、ユーザーとデータをやりとりする
  ユーザー-> UI -> ロジック -> 永続データ
  ロジック構成方針
   トランザクションスクリプト
    ユーザーの要求を満たす手続き
   ドメインモデル
    複雑なロジックをオブジェクト指向で解決する
   ロジックが複雑化すると、トランザクションスクリプトのメンテコストが増大する
   分岐点はどこなのか
    慣れた人に任せるしかないよね
   手続きとは?
    入力チェック、DBアクセス、演算、編集処理
   どういう時に使う?
    ドメインモデルが論理データモデルで表現しきれる場合、ロジックはほぼSQLで表現できる
    ->SQLを気持ちよく使う
   ドメインモデルが論理データモデルで表現しきれない場合とは?
    「暗黙的な概念」 制約・プロセス・組み合わせがあるルール
    制約
     制約は論理データモデル上に表現されず、手続きとけ込んで見えなくなる
     オーバーブッキングの概念がif文の条件に入る
   ただし、制約をすべてオブジェクトとして実装する必要はない

 設計思想としてのDDD
  ハイレベルのドメインモデル 業務の境界と関係を明確化
  各ドメインのモデルを詳細化し、実装方針を策定する
   トランザクションスクリプトが基本とする
  複雑化は囲い込み、適切なモデリングパラダイムを選択する
  Big Upfront design?
   考える事は重要。期限と予算

 実装方式と開発プロセス
  トランザクションスクリプトを基本にする理由
   基本設計をかきやすい
   ほとんどの開発者にわかりやすい
   ウォータフォール
    手戻りが許容範囲に収まればアジャイルよりも安いし早い
     3つの真実<->仕様変更した方が早い場合もある
    プロトタイプは当然作る、CIも重要
 複雑なドメインに対してはそれなりの戦術が必要
  基本設計が書き難い 要件が整理しにくい
  イテレーティブ、インクリメンタル
  シナリオはモデルに目的を与え、モデルはシナリオを実現させる
  実装方式の策定はメンバの力量や期間と相談
 まとめ
  業務を理解しよう
   業務を表現したモデルを共有しよう
  適切な方式とプロセスで実装しよう
   ウォータフォールの手堅さ、アジャイルの柔軟さ
  チームで実現できるアーキテクチャ

 ======感想=========
 ホントは、いかにしてドメイン駆動設計を行うかを聞きたかったのですが、内容としては
 「まぁまぁ落ち着いて。身の丈・状況にあった時だけ使いましょう」というものだった。
 確かにSIの現場を考えたら、現実解というか非常に的を射た答えだと思った。
 アジャイルと同様、言葉が先行してしまうのは確かに良くない。
 ===================



ソーシャルゲームにおけるAWS/MongoDB利用事例
 MongoDB
  ドキュメント指向
  フルインデックスサポート
  レプリケーション
   replicaset セカンダリの自動昇格。その間自動リカバリ
  auto-sharding
   指定したshard keyで水平分割

 Animal Land
  町づくりゲーム
  S3 htmlや画像の配信
  CloudFront 海外対応
  Ehcache - javaプロセスでキャッシュする
  RestFB facebookにアクセスのため

 ======感想=========
 このまとめを書いていたので、軽く聞く程度で。。
 資料はサイトからDL可です。
 ===================



まとめると、オフィシャルというか大人な内容の発表が多かった。
聞く方も大人で、業務に活かせる部分があるかマッチングにしに来ている感じでした。
懇親会でほとんど絡めなかったのが反省点。

Yokohama.pm #8 に参加してきました

blogを書くまでがYokohama.pmです。たぶん。


金曜日はYokohama.pm #8に参加してきました。
今回は僭越ながら発表させていただきましたので、資料は以下に置きました。
http://masartz.github.com/presentation/yokohamapm-8/start.html


ustもどうやら下にアップされているようです。
http://www.ustream.tv/recorded/18590454


YAPC::Asia 2011で話せなかった後悔から勢いで申し込みましたが、なんとか喋りきりました。
練習では全然尺におさまってなかったんですが、本番は時間ぴったり。資料にも混ぜてますが、「ここで半分」みたいな区切り入れるのを真似して良かったです。


内容については、コードはほとんど出てこなくて、最近やってたお仕事の業務報告的な感じですが、今までとちょっと違う事をやったので色々と知る事が多かった点を話してみたいと思ってやってみました。


最後にも触れましたが、「大規模すげーわ、マジすげーわ」という事が言いたい訳でもなく、
「マネジメントキツいわ、マジキツいわー」という事が言いたい訳でもなく(というか俺リーダーじゃない・・・)、
日々黙々としている仕事について発言してみる事も自分や誰かのためになるんじゃないかなと思います。


個人的には、今後はまたちょっとやる事変わりそうなので、このように振り返って残しておけて良かったかなと。


一部でてきたコードの部分について、早くもその場でアイコンカッコ良い人から突っ込み入りましたが、その後オンライン/オフラインで話して、結論としては資料のサンプルが良くなかった。。


bindのミスならnamedプレースホルダを使えばおk、というご指摘はまさに仰る通りです。同じように突っ込む方もいるかもしれませんので、少しだけ補足すると、
bindはサンプルとも言えないただの例で、要は「実際にInsertメソッドをよびだしたあとの結果をdbから引き直して中身チェック」っていうことがしたかっただけで、bindに限ったアプローチという訳ではありません。
これは基本的に動的にSQL文を作らない開発フローにも起因するので、多分これでも説明できてない・・・、この辺についてはもうちょっと自分の中でも再検討が必要なようです。




事前にclouderさんにはご相談させていただいたのですが、今回実は会場の入り口に弊社のちょっとしたグッズを置かせていただきました。
前回に引き続き今回の会場も、livedoor社さんの技術部会が支援してくださった会場であり、その場に他社のグッズを置く事を快く承諾してくださったclouderさんとlivedoor社さんに改めてお礼申し上げます。ありがとうございました。
会場自体もWifi提供など充実しており、非常に快適でした。


直前まですったもんだした懇親会も見事に確保したmyfinderさんも++でした。あのもつ鍋は旨かった!


そんなこんなでお疲れさまでした。
また次回楽しみにしています!

YAPC::Asia 2011に行ってきました

blogを書くまでがYAPCです。
今年も行われたYAPC::Asia 2011に前夜祭含め参加してきました。


トークの細かい内容とかは例によってhirataraさんの記事が一番詳しいのではないかと
思いますし、各スピーカーの方々が資料をアップされているので、そちらを参照すれば良いでしょう。


個人的には、去年はスピーカーとして発表させていただいてダメダメだったので、
今年はリベンジの意味でもう1回トークしたいと思っていたのに出来なかった事が
一番の反省要因です。


トークについては、ベストスピーカー賞に輝いたfujiwaraさんのトークは実際に聞いていて
実は投票もしていたのですが、話がすごく具体的かつ流れがある内容でおもしろかった。


zigorouさんの内容についてはdep-opsな同僚の人と聞いていて、アプローチや環境の違いについて
話したりしてました。課金に絡む部分だとトランザクションが多くなるのがその辺の違いに
現れてるかも、という見解には納得でした。


とかとかあるんですが、今年もたくさんの方と話す機会があって、もうトークよりそっち
メインだったんじゃないかという気もしてます。


印象に残っていること

  • 前夜祭でkanさんに、懇親会で刺身さんに、空気読まずにRubyの話を聞いたけど、丁寧に教えてもらってすごく嬉しかったです
  • 前夜祭LTのkamipoさん発表で、「最新20件を取る時、先にフォロワーの最新投稿者20人を絞り込む」というアプローチはなるほどと思った
  • 大規模サイトを運営している某社では、デプロイタイミングが定期的ではないらしい&テストは通らないとコミットできない仕組みになってるとか。
  • 2日目のyappoさんのLTで社内nopasteを作ったと言ってたので、これは確かに便利かも、あった方がいいかもと思った。それだけでなく、社内の情報をどう収集し、どう活かすかなどLTとは思えない密度だった。

今回発表できなかったのは残念ですが、この反省を活かさないとな。と思いました。
懇親会でclouderさんに「次のyokohama.pmいつですか?やりたいです」って話してたんですが、
近々開催しそうですね!YAPC熱が冷めないうちに「次のyokohama.pmではなんか喋ります!」ってここで言っておきます。




最後になりますが、運営スタッフの皆さん、ボランティアの皆さんお疲れ様でした。
会として過去最高の規模だったようですが、過去と比べても非常にスムーズな運営をされているように感じられました。
今回で最後と言わず、来年もぜひ開催してほしいです。


最後の最後におまけですが、今回一番の収穫。
milanoさんの豪腕で、とても貴重なダブルネームサイン入りTシャツになりました。
来年トークする機会があったら、これ着て喋りたいですね。(逆に普段着れない・・・)

svn の timelineを人別にsortして表示する

svn + tracという組み合わせを使っているプロジェクトで
timelineを見ればコミットされた一覧が俯瞰できるわけですが、
githubみたいに人単位でどういうコミットをしているのがわかると、
便利な事もあるかなと思って、軽く作ってみました。(というかまだ進行中)


https://github.com/masartz/sort_timeline


plackup app.psgi で起動して、http://localhost:5000/feed に
アクセスするとcodereposXML Feedを元にした情報が見られるようになってます。
対象とするTracのfeedはconfig.plのURLの値を書き換えれば、他でもできます。


ぱっと思いついたのがcodereposとかplaggertracだったのですが、
最近のコミット量からしてあまり履歴がないので、伝わりにくいかもしれません・・
業務等で活発なtimelineがある所の方はそっちに向けていただくとわかりやすいかも。


というようにRSSフィードだと当然時間と共に消えてしまうので、http://localhost:5000/log
とかをアクセスすると、過去の全履歴が見られるように、ログファイルなのか簡単なDBなのかを
用意して、そっちからデータを取るようにできればいいかなとか妄想してます。


psgiアプリも書き慣れてないので、まずはapp.psgiにゴリっと書いてみたり、
jqueryサンプルサイトからコピペしただけとか、まだ全体的に適当なので、整形していくつもりです。

「優れたPerlプログラマを見分ける27の質問」に回答

元ネタはこちら
http://d.hatena.ne.jp/gfx/20110301/1298944990


回答例はこちら
http://blog.livedoor.jp/dankogai/archives/51645218.html


以下、やってみました。

1. Perl5において変数のシジルが示すものは何か
 → $,@,%,*。スカラー、配列、ハッシュ、型グロブ
 →○

2. 配列のアクセスする際の $items[$index] と @items[$index] の違いは何か
 →$items[$index]は@items配列の$index番目の要素へのアクセス。
 →@items[$index]は%itemsハッシュの$indexをキーとする値へのアクセス。
 →× @items{$index} と勘違いしてた。。

3. == と eq の違いは何か
 →「==」は数値比較。「eq」は文字列比較
 →○

4. ハッシュをリストコンテキストで評価すると得られるものは何か
 →%hash = ( a => 1 , b => 2); だったら、 ( 'a' , 1 , 'b' , 2)の4要素を持つ配列
 →△ この順番とは限らないか・・

5. Perlドキュメントからキーワードを検索するにはどのようにするのか
 →わからなかった・・・
 →× perldocなのか。

6. Perl5における関数とメソッドの違いは何か
 → MyApps::hoge($param) だと第一引数が$paramで、MyApps->hoge($param)だと「MyApps」が第一で、$paramは第二。
 →○

7. Perl5が変数のメモリを再利用するのはいつか
 →わからない><
 →×

8. 変数のスコープがデフォルトでレキシカルであると保証するにはどのようにするのか
 → 「my」 で宣言する
 →○

9. モジュールからシンボルをインポートするにはどのようにするのか
 →?
 →× 設問が読解できてないので論外

10. perlがモジュールのロードを敢行するディレクトリの操作はどのようにするのか
 →「::」を「/」に変換して検索?
→× 適当に書きすぎた

11. Perl5のエラーメッセージの検索はどのようにするのか(発生するエラーメッセージに説明を加える方法を知っていればボーナスポイント)
 →?
 →×

12. 配列を関数に渡したときに起きることは何か
 → $class->func( @ary , $scalar );だったら、sub funcで$scalarを判別することは無理。@_の中に全部まとめて入ってしまうので。
 →× そういうことじゃない

13. 複数の配列をそれぞれ区別して関数に渡すときにはどのようにするのか
 → リファレンス渡し。$class->func( \@ary1 , \@ary2 , \@ary3 );
 →○

14. 呼び出された側から見た return; と return undef; の違いは何か
 → @result = sub func{ return; }; if @result は偽だけど、
   @result = sub func{ return undef; }; if @result は真。「undef」という要素が@resultに入っている。
 →○かな?

15. 標準的CPANディストリビューションではテストはどこに置かれるか
 → t/配下
 →○

16. 標準的CPANディストリビューションでテストを走らせるにはどのようにするのか
 → perl Makefile.pl → make → make test。
 →○

17. CPANから新しいディストリビューションをインストールする際に使うコマンドはなにか
 → cpan install App::cpanminus
 →○ そして、以後はcpanmを・・・

18. 組み込み関数openを3引数形式で使うのは何故か
 → ファイルハンドルをレキシカルスコープにするため
 →△ 微妙にズレてる

19. openのようなシステムコールのエラーを検出(と報告)するにはどのようにするのか(エラーの検出と報告を自動的に有効にする方法を知っていればボーナスポイント)
 → eval{};でくくって、 $@で検出?
 →× なんか読み違えてた

20. Perl5で例外を投げるにはどうするのか
 → die; もしくは Carp::croak;
 →○

21. Perl5で例外を捕捉するにはどうするのか
 → eval{};でくくって、 $@で検出?
 →○

22. ファイルの読み込みにおけるforとwhileの違いは何か
 → わからなかった。。
 →× 猛省します


23. メソッドと関数においてパラメータ*3を取り扱うにはどうしたらよいか
 → $param = shift; で取ると、@_から先頭要素を抜く。 ($param1 , $param2 ) = @_; で取ると、@_からコピーで取得。
 →○

24. my ($value) = @_; の変数を囲む括弧が意味するものは何か、またこの括弧を取り除くと何が起きるか
 → わからなかった。。
 →× 言われてみりゃ、そりゃそうだ・・・

25. new は組み込み関数ないしキーワードか
 → No。
 →○

26. コアライブラリやCPANモジュールのドキュメントを読むにはどのようにするのか
 → perldoc perl
 →○

27. ハッシュの値のみを取り出したい時はどのようにするのか
 → my $result = value ( %hash );
 →× 地味に「value『s』」だったorz

結果
○:14
△:2
×:11


なんていうか、50点・・・。8割で優れているとのことなので、
27 * 0.8 なので22問以上は答えられるよう頑張らないといけないですね。。
ダメすぎて凹んでますが、晒すネタとしてちょうどいいかも。