Verse Of The Day

Tuesday, March 31, 2009

Google App Engine & Python

I finally took the dive into the Google App Engine last week. It's free to get started (up to 10 applications per Google account) and gets my feet wet for this whole "cloud computing" crapfest. Here are my first impressions of Google App Engine and Python. I won't go into my issues with cloud computing in general and all the hype surrounding it, and how it will magically solve all of our scalability and maintenance issues.

I was surprised at how well done the Google App Engine is, and how quickly I could get started. Downloading and installing the local development environment was quick and painless, and walking through the tutorial, I had a very basic "guest book" application written and deployed out in the vast Google cloud for the world to see. The local development server was up and running within minutes of downloading and installing, and making changes to the Python scripts didn't require any redeployment or restarts. Uploading to the Google servers was a matter of running a single script and entering your user id and password. There is even an admin console where you can see stats on your page visits, bandwidth used, performance, etc.

I like that the Google users and authentication is pretty much built in, as well as the simple "webapp" MVC framework, and that you can use any pure Python library or framework you want to use (as long as there aren't any extensions written in C). The data access layer and GQL query language is interesting -- one big free-form data store where you aren't dealing with individual tables so much as just defining your entities in your code's data structures, and reading and writing from them as if they are tables.

For now, the only supported language is Python, which I have never dealt with. That really wasn't much of a hurdle since the syntax is pretty straight forward and easy to learn. I wouldn't mind seeing other languages supported in GAE, though not sure it really matters or if it is worth Google's time, money, and effort to expand support to other languages. I'm sure if they asked 100 developers they would get 100 different answers of what languages should be supported.

I'm a little more ambivalent toward Python. I didn't dislike it, but it just didn't grab me by the balls and make me exclaim it's superiority either. I can say I'm not a fan of the whole "indentation exception" crap. As a guy with more of a C and Java background, I like my curly brackets instead of relying on indentation levels, which remind me too much of COBOL, yuck!

Anyway, here's my trivial little application. It's all "tutorial-ware", straight out of the book with a few CSS enhancements and a simple "about" page. It's not useful, but not bad considering how little time it took to write.

Next step.... write something useful. I definitely want to get into this more and add it to my development toolbox.

So Tempting....

Eleven turkeys recently found themselves really lucky they weren't in season....

Tuesday, March 03, 2009

An Overzealous SEAM Validation

I am using the Jboss SEAM framework for the project I am currently working on. The first thing that really bit me was a validation on single character fields that seems a bit "too stringent". I'm sure I'm not the first to run into this. In fact it may be fixed by now in a newer version of SEAM, but figured it's worth a post anyways.

When you use Jboss Developer Studio (JBDS) to reverse engineer your database (I imagine the seam-gen tools do the same since JBDS uses them), the getter method on the EJB looks something like this...

@Column(name = "DEFAULT_REMAP_IND", length = 1)
@Length(max = 1)
public Character getDefaultRemapInd() {
return this.defaultRemapInd;
Looks fine, looks reasonable. Single character fields are often used for flags or indicators, as this one above is -- it's a simple Y/N field. So in my XHTML I use a radio button control instead of a free form text field.

<h:selectOneRadio id="defaultRemapInd" value="#{ocamCustTypeDfltHome.instance.defaultRemapInd}" required="true">
<f:selectItem itemValue="Y" itemLabel="Yes" />
<f:selectItem itemValue="N" itemLabel="No" />
<a:support event="onblur" reRender="defaultRemapIndDecoration"/>

The SEAM framework will use that @Length annotation to perform some field validations for you automagically, which is pretty cool as it can be a real time-saver. But the funny thing is that when this "max length of 1" validation fires, you get the lovely message shown in this partial screen shot ....

Not sure how to get a single character with a length greater than 0 but less than 1, but I do know that the easiest thing to do in this case is remove the @Length annotation for that field. I had to do that for a few different tables. Luckily they were all flags that could be replaced with radio buttons, but in the case where you had to allow free input, you might have to get more creative (you can always put a max length on the input text field).

For reference, I am using Jboss 4.2.2, SEAM 1.2GA, Jboss's EJB3 implementation (which is Hibernate under the hood), XHTML and Facelets for the views. Like I said, this might be fixed in a later release of SEAM.