Reteアルゴリズムとは、プロダクションシステム実装のための効率的なパターンマッチングアルゴリズムである。カーネギーメロン大学のチャールズ・フォーギーが設計したもので、1974年の論文で最初に公表し、1979年の学位論文や1982年の論文でさらに洗練された（参考文献参照）。数々のエキスパートシステムの基盤として使われており、JRules、OPS5、CLIPS、Jess、Drools、Soar、LISA、Microsoft BizTalk Server におけるビジネスルールエンジン、TIBCO BusinessEvents などがある。Rete とは、ラテン語の 'rete'（網、ネットワーク）が語源である。 素朴なエキスパートシステムの実装では、知識ベース内の既知の事実と規則（ルール）群を順次照合し、適合するルールを実行していく。ルール群や知識ベースがそれほど大きくなくても、この素朴な方

このページについて: このページは、かつて http://www.selab.tutkie.tut.ac.jp/~yoshida/hoge.html に存在していたページです。 現在は公開されていません。 しかし、このような歴史的・文化的に極めて大きな価値のあるページが 見られないのは実に惜しいということ、 および、私自身が著書にて上記URLを紹介しまくっていることから、 作者の吉田さんに許可を頂き、ここに転載することにしました。 「C言語ポインタ完全制覇」の第6刷からは、こちらのURLを紹介しています。 転載を快諾してくださった吉田さんに感謝いたします。 ひとつ上のページに戻る | トップページに戻る ほげを考えるページこのページはネットワーク文化人類学の新しい分野である「ほげ学」のページです。暇な人以外は、このページを見ないようにお願い致します。特に、 レポートや論文が完成していない技

Frequently Asked Questions Downloading How do I get UnZip (or Zip)? Where can I get MVS executables? Where can I get a Mac version of Zip? Where can I get a Windows CE version of Zip? Why are encrypting versions of Zip not distributed from your main site? How to Use How do I use UnZip? Do you support multi-volume archives? How do I extract one? How do I create a self-extracting archive that will a

このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

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

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

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

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

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