[Effective C#] 項目35 イベントハンドらよりもオーバーライドを優先すること

本当に日が空きました。一月から新しいお仕事です。難易度がむっちゃ高いので復習の意味も込めて Effective C# の紹介再開です。

本日の Effective C# は「項目35 イベントハンドらよりもオーバーライドを優先すること」です。

たとえば、Form が開かれた時の処理を、Form.Load イベントに登録するか、または Form.OnLoad() メソッドをオーバーライドするかの二種類の手段があります。

デザイナで作業しているとついついイベントで処理していますが、これはけた方がいいというお話です。理由として以下のものがあげられています。

プログラムの作成は足し算でやる

tag: 

プログラムの作成は足し算でやるべきだというのがここ数年思っていることです。まあ、自分で導き出した結論ではないのですが。

足し算というっても数学的な足し算じゃなくて、レゴブロックみたいな感じでしょうか? 機能追加は新しいパーツを別途作って追加することで行います。ということは、外すのも別の機能への差し替えも簡単なわけです。

当然、こんなことしなくても、ソースコードを直接修正すれば、機能追加も機能削除もできるんですが。

「ソースコードを修正するとバグが生まれる」という原則を考えたら、ソースコードへの修正は最小限にとどめたほうがよい。だからと機能追加というのは、ソースコードの修正ではなく、追加によって行うべきというのがあるんです。

まあ、この手の話はいろんな本に書いてあるんですが、正直よくわからなかったですが、いろいろと仕事でプログラムを書いてるとなるほどなーと思うようになったわけです。

もともと動いてたのは動いているわけですし、機能追加でソースコードを修正しないなら、原則として今までの部分は確実に動くわけです。バグがあってもどっちが原因かわかりやすいし、一時対策として機能追加分を外すのも簡単です。

JRuby って SDBM が使えない?

tag: 

標準ライブラリだということでどこでも使えると思ったので使ったんですが、SDBM。JRuby だと使えないような感じです。

$ ruby -rsdbm -e 'puts "foo"'
foo

普通はこんな感じです。

でも、JRuby だと

$ jruby -rsdbm -e 'puts "foo"'
Exception in thread "main" :1: no such file to load -- sdbm (LoadError)
        ...internal jruby stack elided...
        from (unknown).(unknown)(:1)

こんな感じ。いろいろ調べたんですけど、理由はよくわかりませんでした。JRuby と Ruby に関する互換性のレポートくらいあってもよさそうなんですが、発見できませんでした。

というわけで、PStore に変更です。

ブログをホストしているサーバーを移行しました

最近忙しいです。あまりいろいろする暇がありません。

それはそれとして、借りている ServersMan@VPS も無償期間を過ぎたのに全くいろいろな検証もすんでなくて、放置気味だったのですが。さすがにもったいないということで利用を開始することに。

まずは、自宅サーバーで運用していたブログの移動から。

なんやかんやで苦労しましたが、まあまあ順調に稼働しています。

移すついでに、mod_php をやめ、suEXEC/FastCGI 化しました。

今のところ問題なく動いていますし、VIA Esther 1.5GHz に比べたら無茶苦茶速いです。一番安いプランなので、メモリは 256MB ほどしかありませんが、意外と動くもんです。

多分、重い時間とかあった気がするんですが、それがなくなりそうです。

うーん、今日は全然中身がない日記でした。

IIS Express

tag: 

なにやら IIS Express というものが出るようです。

Introducing IIS Express とその翻訳記事、IIS Expressの紹介

IIS のほとんどの機能を持つ Web Server が、ASP.NET 開発サーバーと同様に動くってことです。これは大変ありがたいのです。

ASP.NET 開発サーバーはいろいろとプアですし、(IIS のモジュールが動作しませんし、CGI も確か動きません) でもユーザーアカウントで動作できるので大変便利です。

IIS Express は ASP.NET 開発サーバーと同様にユーザーアカウントで動作します。しかも CGI やらもいろいろ動くみたい。IIS と違って管理者権限がないと設定できなかったりとかもない。

[LINQ レシピ] Cast() メソッド

LINQLINQ to SQL ばかりが取り上げられ、微妙に敬遠されている感じがありますが、個人的には LINQ to Object は使わない手はないと思っています。

わりとしょっちゅう使うので、練習がてら一つ一つレシピみたいな感じで紹介していこうかと思います。

というわけで、本日は Enumerable.Cast() メソッドです。

名前の通り、キャストを行うだけです。

moq は Visual Basic 9.0 では使い物にならない

先日 moq で紹介したモックオブジェクトフレームワーク moq ですが、どうも Visual Basic 9.0 では使い物にならないようです。

たとえば、C# では以下のように書けますが、

moq

moq とは、.NET Framework 3.5 以降用のモックオブジェクトフレームワークです。

NerdDinnerステップ12:単体テスト等で、あの Scott Gu 氏が使っているので興味がわきました。

この手のモックオブジェクトフレームワークでは NMock が有名だと思うのですが、moq は、これらのものと違い、.NET Framework 3.5 で追加された機能をうまく使うことで、より使いやすいものとなっています。

Visual Basic は C# に比べると見づらいと思う

tag: 

個人的な見解だし、慣れの問題もあると思うんですが。

Visual Basic で書かれたコードと、C# で書かれたそれを比べると、前者の方が見づらい感じがします。

[Effective C#] 項目34 粒度の荒い Web API を作成する

日があいた…。

本日の Effective C# は「項目34 粒度の荒い Web API を作成する」です。

ずーっと「つぶど」って読んでましたが…。

それはおいておいて、ASP.NET Dynamic Data とかを見てると疑問に思うことがあります。一つの画面を表示するのに必要なエンティティの数は結構多いです。Web Service 経由で直接 DB とやり取りしてしまうと、複数のトランザクションで処理がなされてしまうわけで、いろいろと不整合が起きたり、ロールバックとかが面倒だったりしないかな? ってこと。

この項目では、こういった粒度の細かい API じゃなくて、荒い API を用意せよと言っているわけです。私の考えは間違ってなかったのかもしれないです。

その理由としては、粒度が細かいとパフォーマンスの低下を招く恐れがあるとされています。電話での注文と、FAX での注文にたとえられ、Web API は FAX のようなもの、とされています。

ここからは個人的な見解になります。

ページ

まさくらのブログ RSS を購読