関ジャバカンファレンスにいってきた

Java

ここ７−８年はJavaしか書いていなかったのに、めずらしくこの１−２ヶ月Java書いてません！が、行ってきました。関西Javaカンファレンス。Javaの動向が知りたい、というより、いつもこっそりフォローしてすごいすごいと思っているスピーカの顔を拝みにいくのが一番の目的でした。

相変わらず、自分向けメモ的な感想です。

  • JavaSE 7 Concurrent Utilsがよさそう。
  • JavaSE 7 NIO2もかなり期待する。
  • 8のモジュールにもかなり期待。ただ、リポジトリはmavenがかなり先攻／整備されているので、それが使えるようになるといい、なあ、と思っている
  • でもmavenはあんまり好きじゃない
  • JavaSE7対応のScalaとか、でてくるのいつくらいなんだろう。楽しみ。
  • 「Javaの人はEnterpriseの方が得意だから、GAEはGoogle Appsと組み合わせて企業向けアプリを作るためのプラットフォームととらえたらどうだろう？」というのはちょっとこころにくっときた。
  • NetBeans使ったことない。でもさすがOracle製、Java書くならいい選択肢か。
  • JSF、つかったことない。検討もしたことない。
  • マイベストは、JavaFX 2.0だった。仕事とは全く関係ないし、使うことも（たぶん）ないだろうけど、ぜひぜひ試してみたい。
  • @skrbさんがtwitterのアイコンと似すぎてて驚いた。
  • @tksmd　は、なんか、しゃべりなれてきたな（謎の上から目線）
  • JavaEE 6 というか、JavaEEは、過去をさかのぼってもつかったことない。かれこれ７−８年Enterprise向けのシステムをJavaでつくっているというのに。
  • でもそういう人多いんじゃないかなー。JavaといえばStruts + Spring + Hibernate 。だから、JavaEE6 の比較は、JavaEE 5やその前じゃなくて、SSHとしてほしい、なあ。1.4のEJBとか、本のなかの出来事でしかしらないので、ピンとこない
  • そして、気になったのは、JavaEE6のテスタビリティ。昨今のフレームワークは、どんなものでもかならずテスト用のフレームワークもついている。ので、JavaEE6　や、それのリファレンス実装のGlassFishには、テスト用のフレームワーク、ついているのかなあ、と。そのあたり、テスト環境との切り替えが簡単にできたり、というのがないと、やっぱりちょっと（導入は）つらい。
  • あとドキュメントの量も結構気になります。プロジェクトによっては日本語情報少ないものは、適用つらかったりする。
  • でもGlassFishは評価してみたい。
  • そしてGlassFishとTomcatの比較の話をしているときの寺田さんの勝ち誇った顔はわすれられない
  • でも起動はjettyの方がはやそう。
  • LTいけなかった。聞きたかった。
  • 積ん読がなくなったらGroovyに手を出そうと思っている。
  • おみやげもらいそびれた。
  • のみものただだった。Oracleは太っ腹だなあ。

実はいままでJavaSE7もJavaEE6もあまり追えていなかったので、とても有意義でした。JavaSE 7 とGlassFish 、試してみます。。

スピーカの皆様、運営のみなさま、本当にありがとうございました。

IntelliJに乗り換えた

IntelliJ

最近はIntelliJ に乗り換えましたが、EclipseでできていたことがIntelliJでできなくて、もやもやしてました。
でも、それも昨日までの話。調べてみたら普通にIntelliJでもできました。そりゃそうですね。

まず、そもそもScalaの設定ができてなかった。FacetでScalaを追加しなきゃいけなかったのがしていませんでした。どおりで。追加したら、ScalaTestがIDEで動くようになりました。１ヶ月私は何をしていたんだ。。

次です。Eclipse(Emacs キーバインド)使いの私は、使っているショートカットはほーーーんのわずか。そのわずかがわからなくて、いらいらしてましたが。

  • 補完 = 変わらず Alt + /
  • テスト実行　= Ctrl + Shift + F10
  • テスティングペアに飛ぶ　= Ctrl + Shift + T
  • F3(宣言に飛ぶ) = Ctrl + Alt + G
  • 型検索 = Alt + Shift + G
  • フォーマット　= これはMappingされてなかったので、Command + Shift + F 自分でマッピング

うん、これでいきていけそうだ。。

sbtでつくったjarを公開して、Play!のウェブアプリケーションに依存関係を設定する

