All Posts From : November 2011

Just a quick one about one of my pet annoyances. It doesn't happen to me that much since I went freelance, but I still do get asked these occasionally when places are chatting to me about doing work for them.

I hate it when I'm being interviewed for a tech job and someone asks you one of those stupid logic puzzles. They don't really do anything other than see whether you're any good at logic puzzles or not, and most of them are so abstract as to be pointless. You know the kind of thing, "You have a herd of Elephants, some Snakes and a Bee. How do you weigh the Elephants?".

You're interviewing me for a programming job, not a job writing cryptic teasers for the local paper! By all means ask me something programming/code related, like "you have a design with rounded corners and drop shadows and you need the resulting pages to work in IE6, what techniques would you use in the HTML/CSS?", or "you have a website that's using a high amount of RAM and CPU, how would you troubleshoot the problem?". Those are relevant, and allow me to demonstrate my problem solving skills, AND my knowledge of a relevant subject.

This whole post came up after a very amusing chat with some devs at a clients' office recently, and one of the guys was once asked something like:

"You meet a guy in Japan at a business meeting and you get his number, but not his name. You have the phone-book for the city, how do you find out his name?".

Well, for a start, the person setting the question has clearly never done business in Japan. The chances of you getting just a number from a businessman, rather than a full on business card with all the ceremony that it entails are pretty slim. Apparently "looking the number up on the internet" wasn't and acceptable answer (why not I don't know, it'd probably be the quickest way to do it), phoning up directory enquiries wasn't allowed either. He never did get told the "correct" answer in the end by the interviewer, but this sort of question entirely illustrates my point. It's not a very realistic question, and they don't want a practical answer, they want something clever and convoluted. I don't know about you lot, but back when I did the hiring, I wanted people who could demonstrate practical problem solving skills, not someone who can come up with something clever involving six weasels, an elk and a bag of porridge.

I'd be interested to hear if anyone else has had any particularly dumb/pointless interview brainteasers!

:)

I've been working with Umbraco for a while now, and I've done a fair bit of work that's involved creating some quite complex extensions for the Umbraco back office, from DataTypes, through to whole new sections.

I've learnt a lot as I've gone along, and thought I'd share some of the tips for writing extensions for Umbraco! Hopefully some of these will help others avoid some of the mistakes I've made, or save them hours of research.

1. Don't Customize the Core Unless You Have To

Only modify the core if you absolutely have to. Early on I extended Umbraco by modifying the core code itself rather than using the event models etc. This was great, until I had to perform an upgrade. At which point I had to re-apply my updates to the new source, rebuild and re-test. Ouch.

Using the event models and the API, you can code extensions that are easy to re-use and that should carry on working, even after an Umbraco upgrade!

2. When Coding Datatypes, Don't Rely on the HttpContext

DataTypes can be called by events that don't have an HttpContext, like the timed publisher. In these cases they'll throw a null reference error, as the HttpContext is not available. Use non context versions of functions wherever possible!

3. When Coding Publish Event Handlers, Don't Rely on the HttpContext

Publish events can occur outside of the HttpContext. If your publish event handler relies on the HttpContext, it will fail when you try and use the timed publish feature of Umbraco. The biggest culprit I've seen for this is using HttpContext.Current.Server.MapPath, which will be null when called through the timed publisher.

You can map the path using HostingEnvironment.MapPath instead. For other code that relies on HttpContext, put in null checks and default values in case there is no HttpContext, and your handlers should work on normal and timed publish!

4. When Creating New CMS Pages, Inherit From UmbracoEnsuredPage

If you're creating new pages for the back office, you want to make sure that those pages are only visisble to users who have logged in through the CMS. The easiest way to do this, is to make sure that your pages inherit from umbraco.BasePages.UmbracoEnsuredPage instead of the usual System.Web.UI.Page.

This will make your page unavailable to non-logged in users, and will also enable you to hook into your page using the Umbraco event model!

5. Don't Be Afraid To Grub Through Code

One of the biggest ways I learnt was to grub through other people's code. Want to make CMS pages that look like the Umbraco ones, but not sure how to do it? Easy, grabthe source from codeplex and have a look at how it's done! Want to know how your favourite uComponents DataType works? Go look at the source and find out. The more you look, the more you'll learn about how the core works, and the ways that you can interact with it.

Hopefully (time permitting) I'm going to start a series of step by step tutorials on how to do some common stuff with the Umbraco Event models and API, concentrating particularly on the back office! Some of the things I'm hoping to cover are creating back office pages, using Umbraco UI elements, working with DataTypes, and using the event model to interact with the back office!