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が最近リリースされ、重要な変...
この原則の影は、Javaクラスの変数フィールドを外部の呼び出し者に直接公開しない、という共通のプラクティスにおいて、まだ見えます。その代わりに我々は反射的にIDEの助けを借りてgetterとsetterを生成します。しかし次に示すようにこれらは疎結合にしてくれません。 主流のオブジェクト指向言語のもう一つの特性は、オブジェクトの振る舞いを起動する(メソッドを呼ぶこと)が同期的に起きるため、メソッドコールが戻る時に、結果の値が呼び出しコードに即利用可能になり、あらゆる副作用が起きます。このことによる問題は、オブジェクトを利用不可能にできないことです。あらゆる外部の呼び出し側は、即答えに満足しなければなりません。もしそれが現在不可能であれば、唯一の選択肢は、例外を投げて、失敗をエスカレートすることです。次にこの例外は呼び出し側によって処理されなければなりません。障害回復を起動します。こうして呼
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
今月リリースされたJava EE 7プラットフォームには,VMwareのSpring Batchプロジェクトから多くを受け継いだ,バッチ処理プログラミングのモデル仕様が含まれている。そのSpring Batch自体も同じく今月,設定のスリム化とデータアクセスの合理化を達成した注目のリリースによって,多くの関心を集めている。 JSR-352としても知られるBatch Application for the Java Platformは,アプリケーション開発者に対して,堅牢なバッチ処理システムの開発モデルを提供する。プログラムモデルの中心となるのは,Spring Batchから借用した開発パターンだ。Reader-Processor-Writerパターンと名付けられたこのパターンでは開発者に対して,Chunk指向の処理標準の採用を推奨している。 Reader-Processor-Writer
Java EE 7の数多い機能拡張の中に、Expression Language 3として知られるJava Expression Language APIのオーバーホールがある。JSR-341で仕様化された、EL APIの多くの機能拡張には、ラムダ式、静的フィールドとメソッドアクセス、そしてコレクション処理とスタンドアローンプロセスモードの改善が含まれている。 Java EE 7以前では、Java Expression Languageは、JavaServer Faces と JavaServer Pages APIに密結合したコンポーネントだった。JSR-341 は、Java Expression Language をJava EEのビューレイアAPIから切り離された、個別のエンティティとして導入した。— 尚相互運用可能だが — EL API は、開発者にアドホックにJava ELを呼び
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く