Tips and Secrets for Dealing With App Engine

Google's App Engine is a wonderful, amazing, and revolutionary service. A free, managed hosting experience in which you can build scalable applications. That is huge. I can honestly say I would not know half the things I know or have half the relationships I have with the tech world, were it not for this program. It makes writing server-side software simple; it allows you to only know about writing the software, and not having to worry about system level vulnerabilities, system load, or scaling headaches. I don't have to think about things like iptables, SSH permission levels, or other ways nasty people who are better sysadmins than I am can get into my application. I don't have to worry about hard drive failures at 3 in the morning. Rather, it just asks me to be a programmer.

That divorce between programming and systems administration comes with some costs, though. The most commonly touted one is the lack of control over the system: if I want to run node.js or Redis, I'm out of luck. But there are other, deeper costs as well, things that aren't intuitive to the average user. Things that don't come to mind when you think about the shortcomings of App Engine. And really, they all come down to one thing: if what you want to know isn't documented, you probably are out of luck.

Date and Time

The handling of date and time on App Engine is inconsistent, and it caused me quite the headache. See, the datastore is written in UTC time, but a "day", in App Engine terms, is determined by Pacific time. Your quota, for example, resets at midnight Pacific time. Meanwhile, the datastore holds values that are from UTC time, which means seven hours in the future (according to the quota). Furthermore, the "system time" (what you get if you call datetime.now()) on App Engine is in UTC. The only way to get the values you're writing to the datastore, the values datetime.now() are returning, and the datetime that the quota is based on all in sync is to translate the values to Pacific time, strip the timezone information from them (lest the datastore see it, take it into account, and attempt to correct for it), and then write to the datastore. Then everything will be in sync.

That is all documented, or at least relatively easy to figure out. You can even see it in practice at http://timezones.appspot.com. But I had to implement a soft quota over Google's quota, so I needed to know exactly what quota day I was on, and had to keep the two in sync. And that meant one big question that was not in any documentation and that would take me quite some time to figure out: does the App Engine quota take DST into effect?

Fortunately, Moishe Lettvin, an App Engine employee, has been kind enough to keep in touch with me after I took part in the Channel API trusted testers session. He checked the source code and got back to me. I don't know how I would have handled the situation had he not responded; it would have taken me months to find out on my own. For those who are curious, yes, App Engine's quota takes DST into account.

OAuth

I have a love/hate relationship with App Engine's built-in OAuth provider. I love it because it's a built-in, out-of-the-box, free way to authenticate against someone's Google account. I hate it because if something goes wrong (it's listed as an experimental API, and things do go wrong) or if something isn't working as I expect (it differs from the main OAuth API in a couple crucial areas; mainly it seems to lag. It still uses 1.0a and will not accept xoauth_displayname), I have no real recourse. Beyond not being able to tell why getting a request token threw an error for 38 requests in the last 24 hours, besides undocumented differences between it and Google's regular OAuth offering (not even their 2.0 offering, which is now available in experimental status), my biggest gripe has to be one I discovered just recently: it will not allow a non-http, non-https callback URL. If the URL you are redirecting to uses a different protocol, it will error out. While this seems like a silly gripe, it's actually pretty important for Android developers who rely on callbacks to app-specific protocols to allow the OAuth flow to remain secure and user-friendly.

Those are the biggest gripes I have with App Engine for now. I'm sure more undocumented things I need to know will show up as I continue to learn more and more about the environment. I'm sure I'll be stymied in other places. But I reiterate the point I opened with: App Engine remains a wonderful, powerful tool that makes my development possible. These gripes don't come close to overshadowing the cause of them: the removal of the system from my list of "things I need to concern myself with" in most cases. Really, these gripes are created by the edge cases in which I do need to concern myself with the system.

The Problem With Tangential Learning

