25 Jan 2005
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.
19 Jan 2005
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 BeckFirst 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.
...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.
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...
For example thomas pointed me Alistair Cockburn whom I knew about but never read anything from him.
14 Jan 2005
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...
A blog with "Java/J2EE, XP and Architecture" title seems quite boring and pretentious ;-)
Now it's simply: "Francisoud Blog".
13 Jan 2005
12 Jan 2005
Also recently read about that subject (JSR 174: Monitoring and Management Specification for the JavaTM 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
for an application.
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:
He likes provocation... (just like tirsen).
Funny to see that some people are like that...
7 Jan 2005
6 Jan 2005
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.
- 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).
- 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
[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
Conclusion: I'll still use surrogate keys but try to avoid them whenever possible if there is an easy natural key.