ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
)
Project Aardvark Functional Specification (Jp) - The Joel on Software Translation Project
公開版への序文 Joel Spolsky Copilot.comの最終版(この仕様書では「Aardvark」と呼んでいる)が2005年8月始めに製造工程に入ったので、この仕様書はもはや歴史的な関心の対象でしかない。私はこれをJoel on Softwareの一部として公開することにした。Fog Creekで実際に書かれている仕様書のサンプルを見たがっている人たちがたくさんいたからだ。 この仕様書には1つ大きな誤りがあった。私がこれを書いた時、SSLで使われているポート443が、プロキシサーバを使うように構成されたネットワークでも開いているものだと思っていた。ブラウザから「マン・イン・ザ・ミドル」攻撃と見えるので、プロキシサーバでSSLトラフィックを転送することはできないと信じ込んでいたのだ。これは誤りで、不正確で、間違っており、最初のベータ版をリリースした後になって、それがいかに間違ってい
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
