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-05-31

[]Full Ajax その後

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

の続き。コンポーネントをpageへ追加していくというJavaらしいコードへ変更。

定義ファイル「s2container.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN" 
    "http://www.seasar.org/dtd/components24.dtd">
<components>

    <component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister" >
        
        <initMethod name="addClassPattern">
            <arg>"fullajax.page"</arg>
            <arg>"[^$]*"</arg>
        </initMethod>
    </component>
</components>

前回との違いはインナークラスを除外するように。以前のままだとエラーが出てしまうため。アノテーションをつけていないものは自動的に除外してくれるだけでいいんだけど。インナークラスでもコンポーネントを使いたい場合もあると思うし。

htmlソース。変更なし。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <title></title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        
        <script src='dwr/interface/FullAjax.js'></script>
        <script src='dwr/engine.js'></script>
        <script src='dwr/util.js'></script>
        <script src='prototype.js'></script>
    </head>
    
    <body onload="FullAjax.init();">
        <form id="form1" >
            <input id="text1" type="text" value="うわがきしてくれ">
            <input id="button1" type="button" value="送信">
            <div id="label1" >うわがきされたい</div>
        </form>
        <hr>
    </body>
</html>

Javaコード。アノテーションで関連付けしていたのと違ってコードでの関連付けは、やはりフレームワーク側のコードが非常にシンプルになってよいこと尽くめだった。Swingとか好きだしアノテーションによるSwingFrameworkのイベント方法は待ちがっとると思う人種だし。

package fullajax.page;

import fullajax.annotation.Init;
import fullajax.component.Button;
import fullajax.component.Label;
import fullajax.component.Page;
import fullajax.component.TextField;
import org.seasar.framework.container.annotation.tiger.Component;
import org.seasar.framework.container.annotation.tiger.InstanceType;

@Component(name="/index.html" ,instance=InstanceType.PROTOTYPE)
public class Index {

    public TextField textField = new TextField("text1");
    
    public Label label = new Label("label1");
    
    public Button button = new Button("button1");
    
    //画面開いたときの初期設定
    @Init
    public void init(Page page){
        textField.setText( "初期値" );
        page.add(textField);
        
        label.setText( "ここに表示されます" );
        page.add(label);
        
        button.addActionListener(new Runnable() {
            public void run() {
                label.setText( "はろー" + textField.getText());
            }
        });
        page.add(button);
    }
    
}

結果は前回と変わりませんのでそちらを参考に。

特徴としてはhtmlにイベントの設定やカスタムタグ類は一切なし。wicket:idのような特殊なタグもなく、DreamWeaverと相性もいいはず。これは「FullAjax.init()」でリバースAjaxで動的にイベントの追加等をしているということ。開発者はidをあわせることだけに専念することができる。


最近のフレームワーク比較によくAjax対応度というのが書かれているのだが、Ajaxのときだけ特殊なことをする時点でそれはないんじゃないかなぁ〜という思いで作ってみたのであった。つまりすべてAjaxのみで完結する。通常のWebアプリみたいなことをしないといけないのはファイルアップロードのみという逆転の発想で。

[][]NetBeans 6.1ML版にはGlassfish V2UR2 ML版が付属

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

これはすばらしい。6.0のときはなぜかML版でも英語版がついてきていたので別途インストールする必要がありました。

Glassfishはwarファイルしか扱わない場合においてもTomcatから乗り換える価値のあるサーバーです。Tomcatは最近はあまり言われなくなりましたが、所詮サーブレットコンテナ。Glassfishは管理をするのにブラウザからGUIで簡単に扱えます。管理用のwebアクセスは通常のアプリケーションとポートが異なる設定に最初からなっているのは便利ですしね。

[]クイズマンの番宣がうざい&玉ニュータウン始動

ザクイズマンショーの放送時刻に近い時間帯に、大幅に劣化したクイズマンの番宣をするとはかなり腹立たしい。


一方、何の前触れもなくいきなり万田TVというクソみたいな別番組に変わりすぎた関口さんの後継番組がやっと来週水曜日24:00に登場。

番組名は番組表をみるかぎり予想通り「玉ニュータウン」。この日はプロ野球があって延長するかもしれないので録画する人は長めにしておいたほうがいいかと思われ。

関口さんのくらげキャラクターは万田TVに奪われて使えないため、はたしてどうなるか心配だがはげたまご等はちょっときっついかも。

http://www.touchplanning.com/index06.html

まぁ、まずは見た目より中身だよね。とはいえ、このキャラクターでは戸田大宮でやったような規模のイベントは無理だろうなぁ。

うわさされていたsakusakuとのコラボとかもこれでは無理だろう。くらげはくらげで誰がどのキャラかすぐにわかりにくいというのが問題だったけど。声も似たような感じだったしね。メジャーどころの声優なのにまったく作ってない声質のままだらだら話すのがよかったがそこは引き継ぐのだろうか。


クイズマンショーもまったく別番組名で復活してくれねーかな。

2008-05-30

[]sunってすげーな

Hudsonがついに昼間の仕事になりました

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

へー、オープンソースに理解がある会社ってすごいな。

[]幻霧ノ塔ト剣ノ掟 8日目

http://www.success-corp.co.jp/software/ds/genmunotou/download_sheet.html

うぉキャラクターシートが追加されてる。マニアックすぎ。TRPG好きがいるんだね。

やっと15時間で3F到着。音楽が一気に変わったものの、アレンジだと周りが見にくいなぁ。B1F、3Fの音楽はオリジナルモードのほうがいいみたい。

1フロアの充実度というか満足度というか密度が半端内。たぶん3DダンジョンRPGで最高の密度だと思う。歩いてないところがあればそこは隠し扉や何かが必ずあるだろうという感じ。

マップサイズ自体は22*22、上下左右がつながっているというタイプ。壁は1マスとして数えないタイプなのでこの密度があるのだろう。また、階の上り下りがあってはじめて先に薦めるというところが多いのも原因か。WIZにはあまりないタイプの密度。壁や扉を1増すとして数えるタイプのウルティマ世界樹は1フロアの密度はかなり薄いんだよなぁ。世界樹の場合手でマッピングをするという目的があるからああいう仕組みになるのはわかるんだけどね。


15時間だとはじめてWIZやっても4階くらいうろついてるはずなんだけど、まぁB1Fも多少はうろついたから同じようなもんか。でもこのあとWIZは10Fまですっ飛ばして進むので密度は倍以上はあると思っていいかな。まじで世界樹IIの3、4倍くらいはクリアまでに時間がかかりそう。

[]サマータイム反対の人に票を入れます

サマータイム10年導入めざす 推進議連、今国会に法案

http://www.asahi.com/life/update/0522/TKY200805220296.html

ってのは真っ当な考え方だよね?

同じ時刻で日の長さや季節感を感じるのが日本人だと思うし、あらゆるシステムが高々2年程度で対応できるとは思わない。

そのメンテのコストは国が出してくれるの?

お店にしても看板やパンフレットとか開店、閉店の時間の記述等はどうするの?いまはどこも値上げで厳しい状態なのに。

とりあえず「サマータイム制度推進議連」の人とか推進派の給料を80%くらいもらって補填するといいんじゃないかな。

[]XBOX LIVE アーケードの配信終了の意味がわからない

