IPad vs Rock Side by Side comparison

Recently i received a Side by Side comparison (Ipad vs Rock) where the IPad was declared the winner by a factor of 1 point. However IMHO i found it was unfair to leave best rock's attributes out of the item list:

Here is the Original item list i received in a mailing list (which its not from my authority):



Here are the Rock's attributes they left out IMHO:

• Can be use as a Defensive Weapon
• High Impact Resistant
• Water Resistant
• Fire Resistant
• So easy to use, it doesn't come with User Manual Documentation.
• Doesn't need Battery to Operate
• Its available to all Man-kind without a cost (its Free)

If you think about it, the IPad is a Rock derivate with less functionality, so for me the Rock can be declare a real winner.

TDD or not TDD thats the question!

For the past year i've being very involved in a project and we decide that TDD was a way to go to guarantee have a good TestCase suite and to be fully sure that each class have enough coverage when doing unit test. Hence we start relying in a particular mocking framework (after evaluating several of them EasyMock, JMock, PowerMock, Mockito) we decide to stick with JMockit. Our decision was based on the fact that we need to interface we a lot of legacy code that was not design having testability in mind, therefore JMockit plays a huge role here given its natures of Mocking anything (final classes, private methods, static methods,....).

It says that once you start hammering everything seems a nails to you and i must said im guilty on this. Recently i stump upon a site that make me think about this, i had really use this mocking framework in areas where it was not really needed, So yes I'm Guilty.

Now i look back and i now understand what a horrible mistake i did, i see myself now suffering the “Fragile Test” problem. Answer yourself this question and you may know what I mean:

How many tests break when you change a module? If the number is high, then the coupling between your modules and tests in high. Therefore, I conclude that those systems that make prolific use of mocking frameworks are likely to suffer from fragile tests.

Here is the complete article Mocking Mocking and Testing Outcomes.

The good news is that we are human and we are able to change and adapt, so lets get those test case fix! :D

Back on track!

Hi, I know i have being lost for a while!, almost 2 years from the last post. But a lot of things had happened and hopefully soon i will start posting again. Sharing all those cool stuff i usually find with my dear readers (which at this point i really consider my audience currently had drop to zero!) Nevertheless is 2010, so this new year brings new milestones both in my personal life and professional life. So lets get back on track!

So stay tune!

Newbie to REST

I found this while researching about REST WebServices, trying to find a simple way to describe it:

How to explain REST to my wife
http://tomayko.com/writings/rest-to-my-wife

Essential Skill for Agile Developmet (Turning Comments into Code)

I started reading this book and find it quiet good in the way it clear show you how to improved your development skills in a very simple way.

Today im reading the following chapter 2: "Turning Comments into Code".

How often we find outdated comments in the code, how often do we find useless comments in the code.

Basically this chapter tells you that if would be better insteads of putting a comments side by side with the code, just to make the code as clear as the comments itself. i.e:

public class ParticipantInfoOnBadge {
String pid; //participant ID
String engName; //participant's full name in English
String chiName; //participant's full name in Chinese
String engOrgName; //name of the participant's organization in English
String chiOrgName; //name of the participant's organization in Chinese
String engCountry; //the organization's country in English
String chiCountry; //the organization's country in Chinese
...
}

this could be written like:

public class ParticipantInfoOnBadge {
String participantId;
String participantEngFullName;
String participantChiFullName;
String engOrgName;
String chiOrgName;
String engOrgCountry;
String chiOrgCountry;
}


As you can see the code itself is clear enough to understand the meaning on each fields, even thought i could place a lot of examples showing where comments are not worth, i would rather prefer you to read the book.

Let me cite a paragraph from the chapter that clearly shows what the author is trying to teach us:

Why delete the separate comments?
In fact, comments by themselves are not bad. The problem is that we often
do not write clear code (because it is hard), so we take a shortcut
(use comments) to hide the problem. The result is, nobody will try to make
the code clearer.

Later, as the code is updated, commonly nobody updates the comments
accordingly. In time, opposed to making the code easier to read,
these outdated comments will actually mislead the readers. At the end of
the day, what we have is: Some code that is unclear by itself, mixed with
some incorrect comments.

Wall-E it is a Must See!!

Guys Pixar did it again, take your time and see that movie. I went with my 5 years old daughter and i enjoy it as much as she did.

WALL-E =

Waste
Allocation
Load
Lifters
Earth-Class

Rate 8.7 at imdb.com

Design Pattern and UML Quick Reference

I found this while surfing yesterday, which i think this a "must have" for every developer.

http://www.mcdonaldland.info/2007/11/28/40/

Or Just get the PDF by clicking:
http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf

Also for those who want to have a quick guide for UML:
http://www.mcdonaldland.info/2008/06/16/design-patterns-refcard-released-today/

http://www.digilife.be/quickreferences/QRC/UML%20Quick%20Reference%20Card.pdf