たごもりすメモ

コードとかその他の話とか。

RubyKaigi 2015に行ってきた&しゃべってきた

この週末にあったRubyKaigi 2015に参加した。
RubyKaigiはRubyコミッタやその他の人々に、特に低レイヤや各種OSの事情に詳しい人なんかも多くて、これはこれで非常に刺激になっていていいなあ。言語ランタイムの最適化の話を何セッションも聞くとかは国内の他のカンファレンスでは自分はあまり経験しないので、いつも楽しい。

しゃべってきた

EuRuKo 2015で話したのと同じタイトルだけど内容はけっこう違ってて、なぜTDではRubyでqueue/workerシステムを必死に作っているか、みたいな話をメインに据えて話してきた。あまりRubyのコードそのものに触れることができなかったのがちょっと残念だけど、前提条件から丁寧に、必要性とどうなっているかを説明できたかなという気はする。
あとシステムを改善するときにどうしたらいいかという方針の話を質疑応答で少しできて、それもすごくよかった。質問してくれた @joker1007 さんのおかげです。

来年

京都だ! 楽しみ。行きたいなあ。そのためにもうちょっとコードそのものについて話せるようなネタを作りたいなー。

ISUCON5の出題をやった

(11/2 11:03 末尾に追記と得点経過グラフ掲載)

正確にはいままさに決勝のイベント中なのだが、思った以上に順調にイベントが進行していてヒマな上、完徹の後でコードとか書いてる最中に意識が飛んだりするのでコードも書けない。のでつらつらこれを書いている。

9月末にISUCON5予選をやり、10月末のいま決勝をやってます。3年ぶりのISUCON出題側でしたが、いやはや、過去最高にきつかった回だった。ちょっとday jobのほうでもクリティカルなあれこれが重なったのもあるけど。
しかし両方とも、直前までの死ぬ寸前みたいな追い込み状況に対し、イベントとしては*1大きな破綻もなく進み、本当に良かったと思っている。このイベントがイベントとして成立したことが本当に嬉しい。

そういったあれこれは本当に一緒に出題をやってくれた@kamipoさん、そして実装を手伝ってくれた@hydrakecatさん、@najeiraさん、@makingさん、@taroleoさん、@hokacchaさんのおかげだと思う。出題の傾向・内容ともにだいぶハードだった上、じぶんの作業の遅れがモロにイベント直前に皺寄せでいってしまった。
このような状況でコンテストが成立したのは本当にこの人達のおかげだ。ありがとうございました。

これまで何度か言っていたけど、ISUCONを予選だけで終える人達が大多数になってしまった以上、一度は「自分たちが知っている決勝の問題」を予選でもやってみたかった。今年の予選は(ちょっとギリギリ感があったけど)、それがいまできる最大限にできたと思う。今年の予選に参加した人には胸をはって言える。あれはISUCONだ。

決勝はこれまでとだいぶ方向性を変えてみた。詳しい解説は別途書く機会があると思うが、これまでのISUCONとはだいぶ違う。
これはふたつの理由があって、ひとつは*2これまでと同じような問題では同じような人達が勝ってしまうから、やはり方向を変えたい、ということ。もうひとつは、なんとなくだけど、ISUCONの出題内容・傾向をいちばんドラスティックに変えやすいメンタリティを持っているのは自分なのかなと思ったことがある。

ISUCONはまだ、たかだか5回しかやっていないだけの技術イベントだ。守らないといけないものはないし、これだけ出題というものが大変なんだから、出題者はなんでもやりたいことをやればいいと思う。参加者は不満があれば、自分で勝手にイベントをforkして出題をしてみればいい。

そうやって、全体として面白い、幅広く懐の深い開発者コミュニティになっていければいいなと、そう思う。

ああ楽しかった! 2年参加して今回出題したから、次は少なくとも4年は参加側かな! 超疲れたし!

結果

また! またしても! fujiwara組に勝たれてしまった!!!

他チームの得点が見えなくなった時間帯も含めた得点グラフはこちら。最終計測のもプロットされてます。

f:id:tagomoris:20151102110542p:plain

ベンチマーク走行は全体で1409回、優勝チームは46回実行リクエストがあったようです。最多チームは91回でした。

ということで