オンラインのソフトを外すイミがわからない(ぉ。

評判いい悪いに関係なく、ニッチ商品対象にできるのがオンラインなのに。

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

俺もそう思う。メジャータイトルはパッケージで入手できたり、リメイクや復刻したりするけど、マイナータイトルはそんなの無理だから。配信開始から6ヶ月ってそんなに初動型にしたいのかなぁ。ほんとわけわからん。物理的に場所をとるわけでもなかろうに。

WiiVCもマイナーなタイトルやあきらかにクソとか言われてる作品も含めてラインナップにあるのはゲームの歴史をちゃんと残すという意味があるためだと思う。

[]Wii 6月のバーチャルコンソールのラインナップも神すぎる件。美人薄命キター

6/3配信予定

  • FC - バイオミラクル ぼくってウパ(500P)
  • MS - 阿修羅(500P)
  • PCE - パワーテニス(600P)
  • NG - キングオブモンスターズ(900P)

6月配信予定ソフト

1ポイント1円です。

コンボイの謎は3日でクリアしたソフトなので、当時難易度はそれなりだと思っていたのにネットで調べたら超絶難易度というふれこみになっていたかわいそうなソフト。一番難しいのは1面とあと一箇所だけでしたよ。確か。

ウインズオブサンダーもでてサンダーシリーズが2作遊べるようになりました。

ファンタシースターはこれで2から4までWiiで遊べるようになりました。セガマスターシステムも参入しているので1もおそらく出るでしょう。マスターシステムといえば阿修羅がでるようです。これ名作ですよ!

ニンジャコマンドー龍虎の拳2もきたことによってNEOGEOが一気に神ラインナップに。すでに配信済みの初代やKOF94、飢狼1/2とNEOGEOスティックWiiを購入しても完全に元が取れるでしょう。

ヨッシーのクッキーGC版のパズルコレクションもってるのでいらないかな。ドッジボールはX68版やGBA版もってるのでこれもいらないかな。

ガンヘッドは海外版をよくぞもってきてくれたというところ。ガンヘッドというタイトルはメディアミックス戦略の中で発売されたタイトルなので簡単に使えなかったのでしょう。よくやった、ハドソン最高!


とりあえずバイオミラクル ぼくってウパが即確定。音楽がいまだに頭の中に残るディスクシステムの名作中の名作です。ツインビー2とかディスクシステムの作品が今後もたくさん出てくれるといいですね。


Wii持ってない人もすでにVCのためだけに購入してもいいですね。STGの充実度どころの騒ぎじゃない。

一覧を載せてみます。

[][]リソースファイルからインジェクトする

Google Guiceならばすぐできるかなと思いちょっとやってみた。

環境設定はModule単位で分割できるのでこれでいいかな。

モジュール定義

public class ResourceModule implements Module{

    private ResourceBundle bundle;

    public ResourceModule(String name) {
        bundle = ResourceBundle.getBundle(name);
    }
    public ResourceModule(String name,Locale locale) {
        bundle = ResourceBundle.getBundle(name,locale);
    }
    
    public void configure(Binder binder) {
        for(Enumeration<String> keys = bundle.getKeys();keys.hasMoreElements();){
            String key = keys.nextElement();
            binder.bind(String.class).annotatedWith(Names.named(key)).toInstance(bundle.getString(key));
        }
    }

}

実行&DIされるクラス

public class Main {

    @Inject
    @Named("message")
    private String message;
            
    public void print(String name){
        System.out.println(message + name );
    }
    
    public static void main(String[] args) {

        Module module = new ResourceModule("hoge");
//        Module module = new ResourceModule("hoge",Locale.ENGLISH);
        Injector injector = Guice.createInjector(module);
        
        Main main = injector.getInstance(Main.class);
        
        main.print("名無しさん");
    }

}

プロバイダを使って動的に毎回取得するほうと最初にまとめて登録するのとどっちがいいか考えた結果、起動時にすべて登録するようにした。環境によってはプロバイダを使ったほうがいいかもしれない。

ちなみにNetBeansリソースファイルはよくできていて、プロパティファイルが特定の書式で複数生成されるということをまったく知る必要がない。というか、知る術がない。せめてファイルビューの場合はそのまま表示してほしかったかな。もちろん、native2asciiの存在も知らなくてよい。すばらしい。



右クリックでロケールもすぐ追加可能だ。


入力する場合、ロケールごとにすぐ確認できる。

もちろん、1つのロケールだけを普通にエディタモードで開くこともできる。

2008-05-29

[]OpenJPAでのmerge

Toplinkと同様にidがふられていなければ自動的にpersistしてくれるみたい。

また、idをパラメータにしてコンストラクタで生成、その後特定のフィールドのみ変更をしてmergeを呼び出すとちゃんとその変更されたパラメータのみupdateされるようだ。いったんfindをするということはなくてもいいらしい。

で、ここで問題発生。JUnitからアクセスするとToplinkと同様のエラーが出る。warからRemoteメソッドで呼ぶ場合は問題ないのになんでだろ。エラー箇所はいつものNewIOのところ。Toplinkの場合、warでもJUnitでもエラーが出る。Glassfishの日本語問題は根が深いぜ・・・。

[]妄想だけで終わらせるのはもったいない

妄想2のつ・づ・き♪

http://d.hatena.ne.jp/shot6/20080529#1212046240


JSFのようなイベントモデルをとらないで、こういうActionベースでの考え方の場合、あまり機能を増やさないほうが

結果的に融通が利いてやりやすい。必要ならばその上にかぶせればいいだけだし。

最近だとオレもそんな感じです。

かつActionベースでリクエストの何らかのインスタンス引数でわたってくるモデルがお気に入りですね。

この考え方であればそれでいいですね。インターフェースはラップした側でいれてしまえば、必須として縛ることが十分可能です。ですが、ベースとして最初からインターフェースを入れてしまうと必須をはずすことができないわけですし。

リクエストスコープに入れてしまえば、というのはいろいろと試行錯誤しての結果でした。たしかに便利にはなっていません。不便にもなっていませんけど。メソッドだけを見ればわかるというほうが便利でしょうね。ただし、DWRscriptスコープのような場合はこういうタイプがいいのでしょうけど、これもまたラップすればすむ話。

イベントの振り分けもnameとvalueは必須ではない属性にしてしまえばいいだけですから、これもこのままでいいとおもいます。デフォルトはメソッド名で。


面白いのでSpringMVCのパラメータやモデルの渡し方もここにのせてみたいと思います。SpringMVCの基本はシングルトンですからすべてメソッドで完結しています。

たとえば古の時代からあるSpringMVCの戻り値だとこんな感じです。

	@RequestMapping(method = RequestMethod.POST)
	public ModelAndView add(
			@RequestParam(value="arg1") String arg1String , 
			@RequestParam(value="arg2") String arg2String ) {
			
		//Validationはここらでお好きにどうぞ。
		Integer arg1 = Integer.valueOf(arg1String );
		Integer arg2 = Integer.valueOf(arg2String );

		
		Map<String,Object> requestMap = new HashMap<String,Object>();
		requestMap.setAttribute("arg1", arg1);
		requestMap.setAttribute("arg2", arg2);		
		requestMap.setAttribute("result", arg1 + arg2);//オートボクシングでよい
		
		return new ModelAndView("jsp/add.jsp",requestMap);
	}

フォワードリダイレクト先とrequestへのパラメータの指定ができます。

で、最近だと引数にもかけます。

	@RequestMapping(method = RequestMethod.POST)
	public String add(
			@RequestParam(value="arg1") String arg1String , 
			@RequestParam(value="arg2") String arg2String ,ModelMap requestMap) {
			
		//Validationはここらでお好きにどうぞ。
		Integer arg1 = Integer.valueOf(arg1String );
		Integer arg2 = Integer.valueOf(arg2String );

		
		requestMap.setAttribute("arg1", arg1);
		requestMap.setAttribute("arg2", arg2);		
		requestMap.setAttribute("result", arg1 + arg2);//オートボクシングでよい
		
		return "jsp/add.jsp";
	}

戻り値は何もしないとフォワードで、「redirect:」をつけるとリダイレクト指定になります。


妄想だけで、オレオレフレームワークだけで終わらせるのはもったいないですね。シンプルな各自カスタマイズを前提としたベースとなるべき薄いフレームワークは絶対に公開すべきですよ。


フレームワークとしてとしてjarファイルをクラスパスに登録して終わりということではなく、その上に便利になりそうなプラグインとしてどんどん乗せていく、もしくは自前でコードを書いていくというアーキでいいと思います。

シンプルですからバグは少ないでしょうし、パフォーマンスも問題にはなりにくいでしょうし。


このフレームワークが近日中に公開されるのでしたら、お手伝いしましょう。ドキュメントとサンプルコードはインストール直後のNetBeansからさくっと使えるように用意したりするだけではなく、次の開発案件で(ベータや非公開のアルファバージョンであっても)すぐに実装してバグあらいだしますよ。納品日はまー先になりますし、シンプルだからこそ自前でいくらでも調整はできるでしょうし気にしていません。

前提としてコンテナ非依存がありますけど。つまり、Seasar2でもGuiceでもSpringでもEJB3でもDIコンテナなしでも動かせる物がいい。


と、発破をかけてみる。^^;

[]DS リズム天国 ゴールド発売決定

7月31日3800円だそうで。

タッチペンを使うと思われるので応援団のような感じになるのでしょうか?

公式サイトでもまだ情報がほとんど出ていないのでなんとも。

[]オレオレフレームワーク

昨日のエントリのコメントにも書いたが、SpringMVCはいまいち使いにくいところもあってオレオレフレームワークでちょうど1年前に作っていた。それは妄想その2に非常に近い。

そこでshot6さんのコードをもとに書いてみよう。

public class AddPage implements Controller{

	@Inject
	HTTPServletRequest request;
	
	public View show() {
		return new View(View.REDIRECT ,"jsp/add.jsp");
	}

	/**
	 * addボタンがPOSTで押されたときだけ呼ばれる
	 */
	@WebEvent(name="add" , value="同一ページ")
	public View add() {
		//Validationはここらでお好きにどうぞ。
		Integer arg1 = Integer.valueOf(request.getParameter("arg1"));
		Integer arg2 = Integer.valueOf(request.getParameter("arg2"));
		
		request.setAttribute("arg1", arg1);
		request.setAttribute("arg2", arg2);
		request.setAttribute("result", arg1 + arg2);
		
		return new View(View.FORWARD ,"jsp/add.jsp");

	}

	/**
	 * addAndMoveボタンがPOSTで押されたときだけ呼ばれる
	 */
	@WebEvent(name="addAndMove" , value="結果ページ")
	public View addAndMove() {
		//Validationはここらでお好きにどうぞ。
		Request request = context.getRequest();
		Integer arg1 = Integer.valueOf(request.getParameter("arg1"));
		Integer arg2 = Integer.valueOf(request.getParameter("arg2"));
		request.setAttribute("result", arg1 + arg2);
				
		return new View(View.FORWARD ,"jsp/addResult.jsp");

	}

}

InjectがあることからわかるようにGoogle Guiceを使っていた。まー見事に似ているね。ViewにはバイナリデータのダウンロードとかpdfとかExcelとかタイプがいろいろとある。byte[]をわたしてダウンロードとかよくやるね。

Controllerは最初はなくて、同じように@Defaultというアノテーションで最初はやっていた。実際のところデフォルトなGETを受け取るのを作ることを忘れるなどミスをすることもあるため、コンパイル前に縛るためにインターフェースをつけるようにした。また、URLもクラスにつけていたが、一箇所でどのクラスがどのURLになるのかをすぐ確認や管理できるほうがやはり便利だと思い知ったので、GuiceのModuleで定義した。

なんでもアノテーションにすればいいというわけではないというのをこのとき思い知る。インターフェースで必ず実装してもらうというのは非常にJavaらしく、やはり基本を大事にしようね、と。

requestの判断は最初はshot6さんと同じようにnameだけにしていたが、2度押し防止のために手軽に実装できるdisableをいれるscriptを実装すると判断できないこと、1つのhiddenなパラメータを利用して画面遷移をコントロールするのが一番柔軟性があること、ラジオボタン等の状態によって飛ぶ先をかえることが可能なこと、など柔軟性のためにnameとvalueを用意した。おかげでhtmlとコードを見てすぐわかるというメリットがあった。アノテーションを使う場合メソッド名で判断させないほうがコードを見ていてわかりやすいと思った。IDEで色づけしてくれるわけだし。


実際はRequestにパラメータをセットすることもなくて、このインスタンス自体がrequestにマップされるようにしていた。

public class AddPage implements Controller{

	@Inject
	HTTPServletRequest request;
	
	public View show() {
		return new View(View.REDIRECT ,"jsp/add.jsp");
	}

	/**
	 * addボタンがPOSTで押されたときだけ呼ばれる
	 */
	@WebEvent(name="add" , value="同一ページ")
	public View add() {
		//Validationはここらでお好きにどうぞ。
		
		arg1 = Integer.valueOf(request.getParameter("arg1"));
		arg2 = Integer.valueOf(request.getParameter("arg2"));
		result = arg1 + arg2;
		
		return new View(View.FORWARD ,"jsp/add.jsp");

	}

	/**
	 * addAndMoveボタンがPOSTで押されたときだけ呼ばれる
	 */
	@WebEvent(name="addAndMove" , value="結果ページ")
	public View addAndMove() {
		//Validationはここらでお好きにどうぞ。
		
		arg1 = Integer.valueOf(request.getParameter("arg1"));
		arg2 = Integer.valueOf(request.getParameter("arg2"));
		result = arg1 + arg2;
				
		return new View(View.FORWARD ,"jsp/addResult.jsp");

	}

	//--------------------------------------------------------------------------
	//ここから下がrequestにマッピングされてEL等で取得可能になる
	
	private Integer arg1;
	public Integer getArg1(){
		return arg1;
	}

	private Integer arg2;
	public Integer getArg2(){
		return arg2;
	}

	private Integer result;
	public Integer getResult(){
		return result;
	}
}

おおむねこんな感じ。

小規模開発だとこれとJSTLだけでかなり安定した開発ができていたと思う。当時はGuiceの資料ゼロだったけど、コードによる定義ファイルというのはミスが少なく非常に楽だった。カスタムタグでhtmlを生成すると実行しないと結果がわからないことやDreamWeaverでデザインしやすいようにするため制御以外のタグは一切なしで。あくまでもループやテキスト等を表示するところにタグやELを書くだけに専念する。


いろんな現場でオレオレフレームワークはあるとは思うが、ほとんどはこんな感じだと思う。そしてStrutsの上にかぶせているものはそのほとんどがかなり使いにくいものだったと思う。位置から作ったやつのほうがカバー範囲は狭いものの、このフレームワークでどんな問題を解消しようと考えていたのかがよくわかって、結局使いやすいものが多いと思う。

JSFのようなイベントモデルをとらないで、こういうActionベースでの考え方の場合、あまり機能を増やさないほうが結果的に融通が利いてやりやすい。必要ならばその上にかぶせればいいだけだし。

[]お金は要らないけどさっさと日本語が通るようになってくれ>GlassFish

バグでお金をもらおう - GlassFish GAP プログラム

http://blogs.sun.com/theaquarium_ja/entry/for_bugs_glassfish_gap_program


Glassfishは最高にお気に入りのJavaEEサーバーです。V3での大幅な高速化もすばらしく未来も明るいように見えます。


でもたった一つ問題があります。JPAで日本語が通らないのです。

JavaEEサーバーですからJPA実装は組み込まれているのですが、これが過去に何度も書いてるとおり動かない。


実装をOpenJPAやHibernate EntityManagerへ変更するとちゃんとエラーが出ずに動きます。同梱されている実装を使うと動かないというのもおかしな話ですね。一番テストがされているように見えるのに。EclipseLinkでもToplink Essentialsと同様のエラーが出て動きません。

2008-05-28

[]バーチャルコンソールMSXがやっときた模様

アレスタ登場。800円なり。

http://www.watch.impress.co.jp/game/docs/20080528/aleste.htm

いきなりMSX2FM音源+ディスクという特殊な環境からスタートしてるというのがすごいかも。

つまり、今後も期待できる・・・?

PSGFM音源の切り替えができるというあたり、R-TYPEもMSX1とMSX2でモードを切り替えることができるようになりそうですね!


アレスタ1は持ってるのでおとさないかな。

とりあえずMSXコナミが参入するかどうかがポイントになりそう。つまり神ゲーである「王家の谷」がでるかどうか。英語ミスってるとかいわないから。


WiiSTGの充実具合は圧倒的すぐる。

[]ぱっとみSpringMVCかと思った

http://d.hatena.ne.jp/shot6/20080527#1211873858

たとえばSpringMVCで似たようなコードを書くと以下のようになる。

@Controller
@RequestMapping("hello")
public class HelloPage {

	/**
	 * called from http://yourdomain/samples/hello/* or http://yourdomain/samples/hello
	 */
	@RequestMapping
	public String index() {
		return "/jsp/hello.jsp";
	}

	/**
	 * called from http://yourdomain/samples/hello/request
	 */
	@RequestMapping("/*/request")
	public String requestType(HttpServletRequest request) {

		return "/jsp/hello.jsp";
	}

	/**
	 * called from http://yourdomain/samples/hello/struts
	 */
	@RequestMapping("/*/struts")
	public String likeStrutsType(HttpServletRequest request,
			HttpServletResponse response) {

		return "/jsp/hello.jsp";
	}

}

似てるね。もちろん、@RequestMappingのところは無理やり合わせたような感じなので、ちゃんとやるなら一枚かませてラップしたほうがいいんだけど。

SpringMVCはアクションとビュー遷移のメソッドを分けることもできる。感覚的にはJSFのイベントリスナーとアクションイベントとの違いのような感じで。個人的にはあんまりわかりやすいとも思えないけど。

[]まだ序盤だが断言してみる


世界樹の迷宮IIより幻霧ノ塔ト剣ノ掟のほうがはるかに面白い。


ファミ通着弾によると初週1500本しかうれてないようなのでおそらく続編は絶望的か。もったいない。

口コミでも売れていくといいんだけどなぁ。入手性も悪いし、再出荷があるとも思えないので硬派なRPGが好きな人は確保しておくといいと思う。

[]DS ファイアーエムブレム新・暗黒竜と光の剣 発売日決定か

8月7日で4800円(税込)らしい。

暗黒竜と光の剣FEシリーズ初代でありながらかなりできのよい作品。

SFCで紋章のなぞ1部としてリメイクされたが、ナイト系すべてが建物の中だと降りてしまうことや、登場人物やマップがかなり削除されたため、別物と思っていい。ハーディンの部下のホースメンなんか最初からクラスチェンジ済みの激弱キャラになってしまったのはかなしむべきところ。おかげでカシムがすごいわけだけど。削除されたマップは非常に名所だったりするため悲しんだ人は多いと思う。

まぁ初代は初代でアーマーナイトはクラスチェンジできないし、ハンターもできないつらさはあるんだけど。個人的にはバーツが序盤あほみたいに強かったのでクラスチェンジができるようになっていたら、成長率は大幅に下がってるだろうなぁと思う。

昔のドラゴンナイトは弓以外で落とすのはほんときついキャラだったのでその重圧感が再現できてるといいかな。1ポイントの重みがある昔のシミュレーションとして楽しかったFEにもどってくれー。


[追記]

決定

http://www.nintendo.co.jp/fe/fet_info.html

リフも決定。まさしく暗黒竜。初代は海外ででていないのでスマブラにでてくるこのかっこいい人はだれ?ということになっていたのだ。

[]ドコモ906iシリーズ発表

SHがいいですね。回転2軸の振るワイドVGA

ひそかにこの1年ほどSHがカメラがまともな端末を出してなかったので注目していたり。CMOS 500万画素はシャープは初めてでしょう。

というか、もう完全にCCD死滅しましたね。屋内や光量が少なくてもまともに写真が取れるというメリットはむしろ携帯向きなんですけどね。

CCD 200万画素でいいのでしっかりしたのつくってほしいわ。あと頻繁に使う光学ズームも必須でしょう。ソフトウェアの手振れ補正はむしろ汚くなるばかりなので要らない。顔認識やマルチスポットとかもいらない。

2008-05-27

[]幻霧ノ塔ト剣ノ掟 6日目 初期店売り武器+クリスナイフ

武器の項目を追加。また、ミスしてるところも修正。

店売り武器はすべて網羅した。

戦士・盗賊ダメージAC最大攻撃回数素早命中乱闘息も乱れ撃ち突撃なぎ払い備考
ロングソード1〜6-11     
エストック1〜503     攻撃回数UP
カットラス1〜8-11     
ショートボウ1〜401     両手・長射程
クロスボウ1〜802     両手・長射程
ロングボウ1〜803     両手・長射程
戦士・盗賊・魔術師ダメージAC最大攻撃回数素早命中乱闘息も乱れうち突撃なぎ払い備考
ダガー1〜4-11       
クリスナイフ3〜6-12      アンデッドに2倍ダメージ
戦士・司祭魔術師ダメージAC最大攻撃回数素早命中乱闘息も乱れうち突撃なぎ払い備考
クォータースタッフ1〜4-11        両手・長射程
戦士・司祭ダメージAC最大攻撃回数素早命中乱闘息も乱れうち突撃なぎ払い備考
フレイル1〜601        
戦士ダメージAC最大攻撃回数素早命中乱闘息も乱れうち突撃なぎ払い備考
片手斧2〜701      
バトルアクス3〜12-11      
スピア1〜601    長射程
カタナソード1〜10-11     
ウォーハンマー2〜8-11       両手・ノックダウン
クレイモア1〜8-12    両手・ノックダウン

店売り武器での初期状態での単純なダメージの重さなら

という順番か。エストックが盗賊も装備できてかなり強いがACが下がらないという欠点もある。カタナソードは高いだけあって、攻撃力もそこそこ、スキルに優れるのだが、ダメージのばらつきが多いのが残念なところ。

近接両手武器は盾が装備できないことによってかなりの負担。ただし、ウォーハンマークレイモアともに一定の確率で相手を吹っ飛ばして行動不能にする効果があるようだ。うまく使えば強いのかも。

ウォーハンマーTRPGだと変な数値になってしまったが、最低ダメージが1もしくは、最高ダメージが9が出るのかもしれない。(追記:2d4でいいですね)

武器には最大攻撃回数が設定されているため、クレイモアが戦士のLVがふえて攻撃回数が上がると価値が出る。また、司祭以外は2回攻撃が用意に出る装備があるため、戦士技能の価値があるみたい。おかげでウォーハンマーの価値がわからない。

攻撃回数はまだ確認できたところだけ。ロングソードでも戦士技能が増えることによって攻撃回数が増えるかどうかは不明。

全体的に「突撃」「乱闘」「なぎ払い」を持ってる武器は値段が高いとか攻撃力が低めだとか効果が強いスキルだと開発側に思われているらしい。たとえば「突撃」は後ろから攻撃可能で攻撃力アップという効果らしいからACUPのデメリットがほとんどないというのが強みか。盗賊に戦士技能を持たせてカットラスとかでも強いのかもしれないというわけだ。

B1に降りていきなり入手(階段を下りるとすぐ隠し扉がある)が可能なクリスナイフだが、司祭以外装備可能で攻撃回数が最大2と多いこと、ダメージの安定度が高いことで序盤は頼れる武器になりそう。近接キャラならばやはりエストックが安定だが、ACがあまり低くない盗賊にはAC1の差はかなりあるかもしれない。

たとえばTRPGのよくある計算方法だとAC1につき5%の回避率となる。100%に対して95%ならばさほど差はないのだが、実際の敵の命中率は30%〜50%程度ということで、5%は馬鹿にならない。もし幻霧ノ塔でも同じ計算方式だったらすごいことになる。


まぁ、序盤はひたすら命中UPの攻撃中心で。

[]injectDependencyはかなり限定された動作?

Seasar2のinjectDependencyが思ったように動いてくれない。

GuiceのInjectMembersのように、単純にすでにインスタンス生成済みのオブジェクトに対して注入してくれるわけではないらしい。


xmlouter定義すると動くのはわかるけど、xmlで書くなんて効率の悪いことはしたくない。とはいえアノテーションでの定義の仕方もわからない。

うーん、それともできないのかな。

[追記]

試行錯誤でわかった。

<component name="bind" instance="outer"/>

としておいて


SingletonS2ContainerFactory.getContainer().injectDependency(hello ,"bind");

とでもしておくといいようだ。classは必須じゃないんですね。

[]Spring2.5でJNDIルックアップができない

2.5からはアノテーションでできるらしいのだがまったく動かない。

InitialContext.doLookupとかxmlで定義した場合は問題ないというあたり、JNDI自体は動いているはずなのだが。

org.springframework.context.annotation.CommonAnnotationBeanPostProcessor

がまったくきいてない予感。とりあえず放置しよう。

2008-05-26

[]doLookup使っていますか?

今のjavaはJNDIのルックアップに便利なInitialContextにstaticなメソッドが用意されている。genericsも使われていてキャストも必要がない。

sunのjdkソースコードを見ると

    public static <T> T doLookup(String name)
        throws NamingException {
        return (T) (new InitialContext()).lookup(name);
    }

なるほど。キャッシングしてないというわけか。それがどれだけパフォーマンスに影響が出るか調べてみた。

サーブレット内で以下のように追加した。


    String jndiName = "jdbc/jpa_sample";
    {
        long start = System.nanoTime();
        InitialContext ic = new InitialContext();
        for(int i=0;i<1000;i++){
            DataSource ds = (DataSource) ic.lookup(jndiName);
        }
        long end = System.nanoTime();
        System.out.println("lookupTime:"+(end-start)/1000/1000);
    }
    {
        long start = System.nanoTime();
        for(int i=0;i<1000;i++){
            DataSource ds = InitialContext.doLookup(jndiName);
        }
        long end = System.nanoTime();
        System.out.println("doLookupTime:"+(end-start)/1000/1000);
    }           
    {
        long start = System.nanoTime();
        InitialContext ic = new InitialContext();
        for(int i=0;i<1000;i++){
            DataSource ds = (DataSource) ic.lookup(jndiName);
        }
        long end = System.nanoTime();
        System.out.println("lookupTime:"+(end-start)/1000/1000);
    }
    {
        long start = System.nanoTime();
        for(int i=0;i<1000;i++){
            DataSource ds = InitialContext.doLookup(jndiName);
        }
        long end = System.nanoTime();
        System.out.println("doLookupTime:"+(end-start)/1000/1000);
    }   


結果

lookupTime:225

doLookupTime:167

lookupTime:154

doLookupTime:162

5%くらい遅いということかな。問題なさそう。

seasar2とかからjndiの呼び出しをしたい場合はありかな。

それとも、seasar2はJNDIをフィールドインジェクションとかできるのかな?

できるのならそれだけでいいけど。

[]幻霧ノ塔ト剣ノ掟 5日目 武器参考

※さらに追加して修正したのを書きました


昨日のサブコマンドは攻撃のところがあっていません。命中UPとかない武器も多数。つまり、完全武器依存です。そのかわり職業によって選択肢に差が出るようです。MP切れたからといって魔法系キャラに強力な弓を装備させたところでサブコマンドは一切現れません。戦士技能か盗賊技能が必要なのでしょう。盗賊は命中UPとすばやさUPのやつしかでてこないっぽいです。

とりあえず武器まとめて見ました。ダメージは実際に現れた数値です。

戦士・盗賊ダメージAC素早命中乱闘息も乱れうち備考
ロングソード1〜6-1   
エストック1〜50   攻撃回数大UP
ショートボウ1〜40   両手・長射程
ロングボウ1〜80   両手・長射程
戦士・盗賊・魔術師ダメージAC素早命中乱闘息も乱れうち備考
ダガー1〜4-1     
クリスナイフ3〜6-1    攻撃回数小UP・呪文抵抗UP
戦士・司祭魔術師ダメージAC素早命中乱闘息も乱れうち備考
クォータースタッフ1〜4-1      両手・長射程
戦士・司祭ダメージAC素早命中乱闘息も乱れうち備考
フレイル1〜60      
戦士ダメージAC素早命中乱闘息も乱れうち備考
片手斧2〜70    
バトルアクス3〜12-1    
  • 「素早」は素早さがUPするかわりに命中率低下
  • 「命中」は命中率がUPするかわりに素早さが低下
  • 「力」は素早さが低下代わりにダメージが大きくなる
  • 「乱闘」は範囲攻撃だがACが上昇する(つまり打たれ弱くなる)
  • 「息も」は大ダメージだが、次のターン防御しか使えなくなる
  • 「乱れうち」は範囲攻撃だが、射程が短くなる

見てわかるのは戦士のたしなみの非常に20Sと低価格なロングソードのスキルの多さ。価格の安さのわりに安定した強さを持っています。また、エストックやクリスナイフが非常に強いです。攻撃回数が多いということはミスも少ないですから。片手斧やバトルアクスも価格の割りにダメージはわりと強いですが、命中UPのサブコマンドがないのが気になるところ。

ほかにも万能な武器というものは存在せず、サブコマンドがそれらしい体系に分かれていますね。おかげでプレイヤーによってかなり戦いの幅が大きいと思います。

力によるダメージの差は今のところ見られません。命中率のみに影響するのかもしれません。

職業表記は最重要です。これを外れた装備はできますが、スキルが使えなくなってしまいます。

[]芝君には優しくしようと思った

ひがさんところ経由

中卒の私が学歴について語ってみる

これ見て芝君にも優しくしないといけないなとおもた。

ネイティブではない言語圏での生活はお母さんは大変だったろうね。

        _, ._
      ( ・ω・)
      ○={=}〇,
       |:::::::::\, ', ´
w、、、、、、、、 し 、、、(((.@)wwwwwwwwwwwwwwwwwwwwwww


で、ひがさんのほうだけれども

彼女には、「東大コンプレックス」があったんじゃないだろうか。「東大出身だという話をすると自慢しているように思われていやだ」みたいな。

頭がよければよいで苦労することも出るということか。

よく「料理ができる人とできない人とどっちがいい?」とかいうのがあるが、できることによるデメリットがないのならその質問は成り立たないとかさめた感覚だったのだが、これを見てそうでもないのかもと思うようになった。勉学についてもできないよりできるほうがいいと決め付けていたが、そうでもないのかも。


まぁおいらは頭がよくないし、学歴もないのでコンプレックスの固まりなわけですが。

地方だと大学がほとんどなくて本当に金持ちと頭のよい人、勉強したい人しかいけないところだった。おいらはいかにして家を早く出て実家の負担を減らすかということばかり考えていた。下には妹と弟がいたし。

そして東京に仕事に出てきて初めてその差に驚いた。大学はピンきりであり、大量に大学があるために高卒と同様に大卒がかなり一般的であると。そして大学の電車内広告の恐るべき数にも圧倒される。

もっとも、仕事してからのほうが勉強の量が圧倒的に増えてる(働いてる人みんなそうだと思うけど、1週間で30時間は勉強時間に割り当てるよね)ので、社会に出てから初めて学校のありがたさ等がわかったのだけれども。数年働かなくても生きていけるだけのお金があったら正直いろんな勉強をしてみたい。情報処理にかかわらず調理学校とかそういうのもふくめて。

2008-05-25

[]地上波 コンスタンティン

禁煙しましょうって内容かな。

最後サタンが肺の中からタールとか取ってきれいにしたんだろうということはわかった。また、神にとられるくらいなら生き返らせるほうがましとかなかなか日本人受けしそうなストーリーだなぁ。

[]幻霧ノ塔ト剣ノ掟 4日目

とりあえず幻霧ノ塔ト剣ノ掟はてなキーワードを作ってみた。これではてな内で自動的に相互にリンクもされることでしょう。


今回はサブコマンドについて。攻撃と防御、魔法は普通に選択する以外に右を押すことによってサブコマンドを選択できる。


防御サブコマンド

盗賊固有の防御サブコマンドとして「隠れる」がある。WIZと同じだとすると隠れている間は攻撃対象にならない&後衛からも近接攻撃が可能だろう。もっとも後衛においた場合盗賊は弓が使えるので意味はないと思うけど。

盗賊と戦士の防御サブコマンドはカウンター。攻撃を受けたやつに反撃するらしいのだが1ダメージ以上与えたためしがない。受けたダメージによって変わるとかあるのかな?


攻撃サブコマンド

戦士と盗賊の攻撃サブコマンドとして命中率を上げる代わりに攻撃速度を遅くするということと、攻撃速度を速める代わりに命中率が落ちるというのを選べる。

戦士はさらに武器によって一撃が非常に重い代わりに次のターンに防御しかできないとか、敵1グループに攻撃とか、ACが上昇する代わりに攻撃力アップとかいろいろとサブコマンドが現れる。

呪文サブコマンド

魔術師司祭には呪文にサブコマンドが現れる。行動速度を速める代わりに失敗する確立があがるとか、行動速度を下げる代わりに成功率を上げるとかあるのが面白い。実際にところ呪文は失敗はあんまりしてないと思うので通常の詠唱が多いのだけれども。


とにかく序盤は一番弱い雑魚相手にもミス多発してるので、命中率アップのサブコマンドを優先したほうがいい感じ。

2008-05-24

[]幻霧ノ塔ト剣ノ掟 をプレイ中

いまのところB1とF2まではいけてる。クエストはひとつしかこなしてないけど。

敵が強いのでF1以外は魔法を全快で。


今のところ気がついたことをまとめてみる。

  • 先制攻撃時は魔法などが使えず攻撃のみ。WIZやったことある人ならニヤリ。
  • 攻撃力がわからないので使ってみてはじめて強いのか弱いのか気がつく。参考となる数値がほしいかも。
  • 戦士はHPが増えやすい以外にメリットはあるのか?どの職業でも装備そのものは制限されないのでそれだとメリットが薄い。
  • AC1あたりの重さがかなりあるような気がする。いわゆるバマツ(味方全員のACを4下げる)もあるのだがかなり食らわない。
  • 隊列は前衛1,2,3の3種類。全員前衛とか全員後衛はできない。敵側にも隊列があり、3グループ目から後衛などになる。
  • 武器にはショートレンジとミドルレンジとロングレンジがあるっぽい?(要確認)
  • 死んだやつにも経験値が入るくさい。
  • 最初に選んだ職業以外の技能をとると必要経験値が増えていく模様。
  • 一番安い宿はMPのみ回復。HPも回復する宿も安いのでそちらを使ったほうがいい。
  • 盗賊の補助技能(罠解除、鍵開け)が役に立っているかどうかは不明
  • カティノがものすごく強い。生物系ならば9割以上の確立で寝ている。アンデッドや植物系は効かない。

まだ4時間ちょいしかプレイしてないけど。

[]今年もこの時期がやってきた LEE45倍

今年は45倍。ジョロキアによって30倍から45倍になるようだ。

ジョロキアとは世界でもっとも辛い唐辛子らしい。

この辛さ増強ソースがついてくるのが目的。通常の辛いだけのカレーではおいしくとも辛さが足りない。本当はLEE20倍くらいがちょうどいいが、30倍でもなんとか食べることができる。10倍では辛さがちょっと物足りない。

[][]Slimとかいうやつ

blogいろいろ見てたら今日はseasarのなんかがあったらしい。ストリーミングもしているとな。


というわけでSlimというのだけストリーミングで見た。

小さい文字はつぶれて読めないし、音声も10秒に1度はとまるような感じであまりわからなかったが、とりあえず車とかビールの話らしい・・・。

やたら途切れるからそう思えるのかもしれんが、導入部分が長すぎとも思った。


Slimというのは一言で言えばフルスタックフレームワーク、かな?ただし、今までのSeasar2と違ってSeasar以外のたとえばSpringとかとも衝突しないつくりになっているらしい。DIを見る限りEJB3から機能を絞ったものに見える。確かにDIは@Resourceだけでいいよね。


あとはスコープのアノテーションもわかりやすいとは思う。流行のメタアノテーションつかってる。これ自体は目新しさは特にない。


まぁ方向としてはかなりいい感じ。

フレームワークは機能増やす方向にみんな向かってるのでこういう覚えるのが少ないのは好き。いままでのSeasarの向かってる先はCoCによる記述量の削減だと思うのでデフォルト動作を覚えることが多くてつらかった。スマートデプロイの設定とか。


でもDBとか環境に依存する設定ファイルってところがちょっと気に入らなかった。そういうところはアーカイブにいれないところにあるのがいい。もちろん、設定ファイルからDIできるってのはすごくいい。JavaEEでもできると思うけど。

ドキュメントが英語のみってのはおいらにとってメリットはない感じ。

時間がなくてとばしたのがちょっといただけなかったかな。


Slimって.NETとかClickとかと同じような問題抱えてると思う。つまり非常に検索しにくい。

[]EJB3.1のテストその後

昨日の夜はミス多発で眠い目をこすりながらやるもんじゃないな・・・。

http://d.hatena.ne.jp/shin/20080519/p1のコメントの続きです。


とりあえずわかったのは@EJBで埋め込まれたクラスがあると、そのクラスの名前+@EJBのフィールド名、もしくは@EJBのname要素で指定したものがJNDIに登録される。

つまり

package hoge;

@Stateless
public class Hoge{
  @EJB
  private Hello hello;
  
}

というコードだとJNDI名は以下のようになる。

java:comp/env/hoge.Hoge/hello


name子弟を入れるとそれが直接マッピングされる

package hoge;

@Stateless
public class Hoge{
  @EJB(name="hogehoge")
  private Hello hello;
  
}

というコードだとJNDI名は以下のようになる。

java:comp/env/hogehoge

以下のようにマッピング専用のクラスを作ってそこに@EJBの定義をしておくと管理が楽になるかも

package hoge;

@Stateless
public class Config{
  @EJB(name="index.jsp")
  private IndexAction indexAction;
  
  @EJB(name="login.jsp")
  private LoginAction loginAction;
}

というコードだとJNDI名は以下のようになる。

java:comp/env/index.jsp
java:comp/env/login.jsp

ActionをインターフェースにしてbeanNameでセットしてもよいが、記述が多少面倒になるのでどうだろ。

package hoge;

@Stateless
public class Config{
  @EJB(name="index.jsp" , beanName="IndexAction")
  private Action indexAction;
  
  @EJB(name="login.jsp" , beanName="LoginAction")
  private Action loginAction;
}

2008-05-23

[][]どうせ比較したJavaは古いんでしょ

「今の」Java を見ていない人が「今の」Ruby を見て浮かれている(ようにしか見えない)

そうそう。Rubyは最新のバージョンとか持ってくるくせにJavaのバージョンは1.4時代の古のものと比べていたりね。5.0からはアノテーションジェネリクス等で開発効率や安全性が大幅に上昇したというのを見ようとしない。

しかもXMLが面倒だとかいいやがる人も多い。J2SE5.0時代のアプリXMLはほとんど触らないのに。EJB、Spring、Seasar2GuiceとどれもXMLを必要とはしていない。


ブログのシステムだって設計が終わっていればJavaでも十分15分で開発はできる範囲だよね。設計がすべて出来上がっている状態からの「○分でできるなんとか」というのはあまり意味のないものだと思う。

[]Glassfish V3TP2はマルチスレッドで動いていないくさい

コメントで指摘されたので調べてみたらサーブレットシングルスレッドくさい。

まぁ、スクリプト系のような小規模を対象としたアプリの場合それでもいいのかもしれないけど。開発が容易な代わりにパフォーマンスは出ませんよ、というモードはあってもいいのかもしれない。今のマシンパワーならばそれでも同時50アクセスくらい問題なくさばけるだろうし。

[追記]

ブラウザをかえないとかならず待たされるようです。タブで表示してもだめなようです。FireFoxIEにしたところ並列に動きました。



EJB3.1の仕様とJNDIを調べていたらやっとJNDI名が統一されて、ejb-ref等を書かなくても移植性のあるコードが出来上がるという仕組みにするらしい。3.0のときに盛り込んでおけよ、と思ったけど。

JNDI名は

java:comp/env/[スラッシュでパッケージ区切りにしたセッションビーン名]

で統一されるくさい?

ほかにも

java:comp/env/[@EJBで注入されたサーブレット]/フィールド名

でもアクセスが可能。

これらがEJB3.1の仕様なのかGlassfish独自なのかは不明。

2008-05-22

[]幻霧ノ塔ト剣ノ掟 を少しやってみた感想

まずメニューなどのUI的にかなり古臭いところは多い。レトロ風の雰囲気を出すのはいいのだが、メニュー体系がだめとか操作性が悪いのはいただけない。

アレンジモードだと右の壁が見えないことや、メッセージで一人目の表示が消えるのが少し見にくいかも。おかげでオリジナル。

オリジナルモードの音源はFM音源ではなくFCPSGっぽい音源。とくにリズム音がそれっぽい。メインメロディ聞いてると違う感じはするけど、FMにしろこういう非現実的な音は好きなので非常によろしい。

システムはWIZとかと同じように見えてまったく違う。経験値をためてやれることはいわゆるLVUPだけではない。

最初に4人をキャラメイク。最初からLV2のキャラがメイキングされているので初心者はそれを使うのもいいのかも。

職業というか技能は4つ。

マニュアルを見ると称号技能というのがあとで増えるようだ。学べるのはひとつらしい。まだ選べないので詳細はわからず。

経験値を使って取得できるのは以下の3つ。

補助技能は罠解除とかダンジョンにもぐるのに役に立ちそうなものから、歌とかダンスとかよくわからないものも。クエストに影響するかもしれない。

パラメータアップはLVUPでは行われない模様。必要系見地がすさまじいので序盤は無理。

基本技能は最初に選んだ技能が最初からLV1になっていて、それ以外ではLV0。最初に選んだ技能をあげてはじめてLVがあがる。LVがあがらないと最大HPが増えないので器用貧乏だと打たれ弱いということになる。

また、装備が特殊で面白い。基本的に職業がないということは誰でも最強装備をしてしまうんじゃないかと思い勝ちだが、装備で制限が出る。たとえば、ダガーをもつと司祭の魔法が使えなくなる。クォータースタッフは盗賊技能が使えなくなってしまう上に両手。ちょっと強めのよろいになると魔術師どころか盗賊にも制限が出てしまうあたり、ウルティマWIZといった昔のRPGっぽい。というか元となったTRPGがそう。

さらに、武器にもACが設定されていて受け流しが考慮されているようだ。たとえばクォータースタッフは両手装備で盾がもてないがAC-1、受け流しができなさそうなフレイルACが0。弓も同様。

ということは、さまざまなスキルを使おうと思うと武器防具が大幅に制限されてしまいHPがあがらないだけでなく大変な制限を受けることになる。戦士だけは武器制限が一切ないので戦士+その他1つというのが使いやすいと思われる。また、制限がない戦士はこういったシステムのためにひたすら技能とパラメータだけあげていくのが効率がよさそう。

魔法は性格の秩序と混沌によって覚えれるものが変わるようだ。いわゆるWIZでいう寺院(神殿)は混沌と秩序の2つあるのも面白い。片方の寺院には入れないのだ。エルフドワーフといった種族は性格が固定されるので使いにくいかも。特にエルフは中立固定なので高い知性があるのに司祭になれない。

宝箱には複数の解除順序が設定されていて、ラッチをはずしてばねをはずして・・・などの順番が必要。盗賊技能で失敗するとこの順番がばらばらになる。


と、かなり特殊なシステムだが、いわゆる世界樹などのようなスキル性ではないくせに自由度がやたら高い。装備を考慮してどの技能を伸ばすかというのは楽しそうだ。最初はひとつに集中して伸ばすのがよさそう。


最後に、体験版はできがわるいのであれをやらないほうがいいと思う。エンカウント率とか戦闘中のターゲット変更とか製品版ではちゃんと大丈夫。4人PT以外ではフリーズしたりするので必ず4人で組むこと。


とっつきは悪目だが、味のあるテキストと特徴のあるシステム(最初はWIZクローンかと思っていた)でかなり面白いかもしれない。

[]DS ダンジョンRPG 幻霧ノ塔ト剣ノ掟 ゲットだぜ

ヤマダ電機にひとつだけあったので即購入。ヘラクレスの栄光DSも本日発売だが、こちらは数が多かったことやTVCMで任天堂販売なた目入手制覇そんなに悪くはないだろうということでこちらにした。レシートを見ると「ゲンムノトウトケンノオキテ」と間違って登録してあるっぽい。

そもそもカタカナの読みにくいタイトルにする必要はあったのだろうか。略称もつけにくいのはデメリットか。「げんむのとう」としかいえないか。

サクセスの3DダンジョンRPGということでかなり不安はある。ファミ通の評価もかなり低かったようだ。あてにならんけど。

バグバグ世界樹2も割と楽しめたし、難易度が高いこと自体は問題ではないと思う。ちなみに世界樹2は難易度が高いのは序盤だけでクリアまでは難易度は割りと低め。


このゲームはオリジナルモードアレンジモードが存在する。

BGMとグラフィックが変わるのだが、正直どちらかに統一してその分作りこんだほうがユーザーとしてみるとよかったのではないかと。グラフィックとBGMが2倍かかるというのはもったいない。過去にシステムはまったく変わらず切り替えが可能なRPGワンダースワンの魔界塔士SagaWindowsハイドライド3がある。これらは元々オリジナルモードがが過去に存在したためであって、新規に2つ作ったわけではない。もっともWindows版はグラはアレンジバージョンで、BGMはオリジナルバージョンに差し替えて遊んでいたが。

CDがついてきたが、中身はあまりいい感じではなかった。パッケージングが非常にこっていた世界樹2とくらべて、こちらはCDRで焼きましたとでも言うようなパッケージング。俺はパッケージにこだわらないので胴でもいいけど。曲はオリジナルモードのほうがよさそうだということがわかった。


とりあえずmkeiさんのために地雷ふんどきましたので、詳細は後ほど。

2008-05-21

[]Wii VC ファンタジーゾーンの順位がぐんぐん上昇中

配信されたのは3月だというのに、なんだこれは。

ACと平行して開発されたSG MKIII版はかなり完成度の高い作品だということは一応知ってる。隣に住んでた人がMKIIIもってたから。これはやはり落とさなければならないか。500円と手ごろな価格で名作が遊べるのはWiiの魅力。


と思ったら、今回の順位が高いのはMD版のスーパーがつくほうだった。これはたしかオリジナル作品だったよね。これも600円と非常に安いのでどちらも落とすべきか。



そういやえふおうさんはファンタジーゾーンマニアらしい。2種類のファンタジーゾーンが遊べるWiiはどうでっか?

2008-05-20

[]今日からGガンダム

先週Vが終了したので。どこかには予告としてWがのっていたんだが、Gでよかった。

わかりやすいスピーディな展開はいいね。しかし銃撃が利かない人間ってすげー。

ガンダムが恐怖と憎しみの対象ってのもいい。地味にBGMがすごくいい。

Vよりはまともな作品になりそうな予感。


キャラデザ作画監督はVと同じ逢坂浩司氏か。この人も去年若くしてなくなったんだよね・・・。担当したのは名作ばかりでほんと悲しい。

[]今週のDBZ ベジータ死す

TVオリジナルストーリーだったバーダックを導入した名シーンがなつかしすぎる。

せめてバーダックのテーマ曲ながしてほしかったけど、原作にも取り込んでくれたというだけで十分か。

しかし、ナメック星にきたときは界王拳つかって18万とかだしてたのに、1度瀕死になったくらいでなにもつかわないで推定戦闘力100万を余裕で超えるベジータのさらに上をいくくらい強くなったのは謎。

所詮「俺を半殺しにしてくれ!」という方式では上昇率が少ないということか。

[]NetBeans 6.1 の新機能 その7

ファイルのペーストをするとき、通常コピーとリファクタリングコピーに分かれたようだ。いままではいわゆるリファクタリングコピーしかなかった。

もっとも、バグがないわけではない。

ルートパッケージのクラスを移動するとインポートがおかしくなる。

まぁそうなる理由はわかるんだけど。6.0のコピーもコピー元のパッケージをインポートするのでそのころからあったのかもしれない。

2008-05-19

[]Glassfish V3 TP2でJavaEE 6 の EJB3.1を触ってみる。

デフォルトのままだとEJBの昨日は入っていない。プラグインで追加してあげる必要がある。

一番簡単なのはGlassfishV3をNetBeansインストール、その後右クリックメニューを出すこと。


そこでglassfishv3-ejb3を選択、インストールする。

glassfish再起動後、デプロイ、実行する。

コード等はJavaEE5のままでいいみたい。

おかげでシングルトンとかはできないのだけれども、2種類のセッションビーンが使えればそれでいいだろう。

計算をするクラスを作る。

先頭にアノテーションをつけるだけのインターフェースすらない足し算と引き算をするクラスだ。

package javaee6test;

import javax.ejb.Stateless;

@Stateless
public class Compute {
    public int add(int num1,int num2){
        return num1 + num2;
    }
    
    public int sub(int num1 , int num2){
        return num1 - num2;
    }
}

続いてサーブレットを新規作成する。これはデフォルトのNetServletという名前。

out.printlnという部分とかはNetBeansデフォルトで生成されているのでそこを有効にして呼び出すコードを書いた。

以下抜粋

public class NewServlet extends HttpServlet {
   
    @EJB
    private Compute compute;
    
    /** 
    * Processes requests for both HTTP <code>GET</code> and <code>POST</code> methods.
    * @param request servlet request
    * @param response servlet response
    */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Servlet NewServlet</title>");  
            out.println("</head>");
            out.println("<body>");
            int a = 100;
            int b = 70;
            int result = compute.add(a, b);
            out.println(a + "+" + b + "=" + result);
            out.println("<br>");
            int result2 = compute.sub(a, b);
            out.println(a + "-" + b + "=" + result2);
            out.println("</body>");
            out.println("</html>");
            
        } finally { 
            out.close();
        }
    } 
}


実行結果。

すばらしい。

必要なライブラリは一切なく、Guiceのように手軽に扱うことが可能だ。SpringやSeasar2のようにインジェクトするクラスのパッケージ指定すら必要なく、まるでGuiceのよう。

さらにServletのバージョンも大幅に上がりマッピングすべきURLアノテーションで指定できるようになるんだっけか。


もはやJavaEE6時代にはコンテナはEJBをつかいつつ、Viewとロジックマッピングに専念するようなフレームワークが成功するような気がしてきた。

ちなみにGlassfishV3TP2の再デプロイ時間は・・・

May 19, 2008 11:47:15 PM com.sun.enterprise.web.WebApplication stop

情報: Undeployed web module StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/JavaEE6] from virtual server server

