昔からJSPでスクリプトレットを禁止するオプションがあればいいのに…と思っていたのですが、JSP 2.0からweb.xmlでスクリプトレットの使用を禁止できるようになっていたんですね。最近知りました。
以下のような感じで、scriptlet-invalidをtrueに設定しておけばいいようです。
<jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <el-ignored>false</el-ignored> <page-encoding>UTF-8</page-encoding> <scripting-invalid>true</scripting-invalid> <include-prelude>/WEB-INF/pages/common/common.jsp</include-prelude> </jsp-property-group> </jsp-config>
JSPを使う場合、この設定は必ず行っておくべきですねぇ。実際はそうも行かないと思いますが…w
RDBMSを使う場合、データ中心にモデリングし、SQLで業務に向けたビューを提供するという手法が一般的です。
で、Google App Engineのようにバックエンドが分散KVS（NoSQL）になる場合、SQLが使えないので、導出値は頑張ってロジックで計算するか、更新時にあらかじめ計算して保存しておく必要があります。
どちらかといえば後者の「更新時にあらかじめ計算して保存しておく」という方法が一般的かと思いますが、この方法を採用する場合、データモデルだけでなく、アプリケーションの機能を最初に洗い出しておく必要があります。また、あとから導出項目を表示項目として追加する場合のインパクトもRDBMSを使う場合と比べると大きくなるように思います。また、そのたびにデータ移行も必要になります。
というわけで、データ中心に設計する場合と比べると事前に決めておかなければならない部分が多く、さらに追加や手戻りのダメージが大きいとなると、そういうデメリットを差し置いてまでスケールアウトすることが必要なアプリケーションでしか分散KVSを使うメリットはないわけです。少なくとも、いわゆる業務アプリケーションの分野ではメリットよりもデメリットのほうがまだかなり上回っているような気がするんですよね…。
CPUとメモリはスケールすると考えると、前者の「都度ロジックで計算する」という方法もあながち間違っているとは言えませんが、それだとCOBOLの時代に逆行しているようなものですし…。
僕の頭が固いだけなのかもしれませんが、実際にGoogle App Engineを使っていて上記のような点について疑問を持っています。このようなデメリットを回避、もしくはパラダイムをシフトするようなうまいやり方があるのでしょうか。
Eclipse上でClojureプログラミングを行うためのプラグインとしてCounterclockwiseというものがあるようです。
もともとはclojure-devという名前だったようですが、改名したようです。それにしてもCounterclockwiseって…。
インストールは以下の更新サイトから行うことができます。
実際に動かしてるところはこんな感じ。
入力補完は動作が重かったり、ときどき返ってこなくなったり（しばらく待ってると返ってくる）など正直微妙ですが、対応するカッコがわかりやすいよう色分け表示してくれたり、エディタ上で選択したS式を評価してくれたりするのはなかなか便利ですね。正直あまり期待はしていなかったのですが、少なくともエディタでコツコツ書くよりは効率がよさそうです。
Clojure本やドキュメントを見ながらいじってみようと思います。
