I’ve done it again and decided to change the technology I’m going to use to build LaG. Some my attribute this to technological ADD which I freely admit to, but this time I believe my reasons are substantive.

Uncertain Future of App Engine Patch

I was pretty excited about being able to use Django on Google App Engine with App Engine Patch. However, in recent weeks I noticed that most of the questions to the mailing list were only responded to by the original poster. I personally experienced this when I had a question about a problem loading fixtures and didn’t get a single reply. Then a recent thread on the future of App Engine Patch stated that the maintainers were looking into using a new Django-based framework. Well, I’m just not willing to invest my time in a dead framework. Strike 1.

Wary of Google App Engine

I’ve always been concerned about being locked into App Engine, but the lure of hosting that was free to start and could be scaled with usage needs was very attractive. My desire for a solution that is cheap to start and can scale with need is still very high, but I think there are enough ~$20 per month VPS solutions out there that I’m willing to forgo the $0 starting point for more freedom, control and flexibility. Check Swing.

Desire to Focus on Testing and BDD

Since I’m going to be the only QA for LaG (aside from the users , I really want to have as much automated testing in place as I can. Django and Python have plenty of facilities to do unit testing and BDD, but the community as a whole doesn’t focus much on it and there don’t seem to be a whole lot of best practices around it. While googling Python BDD, most of the references were to say, “We can do that with Doctest and py.test,” but not a whole lot of examples.

Back to the Bad Boy of Software Development

Since I was reevaluating my technology choices, I decided to check in on Rails which I hadn’t looked at in 2+ years. Part of the reason I moved away from the Ruby/Rails scene was that it seemed that things were always changing and not in just subtle ways. I felt like I couldn’t keep up with all that was going on and wanted more stable, measured approach to my choice of frameworks. Well, things haven’t changed much. There’s Rails + Merb = Rails 3, RSpec, Remarkable, Cucumber, etc. all still evolving at fast, if no longer breakneck, speed. But there was still the focus on testing and high quality code. There are also a lot of solutions to help with deployment that didn’t exist 2+ years ago. So I’m reacquainting myself with Rails and RSpec and getting an introduction to Cucumber by going through The RSpec Book beta. I’m feeling pretty confident that this will be the technology I stick with, but I’ve told myself that before.

I’ve been working on the HTML and CSS for LaG using Espresso. I first created the markup in a base html file and then I’ve adding the CSS classes and styles as needed. I’ve now come to the point where I’m going to start implementing the UI in the server. The first decision I need to make is whether to implement the UI using FBML or an iFrame for the FaceBook app.

In a previous application, I used FBML because it was easier to get something that looked like it was integrated with FaceBook. Also, if I recall correctly, it was easier to pass the FaceBook session between server trips. I know I didn’t explicitly have to add a URL parameter to any of the links I generated to pass it along. I didn’t look to see if there was a simple solution to this, but I assumed I would need to do something.

Then today I noticed this note in Mafia Wars, “… we deployed iframe technology to dramatically speed up the game…” Well that kinda sold me. If an iFrame application is faster, that’s what I’ll go with. It also allows me to use common JavaScript libraries like jQuery and I’m less concerned about looking like an integrated application, so that one less reason to go with FBML.

Finally, iFrame development will be a lot easier than FBML because with FBML you have to go through FaceBook servers so the FBML will render. Using an iFrame will allow me to develop LaG as if it is any other web application.

As I mentioned in my last post, I’ve been trying to get some unit testing going so that I can keep focused and gain a higher level of comfort with the code I’m writing. I started by trying move a business method that had crept into the model and put it in its own business class. To test the new business class I tried to use Mock to imitate the behavior of the data model, but I couldn’t find a way to get it to mimic the behavior of a Query object which is both indexed and has methods on it. I did learn that Django fixtures were supported by app-engine-patch. In fact, I learned that most of the ./manage.py functionality works. I had incorrectly assumed that app-engine-patch only allowed you run a Django app on App Engine server, not that it could be used like standard Django. After writing a test for the new business class, I created a fixture to support the test. Well, the test kept failing even though it should have passed. I did some digging, and it seems that the models in the fixture that have relationships aren’t getting loaded. I’ve got a question out to the list to see if this is actually the case, but I can’t think of another explanation.

So, I didn’t actually get any unit tests working, but while writing the test I noticed that there were model classes in my view as well as the database classes in my controller and business logic in my models. So now I’ve got it all cleaned up and the code appears to be working (no tests though). I keep seeing what kind of tests I can write and maybe someone will fix the problem with models with relationships in fixtures.

app-engine-patch

Let’s get down to some programming. First, I downloaded app-engine-patch 1.1RC. This gives me Django 1.1 with Google’s model classes instead of Django’s own Model. For those who don’t know, Google App Engine (GAE) uses BigTable instead of a relational database like SQL Server or MySQL. With BigTable you trade the data integrity of a relational database for performance and scalability. Because I’m using app-engine-switch, I’ve assumed that django-admin.py wouldn’t be of any use so my development cycle has been all manual. If anyone has used django-admin.py with app-engine-patch, please let me know. It certainly would be more convenient.

Changes

After downloading and unzipping the file, you are left with a directory name ‘app-engine-patch-sample’ which will be the basis for my application. I renamed it ‘law-and-gospel’. Then I deleted the ‘blueprintcss’ directory and renamed ‘myapp’ to ‘lawandgospel’. In app.yaml I changed the application attribute from ‘aep-sample’ to ‘law-and-gospel’. In settings.py I changed the DEFAULT_FROM_EMAIL attribute to use my email address. And in urls.py, I added (r’^lawandgospel/’, include(‘lawandgospel.urls’)) as the first of the urlpatterns after ”.

pyfacebook

Next, since I know I’m going to use pyfacebook so after I downloaded and unzipped the files. Then I copied the ‘facebook’ directory into the root of ‘law-and-gospel’.

changes

in settings.py I added ‘facebook.djangofb.FacebookMiddleware’ to the MIDDLEWARE_CLASSES attribute and added the FACEBOOK_API_KEY and FACEBOOK_SECRET_KEY attributes with the appropriate values from the Facebook application I registered.

LaG Changes

I started removing the models, forms, and view that came with the default app-engine-patch application and replaced them with some of the models, forms, and views that I will need for LaG. At this point, documenting every change would be excessive so from now on I will be documenting the more interesting aspects of the development.

My UI Design Paradigm

Let me say upfront that User Experience (UX) design is a major weak spot in my skill set. I’m pretty good at exposing the functionality to accomplish a given task, but optimizing workflow, influencing behavior, and polishing experience are areas I need to work on. Part of the problem is that it has always been easier for me as a developer to code up a UI and evolve it. This tends to lead to less experimentation and low desire to change something that already works. In this paradigm, even if an interface it poorly designed but exposes all the necessary functionality there isn’t much value in re-coding it as the new design might be just as bad and then you’ve done a bunch of coding without adding features or improving the interface.

Been There, Done That

I’ve tried various ways to design the UI without coding, but I’ve always run into some short coming that leads me back to my code and evolve style. Here are some examples:

• HTML prototype – This doesn’t work for me because I spend more time working on the CSS than the design. I’m also typically working within the development environment I’m going to deploy in so I end up focusing on implementing the elements of the design and not the design.
• Flash prototype – I thought this would be a great way to have interactive prototypes but then I ended up having to code mockup elements and it just turned into another case of focusing on the tools rather than the design.
• Paper prototype – I can’t draw and I couldn’t stand the lack of interactivity.
• DreamWeaver – It’s been a long time since I’ve used DreamWeaver, but I do remember the effort to prototype was substantial (managing templates for one) and I felt cheated that very little of what I built was transferrable to the final project.

A New Way Let me state that I received a free license for Mockup for Desktops with the understanding that I would write a review and this is it.

Enter Mockup for Desktops (MfD) from Balsamiq. MfD is a tool built specifically for prototyping web applications. That focus allowed me to think about the UI design without any thoughts about the tool itself (HTML, Flash, and DreamWeaver) or the implementation of the application (HTML). There was no feeling of wasted effort (Flash and DreamWeaver). And the ability to interact with the design (Paper) was faster than with any of the other tools I had used previously.

As I mentioned, MfD is specifically designed to prototype web applications. It presents you with a canvas where you implement your mockup and a palette of standard HTML elements to use to build the design. I found myself putting together my first mockup in a few minutes and then tweaking and coming up with more pages in just a few hours. Here’s an example:

Then you can use the “hyperlink” UI elements to link to additional mockups and view the mockup as a “presentation” to test out the interactivity.

This leads me to my one major complaint with MfD and that is the lack of a template mechanism. My web app, as most do, has a bunch of elements that are common across multiple pages; navigation menu for example. There isn’t a way to make changes to common elements across multiple mockups. You can achieve this visually by using a common background image, but then you lose the interactivity of the elements. My solution was to just use the main mockup to track changes to common areas and to ignore the discrepancies in subsequent pages. Not ideal, but I’m a developer and can deal with it.

Templates aside, Mockups for Desktops is a great tool for prototyping. It allows you to quickly put together and experiment with different interface elements. Tools that let you focus on the task you are trying to accomplish are awesome to work with.

In my continuing exploration of whether video games can convey the Gospel, I’ve decided to develop a Facebook game that incorporates some of my thinking along the lines of basic catechesis and apologetics. The basic idea is to have a Mafia Wars like game which has “catechetical tasks” instead of “jobs” and “apologetic encounters” instead of fighting.

I started by playing Mafia Wars to get a better feel for the mechanics. The basic mechanic is that you do “jobs” to gain experience, money, and “loot.” You use all these to do more difficult and involved “jobs.” You can also participates in fights and wars with other players, but I haven’t found that they are central to the game. The social aspect of the game involves gifting and receiving “loot” and leveraging your friends/”mafia” for assistance in fights.

For lack of a more inspired title and because the name was available for a Facebook app, I decided to call my game “Law and Gospel” (LaG). I replaced Mafia Wars “jobs” with idea of vocation. Players will have tasks such as “Study the Gospel of Luke” as part of there vocation as a “New Testament Scholar” or “Research the Trinity” as a “Theologian.” When players do the tasks, they won’t just earn experience points they will also receive instruction such as a Bible verse, prayers, or quotes from famous theologians. These nuggets of information will be valuable as theological instruction, but also to answer in-game questions and quizzes to earn “gifts” the LaG equivalent to “loot.” The only planned social activity is being able to give “gifts” to other players. I’m thinking about a “congregation” which would be equivalent to a “mafia” but I’m not sure what activities they would share in.

I think the most intriguing part of the game has no equivalent in Mafia Wars and that is the idea of the player doing apologetics. Players will be able to interact with Non-Player Characters (NPCs) who will ask scripted questions and allows the player to respond with a word of Law, a word of Gospel, advice, or some other possibilities depending on the exact question. Based on the response to the NPC’s questions, further interactions with the player will be affected. For example, if the player respond to a question with Law, the NPC may become upset and require a “gift” for further action to proceed. Or a word of Gospel may lead the NPC to continue in his/her problematic ways. This will obviously be the most complicated part of the game to design and implement.

That’s what I’ve got so far, I’m now doing some mockups to get a feel for what the interaction will be like and to get a better idea of what the data model will need to support.

Now that I’ve decided to write a Facebook app using Django on Google App Engine I plan to document as much of the development process as possible. The first steps were purely administrative. I registered a Google App Engine application called “law-and-gospel” (lawandgospel was taken). I then registered a Facebook application called “LawAndGospel.” Nothing complicated about either of those things so I won’t bother doing a walk through of those processes.