デブサミ関西に参加してきました

Developers Summit 2012 Kansaiに遠征してきました。
せっかくの遠征なので、前日から有給を取って観光も兼ねて。

今回の参加のきっかけは、大変お世話になった(今もなっている) @yohhatu さんが自分戦略を話すということで参加を決めました。
もちろん、セッションも魅力的なものが多く、選ぶのに悩みました。（結局、自分が選んだなーって感じのセッションにまとまりましたがｗ）

f:id:tenten0213:20120913112921j:plain

参加セッション

セッション資料は、@devsumiのツイートから探すか、facebookから探してみてください。


  • Togetter

「デブサミ関西」のまとめ - Togetter

f:id:tenten0213:20120913140104j:plain

デブサミ関西に参加して


デブサミへの参加は、デブサミ2012で初めて参加してから3回目でした。
デブサミ2012への参加が社外の勉強会やイベントへの初めての参加だったので、遂に関西まで来たか…と感慨深いものがあります（笑）

デブサミに参加すると、こんなにも情熱に溢れたエンジニアが大勢いるということに気付かされます。
関西のエンジニアの方々とも多く知り合えましたし、岡山や熊本から来たエンジニアとも知り合えました。(2人共Twitter上では知っていましたが、リアルでは初対面！)

懇親会では、講演された寺田さんや阪田さんとお話しさせて頂いたり…なんかもう、凄く楽しかったです！

自社に引きこもって仕事だけしていた1年前から考えると、信じられないですね。
あんなに狭かった世界がどんどん広がっています。

今まではイベントに参加し、影響を受ける側だったのですが、次はスタッフであったりLTであったり、自分でも発信できるようになりたいですね。

  • デブサミ2012に参加したときのブログ

Developers Summit 2012 初参加しての感想　〜情熱を取り戻せ

f:id:tenten0213:20120913153236j:plain

感謝！


デブサミ関西で講演した講師の皆様、スタッフの皆様、素晴らしいイベントをありがとうございました！
そして、お疲れ様でした！
また機会があれば、関西に遠征に行きたいと思います。（懐事情次第ですが。。。）

@irof さん、泊めて頂きありがとうございました！
本の量に圧倒されました…（あれでもまだまだなんですね。。。）
次回はTDDやりましょう！

@ayato_p さん、お話できて刺激になりました！Emacs、少しづつ覚えます！

以下、参加セッションのまとめなど

f:id:tenten0213:20120913132013j:plain

【S-1】Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法


東京で開催されたDevelopers Summit 2012の及川さんの講演を聞き感動したので、期待でいっぱいでしたが、期待通り素晴らしい内容でした。
結構生々しいというか、Googleでの開発スタイルが垣間見えます。

聴講メモ(まとまってない…)

昔は大規模ソフトウェアといえば、JRの発券システムや、オンライン（金融）、社会インフラのシステムなどであった。
プロジェクトには非常に多くのメンバーが参画し、要因が複雑であった。
そんな時に使われていたのがWFモデル。

WFではぶれないことが大事。
何をもって工程を終了するのかを決める。（Exit Criteria）

スケジュールにシビア。
事前に内容を決めておく必要があり、各チームがなにをやるかのチェックリストみたいなものがある。

大規模なシステム開発では全部をひとつの塊としてやるのは大きすぎる。

そこで、各チームをサブシステム毎やコンポーネントで分ける。
小さいチームに保つ。

Googleでは各チームに権限を委譲する。
情報共有の工夫は必要。

われわれは何を作ろうとしているのか、テーマが必要。
東芝のワープロの話。(これはデブサミ2012の資料にもかいてあった。)

テスト
BugBash,Find it!
バグの減少傾向をモニター
Triage-フェーズ毎に高くなる修正のためのバー
プライオリティを決め、高い方から修正。

  • 助かる見込みの無い人を戦争中に治療してもしかたない。優先度を考え対処する。(例として挙げていた)

リリース
極めて高い品質が求められる。
一旦リリースされ、ユーザーに使われてしまうと修正は難しい。
セキュリティの更新はユーザーの手を煩わせる、ソフトウェア提供会社のコストも高く付く。
こうゆうことが無いようにする必要がある。

