Archive for the ‘Francesco’ Category

マイクとAjax の終焉

Ajax 系のプログラムは以前から作っていたが、今回のものほど規模は大きくなく、エンジン部も全て自分で書いていた。特にXML でデータをやり取りとかはなく、直テキストでデータだけ送ったり、HTML を送ってinnerHTML でほりこんでみたり、あるいはJSON をeval してみたりという感じだった。

今回、「ボタンを押すと(ブラウザ内で)ポップアップウィンドゥが開き、その中で画面遷移する」、みたいなアプリをウィンドゥの中と外を極力切り離した形で開
発することとなり、方式をいろいろ検討した。ふと、横の人をみるとなにかしらjQuery とかThickBox とかいうのを使っている。JQuery でjavascript をJava や.Net みたいなイベントドリヴンに書けるみたいだし、ThickBox でポップアップする部分の中身をURL で指定すると
Ajax で取って来たり、まあ便利そうなので使ってみることにした。

次に中身をどうセットするかである。静的な表示と動的(表示するデータが変わる)な場合とを考慮して手法を検討しなければならないか?

1.Javascript の中に直接HTML を書いて、ポップアップウィンドゥのinnerHTML に。

var content = “<div>”;
content += “<h1>D’oh</h1>”;
content += “</div>”;

で、content をポップアップウィンドゥのinnerHTML に。
2.AJAX で中身を取得し、ポップアップウィンドゥのinnerHTML に。

今回は画面遷移が多く、システムを通してひとつのJavascript ファイルで根幹の部分を記述したい。1では、全部の画面データをそのファイルに含めると使いもしないデータが読み込まれまくっているのが微妙だ。

2の方式のようなAjax のリスポンス待ちはないが、今回は画面遷移の度にサーバーとデータのやり取りが生じることがほとんどであまり意味はない。
また、デザイン修正が大変そうなのに加え、ポップアップウィンドゥ内でのイベントをjQuery の強力なイベント処理機能を用いて記述しづらく、タグ内にonclick とか書くと処理を追えないようなコードになりそうだ。

さて、ThickBox では、a タグのhref にURL を指定すると表示するコンテンツをAJAX 的に取得して表示できる。AJAX 的にというのは指定されたURL の出力をそのままポップアップウィンドゥのinnerHTML にほりこむ感じである。ここで、デザインとビジネスロジック的なプログラムコードの分離を考慮した設計を前提にどのように動的データを埋め込むか考えると、

1.URL にPHP を指定し、PHP でSmarty などのテンプレートエンジンを用いて雛形となるHTML ファイルを読み込み、サーバーサイドでデータを埋め込んで出力。

2.URL に雛形となるHTML を指定し、JSON でデータを取得し、クライアントサイドで埋め込み。

素直に考えると1である。2では、HTML を読み込むのと、JSON でのデータ取得と、Ajax処理が2回発生し、クライアントサイドでデータを埋め込みというのが処理を遅く感じさせる。しかし、本件では2を選択してしまった。

まず、その時点ではJSONP を若干考慮していた。AJAX ではドメインが異なるURL からのデータ取得はできないが、script タグのソースはドメインの制限がないため、ドメインの異なるURL をscript タグのソースとして指定し、結果を変数にほりこむあれである。JQuery のJSON 関数はこれらを意識することなくデータが取得可能に設計されている。しかしながら、開発の時点でCertificate が取れていないHTTPS のURL からはデータが取得できないことが判明し、断念した。

次に、ポップアップウィンドゥの中のHTML にもjQuery によるイベント処理や画面遷移のためのThickBox の記述があるが、そういった処理がAjax やPHP を介して取得される部分にあるのが、感覚的になんとなく遠い気がした。

ということで、こういう形式にしてしまったわけだが、開発を通して様々な問題に気づいた。

- ブラウザごとに挙動が異なるJavascript。IE6,IE7, FireFox, Opera, Safari といった主要ブラウザで(時にはWin, Mac 版それぞれで)全動作確認をおこなうのは退屈で骨の折れる作業である。少しの修正でも、全体に影響をあたえることも考えられるし。

