Last talk of the last day at Øredev 2009. I listened to "What not to test" by Robert Sabourin. 

I like testing because I am fortunate enough to belong to a school of programming that wants to do things the right way. So naturally I was intrigued by the theme of the talk. Isn't testing Always Good?

After listening to the talk I still believe this to be the case. However, there might be situations in your career when this will be unfeasible for some reason or another. In this situation knowing what not to test is far superior to skipping a test you didn't know you had to do!

Knowing what not to test comes from knowing as much as possible about what to do test. To this end, Robert advocates continuously collecting testing ideas - on all levels possible. Study how to attack systems and get ideas for testing. Study how your application will be used by users (as opposed to knowing just what the application does for the users). Study specifications and try turning them upside down for alternative usage scenarios that you might have be unaware of.

Look at performance, capabilities, environments, failure models. Become aware of stress levels and state changes.

And so on judgment day you and your application will not be unprepared.

This concludes the blogging from Øredev sessions. Now, with all the great ideas, knowledge, and inspiration, there's only one thing left to do; become a better developer!

Good luck and see you next year.

Was hanging out at the gourmet coffee bar on the side of the exhibition floor.  For the past three years Øredev has asked Johan & Nystrom to set up shop here for everyone to enjoy (what? developers like coffee?). The guy behind the bar is Mattias Sjöbäck, the Manager for Southern Sweden for Johan & Nystrom – a rather special kind of coffee company.  And their elixir, served by heroes of the craft (yes, only an artist can foam like that) is incredibly delicious.  I was walking around like an idiot saying “I think this is the best I’ve ever had.  I think this is the best I ever had.” 

The company is a specialty roasterie (sp?) that actually goes and visits each of the farms from which they purchase.  They do this for quality assurance, but also to make sure the farm is operated in a socially responsible manner.  That way they can deal directly with the farm allowing it receive an even better deal than certified fair trade. 

But I think that’s not the best thing that is making a stop at the Øredev branch of Johan & Nystrom cool:  Mattias and his partners consider themselves coffee geeks analogous to the techie geeks gathered at Øredev.  Of course they don’t know what any of the tech talk is about so the conversations that happen while they make your cappuccino slide over to the more personal.  It’s a spot in the Øredev mix of talking, listening, sharing, where we’re just plain hanging out with new people – over the best coffee you’ve ever had.

Is Behavior-Driven Development just syntactic sugar for integration testing? That's the question I have been asking more than once recently. There's RSpec, and there's Cucumber - if you are a Ruby developer you'd have heard about those. But why should you do BDD? Because BDD tests cover something Unit Tests don't? That's not the case - in terms of code coverage, BDD doesn't add anything.

