The Simple Fundamentals we Forget

A little while ago a frustrated co-worker asked me for some help, he was working on consuming a web service and needed to add an array of strings to the request based on user input and he couldn't figure out how to add a new item to the array. He could find lots of examples of how to create the array, and how to populate it at initialization, etc. but he couldn't find out how to just add a new item. When i explained to him that you couldn't he was a little shocked, all of the other collection type let you add new items, why wouldn't an array? In his defense he came from a dynamic language background, where an array is more like an ArrayList in c#.

This got me thinking about some of the simple fundamentals and basic language features that I don't remember exactly how to use, mostly because I never use them. A good example would be the Conditional Operator

   1: string fileName = tempFileName != null ? tempFileName : "Untitled";

it's purely a personal preference, but I don't like the way they look in code and I think they make it harder to debug, having said that they are a fundamental part of the language and as a good developer I should know how to use them. This is got me thinking about how I should use parts of language/framework that I don't normally use just to keep in practice.

I think this could be beneficial in a couple of ways, primarily it would require me to look for things I'm not using and force me to think about how to use them. Second it would make me think why I don't use them. A prime example is an abstract classes, I know how to use them I just don't like to. Maybe if I forced myself to use them on occasion I would find a place where they are better suited then an interface or I'm just going to prove why I like interfaces better, but the important part is that I reaffirm why I like interfaces more then abstract classes.

At times I think the hardest part of learning new things is not forgetting what I already know, maybe I need to take some time to write some practice code or proof of concepts just for the practice.

Technorati Tags: c# Fundamentals,Software Developemnt

An elegant solution that was completely unnecessary

Working on a web form that would email someone when it was submitted, one of the methods looked like it could use a little refactoring.

   1: private string BuildMessageBody()

   2: {

   3:     StringBuilder messageBuilder = new StringBuilder();

   4:     messageBuilder.Append("Account Number: ");

   5:     messageBuilder.Append(textAccountNumber.Text);

   6:     messageBuilder.Append("\n");

   7: }

It looks kind of ugly and takes up a fair amount of space, I could do string concatenation,

   1: private string BuildMessageBody()

   2: {

   3:     messageBuilder.Append("Account Number: " + textAccountNumber.Text + "\n"

   4: );

but that can get ugly fast and in my opinion it's hard to maintain. So I came up with a brilliant and elegant solution, I would use an extension method!

   1: public static void AppendLine(this StringBuilder builder, string title, string value)

   2: { 

   3:     builder.Append(title); 

   4:     builder.Append(value); 

   5:     builder.Append("\n");        

   6: }

and now my could would look something like this

   1: private string BuildMessageBody()

   2: {

   3:     StringBuilder messageBuilder = new StringBuilder(); 

   4:     messageBuilder.AppendLine("Account Number: ", textAccountNumber.Text);

   5: }

and just as I was thinking how cool Extender methods are it hit me? I could just use StringBuilder.AppendFormat to do basically the same thing like this

   1: private string BuildMessageBody()

   2: {

   3:     StringBuilder messageBuilder = new StringBuilder();

   4:     messageBuilder.AppendFormat("Account Number: {0}\n", textAccountNumber.Text);  

   5: }

Oh well, but just proves that sometimes a cool new way to handle a problem isn't always the right way, and this was a reminder for me to look at existing functionality before I try to create my own.

Tales of the bizarre

Technorati Tags: Bizarre

I ran into a interesting problem today, we have a automated process that zips a file then emails it to a customer, sounds easy right we build a wrapper around the ICSharpLib ?

The zip file it created could be unzipped with the lib (using ICSharpZip) or by using 7-zip, winzip, etc. But the built in zip tool in windows couldn't handle it, also out customer is a Java shop and java couldn't unzip it and they running Unix servers and unzip complained saying it needed a newer version of PK zip.

Here is were it gets bizarre, I take the zip wrapper lib and my thinking is I'll create a command line tool so they could unzip the file in there app, I compile the project in mono on my Linux Virtual box and when I run my unit tests the zip file worked now.

My first thought was that it was a problem with being complied on a 64 bit box vs a 32 bit system(the virtual system is a 32 bit system), or something like that. I looked into it a bit further, wrote a small app in java to unzip a file for testing my changes, and what it finally ended up being was ICSharplib was creating a zip64 format vs the standard zip format. The windows explorer zip tool and java.util.zip can't deal with a zip64 file.

My real question is why did mono use the standard zip format vs the zip64 format?

I have updated our wrapper lib to use the standard zip by turning off the zip64 and it now works just fine, Just Bizarre.

A New Look

I decided to go with a slightly new look, I kept the colors the same, but I removed the fixed width of the content to make it easier to display source code and I changed how source code is displayed by adding a border around it and by adding auto scrolling.

Hopefully this will make reading this a little easier.

Development Heros

I pose the question, who is your development hero? Who has done the most to enlighten and inspire you about software development?

There are many rock star's in our industry Martin Fowler, Uncle Bob Martin, Scott Hanselman, etc. While they write the books and blogs we read and are in the pod casts we listen to and the screen casts we watch, are they truly who inspire us? Or is it closer to home, a mentor or collage professor maybe? For me the answer is simple the person who showed me how to use my first computer 25 years ago. Nine years later he gave me my first programing book (Terbo Pascal 4.5). Since then he has been an endless source in information, a solid sounding board for ideas, and a guild though the world of software design. While we haven't always agrees on everything, see drinking the koolaid, he introduced me to N-tier design, Inversion of control, and why interfaces are so important. While I may have learned more about the specifics from others, it was his guidance that showed me the way. While this may sound like the rantings of a fan boy, I think that it's OK, he may not have been a rock star in our industry, but his simple lessens and guidance let me down the path to good software design, and even at the age of 30 I'm was still inspired by my older brother, may he rest in peace Benjamin Clements 1974 - 2009