1/14,15 の２日間にわたって開催された Scrum Alliance Regional Gathering Tokyo 2013 に参加してきましたのでその模様の一部をご紹介させていただきたいと思います。

開催概要、タイムテーブルなど

• 公式のWeb
  http://scrumgatheringtokyo.org/2013/


• 一日目のtogetter
  http://togetter.com/li/439941

Agile Management – Learning From Software Development どのようにチームを導き、成長していくのか

Jurgen Appelo (ユルゲン・アペロ)氏

セッションのはじめはアジャイルコミュニティで最も影響力のある人々 の第６位の Jurgen Appelo氏によるセッションでした。

セッションの冒頭での「世界の半数の人は自分の仕事が嫌いなのに、ローン返済のためなどのために仕事をやめない」という話が印象的でした。

では、そのハッピーじゃない人たちがハッピーにになるための手段の一つがアジャイルであり、アジャイルに仕事をすることによって士気が上がって、ハッピーになっている事例があるということでした。

アジャイルと言っても手段や適応する局面はたくさんあるらしく、
その中で紹介されていた手法のうち、Beyond Budgeting という
脱予算経営、財務にアジリティを持たせるという手法は全く聞いたことがなく新鮮でした。

また、みんなが楽しく仕事をするためにマネージメントが重要。
ただ、重要なのは「マネージメント」であり、「マネージャ」ではない、
マネージメントは一人に任せるのにはあまりにも重要すぎるのでみんなで責任を持ってやろう！

Management3.0にはみんなの仕事を楽しくさせるヒントが詰まっているようです。

セッションを通して、マネージャとマネージメントをなんとなく混同していたことに気づいたことと、質疑応答であった「スキルセットではなくマインドセットで人を雇う」という一言が印象的でした。

話の随所にいろいろなヒントが詰まっている素晴らしいセッションでした。

Buy or Build: where did your agile come from 日本文化とアジャイル/スクラム

James O. Coplien (ジム・コプリエン)氏

２セッション目は、認定スクラムマスターの認定をしている組織のイベントでの壮大な認定資格を否定するというとても野心的なセッションでした。

スクラム認定を受けることによって何かができるようになるわけではなくて、
継続的にカイゼンを繰り返していくことに価値がある。

セッションの中で印象に残ったキーワードがいくつかありました。

• Scrumとは統制された失敗
• Scrumとはプラクティスではない。考えることだ
• Scrumとはどれくらい出来ていないかを見せる診断ツール
• Scrumに正解はない、正解がないのがScrum
  ここからも、実践の大切さを感じることが出来ました。

Cope氏のセッションからは
「やってみて、失敗して、学んで、カイゼンすればいいんだ」
と勇気づけられた気がしました。

スクラム組織導入入門

NECビッグローブ株式会社 安西剛氏

株式会社NTTデータ 柴山洋徳氏

株式会社バンダイナムコスタジオ 松元健氏

ヤフー株式会社 小野澤興平氏

午後の1コマ目は、すでにScrumを実践している各社の実践者の方からの、いかにして組織にScrumを導入したかという体験談を聞ける貴重なセッションでした。

4社4様の状況に応じて違ったアプローチでScrumの導入をして行っているのが印象的でした。
「コンテキスト重要」と言ったところでしょうか。

そんな中でも

• 小さな成功を積み重ねる
• とにかく結果を出す
• スクラムは目的ではなく手段
• 個人ではなくチームの成長を
  などの点は共通していたように感じました。
  

  [OpenJam] 「ビジネスモデルYOU」ワークショップ

  
  

  @take3000

  
  次は、オープンスペースでのOpenJam @take3000 さんによるビジネスモデルYOUのワークショップでした。

仮面ライダーネタなどを盛り込みつつ楽しいプレゼンテーションと、為になるワークのセットでした。

実際自分自身のパーソナルキャンパスを書いてみましたが、
自分自身のスキルや、周りとの関係を見直すいいツールだと感じられました。

時間が限られていたのでそこからの発展、これから自分としてどうしていきたいかまではかき上げることができなかったのが残念でした。

テンプレートはこちらにユーザー登録をするとダウンロードできるようになります。