(Take a Rails application for example. You can test model integrity with unit tests; application logic with functional tests; and user-app interaction flow with integration tests. That's complete coverage).

Having these doubts about BDD I was eager to sit in on the Cucumber session with Aslak Hellesöy. Things were a bit more involved than I thought. Firstly, it became obvious that Cucumber (or Gharkin, the DSL that powers it) parses human-readable text into strings into which regular expressions can be inserted at runtime.

(Ample amounts of human-readable text is what flashes in the eye when first viewing BDD code. It's easy to think of BDD as something only non-techies can read, but there's more to the picture).

Another interesting detail is that Cucumber follows a well-defined convention for testing. You are Given something, and When you do something else Then something third happens. That's a nice coupling of syntax and semantics. Function follows form. Otherwise it'd be easy to get an impression that nearly everything goes into a Cucumber test spec.

Upon asking Aslak what exactly is Cucumber for: is it mainly for stakeholder - developer communication or is it a superior testing tool aimed at the developer, I received the following answer:

"Cucumber is a stakeholder-team communication tool designed to add more value to the client, however it is also a good developer tool that is capable of providing project documentation at all stages of development: before-coding, during-coding, and after-coding".

A good and exhaustive answer. Now, is Cucumber for you?

Friday, 6th of November 2009 at Øredev. The time had come to sit in on the one of the main attractions of the conference. A talk by the man to whom many of us developers owe their career. (If you have worked with Object Orientation and Model-View-Controller you belong in that category).

Trygve Reenskaug made a monumental talk about rethinking the foundations of Object-Oriented development that spanned the three "ages" of programming: its genesis, the difficult maturing stage, and the recent breakthrough at a higher level.

The first part, "Procedure Orientation: Success" detailed the dawn of programming discipline where chunking code for readability and testability were good practices. Developers used to review each others' code to find bugs; failing early was considered good. If this sounds like something you've heard before, you're right. Procedural programmers of the day were Agile by default. They found what worked and stuck to it.

The next stage ("Class Orientation: Collapse") was more complicated. By that time, it was decided that a program should model the real world by mirroring its objects. Accounts, Users, and Money were represented in classes that at runtime had certain behavior, roles, and responsibilities. This was a major cognitive breakthrough for developers, however it also resulted in a dangerous chasm. To stakeholders, the program was a dynamic system with a certain behavior. The implementors had to deal with a different picture: all this behavior had to be represented using primitives that were static in nature: classes, attributes, objects. Stakeholder - developer communication became complicated.

Enter the last stage ("True OO: a new beginning"); the revival of "true" Object-Oriented development. Now, we are back at what objects were SUPPOSED to do in the first place. An object is something that plays a role. And a role exists in a certain context. (Like acts in a theater play are contexts for roles?) That is crucial. Without context, everything is static. Add context, and everything comes alive; roles can be injected into objects at runtime (context is dynamic!). By now you're probably wondering what exactly these roles are - how do you code them?? While getting into the gory details seems to be overkill for this blog (and would do no justice to Trygve's talk), consider this: roles are something that can have methods!!

With this renaissance of Object Orientation, best practices suddenly shine again. Peer code reviews become meaningful, because now you'll be reviewing both the class AND its context! This is responsibility-driven design.

This has no doubt been of the most memorable sessions of Øredev. I'm glad I attended it  - otherwise I would have missed something that is crucial to the programming discipline and where it is going today.

Scott Handelsman led the day off today with a keynote that followed right along with the take-aways from Marc Lesser.  Going from taking the time to ask the important questions about what we want to avoid in life, and how to get more done by doing less, Scott started with that premise and offered everyday examples of what we can do about it.  He got us applying the lessons learned right down to how you manage your email account. 

Do it - Drop it - Delegate it - Defer it, man. Divest your psychic weight, dude

For a conference with efficiency and effectiveness as a theme this talk hit the bull’s-eye.  Now maybe we can finally get some stuff done.

Oh man, Ze Frank rocked last night.  What a fun, hilarious expedition through some of the simplest elements - fear and love in this case – that we recognize in each other even across something as complex as, errrr, well, the interne! His “work” seems inspired from anywhere and everywhere, but it’s also always real, and a collaboration with whoever wants to jump in. That guy brings an invitation to play in the purest form - best of all it's creative, but also smart and inspiringly human.  An earth sandwich?  Sweeeeet! 

This day concluded with a special topic. Neal Ford gave a talk about being a productive programmer; something close to the heart of every programmer capable of reflection (pun intended).

Did you know that it is faster to type than navigate to files in directory trees using file browsers and finders? Yep, I'm talking about the power of the old UNIX command line. Neal's advice is: use an content indexer program to be able to navigate to any file, anywhere. Better still, build one (you're a hacker, right?). Here we have something essential:

When you 1) acknowledge a problem; 2) begin to treat it like a 1st-class problem, two thing happen. First, you begin building long-term assets out of throwaway scripts. Secondly, you end up with 1st-class tools!

(Just take the example of Neal's book, The Productive Programmer. Originally a collection of all-around scripting recipes, it developed into a book about productivity when Neal realized this "recipe list" wasn't something he himself would be interested in reading).

