先日をもって無事に読了しました。記念に記録しておきます。 読んだ本はこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー

勿論ネタだ。たまにはいいでしょう。 まず、IT系の人間で、スポーツ好きはサッカーファンがおおいような気がします。いや、単に主観なだけという説もありますが。これは、サッカーの特長が「戦略」だったりすることも多少は影響していると思います。まぁ要するにIT屋さんはシステマティックなスポーツが好きだったりするわけで、よって隠れバスケ・隠れアメフトファンも実はそれなりにいらっしゃいますが、やはりサッカーファンが多いでしょう。 さて、どうでもいいですが、ひいきのチームごとに、その性格がカテゴライズできるので、ちょっとまとめておきますよ。 サッカーといえばスペインなわけです。いや、プレミアだろうとか、日本人ならブンデスだろうとか、基本はセリエでしょとか、いやいやリーグ・アンは捨てがたいとか、どうでもいいです。ユーロ・ワールドカップ・ユーロと事実上の世界選手権３連覇している国が最強ですよ。何言っているんで

Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ

ニュースリリースというか記事はこちら。日経の中田さんの記事ですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20130306/461423/ この辺の解説を記録のために書いておきます。個人的にはちょっとしたマイルストーンなので。 まずEDIの定義ですが、これはElectronic Data Interchangeの略で、B2Bでの電子データ交換の仕組み自体をさします。歴史的にはITの歴史と同じくらい古い。当然インターネットよりも古い。昔は（場所によっては今も）電話で”ぴー”とか”がー”とかやっていた代物です。多分50年以上の来歴を誇る仕組みですね。業界ごとにその業界に応じたプロトコルが制定されており、いわゆる標準化がもっとも進んだ分野のひとつです。そして、大抵はミッションクリティカルな業務に属します。エンタープライズ系のITでは最下層に位置するレイ

http://www.nikkei.com/article/DGXDZO50933940U3A120C1MM8000/ どうやら本格的に複数税率が消費税に適用されるようです。まだ、決定でもないし、今後の業界の猛烈な反対もあるだろうから、どうなるか分からないのですが、その辺を部外者的に（かつ元関係者的に）記録として書いておきますよ。 この軽減税率で、もっとも変更のコストがかかる「仕組み」の一つはITであることは、多分論を待たないと思います。特に、税率を複数適応する羽目になる流通・サービス系のITは下手をするとかなりのコスト負担になるところも出てきます。またか！またコストですか！いや、これこそがITなのですよ。 まず影響が出てくるところ予想すると、事の大小はありますが、ほぼ大抵のところで手を入れる必要がある気がします。んで、例によって、多分この辺が正確に予想できている、CIOを除く経営陣は皆無

某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して

2012年の現在、割と悩んでいるのでメモっておく。 年度末ぐらいに再調査の予定。・・なので暫定ですよ。 まず前提として、現行のHadoopの実行フレームワークであるMapReduceは、実行効率は決して良くはないです。この辺が割と辛い。 とはいえ、大規模並列処理を一般的に行うという観点での品質や取り回しを考えた場合、”結果として”非常にバランスがとれており、普及している。その上で、このMapReduceですが、今後の見通しについては、潮流は今のところ二つに割れているよう見える。ので、その辺のメモ。 ■YARN 一つの方向性は、現在のHadoop2.0系で実装されているMapReduce2.0、というか、MapReduceとは別の実行基盤を利用するという方向ですね。すなわちBSPや、MPIを利用する。要は、今までの並列処理の成果をそのまま利用しましょう、という流れに近い。 MapReduce

