2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2008年09月30日

最近、モンハンの動画をよく見てるんですけど。てか、
そのためだけにニコニコ動画のアカウントも作っちゃったし。

でも、これだけゲームのプレイ (実況) 動画が面白いと
なると、やっぱ囲い込むことも考えてんじゃないですかね。
今はYouTubeだろうがニコニコだろうが大目に見られてる
けど。でも、自前で動画サービスやっちゃえば、囲い込める
わけだし。ユーザのほうも、エンコの手間とかが省けるし。

まぁ、でも、いきなり莫大な資源を必要とする動画
サービスをはじめるってのも大変ですかね。だとすると、
YouTubeとかニコニコとかと手を組むとか。プレイ動画の
前後にCM流してもらうとかね。

本家Permlink


2008年09月29日

ライオンズの渡辺監督。なんか、放任主義とかいわれてる
けど、それってちょっと違うんじゃないの?

なにか? 管理野球じゃなかったらみんな放任主義か?

そういう貧しい思考パターンが日本のスポーツをダメに
してるんだろ。

選手をよく観察して、フォローが必要ならフォローする。
そういうのは決して放任してるわけじゃないだろ。

マネジメントとか、コーチングとか、なんか根本から
誤解してるんじゃないか? 型にハメるのは別に管理でも
指導でも何でもねぇだろ。

--

東スポwww。そこでフクシかよ!www

アッキーナがコスプレやったっていうのは東中で知って
たんだけど、さすが東スポ、ひねりが違うwww

しかも、フクシがガンダムの模型の前で満面の笑みを
浮かべてる写真つきwww

マサが紅茶花伝断ちしてるっていうのも東スポで
読んだんだよな、確か。で、あとで記事出した東中は
商品名出さなかったんだよなwww

本家Permlink


2008年09月25日

1つの箱にアレもコレもと入れてるんじゃ、整理整頓
できてないってことになるでしょ。コードもそれとおんなじ。
その箱っていうのが関数だったりクラスだったりするわけ。

high cohesion, low couplingなんていうとむつかしく
聞こえるかもしんないけど、やることはおんなじなわけ。
整理整頓なのね。いるものといらないものとを分けて、
わかりやすく配置する。責任の分配もおんなじ。

--

ソフトウェア開発っていうのは、こういうのが結構ある。
目的はたくさんあっても、その目的を達成するために
起こさなきゃいけない行動っていうのは限られてるもの。

そういう目的をクドクド説明してるのがCode Complete
なわけね。その目的を知るのは大切っちゃ大切なんだ
けどね。何のためにその行動を取るかっていうのは、
やっぱり知っておかなきゃいけないから。でも、やっぱり、
実際に起こさなきゃいけない行動を知っておくのが、
自分ら現場にいる人間なわけでしょう。

本家Permlink


2008年09月24日

自分の場合、プレゼンとか講演とかを聞いても、その内容を
覚えてることはほとんどないんですけど。

でも、プレゼンとかって、結局、それをやる人間を晒して
るんですよね。自分の場合、そういう人間的な印象は強く
残るんです。

まぁ、伝えようと思って一生懸命やってる人は、たとえ
伝わんなくっても、その人間は十分に伝わるんですよね。
そういうのがきっかけになって、「この人のブログ読んで
みたい」とかって思うわけです。

本家Permlink


2008年09月23日

自分の場合、関数を小さく切り分けることで文句は、まず、
いいません。本体が1行しかない関数だって別に構わないし。

関数を分けるときの指針は、『その関数が1つの仕事だけを
全うしてるか』ですよね。

あるいは、『プログラマの意図がはっきり表現されてるか』
っていうのもあります。これは関数の名付けも含めてに
なりますけど。

大体、プログラマっていうのは生来の貧乏性で、関数を
分けたがらないんですよ。だから、『気の済むまで小さく
分けろ』っていうので丁度いいくらいなんです。

だから、分けたこと自体を問題視するんじゃなくって、
分け方とか、名前のつけ方とかで指導するのが本道でしょ。