夜な夜なコードを書いていてゆっくりビールも飲めなかった俺の冷蔵庫を溢れさせてやろうという方は ぜひこちらのwishlistをどうぞ! 本当に溢れたらまたmorisniteやるかー?

*1:トラブルやバグはあれこれあったものの

*2:ISUCON2の時にも思っていたことだけど

EuRuKo2015に行ってきた

EuRuKo 2015 に出したトークのproposalが通ったので話しに行ってきた。往復旅費は現勤務先であるTreasure Dataに出してもらいました。ありがたや。宿泊費はなんとオーガナイザーが出してくれた。すごい。
2ヶ月ぶり生涯二度目のヨーロッパ、今回はオーストリアザルツブルク。あいかわらず行くのは遠いし乗り継ぎも必要でちょっと大変だけど、それでも行ってよかった。たいへんよかった。

前のドイツ行きとちがって今回は日本から他の参加者もいたので、というかまつもとさん、笹田さん、鳥井さんという……ひええ、超豪華メンバー、だったので、英語で疲れたときに普通に日本語で話ができるのがありがたかった。あんまり大勢日本人がいるのも風情がないが完全にぼっちというのもきついので、このくらいだと英語でしゃべる機会もそこそこあるし、いいな。

ということでしゃべってきた。

ふつうに会社名をタイトルに入れてCFPに応募したのが通ったからそのまましゃべってきたんだけど、カンファレンス全体的に他のスピーカーの人達がまったく自社企業のアピールをしないので、ええコレまずかったのかな、という気分にちょっとなったのは事実。でもこれで通ったしなあ。
データ解析系の話は縁が遠い人が多いのかなという印象の反応だったけど、それでも終わったあとで色んな人とあれこれ話をした。自分で作ってる人はやっぱりデータストアやら何やらに苦しんでいる人が多いいっぽう、自分でHDFSとかをホストせずS3に頼ったほうがよいアーキテクチャだということには懐疑的な人も多いようだった。いやー、S3のパフォーマンスすごいよ、という話を何度かした。
いっぽう縁が遠い人にはなんでいちいちそんなソフトウェアを自分達で(Rubyで)書いてるんだ、ということがうまく伝わらなかったようなので、その部分はもっとちゃんと話すべきだなあという感じ。じつは同じ話で RubyKaigi 2015 にも通っているので、そのあたりを直してやりたいと思ってる。

他のスピーカーの話は、なんというか、いろいろ。あまりプロダクションシステムの話をする人は多くなくて、教育だとか素朴な要素技術(SSL/TLSの話とか!)とか、良くも悪くもアカデミックに近いというか開発者コミュニティそのままのカンファレンスという手触りだった。これはEuRuKoだからなのかヨーロッパだからなのか、興味深いところ。隣に座ってた人と話してたらPerl6を話の例に出されてうおっヨーロッパっぽい! と思ったこともあった。

雑談してるときの英語にほとんど困らなくなってたのはよかった。プレゼンテーションも資料を作るところ含めて日本国内でやる場合とほぼ同じ程度の準備、で、まあ英語についてはそう悪くなくやれたんじゃないかな。これはTreasure Dataに入ってから明らかに進歩したところだと思う。

しかしザルツブルクはとにかく街がすごい。まさに多くの日本人が色んなものの刷り込みの結果脳裏に思うような、古き良きヨーロッパの街だ! という感じがする。だって川と橋と教会・聖堂と広場と市壁と断崖と城だぞ。石造りの建物が密集してその間に狭い路地がはりめぐらされてるし、ちょっと山っぽいところを歩いていると木々のむこうから古い城館が現れるし、あちこちに怪しげな門があるし。もうたまらん。

あとは肉を食べ肉を食べ芋を食べチーズを食べ肉を食べ。

ビールビールビールビールビール。

ザルツブルクにも大きいビールメーカーがあるらしいし、そのほか地方のビールもあれこれあった。そんなに多く飲んだわけじゃないけど、けっこう満足できる感じでたいへんよい。

ウィーンだと甘いものがすごいことになってたらしいが、ザルツブルクでもちょっとだけ楽しんだ。よかった。

