モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より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が最近リリースされ、重要な変...
プロジェクトではなく、プロダクトで思考せよ
プロダクトを中心に構築された組織は、エンドツーエンドで作業を監視する。Conwayの法則を逆転して、プロダクトに基づいた長期的なチームを確立することにより、組織が安定すると同時に、作業の管理と優先順序付けが容易になる。レトロスペクティブはプロダクト管理の強力なツールだ – 継続への自信を与え、組織に対するリスクや損失の可能性のあるものを素早く見つけ出せるようにしてくれる。 アジャイルコーチでトレーナ、講演者、コンサルタントのArdita Karaj氏は、eXperience Agile 2018で、“What’s my product”と題した講演を行う。同カンファレンスは10月1～2日、ポルトガルのリスボンで開催される。 InfoQではeXperience AgileをQ&Aや要約、記事などでお伝えする予定である。今年のテーマは“人々を通じた改善”だ。 世界各地から集まった業界のトップリ
SOAの未来はRESTか
最も単純な場合、サービスは必要なものをすべて含んだ、独立して開発、配置、管理、メンテナンスができるソフトウエアの実装であり、企業の特定のビジネスと関係のある機能をに提供し、設計によって"統合可能"である、と言えます。ある“サービス”は動詞で定義できます(例えば、“顧客の信用度を検証する”、というふうに実現する機能を表現します)。 サービスはプログラミングの構成概念ではありません。APIのセットでもありません。むしろ、企業の問題解決のために実装される、設計物(部品の設計、実装、メンテナンス)と配置物です。サービスの機能性はサービスのインターフェイス(そのサービス特有の)によって定義されます。このインターフェイスは複数の実装方法で実現できます。サービスのインターフェイスを定義するにはふたつの基本的な方法があります。RPCスタイルとメッセージングスタイルです。RPCスタイルの実装はサービスの起動
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
アジャイルは”再び"死んだ
Mathew (Ford) Kern氏とMilko氏は先日，どちらも“アジャイルは死んだ(Agile is Dead)”と題した記事を書いた。この話題を，Kern氏は，アジャイルコンサルティングの飽和とハイプサイクルの速さに関連するものとし，Miko氏は，アジャイル活動の具現化したアプローチの速さを越えるために，アジャイルからDevOpsへと進化する必要性を説いている。 Kern氏の最初の記事のタイトルは，“Agile is Dead”そのものだ。意識的に物議を醸すような(そして皮肉な)スタンスを選んだ氏は，次のように言う。 アジャイルソフトウェア開発は死にました。実践している人はドアストップです。管理手法として用いている人はボートの錨です。波は過ぎ去りました，もう終わりです。騙されて資格を取った人は，残念ですがお金の無駄でした。 氏はさらに，マーケティングとマネジメントに関する流行とセン
RDBMSでは不十分
リレーショナルデータベースはクライアント/サーバモデルに適合するものの、サービスの世界では新しいソリューションが必要である(source)。RDBMSはスケーラビリティの問題に陥りやすい。冗長性や並列性をどのようにして実現すればいいのか(source)？ （リレーショナルデータベースは）単一故障点となります。特に複製はささいな事ではありません。疑問に思うのであれば、全く同じデータを必要とする2つのデータベースサーバがあることによって起こる問題を考えて見てください。データを読んだり書いたりするために両方のサーバがあると、同時に変更するのが困難になります。マスターサーバとスレーブサーバがあっても、良くありません。なぜなら、マスターはユーザが情報を書き込む際、沢山の熱を帯びるからです。 また、Assaf Arkin氏も整合性を書くこと(source)はRDBMSが自身の重さで内破してしまう理由で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EclipseとOracle、javaxパッケージ名前空間と商標の扱いに関する合意を断念
MicrosoftがAzure Pipelinesを発表、オープンソースにCI/CDを無償で提供
Volkswagenのエンジニアに懲役40ヶ月の実刑が下る
LinkedIn EngineeringがSenseiDB 1.0.0をリリース
VMware が SQLFire 1.0 をリリース