Posts

When I started my first job, I hardly ever judged my peers. After all, how could I? Everything was unknown for me; I couldn’t differentiate good from bad. Over the years that has changed a bit, but with that, I’ve also slowly become more judgemental towards peers, often prematurely, and not always deservedly. The first few months of last year, I found myself doing maintenance on a legacy code base between projects. While I worked my way through layer after layer, I pointed my frustration towards those that had come before me; they were responsible for putting me in this mess. With half the office having touched the code base, that didn’t really add up though. When I looked at the commit history of some of the offending modules, I found names that I didn’t expect; those people were still around, and I actually thought of them pretty highly. ...

I’ve explored quite a few options on how to handle commands and queries in the last few posts. I finally settled on this approach. The example used in that post looked like this. public class CreateSubscriptionCommandHandler : ICommandHandler<CreateSubscriptionCommand> { private IDocumentSession _session; public CreateSubscriptionCommandHandler(IDocumentSession session) { _session = session; } public void Handle(CreateSubscriptionCommand command) { var subscription = new Documents.Subscription( command.Value, command.Category, command.EmailAddress); _session.Store(subscription); } } Now imagine I would want to do some extra stuff after creating the subscription; update the sales statistics, append the email address to a mailing list, send out a confirmation email, etc.. ...

In the last few posts I settled on an architecture for handling commands and queries. A byproduct of the described approach, is that your codebase quickly racks up plentiful little classes; a class to hold data, and a handler to act on that data, for each use case. There are a few ways you can go at organizing things. Everything in one location When there is very little going on in your application, you can just dump everything in one location without getting hurt too much. ...

I never stub or mock the database when I’m using RavenDB. Generally, I use an embeddable documentstore running in memory, and initialize a new instance on every test. However, I like to run some stress tests against a real instance, and here I found myself wanting to wipe clean the state of previous tests, without having to create a new database (which is rather slow). First I create the default DocumentsByEntityName index to make sure it’s there - it normally gets created when you open the studio for the first time. Then I use one of the advanced database commands: DeleteByIndex, and query all the tags. ...

In my first post on this topic, I started out with an attempt to limit abstractions to solely commands and queries. Commands and queries were self-contained and could be invoked by passing them to a context-providing generic handler. The drawback of this approach was that it made constructor dependency injection impossible. In a next post, I separated data from logic, but never got around to writing a dispatcher that associates command data with their handlers. Last week, I revisited the first approach, and added an unconventional implementation of injecting dependencies by an Inject method convention. ...

Also read: separating command data from logic and sending it on a bus In October I looked at an architecture that limits abstractions to solely commands and queries. In that post, I had some infrastructure that looked like this. public abstract class Command { public abstract void Execute(); } public abstract class Query<T> { public abstract T Execute(); } public interface ICommandHandler { void Execute(Command command); } public class CommandHandler : ICommandHandler { public void Execute(Command command) { command.Execute(); } } public interface IQueryHandler { T Execute<T>(Query<T> query); } public class QueryHandler : IQueryHandler { public T Execute<T>(Query<T> query) { return query.Execute(); } } Commands and queries are both accompanied by their specific handler. In this example, the handler does nothing but invoking the command or query. In reality, you want your handlers to do a little more. For example: provide the commands and queries with a context to work with, add logging, handle your unit of work and all of that good stuff. ...

It’s that time of the year again where I take some time to look back on the year passed and peek at the year ahead. This is mostly a post I like to write up for myself, forcing reflection. The biggest personal changes this year were moving out of my parents’ place, and my girlfriend’s decision to study medicine after graduating as a Master of Arts earlier this year. I had no idea how things would turn out once we lived together, but so far we have been doing great. ...

I look forward to writing this post each year; it’s by far the easiest one to write, and it provides me with an occasion to look back on previous years (2009, 2010, 2011). It’s entertaining - and shameful too - to see what kept me busy back then, which opinions I held, and which technologies and techniques are still relevant in the meanwhile. Anyways, here it goes. The most read post this year, with 37.797 page views, is How a web application can download and store over 2GB without you even knowing it. I just ran this experiment again with the latest Chrome build, and apparently the Chrome team hasn’t addressed these concerns in the meanwhile; the browser still behaves exactly the same. I’m guessing usage stats might prove that it’s not worth the effort. ...

I recently watched a talk on Vimeo where Christin Gorman talks about how cookie dough relates to Hibernate; why use the generic, bloated and one-fits-all solution when you can mix together your own yummy cookie dough? We should aspire to be the Gordon Ramsey of software, not the college student who can only cook Ramen noodles. If you haven’t watched or listened to her talk, you should; it’s only a few minutes long, and she brings it really well. Go ahead, I’ll wait. ...

A few weeks back, I spent an intensive day performance tuning parts of a, to me, relatively unfamiliar part of our codebase. Like it often is, the biggest optimizations were to be found in how we work with the database. Now, I don’t consider myself to be an NHibernate expert; I read this book and have used it on two projects, but in the end I just do my best to avoid doing stupid things with it. The topics discussed below are mostly common knowledge for long time NHibernate users, but I thought it might be convenient for others to just summarize them, and add references to other, more in-detail, posts. ...