summaryrefslogtreecommitdiff
path: root/Biz/Dragons
diff options
context:
space:
mode:
Diffstat (limited to 'Biz/Dragons')
-rwxr-xr-xBiz/Dragons/get-examples.sh5
-rw-r--r--Biz/Dragons/pitch.md14
2 files changed, 10 insertions, 9 deletions
diff --git a/Biz/Dragons/get-examples.sh b/Biz/Dragons/get-examples.sh
index a35a282..35f024f 100755
--- a/Biz/Dragons/get-examples.sh
+++ b/Biz/Dragons/get-examples.sh
@@ -6,8 +6,9 @@ then
exit 1
fi
cookie="$1"
-curl 'https://dragons.dev/analysis?user=github&repo=training-kit' \
+curl 'https://dragons.dev/analysis' \
+ -d "owner=github&repo=training-kit" \
-X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H "Cookie: JWT-Cookie=$cookie" \
- --compressed --insecure
+ --compressed
diff --git a/Biz/Dragons/pitch.md b/Biz/Dragons/pitch.md
index a4d4ffa..91352fc 100644
--- a/Biz/Dragons/pitch.md
+++ b/Biz/Dragons/pitch.md
@@ -1,6 +1,6 @@
-# Dragons
+# Dragons.dev
-Dragons analyzes your codebase trends, finds patterns in how your developers
+Dragons.dev analyzes your codebase trends, finds patterns in how your developers
work, and protects against tech debt.
Just hook it up to your CI system - it will warn you when it finds a problem.
@@ -9,15 +9,15 @@ Just hook it up to your CI system - it will warn you when it finds a problem.
What if none of your active employees have touched some part of the codebase?
This happens too often with legacy code, and then it turns into a huge source of
-tech debt. Dragons finds these "blackholes" and warns you about them so you
+tech debt. Dragons.dev finds these "blackholes" and warns you about them so you
can be proactive in eliminating tech debt.
## Protect against lost knowledge
Not everyone can know every part of a codebase. By finding pieces of code
-that only 1 or 2 people have touched, dragons identifes siloed knowledge. This
-allows you to protect against the risk of this knowledge leaving the company if
-an employee leaves.
+that only 1 or 2 people have touched, Dragons.dev identifes siloed knowledge.
+This allows you to protect against the risk of this knowledge leaving the
+company if an employee leaves.
## Don't just measure "code coverage" - also know your "dev coverage"
@@ -34,7 +34,7 @@ developers then you will never get optimal performance from your team.
## See how your teams *actually* organize themselves with cluster analysis
Does your team feel splintered or not cohesive? Which developers work best
-together? Dragons analyzes the collaboration patterns between devs and helps
+together? Dragons.dev analyzes the collaboration patterns between devs and helps
you form optimal pairings and teams based on shared code and mindspace.
(Paid only)