スクラムの実践現場でのよいやり方を形式知にしよう！～ パターンマイニングワークショップ

鷲崎弘宜氏

スライドにある手順に従って5人程度のグループで実際にパターンをかき上げてみようというワークショップでした。

グループメンバーの経験に基づいてパターンを書いてみると、適切に抽象化してみると実はみんな同じようなことを経験していたことがわかりました。
その時、適切なパターン出会っていたらどうなっていたのか。など興味はつきませんでした。

「暗黙知を形式知に」よく聞くキーワードですが、それに対するアプローチとしてパターン化は有用だと感じました。

最後に

この素晴らしいイベントを計画＆運営してくださったスタッフの皆様に感謝いたします。
おかげで非常に濃密な時間を過ごすことが出来ました。

リポジトリを同期する

同期用のリポジトリを作成

svnadmin create sync

同期用のリポジトリを初期化

svnsync init file:///dest/sync https://dest.example.com/svn/

もし

svnsync: E165006: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook

とか言われたら /dest/sync/hooks/pre-revprop-change
ファイルを空でもいいので作成する windows
の場合は/dest/sync/hooks/pre-revprop-change.bat

同期を実行

svnsync sync file:///dest/sync

全リビジョンをコピーするので時間がかかります。

元ネタ：
http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_svnsync.html

万が一同期中にセッションが切れて

svnsync: E000022: Couldn't get lock on destination repos after 10 attempts

とか出るようになったら。

svn propdel --revprop -r0 svn:sync-lock file:///dest/sync

を実行すると再度syncできるようになる。

元ネタ：
http://stackoverflow.com/questions/4077601/svnsync-couldnt-get-lock-on-destination-repos

前回のコラムより、順調にフクロモモンガ温度記録システムを運用しています。

日々の温度の変化がわかるようになり、もし寒すぎたり暑すぎたりした場合は
メールで通知が送られてくるので、非常に安心なフクロモモンガライフを送ることができています。

人間因果なもので、温度関連の心配がなくなると、次なる欲望が頭をもたげて来ました。

フクロモモンガは夜行性です

ご存知の方もいらっしゃるかもしれませんが、フクロモモンガは夜行性です。

日中のほとんどは巣であるポーチに入って寝ています。
全く活動しないわけではなく、ケージに覆いをかけてちょっと暗くしておいてあげると多少は活動します、
がなんといっても彼（彼女）の活動のメインは私達が就寝してからの深夜帯です。

• 夜間どんなふうに遊んでいるんだろうか


• 餌の食べ具合はどうだろうか。

考え出したらきりがありません。

ということで暗視カメラを付けました

気になるなら見える化してしまえばいい。ということで暗視カメラについて調べてみました。
そうするとどうでしょう、意外と安く売っていることがわかりました。

それならと、早速カメラ赤外線WEBカメラ(130万画素) DC-NCR13UをAmazonで購入しました。
このカメラと、Linux上で動作する動体検知機能付きカメラ制御プログラムのmotion 組み合わせて撮影したのが冒頭の画像です。

バッチリ餌を食べる姿が撮影されていて大満足です。
これで更に私のフクロモモンガライフが充実することうけあいです！

みなさんも、カメラを付けて充実したモモンガライフを送りませんか？

アジャイルサムライ読書会　横浜道場　特別編 First に参加しました

アジャイルサムライ読書会　横浜道場　特別編 First に参加してきました。

募集ページ

今回は、いつもと趣向を変えてワークショップ＆LT大会でした。

詳しい内容は @shinyaa31
さんのレポート
を参照していただくとして。

参加した感想を。

ワークショップ 「THE SPECIFICATION EXERCISE」 @tsuyok さん

１テーブル４人から５人で１つのプロジェクトとし、開発チームと設計チームに分かれて、設計担当が別室でみた図形を文章だけの設計書で開発チームに伝えて、開発チームが設計書の記述に沿ってその図形を書くというものでした。

私は開発チーム役を担当したのですが、文章だけでコミュニケーションを行うことの難しさを味わうことができた楽しいワークショップでした。

第１セット

反省点