May 19, 2008 11:47:15 PM com.sun.enterprise.deployment.util.EjbBundleValidator accept

警告: enterprise.deployment.backend.ejbRefTypeMismatch

May 19, 2008 11:47:15 PM com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl bindToComponentNamespace

警告: naming.alreadyexistsReference name [java:comp/env/NewServlet/compute] already exists in web module [JavaEE6:/JavaEE6]

May 19, 2008 11:47:15 PM com.sun.enterprise.web.WebApplication start

情報: Loading application JavaEE6 at /JavaEE6

May 19, 2008 11:47:15 PM

情報: Loader: WebappClassLoader

delegate: true

repositories:

WEB-INF/classes/

/WEB-INF/classes/

----------> Parent Classloader:

,URls[]=)



May 19, 2008 11:47:16 PM

情報: ==> Restore Timers? == false

May 19, 2008 11:47:16 PM com.sun.enterprise.v3.deployment.DeployCommand execute

情報: Deployment of JavaEE6 done is 1016 ms


約1秒。すばらしい。

中身はEJB3とさほどかわっていないのだが、EJBアレルギーの人も触ってくれるだろうか。

2008-05-18

[]地上波 ナルニア物語 ライオンと魔女

あんまり面白くなかった。話はわかりやすいので小さなお子様向けかな。