そこで、クラウドは？
クラウド側で全て修正が完了する。
最新、最善の安定したソフトを使えるのが特徴。
低い更新コスト。
・品質に対する考え方
　翻訳の話で、失敗が許されないので内部でしっかり確認するコストがかかる。
　クラウドは、すぐ直せる。ただ落ちない必要がある！
　ユーザーの動向をモニターし続ける必要がある。
　リリースの後が勝負！
　予想できないユーザーのトラフィックを考えたり。。。

クラウドでも開発のサイクルは同じ。
WFも使う。

Cloud
ローンチ。イテレーション。
最初から完成度が高いものを時間かけて作るよりも、
小規模のものをローンチし、ユーザーからのFBを取り入れていく。
小さく作り、FBを受け、即座に修正する。
仮説検証を繰り返す。
数週間から数ヶ月のサイクルを繰り返す。

・ベータ
進化しつづけるという意味
ユーザーにバージョンは関係ない。
ユーザーは使いやすければOK
利用者はバージョンを意識することは全くないと思う。
細かい修正が短いスパンで入るのでリニアになっている。

Chrome
Chromiumがオープンソースプロジェクト。
それをGoogleがブランディングした。
ユーザーからのクラッシュ情報を用いたFBや、Adobeなどの利用ができる。

Webkitを使っていることが有名
QT,V8

オープンソースプロジェクトへの依存が大きい
課題でもあり、特徴。

ohloh
オープンソースの統計情報をみることができる。

Challenges
WebkitはAppleやGoogleが主に参画しコードを書いているが、それぞれいろいろな企業、プログラマが目的をもって参画している。
世界中で開発。異なる組織で開発。
・ゴール、同じ目的、方向の設定が重要。

Theme
・シンプル simple
・早い speed
・セキュリティ security
・スタイリッシュ（拡張性） stylish
・同期 sign in

テーマをブレないようにし、開発者に徹底させる。

ブラウザが高機能になってきているから、いろいろな機能をいれたくなるが、
速度に影響が出るのであれば絶対入れない。

UXも設定やプリファレンスはどんどん減ってきている。
そこはユーザーが本来触る必要は無い。

・コミッターの役割定義
定義：プロジェクトの成功に貢献し、プロジェクト成功のためになろうとする市民。

権限：SVNへの書き込みが出来る人。
※グーグルってSubversion使ってるんですねー

コミッターによってSubmitされたコードをレビューする。
OWNERSファイル（Chromium）
リポジトリ中のOWNERSファイルの中にレビュアの名前が記されている。

コミュニケーション
　ML
　IRC
　　東京の開発者がレビューして欲しくても時差がある。
　　チャットが活用されている
　 イシュートラッカーやレビューもWeb上で行なっている。

Scale
ブランチの管理が厳密にはできない。
世界中に開発者がいるから。
徹底的に自動化させる。

・BuildBot
いろいろなバリエーションのプラットフォームで動くようになっている。
自分のコミットした内容がどの状態になっているかわかるようになっている。
テストも実行してくれる。
※Jenkins的な感じ？

・Test/TryServer
PatchをSubmitする人がTestの作成も行う。
・UnitTest
・UITest
・PerformanceTest
・LayoutTest
Valgrindも利用

・TryServerで試せる。

・依存関係は
DEPS
コンポーネントの依存関係を記述。

・Sheriff
Treeの状態を健全に保つ役割。タイムゾーンごとにローテーションで担当する。

・Gardeners
WebKitなどの。常に最新のWebKitがChromeに入るように監視する。

・ブラウザとしてのソフトウェア
自動更新。
Chromeを一度インストールすると、明示的に自動更新をオフにしない限り、常に最新版がインストールされる。

ReleaseCycle
13週毎のリリース
⇒6週毎に変更。


【A-1】Continuous Value Delivery to the NEXT DECADE

聴講メモ

マイクロソフトのプロセス

  • プロダクトバックログ

ビジネス×テクノロジー

  • 便利⇒有効⇒不可欠なものに。

ITじゃなく、BTに
BuisinessTechnorogy

固定な要件、LongBatch⇒完全
便利な時代。
これを今の時代でできるのか？
⇒少なくとも今の案件では出来ていないな…

・変化する要件、SmallBatch、継続
2週間毎に提供するのはタフ

確率したビジネス/完成したIT
短い時間で投資対効果が高い部分。
投資対効果が低い⇒無駄。
長い時間をかけると無駄が増える。

ITプロジェクトの成功率は3割。手戻りは４５割、使わない機能は６５％くらい。