Last Thursday, my roommate turned 21. For her birthday, I baked her a batch of brownies. As college students, we don't have the world's greatest kitchen for baking (she told me she had everything! Steph, if you're reading this, your lies haunt my soul), so I had to make do with a less-than-ideal dish. It was too small in surface area, so the brownies ended up nice and thick. Which would totally be cool, if it didn't make baking them such a challenge. I was kept on my toes trying to keep the outer edges from burning while cooking the entire middle so we didn't end up with spots of raw brownies. In the end, it was a middling success (but, fortunately, it being her 21st birthday, I think she was too drunk to care).

This is a horribly transparent metaphor for the topic I want to discuss. Thanks in no small part to my business partner (if we're going to be entirely accurate, it's all his fault), I've become more or less addicted to Extra Credits, a video series on The Escapist. Extra Credits is what I would call an English major's take on video games, but I'm really giving too much credit to English majors with that. It's actually just video games and the video game industry being examined with critical thinking skills and the built-in assumption that video games are an art-form that are deserving of deep thought—an assumption I don't disagree with.

In one episode, however, I must disagree with them. Sort of. In their "Tangential Learning" episode, they tout the virtues of (spoilers) tangential learning and espouse the belief that this is the best way for video games to become educational without becoming boring. I think this is folly.

Don't get me wrong, I think tangential learning is great. It takes a proposition that I hold most dear (that students learn best when they're interested) and puts it into practice. It shows educators that the trick is not getting students interested in what you want to teach them, the trick is helping them learn what they're interested in. And that's wonderful. Great. Leaps and bounds above the current "I will force-feed you information and hope you remember it" model.

But we're only fooling ourselves if we think it's a silver bullet or even a bronze bullet. The vast majority of our learning cannot be done this way. If every game implemented this, or even most games, it would enrich our educational experience from video games, yes. But that is a far cry from saying it would make video games educational.

In the video, they mention the sephiroth and how Final Fantasy introduced that concept to thousands of people by naming a character after it. At the end, they said that if you didn't know what a sephiroth was and were going to go look it up, you knew that tangential learning worked. And I didn't know what it was, and I did go look it up. But that didn't prove to me that tangential learning worked. That proved to me that tangential learning gave us trivia. I knew what a sephiroth was, but I had no context for that information. My context was the game. In literary theory, we talk about how the original context a fact is learned in shapes the fact—I will always associate the Treachery of Images with Foucault and semiotics, because that's how I learned about it. I never learned about it as a visual art piece; I learned about it as a literary concept. Likewise, I'll never associate a sephiroth with its cultural and religious context, but instead with its gaming context.

The problem is, there is a lot to learn, a lot to be known. Kind of like those brownies I baked: the topic matter is deep, in that you can follow a single idea or topic for quite some time and discover a lot about it; broad, in that there are a lot of topics you can pursue; and (this is the important one) inter-connected, in that ideas give context to each other. Much like the heat had to penetrate from the outside edges of my brownies all the way in or there'd be raw areas, our education needs to cover a certain amount of broad topics, cover them deeply enough to make sure we grasp the nuances, and cover them in such a cross-disciplinary way that we can put them in the appropriate context in our mental picture of the world. Tangential learning doesn't give us that. Tangential learning is much like a scavenger hunt; you're given an interesting item, you go and retrieve it, but it isn't the item that's important—the retrieval is the important part.

I humbly submit that we need more than that in education. We need to have context and meaning for the trivia we're learning, or all we're really doing is making ourselves better Jeopardy players, not more rounded and educated individuals. Tangential learning is great in theory, but it falls short in practice. It's not, to use the educational theory background I paid so much for, theoretically sound. It ignores the instructional scaffolding theory set forth by Bruner, a theory that is generally accepted by the educational community. Knowledge is like a building; you lay the foundations, set up a scaffolding (I bet you see where the name comes from!), and build a lasting structure bit by bit, one piece on top of another. This is not what tangential learning is doing; tangential learning is throwing a shack up rather quickly. Yes, it will keep you dry in the short run, but it's not going to last long. And it's certainly not something you boast about, something that makes you a better person. The results are quick, but fragile and ultimately useless.

