- Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化，継
Modeling by Verb
セイコーエプソン株式会社、萩原豊隆さんによる、新しいモデリング手法、 「動詞de!! モデリング�」のプレゼンテーションです。 ・ソフトウェアの振る舞いは動詞で表現できます。しかし今までのモデリング手順では、“動詞”を適切に扱えませんでした。例えば名詞つまり目的語に着目する一方で、付随する動詞を無視して振る舞いを漏らす。あるいは「○○制御」クラスのように振る舞いがすべて“制御”という言葉に隠れてしまう。いずれも動詞の取り扱いのまずさに起因します。 ・そこで目的語と共に動詞も同時にクラス図へ変換する手法を作りました。モデリングツールを使って、目的語と動詞の組み合わせをサクサクとクラス図に変換していきます。クラス図の良し悪しは読み上げて確認です。単純かつ明快なので誰もがセンスに依存せずにモデリングできるようになります。Read less
ITエンジニア、プログラマのためのUX設計、情報設計勉強会 - paiza times
Photo by Davidlohr Bueso 今回のpaiza開発日誌は片山がお送りします。 paiza運営元のギノでは、これまでも不定期で社内勉強会を何回かやっていましたが、エンジニアの人数が増えてきてスピーカーの頭数が揃ったので、社内勉強会を定期開催する事にしました。 9月の頭に第一回目の「自社サービスエンジニアの為のUX設計、情報設計勉強会」を開催したので、今回はその内容を共有してみようと思います。 ■今回の勉強会の目的、背景 paizaの開発部隊はそれぞれ色々なバックグラウンドを持ったメンバーで構成されているのですが、普段の業務の中だと、なかなかそれを共有する機会や、お互いを深く知る機会が無いものです。そこで過去の仕事の事だったり、得意分野についての共有を順番に発表する形で社内勉強会をやってみる事にしました。 業務的なTipsの共有も重要ではあるのですが、普段の業務の周辺領域だ
bitlyでの分散システム構築から学んだこと
5月に開催されたBacon Conferenceで，bitlyのアプリケーション開発リーダのSean O’Connor氏は，毎月600億クリックを処理する分散システムの開発を通じてbitlyの開発者たちが学んだ，最も価値ある教訓について説明した。 分散システムとは何か？ 分散システムを定義する３大特性は，氏によれば，Wikipediaで簡単に見付けることができる。 コンポーネントノードの真の並行性。これによってノード間の同調に関連するコストと複雑性が発生する。 共通クロックの不在。このため，異なるノードで発生したイベントを時間順に並べることは不可能になる。 障害の独立性。これはノード障害がシステム内の他のノードに影響を与えない，という能力として理解されるべきだ。 従って分散システムの構築では，これらの特性を扱うことを目標にする必要がある。 ただし氏の意見として，システムの分散的特性に起因す
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
PHPカンファレンス2013で「モデルとの向き合い方：ドメイン駆動設計体験ワークショップ」を行いました
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
ソーシャルゲームのためのデータベース設計 まとめ - お笑いプログラマの技術メモ
ソーシャルゲームを作る時に参考になるデータベースやKVSの選定、設計などの記事やスライドのまとめ 2013-02-03追記 スライド ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 とあるアプリの開発運用(トラブルシュート) http://www.slideshare.net/takafumionaka/ss-5852561 PHPで大規模ブラウザゲームを開発してわかったこと http://www.slideshare.net/ketaiorg/php-4638298 Lampで作るソーシャルアプリの負荷対策〜アプリとインフラの調和のテクニック〜 (Klabさん) http://www.slideshare.net/klab/4-d6963726f736f667420506f776572506f696e
仕様変更に強い開発をするための、ヒアリングモデル
仕様変更に強い開発をするための、ヒアリングモデル：仕事を楽しめ！ エンジニアの不死身力（21）（1/2 ページ） 今回のテーマ：仕様変更が起きる理由、そしてそれを防ぐには ある程度の経験を積んだエンジニアなら誰しも、顧客から仕様変更を依頼されて困った経験があるかと思います。 仕様変更が起こると手戻りが発生し、開発工数の増大や予算の圧迫、納期遅れなどを引き起こします。さらに。「仕様だ／仕様ではない」「言った／言わない」といったコミュニケーションのトラブルは感情論になる場合が多く、顧客との信頼関係も悪化します。エンジニアは無理な仕様変更で士気を落とし、顧客は社内調整などでいら立ちを覚えます。 せっかく開発するなら、リソース的にも感情的にも気持ち良く仕事をしたいものです。そこで今回は、「なぜ仕様変更は起こるのか？」をテーマに、仕様変更が起きる原因を探り、それを防ぐヒアリング方法を紹介します。 ヒ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Lv1から始めるWebサービスのインフラ構築
分割と整合性と戦う
ドメイン駆動設計入門