Oct 12 2014

Using Immutable Objects with MyBatis

Immutable is Beautiful

I’m a fan of immutable objects. We all know the benefits; simple, no mutators, thread safe, cache word optimizable. However, I see far too many MyBatis (and iBatis) developers adding no arg constructors to their POJO’s simply so that MyBatis can reflect and set all of the values into the field setters. I’ll ask “why does this POJO need to be mutated” and they quip that it doesn’t, but these setters and protected no-arg constructors are needed by MyBatis. This violates my principle that you make your library work with your code, not the other way around.

Given the lack of good documentation on immutable objects in MyBatis, I hope the following helps folks.

Example Implementation

We need a ResultMap that will tell MyBatis how to map this to a constructor. This is because Java reflection only exposes the constructor parameter types and order, not the names of the parameters (so claim the MyBatis docs, though Spring somehow manages to do this with bean constructors…).

The mapper maps the column names returned in the query to the types on the constructor. It also lays out the order of the arguments. Make sure the constructor argument order exactly matches that of your POJO.

Note: underscores before types map to the primitive value. _long maps to the primitive long type. long maps to the wrapper type java.lang.Long.

<resultMap  id="fooViewMap" type="com.lustforge.FooView">
		<arg column="id"			javaType="_long"/>
		<arg column="is_dirty"	javaType="_boolean"/>

Now make sure your query block points to the mapper via its resultMap attribute. Again confirm that the column names returned exactly match those in the map. Note: the order does not need to match for the query.

<select id="getFooViews" resultMap="fooViewMap">

		FROM foo
		-- your query here

Finally make sure your POJO constructor matches. It’s also a good idea to leave a note to future developers to update MyBatis if they alter the constructor argument types or order.

public final class FooView {

	private final long id;
	private final boolean isDirty;