• １２分の制限時間のうちの９分間を設計の作成に費やしてしまった。
  • 実装フェイズからプロジェクトに参画したものの上流の遅れでやることなくてぼーっとしているしかない。というどこかで聞いたことのあるようなどこか懐かしい状況になりました。
• 結果実装の時間が足りなくて完成しなかった
  • プロジェクトが燃え上がりました。
• 設計担当が、わかりやすいように作戦をたててくれていたものの、そもそも作戦が文字だけではうまく伝わらなかった。
  • ex.
    A4の紙を９つに区切って、意思疎通のしやすさを狙ったものの指示書には９個に区切るとしか書いていなかったため、格子状にすればいいのか縦に９個にすればいいのかなど迷ってしまった。

良かったこと

• 時間がなかった割にはそこそこなものがかけた
• ９マスに区切ったりという設計側の取り組みは理解の助けるのに効果があった

第２セット

第１セットの反省を生かして、

• 設計チームはこまめに伝える。
• 共通認識を作るため、最初に前提となる考えを伝える

などを気にしながらワークを行いました。

反省点

• 設計チームが常に走りまわっていたため、開発チームからのフィードバックが伝わりにくかった。

良かった店

• 設計チームが設計を少しづつ何回も伝えるようにした
  • 開発チームのアイドルタイムが少なくなり、作業も早くなった。
• 前提となる考えを始めに伝えた
  • 第１セットよりは曖昧さがなくなった

意外な気づき

• 図形の形を伝えるのに「レッドリボン軍のマークのような」という表現があった
  • 砂時計を９０度傾けて・・・といった感じの表現よりはるかにわかりやすく、これはデザインパターンかっ！と、勝手にテンションが上がってしまいました。

LT大会

「もしも日露戦争で満州軍総参謀長 児玉源太郎閣下がインセプションデッキを作ったら」@dproject21 さん

• 戦争とは国家プロジェクトだだったらインセプションデッキがあってもいいんじゃないかという考えのもとにインセプションデッキ作ってみましたとのこと。
• 非常に良くできたインセプションデッキでした。

「周囲に賛同者がいなくてもアジャイルな自分を感じられる！ -ポモドーロテクニック- （仮）」 @hyokota さん

• 最近良く耳にする食べ物じゃない方のポモドーロテクニックについてのお話でした。
• メリット
  • 見える化できる
  • 集中できる
  • 見積もりできるようになる
• でも今までのムダが浮き彫りになってキツイよ！

「レガシーコード改善はじめました」 @setoazusa さん

• ちょっとスタッフ業で中座していたら終わってしまっていました。。残念。。。

「アジャイルな指揮者と音楽づくり」 @terahide27 さん

• デジタル音楽＝ｍｉｄｉ の方はおっさん！！！
• 理想的な指揮者は何もしない
  • カッコイイ！

「ジョジョで分かる頭じゃなく精神で理解するアジャイル」 @joker1007 さん

• JOJO=アジャイル！

ビアバッシュ

ビアバッシュで話していた内容で覚えていることなど。。

• JOJOは３部〜５部を押さえればまずは大丈夫。

  • 特に３部と５部は重要！

• Railsって簡単って言うけどインストールで勉強会一回終わってしまった。

  • それGrailsならアーカイブ一個落として展開すればで済むよ！

いつもと趣向が違う特別編でしたが、非常に楽しく有意義なワークショップ＆LTでした。
講師＆LT発表者の皆様、参加者の皆様。ありがとうございました。

アジャイルジャパン2012で大盛況だったとの噂の「アジャイルな開発からアジャイルな組織へ」の再演に参加しました。

告知ページ

公演の内容は Togetter 及び
Slideshare

Agileな開発からAgileな組織へ #aj21
#b2

View more presentations from Ryuzee
YOSHIBA

などを確認していただければ雰囲気を感じていただけるかと思います。

公演内容は、時に痛快で、時に気づきがあり、時にいいパンチをもらうような楽しい公演でした。

印象に残っているところを

変化に対応しないといけない

• ビジネスを取り巻く環境が変わっている
  • 不安定な場所をものすごいスピード競争している
  • 意思決定を早くする必要がある。
  • 考えてても偉くない
  • やったほうが偉い
• ビジネスモデルの賞味期限が短くなっている

改善するかしないかが肝心である。

