Initial revision.

.gitignore

@@ -0,0 +1,2 @@
+.jekyll-metadata
+_site

.redirects

@@ -0,0 +1,2 @@
+# redirect 301 /blogs/chad_myers/archive/2008/01/04/joining-the-donkey-side.aspx http://lostechies.com/chadmyers/2008/01/04/joining-the-donkey-side/
+# redirect 301 /members/chadmyers/default.aspx http://lostechies.com/chadmyers/

404.html

@@ -0,0 +1,23 @@
+---
+layout: default
+---
+<style type="text/css" media="screen">
+.notfound {
+  margin: 10px auto;
+  max-width: 600px;
+  text-align: center;
+}
+  h1 {
+    margin: 30px 0;
+    font-size: 4em;
+    line-height: 1;
+    letter-spacing: -1px;
+  }
+</style>
+
+<div class="notfound">
+  <h1>404</h1>
+
+  <p><strong>Page not found :(</strong></p>
+  <p>The requested page could not be found.</p>
+</div>

Gemfile

@@ -0,0 +1,29 @@
+source "https://rubygems.org"
+
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+#     bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "~> 3.7.0"
+
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.0"
+
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+  gem "jekyll-feed", "~> 0.6"
+end
+
+# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
+gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
+
+gem "jekyll-redirect-from", "~> 0.12.1"
+

Gemfile.lock

@@ -0,0 +1,78 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.5.2)
+      public_suffix (>= 2.0.2, < 4.0)
+    colorator (1.1.0)
+    concurrent-ruby (1.0.5)
+    em-websocket (0.5.1)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0.6.0)
+    eventmachine (1.2.5-x64-mingw32)
+    ffi (1.9.18-x64-mingw32)
+    forwardable-extended (2.6.0)
+    http_parser.rb (0.6.0)
+    i18n (0.9.1)
+      concurrent-ruby (~> 1.0)
+    jekyll (3.7.0)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      em-websocket (~> 0.5)
+      i18n (~> 0.7)
+      jekyll-sass-converter (~> 1.0)
+      jekyll-watch (~> 2.0)
+      kramdown (~> 1.14)
+      liquid (~> 4.0)
+      mercenary (~> 0.3.3)
+      pathutil (~> 0.9)
+      rouge (>= 1.7, < 4)
+      safe_yaml (~> 1.0)
+    jekyll-feed (0.9.2)
+      jekyll (~> 3.3)
+    jekyll-redirect-from (0.12.1)
+      jekyll (~> 3.3)
+    jekyll-sass-converter (1.5.1)
+      sass (~> 3.4)
+    jekyll-watch (2.0.0)
+      listen (~> 3.0)
+    kramdown (1.16.2)
+    liquid (4.0.0)
+    listen (3.1.5)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+      ruby_dep (~> 1.2)
+    mercenary (0.3.6)
+    minima (2.1.1)
+      jekyll (~> 3.3)
+    pathutil (0.16.1)
+      forwardable-extended (~> 2.6)
+    public_suffix (3.0.1)
+    rb-fsevent (0.10.2)
+    rb-inotify (0.9.10)
+      ffi (>= 0.5.0, < 2)
+    rouge (3.1.0)
+    ruby_dep (1.5.0)
+    safe_yaml (1.0.4)
+    sass (3.5.5)
+      sass-listen (~> 4.0.0)
+    sass-listen (4.0.0)
+      rb-fsevent (~> 0.9, >= 0.9.4)
+      rb-inotify (~> 0.9, >= 0.9.7)
+    thread_safe (0.3.6)
+    tzinfo (1.2.4)
+      thread_safe (~> 0.1)
+    tzinfo-data (1.2017.3)
+      tzinfo (>= 1.0.0)
+
+PLATFORMS
+  x64-mingw32
+
+DEPENDENCIES
+  jekyll (~> 3.7.0)
+  jekyll-feed (~> 0.6)
+  jekyll-redirect-from (~> 0.12.1)
+  minima (~> 2.0)
+  tzinfo-data
+
+BUNDLED WITH
+   1.16.1

_andrewsiemer/2015-04-20-exciting-user-groups-and-workshops-coming-up.md

