エイプリルフールを満喫できる休日はいつ訪れるか

今日は 4 月 1 日です。新年度の始まり、そしてエイプリルフールですね。いろんな人がよってこぞってエイプリルフールネタを投下してくるので、どれが本当の記事かわかりません(苦笑)。

しかし今日はあいにくの平日とあって、エイプリルフールを満喫している人は少なそうです。ましてこれから社会人になる新人さんにとってはエイプリルフールどころでは無いかも知れません。

お祭りごとを存分に楽しむにはやっぱり休日がいいですね ! ということで、そんなエイプリルフールを休日として迎えられるのはいつなのか、調べてみました !

…ってわざわざネタをひねり出したのは、実は先日 id:waman 氏が「2 月のカレンダーが日曜から土曜までにすっぽり収まるのはいつなのか Java Time API に問うてみた」っていう記事を書いていたのを見て、どこかで試したいなぁ、と思っていたのを今頃持ち出してきたわけです。

状況として 4 月 1 日が祝日になることはありませんので、ここでは「土曜日か日曜日である」ことを休日の条件とします(土曜や日曜がお仕事の人、ごめんなさい !)。

指定した日が休日(土・日)かどうか Java Time API で調べる

じゃーん !

2017
2018
2023
2028
2029
2034
2035
2040

直近だと再来年が該当するみたいですね。再来年のエイプリルフールは仕事を忘れて満喫しましょう ! (何)

やっぱり Rails を選択しない 3 つの理由

それでもRailsを選択する3つの理由 - pblog
を読んで、敢えて反論を書いてみたくなった天の邪鬼の戯言と思ってください。

まず反論

業務レベルで Rails の導入を検討した場合、概ね以下のような感じになるんじゃなかろうか。

「規約縛りの哲学」への反論

言語レベルでの規約があることは確かに大きいが、だからといって完全に自由度がないわけでもない。結局は現場レベルのコーディング規約で細かいところは縛らないといけないし、だったらわざわざ Rails に乗り換える必要性は感じられないのではないか ?

「周辺のエコシステム」への反論

OSS に貢献するのは義務なんですか ? OSS に貢献しない人は使っちゃいけないの ? Ruby 界隈が蛇蝎のごとく嫌われる理由がこの辺にある気がします。

「Web の進化への追従」への反論

Web が日々進化していることは動かしようのない事実で、それは誰も異論を挟まないと思う。しかし、Web がいくら進化しても、それを利用する人間まで急激に進化するわけじゃない。自分で作ったものを自分で使うならわかるけど、作る人が「Web は進化してるんだよ ! お前らも追従しろ !」って使う人に言ったところで「いや、俺ら素人だし」ってなると思う。

私が Rails を選択するたった一つの理由

じゃあ「お前は何で Rails を選択したんだ」と問われたら、私は自信を持ってこう答える。

「好きだから。」

それ以上の理由はいらないんじゃないかな。開発に携わる人がみんな Rails が好きで好きで仕方ないという状況なら、そうすればいいと思う。ぶっちゃけると使う側の人からすれば動いてれば何で作られていようがあまり気にしないだろうし。

JPA + EJB + JSF による Web アプリケーション(その 6)

　 ∧,,∧
　(；`・ω・）　　｡･ﾟ･⌒） View 作るよ！！
　/　　 ｏ━ヽニニフ))
　しー-Ｊ

Facelets 群 + α。
MajorCityJavaEE/list.xhtml at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/detail.xhtml at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/index.jsp at master · akaneko3/MajorCityJavaEE · GitHub(ダミー)

ソースコードをいちいち貼り付けるのが面倒なので GitHub のリンクでごまかす。JSF 2.2 用の名前空間を使用している以外は基本的に JSF 2.1 のころとそんなに変わらないです。もちろん JSF 2.2 からの新機能を利用した書き方もあるにはあるんですが。

Sass ファイル群はこちら。
MajorCityJavaEE/common.scss at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/list.scss at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/detail.scss at master · akaneko3/MajorCityJavaEE · GitHub
これ以外のリソースは Compass の初期設定時に作成されているのでいじる必要なし。ファイルを変更して保存すると Builder が勝手に走って Sass ファイル群のコンパイルをしてくれるはず。

Sass といえど基本は CSS なので、Facelets 用の独自のタグがどのような HTML のタグに変換されるのかがわかっていないとなかなか書けない。ここはある意味鬼門。

最後に MajorCityEJB プロジェクトと MajorCityJSF プロジェクトを内包する MajorCityEAR プロジェクトを作成して、これを WildFly に登録してやればよい。

あと、web.xml も filter 用の設定を書き加えておく。
MajorCityJavaEE/web.xml at master · akaneko3/MajorCityJavaEE · GitHub

JPA + EJB + JSF による Web アプリケーション(その 5)

長らくお待たせいたしました。今回は Java のソースコードを書いていきます。

下準備

前回作った JSF のプロジェクトのビルド・パスに、以前に作った EJB のプロジェクトを含めること。これをしないと EJB 側のパッケージを参照できずエラーになります。

管理 Bean の作成

JSF では管理 Bean という Bean を作成します。「管理 Bean って何を管理するの ?」と思うかも知れませんが、英語では Managed Bean、つまり「(JSF によって)管理されている Bean」という意味です。

JPA + EJB + JSF による Web アプリケーション(その 4)

今回は JSF 側のプロジェクトを作っていきます。まずは JSF のプロジェクトを作ります。ファイル構成はこんな感じ。

WebContent/WEB-INF/faces-config.xml や WebContent/lib 内に初期に配置される各種 jar は必要ないので削除します。代わりに WebContent/lib 内に filter-1.0.jar を配置します。これは以下のものを jar にしたものです。
akaneko3/EncodingFilter · GitHub

JPA + EJB + JSF による Web アプリケーション(その 3)

そろそろ現実に帰って Java EE の記事を書きます(汗)。

Model の Entity を JPA で、Business logic を EJB で実装します。JPA は前にも説明した通り永続化と O/R マッピングですが、EJB をことさらに使う理由としては、WildFly (やその他 Java EE アプリケーションサーバ)が EJB コンテナを持っていることにより、アノテーション一発でロジックを呼び出せるという利点があるからです。

以下、ソースコードを書いていきます。ファイルの配置については下図を参照のこと。

jQuery と Sass で FizzBuzz を作ったよ(改良)

前回の記事で作ったものは FizzBuzz をやっているのは実質 jQuery 側、ということで、全部 Sass にやらせるバージョンを作ってみた。

akaneko3/FizzBuzz · GitHub

mixin にデフォルト値付きの引数を持たせている。mixin を呼び出すときに引数を適当に引数を与えることで FizzBuzz の仕様変更やスタイルの変更に対応できる。何より一番嬉しいのは、FizzBuzz の仕様変更に対して Sass だけいじれば対応できること。前回の奴だと jQuery の方も直さないといけないので手間が増える。