• Scrumなどの方法論は無駄をなくそうという話！

価値を高めないものはすべてムダ！

• 求められる以上の品質もムダ

• システムの64%は使われていないという調査結果がある

  • 顧客でさえも本当に必要なものがわからない
  • 頻繁に軌道修正をしなければいけない

早く失敗することも重要

アジャイルはリスクマネジメント

• 頻繁にリリースして、確認することによってリスクを最小化する。
• WFは最後にしか確認できないのが厳しい。

短いスパンで改善していく

• ふりかえりを行って、継続的に改善していく
• ふりかえりしたあとにちゃんとTRYが実行されるようにする

チームはばらしてしまうとせっかくの改善が無駄になる

• 無理をしてでもチームを維持するべき

態度重要

• アジャイルはハラをくくってやるかどうかだ！

感想

今の自分のハラのくくり方はまだまだ甘いなと思いました。
次回はハラをくくってアジャイルをやっている人に挙手できるように精進します。

勧められたので、この本を買ってみました。
トヨタ生産方式―脱規模の経営をめざして

有意義な公演をしてくださった @ryuzee
さん、参加してくださった皆様ありがとうございました。

4/21 にOracle青山センターで開催された
TOCfEブートキャンプに参加してきました。

こくちーずの募集ページ

TOCfEってどういうものなの？という話は
教育のためのTOC日本支部コミュニティのページを見ていただくと詳しく書いて有ります。

参加の動機

去年の夏くらいからTOCという言葉をよく耳にするようになっていて、ちょっと気になっていたところに、スタッフの一人にこんなイベントがあるよという話を聞き、どんなものかというのを体験したくて参加しました。

参加前

事前準備として参考書籍として「ザ・ゴール」「ザ・ゴール２」の２冊を購入して読みました。

閉鎖寸前の工場がTOCの手法を取り入れて劇的に改善していくというストーリ仕立ての本はとても面白く、何年ぶりかに本を読んでいて降りる駅を通り過ぎるどころか終点まで気づかないという経験をしてしまいました。

ただ時間が足りなく「ザ・ゴール２」を４分の１読んだくらいでブートキャンプ当日を迎えてしまいました。

当日の題材であるクラウドを含むTOCfEのツールは「ザ・ゴール２」で紹介されていたため、読みきってから参加したほうが良かったなと思いましたがあとの祭りでした。

当日のざっくりとした流れ

一日かけて、TOCfEのツールであるクラウドのワークショップを行いました。

• 午前から午後１

午前中から午後の途中までは参加者個々が自分の抱えている問題についてクラウドを作成しました。

はじめにスタッフの方からどうやってクラウドを作成していくかという説明があり、その後実際に自分でつくってみるという過程をステップを細かく分けて行っていくという進め方でした。

例えば午後１終了時点でのクラウドはこんな感じ。（あくまで例で実際のものではないです。）

• 午後２

その後、３人でグループを作り、その中の一人のクラウドについて解決に向けて３人で協力して考えるという内容でした。

私の入ったグループ（@riskrisk
さん、主婦！の女性、私）は自分も共感できる内容だったので、ぜひとも解決策を導き出すところまで行きたかったのですが、結局時間が足りずに終わってしまったのが残念でした。

• 懇親会

その後そのままの会場でビアバッシュ形式での懇親会になりました。

やはり移動がないのは楽で非常にありがたかったです。
準備してくださったスタッフの方や、会場を提供してくださるOracle社の対応に非常に感謝しなければいけないなと思いました。

懇親会になってもTOCfEにまつわるアカデミックなトークができたり、

@yumzou
さんがクラウドを書いて、クラウドが出来上がって行く様をライブ観戦できたり。

誰かがクラウドを考えて書いていくさまを見るのは非常に興味深く勉強になりました。

某氏のエグい題材に対してのクラウド（酔と題材の重さ故か未完成）が始まったりと、非常にエキサイティングな懇親会でした。

感想

参加する前は、

• 募集ページの「家庭のことから仕事のことまで何でも解決できますよ！」との謳い文句（一部脚色があります。）に半信半疑で、

• 一日かけて「クラウド」というツールのワークショップで時間が持つんだろうか