ということで、非常に良い旅行だった。来年はブルガリアのソフィアらしい。
とにかく普段と異なる経験、USやアジアのカンファレンスに行くのとはまた全然違う経験ができるので、未経験の人には本当にお薦めです。楽しかった!

java-ja.OSS でOSSの話をしてきた

自分はべつにOSSの偉い人でもなんでもないのだが、YAPCで話したこととその発展みたいな感じでどうよということがあって、ざらっと話してきた。イベントはこちら。

java-ja.OSS - connpass

で、スライドはこちら。YAPCの再演でもいいよってことだったけど自分がそれじゃつまらんので、その後の話なんかも含めて取捨選択した。これまでの話は知ってる人が(会場には)やっぱり多かったので、発展的な話題とか細かいところをひろっていくような話にしたつもり。

OSSそのものについてどう思うかっていうの、実際に自分に強い意見があるかというとそんなにはなくて、ストレスを感じなくていいケースではいちばんストレスのない方法を淡々と選びたいなあ、と思うくらい。
そうでないもの*1にはそれはそれで色々あるけど、それはまあ仕事だからなあ、という感じ。日本国内のコミュニティだと仕事としてOSSをやっている会社がほとんどない関係で、そのあたりの話はちょっと興味深い人はいたかもしれない。あるいは、現実離れして聞こえたかもしれない。……ところで仕事としてOSSをやっているTreasure Dataという会社があるらしいよ!

ところでOSSの話をするときに自分がどの視点に立脚しているかを前提として話しておくのは本当はけっこう大事で、それによって考え方や行動様式がだいぶ変わるから。というのは、イベント翌日にTwitterで流れてたtweetを見ても思った。

これは当日に @a_matsuda さんの話を聞いててもすごく思っていたところで「あー莫大なユーザと大規模な開発者コミュニティをかかえてる超強力OSSプロダクト*2はやることが違うなー強いリーダー*3もいるしすげーなー」みたいな。立場が違うとやることが変わる。
ただし唯一(?)共通していたのが「走り続けないと死ぬ」みたいなやつで、これはRubyの開発とかでもコミッタの人々*4がよく言っていることだと思う。違う視点の話だけど毎日コミットするのを継続するっていうやつ、自分は怠惰なので不可能だけど、なるほどなあ、ということを思いはする。

なんにしろ、こういう機会があって自分の思うところをしゃべったり、他の人の話を聞きながら適度にツッコんだりできる機会はたいへんありがたい。
あと夜中まで超面白かった。ありがとうございました。

*1:会社のプロダクトとして推していくケース

*2:Rails

*3:DHH

*4:なぜかイベントにぞろぞろいてウケた

続: OSSプロダクトとコミュニティの話

先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。

t-wada.hatenablog.jp

t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。
明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。

なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく反映しているし、質疑応答の内容などもあるので動画を見るとよいかもしれない。

コントリビューション vs コードの統一性

ごく当たり前のことだが、ソフトウェアというのは、一人で書いたコードが100%を占めていれば、最も統一性のあるコードになる。ただし人間は2〜3ヶ月も経てば別人に等しい何かに変貌してしまうこともままあるため、ここには「短期間のうちに一人で書いたコード」という制約が付く、こともある。

そのコードに何らかの設計あるいは統一されたスタイルというものが無ければそれはその人の責任だが、それはとりあえず問題外として置いておくことにする。

あるソフトウェアがある。どういった目的のために書かれたのかが明確であり、理解しやすい外部APIを持ち、良い効率で動作する。全体の設計は十分にシンプルで理解しやすく、一瞥すれば統一性があって読みやすいことがわかる。いまこの時に限って言えば、完璧なソフトウェアと言ってよい。*1

さて、このソフトウェアに外部から何らかのコードの貢献がある。それは全く知らない誰かからの機能の追加であったり、(その人にとって)意図しない動作の修正であったり、あるいは数ヶ月後の未来の自分からの仕様の変更であったりする。

このコードの貢献は、元の完璧であったソフトウェアを必ず乱す。当初ありえなかった変更がありえなかったはずの場所に入り、シンプルだった内部APIは拡張された仕様に対応するために醜く引数を足され、ひとつのことだけを正しく行っていた関数はなぜか2つ3つと機能を内包するようになる。
貢献者が未熟だから起きるわけではない。どんなに優秀なプログラマでも他人のコードの統一性に完璧に寄り添うことはできないし、例え変更を加えるのがオリジナルの開発者であっても、数ヶ月あるいは数年も経つと書くコードの癖は変わる。ソフトウェア開発者はリリース後に必要となる変更を全て予期することはできないし、であれば、予期できなかった変更は元の完璧なコードに不可避な変更を押し付ける。

