Now what is this Git?

It is an open source version control system. So why do we care? We already have subversion. Here are few points which might get you interested.

It is a distributed version control system – which means every user has a complete copy of the whole repository locally on his/her box, I mean everything with complete history and thus the ability to track the revisions without going to a central server. It brings in the advantage of looking at a file history offline and in no time. It also brings in a side effect of having the repository backup at so many places.

Branching and merging comes in naturally – Since every check out in a way, is a sort of branching by itself, the whole process of branching and merging for Git can be compared to checkout and commit for may be subversion.

Offline and Extremely fast – Remember there is no network latency as everything happens locally, as the local copy on a box is a full-fledged repository. So no matter what we are doing, committing the changes, looking at a previous version of a file, looking at the history, performing a diff or anything else we do not need a network connection to the central server and it is damn fast.

Does need a small space – If every user has a complete repository on his/her local box, so obviously there is a concern for the size of it. Fortunately the way it is packed it is much smaller in size then may be subversion.

Not yet good support for IDEs – Not yet quite there to support most of the features from IDEs like eclipse or may be a windows explorer extension which we have for subversion. Although it does provide command line tools and graphical interfaces like git-gui

Tracking binary files – Git considers each merge of a binary file as a new file and thus do not support tracking and history for such files.

If these are not enough to arouse the interest, may be looking the projects which uses Git for their source code management might as well.

http://git.or.cz/gitwiki/GitProjects

DBUnit – Need for creating tables

While doing unit testing for my DAO’s with DBunit, I never really realized that I have to explicitly create tables in the in-memory database and having an XML for the test data or even a DTD to validate it is not enough. That was till I planned to use JDBC and not hibernate to implement the DAO’s.
While woking with Hibernate it was always so easy to just turn on the hibernate.hbm2ddl.auto to update as part of hibernate properties and that is it, hibernate takes care of creating the schema from the hbm files or the respective annotations. But with JDBC, we have to explicitly create the tables in the in-memory database otherwise executing the test case will throw NoSuchTableException.
The easiest way to do it, is to execute the following.

SimpleJdbcTestUtils.executeSqlScript(new SimpleJdbcTemplate(getDataSource()),
new ClassPathResource("CreateTables.sql"), true);

Obviously we can use the above if we are using spring framework.

Eclipse Tip : Static import help

While working with easy mock, till now I have to explicitly go and copy paste all the static imports from an earlier test case into the new one as there is no way (at least that is what I thought till now) to make eclipse help me assist with content completion without it.

Even worse is for every new method which I want to use on easy mock; I have to explicitly add a static import myself and then use it or for that matter may be first use it and then add the import.

This was till I found a feature in eclipse where I can specify my favorites for static imports.

Is there ever a valid scenario to check in commented code?

Unsure about the changes : From my experiences whenever I comment the code it is because I am not sure about my changes for the time being and I want to test them first may be with some of the already existing pieces commented out. This is just to make sure I do not have to write the same stuff back if my changes do not work.

That is Ok to do as long as we realize that commenting out code is very temporary thing and should never cross the boundary of our workspace. If it does and it goes in the version control, then in a way we are doing what version control does for us (by letting us retrieve the older versions of the code).

Two or more scenarios out of which only one is applicable at a time: Make it configurable to pick one scenario at the run time rather then commenting out the valid scenario and uncommenting the invalid ones before each run. It might sound funny as to why people would want to do it this way but believe me I have seen such occurrences and to quote the most frequent is logging.

I will just leave it there commented out till my code is reviewed: Again just make sure it is not breaking the build and check it in. For the worst scenario, version control has the old version which we can always pickup anytime so why keep the dead code around.

I just read about it in an interesting post on code deletion. The Joy of Deletion

Might Help Tip

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 5 in XML document from class path resource [test-jdbc-context.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ‘beans’.

Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ‘beans’.

This happens as a result of using the older version of spring framework while the DTD in the xml files point to a newer version. For example if you have spring.jar of lets say spring 2.0.8 while the xml file points to spring-beans-2.5.xsd

Package Structure

It might get very interesting and tricky to layout the packages, no I am not talking some skeleton directory structure which is generally created when we create a new eclipse project or run maven, it is more about the way packages should be structured to avoid cyclic dependencies.

When we start we start out with a very basic bare minimum structure but it starts to get ugly as code evolves and we start to unknowingly and unintentionally start creating cyclic dependencies.

What are they : Package A depends on package B and package B starts to use a class of package A

Why Not: Hard to maintain code where a change in package A leads to change in package B which in turn might again need a change in package A. So a small change starts to propagate throughout the module or may be beyond. Hard to reuse code as it will not possible be to take out a package and convert it into a module due to high dependencies across packages.

How to measure it: There are certain static analyzing tools which help in finding out the cyclic dependencies and a free and very popular one is JDepend.

If already in it how to get out: Common set of classes spread across packages into a single utility package or may be in a full blown module.

Rule of thumb: Packages should have one-way dependencies

Agile Programming Essentials

Follow YAGNI : It is very tempting to write more code then we really need. Since we are already on it lets build the whole damn thing as we are going to need it anyway and then we soon realize oh it is not just the code but it has to be a properly tested code, well designed, easily maintainable and also might change with the change in future feature requirements. With this we end up comprising the quality of the feature which we were building in the very first place. Why code when you ain’t gonna need it for the task at hand?

Let it DRY : Use and reuse code as much as possible which might be either our own code or available frameworks, tools, libraries. There are different ways of putting it avoid code duplication, DRY (do not repeat yourself). The key to enable laziness is abstraction – being modular, loose coupling, DI, separation of concerns (aspects). Reuse becomes harder with the increase in the size of the component we want to reuse so keep it short.