xult.org

Sometimes things go wrong while you’re writing them. And it’s all the compiler’s fault – there absolutely has to be a problem with it. Oh wait, perhaps it’s actually just a bad bug in the library. No – maybe it’s the other guy on the team who did that weird checkin yesterday, and something’s gone wrong with that.

Actually, it’s probably just you. Almost all of the time, you’ll have a revelatory moment where you realize that you’ve missed something. It could be glaring, or it could be subtle. But there’s a facepalm moment, and then you move on with your life.

But not too long ago, I did enjoy independently discovering this little bug in the C# 4 compiler. It’s a very minor one, but its diminutive status did not decrease my immense enjoyment at its discovery. Behold: an incorrect compiler warning!

using System;
using System.Collections.Generic;
using System.Linq;

namespace ConsoleApplication
{
    /// <summary>
    /// This example demonstrates a small bug in the C# compiler, which
    /// generates a CS0649 compiler warning saying that the "Field" field
    /// is not used.
    /// </summary>
    public class Program
    {
        // making this private triggers the compiler warning
        private class Example
        {
            public DateTime Field;
        }

        static void Main(string[] args)
        {
            var bug = new List<DateTime>()
                .AsQueryable()
                .Select(dt =>
                    new Example { Field = dt } // this object initializer isn't spotted by the compiler
                );
        }
    }
}

I reported this via Microsoft Connect, and I got a very polite response from a Microsoft PM, who (correctly) did not triage it with any great urgency. But it’s still a notch on the old programming belt.

This does of course mean that after years of conditioning myself to expect that I am the culprit, I am back to believing that everything is actually the fault of the compiler/library/etc. Such is life!

It doesn’t exist! That could actually be my entire blogpost, but you’d be left there with a rather disturbed feeling. So we’ll get into detail.

If you have a web service (say, an .asmx file), and you’re planning on it returning JSON into the page, you’ll pop your usual ScriptServiceAttribute in, and get on with it. A few months later, you’re running happily in production, and suddenly you see some requests failing with an HTTP 500 status. How do they fail? An HTTP header comes back as follows:

jsonerror: true

And instead of the nice JSON you were expecting, you get this:

{"Message":"Server was unable to process request","ExceptionType":""}

Well, that’s pretty annoying. That didn’t happen when you built this service. Something must be wrong with the data you’re trying to return. In debug, this would be showing the actual exception and type, but of course you followed best practice and deployed in retail mode, which turned on custom errors. But no problem, let’s have a look in the application’s error log – luckily, you used ELMAH to log all server exceptions.

Nope, ELMAH is showing nothing. How very odd. After a brief check, you realize that it must be because errors in .asmx methods don’t go through Application_Error. No problem, you’ll just have to bite the bullet and check the Windows Event Log.

Nothing is there. The plot thickens.

As far as I know, there’s nothing you can now do except turn off Custom Errors and inspect the problem. There doesn’t seem to be any way to get a hold of it. The great Ayende appears to have experienced a great deal of frustration at this! As always in programming, there will be a way – but I cannot think of a tidy and effective way of making error handling work.

If you’re having this same issue, you might want to assume that there is a problem with serializing a particular type (if you’re returning complex types); or that your total response is larger than permitted by the MaxJsonLength set in the web.config.

Recently I’ve had the chance to help conduct a round of interviews to grow our expanding tech team. Technical interviews should be considerably more straightforward than interviews in other sectors, as it’s a simple matter of assessing the candidate’s level of knowledge empirically, and then determining whether they’d be a good team fit. But somehow it’s just not that simple.

I’ve never been through what I’d call a very technical interview. Sure, I’ve talked tech, but I haven’t felt like I’m undergoing my viva voce. So I’m not necessarily talking from a position of experience. But I think a good interview could definitely go along these lines.

Getting to know you

I’m nervous when meeting new people. I’m also nervous when meeting new people, and asking them for thousands of pounds in exchange for my labour. So I’ll understand, and even expect, you to be nervous. So in the initial stages of an interview, it’s good just to talk about general, background things. This is the time for small talk – how did the candidate get to you? If they’re new to the area, do they have any questions or observations about it? How long have they been in their current/last position, and what sort of things did they enjoy there? Do they have any favourite bloggers? Do they have any personal projects they work on out of hours? Hopefully a 5-10 minute chat should settle them down and clear their mind a little. And do, of course, offer them a drink – the talking is just getting started!

What knowledge does the candidate have?

This is where we need to get a clearer idea of who the candidate is, and what their strengths are. Their CV is likely to be an optimistic take on things, to put it mildly. Unfortunately, CVs go through bullet point filters at the recruiter level, HR level, and so on. If the requisite bullet points aren’t there, the candidate won’t get through to see the person they think they can impress. So be prepared for some skill inflation, and be ready to call them on it to find out their real level.

There are already some good articles describing some good .NET interview questions (though I hope to one day pen my own) so I won’t revisit that now. But you should try and go into some detail to work out what aspects of the candidate’s skills are strong and correlate with the role being recruited for. However, it’s easy to overlook the fact that the candidate may have some skills that, although not directly applicable to the role, may well demonstrate a more interesting character. So try and discover as much about their competencies as possible.

The challenge stage

I think it’s particularly important that the candidate demonstrate their stated familiarity with the products they’ll be working with. In our case, that’s first and foremost Visual Studio. Like it or loathe it, if you’re a .NET dev, you’ll probably spend a lot of your time working in this environment. So I’ll expect that you’re super-familiar with its usage. In the recent round of interviews we did, we asked people to put together a very small “todo list” webapp to demonstrate their ability to use the tools and the stack (ASP.NET, webforms or MVC). The spec was given to the candidate as a screenshot (on paper!), and we gave them a little time to put it together in front of us.

It’s hard to underestimate the value of watching someone code in front of you. You can immediately form an opinion on them in subtle ways that a verbal interview won’t ever reveal. For example, if someone cannot touch type, I would say that was a concerning trait. If they spend a lot of time poking around in intellisense looking for simple elements of the framework (e.g. the .Length property of an array), then you start to worry about their competence. And if they’re spend a lot of time hitting GUI elements in Visual Studio without ever using keyboard shortcuts, I’ll worry that they are slower developers.

Sure, demonstrating familiarity on strange equipment in an interview environment is tough – horribly tough – and I wouldn’t relish the challenge myself. Some people may normally remap their shortcuts; use ReSharper, or alter their colour scheme - crutches without which they may feel inhibited. But nevertheless, it’s an egalitarian method of assessing someone that no amount of talking can match, and I think it deserves a high place in a technical interview.

The freestyle stage

Here’s where it gets interesting. It’s well know that some larger tech companies try to only recruit superstars by asking them bizarre interview questions. How would you weigh a Boeing 747, without using a scale? How many golf balls would fit in your house? These sort of questions are an amusing novelty, and allow the interviewer to have a smug feeling of superiority as the candidate sweats out an answer. But I don’t feel that they’re pragmatic, especially when they can be simply replaced with more valuable and interesting questions.

Instead, ask open questions that the candidate can work with. Here are some suggestions:

• You’re handed over a legacy web site to maintain. Users are complaining that it’s running slowly, and pages take ages to get served. Where and how do you start troubleshooting? Which tools would you use to debug the database/code/front end scripts? What are the most common causes of slowdown and how would you identify them?
• How would you design an account authentication web service to handle logins for multiple websites? What would you change in your design, if you knew it needed to handle 3 million logins a day? What level of auditing would you provide for failed/successful logins?
• Show me a website you like, and describe something you can see that needs a technical overhaul. How would you do it? How do you think they’re doing it at the moment?

The wrap

Hopefully at this stage you’ll have formed an opinion about the candidate. But there’s a good chance that they may not have formed an opinion about you, or the company. So it’s now your turn to answer the candidate’s questions, and you should invite them to ask.

However, this is not an excuse just so sit back and reel off corporate information. The questions the candidate ask may well reveal more about them. If they simply ask rote questions (perhaps about salary, benefits, working hours, etc) then that’s rather dull. But perhaps they want to know about the products you’re working on, and the team structure? Maybe they want to know what the team culture is like? These are indicative of a more interesting character and you should pay attention!

And that’s all folks

Hopefully you know all you need to know, now. You’ve assessed them technically, practically, and culturally – you should be fully equipped to make a decision. Good luck!

The .NET framework library is a fairly pleasant place to work. A well documented, rationally structured, and easy to navigate API that always seems to have the right thing when I need it. Culturally sensitive pluralization? Yep. Image rotation? Yep. Oh, you wanted to create your own LINQ provider? OK then. Happy days.

Sometimes, though, you come across little oddities that make you groan.

Consider the following – you want to load all files in a directory that end in .doc (typically Microsoft Word files). Should be easy, right? Let’s fire up LINQPad and find out:

Well, that doesn’t look correct at all? I asked for .doc files, but got two more files as well. I guess it’s just expanding my search then, and using an implicit wildcard at the end? If so, I should be able to prove this by searching for .docx files, and only get two files back now.

Wait, what? The .docxx file that came back in the first results, has now not been returned. What could be going on? Well, as a matter of fact, here’s a little clue which might resonate with slightly older readers (if indeed, the post title has not yet given it away):

The clue is, of course, in the MSDN documentation for the method call. The method checks both file names – the current, modern one, and the legacy one that is maintained for backwards compatibility with 16 bit programs, written for Windows 3 or DOS. What a fantastic boon for those continuing to use older apps; and what a curse for the rest of us!

Then again, you can upgrade Windows 1 to Windows 7…

Does your web application allow the user to upload anything? This is one of the most terrifying parts of secure web development. You’ve made a decision to permit users to upload files. Perhaps they’re image avatars? CSV lists for you to import? Whatever they are, you’re going to need to become extremely paranoid, very quickly.

Don’t trust the file name

Surely you can just grab the filename, combine it with your “user uploads” folder, and all will be well? Absolutely not! Consider the following piece of code:

string saveAs = Path.Combine(userUploads, postedFile.FileName);
File.WriteAllBytes(
    saveAs,
    new BinaryReader(postedFile.InputStream)
        .ReadBytes(postedFile.ContentLength));

In most situations, this code will run well. Files will upload correctly into the user uploads folder, and things will tick over nicely. But the subtle problem here is that the FileName property is whatever the user’s browser specifies. In most modern browsers, it is purely the filename. For example, “me standing on beach.jpg”. But for some older browsers, it’s the fully qualified filename. For example, “c:\documents\me standing on beach.jpg”. So the code above can write into folders other than the user uploads folder.

At the very least, use Path.GetFileName to remove any possibility of a path being present in the name. Better yet, generate filenames yourself.

Don’t trust the filetype

This one’s easy, but embarassingly easy to overlook. Only allow users to upload files that end in the extension you’re expecting. If you’re only allowing images, then deny any upload that doesn’t end in “.jpg”, “.jpeg”, “.gif”, etc. Importantly, block the upload BEFORE you write any bytes to disk anywhere

Don’t trust the content

A more complicated problem is that of the actual content being uploaded. This is more of a problem that varies by context, so I can only give high level pointers. But essentially, you need to try and filter out content that is unexpected or invalid for the situation. An example would be a user trying to upload an avatar image that was 100mb, or a text file that contained binary data. You should always be thinking of what type of data you are expecting, and blocking or quarantining anything that is not right.

LINQ, a data querying feature in the .NET framework, was an absolute godsend when it arrived with .NET 3.5 a few years ago. Gone were the endless helper methods designed to manipulate or pick out bits of data from collections. In their place, an intuitive querying syntax – supported either via chaining extension methods, or by using new language constructs which provided SQL-like queries in code.

There’s been a lot of confusion about LINQ since its launch. You could argue that Microsoft didn’t help its cause by closely associating LINQ and LINQ-to-SQL. But it has been some years now, and it is quite concerning that when mentioning LINQ, most developers seem only to be aware of the database querying side of things (the confusion now lives on with LINQ-to-Entities). If only they knew the extraordinary flexibility that arbitrary query trees gave them! The provider model, coupled with deferred execution, is a truly wonderful thing.

It’s also a shame that query syntax is the way that most people seem to choose to write a LINQ query. Redmond says that query syntax is the preferred option, and they should know best, right?

In general, we recommend query syntax because it is usually simpler and more readable; however there is no semantic difference between method syntax and query syntax

But they immediately shoot themselves in the foot with the very next sentence (emphasis is mine):

…some queries, such as those that retrieve the number of elements that match a specified condition, or that retrieve the element that has the maximum value in a source sequence, can only be expressed as method calls.

So they’ve implemented some admittedly pretty syntactic sugar, but not managed to extend it to cover some common and useful parts of the new API? Frustrating!

Given the current, justified popularity, not to mention the inherent readability of, fluent interfaces, I think coding standards should prefer method syntax on these grounds alone. The only impediment I felt, when pushing myself into method syntax exclusively, was that set joining operations are less intuitive in method syntax than query syntax, for those who first learnt set joining from SQL. But I think this isn’t a good enough justification.

Method syntax for me.

Everyone starts somewhere. I started with Mallard BASIC, a very simple variant of the language. In fact, the variant was so simple that it didn’t even include a language primitive for clearing the screen (almost universally CLS in other dialects). I had to resort to bizarre escape codes. There’s probably a good CP/M reason for this, but the upshot was that typing in listings from BASIC magazines was almost always a fruitless endeavour as the subtle incompatibilities defeated my young brain.

Pressing the fast-forward button, I then began tinkering with QBASIC, and even Visual Basic for DOS which came complete with an ASCII forms designer (think a visual designer for an Ncurses UI). Those are not days to look back on with pride necessarily, but the simplicity of the tools really kept me interested in programming. It was easy to do colourful and fun things, and I didn’t have to worry about anything “difficult”. I would look longingly at various beautiful specimens from the demoscene, but I dismissed them as something well beyond my ability.

A brief flirtation with Tcl, and then some dithering around with Java preceded my eventual emergence as a .NET developer who has begun to deal with the “difficult” things. But even as this emergence boosted my confidence, it also became apparent that the childish fantasy of one day reaching the apogee of competence was an illusion. Developers are living their careers on a set of Penrose Steps. The climb is never-ending, as we constantly seek to increase our understanding of the tools we use, all the while trying to sup from the fire hose of new ones, both good and bad.

This isn’t a bad thing. Good developers live for the challenge, and that is what they get. The technical world is racing ahead, and staying in the race is rewarding on so many levels. It can be daunting, but once you take into account the fact that it’s a journey you’re on, rather than a destination to be reached, it begins to make sense. Some developers make a choice, actively or passively, to settle on a particular stair and eke out a standardized and uninnovative living. That is of course their prerogative, but it is an alienating and depressing idea to me!

I shall try to use this blog to illustrate some attributes that define a climber and not a settler, and perhaps provide a little motivation for those who feel they are inadvertently stagnating.

And so it begins. After too many years to count, I have finally got on board with an actual blogging platform. It seems strange to me that having been an early adopter of all sorts of things over the years, I’ve never seen fit to have a blog. But there you are.