Diary?
2009-07-03
Fri
(22:05)
俺はこれまでの生活を改める事にした。具体的にどこを改めることにしたかというと、とにかくまず飯を自分で作ることにした。これまでは松屋とか吉野家とかコンビニ弁当が殆どと言うのが二年以上続いており、流石にこれはまずいと思い始めたのだ。そしてちょうど在宅の仕事になって時間的に余裕ができたので、その時間を使って自炊する事にした。
そもそも俺は社会人になりたての頃、朝昼晩と飯（弁当）を作っており、これまでのような終わってる食生活にはなっていなかったのだ。それがいつ崩れたかというと、某泥沼プロジェクトに巻き込まれ、時間的余裕も精神的余裕も削られ、結果としてまったく料理をする気が失せてしまったのだ。そのプロジェクトが終わった後は比較的時間に余裕があったはずだが、かなりの長期にわたって気力が萎え気味だったのは否めず、時間が余ってるといっても一日の殆どをボーッとして過ごすような暇な仕事や最初から終わってるような R&D で別の角度から HP と MP を削られ、半分ぐらい人生を投げているような状態が長く続いていた。
が、そんな憂鬱な日々は先々月の末で終わったので、これからはもうちょっと人間らしい生活を送ることにした。というかだな、まともな生活をしてないと怒られるというかなんというか。
というわけで早速料理をしようと思ったが、サラダ油とかを買い忘れているのに気がついたので、日本人の魂であるところの卵かけご飯にすることにした。あと明日はいろいろ忙しいので、「ちーちゃんのお料理日記」は明後日からの予定。俺のモットーは「ド素人が手間暇かけても旨くならねえ」「火の通ったものを食べてる限り人間は死なない」「調味料は食べながら足すものだから適当にやる」であり、さらに割とマジで「天体戦士サンレッド」のオマケに載ってるレシピを参考にしてたりするので、なんていうかあんまり期待しないでくれ。
2009-07-02
Thu
(03:42)
数日前より毎日ちょっとずつ作ってきた Creole 1.0 とおおよそ互換の Wiki 文法のライブラリが一応完成した。なんかもういろいろ面倒なんで、使い方はぶっちゃけソース読めって感じなんだが、何しろ初めての Haskell ソフトウェアなのでコードのクォリティは凄まじくアレだと思われる。
(17:35)
今の仕事では Mercurial のホスティングサービスである bitbucket を使っており、そいつの Issue Tracker も活用してるんだが、俺はこいつの入力フォームにはちょっと問題があると思う。何が問題かというと、 Issue の種類と担当者のドロップダウンリストがテキストエリアの右側にあるのがダメだ。これは少なくとも、俺が Issue Tracker を使うときのフローを反映していない。
bitbucket の Issue Tracker のインターフェースは、最初に Issue のタイトルと本文を埋めるような設計になっていると思う。少なくとも、文字の流れる向きが左から右の文化圏ならそうなるんじゃないかな。そして本文を書き終わった後に視点がどこにあるかというと、おそらく "Report issue" のボタンだろう（preview まで目を通していると特に）。そうなると "Properties" の項目を設定し忘れるというケースが出てくることが予想される、というか俺は毎回のように忘れて後から直してる（別に実働部隊が俺一人なんだから気にしなくてもいいかもしれないが、あんま悪い習慣を付けたくないのよ）。
なので俺はこういったアプリケーションのインターフェースは縦長の極めてシーケンシャルなものが適してると思うんだけど、実際のところどうなのかな。アンケート取ったり統計を集めたわけじゃないんで、いまいちよくわからん。
(19:48)
これの参加者を twitter で募っていた時の心温まるやりとり
- hiroki_f
- 層圏トポス合宿これそうな人ってどれくらい居ます?
- ckuwata
- @hiroki_f むしろ俺は行けない理由が見つからないっすね。
- hiroki_f
- @ckuwata 最初からカウントしてるよ。
というわけで（どういうわけだ）圏論に興味のある人は思い切って参加したらいいんじゃないかな。宿泊組もそうでない方も、まだまだ参加できますぜ。
2009-07-01
Wed
(01:00)
Python ネタなら俺の出番だ。
要するにこれは「class の直下で変数宣言をしたい」「でも普通にそれをやるとクラス変数になってしまう」という問題なわけだな。こういう場合にどうするかというと、プロパティを使うのが多分スマートだろう。
class Hoge(object):
def __init__(self):
self.name = 'hoge'
def name():
def get(self):
return self.__name
def set(self, value):
self.__name = value
return get, set
name = property(*name())プロパティに使われる getter/setter を内部関数として定義し、その関数の名前をプロパティ名と同一にし、シャドーイングでその存在を隠蔽してるのがちょっとしたポイントだけど、これは別にやらなくてもいい事なのでどうでもいい。
プロパティの宣言が多くなるとウザったいかもしれないけど、プロパティの宣言がウザく感じるほど外部仕様としてのアクセサが多いというのは俺の感覚としてはクラスの設計かコーディングスタイルが間違っていると思う。これは Python に限らず、他の言語でも同じ。例えば Java は「getter/setter うぜえ」って話をよく聞くけど、俺に言わせりゃ getter/setter のコードが他の部分のコードを読む上で支障になるような設計あるいはコーディングスタイルという事それ自体が終わってる。
ちなみに俺の方針としては、
- 外部仕様として公開するのならプロパティ
- そうでなければ __init__ 内部に列挙
というのがバランスのとれたやり方かなと思ってる。
追記：hiratara さんより返信。デコレータを使った書き方は "Changed in version 2.6: The getter, setter, and deleter attributes were added." とある通り、 2.6 以降でしか使えないですね。もしも 2.6 以降を動作環境として想定できるのであれば、そちらの方が高階関数とシャドーイングを使ったやり方よりも、より宣言的でわかりやすくなると思いますね。
あと「シャドーイング」という言葉に関しては、これは本来「上位のスコープで定義されたシンボルの参照先を下位のスコープで切り替える」事を示す言葉で、例えば次のコードのようにフィールドへのアクセスが仮引数へのアクセスで隠されるような状態に対して使う……はずだけど、もしかして一般的な言葉じゃない?
class Foo {
String foo;
void bar(String foo) {
dosomethingToFoo(foo); //←この時の foo へのアクセスは仮引数へのアクセス
//同じ事はローカル変数でも起こる
}
}それで先に出した property の例は、先に定義した name() 関数へのアクセスを後に定義した name プロパティで隠しているので、本来のシャドーイングとは実は全然違うのだけど、シャドーイングとしてしまった方がわかりやすいかなと。参照先を切り替える/隠すというニュアンスは変わってないと思うし（あーでも混乱の元になるか、こういう書き方は）。
