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で文字列検索までする。XpathWebブラウザ上でいちいち生成して、それからその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だと、Firefoxtwitter.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はJavaPythonを使う必要がある。


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


[合いの手担当] 言語はこれまでRubyPHPを使っていたのか。Rubyに戻してもよかったんじゃないの?


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


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

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


Python

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


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


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


[合いの手担当] でもnode.jsはまだバージョン0.6で熟成されてないよね。


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


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