めざましテレビ

今日の早耳ムスメ木下ココちゃん,お題は「キュート ゴージャス 新作アクセサリー」.

むぅ... お題に「!」が入ってないんですけど.入れるポイントは 2 カ所もあるのにどういうことよ!?
ともあれ (JW),ココちゃん黒のトップスで,いつもと雰囲気が違います.
とっても大人っぽくて女っぽい.新境地? (^^;
でもボトムスはデニムなんだよね.大人っぽいワンピースを着たココちゃんも見てみたいゾ!!
っていうか,六本木ヒルズでロケしてるじゃないですか.
かっくん,朝まで仕事してる場合じゃないよ!! 撮影現場を見に行かないと!!
ちくしょう,鶴見でも収録してくれないかなぁ.無理だよなぁ.
そうですか,おいらも転職してヒルズでお仕事するしかありませんか.
誰か ヒルズ 頼む

Prolog 写経記 その 79 line_type/1

(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.

Prologユーティリティライブラリ

Prologユーティリティライブラリ

今日は line_type/1 を写経します.

解説

line_type(Type) は画面上の行の特性を決める.Typetopbottomnormal あるいは wide のうちの 1 つである.

ふーん.
おらいが使っているのは Windows 版の SWI-Prolog なんですが...
ちゃんと役に立つのでしょうか?
かなり微妙...
(こぴぺ)

モード

line_type(+)

ふむ.

定義

では,こいつの定義を写経しませう.

line_type(Type) :-
	line_code(Type, Code),
	escape(Code).

line_code(top, '#3') :- !.
line_code(bottom, '#4') :- !.
line_code(normal, '#5') :- !.
line_code(wide, '#6') :- !.

昨日の charset/1 なんかにもありましたが,この line_code/2 ってマップ (連想配列とか辞書とかハッシュとか呼ばれるやつ) ですよね.
こういう,ある種データのようなものがプログラムで直接表現されるのってどうなんでしょうね?
これみたいにマッピングが増えたり減ったりしないのはいいけど,実行時に追加されるようなケースではあんまりうれしくない感じ.
きっと Prologer は遠慮無く Prolog データベースへの追加削除をするんだろうけど.
個人的には気持ち悪い気がするのだけど,それを言い出すと (述語として表現される) 事実といわゆるデータの区別が分からなくなって来ちゃいます...

注意

Type は画面上にどのように文字を出力するかを定める.normal は通常の幅 (1 行に 80 文字) で文字を出力し,wide は 2 倍の幅(1 行に 40 文字)である.一方 topbottom は 2 倍の高さと 2 倍の幅の文字を出力するのに用いられる.top で上半分の,bottom で下半分の行を初期化する (下の例参照).選択されたタイプは行全体に有効である.

縦倍・横倍っすか!! 懐かしいなぁ.
でもでも,Windows 版の SWI-Prolog で動くのかは微妙...

では使用例を写経しませう.

write_enlarged(Text) :-
	nl, line_type(top),
	write(Text),
	nl, line_type(bottom),
	write(Text).

例によって述語が掲載されているだけなので,適当に使ってみます.

2 ?- write_enlarged('Yuri').

3Yuri
4Yuri

Yes

ぐはぁっ,普通にダメっぽい.


Prolog 写経記 その 80 screen_background/1

(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.

Prologユーティリティライブラリ

Prologユーティリティライブラリ

続けて screen_background/1 を写経します.少々ヤケ気味.

解説

screen_background(Color) は画面の背景色を選択する.Colordarklight のいずれかである.

ふーん.
おらいが使っているのは Windows 版の SWI-Prolog なんですが...
ちゃんと役に立つのでしょうか?
かなり微妙...
(こぴぺ)

モード

screen_background(+)

ふむ.

定義

では,こいつの定義を写経しませう.

screen_background(Colour) :-
	colour_code(Colour, Code),
	escape(Code).
colour_code(dark, '[?5l') :- !.
colour_code(light, '[?5h').

つまんね.

注意

screen_background(dark) は暗い背景の上に明るい文字を,screen_background(light) は明るい背景の上に暗い文字を表示するよう切り替える.

またまた Windows 版の SWI-Prolog で動くのかは微妙...

では使用例を写経しませう.
...
と思ったけれど使用例がない.(;_;)
まぁ,簡単だから使ってみましょう.

3 ?- screen_background(dark), write('Yuri').
5lYuri

Yes
4 ?- screen_background(light), write('Ebihara').
5hEbihara

Yes

ぐはぁっ,普通にダメっぽい.


Prolog 写経記 その 81 scrolling_mode/1

(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.

Prologユーティリティライブラリ

Prologユーティリティライブラリ

続けて scrolling_mode/1 を写経します.結構ヤケ気味.

解説

scrolling_mode(Mode) は画面上のスクロールモードを選択する.Modejump かあるいは smooth のどちらかである.

ふーん.
おらいが使っているのは Windows 版の SWI-Prolog なんですが...
ちゃんと役に立つのでしょうか?
かなり微妙...
(こぴぺ)

モード

scrolling_mode(+)

ふむ.

定義

では,こいつの定義を写経しませう.

scrolling_mode(Mode) :-
	scroll_code(Mode, Code),
	escape(Code).

scroll_code(jump, '[?4l') :- !.
scroll_code(smooth, '[?4h').

つまんね.

注意

scrolling_mode(jump) は画面上の行を上方にジャンプするように移動させ,scrolling_mode(jump) は連続的でなめらかに移動させる.

ふーん,ダム端でもあまり見た記憶のない指定.
これまた Windows 版の SWI-Prolog で動くのかは微妙...

では使用例を写経しませう.
...
と思ったけれど使用例がない.(;_;)
まぁ,簡単だから使ってみましょう.

5 ?- scrolling_mode(jump).
4l

Yes
6 ?- scrolling_mode(smooth).
4h

Yes

ぐはぁっ,普通にダメっぽい.


Prolog 写経記 その 82 text_attr/1

(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.

Prologユーティリティライブラリ

Prologユーティリティライブラリ

続けて text_attr/1 を写経します.相当ヤケ気味.

解説

text_attr(Attr) は画面上のテキストの属性を選択する.引数の Attr は単一の値か値のリストである.引数が取りうる値は boldunderlineblinkreverse そして normal である.

ふーん.
おらいが使っているのは Windows 版の SWI-Prolog なんですが...
ちゃんと役に立つのでしょうか?
かなり微妙...
(こぴぺ)

モード

text_attr(+)

ふむ.

定義

では,こいつの定義を写経しませう.

text_attr([]) :- !.
text_attr([Attr | Attrs]) :- !,
	text_attr(Attr),
	text_attr(Attrs).
text_attr(Attr) :-
	attr_code(Attr, Code),
	escape(Code, 'm').

attr_code(normal, '0') :- !.
attr_code(bold, '1') :- !.
attr_code(underline, '4') :- !.
attr_code(blink, '5') :- !.
attr_code(reverse, '7').

つまんね.

注意

テキスト属性 normal は,それまでの属性の設定をリセットする.また他の属性と一緒に用いてはならない.そのほかの属性は組み合わせて用いられる.

やっぱり Windows 版の SWI-Prolog で動くのかは微妙...

では使用例を写経しませう.

write_blink_reverse(X) :-
	text_attr([blink, reverse]),
	write(X).

reset_attributes :-
	text_attr(normal).

使ってみませう.

7 ?- write_blink_reverse(hoge).
hoge

Yes
8 ?- reset_attributes.


Yes

ぐはぁっ,やっぱりダメっぽい.


Prolog 写経記 その 83 text/5

(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.

Prologユーティリティライブラリ

Prologユーティリティライブラリ

続けて text/5 を写経します.激しくヤケ気味.

解説

text(Y, X, LineType, Attr, Text) は端末の特性を利用して項 Text を出力する.

ふーん.
おらいが使っているのは Windows 版の SWI-Prolog なんですが...
ちゃんと役に立つのでしょうか?
かなり微妙...
(こぴぺ)

モード

text(+, +, +, +, +)

ふむ.

定義

では,こいつの定義を写経しませう.

text(Y, X, normal, Attr, Text) :-
	cursor(Y, X),
	line_type(normal),
	text_attr(Attr),
	write(Text).
text(Y, X, wide, Attr, Text) :-
	cursor(Y, X),
	line_type(wide),
	text_attr(Attr),
	write(Text).
text(Y, X, high, Attr, Text) :-
	cursor(Y, X),
	line_type(top),
	text_attr(Attr),
	write(Text),
	Y1 is Y + 1,
	cursor(Y1, X),
	line_tye(bottom),
	write(Text), !.

Windows 版 SWI-Prolog ではうまく動かなかった述語がいっぱい...

注意

Y(jump)XText を表示する行と列の数である.Attr はテキストの属性を示す (text_attr/1 参照).LineTypenormalhigh あるいは wide である.highText は行 YY + 1 に表示される.

Windows 版の SWI-Prolog でちゃんと動く可能性は...
微塵もありませんかそうですか.

では使用例を写経しませう.

display_status_line(Status) :-
	text(1, 1, normal, reverse, Status).

使ってみませう.

9 ?- display_status_line(hoge).
1f5hoge

Yes

ぐはぁっ,予想どうりダメっぽい.
そんなわけで (どんなわけで?),「8 章 画面管理終了」.
激しくつまらなかったなぁ...


設定を書きたいのか、書きたくないのか。

ひがさんによる「Seasar2.3にこめたメッセージ」に対する id:da-yoshi さんの反応に反応してみるテスト.

ただ、全てを規約でコントロールしようとすると、逆に開発が規約に縛られるような状況に陥ってしまうのではないかという懸念もあるので、ある程度の範囲にとどめておくべきだとも思います。例えば、トランザクションアスペクト情報を命名規則によって定義するやり方は好きではありません。

ふむ.
好みはね,人それぞれですよね.
でもでも,自分的には

って感じかなぁ.
例に出されているトランザクションについても,アノテーションで指定できてもいいとは思いますが (S2.3 でも EJB3@TransactionAttribute をサポートするかも?),明示的な指定をしなくて済むならそれに越したことはないかな.


多くの場合,トランザクション境界はそんなにきめ細かく設定するものではないと思うんですよね.
例えば CORBA OTS には Transactional Object という概念があります.というか,初期の CORBA OTS にはそのためのマーカインタフェースまでありました (現在は @Deprecated みたいな扱い).
Transactional Object はトランザクション境界の中に生息するオブジェクトで,そのメソッドは全てトランザクショナルな操作ということになります.
そのため,少なくとも CORBA IDL レベルではメソッド単位にこれはトランザクショナル,これは非トランザクショナル,といった指定は出来なかったということになります (暗黙的なトランザクション伝播の場合).
これで不便はなかったかというと,CORBA OTS を実案件で使ったことがないのでよく分からないのですが,おそらく問題ないのではないかと.
なぜなら,一つのクラスがトランザクション境界の中で実行されるべきメソッドと,トランザクション境界で実行してはならないメソッドを併せ持つのは設計がまずい (完全にコンテキストが異なる責務を持たせている) と考えられるから.
効率の問題を考えると,トランザクション境界の中からしか呼び出されないことが分かっているメソッドでトランザクションコンテキストを渡したりチェックしたりするのは避けたいかもしれませんが,CORBA IDL で記述されるのは public つまり外部から呼び出されるインタフェースであって実装クラス固有のメソッドは対象外なので概ね問題なし.
ともあれ (JW),オブジェクト指向トランザクションの経験豊富な連中が作成した仕様である CORBA OTS では,トランザクション境界は非トランザクショナルなオブジェクトとトランザクショナルなオブジェクトの間にあり,トランザクショナルなクラスのメソッドは全てトランザクション境界内で実行されるというシンプルなモデルが考案されていたのです.


このモデルは多くの Web (J2EE) アプリケーションでも有効で,やはりトランザクショナルオブジェクト (トランザクション境界内で使われるクラス) というのはある程度自明なわけです.
いわゆるサービス層とかロジック層とか呼ばれるようなレイヤにあって,プレゼンテーション層などの上位層から呼び出される時にトランザクション境界が設定されるのがよくあるケースではないかと.
こういう,よくあるケースでわざわざ明示的な指定をするのは労力の無駄,あるいはわざわざ墓穴を掘っておくようなものという気のせいがします.


そんなわけで (どんなわけで?),サービス層の境界にある (上位層から呼び出される) クラスは 〜Service ってインタフェースを実装して 〜ServiceImpl って名前を付ける,などの規約で多くの場合は十分だと思う次第.
そして S2.3 の AspectAutoRegisterrequiredTx (EJBREQUIRED 相当) を適用することにすれば,〜Service (を含む) インタフェースで定義されたメソッドに対してのみ,トランザクション境界を設定するアスペクトが適用されます.実装クラス固有のメソッドにはアスペクトは適用されないので効率上も問題ないでしょう.
それに比べて,トランザクショナルなクラス (あるいはメソッド) 全てに対してアノテーションを付けるのは,決して Less Configuration ではないと思います.

3.Annotation。これは今非常にハマって使ってます。

ハマってますねぇ.(^^;
いや,それが悪いとかいうつもりはないですよ.ただなんというか...
「麻疹みたいなもの©太一」
なのかなぁって感じちゃいます.ちょっとやりすぎ感が漂ってるような.
例えていうと,メークに興味を持ち始めたばかりの女の子があまりにも厚化粧しちゃってる,みたいな.(^^;;;
まぁ,誰でも一度は通る (通るべき) 過程なのかもしれませんけど.


典型的なのが 10/19 の「Seasar2.3でEJB3アノテーションを使ってみる」に出てくるコンポーネントの例.

@Components(namespace = "test1")
@Component(name = "client")
public class TestClientImpl implements TestClient {

独自の @Components アノテーションによりコンテナの名前空間を指定することができて,dicon ファイルがスッキリするのは分かります.
が,しかし.
これだと登録する全てのコンポーネントアノテーションを書かないといけないわけですよね.

ちょっとどうかと思うわけです.
もちろん,S2.3 の 〜ComponentAutoRegister と併用してもいいわけですが,それはしばし横へ.
これだと,コンテナの分割など構成を変更したくなったら大変じゃない?
例えばコンポーネントが 100 個登録されているコンテナがあるとして,つまり @Components(namespace = "test1") なんてアノテーションの付いたクラスが 100 個あるとして,それを二つのコンテナに (半々に) 分けようと思ったら,少なくとも 50 個のクラスを修正するのか,と.勘弁して〜.
それよりは,規約を決めて dicon でパターンマッチングする方がずっといいと思っちゃうんですよね.
そもそもコンポーネントがどのコンテナに属するかを知っているのは違和感あるし.


ほとんどの場合,数量的には

  • dicon ファイル <<< (越えられない壁) <<< クラス

となるわけで,少数の dicon をスッキリさせるために大量のクラスにアノテーション付けるのは本末転倒かな,と.
S2.2 以前で dicon ファイルに書いていたコンポーネント固有の情報をアノテーションで書けるようになるだけでは全然うれしくないんですよね.
そのアノテーションも所詮設定情報.dicon に書くのと五十歩百歩.


そんなわけで (どんなわけで?),コンポーネント一つ一つについて dicon を記述するのは避けたいけれど,単にアノテーションに置き換えればいいというものではないと思います.
重要なのはトータルの設定情報を減らすこと.
それには,たくさんあるものは個別に扱うのではなく集合で扱うのが有効.
つまり,規約重要.
S2.3 の場合だと,規約を決めてそれを 〜AutoRegister の設定として表現することで,個別のクラス毎の設定 (アノテーション含む) を無くすのが効果的ってことになるんじゃないかなぁ.
ともあれ (JW),クラスやメソッドに対するアノテーションというのは集合操作ではなく個別操作になりがちなので,決してファーストチョイスではないと思う次第です.


まぁ,アノテーションも使いようでは集合操作的にできるとは思いますけどね.
例えばインタフェースや抽象クラスに付けるアノテーション@Inherited とかもあることだし.
あるいはパッケージに付けるアノテーション.使ったことないけど.
なので,おいらも決してアノテーション撲滅委員会のメンバーということはありません.
でもでも,アノテーション乱用防止委員会のメンバーにはなっちゃうかも? (^^;


最後にまとめ.ひがさんの

設定ファイルを書きたいのか、書きたくないのか。

は,ちょっとだけ言い換えたい.
設定は (XML) ファイルだけではありません.アノテーションも設定です.
つまり,XML だろうがアノテーションだろうが,

設定を書きたいのか、書きたくないのか。

って感じ.このエントリのサブジェクトはこれです.
まぁ,アノテーションJava ソースファイルに記述するんだから設定ファイルでもあるわけですが.


Concurrent Programming in Java (isbn:0321256174)

オレニュでこれが紹介されているけど

Java Concurrency in Practice

Java Concurrency in Practice

  • 作者: Brian Goetz,Tim Peierls,Joshua Bloch,Joseph Bowbeer,David Holmes,Doug Lea
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2006/05/09
  • メディア: ペーパーバック
  • 購入: 7人 クリック: 14回
  • この商品を含むブログ (22件) を見る
当然こっちも要チェック.
Concurrent Programming in Java¿: Design Principles and Patterns (3rd Edition) (Java Series)

Concurrent Programming in Java¿: Design Principles and Patterns (3rd Edition) (Java Series)

定番本の第三版,もちろん Java5 対応に決まってるよね.
今は 5,352 円だけど,おいらが注文したときは 5,240 円.ちょっとだけお得♪
って,発売予定が 2006/05 になってるじゃん...
前に見たときは 2006/02 だった気がするけど??
うーみゅ...

Porto 2 - 0 Inter

(ToT)
まぁ,ココで負けても痛いわけじゃないし...
開幕前から構想が伝えられていた 4-5-1 が試せたのでよかったんじゃないかな.
で,やっぱり Veron と Pizarro の共存はイマイチ?
個人的には 4-4-2 でイイじゃんと思ったり.


出演予定 TV 番組

この近辺 (どこ?) で話題のモデルが出演するテレビ番組を分かるだけ掲載します.
新規分は赤字で (レギュラー除く).直近分は太字で.

山田優
10/22 (土) 12:00〜13:56 CX 「バニラ気分!


CanCam 11 月号 エビちゃんベストセレクション 27

CanCam2005年11月号の蛯原友里ちゃん

CanCam から,お気に入りの蛯原友里ちゃんを紹介しようというこのコーナー.
今日は KOOKAI とのタイアップで「秋の大人カジュアルはロマンティック」から P464 の友里ちゃん.
ちょっとしっとりめ.もしかしたら地味め? (^^;
でもでも,ちょっと憂いのある表情もイイ!!
そんなわけで (どんなわけで?),やっぱり CanCam 買うしか!!