HTML Code Formater

If you always forget what html code is for "greater than" ;-) , here's some usefull tool.

Student Syndrome

Since I've been a student, I feel concern about the Student Syndrome.
I hope I don't procrastinate to much those days ;-)

XP Fun

Yes XP can be fun (hum... may be for a geek:p)... HowToPissOffYourPair

Simulation enthusiasm

I sometimes take a trip to the game developpement world through Gamasutra web site.
Which is, by the way, an excellent site. (you should create an account...)
I've read 2 articles.
The first one The Perils of Bottom-up Game Design:

If you're a software engineer, your natural temptation is to figure out how to program it(simulation) and see how it works. What are the core mechanics of the simulation?
(...)
Bottom-up game design is based on an assumption that any process that is subtle or interesting to program is also going to be interesting to play with. That doesn't necessarily follow. For years I was intrigued by the challenge of programming a traffic simulation. (...) I had gotten all excited about the software engineering problems and ignored the fact that it needed to be enjoyable.
(...)
the temptation to "improve" your software with one more feature, and then one more still, just because you can. In consumer software, the result is usually a bloated, awkward mess like Microsoft Office.

I feel guilty about those unnecessary features. Today I try to stick to those 2 rules:

• Don't had features the user didn't ask fo even if you find them "cool".
• Don't create a "'big realistic system" if it can be done simply (but not realistic who cares if the user is happy with it!).
  

The second article: A Software Process for Online Game Tools Development is discribing an XP development process without knowing it, it seems game development and entreprise development are in two parallele univers that don't communicate... too bad!

Josh Bloch on Design

Excellent article (a bit old 2002), I don't agree with everything, especialy final keyword and the use of inheritance(blog) but still interesting to read.

Dating Design Pattern

Ultimate geek gift for chrismas ;-) Dating Design Pattern

The Blind Men and the Elephant

Yesterday I was reading posts on "extends is evil".
I've often heard that opinion but I was wondering why?!
And actually seeing all the comments these kind of issues rises:

• Why extends is evil
  
• Don't call super
  

I clearly understand that it's not that easy!
Some people fell confortable with inheritance using extends.
Personnaly I sometime use extends. But usualy it gets more and more complicate to maintain over time/adding features (even with JUnit).
So I don't like extends (using super()) that much...

But all those debats about extends/implements, jsf (yes/no) etc... are interesting but often leads nowhere since everybody come and leaves with his idea.
Just like The Blind Men and the Elephant

Moral:
So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!

The problem with IoC

Forget to inject your dependancy in "application" code.
I've run across this problem at least 3 or 4 times since I've started to use JUnit (and therefore IoC).
Let's say I made this test:

public class ExampleTest extends TestCase {
public void testMyMethod() {
Example myExample = new Example();
myExample.setDataSource(mockDataSource);
boolean isOk = myExample.myMethod();
assertTrue(isOk);
}
}

Everything find, green bar!
My application code (where it's really use):

Example myExample = new Example();
// oups! I did it again! forgot this line:
// myExample.setDataSource(realDataSource);
boolean isOk = myExample.myMethod();

I usualy get a NullPointer, using stack trace one can easily find the problem but can I avoid it?
One way to avoid is to inject a default dehavior like this:

public class Exemple {
private DataSource dataSource;
public boolean myMethod() {
getDataSource().getConnection();
// ...
}
public DataSource getDataSource() {
if (dataSource == null) {
dataSource = new RealDataSource();
}
return dataSource;
}
}

I don't like this solution because using eclipse wizard to create getter/setter methods, I can (and I already have) forget to modify the getDataSource like above and also I can use directly the instance: dataSource.

An other solution could be to assemble the different parts of the object in an AssemblyObject of some kind and create a JUnit that assert that none of the attributes a null... but I'm not sure how to do this and still run my tests without the cointainer ?! (for exemple if RealDataSource use JNDI tree to locate dataSource)

Anyone already solved this problem?

Be Humble

Interesting post about being a humble developper: Why I'm the best programmer in the world

When interviewing candidates for programming positions, I always look for someone who is brave enough to say "I don't know" when they need to. Candidates who can't or won't do this get red flagged; those types of programmers are dangerous.

Unfortunalty, during interviews, IT manager doesn't always behave like this and take a "I don't know" answer for a lake of skill or knowledge...

In the same blog, the fear of breaking the code, in my opinion, is not only a sign of problems with developpers but also a sign of (no/not enough/not usefull) testing.
It can also be a sign that the manager doesn't understand that quality of existing features is more important vs getting knew features and doesn't give enough time to the team to refactor.
The refactoring mindset should be taught during university courses.

update: about Hiring Technical people

Does it smell ?!

Excellent set of blog about:

• Development Environment Smells
• Test Suite Smells

Test suite smell:

Suite takes too long to run
(...) These tests are more often than not integration/system tests (...)

When I first started to use JUnit, I did it to help me get a piece of code work. This set of classes where too complicated, unforunatly I couldn't isolate this from the rest of the system and my tests became integration tests that took too long and do not even cover 10% of the tests.
Since then I've learn from my mistakes and I've mocked up some parts to get holy isolation.

But mock aren't always the answer...

Over reliance on mock testing
(...) the usage of mock/stub to stand in for real implementations is that the standins do perform in a fashion largely identical to the real thing. If this is not the case (...) then reality will tend to remind you of this mistmatch (...)

Exemple: A classe need a file, but you can't rely on the file to be in the file system when you run the test, then you mock it up.
The MockInputStream need to behave like a normal InputStream otherwise your test can get a green bar and never work with a real file...