calbazana.com

OK.  I’ve upgraded my VM to the latest and greatest Ubuntu 12.04. It’s pretty snappy and I’m still using XFCE since I still can’t bring myself to like Gnome. One problem that has plagued me this week has been my mouse. My mouse behaves strangely every time I right click. The menu option that appears immediately below the position of the cursor is selected. This drove me insane while working in Eclipse. Imagine that a right click could randomly select “Delete” or “Rename”. Not too good while your coding. I’ve seen countless complaints about this in many versions of Ubuntu, but no solutions:

http://ubuntuforums.org/showthread.php?t=1596928
http://ubuntuforums.org/showthread.php?p=6745430
http://communities.vmware.com/thread/220037

After messing about, I noticed that I have two devices registered:

[acalbaza@ubuntu ~]$ xinput
? Virtual core pointer                    	id=2	[master pointer  (3)]
?   ? Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
?   ? ImPS/2 Generic Wheel Mouse              	id=8	[slave  pointer  (2)]
?   ? ImPS/2 Generic Wheel Mouse              	id=9	[slave  pointer  (2)]
? Virtual core keyboard                   	id=3	[master keyboard (2)]
    ? Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ? Power Button                            	id=6	[slave  keyboard (3)]
    ? AT Translated Set 2 keyboard            	id=7	[slave  keyboard (3)]

If I disabled #9, things work as expected. How irritating, but I hope it helps someone else!

xinput set-int-prop 8 "Device Enabled" 8 0

I’ve been working to get Liquibase into our development process.  If you haven’t checked out Liquibase, you should.  Liquibase is a tool to track and manage database changes.  The idea here is that I want to treat database changes as first class code artifacts that can be revisioned, merged, and monitored.  I store my Java code under source control, where everyone can see, why should my SQL code be any different?  Liquibase addresses this concern as it tracks database change sets and facilitates database refactorings.  In this post, I’ll cover my setup and some of what I went through to get Liquibase in place.

My Setup

Our project is Maven based.  It has multiple Java modules that make up our application.  We have multiple database schemas that we control.  We have additional schemas that we depend on.

Given that Maven is our build tool, I natually wanted to incoporate the Liquibase Maven pluin into the process.  I took the path of dedicating Maven modules to our two schemas that we have direct control over.  This effectively creates two database “projects” which contain the necessary property files to allow Liquibase to work.  Additionally, these modules contain the database changelog structure that Liquibase will use.  I set up Maven profiles to activate these modules during build time.  If they are not present, nothing database related will happen.  By default, these profiles are turned off.

Build Life vs. Command Line

The Liquibase documentation recommends attaching a goal to the process-resources phase of the build.  This works fine in general, but I had a couple of special requirements not really addressed in the Liquibase docs.  First, I want to run Liquibase from the command line using the Maven plugin for any goal exposed by the plugin.  Second, I needed to protect my database credentials on my build server so that they are not encoded in property files that are checked into source control for all to see.

To address the first requirement, I set up my pom.xml as follows:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>foo-parent</artifactId>
<groupId>com.foo.bar</groupId>
<version>1.0-SNAPSHOT</version>
<relativePath>../</relativePath>
</parent>
<artifactId>db-foo-bar</artifactId>
<packaging>jar</packaging>
<name>db-foo-bar</name>
<profiles>
<profile>
<id>db-foo-bar</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc6</artifactId>
</dependency>
<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>get-liquibase-location-props</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<!-- this property file contains a pointer to a file that contains
filter property values for the build environment. this is necessary to handle
different property locations (for example, between local and the build server). -->
<file>src/main/conf/${env}-liquibase-location.properties</file>
</files>
</configuration>
</execution>
<execution>
<id>read-liquibase-location-props</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${location}</file>
<file>src/main/resources/liquibase/${env}-liquibase.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>

<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<executions>
<execution>
<id>updateSQL</id>
<phase>process-resources</phase>
<goals>
<goal>updateSQL</goal>
</goals>

