2009年8月10日月曜日

OGNL

참조
http://starplatina.tistory.com/126?rchid=BR1http%3A%2F%2Fstarplatina.tistory.com%2F126


에서 property 태그는 value의 값을 OGNL로 평가한다.
#표시가 없는 OGNL 표현식 name은 루트 오브젝트의 property이다.
스트럿츠2에서 루트 오브젝트는 value stack이고 value stack 상단에 액션이 있으므로 "name"은 항상 액션의 property가 된다.
JSP EL의 ${name}과 같다.


루트 오브젝트가 아닌 세션 맵의 user를 참조할 때는 위와 같이 "#"을 붙여서 오브젝트 이름과 프라퍼티 또는 맵의 키를 사용해서 참조한다. 루트 오브젝트의 프라퍼티만 프라퍼티 이름만으로 참조 할 수 있다.
JSP EL의 ${sessionScope.user }와 같다.

스트럿츠 2 태그에서 %{...}가 OGNL의 표현식이다. 즉 %{...}내의 텍스트는 OGNL 표현식으로 평가된다.
%{name}이라 하면 문자열 name이 아니고 name을 OGNL 표현식으로 평가한다..
따라서 %{name}은 액션의 name의 프라퍼티 값이 된다.

콜렉션.{ 조작 }

그리고 새로운 콜렉션이 돌려주어진다.{ }안에서는 #this로 현재 요소를 참조할 수 있다.
예를 들면 문자열의 리스트가 있었다고 해서, 각 요소의 뒤에 " ({문자열장})"와 같은 문자열을 부가한 리스트를
작성하고 싶은 경우는 다음과 같이 쓸 수 있다.

list1 의 작성










[]


결과는[aaa (3)] [bb (2)] [ccc (3)] [dd (2)] [eee (3)] [fff (3)]



[]

결과 : [item20][item300]

Struts2의 각종 파일로 이용할 수 있는 OGNL식에서, in구를 사용하면 콜렉션중에서의 요소의 존재를 간단하게 조사할 수 있다JSP의 경우 다음과 같은 리스트가 있었다고 하면
이 결과는item2:[]

item20:[]

item200:[]

이렇게 된다.item2:[false]item20:[true]item200:[false]TIPS:not in도 있다 넘어온 파라메터의 형이 String 타입이면 xxxx.equals("yyyyyy") 로 표현가능

JSON-libでXMLのJSON化

JSON-libでXMLのJSON化
近頃AmazonのAPIで遊んでます。
http://suz-lab.blogspot.com/2008/01/amazon-associates-web-service.html

残念なことに、Amazonからのレスポンスは、
僕の苦手なXMLです。一刻も早くJSONに変換したいところです。

今までは、該当XMLをJavascript側で、
XML.ObjTreeを用いてJSONに変換していましたが、
http://www.kawa.net/works/js/xml/objtree.html
今回は、JSON-libを用いてJava側で変換してみました。
http://json-lib.sourceforge.net/

依存関係も含めて、上記サイトから、
必要なjarを取得&配置すればよいのですが、
XMLまわりの処理では、XOMも必要になります。
http://www.xom.nu/
(サイトのどこかには書いてあるのかなー?見つけられなかった…)

以上のjarが準備できたら、下記のように利用することができます。
--------
String xml ="XMLを文字列かしたもの";
XMLSerializer serializer = new XMLSerializer();
JSON json = serializer.read(xml);
json.toString(); // Stringで出力
--------

いい感じに変換してくれます
ただ、配列まわりの処理が融通ききません。
つまり、


  aaa
  bbb

↓
{root: ["aaa", "bbb"]}


  aaa

↓
{root: "aaa"}

となってしまいます。
{root: ["aaa"]}
となってほしいところですが、
強制的にそうするすべもなさそうです。
(XML.ObjTreeのforce_arrayのようなもの)