Automate tasks whenever possible and use version control. (Hint: Git is good). Start the day with 2 glasses of water (OK, this one is from me, not Neal).

Have a "focus strategy" when you can work uninterrupted for the time it takes to achieve flow with whatever you're working on. "Flow" is the state of complete immersion in the task, when the most challenging becomes most enjoyable. Don't interrupt this by checking email - you'll be wasting hours of productivity. Instead, allocate time to reading emails and do this in batches, as a 1st-class activity. So rather than disrupting the flow of work with email, read email during a certain time and achieve flow with that! What a nugget.

Fail fast, fail spectacularly. Fail with your computer exploding, if that's what it takes for you to come face to face with your problem. That way you'll improve sooner and more thoroughly.

And above all, don't shave yaks. You'll have to attend a talk by Neal Ford to find out what that means.

Sat in on the session Understanding the Origins of Destructive Leadership with Leo Kant this morning.  It was a good reminder that leading in your project or organization or wherever is more than just doing more of the good stuff – you really have to beware of the bad.  It seems one bad move can overwhelm many demonstrations of good leadership. Yes indeed, bad leadership leads a life of its own, it can co-exist with the good and still do its damage, because they are simply not on the same scale.

Leo called destructive leadership repeated bad behavior that violates the interest and objectives of the organization and/or the motivation, well-being or job satisfaction of subordinates. (major paraphrase)

He also noted that most leaders engage in both quite commonly.  So if you missed the session, check it out on video, or at least be aware that the research shows there’s more to being a good leader than just being a good leader.

All right, so this time I decided to venture into uncharted territory: mobile development (and I'm no ace at JavaScript, either). Nevertheless I chose to attended Nicolai Onken's "Creating cross-platform mobile applications with the Dojo Toolkit". I had a feeling that mobile development is both different and familiar (the mobile platform is a new kid on the block - but hasn't JavaScript been around since1995?)

Many interesting insights were gleaned from this presentation. Firstly, it turns out that mobile and web development really aren't that different. (Yes, there are differences in screen sizes and hardware capacity). And secondly: much of what applies to good practices in web development transfers to mobile development (I consider this another case for the web as platform, described earlier in this blog). Judge for yourself:

Are you using the Web Standards trio (XHTML, CSS, JavaScript) to create prototypes for web applications? Well, you can create a perfect mobile app using the very same methodology, as exemplified by EventNinja.

Are you following Steve Souder's advice and minify JavaScript to improve performance? This is something you will be doing (religiously) when developing mobile apps.

(You might, however, find that writing inline CSS improves performance. This flies in the face of good web practice, but consider that for the mobile platform craves every little performance tweak available. As Nikolai said, "Do what your runtime can do and not more". This means, among other things, no rounded-corner effects using a "div" per shaved-off pixel of a rounded corner ;-).

Have you used JSON in a web app? As Nikolai believes, JSON (!=XML) is the format for mobile development.

In fact, mobile development being the sandbox for cutting-edge tricks now begins to influence web applications and browsers - things are turning around. So much so that geolocation, which has probably been among the top mobile apps, is finding its way into the web browser (Firefox is doing it already).

And, it may surprise many developers that CSS 3 is available on many mobile devices! So, if you have been tinkering with a cutting-edge mobile app utilizing CSS 3 it may be pushing the technology's adoption for web applications, some way down the line in the future.

The mobile web is here, and it's both same and different.

Sure the food is good, but you can’t help but notice the difference in what you’re eatin’ ON and WITH. I asked around: there was an explicit choice for Øredev to purchase eating utensils and plates that are compostable and made from renewable resources. They’re actually wood and fallen leaves (so non-harvested – you just collect them) Even the plastic glasses are made from corn.  We go through a lot of these materials during the conference.  We’re going through a lot of food and coffee too – fortunately it’s ecological, fair-trade coffee and food that is as locally produced as possible.  

So bon apetit, my low impact friends.