Fabio Pereira

We have adapted on our project James Crisp’s cool idea about changing the color of the command when the build fails or passes… Now it works for maven

mvncool.bat file

@echo off

color 07

call mvn %*

IF ERRORLEVEL 1 goto RedBuild
IF ERRORLEVEL 0 goto GreenBuild

:RedBuild
color 4F
goto TheEnd

:GreenBuild
color 2F

:TheEnd

It’s quite similar to the one that Crisp posted, so thanks Crisp for the interesting and reusable bat file.
Some small things are different for maven though… Check them out.

Step by step to have it working on your maven project:

• Download this file mvncool.bat (or copy it from the text box above)
• Move mvncool.bat to either:
     - the root of your project, where your root pom.xml is. You can also add this file to your version control so that everyone can use it.
     - or any folder which is in your PATH. It could be the same folder where mvn.bat is: MAVEN_HOME/bin/.

• From the root of your project, just from where you used to run your mvn you can from now on run mvncool instead. You can send the same parameters mvncool clean install for example and they will be sent through because of the %* on the bat file…

Before mvncool

mvn clean install
mvn package
mvn (anything)

Using mvncool

mvncool clean install
mvncool package
mvncool (anything)

Technical Agile, CI, Fun

Do you think it would it be easier to maintain, understand and increment a code where all the variables that represent the same “thing” are named consistently throughout the code base?

Pat talks about “differences that cause your project death”, I wanted to explore a little bit more one of them: Naming…

Have you ever seen something similar?

PersonalBankAccount account
...
PersonalBankAccount personalAccount
...
PersonalBankAccount bankAccount
...
PersonalBankAccount pAccount
...
PersonalBankAccount pba
...
PersonalBankAccount pbAccount

Different names would help if they add any value to the instance, but the aforementioned examples are a result of different “coding styles” amongst different developers. Some of us like to type, others like to use code completion and it’s dependent on the IDE they are using.

Most of the projects that I’ve worked used checkstyle to enforce code standards. One of the standard checks I’ve always seen is the Naming Convention, which checks identifiers for particular code elements.
If we are following Sun coding conventions, the code below, for example, would generate a checkstyle error

public static final Year minimumYear = new Year(1900); // WRONG
public static final Year MINIMUM_YEAR = new Year(1900); // RIGHT

because a constant should follow the regular expression ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$

So, code standards are advantageous! Therefore, we can use the same concept to avoid the PersonalBankAccount example.

What I usually do is totally informal, but I try to define with the team an initial convention, Camel Case with all the words for example,

PersonalBankAccount personalBankAccount // wherever possible

Sometimes we need more than one instance in the same block, I like suffixes:

PersonalBankAccount personalBankAccountToTransferMoneyTo
PersonalBankAccount personalBankAccountSourceOfMoney

This is an exception though, wherever possible, use the convention.

But always bear in mind that this is not a rule that you can’t break, it’s just a convention…

I have never seen any tool, or checkstyle check, that could generate something like:

“Number of different instance names for class T”, maybe it’d be interesting… But that’s another, another, another level…

Technical Code, Java

You must have heard the old story about the fact that “it is always hard to find out WHAT the clients want”?
And also if you are a developer you must have faced the problem of not knowing HOW to implement a particular requirement.
A good approach that my friend Kelly came up with the other day was to ALWAYS ask WHY first.

Once we understand the client’s needs, it will be much easier to implement the feature in such a way that will add more value.

The other big issue of not knowing WHY is delivering or even estimating “not needed requirements”. For example, the other day we were estimating a Single Sign-On feature for an application that did not have any other app or even OS to share credentials… So, we asked: WHY do they need SSO? And then… Ding Dang Doon! (Thanks Dave Coombes and Ryan Moffat for the awesome onomatopoeia “Ding Dang Doon”)

Technical TWCard