Scala Play! sbt

毎日まいにち、地味なビルド回りとかに異様に時間とられてますが楽しいです。

さて、題名通り、共通ユーティリティ的なjarをつくって、あっちこっちのPlay!アプリケーションで使い回したい、というときに。
まず最初の（はまり）ポイントは、「PlayのdependenciesはIvyのローカルリポジトリをみていないようだ」というところです。mavenの公開リポジトリしかみていないので、あきらめてsbtでどこかのmavenリポジトリにpublishして、Play! にリポジトリと依存jarの設定をします。

　sbtでのpublishですが、正当派の手順はhttp://code.google.com/p/simple-build-tool/wiki/Publishingに書いてあります。会社の社内リポジトリへ公開するには、CIサーバ上でmvn installするのが唯一の方法！なので、私はかなり変則的にこう設定しました。

  • CIサーバ上で、sbtビルド、公開
% sbt package 
% sbt make-pom
% mvn install:install-file  -Dfile=target/scala_2.8.1/some_2.8.1-1.0.jar -DpomFile=target/scala_2.8.1/some_2.8.1-1.0.pom
  • Play!のdependencies.ymlの設定
require:
    - play
    - play -> scala 0.9
    - com.example -> some_2.8.1 ]1.0,)


repositories:
    - localRepo:
        type: iBiblio
        root: http://ciserver/maven2/repository
        contains:
           - com.example -> *


これで、Play! webアプリケーション側でplay dependencies --syncと実行すればjarを引っ張ってきて依存関係の設定をしてくれます。

ただ、開発進行中のこの時期、ちょっとした問題が。バージョン番号が変わらないと、Play!は依存するjarの更新してくれないらしいのです。libにあるファイルを消してもだめで、レポジトリに登録した新しいものではなく、Ivyのキャッシュにある古いjarをlibに引っ張ってきます。当たり前といえば当たり前ですが。ということで、sbtのビルドごとに、バージョン番号を変えるようにします。

project/build/以下にあるProjectファイルに以下を追記します。

  override def version = BasicVersion(1,Some(System.currentTimeMillis().toInt),None,None)

もうちょっといい方法がある気がするけど。で、ビルドごとにバージョン番号が異なるので、ビルドが変わるとplay dependencies --syncでjarが更新されるようになります。

早くビルド、環境回りのことが落ち着きますように

Postgresql のTimezone

Postgresql

PostgresqlのTimezoneについての調査メモ

  • with Timezone型のものは、内部的にはUTCで保管されている
  • 表示時に、timezone設定パラメータの値を参照し、そのTimezoneの日時に変換する
  • insert 時にTimezoneを指定可能。これはUTCで入る
insert into test_timestamp values (TIMESTAMP WITH TIME ZONE'2011-01-01 00:00+02')
insert into test_timestamp values ('2011-01-01 00:00:00+02');
  • 出力時にTimezoneを指定する。AT TIME ZONEでできる。
select TIMESTAMP'2011-01-01 00:00:00' AT TIME ZONE '+0';


そうか、そういう感じですか。やりたかったことはできそうです。

QCon Tokyo に行ってきた。

インプットが多すぎて消化するのに時間がかかってしまいましたが、印象に残ったことを記録します。内容を知りたい人は、リンク先などを参照してください。（そもそもいちびって同時通訳使わずに英語で聞いていたので、誤解もいっぱいしている気がしますが。。）

大きなテーマはやはりDDD。印象的だったのは以下の点。

モデルは複数存在し、利用目的により異なる

モデルは最初に完璧なものなどできない。継続して改善していく。

モデル、コードだけでなく、シナリオも継続して改善していく。そして、シナリオも開発していくもの

また、「なぜDDDを適用するのか」という問いに「それがビジネスを本当のゴールに一番速くたどり着く方法だから！」と言い切ってました。ただ、設計やリファクタリング、きれいなコードって、追加開発や不具合修正の段階になって、はじめて効いてきますね。SIでシステム売り切り、という商売をしている場合、SIer（の上の方の方々）には「きれいな設計」っていいことないから関心もてないのかなあ、と悶々としてました。
　ただシステムを利用する企業や、うちみたいなサービスを提供していて、そのサービスの付加価値をどう高めていくかが重要な商売の場合、やっぱりきれいな設計は死活問題。実はお客さん企業こそ、DDDというような手法で取り組んでくれるSIerを選んだ方がいいんじゃないのー、と思ってました（人ごと）
　私はもう少し自社のビジネス領域について勉強しないとなあ。。あと、最初から完璧なモデルをつくろう、とするところや、最初のモデルに固執してしまうところはやめよう、と思っています。といいつつも、いくら分離して設計しても、モデルの変更はインフラの変更を伴う可能性が高いし、なかなか継続して改善したり、作り替えたりできないよなあ、現実問題どうするんだろう？？と思いながら聞いていたんですけどね。

