Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道
最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか？というお話から始めます。もう枯れてんじゃないか？今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの（RDBMSとは限りません）が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
Amazon Glacierについて - 急がば回れ、選ぶなら近道
まずはリリース案内 http://aws.typepad.com/aws_japan/2012/08/amazon-glacier-archival-storage-for-one-penny-per-gb-per-month.html 実際のアーキテクチャや使い勝手は今後のレビューを待つとして、まず基本的にS3以上に、既存のDCに対して脅威となるサービスが出てきたと言えるでしょう。 AWSの最大の長所にして最大の短所はS3であることは、まぁ周知の通りです。クラウドで、ほぼ完全にスケールアウトするS3は、事実上AWSの根幹になっています。あまたのサードパーティーに提供されている実績は、他にほぼ競合が見つかりません。他方、また同時に、使いもしないのに置きっぱなしだとコストメリットがかなり下がるという弱点がありました。 これに対して、AWSに技術的にほぼ追いつけない日本のDCの最後のアドバンテ
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
「チームリーダーの１０か条」 - 急がば回れ、選ぶなら近道
ちょいと家を掃除してて、バックナンバーのフットボリスタの特集が「チームリーダーの10か条」になっておりまして。この雑誌、サッカーは海外でしか存在しません、とばかりに、日本代表とかガン無視の今時珍しいサッカー雑誌でございますが、なんとかいうかサッカーというより「文化」を記述しているのじゃまいか？ということが多すぎるわけです。この特集があまりにもサッカー以外に当てハマるので、ちょっとITにおけるチームリーダー論的に書いてみる。 1 「３０代のベテランが望ましい」ITチーム的には、これはありですね。確かに技術的な吸収力や体力では20代が優位で、政治力優位では40代に以降にはなる。とはいえ、ある程度の経験をもっている上で、かつ過度に政治的になっていない状態で、20代を御せるのは30代ですよ、ということは正しい。しかし、なんというか最近はベテランの勢いがなさすぎな感もあるので、なんとか頑張ってほしい
Amazon EMR セミナーの記録 - 急がば回れ、選ぶなら近道
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のセミナーは大抵はここでやっていることが多い。 今回のセミナーはどうやら複数回やったようで、自分はこの金曜日に、同じ会社の他のメンバーは翌日に呼ばれたようだ。パートナー向けのプライベートセミナーで、「
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
会社を作りました。 - 急がば回れ、選ぶなら近道
さて、会社を作った。 （元）EC-ONEの最首さんと一緒につくった。 EC-ONE側は、SI事業をウルシステムズへ統合して、分社化する。 僕らのチームがそのままEC-ONEに移動し、そして新しい会社を作る。 分散をやっているEC-ONEの福岡のチームと合流して、 分散技術や次世代の技術を業務に活かすということを いろいろでやっていく会社（というか入れ物だ）を作る。 分散技術にウェイトを置いて起きつつ、ソリューションにしていくための入れ物ですね。 「ノーチラス・テクノロジーズ」 NAUTILUS Hadoopや分散技術をエンタープライズに活かしていくことを 目的にした日本では最初の会社になると思う。 1.まず手始めにHadoopを中心の道具立てにしていく 幸いAsakusaもチームの頑張りで晴れてOSSになったし、 実際に動いている 開発効率の高さは自分でもびっくりしているぐらいだ。 分散技
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
