Development Experience(s)

Versioning is hard. The first rule of Versioning is don't do versioning , meaning - if we are at all able, we should try to find ways other than versioning components to coordinate upgrades of the same. Let's start there. If you have component that you wish to expose to a third party - a service  of some kind - and you resist the temptation of creating a generic interface to that service, but instead create a specific interface for that consumer, you will have little reason to change this interface in the future, when you need to cater to another consumer. I've gone into more details in a previous blog post, so I'll just refer you there . When you do need to do versioning, however, there are some strategies you can follow to avoid the dreaded breaking change  scenario, where one or more of your consumers stop working, until they are in sync with your recent changes. The particular strategy explained below, has been tested with WCF Services (using XML serialization

Introduction With the web application platform quickly evolving, we are under a constant bombardment of new features, frameworks and techniques. Some of these, such as Web Components  ( Polymer ), enables us to revisit ideas from the past, such as Web Mashups ( 2003 , 2006 ). The underlying idea of both mashups and components, is to use small pieces of functional UI and assemble them into larger solutions / applications. As the Web Components are maturing / finishing cooking, I have an alternate (or intermediate) solution I'd like to discuss with you. Background Why this article? As the amount of software we produce (and thus need to maintain) in our company increase (while shifting focus to meet the market and rotating some of our staff (consisting of about 50% contractors in some parts of the organization)), our development teams are struggling to deliver consistent quality. This is expressed in a difficulty to ensure green builds (no unit & integration test failures

Just like software projects benefit from first creating a walking skeleton  of its solution, we get a similar benefit from the risk assessment example in the previous article : If stakeholders cannot verbally agree on responsibility boundaries and terms, we cannot possibly produce a maintainable software solution to support the business. We need to find Software-to-Business Alignment . The hard part of software architecture lies where the boundaries intersect. What's inside of each boundary is, generally and relatively, easy. A  Walking Skeleton  is a tiny implementation of the system that performs a small end-to-end function. -  http://alistair.cockburn.us/Walking+skeleton As an example of an identified conflict (i.e. two bounded contexts) in our exercise was the fact that parts of the business process saw the individuals that visited the event as Attendees whereas parts of the process identified them as Customers . A Customer should probably have some billing informatio

What follows, is some reflection after the first exercise (which you can read about here ). Your big enemy is time. Domain Experts are a busy sort, so try to make the workshop as engaging as possible. Postpone any boring bits and don't focus on completing tasks. It's the facilitator's duty to mark hot spots to park any heated discussions and thereby avoiding the participants not participating in the discussion of getting bored. "Postpone ordering events into exact chronological order", Alberto said cheekily - "the developers will do this for you automatically, for free!". Invite the most important people you can, given your goal, and then spread the knowledge from the event storming throughout the organization. This will, in turn, spark interest for any upcoming discussions which might have a larger hit rate, even if the first meeting had a low turnout. Do remember, Alberto instructed us, that the stickies on the wall are not engaging for a third-p

Event Storming is something that needs to be experienced. That said, I'll do my very best to describe my experiences in words, hopefully illustrating its benefit when working in situations that reminds of Business Process Modelling  or requirements/business analysis. Last week, I had the pleasure of joining a one day Event Storming Workshop with the ES father Alberto Brandolini as he was visiting Stockholm. Alberto described ES as a "brain dump" of his - something he had formulated over the years and originally intended as an introduction to Domain Driven Design, but then took a life of its own. In this particular workshop, the average attendee had little to no experience with Event Storming, other than hearing about it from other conference speakers or seeing its name in a flyby tweet. Brandolini started us off by placing us in front of a huge whiteboard (about three average whiteboards in length), making an abundance of marker pens and sticky notes available,

Today, I learned that - although supposedly more efficient - you cannot actually just copy the input stream from a Azure Service Bus BrokeredMessage into a block blob and have that blob be read by Stream Analytics. This is because stream-copy introduces some control characters into the event stream, which makes it so that stream analytics cannot read the events, thinking that maybe you configured your Path Prefix Pattern wrong. In the example above, notice how I pass CultureInfo.InvariantCulture into the path-generating DateTime expression. This is because DateTime has some magic built in, rending the expression as 2015-09-23-15 for the 23rd of September, 2015 at 15 o'clock on my machine, instead of what I (thought I) requested - 2015/09/23/15 . That aside, the resulting blob had control characters and serialization data in it, which was not something I expected: Extracting the JSON-encoded string itself and uploading that as a byte array, worked a lot better, eli

Here are some of my notes from Sweden Azure User Group's CloudBurst 2015 at Microsoft premises in Stockholm. The recordings have been made available  (courtesy of Live Arena ), and if you're interested in the agenda for the two days, it is here . The speakers had been invited and then got to decide for themselves, what they wanted to speak about (given the Azure context, of course). It turned out fairly varied, but with a certain emphasis on identity services / management and microservice characteristics. Azure Service Fabric Still in preview; not likely to be released this year. Is considered PaaS v2, superseding Microsoft's current Cloud Application platform (Web- and Worker Roles). Things like Azure Service Bus, Azure SQL database and Cortana runs on Service Fabric. Now, they are packaging it up for consumption, just like they did with Azure AD. Micro service is: Logic & state that is independently versioned, deployed and scaled. Today's cloud

If you're using Windows Azure ServiceBus behind a corporate firewall, and you just use the default settings the SDK provide you with, you might find yourself in a situation where the initial connection to the services takes forever  (21 seconds on average for me). This is because it, by default, uses TCP connectivity and tries to communicate on ports that we have blocked. To, instead, use HTTPS as transport, run this code in the startup of your application: Connection time down to near-instant. Yay! The ConnectivityMode also includes a HTTP mode.

Testing vs. Monitoring-and-Acting Consider continuously running your main journeys in production! Order a CD every 25 minutes to ensure that things are OK! Don't run destructive tasks though ... ;-) This is an excellent way to identify things that are out of your reach when developing the software, such as changes in a firewall configuration (done by someone else, to resolve an issue elsewhere in your corporation). Canaries Make a checklist of what a good service is, deploy a new parallel version and redirect parts of the traffic to the canary, while monitoring its characteristics. If it fulfills the requirements of your checklist, it works and you can safely retire the old version of the service. UIs User Interfaces are compositional in nature. We don't want to interact with a system through its distinct parts - we want a cohesive experience. One way of accomplishing this, is to create BFFs, or Backends For Frontends : Other schools of thought call these

NDepend 6 is out; let's see what it can do for us! I got the latest bits and ran an analysis on an old project of mine - a MUD Bot. For such a small project, the dependency graph (depicted below) didn't tell me much that I didn't already know, but the code quality analysis was a lot more telling. NDepend quickly ran through its 273 queries, highlighting first an issue with a method being too complex. It was the ShortenPath  method in my NavigationModule  depicted to your right. Seeing the code, I immediately realized that I was lacking a crucial domain concept - that of a Path! A room in a MUD world doesn't just have exits  that can be represented as a string, but they can also be temporarily disabled, e.g. blocked by a locked door. Well, that was a quick win! One big reason to upgrade to NDepend 6, is to get support for Visual Studio 2015. From what I can tell, it doesn't yet support .NET Core projects, but I've gotten back to them about that, so