Rachel Pierson, Work In Progress

Carpe Diem

2019-02-26T15:22:00.000+00:00

It was a beautiful Spring morning today. So I decided to take a walk in Cambusnethan Cemetery. It's a very quiet, peaceful place where you can get a lot of thinking done. I hope you enjoy these photos as much as I enjoyed taking them.

Product Review – Dell XPS 13

2017-11-25T14:12:00.001+00:00

I left my old job recently. And consequently found myself in the market for a new laptop. I hadn’t bothered replacing my old Acer Aspire V3-571 with custom 1TB Samsung SSD that had failed within two years. Because the Toshiba Satellite Pro P50-C-12Z my old job supplied worked fine as both a home and work machine. Especially once I upgraded it with the SSD from my home laptop. However, once I left that job, I found myself relying on a 10-year-old Dell Inspiron for a couple of weeks:

That Inspiron is a loyal old work horse that has served me well as both a dev laptop and file server for a decade. And has been my go-to machine whenever other, newer, higher-spec machines have failed. It's had its screen and hinges replaced. And has had its hard drive upgraded several times with various SSDs. So saying it has lasted 10 years is a wee bit Ship of Theseus-y. But the motherboard, fans, etc have all stood the test of time. However, it just isn’t fast enough any more for modern development, so I needed a new machine.

After some research, I ended up opting for the Dell XPS 13. With 16GB RAM, 512GB PCIe SSD hard drive and the new 8^th generation Kaby Lake Processor (i7-8550U.) I initially ordered the previous model. Which was identical in all respects to the above spec except the processor (it was an i7-7550U), and the price tag: the old spec was £300 cheaper. However, after reading several reviews that all suggested the improvement in performance with the 8th gen processor is significant, I cancelled and ordered the new spec. It cost £1649 in early November 2017. At this time, in late November 2017, it is now retailing at £1547 on Amazon. That’s quite a price change in only a few weeks. Not waiting a few weeks to see how the price settled is my only regret so far about buying this machine.

The main thing that makes the 8^th generation processor so much better is that it has a Quad Core, compared to the previous generation’s dual core. So, even with a lower clock speed, the newer processor burns through tasks like building Visual Studio solutions about 60% faster than its predecessor. That’s pretty significant. Performance gains are usually on the order of 10-20% increases between adjacent versions. As the newer processors have a lower speed, they also run cooler. So, except when you’re building solutions, you almost never hear the fan kick in. I've found that browsing the internet, watching videos, and even using MS Office are all silent experiences on this machine.

I had heard that coil whine (a low pitched noise that accompanies processor-intensive tasks like watching videos) was a problem in the previous model. But I haven’t experienced that problem myself in the three weeks I’ve been using my new machine. Similarly, I had read reports of the wireless network card being unreliable; but my machine has performed perfectly. It hasn't dropped connection to my home wireless even once.

The main things that drew me to this model were the form factor. (A 13.3 inch screen in a machined aluminium chassis, that would usually only be large enough to hold a 11 inch screen in other models.) And the battery life. (Dell reports 16 hours; I’m finding more like 9 or 10. But I do have the QHD screen, which is more battery-intensive.) Every time I’ve bought a laptop before, I’ve gone for power over convenience. But to be honest, the sort of 15-inch laptops I’ve opted for in the past aren’t great for commuting (small tables on trains.) And they typically don’t have a good battery life. (I’d have been lucky to get an hour or so on battery on my old Satellite Pro.) By comparison, this machine runs and runs. If I take it to bed at night, I have to be careful not to surf (do people still say "surf"?) or work too long. Because that battery could easily see me through til dawn. As it is, if I browse the internet or watch a video for 3 hours or so at night on battery, I find I still have 70% battery the next morning. That, to me, is better than having a 10% faster machine that doesn’t last as long.)

As a development machine

Honestly, I’ve not used this laptop heavily as a development machine yet. Though I have experimented with running old Visual Studio solutions on it. A solution with 36 projects Builds in 1-2 seconds in Visual Studio 2015 Professional and VS2017 Community from a cold start. And Re-builds in about 15 seconds. That's amazing - better than any laptop or desktop I've ever had, full size or not, with or without SSD. On my old full-size Satellite Pro laptop with 1TB Samsung SSD, that Rebuild would have taken about 20 seconds. I should warn that there are some gotchas in VS2017. e.g., if you leave the Lightweight Solution Load option on (as it is by default), then the initial build time for that same project is about 40 seconds in VS2017 Community. Also, the solution sometimes doesn't build at all. So, my advice is to switch Lightweight Solution Load off completely. It's not stable enough at the current time to be of any use.

I’m always dubious about using versions of Visual Studio in the same year as they are named for. But VS2017 appears to be particularly bad in terms of buggy-ness and generally poor design decisions. (e.g., I found that the Javascript Language Service (the part that should make Intellisense work for Typescipt and JS files) has been arbitrarily turned off in VS2017 for some of my existing solutions. Seemingly because some Microsoft developer had put it in the “too hard” pile to make Javascript / Typescript work properly in VS2017.) Note to Microsoft developers: if you can’t handle more than 20MB of Javascript / Typescript files for a single solution, you’re just wasting developers’ time. Don’t bother doing less than that and considering the job done. Turning off features that worked perfectly well in previous versions of VS is pretty inexcusable. The only reason for using Typescript over Javascript is that it provides object-oriented capabilities. But you can only leverage those features meaningfully if you have Intellisense. Disabling such a key feature at such a stupidly-low threshold is like having a car whose doors fall off if you go over 30 MPH. And closing bugs about same on the basis that you meant to do something that stupid is even more stupid than the design decision was in the first place. FWIW, I fixed the problems with JS/Typescript Intellisense that are evident in VS2017 by disabling the new Language Service completely using this option:

and including the following settings in a file named "tsconfig.json" in the root of my web project:

        {
          "compilerOptions": {
           "disableSizeLimit": true,
           "module": "commonjs",
           "allowJs": true,
           "outDir": "out"
          },
          "exclude": [
           "node_modules",
           "wwwroot",
           "out"
          ],
          "compileOnSave": true,
          "typeAcquisition": {
           "enable": true
          }
       }

Anyway, this review is about my XPS 13, not the poor design decisions of the Visual Studio 2017 development team. I mention these issues with VS2017 vs VS2015 purely to note how hard it is to assess new hardware if running new software too. Sometimes, it’s not the hardware that's to blame for any failings observed. Overall, like-for-like, my XPS 13 performs better than my old Satellite Pro + SATA 3 Samsung SSD. Even though that machine was no slouch. I’m glad I bought it, and will continue to use it as my main development laptop.

Battery Life

In terms of battery life, the XPS 13 is a world away from any laptop I’ve owned before. Realistically, I get about 10 hours out of it if I’m just browsing the internet, or watching videos. As noted, I haven’t used it for actual development in anger yet. But going by the way the fan kicks when I build VS solutions, I’d suspect that I’d get around 4-5 hours max out of it at full throttle, possibly less. All previous laptops I’ve used have only got around 1-1.5 hours on battery, even if I were only browsing. So, whilst I have to be careful this doesn’t make me sit up too long at night. It is a huge improvement. That battery life is the main reason I bought the XPS 13 over its big brother, the XPS 15. Every time I’ve bought a laptop in the past 10 years, my ‘sensible’ head has kicked in and coaxed me to go for raw power over portability and battery life. With this machine, I don’t need to compromise. It provides both ultra-portability, and processing power in one package. Whilst no doubt the latest generation XPS 15 probably could out-perform this model in sheer processing time. You can’t argue with sub-5 second builds in VS2015, combined with a full day’s battery life for commuting or using in the evening for lighter tasks.

Other features

The XPS 13 has two features that I particularly like. Firstly, it has a nice, carbon fibre, rubberised keyboard surface. The keys themselves are pretty tactile, chicklet-style. As a touch typist, I find it suits me very well. But the palm rest is rubberised, which makes the keyboard pleasant to use if the laptop is cold. Had Dell opted for Aluminium all round, I think that would have made for some pretty cold hands when typing a quick email first thing in the morning. Or when transferring the laptop from a cold car boot to a warm office.

Secondly, the keyboard is well-lit. With differing levels of white lighting available. Including "off." In a dark room, that backlighting makes positioning your hands far easier. Also, the keyboard light only comes on when you type; so it's not distracting if you generally want a keyboard light, but also don't want to be distracted by same when watching a video.

Minor Quibbles

My old Inspiron and new XPS 13 both have one design feature that I find annoying. Namely, there is a battery charging light right on the front of the machine. And it can't be disabled. It goes off when the battery is fully charged, but it'd have been nice to be able to switch it off electively. My old Inspiron battery has reached a stage where it doesn't hold a charge any more; it's therefore even more annoying, as it flashes orange to warn that the battery needs replaced. My new XPS 13 is too new to be able to tell if it does the same thing, though my understanding is that it will when the battery is too old to charge any more. It'd be nice not to have to use black electrical tape to switch this feature "off."

Secondly, the webcam is badly-placed. I don't use it anyway, so it's not an issue for me. But if you do a lot of web conferencing, be aware that it is placed on the bottom-left of the screen. This is because the 13.3 inch display takes up nearly all of the height and width available. But it means that any Webex you have will involve participants looking right up your nose. Not pleasant.

Lastly, the hinge on the lid is very strong. I personally like this, as it means the screen doesn't move when you use the touchscreen. But some people have complained about having to use a whole two hands instead of one to open the lid. The main issue I do have with the lid is that it doubles as a very effective set of pliers if you placed your fingers on the hinge whilst opening. (Just as well you need both hands to open it then really, isn't it?)

Other options

Other options I considered included the Razer Blade Stealth. (In the end, I decided the lack of a 8^th gen processor, combined with the fact I could only get the “gamer” version with a green logo and rainbow-coloured keyboard lighting were deal breakers for me. Plus, support is US-based whilst I’m in the UK.) I also liked the HP Spectre very much indeed – it seems a very nice machine. Just not quite as capable as the XPS 13 in terms of power or battery life. Beautiful, though.

Product Review - Wago Connectors

2017-08-17T10:27:00.003+01:00

I was re-wiring my garage recently, when I got fed up screwing wires into choc blocks. I figured someone must have come up with a better way of connecting wires together, got Googling, and found these guys - Wago Connectors:

Wago make lots of different kinds of connectors, some of which are re-usable. Those are the ones I went for. For historical reasons, there are two kinds of re-usable connectors. The 222s:

And newer 221s:

Both kinds come in 2-way, 3-way and 5-way forms. (For connecting the respective number of wires together.) The 221s are slightly more expensive, and take up about 40% less space. But they do the same job of letting you join wires together. Potentially wires of different gauges (such as when connecting twin and earth solid-core to multi-core flex cable used by most appliances in the UK.)

I can highly-recommend these useful little guys. They sped up the job considerably, and have proven very reliable in use.

I don’t have a fidget spinner, so I kept a few of these connectors on my desk over the next month or so to footer with whilst coding. Opening and closing the levers repeatedly. From that unscientific "test", I can say that the 222s are quite a bit more robust than the 221s. After a few hundred “opening and closing” operations on their levers, the more expensive 221 wouldn’t stay open fully any more. It is still usable, and I could hold it open whilst inserting a wire if I really needed to. But then it becomes just as fiddly to use as a choc block. So if you're going to be installing/uninstalling and re-building a lot, I'd say go for the 222s. If weight is a primary concern (e.g., building a drone) then use the 221s or just solder and accept that greater build time and reduced ability to dis-assemble is the price you pay for less weight.

On the upside, the levers on the 221s are considerably easier to open. Though neither is particularly difficult. There is a dedicated tool for opening them that costs over £100, but really it's a ridiculously over-engineered solution that I can't image anybody needing. Even people that are installing these all day would have no difficulty opening them with just their fingers.

The first time you open one of the 222s, you’ll be unsure if it’s broken. Because its jaws initially open to about half way quite easily, then you need to use substantially more force to open the lever all the way. It can also give you a nasty “mouse trap” snap on your fingers if you’re not careful whilst you close the lever to clamp your wire in place.

Over all, I think I’ll be using the cheaper 222s where space isn’t a consideration. To that end, I bought a box of the 3-way and 2-way 222s, and a box of the 5-way 221s. (Since when I need to connect 5 wires together, that’s usually when space is tightest.)

With regard to their ratings, I'm honestly not quite sure what amperage / voltage they can take. The problem is there are two ratings on each model. (Presumably to satisfy more than one set of tests for different markets.)

The 222s are rated at "20A 300V" on one side and "600V" on the other side. The 221s have labels showing they are variously rated at "450V 32A" or "20A 300V". Confused?, you will be? Here is a YouTube video of someone actually burning the things out to test their limits.

In practical use, I've had no problems having about 10 of these things in the same switch. I've also used three in series on the same circuit.

2-way 222 connectors: £13.23 for a pack of 50 @ Screwfix

3-way 222 connectors: £15.13 for a pack of 50 @ Screwfix

5-way 221 connectors: £13.80 for a pack of 25 @ Screwfix

Addendum: Thelma quite enjoyed these little devices too. She reports that the 222s, being rounder, are 50% “more chasy” than the “boring” more square 221s. They therefore fly faster when she bats them with her paws to simulate spontaneous movement.

Another TrustPilot whitewash artist - Fenix Torch (www.fenixtorch.co.uk)

2016-10-17T15:06:00.002+01:00

I got this spam after making a purchase on Fenix Torch recently. I would note that I have opted out of TrustPilot spam emails several times in the past:

I particularly like the bit that says "All reviews, good, bad, or otherwise will be viewable immediately."

What it doesn't say is that any negative feedback will be immediately subjected to attempted whitewashing:

When will these companies learn? Trying to suppress negative reviews leads to worse publicity than the original review ever could have on its own.

Fenix Torch really should look up the Streisand Effect some time. Because behaviour like this only makes them look foolish.

Building a Total Quality Software environment, with Continuous Integration, Unit Testing, and Dependency Injection. And Futurama.

2015-12-25T02:33:00.000+00:00

Recently at work, I’ve been working with my colleagues to set up a Total Quality software environment. I’ve been learning a lot from my peers about topics such as VMware, RTI and Code-First EF. (I’d previously used Schema-First, but Code First brings its own advantages and challenges). What I brought to the party was some project experience in:

Continuous Integration platforms (specifically in this case, TeamCity.)
Unit Testing and Test-Driven Development techniques.
Dependency Injection to support writing testable code.
NAnt scripting.
Futurama.

We’ll get to that last one in a minute. Let’s go through the others in order first.

Continuous Integration (CI)

Everygeek who’s anynerd is using it these days. But lots of development teams and companies still avoid it, imagining it to be too difficult, too time-consuming, or just not worth the hassle. (For that matter, those same fallacious criticisms can be levelled at every other item in the list above too. Except Futurama.) A decade ago people used to say the same things about Source Control; thankfully there aren’t too many teams I encounter these days that haven’t got their head around how important that is.

Some teams aren’t even sure what CI is, what it does, or what advantages it brings. They’ve always worked by developers just producing software on their own PCs. And they just deal with any time-consuming fallout when it comes to making that software work in the real world as part of the cost of doing business.

OK, so here’s the unique selling point if you’re trying to make the case for introducing this where you work. Are you ready? What CI adds to your team’s game is simply this: repeatable, verifiable deployment.

Unit Testing and Test-Driven Development techniques

Unit Testing has been around for a Very Long Time. I know a lot of people who are otherwise very good developers but who “don’t see the point” of unit testing. And I have been such a developer myself in the murky past.

The misconception that unit testing is pointless generally comes down to a few fallacies:

They believe that their own code always works.
The wider team and stakeholders place more value on quantity of new features than upon quality of existing features.
They believe that they will always personally be around to ensure that their code doesn’t get broken in the future.

Like most good fallacies, there’s just enough truth in most of these to preserve the illusion that unit testing doesn’t provide enough advantages to the person that has to implement it. Not when compared to the opportunity costs of them learning how to do it, or the kudos of pushing out new features (that don’t work as intended.)

Part of the reason more developers don’t give it a go, is that you have to change the way you write code. Most code I’ve seen in the wild is tightly-coupled. This is a phrase that many developers are familiar with, but in my experience vanishingly few know what it means. Basically, it means that if you are writing Class A, and your class depends upon Class B to do its job, your class will instantiatiate a new instance of Class B itself. This means that if Class B stops working, all you (and Users) know is that your class “doesn’t work.” They won't care if your code is perfect, and it's just that damn Class B that let you down.

So, when doing test-driven development, developers need to add another couple of skills to their arsenal. Which brings us to…

Dependency Injection (DI)

One type of Tight Coupling is defined above. Code is also tightly coupled when it is too closely tied to one UI. So, if you’re a developer that puts all their business logic in code-behind files or controller actions, your code won’t be testable. Because your code needs the UI to do its job, before it will be able to be verified.

Fortunately, there are frameworks and coding styles out there that help developers implement loose coupling, to make their code independently testable.

The basic idea behind all of these is that instead of your Class A consuming Class B directly to perform some function, it consumes Interface B instead. That is, some object that Class A doesn’t instantiate itself, satisfies some interface that represents the job Class B was doing for Class A. Typically this is achieved by making the constructor of Class A look like this :

The above pattern is known as Constructor Injection. What it gives you is the ability to swap out whatever is implementing Interface B when it comes to unit testing Class A. So, instead of the object that really does implement Interface B in live use, you can use what is called a mock instance of Interface B. That is typically some object that always gives you anticipated responses. So you can concentrate on testing Class A. That way, any errors you see can be wholly attributed to Class A.

When you write your classes using the Constructor Injection pattern demonstrated above, DI frameworks provide concrete implementations of objects that implement interfaces at runtime. So, you 'magically' find a usable implementation or Interface B available in Class A's constructor. As the developer of Class A, you don't care particularly about where that implementation of Interface B comes from; that is the responsibility and concern of the developer of Interface B and your chosen DI framework.

This is just one of the techniques that developers moving from code that "just works" need to learn if they want their code to be verifiable. It is difficult to embrace. Because frankly writing code that "just works" is hard enough. And because using these techniques opens up the possibility of developers having to recognise errors in their own code. But unit testing also brings with it a huge number of advantages: The ability to prove that a given piece of code works, not just at the time of writing but every single time you build. And it protects your work from being modified in adverse ways by subsequent developers.

Unit testing and Dependency Injection are whole topics on their own, so I won't say more about them here. (I'll perhaps save that for future blogs.) With regard to understanding tight and loose coupling, though, I'll leave you with an analogy. If a traveller wants to get to some destination, they don’t need to know what the bus driver’s name will be, the vehicle registration, what type of fuel the bus uses, etc. They just need to know what bus stop to be at, what time, and what is the correct bus number to get on. Similarly, Class A doesn’t need to know everything about Class B or where it comes from. It just needs to know that when it requires an object to do some job, one will be available at an agreed time. Class A instantiating Class B itself is analogous to a traveller trying to build their own bus.

Last time I checked, there were something like 22 DI frameworks that you can use with .Net. The one I implemented at work recently is called Castle Windsor, which I’ve been using for a few years. In benchmark tests it’s not the fastest. It’s not the simplest. And it’s not the most customisable/powerful. But it is the one that for my money strikes the right balance between those competing factors. And it integrates particularly well with ASP.Net MVC and Entity Framework.

NAnt Scripting

Continuous Integration platforms on their own give you a powerful way of automating builds and deployments. However, there are advantages to be gained to farming out some of that work to a more specialised tool. NAnt is one such tool.

For any system that gets developed, there are typically 10-25 individual “jobs” that are involved in setting up a copy of the system that Testers and ultimately Users can access. e.g, for a web app you might need to:

Create some Virtual Directories in IIS.
Copy the files that the website is made of into the folders those VDs point at.
Customise a web config that tells the site how to access the underlying database.
Create the underlying database in SQL Server.
Populate the database with data.
Create an App Pool in IIS under which the site will run.
Grant the relevant App Pool access to the database

You’d also be well-advised to have steps that involve:

Running unit tests, so you don’t deploy broken code.
Updating Assembly Information so that each build has an identifying number. That way, bugs can be reported against specific builds.
Backing up any prior version so that you can rollback any of the above steps if the deployment fails.

If you put these in a script that lives in your project instead of in build steps on your CI server, you can more easily mirror steps between different branches in your builds.

Futurama

One of the things that motivates me is getting to have a bit of fun whilst I work. In the team I joined a few months ago, there has been one common theme tying all of the above threads together: Futurama.

Myself and my colleagues have set up about 10 Windows Server 2012 machines that perform various jobs. e.g., One of them is a Domain Controller. Another is our CI server. Several more act as paired web and sql servers that can be temporarily allocated to testing, by internal testers or by end users. Or they can be used by developers to test the deployment process.

Each of our VMs is named after a Futurama character and has its own distinct colour scheme. (NB: They have a fully-qualified name too, like DVL-SQLALPHA, that describes their actual role.) This helps developers stay oriented when RDP-ing around what would otherwise be nearly-identical machines. It’s also fun.

You saw how TeamCity / Professor Farnsworth looked above. This is how one of our Web Servers, characterised after Zapp Brannigan, looks. As you can see, it's easy to tell which VM you're on, even from a distance:

