Spotify’s Failed #SquadGoals
Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you. By Jeremiah Lee Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil) About the cover illustration Of all the allures of startup culture, few are more desireable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify sha
Drop Documents Contents
公開中の内容・構成については、変更されることもあります。現在のDrop 2.0Betaの作成状況を下記のマークで示しています。 .....完成かな？ .....もう少しです .....まだまだ 現在も相変わらず修正中です。 みなさんからのご意見は、以下のDrop Q&A;にてご紹介させていただきます。 はじめに Dropの読み方・使い方 LastUpdate: 3.11 コンセプト編 第１章 Drop構成用語集（オブジェクト指向用語編） LastUpdate: 2.15 第２章 Drop構成用語集（開発プロセス編) LastUpdate: 2.15 第３章 オブジェクト指向開発の考え方（映画撮影のように) LastUpdate: 2.15 第４章 Dropの目指すもの LastUpdate: 3.11 プロジェクトチーム構成編 第５章 プロジェクト構成の問題 LastUpdat
アーキテクチャの意思決定を記録する Lightweight Architecture Decision Records について - Tbpgr Blog
Lightweight Architecture Decision Records とは？ Lightweight Architecture Decision Records とは、 重要なアーキテクチャの意思決定を背景と結果とともに記録する手法 です。 Architecture Decision Records は ADR とも呼びます。 一般にこれらは Wiki や コラボレーションツールに保存されます。 ADRにお役立ち情報 以下のリポジトリに実際に ADR を導入する際の手順などがまとまっています。 github.com と言ってもシンプルなもので、実際にやることといえば テンプレートを決める ファイル名のフォーマットを決める アーキテクチャの意思決定をする 意思決定内容をテンプレートにそって記載してバージョン管理ツールに残す このぐらいです。 ツール ADRのためのコマンドライン
Documenting Architecture Decisions
Context Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins. Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small
History: The Agile Manifesto
On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and
If your product isn’t documented it doesn’t exist
If I asked you to tell me about your product’s documentation right now you would probably find someone else to talk to instead. It’s not exactly the most exciting conversation for most product teams, right? Which is interesting as it’s probably one of the most important. Along with the onboarding process and customer support, documentation is the “transfer layer” of knowledge for your customers. D
組織のなかで働く技術 - やしお
会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
スタイル・ガイド・ジェネレーターについて
僕は以前からJavadocを踏襲した形のスタイル・ガイド・ジェネレーターには構造的な欠点と思想的な欠点を持っていると考えている。実際にはスタイル・ガイドを中心としたウェブ制作体制をよく利用すること、そしてその中での作業を自動化してくれるであろうジェネレーターには期待していること、はあらかじめ断っておきたい。 構造的な欠点は、コメントとして埋め込まれることになるであろうHTML断片が重複しやすいこと、だ。コンポーネントという単位ではまず重複することはないが、コンポーネント間で共有するクラスでは必ず重複することになる。もちろんコメントに埋め込むコードは短いもので、場合によっては軽量マークアップ言語を利用できるため、コストとしては微々たるものだ。しかし単純な繰り返し作業を省力化するための自動化ツール(ジェネレーター)が、そういったまた別の単純な繰り返しを強いるというのはどこかがおかしいと感じる。
tadyjp/readable-code-for-web · GitHub
README.md まえがき この文書は「リーダブルコード」にリスペクトされて書いている、「Web開発者向けのリーダブルコード」です。 以下、「リーダブルコード」と表記した場合は、参考にしている「リーダブルコード」のことを指すこととします。 ある程度まで全体像が見えてうまくいきそうなら、著者の Dustin Boswell氏、Trevor Foucher氏、訳者の角征典氏、出版社である株式会社オライリー・ジャパンなどへ連絡していきたいと考えております。 本文書内で「リーダブルコード」を引用する場合には、 ここは引用です と表記します。 法律・権利的なご指摘や、内容についてのご感想・ご指摘などございましたら、 私、多田雅斗a.dat.jp@gmail.comまでご連絡ください。 また、プルリクエストも随時歓迎しております。 はじめに 対象者 この文章の対象は、「Web開発者」としていますが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/hfu/noteworthy/blob/master/what-is-so-funny-about-standardization.md
GitHub - librariesio/metrics: :chart_with_upwards_trend: What to measure, how to measure it.