オラクルがEngine Yardに出資。Oracle CloudでRuby、PHP、Node.jsのPaaS実現へ
オラクルとEngine Yardの両社は、オラクルがEngine Yardに対して戦略的投資を行うことを発表しました（日本語訳）。オラクルはEngine Yardの少数株主となり、Engine Yardは引き続き独立した企業として存続します。 Engine Yardは、Ruby、PHP、Node.jsをクラウド上でPaaSとして提供している企業。Amazonクラウドを基盤に運営されている同社のPaaSは、顧客ごとにデータベースやミドルウェアなどのリソースが分離されているシングルテナント方式を採用しているため耐障害性などに優れる特徴を持っています。今年の9月には日本法人も設立されました。 今回のオラクルの出資により、具体的に両社の関係がどうなるのか、オラクルが発表したプレスリリースの一部を引用します。 In conjunction with this investment, Oracle a
ブロケードがVyatta買収を発表。物理と仮想を包括する戦略へ
ファイバーチャネルのスイッチやイーサネットスイッチの大手、米ブロケードコミュニケーションズシステムズは11月5日、ソフトウェアルータ「Vyatta」（ビアッタ）の開発元であるVyattaの買収を発表しました。 Brocade - Brocade Acquires Vyatta, a Pioneer and Leader in Software Networking オープンソースで開発されているVyattaは、ルーティング、ファイアウォール、VPNなどの機能を備えており、VMware ESX、Xen、Hyper-V、KVM、Oracle VMなどの仮想環境で動作します。 ブロケードによる買収に当たり、Vyatta.orgはコミュニティに向けて、引き続きオープンソースとしてサポートが続くことを宣言しています。 First, we’d like to assure you that Vyatt
［ウェブサービスレビュー］住所出力もできるダミー個人情報出力サービス「疑似個人情報データ生成サービス」
内容：「疑似個人情報データ生成サービス」は、ダミーの個人情報を大量に出力できるウェブサービスだ。かんたんな操作で郵便番号や住所を含む最大5000件の個人情報を作成してダウンロードできるので、会員制サイトのテストなどで実在しない個人情報が大量に必要になった場合に便利に使える。 「疑似個人情報データ生成サービス」は、ダミーの個人情報を大量に出力できるウェブサービスだ。かんたんな操作で郵便番号や住所を含む最大5000件の個人情報を作成してダウンロードできるので、会員制サイトのテストなどで実在しない個人情報が大量に必要になった場合に便利に使える。 使い方は簡単で、一覧から必要な項目を選び、ボタンを押して生成するだけ。あらかじめ用意されているデータをランダムに掛け合わせた個人情報が出力される。出力数は最大5000件で、画面上にそのままHTMLで出力するほか、XML、Excel、CSVの4形式での出力
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
最強のIT系かあちゃんからたかしへのアドバイス
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかったです。でも、このシステムを使う人にどういうメリットがあるか分かりませんでした。
情報処理推進機構：ソフトウェア・エンジニアリング - ｢非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」 報告書を公開
2012年6月19日更新 2012年3月28日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 近年の日々加速するビジネススピードは、ビジネスを実現する情報システムの要件に変化をもたらしています。従来、多くの情報システム開発、特に規模の大きなプロジェクトにおいて、「ウォーターフォール型開発」が用いられてきました。しかしこの開発手法の場合、開発前に要件を確定させることが前提となっており、要件の変化への柔軟な対応が求められる昨今の開発に適合させることが難しいと言えます。一方、この変化に柔軟に対応できる開発手法として、アジャイル型開発をはじめとする「非ウォーターフォール型開発」があります。しかし、非ウォーターフォール型開発は、密接なコミュニケーションを必要とするため、従来その多くは、少人数での規模の小さい開発プロジェクトやWebサービスなどの一部のビジ
［速報］スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令
勘定系システムの開発失敗を巡り、スルガ銀行が日本IBMに115億8000万円の支払いを求めた裁判で、東京地方裁判所は2012年3月29日、日本IBMに74億1366万6128円の支払いを命じる判決を言い渡した。 スルガ銀行は2000年代初頭に勘定系システムの刷新を計画し、海外製の勘定系パッケージ・ソフト「Corebank」を担いだ日本IBMの提案を採用した。ところが刷新プロジェクトは要件定義から難航。新システムを完成させることができなかった。 結果的にスルガ銀行は日本IBMに新システムの開発中止を通知し、2008年3月に「日本IBMの債務不履行によりシステムの開発を中止せざるを得なくなった」として、日本IBMに損害賠償を求める訴訟を東京地裁に提起していた。 関連記事：“スルガ銀－IBM裁判”を振り返る ■変更履歴 スルガ銀による賠償請求額について、当初の記事では「111億700万円」と書い
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
燃え尽き症候群に陥らないために--ITプロフェッショナルが避けるべき10の行動
ストレスや極度の疲労、健康上の問題、能率の低下、無気力--仕事を続けていくなかでマイナスとなる行動を積み重ねた挙げ句に燃え尽きてしまった時、これらすべてがあなたの身に降りかかってくる。 自らの過去を振り返ってみてほしい。仕事や生活のなかで基本的な行動指針に沿わないことをした覚えが一切ないと言い切れる人など1人もいないはずだ。はっきり言って筆者自身、燃え尽き症候群の原因となるような重大な過ちを何度もしでかしてきた。最近、自らのキャリアを少し違った観点から振り返ってみる機会があり、それにより何が間違いであるのかを理解できるようになった。幸いなことに、こういった過ちから学ぶことで、今後仕事を続けていくうえで必要となる満足感や健康、能率（これらは優先度の高い順である）を損なわずにいられるようになるはずだ。以下では、能率の低下や不健康なライフスタイルにつながりかねない行動を10個紹介する。 ＃1：絶
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
ドコモSPモードのトラブルに学ぶ5つのこと
追記しました：spモードの障害報告にとんでもない内容が追記されている件 DoCoMoでSPモードに不具合があり、送信者のアドレスが書き換わってしまうという現象が発生した。 原因の詳細はIT proに書いてあるのでそれから何を教訓に出来るかを考えてみた。 バグの経験のないプログラマーは居ないだろう。 プログラマーでなくても仕事上、大きなトラブルに出会う事は少なくないはず 今回はそれがユーザー数が多く、その影響が甚大（メールアドレスや場合によっては本文が他人にバレる）なところで発生したので大きなニュースになったけれど次は自分がその立場になるかもしれない。 そうならないよう、他山の石としたい 問題の原因は、 1.IPアドレスで個体認証をしていた。 2.サーバーの不具合でIPアドレスと個体をひもづけるサーバーが遅延した。 3.結果、端末のIPアドレスが書き換わった際、個体とひもづかなくなり他人と識
「オープンソースに貢献しちゃいかん」と会社に言われる？
日本でオープンソースへの貢献が増えない理由として、先日次のような話を聞いて「そうかもしれないなあ」と思いました。 「プログラミングを仕事にしている人がオープンソースのためにコードを書くと『仕事上で得た知識なんだから、社外に公開するのはダメ』とか、『オープンソースでコード書く時間があるなら、もっと仕事としてやらないのか？』といった干渉を会社から受けるケースが結構あるようだ」 月曜日の夜に行われたIBM developerWorksブロガーズミーティングでのディスカッションの中で出てきた意見です。 ミーティングのあとの二次会で、ブログ「むささびの視点」の谷川さんやブログ「一般システムエンジニアの刻苦勉励」の山口さんとこの件について少し立ち話をしました。 谷川さんは似たような話として「会社が社員に対して、ブログを書くならこういうことはOKだけど、これはダメだからね」といったガイドラインがあれば、
「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る
「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る 「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ 宇治浩明氏。 東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。 東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか？ 9月9日、早稲田大学 西早稲田キャンパスで行われた日本科学技術連盟主催「ソフトウェア品質シ
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
「遅れているプロジェクトに追加人員を投入するとさらに遅れる」法則を逆向きに適用 - 人生を書き換える者すらいた。
久々の更新です。 相変わらず忙しいですが、最近の仕事の大きなポイントは上海と香港に良いビジネスパートナーが見つかったことです。いつまでも日本だけで活動してても明るい展望は描けないのでチャンスを伺ってましたが、来月ぐらいからこちらの新プロジェクトに本腰を入れることになります。日本が総体的にはだんだんダメになっていく、というのは抗し難い流れだけれども、震災と菅政権がそれをグッと加速させたと思う。 今日書くのは、先月の「なぜ優秀なプログラマは人を雇わないか」に関連して、いかにして少人数の非請負型プロジェクトの成功確率を上げるか、という話。前から考えていたことを、新プロジェクト開始にあたって改めて整理してみた。 ここでいう成功、というのは、きっちり黒字を出す、ということである。 例題として、平均的なプログラマ10人のチームで10ヶ月かかるプロジェクトがあるとしよう。100人月だから、ざっと１人月5
最近話題の「カラム型データベース」とはどんな仕組みのデータベースか？
トランザクション処理を重視する一般的なデータベースは、1行ごとにデータを扱う。カラム型データベースはそれとは異なり、列方向にまとめでデータを扱うことで集計作業などを得意とし、データウェアハウス用途などに用いられている。 「カラム型」あるいは「カラムストア型」「列指向型」などと呼ばれるデータベースの話題が目立つようになってきました。 例えばSAPのHANA、IBMが買収したNetezza、ヒューレット・パッカードが買収したVertica、オラクルのExadata、それにNoSQLの代表的なデータベースCassandraなどがカラム型データベースの機能を備えています。また、マイクロソフトの次期SQL Serverにもカラム型データベース機能が統合されると伝えられています。 とはいえカラム型データベースは最近登場した技術ではなく、Sybase IQでは10年以上前から採用されていた仕組みでした。
もしキュゥべえがブラックITの営業だったら : ゴールデンタイムズ
1 ：仕様書無しさん ：2011/05/14(土) 19:34:10.69 ぼくと契約してデスマプロジェクトに入ってよ！ 2 ：仕様書無しさん ：2011/05/14(土) 19:38:16.07 「まどかがPGになれば、マミよりずっと凄腕PGになれるよ」 「もちろん、どんな案件で契約するかにもよるけれど」 「まどかが産み出すかもしれない単価の大きさは、僕には測定しきれない。 これだけの資質を持つ子と出会ったのは初めてだ」 4 ：仕様書無しさん ：2011/05/15(日) 08:11:43.77 「僕はプログラマになってくれって、きちんとお願いしたはずだよ？」 「実際の状況がどういうものか、説明を省略したけれど」 「訊かれなかったからさ。知らなければ知らないままで、何の不都合もないからね」 5 ：仕様書無しさん ：2011/05/15(日) 08:27:13.83 |::::::::::
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
猛暑でサーバー障害、そうなる前に確認すべきこと～データ復旧.comに聞く 