Update from Capgemini/blog-private@e603852

_posts/2014-10-06-estimation.md

@@ -93,7 +93,7 @@ My estimate is accurate as long as ...
 
 Also, make sure you define "done". Will done mean that you've committed the code and run some tests locally, or that
 you'll have followed the change through various environments and its ready to be pushed into the next Production release?
-Regardless of how you define "done", this is one of your key assumptions, so make sure you and and the person you're
+Regardless of how you define "done", this is one of your key assumptions, so make sure you and the person you're
 giving the estimate to have the same definition of done and therefore share the assumptions.
 
 #### Add inflation

_posts/2014-10-17-microservices-reality-check.md

@@ -30,7 +30,7 @@ Despite all this we're persisting. Despite always questioning every decision we
 5. It's fun, it's exciting, and actively doing things that are new (and this does feel new) keeps you on your toes far more than a "standard" (read: JavaEE) approach would. That's a good thing. A great thing
 
 ### The Un-Good
-And yet its not all #winning.  Perhaps it's the lack of balanced opinion in the general chatter that makes me feel the fear I mentioned earlier. Most posts I read are just so sychophantic on the topic, and the world *really* doesn't need another one of them. So, deep breaths, lets dig into that a bit more and present some of the reasons Microservices might not be for you.
+And yet its not all #winning.  Perhaps it's the lack of balanced opinion in the general chatter that makes me feel the fear I mentioned earlier. Most posts I read are just so sycophantic on the topic, and the world *really* doesn't need another one of them. So, deep breaths, lets dig into that a bit more and present some of the reasons Microservices might not be for you.
 
 1. First up, some honesty.  We're finding that despite all the noise in this space very few folks out there are actually _doing_ this, and even fewer doing it in a public manner.  We however are.  Finding that very few others are with you can be a little scary at times.  It means you actually have to *do  research* and *make your own decisions* which for most of us in the safe world of Jave Enterprise Development is a new experience.  Consequently, we've staked our professional reputations on this, and we've got a lot less to hide behind - we're on the front line of all this challenging of accepted wisdom
 2. Things won't "just work" when you glue them together; and things which do work might not have the greatest documentation in the world.  Many many decks on [slideshare](http://www.slideshare.net/) refer to all the bits you'll need to get up and running in seconds - but there is a impedance mismatch between many of them, and as an early adopter *you* need to fix that.  Having said this, the other thing all these projects have in common is a vibrant community. In most things in this area the code is under active development, and so is the documentation. If you want to get involved and help, folks are very pleased to have you along for the ride.  That's great, but it does slow things down a bit.  It also means you might be [ahead of the curve](https://issues.apache.org/jira/browse/CAMEL-5539) on the major libraries you rely heavily on - for example we plugged Hystrix into Camel for our own Circuit-Breaking purposes before they added a CB of their own in the [latest (2.14.0) version](http://camel.apache.org/camel-2140-release.html).  We also chose [CXF](http://cxf.apache.org/) for our REST APIs (when the rest of the world was going [Jersey](https://jersey.java.net/)) because it was a first-class citizen in Camel, only to find the exposure of Camel Routes as REST wasn't at that point incredibly mature.  ([Note: It now is](http://camel.apache.org/rest-dsl.html), it's even got [Swagger support](http://camel.apache.org/swagger.html))

_posts/2014-10-31-securing-drupal.md

@@ -149,7 +149,7 @@ approaches to keeping your Drupal installation secure:
 * [Securing your Site](https://www.drupal.org/security/secure-configuration) - Drupal.org
 Handbook entries providing security configuration advice
 * [Writing Secure Code](https://www.drupal.org/writing-secure-code) - Drupal.org
-Hanbook entries providing guidance on keeping your custom code secure
+Handbook entries providing guidance on keeping your custom code secure
 * [Cracking Drupal: A Drop in the Bucket](http://crackingdrupal.com/) - written by Greg Knaddison ([greggles](https://www.drupal.org/user/36762)), first published in 2009 but still very relevant
 * [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) -
 A list of the 10 Most Critical Web Application Security Risks