Alternative to JRebel

The Dynamic Code Evolution VM promises an open source alternative to JRebel that will allow redefinition of loaded classes at runtime!  Exciting stuff if well executed.  JRebel has done wonderful work in this area, it will be interesting to see if this team has anything that compares to the comprehensive support of hot swapping that JRebel does.

I have not gotten a chance to try it but I will and I will  post an update.

Software Patent Defense for the Little Guy

It is no secret that the end of the software patent détente has come. It seems like all of the big players in software are suing each other these days [1].   All of these companies have big budgets for lots of lawyers and many patents with which to threaten each other.  But what happens to the little guy who gets sued or even just  threatened with a suit over patent issues?  Well, considering the high cost of fighting such suits, the risks involved, and the lack of counter-suit options, that business owner generally rolls over and pays a licensing fee to the accuser,whether it is truly warranted or not, or they simply stop the potentially infringing business activity...sometimes the overall business organization survives such a blow, sometimes not.

What if the little guy had a patent portfolio to fall back on, to bring counter-suit to the accusing party or invalidate the held patent with an earlier patent or prior art?  What if the little guy had some legal help on retainer so that a simple threat would no have so much weight on its own?  What if there was a cheap way to patent software that would not only protect the innovator's interests but the interests of all of those in our industry that believe that implementation (protected under copyright) is much, much more valuable than ideas (protected by patents)?

There are over a million software engineers and computer programmers in the U.S. If 15% were convinced to give $30 a month (or their employers) that would be over $50 million a year for operations for such an entity. That is not including other donations that would be solicited, or fees payed by other interested parties such as hardware manufacturers, venture capitalists and the like.

Now will $50 mil. be the death knell for the pro software patent lobby or patent trolls? No, there are some very deep pockets that would fund the other side well, but it is a fine start.  My hope would be that the $50 mil. would mostly go to crushing trolls in court, sucking up tasty patents, building and maintaining a solid resource of precedent and prior art in this area and setting good precedent in the courts and perhaps a bit of lobbying with what is left...mostly, the point would be to give the little guys protection through sheer numbers that right now only the largest companies and organizations enjoy through the size of their tresuries.  A non-profit SMB NATO for deterring the patent-troll menace with its own patent arsenal and defense infrastructure.

So there are patent defense companies like Allied Security Trust, RPX and the Open Invention Network but these are for major players and/or have very limited scopes.

I'd love to see the patent system overhauled.  Bilski gets pretty far into defending folks from the overreaching grasp of bad patents but we could wait for decades for reform and wielding Bilski still requires substantial individual legal investment.  This is just my two cents on some positive action that can be taken today so that we can operate and innovate in an business environment with just that much less fear.

More Groovy Weirdness

I love Groovy.  There is no telling how much time it has saved me in scripting simple tasks.  I do stumble over groovy sometimes though, and it seems it mostly relates to scoping rules.

I am the first to admit, I do not write scripts very 'Groovily'.  It looks more like Java that uses some nice closures when convenient (but, boy are those /really/ convenient).  So I am sure that if I stuck to a more Groove like style I would not run into these problems but today I wrote a simple script.  I put a bunch of variables at the top of the script and ran it and --- Whoops I tripped over a groovy.lang.MissingPropertyException: No such property:  for class exception.

Turns out, in a Groovy script, variables that are not defined within methods /cannot/ have either an explicit type or a def.  This is easy to fix, of course.  Just let Groovy handle the duck typing or turn the script into a class but still, a little surprising.

Running remote command over ssh with Groovy

This post is for those who are searching for how to run a remote command over ssh through a groovy script.  Hopefully it will save someone a lot of searching....spoiler alert:  There does not seem to be a clean way to do this.

It is trivial to run a command on a remote system over ssh, especially if you have keys set up between the machines that are communicating.  Just
ssh user@remote_server command_you_would_like_to_run'.

