system-design-primer#system-design-interview-questions-with-solutionsYou 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
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
Railsにおける「サービスレイヤ」「サービスオブジェクト」について – recompile.net
Railsを使ったアプリケーションの特定の場面では、「サービスレイヤ」や「サービスオブジェクト」という概念を導入すると有効に機能することがあります。今回は、その紹介をします。 まず、サービスレイヤとは何でしょうか。『Patterns of Enterprise Application Architecture（以下、P of EAA）』では「サービスレイヤは利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる」と定義されています（参照）。ユーザーインタフェースなどからの呼び出しを受け付けるアプリケーションの境界として、ビジネスロジック、トランザクション制御、レスポンスなどの取りまとめをするのが、サービスレイヤの役割です。 では、どのようなときにサービスレイヤを導入するのでしょうか。P of EAAには、次のように記述されています。 You probably don’t
ドメインとデータ、サブジェクトとオブジェクト、および、事実は常に事実であり、真実は常に仮説である、という話 - たなかこういちの開発ノート
先日参加の「PHPメンターズセミナー」には相当に触発されました。本記事はその勢いのままに書いたエントリーとなります。 ※下記記事もご参照ください。 →《PHPメンターズセミナーに参加してきました》 〜・〜 突然ですが、下図は、視点Aから見ると対象物は四角に見えて、視点Bから見ると三角に、視点Cから見ると円に見えるという様子を表したものです。一つの同一の対象物なのに視点によって見え方が異なる、という現象を説明するのによく使われるようです。 図１：四角、三角、円の三面図 例えば、渡辺幸三氏が下記記事にて、ご自身の「三要素分析法」を説明するのに用いています。『一つの開発対象システムだが、「データモデル」、「機能モデル」、「業務モデル」の三つの異なる視点、観点がある。各観点での設計をそれぞれ行って擦り合わせることで、対象システムの実体が浮かび上がる。』、、、このような趣旨の説明をされています。 I
マイクロサービスに関する資料のまとめ
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
『データ解析のシステムからCQRSについて学ぼう』
どすこい！ 昨年ぶりです！最近よくお相撲さんを見る@sitotkfmです！ またエンジニアブログを書かせて頂くことになりました！ 今回のトピックですが、最初は前回同様ストリーミングアルゴリズムでも発表しようかと思ったんですが、まああんまり受けが良くなかったので今回はパスで。。。(同期に「お前Advent Calender書いてたのかよ」と言われました。。。) それとあの後業務で本当にSparkをつかうことになりまして、まあ、えっと、本当に大変ですね。。。 さて今回のエンジニアブログではCQRSについて説明したいと思います。 CQRSが何故必要なのか まずドメイン駆動設計(Domain-Driven Degien)という、ビジネスの概念の抽象化であるドメインの要求を最優先として設計を行うソフトウェアの設計思想があります。 ここではドメイン駆動設計について説明しだすと主題から外れかねないのと私
Greg Young流CQRS - Mark Nijhof - Digital Romanticism
この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ
Atlas: Building with Rails and Go Microservices
Atlas is a recently announced service by HashiCorp that provides a single platform to take an application from development through to production. The complexity of the problem makes Atlas a sophisticated web service that is composed of many moving pieces. This article covers the design of Atlas, and specifically the use case of pairing a front-end Rails application with a collection of Go microser
YAPCでおもしろ発表してきた - hitode909の日記
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
今話題のReact.jsはどのようなWebアプリケーションに適しているか？ Introduction To React─ Frontrend Conference
今話題のReact.jsはどのようなWebアプリケーションに適しているか？ Introduction To React─ Frontrend Conference 外村 和仁（株式会社 ピクセルグリッド） 本記事は、2015/2/21に行われたFrontrend Conferenceの「Introduction To React」の内容を紹介します。 当日の資料は以下にアップされていますので、こちらも参照してください。 Introduction To React // Speaker Deck React.jsとは何か React.jsはFacebook製のJavaScriptライブラリです。 http://facebook.github.io/react/ 公式サイトに、「A JavaScript library for building user interfaces」とあるように、R
SMACSS 読んだ - CHROMA
Scalable and Modular Architecture for CSS (日本語) を読んだのでそのメモです。 CSSルールのカテゴライズ カテゴライズを行い、それに準じた命名をセレクタに付ける。 ベース レイアウト モジュール 状態（ステート） テーマ レイアウトには1つ以上のモジュールを保持する必要がある。 モジュールは最利用可能なパーツとする。 命名規則 レイアウト、状態（ステート）、モジュールにはプリフィックスを使用する。 レイアウトのスタイルにはlayout-を付ける。または、ドキュメントなどでコーディング規約をまとめてあるなら省略してl-と付けても良い。 状態（ステート）にはis-を付ける。 モジュールは作成される数が多いので、モジュールごとにプリフィックスを付ける。 /* Example */ .comment { } .comment-user { } ベースル
DI コンテナがコードに出現するのは dependency lookup が行われている兆候
Dependency Injection (DI) コンテナを基盤にしたアーキテクチャを採用している場合に、(プロダクト|テスト)コードに DI コンテナが登場するのは dependency lookup (依存コンポーネントの検索)を行っている兆候と考えることが出来ます(もちろん必要があってコンテナの injection が行われている場合もあります)。 テストに DI コンテナが出現することに気付いたら、 Dependency lookup から Dependency Injection (DI) へのリファクタリングの契機とすることもできるでしょう。 続きを読む
プログラミング地獄への道は“ベストプラクティス”で敷き詰められている：Rails Hub情報局：エンジニアライフ
Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日本人（あるいはアジア人）として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏（以下、通称のDHHを使います）は、プロジェクトをリードするという意味で活動が活発になっているそうです。 そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った（opinionated）なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。 DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twit
八角研究所 : POSA 本でアーキテクチャパターンを勉強しよう（1） - パターンとは何か？
POSA 本でアーキテクチャパターンを勉強しよう（1） - パターンとは何か？
インターフェイス志向設計を読んだメモ - voidy21の日記
積読消化したい インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践 作者: Ken Pugh,角谷信太郎(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2008/05/24メディア: 大型本購入: 16人 クリック: 337回この商品を含むブログ (66件) を見る 契約しようよ！ 契約とは、 インターフェイスを実装するモジュールが守らなければならない(守るべき)約束 インターフェイスのユーザーと実装の間に成立する約束事 インターフェイスの三原則 1. インターフェイス実装は、そのメソッド名が示す通りの処理をしなければならない メソッド名から実装が行う処理が想像できるか メソッドの目的と意味合いがその名前と実装場所だけでは明確に連想できない場合、しっかりと文書化されてないといけない(テストにも言及した方がよい) 「インターフェイスの文書化はとても大切
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
StrangeIoC
Webサービスの思想とかについて考えてた。#esa_io #ﾄﾉｺﾄ
書籍『SQLアンチパターン』に関するつぶやきまとめ #sqlap