So, if tangential learning is right in theory but wrong in practice, how do we fix that? Much like Extra Credits, I believe games are one of the best positioned mediums for learning. Games are an inherently interactive medium, and (as tangential learning proponents have noticed) learning is (or at least, has become) an interactive process. There's a lot of talk that in our parents' generation, we learned through broadcast. Someone would tell us something, and we'd know it, and that was learning. I find that hard to believe. I find it hard to believe that being told something can ever constitute learning it—I think the correct word is believing it, which is a very different thing. Just look at the war between science and religion, and you'll see the gulf between belief and knowledge. They're antithetical. But I digress. Whether our parents' generation was interactively learning or not, our generation is. And our children's generation will almost certainly continue the trend. The fact that games have that interactivity in their DNA already puts them in a far better position than, say, television. Or books.

The trick is going to be using that interactivity to kickstart a learning process, not simply giving us allusions. Allusions are helpful, yes. They help to expose us to new areas we may not have explored before. But we cannot have an education based solely on allusion; we need structural support, a contextual mindmap to assimilate those allusions into. Rather than simply suggesting the player look up a sephiroth for a bit of trivia, the game should reward the player for understanding the sephiroth. Things should be easier. Or there should be more depth to the game for that player, more things to do. I agree with Extra Credits, however; the player should not need to understand a sephiroth to move forward in a game. One of the things that tangential learning gets right (and one of the things that terrifies traditional educators) is the surrender of this absurd notion of "curriculum"—the idea that there is a prescribed set of things that students should learn. Interest drives learning, and not everyone is interested in the same things. That's why the interactivity of games is an important feature; players shape the game just as much as games shape the players. It's a two-way relationship, instead of a broadcast. And in that two-way relationship, there's no room for one party to have control. One party can't be dictating to the other party; the relationship (like all relationships) will only work with communication and cooperation. Games need to offer their players this deeper meaning, need to offer a richer experience for those who are interested in learning about the topic, but not require that richer experience in case the player isn't interested. Because as soon as you start requiring players to do things they aren't interested in, things they don't care about, you start losing those players.

I can't see tangential learning or this interactive, cooperative educational system catching on anytime soon. Our education system is too mired in the idea that there needs to be a "standardised student" and that education needs to be heavily controlled and regulated. I hope, one day, our government and our educators will see that the more room you give a student to maneuver, the more room you're giving them to grow. I hope one day we'll see games replace textbooks, rewarding us for learning what we're interested in but not punishing us for having no interest in a topic.

Professionally Yours

We've been running a feedback survey for 2cloud for a couple of weeks now, trying to get a sense of how we're doing with the project. We've gotten some great responses (if they're not from you, please go ahead and take two minutes to fill out the form. We are leaving it open indefinitely), but one response we got bothered me:

"Bottom line you're sounding juvenile, when you want professional."

At what point did the person responding to that get the horribly inaccurate impression that we want to sound professional? We do not want to sound professional. We want to stay away from professional.

Let me start this explanation out by making a distinction. A professional person is responsible. A responsible person is not necessarily professional. The two go hand-in-hand, yes, but you can be responsible without being professional. That's what our project aims to do.

Professional is not what we want for a very good reason: professional is intimidating. Professional exists to create a barrier between two entities. There's a reason it's called "personable" and not "professionable". We want to be a personable project. We want to interact with our users, we want them to be in constant contact and feedback with us. We think this connection is a strength, not a weakness. So we do not want the barriers of professionalism raised between us and our users; we want to tear down as many barriers as possible.

A professional project does not send hand-written thank you notes from its lead to people who donate. A professional project does not engage in lengthy back-and-forth emails with its users. A professional project does not have its users on Instant Messengers and social networks.

We do. And if I have anything to say about it, we always will. Because I am not a professional, I am an amateur. I am a lover of software, of creating software, and of my users. And I'm not going to give that up so we can sound important and impressive.

I've always felt that if I'm not pissing anyone off, I'm not doing things right. If nobody's getting pissed off, nothing worth saying is being said, nothing worth doing is being done. Because everyone has their own preferences. The fact that my refusal to be professional is pissing people off is not a bad sign, in my mind.