Hatena::ブログ(Diary)

masartz->log RSSフィード

2014-09-01

YAPC::Asia 2014に行ってきました YAPC::Asia 2014に行ってきましたを含むブックマーク

blogに書くまでがYAPCです。

ここまで2個下から一緒。


もはや、YAPC専用blogになってる。。


今年はスピーカーではなく、イチ参加者(個人スポンサーになってみた!)

として参加してみました


単純な感想はうーん、なんだろう。

あまり楽しめなかったかなというのが率直な所。

きっとそれは個人の問題だと思うので、イベント自体に何か問題があったという訳ではないです。


客観的に見て良かった所

・安定のネットワークインフラ

・無限コーヒーレッドブル

・HUB貸し切り!

・何気に空調コントロールも良かった。微妙な天候・気候の中で不特定多数の空間をコントロールしていたのにずっと適温だった気がする

・若い人も結構いた気がする


さて、内容についての感想を述べると、

トークの中には「既にブログなどで発表・公開している内容」に留まってしまうものもあります。

それに至る経緯とか今後の話とか、なんかしらの補足を聞ければ良いんですが、そうならない場合もある。

もちろん、イベント駆動開発ってあるし、それは良い事だと思うので、「作ったよ・やったよ」っていう事を

言うのが価値があるというのもある。

もしくは知らなかった人には当然価値のある新情報としてリーチすることができる、など良い面もあると思います。

要は誰向けに話すか、なんのために話すか、という事でどちらも正解なので難しい。


また今回は応募したトークの数もこれまで以上に多かったようですし、そのためにリジェクトされたものもあったようです。


そういう意味では、「世界最大規模のYAPC」では1対多の形式(セッショントーク形式)では話す方も聞く方も

嗜好とニーズが多様すぎるのではないか、という気がする。

多様さを許容するには並列数を上げる事になるけど、現状の3並列以上も現実的に厳しいだろうし。。


個人的にはトークでいうとlyokatoさんのが一番でしたが、「Perlあるある」のイベントが最も楽しかった。多対多のイベントをもっと多くして欲しいなという気がしました。

Perl入学式がどうだったのかは見られていないので、そこの成果も是非聞いてみたい

「2対多」の形式の「Mobile Application Development for Perl Mongers」も同じく聞けなかったのでわからないけど、

このような「(2|3|4|5...)対多」もっと言うと「多対多」のものがあっても良いと思う


「世界最大規模のYAPC」の魅力は著名な人から初めての人までが参加するイベントであることだと思います。

割と、「あの人最近来てないけどどうしてるんだろう」という事が少ない気がして、

YAPCに来ればあの人に会える」と思える事のが多いのも良い事だと思う。


まとめると、

・複数人で募集できるトーク(そういえば昔の miyagawaさんとtokuhiromさんの「Plack作ってる」のセッションは楽しかった)の仕組みはどうか

・スポンサーセッションを設けるとまたアレがソレかもしれないので、スポンサー企業のエンジニア同士でディスカッションすればスポンサー側も旨味があったりするのでは。「大規模トラフィックについて」というテーマだけでもそこそこのスポンサー企業の中の著名人引っ張ってこれるのでは。

・どうせ皆餃子食う(この響きも懐かしいけど)んだから、「適当に集まるスペースだけ作ればいいじゃん」というのはさすがにオーガナイズできないだろうし、成果も見えない(イベント行う上でこれも大事)ので言いません。

が今年の感想です。


などなど書きましたが、特に運営の皆様、今年のYAPCもお疲れさまでした。

上の感想は別として、また来年の開催を楽しみにしてます。

2013-09-24

YAPC::Asia 2013に行ってきました YAPC::Asia 2013に行ってきましたを含むブックマーク

blogに書くまでがYAPCです。

ここまで1個下のエントリと一緒。


結局1年間何も書かなかったということに・・・




各トークの内容は例によってgihyoさん記事とスピーカー自身によるエントリにお任せ。

自分のスライドもSlideShare経由でYAPCのトークページに埋め込んでおきました。


トークした経緯は去年に引き続きgoccyに「喋らないんですか!?」って突っ込まれたから。

今年も人様の作業を堂々とパクる、という芸を見せてきました。


時間がギリギリだったので質問のタイミングがなく、どのように伝わったかわかりませんが

感想・ご意見などありましたらご連絡いただければと思います。


