Hatena::ブログ(Diary)

しんさんの出張所 はてな編 このページをアンテナに追加 RSSフィード

カレンダー
2007 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2015 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 |
2016 | 05 | 08 | 10 | 11 | 12 |
2017 | 01 | 02 | 06 | 08 | 11 |
2018 | 02 |

2008-11-30

[]930SHをしばらくさわってみた使用感

予想通りやはり気軽に使えるようになったというところが大きい。910SHではレンズがくらいので白とびや黒塗りが多発していたが、この機種はそれがない。

910SHでは少しでも明るいと白とびを防ぐためにNDフィルタがすぐにはいってしまい、普通の明るさでもF値が10をこえるとかすごいことになっていた。それをいかに抑えるかが910SHユーザーのテクニックの見せ所で、ズームを入れてF値調整したり(おいらが提唱した2段階くらい入れると良いというのはそのため)していた。

特に、NDフィルタは急激に明るい場所を表示しようとすると簡単にはいってしまい、画質が急激に悪化する。910SHの暗いところの場面の劣化具合がひどいというのはみんな知っていると思うが、NDフィルタが入ると画面全体がひどいボケた画質になってしまう。NDフィルタが入るときに音がすることから、本体を耳の近くにおいて、まずレンズを手でふさぎ、そこから少しずつ光が入るようにレンズから手を離す、といったことが自然と身についてしまった。

また、シャッタースピードが非常に遅くぶれやすいのも問題だった。明るいところではすぐにフィルタが入ってしまい露出時間が上昇、屋外なのになぜか1/100を下回り、ぶれるということも珍しくなかったのだ。

確かにきれいに取れるようにはなったが、手軽さのかけらなどそこにはない。

そんなテクニックを使ったところでどうしても明るいところと暗いところがある場面はどうしてもうまく取れない。例えばこんな感じの画像は910SHでは非常に苦手としていた。

続きを読む

[][]世の中には想像もできないことくらい・・・ある

http://genzou-postit.blogspot.com/2008/11/blog-post_26.html

コメントに反応。

いやーそんなことはないですよ。技術力はいたって平均的なレベルだと思います。ただおいらより出来る人といまだに仕事をしたことがないけど。でも、ネット上の技術者を見る限りおいらの技術力などまさに赤子レベルでしょう。


ただ、愚痴る閾値が他人よりかなり低いのかもしれません。過去に出てきたのも含めるとこんなものがあります。

  • JDBC直アクセスするのにおいらと新人以外はPreparedStatementを使わない(SQLを文字列連結でStatementのみ)
  • Struts以外のフレームワークは試す価値もない
  • アクションレベルでSQLの組み立て(データアクセスなどの層がもはや意味を成していない)
  • もちろんDIコンテナという単語を聞いたことがない
  • バージョン管理システムを使っているのにコメントで変更点を残す
  • 楽観的ロック用にバージョンカラムまで用意しているのにトランザクション再実行が未搭載
  • DB設計においてIDとかFKを使うのは変人
  • そもそもおいらと新人以外トランザクションを使っていない。複数のテーブルの更新があってもそれぞれ別コネクションを使い単体でコミットしている
  • 主キーの採番にシーケンスは使わない。MAX+1で計算。「ちょ、Insertでテーブルロックするんすか」とつい口にしてしまうが無視される

※最初の項目でおいら以外に新人が入っている理由は、おいらが9月からJavaの教育をしていたから。テキストはおなじみの「創るJava」。一通り説明したあと、「ちなみに…」といって補足説明をすると次のページとかでほぼ確実に説明してあってやる必要なかった・・・と思う箇所が非常に多く、考え方が同じなんだなぁと思い安心して進めることができた。ただし、使用したのは初版。NetBeans 5.0以降はグループレイアウトが有効になっていてコンポーネントの配置は容易になったが、Frame直のグラフィック描画で不具合を起こしやすいのでそこだけ手を入れる必要があったかな。


いちいちこの程度に苛立ちを感じるのはおいらくらいでしょう。普通の人なら「そんなの日常茶飯事だろJK」とさらっと素通りできると思います。おいらはもう完全にダメ人間ですね。

大概この程度はどこの中小企業も当てはまるところは多いかと思います。「ここはどれもあてはまらない、いい会社だよ!」という情報をお持ちの方は教えてください。すぐに面接にいきます。特にNetBeans使用している現場だったらはりきってしまいますね。

続きを読む

[][]というわけで Glassfish V3を再インストールしてみた

どうも付属版の動作がおかしいということでGlassfish V3だけアンインストール。ファイルを見ると大量に削除し切れていないのがあるので削除を試みる。が、削除できないどっかでつかみっぱなしになっている模様。最悪。しかたがないのでマシンを再起動

Glassfish v3インストーラをサイトからダウンロード。あいかわらずIEだと巡回できないサイトのようだ。どうにかならんのかな。


起動後ファイルを削除してインストール。なんかインストーラコンポーネントのサイズがおかしい。同意しないを選択できないようにするための手段かな。(^-^)b

よくよくみると、ウインドウアイコンデフォルトのままだ。そういやglassfishV2のアイコンVCデフォの良くわからないアイコンのままだったな。こういう基本的かつ、ユーザーの目に留まる見た目にまったく手をかけないのはどうかと思う。MSならば自社製品でこういうところには手を抜かないはずだ。

さらによく見てみるとインストールのパスがNetBeansに付属のやつと異なる。V2のときも異なっていたので驚くことではないかもしれないけど、Tomcatは6.0以降で統一してきたというのになんだこのちぐはぐ感は。

IDとパスワードを入力して先に進む。

NetBeansからインストールしたGlassfish V3 preludeサーバーの追加をして起動。デプロイ時にIDとパスワードを聞かれる。なんか不安になったのでNetBeans再起動。そしてまたデプロイ。やはりIDとパスワードを聞かれる。毎回聞かれるのはさすがにだるすぎるのでまたアンインストールorz

プログラムの追加と削除を見てもアンインストールが見当たらない。なんじゃこりゃぁ。NetBeansとセットの場合だけここに登録してくれるってか。しかたがないのでアンインストール用の実行ファイルらしきものを直接起動。大量に残るファイル郡。今回も参照中のため削除ができず。マシンを再起動


さすがに再起動を繰り返すのはだるくなってきた・・・。


再起動インストール。今度はIDパスワードなしでセットアップ。

NetBeansを起動。よし、問題なし。続いて管理ツール画面を開いてみる。

お、うまくインストールされた。しかし、管理画面を開こうとするたびに「インストールの進行中です」と表示される。なんじゃこりゃぁ。

[][]NetBeans 6.5に付属のGlassfish V3preludeがおかしい

6.5RCまでは管理ツールが自動的にインストールされて使えてたはずなんだけど、正式版に付属のPreludeは管理画面を開こうとするとGlassfishが起動してますよ、という程度の画面しか表示されない。

なんじゃこりゃーアップデートセンター起動してもそこで管理画面を追加できそうなものはみつからず。

つかえねー。

[][]NetBeans用にT2Framework 0.4サンプルプロジェクトを作ってみた

0.4が登場したのでさっそくNetBeans用プロジェクトを作ってみる。

サンプルプロジェクトをNetBeansプロジェクトへ手動で変更。NetBeansのプロジェクト構造を把握している人は手動でファイルをコピペしたほうが手っ取り早いのはいつものとおり。


NetBeansT2Framework 0.4サンプルプロジェクトはここにおいておきますね。

zipを展開してプロジェクトを開く、でいけるはず。NetBeansのバージョンは6.5で。

実際にサンプルを実行してみての気になった点は別エントリで書く。

2008-11-29

[][]需要と供給

きしださんの最近のエントリのスターやブックマーク数を見ていて思ったのだが、みんなマルチスレッドに関する情報に飢えているのかと思ったがそうでもなかったぜ!

Atomicのときにこれは需要あるかもとおいらもネタにしようと思ったけどなかなか需要を予測するのは難しい。


おいらだけかもしれないけどカテゴリを新設するのには勇気がいるんだぜ?


とりあえずサイクリックバリアは良く使うからみんな覚えておこうぜ!

[]930SH 逆光など

秋葉原

http://shin.cside.com/diary/2008/1129-01.jpg

外に出たらちょうど日が出てきたので撮ってみた。


逆光

http://shin.cside.com/diary/2008/1129-02.jpg

NDフィルタ+メカニカルシャッターのおかげで人間はまぶしくて見ていられない状況でも一応このとおり。当たり前ですが、液晶上はスミアはでています。露出時間は1/1500のようですね。

2008-11-28

[][]これはひどい問題


http://d.hatena.ne.jp/hayassh/20081126/1227715969

わはは。改良じゃなくて別の意味になってるじゃねーか。

もともとの問題として「equals」で比較してる時点でnullがないのが保障されている(もしくはnullポインタ例外を発生させることが仕様にあるか)はずなのにこの選択肢は正直ありえない。


おいらもhayasshさんと同じようにnullが持ち込まれるかの判定が必要な場合はif文で明示します。その条件で例外をどう発生させるのかがそのメソッドの追加機能とかで盛り込まれていく可能性もあるからです(入力がおかしい場合はこの例外をスローするとか。)。assert入れてる現場は正直少ないと思います。




ただ、空文字かどうかの判定にはequalsではなく

if(hoge == null || hoge.isEmpty())

とisEmptyメソッドを使いますけどね。

http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/String.html#isEmpty()

2008-11-27

[]930SHによる写真3点からみるISO感度設定

やはり暗いところでもかなりシャッタースピード落として明るくする模様。やりすぎなくらいに。

したがってデフォISOオートのままでは非常に手振れがしやすくなる。

