If you want to build the kind of science fiction, futuristic GUIs that only exist in TV and movies (think: Minority Report) then you want to be looking at Windows Presentation Foundation (WPF).

WPF is Microsoft’s next generation API for developing applications and it’s possibilities really start to shine through when you look at Microsoft Surface, which was developed entirely with WPF and the .NET Framework.

The idea behind Surface is that any surface – vertical or horizontal – can be made so that you can interact with it in a very direct and natural way.

"We used to say a computer on every desktop and now we say every desktop will be a computer" — Bill Gates

This notion of interfacing with a computer through touch and gestures rather than mice and keyboards is all part of the next generation of user interfaces – termed "Natural User Interfaces" or NUIs for short (pronounced New-eee, like GUI with an "N"). The idea is that we began with Command Line Interfaces (okay, we began with blinkin’ lights, toggle switches, and punch cards – but…), progressed to Graphical User Interfaces, and we are now entering the next stage of this evolution.

"The last 30 years of computing have been about people learning the language of computers. The next 30 years are going to be about computers learning the language of people."
– Daniel Makoski, Interaction Design Manager, Microsoft Surface

Read More…..

Bob Martin’s Clean Code: A Handbook of Agile Software Craftsmanship is finally out and the UPS man just dropped a shiny new copy on my doorstep. It kicks off with these fine words of wisdom:

"The only valid measurement of code quality: WTFs/minute"

Thought I’d take you with me on my quick skim in case your UPS man wasn’t as nice…

Chapter 1 begins with "You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers." Includes sections like The Total Cost of Owning a Mess.

The Functions chapter earns bonus points for its opening image of the hookah-smoking caterpillar from Alice in Wonderland. I’m not quite sure what Uncle Bob is suggesting here, but this chapter includes goodness to the likes of Have no side effects, Prefer exceptions to returning error codes, and classic Uncle Bobness such as:

"Functions should do one thing. They should do it well. They should do it only."

The Formatting chapter explains how to avoid "a scrambled mass of code that looks like it was written by a bevy of drunken sailors" (hmm, I think I’ve seen that code before). And the Objects and Data Structures chapter (which starts with an image of Data from Star Trek – I swear I couldn’t make this stuff up) has some interesting looking sections like Data/object anti-symmetry, The law of Demeter, and Train wrecks.

Read More…..

As the unit testing debates continue on my project, I can’t help but noticing that people are spending all sorts of time pontificating over the right way to unit test, without stepping back to consider what they’re trying to achieve with unit testing. And because they don’t know where they’re going, they’re not able to reach any conclusions on how to get there. Sound familiar?

There are actually a number of fabulous reasons for doing unit testing:

1. They help us think about our design in a way that we might not otherwise.
2. They lead to cleaner code because it’s often easier to re-factor our code to be more testable then it is to write unit tests that exercise obfuscated or otherwise hard to access code.
3. They validate that our modules are behaving correctly.
4. They provide a safety net to ensure our existing modules continue to function properly as our application evolves.

These aren’t all intuitive and so a lot of people will only consider #3 when they think about unit testing. And yet, what’s interesting is that #3 typically provides the smallest return on our unit testing investment because we tend to find WAY more defects through #1 and #2 as we work out how to develop our tests, and then of course in #4 as we continue to change our code over the application’s lifetime. And, unfortunately, by focusing only on #3, it can lead us to make some faulty decisions when we try to reason about the best way to do unit tests.

Read More…..

There is a hot debate on my project about whether or not our JUnit tests are pure unit tests. What the heck does that mean, pure unit tests? Our tests are JUnit tests. Doesn’t that, by definition, make them unit tests?

Actually, no. Unit testing does actually refer to a very specific type of test – one whose sole purpose in life is to:

In other words, a unit test should only test an individual unit (a class or a method). If executing a test crosses that class’s boundaries to say, access the database or call a method in another class, you’re no longer doing unit testing, you’re doing integration testing.

Okay, that’s really nice and now I can feel like a big, important software engineer for knowing the true definition of unit test. But, why do I care?

Read More…..