このイベントの登壇資料です 『ミノ駆動さんと語るエンジニア怪談〜技術的負債の呪いにどう立ち向かうのかLT〜』 https://forkwell.connpass.com/event/291332/
![技術的負債の怨霊と除霊方法 / ghosts-of-technical-debt](https://cdn-ak-scissors.b.st-hatena.com/image/square/74d8b4d2f680575876788d7cb50d347304530ec7/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F1b53541fa6804ef187fbaccaba068a2f%2Fslide_0.jpg%3F26789005)
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか? What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
GoogleのDesign Docについて調べました.Design Docとは,Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです. 一般的にDesign Documentというと,設計仕様書のことをさすようです.設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです.一方でGoogleのDesign Docは,あるソフトウエアについて,何を・なぜ・どのように作るかを記したもののようです.両者ともあつかっている対象や,対象としている読者が少しずつ異なっています.このエントリーではGoogleのDesign Docについて扱います. Design Docの内容 Design Docについては,Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています. 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」
http://steps.dodgson.org/?date=20090705より。 Google社員によるWebKitのWeb Socketに関するdesign docがchromeの開発ML上で公開されている事を知った。 WebKit Web Socket design doc http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh 鵜飼さんなど日本人Googlerによるdesign docらしい。 Googleの講演などでdesign docをよく書く文化があると言う事は知っていたが、実際に見るのははじめて。このdocの場合だいたい以下のような構成になっている。 目的 Web Socketでブラウザ=サーバー間双方向通信のための新しいAPIを定義するよー 背景 Ajaxとかでブラウザ=サーバーの双方向通信をよくやっているけど、httpを無理
Twitter DesignTwitter is an online social networking service where users post and read short messages called “tweets”. Most candidates try to design Twitter as a monolithic service in System Design Interview. If you check several existing online resources, they also try to design Twitter as a monolithic service. However, in our opinion, designing a gigantic service like Twitter as a monolithic ser
Diving Deep on S3 ConsistencyApril 20, 2021 • 1938 words I recently posted about Amazon S3 and how it’s evolved over the last 15 years since we launched the service in 2006 as “storage for the internet.” We built S3 because we knew customers wanted to store backups, videos, and images for applications like e-commerce web sites. Our top design priorities at the time were security, elasticity, relia
Note: This is the preface from Beyond the Twelve-Factor App: Exploring the DNA of Highly Scalable, Resilient Cloud Applications, published by O’Reilly. Buzzwords are the result of our need to build a shared language that allows us to communicate about complex topics without having to stop and do a review. Shared terminology isn’t just convenient, it’s essential for decision making, architecture de
2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく,アプリケーションをうまく開発し,うまく運用するための「ベストプラクティス」として知られている.2020年になった現在でもよく引用されていると思う.日本語訳もある. 12factor.net Beyond the Twelve-Factor App とは? クラウド化が進むなど,提唱された2012年と比較すると技術的な変化もあり,今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは?という意見もある.そこで,2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した.The Twelve-Factor App にあった「12項目をアップデート」し,新
Amazonでは製品開発をするとき、まず最初にプレスリリースを書くらしい。これは”Working-Backwards“と言うデザイン手法。面白げなので色々と調べてみた。 Working-Backwards法の商品開発では、お客様の視点をスタート地点にするため、開発前にプレスリリースを作成する。プレス内容は、既存プロダクトの問題点と、それを新製品がどう解決するかが中心になる。 プレスがユーザーに響かなかった時点でプロジェクトはボツ。そもそもその商品は作らない。これにより見当違いな商品を作るリスクを、一番最初の段階で低コストに回避できる。 このWorking-Backwards法で書くプレス内容は主に以下のとおり。 見出し 顧客が商品を理解できるタイトル 副題 ターゲット層と、彼らのメリットを1行で。 概要 商品の特徴と利点をまとめる。この段落で全てを理解できるように。 課題 このプロダクトが
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ.タイトルの通り,コンテナのデザインパターンがまとまっていて,これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値があると思う.一部ミスリードをしているかもしれない. Design patterns for container-based distributed systems 論文も公開されている. https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
Design Systems have reached peak popularity. It seems that every design team has either built one, is building one, or wants to build one. With the release of the incredible Nested Symbols feature followed by Sketch Libraries just a few months ago, Sketch has emerged as an essential part of the Design System workflow. In this talk we will be covering: • Best of breed Design Systems out in the wild
目次 本書の概要エンジニアと企業のミスマッチ良いエンジニアは市場に出ない リファラル採用が一番多い転職ルートの多様化 年収の透明化採用担当者のリテラシー企業の情報発信企業の差別化ポイント 報酬 転職すると年収が上がるバグ就業条件評価と処遇企業内教育の制度キャリアパス迷ったら採用しないという原則エンジニア採用について最近いろいろ考える機会が増えたので読んでみた。 本書の概要本書ではIT分野で人材採用のコンサルタントとして活動している著者が、「エンジニアと企業のミスマッチ」はどうして起こるのか、それをどう解決していったらよいのかを紹介している。 本書前半部分ではイケてない会社やエンジニアの採用失敗例および就職失敗例が紹介されており、後半部分では企業サイドがどうエンジニアを惹きつけ採用に結びつけたらよいかの話が書かれている。 エンジニアと企業のミスマッチ本書では下記のようにエンジニアが特性に応じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く