itouhiroメモ

WebAborn（ウェブあぼ〜ん）という User JavaScript 作成サイト

http://webaborn.herokuapp.com

を公開してるんだけど、バージョンアップしたので報告だ。

Opera対応

更新履歴みると「Operaに再対応」とあるね。以前は動いていたんでしょ。

http://d.hatena.ne.jp/itouhiro/20120317#c

に書いたことだけど、バージョン11や12だとOperaでうまく動作しなかったんだよね。Google検索の結果をうまく「あぼ〜ん」できなくてさ。

画面上のほうの、titleタグの部分だけ「あぼ〜ん」になってる。

むしろ旧バージョンの、バージョン5や8ならうまく動いた。そこでバージョン8を最新版同様の機能にしてOpera対応とするつもりだった。

でも動作確認するとさらに問題が。

Operaでそのスクリプト使ったとき、NGワードが少なければ動作するけど、NGワードが多いと動かない。具体的にはNGワードが150語だとOK。800語だとまったく動作してない。

へえ。

そこで、NGワード256語以上だと動かないのかも、と勘を働かせて、NGワード200語ごとに動作を小分けにした。するとNGワード800語でも動作したよ。

Operaはいろいろ難しいのね。

でもOperaは個人的にも使ってるブラウザだ。Windows2000やAndroid2.1で軽く動作して新しいブラウザは、Operaしかない。Android2.1でもWebAbornスクリプトはそのまま動く。ほかにはない特徴をしっかり持ってるよね。

ただ、このスクリプト、これまでのスクリプトより遅いんだよね。

遅いのか。それって大きな問題のような。

結局、これまでのスクリプトのほうが動作早いからそれを「タイプ1」(ver13)として提供。Opera対応スクリプトは「タイプ2」(ver13.1)として提供することにした。

なんで動作が遅いかなんだけど、「タイプ2」はWebAbornバージョン8を元にしている。バージョン8については

http://d.hatena.ne.jp/itouhiro/20110107

に書いたけど、内部動作としてXPathで文字列検索までする。XpathをWebブラウザ上でいちいち生成して、それからそのXpathで文字列検索するので、それで遅いのかな？と思った。そこでXPath生成はServer側ですることにした。

高速化を試みたのか。それで早くなったの？

いや、動作速度としてはとくに変化を感じなかった。

変わらないの？

生成したXPathは、元データ（配列）よりサイズが大きくなる。Ver8でファイルサイズが25KB だったuser.jsファイルが、「タイプ2」(ver13.1)だと158KBにまでふくれ上がるのだ。そのファイル読み込みに時間かかって、XPath生成する時間と変わらないのかもしれない。

というか、XPathの文字列検索が遅いんだよ。「タイプ1」では文字列検索にJavaScript使ってXPath使ってないから、その差だろう。

ふーん。

結局「タイプ2」(ver13.1)では、改良後のXPath生成済みuser.jsを提供しているよ。

まあ、遅いといっても、最近のCore i7シリーズだと区別つかないかもしれないね。NGワードが150語くらいなら、とくに重いというほどでもない。

私が使ってるCore Soloの1.0GHzというCPUはいい感じに非力なので、スクリプトの重さがわかりやすい。

NGワード800語のタイプ2だと、Firefoxでtwitter.com表示しきるまでに「このスクリプトの動作に時間がかかっています。停止しますか」という警告ダイアログが2回も表示されるくらいだ。同じ条件でタイプ1だと何とか1度も表示されない程度には早くなる。

最近はAndroidスマートフォンでもCPUが1GHz超えでデュアルコアだからねー。そのCPUは確かに非力だ。でも非力なほうが重さがわかりやすいというのはおもしろい。

公開サーバー・言語

公開サイトが変わったんだね。これまでは

http://ai11.net/software/webaborn/

だったね。

http://webaborn.herokuapp.com/

というところに変わったのか。

http://d.hatena.ne.jp/itouhiro/20120317#c

にも書いたけど、ai11.netのサーバーを移転したらあまりPHPスクリプトの動作がよろしくない。余計な広告も入るし。

そこで、広告なしで無料でウェブアプリを公開できる heroku というウェブサービスを使った。

herokuのポイントは

• node.jsに対応している。
• Ruby作者まつもと氏が参加している。しっかりしたところなのだろう。 google:heroku matz
• URLが短く、TopLevelDomainを無料で使える

以前はGoogle App Engine(GAE)で公開しようかなと考えていたけど、GAEはJavaかPythonを使う必要がある。

herokuならnode.jsが使えるから、これまでクライアント（Webブラウザ）で動作させていたJavaScriptをそのままサーバーサイドで動作させることができる。この利点が大きかった。

言語はこれまでRubyとPHPを使っていたのか。Rubyに戻してもよかったんじゃないの？

RubyはRails使うならともかく、言語単体としてはC/Javaと文法がちがいすぎるのと、汎用性が低いのでそんなに使いたいと思ってない。

汎用性というのは、いろんなところで使えるか、ということなんだけど、JavaScriptは

• ClientSide (Web browser)
• ServerSide (node.js)
• ActionScript (Flash)
• Adobe Extend Script (Photoshop/Illustrator)

とかいろいろ使えるから覚えるとオトクなのだ。

Pythonも

• ServerSide (最近のLinuxDistributionには最初から入ってる)
• FontForge組み込みスクリプト
• Blender組み込みスクリプト

などいろんなとこで使える。

Rubyはそういうところが少し弱いかな。

PHPは正規表現使ったとき「バックスラッシュをあと何個追加すればいいんだー！？　いちいち動作確認しないとわからないぜ」みたいなカッコわるいことがあったので、それほど使いたい言語ではない。ただHTMLテンプレート機能標準装備なので、かんたんなことをするならラクだけどね。

でもnode.jsはまだバージョン0.6で熟成されてないよね。

でももう成長軌道には乗ったと思う。今後もサポート続行して使い続けていけると思うよ。

WebAbornは現在のところDB使わず、HTTPのPOSTで送られてきたデータを文字列加工してブラウザに返すだけだから、仕組みとしては簡単だ。だからnode.js/herokuの使い方覚えるには適した教材だった。