There are Futurama-themed Easter Eggs hidden in other parts of our build process too. e.g., each CI build produces a log file. At the end of which, a build gets reported as “Successful” or “Failed” for some detailed reason. A recent evening in my own time, I wanted to test implementing custom NAnt functions. (NAnt is written in C#, and you can write functions in C# to augment what it does.) In order to test this with something non-critical, I augmented that custom “Success” or “Failure” method thus:

The exact piece of ASCII art that gets rendered reflects whether the build was successful or not, and is semi-random. So, you might get Hermes with a brain slug saying something dumb if the build is broken. Or you might get Professor Farnsworth announcing “Good news, everyone!” if all went as planned.

These 'features' are of course whimsical. But at worst they give developers a smile during some of the tougher moments of the job. And at best they give you a chance to test out new techniques on non-critical features. As well as giving your brain a rest between more intensive tasks.

The best teams I’ve worked with all knew their onions on a technical level, but also knew when to have fun too. I'm glad to be working in such a team at present. e.g., I recently implemented the following function:

My colleague Ian made me chuckle when I discovered this in our code repository a few weeks later:

Product Review - Wrappz Laptop Decals and Custom Phone Skins

2015-10-10T19:40:00.003+01:00

Like many developers, I get my money's worth out of the laptops I buy. Sometimes it seems I use them every minute of the day. And, over the years, I've accumulated quite a collection of physical machines in addition to the various VMs I have carrying out miscellaneous tasks around the house.

I secretly love the obviously-marketed-at-women ones that have cases made of pink brushed aluminium and the like. But, also being a professional developer, I have to say that almost always that fancy case comes accompanied by last year's technology (or older.) It simply isn't a good business decision to buy them when you review the spec.

As a wise philosopher once said, I'm a Barbie Girl in a Barbie World.

So, I often end up buying machines that have phenomenally-fast dual/quad processors with acres of RAM capable of running lots of memory-intensive applications concurrently. And I switch out the standard platter drive for a 1 TB SSD. (I usually also swap out the optical drive for a second 1TB SSD. And 2TB SSDs that I've not yet had a chance to get my hands on have also now become available, so my next dev machine will have 4TB total, but that's really a different review.)

Anyway, for some reason the most performant laptops always seem to come in boring black boxes. When you acquire a few of these over the years, it becomes difficult to tell them apart. So for a few years now I've been putting decals on the back and naming the machine according to which decal adorns it. I also make the login screen and desktop background of these machines match the decal. This all helps keep you oriented when you're navigating around, RDP-ing from one machine to another.

TaylorHe Decals

Up to now, my go-to decal manufacturer has been TaylorHe. They do some very nice pre-made patterns that suit almost every taste. With my new work laptop, however, I fancied doing something a bit more bespoke. I'm a huge Breaking Bad fan, so I wanted a machine that had a theme related to that.

Since the device that I usually take pictures with is in this photo, my friend Ian O'Friel
kindly helped me take this. Which made it a much better photo than it would otherwise have
been as he has a real eye for photography. (You can see more of Ian's fab photos here. I
particularly like the one of the old rusty gate and the South Side At Night.)

Looking around, I found a company called Wrappz that provides exactly this type of product. Not only do they produce decals with custom designs, but they also print them on a custom-sized sheet. So you don't have to trim them to fit your machine. This may seem like a small advantage, but it was nice just to be able to use them out of the box like that rather than messing around with a scalpel or scissors.

Like TaylorHe, Wrappz also do custom phone cases. So I got one of those to match the decal. (Not that I actually own a phone, incidentally - I'm one of the few people I know that doesn't use one, and doesn't miss it. I have a Samsung Galaxy S2 'phone', but it acts as a personal organiser rather than as a communication device. I only put a temporary SIM in it when I have a reason to, which is almost never.)

If you want to order some of these decals / phone cases for yourself, here are some discount codes you can use to get them more cheaply. NB: I've got no commercial relationship with Wrappz, and I haven't benefitted in any way from this review. Also, I won't know whether anyone has used these codes:

Wrappz discount codes

More Wrappz discount codes

Last small tip for those who, like me, have multiple laptops in their network to access. You can place the name of each machine in the Task Bar by creating a new Toolbar, and calling it "\\%computername%", as described here. It makes it amazingly easy to see which machine you're on, even if you have a full-screen program running, and even if you're accessing it from another physical device.

Computer Name on Task Bar

Product Review - LED Lenser LED7299R H14R.2 Rechargeable Head Torch

2014-12-14T16:37:00.001+00:00

I bought one of these for running during the Winter months, when you inevitably find yourself having to make some runs in the dark or twilight.

There are plenty of options out there - ranging from an offering at £5 from Tesco, right the way through to Hollis Canister diving head torches at £800. Obviously, there’s a trade off between getting what you pay for, choosing a light that’s suitable to your purpose, and not spending more than you need to.

After checking out other reviews for several different options, I opted for the LED Lenser LED7299R H14R.2 Rechargeable Head Torch. You can spend anything from £90 to £130 depending on where and when you choose to buy this model. There’s also a similar-but-cheaper model in the same range that isn’t rechargeable. (No reason that you couldn’t buy separate rechargeable batteries of course.) However, I liked the convenience of having the recharging unit built in. It can alternatively take four conventional AA batteries, which you can use as a backup.

For running, it was important that the torch had enough light output to be able to see in pitch darkness on unlit trails with occasional tree cover that blocks ambient light. It was also important that it was comfortable to run with. A lot of runners recommended the Petzl range of head torches. I can see why. They’re a lot lighter than the one I chose (whilst at the same time being a lot dimmer - typically about a third to a quarter of the light output.) My main criticism of the LED Lenser H14 R2 is that it can feel a bit hard and uncomfortable on your head, particularly the front torch holder. A softer, more padded material behind the lamp would have made it much more useable. As is, it’s more comfortable with a beanie hat underneath, but I wouldn’t fancy trying to run with it overnight in the Summer when a hat would make you overheat.

In terms of light output, it was difficult to find reliable information. The minimum light output was fairly consistently reported by various sources to be 60 Lumens. The product box and the site where I bought it both say the maximum output is 850 Lumens. Other sources quoted as low as 260 to 350 Lumens.There appears therefore to be some confusion about what is meant by "maximum". Namely, the torch has a 'boost' setting that increases brightness for 10 seconds at a time. However, there is a second definition which is the maximum brightness that the torch is able to consistently maintain. I suspect this distinction accounts for many of the differences reported by different sources.

60 Lumens is about as good as the majority of the Petzl range. The brightest setting for the H14 R2, whatever the real value in Lumens, is a very bright light that is uncomfortable to look at directly at the highest setting. The very highest setting (known as the "boost" setting) only stays on for 10 seconds at a time. Most of the rest of the time, I used it at the highest 'stable' setting.

On that highest constant-current setting, the light can be diffused over an area about 5m wide and 10m far directly in front of you. You can also elect to have a narrower but more intense beam. The specs say it will project light up to about 260m. I found that not to be the case, though I did stick to the “wide and bright” setting throughout my run. Perhaps the boost setting when combined with the narrowest beam would momentarily illuminate the farther "260m" distance quoted for 10 seconds at a time; I didn't test that, because such brief and narrow momentary brightness isn't relevant for my use case or many others I can imagine. I did test the range on the max consistent setting combined with a wide beam when I returned to my car. I found that whilst that setting is quite good enough for running/walking in the pitch dark by allowing you to see what's immediately in front of you, the light didn’t even make it across to the trees at the far end of the 100m or so car park I was in. I’ll try it again on the “narrow beam, temporary boost” setting during my next night run. However, whilst I suspect that the specs are technically correct and that objects will be able to be illuminated at that distance, albeit briefly, it is only with a beam that’s about 1m wide. It's for the reader to decide whether that performance meets their actual needs.

I found the light was good enough for my use case. I ran during astronomical twilight (the third darkest phase of the night; pretty much pitch black for the purposes of this test.) Without the torch, I would just about have been able to see my hand in front of my face in open ground, but not the path I was running on. On stretches covered by trees, it'd have been completely dark. As it was, I missed a pothole in the same forested location (once on the way out, and once on the way back.) I couldn’t see how I’d done this at the time, as I felt I’d been seeing the path well enough to run at a normal pace. I stumbled at the exact same spot again, however the very next day during daylight. So, it just appeared to be a particularly well-camouflaged pothole, rather than a failing of the torch.

The final lighting feature of note in this torch is the rear red light that you can turn on to allow traffic and cyclists to see you more easily. I thought that was a nice little safety feature. Although, there's no real way to tell if it's on or off once you have the torch on, and the button is very sensitive. Other non-lighting features include a battery-power indicator (the rear LED glows red, amber or green for five seconds when you switch it on, to let you know how charged up the battery is.) I've used mine for less than an hour so far, and it's still in the green from its first charge. I'll update this review with how long a full charge lasts when I've gone through a full cycle. Lastly, you can detach the battery pack (and the front torch itself if you want) and wear them as a belt attachment. I personally prefer the light being cast wherever I'm looking, and didn't find the battery pack intrusive where it was, so haven't used this option.

The last point I want to note about this product isn't about the torch itself. It's about the user manual that comes with it. For a top-of-the-range piece of kit, the quality of the instruction manual translation leaves a lot to be desired. It's some of the worst Deutsch-glish I've ever seen. Take this excerpt for example:

It's so bad that at first I thought I might have been sent a fake item, since I couldn't imagine any self-respecting manufacturer allowing such a poorly-translated document to accompany their product. But, the supplier I used (ffx.co.uk's) bona fides checked out. And, checking with LED Lenser's own website, it seems that they've just done a very bad job of translating the user manual of an otherwise very good product. You can read the full manual (downloaded from LED Lenser's US site) for yourself here.

All-in-all, I’m glad I bought this piece of kit. It’s good enough for what I need it for. The head harness could be a little more comfortable, but it’s very usable for its intended purpose nonetheless. I feel a Petzl and other cheaper options would probably not have been bright enough for what I need. And other more expensive options would have been brighter still, but wouldn’t have been designed to wear out of water.

Not a bad purchase : 7/10

Scalability, Performance and Database Clustering.

2014-02-20T16:29:00.001+00:00

What the Exxon Valdez and database clusters have in common

I was recently asked to comment on the proposed design for a project by a prospective new customer. The project involved a high number of simultaneous users, contributing small amounts of data each, and was to be hosted in the Cloud. The exact details were To Be Decided, but Amazon EC2 and MySQL were floated as likely candidates for the hosting and RDMS components. (Although my ultimate recommendations would have at least considered using SQL Azure instead, given some of the time constraints and other technologies involved that would have dovetailed into the wider solution.)

The discussion got me thinking about the topic of database clustering, as it relates to performance and scalability concerns. During the course of the discussion of the above project with the client’s Technical Director, it transpired that, despite the organisation concerned having used clustering in an attempt to improve performance previously, that approach had failed.

The above discussion didn’t surprise me. It’s a misunderstanding I’ve witnessed a number of times, whereby people confuse the benefit that database clustering actually bestows. In short, people often believe that using such a design aids scalability and performance. Unfortunately, this isn’t the case. What such an architecture actually provides is increased reliability, not performance. (It’s actually less performant than a standalone database, since any CRUD operations need to be replicated out to duplicate databases). Which is to say that if one database goes down, another is in place to quickly take over and keep processing transactions until the failed server can be brought back online.

The analogy I usually give people when discussing the benefits and limitations of clustering is that it’s a bit like the debate about double hulls on oil tankers. As you may know, after the Exxon Valdez disaster the US Government brought in legislation that stated every new oil tanker built for use in US ports was to be constructed with double hulls. The aim was admirable enough: to prevent such an ecological disaster from ever happening again. However, it was also a political knee-jerk reaction of the worst kind. Well intentioned, but not based on measurable facts.

Of perhaps most relevance to the topic was the small fact that those parts of the Exxon Valdez that were punctured were in fact double-hulled (the ship was punctured on its underside, and it was double-hulled on that surface). Added to this is the fact that a double hull design makes ships less stable, so they’ll be that little bit more likely to collide with obstacles that more manoeuvrable designs can avoid . And, just like in database clustering, the added complexity involved actually reduces capacity. (In the case of ships, the inner hull is smaller; in databases the extra replication required means less transactions can be processed in the same amount of time with the same processing power.)

As with all things, the devil is in the details. You can design clustered solutions to minimise the impact of replication (e.g., if you make sure the clustered elements of your schema only ever do INSERTs, the performance hit will be almost negligible). But, many people just assume that because they are clustering that in itself will automagically increase performance, and it’s that misconception that leads to most failed designs.

I’ve been involved in a couple of projects that involved either large amounts of data in one transaction impacting on a replicated database, or large numbers of smaller individual transactions being conducted by simultaneous users. In neither case, in my experience, was clustering a good solution to the design challenges faced.

The first project I have as a point of reference was one I worked on back in 2007, that involved a business intelligence application that collected around a million items of data a month via a userbase of 400 or so. I was the lead developer on that 7-person team, and so had complete control over the design chosen. I also had the advantage of having at my disposal one of the finest technical teams I’ve ever worked with.

The system involved a SQL Server database that was used by around 30 back office staff, OLAP cubes being built overnight for BI analysis, and certain sub-sections of the schema being replicated out to users that accessed the system via PDAs over GPRS (which of course will have been replaced by 3G / 4G now). The PDA users represented the bulk of those 400 users of the system.

The design we settled upon was one that traded off normalisation and database size for the least impact on those parts of the schema that needed to be replicated out to the PDAs. So, CRUD updates made in the back office system were only transferred to near-identical, read-only tables used by the PDAs once an hour (this could be fine-controlled during actual use to aid performance or to speed up propagation of information as required). This approach meant that the affected tables had less sequential CRUD operations to be carried out whenever the remote users synched over their low-bandwidth connections. And if they were out of range of connectivity at all, their device still worked using on-board, read-only copies of the backoffice data required.

The second main consideration in the design involved a large data import task that happened once every six weeks. One of my developers produced a solution that was algorithmically sound, but that quickly reached the limitations of what an ORM-driven approach can do. In short, it took several hours to run, grinding through thousands of individual DELETE, INSERT and UPDATE statements. And if any consistency errors were found in the data to be imported (which was not an uncommon occurrence) the whole process needed to be gone through again, and again, until eventually it ran without hiccups. It wasn’t uncommon to take a skilled DBA 24 hours to cleanse the data and complete the import task successfully. Meanwhile, the efficiency of those replicated parts of the schema used by the PDAs would be taking a battering. A better approach was needed.

In the end, I opted for using SQL Server’s XML data type to pass the bulk upload data into a stored procedure in a single transaction. Inside the procedure, wrapped in a reversible TRANSACTION, just those parts of the data that represented actual changes were updated. (E.g., it wasn’t uncommon in the imported data to have a DELETE instruction, followed by an INSERT instruction that inserted exactly the same data; the stored proc was smart enough to deal with that and only make those changes that affected the net state of the system). I designed the stored proc so that any errors would cause the process to be rolled back, and the specific nature of the error to be reported via the UI. The improved process ran in under a second, and no longer required the supervision of a DBA. Quite a difference from 24 hours.

The second project that informs my views of clustered database designs was one that I wasn’t the design authority on. In this case, I was just using the database(s) for some other purpose. Prior to my involvement, a SQL Server cluster involving three instances of the database was set up, and kept in sync. The solution was designed for use by a vendor of tickets for all sorts of events, including popular rock concerts. It wasn’t an uncommon occurrence for the tickets to go on sale, and for an allocation of many thousands to be sold out in literally ten seconds flat, as lots of fans (and I’m sure ticket touts too) sat feverishly pressing F5, waiting for the frenzy to start. (And sometimes, if the concert organiser got their price point wrong, you’d find that only a few tickets were sold for an over-priced event, but that’s another story!)

In the case of this design, I never did see the failover capabilities come into play. Which is to say that each of the three SQL Server instances that replicated the same data for reliability reasons all stayed up all of the time. I had a feeling that if one ever went down for reasons of load, however, it wouldn’t have been long before the others would have suffered the same fate. And since it was an on-premise deployment rather than being cloud-based, something like a power cut would have stopped the show dead.

It’s not that common for hardware to fail just because a high number of requests are being made simultaneously. All that will happen is that some users won’t get through (and you as the site owner will never know that was the case). It’s not like the server will shut down in shock. Even the recent low-tech attacks to large online retailers like Amazon using amateur tools like LOIC didn’t damage any critical infrastructure. At best, such conditions can saturate traffic for a short while. And often they don’t achieve even that much.

As a final point, I’d note that there are far greater concerns when designing an authenticated, public-facing system, such as CSRF vulnerabilities. Any attempt to address performance concerns by using clustering will inevitably adversely affect those security concerns. Because commonly-accepted solutions to same typically rely on data being reliably saveable and retrievable across short time frames (rather than getting in sync eventually as most clustering solutions allow for).

So, in summary, whilst there’s a place for database clustering for reasons of reliability, my earnest advice to anyone considering using that design for reasons of performance or scalability is to reconsider. There are usually changes you can make to your database schema itself that will have the same or better impact on the amount of data you can cope with in a short timeframe, and the impacts that data will have on your wider design. Don’t end up like Fry from Futurama, lamenting how your design might have worked had you only used (n+1) hulls/servers rather than n :

Tools for Assessing Software Developers

2013-07-16T20:46:00.000+01:00

It’s been a while since I last wrote on the subject of how to hire great software developers and weed out any applicants that aren’t experienced enough for the more senior positions within your team. Given the advent of new tools that are available to conduct such interviews, I felt it was worth updating my previous advice on the subject.

Skype is probably the single biggest game-changer in technical recruiting in recent years. Particularly if distance is an issue, using Skype to conduct interviews is a no-brainer.

Previously, phone screens were the de facto best way of carrying out an initial sift of shortlisted candidates. And to be honest they were never that good of a predictive indicator. What’s different about Skype is that, provided the candidate in question has an IDE at home (and most experienced developers do) you can use it to quickly screen candidates’ coding ability. There’s nothing like seeing someone actually using an IDE right from your very first ‘meeting’ to get a feel for whether the experience they profess to have on their CV actually translates into meaningful skills that they’re capable of applying to realistic business problems.

Skype allows you and the candidate to see one another. For the hirer, that enables you to get feedback from any non-verbal cues about their interest in the job and aptitude for same. It also allows you to screen-share, so you can see what they’re typing in real time in their IDE. In those respects, Skype is even better than trying to conduct a similar process in person, because you don’t need to crowd around a laptop screen or use a projector to be able to see them at work.

So, by all means don’t rule any interesting CVs out on the mere grounds that the applicant doesn’t have a webcam, a development setup at home, or a fast enough internet connection to facilitate a video call. But if they do have those assets available it makes it much easier to confirm their ability in a matter of minutes, before either party has invested any great amount of time in the process.

The second biggest innovation in recent years, in my opinion, is Github. It’s always been desirable for candidates to provide code samples as a means of demonstrating their skill. However, previously you could never be sure that any work submitted was a candidate’s own. Most candidates are honest. Just occasionally, however, you’d identify someone that had provided an impressive ‘code sample’, but who it later transpired couldn’t programme a tenner out of a cash machine. Wherever they had plagiarised such samples from, it was clear that they didn't actually understand them themselves. (Such antics are quite probably how this guy here got his job.) It’s a waste of both of your time if you only discover this fact when it comes to sitting down in front of a laptop at interview and you ask the candidate to take you through their solution, only to find they can’t explain the first thing about how it works or why certain design choices have been made.

Github aids candidates’ credibility by being a freely-available online source control solution, that verifiably identifies the authors of any content submitted. Not only can you freely download any complete solutions that have been placed there, but you can see the individual check-ins that went in to producing each solution and the thought processes indicated by the comments associated with same. If you know what you’re looking at, those fine details tell you much more about a candidate than a mere CV full of buzzwords and all the glowing references in the world ever could. And unlike copying whole solutions you didn't write yourself, forging a history of the individual check-ins that go in to making up a complete solution is all but impossible.

With Github, you can also confirm a demo project’s creation date. This is important. Do you ever get the impression that candidates’ CVs are merely re-wordings of your job spec? This is in some ways understandable, and arises from the fact that the standard advice jobseekers are given is to tailor their CVs to highlight relevant experience. But still, as a hiring manager you sometimes would prefer to see what a candidate felt their own strengths were, before they knew what you were actually looking for. Github gives you that insight. If you’re looking for someone that has experience in Technology ‘X’, being able to see that they’ve completed a project using that technology some months before your particular requirement even came up is a pretty convincing demonstration that the candidate actually does know what they’re talking about when it comes to the subject concerned*.

(* That said, outside of specialist contracting roles, where you do expect new hires to hit the ground running from day 1, hiring software developers should rarely if ever merely be about hiring a particular skillset. It’s always better to instead hire for aptitude and attitude, and train for skill when you need to. Because new technologies come up all the time, and it’s no good hiring one-trick ponies that are incapable of keeping up with constantly-emerging technologies. Or, worse still, people that may be gifted as individuals but whose personality problems render them unsuitable for teamwork. You can teach people with the right aptitude and temperament almost any technical skill they need to know. The best ones will be capable of constantly improving themselves. But you can’t teach them not to try and use their one golden hammer to solve every single problem they come across. And you can’t teach them not to be an arrogant control freak that alienates their peers.)

The above are great ways to identify talent. That said, I know from working with a great many talented software developers over the years, that a lot of them don’t have the time to work on open source projects on Github whilst they’re fitting a family life around about being great assets to their existing employer. And some of them live in places where the internet connection is slow, making Skype a difficult option.

So, for people for whom Skype and Github aren’t options, there is a Plan ‘B’ you can use. A less-preferable secondary approach that also works is to conduct an initial phone screen using a stock list of questions. I’m loathe to suggest an undue correlation between merely knowing the answers to some coding trivia questions and actual meaningful ability as a software developer. One is merely knowledge, the other is a demonstration of actual intelligence. However, there are just some basic things that you should know about any language or technology you profess to be proficient in, and that knowledge can be used as a baseline check if need be.

E.g., for a junior level C# developer, I’d expect them to know:

Q. What is an Abstract Class?

A. One that is only intended to be used as the base for other classes, but that may not be directly instantiated in and of itself.

Q. Tell me three basic variable types in the common type system?

A. Take your pick from any of these.

Q. What are the scopes you may use to limit Field/Property visibility, and to what extent do they make these aspects of a class visible?

A. Public, Private, Protected, Internal and Protected Internal.
(NB: I wouldn’t fault anyone for failing to name that last as a distinct scope in its own right, whose limit is a combination of that afforded by ‘Protected’ and ‘Internal’.)

The key thing is that there are no trick questions here that would require knowledge of obscure parts of the .Net framework. Candidates may or may not not happen to have used certain discrete parts of the 4000-plus namespaces in the .Net Framework, but good developers could easily look up and utilise any part of the Framework if they needed to with only a couple of hours research. Asking about the features of a specific namespace is therefore pretty meaningless. The questions above instead just concern basic, core features of the C# language. Anyone that has used C# at all should be reasonably expected to be aware of them.

Questions like these don’t help you identify whether someone is a great developer or not. Seeing how candidates write actual code using a real IDE is the only thing that enables you to do that. These questions are purely intended as a baseline negative check to help you identify any manifestly-unqualified candidates where the other preferred means of confirming ability mentioned earlier are unavailable.

For more senior C# developers, I’d expect them to know more advanced, but still core, features of the language. E.g., :

Q. What is a Delegate?

A. A pointer to a function. They’re used in lots of ways, but a typical example would be to assign a handler to an event.

Q. What’s the difference between a class and a struct?

A. The first is a Reference type, the second is a Value type. This affects where they’re stored in memory, and how assignment between variables of the types concerned work.

Q. Can you explain the principles of object oriented design?

A. I’m looking for them to be able to succinctly tell me what Inheritance, Abstraction, Polymorphism and Encapsulation are.

For a Lead Developer or Architect, I’d expect them to be able to speak meaningfully about:

Can you describe some Design Patterns? (e.g., please explain what Singleton is, What is the Decorator pattern? Tell me about a time when you used them?)

What are your thoughts on Inversion of Control / Dependency Injection? What about Test Driven Development? Do you always use them on every solution?* If not, what criteria do you use when deciding whether to expend the additional effort? What are the limitations of IoC? Which of the 22 plus frameworks that presently exist have you encountered on live projects?
(* FWIW, I personally believe that using these presently-fashionable methodologies and techniques on every single project is about as misguided as never using them.)

What is an abstract class?*
(* The observant will notice that this last question is the same question used for junior developers. It’s amazing how many Architects can recite high-level summaries of chapters from the Gang of Four, but who’ve lost touch with how coding actually works in the trenches. It gets more difficult as your career develops to keep in touch with the front line, but my personal belief is that you can only lead great developers if you actually share their pain by hitting a keyboard yourself once in a while. You certainly shouldn’t exhibit any signs of Hero Syndrome or micro-managerial tendencies by needing to be involved in writing every line of code yourself, and you shouldn’t try to do developers’ thinking for them. You need to entrust and empower those you lead by allowing them the freedom to get on with any tasks you delegate to them using their own skill. However, it is important to implement a particular feature yourself every so often, purely to keep your own skills current in an ever-changing technical landscape. Otherwise you only lose touch with emergent technologies. A clear sign that you aren’t getting enough personal keyboard time is when you begin to lose the basic knowledge that even junior developers working under you are expected to possess.)

For any one topic that I consider myself experienced enough to assess others in, I have a list of about 200 such questions that represent basic knowledge I’d expect most people to know at each level. During an initial phone screen, selecting two or three such questions as baseline checks is the next best alternative to using Skype or Github to assess whether there’s any potential.

I wouldn’t lose sleep over anyone getting any one individual question wrong. (Especially if they’re honest enough to admit they don’t know a particular fact. The very best people show awareness of things they don’t presently know, whilst less skilled individuals are often paradoxically unaware of their own current limitations. That inability to perceive their own present weaknesses leads to them failing to ever improve. This is known as the Dunning-Kruger Effect.) I still prefer actually seeing a person code using Skype, Github or even YouTube in preference to using coding trivia as an initial screening tool, but phone screens using basic questions to eliminate candidates is the next best option for the initial sift of candidates that invariably apply to almost any openly-advertised technical position. You can apologise to the ones that find it ridiculously easy afterwards, and explain the reasoning behind your using such simple baseline checks.

Skype and Github are better options because they represent positive checks for ability, whilst asking baseline questions is merely a negative check to identify the absence of basic knowledge. However, if a candidate can’t answer any of the simple baseline questions appropriate to their level of seniority, that’s clearly someone that you won’t take forward to interview.

For anyone that attends an in-person interview, I’d always recommend seeing them code using an actual IDE. (If you’ve seen them do so via Skype previously, obviously you can skip this step). The best way to do this is to attach a projector to a laptop that’s loaded up with a full IDE and an internet connection, and watch them work. I once had a hiring manager tell me that they used pen and paper coding exercises instead “because they didn’t want the candidate to have access to Intellisense, and all those other ‘cheats’ that a full IDE provides”. No, I don’t understand the logic behind that one either. I found myself wondering if they’d ask a prospective master carpenter to bang in nails wearing a blindfold, and decide from how swollen their thumbs were afterwards which was the ‘best’ at their craft.

Just like when you’re using Skype, you can record candidates’ efforts to build a quick solution using free tools like CamStudio recorder if you like. That approach can be very useful if you work in a large organisation and have a wider selection committee that will need to review the interview later on. It can also feel a little like an unfriendly interrogation, though, so you need to decide what’s right for your own organisational culture. Personally, I’d only record a coding test if there were a need to show the recording to other members of your recruitment panel afterwards. And I would explain to the candidate that the purpose was to save them having to demonstrate their ability multiple times to different people.

It’s important to make clear that the problem you’re asking them to solve constitutes realistic work, but not real work on an actual business problem. The first activity is a meaningful test of their skill. The second would merely represent unpaid work, and that would risk making you look like a freeloader. One problem I’ve seen used in the past and that I thought was a pretty fair baseline check read something like this:

“Design a system that allows you to model shapes as objects. Each shape should be capable of outputting a text description of itself. The description given in each case will be:

‘I am a _________. I have ____ sides, and ____ corners. My colour is ______. Their lengths are _______.’

There will be appropriate Properties in any classes you use to model such shapes to store the information to be supplied in the blanks in the above description.

You can implement this solution using any UI you like. Have specific classes that describe the shapes ‘triangle’, ‘square’, ‘rectangle’ and ‘circle’”

A developer should be able to come up with a simple design that has a base (possibly abstract) class that provides any shared Properties like colour, numSides, etc. They can either implement a Method in that abstract class to allow a string description to be output, or they can override the default ToString method. Classes describing the specific shapes requested should be inherited from this base. Extra points for having the perception to make appropriate properties/fields read only in more specific classes (i.e., you don’t want consumers to be able to create a triangle with four sides). Points too for using inheritance where appropriate (e.g., realising that a square is just a more specific instance of a rectangle.) Nothing too taxing, and no trick questions or tasks that would take an unreasonable amount of time. Just a simple problem to allow developers to show that they’re not a non Fizz-buzzer.

As this is a blog about assessment tools, it’s worth mentioning ‘online’ tests like ProveIT, Brain Bench, and Codility. These ‘tests’ fall into two main categories:

Tests that attempt to assess ability based on being able to instantly-recall knowledge of obscure parts of particular frameworks.

Tests that try to assess an actual ability to write code, but not using an actual IDE.

My opinion on using obscure trivia to assess problem-solving ability is well-documented. I’m with Einstein on this one, who when asked what the speed of sound was once said that:

“[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think.” *

[ * New York Times, 18 May 1921 ]

I don’t consider memorising a lot of obscure and easily-obtainable facts to be a good indicator of programming ability. Nor do I consider not being able to recall such facts at will to be an indicator of a lack of ability. Developers have Google and reference books available on the job. I’m therefore only concerned with testing those aspects of a developer’s ability that those tools can’t provide.

That leaves those online ‘tests’ that attempt to assess coding skill, such as Codility. There’s nothing wrong with the basic idea of getting candidates to write code as a demonstration of their existing ability and potential. However, there’s a big difference between writing code using an actual IDE, and attempting to write code using a web browser (which is how Codility works). In a real IDE, you have Intellisense, code snippets, meaningful object navigation (e.g., if you place the carat on the usage of a class or property in Visual Studio and use the F12 key, it’ll take you to where that class/property is implemented), colour coding of keywords and objects, compilation checking as you type, etc, etc. Codility advocates believe that because that assessment tool has a “compile solution now” button at the bottom of the browser window that amounts to the same thing. It simply doesn’t. Going back to my earlier analogy about inappropriate ways to assess carpentry skills, you’ve merely gone from using a blindfold to asking the candidate to wear sunglasses in a dimly-lit room.

Codility tests run in a web browser

The main problem with Codility et al, however, is simply this. They don’t give you anything that you don’t also get by watching a candidate solve a real problem using a real IDE. Because of this, you invariably find that these tools are preferred by interviewers that don’t possess skills in the language concerned themselves. Such interviewers don’t use an IDE / laptop with a projector approach, because they simply wouldn’t understand what it was they were looking at. By using Codility instead, they’re generally looking for an ‘easy’ way to understand whether a given solution is ‘right’ or ‘wrong’, without having to go to the trouble of understanding why such a value judgement has been arrived at themselves. Good candidates are aware of this, and the best of them will be concerned that if you only understand how good they are because some automagically-marked test tells you what to think, how are you going to be able to fairly assess their performance on the actual job in the absence of such feedback?

Everyone knows that good interviews are a two-way street. Candidates are assessing you and your organisation just as you are assessing them. Sending a signal that you don’t understand what it is that they do can damage your credibility and your employer/manager brand considerably. So, if you’re not technical yourself (and some managers aren’t), I’d generally recommend instead asking one of your existing staff that you trust to be able to make a meaningful assessment of a candidate's ability to accompany you when assessing candidates’ technical fit.

A second problem with Codility, in my opinion, is that solving discrete problems using technology in the real world rarely works in such black and white terms as a solution being ‘more’ or ‘less’ right than other approaches. There are generally a great many ways to satisfy any one problem. Which one(s) is/are ‘correct’ is all about context. Tests that focus on an overly-narrow set of criteria when determining success may not always identify the best candidate, even if they identify someone that produces the fastest solution, or the one that uses the least (or most) lines of code to solve a problem. e.g., if someone were to use the line 123 << 4 to get the result 1968 instead of writing 123 * 16 , that might be the genius you need to optimise nanoseconds on calculations within the firmware for a graphics card, or they might just be That One Guy that writes unreadable code that produces hard to find bugs. (Mostly, though, they’ll just be someone that doesn’t realise low-level arithmetic optimisations like bitwise operators are largely meaningless in languages like C#, where high-level code is converted at compile time into optimised MSIL before being converted into even more optimised machine code specific to the hardware it’s running on.)

You can try Codility for yourself here, and I'd strongly recommend that you do so if you're considering using it to fairly assess candidates. It's not enough just to get someone else to look at the test for you, unless you ask your chosen guinea pig to work under the exact same time constraints as candidates will be asked to work to. That also means they only get one shot at the test, just like candidates.

In the interests of debunking The Emperor's New Code, when I tested Codility out as an assessment tool I found that I didn't produce a 100% solution myself first time in the time allowed. I therefore felt it'd be unfair to ask candidates to do something that I myself couldn't.

I doubt that many people could produce an 'optimal' result in the timeframe allowed, particularly when you don't get to see the criteria that will be deemed to constitute an 'optimal' solution before submitting your answer. When they only have a short window to think about the problem, candidates will be inclined to focus on providing a solution that works rather than one that shaves milliseconds off of the runtime. And even where candidates do provide an 'optimal' solution, there doesn't seem to be much allowance for readability in the simplistic percentage score returned.

I suspect that most 100% results that users might see from this tool may be best explained by the fact that there are many solutions to the tests published online, and some candidates will be inclined to copy one of those.

This deliberately-obscure and unreable
solution scores 100%

(Full-size view available here)

This shorter and more readable solution also scores 100%

My overall conclusion: companies that let computer algorithms select the best people to work for them rather than the other way round may well be disappointed by the results.

BranchedMigrator : A Database Schema Management Tool

2013-06-30T19:10:00.000+01:00

NB: Owing to YouTube's policy of trying to force Google+ on YouTube members, I no longer
host content on YouTube. Apologies for the inconvenience.

I recently got round to doing a bit of work on an open source project of mine called BranchedMigrator. Inspired by Sean Chambers’ wonderful FluentMigrator, it’s a database schema versioning tool for use in continuous integration environments.

You can download a copy here.

A Guide to The Cloud, Part 1 - For Muggles

2013-03-02T17:00:00.000+00:00

In recent years, I’ve been involved in a number of cloud computing projects. Most recently, this included a very enjoyable project working for a forward-looking games company based in Glasgow. This blog post is intended to dispel some of the myths that linger about the various technologies that enable cloud computing projects to work. The content in this first part is primarily aimed at non-technical managers looking to get an understanding of what the cloud can do for them. In Part 2, aimed at a more technical audience, I’ll delve more deeply into the underlying technologies.

“The Cloud” is one of those buzzword phrases that’s been bandied around an awful lot. In the process, it’s had its meaning stretched and diluted a great deal. There’s been a lot of misinformation about what does and does not constitute a cloud computing project / platform. Common aspects of the various definitions I’ve encountered have included:

Applications that are web-based.
The hosting of those web applications, and the databases that underlie them, on remote hardware that isn’t located in the same building as the development team.
Lower hardware maintenance costs.
The ability to scale applications as an application’s user base grows.

A difficulty with some of the discussion that has fallen under the “cloud” umbrella, is that some or all of these qualities are also found in projects that are not true “cloud” applications, and never will be.

For the avoidance of doubt, when I speak of cloud computing projects, I am talking specifically about projects that encapsulate all of the following discrete qualities:

They are web applications that are accessible across the open internet, and are designed from the ground up to be deployed to dedicated cloud-computing platforms. This involves considering scalability, security and ease of deployment (discussed below) as primary design goals. It is not simply taking an existing Java EE 6 or ASP.Net application that was once hosted on internally-managed hardware and deploying it to a small number of servers in a single data centre.
Projects where the hardware to which the above solutions are deployed is not directly managed by the party that owns/writes the software. That is, an organisation that deploys a solution ‘to the cloud’ typically doesn’t know or care about where the physical server upon which their application runs resides, beyond broad geographical considerations. So, whilst it’s often possible to choose between “Asia”, “Europe”, “North America”, etc, when deciding roughly where your application will be hosted, if your hardware management is any more fine-grained than that then you are not using cloud technologies at all; you’re simply remotely-managing hardware that you are still heavily-invested in maintaining yourself.
Solutions where you can scale your application to serve a greater number of users quickly and reliably. This typically involves a combination of leaving managing any physical hardware up to the third party you purchase cloud hosting services from, and an awareness within the development team of scalability issues as they apply to software design.

In Part 2 of this blog post I’ll get into some specific technical implementation details involving one particular set of cloud technologies: Windows Azure and ASP.Net MVC, in conjunction with SQL Azure. But first, let’s have a look at some general design considerations that apply whichever cloud platform you are using, and that should be clearly understood by technical and non-technical managers of cloud computing projects alike:

Security

I’ve worked on a range of types of application that have been used for a wide variety of purposes, from the very most trivial you can think of to mission-critical applications that needed to work every single time. An example of the diverse range of problems I’ve been involved in solving includes:

· Automating precision engineering manufacturing processes for producing delicate parts that keep satellites in orbit

· National power utility infrastructure management

· DV-cleared national government work

· A national police project

· Investment banking applications aimed at Anti Money Laundering

· A system for designing custom zombies for use in online games (seriously)

All of which is to say, I fully appreciate the need for security and I have a wide enough grounding in a diverse range of applications that required same to be able to make an informed judgement about whether cloud technologies are sufficiently well-protected to be able to use for each of the above discrete applications. I get it. Really I do. (Hey, there’s nothing more important than protecting society against the ever-present threat of a zombie apocalypse, right?)

I suspect that most if not all of the Public Sector and banking organisations with whom I’ve worked would be horrified at the idea of storing their sensitive data on hardware they didn’t physically control. (Even though many organisations in those sectors experience very serious problems anyway, even when working solely with hardware they get to fully manage in ways with which they are more comfortable.) There’s something falsely-comforting to the uninitiated about having physical control of actual touchable hardware. It’s the same misguided illusion of security that makes some people store all their life savings under a mattress rather than putting it in a bank for safekeeping.

As well as the psychological difficulties some organisations/managers have in letting go control of physical hardware, in Europe specifically there are also some rather ill-conceived and as yet legally-untested rules concerning the processing of data outside the EU. So, if you operate there you might be forgiven for wondering whether you are allowed to store sensitive customer information on physical hardware that may be located outside Europe, even if you might wish to do so. Like the EU cookie law, it’s nonsense that’ll get over itself soon enough. But still, misguided and vague concerns like these allow people with a predilection to do so to spread worry and doubt about the security and legality of using cloud technologies they don’t fully understand, to solve problems they’d rather would just go away.

Without getting into the technical details too deeply at this juncture, in summary it is possible to easily encrypt data to a level where even the most sophisticated state/non-state actors can’t access it. If desired, it’s possible to encrypt all of the data you store on cloud servers, or just those parts that are particularly sensitive like passwords. Implementation details aside, most of the encryption schemes in use today use the same public key cryptography principle (though new approaches can and are being developed all the time). It’s the same process that allows you to safely access your bank account online, and make purchases from online retailers without risk of a third party being able to intercept and misuse your details. It’s safe: if it weren’t, there would be a lot more online fraud than there is.

Some organisations that operate in the cloud include: Amazon, Google, Microsoft and the National Security Agency. So, if anyone ever tries to tell you that you shouldn’t use a cloud solution purely on the grounds of security, I suggest you point them at the above links and invite them to come up with a more supportable rationalisation for their preferred approach.

Scalability

Aside from security, this is probably the second most important concern for cloud applications. Scalability is the ability of a given application to be able to adequately and reliably serve the needs of users under a diverse range of conditions. This involves several discrete design considerations, some or all of which may affect your project, depending on its nature:

The ability to support many concurrent users

First and foremost, your application must have the ability to support many thousands of concurrent users equally as well as supporting individual users in isolation. This design consideration is very easy to overlook when you’re working on a Proof Of Concept, where you’re mainly focused on providing features and the only people developers need to satisfy are the rest of their peers in the development team (hopefully augmented by some independent testers that will have the luxury of working on a version of the system that has not yet gone live and where they are consequently not using the system under stress). To be able to have confidence that systems work under the stress of heavy concurrent use, it’s important to test for that specific design goal using appropriate methods. There are various ways to do so that typically involve using a test harness to simulate such use; more on the technical implementation details of that in Part 2.

Considering the strengths of multi-tenancy vs single tenancy

Most software that’s used today tends to be written with a single end-user organisation in mind. If that’s the type of project you’re working on, you can dispense with this consideration altogether, since it doesn’t affect you. However, for some types of application, it’s the case that the same basic application gets delivered to multiple end user organisations, each of whom will have their own user base and subtle usage considerations. In these circumstances, an assessment must be made about the relative benefits and drawbacks of allowing different organisations to share instances of your application (known as multi-tenancy solutions) vs allowing each customer to have their own instance (known as single tenancy).

There’s no ‘right’ or ‘wrong’ answer that fits every situation. However, some things to consider include: Will different customers want to use different versions of your application at the same time? E.g., if customer ‘A’ buys version 1 of your application, and some time later customer ‘B’ comes along and purchases your latest improved version with additional features (version 2), are you going to move every customer that is presently on version 1 up to the latest version for free to satisfy the desire of your latest customer to buy the latest version? And if so, are your existing customers going to be happy to make the move?

The answers to these questions will dictate whether you should provide everyone with their own instance of your application, or attempt to cater to the needs of multiple organisations using one dedicated version.

Deployment

As new customers of your cloud-hosted solution come on board, you’ll need to consider how you are going to cater for providing them with the service they will be paying for. Whether you’re going to take a multi- or single- tenancy approach is a separate consideration. You also need to consider how you are going to get from the point of a customer requesting the ability to use your service, and that service being up and running. This typically involves, but is not necessarily limited to :

Setting up a database to contain the end-user organisation’s information.
Providing an instance of the web application that is specific to the end user organisation. E.g., you might provide the exact same stock management solution to a supermarket as you do to a company that makes metal parts. If you do, the supermarket is unlikely to want to direct their customers to www.shinymetalparts.com to check the price of milk at their local superstore.
You don’t want to get too deeply into managing physical hardware (not having that headache is one of the advantages that cloud computing is meant to bring you). However, you may still want to take an interest in the general geographical area that your solution will be deployed to. If you acquire a customer that has a large user base in Asia, for reasons of bandwidth management you’re unlikely to want to route all the traffic to that customer’s instance of your solution via the North American cloud hub that you used to develop and test your solution.

Most importantly, as an organisation that provides a cloud-hosted Software As A Service solution to others, you do not want to waste a great deal of time and effort getting developers involved in the above matters at the time of deployment. Planning and preparation for deployment needs to be done in advance if it’s to be executed efficiently.

Ideally, you’d like it to be the case that your salespeople can speak with potential new customers, and for those customers to be up and running with a minimum of fuss as soon as a contract for service has been signed. You shouldn’t need a DBA to set up the database, a developer to create a copy of the web application, and a tester to make sure it all still works as intended, just to supply something to customer ‘B’ that you’ve already supplied to Customer ‘A’.

Fortunately, there are solutions to the deployment process that involve minimal work at deployment time. I’ll get into the technical details more in Part 2, but for now I’ll just note that there are tools that, provided they’re used correctly, make the process as simple as running a single script to achieve All Of The Above goals.

In Part 2 I’ll discuss in detail how you can use a combination of Powershell, NAnt, and FluentMigrator to automate the deployment process. Key to the success of these is one final piece of the puzzle…

Continuous Integration and Version Control

The Joel Test has been kicking around for quite a while now, and whilst it is showing its age a little, many of the most savvy developers ask questions from it when deciding where to work. (Side note: yes, believe it or not, the best developers do still get to do that. Even in this economy. Think of the number of businesses that don’t use the internet or IT in some way; that’s the number of places good developers can’t find work, and those organisations are consequently who you’re competing against for the best talent). There aren’t too many organisations still operating today, thank goodness, that don’t provide basic tools like bug tracking and source control. Rather fewer have testing teams that are completely independent from the development team. Fewer still ensure quiet conditions for developers, and in my experience almost no organisation has been capable of doing daily builds or builds in one step at will.

The ability to deploy easily and at will is covered above. Related to that, however, is the consideration of how you will support multiple versions of your solution, some of which may be being used by different customers simultaneously. Part of the reason that most organisations aren’t able to deploy different versions at will is that, as noted earlier, most software today is simply written for one group of users and will only ever been used by and updated for that one specific group of users. If that’s the category your project falls into, then you don’t need to read any further. For those organisations that produce solutions for use by more than one customer at a time, sooner or later you’re going to have to delve into the topic of version control and continuous integration.

Continuous Integration is the process of managing features that are being developed by your R&D / development team, and determining which version(s) of your product will be benefactors of new features / bug fixes that are continually being developed. One day your R&D team might be working on Super Duper feature ‘X’ that is only going to be made available to new customers or ones that upgrade to your latest version. Another day those same developers might be addressing a critical bug that’s been discovered, the fix to which will be rolled out to users of all versions as soon as it’s been through development and testing.

There are tools available that automate and manage this process as a separate activity to development. I’ll discuss one of these tools – TeamCity – in detail in Part 2.

Turning Coffee Into Code : Delonghi Magnifica ESAM04.110.S Espresso Maker

2013-01-04T18:06:00.002+00:00

OK, you got me. This blog is neither about software development in general, nor .Net in particular. But it is about a topic that's close to many developers' hearts: coffee.

______________________________________________________________________________

I'll prefix this by saying that I'm not a coffee snob, though I do have some pretty specific ideas about what I enjoy in a good cup. I don't like the stuff they sell at Starbucks, for example, and I find Costa's brew is way too bitter for me. The nicest store-bought coffee I've tasted actually comes from McDonalds fast food restaurants – their blend tastes really nice. If I didn't have to stand in a line six people deep, all trying in vain to order the food they actually want whilst some poor underpaid student embarrassedly tries to upsell them Things They Don't Want, I'd probably grab a coffee at McD's more often.

My usual brew at home until recently has been Gold Blend instant coffee. That said, I've been working in the centre of Glasgow with a great bunch of guys in a games company for the past couple of months (the first time I've been back there to work in a while). Being in a location that's surrounded by every conceivable type of coffee outlet imaginable, including all of those mentioned above within 100 yards of my office door, has got me to thinking about coffee seriously again. That's led me to invest in a good bean-to-cup machine, so that I can enjoy my coffee just how I want it whilst working at home once my present contract has finished.

After some research, I chose the following machine; the Delonghi Magnifica ESAM04.110.S espresso maker :

I've tried other coffee machines that use pre-ground coffee in the past. To be honest, the results were not at all good. As mentioned above, I find some brands of instant coffee to be very nice. However, if you are going to grind the beans and attempt to make the real thing, then buying pre-ground beans is frankly a step backwards rather than forwards from instant coffee. Coffee beans lose their flavour very quickly indeed: within seven days of being ground. So, unless you're grinding your own as part of the processs, you're probably not getting anywhere like the intended flavour. Pre-ground coffees tend to have been sitting in a warehouse for anything up to six months by the time consumers get them, so they're already well past their best, however they've been packaged, and whichever temperature or atmosphere they've been stored in.

Other unfavourable aspects of those machines I'd tried in the past (which typically cost less than £50) included the fact that they just didn't get the water hot enough to make a great cup. So, even if the ground coffee going in had been right, the results would still have been mediocre. So, I thought I'd invest in a 'proper' bean-to-cup machine this time, to see if better results were achievable at home

The Good Stuff

1) Takes the grind out of grinding

The model above alleviates the issue of ground beans quickly losing their flavour by having an internal grinder that you can fine tune to your own taste. You can set it to grind the beans more finely if you want a smoother brew. (In practice, I've found that leaving it at the median factory setting has achieved just the right balance between a quick brew and a fine enough grind that you get all the flavour). Because the coffee is ground only in the right amount to make each cup and right before it's used, the resulting flavour is generally excellent.

With this particular model, you can also use pre-ground coffee if you really want to. However, since whole coffee beans are generally cheaper or the same price as pre-ground coffee, and tastes very much better, there's really no incentive to.

2) Hot stuff

As it only makes one or two cups at a time, the coffee produced is always piping hot. You can also adjust that setting to suit your own tastes: for me, the hottest setting felt about right.

You can also adjust the strength of the coffee itself. I quite like mine about 25% of the maximum possible strength: strong enough to get a nice caffeine buzz, but without being overpowering or resulting in too bitter a brew à la Starbucks or Costa!

3) Lots of choice, and beans are inexpensive

For beans, I've tried two varieties thus far: Italian Lavazza espresso beans, and a blend called Lazy Sunday by Taylors of Harrogate.

They're both nice and give a mild, creamy coffee. However, Lazy Sunday just edges it for me. I've also bought some Illy beans to try in the coming weeks; we'll see how that goes. I'm looking forward to trying some other blends after that to compare and contrast: that's all part of the fun.

In essence, there are two types of bean: Arabica and Robusta. There are also lots of different types of roast, typically graded from 1 (Mild) through to 5 (Dark).

Arabica beans (which as the name suggests come from high-altitude regions within the Arabian Peninsula) are the oldest and probably more mild of the two, with chocolaty tones. If your tastes are anything like mine, they'll probably suit your palate best. Robusta beans are grown further afield, in places like South America, the Caribbean and Africa, at the same high altitudes. Robusta beans taste earthier and stronger than Arabica. Some blends use a mixture of the two types: Lazy Sunday is in that category.

The roast gradings of 1 (Mild) to 5 (Dark) are a little easier to get a handle on. Counter-intuitively, the middle grade of 3 (Medium) is actually the most flavourful, and the one I like the best. If the bean is roasted less than 3 then the cup will be very mild indeed, and will contain a lot of caffeine. If it's roasted very darkly then it'll taste very smoky, but won't contain as much caffeine since it'll have been burnt up during the roasting process. A medium blend preserves that caffeine kick with a nice, mild flavour: a winning combination for me!

4) Easy to clean

