2011-02-17
デブサミ速攻レポート Developers Summit 2011(2月17日,18日/東京目黒)1日目 レポートx4まとめ
Developers Summit 2011(デブサミ)に参加中です。今年のキーワードはクラウド、モバイル。
レポートは以下のリンクからどうぞ。
- 【17-E-3】 Hadoop：黄色い象使いへの道 〜「Hadoop徹底入門」より〜 下垣徹 氏
- 【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか
- 【17-C-5】Spring as a Cloud Platform 河村嘉之 氏
- 【17-C-6】SpringのこれからとJava開発者向けの次世代RAD、Spring Roo Stefan Schmidt 氏
クラウドを利用する
クラウドは、提供する側の企業ごとに特徴が違うのでそれらを生かしつつ、差違をSpring Rooなどフレームワークで吸収・抽象化するアプローチが活発でした。また、Hadoopなど大規模分散処理の最新の導入事例などは技術的にも新しく、興味深い分野です。
開発管理、手法
チケット管理システムのパネルセッションは、詳細に比較できる機会がなかったので、とてもおもしろく聞けました。アジャイル、scrumについては、開発プロセスとして新しいトピックではなくなって久しいな、と感じました。提唱されて間もない当時の衝撃に比べると落ち着いてきた、という印象です。
どのように導入するか？どうやればうまく回せるのか、絶対的な解がないため、話も抽象的になりがちです。何より様々なプロジェクト＝自分の現場での試行錯誤が必要ですね。
ブース写真
DevLOVEさん。
アジャイルUXカード
デブサミ 【17-E-3】 Hadoop：黄色い象使いへの道 〜「Hadoop徹底入門」より〜 下垣徹 氏
Developers Summit 2011(2月17日/東京目黒)に行ってきました。
いくつかセッションのメモをとったので備忘録代わりに。
まとめ
HadoopはGoogleのMapReduceの論文をベースに作られた大規模な分散処理フレームワーク。
高いスケーラビリティ、I/O性能を持つがRDBMSと競合するものではない。組み合わせて使うもの。
検索Indexの作成などバッチ処理に向いている。
以下、セッションメモです。
Hadoop：黄色い象使いへの道 〜「Hadoop徹底入門」より
スピーカー：下垣徹さん
もともとはDB屋さん。PostgreSQL使い。
- ミッションクリティカルの分野でPostgreSQLを適用
- オラクルからポストグレースへのマイグレーションの実現
- 最近はOSSデータストア担当：Hadoop使い。Hadoopの導入支援など
- 「Hadoop徹底入門」のとりまとめ
Hadoop徹底入門はオライリー「象本」との棲み分けを目指して執筆開始
12月末日Amazonにてひっそりと発売告知。目次も公開されていない段階でランキング1位に。
こちらが象本。
Hadoop徹底入門：書きたいことはたくさんあったが、尺に収まらず、入らないものがでてきた。
FairScheduler Mahout などなど…次があれば入れてみたい。
本日のアジェンダ
技術背景：Google
Google独自の基盤技術を用いて、大規模データを対象としたサービスを展開。自ら「クラウドコンピューティングを持ってサービスを展開」
Hadoopはオープンソースの大規模分散処理フレームワークで、Googleの基盤ソフトウェアのOSSクローン。
巨大なデータを並列で呼んで、データのローカリティを生かしてデータ処理する
- 高いスケーラビリティ、小さくはじめて大きく活用
- 大きな企業での活用事例が増えてきている
Hadoopクラスタの全体像
Hadoopは集中管理型の分散システム。全体を管理するマスターサーバが1つある。
HDFSとMapReduceフレームワーク
HDFS：低価格のサーバーを大量に使用するのが前提。
データの多重化で可用性を担保する。故障の発生が前提の設計
サーバーが死んでも、ラックが死んでも、大丈夫なようにデータ配置を考えてくれる
MapReduce：分散処理のフレームワーク
Map：ある一行のレコードを変換させるなど、1行分の処理
Reduce：集約処理
Hadoopの特徴
プログラム個別に分散ロジックを用意する必要がない(プログラムごとに分散処理を設計しなくてもよい)
高いスケーラビリティ。I/O性能を柔軟に拡張できる。コモディティサーバーが前提
Hadoopの適応領域
数十Gバイト〜テラバイト、ペタバイトのデータを扱うシステム（数十Gは小さいかな）
バッチ処理的な処理に向いている。オンライン処理的なところは適応できない。
リアルタイム性が求められるところの前処理に使える（検索インデックスを作るなど）
一般的にログ解析、レコメンテーション、検索、データマイニング、機械学習、データ変換の分野。
利用事例
- そのほかにもChinaMobile、リクルートなどその他多数
適用領域の大事なポイント
RDBMSと競合するものではない。組み合わせて使うもの。
徹底入門の読み方
まずは1章から5章・6章まで通して読む。（204ページぐらい/全437ページ）
導入からはじまり、3章、4章は前半が理論、後半が使い方。
5章はプログラミング入門、開発したときのテストMRUnitまで解説
6章はSQL的インターフェイスHive。JavaでMapReduceを書きたくない・かけない場合はこちら。
残りの章は必要に応じて読みたいところを。
たとえば10章は性能向上のための性能チューニング、実践的な内容
7，8，9章は次のステップ。
7章：自動構築、高可用性
8章：可視化。台数が増えてくると、監視するための負荷が馬鹿にならない。
9章：マスターサーバーの信頼性を確保するなど（単一障害点の排除）
11章以降はHadoopと連携する周辺ツールの紹介
黄色い象使いになるためには
SQLがそのまま使えるわけではなくちょっと変更が必要だったりする
HadoopはRDBMSではない。トランザクション、1レコードの更新・削除、B-Treeインデックス、これらは存在しない。
RDBの常識を捨てて、大量のデータ処理に特化していると認識すること。
癖のあるシステムなので適材適所の観点で大量のデータの前処理をHadoop→検索はRDBMSにもっていくなど役割分担が必要
Hadoopへのマイグレーションってどう？
「何かの壁をぶち破るために」
何かとは処理時間であったり、大量のデータ(テラバイト)かもしれない。
マイグレーション前と全く同じ品質・機能・SLAを求められるとつらい
機能差違がつきもの。割り切って、メリットを享受したほうが幸せ。既存の処理は1行引っ張ってきて、どうこうする、というRDBMS前提の処理が書かれていることが多い。
そのままHadoopにもってくるのではなく、処理をまとめる(ジョブを減らす)と性能向上が顕著
ジョブ、クエリを減らす。
どのバージョンがいい？
コミュニティから提供されているのは0.21系。周辺プロダクトは0.21系を未サポート。安定性重視の場合はCDH(クラウディア社)
- 新しい機能使いたいひとは0.21系
- サポートが欲しい場合は周辺ディストリビュータがおすすめ。
デブサミ 【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか
鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏 / 大澤俊介 氏
パネルセッションです。チケット管理システムに関する質問に回答する形で進行していました。
まとめ
チケット管理システムはツールである。必要に応じて最適なものを選ぶことが大切。
チケット管理システムをすべて比較できるひとは少ない。色々調べて、聞いて、使ってみると良い。
開発の規模が大きくなると導入効果も上がる。
- 前提として導入するだけじゃなくて、ちゃんとみんなで使うこと、日々改善すること。
- コミュニケーションにかかるコストを節約できる。
- 頻繁な変更への対応、メンバ間、顧客との課題共有がしやすい。
資料が公開されています。あわせてどうぞ。
スピーカー紹介
Atlassian(アトラシアン) 大澤さん @Sean_SF
- 製品をアジャイル開発している会社。JIRA使用歴2年
- チケット管理システムを使うことが普通だった
チケット管理システムはたくさんあるが、何が違うのか？
詳しいひとに聞いてみよう。 #itsjp
鈴木雄介：グロースエクスパートナーズ株式会社
ソフトウェアアーキテクトが知るべき97のことの著者
- 作者: 鈴木雄介,Richard Monson-Haefel,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/10/05
- メディア: 単行本（ソフトカバー）
- 購入: 14人 クリック: 329回
- この商品を含むブログ (76件) を見る
小川明彦：業務系Webシステム開発に従事
- 作者: 小川明彦,阪井誠
- 出版社/メーカー: 翔泳社
- 発売日: 2010/10/13
- メディア: 大型本
- 購入: 15人 クリック: 285回
- この商品を含むブログ (49件) を見る
チケット駆動開発の体験談をまとめて出版。
吉羽龍太郎：スクラムマスター/アジャイルコーチ @Ryuzee
なぜチケット管理システムを使うのか
プロジェクト全体状況の把握とプライオリティ付け
10個のプロジェクトが同時に進行、1つずつの管理が難しくなった。Excelどこ？なにがあるの？
メールでみるとプライオリティ付けができない。2週間前のメールとかが最近のメールで上書きされてしまう。
コストの削減
人数が増えるとコミュニケーションコストが大きくなる。チケットを介してやりとりすることで、見えないコストが減る。
(＝無駄なところにとられるコスト。エクセルのメンテナンスや各資料の不整合)
頻繁な変更への対応
開発途中で要件がかわるのがほとんど。だれがなにしているのかが「ガントチャートでしか見えない」状態での仕様変更は、タスク依存関係がちゃんと見えなくなる。
突発的な仕様変更などで計画立て直しでリーダーさんの負荷が高い
情報の共有、蓄積
一人で複数の案件を担当していたら、メンバーが替わったときに引き継げない。メールの内容をみつけることができず、ナレッジがたまらない。
DTSやITSがあれば、すぐ見つけられる。スキルの追跡が可能＝ナレッジ蓄積しやすい。
なぜそのツールを使っているのか？
Trac
- 導入が簡単。インストーラが用意されており、10分とかからず、環境構築が可能
- プラグインによる拡張が容易であること数百のプラグイン、マクロが提供されている
- プロジェクトの特性にあわせてカスタマイズ可能
- レポートを自由に定義できる(エクセルを作ってくれる。報告書など簡単)
- 日本におけるコミュニティ活動や情報量が豊富(Shibuya.trac)
RedMine
- チケット集計機能、進捗管理機能が優れている、ガントチャートやロードマップ。
- Agile開発の特徴を理解できる。イテレーション、リリース計画。
- 構成管理パターンが理解できる。メインラインモデルは複数プロジェクト対応、タスク管理できる。
- トピックブランチはチケット単位でブランチできる。
→ いろんなViewをつかってチケット属性と進捗の観点でひも付けがうまい。バーンダウンチャート、かんばん、レポート、など自動で作り出せる。
ツールをどうやってつかうか？
プロジェクトの大きさ、内容で使い分けができるのが良い。Tracは柔軟性が高い。
JIRA(じら）
コミュニケーション
アジャイルはF2Fとよく言う。隣にいるのになんでチケットを切る必要があるのか、共有して残したいものを確認しよう。
使い始めると楽しくなってきてチケットをやたら切るひとがいる。粒度を合わせないと。
見積もりと一緒でチケットの粒度が難しい。アジャイルはall or nothingの世界
チケット管理システムに商用を使うメリット
リリースタイミングが明確、サポートがついてくる。証跡を残すなどワークフロー設定ができると可能。
ドックフーディング：アトラシアン社がJIRAを使っている。
利用について
オープンソースプロジェクトの場合はJIRAは無償で使える。
ボーダフォンさんのチケット管理システムの事例：JIRAにチケットを切ると印刷されてでてくる、ホワイトボードにRFIDをつかってはる
チケット管理システムの導入効果
JIRA
- コミュニケーション精度が向上。抜け漏れがなくなる。
- 起票からデプロイまでの流れが明確
- 負荷分散の目安につかえる。
- 顧客とも円滑に
- 問い合わせや依頼の抜け漏れがなくなる
- ユーザ同士の会話が見えてくる
- 定例会はExcel出力して提出できる
- 課題(できれば嬉しいな)
Redmine
チケット駆動開発はアジャイルじゃないと使えない、わけではない。
ウォーターフォール型でもバグを改修するタイミングではとても有効。
Trac
- チケット管理全般。導入しただけでは効果は上がらない。
- うまく使うことでアジリティや顧客満足度が向上する
- チームで使い方や運用方法を決める必要がある。
ツールの導入で効果を出すために
- プロジェクトのはじめから使う。
- プロジェクト成功のための場につかう。全員がそこをみることが大事。
- 顧客に公開もする。とてもよい。
定期的な棚卸しをする。ゴミ箱にしない。放置されたチケット＝プロジェクトの健康状態
自分たちで使い方を継続的に改善する★
最後に「チケット管理システム」について
もっと広げていきたい。エクセルを使うこと（ツールにこだわりすぎる）がボトルネック、変えていきましょう。
プロジェクトに適したツールを選ぶこと。ツールに限らず、みんなで管理していくことが大事。
議論のつづきはハッシュタグ #itsjp で。
デブサミ 【17-C-5】Spring as a Cloud Platform 河村嘉之 氏
日本Springユーザー会 河村 嘉之
まとめ
Cloud上でSpringのプログラミングモデルでのアプリケーション開発が可能
そのまま動くことよりも、クラウドが提供する機能に注目すべき
（クラウドの特徴に合わせて選択）
Springの源流
Expert One-on-One J2EE Development without EJB
- 作者: Rod Johnson,Juergen Hoeller
- 出版社/メーカー: Wrox
- 発売日: 2004/07/02
- メディア: ペーパーバック
- クリック: 5回
- この商品を含むブログ (24件) を見る
J2EE Development without EJB, Rod Johnson / 2004
↑時代背景としてEJBはあまり流行らなかった。その反動でSpringがでてきた。
Spring Framework
世界で一番有名なEnterprise Javaのフレームワークの一つ
その後のJavaはSunがなくなってOracleが買ってJavaが終わったのか？
プラットフォームとしてのJava
言語としてのJava → ある程度落ち着いて、新しいものが出てくることはあまりなくなった。
プラットフォームとしてのJava VM → まだまだ発展途上。Java VM上で動く言語がたくさん出てきた。
Springが終わったのか？
一年前はある程度Yes、Spring3.0にうきうきしなくなった。
JavaでのWebアプリケーションも枯れてきた。使って当たり前、新しいものが始まる場所ではない印象だった。
今は状況が変わった。Spring Sourceを中心に、おもしろくなってきた。
現在のSpring
Springがではじめて2004年から7年の時間が経過。現在のSpringSourceが目指すところ
3つの軸で進化している。
Google App Engine
JavaとPythonが動く。Springのアプリケーションも動かせる。
VMForce
(参考)http://www.publickey1.jp/blog/10/javavmforcesalesforcevmware.html
まとめ
Cloud上でSpringのプログラミングモデルでのアプリケーション開発が可能
そのまま動くことよりも、クラウドが提供する機能に注目すべき
（クラウドの特徴に合わせて選択）
デブサミ 【17-C-6】SpringのこれからとJava開発者向けの次世代RAD、Spring Roo Stefan Schmidt 氏
Stefan Schmidt氏：VMWareのSpringSourceチーム
講演内容はSpring Rooのデモとコンセプト、Springの今後の計画について。
デモンストレーション
Spring Rooでプロジェクトを作成するデモンストレーションでした。非常に軽快にデータベースをつくり、ブラウザから
データ編集をしていました。20分の短期間で、モデル定義からコード生成、テストまで。生産性の高さが伝わってきました。
以下、デモとSpringの周辺製品の情報です
ディレクトリ作成、Spring Rooを使うと画面が切り替わる
hintと入力すればヘルプ、機能が紹介される。かなり簡単にシステム構築できる。
プロジェクトを作成、トップレベルパッケージを設定
Rooはプロジェクト構造を作成、いくつかのフォルダの中はコンフィグファイルが格納されている
つねにhintと入力することでコンテキストにあったヒントが出てくる。
コンフィグ設定
EclipseTool > Datebaseと選ぶだけで新しいデータベースの設定が完了する
プロジェクトの要素を作成する
新しいドメイン Speaker を作成。自動的にSpeaker.javaやテストケースが生成される
Speakerはフィールド 名前/企業を持つ
新しいドメイン Conferenceはフィールド 日付を持つ。
ConferenceとSpeakerの関係を関係づけると単純ではあるが、ドメインモデルができる。
ここまでやったことが機能するか、確認するためのテストを実行（テストケースの自動生成？）
Web画面の生成
Rooに対してはWebサブシステムを指定するだけ。Eclipceで確認するとコードは自動生成されている。（Get/Setなど）
Rooが何をしているのか？はコードをみれば確認することができる。ただし確認はできるが、Roo側で保守、変更されるコード。
直接編集はできない。そのかわり、カスタマイズするための機能もある。
カスタマイズのためにJavaに変換した場合、Rooはメンテしない(できない)
SpringMVC以外に、Google WebToolKitが使える。
ServerBaseのJavaもサポートする予定。
Web画面の確認（MVCフロントエンド）
WebブラウザからSpeaker：2名分を追加、Conference：今日の日付で追加
つづけて参加するスピーカーを選ぶことで簡単に登録、ひも付けできる。
オブジェクトの確認などもListView,ページネーションもフレームワークでサポートされている。
Rooは9カ国語をサポート。GoogleWebToolKitのフロントエンドもあり、MVCフロントエンドと同様の機能がある
デモの補足
ほんの一部しか紹介できなかったが、ほかにもDatabaseリバースエンジニアリング機能等が追加されている。
これは既存のデータベースをアプリケーションに取り込むための移行ツール。
コミュニティも活発。SpringSourceの外でも多くの活動がある。活動の一環として日本語の翻訳も進んでいる。
Spring Rooフレームワークの今後
現在のRooフレームワークはVersion3。Spring Expression Languages（コード作成補助）、新しいフォーマットのサポート、非同期処理を実現してきた。次のバージョンは3.1。
特徴は
- コミュニティからのリクエストが多いものとして環境プロファイル。
- 開発、テスト、ステージングなどで異なるプロファイルが指定可能
- キャッシュ機能、抽象化機能、conversation管理（デフォルトではStateless、クラウド環境に向いている）
→ V3.1ha近日中にDeveloper Releaseされる
次は3.2
今年の末を予定。Java7のサポートが目玉。JVC4.1、Fork/Joinモデルもサポート。並列型マルチコアプログラミングで活用できる。
Springフレームワーク以外のもの
- Spring Data：非SQL型のデータベースへのアクセスを提供
- Spring GemFire：データ管理。分散型キャッシュをサポート
- RabbitMQ：SpringSourceはRabbitMQを買収、MQとのコネクタとしてSpringAMQを用意
- facebookyaLinkedInなどソーシャルネットワークと接続できるように検討している
- Spring Moblie
- Spring Android
- SpringPaymentService：支払い管理
- VMForce:Springアプリケーションをエンタープライズへ適用、Amazon,GAE等クラウドでの実行環境を提供
特に注目して欲しい機能
Spring Roo
とても簡単にアプリケーションを作れる。アプリケーション開発時のみRooを使用。
本番時はRooに依存しているものはない。返還後のコードがあればOK。Rooの開発はオーストラリア、シドニーで行われている。日本との時差もすくなく積極的に取り組んでいる。
しょーもない話で恐縮ですが、僕の名前 s/竜/龍 ですｗ
セッション、とても良かったです！
Shibuya.tracにもぜひお越しくださいませ！