Happy Xmas

Happy Xmas to all, and those who don't do Xmas then best wishes.

This is our first (and probably last) Winter Xmas and unfortunately it looks like it won't be a White one. It will be bloody cold though, can count on that.

Anyway, to my friends in the North - enjoy your Turkey and Brussel Sprouts (yuk). To my friends in the South - enjoy your BBQ's and salads!

Windows Vista Service Pack 1 RC1

Although an Apple fan boy, I still have a Window Laptop for doing .NET dev work on. The machine is new and came with Vista pre-installed. I have MSDN and considered re-installing XP, but thought I would give Vista a chance seeing as I paid for it!

Initial experience was ok, but I felt the internet was a little slow. This was bourne out by testing - my Macbook Pro, and XP via boot camp was around 7000kb/s down, Vista came in at around 4800kb/s. All on the same internet connection. I did a little research and discovered other people were having issues too. I tried all the resolutions to no avail.

I was about to give up on Vista, when I noticed RC1 of SP1 (say that 10 times fast) was available to download. So I did - nothing to lose.

Installation was fairly painless, it comes in via Windows Update. The whole process took about 25-40 mins, rebooted a few times and fairly painless.

The whole OS feels snappier, and I rebenched the internet connection and it was up to 8000kb/s. Ok hardly scientific but the results speak for themselves.

Hopefully, SP1 for Vista has ironed out the many issues that people were having. It seems to have for me so far.

"Blogger arriving on .NET Platform 3.5 is..."

A blog, particularly one which has had a fair amount of work put in over a period of time, can be a precious and special thing, and to be invited to contribute to this one by James is comparable to inviting someone to live in your home, or drive your car. It is an honour that I intend to repay by hopefully making posts that not only maintain the standard that has been set so far, but also by bringing my own perspective of all the new stuff that's going on in the business we call software development. I have to say that James has certainly set the bar pretty high with his post announcing that I had been invited to start contributing to his blog, and I certainly intend to live up to the billing.

So Hi! I'm Shaun, as James has already said I'm a Brit currently based in Cheltenham, UK and have been a software developer for as long as I can remember (even back to childhood.) As a contractor I've worked in many diverse industries from media to government via pharma and banking etc and have tended to focus on the ever morphing set of MS technologies.

So what can you expect from me? Well, my current interest is in the latest greatest bits and pieces that have come along with the new .NET framework releases. Like James I'm quite enthused about the possibilities created by some of these new technologies such as LINQ and hope to be able to shine an "in the real world" spotlight on them. Some of the topics that I'm most excited about and straining at the leash to blog about are:

• LINQ (to SQL, to Entities, to XML all of em)
• ASP.NET MVC
• Continuous Integration
  
• Test Driven Development
• The rise of AOP in .NET development (using PostSharp)
• WCF (son of remoting, grandson of DCOM)
  

One of the current pieces of research I'm playing with at the moment is how we can combine LINQ (to SQL) with a WCF service to provide data to a simple client (WPF) thereby moving closer to a real world implementation of an n-teir LINQ app. So keep your eyes peeled for a post on that some time soon.

New poster

I am happy and honored to introduce a new poster to the blog. Shaun Austin, a dyed in the wool Pom, and all round good bastard. You can trust me when I say he knows his stuff. In-fact I can honestly say I've only met one other person who comes close to his knowledge and ability.

Shaun's C.V is pretty impressive. He has been contracting for the last 10 years or so and has genuine real world experience. The only issue is he is a northerner and slightly Xenophobic in the Flight of the conchords sense of the word. (bit of an in joke I'm afraid). Also, we are (hopefully) co-authoring on a .Net related book. All will be revealed in the fullness of time.

Anyway, I hope you enjoy his posts - I'm sure you will.

Linq to SQL : where are the n-Tier examples?

Further to my last post regarding Linq to SQL. I have been searching the net, looking for examples of how one might use Linq in an n-Tier world.

Short answer is there isn't really any. The vast majority of examples you will find are for a 2-tier model, where the DataContext is alive across the call, and the Entities will always be attached to the DataContext. Unless you are developing utilities, or you code will always be executed in the same box as the database, then this isn't really real world examples.

With a bit of digging, I have found a series of articles on the MSDN site here with the most useful being this one.

