You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
AWS(Amazon Web Service)を個人的にボチボチいじっているのだけど、ELB(Elastic Load Balancing)が結構気持ち悪い。ので今日はその辺のお話。 ELBとはAWSが提供するロードバランサで、オートスケールと組み合わせることにより、トラヒック増大時にも自動的にスケールアップしてくれるというのが売りとなっている。内部的な話をすると、ひとつのELBにはひとつのFQDNが割り当てられ、スケールする際にはこのFQDNのIPアドレス(Aレコード)が変わるという若干トリッキーな動きをする。そのため、ユーザはIPアドレスではなく、常にFQDNでアクセスするようにしないといけない。（この他、配下のサーバのヘルスチェックもきめ細かくできるとか、Route 53の合わせ技が強力……とか色々あるけど本稿では関係ないので省略）。 さてここで問題は、スケールしてELBのIPアドレ
昨日，JavaDayTokyo2015でProject Lambdaのハンズオンのお手伝いをしてきました． その中で，Collectors#averagingDoubleやDoubleStream#averageの実装が優秀だということが分かったので，まとめておきます． 結論を先に言うとStreamAPI*1が優秀なので，それを使おうという話です． *2 普通の実装の話 よくサンプルで出てくる，ある数列から平均値を求める処理は以下のようになっていると思います． また，おそらく普通のプログラマに平均値を求める処理を書かせても同様なコードを書くと思います．*3 double[] array = {...}; double sum = 0; for (int v : array) { sum += v; } double ave = sum / array.length;実はこれは精度が低く，実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く