Java

java-jaでTDDでペアプロUst中継をしました

凪瀬 — Mon, 08 Jun 2009 00:55:00 GMT

第二回チキチキ日本ペアプログラミングの会java-ja支部会（仮）に参加してきました。会場を提供してくださった株式会社ドワンゴ様、本当にありがとうございました。

TDD(test-driven development)での開発ってどんな感じ？というセッションをまずt_wada氏がやって、踏まえたうえでペアプログラミングで実践して体感するという流れ。

ペアプロの相手を探すフェーズがさながら合コンかお見合いパーティといった風情。私は@yamashiro氏とペアを組みました。 @yamashiro氏はTDD慣れしているんだけど、僕のLet'sノートのキーボードと相性が悪かったのが残念。僕らのペアプロ姿はUst中継で放映されていましたよ。

セッション内容は@monjudoh氏がリアルタイムにblogに上げた奴とかたくさんあるので割愛。

成果物

テーマはプライオリティキューを作ろう、というもの。ぶっちゃけてしまえば、Java5からあるPriorityQueue を自作しましょうというネタです。

作業のステップは以下のような感じ。記憶を元に書いているので怪しいです。実際にはもっと細かいステップもいろいろあります。Ust中継を見ていた人はわかったんじゃないかな。

まず単なるキューを実装する方針にしよう
ひとつのオブジェクトを入れて出すところまでをまず作る
1. まずはテストを書いてJUnit(※自動テスト用ツール)を実行してバーをレッド(※自動テストが失敗した状態)にしないといけない
2. キューに入れるテストコードをまず書く
3. コンパイルエラーになるのでCtrl+1 (※エディタはEclipse3.4)を使って実装をCtrl+1で補完
4. とりあえずJUnitのテストが通過してグリーンになる（pushは値を返さないので空実装でも関係ない）
5. キューから取り出す部分のテストコードをまず書く
6. コンパイルが通るように実装コードを補完して、JUnitを実行して失敗、バーが赤くなる
7. Object型フィールド変数を作って格納してget()で返すという簡単な作り
8. JUnitを実行して成功、バーがグリーンになる
次に複数個の入れれるようにしてちゃんとキューにしよう
1. テストケースを書き足して、２個入れて２個出すようにする
2. バーがレッドになる
3. フィールドをList型に変更
4. get()の実装は return this.data.remove(0); でいいよね(List#remove(int)を利用)
5. バーがグリーンになる
ジェネリクス対応させちゃいたいんでここで入れちゃおう
1. コンストラクタに型変数を渡すようにテストコードを修正。コンパイルエラー
2. コンストラクタに型変数を追加
3. あー。このへんのリファクタリングで自動でやれないんだよなー。(2009年6月現在)
4. 手動で実装を載せるしかない
さて、プライオリティを渡せるようにしますか。コンストラクタで渡すでいいよね
Comparatorを渡すようにして順序付けを外から指定できるのがいいよね
1. コンストラクタにComparatorを渡して比較をするテストケースを書く
2. コンパイルエラーになるので実装をCtrl+1で補完
3. バーがレッド。さて、グリーンにするにはどうしようか？
4. ちょっと小さい手ごろなステップが思い浮かばないので一気に実装しちゃう
5. ThreeSetを使って実装しちゃえば速いんじゃない？
6. 実装できた。テストを実行すると…あれ、レッド？
7. あー。同じ値を入れたらTreeSetだとひとつにまとめられちゃうからか
ダメだ、TreeSet方式は却下
ちゃんとダメなケースをはじけたわけだからTDDがうまく機能したね
Listにケツから突っ込んで、比較しながら手前に向かって追い越しをやる方法でどうだろう？
push()時点でキューの中の状態を正しい状態に保つ感じ
1. まずはTreeSet方式を差し戻す。Subversion使っておけばよかった orz (現地の環境がトラブル多そうだったので避けたのが敗因)
2. ただのListにしよう
3. 後ろから順に比較しないといけないから逆順にループしないと
4. Collections#reverse()を使う？
5. 挿入するときにループカウンタ必要になるから拡張for文つかうのはあきらめよう
6. compare()の結果ってどっちが大きいときに正だっけ？ｗ
出来上がり。なんか拡張するテーマ決めよう
SQLのorder by みたいな感じで複数のキーを優先度設定できるようなのどう？
よしそれで行こう…って時間切れか！

ソースコード

ソースをそのままで張ろうかとも思ったんだけど、コメントないなー orz　普段はjavadocとかコメントがりがり書く派なんだけど、なんかすっかり忘れてました。

上で時間切れになった後、「各自の荷物片付けてー」とか言われている最中に実装をやっちゃったので、実装完了版にコメントを追記したソースを載せます。


package queue;



import static org.junit.Assert.*;



import java.awt.Point;

import java.util.Comparator;



import org.junit.Test;





public class PriorityQueueTest

{

  @Test

  public void testname() throws Exception {

    PriorityQueue<String> queue = new PriorityQueue<String>();

    String expectedObj1 = new String();

    String expectedObj2 = new String();

    queue.push(expectedObj1);

    queue.push(expectedObj2);

    assertEquals(expectedObj1, queue.get());

    assertEquals(expectedObj2, queue.get());

  }

  

  @Test

  public void プライオリティを設定できる() throws Exception {

    PriorityQueue<String> queue = new PriorityQueue<String>(new Comparator<String>(){

      @Override

      public int compare(String o1, String o2) {

        return o2.compareTo(o1);

      }});

    String expectedObj1 = new String("b");

    String expectedObj2 = new String("a");

    queue.push(expectedObj1);

    queue.push(expectedObj2);

    assertEquals(expectedObj2, queue.get());

    assertEquals(expectedObj1, queue.get());

  }

  @Test

  public void 複数の優先度を設定できる() throws Exception {

    PriorityQueue<Point> queue = new PriorityQueue<Point>(

        new Comparator<Point>() {

          @Override

          public int compare(Point o1, Point o2) {

            return o2.x - o1.x;

          }},

        new Comparator<Point>() {

          @Override

          public int compare(Point o1, Point o2) {

            return o2.y - o2.y;

          }});

        

    Point p1 = new Point(1,4);

    Point p2 = new Point(1,3);

    queue.push(p1);

    queue.push(p2);

    assertEquals(p1, queue.get());

    assertEquals(p2, queue.get());



    Point p3 = new Point(2,2);

    queue.push(p1);

    queue.push(p3);

    assertEquals(p1, queue.get());

    assertEquals(p3, queue.get());

  }

}


package queue;



import java.util.ArrayList;

import java.util.Comparator;

import java.util.Iterator;

import java.util.List;



/**

 * 2009.06.06 第二回チキチキ 日本ペアプログラミングの会java-ja支部会（仮）

 * TDDでプライオリティキューの実装をした成れの果て。

 * TDDで作ったものは複数優先度がやりかけだったので、お片づけ時間中にnagiseが完成させ、

 * blog掲載時に読む人を考慮してnagiseが解説のコメントを足したもの。

 *

 * @author yamashiro, nagise

 *

 * @param <T> 格納するデータ型

 */

public class PriorityQueue<T> {

  List<T> data = new ArrayList<T>();

  List<Comparator<T>> comparators;



  /** 自然順序付けによるプライオリティのキューを作成する */

  public PriorityQueue() {

    this.comparators = new ArrayList<Comparator<T>>();

    this.comparators.add(new Comparator<T>() {

      @SuppressWarnings("unchecked")

      @Override

      public int compare(T o1, T o2) {

        Comparable c1 = (Comparable) o1;

        return c1.compareTo(o2);

      }

    });

  }



  /**

   * 指定したComparatorをプライオリティ判定に用いるキューを作成する

   * @param comparator プライオリティ判定に用いるキュー

   */

  public PriorityQueue(Comparator<T> comparator) {

    this.comparators = new ArrayList<Comparator<T>>();

    this.comparators.add(comparator);

  }



  /**

   * 複数優先度を持つキューを作成する

   * @param comparators 第一優先度判定用Comparator、第二優先度判定用Comparatorといった形で並べる

   */

  public PriorityQueue(Comparator<T> ... comparators) {

    this.comparators = new ArrayList<Comparator<T>>();

    for (Comparator<T> c : comparators) {

      this.comparators.add(c);

    }

  }



  public T get() {

    Iterator<T> iterator = data.iterator();

    if (iterator.hasNext()) {

      T next = iterator.next();

      this.data.remove(next);

      return next;

    }

    return null;

  }



  public void push(T obj) {

    // 挿入時に末尾から前に向かって順に優先度判定をして、しかるべき位置に挿入する

    int i = this.data.size();

    // 第一優先度からループして、等しい値が現れたら次の優先度で比較

    comparatorLoop: for (Comparator<T> c : this.comparators) {

      // 末尾から前に向かって湯鮮度判定するから逆ループ

      for (;i > 0; i--) {

        T target = this.data.get(i -1);

        // 現在の優先度が等しければ、次の優先度での比較に移行

        if (c.compare(obj, target) == 0) {

          continue comparatorLoop;

        }

        // 優先度を超えそうな境目を見つけたら、そこが安住の地

        if (c.compare(obj, target) <= 0) {

          break comparatorLoop;

        }

      }

    }

    this.data.add(i, obj);

  }

}

複数通貨のMoneyをジェネリクスで作る

凪瀬 — Tue, 19 May 2009 00:54:00 GMT

Kanazawa.processではテスト駆動開発入門を読んで、テスト駆動開発を学びました。その本でのテスト駆動開発のサンプルとして挙がっていたテーマは複数通貨のMoneyを作るというものでした。

Dollarという米ドルを表現するオブジェクトを作り、Francというスイス・フランを表すオブジェクトを作り、そしてMoneyというオブジェクトに統合していくというリファクタリングの過程を経ています。

これをジェネリクスを使って設計したらどうなるでしょうか。

public abstract class Money<T extends Money<T>> { public abstract T add(Money<?> m); }

Moneyオブジェクトに演算用のメソッドadd()を定義します。引き算や掛け算など要求に合わせて各種用意するといいでしょう。

Money<T extends Money<T>> という型変数の宣言方法は自己言及するジェネリクスの稿で取り上げた手法です。add()の戻り型をTとしておくことで具象型自身の型を返させることができます。

これをDollarやFrancでオーバーライドして実装します。

public class Dollar extends Money<Dollar> { @Override public Dollar add(Money<?> m) { // ... } }

こうすることで、Dollarのadd()はDollar型で返るわけです。しかし、これだけだとDollarやFrancといった通貨単位ごとにadd()の実装を施さねばなりません。 protectedなファクトリーメソッドを用意して、オブジェクトの生成を具象型に委譲することでスーパークラスであるMoney型で統一的にadd()を記述することができます。

public abstract class Money<T extends Money<T>> { /** 為替レート */ Map<Class<? extends Money<?>>, Map<Class<? extends Money<?>>, Double>> rateMap; /** 値 */ protected double value; /** 加算メソッドの共通実装 */ public T add(Money<?> m) { double rate = rateMap.get(this.getClass()).get(m.getClass()); return getInstance(this.value + m.value * rate); } /** 具象型の生成 */ protected abstract T getInstance(double value); /** コンストラクタ */ protected Money(double value) { this.value = value; } }

こうした手法で通貨単位ごとに型を作って何が嬉しいかと言えば、ドル建てである場所にスイス・フランの型が紛れ込んだ場合にコンパイルエラーにすることができるという点です。

設計にはいろんな手法がありますし、それぞれにメリット、デメリットがあるので要求に合わせて柔軟に選べるようにしたいものですね。

Kanazawa.processで挙がった話題の補足

凪瀬 — Tue, 19 May 2009 00:19:00 GMT

Kanazawa.processというテスト駆動開発の勉強会が開催されたので参加してきました。話題に上がったネタの技術的な部分をいくつか補足しておきます。

副作用

この勉強会ではテキストとしてテスト駆動開発入門を用いました。第一章で出てくる「副作用」という表現。あまりにも一般用語然としていますが、プログラミングの専門用語として「副作用」と言う場合、状態の変更によって得られる結果が変わることを言います。 wikipediaにも副作用 (プログラム)という項がありますね。変数の破壊的代入というような言い方もします。

関数型言語では関数が副作用を持たない、つまり、同じオブジェクトを引数に渡したとしても、オブジェクトの状態が変わったことによってメソッドの呼び出し結果が異なる、といったことが起きません。そのために変数への代入は初期化のみが許されて、再代入(破壊的代入)は許されないという特色があります。

その利点にあやかるべく、値を表すオブジェクト（バリューオブジェクト）には Immutableパターンというデザインパターンが適用されることが多くあります。 Javaの標準APIでは、Integerなどのプリミティブ型に対するラッパー型や、BigDecimal型などがこうした設計になっています。これらは不変オブジェクトと表現されることもあります。

今のJavaには破壊的代入をコンパイラにチェックさせる機構がありませんが、JavaVM上で動作するScalaなど、関数型の流れも汲み入れた新しい言語ではこれをサポートする機構が存在します。 Scalaの場合は変数宣言にvarとvalというキーワードで再代入可能な変数と再代入不可の変数を使い分けることができます。 IT Proの記事がわかりやすいでしょうか。

また、Java7での拡張に含まれる予定のJSR 305ではバグを根絶するための各種アノテーションの提案がされています。マイコミの記事が詳しいですね。この候補として@Immutableというものも候補に挙がっており、Java7ではコンパイラでチェックできるようになるかもしれません。

不変オブジェクトとGC

Javaの理論と実践: パフォーマンスの都市伝説でも述べられているように、不変オブジェクトを用いることによって目に見えるようなパフォーマンスの劣化が起こることはありません。 90%のオブジェクトは作られてすぐに廃棄されると言われており、近年のGC(ガーベッジコレクション)は世代管理をしてこうしたライフサイクルの短いオブジェクトの回収を効率的に行えるように設計されています。

オブジェクトの再利用を行う機構を作ったとしても、不変オブジェクトの生成と破棄を行うスタイルと目に見えるほどのパフォーマンスの改善を得ることはなかなかできません。下手に頑張ったところで残るのは再利用や修正のしにくい醜い設計のプログラムだけです。

ソフトウェア品質の12の属性で取り上げたとおり、パフォーマンスチューニングによる効率性の向上のためには、柔軟性、相互接続性、保守性、移植性、信頼性、堅牢性、試験性、使用性が犠牲になります。そこまでの多大な犠牲と、パフォーマンスチューニングにかける時間、労力、そしてわずかばかりの効率性が釣り合うのかを冷静に判断してください。

大規模開発と静的解析

大規模特有の難しさと言うのは「人」が増えることによる開発の難しさなんですよね。多くの人が関わって作業をすると言ったときに、メンバーの技術的ばらつきは大きくなる。作業のやり方を統一することも難しいし、何より人間はヒューマンエラーを起こすのです。これを漏れなく拾うことの難しさ、そしてフィードバックして個々人をレベルアップさせることの難しさがあります。

まぁ、ぶっちゃけて言えば手が回らない。なので、人海戦術はやめにして、機械化しましょう。システム開発を機械化で高生産にするわけです。ビバ産業革命！

技術を持った人が注意深く作業する必要のある単純作業なんてのは、機械にやらせてしまいましょう。そう、リファクタリング機能です。EclipseやNetBeansには高度で信頼できるリファクタリング機能が搭載されています。静的な構文解析に裏打ちされた安定した機械的なリファクタリングを活用しましょう。

FindBugsプラグインなどの静的解析ツールによる機械的なコードレビューを活用しましょう。命名規約やフォーマットのチェックなんてのはCheckStyleプラグインで機械的にチェックしてしまいましょう。データ型の不一致をあぶり出す机上デバッグなんてやめて、ジェネリクスを使ってコンパイラでの静的型チェックをしましょう。

技術を持った人が注意深く、ヒューマンエラーと戦いながら退屈な単純作業をやらなきゃいけないなんてそんな低生産なやり方はガーベッジコレクションに回収させてしまいましょう。もっとも、頭の固いエライヒトがいつまでもそのやり方を参照しているとリークしていつまでも回収できないのですけどね。

java-ja富山

凪瀬 — Sun, 05 Apr 2009 23:25:00 GMT

4/4(土)に第十四回java-ja勉強会 - 第1回チキチキ地方巡業withひがやすを飲み会in富山を開催しました。遠路はるばる富山までスピーカーしにきてくださったひがさん、矢野さん、米林さん、ヨシオリさん、本当にありがとうございました。

凪瀬のジェネリクスの話

わんくま大阪でやったのと同じネタなんですが、時間を切り詰めてたので伝えたいところをうまく伝えられなかったかなぁと反省。

Javaのジェネリクスのややこしい部分は座学ですんなりわかるものじゃなくて、自分で四苦八苦してコード書いてみないと分からないわけですが、苦労してジェネリクスを学んだ先にはより設計の幅が広がって幸せになれるから是非学ぼうという話をしようという目論見だったのですけども、サンプルコードとかの説明とかがうまくやれなかったな、と。テーマの取捨選択が難しいですね。変な切り落とし方しちゃったかなぁ…。

矢野さんのアニメーションの話

詳しいメモを取っていなかったのだけど、たぶんこのへんの奴。Timing Framework。具体的にどれとかって話はきっと矢野さんがエントリを書いてくれるでしょう。

アニメーションの移動開始、終了間際の加速度の制御みたいな部分とか地味に面倒で難しいテーマ。書籍 Filthy Rich Clientsの第三部あたりの話題。矢野さんが言うには「あの本にはアニメーションは難しいから俺の作ったフレームワークを使え的なことが書いてある」とかなんとか。まぁ確かに。

自前で頑張ってチューニングを試みたらむしろ遅くなった、今のSwingはチューニングが凄いから下手に頑張るよりそのまま何も考えずに描画した方が速い、みたいな話をしていて最近の画像処理にはついていけないやと思った次第。自分はポリゴンとかの描画アルゴリズムとか勉強したことはあるけどパフォーマンスチューニングに凝ったことがないしなぁ。あちこちで聞くけども本当に近年のSwingは速いらしいよ。

ひがさんのAOPの話

今回はひがやすを飲み会（東京都、仙台市、札幌市に続く第４回目。参考記事）も兼ねているわけで、真打登場といった感じ。

Slim3あたりのAOPのえらくマニアックな話をして頂きました。自分は大喜びで食いついていたけど、他の参加者の人は大丈夫だったかしら。

AOPでのパフォーマンス向上のためのいろいろな工夫を聞いて感心することしきり。実行時に通るAOPのための仕掛けをいかに薄くするかという話で、実装方法論の部分で話題に上がってたのは確かClassLoader#defineClass() あたりでロード時に書き換える話とか、Javassist で継承クラスを作るとかの話かな。自分で実装してみたことないので間違ってるかもしれません。

自分はClassLoader#defineClass()でクラスロード時にウィービングする手法と、コンパイル時でのウィービングする手法ぐらいしか理解していなかったのでこのテーマの深遠さが覗けて興奮しましたね。

よねさんの１つめの話

JavaとAIRの間で通信したりする話。あとはJavaFXとかJavaScriptとかもあって相互に通信しまくり。こういう部分で何が可能なのかを知っておくことはトータルのシステム構成を考える上での重要な前提知識だと思うので非常に興味深く聞いていました。

そうそう、よねさんのAppletは起動が超速かったデスヨー（棒読み

ヨシオリさんのTDDの話

テスト駆動開発 (test-driven development; TDD)の話。テスト手法とかはコレという正解が確立されていない感じでみんながいろいろと模索しているようなテーマだから議論が盛り上がる、盛り上がる。ust中継してたので和田さんのツッコミとかもあって面白かった。

僕もテスト駆動のテストって品質を担保するテストだと思っていたクチなので、そういうテストじゃないんだという話に目から鱗。

「テスト駆動開発は宗教である」「コード＝神」とか名言が飛び交う面白いセッションでした。今日も誰かがモニタに向かって邪神を生み出そうとしてたりするのかな。

よねさんの２つめの話

T2とかの話。今日は相方の片山さんはいなかったけども SeasarConference2009Whiteのときのの話。僕はSeasarConのときに聞いてたのでテーマを復習した感じでしたね。

今回の失敗点

ust中継をやっていたのですが、Webカメラで写すとプロジェクタの文字が白飛びして見えない！その上、マイクが中継機になってたヨシオリさんのノートPCのマイクになってて音が凄く拾いにくい！

ustでの中継だと空間的な場を伝えるには便利なんだけど、勉強会とかでの資料とかは解像度的に全然読めないのが常。この辺どうにかならないんですかね。次会には機材としてマイクを準備しておきたいところです。

ボクシング変換とMapのキー

凪瀬 — Mon, 02 Mar 2009 21:59:00 GMT

今日はまったバグ。

Map<Long, String> map = new HashMap<Long, String>(); map.put(1L, "1"); System.out.println(map.get(1)); System.out.println(map.get(1L));

キーに1 (ボクシング変換でIntegerになる)を渡した場合と1Lを渡した場合で挙動が異なるというオチ。Map.get()の引数がObjectなので両方受け付けちゃうんですね。

再帰型のジェネリクス型変数の境界

凪瀬 — Fri, 23 Jan 2009 23:45:00 GMT

先日ジェネリクスで引っ掛かった点をメモ。

自己言及するジェネリクスで述べたような具象型に具象型自身の型を扱わせることをもくろんだ型を作った場合の話。

public class GenericsTest { static abstract class S<T extends S<T>> {} static class A extends S<A> {} static class B extends A {} static class C extends S<A> {} static class X1<T extends S<T>>{} static class X2<T extends S<?>>{} static class X3<T extends S<? super T>>{} public static void main(String[] args) { X1<A> x1A; // OK X1 x1B; // NG X1<C> x1C; // NG X2<A> x2A; // OK X2 x2B; // OK X2<C> x2C; // OK X3<A> x3A; // OK X3 x3B; // OK X3<C> x3C; // NG } }

Sが親となるクラスで<T extends S<T>>という境界をもつジェネリクス型変数Tを持ちます。サブクラスであるAはこのTにA自身を渡すことで、Sクラス中にT型で宣言した部分をA型にすることができるのですね。

そのA型を継承したクラスBを考えた場合、BはS<A>を継承しているのでB extends S<A>ということになります。なのでX1の境界<T extends S<T>>に合致しません。

こうした型を受け入れれるように規制を緩めたのがX2で<T extends S<?>>としています。この場合、穴ができてCのようなAのサブクラスでもないのにSの型変数TにAを渡したような歪なクラスを宣言した場合に許容されてしまいます(x2C部分)。クラスS中に表現されるTを具象型自身にするという趣旨からすればこのような歪な型は許容したくありません。 T型の戻り値のメソッドでreturn this;とか書きたいわけです。

なので正確に型を表現するとしたならば<T extends S<? super T>>とします。これでAはもちろん、AのサブクラスであるBも許容され、歪なCは弾くことができます。

次世代のカプセル化手法

凪瀬 — Wed, 07 Jan 2009 21:48:00 GMT

「interfaceに物申す」 (1) (2) (3) は、public, protected, privateといったアクセス制御の修飾子によるカプセル化の限界を憂いたものです。

そもそもこれらの修飾子はクラスを境界としたカプセル化であるため、デザインパターンなどクラス群で表現されるモジュールの内外の境界でのカプセル化には無力です。 Javaではパッケージプライベートというアクセス制御レベルも存在しますが、モジュール境界とパッケージ境界を一致させることが現実的ではないことはご周知のとおりです。こうしたクラス群で表現されるモジュールに対して、カプセル化を行うための新たな機能が求められているわけです。

そこでスーパーパッケージ(superpackage)という概念が提唱されました。これはJSR 294として仕様の策定が行われており、Java7で搭載される見込みです。 (http://www.infoq.com/news/2009/01/java7-updated参照)

スーパーパッケージについては http://journal.mycom.co.jp/articles/2007/05/13/superpackage/ が比較的詳しいかと思います。

ジェネリクスの代入互換の補足

凪瀬 — Sun, 04 Jan 2009 18:06:00 GMT

ジェネリクスの代入を理解するその２に以下の質問を頂きました。

インタフェースIFをAが実装しているとし、
A←B←Cの関係はそのままの場合で下記処理をコンパイルしたとします。
List<? super B> list = new ArrayList<IF>
list.add(new B()); //1
list.add(new A()); //2
list.add(new C()); //3

この場合も2はエラーとなってしまいます。
ArrayList<IF>にAをaddしても矛盾しないと思うのですが、
これは何故なのでしょうか？？

変数list はList<? super B>型ですから、ArrayList型を代入することができますよね。

List<? super B> list = new ArrayList<IF>(); list = new ArrayList(); list.add(new A());

としたらどうなるでしょうか？
ArrayListにAをaddすることになりますね。落ち着いて考えてみてください。List<? super B> list = new ArrayList<A>();のケースと同じです。

コンパイルによる静的な型チェックは、いつ変数listにどういう型を代入されたかを追跡しません。
なので代入して矛盾が発生する可能性がある場合にすべてコンパイルエラーとします。

古いエントリになりますが、ジェネリクスと代入と落とし穴2も併せてご覧ください。

わんくま同盟富山勉強会レポート

凪瀬 — Wed, 12 Nov 2008 01:10:00 GMT

11/8(土)にわんくま同盟富山勉強会が開催されました。

参加いただいた皆様、スピーカーを引き受けてくださった皆様、ネットから視聴していただいた皆様、どうもありがとうございました。

Wicketで変わるウェブ・アプリケーション開発

矢野勉氏のWicketのセッション。私が忘れ物をしたせいで、セッション時間を入れ替えてもらったという経緯あり。そんなわけで、自分はほとんど見ることができなかったのが悔やまれます。

RIAことはじめ

3月まで自分一緒にプロジェクトをやっていたhikaru氏に頼んでFlexの紹介セッションをやってもらいました。初スピーカーで緊張気味でしたが、セッション狙い（「Flexで作ったアプリは簡単なのにリッチだ!!」といった部分を伝える）は達成できたんじゃないかな。

おひるごはん

私を含む8人で県民会館から少々歩いたところにあるうどん屋（本当は蕎麦屋なんだけど、最近蕎麦を出していない）「鶴喜」にて。富山の名店。平日と土曜の昼しか開いていないのでなかなか食べに行けない。

Javaのこれまでとこれから

本当は最初にやるはずだったセッション。この日の勉強会の各種セッションの土台となる部分を統括的に。Javaの歴史のおさらいと、最近の方向性を提示して、各セッションで具体的なところを見てもらうというつもりだったのですが。

最近は、システム開発の環境改善には経済的側面をちゃんと考えないとうまくいかないよというのを痛感しているので、そちらの比重が高めにしてみました。

部屋移動

会場の都合で連続して部屋を確保できなかったので部屋移動が入ってしまいました。後半の部屋の方が椅子とか座り心地が良かった。富山県民会館を使うなら7Fの部屋の方がグレードが高いよ！

ライトニングトーク

katzchang氏によるプログラミング言語Ioの話。言語としてなかなか面白そう。

daisuke氏によるメールサーバの管理の話。スパムのリレーが多くて挙句スパムのブラックリストに載せられてしまった！スパム対策どうしよう！といった話題。スパム対策は本当に頭の痛い問題です。

矢野勉氏が飛び入りで１つやってくれました。業務で使うちょっとしたツールもJavaで書いちゃうぜってときに短く楽に書くためのコツみたいな話。潔い割り切りが重要。時間が余って晒し者タイムになったのでjava-jaでのLTの雰囲気とかそんな話も少々。

JavaからScalaへ

keisuken氏のScalaセッション。と見せかけて本題は氏の開発するWeb Flavorだったりしたセッション。手続き型のプログラム言語しかやったことない人にはかなりのデカルチャーだったのではないでしょうか。自分もチャンスがあったらScalaを採用したいなぁ。

やっぱAppletやちゃ

米林正明氏によるセッション。Java SE6 update10のドラッガブルアプレットとかそのあたりの話題。(参考：Java SE6 update10 を使って Applet で遊ぶ！)

これはデモのインパクトが大。会場が沸きました。JavaScript - Applet間での呼出しは実務でも応用が効きそうですね。注目すべき技術の一つでしょう。

なお、タイトルの語尾「～やちゃ」は「～だよ」の富山弁表現。氏は富山の出身だそうで、今回の勉強会もスケジュールの厳しい中駆けつけてくれました。感謝！

懇親会

近くのお店に移動して懇親会。掘りごたつ型の座敷だったんだけど、席移動がしにくいのが難点かな。各所で話が盛り上がっていたのはいいのだけど、話す人が偏ってしまいましたね。

1.5次会

数名はラーメンの富山ブラックの大喜（富山駅前店）に吸い込まれていきました。県外の人は一度食べておくと話のネタになるかもしれない。個人的には、一度だけでいいんじゃないのとも思う。

2次会

白馬館という老舗バー。富山駅前の近くなので、電車やバスなどの人がいる場合には最適。自分は思い切り面が割れているので悪いことはできません。えぇ。

3次会

代行運転を捕まえて凪瀬邸へ。矢野氏は前日からの疲れからか付いた早々に爆睡。もうひとりのメンバーkeisuken氏としばらく話をして就寝。

翌日

朝に二人を送って富山駅へ。お土産を購入。富山の黒作り（イカスミ入りのイカの塩辛）を勧める。関西方面のkeisuken氏を見送った後、東京方面の電車の発射まで時間があったので矢野氏と朝食。話し込んでいたら時間ぎりぎりになってしまった。無事に乗れたようでなにより。

月曜日

気が緩んだのか風邪をひいたらしく、寒気がしてヤバい。夕方に早退して実家で養生。レポートが遅れてすいません。

今週末は富山勉強会#1

凪瀬 — Thu, 06 Nov 2008 01:29:00 GMT

いよいよ今週末土曜日がわんくま同盟富山勉強会 #01です。

場所は富山県民会館です。当日参加も可能ですが、出来るだけ事前登録をお願いします。

10:40 ～ 10:50 わんくまについて
10:50 ～ 11:40 「Javaのこれまでとこれから」凪瀬悠輝Lv2くまー
11:50 ～ 12:20 「RIAことはじめ - Flex-Javaで簡単なアプリを作成してみる -」hikaru
12:20 ～ 13:20 おひるごはん♪
13:20 ～ 14:20 Wicket関連矢野勉
14:20 ～ 14:50 部屋移動
14:50 ～ 15:20 ライトニングトーク

katzchang
daisuke
スピーカー募集中！

15:20 ～ 16:10 「JavaからScalaへ、ScalaからJavaへ(仮)」keisuken
16:20 ～ 17:10 Teeda、Applet関連米林正明
17:40 ～懇親会

わんくま勉強会全般がそうですが、懇親会がメインです！

いろんな人といろんな話ができるのはこうした勉強会の大きなメリットですね。懇親会に参加される方はお店の予約の関係もあるので、できるだけ早く登録をお願いします。