stnard.jp http://stnard.jp Everyday studying. Sat, 04 Sep 2010 05:51:26 +0000 http://wordpress.org/?v=2.9.2 ja hourly 1 RubyKaigiついて思うこと http://stnard.jp/2010/09/04/362/?utm_source=rss&utm_medium=rss&utm_campaign=rubykaigi%25e3%2581%25a4%25e3%2581%2584%25e3%2581%25a6%25e6%2580%259d%25e3%2581%2586%25e3%2581%2593%25e3%2581%25a8 http://stnard.jp/2010/09/04/362/#comments Sat, 04 Sep 2010 05:50:48 +0000 rust http://stnard.jp/?p=362 はじめに注意

個人的にはいままで参加した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会議の懇親会とかいいんじゃないだろうかとか思います。とりあえず、まだまだ頑張ろうと思います。

Tags: ,

Related posts

]]> http://stnard.jp/2010/09/04/362/feed/ 0 RubyKaigi 2010 3rd day http://stnard.jp/2010/08/31/365/?utm_source=rss&utm_medium=rss&utm_campaign=rubykaigi-2010-3rd-day http://stnard.jp/2010/08/31/365/#comments Tue, 31 Aug 2010 03:24:22 +0000 rust http://stnard.jp/?p=365 RubyKaigi 2010 3日目

地域 Ruby 会議 Kaigi

  • Commit するまえに Conflict 解消しようぜ
  • チェックイン
    • かくたにさん
    • 島田さん (Sapporo)
    • (島根の人)
    • 小川
    • 河野さん
    • 三浦さん
    • 武田さん
    • 小柴さん
    • 高井さん
    • 川上さん (松江の人)
    • BECK さん (東京の人)
    • 米沢さん (toRuby)
    • okkez (関西の人)
    • 松本 (名古屋の人)
    • かたぎりさん (名古屋の人)
    • 片平さん (仙台の人)
    • 永井さん (Rubyist 九州の人)
    • 藤岡さん (福島の人)
    • ひがきさん (関西の人)
    • てらしまさん (鳥取の人)
    • 池沢さん (toRuby)
    • せきさん (toRuby)
  • RubyKaigi 歴 2010 のふりかえり
    • 名古屋01
      • リソース不足で告知が遅れて、諸処にご迷惑をおかけした。
        • 作業者がいない
      • 話者がいない
      • 80人参加
      • 懇親会が濃かった
    • 東京03
      • 完璧な運営
      • 半年前から月一でMTG
      • 事前議題 -> 議論 -> TODO といういいサイクル
      • クオリティを上げすぎないように
      • 懇親会ができなかった
        • ドタキャンに備えて開催できなかった
      • お金の問題
        • スタッフ有料イベント
        • 儲からないのに誰かが負担しなければならない
          • えにしテックが札幌Ruby会議に投資するのはどうなのか
      • 「俺のやりたいことをやらせろ」ということで高井さんが頑張った
        • The RubyKaigi ではないことをやりたかった
          • Talker や Workshop など
    • Tokyu 01
    • 札幌 02
      • 懇親会はしなかった
        • 途中で時間を設けて、お酒のない懇親会をやった
      • お金の問題
        • やりたいと思ってる人がお金を出している状態
      • 01 よりも規模を大きくしてみた。手にのる範囲で。
        • 期待と思う人が増えれば話者に困ることはないんじゃないか
      • タレント不足
        • 札幌の人たちが話すのをメインに据えた
    • 関西 02
      • KOF にのっかって
        • 会場の心配はしなくてもいいがスケジュールを握られる
        • 考えるまもなく進めなくてはいけない
          • 他とは制約事項が違う
      • 毎月やる勉強会でお金を貯めて講師を呼ぶ
        • okkez さんが RubyKaigi で営業してその人を呼ぶ
        • 今年は福井さんがやっている
      • リソースが足りない
        • スタッフが KOF の参加者なのでいろいろ大変
    • 松江 02
      • 01 が島根大学の野田先生が主導で
      • 02 は Matsue.rb の高尾さんが主催で
        • 場所は行政が確保している
        • 地元の発表がしっかりしていて、80人ぐらいの参加者が
        • 高尾さんが一人でやっている
    • 仙台 02
      • いっぱいいっぱい
      • 片平さんが過囲え込みすぎていて、周りの人がいろいろ助けてくれた
      • ネタがない
        • 01 は東北の Rubyist を呼んだ
        • 02 は田舎親方 Ruby 会議をやった
      • 有料にした
        • 発表する人も
      • 01 は OSC に乗っかってみたが、いろいろ大変だったので、次回はやらないでおこうと思った
    • (できなかった) 九州 02
      • 01 は行政との共催
        • RBC から当日のヘルプがもらえなかった
        • 200 人規模
      • 02 は軽くやろうと思ってた
        • Rubyist 九州の年齢層が上がった
          • コミュニティ世代の問題
          • 代表の意気込みが薄れているところがある
        • 地理的に集まらない
          • スタッフになる人がいない
        • コミュニティの問題
          • 永井さんが代表でもないので判断できない
          • 入りづらい雰囲気があった
          • 運営でいろいろ問題や悩みがあるので、地域 Ruby 会議をすることができない感じ
          • 同じ地域にコミュニティが2つある
          • 長い歴史があるということが問題になっている
    • とちぎ 02
      • もともと toRuby 拡大版
    • Tokyu 02
      • スタッフを 10 人に
      • 合計 20k ですんだ
      • ゆるくやった
  • 参加者でいくと凄くいい
  • 中央から地域にという流れは必ず来るという問題意識
    • 社会を回すためのコミュニティとして Ruby コミュニティが成長していく
  • 来年まで地域 Ruby 会議 Kaigi ができないのが辛い
    • 複数地域での共催
      • タレント不足の問題を解消したい
      • 地域 Ruby 会議をやる以上の問題があるので、先に延ばしたい (かくたに)
  • 地域にタレントはいる
  • 東京 03 には Workshop がいる
  • “Ruby 会議が町にやってきた！”
    • Ruby 会議は呼び込むための名前として使ってもらいたい
    • ビッグネームもそういう風に使ってもらいたい
    • 仙台は matz でも人は来ない
  • メリハリをつける
    • 札幌では勉強会はだらだら、会議はしっかり
  • 勉強会の運営や開催方法について
  • 他の地域の Ruby 会議に参加して欲しい
  • こういう話をしたい
  • RubyKaigi 歴 2011 にむけて
    • 関西03
      • 11/5, 11/6
    • 札幌03
      • 12/4
    • 松江.rb
      • 1/末 〜 2/頭
    • Tokyu
      • 1/末
    • 名古屋
      • 1/末

