めざましテレビ
今日の早耳ムスメは木下ココちゃん,お題は「キュート ゴージャス 新作アクセサリー」.
むぅ... お題に「!」が入ってないんですけど.入れるポイントは 2 カ所もあるのにどういうことよ!?
ともあれ (JW),ココちゃん黒のトップスで,いつもと雰囲気が違います.
とっても大人っぽくて女っぽい.新境地? (^^;
でもボトムスはデニムなんだよね.大人っぽいワンピースを着たココちゃんも見てみたいゾ!!
っていうか,六本木ヒルズでロケしてるじゃないですか.
かっくん,朝まで仕事してる場合じゃないよ!! 撮影現場を見に行かないと!!
ちくしょう,鶴見でも収録してくれないかなぁ.無理だよなぁ.
そうですか,おいらも転職してヒルズでお仕事するしかありませんか.
誰か ヒルズ 頼む
Prolog 写経記 その 79 line_type/1
(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.
- 作者: ボグダンフィリピッチ,中島誠,伊藤哲郎
- 出版社/メーカー: 海文堂出版
- 発売日: 1990/08
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (68件) を見る
line_type/1
を写経します.解説
line_type(Type)
は画面上の行の特性を決める.Type
はtop
,bottom
,normal
あるいは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 文字)である.一方top
とbottom
は 2 倍の高さと 2 倍の幅の文字を出力するのに用いられる.top
で上半分の,bottom
で下半分の行を初期化する (下の例参照).選択されたタイプは行全体に有効である.
例
では使用例を写経しませう.
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 を写経します.元ネタはこちら.
- 作者: ボグダンフィリピッチ,中島誠,伊藤哲郎
- 出版社/メーカー: 海文堂出版
- 発売日: 1990/08
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (68件) を見る
screen_background/1
を写経します.少々ヤケ気味.解説
screen_background(Color)
は画面の背景色を選択する.Color
はdark
かlight
のいずれかである.
ふーん.
おらいが使っているのは 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)
は明るい背景の上に暗い文字を表示するよう切り替える.
例
では使用例を写経しませう.
...
と思ったけれど使用例がない.(;_;)
まぁ,簡単だから使ってみましょう.
3 ?- screen_background(dark), write('Yuri'). 5lYuri Yes 4 ?- screen_background(light), write('Ebihara'). 5hEbihara Yes
ぐはぁっ,普通にダメっぽい.
Prolog 写経記 その 81 scrolling_mode/1
(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.
- 作者: ボグダンフィリピッチ,中島誠,伊藤哲郎
- 出版社/メーカー: 海文堂出版
- 発売日: 1990/08
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (68件) を見る
scrolling_mode/1
を写経します.結構ヤケ気味.解説
scrolling_mode(Mode)
は画面上のスクロールモードを選択する.Mode
はjump
かあるいは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 を写経します.元ネタはこちら.
- 作者: ボグダンフィリピッチ,中島誠,伊藤哲郎
- 出版社/メーカー: 海文堂出版
- 発売日: 1990/08
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (68件) を見る
text_attr/1
を写経します.相当ヤケ気味.解説
text_attr(Attr)
は画面上のテキストの属性を選択する.引数のAttr
は単一の値か値のリストである.引数が取りうる値はbold
,underline
,blink
,reverse
そして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
は,それまでの属性の設定をリセットする.また他の属性と一緒に用いてはならない.そのほかの属性は組み合わせて用いられる.
Prolog 写経記 その 83 text/5
(ほぼ) 毎日淡々と Prolog を写経します.元ネタはこちら.
- 作者: ボグダンフィリピッチ,中島誠,伊藤哲郎
- 出版社/メーカー: 海文堂出版
- 発売日: 1990/08
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (68件) を見る
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), !.
注意
Y(jump)
とX
はText
を表示する行と列の数である.Attr
はテキストの属性を示す (text_attr/1
参照).LineType
はnormal
,high
あるいはwide
である.high
のText
は行Y
とY + 1
に表示される.
例
では使用例を写経しませう.
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 の AspectAutoRegister
で requiredTx
(EJB の REQUIRED
相当) を適用することにすれば,〜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)
オレニュでこれが紹介されているけど
- 作者: 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)
- 作者: Doug Lea
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2020
- メディア: ペーパーバック
- クリック: 8回
- この商品を含むブログ (2件) を見る
今は 5,352 円だけど,おいらが注文したときは 5,240 円.ちょっとだけお得♪
って,発売予定が 2006/05 になってるじゃん...
前に見たときは 2006/02 だった気がするけど??
うーみゅ...
Porto 2 - 0 Inter
(ToT)
まぁ,ココで負けても痛いわけじゃないし...
開幕前から構想が伝えられていた 4-5-1 が試せたのでよかったんじゃないかな.
で,やっぱり Veron と Pizarro の共存はイマイチ?
個人的には 4-4-2 でイイじゃんと思ったり.