The Magnifica machine itself has proven easy to clean and maintain. The coffee grounds are condensed into little discs during the brewing process: one for each brew made.

It's easy just to empty the container out whenever the appropriate warning light comes on (about every fifteen cups or so), then give the container a rinse out and dry it ready for the next brew.

The instructions advise cleaning out the internal filter around once a month, and not to use a dishwasher or any form of soap for cleaning (as soap can jam the very fine metal filter the machine uses). In practice I find it easiest just to give the filter a rinse under the tap and then dry it with a paper towel whenever the grounds container needs emptying, and you're set to go for the next few days' worth of coffee.

The Bad Stuff

1) Price

The machine itself costs in the region of £350. There are various models in the Delonghi range that go down to about £275, and as a beginner to using espresso machines it's not that easy to see what the benefits of one model against another are. And it's not just as simple as choosing the newest, whizziest-bangiest option either: some of the older models in the same range are more expensive and give better results in terms of reliability/performance/features than newer ones.

I found this site to be quite useful for providing an independent guide, and for allowing you to directly compare and contrast the different models that are available.

In the end, I chose the model I did mostly because other Delonghi models in the same range had a lot of very good customer reviews on Amazon, and because it happened to be the model in the Delonghi range that was available from my local electrical retailer. With Christmas approaching, and consequent delays in the post, I wanted to enjoy my machine whilst I had a couple of weeks away from my current contract over Christmas and New Year, rather than having to wait for an item to be delivered from Amazon (which I'd have been quite happy to do at other times in the year).

I've been very happy with the model I got, though I'm sure the cheaper one available through Amazon would have been just as good.

2) Designed by committee

