May 17, 2010
icu4j で和暦の parse
何回かやってるんだけど、忘れてしまうのでメモ。
IBM の国際化ライブラリ ICU のは、数値や通貨やカレンダーの国際化に役立つライブラリ。Java 用には icu4j がある。博物館のデータではあちこちに和暦が登場するのだけれど、西暦に変換したいこともよくある。で、Java SE 6 では JapaneseCalendar で元号がサポートされたとはいえ、明治以降だけなので全然使えません。というわけで、icu4j を使って日本の元号で書かれた年代を西暦（グレゴリオ暦）の普通の日付に変換するコード。
JapaneseCalendar jcal = new JapaneseCalendar();
DateFormatSymbols dfs = new DateFormatSymbols(jcal, Locale.JAPANESE);
DateFormat sdf = new SimpleDateFormat("Gy年M月d日", dfs);
sdf.setCalendar(jcal);
Date date = sdf.parse("天保11年1月1日");
System.out.println(date);
結果は、
Wed Jan 01 00:00:00 JST 1840
と。ただこれ、元号だけでいわゆる旧暦（太陰太陽暦）のことは、というかつまり月日までは考えてません。自分の仕事ではそこはあまり問題になることがないので…。
投稿者 ryoji : 05:30 PM | トラックバック
January 28, 2006
Greasemonky の練習 (Amazlet ツール)
FireFox も 1.5 バージョンアップしたことだし、Greasemonky で遊んでみよう、というわけで。
Amazlet ツール を使っているのですが、リンクテキストをコピペするのがおっくうで (IE じゃないので「コピー」ボタンも使えない) 、テキストエリアを1回クリックしたらテキストが選択状態になるように Greasemonky スクリプトを書いてみました。
amazletselect.user.js
いやまぁ、textarea の onfocus に this.select() を設定してるだけです。モロに Greasemonky で書いてみたかっただけって感じですが。でも面白いですねー。
投稿者 ryoji : 10:57 PM | トラックバック
December 04, 2005
美術情報とプログラミング
どのような勉強をすればプログラミングができるようになるのですかという質問に、「 プログラミングが「できない→できる」へデジタル的に変化するのではない。しだいにできるようになっていく。」と答えてるのを見て、うまいなぁと。僕もたまに聞かれるんですが、こう答えるのはいいですね。
最近よく思うのは、僕が関わってるような美術情報の分野(と言えるほど人はいないのですが)で、プログラミングのできる人が増えてほしいなぁということ。ま、そもそも関心を持ってる人が少ないので、とにかくまず多くの人に興味を持ってもらうことが大事なんですけど。でも一方で、時々若い人で博物館・美術館の情報化に興味があるという人に出会うのですが、プログラミングができるという人はほとんどいないんですよね。僕の場合、自分でコードが書けるからこういう研究をやりはじめたというところがかなりあるので、そういう僕からするとちょっと意外なんですけれど。
もちろん実際に何かシステムを作るというときに自分自身でゴリゴリとコードを書く必要があるわけではなくて、まあだいたい業者さんと仕様を決めて発注してって感じなんでしょうけれど。でも、うーん、プログラミングをするのとしないのとでは、全然世界が違うというのが実感としてすごくあるので、やっぱりそういう人達にはプログラミングの勉強をしてほしい、とつい思ってしまいます。それはもう、デッサンの訓練をする前と後くらい違うし、あるいは英語を読めるのと読めないのとくらい違うという感じです。文系だからとか言わず(僕だって文系だし)、ちょっとかじってみてほしいです。算数苦手でも平気ですから(笑)。
それに、自分でコードを書けないと、思いついたアイデアを軽く試してみるっていうのがすごく大変だと思うんですよね。身近に協力してくれるプログラマがいればそういう人に頼めるかもしれないけど。そうでないと、何かしらの形で予算を獲得して発注して…とせざるを得ないですよね。それかアイデアだけをとりあえず論文にして、誰かがたまたまやってみてくれるのを待つとか？ でも自分でコードが書ければ、思いついたことをちょっとハックしてみるとかいうことが可能です(もちろんアイデアの内容によりますが)。僕としては、美術情報のような蓄積の少ない分野では、実際に手を動かしていかないと先に進んでいけないと思うのです。どうせ読むべき文献なんかちょっとしかないんだし。作ってみないと何もわからないんじゃないかと。だったら自分で作れるのが一番いいと思います。
というわけで、美術情報に関心のある若い人には、是非プログラミングの勉強をしてほしいです。
投稿者 ryoji : 05:19 PM | トラックバック
September 07, 2005
Hibernate でバッチ処理、と composite-element と Criteria
しばらく Java ばっかり使ってるので、だいぶ慣れてきた感じです。でも log4j とかあまりちゃんと使えてないですが…。ま、それはそれとして Hibernate でまた半日くらいハマったのでメモ。
データ移行などで大量のデータを一気に insert, update したりすると、自分の場合では 3000 件ちょいくらいで Out of Memory Exception が発生。え? ひょっとしてメモリリーク? 自分のソースの中を探してもそれらしきコードは見つからず、10万件以上あるのにどうすんのよこれ…とビビりましたが、正解はいつものとおり「マニュアル読め」。Google とか Hibernate Forum で検索する前にマニュアルをちゃんと見るのが正しい、というのは頭ではわかってるんですが、なかなか習慣として身につきません。うぅ。
で、Chapter 14. Batch processing によると、バッチ処理するならとりあえず
hibernate.jdbc.batch_size 20
とかしておくとマトモなパフォーマンスが出るよ、とのこと。確かに妙に遅いなーと思ってたんですが、20倍くらい早くなりました。知らなかったら何日も無駄にしてたかも。あわわ。で、メモリの問題は Hibernate のキャッシュが溜まってしまうのが原因らしく、
hibernate.cache.use_second_level_cache false
と。そして first-level cache もクリアするために、 session.flush() のあとに session.clear() を入れておく。これで問題解決でした。
ついでにもう一つ。Hibernate Forum のこのスレッドによると、
Querying collections of value type is not supported in the Criteria API. Use HQL, or change your mapping to make the composite element class an entity class.
だそうで、composite-element を Criteria で使えないってことみたい。エエー!? どうしよ、あてにしてたのに…。
投稿者 ryoji : 10:21 AM | トラックバック
August 23, 2005
kichijoji
post to blog via flickr
ってやってみたんですが、ズレた…。
測地系が Tokyo になっちょる。携帯で地図を確認して修正したら Tokyo にかわっちゃうのかなぁ。
うぅ、確認して計算してやんないとダメかしらん。
修正。正しい。測地系が TOKYO のときには WGS-84 に変換するように。
なんだかいったりきたり無駄な気が…。
投稿者 ryoji : 08:44 PM | トラックバック
August 18, 2005
Hibernate の composite-element を使うときは equals() と hashCode() をオーバーライドする
という必要があるのに気づくまで、ちょっとハマったのでメモ。
Hibernate でコンポーネントのコレクションへのマッピングをするとき、つまりあるクラスのメンバに Set などのコレクションがあって、その中身が特定の値型のとき、composite-element を使います。そのとき、コレクションの中身になるクラスでは equals() と hashCode() をオーバーライドしないといけない、という話。
クラスが、
public class Group {
private Integer id;
private String groupName;
private Set members = new HashSet(); // 中身は Person
....
}
public class Person {
private String name;
private Integer age;
....
}
みたいなとき、マッピングファイルは、
<hibernate-mapping>
<class name="Group" table="group">
<id name="id">
<generator class="identity"/>
</id>
<property name="groupName" column="group_name"/>
<set name="members" table="members">
<key column="id"/>
<composite-element class="Person">
<property name="name"/>
<property name="age"/>
</composite-element>
</set>
</class>
</hibernate-mapping>
てな感じになるわけですが、ここで、Person に equals() と hashCode() を実装しておかないとですね、例えば Group に member を追加するときに、members テーブルに対して大量に insert と delete を発行してしまったり、わけわかんないことになります。まあよく考えてみれば確かにそうなるかも、というところですが、ドキュメントにも、
Note: if you define a Set of composite elements, it is very important to implement equals() and hashCode() correctly.
とか書いてあるので、注意が必要です。バッチリ見落としてましたよ。よく参考にしてるHibernate 入門記のエントリでも、
こいつは値型なので本来は hashCode() と equals(Object) をオーバーライドすべきですが，手抜きしてます．心より恥じる．とあったのですが、これも見落としてました。いかんいかん。
投稿者 ryoji : 10:47 AM | トラックバック
July 23, 2005
JavaScript って入門以後に勉強する手段が少ない
Web 2.0 とか言われて Ajax も流行ってインターフェースの実装に JavaScript が結構本気で使われることが増えていると思いますが、資料がイマイチ充実してないように思います。書籍だと言語としての JavaScript をきちんと扱ってるのは O'reilly の 『JavaScript』 くらいではないでしょうか。書店で立ち読みとかしたかぎりでは、JavaScript の本は今だにほとんどがド素人向けという感じがします。「時間帯ごとに表示する挨拶を変える」とか、アホかと思う。Web 上に数多あるリファレンスの類いも、その多くはあまり違わないと思います。変に対話形式になってたり、説明が冗長すぎたりして読んでられません。あと内容が古い。上の O'reilly のサイ本もちょっともうさすがに古いので、新しい版を期待しているのですが。言語そのもののしっかりした解説書がほしいのは、、例えばイベントハンドラにセットするメソッドには引数が渡せないけどグローバル変数は使うべきでない、というような状況で、そうだクロージャがあるじゃないか、とか思いつけるようにしておくため。ついでに Venkman JavaScript Debugger とか DOM Inspector とかの使い方もつけておけば、案外売れるんじゃないかなぁ。
あとは以前にも紹介した 『JavaScript & DHTMLクックブック』 が使える素敵な本ですね。でも結局 O'Reilly かよ。クックブックだけでは作業できないので、いいリファレンスが欲しいです。僕も辞典的な本を一つ使っていますが、使いやすいのが本当に少ないですね。特に DOM の扱いが全体的に弱いのと、索引が貧弱。
で、ちょっと応用的なことをやろうとしたら、今一番役に立ってるのは様々な Blog の個別のエントリだったりします。Blog だとどうしてもバラバラな話になってしまうのですが、Blog 以外で多少ともまとまってるのだと、
あたりが勉強になりました。まぁ CSS + JavaScript でリッチなインターフェース、というのは基本的にはバッドノウハウまみれではあるのですが。
投稿者 ryoji : 07:50 AM | トラックバック
May 26, 2005
Hibernate の Criteria で count
ものは試しということで、java の O/R mapper Hibernate を試してます。で、検索クエリを動的に組み立てるのに超便利な（気がする） Criteria を使ってるときに、こいつで組み立てた検索条件の検索結果の数を知りたい。つまり SELECT COUNT(*) FROM ... がしたい、と。Hibernate 2 まではどうもできなかったっぽいんですが（ちゃんとは調べてないです）、Hibernate 3 ではできるようになってます。で、この話、Google で日本語で「Hibernate Criteria count」とかしても「できないっぽい」「できません」「HQL使っとけ」てな話ばかりで（3.0が出たばかりだから?）、僕もあやうく諦めるところだったので、ここに「できますよー」と書いときます。
やり方はリファレンス・ドキュメントの 16.7. Projections, aggregation and grouping をどうぞ。うーむ、ちゃんとドキュメント読めってことですね…。でもざっと探してるときに「Projection」なんて言葉じゃ気がつかないよなぁ。
で、検索結果を表示してかつ引っかかった数も出したい、でも同じ条件を2度組み立てるのは嫌だから Criteria をコピーできないかな? と思うのが人情です。実際にはコピーする必要はなくて、setProjection(null) で Projection をクリアして再利用すればいい、と。という話はこのあたり。
そんなわけで、
Criteria crit = session.createCriteria(Hoge.class);
crit.add(Restrictions.like("name", "%"+name+"%"));
Integer rowCount = (Integer)crit.setProjection(Projections.rowCount()).uniqueResult();
crit.setProjection(null);
crit.setResultTransformer(Criteria.ROOT_ENTITY);
crit.setMaxResults(20);
List list = crit.list();という感じ。のはず。
投稿者 ryoji : 05:32 PM | コメント (1) | トラックバック
May 11, 2005
るびま: 江渡浩一郎さんインタビュー
Rubyist Magazine の江渡浩一郎さんインタビュー（前半）の最後の部分、「Art と Programming」が面白かったです。
プログラミングとアートって、言葉のレイヤーとしては違いまくるよね。なんだろうな。ささださんが質問者じゃないから想像して答えるしかないんだけど、「めちゃくちゃ関係あるんじゃないんですか」。
ハックとアートは似てると言わざるを得ない、でも違うものであることも間違いない、という。で、ハックとアートにはつながりを感じるけど、プログラミングっていうとなんか全然レイヤーの違う話になっちゃう。結構共感しながら読みました。ストールマンの On Hacking という文章にジョン・ケージが出てくるんですねー。面白いなー。しかし Rubyist Magazine にジョン・ケージとかゴードン・マッタ=クラークの名前が出てくるというのがなんとも妙な感じです。
投稿者 ryoji : 10:31 AM | トラックバック
Java の開発環境とか
今どきの Java による Web アプリ開発のことをちょっと調べたりしてるんですが、何故か、なんかムカついてきた。なんだろ。
まず必要以上に特殊用語を使いすぎ。「デプロイメント・ディスクリプタ」とか、もうちょっと普通の言いかたすりゃいいのに。雑誌とか見てても、もうパソコン嫌いなおじさんみたいにカタカナの羅列にイラついてしまいます。だぁーもう普通に言えよ！みたいな。struts とか解説見ても構造を理解する前に用語を覚えられません。解説文とかマニュアルがすげー可読性悪い。それでなくてもサンプルコードだって (Java ゆえに) 冗長なのに。加えて、もともとから冗長な XML を設定ファイルに使うのが作法らしく、しかも長い名前が良いスタイルらしいので、もう本当、読んでてハラ立ってきます (気が短い)。で、あと JSP よか Velocity とかの方が良さげと思ったんですが、立ち読みした参考書がヒドイ内容で (なんで Velocity の本に「Java の基礎」とかあるんだ?) そこでまたブチキレですよ。
struts 以外の代替フレームワークとかテンプレートとか O/R マッピングツールとか調べてても、なんていうのかな、解説文の「文調」がみんな似てるっていうか。うをーこれは良さげ! ってならないんですよね。元気がないっていうか、色気がないっていうか。パサパサなんだよなー。…なんて他の人達は思わないんでしょうかね。一応がまんして読んで、あーこれが自分の目的には合いそうだなーって理解はできるんですけど、なんか全然ウキウキしない。
しかし、たぶん、きっと、慣れの問題もかなりあるでしょうから、もうちょっと我慢して頑張ってみます。
投稿者 ryoji : 12:19 AM | コメント (2) | トラックバック
March 23, 2005
テストファースト
（貧乏な人のための）Perl モジュールの作り方。 : torus solutions!を参考に、テストファースト・プログラミングを初めて(をい!)試してます。うーむ、これは結構、いやかなり、いいかも。前にちょっと Java で JUnit をやってみよう、と思ったときは、Eclipse とか含めていろいろ一度に覚えようとして挫折しましたが、慣れた Perl なら簡単でした。もう余計な心配するより先にテストしたほうが絶対に精神的に楽。テストファーストを勧める本とかでは「テストを書くのが楽しくなる」とかありますが、そこまではさすがにいきません。が、モジュールを書くときはどうせインターフェースを決めながら作るので、仕様のアイデアをメモするくらいのつもりでテストを書けば、そのままずっと使えていい感じです。
AHHHHHHH!!!! NOT TESTING! Anything but testing! Beat me, whip me, send me to Detroit, but don't make me write tests!*sob*
Besides, I don't know how to write the damned things.
とかあって笑いました。
ついでにメモ。CVSの基礎練習。