ビジネスと共に成長するIT
スモールバッチでその時その時必要なものを提供する。
これからは提供し続けるモデルが求められるケースが増えると思う。
ずっとクライマックスな状態なので、ちゃんとした方法論、ツールを活用しなければ難しい。
今までの根性論じゃ無理。

今までの戦い方
I'mDone
長い仕掛り、フィードバックの遅れ、マイクロマネジメント
⇒
We'reDone
短い仕掛り、フィードバック・ループ、透明化、ムダ取り、価値の流れ、自己組織化と現場力
チームVS問題

魔法
回帰テストしない、見て見ぬふり、俺の仕事はオワタ
これからは魔法は効かない！

アジャイルコンセンサス
アジャイルプラクティスの実践
エンドユーザーとできる事や優先度をコミットする。
開発したらテスト環境でエンドユーザー触ってもらい、FBを受ける。
良ければリリース

サイクルタイムを極限まで短くする。

エンドユーザーは１年も待ってくれない。
バグの修正なんかは１日、半日で。

CD
我々開発者は開発だけみているので無く、開発の流れを意識しなければならない。

ソフトウェア・エンジニアリング支援

対症療法VS原因療法
SCM,バックログ、テスト、イシュー、バグトラッキング
原因療法で、ミスを繰り返さないようにする。

Point　VS　Flow
Point　to Flow
Flow Solutions
一番使いやすいものから全てにアクセスできるようにする。
CIが苦手だからとかダメ
全体の底上げをしていく

継続的３兄弟
・継続的インテグレーション
・継続的デリバリー
・継続的フィードバック

運用は自動化がかなり進んでいる。
開発にも求められている。

開発者に求められるもの
今までの固定観念を変える。
マインドを変える。
どうせ出来ないから…ではなくて脱皮する。
加速するためにプロセスを活用する。

  • 常に進化する意識
  • 利用者視点
  • 技術とあいのりする勇気

持続可能な継続が改善へ

  • プロセス/プラクティス
  • ルール　インフラ　支援

世界でのトレンド
BTS，ITS,SCM，CI,TDDはもうあまり議論されていない。当たり前。

ALM　DevOps
CD
CF
AcceptanceTestDriven

BuisinessAgility

【B-2】ヤフーのHTML5対応


自分には珍しく、WEBっぽい内容を選んでみました。
知識不足でメモ漏れが多そうです…

聴講メモ

