「システム運用アンチパターン」を一読したので、その要点（特に薦めたい感想5点） - Qiita
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章 せっかくのインシデントを無駄にする 10章 情報のため込み：ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ
新人さんにすすめる有益な技術書達 2022春 - Qiita
はじめに 以下おすすめする技術書達です。分類に迷うものありつつ、流行り廃りあるかもなので2022春と書きました。 技術書達 基本 プログラムはなぜ動くのか プログラムはなぜ動くのか 第3版 知っておきたいプログラミングの基礎知識 | 矢沢 久雄 |本 | 通販 | Amazon 2000年代から推されている基本情報技術者レベルの本 イラスト図解式 この一冊で全部わかるWeb技術の基本 イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon Webの全体像から、HTTPでやりとりする仕組み、さまざまなデータ形式、Webアプリケーションの開発、セキュリティ、システムの構築・運用まで、これからWebにかかわる人が知っておきたい知識をこの一冊で丸ごと解説! リーダブルコード リーダブルコード ―
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
エンジニアはどこまで勉強すればよいのか - スキルマップと生存戦略を考えた - Qiita
最近自分の周りで「スキルマップ」というものを作ったり 新卒の子にどこまで勉強すれば良いですかね？と聞かれた件 ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 というような記事を見つけたりしたので、考えたことを視覚化してまとめてみた。 スキルマップとは 人のスペックを表現する箱がこのようにあったとして 図1. 箱 便宜上Frontend, Backendとかいう方向性があるとします。 図2. 分野、方向性 図3. 1年目- 例えば「バックエンドを1年位経験しました」。 図4. もっとやってる1年目- 例えば「『フルスタック』で1年位経験しました」。 図5. のらりくらりと5、6年- 例えば「バックエンドだけ5, 6年やっていました」。 などと表現されるとする。 実際は 濃淡があると思う。 図6. バックエンドの便利屋、3年選手- こんなだったり 図7. 学生の時から個人開発含め
GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい - Qiita
伝えたいことは全てタイトルに書いた。 動機 https://github.com/topics/awesome を眺めていて本当にawesomeなものばかりだった (割にあまりどこにもそのawesomeさが書かれていないように見えた) ので書く。 awesomeリストとは GitHub で使われる慣習的なリポジトリについてまとめてみた#awesome より: 「特定テーマに関するキュレーションを行うリポジトリ。Markdown のリスト表記で一覧化するのが一般的。また、Contribution も受け付けている（人気のあるリポジトリはガイドラインも厳しめ）。」 Where? ここのことです: https://awesome.re/ 画像はリポジトリから引用。 What? What is an awesome list? よりDeepL翻訳 awesome マニフェスト もしあなたのリストを
開発者が考える提案書テンプレート markdown版 - Qiita
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」 - Qiita
Why doesn’t Japan excel in software as they did in hardware? (なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？) という英語Quoraのやり取り、分析が興味深かったので、まとめ。 仮説1: 日本は完璧を求める 10人のエンジニアのソフトウェア開発会社を経営しているフランス人の友人が、ルイ・ヴィトン日本支社のコンピュータシステムのマネージャーと同意した話：ソフトウェアはハードウェアではなく、産業用でもない。50年間同じトヨタカローラのように構築され、洗練され、完成されたものではありません。ゼロバグでそれを「完璧」にすることは不可能であり、したがって、「ゼロデフォルト」という、総合的な品質、継続的な改善を求める日本人の精神に反するものです。 日本は職人の国であり、漢字を書いたり、折り紙を折ったりする技術を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
