I hate release days...

My months-long shipping project has just been released - my largest at this company to date - and it replaced a great deal of critical functionality. My nerves are shot and I didn't sleep well last night while our lead dev rolled out the changes. All went well, and everything's fine, mostly thanks to the fact that we 'practiced' the release the day before on our test setup.

Still, the butterflies won't go away...

.NET 4 + VS 2010 = Sweeeeet

-- and it's that sweetness that makes me feel even more guilty about having a VS niggle after 2 minutes of using it...

In VS 2008, if, in the body of a method, you press Enter a few times to give yourself some space, when you up-arrow to go back up, the cursor stays at the indentation level of the rest of the method. 2010 doesn't do this - the cursor jumps to position 1, regardless of the current indentation level you're at.

Meh.

Behavior Driven Design

Every now and then I get the urge to try out some of the more recent design methods coming out lately - usually they tend to end in 'DD.' Rob Conery is largely responsible for this trend in me to experiment, as his screencast series on MVC Storefront (now Kona) demo these different ideas rather well.

His most recent screencast introduced Behavior Driven Design (BDD) to me, and I have to say that of all the 'DD's, BDD makes the most sense to me. So I've decided to try and build an entire project using it (one that I've been putting off far too long).

The guild to which I belong (which I will not name here) requires a website, and rather than use something like GuildPortal for it, I've decided to build it myself, using ASP.NET MVC. All of the various systems will be custom built by me - I don't want to use any community management software, etc., because I want this to be a learning experience for me.

Among the components I'll be building, the simplest is the News Service, which will let administrators post guild news. I've decided to spec out this service before I build it. Here's my list of specs:

• when viewing article titles
  • should display a date descending ordered list of article titles
• when viewing top n articles
  • should display up to n articles in a date descending ordered list
• when creating a new article
  • should contain the authors id
  • should contain the posted date
  • should contain the article title
  • should contain the article body
• when viewing a single article
  • should display the articles contents
• when adding a new news article
  • should provide a new id for the news article
  • should add the item to the news service
• when removing a news article
  • should remove the item from the news service
• when editing a news article
  • should update the item to the new contents

This describes a basic news service, I think, as a user or administrator might understand it (which is one of the goals of BDD btw - the terminology you use should be part of the business language rather than the technical language).

Now for some disclosure - I must admit I've cheated a bit here for the purposes of this blog post. The above list comes from the MSpec runner report output. MSpec is a BDD specification framework which lets you define your specifications in terms of executable code, which you can use to verify that your specifications are met. I did write my specs first - MSpec allows you to leave your specifications unimplemented - but I have already written the required functionality against a mock news article repository.

