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が最近リリースされ、重要な変...
![C#用静的解析ツールRoslynator.Analyzersで500以上の方法によるコード改善が可能に](https://cdn-ak-scissors.b.st-hatena.com/image/square/10db31156874e9e833eb66eade113fc2b6cec6e2/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s1_20240425073937%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
いずれにせよ、システムの状態が時間の関数であり、そのため時間は考慮しなければならない余分な要素となります。"xの値は何?"と問い合わせることは実際できません。代わりに、"時間tにおけるxの値は何?"と問い合わせなければなりません。これではコードを判断するのが難しくなり、複雑な要素が増えます。結論としては... 状態あり: ダメ! 状態なし: グッド! 式とアクション 式とは値を持った文です。たとえば以下のコードを考えてみましょう。 x = 5 y = x + 7 x = y + 1 最初のxは値が5であるという式です。最後のxは値が13であるという式です。コードは他の式も含んでいます。たとえば真ん中の行は、x + 7が12という値であるという式です。 ほとんどのコンピュータ言語では、キーボードから読み込むコマンドは式であり、その式は値を持っています。次の文を考えてみましょう。 x = ne
C# 8で新たに提案された機能である非同期ストリーム(Async Streams)では、結果がスカラ値でなくてはならないという制限が排除されて、非同期メソッドから複数の結果を返すことが可能になります。 この変更により、asyncパターンはより柔軟になり、データベースから遅延非同期シーケンスでデータを取得したり、あるいはデータが利用可能になった時にチャンクで返すような非同期シーケンスを使ってデータをダウンロードしたりすることが可能になります。 例: foreach await (var streamChunck in asyncStreams) { Console.WriteLine($"Received data count = {streamChunck.Count}"); } 非同期プログラミングの問題を解決するもうひとつのアプローチは、Reactive Extensions(Rx)で
オブジェクトグラフは到達可能な子オブジェクトから構成されます。データモデルやDTOの場合、オブジェクトグラフは一方向のツリーに似た構造になります(循環グラフもありうるが、シリアライゼーションで問題になる)。 ドメインモデル ドメインモデルは関連するデータモデルを表す、より高い次元の概念。 エンティティ “エンティティ”という言葉には多くの定義があります。本質的には“データモデル”と同じ定義のものもあります。nHibernateとEntity Frameworkが人気になったので、データベースのテーブルと一対一にマッピングされるDTOを意味するようになりました。 この定義の場合、エンティティはカラムと列のマッピングを正確に説明する属性で飾られるようになります。データベースからの遅延読み込みもサポートします。 エンティティを拡張してデータモデルとしての役割を担わせることもできますが、エンティテ
この機能にうってつけのシナリオの一つが、以下に説明するロギングの例である。ILoggerインターフェースが持つ抽象メソッドはWriteLogCoreただ一つだけで、WriteErrorやWriteInformationのような他のメソッドはすべて、それぞれ別の設定でWriteLogCoreメソッドを呼び出すデフォルトメソッドとして定義されている。ILoggerの実装者は、WriteLogCoreメソッドだけを実装すればよい。 ロガー型の各実装クラスで削減されるコードの行数を考えてもらいたい。この機能は素晴らしいものにもなり得るが、危険性がないわけではない。一種の多重継承であるので、ダイヤモンド問題が起こり得る。これについては後で述べる。また、インターフェースメソッドは、状態を持たない「純粋な振る舞い」でなければならない。つまり、インターフェースは、これまで同様、フィールドを直接参照すること
モノリスからマイクロサービスに移行することで、それまでモノリスの中の暗黙的に存在していた複雑性が明らかになり、通信に関する課題が指数級数的に増加する — Michael Plöd氏は、GeeCON 2018でのプレゼンテーションでこのように述べ、マイクロサービス間の通信に関するさまざまな手法について説明した。 InnoQのプリンシパルコンサルタントであるPlödは最近、経験豊富な氏のチームが、マイクロサービスを既定のアーキテクチャとして見ていることが多い点に気付いた。分散システムは難しいシステムだ、と氏は強調する — 必要がなければ、そのためだけに苦労するのは避けるべきだ。そのような状況では、適切に構築されたモノリスの方がよい選択肢であることも少なくないのだ。 モノリスでは不十分であるためにマイクロサービスが採用されている場合は、それらは統合されていなくてはならない。これは単に技術的な問題
Gophercon 2018においてRuss Cox氏は、エラー処理、ジェネリックを含むGo 2について説明し、新しい提案がどのように見えるかのプレビューを提供した。 昨年のGophercon 2017の発表で、Go 2は、多くの相互作用する並行サービスで構成された大規模システムと、多くの緩やかに調整されたエンジニアによって開発された大規模なコードベースというシステムを大規模に開発するための効率的な言語であるという全体の目標を維持しながら、言語の欠点を修正する。 Cox氏が説明したように、Go開発のアンケートで一貫して表示される3つの領域がある: パッケージ管理、エラー処理、ジェネリック InfoQのレポートでモジュールはGo 1.11で登場したが、また実験中に変更されている。モジュールはGOPATHの代わりとしてプロジェクトの依存関係を見つけるための代替手段として、共通のインポートパスプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く