タグ

2009年4月17日のブックマーク (6件)

  • 10 Things It Architect Should Know

    1. グロースエクスパートナーズ(株) ビジネスプラットフォーム事業ゼネラルマネージャー チーフITゕーキテクト 日Javaユーザー会幹事 日Springframeworkユーザー会幹事 鈴木雄介 現場のITアーキテクトが知っておくべき10のこと - あるいは、技術が分かるPMが知っておくべき10のこと 2. 自己紹介  鈴木雄介  エンタープラ゗ズゕプリのITゕーキテクト  標準化支援、技術支援、新規事業企画…  ブログ:ゕークランプ  http://www.arclamp.jp/  日Javaユーザー会幹事  日Springframeworkユーザー会幹事  日経SYSTEMITゕーキテクトの視点」連載 3. 狙い  ITゕーキテクトが現場で”考える”ための 考え方を紹介  “銀の弾丸ゕーキテクチャ”は存在しない  現場に合わせて悩み、考えることが大事。

    10 Things It Architect Should Know
  • Programming the Cloud -the Internet as Platform-

    イケメンGregor Horhpeによるクラウドセッション。この人は、Martin Fowler SignitureのEnterprise Integration Patternsの著者の一人でもある。今回はEIPではなく、BASE〜CAP TheoremGoogle App Engineといったあたりのお話。 クラウドの良い点、悪い点 アーキテクト(の関心事)にとっては、夢を実現するコンセプト。 疎結合拡張性標準への準拠耐障害性無制限のコンピューティングパワーユビキタスしかし、開発者にとっては悪夢の発現。 No Call StackNo TransactionNo PromisesNo CertaintyNo Ordering Constraint# No Certaintyがよくわからず、訳せなかったので全部英語 ^^; [メモ] このあたりは、パネルディスカッションでGregorが

    koroharo
    koroharo 2009/04/17
    cloud web
  • 大規模ウェブサイトのベストプラクティス -eBayでの事例-

    ほとんど「大規模サイト構築のノウハウ全部見せます!-全部で20以上あるよ!-」みたいなノリだったので、とても全部メモることはできなかった。プレゼン資料欲しいです。

    koroharo
    koroharo 2009/04/17
    cloud web
  • クラウドの技術的な特徴について

    丸山先生のジェネラルセッション。内容的にはEric Brewerの資料(CAP Theorem/Eventually Consistent)をクラウドの立場から眺める、といったもの。 ScalabilityとAvailability Scalabilityは、Scal-outによって達成できるが、Scale-outには技術的な裏打ちが必要であり、ノウハウの蓄積が必要。 Availabilityは、故障に対する適切な対処によって達成できるが、これには複製を作成する戦略(Replication)が基になる。複製を作ってしまうと、同期の問題、すなわち一貫性に関する問題が発生する。 [メモ] CAP定理で言うと、ScalabilityがおおよそPartitionに、AvailabilityがそのままAvailabilityに、一貫性がConsistencyにあたると考えてよいと思う。上記は、クラ

    koroharo
    koroharo 2009/04/17
    cap base cloud
  • CAP Theorem(定理)

    QCon Tokyoでは色々なところで「CAP Theorem」という定理が出てきた。が、eBayの人をのぞけば(たぶん)正確な定義は提示されておらず、不明な点がいくつか残っている。これからのインフラを考える上でも、QConセッションの内容をより良く理解するためにも、このあたりをまずきちんと理解しておきたい。主な疑問点は以下のとおり。 C, A, Pの特性の正確な定義は何なのかCAP定理が前提にしているシステムのモデルはどのようなものなのか Theoremとなっているが、単なる経験則なのか、それとも数学的な定理なのか 頼みの綱?のWikipediaを調べてみたが、日語版はおろか英語版にも載っていない。概観をまとめた海外の記事を結城さんが訳してくれているようなので、これを読んでみる。 CAP Theoremそのものは、Eric BrewerがPODCカンファレンスのキーノートで提唱したもの

    koroharo
    koroharo 2009/04/17
    cap cloud
  • QCon Tokyo 2009へ行ってきました(続き) - recompile.net

    どうやら、リーンソフトウェア開発は、当に必要なものだけをつくるための方法論として広く理解されているようです。リーン方式であれば、必要なものだけを作るので、ソフトウェア投資を必要最小限に抑えることができます。 こうしたふたつのキーワードの背後にある環境要因が不況です。ハードウェア投資を抑制する手段としてクラウドコンピューティングが、ソフトウェア投資を抑制する手段としてリーンソフトウェア開発が着目されているのです。 では、これは一時的な現象なのでしょうか。多くの論者は、そうではないと考えているようです。現在は、構造的転換の節目にあるという認識が広く共有されていました。不況は、単にこうした傾向を押し進めているにすぎない環境要因のひとつです。 もし、この変化が構造的変化だとすると、私たちのビジネス環境はどのように変化するのでしょうか。端的に言えば、定年になるまで今の会社でっていくことができるの