8日にふと思い立ち、勉強も上の空でスクリプトを組みまくってました。部活サイトの編集スクリプト、記事部分の作成・編集・削除等の基本操作がやっとこさできるようになったんです。PHP5で書くとちょっとは楽になるかなぁと淡い期待を寄せていたんですけど、見事にその期待は打ち砕かれ。クラスメソッドのカプセル化による再利用性向上とかはそこそこなんですけど、その分今まで慣れていたアルゴリズムの把握が急に難しく感じるように。処理による分岐が多くなったので、処理を上から下へ読むだけじゃダメなんだよなぁ。どこに何を置いたのか把握して、スコープとかも考慮しておかないと今まで以上にスパゲッティなコードを書いてしまいそうだ。うへ。
などと専門的な話題から入ってしまいたくなる今日この頃、皆様いかがお過ごしでしょうか。サイトの身内バレが激しくなってきたので、ストレートな専門用語は普段できるだけ回避するようにしていたんですが、今日だけ解禁。業界でもなかなかに面白い動きなどがありましたので。
まず、Openwaveの紹介から。これはau等に使われているWAP端末のエミュレートができるWebデベロッパーには有り難い一品。俺の携帯は古っいDoCoMoなので、auのエミュレートが一番困っていたのでした。Win版しかないようですけど、当面の間はこれでエミュレートできれば携帯でのサイトの状態確認にも使えそうです。試してみたところ、HTTPヘッダのMIMEタイプでいくつか問題がありました。HTTP_ACCEPTから対応するMIMEタイプの記述を判別し、さらにHTTP_ACCEPT_CHARSETから対応する文字コードを判別、それぞれ対応したヘッダを送出するようにしておいたんですけど、その判別に困ってました。今までならapplication/xhtml+xml文字列が存在すればXHTML文書を読み込めると判断していたんですが、どうにもOpenwaveを見る限りではさらに特殊なMIMEタイプがあるらしく、application/xhtml+xmlの後にセミコロンをつけてprofile=URIが記述されていたんです。このせいで実際には対応していないMIMEタイプを送り出すことになっていたようで、ちゃんとコロン区切りかどうかを厳密に判別する必要がでたということ。これを知らなかったせいで、今までau携帯から見れなかったんですな。厳密な判別を行ったところ、ちゃんとエミュレータでも表示されるようになったので検証価値が出たと思います。このエミュレータ(･∀･)ｲｲ!!
次からはニュース。まぁ全部スラッシュドット ジャパンなんですけど。なかなかに興味深い記事が多かったので紹介。
「Windows XP Homeはあと3年でパッチがリリースされなくなる」（スラッシュドット ジャパン）
Microsoftの方針として、次期Windowsである「Windows Vista」がリリースされてから2年後にXP Homeのサポートを打ち切るそうです。今年末までにはVistaがリリースとなるであろうということから予測したタイトルでしょうな。が、記事コメントにもあるように、あまりにも早すぎる打ち切りのような気がします。今までのような2000→XPやME→XP、98SE→XPなどのアップグレードとは違い、VistaはOSの根幹からして違うようなので、単純に上書きアップグレードとは行きそうにないです。性能的にも、Vistaを動かすには（現在の様子からすると）スペックが厳しいでしょう。さらにパソコンそのものの性能も黎明期から成熟期に入りつつある昨今、OSアップグレードのためだけにパソコンを買い換えるというのもあまり現実的な話ではありません。となると、後はメンテナンスされなくなったXP Homeがごろごろ……という感じになりそうで嫌ですな。大方記事コメントの方が参考になると思うのでこれ以上はそちらを参照していただきたいのですが、ともかくこのサポート打ち切り期間は延長してほしいところ。コメントにあるように、Linux使いとしてはここで奮起してLinuxユーザを取り込むという視野もほしいですけど。ちなみに、98SEも2006年6月末でサポート打ち切りとなるそうで。
「Mozilla プラットフォームで開発してみませんか」（スラッシュドット ジャパン）
XULRunnerという、Java仮想マシンのようなもののプレビューがリリースされたようです。MozillaやFirefox等のコードをベースにしているそうですが、これがあればMozilla・FirefoxいらずのスタンドアロンなXULアプリも開発可能になりそうです。コメントでは、XULは結構叩かれ風味ですけど個人的には期待してます。今後の一押しアイテム。XULそのものよりMozillaの態度が疑問、というのは反論しませんけど。JavascriptよりもPHPが使えるようになれば最高なのに。(´・ω・｀)
「OpenOffice.org 開発ドキュメントコンテスト開催」（スラッシュドット ジャパン）
いや、これはあんまり関係ないですけど。語学力と開発周りの説明に自信がある人、腕試しをしたい人はよろしいんじゃないでしょうか。賞金は750ドル。説明にもありますけど、オープンソースへの貢献というのは何もプログラム作成・バグ報告だけではないということを知ってもらいたいですね。時と場合によっては、ドキュメントはそれらよりも貴重。
「バグを発見する典型的なやり方ってありますか？」（スラッシュドット ジャパン）
俺はWebアプリ（PHP)中心なんで、デバッグはほとんどエラーレスポンスを眺めていれば予測がつきますな。エラーではないが予想と違う動作をするという場合は、printデバッグが早いですね。デバッガとかでもいいのかもしれませんけど、そこまで複雑な開発はしてませんし、個人ならどこに何があるのか頭の中にあるので、それを試すだけでいいprintデバッグの方がいいと思うんですがどうでしょうか。どうしても解決の糸口が見つからないときはエラーログをしっかり見直しますけど。
で、「バグの原因を発見する」ではなく「バグそのものを発見する」のはほとんどしません。理由。もうある程度起こるであろうバグは予測がついてるから。
それはこう言います。「仕様です」と。
（#ノ゜Д゜）ノ ┫：・’．：：・┻┻）`ν゜)・;'.、：・’．ﾋﾃﾞﾌﾞ
あ、あのですね、実を言うとそれを回避する手段を構築するには、機能以上の行数を書かなきゃならんわけですよ。プログラムの機能そのものはほんの数百行、そのエラーを検出し、訂正なり例外処理を行うなりする部分がその倍以上を占めるようになり、それらを書くよりも数倍もの時間をデバッグに費やし、さらにそれらの機能を考案するだけでも数十倍の時間がいるんだよこのド低能が！！ 自分が主体になって使うようなアプリにンなもん費やしてられるか！？ セキュリティのこともあるけど、その前に人前に出られるほどの立派な腕もねぇだろうがぁぁぁぁ！！
――なぁ＞俺。orz
最後は日頃の鬱憤が爆発気味になってしまいましたが、アプリの開発ってのはそんなもんです。まぁ、開発者が直に使うとはいえ、部活のスクリプトは俺以外が中心に使うはずなんで、そういった仕様とかも細かく伝えるようにドキュメントを作成しなければならんというのがこれからの作業というところでしょうか。
こうやってみると、何も気にしないではっちゃけて書いたときの文章量は半端ないなぁと省みる。やっぱり文章の推敲って大切だわ。
Comment