何となく気になるので突っ込み

元ネタ
WEBプログラマ向け、10個の禁止事項
http://pgyougo.seesaa.net/article/112302930.html

1. 車輪の再発明禁止

非常に難しい。「同じ機能」という単語を真摯に捉えた場合においてより一層。
端的に一番厄介なのが「似たような機能は確かにあるんだけど実際問題処理が以下略だったり実装が前略中略以下省略だったりする」ケース。自力で再実装かましたほうがマシなケースも少なからず*1。
とはいえ「闇雲に全部自力」は色々としんどいので、そのあたりはある程度柔軟に対応すべき。

2. 言語的冒険禁止

指定された言語にもよるけど…まぁ…基本依頼主のご意見を尊重しましょ。

3. 死ぬほど働くの禁止

っていうか週あたり40時間を超えて働いちゃいけませぬ。

4. 新人に優しくないソース禁止

これは全力で否定。
無駄にややこいソースにする必要はないと思うが、必要性があれば、ビット演算や状態遷移や各種アルゴリズムやらデータ構造やら、その辺は駆使して然るべき。
我々は新人のためにプログラムを組んでいるわけじゃない。お客様のために組んでるんだ。
で、無知は純粋に罪悪だと考えて、いいから学べ。
質問は当然ながら許可。っつか質問しないほうが悪い。

5. 英語苦手意識禁止

あぁうんYes。…とかいうおいちゃんも可能な限り英語は回避するがｗ

6. リファクタリングのやり過ぎ禁止

そんな余裕は滅多にないが、万が一そんな余裕があったらうん多分Yes。

7. 寝不足禁止

当たり前以前。この世界には「マイナスの生産性」とか「生産性の逆噴射」とかいう恐ろこい現象が有る事を忘れてはいけない。

8. Firefoxベースで考えるの禁止

っつかとりあえずIEって鬼っ子だから…嫌いだけど確認はせざるを得ない。
問題は。今チェックするのにIEの６と７とでまた挙動が以下略。どないせぇっちゅぅねん orz

9. 調べごとに没頭し過ぎるの禁止

しすぎない程度には没頭して欲しいものですが。
まぁ…タイマーとか使って区切りましょ。

10. 仕事中のネットサーフ禁止

これも「息抜き」程度が限度。さすがに丸一日とかいうのはどうかと思う。