　また、レガシーシステムに追加開発する場合のデザインパターンの話も。「一からつくりなおすのじゃ時間がかかりすぎる。だけどいくらリファクタリングしていっても全く新しい思想はシステムに追加できない。」という話。いかにも陥りそうなバッドパターンですよね。いや、作り直したくなるし、「生まれ変わらないとできません」っていいたいエンジニアの気持ちをぐさりとつかれました。「レガシーのいいところをみつけて活かそうよ！」って、そうしよ。

もう一つ、よかったのがマイクロソフト萩原さんのセッション。HadoopのMap/Reduceのような設計の勘所を説明してました。



現代のデータ設計は、分散処理できるデータ構造とその処理方法の設計も含まれる

のようなことをおっしゃてて、また勉強すること増えたぜ！と思ったものの、自分で試行錯誤せずとも先駆者の成果にいろいろあっててに入りそうな感触を得たので、これからどっぷりアルゴリズムなどを学んでいこうと思っています。「並列数を増やすのは最後、その前に処理の方式を変更することによりもっと速くできる」みたいです。

他にも、Twitterの若いおにいさんが、Ruby　ガベージコレクタを自作した話とかしてましたが、かっこよかったがついていけなかった。。精進し直します。。

そして、ここ４、５年、17:00くらいまでしか仕事してないので、18:00すぎると頭わいてきて、最後のパネルディスカッション全然きけてなかった。そんな湧いた頭にも飛び込んでくる、エリックさんの言葉。

そう、プログラマは圧倒的にビジネスの話をしたりないんだと思うんですよね。でも実装するのに必要だから、細かいことききたい、よなあああああ

日帰り東京久しぶりだったけど、子連れじゃないとこんなに新幹線って快適空間なのかあ、と思いましたよ。家族に感謝。今年の東京遠征はこれで終わりにします。

PUT/DELETEをいっぱいするときの注意

HBase

昨日もいったようにHTableは、マルチスレッド非対応です。じゃあ、とスレッドごとにHTableインスタンスを生成すると、それごとにHBaseのコネクションが作成さられてしまうので、そりゃもう遅くなるわ、メモリも不足するわ、たいへんな騒ぎになります。

そういうときは、Configurationを共有しましょう。Configurationを１個にすれば、コネクションはひとつを使い回すようになります。と、Javadocに書いてありました。実際、ログをみるかぎり、ZooKeeperへの接続が使い回されるようになりました。

また、put/deleteをいっぱいする場合は、put(Put)を複数回実行するより、put(List)でやる方が、断然速いです。ソースみると、flushCommitsという大事だが重そうな処理がputメソッドを１回実行ごとにやっているから、そのせいでしょう。

Maven 3.0 ではsiteの設定方法が変わっている。

maven

カバレッジを取得、表示するためのcoberturaの設定。2.0 まではreportingに設定していましたが、3.0からはmaven-site-pluginのconfigurationで設定します。ローカルはmaven3、だけどJenkinsはmaven2を使っているので、両方で動くようにmaven3用のプロファイルを作成しました。

    <profile>
      <id>maven-3</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-site-plugin</artifactId>
            <version>3.0-beta-2</version>
            <configuration>
              <reportPlugins>
                <plugin>
                  <groupId>org.codehaus.mojo</groupId>
                  <artifactId>cobertura-maven-plugin</artifactId>
                  <version>2.4</version>
                  <configuration>
                    <instrumentation>
                      <excludes>
                        <exclude>com/hoge/**/*Test.class</exclude>
                      </excludes>
                    </instrumentation>
                  </configuration>
                </plugin>
              </reportPlugins>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>

javadocなど、reportingに設定していたプラグインは、すべてconfiguration以下に移動する必要あり。でも、一部maven3に対応していないreportingプラグインもあるので注意が必要。maven 3.0はmaven 2.0と完全互換、って書いてあったのになあ。英語読み間違えたかな。

https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html