JDK1.7でClosureが復活するみたい

InfoQの記事によると、JDK1.7でClosureが復活、ただしリリースが延びるとのこと。

JDK1.7のリリースが延びるのは残念ですが、まだ業務的にはJDK1.6の普及もまだまだですので、せっかくのメジャーリリースにClosureが採用されるほうが嬉しいです。

Closureも Simple がついたということで、何が変わったのかと Closureの仕様を見たところ、若干、表記の仕方が変わったみたいですね。

定義と処理が分割して、Lambda記法の結果の型が後ろから、前に移動して、よりJavaプログラマがわかりやすい記述を採用したのですね。

旧： {int,int=>int} plus = {int x, int y => x+y};

新： #int(int,int) plus = #(int x, int y) x+y;

個人的には、"#"を使うとプリプロセッサを使ったコードと相性が悪いため

あと今更ながら気がついたのですが、1つしかメソッドをもたないInterfaceにも Closure を適用できるのは、いままでのライブラリを、そのまま利用できるので良いですね。

これに関してひとつ疑問がでてきました。

Closure間の型変換ってどうなるなるんだろう？

擬似コードで書くと、次の２つのクラスの内部に定義された、funcのクロージャー形は、コンパイルされると別のクラスになると思います。

class A {
   #int(int, int) func;
}

class B {
   #int(int, int) func;
}

これらの間で、コンパイラでラッパークラスなど作られると、コンパイル後のクラスは異なります。

Closureの場合、クラスの内部変数にもアクセスできるからクラスが分かれるのはしかたないのですが、関数オブジェクトとして使いたい場合、シグネイチャーが一致していると型を一致させてほしいですよね。

あ、外部に公開して共有する場合はinterfaceを書けってことなのかな。

それは、それでありだな。

まだ情報がでてきたら、そのときチェックしよう。

Lenovo Enhanced Experienceを体感してきました。

Lenovo Enhanced Experience搭載のThinkPadを触ってきました。

X200sで電源ONからWindows ７が起動するまで20秒くらいでした。

比較対象となる機器がなかったので、相対的にどのくらい早くなったのか判断できませんが、HDDでこの速度なら十分です。

いまだと、いくらで購入できるのだろうかと、久しぶりにLenovoのサイトにアクセスして、カスタマイズをしてみると、拡張保証もちゃんと選択できるようになっています。
保証のオプションが選択できないと苦情のメールを出した効果が多少はあったのかな？

けっこう価格もこなれていますが、キャンペーンのときよりは若干高く感じますし、ThinkPadのロードマップによると、1月に新機種がでるようです。

もう少し待とう思います。

Pocket WiFi を見てきました

Pocket WiFiが置いてあったので、触ってみました。

第一印象はポケットマウスです。

ポケットマウスで通信っ何だろう？と思って、近寄ってみたらPocket WiFiでした。

これだけ小型だと、カバンに入れて持ち歩いても邪魔にならないでしょうね。

ガジェットが増えるたびに回線の契約を増やすほど、豊かな人は少ないので、小型で携帯可能な無線LANルータは、現時点での一つの解なんだろうなと思います。

まだWillcomの回線もあるため、いますぐ必要というわけではありませんが、iPodTouchを利用していると常時接続ができる環境は惹かれます。

PersonalWiressRouterも年内発売という噂もあるため、しばらく様子見ですかね。

MySQLのInsert or Updateについて

RDBを使っていると、データがあれば更新、なければ追加という

処理を行いたいことがあります。

素直に処理を書くと、以下のようになります。
(1) SELECT してレコードの存在チェック（必要に応じて行Lockも行う)
(2) レコードが無ければ INSERT
(3) レコードがあれば UPDATE

ORACLEの場合、mergeという命令をつかうと、この処理を1つのでSQLで書けるため便利です。

# MySQLにあるmergeはテーブル結合の命令なので、意味が異なります。

MySQLでも同様の命令として、insert on duplicate key update や、replaceという命令があります。
# 2つのSQLの違いは省略します。

しかし、oracleのmergeと異なり、mysqlの命令は制限が強く限定的な使い方しかできません。

Oracleの場合、対象レコードの検索をかいて該当レコードがあった場合と、無かった場合で、場合分けをして処理を記述できます。

しかし、MySQLの場合、INSERTを行い、結果として、PKもしくはUKで重複エラーとなる全てのレコードに対して、データ更新処理が実行されます。

そのため、MySQLの命令はPKもしくはUKが1個しかないときしか、insert or updateで期待した動作はしてくれません。

