2010/12/31(Fri)冬コミの記録
2010/12/17(Fri)こわくない
こう、毎日のうのうと生きてられればいいなぁって、僕は思う。
一生というチョー短い限られた時間の中で、
一人の人間ができることなんてたかがしれてる。
気張ってもしょうがない。張り詰めてもしょうがない。
自由に気ままに生きていられる方がずっといい。
でも、その一生をチョー短いって感じるのは、
やっぱり「あれもこれもしたいから」なのかな。
2010/12/14(Tue)デザインパターンなんて勉強しなくてもいい?
デザインパターンは誰かとプログラムを組むときのコミュニケーションの手段になる。
でも、誰かと協力してプログラムを書くのでなければ、それは必要ない。
本当にそうだろうか。
もしあなたが一人でプログラムを書いていたとしても、
30分前のあなたと協力しなくてはならないし、
1時間前のあなた、3時間前のあなた、昨日のあなた、
先週のあなたと協力しなくては、大きなプログラムは完成しないだろう。
誰かと協力しないでプログラムを組むなんてコトはそうそうない。
誰かって言うのは、文字通り他の誰かかもしれないし、来週のあなたかもしれない。
常に相手にわかりやすいプログラムを書くっていうのはやはり重要だと主張したい。
環境がどんどんよくなっている今の時代では、
覚えておかなきゃいけないことも変わってきているように思う。
関数の使い方は都度IntelliSenceが教えてくれる。
オブジェクト指向やポリモルフィズムがプログラミング言語に取り入れられて、
同時に大量のシンボルや変数に注意を払う必要もなくなっている。
バグは減り、生産性をあげることができている。
忘却の時代。OOPのイディオムやデザインパターンがそれらを支えている。
言語が道具であるのと同じで、デザインパターンも道具であるとは思う。
ある「実現したいこと」がオブジェクトコンストラクタでが十分なのなら、
わざわざFactoryを使う必要もないが、それではできないこともある。
そういうときに、パターンを知っていれば近道ができるという程度のもの。
それはパズルの解法の一つになるのではないかと。
便利だと思ったら使えばいいし、そう思わなかったら勉強しなくてもいいのかもしれない。
それでも、パターンに沿った教科書通りの実装というのは理解しやすいものだ。
ゲームを作るときだって、お決まりのアルゴリズムがあるのと同じぐらいおきまりのパターンがあるのだ。
たしかに、そのパターンに名前はついていないかもしれないけれど、
それをデザインパターンと呼ばずして何と呼ぶんだ。
2010/12/14(Tue)かんじょーろん
2010/12/13(Mon)ICPC 2010 アジア地区予選 東京
12月11日から13日まで、選手としての最後の参加になるであろうICPCのアジア地区予選東京大会に行ってきました。
参加記録というか日記というか備忘録というか、むしろgdgd書き。
2010/12/10(Fri)ICPC 前夜 の Magical Festival
あのゲームを対人戦(専用)にしてみたら結構アツかった。
Download: Magical Festival in yukatama.zip
Windows / .NET Framework 2.0 / Managed DirectX 1.1