Timeline of 萩原正義 (masayh)
All days
Fri, Jul 30
- 02:34 @okachimachiorz 技術に対する目利きというか予見性を持っていないと貴重な時間を失うことになる。最先端の技術をやることは、時間の投資リスクを減らすため。顧客への提案に使うためではないでしょう。そちらは要求に従い枯れた技術で。枯れたというのは自分の中で。 [in reply to okachimachiorz] >
- 01:59 もう１つは時間を使うことではないですか？後戻りできない。@okachimachiorz 最近、リスクをとる、ということがどういうことか、を良く考える。一義的には金を使って、回収できるか？という話ではあるけど。 >
Wed, Jul 28
- 08:39 いままで自分のは400番台と思っていたのに、今日初めて500番台なのを知った。遅すぎ。これで内容はもうちょっと高度にできるな... >
- 07:04 あと、もしかしたら、MSにおけるHadoopの戦略の話もあるかもしれません。 >
- 07:03 TechEdは有償イベントなので、当面、この話題を他で話すことはありません。 >
- 07:02 TechEdでは前半が分散キャッシュ、noSQLへのアーキテクチャ移行手順、MapReduceとDAGモデル、後半が、計算モデルとパラダイム、CSPによる並列化の分析設計手法、イベントによるクラウドのマルチパラダイム実装の分析手法です。最新のクラウドアーキテクチャと設計を解説。 >
Tue, Jul 27
- 17:07 DSLについてはMartin Fowlerの新刊が期待できる。僕はこのあたりをSoftware Factoriesでさんざんやった。モデリングは手法によるので、いろんな書籍を読まないといけないでしょう。UMLだけやっててもだめです。 >
- 17:03 具体的例はどちらにしても必要ですね。それが欠けていたところは改善しないといけないと思ってます。@kimtea こういう機能がありーみたいな感じで、少し説明があると前後がつながるんだよね >
- 17:02 DSLもモデリングもすでに枯れた技術です。新しいのはクラウドへの適用の部分だけ。そこが分散システムとは違う部分。正確には、分散システムもデータモデルもそんなに新しくないので、黎明期といえるかどうか。@kimtea 黎明期であればあるほど、 >
- 16:54 チュートリアルやプレコンファレンスを開催すれば？ >
- 16:53 DSLの理解にはコンパイラの基礎やメタモデルなどの知識が必要です。モデリングでもドメイン分析とかユースケースの持つ深い意味の理解が必要だから、その解説は1日がかりになります。 >
- 16:51 内容が高度になればなるほど、基本とする概念、用語が困難になるとは致し方ないのでは。パラダイムという用語1つとっても意味が深いです。オブジェクト指向と関数型の違いを説明することが含まれるくらいの意味を持つので、それを1つずつ説明することは討論の趣旨に反することだと思います。 >
Mon, Jul 26
Sun, Jul 25
- 13:29 クラスターが1000台になれるのは通常のスター型ではなくて、LAVacというのがあったから。LAN-based VAX Clusterで最大1024台までのクラスターが組めました。 >
- 13:27 その開発環境のビルドシステムを1年がかりで作りました。ソースコード管理、リグレッションテストなどはすべて自動でした。クラスターのローリングアップデートもやってました。 >
- 13:23 VMSの開発環境自体がクラスターになっていました。日本でも最大級でしたね。マシンルームは壮観なくらい大きかった。最大1000台くらいのクラスター構成。 >
- 12:57 お疲れ様でした。こちらはこれから空港に向かいます。@shosuz NEXなう。成田がこれほど遠かったことは今までないかも…。 >
- 12:51 DECでVMSの開発してました。あと、DCEとかX/OpenとかX.500とか。 >
- 12:50 モデル検証は厳密さが必要なので、分析手法としてはより簡単なものを分けて考える方針です。@keisyun LTSAとかモデル検査も検討範囲でしょうか？ >
Sat, Jul 24
- 20:54 UA便もワシントンDCで1日オプショナルツアーになりました。とほほ。 >
- 04:33 DCIはCoplien氏、アスペクト指向分析はJaconson氏、そして新しいrefactoring UMLはJaconson氏の考え方が入ります。イベント分析ではどちらがいいか？ >
- 04:32 アスペクト指向分析ではユースケース分析後、もう一度ユースケース共通部分のドメイン分析のような分析プロセスを2段階かませる。これがイベントでも適用可能かどうか。DAGならsubgraphの共通化に相当する部分です。そうすることで変化への対応力が増します。 >
- 04:27 はい、それは満足してます。@okachimachiorz クラウド上での、イベントに対する考え方は、多層的・構成的だと思う。 >
- 02:49 このイベント分析をOOAに絡めて、CSPプロセスによる合成の並行処理の分析に代えようとするのが現在の試み。もう少しでできそうなのですが、CSPも捨ててはいない。設計法の詳細化ではそのアイディアを少し拝借する。 >
- 02:47 OOではインターフェイスが契約になるが、クラウドの実時間処理ではイベントが契約になる。これが原子性を持つ契約。それで、このイベントがドメイン分析なのかユースケース分析なのかが大きな設計上も問題となる。Coplien氏のDCIではドメイン分析としている。実はそれほど単純ではない。 >
Fri, Jul 23
- 12:40 おやつカンパニーは大ファンです。@okachimachiorz おやつカンパニーになるわけよ。 >
- 05:26 クラウドになり分析や設計の方法を考えるときの2つの困難。1つはアーキテクチャに対する予見性。データやアプリケーションの将来を想像すること、2つは単純化。いかに多くの物理制約、論理的複雑さを抽象化、直交化して単純化するか。基礎となる公理系が単純で汎用性があることの原則の大切さを尊重 >
Thu, Jul 22
Wed, Jul 21
Tue, Jul 20
- 17:51 ドメイン分析にしても既存の要求定義にしても開発対象を固定スコープで定義することを前提としますが、ストリームデータに対するwindowは対象を動的に定義することが異なります。この考えを積極的にすれば、既存のドメイン分析も要求定義も否定されるます。既存の考え方には疑問を持つべき。 >
- 17:08 不完全な情報を対象にするWindowの考え方は他にも応用のきくDSLモデルの特性の一種です。 >
- 16:35 イベントをルールの対象とすることや、ストリーム間のデータ依存性に着目することは当然のことではありません。かなり恣意的な定義。@oota_ken event driven architecture と stream computing がどう補完し合うかがわかった本日。 >
- 07:00 OOAつまりオブジェクト指向分析はオブジェクト指向で実装するためのものだけではありません。今はOOAを使い、関数型や論理型で実装するのもありです。そういうこと書いてある本あまり見たことないのですが、クラウドでは普通に考えないと。 >
Mon, Jul 19
Sun, Jul 18
- 14:02 @tumada 演算子の意味はそれが作用する集合、あるいは、データ型に依存しますから。 [in reply to tumada] >
- 14:00 ITアーキテクトというと最近は言葉が広くなりすぎて、軽く考えられている面もあるけれど、このレベル以上を目指すべき。 >
- 13:58 Design by Contractの契約の概念に複合化や原子性を入れるなどもコンセプトに1つ。日本ではこういうことができる技術者は限られる。ACIDを語れる設計者は多くいるが、自分でDSLのモデル要素を定義し、そこに原子性を入れた設計手法、論理アーキテクチャを作れる人が少ない >
- 13:54 これまでのITアーキテクトはフレームワークや設計手法を適材適所に選択して意思決定する役割だったが、クラウドではそれでは足りないし、差別化は難しい。新しい問題には新しいコンセプトやモデルを作れること、ここでのコンセプトはビジネスのことではなく、計算モデル上のデッドロックなど具体性。 >
- 13:52 明日からアトランタです。その前に一定の成果を出しておこうとしたが、時間がかかり過ぎた。ソフトウェア工学は過去の蓄積からいろいろな選択肢があるのですが、クラウドの課題に関して言えば、どれも完全には適用できない。それだけ大きな変化ということだろう。 >
- 13:49 しかし、既存のプロセス代数による形式仕様はあまり役にたたないな。そこから考えるのか。時間がない。 >
- 10:07 関係性によって存在は意識され、定義されるとか。@tumada 逆に一から出発して足すという操作を定義するにはどうしたら…。はじめに関係ありき、というか集合ありき、のようなきもします。 >
- 06:45 前者が強いと思う。@tumada 要素還元主義批判の文脈で「１＋１は２以上」と言われたとき、「１」のなかに相互作用のファクターを入れていなかっただけで単純に１が間違いで足し算はあっているのか、それとも１はあっているけれど特殊な場合において足し算という法則が間違っていたのか。 >
- 06:44 逆ではないですか。+の意味は1で決まります。@tumada いやでもやはり１という概念は＋という操作によって担保されているかな、 >
Sat, Jul 17
- 02:05 そうなってくると、social graph、value chainとの関係の記述も重要となる。上流はこうした関係性のモデル、そこから、BPMやMapReduceのDAGに落ちてくるというモデル変換がいい。 >
- 02:02 関数型のreactive programming、EDAに代表される動くはまだこの段階の初期でしょう。将来的には必ずproactive programmingになっていく。つまり、より論理型に問題指向になっていく。契約、制約、コンテキスト、ポリシー、ロールなどがモデル要素。 >
- 01:59 Coherenceがクラウド以前に出てきた経緯とか、MegastoreのAppengineに対する位置づけとか、AppFabricの役割とか、ミドル層がトランザクションシステムの進歩の方向性を決める。ここにマルチテナント、sharding、CEP、BAMなどが入ってくる。 >
- 01:52 「分散TX」と「分散並行TX」だと天と地ほど扱いがちがう。Gartnerのフェローがクラウドでのトランザクションシステムは既存のとは別次元のカテゴリーに属すると断言していていた。単にスケールアウトできるとか、BASEとかそういう次元ではないと。 >
- 01:47 このあたりの基本的な整理をすることから始めるのは意味があることだと思っています。特にDSLのモデル要素のとらえ方などモデリングでは。@okachimachiorz 「分散TX」と「分散並行TX」だと天と地ほど扱いがちがうな～と思った。 >
Fri, Jul 16
- 16:28 あとはこの限定されたUoWを使ったDAGとの関係を定義する。DAGのトランザクションスコープ（UoW）を単位としたVertexに対してOOAを使いモデル検証したうえで、Vertexの実装に対して最適なパラダイムを導入する。MRでは関数型で十分だが、実時間性がある場合は論理型。 >
- 16:26 ただ、述語を導入したとしてもそれだけでも不十分。そこで、OOAの方法論としてMERODEを導入する。これでオブジェクト間のリンクに限定して状態遷移を導入可能となり、分析段階で状態遷移の検証が可能となる。ただし、OOAの方法論の導入によっても実装はOOを仮定しない。 >
- 16:24 問題はクラウドにおける状態遷移をどう定義するか。1つはUoWに限定する。UoWをつなぐパイプはステートレスのため。しかし、これはUoWの実装をOOに限定しない。論理型でも関数型でも可能。ビジネス領域でこのUoWに状態遷移を限定させる方法が述語の導入です。 >
- 16:21 契約の概念は静的タイプ言語と動的タイプ言語によって異なる。つまり、ドメインによって異なる契約定義の方法があるということ。そしてステートレスな定義が事前事後条件による契約定義、いわゆる、DbC。しかし、クラウドにおける動的な振る舞いの定義はこれだけでは不十分。状態遷移。 >
Thu, Jul 15
- 16:06 DAGのfault tolerant特性にも合いますね。しかもvertexの実装にはいろんなパラダイムが使えるのでいいです。vertex内の状態遷移の一貫性は別機構で@ashigeru 原子性のあるDAGは外側から見たら論理的にsingle vertexになってるのが理想的かな。 >
- 15:59 はい、この時期の風物詩になってます。レベル感にギャップを感じてきたので今年で最後にしたいと思ってます。@suzietta TechEdと聞くと夏だなぁ～と思います。 >
- 05:53 さて、TechEdの準備に取り掛かるかな。 >
- 05:47 @asami224 いろいろと他にも話したいことはあるので、よろしくお願いします。モデリング、DSL、計算モデル、パラダイム... [in reply to asami224] >
- 05:46 @afukui テンプレートから作ってあげないいけないんですね。それで @hmoriya55 ところのツールはああなっているんですね。こりゃ、大規模だと全然いけないですね。データアクセスの戦略すら安定しない。 [in reply to afukui] >
- 05:30 大原則ですね。で、シンプルさの程度が難しい。@afukui 昨日 @hmoriya55 から学んだこと。シンプルな構成から必要に応じてアーキテクチャ構成を変化させていくこと。最初から複雑にしないこと。この辺りをTechEdで話せればいいな。 >
- 05:29 @asami224 残念ながら参加者限定になっております。今度お会いしたときに時間をとっていだだければ解説いたします。すみません。 [in reply to asami224] >
Wed, Jul 14
- 15:09 これはDAGのdataflowだけで別のvertexを通るようにすればできるはず。問題は循環しないようにすること。@okachimachiorz 有る条件を満たせばdispachできるvertexがあれば、そこへ別の論理を埋め込んで、全体で別の業務が作れるだろうという発想です。 >
- 15:02 @okachimachiorz 飛ばした=skipということですか？processの可変性がある処理？僕は、飛ばす＝障害のことと思っていました。 [in reply to okachimachiorz] >
- 14:57 DAGの性質として、負荷分散や入力の待ち合わせ同期がモデルの意味に含まれているので、それを実装にマップできるようなHadoop上のミドルが必要です。障害時のjobのfailoverもvertexの意味にカプセル化されるはずです。その他にもDAGの多くの意味を乗る必要があります。 >
- 14:54 いや、DAG vertexは論理なので、物理で障害があったら別の正常なノードで実行するということになると思う。だから、飛ばしてOKはなくてもいいと思えます。@okachimachiorz このvertexは飛ばしてもOkとか。わかると機能の分離実装ができる。品質もあがる。 >
- 09:04 クラウドでの本質的なモデル対象であるUoWをモデル化するためには、存在依存性という概念を導入します。通常の概念モデル設計でも無意識にモデル化していた部分ですが、この概念を導入し明示的にモデル化することで、UoWの一貫性をモデル検証できます。 >
- 09:01 ビジネスプロセス、ソーシャルネットワーク、バリューチェインの3つを統一的に分析していく手法を考えることです。クラウドでビジネスプロセス、その一部のバッチ的な実行であるワークフローやHadoopの実行だけを考えていてはいけません。 >
- 08:59 @asami224 匠のオープンセミナーのトランザクションハブはCEPやHadoopの技術で実行するので、そこにDAGを入れていくことは可能です。Gartnerはそれをさらに発展させるビジネスルールやパターンベースのやり方を考えています。 [in reply to asami224] >
- 08:54 状態遷移のスコープをresourceと考えれば、そのresourceを適切に切り出す手法がMERODEです。クラウドで状態遷移を追跡する必要がある個所からオブジェクトを切り出します。@asami224 usecase(利用事例)=event列=resourceの状態遷移の列。 >
- 08:50 最近、クラウドのインフラとアプリケーション、ロジックと人による補償、同期と非同期などの境界に関する議論があったが、これらも時代とともに変わっていくのだろう。揺り戻しと進化と。 >
- 08:47 Gartner Application Architecture Summit 2010ではいろいろとヒントをいただいた。中心はコンピューティングファブリックという技術。クラウドトランザクションシステムというのもあった。新しい技術ができている。 >
Mon, Jul 12
- 16:26 network partitioned に対応したquorumの正常な動作。@terurou #zookeeper 良く見たら偶数台のクラスタで半数のノードが死んだらクラスタが死ぬ（＝2台構成で1台死んだらダメ）と - http://bit.ly/aY0wgA >
- 16:20 Hadoopもリアルタイム化したら論理型になるので、ヒントとしてはそう場合のプログラミングモデルという位置づけです。@shot6 Erlang勉強会に最近参加できていないですが、あそこにヒントがある気はずっとしてます。 >
Sun, Jul 11
- 07:35 GartnerのApplication Architecture Summit 2010 http://www.e-gartner.jp/aabi2010/aa/ >
- 07:34 明日からのGartnerのApplication Architecture Summit 2010で、クラウド上のトランザクションシステムやBPM、SOAがどうなっていくかの予見を聞くことになっている。予見だから参考とはするが、そこはあくまでの予見ということで。 >
Sat, Jul 10
- 15:06 成果物の一部がここにあります。将来、電子書籍化の予定。http://www.exekt-lab.org/ @shot6 新ソフトウェア宣言はもう既にどこかに公開されているのでしょうか？興味あります。 >
- 15:02 新ソフトウェア宣言はsematで行われているソフトウェア工学の見直しに関する活動とは違った、哲学、科学（数学）、経済、経営、意匠、社会活動にまたがった活動から起こったものです。sematと共同で活動できればいいと思っています。 >
- 14:54 こうした理想の仮定で理論化され、プラクティスとなっている方法は、脆弱なものである。これは分散環境における神話、抽象化のやぶれと同じ問題である。合意された仮定は成立せず、分割したモデルは意味が異なっていることもふつうに起こる。それらに疑問を持ち、仮定の妥当性を再確認するに価値がある >
- 14:51 現在のソフトウェア工学、主要なOOADなどは分割可能性や複合可能性を前提とする。あるいは、開発プロジェクト管理はチームメンバー間で情報が共有可能であることが仮定される。しかし、現実には分割可能でない、分割することで意味が変わる問題、情報共有できない制約下での共同作業がありうる。 >
- 14:48 新ソフトウェア宣言はクラウドの影響をかなり受けています。あとは、言語ゲーム、分割できない非線形性、制約の位置づけ、実行可能な知識表現、経済活動との関係など。いままでのソフトウェア工学よりずっと広いスコープを持つ。 >
- 14:45 @frsyuki 「メッセージが壊れている」の一番の原因は通信エラーよりも、クライアントとサーバ間の微妙な互換性の違い、あるいは、その他の原因がありうるのでは。たとえばセキュリティ関連など。昔、DCOMでそういうエラーがあって、デバッグたいへんでした。エラー発生とその原因が乖離。 [in reply to frsyuki] >
- 05:48 新ソフトウェア宣言というのを策定中。全7宣言。署名者は日本でそうそうたるメンバーです。 >
Thu, Jul 08
- 09:05 Sparkの論文を読んでいるとDAGでは解決できない問題領域があると書かれている。これがDAGのデータモデル上の制約から来るものであれば、他のデータモデルとの比較をしてモデル上の長所と短所を整理しなければいけません。モデル要素の新たな選択と定義の段階に来ていると思います。 >
- 08:53 でも読者には難しなり過ぎないようにという条件付きです。なので内容なちょっと甘くなると思います。しかたないですね。ツイートのように尖がったことだけを言っていると意味わからないですからね。@kazunori_279 「自由」ですか、それは面白そうですねぇ^^ >
- 08:33 はいそうです。本当は連載はきついので隔月にしてほしいと頼んだのですが、押し切られました。その変わり、内容については自由を認めてもらいました。@kazunori_279 松山さんですか >
- 08:26 私も同時期に行きます。あちらではまた夜一緒にぼやきましょう。@oniak3 7/19-7/25、海外出張のため、日本から離れます。Tech Edの準備も頑張らないと。 >
- 08:25 日経systemsにKVSやHadoop関連のデータ設計の連載をすることになりました。10月号から。すでに@kazunori_279 さんがGAEでの連載をしていますね。合わせてよろしくお願いします。 >