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が最近リリースされ、重要な変...
原文(投稿日:2009/09/22)へのリンク スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて,決着の付かない議論が長く続いている。どちらの陣営も,自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して,それを元に時間見積を行う方法を好んで使用すれば,それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが,自らの好む方法とその理由について意見を表明している。 Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって,短期作業には向かないと考えているからだ。彼の意見では, シ
アプリケーション開発者はシグネチャを見て、このルールに従っていると仮定します。例えば、ライブラリに同期メソッドがあれば、利用者側はスレッドプールを使って安全に並列化できると仮定できます。しかし、非同期であれば、スレッドを新しく生成するのは無駄で、シングルスレッドのループの中で非同期メソッドを実行するほうがいいと判断するでしょう。 このように考えると、さらに基本的な原則が生まれます。 “ライブラリ内でTask.Runを使わない” スレッド、特にスレッドプールのスレッドはグローバルに共有されているリソースで、アプリケーション開発者に属しています。ライブラリの作者はTask.Runを使ったり、スレッドを作るメソッドを作成するべきではありません。どのようなタイミングでスレッドを追加するか決めるのはアプリケーション開発者の権利と責任です。 次のコードは典型的なアンチパターンです。 public st
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く