むずかしそうなコロナの話も、Apple文体になれば、ほら。#わかるコロナ
増えるか、減るか。 コロナ禍でいちばん大事な、実効再生産数の話をしよう。 増減なんて、見りゃわかるって？ その意気込みで付いてきて。 実効再生産数。目にしたことはあるでしょう。理解もしやすい数字ですが、ここでおさらいしておきましょう。たとえば、新規感染者数が1週間ごとに 1000 → 2000 → 4000 のように2倍、2倍と増えていれば、実効再生産数は 2。半減、半減が続いていれば 0.5。増えも減りもしなければ 1 です。1 より小さい数字をキープしていれば、コロナは減るわけです。はい、かんたん過ぎましたか？ でもこれがコロナに勝つか負けるかを左右する、いちばん大事な指標なのです。 ※ 実際にはより厳密な定義があって、新型コロナの場合はこの単純計算よりも少しだけ 1 に近づきます。 ほうっておけば、1.4倍。 うんとがんばれば、0.7倍。 「1」を挟んでせめぎ合う、わたしたちの緊張の
Go で使う Makefile の育て方
Go を使ってプロダクトを作る時、Makefile を使ってビルドを指定することが多いです。 理由としては、 バージョン情報などを埋め込むのに都合がいい 複数のバイナリを吐き出す時に都合がいい Go のビルドオプションを指定するのにいろいろあって整理しておきたい 事前にコードジェネレータで書き出す部分があり、それを考えると Makefile などで整理したい などなどです。なので今回はプロジェクトが大きくなっていく中でどういう Makefile の書き方をしているか、というのをご紹介しようと思います。 サンプルとして、今回のプロジェクトでは gRPC を使ったチャットサービスのサーバーとクライアントを作ることにします。リポジトリは https://github.com/rosylilly/gochat に置いておきました。 Step 1. バージョン情報を埋める 今回はサーバーとクライアン
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