OSSプロダクトの開発と利用の促進を進める上で、これは必ず起きることだ、と思う。

もちろんあらゆる貢献を拒絶すればこの変化の進行を最小限に抑えることはできるが、ユーザとユースケースが広がらずメンテナンスの行われないソフトウェアの先に待つものは、単なる停滞でしかない。

プロダクトにおける沈降 vs コミュニティにおける浮上

最初は十分に小さく美しく軽快だったソフトウェアが、多方面からの多数のコントリビューションにより大きく醜く鈍重なものになっていく。一方OSSコミュニティにおける開発者たちは常に、小さく美しく、気軽にコントリビューション可能で、そして参入しやすいソフトウェアを求めている。

これは不思議でもなんでもないし、矛盾してもいない。誰だって同じことができるならより労力の小さいほうがいいに決まっている。既存プロダクトのコミッタなら既存プロダクトに変更を加えるほうが簡単だろうし、そうでなければ、まだ十分多くの人には使われていないかもしれないがしかし十分に小さく美しいソフトウェアがあれば、そちらに貢献するほうがおそらく合理的だ。

コミュニティはこうして、全体的には小さく美しいコードを志向する。これは個々のプロダクトが必ず肥大化し醜くなるという事実とバランスして動的平衡のような状態を作りだす余地を持っており、おそらく、そのふたつが完全にバランスしていれば、それはコミュニティ全体としては健全なのだろうと思う。*2

だからここまでを総合すると、t-wadaさんの疑問に対する答えを書ける。

健全な OSS 社会ときれいなソフトウェア設計との間には、やはり緊張関係はある、ということになるのだろうか。

ない。適切なバランスが保たれていれば。

プロダクトの長い寿命 vs コミュニティにおける新陳代謝

コミュニティ全体の動向に関係なく、各々のプロダクトはその寿命を可能な限り長くしようとする。これはそのプロダクトに主要開発者として関わっているチームがある限りは自然なことだ。自分が今現在開発しているソフトウェアについて「これはもう使うな」と言える人は多くはないだろう。
また別の事情もある。ユーザは大抵の場合、開発者よりもはるかに長い寿命をソフトウェアプロダクトに期待する、ということだ。今問題なく使えているものを変更する理由は普通のユーザには無い。

既に動いていて長い歴史をもっているプロダクトは、大抵強固な開発者チームをもっている。新規参入はやはり難しい……ケースが多い。長い歴史をもつプロダクトには過去様々なことが起きており、新規参入者にとっては理解不可能な設計やコードも、過去の経緯を知っていれば納得できることもある。
もちろんコアの開発者チームがあまり大きくなるとコミュニケーションにも影響が出る。

こういった事情がやはり、新規の参入者にとっては障壁になる。こうして若く元気のある人達はこぞって小さく美しいプロダクトの開発に夢中になり、長い寿命をもったプロダクトのコア開発者の平均年齢は、毎年ひとつずつ増える。

小さくて美しい vs 活発なメンテナンス

djbという開発者によって書かれた一連のソフトウェアがある。知らない人はぐぐってほしい。……昔は知らない人などいなかったものだが、今ではもしかして、知らない人の方が多いかもしれない。つまり、そういうことだ。
djbwareは小さく美しく、ひとつの目的を果たし、バグも(ほとんど)なく、また小さいツールの集合により機能を実現する形になっていたから、変化に対しても強靭だった。そしてそれ故に外部からの貢献といったものを受け入れず、孤立していた。

これはおそらく、djb本人にとっては本望だったのだろうと思う。そしてユーザから見れば、各OS/ディストリビューションのやり方を無視し、わかりにくい設定と操作方法を押し付け、必要な機能を足してくれないソフトウェアに見えたかもしれない。

世界はdjbwareに支配されなかったし、ApachePostfixやBindや、あるいはsupervisordやUpstartやsystemdや、そういった多くのソフトウェアが世界を分割している。

