全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表
全国銀行資金決済ネットワーク（全銀ネット）とNTTデータは12月1日、10月10日〜11日に発生した全銀システムの大規模障害の真の原因を明らかにした。 全銀システムは、日常の振込や送金をリアルタイムで処理するシステムで、国内のほぼすべての預金取扱金融機関が利用している。10月のシステム障害では三菱UFJ銀行、りそな銀行など10行で、他行宛の振り込みができないなどの障害が丸2日間継続した。 障害は、全銀システムの中継コンピューターを新機種「RC23シリーズ」へ交換し、その後営業運用を開始した直後に発生した。RC23シリーズ内の「銀行間手数料を処理するためのインデックステーブル」が破損しており、同テーブルを参照する際の処理でエラーが生じたためだ。 中継コンピューターは東京と大阪に1台ずつ、冗長化として設置されていたが、2台同時に新機種のRC23シリーズに切り替えたため、2台ともにソフトウェア障
「2回ボタン押したら水が…」音楽フェスの準備中に男性スタッフ死亡 時速120キロの水が誤射で“直撃”【news23】（TBS NEWS DIG Powered by JNN） - Yahoo!ニュース
14日、大阪市の音楽イベント会場で男性スタッフに倒れているのが見つかり、死亡が確認されました。当時、リハーサル中で演出で使う水が、男性に直撃したとみられています。 【写真を見る】「2回ボタン押したら水が…」音楽フェスの準備中に男性スタッフ死亡 時速120キロの水が誤射で“直撃”【news23】 ■時速120kmの水“直撃” 音楽イベントのスタッフ死亡 7月14日午前11時すぎ、大阪市のイベント会場で水を高速で拭き上げるウォーターキャノンという装置が誤作動し、スタッフの八代達司さん（40）が死亡しました。発射した水が八代さんの頭に直撃したとみられています。 会場では、7月15日と16日に開催予定だった「ウォーターボム」という韓国人アーティストらによる音楽イベントのリハーサルが行われていました。八代さんが、40台あるウォーターキャノンの操作装置を確認していたところ、一部の装置から水が高速で発射
1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」（※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→）
門脇 敦司/ Atsushi @at_sushi_ Knowledge Sense, Inc. CEO ← 東大 / エンタープライズ向け生成AIプロダクトで成長中のスタートアップ（2019年~） / ソフトウェアエンジニアを募集中（800万円~+SO）→DM開放中 / 好きな言葉は「実験と学習」/ 最新の生成AI 事情に少し詳しいです https://t.co/PwBZaT31cB 門脇 敦司/ Atsushi @at_sushi_ 1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」 （※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→） twitter.com/jasoncwarner/s… 2022-11-16 09:20:18 Jason Warner @jasoncwarner I'm convinced that o
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
「バグを意図的にバグのまま残す」という選択肢がある
はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。本記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++
「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基本的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか？ ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。
Go言語が好きな理由
はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 （元ネタ）Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰？ 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味でGoに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関
【PHP8.1】PHPで簡単に非同期処理を書けるようになる - Qiita
PHPは長きにわたり同期的、すなわち、あらゆる処理を上から順に実行していくというスタイルを取ってきました。 しかしたとえば、複数のURLからデータを取ってきて結果をまとめたいといった場合、時間のかかるHTTPリクエストは同時に投げたいですよね。 この用途にはGuzzleというライブラリが存在し、これを使えば同時にリクエストを投げられます。 しかし、ではHTTPアクセスとDBアクセスを同時にやりたい場合は？ 時間のかかる計算を裏でやりたい場合は？ などと考え始めると、こういった個別のライブラリでは対処しきれません。 ということで汎用的な非同期処理をPHPで書けるようにするRFCが提出されました。 PHP RFC: Fibers Introduction 人類史上ほぼ全ての期間において、人々はPHPを同期的なコードとしてのみ書いてきました。 同期的に実行されるコードのみが存在し、そしてそれを同
AWS構成図おすすめツール - Qiita
AWSの構成図を作成する際に便利なツールを紹介します。 vscodeの拡張プラグイン「Draw.io Integration」です。 インストール方法 vscodeの左サイドにあるExtensionsをクリックし、検索窓にdrawと入力するとDraw.io Integrationが表示される。そして、Installボタンをクリックするとインストールされる。 作画ツールの表示 インストール後に新規ファイル作成ボタンを押し、 拡張子を.drawioにすると自動的にvscode上でdrawioの作画ツールが表示される。 これを使って簡単なAWSの構成図を描いていきます。 VPCを作成して、その中にパブリックサブネット、EC2インスタンス、インターネットゲートウェイを作成する。 使い方 AWSアイコンの追加 下部の+More Shapesを押すと、アイコンのセットが表示される。 ここからAWS 1
React Server Componentsに感じたフロントエンドの消失
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
Rubyと型についてのポエム - まめめも
zenn.dev matz はじめコミッターの型に対する姿勢にも疑問を持っています。 というご意見が自分に刺さった気がしたので、他の話題はともかくこの点に関してだけ、ポエムを書きます。 「Rubyに型が欲しい」というのは、「もっと速い馬が欲しい」だと思っています。意味を知らない人は ヘンリー・フォード もっと速い馬が欲しい で検索してください。 これは批判でも皮肉でもありません。みんなが馬の乗り方を知っている世界では、誰も乗り方を知らない自動車より、速い馬のほうが確実で合理的です。まして、自動車が本当に実現できるかどうかわからない段階では。なので、他言語で型注釈を書くことによるプログラミング体験が良いと思った人が、それをRubyでも享受したいと思うのは自然だと思います。実際、Steep や Sorbet は Ruby でそういうプログラミング体験を提供することを目指していて、すでにある程度
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
プログラミング初心者は変数名やメソッド名を略さない方がいいよ、という話 - give IT a try
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所
以前、Twitterで呟いたもので反響が大きかった内容がありました。今回はその呟きに対すると皆様の回答について整理・考察していきたいと思います。 新人くんの設計事例 下記が私がTwitterで呟いた内容です。 【新人君の設計事例】 新人君が出してきた設計案。これは"やってはいけない締結"だよと色々説明したが、あまり納得してもらえず。上司も"部品強そうだし、問題ないでしょ"と一言。 個人的な感覚では、"絶対にダメな奴"なんだけど上手く納得させる説明ができなかった。皆さんならどう説明しますか？ pic.twitter.com/FYMZOu9dqx — しぶちょー (@sibucho_labo) September 5, 2020 ある日、新人君がこのような設計を提案してきました。ボルトの下は隙間になっていて、普段あまり見ない形です。詳細な意図は省きますが、他部品との干渉の関係もあり、こういう形
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） - outsider reflex
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 Main 「なぜMozillaはXULアドオンを廃止したのか？」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 » なぜMozillaはXULアドオンを廃止したのか？（翻訳） - Aug 22, 2020 （原著：David Teller, 2020年8月20日、CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。） 要約：Firefoxはかつて、XUL
「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に
「UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている」「キャッシュはアーキテクチャではない。単なる最適化だ」などの語録を生んだ「Goの父」とも呼ばれるロブ・パイク氏の「プログラミング5カ条」について、ネット上で話題となっています users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html Rob Pike's Rules of Programming (1989) | Hacker News https://news.ycombinator.com/item?id=24135189 パイク氏の「プログラミング5カ条」は以下。 ルール1：プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
WindowsがLinuxより優れている点は何ですか？ (OSの設計に関する質問であり、利用者の使い勝手の話ではありません) 。
SEだが正直noteのやらかしを見てほっとしている