- 要求仕様が開発開始前に固まってればいいが、開発開始後にデータ項目が変わったりすると、DB, PHP, HTML, Javascript とそのデータを扱う箇所を全て修正する必要が生じ、精神的苦痛が大きい。

- Plug in などを用いての開発は、要求仕様がPlug in の機能内のうちはいいが、それを超えるような要求仕様変更が生じると、Plug inの中身を解析して修正を施すか、最悪Plug in 全体を自分で書き直すこととなり、想定外に時間を消費する。

- jQuery とPlug in とでVersion の互換性に問題がある場合がある。例えば、Interface Pluginの最新版は現時点でjQuery1.2 では全く動かない。

- jQuery ではHTML タグのID やクラス名で要素を取得して処理を、という形が多いが、デザイナーのCSS とぶつかると痛い。

- jQuery やPrototye.js といったフレームワークを用いると、それぞれでの開発経験がないとコードを追いづらいかもしれない。また、初心者がいきなりprototype.js を用いる前提でjavascript を書き出すと危険である。どこまでがjavascript の言語仕様で、なにがprototype.js の機能かわからなくなると微妙。

- 今年半ばに発表されるIE8 ではたして動くか?

まあとりあえず今回はjQuery でイベント処理部をHTML から分離し、画面毎のファイルも分割されているため、そんなにごちゃごちゃでもないと自分では思うが、PHP にも勝るとも劣らないJavascript の言語仕様のゆるさは、常人には理解しがたい混沌さを生み出すには十分である。特にグローバル変数のスコープは異なるドメインさえ駆け抜ける。

ということで、Ajax はもう無理です。そろそろSliverLight とかでいいです。

マイクよ、永遠に

いやー、LAも寒くなってきましたね。事故りました。前回お伝えしたとおり、Premiumが前年比$1500アップのため、Coverageを最低に設定して、年$300くらい安くなるようにした矢先、クラッシュしました。

この町は人口過剰すぎてきびしい上に、公共交通機関があまり良くない為、車であふれています。無作法な運転の車もかなり多いです。

だいたい、私は眠気がさめるのが遅く、能力も通常時から大きく劣るため、朝に車を運転とか避けたいのですが、代替の通勤手段はバスと電車になります。時間が倍かかるのに加え、ほとんどの乗客がかなり無作法です。Hollywoodに住んでいて車を持っていなかった1ヶ月間くらいの時期で乗客の喧嘩に2回遭遇しました。

もう、無理です。身体的・精神的・社会的に、無理です。LAはもう無理です。

さらば、マイク

いやー、自動車保険の更新の季節ですね。来年分のPremiumが着ました。1年で$4000でした。前年比$1500アップです。一回、30mphくらいでレイン変えただけで、後ろに車もいないのに、無実の罪で“Dangerous Driving”とか言われて捕らえられまして、violationが付きました。そのときは、書面で戦ってだめで、裁判所出頭とかも面倒なので、この非情な町に住む税金として$150払いましたが、実はそれだけで済みませんでした。

これだけ払っても、Bodily Injury and Property Damageは$500,000までしかカバーされないのもどうかと思います。日本では年10万円以下で、対人無制限とかのような。

いろいろ他の保険会社も調べましたが、これが最安のようです。もう無理です。アメリカは無理です。

(惜しまれながら)最終回 フランとネタ切れ

フランです。いやーなんていうか書くネタがないんですよね、正味の話。なんか会社と家と往復するだけの毎日で、目新しいこととかまったくないし。人生って苦痛ですよね。

正直途中からどういうネタを書けばいいかわからなくなりました。物書きの端くれとして、読者の望むようなものを提供していければ、と考えていました。しかしながら、編集部からは特に対象や内容に関する情報はなく、通常、年齢層、性別、所在地などから読者を想定して、興味を持っていただけそうなネタを探すのですが、そういったイメージがわかず、かといって、万人に喜ばれるようなものを書けるほど、私は物書きとして優秀でないことに気が付きました。

