diff options
Diffstat (limited to 'Biz/Dragons')
-rwxr-xr-x | Biz/Dragons/get-examples.sh | 5 | ||||
-rw-r--r-- | Biz/Dragons/pitch.md | 14 |
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) |