ここでは絶対的な基準や善悪を語っているわけではないから、djbのやりかたでもよいではないか、という意見はあるだろう。もちろん、どういうやり方をとるかはその人の自由だと思う。

All-in-one vs Plugin chaos

ソフトウェアに多くの機能を足しユーザコミュニティと開発者コミュニティを広げつつ、ソフトウェアのコアを小さく美しく保つ方法がある。プラグイン機構の導入だ。
ソフトウェアの機能の多くをプラグインに移譲し、誰でもプラグインを書き公開できるようにしておく。多くのユースケースを組込みのプラグインでカバーしつつ、それ以外に必要なものは必要な人が開発し公開できるようにする。

これはうまくいく。最初の設計が十分にうまく行われていればコアに必要な変更は後々までそう多くはない。多くの人が使いたい機能はもう誰かが過去に必要としたもので、うまくすればプラグインが公開されているからそれを使えばいい。無ければ書いて公開すればいい。
ユーザコミュニティが開発者コミュニティの性質を帯び、多数の機能とユースケースが自己増殖的に補完され、それが更にユーザコミュニティの拡大を後押しする。そしてソフトウェアのコアは小さく綺麗に保たれたままだ。

ではこのやり方をとれば何もかも全てがうまくいくかというと、もちろん、そんなことはない。待つのは膨大な数に膨れあがったプラグインの混沌だ。
目的の実現のためにどのプラグインを使えばよいか分からず、どのプラグインがメンテナンスされているかもわからない。似たような機能のプラグインがいくつも併存し、あまつさえそれぞれ使いかたが異なる……。

これは要するに All-in-one の場合にソフトウェア開発者が負っていた責任を、あらゆるプラグイン開発者に分割しただけとも言える。そしてもしかして、全体的な品質で言えば、悪くなってすらいるかもしれない。中心の開発者たちなら維持できたであろうある一定の品質の保証は、こうした社会では期待できないからだ。

それでもこれは、悪いことではない。コミュニティに多くのアクティブな開発者を供給し、より小さい単位でプロダクトの沈降と新陳代謝を促す。より早くより小さい単位でかかるフィードバックと分散された責任は、ひとつのチームの巨大な責任とそのチームの失敗による巨大なカタストロフの脅威よりは、たぶん我々にとっては扱いやすい。

整備されたガイドライン vs 10年ROMってろ

あるソフトウェアの品質を担保しようとするとき、もちろんコントリビュートされてくるコードの質の高低は非常に重要だ。そしてその質をどうコントロールするかは難しい問題だと思う。

ソフトウェアの変更にはいくつかの種類のものがあるが、最も行いやすいのは、機能を足すことだ。特に似たような機能が既に存在し、それとはちょっとだけ異なる機能を足す、というケースだろう。Linux kernelに新しいデバイスドライバを足す、Dockerに新しいロギングドライバを足す。

しかしこういうケースであれ、コントリビュートされてくるコードの品質には大きな差がある。既に存在する似たような機能のものを参考にすればいいのに、びっくりするくらい独特なコードで書く人は割といる。リポジトリ内のコードを読めばなんとなく受け取れる思想のようなものを考慮だにしないかのようなパッチとか。

この問題に対抗する方法はいくつかあるが、ひとつは、よく整備されたガイドラインを作ることだ。コードスタイル、設計方針、実装方針および使用してよいAPIなどについて詳細なガイドラインを書き、それを強制する。違反するコントリビューションは受け付けない。これにより最低限のコードの品質は保たれる。
しかしこれは非常に大きな手間と長い時間を必要とする。時代の変化や設計の変更に追従するための労力もわずかとはとても言えないだろう。小さく美しいソフトウェアプロダクトには似つかわしくない。

いっぽうもうひとつの方法は、もっとよく周囲のコードを見てそれを真似しろ、というフィードバックを出すことだ。明文化を避け、しかし明らかに空気を読んでいないコードは明確に拒否する。「10年ROMってろ!」
かくして閉鎖的なコミュニティができあがる……。

独裁者 vs 委員会