本家Permlink


2008年09月19日

やっぱり「平凡」より「フツー」のほうが誤解を生みにくい
気がするなぁ。まぁ、ほんとに言葉遊びのレベルの話かも
しれないけど。

自分は、best and brightestの対義語としてフツーって
いう言葉を使ってるんだけど。

いってみれば、フツーっていうのは、ロングテールのほうに
いる人たちなんだよね。

まぁ、でも、フツーの中にも高低があるのは当然でね。
ただ、低いほうから高いほうに移るのが、そんなに
むずかしくないっていう意味で、みんながロングテールに
いるっていう。

だから、タイトルをつけるなら「ロングテールの逆襲」
ってところなんだよね。自分が狙ってるのは。で、そ
れっていうのは、非常に日本的でもあるんだよね。

本家Permlink


2008年09月16日

結局のところ、ドキュメントのうまい人間を作るのか、
それともプログラミングのうまい人間を作るのか、
どっちのほうがいいのかっていう話になるんだと思う。

ドキュメントだって、読まれてナンボなんだし、誰が
書いても同じというわけじゃない。それを、あたかも、
誰が書いても同じだといわんばかりの論調はどうなの?

たとえば、「ドキュメントはアートではない」というのと
同程度に「プログラム・コードはアートではない」と
いうことはできるだろう。でも、やはり、ドキュメントに
してもコードにしても、そこには厳然とした優劣という
ものがある。

優劣があるということは、そのためのトレーニングが
あって然るべきだということだし、そこらへんを無視
して、ただ「ドキュメントを書け」というのは頭が
おかしいとしかいえない。

トレーニングするにしても、もちろんコストがかかる
わけで、だから冒頭の二者択一というのが妥当なところ。

本家Permlink


2008年09月14日

まぁ、あんまり抽象的というか、精神論っぽい話をしても
誤解されちゃうかもしれないんだけど。

モラルなんだよね。組織のレベルっていうのは、モラルに
現れる。

『それはダメでしょう』というのをお互いに指摘し合う
ことができないと、なかなか組織のレベルっていうのは
上がらないわけで。上下関係だとか、所属関係だとか、
そういうしがらみを超えないと、上がっていかない。
で、しがらみを超えるのに必要なのがモラルということに
なる。

--

ただ、モラルっていうのは、すぐに高くなるもんじゃ
ないしね。実践するとしたら、やっぱりもっと具体的な
施策が必要だろうね。

--

まぁ、あんまりクドクド書くのもアレだけど。

respectだとか、courageだとか、motivationなんかを
ひっくるめてモラルと呼んでるわけです。

--

『5回のなぜ (真因追求)』も、『全体最適』も、結果と
しては同じことになるわけです。真因を追求し、それを
解決すれば、全体最適になると。

--

自分が設計というものに期待するのは、全体最適なわけ
です。できるだけ高いレベルで問題を解決する。

--

極端な話、コードがよく書けてないからドキュメントが
必要になる。コードがよく書けてないのは、結局は、
それを書いた人の理解が足りないから。

本家Permlink


2008年09月12日

義を見てせざるは勇なきなり。

正しいことをやるには勇気が必要なのだろう。

その勇気はどこから来るかといえば、自分を
変えるところから来る。自分を変えることが
できれば、周囲を変えることもきっとできる
はず。

Change yourself, then envirionment changes.

本家Permlink


2008年09月10日1

自分もまだまだ未熟です。

XPでもかなり重要で、かつ初歩的な話。見積もりの話。

なんのためにストーリーという細かな単位に切って、
その都度見積もりを出すか。

これはシグナルを捉えるためにやるんですよね。変化を
早い段階で察知するためにやる。変化っていっても、
いい変化、悪い変化あるんだけど、主に知りたいのは
悪いほうの変化。危機。

もちろん、危機を察知するだけじゃ不十分で、予防や
手当てをしないといけない。具体的な対策を施して、
態勢を整え直す、計画を立て直すことまでが、この
ストーリーによる見積もりに含まれる。

