A lesson in bad exception practice

2017-08-22 by mookid8000 2 Comments

Consider this stack trace from an exception thrown by Entity Framework 6.1.3:

System.InvalidOperationException : Sequence contains no matching element
   at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source, Func`2 predicate)
   at System.Data.Entity.Utilities.DbProviderManifestExtensions.GetStoreTypeFromName(DbProviderManifest providerManifest, String name)
   at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.ConfigureColumn(EdmProperty column, EntityType table, DbProviderManifest providerManifest)
   at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.Configure(EdmProperty column, EntityType table, DbProviderManifest providerManifest, Boolean allowOverride, Boolean fillFromExistingConfiguration)
   at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.<>c__DisplayClass4.<Configure>b__3(Tuple`2 pm)
   at System.Data.Entity.Utilities.IEnumerableExtensions.Each[T](IEnumerable`1 ts, Action`1 action)
   at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.Configure(IEnumerable`1 propertyMappings, DbProviderManifest providerManifest, Boolean allowOverride, Boolean fillFromExistingConfiguration)
   at System.Data.Entity.ModelConfiguration.Configuration.Types.StructuralTypeConfiguration.ConfigurePropertyMappings(IList`1 propertyMappings, DbProviderManifest providerManifest, Boolean allowOverride)
   at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.ConfigurePropertyMappings(DbDatabaseMapping databaseMapping, EntityType entityType, DbProviderManifest providerManifest, Boolean allowOverride)
   at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.Configure(EntityType entityType, DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)
   at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntityTypes(DbDatabaseMapping databaseMapping, ICollection`1 entitySets, DbProviderManifest providerManifest)
   at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)
   at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo)
   at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)
   at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
   at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
   at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
   at System.Data.Entity.Internal.InternalContext.ForceOSpaceLoadingForKnownEntityTypes()
   at System.Data.Entity.DbContext.System.Data.Entity.Infrastructure.IObjectContextAdapter.get_ObjectContext()

System.InvalidOperationException : Sequence contains no matching element

at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source, Func`2 predicate)

at System.Data.Entity.Utilities.DbProviderManifestExtensions.GetStoreTypeFromName(DbProviderManifest providerManifest, String name)

at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.ConfigureColumn(EdmProperty column, EntityType table, DbProviderManifest providerManifest)

at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.Configure(EdmProperty column, EntityType table, DbProviderManifest providerManifest, Boolean allowOverride, Boolean fillFromExistingConfiguration)

at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.<>c__DisplayClass4.<Configure>b__3(Tuple`2 pm)

at System.Data.Entity.Utilities.IEnumerableExtensions.Each[T](IEnumerable`1 ts, Action`1 action)

at System.Data.Entity.ModelConfiguration.Configuration.Properties.Primitive.PrimitivePropertyConfiguration.Configure(IEnumerable`1 propertyMappings, DbProviderManifest providerManifest, Boolean allowOverride, Boolean fillFromExistingConfiguration)

at System.Data.Entity.ModelConfiguration.Configuration.Types.StructuralTypeConfiguration.ConfigurePropertyMappings(IList`1 propertyMappings, DbProviderManifest providerManifest, Boolean allowOverride)

at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.ConfigurePropertyMappings(DbDatabaseMapping databaseMapping, EntityType entityType, DbProviderManifest providerManifest, Boolean allowOverride)

at System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.Configure(EntityType entityType, DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)

at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntityTypes(DbDatabaseMapping databaseMapping, ICollection`1 entitySets, DbProviderManifest providerManifest)

at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest)

at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo)

at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection)

at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)

at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)

at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()

at System.Data.Entity.Internal.InternalContext.ForceOSpaceLoadingForKnownEntityTypes()

at System.Data.Entity.DbContext.System.Data.Entity.Infrastructure.IObjectContextAdapter.get_ObjectContext()