	// Prescient comment
	// NOTE: MyBatis depends on parameter order and type for object creation
	// If you change the constructor, update the MyBatis mapper
	public FooView(long id, boolean isDirty) {
	    this.id = id;
	    this.isDirty = isDirty;

	public long getId() {
	    return id;

	public boolean isDirty() {
	    return isDirty;
	// ... don't forget equals/hashcode and toString as well

That was easy and now you’re using best practices. Pat yourself on the back and get busy with your new immutable POJO.

Oct 4 2014

PreRelease: Open ICAO 24 Database

I’ve long been a fan of aviation. When sites like FlightAware came out, I was a huge fan to learn about the contrails around me.  I was even more excited when the revolution in RTLSDR enabled everyone to track ADS-B enabled aircraft for $10.

Sometimes outside on a run or drive, I’d see a high altitude contrail do a 180 and wonder, what just happened? In 1998, short of calling the FAA, you’d never know. Jump to 2014 and you can look up the track on FlightAware or FlightRadar24 (et al) and then pull the ATC tape via LiveATC. Information is becoming freer and freer! That’s the information revolution of the Internet at work.

Imagine my chagrin when running dump1090, realizing there is no freely available database of ICAO24 hex codes to aircraft registrations! Crawl the forums and you’ll find discussions about reverse engineering pay products to extract ICAO 24 codes. Some forum members have even manually amassed spreadsheets of hundreds of thousands of codes and insist on keeping them close to their vest. Others, like AirFrames.org have databases, but rate limit lookups and forbid high transaction rates of lookups and automated usage. Why?

Information Wants to Be Free

The Open Source Software revolution is predicated on the work of a few contributors enhancing the lives and experiences of the whole. People contribute their time to make code that will benefit the public many fold more than what the contributors put in. Software engineers love to do this since it provides the code that drives the internet (i.e. Linux, Apache, BSD, Nginx, Android, etc…) and massively increases the productivity of a single developer because she can freely leverage the high quality works and tools others have made.

So then, why does the ADS-B and aviation hobbyist community not band together to solve this common problem? Why do they resort to reverse engineer paid products and make private exchanges of hex codes through back channels? Partly because there is money to be made and partly because people feel the need to protect the information they’ve collected. However, the reality is that ICAO24 hex codes and airframe registration numbers are public information. This public information can be found in public registries and is being broadcast continuously into the ether 24/7 in the form of ADS-B and ACARS messages. By definition of US copyright law, assemblies of public facts cannot be copyrighted, so the should rightly be set free.

Open ICAO 24

The Open ICAO 24 database shall be an assembly of all the 24 bit hex codes, tail numbers, and aircraft types that I can assemble with my east coast ADS-B/ACARS network that is presently in the buildout phase. Given the small number of codes and tails in the world, operation of such a database and API will be a rounding error down to zero and shall remain freely available. The entire database will also be freely downloadable to anyone and the XML/JSON API will allow instant lookups and any needed frames.

Stay tuned, the beta will be launched shortly and I’ll work to automate it’s population. However, my present physical plant can only process a few thousand registrations per day, so I invite the community can embrace such openness and contribute as well, so the entire ADS-B enthusiast community can benefit from the worldwide network and the efforts of the community members.

Aug 26 2014

Accessing the GWT History Stack

GWT (Google Web Toolkit) does not supply a direct way to know where users have been within your application. However, you can use a simple listener and stack to record and access history events.

The key is the GWT History object. You can listen to its change event to know the user has gone to another Place. The restriction is we don’t know when the user has gone back. This is an inherent state detection problem in the stateless HTTP web. Ideally, it should not matter to your application how a user arrived at the given Place.

We’ll start with an interface to define our new class’ contracts. There is a 16 step limit since we don’t want to keep filling memory with history locations. I’ve added a method to get the last 16 and to get the last place as well.

 * Stack that tracks browser history interactions
public interface HistoryStack { 

	 * Get up to the last 16 history events. 0 index is the last visited.
	 * @return
    String[] getStack(); 

     * Return the last event, if any. Is not the current place, but current -1
     * @return NULL if no history
    String getLast();


Now for the implementation. Oddly, since we cannot track back events, we can’t really use this as a stack, but rather are placing Places in a fixed size queue. Instead than switch to a queue, I’ve stuck with a stack, which is the classic structure for this use case. Folks might get confused if they saw a “HistoryQueue.”


 * Create a stack that updates as we navigate, tracking history
public class HistoryStackImpl implements HistoryStack, ValueChangeHandler<String> { 

    private static final int MAX_LENGTH = 16;

    private final Stack<String> stack = new Stack<String>(); 

    // Instantiate via Gin  
    protected HistoryStackImpl() { 

    public void onValueChange(ValueChangeEvent<String> event) {
    	// only store max elements
    	if(stack.size() > MAX_LENGTH) {

    public String[] getStack() {
	    // reverse stack so first entry of array is last visited
	    // return defensive copy
	    final String[] arr = new String[stack.size()];
	    int i=0;
	    for(int n=stack.size()-1; n>=0; n--) {
		    arr[i] = stack.get(n);
	    return arr;

    public String getLast() {
	    // null no prior location
	    if(stack.size()<2) {
		    return null;
	    return stack.get(stack.size()-2);


Finally we’ll tell Gin to ginject this into our application for use, starting it up when the app loads.

public class MyClientModule extends AbstractPresenterModule {

	protected void configure() {
			.asEagerSingleton(); // history from startup


Now that was easy. Just inject your history stack into any presenter than needs to make history bases decisions. In my case, I had a user setting editor. I wanted the “Done” button to go back to the Place the user was last on so they could continue their work there, or if they started the app on the Settings page, to take them to the home page. This hack fit the bill perfectly. I hope it does the same for you.

P.S. I must give credit to dindeman for the initial revision.

Aug 21 2014

Jenkins vs. Teamcity – The Better CI Tool

Let’s dispel the myth about Jenkins being the gold standard continuous integration tool. I’m sorry, TeamCity is much better. 

Dispelling the Jenkins CI Myth

I started using Jenkins when it was called Hudson, before the Oracle naming spat. Recently, I downloaded and installed it again and was shocked to see that little appears to have changed in so many years. What’s in a UI? Not much if you’re technical, but geeze, Jenkins still has the aura of an app knocked together during an all night hackathon in 1997 .

Let’s knock the legs from under this myth.

1. Jenkins is Open Source

Many Jenkins fans are FOSS fans. If there is an open source solution, regardless of how buggy or poorly maintained, these individuals must use it. Much like one can imagine RMS forgoing a life saving treatment if the medical apparatus didn’t run open source code he’d compiled himself.

Be careful though, as many supporters of this myth are mere turn coats. The same CIO that champions Jenkins as the company standard because it’s open source chooses Windows as the company’s desktop platform and Oracle as their database tier. Sure it’s open source, but does that make it best tool for the job?

2. Jenkins is FREE!, TeamCity is Expensive

The Jenkins fan will note that Jenkins is free, but TeamCity costs money. Hiss! Boo!

They’ll not mention you can use the TeamCity CI server and three (3) build agents for FREE. And that you’re only out $100/agent thereafter and $1000 for the CI server. Anyone bought Visual Studio lately? Anyone use the many $5K/seat tools out there? Anyone…use Windows (Debian lover myself) ? They all cost a ton more than Jenkins. Why do you use those rather than the FOSS solution? Perhaps it’sf or the quality of the tool or the paid support behind it. Remember, many of use work for profit.

3. We’re an OSS Project, We Can’t Afford Paid Anything

I’m a huge fan of open source projects. I contribute to several. And I frequently spar over what CI tool to use. CloudBeesBuildHive, Travis or your own Jenkins Instance? Fatuously such groups write off TeamCity since it would cost cheddar they don’t have. But that would completely ignore the fact that JetBrains gives away everything for FREE to open source projects.

4. But There’s a Plugin For That!

My first production encounter with Jenkins was a comedy of errors. The team I joined had a mature Jenkins install, but all of quotidian tasks were either manual or cumbersome. For example, hand written jobs to do nothing but free up space from other jobs. Hacks and hacks and duct tape scripts to make the build chains we used. And throw in a monthly inopportune crash for good measure.

I was aghast. Everything folks had wasted their time on via various scripts and manual efforts was a standard, default, out of the box feature in TeamCity. But stand back if you ask a Jenkins fan about this. They will recant “but there’s a plugin for that!” Perhaps there is. A non-code reviewed plugin that does part of what you want and was last updated 19 months ago and a few major releases hence. Or, there will be three plugins to do almost the same task, and most of it might work, but check the GitHub page and recompile if you want that functionality.

This is sad given that the configurations TC has out of the box could have skipped $10K in developer efforts over the last two years. But, you know, TC isn’t FREE!

Other Bones to Pick

Some other things that Jenkins could correct to burnish their product:


  • NO SECURITY by default? Why? TC secures out of the box. Common man.
  • No PreTested Commit – a TC standard that’s integrated with Intellij/Eclipse – Jenkins no intention to add
  • Defaults to port 8080 … way too common a port for DEV’s. Will conflict with all Java devs
  • Startup logs are to .err.log? Why?
  • Lack of timestamps in 2 of 3 logs
  • Plugin install still triggers server restart, even if no plugins were updated/installed
  • Coarseness of “Auto-Refresh” – keeps reloading documentation pages! Is it 1998? XHR Anyone?

Conclusions and Disclaimers

Give TeamCity a try. I’ve been loving it for 4 years now and use it on every project. Do I work for JetBrains? Nope. Then why write this? Because everyone I talk to claims Jenkins is God’s gift to integration. It makes me think I’m must be taking crazy pills, so I’ve written this so someone out there can make a more informed CI tooling decision.


Don’t Take My Word For It

For all your know I’m a shill that screams at fire hydrants in the night. Read the top hits for “TeamCity vs Jenkins” and you’ll discover the same thesis.



Aug 2 2014

Ringing the Cygwin Terminal Bell

Let’s say you’ve sadly been running several processes in a row. They take time, so you catch up on your blog reading while they run, but have to keep checking back on the terminal to see if they’re done. Wouldn’t it be nice to know when a command is complete? Easy, just have it ring the Cygwin Terminal Bell!

For example, download a big file, untar it, and let me know when you’re done:


wget fatFile.tar.gz; tar -zxvf fatFile.tar.gz; echo -e "\a";


So, be sure to \a to ring the bell from now on:

echo -e "\a"

Jun 12 2014

Restoring the Chrome GWT DevMode Plugin

Did your DevMode Chrome extension stop working recently? Welcome to the party. The powers of divine wisdom on the Google Chrome team decided that NPAPI was a superannuated security hole and must die. The fact that they proposed no clear alternative solution has led many a plugin (Java, GWT DevMode, Linx Garmin Connect, VDPAU, GNOME Shell Integration, VMware VSphere Client, Nemid) to wither and die. But what about Flash!! Well, to keep important plugins from being impacted, they’ve been whitelisted, but for the rest of us who depend on the Chrome DevMode Plugin… too bad.

The timing is unfortunate, but the number of Linux users that require NPAPI plugins that aren’t Flash is just too small to justify this effort.

-Matt Giuca

To boot, the aforementioned plugins “could be rewritten” from scratch in javascript, just for Chrome, using the various new API’s, but it will be a swift death blow for many an OSS plugin where no one has the time to completely rewrite the project. Will a phoenix rise from the ashes? Certainly. It will be an opportunity for many to reinvent the wheel using toothpicks. However, in the mean time, many of us will be without wheels, especially in the Google Web Toolkit dev community.

Retrograde GWT Plugin Install

You’ll need to revert to the less secure Chrome 34 build. Generally speaking, this is a bad idea, so be careful with this. Don’t do things requiring security on it. Sadly, the Chrome team has left us little choice, while also saying you shouldn’t do the above ;) .

  1. Download and install the Chrome 34 Portable Installer (has no updater)
  2. Reenable drag and drop install of disabled .crx extensions
  3. Install GWT Chrome extension from the Chrome Web Store

Hopefully that works for you. Now you can continue developing GWT until Chrome adds more road blocks, but you should really consider moving to SuperDevMode. If you’re keen to help, please contribute to the SDBG Eclipse Dev Mode replacement project.

Mar 16 2014

Subdomain SSL Certificate Verification on Route 53

Sadly a GoDaddy User

I use GoDaddy for a few domains and some SSL. Every time I need to set something up, it is like pulling teeth. First you’ve got to get through four layers of sales pitches, cross sells, and upsells. Then you finally get to the admin UI’s. Not the UI, the UI’s. Each one of them appears to have been designed by team with a different design philosophy. To boot the doc’s appear to have been written by someone that never actual used the UI they’re prescribing the use of.

SSL Domain Verification

Here’s the problem. You’ve got 2 domains to issue SSL certificates on. Let’s say

  • foo.com
  • staging.foo.com

According to the doc’s you need to put a TXT record on “dzc.” + your domain. OK, so that would be

  • dzc.foo.com TXT=”fooVal1″
  • dzc.staging.foo.com TXT=”fooVal2″

Great, looks good. What? Why is it that only one SSL domain is validated and the cert issued? We’ll, it’s your fault for following the directions.

The rub is that all subdomain TXT values must be placed on the root domain. Awesome. Does everyone in control of a subdomain have control of the root? Certainly not. Hopefully you learned this by trial and error.

Hope it Helps

I’ve jotted down these little ditties as time and time again, I have to experiment with GoDaddy settings as following them to the letter rarely works. GoDaddy, please read your own docs!

Feb 8 2014

Don’t call non-final methods from your constructor, please.

I ran into problems with someone doing this recently, so I’ll have to embellish the web a little more. The world must learn.

Why don’t we call non-final methods from constructors? Because it’s bad. Why is it bad? Because OO has an order to the madness and this ain’t the order. Let’s do a quick experiment to find out why.

Here is our parent and child class.

public class FooKlassParent{

    static {
        log("Parent: Init static block 1");

    public SysWriter w1 = new SysWriter("Parent: non-static field init");

    private static final SysWriter w2 = new SysWriter(
            "Parent: static field init");

    public FooKlassParent() {
        log("Parent: Constructor called");

    static {
        log("Parent: Init static block 2");

    public void doSomething() {
        log("Parent: do something");

    protected static void log(final String msg) {

So many goodies! Static blocks, static fields, non-static fields, non-static methods. Yum. If you’re programming Java and don’t know the order these all fire in, please switch to PHP.

Now we’ll extend with a child who is essentially the same.

public class FooKlass extends FooKlassParent {

    static {
        log("Child: Init static block 1");

    public SysWriter w1 = new SysWriter("Child: non-static field init");

    private static final SysWriter w2 = new SysWriter(
            "Child: static field init");

    public FooKlass() {
        log("Child: Constructor called");

    static {
        log("Child: Init static block 2");

    public void doSomething() {
        // shame, you didn't call super.doSomething() first!
        log("Child: do something");

Ok, now everyone pick up your pencils and write what will be the output of making a new FooKlass.

Parent: Init static block 1
Parent: static field init
Parent: Init static block 2
Child: Init static block 1
Child: static field init
Child: Init static block 2
Parent: non-static field init
Parent: Constructor called
Child: do something
Child: non-static field init
Child: Constructor called
Child: do something

Alright, so what did we learn? Things don’t “just happen” – Java operates by the JSR which is painfully specific here. The firing order is:

  1. Parent static blocks and fields in order of appearance
  2. Child static blocks and fields in order of appearance
  3. Parent non-static field initializers
  4. Parent constructor
  5. Child non-static field initializers
  6. Child constructor

Damn! That’s mind blowing! The child’s constructor calls super() but super() was really called before the child’s constructor. WYSINWYG. The byte code ain’t the code you wrote folks.

Now, to conclude, why are non-final method invocations from the constructor bad? The child class’s fields are not initialized yet. It’s state is not yet prepared. Even though we see the parent’s method, it’s been overwritten with the child’s byte code. Unholy things can happen now because your assumptions are no longer correct. And worse, it’s not just your assumptions, but someone might extend that lib/API class non-final public method and mayhem will ensue, at 3AM, on Christmas Eve, when you’re on the support rotation and as you rub your eyes and stare into the debugger it just ain’t going to make sense to you.

Don’t do it.

Feb 5 2014

MyBatis Query Optimization : Dollar Sign be Damned

I discovered a shocking truth today. We use MyBatis on my current project for read only queries. Recently we had a cache populating job that ran rather slowly. We optimized and optimized cleaning up the queries and adjusting the database indexes and statistics tables. Try as we may, the job still required 30+ minutes each day.

Miraculously the job dropped to 3 minutes yesterday. It must be broken! Check the logs! Alas, all of the outputs were correct. To the source control, what changed?

... where id = ${id} ...
... where id = #{id} ...

A dev had correctly fixed their query to use an octothorpe rather than dollar sign, since $ is an SQL inject inviting anti-pattern in MyBatis. However, $ also makes the query DML dynamic and as such MyBatis and subsequently Oracle never cached the query and the execution plans, instead recalculating them each time.

So, yet another reason to never use $ in MyBatis. I’ve searched for a way to disable it in MyBatis, but haven’t seen a flag yet. Shout out in the comments if you know a way. :)

Nov 16 2013

AWS EC2 Spot Market Volitility

The spot instance market does not often make sense. You first learn of it and think “Wow! Why did I waste that money on a reserved instance when I can get the same price on demand?!?!?!” Then you see pricing curves like this:
$6/hr for an instance!? 5000% markup! That is stultifying. This (m1.medium) is a perfectly fungible resource. You can

  • Pay on-demand rate of $0.12/hr
  • Reserve it for 3 years and pay a combined rate (amortizing down payment) of $0.042/hr
  • Rent it at the median Spot Market rate of $0.013/hr

$6/hr is 30% more than that most expensive instance AWS sells (hs1.8xlarge, $4.60/hr), and this instance is puny by comparison.

So, what gives? Are there really people that are so gormless they shovel money to Amazon? Impossible. Perhaps one foolhardy API consumer put in too high a bid, but we’re talking a $6 market clearing price. That means the entire market is going for $6. You can’t get any instance for less. Also note that the price is always going to $6 in a step function, while in a real market, with sentient traders, we’d expect to just barely outbid our competitors as anything else is waste. You don’t see people winning an auction by 5000% do you? You pay $0.01+ and call it a victory.

The only explanation is that during these hours Amazon (or someone with money to burn) is shutting down the market. They don’t want the spot pool available, perhaps for maintenance reasons or some internal load shaping. Regardless, it renders much of the market useless and highly inefficient.

Other Observations – Highly Non-Correlated Market Demand

Markets are often correlated. If the price for beer in a 1 liter container is up, we’d expect to see a similar rise in demand for beer in the 2 liter container. However, demand for compute is oddly inconsistent across regions, zones, and instance type.

  • Highly different demand between Availability Zones (i.e. us-east-1d is low, us-east-1c is high)
  • Highly different demand between instance types (c3.large low, m1.medium high)

If the price for work in one AZ is much higher than another, near by AZ, we’d expect to see work migrate there. Sure, some jobs might need very high intra-AZ networking speeds, but most can (and should) be spread across AZ’s. In the 3 months of data analyzed we see notable spot price disparities between neighboring zones.

Instance demand is also illogical. For example, why is the c3.large instance, which is far better than a m1.large instance, always available for $0.032/hr? Over the last three months, there is not a spike to be seen. This makes the average clearing price for a c3.large ($0.032/hr) 97% lower than an m1.medium ($1.26). That’s odd, given this is a compute node, which you’d expect to see large number being recruited and released for brief computation cluster bursts. For your shillings, you’d likely be better with a c3.large than a m1.medium, but the market data does not indicate consumers realize this as the price for c3.large instances is a flatline.



AWS originally marketed the spot market as allowing you to run work at different times. But, you should also ask yourself

  • Do you need an on-demand instance when a spot will do?
  • Do you really need your spot in the same AZ or region?
  • Can you run your AMI on a different instance type?
  • Will someone manipulating the market price, pushing it beyond reasonable viability?

Now if only EC2 would let bid across a range of instance types to run your jobs, folks could get more done with less.

P.S. These are just some observations from poking around the data a couple minutes. If you’d more piercing insights, please elaborate below.