MySQL流だと、テーブルのPKは連番、業務的なPKはUKで定義し、それ以外はUKは定義しないという設計をするのかな？

PocketInformant9にUpdate

PocketInformant9にUpdateしました。

いま使っている、PocketInformant8で不満は無かったですし、iPodTouch版のPocket Informantも使っているため、W-ZERO3の将来次第ではWindows Mobile版は使わなくなるかもしれませんが、応援も含めての投資です。

PI9になって微妙にインターフェイスが変わっているように感じますが、新しい機能を使っているわけでもないため、いまのところ特に不便は感じていません。

ただ、すこし気になったいるのは月間スケジュールです。

僕は月間スケジュールはテキスト表示させているのですが、一部を選択したときの表示内容がテキストではなく、時区間のチャート表示されてしまうことです。

PI8のときはテキスト表示できていましたので、どこかに設定があると思うのですが、見つけ切れていません。

もともと一部選択表示の機能は使ってなく困らないのですが、操作ミスで一部選択してしまうことが多かっただけに気になりました。

これを機会に、設定の調査を兼ねて、使っていない機能も試してみますかね。

MySQLのCHAR型は後ろのスペースが削除される

いまの仕事で、MySQLのCHARは後ろのスペースが削除されるという仕様が問題になりました。

バージョン5からはVARCHARの後ろのスペースは削除されなくなったようですが、バージョン4まではVARCHARの後ろのスペースが削除されます。

CHAR型はバージョン5になっても後ろのスペースが削除されます。

ほとんど場合は後ろのスペースは削除されていても問題無いし、むしろ削除されてくれたほうが有難いのですが、それだと困る場合があるのですよね。

すこし調べたところ、TEXT型だと後ろのスペースが削られないようなのでデータ型変更だけで対応できるか確認してみようと思います。

しかしMySQLを使っている人には常識なのでしょうが、他のRDBと異なるため見落としていることで、あとから問題となることが多いです。

ノウハウを貯めていかないとな。

Google App Engineを始めました

Google App Engine for Java を購入したので、JavaでGoogle App Engine (以下、GAE/J)を始めました。

内容もわかりやすく、GAE/JのEclipseのPluginも素晴らしく、動作確認はサクッとできました。

久しぶりの Servlet の作成ということもあり、日本語の文字化けに悩まされたりしたりしました。しばらく触っていないと、忘れちゃいますね。

いまのところ興味をもって調べているのが、BigTable です。

BigTableには、以下のような特徴があります。

(1) RDBのテーブルに対応するはKindと呼ばれている。

(2) Kindのレコードは、Key-Valueストア形式でデータを格納されている。
    各レコードは、Keyで特定できる。

(3) データがKey毎に分散されて格納されることが前提としている。

(4) データが分散して格納されていることが前提となるため、データ操作はレコード単位でのAtomic性のみ保証される。複数行のトランザクションは保証されない。

(5) レコード単位での操作でしかトランザクション処理では制限が厳しいため、
     親子関係のあるキーについてはエンティティグループという概念を用いることで、
     同じノードでデータを保存することで、
     エンティティグループについてトランザクション処理を行うことができる。

(6) データの登録／更新よりデータの読み込みのほうが早い設計がされている。

サンプルとして書かれていた、分散カウンタは(6)の特性をいかした発想から作られており、RDBでは思いつかない発想だけに目から鱗でした。

次のようなアルゴリズムで分散カウンタが実現されています。
(1) カウンタを一カ所にするとロックに時間がかかりスケーラビリティが無くなるため、N個に分散させてカウンタを持つ。

(2) ランダムに選んだカウンタを選択して、選んだカウンタを更新する。

(3) 全てのカウンタ値の合計を、カウンタ値とする。

(3)の全てカウンタ値を取得して合計をとる計算がボトルネックになりそうですが、BigTableの読み込みがデータの量に関わらず、一定の速度でアクセスできるという特性から実現できるようです。

ただ、トランザクションがテーブル全体に対して適応できないなどあり、データ一貫性としては、見えないところがあります。

いくら早いとはいえ書き込みと読み込みの間に時差があるのであれば、同じカウンタ値を得ることがあるんじゃないかなと、気になっています。

ホームぺージのアクセスカウンタぐらいでしたら、たまたま同じ値になっても構わないでしょうが、RDBのPKを作るときのシーケンスの代わりには単純には使えないから工夫が必要だなと、色々と気になることもあります。