Lucky for me, I know which tiny change I made to the code I am working with to induce the exception, and therefore I am pretty confident that I know what caused it. Had I not been so fortunate, this stack trace would have provided almost no help at all with diagnosing what is actually wrong.

Let’s try and decompile the topmost method, GetStoreTypeFromName, which is the one that apparently calls .Single(..) on a sequence without any matches. It looks like this:

internal static class DbProviderManifestExtensions
{
    public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)
    {
        return providerManifest.GetStoreTypes().Single<PrimitiveType>((Func<PrimitiveType, bool>) (p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase)));
    }
}

internal static class DbProviderManifestExtensions

{

public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)

{

return providerManifest.GetStoreTypes().Single<PrimitiveType>((Func<PrimitiveType, bool>) (p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase)));

}

This, Ladies And Gentlemen, is in my humble opinion almost unforgivable: It is simply not OK to call .Single(..) on stuff without re-throwing the exception along with information on what we were looking for.

A much improved version of the method would have looked like this:

internal static class DbProviderManifestExtensions
{
    public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)
    {
        try
        {
            return providerManifest.GetStoreTypes()
                .Single<PrimitiveType>(p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase));
        }
        catch(Exception exception)
        {
            throw new ArgumentException($"Could not find PrimitiveType named '{name}'", exception);
        }
    }
}

internal static class DbProviderManifestExtensions

{

public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)

{

try

{

return providerManifest.GetStoreTypes()

.Single<PrimitiveType>(p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase));

}

catch(Exception exception)

{

throw new ArgumentException($"Could not find PrimitiveType named '{name}'", exception);

}

this way not losing the original exception, still providing information from the callsite telling the caller what’s wrong.

An even better version of the method would provide me with a list of available “store types”, which often provides some great hints about what is wrong:

internal static class DbProviderManifestExtensions
{
    public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)
    {
        var storeTypes = providerManifest.GetStoreTypes();
        try
        {
            return storeTypes
                .Single<PrimitiveType>(p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase));
        }
        catch(Exception exception)
        {
            throw new ArgumentException($"Could not find PrimitiveType named '{name}' among the following store types: {string.Join(", ", storeTypes.Select(p => $"'{p.Name}'"))}", exception);
        }
    }
}

internal static class DbProviderManifestExtensions

