東京証券取引所は、株価の情報を配信するシステムにトラブルが発生しているため、1日終日、すべての銘柄の取り引きを停止すると発表しました。
This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ
ホーム 全記事 ニュース Steamレビューにて、「トピックのずれた不評」を評価から除外するシステム導入へ。低評価爆撃問題にテコ入れ Valveは、Steamにおけるユーザーレビューを再考し、新システムを導入する予定があることを発表した。その内容は、「トピずれの(論点のずれた)レビュー荒らしを特定し、レビュースコアから除外する」というもの。Steamでは、販売されているゲームに対しユーザーがレビューをすることが可能。レビュー内容は、ゲームプレイに関するものからバグに関するもの、ローカライズの有無やゲームの価格、サービスについての賛否まで幅広い。そうしたレビューにおける、論点のずれたレビューをスコアから除外するというのが今回の趣旨だろう。 Valveは以前より「プレイヤーがゲームのレビュースコアを下げる目的で、短期間に大量のレビューを投稿すること」をレビュー荒らしと定義し、問題視してきた。そ
いきなりですが皆さん、システムの保守・運用っていうと、どんなことする仕事なのかってご存知ですか? 勿論、一言で保守とか運用って言っても、対象となるシステムにもよりますし、担当者の守備範囲にも、契約の内容にもよるんで、あまり一概に言える話でもないんです。 ないんですが、それを承知でざくっと言ってしまうと、例えば一般的なwebシステムでいえば、 ・システムの負荷監視、死活監視、パフォーマンス監視 ・トラブル時の調査・問題切り分け・障害対応 ・インフラの故障対応 ・ネットワーク監視 ・バックアップ対応 ・定期メンテナンス ・ジョブ管理 ・マニュアル・ドキュメント管理 ・障害対応訓練 ・バージョン管理・変更管理 ・ログ管理 ・セキュリティパッチ対応 ・瑕疵対応、バグ対応 ・修正開発時の事前調査 この辺については、まあ代表的な保守・運用の仕事と言ってもそんなに問題ないでしょう。正確にいうと、保守と運
AWSのシステム構成情報を集めて構成図を自動生成してくれる「CloudMapper」、オープンソースで公開 CloudMapperを用いることで、AWS上のシステムについて以下のような状況をすぐに把握することができると説明されています。 どのリソースがインターネットに公開されているか? どのリソース同士がつながっているのか? アベイラビリティゾーンが落ちたときでも十分堅牢なアーキテクチャか? このアカウントはいくつのリージョンを利用しているか? どれだけ大きないシステムを運用しているか? CloudMapperを開発しているDUOは、セキュリティサービスを提供する企業。同社は自身もAWSユーザーで、さまざまなオープンソースのツールを試してみたものの満足できるようなものがなかったため、自社でCloudMapperを開発したとのこと。 CloudMapperの仕組みは、まずAWSコマンドライン
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
この記事は下記のURLにあるコミックマーケット90で頒布した同人誌と自分が管理するブログの記事を微修正し、転載したものです。 南関東開発機構 : 同人誌「日本の行政機関が公開中のAPIについて調べてみた本」を公開しました http://blog.livedoor.jp/south_kanto_dm/archives/52143201.html 南関東開発機構 : 日本の行政機関が公開中のAPIについてのまとめ(2016年8月17日暫定版) http://blog.livedoor.jp/south_kanto_dm/archives/52143463.html 前書き この記事の目的は、日本の行政機関等が公開しているAPIを紹介する事です。 日本の情報技術は他国と比較して、立ち遅れている部分があり、これを立て直すのが喫緊の課題であると言えます。 日本政府もこの問題に危機意識を持ち、先日、経
大型のシステム障害の詳細が見えてきた。全日本空輸(ANA)が2016年3月22日に起こした国内線旅客システム「able-D(エーブルディ、以下では便宜上開発コード名のANACore:アナコアと称す)」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース(DB)サーバーが停止したというもの(関連記事:ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン)。今回、弊誌
米サンフランシスコにあるツイッター本社の入り口に掲げられた同社のロゴ(2011年3月11日撮影)。(c)AFP/Kimihiro Hoshino 【1月20日 AFP】マイクロブログのツイッター(Twitter)で19日、世界各地での利用が数時間にわたり不可能となる障害が発生した。10年にわたるツイッターの歴史の中でも最大級の障害となった。 ツイッターはグリニッジ標準時(GMT)の19日午後6時(日本時間20日午前3時)すぎ、公式アカウントへの投稿で、障害からの復旧を発表。原因は「内部のコード変更に関係したもの」だったが、「変更を取り消し、問題は解決された」と説明した。 ネット障害情報サイト「ダウンディテクター(DownDetector)」によると、ユーザーによる障害の報告はGMTの19日午前8時~午後2時(日本時間19日午後5時~11時)に急増し、同日午後4時(日本時間20日午前1時)ま
巨大なシステムやってて一番思うことは、「隣のプログラムが何やっているかすら知ろうとしない技術者が9割」ということです。これは愚痴です。役割分担が細かいのは良いんですが、仕様すらきっちり確認しようとしない。仕様ってのはそれがわかってないと作れないレベルのI/F仕様だったりするんだけど、誰がどこでどうその項目を設定するの?ということについて興味がなさすぎる。リーダークラスの人が知っててその人に聞けばいいや的な。 で、もうちょっと上のところに行くと、今度はI/Fしている隣のシステムの仕様はやっぱり興味ない。もちろん、I/F仕様どおりにデータが来れば問題ないんだけどさ、データのパターンとかそういう話ってざっくりとした仕様くらいは理解した上で、懸念される問題(あっては困るパターンとかが実際に発生しないかとか)をやり取りするのがシステム屋の仕事だと思うんだよね。 んで、そういうのを寄せ集めて作った巨大
日本アニメ初の快挙!海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤:たった一つのプロセスが故障しただけでも有限時間で合意できない 正:たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
As I hear stories about teams using a microservices architecture, I've noticed a common pattern. Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. This pattern has led many of my colleagues to argue
システムの時代と日本人 「システム工学の7人の侍」(The Seven Samurai of Systems Engineer-ing)ということを言い出した人がいる。アメリカの著名なシステム工学者であるJames Martin氏である。システム工学に7名のリーダがいるという話かと思ったらそうではなく、システムの七つの見方、あるいは種類を言うそうである(SEC journal 2015年3月号参照)。筆者はこの言葉を聞いて全く別の連想をした。 ご存じのように黒澤明の映画ではそれぞれ個性豊かな7人の侍が見事な連係プレーで野武士を撃退するが、これこそシステムの原型ではないか、と思ったのである。 まず野武士の襲撃から村を守る、という目的が設定される。仕事を請け負ったリーダ格の勘兵衛は、目的を達成するには最低限7人の侍と農民の武装が必要であると考える。これは一種の設計である。7人の侍をリクルートす
クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性(前編)。JaSST'15 Tokyo ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。 そこで行われたセッションの1つ「Web.JaSST ~ウェブ開発のテスト~」」では、ミクシィ、ネクスト、クックパッド、グリーの品質管理(QA:Quality Assuarance)マネージャが登壇し、Web開発やモバイル開発分野の品質やテストにおいて、これまで乗り越えてきた課題、現状、そしてこれからの可能性について語りました。 本記事ではその内容をダイジェストで紹介します。 中野氏(モデレータ) 今日のパネリストの方々は現場でテストをリードしている方々です。その現場で取り組んでいる内容や品質管理について
「我が国が誇るSIer業界が馬鹿にされている記事がけしからん」というので見物にいきました。執筆されていたのは日経BPの木村岳史さん。 SI亡国論(その2)- 日本企業のイノベーションを20年遅れにした罪 http://itpro.nikkeibp.co.jp/atcl/column/14/542472/121100010/ お、おう…。 もっとも、これというのは日本企業の側が業務効率化のための情報投資に対して、きちんとした仕様を組み上げられなかったり、システムの妥当性を評価できなくてSIerに丸投げした結果も結構あるんじゃないかと思い、そうであるにもかかわらず日経こんぴうたのこんな記事でSIerは酷評されつつも現場は日々のデスマーチで命を削っておられるのだなあと考えると冷え込みの厳しい夜長に暖かい火が心に灯るのであります。 まさにこのあたりの話を聞きながらシヴィライゼーションとかやりますと
よんてんごP @yontengoP ・「何もしてないと私は思っていますが壊れました」 ・「壊れたのですからきっと私が知らないだけで何かをしたのでしょう」 ・「何かをしましたが何をしたかは分かりません」 ・「そもそも壊れることと何かをしたことの間に因果関係はあるのでしょうか」 同僚「全てムカつくわ」 よんてんごP @yontengoP 「使い続けていたら壊れました」 同僚「まだ納得がいく」 「何も知らずに使い続けていたら壊れました」 同僚「説明書読んで、どうぞ」 「何かを知ろうとした結果、壊れました」 同僚「何だろう、宗教感ある」 「そもそも壊れるとは何でしょうか」 同僚「壊れてるのはお前の発言だよ」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く