懇親会で「Perlバージョンアップはホントにあんなすんなり行ったのー?」と聞かれました。

多少過去の出来事 && 一部のみ関わってた立場 ということもあり、把握してない苦労など

あったとも思いますが、lestrratさんのトークからも「mod_perlからの脱却の方が大変」

と感じました。そしてそれは未知の部分なので、その差かもしれません。




他の方のトークで印象に残ったのはkazeburoさん、myfinderさん、yappoさん、lestrratさん、ikasam_aさん

と並べると見事にミーハーっぽいチョイスになってる。




kazeburoさんは昔からですが、話がわかりやすく、易しい所から難しい部分まで丁寧に触れられていて

すごく頭に入ってくる内容だった。近年のPerlにおける必須項目Plack周りを知りたい方はまずこちら、という内容でした。

ベストスピーカー賞第3位おめでとうございます。


myfinderさんのは、内容的には弊社内でも全く同じ取組をしています。

tech hills vol.6 においてgoccyが発表しているのでその資料を参考にしていただけると良いと思います。


発表のポイントとして「スケールしていく開発環境にどう対応するか」という所を触れられていて、

実は1日目の懇親会の時に「プロダクトや開発人員が膨らんでいくとテストがボトルネックになりがちですね」という話を

複数人でしていて、そこを重点的に話すというまさに作戦通りのベストスピーカー賞2位おめでとうございます。

bonnuさんの資金でお祝いにいきましょう。


yappoさんの「コピペイクナイ」のコンセプトは素直にステキで、コードレベルだと皆わかってることなのに、設計やプロジェクト運用などスコープが広がるとついついやってしまう事。新しい取り組みを始めた社内でも散見される事象かなと思います。もちろん確立された手法だったり、どうしてもスピードが求められるケースだったり、とか例外はあると思いますが。


lestrratさんのトークは、自分も似たような話をしたハズなのに、全然違う内容に感じるなど

発表方法として学ぶ部分もすごい多かった。mod_perl周りの話は前述のとおり。

発表時間がより短い中で、さらにその一部分で触れていただけなので厚みに差があるのはまぁ当たり前なのだけど、

どちらのが伝わりやすかったかと考えると明らかかなと。


ikasam_aさんのは何度か聞いているSWETグループの立ち位置と取り組みが興味深い。

Testをエンジニアリングするというのがクールだし、その過程で出る問題とかもっとあるだろうなと思うので、

その辺含めて今後も聞ける機会があると良いかと思いました。非機能要件にアプローチするという点では

今の仕事と通じる部分があると思っていて、それがおもしろかったです。




聞けなかったトークだと、soh335の話。

自分の発表の真裏だったので物理的に不可能でした。後夜祭でお話しさせていただいて、

改めて資料チェックしようと思います。


自分の発表資料の中で、Test::UselessModuleというのを紹介しましたが、

そのあとタイムライン見てたらたまたま Test::UsedModuleというのを知ったので見てみたら

完全に元々やりたかったことが実装されてる内容になってるっぽいですね。

作者のmoznionさんとお話しする機会を密かに狙ってたんですが開催中に会えなかったのが残念でした。




内容が被っているという意味では、nekokakさんのLTで出ていた共通モジュールの話もそう。

まさにたんぽぽ的な取り組みですね、という印象で他にも同じような取り組みをしているorこれからする

所はあるんじゃないかと思う。共通なものを作ったあとに、呼び箇所をスムーズに置き換える所にも

工夫してる部分あるんですが、その辺をどうしてるのかとかも気になりました。




YAPC::Asia 開催全般で言うと、運営の方々の安定感もあり、特に困る事はありませんでした。

メイン会場の電源が確保されていたり、ネットワーク環境が整備されていたり何不自由なく過ごせました。

スポンサー企業のご協力でサービスしていただけた部分(懇親会とか)、ボランティアの方々、

もろもろ含めてお疲れ様でした&ありがとうございました。


ここまで完成されたイベントが来年からどうなるか楽しみ以上に不安な部分も大きいですが、

ぜひとも継続して開催してほしい、いやしていくのに協力したい、と思いました。

皆様お疲れ様でした、来年もお会いしましょう。

2012-10-01

YAPC::Asia 2012に行ってきました YAPC::Asia 2012に行ってきましたを含むブックマーク

blogに書くまでがYAPCです。

今年もYAPC::Asia 2012に前夜祭含めて参加してきました。


