Code

Yesterday, I read this blog post by Michael Feathers. In the post he goes over a pain point he has often found himself struggling with while breaking down a large method; conditional statements. if (alarmEnabled) { var alarm = new Alarm(); ... alarm.Sound(); } Should we extract the if and the associated block into a new method, or just the content of the block? Is the condition too important to hide in a method? How would we name the extracted method? How do we avoid the code from telling us lies? ...

Like I mentioned last week - after only five posts on the subject - there still are a great deal of event sourcing nuances left to be discovered. My current event store implementation only supports a single user. Due to an aggressive file lock, concurrently accessing an aggregate will throw an exception. Can we allow multiple users to write to and read from an event stream? Also, what can we do about users making changes to the same aggregate; can we somehow detect conflicts and avoid changes to be committed? ...

In my first two posts on event sourcing, I implemented an event sourced aggregate from scratch. After being able to have an aggregate record and play events, I looked at persisting them in an event store. Logically, the next question is: how do I query my aggregates, how do I get my state out? In traditional systems, write and read models are not separated, they are one and the same. Event sourced systems on the other hand have a write model - event streams, and a separate read model. The read model is built from events committed to the write model; events are projected into one or more read models. ...

Last week, I implemented an event sourced aggregate from scratch. There I learned, that there isn’t much to a naively implemented event sourced aggregate; it should be able to initialize itself from a stream of events, and it should be able to record all the events it raises. public interface IEventSourcedAggregate : IAggregate { void Initialize(EventStream eventStream); EventStream RecordedEvents(); } The question I want to answer today is: how do I persist those event sourced aggregates? ...

Last week I shared my theoretical understanding of event sourcing. Today, I want to make an attempt at making that theory tangible by implementing an event sourced aggregate. In traditional systems, we only persist the current state of an object. In event sourced systems, we don’t persist the current state of an object, but the sequence of events that caused the object to be in the current state. If we want an aggregate to be event sourced, it should be able to rebuild itself from a stream of events, and it should be able to record all the events it raises. ...

Working on side projects, I often find myself using RavenDB for storage and IronMQ for queueing. I wrote about that last one before here and here. One project I’m working on right now makes use of domain events. As an example, I’ll use the usual suspect: the BookingConfirmed event. When a booking has been confirmed, I want to notify my customer by sending him an email. I want to avoid that persisting a booking fails because an eventhandler throws - the mail server is unavailable. I also don’t want that an eventhandler executes an operation that can’t be rolled back - sending out an email - without first making sure the booking was persisted succesfully. If an eventhandler fails, I want to give it the opportunity to fix what’s wrong and retry. ...

Older Internet Explorer versions are notorious for agressively caching AJAX requests. In this post, you’ll find two techniques that combat this behaviour. The first option is to have your server explicitly set the caching headers. Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1)); Response.Cache.SetValidUntilExpires(false); Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches); Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.Cache.SetNoStore(); Since you don’t necessarily own the server, or clients might already have cached some requests, you can trick the browser into thinking each request is a fresh one by making each url unique. Our old pal jQuery already learned this trick years ago. Angular.js on the other hand seems to have forgotten. We can get around though. ...

When you use knockout validation to extend observables with validation rules, it will add a few functions to these observables - the most important ones being; error and isValid. You can use these functions to verify if any of the validation rules were violated, and to extract an error message. To extract all of the error messages out of a composite model, you can use a grouping function. function BookingModel() { var self = this; self.contact = new ContactModel(); self.departure = new DepartureModel(); self.isValid = function() { return self.contact.isValid() && self.departure.isValid(); }; self.validate = function() { if (!self.isValid()) { var errors = ko.validation.group(self); errors.showAllMessages(); return false; } return true; }; } function DepartureModel() { this.street = ko.observable('').extend({ required: true }); this.houseNumber = ko.observable('').extend({ required: true }); this.city = ko.observable('').extend({ required: true }); this.time = ko.observable('').extend({ required: true }); this.isValid = function() { return this.street.isValid() && this.houseNumber.isValid() && this.city.isValid() && this.time.isValid(); }; } function ContactModel() { this.firstName = ko.observable('').extend({ required: true }); this.lastName = ko.observable('').extend({ required: true }); this.phoneNumber = this.firstName = ko.observable('').extend({ required: true }); this.email = ko.observable('').extend({ required: true }); this.isValid = function() { return this.firstName.isValid() && this.lastName.isValid() && this.phoneNumber.isValid() && this.email.isValid(); }; } This is what my first attempt looked like. A little later I discovered that you can get rid of these boilerplate functions on the composite model by applying the validatedObservable function instead. ...

The first year I wrote software for a living I spent my days mostly writing forms over data applications; most of my efforts were wasted just trying to make things work using ASP.NET and the Webforms engine. It was only after a year and graduating from the School of Hard Knocks that I learned there is a lot more to building clean and maintainable software than knowing the ins’ and outs’ of a proprietary UI technology. ...

I’ve been doing some work lately which involves sequentially reading large files (> 2 to 5GB). This entails that it’s not an option to read the whole structure in memory; it’s more reliable to process the file in chunks. I occasionally come across legacy that solves exactly this problem, but in a procedural way, resulting in tangled spaghetti. To be honest, the first piece of software I ever wrote in a professional setting also went at it in the wrong way. ...