プログラミング Archive

既に2か月分ほど原稿を書いてあるので、いつでも発行できるのですが．．．

まぐまぐによると、発行するメールマガジンが、ウィークリーまぐまぐで紹介されるのが、5/12とのことでした。
その後、3～4日ほどで読者が急増する傾向があるようです。

メルマガは、最初のスタートダッシュが成功すると、新着ランキングに載ったりして、順調に成長できるケースが多いので、勝手ながら19日に延期した次第です。

12日の発行を楽しみにしていた方、どうもすみません。

ブログで告知したおかげもあって、読者が少しずつ増えており、大変嬉しく思っております。

• 誰にでもできる！インターネット活用術　…　SEOの話題を中心として、インターネットを活用したビジネスの考え方などを紹介しています。


• 誰にでもできる！システム開発　…　ＩＴエンジニア向けに、システム開発で失敗しないやり方を中心にお話していきます。

いつもブログを見ていただき、ありがとうございます。
今回は告知なんですが、是非ともご協力いただけますよう、お願い申し上げます。

2008/5/12（月）に、以下の２つのメールマガジンを創刊することになりました。
既にまぐまぐさんの審査も合格し、あとは12日を待つだけとなりました。

無料で購読できますので、少しでも興味がありましたら、ご購読いただけると嬉しいです。

• 誰にでもできる！インターネット活用術　…　SEOの話題を中心として、インターネットを活用したビジネスの考え方などを紹介しています。
• 誰にでもできる！システム開発　…　ＩＴエンジニア向けに、システム開発で失敗しないやり方を中心にお話していきます。

いずれも、私がエンジニアやコンサルタントとして経験してきたこと、勉強してきたことなどを、初心者の方でも分かりやすいように説明しています。
ただ説明するだけでなく、問題提起やクイズも取り上げていきますので、読んでいるだけでパワーアップできること間違いなしです。

あるＳＥのつぶやきさんのところで紹介されていました。
[あるＳＥのつぶやき]BugTracker.NET － .NETベースのバクトラッキングシステム
大変興味深い記事です。

元ネタは@ITから
[@IT]オープンソースのバグトラッキング・ツール「BugTracker.NET」を使う

　Visual StudioのユーザーならTeam Foundation Serverという選択肢もありますが、本稿で紹介するBugTracker.NETは大規模なアプリケーション構築のための重厚なツールというよりむしろ、バグの報告と修正状況の管理に特化した非常に軽いツールです。

　また、オープンソースのWebベースのツールでは、PerlやPHPなどで記述され、データベースにはMySQLが前提……といったものが多いのですが、このBugTracker.NETは、ASP.NETによるWebアプリケーションで（ロジックの記述はC#）、バックエンドのデータベースにはSQL Server（Express Editionも利用可能）を使用しています。このため、マイクロソフト・テクノロジに精通したプログラマーにとっては動作環境に特に前知識を必要とせず、インストールや運用がとても楽に行えます。

　残念ながら日本語対応はされていないので、ドキュメントやブラウザで表示される内容が英語になってしまいますが、列見出しの「タイトル」が「Title」と表示される程度なので、ほとんど問題にならないでしょう。

デモを試してみる場合は、こちら
BugTracker.NET - logon

最新のソース、実行ファイルは、こｔら
[SOURCEFORGE.NET]BugTracker.NET

まだ少し触ってみた程度ですが、ASP.NET + SQLServerで実装されているので、ちょっといじってみたい人には最適かもしれませんね。

おおっ、と思うニュースでした。

マイクロソフト、.NET Frameworkライブラリのソースコード公開へ

　米マイクロソフトは10月3日（現地時間）、Scott Guthrie氏のブログで、.NET Frameworkライブラリのソースコードの一般公開を発表した。今年後半の、.NET 3.5／Visual Studio 2008（以下、VS 2008）のリリースと同時に公開する予定だ。

　初めは、ベースクラス（System.IO、System.Netなど）や、ASP.NET（System.Web）、Windowsフォーム（System.Windows.Forms）、ADO.NET（System.Data）、XML（System.Xml）、WPF（System.Windows）のライブラリから提供を初め、続けてWCFやWorkflow、LINQなども公開していくという。

　ソースコードは、マイクロソフトリファレンスライセンス（Ms-RL）で提供される。

　また、ソースコードはダウンロードしてエディタで閲覧できるだけではく、VS 2008における統合的なデバッグのサポートも予定している。

　たとえば、GridViewのDataBind()の呼び出しにブレークポイントを設定した際、従来までは、DataBind()内部での動きの詳細は確認できなかったが、VS 2008ではステップインで.NET Frameworkライブラリ中のコードもデバックできるようになる。［ローカル］ウィンドウや［ウォッチ］ウィンドウで変数を監視することも可能。また、.NET Frameworkのソースファイルは、必要に応じてデバッグ時にオンデマンドで取得するため、あらかじめ全てのファイルをローカルにダウンロードしておく必要はない。

　マイクロソフトでは、.NET Frameworkライブラリのソースコード公開とデバッグの統合は、.NET開発者にとって非常に価値のあることであり、よりよいアプリケーション開発の手助けをしていきたいとしている。

確かに、デバッグ中にライブラリの先が見たいときはありますよね。
今まではソースが無くてもなんとかなったので、必須という訳ではないですが、無いよりはあった方が良いですね。

Sandcastle 2007 Juneがリリースされていたので、入れ替えました。

