眠る開発屋blog ある開発屋の雑感。日々勉強。

2008/11/9 日曜日

個人事業主とか

Filed under: 社会 — タグ: — dev0000 @ 12:18:14

いやー、ねぇ。

http://anond.hatelabo.jp/20081108215352

恥ずかしながらこれは最近知った。

バイク急便 -地下鉄・バスで配送強化-

配送員はいずれもバイク急便から配送を請け負う個人事業主の形態。
配送費用は配送員が自らの収入から賄っており、公共交通機関を使えばガソリン価格高騰も響かない。

個人事業主ねぇ。
労災とか大変そうだな。

バイク便は労働者か?それとも個人事業主か?

働かない人とか

Filed under: 仕事 — タグ: — dev0000 @ 3:39:29

日本IBMのリストラが始まった

日本IBMがそうかどうかは分からないけど、
大企業とかで働く人はすごく働くけど、働かない人は本当に働かないイメージがある。
・・・ってか、企業規模に限らないか。

例えば、
昼過ぎに来てスポーツ新聞をずっと読んでて定時前に帰ってしまうとか、
外回りと称して、一週間の半分を喫茶店とかで潰しているとか。

スキルが低いとか要領が悪いとかそういうレベルではなくて、
本当に何もしていない。

大企業のほうがそういった人間が生き残りやすくなってしまってるかもしれない。
利益に対するインパクトが小さければ切迫した問題にはならないしね。

レイオフかぁ、うーん。
雇用対策を企業の責務にするのは限界があるから・・・というかちゃんとやってくれる信頼性がないから、
国でやるしかないと思うのだけどね。

あと前も書いた気がするけど、
全員の給与を1割下げるよりかは、社員を1割クビにした方がよいという話を聞いたことがある。
給与が下がることによるモチベーション低下は1割どころの生産性低下じゃないから、だとか。

“$instance = new self;” とか

Filed under: 技術メモ — タグ: , — dev0000 @ 2:20:01

自分用覚書。

第2回設計勉強会に参加してきた

[php]
public static function bindHermitDataSource(sfDatabaseManager $manager){
$instance = new self;
$instance->dbManager = $manager;
HermitDataSourceManager::setCallback(array(
$instance, ‘getConnectionCallback’
));
}[/php]

new self って使えるんだよね。
今度からそうしよう。。。

DBのカラムの話とか

Filed under: 技術メモ — タグ: — dev0000 @ 0:39:36

外部テーブル、enum、varcharとかにコメントをいただいたので続き。

なんかだいぶ後付けなんですけどね、参考程度。

結局、CBC(ケースバイケース)な訳ですが、ここ2年ばかり、「初期開発時には最低限の機能だけで、要求の殆どは運用中に発現する」といった開発ばかりやっているからかもしれないです。

1. 外部テーブルとして マスタstatus を準備し、元のテーブルにはキーのみを持たせる。
2. enum型のフィールドを作成し、 値を”sleep”、”runnning”、”ready” とする。
3. varchar(30)とかにしておき、文字列をそのまま入れるようにする。

まぁそういった初期開発よりむしろメンテナンスな開発体制だからかもしれませんが、

2のenumについてですが、status が増えた場合、カラムの改修が入るというのが最大のネックかな、と。
例えば、オープンソースとか配布されたものを考えると、
元々enum を採用しており、その後、新バージョンで status が追加された場合、
データベースのカラム変更を伴うアップデートスクリプトが必要となるわけです。

まぁオープンソースの例は極端な気がしますが、
個人的にはカラム変更ってあまりやりたくなかったりします。
既存データを破損させる可能性が高いから。
あらかじめ検証済みの alter の SQL文を使えば問題はないのですが、そういう手間暇を生んでしまうのがメンドウだったりします。

1 のマスタですが、個人的には正しいのはこれかなという気もします。

ただし、IDがなんとなく意味を持っちゃうとどうだろうか。

“sleep” => “ready” => “running”

というようになんらかの状態遷移を持っており、

1 sleep
2 ready
3 runnning

とIDが設定されているとして、そこに “wakeup” を追加したとして、

“sleep” => “wakeup” => “ready” => “running”

と状態遷移が変わったとしても、

1 sleep
2 ready
3 runnning
4 wakeup

とせざるを得ないのはなんだか気持が悪い気がします。

1 sleep
2 ready
3 wakeup
4 runnning

こういうふうにマスタを変更し、status を所有するテーブルの値も変える?
って運用中のサービスであれば停止する必要があるし、停止させる為の手間暇(関係者各位やユーザへの告知)が一苦労。

そもそもプログラム中でマスタstatusをどの程度必要とするか?という話もあったりするので。
キーしか必要としないものであれば、多分いらないだろうし。

で、文字列をキーとして用いてしまう件ですが、
数字の 2 を 3 と打ち間違えるのと、”sleep” を “slep” と打ち間違えるのにどの程度の差があるか?
プログラム中でそれらの打ち間違えを防止する為に alias などを使用するのであれば、
結局、数字も文字列もあまり変わらないのかな。
であれば、より直感的に理解できるほうがいいのかな、と。

とはいうものの、CBCですからね、所詮。
こういった状況がむしろ例外かもしれないですし。
一人開発プロジェクトが多いからかな、ってのもあります。

そもそも「最低限の要求定義」という状態自体が間違いなのかもしれません。
が、間違いを間違いと指摘したところでどうにもならないし、むしろ「頑張って作った機能が使われない虚しさ」を感じることが多いから、なるべき初期は軽めにただし変更しやすくってことになるのかな、とか。
要求定義の精度が上がれば使われない機能も減るのか?
おそらく業務系かコンシューマ系か?で「何が必要で何が不要か?」の精度は分かれるのではないかと思います。
例えば、ニコニコ動画システムの要求定義は当初はニコニコ市場の登場を見越せてないと思います。
でも、後から必要になったと分かったのであれば、それはそれで対応しなくては仕方がないだろうし。

とはいうものの、いわゆる正規化とかは真面目にやったほうがいいかな、とは思いますが。
文字列ってのは邪道なんだよね、やっぱり。

Powered by WordPress