WeBlowg Side

この前に書いたGenericを使ったコードでは、分からない点がつあります。

 public class Variant {
 	public Variant() {
 		Foo<? super MiddleType> foo1_1 = new  SubFoo<MiddleType>();
 		Foo<? super MiddleType> foo1_2 = new  SubFoo<SuperType>();
 		Foo<? extends MiddleType> foo2_1 = new SubFoo<MiddleType>();
 		Foo<? extends MiddleType> foo2_2 = new SubFoo<SubType>();

 		foo1_1.bar(new MiddleType());
 		foo1_1.bar(new SuperType());
 		foo1_2.bar(new MiddleType());
 		foo1_2.bar(new SuperType());

 		foo2_1.bar(new MiddleType());
 		foo2_1.bar(new SubType());
 		foo2_2.bar(new MiddleType());
 		foo2_2.bar(new SubType());
 	}
 }

 class Foo<T> {
 	 void bar(T m) {
 		System.out.println("Foo is called");
 	}
 }
 class SubFoo<T> extends Foo<T> {
 	@Override
 	 void bar(T m) {
 		System.out.println("SubFoo is called");
 	}
 }
 class MiddleType extends SuperType {
 }
 class SuperType {
 }
 class SubType extends MiddleType {
 }

上記のようなコードだと、コメントで示したようにbarメソッドを呼び出すほとんどの所でコンパイルエラーになります。