The readers digest version for those of you who are too lazy to read the articles, is that you need to serialize your Entities and then use the Attach API to "reattach" them to a DataContext.

There are some gotcha's, most important of all being you may have to handle concurrency issues yourself.

I intend on posting some code once I have digested the articles and found time to do some playing, but I would suggest you do some digging of your own, and those articles would be a good place to start.

Linq

I have been playing with Linq (Linq to Sql) for a couple of weeks, when I get a chance. I do like Linq. The most powerful (and obvious) feature is automating the plumbing of creating a data-access layer. Design the database, drop the tables with links on the designer and bam, you're done.

While this is a really good thing, I think there are two potential issues:

1) Linq can promote tighter coupling of UI to DataLayer (DataContext in this case)
Maybe this isn't as big an issue as it used to be in the bad old days, but I can see lazy coders talking directly to the dataContext/Layer from the UI. For example

myDataGrid.DataSource = MyDataContext.Customers;

it probably isn't a sin but it's a small step from there to embedding business logic in the UI layer because it is so easy to do something like

string id = txtId.Text;
var cust = from customer in MyDataContext.Customers
      where customer.id == id
      select customer;

someControl.DataSource = cust;

in a search button on click event. This sort of thing was/is common in Delphi. Delphi has a concept of a Datamodule, which isn't a million miles away from a DataContext. Well I guess it is, but for arguments sake, if you think of a DataContext as a central data repository then a Delphi data module is getting closer. It makes ugly, hard to maintain code. So please don't ever do this. Use Linq to Sql by all means, but there is no reason not to still have a business layer in between.



2) Linq to Sql will generally create a 1:1 mapping of data objects to business objects
A lot of people don't care about this, but business objects shouldn't necessarily be a 1-1 mapping of your tables. Take an order for example, it will contain data from a number of different tables, customer, order master, order detail, product, possibly tax. Anyway you get my point. From a business object point of view, this is one object.

Without discipline, good design, and buy in, linq makes it very easy to cobble bits of data together to do what you need quickly and easily, in the short term, but can cause a mountain of headaches in the maintenance phase. I have seen it all to often in Delphi code.

I guess in a nutshell, the point of this post boils down to this statement:

Linq offers great power, but with great power comes great responsibility. Please, please, please remember this when you are dipping your toes into the Linq pool for the first time.

Reskin

A couple of people have complained in the comments about the last skin causing vision bluring after a while. I have therefore changed skin. It's just a standard template supplied by BlogSpot. I really should create my own, but only so many hours in a day...

The old 80 / 20 rule

Jeff Atwood suggests there are two types of developer. Basically it comes down to 80% of developers are what I would call plodders. They get on with the job, but aren't particularly brilliant or interested in coding as a craft.
The other 20% have a passion for developing and are not only good, but are always trying to be better.

Being a contractor, I have worked in a lot of different industries, and more importantly with a lot of different people. My observations of different types of developer are below.

Type A: Plodders

Plodders get their name because they tend to plod away day after day, producing code. The code they produce might not be the most elegant solution but it works and that's all they care about. These types never really better themselves too much, because programming is something they do to pay the bills and they don't really love it.
Every project needs plodders - tell them what to do and then let them go.

Type B: Coders

Coders are definitely in the 20% mark. They are very good developers, with the ability to look outside the confines of what they are doing and see the bigger picture. They would be keen to better themselves by reading blogs and books and keeping up to date with latest technologies. Coders usually need to be kept interested in, or believe in what they are doing, and can revert to plodding if they aren't. Coders would rather prototype something to see if it will work, rather than methodically work out what would be needed and document every part of the system before coding.

Type C: Careful Coders

A careful coder is basically a coder with a more meticulous personality. These types prefer to have a full understanding, and a fully documented specification before turning on the IDE.

Type D: Guru

These are very rare types, maybe 5% of all developers. They fully understand the languages and technologies they use, and know things inside out and can wring the last CPU cycle out of their code. A true guru isn't self titled. It's up to other developers to give them that name. I've worked with maybe 2 or 3 in my entire career.

Obviously the above list is entirely subjective and only coming from my experience but I think most people would agree that the guys around them would fall into one of those categories above.

For the record, I consider myself to be a coder, but always seeking to be better and improve so one day I might come close to being a Guru...

VB Must die

