Seeing as I am a Google fanboy, I’ve been waiting for this the second I heard it was happening.  The fact that they got Scott McCloud to create a 38 page comic detailing Chrome’s features adds bonus points!

From my perspective, the three most interesting features, in order of importance are;

• Separate threads for each tab/plugin/window.
• Javascript compiler
• Open source

In some ways, the prominence of Wikipedia has almost “sullied” the concept of a wiki. When someone says “wiki” it’s the first example that springs to mind, with all of the baggage that accompanies it. Some see Wikipedia as a resource of knowledge, others as a chaotic tangle of mis-truths and flame wars. Some of the fairly recent press on Wikipedia hasn’t helped this image.

This prejudice towards wikipedia spills out onto wiki’s in general, which has made selling the concept of a wiki to the corporate world something of a challenge.

Wiki’s allow communities of people to share knowledge and experience on relevant topics in a structured yet flexible manner.  In order to leverage the power of this collaborative resource, a level or order must be imposed on the evolution of a wiki.  Wikipedia benefits from a core group of dedicated administrators policing the site, re-writing, linking and trimming the articles entered from the collective conscious of the internet.  In a corporate environment where resources (people) are more limited in the time they can spend enforcing structure, sections of the wiki need to be organised in a consistent and logical manner.

Companies can greatly benefit from the wiki concepts.  Corporate Wiki’s can become vast stores of knowledge, all interlinked from article to article, allowing a user reading the policy regarding the Disaster Recovery policy immediate links to related pages on back-up procedures or fire regulations, etc.  Were these documents each stored in a static Word document, it would increase complexity.

When looking for advice on introducing a wiki into the business world, I trawled the web looking for some kind of “best practice” which would help me to define a structure and hierarchy which would encourage use and growth in a scalable and maintainable way.  The best resource I discovered in this capacity was WikiPatterns, an excellent resource of Patterns and Anti-Patterns, how you can get the best use out of them, or solve their issues as they arise.

I am currently working on a project to implement the Confluence wiki from Atlassian.  This is a Java based, fully supported enterprise level wiki.  In my own webspace, I plan to use MediaWiki, the open source wiki behind Wikipedia.

Recently I’ve been looking at escaping the standard “Waterfall” approach to projects and the development lifecycle. There are many reasons behind this shift, not just the “everyone works in an agile manner” thought, here is a small list;

• Client involvement and “buy in”.
• Easier incorporation of ideas and changes.
• Ability to change direction to meet the changing demands of the client.
• Reduction of risk.

I have had issue in the past of seeing the benefits of agile practices, mainly from reading and listening to preachers and evangelists giving sermons on agility from a highly theoretical, high level manner.  What I found lacking was an easy to understand, entry level discussion on what works, and what doesn’t.

Whilst at the qCon conference, I picked up a couple of books for free in print that InfoQ make available on their website.  One of these publications gave me that low level basic understanding and view of agile that I needed.

Scrum and XP from the Trenches

This book walks through the concepts of the Agile development methodologies from the perspective of a developer, the author Henrik Kniberg, has implemented many projects using the agile concepts, and through all the struggle and teething problems, has written his experience and approach down in an easy to understand way.  It is important to note that this isn’t a theoretical “how you should work” it’s his own experience of how they did work.

I have found it an invaluable resource and have encorporated many of it’s teachings into my current way of working.

That would probably explain the jump in spam

So now we have iTraffix - US, which also happens to be up on Apple’s website too!

Its very simple, just using the iui javascript, all it does is go and grab the XML traffic feeds from the highways agency and allow you to read through it by region and road.

You can check it out at http://smileham.com/itraffix

With a change to the format of the previous days, Friday just ran straight to the different tracks.  Out of interest in the “Architecture You’ve Always Wondered About” track I checked out the Introduction.

Deciding that I’d had enough SOA knowledge, I stuck around the Architecture track and listened to the eBay presentation.  A really interesting look at how they design a flexible architecture that allows for their systems to scale with the traffic going to the eBay site, and still enable them to roll out new code releases ever couple of weeks.  They work on four basic principles;

1. Partition Everything
2. Async Everywhere
3. Automate Everything
4. Remember Everything Fails

The main enabler of this architecture is their dedication to keep it as stateless as possible.  The only time they use a session is the process by which a user creates an auction on the site through a multi-page wizard style interface.

After the eBay presentation, I wandered over to the Solution track to check out the testing framework for the Spring platform.  Basically it creates a wrapper around JUnit 3.8, 4.0 or TestNG that lets you “wire up” an application through Spring configuration and Java 5 annotations.

The rest of the day was dedicated to JavaScript, with a presentation on the Google Web Toolkit, an excellent AJAX platform for writing applications, and finally jQuery.

The day began with an interesting talk on Agile development methodologies (yet again). The different aspect of this presentation, was that it was more focused on the social skills needed in a team in order to work in an iterative, collaborative manner. His main point seemed to be to focus on what you as a team are good at, and making sure that your energies go into that, rather than inventive spin and lies or excuses as to why performance wasn’t what it should have been.

The rest of the day I spent in the “SOA, REST and the Web” track. Having now finally grasped the concept of REST services, I want to go back and rewrite all the web services I’ve already built. Whereas traditional “Web Services” focus on defining specific interfaces and APIs which must be continually maintained, so that if the back end is changed, the consumers of that service must be updated, REST utilises the standard operations of HTTP;

• GET
• PUT
• POST
• DELETE

By using these methods, any HTTP client can now consume your service, the services is identified by a URI which describes the resource, eg; http://example.com/orders/2007 would return all orders from 2007. The resources returned can then be defined as a MIME type, the same data could be represented by an Excel spreadsheet, and HTML table or a JPEG graph, all from the same GET request, just with different clients in the Header.

Much of the day repeated these concepts of REST.

After this opener, I attempted to take an interest in the Agile development track, I stayed for the introduction to the day, and decided I’d check out the “agile mash-ups” talk, but the rest didn’t interest me.

I ended up watching the first “Cloud as the new middleware platform” presentation on Amazon’s web services. I wasn’t aware that Amazon even had anything in this sector, I was expecting services for e-commerce to be honest. What they actually covered though, was a completely scalable server infrastructure upon which you could run any application you wanted. Using their server farms, they host numerous virtual servers, which for a reasonable fee, can be dynamically created, clustered and utilised for an arbitrary amount of time, charged by the hour and storage. Creation of servers was entirely scripted to allow for scaling when demand reached a specific point or more storage was required.

Returning to the Agile track, my mind ended up wandering through the “Agile mash-ups” talk, partly because we’d just had lunch, and partly because I just don’t think I get why Agile is such a big issue. Much of what the presenter said was common sense, take the bits that work for you from each of the agile methodologies and leave the rest.

InfoQ, the organisers of the conference regularly host recorded interviews with industry shapers on their website. For this conference they invited an audience in to participate in the interviews. I watched an excellent interview with Mark Little, a developer for Redhat who has worked on many of the current web service standards. He spoke about transactional web services, specifically WSTX’s two models acid transactions and business activity transactions. For a SOA environment, BA transactions should be used, although this just means providing compensation methods for each service. He talked about the great divide between SOAP Web services and RESTful services, how he wishes they would just “kiss and make up”. Finally he mentioned the JBoss Redhat merger last year, comparing JBoss to a teenage son to Redhat’s 40 year old father.

Last presentation of the day was on Spring Batch, an extension to the Spring framework to allow for easier development of batch processes.