これみたあとだと第2部見に行こうと思う人減るんじゃないかなと心配になる。

[]Cubby1.0.3をGlassfishV2UR2にデプロイしてみた

Cubbyが新しくなったようなのでGlassfishV2UR2にデプロイしてみる。

今回はソースではなくwarファイルそのままという手抜き。

また、前回はGlassfishV2UR1だった。

起動するときにワーニングやエラーが出るのは前回と同じ。

起動後は問題なさそう。

エラーメッセージ

cvc-complex-type.2.4.a: Invalid content was found starting with element 'type'. One of '{"http://java.sun.com/xml/ns/javaee":rtexprvalue, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method, "http://java.sun.com/xml/ns/javaee":fragment}' is expected.

org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'type'. One of '{"http://java.sun.com/xml/ns/javaee":rtexprvalue, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method, "http://java.sun.com/xml/ns/javaee":fragment}' is expected.

TLD parse error on /META-INF/html_basic.tld

java.lang.RuntimeException: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'type'. One of '{"http://java.sun.com/xml/ns/javaee":rtexprvalue, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method, "http://java.sun.com/xml/ns/javaee":fragment}' is expected.

気になった点は

  • 最初のHelloWorldがエスケープしていない。

あくまでもサンプルなのでエスケープしていませんという記述は必要かも。


  • Todo編集確認の「戻る」がきかない(ブラウザによるのかも)

  • そもそもCubby Exmaplesの内容がわからない。

たとえば配列とはなに?

Cubby Exmaplesで「こういうことをやります」というドキュメントが見当たらない。


  • ドキュメントのモジュール群をクリックして中に入るとその後の左のメニューのリンク先がおかしい。

[]この感覚懐かしい

社会の出来事、日常生活の感想

そういや、こういうことを言う人って減ったと思います。当時(12年くらい前)は、やはりCの技術者が圧倒的に多くC++もまだ標準仕様が固まっていない時期。みんな新しい言語に対して疑問や不満等いろいろといっていたと思います。いまや言語が増えすぎたということもあるかもしれないですが。

今では最初にJavaを勉強することが多いでしょうから疑問に持たない人が多いのでしょうね。Javaを理解するためには最終的にはCを理解する必要があるので先にCを勉強してほしいのですが、世の中即戦力という名の下にそれは省かれてしまいます。

このあとJavaを触り続けて2,3年くらいたったあとにはJavaのよさがわかるようになるはず。



ほかには会社に対する愚痴が多いですね。これもほんと懐かしい。自営業をになってからもう6年以上がたつ(今年は7期目)のですが、会社勤めしていたときにはみんなで頻繁に悪口を言っていた気がします。ストレスのはけ口なんでしょうね。最初の会社はそれでも足りなくてストレスで体を壊して辞めるわけですが、そこでやめてなければ今頃は違う会社にしろ会社員のままだったのかなぁとか思うこともあります。

昔は会社の中での開発がほとんどで、外へ人を派遣して稼ぐというスタイルはほとんどなかったと思います。おかげで人に聞いたり話し合ったり割と会社にノウハウがたまりやすかったのですが、いまや完全に個人に技術がつくようになってしまいました。元々個人に技術がついてくるのは当たり前でしたが、その部分がとんがりすぎてるのではないかと思います。そのへんをちゃんとサポートできる会社ならばそこはよい会社です。

今では上司がいないのでそれに対する愚痴というのはないのでさくさく仕事ができるのですが、それ以外で神経を使うために会社勤めをする場合と独立とどちらがいいとは即答できなかったりします。


仕事をする上ではやはり

  • 仕事のやりがい
  • お給金
  • 自由となる時間

この3つが大事だと思うのですが、ひとつでも納得したものがあればまだいいほうでひとつもない場合も多いと思います。フェスタのときのお話を聞く限り、mkeiさんはお金はあるが自由な時間がないと嘆き、えふおうさんは今は時間だけはとりあえずあるといい、おいらはやりがいだけがあるという見事にばらばらだったりします。当たり前ですけど独立をすれば仕事を選べるのでやりがいだけはあるとは思います。その結果暮らせるかどうかは知りませんが。

独立しようとして独立したわけでもないので、もうこればっかりは運命としかいえないですけど。

[][]JSFでお手軽Webアプリ開発 その1

JSFを使うとこんなに簡単にWebアプリを開発できる、ということを書いていきたいと思います。


まず、IDEとしてNetBeansを使います。AWTやSwing等の開発にNetBeans以外ありえないのと同じように、JSFEJBでの高速開発には欠かせません。

おいらは面倒くさがりなので、できるだけコードを書かない(ロジックのみに専念したい)ことやXML定義ファイルを触りたくないという人種なのでこういう選択になります。


フレームワークとして通常のJSFではなく、Visual Web JSFを使います。ViewのコンポーネントJavaのコードの一致を行ううえで欠かせません。


今回はVisual Web JSFの特徴をあげていきたいと思います。

ViewはJSPドキュメントである

viewはjspという拡張子がついていますが、jspドキュメント形式(xmlによるjspの再現)です。開いてみるとわかりますが、見事にxmlです。これはツールが扱いやすい形式を選んだということでhtmlをベースとした旧来のjspは使えません。つまり、jspソースはまず見ないということです。

Viewはぽとぺたで作れる

AWTやSwingアプリを作る際に、いまどきコードでコンポーネントを配置するコードは書かないことでしょう。それと同様にVisual Web JSFコンポーネントの配置のコードは書きません。対となるJavaのコードもバインディングは自動です。


ViewファイルとJavaのページクラスが1:1

ページの新規作成をすると必ずjspファイルとJavaファイルがついで作られます。ファイル名も同じになります。拡張子が違うだけです。これによって画面とコードの対応がわかりやすくなります。

このついになったクラスをページビーンとVisual Web JSFでは言っています。

ページビーンはAbstractPageBeanというクラスを必ず継承しています。


Teedaのページとテンプレートに対になった構造はおそらくこれを参考にしたのではないかと思われます。もっとも.NETやさらに昔にはBorland C++ BuilderDelphiというものがフォームファイルとソースファイルで1:1とかありますが。

[追記]

ひがさんによると.NETだそうです。

歴史はJSFのツールで最古

JSFの発表のときのプロジェクトRaveというのがこのツールの原点です。5年ほど前になります。発表自体は早かったのですが、製品はなかなか登場しませんでした。



その有償製品が Sun Java Studio Creatorとして2004年初夏に世に出ました。NetBeansプラットフォーム3.6がベースです。付属するアプリケーションサーバーが当時のマシンでは重かったことや、VMの速度等も今ほど早くなくてかなりヘビーでした。

また、ライバルはAccessということでRowSetのようなDBを前提としたつくりでした。Javaのコードを使ってロジックを書くことはNetBeansほど得意ではありません。細かいロジック等はSun Jva Studio Enterprise等で作った Webサービスを呼び出すのが普通だったと思います。一見難易度は低いように見えて実はかなり敷居の高い開発環境でした。



その後無償になったCreator2が登場します。2006年初頭です。ベースとなったNetBeansプラットフォームも以前の3.6から4.1となり大幅に快適になり、TomcatWebLogicWebSphereなども対応しました。EJB2の呼び出しにも対応しました。NetBeans4.1ではEJB2作成機能が取り込まれたのでオープンソースプロダクトだけで完結できるようになりました。が、あいかわらず2つのIDEを行き来するのは大変でした。

しかもリリースした時期が悪い。NetBeansは5.0がリリースされた時期でした。4.xベースでは古いと思われてしまうのは当たり前でした。このころから標準コンポーネント以外にwoodstockコンポーネントが登場します。Ajax等を利用したり高機能なコンポーネントが用意されることになります。基本的にはこのCreator2が今後のバージョンのすべてのベースとなります。この時期もRowSetを基本とした開発が前提になっているようで、付属するPointBase以外は扱いにくいものでした。その後RowSetのRIがでますが、お世辞にも安定してるとはいいがたいものでした。



不遇のCreatorでしたが、転機が訪れます。2006年末のNetBeans5.5の登場です。プラグインとしてCreator2の機能が取り込まれることになりました。NetBeansのその時点での最新バージョン(5.5.1にもすばやく対応)に対応できることで開発がまともにできるようになったのはこのバージョンからといってもいいでしょう。名称はVisual Web Packとなり、Creatorという名前は消えました。欠点はVisualWebプロジェクトと通常のWebプロジェクトが違うことでした。

5.5というバージョンはほかにもEJB3対応やJPA対応、JavaSE6対応など目玉だらけでした。Visual Web Pack以外にもMobility Pack、Profiler Pack、C/C++ Pack、Enterprise Packなどプラグインによる拡張も目玉としていました。



NetBeans6.0ではVisual Web PackはVisual Web JSFとなり、標準コンポーネントになりました。他のpackシリーズも同様です。インストール時に選ぶか、インストール後のプラグインダウンロードですぐに使うことができるようになりました。

Visual Webは通常のWebプロジェクトとやっと統合されました。あくまでも選択フレームワークという位置づけです。同様にStrutsも選択するだけで併用が可能です。6.1ではSpringMVCもこのフレームワークに選択肢として現れました。



NetBeans6.1ではデフォルトコンポーネントバインディングを行わなくなりました。そのかわり、ビジュアルデザイナ上の右クリックで生成や破棄がすぐに行えます。必要なコンポーネントのみコンポーネントバインディングをするという動きです。おかげでフットプリントは軽くなり、動作も速くなることになりました。


欠点は?

欠点はオールインワンであるがゆえにそれから外れた場合は面倒になるということです。

とはいえ、NetBeaans6.0からは通常のWebプロジェクトに統合されたので、他のフレームワークと併用することも可能です。このメンテナンス系の提携画面はVisualWebJSFだが、こっちの画面はプレーンなJSFStruts、SpringMVCという選択もできるわけで、どうにでもなります。

Visual Web JSFは広い範囲をターゲットにしたフレームワークではありません。そのかわり、特定用途(社内用業務アプリなど)に対しては圧倒的な開発効率を誇ります。どのフレームワークにしてもライブラリにしてもそうですが、ターゲットを絞った製品ほどとんがることができます。Visual Web JSFはWebフレームワークとしてはその傾向は強いと思います。

2008-05-17

[]JavaからUSBデバイスへアクセス

JavaからWindowsのUSBデバイスにアクセス

ほう、これはいい。

ライセンスLGPLということで問題はないだろう。


えふおうさんあたりがそのうちCQの付属基盤等ていじり倒してくれるに違いない。

[][]OpenJPAをさらに調べる

GlassFish上で動かすJPA実装をまじめに乗り換えようと思うのでもうちょっと調べてみた。DBPostgreSQL


LAZYは問題なく動くか

まったく問題なし。TopLinkと並んで安心して使える。

ID生成は

@GeneratedValue(strategy=GenerationType.AUTO)はGenerationType.TABLEと同じ。


おそらくほとんどの場合、ID生成はGenerationType.IDENTITYだろう。

strategy=GenerationType.IDENTITYは当たり前だがidはinsertせず。

そしてその後

executing prepstmnt 27464544 SELECT CURRVAL('item_id_SEQ')

となって値をシーケンスから取得している模様。これをidのプロパティへセットしているのだろう。

LAZY指定なしの@ManyToOne()

SQLのログを見てもらえると話が早い。

ここではMakerとItemという2つのテーブルを使っている。ItemテーブルがMakerテーブルを参照している。

executing prepstmnt 11263033 SELECT t0.id, t0.商品名, t1.id, t1.生産者名 FROM item t0 LEFT OUTER JOIN maker t1 ON t0.生産者id = t1.id

なんと連結してもってくる。TopLinkだと1件1件明細の数の分検索するのに対して、これは1回のSQLだけだ。件数やDBの種類、テーブルのサイズ等にも影響されると思われるこの問題だが、個人的にはOpenJPAが頭ひとつ抜けてる感じがする。

とはいえTopLinkではキャッシュを積極的に行うのでこのid単位での検索が非効率ではない場合もある。

一方でHibernate EntityManagerとOpenJPAはキャッシングをしないようだ。DBの値をいじると結果もすぐ変わる。TopLinkキャッシュをオフにするか、キャッシュを破棄して検索させるなどの処理が必要なのだが、この辺は考えなくてもいいようだ。

効率という点ではTopLinkのほうがいいとは思うが、DBを他のツールで直接扱うこともあるのでキャッシュオフにすることが多いことからOpenJPAなどの実装のほうが望ましい。

もっともremoteセッションビーンが可能なのならDBにはアプリケーションサーバー経由でしか触らないと割り切るのもありだと思うが。DBによる排他制御ではなく、アプリケーションによる排他制御もできる(とはいえ、HSQLDBくらいしかあまりやらないと思うけど)し。


persistence.xmlのサンプル

悲観的ロックも可能、SQLがログに出るようにという設定を。

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" 
    xmlns="http://java.sun.com/xml/ns/persistence" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="JPATest-ejbPU" transaction-type="JTA">
    <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
    <jta-data-source>jdbc/jpa_sample</jta-data-source>
    <properties>
        <property name="openjpa.Log" value="DefaultLevel=INFO,SQL=TRACE"/>
        <property name="openjpa.LockManager" value="pessimistic"/> 
    </properties>
  </persistence-unit>
</persistence>

結論

NetBeansGlassFishと最も相性のよいJPA実装はOpenJPAで決まり。デメリットはほぼない模様。

そういやJavaEEコンポーネントで実装を手軽にさしかえができてるのってJPAくらいか。

すべてのコンポーネントがそうなるとうれしいのだけれども。管理ツールの使い勝手とかそっちだけしっかりやってほしいというか。もっともGlassFishV2はTopLink以外満足しているし、V3の起動時間の速さは本当にすごいので変えるつもりはないのだけれども。

[追記]

JUnitがうまくいかない。webからのアクセスだとRemoteでもうまくいくのに。それでも現在最も安定して扱えるJPA実装のようだ。

2008-05-16

[][]最後にOpenJPAで日本語が通るか試してみた

NetBeansライブラリへ登録して、EJB-jar、warともに組み込む。ライブラリサイズはHibernate EntityManagerよりはるかに小さい。

そしてpersistence.xmlJPAベンダを切り替え。これはNetBeans6.1だとドロップダウンリストを選択するだけなので非常に楽チン。


・・・結果成功!日本語の扱いに問題があるのはTopLink & EclipseLinkだけということになった。


ログが一切書き出されていないようなのでそれを表示。

persistence.xmlのpropertiesに追加する。

<property name="openjpa.Log" value="DefaultLevel=INFO,SQL=TRACE"/>

これでSQLが表示される。

生成されるSQLを見る限りHibernate EntityManagerのようにひどいSQLを発行することはないようだ。よしよし。

あとは悲観的ロックだが、Hibernate EntityManagerはやり方はわからなかったが、OpenJPAはちょっと調べればすぐにわかった。

まずpersistence.xmlのpropertiesに次の一文を追加する。

<property name="openjpa.LockManager" value="pessimistic"/> 

そして、発行時のヒントとして

setHint("openjpa.FetchPlan.ReadLockMode",LockModeType.READ)

を追加する。


生成されたSQLを見る限り「for update」が追加されている。おそらくこれで動いてると思う。


ちょっと触ってみた感じだと一番まともに動いてるのがOpenJPAという結論になった。GlassFishとの相性が悪いTopLinkから差し替えていい気がする。

というか、TopLink(とEclipseLink)はGlassFishコンポーネントのひとつなのに相性が悪いというのがおわっとる。

まとめるとこんな感じ

JPAベンダ発行されるSQLライブラリサイズ悲観的ロック日本語LAZY
TopLink Essentials & EclipseLink(NetBeansGlassFishデフォルト)×
Hibernate EntityManager×××
OpenJPA

OpenJPAは日本語の資料ほぼゼロというあたりがアレだが、Apacheプロジェクトの中ではかなりまともな部類に入るような気がする。

[追記]

Hibernate EntityManagerはRemoteで動作がおかしくなるようでした。

[]なにこれ、すごすぎる

Spring+AspectJ+LoadTimeWeaving

えーっと。

ちょっとこれすごすぎるんでないかい?


ちょっくらSpringに浮気してくる。

2008-05-15

[][]せっかくなのでHibernate EntityManagerも日本語が通るか試してみた

Hibernate CoreとHibernate EntityManagerを落としてNetBeansライブラリ登録。

依存ファイルも大量にあってファイルサイズがすさまじいのでデプロイ時間増加につながってちょっとイラつく。

persistence.xmlベンダ設定のみを修正。ソースコードは一切かえずに実行!


・・・おおおおお、動いた!!!!!


