capsctrldays - 30歳からの提案書
1 30歳からの提案書 30歳にして提案書童貞（DT）だったんだけど、ちょいちょい提案書を書くことになってきたので、調べた結果をメモしとく。 内容については個人差があってしかるべきだと思うので、本当に大事なのは"型"だと思うのだ。ファミレスでダラダラしてるときに紙ナフキンなんかに殴り書きできると使い勝手がいい。その場で適当に10マスに区切って、思考のスタートにできるといいんじゃないかな。 というわけで、その10マス(1-3-1-3-1-1)。 表紙とか 「表紙」では提案書のキャッチコピーをきちんと考えること 会社紹介したことないんだったら、表紙のあとに「会社概要」を入れること 「アジェンダ」も入れてもいいけど、100ページとかにならないんだったらあまりいらないでしょ "今回は提案の機会をいただいて誠に〜"的な「はじめに」を入れる人もいるけど、そういったのは次のPIPで代替してもいいと思う
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
Martin Fowler's Bliki in Japanese - CollectionClosureMethod
http://martinfowler.com/bliki/CollectionClosureMethod.html (detectとinject部分を明確にするよう更新) Smalltalkでプログラミングを始めたときから、コレクションクラスが好きでした。 よく使う強力なオペレーションを簡単に使うことができました。 Javaが登場したとき、このようなメソッドがなくなって物足りないと感じました――Java（およびC#）のコレクションは、Smalltalkのそれと比べて非常に限定されたものでした。 というのも、JavaにはClosureが実装されていなかったからです。 Smalltalkの強力なコレクションのメソッドは、すべてクロージャに依存しています。 近年、私はRubyで頻繁にプログラミングをするようになりました。 Rubyに引き付けられたのは、Rubyには強力なコレクションメソッドがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
