関心事オブジェクトの識別 【パターン】 | システム設計日記
モデリングでは「識別」ネタは、基本だし、また、奥が深い。 「識別キーの分析・設計」だけで、本が一冊、書けると思う。 エンタープライズアプリケーションのモデリングパターンの基本としては、まず、「識別キー」はしっかり押さえておきたいところ。 識別キーについて、ざっと思いつく、参考情報： ■ Evans "Domain-Driven Design" の 「Entities パターン」 ■ ファウラー "アナリシスパターン" の ５章「オブジェクトの参照」 ■ Hruby "ビジネスパターンを使ったモデル駆動設計" の 「識別」パターン ■ Richardson "RESTful Web サービス" ４章の「URI」と「アドレス可能性」 ■ データモデリングの、主キーの議論 ... などなど。 「識別」という関心事 識別という関心事は、「業務」の関心事でもあるし、ソフトウェアの実装技術の関心事でも
Shibu's Diary: 中間データ形式について考える
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 by oschene under CC @voluntasに、SQLiteをプログラミング言語間の中間ファイルに使っている、ということを言ったらちょっとビックリされたので、僕なりの中間ファイルに使う基準とかを軽くまとめてみます。あんまり厳密なベンチマークとかは取ってません。フィーリングで書いてます。 SQLite Pythonをはじめとして、多くの言語でデフォルトで使えちゃったりする、オンメモリRDBです。Rubyも早く同梱してくれればいいのに。出力したデータの一部だけを利用するような、ランダムアクセスの場合は効率がいいです。 読み込むプログラムは、作成したデータの一部しか利用しない ちょっと凝った検索がしたい ちょっとした構造体並のデータ構造が表現したい。型も 表形式のデータ
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPやRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard：フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard
【CakePHP】フレームワークにおける「秩序」とは何なのだろう？ | ECWorks Blog
Twitterで少し議論になって、これってちょっと大事だよなと思ったことがあったので、言葉足らずだった部分についてもちょっと補足したりして記事として残しておこうと思います。 なお、これはあくまでも私の一個人としての「考え」であって、正解というわけではないと思います。ただ「こういった考え方もある」という点だけ伝わったら嬉しいです。 で、まあよくあるフレームワークにおける「MVC」の話なんですが、例えば「コントローラやモデルの中でヘルパーとか使ってもいいんじゃないか？」という点について。つまり、MVCで役割を分割しているのに、その領域を乗り越えて機能を実現することについてどうなのか、ということです。 CakePHPでも、ヘルパーの機能で汎用的に使いたい（そして実際に使える)機能があったり、逆にヘルパー内からモデルとかを呼び出して情報を取り出したりすることが出来るっちゃー出来ます。実際にコアヘル
日記/2010/02/16/ステートマシン系のフレームワーク、流行らないよな・・・ - Glamenv-Septzen.net
あんまり、状態遷移の概念を使ったフレームワークって流行らないな・・・。 Piece Project も落ち着いてしまった感じがするし、普段のPHP勉強会で話題になるのは状態を持たないstatelessなフレームワークばかりだ。 多分状態遷移の概念自体が、理解するのが大変・・・というか「ステート」とか「ビュー」とか「イベント」とか、キーワードが一気に出てくるし、裏側の動きがうまくイメージ出来ないのも流行らない原因かな？敷居が高いのかも。 でも業務アプリで入力フローが複雑な場合は、これが無いとやってらんないと思うんだけどね・・・2画面以上に渡るウィザードであったり、一つの作業を完結させるのに複数画面を行き来する必要があって、その流れの中での「一時的な作業途中の状態」に基づいて色々処理しないといけないときとか。こういう場合は、個人的には状態遷移の概念が無いととてもじゃないけどやってられないと思う
DOM = フレームバッファ - id:anatooのブログ
この記事はDOM = Frame buffer | Quixey Blogを勝手訳したものです。 もしあなたが大規模なAJAXアプリケーションを書いているなら、このようなコードを書くのを許せるだろうか。 if (jQuery("#file_menu").is(":visible")) { ... } 駄目だ、これは全然良くない。というのも、プログラムの状態の保持をDOMに依存しているからだ。私たちは以下のように主張したい。DOMは木構造を持っているにもかかわらず、あなたのアプリケーションの出力をエンコードするのみであり、セマンティクス(意味論)を持っていない、と。 デスクトップのメタファ デスクトップアプリケーションをプログラミングすることを考えよう。あなたのプログラムはメモリ内のオブジェクトを通じて一連の状態を保持する。もしあなたが現在どのUIエレメントが表示されているかを知りたいならば
プログラミング原則一覧 - Strategic Choice
見つけた時に逐次エントリしている「プログラミング原則」カテゴリの一覧です。不定期に追加しています。プログラミング一般デメテルの法則DRY原則YAGNIKISS原則OAOOUNIX哲学可逆性曳光弾直交性契約による設計 DbCプログラマの三大美徳PIEの原則SLAPパフォーマンスチューニングの格言驚き最小の原則オブジェクト指向プログラミングパルナスの規則抽象データ型サブタイプ求めるな、命じよコマンドとクエリ分離原則オブジェクト指向設計パターン言語生成・使用分離の原則パターンの定義IOP
『Social IME 〜みんなで育てる日本語入力〜』のご紹介 - nokunoの日記
Social IMEのご紹介をする機会があったので、発表資料を公開します。
各ディレクトリの役割を知ろう（サブディレクトリ編）
巨大な/usrのディレクトリ構造 /usrには、読み出し可能かつ共有可能なファイルを配置します。一般的にいって、ここには多数のファイルが配置され、ディレクトリ構造も複雑になっています。 FHS 2.2におけるサブディレクトリは以下のように定義されています。ここでも、ディレクトリによって「必須」と「オプション」に分かれます。
美は動機か結論か - #書評_ - ビューティフルアーキテクチャ : 404 Blog Not Found
2009年11月23日21:00 カテゴリ書評/画評/品評Value 2.0 美は動機か結論か - #書評_ - ビューティフルアーキテクチャ オライリーより献本御礼。 ビューティフルアーキテクチャ Diomidis Spinellis / Georgios Gousios編 久野禎子 / 久野靖翻訳 [原著:Beautiful Architecture] 美しい。「ビューティフルコード」も美しい一冊だったが、本書も実に美しい。 と同時に、「美」についての立脚点が、これほどまでに異なるのかということに驚きもした。 美とは動機なのか結論なのか。両書を読むと、ぶつからずにはいられない設問である。 本書「ビューティフルアーキテクチャ」は、「ビューティフルコード」の続編にあたる一冊。ここでいう「アーキテクチャー」は建築一般ではなく、コンピューターの設計に関わるものではあるが、コンピューター関係者で
ER図から，Webアプリを自動生成
下記の流れは，一度は体験しておきたい。 ER図を書く。 → 1 から，DDL文+テーブルを自動生成。 → 2 から，テーブル定義書を自動生成。 → 2 から，Webアプリを自動生成。 コーディングなし。 例として，複数人で利用できるブックマークアプリのようなものを生成してみる。 「CakePHPが作ってくれる雛型（scaffold）はリッチだ」とよく言われるが，それを更にテーブル生成ツールと組み合わせたらどうなるか，というのが焦点。 CakePHPの入門方法もちょっと兼ねる。 事前準備（1/2）：ツール ER図描画+DDL生成+テーブル定義書生成のために，A5SQLというフリーソフトを使うのでインストールしておく。 A5SQLをDL http://www.wind.sannet.ne.jp/m_matsu/... また，DB+DB管理+PHP実行のために，XAMPP+CakePHPを使う。
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
バグゼロのための設計原理
バグゼロのための設計原理 昨今、いかにソフトウェアの不具合を減らすべきかという議論がいろいろとなされています。現状として、量産直前での総ざらい、過去トラチェックで不具合を発見しても、待ち構えているのはあまりにも大きな手戻りと、穴を空けてしまう日程への困難な交渉業務です。 そこで、よく言われるようになってきたのが、“日々の品質の作り込み”＝“先手管理”が大切だということですが、スローガンとして理解できても、さて担当として何を実践すればよいのか迷うところです。もう少し、具体的にブレークダウンした方法論は、何かないのかと調べてみました。 その結果、以下の表に示す七つの実践原理をソフトウェア工学の論文より見つけてきました。［君島 浩氏（富士通）論文より部分引用］ 少しでも皆様のお役に立てるようここに公開します。
CakePHPを使ったMVC設計のベストプラクティス - Sooey
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
Latest topics > 他のアドオンと衝突しないように心がけたいし、心がけて欲しい - outsider reflex
Latest topics > 他のアドオンと衝突しないように心がけたいし、心がけて欲しい 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « ツリー型タブとVimperatorが衝突する Main 中学生男子のおっぱいへの情熱に溢れた青春映画「おっぱいバレー」 » 他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009 「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。 現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んで
プログラミング言語の進化の方向 - 世界線航跡蔵
セキュリティ&プログラミングキャンプ のBoFで、笹田さんがやってたセッションで話したことがある。言語の進化はベストプラクティスの取り込みにある、と。 ベストプラクティス取り込みの歴史 計算可能である事柄を計算するだけが問題であるなら、チューリング完全な言語なら何でも良いということになるし、不完全な言語は出る幕すらない。ラムダ計算からの自然なマップを考えるならS式で書いて何か実行すれば良いんだし、最小のプリミティブから出発するのが目的ならLazy Kなんかもいいかもしれない。 でも、工学的要請からは、計算可能関数が等しく計算の対象となるわけではない。そして、ある種の計算の傾向、パターンに対して「こうすればいい」「こう考えればいい」「こう設計すればいい」というベストプラクティスが生まれてくる。プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザパタ140文字
ダメなユーザインタフェイス講座