なので、今回は、Javascript側で、
object instanceof Array
で条件分岐して対応しました。

こう考えると、XML.ObjTreeの方が使いやすく感じてしまいます。
xmlObjectifier(jQuery)はどうなんだろう?
http://www.terracoder.com/
XPathを使うべきか?
http://coderepos.org/share/wiki/JavaScript-XPath
難しく考えすぎ?

この辺、まだまだ揺れてます。

アノテーションのアノテーション

アノテーションのアノテーション

アノテーションを読み込んでクラスやフィールドなどの情報を管理するという手法が可能になりますが、そのためにメタアノテーションを知る必要があります。 メタアノテーションとは、単純にアノテーションに指定するアノテーションです。

例えば、デフォルトでアノテーションは、クラスやフィールド、メソッドやコンストラクタなど、アノテーションが指定できるあらゆる宣言に記述可能です。 しかし、アノテーションの目的によってはクラスだけに指定して意味のあるものや、メソッドだけに指定して意味のあるものが存在します。 例として、メタアノテーションはアノテーションに指定するためのアノテーションであり、メタアノテーションをクラスに指定することに意味はありません。 こうした問題を解決するための、アノテーションの振る舞いや制限を指定するのがメタアノテーションなのです。

メタアノテーションには、コンパイラが認識することができる標準メタアノテーションと呼ばれるものが用意されています。 この標準メタアノテーションは java.lang.annotation パッケージで宣言されていて、アノテーションの扱いを決定する重要な存在です。

java.lang.annotation.Target アノテーションは、アノテーション型の宣言にのみ利用できるメタアノテーションであり、アノテーションの対象を指定することができます。 Target アノテーションは、シングル・メンバ・アノテーションなので、value() という名前のメソッドを持ちます。

public abstract ElementType[] value

このメンバは ElementType[] 型なので、Target アノテーションは ElementType の配列で初期化されなければなりません。 ElementType 型は java.lang.annotation.ElementType 列挙型で、アノテーションの対象要素を表す定数を提供しています。
定数 解説
ANNOTATION_TYPE アノテーション
CONSTRUCTOR コンストラクタ
FIELD フィールド
LOCAL_VARIABLE ローカル変数
METHOD メソッド
PACKAGE パッケージ
PARAMETER パラメータ
TYPE クラス、インタフェース、または列挙型

アノテーションの対象がクラスなどの型なのであれば、アノテーション宣言で Target アノテーションに ElementType.TYPE を指定すればよいのです。 複数の要素を対象とするには、{ } で囲んで配列の定数として渡します。

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@interface Copyright {
String value();
}

@Copyright("LeonAkasaka") //OK
public class Test {
@Copyright("LeonAkasaka") //エラー
public static void main(String [] args) {
}
}

このプログラムの Copyright アノテーションは、クラス、インタフェース、または列挙型にのみ指定できる ElementType.TYPE を対象に指定しています。 そのため、Test クラスに Copyright を指定することは問題ありませんが、main() メソッドに指定した場合はコンパイルエラーとなります。

Target アノテーションも Target アノテーションで ElementType.ANNOTATION_TYPE を設定されています。 そのため、Target アノテーションはアノテーションにしか指定できません。
アノテーションの配置

アノテーションは、他のツールからプログラムの注釈情報をプログラム的に読み込むことができる重要な機能ですが、プログラムの実行時に影響を及ぼすものではありません。 そのため、アノテーション情報を実行時にメモリに読み込むことが、必ずしも有益になるとは限らないのです。 実行時にクラスが保有する必要の無いアノテーションであれば、コンパイル時に破棄するか、クラスファイルを読み込む時にアノテーションは読み込まないようにするという方法が考えられます。

このように、アノテーションを実行時に VM に読み込ませるかどうかを指定するメタアノテーションが java.lang.annotation.Retention アノテーションです。 Retantion アノテーションはシングル・メンバ・アノテーションです。