順調に進んでいれば、ストーリーの見積もりっていう
のは減っていくわけです。でも、減っていかなかったり、
逆に増えていくような場合。それは危機のシグナル。
アンドンが点いたといっていい状態。アンドンが点いたら?
全員が作業を中断して、全員で危機から脱するための
対策を練り、実施しないといけない。

と、こういうような話は、こうやって書くことは
できるんですけど、いざ現実に対応できるかというと、
いかんせん未熟なもんで。

--

しかし、バカから謙虚さを取ったら何も残らないんだから、
よく注意せんといかんよな。

--

『成長するシステム』っていうのは、結局は、それに
関係する人たち、顧客や開発者が成長するっていうこと
なんですよね。

iterativeな活動でフィードバックをかけるのも、人の
成長をシステムに反映させるため。

『教育』っていうと『育てる』っていうニュアンスが
強いんだけど、でも、『(自発的な) 成長を促す』、
あるいは『成長を助ける』っていうのも含めて自分は
『教育』という言葉を使いたい。

平凡な人でも向上心は持ってると自分は信じてるし、
その向上心が萎えることのないよう、あるいは向上心が
何らかの結果に昇華するよう、バカなりに考えていきたい。

--

見積もりより実績のほうがオーバーすることをスリップと
いうわけですけど。

スリップしたときにとれる対策は主に2つ。1つは、お馴染の
〆切延期。もう1つは、実現できていない機能をあきらめる
(これを『スコープを狭める』といます)。

対策の選択肢は多いほうがいいわけで。延期とスコープの
両方のオプションがあるほうが好ましいわけです。そう
いう意味では、スコープを狭めてもすぐに出荷できない
ようでは、実質的に選択肢は1つ、〆切延期しかないわけ
です。

だから、システムは早い段階で自立させておくほうがいい。
常に出荷できる状態にしておく。

こう書くと簡単なんですけど、実際はなかなかむずかしい。
というのも、『出荷できる状態』にするためには、結構
細かいことをやる必要があって、それが一見『些細な
こと』のように思えてしまうんですね。だから、こういう、
『出荷のためには絶対必要なんだけど、細々としたこと』
っていうのは後回しにされがちです。で、後回しにされる
っていうことは、いつまで経ってもシステムが出荷できる
状態にならないっていうことになります。

だから、『常に出荷できる状態にしておく』っていう
ことに本気で取り組まないとダメなんですよね。
『なんとかなるだろう』じゃダメで。

本家Permlink


2008年09月10日

だから、『仕様をはっきり決められない』っていうのは、
別に悪いことじゃないんですよね。今までになかったものを
作るんだから、はっきり決められないのは当たり前の話。

結局、ドライブのメタファーなんですよね。走りながら
ちょこちょこ方向を調整するしかない。

顧客と開発者とでインタラクション取って、手探りで
ゴールを決めながら、お互いに納得のいくものが作れれば
いいわけで。

--

結構、悩んでもしょうがないことで悩む人が多いのかな。
悩んでもしょうがないことは事実として受け入れるしか
ないわけで。その事実をなくすることはできないんだし。

ヘンな例えだけど、プロ野球のバッターだったら、3割
打てれば一流なわけですよね。逆にいえば、一流で
あっても7割は打ててないわけです。その7割をどうこう
しようと悩んでもしょうがないわけでしょう。

開発の話っていうのは、やっぱり人の問題に行き着くし、
それは結局は教育の話になるんです。どうすれば人が
育つのかっていうのを常に考えないといけない。

ついこないだ、長めのプロジェクトが一段落したんだけど。
自分の印象に残ってるのって、やっぱり人の問題なんですよ。
どうすれば新しい人がチームに馴染めるのかとか。どう
すればみんなの設計意識が高まるのかとか。みんな働き
すぎじゃないのとか。そういう心配ばっかりしてた気が
する。技術的なことでも苦労したけど、あんまり覚えて
ないんですよね。そういうのは印象に残らない。