I'm sure there are some excellent VB programmers around it's just that I've never met any. Judging by the quality of the VB code I've been looking at recently, none worked at the place that wrote that code.

There is something about VB that seems to invite cowboys and morons to it. Guys that were flummoxed by C/C++ or Delphi, but still wanted to get on the IT Gravy train. I guess it's easy to get something up and running, and without a lot of forethought or future thinking. Just put all our business rules on the click event of this button, no one will ever need to change the code, or the UI.

The language itself encourages laziness.

On Error Resume Next

WTF!

Sure the program has just come back from catastrophic error, but I'll still try and plug on anyway. What's the worst that could happen?

variables don't need to be defined before using

VB guys counter this by saying, "Always use Option Explicit". Well if you should always use it, why isn't it turned on by default? Or better still why give the choice?! Sugrue rule number 1 states that if you allow a programmer to be lazy, they will be.

The single worst thing about VB to me though is the use of braces when calling a method with parameters. Or not.

myMethod parmeter1, parameter2

is valid, infact that's how you do it. However if you are assigning the return of a method to a variable, put the brackets in:

myVar = myMethod(parameter1, parameter2)

why? What sane person thought of this? WTF is the point. Either use it or don't.

Which brings me to VB.NET. Obviously it is real OO and utilises the .NET framework so is built on the foundation of brilliance, but what is the point? If it's to allow VB coders an easier starting point to .NET, then they are kidding themselves.

Microsoft should doing everyone a favour and send VB for a long walk off a short pier. Either learn C# or flip burgers instead.

Sometimes you have to be cruel to be kind.

When is String.IsNullOrEmpty doesn't work

If you read my previous post you'd know I was involved in some C#->VB COM developing. Well actually VB->C# to be 100% correct.

Anyhoo, in VB you can define a string with a length eg

Dim suckyVBString as String * 9

which defines a string of max length 9 characters. When this string is part of a user defined VB type (or "class") then when the type/class is newed then suckyVBString will be "         " rather than "".

So a little unexpectantly doing a String.IsNullOrEmpty(suckyVBStringFromCOM) returns false

a little browse of the IL shows that IsNullOrEmpty contains this code (not exact code I am blogging on my mac but you get the point):

public bool IsNullOrEmpty(string s)
{
   if (s != null && s.Length > 0)
      return false;
   else
      return true;
}
so while the Marshaled VB string is full of 9 nulls (char /0), it is neither null or empty according to the code.

A quick visit to String.Trim() sorts all this out, but it's a trap for young players if you're not careful.

C#->VB6->C# Sucks

The current project I am working on is erm, interesting. The scope of the project is to replace VB business logic, with C# and SQL Server. The major caveat is that the VB front end MUST stay intact. Not only intact but untouched.

Fun fun.

Most things just work out of the box. Obviously all classes must be exposed with [ComVisible(true)] attributes and given a GUID. Even though Microsoft states that you shouldn't =, we also had to use the AutoDual visibility attribute to get VB to see the public methods.

The VB code we have to interface to uses classes with property method indexers. These are probably called something else in VB, But I call it this. These look something like this (going OTOH so might get syntax wrong)

Public Property Let Reminder(index as Integer) as String
Public Property Set Reminder(index as Integer) as String

instead of being marshaled as

public string[] Reminder
{
get;
set;
}

as you might think, this gets Marshaled as

public string get_Reminder(short __p1);
public void set_Reminder(short __p1, string __p2);

which is of course correct. This is not a major, but the VB code does need changing. Also if the underlying VB array that the properties refer to are not zero based then the C# code then has to take this into consideration when dealing with the index.

oh and any normal VB property that is assigned with ByRef or more to the point, with ByVal not added then the properties get marshaled as above.

Like I said fun fun.

Heres the "killer feature" though. If you are doing Unit testing in C# of the VB Business logic that includes your C# that includes VB arrays that are marked by ref, well it won't work. It falls down in the re-marshaling back into C#. (Don't ask).

But with a bit of reflection foo it is possible.

First you have to get the type using

Type t = Type.GetTypeByProgID("mydll.dll");
object objectInstance = Activator.CreateInstance(t);

then we just simply go InvokeMethod with the Class Name, Method Name and any method arguments in an object array.

I'll post the code - don't have it on hand at the moment.