public abstract RetentionPolicy value

java.lang.annotation.RetentionPolicy 列挙型は、アノテーションの配置方法を指定する定数が提供されています。
定数 解説
CLASS アノテーションはコンパイラによってクラスファイルに記録されます。しかし、実行時に VM に読み込まれることはありません。
RUNTIME アノテーションはコンパイラによってクラスファイルに記録され、実行時に VM に読み込まれます。
SOURCE アノテーションはコンパイル時によって破棄されます。

デフォルトで、アノテーションは CLASS が指定されています。 アノテーション情報はクラスファイルに記録されますが、実行時に読み込まれることはありません。 そのため、実行時にリフレクション API からアノテーションを取得することはできません。

SOURCE は、コンパイル時にアノテーション情報がソースから破棄されてしまいます。 このタイプのアノテーションは、コンパイラや総合開発環境のソース管理機能などに情報を通知するためのものです。

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface Copyright {
String value();
}

@Copyright("LeonAkasaka")
public class Test {
public static void main(String [] args) {
}
}

このプログラムの Copyright アノテーションは、RetentionPolicy.RUNTIME の Retention メタアノテーションを持ちます。 コンパイラは、Copyright アノテーションをクラスファイルに埋め込み、VM は実行時にアノテーションをメモリにロードするでしょう。 実行時に、リフレクション API を用いてアノテーション情報を得ることができます

2009年8月7日金曜日

s2strutsとsastrutsの違い

■ S2Struts 11:38

Strutsで開発をする場合にActionやActoinFormをコンポーネント化できたり、POJOとして開発できるようになったりというStrutsの拡張フレームワーク的な印象がある。

■ SAStruts 11:38

Strutsのラッパーフレームワークで、Strutsをベースにしているが利用者はStrutsを意識して開発する必要がない。

(MVCフレームワークをより単純化したフレームワーク)

Java版のRuby On Rails


SAStrutsはStrutsをベースにしているが、利用する分にはあまりStrutsを意識する必要はない。

むしろまったく別のフレームワークと思ってもいい気がする。

(でもStrutsの知識があったほうが学習はより早い)

2007年7月9日月曜日

面接のNG例

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001101

1位 応募の理由に疑問を感じた
2位 面接での会話がなり立てない
3位 根拠のない自信過剰
4位 給与・制度・残業ばかり気になる。
5位 前の会社の愚痴、悪口を言う

2007年7月8日日曜日

一テーブルのカラム数について【DBの正規化と非正規化】

引用:http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=26266&forum=26&start=8&12

■ 問題提起
「DBを正規化すると遅くなる」は誤解だそうです。

実体験から感覚的になんとなくそんな気がしていましたが、
実証結果を発表したプロジェクトがあります。

http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
興味を惹かれたので、詳細を見てみました。
http://www.doaplus.com/html/bun03_20051101.html

◎ 反論1

結論ありきの無理やりな実証、というのが素直な感想です。

「非正規化は早いか否か」という問題設定ではなく、早くなるケースもあるということを前提に、どういうケースなら効果を得られるのか・得られないのかというアプローチのほうが良いと思うんですが。

正規化モデルでは性能要件を満たせなくて、非正規化モデルなら満たせる場合だけ非正規化すればよいのです。実際に非正規化する場合は、もちろんプロトタイプとかを用いた実機検証が必要。

そして「非正規化のほうが早い」というだけで非正規化しないことが重要。性能に関する比較を行う場合は、「方式1と方式2を比較」だけではなく、「性能要件と比較」という観点を忘れるべきではありません。

◎ 反論2

私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。

世の中の冗長化が「適切な冗長化」だったらいいんですけど。。

概念分析 → 正規化 → ボトルネックを冗長化 (オブジェクト参照の競合排除)

って手順ならいいわけです

もしくは、DB設計に精通した方が分析からいきなりボトルネック箇所を
冗長化した設計にできるのなら正規化と一緒でもいいかもしれません。