本家Permlink


2008年09月08日1

Manの話なんだけど、X68k (Human68k?) がMan使ってたん
だって。

Webで調べようとしたんだけど、ほとんど情報ないんだね。
Web前のコンピュータ史、特にプログラミング関係なんかは
ほとんどWebにないよね。

こうやって数少ない資料を見てみると、X68kって、やっぱり
ゲーム・マシンだったのかなって思う。そういう資料しか
残ってないんだもん。

--

『コードのイヤな臭い』っていうのは、非常に直感的な
ものなんだけど。でも、やっぱりそれを言語化しないと
ダメなんだよね。

そういう直感を直感のまま他人と共有できるんならいいん
だけど。そうじゃないことも多いしね。人のレベルにも
よるし、感性の違いもあるし。

--

そうそう、その臭いとちょっと関係があるんだけど。

ダメな設計のままコーディング進めるくらいなら、
コード書かずに、UMLとかで一生懸命机上設計やった
ほうがマシだよね。

だから、コーディングは設計と不即不離なんだと自分らは
主張してるわけでしょう。だったら、コーディングしてる
そばから設計が良くなってかないとウソじゃん。

だから、今書いてるコードが、設計として正しいかどうかを
常にチェックしないといけないんだよね。で、そんなの
いちいちチェック・リスト作ってやるわけじゃないから、
直感でチェックできてないといけない。それがセンスと
いうもの。

何回も書いてるけど、K.Beck氏曰く『センスとはスピード』
なわけです。正しい判断を素早く下せないと意味がない。
そのために訓練するわけです。正しい設計っていうのが
どんなものかっていうのを肌で覚えないといけない。

センスっていうと天性なものって受け取られるかも
しんないけど、でも、生まれたての赤ん坊じゃプログラムは
書けないんですよ。泣いたりハイハイする能力とかって
いうのは天性のもんだけど。

--

フト思ったんですけど、Shiroさんがたまに書く『抽象化の
漏れ』っていうのは、自分のいうところの『責任の分配
ミス』と似たような話なんじゃないですかね。

ただ、『抽象化の漏れ』のほうは、もうちょっと範囲が
広いかもしれませんけど。『抽象化の漏れ』っていうと
『層』がイメージされますから。で、自分のほうの
『責任の分配ミス』っていうのは、大抵はオブジェクト
単位の話ですから。

--

『自分のいうところの〜』なんて書くと、なんか自分が
発明したような印象を与えちゃうかもしれませんけど、
『責任の分配ミス』っていうのはOOPではよくいわれる
話です。念のため。

--

で、『抽象化の漏れ』にしても、『責任の分配ミス』に
しても、感性の話なんですよね。感じるか、感じないか。
そこらへんは数値化できないところなんですよね。

いわゆる『マジック・ナンバー7』とかあったりもするん
ですけど。でも、そんなにアテになるもんなんて、
やっぱりないんですよね。

本家Permlink


2008年09月08日

そうそう、思い出した。

Managerがダメだっていうんなら、Manでいいんじゃね?

そのほうが短いし、カワイイ感じもするし。

DisplayManとかさ。WindowManとかさ。

なんだかんだで、情報を集中的に管理しなきゃいけない
ことって結構あるわけで。で、そんなときにManagerって
名前を使いたくなるんだけど。でも、「Managerがたくさん
あるのは危険な兆候」って誰かがいってた。だったら、
Manでいいじゃん、っていうね。

一般的に「名前はわかりやすく」っていわれるけど。
でも、そういうんだったら印象的な名前っていうのも
アリだと思うんだよね。たとえば、作った人の名前を
入れちゃうとか。たとえば、TkoWindowとかね。もちろん、
「なにこれ?」っていう話が出ると思うんだけど。でも、
そんときに「ああ、これはtkoって人が作ったんだよ」
っていえば、まずウケるでしょ? ウケたら印象に残る
でしょ。まぁ、ほどほどにしとかなきゃいけないけどね。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails