マイクロサービス設計原則: SOLIDではなくIDEALS
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
DenoにはWebAssemblyがある
このDenoスタータプロジェクトテンプレートをGitHubからクローンあるいはフォークしてください。インストラクションに従えば、Denoで動作する最初のWebAssembly関数(Rustで記述されている)が5分以内に完成するはずです。 ちょっとした背景説明 Node.jsが大きな成功を収めたのは、開発者に２つの世界で最高のものを提供できたからです。すなわち、JavaScriptによる、特にイベントベースの非同期アプリケーション開発における簡便さと、C/C++のハイパフォーマンスです。Node.jsアプリケーションはJavaScriptで記述されますが、実行は、Google V8 JavaSciptエンジンと多数のネイティブライブラリモジュールを含んだ、C/C++ベースのネイティブランタイムによって行われます。Denoはこの勝利の方程式を再現する一方で、そのプロセスを、TypeScript
スクリプト言語としてのGo
原文(投稿日：2020/04/23)へのリンク ハイパフォーマンスなネットワークシステムや並列システムを開発するプログラム言語として、Goの採用が拡大していることから、開発者たちはこれをスクリプト言語として使用することに熱意を持ち始めている。ただし現在のGoは、そのままではbashやpythonの代用としては使えないため、これには多少の努力が必要だ。 CodelangのElton Minetto氏が説明しているように、そのパワーや簡潔さ、goroutineのサポートなど、スクリプト言語として使用する上でのGoには多くのアピールポイントがある。GoogleのソフトウェアエンジニアであるEyal Posener氏は、Goをスクリプト言語として使用するさらなる理由として、豊富なライブラリが使用可能であることと、言語自体が簡潔であるためスクリプトのメンテナンスが容易であることを挙げている。やや違う
REST入門
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
RESTに関する疑問に答える
相も変わらず、REST(source)についての学習は、特定のシナリオに対して実際にその概念がどのくらい適用可能であるかということを疑問に思うことに落ち着くと言えるでしょう。そして、あなたがおそらく全く異なるアーキテクチャのアプローチに慣れているだろうとすると、RESTに疑問を持ち始めた状態、あるいはRESTfulなHTTPを気に入り、実際に本当に動かしている状態、あるいは「Hello, World」レベルの導入を終えたまま、単に中断している状態であるというのは、ごく自然なことでしょう。本稿では、RESTを探求しようとしている、特に、SOAP/WSDLベースのWebサービスを背景としたアーキテクチャのアプローチにおいて多くの経験があるときに、RESTについて抱く最も一般的な10の疑問について答えようと思います。 1.RESTはCRUDに適しているが、「真の」ビジネスロジックには適していない
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースになったGitHub OpenAPI仕様 (ベータ)
CSS ContainmentがWeb標準に
Javaの起動時間を改善するプロジェクトLeyden
IBMがSwift開発を終了 - Chris Bailey氏とのQ&A
Deep Java Library - Java開発者のための新たなディープラーニングツールキット
Googleのソフトウェアエンジニアリング文化
Shopifyはいかにしてモジュラモノリスへ移行したか
JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”
C言語の現代化を目指すC2
WebKitがWebAssemblyを完全にサポートした
ペアプログラミング - 隣り合わせか，対面か
人間を考慮した自動化