Things get surprisingly complicated when you want to script this kind of interaction.  I believe that this is because most ssh implementations use tty and it is made difficult by design to use in a scripted environment (and rightly so, since it is a security risk).

I simply wanted to connect to a remote server with groovy and list the files in a known directory.  I was hoping that I could do this with groovy's .execute().text since I did not need to send passwords or anything else because I have keys set up between the machines.  No dice.  I tried the array version of .execute too and still no joy.  What I ended up having to do is to create a simple bash script:

 #!/bin/bash
 ssh user@remote_server 'ls /directory_I_am_interested_in'


which I called ls_script so my groovy line became:


 def listOfFiles = "ls_script".execute().text


I did not like calling outside of the original script but it is quick and it works.

If it makes sense for the overall job at hand, there is a wonderful python library called pexpect .  Somehow this great little library very cleanly bypasses the tty issues I mentioned earlier.

Here is a simple use case of pexpect:


 spawnString = 'ssh ' + thisLogin + '@' + thisIP + ' -p ' + thisPort
 foo = pexpect.spawn(spawnString)
 ssh_newkey = 'Are you sure you want to continue connecting'
 i = foo.expect([ssh_newkey, 'password'])
        if i == 0:
            foo.sendline('yes')
            i = foo.expect([ssh_newkey, 'password'])
        if i == 1:
            foo.sendline(thisPassword)
 foo.sendline(' ')
 data = foo.readline()


Checkout the sourceforge page and http://www.noah.org/wiki/pexpect which I believe is the original creator's site with some nice documentation.

Preparing Images For Transfer Through XML -- step 1) resize the image

I found myself needing to marshal an image for transfer to a REST client on a mobile phone.  The first issue I ran into was that the phones memory is very limited so I had to limit the size of the XML representation of the picture's data before it was sent across the wire.  In short, I had to decide on a size that I needed on the client end and make sure no more than that was sent.  The following assumes .png because it is easier to work with than jpeg in Java (avoiding JPEGImageWriteParam ).


public static byte[] resizeImageForTransfer(byte[] png, int newWidth, int newHeight) throws IOException{
BufferedImage image = ImageIO.read(new ByteArrayInputStream(png));
int oldHeight = image.getHeight();
int oldWidth = image.getWidth();
BufferedImage outputImage = resize(image,newWidth,newHeight);
ByteArrayOutputStream os = new ByteArrayOutputStream();
ImageIO.write(outputImage, "png", os);
return os.toByteArray();
}

private static BufferedImage resize(BufferedImage image, int width, int height) {
  int type = image.getType() == 0 ? BufferedImage.TYPE_INT_RGB : image.getType();
BufferedImage resizedImage = new BufferedImage(width, height, type);
  Graphics2D graphic = resizedImage.createGraphics();
  graphic.setComposite(AlphaComposite.Src); //makes sure graphic is set to Opaque
  graphic.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
  graphic.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
  graphic.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
  graphic.drawImage(image, 0, 0, width, height, null);
graphic.dispose();
return resizedImage;
}


Because of the way JAXB works, it expects a byte array representation of the picture so here we pass in they byte[] of the picture and the desired width and height to resizeImageForTransfer which returns a similar, hopefully smaller, byte array.

The real work is accomplished in resize method.  setComposite uses a basic AlphaComposite -- this is an easy default to choose.  Setting the KEY_INTERPOLATION hint to VALUE_INTERPOLATION_BILINEAR worked nicely with how much I scaled down the images (cutting the area to about a quarter of the original).  KEY_INTERPOLATION is where experimentation might be in order to find a good fit for your app.  VALUE_INTERPOLATION_NEAREST_NEIGHBOR is simple and fast but blocky, and VALUE_INTERPOLATION_BICUBIC is cleaner for most applications but a bit heavier.  KEY_ANTIALIASING might be a worthy area to experiment with but, in general, I like to have it on.