bar(capture#81 of ? extends MiddleType) in Foo<capture#81 of ? extends MiddleType> cannot be applied to (MiddleType)

この辺りはwildcard captureと言うキーワードがからんでいるようです。
barメソッドをgenericメソッドにすると、コンパイルエラーは解消されます。

<T> void bar(T m)

クラスファイルを逆コンパイルしても、genericメソッドの導入前後で変わりがないんですよね。
型推論ってどういうメカニズムなんだろう。。。。

分からない点は以下の2点。

• 最初の段階のbarメソッド呼び出しでコンパイルエラーが出るものと出ないものがあった。
• gnericメソッドを導入した時点で何が起きているのか。

IBMの記事をじっくり読めば分かるのかもしれないけども、今のところピンとこないんですよね。

コンパイラの気持ちになって、じっくり考えて見ます。

Blogのデザインを変えてみました。
今回、HTMLベースのテンプレートを利用させてもらうことで、Wicketのウリの一つである、プログラムとデザインの分離による分業を擬似体験できました。
テンプレートを利用させてもらったのはこちら。
Styleshout.com

HTMLベースのテンプレートを組み込むのは大変簡単でした。
wicket:idさえ意識すれば、大体テンプレートの組み込みはできてしまいました。
ただ、行毎にスタイルを変えるようなデザイン部分についてはプログラマとデザイナのコミュニケーションが重要になりそうです。
例えば、以下のようなListViewクラス内のpopulateItemメソッドにおいて、CSSのclassを行毎に変えたりする場合です。

 protected void populateItem(final ListItem item) {
     if(item.getIndex() % 2 == 1) {
         item.add(new SimpleAttributeModifier("class", "alt"));
     }
 }

他にもwicket:enclosure等のWicket独自タグを意識する必要がありますが、JSP何かに比べれば大分簡単だと思います。

JavaのGenericの便利さに気づいて以来、Genericの技術はメリット、デメリット共に注目してました。
最近、Wicket1.4のGeneric対応でもめたりしてたのもあって、もう一度Genericについてじっくり勉強してみました。

IBMの以下の記事なんか見てると、ちょうどこの前発見した共変(covariant)って単語が結構出てくる。
http://www.ibm.com/developerworks/jp/java/library/j-jtp04298.html
http://www.ibm.com/developerworks/jp/java/library/j-jtp07018.html

共変(covariant)という単語自体の理解がだいぶ足りなさそうなので、まずはここから攻めてみた。
covariant / contravariant /invariant を調べてると、Wikipedia経由でぶつかったのがこちら。

Say you have a class Foo, which has a method bar(). Method bar() takes an argument of type middle_type, and returns a value of type middle_type.
Now you make a subclass of Foo called SubFoo, and you override bar(). What types can the new bar() take? What types can it return?

 Look at return types first: 
 we want to be able to substitute SubFoo where existing code expects Foo, 
 so it needs to return things of type middle_type, or of some subtype (e.g. sub_type). This should be pretty obvious.

 As for what types our new bar() can take: 

 One answer is: 
 bar() can take only things of type middle_type. 
 You can't declare it to take sub_type, and you can't declare it to take super_type. 
 This is called invariance.

 Another answer: 
 bar() can only be declared to take things that are a subtype of middle_type
   so middle_type is OK, and sub_type is OK, but super_type is out. 
 This is called covariance.

 Finally, the third answer: 
 bar() can only be declared to take things that are a supertype of middle_type
   so any of middle_type, and super_type may be passed to bar(), but sub-type is not allowed. 
 This is called contravariance. 

親クラスFoo, 子クラスSubFoo があって、SubFooがbarメソッドをOverrideしているときに、barメソッドの引数として

• middle_typeしかとれないケースをinvariance
• middle_typeとsub_typeがとれるケースをcovariance
• middle_typeとsuper_typeがとれるケースをcontracovariance

と定義するそうです。

以下のようなコードの場合、

 class Foo<T> {
 	void bar(T m) {
 		System.out.println("Foo is called");
 	}
 }

 class SubFoo<T> extends Foo<T> {

 	@Override
 	void bar(T m) {
 		System.out.println("SubFoo is called");
 	}
 }

インスタンスを生成する時にパラメータタイプとして<? super MiddleType>や<? extends MiddleType>を駆使すればcovarianceやcontravarianceが実現で来そうです。

 Foo<? super MiddleType> foo1_1 = new  SubFoo<MiddleType>();
 Foo<? super MiddleType> foo1_2 = new  SubFoo<SuperType>();
 Foo<? extends MiddleType> foo2_1 = new SubFoo<MiddleType>();
 Foo<? extends MiddleType> foo2_2 = new SubFoo<SubType>();

ただ、このままだとbarメソッドの使い道がいまいち腑に落ちないんですよね。
引き続き調査です。

Wicket社内勉強会2日目も昨日無事終わりました。
参加者には色々質問してもらえ、Wicketに少しでも興味を持ってもらえたようでなによりでした。

さてさて、Wicket In ActionのChapter11を読了しました。
この章は、Ajaxについて説明されています。
標準のAjaxコンポーネントの使い方から、仕組み、カスタムコンポーネントの作り方まで、Ajaxを使う上で必要な知識が網羅されてます。

このBlogもAjaxは全然使ってないですし、他でもAjaxを使う経験がなかったので新鮮でした。
Ajaxコンポーネントの存在は知ってたのですが、AbstractAjaxBehaviorを使うことで、結構簡単にAjaxを体験できるのは驚きでした。

下のコードは単純なLabelコンポーネントにAjaxSelfUpdatingTimerBehaviorを追加してAjax化した例です。
モデルの方で出力する文字列を制御するようにして、0.5秒毎に表示する文字列を切り替えてます。

 public class HelloWicket extends WebPage {
 	public HelloWicket() {
 		Label label = new Label("text", new EmojiModel());
 		add(label);
 		label.add(new AjaxSelfUpdatingTimerBehavior(Duration.seconds(0.5)));
 	}

 	private static class EmojiModel extends AbstractReadOnlyModel {
 		private int count = 0;
 		private String[] emoji = new String[]{
 				"ε=ε=ε=ε＼(*｀∧´)／ ﾑｯｷｰ!!ε=┏(ﾟロﾟ;)┛ﾀﾞﾞｯ!!",
 				"＼(*｀∧´)／ ﾑｯｷｰ!!ε=ε=┏(ﾟロﾟ;)┛ﾀﾞﾀﾞﾞｯ!!",
 				"＼(*｀∧´)／ ﾑｯｷｰ!!ε=ε=ε┏(ﾟロﾟ;)┛ﾀﾞﾀﾀﾞｯ!!",
 				"＼(*｀∧´)／ ﾑｯｷｰ!!ε=ε=ε=ε=┏(ﾟロﾟ;)┛ﾀﾞﾀﾞﾀﾞﾞﾀﾞｯ!!",
 		                "＼(*｀∧´)／ ﾑｯｷｰ!!ε=ε=ε=ε=ε=┏(ﾟロﾟ;)┛ﾀﾞﾀﾞﾀﾞﾀﾞｯ!!"};
		
 		@Override
 		public Object getObject() {
 			if (count >= emoji.length)
 				count = 0;
 			return emoji[count++];
 		}
 	}
 }

Ajax系のコンポーネントはwicket-stuffにも結構あるし、Ajaxをお手軽に体験するという点でもWicketはお薦めですね。
そのうちこのBlogもAjaxをもうちょっと取り入れていこうかと思います。

Wicket in Action Table of Contents
Part 1 Getting started with Wicket
1. What is Wicket?
2. The architecture of Wicket
3. Setting up a Wicket project
4. Building a cheesy Wicket application

Part 2 Getting a basic grip on Wicket
5. Understanding models
6. Using basic components
7. Using forms for data entry
8. Composing your pages

Part 3 Advanced Wicket
9. Creating custom components
10. Working with Wicket resources
11. Rich components and Ajax
12. Authentication and authorization
13. Localization
14. Multi-tiered architecture
15. Putting your application in production
16. Component index

ひょんな事から社内教育を行うことになった。
お題はWicket。
簡単なWicketの紹介をプレゼンして、実際にWicketでアプリを書いてもらうハンズオン形式の社内教育にしました。

レベル的にはあまりWebアプリを知らなくて、Javaはそこそこできる人間が対象でした。
そんなわけで、JavaでのWebアプリケーションの歴史を追う意味でも、Servlet、Struts、Wicket で同じ仕様のアプリをソースレベルで比較、解説してみるってコーナーも設けました。
私自身、Webフレームワークを使わないServletのみの現場と言うのは未経験ですし、
Strutsは経験あるけども、既にWicketで書いたコード量の方が多いぐらいでそんなに分かっていませんでしたので大変勉強になりましたね。

久々StrutsやServletでアプリを書いた経験は貴重でした。
「やっぱ設定ファイルだるいなー」とか、「やっぱJSP嫌いだなー」ってのを再実感できたし、
Servletのみの構成で作ってみると、「Strutsていいなー」とあらためて実感できたり。
技術の進歩をこじんまりと実体験できた気がします。
参加者もその辺を感じ取ってもらえたようです。

講師を引き受けてみて、こういうプレゼンとかセミナーでは一番講師が得している事が実感できました。
やっぱり人に教えるといういい意味でのプレッシャーがあるといいですね。
質問も違う視点での疑問点が聞けて非常にためになる。

Wicketを広めるという点では、JSP嫌いの子がかなり食いついてくれたようで好感触でしたので、ひとまず成功ということで！

この自作BlogソフトはOrg-mode記法を読む事をテーマに開発しました。
そんなOrg-modeの開発者 carsten dominik氏がGoogle TechTalkで行ったプレゼンが公開されています。
http://jp.youtube.com/watch?v=oJTwQvgfgMM

内容についてはOrg-modeの基本的な使い方に終始しています。これからOrg-modeを使ってみようと思う方向けですね。
新発見は少なかったのですが、個人的にはあまり使ってないremember.elとの連携やcolumn viewについても詳しく解説されており、使ってみようかなと思わせる内容でした。
使ってみて便利そうだったら、また紹介しようと思います。

プレゼンでも主張されてますが、テキストベースであるということは、本当に重要だと感じました。
自分のようにOrg-modeで書かれたファイルをバージョン管理して、複数のマシンで編集する場合や、
様々なツールで加工するケースでは、テキストファイルであることは非常に便利です。

公私にわたって大活躍のOrg-mode、ますます発展してほしいですね。

この前Eclipse Europaを試してみたばっかりだったのですが、毎年恒例になったEclipseのバージョンアップが行われたそうです。

Europaではコンソールに出力があった場合は、問答無用でコンソールビューが最前面に表示されていました。
このおかげでWTP(Web Tool Platform)でWebアプリを開発している時に、ソースを変更するとアプリケーションサーバーが再起動してしまい、コンソールビューが最前面にでてしまい非常にうっとうしかったんです。
自分は大体エディタを最大化して作業するんで、これをやられると最悪です。
アプリケーションサーバを再起動しない設定にするって手もあったんですが、このせいでEuropaに乗り換えるのを躊躇してました。
ところが今回のGanymedeでは最前面に表示されるケースをカスタマイズできるようになりました。

あと、リモートのファイルをEclipseで簡単に扱えるPluginが同梱されるようになりました。
まさにEmacsのTrampみたいな機能なんですが、リモートのファイルをローカルファイルみたいに編集できます。
さらにターミナルまでついてるんで、ちょっとした作業なら専用のターミナルソフトを使わなくても実用に耐えれそうです。

というわけでEuropaよりも断然乗り換える意欲が沸くGanymedeでした。お勧めです。

この暑いさなかWii Fitを汗だくになってやってるんで、ちょっと更新が滞ってましたが、Wicket In Action Chapter10読了しました。

この章は、イメージファイルやPDF等のリソースをWicketで扱う方法が書かれています。
自分としてはリソースはあまりわかっていなかったので、大変参考になりました。
業務チックなところでは、CSVの出力なんかにも関わってくるところです。

リソースを扱う方法は大きく分けると以下の3つの方法になります。

• 画像であればImageコンポーネントやResourceLinkコンポーネントを使う方法。
• Applicationクラスで管理するSharedResourceを用いる方法。
• RequestTargetに直接リソースを設定する方法。

試しにこのBlogの横っちょにある「カテゴリ一覧」にImageコンポーネントを使ってアイコンをつけてみました。
「カテゴリ一覧」はListViewを使って実装しています。populateItemメソッド内に以下を追加します。

protected void populateItem(final ListItem categoryItem) {
    categoryItem.add(new Image("icon", new ResourceReference(CategorySummary.class, "icon.png")));

CategorySummaryクラスと同じパッケージ内にicon.pngというファイル名でイメージファイルを置いておけば、イメージが表示されます。
ちなみにHTMLはこんな感じ

<span wicket:id="categorySummaryList" class="categorySummary">
    <img wicket:id="icon" src="icon.png" /> <a href="#" class= "categorySummary" wicket:id="categoryLink"><span wicket:id="category">category</span></a><br />
</span>

この辺りの知識は、リソースを扱うPanel等を作るときには重要になりそうですね。

Wicket in Action Table of Contents
Part 1 Getting started with Wicket
1. What is Wicket?
2. The architecture of Wicket
3. Setting up a Wicket project
4. Building a cheesy Wicket application

Part 2 Getting a basic grip on Wicket
5. Understanding models
6. Using basic components
7. Using forms for data entry
8. Composing your pages

Part 3 Advanced Wicket
9. Creating custom components
10. Working with Wicket resources
11. Rich components and Ajax
12. Authentication and authorization
13. Localization
14. Multi-tiered architecture
15. Putting your application in production
16. Component index

Javaが不憫すぎる ―矢野勉のはてな日記
Javaにはわくわくするところが沢山ある ―凪瀬 Blog

まぁこの人方達には全く及ばない技術力ですが、今まさにわくわくと驚きのの波にもまれまくっている人間からも一言。
他の言語をあんまり知らないんで言語間の比較は出来ないし、主に未知との遭遇というわくわくだけど。

今更ですが、ここ数ヶ月 Java言語仕様をじっくり読むようになりました。
マニュアル類は原典をあたれと言われてきて、英語だろうとその教えをある程度は守ってきたのですが、言語仕様に関しては守れていませんでした。

で、Java言語仕様なんですが、なかなかおもしろい。矢野さんが言われているように目次見ただけでなかなか世界が広がります。
strictfp Classesって知ってました？お恥ずかしながら知らなかったです。
知っている人にはちゃんちゃらおかしいんだろうけど、意外と知らない人も多いような気がします。

どうしたら言語仕様を読む気になるか、それは一つの言語にこだわってみるのも手だと思います。
いろんな形態でこの業界に関わっている人がいるんだろうけど、まずは一つの言語にこだわった働き方をするというのはどうでしょう。
自分は様々なプロジェクトを転々とするような働き方をしているけども、一つの言語にこだわらせてもらえた。(自分の場合はそれがたまたまJavaだった)
あまりにいろんな言語をちょこちょこやらされると、言語仕様まで読もうという気にならないと思う。

今現在Javaに関わっていて、わくわくが感じられないなら以下の2冊をお薦めします。
私自身も仕事でJavaを使っていた初期の頃はあまりJavaの良さを感じれなかったけど、以下の2冊に出会って認識が変わりました。

• Javaの格言―より良いオブジェクト設計のためのパターンと定石
• リファクタリング―プログラムの体質改善テクニック

オブジェクト指向というのもわくわくを与えてくれたもののひとつです。
Wicketと出会ってこの楽しみはさらに増してます。というわけで今更ながらWicketお薦めですよ。

娘が風邪でてんやわんやの中、飛ばしてたChapter8をやっと読了。

この章はコンポーネントのグループ化とページレイアウトについての説明になります。
コンポーネントのグループ化では、Panel, WebMarkupContainer, Fragment、ページのレイアウトについては、Panel, wicket:extend のそれぞれについて具体的な例が示されて大変わかりやすいです。
個人的にはそんなに新しい知識はなかったのですが、 Wicket を初めて知ったときに wicket:extend でページが継承できるとしって感動した事を思い出しました。
このおもしろさはなかなか他のフレームワークでは味わえないんじゃないでしょうか？

さてさて、この章で興味深かったのはページのレイアウトをPanelで構成するかwicket:extendで構成するかを考察している部分でした。
Wicketで作ったこのBlogもそうだけど、基本的には wicket:extend で構成してます。
個人的にはページのヘッダ部やメニューバー等を構成するにあたってはPanelよりwicket:extendが好みです。
一つのWebページクラスでリンクの押下をトリガにメインコンテンツ部のPanelを切り替える方法もありますが、制御が複雑になるために本著でも切り替えは2つのPanelまでだろうと述べられています。
また、複数WebページクラスにPanelを追加していくにしても、結局Panelインスタンスをaddするコードが複数箇所にあらわれちゃうんですよね。
抽象化した部品を構成するにはPanelは威力を発揮するでしょうが、ページを構成するにはむいてないんじゃないかなぁと思ってます。

Wicket in Action Table of Contents
Part 1 Getting started with Wicket
1. What is Wicket?
2. The architecture of Wicket
3. Setting up a Wicket project
4. Building a cheesy Wicket application

Part 2 Getting a basic grip on Wicket
5. Understanding models
6. Using basic components
7. Using forms for data entry
8. Composing your pages

Part 3 Advanced Wicket
9. Creating custom components
10. Working with Wicket resources
11. Rich components and Ajax
12. Authentication and authorization
13. Localization
14. Multi-tiered architecture
15. Putting your application in production
16. Component index