Anyway, if you can avoid COM and .NET do so. Well VB frontend to C# code anyway...

Slack

Been a bit slack lately. Haven't posted for ages.

I have a few ideas, but finding the time to do them is an issue. I bought an Xbox 360 a couple of weeks ago, and between that, learning Objective-C on the Mac, the Rugby World cup, and usual work/family/sleep patterns I just haven't had time to sit down and put pen to paper, so to speak.

However once I get Halo 3 and BioShock out of my system I plan to up the frequency on here.

Forthcoming topics will include:

Agile / XP
Nunit and Test driven development
Continuos Integration
Why VB sucks
C# 3.0 salty goodness.

BTW if you have an XBox 360, get Halo 3 and get Bioshock if you haven't already. Both are awesome. Oh and Forza 2 aint bad either.

C# 3.0 - Extension Methods

Think of extension methods as normal static utility methods you can add to any object.

Extension Methods can be defined in any class. There are only two things you need to do to define an EM. First the method must be public static in a static class, and you must add this to any parameters.

Example
public static class MyExtensions
{
   public static string AddNewLine( this string s )
   {
      return s += "\r\n";
   }
}

Usage

string s = "This is my Test";
Console.Write(s.AddNewLine());
Console.Write("I'm now on a new line");
Console.ReadLine();

This is a fairly trivial example, but I'm sure you are starting to see the power of extension methods.

In C# 2.0 days the above would be:

string s = "This is my Test";
Console.Write(MyExtensions.AddNewLine(s));
Console.Write("I'm now on a new line");
Console.ReadLine();

To my mind, the above is not as readible, but also you have to remember which utility class you put AddNewLine in, or more importantly another coder has to know which class you put the method in.

Microsoft suggest you should use your own Extension Methods sparingly and warns not to extend existing types that you don't control. This is because changes in the existing type could break your code.

I guess this is all logical stuff. I think that most people will use Extension Methods for adding utility functions to standard types, for example the one I can think of, off the top of my head would be something like ToInt() to convert a string to an Int.

Great Post

Here is a great post explaining the intangible benefits of Mac use. Gets especially insightful around page five ;-)

What do you want in a computer?

If you hate Macs, then don't bother reading on.

Anyone who reads this blog will know that I am a developer for a living, what's more I develop on Windows using Microsoft tools. Without a shadow of a doubt Visual Studio and in particular C# are the best tools for getting the job done. Period. Windows, well not so much.

When I get home, I just want my computer to work. I want to catch up on email, read and write blog posts, surf the net, watch video, listen to music and import, edit and view of Digital photos. I would estimate that 80% of computer users would have the same requirements.

I don't want to have to piss around making sure my Virus, Malware and Spyware apps are up to date and my computer is clean. I can't be arsed with my machine crashing when I'm half way through something. In other words I use a Mac. Now, I can respect people thinking they are saving money by buying a budget Dell or equivalent. I'm sure they are fine and do the job 90% of the time. More power to them. For the rest of us, I really and honestly don't understand why so many people persevere with Windows.

I think other than the fact that OSX just works without fuss and is virtually Virus and Spyware free, the biggest pro for getting a Mac is the bundled software. iPhoto, iDVD, iMovie, iTunes, GarageBand, iMail and iCal are brilliant. There are apps on Windows that do the same thing for free, but none of them are included with the operating system, or work as seamlessly.

There is a new version of the so called iLife apps out. Link here. Having seen what is on offer, I think that the new iPhoto could be the killer app to make Windows users switch. It automatically imports photos from your Camera and breaks them into Events, making it easier to view your photos. This with iPhoto's already impressive ease of use, speedy search and "it just works" factor will make viewing your photo library painless.

I know this sounds like an ad for Apple, but it's more wanting to let everybody know how much simpler life with a computer can be. If you've ever used an iPod then used any other MP3 player you will understand what I mean.

The future is Linq and Linq to SQL

I have been playing with VS 2008 Beta 2 all morning. Where to being. I will post some more specifics later but Linq - wow.

I have read some propeller heads not liking Linq to SQL, because it isn't a true ORM, whatever that means. Me, I like it. It gives enough abstraction to handle the meanial tasks, but gives me enough flexibility to let me do what I want, and not have to buggar around with config files.

Get used to seeing code like this:

