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>

 


Jul 26 2013

GWT SuperDevMode Compile Button Missing

So you are trying out SuperDevMode on your GWT project, but you’re getting the bookmarklet popup without a compile button? Boo.

Selection_021

If you’re like me, can’t sleep and decided to attempt SuperDevMode at 5:10AM, then you might not have read the official documentation that well. Luckily there is a more detailed write up that will admonish your insomnia addled pate. You see, you’ve almost made it, but forgotten to enable SupperDevMode in your project’s module.gwt.xml file. Just add the below and you’ll be off to the races.

 <!-- For local work, use Super Dev Mode -->
 <set-configuration-property name="devModeRedirectEnabled" value="true"/>
 <set-property name="compiler.useSourceMaps" value="true" />

Ah, that’s more like it!

Selection_022


Apr 12 2013

Pebble SDK Shipped!

Finally, a rough alpha SDK is in the wild without the hindrance of an NDA.

www.isPebbleSDKShipping.com

and its API have been updated accordingly.


Apr 7 2013

Disable JavaScript validation in Eclipse

Ever seen this gem before popup when working on a Google Web Toolkit project?

"Errors occurred during the build.
 Errors running builder 'JavaScript Validator' on project 'com.your.project'.1"

Here is the trouble. Let’s say you’ve not marked your target/ directory as derived, so that the GWT Eclipse plugin can launch DevMode from there. Since Eclipse can see these files, it will try to validate that compile, minified JS that GWT created and sometimes die. You don’t want this.

So, disable JS validation on your GWT project since the GWT Compiler will take care of that validation for you. Just visit:

Window > Preferences… > JavaScript > Validator > Errors/Warnings and uncheck the box.

Selection_004