グーグルによるMapReduceサービス「BigQuery」が登場とか

　Twitterで、気になったもの。
　idがその発言のID,screen_nameが発言した人で、下の行が発言内容

---

id:14676142831 　　 screen_name:doidoi07
@MitsutakaOhisa 確かに。ベンダーに頼らないとメンテできない共通インフラはまずいかなｗ

id:14613365981 　　 screen_name:doidoi07
hpってOVOまだ担いで行く気があるんだろうか？OpsWareとかSIMに移行してくれって話になるのかな？

id:14656427458 　　 screen_name:yaha_questetra
【導入事例PDFその3】 #QFaq #QFeature 加工食品メーカーでの導入事例をPDFでダウンロード出来るようにしました。[PDF] http://bit.ly/bDdIUv

id:14596838579 　　 screen_name:yaha_questetra
【導入事例PDFその2】 #QFeature #QFaq 導入事例PDF他にもあります。 [PDF] http://bit.ly/d8GyT7 ミラクルリナックス社の事例です～

id:14587295459 　　 screen_name:yaha_questetra
【導入事例PDF】 #QFeature ＃QFaq 導入事例のPDF資料公開しました～ [PDF] http://bit.ly/bvS6Zb 京都のソフトウェア開発会社インフォニック社の事例です♪

id:14600257419 　　 screen_name:kazkawamura
nakさんが日立製作所のクラウドの本部長なんですね。 http://www.itmedia.co.jp/enterprise/special/dev_marulec/2008.html sIBSのころは製作所上等な感じだったんですけど、時代は変わりますね。

id:14554335563 　　 screen_name:stormfogs
あとで確認：　iPhoneアプリ MATLAB Mobile

