Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
A couple of years ago I was talking to a couple of friends of mine who were doing some work at eBay. It's always interesting to hear about the techniques people use on high volume sites, but perhaps one of the most interesting tidbits was that eBay mostly hardly ever uses database transactions. For most people, coming into a transactionless environment is quite a shock. Using transactions is a ver
システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践) 作者: ニック・ロザンスキ,イオイン・ウッズ,榊原彰,牧野祐子出版社/メーカー: 翔泳社発売日: 2008/12/03メディア: 大型本購入: 15人 クリック: 355回この商品を含むブログ (16件) を見る アーキテクチャ設計の際には、ぜひ手元に置いておきたい一冊。 設計に関する書籍はスタイルやパターンについて書かれたものが多いが、本書はステークホルダ、スコープ、パターンに始まり、データ構造、運用、セキュリティ、パフォーマンスなど取り扱う範囲が非常に広い。 しかし網羅性は高いものの、各項目はそれほど詳細に記述されているわけではない。詳しく学びたい場合は、各章で参考文献が紹介されているので、それらを参考にするのがよいだろう。 また、実際の設計の
「大規模サービスの運用事例まとめ」をすべて読んでいる時間がない人はこの一枚のスライドだけでも見ておくといいかもしれない。 tech days Japan 2009 の萩原正義さんのセッション「クラウドコンピューティングのエッセンス」のスライド 33 枚目にこう書いてある。(ちなみにこれはエンタープライズアプリケーションの話。) N-tier モデル 密結合が条件 障害がないことが前提 ACID トランザクションが前提 データ層がボトルネック 新しいアーキテクチャ Scale out Key-value データ 非一貫性モデル 非同期 REST, AtomPub 関数型での処理 via http://www.microsoft.com/japan/powerpro/techdays/default.mspx の T1-401 のセッション。 それぞれについての詳しい解説は上記からダウンロード
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは2つあります。 (1)言語やフレームワークの選択自由度が上がる 現在運
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります インフラの設計をレビューする方法って、何があるのでしょうか? 多くの現場では”経験に基づいた判断”程度ではないでしょうか? 私がお勧めしているのは、ATAM(Architecture Tradeoff Analysis Method)です。「シナリオ」と呼ばれる”ある事象”においてどんな振る舞いを起こすのかを確認することで、リスクや危ない点、トレードオフなどを洗い出し、アーキテクチャの品質を確認することができます。 ATAMの解説PDF(英語)です。日本語は書籍で(ピラミッドのような絵が表紙の「実践ソフトウェアアーキテクチャ」 が良いと思い
濱野智史さんの『アーキテクチャの生態系』を読んでいる途中なのですが、この「アーキテクチャ」の肯定的な捉え方に、RailsとRESTの関係が思い起こされたのでメモを。 濱野さんによる『アーキテクチャの生態系』の紹介はこちら。 アーキテクチャって? ここで呼ばれている「アーキテクチャ」とは、ローレンス・レッシグ『CODE』で説明されていたものです(最近はver. 2.0が出ています)。 レッシグさんは、人の行動や社会秩序をコントロールするためには、4つの方法があると言っています。それは、規範(慣習)、法律、市場、そしてアーキテクチャです。たとえばタバコを吸わせないように人の行動をコントロールするためには、これら4つの方法をどのように使えるでしょうか。 規範(慣習) 人の行動はマナーのような規範で制約することができます。分煙という規範は喫煙者に制約を与えます。もしくは「煙草は体に悪い」という言
id:ZIGOROu に連れてくると言われたままペンディングしていたので,今回行ってきました. http://kunit.jp/restful/wiki/index.php?%C2%E86%B2%F3%CA%D9%B6%AF%B2%F1 会場は株式会社ディノさんのセミナールームで,会場提供のみならず,なんとビールが振る舞われました.ディノ++ 以下,感想というよりは,たけまるさんの問いに答えておく. AtomPub が標準化されて楽になりましたか? サービス実装という立場で考えると「楽になった部分と変わらない部分がある」と思う. AtomPub は,あさくらさんも言われていたように Atom Publishing Protocol という名前のプロトコル仕様の域にあるものだと思う.その観点で考えると(あらかじめリソースが定義されてるとして)そこにどう HTTP メソッドを適用していくか,と
Eric Newcomer: "This afternoon I finally caught up up on Steve Vinoski's recent article and blog entries about the "evils" of RPC. If you aren't already among those who have read them thoroughly, I'd encourage you to. Including the comments, it's one of the best discussions of the merits and demerits of RPC and REST that I've ever seen. The core of his argument is that the RPC abstraction is n
インターネットとは、技術的に言えば世界規模で張り巡らされたIPネットワーク網のことだが、パソコンの「インターネット」というアイコンをクリックすると、Webブラウザというソフトが立ちあがる。 IPネットワーク網が何であるか理解できるのはごく一部の人だけであり、適切なUI(ユーザインターフェース)を与える必要がある。Webブラウザができて初めて一般の人がインターネットとは何であるか理解したので、そのソフトウエアに「インターネット」という愛称を与えることは自然である。 Webブラウザが「インターネット」であったのと同じような意味で、iPhoneは「インターネット」になるだろう。 iPhoneは、もう一つの、一般の人にも使えるインターネットのUIである。Webブラウザによって世界規模で張り巡らされたIPネットワーク網の使い道が広がったのと同じレベルで、iPhoneによってもう一段階「インターネット
The End of an Architectural Era (It’s Time for a Complete Rewrite) Michael Stonebraker Samuel Madden Daniel J. Abadi Stavros Harizopoulos MIT CSAIL {stonebraker, madden, dna, stavros}@csail.mit.edu Nabil Hachem AvantGarde Consulting, LLC nhachem@agdba.com Pat Helland Microsoft Corporation phelland@microsoft.com ABSTRACT In previous papers [SC05, SBC+07], some of us predicted the end of “one size f
2. About Us Mark Baker Coactus Consulting CTO-level consulting and large-scale distributed systems architect Leading proponent of “REST style web services” for over seven years Prior work at Nortel, Sun Microsystems, and several startups Co-developed internet, mobile, and web standards through the IETF , W3C , and OMA Mark’s Blog http://www.markbaker.ca/blog/ mailto:mark@coactus.com Stuart Charlto
最近本腰を入れて大掛かりなアーキテクチャ設計をしようとしているが,ドキュメントを書く際にいつも帰ってくるのがこのエントリー. Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal: What should be in an Architecture Document? とても素晴らしい内容なので,以下に意訳しておきます.ぜひ原文も合わせて読んでみて下さい. - ドメインモデル (もしあれば),使用されているパターン,ガイドラインなどに特化したドキュメントを合わせて紹介すること.アーキテクチャドキュメントは,それらのガイドラインと整合性を保つこと. - 1つのドキュメントは50ページを超えないこと.肥大化したドキュメントは誰にも読まれない (少なくともその全ての内容は). - 当たり
_ [ソフトウェア] DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる サイボウズも memcached + MySQL DB 分散 Cybozu Developer Network: MySQL Users Conference Japan 2007 講演概要 を読んで、memcached でキャッシュ& 複数の MySQL をアプリのロジックで分散化というのは、もうすっかりスケーラブルなウェブアプリの作り方として常套手段になったと思いました。 2004 年 4 月の MySQL カンファレンスでの Brad Fitzpatrick の発表 Inside LiveJournal's Backend (PDF)から約 3 年半。Mixi やはてなのようなエッジな企業はだいぶ前からこの構成を採用してますが、対法人のビジネスをしているサイボウズでも採用されたというのは一つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く