When I was researching which machine was right for me, I noticed a lot of variety in the options that were available. The cost ranged from between about £250 and £900. The main thing that seemed to differentiate the more expensive models were that they had digital controls, and the ability to store and retrieve different settings. That didn't seem particularly important to me, since once I'd found the settings I liked I intended to keep them that way. However, if you're buying a machine for an office where each person has their own individual taste, the ability to store and replicate multiple different preferences rather than fiddling with the controls manually each time might make more sense.

The unintuitive way that machines in the £250-£500 bracket work is my only real quibble about the Magnifica. It appears to have been designed by the same guy that was responsible for Windows Vista: the controls are horrible, and it's very easy to get confused about how to use the machine at first, particularly for accessing the type of features you'll only set infrequently, such as the water hardness setting.

These are the controls:

I won't go on ad infinitum about each individual feature, but describing just one in detail may help demonstrate the issue.

The coffee comes out of the two nozzles marked 'A' in the photograph above. These nozzles are also where water comes out around twenty seconds after you switch on the machine, as it goes through a cleaning cycle. That same cleaning cycle is repeated (with attendant unexpected hot water flow) when the machine turns itself off after two hours on standby. There's a drip tray on the machine, but it still makes a bit of a mess when a full flow of water is deluged into it unexpectedly. So, I've taken to having a cup positioned under those nozzles at all times when I'm not making a brew, just in case it catches me unawares. The cleaning cycle can be sort of useful as you can use the water to pre-heat your cup(s), provided you remember to position them under the nozzles before turning the machine on!

So far, so good.

Then we come to the milk frother 'wand' (labelled 'B' in the photo above). This device is meant to provide steam to froth milk for making cappuccinos. And it does. Provided you master the magical ritual for making it work first (I suspect that's how it came to be known as a "wand").

The process for getting frothy milk involves first pressing the button marked 'C', then turning the knob marked 'D' anti-clockwise. But don't go putting your milk cup under the wand straight away or anything crazy like that, because what comes out of that 'wand' at first is - yes, you've guessed it - boiling hot water!

To get the process to work properly, you need to get that same cup that you use to catch unexpected water flows from the coffee nozzles, and place it under the wand. Then you turn the knob and let the boiling water turn to steam over the next ten seconds or so. Only then do you switch over to your pre-prepared cup of milk (which should only be about a third full, since it expands in volume as you steam/froth it). If you forget to press the button marked 'C' before you turn the knob 'D' you'll be waiting a long time for that flow of boiling water to turn to steam. I personally found that a little pointless initially: if knob 'D' had been dedicated to the function of producing steam there would have been no need for button 'C' at all.

When you're done steaming the milk, naturally you're going to want to make some coffee to put that freshly-frothed milk into. However, Cappuccino By Vista has thwarted you once again. Because it's at this juncture you'll find that the machine is too hot to make coffee, and needs to be left alone for ten minutes or so to cool down (by which time your milk will be flat and cold).

There is a solution that doesn't require access to a Tardis to be able to go back in time and make sure you prepare the coffee first. That solution is to press button 'C' again until the light next to it goes out. This causes knob 'D' to stop being able to produce steam and puts it into "hot water" mode. Whilst in this mode, you place a cup under knob 'D' and turn it until steam stops flowing and boiling water resumes once again (takes about ten seconds again). This has the corollary effect of cooling the machine down enough to make coffee once more. See?, I knew there must be a 'logical' purpose to requiring two controls (a button and a knob) to control the frother wand when at first it seemed that only one should be needed.

I think you'll agree the above isn't entirely logical or user-friendly. It has the feel of a Beta Version about it. When researching which machine to buy, I read a lot of opinion to the effect that "coffee makers just do what it takes to make great coffee, whether they're easy or intuitive to use is a secondary consideration ". I don't agree with that outlook: great tools don't just need to produce great results, they also need to be user-friendly in order to make the power they facilitate available to us mere mortals. So, whilst the sometimes-obscure controls on the Magnifica may well double-up as a useful test of debugging skills for new developers should you decide to install one in the office (see, I'm getting back on topic now), it is still a pretty inexcusable limitation in a machine that costs £350.

_______________________________________________________________________________

Bottom line, I'm glad I got one. It's nice to be able to enjoy a decent cup of Joe or two in the morning before heading out to face the day. And, minor quibbles aside, it is actually pretty easy to use to get a normal cup of coffee once you've got it set up. All-in-all, I'm pleased with the results and would recommend it.

Amazon Kindle: One of the Best Tools in a Technical Pro's Arsenal

2012-07-12T19:58:00.000+01:00

As any professional knows, you can't get by in technology without constantly keeping your skills up to date with emergent technologies. Of the various ways to do this, one of the best is to choose some detailed technical books in those fields that are presently of interest. Preferably ones that have been written by people that are actual hands-on developers themselves, rather than those by authors that merely have an academic interest in the subject under discussion. Wrox Press does an excellent line of books called Programmer to Programmer, which are very useful in this regard.

Once you've absorbed the material, and have used the technologies concerned on a few live projects, these books become an excellent source of reference material, which you can refer back to time and time again. If you're anything like me, you'll have a bookshelf at home that looks something like this:

RP's old technical library

The only downside to Wrox books (and any other type of reference manual) is their weight. It's typically handy to have those books that are relevant to the discrete areas you're working in at a given time to hand as you tackle a real project. Given that even a few books combined generally weigh around 2-3kg, that can be a real strain on your back, especially if you're already carrying a laptop and other bits and pieces around too.

Around about two years ago, I bought an Amazon Kindle, for the express purpose of carrying around these tomes without dislocating my spine. The passive e-ink display of the basic Kindle device is great for reading in bright sunlight:

Physical Kindle Device

And there's a handy little management tool on the Amazon website that allows you to keep your books safe and available at all times, wherever you may be:

Amazon's "Manage Your Kindle" tool

(View full size here)

The battery on a physical Kindle device lasts for a very long time (at least a month of continual use between charges), and the device itself has room for loads and loads of books. There's also a free PC-for-Kindle application that allows you to view the e-books you've purchased on any PC. And for Android users, there's a nifty free Kindle-for-Android app that allows you to view your books on your tablet:

Kindle for Android tablet, Library View

or on your Android phone:

Kindle for Android phone

These latter applications are particularly useful if a book you happen to be using utilises colour to convey meaning:

Colour-Coded Keywords

Coloured Graphics

(View full size) (View full size)

However, the best thing about using Kindle as your technical library, which all technical departments should take heed of, is that you need only buy each book once. If you've got a department full of 20 developers (within which there will undoubtedly be a huge overlap of skillsets), it makes sense to buy one copy of each book, and allow each developer access to that library of virtual books via their own PC. An organisation that wants to make effective use of technology will also probably find it profitable to fork out for a few Tablets and physical Kindle devices for taking into meetings. In terms of increased profitability for individual developers, they'll pay for themselves in no time.

Academia: The Internet, You're Doing It Wrong.

2012-04-11T13:00:00.009+01:00

There was an interesting article on Radio 4's Today programme yesterday, concerning the way peer-reviewed research journals such as Science and Nature charge British Universities hundreds of millions of pounds each year for access to the scientific research they publish on academics' behalves. In many cases, in a bizarre reversal of the normal economics of the process of publication, these journals also both charge the publishers of the research themselves for the act of publishing, and require those authors to sign away copyright to the journals involved so the originators of the work can't even reproduce their own articles elsewhere (hence the fees – to the publisher, not to the author - when other academics later want to see what's been written by their peers).

The wider piece centred around a new website that's about to be launched, called eLife. The project is being championed by Sir Mark Walport, the director of the Wellcome Trust, and aims to provide a free, centralised place for research to be published instead.

The whole piece got me thinking about how Universities, and for that matter most publicly-funded bodies, don't seem to use information technology at all well, most particularly the web. The apparent benefits of peer-reviewed publications, at least in the eyes of those academics that choose to publish their work through them, is that they allow other academics in their fields an easy way to find and review their research. This apparently enables them to collaborate better and promotes further scientific development. Because, you know, unless publications like Nature et al existed, academic research would be otherwise impossible to publicise, find and share.

If only there were an effective way to search the internet using some sort of tool – kind of like an engine for searching, if you will – that could enable academics to allow their work to be discovered that way instead? And wouldn't it also be nice if there were some existing, free, centralised, widely-respected encyclopaedia of knowledge, that was editable by anyone, and that was well-indexed by these 'search engines'. In an ideal world we could even make that online encyclopaedia itself searchable in its own right. In such a technological Nirvana, academics of all flavours could easily just publish their own original research on their own blogs, within their own institutions' websites, whenever they liked for little to no cost, retain the copyright themselves, then provide an entry in that centralised encyclopaedia of knowledge containing links to their own independently-published research. That way anyone, including other academics, could then subsequently easily find and develop their ideas.

But no, I can't see us having that sort of technology until at least the next millennium, so I guess Universities will just have to keep handing over millions of their tuition fees and state research funding money to journals that provide a shadow of the above service for a fee instead. And who then also charge anyone that wants to read it too.

Update: Loftek Sentinel D1 Review

2012-04-09T13:46:00.005+01:00

Despite the Loftek Sentinel D1 CCTV camera that I reviewed recently performing well when first installed, I regret to report that it unfortunately developed a fault within 2 days of installation, ultimately necessitating my returning the unit for a refund.

The fault manifested itself by the camera stopping working during a pan movement on day 2 of operation. I had thought perhaps that it might be a temporary fault that could be easily rectified. Being a professional geek, I tried all of the obvious solutions before concluding the problem was with the unit itself:

1) Resetting the unit, both using the power supply itself and the reset button on the cable bundle.

2) Hard-wiring a connection to the camera to check if it'd lost network configuration settings somehow (it hadn't).

3) Checking whether my router's signal had for some reason stopped reaching the location of the camera (located only 10m from the router, on the outside of my property). Both my mobile phone and my laptop could 'see' my router from the camera's location without difficulty, leading me to conclude that the problem was definitely with the camera's own ability to communicate over that distance, rather than being a problem with the router itself.

4) Despite the fact that (3) above tended to rule out any problem with the router's signal, I tried alternative channels on the router, including auto-channel select (which should find the best available channel), with no success.

5) Bringing my router out to my garage, less than 1 metre from the camera, did cause the camera to begin being able to transmit on the network once again. This conclusively proved that the problem wasn't with the configuration settings, power to the camera or a mechanical issue with the camera, but was definitively a camera to router signal propagation issue. [If it had been a router to camera propagation issue, then my other wireless devices wouldn't have been able to communicate from the camera's location whilst the router was in its usual indoor position. Also, it was clearly a fault that had developed, rather than simply being a characteristic of the camera, since the camera itself had been able to communicate with my router in its indoor location for the initial 48 hours after first installation.] Unfortunately, I couldn't leave my router outside in the garage just to allow the camera to work over a much shorter distance, as it would then be out of range of my hard-wired internet connection, negating the purpose of having a wireless camera in the first place.

I contacted Loftek to give them a fair chance to recommend a fix to the problem. Unfortunately, their technical advice appeared limited to suggestions that frankly I could have got by watching an old episode of The IT Crowd. They said to try changing the router's channel (I hadn't told them that I'd already tried that, but I had explained in my e-mail that other wireless devices could connect to my router over the same distance, which should have ruled out frequency interference as a possibility). In their only other suggestion, they actually used the phrase "try switching the camera off and back on again". Really, any techie that still gives the old "try switching it off and on again" advice to someone that's demonstrated they're reasonably technically proficient should be deeply, deeply embarrassed.

So, with regret, my ultimate conclusion about the Loftek Sentinel D1 is that it was a good idea, but the unit itself is so unreliable as to make it unworkable in practice. Going by the mass of traffic to my blog with search terms such as "Loftek Sentinel D1 wireless doesn't work" since posting my review, I'm guessing I'm not the only one that's experienced difficulty.

Good luck, dear readers, with your own technical woes. I hope you have better luck making this product work than I did. If not, try switching it off and.......never mind.

Product Review: Loftek Sentinel D1 CCTV camera

2012-04-08T00:07:00.020+01:00

This is a product review for the Loftek Sentinel D1 CCTV security camera that I installed at home recently, available in the UK for £115 from Amazon.

NB: Please read the post below in conjunction with my subsequent update to this review.

________________________________________________________________________________

I chose this particular camera because I wanted a more subtle method of security for my property than a more in-your-face CCTV system could have provided. The dome design on this model means that it can easily pass for a light fitting, and is therefore not too obtrusive, thereby allowing me to beef up security in a subtle but effective way, without making my home feel like Fort Knox. Other more overt camera systems may provide a greater degree of visible deterrence to vandals and thieves, if that's what you're looking for, but for a home setting in a quiet residential area that you want to remain welcoming, this felt like the right choice.

Wos this?

On the technical front, being a geek by profession, I found no difficulty in getting this item set up within minutes of opening the box. It was merely a matter of attaching the camera to my wired network (via a LAN port on my wireless router) in the first instance, then you have the option of either installing the enclosed IP Camera software to obtain the device's IP address, or simply use your router management software to identify the IP address that your home network has assigned to the camera. After that, just use any popular browser (Firefox worked for me, and I tested IE9 too) to navigate to the camera's setup page, by typing the camera's IP address into the browser.

tinyCam for Android running on an ASUS Transformer tablet PC

...and on an Android phone

Screen dump of the browser-based configuration utility

The home page guides you to install some third party software from VLC to view and control the actual camera feed, and you're off. Finally, use the camera's web-based configuration utility to provide the device with your wireless network settings. After that you can dispense with the wired connection, which you wont need again. I found that the camera retained wireless configuration settings, even when switched off during the actual installation process. So, once set up, the device seems to be pretty stable to issues like power cuts that might otherwise have been a problem for a less well thought out design. I also tested accessing the camera using my Android tablet, and found that to be very easy too. There's a free app called tinyCam monitor that does the job. There are also other applications for a modest fee (typically less than £5) that purport to enable you to store images online or on your device's SD card, based on real time rolling imagery or on motion-sensitive images. I haven't tested any of these capabilities, and therefore can't comment on whether this model or the Android apps mentioned work for these purposes.

My installation

With regard to the hardware itself, the only slightly-misleading thing for me was the fact that the unit requires a wireless antenna, which screws into the side of the camera itself rather than being located in a more subtle location such as at the cabling terminus. This isn't shown in the product photographs provided. If you look at the manufacturer's images, there's a little gold protrusion shown, that looks like the end of a screw that goes right through the bracket holding the unit.

Manufacturer's image, with antenna missing

