設定ファイル!=ソースコードor設定ファイル==ソースコードという文化と違和感

　某所のDI系設定ファイルに関してconfigファイルをjavaで書くスタンス「も」とれるという話について。
　僕が感じたのはDIに限った話ではないので的外れかも。

　設定ファイル＝ソースコードという文化は元々、C/C++などのマクロを持つ言語、もしくはPerl、PHP、PythonなどのLL言語が持っていた文化だと考えた。
　Javaはむしろそれを否定してきたように見えるし、設定ファイルとして、Config.javaのようなスタンスを採用してこなかった。
　設定ファイルのスタイルとして.propertiesといったファイルや、.xmlが散見されるが.javaを設定ファイルとして用いたりするケースをほぼ見かけないと言っていい。

　が、C/C++やLLはxxxxx-config.plとか、config.phpだとかsettings.pyといった文化を積極的に築いてきた。
　要するにソースコード上に設定を記述してしまおうというスタンス。

DEBUG = True

DATABASE_ENGINE = 'mysql'
DATABASE_NAME = 'test'
DATABASE_USER = 'root'

といった記述を「設定名を冠した」ソースコードに集約する。

if DEBUG:
    DATABASE_NAME = 'debug'
else:
    DATABASE_NAME = 'release'

なんて記述もお茶の子さいさいだ。

Cでもこの文化は有効で、マクロを多用するが、

TASK_SETTING_START

    TASK_SET( mainTask, PRIORITY( 1 ) ),
    TASK_SET( fieldTask,  PRIORITY( 2 ) ),
    TASK_SET( spriteTask, PRIORITY( 2 ) ),
#if DEBUG
    TASK_SET( debugTask, PRIORITY( 3 ) ),
#endif

TASK_SETTING_END

みたいな記述ができた。イリーガルさがあるけど。

Pythonのsettings.py
で近しい記述を探すなら、

# テンプレートコンテキストプロセッサの実行の前に処理するメソッドを書く
TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
)

のようになるだろうか。

これに対して、Javaは多くの場合にこのスタンスを採用してこなかった。
「なぜか」と考えれば（自分は）Javaはこれらの記述をすることで設定ファイルがソースコード的になってしまうため、あえて分離を目指したのだと思う。
（それ自体Javaの記述自由度が低いともいえるが、厳格な言語であることを目指す以上当たり前）

それを、あえてConfig.javaでやろうとするアイディアは面白いと思う。
が、JavaがJavaである以上、簡潔に記述できないという箇所がでるのは避けられない。
ロジックを書き始めると、どうもJavaでは単なるソースコードにしか見えない気がする。

@DatabaseEngine(name="mysql")
@DataBaseName(name="test")
@DataBaseUser(name="root")
class DatabaseConfig {
     // or ...
    final String DATABASE_ENGINE = "mysql"
    final String DATABASE_NAME   = "test"
    final String DATABASE_USER   = "root"
}

@AppName(name="hoge")
class AppConfig extends DatabaseConfig {
      ...
}

なんてソースコードになってしまう気がする。

DATABASE_ENGINE = "mysql"
DATABASE_NAME   = "test"
DATABASE_USER   = "root"

ほど簡潔な記述と等価になりえない。（気がする）
特にプリプロセッサ周りもないので、

#if ALPHA_SERVER
    final String DATABASE_ENGINE = "mysql"
#else
    final String DATABASE_ENGINE = "postgresql"
#endif

という感じのロジックを書きにくい。（かけないことはないし、これはこれで拙いけど）
で、違和感を感じたというお話。

（けど、Javaで書く設定ファイル≒ロジックを記述できる設定ファイルは魅力的）

適材適所で棲み分けを考えていけばよいのだろうけれど。
Springとかは綺麗になるのかしらん。
@ConfigurationとかAnnotationアプローチだと意外に綺麗になるのかも。

まぁ、いろんなアプローチがありますね、というお話。

Introduction to Django ... ? lesson.1

　Djangoってなんだ？
　本家から引用するならば

“Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.”

　ということです。
　DjangoはハイレベルなPythonによるWeb frameworkでなんですけど……、
　とってもrapidで、cleanで、実用的なデザインを持っていますよ！
　ってな感じです。

　じゃ、どこがrapidで、cleanで、pragmaticなんでしょう？
　ではその１！

• It provides a method of mapping requested URLs to code that handles requests.
  • MethodがURLに割り当てられます。ってことです。
  • /movies/upload/や、/photos/upload/や、/users/hoge/、または/movies/2/といったURLを書くと適切な引数とリクエストを伴ってMethodに渡される（渡すことができる！）ってことです。

• It makes it easy to display, validate and redisplay HTML forms.
  • HTML formsってパラメータを受け取るのに一般的な手法ですよね。これが簡単に扱えますよ！　ってことです。
  • 簡単に表示できるし、バリデートもできるし、再表示もできる！　formの要素を一つ一つ<input type="xxxx">なんて書く退屈なコードとはおさらばだよ！　ってことです。

• It converts user-submitted input into data structures that can be manipulated conveniently.
  • HTML formが渡してくるユーザーが入力したデータ＝データ構造体、これを簡単に扱えますよ！　ってことです。
  • プログラミング言語のネイティブなデータ型に変換してくれるんですよ！　ってことです。

