Working with Entity Framework Code First and SQL Bulk Copy

There's a few of these that I haven't written, but it seems that you could keep a blog going pretty well with just "Working with Entity Framework and ..." posts. That's not because Entity Framework is particularly bad, I really quite like it myself, but because if you're writing an application of any considerable size or complexity you will at some point reach the limitations of what is possible "out of the box". I'm also aware of the number of "ORMs are evil" posts circulating currently, and possibly you're someone who thinks the same, but for what I'm working on now they make perfect sense, and I'm all for using the right tool for the job.

So what's the problem this time?

General purpose ORMs are great when you're working with transactions, it's what they're meant for.  A user interacts with the system and you need to persist the data from their most recent transaction.  The problem this time is that as the system grows you suddenly find yourself with a couple of use cases where you need to persist a lot of data.  In the example application I've put together for this post I'm using an XML data source with 10,000 records which need to be persisted.

The problem here is that when running with this size data set (with auto-tracking changes disabled) is that it is taking around 40 seconds to run.  10,000 records in 40 seconds is certainly more that I can process manually but for a modern computer it's not so great.  The problem is that as you're adding more records to the context it's getting bloated, it has to start tracking more and more entities, then each entity is persisted individually.  That last point is important because each insert in Entity Framework inserts the new record and then pulls back out the newly created ID code and updates the entity in memory with the new ID code, which is not a trivial amount of work.

So what are the solutions?

Disable features: The first thing to check is that you are telling the context to not auto-track changes, it's a small thing but you're giving the context less work to do, performance isn't about making your code faster, it's about making it do less.

If you were to run this again you would find that you've taken a few seconds of the total run time, which is better but it's still no where near fast enough.

Commit early, commit often: A fairly obvious option but rather than waiting until we've attached all of the entities to the context before saving, save more frequently (e.g. every 100 entities).  Again this is reducing the amount of work the context is having to perform when it figures out which entities it needs to persist and makes a more significant impact in our figures, but it's still got a way to go.

You might also remember that I mentioned about the context getting bloated, well we can do something about that as well by re-creating the context after each time we save the changes.  This stops the context from getting too bloated and again reduces the amount of effort needed to work out which entities need to be persisted.  We've added in some work now for context initialisation but this is typically cheaper.  This does take a bit more effort to maintain and ensure that we're not breaking the system by doing anything stupid, but it again takes a bit more of a chunk out of the run time.

Get to the DbSet differently: The typical route to adding an entity is to add it to the contexts DbSet collection.  Bizarrely this collection doesn't have an AddRange method, but there is a way to get at one by asking the context for the set directly.  By adding the entities using the AddRange method we can skip all of the tedious foreach looping and adding the entities one at a time.  So we can now make a simple call to AddRange followed by a call to SaveChanges, this is much more performant than the previous solutions, getting down to some slightly more reasonable numbers.

But what about SQL Bulk Copy?

So the title of the post is about bulk copying, and having read through the above you're probably wondering why I didn't just jump to this as a solution.  Well, Entity Framework has no out of the box support for SQL Bulk Copy because it's database agnostic.  But I've done this before when working with SQL FILESTREAM so why can't I do it again?

Being a lazy developer the first thing I did was look for an existing solution and one turned up in the shape of EntityFramework.BulkInsert.  It seems pretty popular online for this kind of a problem, is available through NuGet and is pretty easy to use.  After adding the package and creating a method to try it out I ran the sample application and waited for it to finish.  It took me a while before I realised that it already had!  For 10,000 records it ran in under 1 second.

So surely EntityFramework.BulkInsert is the answer then?  Well if you want to stop reading here and go and download it then please do, it's a great little package.  Naturally there are a few things that you need to take into consideration.  First of all bulk copying doesn't bring the ID codes back, so if you need the values you will have to think of a way around this (think SQL 2012 sequences and sp_sequence_get_range).  Next you have to think about how bulk copying works and make sure you get the bulk copy options correct.  By default it won't check any constraints you have in place and it might not observe NULL values, instead putting in default values for the column type.  It also works within its own transaction (unless you provide a TransactionScope), but if you can work around these then you have a great little solution in your hands.

