C#-like TryParse Integer for Java

[AppEngine] java.lang.RuntimeException: Unable to restore the previous TimeZone

Started getting the error on the dev server after upgrading to AppEngine 1.6.3 on Mac.

Turns out AppEngine is looking (via reflection) for a field that's missing from JDK 6.

You can either use a different JDK or add the following to the VM arguments from run configuration (which did the trick for me):

-Dappengine.user.timezone=UTC

Javascript Random Masking

Just a snippet to randomly mask some text, for whatever reason (such as not getting sued).

Javascript Profanity Check

Here's a copy-paste-ready snippet implementing a javascript profanity check:

Enjoy.

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.

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.

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).

.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.

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!

T-SQL Convert string to datetime

This is the kind of stuff you don't wanna waste time on - and yet ...

DECLARE @test varchar(10)
SET @test = '12/31/2011'

DECLARE @test_date datetime
SET @test_date = CONVERT(datetime, @test, 101)

Heads or Tails? or: how to lose money at the roulette table

I've always wondered how many heads/tails you'd get in a row if you could just keep flipping coins forever. The other day I was bored so I put together a stupid matlab script to try it out (leaving out the "forever" bit).

It's obvious that in theory you could get a never ending series of heads or tails, but in practice that is infinitely unlikely to happen, so I just wanted to get a feel for a "reasonable" figure in terms of how many repetitions one should expect to experience if one actually started tossing coins (or betting money on red/black at the roulette) for a very long time.

Out of 100 million series of coin tosses (where a series is defined by an uninterrupted streak of heads or tails) the longest streak of identical outcomes was 26 (I wanted to try with a billion series but was taking too long).

That means that if you go to a casino to make money doubling bets on red/black (the so-called Martingale strategy) and you are particularly unlucky you might have to flush out 20*(2^25) = 671,088,630 $ (a single bet is usually at least 20 $) on your last bet to actually make a profit (plus all the money you spent to get there).

