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年08月27日

http://blogs.itmedia.co.jp/hiranabe/2007/01/tps_agile2_5s_0862.html

む。さすが平鍋さん。

でも、巡回リストに入ってないんですよね (笑)。

--

でも、逆輸入だからっていって英語にしなきゃいけない
理由もないんですよね。結局、こういうのは現場レベルで
一人一人が理解しなきゃいけないことなんで。

そういう意味で、``retrospective''を「ふりかえり」と
呼んだのは素晴らしいと思うんですよね。

--

フラグを5つも6つも抱えるようなオブジェクトって
いうのは、もう設計が破綻してるんですよ。

フラグっていうのは状態そのものなわけでしょう。
だから、1つのオブジェクトが5つも6つも状態を抱えて
るのは、何かおかしい。

たとえばStateパターンを使うような場合っていうのは、
1つの事象に関する複数の状態を管理するわけでしょう。
無関係の事象を1つの状態オブジェクトで管理するわけじゃ
ない。

でも、フラグっていうのは、2つのフラグがあれば、2つの
事象を扱ってることになるでしょう。2つの事象を1つの
オブジェクトで扱ってることになる。それじゃぁ、
オブジェクトを使ってる意味がない。モジュール化できて
ないでしょう。

大体、フラグなんか使ってるときは、それに対する
publicなsetterが用意されてることがほとんどで。
それもまたカプセル化を壊すわけでしょう。グローバル
変数と大して変わんないわけです。

本家Permlink


2008年08月26日

当たり前の話ですけど、デバッグっていうのは、
同じような間違いを他の場所で犯してないか確かめて、
同じような間違いを犯さないための仕組みを作るまで
含むんですよね。

--

仕事先の工場に「整理・整頓・清掃・清潔」っていう
標語が掲げられてるんです。で、これってソフトウェア
でもおんなじだなって思ったんです。

整理:要不要をはっきり分け、不要なものを捨てる。
整頓:必要なものをすぐに取り出せる。
清掃:常に掃除する。
清潔:整理・整頓・清掃を実行することで清潔さを保つ。

これ、「4S」っていうらしいんですね。他に「習慣」とか
「躾」を加えて「5S」としているところもあるようです。

「ただそこにあるから」っていう理由だけで使われて
いない関数が残ってたり。「このクラスがこの関数
持ってちゃダメだろう」っていうのがあったり。
インデントがガタガタだったり。そういうのを始末して
いって、常にコードが清潔になるように心がけないと
いけない。

4Sっていうのは、一言にすれば「手入れ」っていうことも
できるかもしれないけど。

--

だから、よくいわれる「きれいなコード」っていうのも、
上の4Sからその定義が導かれるわけです。整理・整頓・
清掃されているコード。それは、まぁ、感覚的といえば
感覚的かもしれないけど、でも、単に「きれいなコード」
っていうよりは具体的ではある。

本家Permlink


2008年08月25日

自分も前はデバッガ全然使わなったんですけど、最近は
よく使うんですよね。前使わなかったっていうのは、
ドメインのこともあるし、デバッガがない、あるいは
不十分な言語や環境が多かったっていうのもあるし。

前から書いてますけど、そもそもデバッガっていう名前が
よくない。ステッパーとかインスペクタっていったほうが
相応わしいでしょう。デバッグするために使うっていう
よりも、現状を理解するために使うことのほうが多いん
だし。

XPでいう『システムに聞け』っていうのは、デバッガも
含めての話ですよね。わからないところがあったら
システムを動かしてみる、デバッガで追ってみるっていう。

こないだ書いた『制御の流れの逆流』っていう話。あれ
なんかはデバッガで追ってて気づいたんですよね。ああ
いうのは、コード読んでるだけだとちょっと気づきにくい
かなと思うんですよ。

本家Permlink


2008年08月23日

ぶっちゃけ、オレは、上場企業が出資して作られた会社なんて
ベンチャーとは思ってねぇから。ただの子会社だろ。

本家Permlink


2008年08月20日

例のごとく、言葉が足りなかったかな。

本気で神輿を担いでくれるっていうなら、それに乗るのも
一興だけど。安いアイドルみたいに使い捨てにされるん
だったら、そういう人とは付き合わないほうがいいで
しょう、ということ。

本家Permlink


2008年08月19日

もう読んだと思うから消しときますよ。

--

確かにそういう生き方のほうが賢いし、幸せになれる
可能性も高いんでしょうね。

でも、自分みたいなバカにはそういうのはできないん
ですよね。

爪先から頭の先までドップリはまってみないと何も
見えてこないんだから。

で、泥沼にハマったらハマったで、すぐ横に同じように
ハマってもがいてるバカもいたりして。泥沼の底にも
道らしきものがあったりして。

大体、gdgdile的にいえば、「何に情熱を注いだか?」
よりも「どれだけ情熱を注いだか?」のほうが重視
されるし。

だから、応用が利くくらいまで自ら進んでハマっちゃう
わけですよ。

前にも書いたことがあるけど、「一をもって万に当たる」。
その選んだ「一」がハズレなら、情熱の燃えカスを
抱いて死ね。

