Codebureau - Matt Simner

Had some security training yesterday (don't normally get training as a contractor so I was very happy to go along). 

The trainer mentioned the Developer Highway Code from Microsoft (seemingly originating from the UK based on the style of the publication).  Not only does it look cool, and have some rather amusing geek stuff (just see the 'Reduce Coffee Now' sign on the cover), it also has some really practical advice for people wanting to build secure applications.

Download it from Microsoft

I love that Scott Hanselman challenges his own as well as others' thoughts on how to solve technical problems.

I'm not making any judgements about junior devs vs. senior devs. I'm talking about idioms and "vocab." I think that using only if, for and switch is the Computer Programmer equivalent of using "like" in every sentence. Like, you know, like, he was all, like, whatever, and I was like, dude, and he was, like, ewh, and I was like meh, you know?

There's some good examples on forcing yourself to learn new objects, features and constructs through refactoring.  If you don't refactor then you'll never know...

I don't have the time, inclination or grunty machines to play around with Virtual machines just so I can test a website in IE6 (after IE7 'magically' appeared).  When I say 'test', I actually mean hack an IE-specific CSS together with some box-model workarounds.  I digress...

Enter Multiple_IE.  It's not perfect (it's a hack in itself), but it suffices in most cases so kudos for that...  You even get the nostalgia of IE3

I'd totally forgotten about this - don't want to lose it...

http://www.jonathancoulton.com/2006/04/14/thing-a-week-29-code-monkey/

I downloaded the Patterns and Practices 'Guidance Explorer' a year or more ago, and quite liked the idea.  I think the problem with any tool that tried to be a flexible storage and delivery method for 'organic' content (I'm interested in using it for development processes/standards etc) is viewed and searched by different people in completely different ways. 

Some like to dip into 'reference' material, some always 'search', and some people like to print everything and read cover to cover.  I know there've been some updates to the tool, and although the download count is still pretty low (3000 ish) I'll give it another go and see if it works for me.

Other people just throw this stuff into docs and put it on SharePoint.  Others use something like WikidPad - which again I liked but ultimately got out of the habit of using - meaning it obviously didn't work for me. 

Update

I just noticed that there's no possible way of printing from Guidance Explorer, and so while I can understand the reasons why it isn't implemented (to try and encourage people to write screen-consumable, concise content), it simply won't work for the users I'm looking to target.  Shame :-(

Brad A's just been highlighting the MSDN Survey to get opinions on how Visual Studio and MSDN documentation works (or doesn't) for people.  I added my 2c and it made me think a little about how I access 'help' these days.  Here's what I wrote in the 'other comments' (Q 14 I think).

I generally access MSDN content through google (as it's quicker than accessing the MSDN site, waiting for it to load the TOC, then searching).  It's probably testament to the indexing of the site that a search such as "msdn Path.Combine" will take me straight to the specific page I 'know' I'm looking for.  I guess this means I've got some knowledge of how things are structured and I use that to good effect.  In a simple comparison...

Local Help
Typing Path.Combine into VS.NET code editor - selecting the text and hitting F1 came up with a false start (my current machine doesn't even have the docs installed apart from Enterprise Library 3.1.  It did find some less than useful reference from EntLib!).  I went to Help options and chose 'use online first', and tried again (incidentally I didn't even realise you could pull in your own list of sites to search (Codezone community) - cool).  It chose a different 'Path property' first and took about a minute in total to get to the right 'Path class'.

MSDN Library Site
Opening up the MSDN site (which still feels too heavy in my book - and now curiously like BBC news) and searching for 'Path.Combine' took about the same time (1 min).  This includes opening the browser, loading up the MSDN home page, searching, clicking the first item in the search results, and loading that page.

Google search on MSDN
Opening up Google (admittedly my home page - but I'm looking for speed here) and searching for 'msdn Path.Combine' took 20 seconds.  The first item in the list was what I wanted so got straight to it.  It's also worth noting that Google's become a little fat puppy too with all my iGoogle stuff on it, but it's still way quicker than any of the alternatives.

Well you may think it's just a matter of rendering some well-formed markup and setting your doctype...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

right?  Wrong!

Different browsers render in different ways.  What's common however is that unless your response's content type is "application/xhtml+xml" then you may not pass go and pick up $200.  You can force the browser to recognise the content type in two ways (in addition to the DOCTYPE declaration above):

1. Name your file with an .xhtml extension (not really a solution as IE says 'what?')
2. Set Response.ContentType = "application/xhtml+xml" (See here for more info)

The DOCTYPE is really an additional information item and not something modern browsers do much with on its own.  So how different are the browsers'  XHTML implementations?

Internet Explorer for instance takes the 'all comers' approach and will do the best it can given the markup, whilst degrading gracefully if it encounters errors.  great! I hear you say - saves me from actually testing this thing!

Firefox on the other hand will use a completely different parser once it knows you want to serve well-formed markup.  The good thing about this is that you immediately see any errors and the page won't render if there's invalid markup.  IE meanwhile continues to let you believe you're an XHTML master (note: it doesn't recognise the xhtml extension).

Firefox has some good resources about supported features.  A common one that catches people out is Javascript's document.write.  This isn't allowed in XHTML as the string input can't be guaranteed to be valid XML. 

Safari's not quite as advanced yet as Firefox's support, but it too will properly validate your markup and report errors.

If you really want to stick your neck out then place a link on your site to validate against the W3C's standards.  You're likely to get plenty of errors - like this page!

Other things to watch out for are Content Management systems that allow you to enter non-compliant html in text editors, and simply not having JavaScript blocks in CDATA sections).

Yes - I couldn't be bothered to read through the Microsoft docs on this, so got what I needed from here.