そして、修行のため、旅にでることを決意しました。

努力を惜しまず、苦痛を恐れず、物書きとして大成できるようがんばっていきたいと思います。

いままでご愛読ありがとうございました。

編集部より
フランチェスコ先生の次回作にご期待ください。

次号、満を持してあの男が登場!新連載「xxx」。

第7話 Fran’s Apple

どうも、フランティック・フランです。喉のでっぱってる部分をAdam’s appleとか言う人がいますが、皆さんはちゃんと自分の名前を入れて呼んであげて下さいね。Joeyのように。

いやー、新型でそろいましたね。個人的には赤のNanoがかなりいい感じでした。2Gの黒Nanoをもっているのですが、売って買い換えたい感じになりました。

でもまあ5GのいわゆるビデオiPodがでるまで、正直アップルにぜんぜん興味ありませんでした。Playerの中身の管理がiTunesを介してしかできない(他のPCから音楽ファイルをPlayerに入れられない)とか、そのiTunesがかなり重いとか、iPodがWMA(Windows Media Audio)を再生できず、当時私はMP3より音がよいとされていたWMA128kbpsでエンコードしていたりとか、正直5Gまではあまりスタイリッシュでもなく、しかも高いとか。しかし、5Gがでて、デザインの良さと十分に鑑賞できるビデオの品質に惹かれて購入しました。

利点は

  • 安い。人気が出て薄利多売な感じに。
  • 全ての音楽ファイルが持ち出せる。
  • ジャンルやアーティストなどのタグ付けにより、管理が楽。探しやすい。どのジャンルのCDが何枚あってとか、誰のCDが何枚あってとかわかる。
  • カバーフローで、実際にCD手にとって選んでいるような感覚で聞くCDを決められる。
  • 再生回数が記録される。iPodで聴いても同期すれば加算される。SmartPlayList機能で再生回数が多い曲順に並びかえれたり。スキップ数とかもある。
  • SmartPlayListが強力。標準のタグを利用して、ジャンルが何で、Ratingが3以上で再生回数が0の曲みたいな複雑な抽出条件を設定できるし、自分でCommentタグに更にタグを決めて入れておけば(例えば、Piano, Instrumental, Ballad, Acoustic, Female Vocalとか)、Commentタグに「Piano」と「Ballad」を含むとかで、かなり自由に抽出化。なんかガキのころ、そういう感じで女性ヴォーカルのPianoのBallad集みたいなカセットテープをつくってたのがすぐできる感じ?
  • フリーで楽しめるものがいっぱい。毎週1曲無料でダウンロードできるし、Prison BreakとかのSeason Premiereとかもフリー。ビデオポッドキャストとかフリーで質の高いビデオがいろんなジャンルに亘って公開されているし。

欠点は

  • クラシックとか管理しづらい。例えばロンドンフィルが演奏したMozartとかだと、Artistの欄にLondon Philharmonic Orchestraとはいって、ComposerがMozartになるが、Composerからは、曲を辿れないので、自分にとってはあまり重要でない演奏者を覚えるか、ジャンルがClassicalを全表示してCoverflowで探すか。。ちなみにiPodではジャンルごとのCoverflowとかないし。Operaとかだと更にえらいことに。歌手がグループに属しているわけではないので、1曲1曲歌ってる人の名前がArtist欄に入ったり。全員を総称する名前とかないので。
  • AudioBookとか著者があって、本のタイトルがあって、章ごとのファイルがあるのが普通だが、そういう構造化はされず、全部表示される。ミュージックビデオ系もそんな感じ。

CD屋で見ていて、買ったかどうか忘れたCDもiPodをみればすぐわかるのがいいですね。また、昔はCD買って帰って、それをCDPlayerに入れて、入ってたやつを新しいやつのケースに入れてとかしていると、どれがどのケースに入っているかわからなくなるのが普通ですが、そういうこともないですしね。

では、また。