B-CAS社が素敵すぎる件について
んと。地デジのために無くてはならない会社さん……………の、はづ、なの、ですが。ね。
ちなみに一応。
B-CASカードとは何ですか？
B- CASカードは、デジタル放送受信機に同梱されているICカードです（台紙に封止された状態で同梱されています）。BS・110度CS・地上デジタル共用受信機には赤色のB-CASカードが、地上デジタル専用受信機には青色のB-CASカードが同梱されています。B-CASカードは、デジタル放送の有料放送、自動表示メッセージ、番組の著作権保護、データ放送の双方向サービスなどで利用されています。
という、地デジのためのまさに必須アイテムなのですが。
http://d.hatena.ne.jp/JavaBlack/20080713/p2
http://ja.wikipedia.org/wiki/B-CAS
http://blog.goo.ne.jp/ikedanobuo/e/e3b44ae168cda176cb937bf809bfe8ec
http://gigazine.net/index.php?/news/comments/20080625_bcas/
http://slashdot.jp/yro/article.pl?sid=08/07/09/1013217
http://gigazine.net/index.php?/news/comments/20080709_bcas_financial/
まぁお好きなところから。
とりあえず、 id:JavaBlackさんの
史上*1を独占して巨額の資金が流れ込んでいながら財務状況も存在も謎に包まれてるって，一体どこの犯罪組織のダミー会社ですか．
この一言が楽しいくらいにぴったしカンカン。
*1:市場だと思われる
とりあえず駄目すぎるorz
ネタもとはここ。
Vol.46 システム品質より プライドを優先 開発を混乱させる
http://itpro.nikkeibp.co.jp/article/COLUMN/20080321/296728/
さぁ眠さにまかせて突っ込んでみようｗ
M子さん（29歳）は，ITベンダーのB社で働く中堅エンジニアである。
この「中堅エンジニア」ってのが後半の突っ込みに大切なスパイスとなりますｗ
彼女が「中堅エンジニア」であることを心に留め置いて以下ご覧ください。
M子さんが所属するのは，契約システム開発チームだ。一口に契約システムといっても，新規契約だけではなく途中解約や事故による契約解除業務などを含み，開発規模は大きい。チーム編成は，Nリーダーのほかエンジニアが7人。女性はM子さん1人である。
とりあえず状況を明示、っと。
ところが，12月に入って状況は一変した。結合テストで，15ものバグが発覚したのだ。それも，ほとんどがM子さんの担当部分だった。
「なんで結合まで気づかないかね？」ってのがまず初手の突っ込みとして。どう考えてもユニットテストの類がろくすっぽ出来てないとしか思えない。
Nリーダーは急きょ，メンバーを会議室に召集した。「総合テストは6週間後だ。それまでに，システム品質を確保しなければならない。見通しはどうなんだ」。Nさんの問い掛けに，ベテランのPさんが答えた。「バグの数から言って，3週間は見ておくべきでしょう。理想的には，4週間あれば…」。慎重派のP さんらしい発言だった。
Pさんは多分チームメイト。バグの粒度がわからんので、とりあえずこの台詞は鵜呑みにするとして。
そこに，M子さんが割って入った。「私にやらせてください。責任を持って2週間で片付けます」。メンバーの視線が，M子さんに集まった。Nリーダーの顔に一瞬，不安がよぎった。M子さんは，さらに言い張った。「私の担当で発生しているバグです。皆さんに迷惑はかけません」。チームの足を引っ張りたくない一心だった。そんなM子さんを，Pさんたちは心配そうに見ていた。
んとね気持ちはわかるけど。
Nリーダーは，しばし考え込んだ。確かに，まだ手付かずのテスト項目は山積みで，バグ修正に手を取られるのは痛かった。
って状況もわかるけど。せめて、Pさんをレビュアーとして突っ込まなきゃ。
新人研修は，決して楽ではなかった。「TCP/IP」や「ミドルウエア」といった耳慣れない言葉が，M子さんを当惑させた。プログラミングにも手を焼いた。それでも，M子さんは必死についていった。文系だからといって，同期には負けたくなかった。理解できないことはすぐ講師に質問したし，ITに詳しい同期をつかまえて解説してもらうことも度々だった。
聞き慣れない単語なんざすぐ慣れる。文系が云々とか関係ないし。まぁ「質問したおす」その姿勢はよし、なのだが。
…なら「なぜ今回もちゃんと周囲を質問攻めにしてでも理解しようとしない？」
3年前，金融サービス事業部に異動した際も，徹夜をいとわず作業して経験不足を補った。入社以来，年末年始やゴールデンウィークでさえも，まともに休んだ記憶はない。「女性であることをハンデにしたくない」という思いが，M子さんのがんばりを支えていた。
ダウト。「徹夜をいとわず作業して経験不足を補った」あのねぇ。不足を時間で補える業界じゃないからITって。
駄目な人が16時間やったらちゃんとした人の８時間分の作業には、間違ってもならないの特に品質の部分が。
入社以来，年末年始やゴールデンウィークでさえも，まともに休んだ記憶はない。
いいから休め。休みの間に本でも読んでろ。
さて，契約システムのバグが見付かってから2週間が経過した。M子さんは連日，深夜までバグと戦っていた。しかし，進ちょくは思わしくなかった。総合テストの日程は，容赦なく迫ってきていた。
いち。当たり前「時間費やしたからバグがつぶれる」ならみんな困りません。っつか「中堅エンジニア」ならそれくらい気づこうよ？
に。Mさん「２週間」言うてたんでしょ？ リーダーさんいい加減介入しないと。っつか普通「１週間で進捗が芳しくなければ介入」だよねぇ甘めに考えても。
さらに1週間が過ぎたころ，NリーダーがM子さんの席にやってきて進ちょくを尋ねた。
遅すぎ。ちゃんとクリティカルパスとかそういうあたり意識してる？
「緊急事態だ。バグ修正が遅れている。P君，M子さんのサポートに回ってくれ。P君の作業分は，他のメンバーでカバーする。どんなことがあっても，3週間後に始まる総合テストに間に合わせるんだ。以上！」
これが３週間前に言えてりゃいいんだけど。このタイミングじゃ「駄目管理者」の烙印押されるよ？
男性エンジニアに負けまいと，体力の限界までがんばってきた。
だからこの仕事体力じゃ片付かないって。論点間違えすぎ。
うんなんていうか駄目な人が多すぎて「どこが駄目？」って聞かれたら「全部」とか答えちゃいそう(苦笑
答えのない世界
んと。なんかテレビで大学生をインターシップにして云々いう番組をやっていまして。
なんでも「想定力が足りない」とかなんとかいう話をしていたのでふと気になって。
割合に多くの、特に「学生さん」「教育関係者」がはまるのですが。
学校のお勉強は、基本的にゴールもあれば正解もある世界観です。
でも、現実IT系のお仕事やってると、ゴール設定がないに等しくて答えが存在しない、なんて事も少なくありませんっていうかそっちのほうが普通です。
ある程度慣れてくればよいのですが、とくになれないうちや個人の資質、性格などの問題から「どこか正解がある事を前提にした考え方をしている」人は少なくなくて。ただ、それをやると大抵どこかで大きく失敗します。
で、想定力、という話なのですが。正直言いますと「想定なんて出来ない」と思ってます。この業界。
このあたり…私が趣味にしている、TRPG、というゲームに似ているのですが。
人間、自らの経験や人の話を聞いたあたりから、可能な限りの「全ての可能性」を想定しようとするのですが。
ハッキリと暴言を吐きますと「大抵の人はおかしい」です。
より正確には。
全面的におかしい事は希ですが、１〜２割前後くらいは「なんでンなことしたいの？」と聞きたくなるような、おかしな発想を持っています。
んで。どんなに頑張って鍛えても「その斜め上を行く想定外な発想」っていうのは少なくなくて。でも、その発想こそがビジネスに大きな意味合いを持ったりする事もまた少なくありません。
そこで「どれだけか想定して自らの想定内に落とそうとする」と、想定外の発想に対して対応できなくなります。
しかし、多くの「正解がある世界観の人々」は、どうしても「想定すればいつかは100%網羅出来る」って思ってるように見えるんですね。
なので、奇抜な、でも面白いクライアントのアイデアに、どちらかというと嫌悪感すら抱くような印象を時々受けます。
なので。ある程度大筋はいくつか想定しておくとしても。
「まぁそうはいっても想定外な話も来るんだろうなぁ」と、そのあたりは緩く柔らかい発想力を持ってみてください。
あんまりにもあんまりな想定外のお話なら「ンであんた何したいの？」ってお客様に素直に聞けばいいんです。
アイデアの発露たる「やりたい事」は突拍子もなくても、そこに至る道は、案外に順当なものですから。
なので。
想定力なんてぇものを磨くくらいなら、神経の太さと「質問力」を磨いた方が、多分有利なんじゃないかと私は思います。
…まぁ私の経験範囲内での話なので「甘〜い!!」と突っ込まれる可能性も多々ありますが。
phpDocumentor使ってみた…けど…orz
んと。MagicWeaponのマニュアルがあるので、ちと使ってみた。
何はともあれインストール。
http://phpdoc.org/
から適当にdownloadとかいう文字を頼りに落とす。
おいちゃん的に当然tar ball。
tar ball回答したのを適当なディレクトリに入れて使うとの事なので、copyしないでとりあえずln -sしておく。
まず*.incだけを対象にしたいので、phpDocumentor.ini ファイルをごにょりんこと編集。
んで、作成。
phpdoc -d
との事なので
sh /phpDocumentorのあるディレクトリ/phpdoc -d /MagicWeaponのソースがあるディレクトリ/ -t /DocumentRoot/mw_doc
ってやる。実際には
sh /phpDocumentorのあるディレクトリ/phpdoc -d /MagicWeaponのソースがあるディレクトリ/ -t /DocumentRoot/mw_doc -o HTML:Smarty:PHP
こんな風なのも作ってみた。…どっちが見やすいかは微妙。
んで。テンプレートが「べた書きだわ文字コードiso-8859-1固定だわ」でめっさ使えない orz
とりあえず…しゃ〜ないので気合いで全部EUCに書き換えた。
しっかし…思った以上に使いにくい気がする orz
慣れれば楽なのかなぁ？
ちとその辺明るい諸氏のコメントを切に希望(笑
この台詞が苦くない上司が何割くらいいるんだろうか？
正直、駄文駄目記事が少なくないITProさんですが。
「泰蔵の一日一句」シリーズというのがありまして、個人的に非常にお勧めです。
で…その中から、一つ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080515/301935/
忠誠は 俺にではなく 目的に
さてこれを「苦く感じずにうなずける上司」がどれくらいいらっしゃるものなんでしょうか？
特に権力を握りまくっちゃってる立ち位置の方に是非聞いてみたいものです。
湖の女神様理論とは？
- 湖の女神様理論
端的にまとめると「実装はともかく設計はいろいろな状況を加味して」って感じです。
いやまぁ設計以外でもあちこちで使いますがようは「欲張れ」とｗ
語源というか由来はこんな感じ。
いわゆる「金の斧 http://ja.wikipedia.org/wiki/%E9%87%91%E3%81%AE%E6%96%A7 」の物語があるです。
技術者たるもの。女神様に「あなたが落とした斧は金の斧ですか？ 銀の斧ですか？」と聞かれたら。「落としたのは鉄の斧だけどね。どうせなら金と銀の斧だけじゃなくて、女神様、あんた「も」欲しい！」って言わなきゃｗ
DBの、特に削除と候補キー周りにまつわる思考実験
おもいっくそ思考実験なので鵜呑み厳禁＆考えながら書いてるので多分文体めちゃくちゃｗ
まず。以前に、オラクルマスターとお仕事をしたりしてその流儀をしばらく使ってみたんだけど*1………うん正直トラブルを引き起こしやすかった。
いや別に善し悪しをどうこうというわけではないので念のため。
一つ目。いわゆる「削除フラグ」を必ず盛り込んでいたんだけど…うんこれが使いにくい orz
ほかでも思ったンだけど。多分、彼の流儀は「全てを人工キーで処理する」んだろうなぁという感じ。
自然keyに削除フラグ付け始めるとPKの意味合いが壊れる(苦笑
直近だと。携帯サイトで、[iモードID | サブスクライバID]を識別用に使ってたんだけど。これをkeyにすると、削除フラグとの相性が悪い。
でまぁ 別物として処理してたんだけど、つい削除フラグを考慮し忘れたバグが結構あった。
いやまぁ「何らかの共通なルーチンでフォロー」すればよいんだろうけど…MagicWeaponを見据えて「アプリケーションをまたいで」って考えると、正直少々面倒。
っつか「自然keyをPKに出来ない」のがなんとも歯がゆい。
で、考えた。
なんで削除フラグが必要なのか。多分あれは「間違えたとき用のundoのために」なので。…ンないらんデータを必要なテーブルで保持する必要はないんじゃないかと。
例えば。hogeテーブルに対して、hoge_deleteテーブルを用意する。
hoge_deleteテーブルは常に「hogeと同じアトリビュート＋"delete_date"を持ち、keyは存在しない」。
これで「必要なら頑張って探してundoしてよ」と言える。
data_clump*2のdelメソッド作り替えりゃいいかなぁ。
2008/07/11：削除＆追記 start
><もいっちょ。
…RDB的には「keyってアトリビュートの集合」ってイメージがあるんだけど件のオラクルマスターは「複数カラムにわたるキーはおかしい」と言っていたってのはおいといて。
「複数アトリビュートにまたがる候補キー」をcreate tableとかで指定する方法が、MySQLとかPostgreSQLとかだと見つからないっぽい(探し方が下手なだけかもしれないんだけど)。
なので。これをうまく設定化できて、data_clumpでinsertやupdateの時にはじけないものかなぁと。
そうすると、一部の「うざくて本質的じゃないチェックロジック」から解放されるような気がする。
んと…PKも含めて…例えば…PKって設定するところにc1とかc2とかって名前で区別するとか*3。>
