ねことくまとへび

職場の隣の島で麻雀の話がされていたのですが、七対子という単語が出るたびに反応してしまい、作業に集中できませんでした。カクテルパーティ効果ってハンドルネームでも当てはまるんですねｗ　まあ、当たり前と言えば当たり前ですけど。

と、こんな話題でお茶を濁すしかない程度には忙しいです。ここ最近の状況からいつ歩けなくなるかわからないので、できる限り前倒ししておきたいという思惑があるからということもありますが、今月いっぱいはこんな感じですかねー。

ライオンズのキャンプのA班メンバーが発表されました。

【西武】春キャンプ１軍メンバー一覧 - プロ野球ニュース : nikkansports.com

すでに予告されていたとおり、ルーキーの森はB班スタートとなりました。注目度が高いからといって安易に一軍に上げたりせず、じっくり育てるという方針は正解だと思います。焦らずに着実に成長してもらいたいところです。伝統的に打てるキャッチャーがいつの間にか外野手になっていたりすることの多いチームですが、くれぐれもそんなルートには乗らないでください。

予告どおりといえば、増田と大石が漏れているのも事前情報にあったとおりです。後ろが手薄なだけに、特に去年結果を残した増田が欠けるのは非常に痛いですが、まだまだ開幕までは時間がありますから、こちらも焦らずに調整していってほしいと思います。

あと、西口さんは内転筋を痛めたり風邪をひいたりしないでください。

QMA新作稼働前最後の週末でしたが、両日とも満席魔神と戦うほどの気力はなくノープレイで撤収してきました。最後にちょこっとやりたいなぁとは思っているので、明日明後日あたりで時間を作りたいところです。

しかし、あと半年もすれば私がQMAを始めてから10年になるんですよね。まさかこんなに長いつき合いになるとは思いませんでした。さすがにQMA2、3のころのペースではプレイしていませんが、それでも世間一般のライトプレイヤーよりはやりこんでいますからねぇ。

そういえば、QMAを始めたころは、相手にかかわらず野球（当時はスポーツランダム1）を投げ続けると言っていたような気がしますが、今ではアニゲや文系ばかり投げる人になってしまいました。野球を投げるのなんて昔からの野球使いとマッチングしたときくらいのものですｗ

純粋だったQMA2のころを思い出すためにも、次回作ではナビをマロン先生にして野球を投げ続けてみるのもいいかもしれませんね。途中で心が折れるかもしれませんけどｗ

Djangoによる開発でもやもやしている部分があるので、不明点を明確にするために文章にまとめてみます。しばらく後に見返したときに笑い話になっているといいな。

私はこれまでにDjangoを使ってTustle!というサービスと、流山百歌というサービスを作りました。

しかし、どちらも完成までは漕ぎ着けましたが、これをもってDjangoを理解したとは言いがたい状況です。特にProject内のApplicationの扱いについて。そして、Applicationを細かく分けたときのModelsの分割について。

Tustle!ではユーザー認証を司る「twingo」、それ以外の業務機能を担当する「tustle」の2つのApplicationを作成しました。そして、twingoのModelsにはユーザー情報のテーブル（Django1.4なのでカスタムユーザーモデルではなくProfile）、tustleにはそれ以外のテーブルを配置しました。このときは（それが良い作りであるかどうかは別にして）作っていく中で構造に迷いが生じたことはありません。

しかし、その後いろいろと調べていくうちに、どうやらDjangoではもう少し細かい粒度でApplicationを分割するべき、ということを学びました。

それを踏まえ、流山百歌では「100か所一覧」「俳句一覧」……など、かなり細かい単位でApplicationを作成しました。しかし、このときにModelsをどうすべきかに相当迷っています。

当初はそのテーブルにレコードを作成する機能を持つApplicationのModelsにそのテーブルを置こうかと考えました。しかし、例えば俳句関連のテーブルを俳句投稿のApplicationに置くことはいいとしても、日次バッチ処理で定期的にWeb APIから取得した情報で更新するようなテーブルの扱いはどうすればいいのでしょうか。バッチ処理をまとめたApplicationの下に置くのもちょっと違和感があります。

結局、このときは「core」というApplicationを作り、システムの全テーブルの定義をそこのModelsに書いています。そうするとその他のApplicationのModelsが空になってしまって寂しいので、それらについては「MVCのM」ととらえ、テーブルの定義ではなくビジネスロジックを書く場所にしています。「core」の特別扱いを許すのであれば、一応一貫したルールにはなっていますが、やはりオレオレルールであることには変わりがありません。

Projectを複数Applicationに分けて、その中でまたがって利用されるModelを定義する場合、どのようにするのが一般的なんですかね？　もしかして、相互にModelが依存するような単位でApplicationを分割してしまうこと自体が間違いだったりするのでしょうか……。

明日からセンター試験です。受験生のみなさんのご健闘をお祈りいたします。

私がセンター試験を受けたのは18年前、つまり、多くの受験生のみなさんが生まれた年です。そうかー、俺は受験生の倍も生きてるのかー。そりゃおっさんになるわけだ。

ところで、最近のセンター試験は私の受けたころとはずいぶん科目が違うんですね。やたらとIやらAやらBやらがついていて賑やかに見えます。私のころはこんなのは数学I、IIくらいだったような気がするのですが。というか、数学AとかBとかがいったい何を指しているのかさっぱりです。IIAとかIIBじゃなくてただのA、Bなんですよね？

受験生に向けた挨拶で始めておきながら、30代後半以降にしか共感してもらえなそうな締めくくりですみません。