いつまでたっても覚えられない「COALESCE」の読み方。

社内でも、明確に発音を知っている人がいないようで、話題が出るたびに「コー何とかを使ってさー」となる。結構な頻度で使うし、口にも出すくせに、「コー何とか」である。読めずともDBには通じるし、いっそ「コー何とか」を社内言語にしてしまうのも手かと思ったけど、横着にもほどがあるので調べた。

coalesce

【自動】 合体｛がったい｝する、連合｛れんごう｝する、融合｛ゆうごう｝する
【発音！】ko`uэle's、【＠】コウアレス

via. スペースアルク

ということで、正解は「コウアレス」とのこと。どうか忘れませんように。

flash8 はリリース直後にちょっと触って、あとは最近まで放置したままだった。ということで、今さらながら、ぼちぼち試していくことに。とりあえず、flash8 では Color クラスを使っちゃいけないらしいので、代替の ColorTransform クラスの習得から。ほとんど同じフローで、一安心。

やっぱり猫はかわいいなあ。

続きを読む "flash.geom.ColorTransform"

javascript でも JSP 同様にカスタムタグが使えたら、かなり柔軟なことができるだろうなーと思って試したら、できた。js ファイルを JSP と見なすように設定すれば良いだけの話。

web.xml の jsp-config を以下のように指定すれば、OK。

<jsp-config>
  <jsp-property-group>
    <url-pattern>*.jsp</url-pattern>
    <el-ignored>false</el-ignored>
    <page-encoding>MS932</page-encoding>
    <scripting-invalid>false</scripting-invalid>
  </jsp-property-group>
  <jsp-property-group>
    <url-pattern>*.js</url-pattern>
    <el-ignored>false</el-ignored>
    <page-encoding>MS932</page-encoding>
    <scripting-invalid>false</scripting-invalid>
  </jsp-property-group>
</jsp-config>

ただし、jsファイルもJSP同様にバイトコード化されて実行されるので、負荷は上がる。そして、外部 js ファイルの読み出しだと、request スコープが変わるため、値の取り出しには工夫が必要。ということで、あまりオススメしません。何だそれ。

こんなことするんだったら、カスタムタグを使いたい javascript 関数をまとめた javascript.jsp みたいなのを作って、それを import する方が、賢い気がする。request スコープも同じだし。ああ、そうしよう。

と、ひとり納得して終わる。

またぞろ開発プロジェクトがスタート。過去のプロジェクトを引き継いでの開発なので、とりあえずCVSリポジトリにブランチを作るところから。

これまでCVSの操作は、linux にログインしてダイレクトに行っていた。でも、今回は実験もかねて、Eclipse からやってみようかと。ホントに Eclipse は、何でもできる。便利すぎて怖い。まんじゅう怖い。お茶も怖い。

なお、「CVSって何ですか？」とか「ブランチって何？」という人は、こちらのページが異様に詳しいので、のぞいて圧倒されてみると良いと思います。

以下、Eclipse によるブランチタグ生成のメモ。

続きを読む "Eclipseでブランチタグを作成する"

「Iteratorパターンなんて使わなくても、for文を使えば良いんじゃないの？」

煽りではなく、不意にそう思ってしまった。でも、冷静に考えると、このふたつは等価であるとは限らない。そして、反復処理をそのコレクション型クラス自体に隠蔽することに、大きな意味があるな、と思い直した。危ない、危ない。

List list = new SomeArrayClass();
for (Iterator it = list.iterator(); it.hasNext();) {
    System.out.println(it.next());
}

これを for文 で扱おうとすると、SomeArrayClass が何者かを知らないといけないので、オブジェクト間の関係が密になってしまう。その正体が何なのかを意識しなくて良いのが、iterator の良いところ。極端な例ではあるけど、これなら将来的に SomeArrayClass の内部実装が変わることに耐えられる。

そこに気付いたところで、次なる疑問。じゃあ、拡張for文とは何が違うのか。

List<String> list = new SomeArrayClass<String>();
for (String str : list) {
    System.out.println(str);
}

こう書くと、上のIteratorパターンのサンプルとまったく同じ役割を果たしてくれる。何が違うんだろうと思って探索した結果、どうやら拡張for文は内部で iterator を使っている模様。ああ、そういうことでしたか。

こういうことをキチンと踏まえた上で、敢えてIteratorパターンを用いず、for文で反復制御を書くことに意味があるんだろうなあ。

続きを読む "Iteratorパターンはfor文じゃダメなの？"

クリエイター視点は、新しい技術や表現を求めるし、そういったものを評価する傾向がある。でも、それが一般に効果的かというと、そうとは限らない。ここに溺れると、デンジャラスである。

Ajaxで頑張って画面リロードを無くしても、実はユーザーはリロードなんか気にしていないかもしれない。または、Flash8の機能てんこ盛りでスゴイサイトを作っても、ユーザーは動かないかもしれない。発想が逆で、ユーザーを動かすために新しい技術なり表現を使っていかないといけない。

画面デザインとか機能性といった作り手がこだわりがちな部分とは別のところで、ユーザーは評価をくだす。コンシューマーインサイトを忘れて、クリエイティブな妄想に走らないようにしたいところ。

そういう意味では、既存のありふれたテクニックの隙間や、その単純な組み合わせだけで、効果的なものを作れる可能性も大きいんじゃないかと思う。もちろん新しいことも、ないがしろにしてはいけないけど。

以上、ここ最近の自分の仕事に対する姿勢への反省でした。はい。

MovieClipの現在のRGBをトレースしたら、10進数で表示されるので困る。自分で16進数に直しても良いけど、そのくらいサポートしてるだろうと思って調べたら、ありました。

var trans:Transform = new Transform(mc);
trace(trans.colorTransform.rgb.toString(16));

toString の引数に、構文解析用の基数を指定すればOK。これで2進数から36進数までいけるっぽい。便利。しかし、何で今まで知らなかったのか不思議。

ちなみに、逆に16進数を10進数に変換する場合には、parseInt を使用する。

var string = "FFFF00";
trace(parseInt(string, 16));

こっちはちゃんと知っていた。自分よ、なぜ。

ようやく業務が冷静さを取り戻してきたので、ここぞとばかりに Flash イジリを再開。しかし、SEPY で AS を書くのが、どうもしっくり来ない。しばらく eclipse を使ったあとでは、どうしても SEPY に物足りなさを感じる。

というわけで、未練もなく SEPY にサヨナラを告げ、eclipse で環境を作ることに。今回は、「ん・ぱか工房：ActionScript2.0メモ」を参考に、「eclipse + ASDT + MTASC」の組み合わせで。ああ、この世の中ってスゴイなあ、と思った。

AS3 対応を考えると、eclipse への環境移行は自然な流れだけど、AS3 が正式に出たらば、公式の環境を用意してもらえそうな気もする。だもんで、ちょっと早まった気もするけど、まあ細かいことは気にしない。もう環境できちゃったし。ハハハ。

続きを読む "Flash開発はSEPYからeclipseへ"

NetBeans でプロジェクトを構築しようとしたところ、OutOfMemoryError が出て、構築に失敗してしまった。ソースファイルが2000を超えたら、そりゃ厳しいか。

NetBeans 使用時のヒープサイズは、%NETBEANS_HOME%\etc\netbeans.conf にて設定できる。(%NETBEANS_HOME% は NetBeans のインストールディレクトリ)

# 6行目あたり(実際は1行)
netbeans_default_options="-J-Xms32m -J-Xmx128m -J-XX:PermSize=32m
 -J-XX:MaxPermSize=96m -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true"

今回は単純なメモリ不足が問題だったので、最大ヒープサイズを大きくするため、-J-Xmx を 256m に設定。これで無事、プロジェクトの構築が完了。ふう。

ちなみに、上記の起動オプションについてまとめると以下のとおり。

これまで eclipse で製造していたWebアプリケーションを、Profiler にかけるため、NetBeans に必死で移行。その結果、DataSource でコケる。

javax.servlet.ServletException:
Cannot create JDBC driver of class '' for connect URL 'null'

やっぱり設定をコピペするだけでは、動いてくれないらしい。ううう。

原因は Tomcat にあり。これまで Tomcat5.0 で開発していたのだけれども、NetBeans5.0 にバンドルされていたのは Tomcat5.5 だった。「0.5くらいなら大丈夫だべ」と思って強気で攻めたんだけど、だいぶ違うみたいでして。トム猫さん、頼むよ。

具体的には、JNDI リソースの指定方法が変わった。設定は、<ResourceParams> タグを使わず、<Resource> タグの属性として指定しなければいけなくなったようだ。

以下、設定のサンプル。

続きを読む "Tomcat5.5 で DataSource を使う"

Java のメモリリークを発見するために、NetBeans Profiler を使ってみることにした。JProbe や Borland Optimizeitなどの商用ツールが一般的な、Javaパフォーマンスチューニングツールにあって、なんと無償。試しに使ってみるには良いんじゃないかと。

以下、使用までの流れ。

続きを読む "NetBeans Profiler のインストール"

メモリーリーク。記憶漏れで、あああああ、である。

厳しいスケジュールを乗り越え、ようやく本番稼動まで漕ぎつけたシステムが、今度は java.lang.OutOfMemoryError に見舞われた。試験環境では発生せず、本番になって起こるところが、何ともいじらしい。

原因のひとつは、使用ユーザー数が想定を超えたこと。もうひとつは、セッションに保持する情報が多いこと。…という線で話は収束しているけれども、想定の倍程度のユーザー数がちょっと触っただけでコケるというのは、大げさだろう。負荷テスト足りなかったけどさ。どっかに致命的なメモリーリークがある気がする。

いまだに Java には GC があるからメモリーリークが無いと思っている人がいるけど、そんなことはない。不要になったデータに参照が残っていれば、メモリが開放されず、メモリリークになりうる。たとえばWebアプリケーションでは、Servlet で 非static なクラス変数を使用すると、そのインスタンスは Servletコンテナが参照し続けるため、メモリリークになる可能性がある。

そんなわけで、チマチマと開発メンバの書いたソースを読んでいたら、眠くなってきた。こんなところで春を感じる。ソース量も膨大だし、何かツール使った方が良さそうだなあ。

続きを読む "java におけるメモリーリーク"