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
 */
@Singleton
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() { 
            History.addValueChangeHandler(this);
    } 

    @Override 
    public void onValueChange(ValueChangeEvent<String> event) {
    	
    	// only store max elements
    	if(stack.size() > MAX_LENGTH) {
    		stack.remove(0);
    	}
        stack.push(event.getValue()); 
    }

    @Override
    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);
		    i++;
	    }
	    return arr;
    }

    @Override
    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 {

	@Override
	protected void configure() {
		
		bind(HistoryStack.class)
			.to(HistoryStackImpl.class)
			.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:

Jenkins…

  • 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

noNappi
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() {
        super();
        log("Parent: Constructor called");
        doSomething();
    }

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

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

    protected static void log(final String msg) {
        System.out.println(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() {
        super();
        log("Child: Constructor called");
        doSomething();
    }

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

    @Override
    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:
snapshot5
$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.

snapshot6

Conclusions

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.


Aug 6 2013

Mockito Fails to Inject Autowired Dependency

If you must test Spring beans and you’ve used @autowired in them, then you’ll need to use Mockito.

EasyMock is easy for easy things, but breaks down in this more complex situation. No worries, just let Mockito inject those DI’d dependencies for you. Ugh oh… they are not injecting. But you’ve read their docs and they should inject! Sadness.

Let’s set the stage, enter our sample class stage left.

public final SampleImpl {

    @autowired
    private Foo someFoo;

    private Bar someBar;

    public SampleImpl(final Bar someBar) {
        this.someBar=someBar;
    }

    public final void doSomething() {
        someFoo.doSomething();
        someBar.doSomthing();
    }
}

Here is a typical test for it, that will fail because someFoo is NULL as it was never injected.

public class FooClassTest {

    @Mock
    private Foo mockFoo;

    @Mock
    private Bar mockBar;

    @InjectMocks
    private SampleImpl sampleImpl;

    @Before
    public void initMocks() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void testFooImpl() {
        // setup
        when(mockFoo.doSomething()).thenReturn("foo works!");
        when(mockBar.doSomething()).thenReturn("bar works!");

        // test
        sampleImpl.doSomething();

        // verify
        verify(mockFoo).doSomething();
        verify(mockBar).doSomething();
    }
}

Now change this line of the test and you’re back in business.

    @Before
    public void initMocks() {
        // must instantiate and then initiate since not using no arg constructor
        sampleImpl = new SampleImpl(mockBar);
        MockitoAnnotations.initMocks(this);
    }

As far as I can tell, if you’re not using a no-arg constructor, Mockito, which would normally instantiate the class to be injected with mocks, and then inject them, assumes you want constructor injection only and ignores the remaining @autowired dependencies. Hope it helps someone. ;)


Jul 27 2013

Caused by: java.lang.ClassNotFoundException: org.apache.ibatis.mapping.DatabaseIdProvider

Perhaps you’ve had this trace recently while trying to get myBatis working on Spring:

 Caused by: java.lang.ClassNotFoundException: org.apache.ibatis.mapping.DatabaseIdProvider
 at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
 ... 57 more

It is the bane of open source. You can’t always depend on quality releases. Don’t worry, you followed the tutorial correctly. Let’s take a look at the package’s history in Maven Central.

Selection_023

Maybe something is not quite right with 1.2.0? Let’s try using 1.1.1 instead.

Bingo! That did it. Just stay away from 1.2.0. Hope that helped someone.

But what else could we do to use the newer build? Just use the new dependency, which the project’s site sadly has incorrectly listed.

 


<dependency>
 <groupId>org.mybatis</groupId>
 <artifactId>mybatis</artifactId>
 <version>3.2.2</version>
 </dependency>