Archive for the ‘software development’ category

Stop Press! facebook do social networking!

October 15th, 2008

As FOWA this year, Mark Zuckerberg confided in us his vision for FaceBook – social networking! Revelation!

As far as the interview with Ryan Carson suggests, he’s only in it for the betterment of the human race. A truly dull and uninvolved interview

The BBC did a much better job and actually asked him why he didn’t sell out! Well done Beeb

Sproutcore – 1st impressions

October 14th, 2008

Today i had a short play with Sproutcore (the “Cocoa for the Web” JS framework used by and optimized by Apple for me.com) for the first time. I was a little surprised with what i found.

 

 

 

 

 

 

The Great

  • The development tools are in Ruby using the merb framework
  • The development tools adopt a Rails like MVC architectural pattern, with commands like 

sc-gen model example/contact
sc-gen controller example/detail
sc-gen view example/card

  • The development tools include build tools that prepare all JS, HTML and CSS ready to be distributed.
    sc-build
  • The development tools have a bunch of ruby (rails-style) helpers
    <%= button_view :my_button, :label => 'Here is a functioning button!' %>
The not so great
  • It doesn’t work with the latest version of Merb (0.9.9 RC1) and doesn’t appear happy even having it around (even if 0.9.4 is installed, if seems to force a removal of 0.9.9 in order to work) – Patch submitted, but only recently.
I’ll keep playing and posting what i find, plus an app or 2 as i create them.
Check out these links for more info: 

synchronous scalability: the meebo.com success story

October 10th, 2008

Last Friday, i attended a presentation by the meebo.com crew where they explained their challenge and how their tackled it. I enjoyed their agile approach and the challenge they had to solve – how to make a synchronous web app that handles thousands of users without bringing down the server.

Scalability is an old story, but meebo.com’s challenge was different. They needed to scale in ways that asynchronous web apps (facebook, myspace, twitter etc.) do not.

  • They use the long-polling technique that results in the web server maintaining thousands of open connections with each user and that has significant affects on the server. 
  • They have a single gaim instant messenger process per user to allow the user to connect to MSN Chat, Google Chat, etc. and this had other effects (and significant benefits).
  • They initially used Apache and it had some affects.

It was clearly a fun challenge to have and as their user numbers ramped up, they followed a streamlined and effective approach that resulted in a lean, fit for purpose and extensible app. A great success story.

The big picture

September 18th, 2008

Software development is fun, there’s no doubt about it. All the collaboration, client interaction, protoyping, system architecture, and all that lovely code.

But, what happens when we, as developers, get too close? What happens when we get too involved in the code?

It all sounds rather obvious, but it can happen:

  • We don’t take a regular step back.
  • We lose the wider perspective.
  • We lose visibility of what ‘finished’ looks like, what parts make up the whole and how close we are.
  • We strain relationships with ambiguity, overly detailed feedback and uncertainty.

Getting this wrong can result in project failure. Getting this right takes a strong, close, confident and brutally honest relationship between all members of a project team. All members maintain a focus on the scope, plan and budget; especially the seniors. Daily catchup meetings provide a platform for team members to demonstrate their responsibly to the rest of the team and a platform for all members to consistently establish their awareness of the whole. Challenge is normal and data is king.

With all this in hand, projects flow and risk is clear and manageable. Team members are empowered and in every way are a part of the solution. Resource management is possible early and in perfect balance. Reporting and escalating is possible iteratively, keeping everyone empowered and in the loop.

How do developers get to this place? More to follow…

Uprooting agile

September 14th, 2008

Agile methodologies are being bantered around again and are quite often discussed as if for the first time, with an energy that is exciting, but at times with a level of certainty and yet incompleteness in some people that just doesn’t seem to fit – I’ve recently sat through presentations and had discussions where people seem to be looking for some kind of fame or self-certified expert opinion without getting to the roots of this clearly historically evolved perspective – They are grasping at small aspects of what appears to be a much broader subject that requires careful review. Don’t get me wrong, i love the banter, but either i am just well far behind everyone else on this subject (which is most likely true), or they are just blagging.

So, my mission is to uproot the agile working methodology and get an understanding of:

  • What are its parts?
  • What are its predecessors and its history?
  • What is its scope and who does it impact (it’s clearly a lot more than TDD, although some people don’t seem to think so)?
  • Is it actually possible to “do” or “not do” agile, or is it valid to adopt only some of it’s parts (This sounds like an obvious one, but i’m fed up with hearing “we do agile” and “we don’t”!)
  • How can we benefit from its many parts?

I’ll be posting more as I progress my uprooting.