Update 2015-09-18-guapo.md

_posts/2015-09-18-guapo.md

@@ -32,7 +32,7 @@ So yes, this is definitely more real than a unicorn.
 	<figcaption>"Hang on Bill, let me check my test coverage before we hit the bars."</figcaption>
 </figure>
 
-###Docker 
+### Docker 
 
 In order for all of this to be real, we need that crucial core functionality that is the ability to quickly and easily distribute our environment. We found this solution in [Docker](https://www.docker.com/). You can get the complete description and ins and outs of Docker on their site, but for our purposes, it is a medium for running extremely lightweight VM's that can be heavily customized and built on command. There are three main concepts to internalize for the purpose of this explanation;
 
@@ -44,7 +44,7 @@ As a developer, one needs only pull down the El Guapo container from [Docker Hub
 
 It's worth noting at this point that Docker is used for a multitude of applications (pun intended) and further exploration of it is highly encouraged, but now that you've gotten the elevator speech on it, we take a look at El Guapo's toolbox.
 
-###Standardized Tools and Testing
+### Standardized Tools and Testing
 
 Our development group is a pretty diverse bunch, and with that diversity comes a wide variation in experience and exposure. In terms of testing, everyone is *familiar*, but it is not always put into practice on projects, and when it is, sometimes the coverage can become lax. Other times, it may not really make sense to have certain types of testing. A large scale web application might require **everything** to be tested, but a microsite with a four week development timeline, might just require some light end to end testing and performance testing. 
 
@@ -56,7 +56,7 @@ With El Guapo, a developer can choose what to use and when to use it. By simply
 	<figcaption>"This batch should be done testing after lunch."</figcaption>
 </figure>
 
-###Continuous Integration and server deployment
+### Continuous Integration and server deployment
 
 Finally, we want all of of our building and testing to happen automatically, both locally and on our servers. Well, since we have total control over our own environment, we can simply setup an instance of Jenkins in our Docker image and we're ready to go! The power this affords us is having a CI environment already setup for our front end that can be deployed on a server in the form of our Docker container. Too often we find ourselves wrestling with trying to get a new server environment setup to build our project automatically (often remotely) and it goes a lot like this:
 
@@ -76,4 +76,4 @@ The point of all of this is to hasten the ramp up time for new developers on a p
 and now it can feel like this:
 <figure>
 	<a href="https://media.giphy.com/media/MteOtn95GNx5e/giphy.gif"><img src="https://media.giphy.com/media/MteOtn95GNx5e/giphy.gif"></a>
-</figure>
+</figure>