サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Wikipedia
capsctrl.que.jp
html コメント 書き方 ×4 / ルームメイトカフェ ×3 / バーチャルボーイ 分解 ×2 / 適用 適応 ×2 / heroku ×2 / 新アジャイルマニフェスト ×2 / mregexp ×1 / フォント bankgothic ×1 / 自分探し世代 ×1 / おしぼりアート チンコ ×1 / ウオッチメン ×1 / 「すぐやる人」になれる本 ×1 / ちくま文庫 悪魔くん ×1 / 宇多田ヒカル 胸 ×1 / UML アレグザンダー ×1 / 平秀信 カンニングペーパー ×1 / ゲゲゲの鬼太郎 漫画本 オリジナル版 ×1 / ゼピール サーキュレーター ブラック DKS-20 ×1 / 住所の書き方 マンション ×1 / 戦国無双 2CH 2004 ×1 / ジェームススキナー wiki ×1 / アジャイルマニフェスト Kent Beck 新しい ×1 / java w
■1 tDiaryをherokuで動かすなど 試作。 http://tdiary-on-heroku.heroku.com/ （あとで消す） http://github.com/hsbt/tdiary/tree/master/core/ を持って来る $ cd core $ cp misc/rack/tdiary.ru config.ru 最新版では不要になりました。 config.ru 編集 最新版では不要になりました。 require 'rack/tdiary_app' → require 'misc/rack/tdiary_app' tdiary.rb 編集 data_mapper_io側で対応しました。 load logger 行を コメントアウト store_cache メソッドを コメントアウト tdiary.conf.rack 編集 # tdiary/data_mapper_
http://martinfowler.com/bliki/Semat.html 2010/4/16 SEMAT（Software Engineering Method and Theory: ソフトウェア工学の方法論と理論）は、Ivar Jacobson、Bertrand Meyer、Richard Soleyが始めた試みである*1。 公表によるとその狙いは「確かな理論と証明された原則とベストプラクティスの上にソフトウェア工学を再構築」することだそうだ。 ソフトウェア業界で名のある方々と一緒に、私もこの試みへの参加を勧められた。 丁重にお断りしたが、その理由を説明する必要性があると感じている。 その活動の呼びかけ(Call for Action)は、私には少し漠然としているように思えた。 一時的なブームや流行を否定しているが、それ自体が流行を追った発言のようだった。 何が起きているのかを
http://martinfowler.com/bliki/LayeringPrinciples.html ここ数日、ノルウェーで開かれたエンタープライズソフトウェアのワークショップに参加してきました。Jimmy Nilssonが主催するワークショップです。 そのなかで、いくつかの設計原則を挙げ、それに投票するというセッションを行いました。 ルールはこうです。 まず、レイヤリングに関する原則をみんなでリストアップしていきます。 次に、簡単なディスカッションを行います（各項目を明確にします）。 自分が好きだろうが嫌いだろが関係なく、 とにかく現場で聞いたことのある原則を残らず挙げていくのが、ここでのルールです。 リストができあがると、投票の時間です。 我々はドット投票の変形を使いました。 各自が賛成票と反対票をそれぞれ10票ずつ持つというものです。 以下に投票結果を掲載しました。 原則の後ろ
http://martinfowler.com/bliki/ToyotaFailings.html 2010/3/2 リーン手法をソフトウェアに導入を支持する理由として、トヨタの成功を挙げることが多い。では、最近のトヨタの品質欠陥は、リーンソフトウェア手法を貶めることになるのだろうか？ まず言えるのは、バランス感覚を持つべきだということだ。 リーン生産方式というのは、トヨタが1950年代の零細企業から2000年代の世界の大企業に躍進する土台となったものである。 1990年代までには、その他の自動車企業、そして多くの製造業者が、トヨタの手法をせっせとマネしていた。 一般的な感覚としては、この約10年間は、トヨタの手法のマネをすれば自動車の品質が全体的に向上するものと思われていたわけだ。 だから、最近のトヨタの問題が、この半世紀の成功を打ち消すほどのものだとすると、私は驚かざるをえない。 もっ
■1 第11回すくすくスクラム――ユーザーストーリービギンズナイトで講演してきました。 講演といってもワークショップ形式なので、あまりしゃべってないですけれども。 2時間という長時間でしたが、原メソッドのおかげでピッタリ時間通りに終わりました。ご参加いただいたみなさん、ust参加者のみなさん、スタッフのみなさん、どうもありがとうございました。 今回は、ワークショップへの参加者として思ってたことを2つ実践してみました。 （参加者同士の）自己紹介なんて必要なくね？ 模造紙って非日常的だから使えなくね？ もちろん異論はあるでしょうけれど。 ustの録画は以下。 ちゃんとした録画は、このへんにアップされるんじゃないかなあ。 http://www.microsoft.com/japan/powerpro/developer/agile/community/suc3rum.mspx 資料も、いずれこの
1 [krb] Head First Kamen Ride―頭とからだで覚える平成仮面ライダーの基本 a.k.a. 平成仮面ライダー勉強会 影の大首領として働いてみました。平日の夜なのにわざわざご参加いただいた皆様、基調講演を快く引き受けていただいた宇野常寛さん、11人のLTライダーの方々、まるでプロの犯行のようなスタッフの皆さん、どうもありがとうございました。 くわしくはサイトを見てもらうとして、 ここでは裏方の作業をチラホラまとめてみます。 ビギンズナイト ジョジョやガンダムが"基礎教養"のような扱いになっていること対して私が発言したのがきっかけ。 @kdmsnr: ジョジョもガンダムも興味ないんだよなあ @kakutani: プログラマのためのライダー勉強会を!! @kdmsnr: それなら講師に @wakusei2nd さんをお招きしたい。鳴滝（ @eto ）さんも。 @waku
http://martinfowler.com/bliki/ConversationalStories.html 2010/2/4 アジャイル方法論に対するよくある誤解の話をしよう。 アジャイル方法論は、開発のなかでユーザーストーリーを作り、変化させていくことに重点を置いている。 よくある誤解とは、プロダクトオーナー（あるいはビジネスアナリスト）がユーザーストーリーを作り、それを開発者に差し出して実装してもらうというものだ。 この考えでは、流れはプロダクトオーナーから開発者に向かっている。 プロダクトオーナーの責任は何が必要かを決めることであり、開発者の責任はどうやって実現するかを決めることだというのだ。 この考えは、能力に沿った責任の分割をその理由としてる。 プロダクトオーナーはソフトウェアの目的であるビジネスを知っており、何を行うべきかを知っている。 一方、開発者は技術とその方法を知っ
http://martinfowler.com/bliki/BusinessReadableDSL.html 2008/12/15 ビジネスピープルは、DSLを使えば、プログラマがいなくてもソフトウェアのルールを書けるのだろうか？ DSLの話になると、ビジネスピープルが自分でコードを書くのかといった話によくなる。 こうした考えには、COBOLのインターフェースの話を持ち出そう。 元々のCOBOLの目的は、プログラマがいなくてもソフトウェアを書けるようにすることだった。が、結果は見ての通りである。 プログラマがいなくてもコードを書けるという話には、COBOL（とその他大勢）が失敗したところを、今回はどうやって克服するのかと尋ねるようにしている。 私は、プログラミングには特殊なマインドセットが必要だと考えている。 それは、マシンに正確な指示を与えること、そして、そうした膨大な指示を構造化して、
原文: http://www.martinfowler.com/eaaCatalog/lazyLoad.html 必要なデータ全てを持つのではなく、その取得方法を知っているオブジェクト 解説の全文は『PofEAA』 200 ページを参照。 データベースからデータをメモリ上にロードするとき、関心のあるオブジェクトだけでなく、それに関連するオブジェクトも同時に読み込むように設計してあると便利である。開発者にとってオブジェクトのロードが楽になり、必要なすべてのオブジェクトを明示的にロードする必要がなくなる。 しかし、この方法を採用した結果、ひとつのオブジェクトのロードが、関係する多数のオブジェクトのロードを引き起こしてしまう。そのうちの一部しか必要でない場合、これは性能上の問題となりうる。 Lazy Load (遅延ロード)ではロード処理をしばらく保留し、オブジェクト構造にしるしをつけておくこと
http://martinfowler.com/bliki/Xunit.html XUnitとは、今やソフトウェア開発者に広く知られるようになったテスティングフレームワークの総称である。最初に有名になったJUnitにちなんでその名がつけられている。 テスティングフレームワークの起源はSmalltalkである。 Kent Beckは、ソフトウェア開発の心臓部である自動テスティングの熱烈な愛好者だった。 彼は自分自身、そしてクライアントが、自動テスティングを行えるように、ユニットテストを構成したり実行したりするためのシンプルなフレームワークを作った。 このフレームワークの狙いは、通常のSmalltalk環境を使ったテストをプログラマが簡単に定義できるようにすること、そして、テストの一部または全てを迅速に実行できるようにすることだった。 Kentと彼のフォロワーたちは、Smalltalk IDE
1 [tochigirubykaigi02] とちぎRuby会議02で発表してきました あまり外に出かけないのでハッカー社長に「引きこもり経営者」と罵られながら頑張って発表してきました。とちぎピープル are ナイス。勉強会嫌いの私でも、とちぎの勉強会の雰囲気は好きでした！ 2 仮面ライダーW in ゴッサムシティ 自分のなかでモヤモヤしていることが、他人と会話する過程でハッキリしていくことがある。今回は新幹線のなかで気づいた。 今度の映画のタイトルは「ビギンズナイト」なわけで、これは当然「バットマンビギンズ」と「ダークナイト」からの引用と考えて間違いない。ここまでは簡単に気づけるところ。 で、以前からWの「世界が狭い」と思っていたんだ。これまでの事件はすべて風都のなかだけで完結する。悪の組織の目的がまだ定かじゃないが、風都だけ狙ってるのはおかしくないか？視野が狭すぎやしないか？（ショッカ
原文: http://www.martinfowler.com/eaaCatalog/serviceLayer.html by Randy Stafford アプリケーションの境界をサービス層を使って定義する。サービス層は利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる。 解説の全文は『PofEAA』 133 ページを参照。 エンタープライズアプリケーションには、 ストアしているデータと実装しているロジックとの間に 様々なインターフェイスが必要である。 例えば、データローダー、ユーザーインターフェース、統合ゲートウェイなど。 それらは目的は異なるが、データにアクセスしたり、データを操作したり、ビジネスロジックを呼び出したりと、アプリケーションとの相互作用が必要である点で共通している。 Service Layer はアプリケーション境界 [Cockburn PloP]
以下の文章は、Martin FowlerによるSoftware and Obama's Victoryの日本語訳である。 2008年の大統領選挙におけるバラク・オバマの勝利の裏には、ソフトウェアの重要な貢献があった――インターネットの利用である。しかし、最も興味深いのは、ソフトウェアの進歩とオバマ陣営の組織の発達との相互作用だった。 最終更新日：2009/7/30 本稿は、ザック・エクスレイと私のQCon London 2008での基調講演を基にしている。 目次 インターネットキャンペーンの目覚め キャンペーンの組織ダイナミクスの変化 有権者について知る 地方組織の再考 Neighbor to Neighbor（隣人の隣人） 巨大なスパム銃 ビデオ 今後の展望 インターネットがなければ、バラク・オバマは大統領ではなかったでしょう。 --Arianna Huffington 2008年の大
1 [セミナー] オブジェクト倶楽部２００９夏イベント アジャイル開発方法論の現状、課題、未来 "海外では独立コンサルタントが産業界の知的伝搬を行っている。" テスト駆動開発者は三周目で死ぬのか "創発的設計とピラミッド"の説明。いろいろ文句言ってくる奴への説明っぽい。巨人の肩に乗りまくり。日本人の巨人（著者）はいないのかな。 ソフトウェア開発に自働化を導入して、人の力を発揮しよう。 TPSはどうでもいいなあ。"製品コードに安全装置" 鬼に金棒：人文系スキルを身に付けよう ドラッカーが好きらしい 出版業における自動化の事例報告 "ccでコミットしたらpdf生成"。ぜんぜん関係ないけど、http://twitter.com/ctakao がカオス。 格差社会を生き延びるためのiPhoneアプリ開発 iYamatoってのがあるらしい。 JSpecの紹介 何が嬉しいのかわからないけど、"文字列置
次のページ
このページを最初にブックマークしてみませんか？
『http://capsctrl.que.jp/』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
