2018年12月14日に行われたJaSST Review'18（ソフトウェアレビューシンポジウム 2018）での講演「アーキテクチャのレビューについて」の資料ですRead less
2018年12月14日に行われたJaSST Review'18（ソフトウェアレビューシンポジウム 2018）での講演「アーキテクチャのレビューについて」の資料ですRead less
What is Jamstack? Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability. Jamstack removes the need for business logic to dictate the web experience. It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs. The Roots
Modular MonolithというアーキテクチャをRailsアプリケーションへ適用する記事を読みました。 medium.com モノリスアーキテクチャとマイクロサービスアーキテクチャの中間に位置する、一つのモノリシックなアプリケーション内でドメインごとにモジュールに分解しつつ運用するためのアーキテクチャを、Railsでどのように実装するか、という内容です。 Modular Monolithとは 記事から引用します。 Rather than extracting microservices, we decided to first focus on making our app modular. Our goal was to identify good architectural boundaries before we extracted code out into independ
翻訳を担当した書籍『進化的アーキテクチャ ― 絶え間ない変化を支える』（オライリー・ジャパン）が8月18日に出版になります。原書は2017年に出版された『Building Evolutionary Architectures ― Support Constant Change』（O'Reilly Media）です。 O'Reilly Japan - 進化的アーキテクチャ 現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ
Railsを使ったアプリケーションの特定の場面では、「サービスレイヤ」や「サービスオブジェクト」という概念を導入すると有効に機能することがあります。今回は、その紹介をします。 まず、サービスレイヤとは何でしょうか。『Patterns of Enterprise Application Architecture（以下、P of EAA）』では「サービスレイヤは利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる」と定義されています（参照）。ユーザーインタフェースなどからの呼び出しを受け付けるアプリケーションの境界として、ビジネスロジック、トランザクション制御、レスポンスなどの取りまとめをするのが、サービスレイヤの役割です。 では、どのようなときにサービスレイヤを導入するのでしょうか。P of EAAには、次のように記述されています。 You probably don’t
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケ
ソフトウェア開発、すなわち、アジャイル開発プロセスやアーキテクチャ設計、UXデザインなど、における発想をソフトウェア開発以外に用いても役立つことは多い。 少し前になるが、ある事業の相談を受けたことがある。ここではそれを架空のコンビニ事業に置き換えて説明しよう。架空なので、現実的ではない部分も多いが容赦願いたい。 コンビニ各社は店舗で買い物するのが出来なかったり、店舗を訪れるのが面倒に感じる顧客のためのデリバリーサービスを持っている。このデリバリーは実際はいわゆる通販であり、宅配ピザのように短時間で配達されるものではない。だが、ここでは例として、コンビニがある特定の商品に限っては極めて短時間で配達するというサービスを展開していると仮定する。また、（出来るだけソフトウェアとは遠い処理の例にするため）注文はコールセンターで電話で受けるものとする。 この短時間での配達を約束している特定商品を「アル
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
Why People Want Microservices.md マイクロサービス化が進む背景について考えてみた 最近マイクロサービスって流行ってますよね。バズってると言ってもいいくらい。 個人的には、「マイクロサービスって結局何なの？」とか、「SOAと何が違うわけ？」とかいう議論は苦手です。 でも「なんでみんなマイクロサービスで作りたいのか？なんでマイクロサービスで作られるサービスが多いのか？」にはすごく興味があるんです。 僕は今、シリコンバレーにある日系SIerの小さな子会社で駐在員をやっていますが、このエリアに居ると、とにかく最近、 「サービス全体が、独立した小さなサービスの集合で構成されるようになってきている」 という流れがあるのは実感できます。もうそれが前提みたいになってるくらい。普通サービスって依存サービスを幾つか呼び出しますよね？ってところから始まるのが普通なくらい。 この記
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
マイクロサービス（microservices）という言葉をご存知でしょうか？ 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
