mixiで、「業務経歴書にPerl案件を書くと馬鹿にされる件」という話が出て、それについていろんな方が意見を述べられていて、とても興味深い。(例えば、Java圏とPHP,Perl圏の断絶について。 や、 なぜ「業務にPerlは使えない」のかなど) もともと、WWWが普及する前は、Perlといったらシステム管理者のたしなみというか、「レポート作成」のためのプラクティカルなツールってことで、使いこなせれば色々生産性が高いよねって感じのツールだったんじゃないかと思う。(これ想像) その後、ウェブが普及してきて、ブラウザから投げられた入力を色々処理したいって要求が出てきたとき、これちょうどいいじゃない、ってことでPerlがチョイスされたと。「The duct tape of the internet」つまり、インターネットのガムテープ、とか言われたりするんだけど、(ちなみに、ダクト・テープっていう
はてなラボのサービスhttp://hatena.g.hatena.ne.jp/hatelabo/20060221/1140521491と言うのは何がなんだかよくわからないのだが、なんとなく面白そうという感じのものだ。だけど、ヘルプも何もついていないので使い方が正直よくわからない。 さっそくLife is beautiful (http://satoshi.blogs.com/life/)さんが噛み付いた。いわく「50%の完成度でサービスを出す」という言葉を誤解してはいけないである。(50%の完成度でサービスを出すも参照のこと。http://d.hatena.ne.jp/jkondo/20060222/1140588819もね) おっしゃる通りである。おっしゃる通りであるが、ちと週末考えてみた。 昔、シリコンバレーにいたころわたしのソフトウェア開発に関する思いを根本的に変えたことの一つが、「
Windows Vistaは、UNIXベースのOSに付き物の高レベルの信頼性に近づいているのかもしれない。 これはわたしの友人ロブ・エンダールの言だ。良識ある意見だ。 極めて洞察力があることで知られる業界アナリスト兼コンサルタントのエンダールによると、Microsoftはハードベンダーに、Vista搭載ハードの仕様にECC(エラー訂正コード)メモリを入れるよう推進している。 それは、Microsoftは今調べているドライバの問題から、Windows XPのシステム・アプリケーションのクラッシュの主な原因がメモリの欠陥にあることを知ったからだ。この問題を修正すれば、ECC対応ハードで実行されるWindows Vistaの信頼性は大幅に改善されるはずだとエンダールは言う。 ここでちょっと歴史を振り返ってみよう。Microsoftは長い間、ほとんどのシステムクラッシュ(またの名を「死のブルースク
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 今回のハードウェアの信頼性について説明する。その前に、お話を一つ。 人里離れた温泉に向かって山道をドライブしていると、なんだかエンジン音がおかしい。何が起こったのか分からないまま走っていたら、とうとう止まって動かなくなってしまった。 ボンネットを上げて見てはみたが、プロじゃないのでさっぱり分からない。携帯電話で修理屋を呼ぼうとしたが、山奥なので電波が届かない。もちろん近くにガソリンスタンドや公衆電話があるはずもない。通りかかる車もなく、家族を残して私は歩いて山を下り始めた。幸いにも民家を見つけたので、電話を借りて修理屋に連絡がついたが、到着するまで1時間以上待たされた。 この間、家族は暖房もない山中で心細い時間を過ごし、生命の危険すら意
ライブドアの技術の話へのYamatoさんのコメント 我々はライブドアのポータル以上のシステムをいくつも見ることが出来ます。電話の交換機、気象予報システム、大企業のERPシステム、コンビニのPOS等、ライブドアが素人の集団では無い事に間違いはないでしょうが取り立てて技術が素晴らしいというレベルでもないと思います。 (中略) そう、システムの負荷限界を超えれば落ちるのは常識それはライブドアのサイトも同じ ただ、ライブドアのサイトはその負荷限界の設定値がその規模に対して高かったとそれだけにすぎません。 otsuneさんのコメント 「テレビでガンガン放映されているのに、あの手のポータルをアクセス不能にしないこと」ってのがどれだけ困難で、金だけではない技術が必要だ。ってのは、大規模Apacheサイト運営についてを見聞きした技術者には自明の話なのだけど。それがこのコメント欄に代表されるような「たんにコ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
2006年01月29日00:51 カテゴリMediaiTech TVではかき消せない、permalinkの威力 かつてならその数の暴力に抗う手段はなかった。 にぽたん休憩所 そして、そこで発せられたデタラメ。 ネットではかき消せない、数の暴力。 デタラメを真実ととらえる浅はかな視聴者。 しかし、今はpermalinkがある。TVには今のところそれがない。そしてそれこそがTVの最大の弱点だ。 TVの数は凄い、確かにサンジャポ一回で私は当blogの2年分のビューを稼ぐことが出来る。街頭演説が鉄砲ならblogは機関銃。しかしTVは空爆だ。 しかし、TVは忘れ去られるのも早い。持続性が薄いのだ。この持続性の差というのは、同じTVでも番組によっても異なる。視聴率にして朝生はサンジャポの半分程度だが、blogへの反響はその逆どころではなく朝生が上だ。その朝生も、TBの連鎖による議論の持続度において適わ
「ようやくRed Hat Enterprise Linux 4を基幹システムへ適用可能に」,NECがExpress 5800での拡張サポート開始 NECは1月31日,同社のPCサーバーExpress 5800向けのサポート・サービス「Linux拡張サポートサービス」の対象をRed Hat Enterprise Linux 4(RHEL4)に拡大した。RHEL4は約1年前の2005年2月に米国で発売されたが,NECでは「ようやく基幹システムで適用できる安定性が得られた」としてサポートを開始する。 「Linux拡張サポートサービス」は,24時間対応や,障害時にダンプからの原因調査を行い,対応策を提示するサービス。 NECでは「数十時間から約1週間,数十Gバイトのファイルのコピーを繰り返すなど,長時間高負荷でのテストを行ってきた」。しかし,まれに障害が発生するなどの問題が起きていいたため,基幹シ
切込隊長記事を震源地としてGeek不在ネタがいくつか伝播していったわけなんですけども、個人的に追っていくに、 震央のネタを読んでなるほどそうだよな、とは思いつつも、まるで伊藤氏が富士通の(いや伊藤氏は元富士通ですが)件の職場にいたら問題は解決、みたいな感じにちょっと違和感を感じていたら、小飼弾氏の記事にもやもやがすっきりした感じを受けた。 でもそのすっきり感にちょこっとコメントを残したら、I氏とかH社とか変な書き方をしてしまったせいもあって、なんか「伊藤氏にそんな力量なんかねーんだよ」みたいな意味合いにとられちゃうんじゃないかなあ、そういう意図でもないんだけどなあ、というまたもやもやした感じになってたんだけど、これを見てしっくりきた。まさにその通り。 伊藤さんが力量どうのというより、そんなところに一人いたからといって、土壌がそうだとどうにもならんのだよな。 俺は別に伊藤さんと違ってG
NECは11月18日、サーバ1000台クラスの大規模クラスターの障害を高速かつ低コストに回復する技術を開発したと発表した。 プロセスの高速復元方式と障害を短時間に発見する方式を開発し、Linuxによる同規模のクラスターの障害1回当たりの停止時間を10秒未満に短縮する。電子政府やショッピングモールなど、生活インフラの信頼性を向上できるとしている。 開発した「高速リカバリ技術」では、プロセスリプリケーション方式を改良し、メモリ使用量を1/3~1/10に削減。プロセスの複製を置くために必要なコンピュータの数を減らせる上、復旧は数秒で行えるようにした。クラスター監視方式も改良し、1台の監視サーバで数秒以内の障害発見が可能になった。 研究成果は、18日まで都内で開かれた研究の委託元である新エネルギー・産業技術総合開発機構(NEDO)の展示会で披露した。またクラスター監視方式を12月7~9日の「C&C
昨日のエントリーで証券取引のシステムダウンのコストは1時間当たり10億円と記憶を頼りに書きました。ソースを探してたんですがどうやら捨ててしまったようで、ネットで新たにサーチしたところ、こんなデータが見つかりました。なんと、UCバークレーのあのパターソン先生がシステムのダウンタイムコストについて論じた論文です。 ダウンタイムコストの事例データはパターソン先生の調査結果ではなくInternet Weekから持ってきたようですが、証券会社のオペレーションのダウン1時間あたりのコストは、645万ドルとなっています。まあ、10億円としても当たらずと言えども遠からずですね。 こういうシステムダウンのコストを算定する場合には、ダウン時間の売り上げがゼロになるという仮定の元に計算するのが普通です(実際には、顧客はシステムの回復を待って注文することもあるので、ダウン中の売り上げがすべてゼロになるわけではない
東京証券取引所で11月1日午前、システム障害が起き、全銘柄の株式売買ができなくなった。東証によると障害の原因は、売買注文を受け付ける富士通製システムのプログラムミスだった。 証券会社などから売買注文を受け付けるシステムで朝から障害が発生。東証1部、2部、マザーズ上場株式と、不動産投資信託(REIT)、転換社債型新株予約権付社債(CB)など全2520銘柄について、午前9時からの立会取引を一時停止。午後1時30分に復旧・再開した(関連記事参照)。 東証で株式の全銘柄が取引停止になったのは初。 東証のシステムを利用している福岡証券取引所と札幌証券取引所でも一時、株式とCBの立会取引を停止した。 東証は10月8~10日の連休中に、注文処理能力を1日当たり620万件から750万件に増やすシステム増強を行った。その際新たに導入したソフトが、毎月末に自動で行われるデータ整理にうまく対応できなかったことが
2005年11月02日13:23 カテゴリMoneySciTech たかが750万注文 ああ久々の昼酒が。しらふでないので手身近に。 信州さむっ-マルセルさんのコメント プロのご意見として信州から東証のシステム障害についてひとつ何のプロなのかが今イチ不明なのだけど、とりあえず電網土方としての一般論から導出される感想を。 一日750万注文というと、膨大な数字に思える。たしかにこれだけの数の注文を人手や紙で裁いたら大変だろう。 しかし、やりとりするデータ量を考えると、また別の意見も出てくる。まず一注文に必要なデータだが、64bitで余裕で収まる。以下、実装例 FieldBitsComment 証券会社コード101024社まで 銘柄124096銘柄まで 売買フラグ1 単価9512ノッチまで 単位数3242億単位まで 実際はもっと冗長性の高いデータ構造を使っているだろうが、必要なのはこんなところだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く