tmk.nomさんがtweetしていた「学習する組織」の読書メモがとても良かったのでまとめ。大変分厚い(500ページ)の本なので、読んで公開してくれて感謝。 http://www.amazon.co.jp/dp/4862761011 私自身も組織で同じような問題に直面していますが、組織の話だけでなく、自分自身の行動指針としても大変ためになりました。私も読んでみたいと思います。
こんにちは。GREEのプラットフォーム開発部でインフラ系の仕事をしているmdoi(@m_doi)と申します。よろしくお願いします。今回は、AMQPについて簡単に紹介したいと思います。 はじめに GREEで稼働中のサーバは、日々サーバの異常ログ、自己監視結果、メール等々、大量のメッセージをやり取りしています。しかしながら、共通のメッセージングインフラが存在しないため、それぞれが独立に色々なメッセージ送信を行っています。 サーバ台数の増大に伴って、メッセージ配送の負荷が無視できないレベルになって来ると、それらのメッセージングシステムについて、個別に負荷対策を施すなど運用上様々な問題が課題が出てきます。また、メッセージの種類によっては、その配送の仕組がスケーラビリティに欠けるものとが存在し、規模の増大に対応できなくなる恐れもあります。そのため、こういうった用途に使えるスケーラブルなメッセージング
今回のブログは、Spring Framework Advent Calendar 2012の6日目の記事として投稿します。 Springに関係する内容として何を書こうか考えたところ、最近、私の周りでよく話題になるSpring IntegrationとMuleについて、妄想レベルですが、書きたいと思います。 Spring IntegrationとMuleは、どちらもEAIのプロダクトとして知られており、EIP(Enterprise Integration Patterns)に従って作られています。ですので、プロダクトの選定時の候補として、どちらを採用すべきか比較されることが多いのですが、実は、用途が結構違うのではと考えています。なぜかと言うと、サービスバス(データの流れを制御する部分という意味で使っています)によって疎結合にしようとする対象が違う(と思う)からです。 Muleの場合、サービス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く