JavaScriptデザインパターン入門 - Qiita
1. はじめに JavaScriptデザインパターンは、JavaScriptを使ってプログラムを書くときによく出くわす問題を解決するためのガイドです。これらのパターンの背後にある考え方を理解することで、自分の問題に適用することができます。また、これらのパターンが自分のコードに役立つ場合を見つけることもできます。 2. モジュールパターン モジュールパターンは、JavaScriptのモジュールシステムの一部で、データを保護する方法を提供します。これは、モジュール内のプライベートなデータと動作を保護し、一方で公開APIを提供する方法です。これにより、プライベートとパブリックのアクセスレベルを持つ自己完結型のモジュールオブジェクトを作成することができます。 これは、JavaやC++のような言語でクラスにアクセス修飾子を使用するのに似ています。 JavaScriptでは、クロージャを使用してモジュ
デザインパターン「Adapter」 - Qiita
はじめに 本投稿はJava言語で学ぶデザインパターン入門のデザインパターンをまとめた記事です。今回はSingletonパターンになります。 まとめ一覧はこちら Adapterパターン Adapterとは Adapterとは適合するという意味で、Wrapperパターンと呼ばれることもあります。 「すでに提供されているもの」を「利用できるもの」にするためのデザインパターンで、本書ではAC電源とノートパソコンの間のACアダプターを例として説明されています。 利用場面として以下が考えられます 関連性のないクラス通しを既存のクラスを変えずに関連付けする場合 既存のクラスをある新しいインターフェイスを通じて再利用したい場合 既存のクラス・インターフェイスをアプリケーション固有なものに(使いやすく)したい場合 Adapterパターンのクラス図 利用する側はAdapterを生成し、Target[インタフェ
AASM - classの状態遷移をスマートに実装するためのgem (Ruby, Active Record, Sequel, Mongoid) - Qiita
AASM - classの状態遷移をスマートに実装するためのgem (Ruby, Active Record, Sequel, Mongoid)RubyRailsActiveRecord AASM - Ruby state machines ここを参考にしました。 https://github.com/aasm/aasm/blob/master/README.md https://github.com/aasm/aasm/blob/master/CHANGELOG.md ※2014年に本記事を投稿してから、細々と継続的にアクセスがあるようです。AASMの仕様は投稿当時と最新版でもそれほど変わっていないようですが、ご利用にあたっては必ず上記GitHubのREADMEとCHANELOGの確認をお願いします。 概要 AASMはRubyのclassに有限オートマトンを追加するライブラリ。2014年
TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた - Qiita
はじめに UL Systems Advent Calendar 2018の10日目です。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース(DBなど)処理のみ行うローカルトランザクションと、1つのトランザクション内で複数のリソース処理を行うグロー
安定性のパターン大全 (とその実装) - Qiita
Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッキングしてしまう重い処理は、システム全体がスローダウンしたり、無応答になってしまう危険にさらされています。クラウド時代になって、これらの安定性を保つための設計はより強調されるようになりましたが、わりと昔から様々な工夫がされてきたものでもあります。以下、Rel
Ruby/Rails + Clean Architecture で API サーバーを実装してみる - Qiita
以前 iOS/Android 開発を経験した際に知った Clean Architecture を、Ruby/Rails な API サーバー開発に適用してみた。 Clean Architecture といえば以下の図を元にした説明が多いが、 以下の記事を参考に、今回は Data/Domain/Infra/Presentation レイヤーで分けてみる。(これが一番しっくり来ました) まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて 最終的なディレクトリ構造 Rails のルールに則り、controllers だけは app 配下に配置している。 app/ controllers/ layer/ data/ entity/ repository/ domain/ model/ translator/ usecase/ view_model/
コンテナ・デザイン・パターンの論文要約 - Qiita
Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基本的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター
Rails における値オブジェクトと ActiveRecord の composed_of - Qiita
Rails の ActiveRecord には値オブジェクト (Value Object) を便利に使うための composed_of というものがあるらしいのでメモっとく。 エンティティ (Entity) と値オブジェクト エンティティと値オブジェクトはドメイン駆動設計におけるモデルを表現する3パターンの要素のうちの2つだ。 エンティティ 本からエンティティの説明を引用しておこう。 多くのオブジェクトは、本質的に、その属性によってではなく、連続性と同一性 (identity) によって定義される。 例えば Person クラスがあり、その属性は firstname・lastname・age だとしよう。Person クラスの2つのインスタンスがあり、それらが同姓同名同年齢だったとしても、その属性が一致しているからといって同一の人であるとは言えない。なので Person クラスのインスタン
戦術的DDD基本原則まとめ - Qiita
DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約） FACTORIES（ファクトリ） REPOSITORIES（リポジトリ） 関連 関連をたどる方向を強制する 限定子を付けて多重度を減らす ドメインにとって本質的でない関連を除去する 本質的でない関連が除去された結果、残った関連はそのドメインの特徴を表す E
ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita
この記事のモチベーション RDB(Relational DataBase)の歴史は長く、ノウハウも蓄積されている。 関係代数という学問もあるなどアカデミックにも研究されており、 国家資格である「データベーススペシャリスト」も、ほとんどこのRDBのことを扱うなど、 RDBは一定の体系が確立した技術と言える。 一方で、2010年ごろより広まったNoSQL、特にドキュメント指向DBに関しては、 当然ながらRDBに比べると未成熟な段階であろう。 また主観だが、NoSQLは、スケーラビリティといった物理的側面にfocusが当たることが多かったのではと思う。 一方で、論理的側面 = モデリング に関して、および物理的側面と論理的側面のトレードオフの関係について、 議論されつくされているとは言えない。 本稿では、DDD(ドメイン駆動設計)というプログラミングの論理的側面の手法を、 各DBがいかに扱えるか
「Rubyによるデザインパターン」の要点と使いどころ - Qiita
既出ではありますが、『Rubyによるデザインパターン』を読んだので自分なりにまとめました。 なお、「Rubyによるデザインパターン」についてより詳しく知りたい方は、Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern]を参照されると良いかと思います。サンプルソースなども充実しています。 Template Methodパターン アルゴリズムを変更する。 抽象基底クラス（厳密にはRubyに抽象クラス／抽象メソッドは存在しないが、抽象クラス／抽象メソッドとして定義するという意味）に雛形となるメソッド（これをテンプレートメソッドという）を定義し、最低限（または既定）の動作のみを実装する。 詳細な処理はサブクラスのメソッド（これをフックメソッドという）にてオーバーライドして実装する。 処理全体の流れは同じだが、一部が異なる処理が複数ある場合に用いる
JavaScriptのasync/awaitがPromiseよりもっと良い - Qiita
Node.js V7.6からasync/awaitが正式に使えるようになりました。 async/awaitの説明 async/awaitが非同期処理を実装する新しいやり方である。 今までがコールバック及びPromiseを使っていた。 Promiseをベースにしているが、普通のコールバックまたはNodeコールバックを共用できない。 async/awaitの非同期処理がアンブロッキングである。 非同期処理が同期処理のような見た目になり、ソースコードの見通しが良くなる。 文法例 下記の例で説明します。 getJSON関数で非同期通信でネットAPIを叩いてPromiseオブジェクトを返します。レスポンスデータをコンロールログに取得します。 Promiseを利用 const makeRequest = () => getJSON().then(data => { console.log(data);
Rustで写経、デザインパターン23種 - Qiita
Rust力を高めたいけれども、特に作るものが思い当たらなかったのでデザインパターンを真似して書いてみようと思った. 解釈間違い、表現間違い、などなど、コメントお願いします. Githubにも同じコードを上げています Github - mopp/CodeGarage/rust/design_patterns/ 追記 κeenさんが大変良い記事を書いてくださいましたのでリンクを貼らせていただきます Rust風にデザインパターン23種 以下の例では不十分な部分を補足、修正してくれています。 ありがとうございます。 結論 真似して書いてみました。が理解できたという実感が伴っていない おそらく格好のマサカリの的であろう 何かを作るときに実際の問題を考えながら使わなければ覚えられないし、体に馴染まない パターンがあるから覚えるのではなく、問題を解決したいからパターンを参照する、ではないと駄目だなと思っ
Lumen/Laravel Action-Domain-Responder(ADR)アプローチ - Qiita
MVCをより洗練させたパターンとして提唱された派生パターンです 1 このADRのフローは次の通りです フロー WebハンドラはRequestを受け取り、ActionをDispatch ActionはDomainとやりとりを行う アクションはデータをResponderへ Responderは、アクションによって生成されたデータを使用してResponseを作成 Responseをクライアントに返却 ほとんどのwebアプリケーションはこのパターンとなります。 特定のAction(endpoint)は、ドメイン、つまり特定の業務ロジックを実行、それをレスポンスとして返却します。 複数のエンドポイント、リソースを一つのコントローラで解決するのではなく、 一つ一つが独立したクラス、責務となりますので、より小さく、シンプルな実装となります。 メンテナンス性や、複雑さも生まれにくいパターンであるともいえる
Riot.jsによる再利用しやすいコンポーネントの作り方 - Qiita
Riot.jsは単純な仕様のため、複合したHTMLタグとJavaScript機能を持ち合わせた、いわゆるコンポーネントが非常に作りやすい。 今回実際作成したコンポーネントの解説を通して作りやすさを感じてもらい、Riotの普及活動に繋げたい。 再利用しやすいコンポーネントとは これには諸説あると思うが、自分が思うに「利用したくない」と思われるコンポーネントは再利用されない。 自分が利用したくないコンポーネントは 使い方が複雑 依存関係が複雑 カスタマイズできない。もしくはしづらい 見た目がかっこわるい なので、これらの逆をつけば再利用しやすくなるのではと考える。 作ったもの 手書き入力した内容を自動認識し、変換された文字列を返せるもの → <input type="text">の代替として利用可能なもの 仕様としては タッチもしくはマウス操作で手書きすると右下に認識した文字列を表示し、Jav
みんなRailsのSTIを誤解してないか!? - Qiita
な、なるほど...!? いや、みんなちょっと誤解してるんじゃないか? よーし、お父さん、みんながSTIを使いたくなるようにちょっと頑張っちゃうぞ! STIとは STIは、単一の継承階層に所属するクラス群を、ただひとつのテーブルを使って永続化する手法です。 PofEAA Railsのドキュメントを漁ると、次のような記述が見つかります。 http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html Note, all the attributes for all the cases are kept in the same table. Read more: www.martinfowler.com/eaaCatalog/singleTableInheritance.html このリンク先は、リファクタリングで有名なMarti
Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita
この記事はCrowdWorks Advent Calendar 2016 の24日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 昨日の記事は @suzan2go による「ラーメン屋で考えるRailsのデータモデリング」でした。 はじめに CrowdWorksは、2011年の創業以来、約5年間の開発を続けてきました。サービスの立ち上げ期においては、サービスの継続性・変更容易性を高めることよりも、サービスを成長させ、存続に繋がるフェースまで素早く立ち上げることが最重要な観点です。 一方で、サービス提供も5年が経過し、多くの方にご利用頂く「社会インフラ」に一歩ずつ近づいてきています。そういった環境の変化もあり、「日々改善し続ける」「日々変更し続ける」ことに重要視する観点が移り変わってきました。そのような価値観の変遷に取り組む過程で考えている「大規模で複雑な業務要件を担う
CakePHP3新機能 View Cellの使いどころ - Qiita
利用手順 CakePHP3新機能 View Cell の利用手順 Cellの使いどころについて メリット CellはTemplateから呼び出せる都合上、 Controllerのアクションへ記述を追加することなく画面にデータと結びついた表示を追加できます。 これは既に複雑化しているControllerをに対する変更のリスクを避ける、非常に有効な方法です。 利用範囲はReadに留める しかしアクションのコードを汚さなくて済むというメリットの一方で、デメリットも勿論存在します。 それは責任範囲をCRUDのうちReadのみに留めておかないと、Controllerがより一掃汚れてしまうという点です。 Cellでフォームを追加した場合、Cellの存在を知らなくて良いはずのControllerのアクションがその保存を担います。 ReadとCreate/Updateでアクションを分けていたとしても、Cr
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
Railsを事例にして学ぶ、むやみにモジュール分割しているとハマる落とし穴とその回避策 - Qiita
この記事は リクルートライフスタイル Advent Calendar 2016 5日目の記事です。 ビューティー開発Tの@tacuma_igeiです。主にRailsを使って、まだここにない出会いを創出していこうと励んでいます。 はじめに 中規模〜大規模のRails開発をする上で、多くの人が直面するであろう「ApplicationController・Helper散らかる問題」に対して、多くの人がやりがちな対処法とその落とし穴について理解を深め、回避策を提示していければと思います。 需要がありそうなので 事例をRailsにしていますが、基本的にRubyの話なので、Sinatra や Padrinoでも同様の問題が起こりえます。 結論 結論から述べると、 モジュールに切り出してMix-inする場合は、module_functionを使って、明示的にモジュール関数を呼び出すようにしましょう 時間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
