カスタム検索

2008年1月22日火曜日

Ext-JS 2.0 速度検証(フォームapplyTo,transform編)

前回のサンプルに近い適当なフォームを用意して 100個作成と applyTo と transform で作ってみました。

ext-base
11712ms

・・・で、FireFoxがハングします(´・ω・`)
早くもないしちょっぴりショック、、、

で、気をとりなおして Safari でも計測

Safari
1306ms

            スポポポポポポーン!!!
      。     。
        。  。 。 。 ゚
       。  。゚。゜。 ゚。 。
      /  // / /
     ( Д ) Д)Д))


Safariはやいなー、JSの実行もエレメントの追加/削除もFirefoxとは比べ物にならない早さ・・・
ただComboBoxがうまくtransformできませんでした(´・ω・`)
(セレクタの位置が変な所にいってしまいます)

うーん、JavaScriptでダイナミックにフォームを作るのはもう少し様子見で・・・

Ext-JS 2.0 速度検証(FormPanel)

Javascriptのコンパイル(圧縮)で計測に使ったJSの重い処理ですが、
Ext-JS1.1を使ってダイナミックにフォームを作ってます。

Ext-JS2.0では早くなったのか検証してみました。(同じ処理をしているわけでないので比較にはならないですが、、、)

まず公式サンプルのフォームを使ってテストしてみます。
リンク先の Form 1 - Very Simpleです。

このフォームを100個作成してかかった時間をはかっています。(FireFoxで行いました)

ext-base
10488ms
10768ms
11003ms
10428ms
10556ms

jQuery 1.1.1
10824ms
10961ms
10877ms
11029ms
11118ms

yui-utilities 2.2.0
10778ms
10793ms
10547ms
10954ms
10502ms

prototype 1.5.0
10840ms
10502ms
10507ms
10852ms
10898ms

変わらんですね〜、んでは$()が300%早くなったという噂のjQuery1.2.2を使ってみましょう、、、

jQuery 1.2.2
10856ms
11147ms
11139ms
11134ms
11140ms

・・・(#^ω^)ピキピキ

せっかくなんでやたらと快適な Safari3 でも試してみました。

safari(ext-base)
5874ms
5845ms
5885ms
5902ms
5881ms

  。 。
 / / ポーン!
( Д )

・・・えーっと、ってことはブラウザのエレメントの追加/削除が単純に重くてJavascriptが悪いって事ではないのかな
(Firefox最近やたらと重いんだよなぁ、、、拡張もたいしていれてないのに、微妙になってきたなぁ)

次回は、dom操作が少ないと思われる、既存のフォームからext-formへapplyしていった場合の速度を計ってみたいと思います。

2008年1月20日日曜日

引っ越し準備

プロフィールに名古屋とか書いちゃってますが、実はまだ名古屋んではなかったりします・・・
@1Weekで引っ越しなんで準備でてんわやんわ(古い?)です

引っ越しの度に思うのですが、びっくりするほどゴミが出ます。
今の所にひっこしてから一切手つかずだった燃えないゴミをひっぱりだしたらなんと、、、


iPodが発掘されました



ワロス

2008年1月16日水曜日

MacでGrails! 超入門編(Hello World!)

まずはお決まりのHelloWorldです。
コマンドプロンプトより、以下のコマンドでプロジェクトを作成します。

grails create-app hello

helloがプロジェクト名になります。
だらだら〜っとメッセージが流れてプロジェクトの雛形が完成です。

作成したプロジェクトのフォルダへ移動し、コントローラーを作成します。

cd hello
grails create-controller home

以下のファイルが作成されます。
hello/grails-app/controllers/HomeController.groovy

コントローラーとはアクションの集まりです。
今回はHelloWorldを画面に表示する、というアクションを作ります。

HomeController.groovy を編集します。


class HomeController {
 def index = { }
 def world = { render "Hello World!" }
}


これで HomeController には index と world というアクションが作成されました。
では以下のコマンドを実行して起動してみましょう。

grails run-app

つらつら〜っとメッセージが出てきて、以下のメッセージが出た所で起動完了です。

Server running. Browse to http://localhost:8080/hello

http://localhost:8080/hello へアクセスしてみましょー
Welcome to Grailsのメッセージと共に HomeController へのリンクが表示されていれば完璧です :)

早速 HomeController へのリンクを踏んでみましょう・・・エラーが出ますね ^^
404エラーが出ています、が、これは正しい動きです。

現在のURLを見て下さい、 http://localhost:8080/hello/home になっていると思います。
これは「hello プロジェクトの home コントローラーの index アクションを実行」という動きになります。
index アクションは何も作ってないのでエラーになってしまった、というわけです。

では先程作った world アクションを実行してみましょう。
感のいい方ならもうわかったかもしれませんが、worldアクションの実行は http://localhost:8080/hello/home/world へアクセスすると実行出来ます

