タグ

designとpatternに関するa2ikmのブックマーク (13)

  • 補正トランザクション | Microsoft Docs

    一連のステップで構成される最終的に整合性がある操作を使用するときは、補正トランザクション パターンが役立ちます。 具体的には、1 つ以上のステップが失敗した場合、補正トランザクション パターンを使用して、ステップで実行された作業を元に戻すことができます。 通常、最終的整合性モデルに従う操作は、複雑なビジネス プロセスとワークフローを実装するクラウド ホスト型アプリケーションで見受けられます。 コンテキストと問題 クラウドで実行されるアプリケーションでは、データが頻繁に変更されます。 このデータは、異なる地理的場所にあるさまざまなデータ ソースに散在している場合があります。 分散環境で競合を回避しパフォーマンスを向上させるために、アプリケーションは、常にトランザクションの整合性を維持しようと努力すべきではありません。 代わりに、アプリケーションで最終的整合性を実装します。 最終的整合性モデル

    補正トランザクション | Microsoft Docs
  • activerecord-bitemporal/README.md at master · kufu/activerecord-bitemporal

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    activerecord-bitemporal/README.md at master · kufu/activerecord-bitemporal
  • コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog

    2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ.タイトルの通り,コンテナのデザインパターンがまとまっていて,これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値があると思う.一部ミスリードをしているかもしれない. Design patterns for container-based distributed systems 論文も公開されている. https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern

    コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
  • form objectを使ってみよう - メドピア開発者ブログ

    こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。 Ruby化のプロジェクトが始まって1年が過ぎました。新しいメンバーも入り、Railsのコード量は日に日に多くなっています。可読性を保ちつつアプリケーションを大きくしていくために、使える知見をチームメンバーに効率よく伝えていくのが大事だと感じる今日このごろです。 普段メドピア内ではコードレビューや社内勉強会などで知識のシェアを行っています。そんなとき、ブログ記事や書籍などのまとまった文章があると「これ読んでおいて」と言うだけで良くなるので楽です。先日form objectを使ったほうがいいですよーという内容でレビューコメントをつけようとしたところ、日語で詳しくまとまった文章が見当たりませんでした><なければ自分で書くしかありません。そこで今回はRailsにおいて可読性を保つための知見である、form o

    form objectを使ってみよう - メドピア開発者ブログ
  • マイクロサービスのデザインパターン

    第1版 2015年9月21日 第2版 2015年12月24日 Bluemixでは,たくさんのサービスやAPIが提供されており,それらを組み合わせることでアプリケーションを開発することができます.単一のプログラム言語を使って,多数のライブラリやクラスファイルを結合して作る大きなアプリケーションにももちろん利点がありますが,新しい機能やUXを継続的に提供したい時や,目的に合わせてプログラミング言語やデータベースを選択したい場合には,それぞれが独立したサービスを組み合わせるやり方が有利です.この考え方の根底にあるのが,James LewisとMartin Fowlerが提唱しているマイクロサービスです.彼らのブログ記事にあるマイクロサービスの定義にあたる部分を訳してみました. マイクロサービス(Microservices)アーキテクチャスタイルは、それぞれが独立のプロセスで実行され,HTTPリソ

    マイクロサービスのデザインパターン
  • 状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない?横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になりになり死

    状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • リソースモデリングパターン

    Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方(パターンは名前重要) など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター

    リソースモデリングパターン
  • Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと

    GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう! 🗻 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🤔 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ

    Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと
  • MapReduce Patterns, Algorithms, and Use Cases

    In this article I digested a number of MapReduce patterns and algorithms to give a systematic view of the different techniques that can be found on the web or scientific articles. Several practical case studies are also provided. All descriptions and code snippets use the standard Hadoop’s MapReduce model with Mappers, Reduces, Combiners, Partitioners, and sorting. This framework is depicted in th

    MapReduce Patterns, Algorithms, and Use Cases
  • 「クラウドデザインパターン」をAmazonが公開。システム冗長化、突発的トラフィック対応、動的コンテンツ処理など45種類

    Amazonクラウドを使ったシステム設計の際に直面する典型的な問題に対して、解決策を分かりやすく分類、解説した「AWSクラウドデザインパターン」(略称CDP)が公開されました。Facebookページも開設されています。 作成したのはAmazonのスタッフやサードパーティのエンジニアら。 CDPのWebサイトはWikiで作られているため、誰でも新たなデザインパターンなどを追加可能。現在45種類のパターンが登録されており「あと3つ加えると“CDP48”と言えるようになるので、ぜひ追加してください」(玉川氏。JAWS Summit 2012でCDPの公開について説明した際に)と、呼びかけています。 45種類のパターンが9のカテゴリに分類 それぞれのパターンには、名前、解決したい課題、クラウドでの解決方法、実装方法、解説図、メリットと注意点、関連パターン情報などが含まれています。 例えば、サーバの

    「クラウドデザインパターン」をAmazonが公開。システム冗長化、突発的トラフィック対応、動的コンテンツ処理など45種類
  • AWS-CloudDesignPattern CDP2.0候補

    AWSクラウドデザインパターンとは? AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収

  • Inversion of Control コンテナと Dependency Injection パターン

    以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 記事では、このパタ

  • BDDの導入 - Dan North - Digital Romanticism

    この記事はDan North氏の記事「Introducing BDD」を氏の許可を得て翻訳した公式版("the official translation")です。(原文公開日:2006年9月20日) 私は1つ問題を抱えていました。様々な環境にあるプロジェクトでテスト駆動開発(TDD)のようなアジャイルのプラクティスを用いたり、あるいは教えていると、いつも同じような混乱や誤解に行き当たったのです。プログラマが知りたいと望むのは、どこから始めれば良いのか、何をテストすれば良いのか、何をテストする必要がないのか、1つのものに対してどの程度テストすれば良いのか、テストをなんと呼べば良いのか、テストが失敗した理由をどう理解すれば良いのか、ということでした。 TDDに深く入り込むほどに、自分の道程が、言われたことをコツコツやれば徐々に上達するようなものではなく、むしろ行き詰まりの連続であると感じました

    BDDの導入 - Dan North - Digital Romanticism
    a2ikm
    a2ikm 2011/05/22
    テストと設計
  • 1