などとちょっと斜に構えていた所があったのですが、この両方共見事にいい意味で裏切られました。

家庭の問題から、仕事の問題まで実に多岐に渡るクラウドが作成されてかつ活発な議論がかわされていましたし、私のチームでは結局時間が足りなくなるハメになり、TOCfEの深さ、スタッフの深慮に、脱毛する思いでした。

今回はクラウドというツールを使って、今までなんとなく考えて結論を出していた（と思っていた）問題について再度ちゃんと考えることによって、たくさんの新しい気づきを得ることができました。

参加者もどこかで見たことがある方も多かったですが、主婦の方など普段の勉強会ではまずお会いしない方ともお話ができて非常に貴重な体験ができました。

スタッフの方々、会場を提供してくださったOracle社さん
ありがとうございました。

TOCfEって本当に素晴らしいですね！ #ステマ

どんなシチュエーションで使うのか

• バッチ処理でログをDBに書き込んでいるケースなどでログは残したいけど、失敗した場合にトランザクションはロールバックしたいとか。

どうすればできるのか

• 別トランザクションにしたいメソッドまたはクラスに
  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
  アノテーションをつければOK

注意点

私の環境では、メソッドにこのアノテーションをつけた場合に
メソッドがpublicでないと トランザクション境界にならなかった！

なんでつくったのか

昨年の7月にフクロモモンガを飼い始めました。

こんな感じです。
３X歳のいい年した男ですが、可愛いと言わざるを得ません。

最近では結構人気があるようで、芸能人でも飼っている方が居るとか。

近所のペットショップでも、かなり見かける小動物です。

よく言われる魅力は、

• 慣れやすい
  ベタなれという状態までなれると名前を呼ぶと飛んできたりするそうです。
  うまくすればナウシカ気分になれるとか。




• 比較的長寿
  10年とか15年とか聞くこともありますが、普通に5年から7年くらいは一緒に暮らせるようです。




• 滑空します。
  ムササビとか、忍者ハットリくんのイメージです。

他にも色々魅力はありますので、もし興味の湧いた方はインターネットで検索していただけるといろんなモモンガが見られます。
youtubeに動画もあるようですので、自宅に迎える前に魅力を堪能してみてください。

そんな魅力たっぷりのフクロモモンガですが、飼い始めて、フクロモモンガのことを調べていくと、

どうやら温度管理が大切だということがわかりました。

インターネットや、本の情報を見ると20度を下回ると低体温状態になり、30度をこえると熱射病の危険があるそうです。

夏の間はエアコンをかけっぱなしにしていたのである程度安心でしたが、

冬は光熱費の関係などもあって、室内全体を温めるのではなく、

モモンガのケージの周りだけ小型のオイルヒーターと、パネルヒーターで温めることにしました。

そうなると、室内の温度とモモンガの生活空間の温度が一致しなくなり、

実際のところ適温にできているのかという疑問が湧いてきました。

温度計のような、その時その時の状態だけでなく、一日を通しての温度変化。

しかもフクロモモンガの生活している環境により近いところでの計測がしたいという欲求が湧いてきました。

そんなことを考えていた矢先に、社内でワインセラーの温度管理システムを趣味で構築した話を聞いたことを思い出しました。

それをそのままいただいてしまって、ちょっと手を加えればフクロモモンガに使えるんじゃないかと思い、

システムの作成者をうまく口車にのせて説得して。

セラー温度管理システムにプラスアルファしてこのシステムが完成しました。

何ができるのか

• 10分置きに温度を測定して、記録し続けます。


• 記録した温度の変化をブラウザから折れ線グラフで確認できます。
  
  
• 予め設定した温度の上限と、下限をこえた場合、メールでお知らせします。

なにでできているのか

今回制作したモモンガ温度管理システムは
アメリカ Globalscale Technologies社の GuruPlug Server Standard という小型LinuxBoxの上で稼動しています。
温度計は TEMPerUSB というUSB温度計を使用しました。

GuruPlug Serverは350ml缶を横にして四角くしたくらいのサイズの中にサーバーとして使用するに必要十分な機能が詰まったLinuxBoxです。

