「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
オブジェクト指向による情報インパール大作戦 - camlspotter’s blog
えー、なんだか、(都合の良い)情報というのはそれを望んでいる人の所に自然に集まってくるようなのです。大変芳しいネタに行き当たってしまいました。(id:mzp さんどうも情報ありがとう。) まじめなオブジェクト指向論を繰り広げたく、少しづつ論考してはいるのですが、寄り道の誘惑に抵抗できません。 挑戦: 金融工学を駆使した先進的市場系システム開発に挑んだ精鋭たちの物語!、なのか？これが？ プロジェクトX型神話、と私が呼んでいる都市神話類型があります。場所や登場人物がころころと変わりますが、基本的なプロットはまず全て同じで、大まかに次の起承転結四要素からなっています: 挑戦: 優秀な人材が夢一杯に新プロジェクトを開始。 挫折: 予測もしていなかった難題にぶつかる。 打破: 社員の才能と努力で解決! 成功: 得られた教訓を語る、プロフェッショナル仕事の流儀 もちろんこの類型の大元はNHKの人気番組
サーバー起動用に JavaScript が 1 秒以上実行されなくて alert しないブラウザを作る - IT戦記
はじめに サムネイルサーバーのようなサービスを作るときには、ウェブサーバー上にブラウザを乗せる必要があります。 問題 ただ、そういった用途でブラウザを使う場合。 JavaScript が無限ループに落ち入らないように配慮する必要があります。 ほとんどの場合は、 JavaScript 自体をオフにすることが多いのですが JavaScript を実行したいような場合もあるでしょう。 解決方法 今回は、 WebKit でその解決方法を紹介します。 1. まず WebKit のソースコードを取得する svn co http://svn.webkit.org/repository/webkit/trunk WebKit 2. 次に、タイマーの時間を短くする WebCore/bindings/js/JSDOMWindowBase.cpp を編集 JSDOMWindowBase::JSDOMWindow
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
NTTデータがウォーターフォールから脱却? - ひがやすを技術ブログ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
天空の鯖ラピュタ
[N:TM] ライトニングトーク ～ 不在通知P![[N:TM] ライトニングトーク ～ 不在通知P](https://cdn-ak-scissors.b.st-hatena.com/image/square/eb02d28824405c65edd675ae832b470e3bcb82fa/height=288;version=1;width=512/https%3A%2F%2Fnicovideo.cdn.nimg.jp%2Fthumbnails%2F4469920%2F4469920)