Hatena::ブログ(Diary)

cc1000の日記

2009-07-04

Google Codeでの挫折

03:02

先日、Google Code にプロジェクトを立ち上げた。

翌日、設定をいじっているうちに管理者アカウント一覧から自分のアカウントを消しました。

オシマイ。

終わりはけっこうあっけないものですね、もう何もできませぬ。

2009-07-03 JavaScriptでの最適化について

英語は基本的にダメなので、いつも誰かが日本語にしてくれるのを待ってたりします。

今日はtohokuaikiさんの記事を読んで、ちょっとJavaScript最適化に取り組んでみました。

http://d.hatena.ne.jp/tohokuaiki/20090630/1246351679


文字列結合の最適化!

配列にpushして最後にjoinってのは、JavaでのStringBufferみたいなお作法に近いでしょうか。

検証してみたところ、確かにIE6だといい感じに・・・「すご〜く遅い=>ちょっと遅い」になりました。

FireFoxChromeについても、気にするほどの副作用はなさそうな感じです。

                             IE6            FireFox        Chrome
10byte * 10000回結合    526.5 => 43.8    10.0 => 10.9    1.8 => 5.0
100byte * 1000回結合     54.7 =>  6.2     4.3 =>  4.4    0.3 => 0.7      ※単位msec

それにしてもChrome素敵。

テンプレートエンジンでは文字列結合を多用しているので、早速ソース修正しました。


他のところは適用が難しい&修正後の検証がちょっと厄介なので・・・そのうち検討してみます。

2009-07-01 JavaScriptでフレームワークをつくりました

数年遅れな感じは否めませんが、JavaScriptによるフレームワークをつくってみました。

恥ずかしながら公開させていただきます。

デモ http://fri-sun-mon.appspot.com/


構成

  • テンプレートエンジン
  • イベントプロセッサ
    • 処理はXMLで定義するので、その日の気分や実装者によるブレがあまり生じません。
    • 通信やエフェクトなどの非同期処理もあまり意識せず、すっきり記述できます。
    • JavaScriptの知識がない人でもいろいろできます。

これを使うとなにがうれしいのか

  • レスポンスはViewでなく素のデータでよくなるので、サーバーサイドがかなりすっきりします。
  • ステートレスな感じになり、スケールアウトも容易にな・・・るかもしれません。
  • レンタルサーバーGAEなど、制限の多い環境・慣れない言語でもなんとかなります。

以上、拙作フレームワークの宣伝でした。

ぶっちゃけ、ひとりプロジェクトだと正直モティベーションがなかなかあれな感じです。

是非、ご意見をいただけますと幸いです。

2009-05-29 JDOの@Persistentをいじってみた

higayasuo様のコメントでいただいた

Set<T>では@Persistentの指定時に「serialized="true"」は不要

というご指摘を元に、ちょっといじってみました。

serialized="true"をつけない場合(defaultFetchGroupの指定も不要)

    @Persistent
    private Set<String> monthSet;
    public void addMonth(DateM month){
        this.monthSet.add(month.getKey());
    }

これで、きちんと永続化しました。

つけた場合とつけない場合の挙動をまとめると・・・

  • serialized="true"をつけた場合
    • defaultFetchGroup="true" も指定しないと、プロパティが復元されずにnullのママ。
    • 内容だけが変更された場合は永続化されない。
  • serialized = "true"をつけない場合
    • 内容だけが変更された場合でも永続化される。
    • 永続化したオブジェクトを復元した際に、クラスは維持されない(維持される保障がない)。
      • 例:java.util.TreeSetのインスタンスを永続化して復元した際のクラス
        • 宣言型がjava.util.Setの場合=> org.datanucleus.sco.backed.HashSet
        • 宣言型がjava.util.SortedSetの場合=> org.datanucleus.sco.backed.TreeSet

ということで

個人的なまとめとしては・・・

  • serialized=trueをつけなくても問題ない場合はつけない
  • プロパティの宣言型については無駄にあいまいな指定をしない

という感じでございます。

higayasuo様、ありがとうございました。

cc1000cc1000 2009/05/30 14:01 とりあえず、ここで記述した挙動についてはこっちもみとくべきでした
http://code.google.com/intl/ja/appengine/docs/java/datastore/dataclasses.html
英語はきついすなぁ…

2009-05-28

GAE/JでJDOいじってみた

02:10

なかなか慣れない・・・

パターン集というかセオリー集が欲しいです。

先行者様のお言葉に頼りつつ一歩一歩進む。

他のEntityへの参照を保持するクラスの実装はこんな感じかと思う。

    @Persistent(serialized = "true", defaultFetchGroup = "true") 
    private Set<String> monthSet;

    public void addMonth(DateM month){
    	if(this.monthSet.add(month.getKey())){
        	Set<String> tmp = this.monthSet;
        	this.monthSet = (new TreeSet<String>());
        	this.monthSet.addAll(tmp);
    	}
    }

はまったこと。

・これだと、Entityが再生成されたタイミングでもmonthSetがnullのまま。

    @Persistent
    private Set<String> monthSet;

・これだと、Setの中身がちゃんと永続化されない。

    public void addMonth(DateM month){
    	this.monthSet.add(month.getKey());
    }

・これでも、何故かSetの中身がちゃんと永続化されない。

    public void addMonth(DateM month){
    	this.monthSet = (new TreeSet<String>(this.monthSet));
    	this.monthSet.add(month.getKey());
    }

・同一Entityに対する更新処理を重複して行なうと、ちゃんと永続化されない気がする・・・。

・別のエンティティグループのエンティティを1つのトランザクション内でいじると怒られる。

・一度腐った実装で生成したEntityを永続化しちゃうと、ソースを修正しても腐った動作になる。

 とりあえず、開発時には廃棄処分をまめにしたほうがいい気がした。

なんとなく疲れる。

higayasuohigayasuo 2009/05/29 09:59 基本的には、内部のフィールドに直接アクセスするのはだめで、
setter, getterメソッドを通じてアクセスするようにしないと
JDOがその変更を認識できません。
setter, getterメソッドをエンハンスして、
変更を検知しているためです。

Set<T>のプロパティは、serialized=trueでなくても
永続化されたはず。

cc1000cc1000 2009/05/30 00:33 コメント、ありがとうございます。
>Set<T>のプロパティは、serialized=trueでなくても
>永続化されたはず。
ここがミソみたいでした。
検証したところserializedがtrueかfalseかで若干挙動が変わるようです。