If you play smart though, and you wait for 5 reds/blacks in a row before you start betting against that, then you can get away with a last bet of only 20*(2^20) = 20,971,520 $ (that's 20 millions!).

Disable DIV with jQuery

Here's a lame trick I use to disable divs:

// this works on IE

// disable
$('#myDiv').attr('disabled', 'disabled');


// enable
$('#myDiv').attr('disabled', '');

Disabling the whole div doesn't seem to disable inputs in chrome and firefox though, so here's the alternative version drilling down to each single input elements:

// this works everywhere but looks weird in IE


// disable
$('#myDiv :input').attr('disabled', 'disabled'); 


// enable
$('#myDiv :input').attr('disabled', '');

Good hacking.

Get list of OpenCL supported devices with jogamp.jocl

I recently got started on GPGPU, and the natural choice seemed to be OpenCL, since it's supported by both ATI and nVidia. The nice thing about OpenCL (other than being cross-platform) is also that it provides a layer of abstraction that allows you to use both CPUs and GPUs (not only GPUs as for nVidia's CUDA and AMD's Stream technologies).

I started investigating a few java wrappers (there's only a handful around) and ended up playing with jogamp.jocl.

This is just a snippet showing how to retrieve a list of OpenCL enabled devices on your machine:

// create context for all devices detected using default platform
CLContext context = CLContext.create();

// an array with available devices
CLDevice[] devices = context.getDevices();
         
for(int i=0; i < devices.length; i++)
{
   out.println("device-" + i + ": " + devices[i]);
} 

Goes without saying that if you don't see your GPU in the output it's time for some painful driver sweeping. I found that Snow Leopard works straightaway with both ATI and nVidia (MacOSX 10.6.x ships with OpenCl support), while windows can be a bit trickier to setup (as we all know, Catalyst software kinda sucks).

Just to give you a sneak-peek at what comes after, once you've had a look at the output then you can go ahead and select a device to create the queue(s) you'll use for sending data up to the devices:

// have a look at the output and select a device
CLDevice device = devices[0];

// create command queue on selected device.
CLCommandQueue queue = device.createCommandQueue();

You can see the entire code for the official jogamp.jocl  'Hello World' example here if you're curious.

Was Darwin Wrong?

In the beginning it was self-replicators.

Then it was self-replicators with metabolism (which kind of is the definition of life).

Now, to go from self-replicating blobs to human beings it takes a pretty good search algorithm.

Natural selection is that algorithm, and it happens to be the most robust search algorithm there is, beating hands down any other kind of human-designed search tool.

So, was Darwin wrong?

P.S. if you don't believe in facts then there is very little that can be done to convince you

How to load text files with jQuery

I was looking into this to help out @tarelli with one of his crazy tasks from hell (spare you the details). Here's how you go about loading local files using jquery:

// LOAD file
$.get('file:///C:/myPath/myFile.txt', function(data) {    
    
    var lines = data.split("\n");

    $.each(lines, function(n, elem) {
       $('#myContainer').append('<div>' + elem + '</div>');
    });
});

This will only work if you double click on the file that executes the script, obviously a web-server shouldn't allow you to go mess around in the file system (I tried on IIS and couldn't fool it, damn). Obviously the same snippet can be used to load files on a web-server by providing a url to an accessible file.

Notes:

• couldn't get it to work without specifying the file full path in format file:///C:/myPath/myFile.txt
• to get this to work on chrome you'll have launch it with the --allow-file-access-from-files cmd line arg

P.S. happy xmas

Javascript - strip off illegal characters from string

Recently had to come up with a piece of javascript to strip off a set of illegal characters from strings before passing down to the persistance layer.

Took me a while to come up with a regex for the replace, not because it's particularly difficult, but because I suck at regexes (and I am no js expert either).

I thought it could be handy to have this functionality as a string prototype:

// strips off illegal chars &%$
String.prototype.stripOffIllegalChars = function() {
 return this.replace(/[&%$]/g, "");
}

The /g above means that the replace will be global (so not just the first of those characters will be replaced).

It can be used like this on any string:

var dirtyString = "blah$blah%blah&";
var cleanString = dirtyString.stripOffIllegalChars();

Hopefully it'll save some time to the next in line.

WCF client hangs on big response: make it streamed

I have to blog about this - as I spent a few days having nightmares about it.

An operation from a websphere service was returning a pdf string, for a payload of about 500KB. The WCF client consuming the service was working fine on the test fixture, but when the operation was integrated in the web solution, with the exact same binding and endpoint, the client was hanging for more than a minute onto the response of this particular operation (every other operation with a smaller payload was OK) before coming back with the deserialized response.

I initially blamed the service, but then noticed (sniffing traffic via fiddler) the response was coming back quick enough and only then the client would hang for more than a minute obviously trying to deserialize or God knows what.

After quite a bit of hacking around on and off, I managed to change the transportmode config setting on the binding from buffered to streamed (I had nothing else left to try!), and it did the trick. In light of this it's pretty obvious that the response was being chunked in parts the size of the buffer and that was probably slowing down the whole process.

Morale of the story: if you've got big payloads transportMode="Streamed" could save your sorry ass.

You have requested an outdated version of PayPal. This error often results from the use of bookmarks.

Recently started getting this error when linking to paypal:

You have requested an outdated version of PayPal. This error often results from the use of bookmarks.

Solved it by commenting this line on my code (when setting up the paypal form in GWT):

paypalForm.setEncoding(FormPanel.ENCODING_MULTIPART);

Apparently PayPal recently implemented changes to prevent it from accepting posts with encoding type multipart/form-data.

Hope it helps.

CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

This is what I got back when I tried to bounce a JAVA WebSphere Axis service from a WCF client:

CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

Took me a while but eventually figured out what was wrong and ,long story short, WebSphere did not like the HttpHeaders generated by the WCF bindings (basicHttpBinding) when sending the request.

I started sniffing traffic with Fiddler, but initially I was paying attention only to the SOAP envelope. I then tried to directly invoke the service using SoapUI and it basically seemed to work fine (no Unable to create AxisService error message and I was getting back the result I expected). With the SOAP envelope ruled out, the next logical consequence needed to be the HttpHeader, so I compared the header generated by WCF with the one automatically generated by SoapUI (by pointing the tool to the endpoint url):

WCF Generated HttpHeader:

POST /MyWebServiceDomain/aWebService HTTP/1.1

SoapUI Generated HttpHeader:

POST http://xx.xxx.xxx.xx:9080/MyWebServiceDomain/aWebService HTTP/1.1

At this point it was fairly obvious that I needed to tweak the POST line of the HttpHeader to include the full definition of the endpoint, hopefully by WCF configuration - and after asking around a co-worker pointed me in the right direction: hostNameComparisonMode="Exact" on the WCF binding is what I was looking for (it seems to be set to StrongWildcard by default).

Couldn't find anything on the web about any of the above - I hope this helps someone else with the same problem.

Add Service Reference duplicates properties on Faults

Spent the last few days fighting with this, finally found what seems to be a workaround so I thought I'd share hoping that it can be of some use to some other poor devil who's stuck.

Dealing with WebSphere generated web services, the curious occurrence of duplicate properties on Faults (on different partial classes) was encountered when generating proxies through add service reference on Visual Studio 2008, pretty much in a very similar way as described in this post on the msdn forum.

Solution: Long story short, you have to use svcutil to generate your proxy classes and data types with the /useSerializerForFaults attribute, this will cause the XmlSerializer to be used for reading and writing faults (but only those), instead of the default DataContractSerializer (which will still be used for the rest of the stuff).

Note 1: using the option /serializer:XmlSerializer instead of /UseSerializerForFaults on svcutil will cause the Faults to be wrapped in a sub-namespace (the same namespace they were defined in the xsd contract).

Note 2: setting the corresponding option item UseSerializerForFaults to false in the ServiceMap file does not give the same results (instead of generating duplicated properties it started generating duplicated attributes, two on each partial class).

This seems to be a genuine bug. Let's just hope it gets fixed because it's a pain to import stuff manually.

Note that if you kick it old school and import the service as web reference (the .NET 2.0 way) it should work fine as well, but for me this was not a choice.