サイトリニューアルのお知らせ - 石橋秀仁当サイトのデザインをリニューアルしました。
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
JOIN禁止と固定長カラムについて - SQLer 生島勘富 のブログ
あまりに気になったので「山本大＠クロノスの日記」にチャチャを入れてみる。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 まあ、政治的にはどのみち勝てなかったでしょう。私も同じ条件であれば、一応は説得を試みるけれど返り討ちに遭うと思う。いずれにしても結果は同じですが、教えられたと思っているなら間違いです。 結論はいつものとおり「下手糞が居るから」に行き着くのですが……。 JOIN禁止について 「JOIN禁止」が正しい場合がある。 それはJOINされるデータがアプリケーションサーバにキャッシュされていて、その一貫性が何らかの形で保証されている場合。 そもそも、せっかくキャッシュしているのに、それを使わずにJOINして取り直
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited
SIerの常識：「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識：「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか？「設計書に記載するべき内容が間違っている」からだ。 （設計が間違っている場合も多々あるが。） 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ
モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
仕様書はどこまで書けばよいのか？ - rabbit2goのブログ
新人にソフトウェア開発の作業手順を教えていると、思いも寄らぬ質問を受けて戸惑うことが有る。例えば、先日はこんな質問を受けた。 「仕様書はどの程度まで書けばよいのですか？」 あまりにストレートな質問なので何と答えるべきか一瞬戸惑ってしまったが、考えてみれば仕様書の記載をどの範囲でどのような粒度でどこまで書くべきなのか？という基準は何も存在していないのだ。品質管理の規定に従ってレビューや照査・承認のプロセスは存在するものの、それは書いた後で行われるプロセスだし、ソースコードと違って「動作する」「動作しない」という明確な境界線も存在しない。内容にモレや矛盾が存在する仕様書は珍しくないし、書き手によって仕様の構成や内容が違うことも有るのだ。 しかし、実際問題として仕様書を上手に書く人はいるし、チーム内には失敗事例を元にまとめた仕様書ガイドラインも存在している。だから「完璧ではないけれど、それなりに
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと１対１に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容（内部の処理の実装方法）の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