NetBeansGlassFishと最も相性のいいJPAベンダHibernate EntityManagerってことか。なさけないけど日本人なら日本語が問題なく通るほうを選ぶよね。TopLink & EclipseLinkだけの問題らしいということもこれで確定したかな。あとでOpenJPAも試してみよう。


HibernateJPAの挙動が最も気に入らないので避けていた。LAZYの問題もあるし、トレースのログが見にくいし、なんといっても吐き出すSQLが一番へぼい。設定とかで変わるかもしれないけど、JPAでの利用においてはかなりへぼい。Hibernate EntityManagerの悲観的ロックの仕方もようわからないし。上であげたようにライブラリが大きすぎるのも開発に時間がかかるということなのでバツ。

JPAの範囲だけを使う場合、かなり欠陥だらけだと思うんだけど。



でも背に腹は変えられん。無理して使うか。

まともなSQLを返す設定方法と悲観的ロックの仕方がわかればとりあえずのりかえてもいいかも。LAZYはJPAの範囲に収まらないけど一応解決方法があるようだし。

[][]EclipseLinkで日本語が通るか試してみた

ライブラリを眺めていたらEclipseLinkがあった。


入れた記憶もないのだが、ディレクトリを見るとGlassFish V3TP2をインストールするとここに追加されるようだ。

そういやTopLink Essentialsは日本語の扱いに問題があるのだが、EclipseLinkでは直っているのか気になった。そこで試してみることに。



JPAのウィザードのところにも自動的に検出されているようだ。


ここでEclipseLinkを選び、ライブラリejb-jarとwarのプロジェクトにそれぞれ追加する。あくまでもremoteのテストなのでearは今回は触らない。パッケージングするとremoteセッションビーンでもLocalと同様の扱いになるためだ。


実行。

com.sun.rave.web.ui.appbase.ApplicationException: nested exception is: java.rmi.RemoteException: CORBA DATA_CONVERSION 1330446337 No; nested exception is: 
        org.omg.CORBA.DATA_CONVERSION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.DATA_CONVERSION:   vmcid: OMG  minor code: 1  completed: No
        at com.sun.corba.ee.impl.logging.OMGSystemException.charNotInCodeset(OMGSystemException.java:2093)
        at com.sun.corba.ee.impl.logging.OMGSystemException.charNotInCodeset(OMGSystemException.java:2111)
        at com.sun.corba.ee.impl.encoding.CodeSetConversion$JavaCTBConverter.convertCharArray(CodeSetConversion.java:336)
        at com.sun.corba.ee.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:249)
        at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeString(CDROutputStream_1_0.java:504)
        at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_string(CDROutputStream_1_0.java:493)

EclipseLinkもTopLink Essentialsと同様に日本語のフィールドがあるとだめみたい。まったく同様の現象から日本語のプロパティ自体はうまくいくと思われる。また、EJB単体でもうまくいくはず。

JPAを使う範囲においてはEclipseLinkとTopLink Essentialsは同様だと思っていいみたい。まだ1.0の実装だしね。

2008-05-14

[][]やはり業務系はJSF最強

正直、どれがいいのかわかんなくなってきました

おいらも似たような意見。

社内アプリやBtoBなどのユーザー数が特定できてサーバーリソースが想定しやすいような場合、定型のコントロールさえあれば困らない「いわゆるWebアプリ」はJSF最強。Teeda実装とRI実装の違いはありますが、イベント駆動はやはりやりやすいですね。特にVisualWebJSFは使い方を理解すればすさまじい開発効率が出ます。

一方で一般ユーザーをターゲットとした不特定多数の「動的コンテンツ」の場合、イベントベースである必要性は少ないと思います。この場合、画面のデザインは開発者がしない場合も多く、DreamWeaverでアクセス可能なhtmlソースというのがポイントになってくるかと思います。とはいえ、Strutsは個人的に採用はしたくない。おそらくSpringMVCかStripseかCubbyかの選択になってくると思います。

さらに携帯電話対応を考えると頭が痛い。Ajaxブームのおかげでリッチにscriptを使うアプリがどんどん増えていく一方で、それに追従できない携帯電話。この分野はほんと昔ながらのシンプルなcgiの延長でいいと思います。デザインもPC用と違って、見やすい配置であるか、より多くの環境で見ることができるかがポイントであって、cssがどーだとかそういうこととはわりと無縁です。WAP2.0によりXHTML-BASICが普及して・・・というもくろみはほぼなくなりました。各社のゲートウェイや端末のhtml解析が動けばそれでいいのです。

それぞれ目的としているところが違う以上、今後もフレームワークは選択して使い続けることになるでしょう。

  1. 社内向け業務アプリ(PC用)
  2. 社内向け業務アプリ(携帯用)
  3. 一般向け動的コンテンツ(PC用)
  4. 一般向け動的コンテンツ(携帯用)

4つあるうち1番目しかまだこれだ!というフレームワークには出会っていません。3番目は選択肢が多くPC向けはどうにでもなりやすいですが、携帯はどうすべきか難しい。むむむ…

[]SMART deploy

SMART deployに対応させてみる

これは助かる。

2.3までのseasar2は使えても、SMART deployになってからの初期設定の難易度が大幅に上がってあきらめていたところだったからだ。

設定の複雑さはEclipseプラグインが前提なのかなー。

とりあえず一番シンプルそうなSAStrutsのブランクをベースにNetBeans用パッケージにして勉強してみよう。

[][][]JNDIによるJPAアクセス

昨日のコメントだけにしておくとわすれそうなので、備忘録タグで。

persistence.xml

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" 
xmlns="http://java.sun.com/xml/ns/persistence" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

  <persistence-unit name="VWPTestPU" transaction-type="JTA">
    <jta-data-source>jdbc/jpa_sample</jta-data-source>
    <properties/>
  </persistence-unit>
</persistence>

web.xml抜粋

<persistence-context-ref>
    <persistence-context-ref-name>persistence/em</persistence-context-ref-name>
    <persistence-unit-name>VWPTestPU</persistence-unit-name>
</persistence-context-ref>

実際に使う場合のコード

EntityManager em;
UserTransaction ut;

//キー
Integer id = 100;

InitialContext ic = new InitialContext();

em = (EntityManager) ic.lookup("java:comp/env/persistence/em");
ut = (UserTransaction) ic.lookup("java:comp/UserTransaction");
            

ut.begin();
            
em.find(id);
            
ut.commit();

TransactionManagerのJNDIはアプリケーションサーバー依存なようでglassfishだと

tm = (TransactionManager) ic.lookup("java:appserver/TransactionManager");

となる。JNDI一覧でも見れないので注意。

さらにそれっぽくするためには


トランザクション管理をユーザーの手に任せたくない場合。適当なので注意。


まずロジックを実装してもらうインターフェース

public interface TransactionArea<T> {

    T run(EntityManager em);
}

続いてトランザクションを管理するクラス。とりあえず例外等手抜きなので要注意。まともに使うためにはかなりの部分をてこ入れ必要。

class Transaction {
    
    public static <T> T exec(TransactionArea<T> area) {

        EntityManager em;
        UserTransaction ut;
        T result = null;
        try {
            InitialContext ic = new InitialContext();

            
            em = (EntityManager) ic.lookup("java:comp/env/persistence/em");
            ut = (UserTransaction) ic.lookup("java:comp/UserTransaction");
            

            try{
                ut.begin();
                result = area.run(em );
                ut.commit();

            }catch(Exception ex){
                ut.rollback();
            }
            
            
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return result;
    }
}

インターフェースを実装する。ここにJPAロジックを書く。


    class UpdateCustomer implements TransactionArea<Customer>{
        private Integer id;
        private String name;
        private String tel;

        public UpdateCustomer(Integer id, String name, String tel) {
            this.id = id;
            this.name = name;
            this.tel = tel;
        }

        public Customer run(EntityManager em) {
            
            Customer c = em.find(Customer.class , id);
            c.set得意先名(name);
            c.set電話番号(tel);
            return c;
        }
        
    }

実行

        Customer c =  Transaction.exec(
                new UpdateCustomer(1,"新しい名前","03-hogehoge") 
                ) ;

        System.out.println(String.format("%d:Name=%s TEL=%s", 
                c.getId() , c.get得意先名() , c.get電話番号())
                );

結果

1:Name=新しい名前 TEL=030-hogehoge

予想通り。

printfを使ってないのはバッドノウハウ。printfはバッファリングしてないのでログが複数回かかれてしまうのを防ぐため。

TransactionArea#runの中で他のTransactionAreaのrunをEntityManagerをわたしてあげて呼び出せばそれもトランザクション内で実行される。REQUIREDのみで大概の場合問題ないのでこれでいいかと。


圧倒的な単体テストがやりやすいのがメリットだなぁ。依存するものがゼロだし。単体テスト時はSeasar2のシンプルEJB3で行って運用時はEJB3で実行できると楽だけど、さすがに無謀すぎるか。

2008-05-13

[]機動戦士Vガンダム最終話

んー。とりあえず話の内容が毎回ころころというか適当に作られていてひとつの話になっていない感じがすごいした。台詞と行動がばらばらだもの。


最終話の一つ前では主人公の父親が船を脱出したかのような描写があったのに、最終話ではその船が敵の旗艦に突っ込んだときに死んだかのようなイメージ映像が。わけわからん。


MSは特に敵は見分けがつかないものばかりで、ガンダム以外はかなりいまいちだと思う。


人はとにかく死ぬ。しかも意味のあるかっこいい死に方等は後半は少なく、あっさり死ぬ。

クロノクルは最後までどうしたいのかがよく分らなかった。タシロのほうがましだったと思う。

ラストのカテジナは目が死んでいた。これは盲目なのか、記憶喪失なのかその辺はあいまいにしたまま終わったようだ。

キャラ絵は非常に特徴的だが、温かみのある絵でかなりよかった。


総合的に見てほめられた出来ではないと思う。Vは適当にその場その場で現場の監督が話を作ったという感じがすごい強い。

[][]Seasar2とSpringでいまいちサーバー管理のJPAの使い方が分らない

まずRESOURCE_LOCALとかnon-jta-datasourceとかがはいってるwarやejb-jarGlassfishデプロイ時にはじくので環境がかなり狭められてしまう。

そしてSpringやSeasar2のサポートするJPAは独自のJPA管理ということで躊躇してしまう。アプリ側のコンテナ依存はしかたないにしても、JPAやデータソースは鯖側で持っていてほしい情報だ。そこをアプリ側で持つのは我慢できない人は多いと思う。

Glassfish管理ツールでjndi一覧を見る限りEntityManagerはjndiで取得することはできなさそう。

やはりJPAを使うならEJB3が一番だということか。GlassfishToplinkで日本語が通らない問題さえ解決すればべつにこだわる必要はないのだが。

もっともJPAを扱う場合NetBeansEJB3の開発効率は割といいので本当は日本語問題が解決されるのが一番なのだが、ここは正直期待できない部分なので回避方法を探すしかない。


シングルバイト圏とくらべてこういった部分だけでもかなりハンデだなー。


そこでJSFでは@EJBがきくことから、他のリソース系もインジェクトされるかどうか確かめてみた。

Visual Web JSFを起動して確かめる。Visual Web JSFJSFのRIを使いつつもさらに薄いラッピングをしている一種のフレームワークだ。NetBeansGUIエディタのようにボタンを貼り付けてそのイベントを書くだけでWebアプリを作ることが可能だ。

そこのイベントにコードを書いてみる。

    @PersistenceContext
    EntityManager em;

    @Resource
    UserTransaction ut;

    //ボタンクリックイベント
    public String button1_action() {
        
        try {
            ut.begin();

            Customer c = new Customer();
            c.set得意先名("なまえ");
            c.set電話番号("TEL");
            em.persist(c);

            ut.commit();
        } catch (Exception ex) {
            Logger.getLogger(Page1.class.getName()).log(Level.SEVERE, null, ex);
        }
        return null;
    }

まったく問題なく動いた…。

シンプルにアプリを書く場合悪くはないな。トランザクション管理はコンテナがやってくれるのが一番だが小さいアプリを書いたりそこまでやる必要としない場合はこれでいいかもしれない。ejb-jarが必要としないのでシンプルに扱える。

通常Visual Web JSFロジックセッションスコープのマネージドビーンにおいておくのが普通だ。そうなるとインジェクトしたEntityManagerの動きがどうなるかが怪しく感じるかもしれない。

そこでGlassfishのソースを調べてみた。NetBeansコンパイルの仕方が分らないのでデバッグ用のログも吐き出すことができず、エディタで開いての机上デバッグのみとなる。それでも、実際に動かしててどの用になるのか調べる必要が出てくる。

そこでリフレクションだけでひたすら追ってみた。フィールド変数までしか終えないが、getDelegate()とかを使うとトレースできないからだ。

たとえば一部を取り出したりするとこんな感じになる。

            try {

                Method method = em.getClass().getDeclaredMethod("_getDelegate");
                method.setAccessible(true);
                method.invoke(em);
                
                Field field = em.getClass().getDeclaredField("txManager");
                field.setAccessible(true);
                Object obj =  field.get(em);
                System.out.println("txManager:"+obj);
                
                Method tran = obj.getClass().getMethod("getTransaction");
                System.out.println("transaction:"+tran.invoke(obj));

            } catch (Exception ex) {
                Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
            }

Object型だけでひたすらリフレクションで追うという、あほみたいに時間がかかることをしたのは俺だけでいい。

getDelegate()やその他のメソッドは毎回生成されて初期化や後始末等されていて追えないので、_getDelegateを直接いじったりトレースしたりする必要が出てくる。


とりあえず軽く触って分ったのは、インジェクトされるEntityManagerはラッパであるということ。そしてEntityManagerをアクセスするたびに本来のEntityManagerが生成されるということ。

あとUserTransactionのcommitまたはrollbackでこれら取得した本来のEntityManagerがcloseされるようだ。

この場合EJB3でのユーザー管理のトランザクションと同じ動きなのでたぶん問題はない…はず。


ということはこのインジェクトをSpringやSeasar2コンポーネントに対しても行うことができれば手軽にアプリケーションサーバー管理のJPAを扱うことができるはず。そうすれば日本語問題も解決しなくてもなんとかなるかな。

[]Wii 600万台突破

Wii:1年半足らずで国内販売600万台 Wiiフィットも200万本、ダブルで大台突破

過去に日本国内で600万台突破した据え置き機は

  1. ファミリーコンピュータ
  2. スーパーファミコン
  3. プレイステーション
  4. プレイステーション

の4つでした。いわゆるすべて勝ちハードとよばれるものだけです。国内ではサターンががんばったのですが、この壁は越えられず。海外ではわりと健闘したDCは国内ではふるわず。


ちなみに1年半で600万台というのは過去最速です。いままでは発売前から勝ちハードが確定していたPS2が最速でしたが、Wiiは半年近く引き離しています。

2008-05-12

[]Struts2がなぜ重い

(4日目)3大Webアプリケーションのロードテスト

Struts2はアクションベースのままなのでJSFよりはどう考えても軽いと思い込んでいました。Stripesはどーなんだろ。

JSFglassfishの実装?)が意外とまともなのにも驚いたけど。元商用製品は伊達じゃないってことか。MyFacesはひどいみたいだけど、使ってる人は少ないと思う(JBOSSGlassfishはSUNの実装だし)のでかまわないか。

2008-05-11

[][]Full Ajaxやってみた

過去にシンプルにAjaxのみではどうなるかということでテストまではしたのだが、本格的に作ることはしなかった。テストはformによるsubmitだったが、今回はajaxのみということで非常にシンプルになる。

ページはプレーンなhtmlまんま(wicketとかカスタムタグのように修正が入るわけではない)。最終的にhtmlさえ生成されればいいのでビューは何のフレームワークを選択してもよい。

seasar2のセットアップで躓く

コンポーネントの登録にはSeasar2を。でもhot deployのセットアップの仕方が分らん。

hotdeploy.diconをincludeしたら大量にあれがないだのいわれた。

seasar2は環境設定ファイルが大量にあるのだが、どれが何を意味するとかのドキュメントが見つからない。


まずは一番シンプルな登録のみをやってみる。

・・・動かない。おかしい。前回の設定のままでも動かない。


そこでFileSystemComponentAutoRegisterに変更してみる。お・・・動いた。


とりあえず設定ファイルは以下のように。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN" 
    "http://www.seasar.org/dtd/components24.dtd">
<components>

    <component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister" >
        <initMethod name="addClassPattern">
            <arg>"fullajax.page"</arg>
            <arg>".*"</arg>
        </initMethod>
    </component>
</components>


ソース

ビューはこれだけ。真にプレーンなhtml。必要なのはページを表示したときにinit()を呼ばせるだけ。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <title></title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        
        <script src='dwr/interface/FullAjax.js'></script>
        <script src='dwr/engine.js'></script>
        <script src='dwr/util.js'></script>
        <script src='prototype.js'></script>
    </head>
    
    <body onload="FullAjax.init();">
        <form id="form1" >
            <input id="text1" type="text" >
            <input id="button1" type="button" value="送信">
            <div id="label1" ></div>
        </form>
        <hr>
    </body>
</html>


ページに関連付けされるクラス。テキストとラベルとボタンだけ関連付けしている。アノテーションの中の文字列はhtmlのidを指定しているだけ。これが関連のすべて。

package fullajax.page;

import fullajax.annotation.Text;
import fullajax.annotation.Init;
import fullajax.annotation.Action;
import fullajax.annotation.Label;
import org.seasar.framework.container.annotation.tiger.Component;
import org.seasar.framework.container.annotation.tiger.InstanceType;

@Component(name="/index.html" ,instance=InstanceType.PROTOTYPE)
public class Index {

    @Text("text1")
    public String text;
    
    @Label("label1")
    public String label;
    
    //画面開いたときの初期設定
    @Init
    public void init(){
        text = "初期値";
        label = "ここに表示されます";
    }
    
    //ボタンクリックされたイベント
    @Action("button1")
    public void submit(){
        label = "はろー" + text;
    }
}

実行

動作はソースから予想されるとおり。

開いた状態。初期値がinitメソッドの内容で上書きされている。htmlは適当な文字をセットしておいてもよい。

名前を入力してボタンをクリックする。

ポイントはjavahtmlの関連にはidのみを使っていること。しかもアノテーションでシンプルに。

できないこと

  1. ファイルアップロード

これだけはセキュリティ的にできないのでインナーフレームとか別の処理でやらせる必要がある。


さらによくするには

今回はテストということでStringとvalueを直接結びつけたが、これはコンポーネントにしたほうがよさそうだ。上のコードならば

@Text("text1")
TextField text1 = new TextField("初期値");

@Label("label1")
Label label1 = new Label("ここに表示されます");

    @Action("button1")
    public void submit(){
        label.setText( "はろー" + text.getValue() );
    }

のような感じで。こうすることによって、java側のライブラリcss等も細かく調整できる。


適当に作った割には満足した結果になった。

[]DS ヘラクレスの栄光 〜魂の証明〜 の音楽がいい