YOLP(地図) - Yahoo!デベロッパーネットワーク
震災関連、テキスト解析などのWebAPI(自社からなんかサービスが出てたきがする）

エンドユーザーはYahoo!に探したい、知りたいなど◯◯したいと訪れている。
エンドユーザーの声に耳を傾けて、新しいサービスを開発。
◯◯したいを解決する。

・リアルタイムの株価チャート表示
・ワンタイムパスワード

クールじゃないと言われているのは知っている。
エンドユーザーの課題解決を真摯にやっている。
⇒ココは熱いものを感じました。是非クールにして欲しいですね！

Yahoo!の課題解決の手法のひとつ
課題解決の手法のひとつとしてHTML5が挙げられる。
HTML5を使うのが目的にならないようには気をつけている。

ネイティブアプリはパフォーマンス重視。デバイス機能との連携
ブラウザ面はHTML5良い。共通化、パフォーマンス重視

HTML５は環境が整っているスマートフォンで先行開発。

  • ブラウザが限定されている
  • 下位互換の必要性がほぼない
  • HTML5の技術が活用できるなど

・スマホ版Yahooトップ
使っているHTML5の機能

HTML記述の簡略化

  • より意味のある要素に置き換えられるパーツ、全体で見ても正しいアウトライン。
  • header,footer,section

divじゃなくsection

入力方法に合わせたフォーム

  • type="search"
  • ほかにも"email","url","tel","number"など細かい実装にも気を配っている

タッチイベント

  • ニュースタブは指を話す前にタブが切り替わることでスピードを

位置情報

  • GeoLocationAPIを使うと位置情報と連携できる。
  • サービスには文脈を意識することが大切。

WebStrage

  • データを保存する仕組み
  • 検索の履歴
  • トピックス、スポーツなどのタブを保存

CSS3

  • グラデーション
  • 角丸
  • ボックスシャドウ、テキストシャドウ
  • N番目の要素セレクタ

Yahooジャパンテンプレート
独自開発テンプレートシステムを利用
テンプレートシステム
基本テンプレート（html）
Javascript　モジュール動作や機種別差異を吸収
モジュールパーツ、共通ヘッダ、検索ボックス

できるところから

HTML5の標準化も方向性が定まる。
HTML5によって様々なデバイスで利用できる。
最近はブラウザがいろいろなところに組み込まれている。
HTML5は可能性がある。

もっとブラウザでいろいろできる。
でもクリアするべきとこは多い。

【A-3】テスト駆動開発の進化


実践テスト駆動開発の翻訳者である和智さんのセッション。
最近TDDやテストに興味を持ち始めたので、一番聞きたかったセッションでした。

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

当然会場で購入し、和智さんのサインゲット！！！

聴講メモ

テスト駆動開発の進化

5年の間になにがあったのか？
テスト駆動開発だけではなく、アジャイルにも重要な5年。

TDDの基本的なサイクル

最終的なゴールが動作する綺麗なコードだとすると、どうやってゴールに辿り着くか。

  • まずは動くコードを作り、綺麗にしていく。

従来型だと、綺麗なコードを書き、テストコードを書く。失敗したら。。。

  • まずは失敗するテストコードを書く⇒テストに通るプロダクトコードを書く⇒コードを綺麗にする。

クラスをひとつ書く場合ならテストコードも悩まずかける
テストコード⇒Moneyクラス

TDDの黄金律

  • 失敗するテストを書く。

　ここではUnitTestではなく、受け入れテスト。
　　・システムが実装すべきフィーチャー
　　 ユーザーに対して届けるべき価値
　　
システムのスライス
・受け入れテストはエンドツーエンドに。
　　端から端
　　ユーザーが入力し、データを取得し戻ってくるまで
　　　
進化したTDDサイクル

  • 2重のテストループ

　　失敗する受け入れテストを書く⇒失敗するユニットテストを書く⇒。。。
　　Cucumber,Rspecの関係

外から内へ

  • 外側のテストは進捗の指標に
  • 内側のテストはコードの質のため

外側だけよければいいというわけではない。
デベロッパーのためのテストも必要。
高凝集、疎結合

GOOSのポイント

  • モック
  • ウォーキングスケルトン

JUnitはケント・ベック
JMockはGOOSの著者

モックについて

　オブジェクト指向システムは協力しあうオブジェクトの網の目のようなものなのだ。
　クラスよりもインターフェース
　
この観点で見るとUnitTestの位置づけが変わってくる。
　網の目の中のオブジェクトはどうテストしたらいいのだろう？
　おとなりさんが多い。
　　隣合うオブジェクトをモックに差し替える

インターフェースの発見

  • 外から中への開発ができるようになる。
  • 外からばーっと書けば気持よくかけるわけでは無い。

オブジェクトの登場パターン
Goosの中に紹介されている。

  • 分解
  • 発芽
  • 包含

ビジネスドメインの言語を使って記述する

最初のフィーチャのパラドクス

  • フィーチャをエンドツーエンドに開発
  • テスト基盤

ウォーキングスケルトン

  • フィーチャの薄いスライス
  • ただし、エンドツーエンドに。

　
継続的デリバリー

  • まずは基盤をつくり、ビルド/デプロイ/テスト

フィードバック・ループ

  • エンドツーエンドのいベースを作ろう
  • １フィーチャずつ差し込んでいこう
  • Growということで成長させる。

開発の現場で活かすには

想定

  • 受託開発
  • お客様の業務を学びながら開発
  • 中規模

２重ループのさらに外

  • 最初の受け入れテストはどうやってかいたらいいだろう？

下準備
　問題を理解する⇒アーキテクチャを定める⇒ビルド、デプロイ、テストの自動化

  • GrowingObject−OrientedSoftware，Guided　by Tests

事前に特性を見極める

  • 複雑さを吸収する場所

　　業務が複雑化すればシステムも複雑化する。
　　それをどこで受け止めるのか？

エンティティ主体のドメイン

  • ロジックがSQLに集約
  • 設計すべきはデータパターン

　
ロール主体のドメイン

  • ロジックがオブジェクト間のインタラクションに集約
  • 設計すべきはシナリオパターン

まとめ

【A-4】Struts の時代から、標準 Java EE で実現する効率的な Web サイト構築の時代へ


（最近は書いてないですが…）今のPJで利用しているFWがSeasar2(SAStruts)ベースなので興味を惹かれました。
セッションの内容は、デモ動画を流しながらの説明だったのですが、詳細まではついていけず…
ただ、かなり生産性が高いのでは？と思わせる内容でした。
※懇親会でお話させて頂いたのですが、そう思わせるのが狙いだったようです。

なんかスゲーって感じで見ていたので、ちゃんとしたメモが残っていませんでしたが（笑）、寺田さんのブログに詳細と動画があがっているのでそちらを参照すると良いと思います。

JSFについては、機会を見て自分でも触ってみてブログを書きたいと思います。
ちなみに、NetBeansを利用すればインストールだけで環境構築が完了するとのことです。
これを機にNetBeansも触ってみますかね。

JSF 2.0 の詳細について « 寺田　佳央 – Yoshio Terada

【A-5】あの人の自分戦略を聞きたい！-デブサミ関西編


楽しみにしていた自分戦略！
と言いつつ、実は前日に中村さん、野崎さんと夕飯をご一緒させて頂いていて発表を聞いているんですよね（笑）
ただ、壇上に立って講演している姿は格好良くて、飲み屋さんで聞いた時とはまた違った印象でした。
中村さんとは社内の読書会で毎週ディスカッションをしていたので、そんな人が壇上に立っているのは不思議な感覚で、凄い贅沢な、濃い時間を過ごしていたんだなぁと実感しました。

これから、自身の自分戦略を立てて、同僚や後輩にそう思われるようなエンジニアになれるように成長していきたいです。

オープニング

聴講メモ

前川 直也 氏の自分戦略

エンドロールへのOvertake

分岐点ってありますよね？
今日がそれ。
琴と三味線が趣味。大奥で三味線男子を募集していて、映画にでれそうだった。（デブサミ関西と日程が被ったらしい！）

エンドロールに名前を残したい。
オリンピックステップアップ

変化を抱擁せよ。

変化とは？
XPJUGに行った。
2002年くらいにはエンジニアリングが多かった。
自分はマネジメント側に興味があった。
平鍋さんの資料で言うところのレフトウィングから。

SNSって？
人から認めてもらうアクノリッジメント⇒頑張る。
相手を認める⇒自分も認めてもらう

リアルのいいね！
自分VS◯◯

みんな違ってみんな良い！

吸い取る⇒考える⇒伝える⇒つなげる⇒描く！

自分はなにができるんだろう？なにがしたいんだろう？

証を残す≒エンジニアリングをビジネスにする。

自分をOvertake!

あなたのエンドロールをどう描きますか？

野﨑 啓史 氏の自分戦略
プログラマであり続けるために　

１．がんばらない

  • がんばる＝無理する
  • 継続は大事

２．選択する（指針）

  • 選択する、選択しない

３．年齢をきにしない

  • 年齢とか関係無い
  • 年齢バイアスを避ける
  • 新しいものをはじめるカセは少ないほうが良い
  • 1000年生きるつもりで

⇒そのくらいの気持ちがあればなんでもできるだろう。

ジョーカー的な立場でありたい

  • エースではなく

3人目

  • 思いつくのは1人でも
  • はじめるのは2人いれば
  • 続ける広めるのに3人目
  • 触媒みたいな役割を目指している

　
目指すプログラマ像は3人目、ジョーカー

障害は多い
障害が無くなったら自分はどう振る舞うのだろうか？？？
みなさんはどう思いますか？

中村 洋 氏の自分戦略
自分の源泉

  • チームの成長

⇒チームの成長を見るのが嬉しいし、モチベーションになっている。
　　成長できる環境を整える！
　　チームからいらないと言われるのが目標

  • お土産

　⇒次に会った時、おみやげを渡したい。
　　勉強会で良いアウトプットがしたい。

  • 恐れ

　⇒素晴らしいコードを書けるわけではない、１人でリリースできるわけでもない
　　モチベーションが低く力を出せていないチーム(中村さん的に”恐れ”というより好物なのでは？？)

自分戦略

自分でハンドルを握る。

やってること

  • 表明

　　やりたいことを表明

  • 準備

　　普段から爪を研いでおく。ちゃんと準備する。勉強する。

  • 雪かき

　　人がやりたがらないことをする。
　　チームに貢献する。
　　信頼貯金ができる。
　　いざという時にやりたいことを

  • 巻き込む

昔の上司に「仕事なんて楽しいはずない」と言われた。
楽しくしたいから自分にできることにベストを尽くす！

エンディング