二流プログラマの三流な日常

会社を辞めて思うこと

去年、会社を辞めた。
良い仕事が見つかったというより、今後の生活が追いつめられた感じ。

暫くたって思う。もう戻れないんだなと。
ここを見てる数少ない、友人へと贈る、本音と近況。

まぁ、私信。みても得はしない人が多数。

電車の中では相変わらず、プログラマ向けの本ばかり読んでいる。時間があけば、ＩＴの掲示版や記事を見つつ、笑っている。そして、時々、掲示版に書き込んでみたりするのだ。何もかわっちゃいない。そして、その反応１つ１つに勉強させられている。

それにしても、日本のＩＴは何処まで落ちぶれていくんだろう。ＩＴが嫌われる仕事になってしまってから、はや５年。私の見ていた優秀な人材も、足を引っ張り合った結果、やる気を削がれ、輝きを失っていく。同じ職場で競って何になるんだろうか？

そういえば、ＩＰＡのお偉いさんが「ＩＴは面白い、誤解されている」と言っていた。その通り。非常に面白い。ただ、少なくとも私がみた職場にその楽しさはなかった。低賃金と過酷労働だけ。未経験者歓迎で募集して人材不足なのが良い証拠。

ＩＴは、頭の良さや知識より、興味が要求される世界。仕事がないからＩＴやってみるかくらいでは、耐えられない。結果、Google検索や掲示版を駆使して、問題を解決したり、プログラムを動かしたりする。普通の管理職は、その善し悪しは判断出来ない。だって年功序列の管理職世代に、今のＯＳやプログラムが分からないのは当然だし。そしてまた、低賃金の未経験者を雇うわけだ。何がいいたいかというと、進化の速いＩＴ業界と、年功序列は相性が悪い。ただそれだけ。

出来ない人がクビにならないのは、日本企業にＩＴが向かない決定的なの理由。それを見た優秀な人が、仕事の手加減を覚えてしまい、外国の優秀な人材とは差が付く一方。実は、ＩＴの仕事は手を抜き放題。ちなみに、海外では情報学科でないと、高賃金なＩＴの仕事にありつけない。院卒が普通なのだから、私の思い違いではないだろう。

結局、プログラマを給与の面から去ったのが自分。今、フリーで年間８００万だすという人間がいようが、１０年後、同じ事を言ってくれる保証はない。保証のある仕事に逃げただけ。

そして今、電気回路とかも眺めている。能力は皆無だが、面白い。パソコンを知らなかった頃、１０年前を思い出す。ついでではあるが、これまでの能力も必要とされているのだ。しかし、これを天職だとは言えない。やっぱり私はＩＴ技術者が大好きだったのだ。

これからもひっそりと頑張っていこうと思う。まだまだ、負けるわけにはいかない。

.NET Framework のリソース開放基礎（２）

.NET Frameworkのリソース開放は非常に難解です。

今回は重要メソッドである以下の２つについて説明します。

・Dispose（リソースを開放できるメソッド、自動で呼ばれることはない）
・Finalize（リソースを何時か開放するメソッド、自動で呼ばれる）

実装時の注意点は以下のとおりです。

■ Dispose

• Disposeは複数回呼ばれる可能性があるし、その場合に例外なしに呼び出せるよう実装しなくてはならない。
• DisposeとFinalizeは殆ど似たような開放処理になる。しかし、アンマネージリソースの一部は、Disposeの実装とその呼び出しでしか開放できない。
• DisposeとFinalizeを両方実装した場合、Dispose内でGC.SuppressFinalizeをする（パフォーマンス上の問題）

■ Finalize

• スレッドセーフに実装する必要はないし、複数回呼ばれることはない（ＧＣがファイナライザを実行するスレッドは 1 つだけであることを保証している）。
• Disposeが呼ばれなかったときの対策としてリソース開放を任せることができる場合がある。アンマネージリソースの大半はFinalizeの実装で開放できるため、予防線として開放処理を実装すべき（IDisposableなオブジェクトでDisposeを呼ばなくても、リークにならない場合があるのはFinalizeのおかげ）。
• Finalizeは必ず呼び出されるわけではない。スレッドの停止等、特殊な条件で呼ばれない事がある。
  →つまり、OSに関連する重大なリソース（HWNDやHDC等）の開放はFinalizeに頼るべきではない。（これについては後述、CERにも関連）。
• Finalizeを実装するとリソースの破棄に時間がかかる(Finalization Queue)

ここまではしっかり覚えておくべきです。

ついでに.NETのリソース利用におけるガイドラインを少し。

• GCが管理できないリソースの開放は難解である。だから、アンマネージリソースにSafeHandleやCriticalHandleを使える場合は必ず使う。私たちが想像がつかないようなケースにも対応している。
• 同様にGCが管理できないリソースを利用するのも難解である。GCHandle等のクラスはそれにも対応するので、自前でIntPtrなどを使うことは安全なリソース開放のためにもなるべく避けるべきである。

さて、メソッドやファイナライザによるリソースの破棄が完全に保障できない以上、サーバ系プログラムはどうすべきなのでしょうか？

Microsoftのだした１つの回答はCER(Constrained Execution Region)になります。
これについては次回。

---

[MSDN] CLR Inside Out Digging into IDisposable -- MSDN Magazine, July 2007