前明石市長が「壊れてないが保証期間が切れたので交換したい」に対して「止まったら修理すればいい」と返したスタンスは危険に感じる話PRESIDENT Online / プレジデントオンライン @Pre_Online プレジデント社のメディアサイト「PRESIDENT Online」の公式アカウントです。前向きに働くすべての人に、明日使える話題の経済や政治、社会のニュースをお届けします。 【Podcast 音声版】podcastranking.jp/1525273315 president.jp
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
本番サーバー60台のホスト名を全部 cat にしてしまった話 - Qiita
この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の4日目です。年末進行、いかがお過ごしでしょうか？みなさま無事に仕事が納まることを願っております… 新人インフラエンジニアが、本番ウェブサーバー60台のホスト名を全部 cat にしてしまった話について、ここに供養させていただきたいと思います 背景 おそらく今から7年くらい前、インフラエンジニアとして転職してきて1年ほどが経ち、本番環境での作業もこなれてきたなというバッチリのタイミングで事を起こしてしまいました。サーバーは CentOS 6 だったと思います。 職場としてはまだまだベンチャー感にあふれ大きな裁量が与えられスピード感のある環境ながら、サービスの登録ユーザー数は1,000万を超え、本番環境の規模としては既になかなかの大きさがあり、ウェブサーバーだけでも60台くらいあったと思います。ひと山につき
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
こないだたまたま入ったラーメン屋のシステム
席ごとにQRコードの書いた紙が置いてある ↓ QRコードを読み取りスマホで注文 ↓ 食べ終わったらその紙を持って精算機へ ↓ QRコードを読み込ませて支払い 精算機の代わりに食券販売機置けばよくない…？ いまいちシステムの利点がわからん 追記 ・券売機は初期費用がかかるしスペースを取る 精算機も初期費用がかかるやろがい！大きさもATMくらいあったぞ。現金も中に入っとるぞ そのままスマホ決済ならわかるけど精算機挟むのが中途半端に思う ・食券の紙資源 席に置いてあるQRコードは使い捨ての紙やったんやが。補充も地味にめんどくないか ・座席と紐づいた注文が直接厨房にとぶのでオペレーション短縮 それはたしかに ・
医療事故調査制度についてチーム医療：ダブルチェックの有効性を再考する（pdf）
ダブルチェックの有効性を再考する 京都大学医学部附属病院 医療安全管理部部長 松村由美 平成30年度医療安全セミナー 主催：厚生労働省四国厚生支局 サンポートホール高松 平成30年12月7日（金）13時00分 ダブルチェックとは？ 説明してみよう！ 2 誤薬の防止 各業務プロセスの中でのダブル チェックなど，・・・が重要である 日本看護協会 医療安全推進のための標準テキスト 論理・文脈チェック 表層チェック 3 各業務プロセス：薬剤の場合 処方 調剤 与薬 時間差 ダブルチェック 同時 ダブルチェック ダブルチェックなし または 研修医，指導医など または カンファレンス（論理・文脈チェックに向く） 業務として定めていない 処方鑑査業務 4 看護師は，同時ダブルチェックが多い ～注射薬のダブルチェックを例に～ • 方法は様々・・・ 指示簿とラベルと薬剤を二 人で一緒に同じものをみて います
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc
はじめに 当記事を開いてくださりありがとうございます。私は表題の通り、私は一般にメガベンチャーと呼ばれる自社開発企業で機械学習エンジニアとして勤務しはじめてからわずか半年で、鬱を発症し退職することになったものです。この会社は待遇も良く、社風としても労働者思いのとても素晴らしい会社であったと私自身振り返って思います。 そんな会社に運よく入社することができた私ですが、わずか半年で「鬱状態」と心療内科から診断を受け休職し、会社制度により退職することになりました。「え？そんなに素晴らしい環境なのにメンタル弱すぎでは？」と思われる方もいらっしゃることでしょう。返す言葉が全くありません。おっしゃる通りです。 しかし同時に、「何故鬱になったの？」と思われる方もいらっしゃるのではないでしょうか。本記事ではこの点について鬱を発症した本人の目線から「どうしてそんなことが起きてしまったのか」という点について考察
人生を仕組み化していったら結婚できた件 - Amosapientiam
この記事は妻にレビューしてもらっています。 概要 この春結婚しました。 我々二人の生活は、多くの仕組み化・組織化を実行しているという点でかなり変である、ユニークだと思います。この記事では我々が導入している仕組み化を紹介していきたいと思います。 経緯 妻とは一年ほど前から人生をよりよく生きるためのアドバイスをし合う朋友・盟友的関係を築いていました。 お互いの人生には課題が山積しており、それを抜本的に改善する必要があったのです。 そのために我々は仕組みの力に頼ろうと、さまざまな人生の仕組み化を図りました。 改革は功を奏し、我々の抱えていた諸問題は対処可能になっていきました。 また、お互いの課題解決的なコミュニケーションが大いに促進され、相互理解が深まっていきました。 我々の協力関係が実り多いものであることを深く確信した我々は、お互いの人生に貢献したい、二人三脚でこの人生を楽しんでいきたい、一緒
プログラマーを解雇して新しい人員に置き換えることがソフトウェアにとって致命的になり得るという指摘
IT業界は人材の入れ替わりが激しいことが知られており、有能な開発者は好待遇を求めてさまざまなチームを渡り歩いているほか、企業側も不景気時には積極的に人員整理を行います。ところが、ソフトウェア開発チームの運営に関する複数の著書を持つBaldur Bjarnason氏は、「プログラマーを解雇して新しい人員に置き換えることは、ソフトウェアにとって致命的になり得る」と主張しています。 Theory-building and why employee churn is lethal to software companies – Baldur Bjarnason https://www.baldurbjarnason.com/2022/theory-building/ Bjarnason氏はソフトウェアのプログラマーを庭師にたとえた上で、「ソフトウェアは一時的な庭であり、その運命は庭師と密接に関わっ
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
間違いだらけの24時間換気システム設計～個室が寒い 窓を開けると2Fが換気されない・・ | 創造の館マイホーム
「換気口の風が寒い」「寝るとき寝室が冷え切っている」「キッチンのゴミ臭が充満」３種換気は単純でコストが安くできることから広く施工されている。しかし設計難易度は一番高い。施工後の調整が不可欠だが、大抵の建築業者は風量測定もせず「完成しました」といって引き渡してしまう。 設計のポイント 新築の換気設計はファンを作るメーカーに丸投げすることが多い。我が家の場合MAXが担当したが、出てきた計画がダメだったので自分でやることにした。自分で設計してみて気づいた24時間換気システムの設計のポイントと注意点をまとめてみた。 １種と３種のメリット・デメリット 住宅では１種（強制吸気＋強制排気）または３種（自然吸気＋強制排気）で計画される。それぞれのメリット・デメリットは次ようになる。 １種のメリット ・設計通りの換気が実現できる。 ・建物の気密が怪しくても問題なく機能する（屋外と室内に気圧差を生じないため）
はてなのサーバー監視サービス「Mackerel」が日本企業で初めてAWS Graviton Ready の認定を取得 - プレスリリース - 株式会社はてな
株式会社はてな（代表取締役社長：栗栖義臣／本社所在地：京都市中京区）は、当社が提供するサーバー監視サービス「Mackerel」が、アマゾン ウェブ サービス（以下「AWS」）のパートナー制度「AWS Graviton Ready」に認定されたことをお知らせします。 日本企業のサービスが「AWS Graviton Ready」の認定を受けるのは、当社の「Mackerel」と、このたび同時認定されたビジョナル株式会社の脆弱性管理クラウド「yamory」の2社が初めての事例となります。 ▽「AWS Graviton Ready」について https://aws.amazon.com/jp/ec2/graviton/partners/ 「AWS Graviton Ready」は、AWSのプロセッサである「AWS Graviton プロセッサ（※1）」ベースのインスタンスの採用を容易にし、「AWS
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
(GPT補完) 下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/524aefbbe8f601d7a9248f00b4ca010578396064/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wODBjMWQxOWYwOTg5NDI4YzZiMWRmYWE2YmNmMzI1OA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc3lhbnRpZW4mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTQ5NDc0M2ZjOWU5MDg1NWM3YzExNjg3ZjA1ZDIwMjRl%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D3c956ec09e55703533b9a2487bd3c5f6)
ソフトウェアを完成させる - blog.8-p.info
Why is building the Ruby environment hard? の、 ソフトウェアは何もしないと壊れる というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。 Go の logrus の README には、こんな段落がある。 Logrus is in maintenance-mode. We will not be introducing new features. It’s simply too hard to do in a way that won’t break many people’s projects, which is the last thing you want fro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
暗証番号を設定不要なマイナンバーカードと2026年の新カード【鈴木淳也のPay Attention】
テスト自動化から、 開発を支える継続的テストへ
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ～プリコネ！グランドマスターズ開発事例～
窓ガラスの結露を確実に防ぐ～冬場の結露対策 | 創造の館マイホーム
エアコンのカビを防ぐ～１０年間やってみた対策と検証結果 | 創造の館マイホーム
「SoftEther VPN」で知られる登大遊氏が「Win32 Disk Imager」の改良版をリリース／「素人システム管理者」をボコボコに批判する長大なREADME付き【やじうまの杜】
