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.

Currently a roundtable discussion on everyone’s current projects (check this out.), next projects (is there overlap?), and the future of the biz (Oracle wants to buy Sun?). We've got choices of language (of course), should you jailbreak your iphone? (wait, is that cheating or just good sense?), and which other speaker session are you headed to next?

I've always thought that microformats are intriguing. They're not an official specification; they add nothing to the existing web standards stack that already isn't there; and they seem to be one of those rare "bottom-up" innovations that become a part of our toolbox solely through an organically increasing user base. They were the topic of a talk by Karsten Januszewski from Microsoft research.

Microformats solve a simple problems really well, and that is perhaps the secret to their increasing popularity: they add meaning to web pages through conventions for XHTML attribute elements (notably the "class" element). This meaning can then be extracted from the markup by software and "sliced and diced" for further effect.

Microformats are both "extensible" and "not". Extensible because it is relatively easy to propose a new microformat (the microformats wiki hosts both the list of ratified microformats and current proposals). Not extensible because once a new format is accepted, one cannot use it to define one's own specialized or fine-grained version of it. In other words, "subclassing" a microformat is impossible.

It's interesting how the microformat movement is going to deal with its challenges. According to Karsten, these are:

• Meaningless microformats (isn't that easy? Don't ratify them).
• Browser support (this one has never been easy, I guess).
• Search engine support (in spite of half a billion microformatted pages, SEs haven't been quick in processing them. I find this a bit paradoxical. Are microformats too "primitive" for SEs? Sometimes, a thing can be good even if doesn't require intricate algorithmics).
• Tooling issues (before long, some open source IDE will start supporting microformat development. Who's first?)

All in all, a nice talk about about an interesting topic. Microformats are a part of the next web. To what extent will become more clear in the coming years. Much lies in our hands as developers. Microformat development, anyone?

Being a web nut, I planned for "The Future of Web Applications" by Ben Galbraith and Dion Almaer. The web as platform is a compelling case - at least in my view. (Software is moving to the web to a large degree, even applications traditionally viewed as desktop applications. Because web-based software per definition is directed at the broadest user base possible, it must be better than desktop software in every way: faster, simpler, more usable, sexier, and more functional).

It was exciting to see the presenters outline the many factors contributing to the web as platform. First, as Dion stressed, there's the browser runtime. Recent improvements in JavaScript virtual machines make it run exponentially faster than before! This makes possible some crazy real-time, computationally heavy JavaScript programs.

Then there's the "web in everywhere". What is the next stage of web evolution? Interestingly, it is ceasing to be "web only" - breaking out of the traditional sandbox. The web on the desktop and the web on devices (or is it devices on the web?) - how about that? Personally, I think this is both logical and desirable. Logical because the web can theoretically "be" on every device that is capable of connecting to it. Desirable because a standardized platform is a good platform. So I know which platform I'd rather develop for!

Kudos to Palm for being the 1st mobile company to embrace web as platform. (As Ben mentioned it they are unlikely to remain the only one).

Text, box, image - these largely remain were the primitives of web development. Therefore it's amazing to see how sophisticated things can get with only these basic concepts.
 
What an evolution the web has undergone. Not long ago developers needed to create pages for 2-3 different browsers, each with multiple versions. Now, with each year, there appear numerous tools for development, testing, profiling, and just experimenting with the latest technologies, which are both standardized and cutting-edge. The presentation was just a glimpse of what will be; it made abundantly clear, however, that we have come a long way since the blink tag.