ただ、Googleのシステムは、BigTable上に実現されていることから、色々とノウハウがあるのでしょう。

これからも勉強です。

MySQLのUPDATEの実行順番対応

前回、MySQLのUPDATE文に実行順番があり嫌だなというという文章を書きました。

殆どのUPDATE文は書き換えで対応できると思えますが、
２つのカラムの間の入れ替えをできないなど基本的な機能が不十分なところに、
引っかかりや、使いたくないなという感じていました。

各種ドキュメントを読んでいたところ、MySQLでは、UPDATE文でJOINを使えることがわかりました。

変更前と変更後で同じレコードだから実行順序が問題となるいうのであれば、

自分のレコード自身を結合すれば、変更前のレコードを確保できるのではないかと思い、
試してみたところ～

うまくいくようになりました。

こんな感じです。

【通常のUPDATE文】
UPDATE テーブル
      SET カラム1 = カラム2,
            カラム2 = カラム1
WHERE キー = 1

【MySQL用に書き換えたUPDATE文】
UPDATE テーブル T1
  INNER JOIN テーブル T2
      ON T2.キー = T1.キー
    SET T1.カラム1 = T2.カラム2,
           T1.カラム2 = T2.カラム1
WHERE T1.キー = 1

まだ制限として1レコードを特定できるカラムが無いテーブルでは使えないというがあります。

ただＰＫが無いテーブルは殆どありませんし、PKが無いテーブルは使い方も特殊なので、あまり問題とはなりにくです。

ただ、だいぶ複雑になるため、どうしても書き換えができないときの最後の手段とします。

MySQLのUPDATEには実行順番がある！

初期のMySQLには外部結合ができないなど色々と制限があり、好きではありませでした。

いまの仕事の関係で、MySQLを使い始めたのですが、外部結合などもできるようになり、なかなか良いじゃんと思っていましたが・・・

なんとUPDATE文のSET処理に実行順番があるのです！

たとえば、次の2つのSQLで実行結果が異なるのです。

[SQL-1]
UPDATE テーブル
      SET C1 = C1 + 1,
             C2 = C2 + C1
  WHERE PK=キー

[SQL-2]
UPDATE テーブル
      SET C2 = C2 + C1,
            C1 = C1 + 1
  WHERE PK=キー

通常のRDBMSではSQL-1とSQL-2とで同じ結果となるのですが、MySQLでは実行結果が異なるのです。

UPDATE前の値を、C1=1, C2=10とします。

[SQL-1]では、先にC1を計算するため、C1+1 → 1 + 1 → 2となります。
次にC2を計算するため、C2 + C1 → 10 + 2 → 13となります。
結果は、C1=2, C2=13です。

[SQL-2]では、先にC2を計算するため、C2+C1 → 10 + 1 →  11となります。
次にC1を計算するため、C1 + 1 → 1 + 1 → 2となります。
結果は、C1=2, C2=11です。

これに気がつかなくて、びっくりしました。

参考までに、通常のRDBMSでは、上のSQLは次のように解釈されます。
C1 = 変更前C1 + 1
C2 = 変更前C2 + 変更前C1

そのため、結果は、C1=2, C2=11となります。

この例の場合、[SQL-2]と同じ結果となるため、期待した結果を得ることができるのですが、一般論として全てのUPDATE文を書き換えるのは難しいです。

たとえば、C1とC2を入れ替えるUPDATE文は、MySQLではできません。
UPDATE テーブル
      SET C1 = C2,
            C2 = C1
  WHERE PK=キー

工夫すれば方法はあるかもしれませんが、いまのところ必要としている箇所では書き換えができたので、必要に応じて調査するつもりです。

なんにせよ他のRDBMSと、MySQL間でSQLを移植するときに、UPDATEについては注意が必要。

まだ、他にも独自仕様がなければ良いのですけどね･･･

iPhone 3GSを触ってきました

iPhone 3GSを触ってきました。

アプリの起動など、けっこうキビキビうごきます。

２倍速くなったかはわかりませんが、あきらかに早くなったのがわかるだけに、おぉ～といった感じでした。

いまの iPhone 3Gで満足なひとは良いでしょうが、もっさりしているという人は買いでしょうね。

また新しく購入予定の人には、よほどのことがない限り、iPhone 3Gsを購入すべきでしょう。

個人的には、iPod Touchを買って以来、どこでもつながるという点ではiPhoneには興味があるのですが、まだ様子見です。

経済的な事情が一番の理由なので、PCとの通信ができるようになるなど付加価値も含めて待っています。