dev-academy-programme · don-smith · Jul 1, 2017 · Jul 1, 2017
diff --git a/README.md b/README.md
@@ -1 +1,5 @@
-# concepts
+# concepts
+
+> This repository has been deprecated.
+
+Formerly it served as the location for concepts in the student handbook, which was a separate repository. We found there wasn't any value in separating the content from the book so the concepts have been moved into the [student handbook](https://github.com/dev-academy-programme/book-source). Only the concepts being used at the time were migrated out of this repo.
diff --git a/agile/introduction.md b/agile/introduction.md
@@ -1,7 +1,8 @@
-Agile is a methodology for software development whose aims include responsiveness, flexibility, and early/continuous delivery of products.
+# Agile Software Development
 
+Agile is a methodology for software development whose aims include responsiveness, flexibility, and early/continuous delivery of products.
 
-### Why?
+## Why?
 
 Agile's origins date back to the 1970s. People started becoming frustrated with the traditional 'waterfall' model of development:
 
@@ -22,37 +23,37 @@ Trouble is, often what the finished product actually needs to be can't be determ
 > At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished? ~ [agilemethodology.org](https://agilemethodology.org)
 
 
-### Scrum
+## Scrum
 
 Scrum is the most common/popular approach to Agile development. You can read more about it <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)">on Wikipedia</a>. Some people use the terms interchangeably, but strictly speaking Scrum is _a kind_ of Agile. Another way to describe it: Scrum is a _framework_ for Agile development. It gives specific guidance on roles (Product Owner, Scrum Master) and the process or order of events. Most of the following content is related to "Scrum-flavoured Agile".
 
 
-### Team composition
+## Team composition
 
 Traditional teams are often siloed: all the management/architects together, all the designers together, all the developers together, all the testers together. Agile development encourages teams to be _cross-functional_: made up of people from many different disciplines. Scrum encourages self-organising teams.
 
 
-### Iteration
+## Iteration
 
 In Agile, we try to incorporate a little of each phase of development (requirements, design, develop, etc) into short cycles, often called _sprints_. The idea is to have code that could potentially be _shipped_ (deployed, published) at the end of each sprint. Two week sprints are common.
 
 ![](https://raw.githubusercontent.com/dev-academy-programme/concepts/master/agile/agile.png)
 [Source](https://commons.wikimedia.org/wiki/File:Agile_Project_Management_by_Planbox.png)
 
 
-### The backlog
+## The backlog
 
 A backlog is a list of tasks that together make up an application: if you completed all of them, you'd have a great product! Some are product features, but not all: documentation and bug fixes are also entered on the backlog. Items on the backlog may be further classified with labels: is it a feature or a bug? Is it considered part of the Minimum Viable Product? Is it frontend or backend, or both?
 
 The backlog is likely to feature _user stories_, and may break each story into multiple tasks to be completed.
 
 
-### Sprint planning
+## Sprint planning
 
 At the start of each sprint, a [meeting](http://www.leadingagile.com/2012/08/simple-cheat-sheet-to-sprint-planning-meeting/) is held to set the scope of the sprint, deciding which tasks will be completed by the end of it.
 
 
-### Stand-up
+## Stand-up
 
 Held daily, the stand-up (or "scrum") should be carefully timeboxed and starts even with missing team members. Everybody should report:
 
@@ -63,19 +64,19 @@ Held daily, the stand-up (or "scrum") should be carefully timeboxed and starts e
 This isn't the time for long discussions! Standups are for quick summaries. For most teams they shouldn't take longer than 15 minutes. A scrum master or similar role will keep track of blocks that might affect the ability of the team to deliver on time, and who on the team is assigned to resolve the block.
 
 
-### Sprint review
+## Sprint review
 
 Review the work that was completed, and what was not completed. Demo the working code. Don't demo what was not completed!
 
 
-### Sprint retrospective
+## Sprint retrospective
 
 What went well? What could we do differently or better next time?
 
 This is a great chance to learn from the previous weeks. It should not be used as an opportunity to cast _blame_, however. Instead, identify _systemic_ problems. How could our team improve to overcome the difficulties we experienced?
 
 
-### Resources
+## Resources
 
  - http://agilemethodology.org/
  - http://scrumreferencecard.com/

diff --git a/agile/user-stories.md b/agile/user-stories.md
diff --git a/ajax/ajax-intro.md b/ajax/ajax-intro.md
diff --git a/ajax/cors.md b/ajax/cors.md
diff --git a/api/api-proxy.jpg b/api/api-proxy.jpg
diff --git a/api/cors.md b/api/cors.md
diff --git a/api/crud-rest.md b/api/crud-rest.md
diff --git a/api/intro.md b/api/intro.md
@@ -1,4 +1,6 @@
-Application Programming Interface - not an initialism that feels particularly useful.
+# Application Programming Interface
+
+Admittedly not an initialism that feels particularly useful.
 
 Essentially, an API is a point where you can access information if you ask for it in a specific manner.
 
@@ -15,3 +17,4 @@ If we ask the bank teller through the window (*endpoint*) 'Hey, can I have $300?
 Imagine if you will, you go to the bank window (*endpoint*) wearing a mask, waving a toy gun around and shouting 'GIVE ME ALL THE MONEY!' You are not going to get any money (if the bank's security is sufficiently strong!)
 
 This highlights one of the most important features of using an API: there will be a specific way in which you can interact with them, which will be listed in its documentation. If you don't ask an API for information in a way it expects, you will not get your required data.
+
diff --git a/api/keys.md b/api/keys.md
diff --git a/api/supertest.md b/api/supertest.md
diff --git a/api/versioning.md b/api/versioning.md
@@ -1,7 +1,6 @@
-APIs should be properly versioned.
-APIs evolve and change, we must do this while supporting old versions.
-Otherwise, if you just change your API, a lot of your clients would be in trouble.
-Although, we won't be developing multiple versions (today we're working on V1), it is important that we plan for the future and properly namespace our documentation and work under V1 namespace.
+# Versioning APIs
+
+APIs should be properly versioned. APIs evolve and change, we must do this while supporting old versions. Otherwise, if you just change your API, a lot of your clients would be in trouble. Although, we won't be developing multiple versions (today we're working on V1), it is important that we plan for the future and properly namespace our documentation and work under V1 namespace.
 
 Here's our v2 api: get a list of all cats at `/cats`
 
@@ -15,4 +14,5 @@ The original route for getting all the cats was `/show_me_the_cats`
 
 ```
 api/v1/show_me_the_cats
-```
+```
+