…ふむり。結局本気の反論は４番くらい(笑
つまり、概ね人は同じ事を考えているんだろうなぁ、と、しみじみ。

*1:とはいえ。「言語が用意している関数」が使い物にならなくて再実装、ってのはどうなのさね？

言い当ててるなぁ

結局のところバランスの問題なんでしょうがね。

■[非効率]ウォーターフォール
http://d.hatena.ne.jp/tonotonotono/20090308/1236527471
経由
アジャイルとウォーターフォール
http://d.hatena.ne.jp/shivashanti/20090307

こいつは将棋を指す時「詰み」まで読み切ってから始めるのか？

２手３手先とか。熟練者なら４手５手先を読むのは大切。
でも結局「読み切る」なんてのは無理なんだから、ある程度のところで後は「えいやっ」とやらざるを得ない部分が当然ながら出てくる。
…はず、なんですがねぇ。現実を考えると。

おそらくこの辺は「減点主義」が根底にあって。
つまり「全員が横並びで問題を起こさないのが尤も良い」状態で。それこそ「理由の如何に因らず( http://d.hatena.ne.jp/gallu/20080516/p1 )」何か問題を起こしたらその時点でマイナスを付ける。
このやり方って「上司が無能なままで居られる」、おそらく唯一の選択肢な訳ですな。
中身を精査するってぇのはそれなりに技能なり知識なり経験なりがいるのですが。「結果としての問題の露見」は、それこそガキだってわかる。
だから、中身をちゃんと精査するんじゃなくて「最終的なoutputに問題があればNGとする」減点主義のほうが、無能な上司には楽なわけで。

んで。

減点主義であるとするならば、当然ながら「詰みまで読み切ってから初めてもらう必要」が、むしろ不可欠なわけで。
そりゃウォータフォール全盛にもなりますわな。

唯一にして致命的な問題点は「現実に全く即していない」わけです。
まぁ。私も使えるタイミングがあったら使ってみましょうかねぇ。

「詰みまで全部読み切れと、でも？」

「質」に関しての雑感

最近思うに。質は、景気やら好況不況やらの波に対しての耐性なんじゃなかろうか、と思うです。
質のよいものは、不況においても正直そんなに困りません。ある程度コンスタントに需要が確保できます。これが質の悪いモノだと一気に落ち込みます。
ただ…景気がよい時に、最大瞬間風速をぶちかまして飛び上がるように売れる物は案外に質が悪いモノが多く、逆に質の良いものは、どんなに好景気だとて、正直大して売り上げが上昇したりしません。

ビジネスとして考えると…どっちも、どこまでも微妙です。

「質が悪いものを"下手な鉄砲も数打ちゃ当たる"の理論で大量にたたみ掛けてどれか一つあたれば大もうけ」というのは確かに一つのやり方で。
一つ一つは、質が悪い分安く買いたたけるので、損失も案外に低く抑える事が可能です。当たればそこらへん全部払ってもおつりが来るくらい儲かりそうですしね。
ただ、不景気になると一気に分が悪くなるので。景気の波には敏感である必要があります。

質が良い物は景気の波にある程度左右されませんが。そも初期コスト(開発コスト)が高いですし、その上で当たらなければ目も当てられません。
その割に売れても「地道に」しか売れませんしね。「百年の計」を前提にするならよいのですが、一攫千金にはまず向きません。

まぁ色々難しいんじゃないかと思うんですね。
え？ 「おいちゃんはどっちのスタンスなの？」
なんで「質の悪い物を売る」なんて品のない事せなかんのですか？
そんな「自分を貶めるような」事をしてなんか楽しいですか？

よりよいものであろうと努力するのは、職人として親方として最低限というか前提以前の事だと思うのですが。

雫どりと圧搾の違い

大本はコミュニケーションの取り方の話だったかと思うのですが…教育を含め、いろいろなレイヤーの話で感じた事だったので、少し。

例えばいわゆる「コミュニケーション how to 本」の類とか。
例えばいわゆる「教育の仕方の解説書」の類とか。
いろいろな書籍があるわけですが、どうしても所々、おいちゃん的にしっくりこない部分がありまして。

結論からいうと。
おいちゃんは基本「雫どり」で、書籍は概ね「圧搾」をベースにしてるわけです。
この二つの元々は日本酒などの造酒の用語。詳細は毎度おなじみで恐縮ですが「ググれ」(笑

正直。
おいちゃんは、コミュニケーションウィルのない人間と会話する気まったくないですし、学ぶ意欲のない人間に教育なんて想像すら出来ません。
でも、書籍では「コミュニケーションウィルのない人間との会話方法」に色々と心をくだき、学ぶ意欲も礼儀もなってない連中を教育するためのノウハウがたくさん書いてあります。

善し悪しの問題ではないと思うんですがね。どうしても性格的に「意識/意欲が出来てない相手」って苦手なんですよね(苦笑
いつも思うですが。しみじみ自分は「一般向けから外れてるなぁ」と思うです(苦笑

あなたは上にいるんじゃない。「上から見る」という立場をもつ、同格の社員なだけだ

元ネタ
「解雇されないだけマシ」「長時間労働こそ鏡」――上司が陥る10の勘違い
http://www.itmedia.co.jp/bizid/articles/0903/05/news098.html

んと…上司、って単語が多分勘違いの元なんだろうなぁと思うですが。

1. （解雇されずに）仕事があるだけ運がいいと思え（Feeling people are lucky just have a job.）
2. 達成不可能な場合でも、君ならできる、と仕事を振ればできるはず（Making work"mission impossible".）
3. 部下と管理職は一心同体だ（Tying your employees' hands.）
4. 長時間働く部下はいい部下だ（Equating busy with productive.）
5. 景気好転は待つしかない（Waiting for an economic turnaround.）
6. 噂は放っておけばいい（Ignoring rumors.）
7. 仕事を達成し、成果が見えた段階で褒めてあげればいい（Saving the praise for last.）
8. 優秀な部下は放っておいても目標達成できる。そのまま放置しておけばいい（Failing to give star treatment.）
9. 部下は意思決定をする必要はない（Not standing by your employees.）
10. 経費削減の一貫として、研修費も削減すべき（Cutting back on trainings.）

はいこれ間違えないように。
これは「管理職者が陥りがちな思い違い」ですから。

これらは親会社のロバート・ハーフ・インターナショナルが、求職者の転職動機に多いという「管理者への不満」や、管理者の募集企業が抱く「要らない管理者像」など、1948年の設立以来60年間に蓄積したノウハウをまとめたもの。

怖いですねぇ「管理者の募集企業が抱く「要らない管理者像」」ですって奥様ｗ

ただ、この記事、間違いが一つ。

なお、公表した10の見解は日本向けに厳選したもの。親会社ロバート・ハーフ・インターナショナルは15の見解を欧米で公表した。欧米のみで公表した1つが、不景気に顕著だという「品質を犠牲にする（Sacrificing quality.）」。日本で公表しなかった理由について「日本人は手先が器用。メンタリティとしても品質を下げるという発想がないから」としている。

は？
なにをおっさっておられるのですか？
「品質を下げる」なんて、どこに行ってもザラに見受けられるお話しじゃぁあぁりませんか。
っつかその前に「品質をちゃんと見る事が理解する事が出来る」上司がどれくらい居るのかすら不明ですがね B-p

爆弾注意！！

BOMBだとリアルに爆弾ですが、BOMもまたなにげに爆弾です。

UTF-8という文字コードがあります。最近、散々市民権を得まくって、割合にデフォルトな文字コードといった風情になっております*1。
まぁ多言語対応とか考えた時に大変によろしい感じではあるのですが。
が。
が。

プログラムファイルそのものをUTF-8で記述＆保存する時に。
一つ、注意すべき点があります。

UTF-8…というかUnicodeは。己がUnicodeで有る事を主張するために(っつか、guessとかいう面倒でトラブル起こしやすいロジックから解放されるために)。
ファイルの先頭に、ある固定のバイナリを置く事にしました。UTF-8の場合、EFBBBFHとか0xfebbffとか表記される16進数３バイトの値です。
これをByte Order Mark、略して BOM と呼称します。
これで、煩わしいguessルーチンから少しだけ解放されて、ハッピー目出度し万々歳、というやつです。

テキストファイル、ならね。

PHPプログラムがBOM付きの場合。まるでそれはBOMBのように働きます。ちゅどむ、ってやつですな。
一見するだけだとわかりにくい部分なだけに。奇妙なエラーとともに出るこの子は、結構な厄介者です*2。
ですので。
プログラムとして保存する場合。絶対に何があろうとも、BOMを付けないようにしなくてはいけません。
場所によっては「UTF-8n」なんて表記をする事もあるみたいですねぇよぉ知りませんが。

BOMって話をした時に。案外に通じない事があったので、ちょろりとメモり。
…一応、BUG、としてPHP側も認識しているらしいんですけどねぇ…ステータスどうなってるんだろ？

*1:おいちゃんは未だにeucベースですが

*2:徹夜が続いてたってのもあるんだけど…気付くのに小一時間かかったですよついこないだ…

仮想世界でのビジネスを知るための第一歩

良いだろうとは思ってましたが…予想を超える良書でした。

人はなぜ形のないものを買うのか

まぁ。
経済学部の准教授さんですからその方向に専門性があるのは当然としても…
http://www.4gamer.net/games/005/G000546/20081222001/

ただ，研究と言えば聞こえはいいんですけど，いざオンラインゲームを遊んでみたら，私自身が大ハマリしてしまいまして……。一時期は，いわゆる「廃人」レベルで熱中していました。

そうですね……平日は毎日3〜5時間，週末は一日中って感じでしょうか。私生活に影響が出まくってしまって，ホント大変でした（笑）。一番ハマっていた時期などは，研究室から家に帰る時間がもったいなくて，研究室に寝袋を置いていたくらいです。

という、大変にユーザ目線体験談に基づいたお話しなので(笑
そりゃ良い本になるはずですわ。

方位磁針と地図があれば迷わない、なんてのは嘘ですが。
なんの指針もないよりは、なにがしかあったほうが「まし」なのは当然のことです。

そんな「一つの指針」をこの本は与えてくれます。