来週にも発売されるヘラクレスの栄光 〜魂の証明〜任天堂発売で価格も安いので気にはなっていた。

ここの動画を見る限りフィールドの曲、先頭の音楽ともにかなりよさげ。ゲームらしい音楽は好み。正直世界中の迷宮IIよりいい感じだ。古代の曲も昔風になっていたらよかったのに。

http://www.nintendo.co.jp/ds/yekj/battle/tairetsu/index.html



グラフィックのかなりよさげ。

http://www.nintendo.co.jp/ds/yekj/battle/ability/index.html

http://www.nintendo.co.jp/ds/yekj/battle/magic/index.html

キャラはあらかじめレンダリングしておいたのをビルボードで描画、拡大縮小と地面のパースで立体的に見せるところが秀逸。幻想水滸伝みたいな感じかな。

2008-05-10

[]パワプロ15の価格差

http://www.watch.impress.co.jp/game/docs/20080509/pawa.htm

機能はWiiのほうが多いのに低下がWiiのほうが1000円も安い。

これは戦略的なものなのか、ライセンス料の差なのか。なんか気になる。

ゲームそのものは気になってないけど。パワプロのベースになったリアル系生中継68K 2008とかなら少しはやりたいかもしれんけど。

[]イーモバイルがすごい

4月の携帯・PHS契約数、ツーカー終了でKDDIが初の純減

減少はツーカーの終了に伴うもので予想通り。

ポイントはイーモバイルの強さ。ドコモとほぼ同じ、auとも大差はない。エリアが非常に限られているために使いにくいのだが、それでもここまでとは。ウィルコムが減少しているのはおそらくイーモバイルにとられているためだろう。これでエリアが充実してきたらかなり面白いことになる。

データ通信専用としてみると新つなぎ放題は悪くはないんだけどねー。

[][]ShinGL3 0.66リリース

http://shin.cside.com/product/shingl3/index.htm

昨日指摘されたテキスト描画のバグを修正しました。また、動かないrubyスクリプトライブラリを削除してファイルサイズを小さくしました。

2008-05-09

[][]ShinGL3バグ報告

ShinGL3のバグ報告をえふおうさんからいただきました。ありがとうございます。

まずは宣伝

一応説明しておくとShinGL3はゲーム用のライブラリです。入り口はこちらです。

http://shin.cside.com/product/shingl3/index.htm

サンプルが旧バージョンのままなので今はだいぶ違いますけど、シンプルにBASICやX68でC+IOCSのように手軽に扱えます。Javaであることを意識したコードは必要ありません。

というか、JavaSE6のスクリプティングAPIに対応しているのでJavaScriptでゲームが作れます。JRubyはマルチスレッドの動作がちょっとアレだったのと、日本語がうまく扱えていなかったので放置中です。まともにスレッドが動くようになったら考えます。SPIをいれていろんな言語でそのうち試してみたいかなとは思っていますが。パイソンとか。


どういったゲームが創れるかというとサンプルプログラムがあります。アルファブレンディングや拡大縮小、回転機能等があります。

http://shin.cside.com/product/pw/index.htm

このゲームは確認が取れたWindowsでのみでしか対応はしていませんが、ジョイスティックも対応しています。

すべてJavaによって創られています。JavaSE 6のランタイムがある人はぜひ起動してみてください。キーボードのみでもプレイ可能です。

LinuxSolarisの環境があればそれらでも動作確認させたいところです。ゲーム向けのアクセラレーションがしっかりきいているハードはやはりWindowsメインだと思いますのであまり害はないかもしれませんが、せっかくのクロスプラットフォームですから、確認したいところです。


ありがたい報告

VistaではAeroをいれないと処理速度が大幅に落ちる可能性があるようです。Vista環境を持っていないので確認できていませんが、OpenGLアクセラレーションがきかないと大変なことになるので注意です。


もうひとつサンプルでも使っているShinGL3OpenGLにあるPRINTメソッドがバグもちです。JOGL1.1での新機能にとびついて放置してました。メモリーをどんどん食っていきます。後で修正します。できるだけ使わないほうがいいです。

えふおうさんありがとうございます。

[]昼ドラ スイート10〜最後の恋人〜最終話


最後で無理やりいい話にしようとしてたようだけど、全体的に見てひどい話だと思う。

女の浮気はいい浮気。結婚していても好きになったら仕方がないじゃない。私を愛してくれる男はすべて一途でいい人。

男の浮気はゆるせない。離婚するべき。

主人公や視点が女性陣側なのと、視聴者が女性が多いからということなんだろうか。よくある少女コミック的というか。


先週終わった昼ドラ ドラマ30みこん六姉妹2」のほうがはるかに愛の劇場っぽかったかも。というか「みこん六姉妹2」は前作よりも出来がよかった。最後の子供を生んでというのはかなり蛇足だけれども。続編作れないだろうし、いい人だった大藪先生の立場もない。むしろ、たった数日でプロと並ぶほどの腕を身に着けたという当たり何かあってもよさそうに見えたけど。睦は大人になってかわいらしさがなくなったけどいい人になりすぎ。


ちなみに今のドラマ30はひどいのでもう見ない。

[]「遅延評価勉強法」ってただのモチベーションの問題じゃない?

勉強が苦手な人向けの「遅延評価勉強法」

うーん、趣味のプログラミングならばこれ当たり前のことだと思うんだけど。

8bit時代はBASICが標準でついてきたが、誰もBASICの言語を完璧に勉強してからプログラミングするなんてことはなかったはず。自分の好きなところからいきなりプログラミングしたはずです。音を出したければPLAY文、キャラクタを表示したければLOACTE、PRINT、PUTSPRITEなど、入力をしたければINKEY$やSTICK、INPなどといった具合にそこにだけ特化していたはず。DATAだってキャラクターデータ等が必要になってはじめて覚えた。

仕事で使うならば言語部分はちゃんと覚えておく必要はあるけど。


とはいえ、仕事で使う範囲のものであってもすべてをマスターしている人はいないはず。毎年追加されるAPIは膨大になり、把握はしきれない。

と考えると別に不思議でもなんでもないのでは?


モチベーションが違うからさくさく覚えるのは当たり前。

いろんな書籍が出てるけど、やっぱりモチベーションを維持するには好きなものを作ったりしながら覚えるのが一番だ。最初にclassが必要です。mainがstaticな意味とか一からまともにやっていたらみんな投げ出してしまうだろう。ゲームとか音楽とかそういうのをスタート地点として入門用の書籍があるといいのだけれども、BASICアセンブラ時代はそういうのがあったけど、C言語時代になってから一気に敷居があがって消滅したんだよね。

Cの標準ライブラリは環境依存しないようになっているけど、これだけでは音楽もゲームも作れない。おかげで「はろーわーるど」とかわけのわからないのが入門用になってしまった。こんな定数を表示しても楽しくはないし、モチベーションもあがらない。当時はBASICのように高い生産性をだしつつアセンブラのように高速な環境がほしかったからみんな我慢して覚えていたけど、マシンパワーが大幅に上がった今ではどーなんだろ。

そしていまやどの言語も「はろーわーるど」からはじまるつまらない入門用書籍だらけになってしまった。たとえばJavaは標準でグラフィックは表示できるし、音楽もいろいろと再生できるんだからそんなところに縛られる必要はないと思うのに。

おかげでどの書籍を薦めても長続きしない。ここ数年では楽しく学べることをやってやろうというのは「創るJava」くらいだろう。Javaは標準ライブラリが非常に幅広い分野をおさえているんだからLLに比べてこういう書籍は有利になりやすいはずなんだけど。

2008-05-08

[]Eee PC 900は想像以上にしっかり作ってきたようだ

ASUSTeK Computer「Eee PC 900 台湾版」〜高解像度液晶と大容量SSD搭載、性能も向上

かなりしっかり作られている。液晶が解像度だけじゃなくて発色などもよくなっているようで、これはレッツノートも見習うべきだろう。

Eee PC 4G-Xはとりあえず一部門でテスト的に作られたという感じが強いのに対して、想像以上に盛り上がったので予算が与えられてEee PC 900の開発につながった…と考えたくなるくらい。

[][][]せっかくなのでSpringMVC2.5で書いてみる。


せっかく Spring Framework MVCのプロジェクトがあるのだから、2.5らしい書き方をしてみる。

まずWEB-INFの下にある「dispatcher-servlet」を修正する。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
        http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
    
    <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"/>

    <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>

    <bean id="viewResolver"
          class="org.springframework.web.servlet.view.InternalResourceViewResolver"
          p:prefix="/WEB-INF/jsp/"
          p:suffix=".jsp" />
    
        <context:component-scan base-package="shinsan"/>
</beans>

次に/WEB-INF/jsp/index.jspを修正する。

<%@page contentType="text/html" pageEncoding="UTF-8" %>
<html>
    <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <body>
        <form action="result.htm" method="post">
            <input type="text" name="name">
            <input type="submit" value="送信">
        </form>
    </body>
</html>


DreamWeaverなどですぐに修正できるのがjsphtmlテンプレートで扱う理由だと思うので、ループや値表示以外にカスタムタグを使うのは好きじゃないので通常のhtmlで。そうでないならVisualWebJSFのようにツールですべてやってくれたほうがいい。

同じところに結果表示用のresult.jspを追加する。

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Hello</title>
    </head>
    <body>
        <h2>Hello ${name}</h2>
    </body>
</html>


そしてコントローラクラスを作成。1つのクラスで複数のURLを作成するというマルチアクションコントローラというやつ。

package shinsan;

import org.springframework.stereotype.Controller;
import org.springframework.ui.ModelMap;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;

@Controller
public class HelloAction {
    
    
    @RequestMapping(value="/index.htm" )
    public String index(ModelMap model){
        return "index";
    }
    
    
    @RequestMapping("/result.htm")
    public String result(@RequestParam(value="name" ) String name , ModelMap model){

        model.addAttribute("name", name);
        
        return "result";
    }
    

}

Spring MVCはやりたいことに対してたくさんの書き方があるのがいいと感じるか、面倒だと感じるかは意見が分かれるかも。

これでindex.htmで入力した値がresult.htmに表示されるというよくあるサンプルは出来上がり…

かと思ったら日本語を入力したら文字化け。UTF8使ってるというのに。いったいいつの時代のフレームワークだよと。


これML版のNetBeansだとこのまま出してしまうのはまずそう。おそらく日本語以外も問題がでまくりだと思うし。


というわけで、なつかしのエンコーディングフィルタを入れる。

org.springframework.web.filter.CharacterEncodingFilter

というのがそれだ。

web.xmlを開いてフィルタのタブを選択する。GUIで入力しよう。

これで文字化けはなくなった。エスケープ等してないので、その辺はちゃんと対応するべし。


ラッピングが薄いのでフレームワーク入門用としては結構優れているかも。

[]はてなが最近また不安定に

最近はてなの調子が悪すぎる。

長文書いたのにメンテナンス画面が頻繁に出て全部消えるという悪夢。すげーつらい。

2008-05-07

[][]NetBeans 6.1 の新機能 その6

今回はSpringサポートを見てみる。

まず、Webプロジェクトの新規作成をする。そこで選択するフレームワークとしてSpring MVCを選択。

Spring単体が見つからない。なにこれ。いやな予感がする。

自動でサーブレットの設定がされているのは当たり前として、そこで自動生成されているindex.jspを開いてみる。


・・・おおう。これ文字コード指定してないからだな。実際テキストエディタでUTF8指定して開くと日本語が表示される。そこでテキストエディタ

<%@page contentType="text/html" pageEncoding="UTF-8"%>

の一行を先頭に追加する。


まちがってもNetBeans上でやってはいけない。すでに化けていることから分るとおり、その後保存をすると文字化けした状態でUTF8で保存されてしまう。

そのまま実行してみると問題なく「index.html」というアクセスで表示される。SpringMVCはシンプルなため動作確認しやすいのはいい。のだが、xmlの補完等が怪しい。あくまでもクラス名認識してくれるだけのサポートのようだ。右クリックしても何もメニューが出ない。

なんてこったい/(^o^)\。


なーに、コントローラを新規作成してみればそのありがたみは分るはず。

・・・う、用意されてるコントローラのウィザードが2つだけとかどんだけ。しかも名前からしてこれは1.3時代のSpringMVCのもののように見える。

い、いや、何かの間違いだ。自動生成されたコードを開けば安心するはず!

public class HogeController extends AbstractController {

    public HogeController() {
    }
    
    protected ModelAndView handleRequestInternal(
            HttpServletRequest request, 
            HttpServletResponse response) throws Exception {
        
        throw new UnsupportedOperationException("Not yet implemented");
    }

}

なんてこったい/(^o^)\。

正直これはSpringサポートといえないと思う。しかも予想通り1.3時代のMVCの雛形をちょっと作ってくれるだけ。

JSFEJB3のサポート具合と比較するとかなり劣るのは分るのだが、正直言ってあんまりよろしいとはいえないStrutsサポートより手抜きに見える。

Spring2.5サポートと書いてあるから何かと思ったが、あくまでもライブラリとしてバンドルしてるだけなのね。MVCの2.5サポートだったらすごいことになるかもしれないと思ったけど、あくまでもディスパッチサーブレットとコンフィグファイルの関連付けをしてくれるだけ。



Springサポートは期待しないほうがいいだろう。これがもしMVC2.5フルサポートだったら標準JavaEEAPI群が駆逐されるかもしれないくらいの衝撃だったのだが。それだけMVC2.5はすごいかわったのに。2年前の状態に戻された気分。


NetBeansではおとなしくJavaEE標準APIを使うのが一番開発が容易という状況は6.1でも変わらないと思う。期待していただけにがっかり度もすごい。

[]java.io.FileReader#read()が正直分りにくいかも

java.io.FileReaderに泣く

コメントに囲うと思ったけど、自動トラックバックしてくれるようなのでこちらに書く。


どうでもいいこととしてFileは使われていないようだね。

この

String.valueOf((char)ch));

が実に気持ち悪い。キャスト慣れにくい。常に変数の型を把握してないといけないというか。

キャストが必要なのはString.valueOf()の引数にint型とcharがあって区別するため。

やりたいことを認識して勝手にchar引数のほうを使うなんて判断ができる言語があるとは思いにくいけど。


さらにいうと厄介なことにFileReader#read()が特殊なメソッドであるということ。

終了条件と結果をひとつの引数で返すために、2バイトの結果でいいはずなのに無理して4バイトに拡張して2パターンを1つにまとめて返すという複雑なことをしている。したがって2バイトを取り出すということが必要になってしまっている。

正直お勧めできないメソッドだと思う。初心者にscanfを教えると大変なことになるというのに似ているというか。

使うならばchar配列を使うほうがいい。変数ふくめて似た感じのコードを書くとこんなところか。

private void fileRead(String fileName) {
    try {
        FileReader filereader = new FileReader(fileName);
        char[] buf = new char[1];
        while(filereader.read(buf) > 0) {
            char ch = buf[0];

            jTextArea1.append( String.valueOf( ch ) );
        }
        filereader.close();
    } catch(Exception e) {
        e.printStackTrace();
    }
}

さらに効率よくと考えるならばこの配列の数を増やしてバッファリングすることや、後でまとめてappendをするということを考えればよいが、それは2日目の内容ではないなぁ。より安全なcloseもまだ2日目の範疇ではないだろう。

その辺を考慮するとたとえばこんな感じになる。

private void fileRead(String fileName) {
        FileReader fileReader = null;
        StringBuilder sb = new StringBuilder();
        
        try {
            fileReader = new FileReader(fileName);

            char[] buf = new char[1024];
            int len ;
            while ((len = fileReader.read(buf)) > 0) {
                sb.append(buf, 0, len);
                System.out.printf("%,d char読み込み%n",len);//debug用
            }
            
            jTextArea1.append( sb.toString() );
        }catch (Exception ex) {
            ex.printStackTrace();
        }finally{
            if(fileReader != null){
                try {
                    fileReader.close();
                } catch (IOException ex) {
                    ex.printStackTrace();
                }
            }
        }
    }

Javaは使えます、という人材の試験にファイルを読み込んでテキストエリアに表示してよ、というのはわりといい判断材料になるかもしれない。

「例外はどうします?仕様に明記されていないのでとりあえずログ出して握りつぶしてもいいでしょうか?キャラクタセットはデフォルトのままでよいでしょうか?」などといってくるようならコード見なくても安心といったところだが。

しかし、今まで何度も言うようにやっぱりはじめて言語を勉強する場合Javaは向かないかもなぁ。とはいえ、今現役の言語はどれも入門用には思えない。オブジェクト指向のない関数ベースの分りやすい言語が一番だが、BASIC関数すら知る必要がなく、敷居が低かったことを考えるともっと下げないとだめだなぁ。

[]そういやcommons使わなくなったなぁ

本質的でない記述が大規模開発の役に立っているかを見ていて思った。commonsって最近ほとんど使わなくなったよね。


というかApacheのプロダクト自体、HTTPDTomcat以外まず使わなくなったような。


まずcommonsの依存とか多すぎて使いにくい。GuiceJava EEの環境構築のシンプルさは最高。


もちろん、昔はお世話になってました。

たとえばいまやほとんど使われないコネクションプーリングのライブラリであるDBCPは有名でしょう。でも商用DB等をはじめとして各社コネクションプール用のライブラリはあります。そちらのほうがパフォーマンスや細かいこともできて使い勝手がいい。また、アプリケーションサーバー側ですべてセットアップするのが当たり前になってからはさらに離れました。

一番使ったのはJXPath。標準APIXPathがなかなかこなかったのでXMLを扱う場合重宝していました。J2SE5.0以降は標準搭載されたので使う機会は減ったはずです。JavaSE6からはJAXB2.0搭載でさらに減ったでしょう。


どちらも便利な小粒なライブラリを選択したというよりは、実装そのものが貴重だったものを選んだという感じがしますが。


何より使わなくなった原因はJavaのバージョンが低すぎるということ。1.2とか1.3とかがターゲットになっています。互換性のためですが、おかげで高速化の恩恵は受けないとか、新しい構文未対応とか今となっては使い物にならないライブラリが多すぎる。1.4時代くらいまではよかったんでしょうけど。いまやバージョンは6が登場して1年半くらいたちました。そしてもうすぐ7が登場します。

今後もピンポイントで採用はあっても大々的に採用することはますます減るでしょう。

ライブラリって旧システムのサポートのために互換性も大事ですけど、最新の環境をサポートするというのも大事なはずです。商用製品じゃないとこの辺はつらいところかも。

2008-05-06

[]ドラゴンボールZ フリーザ編の主人公はベジータ

東京MX火曜22:00のフリーザ船も佳境にはいった。来週は悟空が復活するらしい。

最後孫悟空がもっていくのはベジータ編と同じだけど、それ以外の活躍度や成長を見ると主人公はベジータだなぁ。

本来ならばキュイと同等の戦闘力だったのが、地球にいってぼろぼろになって逃げ出してから大幅パワーアップ。ドドリアさんにも勝てるように。変身後のザーボンさんには負けるものの、そこでまた復活してザーボンさんを倒す。

