YAPC::Asia 2013 / Github によりバザールモデルへ

ブログを書くまでが YAPC、ということなので、書きます。

初日「モダンPerlリファクタリング

自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。

今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが

と @t_wada 御大よりお褒めに与ったので個人的には満足です。

リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。

2日目「Ruby の良いところ語ってください」

2日目は、@hotchpoch、@shyouhei、@masuidrive + @tokuhirom によるパネルディスカッション「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か?」の司会も務めました。しかしなんだこのメンツ。最初 @lestrrat さんから依頼を受けたときは全然違うメンツ案で、一ヶ月後に「決まりました!」と連絡が来たらこのメンバーになっていた。聞いてない。

Ruby 陣営から猛者が集まったわけだししっちゃかめっちゃかな会になる・・・かと思いきや、みなさんここ数年で流石に丸くなったのか、予想外にスムーズな進行でこっちが逆にびっくりしました。とはいえ、おとなしくしてもらったというよりは

と、言いたいことはちゃんと言ってもらったし、投票結果は3位だったりとで聴衆のみなさんにはそれなりに満足いただけたのではないかなと思います。実は @miyagawa さんをはじめパネルを聴いていた面々がその後の HUB でビール片手に自分にも言わせろ的にいろんな議論をしはじめて非常に面白かったのですが、熱量的にそっちの方が本番じゃないかという感じでその勢いや本音を壇上で引き出せなかったのが反省点ではあります。

内容的には、結局パネルディスカッションの最後のテーマである「Perlリスク」に関してがやはり一番の感心どころでしょうが結論は以前に @shyouhei さんが書いていた http://shyouhei.tumblr.com/post/44451702850/1 のポストにある論旨がすべてだったと思います。壇上にいた4人、それに関しては同意していたし。

だからまあ、こう言ってしまうと身も蓋もないかもしれないけど、リスクはPerlじゃない、Perl固執することにあるのです。

Perl って今どうなの」という問いに対してどう答えるべきかというのは難しいところなのだけど、個人的には、ライブラリの更新数であったり何か新しいパラダイムアーキテクチャが生まれてくる土壌を他言語と比較された場合には、かつての勢いが無くなっている (というかそんな勢いあっただろうか云々) という所は認めざるを得ないのかなと思うし、それはもう大前提とした上で、なぜ今 Perl コミュニティに自分が帰属しているか、どうコミットしていくかとか、どう Perl と関わっていくかということを考えたいと思っている。

Perl でも同じことができる、あの言語にあるこれはこうやればできる・・・ということを言っていくのも、ググラビリティその他の意味で必要だとは思うのだけど「Perl って今どうなの?」と疑問に思っている人が期待してる回答は多分そこではないだろうし、まずは他言語との差分をちゃんと受け入れるところから、かなと思います。そういう意味で今回のパネルでは、Ruby のコミュニティやエコシステムと Perl のそれの考え方の違いをそれぞれの識者から話してもらうことができたのが、自分の思うところを代弁してもらう形に誘導した形ですこしずるかったかもしれないとは言え、良かったと思ってます。

テスト、CI、Github ─ 伽藍方式からバザールモデルへ

毎年の YAPC ではときどき、誰がいうわけでもなく、その年のテーマがはっきり見える会、というのがたまにあります。

Audrey が来たときは Perl 6 ・・・というか Pugs 絡みで Haskell の話が盛り上がった年だったし、あちこちで Moose が話題になった年、AnyEvent が、Plack/PSGI が、みたいなときもあった。必ずしも毎年そういうテーマみたいなのが浮かび上がるわけではないのだけど、一方でそういうテーマが浮かび上がるときというのは、つまりその話題について同時多発的にみんなが感心を持ったということでありその年のトレンドを表しているといって間違いないと思います。

今年はどうだったかというと、テスト、Continuous Integration、Github あたりが話題に上ることがとても多かった。テストに関しては、CPAN モジュールのテストの仕方というよりは大規模アプリケーションでの分散テストの仕方であったり、アプリケーションにまつわるテストの書きにくい場所をこう書こうという話であったりとより業務寄りの話が多く、CI や Github の文脈もそうだった。たぶんこれが、今年のトレンド。

たとえばこのへん。

前者に関して、古巣の資料を紹介するのも変な感じだけど自分がいた頃の開発フローとは大きく変わっていたということも併せて述べたいということで、敢えて紹介します。後者は、やはり Github を使った Pull Request ベースの開発についての発表。とてもおもしろい。中にはこれを読んだり聴いたりでカルチャーショックを受ける人もいるのではないかと思う。

YAPC とは関係なく、このところ、Pull Request ベースで開発してテストを CI して Social Coding ですよ、というのを軸にした各社の開発フローみたいな話をよく聞く。そういうトレンドが、Webサービス開発なんかを手がける人が多く参加しているであろう YAPC でも表面化したということではないかなと思ってみていました。

ところで、今日こんなツイートをした。

Github/Github Enterprse あるいはその同種のツールを用いて Pull Request ベースの開発・・・つまり OSS 開発で培われてきたワークフローで自分たちのソフトウェアを開発する、というやり方が現在進行形で拡大していて、またその拡大度合いも勢いづいてきている印象を受けます。

これまでも Webサービス開発に関して言えば、アジャイル的であったり軽量な開発だったりするのはごくごく普通に行われてきたけれども、現場の実感としては Github によってコードレビューやテストや CI が当たり前のように根付くというのはそれなりに・・・というか、かなり大きな変化に感じているのでないかと思う。1年やそこらのスパンでそういう大きな変化が起こっていて、その中に身を置いている人が多いからこそ敢えてその話を YAPC でしようと思うモチベーションが沸くわけで、今年のそれはそれが同時にあちこちで起こっているということの証左じゃないかと自分は思いました。小さな変化でたいしたことのない話であれば誰も発表しようという気にすら、ならないわけですしね。

より大袈裟にいうとこれはつまり「Github はコンピュータ・プログラミングの民主化だ」という話があるけれども、それが Webサービスクラウドサービス、アドテクそのほかいろんな分野の開発現場で起こっている、ということ。Github を使った開発、つまり OSS のような開発プロセス ─ ソフトウェア開発の方法論が伽藍方式からバザールモデルへと移行していくという大きな流れがおそらくあって、その流れがこの一年の間に一気に速くなった。自分はそんな風に捉えています。いつか恥ずかしげもなく、あれがソフトウェア開発革命のターニングポイントのひとつだったよ、という風に言えるときがくるんじゃないでしょうか。

事実、かつて当たり前のようにスタートアップが Rails を採用することがニュースになった時と同じように、昨今のスタートアップは当たり前のように Github でコードをホストして、テストを書いて、Pull Request をして CI をするようになってきている。これはサービス開発の現場に定着していくやり方になると思います。

ただ、その現場で起こっている大きな変化はその外からはかなり見えにくい。それがもどかしい。・・・もどかしいけれどもこうして YAPC でそれが話題になって表面化したということは、やがてより広範な分野に知られるようになって、そのもどかしさはどこかに行くでしょうし、それはもう時間の問題だろう・・・ということを強く感じました。

えーと、なんか最後は YAPC に絡めて自分の言いたいことを言ってるだけになってしまいましたが、今年の感想は以上です。他にも PerlMotion とか、LT とか、その後の打ち上げで Shibuya.pm 同窓会みたいになったとか、いろいろ面白い話はあったのだけどこの辺で。

@941 さん、@lestrrat をはじめとするスタッフのみなさん、おつかれさまでした & ありがとうございました。(今年も) 楽しかったです!

・・・さてさて、来年以降どうしましょうかねー。

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy