サーバー側はＲＥＳＴでＤＢ操作だけとなると、ツール化できてしまうんだよね！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） で、昨日の問題。 ソフト開発は、必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数なので、 ・画面開発者の単価を減らし ・画面と操作部分を完璧に分離し、操作部分をバッチに落とし込めば 価格は安くなることになる。 このとき サーバー クライアント ・ＧＥＴまたはＰＯＳＴで引数を受け取り セッションの引数とあわせて（共通関数で） ・画面操作、処理をflashで行い ・ＤＢ操作処理 ←→ ・サーバーをflashから呼び出し、 ・結果をセッションに入れたり ・受け取ったＸＭＬをもとに ＸＭＬで返す（共通関数にセット） 画面表示させる とすると、クライアント側はＦｌａｓｈ処理のみとな
「ヨドバシ・ドット・コム」がリニューアル直後から表示が遅すぎて激重になる大規模障害が発生、一体何が起きているのか？
ヨドバシカメラの公式サイト「ヨドバシ・ドット・コム」が2008年10月21日（火）にリニューアルされました。個人的な感覚では「使いにくく、見にくく、お目当ての商品が探しにくく」なって改悪されたように感じられていたわけですが、それどころかあまりにも表示が遅すぎて激重になり、なんとお詫びページまで作られるほどになってしまいました。 そして既にリニューアルから1週間が経過したものの、いまだに改善されておらず、一体何がどうなっているのかよくわからない状態で、どれぐらいの損失が発生したのかが非常に気になります。何が起きているのでしょうか？ 戦慄の実態は以下から。 まず発端は10月21日（火）。リニューアル直後から重くなり始め、ついにはタイムアウトを連発。たまたまこの日は前日にヨドバシ・ドット・コムから「ポイント残高失効のお知らせ」が届いていたため、ポイントでLANケーブルを買おうと思っていたのですが
SEが声を大きくして国民に伝えるべきたった一つのこと。 - 304 Not Modified
それは、コンピュータは必ず壊れるということ。 先日拝聴した香取貴信氏の講演で聞いたことから、ずっと頭に残っている言葉がある。それは、「ディズニーランドのアトラクションが機械の故障で動かなくなってしまった場合、アメリカ人はリアクション大きく悔しがるが案外あっさり諦めてくれる。しかし、日本人は決して納得してくれない」といった感じのこと。 これを聞いたとき、私はとっても頷いた。アメリカ人についてはどうか知らないが、日本人にいたっては－少なくとも私の思う限りでは－まだコンピュータ完ぺき主義が残っていると思う。コンピュータはちゃんと動いて当たり前なんて思っている人を、まだまだ見かける。 こう思ってしまうのもきっと、かつて「安全と水はただで手に入る」と言われた国だからなんだと思う。マスコミの情報を鵜呑みにしがちな面もそうで、“そこに在るものは正しい”って思っちゃうんだと思う。でも、そんなことは絶対にな
ユーザビリティ | 秋元@サイボウズラボ・プログラマー・ブログ
Eric Burkeさんのブログ Staff That Happens(閉鎖)より、単純さ(Simplicity)とは、 Apple や Google と、「あなたの会社の製品」では、カバーする内容が違っているというのもあるだろうけれど、ユーザーが選べる箇所を減らすためにはどうするか、という視点を持つことについて示唆に富む比較かもしれないと思った。 [更新 2015-09-11 リンク先閉鎖確認にあわせて修正] この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません
「オーバースペック」でコストが下がる話 - 設計者の発言
「革新的生産スケジューリング入門」や「ＢＯＭ入門」といった、生産管理に関する優れた著作を書かれた佐藤知一さんと神戸でおしゃべりしてきた。さすが「工場そのものの開発」に携わってきた佐藤さんだけあって、面白い話をいろいろと聞かせていただいた。それらの中から、設計者のまっとうなコスト感覚が建設現場での障害をもたらすという話を紹介したい。 佐藤さんが本業で扱う化学プラントにおいて、いちばん目に付く部品は「パイプ」である。素人には想像を絶するが、その種類はじつに４千点にものぼるのだそうだ。口径や長さはもとより、壁面の厚さや付随するバルブの仕様だのなんだのが順列組み合わせ的に関係するためだ。 で、プラントの設計者は、要求性能にぴったり沿うパイプを用いて各モジュールを設計する。たとえば１００の強度を要求する部分には１００の強度を保障するパイプを組み込む。あたりまえの話だ。そんなところに２００の強度を保障
東葛人的視点 日経BP社
« またも東証のトラブル、改めて考 | メイン | プロジェクト・マネジメント「格 » 作る「バカ」と使う「バカ」が共振した東証のシステムトラブル ［2005年12月22日］ あるメーカーの幹部に言わせると、「バカよけのロジックがなかった」ということになる。もちろん、みずほ証券による誤発注騒動の件である。東京証券取引所の売買システムに、重大なヒューマン・エラーが起る可能性を想定した要件定義が盛り込まれていなかったのか、システム開発サイドの人間から言うと不思議でならない----その人はそう話を続けた。「バカよけ」とは言葉は悪いが、多くの技術者が同様の思いを持ったことは事実だろう。 確かに、情報システムはエラー処理ロジックの塊である。今回のような通常あり得ないような入力ミスも含め、あらゆる事態を想定して要件を定義し、それに対処するエラー処理のロジックを書かなければならない。通常の処理ロジックだ
東証、名証、だけでなく、大証も調べてくれ。テストケースを先に作って。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ジェイコムショックで、東証のシステムの不具合が出たけど、それが、名古屋証券取引所でも起こるというニュースがでている。 ということで、東証、名証（＝名古屋証券取引所）は、再チェックするだろうけど、 たのむ、大証（＝大阪証券取引所）もしてくれ！。 けっこう、頻繁に、売買のレスポンスが特定の銘柄で遅くなるっていう問題があるんだよねー。これって、大証のシステム能力のせいってなってるけど。。。うーん？？ やっぱ、本当に能力のせいかどうか、確認する必要はある気がするけど。 で、こういうチェックの場合、ウィリアムのいたずらは、とりあえず、先にテストケースを使ってチェックしていただきたーい！と思います。 まあ、最近の流れとして、テストファーストといわれていることからも、まずテストケースを先に作っ
今回のジェイコムショック、東証の不具合の再発の可能性と、改善策を考えてみる - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） で、前のブログで、ジェイコムショックの東証における不具合である、 で、こういうケースは、２度とおきないのかというと、その「今後の対応」に書かれているように ・当取引所に直接新規上場する銘柄の場合（＝値幅制限がきめられない）で、 ・かつ、今回のケースのように、特別買気配が表示中に（これは、新規上場では良くある） ・気配の差引数量を超え、初値決定後も売注文が残るほどの大量の注文が ・みなし処理の対象となるような値段で発注されたような場合に発生する でないと起こらない＝逆に言うと、こういうケースなら起こるというのなら。。。 ありえない話ではないんだよねー どういうケースかっていうのは、長くなりすぎたので、また今度かくね。 について、一応書いておきます。 条件を、 （１）当取引所に直接新
ファイル名はなくてもいいかもしれない - モジログ
言語ゲーム - 無名ファイルシステム http://d.hatena.ne.jp/propella/20050822/p2 ＜無名のファイルシステムを考える。無名とは呼んで字の如くファイルに名前がついてない事である。私達はファイルには必ずファイル名がついている物と考えているが、ファイル名には欠点がある。だからファイル名は無いほうが良い。少なくともファイル名が無くとも動作するシステムを設計するべきだという主張＞。 ＜簡単な話ファイルをメモリのように扱うという事だ。ファイルは無名であるべきである＞。 たしかに、そうかもしれない。 わたしたちはもうURLに慣れている。 いまではURLのほとんどは自動的に生成されているが、それで誰も困らない。 とにかく一意的にページやファイルを識別できればよく、自動生成でも構わない。 多くのブログツールではエントリのIDを自動生成するが、それと同じでいい。 ファイ
ネタ投入のタイミングもシステムが指示、RFIDで勝ち残る回転寿司企業
回転寿司業界の競争は熾烈を極める。ロボットで酢飯を握るのはもはや当然。仕入れや客の回転率を極限まで効率化し、利益を出さねばならない。「あきんど」「スシロー」を関東・近畿に展開しているあきんどスシローでは、効率化の手段として1皿ごとの単品管理を追求してきた。同社は、RFIDタグ（無線ICタグ）により、大幅に廃棄率を下げることに成功している。 画像認識による単品管理は失敗に終わる スーパーやコンビニで買い物をすれば、商品のバーコードをレジで読み取るし、ファミリーレストランでは客の注文を専用端末に入力していく。売り手の側では、こうしたデータをPOSですべて把握し、商品の仕入れなどに役立てている。このような商品の管理は今では常識だ。 ところが、回転寿司の店では、お客が何皿食べたかということしか分からない。大まかな人気商品の傾向は分かっても、時間帯、天気等による傾向や変化を正確に読み取ることができな
システム管理者が“暴君”になるとき
パスワードポリシーをやたら強化したがるシステム管理者が現れた。「情報漏えいが起きたら、責任を取れますか？ 」――この言葉に従業員には、反論の余地はない（攻めのシステム運用管理）。 会社規模が大きくなるにつれて、さまざまなパスワードが扱われるようになる。セキュリティに過剰なまでの反応を見せるこのご時世で、パスワードポリシーをやたら強化したがるシステム管理者が現れてもおかしくはない。 模範的なパスワードポリシー 前任のシステム管理者は非常に生真面目な性格であった。曲がったことが大嫌いで、特にパスワードポリシーについては一切妥協を許さない性質の人であった。記号入り英数字6文字以上、2週間ごとのパスワード変更義務、同じパスワードは2度と使えないという、良くいえば模範的、悪くいえば非現実的なポリシーである。 当然、社内からは厳しすぎるという不満の声が上がり始めた。しかし、システム管理者としてのある種
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://lingr.typepad.com/photos/uncategorized/lingrbackendarchitecture20060920.png