何を受け入れるべきで何を受け入れるべきでないかの判断は非常に難しい。いくつかの超有名プロダクトには独裁者が君臨していて、受け入れるべきないものを明確に拒否する力を振るっている。LinuxにおけるLinusPythonにおけるGuidoそしてRubyにおけるMatz。彼らのキャラクターは既に知られているから、言下に拒否するその姿勢は*3おおむね誰にでも受け入れられている。いいなあ。

そうでないコミュニティはApache Foundation傘下あたりに特に多く存在し、それぞれ委員会制とでも言うべき方向で集団での開発を進めている。よく使われているソフトウェアプロダクトにおいてはこれらはほぼ完全にいくつかの企業の勢力争いの場となっているように見える。
業界の巨人たる各企業がイチ押しの変更をゴリゴリ入れつつ境界面で押し引きする姿はそのソフトウェアのユーザとしては頼もしいものの、開発者として参考にできるものがあるかというと、無い。ざんねん。

開発者個人としての自分 vs プロダクトメンテナとしての自分

開発者個人としては、パッチひとつ送るにもあれこれと面倒な手続きを要求されるコミュニティはできるだけ敬遠したい。あれこれのものを使いつつ、できるだけ明快に使える小さく美しいソフトウェアと関わり生きていきたい。それができるだけのフットワークの軽さと、技術的視点でプロダクトの選択ができるだけのものを維持したい。

プロダクトメンテナとしては、ユーザがいる以上はきちんとメンテナンスをしたいし、また使用範囲が拡大すれば嬉しい。機能拡張の提案は真剣に受け取り、ソフトウェアの肥大化を招くかもしれないとしても受け入れることもあるだろう。そのプロダクトに技術的優位性があると思っている限りはどっしりと座りこんで開発を続けたい。

自分がメンテナをしているプロジェクトに自分でパッチを送れなくなる日が来ないようにする、という努力を続けたい、というはかない決意をするのが精一杯だなあ。

まとめ

結局どうするんだよ! というと、あらゆる2項対立のどの極端な点にもどうせ正解はないので、あれこれバランスの取りかたを試しながら、よさそうなやりかたを模索するしかないのだろう。
それでも一番大切なことがあるとすれば、こういったことを絶えず検討しなおすべきだということ、他の開発者とコミュニケーションをとることを絶対に拒絶すべきでないということ、くらいかもしれない。

*1:自分の理解では、t-wadaさんはこういったことを(理想的に)実現する、ということを抽象して「良いソフトウェア設計」と言ったのだと思っている。

*2:ソフトウェアの沈降速度が速くプロダクトの新陳代謝が追い付かなければ全体としてはあまり良くない状態のコードに携わる人数が増え、開発者にとってはストレスフルな状態になる。プロダクトの新陳代謝があまりに早過ぎるサイクルで起きると各々のプロダクトの熟成あるいはユースケースの充実が全く行われず、ユーザにとってはリスキーすぎるコミュニティになるだろう。

*3:時折ネット上のニュースを騒がせることもあるけれど

YAPC::Asia Tokyo 2015 にいってきた&しゃべってきた

毎年おなじみのYAPC::Asia Tokyo 2015が今年も行われたので参加した。いやー、たのしかった。

YAPC::Asia Tokyo 2015

しゃべってきた

Talk proposalは出してあって、acceptされたというので話してきた。前夜祭。ビール飲みながら発表ができるぞ! ということで、内容はガチでコードの話というよりはもうちょっとだけふわっとした気分で、OSSをどう開発するか、それをどう継続して広げていくか、みたいな話。

枠は前夜祭……と思ったら、前夜祭のところにはRejectconと書いてあって、えっそうなの、みたいな感じ。まあいいけど*1。思ったよりだいぶ多くの方に聞いてもらえてよかったです。満席になって立ち見も出てた。

ウケるOSSの作り方、そしてコミュニティを盛り上げる方法! YAPCモリストーク #yapcasia #yapcasiaD - Togetterまとめ

スライド以外に口でしゃべったこともあるし、質疑応答も非常に濃い状態になっていたと思うので、気になる人は動画を見てみてほしい。

あとでTLを遡ってみたところ、けっこう評判よかったようで安心した。していたら、こんな反応エントリも出てきた。うわお。

t-wada.hatenablog.jp