So far - fun stuff. I'm still a little apprehensive - I have no real idea what I'm doing, but I'm sure I'll figure it out as I make false steps here and there. This is a toy project really (but unlike other toy projects this one will be actually useful, so I'll be less inclined to give up on it, especially with my guild leader nagging me incessantly...) - but I want to give it all I can.

File operations and temp folders...

This is a problem I've seen before in many places, and it seems like good practice (or at least it must have at some point) - but for me it seems to cause more harm than good.

Many program (Internet Explorer for file downloads, certain ZIP utilities, etc) perform file operations in a temporary folder, then copy the results of the operation to the ultimate destination.

I can see why this makes sense. Depending on the operation, allowing the user to muck with the file during processing can cause data loss, errors, mini-black holes, etc. But when the resulting file is very, very large, the subsequent copy can take forever. Additionally, if there isn't enough space on the destination, then instead of failing fast and reporting the file allocation error, we have to wait until the end of a potentially expensive operation (like unzipping a 12 gig file from an archive) before we find out. In fact, this practice makes such a problem more likely because the space requirements are doubled in order to facilitate the copy.

I'm really just ranting here rather than offering a fix for the problem - the only fix I could possibly suggest would be to avoid doing this at all. If you must, however, make it an option for the user to override, allowing said user to take responsibility for his/her own file system.

*ahem* STOP PROTECTING ME FROM MYSELF.

Genetic Algorithm + Brainfsck

First: Genetic Algorithms. A GA is a program designed to find the solution to a problem via iterative searching - that is, the algorithm itself searches for a solution to a problem. GAs in particular use biologically-inspired methods to perform the search.

The analogy with biological systems is like so: a GA spawns multiple search 'organisms,' which 'live' in the algorithmic environment. With each generation, each organism is tested against a 'fitness' function, which determines how well the organism solves the problem we're looking for a solution for. Only the fittest of each generation survive, passing on their genes (parameters) to the next generation. Each of the survivors randomly selects a mate and mixes the genes (with some random mutation factors), with the expected outcome of iteratively evolving toward the best possible solution to the problem.

I've built a couple small GA systems in the past - nothing for anything in production, but mostly just to toy with - and I find them particularly interesting, especially given how very small changes in how the organisms select mates, mix genes, and mutate can result in large-scale changes in the search behavior.


Now the second part: Brainfsck (which is actually spelled with a 'u' instead of an 's', but I want to maintain some civility here) is a programming language in which there are only 8 legal characters - '>' '<' '+' '-' '.' ',' '[' and ']'. Each of these characters performs some function in the program, usually with regards to manipulating 8-bit memory locations called cells. Wikipedia has more information - but suffice it to say that Brainfsck has been proven to be Turing complete, which means it can be used to perform any computable function (provided it has infinite memory).


Here's how Genetic Algorithms and Brainfsck can come together: I mentioned earlier that GAs use digital organisms and 'genetic' parameters to evolve toward a solution. What if those parameters were snippets of Brainfsck programs, and the fitness function ran the Brainfsck programs to see what their output is, and check that output against an expected output? Wouldn't it, in theory, be possible to iteratively evolve toward the solution of any computation problem that way?

Just a random thought that's been plaguing me for the past couple of days. Don't think anything particularly interesting would come of this.

DLR Trees == LINQ Expression Trees?

Appears so - at least, once .NET 4 ships.

I've been doing some research on the DLR lately, for no other reason than sheer boredom - and came away fascinated. The DLR (Dynamic Language Runtime) is .NET's answer to dynamic languages running in the .NET environment. It's still in beta at this time (DLR is version .9 as of this writing), but already many languages have been implemented on it - the most famous of which are the Iron languages - IronPython and IronRuby.

The way it works (and I'm simplifying things here) is thus: you provide the translation from source code to DLR trees, and the DLR provides IL generation, fast execution, a proven garbage collector, and the entire .NET Framework. Sounds like a bargain to me. DLR trees are syntax trees that tell the DLR how to generate code - you have things like AssignmentExpression, StatementExpression, LambdaExpression, etc.

A lot of this sounds very similar to what you get right now with LINQ Expression trees. In fact, there was an announcement a short time ago which stated that LINQ Expression trees were going to be getting an upgrade. Currently (.NET 3.5) LINQ Expression trees can only represent simple logic - property lookups, method invocations, things like that. You currently cannot express an IF statement, for example, inside a LINQ Expression tree. With .NET 4.0, that's going to be changing - LINQ Expression trees will be augmented with the functionality it's currently missing.

This is great news for LINQ implementors, to be sure - but seems to me to be a bit redundant. LINQ expression trees and DLR trees are starting to sound a lot alike - so I popped on over to the DLR's home on CodePlex and asked about it:

Me:

Not sure if this is the right place to ask this, but here goes:

Why is there so much duplication between these two incredibly similar tasks? Why couldn't Expression Trees have been implemented as DLR Trees (or vice versa)?

Them (specifically, Bill Chiles):

:-) You’re like the audience plant to ask just the right questions :-).

They are the same. LINQ Expr Trees v1 evolved into Expr Trees v2 which are exactly the DLR tress. All the sources you see in our codeplex project are the sources we’re shipping in CLR 4.0 for all of the Expr Trees code. What might be confusing is that until we RTM CLR 4.0, we change the namespaces on codeplex. We need to do that so that if you have a .NET 3.5 C# app that both uses LINQ and hosts, say, IronPython, then LINQ works as well as the DLR. You just can hand those threes back and forth, which would be a very corner case scenario if one at all. When we hit RTM, the codeplex sources will will have the same namepace, but we won’t build the Microsoft.scripting.core.dll in our .sln file.

Bill

So, there you have it - DLR Trees == LINQ Expression Trees. Very cool stuff happens when you explore the possibilities here - consider a LINQ to SQL provider that might be capable of understanding your custom C# logic and translating that into the equivalent TSQL code -- or, even better -- send the DLR tree over the wire to SQL Server which can run it on a DLR implementation there!

That would be just awesome...

Here is the thread on CodePlex where I chat with Bill about the trees, in case you'd like to see the follow-ups.

Arrrgh

Slow Visual Studio builds make me a SAD PANDA.