Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す
as, box2dワリオランドシェイクと YouTube のコラボプロモーション が面白かったので、似たようなものを作ってみました。次の文字列をコピーしてアドレスバーに突っ込むと、HTML が崩壊します。javascript:(function(){var d=document; var s=d.createElement("script"); s.charset="UTF-8"; s.src="http://tech.nitoyon.com/meltdown/meltdown.js?"+(new Date()).getTime(); d.body.appendChild(s)})();崩壊するのは画像だけなので、画像があるページで試してみてください。このブログだとこんな具合。画像はドラッグすることも可能です。あまり画像が多いと重くなりすぎるのでご注意を。仕組みFlash と JavaSc
はじめに 自分がAWSをこれっぽっちも知らない頃、 ググって出てきたどこか知らんサイトからだと、「欲しい情報はこれじゃない」ってのが多くあった。 そんなこと繰り返していると エラー、トラブル時に即対応できない 間違って構築したせいで運用時に悪化してしまう 古いソースコードでエラーがでて動かない これで無駄な時間を過ごすことになる。 要は「ググって得たその情報で、作ったものは正しいのか?」 AWSは常にアップデートされ続ける 欲しい情報を手に入れるまで調べる時間を割くなら、 公式展開してるサイトから得たほうが正確である。 ということで、最速でAWSを攻略するサイトをまとめる。 この記事をブックマークでもしておくと、ググる手間も省けるだろう。 目次 AWSドキュメンテーション AWSサービス別資料 トレーニングライブラリ AWSブログ アーキテクチャーセンター ワークショップをする よくある質
あー、やっとアーキテクチャ(システムの構造、の意)が完全に変わるんだ。っていう感想。 私が交通系ICカード開発の仕事に関わってたのがもう20年近く前で(正確には15〜6年前)その頃から今日まで全くアーキテクチャの基本構造が変わってなかったんですよ。 www.watch.impress.co.jp www.itmedia.co.jp 20年変わらないってのも、なかなかすごいよね。ある意味、完成された構造だったわけですけども。 とはいえ通信速度が向上したら、ネットワークの信頼性が向上したら、いずれこの形になるのは想定されてました。 逆に言うと20年経ってようやく「新しい形式に移行できるぜ!」ってなったわけで、検証もこの間に重ねられてきてたって事だと思います。 思いつきで移行なんかしないですよ、鉄道会社の方々って。 だって障害発生したらニュースになるんだものw 私は過去に下記のようなブログとかも
「最近、モダンモダンすげぇ聞くけどモダンってなに?」 「人の数だけモダンはあるんだよ…」 近年、パブリッククラウドを主軸としたアプリケーション開発文脈の中で「モダンアプリケーション」という言葉をよく聞くようになりました。自分もMAD(Modern Application Development)事業部の部長を去年やっていたりして、モダンという言葉には人一倍敏感だったりします。 そんなおり、そのモダンアプリケーションについて真正面から解説する本を、著者の落水さんから献本いただいたので、僭越ながら書評という形でご紹介させていただきます。 モダンがなにかようやくわかるの…!? ( ゚д゚) ガタッ / ヾ __L| / ̄ ̄ ̄/_ \/ / 丸わかりやで。 書籍の概要「AWSで実現するモダンアプリケーション入門」 AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイ
この記事は,ネットワークの学習の序盤につまずくポイントである 「MACアドレスとIPアドレスってどっちか片方だけじゃだめなの?」「レイヤ2と3って結局何が違うの?」 という疑問について,私なりの回答をまとめた記事です。世に不正確な記事が出回っているように見受けられるので,正確な回答をまとめたく、長文になってしまいました。とはいえ,初学者向けにかなり初歩的なところから書いたつもりですので是非読んでみてください。 この記事について この記事を読むと何が分かるか MACアドレスとIPアドレスの役割の差が分かる レイヤ2(=同一サブネットの通信)とレイヤ3(=サブネット間の通信)の仕組みが分かる ネットワーク設計時にレイヤ2・レイヤ3のいずれで設計すべきか判断できる なお,教科書的な説明ではなく,概念や捉え方の説明となっていますので,試験勉強には役立ちません。実務としてネットワーク設計を行う方の役
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための(レスポンスボディに載せられる)標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
はじめまして。デジタル庁ファクト&データユニット所属、データエンジニアの長谷川です。 本記事ではデジタル庁内でデータ活用を推進するための組織と分析基盤についてご紹介します。 これまでのデジタル庁noteと比べると、技術寄りの話題が多い記事となりますが、庁内のデータ活用に興味のある方はぜひご覧ください。 デジタル庁のデータ活用組織「ファクト&データユニット」ファクト&データユニットとはデジタル庁の特徴の一つに、デジタル分野において各種の専門性をもつ「民間専門人材」が多く所属していることが挙げられます。 民間の専門人材は、デザイン、プロダクトマネジメント、エンジニアリングなど、領域ごとに「ユニット」と呼ばれる組織を構成しており(参考:デジタル庁 - 組織情報)、必要に応じてさまざまなプロジェクトにアサインされて業務を遂行する、人材プールのような役割を果たしています。 ファクト&データユニットも
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著?著者のロバート・C・マーチン(著書読んだことあるかも?)は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基本原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った.未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった.本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し,なぜやるべきか?・なぜ避けるべきかを整理する. Microservices? Microservicesアーキテクチャとは「Single purpose,High cohesion,そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である.それぞれの原則をまとめると以下のようになる. Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
地雷キャッチャーとして定評のあるfladdictですが、今回も大量の地雷を踏み歩いております。 とりあえず、解決方法を知らないとハマるポイントを色々とピックアップ。自分では直ったけど一般化できてない現象もあるので、間違い勘違い等ありましたら、コメント欄でビシバシご指摘ください。 iPhone5対応すると、iOS4.3以前では動かなくなる 最新のXCodeがarmv6のコンパイルをしてくれないので、ご臨終となります。 公式じゃないほうほうで無理矢理バイナリをビルドすればhogehoge。 サードの静的ライブラリが入ってると、コンパイルできない場合が 最新XCodeからコンパイルに、armv7sという新アーキテクチャが必須となってますが、ビルド済み静的ライブラリにはむろん入っていないのでコンパイルできません。対策は2つあって、ひとつは対応ライブラリが出るまでリリースを見送ること、もう片方はXC
2024/3/21 「GNOME 45.5」リリース 2024/3/21 JavaScript/TypeScript対応Webフレームワーク「Astro 4.5」リリース 2024/3/21 ELYZA、700億パラメータの大規模言語モデル(LLM)「ELYZA-japanese-Llama-2-70b」の開発を発表 2024/3/19 Linuxディストリビューション「4MLinux 45.0」リリース 2024/3/17 セキュリティを重視した「Proton mail」のデスクトップアプリケーション発表 2024/3/17 PHP向けWebアプリケーションフレームワーク「Laravel 11」リリース 2024/3/17 「Samba 4.18.11」リリース 2024/3/16 Visional、脆弱性管理クラウド「yamory」のAWS Marketplaceにおける提供開始 20
もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害:大規模は5年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対
本書は、Micro Frontends Architecture Patternsというタイトルを付けていますが、モノリスからJAMstack、Micro Frontendsまで、Webフロントエンドを包括した様々なアーキテクチャパターンの詳細を体系的に紹介しています。 ソフトウェアとしてのアーキテクチャ全体を俯瞰し、他のシステムとのやりとりを設計するような考え方が役に立つことは多いです。フロントエンド観点で、様々なアーキテクチャパターンをまとめることで、Web開発の助けになればと考えています。 また、アーキテクチャの歴史と変遷を知ることで「Micro Frontends」への理解を深めることができると筆者は考えました。Micro FrontendsはThoughtWorksのTechnology RadarではすでにADOPTとなり、海外で多くの事例が存在します。Micro Fronte
Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基本は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
ソーシャルゲーム開発に関するスライド資料をまとめてみました Tweet 2011/1/28 金曜日 matsui Posted in 記事紹介・リンク | 5 Comments » 最近は、ソーシャルゲーム開発に関するスライド資料が多く公開されており、各所で人気を集めているようです。 これらのスライド資料は、高負荷・大量アクセスを捌くための工夫がちりばめられており、とてもためになるものが多いです。 今回はそんなソーシャルゲーム開発に関するスライド資料をまとめてみました。 まずは手前味噌ですが、昨年のOSC北海道での発表に使わせて頂いた私のスライドです。 ブラウザ三国志を開発した際に苦労した箇所などをまとめました。 → ke-tai.org OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」 [ke-tai.org] PHPで大規模ブラ
岡野原です。Deep Learningが各分野のコンペティションで優勝し話題になっています。Deep Learningは7、8段と深いニューラルネットを使う学習手法です。すでに、画像認識、音声認識、最も最近では化合物の活性予測で優勝したり、既存データ・セットでの最高精度を達成しています。以下に幾つか例をあげます。 画像認識 LSVRC 2012 [html] 優勝チームスライド [pdf], まとめスライド[pdf] Googleによる巨大なNeuralNetを利用した画像認識(猫認識として有名)[paper][slide][日本語解説] また、各分野のトップカンファレンスでDeep Learningのチュートリアルが行われ、サーベイ論文もいくつか出ました。おそらく来年以降こうした話が増えてくることが考えられます。 ICML 2012 [pdf] ACL 2012 [pdf] CVPR
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
初めまして、インフラストラクチャー部の加藤 (@EugeneK) です。 クックパッドでは現在178万ものレシピが公開されていますが、目的のレシピを探すために検索機能を提供しています。 今回は検索機能の裏側の仕組みについて、インフラストラクチャーの観点からお話ししようと思います。 全ての検索機能を支えるSolrと周辺のアーキテクチャ クックパッドにはレシピの検索だけでなく様々な検索機能がありますが、その全てはSolrを活用して実装されています。 以前はMySQL Tritonnによる全文検索機能を使用していましたが、2011年頃からSolrに切り替わりました。 クックパッドではSolrをマスタ - スレーブ構成にすることで冗長性と負荷分散を実現しています。以下の構成図をご覧ください。 マスタとスレーブの間には、リピータと呼ばれる検索インデックスを中継するためだけの役割のサーバがいます。この
ChatGPTとLLMシステム開発について纏めた187ページ資料です。 2024/04 名称を改め資料を大幅にアップデートしました! 今後も随時更新していきます。 データサイエンティスト協会での発表動画はこちら。 https://youtu.be/l9fpxtz22JU Build Japanでの発表はこちら。 https://youtu.be/UEZzx6a005g?si=Ot8EO2bv8yhQQEcy 2023/7/28 体裁修正、余計なページを削除 2023/12/12 RAG、API仕様、モデルのページを追加。また情報を最新化。 2024/04 名称を改め資料を大幅にアップデートしました! 1. LLM - GPTの全体像 LLM - GPT とは何なのか ~チャットAIを例にした動作イメージ~ 大規模言語モデル(LLM)が持つ基礎能力 デジタルツールとLLMの連携 GPTに関す
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(前編) 仮想化やクラウドを基盤とした新しいインフラの考え方である「Immutable Infrastructure」が注目されています。3月25日、このImmutable Infrastructureをテーマに渋谷のDeNAオフィス大会議室で開催された勉強会「Immutable Infrastructure Conference #1」は、150人の定員に400人以上が申し込む人気ぶりでした。 これまでのImmutable Infrastructureに関する議論はおもにデプロイなど運用とインフラ周りの話題が中心でしたが、最初のセッションで登壇した伊藤直也氏は、Immutable Infrastructureが結果的にアプリケーションアーキテクチャにも大きな影響を与えるため、アプリケ
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture 達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう!プロセス設計 ~要件定義のその前に はじめよう! 要件定義 ~ビギナーからベテランまで はじめよう!システム設計 ~要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
本当にScala化できるんですか? 増井:今日は、チャットワークをPHPからScalaに切り替えるお話を伺うためにやって来ました。 山本:はい。 増井:僕がこの話を知ったのは、ちょうど2年ぐらい前に読んだブログのエントリだったんです。いきなり失礼なんですが、僕はこの話を知って、ぶっちゃけアホじゃないかと思ったんですよ。 山本:あはは(笑) 増井:基本的に開発言語やフレームワーク、方法論を同時に変えるって結構大きな変更ですよね? 山本:そう思います。 増井:それなのに、この決断を発表された当時、御社にはScalaエンジニアがいなかったそうじゃないですか。「本当に大丈夫なのかな?」と思って、気になってたんです。昨年春には「Scala採用を決めて一年たった、CTOの雑感」というエントリをポストされていましたが、さらに1年経った今はどんな状況なんですか? 山本:ひと言で申し上げると「絶賛移行中」と
Fumihiko Shiroyama @fushiroyama 父、博士課程 Senior Software Engineer @Microsoft 👨🏻💻 / ex-@amazon All opinions are my own. note.com/fushiroyama/ Fumihiko Shiroyama @fushiroyama Twitterみたいな緩いつながり、TLひとつ実装するだけでも普通のウェブシステムみたいなクエリでは取れなくてちょっと考えれば非常に複雑なシステムであることは明白だし、システムアーキテクチャの試験の定番トピックだったりするので「誰でも作れる」とか「簡単」みたいなのはご指摘申し上げたくなる 2022-11-22 02:16:50 Fumihiko Shiroyama @fushiroyama 昔つぶやきましたが例えばこの記事を読むと分かりやすいです
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは?(前編) Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
Latency numbers every programmer should know — Gist L1キャッシュ参照 0.5ナノ秒 分岐予測失敗 5ナノ秒 L2キャッシュ参照 7ナノ秒 Mutexのロックとアンロック 25ナノ秒 メインメモリー参照 100ナノ秒 Zippy[Snappy]による1KBの圧縮 3,000ナノ秒 1Gbpsネットワーク越しに2KBを送信 20,000ナノ秒 メモリーから連続した1MBの領域の読み出し 250,000ナノ秒 同一データセンター内におけるラウンドトリップ 500,000ナノ秒 ディスクシーク 10,000,000ナノ秒 ディスクから連続した1MBの領域の読み出し 20,000,000ナノ秒 パケットを、カリフォルニア→オランダ→カリフォルニアと送る 150,000,000ナノ秒 Jeff Dean著(http://research.googl
理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く