<configuration>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
<verbose>true</verbose>
<changeLogFile>${changeLogFile}</changeLogFile>
<migrationSqlOutputFile>updateOutput.sql</migrationSqlOutputFile>
<driver>${database.driver}</driver>
<url>${database.url}</url>
<username>${database.username}</username>
<password>${database.password}</password>
<verbose>true</verbose>
<expressionVars>
<property>
<name>db-changelog-dir</name>
<value>${basedir}/src/main/db-changelog</value>
</property>
<property>
<name>schema.name</name>
<value>${schema.name}</value>
</property>
<property>
<name>tablespace.index</name>
<value>${tablespace.index}</value>
</property>
<property>
<name>tablespace.data</name>
<value>${tablespace.data}</value>
</property>
</expressionVars>
</configuration>
</execution>

<!-- FOR USE ON THE COMMAND LINE ONLY! -->
<execution>
<id>default-cli</id>
<configuration>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
<driver>${database.driver}</driver>
<url>${database.url}</url>
<username>${database.username}</username>
<password>${database.password}</password>

<propertyFile>target/classes/liquibase/${env}-liquibase.properties</propertyFile>
<!--
<migrationSqlOutputFile>updateOutput.sql</migrationSqlOutputFile>
-->
<verbose>false</verbose>
<expressionVars>
<property>
<name>db-changelog-dir</name>
<value>${basedir}/src/main/db-changelog</value>
</property>
<property>
<name>schema.name</name>
<value>${schema.name}</value>
</property>
<property>
<name>tablespace.index</name>
<value>${tablespace.index}</value>
</property>
<property>
<name>tablespace.data</name>
<value>${tablespace.data}</value>
</property>
</expressionVars>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>

This pom.xml makes use of the Maven’s default-cli execution behavior to instruct an execution that it is coming from the command line and to honor any goals associated with that plugin.  This allows me to run all of the Liquibase goals directly from the command line without having to attach Liquibase to a phase in the Maven build lifecycle.  To run this from the command line, given the pom.xml described above, I need to issue something like the following:

mvn initialize liquibase:<liquibase goal> -P<profile-name> -Denv=<environment>

This gets me to a place where I can kick off Liquibase command, using Maven, directly from the command line.  This opens things up to other developers on my team and allows everyone on my team access to Liquibase from the command line.  Now, to tackle the next requirement, securing database credentials.

Securing DB Credentials

So, I need to protect my database credentials.  Storing them in source control isnt an option.  I need a way to enable my build process to read credentials without my source knowing about them directly.  Again, I leverage Maven to do the work of sourcing properties files that are visible to the build process (anthill in my case) but not to anyone else.  The setup here is that my build server has local directories permissioned such that it, and only it, can read files containing my database credentials.  How can Maven load these files so that it can tie them into Liquibase?  I used additional Maven plugins to do this for me.

If you notice in my pom.xml, I have two executions as part of the properties-maven-plugin.  The first execution loads a “location” property file that is keyed by environment.  Once we have the appropriate location property file for the given environment, a second execution runs that loads the discovered property file.  Additionally, it loads supplemental properties for the given environment that are then used as part of the Liquibase configuration.  As you can see in my pom.xml, the supplemental properties are jammed into expressionVars for use in my changesets.

In my next post, I’ll dig into more detail…

Rocking Gingerbread on my original Motorola Droid.  I’m pretty impressed with the stability, speed, and the smoothness on a 1ghz kernel.  Big ups to Pete Alfonso for the new ROM   Get it at http://goo.gl/HSYPm.

Can’t sleep…  It’s 3:30AM EST and I can’t sleep!  So, I figured I’d write about my recent battles with Maven, Anthill, and Junits.

I’ve recently converted a project from an Ant build over to a Maven build.  The motivation for doing this was that the project structure was starting to get a little messy and the development teams could benefit from having a well defined project structure for future development efforts not to mention dependency management.  While making the conversion, I decided to turn on junit reporting as this is standard practice in any healthy development project.  Since our build environment is backed by Anthill, I needed to emit junit report xml files so that Anthill could dutifully package junit reports for distribution to a mailing list.  I also wanted to have Anthill fail the build if a junit failed or errored out .  Sounds simple right?

