Kanasansoft Web Lab.: 2007年03月アーカイブ

« 2007年02月 | メイン | 2007年04月 »

2007年03月アーカイブ

2007年03月03日

Kanasansoft BlogEditor(20070303024732)公開

BlogEditorの最新版を公開した。主な変更は、新しいテンプレートの追加とライセンスの変更である。ライセンスは、修正版BSDからMITへの変更となっている。圧縮ファイル内に、MD5取得メソッドやJSON変換メソッド等、有用と思われるライブラリも含まれるため、興味のある方はダウンロードして頂きたい。

Kanasansoft BlogEditor(20070303024732)

2007年03月04日

Kanasansoft BlogEditor(20070304112210)

テンプレートの読み込み処理が抜けていたため、修正版をUP。既出の通り、MITライセンスへの変更も行なっている。

Kanasansoft BlogEditor(20070304112210)

2007年03月07日

元VBプログラマがWebアプリケーションを設計する際に気に留めておいて欲しいこと

そもそもC/SアプリとWebアプリは全く違うものと考えること

新聞・テレビ・ラジオ・雑誌等、メディアはいくつもあるが、それぞれに長所短所があるように、C/SアプリとWebアプリにも長所短所がある。新聞で音声を、ラジオで文字を伝えるのは不適切("みえるラジオ"等の文字多重放送は除く)であるのと同様に、C/Sアプリで簡単に実現できてもWebアプリでは不可能な事がある。

画面レイアウトを厳密に定義しないこと

VBの画面設計はドローアプリケーションのように、オブジェクトを自由に配置できる。しかし、Webの基本は言わばワープロだ。ワープロが入力された文章を順に表示するように、ブラウザはサーバから出力されたデータを順に表示する。CSSで位置やサイズの指定が可能であるが、それでも限界がある。table要素で厳密にレイアウトできなくもないが、昨今のxhtmlへの潮流に逆らうことになる。また、プリントされる事を考えるのなら、なお更tableは使用しない方がよい。
※印刷すると用紙をはみ出してしまうWebサイトは大概tableによるレイアウトを行っているかframeを用いている。

ダイアログに多くを望まないこと

VBアプリの多くはダイアログを多用する。ダイアログだけのVBアプリも存在するように、VBの開発の中心はダイアログだ。しかし、Webアプリはウィンドウ中心である。しかも、それはドキュメントウィンドウである。Webアプリにダイアログと言えるような機能は基本的に「alert」「confirm」「prompt」の3つしかない。これらダイアログにレイアウトの自由はほとんどない。
※複雑なレイアウトが可能な「showModalDialog」「showModelessDialog」があるが、これはIEのみの機能である。

別ウィンドウを開こうとしないこと

ダイアログのかわりに別ウィンドウを開こうとしてはならない。VBプログラマには以外に思えるかも知れないが、ブラウザ上のウィンドウの制御は意外と面倒で制限も多い。ポップアップブロック機能がIEにも標準で組み込まれており、Googleツールバー等もこの機能を持っている。これら全てのポップアップブロックを無効にしろとユーザに強要するのは問題だ。最近ではIE7にも実装されたようにタブブラウザも一般的になっており、ますます制御し難くなっている。

ウィンドウのサイズ変更・サイズ固定・位置変更を望まないこと

一応可能であるが望まないこと。Firefoxでは無効化も可能である。タブブラウザが一般化した現在では、ユーザに望まれない挙動であろう。そもそも、ブラウザのウィンドウはユーザのものであり、Webアプリはブラウザの表示領域にお邪魔しているだけのゲストである。
※「タブブラウザを判定し、ブラウザ毎に動作を変更せよ」等とPGに言ってしまったら、その場では何もなくともPGの間では永遠に笑い種となるかもしれない。

使用可能なコントロール数が全く違うと理解すること

VBのようにプロプラエタリで至れり尽くせりな環境で、豊富なコントロール群を使用し開発を行ってきたVBプログラマには信じられない程、Webアプリで使用できるコントロール数は少ない。タブや後述するコンボボックス等、基本と思われるようなコントロールでさえないのだ。

コンボボックスはWebアプリでは原則として使用できない

VBプログラマがコンボボックスと言う時は、リストボックスを指す事が多いが、リストボックスとコンボボックスは別物と一刻も早く気付くべきだ。コンボボックスとは「テキストボックス」と「リストボックス」を併せ持ったコントロールを言う。気の弱いPGや新人などはテキストボックスやリストボックスを駆使して何とか実現しようとするが全くの無駄である。
※最近では、AJAXを使用して可能となってきているが、今のところAJAX Libraryには後述するような問題がある。

戻るボタンの無効化を考えないこと