実測。手元にあったパックランドの下敷きを撮ってみた。このころのナムコはもう最(ry

ISO感度設定実際のISO感度シャッタースピード
オート1251/4
高感度オート4001/33
ISO1001001/8

オートのはさすがに手振れをしていて論外。1/4ってさすがに無理すぎ。ISO100が一番きれいですね。

手振れするよりはまだましだが、さすがにISO400では高すぎる。蛍光灯の下とかの場合手動で100や200に設定したほうがいいかも。ISO2500だとシャッタースピードはかなり良いけどさすがに画質劣化はかなりのもの。それでも910SHのISO200よりましな気がする。910SHはオートもしくはISO100しか事実上使い物にならなかったからなぁ。910SHはF値が非常に悪いのでカタログスペックだけのはったりISO感度だった。

ちなみにホワイトバランス等はいじっていない。あくまでも今回はISOのみの比較。

[]ゴールドライタンでかすぎ

ちょ、でかすぎ。

http://game.watch.impress.co.jp/docs/20081127/tatsu.htm

ゴールドライタンだけタッグになってないように見えるけど、かっちょいいからいいか。

[]NOKIA日本撤退

http://k-tai.impress.co.jp/cda/article/news_toppage/42960.html

日本専用に開発していたのならともかく、ぜんぶ日本語化した程度じゃねーかと思った人は多いはず。

2008-11-26

[][][][](ゲーム)

http://blogs.sun.com/katakai/entry/hottopic_seminar_2008_11_netbeans


むむむ。

ひとりだけ(ゲーム)とか不思議なリンクがあるぞ!クリックしてみようぜ!



Windows用のJNIのライブラリ添付してランチャーにexe使ってるのでWindowsでしか今のところ遊べませんけど、そのうちWebStartかupdate10アプレットにしてどの環境でも遊べるようにするかも。Windows持ってる人はぜひ遊んでみてください。update10でも動作確認しました。ジョイスティック対応してますのでキーボードよりはそちらのほうがいいでしょう。

ALL2面です。

言語はジョイスティックサポートのJNIでC言語を利用している部分以外はすべてJavaです。Javaだけでも60fps安定なゲームが作れますよっと。

[]携帯を930SHに機種変更してきたが、カメラの画質きれい杉ワロタ

久々のCCD、メカニカルシャッター+NDフィルタ搭載。2年前の910SH以来だ!カメラの画質きれい杉!

8Mピクセルというところが目立つがやはりうりはそんなところではない。

暗いところでかなりISO感度あげるようで、真っ暗な場所でもかなり写る。明るさを考慮するならばオートではなくむりやりISOを下げる必要がある模様。

今まではいかに暗いところでもとれるようにするために、ISO感度をあげるか、がキーだったのにオートで2500まであがるようになっちゃうと以下に下げるか、がテクニックとして重要になるとかやりすぎだと思う>シャープ


というわけで、すでに夜だったためと購入直後はバッテリがほとんどないということで、写真は外では取れず。仕方ないので家に帰ってからとってみた。


蛍光灯の下の画像457KB


蛍光灯の下で適当にとっただけでこの画質。910SHは調整すればいい画質が出るという非常に使いにくいくらいレンズだったが、それが大きく改善され、903SHなど光学2倍+300万画素クラスと比較しても暗いところで色が出ないということもない。910SHからの機種変だがこれは正直やばいくらい性能アップしてるのがわかった。SH07やSH51という初期のシャープ端末からずっとシャープ一筋なのだが、ピントがあってない場所のボケ具合とかはほんとうまくなったなぁとか成長を感じた。


続きを読む

2008-11-25

[]今日の愚痴

subversion導入してるのに変更があった箇所や変更前をコメント化して残せといわれた。

ええええええええええええええええええええええええええ。


最近は精神的ダメージのほうが大きい気がする。

[]テツとイーダ

http://d.hatena.ne.jp/shot6/20081125#1227574364

2キャラ(3?)の名前をあわせると「テイーダツ」。つまり、「Teeda 2」。

考えすぎかな。

[]ついにしんさんの素顔を公開!

19日のsun本社のJavaExpert #3 まるごとNetBeans記念セミナーの筆者紹介で使われた写真がついに公開。


当日いった人は、この写真見たよ!間違いないよ!といってくれるだろう。

アングルが悪いのでわかりにくいですが、おいらはしっかり二重まぶたですよ。

ほかにも見えにくいところがあるかもしれないけどそれらはすべてアングルのせいですね。写真撮るのが下手でごめんなさい。

でも(゚ε゚)キニシナイ!!


そういや紹介用にJavaでゲームも作ってる人、というのを片貝さんにお願いしたのだが、今にして思えば、仕事を募集したほうが良かったかな。(ぉ


というわけで宣伝。

正社員でも非正規雇用でも請負でも形態はこだわらないのでJava技術者がほしいところはよろしくです。いわゆる派遣型以外ならOK。

技術力は一般的なレベルだと思いますが、趣味のひとつがプログラミングの勉強ですのでそれなりに順応は出来るかと。できればJavaDocが気軽に見れる開発がいいです。仕事の内容次第で金銭面はびっくりするほど妥協(やりがいがあって技術の成長も期待出来るようなものならば)しますよ。気に入れば通勤による体力消費を抑えるため引越しもすぐに考慮します。ただし既存のお客さんとのやりとりもあるかもしれないので、場所は東京埼玉近辺のみです。

使用するIDEについていっておくと現時点ではNetBeansのほうがEclipseの1.5倍から2倍のパフォーマンスは出るようです。Java以外のスキルC言語くらいしか今はないと思います。

2008-11-24

[][][]小ネタ千夜一夜 第1夜

きしださんの一連のエントリで新しいネタである必要がないということに衝撃を受けたので、小さいTipsをいろいろと思いついたときに書いていこうと思う。


記念すべき第1夜の今回はJavaによる環境変数の取得。これもネタとして新しいものではありませんな。知っていて当たり前の情報。

J2SE 5.0からは環境変数の取得ができるようになった。昔は出来ていたのでいまさらなのだが、実は新しいメソッドも追加されている。

java.lang.System

public static Map<String,String> getenv()

戻り値を見てわかるように環境変数の一覧が取得できるようになったのだ。


以下サンプルコード。

    public static void main(String[] args)  {

        for(Entry<String,String> e : System.getenv().entrySet()){
            System.out.printf("%s=%s%n",e.getKey(),e.getValue());
        }

    }

ちなみに

現在のJava SE 6 update10ではVMの起動に0.1秒もかからないこと、環境変数が自由に取得することも出来ることを考えるとJavaCGIも使用可能な状態になった気がする。メモリ使用量も20KBくらいのようだし、PHPRubyと比べて大きく不利とも思えない。起動が早いホットスポットVMとの相性も実はいいはず。もちろん、ループなどでは途中でコンパイルがされて高速化するので遅いといったデメリットもない。

プロセス単位での起動はやはりパーミッション等の設定が容易になるということで、レンタルサーバー等で導入いやすいような気がする。問題はmod_cgiのままではすぐに扱えないので、mod_javacgiとかが用意されれば一気に広がる可能性もあるのでは?という妄想が膨らむ。

Java SE 6 update10はまじでVM起動が一瞬なので、コマンドライン用ツールが大量にJavaで書かれてもおかしくないかも。Java=起動が遅いと思ってる時代遅れな人はぜひupdate10を試して欲しい。

[追記]

ブックマークコメントみて反応。NetBeans6.5付属のJRuby1.1.4を起動してみたところ0.5秒かかっている模様。0.1秒あれば動くJavaのコードに比べるとやはりプロセスの起動はちょっとつらいかも。

2008-11-23

[][]XFDっていうのがおもすれー

http://d.hatena.ne.jp/masanobuimai/20081123#1227449173

このスライド、後半のXFDってのが面白い。

やっぱり表現力(ここでいう表現力はいわゆるPC方面の用語で死語。15年位前には消えたかな。グラフィックだったり音楽だったり視聴覚に訴えるものという意味で、CPUとテキストさえ出ればよいという通常のビジネスマシンで必要としていないもの)って大事だね。

こういうところに手を出せるえふおうさんやmkeiさんがうらやましいのです。おいらはハードはからっきしだから。半田ごてすら持ってないただの一般人だから。


このリンク先で1000speakersというものをはじめて知ったのだが、ピザって項目があって○×があると、太ってるかやせてるかという項目に見えるおいらはネット脳。


肝心のテストについてはなんかもう一歩踏み込んだものがないと普及は難しいのかなぁという気がします。JUnitとかやってない現場だって大量にあるし、DBUnitだけではDB方面も完璧ではないだろうし(知らないだけかもしれない)。例えば、ロジックでコネクションやHttpServletRequestを引き回したりするコードが容易にテストできるとは思えないし。

テストしやすい環境つくろうよ、といってもこの業界DIコンテナなんて知ってる人は体感として10人に一人くらいだと思う。ネットだけ見てるとなんかすごい普及しているように錯覚するけど。

やっぱりこういうのはお偉いさんにわかりやすくアピールできる表現力的なものが必要になるのかなと。そして上から導入に対してGOをかけてもらうしかないのかなと。

[]プレリュードは所詮プレリュードだがそれがいい

プレリュードは所詮プレリュード

だがそれがいい」という人も多いかもしれないよ?というお話。

https://glassfish.dev.java.net/public/comparing_v2_and_v3.html


見てわかるようにGlassfish V3 PreludeはぜんぜんJavaEEを網羅し切れていません。JavaEE6どころかJavaEE5ですら完全には実装されていません。JavaEE 6に必要な機能はJAX-RSくらいしかまだ実装されていないのです(そのJAX-RSの実装であるJersey1.0ですらバグもちのようです)。

でも見方を変えると面白いことがわかります。アプリはwarファイルしかデプロイは出来ませんが、よく使われる機能としてJTAによるトランザクション管理とコネクションプーリング機能を持っています。もちろん、管理画面はすべてGUIによる管理が可能です。ログのローテートとかログレベルの動的な変更とかさまざまな便利な機能がGUIから操作可能なのです。

つまり、基本機能はTomcatでいいという人にうってつけなのです。ただ、Tomcatでいいという人であっても真っ当なコネクションプーリングとトランザクション管理が欲しいという人は多いはず。そしてこれらの便利なGUI管理ツールは日本語化されています。


それで上のほうで「だがそれがいい」といったのです。JavaEEのフル機能が入っていないからこそTomcatからの移行に最適です。Tomcatは5.5まではGUI管理ツールが一応搭載されていて、多少の操作は可能でした。しかし、6.0からはそれがなくなりました。

自前でやるにしても例えばTomcatではコネクションプールの設定などを行おうにもバージョンによって設定方法が異なったりします。今後もどんどん変わるかもしれません。JTAにおいては良く使われる機能なはずなのにTomcat上ではサポートしていません。DIコンテナ上でやるにしてもSpringは真っ当に実装されていないままだと思われます(過去に調べた範囲だとSeasar2は真っ当でした)。

コネクションプールはJNDIで取得するのがベストです。つまり、開発時と運用時でwarアーカイブの中身は替えないのが普通です。中の環境設定ファイルを変えるとなると他のファイルを間違っていじってしまうという可能性が残るため、普通に考えてテストしなおしが必要になってしまいます。

つまり、運用する場合サーブレットコンテナだけを使うとしてもすでにGlassfish V3に移行したほうがはるかにいいのです。GlassfishサーブレットエンジンはTomcatを使用していますのでTomcatで動いていたものはまずそのまま動きます(そもそもTomcat自体sunから提供されたもののはず)。

入っているコンポーネントが少ないという音は非常にサイズが小さく小回りも聞くということです。すでに入っている各種JavaEEコンポーネントを削除してさらにコンパクトにすることも可能なようです。


ちなみにプレリュードという名前がついているので未完成版に見えるかもしれません。たしかにJavaEEフル機能は入っていませんが、すでにちゃんとした製品版です。V2のように有償サポートも受けられます。



欲しい機能が以下のものだけでいいという人はGlassfish V2ではなく、Glassfish V3 Preludeがオススメです。小さいので起動も早く、フットプリントも小さいでしょう。

  • JavaEE5に対応したwarファイルがデプロイできること
  • コネクションプール機能があること
  • JTA機能があること
  • GUIによる管理が可能なこと

単純なwarファイルのデプロイ時間が異様に速いこと、再デプロイしてもセッションの維持をしてくれることはかなり便利だと思います。

実際のデプロイ時間はこんな感じ。

情報: Loading application WebApplication6 at /WebApplication6

情報: Deployment of WebApplication6 done is 93 ms

Webアプリの配備が100msもかからなくてもおどろかなーい。


再配備時のセッションの復元は思った以上に便利ですね。デバッガと同様にフィールドが増えたりメソッドが増えたりした場合はセッションに格納されたオブジェクトは復元できませんが、大概繰り返して実行したいときというのはロジックの修正がやはり多いです。

逆に言えばセッションスコープのBeanにロジックを書いているとメソッドの追加でもやり直しになるのでJSFとは相性がちょっと悪い気もします。ただ、プライベートなメソッドの追加ならば影響は無いようですのでそんなに問題は無いかな?StrutsとかSpringMVCなどアクションベースのフレームワークとかはわりとさくさく開発できるのではないでしょうか。


デプロイ一瞬、再デプロイでもセッションには情報は残っていますから、Seasar2のHotDeployに「比較的」近い感覚で開発が出来るのではないでしょうか。ちなみにNetBeans 6.5ではこのセッションを保持がデフォルトで有効になっています。NetBeans 6.5を落とした方はぜひお試しあれ。

あとはこのGlassfish V3のセッション保持機能がパワーアップしてちゃんとシリアライズと復元をしてくれたらこれほど便利なものは無いでしょうね。なんせ、フレームワークとかに依存しませんから。

[]このかわいい生物?はなんですか?

http://d.hatena.ne.jp/yone098/20081121/1227279088

とりあえず左上にいる謎の生物が気になった。


マッスルスパークきめてるんだよね?

2008-11-22

[]Java2Dの大幅な高速化その4 完結編

http://d.hatena.ne.jp/shin/20081118/p2の続き。


画像を表示

drawImageでテスト。画像サイズは64*64ピクセルでImageIOにて取得したもの。

J2SE5.0のときはアクセラレーションを効かそうとするとピクセルフォーマットを理解して設定する必要があってImageIOから取得しただけだとぜんぜん使えなかった(ちゃんと環境を理解している人のみが高速化できた)。JavaSE6からはその制限が大きく緩和されて比較的手軽に高速化するようになった(ここまではblog移行前の日記でいろいろと触れてます)が、update10ではまた別次元の速さを見せ付けてくれた。

256個の透過付画像を表示を1フレームとし、1000回フリッピングして時間を計測した。

update62860ms
update10680ms

3倍もはえー。これだけ速いとマシンパワーがかなり低くてもJOGLを使わずに60fpsでのアクションゲームは余裕で作れそうな気がする。


拡大縮小


で、ここからが本題。拡大縮小をしてみる。


update624560ms
update10680ms

えええええええええええええええええええええええええええ。

速度が変わってない。拡大縮小は完璧にアクセラレーションが効いているようだ。update6は9倍近く遅くなってるのに。

回転


update622960ms
update10800ms

2桁違う結果が出ても、もう驚かないぞっ!


αブレンディング


update617680ms
update101380ms

ここも10倍以上の差がついた。



ちなみに


ちなみに、同じコードでbufferStrategy.getCapabilities().isPageFlipping()の実行結果が異なった。

update6false
update10true

注意されたし。


結論


update10ではJava2Dがおおむね3倍から10倍くらいの描画性能がアップしている。すごいの一言。

とはいえ、Java2Dがゲームやまともな各種描画用途に微妙なのは変わらない。αブレンディングが弱すぎるからだ。5.0、6とバージョンアップするたびにCompositeが増えるのではないかと期待していたのだが、見事に裏切られ続けられてきた。自前でCompositeを実装した場合ソフトウェアレンダリングになるうえに、パイプラインが中断、VRAM→メインメモリへの転送が大量に発生するのでこれも現実的ではない。

わかる人向けの説明とすれば、NEOGEOX68000のスペック程度のアクセラレーションはPureJavaでしっかり効くということ。もちろん、速度ははるかに今のPC+Javaのほうがはるかに速い上に制限がない。


テキスト描画などを考えるとJOGLとどっちを使うかというのは結構悩むところ。

ゲームが一番熱かった時期を考えるとNEOGEOやX68程度のスペックでも十分なのかもしれない。ShinGL1のようにJava2D用のゲームライブラリをまた作るのもいいかも。今度はオープンソースにすっかなぁ。でも需要無いからいらないか。

[][]NetBeansの長年悩まされたバグの正体

http://d.hatena.ne.jp/shin/20081118/p1の続き。まさか忘れていたなんて言えない。

画像を見てもらえればすぐわかると思う。

JavaSE 6 update6で実行した場合の補完。



そして下がJavaSE 6 update10で実行した場合。


Netbeansの補完ウインドウは描画可能な画面のサイズを自動的に計算してくれていないために、このようなことになってしまっていた。タスクバーより手前に描画しないタイプのポップアップを使っておいてそこに補完ウインドウが重なると非常にうざったい。ソースの長さによっては回避できないこともあった。これは少なくともNetBeans3.xからあった古のバグで放置されすぎと十分非難されてしかるべきバグである。


それが、update10にしたら解決。6.1や5.5.1などでやってもすべて解決されたため、とりあえずこれでいいかな。しかしこういった基本的な挙動が変わるとそれにべったりと依存していたSwingアプリとかまともに影響を受けてやばそうだ。

[]930SHのモックみてみた

想像以上に薄い。これで8Mピクセルか。たしかに光学ズーム入れる場所はない模様。でも2軸はいれてほしかったような。色はどれもよさそうに見えた。やっぱりWebや紙でみるのと実物見るのとでぜんぜん違うわ。

機種変予定。おいらと同じく発売日にカメラ重視で910SHかった人はこの週末は指をくわえてみているほかない。なんせ25日が910SHの発売日だったから。

とりあえず上がっている写真はいくつかあるが、夜のようにとか発光体と暗いところの差が激しいところでもきっちり移ってるのがまじですごい。

購入したら今回も2年前のように大量にレビューする予定。お楽しみに。

2年前の日記

[]これじゃ再生ではなく清算だろ

http://d.hatena.ne.jp/JavaBlack/20081121/p1

しかも他の債権者に迷惑をかける分たちが悪い。

2008-11-21

[]豪華特別ゲストの正体

そういや気がついたら19日とっくにすぎておった。

http://blogs.sun.com/katakai/entry/java_hottopic_seminar_november_netbeans

ミニセミナーの豪華特別ゲストって誰だろうと思っていたが、参加されてたかたのエントリをみるとヨシオリさんきしださんだったらしい。豪華すぎてまぶしっ。

ん?片貝さんのねこび〜んTシャツ姿…だと?ゴクリ。

これからの時期Tシャツ姿はなかなか難しいと思いますので、ねこび〜んグッズはさりげなく1年中日常的に使えるものがいいですね。最近は画像さえあればオリジナルネクタイとかも作れるようなのでそういうのにもちょっと興味があったり。


JavaExpertの筆者紹介ということはおいらの恥ずかしい写真も写ったのだろうか。キモーいという歓喜の声が上がったかもしれない。これでは恥ずかしくて外を歩けないといいたいところだが、おもいっきり髪をばっさりと切ったのでたぶん同一人物とみられまい。


そういやこのセミナーの開始時間を考えると普通にお仕事されてる方はなかなかいけないはず。フレックスを導入しているところならばわりといきやすいとは思う…のだが、最近は減ってきている。10年前はIT業界はどこもフレックス採用していてそれが売りだったのに、いまではどこも拘束時間で稼ぐスタイルが蔓延し、フレックスをやらなくなってきているのが残念。システム開発なんて時間をいくら高速したところでできあがらないっつーもんはできあがらない。ちょっと調子が悪いとかくぎりがいいところなどですぐに退社したり、今のっているからもうちょっとやっていくなど、フレックスとの相性は一番いい業界なはずなのだが。

ということは当日参加できた方は有給を使ってきた漢ばかりということか。14年近くこの業界で働いてきても、「セミナー行くので5時にあがります」なんてのを許す現場というものをおいらは想像できないのだが、はたしてそんな会社は日本に存在するのだろうか。そんな技術者を大事にする会社なら給料は少なくてもかまわないので働いてみたいものだ。


ここなどで一人だけやけにういているように見えるあたりが、キモいおっさんたる所以。

[]NetBeans6.5の目玉はやはりPHP

以下の動画をダブルクリックで大きくしてみてみると雰囲気がわかると思います。

http://www.netbeans.org/kb/docs/php/php-editor-screencast.html

おいらは開発版からずっとPHPの開発にNetBeansを使用してきましたが、もうこれなしでPHPの開発はする気にならないですなぁ。

LLはテキストエディタで開発は出来るけれども、やはり実行前に構文チェックはして欲しい。構文ミスを実行時に発見するのはだるすぎるから。


そういう意味ではBASICって中間言語で格納するおかげで、入力時に構文チェックされるというすばらしいバランスだったのですね。中間言語にすることによってインタプリタの実行の容易さもあるわけで。

その後C言語等が普及しましたが、テキストエディタで開発するスタイルになったため、コンパイルという作業が面倒に感じられたりしたのでした。

BASICが支持されたのはたまたまではないんですね。


LLをそんなBASIC並に改善するIDEは必須です。コンパイルがない言語では必須だと思います。NetBeansひとつでRubyPHPJavaも快適。


「必要な唯一の IDE です」は伊達じゃない!

あとHibernateサポートが入ってきたのでHibernateを使用する人にとってはかなり大きいかもしれません。なんせSQLをうって結果セットを取得するようにHSQLを打ち込んでその場で正しいか確認できます。それをコピペして組み込めばよいのです。

JPAにもこの機能入れてほすい…。

2008-11-20

[]これすっごくいい

http://d.hatena.ne.jp/masanobuimai/20081117#1226921940

NetBeansにもほすい…。

ALT+Insertもぱくったのでついでにぜひ!

[]良いエントリにはてなスターがつくとは限らない

http://d.hatena.ne.jp/nowokay/20081119#1227076215

http://d.hatena.ne.jp/nowokay/20081120#1227153604

を見て思った。ブックマークがずっとつかなくて心配していたけど。

※注 なんかリンク先間違えた気がするけど気にしなーい


トランザクショナルメモリで必ず思い出すのが楽観的ロックでループ処理をしていなくて競合したときに不具合がでるというやつ。バージョンカラムがないてるぜ。

ちなみにこれ、ソフトウェアのみでやろうとするとデータのコピーがかなり問題になる。今回の例のように単純なものならいいけど、実際はそんな簡単にいかない。ディープコピーの問題がすぐに発覚するし、単純にデータのコピーによる時間が問題になる。となると、変更箇所のみバージョンを持つという考え方が必須になってJavaのみではどうにもならない。

実際のアプリでは書き込みが少ない場合メリットが最大になるわけだが、そもそも書き込みが少ないのならライトロックしていてもそんなに問題にならなかったりする。

トランザクションが非常に少なく、そのたまに実行されるトランザクションが異様に長い場合のみに威力を発揮するわけだが、それがどれだけあるだろうか。

バージョン管理機能をもつRDBを普通に使ったほうが結局無難だということになったりする。



ちなみにjava.util.concurrent.atomicは便利そうに見えて一般的なアプリでは使う場面がまずない。一意となる連番が欲しい場合はRDBのシーケンスを使うことになるだろう。マシンが正常稼動している間のみ動く連番処理が欲しい場面は結構少ないのだ。複数のマシンを導入して負荷分散をするならばなおさら。

Javaのconcurrentパッケージでよく使うのは

  • Executors
  • ExecutorService
  • CountDownLatch
  • CyclicBarrier
  • BlockingQueue
  • ThreadPoolExecutor

これくらいかな。Thread+独自ライブラリで管理していたときに比べたら組込Javaプログラミングは天国だと思う。Queueインターフェースが定義されたのも大きいかな。

Queueの話が出たのでついでに話すと、非常に便利そうなPriorityQueueは意外と使い物にならない。同じ優先度の場合の処理をカスタマイズできないから結局自前で作ることになる。


話があっちこっちにとんだりしてるが気にしなーい。

[]NetBeans 6.5MLリリース!

http://ja.netbeans.org/

Eclipseが3.3以降日本語などマルチリンガル対応で遅れていく中、逆にNetBeansは日本語版を含むML版が英語と同時リリースですよ。今までは英語版の後一ヶ月くらいたってからでていたのに今回は同初。すばらすい。

次回はついに英語版を他言語が追い越して英語版が日本語版の一ヵ月後にリリースされるのですね。わかります。


次は7.0とかいうバージョンになって機能が大量に追加されるだろうからML版は遅れそうな予感。JavaSE 7にあわせてでてくるのかな。

2008-11-19

[]なぜ今頃

concurrentパッケージの使い方を知らない人が結構いて驚き。5年位前に話題になってたきがするけど。きしださんのことだからupdate10で何か大きく仕様が変わったとおもっちまったぜ。もしかしてSystem.nanoTime()とかSystem.out.printf()とか一般的に使う頻度の高い命令も知らない人もいるだろうか。

本当にJava2SE5.0すら普及してないんじゃないかと思わずにはいられない。みんな知ってると思うけど5.0ですらもうEOL(End Of Life)移行フェーズに入っているんだぜ?



というわけで5.0や1.4.2からアホみたいに速くなったJavaSE6はよう普及しる。update10でさらに加速したし。

ちなみにこのJavaSE 6 update10でNetBeans 5.5を起動するとキャッシュに入った2回目以降はなんと2秒くらいで起動する。あーやっぱり6.0からプラグインが大量に組み込まれたおかげで起動時間遅くなってるんだよなぁと実感した。5.5も素のEclipseに比べると機能が膨大なわけだがそれを感じさせないVMの進化に驚いた。

[]ネガティブ思考であること=努力しないわけではない

http://d.hatena.ne.jp/t_yano/20081118/1227030231

これ見ると、最後の引用とかネガティブ思考=努力しない人のように見られていやだなぁ。努力とネガポジなんて関係ありませんて。また、新しいことに足を踏み出すのにもネガポジは「まったく」関係ない。


ネガティブ思考ってのは慎重さをもとめているわけであって前に進まないのとは違う。最悪の状況を常に想定して、そこから先は上昇のみを目指すという考え方だと思うんだけど。だから、足を踏み出す前にいろんなことを頭の中で高速に考える。

どんなポジティブな人でも足を踏み出すことをしないほうがいいという結論になることはあるはず。「これはやめておこう」とか「この部分をクリアにしてからじゃないと」とかいうことね。それの敷居が他人より低いだけがネガティブ思考じゃないかな。


たとえば仕事をもらうときにあまりにも不確定要素が多くて下手するとデスマになりそうだなと思ったとき、前に進むかい?おいらはこの部分は大丈夫、この部分はだめ、この部分は不確定すぎて危険と3つのパターンに要求項目を常に当てはめて考えてるよ。その割合から受けるか受けないかを判断する。そして失敗したときのことも常に考えていて、その場合の対処方法とか選択肢をいくつか考える。

常に最悪のことを考えておくというのはセキュリティホールがらみとかではよくあることなんだけど、みんなそうじゃないのかなぁ。ただ、営業の人とかはやけにポジティブ思考な人が多いのか、5割くらいいけそうならGO出す人とか多いし(おいらは確定要素が5割ならうけません)、もしこの移行に失敗したら、もしパフォーマンスが出なかったら、もし納期が遅れたら・・・といったことをすぐに網羅する人が案外少ない。


チャレンジは必要だろ?という人多いけど、そのチャレンジに失敗したら企業がつぶれるという状況だったら大きいチャレンジしませんよね。1つくらいプロジェクト失敗しても大丈夫だ、ということがわかった上でなら大きいチャレンジでもする可能性は十分ある。そして失敗する可能性をどうすれば減らせるかをひたすら考える。この不安要素をすべてつぶした上で進もうという壁の高さがネガティブ思考だと思う。

だから、結論を出すのが遅く、無限ループに入っているように見えても不確定要素の把握ができていない、計算が遅いというだけの話ですから、それはネガティブ思考だからという考えではないと思う。真に無限ループにはいっていたらネガポジ以前の問題。たんに状態の把握、整理ができない人なのかもしれません。



一言で言えば「石橋をたたいて渡る」って言葉が大好きなのがネガティブ思考。石橋をたたいてる途中に口ははさまんでおいてもらいたい。

つまりおいらはネガティブ思考。でも新しいフレームワークとかライブラリとかガンガン試すよ。それがあることによって判断基準が確立していって石橋をたたきやすくなるもの。試すことによるデメリットが大きいのなら躊躇するけどさ。

[]最近やっとはてなスターの使い方がわかってきた

きしださんのこのエントリはなかなか練習の使い勝手が良いのでぜひ!

2008-11-18

[][][]フレームワーク比較

http://d.hatena.ne.jp/t_yano/20081118/1227008018

ポイントとしては作成するアプリによって得意不得意がでるため、その辺は考慮するというところか。

Wicketの考え方はわりと好きだし、Guiceは大好き。でもDBアクセス周りはツールの豊富なサポートがあるJPA使いたいのとトランザクションまわりなどの設定の容易さを優先して考えるとEJB + JPAの組み合わせになってしまうかな。JavaEE6時代は何も考えずにWicket + EJB3.1 + JPA2.0がかなりいける予感。

JPAはJavaSE 7のプロパティ構文対応したときCriteriaが真価を発揮できるかな。文字列や無理やりつけたメソッドを使うのは好きではないからJavaSE 7でぜひとも採用して欲しい。そのときは3.0、JavaEE7あたりになってるだろうか。

でもそのときは覚えなくてはいけないことが多くなりすぎてないか心配。2.0のドラフト時点で大量に命令が追加されて覚えるのが容易ではなくなっていることを考えると、JPA1.0って後から考えると意外といいバランスだったんじゃないかと思えてくる。APIってなんでもそうだけどちょっと物足りないくらいがちょうど良い気がする。ラッパを作る余地が残されているというか。足りないのは各自独自の命令でいいわけだし、それが標準APIというものかと。ただ、ヒントの共通化とかいくつかは最初から欲しいのが多かったけど。

ただ

プログラム的にLAZY/EAGER を変換する方法はないっぽい。

ってのはないんじゃないかな。JPAでは設定をLAZYにしておいて、取得時にIN設定だったか(記憶が曖昧なので後で調べなおす)するとLAZYでもEAGERでとってきた記憶がある。気のせいかもしれない。


あとJPAは@PersistenceContextでDIできてすぐ使えるのと同様の環境があるのなら@Resourceでデータソースをインジェクトできるので、ネイティブSQL云々はそっちでやればよいとわりきると楽。例えばDBUtilを使用してJavaSE5構文に対応したクラスを作るとものすごーく楽。


JPQLは独自というよりEJBQLからの派生。というかほぼ同じ。


更新操作は他のものと変わるようには見えないなぁ。むしろ変更があったフィールドだけを適切に更新してくれるので(Toplink、EclipseLink、OpenJPAにて確認済み)キーや更新比較用のBeanを用意しない分優れていると思う。管理状態かどうかはトランザクションをコンテナ管理のみにしてしまえば問題はない。

トランザクションは無条件でJTA必須として考えたほうがいいんじゃないかな。glassfishなどの真っ当なアプリケーションサーバーにデプロイするとJTA以外はデプロイ時にはねられたりするし。


JPAは最初の敷居は高いが慣れると楽になるタイプのフレームワークで、ある意味Wicketに近いかもしれない。

[]これもすごいんじゃね?

http://pc.watch.impress.co.jp/docs/2008/1118/emachines.htm

入門用として必要十分なスペックを持ってる。CPUの性能はおおむねAtomの倍くらいと思っていいだろう。

大きいのでUMPCとは使い方が異なるのだが、ほとんどの人にはあの大きさがメリットになるとも考えにくい。入門用にはならないわけだし。


Atomが登場してUMPCが一気に増えたわけだが、個人的にはノートPCでも10万円を切るのが珍しくない状態になったというのが非常に大きいと思う。

だから日本のメーカーもEeePCの魅力のない後追いばかりするよりは、本気で低価格PC(それでいてしっかり利益が出るように)を考えたほうがいいんじゃないかな。企業にとって10万をきるというかどうかはやっぱりポイント高いし。

[]Java2Dの大幅な高速化その3

http://d.hatena.ne.jp/shin/20081116/p3の続き

JDKに含まれるJava2Dデモをupdate6とupdate10で実行してみた。最後のTransformの下の画面をクリックし、最大化しでキャラを最大に増やしてTranslateのみにしてみる。

  • update6 240fps
  • update10 480fps

ぎょえー。ちょっとまともにJava 2Dの速度を検証しなくてはならないな。

なんせいままでのはJava 2Dといいつつ1.1時代からあるGraphicsしか使っていなかったのだから。主に使うであろう拡大縮小回転αブレンディングくらいはすぐに調べよう。

[][]長年悩まされていたNetBeans最大のバグが解決した!

バージョン3から何年も続く非常に厄介だったバグがついに解決!NetBeansでコードを書いたことがある人なら初日で気がつくであろう有名なバグなのだが、なぜかいままでずっと放置されていたのだ。

これほどうれしいことはない。

あとでかく

2008-11-17

[]もう技術力うんぬん以前の話だろ

今日知り合いから「ちょっとわからないことがあるから教えてくれないか」との連絡が入った。

どう考えても難易度の高い質問ではない。すぐに検索したり調べてみればわかる類のものだ。


おかしい…。


彼は技術力が低いということは決してない。ちゃんと調べれば大丈夫なはずだ。


念のため聞いてみた。

「もしかしてネットがつながらない場所?」

「そうだ」


ネットがつながらない環境での開発現場は結構多いよね。そんな状況でパフォーマンスを最大限に出せる人がどれだけいるのだろう。


さらについでに簡単なAPIの使い方を聞いてきた。これもすぐにしらべればわかるはずだ。まさかと思いまた聞いてみた。

「もしかしてJavaDocはないの?」

「ない」


ぎゃー。こういう現場はベテランの生産性をも新人レベルまでさげてしまう。ひがさんのblogにも出てくる一般的な企業なのだが、こういう現場ではてなとかに技術的なblog書いてるベテラン勢がどれだけパフォーマンスが出るか興味がある。

ちなみに、おいらは無理。JavaDocやソースにすぐにアクセスしてライブラリバグでしたとか確認できないような環境は無理。無理ったら無理。愚痴ばっかり言って新人以下のパフォーマンス出してると思うよ。

[]たった1万時間でいいんすか!

http://d.hatena.ne.jp/higayasuo/20081117/1226919944

たった1万時間で天才すか!それだと俺天才!おk。実感ないけどwwwwww!



と思った人手を挙げて!少なくとも職業プログラマベーマガ世代には多いはず。


直接的にキーボードをたたいていなくても、机上でアルゴリズムを考えたり書籍を読み漁ったり、妄想した時間を考えると、ベーマガ世代はどう考えても1万時間程度は誰でも通過点、もしくはこのままいけば容易に達成可能な時間数なはず。おいらの場合でも中学校だけでおそらく4000時間は行ってたと思います。テキストエディタがありませんでしたからね。紙にアセンブリ言語のコードを書いて、ハンドアセンブルするのが普通の時代でしたから、時間はいくらあっても足りない。

PCが当たり前な今のPCできる=すごいという時代と違い、他人からPCできる=変人あつかいされた時代です。変人扱いされていたにもかかわらずそのすばらしさに魅了された人々は並大抵の努力でおさまりません。当時のPCを触る=(ほぼ)プログラミングでしたからプログラミングの時間数などあっという間に膨れ上がる。

昔はネットはなかったわけで書籍の力をかりながら自力で組むのがすべてでした。検索してすぐに結果を出せる今とは違うのです。書籍を買うにも学生には高すぎて月々のベーマガ+αが限界でした。SINとCOS組み合わせると円がかけそうだとか、シフトしてみたら値が倍になった!ATANで自機狙い弾ができそうだとか、キャラクタのジャンプにVという変数を用意してVを引き算しながらYに足したら滑らかに動いたよ!といったことを試行錯誤の上で身に着けていくのでした。

車輪の再発明どころの話ではない。今では調べたり聞けばすぐわかるものを何十何百時間もかけて組むのです。でも聞ける人はいません。PCもってる人は非常にマイナーでしたから。


そうではなくても、就職するまでPCを触ったことがない人であっても就職すれば毎日10時間プログラミングするのも別に不思議なことではないでしょう。一ヶ月に250時間とか普通ですし、年間で3000時間組むのも普通にありえることです。これでは1万時間をたった3,4年で達成してしまいます。そして作業効率が悪い人のほうがより天才に近いという不思議な現象が。

残業ほぼなしでも毎月160時間くらい働いた人は年間で2000時間。5年もたてば達成できてしまいます。


やっぱり天才と時間は直接的には関係ないよ。そうじゃなきゃプログラミングの天才はもっと出てこないとおかしい。

2008-11-16

[]BigDecimalひどすぎるといわれ続けて10年くらい

BigDecimalのプログラムめんどすぎ泣ける。

http://d.hatena.ne.jp/nowokay/20081116#1226837247

おいらも過去に何度も何度も書いてる話ですが、BigDecimalはStringと同様に特殊な扱いにして欲しいなぁ。

BigDecimal num1 = 1.23456bd;
BigDecimal num2 = 9.8765432bd;

BigDecimal result = num1 + num2;

とか、こんな感じで。floatはfをつけるし、longはlをつけるのと同じようにbdとかで初期化できるようにして欲しい。さまざまな初期化パラメータアノテーションで対応すればいいかな。あとは普通に演算子演算できるように。コンパイル時だけの問題だから容易に対応できると思うんだけどね。


Javaがいまだに業務アプリではCOBOLの足元にも及ばないのはこれが原因。COMPUTE命令のほうがどうみても楽だよね。桁についての制御も簡単にしてほすい。

ってJDK1.2のころからいわれ続けててたよね。つまり10年くらい。それともJavaはいまだに業務アプリにあまり使われてないとか。EoDって真っ先にこれやるべきだったろう・・・。

[]屋上や最上階の

デパートの屋上や最上階にあるゲームコーナーのワクワク感は異常。

http://www.pipitan.com/sb/sb.cgi?eid=1642

大人になってからいってみると意外と狭いことに驚いたりするものです。


閉鎖が相次いでますが、子供をここで遊ばせてその間に親は買い物をするという文化はもうないのでしょうか。悲しいですね。

[]Java2Dの大幅な高速化その2

昨日の続き。

昨日はfillRectしか試していなかったが、今度はいろいろと変えて実行してみる。昨日と同様に256000回のループで。

円描画

描画部分を以下のように変更。

g.fillOval(x*24, y*24, 16, 16);

結果

  • update6 4700ms
  • update10 3600ms

update10のほうが速いことは速いが、割合としての差は減ったようだ。差の絶対値としてfillRectのときと同じくらいの差があるようだ。ということはもしかして純粋にレンダリング性能以外の例えばページフリッピング等の処理に差がついたということか?


描画なし

ということで今度は描画を一切なしでテスト。

  • update6 40ms
  • update10 190ms

今度はupdate10の方が遅くなった。どうやらレンダリング以外が早くなったというわけではないらしい。Direct3DよりDirectDrawのほうがスループットは劣るがレスポンスがいいというのは常識なのでこれは納得する結果かな。

文字の表示

今度は文字を表示してみる。固定で"ABC"という文字列を繰り返したところあまりの差がでて驚いた。ここまで差がつくとキャッシュの問題とかバグかもしれない。というわけで'A'から順番に文字を描画してみた。

描画部分を以下のように変更。

char c = (char)('A'+x);
g.drawString(Character.toString(c), x*24, y*24);
  • update6 14400ms
  • update10 400ms

やっぱりとんでもない差がついた。ひらがなや漢字に変更したり表示する文字の範囲を増やしたりしたが、どれも同じくらいの結果になった。これだけ文字の描画が早いからこそSwingアプリが快適になってるのだなぁと認識した。


やっぱりupdate10はすごいっす。5.0以降0.1単位はなくすると宣言したためただのupdateになったが、本来だったら6.1という名前がついていたのだろうなぁと改めて思った。逆に今までクライアントに対してどれだけ力を入れてなかったのかがわかる。

Java同士での比較だけではなくてネイティブな描画との比較もできると面白いかも。もしくはupdate10のDirect3Dに対して、JOGLのOpenGLによる描画とか。

[]ツクモの危機を救う勇者達

http://gigazine.net/index.php?/news/comments/20081116_intel_core_i7/

破産じゃなくて民事再生なのでユーザーが離れなければ大丈夫。日本のPCの歴史において欠かせないお店なので勇者さんたちにはがんばっていただきたい。


で、肝心のCorei7ですが、発売前のベンチを見ると45n世代のCore2と比べてメリットがあまりにも少ない。8スレッドなのでメモリ3枚ざしという帯域の強化はたしかにいいのでしょうが、普及価格帯のCorei7はこの部分もメリットがないわけで。CPUを動かすのにバス経由でアクセスすることがなくなったので統合チップセットもかなり不利ですしねぇ。はやくCPU側にGPUが統合されることを願うのみです。

[]雪虫

今日は風がなく、ここ最近の関東の気温の高さもあってか雪虫をよく見かけた。

もうすぐ冬が来るのだろう。

2008-11-15

[]Java2DのFillRectですら大幅な高速化

元々アクセラレーションが効いていたはずのFillRectだが、update10にするだけで大幅に高速化するようだ。


            Graphics2D g = (Graphics2D) bufferStrategy.getDrawGraphics();

            g.translate(8, 32);

            g.setColor(Color.BLACK);
            g.fillRect(0, 0,640,  480);

            g.setColor(Color.RED);
            for(int y=0;y<16;y++){
                for(int x=0;x<16;x++){
                    g.fillRect(x*24, y*24, 16, 16);
                }
            }

            g.dispose();
            bufferStrategy.show();

これを1000回繰り返した場合

  • update6:1500ms
  • update10:300ms

なんじゃこりゃあ。速すぎる!アルファブレンディングとか使わないのならJava2Dでもかなりよくなってるとか。Swingアプリがupdate10で大幅に快適になったのはこういうのも関係ありそうだ。

[]代引きがなくなる

金融庁「代引きサービスは規制するね^^」、宅配業者「ふざけるなヴォケ」


これはひどい

少なくとも商品とお金を対面で交換してる時点で、破綻した場合でも消費者にとって問題が一番ない集金方法だと思うんだけど、金融庁は何を考えてこうなったんだ?他の支払い方法はすべて先払いだからむしろ面倒なことになるだろう。

[]JavaSE 6 update10でfpsが低下

update10にするといまや使わないShinGL2だけどフレームレートが10%くらい下がってる。それでもJ2SE5.0に比べるとはるかに速いけど。

ちなみにShinGL2はマルチスレッド対応のソフトウェアレンダリングなゲーム用お手軽ライブラリ。Java2Dはハードウェアアクセラレーションが聞かない描画だらけなこと、アルファブレンディングがまともに使えないこと、マルチコアが今後当たり前になるだろうなどの理由で自分でレンダリングしたほうが良いという結論で勢いに任せて作ったものだ。

つまり、描画そのものは関係ないのだ。単純にblitの問題というか。オフスクリーンバッファの生成方法がおそらく変わったのだろう。

マルチコアが流行るというのはとりあえず予想通りだったかな。今のマシンだとJavaですら信じられないことにハイカラーでQVGAレンダリングだと600fpsとか普通に出るので、8ビットカラーのQVGAソフトウェアレンダリングWindows超連射68Kが当時のマシンでぎりぎりだったのを考えるとなかなかに面白い。まぁ元々は68000-10MHzのマシンで動いていたものだしねぇ。



とりあえずJava2Dまわりについて調べよう。

2008-11-14

[]ここは否定したい

http://el.jibun.atmarkit.co.jp/yoshi/2008/11/post-895e.html

従来のプログラミングは、動くかどうかわからないコードをたくさん書いていって、最後にプログラムを動かし、エラーを直していく作業です。TDDはこの方法と違い、少しずつ動くコードに内容を足していきます。

十年以上の昔から少しずつ動くコード書くのが普通だったと思うけど。

COBOLとかコーディングシート書いてトライアンドエラーという文化もあったことはあったけど、PCの文化はわりとそういう細かく分割コンパイル&単体のチェックだったはず。

初心者ほど最初から全体の大きいコードを書こうとして躓いたり、全部出来上がってからはじめて実行して大量のバグつぶしに苦労しているという構図は昔も今も変わらないほほえましい光景と思うんだけど。


Javaを始めてみたときの一番の衝撃は、すべてのクラスにメインを書くことが出来て手軽に単体テストが出来るということだったよね。たぶん、他の人も10年以上前にJavaを初めて見たときそう思ったはずだよ。これでバグが大幅に手軽に減らせる、と。

[]忘れ物ですよ

http://d.hatena.ne.jp/nowokay/20081114#1226611827

つ「0x」


int age = 0x20;
System.out.printf("やあ、ぼくきしだ。%d歳!", ++age);

たぶん、こっちのほうが近いんじゃないかな。


16進数で思い出したけど、JavaやCは2進数表記ができないのがだるい…と昔は良く思ってたけど最近ビット演算あんまりつかわないからどうでもいいかとおもうようになってきた。BASICってやっぱりすごいよね。

2008-11-13

[]コードの意味はわからんがとにかくすごいベンチだ

http://d.hatena.ne.jp/nowokay/20081113#1226565440

頭の悪いおいらには何をやってるのかさっぱりだけど、ベンチマークにはなりそうだね!

CPU1個しか使ってないようなのでマルチスレッド対応するとベンチとして磨きがかかるね!世の中のベンチ取りまくってる人間の99%はどういったアルゴリズムかは理解しないで計測してるから問題ないよね!


Core2Duo E8400にて6分37秒ですた。2万きってる石のわりにはまぁまぁ快適。今じゃ1台まるごと7万台くらいで買えちゃうごくごく一般的な今では平均的なマシンスペックですがね。


感嘆符で連呼すると口にだしてないけどなんとなく疲れるね!空元気だけが売りだからね!

[]これ誰が買うんだ…

http://pc.watch.impress.co.jp/docs/2008/1113/dell.htm


V420シリーズのほうなんてスペックが高いわけではないのに12万円を超える。ビジネス向けとかいいつつOSVista Home Basic

CPUだけE8500搭載してメモリはVistaなのに1GBしかないし、HDDも容量が少ないし、DVDは読み込みのみで、オンボードビデオの価格とは思えない。

V220にしてもVista搭載でメモリ512MBって気が狂ってるとしか思えない。


バランスの悪さと値段の高さから売る気はまったくないのだなぁとか思ってしまう。CPUだけ早くて値段がアホみたいに高くてなんかバランスの悪さが昔のPCみたい。

[][]Java Expert #3 の献本が届いた

Java Expert#3 献本いただきました。ありがとうございます。


「まるごと!」という名前にふさわしいボリューム。NetBeansの特集で全ページの2/3近くもページを割いている。


で、軽く眺めてみたけど、NetBeans特集なんですが、NetBeansをすでに触ったことがある人には敷居は低いかもしれませんが、NetBeansを触ったことがない人には敷居がやや高いかなという印象を受けました。なんせ、おいらの記事以外マニアックすぎる。インストーラの標準構成でないプラグインの記事が多いです。

今頃遅いけど、敷居を下げるための記事というのも必要だったのかなぁとか思いました。たとえば、NetBeansのプロジェクトの構成とかインストーラでふくまれるプラグインの違いとか、基本的なショートカットの一覧とか、こういうときにはこのウィザードを使うとかそういう入門的なものが。

おいらのお勧め記事は、ずばり「NetBeansプラグイン開発のススメ」。NetBeansプラグインの日本語情報は壊滅的に存在せず、そのとっつきによいものだと思われます。さらに深く入って、「こういうときにはこうする」といった具体例をあげたこの先のの情報なんかも期待したいところです。


特集以外だと「AppletReloaded」が面白い。起動時間がちょー早くなったとかドラッグができるようになったとかいろいろと目だったパワーアップはありますが、一番のキモはjavascriptからの各種操作ですね。インストールされているJREのバージョン等を細かく調べたり、インストーラのページへ誘導したりといったおもてなしができるようになったところだと思っています。本当はu10ではなくて2年前のFCSでほしかった…。


そのうちおいらもNetBeansプラグインつくってみよーっと。

2008-11-12

[]とりあえず写真とってみた

http://d.hatena.ne.jp/shin/20081107/p2

の続き


NetBeansセミナーでJavaExpert#3の執筆者紹介があるというので自分でとって片貝さんへ送る。

動かしていて思ったけど、携帯の自分取りってむずかしいですな。鏡と違って左右反転しないものだから思うとおりにレンズをむけられない。正面見てるのもこっぱずかしいので横を向いてみた。

残念ながら「フォトレタッチをして実はイケメン大作戦!」はだれも応募がなくあきらめた次第だ。



へっぽこなおっさんのレアなはずかしい写真を見たい人は、11/19の「Java Expert #03 『まるごと NetBeans』 号 出版記念セミナー」へGO!だ

http://jp.sun.com/company/events/2008/000275.html


※ひがさんのような自分の顔をアイコンにできるくらいの度胸がおいらにも欲しい

[][]貧乏暇なし

不況のときこそ、開発者は勉強したほうがいい。時間が余っているんだから、自分にもっと投資しようよ。これはチャンスと考えよう。

http://d.hatena.ne.jp/higayasuo/20081112/1226467843

言いたいことはわかるけど、貧乏人はまず時間が余ってないと思うよ。結局時間はお金を使って作り出すもの。そう考えると格差は加速するのでしょう。逆に時間を消費して金を生み出しているのが仕事。


貧乏人は都内で仕事をしていても都内に家を構えることは出来ない。家賃が高いもの。そうなると長距離の通勤でかなりの体力と精神力を消費します。おいらの場合通勤で1日に使える体力と精神力の7割くらいは持っていかれてる感じです。それくらいハードなのです。

お金ない人はできるだけ外食しないよね。食材をかいにいって自炊します。安いスーパーのはしごなんて当たり前。移動手段は歩くか自転車。これだけで体力と時間がとられる。

仕事がなかなかみつからない人は仕事を探しますよね。勉強してる時間もない。いきたくても電車代ですらつらい状態ではセミナーとかいってる暇もない。

再来週くらいには餓死するかも、とかいうぎりぎりな生活をした人しかこの苦労はわからないだろうなぁ。



根拠のない人月計算の客先常駐開発案件をすべて断り続け、顧客と直取引で最適な設計やハード構成、社内のIT便利屋などまるごと面倒を見るという、納得した仕事のみを選択した結果ですわ。納得した仕事だと例えば今年でもWebアプリロジック含めて1日1画面とか超絶なことやってたけど、これ以上の効率化ってかなり大変だよね。Struts+生JDBCだったらたぶん作業期間は3倍はかかってたと思う。ひたすら試行錯誤して最適解を自分なりに考えてはいた。


それでもだめなんだ。不景気ってやつの前では。技術力とかをアピールするところまで行かない。例えば「業務アプリ1画面3万円で作ります」といったところで、だれも飛びつきはしない。保守も真っ先にけづられる。


最近の不景気で中小企業は直接的な金を生まないIT投資を見事にばっさりと切り捨てています。おそらくこの流れはしばらく続くでしょう。おいらの感覚では大企業の常駐案件ですら1年前の1/2くらいになってるんじゃないかな。そして余裕のない中小企業だとその比ではないということ。


この半年くらいで都内とか家の近くとかびっくりするくらい店がばたばたつぶれるのを見てると、やっぱり想像以上に不景気なんだなと思う。






まぁ勉強はし続けますけどね。ただ、今までと比べて大きく時間は減らさないといけないとは思います。

2008-11-11

[]Jersey 1.0でも生成されるJSONに不具合が

NetBeans 6.5RC2ではJersey1.0になってるので試してみた。(NB6.1までは0.8までしか上がらない)

結果。0.8からなおってねー。Javascriptとは連携できるけど、汎用的なデータ連携としてこれはないだろう・・・。実際GWTとやりとりできないし。

[]doLookupが泣いている

EJB3.1とかsunの技術資料でもテストコードでみんな

HogeBean hoge = (HogeBean)new InitialContext().lookup("hoge");

とわざわざ生成してキャストまでして書かれてる。sunにすら見捨てられたdoLookup涙目。もう4年以上前に実装されてる命令なのに。

Generics使ってキャストも自動でしてくれてるのに。たったこれだけでいいのに。

HogeBean hoge = InitialContext.doLookup("hoge");

[]DS ガールズモード…だと?

WiiをネットにつないでいるとWiiを経由してDS体験版ダウンロードプレイできるのは皆さんご存知のとおり。お店に行かなくても体験版が落とせるので引きこもりにはぴったりだぜ!


というわけで、せっかくなのでおいらみたいなおっさんがもっともプレイしないようなソフトを体験しちゃうよ!

http://www.nintendo.co.jp/ds/azlj/index.html

…やばい。面白い。

体験版では存在しないけど、自分で店の概観作ったり自分で衣服を仕入れて客に着せたり、店員である自分を磨いたりとやばいくらいの出来。

そもそもザ・コンビニはすきだったし、その原点だったはずのMマガだったかMSXFANあたりのMYSHOP(もう記憶があいまいでタイトル完全にわすれてる)とかそんな自分で仕入れて販売するゲームもとにかく遊びまくった。

それらを進化させたような出来。なんせ、他の作品のように客が勝手にお店で買い物をしていくのではなく、自分のファッションセンスと顧客の予算、要望、外観等を見ながらコーディネートしてあげるというアクションが取れるのが面白い。相手が喜ぶと、気に入ったからほかにもこのインナーに合わせて3点くらいみつくろってとかいわれると脳汁がでる。

ファッションに興味がないおっさんでもこれだけ面白いのだから、たぶん女性はもっと楽しみながら遊べるんだろうなぁとちょっと嫉妬。



さて、おっさんモードなるゲームでもつくる作業に戻るか…。

2008-11-10

[]擬似乱数に反応するやつは間違いなく・・・

http://d.hatena.ne.jp/nowokay/20081110#1226302607

所詮擬似乱数なので値の偏りがあるのは当たり前かと。でも、種を0から5000にすると少し緩和されますし、5000から10000では偏りを探すのは難しいという結果が出ました。きしださんのいう5000から10000が偏るというのが再現できませんでした。

で、こういった擬似乱数を扱う場合、種が重要です。8bit時代から種の値には時刻を使うというのが常識でした。今回も時刻を入れると偏りはまず出ません。

r.setSeed( System.nanoTime() );

んで、調べるとわかりますが、種を入れない場合これ使っています。つまり下手にやるくらいなら何もしないほうがまだ安全というわけです。

乱数の調整なつかしいですね。なんか20年前を思い出します。ゲームでは頻繁に使う(最近だとリプレイの維持のために自作するのが多いですが)基本的なものだけに、当時からいろんな試行錯誤がありましたけど、「種はマイナスだろJK」、「RND(-1)ですねわかります」という人は間違いなくおっさん技術者

[]JavaSE 6 update10でのアプレットの起動時間

update10での改善点にアプレットの起動時間短縮というものがある。

というわけで試してみた。update7以前で計測していないため、比較は出来ないのだが確かに問題になる時間はない。しかし、もともとSunのJDKでは大幅に改善されており、特にhotspot VMになってから大幅に改善された。hotspotVMのコアの技術はサーバーサイドで恩恵がそんなにあるものではないということ。

Appletが遅いといわれた理由はずばり当時のブラウザの主流であったNetscapeに搭載されたシマンテックJIT VMにある。コンパイルしてから起動するので非常に速度が速く、ベンチマークでも圧倒的な速度を誇っていたのだが、起動時間がすさまじく遅く、インタプリタ時代のほうが使いやすかったというオチがついたのだ。1分とかブラウザが固まるってのはとんでもないことだとは誰も思わなかったのかねぇ。

その反省点からhotspotVMの開発が始まったと考えると悪いばかりではないと思うのだが、ちゃんとそのままアプレットが普及していれば少なくとも現在のWebアプリのような陳腐なHTMLを組み立てるWebアプリがこれほど普及することもなかったし、リッチクライアントの技術競争が激しくて面白かったのかもしれない。


起動後初回起動

マシンを起動し、ブラウザのみを立ち上げて、アプレットのあるページを表示。

何度か再起動させたが、おおむね3秒。まったく問題ない速度だね。これが10年前に実現できていれば・・・。


ブラウザ再起動

ブラウザ再起動し、アプレットのあるページを表示。つまりJavaアプレットプロセスの起動時間の計測。

何度も確認したが、おおむね1秒以内に表示される。ブラウザをこまめに閉じる使い方をする人も多いので、これも問題ない速度なのがわかる。

アプレットのみ

一度アプレットを表示し、ブラウザはそのまま他のアプレット等のあるページを表示。

ずばり0秒。



はは・・・アプレット全然問題ないやん。今後はアプレットで作ろうかなぁ。でもJNIまわりが面倒だからやっぱりアプリケーションにしようかな。アプレットが動くということはスタンドアロンJavaアプリケーションも起動するわけで。入り口としてアプレット、本格的なアプリアプリケーションスタイルということになるかな。通常のアプレットでもJNLPが使えるようになったおかげでWebStartアプレット(元々使ってる人少ないけど)の存在意義はなくなったかな。ドラッグデスクトップにおけるようだし。


Javaは元々サーバーサイドの技術用に作られたのではなく、クライアントサイドで動くように作ったのがはじまり。したがってJavaクライアントアプリを作ることこそがもっともJavaの本質をあらわす・・・ことになるよね?はてなキーワードからいろいろとみてると、Javaサーバーサイドの話ばかりでつまらんよね?仕事ならともかく、趣味でもサーバーサイドばかりなんてなんとつまらんことよ(暴言)。

Webアプリよりはるかにゲーム開発のほうが敷居は低いのになんでネットで情報が少ないんだろう。書籍にしても10年以上の歴史がある中、Javaのゲーム関連書籍でまともに書かれてるのが1冊しかない(15歳からはじめる〜とかいうやつ)という時点でおかしいんだよ。

というわけでJava使いはみんなゲームつくろうぜ。DRAGON 'J' SPIRITとかそういうの楽しいだろJK

2008-11-09

[]JDK6 update10とupdate6のGC比較

update7はいれてないのであしからず。update6とかわらないでしょう。たぶん。

GC比較といえば5.0と1.4.2との比較以来だなぁ。

比較対象アプリPureWind。2面ボスが強くなっていたので未公開バージョンのような気がするけどきにしなーい。しばらくまともに触ってないから忘れていただけともいう。

GCバックグラウンドで音楽をロードしてるときとか、OggVorbisを最後までデコードした場合とかで激しく結果が変わってくるので、場面ごとに。

VMオプションはいつものとおり。特に珍しい設定にしているわけではない上に、これJ2SE5.0のときにチューニングしたやつだから6.0だと最適にはなってない気がする。

1つの面で使用するヒープ容量を把握しつつ短い時間のGC時間がやってくるようにする。つまり、スループット重視ではなくレスポンス重視というわけだ。クライアントサイドのアプリでは5分ごとにやってくる1秒のGCよりは10秒ごとにやってくる100msのGCのほうがトータルでGCにかかる時間は増えているが、レスポンスという点ではるかにましということ。ゲームならなおさらだよね。

-Xconcgc -XX:MaxTenuringThreshold=1 -XX:+UseParNewGC -Xms28M -Xmx28M -XX:NewSize=5M -XX:MaxNewSize=5M -XX:SurvivorRatio=2 -noclassgc

タイトル起動まで

update6の結果

[GC 2528K->1107K(27392K), 0.0069923 secs]

[GC 3207K->1518K(27392K), 0.0040060 secs]

[GC 4078K->1893K(27392K), 0.0026673 secs]

[GC 4453K->1941K(27392K), 0.0011367 secs]

[GC 4471K->2102K(27392K), 0.0006493 secs]

[GC 4662K->2184K(27392K), 0.0005659 secs]

update10の結果

[GC 2539K->1002K(27392K), 0.0069967 secs]

[GC 3562K->1519K(27392K), 0.0043149 secs]

[GC 4079K->1768K(27392K), 0.0021547 secs]

[GC 4328K->1720K(27392K), 0.0010736 secs]

[GC 4280K->1918K(27392K), 0.0005505 secs]

[GC 4478K->2108K(27392K), 0.0010216 secs]

1面ボス戦

update6の結果

[GC 9186K->7692K(27392K), 0.0017684 secs]

[GC 10252K->7920K(27392K), 0.0013299 secs]

[GC 10480K->7817K(27392K), 0.0003274 secs]

[GC 10373K->7525K(27392K), 0.0002452 secs]

[GC 10085K->7427K(27392K), 0.0019945 secs]

update10の結果

[GC 8839K->7141K(27392K), 0.0007819 secs]

[GC 9701K->7677K(27392K), 0.0012102 secs]

[GC 10237K->7809K(27392K), 0.0005093 secs]

[GC 10369K->7479K(27392K), 0.0002434 secs]


2面ボス戦

update6の結果

[GC 5247K->3846K(27392K), 0.0017363 secs]

[GC 6406K->3965K(27392K), 0.0011171 secs]

[GC 6525K->3931K(27392K), 0.0003209 secs]

[GC 6487K->3915K(27392K), 0.0017912 secs]

[GC 6474K->3915K(27392K), 0.0017794 secs]

[GC 6475K->3913K(27392K), 0.0018668 secs]

[GC 6473K->3921K(27392K), 0.0003548 secs]

[GC 6481K->3913K(27392K), 0.0002476 secs]


update10の結果

[GC 5732K->3703K(27392K), 0.0008781 secs]

[GC 6256K->3121K(27392K), 0.0003059 secs]

[GC 5676K->2921K(27392K), 0.0002617 secs]

[GC 5481K->2824K(27392K), 0.0002623 secs]

[GC 5384K->2798K(27392K), 0.0003003 secs]

[GC 5358K->2787K(27392K), 0.0002501 secs]

[GC 5347K->2787K(27392K), 0.0002806 secs]

[GC 5347K->2787K(27392K), 0.0002584 secs]

[GC 5347K->2787K(27392K), 0.0002534 secs]

[GC 5347K->2801K(27392K), 0.0002756 secs]

[GC 5361K->2795K(27392K), 0.0002607 secs]

[GC 5355K->2785K(27392K), 0.0002469 secs]


あーあきらかに違ってる気がする。省メモリっぽい。あとGCにかかってる時間も全体的に減ってる傾向が。通常同一のバージョンだとupdateが変わったくらいだと大きく変わらないはずなのだが、update10とそれ以前とでGCのはいるタイミングとか結構違う感じ。

とりあえず2面ボス戦のほうでGC時間が1msかかってないのがすばらしい。250マイクロ秒前後で安定しているようだ。

あとはGCをしてもいいタイミングをVMに通知することが出来るようになればJavaでリアルタイム性があるアプリもかなり大丈夫な予感。

[]update10でいろいろ動作確認

V2Cの範囲選択が遅い以外はむしろ、ホイールスクロールなどがきれいに回るようになった感じでむしろ軽くなったようだ。そもそもJavaSE6になった時点でJ2SE5.0から大きく速度向上しているのでJ2SE5.0やJ2SE1.4を触っている人がJavaSE6update10を触ったらびっくりするんじゃないかな。


自作の縦スクロールSTGであるPureWindで動作を確認した。とりあえずクリアまでやったが特に問題はなかった。


NetBeans6.5RC2を起動。予想通り問題はない模様。軽いかどうかまではわからなかった。ビデオ周りよりCPU回りのほうが重要だと思うのでむしろバージョンが上がったhotspotVMの動作のほうが影響するのかも。

[]JavaSE u10だとV2Cの文字選択動作が遅い

テキスト表示した文字の上をドラッグすることで行う文字列の選択が瞬時に行われない。非常に遅い。なんだこれ。

文字が少ないと早くて増えるにしたがって重くなるようだ。

update6で起動してみると問題ない。うーむ。update10はやはり大きな変更が入っているようだ。これはいろいろとしらべなくては。

2008-11-08

[][]やはり勉強しないほうがいいのか


勉強をしていると、もっと開発効率が良い、バグが出にくい、仕様変更に強い開発手法などをしっていくわけですよ。そうすると5年以上前のやり方で押し進められるのが精神的にきつく感じてくる。これがもし勉強をしていなければ疑問に思わず、ひたすら土日も残業してやるわけです。

残念ながら効率よく開発するための打ち合わせや勉強会を開いて残業なくそうぜという流れにはなりそうな気配がない。というのは開発期間によって、拘束時間によってのみお金が発生するから。出来上がるものの品質は関係ない。そういう意味ではStrutsは最高のフレームワークだし、これを超えるフレームワークは今後まず出てこないわけです。


この業界ではList<E>の「E」ってなに?という人がおいらの3倍くらいお給金もらってるわけですよ。今もJPAJSFだと3日くらいで出来上がる品質のものを生Struts+直JDBCで2週間以上かけて開発しています。愚痴りたくもなるものです。


このまま勉強するとますます仕事がなくなると考えると、やはり長期的な視点で勉強をやめるか、IT業界から足を洗うかしかないのかなぁとまじめに考えています。年を食ってくると土日休みなしで終電くらいで帰る生活を続ける自身がないので前者はありえないですから、なにか考えないと。やりがいがある仕事なら残業しても精神的に楽ですからまだいいんですけどねぇ。


あんまり愚痴ばかりいってるとNetBeansアイドルのきしださんががっかりしそうなので、あさってまでにまた何か技術的話題載せるぜ!ネタないけど!

[]日本IBMもか・・・

日本IBMのリストラが始まった

日本IBMも関係あるんですね。というか、リストラという文化をもちこんだのは日本IBMだったのか・・・。

日本で1000人をこえるリストラってかなりの規模ですよね。しかも日本では流動化してないからたちが悪い。

[]NetBeans 6.5 RC2でVisualWebJSFをさわる

まず6.1までバグバグだったスタイルのプレビュー機能が直ってる。かなり便利になった。というか、5.5時代にやっと戻った。素直にうれしい。



Woodstockコンポーネントは基本的に使いにくいのは変わらず。scriptによるコンポーネント生成(DOJO)でブラウザによる不具合が出やすいので、JSF標準コンポーネントを使うようにしようという方針もかわらないようだ。

せめてJSF1.2のプロパティくらい追加してもらわないと正直困る。いまどきJSF1.1なんて誰もつってねーよと。

woodstock全般としてラベルが必ず表示されるのが「非常に」困る。ラベルプロパティJSFで意味のあるプロパティだからだ。非表示にできるといいんだけどね。また、ラベルの表示の強弱があるのだが、これにバグがあるようだ。「弱」と「中」が同じサイズで描画される。「強」だけ大きい文字で表示される。「中」の意味がない。

また、デザイン時は「弱」と「中」が同じで「強」が大きいタイプ、「弱」と「強」が同じで「中」が大きいタイプなど文字の大きさがコンポーネントの種類によってかわったりする。なんじゃこりゃぁ。woodstockコンポーネントは使い物にならないからまともに実装してないのかな。



woodstockコンポーネントの中でもカレンダーコントロールは使いやすくなった気がする。それでもdateFormatPatternプロパティでカスタマイズしても反映されないバグがある模様。一度編集した項目から選択行を移動させて再度選択しなおすか、一度ダイアログを閉じてからまた表示させて、選択しないとこの項目が未設定状態になるようだ。

さらにいうと、ポップアップカレンダーの描画が崩れているのが気になる。というかすぐにわかるのでやばい。ついでにフォントサイズを少しでも変えるとそのほかの描画が崩れだすし、使えそうなコンポーネントバグを仕込むのがwoodstockはあいかわらずうまい。

というか致命的バグだった「カレンダーコンポーネントの日付が一ヶ月ずれるバグ」がいまだに長期間(確かNB5.5のときからだから2年以上はあるということかな)絶賛放置中で直ってないことを考えると、woodstockはやっぱり使っちゃダメなのかなぁ。JSF2.0では自作コンポーネントが作りやすくなる予定らしいからそっちに期待するべきか。でも、一番の問題は独自のコンポーネントを作るより、コンポーネント登録用のセットアップが激しく面倒というあたり、JSFの改善だけではどうにもならない気がする。NetBeansJSFのメニューからオリジナルコンポーネントの作成とかがないとね。


もう、パレットの初期表示は標準グループを上のほうにしてよ。間違って初心者がwoodstockコンポーネントを触ってバグに悩まされるのを見ているのがつらい。5.5.1あたりまではwoodstockという表記がなかったので被害は甚大だったから、それに比べると今の状態でもまだよくなったほうだけど。あとNetBeansのサイトにあるサンプルはwoodtockコンポーネントを使ったものばかりだから、純正のヘルプが正直参考にならないというのはJSFにとってかなりの痛手かと。

6.1で追加されたバルーンとメニューという使い勝手のよさそうなコンポーネントはあいかわらず実装しにくい。javascriptで呼び出しのコードをガリガリ書くって信じられない・・・。状態が変更されたらsubmitが自動的に呼ばれるというscriptは用意されているんだから、同じようにやってくれないと。


標準コンポーネントではリンクアクションコンポーネントのtargetバグはあいかわらずあるようだ。これを実装したい場合はwoodstockコンポーネントハイパーリンクを使うという回避が今回も必要になるようだ。

軽く1時間触って気がついたのはこんなところかな。

[]ワギャンランドが15年ぶりに復活

http://www.watch.impress.co.jp/game/docs/20081107/wa.htm

キャラ絵が微妙に見える。ポリゴンだろうか。ドット絵のほうがいい気がするが、この辺は動いてるものを見てみないとなんともいえないかな。

メニューとかはひらがな表記でちびっ子も安心して選択できそうに見えて、メッセージに漢字を使っているというナムコの配慮のたらなさが非常に気になる。普通に考えてメッセージに漢字使うならメニューも漢字を使えば?と。誰をターゲットにしたいのかわからない。

ちなみにゼルダの伝説DSは漢字の部分をタッチすると読み仮名が出るという非常に親切設計で、小学校に入っていないおいらの甥っ子も遊べていたのを考えるとこの辺がナムコとニンテンドウの差かと思いたくなる。

低年齢層もターゲットに入っていそうなお子様も普通に遊べるはずのまちがい探しミュージアムもメニューに平気で漢字とか英語をつかっていて、読めなくて遊びたくても先に進めず遊べないという状態でひどくがっかりしたものだ。なぜかひらがなばかりの場面と平気で難解な漢字が大量に出てくる場面とまざったりしてユーザーのことを何も考えちゃいない。今のナムコってこんなやつしかいねーのかよと。ゲームそのものはしっかり作っていてもUIがだめすぎた。

UIといえばテイルズオブシンフォニア ラタトスクの騎士もだめな部分がいろいろと見受けられていたし、そういうのをチェックするというのが社内的にないんだろうね。

2008-11-07

[]この価格でこのスペック・・・

http://pc.watch.impress.co.jp/docs/2008/1107/dospara.htm

ほえー。バランスがいいな。メールとWeb以外にもいろいろと使えそうなスペックをもちながら、何とか持ち歩けるくらいの重さ。低価格マシンって重いとかバッテリが1時間持たないとかスペックが非常に低いとかとんがってるのが普通だが、この価格でこのスペックはすさまじい。OSXPなとメモリが2GBもあるのがすばらしい。

[]さてまいった

NetBeansセミナーでJavaExpert#3の執筆者紹介で、写真や似顔絵をのせたいということを片貝さんに言われたのだが、似顔絵なんて書いたこともなければ書かれた事も一度もない。

そして写真は10年以上前に集合写真を1度とったことがあるっきり。写真撮られると魂抜けるから危険だしね。


うーんまいった。提出できるものがない。どこかにカメラに自信があるひとはいないだろうか。ブサメンをイケメンに見えるようなテクニックの持ち主とか。もしくはフォトレタッチが非常にうまい人とか。原形とどめないくらいイケメンに修正してほすい。

最悪自作STGのPureWindのアイコンスクリーンショットでも送ろうか。

[]はてなキーワードがおかしい

過去のブログを見ると現在表示されているblogが延々と繰り返される。

昨日ははてなダイアリーが応答なしが頻繁に起こってまともに使えなかったけど、キーワードに関してはパフォーマンスがどうだとかそれ以前の問題のようだ。

[追記]

現在では直っています

[追記]

と思ったけど、直ってない。どうやら種類による模様。キーワードタブのblogの一覧に出てこなくて、blogタブに切り替えるとでてくるような場合のみに発生する感じかな。

2008-11-06

[]エリアルの途中で交代できるんかー

http://www.watch.impress.co.jp/game/docs/20081106/tatsu.htm

エリアルの途中で交代できるのかっちょええな。しかし、人気のなさそうなアレックスは・・・いらんような。スト3で主人公になる予定がなんかなりきれなくて、豪鬼春麗などスト2のキャラがでるようになって影が薄くなっていったという・・・。

[][][]Java Expert #3に記事書きました!

Java Expert #3に記事書きました!記事を書くというのは今回が初めてです。10年前のmkeiさんに少しは追いついたでしょうか。

http://gihyo.jp/book/2008/978-4-7741-3677-6

今回はNetBeans特集です。NetBeansをいつもいぢめているせいか(ぉ)、Sun Microsystems橘さんから声がかかりました。メールを返信したら数日たってスパムサーバー認定されてるからはねられたとの結果が返ってきてあせったものです。共用レンタルサーバーじゃつらいですなぁ。

というのがこれです。当時ほとんどの人には意味不明な文章でしたね。すみません。

6月あたりから7月の下旬あたりまで、句読点がかわっていたのはこの記事の作成のためでした。あとから気がつきましたが、Fepの設定変えるんじゃなくて置換すればいいだけでした・・・。




NetBeansによる実践的Webアプリ開発のコツ」という記事を書きました。見出しはおいらが作ったわけではないけど、「コツ」といえる部分が仮想フォームやレイアウトインスペクタくらいと少ないのがちょっと残念です。^^;

というのもサンプルアプリを動かすだけで大幅に予定していたページを超えてしまい、技術評論者様には迷惑をおかけしてしまったのでした。本当は突っ込んだ部分をたくさん書きたかったのですが、大幅にページや画像などを削減しています。見積もりが甘すぎました。



そもそも使用するフレームワークがVisualWebJSF(JSF)+EJB3.0JPAという組み合わせな時点で、それらをNetBeansからどう扱うかという説明をしていくだけでページ数がどんどん減っていくのは当たり前だったかなぁと。フレームワークを3つも使っているわけですから。かといってEJBを抜いたところでトランザクション管理を自前で行わなくてはならず、その設定がほぼすべてNetBeansによって自動生成されるEJBをはずしたところでページ削減につながるわけでもなく、メリットもなかったというオチが。

とりあえず画面はぽとぺたで開発しつつ、コンテナ管理のトランザクション、面倒な設定いらずのO/Rマッピングという組み合わせを紹介してみました。そのほとんどはNetBeansによる自動生成ですので純粋にロジックに集中することが出来るはずです。



個人的な地味なポイントはDataModelを使っていないところでしょうか。DataModelがGenericsを使っていなくて、ラップされるデータはObject型のままで、何が格納されているのかわかりません。また、リスト等の更新があった場合それをセットしてあげる面倒くささもあります。

なによりデータ表を使うときどのプロパティがどのデータ表と対応するのかがわからなくなります。データ表が増えると見通しの悪さはかなりのものになってきます。それくらいならば思い切ってコレクションをそのままデータ表に渡し、どのデータがどの表に関連付けされているのか一目瞭然にしておいたほうがメリットが大きいと思ったためです。この辺は実際にVisualWebJSFを使ったアプリケーションをいくつか作成していると自然と身につくところだと思います。

[追記]

ちなみにこのエントリの続きが書かれなかったのはそういうことです。ぜひお買い求めください^^;

2008-11-05

[]ドコモの冬モデル

おお、SBと同様にシャープが8M/CCD搭載しています。

http://k-tai.impress.co.jp/cda/article/news_toppage/42597.html

やはりカメラ重視という方向もあるときがついたのでしょう。確かに最近の携帯のハイエンドカメラはひどいですからねぇ。ローエンドは全体的に画質は上がっているとは思いますけど。

カメラといえばもうひとつの雄であるカシオが今回も画質重視でこなかったのが悔やまれますが、来年の夏モデルあたりには復活してるでしょうか。

[]VirtualBox

最近VirtualBoxをいじっているのだが、動作が比較的軽くなかなかよいものですなぁ。

ただ、CentOS4が入らないのが痛い。正確には入るのだが、画面の描画が崩れてメニューの判別も出来ないので使い物にならないのだ。ちなみにCentOS5は動く。が、RHEL4ベースのシステムも多いためにこれの検証が出来ないのは痛い。

あとはLANの接続が面倒なところが厄介か。どうもホストとブリッジ接続しないといけないようだ。そしてこれはVirtualBoxを起動していないとケーブルの切断というマークが表示されてうざいことこの上ない。


VirtualPCが有料時代に購入したくらいなので、こういう仮想系はすきなのだが、いまや無料でかなりのものが動く。マルチコアなため、仮想化されたマシンがCPUを100%使い切ってもまだ余裕があるというのも大きいだろう。でも、VirtualBoxは起動してるだけでなにもしていなくてもずっとCPU使用率が高いのはちょっといただけないかな。

[]Java SE 6 のドキュメントが消えた

http://java.sun.com/javase/ja/6/download.html

確かupdate10の登場前まであったJava SE 6の日本語ドキュメントが消えたようだ。

なにこれ。管理者が間違って消したとか。


つまり今後はEclipseIdea使いもドキュメントを見たいときはNetBeansをつかえ(NetBeansプラグインで日本語ドキュメントの追加ができる)ということかな。


[追記]

11月17日時点で復帰しているのを確認しました。

2008-11-04

[][]NetBeans 6.5RC + Glassfish V3 で VisualWebJSF + EJB3.1 + JPA

この組み合わせだとなぜかGlassfish V3にデプロイが出来ない。仕方がないのでデプロイGlassfish V3の管理ツールでwarを配備。特に手間ではないけど困り者。GlassfishV3が標準でついてくる割には連携がいまいちだなぁ。まさかこのまま正式版が出なければいいのだが。

今回はボタンをクリックしたらJavaDBサンプルテーブルのCustomerテーブルの一覧を表示するというシンプルなものを。


プロジェクトをVisualWebJSFで作成。

EJB3.1は標準で動かないのでGlassfishV3のアップデートで追加した「javax.ejb.jar」をプロジェクトのライブラリに追加する。

JavaDBのサンプルデータからエンティティクラスを自動で生成する。ここまでは2年前のNetBeansでもやっていたことで特に不思議ではない。いまどき全部手で作るやつもいないだろうし。


SessionBean1.javaに以下の文を追加する。

    private List<Customer> customerList;

    public List<Customer> getCustomerList() {
        return customerList;
    }

    public void setCustomerList(List<Customer> customerList) {
        this.customerList = customerList;
    }

続いてEJBの作成。EJBといってもアノテーションがついてるだけの普通のクラス。JTAとかAOPとかデータベースの設定とかそんなのは考えなくても良い。NamedQueryも自動生成されているのでそれを使う。NetBeansJPAサポートはすべての項目単体で検索が出来るように最低限のNamedQueryは自動生成することが出来るのだ(デフォで作成する)。

package visualwwebjsfxejb31.ejb31;

import java.util.List;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import visualwwebjsfxejb31.entity.Customer;

@Stateless
public class CustomerLogic {
    @PersistenceContext
    private EntityManager em;

    public List<Customer> getData(){
        return  em.createNamedQuery("Customer.findAll").getResultList();
    }
}


最後にPage1.javaに以下の文を追加。もちろん画面もぽとぺたで貼り付けてある。


    public String button1_action() {
        getSessionBean1().setCustomerList( logic.getData() );
        return null;
    }
    @EJB
    private CustomerLogic logic;


実行。ボタンをクリックすると以下のようになる。


画面はGUIで配置できるし、ビジネスロジックはただのアノテーションつけたクラスがEJB3.1になってトランザクションとかDIとかやってくれるし、あとは画面とのリンク用にプロパティを用意するだけ。テーブルだから今回はコレクションにつめただけ。

おそらくJavaのWebアプリでもっとも早くこの画面を作れる環境だと思う。

シンプルすぎる。もっともearとejb-jarインターフェースを使う状態ならば現行のJavaEE5+NetBeans6.1でOK。

2008-11-03

[]NetBeans6.5RC2 JavaSEアプリ

Swingでの開発時に自動生成されたアクションイベント等のメソッドがちゃんと字下げされるようになった。6.1ではなぜか字下げがされていなくてびっくりしたものだ。

そのほかこれも構文解析の不具合なのか背景色がめちゃくちゃになるのが普通だったのが、6.5では今のところ再現しない。

軽微なバグ修正とはいえ、かなり精神的にきついものがあったので一歩前進したと思ってよい。


しっかし、JavaEEな開発環境に比べるとJavaSEの開発環境の軽いことよ。

[]血液型ゲノム

血液型ゲノムやってみたよ!を見てそういや9月あたりにそんなのやったなぁと思い出した。結果アップしてなかった気がする。


というわけで、もう一度やってみる。回答は一部変わってるところがある気がするけど、たぶん結果は変わっていない。

http://blood-genome.com/d/112008/11311/1139271026/


結果はまぁ全体的にはあってると思うよ。というかだれにも多少あうように作られてるんでしょ?気分で仕事の結果が変わるなんて誰にでもあることだと思うし。


性格

>なかなか他人に理解され難い人で、あなたはさらに常軌を逸しています。

>人の予想の斜め45度上の結果を出します。

仕事

>それはあなたはどちらかというと変だからです。

恋愛

>熱しやすく冷めやすいところがあります。

でも、このへんはあってないよ!真面目な人でとおってるよ!(タブン)

2008-11-02

[]930SH の情報続き

http://plusd.itmedia.co.jp/mobile/articles/0811/01/news016_2.html

シャッタースピードが速いことやISO感度が2500までいけること(910SHでは800まで)などアピールするべき部分は多い。

910SHに引き続きNDフィルタがはいったのもよい。910SHはF値3.5と暗いレンズだったがこの表記を見る限りF値は2.8なのかな?だとしたらかなり期待できそう。

デジカメスタイルで操作が出来ないのはまぁ我慢すればいいか。902SH、903SH、910SHとデジカメスタイルでとれてたからとまどいそうだけど。メニュー操作は結局通常のスタイルで操作することが多かったのでなんとかなるかな。

ちなみに半押しによるフォーカスロックは最悪のバグ携帯である902SHが一番よかったという皮肉。背面液晶もこの中では一番見やすかった。

[]EJB 3.1を以前触ったときとくらべてみた

どうも今日も体調が優れないので小ネタで。

NetBeans6.5RC2をいれたのでいろいろとテストを。今日はGlassfishV3のアップデートセンターが動いているようなので更新リストを見るとEJB3.1の更新があった。早速入れる。あいかわらずWebアプリしか使えないけど。

Webプロジェクトにjavax.ejb.jarライブラリに追加。これで準備はOK。

以前と同様にStatefulやMessageDrivenは動かない模様。Singletonは動くようになった模様。ローカルのJNDI名の登録も以前のような不思議なものではなく、それらしいものにちゃんとなったようだ。Statefulを使わないアプリも多そうだからこれだけでもかなり実用的といったところかな。


ログを見ると実装クラスのみは「no interface view」というらしい。インターフェースがある場合は「business view」。

JNDIの命名規則は

EJBタイプJNDI名
no interface viewjava:global/warファイル名/実装クラス名
no interface viewjava:global/warファイル名/実装クラス名#実装クラス完全修飾名
business viewjava:global/warファイル名/実装クラス名#インターフェース完全修飾名

となるようだ。

つまり、実装クラスだけの場合2つ登録される。また、「#」のあとに完全修飾名があることで、複数のインターフェースを実装した場合、どちらのインターフェースで取得するかが選択可能というわけだ。


1つのインターフェースで複数の実装クラスがあった場合、どちらを使えばいいのかわからないため、デプロイ時にエラーではじかれる。business viewの場合は@Localを省略しないほうがわかりやすいかもしれない。


JNDI名に完全修飾名が必ずつくことによってJavaEE6対応以外のフレームワークも対応がしやすい・・・といいなぁ。

GlassfishV3上でVisualWebJSFも動くようになった模様。もうこれで大概のアプリは開発できそうだ。あとはVisualWebJSFがJSF2.0対応してJPAも2.0にあがれば、まじで標準APIのみで十分やっていけるだろう。

体調がよければ明日あたりGlassfishV3上でJSF2.0 + EJB3.1 + JPA1.0をやってみたい。JPAはまだまだ2.0がでそうにないから、仕方がない。


ずっとEJBは3.0からDIコンテナの中でも最も敷居が低いといい続けてきたのだが、JNDI名が標準化され、ejb-jarが必要なく、war単体で使えるようになった3.1はもっとも手軽に扱えるコンテナになったと思う。よくあるDIコンテナのようにトランザクションAOPがどうだとかそういうことを考える必要がないから。セットアップが容易ってのはやっぱり重要。標準APIだけに別途jarをセットアップしたりする必要もないし、各種IDEでもサポートされることだろう。

個人的にURLを意識するアプリはフロントエンドをT2FrameworkビジネスロジックEJB3.1管理ツールや業務アプリはJSF2.0 + EJB3.1という組み合わせがベターになるのかなと。さらにRESTやりたいのならJAX-RSで、SOAPやりたいならJAX-WSで、ガリガリ書きたいのならwicketで。

ビジネスロジックを共通化したいのならejb-jarにしてこれら複数のwarからのビジネスロジックのリクエストをうけれるようにするといいかと。フロントエンドに依存しないビジネスロジックに特化したコンテナという姿がやっと日の目を見る気がします。ejb-jarでリモートインターフェースならばEJBクライアントとしてSwingなどのアプリから高速にアクセスも可能ですし。


[追記]

EJB3.1 EJB 3.1キーワード作ってみた。

[]バーチャルコンソール 11月ラインナップ

ファミリーコンピュータ

メガドライブ

スーパーファミコン

セガマスターシステム

PCエンジン


注目はドラゴンバスター伝説のオウガバトル、カダッシュ、ヴォルフィード、風の伝説ザナドゥあたりでしょうか。本数は少ないものの、名作がやけに多いです。

ドラゴンバスターアーケードと比べるとキャラがしょぼいとか音楽が悪くなりすぎといわれたものですが、斜めジャンプが容易になったり(4方向レバーで斜めジャンプはつらかった)アイテムが大幅に増えたり、性能が低い家庭用へ移植するにあたって何が必要かがわかっていたような作品でした。

[]サンダーフォース6は見事に

玉砕したようですな。内容的に。一番の問題である「サンダーフォースっぽくない」ってのは致命的だなぁ。

内容が良くてもこれがあるだけで文句いわれる理由には十分なのにね。例)グラ5

[]@ResourceはJNDI以外で使ってはいけない

アプリケーションサーバーはデプロイ時に@Resourceという部分を見つけるとリソースの準備を始めます。

Spring2.5では@ResourceをJNDIに関係なくSpringのBeanのインジェクトに使用できるのですが、そういう使い方をするとデプロイ時にスタックトレースが大量に出る原因となります。実際Glassfishではでます。

というわけで、Beanのインジェクト専用の@Autowiredを使うようにしましょう。


そもそも@ResourceはJNDI専用に定義されています。似たようなインジェクトの動作をするからといって安易に同じアノテーションを使いまわしするというのは正直考えられませんね。同じ@Resourceを使うにしてもパッケージは変えるべきです。紛らわしいですが、別物にしている分まだましです。

本来の動作が定義されているのにそれを違う意味で扱うというのはやめましょう。例えば今回はJavaEE5/JavaSE6の知識がある人ほどJNDIアクセスしてるんだな、と錯覚するわけですから。

2008-11-01

[]Loggingについて

http://d.hatena.ne.jp/kkawa/20081030/p1

おいらも最初はそう思いました。なぜ簡易メソッドはメッセージしかよべないのかと。


でも、ロギングAPIって生で使うことはなくて、各種プロダクトで用意するラッピングするロギングを使うと思います。


以前のFileReaderが使いにくいとかいう議論と同じでJavaは小API主義で生APIを用意しているだけです。使いやすくしたければラッパクラスを用意すればいい。Win32API直アクセスが使いにくいよ!といってるのと同じです。

java.util.Loggingを利用したラッパクラスはみんな作ってると思いますので、今のままでもさほど困ることは誰もいないと思います。標準APIに必要ならばラップされた簡易アクセス用のクラスを追加で用意するほうが従来のユーザーの妨げにならないでいいかもしれません。

エラーのログを出したい場合staticインポートを用意したりすると、

try{
・・・

}catch(Exception ex){
  error(ex , "えらーですよ[%s]  errorNo:%d" , "hoge", 123);
}

こうなりますよね。特に問題になるようには見えません。クラスも1個だけでいいですし、標準APIだけに依存しますし問題はないでしょう。

こうなるログライブラリはどこの小規模なプロダクトでも用意していると思います。ここはおいらの趣味でいわゆるprintfを使えるようにしていますけど、普通に「{0}」とかを渡しているところのほうが多いかもしれませんね。おいらは16進数で表示させたいとか桁そろえたいとかありましたので、好き勝手にいじれるほうを用意しました。規模が大きいプロダクトの場合は変えたほうがいいでしょう。

[]Glassfish V3 preludeのアップデートが出来ない

ここんところずっと503がかえってきます。おかげでGlassfishまわりのテストが出来ませぬ。なんかこういうの最近多いですね。JDKもu10はいまでも落とせませんし。Glassfishのサイトも今現在でもIE未対応。


サイトを用意はしても動いていないのならばそれはないも同然でしょう。つまりJDKの最新版は存在していませんし、Glassfishなんてものも存在していないのです。(ぉ


Glassfish V2のアップデートはつながりますね。ただ、このアップデートセンターのソフトがくせものでウインドウサイズがめちゃくちゃでかいです。小さくしてくれるとありがたいですね。あと項目もソートが出来ないのが非常に使いにくいです。NetBeansプラグインのようになってくれるといいですね。

お、Glassfish V2でJAX-RSのバージョンが上がってる。でも、NetBeans6.1のJAX-RSのサポートするバージョンはJersy0.8までなので不具合が出るでしょう(クラス名から変わってるのがいくつかある)。6.5ならば最初からはいってるのが1.0対応っぽいです。

[]はい11月ですよ

もう今年も残り2ヶ月をきりました。早いですねぇ。

今年の初めに今年こそ○○をするぞ!と誰もが豊富をかかえていたでしょうが、それは実現できてますか?あと2ヶ月で何とかなりそうですか?





おいらはぜんぜんです。

明日の食事代をどうするか考えるレベルの生活では正直何も生み出せませんなぁ。技術力を高めるとか勉強するとか、すぐに目の前の金が生み出せないようなものは切り捨てていくしかありませんね。たぶん、この業界はもう数年こういう流れなのでしょう。