URLとコントローラー、アクションの関係は以下のとうりです。
http://localhost:8080/{projectName}/{controllerName}/{actionName}
index はちょっと特殊で、アクション名をつけなかった場合は index が動作します。
(もちろん、 http://localhost:8080/hello/home/index としても動きます。)

Hello World!が画面に表示されましたか?
表示されていればもうあなたはgrailsユーザーです ^^

2008年1月15日火曜日

MacでGrails! 超入門編(概要とセットアップ)

最近メインで使っているフレームワーク、Grailsを紹介していきます。
まだまだ日本では知名度は低いですが、将来有望(?)なフレームワークです。
わかりやすく乱暴にいってしまうと RubyOnRails の Java になったバージョンです。(RoRと目指す所は違います)

利点
・Javaの様々な資産を利用出来る
・コアはSpringFrameWork、Hibernate等定評のあるソフトで動いている
・Groovy言語を使用し、Javaのめんどうなソースを簡略化可能
・Java(ほぼ99%ぐらい)そのままで書く事も可能

欠点
・発展途上の為仕様が変わる事が良くある
・リリースされたバージョンといえども一部バグがあったりする
・ちょっと重い?

まぁ欠点はいずれも時間が解決していく系だと思います。

で、Macで動かしてみましょー
といっても開発陣はMacが多いようでMacで動かすのはとても簡単です。
Winでもほぼ同じです、試した事はないですがWinではインストーラーもあるようです :)

http://docs.codehaus.org/display/GRAILS/Japanese+Installation
ここの「ダウンロードしてインストール」に従って進めていきます。

ここで日本語対応の為のおまじないをかけておきます。
grailsを解凍したフォルダの bin/startGrails の先頭の方(10行目辺り)へ以下の行を追加します。

JAVA_OPTS="-server -Dfile.encoding=utf-8"

これでファイルをUTF-8で作成すれば日本語はOKです。
コマンドプロンプトから「grails」を実行してメッセージが表示されたら次のステップです!

2008年1月8日火曜日

Cubby セットアップ編

ふと Cubby をインストールしてみた。

公式のセットアップ(http://cubby.sandbox.seasar.org/setup.html)に従い進めていく。

Mavenをインストール、よくわからないままパスを通してコマンド実行
ごりごりとダウンロードがはじまり、しばらくして終了

mvn tomcat:run してとりあえず起動、またまたダウンロードがはじまる、、、
止まった所で http://localhost:8080/artefactId へアクセス、おー動いてる!

サンプルのおうむ返しをチュートリアルを読みながら解読、基本は今流行のRails系な感じ
まだやってないけどEclipseのプロジェクトもMavenからサクっと作れるみたいなので、
保管とか楽そうでいいなー、Javaっぽいめんどくささはアノテーションで頑張っているみたい

ここまでダウンロード時間も含めて10分ぐらい、Seasar自体まったく触った事なかったんですが、これなら入りやすいですね。
とりあえず次回はもう少し触ってみたいと思います

Javascriptの圧縮(gzip編)

まずは容量比較から

通常状態(788kb)
yuicompressor(718kb)
yuicompressor+gzip(196kb)

おー、だいぶ変わりましたね。

続いて読込み/スクリプト実行速度の計測です。

1770ms / 3856ms
1790ms / 3798ms
1690ms / 3797ms
1820ms / 3738ms
1620ms / 3793ms

ローカルだと違いが出ませんでしたが、容量はあきらかにへっているので、実運用では有効に働きそうですね。
ただローエンドなクライアントでgzipの処理がどの程度負荷になるのか気になるところです。

2008年1月7日月曜日

Javascriptのコンパイル(圧縮)

Javascriptの圧縮をYUI Compressorでテストしてみました。
圧縮によるクライアントへの受信速度と、圧縮されたスクリプトの実行速度の計測です。

対象となるのは、サイズばらばらのJavascript16ファイル(全788kb)を表示、
JavaScriptにて約1000のエレメントを追加するページ。

無圧縮(788kb)でのロード時間 / スクリプト実行時間
1530ms / 3776ms
2360ms / 3751ms
2650ms / 3789ms
2290ms / 3754ms
1500ms / 3789ms

圧縮時(718kb)のロード時間 / スクリプト実行時間
2480ms / 3818ms
1980ms / 3766ms
2520ms / 3788ms
1480ms / 3761ms
2470ms / 3713ms

か、かわんねぇ〜・・・ローカルで動かしてるから通信速度が遅いほど効果はあると思います。
とりあえず圧縮してもスクリプト自体の実行速度は同じ、と(当たり前か)
(容量があんまりかわってないのは元々圧縮されたものが多いため)

というわけで次回は+gzipで計測してみます。

2008年1月4日金曜日

思い立ったが吉日

誰に見せるわけでもないけど、やれる事はやっておこうという精神で。

で、Adobe Airの話です。
前から気になっていたのですが、なかなか触る時間もなく放置だったAirをインスコ。
適当に調べてとりあえずHelloWorld! > オウム返しの作成

Hello.xml

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/1.0.M6" version="1.0">
<filename>Hello</filename>
<id>com.kujirahand.test.Hello</id>
<initialWindow>
<content>Hello.html</content>
<visible>true</visible>
<width>640</width>
<height>480</height>
</initialWindow>
</application>


Hello.html

<html>
<head>

<title>Hello</title>
<script type="text/javascript"><!--
function say() {
alert("Hi "+document.getElementById("name").value);
}
//-->
</script>
</head>
<body>
Input your name:<input type="text" name="name" id="name">
<input type="button" onclick="say()" value="OK"/>
</body>
</html>


何事も無く順調に、、、ってあれ、日本語入力できなくね?
ちょっと調べてみるとまだ日本語入力には対応してないっぽい、、、しょぼーん
というわけでしばらく様子見なAirでした。