Monday, March 22, 2010

Barbie geek !

There is a new Barbie doll that came up couple months ago : the computer engineer ! or should I say the Barbie Geek ?

Well I am not sure about the pink notebook,  the binary screen is  a bit Matrix-like and the T-Shirt quite ugly compared to Roy's fantastic T-Shirt collection. (RTFM Might not be appropriate  though...)

and Barbie's glasses looks like more a librarian than ones Moss have( More on the great show The It Crowd)

Well all  that to say that IT, is definitely an area of men. But apparently, it is not always have been the case.
In the 80's, there was about as many women as men in the IT field - what was 80's IT anyway? perforated cards ?. Some say that it was because computer had keyboard, and therefore linked to the type writing activity - activity linked to the female gender. I believe on the contrary, that it is more a transformation of our society that change a non gender specific activity  to make it a male dominated field :towards the 90',s it then became almost exclusive to men.

In the 80's, PCs became part of the house, and male fascination of the machine combined with gaming experience, led a bunch of boys naturally attracted towards the computer (including myself), wanting to know how that game worked, maybe trying to code their first game. This led them naturally to an IT career, wanting to go on and work on The Machine aka computer.

Then on the computer class, that led of a difference of level : more at ease with the computer through their home hacking, that often discourage their female counterpart. It does not mean that they would be better students, even probably the contrary since they will not empty their cup.

A later obstacle for a girl to pursue an IT career is the image of  the IT student:  a social image of someone sitting in front of a screen 24/7. Not very appealing for a girl, and neither for her parents.

Women apparently have a different view of IT career, wanting to code for a real application like, for example medical research.
In the meanwhile, in other scientific areas, the trend is to tend towards at least an equilibrium, alas not in IT.

Some links:

Wednesday, March 17, 2010

Test Driven Reverse Engineering

I stumble upon a piece of code, trying to figure out what the code was doing.
There was some useless comments, and the method I was studying was simply too complex.
To complete the picture, no unit test was available.

So instead of trying to understand the code, probably missing a lot of subtle flows, I created a unit test from scratch. Doing so made me understand the behavior of the particular class.

As in Test Driven Development, you are writing the behavior of the class in the unit test before implementing it.
(Check the very good M. Fowler article)
In my case the code was there, so it was Test Driven Reverse Engineering.
The end result was great :
  • I could understand the behavior of the method
  • Having a working unit test, I could easily refactor with confidence to make the code understandable.

Tuesday, March 16, 2010

Code generation and MDA

"Wouldn't it be great if dummy code could be generated ? "

Yes, a great idea that turns out not to be a great one at the end.

I remember the code generation by the Rational Rose IDE. I used it back in early 2000's creating a lot of class, collaboration and sequence UML  diagrams We even made some specific VBA to extrapolate state diagrams, and then generated nice classes, that were basically skeletons. So you have nice diagrams with  the code matching it, and the "Architect" is happy with all this artwork.

Then refactoring came in the picture, the upfront diagrams did not hold very well of course, and at the end those nice diagrams were out of sync with current code, making them quite useless, (but the "Architect" can still show off  his MDA approach of the project to some gullible people).

Another example : generating POJO classes from the database schema/
You can use an hibernate tool to generate, from the database, the associate mapping and the corresponding POJO.
First that remove the ORM from the "hibernate is an ORM persistence framework".
But besides that the very annoying part is that you cannot modify the generated POJOs. Let's say that you want to modify a field, or rename it. Since you would need to modify the create a DLL script, modify the dB, generate the classes, and refresh it in your IDE, more likely you will never evolve to do simple refactoring. You can't do it directly in your IDE. That case goes actually a bit beyond simple code generation and MDA, since it is also about database evolution. Great article and author book about it.

But back to the subject, sometimes the generated classes are missing some behavior that you want to add ( maybe a specific logic for that object - remember that you are still doing OO, or a well defined equals method often missing)... can't do it.


You must not modify generated code, but you want to since it is part of your compilation / IDE.

So now, why someone would want to generate code?
Because the code is dummy and is redundant with DataBase/UML Schemas/ Existing Code

2 ways I see it :
 - those dummy classes should not exists or should act behind the scene. If the code is generated means there is no logic inside so why even the need of the code ? Use dynamic proxies, dymaic language, anything so that it is not part of your compilation environment / IDE..
 - the code is the design. Diagrams could be used for a sketch but the current design is the code.

Tuesday, March 2, 2010

Useless Javadoc

Javadoc, similarly to comments , is useless in a in-house project (with no public API), and would show that the class/method is not named properly, or do more stuff that it is supposed to do.
Moreover when it is automatically generated by the IDE ( namely Eclipse),  you might see horrors like that :

     * @param bookId
     * @param bookType
     * @return Book
     * @throws Exception
    public Book geBook(String bookId, Long bookType) throws Exception
Great. Very useful. In that particular case, I'd rather not have any Javadoc since the method is pretty straightforward, and I don't know what kind of exception I would get.
Some argue that Javadoc  could be useful for boundary cases.
" What the method would do if there is no book type with a given type ID ?"
Well return  a typed exception BookTypeNotFoundException and I am sure that you would not need any Javadoc.