That's not actually a screw, though: it's the connector for the antenna, which isn't shown, and which is about 7 inches in length when fitted. This reduces the visual appeal of the device, by making it more obvious that it's a camera. There is still the option of connecting a wireless access point to the cabling terminus of the device (which is hidden away near the power supply), but still, it'd have been nice to see the product as it really appears, rather than having visual details like this being left off of the product photos.

Having read some of the other reviews available online for this item, I had been a little worried that I might experience some issues with autofocus whilst panning to areas at different focal lengths (some of the American reviewers referenced above had indicated that they'd had difficulty in this regard, and had been instructed by the retailer to adjust the focus manually by removing the camera's cover and using a screwdriver). However, I needn't have worried, as I simply didn't experience this issue. If this were ever a problem, the current model doesn't appear to suffer from it.

The low light facility on this camera is pretty damn impressive. It's not an infrared camera, and that's not what I'd decided upon for this particular installation, preferring instead to rely on visible lighting around my property. The first day after I installed the camera, though, I was in the position of still having to replace some external lighting that had failed over time (job now done, though it took an angle grinder and a lot of sparks to remove one of the old light fittings - apologies to any of my neighbours disturbed by the brief but wrenching noise of that process!). Because I had a day of darkness before I replaced that broken external lighting, I inadvertently had the opportunity to see how the camera performed in near-complete darkness. Under those conditions, I could still make out a reasonable amount of detail and colour, just from the ambient light provided by a streetlight across the road (see the sample photos below for a comparison of daylight, full dark, and moderately lit nighttime camera images). I felt that the 'moderately lit by a 60W door light' images were quite good enough for my purposes, negating the need for a camera with full night vision capabilities that I had been considering as an alternative.

Daylight

Lit by one 60W bulb

Complete Darkness

Lastly, I'd say this model is a good option for securing your own property, whilst respecting the privacy of your neighbours. I can see everything I need to see on my own property. However, the fact that the camera is limited to a moderate 3x zoom means that whilst it's more than enough to identify callers at the front door, the view it necessarily gives of any public areas and neighbouring houses actually has less resolution than the view I can get from looking out of my own front window or walking down the public street. I see this as a good thing. Some of the cameras I reviewed before deciding upon this item were way too highly-powered for a residential area, offering up to 22x magnification in some cases; it'd be hard to justify the need for that sort of resolution outside an industrial setting.

Overall: I think this an excellent camera, at a reasonable price that represents good value for money, and that's not too hard to set up. I'd recommend it for use in a domestic setting, especially for areas where fixed cabling may be an issue, provided you don't require true night vision for your specific purposes.

Silverlight Data Binding: A comparison of INotifyPropertyChanged and DependencyObject.

2012-02-06T17:35:00.003+00:00

NB: Owing to YouTube's policy of trying to force Google+ on YouTube members, I no
longer host content on YouTube. Apologies for the inconvenience.

The project I worked on most recently involved using Silverlight 4 in conjunction with Prism and MEF. This entry is a brief tutorial on one of the core concepts in Silverlight : data binding, which can be achieved in two main ways, each with benefits specific to the contexts in which they're best suited.

Moving, keep on moving.

2011-11-26T11:45:00.007+00:00

The company that I’m working for at present is in the process not just of designing their latest product, but of moving offices. A small advance party has been sorting out arrangements at our new location over the past few weeks, and, on Friday, our team became the first group to take up permanent residence.

This is how the new place looks. Somewhere in that photo, there are eight developers hard at work [clue: the kitchen, containing the coffee machine, is just out of shot on the left].

It was kind of weird having the whole place to ourselves for now. I guess that will change soon enough, as the rest of the company ships across over the next month.

The open-plan layout represents a stark contrast to the previous location, which was rather warren-like in character. It’s nice – I like it. The only thing that had me slightly perturbed was that, despite only being a couple of miles from the old place, my satnav decided to get creative when I left for the evening, and took me home via an entirely different route to the one it recommended from the old place, involving lots of unfamiliar local roads. It turned out to be a very fast route indeed, but it did make me wonder, as I belted along in the dark, about the mathematical implications of the common algorithms used by satnav devices in selecting the ‘best route’ from A to B that could result in such radically different conclusions when A moves by just 2 miles. I think that must mean I’m a software developer at heart. :)

Silverlight, Prism & MEF

2011-11-05T20:56:00.010+00:00

In my latest project I’ve been working with Silverlight (version 4), in conjunction with Microsoft’s Prism framework, and the Managed Extensibility Framework (MEF). Prism was designed by Microsoft's Patterns & Practices group, and is also sometimes known by the somewhat less catchy title of “Compososite Application Guidance”. It's a generalised framework for composing UIs in WPF and Silverlight that are comprised of loosely-coupled parts. It makes use of patterns like Dependency Injection / Inversion of Control to achieve loose coupling between the various constituent components of a solution. This means that those components can be designed by teams working in isolation, and leaves the design open to be extended in the future. Whilst Prism itself isn’t specifically tied to the MVVM pattern, the loose coupling it enables is typically used by developers working in Silverlight or WPF as a mechanism to help implement that pattern, and to thereby leverage the testability and extensibility benefits that MVVM bestows. My current project has also provided some other interesting challenges for me, in the form of technologies that I’ve been encountering for the first time in a live project. Specifically, for reasons related to the product itself, the project I’m working on utilises several Postgres databases running within a Linux environment – not an everyday challenge for a .Net developer by any means. This blog entry provides a brief overview of the above toolsets, and their purpose within the overall design.

MVVM (Model View ViewModel) is a development pattern that was first proposed by John Gossman, and is based on an even earlier pattern by Martin Fowler called the Presentation Model. I wont attempt to describe MVVM in full here (there are a great many other articles available on the web that do that far better than I could, for example this one here, as well as useful training videos that give you an introduction to some actual coding techniques to implement the pattern. More on those later.) For the purposes of this blog, I’ll just summarise by saying that MVVM is a pattern that takes code that would ordinarily reside in code behind files, and pushes that code into separate areas of the application known as ViewModels. The code that resides in these separate ViewModel classes represents the pure business logic of the application. This is where the pattern starts to become useful in ways that have made it the most popular and widely-adopted approach for extensible WPF and Silverlight applications. Separating concerns in this way makes the ViewModels in which the business logic resides independently unit testable, which in turn makes the design more resilient to ongoing development and change. So, any developers that need to alter the design in the future after initial development has been completed and the product is in a care and maintenance phase can have greater confidence that any changes they may implement will not break existing code.

Prism: Not the only option for implementing MVVM

Prism isn't the only option for implementing the MVVM pattern. There are many alternative MVVM frameworks out there, e.g. the MVVM Light Toolkit. As noted, Prism version 4 isn't in itself tied to MVVM in any way. It’s just a generalised framework for designing extensible, composite UIs that exhibit loose coupling. However, the loose coupling that Prism provides is commonly used by WPF and Silverlight developers as an enabling mechanism for implementing MVVM. Which framework and pattern you may choose for a given solution is entirely a judgement call. Prism and/or MVVM may well be over-complicated for some types of simple application. Just because you're working in WPF or Silverlight, doesn't mean you should de facto be using Prism, or implementing MVVM. There are overheads involved in deciding to use each, and it's worth noting that they won’t be the right choice for every single project that uses those technologies. Even John Gossman himself has suggested that some of the approaches that MVVM facilitates may be overkill for simpler applications that are not intended to be long-lived, extendable or scalable. Prism contains a great many discrete features for building composite UIs. (e.g., it provides a selection of Navigation frameworks, the ability to group individual Views into Regions and Modules, has integration with the separate Unity or MEF components for Dependency Injection, and even facilitates the option to use your own preferred DI framework of which there are literally dozens of options if you prefer, as well as features such as its Event Aggregator which facilitates communication between loosely-coupled components in a way that leaves the publishing and consuming components freely independent of one another). However, what's nicest about Prism is that developers are free to pick and choose which specific parts of that significant set of features they will use for their own particular solution. You don’t have to use it. And, if you do choose to, you’re not forced to use it all.

When implementing MVVM, Prism may be used in a range of discrete ways to facilitate reliable, scalable results in a reasonable amount of time.

I wont go into all of Prism’s more discrete areas that I touched upon above within this blog, but can recommend this excellent guide to Prism in conjunction with this equally-enlightening guide to Silverlight 4 development for further reading. The Prism guide is part-written by the lovely Ward Bell, whose insightful videos on IdeaBlade’s DevForce ORM tool gave me many an enlightening chuckle a few years back. Get ’em on Kindle so that you can read them on your PC instead of lugging heavy books around – you know it makes sense. ;)

Before moving on from this discussion of Prism and MVVM, I'll just lastly note that there's a great little series of instructional videos by Microsoft's Mike Taulty available.

It's a rare individual that can grasp technical concepts clearly, and communicate them to others. Mike manages to do so beautifully over the course of just a few hours. His videos are great for getting a feel not just for what Prism and MVVM can do, but also along the way they give quite a bit of insight into how composite applications can be more complicated to understand than traditional, tightly-coupled designs. And they demonstrate how easy it is to build up an illusion of loose coupling using frameworks like Prism, whilst in realty just turning turning tight coupling that would otherwise cause build errors at design time into breaking functionality at runtime that are harder to track down and eliminate from the design. When you get to the part of the videos where Mike is having to copy DLLs into bin folders by hand to ensure that the project still works as expected you'll see what I mean.

I appreciate that Mike's videos do contain some contrived examples, but still voluntarily immersing yourself back in the Bad Old Days of DLL Hell isn't what any pattern or practice that's meant to make developers’ lives easier should be about. That illusion of loose coupling whilst really still having all the same interdependencies of tight coupling in disguise is also evident when Mike doesn't attempt to type in the XAML configuration files that describe how his Modules should be loaded and what dependencies they will have on one another. He instead stops the video when it gets to those points and gets said config files from a Blue Peter -stylie pre-prepared example, because in his own words typing in such config files by hand is “prone to error”. It's ridiculously easy to get such configuation information wrong in ways that will only become apparent when a user tries to use the components controlled by them at runtime. And it's even easier to get the configs right in the first instance, but for them to become invalidated at some later point during the lifetime of the extensible application involved by later development work. It's a judgement call for the developer/architect to make as to whether the risks vs rewards of using Prism make using it the right decision for a given project.

Getting back to MVVM as a concept in its own right, as I mentioned the last time I wrote about Silverlight, one of the main strengths of and purposes behind the XAML-based design environment that each of these technologies uses is the separation of concerns that XAML facilitates between the related but distinct goals of design and development. Using XAML as a common medium allows designers that are primarily concerned with the look and feel of an application to work hand-in-hand with developers, whose primary responsibility is making sure the application actually does what it was functionally intended to do. MVVM adds a further refinement to that collaborative effort within WPF/Silverlight. It enables developers to protect their work against any unintended behaviour that may be introduced after initial development, by allowing their business logic code to be unit tested in isolation from the purely visual elements of the solution. For designers, MVVM allows the visual elements that they are most interested in (called the Views) to be designed independently from the application state and business logic stored in the ViewModels. In the case of designers, using MVVM is also useful for simulating application state at design time, thereby allowing them to refine the visual representation that the UI will be required to have when it experiences those states when the application actually runs. The final part of MVVM – Models – concerns those parts of the application that are purely concerned with the business of communicating with whichever specific back-end database is being used. This is particularly useful in allowing developers to focus on business logic in isolation, without becoming overly-involved in issues that are more generally within the purview of DBAs.

Some clichés about Web Designers
and Developers. And Women.

Designers use a tool called Expression Blend to work on the visual elements of WPF/Silverlight applications. As a developer, you can think of Blend as a great big Photo Shop for Visual Studio 2010. It allows all those subtle little visual effects that differentiate between professional and amateur software products to be applied to functional designs in a way that takes those designs from being merely useable to being useable + refined. One of the first problems that users of Blend typically experience when working with .Net projects is that any moderately-complex business logic that is tightly coupled with UI elements has a fairly high probability of completely breaking Blend. Typically, problems that will break Blend in this way include things like database connectivity that is not available at design time being required to provide data for the UI Element’s initialisation. Since Blend semi-initialises components in order to render them in its design surface, this presents an additional challenge for developers. If you’re a developer user of Blend, initialisation issues of the type described are just about a manageable problem, since it’s possible to attached Visual Studio’s debugger to the Blend executable using Visual Studio’s “Debug -> Attach to Process…” feature, and thereby discover at precisely which point in the code Blend is failing to render a given control. Fixes to such problems will typically involve using C#’s System.ComponentModel.DesignerProperties.IsInDesignTool Property to intelligently protect those areas of code that are erroring out. For designers, who typically don’t touch the underlying code, this issue can present more of a brick wall – if there’s an area of code underlying a UI element that they need to style that doesn’t work, they’re pretty much stuck without a developer’s help.

By using MVVM, any code that UI Elements use can be separated out into their own classes (called ViewModels). By separating concerns in this way from the outset, it makes it less likely that UI Elements will be fundamentally unable to be rendered in Blend at design time. Most MVVM frameworks will render any constructor logic within a base ViewModel class that utilises the DesignerProperties.IsInDesignTool Property mentioned above within a common base constructor. By solving this problem once and for all, and avoiding rather than dealing with the consequences of designtime / runtime issues of this type, MVVM helps to significantly reduce the number of occasions when design members of the team will have to call on busy developers for help.

Concentrating on the developer-centric benefits of MVVM, by separating out business logic code into ViewModels developers obtain in return greater control over the stability and testability of their functional code. If you’ve worked on a software product of any level of complexity with a moderately-sized team, you’ll know that there is ample scope for code that has been written, debugged and tested to begin experiencing unanticipated behaviour at some later point in the development cycle, through no fault of the original developer or tester. Developers that are starting out (and even some that have been around long enough to know better!) are sometimes misguided enough to believe that their own code is bug-free.

This is usually not the case, but, even if we were living in some mythical Nirvana universe where we were all super-developers that produced error-free code first time every time, there is still ample scope for any developer of any level of ability to have bugs inadvertently introduced into their code by other team members as the collaborative software product you’re building together evolves over the course of the project. This is where the Unit Testing that MVVM facilitates becomes useful. Just to make my position clear on this subject: I’m not an advocate of what I would term ‘fundamentalist’ Test Driven Development. Which is to say that I don’t advocate the approach to TDD that involves writing tests before writing code, or that encourages writing lots of meaningless tests for even the most simplistic parts of the system. I do, however, support the concept of writing tests to protect existing human-tested code against unanticipated bugs being introduced by subsequent development. MVVM allows various frameworks such as the Managed Extensibility Framework (MEF) and Unity to work in conjunction with Unit Testing and Mocking frameworks such as xUnit and Moq to test ViewModels in isolation at design/test time. This allows developers to set up unit tests that automate the process of confirming ‘What should happen if…’ scenarios. [And, in the case of MEF, there is also lots more functionality on offer, including the ability to group loosely-coupled independent components of the solution into a coherent composite application. You can find lots of good info about how to use MEF in conjunction with Silverlight here. ]

Well, so much for this overview. I’m enjoying working with Prism, as well as the other tools/environments that I mentioned such as Postgres and Linux for the first time, and thereby evolving into an ever-more-experienced developer with first-hand insight into how a range of technologies are being used on live projects. As the name of this blog suggests, it’s not just the code or the software products that I’ve been involved in building over the years that’s a Work In Progress, it’s myself and my professional experience that are ever-evolving. One of the things that makes that process of learning and personal development possible is having a great team to work with in a positive and forward-thinking environment. I’m very pleased to be working with such a knowledgeable team at this time, who have many strengths in those areas that are newest to me, and are open enough in their outlook to allow my ideas and discrete experience to be part of their already-impressive mix too.

Product Review: 120 Gb Outbacker MXP Biometric Hard Drive

2011-08-08T20:36:00.009+01:00

This is a great little tool for using in environments where you’re required to work with sensitive data. The biometrics in the device behave flawlessly (having heard about some other less-than-impressive implementations of fingerprint recognition technology, I had been a little worried that this item would be one of those that had lots of ‘false negatives’, but I needn’t have worried – it does what it’s designed to do, and it does it every time). The drive itself is sturdy, small and absolutely silent in operation. It doesn’t heat up in the slightest, and the rubber feet and chunky construction mean that it sits steadily on whichever surface you put it on, so you can use the fingerprint reader with one hand, without having to use your other hand to steady the unit. It also comes with a power adapter (which, admittedly, looks a little flimsy and makeshift once you plug the UK adapter into the two-pronged US-format base unit). On my PC and laptop, the power adapter wasn’t needed anyway, provided I plugged it straight into a USB port (it wouldn’t work on its own through an unpowered USB hub). For £40, I think the fact that it comes packaged with an adapter at all is pretty impressive; many of the more expensive drives I’ve bought have had adapter sockets, but haven’t come with an adapter unit.

The pre-loaded software works seamlessly in Windows 7, and is well thought-out. You just plug the unit in, and a new drive appears in your list that contains the start.exe programme you need to get going. Double-clicking on start.exe guides you through the simple (less than one minute) process of registering two fingerprints and setting you up to use the drive. You choose an administrator password during that initial setup (which you can use to access the drive should the biometrics fail at any point, or should you be in a position where you can’t physically access the drive but still want to unlock it; e.g., if you’re using VPN to access a PC it’s connected to). After that initial setup, it’s just a matter of plugging the drive into whichever PC you want to use it on, swiping your finger once over the reader, and you’re good to go.

My only slight quibble is the ugly, branded “McAfee” logo that’s been plastered over the top of the drive! It’s hideous!! If you want to, you can remove this eyesore easily enough with the edge of a coin, just like using a scratch card, without damaging the underlying silver paint. To avoid any mess as the little flecks of powder-coat paint re-adhere themselves to the silver case after rubbing off the logo, I recommend covering the logo with ordinary, clear sellotape first, then rubbing gently over the tape with the edge of a coin, then peeling back the tape to remove the logo (which adheres neatly to the tape and comes off cleanly in one piece rather than turning into thousands of individual sticky dust particles).

In terms of transfer speed, the on-the-fly encryption used is just about noticeable. The transfer speed I saw on large ( > 6Gb) files was around 10Mb/s. My unencrypted SATA II drive manages around 40Mb/s by comparison. This was still a good enough performance for me, and compared favourably with the SSD + TrueCrypt Traveller Disk arrangement I had been using prior to this purchase.

All in all, minor quibbles aside, this is easily the best bargain I’ve seen in a while. £40 for a reliable 120Gb biometric drive that has reasonable transfer speed is simply superb value. I recommend this item for anyone that’s serious about security, but who doesn’t want to have the hassle of setting up TrueCrypt/Bitlocker etc, or remembering passwords, whilst moving data around.

You can buy one here.

Code Reviews

2011-02-19T23:49:00.039+00:00

One of the practices that’s become semi-common within development teams over the past ten years or so has been the observance of formalised management/peer reviews of team members’ work, known as Code Reviews. The specific format these reviews take, and who carries them out, varies quite a bit from workplace to workplace, and project to project. This article covers some of the approaches I’ve encountered within various working environments, and provides some personal viewpoints on what works and what doesn’t when carrying out reviews.

When I first started writing software professionally, in the late 1980’s, it was a fairly solitary activity. Development ‘Teams’ tended to be comprised of at most two or three individuals. Often, only one of those people would be writing the actual code, and it was rarely the case that anyone other than that single coder would take an interest in the actual implementation of the solution (as distinct from a user-level understanding of the functionality being developed). Code reviews were therefore fairly superfluous to the development process – solutions either worked, or they didn’t, and it was usually fairly easy to see what was or wasn’t working without having to enter into too much analysis of the subject.

In recent years, since around about the turn of the millennium, it’s become more popular to have larger development teams, comprised of more specialised (and less broadly-skilled) individuals. The reasons for this change in approach are many and varied, but perhaps one of the main drivers is that there are so many more development technologies available now in comparison to those early days, and having larger teams allows different parts of those larger and more diverse teams to better focus on more specific parts of the solution. It’s common nowadays to find 3-4 developers, a DBA (sometimes more than one, especially in the Public Sector), Business Analysts (including some that don’t have a coding background), Project Managers, and specialist users with expert knowledge of the problem being solved, all working together within dedicated teams aimed at producing a single software product. There are some advantages to this more modern approach, including greater support for individuals within the team and an increased ability to fill gaps left by any departing members, though there are some disadvantages too. Specifically, a corollary of working within those larger and more diverse teams is that, when working on multiple fronts consecutively, there is more chance of any one particular area of work getting out of sync with the rest of the team’s activity. By increasing the separation of concerns, development teams also multiply their potential points of failure. This is where Code Reviews come in.

Code Reviews, when done correctly, can have multiple benefits to a properly-functioning and well-motivated team. They can help individuals to communicate their ideas with, and engage in mutual learning from the experience of, their peers and technical management, thereby facilitating a two-way process of learning and mutual understanding. They can make the product being developed more robust and maintainable, since it stands to reason that the more members of the team that know about the logic behind the wider implementation (including parts of that implementation they may not have worked on directly themselves), the easier it’ll be for any one developer to take over another’s work if the demands of the team (sickness, holidays, re-prioritisation, etc) dictate. Perhaps most importantly, though, Code Reviews enable individual developers to understand the impact that their own work has within the context of the wider team’s direction. They enable individual members of the team to contribute their own part of the wider effort in conjunction with rather than in isolation from the concurrent activity going on around about them. In this way, they encourage each member of the team’s work to be part of a widely-understood set of greater goals, rather than just leaving each individual to contribute their part of what eventually becomes a patchwork quilt of loosely-aligned ideas.

If carried out incorrectly, on the other hand, Code Reviews can be extremely damaging to a team’s morale. If conducted in the wrong spirit, advice passed on during code reviews can seem, from the perspective of the recipient, to merely represent unnecessary interference in, unwelcome distraction from, and unjustified criticism of, their work. They can create a climate of fear that stifles individual initiative. If done badly enough, they can breed resentment that ultimately leads otherwise skilled people to (correctly or not) conclude that they can’t do right for doing wrong, sapping their confidence and motivation, and diminishing the team’s productivity.

So, how best do them properly? Well, in my humble opinion from two decades of being on the receiving and delivering end of same, here are some of the things that I’ve seen work worst and best during my career:

1) Keep It Private

I’ve found it best to always give reviews about individual developers’ work directly to the person concerned, face-to-face and in private. If more than one individual is involved in a particular piece of discrete work, it’s of course fine to have a conversation together with all of the parties concerned aside from the wider team, but any discussion of individuals’ work should never be done in front of uninvolved members of the team. It’s human nature to perceive even constructive criticism as a negative experience, where that constructive criticism is delivered before an audience of the recipient(s)’ peers. The self-same feedback that would be perceived as well-meaning advice if delivered in private, can sound like the harshest criticism if given in public; context is everything. I once knew a lead developer that not only gave code reviews in public at individual developers’ desks in front of the whole development office, but who also later wrote about those individuals’ work in clearly-identifying terms on his internet-facing public blog. I guess he must have mistakenly thought of the internet as an anonymous medium and considered his blog in much the same way that other people might think of their private diaries. Ouch. My advice is to never behave in this way, however tempted you may be to vent frustration and however much you may feel that an individual deserves it. Criticising your peers (or, even worse, your direct reports, who look to you for even-handed guidance and leadership) in public is never a classy way to behave. Doing so is guaranteed to immediately lose you credibility with the very people whose work you should be trying to positively influence – who wants to work for someone that appears only to be interested in embarrassing and deriding them in public? What you should aim to achieve out of each Code Review is a more motivated and better-informed team member, and an insight into that team member’s thought processes for yourself; it’s plain to see that you’re unlikely to achieve either of those outcomes by merely seeking to criticise or denigrate people in public.

Code Reviews are either Win-Win or they are Lose-Lose for the parties involved; by providing any constructive criticism you have to make in private, you’ll help ensure the former rather than the latter outcome.

2) It’s Not All About The Negatives

One of the things that can make Code Reviews become a morale-sapping chore rather than the productive exercise they should be is if a perception is allowed to develop amongst the team that they’re merely used to provide oversight of those being reviewed, to pick up on any areas where there’s room for improvement. For experienced technical professionals (who are most often experts in their particular field, and are regularly the most experienced member of the team in whatever it is that they individually specialise in) this can sometimes feel like a wholly-negative experience. Even where the technical reviewer is of equal experience in a given technology, it’ll certainly be the case that the person being reviewed has a greater knowledge of the solution as it was developed, since they will be the very person that built the thing. They’ll know precisely why they chose implementation ‘X’ over possible alternative ‘Y’, and can resent it if someone with ten minutes’ understanding of their work chooses to focus exclusively upon perceived negatives in preference to recognising the bigger picture. It’s not that reviewers should be afraid of giving relevant feedback where necessary – they should by all means do so, that’s one of the things they’re there to do – but it is highly beneficial to the process if that feedback can be delivered in a way that avoids alienating the skilled people whose initiative and expertise the reviewer should be seeking to encourage and nurture. One of the key things that makes for such an effective review is that the reviewer should make clear that any constructive criticism being passed on is being given within the context of a generally acceptable performance by the person being reviewed (if indeed that is the case, which it should be in all bar exceptional circumstances: if the reviewer was responsible for mentoring and briefing the person whose work they are now reviewing, and the reviewer has been keeping an eye on source control during the development process, any major problems discussed during a code review shouldn’t come as a total surprise to either the reviewer or the developer – unaddressed major problems should have been spotted and raised well in advance of a retrospective code review). Showing appreciation for the many positives of your direct reports’ efforts within the wider context of a rounded and balanced review of what they have produced goes a long way to lending credibility to any suggestions for improvement you may have to make.

3) Don’t Nit Pick

This is related to but subtly different from It’s Not All About The Negatives above. The first and foremost consideration when you’re giving a review should be whether the work you’re reviewing actually does what it was functionally intended to by the developer, and envisaged to by any specification document. If the solution does meet those criteria, that’s the biggest single tick in the box, whether or not you may have implemented things subtly differently yourself. Within the context of that big picture, a rounded review may also encompass some more esoteric developer-level issues such as the coupling and cohesion evident in the design, how well abstraction of concerns has been achieved, whether the developer has adhered to any design patterns that had been set in advance, the readability of the code, whether the developer has included meaningful comments, etc. However, it’s advisable to avoid commenting on trivial issues, such as the variable names used, or the developer’s use of white space (unless there are glaring and inconsistent gaps that make the code hard to read). The only time it’s appropriate to comment on something as subjective and individual as variable names is if the developer is using generic names like String1, String2, etc, instead of labels that make it clear what the variable is actually for. Perceived wisdom on the ‘best’ naming conventions for Variables, Classes, etc varies wildly from workplace to workplace, and even from project to project within the same workplace. On the whole, it’s best not to focus too much on minor details like these during formal reviews. If you make the mistake of being over-controlling, whatever you may ‘gain’ from that approach in terms of control and code consistency, you invariably lose in terms of individual initiative and the developer’s pride of ownership in their work (and the inner motivation to do their best that professional pride brings). Trying to micromanage every aspect of a person’s work is a sure-fire way to stifle their initiative, and ruin their self-confidence, which in the long run reduces the team's productivity. It’s far more beneficial if developers walk away from code reviews with an accurate sense that the reviewer trusted their judgement enough not to sweat the small stuff, and only bothered them with feedback that was worth their time and the reviewer’s time.

4) Use The Review To Communicate Across The Team

I mentioned above that one of the most beneficial aspects of Code Reviews are that they allow individuals within the team to gain a broader perspective on where their work falls into the bigger picture of concurrent activity going on within the wider team. Code Reviews can be a good time to discuss other areas of the wider solution with developers that are uninvolved with those areas, and to explain where the work being reviewed is intended to fit in with those separate parts of the wider team’s activity. This helps provide an element of useful redundancy within the team (in case developers need to cover for one another or take over one another’s responsibilities for a time), and helps communicate a greater understanding of why certain strategic decisions have been made. From the perspective of the reviewer (who will generally be the lead developer or development manager), Code Reviews also help communicate intent from individual developers back to those guiding the overall solution; as touched upon earlier, good reviews should involve a two-way flow of useful information and feedback.

5) Write It Down

Code Reviews should be formally documented, and held confidentially for later reference only by the reviewer and the person whose work was the subject of the review. This formal record of the review should ideally only be 1-2 pages long, will contain less than 500 words in most cases, and no more than 1000 words in any event. The written outcome should be a list of bullet points of any positive and negative observations to be raised, that the reviewer brings two copies of to the meeting and uses to guide the discussion, then e-mails to the person being reviewed after the meeting. It’s advisable not to send this document in advance, since the brief nature of a bulleted list can be taken out of context if the issues it pertains to aren’t given context by being elaborated upon in person. Another reason for waiting until after the meeting to mail the document to the recipient of the review is that it allows you to incorporate any feedback from the meeting itself into the formal record, and to note any specific outcomes that are expected (such as any remedial work that may have been requested). If you’re feeling brave and you’d like to encourage openness and communication, it’s also an idea to include a section at the bottom of the document headed : “And how did I do?”. This encourages the recipient of the review to give you any feedback they wish on any aspect of the process. Any given project needs to have one distinct individual that is entrusted with responsibility for the overall direction of the solution, and that individual will usually be the person conducting the code reviews (though I have seen working environments where developers have been asked to review one another’s code on a regular basis, which I don’t think worked particularly well - developers like to be able to focus on their own work in the main, and they often perceive it as a distracting and unnecessary chore if they’re instead tasked with regularly commenting on their peers’ work; perhaps most importantly, though, developers’ time is too valuable to waste on administrative tasks that the technical leadership of the team should be shouldering for themselves). Meaningful communication between members of the team is the key to making sure that the main technical decision maker knows everything they need to know to do their job effectively. If communication is truly to be bi-directional, in a code review it’s advisable to document any feedback from the person being reviewed alongside any critique the reviewer may have made of their work.

So much for Code Reviews, and the best and worst of how I’ve seen them employed in various places. I of course welcome any reviews of the above that anyone out there may care to make. ;)

ASPX Page Life Cycle

2011-02-10T21:24:00.064+00:00

One of the most fundamental concepts of ASP.Net – and indeed of any transactional web development technology – is the concept of Postbacks. That is, the idea that an interactive web page may be used by inputting information via the interface presented at the client (i.e. web browser) side of the transaction, and then ‘submitting’ the page so-influenced by user input for processing by the web server. Web users are highly familiar with this concept from a user perspective – whether they’re shopping at Amazon, commenting on stories on the BBC News Site, posting threads on web forums, or whatever, it’s widely understood that in order to affect any change whatsoever with an interactive website users need to input what they want at the browser UI, and ‘post’ the page back in some way (often by simply hitting a button marked ‘submit’, but also in may other ways specific to context).

For web developers, facilitating this type of interaction with users presents many challenges, not least of which is the fact that the web is essentially a ‘stateless’ medium. Which is to say that each time an interactive web page is ‘submitted’ for processing, from the perspective of the web server it’s as if it is the first time it has interacted with the user in question, and so everything about the transaction that is being attempted must be included in the page that has been submitted (including information that, from the user’s perspective, they may have submitted several steps previously, e.g., they may have entered their Amazon user account name and password previously, and have added several items to their ‘basket’ in the meantime, but they don’t expect to have to enter their credentials again when they click ‘Purchase’ as the final step in the process – they expect the page to somehow have ‘remembered’ that they had provided that information already).

This article is about how ASP.Net handles Postbacks in a stateless medium, and focuses in particular on the .Net-specific concept of the page life cycle of an ASPX page.

As mentioned above, facilitating interaction between website owners and website users, and between website users with one another, presents many challenges, whatever development technology you’re using. The HTTP protocol upon which the internet was originally based, and that it still relies heavily upon today, was really designed for allowing people to share ‘static’ content with one another. The web, as it was originally envisioned, allowed users to share simple text files of a fixed content with their peers. Each request for a ‘page’ would result in the exact same HTML being rendered, until and unless the publisher of that page deliberately changed the content manually. For this type of interaction, a stateless communication protocol is perfectly suitable : user requests a page, user gets that page; simple. However, that original concept isn’t how users expect the web to work any more. Today, they expect to be able to interact with, not merely consume, the content of the websites they use. Providing this type of interactivity has involved developers finding ways to allow an essentially static medium to somehow ‘remember’ individual users, and interact with them in ways that make sense within the context of those preceding interactions. ‘Remembering’ previously-encountered information in this way is known as ‘persisting state’.

The main tool that ASP.Net provides to facilitate the illusion of persisting state in interactive web pages is the concept of an ASPX page. Simply put, an ASPX page, also known as a ‘web form’, is a type of container that can hold several discrete types of object – collectively known as ‘controls’ – that allow a user to input information, or otherwise interact with the page. The types of control that can be placed in an ASPX page (which I’ll refer to simply as a ‘page’ from here on in) are many any varied. There is, for example, a particular class of objects known as ‘web controls’, which are defined in the System.Web.UI.WebControls .net framework namespace. These controls provide many ready-made interactive elements, such as text boxes, radio buttons, drop down lists, and others, that retain the values entered into them by users across different postbacks of the page. Developers can additionally create more complex interactive elements of their own design, known as ‘user controls’. User controls employ many of the same paradigms as web controls, but require more developer knowledge to build, whilst providing a greater degree of control over visual presentation for the developer. The last thing that developers should know about controls (of whatever type) is that they may facilitate custom Events, specific to the type of control. That is, they can be designed/used in such a way as to ensure that a postback occurs and that specific code runs at the web server in response to users interacting with the controls in a certain pre-defined way. E.g., textboxes may be designed to respond to users entering text in them, and buttons and images may be designed to respond to being clicked, etc.

The way that ASPX pages manage the feat of appearing to persisting data within the confines of the stateless medium of the internet is by using something called ViewState. In essence, ViewState is a special type of non-visible or ‘hidden’ control, contained within the ASPX page, whose job, amongst other things, is to keep track of all of the data entered in and required by each of the other data-dependent controls on the web form. It is the ViewState mechanism that allows a web server running Internet Information Services (IIS) to interpret the virtual ‘state’ of a page (a ‘state’ that was potentially built up over several preceding postbacks). If you ever look at the underlying page source of an ASPX page as it is rendered in a browser, you may well see something that looks like this somewhere in the middle of the HTML:

This is the page's ViewState. It’s not visible to the user (hence the type="hidden" attribute of the input HTML element tag), but it is nonetheless very important to maintaining the illusion that the system the user is interacting with ‘remembers’ key aspects of the user’s preceding interaction, thereby providing the illusion of persisting state. The value contained in the value="......" tag is a serialised representation of the data used by other controls in the form. There’s a lot more to ViewState, and indeed optimising it is a whole other topic in itself that I’ll perhaps write about another time. Within the scope of this discussion, though, it can be understood to be a serialised hash table, that ‘stores’ named Properties of controls on the page and their values across different postbacks of the page. There’s another type of object, known as ControlState, that performs a similar job to ViewState, but which specifically exists to track properties of controls regardless of any other settings a developer may choose to implement. The main distinction between ViewState and ControlState is that, whilst ViewState may optionally be developer-configured to be disabled, ControlState cannot; where ViewState doesn’t exist ControlState is necessary to do all the work of tracking control properties on its own.

So, to recap, ASPX pages contain various types of control, and the page itself may be submitted by users to the web server for further processing in a process known as making a postback. From the users’ perspective, making a postback conceptually involves ‘submitting’ the page, thereby performing some data-driven action, such as processing an order, making a post on a forum, etc., in a way that is abstracted from and invisible to the user. Now, let’s look at what actually happens from a developer perspective at the web server when such a postback actually takes place.

As well as allowing developers to design the visual and non-visual elements of the user interface, at design time ASPX pages also include a separate developer tool known as the Code Behind element of the page. This part of the design may be thought of as representing that part of the design that gets executed at the web server end (as opposed to anything that happens in the users’ browsers). The Code Behind part of the page facilitates interaction between disconnected users submitting pages via postbacks out in the stateless web, and those ‘back end’ parts of the system that turn those user postbacks into meaningful actions, such as facilitating transactions with underlying databases. For example, this is the part of the wider system that allows product orders placed by users on commercial websites and posts made on internet forums to be turned into records in a more permanently-stored medium, such as a relational database. The way that the Code Behind element of the page facilitates this interaction relies heavily on several of those elements already touched upon, as well as some others that will be discussed below. In summary, whenever a postback takes place, the following Events will take place in the order presented below within the Code Behind:

1. Pre-Init

2. Init

3. InitComplete

4. Pre-Load

5. Load

6. Control Events

7. LoadComplete

8. PreRender

9. PreRenderComplete

10. SaveStateComplete

11. Render*

12. Unload

* Render isn’t an Event per se, but a Protected Method that gets called for each control on the page at this point in the proceedings.

You can ‘subscribe’ to these Events by creating an appropriate ‘handler’ in the code behind. For example, to create a handler for the page Pre-Init Event, simply enter the following code:

C#:

void Page_PreInit(object sender, EventArgs e)

{

'Your custom code here

}

VB:

Private Sub Page_PreInit

(ByVal sender As Object, ByVal e As System.EventArgs)

Handles Me.PreInit

'Your custom code here

End Sub

In VB this is slightly easier than in C#, in that you need only select the Event you want to create a handler for from the drop-down list provided in the Visual Studio IDE, as demonstrated:

In C#, you either need to type the code by hand, or use the following method:

As noted in the C# version, using the above method will insert a Handler that is specific to the individual ASPX page, rather than one that is generally applicable to the System.Web.UI.Page object that all ASPX pages are based upon. This isn’t hugely problematic, but it is just a little neater and generates less code to be maintained if you rename the Handler using the nomenclature “Page_EventName” as suggested in the example, then delete the line reading:

this.PreInit += new EventHandler(WhateverYourPageIsCalled_PreInit);

that you used temporarily. You delete this line because upon renaming the Handler it becomes superfluous, because the ‘WhateverYourPageIsCalled_PreInit’ Handler to which it refers no longer exists, and because for exactly the same reason you’ll get a compilation error telling you about the Handler it refers to not existing. The reason that the “Page_EventName” Handler naming format is slightly more robust is that, provided you include the AutoEventWireup="true" attribute in the @ Page directive within the markup component of the ASPX page (and that attribute is included by default: see screen dump below), the ASPX page creates appropriate add handler code for any Page_Event handlers you define for you behind the scenes, rather than you having to maintain your own.

The VB environment is just a little bit smarter on this occasion than the C# one, and makes use of this useful feature without having to be overtly told to do so.

Moving on, the following sections describe what each of the Events you may create handlers for actually do, and provides suggestions for when you may want to use them.

Pre-Init

By the time this event runs, certain pre-processing will have occurred that allows the developer to decide what should happen at this juncture. Certain useful page properties will have been set, including the IsPostBack and IsCallBack properties. Respectively, these properties allow the developer to know whether the page is being ‘submitted’ for the first time by a user (in which case IsPostBack will be false), and whether the ‘submit’ action was triggered as a result of client script utilising a CallBack (a sort of mini-postback, involving processing of the code behind by the server without utilising the ‘submit’ mechanism or refreshing the page, used in AJAX-enabled applications). It’s possible in ASP.Net to submit the results from one ASPX page into the code behind for another ASPX page; if this is the case, then the IsCrossPagePostBack property of the page will be true at this stage.

As well as using the above properties to direct which Methods of your code behind to run, it’s common to use the Pre-Init handler to dynamically set any desired aspects of the page, such as setting the Theme or Master Page (both of which can affect the appearance and layout significantly), depending on the context.

It’s important to note that at this stage of the page life cycle, the controls on the page will not have had their values retrieved from the page’s ViewState yet. So, don’t use this handler to try and retrieve and act upon user input just yet.

Init

Each control on the page has an Init Event, which may be separately handled. Each of the individual controls’ Init Events will run before the page’s Init Event does.

MSDN advises to use this Event to “read and initialise” control properties, and also states that “controls typically turn on view state tracking immediately after they raise their Init event”. Be advised, however, that when I double-checked the actual behaviour under Framework version 4 and IIS 7 for writing this article, the specific behaviour I observed appeared to be as follows:

· You may validly set properties of controls during this Event only where the current page is not experiencing a PostBack (i.e., provided that this is the first time the user has submitted this page). Where you do initialise any properties here, you may expect those properties you initialise to be persisted to the control/page sent to the client during the first time the page is loaded only. i.e., if you set the ‘Text’ Property of a textbox during this Event, whatever you set that ‘Text’ Property to will be shown on the page as seen by the user, during the first processing of the page only, but not during any subsequent postbacks.