Termtter Kaigi

  • ちょっとうるさい人がいる
    • 別にいいが
  • Termtter の紹介から
    • なぜか rvm の紹介が

There is No Spoon

  • かくたにさん
  • Asakusa.rb のインターフォン係
  • Ruby has “Quality”
  • 主観と客観の前の、直感的に感じるもの #=> クオリティ
  • Ruby is the Red Pill.
  • 少数精鋭でやるほうが良い
  • 人とコンピュータの間に価値を置いていくのが Ruby
  • コミュニティ
    • Regional Ruby Kaigi
    • コミュニティはツリーではない
    • 大事なのは個人が活動を続けるというプロセス
    • いまできることから始めてみる
  • かくたにさんの気持ちを、みんなに伝えるためのプレゼンだったのではないでしょうか

基調講演

  • The PASSIONATE PROGRAMER
  • Chad Fawler
  • これもあとで別に感想を書こう
Tags: , , , ,

Related posts

]]> http://stnard.jp/2010/08/31/365/feed/ 2 RubyKaigi 2010 2nd day http://stnard.jp/2010/08/31/364/?utm_source=rss&utm_medium=rss&utm_campaign=rubykaigi-2010-2nd-day http://stnard.jp/2010/08/31/364/#comments Tue, 31 Aug 2010 03:22:36 +0000 rust http://stnard.jp/?p=364
  • softbank 回線は絶望的
  • wifi も人数が多いせいか絶望的
  • ここで emobile も絶望的っぽいので、回線はあきらめることにした

    • RubyKaigi 2010 2日目

    • 昨日疲れたからか、かなりよく寝れたっぽいのが功を奏している気がした。

    jpmobile 会議

    • 参加者の皆さんにより、いい情報交換ができました。
    • 後ほど別にまとめよう

    基調講演: Matz

    • Ruby 2.0
      • Ruby 1.9.2
        • Ruby 1.9.2 Award
          • 遠藤さん( @mametter )
    • キーノートの苦悩
    • Ruby 2.0 (笑)
    • 完璧に近い言語が、ある種限界
    • Ruby は十分に良い言語
    • つくばくんだり
    • Matz’s Goal: To Make Ruby nearly perfect
    • “珍しくRubyのプログラムが書かれている”
    • 積み残しがある
      • Local variable propagation
        • 使われていたら自動的にブロックの外側へ伝播させる
          • 「でも重箱の隅をつつくようなことは気にしないよ！」と言われる
      • Mix-in defect
        • インクルード時の構造が取り込まれるので、後で追加しても反映されない
      • No private method
      • Global monkey patching
        • Classbox
      • Integer division
        • 5 / 2 #=> 2
        • mathn ?
          • mathn + Classbox
    • Mix-in defect
      • Inheritance : 継承
      • LSP : Liscov Substitution Princible
        • Liscov 置換原理
      • undef があるので LSP じゃない
      • Ruby の継承は方としての整合性などは重要視されていない
        • 多重継承もないし
      • そこで Mix-in
        • 多重継承の使い方の一つの方法
      • Non primary class == Module
      • Problem
        • 名前の衝突を検出できない
          • 解決法もない
        • 継承関係の変更に追従できない、とか
      • 名前の衝突の検出
        • 意図的か？事故なのか？
        • alias を使った解決法は泥臭い
        • alias もコンフリクトする
    • mix
      • Traits-like ( from smalltalk )
      • 本当に”混ぜ”る
      • mix
        • モジュールのメソッドをすべてコピーする
        • 名前が重なるとエラー
        • mix だと定数が取り込まれない
        • mix 時に名前をどうするかを指定できる
        • 明示的に取り込む定数を指定できたりする
        • 定数も被らないように変更することができる
      • include よりも mix が短い
      • まだ真の private method が無いことが問題になる
        • そこで classbox
    • Ruby 2.0
      • もうすぐ始まる
      • 1.9 からはそれほど変更ないかも
      • Traits
      • Classbox
      • キーワード変数
      • 互換性に問題のない些細な問題
    • mix は順番によって違わないことが重要
    • “kind_of? とかくそ食らえ”

    KSP

    • つつがなく終了
    • “あなたが想像していたかくたにさんでしたか？”

    M-x ruby-and-emacs-workshop

    • iknow の zev さん主催
    • 裏番組が JRubyKaigi 2010 と Vim とペアプロという、これまた熾烈な戦い
    • すべて emacs の中で実行しています。
    • emacs 24 では ELPA がデフォルトになるらしい
    • irbsh
    • M-x occur
    • M-x で複数のスペースが一つになる

    UNIX 修正主義

    • akr さん
    • ちゃんと聞けてなかったので他の人のを見ることにしよう

    Lightning Talks

    Tags: , , , , , ,

    Related posts

    ]]>     http://stnard.jp/2010/08/31/364/feed/ 0     RubyKaigi 2010 1st day http://stnard.jp/2010/08/31/363/?utm_source=rss&utm_medium=rss&utm_campaign=rubykaigi-2010-1st-day http://stnard.jp/2010/08/31/363/#comments Mon, 30 Aug 2010 23:45:29 +0000 rust http://stnard.jp/?p=363 RubyKaigi 2010 1日目

    Opening

    • Theme
      • Conflicts and Resolutions
    • Good Timing
      • Ruby 1.9.2 Released!
      • Rails 3.0 coming soon!
    • Start!

    諸注意

    • 名札忘れないように
    • ネットワーク
      • モバイルルータもダメそうだ
    • フィードバックもしよう
    • 大ホールは飲食禁止
    • 各種諸注意
    • コミュニティ・ナイト
      • 自分の分を持っていろいろ集まれー

    Conflicts and Resolutions

    • 漫談形式らしい
      • @takahashim
      • @a_matsuda
      • @wycats
      • @tenderlove
        • translator
          • @matz
          • @lchin

    質問など

    • Different Rails 2 and Rails 3
      • Rails 3 は 2 の上位互換
      • いろんなところを書き換えているが、APIはそれほど変わっていない
      • コアな部分を切り離したので、各パーツを独立で使うことができる
    • merb と rails の統合で、当初描いていたゴールにたどり着いた？
      • たどり着いている！見返してみてもその通りだと感じる。
      • AR の代替物を簡単に使えるようになった
    • Ruby 1.9 のいいところと、はまったところを紹介してほしい
      • Python 3 と違って 1.8 と互換性のあるプログラムを書くことができるところ
      • エンコーディングについてが問題だった
        • 良かった点は、エンコードについてちゃんと考えるようになった
      • Rails が依存するライブラリは同時に 1.9 に対応した
        • ライブラリは早急に 1.9 で動くようにするべきだ
      • ruby-trunk でテストしていたので問題なくリリースできた
      • Rails 3.0 は来週リリースされるが、Ruby 1.9.2 で問題なく動くことを信じている
    • Ruby と Rails のコアコミッターになったのはなぜだと思う？
      • たくさん文句を言ったから
      • たくさんバグレポートを出してたくさんパッチを書いたから
        • Rails に関して言えば、熱意を出せばコミッターになれるよ
        • ただしパッチにはテストを書いてくれ
    • tenderlove は Rails 3 についてどう思う？
      • ActiveRecord については独立したコンポーネントとして利用できる状態ではないことが残念な点
        • ActiveRelation(Arel) を入れることで抽象化できるようになった
          • でもまだ作業が必要
      • 心配しないでも Rails 3.1 がでるから
    • Ruby と Rails のコアチームの違いをどう感じる？
      • 日本語と英語の間の壁が大きいようだ
    • 言い残したこと
      • お互いの言語を学ぶのがいいと思う
      • Ruby と Rails が共通の CI をも持てばいろいろいいんじゃないだろうか
      • 1.9 に移行しようぜ！

    jpmobile on Rails 3.0

    • いろいろ疲れました…
    • sub-class 化する方が alias_method_chain するよりも良かったらしい by @wycats
      • Rails 3.0 Release して Mail を理解したら変更してみようかな

    Ruby 親方会議 2010

    • 親方会議の紹介
      • 「Ruby を使って仕事をしているエンジニア社長や個人事業者の情報交換をする」を公開で。
    • RubyKaigi 2009 -> Sapporo RubyKaigi #02 -> toRuby Kaigi 02 -> Sendai RubyKaigi 02
    • rake:money があるので、社員を雇用している社長をパネラーに迎えて情報交換
    • なぜ親方会議をやるのか
      • 社長は孤独
        • 仲間がほしい！
        • エンジニア仲間が欲しい
    • オフレコの話もあるので気をつけて！

    自己紹介

    • 新井さん
      • もぐらの CTO
      • ビジネスの勉強をする勉強会を開催している
        • プログラムを価値あるものにするために
    • 山崎さん
      • スケールアウト CEO
      • 強力なメンツががっ！
    • 和田さん
      • ホームページがないことで有名な会社「タワーズ・クエスト」の社長です
      • 起業20年目で二代目社長
    • 大場さん
      • 万葉の社長様
      • 17:30 から Hyper Everyleaf Time!

    起業したきっかけ

    • 藤岡さん
      • 何かやりたかったので起業してみた
    • 新井さん
      • 言われたものをつくるのではなくて、自分で考えたものを作りたかったので起業した
    • 山崎さん
      • 将来的に窓際っぽくなる気がしたので辞めた
    • 和田さん
      • プログラム書きすぎて留年しました
      • エンジニアとしての知名度が上がったので
    • 大場さん
      • 最初はIMEの大手でキャリアプランが見えなくなったので
    • 最初に採用するのって大変じゃないですか？
      • まあその場のフィーリングっぽい感じで決まったっぽい (万葉)
    • 解雇するのって大変
    • 何を聞きたくてやってきましたか？
      • 社員として企業の利益に貢献できるようになるにはどうすればいいのか？
        • 新井さん
          • 社長と同じ目線で同じ感覚で話をできるといいんじゃないかと思う
          • どうすれば利益が出るのかを考えているのかはいいことです
        • 山崎さん
          • ソフトウェアのコピーはただであるということを、ビジネスに生かせればいいのではないか？
        • 大場さん
          • 利益を出すことと、生きていくことは必ずしも一致しない
        • 山崎さん
          • 会社は4番バッターだけじゃなくて、職人が欲しいときもある
    • 人を獲得していくために取り組んでいること
      • 和田さん
        • どういう人かわからないので採用にはリスクがある
        • 素をさらすことに気をつけている
      • 大場さん
        • 露出を増やす
        • 法律を守る
        • 嫌なことをしない
      • 山崎さん
        • ゲリラ戦法しかない
        • 人と会わないとどういう人か、どういうスキルかわかならない
        • 面白い仕事を準備している
      • 新井さん
        • 勉強会を主催している
        • ハードル高めの内容だといいんじゃないかと思われる
      • 藤岡さん
        • いきなり応募してきたりして困ることがある
        • twitter で応募してくるのが、いまのところあたりっぽい
    • 会社の目標と個人の目標
      • 藤岡さん
        • 会社: 自分がいなくても回る会社にする
        • 個人: 何か違うことをしたい
      • 新井さん
        • 会社: 会社として大きくしたい
        • 個人: 勉強して社会貢献したい
      • 山崎さん
        • 会社: 会社を大きくする
        • 個人: 技術が省力化に繋がっていないのがちょっとあれだなと思う。自分の本当にやりたいことができるようになることを目指している。
      • 和田さん
        • 会社: 会社を大きくする
        • 個人: 自分が書いたソフトウェアで働き過ぎを防げるようになることが大義。ゆとりを作れるようなソフトウェアを作って社会貢献にしたい。
      • 久保さん
        • 会社: 会社を大きくする
        • 個人: 個人の時間を作れるような環境を社員に提供したい
    • GIGAZINE 問題ではどう？
    • 他にもチョイスがあるにもかかわらず、弱小企業を選んでくれた人材にどう報いるのか？
      • 山崎さん
        • ストックオプションなどはないのでどうすればいいのか？いまは給料を高めにすることで報いようとしている。
      • 藤岡さん
        • 地元の雇用を守ること
      • 新井さん
        • 高い給与を出すことで報いようとしている
      • 和田さん
        • 経済的に報いるのは中長期的にやらなければいけないので、やっていく。
        • ソフトウェア産業の儲け方は特殊なので、いろいろ考えていきたい。
        • 人それぞれの報い方をやっていきたい。
    • 起業するときのパートナーはどう？
      • 藤岡さん
        • 欲しかったけどいなかった
      • 新井さん
        • 一人ではいろいろわからないことがあったので、パートナーを見つけて起業した
      • 山崎さん
        • 二人だとそれはコストになる。営業とか
        • アメリカだとスタートアップ資金が入ることがあるが、日本はない
        • 追い込まれると、お金に関していろいろある
      • 新井さん
        • 営業の人だとそれまでフリーでやってもらうとか
        • パートナーにするなら、フリーや起業したことある人の方がいい
      • 和田さん
        • 血縁は入れない方がいい
      • 久保さん
        • 長年の友人で、仕事も共にやっていた
        • 何で言い合おうと思ってやっています。

    参考文献

    • ネットワーク経済の法則
    • スティグリッツミクロ経済学
    • Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 [単行本（ソフトカバー）]
      • http://www.amazon.co.jp/Eric-Sink-Business-Software-%E9%9D%A9%E6%96%B0%E7%9A%84%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E4%BC%81%E6%A5%AD%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9/dp/4798117501
    Tags: , , , , , , , , ,

    Related posts

    ]]>     http://stnard.jp/2010/08/31/363/feed/ 0     jpmobile on Rails 3.0 in RubyKaigi 2010 http://stnard.jp/2010/08/28/358/?utm_source=rss&utm_medium=rss&utm_campaign=jpmobile-on-rails-3-0-in-rubykaigi-2010 http://stnard.jp/2010/08/28/358/#comments Fri, 27 Aug 2010 23:02:00 +0000 rust http://stnard.jp/?p=358 jpmobile on Rails 3.0

    と言うわけで準基調講演とかいろんな冷やかしを受けながらもなんとか発表終わりました。いやー、緊張しましたがなんとか発表できて良かったです。あとは今日のjpmobie Kaigi 2010が終われば、ようやく楽しめるようになるんじゃないかと思っています。

    ところで、コミュニティ・ナイトのあとに懇親会行ったのですが、外国からの参加者が7割以上を占めるという、ある意味過酷な環境でした。英語慣れしてないのでかなり疲れましたが、それはそれで楽しかったです。さて、今日の懇親会はどうなることやら。

    Tags: , ,

    Related posts

    ]]>     http://stnard.jp/2010/08/28/358/feed/ 1     RubyKaigi 2010にて「jpmobile on Rails 3.0」という題名で発表してきます http://stnard.jp/2010/08/26/356/?utm_source=rss&utm_medium=rss&utm_campaign=rubykaigi-2010%25e3%2581%25ab%25e3%2581%25a6%25e3%2580%258cjpmobile-on-rails-3-0%25e3%2580%258d%25e3%2581%25a8%25e3%2581%2584%25e3%2581%2586%25e9%25a1%258c%25e5%2590%258d%25e3%2581%25a7%25e7%2599%25ba%25e8%25a1%25a8%25e3%2581%2597%25e3%2581%25a6%25e3%2581%258d%25e3%2581%25be%25e3%2581%2599 http://stnard.jp/2010/08/26/356/#comments Thu, 26 Aug 2010 14:34:11 +0000 rust http://stnard.jp/?p=356 と言うわけで表題の通りRubyKaigi 2010にて「jpmobile on Rails 3.0」と言う発表をします。主な内容はRailsのソースコードを解説するというよくわからないことになりそうなのですが、次の日にあるjpmobile Kaigi 2010の前振りという感じで気軽に聞いてもらえればと思います。

    まあ物理学会では大御所を前に持論を展開すると言うことは何度もやってきたのですが、さすがに技術系では初めてなのでいろいろ緊張してます。さてどうなることやら。

    Tags: ,

    Related posts

    ]]>     http://stnard.jp/2010/08/26/356/feed/ 0     JRubyKaigi前夜祭に行ってきた http://stnard.jp/2010/08/09/350/?utm_source=rss&utm_medium=rss&utm_campaign=jrubykaigi%25e5%2589%258d%25e5%25a4%259c%25e7%25a5%25ad%25e3%2581%25ab%25e8%25a1%258c%25e3%2581%25a3%25e3%2581%25a6%25e3%2581%258d%25e3%2581%259f http://stnard.jp/2010/08/09/350/#comments Mon, 09 Aug 2010 04:45:02 +0000 rust http://stnard.jp/?p=350 仕事で使うJRuby! そこが知りたい技術・開発・案件の最新情報
    • 2010/08/05 19:00-
    • ジュンク堂 池袋本店
    • 抽象エア社員として参戦

    はじめに

    • 自己紹介
      • 大場夫妻
      • 橋本さん
      • 中村さん(nahiさん)
        • OpenSSLとかの人

    本を出した経緯

    • 大場さん
      • 原書は2007年に発刊
      • @takai さん経由で知らせてもらった
      • だいたい3部構成
        • Rails を使いアプリを開発しながら、それとは気づかずにEEにはまる感じ
        • Java -> Ruby / Ruby -> Java の章がある
          • 黒魔術から白魔術まで
      • 原著作者に推薦文を書いてもらった！
      • みどころ
        • JRuby のリファレンスがある
    • 橋本さん
      • DB Magazineでの連載
      • 2部構成
        • 後半にエンタープライズでRailsを使う上で注意すること
          • Javaシステムとの連携
      • Thomas Enebo に推薦文もらった！
    • 結論
      • 両方買うといいよ！
    • 総括 by nahi さん
      • Olavini の本は入門として買うとかなりつらい
        • ただし細かい部分も書いてあるので、さらに進むにはいいのではないか。
      • 橋本さんの方が入門としては良い

    JRuby の魅力

    • 大場さん
      • 好きなメソッド : to_java
        • Ruby のオブジェクトを Java のオブジェクトにいい案配に変えてくれる黒魔術
    • 橋本さん
      • 聞き逃したorz
    • nahi さん
      • JRuby の JIT コンパイラ

    仕事で使えるか

    • 橋本さん
      • 沖縄に幽閉されて地方自治体向けのシステムを作っていた
        • Thomas らに用賀でたまたますれ違って、「使ってみてよ〜」と言われたので
      • Ruby でもあるから危なくなったら切り替えられる
      • 1.2 のころだったので、かなりもっさりしていた
        • 1.4, 1.5 で早くなった
      • Java の利点
        • SOAP のライブラリの運用などで便利だった

    最近の Java の動向

    • Java EE6 がでました
      • アプリケーションサーバ用のAPI
        • WebLogic とか
      • SOAP が大ブーム
        • Java のアプリケーションサーバがちゃんと SOAP 喋れるようになってきた
        • REST 厨的には SOAP は滅んだと思ってたのに….

    Rails の魅力

    • 最初に Rails が動くのを見たときは感動した
      • Olavini が YAML の parser を書いて去っていった….
        • 4回もあったらしい
      • String を実装してあった
      • 鬼車を Java で実装しある
      • CRuby に忠実
        • バグさえも
      • Rails 3.0 も対応している

    JRuby を採用するには

    • いつも JRuby と言い続けたので
      • 変更に強い部分とそうでない部分を切り分けてみたり
        • Java で書く部分と Ruby で書く部分を分ける
      • インフラでは JRuby がいいんじゃないか
        • Windows サーバでは Java の方が有利
        • クラスタリングなどやりやすいんじゃないか
      • ただしすべての利点を活用できる訳じゃないので、そこは注意すべき
      • 地雷は根本的に避ける

    XML & Webサービス

    • 他社とつなぐのに堅くやるには Java の XML でやるのが利点

    JMS

    • 非同期通信のためにメッセージングキューの、標準化されたAPI

    JRuby Kaigi 2010

    • 2010/08/28 に Ruby Kaigi 2010 内で開催
      • JRuby Pony Show
        • JRuby の現状と今後を JRuby の開発者が話します
        • 9月に1.6が出るらしい
        • Android / GAE
      • RedBridge で Java -> Ruby を
        • 原田さん
          • Java アプリで Ruby を活用したい
      • JRuby on GAE/J のノウハウ
        • 13個の TIPS
      • JRuby on Rails の力を JavaEE 技術を使ってさらに高める 10 の方法
        • 本に書けなかったことを書きます
      • Ruby と DSL で MapReduce – Hadoop-papyrus
        • JRuby 上で Ruby で書いてしまえ
      • JRuby ソースコード詳説
        • JRuby のソースコードのどこに何があるかを示して、デバッグしやすいように解説します
      • LT募集
      • Tシャツ購入募集
        • ファイナンシャルサポートも混みで 4000 円

    最後に

    • JRuby 1.5 on Rails 2.3.x という安定していく環境の入門本を是非買いましょう
    Tags: , , ,

    Related posts

    ]]>     http://stnard.jp/2010/08/09/350/feed/ 0     「ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜」に行ってきた http://stnard.jp/2010/07/27/345/?utm_source=rss&utm_medium=rss&utm_campaign=%25e3%2580%258c%25e3%2582%25bd%25e3%2583%25bc%25e3%2582%25b7%25e3%2583%25a3%25e3%2583%25ab%25e3%2582%25a2%25e3%2583%2597%25e3%2583%25aa%25e3%2581%25a7nosql%25e3%2581%2582%25e3%2582%258b%25e3%2581%2584%25e3%2581%25afkvs-%25e3%2580%259c%25e5%25ae%259f%25e8%25b7%25b5nosql%25e3%2580%259c%25e3%2580%258d%25e3%2581%25ab http://stnard.jp/2010/07/27/345/#comments Tue, 27 Jul 2010 11:36:50 +0000 rust http://stnard.jp/?p=345 ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜
    • 2010/07/23(金)
    • オプトさんの例のセミナー
    • GREEのCTOの人
    • ソーシャルアプリでNoSQL(KVS)の話
    • KVSの利用者は少ない？ 2/3ぐらい
    • 副題 : 如何にして5キーに耐えるか
    • NoSQL = Not Only SQL
      • 世にプロダクトはたくさんある
        • それぞれさまざまな特性がある(オンメモリ、分散、性能、実績などなど)
          • デファクトスタンダードがないので乱立？
    • それ MySQL(Drizzle) でできるよ
      • それでもいいんじゃないかと思ってます
    • NoSQL と言い出すまでの歴史
      • 1998 年ぐらいから言われ始めたらしい
      • 第一期 : RDBMS でいいよね期
        • 最初はポスギレが多かった
      • 第二期 : memcached も便利だよね期
        • まあセッションとかも使い始めたところ
      • 第三期 : やっぱりスケーラビリティだよね期
        • mixi などでの分散とか
        • sharding
          • JOIN できない＞＜
          • トランザクションできない＞＜
          • 複雑なSQL書いたら怒られた＞＜
        • RDBMS の機能を余り使っていない
          • Relationa じゃないよね
      • 第四期 : 全部 RDBMS じゃなくてもいいよね期
        • たぶんいまここ
    • NoSQLのデータモデル
      • 1 : 1
        • ハッシュテーブル
        • 一番シンプル
          • kumofs / Flare / Voldemort とか
          • パフォーマンス / 安定性 / sharding / replication / Failover
          • サーバを追加すると自動で負荷が分散されたりする
      • メソッドとか
        • set / get / delete
        • add / replace / cas の違いとか
          • add -> INSERT
          • replace -> UPDATE
          • cas -> compare and swap (version 管理して意図しない上書きを抑制できる)
        • incr / decr -> increment / decrement
        • append /prepend
      • vector clock
        • consistency を確保するための仕組みらしい
          • 何かしらの指標によって、replication の失敗を発見して、回復しようとする仕組み？
      • consistency policy
      • serialized object
      • multi get problem
      • disk i/o -> tmpfs
        • sparse file problem
    • 実例
      • 複数のデータを一気にとるときに大変
        • 100パラメータ x 100ユーザ x 100アクセスとか
      • serialize する？
        • get は1回
        • 並列すると conflict -> CAS
          • 更新合戦になると大変 -> ある程度であきらめる
      • 値でのランキングとか
        • 要するに集計したい
        • 全データを dump する
          • あんまりすぎる
        • 適当なタイミングで RDBMS に flush
          • 一番無難
            • 集計系はリアルタイム性がなくても大丈夫だから
              • あとでやってみよう
      • だいたい in memory での運用
        • MMORPG とか
          • オンメモリでいろいろやって、レベルアップとかのタイミングでデータベースに flush するそうな
      • 1 : n
        • Redis / Casandra
      • Redis
        • 1 : 1
        • List
        • Set (Hash)
        • 便利になるが、パフォーマンスリスクが高い
        • さらに table っぽく
      • Casandra
        • Keyspace.ColumnFamiry.Key.Column
        • 多重Hashのような
        • バイナリログ + メモリテーブルのような感じ
      • m : n
        • Key の prefix search がしたい！
          • 解決法？
            • Index Server
            • Ring w/ Sorted Key
            • Skip Graph ?
      • value で検索したい！
        • DataStore でできてるよ？
          • index をKVSに置いている
        • MongoDB
          • Power Play っぽい？
            • 各ノードから検索してマージして持ってくる
    • RDBMS との使い分けも考えてみるのがいいと思っているらしい
    • Casandra / Redis の好きじゃないところ
      • 自動分散ができない？
      • master/slaveにはできるがslaveに書き込めたりする
    • GREE では？
      • Flare(1:1)のものだけ
    • serializeに適切なフォーマットは？
      • GREEはPHPなので…
      • 多言語ならMessagePackとかいいんじゃないでしょうか
    Tags: , , , ,

    Related posts

    ]]>     http://stnard.jp/2010/07/27/345/feed/ 0     TOEICを受けてきたの巻 http://stnard.jp/2010/07/22/342/?utm_source=rss&utm_medium=rss&utm_campaign=toeic%25e3%2582%2592%25e5%258f%2597%25e3%2581%2591%25e3%2581%25a6%25e3%2581%258d%25e3%2581%259f%25e3%2581%25ae%25e5%25b7%25bb http://stnard.jp/2010/07/22/342/#comments Thu, 22 Jul 2010 04:52:12 +0000 rust http://stnard.jp/?p=342

    と言うわけで初TOEICでした。予想通りリスニングが酷いですね＼(^o^)／

    さて、どうしようか….

    Tags: ,

    Related posts

    ]]>     http://stnard.jp/2010/07/22/342/feed/ 1     技術者はもっと説明責任を果たすべき http://stnard.jp/2010/07/12/104/?utm_source=rss&utm_medium=rss&utm_campaign=%25e6%258a%2580%25e8%25a1%2593%25e8%2580%2585%25e3%2581%25af%25e3%2582%2582%25e3%2581%25a3%25e3%2581%25a8%25e8%25aa%25ac%25e6%2598%258e%25e8%25b2%25ac%25e4%25bb%25bb%25e3%2582%2592%25e6%259e%259c%25e3%2581%259f%25e3%2581%2599%25e3%2581%25b9%25e3%2581%258d http://stnard.jp/2010/07/12/104/#comments Sun, 11 Jul 2010 23:55:39 +0000 rust http://stnard.jp/?p=104 まあ単純なことなんですが、営業や企画の人に技術用語を捲し立てる人がわりと多いですよね、と言うこと。

    下手な専門用語を使うことで自分の首を絞める

    そういう時に限って、聞いてた人が拡大解釈してしまい、あとでいろいろ大変な目にあうことは少なくありません。「いや、そういう意味じゃなくてですね…」「でも、もうお客さんに言っちゃったよ？」なんで言う、ありがちな会話が繰り広げられたりするわけです。こうなってはいくら口論しても取り返しがつかないことが多いので、仕方なく作業することを強いられます。でもどうしてこうなってしまうのか。

    本質を理解していないと説明できない

    私自身もそうですが、用語の本質を理解していないと人に説明することはできません。大学・大学院とお世話になった先生に、「絵を描いて説明して。絵を描けないということは、ちゃんと理解していないということ」とよく言われました。自分が理解していればそれを図示して、つまり本質をわかりやすく絵に描けるはずだというのです。最初はよくわかってなかったのですが、博士課程あたりでその重要性を理解できた気がしています。物事の本質を理解せずに話をしようとしてもうまく伝わらないだけでなく、間違った認識を与えてしまうこともあります。

    ちゃんと説明するのは難しい

    では、本質を理解した上で話せばいいのかというと、そうでもありません。今度は何が必要とされているのかを認識しないと、的外れな内容を説明してしまいかねません。つまり聞き手の状況や認識を考慮して説明する必要があるのです。仕事であればその全容を把握して、何が問題となっているのかを理解しないと大変なことになります。的外れな回答になってしまって、やったこと全てを巻き直しなんてことになりかねません。

    相手の立場になって考える

    そう言う意味で簡単なようで意外にできないのが、相手の立場で物事を考えるということ。「俺はそうは思わない」と決め付けずに、何故その結論になったのかを考えないと、いつまでも状況は変わりません。とは言え、どうしても理解できない時もあるでしょう。その時は新天地を目指せばいいだけです。

    「できないこと」じゃなく、「できること」をまず言おう

    また「それじゃ無理ですよ、だって・・・」といきなり言うのではなく、「これではどうですか」と提案することも重要です。一見当たり前のことですが、意外にできないものです。面倒な実装になりそうだったり、手間がかかったりと、ネガティブなイメージが先行してしまうことが多いからでしょうか。でも結局「無理ですよ」といって別の大きな手間がかかってしまうことって多くないですか？そう言うのから脱却するためにも、否定から入るのではなく肯定から行くべきだと感じています。

    扱いにくい人にならないように

    また仕事が増えるだけなら、まあそれもよくないのですが、まだましですが、社内の信用を失うことになる可能性があります。「あの人何言ってるかわかんないよ」や「あの人話しにくいし扱いにくい」と言われるようになってはおしまいです。私自身は、難しいことや不可能そうなことを、自分のアイデアや技術力でなんとかしてこそ、技術者の本領発揮なわけですから、「そんなの無理ですよ」という前に一つでもアイデアを出して見たいと思っています。

    Tags: , ,

    Related posts

    ]]>     http://stnard.jp/2010/07/12/104/feed/ 0