マンガ災害事例
安全管理や労働災害防止は、難しくはありません。 過去の実例や経験を上手に活用すれば、かなりの程度、達成できます。 先人の犠牲は貴重な教訓です。 その一端を、順次ご紹介して参ります。 社会保険労務士・行政書士 横山事務所 所長 横山 誠 〒 ２６２－００３３ 千葉県千葉市花見川区幕張本郷２－５－１－２０７ 電話 ０４３－２７２－３９１７ ファックス ０４３－２７２－３９１８ 業務内容 主に、職場の安全管理、労働災害防止に取り組んでいます。 実際に発生した災害を４こまマンガで表し、その状況、原因、防止対策を検討して、安全診断、教育、講演等の材料にしています。 紙芝居風（パワーポイントも可能）の講演は、ユニークな手法として好評を頂いております。
主要データベースの増え続けるdisk容量の対応事例
こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能
バッドデザイン賞を勝手にノミネートしてみた-2017年度版-｜おり
忙しい年の瀬ですが、皆さま如何お過ごしでしょうか。 さて、皆さんは「グッドデザイン賞はあるのにバッドデザイン賞が無いのはおかしい」という風に思ったことはありませんか？ 私は職業柄、日常生活で見かけた良いデザイン事例と悪いデザイン事例を写真に撮ってストックしているのですが、その中には「本当にこれギャグじゃないの？」というレベルのバッドデザインがあったりするんですよね。 良いものを良いと評価することも大切ですが、良くないものを無視するのは人類の進歩に大きな影を落としているような気さえします。ということで、勝手にアワード化してしまいました。2017と付いてますが、私が見つけたのが2017年だったというだけで製造年度などとの相関性はなく、特に意味はないです。あくまでジョークコンテンツとしてお楽しみください。 【追記】Twitterの方で一部画像が自分で撮影したものではないのでは？とご指摘頂きました
設計者に86億円の損害賠償請求
日経BP社は3月6日、書籍「設計不具合の防ぎ方 増補改訂版」を発行しました。発注者が自ら明かした、実際に起こった200の不具合事例をまとめた類例のないマニュアルです。 増補改訂版では、日経コンストラクションに掲載したトラブル事例を新たに追加しています。 この短期連載では、本書の内容の一部を紹介。最後となる第5回は、本書に転載した日経コンストラクション2016年6月13日号の記事を抜粋して掲載します。 設計ミスが原因で工法の大幅な変更を余儀なくされたとして、大阪府が日本シビックコンサルタントに約7億5000万円の損害賠償を求めた裁判が、異例の展開をたどっている。2016年2月末、府が請求額を約86億円に増額したのだ。 「設計に瑕疵はなかった」と主張してきた日本シビックは、「いたずらに裁判を長引かせるだけの理不尽極まりない行為だ」と猛反発。親会社の日本工営も、「引き続き法的責任がないことを主張
無償で仕事をしてはいけないという論理 - 103
優秀な人間が安い賃金で働くと相場が下がって周りの人が困る、みたいなことは以前からよく言われる。 「高い技術には高い報酬を要求しましょう」という意味だと考えれば真っ当な話ではあるし、技術力は高いが無知でもある人が損をしないようにと与える助言としては有効かもしれないが、それによく似た別の話なのではないか、と思った事例があったのでメモしておく。 比較的最近公開された以下の記事に対して、 cybozushiki.cybozu.co.jp 以下のようなブックマークコメントがついて、 インタビューを受けた西尾さん自身や徳丸さんから以下のような回答もあったのだけど。 この記事に関する質問・コメントに回答します。コメント「他の方が困るので仕事の報酬はきっちりもらえ」回答「お金を第一の目的にしないことを強調した結果こういう文章になったけど、意外と貰ってます。インタビュワーに金額言ってないだけ」https:/
ドイツの受託開発会社を退職しました - WETな備忘録
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3
はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定
React / Flux を実案件で使ってみた
自己紹介 Name : Takuto Wada github : twada twitter : t_wada hatena : t-wada TDD とライオンの人 power-assert の人 React / Flux を知ったきっかけ mizchi さんのエントリ (あなたがReactを使うべき理由) だったと思う 日本語の情報はほとんど無かったが、エッジ系の人たちが騒ぎ出した & 海外で圧倒的に事例が増え出したので興味を持った Rendr の AirBnb が React を使い始めたことを知り、これは決定的だと思った React をどう勉強したか 公式ドキュメントとチュートリアルが充実している まず Tutorial をそのまま写経 次に browserify + reactify で Tutorial をもう一周やってみる (showdownはbrowserify 対応してい
「素人まがいのシステム開発」を見分ける方法
自分のプロダクトだっていう意識が皆無なのかテストしないやつ多いよね 最近転職したんだけど、テストしてもリリース後にバグが見つかるからテストは意味がないとかぬかすし 新卒から数年のクソガキが、なぜかプログラマを単純作業労働者かと何か勘違いして下に見ているし テストをしないプランナーとかディレクター プログラマーが単純労働者だったとしてもテストは必要。 単純労働ってことは、工業製品なんですよ。で、工業製品はテストと称する品質チェックをしてますけどね。 素人まがいなところで、単純労働者扱いされて働くのは、正直メンタル的にかなりつらいと思う。マトモなプログラマーほどそう。 給料がそこそこあっても、そういうところで働くは、ストレスがたまると思う。 一度もプロ的な仕事をしたことがない人たちは、そういうのは全然気にならないから、平気。 ということで、素人まがいの人たちが、量産されていく。 素人まがいな開
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「システム構築に潜むヒヤリハット事例」なる教育ビデオ