Thanks to TupleSpace I have the time to enjoy spring skiing in Garmisch :-).

 >> What happens when John leaves the company, and he's trained everyone
 >> to, whenever a certain class of error happens, go to him without
 >> learning anything about the problem first?

 That does concern me... It makes economic sense to me the rule "If a
 person is indispensable to your company, fire him now, since it
 will cost you more when you do eventually loose him."

 Thus I have several counters to the Truck Factor...
 1) Unit Test / TDD === executable documentation.
 2) Good rdocs that I periodically refresh.
 3) Get others to code review my changes.
 4) Go on holiday. The "It's Johns fault" message tells them immediately
     they had better start reading code if they want it fixed before I get back...

 > You don't have to be stupid to avoid work. I'm no dope, but I avoid any
 > > work I can avoid. If your co-worker sees the change a fully-automated
 > > build as extra work, and he doesn't want to do extra work, then you
 > > could try showing him why the fully-automated build will make for less
 > > work. If he can't see it, he can't see it. Don't smack your head against
 > > the wall; it just hurts.

It could be a "cultural" thing. The Unix philosophy was that if you were going to do something more than a couple of times, you should write a script to automate it. For PCs, it was that if you were going to do something a bunch of times, you should get some fancy GUI with a ton of buttons and then memorize all of the icon functions and key sequences. Pressing 5 or 10 buttons in a row is not seen as being too onerous.

Having been on both sides, automating it is always more consistent, faster in the long run, and helps to document the steps. Long sequences of button pressing are prone to human-memory glitches, making it a source of frequently errors. GUIs are good for rarely used and exploratory tasks, but not for frequently used or critical work. Unfortunately the PC development culture leans heavily on button bashing, IDEs and pretty GUIs (even for things like diff). It is something that I’ve always seen as a de-evolution in software development, but I realize with many developers it is a religious argument.

Paul.

Anyhow, my wife flew with AlItalia from Buenos Aires to Munich. As she forgot to show her flying blue card at checkin time we sent the original boarding passes to Air France. Surprise, surprise, they do not add the miles and also do not send back the original boarding passes. Of course I did not go so upset if that were the first time … the same happened to our miles from the flight to Colombia.

Oh well, we are all human, so I call flying blue and wait and wait in the queue only to hit a poor operator who can’t even pass me to his manager .. the system does not allow me. So, I call Air France directly to hear:

  "It's your choice whether you fly with Air France or not".

Isn’t that a nice statement? An for sure, it will be my choice. I will empty my frequent flyer miles and then good bye Air France! Airlines try to save money, but treating your customers like that is simply appalling! Why can’t one talk to a normal human being and release steam and find a solution that works for all parties?

I recommend you all to take your money where people treat you with respect!

They got zillions of interesting parallel computing and Bayesian maths problems. More to follow ..

One of the lessons I learnt sofar from this venture is that if you have enough data, you do not need to be too smart as things have nicely converged :-).

Sebastopol, CA, February 13, 2007—To meet the increasing demand for skill building, and to spread the joy of Rails, Ruby Central and O’Reilly Media are teaming up to produce RailsConf Europe 2007, an entire conference dedicated to Ruby on Rails. Happening September 17-19 in Berlin, Germany, RailsConf Europe will offer keynotes, sessions, and tutorials from the most innovative and successful Rails experts and organizations. O’Reilly Media and Ruby Central are seeking leaders to present sessions and tutorials at the conference. Qualified practitioners with insights and anecdotes to share with IT professionals and the Rails community are invited to submit a proposal by April 12, 2007.

The Ruby on Rails development framework turns three years old this summer, and in that short time, it has gone from cult favorite to major player in the Web development world. By every measure—feature richness, adoption, publications, developer reception—Rails is a phenomenon, and one that’s here to stay.

The conference committee is looking for presentations and/or tutorial proposals from Rails developers and hackers, Rubyists at large, Rails trainers, designers with a Rails focus, managers, entrepreneurs—anyone with Rails experience, expertise, and insight.

Proposals should focus on helping attendees by teaching from experience. Any Rails-related topic will be considered. Below are some specific areas the committee would like to see represented at the conference:

• Timesaving developer productivity tips, tricks, and tools
• Spotlights on important Rails subsystems
• Making the most of new Rails features
• Rails development case studies, including application rewrites and organizational boot-strapping
• Migrating applications and people from other technologies to Rails
• Gem and plug-in highlights
• Patterns and best practices
• Extending Rails

RailsConf Europe 2007 will bring together hundreds of Rails practitioners from Europe and around the world, for three days of presentations, tutorials, and Rails comradery. Last year’s event sold out completely and we are expecting an even greater number of participants in Berlin for RailsConf Europe 2007. Attendees will include Ruby and Rails enthusiasts, web developers and programmers from all sizes and types of organizations, open source developers and hackers, IT managers tracking emerging technologies, tech-savvy entrepreneurs, and users at every level of expertise.

For complete RailsConf Europe 2007 details, visit: www.railsconfeurope.com

Interesting write up at register.com

Brian Marick wrote this great book. Brian is a well known testing guru, but this books appeals to a much wider audience. Through a few simple scripts he teaches people how to code every day tasks in ruby.

It’s a short and easy read of nearly 300 pages and requires no previous ruby knowledge. If you already know ruby, this book is probably too slow, but if you come from any other language, it’s a great book.

In the end, it’s better to avoid creating stubborn dragons in the first place and to slay them early if they start to turn bad. Young dragons are easier to slay than old ones. You may even slay several dragons before you are happy that you have one you can live with.

Image source

The rumor mill says, that we will soonish see tons of interesting Javascript and Ruby stuff there .. thanks to one project in winter country :-).

Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. However, in business we often try other strategies with dead horses, including the following:

• Buying a stronger whip.
• Changing riders.
• Say things like, "This is the way we have always ridden this horse."
• Appointing a committee to study the horse.
• Arranging to visit other sites to see how they ride dead horses.
• Increasing the standards to ride dead horses.
• Appointing a tiger team to revive the dead horse.
• Creating a training session to increase our riding ability.
• Comparing the state of dead horses in todays environment.
• Change the requirements declaring that "This horse is not dead."
• Hire contractors to ride the dead horse.
• Harnessing several dead horses together for increased speed.
• Declaring that "No horse is too dead to beat."
• Providing additional funding to increase the horse’s performance.
• Do a Cost Analysis study to see if contractors can ride it cheaper.
• Purchase a product to make dead horses run faster.
• Declare the horse is "better, faster and cheaper" dead.
• Form a quality circle to find uses for dead horses.
• Revisit the performance requirements for horses.
• Say this horse was procured with cost as an independent variable.
• Promote the dead horse to a supervisory position.

Nice thread int he extremeprogramming-ML