@t_wada さんや @hsbt さんとはカンファレンス期間中などにも(他の人も含めて)いろいろ話した。この話題は長くなるので、別エントリに分けて書く。

いってきた

毎年様々な人から聞く「YAPCの同窓会感がすごい」っていうやつ、これまでは色々な人と会えるしすごいなーと思う程度だったんだけど、今年行くと前職の同僚とかがいっぱいいて、あっこれ同窓会だ! ってなってた。

同時に今年は他言語なんかのコミュニティ・カンファレンスの知り合いも本当に多く来ていて、あらゆるところであらゆるところからの知り合いに会った。この何でもアリという感じはすごい……というか、あらゆるプログラミング言語・あらゆる問題意識の開発者が集まってきてやるカンファレンスはこれしかないのかもしれない。

会場がビッグサイトになったのもあってスペース全体の問題は去年に較べればはるかに改善されてた。ただトークによっては(というか結構な数のトークが)満員になっていて、満員だからもう入れない、というのもけっこうあった。話す側としては満員になってるとモチベーション高く話しやすいのは確かだけど。
ということで、いくつか特に気になるトークはちゃんと聞きつつ、あとは適当に会場内をふらふらして知り合いと話したりもしてた。わいわい。コーヒースペースが本当にすばらしかった。

今年でJPA主催という形で行われるこのイベントは最後(来年は無い)とのことなので残念ではあるが、どんなプログラマでも来られるカンファレンスというのがBeaconなのかな、という気がする。
まあなんだかんだいってYAPC::Asia TokyoはPerlという枠で収めず大きくなり続けていったので、それをいったんリセットして、誰でも来られるカンファレンスと、Perlに集中したもうすこし小さいカンファレンス*2に分ける、というのは悪くないアイデアだと思う。

何にしろ、いいヤップシーだった。主催者、スタッフ、スピーカー、参加者のみなさま、おつかれさまでした。またね!

*1:ベストトーク賞の対象外だったのはちょっと悲しかった。ハム……。

*2:それを誰が主催するかはともかく

JRubyConf.EU と Eurucamp に行ってきた

JRubyConf.EU 2015 のCFPにsubmitしたproposalが通ったのでポツダムに行ってきた。……のは7月末〜8月頭にかけてだったのでもう2週間以上経ってしまった。反省。
ポツダムドイツ北東部、ベルリンのすぐ隣の街。人生で最も遠くへの旅になった。旅費はTreasure Dataに出してもらった。ありがたい。

http://40.media.tumblr.com/a71c888ce9c180df473de710efc7a237/tumblr_ntbbol51W11s76egdo2_400.jpg

すごくよくオーガナイズされたカンファレンスで、主催者にはあれこれ親切にしてもらって、滞在中は不便なことは皆無だった。ぐれーと。

話したスライドはこちら。JRubyJavaなソフトウェアの上にプラグイン層を作るために使うと良いよ、という話。

JRubyConf.EU は Eurucamp という別のRubyコミュニティのカンファレンスのイベント内イベントという感じ。なのでJRubyConfには参加せずEurucampのみの参加という人もすごく多くて、スピーカーとしての立場が使えない英会話を行わざるをえなかった。なけなしの英会話力をふりしぼっている側にはけっこうきつい。今回は日本から行ったのは自分だけだったので、途中でコミュ力を使い果たしてカンファレンス最終日はほとんどくたばっていた。Eurucampはコードよりはかなりコミュニティ側に寄った内容のトークばかりだったというのも、まあ、あるかなあ。参加者の人に聞いたらこのカンファレンスが特徴的にそうらしいけど。

話した中ではやはり日本は遠い……ということでTDもFluentdもあまり知られていない。けど話すとそれはいいね! みたいにわかってはもらえる。もっと人の行き来が増えるといいなー、というか、もっと向こう行って話さないとな、というところ。遠いんだけどねえ。
LogStashの開発者と話せたりというあれこれはあった。日本に長いこと住んでいたドイツ人の人とか、日本の企業でリモートで働いているベルリン在住の人とかとも話せて、いやはや世界は広いのか狭いのか。貴重な経験だった。

ということで面白かったんだけど、次は10月にEuruko 2015がオーストリアザルツブルグであって、こっちも通っているので、また話しに行くのでした。

www.euruko2015.org