blog.fuktommy.com/ 長文記事

真実と嘘は同程度に尊いという信仰を持っている。自分でも非合理だとは思うが、そういう感覚はあるので、信仰としか言いようがない。

それと同じ原理だと思うのだが、あるサイトの背景が白かったとして、そのサイトから文化が生まれたとする。もし背景が黒かったとしたら、別の文化が生まれた可能性がある。このときの実在する文化と、可能性の中の文化についても、同程度に尊いという信仰がある。

プログラミングにおいて、途中状態の変数を作らないというのは、1つのルールになるのではないだろうか。

PHPのDateTimeクラスは便利なのだが、不思議なところがあって、ほとんどのメソッドに副作用がある。
例えばある日の1日前を作ろうと思うと、

$yesterday = clone $today;
$yesterday->modify('-1 day');

のようにしなければならない。
これがルール違反というのが主旨で、
$yesterday = clone $today; の段階では変数名は昨日なのに、値は今日になっている。

別のパターンだと

$ret = array();
while (条件) {
　　$ret[] = 値;
}
return $ret;

とか。これもreturnに至るまでの$retは戻値ではない。

$retはよくあるパターンなのであまり気にしていなかったのだけど、
$yesterday = clone $today; には頭を抱えた。

Scalaでいうところの var と val なんですかねえ。

Rails系統のフレームワークはMVCの結合が密になる傾向があると思ってて、実際のシステムで使っていくと苦労しそうだと思ってたのだけど、MVCが密結合なのは諦めて小規模のMVCの集合体として全体を作ればいいのかな、と思いつつある。「システム内のどんな文脈から呼ばれても動作するモデル」を実装しようとすると考えることが多くなるけど、「このモデルはこの文脈でしか使われない」と限定してしまえば手間がない。

これはやっぱり納得できないんだよな。例えばHTTPの仕組みでは受け取ったデータを一時的に保存するだけで最終的に消さねばならないとか、そういう制限はないわけで、受け取ったデータをどうするかというのはブラウザその他の実装の問題であり、個々のPCの中で何が起こるかという問題であり、つまり人間でいえば内面の問題なのであって、そういう意味でダウンロードと表示を区別するというのがなんというか適切ではないと感じる。

これはやっぱり納得できないんだよな。例えばHTTPの仕組みでは受け取ったデータを一時的に保存するだけで最終的に消さねばならないとか、そういう制限はないわけで、受け取ったデータをどうするかというのはブラウザその他の実装の問題であり、個々のPCの中で何が起こるかという問題であり、つまり人間でいえば内面の問題なのであって、そういう意味でダウンロードと表示を区別するというのがなんというか適切ではないと感じる。

なんかポイントを集めるゲームに似てる気がしたし、そう思うといろいろ考えることもあるよなあ。会社員としての仕事は、仕事をすることとそれがお金になることが直結してるわけじゃないし、じゃあ経営者をやるとなっても大変なわけで、自分の行動とお金が直結しつつ、気軽にできるものがあったら面白いとは思うんだよね。

gitで複数のリポジトリを結合した話。

svn で project1/trunk と project2/trunk の2つがあったとき、
repos/project1 と repos/project2 をもった repos を作ろうという手順です。
よく調べればもっといいやり方があるのかもしれないけど、よくわからなかった。

git init repos
cd ./repos
touch .gitignore
git add .gitignore
git commit

git fetch ../project1 refs/heads/master:refs/heads/project1
git checkout project1
mkdir project1
mv * project1 # 実際には * ではなくて project1 が入らないようにします
git commit

git fetch ../project2 refs/heads/master:refs/heads/project2
git checkout project2
mkdir project2
mv * project2 # 実際には * ではなくて project2 が入らないようにします
git commit

git checkout master
git merge project1
git merge project2
git branch -d project1
git branch -d project2

僕はクラスの継承はあまり好きじゃなくてなるべく避けるようにしてきたんだけど、小規模で親クラスがどんなメソッドを持っているか把握できる範囲であれば、使ってもいいかなと思うようになってきた。でも多くの場合は親クラスに無節操にメソッドを生やすことになりそうなので、それはよくないね。そういう意味ではmix-in的な、1～2つのメソッドを持ったクラスを複数継承できるのが都合がよさそうだと思った。