OSはDebianがプリインストールされ、GigabitEthernetや、２PortのUSBなど画面を出力できない以外はほぼすべての機能を備えたマシンです。

使ってみてみてどうだったのか

しばらく運用してみると、我が家のモモンガのケージの気温は多少の上下はあるものの、概ね適温を推移しているということがわかりました。

大丈夫だろうと思っていたものの、実際数値になって見えることによりより安心出来ました。

また、汎用的なLinuxBoxを使ってシステムを作っているので、機能を拡張する自由度が高いのが魅力です。
今後も、このシステムを改良して楽しいモモンガライフを送ろうと思います。

せっかく作ったシステムですので、興味のある方がもしいらっしゃれば使っていただけるようにしたいと思っています。

1 ) 実行中のSQLの一覧を取得する
　　mysql> show full processlist;

　　または

　　mysql> show processlist;

　　fullをつけると実行中のSQLが省略されずに表示されるようだ。

　　ここで表示されたIDを控えておく

​2) おもむろに停止

　mysql> kill ${１）で確認したID}

2012/1/27 JR田町駅から徒歩10分かからないくらいのところにある
ベルサール三田 で開催されたCouchConf Tokyo に参加してきました。

奇しくも同日に開催されていた ビールが2トンとか、レッドブルのおねいさんがいるとかいう話だった

#CROSS2012 とはベルサールつながりでした
＃CROSS2012の内容は @shinyaa31さんのブログにまとめられていますので詳しくはそちらをご覧ください。http://d.hatena.ne.jp/absj31/20120127/1327732404

ｰｰ閑話休題－－

ということで一日Couchbase漬けになってきました。

当日のタイムテーブルはこちらのとおり http://www.couchbase.com/couchconf-tokyo
また、当日の雰囲気を感じられるかもなまとめもついでに作成しました。
http://togetter.com/li/248729

Welcome and Opening Session
まずはCouchbase社の Vice President @stevenmih さんの挨拶

副社長さんが日本語で挨拶中 #CouchConf

— わたなべ @残念な執筆者 (@jp_watanabe) 2012, 1月 27

そして

オープニングセッション！ Bob Wiederhold, President and Chief Executive Officer #CouchConf

— Atsushi SHIGETA (@shige10) 2012, 1月 27

です。
Couchbaseは　Simple Fast Elastic
Simple:
5分でセットアップできる

Fast:
Memcached由来のハイパフォーマンス

Elastic:
スケーラビリティに優れている
… and Mobile:
モバイルとクラウドの同期を簡単にできる仕組みがある！
[f:id:yenjoji:20120129013134j:image:small]

Tour of Couchbase Server 2.0 and Demo
v2.0の新機能とリリーススケジュールについて。
2.0は今はちょっとパフォーマンスに問題があってまだリリースできないらしい、2月末にベータ4月以降にリリースの予定らしい。

ここでも、運用が簡単だってことと、パフォーマンスを維持しつつ安定性とデータの保全性を大事にしているよという話が印象に残った。
使いやすそうな管理WebUIがあって、しかもすべてREST APIでアクセスできるから自動化も簡単という話らしい。すごい。
[f:id:yenjoji:20120129013135j:image:small]
[f:id:yenjoji:20120129013136j:image:small]
[f:id:yenjoji:20120129013137j:image:small]
[f:id:yenjoji:20120129013138j:image:small]

Developing with Couchbase Part I: Getting Started
Couchbaseを利用した開発について基本的な機能を一巡り。

開発言語は何でもいいらしい、ただ、Couchbaseで開発ライブラリを用意してある言語Javaとかはそっちを使ったほうがいいらしい。
それ以外の言語は基本memcachedなんで、そっちのライブラリで使えるということらしい。
[f:id:yenjoji:20120129013139j:image:small]
[f:id:yenjoji:20120129013140j:image:small]
[f:id:yenjoji:20120129013141j:image:small]

Developing with Couchbase Part II: Advanced Document Design
Couchbaseはスキーマレスなので、スキーマの定義とか煩わしいことはないけど、
それでもいろいろなテクニックがあるよというはなし。
もう少しCouchbaseを使い込んでいくと色々腑に落ちるんだろうなという感じでした。
[f:id:yenjoji:20120129013142j:image:small]