例によってトークの細かい内容はgihyoさんの記事や

各スピーカーの方々が資料をアップしてくれるのにお任せしたいと思います。


今年は、2年ぶり2回目のスピーカーとしての参加でしたので、その辺メインで。


トークしようと思ったきっかけは、同じチームの人が喋るから、っていうのに

引っ張られただけで特に強い意図があったわけではなく・・・

ここ最近の会社の取り組みで、他人が頑張った事をさも自分の功績の如くエラそうに喋る。をしてきました。


資料はSlideShareにアップしましたが、YAPCのトークページからでも閲覧可能です。

(動画もそのうちあがるはず)


会場で質問いただいた中で、ちょっと上手く答えられなかったかなという部分について補足します。

「既存のuseして呼び出しているメソッドをServiceProcedure経由に置き換える場合にデグレをどう担保しているのか?」

という質問をいただいた(と記憶してます)

これにつきましては、ServiceProcedure呼び出しは新しいパブリックなI/Fの提供を行う、

という仕組みなので必ずしも既存の呼び箇所がすべて同時に置き換わる訳ではありません。

つまり「呼び換え漏れ」というものはなく、それはただ移行段階であると言えます。

既存のメソッドに手を入れる訳ではなくAdapter層を設けているため新旧I/Fの併用が可能なためです。


ここからは会場で返答した部分ですが、呼び換える際に、I/Fが変わる事はちょいちょい起きます。

特にレスポンスの部分は元々がオブジェクトを返すような形式だった場合、ServiceProcedureはplainなデータを扱うと規定しているため、呼び側でオブジェクトを期待しているコードは修正する必要があります。それに合わせてテストの修正が必要になることもあるかと思います。

plainデータに縛っているのは、そこでオブジェクトを返してしまうと結局呼び側が他の名前空間モジュールを意識(=管理)することになってしまうためです。


2年前にトークした時には質問とかいっさいなかったので、質問をいただけるということは嬉しいことですね。

リハしたら毎回30分近くかかるものが、20分にきっかり収まってたので、どんだけ早口だったのかどんだけ言い漏れしてたのかは動画がアップされてから反省したいと思います。。




今年もいろんな方とお話しさせていただきまして、個人的に嬉しかったのは1日目の懇親会の時にlyokatoの計らいで、mizzyさんに通われている大学の授業について聞くことができました。

実は同じように大学に通いたいと考えていたので、どんな感じの授業なのかとても参考になりました。1日平均で4時間くらいは勉強されているということで、かなり甘く見てたのを思い知りましたが。。




YAPC全体としては、パネルディスカッションの時にも話が挙がっていましたが、ここ最近のYAPCでは技術的に新しくてみんなが「オォー」ってなるものは出ていない気がします。(2008年のMoose、2009年のPlackくらいまで)

例年ベストトーク賞などの優秀賞は会社の内容や業務に近い話をされている方が受賞されている傾向が多いようにも見えます。

(2日目の後夜祭で、「初めてYAPCに来た人とかだけが真面目に投票して、そういう人達に刺さるのが会社系トークなんジャマイカ」っていう会話をした記憶もありますが、それはさておき・・)

なので、まだ発表されてない方で、発表内容に困っている方でもどんどんトークすればいいんじゃないかと思いました。

かく言う俺も(賞とか貰ってないけど)まさにそれ系のトークですし。

逆にパネルの時に予見されていた「そろそろまた『新しい何か』が出てもいい頃」の方に踏み込むのももちろんアリではないかと。


いきなりYAPCは、と思った方は来月開催される予定のyokohama.pmに参加してみてはいかがでしょうか。




最後になりますが、牧さん・941さんをはじめとする運営スタッフ&ボランティアの皆様お疲れ様でした。

慣れ親しんだ東工大から離れて大変な面もあったかと思いますが、例年に近いくらい快適でした。

お陰様で安田講堂を写真に収め、近くにあった生協東大シャーペン東大ノートも買えました。

経理担当のJPA理事さんもお疲れ様です。

来 年 も 楽 し み に し て い ま す




今年もお土産写真を掲載して締めます。Thank you very much, Larry!

f:id:masartz:20121001141801j:image:w360

2012-07-10

Params::Validate をuseする時「use Params::Validate qw//;」と書くのを推す理由 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今年も楽しみですね!

2012-07-03

gitで別のリポジトリにpushする 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する」というのは多分あんまりないので、書き残しておきます