タグ

architectureに関するtaketyanのブックマーク (20)

  • Beyond the 12 Factor App: Exploring the DNA of Highly Scalable, Resilient Cloud Applications

    In 2012, early cloud pioneer Heroku developed the Twelve-Factor App, a set of rules and guidelines for helping organizations build cloud native applications. It served as an excellent starting point, but as technology inevitably marched forward, some areas needed revisiting. To accommodate current best practices, this practical book expands on the original guidelines to help you build applications

    Beyond the 12 Factor App: Exploring the DNA of Highly Scalable, Resilient Cloud Applications
  • Microservices on Fastly

    RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub

    Microservices on Fastly
    taketyan
    taketyan 2017/10/18
    Fastly を Service Registry として使う、なるほど
  • Service-Oriented Architecture: Scaling the Uber Engineering Codebase As We Grow

    You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Like many startups, Uber began its journey with a monolithic architecture, built for a single offering in a single city. At the time, all of Uber was our UberBLACK option and our “world” was San Francisco. Having one codebase seemed “clean” at the time, and solved our c

    Service-Oriented Architecture: Scaling the Uber Engineering Codebase As We Grow
    taketyan
    taketyan 2015/10/12
    IDL の価値よくわかってないので Finagle でもさわってみるかな
  • YAPCでおもしろ発表してきた - hitode909の日記

    YAPCおもしろ発表してきた. はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話. speakerdeck.com なぜか大人気発表みたいになってて,会場満員で,すみませんこんなところに来ていただいてすみませんというかんじだった. 紹介したはこちら.予約投稿で仕込んであって,発表終わったら,こちらから買ってくださいとかやろうと思ってたけど,すっかり忘れてた. YAPCの発表で紹介した - hitode909の日記 質問たくさんいただいて,よいかんじにおさまったと思う. 「難しくて挫折するという問題がありますよね」「歯をい縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は?」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE

    YAPCでおもしろ発表してきた - hitode909の日記
    taketyan
    taketyan 2015/08/21
    めっちゃ良い。あらゆるレイヤで改善を積み重ねていて最高 / 途中でてくるPostEntry::Factory はデザパタ的には Builder っぽい
  • Martin Fowler氏の語る“犠牲的アーキテクチャ"

    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が最近リリースされ、重要な変...

    Martin Fowler氏の語る“犠牲的アーキテクチャ"
    taketyan
    taketyan 2014/11/14
    式年遷宮っていうとモノリシックな何かを丸ごと作り変えるってイメージがしてちょっと違う気がしてる。モジュール化してそれぞれをリプレース可能にする、という話なわけで。
  • 例えば OSFA な API をやめる - @kyanny's blog

    OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み

    例えば OSFA な API をやめる - @kyanny's blog
    taketyan
    taketyan 2014/03/10
    「REST から RPC へ」感。単純なリソースを表現する API で足りるものごとも多いし、両方あればいいと思う。パフォーマンスとかの要件に合わせて作り足していく感じ。
  • 次世代Webアーキテクチャーの話 (CROSS2014を聞いて)

    CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 (ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ

    次世代Webアーキテクチャーの話 (CROSS2014を聞いて)
  • ServiceとDCIについて - じゅんいち☆かとうの技術日誌

    面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識

    taketyan
    taketyan 2014/01/04
    難しいけど面白かった。ドメインモデル貧血症気をつけたい / Scala 楽しい。ブジェクトはイミュータブルで、一意性はBankAccountId でチェック、って感じなのかな。今年こそ覚えよう。
  • やはりお前らのMVCは間違っている

    PHPカンファレンス2012 & WordCampTokyo2012 LT発表資料です。 タイトルの元ネタ: http://www.amazon.co.jp/dp/4094512624

    やはりお前らのMVCは間違っている
    taketyan
    taketyan 2012/09/27
    個人的に ActiveRecord はじめ ORM それ自体はあくまでもモデルを支えるものであってモデルではないと思ってるんですがどうなんでしょう
  • フレームワークで語るMVCの話 : PHP Advent Calendar #19 - basuke の日記

    この記事はPHP Advent Calendarの19日目の記事です。 プログラマ10人集まれば、誰かMVCうんちく語るのが常。みんな大好きMVCの話です。僕は今年でPHPプログラマとして10年が経過しました。この節目の年に、これまで触ってきたフレームワークを振り返り、徹底的な個人的主観でMVCについて語っていきたい思います。忘年会シーズンでお疲れの皆様、ご安心ください。コード・ゼロでお届けします。 いろんな言語のいろんなフレームワークを触ってきたつもりですが、Javaはやってなかったんであまり詳しくないです。主にRails以降のフレームワークを見ていきます。 Railsの功績 PHPプログラマとしてRailsの登場で何にびっくりしたかというと、次の三つです。 router ActiveRecord cliと対話型shell ActiveRecordは魔法のように見えましたが、いずれ出ても

    フレームワークで語るMVCの話 : PHP Advent Calendar #19 - basuke の日記
    taketyan
    taketyan 2011/12/20
    Rails の C と M の関係性の奇妙さ / C にロジック突っ込むのは単に M を切り分けられない人がやることで Rails という文脈は関係無いと思った
  • PoEAA by Example

    Building Business & IT Architecture Roadmaps with ArchiMate & TOGAFCorso

    PoEAA by Example
    taketyan
    taketyan 2011/11/02
    明日覚えてたら読む
  • Quora’s Technology Examined - Big Fast Blog

    Quora has taken the tech and entrepreneurial world by storm, providing a system that works so fluidly that it is sometimes hard to see what the big fuss is all about. This slick tool is powered, not only by an intelligent crowd of askers and answerers, but by a well-crafted backend created by co-founders who honed their skills at Facebook. It is not surprising that, with all the smart people using

    Quora’s Technology Examined - Big Fast Blog
    taketyan
    taketyan 2011/08/20
    Quora を支える技術.
  • DataMapper - Why DataMapper?

    Why DataMapper? DataMapper differentiates itself from other Ruby Object/Relational Mappers in a number of ways: One API for a variety of datastores DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and even some popular webservices. There’s a probably incomplete l

    taketyan
    taketyan 2011/05/21
    何故 DataMapper か, というお話.
  • MVVMによるSilverlightアプリケーションの開発(その1)

    はじめに Silverlightに限らない話ですが、ページからのイベントに対する処理をすべてイベントハンドラに記述してしまったために、再利用性が著しく低かったり、単体テストがひどくやりにくいシステムを見たことはありませんか? これは、プログラムの機能をすべて同じ層に記述していることが原因の1つです。 この問題に対するSilverlightでの解決策の1つが、MVVMパターンです。今回はMVVMパターンと、MVVMパターンの要となるデータバインディング、コマンドバインディングについて2回にわたって解説します。 MVVMパターンとは MVVMはModel-View-ViewModelの頭文字をとった、アプリケーションの階層化パターンの1つです。階層化パターンを適用することで各層の依存関係が薄くなり、アプリケーションの修正、複数人数での分散開発、単体テストなどが実施しやすくなります。 Expre

    taketyan
    taketyan 2011/05/05
    スマートフォンアプリ開発に活かせるかなー.
  • OTN Japan - 今だからデータ・アクセスを真剣に考える! 第2回

    前回の「データベースことはじめ(前編)」では、システムの論理的な階層の中でドメイン層をどの様に実装するかということで、PoEAAのアーキテクチャパターンを元に見てみました。今回は、パーシステンス層のアーキテクチャパターン+αを見ていきます。 まずパーシステンス層を見る前に、今回の話題とは直接ではないですが、間接的に関わってくる層のサービス層に関して少し触れておきたいと思います。サービス層は、ドメイン層配下のビジネスロジックをユーザインタフェース層やアプリケーション層から利用するためのインタフェースとして機能します。一般的にトランザクションロジックやセキュリティロジック、ドメインロジックのワークフロー等のドメインロジックとは直接関係ないロジックを含むのみで、大きなドメインロジックを含むことは好ましくないとされる層です。 では、パーシステンス層です。ここまで、役割的には、データアクセスの実装を

  • 『スロット ハワイアン ドリーム』|豪 血 寺 一族 パチンコ|cr オグリ キャップ・栃木県佐野市|長野県筑北村|美空 ひばり パチンコ

    広島県北広島町 パチスロ かぶき ものがたり Basic Strategy Counting DIA 4th ミニアルバム「Summer Ade」ティザー映像公開 爽やかなルックスのおまけスロットマシン シンガポール 中泊町 大工 の 源 さん 超 韋駄 天 ボーダー ジェリーフィッシュ・エンタテインメント・ジャパン株式会社 インタラクティブ・メディア・ミックス株式会社td 長崎県島原市 ニューギン 009 (G)I-DLEがフラッシュモブに参加したファンとタイムズスクエアの前でポーズをとっている画像。 豪 血 寺 一族 パチンコ マクロス f パチンコ 初代 パチスロ ガメラ 導入 日 新曲「雨が降ったら」MVティザー映像 [ウングァンInstagram全文] こんにちは 5ch スロット 機種 福岡県宗像市 キョンシー パチンコ 自身のインスタグラムに「2週間前の稽古場で…明るくて優し

    taketyan
    taketyan 2010/12/11
    ちょっと長くて難しそうだけどあとで読もう
  • Guice(ジュース)を早飲みしすぎていませんか?

    垂直スケーラビリティと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化 Peter Lawrey氏はJavaチャンピオンであり、Chronicle SoftwareのCEOとして、開発者を鼓舞してソリューションのクラフトマンシップを高めることに情熱を注いでいる。経験豊富なソフトウェアエンジニアとして、Lawrey氏はソフトウェア開発プロセスにおけるシンプルさ、パフォーマンス、創造性、革新性を奨励することに努めている。

    Guice(ジュース)を早飲みしすぎていませんか?
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • PofEAA's Wiki - (ファウラー | 読書会)

    PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。

  • Catalog of Patterns of Enterprise Application Architecture

    Catalog of Patterns of Enterprise Application Architecture Last Significant Update: January 2003A short summary of the patterns in Patterns of Enterprise Application Architecture (P of EAA). These pages are a brief overview of each of the patterns in P of EAA. They aren't intended to stand alone, but merely as a quick aide-memoire for those familiar with them, and a handy link if you want to refer

  • 1