デブサミ2010に行ってきました
去年に引き続き、今年もDevelopers Summit 2010 に行ってきました。
情報は生ものといいますので、忘れないうちに書き起こしておきます。メモ書きからの転記ですので間違いがありましたらご指摘ください。
ソースコード・リーディング・ワークショップ in デブサミ2010
ソースコードを読む力を養うために、実際にコードを読んで参加者同士数名のグループに分かれて語り合う会。JavaAppletの動くコードを読んで、さらに機能追加差分のコードを読んで組み込んでも問題ないかを評価する課題です。
僕も数日前にコードを読んでいたのですが、開発スタイルが少し書いて動かしてみるやり方をしているので、コードを読むだけなのは難しかったです。とは言うものの、現場でも経験の浅い人がリポジトリにコミットした時には、一つ前のバージョンと比較して差分を読んでいますね。難しく感じたのは読みが足りなかったからかな。
セッションメモ
- ソースコードメトリクスと読解時間の関係
- 変数の数が多いと、読解に時間がかかる
- 呼び出しメソッドが多いと、読解に時間がかかる
- 変更差分の行数は、読解時間に影響は少ない
- 日本では開発者と研究者の連携が不十分
- Apache Mavenでメトリクス計測ができるので、とりあえずそれから使ってみるといいかも
- 変更の種類
- 変更メソッドの複雑さ
- 変更の規模
- 差分の複雑さ
- 差分から参照される外部定義
【18-C-3】アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
「実践アジャイルテスト」の訳者の方がスピーカー。アジャイルテストとは何ぞや？という事を本を読んだ気になれるセッションです。
内容
プログラマでなくテスターの視点
従来型テストの視点
- 標準（IEEEなど）
- テストタイプ、テストレベル
- インシデント管理
- テストケース作成
- 網羅性
メソドロジ
- プロセス記述(WBS)
- ガイド
- 作成済みサンプル
4象限
- 技術よりでチームを支援する：単体テスト・コンポーネントテスト
- ビジネスよりでチームを支援する：機能テスト（ストーリーテスト・プロトタイプ・シミュレーション）
- ビジネスよりで批評する：探索的テスト・シナリオ・ユーザビリティ・ユーザ受け入れ・アルファ/ベータ
- 技術よりで批評する：パフォーマンス/負荷テスト・セキュリティテスト・「〜性」テスト
高品質を目指すチームのプラクティス
1.チーム全体のアプローチを取る
会議に参加する
2.アジャイルテストの考えを採用する
より良い方法を常に探す。良い本やブログを読みアイデアやスキルを身につける。
3.自動リグレッションテストを適用する
自動リグレッションは開発者・テスターどちらかでなくチームの仕事。シンプルにはじめる
4.フィードバックを与え、受ける
フィードバックはアジャイルの中心的な価値である
5.コアプラクティスの基礎を築く
1.継続的インテグレーション
2.テスト環境を管理する
3.技術的な負債を管理する（未解決の技術的課題の累積）
4.段階的に作る
5.コーディングとテストはひとつのプロセスとする
6.各プラクティスの相乗効果を図る
6.顧客と共同作業をする
テスターはまとめ役になる
7.広い視野を持つ
現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする
アジャイルテストへの移行
1.文化的なチャレンジ
2.チーム運営
3.プロセスの移行（できるところから始める、既存のプロセスに従うべきものもある）
Rational Team Concertの宣伝
【18-E-4】データベースの品質を守る。-22年間のノウハウを終結させたデータベース開発・運用改善手法の紹介-
データベースを読み書きするアプリの品質を良くするためには？
ソフトウェア品質を追求する大きな課題
・確率でないと語れない。
・10回連続で動いても、次に動くとは限らない。
・ハードでもリコールが起こるなら、ソフトでは当然（常に確率論）
ソフトウェアほどいい加減なものもない。動かなくても責任取らないよとたいていのソフトに書いてある。
良いアプリケーションとは
・正確（機能を満たす。バグフリー）
・効率
・運用効率（今日も明日も一年後も動く。誰でも修正できる）
天才の仕事でなく、努力の結果
高品質なアプリを作るには？
テスト
開発の標準化はテストの標準化にあり
これらのことが正しく行われていれば、最適化する必要のあるコードは5%ぐらいになる
・計測可能なテストケースの作成（成功か失敗か）
・コードのテストユニット化
・デバッグの自動化
・標準化されたコード規約の適用
SQLチューニングの課題
・最適なSQLを証明することは事実上不可能
・SQLの性能は、本番直前までテストされない
データ数や同時アクセスユーザ数は考慮しているか？
Toad for Oracleの宣伝
【18-B-5】クラウドの構築事例「クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例」
実際にAmazonEC2を利用してクラウドサービスを立ち上げた際の体験談です。本にまとめて出版されているようです。
Amazon EC2/S3とは？
・EC2：仮想サーバ
・S3：オンラインストレージ
・初期費用無料で1h/1GBごとの従量課金
・インフラにかかわるコストを小さくできる
・VPNにより自社内ネットワークのリソースとして利用できる
・APIで操作する（HTTP API）
基本機能
・AMI
仮想OSイメージ。バックアップ・リストアで環境のコピーが容易
・KeyPairs
リモートログイン時に必要となるキーの生成
ログインセキュリティの強化
・SecurityGroup
仮想サーバへのアクセス制限
ネットワーク遅延の対策
・日本とアメリカ・ヨーロッパのRTTは、200ms程度かかる
・Amazon CloudFront（キャッシュサーバ）もしくは国内に静的コンテンツサーバを併設
ストレージ
・Amazon EC2（ローカルディスク）複製されない
・Amazon EBS 書き込み時に複製。同一のZONEのみ
・Amazon S3 書き込み時に複製。2つ以上のZONEに複製
・仮想サーバのローカルディスクは、サーバを停止させると消える。ロストしたくないデータはEBSの利用が必須
利用例
・EC2 基本的に変更しないシステムデータ
・EBS ファイル、DB、ログなどのアプリデータ
・S3 バックアップデータ、カスタムAMI
バックアップ
・システムはAMI化してS3にとる
・EBSのデータをS3にスナップショット
・S3Sync
メールサーバ
・EC2のインスタンスで使うIPアドレスが、スパムメールのDULに登録されていることがある
spamhaus.org / mail-abuse.com (maps)
・DNSの逆引き設定をAWSに申し込む。この後スパムリストに解除申請を出す
オペレーションミスの影響範囲
・本番用とテスト用で別のアカウントIDをとるといいよ
インスタンスの障害対応（すべて英語）
・AWS Health Dashboard
・AWS Developer Community Forum
・AWS Premium Support（有償）
アクセスできなくなった場合の復旧パターン
・自然復旧
・API経由でリブートによる復旧
・AWSサポートスタッフによる復旧
・別インスタンスへのマイグレーション（ユーザ側、AWS側）
対応フローを準備しておく
OSより上のレイヤはユーザが責任を持って運用する
・バックアップ、セキュリティパッチの適用、HTTP死活監視
【18-E-6】RDB入門〜アプリケーション開発者が陥りやすいDB開発の落とし穴〜
DBにまつわる問題とその対応。僕の周りでも同じような事例がありました。
1.システムがとまった
2.プログラムのパフォーマンスが出ない
3.Viewを使っているのだがパフォーマンスが出ない
4.マルチコアCPUが有効に利用されていないようだ
1.システムがとまった
特定の処理でフリーズするが、毎回発生しない。テスト環境で再現しない。
原因は、ある処理がトランザクション分離レベルをReadCommitedに設定していた（システムはReadUncommitedが前提）
.NETの仕様で、プールされているコネクションは直前に使用された分離レベルを継承する。
解決方法は、処理開始・終了時に必ず分離レベルの設定を行う
RDBMSによって実装の仕方が違う（Oracleではこのケースは発生しない。読み取り一貫性）
2.プログラムのパフォーマンスが出ない
要求仕様を単純にSQLに置き換えると、何回もSQLを実行する場合があるので効率の良いSQLを検討する
3.Viewを使っているのだがパフォーマンスが出ない
Where句のつけ方でViewを使うほうがパフォーマンスを低下させることがある。
マテリアライズドビューを使う解決方法もあるが、Refreshの管理やデータ領域に気を配る必要がある。
4.マルチコアCPUが有効に利用されていないようだ
ディスクIOがボトルネックになっている場合があるよ
あとSQLAnywhereの宣伝
【18-C-7】アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション
アーキテクトが知るべきの本にはあまり触れずに、アーキテクトの人がどんなことを考えているかという会でした。
普段触れているアーキテクチャ
Swing, Silverlight, MVC, データスパイダー（パッケージ）
考えること
クラウドのデータはスケールアウトすると、コミットしたデータが反映されるまで時間がかかる
これをどう利用するかがアーキテクトが考えるところ
インターネットのクラウドと企業のクラウドは別物と考えたほうがいい
今何か新しいサービスを立ち上げるならクラウドを使うことも考える
アーキテクチャで失敗したこと
フレームワークのような土台になるものは、きちんと作りこまないと後で後悔する
フレームワークはコミュニケーションツールのようなもの
コストの高いフレームワークを作ってしまった
完璧なものを作っても、既存のものは捨てられない
理想を求めすぎるとよろしくないものができた
アーキテクチャは後方互換性も考える
Windowsは意外と後方互換に気を使っている（これも戦略）
ライフサイクルが短い製品を作るときに、いろいろ実験する
メインの製品に依存しないように
社会的なアーキテクチャ
Twitterはなぜこれほどまでヒットしたのか
はてブのホッテントリに表示されるジャンルがIT以外も出てくるようになった
IT以外の量が増えたわけでなく、ITの表示を絞った。
各ジャンル2位まで表示
企業情報システムは使われていないものが多い
なぜ使われないかを追跡する機会が少ない
運用をやれば機会があるかも
お金を払わせるサービスは？
人の感情を刺激するものがヒットするかも。サンシャイン牧場やブラウザ三国志
スーパーマリオのジャンプは計算され尽くしている
気持ちのいいジャンプ
とあるゲーム会社で入社試験にジャンプをするだけのプログラムを作らせているところも
センスが見られる
ペアプロは良いものだ。
メソッド名を考えるのは大変だ。
