“When you make changes, many tests may break. Perhaps you change the name of a method that it invokes on its dependent object. Now you must go update all your dynamic mocks to change the name of the method.”

What? When was the last time that you changed the name of a method in more than one place? If you’ve been using Eclipse, Visual Studio, or basically any other IDE, it should be a long, long time ago. Are you coding in vi? If so… WHY? Do you shun the basic refactoring tools in your IDE… WHY?

Now, some technologies cripple the abilities of your IDE to treat code as code. For example, a mocking framework that requires you to enter method names as strings (which I think is what Josh was referring to). If you use one of these, your code is treated as text, which is a waste of the power you have on your desktop.

I strongly recommend avoiding frameworks which make you treat your code as merely text. Not only does this reduce the usefulness of your development environment, it can also introduce errors that the compiler cannot identify which in turn produces bugs which are harder to identify and fix.

It can be difficult to replace certain frameworks, but all modern programming languages have some form of reflection-enabled closure, delegate, anonymous method or lambda-expression which make it possible to make wrappers which actually use the classes and types in your own code. (Although such constructs can be very cumbersome… I’m looking at you, Java).

So, treat your code as code, and help your tools help you.

As a journeyman developer reads more and more about how to design good code, how to structure good code, how to recognize good code, etc. etc. the principles that he picks up move to the forefront of his mind when writing new code. This is not always a bad thing, but it is easy to get in to the trap of changing the design so many times before having a clear purpose for the code that a developer loses sight of the goal he is trying to achieve. Hours can be lost perfecting the design of code that, in the end, turns out to be unimportant or unnecessary.

So, I am advocating the creation of bad code. Wait… that doesn’t sound right!

That is right, but within constraints.  Pick up a copy of Clean Code, The Pragmatic Programmer or Working With Legacy Code. Hear that…? The background hum? Listen carefully… “Red, Green, Refactor, Red, Green, Refactor”. That’s the drumbeat of test driven development. The bad code only exists between the Red and Green beats. As soon as Green beat is sounded we move on to refactoring. Then you can get your rules, patterns and principles out and polish that code until it shines!

Remember, you can only get away with that sloppy code if you sound that last beat of the drum loud and clear – never neglect to refactor!

The book starts off with a few simple rules. On the surface, these seem to be dry and quite familiar territory to anyone who has much experience with developing software. “Variable names should be descriptive”, “Functions should have a single purpose” etc. But within this advice is a more sweeping message - carefully written code, like well made art, is something you can be proud of. My own viewpoint is shifting from one of merely producing deliverable (and maintainable) goods, to also encompass the construction of something which can be appreciated for its craftmanship.

“Uncle” Bob has, with a few simple rules, injected more fun into coding for me.

I now have a repository on GitHub for a simple form filling application making use of the local storage and offline application APIs. As of writing, I’m still feeling my way around this stuff, so the code isn’t really worth using in any other project, but I hope to clean it up over time.

HTML5 opens up many, many possibilities that were, until recently, the sole domain of installed applications. The future of the web is definitely getting more exciting.

“We have come to value … Customer collaboration over contract negotiation”

- The Agile Manifesto

Much has been written about Agile, Domain Driven Design and other modern software development methodologies. You can’t read very much of this without coming across a foundational common thread… user and customer involvement.

The more teaching on Agile that I read, the more I am convinced if you don’t have constant interaction with your users and customers, you are not doing Agile.

The specifics of implementing offline applications are well documented elsewhere. But what isn’t often mentioned is how to discover the required files for your application which should be listed in the cache manifest.

A little google/binging around finds a handful of attempts to make this easier, but I have stumbled upon a quick way to a kind of poor man’s dependency finding… Just fire up Fiddler when using the application and copy the file listing. This method is far from foolproof, but it beats tracking down each file by hand, especially when using add-ons like jQuery UI which pull in other external files.

Having read a little about Metro before, I found a lot of  the language to be very airy, arty and generally fluffy. The presentation made a lot of the fluff much more solid.

I’ll unpack a couple of the terms used in the Metro UI literature. Interestingly, these guidelines have more to do with what is left out of Metro apps than what is included.

‘Content, Not Chrome’

Every application that allows users to write, discuss, photo, video, chat etc. contains user content. This is nothing new. We are used to presenting users with windows, menus, scrollbars and all manner of widgets in order to view, organise and manipulate their stuff. The difference with the Metro guidelines design language is the idea of letting go of all these widgets and simply allowing  the content to be the interface.

‘Authentically Digital’

This is a term that really had me scratching my head when first reading it. ‘Authentic’ sounds like a term that a designer jeans company would use more often than a UI designer. It’s actually rather simple, but at the same time it’s a big departure from the way we’re used to designing traditional desktop applications.

Think about the word ‘desktop’ for a second. From the begginings of GUIs, we’ve attempted to draw analogies from the interface into the real world. Glancing at my virtual desktop here for a second, I see a ‘recycle bin’ that looks rather like a real, physical waste paper basket, a couple of sticky notes and an analog clock. All of them digital artefacts disguised to look like their physical equivalents.

Being ‘authentically digital’ simply means to abandon the attempt to make computers look and behave like other objects and let them be computers.

Bottom line

The Metro UI ‘design language’ has resulted in some really great looking apps so far, and will continue to do so. The advice given is more high level than most developers are used to, or will even be comfortable with. This is intentional. The broadest advice that Albert gave at the talk was also one that is very applicable to developers, designers and product managers: Pick a small set of principles and use them to answer the decisions and dilemmas that will inevitably appear. You can get much more milage from a rule such as ‘design should be clean and open’ than from ‘All second level headings should have a 20px upper margin’.

Because the concepts from Java, C#, etc. are close to the concepts in JavaScript, they give a developer a ‘leg up’ when starting to understand the language. However, relying on the understanding that comes from other languages prevents a developer from fully grasping the power of JavaScript. It is, after all, as much a functional language as it is object based. For example:

• Methods are somewhat like functions
• Scopes are somewhat like closures
• Classes are somewhat like prototypes

It’s just like learning a spoken language; If you want to speak fluently, you need to stop translating from your native tongue and learn to think in a new language.

To be more precise…
Developers who need to read this book:

• Anyone who has written basic JavaScript, but feels a little uncertainty about the phrases ‘closure’ or ‘prototype’
• Anyone who writes JavaScript, but relies on a third party library such as jQuery or MooTools

Developers who don’t need to read this book:

• Anyone who hasn’t developed a web / JS app (read something more introductory, then this book)
• Valerio Proietti

I’ve only covered about a third of what has so far been written (covering unit testing, functions, closures and prototypes). But… these fundamentals are of inestimable importance to a developer who has made do with applying knowledge from OO languages to JavaScript.

This was basically a quick run through of what’s available in the Windows API Code Pack, with some hints as to how (and when) to implement the new bells and whistles available in Windows 7.

Here’s what I took away from the talk:

• All the taskbar improvements (jump lists, overlays, progress bars…) are easy to use, but just provide eye-candy. I do think that the thumbnail buttons are pretty cool if you have a use for them, though.
• Restart and Recovery is nifty, and not only useful for program crashes. Having your app ‘come back from the dead’ on the morning after patch Tuesday is a great idea.
• The touch API is not so easy, but the Surface SDK is. Unless you’re interested in fine control over the intricacies of the touch API, pass over it and just use the tools provided for Microsoft Surface.
• There are ways of laying out an application that make life easier for touch users without specifically programming for touch. A nice observation.
• Liquid cooled computing can have disastrous results. Thanks for that, Richard.