ブックマーク / www.publickey1.jp (70)

  • IBMの新メインフレーム、商用初のトランザクショナルメモリ搭載でJavaを超高速実行。JavaOne 2012

    IBMのメインフレームにはJavaを高速に実行する仕組みが組み込まれている。JavaOne基調講演に続いて行われたIBMの講演では、そんな興味深い技術が紹介されました。 このメインフレームは8月末に発表されたばかりの新型で、1筐体で最大10万もの仮想サーバを実行可能という怪物のような性能のマシン。これひとつでその辺のデータセンター並の性能を持つといっても過言ではなさそうです。 しかも、商用マシンとしては初のハードウェアによるトランザクションメモリを搭載。ランタイム・インストゥルメンテーションなど多くの機能によってJava実行の高速化を実現したとのこと。業務用アプリケーションを実行するメインフレームにとって、Java性能が重要であることを示しているようです。 IBMの講演の一部を紹介しましょう。 4年前から取り組む IBM Distinguished Engineer、Java CTOのJo

    IBMの新メインフレーム、商用初のトランザクショナルメモリ搭載でJavaを超高速実行。JavaOne 2012
    estragon
    estragon 2012/10/15
    わろた / 「IBM Distinguished Engineer、Java CTOのJohn Duimovich氏。System z。こいつはメインフレームだぜ、すごいぜフォー!(注:本当にフォーって言った)」
  • 自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)
    estragon
    estragon 2012/09/24
    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説
  • Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる

    先週6月14日に発生したAmazon Web Servicesの米国東部リージョンでのシステム障害は、HerokuPinterestなど大手のサービスにも影響を与えたようです。その障害報告が、Service Health Dashboardで公開されています(現在はRSS内の記述として読めます)。 障害は米国東部リージョンでの特定のアベイラビリティゾーンで発生したもの。報告によると、プライマリの電源ケーブルのトラブルをきっかけにバックアップとしての発電機へ移行したものの、そこでもまたトラブルが発生し、二重、三重の防護策が次々に倒れていったことが示されています。 Amazonクラウドの多重の防護策の一端が分かると共に、これだけバックアップ策が用意されていても、わずかなトラブルによって防護策が倒れることの教訓を得ることができます。 一方で、障害は特定のアベイラビリティゾーン内だったため、マル

    Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる
    estragon
    estragon 2012/06/24
    3重に冗長化された電源が次々に死んだとのこと。事象・対応をオープンにしていることが好印象。 / Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる
  • テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ

    テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5%(「既に導入済みである(追加リプレイスなし)」7.5%と「既に導入済みである(追加リプレイスあり)」の1.0%の合計)で、導入を検討しているが4.8%。今後も導入しないするグループは86.7%(「必要性を感じているが導入を検討していない」の38.6%と、「必要性を感じない」の48.1%の合計)」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15%である一方、100名以下では1.8%であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト

    テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ
    estragon
    estragon 2012/06/10
    開発現場では断片的に使ってるところが多いはずだが、システム部として取り組んでないってことだろうな / テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ
  • グーグル、BigQueryを正式公開。SQLで大規模データに対して高速処理

    BigQueryはカラム型データストアの一種で、テラバイトクラスの大規模データに対して大量の並列処理を行うことで高速に結果を得ることが可能。グーグル 佐藤一憲氏の発言によると、 OLAP/DWH/Data Miningで行われるようなread onlyのad hocクエリをきわめて高速(数秒〜数十秒)に実行します。 とのこと。 SQLによる問い合わせが可能 この高速性に加え、BigQueryではSQLを問い合わせ言語に使えるという点にも大きな特徴があります。数秒程度のレスポンスとSQL文による記述は、大規模データに対するアドホックな処理を行うのに適したサービスだといえるでしょう。 BigQueryのSQLの構文は「Query Reference」で解説されていますが、SELECT文にFROM、WHERE、JOIN、HAVING、GROUP BY、ORDER BY、LIMITなどが使えるため

    グーグル、BigQueryを正式公開。SQLで大規模データに対して高速処理
    estragon
    estragon 2012/05/14
    グーグル、BigQueryを正式公開。SQLで大規模データに対して高速処理 - Publickey
  • 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態

    今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩氏の提案についても掲載したいと思います。 以下からは萩氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記(注:記事の元になったFacebookへの書き込み)を書いたのは、二度とこのような案件が出ないよう質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 質的問題を提起したつもりですが、しかし当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何

    特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
    estragon
    estragon 2012/02/03
    企業内でITシステムを戦略上重要なものと位置づけるところからかなと。特許庁の件は派手に崩壊して救われたサブコンもありそう / 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
  • 特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐

    特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 [スクープ]特許庁、難航していた基幹系刷新を中止へ - ニュース:ITpro 朝日新聞デジタル:費やした55億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO(ガバメントプログラムマネジメントオフィス)補佐官」の肩書きで2009年まで民間から参加した萩順三氏(現 匠BusinessPlace 代表取締役社長)がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩順三氏の発言の主要な部分を引用します。 内閣官房GPMO(ガバメントプログラムマ

    特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
    estragon
    estragon 2012/01/30
    「なぜ失敗したのか、どうすべきだったのか、しっかりと振り返り、その情報が今後のために公開されるような動きになることを期待」/ 特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏
  • 分散リアルタイムデータベース「SenseiDB」がオープンソースで公開。LinkedInのインフラとして開発

    テキストなど非構造化データのデータベース機能とサーチエンジン機能を兼ね備えた分散リアルタイムデータベース「SenseiDB」が、オープンソースとして公開されています。 SenseiDBとは先生DBの意味らしく、「Sensei (先生) means teacher or professor in Japanese」と説明があり、ロゴにも「師」の文字が使われています。なぜ先生なのか、その意味について以下のように説明があるのですが…… This name indicates that the system can be used in place of Oracle database in many applications. この名前が示しているのは、このシステムが多くのアプリケーションにおいてOracleデータベースで使われているところで利用可能だということです。 TeacherやProfe

    分散リアルタイムデータベース「SenseiDB」がオープンソースで公開。LinkedInのインフラとして開発
    estragon
    estragon 2012/01/23
    名前に注目してしまう。確かに命名理由がよくわからない。「Oralce(預言者、神託)」の代わりに使えると「先生」なのか? / 分散リアルタイムデータベース「SenseiDB」がオープンソースで公開。LinkedInのインフラとして開
  • 「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る

    「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る 「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ 宇治浩明氏。 東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。 東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか? 9月9日、早稲田大学 西早稲田キャンパスで行われた日科学技術連盟主催「ソフトウェア品質シ

    「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る
    estragon
    estragon 2011/09/26
    「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る
  • さよなら、僕が知っていたイーサネット

    20年ほど前にイーサネットを学び始めた頃、イーサネットの2つの大きな特徴を教わりました。1つは、イーサネットでは複数のノードがケーブルを共有しているため、信号の衝突(コリジョン)が発生すること。もう1つはネットワーク構造には決してループとなる部分があってはならない、ということです。 しかしこの2つの特徴は、イーサネットの進化とともに消え去ろうとしています。イーサネットは僕の知っている昔の姿から大きく変わろうとしているのです。 コリジョンはなくなった イーサネットの大きな特徴の1つが、CSMA/CD(キャリアセンスマルチプルアクセス/コリジョンデテクト)です。ネットワークに複数の機器が接続されている場合、同時に通信を開始するとネットワーク上で信号が衝突するコリジョンが発生、コリジョンの発生が検出された場合には、それぞれの機器はランダムな時間だけ待って再送する、という仕組みです。 これによりイ

    さよなら、僕が知っていたイーサネット
    estragon
    estragon 2011/06/06
    さよなら、僕が知っていたイーサネット - Publickey