WebAbornバージョン13をリリース
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)
とかいろいろ使えるから覚えるとオトクなのだ。
などいろんなとこで使える。
Rubyはそういうところが少し弱いかな。
PHPは正規表現使ったとき「バックスラッシュをあと何個追加すればいいんだー!? いちいち動作確認しないとわからないぜ」みたいなカッコわるいことがあったので、それほど使いたい言語ではない。ただHTMLテンプレート機能標準装備なので、かんたんなことをするならラクだけどね。
でもnode.jsはまだバージョン0.6で熟成されてないよね。
でももう成長軌道には乗ったと思う。今後もサポート続行して使い続けていけると思うよ。
WebAbornは現在のところDB使わず、HTTPのPOSTで送られてきたデータを文字列加工してブラウザに返すだけだから、仕組みとしては簡単だ。だからnode.js/herokuの使い方覚えるには適した教材だった。