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.

I’ve been working on LaG for a month or so. Progress has been slow, because I haven’t set enough short term goals. I really need to get back to my GTD weekly review to prioritize and get to a list of actions for the project.

Most of the work I have done has been to flesh out the data model. I had some basic functionality that I wanted to implement, and then I fleshed out the data model and functionality to support it. The one thing that was nagging me was that there weren’t any unit tests. I know that unit tests are a good thing. I’ve even done some TDD/BDD and have been very happy with the results. I’ve also had the experience where TDD/BDD has made me feel like I wasn’t actually moving closer to delivering anything of value. I was writing good (in my mind at least) code, but wasn’t getting closer to end user functionality. I decided that I needed to get some tests written and that it would also help me by focusing me on a task that would move LaG forward.

Part of the reason I had avoided writing tests was that I assumed that app-engine-patch didn’t support the same unit testing that is available in standard Django. Of course it took me all of one Google search to find that I was wrong. So, I fired up ./manage.py test and 26 tests ran and passed . Cool, now I had to add my tests.

No Business Logic in model.py

I recently read a tweet from UncleBob about isolating 3rd party API’s. For Django/app-engine-patch, I consider model.py to be owned by the API. It will be very different for each of the implementations and I would like to be able to port the app to a standard Django deployment if GAE is no longer appropriate. I found that some business logic has crept into model.py. The first thing I need to do is to write a test and pull this functionality out of model.py.

No db in the Business Layer

I also found that some google.appengine.ext.db calls had crept into my business layer. So my next task will be to write a test and remove any db calls from my business layer.

I think my decision to focus on just getting some functionality and database modeling done without testing was appropriate. I wanted to get a feel for what I would be able to do and what the application would feel like. But now, it’s time for me to clean up the code and get to TDDing. Sometimes l need to just write code to keep myself motivated, and other times I need to be more disciplined and follow a process to gain focus. I’m not sure the Agile term ‘spike’ is exactly write, but that what it feel like to me. A short interval where you experiment and just code, then go back to disciplined development.

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.

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.

I started working through the Lift getting started guide and other documentation and I’ve come to the conclusion that a lot of the benefits of using Lift aren’t applicable to the project. The project is a Facebook app and I have a little experience writing those with Django and Google App Engine. All the nice CRUD, AJAX, JSON, Comet, etc. integration isn’t going to help me. Also, there aren’t a whole lot of examples of using Lift with Facebook. In fact, my biggest concern with using Lift would be the lack of documentation. There is “The Lift Book” but this is more a guide to what Lift can do and how to do it. There are a few tutorial floating around, but the ones I found were out of date and incomplete. I’ve come to realize that I learn best by working through examples and there just aren’t enough of those to make me want to move forward with Lift.

I’ve decided to go with Django on Google App Engine for this project. It’s somewhat familiar ground and will allow me to focus more on building the app rather than learning a framework and language. Although I’m not well versed enough in Django, Python, Google App Engine, and Facebook to believe I won’t learn a whole lot.