某プロジェクトが一旦のキリがついたので、ちょっと今までの経験とかまとめてをupdateしておきます。 これから記す内容は、実際のモノをハンドリングする業務ITについて、特にそのデザイン（設計）のポイントについての考え方です。一応、検討の範囲外にあるものは、モノそれ自体よりもその情報に本来的な価値があるような財・サービスになります。例えば金融。（実はあまり違いはない、という話もありますが、相対的に曖昧な部分があるのは事実だと思うので、一応除外しておきます。） まず、いきなり要諦ですが、そもそも業務系のシステムや仕組みを設計するときの最大のポイントの一つは、「PxQを分けて管理し、どの時点でかけ算するか？」という風に考えると良い、という点です。経験的に非常に見通しが良いことが多い。 ここでいうP(price)はコスト・プライス・価額等々の単価/原価/売価系の情報をさします。またQ(quanti

ちょいと家を掃除してて、バックナンバーのフットボリスタの特集が「チームリーダーの10か条」になっておりまして。この雑誌、サッカーは海外でしか存在しません、とばかりに、日本代表とかガン無視の今時珍しいサッカー雑誌でございますが、なんとかいうかサッカーというより「文化」を記述しているのじゃまいか？ということが多すぎるわけです。この特集があまりにもサッカー以外に当てハマるので、ちょっとITにおけるチームリーダー論的に書いてみる。 1 「３０代のベテランが望ましい」ITチーム的には、これはありですね。確かに技術的な吸収力や体力では20代が優位で、政治力優位では40代に以降にはなる。とはいえ、ある程度の経験をもっている上で、かつ過度に政治的になっていない状態で、20代を御せるのは30代ですよ、ということは正しい。しかし、なんというか最近はベテランの勢いがなさすぎな感もあるので、なんとか頑張ってほしい

Amazon EMR セミナーに行ってきたので、個人的にまとめておく http://kokucheese.com/event/index/34636/ 日時： 2012/5/18 14:00 – 17:00 会場： アマゾン目黒オフィス 東京都目黒区下目黒1-8-1アルコタワーアネックス16F メインスピーカーは、EMRのSenior Product Manager の Adam Gray氏 場所は目黒のAmazonJapanの本社。渋谷の東邦生命ビルの時とは大違いで、ビル全てがAmazonという陣容。16Fのセミナールームはおそらく200名前後は余裕で入れるしっかりした部屋で、東京でのAWSのセミナーは大抵はここでやっていることが多い。 今回のセミナーはどうやら複数回やったようで、自分はこの金曜日に、同じ会社の他のメンバーは翌日に呼ばれたようだ。パートナー向けのプライベートセミナーで、「

エンタープライズのOSSについて こんなこと書くとOSSなモヒカンな人にぶん殴られるわけです。読み手の方で、自分はOSSを引っ張ってきたと自負されている方や組織のかたや、OSSは商用より無条件で優れていると思っている人は気分が悪くなるので、読まないでください。非常に個人的なメモですので。以下の考えは基本的にソフトウェア・ビジネスとしての考えなので、自分で作って、自分で利用して、ムフフな人はあんまり考えてないので、そのつもりで読んでね。自分利用OSSはそれでいいと思うので、それでいいかと。 [まずAsakusaについて] まずAsakusaがなぜOSSかということを明確にしておきます。非常に単純です。Asakusaは様々な人の意見を集約してできています。これは別にNautilus-technologiesのメンバーというわけではなく、Hadoopコミュニティに参加した方の意見を相当取り入れて

某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と

自分的な話題なので書いておきたい。 まず立場的はっきりさせて置く。AWSを基本的にはエンタープライズ・ユースで考えています。もっと直裁にいえば、Asakusaの実行基盤として、すなわちEnterpise Hadoopの実行基盤として見ています。クラウドの利用は単社ではできないことをできるのが特長であり、それは現時点では分散処理です。多数のノードを利用する分散処理は、単社で持つにはコスト的にペイしません。ので、一種のハードの共同利用としてクラウドを利用すべきです。単純にレンタル・サーバーの延長上で見るのであれば、クラウドのメリットはないでしょう。分散処理を一定の計算資源を利用して行うことがクラウドでできるかどうかがポイントと考えています。AWSは十二分にこの目的には合致しています。特にパブリックではないVPCの存在は非常に大きい。 （分散処理としてHadoopMapReduceが最適か？とい

まず、社内のオープニングで説明した内容だったりするのですが、一回まとめておきたいので。 断っておくとこの言い方はニコラス・ネグロポンティから取っています。彼の主張は明確でいままでアトム（物質）的な存在だったものが、ビット（電子情報）的な存在に凌駕される、いや大きく姿を変えてるという指摘でございますね。Being digitalが出版されたのが95年なので、もう15年以上になるわけですね。ま、ざっくりすぎてアレですが。・・ワーディングとして便利なので利用させてもらいます。 まず、主題は何かというと、「バッチが速くなって何がうれしいのか？」という問題の背景をちゃんと説明しておきたい。もともとHadoopで何がしたかったのかというと、そもそもバッチのスピードを上げたかった。そもそもRDBMSではまぁ限界があったというのが事の起こり。んで分散処理を行うとIOが分散されるので、スピードがあがりますね

先週の月曜日にお披露目会的なものがあったので行ってきた。 ちょいと前半戦は見れなかったので、肝心なところを見てない説もあり、その辺は割り引きたいが、まず印象まで。 Jubatus http://jubat.us/ 基本的なラインは、言ってみれば、分散CEP+機械学習というコンセプト。（ある程度の）リアルタイム性を重視して、データの使い捨てをベースにして、スケールアウト戦略を選択している。溜めてから学習するのではなく、ストリーミングしながらの学習というコンセプトに見える。アーキテクチャはN:Nな感じ。耐障害性はどこまで見ているのか？ってのはあるが、まずはスループットを優先したのと、ボトルネックが発生しないように割と気を使っているのはわかる。おそらくもっとも重視したのは「使い勝手」だろう。 まず、現状の日本のITでは機械学習は使いこなすだけ精一杯という中で、アーキテクチャや仕組みまで考えたフレ

どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

まぁちょっと遅くなったのですが、やっと時間が空いたので アンケート結果のレビューをしてみます。 Hbase@FacebookFacebookのJonathan Grayさんのお話の勉強会でした。 1：Hbaseを導入していますか？有効回答：114 本で読んだ　63(55.3%) 触っている　39(34.2%) 体制を構築した　7(6.1%) POC中　2(1.8%) Hbaseなら任せろ　3(2.6%) 過半数が本・雑誌読んだという状態でした。 もっともHbaseの勉強会でのプロダクション提供を おこなっている人という質問に対して 挙手がほとんどいなかったことを考えると そのような状況なのは仕方がないところかな、と思います。 まぁ一方で実際に触った人が1/3を超えているの興味深いところです。 体制の構築とPoC中でも計9件の方（8%）が挑戦中という状態です。 典型的なアーリーステージと言っ