Box Lunch and Lightning Talks
Docomo Innovations @yas さんによる Couchbase・mongodb・cassandraの比較についてと、
couchdb.jp ＠ijokarumawak によるLTセッション

Couchbase・mongodb・cassandraについては、各々得手不得手があるからそれに合わせて使えばいいんだなと理解しました。
[f:id:yenjoji:20120129013143j:image:small]
[f:id:yenjoji:20120129013144j:image:small]

Developing with Couchbase Part III: Advanced Application Development
[f:id:yenjoji:20120129013145j:image:small]
[f:id:yenjoji:20120129013146j:image:small]

Couchbase in Production 24x7
Couchbaseをノンストップで運用し続けるためにいろいろな仕組みがあるというお話。
クラスタの追加削除がいつでもできて、データの再配置もオンラインでできる、
しかもオフピークに狙って実施できるようにタイミングは自分で決められるとか。

パフォーマンスボトルネックの判別や、サーバー増強計画を立てやすくするためにたくさんの情報を自動的に収集しているとか。
バージョンアップも稼働中にできてしまうとか、ここまでやるかというくらい運用がやりやすくなるような仕組みがいっぱいありました。
OpeningSessionで言っていたSimpleというのは使う側が行う作業をなるべくSimpleにしようという考えなのではないかと思いました。
[f:id:yenjoji:20120129013147j:image:small]
[f:id:yenjoji:20120129013148j:image:small]
[f:id:yenjoji:20120129013149j:image:small]
[f:id:yenjoji:20120129013150j:image:small]
[f:id:yenjoji:20120129013151j:image:small]

Mobile Application Development and CouchSync
YOUR DATA ANYWHERE
ということでMobileSyncpointの概念の説明、チャネルという概念とその利用方法とか。
Use Caseについていっぱい。
アイディア次第ではいろいろな可能性がありそう。iCloudみたいなことがオレオレでできると考えただけでもご飯3杯は行けるか！？
[f:id:yenjoji:20120129013152j:image:small]
[f:id:yenjoji:20120129013153j:image:small]

Mobile Application Development with Couchbase
Docomo Innovations の @yas さんによる MobileSyncpointを使ったAndroidアプリケーションのおはなし。
アプリで写真を取ると自動的にクラウド経由で複数端末で写真をシェアできる。
親子と、遠隔地のおじいちゃんとかが今回のモデルケース。
チャネルをうまく使うと公開する対象とかも絞れそう、うまく作りこめばGoogle＋のサークルみたいなアクセス制御もできそう。
[f:id:yenjoji:20120129013154j:image:small]

Q&A Panel with Couchbase Experts

では Mobile Syncpointとクラウドに関する質問が多かった印象です。
Couchbaseとして特定のクラウドテクノロジー（OpenStackとか）・サービス（dotCloud）とかと関係を強化する予定はあるんでしょうか。
という質問に対しては、現時点では特にクラウドとのれん系については何も行っていないとの回答でした。

個人的にはdotCloudでCouchbase使えるようになると
自分でサーバー用意しなくていいし、0円スタートだしで導入への敷居がグッと下がっていいなぁと思ったりしているのですが。。。

After Party

After Partyでは、誰が言ったか「質問するまでがCouchConf」という掟に則って VPのStevenさんに質問しました。

今日のセッションでもZingaではかなりのノード数が使われているらしいとのことだったのですが、
実際どのくらいの規模のクラスターまでの実績があって、パフォーマンスはどこまでリニアにスケールしていくのかきになったので聞いてみました。

回答としてはZyngaでも200台くらいのクラスターの実績があるし、
理論上は特に問題なくノード数を増やせばリニアにスケールしていくはずだとのことでした。
実際は200台も同じクラスターにすることはないだろうから、気にしなくてもいいんじゃないかなということでした。
（一部うろ覚え。。。）

一日Couchbase漬けになって、ビールもたくさん呑んで、
Couchbaseの中の方ともはなしが出来て、総じて良かったなぁと思いました。
（参加者も思ったより多かった印象でしたし。。。）

途中でCouchbaseの中の方が来年も・・・みたいなことを言っていたので、
次は使っている人のポジションで参加してみたいところです。