var totalInvoiceValue = db.Invoices.Where( cust => cust.City == "London" ).Sum( cust => cust.ExtendedPrice );

In a nut shell, that is all you would have to do (once the mappings are setup and thats Visual) to get all the sum of all invoices for London. No more query strings. Very nice.

It is my intention to door some more posts around Linq as I get more into it, mostly so I can write down my thoughts as I find having to explain something in words help me get a better grasp of it too, and if it is useful to others along the way then all the better.

But until then, do yourself a favour and download the beta and start playing.

New iMacs Released

New iMacs here

Even though I am an unabashed Apple fan boy, I have to admit I was surprised at how cool the new iMacs are. Might even have to get one I think.

Not sure about the new keyboard, but I like the USB port at either end.

I would wait until Leopard comes out in the next month or two before getting one though. Oh and they'll run Windows just fine, trust me. I have just installed Visual Studio 2008 Beta 2 on mine and it runs great.

Tour de Farce

I have been into cycling since about 1995. I caught my first Tour on the T.V. around that time. I was captivated, awesome scenery coupled with the drama of the tour made for awesome T.V. I guess I was a little naive and really didn't know the dark under current that was perversive in the sport.

I watched year after year from then on. I loved Jan Ulrich's tour win taking the title of his team leader Barne Riis who was the defending champion. Richard Virenque winning 5 or 6 King of the Mountains in a row. Little Marco Pantani defying the odds with his awesome come back victory. Unfortunately, they were all caught cheating (well Ullrich "retired" before he could be found guilty but was implicated in a drug ring) the very sport they were supposed to love.

Then came Lance Armstrong and all was good with the world again. Even he, the most tested athlete in history, was tainted by the drugs. I firmly believe he was clean, but I'm an optimist. I want to believe.

After the on going fiasco with last years tour, it had to be squeaky clean this year. In every sense of the word. It was looking good. We had the drama of Vinokorov falling and then his heroic time trail victory and stage victory in the Pyrenees. Last year was almost forgotten. And then the bombshell. Vino and his team were thrown off the tour and he was found guilty of blood doping. Then today Rasmussen who was leading, was thrown off the tour for irregularities in off season dope testing. These two incidents are another slap in the face, in a long line of slaps in the face.

It's not the other riders, or the sponsors, or even the organizers of the tour that are hurt most. It's you and me, the cycling fan. The guys who will never make a bean from cycling, but race and train in the rain and the wind and the incessant attacks from Magpies in the Spring. All for the love of the sport. The drug cheats are killing it for everyone and have to be stopped.

What can we do?

We can hit the cheats were it hurts. In the pocket. We're the guys who buy the bikes and the wheels and the group sets and the team shirts, and show up to watch the pro's. There would be no pro cycling without us. So lets all make a stand. Let us agree, as cycling fans, to boycott the sponsors and teams of drug cheats. Lets not fuel the vicious circle any longer. We owe it to ourselves...

Old Code

As I have posted previously, I am modifying some old Delphi code I maintain. It is usually a yearly thing. The client has some requests I procrastinate and do it at the 11th hour. I am not a procrastinator as a rule, but going back to Delphi from C# is very very painful, and something I don't like doing.

Looking through my old code is painful too. Most of the stuff I did between 5 and 7 years ago. I thought I was good in those days, but well I wasn't as good as I thought that is for sure. It seems looking back, that I didn't fully grasp OO. Also I seem to put code in utility type files - just source code files with procedures and functions that don't tie in together. I see now that most of the code should have been wrapped up in classes but for some reason I didn't.

Would have made my life a lot easier now that is for sure.

It's a worthwhile and humbling experience to go through some old code. It makes you realise that there is always room for improvement and learning. I bet in 5 years the code you did yesterday that you thought was awesome will look just as bad 5 year old code does today.

A little reminder that taking a step back from your code and thinking about what you are doing is always a good thing...

ModelMaker Explorer

Recently, I have been coding in Delphi again. I have to take some code (mine) and refactor. In standard Delphi it's not a pleasure. I am using D7 which is getting a little old now, but I prefer it over 2006 which I also own.

I purchased ModelMaker Explorer to help out. It comes highly recommended. I bought it for refactoring features, but it has a ton of other useful features too, such as live metrics. I haven't checked out all the features yet, but at 95Euro it is a bargain. I wish I had bought it years ago.