• It helps separate content from presentation via a template system.
  • 優れたテンプレートシステムはコンテンツをデザインなんかときちんと分離してくれますよ！　ってことです。
  • デザインを変えずにシステムの中身を変えたり、システムの中身を変えずに自由なデザインができます！　ってことです。

• It conveniently integrates with storage layers.
  • データベース？　なにそれ？　食えるの？
  • そんなあなたでも大丈夫！　データベースを意識しなくても大丈夫です！

• It lets you work more productively, at a higher level of abstraction,
  • 高いレベルの抽象化は生産性を高めます……なんて感じですが、とにかく楽しく楽に早くコードを書けますよ、ってことです。
  • HTTPだからどうだこうだ、っていう低い意識は必要ありません！！

• It gets out of your way.
  • 語尾に.doとか.phpとか、.aspxとかつくのはださいですよね！
  • Djangoはそんな制限は一切ありません！　自由に楽しく綺麗なあなたのURLがサイトを彩るでしょう！

　とにかく僕が言いたいのは「楽しい」ってことです。
　美しく、簡潔で、強力なPythonでかかれているってことも楽しさの一つといえます。
　あなたがPythonを使いこなせないとしてもDjangoを始めるのは簡単です！

　あなたも今日からDjango！

毒は毒を持って制する

　Winnyの判決においてソフトの開発者が罪に問われることがある……というのは問題だが、

　実際に建前を抜きにすればWinnyは「自作ポエムなどの交換」を意図したものではなく、著作権侵害物の配布を目的としたことは明らかで、それはダウンロード専用Winnyを開発していたことでもうかがい知れる。

　要するにどんなに綺麗事を並べ立てたとしても、悪意があったのは否定しきれないんじゃないかな。
　
　そして法律を持ってしてそれ（心のうち）を律することはできない訳だから、裁判の結果はどっちでも良かったと思う。
　ぐだぐだ言っても、作るやつは作るし、作らないやつは作らない。法律があっても悪いことをするやつがいるのと同じで、どんな法律があっても個人の行動を規制しきることはできない。

　だので、これは実際どっちでもいい。
　日本国が嫌なら海外に逃げても良いし、別にやりようはある。

　なので、こんなのはどうでも良いんじゃないかな、というのが僕の所感。

　毒は毒を持って制するというのは、所詮有罪判決でWinnyもShareも失われることはない＝利用者をなくすことはできない。
　のだから、Winny自体に寄生するウィルスを持ってすべてのPCを破壊するくらいでちょうど良いんじゃないかな。
　防御力がある人間は仮想マシンなどでやっている可能性があるから全滅は無理だけれど「Winnyを立ち上げたらPCが壊れた」という方が「Winnyの作者が罪に問われた」ことよりもよっぽど規制する力を持つ。

　人は自分に火の粉が降りかかるのをおそれるから、Winnyに対抗しようとした人間は山田ウィルスを開発した。
　そういう意味で、もっと強力なトラップがでてくればWinnyやShareも下火になるだろうと思う。

　Winnyのようなソフトが蔓延してソフトウェアや著作権物の価値をおとしめるほうが、自分にとっては技術者の首を絞めているように思えてならない。

それにしてもこやつやりすぎである

　1900Pとはやりすぎである。
　でも、とても読みたいのである。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 (ASCII SOFTWARE SCIENCE Programming Paradigm)

Python+DjangoでUIコンポーネント開発 with Me (0)

　TurboGearsも触っていたんですが、ついにDjangoにも浮気！
　RoRみたいなフレームワーク、Djangoの簡単な使い方を書いていけたらいいなぁ、と思って（０）としてみた。
　コードを書いているとワクワクできる。
　こういうフレームワークっていいね。
　何かできる予感が詰まっている玉手箱みたいだ。

早く帰るのは悪いことではない……が

　自分は早く帰るのは悪いことではないと思っているし、いたずらに遅くまでやって充実感だけを蓄えるよりはサッと帰ってリフレッシュする方が良いと思ってる。
　でも……通常ではなくて「何か」があるべきときは目の前の作業がなくても待機という意味合いでいることは必要だし、いないにしても何かしらできることはあるはずだ。
　と、思うんだけどなぁ。
　いなくても困らないといえば困らないけど、これは気持ちの問題。
　このあたりの気持ちはなかなか消化できないので嫌になることもある。
　空き時間があって手持ちぶさたなら、何か他の技術を弄んでも良いわけだし。

簡単だからやっちゃいましたの件

簡単だからやっちゃいました、って、
簡単だから（勝手な判断で誰にも断りもなく）やっちゃいました
ってことで、物事が「簡単だから」「すぐできるから」やっちゃうってことなんですよね、っと。

でも、それは大きな間違いで、
多くの場合、そうすべきかどうかは「簡単だから」そうすべきかそうしないべきか、そうすべきタイミングがいつかは決まらなくて、
それをすることによる影響を見積もれることが必要になる。
すべきか、しないべきか、するならいつか、は「簡単」だから決まるのではない。
判断のより所はそこではない。

勝手にやってはいけない、ってことはやっぱり取り返しがつかないことになりかねないから。
判断は常に個人ではできないことばかりで、だからチームというか組織が存在しているわけで、何かしらに関わる重大な意志決定を狭量な個人で定めてはならない、というのは基本原則ともいえるんじゃないかな。

これは自戒でもあって、改善事項でもある。