·        ViewState is made active for individual controls during their own individual Init events, but be advised that setting values in ViewState directly is not possible within the Init event. NB: this is usually done to model generic ‘Properties’ within code behind pages, and the syntax takes the form:

      ViewState("MyProperty") = "123"          (VB)
      ViewState["MyProperty"] = "123";                (C#).

· If you set default values for control properties in the ASPX page Markup, you can read those initialised properties during this Event. Any dynamically-initialised properties of user controls may also be read here (which might be important, depending on what you intended your user control to do). However, please note that whilst the above is all well and good, other behaviour observed during this event is a bit odd and counterintuitive. Specifically, you should be aware that, if this is a postback, and if the user has set a Property of a control, that user-set control property will not yet reflect the value contained by the control during this Event. Even worse, during this event any user-set controls will incorrectly appear to show the initial values they held when the page was ‘new’; so, control properties are not merely missing, but misleading and incorrect, during postbacks. Please remember this fact, and surround any code you may place within the Init event handler within a if (Page.IsPostBack) block to ensure that it behaves as you intend during all stages of the page’s life cycle.

InitComplete

Between the Init and InitComplete Events precisely one thing happens: ViewState tracking gets turned on. So, using the

ViewState["MyProperty"] = "123"

syntax mentioned earlier will cause values to be ‘permanently’ persisted to ViewState during this Event.

PreLoad

MSDN says that this Event runs after the page loads ViewState for itself and all child controls on the page. As noted above, however, I found that ViewState had already loaded during InitComplete. All postback data processing should have been completed by the time this Event runs.

Load

The page’s own Load Event runs, then the Load Event for each individual control on the page runs. Event handlers for the page and individual control’s Load events may be reliably used to set control properties programmatically during postbacks.

Load Event Handlers are a good place to initialise and open any database connections that may be required for further processing during the next stage.

Control Events

Individual control Event Handlers will run at this point in the page’s processing. So, if you’ve created a TextChanged event handler for a TextBox, this is the point in the page’s life cycle where that handler’s code would run.

LoadComplete

LoadComplete runs for the page only, not for individual controls. Place any code that relies on individual control event handling to be complete here (e.g., you may have code that determines whether a ‘Complete Transaction’ button is enabled here, depending on whether all necessary data has been entered in other controls first).

PreRender

An important part of what an ASPX page does is that it dynamically generates HTML markup pertinent to the present state of the page and its constituent controls (remember that discussion about how the web was originally conceived to be a static medium earlier? – well, it still is, and dynamic rendering of HTML in this way is the part of the whole ‘page life cycle’ process that makes it appear that a static medium is capable of generating interactive content based on user input). At this stage in the cycle, all controls have been added to the page, have been updated with the latest data from user input and server-side processing, and are ready to be rendered as HTML.

This Event may be used to make any final changes to control properties before final rendering takes place.

PreRenderComplete

This Event fires just after all data bound controls whose DataSourceID property has been set call their DataBind methods. Data Binding is outside the scope of this article.

SaveStateComplete

The SaveStateComplete Event fires after ViewState and ControlState have been finalised. MDSN advice says that any changes to controls made during or after this Event will be rendered, but will not be persisted during the next Postback. I didn’t find this to be the case – for example, setting the ‘Text’ property of a TextBox during this event will both change what gets rendered in the textbox when the page is presented to the user, and will persist the value set through to the next postback (and beyond). It just goes to show, it pays to check advice, even advice from the horse’s mouth, with each new release of the framework and IIS.

Render

Render isn’t an Event that can be handled, but a Protected Method that exists for each control on an ASPX page, that gets called for each control on the page at this point in the proceedings. This is the Method that is used to output the actual HTML that has been dynamically generated from all the foregoing processing within the page. The ASPX page passes a Framework object called a HTMLTextWriter into the Method as an argument. That HTMLTextWriter contains the page’s calculated HTML output specific to the present context of the control.

In 99% of all cases, the HTML generated by ASP.Net will be smart enough to ensure that what the developer intended to be presented to the user is what actually gets sent. However, there are a small number of cases where pages are just a little too complex, or where the evolving capabilities of the evermore complex browsers that are continually being developed falls out of sync with the most recent version of the .Net framework, leading to the ASP.Net rendering process sending HTML that is inappropriate for a particular user’s setup. In these cases, the Render Method may be overridden by the developer.

The following example shows one way of overriding the Render Method, that I used on a live project recently. The basic crux of the problem was that the ‘name’ attributes of the HTML tags rendered by the ASP.Net engine were of a particular format, and, for the purposes of working in harmony with another solution that I didn’t have access to the source code for, those name tags had to take on a different naming convention. I tried a couple of approaches, but the one that produced the most satisfactory results is reproduced below. The basic jist of the solution is that the Render Method is overridden in my custom user control, and HtmlTextWriter object that the Render Method takes as input from the ASPX page is tinkered with to ensure that each of the name attriubtes inserted by the ASP.Net engine is replaced by deliberately-set name tags chosen by the developer instead:

protected override void Render(HtmlTextWriter writer)
{
    if (QuestionLabel != String.Empty && RenameControlsAsPerQuestionLabel == true)
    {
        StringBuilder sb = new StringBuilder();
        StringWriter sw = new StringWriter(sb);
        HtmlTextWriter hw = new HtmlTextWriter(sw);

        base.Render(hw);

        if (ResponseControlType == ControlTypeEnum.CheckboxGroup)
        {
            foreach (ResponseOption o in AvailableResponses)
            {
                sb.Replace(
                    "name=\"" + o.ResponseCheckBoxForCheckBoxGroupTypeQuestions.UniqueID + "\"",
                    "name=\"" + o.ResponseControlName + "\"");                
            }
        }
        else
        {
             sb.Replace("name=\"" + responseCtl.UniqueID + "\"", "name=\"" + QuestionLabel + "\"");
        }

        writer.Write(sb.ToString());
    }
    else
    { 
        base.Render(writer);
    }
}

The times when developers should need to override ASP.Net’s natively-generated HTML are few and far between, but it’s useful to know how to do this should it be required.

Unload

The last thing that happens before the processed page gets output to the user that submitted/requested it is that the Unload Event gets called for each control on the page, then for the page itself. This is the best place to close any open connections to databases or files at the server side (either in the page level event for general connections, or in control-level Unload events where a specific control has exclusively used a particular resource during the processing of the page).

That’s pretty much it for the page life cycle. It should be noted that the life cycle for a CallBack is slightly different, but similar in most of the important respects noted above (the main difference is that Callbacks don’t involve submitting the whole page for processing, only discrete elements of it, and that consequently ViewState is therefore unaffected by Callbacks). It’s pretty amazing to think how much innovation and ingenuity has gone into making what was originally a static document delivery system into the fully-interactive medium that it’s since become.

How to Recruit and Vet Technical Professionals

2010-08-13T23:55:00.015+01:00

Over the years, I’ve had several experiences of being on either side of the recruitment table. At different times, I’ve been the hiring manager looking to augment the team I’ve been leading with a skilled technical professional, and at other times I’ve been that external technical professional, with skills, experience and insights to offer the team I’d be joining. Those experiences on either end of the equation have led me to some conclusions about the best way to go about ensuring that each party to the process gets what they intend out of the deal. For the hiring manager, that’s a new and well-motivated team member that’s able to bring some desired skills into the team, and for the candidate it’s the opportunity to meaningfully demonstrate what they can do and determine what the opportunity has to offer them. Those goals aren’t in competition with one another; a “win, win” is what each party should be looking for when it comes to matching the right people to the right roles. It’s only when each party gets what they’re looking for that everyone involved (the hirer, the hired, and any intermediaries) can consider that the process has been truly successful. This article contains some thoughts on how each of the various parties to the process can help ensure a mutually-beneficial outcome.

One of the difficulties with recruiting technical professionals is that you will sometimes find yourself in the position of assessing people that have skills you don’t yet have. For intermediaries like recruitment consultancies, HR departments, and for non-technical hiring managers, you can substitute the “sometimes” in that last sentence for ‘always’, and the “do not yet have” for ‘will never be interested in personally acquiring’. That’s merely a fact of the different types of value those parties add to the process; similarly, you can be sure that most prospective technical hires will never be overly interested in finer details of employment legislation, employer branding, marketing, or abstract management theory. How, then, if you’re not a technical professional yourself, do you go about determining whether the person in front of you has what it is that you’re looking for? Before answering that question, here are some likely approaches that might seem reasonable at the time, but which, depending on how they’re carried out, may not provide the outcome you intended:

1) Sending an intermediary to do your first interview for you

Whatever else you do, as a hiring manager my advice is not to make the mistake of letting someone else represent your company or department to prospective new employees. Your HR department and any external recruitment consultancies you may engage can certainly take the marketing burden out of sourcing suitable candidate CVs for you, and they can also provide a screening service to ensure that you don’t need to deal with the initial sift of wholly-unsuitable applicants yourself, but they’re not there to conduct any actual interviews or assessments on your behalf.

Typically, what an agency will do when they receive a brief from a hiring manager is they’ll advertise for suitable candidates using the job spec you provide on several of the industry-specific online recruitment websites such as JobServe, etc. The agency will remove your company’s name and identifying details from their listing, so that any less-reputable candidates and competitor agencies wont attempt to contact you directly. The recruitment consultant will sift the CVs they receive in response to their advert, will discount any outright unsuitable applicants (e.g., you’re looking for a Java guru, and it turns out the candidate has made coffee once), and they will conduct a brief telephone screen with each short-listed candidate to make sure that their stated skills, salary aspirations (or daily rate, for a Contractor) match with what you’re looking for. A good HR professional or external recruiter will also be able to give you as hiring manager advice on the state of the skills market, average salaries that other organisations are paying for roles similar to the one you’re recruiting for, and will be skilled at extending and negotiating a mutually-beneficial package when it comes time to do that. Make no mistake about it, though: for all the value they can add, your recruitment consultant or HR professional isn’t in a position to conduct an in-depth technical interview or make a recruitment decision for you, and they’re not there to represent what you have to offer to the candidate – that’s your job.

Interviews are a two-way street, and if you make the mistake of letting your department be represented at a first interview by someone that doesn’t even work in your department, don’t be surprised if the most marketable candidates fail to be impressed by having to run a gauntlet of your intermediaries before even getting to meet an actual decision maker, and opt out of your process before you get a chance to assess them.

2) Getting the candidate to write some code using a pen and paper.

It’s certainly useful to get a candidate to write code at some stage in the interview process (and this is in fact something that many good developers look for in the recruitment processes they’re subjected to – an employer that tests their ability to write code not only gives them a chance to prove themselves, but also gives them some confidence that their colleagues-to-be will be as skilled as they are, having come through a similar process themselves: more on this later). In my experience, though, it’s never a good idea to ask a developer of any level of experience to write code using a pen and paper. Doing so is akin to asking a skilled chef to cook you a meal.......with their feet. Which is to say, it’s simply the wrong tool for the job, and not in any way indicative of the relevant skills you should be looking for.

An analogy I use when highlighting why pen and paper is the wrong medium for assessing an ability to write useful code is the telephone. Up until the mid-nineties, most people were able to remember lots and lots of their friends’ telephone numbers off by heart. It wasn’t an uncommon nor an especially useful skill, it was just a somewhat abstract and unusual ability that everyone had spontaneously acquired because of the limitations of the way the telephone medium worked back then. These days, in the age of near-ubiquitous use of mobile phones, less and less people choose to remember such meaningless lists of numbers off by heart. Instead, everyone tends to use the standard address book function on their mobile phone to attach meaningful text labels to the people with whom they wish to communicate, and look up those labels whenever they need to make a call. You often find people looking up numbers on their mobiles these days, even when they’re using a desktop phone, because it’s become the modern paradigm of how to efficiently access that category of information. The essential skills of how to use a telephone and how to have a meaningful conversation with another person that you can only hear but not see are still the same today as they were in years gone past; it’s merely the tertiary skills surrounding the medium that have evolved.

With reference to the above sociological changes that have come about as a result of advances in telephony technology, asking a developer to write code with a pen and paper is a bit like attempting to assess a person’s ability to use a telephone by asking them to write down all of the telephone numbers they know off of the top of their heads. In much the same way as telephone handsets have evolved, development environments have changed a lot in the past 15 years too. Round about that same time in the mid-nineties that everyone in society possessed ubiquitous Rainman-esqe abilities to recall lists of essentially meaningless numbers in order to be able to communicate using the telephone, developers once had to remember most of the syntax of the languages they worked with in their heads. These days, in the age of smart Integrated Development Environments (IDEs), that’s not the case any more. With the advent of Intellisense, Code Snippets, Templates, and Keyboard Shortcuts, there are many more efficient ways of coding today than there were even five years ago, and new tools are becoming available all the time. These days, if developers want to insert a Constructor into a class they’re designing in C#, they don’t need to recall the exact format of such a code fragment from memory, they can just type ctor, hit tab, and all of the syntax for a parameterless Constructor that is meaningful within the context of the class they are creating is inserted for them. The real skill isn’t in remembering the syntax, it’s in knowing what a Constructor is, when to use one, and in understanding why a parameterless one can be overtly implemented in a class but not in a struct. When you can’t quite remember which namespace one of the 3,500-odd pre-defined .Net Framework classes resides within, the latest development environments will help you by suggesting ‘Imports / using’ directives that you may have missed. When you create a custom class in a project, provided you’ve been smart enough to structure your project logically using folders, the Visual Studio development environment will create meaningful namespaces for you. These cues, and many others, allow developers to concentrate on the important part of their job – creating innovative, robust and reliable solutions to well-defined problems – and relegates the non-cognitive and repetitive parts of the process to the place where they belong: the subconscious.

Asking a developer to undertake a pen-and-paper coding exercise never reveals any of that relevant knowledge, insight or craft. Instead, it obstructs many good developers from demonstrating the meaningful work they can do inside a real development environment that takes care of the repetitive, irrelevant and non-creative parts of the process, and lets them focus on the meaningful work they’re actually good at: producing useful, stable, innovative solutions.

3) Trivial Pursuit

Nearly as bad as using pen-and-paper coding, is having a list of trivia questions associated with the skill of interest, and asking the prospective developer a pre-set list of abstract multiple-choice questions. Generally speaking, interviewers do this when they don’t have an in-depth knowledge of the topic themselves, because it provides an easy way for them to understand whether the answers they receive are ‘right’ or ‘wrong’, without the interviewer having to understand why they may be right or wrong themselves. It’s not advisable to go down this route, for two reasons. Firstly, to be blunt, it’s pretty disrespectful to the interviewee; if you don’t understand the answers to the questions you’re asking yourself, how can you be certain that the questions and the way you’re framing them makes any sense to someone that is actually knowledgeable on the subject? Go down this route, and it’ll quickly become clear to an experienced candidate that you don’t know what you’re talking about, and are merely repeating what’s written on a piece of paper in front of you parrot-fashion. That in turn will ruin their confidence in your ability to assess them meaningfully, and even if they do ‘pass’ your test, you may very well find the best candidates will opt out of your process as a result. Secondly, even if the developer isn’t put off by being quizzed by someone that clearly doesn’t understand the subject themselves, a process based on the ability to recall abstract facts fails to address the fundamental difference between knowledge and intelligence. I’ll take an intelligent developer that has yet to acquire knowledge in a given area over one that has learned to recite stock answers to set questions but has not one iota of ingenuity and creativity about them any day of the week, and twice on Sunday.

In short, if you use set lists of coding trivia that you don’t really understand the answers to yourself in a misguided attempt to assess your candidates, whilst you may end up with someone that would do very well on a VB Pub Quiz Team, you’re just as likely to end up with an individual that couldn’t implement an IPissup interface within a Brewery class if their lives depended on it. You may find to your horror, after they come on board, that they are not after all the learned experts you supposed, but had merely read the same three articles on Wikipedia as you used when compiling your list of questions.

Finally, I would strongly advise against using ‘online tests’ to assess candidates. Such ‘tests’ tend to have all of the abstractness, lack of context, and general irrelevance of the in-person version of the Meaningless Trivia Test, but are even less personal than the in-person variety.

4) Getting the candidate to do some real work

Getting close to the way I recommend doing things now, but with caveats. The best developers, like any skilled professional, are happy to demonstrate that they can do the work you’re asking them to do. They welcome employers (or customers, in the case of contractors) exercising meaningful due diligence that allows them to demonstrate they’re the right person for the job. As I mentioned earlier, this is something that many of the best people actively look for in a recruitment process, because as well as giving them an opportunity to prove themselves, it also gives them confidence that their colleagues will be every bit as on their game as they are. Good people want to work with other good people, from whom they can learn and share knowledge, and alongside whom they can grow and develop as ever-more experienced professionals. The fly in the ointment is that there are a small number of less-reputable organisations out there, also advertising jobs, that are only too happy to ask for samples and free work, without ever intending to recruit. For such organisations, unfortunately, it’s a ‘creative’ way of saving on their training budget by getting an external professional to give some free demos under the auspices of an interview, or of getting small projects done for free. For this reason, you need to be careful; you don’t want to chase good people away by coming across as a freeloader.

One good way of avoiding your organisation’s honourable intentions being misconstrued, is to not make providing a sample of the candidate's work the very first stage in the process. Interview the person first, and invest some of your time to show them a little of what you have to offer them as an employer, before asking them to invest their time in providing free work for you. That approach immediately makes you stand out as an organisation that’s serious about recruiting. Organisations that are instead only looking for freebies, generally make it obvious by asking prospective candidates to invest their time in providing a demo solution after only a short telephone screen, and well before the organisation has demonstrated that it has anything of substance to offer the right candidate. Less reputable organisations will also have the cheek to ask for second and third samples of work, and changes to work submitted, never attempting to explain why earlier demos didn’t satisfy their ostensible purpose of demonstrating the candidate’s technical ability. I advise those on the hiring side of the recruitment table never to behave this way; not only will it be entirely obvious to people with marketable skills that you’re merely freeloading, but the best people can and will inform their equally-skilled professional colleagues about their experience with your process, and it’s very likely that you’ll be left with only sub-standard applicants should you become serious about recruiting at any point in the future. Reputations are hard to win, and easy to lose; for candidates, for employment brands and for internal and external recruiters of all flavours alike.

So much for the ‘wrong’ ways to go about finding the right people to join your fold. Now, the right way. As touched upon above, the best people will welcome you engaging in due diligence. There’s no better way to do this than by getting your existing technical staff to speak with the prospective new member of the team. Ideally, on your side of the interview table, as a minimum, you’ll have your lead developer or development manager (whatever nomenclature you use within your particular organisation, they should be the person your most senior management are most likely to go to when they want an opinion on how anything technical should be tackled within your organisation).

Invite your prospective new employee in to speak with you and your lead tech informally for a first interview (or a telephone screen, if distance is an issue), and don’t beat them up during that initial interview. The first interview should be to establish just two things: one, whether the person in front of you is manifestly unqualified for the work concerned, and two, to give them a taste of what you have to offer and to let them know what you expect in return. That’s it for the first meeting; those are the only goals. The aim isn’t to establish whether they’re exactly right for your organisation just yet, and it’s not to make any hasty decisions based on limited information. During your conversation, ask them to tell you about something particularly innovative that they’ve worked on recently, or better still their pet project; every developer has at least one on the go, and, whilst they’ll mostly be commercially irrelevant to your business, they’ll tell you a lot about how well your prospective new colleague is able to communicate the concepts they understand to others.

As mentioned earlier, I strongly advise against asking coding trivia questions from a set list, but it’s perfectly acceptable to have your internal technical expert ask the candidate to explain more about the nuts and bolts of the candidate’s pet project or most recent work. This is why you have your best existing internal technical resource on your side of the interview table; they should be able to probe and question during a discussion of the design, without coming across as needing to be the smartest person in the room. Your technical expert should avoid the temptation to ask the candidate any ‘trick questions’, that rely on obscure technical knowledge that they’ve only just encountered themselves, but it’s OK to probe a little to see how deep the candidate’s knowledge of underlying concepts is. It’s also OK to ask about newer technologies that the candidate may or may not have encountered; if they’ve not, you’re looking for them to tell you so rather than for them to waffle or bluff their way through – knowing what they don’t know is a good trait in a developer. Your internal technical expert may not know everything that the candidate does about the subject at hand, especially if the candidate is intended to add a skill to your team that it hasn’t yet mastered, but there should be enough common ground for your tech lead to determine whether the candidate outright doesn’t know their subject area.

After that first interview, ask suitable candidates to participate in a coding task. You can choose to allow your candidate to do this at home, or within your premises; it shouldn’t matter which to you, although bear in mind that some developers wont have access to all of the tools at home that they’re used to having in their workplace. The developer should have access to every resource they’ll have available on the actual job, including the internet, any reference books they want, MSDN, etc. They should also have a reasonably-powerful development machine, similar to the one they’d be using if they were to be recruited. Make sure that the problem you ask them to solve is realistic, and can be developed by someone with reasonable skill in the area you’re recruiting for within 3-4 hours max. Ideally, get one of your existing developers that wasn’t involved in designing the exercise to try out the problem first, to be sure it’s of a reasonable level of difficulty. Make it obvious to your candidate that you’re not asking them to do unpaid commercial work, by presenting them with an abstract problem that is clearly unrelated to your business (e.g., perhaps ask them design a Windows Service that writes an entry to the event log every time the sum of the minutes in the current time is a prime number, or something similar). It’s not usually possible to present candidates with a real commercial problem, because even if it’s something your team has actually tackled within a set time frame, chances are you brought existing knowledge to your understanding of the problem that brand new candidates wont be able to draw upon.

After your candidate has completed their solution, get them to talk through their design with you, and review it with them in the same open and non-critical way that you’d conduct internal code reviews on real, commercial pieces of work. Doing this will not only tell you a lot about how the candidate approaches technical tasks, it will additionally give you an insight into how well they work with others as part of a mutually respectful and co-operative team. If done properly, it’ll also give the candidate a good insight into your culture, and help you both to decide whether or not you’re a good fit for one another. What you should be looking for in an ideal candidate isn’t just a window onto their existing knowledge, but their ability to apply what they know to new problems, whether they have the honesty and self-awareness to recognise what they don’t yet know, and, of key importance, whether they have the initiative to find things out as and when the need arises. Those are all key traits that a set list of coding trivia questions or a faceless online test would never tell you.

After your ‘technical review’ with the candidate, discuss your findings internally amongst the recruitment team. Subsequently, if you decide to proceed, have one, final interview with the candidate, to review all that you’ve learned about one another in a post-mortem type setting. Ask them about their experience of your process, discuss any issues that you’d like to clarify with them, and be prepared to take any questions they’ll have of you. This meeting is about rounding out what you know about one another, and finalising any missing details.

Once you’ve completed the above process, your internal ‘recruitment team’ (consisting of the hiring manager, your internal technical expert, and any advisers from HR that you’ve consulted) should be in an excellent position to decide whether the person in front of you is a right fit for your needs or not. Don’t be tempted to conclude that just because you’ve come all the way through the process, you need to extend an offer; psychologists call that phenomenon ‘justification of effort’. Remember that your process is designed to give you the information you need to make an informed decision, and to give a favourable impression of your organisation to everyone that has taken the time to apply. It’s not merely about picking the last person standing.

Put any candidates that have made it to the end of your process into three categories: first choice, any second choices, and any unselected candidates. Contact unselected candidates right away, to thank them for their time, and to tell them they haven’t been selected. Keep any second choices in reserve whilst your external recruiter extends and negotiates a mutually-agreeable offer with your preferred candidate (hiring managers should never do this part themselves – negotiation is skill that most hiring managers don’t have, and, even when they do, this process is still at its most effective when conducted via an intermediary). If an offer can’t be agreed with the preferred candidate, approach any second preferences and try to come to an agreement with them.

At the end of the process, let every candidate that hasn’t been selected know the outcome, and, if they’d like to know, the reasons for your decision. The classiest way of doing this is for the hiring manager to call each individual personally, to thank them for their time, and to express regret that they weren’t the right person on this occasion, followed up by a letter to confirm the news. Many hiring managers shy away from doing this, perhaps through fear that the candidate will react badly. In my experience, though, most if not all professional candidates really appreciate it when the organisations in which they’ve invested their time and effort take the time to conclude the process properly. In years of informing people in person when they’ve not got a job, I’ve never once had the experience of a candidate reacting with anything other than courtesy and appreciation that I had enough respect to let them know the outcome myself, when I called to let them know the decision. If you’re unfortunate enough to experience a candidate being aggressive, or treating the call like a debate rather than a simple communication of your decision, feel free to end the call quickly – you’re not there to be their career counsellor, and you’re not there to justify yourself beyond respectfully communicating your decision, and your reasons for making that decision if the candidate is interested in hearing them. Conclude matters this way, and you’ll always have a steady stream of candidates for jobs that you may advertise in the future; word gets around about which organisations treat candidates well and which don’t, and it’s amazing how often that candidate that wasn’t quite right for you yesterday, has exactly the right skills for the position that comes up tomorrow, or knows someone that does. End things well, and you’ll always have the ability to open dialogue again if it becomes relevant to do so.

Structs and Classes

2010-08-12T12:54:00.017+01:00

.Net provides two basic object types that can be used to construct more complex objects: Structs and Classes. These object types are made up of similar features, and can be used to fulfil many of the same tasks as one another. There are, however, some important distinctions between what you can do with Structs and with Classes, and between how similar features are implemented differently by each object type. This article describes those similarities and differences, and provides some suggestions for when and how to use each type.

The Similarities

