markdown syntax issues with headings

_posts/2015-09-27-agile-dirty-word.md

@@ -24,7 +24,7 @@ I guess I wasn't surprised; Agile is, after all, a development methodology. But
 
 <!--break-->
 
-###Goofy Vocabulary###
+### Goofy Vocabulary ###
 
 It may be reductive to say that Agile isn't embraced by non-technologists because it doesn't sound cool. But honestly, "scrum master"? You might as well call it <em>dungeon master</em> for all the good it'll do for Agile's image. Having known a few of the former and many of the latter, it's hard to say who makes out worse with the comparison.
 

about/index.md

@@ -18,7 +18,7 @@ This isn't to say I wouldn't value input from the mainstream devops community. F
 
 So whether you're just learning about devops and you want to share your questions and ideas, or you're a seasoned professional that wishes the rest of the world would work as efficiently as you do, please feel free to engage with this platform. Comment with your thoughts, or take it one step further and <a href="https://github.com/JoeMorgan/devopsfortherestofus" target="_blank" title="Fork this blog on GitHub.com">fork this blog on github</a> and make a pull request to [write your own post](/submission/ "Learn how to submit your own post to Devops for the Rest of Us").
 
-##About Me##
+## About Me ##
 
 I'm a Senior Manager of experience technology at <a href="http://www.sapientnitro.com/en-us.html#home" target="_blank" title="SapientNitro.com">SapientNitro</a> in Boston. I'm lucky to help lead a group of incredibly talented developers in an energetic and fast-paced agency environment.
 

submission/index.md

@@ -14,9 +14,9 @@ Maybe you have an idea for how to apply devops principles to your job, outside o
 
 Well, why not author a post of your own? One of the neat things about this blog is that it <i>is</i> open source, and anyone can contribute. Given the intended reach of this site, there are a couple ways that you could write a post, depending on whether or not you're comfortable with <a href="https://github.com/" target="_blank" title="GitHub">GitHub</a>.
 
-##Ways to Contribute##
+## Ways to Contribute ##
 
-###Fork the Repo on GitHub###
+### Fork the Repo on GitHub ###
 
 If you're a technologist or you're otherwise familiar with git and GitHub, you'll probably find it easiest to simply fork <a href="https://github.com/JoeMorgan/devopsfortherestofus" target="_blank" title="Devops for the Rest of Us on GitHub">the repository</a>, draft your content, and make a pull request.
 
@@ -41,15 +41,15 @@ And please remember to follow the general [submission guidelines](#submission-gu
 
 That's it! Now you can list experience with Jekyll on your resume.
 
-###Send Me Your Post Content###
+### Send Me Your Post Content ###
 
 Yup, the old school way. Since this is a simple static site, we're not going to deal with logins, draft states, and permissions. Unless you're [comfortable using GitHub](#fork-the-repo-on-github), the best way for your voice to be heard on the blog is to simply reach out to me with your idea.
 
 You can draft the post content and send it to me by <a href="mailto:{{ site.owner.email }}" target="_blank">email</a>, along with some info about you for the sidebar (name, email, bio, an avatar picture to use, and any social info you want displayed). 
 
 Assuming you've followed the general [submission guidelines](#submission-guidelines), I'll draft the post and let you know when it's live. Easy, no?
 
-##Submission Guidelines##
+## Submission Guidelines ##
 1. Content in some way relates to devops
 2. Nothing derogatory, spiteful, or inflammatory; i.e., no trolling
 3. Opinion pieces are okay (encouraged, even!)

what-is-devops/index.md

@@ -13,7 +13,7 @@ People have been defining and redefining devops for years. The intent here isn't
 It may be obvious from the word devops&mdash;technically called a <a href="https://en.wikipedia.org/wiki/Portmanteau" target="_blank" title="Wikipedia">portmanteau</a>, but I prefer "frankenword"&mdash;that this all started as a way to combine development and operations. To bridge the gap between coders, who build products, services, and experiences, and infrastructure teams, who provision hardware and configure environments to bring that code out into the world. But why? What gap are we talking about?
 
 
-##Build and Release##
+## Build and Release ##
 
 At the risk of oversimplifying (and without getting into the historical details, best left to the pros at <a href="http://itrevolution.com/the-history-of-devops/" target="_blank" title="IT Revolution Press">IT Revolution Press</a>), it's about the old school build and release process, which kind of resembles this:
 <figure>
@@ -30,15 +30,15 @@ Historically, the result of this is that deployments are done infrequently to mi
 Given this, it shouldn't be surprising that, for many years, people have been looking for a better way to do things.
 
 
-##Devops as Automation##
+## Devops as Automation ##
 
 The rise of automation isn't exactly new. Developers have been using tools like Ant and Maven to improve build processes since the turn of the century (and before), and there are certainly analogs on the ops side. But it wasn't until tools were created to facilitate the *collaboration* of developers and IT operations staff that we started to see some real gains. The seminal example of this was the 2009 Velocity conference talk by John Allspaw and Paul Hammond, <a href="https://www.youtube.com/watch?v=LdOe18KhtT4" target="_blank" title="10+ Deploys Per Day: Dev and Ops Cooperation at Flickr">10+ Deploys Per Day: Dev and Ops Cooperation at Flickr</a>.
 
 Since those early days, there has been an explosion of tools coming out of the devops movement. So many in fact that people keep coming up with new ways to keep track of and organize them all. The <a href="https://xebialabs.com/periodic-table-of-devops-tools/" target="_blank" title="Periodic Table of DevOps Tools">Periodic Table of DevOps Tools</a> by XebiaLabs is my current favorite.
 
 And along with the popularity of these tools comes an increasing number of success stories from the companies that have embraced them (and, more importantly, the thinking behind them). Esty <a href="http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches" target="_blank" title="Continuous Deployment at Esty: A Tale of Two Approaches (on slideshare)">spoke at SWSX in 2013</a> about doing 25+ deploys per day (a number that has since doubled to more than 50 per day at QCon, London), while Amazon reports performing a production deployment every *<a href="https://www.youtube.com/watch?v=dxk8b9rSKOo&amp;feature=youtu.be&amp;t=10m8s" target="_blank" title="Velocity 2011: Jon Jenkins, &quot;Velocity Culture&quot;">11.6 seconds</a>*.
 
-##A More Interesting Angle##
+## A More Interesting Angle ##
 
 It may be obvious, but tools are a means to an end. If we surmise from the statistics above that the end in question is a deployment metric, then that should tell us something. What is a production release but the delivery of value from the business to the consumer? This line of questioning leads us to what I consider to be one of the more interesting views of devops:
 
@@ -59,7 +59,7 @@ Modeled after <a href="http://www.amazon.com/The-Goal-Process-Ongoing-Improvemen
 
 I was struck when reading this, not just because the word devops wasn't introduced until I was 78% of the way through the book, but because I started to think about challenges that I see in my own work in these terms.
 
-##Carrying Devops Forward##
+## Carrying Devops Forward ##
 
 If we accept the idea that practices of agile collaboration, automation, and measurement/refinement can have impacts throughout all areas of an organization, then it becomes clear that we're no longer just talking about development and operations, but a new way of doing work.