@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Well, that went relatively well. As a proof-of-concept for Google App Engine I decided to see what I could whip together today in between domestic duties, looking after the kids and praying that my wife gets better from her massive cold because I’m off to Vancouver tomorrow.

So, I pushed the database for Rallyhat up into the cloud and wrote a super-simple front end just to see if I could do it. You can take a quick peek at http://chrishartjes.appspot.com. To get it to spit something out, you need 3 parameters:

• home_team — nickname for a baseball team (i.e. Yankees, Red Sox, Padres). Don’t forget to urlencode the spaces with a +
• begin_date — date in YYYY-MM-DD format
• end_date — date in YYYY-MM-DD format

It’s a small start, but a start nonetheless. Next step is to configure my app to use the dev version of Django, not the built in version.

This will be the first in a series of posts chronicling my building out of Rallyhat, a site that people will use to plan sporting road trips, baseball first. In this first installment I wanted talk a bit about the first steps I too to actually get this thing rolling.

Now, I could easily build this site in CakePHP, so that's not really much of a challenge. I already have one site that runs Cake to keep me on top of things there, and future work-related projects are going to be CakePHP for me as well. So, something else then? I already did the Rails thing, and tore that down to build the CakePHP one. I thought about using Merb, and I'm going to attend a talk at Open Web Vancouver about Merb so I get a better idea about what it could do for me. So that left just one choice.

C'mon, you're not really surprised are you?

One of the things I really liked about Django is the admin app that you get for free. I've already been using it to full some of my support tables for the application, but I wanted to talk about a neat little thing you can do here. In Django, you define the names of the fields in your model in order for the ORM magic to work. Here's a little sample:

The Admin stuff is so that those models show up properly in the admin part of the application. So, just like in CakePHP where you can use $this->Model->find('list') to get an array for use in your dropdowns for forms. Django, does this a little differently.

Being totally object oriented, if you drop into the Python interpreter and ask it to return a model to you, you'll get something like this, taken from the Django tutorials:

WTF? What good is "Sport: Sport object" to us? I want something more descriptive. How about the name of the sport? That's easy. We can modify the Sport model and tell it that when we return the object, return the "name" field instead.

So, when I drop into the shell, I get the following:

Same result, different way to get to it.

A while back I was contacted by Cal Evans over at the Zend Developer Zone to contribute to a new podcast he was starting up called PHP Abstract. Very cool idea, a small 5 to 7 minute podcast by PHP developers where they talk about a topic of interest to them (and hoepfully to you). Well, being one to never miss out on an oppurtinity to promote myself I agreed to contribute what I could. I settled on a brief talk about opinionated software. Also known as "convention over configuration" by the Ruby on Rails crowd.

Go over and have a listen and don't be shy in sharing your feedback via the comments there or here. Opionated software / convention over configuration / tools with rules is a powerful yet misunderstood programming practice.

[Note: looks like the move to the new server will take some time as I configure things *just so* so blogging can continue]

So I'm sitting around thinking about how I'm going to build out the new rallyhat.com, turning it into a "plan a baseball road trip site" and figuring out what tech to use. To be honest, I've gotten kind of bored with Ruby on Rails for a few reasons. One is that I understand the tech behind Rails, and don't agree with a lot of the magic methods that Ruby seems to be encouraging. I like to sort of understand what's going on rather than being told "just do it this way". I don't understand Ruby enough to wade into the source for Rails and figure things out. Secondly is that I haven't touched any Rails code in months, so any momentum I had has leached out.

So, I like to learn new languages because, well, it makes me a better programmer. I've spent my time this year learning my way around Javascript so I can get a firm grip on just how all this Ajax stuff is supposed to work. Now I'm glancing over at Python and trying to decide if I want to invest in learning Python so I can try out Django, a web application framework that gets lots of nice things said about it. Not as flavour-of-web-pi that Rails has become, but a solid, well-documented web application framework.

So naturally I do some research and found an interesting post about Python web development frameworks that talks about Django vs. Pylons vs. Turbogears. Very interesting reading and it convinced me that Django is the way I should go if I'm going to become a snake handler on this project. But I followed some other links and got to a page (can't find it now of course but I remember it) where there was a discussion of glue vs. full stack frameworks.

A glue framework provides you with a bunch of components that you can use together, but don't necessarily have to. Zend Framework is a PHP glue framework, as it comes with all these cool components that you can pick and choose depending on what you need done. You're not forced to use them, and this appeals to certain programmers who have fallen in love with their own quirky set of libraries and methodologies. This used to be me. To shift this over to Python, since I know no Python at this point i would be pointless to go with a glue framework.

A full stack framework gives you everything you need to create your web app, and pretty much forces you to use it. CakePHP is a full-stack framework. It has a bunch of conventions, and you must follow them or die. Okay, maybe you won't die but your application will never work properly if you don't understand the conventions. Django is a full-stack framework. So, given my knowledge level of Python I think that would be my safe choice.

However, I have the Imp of the Perverse mumbling into my ear that I should just build the damn site, screw Python because we're tying to get something done here. So I'm thinking that I need to put my money where my mouth is, and build in CakePHP. After all, I have that cool interactive console to test stuff with.

So, give me some feedback: which do you prefer when building an application? Full stack or glue?

My apologies for the lateness (and shortness) of this post. Real life has intruded this week. More news on this later. But here's what's jumping around in my brain:

• Nate from CakePHP is helping me out with the work on my proposal for an interactive console. Trax (a Cake "competitor") has an interactive shell so I'm taking a look at how they are doing things to see what I can use from it. Thank you open source licensing!
• There has been great feedback from those who watched the screencast of my talk from Vancouver and I'm going to tweak the talk for May. Remove some slides, avoid duplication and build up the parts that drew a lot of interest: deployment and programmer ego.
• I'm going to have to dive into the slightly old Typo install and figure out how to stop the huge amounts of trackback spam we've been getting. Seems that the Typo install I'm running ignores requests to stop accepting trackbacks. Gotta fix that by hacking at the source