Unfortunately, I encountered a few hurdles in getting Maven to play nicely with junits and getting Anthill to play nicely with the Maven way of doing things.  The problem was that:

1. My project is a multi-module structure.  Each time unit tests are run, the junit report xml is dumped into the respective module’s target directory.  Anthill wants report xml aggregated up to a chosen directory.
2. I want my build to fail if a junit error/failure is detected but continue to run.
3. I don’t want to use site:site since this takes forever and generates  artifacts I don’t care about.

In order to achieve my goal, I needed to fall back to Ant tasks.  The Ant tasks that follow simply concatenates the generated junit test results into one file.  After concatenation, I load the file into a Ant properties so that I can search for key indicators of failure or errors.  If these are present, I flag the build as a fail and let this bubble up to Anthill to fail the build.

Anyway… This isn’t the most elegant solution, but it works.  Hope this helps someone.

  org.apache.maven.plugins
  maven-antrun-plugin
  
    
      test-reports
install
      
        




          
          
          
          
          
            
              
            
          
          
            
              
            
          
          
            

                
              
            
          
          
            

                
              
            
          
          
          
        
      
      
        run
      
    
  
  

The turkey has been placed in its brine. Now its time to let osmosis take its course and let flavor flow freely through membrane and tissue until it finds perfect equilibrium. Damn I love the science of Thanksgiving!

Seriously though, it will be nice to stop for minute, breathe, give thanks and reflect on what we have been given. Our family has been blessed this year and I’m happy to celebrate that.

Cheers!

Alejandro

Added captcha to the registration process. Getting tired of the registration emails from .ru and .pl extensions

I spent some time today trying to figure out why my Weblogic domain takes FOREVER to start when running under a Linux virtual machine on my new laptop. I found a couple of things that I didn’t event think to look for. Here they are:

• I run a Ubuntu 10.04 VM on a Windows 7 host. I run Weblogic 10.3 on my VM and noticed that it took a while for my domain to start up. It took anywhere from 5-10 minutes to get to a ready state BEFORE my domain started to deploy. Java uses a randomly generated number to seed its security model. Under Linux, it gets this from /dev/random. This device uses entropy to generate randomness. /dev/random is SLOW because it waits for a sufficient amount of entropy to gather before it generates a random value. While it waits, it blocks. As a result, the domain startup blocks. /dev/urandom on the other hand is non-blocking. Using this as the source from randomness shortens the startup time. Horray!
• My project is on a Spring MVC stack and I use Eclipse as my IDE (anyone who knows me knows that I prefer Netbeans, but when in Rome…). I use OEPE since it plays well with Weblogic (in theory anyway… OEPE is still wonky when it comes to dealing with successive deployments). I noticed that when my domain did deploy, the application context restarted itself from time to time. Why? I really don’t know, but I have a theory. I noticed that Weblogic sets servlet checking to a default value for development mode. I turned this value off in my weblogic.xml file and redeployed. So far, so good… I also turned of page checking. Hopefully this makes Weblogic behave.
• I use JRebel to get hot deployments of code changes. JRebel is nice because it picks up class changes and makes them available immediately rather than having to redeploy (I still can’t believe this isnt the default JVM behavior, but hey…). JRebel phones home during startup and provides usage statistics back to the mother ship. While I am sure that performance isn’t taking a hit over this, its not needed. I turned this off using a properties file generated by the Eclipse plugin.

Now, where does this leave me? Fortunately, I’ve helped get some inertia behind moving projects to a Maven2 model. My goal is to re-organize projects into a Maven structure and leave Eclipse behind fully. This will eliminate the need to bring a bunch of tools to the table when developing as Maven and JRebel play well together. As a side effect, it might be possible to leverage a smaller application container for local development (Glassfish comes to mind). When things are nice and tight, we can promote it to Weblogic using profiles to configure for that environment.

