November 2008 Blog Posts
Yes, I am aware that I have a tendency to raise new points in the summary section of my posts. This works for me.
For any particular development task it is possible to classify it into one of two categories: tasks that you know how to do and just have to actually be done and tasks for which the solution is unknown. The later category is decidedly more prevalent although ideally all tasks eventually decompose to the former. The implication of this is that you will be developing things that you do not a priori know how to build. This involves design and particularly making design decisions. These decisions will necessarily be made with incomplete knowledge. Unless you are particularly lucky (and lucky...
I'm heading off to a movie later and decided to use Google Maps to find out how to get there. The movie is at Hoyts Garden City, so I chose "garden city" as the destination. This is the result*: I particular love that it wants me to paddle a kayak across the Pacific. Although it helpfully arranges stops in Japan and Hawaii. The total journey time is estimated at over 26000 km and 56 days which I'm reasonably sure means that I'd miss my movie. At least kayaking is a step up from previous recommendations...
Because it produces things like this. With stick figures. It's genius in (mostly) monochrome.
OK, all it does is demonstrate my ability to pay for a MSDN subscription. I'm trying to work out why they're giving them out. It has my subscriber ID and subscription expiry date, but I have them elsewhere. It also has my name and email address but I'm not immediately in danger of forgetting those. So my question is: what does this piece of plastic get me? And how can I use it to lord over those I consider beneath me? If you have any suggestions post them as a comment. Comments on this blog are currently broken (one...
The example I used in my previous post is a highly simplified case I found in actual code. If differs from the code I encountered in a couple of major ways, it's simplified, it deals in test classes not the domain classes from the example (which are not relevant here nor which I am at liberty to post) and that it doesn't contain a bug I find mildly amusing and somewhat informative. The bug is illustrated here: public static BusinessObject FindByCriteria(IEnumerable<BusinessObject> businessObjects, DecisionCriteria decisionCriteria)
{
if (businessObjects == null)
{
...
There's a school of thought that methods should have only a single exit point. This school teaches that all the logic paths through the method should end in a single place from which there is a return of control and the method result (if any) to the caller. The arguments I have seen for this include alleged benefits in readability and correctness. I find these claims to be spurious. If is my hypothesis (for which I've done no research whatsoever) that single exit point comes from unmanaged environments and this is where I first encountered it. Unmanaged environments require...
I've learnt tonight that ASP.NET MVC tends to get annoyed when you reuse a controller instance. I have a (rather primitive) factory creating controllers and doing some simple dependency injection. This is a result of a medium trust target environment. My first pass at a controller factory reused controller instances. This resulted in InvalidOperationExceptions with the message: The parameters dictionary does not contain a valid value of type 'System.Int32' for parameter 'id' which is required for method 'System.Web.Mvc.ActionResult EditPosting(Int32)' in '<MyController>'. To make a parameter optional its type should either be a reference type or a Nullable type....
My discussion of failing fast as a development philosophy was relatively general in terms of the level to which it applied. It could be read as a suggestion that it is only inputs to a system that should be validated, but this would be inaccurate. It is my opinion that failing fast is a concept that should be applied at all levels of a system. One key area is in validation in methods. There are a number of advantages to methods performing validation before execution. The reasons for failing fast I discussed in my previous post. Validation also has...
Of the opinions I hold about software development probably the most counter-intuitive is that software that fails fast is more robust. After all, if the software breaks all the time it can hardly be considered robust. However there are a number of reasons I hold to the practice of failing fast and consider it to be a vital practice in building quality software. The first thing to note is that there is a distinct difference between failing and breaking. Failing is being unable to complete an action because required conditions are not met. Failing is normal and expected. Your...