設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
設立して1年経過 - 急がば回れ、選ぶなら近道
この10月でノーチラスの設立1年という運びになりました。お世話になったお客様・パートナー様・応援して頂いた皆さんに感謝申し上げます。ありがとうございます。 ということで気づけば一年経過ということで、陳腐なようですが「光陰矢のごとし」の一言に尽きます。思えばこの一年はいろいろありましたというか、有り過ぎました。 ■Asakusaの状況「Hadoopの使い方としてのバッチ処理」という意義は市場ではアクセプトされた感もあります。この一年は、SI屋さんを始めベンダーさんやトップ・ノッチのエンドユーザーさんでの検証・小手調べの期間だったかな、と思います。結果としては「まぁ確かに速くはなるね」という点と、「まぁ確かに開発効率は高いわね」という二点については、程度の差こそあれ、大抵の利用者・検証者には認識してもらえた感じです。 一年終了時点での市場でのプレゼンスはそこそこには出せているので、まずは及第点
A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
某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にはかかわっているので、割と現状の問題も意識して
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の方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
CDH4説明会に行って参りました。 - 急がば回れ、選ぶなら近道
CDH4説明会に行って参りました。 日時：2012年7月6日（金） 場所：ベルサール八重洲 タイトル： 進化するHadoop：CDH4とCloudera Enterprise4.0のご紹介 アジェンダは以下の通り。 18:30 開場 19:00 開会のご挨拶（ジュゼッペ小林さん） 19:10 CDH4とCloudera Enterprise4.0（川崎さん） 〜エンタープライズにおけるHadoopの標準〜 19:50 CDH4はなぜエンタープライズに適しているのか（嶋内さん） 〜新しく導入された技術から読み解く〜 20:30 懇親会 21:00 閉会 以下、内容と感想をまとめておきます。スライドはあとで上がるそうなので、セミナーの詳細はそちらを参考にした方がよろしいかと。 あとはメモも上げられているので、こちらを見ると詳細がわかるかと。 http://d.hatena.ne.jp/gara
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のセミナーは大抵はここでやっていることが多い。 今回のセミナーはどうやら複数回やったようで、自分はこの金曜日に、同じ会社の他のメンバーは翌日に呼ばれたようだ。パートナー向けのプライベートセミナーで、「
AmazonのB2Bについて思うところ - 急がば回れ、選ぶなら近道
もの凄く個人的なまとめですので、その辺はご了承ください。 まずはこのサイト http://www.amazonsupply.com/ 試験的ではありますが、あのAmazonが業務用に手を出してきました、という内容です。まず、慌ててはいけませんが、そのまま普通にB2BでAmazonが圧勝かというと全然そんなわけはありません。仮に、日本で同じような商売をAmazonが始めた場合にどうなるか、ということを自分的にちょっと思うところをまとめておきます。 まず日本のB2B的な市場ですが、業務・業界ごとに割とそれぞれ縦割りで展開して成立しています。これはある意味、一種の効率的市場ができていると解釈すべきだと思います。その上、日本の場合の市場規模は、非常に大きい。これは個人の家計よりも、法人の経済活動の方が、日本経済に占める影響が非常に大きいことから考えても容易に分かります。こういった、B2B市場は日本
Hadoopは統計の基礎を無視しているのか？ - 急がば回れ、選ぶなら近道
http://ascii.jp/elem/000/000/687/687170/ こういう塩梅になった。これでも一応、最初に上がってきたインタビュー記事を訂正して、この状態という感じです。最初のほうはもっと派手だった。まー、さすがに読み手で不快に感じる人もいるだろうし、とはいえ、話したことをつないでいる部分は確かにあるわけで、はてどうしたものかな・・・と思っているうちにリリースになったというのが実態ですね。 えっと、まず読んで不快に思った方は確実にいらっしゃると思うので、その方たちにはお詫び申し上げます。すんませんでした。 その上で真意を書いておくと・・・ まず、Hadoopは統計の基礎を無視しているのか？という問題ですが、基本的にHadoopのBIで飯を食っている人は、いわゆる「データ・サイエンティスト」という職種の人たちにあたる方たちで、当然、統計のプロだ。当たり前の話だが、大抵のHa
Dosakusaフレームワークがリリース間近 - 急がば回れ、選ぶなら近道
ノーチラス社内でAsakusaと同時に開発されているフレームワークについて。 Dosakusaフレームワーク基本的にAsakusaフレームワークの上位で構成されているフレームワークで、Asakusaフレームワークの拡張仕様。N階層DSLにより構成される、現時点では100万階層まで確認されている。無数のオレオレDSLを、鬼の勢いでステージングコンパイルして、原型をなくして、最後はシンプルなニーモニックに変換しきる。可能コンパイルオプションは、guutara、shot、kobayashiの３つの隠しオプションがある。 -guutara 残念デバックモードになる。ちょっと間違うと、何やってんのそれ？とか言われる。よく見ると多少Haskellっぽい感じ。間違った箇所はなんか割と適当にでる。 -shot 若干まじめ愚痴デバックモードになる。筋があっていると、まぁいんじゃないでしょうか？というコメント
ノーチラス第二期の開始 - 急がば回れ、選ぶなら近道
Nautilus-technologiesの第二期に入った（というべきですね）。 まずAsakusaをOSSにして、早いものでもう一年になる。当時はとにかく3月中に公開するぞ、というぎりぎりの中での公開だった。相当無理があったが、チームが頑張ったので、なんとかできたというのが当時だったと思う。一年経過して状況を見ると、予想以上の反響になっている。ターゲットがそもそも業務系・基幹系のバッチ処理なので、名前が知られるには２−３年はかかるだろうな、と考えていたのだが、折からのビッグデータブーム（これはAsakusaの公開時点ではまだ来ていなかった）->Hadoopの知名度向上->バッチの高速化の流れにうまく棹さすように乗れている事も大きい。 また、OSSにしたことも結果として、よかった。まずは簡単に使えてもらえるということと、各SI屋さんや使い手のNot Invented Here 症候群への緩
小売業における個別原価法とシステムとその先に - 急がば回れ、選ぶなら近道
まず小売業の利益計算の基本的な会計処理は売価還元法になっている。ありとあらゆる原価法の中でもっともザルで、かつ、いい加減な方法の一つである。端的に言えば、一定のカテゴリーベースでの売価の総額と仕入の総額を総計して、原価率を算定して、その率をもって利益を算出する計算方法になる。また、基本的に棚卸法になるため、実際の棚卸を行い、原価計算期間終了時点での在庫金額を確定させないと、利益が算出されない仕組みである。 現場感覚でいうと、値入率（事前想定粗利率）から、実際のロス率を差し引いても、粗利率（事後達成粗利率）に一致しないため、直感に反するオペレーションになる。このため、数字にしっかりした人間であればあるほど、数字を信頼しないというモラルハザードな仕組みになっている。さらに、そもそも小売流通業の税前利益率は2-3%を達成できれば“優秀”であり、細かい利益率の管理が必須である。バイヤーレベルでは、
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
Hadoopは汎用機の夢を見るか？ - 急がば回れ、選ぶなら近道
オープン系の歴史は、基本的に汎用機との戦いでした。個人的にも自分の戦いも、わりとまじめに汎用機との戦いでした。Linux? おもちゃですね。Java? 飲めるの？Object指向? 品質高いの? ・・・まぁこんな感じでしたね。確かにLinuxはもはや標準になりました。Javaでの開発は普通になりました。Object指向以外の開発はまぁ普通にないですね。・・・しかし、残念ながら基幹バッチは未だに汎用機です。汎用機は未だに現役であり、基幹処理の根っこは、いまだ汎用機で動いています。信頼性は突出しているし、パフォーマンスもバッチ処理に関しては依然として最強だと言えるでしょう。新人COBOLな人のバッチが、ハイパーなOracle使いのSQLバッチを軽く凌駕する事は、まだ普通にあります。・・・なぜか？ 多重度が違いすぎますね。 汎用機はハードウェアからOSレベルまですべて、多重度が上がる事を前提に処
Asakusaでの設計・実装の方法についてのドキュメント - 急がば回れ、選ぶなら近道
Asakusaのドキュメントを大幅に見直し+追加しました。自分の担当は設計関連の部分だったので、その辺の“あとがき”的なものを以下。自分で書いて気になったところもまとめて置く感じで。 http://www.asakusafw.com/techinfo/methodology.html 1.設計手法について 理論的な背景はともかく、業務バッチ処理をどのように設計するか、ということについての一つの「やり方」を書きました。これは完全に経験則と過去の方法論の掘り起こしによるものです。基幹バッチ処理をデータフローで、ゼロから設計するという手法は、周りを見るところ、ほぼ完全なロスト・テクノロジーになってしまっていて、ちょっと見当たらないです。（調査が足りないという話もありますが） データフローベースの、（有り体にいうとCOBOLライクな環境での）バッチの作成は、現状では、メンテナンスで既存に手をいれる
年始の抱負〜仕事の師匠から教わった事 - 急がば回れ、選ぶなら近道
2012年の始まりなんで。記録として書いておく。今年の抱負も含めて。 ちょうど会社も立ちあげたし、こんな事を書いても良い世代になってしまったと思うわけです。 えっと、自分が師匠とよべる人はふたりしかいなくて、しかも性格は正反対だった。しかしながら、二人とも仕事は異様にできた。あんなにできる人は今まで見た事がないし、今後も見ることは無いと思う。（今時「師匠」って言い方もどうかと思うが、他に適当な言い方もないし。死語ですけど。） 一人目の師匠は、掛け値なしの鬼軍曹だった。本気と書いてマジという位、本気で怖い感じだった。ついていける人はほとんどいなかったと思う。僕はたまたま仕事に集中して余計な事を考えたくなかった時期だったこともあって、ゾンビのように働いた。月の残業時間が400時間とかいう時もあった。（勤務時間ではない） 死ぬかと思った。 仕事のやり方は、もう軍隊のようだった。ミスしたら、ミスし
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
来年のHadoop - 急がば回れ、選ぶなら近道
Hadoopアドベント・カレンダーの多分最終日のはず。 せっかくなんで、来年の予想でもしてみようかと。 日本の話です。世界のことはよくわかりません。本当のことは、日本には伝わらない（表向きの話はともかく、現状ではVCあたりの外野の方が発言力があると思うし、向こうでも、その辺の正確な情報は伝播してる気がしません）と思うので。とはいえ、日本のHadoopマーケットは、それなりわかっている（というか、わかっていないとまずい）感じみたいなので・・・勝手に、来年のHadoopとか予想します。外れたら焼き肉おごります。 1 大量データ処理でのデファクト化 ・いわゆるWeb系ではつかっていないところは一社もなくなる 特にレコメンデーションエンジンあたりは、もう普通に実装して使う。ただし、それ以上のものは出ない。集計処理と推論をうまく利用したレコメンデーションエンジン（とその亜流）、従来からのフィルタリン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
