Approximity blog home
230 to 239 of 784 articles

Blackbox: your datacenter in a container   24 Jun 07
[print link all ]
For a project we are currently looking at datacenters and we all agree that the idea of getting all the equipement stuffed into a container is a useful one:-).

Hello Ruby, I'm Erlang   07 Jun 07
[print link all ]
Ruby-Erlang bridge. Really nice to have and no surprise, as Erlang is fascinating ever more ruby enthusiasts. Always nice to use the right tool for the right job.

Free Book: Data Structures and Algorithms with Object-Oriented Design Patterns in Ruby   26 Apr 07
[print link all ]
Great free book by Brune R. Preiss.

"The execs say they have the least troubles with the programming department"   20 Apr 07
[print link all ]
Jim Shore posted this to the XP-List
 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.


XP: Real-world experiment with Hours instead of points   11 Apr 07
[print link all ]
Manuel Klimek posted his insights to the XP-list.

 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

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


Skiing in Garmisch :-).

APFP (Arbitrary Precision Floating Point)   09 Apr 07
[print link all ]
APFP (Arbitrary Precision Floating Point) is an Unicon class for performing arbitrary precision floating point calculations. It also includes a class for calculating with arbitrary precision complex numbers. It requires unicon overloaded operators. It also contains a ureal class for built-in reals. Both classes keep an estimate of the accumulated error.

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

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

Happy Easter!   08 Apr 07
[print link all ]

Good read on Rinda on DataNoise   08 Apr 07
[print link all ]

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

On indispensable persons in a team   29 Mar 07
[print link all ]
John Carter posted this to the pragprog-ML.
 >> 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...

Update: Air France - miracles happen   29 Mar 07
[print link all ]
After writing a "nice letter" they finally accepted the miles. I am still positively surprised that I was able to get somebody in this big company to listen to me. Good. I guess the lesson to learn is that one has to by very stubborn and never give up!


powered by RubLog
230 to 239 of 784 articles Syndicate: full/short