[B! programming][Arch] nyopのブックマーク

nyop id:nyop

programmingとArchに関するnyopのブックマーク (6)

マイクロサービスと設計原則 / Microservices and Design Principles - Speaker Deck
サーバー間 GraphQL と webmock-graphql の話 / server-to-server graphql and webmock-graphql
nyop 2018/11/09
現実的なアプローチがよくまとまってる。

it

Arch

programming
リンク
Microservice Integration Patterns
nyop 2018/03/13
IT

SAP

programming

Arch
リンク
「ソフトウェアの時代」について - 急がば回れ、選ぶなら近道
まぁなんか適当に思うことを。 ■ハードの限界の露呈ムーアの法則の限界はITのあり方を根本から変えると思う。この四半世紀、ITの現場レベルでは「困ったらハード増強」が一つの基本政策であったことは間違いない。ハードウェアの進歩は結果として、IT全体のパフォーマンスを上げ、結果として社会における有用性を増した。その一方でハードウェアの高進はソフトウェアの進化を止めていた側面は確かにある。ソフトウェアのレイヤー、とくにミドルレイヤー〜アプリケーションのレイヤーでは、通信にしろ、分散処理にしろ、DBにしろ、OSにしろ、「業界全体としてトコトンできるレベルまでやったのか？」という意味では、実際はやっていないと思う。もちろん、各セグメントではそれなりに追求はしたけど、ドカドカ、金突っ込んで全部ひっくり返すというまでには至っていない。これはIT全体に言えることだけど、ソフトウェアにコストをかけるよりも
nyop 2016/12/09
"表面上はビックデータ・IoT・AIとかなんかそんな感じのバズワードが百花繚乱になるとは思うけど、その下の地層レベルでは相当な変動がおこっている" ほんまこれ。アプリ屋やアーキ屋として考えるべき事が山ほどある。

IT

SI

programming

Arch
リンク
分散システム処理モデルに関する動向について（MapReduceからBorgまで）
詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化（限定）されたモデルであったと言えます。また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
nyop 2015/06/11
it

programming

Arch
リンク
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ．概要 “Microservices” とはソフトウェアシステムの開発スタイルである近年このスタイルでの開発を見てきて良い結果が出ている初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりするこれらのサービスは独立して自動デプロイされる一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい一般的なエンタープライズのア
nyop 2014/12/21
ふむー。結果SOAに近くなる気もする。

it

programming

Arch
リンク
MVCの流れを簡単にまとめてみる - Qiita [キータ]
理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
nyop 2014/01/15
it

programming

design

Arch
リンク
1