現実は違って、概念分析も行わず画面をそのままテーブルにしたような
元から冗長化されまくった構造を見かけることが非常に多いです。

正規化されてないように見えても、実は正規化されている場合もあります。
例えば、商品マスタと販売系のトランザクションテーブルで重複して商品
データを持っているような場合だと、商品マスタは今後扱っていく商品、
販売側は販売時点のデータ、というような別の意味になったりもします。

冗長化を行う前提として、適切な論理設計が必要なのではないですか?
パフォーマンス目的の冗長化はあくまで物理レベルのチューニングであって、
その元となる正規化された構造が必ずあるはずですから。

とはいえ、列方向への非正規化は問題外じゃないかと。

「DBを正規化すると遅くなる」は誤解,実証実験の結果が公開に

「DBを正規化すると遅くなる」は誤解,実証実験の結果が公開に
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/

データ・モデリングの普及団体,DOA+コンソーシアムはこのほど,リレーショナル・データベース管理システム(RDBMS)の処理性能に関する実証試験を行い,調査結果を公開した。「データを正規化してデータベースに実装すると,処理性能が低下する」という“誤解”を正すため,実証実験を行ったという。

※ 詳細はこちら

http://www.doaplus.com/html/bun03_20051101.html

 データを正規化して実装したときと,非正規化して実装したときの処理性能の違いを調べた結果,「正規化して実装したデータベースの方が処理性能が高い」,「非正規化して実装したデータベースを操作する際,テーブル結合(JOIN)が発生する処理を行うと,処理性能が低くなる」と結論付けた。

 実証実験では,自動車の受注業務を想定したWebシステムを構築して,処理性能を測定した。このWebシステムは,データベース上に格納された受注データを基に,製品データや部品データ,部品メーカのデータなどを検索する。

 データベース実装の違いを調べるため,Webシステムは,(1)データベース上にデータを正規化して実装したものと,(2)非正規化して実装したものの2パターンを用意した。実証実験は,これら2パターンのシステムのデータベースに,受注データ500万件,受注明細データ5000万件などを格納して実験した。

 実証実験の結果,データベース上の単一テーブルを対象に検索した場合,いずれのパターンも2~3ミリ秒で処理を終えた。一方,3つ程度のテーブルにわたりデータを検索した場合,正規化したパターンでは,5000万件のデータを90ミリ秒で検索できた。だが,非正規化したパターンでは,500万件のデータ検索に14秒かかった。

 テーブルを1つだけを検索するときには処理速度に差がつかず,複数テーブルにわたって検索すると処理性能に差が出ている。非正規化されたデータベースの場合,複数テーブルで同じ項目を持つことになる。その項目が検索対象になると,その項目を含め,複数のテーブルから値を集計するようなケースでは,テーブルの結合処理が多く発生するためだ。

 実証実験の参加者のひとり,ウルシステムズの鳥谷部 聡シニアコンサルタントは,実証実験の結果を受けて,「単一テーブルをアクセスする処理時間がほとんど変わらないのであれば,正規化して実装したほうがデータベースの構造を変更することになっても対処しやすい。複数テーブルにわたって検索処理をするときには,非正規化すると処理性能は極端に落ちる。いずれにしても,非正規化するより,正規化して実装するほうが有利だ」と説明する。

 実証実験にはこのほか,NECネクサソリューションズ,住友電気工業,データアーキテクト,PFUの各企業のITエンジニア/コンサルタントが参加した。実験で使用したサーバーは,100万円程度のもの。動作周波数3.6GHzのXeonプロセサを2個,7GBの主記憶,300GBのハードディスクを5個搭載する。サーバーOSにLinux,データベース管理ソフトにPostgreSQL,Webサーバー・ソフトにTomcatを採用した。

マイブログ リスト


Jang ki hote

自己紹介