--

上のを書いてから読んだんだけど:

http://d.hatena.ne.jp/lionfan/20080727

ネタがかぶってて笑っちゃった。もちろん、ここに書いて
あるように、すごい人は「どれだけ情熱を注いだか?」と
同じくらい「何に情熱を注いだか?」を重要視するわけ
です。

でも、自分みたいなバカは、往々にして、くっだらねー
ことに情熱を注いでしまうわけです。モンハンとかね (笑)。
それはもう、仕方ねぇんだと。あきらめちゃってるわけ
です。

本家Permlink


2008年08月18日

OOPで「ハリウッドの原則」というものがある。

http://c2.com/cgi/wiki?HollywoodPrinciple

このページに書かれてるように、この原則は、フレームワークの
設計についてのもの。なんだけど、フレームワークに限らず、
OOP一般にいえることだと思う。

たとえば次のようなコードは、ハリウッドの原則に反してると
自分は思う:

class Controller
  def initialize
    @view = View.new(self)
  end

  def call_view
    @view.show
  end

  ...
end

class View
  def initialize(controller)
    @controller = controller
  end

  def show
    msg = @controller.msg
    print(msg)
  end

  ...
end

Controller#call_viewの中でViewのメソッド (show) を
呼んでるんだけど。でも、そのshowの中で、Viewが
Controllerのメソッド (msg) を呼んでいる。

呼び出された側が、呼び出した側に何かを尋ねてる。
こういうのを自分は「制御の流れが逆流してる」と
感じる。

こういうことをやるなら、当たり前だけど:

class Controller
  def initialize
    @view = View.new(self)
  end

  def call_view
    @view.show(msg)
  end

  ...
end

class View
  def initialize(controller)
    @controller = controller
  end

  def show(msg)
    print(msg)
  end
end

とやればいい。

こういうチョー単純なコードならわかりやすい、
っていうか、こんなことやるはずもないんだけど。
でも、もっと複雑になると、意外とやってしまうもの。

制御の流れっていうのは一方通行のほうがいいわけで。
そういう意味で上みたいな例っていうのは、``Don't call us,
 we'll call you''というのが当てはまると思う。

たくさんパラメータを渡さなきゃいけないんなら、
パラメータ・オブジェクトを作ればいいしね。

本家Permlink


2008年08月11日

330号沿いのローソンが怪しい。

なんとなく国際高校そばのファミマも怪しいけど、
とりあえず足はないはずだし、駅に近いほうに
ヤマを張ってみる。

本家Permlink


2008年08月06日

結局のところ、どれだけ現実の問題を解決できるかが
大切なんだよね。そこを忘れて分析・設計だの、表記法
統一だの、本質でないところで盛り上がっちゃった
ところが、あれをオブジェクト指向バブルと呼ぶ所以な
わけだど。

分析・設計、いわゆるOOA/OODと呼ばれるもの。まぁ、
それなりに大切なのかもしれないけど、ソフトウェア
開発全体から見れば、ごく一部分の話でしかないよね。

--

ああ、でも、バブルの残党みたいなのがまだウロウロ
してたりするんだろうかね。XP界隈とか (笑)。


本家Permlink


2008年08月04日

え? わける必要ないじゃん。まぁ、ヲタ話のほうが
好きだし、そっちがHotLinksに残るからいいっちゃ
いいんだけど。

「わけなよ」って何を期待してんのか、よくわかんない。
わけて長続きした例って見たことない。結局、書く側の
モチベーションが一番大切なんだし、読む側の都合なんて
どうでもいいでしょ。「これは技術か日記かどっちかなぁ」
なんてくだらないことで悩むこと自体、自分はイヤだし。

本家Permlink


2008年08月01日

部活に勤しむ夏休みっていうか、一人で自宅合宿状態 (笑)。

村のティガを無理矢理ヘビィボウガンで倒してから、また
手詰まってる感じです。『4本の角』に挑戦する気になれ
ない (笑)。

村ティガ、つまり『絶対強者』は、6番から一歩も降りずに
全レベルの貫通弾撃ちまくるだけ。岩飛んできたけど、
シールドのおかげでなんとか持った。ガルルガシリーズ
だったんだけど、高級耳栓するの忘れてて、しかもホット
ドリンクも尽きるあり様。どっちかっていうと様子見の
つもりだったんだけど、なんか倒せちゃったんだよね。
このティガは弱いらしくって。おんなじ作戦で集会所の
『絶対強者』やってもダメだった (笑)。

でも、カプコン、細かいところが雑だよね。操作が場面
場面でバラバラだもんね。たとえば、武器屋のアイテム
詳細画面とアイテムボックスのそれとじゃ操作が違うし。
それに、どうでもいいところで『はい・いいえ』を尋ねて
くるし。いちいちボタン押させんなって感じ。

ゲームそのものと違って、こういうところは才能は
いらないんだから。組織がきっちり指導なりすれば
いいだけのところでしょう。カプコンみたいな老舗が
こんなんだとガックリするところがあるよね。

まぁ、ゲームが面白いからどうでもいいっちゃどうでも
いいんだけど。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails