タグ

ブックマーク / capsctrl.que.jp (9)

  • テストダブル - Martin Fowler's Bliki in Japanese - TestDouble

    http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double(テスト代役)」という言葉だ(スタントの代役(double)を想像してほしい)。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡

  • 講演料っていくらで依頼すればいいのか問題 - capsctrldays(2011-06-08)

    ■ 講演料っていくらで依頼すればいいのか問題 ちょっと思うところあって(まぁ平成仮面ライダー勉強会のことなんですけども)講演料の相場を調べてみました。 話が複雑なのはわかっているよ 講演料の話をすると「人はお金のために動くのではないのであって……」云々いうバカに見つかって辟易したりしますけど、「おもしろくない仕事お金もらってもやらない」とか「知人の依頼なら無料でもやる」とか「主催者やイベントの内容によって値段は変わる」みたいな、各種さまざまな要因が存在することは承知しています。 この点については、東浩紀さんの発言が参考になりました。 ちなみに、学祭の講演だとお車代1万円のみとか平気であります。でもラジオ出演で1万円とか言われたら速攻で断ります。社内講演会なら10万でも断る。主催者が営利企業かどうか、公開かどうか、有料イベントかどうかは大きいですよね。個人の場合、そこらへん自由に裁量ができ

    takeshiketa
    takeshiketa 2011/06/09
    大切なお話。
  • 私の翻訳のやり方 - capsctrldays(2011-03-26)

    ■ 私の翻訳のやり方 秋から半年かけて2冊のの翻訳をしたので、そのやり方をまとめて書いてみる。翻訳の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙(原書)なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな

  • Martin Fowler's Bliki in Japanese - トヨタの欠陥

    http://martinfowler.com/bliki/ToyotaFailings.html 2010/3/2 リーン手法をソフトウェアに導入を支持する理由として、トヨタの成功を挙げることが多い。では、最近のトヨタの品質欠陥は、リーンソフトウェア手法を貶めることになるのだろうか? まず言えるのは、バランス感覚を持つべきだということだ。 リーン生産方式というのは、トヨタが1950年代の零細企業から2000年代の世界の大企業に躍進する土台となったものである。 1990年代までには、その他の自動車企業、そして多くの製造業者が、トヨタの手法をせっせとマネしていた。 一般的な感覚としては、この約10年間は、トヨタの手法のマネをすれば自動車の品質が全体的に向上するものと思われていたわけだ。 だから、最近のトヨタの問題が、この半世紀の成功を打ち消すほどのものだとすると、私は驚かざるをえない。 もっ

    takeshiketa
    takeshiketa 2010/03/03
    おお。どう思ってるのか聞きたかったのだ!!
  • 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 - capsctrldays(2010-02-25)

    ■1 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 講演といってもワークショップ形式なので、あまりしゃべってないですけれども。 2時間という長時間でしたが、原メソッドのおかげでピッタリ時間通りに終わりました。ご参加いただいたみなさん、ust参加者のみなさん、スタッフのみなさん、どうもありがとうございました。 今回は、ワークショップへの参加者として思ってたことを2つ実践してみました。 (参加者同士の)自己紹介なんて必要なくね? 模造紙って非日常的だから使えなくね? もちろん異論はあるでしょうけれど。 ustの録画は以下。 ちゃんとした録画は、このへんにアップされるんじゃないかなあ。 http://www.microsoft.com/japan/powerpro/developer/agile/community/suc3rum.mspx 資料も、いずれこの

  • Martin Fowler's Bliki in Japanese - 朝会のパターン:立ってるだけじゃないよ

    朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく

  • Martin Fowler's Bliki in Japanese - ビジネスリーダブルなDSL

    http://martinfowler.com/bliki/BusinessReadableDSL.html 2008/12/15 ビジネスピープルは、DSLを使えば、プログラマがいなくてもソフトウェアのルールを書けるのだろうか? DSLの話になると、ビジネスピープルが自分でコードを書くのかといった話によくなる。 こうした考えには、COBOLのインターフェースの話を持ち出そう。 元々のCOBOLの目的は、プログラマがいなくてもソフトウェアを書けるようにすることだった。が、結果は見ての通りである。 プログラマがいなくてもコードを書けるという話には、COBOL(とその他大勢)が失敗したところを、今回はどうやって克服するのかと尋ねるようにしている。 私は、プログラミングには特殊なマインドセットが必要だと考えている。 それは、マシンに正確な指示を与えること、そして、そうした膨大な指示を構造化して、

  • Martin Fowler's Bliki in Japanese - ドメインモデル貧血症

    http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基的な症状は、一見、それが物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな

  • Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby

    以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日語訳である。 ThoughtWorksは、2006年から格的なプロジェクトRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

    takeshiketa
    takeshiketa 2009/06/15
    極めて貴重なレポート
  • 1