{

public static PrimitiveType GetStoreTypeFromName(this DbProviderManifest providerManifest, string name)

{

var storeTypes = providerManifest.GetStoreTypes();

try

{

return storeTypes

.Single<PrimitiveType>(p => string.Equals(p.Name, name, StringComparison.OrdinalIgnoreCase));

}

catch(Exception exception)

{

throw new ArgumentException($"Could not find PrimitiveType named '{name}' among the following store types: {string.Join(", ", storeTypes.Select(p => $"'{p.Name}'"))}", exception);

}

The next method in the stack trace is called ConfigureColumn, and sadly if you decompile the method, it will be just as cheap with regards to helping us know what was wrong, even though it has all kinds of valuable things to tell us like:

which type was it trying to map
which property could not be mapped
which column in the database was it trying to map to

etc. etc. etc.

Please don’t write code like that.

Rewrite things

2016-11-18 by mookid8000 Leave a comment

There is a piece of advice in the software development world, which is pretty clearly expressed in this blog post by Joel Spolsky. It basically says that you should never rewrite your code from scratch.

I agree with this advice as a general rule to avoid running with the impulse of throwing out what you are working on sometimes, because you might feel like starting over fresh.

poo It could be when new technologies come around, making your legacy system look old-fashioned. It could be when you are sitting there at your job, frustrated and tired of shoveling code turds, trying to understand a legacy system that has had all sorts of bad design decisions implemented in it.

There can be many reasons why one might feel like starting over, because THIS TIME better decisions will be made, and everything will be better.

The reason why this is generally not such a great idea, is that you tend to forget how much work and hard-earned knowledge is actually baked into the systems we maintain. Sometimes, little bug fixes and unit tests of esoteric corner cases are the result of weeks of real-world testing and subsequent reproduction by developers, which is not so easily redone.

While the advice to avoid rewrites makes good sense most of the time, all rules come with exceptions!

At the other end of the scale we find something that is slowly becoming one of my favorite pet peeves: Software developers who go to great lengths to preserve code that they have already written, to avoid having to write it again.

Symptoms include having code repositories, directories of text files, GitHub Gists, maybe even OneNote projects, containing code snippets, which are then consulted or copy/pasted from whenever it is time to build something “new”. Other symptom is when “new” projects are started out by bringing in loads of code files of utilities, helpers, primitives, etc.

skaermbillede-2016-11-18-kl-14-52-39 This type of developer might claim that it helps them “hit the ground running” – but my experience is, that it is more likely to make them HIT THE GROUND WITH A BACKPACK FULL OF BRICKS.

The thing is that this “new” project will not be built with new code or new techniques learned since the last time the developer worked on something greenfield – it will be built with all the OLD knowledge, the OLD techniques, and the OLD technologies.

When you avoid rewriting things by reusing your old code snippets, you are robbing yourself of a great self-improvement opportunity, because you don’t let yourself re-do something that you have already done before with the knowledge that you have accumulated since the last time you did it.

If, on the other hand, you take on rewriting things (often, if not) every time you build something new, even things like trivial CRUDdy coding tasks and other mundane endeavors can end up working like a form of code kata where each repetition can bring a new dimension or new refinements into the solution.

I should probably end this post by saying that I don’t think you should reinvent the wheel – or “invent the soup plate” as we say in Danish 😉 – every single time you need a wheel or a soup plate. Just be observant that you are not missing out on a great, new, improved soup plate, just because you thought that the one you got from your parents when you moved out at 19 was good enough.

PS: After having written this, I saw this post by Dennis Forbes, who seems to share my pet peeve, as he touches on that type of company that treats all of its homegrown code and libraries as an asset, when it is in fact a brick in the backpack. Read his post – it’s much better than mine 🙂

PPS: Inventing wheels and soup plates are terrible analogies to writing software. I will bet you almost anything that you can look at any piece of code you wrote a year ago and come up with several things you would do in a better way if you were to rewrite it. However, if this is not the case, I think you have another problem 🙂

Enter Rebus.fm

2016-01-27 by mookid8000 1 Comment

little_rebusbus2_copy-500x500 Since the inception of Rebus more than four years ago, I have been a happy user of this small messaging library targeted at being intuitively easy and natural to configure and use.

I am not the only one who has been using it, though. Over the course of Rebus’ lifetime I have had contact with several companies who were using it to solve their business problems, and I have always been delighted to hear about both good and bad experiences with it.

Now I have decided to take it to the next level: I will now begin to offer commercial services as a complement to Rebus from my company, Rebus.fm:

rebus.fm logo

Rebus has always been and will continue to be absolutely free and open source (with the MIT license).

This just means that serious Rebus users can receive a higher degree of commitment from me in the form of support and guaranteed bug fixes, and also in the form of supplementary tooling in the future.

This does not mean that I am ending my close cooperation with my employer, d60. We will continue to work together and support each other, which also means that I can welcome d60 as the first “Rebus.fm partner” (but I’ll talk some more about that later…. :o) ).

If this sounds interesting to you, I suggest you go and read some more about Rebus.fm at the Rebus.fm homepage. And don’t hesitate to get in touch if you have questions or comments.

This is how developers might punish your database…

2015-09-08 by mookid8000 Leave a comment

…or “Twisted use cases for SQL Server”, as I also like to call it 🙂

It’s the title of a presentation that I’m doing at this year’s SQL Saturday in Copenhagen on the 19th of September.

The presentation is about how development teams need not despair when faced with the classical and almost ubiquitous constraint that data must be stored in SQL Server…

I’ve created the following state diagram to illustrate what the presentation is about:

sql-server-yes-no

When they said to put data in SQl Server, did they tell you HOW to put data in SQL Server? They didn’t? Cool… let’s talk about that 🙂

Exciting times!

2013-09-11 by mookid8000 Leave a comment

Preface

Back in 2011 I had worked with NServiceBus for a couple of years, and I was very happy about using it. I became sad though, when NSB version 2.5 was announced, because Udi had decided that NServiceBus would go away from the ultra liberal Apache V2 license, to requiring a paid license to use it in production.

I wasn’t sad because I thought that NServiceBus wasn’t worth the money. I was sad because I knew that the money aspect – just the fact that there was a money aspect – would suddenly become a barrier for me to introduce NServiceBus into future small to medium-sized projects.

I also realize that the money aspect was probably the one thing what was missing for NServiceBus to be looked at with greater seriousness by many companies worldwide, so – from a business perspective – I totally understand the move. It just didn’t fit my plans of building cool distributed stuff, made entirely from free frameworks and libraries.

Taking matters into my own hands

Therefore, on September the 11th 2011, I made the initial commit to the Rebus repository and laid the ground for what I wanted to be a kind of “lean NServiceBus little brother”, an NServiceBus stand-in that could be used in small systems until they became serious enough to warrant the license fee.

From the outset, Rebus mimicked NServiceBus’ APIs, and would even be able to read and understand NServiceBus endpoint mappings, so as to make porting systems back and forth between Rebus and NServiceBus easy.

Rebus turned out to be pretty neat though, and it didn’t take many alpha versions before money was suddenly being moved around by Rebus. And a few versions after that, Rebus would help some people control a couple of power plants. At that point, I hadn’t even had the chance to use Rebus to build something real myself, but other people were happily using it to solve their messaging problems.

Today

Fast forward two years, and I’ve helped build several systems with Rebus, and I get to go to conferences and talk about it, and a big part of my daily work is to help my awesome colleagues at d60 build systems using messaging.

All is peace and quiet in Rebus-land, and then – BAM!1 – I get an email from Udi saying something along the lines of: “Have you considered turning to the dark side?” – where Udi invites me to become part of the NServiceBus core team…………!!

I did not see that one coming.

AND like that, I’m in a huge dilemma – because I really love working at d60, and I love my awesome colleagues, and I love the spirit that we have succeeded in building in the company – so it pains me to think that I would no longer be part of the d60 project.

On the other hand, I realize that this an immensely awesome opportunity to

get to work with Udi, whose work I have admired for the last 5 years, and
get to work with some of the most talented .NET developers on the globe to
help building a messaging library, full time, as my day job – a task that I apparently think is fun enough that I will do it while doing the dishes, while sitting up at wee hours, again and again at our monthly hackernights, etc.

Therefore – a tough decision, but an obvious one. So of course I accepted Udi’s invitation!

So how’s that going to happen?

Luckily, d60 have been nice enough to make an agreement that I can start working on NServiceBus right away, ramping up my efforts over the next 6 months while I ramp down my d60 activities. I will not ramp all the way down though: I’ll continue to hang out at the d60 office and help d60 make cool distributed stuff with messaging, participate in brown-bag meetings, etc. I’ll just spend most of the time working with the NServiceBus core team.

But what about Rebus?

There’s no doubt that I will concentrate my efforts on NServiceBus now.

But Rebus still exists! Noone can deny that 🙂 And Rebus has gained traction in places, in big as well as small companies that will most likely NOT readily replace it with something else, so I expect Rebus to continue to be refined and be maintained by its community for a long long time.

I’ve agreed with Asger Hallas, whose contributions to Rebus throughout the last two years have been invaluable, that he will be the new Rebus lead.

Asger has contributed with code in the form of all of Rebus’ RavenDB integration and several improvements, and he has contributed with excellent insights into the technical challenges of building a messaging library, and our lengthy discussions have brought much awesomeness to the table. I can think of no better person to continue the direction in which Rebus is heading.

I’m a Rebus user – should I be worried?

I don’t think so. If Rebus can make your endpoints communicate now, Rebus will still be able to make your endpoints communicate in the future. Rebus has never had an ambition to become bigger than it is right now, so if you’re satisfied now, chances are you’ll be satisfied tomorrow as well.

I’m still gonna be around!

Also: I’m not going away! I’ll still be around for helping out if you have trouble with using Rebus. I have just been given the opportunity to focus on helping a great team improve the most popular .NET service bus framework, which I hope will teach me a lot about messaging and hopefully turn out to be beneficial for NServiceBus as well.

So, please don’t hesitate to contact me if you have any questions regarding Rebus down the road. And in the future, I might be able to answer a few questions about NServiceBus as well 😉

Cheers!

Edit: If you’re interested, check out Udi’s perspective on this.

I am not usually that judgmental

2013-05-06 by mookid8000 Leave a comment

but I did write a blog post called “I judge developers by how many toolbars are showing in their IDE”, which could also have been called “if you reach for the mouse, you are n00b scum to me”.

I wrote the original blog post on how to strip some of the disturbing elements off of Visual Studio and get started using the keyboard for navigation because I was frustrated when I saw colleagues helplessly wiggle the mouse around and try to click small pathetic buttons among hundreds of other buttons in huge menu bars in integrated development environments…

So, today I got a tip from Brendan J. Baker who suggested I install the “Hide Main Menu” VSIX and get an auto-collapsing menu bar! Pretty cool, actually – it shows up again when you hit Alt, just like you expect it to after having used the keyboard for navigating Sublime all day.

The menu bar might not take up a lot of space, but it’s still 30 px in the expensive direction, at the entire width of the screen, holding a BUNCH OF YELLED WORDS – but most of all, it’s clutter!

Thanks, Brendan – you made my Visual Studio even more clean and good looking 🙂

2012 retrospective and 2013 resolutions

2013-01-01 by mookid8000 Leave a comment

Just like I’ve done the previous two year, I’ll spend a blog post summing up my experiences for the past year and possibly try to think about what I’d like to do the next year. Here goes…:

This is what happened to me in 2012 in random order – I:

Started in my new position as a software development consultant at d60 – I spent the first three months helping out in a financial company that needed to reach a hard deadline, and the next three months I went back and helped out on the PowerHub project – and then, afterwards, I began working as an architect on d60’s trading systems. Starting at d60 has been absolutely awesome, and it’s really exciting to be part of the rapid growth of what still feels like a small company.
Helped introduce Rebus on several projects, my own as well as other peoples’ – at the moment, Rebus moves money around, controls a couple of power plants, and hopefully makes the lives of a few software developers even more enjoyable 😉
Took Rebus+MongoDB to production – a match that I’ve often thought was made in heaven (even though I know that the match was made at a Hackernight, or while I was doing the dishes at home, some time in early 2012…)
Attended Software Passion Summit in Göteborg where I did a presentation on MongoDB.
Attended Miracle Open World 2012 where I presented on MongoDB and NServiceBus.
Gave my first presentation on Rebus at Community Day in Copenhagen.
Attended GOTO Aarhus where I met a lot of my awesome ex-colleagues from Trifork.
Gave user group talks on Rebus at ONUG, CNUG, and ANUG.
Did a Rebus code camp at ANUG that featured a Columbian drug lord and loads of drugs & money.
Was awarded as a “Microsoft C# Most Valuable Professional” on the 1st of April – I still sometimes wonder whether someone just played an April Fool’s prank on me 😉

My theme for 2012 has definitely been “Rebus” almost all the time, and I really hope to continue being able to work with Rebus – at work as well as in my spare time.

Here’s my plans for 2013 – I’d like to:

Do some presentations on Rebus to continue spreading the word and build even more inertia – first one is already planned: Taking The Hippie Bus To The Enterprise.
Go bump Rebus’ version to 1.0 (mostly some configuration options missing).
Gain some experience with breaking down our trading system, which is being developed by a team of more than 20 people, into a service-oriented architecture that respects the bounded contexts.
Get some experience operating MongoDB as it grows.
Build something with HTML5.
Hopefully get the MVP award again, although I haven’t done a single thing with this in mind – all of my activities are purely driven by me wanting to do stuff I think is fun.
Learn, learn, learn!

happynewyear27 As usual, I like that the theme of my new year’s resolutions is mostly about expanding my horizon, although I realize that I’m pretty stuck in .NET country. It’s still a really interesting place to be, though, with a lot of interesting things happening, and I like that .NET developers in general seem to be really open towards getting inspiration from stuff that’s happening in the other camps.

Now, as we approach the end, please enjoy this animated gif of an extremely cute and cuddly bear that wishes you and your loved ones a happy new year!

I’ll be speaking at Warm Crocodile Developer Conference

2012-11-28 by mookid8000 Leave a comment

In Copenhagen, on the 16th and 17th of January, there’s a new conference called Warm Crocodile – pretty cool title, if you ask me!

I begged and begged, until they caved in and gave me an hour of their otherwise extremely cool schedule – so I’ll be giving a talk that I’ve dubbed “Taking the hippie bus to the enterprise”… it will most likely be about using a free .NET service bus in combination with other cool free software to rapidly solve enterprisey problems without feeling a lot of pain.

If you’re interested, you can read the full abstract here: Taking the hippie bus to the enterprise

Why do all NoSQL discussions end up discussing CAP?

2012-10-01 by mookid8000 Leave a comment

Having watched an equally interesting and entertaining panel discussion, “The Aarhus 6”, at GOTO Aarhus, it strikes me – again! – as weird and funny that NoSQL discussions almost always seem to end up discussing performance and availability.

In my experience – and Martin Fowler actually noted this towards the end – most development teams and organizations don’t care about the availability of their database. Not as in “don’t care at all”, but as in “availability demands are so that an ordinary OPS team can make the database sufficiently available”.

In other words, almost no organizations need five nines, four nines, or something like that. Most organizations, if they’re honest and don’t pretend to be more important than they are, probably don’t even need two nines!

Thinking about this, it’s funny that the discussions almost never discuss how easy the databases are to get started with, and how easy it is to store data in them. Matt Dennis even managed to talk almost for his entire 50 minutes in his “Big Data OLTP with Apache Cassandra” without touching on how data is actually stored in Cassandra. It’s only because someone in the audience asked about it, that he said the word “column family”.

Chris Anderson did at some point however, comment that “the winner” (i.e. the NoSQL database that development teams will end up choosing), might be selected “because it’s easy to install”.

This is actually spot on, in my opinion! I think most development teams are better off prioritizing ease of installation and operation, and ease of usage, far far over operational quality attributes like insane scalability and availability.

Developing .NET applications very rapidly

2012-09-07 by mookid8000 Leave a comment

In my current position as an agile .NET dude at d60, I have already found myself in need of rapidly building several small applications and services from scratch.

This way of working reminds me a lot about some of the things that Dan North talked about in his “From months to minutes – upping the stakes” talk at GOTO Aarhus 2010.

In the talk, Dan described how he was part of a team that would rapidly prototype and deliver working systems to some stock exchange or something, and in doing this they would often start from scratch and replace the existing applications, instead of adapting old ones. The advantage is that you get to take some shortcuts when you’re making fairly short-lived applications, you don’t have to carry the burden of old legacy crap, you get to re-do, possibly undo(?) almost every decision some time, and you become really good at building stuff from scratch!

So, this is cool, and I think he said a lot of things that really make sense. But how can you build stuff very rapidly when you’re a .NET developer in a Microsoft shop, and your customer has based everything on Microsoft technology? You would think that a .NET developer would be slow compared to the hip coders working with Node.js, Clojure and [insert hip new technology here]…?

Well, it just so happens that .NET developers are actually pretty lucky in that regard. In this post, I’d just like to go through a few of the things that enable us to deliver stuff really quickly, both .NET and not-necessarily-.NET-things.

Git and GitHub

Like all sensible coding teams, we have moved to distributed source control. We have some pretty skilled Git-people among our developers, so Git was the natural choice. And since we’re not really interested in maintaining our own servers, it makes the most sense to have some hosted Git repositories somewhere – and for that, we got a company account at GitHub, because it’s a great place to host Git repositories.

Git’s branching model is just so extremely fast and lightweight that I’m wondering how I ever managed to get anything done in Subversion. Well, I guess I just didn’t update & commit that often then.

Is anyone still using Subversion? Why?

TeamCity

We have our own locally hosted TeamCity server to check out our code from GitHub, build it, run tests, create NuGet packages etc. Configuring and maintaining TeamCity is really easy compared to CruiseControl.NET, which I used to use – and with the extremely cool feature branch support of TeamCity 7.1, our build server will automatically check out, build, and test my branch if I name it feature-whatever_I_am_working_on when I push it to GitHub!

NuGet

When you want to build stuff rapidly in .NET, there’s really no way you can ignore NuGet – this is how we get to quickly pull down all of the open source libraries and frameworks that we’re using to build cool stuff.

In addition to the free open source stuff, we also NuGet-pack all of our purchased libraries if they’re not already in a .nupkg. And finally, we pack our own shared libraries as NuGet packages as well (actually, TeamCity does this for us automatically on every successful build…), which is how we distribute shared assemblies like e.g. assemblies with Rebus messages.

NuGet has been really easy and smooth in this regard. I’m sorry that I never tried OpenWrap, though – I’m wondering if anyone is using that, or if everybody has moved to NuGet?

Our own NuGet package repository

In order to reduce the friction with NuGet, we have our own NuGet package repository. NuGet.org is just damn slow, and it doesn’t host all of our 3rd party and home-rolled packages.

At first, we used TeamCity to do this, but the NuGet extension in Visual Studio doesn’t remember your credentials, so you have to constantly punch in your username and password if you’ve enabled authentication. This was just too tedious.

Then we hosted our own stand-alone NuGet Server, which would have been OK if it weren’t for the fact that we’re often working outside of our office, and often on other companies’ VPNs. This doesn’t go well with a privately hosted NuGet server.

But then someone had the crazy idea that we should use DropBox as our NuGet repository! This is as crazy as it is ingenious, because we’re already using DropBox to share documents and stuff, so it didn’t really require anything to just throw all of our NuGet packages into a shared folder… which is what TeamCity also does whenever it has packed up something for us, immediately synchronizing the new package to everyone who’s connected to a network.

This way, we can always get to include our NuGet packages, even when we’re building new stuff on a train with a flaky internet connection. As I said: Crazy, yet ingenious!

Free choice of frameworks and tools

Last, but not least, I think a key to rapidly building stuff is to free developers’ hands so that they can use the tools they like to use best and feel are best for the given task.

It seems many companies are afraid that developers might pollute their applications with questionable libraries and bad decisions, but my feeling is that most developers are totally capable of handling this freedom and will respond with a sense of responsibility and care.

Conclusion

These were a couple of things that I could think of that help us build cool stuff and deliver often. As I may have already insinuated, I’m not sure this way of working would work on large monolithic applications that must live for very long.

But then again, in my experience many systems live for too long because they’ve become too huge, and thus too big and expensive to replace – it is often very healthy for systems to be divided into smaller applications that are well integrated, but each application in itself is fairly small and decoupled and thus doesn’t constitute a huge risk and equally huge endavour to replace.