I spent a rainy Sunday rooting my Motorola droid. Nothing too exciting… I patiently waited for the stock 2.1 update to roll out and played with it for a few weeks. Honestly, the updates were pretty unimpressive save for the new gallery. I decided it was time to take the plunge and root, install a custom mod, and overclock. This is just a quick cruise through the process I went through with a list of apps that I’ve installed.

In order to root, I needed to fall back to the stock 2.0.1 install. I decided to flash the device with a stock SBF. This gave me a way to flash back to stock in case something went really wrong. I wasn’t really concered with data loss as most of my important stuff lives on the Google infrastucture and would be available after I reset my phone. I did pull off any pictures from my SD Card and saved them to another location.

After flashing back to 2.0.1. I chose a couple of different ROMs to play with. First, I tried the latest DroidMod. I liked it at first, but things were a bit buggy when I tried to install other apps. Maybe it was the process that I used to update, but it didn’t really play nicely and the market app kept force closing. I wiped my phone and re-applied DroidMod and everything went well. After a bit of hunting, I found ROM Manager. This little app allowed me to choose custom ROMs pretty easily and let me bounce around different ROMs to see which one I liked best. I ended up with the latest cyanogen mod. I picked cyanogen for a couple of reasons. The base mod gave me everything that I liked and the defaults were reasonable. I especially liked the ability to orient the screen 360 degrees. Once I overclocked to 1ghz and things are very smooth. After a day, battery life seems reasonable.

The apps that I have installed:

gTasks – TO DO manager that links up to Google Tasks
Google Maps – Google Maps, what else?
Pandora – Internet Radio
Dolphin Browser – Better browser than stock – IMHO
StopWatch – Simple stockwatch to clock things when I need to.
BuzzLock – I hate ringtones. My phone is always on vibrate.
NoLock – Bypasses the “swipe to unlock” screen.
Twidroid – A decent Twitter client
SlideIt – A swipe to type replacement for keyboard input as the stock keyboard sucks.
Pure Calendar – A calendar widget that integrates with Google Tasks.

Now that I have a nice base image, I am interested in taking a snapshot of my install for restore later; however, I haven’t looked at the backup apps in much detail.

Lots of stuff going on over the passed few weeks. My life is strapped to a roller coaster that has a mind of its own, or so it feels.

Anyway… Soldiering on… I found myself with the need to work with a bit mask today, or so I thought at first. I wrote an email sender that I wish to control through configuration. Basically, I want emails to be sent in production; however during development, I want to log them to a file, a database table, or all three. My first instinct was to knock up a bit mask similar to:

Original enumeration…

public enum MailSenderBehavior {
   NONE = 1 << 1,
   SEND = 1 << 2,
   LOG  = 1 << 3
}

You get the idea... But a second look at the Java language turned up EnumSet. MUCH simpler to put together and code against than the old school bit masks. Nice!

New enumeration...

public enum MailSenderBehavior {
	NONE,
	SEND,
	LOG,
	STORE
}

Adding behaviors....

        final EnumSet<MailSenderBehavior>  behaviors = EnumSet.noneOf(MailSenderBehavior.class);

        behaviors.add(MailSenderBehavior.valueOf("LOG"));
        behaviors.add(MailSenderBehavior.valueOf("SEND"));

        System.out.println(behaviors.contains(MailSenderBehavior.LOG));    // true
        System.out.println(behaviors.contains(MailSenderBehavior.SEND));  // true
        System.out.println(behaviors.contains(MailSenderBehavior.NONE));  // false

The properties value in my properties file... I simply split the list on a delimiter, create enums of them, the add them to the EnumSet.

SMTP.sendBehavior=LOG,STORE,SEND