そしてギニュー特戦隊にガグブル。特戦隊にはボロボロにされるが、悟空が助けに来て生き延びる。ここでまた復活してパワーアップ。その後のギニューとのやり取りを見てるとギニューにはかなわないもののそれ以外には勝てるらしい。悟空の強さに嫉妬しまくる。

でも、このままの戦闘力だと御飯とクリリンあわせれば第一形態にはなんとか勝てるかも!と言わせるくらいの戦闘力にはなりそうもない。その後寝不足から寝てしまうが、軽く休んだことによって大幅に強くなったのかもしれないけど。

フリーザ第1形態の時点で3人そろってもいいところ五分まで。そこでフリーザは第2形態になり、圧倒的なパワーのために動けないほどおびえる。このへっぽこ具合がよろしい。クリリンや御飯は必死に戦うのに。クリリンがやられたときには御飯が瞬間的にフリーザに痛かったといわせるくらいのパワーアップ振りに嫉妬をおぼえるあたりの描写が面白い。

しかもそこへ無敵のパワーを手に入れたと豪語するピッコロさんが到着。ここでさらにベジータさんは嫉妬。ここまでくるとかわいい。

結局ピッコロさんの力も第2形態にやや劣るくらい。恐怖を見せてやるといいつつ第3形態へ。ピッコロ手も足も出ず。やられそうになったピッコロさんをすくうため御飯がまた力を発揮。デンデに復活させてもらっていたので大幅に強くなっていたということもあるだろう。ここでベジータさんはまた嫉妬。「スーパーサイヤ人に近いのはやつ」という台詞がなける。

第2形態の時点でみんな負けるくらいの強さなのにさらに絶望を見せるといいつつフリーザは最終形態へ。ベジータはあわててクリリンに半殺しにしてもらう。おかげで大幅にパワーアップ。こんなにパワーアップが楽ならばいくらでも強くなりそうだけれども、デンデ依存症になりそうだ。

そして最終形態ともなるとまずピッコロさんですらも攻撃が見えない。そこで攻撃が見えるほどまで強くなったベジータ。ここで自分はスーパーサイヤ人だ発言。もちろん、フリーザ最終形態には手も足も出ず。


このようにフリーザ編はベジータ嫉妬成長の歴史である。


そういやフリーザ、4形態ですべて声の出し方が違うのはさすが。どうしてもフリーザといえば第1形態の声のイメージだけがすごく強いけど。

昔のアニメは次回予告のネタばれがすごい。TV埼玉火曜日23:00から放送のVガンダムもネタばれがすごい。

Vガンダムといえば今日の特攻がかっちょよかったけど、その前に特攻かけてる旗艦があるのでインパクトはすごい弱い。インパクトはすべてカテジナさんにもっていかれたということもあるか。カテジナシャクティがいなかったらすげーあっさりとした話になってそう。どっちも悪魔という意味で。

来週は最終回。次はガンダムWがはじまるようだ。Gじゃないのかー。TV埼玉はここ最近だけで初代からZ、ZZ00800083、Vと積極的にガンダムを放送している。TV埼玉は元々ロボットものアニメはほぼ制覇しているというすさまじい放送局だけど。そのおかげでダグラムのよさにほれ込んだわけだが。

[][]Hot DeployとNetbeansとの相性がすこぶるよい

Seasar2自体はNetBeansをサポートしていないが、相性はすこぶるよろしい

NetBeansデフォルトディレクトリ配備をする。

そして、現在編集中のファイルを保存し、コンパイルするショートカットが「F9」。HotDeployをしているとこれですぐに動作を確認可能。

「F11」ではプロジェクト内のすべての保存していないファイルを保存し、コンパイルするべきファイルがあればコンパイルがされる。これもHotDeployしていれば即座に確認が可能で非常に便利。

そして「F6」でF11+再配備。これがセッションを破棄し、最初から実行することになる。


このように設定は一切必要とせず、Hot Deployに対応しているのだ。


環境によるSMART Deployの切り替え

ぱっと見た感じSMART Deployをアプリケーションサーバー側の設定できりかえれるように見えなかったので、軽く作ってみた。標準でそういう機能はあるかもしれない。環境設定ファイルを変更し、アーカイブを作り直しというのは業務アプリを作る側としてはありえない(テストをしたバイナリと実行するソースは同一である必要がある)のでたぶんこの機能はあるはず。

環境を一から整えるのが面倒だったため、SAStrutsチュートリアルのプロジェクトに記述することに。

適当にファイルを見ると「s2container.dicon」が切り替えているようだ。これはドキュメントを見る限り同様のリソースに依存しているため、このままでは使えない。Seasar2は詳しくないのでよく分らないが、OGNL式というのでこの辺はできるらしい。

ふむふむ、staticなクラスを用意するのが一番楽そうだ。というわけで、まずクラスを作る。

package tutorial;

public class SmartDeploySelector {
    public static final String key = "SMART_DEPLOY";

    public static String select(){
        String value = System.getProperty(key);
        if(value != null){
            return value;
        }
        
        return "warm";
    }
}

今度はこれを使用するように「s2container.dicon」を変更する。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container 2.4//EN" 
	"http://www.seasar.org/dtd/components24.dtd">
<components>
    <include condition="@tutorial.SmartDeploySelector@select() == 'warm'" path="warmdeploy.dicon"/>
    <include condition="@tutorial.SmartDeploySelector@select() == 'hot'" path="hotdeploy.dicon"/>
    <include condition="@tutorial.SmartDeploySelector@select() != 'warm' 
            and @tutorial.SmartDeploySelector@select() != 'hot'" path="cooldeploy.dicon"/>
</components>

Glassfishのメニューの一番下のConfiguration> System Propertiesで設定を記述する。

こうすることによって、開発時はHot Deploy、運用時はCool Deployとバイナリを一切変えずに変更することが可能だ。

[]NetBeans 6.1 の新機能 その5

対象となる文だけにtry〜catchできるようになったようだ。

6.0のときはブロックのみになっていたので使い勝手が悪かった。そして5.5.1まではこの文のみにtry〜catchがされていた。

つまり、これもあまりにも使い勝手が悪かったので戻った機能の一つだ。

そしてブロック単位も引き続きあるし、範囲指定をしてそれをtry〜catchでくくるというのも引き続きある。

柔軟性が増したというべきかもしれないが、ブロックスコープの例外処理ってのが正直あんまり使う場面が見当たらない。


従来はあったのに機能が変わってしまって6.0でコードが書きにくくなった不満点が解決されたのは喜ぶべきこと。


JavaDocコメント機能も復活してくれー。

2008-05-05

[]Glassfish V3 TP2がバギーホッパーすぎる

NetBeans 6.1でプラグインから自動インストールができるのを思い出したので早速やってみた。

起動時間は非常に早い。0.5秒もかからないようだ。すごい。

その後も遅いかといえばそんなことはなく、デプロイ時間だけを見る限り普通に動いているくさい。

でも、SastrutsCubbyチュートリアルを配備してみたところどちらも動かず。それどころか、フェスタにあわせたネタRPGも動かず。非常に小さいプログラムDWRを使っていることくらいしか特に何もしていないというのに。かなりバグバグなようです。テクノロジープレビューにもなりやしません。

ちなみにCubbyのサンプルはTomcat 6.0.16への配備だとエラーが消えますね。起動時間も早くなりました。SAStrutsTomcatでもGlassfishでも変わらない動きです。起動時間も同じ。CubbyはやはりTomcatへ依存するような動きなのかしら。SAStrutsのほうが安心して使える感じが強いです。

SAStrutsのプロジェクトを開くとNetBeans 6.1ではちゃんとフレームワークとしてStrutsが認識されています。xmlファイル等の設定も右クリックでメニューが出ます。もっともSAStrutsはこの部分を解決するので意味はないですが。

[]NetBeans 6.1 の新機能 その4

バージョン管理が増えている。Mercurialが標準サポートされたようだ。



ただし、Subversionと同じくコマンドラインの自動化程度。CVSのようなネイティブサポートではないのが残念。Subversionもコマンドのままということで各種問題もおそらく改善されていないだろう。

[]ヤッターマンの歌が変わっていた

歌自体は下手になった気がするが、元気のいいタイプなのでこちらのほうがはるかに出来がいい。やっぱりヤッターマンは元気のいいOPでこそだろう。前のがひどすぎたというか。

[][]次期バージョンのRailsActiveRecordが真っ当になるらしい

ActiveRecordってupdateのSQL発行が気に入らなくて、なんでこうなってるんだろうと思ったけれど、とにかく効率は悪くとも実装を軽いものにするという意図があったのかなぁと思っていた。でも結局実装するみたい。


そう考えるとJPAはほどよくよくできていると思う。

updateは変更があったところだけが更新されるし、LAZYはきっちりきくし、関連先をjoinで一気に持ってきたい場合ももちろん対応できるし。

new句を使えばEntity単位以外に好きな項目のみ取得することもできて、メモリ効率や速度にも優れる。複数のテーブルを連結してその中の一部の項目だけを取り出すといったことももちろん可能。もっともnew句がNativeQueryで使えるのが一番いいのだけれども、型が分らないってところだろうね。

そしてツールサポートを期待したつくりになってるおかげでO/Rマッピングはすべて自動で行われる。ユーザーが調整するのは主キーの作成方法くらいだろう。面倒なXMLをいじったりコードをガリガリ書くといったことはない。

ActiveRecordはsaveだけでinsertもupdateもできるのがいいなぁと思ってたけど、TopLinkの実装を見る限りmergeのみで自動的にinsertとupdateが行われるので同等と思ってもいいのかも。それを期待していいとは思いにくいけど。

JPAに限らずほとんどのライブラリは確かに細かい不満はあるけど、本当にそれが必要なのか、回避方法はあるのかがポイントかな。たとえばJPAは高レベルAPIだけれども、ストアドや細かい挙動を使いたい場合データソースをインジェクトすればいいだけだし。

JPAは代替方法があるならそれを使えばいいじゃない、というJavaの思想そのままだと思う。

[]SAStrutsチュートリアルとブランクのweb.xmlの記述ミス

は以前指摘したが、どこに報告するといいのだろう。スキーマロケーションがまずミスってるよね?そこが正しくなるとその他の問題箇所もIDEがはねてくれると思う。

CubbyS2Strutsは正しい。TeedaS2JSFservlet 2.3なのでDTDで問題なし。SaStrutsのみの問題。

とかいておけばとけばそのうち直るだろうか。

[] FileReaderに突っ込むのはまちがっとるきがする

Java における本質的でない記述がどのように大規模開発に役立つのか


>>FileInputStream や InputStreamReader や BufferedReader を組み合わせたコードは、FileReader ひとつだけで済むコードより長く複雑になりますが、それは大規模開発にどう役立ってますか? もし仮に FileReader だけで済むようになった場合、大規模開発にまずい点がありますか?

元々FileReaderはJavaにはありませんでした。それどころかReaderすらありませんでした。なくてもファイルから文字を読み込むことは一応できるからです。バイト単位で取得できますから(元々マルチバイトは考慮されていませんが)。

これはAPIですから、そのAPIがないことによって実現が困難であることのほうを恐れます。重要です。書き方が多少面倒であったとしても実現可能ならばそれはラッパなりを書けばいいだけのことでしょう。

ということで非常に使うことが多いであろうデフォルトエンコーディングを利用した文字列操作が楽になるように1.1で追加されました。FileReaderがそれです。あくまでも簡易用であるということはドキュメントにもそうかいてあります。

文字ファイルを読み込むための簡易クラスです。このクラスのコンストラクタは、デフォルトの文字エンコーディングデフォルトの byte バッファーのサイズが適切に設定されていることを前提としています。これらの値を自分で指定するには、FileInputStream 上に InputStreamReader を構築してください。

あくまでもこれは生APIです。WindowsでいえばWin32APIと同じレベルの話です。

ですから、Swingも素のままのコンポーネントは非常に使いにくいですし、設定が面倒なことがたくさんあります。

ですから既存APIを拡張するのは優先度が高い場合はされるかもしれませんが、シングルバイト圏からみるとデフォルトエンコーディングですらやめようとする動きがあるくらいなので、こういうところはあんまり機能追加されていかないのでしょう。すでに動いているこれだけ膨大なAPIセットに機能を追加するのも大変なことでしょうしね。

APIとしてみればこれだけ機能が豊富ってこと自体がすごいと思いますが。C#Javaの完成度に驚き、人材を引き抜いて急いで作ったわけですが、思想的にはMFCとかDelphiとかJavaAPIより高レベルなものを積極的に取り入れています。


おかげで、Javaの世界はフレームワークライブラリが大量にあると思っています。これを選択の自由と見るべきか、覚えなくてはいけないものがたくさんありすぎると見るかの違いはあるでしょうけど。

2008-05-04

[][]第11回オリゲー・フェスタ☆68

今年もやってきました、オリゲーフェスタ68。ハードウェアが非常に多いのが特徴で、前回はソフトウェアはほとんどないくらいでした。今回は来場者数も出展数もセッションも非常に多く、正直びっくりしました。セッションが多いので細かく回ってみることができなかったのが多少残念でしたが、前回よりさらによくしてやろうという感じがあってかなりよかったと思います。まぁ、午前中からきていればいいだけですが。

注目は

来栖川電工にまさちく氏が復活。

CQ出版で設計した基盤の展示を行っていました。インターフェース付属のFRマイコンは予想通りかなり面白そうなものでした。メインはROMEO2の発表。

このブースで4年ぶりくらいにCQの村上さんとお会いする。あいかわらずお若い…。

つゆさんともお会いする。3年ぶりくらいかな。というか、名乗られるまでまったくわからなかった…。風貌が変わりすぎかと。mkeiさんは最後までつゆさんだとわからず。あの人がつゆさんだよ、といったらかなり驚いていた。わからないのはおいらだけではなかったらしい。


ほかに目に付いたのはMSX Turbo Rのソフト。Rabbit Soft Worker'sというサークルらしい。ゲームの公式ページはこちら。

http://www9.ocn.ne.jp/~rabbits/Contents/Object/HEARTS.htm

Turbo Rというだけでレアなのにアタリマウスも2つというのはかなりレアな環境だった。中身は対戦型ガンシューという感じでキャラごとにCPUアルゴリズムや能力が異なるらしい。コードはBASIC+一部アセンブラBASICでここまで動くのかと衝撃を受けた。Z80ではこうはいかないだろう。大容量メモリを生かしてストレスのないロードも実現している。

今のPCはマウスが前提となっているのでぜひ移植にもトライしてもらいたい。1台での対戦は無理だろうが、そこはネットワーク対応すれば問題はないだろう。


ほかにはえふおうさんが購入されたFCのパッドがつながっているハードが光る。このハード単体でTVにつないでゲームができるという意味では一番完成度が高かったかもしれない。くわしいことはえふおうさんのレビューを待て!


ネタ見せ合戦

でいつもの、えふおうさんとのネタ見せ合戦。なんと今年はmkeiさんも乱入してきました。

mkeiさんはs○n(伏字)にいたことがあったり、○racle(もちろん伏字)で日本法人のトップの技術の現場にいたりと数々の輝かしい経歴の持ち主だけにネタも実用性のあるすばらしいものでした。惜しむらくは前日にsonyタイマー発動、環境のあるvaioを持ってくることができなかったというところ。それでもすごさは十分伝わってきます。

それはなにかというとBASICインタプリタ。自分でちょっとした処理をするときにやはり便利だということでした。また、教育目的やプログラムの取っ掛かりとしてかなり有効だということもおっしゃっていました。やはり、いきなりオブジェクト指向とかクラスとかを覚えるのでは敷居が高すぎますからね。まずは

PRINT 1 + 2
3
OK

とやって、コンピュータってのは計算機のお化けなんだと理解させることが大事だろうということでした。非常に納得。


つぎにえふおうさん。

確か前回はJavaでインベーダーもどきだったと思います。今回はテトリスもどきをJavaで完成させてきたようです。BGMもあったりジョイスティック対応だったりゲームとしてかなり完成されていたと思います。ShinGL3を使っていただいてるのですが、Vistaだとちょっと挙動が変わるようですね。本来ならばライブラリを提供しているこちら側は真っ先にVistaを入手してテストをする必要があるのですが、残念ながらそこまで手が回っていません。

ええ、2日前に購入したマシンはコストと快適さを重視してXPですよ。すべて貧乏が悪いのです。


今回はおいらのネタ仕込み時間がほとんどなくて、かなり中身が薄いのが欠点でした。ネタ度だけは最高に高いですが。去年まではSTGバージョンアップだけを重点的にやってきましたが、今回はShinGLのバージョンアップもなく(PW自体がShinGLのサンプルプログラムである)どんなに作りこんだとしてもインパクトが弱いだろうということで方針転換。

結局AJAXを利用したMMORPGのようなものをもっていきました。インパクトだけならあるはず。バイナリはwarファイル。GlassfishTomcatを起動して配備します。

実行中の画面。


最初はWIZのような3Dダンジョンものでした。開発が容易なことを理由に進めていました。マップはExcelファイル。Poi3.0が非常に安定しているのでそのままExcelファイルを読み込んでマップが生成されるというものでした。

でも、インパクトが非常に弱い。そこで古典的2DRPGのようにしてみたわけですが、キャラクタを大量に作らないといけないので時間がかかってしまった。結果、中身はほとんどない薄いものに。一応ツールはBGToolを思い出したように使う。このツールもほとんど未実装といういいかげんなものだが、単純でもこんなときには約にはたつ。



基本的にDWRを使ったAJAXなもの。キーボード入力をサーバーへ送り、画面の変更がある場合、その画像を取得するというもの。キーボード入力には多少の工夫があるが、その程度で非常に中身はシンプル。あくまでも静止画の生成&転送ということで、各種パケットデータとして送る場合に比べてチートツールを使用される危険性が低い。

各種データはサーバー上のDBに格納するため、調整が容易だ。また、サーバーサイドの技術なのでスケーラビリティ、アベイラビリティに優れる、といったらmkeiさんには大うけした模様。これからはゲームもクラスタの時代だ、とかあほなことをいいました。ネタ度としてはかなりのものでしょう。


最後にmkeiさん、つゆさんのメッセンジャーのアドレス教えますのでよろしかったらメールください。

2008-05-03

[]Cubbyのいいところ

サンプルが容易に動くのがいい。

これ重要なところだと思うんだけど、意外と何でも詰め込むサンプルが多すぎて使い物にならなかったりする。

NetBeansからの配備時間のテストに使ったフレームワークは4つ。その中ですぐ動いたのがCubbyだけだった。

まず、Click、Wicket。この2つはサンプルがすさまじくでかく、また依存ファイルがものすごく多い。Clickのほうは依存するcayenneが2バージョンある用でどうしたらいいのかよくわからん。Wicketはとんでもない数の他のプロダクトに依存していて手作業で構築していくのが絶望的。お話にならなかった。一からプロジェクトを作る場合は問題はないのだろうけどね。

