Net pearls

Reading tons and tons of internet stuff, I often find some posts or some documents I find interesting or funny: some net pearls.

As usual I would like to share this with the rest of the world and present those collected pearls as a post.

Pearl n. 1

This historical document by Dr. Winston Royce presents the waterfall model. The interesting sentence in this document is:

I believe in this concept, but the implementation described above is risky and invites failure.

This line must not have been quoted very often by waterfall proponents,...

Pearl n. 2

The next pearl comes from a study of the productivity of several languages. This story is interesting because it compares the use of different types of languages, static or dynamic, through different axes: productivity, length, memory consumption, speed,... Whatever my love for programming languages, the pearl is in the following conclusion:

Interpersonal variability, that is the capability and
behavior differences between programmers using the
same language, tends to account for more differences
between programs than a change of the programming
language.

Pearl n. 3

This one is both funny and interesting (read the whole thread): do we need a "might-equal" operator?

How about adding a "might-equal" operator?  I recommend useng
 the characters "=?".  I hav implemented my hone programming 
language, incubating the might-equal operater.  It works 
somthing like this:

if (x =? y)
  print ("x might equal y");
else
  print ("x might not equal y");

Acording to my studys, the might-eqqul operatir is 299834%
 more useful than the standerd ekwal operator.  For
 testing porposes, I have usd the mighty-kwal operatyr 
in severul custom sofware packages, including spell 
chex and statistics soffy-soff.  I hope that you ull can 
make yous of it in yore own pergroomink lunkishes. 

Pearl n. 4

This presentation from Michael Feathers introduces some coaching patterns and suggests visualizing the group as an individual, "Pat", even if one-on-one action is the privileged interaction medium:

‘Pat’ does not embody an organizational goals, ‘Pat’ is an amalgam of the team

Pearl n. 5

A little bit of history here. Here's a snapshot of notes taken during the meeting that led to the Agile Manifesto.

Pearl n. 6

Acceptance tests is one area that is still not very well covered by software vendors, despite their great usefullness (in terms of executable specifications). This may not be true anymore with Greenpepper software.

Pearl n. 7

Do you like programming quizzes? Here's a nice puzzle from John McCarthy (Lisp's inventor), solved with Haskell:

We pick two numbers a and b, so that a>=b and both 
numbers are within the range [2,99]. We give Mr.P 
the product a*b and give Mr.S the sum a+b. The 
following dialog takes place:

Mr.P: I don't know the numbers
Mr.S: I knew you didn't know. I don't know either.
Mr.P: Now I know the numbers
Mr.S: Now I know them too

Can we find the numbers a and b?

This puzzle is solved by encoding the facts in a few statements.

Pearl n. 8

You can still do funny stuff with Java! Check this out and turn the page.

Pearl n. 9

What's hot, what are the next technologies you should keep an eye on? This conference program proposes some answers:

• Services (SOA, web services, composition, mashup)
  
• Web frameworks (Rails, Tapestry) and Ajax
• Application frameworks (Spring, OSGi)
• Build systems (Maven) and automation
• AOP
• Open-source (use, participation)
• Collaborative, open webapps (Web 2.0)
  

Pearl n. 10

I like concrete examples when it comes to describe concurrencies issues, the next big question in our industry (not in the previous list, which also shows that is it far from complete). But fortunately, humans do distributed computing!

Bob. Alice calls Bob: "Could you get me those numbers?"

Bob jots Alice's request on his to-do list. "Sure thing, Alice, I promise I'll get them for you after I solve this engineering problem."

Bob has handed Alice a promise for the answer. He has not handed her the answer. But neither Bob nor Alice sits on their hands, blocked, waiting for the resolution.

Rather, Bob continues to work his current problem. And Alice goes to Carol, the CFO: "Carol, when Bob gets those numbers, plug 'em into the spreadsheet and give me the new budget,okay?"

Carol: "No problem." Carol writes Alice's request on her own to-do list, but does not put it either first or last in the list. Rather, she puts it in the conditional part of the list, to be done when the condition is met--in this case, when Bob fulfills his promise.

Conceptually, Alice has handed to Carol a copy of Bob's promise for numbers, and Carol has handed to Alice a promise for a new integrated spreadsheet. Once again, no one waits around, blocked. Carol ambles down the hall for a contract negotiation, Alice goes back to preparing for the IPO.

When Bob finishes his calculations, he signals that his promise has been fulfilled; when Carol receives the signal, she uses Bob's fulfilled promise to fulfill her own promise; when Carol fulfills her promise, Alice gets her spreadsheet. A sophisticated distributed computation has been completed so simply that no one realizes an advanced degree in computer science should have been required.

Conclusion

Here we are. I didn't mean at all to reach 10 pearls exactly but this came to be precisely the number of pearls I wanted to share. This must be a proof of the profound wisdom they embody.

See you for Net pearls 2! (Sooooo handy when I have nothing to say ;-) )