ヽ(´・肉・`)ノログ

How do we fighting without fighting?

札幌 Java カンファレンス 2012 に参加した

僕にとっては新しく知った話があり,とても勉強になりました.

すでに感覚としてぼんやりと認識していた話もありましたが,話者が整理して再構築してくださったことで,認識をクリアにすることができ,これもまたとても勉強になりました.

良い刺激になりました.ありがとうございます.

次回は IntelliJ 入門があるといいなあと思いました. Eclipse と NetBeans は使ってみたことがあるのですが,IntelliJ は半日程度試してみたものの,使い方があまりわからず断念した経緯があります.

Lambda への道 - @skrb

Java の lamda について, 外部のローカル変数に再代入できないのは, 大体の場合 reduce があれば大丈夫なので平気です. 1 行のときだけ特別扱いする記法があるのも 細かい粒度での記述のモチベーションになるので悪くないなあと思いました.

もし,JVM 系言語で開発するなら,僕の場合のファーストチョイスは JRuby になりますけど, 他の選択肢としては,今のところ Java8 >> Groovy > Java7 以前という順番になりそうです.

Java8 早く出ないかなあ.

以下はメモです

BackGround - なぜ lambda が必要とされているのか

2008 年に中止したのに 2009 年にすぐ復活している.なぜ lambda が必要とされているのか -> 2000 年代後半から multicore が隆盛

Lambda Syntax - Lambda の記法

(引数, 引数) -> { 処理 }

interface Adder { int add(int x, int y); }
Adder adder1 = (int x, int y) -> { return x + y; };
// 引数の方を省略
Adder adder2 = (x, x) -> { return x + y; };
// 処理が 1 行であれば波カッコと return を省略
Adder adder3 = (x, y) -> x + y;

interface Doubler { int doubleUp(int x); }
// 引数が 1 つであれば,カッコも省略可
Doubler doubler = x -> x + x;

Default Method

interface Hello {
    void sayHello(String name);

    void sayGoodbye(String name) default {
        System.out.println("Goodbye, " + name + "!");
    }
}

Iterator - イテレーターAPI

Stream

List<String> list = ...;
list.forEach(element -> System.out.println(element));

Stream<T> filter(Predicate<? super T> predicate)
Stream<T> sorted(Comparator<? super T> comp)
Stream<U> map(Mapper<? super T, ? extends U> m)
T reduce(T base, BinaryOperator<T>, reducer)

Bulk Operation

// Shape のうち,青い色の合計重量を求めよう
List<Shape> shapes = ...
int sum = 0;

for (Shape shape: shapes) {
  if (shape.getColor() == Color.BLUE) {
    sum += shape.getWeight();
  }
}

// lambda で書いてみる
// フィルタリング処理 + マッピング処理 + 合計処理
int sum
= shapes.stream()
        .filter(s->s.getColor()==Color.BLUE)
        .map(s -> s.getWeight())
        .reduce(0, (l, r) -> l + r);

// 並列処理してくれる
int sum
= shapes.parallel()
        .filter(s->s.getColor()==Color.BLUE)
        .map(s -> s.getWeight())
        .reduce(0, (l, r) -> l + r);

現状

Developer Preview は http://jdk8.java.net/lambda にあるよ

作って学ぶデータベース - @kis

自分でももしかしたら DB を作れるかもしれないと思うような内容で,ぜひやってみたいと思いました. 特に自分でトランザクションを実装できれば,自分の自信になりそう.ついでにもしかしたら業務アプリケーションの承認フローの実装の役に立つかもしれません.

プレゼンの絵が斬新だったのと,写真のヒヨコがかわいかったです.

ただし,後でお話を伺ったら,実装は 10 日でできてますけど,作るための知識を得るのにはもうちょっと時間がかかっているみたいでした.

以下はメモです

作ったもの

day1 - 基本

リレーショナルモデルの実装 300行くらい

day2 - サブクエリと構造変更

day3 - 集計

600 行いかないくらい

day4 - インデックス

山場

day5 - 集計でのインデックス

day6 - 更新・削除

day7 - ユニオン

SQLで直接は書いてないんだけど,DBが裏で使いまくってるんだぜ.

kubun = 5 OR price > 1000

day8 - insert時のトランザクション

day9 - MVCC

day10 - 隔離レベル

1700 行くらい

上から下に隔離レベルが上がっていく

Read Uncommited未コミットの操作も見えるMVCCだと,バージョンを指定しなければこれになる
Read Commitedコミットした操作は見えちゃうMVCCだと,読むときにバージョン番号を判断する所で,バージョンを無視すればこれになる
Repeatable Readコミットした追加・削除は見える,更新は見えない理解不能なのでやらなかった
Serializableトランザクション開始時のデータしか見えないMVCCだと,もうできてる

作りたいもの

クエリと実行計画

実行時最適化

ストレージとログ

Join戦略

複数の戦略が使えるときにどうするか

JDBC対応

ロック

デッドロック

まとめ

顧客とPMとPGの話は,なぜ噛み合わないのか - @yusuke_arclamp

僕の行動原理を振りかえってみると “Do the right thing” のことばかり考えていて,”Do things right” について主で考えたことはなかったですねえ. “Do the right thing” するために “Do things right” が必要なのだと思っていた.実施についてもうちょっと考えてもいいのかな.

物事を整理して説明してくださった前半と,選択する責任と覚悟の話をなさっていた後半 ( というか最後 ) の対比が印象深かったです.

前半の話は、プロジェクトの当事者でなくてもできる、プロジェクト一般について語られている話でした。 もちろんそれがないと、どの方向に進めていいかわからなくなるので必要です。いわば地図ですね。

後半の話は、プロジェクトの当事者でなくてはできない、プロジェクトを進めるための話でした。 みんなで「うーん、どうしよう」と考えているだけではプロジェクトは動かないですね。 「こういう事情を勘案して、今回はこれでいく。責任は俺が取る」と言う人がいてはじめてプロジェクトはうまく動けるのかもしれません。

以下はメモです

次の案件にはどのフレームワークを採用しますか?

決めたとき,どの立場で考えていましたか

他の立場に立つと選択は変わるかもしれない

ソフトウェア開発とは

ソフトウェア品質モデル(JISX0129-1ソフトウェア製品の品質 第1部 品質モデル)

  1. プロセス品質
  2. 内部品質
  3. 外部品質
  4. 利用時の品質

品質は1->4へ影響を与えるし,4->1へ依存する.

どうやったら良い依存/影響関係を築けるだろうか

プロジェクトマネジメントとは

プロジェクトマネジメントをざっくり言うと計画・実行・調整をしている

PMBOK は計画と実行の差を把握するための知識群

PMは「計画と実行の差」から「課題を予測/予知」し「調整」を行うことで,プロジェクトを正しい状態に導くことが必要

アーキテクチャとは

アーキテクチャ設計とは,システムのミッションと制約を前提に利害関係者の関心事を整合させた

アーキテクチャとマネジメント

どちらも,品質同士の依存/影響関係に注目している人のことだよ.

役割主題いつ活動するか
プロジェクトマネジメント問題の予測と対応事後的な活動(対応)がメイン.計画段階はアーキテクトと協業
アーキテクチャ設計問題対応能力の確保事前的な活動(計画)がメイン.事後はプロジェクトマネジメントへの技術的な支援をする

“不満をいくらtwitterに書いてもプロジェクトは好転しないので”

どうやってバランスを取るか

内圧と外圧のバランスを取り,張りを維持する

まとめ

「次の案件にはどのフレームワークを採用しますか?」 「場合による」

選択することは簡単ではない.理由を説明する「責任」と,結果を受け入れる「覚悟」が必要.

何かを「選んだ」と思ったら,その理由を自身で説明できるか.

コロケーションアジャイルの実践 - @matsudate

アジャイルなソフトウェア開発をするためには,円滑なコミュニケーションが必要不可欠なので,拠点が離れている場合はその部分をどうやって埋めるかに焦点が当たっている感じがしました.

最初は一緒の場所で働いていて,徐々に分離していくところや,離れていることを利用してチームの意気を上げるところは上手だなあと思いました.

以下はメモです

横浜と函館の拠点でアジャイルなソフトウェア開発をしているよ

種別管理・責任作業分担コミュニケーション
オフショア開発独立分割
アジャイル開発連帯共有

16 のポイントについて語っていく

1. Continuous Integration

1番最初にやっておく

2. Have Each Site Send Ambassadors to the Other Sites

  1. 一緒に作業
  2. 近くだけど別の場所で作業
  3. 函館へ移転して作業

3. User Contact Visits to build trust

試行錯誤の臨場感演出(コミュニケーションギャップを生まないように)

4. Don’t Underestimate the Culture Change

“autonomy is a great motivator, allowing people tobe productive and responsible”

函館チームのプライドを鼓舞

5. Use wikis to contain common information

6. Use Test Scripts to Help Understand the Requirements

イテレーション開始直後のテスト仕様確定

必ずペアで作業する

7. Use Regular Builds to Get Feedback on Functionality

イテレーションリリース

8. Use Regular Short Status Meetings

Skype朝会

持ちまわり一言

9. Use Short Iterations

10. Use an Iteration Planning Meeting that’s Tailored for Remote Sites

前イテレーション中に次開発要件をブレイクダウンするチームを結成

あらゆる通信手段を駆使(TV会議,電話,Skype,IPM…)

11. When Moving a Code Base, Bug Fixing Makes a Good Start

リファクタ,バグフィックスのみのイテレーションを実施

開発とは別ラインでのバグフィックス平行作業

12. Separate teams by functionality not activity

13. Expect to need more documents

自らが必要とするドキュメントは作成する

ドキュメントは間違ってることもある.必要なところだけ抜き出して新しく作ってもいいよ.

14. Get multiple communication modes working early

最初,プロジェクトの概要説明をビデオに撮っておいて,後からjoinした人に観せるとか

15. Costs and Benefits of Offshore Development

“productivity differences between developers are far greater than salary differences”

16. The Future of Offshore and Agile

テストコードのリファクタリング - @shuji_w6e

テストが増えてくると,テストの構造化やパラメタライズドテストは必要になりますよねえ.

テストをどこまでまとめてしまうかはそれぞれの利点/欠点があると思いますが, 僕の場合は,テストを見たとき,上下にあるテストと比べて,どこが違うのかを一目でわかる程度にはまとめますね.

テストコードをリファクタリングするくらいテストが増えてくると, テストがすぐに終わらない,スローテスト問題というのも出てくるので, そちらについても今度話を伺いたいなあと思いました.(実際に測ったベンチとかあれば)

以下はメモです

ユニットテストの目的

TDDのユニットテストの目的 -> 開発者の不安の解消

ユニットテストはセーフティネット

書いて整理する

JUnitでのテスト整理の鍵