Monday, July 30, 2012
Thursday, May 24, 2012
[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):
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
Wednesday, May 9, 2012
Javascript Random Masking
Just a snippet to randomly mask some text, for whatever reason (such as not getting sued).
Saturday, February 11, 2012
Javascript Profanity Check
Here's a copy-paste-ready snippet implementing a javascript profanity check:
Enjoy.
Enjoy.
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:
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
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:
- You are aware you are doing a horrible thing, and it makes you sick
- 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.
- You are aware that the given piece of
crapcode will most likely never be changed (we'll change it later = we'll forget everything about it around 6) - 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.
Subscribe to:
Posts (Atom)