Webアプリでよくある要求に、ボタンの二度押しをしてほしいというのがあります。
これは、ボタンを二度押すことによってリクエストが二回発生してしまい、データが二重に登録されるのを防止するためです。

よくある手法がJavaScriptでボタンを無効にしてしまう方法ですが、JavaScriptは設定で無効にできるため、サーバサイドでチェックを行うこともあります。

で、実際にJavaScriptで実装しているサイトを調べてきました。

[CodeZine]JavaScriptを利用してフォームの二重送信を防止する

この方法は画面をフリーズさせるので、視覚的にも分かりやすいと思います。

[手抜きぷろぐらまのメモ帳]ASP.NET & JavaScriptでコード汚染をしないで2度押し防止

タイトルにASP.NETとありますが、実際にはHTML上にSCRIPTタグを入れるだけなので、環境は何でもOKです。
スクリプトはjsファイルにしてしまえば再利用の効率も良くなりますし、ボタンだけでなくリンクなどにも効いてくれるため、大変使いやすいと思います。
アスペクトは便利ですねえ。

デブサミで大好評だった「JavaScriptの現在と未来」の資料が公開されました。

デブサミ2007資料「JavaScriptの現在と未来」

セッション資料をJavaScriptで作っているというのが、実に漢だと思いました。
内容も素晴らしいですね。
JavaScriptって、こんなことできたのかあと驚くことばかりで、JavaScriptへの見方が少し変わりました。

最近アーキテクトという言葉を目にするようになってきました。
先日のデブサミ2007でも、カテゴリにアーキテクトがありましたし、これも時代の流れなんでしょうか。

個人的には、アーキテクトが見直されるようになったことは大きな変化だと思います。
アーキテクチャ不在によるプロジェクトの破綻が少しでも減ってくれればなあという期待の半面、ダメなアーキテクチャを作って失敗するプロジェクトなんかも出てくるのかもしれません。

いずれにしても、今後の動向を見守っていきたいということでカテゴリを追加しました。

というか、作ってあったのですが公開忘れてました orz
公開したバージョンは1.0.1用です。
1.0.0版は作ってませんが、大体同じなので勘弁してください。

namespaceのヘルプが作成してないですが、気にしないでください（滝汗）
次のバージョンではちゃんと入れるようにします（ナイアガラ滝汗）

先日のデブサミ2007で萩原さんの話している内容が自分の考え方に似ているなあ（O/Rマッピングとか）と感じていたのですが．．．

私がもの凄く参考にしている、ITアーキテクトの記事を書いたのが、なんと萩原さんでした。
かなり記事の影響を受けていたので、そりゃ似てて当たり前だなあと。

弁慶1.1あたりで、リクエストのキューイング機能を入れようかと思ってます。
現状のままだと、リクエストの投入だけしたいという場合に独自実装が必要なんですが、キューイング機能を加えることでより作りやすくなると思います。

頭の中ではもう出来ているのですが、優先順位的にConfigGenerator、ドキュメントを優先したいので後回しにします。
実質１人で作ってるので、なかなかマルチタスクで作るのは難しいです。

デブサミ2日目です。

今日は2つ目のセッションから受講予定だったのですが、早めについたので空いていた「徹底討論：日本のIT技術は世界一になれるか？」を聞いてみることに。
昨日から薄々気付いていたのですが、人気の無かったセッションが意外と面白いんですね。
人気のあるセッションの多くはタイトルのインパクトが強いんですが、実は商品説明な場合が多くて、期待はずれが多かったように思いました。

でも、さすがGoogle、「Googleを支える大規模分散システム / Google における開発プロセス」の内容は秀逸だったとのこと。
Googleと言えば、止まらないシステムで有名ですが（過去には火事になっても止まらなかったこともあり）、サーバが数万台あるので、常に何パーセントかは故障しているとかって話もあったようです。

午後はコミュニティライブを2つほど覗いてみました。
オブジェクト倶楽部さんのライブは討論会みたいな流れでしたが、Judeでマインドマップを書きながら進行していたは新鮮でした。
Judeっていいね、明日ダウンロードしようっと。

そして締めくくりは「対談：ITアーキテクト大解剖」を受講。
例によって空いていた訳ですが、これが大当たりでした。
アーキテクト３人が討論するというものなんですが、進行役の鈴木雄介さんに対して、マイクロソフトの萩原正義さん、建築家の大川信行さんという異色の組み合わせ。
アーキテクトとか、デザインパターンって建築用語から来ているわけで、抽象的なモデリングを重視するあたりは共通点も多く、目からウロコでした。
全体を通して、建築家の大川さんの存在が大きかったと思います。
大川さんがいたことで、あまりテクニカルな話にならず、バランスの良い流れになったように感じました。
また、建築という視点から見た世界の話を通して、何かがつかめた感覚があります。
企画した鈴木さん、ナイスです！

そして、マイクロソフトの萩原正義さん、この方は凄い思考回路を持っています。
正直、神だと思いました。
萩原正義さんが最近捨てた技術に「O/Rマッピング」を挙げたときに笑いが起こりましたが、実は私も弁慶フレームワークで悩んだ末に「O/Rマッピング」を採用しなかったので、あながち間違ってなかったのかな？とホッとしてみたり。
エンジニアとして生きてきた中で一番勉強になった１時間半を挙げるとするなら、確実にこのセッションだったと言い切れる、そんな有意義なセッションでした。

