パブリッククラウド
サード・パーティー (ベンダー) によって提供されるクラウド・サービス。パブリッククラウドは企業のファイアウォールの外側にあり、クラウド・プロバイダーによって完全にホストおよび管理される。
・メリット
リソースのアウトソース、オンデマンド利用
・デメリット
事業者のインターフェースにあわせる必要性、ガバナンスが効かない
プライベートクラウド
企業内部に提供されるクラウド・サービス。これらのクラウドは企業のファイアウォールの内側にあり、企業によって管理される。
・メリット
リソースの一元化、オンデマンド利用、パブリッククラウドに比べて細かな制御
・デメリット
リソース管理は自社内、運用コストが大きい
ハイブリットクラウド
パブリッククラウドとプライベートクラウドを組み合わせたクラウド。ハイブリッドクラウドは企業が作成し、その管理責任は企業とパブリック・クラウド・プロバイダーとの間で分担される。ハイブリッドクラウドはパブリック・スペースとプライベート・スペース両方のサービスを利用する。
・メリット
パブリッククラウドとプライベートクラウドを適材適所に適用
・デメリット
パブリッククラウドとプライベートクラウドを組み合わせることでの実装、管理の難しさ
バーチャルプライベートクラウド
パブリッククラウド内にプライベートな専用領域を作り出すクラウド。パブリッククラウド内に仮想的な占有領域を作成し、ユーザー企業内の情報システムをVPNで接続する。
・メリット
プライベートを構築できない中小企業でもプライベートクラウドのメリットを享受できる
・デメリット
実験段階で商用事例がない、VPNの提供など事業者の協力が必要
2009/08/10
クラウド・コンピューティングの提供形態
アプリケーション・サービス(SaaS)
ソフトウェア（主にアプリケーションソフトウェア）をネットワーク経由のサービスとして提供・販売。
（例：Gmail 、Yahoo! メールなど）
プラットフォーム・サービス(PaaS)
ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供。
（例：Amazon Webサービス、Google App Engineなど）
インフラストラクチャー・サービス(IaaS)
コンピュータシステムを構築および稼動させるための基盤（仮想マシンやネットワークなどのインフラ）そのものを、インターネット経由のサービスとして提供。
（例：Amazon EC2、Amazon S3など）
ソフトウェア（主にアプリケーションソフトウェア）をネットワーク経由のサービスとして提供・販売。
（例：Gmail 、Yahoo! メールなど）
プラットフォーム・サービス(PaaS)
ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供。
（例：Amazon Webサービス、Google App Engineなど）
インフラストラクチャー・サービス(IaaS)
コンピュータシステムを構築および稼動させるための基盤（仮想マシンやネットワークなどのインフラ）そのものを、インターネット経由のサービスとして提供。
（例：Amazon EC2、Amazon S3など）
2009/08/03
JUnit A Cook's Tour 「4. Conclusion」まとめ的な何か（自分めも）
・パターン使うとフレームワーク開発とか人に説明するのにベンリだよ！
・パターンが密集してると使いやすいけど、変更しにくいよ！
・でもよくできたフレームワークはパターン密集してるからそっちの方がいいかもね！
・他人に使わせる前に自分で使ったらいいと思うよ！
・フレームワークはシンプルなのが使いやすくていいよね！
・どうしても機能追加したくなったら拡張パッケージにしたらいいと思うよ！
・コード書くよりいっぱいコード読んでね！
・リファクタリング大事だよ！
・パターンが密集してると使いやすいけど、変更しにくいよ！
・でもよくできたフレームワークはパターン密集してるからそっちの方がいいかもね！
・他人に使わせる前に自分で使ったらいいと思うよ！
・フレームワークはシンプルなのが使いやすくていいよね！
・どうしても機能追加したくなったら拡張パッケージにしたらいいと思うよ！
・コード書くよりいっぱいコード読んでね！
・リファクタリング大事だよ！
JUnit A Cook's Tour 4. Conclusion翻訳メモ
JUnit A Cook's Tour の「4. Conclusion」を雰囲気でほにゃくしてみる。
☆はよくわかんないところ。
ほんやくこんにゃくホシイ。
----
4. Conclusion
4.結論
To conclude, let’s make some general observations:
結論として、全体を見てみましょう
Patterns
パターン
We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others.
設計をパターンの単位で議論することは、フレームワークの開発とフレームワークを他者に説明する上で有益であることが分かりました。
You are now in a perfect position to judge whether describing a framework with patterns is effective.
あなたは、現在、あるフレームワークが効果的なパターンで記述されているか判断できる最適な立場にあります。
If you liked the discussion above, try the same style of presentation for your own system.
もし上記のような議論が好きなら、自分のシステムのために同じスタイルのプレゼンテーションを試してみてください。
Pattern density
パターンの密度
There is a high pattern "density" around TestCase, which is the key abstraction of JUnit.
TestCaseのまわりには高いパターンの「密度」があります。そして、それはJUnitの鍵となる抽象概念です。
Designs with high pattern density are easier to use but harder to change.
高密度なパターンによる設計は、使いやすいのですが、変更が困難です。
☆We have found that such a high pattern density around key abstractions is common for mature frameworks.
成熟したフレームワークではそういった鍵となる抽象概念による高密度なパターンは一般的であることがわかりました。
☆The opposite should be true of immature frameworks - they should have low pattern density.
反対に、未熟なフレームワークではパターンの密度が低いはずです。
☆Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.
いったんあなたが本当に解決したい問題を発見したら、あなたは解決策を圧縮して、パターンが提供する、より高密度な領域に導いてくれます。
Eat your own dog food
あなた自身のドッグフードを食べてください(他人に提供するものはまず自分で試してみましょう)
As soon as we had the base unit testing functionality implemented, we applied it ourselves.
我々は基本単位のテストが機能するところまで実装したらすぐに、我々自身でそれを適用しました。
☆ A TestTest verifies that the framework reports the correct results for errors, successes, and failures.
TestTest(Testインターフェースのためのテスト？)は、フレームワークがエラーや成功、失敗などの適切な結果をレポートすること検証しています。
We found this invaluable as we continued to evolve the design of the framework.
我々がフレームワークのデザインを発展させ続けたので、こういった内容は非常に貴重であるとわかりました。
We found that the most challenging application of JUnit was testing its own behavior.
JUnitで最も挑戦的なアプリケーションは、JUnitがJUnit自体のふるまいをテストしていることであることを見いだしました。
Intersection, not union
交差、結合ではなくて。
There is a temptation in framework development to include every feature you can.
フレームワーク開発では、できるだけいろんな機能を取り込みたいという誘惑があります。
After all, you want to make the framework as valuable as possible.
結局、あなたはフレームワークをできるだけ価値のあるものにしたいのです。
However, there is a counteracting force- developers have to decide to use your framework.
しかし、開発者があなたのフレームワークを使うことを決心させなければならない反作用（ジレンマ？）があります。
The fewer features the framework has, the easier it is to learn, the more likely a developer will use it.
機能が少ないフレームワークは、学習が容易で、開発者に使われやすいでしょう。
JUnit is written in this style.
JUnitは、このスタイルで書かれています。
It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically.
JUnitはテストを走らせるために厳選された機能だけを実装しています。それは、テスト１式を走らせること、お互いに独立したテストの実行、自動的にテストを走らせることなどです。
Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions).
もちろん、私たちは若干の特徴を加えることを抑えることができませんでした。しかし、それは拡張パッケージ(test.extensions)の中に、注意深く取り込みました。
A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.
この拡張パッケージで特筆すべきクラスはTestDecoratorで、TestDecoratorはテストの前後に追加コードを実行できるようにしています。
Framework writers read their code
フレームワークの記述者は、自分のコードを読みます
We spent far more time reading the JUnit code than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality.
我々がJUnitのコードを読んでいる時間は、JUnitのコードを書いた時間よりも遥かに多くの時間を費やしています。
そして、新しい機能を追加している時間とほとんど同じくらいの時間を重複機能の除去に費やしています。
We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine.
我々は新しいクラスを加えたり、想像できるあらゆる方法で責務を移動したりして、積極的に設計を試しました。
☆We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.
JUnitへの洞察、テスト、オブジェクトデザイン、フレームワーク開発、そしてさらなるものへのチャンスといった、我々の執拗で継続的継続的なフローによって、我々は恩恵を受けています。（そしてこれからも）
The latest version of JUnit can be downloaded from http://www.junit.org.
JUnitの最新版は、http://www.junit.org.からダウンロードできます。
☆はよくわかんないところ。
ほんやくこんにゃくホシイ。
----
4. Conclusion
4.結論
To conclude, let’s make some general observations:
結論として、全体を見てみましょう
Patterns
パターン
We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others.
設計をパターンの単位で議論することは、フレームワークの開発とフレームワークを他者に説明する上で有益であることが分かりました。
You are now in a perfect position to judge whether describing a framework with patterns is effective.
あなたは、現在、あるフレームワークが効果的なパターンで記述されているか判断できる最適な立場にあります。
If you liked the discussion above, try the same style of presentation for your own system.
もし上記のような議論が好きなら、自分のシステムのために同じスタイルのプレゼンテーションを試してみてください。
Pattern density
パターンの密度
There is a high pattern "density" around TestCase, which is the key abstraction of JUnit.
TestCaseのまわりには高いパターンの「密度」があります。そして、それはJUnitの鍵となる抽象概念です。
Designs with high pattern density are easier to use but harder to change.
高密度なパターンによる設計は、使いやすいのですが、変更が困難です。
☆We have found that such a high pattern density around key abstractions is common for mature frameworks.
成熟したフレームワークではそういった鍵となる抽象概念による高密度なパターンは一般的であることがわかりました。
☆The opposite should be true of immature frameworks - they should have low pattern density.
反対に、未熟なフレームワークではパターンの密度が低いはずです。
☆Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.
いったんあなたが本当に解決したい問題を発見したら、あなたは解決策を圧縮して、パターンが提供する、より高密度な領域に導いてくれます。
Eat your own dog food
あなた自身のドッグフードを食べてください(他人に提供するものはまず自分で試してみましょう)
As soon as we had the base unit testing functionality implemented, we applied it ourselves.
我々は基本単位のテストが機能するところまで実装したらすぐに、我々自身でそれを適用しました。
☆ A TestTest verifies that the framework reports the correct results for errors, successes, and failures.
TestTest(Testインターフェースのためのテスト？)は、フレームワークがエラーや成功、失敗などの適切な結果をレポートすること検証しています。
We found this invaluable as we continued to evolve the design of the framework.
我々がフレームワークのデザインを発展させ続けたので、こういった内容は非常に貴重であるとわかりました。
We found that the most challenging application of JUnit was testing its own behavior.
JUnitで最も挑戦的なアプリケーションは、JUnitがJUnit自体のふるまいをテストしていることであることを見いだしました。
Intersection, not union
交差、結合ではなくて。
There is a temptation in framework development to include every feature you can.
フレームワーク開発では、できるだけいろんな機能を取り込みたいという誘惑があります。
After all, you want to make the framework as valuable as possible.
結局、あなたはフレームワークをできるだけ価値のあるものにしたいのです。
However, there is a counteracting force- developers have to decide to use your framework.
しかし、開発者があなたのフレームワークを使うことを決心させなければならない反作用（ジレンマ？）があります。
The fewer features the framework has, the easier it is to learn, the more likely a developer will use it.
機能が少ないフレームワークは、学習が容易で、開発者に使われやすいでしょう。
JUnit is written in this style.
JUnitは、このスタイルで書かれています。
It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically.
JUnitはテストを走らせるために厳選された機能だけを実装しています。それは、テスト１式を走らせること、お互いに独立したテストの実行、自動的にテストを走らせることなどです。
Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions).
もちろん、私たちは若干の特徴を加えることを抑えることができませんでした。しかし、それは拡張パッケージ(test.extensions)の中に、注意深く取り込みました。
A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.
この拡張パッケージで特筆すべきクラスはTestDecoratorで、TestDecoratorはテストの前後に追加コードを実行できるようにしています。
Framework writers read their code
フレームワークの記述者は、自分のコードを読みます
We spent far more time reading the JUnit code than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality.
我々がJUnitのコードを読んでいる時間は、JUnitのコードを書いた時間よりも遥かに多くの時間を費やしています。
そして、新しい機能を追加している時間とほとんど同じくらいの時間を重複機能の除去に費やしています。
We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine.
我々は新しいクラスを加えたり、想像できるあらゆる方法で責務を移動したりして、積極的に設計を試しました。
☆We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.
JUnitへの洞察、テスト、オブジェクトデザイン、フレームワーク開発、そしてさらなるものへのチャンスといった、我々の執拗で継続的継続的なフローによって、我々は恩恵を受けています。（そしてこれからも）
The latest version of JUnit can be downloaded from http://www.junit.org.
JUnitの最新版は、http://www.junit.org.からダウンロードできます。
登録:
投稿 (Atom)