id:14678591182 　　 screen_name:bufferings
人の書いたGAE/JPAのコードをちょっと読んだけど、ほんとRDB的なんだね。入りやすそう。そして、その後きっとはま(ry

id:14675978170 　　 screen_name:kazunori_279
もうノイマン型には戻れないのですねw RT @kibayos: 第5世代コンピュータの頃の著名は研究者の何人かは、分子コンピュータのフィールド（DNAコンピュータ）で活躍されています。東大の萩谷先生しかり、The Art of Prologで有名なShapiro博士しかり。

id:14675169716 　　 screen_name:kazunori_279
古代エジプトの遺跡ですねわかります RT @moriyoshit: RT @gyuque: 最近の若者はすぐMapReduceで解決しようとする

id:14673407404 　　 screen_name:kazunori_279
はやっ RT @publickey: ブログ書きました。またグーグル、またMapReduceネタです！ ： こっちは本物のMapReduceだ！ グーグルがAppEngine-MapReduceをオープンソースで開発中 http://bit.ly/9YOlJo

id:14671916676 　　 screen_name:kazunori_279
@jniino オリジナルのMRはおそらくC++かsawzallでしか動かないので、 #appengine のようにセキュリティやリソースのサンドボックス作るのが難しいのではないかと。。

id:14671537604 　　 screen_name:kazunori_279
@jniino ええ、これです。とはいえまだmapだけで、reduceは現在開発中。もっともC++/sawzallで動くオリジナルのMapReduceとは別実装です（ややこしいw）

id:14671363833 　　 screen_name:kazunori_279
@jniino 内部ではMR使ってるかもしれませんね。ただしサービス自体はAmazonのHadoopのようにユーザーがMRを使える環境ではなく、「超巨大データの集計機能」って感じです

id:14669698796 　　 screen_name:kazunori_279
@jniino ここにセッションのtranscriptがあります。 http://ow.ly/1PoFo これとは別に、MapReduceのmapだけmapper apiとして #appengine でサポートするという発表がありました http://ow.ly/1PoGf

id:14669368769 　　 screen_name:kazunori_279
これMapReduceとは別物ですよ～ "グーグルによるMapReduceサービス「BigQuery」が登場。SQLライクな命令で大規模データ操作 － Publickey" ( http://bit.ly/9ETU6d )

id:14552260674 　　 screen_name:kazunori_279
デルタの座席にある画面いじってたとき、固まったなあと思ったらLinuxブート画面が出てきたww

id:14592405790 　　 screen_name:kharaguchi
宮崎県口蹄疫被害に対する日本郵政グループの救援対策をまとめていただいています。株式会社ゆうちょ銀行 義援金の無料送金サービス…全国のゆうちょ銀行及び郵便局の貯金窓口で取り扱います。

id:14604415006 　　 screen_name:Nakada_itpro
@shot6 そうですね。データモデルが変わっても、新旧のデータをまとめて分析できるのがMRの良いところだと。あと、記事の終わり方から、次回はHiveやPigのような気もしました

id:14604228355 　　 screen_name:Nakada_itpro
@shot6 容量を気にせず貯められるところは良いけれども、プログラムの開発はまだまだ難しい、てな話題はやはり共通のようですね

id:14603683639 　　 screen_name:Nakada_itpro
Cloudera Blog「Considerations for Hadoop and BI http://bit.ly/a7Ngyt 」。BIツールを置き換えるのではなく、まずはデータを貯めることから考えよう、という意味かな？

id:14694231272 　　 screen_name:mkoszk
@Taka_bow 派生開発カンファレンス2010は、ツダるの”あり”でしたっけ？　僕の経験では、要求とテストの人は拒絶反応が強いと思っています。古い話では要求開発サミット、新しくは要求工学シンポジウムで、キーボードを叩いていたら、まわりの人から怒られました。

id:14684982640 　　 screen_name:mkoszk
事例発表が中心なのでケースバイケースだと思います。 RT @rin2_ 派生開発カンファレンスのハッシュタグがあるのか。これは、tudaってもいい、ということだろうか(^^

id:14678870703 　　 screen_name:mkoszk
SECメールに派生開発カンファレンス2010の案内が載っていましたね。

id:14676287002 　　 screen_name:mkoszk
RAEWは、Responsivility（責任）、Authority（権限）、Expertise（専門）、Work（作業）

id:14676259246 　　 screen_name:mkoszk
RACIは、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協業先）、Informed（報告先）。

id:14676254894 　　 screen_name:mkoszk
プロジェクトマネジメントで使うときは、RACIが良いけれども、業務分析で使うときは、RAEWの方がよいと思う。

id:14666403331 　　 screen_name:mkoszk
要求工学とUSDMの用語の違いも整理をしたいと思っています。

id:14666368086 　　 screen_name:mkoszk
@honda_ XDDPの構成要素であるUSDMとPFDについては興味がありますが、派生開発の経験が無いため、XDDPについてはほとんど発言をしないようにしています。さて、USDMの良さは理由や背景記述になるのですが、そもそも「何を」「どのように」書くかということに興味があります

id:14609715749 　　 screen_name:mkoszk
ワインバーグの「要求仕様の探検学」より。「文書は価値がない。文書化することがすべてだ。」

id:14609005603 　　 screen_name:mkoszk
USDMの仕様というのは、手段を検討した結果が反映されたものという認識でよいのかしら？　USDMの仕様はかなり手段よりだからなあ。USDMを用いて要求を書くときには、手段の検討というプロセスを入れないといけないのかな。

id:14608940202 　　 screen_name:mkoszk
@YasuharuNishi ごめんなさい。今、ちょうど、「要求の検証と妥当性確認」という章を書いていました。


id:14607754570 　　 screen_name:mkoszk
USDMで書かれた記述ならばどうだろうか。記述されるとするならば、要求ではなく仕様にあたるだろう。または要求の範囲を狭めるために、形容詞・副詞を含んだ要求が書かれることになるのかな。

id:14607673875 　　 screen_name:mkoszk
さて、最近の要求を見てみると、この属性リスト（願望リストから変換されたもの）をあまり見ない。書かれていればテスト設計が楽なのだが、無いので、テスト観点という概念を使って補足しなくちゃいけない。

id:14607540423 　　 screen_name:mkoszk
ワインバーグの「要求仕様の探検学」。僕がテスト観点でやろうとしていたことが、「１５．属性」に載っていた。やはり読み直すものだなあ。引用してみる。「属性とはクライアントが望む特性のことだ。だから、形容詞か副詞のように考えたほうがよい。（中略）

id:14592267226 　　 screen_name:mkoszk
PMBOK第４版に「ステークホルダー特定」が追加されたのはBABOKの影響。

---