次にSAStruts。これはまずweb.xmlがおかしいので問題が起こる。それらを修正すると起動はしたものの、肝心のサンプルへとぶクリックで例外が出てる感じ。

StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception

java.lang.NullPointerException

at org.apache.jasper.compiler.TagLibraryInfoImpl.toString(TagLibraryInfoImpl.java:111)

at java.lang.String.valueOf(String.java:2827)

at java.lang.StringBuilder.append(StringBuilder.java:115)

at java.util.AbstractMap.toString(AbstractMap.java:490)

at java.lang.String.valueOf(String.java:2827)

at java.lang.StringBuffer.append(StringBuffer.java:219)

at org.seasar.extension.filter.util.RequestDumpUtil.dumpContextAttributes(RequestDumpUtil.java:86)

SAStrutsはおそらくGlassfishは未対応ということなんだろうか。・・・エラー表示されているところがフィルタだけっぽかったのでdumpフィルタを削除したら、そのままGlassfishでも動いたくさい。

ちなみにNetBeansでweb.xmlがおかしいと指摘されたのは3箇所。これらを修正すると一応動くようだ。

修正したのはまずスキーマの設定がおかしい(と思われる)ところを修正。Cubbyのほうからコピーしてきたら動いた。

2つめは必須であるはずの <welcome-file-list>の中が空っぽだという指摘。ここは1つ以上が必須となっている。空にしたい場合 <welcome-file-list>自体を消せばよい。

3つ目は<security-role>の下に<role-name>エレメントが2つあったこと。これは最大で1つしか書くことができないはず。複数書きたい場合は<security-role>自体を複数書くとエラーは消えた。


このときの配備時間はwarファイルで6秒くらい、ディレクトリ配備で2秒くらいといったところ。

hotdeploy使わなくても十分高速だ。当たり前だけど、NetBeansディレクトリ配備(デフォルト)だとhot deployは動く。F9(保存+コンパイル)で即座に反映されるのだが、その後ブラウザを手動で表示するよりF6で再配備をかけて2秒かけるほうが楽な場合もある。10秒以上配備で時間がかかるのならHotDeploy一択なんだろうけど。もっとも再配備だとセッション関係は消えるのでこれらは使い分けたほうがいいのだが。

むかしからNetBeansは伝統的に差分配備するのでさくさく開発するのに向いてたんだよね。


これらサンプルのwarファイルだけを直接配備するならばまず動くので問題にならないのだけれども、あくまでソースを元にwarファイルを作ろうと思うと障害が多すぎた。でもバイナリ動かすだけじゃ勉強にはならんよ。


だが、それはCubbyだけはなかった。すばらしい。SAStrutsはおしい。この辺のライブラリもすべて含めて動くサンプルの親切さはSeasarプロジェクトの特徴・・・だろう。たぶん。

[]後期高齢者医療制度・・・ってその前に養老年金で暮らせるの?

40年すべて支払ったとして毎月6.6万円。後期高齢者医療制度で6000円天引きされるとして、6万円。安いところにすんでたとしても家賃払って水道通信光熱費等はらったら終わりじゃない?

そもそもPSE法にしろ、この制度にしろ公布はかなり前からやってるようだけれども、誰も知らなくて施行直前になってあわてるというパターンはどうにかならんものか。

とりあえず、与党衆議院は体験として月6万で一ヶ月暮らしてもらったほうがいいんじゃないの?ああ、でも法律の原因になった小泉内閣を選んだのは国民だから6000円天引きはしないとして、6.6万支給でいいや。

どーやって暮らすんだろうね。

[][]without JavaEEのほうが重いという衝撃的事実

新しいマシンのスピードをいろいろと試してみたが、そもそも1MB程度のwarファイルのデプロイ持間はCore Duo 1.66GHzでも0〜2秒で終わっているので圧倒的な速度は体感はできなかった。

そこですでに出来上がっている世の中のサンプルコードをデプロイするとどうなるのかをテストしてみた。まずサンプルがわかりやすそうなCubbyをテストモデルに。いろんなところで開発されているだろう独自フレームワークはほぼこの内容と一致するはずだからサンプルとしてはもってこいだ。

サンプルコードそのままではNetBeansディレクトリに展開できないのでsrcとlibを違うフォルダへ移動させて、既存のソースコードからプロジェクトの新規作成を行った。Eclipseプロジェクトを使えるようになるプラグインもあったはずだが、それは使っていない。サンプルはたぶん動いてると思う。起動時にワーニングやエラー(saxパースエラーが出てる)がいくつかでてるけど、動作そのものは問題があるように思えない。


そこで気になったのが起動時間。デプロイそのものは2秒程度で終わってると思う。

だが、そこからアプリケーションが起動するまでが非常に遅いのだ。

新調したマシンでの結果はwar配備で12〜19秒、ディレクトリ配備で11〜17秒となった。これ、旧マシンで起動させたら30秒を余裕で超える大変な起動時間になりそうだ。あまり大規模でないプロジェクトでこの有様ということは実際に業務で扱うプロジェクトではとんでもないことになる。

これだと確かにHot Deploy、Hot Deployというのもうなずける。


たしかにwarベースのservlet以外JavaSEな環境では配備されて実行されてからはじめてコンテナの起動やセットアップを行う。つまり、本来JavaEE環境ならすでに終わっているはずの各種コンテナの初期化等がここから始まるため非常に重いのだ。つまり、DIコンテナ上ですべてセットアップする方法だと毎回アプリケーションサーバーを再起動しているに等しい。

一方JavaEE準拠の開発方法だとコンテナの起動は15秒くらいかかるものの、1度起動したら起動しっぱなしでよい。デプロイにかかる時間はほんの数秒だ。


つまり、JavaEE準拠のほうが開発効率がよいことになる。うーむ、意外だった。それとも、このサンプルは遅くなるような特徴があるのだろうか。一応coolDeployにしてもデプロイ時間は変わらないのは確認済みだが。

2008-05-02

[][]速さは力

その昔そんな広告があったと思ったあなた、30歳超えてますね。

思い立ったら行動は早いので早速デスクトップPCを購入。予定通りCPUはE8400。バスクロックもメモリの速度も2ndキャッシュ容量もビデオも今まで使っていたVAIOのノートPCとは段違いに高速化しているはず。

パーツ変更後変更前
CPUCore 2 Duo /3GHzCore Duo /1.66GHz
2ndキャッシュ6MB2MB
バスクロック1333MHz667MHz
ビデオGeForce8600GeForce7400GO
メモリDDR2/800-2GBDDR2/667-1.5GB
HDD7200RPM5400RPM

アンチウィルスソフト、データベースJDK、NetBeans6.0(お仕事環境のため)、glassfishV2、Firefox、メーラとセットアップ完了。

実際にお仕事で使っているearファイルでアプリケーションサーバー(Grassfish V2UR1)のデプロイの速度を計ってみる。中身はwarファイル*3+ejb-jar*1と比較的ヘビーなものだ。アプリケーションサーバ側もjmsやコネクションプール等設定はしてあるので、素の状態より重いはず。

結果はantの表示時間。もちろん、NetBeansによるいわゆる「主プロジェクトの実行」、つまりF6を押しただけ。

デプロイ時間 ・・・ 6秒!

ぎゃー早い。earファイルのコピーと展開でそのほとんどの時間がとられている感じ。実際に開発するときと同様アンデプロイの時間も含めてこれ。単純にデプロイ単体ならば「4秒」という表示だった。


そこでディレクトリデプロイをしてみる。メモリに余裕があって、生成物の削除と構築をするときにだけアンデプロイをするということを心がけるならば、こちらも使い物になる(Tomcatはつかみっぱなしになってだめだったはず。また、NetBeansデフォはこちら)。


デプロイ時間 ・・・ 3秒!!!

なにこの速さ。メモリも2GBへ増やしたので、Glassfishにメモリを割り当てるようにして、ディレクトリデプロイを本気で考えるというのもありかもしれない。


金で時間を買えるならマシンを買い換えるというのはありだなー。このデスクトップは自作でもなんでもなくてショップブランド。省スペースタイプで価格も8万円台なので、ビデオはいらないとか筐体はあまり小さくなくてもマイクロATX程度でいいやとなるとさらに値段も下がるだろう。

[]ベテランかどうかはあまり関係ないかも

ソースコードがドキュメント足りえないのは訓練していないから

 駆け出しのプログラマは、仕様書トレースしたような(つまり手続き型的な)ソースコードを書きがちです。それは仕様書に忠実ですが、読みやすいソースコードになるとは限りません。下手をするとこれだけでSEなるお化けに彼らはなってしまいます。こうして、SEたちは仕様書至上主義者となっていくわけです。

 いっぽう、ベテランプログラマは、仕様書を一度そしゃくします。そしてわかり易いソースコードになるように再構成するわけです。すると、仕様書というものが空しく見えてきます。SEなるお化けは、仕様書トレースするようなコーディングしか経験していませんので、仕様書を詳しく書くことこそがコーディングさせるのに最良のものと考えます。

ベテランかどうかはあまり関係ないかも。おいらが新人として配属された1年目ですらそういうソースコードにそのまま起こすための仕様なんてものは渡されてなかったし、やりたいことをちゃんと理解させて、コードは自由に書けというスタイルだった。つまり、環境のせい。

そもそもそんな仕様書を書く暇があったらコードが書けるわけで、効率がひたすら悪い。


でも日本語によるプログラム設計書と違い、ソースコードの場合、使用する言語やフレームワークによって大幅に構成は変わってくる。それらをすべて自称SEクンに読ませるのは骨が折れるだろう。そのSEクンは現場によって違う、ありとあらゆる言語やフレームワークを理解してもらわないといけないのだから。


とはいえ、言語やフレームワークにはそれなりにあった使い方というものがあり、日本語で指示されたコードがその流儀に従っていない場合どうしたらいいのだろう。つまり、日本語で書かれたトレースさせるような設計書自体役に立たないことを現してしまう。だからいつまでたっても、コボラーのようなコードといわれるのだろう。


言語によって思想が違うというのはこちらにもあったが珍しくはない。だから、すでに言語を1つ知っていれば一ヶ月もあれば追加の言語をマスターするのは簡単だという人は信用できない。それはうわべを覚えただけでマスターとは程遠いだろう、と。たとえばJavaも最低でも1年、まともに使い物になるには2、3年は要するはずだ。

つまり、言語やフレームワークにあわせた最適な日本語によるトレースさせるようなプログラム設計書は事実上不可能になってしまう。数種類の言語を使い分けることができるころには10年以上を要することになってしまうからだ。


言語を選択するってことはとても大事なことで、会社として新人にどういった言語を勉強させるか、2〜3年後の収穫期(バリバリコードを書けるようになる時期)を考慮しながら教えていかなければならない。3,4年たったのでプログラマからSEへクラスチェンジをしてもらうという会社も多く存在するが、稼げる時期をなくしてしまう理由が個人的にはわからない。プログラマってのは設計もコーディングもするクラスなのだからみんなやればいいじゃない。

新人のOJT用としてトレースしたような設計書を渡すのは、ぜんぜんトレーニングにならないのだからやめたほうがよい。最初からこのプロジェクトの背景にあるものとか、DB選択の理由、こういった設計になったわけなどを教えていけばよい。その辺がしっかりわかっていれば、人のコードを見ながら(できればペアプロがいい)自然と必要になるテストコード等がわかってくるはず。そんな状況で鍛えられた新人ならば1年後には仕様の間違い等もしっかり指摘できる頼れる人材になっているはずだ。


そもそも、日本語からコンピュータ言語へ変換するだけの作業ならば、将来に絶望してこの業界をやめていく人が大量にいそう。夢と希望と不安を持って新卒の内容がこれだったら絶望しか生まれてこないでしょ。できる人ならなおさらというあたりがたちが悪い。モチベーションって大事だよね。

[]初音ミクで自然な歌声

初音ミクの“神調教”が自動でできる「ぼかりす」がニコニコ動画で空前の話題に

これは自然ですなぁ。むしろこれくらいのものが最初から実装されているべきだったと思う。

2008-05-01

[]ヤマダ電機スロットで500ポイント当たった

大宮ロフトにあるジュンク堂Java関連の書籍をちらちら見ていたのだが、Seasar関連書籍が見当たらない。JBOSSやSpringはあるのに。場所を変えてRubyPHPなどがあるほうを見てみたらそこにあった。Javaという文字をどこかに入れないとJava関連書籍のところにおいてくれるのを期待するのは難しいなぁと思った。


以前指摘した「Seasar2によるスーパーアジャイルなWeb開発」もはじめて見つけたので軽く見てみた。どうやら「アプリケーションサーバーの再起動」という誤解を生む表現はこの書籍にかかれてあった。ということは、このレビュー記事はそれを引用したに過ぎないということ。おそらく竹添直樹さんの言葉ではないだろうということで失礼しました。

内容はソースコードの解説はあまりないし、Seasar2の設定の説明もほとんどないということで、これをさくさく読めるのはJavaをしっかり知っていて、Seasar2をすでに触ったことがある人だけだろうと思った。あくまでもSeasarの各種プロダクトの初心者向けであって、新人等にいきなりよませる内容ではないので注意されたし。


JBoss徹底活用ガイド」もみつけたので軽く斜め読みしてみたが、seamはユーザーが非常にほしい機能を貪欲に実装してきたものという感じが強い。だが、機能が豊富すぎてユーザーは追いかけるのに疲れてしまいそう。すべての機能を無理して使う必要はないっぽいのでまずはバイジェクションあたりをとっかかりに、効果が大きく勉強するコストが少ないものをかいつまんでいくとよさげ。

とはいえ、今年中にも策定されるであろうJavaEE 6でかなりの部分が取り込まれる感じがして、seamをすぐに使ってみようという気にならなかった。ダメ人間杉。



帰りに大宮駅のホームで電車を待っていたら蒸気機関車が走っているのを見た。初めて蒸気機関車なるものを見たような気がする。真っ黒いボディに白と黒の煙を撒き散らせて走る姿はちょっとかっこよかった。シュッシュッという音もよかった。その場にいたいろんな人が携帯電話やカメラで写真とってた。


その後ヤマダ電機にふらっと立ち寄り、スロットをまわす。回数は40回以上あるし。そうしたら初めてカスあたり以外が出た。500ポイント当たったのは初めてだ。いつもは購入後20ポイントなのに。

[]お、CPUもパワーアップしてやがった

本日到着! 第2世代の「Eee PC 900」ファーストインプレッション

メモリが1GBに大幅増量、ストレージも8GB追加されて12GBへ、液晶も1024*600と高解像度化と大幅なパワーアップをした新EeePC

この記事でも特に目新しい内容は見受けられない。ただし、CPUのクロックが上がった点を除いて。

CeleronM353搭載ということでパフォーマンスはいいはずなのだが、旧EeePCはクロックを落とされていた。バッテリのもちや小型狂態に治める上での発熱の問題等があったのだろう。それが今回はフルスピードでることに。これならAtomプロセッサと遜色のないパフォーマンスが出るはずだ。

ただ、本来ならばバッテリのもちをよくするためにはCeleronMではなく、PentiumMやIntel Core Soloといった電力コントロールが可能が石を採用するほうがいいはず。ただし、コストも上がるので低価格PCとしてはつらいところ。ターゲットが日本オンリーならばそっちのほうがいいんだろうけどね。

[]ついにこの日が来てしまった

アドビ、「GoLive」の開発、販売を終了し「Dreamweaver」への移行を促す

GoLiveのユーザーではないのでおいらにはこのこと自体は影響はないのだが、FireWorksが生き残れるか興味がある。FreeHandはすでに終了済み。問題はFireWorksは代替肢がないことかな。ドローとペイントの融合をしているソフトはそうそうない。

[]NetBeans 6.1 の新機能 その3


VisualWebJSFで変わった場所がないか調べてみる。

パレットがかわった


単純にbasic(日本語版だと基本)とかいう表記をやめてWoodstockという表記が入るようになった。おかげで標準コンポーネントと間違えにくいので改善点と思って間違いないだろう。


woodstockのバージョンがあがった

おかげで6.0で作ったものを6.1で開いたプロジェクトはもはや6.0では開けない。注意しよう。

追加されたコンポーネントアコーディオンバブルポップアップメニューの3つ。

アコーディオンは動作確認辞退していないのだが、タブは非常に重くて使いにくいのでこれも使わないかもしれない。・・・と思ったけどタブ同様ほしい場面は確かに少ないながらもある。この類は1画面に登録されるコンポーネント数が飛躍的に増える仕組みでもあるので遣い方は注意しないといけない。コンポーネントツリーが肥大化するとPOSTするのに時間がかかるからだ。

ポップアップメニューは使用してみたが、使い物にならないようだ。文字数をポップアップメニューの幅として計算するのだが、全角文字は2文字として数えていないために表示がおかしくなるようだ。つまりいまのところ使い物にならない。

最後にバブル。いわゆる吹き出しを表示するポップアップなのだが、これは待望の新機能だ。クリックしたりマウスオーバー等で表示させることにより直感的なヘルプや詳細情報が可能になる。バブル内はコンポーネントを自由にレイアウトできるので簡易的なダイアログのような使い方も可能だ。

さっそくVisualWebJSFで使ってみる。

・・・どうもそれをサポートする機能が見えない。exampleを見る限り、javascriptのイベントを書かないといけないようだ。しかもコンポーネントのidを指定するために少々面倒なことになる。JSFで表示されるidはそのままhtmlのidにならないためだ。これはレイアウトインスペクタ(CTRL+ALT+コンポーネントをクリック)を起動してidを確認しないといけないことを表す。woodstockサポート機能としては弱いなぁ。せめてJSFコンポーネントを指定したら自動生成してほしいのに。

そしてイベントを書いてみる。こんな感じで。

onMouseOver="document.getElementById('form1:bubble1').open(event);" 

お、こいつ動くぞ!

表示されたのはいいのだが、サンプルにあるようにふきだしのとんがった部分が表示されない。jspを比較しても違いは特に見受けられない。違いといえばstyle指定があるかどうかだ。VisualWebJSFでそのまま貼り付けると絶対座標でstyle指定が自動で入るのでここを削除してみる。

ビンゴ。

どうやら、座標系のスタイルを入れないと、自動的にイベント発生もとのコンポーネントから座標が生成されるようだ。すばらしい。

ただし、IEだと表示がおかしくなるのは直っていない。woodstockコンポーネントIEだと表示が変わってしまうのが非常に多いのだが、IEはサポート外なのだろうか。ユーザー数は一番多そうなのだが。そもそもGlassfishのサイトがIEだと見ることができないのでwoodstock等サブプロジェクトもまったく見ることはできません。


まーわかってしまえばたいしたことはないのだが、もうちょっとなんとかならないのかなぁというのが正直な感想。ただし、かなりバブルヘルプは使える!業務アプリでも一般のアプリでも大活躍するだろう。「?」マークのアイコンでもおいておけばいいのだから。