これも可能であるが、前述の通りブラウザのウィンドウはユーザのものでアプリ側が勝手に制御しても良い類のものではない。設計段階から戻るボタンが押されてもいいように考えておくべきだ。閉じるボタンも同様である。

自動的にプリントさせようと考えないこと

上と同様。Webアプリで(正確にはJavaScriptで)可能なのは印刷ダイアログを表示させるぐらいである(厳密にいうと[@media]によるCSSの変更も可能)。『「ボタン押下」すると一覧を「A4横・2UP・カラー」で印刷』などもっての他である。只、上記機能はActiveXコントロールで可能なのでこの方向に流される事がある。しかし、セキュリティのリスクを多く抱えるActiveXの使用を今更ユーザに許容するのか。
※更にWin+IE限定になってしまう。

画面に表示されているままにPDFに出力しようなどと考えないこと

クライアントにPDF作成のアプリケーションがインストールされていようがなかろうが、そもそもWebアプリからはそれらを操作できない。どうしてもPDFが必要なのであればサーバ側の処理となるが、様々な実現方法があるため詳細はここでは割愛する。しかし、どのようにユーザ側で表示されているかサーバ側からは把握できないため、「画面に表示されているままに一覧をPDFに出力」は不可能である。
※Excelを使用するような事も考えられるが複雑な話になるため、これもここでは言及しない。

入力チェックをクライアントだけですまそうとしないこと

これは余りにも当たり前の話であるが、未だに入力チェックをクライアントだけで行おうと考える設計者がいる。余りにも当たり前の話であるためここでは割愛する。

技術者の眼

これらの過ちを犯してしまう設計者は、普段どのようにWebを利用しているのだろうか。少なくとも「技術者の眼」で利用していないと筆者は考えている。目の前で起きていることの裏側を少しも考えていないのではないか。別ウィンドウを開くようなサイトがほとんどない事に気付かないのか。画面内のボタンを押すと自動的に印刷が始まるようなサイトが存在しない事に気付かないのか。こんな過ちの積み重ねが、予算や期間を切り詰め、そして実装者を追い詰めている。技術者は常に「技術者の眼」を持っているべきで、これができないのであればそもそも技術者となのるべきではないと考えるのは言い過ぎだろうか。

AJAXライブラリを多用しないこと

現行のAJAXは他のライブラリと同時に使用することを考えて設計されていないものも多い為、多用してしまうと思わぬバグを埋め込んでしまう。既存システムで利用しているJavaScriptにも影響するため安易に導入すべきではない。例えばPrototype.jsは著名なAJAXライブラリではあるが、JavaScriptのNativeオブジェクトの挙動を変更してしまう。これらの問題を回避する為に「OpenAjax Alliance」で標準化が進められてはいる。

どうしても戻るボタンの無効化をしたい

お勧めはしないが方法としては次の方法で可能である。通常の画面遷移はa要素ではなくJavaScriptのlocation.replaceを用いる。現在のhistoryが上書きされるため、Webアプリ上の別画面に戻れなくなる。
(ブラウザのウィンドウの初期表示が当該Webアプリであれば戻るボタンはアクティブにはならない。ブラウザのウィンドウが当該Webアプリ表示以前に別サイトを表示していたのであればそちらに移動する。)
フォームの場合(特にPOSTの場合)は最小化したiframe要素を配置しターゲットをiframeに設定する。更に、iframeのonload時にparent.location.replaceを用いた再描画処理を行う。frameで可能のように感じるが、これでは戻るボタンが有効化する。画面の再描画処理はDOMでも可能に感じられるが、iframeに対しての履歴が有効になる。「履歴が有効になったiframe」をそれを含むhtml毎replaceしてしまうのが肝である。ただ、このような実装を行うと他に無理が生じてしまうためお勧めはできない。やはり履歴ありの(つまり戻るボタンが押されてもよい)設計をすべきである。

OpenAjax Alliance

2007年03月11日

『あちら』側の技術者や『あちら』側を理解している技術者に『こちら』側で遭遇できるか

各所で話題になっている梅田望夫氏の『ウェブ進化論』を読んで感じたことをいくつか書こうと思う。
実際のところこの手の話はブログ等で非常に盛り上がっており、大筋において同感だ。Webアプリケーションの開発に携わっている筆者もひしひしと感じていたものの、うまく説明できずにいたインターネットの将来像を、『ウェブ進化論』は見事に言い表している。だた、前半貫かれていた客観性が、後半の『はてな』の話で客観性を欠けてしまったと思う。最後まで客観性を貫いていればよかったのにと考えてしまう。もちろん『はてな』はWeb2.0企業であることは間違いないと思うが、これを貫くことで『人月の神話』のように更に(国内では)長い間読まれる本になったのではないかと考えてしまう。

