ENV['LC_CTYPE'] = 'en_US.UTF-8'
 Ferret.locale = "en_US.UTF-8"

 see http://bugs.omdb.org/browser/trunk/config/environment.rb

 searching for utf-8 works great, i've indexed characters
 in german, english, asian languages, hebrew and other..

It’s one of the few links that made it into the expensive real estate of my browser toolbar.

strangemaps.wordpress.com/

Here is one update I can talk about .. my hair makeover done by my beautiful wife. That is what I look like right now. Hal called it an "ugly baby" :-).

Enjoy summer!

bluxte.net/blog/2007-07/06-39-54.html

www.sun.com/emrkt/blackbox/index.jsp

www.datacenterknowledge.com/archives/2007/Jun/23/stanford_center_is_first_blackbox_recipient.html

www.youtube.com/watch?v=svLdboZdfQ0

nullstyle.com/2007/5/9/erlectricity-hi-ruby-i-m-erlang

www.brpreiss.com/books/opus8/

 I heard something similar just this week, actually.  It wasn't a
 manager--it was the person responsible for sales and support.  She
 said, in a discussion of the company's value stream, "Programming
 isn't the problem.  Once it gets to the programmers, we know it's
 going to get done."

 Pretty cool.  She was referring to an experienced XP team that's
 three or four years old.

 Cheers,
 Jim

 Hi,

 we're currently implementing some the XP concepts when we can see the
 reason for using a concept. Mostly this is due to some problems we
 identify. I'm not a consultant, but integrated into a development
 team, perhaps that allows me to see things from a different
 perspective.

 I found that people dislike "guessing" effort in time, because they
 feel bad if estimated ideal time is small compared to actual time.
 This can lead to the following problems:
 - overcommitment (but this time I'll do it in 2 days! really!)
 - undercommitment (if I guess a lot too much, I feel better if I'm wrong)
 - artificial pressure (I guessed 2 days, so I need to do it in 2 days,
 let's not do refactoring now)
 - demotivation (being wrong makes me feel bad)
 - problems with communication to product management ("but you said
 you'll do it in 2 days, now it took already 5!" - "but I said it's
 ideal time!" - "than tell us the actual time it will take the next
 time!" - "but I can't do that" etc)

 Using points solved this. Perhaps explaining to the developers that
 they have to accept that ideal time has nothing to do with actual time
 and that they should not worry too much about correctness of single
 guesses and explaining to product management that there are different
 time estimations (some in ideal time and some in actual time) would
 have solved the issue, too, but simply using points is clearer, since
 you make the distinction explicit if you communicate about effort.

 If I tell to product management that this item has size 3 and they ask
 me how long it'll take, then I tell them that if they include it in
 the current iteration they'll have it at the time the current
 iteration finishes.

 All this is less communication effort for me and thus increases ROI
 because I can work on code instead of nitpicking on the concept of
 time  :-)

 Cheers,
 Manuel

Skiing in Garmisch :-).

Changes: This is the first Ruby version. The design is much cleaner. Error tracking and complex numbers are not yet completed.

apfp.sourceforge.net/

Spring at the "kleiner Arbersee" (Bavarian Forest, Germany).

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 :-).