SQL Bulk Copy

I'm a lazy developer but I'm also a fascinated one, I wanted to know if I could still write the code using the System.Data.SqlClient.SqlBulkCopy class instead of relying on 3rd party packages or falling back to ADO.NET (which is an option, but not one I'm going to cover).

I already know that I can get the connection information from the context, and I've previously shown how to get the mapped table name for a given entity, so surely this is possible.  But I am going to be a little bit lazy and not implement an IDataReader for my collection, instead I'm going to load the entities into a DataTable and use that (note, this option really isn't going to scale well).

This is actually a fairly easy solution to implement with probably the most complicated piece being a fairly simple extension method which pulls out the entity properties and their types, then using this to create a DataTable and copy the data using reflection (again, this isn't going to scale well).  Once you have that you just need to write the data to the database for your chosen batch size.

This solution isn't quite as fast as the EntityFramework.BulkInsert component, mostly for the reasons I mention, but it can still persist 100,000 records in about 1 second.

I've created a project which is available on GitHub under an MIT license for you to grab and look at.  I've done this because the code isn't really that difficult to follow and is pretty similar to my previous post on SQL FILESTREAM and me talking through lines of code is boring.  Also available is a LinqPad file which I used to create the input data files, just change the number of entities and run it.  But for convenience I've added a 1,000 and 10,000 entity files into the project anyway.

Working with Entity Framework Code First and SQL FILESTREAM

Whilst looking around at these two technologies I couldn't find any information which was particularly useful about how to get the solution working.  So I wanted to put this up so that should anyone else want to try something similar then there's some (hopefully) useful information out there.

What am I trying to do?

The system that I am involved with at the moment has the need to store files with some of it's entities.  We've started out by using Entity Framework 5 Code First (although in this post I'll be working with Entity Framework 6) to create the data model and database mappings which is working nicely and is proving itself a very useful framework.

When looking at saving file data along with an entity there are a few choices:

1. Store the file contents directly in the database
2. Save the file contents to the file system
3. Use a database table with FILESTREAM enabled
4. Use a FILETABLE

The first option is fine for small files, but I don't really want to load all of the file data each time I query the table and the files might get pretty big.

The next option is a reasonable option and with recent versions of Windows Server we have a transactional file system.  So far so good, but it would be nice to not have to think about two persistence mechanisms.

FILESTREAMs were introduced in SQL Server 2008 and allow you to store unstructured data on the file system, so it feels like we're using the right tools for the job but they're all nicely in the same package.  The problem here is that Entity Framework doesn't support FILESTREAM.

Lastly there's FILETABLE which was introduced with SQL Server 2012.  This is like FILESTREAM, but rather than defining it at a column level you get a table created for you which provides information from the file system.  It is a really nice system, but it didn't quite fit with how we're structuring data and it's also not supported by Entity Framework.

So the option that I would ideally like to work with here is the FILESTREAM option as it gives me all of the database goodness but with the performance of the file system.  But there is just that minor sticking point of it not being supported by Entity Framework.  After a fair amount of playing around with the technology and research into the problem I figured that I could probably make it work by falling back to basic ADO.NET for handling the FILESTREAM part of the requests.  Whilst this was an option I didn't really want to start having different technology choices for doing database work, so the goal was to see how much I could get away with in Entity Framework.

Setting up the test solution

The database server

With SQL Server the default install options will not give you a FILESTREAM enabled server but you can enable it.  I'm not going to go into how with this post as Microsoft have some pretty good documentation available on how to do this.

This also means that we can't let Entity Framework create the database for us, so you will need to create an empty, FILESTREAM enabled database and point to that.

The outline of the project

I created the solution in Visual Studio 2013, and delving into the most creative parts of my mind I came up with a solution that has hotels, with rooms and multiple pictures of each room (okay, not my most creative moment, but it gets the job done).

So in this solution I have my data model which is pretty simple.  I have some locations, at each location there are a number of hotels, each hotel has rooms and each room has photos.

Solution Data Model

Of all of these the import one is Photo.  This entity has some basic properties, Title and Description, which describe the photo, then there's the navigation properties for getting back to the room and then lastly there's the Data property which is intended to hold the content of the file.  Normally Entity Framework would see this property and it's type (a byte array) and map it to an appropriately named column of type VARBINARY(max).  Whilst we could still let it do this, it would somewhat defeat the purpose of the exercise as we'd be storing the contents of the file directly in the database, so we need to add some configuration to tell Entity Framework to ignore this property when mapping.

Photo entity configuration

I'm using the Fluent API here, but you should be able to do this using Data Annotations as well.

At this point if we were to deploy the database we would get a table with no data information and a blank property in our entity.  What we need to do next before any of this is useful is to somehow get a FILESTREAM column into the Photo table.  The solution to this is to use Entity Framework migrations, the basics of which I'll not cover here and leave it as an exercise to the reader.

Migrations provides us with a migration class for each migration added to uplift and roll-back the changes to the database.  The useful method for us in this class is the Sql method which allows us to execute SQL commands; using this we can add our ROWGUID column and our FILESTREAM column with all the constraints we need (and of course the appropriate commands to remove it all again as well for the Down method).

Migrations SQL commands

Now if we run the Update-Database command from the Package Manager Console we get a table with all the right columns of the right types for being able to use FILESTREAM.

So that's half the battle won, the next challenge is being able to read to and write from the table.

Storing and retrieving file data

So how do we query data in a FILESTREAM column?  Well this is the bit where we fall back to the System.Data.SqlTypes namespace, specifically the SqlFileStream class.  We use this class to read the contents of the file back from the server as a stream, but this only works in the context of a SQL transaction.

So the first thing we need to do is get the file path and the SQL transaction information, we can then pass this to the SqlFileStream constructor to get our stream, after which it's just a case of reading from the byte array in our entity and writing to the SqlFileStream stream.  To get this information we need to run a custom SQL statement.  We could do this using a SqlCommand object, but I still want to stick to Entity Framework a bit more, fortunately there's the DbContext.Database.SqlQuery<TElement> class which we can use to run raw SQL statements, it also handles parameters so we can parametrize the query (great for guarding against SQL injection attacks) and it an enumerable collection mapped to TElement (which does not have to be a part of our data model).

Raw Data Query

The FileStreamRowData class here is a custom class with a string property for the path, and a byte array for the transaction context.

Running all of this inside of a transaction scope will get information required (the call to "First" will enumerate the collection) to pass to the SqlFileStream constructor, we can then use this to write data to the stream.

Writing to the FILESTREAM

The same applies when writing to the database as well, but with the source and destination reversed.  Also when writing to the database you would need to save the entity first.  Wrapping up the Entity Framework bit in the same transaction scope means that even if you call "SaveChanges" on your context, if the transaction does not successfully complete then the changes are stilled rolled back.

So does it work?

Well, yes it does, and it works pretty nicely as well.  It's maybe not the final solution that I'll use as I'm still investigating a couple of other options, but it's certainly not a solution that I would be upset at using, and by hiding the complexity in the data services the client need never know how the file information is being held in the database or using which technologies.

How do I play with it?

You could probably work most of what you need out from this post, but for convenience sake I've also put up the whole solution onto GitHub, so feel free to head over and take a look.  If you come up with any suggestions or improvements then feel free to contribute.

Playing with CoffeeScript

I've recently been playing around with CoffeeScript lately, and as I have a tendency to do I decided to crack open a prime number challenge and see what the solution looked like.

The Challenge

I recently set this up as a challenge at work as a bit of fun which goes as follows.

"Calculate the first 10,000 prime numbers, output the largest prime number and the sum of all palindromic primes"

I've implemented the solution a number of times using C#, C++, Python, Go and JavaScript and it is the latter that I wanted to compare the solution to.  The JavaScript solution I created typically ran in about 15ms after a fair amount of tweaking and profiling to squeeze as much out of it as I could do (within my own abilities).

In all I found writing the solution a pleasant experience, with a very simple and expressive syntax which abstracts away some of the ugliness that is JavaScript (not that I particularly dislike JavaScript, it's quite fun actually).  List comprehensions were incredibly useful and powerful as they are in other languages and writing iterations and checks were very simple.

Anyway, here's my solution.  I'm sure it's not perfect, and there are probably some CoffeeScript tricks that I've not picked up yet.  But the solution is as fast as my JavaScript implementation and much easier to read, so all positives in my book :)

My JavaScript solution along with a couple of others is available on the gist as well.



EDIT: Since posting this I tweaked the solution a little bit after noticing that I was evaluating all of the values in the array of candidates, instead of working only up to the square root of the upper value

Living in a "dynamic" C# world

Taking a brief break from the C++11 posts (I'm working on the next one, I promise), I thought I'd quickly cover a small problem I came up against in C# and how something I'd previously dismissed really helped me out.  If you want to try out any of the code below I'd strongly recommend looking at LinqPad which is a great tool for trying out sample code, expressions and for querying your databases using Linq.

I can't remember the number of times I've looked at the new "dynamic" keyword and thought of it as ugly, and I will admit that maybe I've not been it's greatest advocate.  Recently however I went on a training course during which we spent some time calling IronPython scripts from C#, so I could see a use for dynamic, but not so much outside of this use-case.

Today however I encountered a problem and the dynamic keyword came to my rescue.  The problem was this; I'm loading in data from an XML document (and no, XML is not my problem), this document has a number of sections which identify how to check something from another document, so it might have an entry which says "You're expecting a value in a field called 'x' of type 'y' and I want to check it like this...".  So as an example, say I'm picking up a value which is a double precision value, and I want to check it against another value of the same type but using a tolerance.  So if 's' is my source value, 'x' is my expected value and 't' is my delta then I would want to check it using the following:

// |s - x| < t
var s = 1.0005;
var x = 1.0004;
var t = 1.0001;

return Math.Abs(s - x) < t;

Great, but here's the problem, when I'm writing the code the function first needs to check the type and convert it from a string value to the correct type, which I only know about because the type is held in another variable.  Again, not too tricky as I can just write the following (where "type" is a Type variable holding the type I need to use):

var convertedValue = Convert.ChangeType(s, type);

The compiler has no problem with this and lets me carry on my merry way, but when I add the following line the compiler starts to shout and tells me I'm an idiot for even attempting to apply an operand of "-" to a type of "object" and "object"!

var sourceValue = "1.0005";
var expectedValue = "1.0004";
var tolerance = 1.0001;
var type = typeof(double);

var convertedSource = Convert.ChangeType(sourceValue, type);
var convertedExpected = Convert.ChangeType(expectedValue, type);
var result = Math.Abs(convertedSource - convertedExpected) < tolerance;

Console.WriteLine(result);

The thing is, I know that my converted values are doubles but I need to tell the compiler that I know what I'm doing here and it can compile this.  Well this is where "dynamic" comes to save the day, it allows me to bypass compile-time type checking and instead have this checked at run-time.  So changing the code to the following:

var sourceValue = "1.0005";
var expectedValue = "1.0004";
var tolerance = 1.0001;
var type = typeof(double);

dynamic convertedSource = Convert.ChangeType(sourceValue, type);
dynamic convertedExpected = Convert.ChangeType(expectedValue, type);
var result = Math.Abs(convertedSource - convertedExpected) < tolerance;

Console.WriteLine(result);

I get the expected result of "True" when I run the code.

I know there are probably other ways of doing this, and the example code I've presented doesn't exactly portray the complexity I was attempting to deal with, but I do think it's quite a nice little solution.  Hopefully after reading this you might also re-consider looking at the "dynamic" keyword, you never know when you might have a genuine use for it.


This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Thoughts on open-source development methods (and congratulations to Ubuntu)

First of all I want to say congratulations and thank you to all of the people at Canonical and in the Ubuntu community for all of their hard work in getting out the latest release of the Ubuntu Linux distribution.  Despite all of the criticism the distribution comes under from time-to-time these people strive hard to put out a new version every 6 months.

When you think about their achievement you soon come to realise it's no small feat that they have pulled off, bringing together the best-of-breed free and open-source applications into an easy to install and use distribution readily available to the entire world for free.  It becomes even more amazing when you consider that the people working on the projects are spread all over the world, even the teams working on a single feature might be spread across multiple countries perhaps only meeting in person a few times a year.  The same is true of many free and open-source projects where there may be hundreds, if not thousands, of contributors to a single project spread around the globe.  And yet the projects comes together and produce incredible results, such as the Linux kernel itself which powers so many of the devices and much of the infrastructure we use each day without realising, the chances are that you have at least one gadget in your house powered by the Linux kernel.

The main reason I find all of this amazing and why I felt compelled to blog about it is because, following the very recent release of Ubuntu 11.04 (Natty Narwhal), is because of this geographic spread of developers, document writers, testers, packagers etc... and my own experiences of working in teams within a corporate environment.  I have worked in a number of places now where people have found it difficult (if not impossible) to work with people who are not sat immediately within the same vicinity as them.  Where projects have been delayed and delivered late because people have had difficulties in working across time zones, and in a few instances where people have been in different offices in the same building.  So I suppose I'm curious as to why people working with free software all over the globe can meet these 6 monthly deadlines with amazing frequency and yet companies with money to throw at the same or similar problem have so much trouble!

I have seen a few problems in corporate environments which are often quickly overcome by open-source companies and communities, but I'm sure that these are not the only problems.

The first is often something as simple as choice of version control system.  Whereas the recent adoption of distributed systems such as Git and Bazaar in the open-source world has allowed people to work within a project more efficiently companies I have worked in seem to stick to and prefer the older check-out, check-in systems such as SourceSafe.  This type of system, although easier to understand by inexperienced developers, is often slower and imposes bottle necks on development process, whereas using a distributed system allows users to work remotely without requiring constant access to a centralised server meaning that the developer only requires access to main branch when retrieving a revision and finally merging changes.

A second problem I've often seen is one of communication.  Often in corporate environments communications in teams is limited to office chat, email or meetings, the problem here is that chat often excludes a large number of the team, email is limited to the people on the To and CC list and meetings are more often restricted to a single geographical location.  These factors typically lead to large numbers of team members becoming excluded from conversations and vital information, some companies try to limit this by creating procedures for disseminating information but these are not always followed (lets be honest, most of us despise more procedure!).  In open-source conversations take place in the open, normally using social systems such as blogs, microblogging, mailing lists, wikis and internet chat, other systems such as mumble are also being adopted for having open meetings over the internet where anyone can join in.  Typically a project will let contributors know which are the preferred methods for keeping up to date with project information and developments and which channels are preferred for informal chats.

Whilst I do not think that open-source development methods are perfect, I do believe that there is a lot companies can learn from them if they are willing to break away from traditional models.  Perhaps if they do then maybe they to can hit deadlines repeatedly and successfully in the same way many open source projects do.

Catching Up #1

Well it's been a fun couple of weeks so I thought I'd quickly jot down what's been happening here and what I've been getting up to.

Last week I started working on the kitchen, well I really started the week before but that was only a small amount of preparation.  Last week the gloves came off and we managed to get most of the kitchen out, walls and all.  Currently we still have a sink and the free-standing gas oven left in but that's it, so we're mostly living out of the back room and plastic boxes.  Tyler thinks it's great as all the fun toys like the measuring jugs which were behind locked doors are now in reach.  He's actually been a very good boy whilst we've been decorating and unusually for him has been happy to sit and watch!

There have been a few fun moments such as blowing the upstairs lighting circuit fuse after we found out that the previous occupants had wired in a 13 amp socket to it!  Cables barely below the surface of the walls, plaster falling off with the wallpaper and we even found the old door from the front room to the kitchen which hadn't been covered up properly.  That's all sorted now and the plasterers have done a good job in levelling out the two problem walls.  So now all we need to do is:

• Fit the new units on one side
• Get rid of the sink unit on the other side and install the new units there
• Replace the boxing
• Buy and fit new appliances
• Replace the lighting
• Decorate

Sounds like a lot but now the room is looking better as a shell it seems doable.

When I've had a few moments and not been reading (love my Kindle by the way, post coming soon) I've been trying out the Vala (and here) programming language.  It's syntax is very close to C# but instead of compiling to assembler or another intermediate language it compiles to C and is then compiled with the platforms standard C compiler, so you get the bonus of not having to worry so much about memory management and benefit from a more modern programming syntax but you also get the performance benefits of a natively compiled C application.

Hopefully when I've spent a bit more time with it I'll be able to do another post about it.  In the mean time if you want to see what it's capable of I'd strongly recommend checking out applications like Shotwell which is a photo manager for Gnome which is written in Vala.  It's very cool and is coming on very quickly.

Other than that it's been pretty much the same, but I'm hoping to try and post a bit more frequently here so keep checking back to see what else is going on.  Alternatively subscribe to the feed and keep up to date from the comfort of your favourite news aggregator, personally I'm a fan of Google Reader but that's because it fits nicely with my Android phone.

Staying in the game

One of my biggest concerns as a developer (and I have quite a few) is being able to stay relevant.  This doesn't necessarily mean making myself the only go-to-guy for a project or getting upset when I'm not invited to meetings but staying relevant as an experienced developer.

So to stay relevant what do I need to do?

Well the first thing is to keep my existing skill-set up-to-date, calling myself a .NET developer is all well and good but if I only know about version 1.1 and not 2, 3, 3.5 and 4 then how useful am I and how am I able to help influence technical direction if I don't know about what's new!

Next is a harsh one, but necessary.  Know when to move on from an existing skill.  I know we all feel comfortable with what we know but if you're a C++ programmer and there are no C++ based programmes left to maintain or write then should you spend as much - if any - time investing in those skills.  I'm not saying forget about them, and from time-to-time it's nice to come back and brush up a little but sticking with it as a core skill means you'll be slowly phased out like the programmes you maintain.

Try to keep up-to-date with new theories and practices.  Some times people do re-invent the wheel and sometimes it's a good thing, maybe it's a new design pattern or a new way of looking at threading; but knowing about these can help make you a better programmer.

Keep your eye on the horizon.  Sounds a little managerial I know but looking at what's coming up is really useful as it will help to figure out where you should be spending your time.  Maybe looking at a new language instead of an entrenched one will help with a new product or problem that you know is coming up, or maybe it might just be more fun.

Enjoy what you do.  Sounds obvious but you go to work every day and churn out code without really enjoying it you wont have the motivation to spend the time learning new things and before you know it you're out of touch and out of date.  This can be a tricky one though, if the project you're on isn't that interesting then how can you stay enthused about it?  Well look for little things around the project you can do in your spare time to make it more interesting, such as writing a little app to make a repetative task more efficient.  Contribute to an open-source project you like or just write a little app for yourself, some of the best applications have been written to scratch your own itch.

The last thing is a tricky one for some people but here goes.  You DO NOT know it all, you might have at some point but things move on, and quickly so you will need to as well.  But there are people at the other end of this scale and to those people I say you DO know something, there is no such thing as a perpetual noob, every day you learn something you're more experienced than the day before.  Look at it this way as well, even people who write programming languages don't know every little aspect of it as other people contribute ideas and write libraries and frameworks and they don't know how all of them work!

The advantage of not being connected

There are normally a few articles published each week on version control, an odd "How-To" guide, a tale of how a version control system saved someone numerous hours worth of work or the odd rant.  Over the last few weeks however there seems to be a little more background noise when it comes to version control, more grumblings on the internet and a lot more where I work.

With my current employer we have numerous projects being worked on by teams internationally, but we don't seem to have any real consensus on which tool set to use.  This is fine for some of the work as we have client apps and web apps written in Java/.Net/C++, but a common version control system would be nice.  I've so far worked on applications where the code has been commited to CVS, SourceSafe and Subversion repositories, we also have Team Foundation Server (TFS) and a couple of others which I rarely remember around somewhere as well.  I know the people working on CVS complain that it's slow, SourceSafe users complain that it's ancient and unfit for purpose, the TFS guys complain that the system is unusable and the Subversion people actually tend to be quite happy.

There was one occasion however where non of them were happy and that was the day a virus hit the servers.  The infection itself wasn't that serious but the downtime was crippling while the network monkeys checked the servers and slowly bought them all back online.  Most people were able to continue working for a short while until they needed to check bits out or check them back in.  So I got a few odd looks when I was sat at my desk working away on some code, performing regular commits and relatively oblivious to the world around me.

As it happened I was in a lucky situation, first of all I was working on a new piece of code so had little reliance on others and secondly a few weeks earlier I had added another version control system into my tool set.  I had installed Bazaar and had worked it into my processes so that when I started a new piece of work I would use a local Bazaar repository, I would push this up onto a remote location every few commits and then when I was ready for everyone else to get their hands on it I would export it to a new location and commit it to the standard (which ever one it was that day) version control repository.

A number of times since it has proven invaluable to have a local repository, for instance I have a folder where I keep all my snippets and tests, these are all version controlled using Bazaar and again I push them to a remote location every once in a while.  Sometimes I will remove folders and files just to keep it tidy and relevant but on the odd occasion I will need to go back in time to some folder where I had worked on something which I would be in need of again.  If I've deleted it then I can restore it, get the information I need and if I feel the need delete it again.

Not having to rely on a central repository has been a life-saver on numerous occasions, a few people have also gotten wind of what I'm doing and are investigating switching newer projects over to a distributed version control system to avoid the kind of downtime I mentioned earlier.  Naturally there are a few doubters, some of whom still aren't convinced by version control itself, but they're the ones who'll be losing their hear quicker when it all goes wrong.

Belated Birthday Wishes C++

So 25 years ago, on October 14th 1985, a little known programming language called C++ was released to the world.  Since then it has been the cause of many arguments, mostly around complexity, efficiency and the differences between procedural and object-orientated languages.  Say what you will but for a language to still be in as much use as it is now (and currently at number 3 in the tiobe index) is for me at least incredible.  Admittedly the fact that 'C' is still in wide spread use since it's first appearance back in 1972 is simply astounding but I don't think that should detract from the C++ success.

So when C++ was released commercially I was 5 years old, playing with friends with much fewer cares in the world.  I might have been aware of computers but possibly didn't care as much, I do remember that doors opening by themselves was kind of amazing still!  And here 25 years later I'm using a programming language which is almost as old as I am day in and day out to earn my living.  Sure it may not be as pretty as some languages, or as expressive, you have to consider memory and resources and doing some basic stuff like sending data over the internet is a lot harder work, but I quite like it.  It's a challenge and in these days of automatic garbage collection considering memory and resources is quite refreshing and it makes you consider how wasteful some modern languages and frameworks are.

So happy 25th birthday C++, here's looking forward to the next 25.