『あちら』側の技術者はどこにいるのか

ブログ界隈には『あちら』側で働く技術者だけでなく、『あちら』側に憧れている技術者や『あちら』側を理解している技術者が大勢いるが、ここではまとめて『あちら』側の技術者と表現することにする。『あちら』側で働く技術者の『こちら』側には『あちら』側で働く技術者は大勢いるであろう。では、『あちら』側を理解している技術者の周辺には、存在しているのだろうか。筆者が思うことは、『あちら』側を理解している技術者の『こちら』側には、『あちら』側の技術者はほとんど存在していおらず、ある種の疎外感を感じているのではないかといくこと。『あちら』側を理解してもらおうと『ウェブ進化論』を勧めたところで、そもそも『あちら』側の存在に気づいていないことが多いため、まさに暖簾に腕押し、糠に釘である。ますます疎外感を強くしてしまう。このような事態に対応する術は、筆者が考える限り勉強会等に自主的に参加することのみであるが、首都圏ではともかくそれ以外では不可能に近い。関西圏在住である筆者は、勉強会を探してみたもののほとんど存在せず、社会人サークルのようなものばかりだ。Rubyの勉強会は存在するが、ターゲットが狭過ぎで、Webアプリケーションを包括するようなものは見つからない(存在するのであればぜひ教えてほしい)。関西圏でもこの有様である。他の場所では絶望的だろう。『あちら』側を目指す技術者が切磋琢磨する環境が、首都圏以外には存在しない状況は憂慮すべき問題なのではないかと思う。

アマゾンの「Best of 2006 和書総合ランキング」で「ウェブ進化論」が年間第四位に!!!

2007年03月13日

Library内のhasOwnProperty使用に対する補足説明

はてなブックマークで『ObjectをJSONへ変換するJavaScript Library』に対して次の様な突っ込みが入っていた。

json化するのにhasOwnPropertyじゃなくてfunctionかそうでないかくらいで十分な気がする

確かに説明不足な感は否めないので、補足。Functionオブジェクトはswitchの『default:』に振り分けられ、『case Object:』内は実行されない。では、『hasOwnProperty』は何のためにあるのか。著名なLibraryである『Prototype.js』等で、javascriptのnativeのObjectを拡張している。有用な機能を拡張しているため、便利ではあるが、手放しには喜べない。例えば、次の様な処理を考える。

//[for in]処理
var obj={"a":"apple","b":"box","c":"cat"};
var res="";
for(var key in obj){
res+=key+":"+obj[key]+"¥n";
}
alert(res);

/*
以下のように表示される。
a:apple
b:box
c:cat
*/

通常では上記方法で問題はないが、Objectを拡張している場合は問題となる。

//Objectの拡張
Object.prototype.f1=function(){return "function1";}
Object.f2=function(){return "function2";}
Object.prototype.v1="value1";
Object.v2="value2";

//[for in]処理
var obj={"a":"apple","b":"box","c":"cat"};
var res="";
for(var key in obj){
res+=key+":"+obj[key]+"¥n";
}
alert(res);

/*
以下のように表示される。
a:apple
b:box
c:cat
f1:function(){
return "function1";
}
v1:value1
*/

つまり、prototypeに拡張したクラスメソッドやクラスフィールドまで拾ってきてしまうのである(正確にはJavaScriptはクラスとは言わない)。『for in』処理はさほどマイナーな処理ではないため、既存システムのカスタマイズ時に『Prototype.js』を安易に導入すると、既存処理と衝突する可能性がある。これを一部では『Object汚染』と表現する。これを回避するために『hasOwnProperty』を使用しているのである。

//Objectの拡張
Object.prototype.f1=function(){return "function1";}
Object.f2=function(){return "function2";}
Object.prototype.v1="value1";
Object.v2="value2";

//[for in]処理
var obj={"a":"apple","b":"box","c":"cat"};
var res="";
for(var key in obj){
    //Object汚染回避
    if(obj.hasOwnProperty(key)){
        res+=key+":"+obj[key]+"¥n";
    }
}
alert(res);

/*
以下のように表示される。
a:apple
b:box
c:cat
*/

前述のLibraryのhasOwnPropertyは、この問題を回避するためのものであり、Functionの判定処理ではない。

ObjectをJSONへ変換するJavaScript Library

2007年03月17日

RFCの印刷を支援するBookmarklet