Structs and Classes are both capable of utilising Fields, Properties, Constants, Methods, Events, Handlers and certain types of Constructor. They are both capable of being instantiated, and they are each able to have variables declared as being of the type they define. Both can model data objects, using much the same syntax in each case, and indeed you can often convert a Struct to a Class and back simply by changing the word struct in its definition to class, or vice-versa. Both types of entity may also implement Interfaces.

The Differences

The most fundamental distinction between Structs and Classes is rooted in a .Net concept known as the Common Type System. When you compile a program written in any of the languages that target the .Net Framework, the first step that happens is that the code gets converted by the specific compiler for the high-level language (e.g., C#, VB, C++, or whatever) into something called Microsoft Intermediate Language (also known as the Common Intermediate Language, often abbreviated to ‘IL’ for short). The IL representation of a .Net program is then converted into a set of platform-specific machine code instructions by the .Net runtime execution environment, known as the Common Language Runtime (CLR). [ NB: For Java developers, the concept of .Net’s IL is analogous to the way that Java compilers convert raw Java code into Bytecode, to be run within a Java Virtual Machine.]

Part of what makes the process of converting any of the languages that target the .Net Framework into IL possible, is the fact that each of those different languages uses the Common Type System (CTS) mentioned above. The CTS defines the basic set of types (boolean, integer, etc) that IL understands and knows how to work with. [Actually, the set of types that IL understands is far larger than any of the languages that presently target the .Net Framework is capable of modelling, and not all of the languages that target the .Net Framework implement exactly the same subset of those IL types, leading to the potential for subtle language interoperability issues, but that’s a discussion for another day.]

The key point of relevance to the subject under discussion is, there are two core types defined within the CTS, which are known as Value Type and Reference Type respectively. Every type in any .Net program derives from one or other of these two possible base types, and which one they derive from dictates how they will be stored in memory, how the object may be inherited, and how objects that are of those types will behave.

Getting back to Structs and Classes, it’s the case that every Struct defined in a C# or VB program is considered to be a Value Type by the CTS, and every Class is considered to be a Reference Type at the very root of its inheritance chain. This difference in base type inheritance is what accounts for many of the differences between Structs and Classes, which are listed below:

Differences in Implementation Inheritance

As noted above, both Structs and Classes may implement Interfaces. However, only Classes may overtly use Implementation Inheritance to inherit from another object. Classes, unlike Structs, may also be inherited by another object.

At their root, Structs derive from a CTS type called System.ValueType, which in turn inherits from System.Object. Classes with no overtly-defined base inherit directly from System.Object (and, for Classes that don't inherit directly from System.Object, there may be any amount of Classes in between System.Object and themselves).

Concentrating on Structs, you may find it surprising to know that most of the defined system types in C# and VB (e.g., integer, double, decimal, etc), also derive from System.ValueType, and are in fact implemented as Structs. If you mouse over the keyword of any data type implemented in this way within C# or VB, this fact becomes readily apparent:

System.ValueType doesn’t add any functionality to Structs that is not also available to Classes through their common inheritance from System.Object, but it does replace some of the functionality present in System.Object as virtual methods with implementations that are more appropriate for Structs.

Structs, in short, are intended to be used for tasks that require allocating small, fixed-size chunks of data, that need to be able to be accessed and changed rapidly, without incurring an undue performance hit in managing the memory resources that are allocated to them. That’s why they’re used to implement the basic data types such as integer, etc. : when a developer defines an integer variable, they expect to be able to begin using that variable to store numbers within the permitted range for that type immediately, without needing to mess around with allocating space in memory by using a new() operator as a separate activity each and every time, and without checking whether any modifications their application makes to the value stored in the variable has had any implications for the amount of memory required. They want to be able to access any values placed in their variable readily, without having to rely on the underlying implementation to use pointers to look up an address in memory, then decide what has been stored there, as a two-stage process. Structs enable developers to achieve this rapidity of declaration and access to memory chunks of a fixed size, but the trade-off is that they can’t be used to achieve true Implementation Inheritance, which would require management of an area of memory of a variable size.

So, whilst Structs are easy to consume and fast to access, if you need to use Implementation Inheritance, that’s a clear sign you need to use a Class instead.

Structs can be consumed without explicit instantiation, Classes cannot

When you create a variable of a type defined by a Class, you need to use the new() operator to instantiate that object before you can access the properties of the object the variable represents. With Structs, this is not the case. Take the following simple example, using a struct:

public class StructsAndClassesDemo 
{
    static void Main()
    {
        MyStruct myVariable;
        myVariable.SomeInteger = 1;
        Console.WriteLine(myVariable.SomeInteger);
    }
}

public class MyClass 
{
    public int SomeInteger;
}

public struct MyStruct 
{
    public int SomeInteger;
}

This will compile and run correctly, outputting “1” in the Console window. If, on the other hand, we change the Main() Method to:

a compilation error will occur, since we have tried to use an uninstantiated variable of a Reference Type.

NB: You still need to instantiate an object of type struct before you may access Properties (as distinct from Fields) of that object.

Variable Assignment works differently for Classes than for Structs

Because Structs are Value Type objects, variables of types defined by Structs behave somewhat differently than variables of types defined by Classes. Consider the following simple program:

public class StructsAndClassesDemo 
{
    static void Main()
    {
        MyClass myVariable1 = new MyClass();
        MyClass myVariable2;

        myVariable1.SomeInteger = 1;
        myVariable2 = myVariable1;
        myVariable1.SomeInteger = 2;

        Console.WriteLine(myVariable2.SomeInteger);
        Console.ReadLine();
    }
}

The above example would output “2” in the console window. If we instead exchange the usage of a Class type object for a Struct, and keep the variable assignment logic exactly the same:

public class StructsAndClassesDemo 
{
    static void Main()
    {
        MyStruct myVariable1;
        MyStruct myVariable2;

        myVariable1.SomeInteger = 1;
        myVariable2 = myVariable1;
        myVariable1.SomeInteger = 2;

        Console.WriteLine(myVariable2.SomeInteger);
        Console.ReadLine();
    }
}

The revised program will output a “1” in the console window instead.

This highlights a key difference in the way that Value Type and Reference Type objects are treated in memory. Reference Type objects (in this case, Classes) actually represent a pointer to an address in a part of the computer’s memory known as the Heap. When assigning one variable to be equivalent to another variable, as happens in the line myVariable2 = myVariable1, what happens in the case of the variables concerned being of a Reference Type is that it is the pointer to the relevant address on the Heap that gets copied to the variable being assigned to, not the actual data that is contained at the address itself. An upshot of this is that when the variable that has been assigned from, in this case myVariable1, subsequently gets updated so that its SomeInteger field takes on the value “2”, myVariable2 in effect gets its value updated as well, since it is the object that resides at the location in memory that is being pointed at by both myVariable1 and myVariable2 that has been modified.

Values associated with variables of Value Types such as Structs, are stored in a different place in memory, known as the Stack. In the case of Value Types, assigning one variable to be equivalent to another does copy the actual data from the object being assigned from to the object being assigned to. Because of this, when the object that has been assigned from is subsequently updated, the effect of this change is not felt by any variable that had previously been assigned to by that variable. This is why the value “1” is returned in Console window in the second example above, in contrast to what happens when the types being considered are Reference Type variables based on custom Classes.

Classes can have overt Parameterless Constructors, but Structs cannot

As was mentioned earlier, you can use a Struct without explicitly instantiating it using the new() operator. It’s also the case that you may use the new() operator if you wish (which has the effect of instantiating the whole object for use, including any Fields the Struct may contain, by calling an instrinsic parameterless Constructor for the Struct). However, when you’re designing a Struct, it is erroneous to overtly define a parameterless Constructor for the Struct, since one is declared behind the scenes by the C# or VB compiler for you. You may still create additional Constructors that do take parameters. So, whilst the Constructor:

public class MyClass 
{
    public MyClass()
    {
        SomeInteger = 99;
    }

    public int SomeInteger;
}

is fine in a class, a similar Constructor for a struct would result in a compilation error. You may only provide a parametered Constructor for a Struct, like so:

public struct MyStruct 
{
    public MyStruct(int intialIntegerValue)
    {
        SomeInteger = intialIntegerValue;
    }

    public int SomeInteger;
}

The reason for disallowing overtly-defined parameterless Constructors in the case of Structs is that the CLR, as part of that trade off of rapidity of access for completeness of memory management mentioned earlier, does not guarantee to call such Constructors for Value Types, and so any code you place in such a parameterless Constructor would not be guaranteed to run once the program was fully compiled. This is down to the same phenomenon that makes it possible for the Fields of Structs to be accessed and set without initialisation; if the compiler spots an optimisation for your code such that you are only accessing the Fields of a variable that is of a type defined in a Struct, it will not bother generating the IL to call the Constructor for that Struct, and will instead make assumptions that the Fields you are accessing will contain meaningful values. Curiously, if creating the IL directly yourself, it would be perfectly possible to create a parameterless Constructor, and have it run every time, regardless of any apparent optimisation that may be possible, but then if you had a task that required a Constructor to run every time, that’d be a pretty clear sign that what you really needed to use was a Class. For now, in the trade off of best speed for true object orientation in the case of Structs, the designers of the VB and C# languages have decided to take the simplest route, and have prevented parameterless Constructors from being defined for Structs altogether.

You cannot initialise a field within the definition of a Struct

Both Structs and Classes can have Fields. In the case of Classes, it is possible to give a Field an initial value within the definition of the Class itself, like so:

public class MyClass 
{
    public int SomeInteger = 99;
}

Trying to do the same within the definition of a Struct, however, will produce a compilation error:

The reasons behind this difference in the way that Structs and Classes are permitted to operate cuts right to the heart of the different ways these distinct types of object are treated in memory. For Classes, because their values are physically stored on the hardware’s Managed Heap, and because .Net’s Garbage Collection mechanism deals with managing resources on the Heap, the CLR can guarantee to have cleared the area in which objects defined by Classes will be stored before placing any new object in that area. Because of the Garbage Collection process, the CLR can be sure that the Properties and Fields of any objects defined as Classes will either be null, or that any values they do hold will have been deliberately assigned to them. CLR is therefore happy to have Class –type objects that have a mixture of assigned and as-yet-unassigned Fields and Properties.

The Stack, on the other hand, where Structs are stored, is much less well managed (and, as a trade-off, it is generally much quicker to access and modify resources placed there). However, because there is no Garbage Collection process going on in the background to manage that area of memory, Structs will generally be assigned to a random area of the Stack, big enough to contain the Struct, but where the CLR cannot guarantee that any values placed in that area of the Stack have been deliberately assigned to the Struct that now resides there, or whether the area in memory that happens to currently be assigned to a given Field or Property of a Struct was actually a piece of data from another unmanaged object that was left behind when that object was cleared from the Stack at some prior point.

In an effort to mitigate the uncertainty about the whether parts of a Struct have been deliberately set or are merely a throwback from prior use of the same location of the Stack by some other unrelated object, Structs are restricted to having their fields initialised in a certain controlled way, that can be efficiently checked by the compiler. If you use the implicitly-defined Constructor, new MyStruct(), to create a new instance of a Struct, this has the effect of setting all of the Struct’s Fields and Properties to their default values (so, 0 for int -type Fields, etc). If you define your own parametered Constructor for a Struct, the compiler will warn you if you fail to initialise any of the Struct’s Fields within that custom Constructor:

As mentioned earlier, you don’t need to initialise a Struct at all before you begin to assign values to it. If you do use a Struct –type object in this way, and you fail to assign a value to one of the Fields of that Struct variable before assigning the value of that variable to another variable of the same type, you will also get a compilation error:

By removing the possibility that Fields may be set within the definition of the Struct itself, it allows the compiler to efficiently focus on other more straightforward possible places (i.e., within a Constructor, if one is used, or within the scope of a variable defined to be of the type the Struct declares, if no Constructor is used), to determine whether all of the Fields of a Struct-type object have been fully initialised before those Fields can be accessed by or assigned to any other object.

Structs may not have a Destructor

Because instances of Structs exist on the Stack and not on the managed Heap, the concept of Destructors (i.e., an overt override of the Garbage Collection mechanism to allow the developer to specify how to dispose of temporary resources) clearly does not apply to them:

So, in summary, the differences between Classes and Structs are:

· Classes are Reference types, whilst Structs are Value Types.

· Classes are physically stored on the Managed Help, whilst Structs are stored on the Stack.

· The effect of variable assignment works differently for Classes and Structs.

· Both types of object can implement Interfaces, but only Classes may overtly employ Implementation Inheritance.

· Structs cannot have overt parameterless Constructors, Classes can.

· When you define your own parametered Constructor for a Struct, the compiler enforces that you must explicitly set the value of any Fields within that Constructor to avoid said Fields containing spurious values. For Classes, the compiler entrusts the Garbage Collection process with this task.

· You must instantiate a variable based on a Class, whilst you may instantiate an object based on a Struct (though you don’t have to).

· Structs may not have default values for Fields, Classes may.

· Where you choose not to instantiate a Struct –type variable, the compiler will enforce that you must set each Field of that instance of the Struct before you can use the variable for assignment.

· Structs may not utilise Destructors.

Because of these different characteristics, Structs should be used most often for small structures, where the values contained therein will not be frequently re-assigned between variables, thereby creating a lot of duplicate data in memory, and where there is no need to use Implementation Inheritance.

Classes should be used where a more complex object that will be frequently passed around between parts of the program needs to be modelled, and in instances where it doesn’t matter that assignment between variables copies a reference to the object being assigned from, rather than the underlying data of the object itself being assigned.

Extension Methods

2010-07-21T20:13:00.030+01:00

Extension Methods were introduced in the revisions to the C# and VB .Net languages that accompanied the release of Framework version 3.5 in November 2007 (that is, C# 3.0 and VB 9.0 respectively). They allow developers to augment – to extend – existing classes and interfaces by facilitating the creation of new Methods, without breaking the encapsulation of the original type/interface being extended. This can be achieved without the developer having to create a whole new type that derives from the type they wish to extend, and without their needing to have access to or know about the internal implementation of the type/interface they are extending. Used sparingly and intelligently, Extension Methods can be an extremely powerful and useful technique in a developer’s repertoire. This article contains a brief background on the advent of Extension Methods, a discussion of the syntax for implementing them, and some suggestions as to where and when best to use them.

A little background...

It’s no accident that Extension Methods were first included in the same version of the .Net Framework that also introduced LINQ. A full discussion of LINQ and the capabilities that it appends to the .Net language is a separate topic for another time. In summary, though, and of relevance to the present topic, LINQ (Language Integrated Query) is a syntax extension of the .Net languages that allows types that implement certain existing Interfaces to be directly queried in a native language syntax that reads very much like the SQL statements that had hitherto traditionally only been used within DBMS such as SQL Server. Using LINQ, developers could for the first time query, sort, and otherwise work with types representing data collections in-memory. The following simple program demonstrates LINQ at work on a collection of type string[] :

using System;
using System.Linq;

namespace Demo
{
    static class Program
    {
        static void Main()
        {
            string[] _CapitalCities = new string[5] { "Edinburgh", "London", "Paris", "Rome", "Stockholm" };

            foreach (string city in _CapitalCities.OrderByDescending(city => city))
            {
                Console.WriteLine(city);
            }

            Console.ReadLine();
        }
    }
}

The above program produces a Console window, listing the five cities stored in the variable _CapitalCities in reverse alphanumeric order. It does this by accessing a new method for type string[] called OrderByDescending. If you remove the using System.Linq directive from the above program, you will find that the compiler no longer recognises a Method called OrderByDescending for objects of type string[]. So what’s going on?

Because the type string[] implements an existing generic interface called IEnumerable<T> that was defined in previous versions of the .Net Framework, and because a new class called System.Linq.Enumerable that was appended to Framework 3.5 by the designers of LINQ defines an Extension Method for IEnumerable<T>called OrderByDescending, variables of the type string[] acquire the new Method observed, which is only accessible within the context of any object that references the System.Linq namespace.

LINQ uses Extension Methods in this way to facilitate adding new functionality to existing Framework definitions such as IEnumerable<T>, for the purpose of enabling objects that utilise those definitions to be instantly usable in conjunction with the new LINQ syntax. Extension Methods allowed them to do this without causing breaking changes to designs that preceded LINQ, and which consumed the original, un-extended versions of those existing Framework objects. Alternative approaches by the designers of LINQ might have included updating all of the Interfaces that they wanted to add new functionality to (which would have been great for LINQ, but would have broken any existing designs that had used previous versions of the updated Interfaces as soon as those designs were upgraded to the new version of the Framework, thereby upsetting a lot of developers and system owners). Or, they could have created an entirely new set of Interfaces, based on the originals, but with the extra LINQ goodness included (would have needlessly added to the complexity of the .Net Framework, which already contained quite enough redundant but kept-for-reasons-of-backward-compatibility features and near-identical object definitions from earlier upgrades and improvements, and would furthermore have needlessly rendered LINQ unusable by existing objects that had implemented older versions of the superseded Interfaces). By using Extension Methods, the LINQ developers were able to add functionality to existing objects, in a way that would only be apparent within designs that utilised their new language feature, and that avoided producing unnecessary breaking changes for developers that were merely upgrading their designs to the latest version of the Framework, but who had no interest in utilising LINQ within their legacy designs. In the process of their work, the LINQ developers gave us a useful additional tool to make much the same subtle enhancements to our own established designs as they had to the preceding version of the Framework.

Implementing Extension Methods within your own designs...

The syntax of implementing Extension Methods for a given class is demonstrated below. Suppose you have an existing class defined in the following way:

namespace RPPClassLibrary
{
    public class Person 
    {
        public Person()
        {
        }

        public string FirstName { get; set; }
        public string LastName { get; set; }
    }
}

If you wanted to extend the class Person to include a new Method called FullName using Extension Methods, the syntax for doing so would be as follows:

using System;
using RPPClassLibrary;

namespace RPPConsumingAssembly
{
    static class Program
    {
        static void Main()
        {
            Person aRachel = new Person() { FirstName = "Rachel", LastName = "Pierson" };
            Console.WriteLine(aRachel.FullName());
            Console.ReadLine();
        }

    }

    public static class MyExtensions
    {
        public static string FullName(this Person pExistingObject)
        {
            return pExistingObject.FirstName + " " + pExistingObject.LastName;
        }
    }
}

The above scenario, where the developer has free access to the class they are extending, isn’t a particularly good example of when Extension Methods should be used, but it is nonetheless a simple enough scenario to demonstrate what the syntax for creating such a Method should look like. The above code snippet takes an existing class, Person, which resides within the namespace RPPClassLibrary, and extends it to include the newly-required Method FullName, only for objects of type Person that are defined within the scope of the separate namespace RPPConsumingAssembly. This is achieved by adding a new static class within RPPConsumingAssembly called MyExtensions. The Main Method of the class Program within RPPConsumingAssembly demonstrates using the new FullName Extension Method with an object of the freshly-extended Person type. The output of the program above is as follows:

To create an Extension Method for any existing class or interface, as the code snippet above demonstrates you need to create a static class at the top level of the namespace in which you want to consume the Extension Method, then create as many public static Methods within that static class as you wish to create Extension Methods for. It doesn’t matter what you call the static class that you use to contain the Extension Methods you define, it matters only that the parameter list for any Extension Methods you define within your top-level static class take the exact format shown above – i.e. (this Person pExistingObject) – changing the type Person for whichever class/interface it is that you are extending. You can include Extension Methods for entirely different existing types within the same top-level static class, provided your definition of each individual Extension Method makes it clear which type your new Method applies to.

When to use Extension Methods...

There is a school of thought that says: “Never!”. The reason for this viewpoint is that extending classes willy-nilly certainly could lead to confusion at a later date, if the class that is extended by Extension Methods subsequently gets directly updated at some point to contain some additional intrinsic Methods with the same signatures as the Extension Methods that have been defined in the interim by external consuming classes. There would be nothing in the compiler that would alert the original author of the class being reviewed to the fact that some consumer of their object had previously extended it in what would in some respects be a potentially conflicting change. What would happen in actuality if the developer of a since-extended class happened to add a new Method to their class that had exactly the same signature as an Extension Method that had been created by a consumer, is that the new internal Method would take precedence, and the Extension Method would be superseded and effectively ignored by the compiler. For example, imagine if the original class in the simple example presented earlier were to be revised at some point so that it looked like this:

public class Person 
{
    public Person()
    {
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string MiddleName { get; set; }

    public string FullName()
    { 
        StringBuilder _FullName = new StringBuilder();

        _FullName.AppendFormat("{0} {1} {2}", 
            FirstName ?? "(No First Name)",
            MiddleName ?? "(No Middle Name)",
            LastName ?? "(No Last Name)");

        return _FullName.ToString();
    }
}

In this scenario, the assembly that consumes the Person class (which would still contain a now-obsolete Extension Method with the same name as the new internal Method FullName that has been added to the original Person class) would still compile, and the program would run without errors, but the output would now reflect the internal, subtly-different, definition of the FullName Method:

The basic issue that some developers have with Extension Methods is that, by some definitions, they break the key object-oriented design principle of encapsulation. That is, they begin to impact upon the ability of objects to contain and control their own definitions, and act as black boxes to consumers. This isn’t an entirely fair criticism since, as the above example demonstrates, the original object remains quite untouched by any external consumers implementing their own Extension Methods for their own internal consumption; there’s nothing about such Extension Methods that prevent the developer of the original object from continuing to be in full control of their object’s design (though there is certainly an impetus on the developer of any Extension Methods to consider the possibility of unexpected behaviour should any object they have extended subsequently have its design changed).

The encapsulation issue aside, as the historical example of the introduction of LINQ demonstrates, there are certain discrete circumstances when it can be very useful to be able to extend the existing definition of an established object, in a way that avoids creating breaking changes for existing consumers of the original object, but that still provides new functionality for new consumers of same. Where Extension Methods are most useful, therefore, is when you are reasonably sure that the object you’re extending wont be subject to further internal change, and the functionality you are adding is specifically useful within the context in which you are adding it.