手順は簡単で、アンインストール後、新たにインストールすればOK。
ついでに、SandcastleBuilderの最新版(1.5.0)を入手。
過去のSandcastleBuilderプロジェクトも、そのまま読み込めて実行できました。
どうやら、いつのバージョンからか分かりませんが、Namespaceの説明も設定できるようになっていたようです。

ということで、弁慶のHTMLHelpは今後これで作っていこうと思います。

可読性を上げるためにコメントを入れることは当然なのですが、ただコメントを書くだけでなく、書き方にも工夫してみようかという試みです。

例えば、

	// 社員登録

	社員マスタ.Save();

なんてコードがあったりします。
まあ、よくあるコメントですね。

では、この例ではどうでしょうか。

	// 入力データを社員テーブルに登録します。

	社員マスタ.Save();

少しコメントに温かみがあるような気がしませんか。
なぜかというと、文章で説明しているからです。
例えばコメントが一切書かれていないとき、コードの意味を作った人に聞いてみるとします。

「これってどういう意味ですか？」
「社員登録」

こう言われると、意味は分かりますがなんか気分良くないですよね。
それでは、次のケースではどうでしょうか。

「これってどういう意味ですか？」
「入力されたデータを社員テーブルに登録しています。」

こっちの方が普通の会話ですよね。
コメントというのは、自分以外の人がコードを見たときにきちんと理解できるように入れるものですが、理解できればそれで良いというものではなく、優しく語り掛けてあげるような書き方をすることで読む方も気分よく仕事をすることができるようになります。
「あいつのコード読みたくないんだよなあ」と思いながら仕事をするより、「あいつのコードを読むのは面白い」と思われた方が作業効率も違ってきます。

この僅かな気持ちの差は、長い期間で大きな差となってくるでしょう。
面倒くさいかもしれませんが、「ですますコメント」をやってみてはいかがでしょうか。

ちなみに、弁慶フレームワークは「ですますコメント」で書かれています。
弁慶フレームワークの半分は愛情で作られています（汗）

ある理由から、意味の分からないソースコード（C#）を読んでいます。
資料はそれなりに揃っているものの、ソースコード上にコメントがほとんど無く、資料と整合性が合っていない場合、なぜ違うのかが全く分からないんですよね。
かなり苦戦している訳ですが、せっかくなので、なぜ読みにくいコードになっているか考えてみようと思います。

簡単に思いつくあたりでは、
・コメントが圧倒的に足りない。というか必要なところになく、役に立たないコメントだけ存在。
・「とりあえず動けばいいや」的な場当たりな作り方。
・間違った共通化。共通ロジックの呼び出し方が暗号みたいな作りになっていた。

と、こういうのは大体どこにでも存在するコード（泣）で、どちからというとマナーみたいなもんなんですが、果たしてこれが解決すると読みやすいか？というと、そうでもない気がしてきました。
根本的な問題があるのはプログラムの構造で、モジュール分割や機能と実装の分離が正しく行われていないことが原因だと思います。

特に重要だと思うのが、機能と実装の分離です。
例えば、機能説明に「検索ボタン押下時に受注情報を取得する」と書いてあるのに、その処理を示すメソッドが「SelectOrder」となっていたとします。
これは最終的な結果から見ると正しい動作になっていますが、構造では欠陥があります。
つまり、「受注情報を取得する」をしたいときに、何故「SelectOrder」なのか関連性が不明だからなんです。
（この例は単純な例なので容易に想像できちゃいますが．．．）

検索ボタン押下→SelectOrder

ではありません。
この場合は、

検索ボタン押下→Get受注情報→SelectOrder

とすべきです。
なぜなら、機能説明に忠実に作成するなら、検索ボタン押下に要求される機能は「受注情報を取得する」ことだからです。
そして、「受注情報を取得する」ための実装として「SelectOrder」が呼ばれます。
このように、機能と実装を分離すると、もし実装が変わっても（例えばデータベースが変わるとか）、ボタン押下イベント側には影響が出ません。
また逆に、ボタン押下イベント側から利用する際にも、どんな実装をしているかを気にせずに呼び出すことができるようになります。

さらに付け加えると、ボタン押下イベント側から呼ばれるメソッドは、機能を表す名前をつけることが望ましいです。
なので、この例でも「受注情報を取得する」のような機能の場合、動詞を前に出して「Get受注情報」としています。

他に気をつけるべき点として、メソッドを単一機能に限定することが挙げられると思います。
つまり、メソッドの説明をするときに「このメソッドは○○と××をします」のようになってしまうのは問題があります。
正しくは、「○○をする」メソッドと、「××をする」メソッドの２つのメソッドに分割することです。
そうすることにより２つの機能が独立するため、単純な構造になります。

実はこういう事を言うと、「こんなことをしたら、クラスやメソッドがいっぱい増えて、処理が遅くなってしまう」と反論する人がいます。
これはある意味では正しいと言え、実際にクラスやメソッドが増えるし、処理も遅くなります。
しかし、オブジェクト指向言語を選択した時点で、パフォーマンスが最重要課題でない（最重要課題ならC等を選びましょう）ため、例えば0.01秒掛かっていたのが0.02秒になったとしても、実際にほとんど影響が無いと言えます。（それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう）

確かにわずかながらデメリットはありますが、システムの将来を考えると、より可読性の高いコードを生産する方が価値が大きいのではないでしょうか。

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

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

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

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

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

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

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

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

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