昨日の夕方、突如言われた「デブサミ、行きたかったら行ってもいいよ」の一言で慌てて申し込んだのでした。

Developers Summit 2007
一応言っておくと、デブのサミットではないです。技術者のサミットだそうです。

そして、今日が1日目。
残り時間が１時間切ったところで申し込んだため、人気のあるセッションは予約できず。
本当なら、「JavaScriptの現在と未来 ～今JavaScriptに出来ること / 次世代JavaScriptの勢力図～」を見たかったのですが、凄い人気だったそうで無理でした。

他のセッションは企業広告の色が強く出ていて、技術習得が目的の人にはつまらなかったかも。
そういう意味では、Seaser2の話なんかは面白かったです。（なぜか人気が無かったようですが）

セッションがどうかと言うより、帰りが土砂降りで鬱になりました。
あと、予想以上の人数でちょっと人酔いしたかも。

2日目の日記に続きます。

個人情報テスト用データを一気に5000件出力する「なんちゃって個人情報」

個人情報を5000件まで自動生成してくれる無料サービスのようです。
個人情報の漏洩対策として、実データのテスト使用ができなくなっており、テストデータをどうやって作ろうかというのが課題だったりします。

解決策として自動生成というのがある訳ですが、このサービスの場合、統計に基づいた比率でデータを出力するという本格派です。
出力項目の最後に「カレーの食べ方」というのがあり、なんかよく分からんけど、思わずクスッと笑ってしまう感じですね。

グラフィカルなグラフを描画するJavaScriptライブラリ「Plotr」

これは凄いライブラリです！
「Plotr」は、Prototype.jsを利用したJavaScriptライブラリで、「HTML Canvas」を利用しており、ブラウザはFirefox 1.5以上、Opera 9.0以上、IE6以上に対応しているとのこと。
早速サンプルを見てみると、大変美しい棒グラフが表示されました。
グラフ好きには堪らない一品と言えそうです。
しかも、ソースコード量も想像していたより、かなり少ない量で書けてしまいます。

株価チャートを作ってみようかなあと思っていたので、ちょっとやってみようかなと思ってみたり。

大量のAjax関連リンク集

「あるＳＥのつぶやき」さんで紹介されていたのですが、本当に大量のAjax関連リンク集でした。
英語のページなんですが、きちんと分類されているので、目的の情報を探しやすいんじゃないかと思います。
Ajaxだけでなく、Javascriptだけのページも分類されているようです。

なんとか1.0.1をリリースできました。
ついでにDAOGenerator1.0.0もリリースできたので、よかったらダウンロードしてみてください。
次のリリースでbenkei.config、コントローラクラスを生成するツールを作る予定です。

https://sourceforge.jp/projects/benkei/

TeraStationが故障したりとか、TeraStationが故障したりとか、TeraStationが故障したりとかでトラブル続きで作業が遅れていた訳ですが。

本日ようやく完成にこぎつけました。
機能としては、
・SQLServerからテーブル情報、フィールド情報を取得して、その情報を基にソースコードを自動生成する。
・SQL文からソースコードを自動生成する。
の２点です。

このDAOGeneratorを使うことで、C#の開発がよりスピーディー、高品質になることを願っています。
現在はC#だけですが、VB.NET版も開発予定ですし、対応DBもPostgres、MySQL、Oracle、DB2あたりまで対応させたいなあと思っている次第です。

公開はドキュメントを少し整理してからとなりますので、もう少しお待ちください。

最近、コーディングルールいらなくね？とか思っているのですが。
というか、アホなコーディングルールなんてうんざりだ！

まず、コーディングルールのメリットと思われている部分って、大体こんなところでしょうか。
あまり思い浮かばなかったので、他にもあるよって人は教えてください。
・作り方を統一することで、メンテナンス性が向上する。
・コードのサンプルを読むことで、全員のレベルを一定水準まで上げることができる。

そして、その運用結果は大体こんな感じになったりします。
・コーディングルールが、特定メンバが好きなルールの押し売りになっている。ベテランが作ることが多いので、時代遅れなコードの場合がある。
・コーディングルールが気に知らないとかで、メンバ同士が大喧嘩。
・技術力の低いメンバが作成してしまい、全員のレベルを下げて開発するハメに。
・プロジェクトがハマってしまい、どんどん人が入ってくる。納期間近でコーディングルールどころではないってことで、ルール無視。
・協力会社のメンバとかが、「どうせすぐいなくなるんだし、適当でいいや」と、ルール無視。
・業務のパターンが複雑で、コーディングルールが対応できなくなる。
・サンプルコードの品質に問題があったため、全体のコードがえらいことに．．．

ええっ？と思うかもしれませんが、私はこういう場面にかなり遭遇しています。
というか、全く無いってことは一度たりともありませんでした（泣）
基本的に、みんな自分のやりやすいようにやるのが一番開発効率が良いと思っているんじゃないかと思うんですよね。
だから、コーディングルールが弊害となる。
それなら、コーディングルールいらなくね？という結論になったわけです。

でも、さすがに全く何もなく、「全員適当に開発しといて～」って言う訳にもいかないので、別の方向性で考えてみたいと思います。
・システムの方向性、アーキテクチャを決めておく（方向性の確保）
・絶対やってはいけないことを決めておく（アンチパターン）
・誰かのコードを直すときは、その人の書き方に合わせる（平等）
・コメントを詳しく残すようにする（マナー）

と、このくらいでいいのではないでしょうか。