The usage...

		try {
			// log for behavior
			if(behaviors.contains(MailSenderBehavior.LOG)  || behaviors.contains(MailSenderBehavior.STORE)){
				logNotification(id, model, result, behaviors);
			}
		} catch (MailException e) {
			logger.error("An unexpected exception has occured while logging notification.",e);
			this.getExceptionBuffer().add(e);
		}

		try{
			// send for behavior if prepared successfully
			if(behaviors.contains(MailSenderBehavior.SEND) && this.isPrepared()){
				((JavaMailSender)this.getMailSender()).send(  ((MimeMailMessage)result).getMimeMessage());
			}
			this.setResult(MailSenderResult.SEND_SUCCESS);
		} catch (MailException e) {
			this.setResult(MailSenderResult.SEND_FAIL);
			logger.error("An unexpected exception has occured while sending notification.",e);
			this.getExceptionBuffer().add(e);
		}
	}

Kinda neat...

This week, I’ve been looking at Git. Git, if you don’t know, is a distributed version control system. I really like Git for one reason – local branches. I really, really, really, really, like the reality of having a local branch that I can commit to without having to go across the network. I’m stingy. I like my own sandox of code. I like working with my own snapshot of a source tree to do whatever I want with it. If my changes are good, I can commit them back as a coherent change set. If they suck, I can roll them back and no one will ever know what I was up to. The reality of local branches gives me the ultimate in flexibility.

I was once in pretend land where I though that SVN gave me the same flexibility. However, I needed to create branches on the repository, then check the branch out, then switch to my newly created branch, then check my changes back into the newly created branch. Finally, I need to merge between branches. This is okay for changes that are long lived (more than a few days at least…). For example, I’ve worked on stories that span more than a few days. Since I like to experiment, I would branch the trunk and work on something experimental, then merge in my changes with the trunk. This is status quo for SVN users. Textbook examples of using branches…. When I was satisfied with my work, I would merge my changes back into the trunk and life would go on. Life was good, so I thought…

The problem is that branches are expensive in SVN. I need to do a lot of work to materialize a branch. It’s also visible to everyone. What if I wanted to work out something non-trivial? Does everyone need to know that I’ve branched the trunk to work on story “xyz”? Further, I need the network to branch. I can’t do it without a connection to the repository. Kinda sucks if I’m on a plane or at Starbucks with a crappy wi-fi connection!

What if I’m working on a team with several developers on the same feature? I need to commit back to the mothership (SVN repo) in order for my changes to be visible to other committers. What happens if I only want to work with a subset of the team on a specialized sub-feature? The very nature of commit -> publish -> update model disallows this.

So… Where does this leave me? Well, I can’t shift the organization to a git repository. That would require me swimming upstream. There are way too many SVN users in the crowd and I think I’m the only one who would entertain git for practical usage at the moment. Perhaps there are others, but I haven’t heard any rumbles.

I’ve retreated to wrapping my mind around git and the integration with SVN (git-svn). So far, the learning curve is rather steep. Specifically, I’m having trouble wrapping my brain cells around gits ability to rebase. I’m pretty satisfied with happy-path workflows using git and svn. However, when I get into conflicts or I need to re-examine my git index, I get into la-la land. I’m much more comfortable than I was last week; however, I’m still not confident in my git skills.

The take away… Local branches are the right way to go. There should be no reason why I need to connect up to the repository to do feature work, experimental work, or hot fixes. In my opinion, the very nature of software development requires that code should fork from a stable basis in order to evolve. It doesn’t have to follow lock step with a repository commit in order for it to be useful. Once changes satisfy a need, they can be committed back to the mothership.

Git speaks to my heart when it talks about local branches and I’ve been looking for such a workflow for some time now. SVK seems to support local branches with the promise of speaking SVN, but its still SVN under the covers. If I’m going to exhause brain power on managing local branches, I might as well commit to a tool that does it as a cleanly as git.

Bottom line… Git is the new hotness for me. The learning curve is steep and its going to take me some time for feel as comfortable with it as I do SVN. SVK is a non-starter for me. If anyone has a decent workflow for git-svn, let me know… I’d be interested in trying it out. Also, if anyone knows of any other tools that let me whip off local branches for later commits back to a repository, let me know. I’ve found none thus far – other than bitkeeper, but Linus already told me that