DeveloperSummit2010のメモ

あくまでメモの段階です。

Google的分散コンピューティング(2月18日)

GFS

Bigtable: A sparse, distributed, persistent, multidimensional, sorted Map
Bigtable, Not Bigdatabase
  • Less is More
    • No transactions
    • No schema
    • No foreign keys
    • No join
    • No relational algebra, Cartesian product, etc
    • No SL
  • Singl row updates are atomic. Everything else is not
  • Only basic data types: string, counter, protocol buffer
Expect Failure
  • GFS
    • Data replicated 3 times.
    • Upon failure, software re-replicates.
  • MapReduce
    • Restarts failed map / reduce workers
    • Detetcts key key//value pairs that cause crashes, skips
    • Tougher to deal with :laggards
Autonomy

GFS

Sawzall Quantifiers
  • Descriptive as opposed to Prescriptive
  • some / all / each
感想

英語Onlyでほとんど聞き取れなかった。。。
ということで必死にメモした内容のとおりです。

エンタープライズクラウド(2月18日)

www.appirio.jp

エコポイントはクラウドを用いて開発
  • 3週間で作れた機能
    • インターネット機能
    • コールセンター機能
    • 申請の審査機能
  • 6週間でできた機能
    • ユーザ機能の完成
  • すべての機能ができたのは16週間
    • 不正検知システム
    • 環境団体への振込み機能など
  • 2000万人の会員
  • 開発
エコポイントの使い方
  • もらったポイント
  • 交換したポイント
force.comの利点
  • 簡単に使える
    • フィールドが簡単に作れる
    • オブジェクトが簡単に作れる
  • 明快
  • 安全
    • データの一貫性
    • データの隠蔽性
force.comの制限事項
  • High Volumeなデータを使うことはできない
    • こういった場合は別のクラウドを用いる
  • 1日1000件までしか外部にメールが送れない
    • この時GoogleAppEngineを用いる
      • Googleは1日170万件まで送ってよい
      • エコポイントは1日10万件のメールを送っている
クラウドに向いているアプリケーションは何か?

クラウドでできないことは何かと考える

force.comとflexの組み合わせ

swfを活用してインタフェースを直感的にすることができる

感想

「クラウドってどんなだろう?」という軽いノリで行ってみたが
かなり面白いセッションでした。
force.comはsymfonyのようなフレームワークという概念よりも上の
WEBサイトフレームワークという感じでさくさく開発できそうだった。
エンジニアでなくても仕様が固まっていれば開発が行えそうだ。
いずれプログラマという職業は必要なくなって時代が来る。
いつかはわからないけど。

kumofs(2月18日)

@frsyuki氏

過去
  • viver
  • runes
  • v-field
NoSQLとは
  • key-value store
  • NoSQL
    • スケーラビリティが高い(今回はここを軸に進める)
      • 利用者や仕事の増大に適応できる能力(拡張性)
スケーラビリティが高い
  • スケールアップ
    • 負荷が増大した場合にサーバを置き換える
  • スケールアウト
    • 付加が増大した場合にサーバの数を増やす
kumofsのアーキテクチャ

特徴

  • 耐障害性
  • 超高速
  • 動的な運用

ApplicationサーバではMemcachedのプロトコルを使用している。
またlocalhostで動作しているためkumofsサーバのスケールアウトが容易である

感想

kumofsは堅牢性、拡張性が高いように感じました。
WEBサービスを提供しているところであれば
Key-Valueストアの利点を感じることが出来たセッション。

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス(2月19日)

IBMの方

アジャイル導入の効果
IBMのソフトウェアグループの開発プロセス
  • 1980年代はウォータフォールで開発が行えていた
  • 90年代〜2000年代では反復型
  • 最近はアジャイル
アジャイル開発の本質
  • 反復&インクリメンタル&適応型の開発
    • 要求は劣化していく
      • 平均的には1年間で30%ほど劣化していくと言われている
    • 短いサイクルで重要な機能から作成していく
  • 短いタイムボックス内で動くコード
  • 小さな一口単位で開発
    • ストーリーの粒度は数日、タスクの粒度は一日以内
規模に関係なく適用可能なプラクティス
感想

要求が劣化していくという考え方は腹に落ちました。
外部環境が大きく変動する昨今ではアジャイル開発が
肝になってくるとは思いましたが、自身のスキルの面で
乗り越えなければならない壁が多いです。


三週後れのXP 僕とドワンゴのXP(2月19日)

  • DWNGO
  • @yoshiori氏
  • ケントベック…xpの提唱者
  • 車輪の再発明をしないこと
  • 高速道路の設置をするのが我々の仕事
4つの価値
  • コミュニケーション
  • シンプルさ
  • フィードバック
  • 勇気
    • 不安をなくすための行動
    • たとえばTDD
    • 勇気を出すための
おやつ神社

賽銭箱

テスト駆動
  • 角谷信太郎
  • java-ja勉強会
注意

テストファーストの話はしない

TDDの目的

あくまでも開発であり、テストのためのアプローチではない

動作しない 動作する
綺麗 ここを目指す
汚い
  1. 汚いコードを動作するコードにする
  2. 汚くて動作するコードからきれいで動作するコードにする

プログラマなら面倒なことを自動化してしまえばいい
リファクタリングのためにテストを書いている

TDDの利点
  • 自分の課会決すべき問題を小さく明白にする
  • すぐにテストを実行
  • 開発するためのテストを書く
  • 品質を担保するためのテストではない
    • TDDという開発手法自体が品質をアップさせる
TDDの伝わりにくいところ
  • UnitTestではない
    • 不安をテストする
  • 品質どうこうではない
    • 開発のためのテストであって品質のためのテストではない
  • コードはxxxさんの書いたところだからという意見はNG
    • コードはチームのもの
  • コードを批判を人格批判だと捉える人がいる
    • コードの批判は青果物に対する批判であって人格否定ではない
社内にTDDを導入した方法

社内でTDD写経会を実施

ペアプロで大切なこと

コードを共有できる

コードを共有しないことのデメリット

「そこは私が書いていないからわかりません」ではNG

新人教育
  • 新人にはブログを書かせている
    • コードをさらすことを目的としている
    • コードを私物化させない
CI(Continuous Integration)

永続的結合
Hudwonを導入している

ciのいいところ
  • テストを自動で行ってくれる
  • メール送信される

SLOWTEST

  • テストが増える
    • テストにかかる時間が増える
      • テストを実行しなくなってくる
感想

開発プロセスという概念のパラダイムシフトが起きてしまうセッションでした。
TDDやアジャイル開発プロセスをまずは個人から始めてみようと思います。



資料などはまた調べてUP予定です。