はじめに注意 個人的にはいままで参加したRubyKaigiには非常に満足しています。またスタッフやスポンサーの方々には言葉では言い尽くせない感謝の気持ちで一杯です。その上で、今後のRubyKaigiやRuby界を考えたときに、これだけは言っておきたいことをつらつらと書いてみます。スルー力を持たない人は読まない方がいいかもしれません。
RubyKaigiの問題点 一番の問題は目的を見いだせないこと。いや「開催すること」が目的になってしまっていることか。なんせRubyKaigiは大人が開催する有料「学園祭」になっているので、「やって楽しいこと、来て楽しいこと」を考えて構成されていると感じるとれる。「おもてなしの心」なんて言っている時点で、そっちがメインになってしまうのだろう。でもそれって参加者も含めて自己満足でしかなくて、それ以外の人たちになんら影響を与えられていない可能性がある。
RubyKaigi とはそもそもなんのために? そこで今一度考え直さないといけないと思うのが、開催する目的。開催趣意書には目的が書いてある。しかし、それ以前に、一体なんのために開催するのか。Rubyist の交流にためと言うのもあるかもしれないが、@tdtdsさんも言うように、もうそのステージは卒業しているはずだし、それならそもそも東京でやる意味が大きいとは思えない。交流のためなら地方に大物Rubyis を連れて行った方がいい。Rubyistにとって心地いい場所の提供ばかりしていても、もう仕方ない時を迎えたんだと思う。むしろ日々Pで始まりPで終わる言語やお茶みたいな言語を扱って疲れていたりするRubyistの癒しの場になっている。つまり逃げ場になって現実逃避しているだけじゃないだろうか。
スタッフのやり遂げた感がやばいと感じること これはスタッフにも言えて、「来年もスタッフとして頑張ろう」なんて思ってるとしたら、それも逃避に近い。みんながみんなそうだとは言わないが、高橋会長やかくたにさん、島田さんや設楽さんなんかは、スタッフとして走り回ってる場合じゃないんだよ。あなた達にはもっとやるべきことがあるはずだ。Rubyの将来やRubyistのことを考えるなら、学園祭で盛り上がって参加者におもてなしなんてしててはいけないはずだ。その辺にいるRubyist達が勝手に盛り上がって開催しているならそれでもいいのだが、日本Rubyの会として開催していることがもうダメなんだと感じる。
組織としての日本Rubyの会 日本Rubyの会はその公式サイトにあるように支援やイベント開催をその目的にしていると言うことだが、こちらもそろそろ次の段階へ行くべきなんじゃないだろうか。振興という意味ではエンジニアの中では浸透してきたのだから、それを仕事へつなげやすい環境を作るべきだろうと思う。そういう意味では、いまの組織体制だときついのだろう。だいたい全員が別に仕事を持っていてボランティアベースと言うところからして限界があるのは当然のこと。ならば組織として法人化するなりしてはどうかと思う。たぶん内部的にはこの話は出てるんだろうが、じゃあ誰がそこに所属する?となったときに答えが出ないのだろう。そりゃみんな自分の会社や生活があるわけで、そこはどうしようもない。かといって誰だかわからない人に任せるわけにもいかないので、辛いところ何だろうなと思う。でもやはり何かしら痛みを伴ってでもやってしまうべきだと思う。
エンジニアを幸せにする会議へ で、そうやって日本Rubyの会を法人化したとして、どういうRuby会議をやるべきか。それはRubyistを幸せにする会議。「いやー、楽しかったねー」と言うだけでは、仕事上がりの宴会と変わらない。そりゃその場の楽しさはあった方がいいだろけど、じゃあそれで仕事でもRubyを使えるようになり、アジャイルに仕事が進められるとは限らない。何というか、「瞬発力のあるその場の楽しさを胸に抱きながら、仕事の辛さに耐える」ような人が少なくなればいいかなと思う。
そのために自分ができること では自分には何ができるのか。まずはRubyを使って仕事をし、さらにRailsやjpmobileなどで貢献していくこと。そうすることでRubyを使える場所や仕事が増えるようになればなと思う。あとは可能であれば日本Rubyの会の運営に関わること。外から意見を言うだけでもいいし、中の人になるのでもいいけど、とにかく何かにつけて意見を言っておきたい。と言うかみんなも「RubyKaigi楽しかったです!」じゃなくて、言いたいことはちゃんと言うべきだと思う。あとは地域Ruby会議へもっと参加していこうと思う。いろんな地域のいろんな意見を聞くことは、今後の自分のためにもなるし、Ruby界隈のためにも繋がる。
まとめにならないまとめ つらつら書いたので全然まとまってないですが、いまの状況に対して漠然とした危機感というのを感じています。こういう話をいろんな人としたいですね。そういう場所として地域Ruby会議の懇親会とかいいんじゃないだろうかとか思います。とりあえず、まだまだ頑張ろうと思います。
RubyKaigi 2010 1日目 Opening <ul> <li>Theme</li> <ul> <li>Conflicts and Resolutions</li> </ul> <li>Good Timing</li> <ul> <li>Ruby 1.9.2 Released!</li> <li>Rails 3.0 coming soon!</li> </ul> <li>Start!</li> </ul> 諸注意 <ul> <li>名札忘れないように</li> <li>ネットワーク</li> <ul> <li>モバイルルータもダメそうだ</li> </ul> <li>フィードバックもしよう</li> <li>大ホールは飲食禁止</li> <li>各種諸注意</li> <li>コミュニティ・ナイト</li> <ul> <li>自分の分を持っていろいろ集まれー</li> </ul> </ul> Conflicts and Resolutions <ul> <li>漫談形式らしい</li> <ul> <li>@takahashim</li> <li>@a_matsuda</li> <li>@wycats</li> <li>@tenderlove</li> <ul> <li>translator</li> <ul> <li>@matz</li> <li>@lchin</li> </ul> </ul> </ul> </ul> 質問など <ul> <li>Different Rails 2 and Rails 3</li> <ul> <li>Rails 3 は 2 の上位互換</li> <li>いろんなところを書き換えているが、APIはそれほど変わっていない</li> <li>コアな部分を切り離したので、各パーツを独立で使うことができる</li> </ul> <li>merb と rails の統合で、当初描いていたゴールにたどり着いた?</li> <ul> <li>たどり着いている!見返してみてもその通りだと感じる。</li> <li>AR の代替物を簡単に使えるようになった</li> </ul> <li>Ruby 1.
softbank 回線は絶望的 wifi も人数が多いせいか絶望的 ここで emobile も絶望的っぽいので、回線はあきらめることにした RubyKaigi 2010 2日目 <ul> <li>昨日疲れたからか、かなりよく寝れたっぽいのが功を奏している気がした。</li> </ul> jpmobile 会議 <ul> <li>参加者の皆さんにより、いい情報交換ができました。</li> <li>後ほど別にまとめよう</li> </ul> 基調講演: Matz <ul> <li>Ruby 2.0</li> <ul> <li>Ruby 1.9.2</li> <ul> <li>Ruby 1.9.2 Award</li> <ul> <li>遠藤さん( @mametter )</li> </ul> </ul> </ul> <li>キーノートの苦悩</li> <li>Ruby 2.0 (笑)</li> <li>完璧に近い言語が、ある種限界</li> <li>Ruby は十分に良い言語</li> <li>つくばくんだり</li> <li>Matz's Goal: To Make Ruby nearly perfect</li> <li>"珍しくRubyのプログラムが書かれている"</li> <li>積み残しがある</li> <ul> <li>Local variable propagation</li> <ul> <li>使われていたら自動的にブロックの外側へ伝播させる</li> <ul> <li>「でも重箱の隅をつつくようなことは気にしないよ!」と言われる</li> </ul> </ul> <li>Mix-in defect</li> <ul> <li>インクルード時の構造が取り込まれるので、後で追加しても反映されない</li> </ul> <li>No private method</li> <li>Global monkey patching</li> <ul> <li>Classbox</li> </ul> <li>Integer division</li> <ul> <li>5 / 2 #=> 2</li> <li>mathn ?
RubyKaigi 2010 3日目 地域 Ruby 会議 Kaigi <ul> <li>Commit するまえに Conflict 解消しようぜ</li> <li>チェックイン</li> <ul> <li>かくたにさん</li> <li>島田さん (Sapporo)</li> <li>(島根の人)</li> <li>小川</li> <li>河野さん</li> <li>三浦さん</li> <li>武田さん</li> <li>小柴さん</li> <li>高井さん</li> <li>川上さん (松江の人)</li> <li>BECK さん (東京の人)</li> <li>米沢さん (toRuby)</li> <li>okkez (関西の人)</li> <li>松本 (名古屋の人)</li> <li>かたぎりさん (名古屋の人)</li> <li>片平さん (仙台の人)</li> <li>永井さん (Rubyist 九州の人)</li> <li>藤岡さん (福島の人)</li> <li>ひがきさん (関西の人)</li> <li>てらしまさん (鳥取の人)</li> <li>池沢さん (toRuby)</li> <li>せきさん (toRuby)</li> </ul> <li>RubyKaigi 歴 2010 のふりかえり</li> <ul> <li>名古屋01</li> <ul> <li>リソース不足で告知が遅れて、諸処にご迷惑をおかけした。</li> <ul> <li>作業者がいない</li> </ul> <li>話者がいない</li> <li>80人参加</li> <li>懇親会が濃かった</li> </ul> <li>東京03</li> <ul> <li>完璧な運営</li> <li>半年前から月一でMTG</li> <li>事前議題 -> 議論 -> TODO といういいサイクル</li> <li>クオリティを上げすぎないように</li> <li>懇親会ができなかった</li> <ul> <li>ドタキャンに備えて開催できなかった</li> </ul> <li>お金の問題</li> <ul> <li>スタッフ有料イベント</li> <li>儲からないのに誰かが負担しなければならない</li> <ul> <li>えにしテックが札幌Ruby会議に投資するのはどうなのか</li> </ul> </ul> <li>「俺のやりたいことをやらせろ」ということで高井さんが頑張った</li> <ul> <li>The RubyKaigi ではないことをやりたかった</li> <ul> <li>Talker や Workshop など</li> </ul> </ul> </ul> <li>Tokyu 01</li> <li>札幌 02</li> <ul> <li>懇親会はしなかった</li> <ul> <li>途中で時間を設けて、お酒のない懇親会をやった</li> </ul> <li>お金の問題</li> <ul> <li>やりたいと思ってる人がお金を出している状態</li> </ul> <li>01 よりも規模を大きくしてみた。手にのる範囲で。</li> <ul> <li>期待と思う人が増えれば話者に困ることはないんじゃないか</li> </ul> <li>タレント不足</li> <ul> <li>札幌の人たちが話すのをメインに据えた</li> </ul> </ul> <li>関西 02</li> <ul> <li>KOF にのっかって</li> <ul> <li>会場の心配はしなくてもいいがスケジュールを握られる</li> <li>考えるまもなく進めなくてはいけない</li> <ul> <li>他とは制約事項が違う</li> </ul> </ul> <li>毎月やる勉強会でお金を貯めて講師を呼ぶ</li> <ul> <li>okkez さんが RubyKaigi で営業してその人を呼ぶ</li> <li>今年は福井さんがやっている</li> </ul> <li>リソースが足りない</li> <ul> <li>スタッフが KOF の参加者なのでいろいろ大変</li> </ul> </ul> <li>松江 02</li> <ul> <li>01 が島根大学の野田先生が主導で</li> <li>02 は Matsue.
jpmobile on Rails 3.0View more presentations from Shin-ichiro OGAWA. と言うわけで準基調講演とかいろんな冷やかしを受けながらもなんとか発表終わりました。いやー、緊張しましたがなんとか発表できて良かったです。あとは今日のjpmobie Kaigi 2010が終われば、ようやく楽しめるようになるんじゃないかと思っています。
ところで、コミュニティ・ナイトのあとに懇親会行ったのですが、外国からの参加者が7割以上を占めるという、ある意味過酷な環境でした。英語慣れしてないのでかなり疲れましたが、それはそれで楽しかったです。さて、今日の懇親会はどうなることやら。
と言うわけで表題の通りRubyKaigi 2010にて「jpmobile on Rails 3.0」と言う発表をします。主な内容はRailsのソースコードを解説するというよくわからないことになりそうなのですが、次の日にあるjpmobile Kaigi 2010の前振りという感じで気軽に聞いてもらえればと思います。
まあ物理学会では大御所を前に持論を展開すると言うことは何度もやってきたのですが、さすがに技術系では初めてなのでいろいろ緊張してます。さてどうなることやら。
仕事で使うJRuby! そこが知りたい技術・開発・案件の最新情報 2010/08/05 19:00- ジュンク堂 池袋本店 抽象エア社員として参戦 はじめに 自己紹介 大場夫妻 橋本さん 中村さん(nahiさん) OpenSSLとかの人
本を出した経緯 大場さん 原書は2007年に発刊 @takai さん経由で知らせてもらった だいたい3部構成 Rails を使いアプリを開発しながら、それとは気づかずにEEにはまる感じ Java - Ruby / Ruby - Java の章がある 黒魔術から白魔術まで </ul> <li>原著作者に推薦文を書いてもらった!</li> <li>みどころ</li> <ul> <li>JRuby のリファレンスがある</li> </ul>
橋本さん
<li>DB Magazineでの連載</li> <li>2部構成</li> <ul> <li>後半にエンタープライズでRailsを使う上で注意すること</li> <ul> <li>Javaシステムとの連携</li> </ul> </ul> <li>Thomas Enebo に推薦文もらった!</li>
結論
2010/07/23(金) オプトさんの例のセミナー GREEのCTOの人 ソーシャルアプリでNoSQL(KVS)の話 KVSの利用者は少ない? 2/3ぐらい 副題 : 如何にして5キーに耐えるか NoSQL = Not Only SQL 世にプロダクトはたくさんある それぞれさまざまな特性がある(オンメモリ、分散、性能、実績などなど) デファクトスタンダードがないので乱立? </ul> </ul> それ MySQL(Drizzle) でできるよ
<ul> <li>それでもいいんじゃないかと思ってます</li> </ul> NoSQL と言い出すまでの歴史
<ul> <li>1998 年ぐらいから言われ始めたらしい</li> <li>第一期 : RDBMS でいいよね期</li> <ul> <li>最初はポスギレが多かった</li> </ul> <li>第二期 : memcached も便利だよね期</li> <ul> <li>まあセッションとかも使い始めたところ</li> </ul> <li>第三期 : やっぱりスケーラビリティだよね期</li> <ul> <li>mixi などでの分散とか</li> <li>sharding</li> <ul> <li>JOIN できない><</li> <li>トランザクションできない><</li> <li>複雑なSQL書いたら怒られた><</li> </ul> <li>RDBMS の機能を余り使っていない</li> <ul> <li>Relationa じゃないよね</li> </ul> </ul> <li>第四期 : 全部 RDBMS じゃなくてもいいよね期</li> <ul> <li>たぶんいまここ</li> </ul> </ul> NoSQLのデータモデル
と言うわけで初TOEICでした。予想通りリスニングが酷いですね\(^o^)/
さて、どうしようか….
まあ単純なことなんですが、営業や企画の人に技術用語を捲し立てる人がわりと多いですよね、と言うこと。
下手な専門用語を使うことで自分の首を絞める そういう時に限って、聞いてた人が拡大解釈してしまい、あとでいろいろ大変な目にあうことは少なくありません。「いや、そういう意味じゃなくてですね…」「でも、もうお客さんに言っちゃったよ?」なんで言う、ありがちな会話が繰り広げられたりするわけです。こうなってはいくら口論しても取り返しがつかないことが多いので、仕方なく作業することを強いられます。でもどうしてこうなってしまうのか。
本質を理解していないと説明できない 私自身もそうですが、用語の本質を理解していないと人に説明することはできません。大学・大学院とお世話になった先生に、「絵を描いて説明して。絵を描けないということは、ちゃんと理解していないということ」とよく言われました。自分が理解していればそれを図示して、つまり本質をわかりやすく絵に描けるはずだというのです。最初はよくわかってなかったのですが、博士課程あたりでその重要性を理解できた気がしています。物事の本質を理解せずに話をしようとしてもうまく伝わらないだけでなく、間違った認識を与えてしまうこともあります。
ちゃんと説明するのは難しい では、本質を理解した上で話せばいいのかというと、そうでもありません。今度は何が必要とされているのかを認識しないと、的外れな内容を説明してしまいかねません。つまり聞き手の状況や認識を考慮して説明する必要があるのです。仕事であればその全容を把握して、何が問題となっているのかを理解しないと大変なことになります。的外れな回答になってしまって、やったこと全てを巻き直しなんてことになりかねません。
相手の立場になって考える そう言う意味で簡単なようで意外にできないのが、相手の立場で物事を考えるということ。「俺はそうは思わない」と決め付けずに、何故その結論になったのかを考えないと、いつまでも状況は変わりません。とは言え、どうしても理解できない時もあるでしょう。その時は新天地を目指せばいいだけです。
「できないこと」じゃなく、「できること」をまず言おう また「それじゃ無理ですよ、だって・・・」といきなり言うのではなく、「これではどうですか」と提案することも重要です。一見当たり前のことですが、意外にできないものです。面倒な実装になりそうだったり、手間がかかったりと、ネガティブなイメージが先行してしまうことが多いからでしょうか。でも結局「無理ですよ」といって別の大きな手間がかかってしまうことって多くないですか?そう言うのから脱却するためにも、否定から入るのではなく肯定から行くべきだと感じています。
扱いにくい人にならないように また仕事が増えるだけなら、まあそれもよくないのですが、まだましですが、社内の信用を失うことになる可能性があります。「あの人何言ってるかわかんないよ」や「あの人話しにくいし扱いにくい」と言われるようになってはおしまいです。私自身は、難しいことや不可能そうなことを、自分のアイデアや技術力でなんとかしてこそ、技術者の本領発揮なわけですから、「そんなの無理ですよ」という前に一つでもアイデアを出して見たいと思っています。