greg haygood

In picking up Android development, one thing I miss from the iPhone camp is Interface Builder.  Coding up Android's XML files to handle all the UI screens is tedious even for one display type.  Add on the different orientations, dimensions, and the rest makes it very un-fun. 

Started working on an Android version of an existing security tool.  After setting up the basic screens, I started importing some of the existing Java code.  I expected some issues, of course, but I ran into a maddening one.  Eclipse started complaining of this:

[2010-01-14 22:41:43 - MyApp]
trouble writing output: null
[2010-01-14 22:41:43 - MyApp]Conversion to Dalvik format failed with error 2

Trying to Run or Debug would bomb with messages like:

It's 2009, right?  And Java is a write-once, run-anywhere platform, or at least purports to be such.  And we have eons of experience that says "don't hardcode file path references" (seriously, BeOS knew this!)
 

JRuby has been around for a little while, and is getting lots of attention for its ability to let Ruby developers code for a Java environment, and vice versa. However, as with many young projects, there isn't much documentation when it comes to the fringe cases.

The need I came across is the following: I have a client that's been running a JSP/servlet app under Tomcat for many years (originally started with JSP 0.91!). Over time I've added more and more functionality using the same JSP, Struts, etc. toolkits as everyone else uses.

I may have finally found the perfect monitor solution for my network: Zenoss. I have been using Nagios + Cacti + Smokeping for quite a while now. It works, but it's not integrated, and for many services, I'm running 2-3 checks. Running those every 5-10 minutes generates a tremendous amount of traffic (during the last 2 weeks, the monitor station has caused 20% of all traffic crossing the primary firewall!). The closest all-in-one I'd found previously was OpenNMS, which is so difficult to really understand and manage well, and so didn't fit my needs.

This is something I discovered quite a while ago, but re-discovered a bit tonight. I always love the situations where you want to do something as stupidly simple as launch the user's default browser, only to discover that it's really not all that simple from a cross-platform programming point-of-view. After a few hacks of my own for a particular project, I came across the BrowserLauncher2 project on SourceForge. It easily handles all the "let's try it this way .... no? how about this way .... no again? ok what about this ... ?", all in a single method call.

I've been trying to implement a continuous integration server for one of my bigger projects. Luntbuild has a lot of great features, so I've been working with that. But I keep running into stupid design flaws that always make me reconsider. For instance, Luntbuild supports a very sophisticated variable system that can be used in numerous ways. One helpful use is to refer to the previous successful build.