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...