RFCをプリントアウトして読みたい事がある。ただ、IETF上のRFCはテキストファイルのため、ブラウザ上から印刷する場合、レイアウトが崩れてしまう。あまりにも面倒なので、RFCをレイアウトし直すBookmarkletを作成した。
対象ブラウザはFirefoxのみとなっている。A4サイズぎりぎりのため、余白の調整が必要だ。
また、他サイト上のRFCはレイアウトし直されている可能性があるため、IETF上のRFCでのみ動作するように制限をかけている。

IETF上のRFCを印刷しやすくするBookmarklet Ver1.0.1

/*
================================================================================
    Name        :   IETF上のRFCを印刷しやすくするBookmarklet Ver1.0.1
    In          :   [none]
    Out         :   [none]
    Note        :   IETF上のRFCを印刷向きに再レイアウトします。
--------------------------------------------------------------------------------
    Version     :   Ver1.0.0    |   2007/03/17  |   新規作成
                :   Ver1.0.1    |   2007/03/17  |   ページ分割処理を修正
--------------------------------------------------------------------------------
    License     :   MIT license
    URL         :   www.kanasansoft.com
================================================================================
*/

(
    function(){
        if((/^http:\/\/www\.ietf\.org\/rfc\/rfc[0-9]{4}\.txt$/).test(location.href)){
            var
                 d  =   window.document
                ,p  =   d.getElementsByTagName("pre")[0]
                ,c  =   p.textContent?true:false
                ,s  =   (c?p.textContent:p.innerText).split("\f")
                ,b  =   d.getElementsByTagName("body")[0]
                ,i
                ,q
                ,r
            ;
            while(b.hasChildNodes()){
                b.removeChild(b.firstChild)
            }
            for(var i=0;i<s.length;i++){
                q                   =   d.createElement("pre");
                with(q.style){
                    width           =   "7.5in";
                    height          =   "10.75in";
                    borderWidth     =   "0in";
                    padding         =   "0in";
                    margin          =   "auto";
                    fontSize        =   "14pt";
                    fontFamily      =   "monospace";
                    lineHeight      =   "14pt";
                    pageBreakAfter  =   "always";
                    pageBreakInside =   "avoid";
                }
                r                   =   s[i]                                        .
                                        replace(    /^\n/ig     ,   ""          )   .
                                        replace(    /[ \n]+$/ig ,   ""          )   .
                                        split(      "\n"                        )   .
                                        slice(      -55                         )   .
                                        join(       "\n"                        )   ;
                if(r!=""){
                    if(c){
                        q.textContent   =   r
                    }else{
                        q.innerText     =   r
                    }
                    b.appendChild(q)
                }
            }
        }else{
            alert("don\'t match \n[RFC] of IETF site")
        }
    }
)
()

ときどきではない。大方がだ。

なんというか、まあ、そういう業者いますね。ときどきですが。

高木浩光＠自宅の日記 - RFID児童登下校管理システムのクオリティは安心安全ソリューションってレベルか

どれだけ問題を抱えているシステムであろうと納期までに間に合わせ、納品後に発生した不具合は継ぎ接ぎの対応で凌ぎ、瑕疵期間が過ぎるまで粛々と待つ。そんな会社・開発者がどれほど多い事か。
ときどきと書くのは、業界を全く理解していないか、あえて皮肉かのどちらか。高木氏が知らないはずがないので、あえて論議を起こさせる為に煽っているのかもしれない。

2007年03月18日

プログラマに拘束時間は必要か

プログラマの勤務は如何にあるべきか。現場を知っている上層部がいる会社ではフレックス制を導入している場合が多いだろうが、そうではない会社も多いと感じている。

IT産業は文字通り産業化してしまっており、既存の勤務体系内にあわせ定時出社・定時退社(もしくはそれを拡張したフレックス制)が設けられている場合があるが、そもそもプログラマはこの様な制度に押し込めるべきではないのではないだろうか。

そもそも、プログラミングというのは執筆活動に近い。それも雑誌や新聞等の執筆ではなく、小説や漫画等に近いだろう。つまり、9時に出社し作家に小説を書かせ17時まで拘束したところで、まともなものが書けるだろうか。本当に良い小説を書いてもらいたいのであれば、拘束などはせずに本人の自主性に任せるべきではないだろうか。締め切り(つまり納期)に間に合うかどうか非常に気になるだろうが、納期の調整は担当者(この場合プロジェクトマネージャ)の仕事ではあるが、本来現場の仕事ではない。

もちろん、自由奔放にして全く出社しないというのは問題だし、納期を全く気にしないというのも問題だ。しかし、プログラミングは乗っているときには一気に進むが、乗らないときには全く進まない作業のため、拘束時間を設けるのはそもそも本質的ではない。フレックス制度というのは、旧来の勤務体系に比べるとまだマシだが、まだまだ不十分と思う。

2007年03月 アーカイブ