@@ -0,0 +1,46 @@
+---
+id: 30
+title: Exciting user groups and workshops coming up
+date: 2015-04-20T15:15:34+00:00
+author: Andrew Siemer
+layout: post
+guid: http://lostechies.com/andrewsiemer/?p=30
+dsq_thread_id:
+  - "3764970822"
+categories:
+  - AzureAustin
+  - Clear Measure Workshops
+  - Community
+  - meetup
+---
+Good morning all! Some of you may be aware that I run a couple of user groups.  Figured I would let you all know about the user groups that are coming up in our near future.
+
+## Azure Austin
+
+[Azure Austin](http://www.meetup.com/azureaustin/) meets every third Wednesday of the month to discuss all things Azure oriented.  Some are deep dive topics on Azure.  Other presentations discuss a topic deeply that may leak over into Azure.  If you are interested in presenting let me know.
+
+[May 20, 2015 – James Allen – Infrastructure as Code](http://www.meetup.com/azureaustin/events/221920439/)
+
+James Allen will discuss how to use templates to drive the launching of an Azure environment using json templates and resource manager.
+
+[June 17, 2015 – Lightning Rounds – Sign Ups Open!!!](http://www.meetup.com/azureaustin/events/221920588/)
+
+This is a lightning talk session.  5 minutes to talk about what ever cool Azurey thing you like.  Sign ups are currently open.  If you have some cool thing to share with the group let us know.  This is a great format for your first public speaking experience if you are new to this.  Come hang out with us and get a machine gun effect on Azure topics.
+
+## Clear Measure Work Shops
+
+Clear Measure Work Shops are a longer format that is more about hands on keyboards and less about long winded slide show presentations.  These will happen at least once a month on the last saturday of the month.  In these meetings we will spend 20 minutes defining the topic and goal of the day. Then 3 hours actively working towards the goal in a small group (think pair programming) format.  There will be at least one moderator that has experience on the topic being presented to help drive the group towards their goal.  We will be supporting virtual attendees as best we can in these groups.  Virtual attendees will pair with one another.
+
+[April 25, 2015 – Learn CQRS with Gabriel Schenker](http://www.meetup.com/Clear-Measure-Workshops/events/221702494/)
+
+In this meeting we will discuss a system to build using the CQRS pattern.  Bring your laptops and come prepared to get your fingers dirty banging out some code with your peers!
+
+[May 30, 2015 – Learn DDD with Justin Self and Jeffrey Palermo](http://www.meetup.com/Clear-Measure-Workshops/events/221920364/)
+
+In this meeting we will discuss a system to build using the DDD pattern.  Bring your laptops and come prepared to get your fingers dirty banging out some code with your peers!
+
+## Want to get involved?
+
+If you are interested in coming to one of these events sign up on meetup.com and RSVP to the event.  If you are interested in presenting a new idea just reach out to me directly and let me know.  I will get you into the schedule.  We need people like you to keep this sort of community event alive!
+
+ 

_andrewsiemer/2015-04-27-the-first-clear-measure-workshop-was-a-great-success.md

@@ -0,0 +1,23 @@
+---
+id: 32
+title: The first Clear Measure Workshop was a great success
+date: 2015-04-27T15:29:13+00:00
+author: Andrew Siemer
+layout: post
+guid: http://lostechies.com/andrewsiemer/?p=32
+dsq_thread_id:
+  - "3758592787"
+categories:
+  - Clear Measure Workshops
+---
+[<img class="alignnone size-full wp-image-37" title="clear-measure-workshops" src="http://clayvessel.org/clayvessel/wp-content/uploads/2015/04/clear-measure-workshops.png" alt="" width="600" height="362" srcset="http://clayvessel.org/clayvessel/wp-content/uploads/2015/04/clear-measure-workshops.png 600w, http://clayvessel.org/clayvessel/wp-content/uploads/2015/04/clear-measure-workshops-300x181.png 300w" sizes="(max-width: 600px) 100vw, 600px" />](http://clayvessel.org/clayvessel/wp-content/uploads/2015/04/clear-measure-workshops.png)
+
+This weekend we had our first [Clear Measure Workshop](http://www.meetup.com/Clear-Measure-Workshops/) on CQRS.  I will save you my retrospective on the event as [Gabriel Schenker](https://lostechies.com/gabrielschenker/2015/04/25/cqrs-workshop-retrospective/) already posted his thoughts on that.  Instead I will point you to our next event by [Justin Self](https://twitter.com/thejustinself) and [Jeffrey Palermo](https://twitter.com/jeffreypalermo) on [Domain Driven Design](http://www.meetup.com/Clear-Measure-Workshops/events/221920364/) which will be held on May 30th (every last Saturday of the month).
+
+In our last event we had roughly 20 or so folks show up, spread across in person and remote folks.  We already have 21 folks signed up for the next event.  And if you are reading this outside of Austin, please do consider signing up for the next event.  Our remote viewers had just as much fun at this even as the in person folks did.
+
+Not yet familiar with the notion of our workshops?  Let me break it down real quick.  This is not a user group meeting, brown bag, or other slide heavy presentation.  Instead we intend to constrain the moderator to no more than 20 minutes of presentation in the front of the day.  Then we break into 2-4 person teams to work towards the days goals.  We present the days goals in &#8220;story form&#8221; just as you would be presented by a product owner in a working scrum fashion.  It is up to you to mind the constraints of the day (DDD for example) and work with the product owner to get a good picture of what is being built.  Not asking questions could lead you to building too much of the wrong thing.  So ask questions.  Towards the middle of the day we will provide lunch and have a mid-day review of where everyone is.  The idea is to talk about the problems you are facing.  Talking in real time across teams is also encouraged.  We will provide the lunch (in the last workshop we had Chuy&#8217;s!).  Then we get back at it again.  And towards the end of the day we break for a final retrospective to openly discuss pro&#8217;s and con&#8217;s that you found during the day.
+
+In our last workshop we used Zoom.us for overall group communication.  We also used Slack (cmworkshops.slack.com team) to coordinate teams via group chat.  And in Slack we enabled appear.in and google hangouts for team video collaboration.  We intend to keep the slack channel open so that the group can have good conversation there for long term.  A little community building if you will.
+
+If any of this interests you make sure you go find us on meetup and join in!  Also, feel free to suggest a topic if none of the scheduled topics interest you.  We will do our best to incorporate your ideas.

_andrewsiemer/2015-05-10-initial-thoughts-on-microservices.md

@@ -0,0 +1,55 @@
+---
+id: 41
+title: Initial Thoughts on Microservices
+date: 2015-05-10T00:06:54+00:00
+author: Andrew Siemer
+layout: post
+guid: http://lostechies.com/andrewsiemer/?p=41
+dsq_thread_id:
+  - "3758464786"
+categories:
+  - Microservices
+---
+I have spent quite a bit of time teaching cqrs, ddd, strong boundaries, document data stores, and all sorts of other methods for taming complexity in either wide applications (lots of features/complexity) or  high volume systems (both have different issues).  Microservices has been very interesting to me on the side for a while.  But since working on a few massive projects at {insert big commerce company name here} and seeing some of the complexities around trying to mash up massive monolithic systems, I am compelled to look at microservices as an upfront solution for addressing the day to day complexities of even some of the smaller systems we build.
+
+There are all sorts of trade-offs with microservices as you probably all know.  The first rule of any distributed system being don’t do it!  Of course.  But there are also issues such as chattiness on your network, more moving pieces to be managed in production, more complexity around deployment processes. The list goes on.
+
+But I have found myself wondering quite a bit lately if it shouldn’t be the norm for many medium complexity systems?  I am not making that statement here and now.  Instead I figured I would explore the concept in the open over the course of a few posts and perhaps we can have a great conversation along the way. I have no agenda to push microservices one way or the other.  Just curious!
+
+## Single Responsibility Principle Everywhere?
+
+Most of us are aware of the SOLID principles.  If you aren’t aware of them… stop reading my dribble and head over to Wikipedia to learn about SOLID ([http://en.wikipedia.org/wiki/SOLID\_%28object-oriented\_design%29](http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29)).  As with most “best practices” do keep in mind that you can’t apply any of the solid principles 100% of the time to 100% of your code.
+
+The single responsibility principle to me is an interesting one.  It basically states that there should be only one reason for something to change at the class or module level. This idea leads to stability in the system. Unless I am changing the contract of a class or module, all changes should be internal.  The surface area for testing that one thing is small and easy to understand.  A change here shouldn’t necessitate full stack testing…little impact should be felt.
+
+This usually means that we have an orgy of classes in our code base.  And those classes tend to have long but meaningful names. If you have ReSharper or similar tooling installed, having lots of characters in a class name shouldn’t bother you. Nor should have a lot of classes bother you. Yet these two facts keep people from embracing SRP even in their current monolithic systems…I always wonder why?
+
+What if we were able to apply SRP to the various components of higher level SDLC concepts? What if I had one github repository for each component in my system?  What if I could use “whatever technology best fit the problem” for each component of the system? What if the scope of each component of the system was so small I didn’t have any complexity to manage in code, and therefore didn’t need CQRS or DDD?
+
+This sounds pretty good to me as someone that is involved with staffing teams. I could start to hire folks that didn’t need to be overly skilled at managing complexity. I could have one or two really skilled folks involved with contract definitions.  And an army of folks building lego blocks.
+
+In theory I could build a mashup of components instead of a monolithic system.  Each component with a single reason to change.  A small surface area to test. Its own versioning story. It’s own deployment story (no more managing deployments across teams of monolithic highly coupled systems over the course of several days). That sounds easier in many ways.  But it also sounds like it adds complexity in other new and interesting ways.
+
+## Managing Code Complexity by Building Something Small
+
+I so often come across big code bases that struggle to manage the complexity of the business features (price vs. product vs. search etc.) and the complexities of lots of code coexisting with other code (UI vs. business concerns vs. data access vs. offline processing etc.).  There are usually a whole bunch of architectural complexities and design patterns injected to solve some of these problems.  But usually injected in the form of the shiniest hammer the implementer had in their tool box at the time (I am so guilty of this – be honest…).
+
+Following the SRP concept above, if we spent two weeks building a microservice, focused on only what was needed in a LEAN/MVP way, there should be next to no complexity to manage.  And if we did it just good enough for now, it would be cheap to throw it away and build another once we learned more about our needs.
+
+It’s so very odd to me that the best thing I learned from Udi’s 5 day course on advanced distributed systems (years ago) was this same statement of “get the contract right, build just enough to achieve the business goal, use an entry level guy to build it, throw it away when you need something better” – is now a labeled way of doing things.
+
+## Managing Code Complexity with Hard Boundaries
+
+One of the mechanisms we use to manage complexity in code is through defining healthy logical and physical boundaries that map to the concepts of business.  An example of this is the idea of a “product”.  I have seen so many projects that have one class that is named product.  But when interviewing the company the Marketing Department would define a product as something different from what the folks in the Inventory Department would tell you which might also be different from the folks in the Accounting Department.  If each of these departments have a product concept why not model three different forms of product?
+
+Usually the answer comes down to our issues with efficiency around typing three classes that are all product oriented – we don’t like to repeat ourselves (keep it DRY).  We like the OOP concept of defining a base class and extending it into multiple forms.  But we usually shouldn’t do that if we really paid attention and heard the business.  Marketing’s product is the virtual thing that needs to have well-spoken text around it and lots of pretty pictures.  Inventory cares about how many of those products we have in a warehouse, how big they are, how many are on a boat this very second and about to arrive any day “where are we going to put those?”  Accounting doesn’t really care about any of that.  Instead they want to know what we paid for it vs. what we sold it for.  Did we make a profit?
+
+Defining a hard boundary allows each of these product concepts to have their own life cycle.  Changing some aspect of a product for one department shouldn’t have any potential to break the concept of product anywhere else.  Each boundary should manage its own state. And provide views around its state to other consumers as necessary. In some cases it may even provide UI elements to ensure consistency at all times.
+
+What about groups of domain objects that are all related?  Which one is important (entity)? Which one can’t exist on its own vs. needing its peers to make sense (value objects)?  How do we consistently manage the state of those things (aggregate roots)?  And how do we manage the physical presence of these things in the real world (autonomous components) vs. a larger logical boundary in our code (bounded context)?  All of these concepts are required to manage the complexity of a code base that lives in an uber solution all next to one another (commonly referred to as monolithic…aka spaghetti).  But what if it all didn’t live next to each other?  Wouldn’t we be less likely to create a monolithic system that accidentally starts to take short cuts and couple itself to itself…mistakenly? Enter the senior/junior code review relationship could be reduced to some degree.  People processes to manage accidental complexity could start to be reduced all around.
+
+## Just Getting Started
+
+While this has interested me for many years now – I am starting to see how this could help many teams either building products or servicing clients. Not for cool architectural reasons but for the ability to really focus on delivering just enough – and no more.  And the ability to continuously deliver just enough at a very rapid rate. Instead of having a team whose velocity slows as the complexity of the system increases over time.  Also for the ability to scale a software factory where the needs of the client tend to grow and contract (not forgetting the 9 mother 1 month baby analogy of course).
+
+Please feel free to pose questions here around this topic.  I will do my best to address them in follow up articles and talks.