マウスカーソルがデフォルトボタンに移動するのがウザい
AppearanceのUI Optionsにある「Automatically position mouse cursor on default button」をOFFにすればOK.
余計な改行を除去したい
放っておくと埋もれちゃうのですくい上げておきます。
Code Styleの言語別設定の「Wrapping and Braces」にある「Keep when reformatting / Line breaks」の事。
Java Meeting Sendai 2014 〜秋のてらだよしおまつり〜 に行ってきた
当時のつぶやきはtogetterにまとめておきました。
併催イベント、その後の懇親会含めて、ひさしぶりに楽しめました。寺田さん、櫻庭さん、スタッフのみなさん、および当日参加された方々おつかれさまでした＆ありがとうございました。
JavaEE関連で、ちょいと補足しときたいことも無きにしもあらずだけど、検証する環境が手元にないので、またあとで。
なぜ、テキストエディタじゃなくてIntelliJ IDEAを使うか
→ http://samuraism.jp/diary/2014/07/21/1405945860000.html
ネタエントリです。私はテキストエディタで済むのはテキストエディタを使います。もっぱら使うのは香り屋版gVim（Windows）で、自宅ではMacVimだったのにOS X 10.9.4にしてから調子悪くなったのでSublime Textに浮気中。ええ、そうです。Vim指に呪われています。
1.Mac, Linux, Windowsのどれでも使える
Javaアプリですからね。インストールのしやすさはどれも同じだけれど、無事に初期起動できるかどうかで、これくらいの差があるんじゃないかな。
Windows >> Linux >>(越えられない壁)>> Mac
MacやLinuxは起動用のJREが付いてない。Macはさらに初期設定でJava6を要求するとかで、地味にハードル上げてます（別にJava7でも動く）。あとプロジェクト用のJDKも付いてないので、はじめに設定しないとJavaプロジェクト作るのにも一苦労です。
2.起動が速い
どうゆう理由かわかりませんが、その日の初回起動は普通に遅いです。インデックスの再構築がとってもCPUパワーを食いつぶすので、コア数多ければ多いほど起動は速いです。インデックスの有効期間なのかキャッシュなのか、わかんないけど、それを乗り越えると起動は早くなります。
なので、他のIDEと比べて格段にちょ早って感じはしないです。隣の芝生は青く見えるものです。
3.キーマッピングが自由自在
Macはもともとのいろんなショートカットが割り当てられているので、その辺の知識が無いとキーカスタマイズするのも一苦労です。キーカスタマイズのしやすさは、こんな感じ（Linuxは風評。
Windows >>(越えられない壁）>> Linux > Mac
4.他のテキストエディタやテキストエディタに比べて、カーソルが速く移動できる
これは慣れの問題かな。昔は Goto -> Class とかIntelliJならではだったけど、今だと別に珍しくも何ともない。
6.検索、置換が強力(変態)
これは本当。ただ、検索／置換メニューがメニューバーの「Edit → Find」と奥まってるので、どこにあるのか慣れるまで戸惑う。
あと、IDEA13.1から追加されたマルチカーソルが地味に便利。
7.Postfix completionという機能が便利過ぎる
そうなんだけど、忘れる。覚えたら便利なんだろうなって感じ。
8.英語ドキュメントやヘルプが豊富
書籍の類いはとほんど無いので、インターネットの海を探そう。
9.日本のIntelliJ IDEAコミュニティがやばい
あたしがレスするのは、もはや嫌がらせのレベル。
ちなみに「IdeaVIM」ってつぶやくと、それが何語だろうとIdeaVIMのコミッタからレスが来るので気をつけろｗ
10.ある意味マルチプラットフォームなIntelliJというプラットフォーム
パーソナルライセンスだったら、どのPCに入れてても良いってのもよかね。
11.設定ファイルを読む必要はない
そのかわり検索ワードは英語だし、ある程度あたりが付いてないと、いくらそれっぽいワードを入れてもヒットしないよ。
12.他言語サポート
Ultimate EditionはAppCode以外に相当するので、たしかにUltimateなんだけど、PHPやRubyなどの多言語プラグインの追従性とか知ってないと「思ってたんとちゃう」って事になるので、これも注意が必要だ。
13.UIがどんどん改善されていく
UIはね、だいぶ主観がはいるから。EclipseのSWTがイケてるとか、Visual Studioの見た目がサイコーだとか、人によってさまざま。確実に言えることは、
ってあたり。
終わり。
万能軽快快適IDEなんてあるわけないけど、その辺のダメなところを分かった上で「やっぱりIntelliJ最高だ！」と言っているので、共感できる人は共に行こう！だし、単にあこがれているなら、悪い面もちゃんと知っとこうね、というネタのようなホントの話。
JSF2.2試してみた - 管理ビーンの模索
前回とちょっと間があいたけど、その続き。今度は管理ビーンのあり方についての模索、というか悪あがき。
素直にlombok使えばいいのだけれど、どうしても getter/setter だらけになるのはイヤなので、なんか回避する方法は無いものかと模索した結果がこれ。
@Named @ViewScoped public class CalcCtrl implements Serializable { : public void doCalculation() { long l = Long.parseLong(requestMap("left").toString()); long r = Long.parseLong(requestMap("right").toString()); long a = l + r; if (l % 2 == 0) flash("left", "左辺 " + l + " は偶数です"); if (r % 2 != 0) flash("right", "右辺 " + r + " は奇数です"); List<Calc> results = (List<Calc>) viewMap("results"); results.add(0, new Calc(l, r, a)); reset(); } : }
ちゃんとしたソースコードはここ。
→ JSFSample/CalcCtrl.java at master · masanobuimai/JSFSample · GitHub
何がしたかったかというと、Grailsや（最近は知らないけど）RailsみたくViewに渡す値をコントローラのメンバ変数に持たすのではなく、リクエストに紛れ込ませてみた。それを取り出すView側のコードはこんな感じ。
<h:inputText id="left" label="左辺" value="#{requestScope.left}" style="#{faceUtils.valid(component.clientId)}" required="true"> <f:validateLongRange maximum="99999"/> </h:inputText> : <h:dataTable value="#{viewScope.results}" var="calc"> <h:column> <h:outputText value="#{calc.left}"/> + <h:outputText value="#{calc.right}"/> = <h:outputText value="#{calc.answer}"/> </h:column> </h:dataTable>
入力値（左辺・右辺）の受け取り方がJavaBeans（Calc)経由ではなく、リクエスト（requestMap("left" or "right")）経由でString型の取り出しになるため、そのままだと型チェックが効かない。なんでまぁ、苦肉の策として範囲チェック（validateLongRange）をあてて型チェックも兼ねさせる。
やってみて一応できたけど「こりゃイケる」という感慨はなかった。むしろJSFとしてはかなりトリッキーな組み方になるんで、こんなの広めても良いこと何も無いなと思うのであった。
別の見方をすると「JSF、柔軟性ありすぎや」とも言える。この話はもちょっと続くのだけれど、今回はこれでおしまい。
