Delegate types and lambda expressions have been a part of the .NET tool belt for a while now, so they show up everywhere. If you’ve ever used StructureMap, AutoMapper, ASP.NET MVC and the like, then you’ve surely run into them. Despite this, delegates and lambdas tend to confuse developers when first encountered. Even when you get comfortable with the syntax as it’s used in your favorite library, you might not really be familiar with what they are or how they allow for such seemingly magical statements.

Let’s pretend that delegate types and lambdas don’t exist yet, and then reinvent them in terms of other .NET concepts that are more widely understood.

Suppose we have been given an IEnumerable<Customer> and we want to filter that down to the list of those customers who live in Texas. Without delegates, we could write the obvious loop like so: Read the rest of this entry »

Traditional relational database schemas are designed to keep computers happy. Indexes, foreign keys, joins…all of these tools allow for the highest level of optimization so data can be recorded and read back in record time. However, humans are typically very unhappy when it comes time to answer business questions from this data.

Imagine your boss approaches you and asks for a report of all orders placed by the Acme Corporation on Thursdays. You recall how many times you and your team optimized the database containing this information so data could be written at break-neck speeds and moan when you think of the complex script you’ll need to write to retrieve the report your boss requires. Wouldn’t it be nice if, instead of lines and lines of arcane SQL, we could ask a database something like the following and get back exactly what we expect? Read the rest of this entry »

A lot of people call me up when they need custom software to solve a problem. While each project is a little bit different, they typically fall within a few categories of maintainable software solutions. I’ve learned a valuable lesson about categories though: Sometimes you have to throw them out the window to clearly understand a problem…

Growing up I read a lot of Calvin and Hobbes. I’ve got every anthology including the leather-bound edition. As much as I love reading them, I find myself having to refocus halfway through a single strip. I tend to think that I know the ending to a given strip or series, and I skip ahead.

Oh, this is the one where he collects all the UPCs and gets a propeller beanie. I’m going to flip a few pages and see the look on his face when he doesn’t take off! Read the rest of this entry »

In conjunction with Pablo’s Fiesta, an open-space development conference being held in Austin September 30-October 2, Headspring will be sponsoring an Open Source Hackathon at our offices on Sunday October 2nd from 1 PM to 6 PM. Over 150 developers from all over the United States and beyond are coming to Austin for 3 days of ‘sharpening the saw’, and the Los Techies Crew realized that with all that brainpower in one place, we ought to be able to do some concentrated work on the open source tools we all use so much.

If you’re attending the Fiesta, or even if you aren’t, feel free to come by the Headspring offices on Sunday to learn more about how open source software is written, ask questions about tools you’re using or would like to use, or even kick-start a new open-source project! Please bring a laptop if you can!

Get more details by going to the Google Group for Pablo’s Fiesta Hackathon.

When I’m teaching the MVC boot camp, I’m always amazed at how some of the smallest things are most impressive to students. One of the most common “wow” moments I see from students not familiar with jQuery is how you can trick Visual Studio to provide IntelliSense by including the vsdoc file, but make sure it still uses the min file for performance. That can be done by including the vsdoc file in an if(false) condition like below. This ensures it will never get included in the production code, which still tricking visual studio’s tooling to import the IntelliSense.

When LINQ first became available, it was described as having a “lazy evaluation model”, meaning that a query would not actually be executed until you started to look at the result. Iterating through a result, for instance, would finally cause the query to actually run. This gives you the power to piece together a query over multiple statements before letting it execute.

Recently, I found that this abstraction can leak. I had a set of queries that were misbehaving, and it seemed that a bug would be reproducible in one set of queries but not in another, even though they were remarkably similar to each other in structure. The culprit was a big surprise: it turns out that the first ‘from’ clause in a query is treated differently from subsequent ‘from’ clauses. Although my project’s ‘from’ clauses were not implemented with side effects, an example that does use side effects best illustrates what is going on. Consider the following: Read the rest of this entry »

In my first post in the Unit Testing Best Practices series, I introduced you to the basic lifecycle of an NUnit test fixture. This time, we’re going to see what happens when we give our tests a common test fixture base class.
Why a base class?
There are two cases where having a base test fixture can be useful in keeping your test code simpler:

1. You have lots of the same kind of tests. Maybe you’re writing integration tests for your persistence layer. Your tests are going to all be performing some similar operations, like creating a database connection. Maybe they all need to reference an Inversion of Control container like StructureMap or Autofac in order to retrieve repository instances. You don’t want to write that boilerplate code for every fixture, do you?
2. You have a hierarchy of classes that need testing. If you have a base class in your domain, you will probably want to set up a parallel type hierarchy of test fixtures. In this case, a base test fixture gives you one place to define tests that verify the base class invariants to which all your derived classes need to conform.

The Code

Well, not YOU, of course. YOUR team’s code reviews, I’m sure, are pleasant, productive engagements where everybody leaves feeling good about the results. They happen early and regularly in the development process, the goal of the review is well understood, and you wouldn’t dream of shipping a line of code that hadn’t been through your review process. Your team loves doing them, and you don’t worry about who does the review because you’ve got a consistent standard that your whole team agrees with. You’re just reading this article because there’s this other team in the building that you think would benefit from reading it, and you’re going to forward it to them when you’re done reading.

I’m with you. Personally, I’ve never sat around a meeting table with 15 other developers, Read the rest of this entry »