Friday, February 3, 2012

Use of com.google.appengine.repackaged may result in your app breaking without warning.

I got this nasty error on the repackaged version of Base64 after upgrading to app-engine 1.6.1 on a project:

Use of com.google.appengine.repackaged may result in your app breaking without warning.

You can make it go away by switching to org.apache.commons.codec.binary.Base64, that can be found on the commons-codec library. Mapping of the encode/decode methods is pretty straightforward:
  • encode --> encodeBase64String
  • decode --> decodeBase64
Or something like that.

Tuesday, January 24, 2012

The never-ending dilemma: Easy VS Right

If you're a software engineer, countless times you have been in situations where you had to choose between the easy way and the right way to solve a given problem. 

Every experienced hacker knows that the right(eous) way will probably spare you some trouble in the long run (and probably will help you sleep at night too), but the same experienced engineer is also familiar with the reality of facts: sometimes there's just no time for best practices.

As a personal code of conduct, I think it is OK to choose the easy way (often referred to as a HACK) if the following is true:
  1. You are aware you are doing a horrible thing, and it makes you sick
  2. Environmental constraints (such as a guy coming at your desk every 5 minutes to check if it's done) make the HACK the only affordable/reasonable solution.
  3. You are aware that the given piece of crap code will most likely never be changed (we'll change it later = we'll forget everything about it around 6)
  4. You can live with the fact that people looking at the horror will know you are responsible and talk shit about you when you leave (you can try to sweeten the pill with comments on how bad it is, but that just makes it worse)

In conclusion, as an engineer you are often called to compromise, and this is perfectly normal. I will add that this happens most of the times unless you are very lucky, and arguably as an engineer you'll be judged  based on the goodness of the compromises you make.

Unfortunately, all of the above doesn't help with sleeping at night.

Monday, November 28, 2011

AccessControlException when pushing file to S3 bucket from GAE (on OSX)

This is one of those edge case scenarios that can drive people crazy.

I was trying to push a file from a Google App Engine app to an Amazon S3 bucket via the jetS3t API and it would keep coming back with an AccessControlException (access denied) kind of exception.

After quite a bit of digging around turns out the Mac default Java SDK will try to load a native library for the cryptographic needs of the S3 stuff and this is forbidden in GAE.

There's 2 workarounds apparently:
  1. if you feel adventurous, (as I did) add this to your VM args from Properties > Run/Debug settings > Edit launch configuration options > Arguments: -D--enable_all_permissions=true
  2. use another crypto library instead of the default (BouncyCastle is a common one, and it comes with the S3 API).  
Happy hacking!

EDIT (Dec 2nd 2011)Some news after more work on this, unfortunately solution 1) only fixes the problem locally - when you go and deploy you still get the same AccessControlException. Also, it appears that Google App Engine prevents you from specifying a custom crypto library so solution 2) is no good either. But bad news don't stop there, according to this thread
JetS3t is not compatibile with Google App Engine. Or the other way around. Because JetS3t uses a number of libraries and techniques that are not supported in the restricted execution environment of Google App Engine there is no easy way to remedy this.
Viable solutions seem to be:
  1. This contraband version of the AWS SDK forked for app-engine
  2. jclouds
I am in the process of trying some of this stuff. Will probably post something in a future post (if this stuff doesn't kill me first).

Thursday, November 10, 2011

.NET Butchering --> Code Butchering

This is probably long overdue, I am changing the title of the blog to reflect the fact that I've been posting less and less .NET related stuff. This is somehow related to the fact that I've been trying to get more experience on non-microsoft technologies (mainly working on my pet open-source project), trying to practice my credo of language agnosticism.

Monday, July 4, 2011

How to ssh into Amazon EC2 Linux instance (and copy stuff over)

This is easy enough on an absolute scale but can be a bit of a nightmare if you're windows-oriented (as I unfortunately am ... but I am trying to snap out of it).

Here's a list of steps:
  • Create amazon instance with a new key pair
  • Save your private key to a known location (it's a .pem file you'll download in the process)
  • Make sure the folder with the private key has appropriate access otherwise it won't work (e.g. on mac: chmod -R 700 path/to/pvtk).
  • In the EC2 dashboard go the the security group settings for the instance and open ssh port 22
  • Connect: ssh -i path/to/key/myKey.pem root@my-ec2-public-ip.amazonaws.com 

An alternative to referencing your key on the ssh command is to add it via ssh-add (on mac).

Another thing you might wanna do is to copy stuff over to the EC2 instance - you can use the scp command:

scp test/winning.txt root@my-ec2-public-ip.amazonaws.com:temp-files/

Good luck!