I’ve been working on a Facebook iframe app for the last few weeks, and it’s been an adventure to say the least.  For those that don’t know, there are two ways to develop Facebook apps, the iframe method, and the FBML method.  The iframe method allows you to basically embed content from your own server in an iframe within Facebook’s chrome, while passing back and forth the necessary Facebook data.  The FBML method provides you with a markup language that allows you to more tightly tie your app’s design in with the native look and feel of Facebook.  This route keeps all your content on Facebook’s servers.

For our app, we went with the iframe option, because we had lots of data exchanges going on with our own database, and users needed to upload pictures as part of using the app. During testing, (in various flavors of IE, Firefox, and Safari on both major platforms), no real problems were encountered with the functionality of the app that weren’t resolved before deploying. Once deployed, however, some users were encountering problems that seemed to be random glitches that we couldn’t really troubleshoot.  The API methods for getting a user’s photos sometimes didn’t return anything, no errors, no photos, nothing.  This actually seems to be a known problem, and an obviously annoying one.  Also, sometimes the user would be taken outside of the iframe, and directly to our server, which is obviously not ideal.  This was fixed with a kludgy workaround, where all links were pointed to the app’s URL on Facebook, with our URL parameters appended.  This, however, is going to make tracking less accurate with Google Analytics, since they are technically not links within the iframe any longer.

So I’m curious, has anybody else had problems when developing Facebook apps?  Does it feel as messy to you as it did to me?  It’s been an interesting experience, and I just hope I’m not the only one that feels this way after my first real Facebook app.

I have a confession to make.  If you read my blog at all, you may remember that I posted about switching to Django for my wife and I’s blog.  I have to say that I’ve had a change of heart.  I’m going to stick with my old reliable favorite, PHP.  Essentially this is an exercise of restraint.  I really like coding in PHP, and for a multitude of reasons.  It’s lean, flexible, and can be object-oriented.  I’ve been taking a more object-oriented approach to PHP lately, and I would definitely like to the get the practice in.  Another reason I don’t want to switch to a new platform is because of the flexibility of my job.  New projects come along frequently enough that allow for experimentation with new language and technologies. I definitely want to hone the skills I already have, and if something comes up on the job that requires a new language, I’ll delve in there.  In working at Bridge, I’ve already tested the waters in two new languages, Java and Perl, and I enjoy both of them.  So that’s that.

In related news, I’m finally getting to the point where I’m actually redesigning my other blog, so stay tuned for posts on the entire process of re-creating that site.

Cheers.

I’ve been reading up a bit on Python lately, which is a pretty popular high-level programming language used for a variety of applications – including web and desktop apps.  It’s used extensively in a lot of Linux applications, and Google utilizes Python in a lot of their work.  The performance of the language seems to be a key selling point, as does its refreshingly simple syntax.  Naturally, I’m curious about using the Django framework in my own work.

This doesn’t mean I’m leaving PHP in the dust – I still use it extensively at work, with no plans of stopping anytime soon – but I just have a feeling this is a language I would like to work in. Python’s syntax is similar to Ruby’s (at least at first glance), and from what I’ve read it outperforms Rails by quite a bit.

The project that I’m going to cut my Django teeth on is my wife and I’s blog: www.rustyandben.com. I talked briefly about overhauling the site a few months ago, but some other higher priority projects came up. I’m getting to the point now, however, where I can start working on it again. I’ll be re-designing and developing from scratch (obviously maintaining all data), so it makes the perfect opportunity to try out Django. I’ll be upgrading my Media Temple hosting to a virtual dedicated server so that I can have root-level access in order to install whatever software I want. This, in turn, will allow me to try out a couple other technologies I’ve been wanting to check out: SQLite (a lightweight flat-file database system) and Lighttpd (a lightweight and fast HTTP server). More on those as I assess their feasibility.

I’ll be posting about all this again soon, as I’m planning on writing a series of posts about the creation of the site.