Project Euler - Problem 19 - JodaTime Rocks

Problem 19

How many Sundays fell on the first of the month during the twentieth century (1 Jan 1901 to 31 Dec 2000)?

This really feels like cheating, but the very simplest way I immediately thought to solve this was using Joda Time.

Joda Time is a wonderfully written Java library, that replaces the need for the both inept and ugly mess that is java.util.Date and java.util.Calendar. Joda Time is so good that it is the basis on which the new Java 7 Date and Time API will be built (see here).

Here's my solution in the typically oh so long winded Java:

DateTime date = new DateTime(1901, 1, 1, 0, 0, 0, 0);
DateTime end = new DateTime(2000, 12, 30, 0, 0, 0, 0);
   
int numberOfSundays = 0;
   
while (date.isBefore(end)) {
  if (date.getDayOfWeek() == DateTimeConstants.SUNDAY) {
      numberOfSundays++;
  }
  date = date.plusMonths(1);
}

Short, simple, expressive. Thanks Joda Time.

Liquibase

Following from my previous post, I've continued to try out Liquibase, a database refactoring/migration tool.

I'm becoming increasingly impressed with Liquibase. Not only is the framework very well documented (including demo videos) but I'm increasingly seeing the benefits it provides.

At work we're pretty much an "always branch" team. We work at the mercy of the business who often will push deadlines on certain parts of a release back, or try and bring them forward. A consequence of that is the high SCM maintenance overhead, which is done by me. We only rebase (merge out from trunk) when trunk is updated, which is only done after a release. This means that two branches can end up fairly incompatible fairly quickly.

Rather than turn this into a post on SCM, I'll refocus and say that database changes from one branch are not pushed to other active development branches until that branch is released. Our big problem is that since there is not formalized database migration process, the released branch's database changes are typically not applied to the test server for the branch still in development. The development branches only finally work with the previous releases database changes when the dev databases are refreshed from production (obviously containing the previous releases changes.) This is further compounded by our lack of across the board automated testing, and that the production refresh typically happens when a branch is moved to systems or user testing (not when you want to discover a tonne of error messages.)

If we were using Liquibase when the released branches changes were merged to the dev branches via trunk, the changes would automatically be applied by the Liquibase framework when the dev branch was built/deployed (depending on the build configuration.) This is because Liquibase keeps track of the change sets it applies through a unique id, author, file combination, so only the new changes would be applied. Ignoring the SCM practice being somewhat of the root cause here, at least Liquibase reduces the manual overhead of keeping track of the changes and applying them.

It's all quite impressive, but I still feel like I've barely scratched the surface.