Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
AgileData.org in Japanese - オブジェクト・リレーショナル・インピーダンス・ミスマッチ
http://www.agiledata.org/essays/impedanceMismatch.html この論文は、Agile Database Techniques Chapter 7より抜粋。 オブジェクト指向技術はデータと振る舞いを持つオブジェクトを使ったアプリケーションの構築をサポートする。リレーショナル技術はテーブルへのデータの保管をサポートする。また、データベース内部においてはストアドプロシージャ、外部からはSQL呼び出しを用い、データ操作言語（DML; Data Manipulation Language）を使ったデータの操作をサポートする。 さらに進歩したリレーショナル・データベースには、内部的にオブジェクトサポートするようなものもある。 データベースがより強力になるというこの傾向は、時とともに強まりこそすれ弱まることはないだろう。 多くの組織において、オブジェクト
講演料っていくらで依頼すればいいのか問題 - capsctrldays(2011-06-08)
■ 講演料っていくらで依頼すればいいのか問題 ちょっと思うところあって（まぁ平成仮面ライダー勉強会のことなんですけども）講演料の相場を調べてみました。 話が複雑なのはわかっているよ 講演料の話をすると「人はお金のために動くのではないのであって……」云々いうバカに見つかって辟易したりしますけど、「おもしろくない仕事はお金もらってもやらない」とか「知人の依頼なら無料でもやる」とか「主催者やイベントの内容によって値段は変わる」みたいな、各種さまざまな要因が存在することは承知しています。 この点については、東浩紀さんの発言が参考になりました。 ちなみに、学祭の講演だとお車代1万円のみとか平気であります。でもラジオ出演で1万円とか言われたら速攻で断ります。社内講演会なら10万でも断る。主催者が営利企業かどうか、公開かどうか、有料イベントかどうかは大きいですよね。個人の場合、そこらへん自由に裁量ができ
Martin Fowler's Bliki in Japanese - 対話的ストーリー
http://martinfowler.com/bliki/ConversationalStories.html 2010/2/4 アジャイル方法論に対するよくある誤解の話をしよう。 アジャイル方法論は、開発のなかでユーザーストーリーを作り、変化させていくことに重点を置いている。 よくある誤解とは、プロダクトオーナー（あるいはビジネスアナリスト）がユーザーストーリーを作り、それを開発者に差し出して実装してもらうというものだ。 この考えでは、流れはプロダクトオーナーから開発者に向かっている。 プロダクトオーナーの責任は何が必要かを決めることであり、開発者の責任はどうやって実現するかを決めることだというのだ。 この考えは、能力に沿った責任の分割をその理由としてる。 プロダクトオーナーはソフトウェアの目的であるビジネスを知っており、何を行うべきかを知っている。 一方、開発者は技術とその方法を知っ
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..
1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j
capsctrldays - 30歳からの提案書
1 30歳からの提案書 30歳にして提案書童貞（DT）だったんだけど、ちょいちょい提案書を書くことになってきたので、調べた結果をメモしとく。 内容については個人差があってしかるべきだと思うので、本当に大事なのは"型"だと思うのだ。ファミレスでダラダラしてるときに紙ナフキンなんかに殴り書きできると使い勝手がいい。その場で適当に10マスに区切って、思考のスタートにできるといいんじゃないかな。 というわけで、その10マス(1-3-1-3-1-1)。 表紙とか 「表紙」では提案書のキャッチコピーをきちんと考えること 会社紹介したことないんだったら、表紙のあとに「会社概要」を入れること 「アジェンダ」も入れてもいいけど、100ページとかにならないんだったらあまりいらないでしょ "今回は提案の機会をいただいて誠に〜"的な「はじめに」を入れる人もいるけど、そういったのは次のPIPで代替してもいいと思う
Martin Fowler's Bliki in Japanese - ロールインタフェース
http://martinfowler.com/bliki/RoleInterface.html 2006/12/22 ソフトウェアの構成要素としてのインタフェースには二種類ある。 ひとつは私がロールインタフェースと呼んでいるもの、もうひとつはヘッダーインタフェースである。 ロールインタフェースは、サプライヤ(suppliers)とクライアント(consumers)*1間の、ある特定のやり取りを考慮して定義される。 サプライヤコンポーネントは通常、いくつかのロールインタフェースを実装する。 インタフェースのひとつひとつが、この種のやり取りに使用される。 サプライヤコンポーネントがただひとつのインタフェースしか持たないヘッダーインタフェースとは対称的である。 PERTを使ったプロジェクト計画のプログラムを例にして見ていこう。 ここでは、プロジェクトをいくつかのアクティビティに分解する。 次に
オブジェクト指向プログラムのためのパターン言語の使用
以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。 Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの
RDT - Ruby Development Tools
RDT - Ruby Development Toolsのドキュメント翻訳Wikiです。どなたでも編集が可能です。成果物のライセンスは、GNU Free Documentation License に準じます。 現在は、Ruby Development Tools Documentation - 0.5.0 の翻訳を行っています。 そろそろ 0.6.0 の翻訳をしないと。 mixi内にコミュニティがあったりします。 RDTへようこそ RDTは、オープンソースのRuby IDEです。 Eclipseプラットフォーム上で動作します。 サポートしている機能は、 シンタックス強調表示、 即時シンタックスチェック、 グラフィカルアウトライン、 Test::Unit ビューワー／ランナー、 Rubyアプリケーション起動、 コード・アシスト（コンテンツ・アシスト）、 ソース・フォーマット、 Rubyデバ
Martin Fowler's Bliki in Japanese - 言語ワークベンチ
以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」 の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriente
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20090611.html
http://capsctrl.que.jp/kdmsnr/diary/20090529.html
http://capsctrl.que.jp/kdmsnr/diary/20090522.html
capsctrldays - Webアプリケーション技術者の見極め方（Java）
Google Japan on タモリ倶楽部 - capsctrldays (2006-07-30)