- Posted by mateid on September 28, 2010
I was working with some legacy code a couple of weeks ago and I came across a little gem that deserves some bits on the wire. Le this serve as a cautionary tale for all developers out there.
The story dealt with extracting a document from a legacy database and displaying it in a new application. Fairly easy task one might be tempted to think. Wrong! After some trials, tribulations and perusing some very convoluted legacy code we track down the offending piece of code. What we found was… well… it defies qualification; or maybe I’m just not good enough with words. !#@$@@%! There, that’s better!
Somebody decided that they were missing out by not using this cool feature called XML, so they took their HTML document and stuffed it in an XML document. Cool right? NO, that is NOT cool dude!
Than there was a need to add more HTML documents in the XML document. Easy, just add another node and store it in there. Even cooler, right? NO, that is seriously not cool dude! Maybe we should backtrack a little at this point. If you had a pair they’d be smacking you over the head with the heaviest book in reach by now. Or just not allowing you keyboard access for the next day or so.
Now all of this XML/HTML data is consuming a lot of storage space on the server. We should probably compress this sucker. Really? Have you looked up the cost per gigabyte lately? And while we’re at it we should use the most obscure compression algorithm ZIP supports, Deflate64. This thing is going to be awesome!
Finally, this data needs to at least be easily accessible and query-able. Let’s leverage an RDBMS and store the compressed XML document that contains HTML in a binary format. That will make the task complete!
My only question is: Really? Why would you do this to yourself? The moral of the story is that your coworkers will get upset, angry and might have random emotional outbursts when dealing with this kind of code. If you find yourself contemplating storing HTML inside and XML document, compressing it and than storing it in the database, PLEASE DON’T DO IT!
- Posted by mateid on September 19, 2010
Hijacking language features to support syntactic sugar is not always a good idea.
I was working on a little pet project and I decided to try and add some syntactic sugar to my pages. I have a navigation menu and I would like page to specify which item in the navigation menu is the current one so that it can be highlighted. The navigation menu is a partial view and I would like to be able to write something like this:
<% Html.RenderPartial("Navigation", currentItem => "Log in"); %>Notice the current item part – this looks like a ruby hash and it’s nice and descriptive. Making this work on the other hand is pretty sketchy. First we need an extension method for HtmlHelper that can actually take Func<string, string> as a parameter. Here’s the implementation I came up with:
public static class RenderPartialExtensions
{
public static void RenderPartial(this HtmlHelper helper, string partialViewName, Func<string,string> currentItem)
{
helper.RenderPartial(partialViewName, currentItem(string.Empty));
}
}All I do here is invoke the Func<string, string> with string.Empty as parameter. Really? Pretty shady. There’s also a small issue with the “currentItem” part. I can’t think of a way to make sure it’s called that which defeats the purpose. I decided to abandon this idea, there are simply too many things wrong here.
For now I ended up creating a NavigationModel that has a CurrentItemName property and just use it that way. The syntax is still nice and readable and it has none of the smells of the previous try. If somebody were to come up with a cleaner implementation I might be persuaded still. The final usage looks like this:
<% Html.RenderPartial("Navigation", new NavigationModel { CurrentItemName = "Log in" }); %>
- Posted by mateid on August 22, 2010
I think dynamic languages have some serious advantages when working with JSON over static languages. Things are just easier and there is a lot less friction. Static languages like C# make things a little cumbersome because you always need to specify a type. That is almost always. :) There is an alternative in C#, provided via anonymous types. You can deserialize to an anonymous type by giving the JSON deserializer and example object. (I’m using the fabulous JSON.net library for these samples) Let’s see what I mean:
public class JSON_to_anonymous_type
{
private string json = @"{ Name: ""James"" }";
[Test]
public void can_deserialize_to_simple_anonymous_type()
{
var example = new { Name = string.Empty };
var person = JsonConvert.DeserializeAnonymousType(json, example);
Assert.AreEqual("James", person.Name);
}
}The JSON serializer will take your example anonymous object and attempt to use it as template to deserialize the JSON literal. This provides a nice alternative to defining a full blown C# class to deserialize to in some cases.
The example above is rather simplistic, usually the JSON literals we have to deal with in real life are a little more complex than this. Let’s look at something a little closer to a real life scenario. Say the person is married, and we’d like to include the spouse information with our JSON literal. We now need a nested anonymous type. The syntax can get a little crazy but here goes:
[TestFixture]
public class JSON_to_anonymous_type
{
private string json_moderate = @"{ Name: ""James"", Spouse : { Name: ""Sally""} }";
[Test]
public void can_deserialize_to_moderately_complex_anonymous_type()
{
var example = new { Name = string.Empty, Spouse = new { Name = string.Empty } };
var person = JsonConvert.DeserializeAnonymousType(json_moderate, example);
Assert.AreEqual("James", person.Name);
Assert.AreEqual("Sally", person.Spouse.Name);
}
}Let’s try one more scenario – we would like to parse a list of children from the JSON literal. This is starting to become a little hard to read, but still better than having to define two static classes if all we need to do is say count the couple’s children.
[TestFixture]
public class JSON_to_anonymous_type
{
private string json_complex = @"{ Name: ""James"", Spouse : { Name: ""Sally""}, Children : [ { Name : ""Tom"" }, { Name : ""Sandra"" } ] }";
[Test]
public void can_deserialize_to_complex_anonymous_type()
{
var example = new { Name = string.Empty, Spouse = new { Name = string.Empty }, Children = new[] { new { Name = string.Empty }}};
var person = JsonConvert.DeserializeAnonymousType(json_complex, example);
Assert.AreEqual("James", person.Name);
Assert.AreEqual("Sally", person.Spouse.Name);
Assert.AreEqual(2, person.Children.Length);
}
}I think that covers a couple of complex scenarios that you might encounter in real life. Deserializing to anonymous types can reduce the friction of declaring one or more static classes for simple scenarios where we may need to simply peak at a JSON literal to extract one or two properties, or perform some simple operation. If things get a little more serious than by all means declare a couple of static types to deserialize to, if only for readability's sake.
- Posted by mateid on August 11, 2010
I think I’ve posted before about build automation but I didn’t really stress how important this is for a dev team. This is probably the one thing that will support your team day in and day out. It will save you lots of tedious, manual labor and a lot of frustration when you integrate with other systems. Once you get your builds going on a build server like TeamCity visibility into issues increases dramatically. You can also expect issues to be resolved dramatically faster than before. One thing to remember is that this new increased visibility is not to give you ammo against you team mates, but to enable you to help them. The bottom line is that automating your build and deployments is well worth the time you’ll spend to set it up.
This will probably turn into a little series, but I’ll show how to set up a basic build script. I’ll be using MSBuild but the same concepts apply if you happen to be using nant. I used to prefer nant because I find it easier to work with. MSBuild has a somewhat cumbersome, awkward syntax but it seems easier to adopt in Microsoft environments.
I’ll assume a simple solution that consists of a web project, some library projects and at least one test project. The solution is self contained – in other words all the tools and libraries we need are in the solution folder. All we need to do is check out and off we go. This enables us to build without even opening studio. Our goal is to clean the solution, build it and run the unit tests. As you will see this is not very difficult to accomplish.
The basic building block for a MSBuild script is a target. A target is a group of tasks that will be executed sequentially in the order they are defined in your build script. A very basic build script can look like the one below:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<MSBuild Projects="solution.sln" />
</Target>
</Project>This a simple project that consists of one target – Build – which also happens to be the default target for the project. We save this as solution.build for example. Using the .build extension actually gives you intellisense when working with your build file in VS 2010. You can setup a batch file that will call MSBuild and execute the script we just created with the following line:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe solution.build %*
This will execute the default target in your build file – Build. The ‘%*’ means that any parameters that you pass to this batch file will be appended to the command line used to invoke MSBuild.
One thing that we would like to do is ensure a clean build. We need to clean the output folders of all assemblies that might be stale before we build our solution. We can easily do this by setting up a new target called Clean. In here we’ll define a list of files we’d like to delete using and ItemGroup. Once defined, the item group can be passed to the Delete task to clean our output folders. Your new build script will look similar to this:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build" DependsOnTargets="Clean">
<MSBuild Projects="solution.sln" />
</Target>
<Target Name="Clean">
<ItemGroup>
<BuildFiles Include="$(MSBuildProjectDirectory)\**\obj\**\*.*" />
<BuildFiles Include="$(MSBuildProjectDirectory)\**\bin\**\*.*" />
</ItemGroup>
<Delete Files="@(BuildFiles)" />
</Target>
</Project>Here we’ve introduced a new target and leveraged a couple of important MSBuild features. We stated that the Build target depends on the Clean target. MSBuild will now ensure that the Clean target runs before the Build target. Inside the Clean target we used ‘$(MSBuildProjectDirectory)’ – this means we would like to use the value of the property ‘MSBuildProjectDirectory’. In this case it is a build in property but we’ll see shortly how you can define your own properties. We are now at a point where our script can perform a clean build of the solution. Time for a check in! In fact you can now start to leverage this build script on a build server like TeamCity where by defining some artifacts you can have your build output packaged and ready for deployment.
Finally we would like to control the active configuration for our project. We don’t necessarily want to package and ship debug assemblies! We can accomplish this easily by defining a property named Configuration in our build script. This will most often take one of two values - [Debug|Release]. We’ll pass the value of this property to our MSBuild tasks in our Build target. The build script will now look like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition="$(Configuration) == ''">Release</Configuration>
</PropertyGroup>
<Target Name="Build" DependsOnTargets="Clean">
<MSBuild Projects="$(ProjectName).sln" Properties="Configuration=$(Configuration)"/>
</Target>
<Target Name="Clean">
<ItemGroup>
<BuildFiles Include="$(MSBuildProjectDirectory)\**\obj\**\*.*" />
<BuildFiles Include="$(MSBuildProjectDirectory)\**\bin\**\*.*" />
</ItemGroup>
<Delete Files="@(BuildFiles)" />
</Target>
</Project>We can now change the active configuration for our build simply by passing a command line parameter to our batch file.
build.bat /p:Configuration=Release
We now have a very basic build script that we can start using in a build server or from the command line. This pretty much concludes the first part of what is to become a series.
- Posted by mateid on August 9, 2010
As a follow up to my previous posts and the issues we’re dealing with on my current project let’s look at how we’re dealing with blockers.
First of all what are blockers? Things that prevent me from doing my work and moving the ball forward, things that make me waste the clients time and money. As of late there are a couple that have managed to sneak in and we’ve not dealt with them effectively. They weren’t blocking any high priority tasks but it is a somewhat unsettling trend. Perhaps that is why the visibility was so low, they were just flying under the radar.
During the standup we all say our piece followed by “no blockers” or “I am blocked by…” (Stating “no blockers” at the end of your update is a bit of a smell to me, it smells of agile implemented as a control mechanism but that’s a post for another day) So how is it than that we have issues that remain unresolved for extended periods of time? The must be a disconnect somewhere. The problem is that blockers were not assigned an owner. Lack of ownership is an issue we learned to deal with quickly.
Soon enough when a team member reported a blocker we started noting it on a sticky, and placed it in a column on the wall dedicated to blockers. We found that an approach that works reasonably well is having a team member own the issue. Just ask for volunteers during the standup! An expected resolution date associated with the item also helps drive the resolution or further escalation. At the end of the standup when everyone has given their update we go through the blockers and deal with them on a case by case basis. Obviously if discussions are taking a long time you can take it off line with a couple of teammates. We found that the increased visibility and daily attention helped us deal with various issues effectively and keep the dev machine from grinding to a halt.
We found that when dealing with blockers what works best is increasing visibility and ownership of the issue. Taking control of your blockers really helps to keep the project moving and it gives an tremendous opportunity to deal with tough issues early and effectively.