The Kaizen way

When facing a problem the usual "envy" is to create a big solution that seems to address every problem.
But in real life, you'll soon realize that's not that easy! Small problems go along your way and transform that wonderfull piece of solution into a not so perfect one!

I found working with small steps the better way to achieve things. Taking small requirements and adding them one by one is the best solution.

The Toyota production system really captured that spirit.

The same principle apply to Software has been discribe by Mary Poppendieck. (Excellent article: Principles of Lean Thinking).

You can also find a definition of Kaizen at wikipedia.

Testing difficulties

Quoting from xp book mailing list:

If it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test. --Kent Beck

First time I used JUnit, I had trouble because my components where tightly coupled and then couldn't be tested easly.
At first I thought I'll extend JUnit framework by subclassing TestCase and then I realized I should use IoC to get easy to test and therefore easy to use components.

Pragmatic Programmer

Thomas lend me this great book: Pragmatic Programmer
...at least great until the 40th page since that the page where I stopped reading yesterday ;-)
Funny, easy to read, full of good advises and tips (some I knew, some I didn't).
Now I know I'm not the only sick person who keeps asking "why I'm doing this or that" when I work... :p
They emphasis you to always think about what your doing and why, to see if you could improve the thing (code, documentation, meeting, whatever...) your currently working at and become better.

Learning Names

Looking back at 2004, I realize (amongst other things) that I've learn peoples'names.
In 2003 I had hard time remembering names of famous java programmers/architects (or even not knowing those people at all).
Now I know who is:

• Martin Fowler
• Ward Cunningham
• Kent Beck
• Ron Jeffries
  
• Craig McClanahan
• Ron Johnson (no blog, too bad... have a look at spring)
• The GoF (Erich Gamma)
  
• and many other...
  

But I still need to read a little more about some of them...
For example thomas pointed me Alistair Cockburn whom I knew about but never read anything from him.

New job at anyware

Leaving midiway where I worked for soltim.
I had the opportunity to learn lots of technical stuff during those 3 last years (cvs, xp, junit, struts, eclipse...) in a team with cool people and a project manager who lets us try things to improve quality!
I'm going to anyware (thank you sylvain :-) ) , it will be hard since this company seems loaded with smart developers! (looks like a french thoughtworks to me).
Don't know yet exactly when I'll start...

Blog title changed

When I first created my blog at blogger, I didn't expected the text I was putting in the title input would appear in rss aggregators.
A blog with "Java/J2EE, XP and Architecture" title seems quite boring and pretentious ;-)
Now it's simply: "Francisoud Blog".

XP Story Studio

.NET tool, usually XP stories are written on card but why not...
Also about user stories.

JVM profiler

NetBeans memory profiler, usefull when you need to understand how memory is handle by the jvm (thanks to Tor for the link).

Also recently read about that subject (JSR 174: Monitoring and Management Specification for the Java^TM Virtual Machine):

Monitoring and Management APIs: The java.lang.management package provides the interface for monitoring and managing the JVM. It provides access to information such as: number of classes loaded and threads running, memory consumption, garbage collection statistics, on-demand deadlock detection, and others.

Since Sun made significant improvements of the memory handling:

New in the J2SE Platform version 1.5 is a feature referred to here as ergonomics. The goal of ergonomics is to provide good performance from the JVM with a minimum of command line tuning. Ergonomics attempts to match the best selection of

• Garbage collector

• Heap size

• Runtime compiler

for an application.

EAI Patterns

If you like patterns (at least I knew a colleague who does :p ) and messaging (excellent introduction article to JMS), you should take a look at Enterprise Integration Patterns.

(Not so) surprising Holub rant

I've come across this SD times article from Alan Holub (pointed by Alexis).
At first I was surprised:

The newest version of Tomcat was just plain broken. (...)
Tomcat’s documentation is virtually unusable(...)

Some other open-source source code that I’ve seen is equally bad—Hibernate is a mess, for example—and many commercial projects aren’t much better (much of the Java library code is a case in point).

In all fairness, some open-source projects don’t have many of these problems, but those projects tend to have started life as commercial software that was released to the open-source community.

Since I've never really had problems with Tomcat and being a "open source" freak... I don't really agree with him, BUT he has some points and (even) open source projects aren't perfect (actually the perfect project is an utopia) and providing the right documentation (enough/not too much) is hard.

And then I realize I knew this guy from javaworld articles:

• More on getters and setters
• Why getter and setter methods are evil
• Why extends is evil
  

As you can see from his articles'titles, he's "Dr Evil".
He likes provocation... (just like tirsen).
Funny to see that some people are like that...

New year - New Template blog

This is a new year so I decided to change my template blog. done! nicer!

Database: natural vs surrogate key

When I fisrt started to use database, my teacher taught me about natural key (like Social Security Number) and then warn us about not making too much use of it (example of bad use: primary key is street + postal code + town + phone number to define a unique address) .
Then he introduced surrogate key (usualy a unique integer like AddressID).

My experience of database lead me to use mainly surrogate keys... until recently! where it seems that surrogate key might be a problem in some case.

Exemple:

• Problem 1: your application/database need to import/export/communicate data to another application/database for exemple using a flat file between the 2 systems.
• Problem 2: As always the 2 databases strutures are differents (concepts-features-tables-cardinality).
  

Question: What can you do? What problems do you have?

• If you used surrogate keys:
• You can send your AddressID to the other system but what will it do with it? The other system surly will aslo have PK_Address_Id of his own, it won't be able to insert your Id into his -> not able to keep unicity
• You can try to send only natural keys (Social Security Number), but since it is not you primary key you can export 2 lines that seems identical but have a different Id...
• If you used natural keys:
• It seems easer to export Social Security Number into a database struture with ID + SSN than the other way

Reading the excellent agile data site, about this subject:

[Using natural keys]... The implication is that you want to avoid keys with business meaning because business meaning changes.

I tend to agree with him that surrogate keys are somehow still better since queries are easer and refactoring more flexible.
Also using natural or surrogate keys don't avoid problems about concepts such as:

• system n°1: n Users owns 1 Order
  
• system n°2: n Users owns n Orders

In that case I don't see any solution except changing one of the two system.

Conclusion: I'll still use surrogate keys but try to avoid them whenever possible if there is an easy natural key.

Refactoring to Patterns

Whee! I just received Refactoring to Patterns (ISBN: 0321213351)
It seems nice but as an introduction Joshua Kerievsky talks about the GoF and Refactoring.
I haven't read them (yet), hope this won't be a problem to understand...