Archive for the ‘programming’ Category

Hacking the Human Brain

Sunday, March 6th, 2011

Back in 2008 I was frequently riding a train twice a day for a ridiculous ~3 hour (each way) commute that nobody on this planet should ever have to do. Needless to say, I did a lot of reading, particularly issues of Wired Magazine. To this day, one article still stands fresh in my mind, which essentially dealt with the concept of surrendering your brain to an algorithmic approach to memorization. The man behind the core of the theory is Piotr Wozniak, a gentleman out of Poland who still somewhat astounds me to this day.

I won’t reproduce the theory in full here, as the Wired article does a much better job writing things up, but the core things to take down are that the human brain tends to have times when it memorizes better or worse, and it’s possible to capitalize on these moments to increase your potential for solidly committing something to memory. SuperMemo is an effort to implement this in software. It’s cool and all, but I’m not sure I’m in 100% total agreement.

Hack Faster, Please.

You see the thing about the theory is that your core memory might work on a two week cycle; learn something today, see it again in two weeks, and if everything holds true you’ll probably never forget it. However, I disagree with the concept that short term memory commitment can’t be stronger for certain concepts.

Take something like teaching yourself a new language. If it’s something truly foreign to you, the characters won’t make sense, the pronunciations will sound totally off, and there’s a good chance that anyone who’s not forced through it will give up in about a week or two. Long term memory won’t have a shot in that case; maybe not due to any particular flaw in the theory, but merely due to the lack of willpower some people have. In addition you have to factor in the concept of age: as we get older, our memory and the way it works through concepts changes. Short term memory is nowhere near as slighted when up against these two conceptual foes; are we certain there’s no good middle ground to hit?

Can It Be Proven?

So let’s provide a short bit of backstory here. This past week (beginning of March, 2011), I got the awesome opportunity to work with the folks at myGengo, a company that builds tools to help ease translation efforts. This required heading to Tokyo – for the astute, I had visited Tokyo some months prior, so I wasn’t a total stranger to what I’d experience upon arrival. I do want to learn the language, though.

A typical approach for character memorization would be to make flash cards, sit down and repeatedly run through them. I won’t lie, this bores the hell out of me. I’d much rather have something portable that I can use on the train when I’m traveling in the mornings. To that end, I just went ahead and built an Android application (app) to do this.

Katakana on the Android Market

Now, since I was already creating an app for this, I figured I could take some liberties. With the theory still lingering in the back of my head, I began to muse: what’s my own learning pattern like? Well, for the past (roughly) seven years I’ve learned things incredibly quickly. In some cases this was by design, in other cases… well, you get the idea.

The thing is that it’s worked for me so far, and it’s the same for many other programmers I know. Programmers far and wide can attest to the fact that while there’s no doubt benefits to the long-term memorization benefits, we consistently rely on short term to do our jobs. We accrue a sometimes ridiculous amount of information in a short period of time that will instantly come back to us when we need it. The key is, of course, when we need it, generally through a trigger (a linked piece of information, for example).

The Theory Itself

So this theory started formulating in my mind. What if I could apply elements of Wozniaks theory to short term memory, and then rely on the trigger to pick up the rest? Even in short term memory I found that I, personally, had a few-minutes window where if I reviewed the same concept, I’d commit it pretty quickly. The triggers, in this case, will be as I walk down the streets of Tokyo or read a menu.

I got down to building the app. The core details of building an Android app are outside the scope of this article; the algorithm I threw in is worth detailing a bit, though. In my mind, when you use an app on your phone, you’re going to use it, at most, for five minutes. The app concept just lends itself to this, a bunch of miniature worlds that you can hop in and out of at will. So with that in mind, I set the high barrier for this experiment at five minutes – roughly the maximum amount of time I expect someone to stay engaged.

I’m assuming, based on my own use cases and the trials of a few friends, that on average I can expect people to get through roughly three cards in a minute. At five minutes, fifteen cards, not too bad. The question of where to ‘re-appear’ content then came up – for this, I first settled on throwing it back in the users face every couple of minutes. The number of minutes is variable; it starts off set at one minute, but will adapt based on whether or not you answer correctly as things re-appear. If you memorize things at the four minute mark, for instance, it’ll edge towards that – never 100% four minutes due to the relative inaccuracy of Android’s timing, mind you, but it gets the job done.

I’ve been using the application myself for roughly two days now, and it’s easily topped any effort I put in with books or traditional methods over the past two months. It’s worth noting that I still can’t write Japanese to save my life, but that’s also a two fold issue: characters can be quite complex (kanji), and don’t lend themselves well to a trigger-based scenario for recall. However, if I’m looking at a character screen, I can at least make some sense of what I’m seeing now.

Taking This Further

My theories aren’t proven, but then again, it’s the human brain we’re dealing with. I released the Android app as a test of my take on Wozniak’s theory with a bit of my own magic; based on how well it does, I’ll release apps for Hiragana, Kanji, and anything else applicable. I personally believe that the effects of memory commitment through short term memory optimization can be optimized, and this is a pretty great and open way to give it a whirl.

Emulating Ruby’s “method_missing” in Python

Tuesday, November 2nd, 2010

I don’t pretend to be a huge fan of Ruby. That said, I can respect when a language has a feature that’s pretty damn neat and useful. For the uninformed, method_missing in Ruby is something like the following:

Obviously, this is a trick that should be used with caution. It can make for some unmaintainable code, as a class with many methods could get difficult to trace through and figure out just what the hell is happening. It can be put to good use, though – take an API wrapper, for instance. What’s it consist of? Generally, nothing more than the same function calls made over and over to various service endpoints.

Cool, let’s use this in Python!

I recently rewrote Twython to support OAuth authentication with Twitter (as of Twython 1.3). It ships with an example Django application to get people up and running quickly, and the adoption has been pretty awesome so far.

The funny thing about the Twython 1.3.0 release is that it was largely a rewrite of the entire library. It had become somewhat unwieldy, some odd two thousand lines of code with each API endpoint getting its own method definition. The only differing aspect of these calls is the endpoint URL itself. This is a perfect case for a method_missing setup – let’s catch the calls to non-existent methods, and grab them out of a dictionary mapping to every endpoint.

The source above is fairly well commented, but feel free to ask in the comments if you need further explanation. This resulted in a much more maintainable version of Twython – for each function that’s listed in a hash table, we can now just take any named parameter and url-encode/combine it. This makes Twython pretty API-change agnostic of the entire Twitter API. Pretty awesome sauce, no?

On Date/Time/DateTime in Ruby, and why they suck

Sunday, July 18th, 2010

Yeah, there, I said it – this is a stupid situation for a language to be in. The concepts of Date, Time, and DateTime are all pretty well related – Date is a point in Time, DateTime is a really nice representation of Date and Time mashed together.

In a world that actually makes sense, you’d be able to easily convert between these types (e.g: DateTime should be able to easily convert over to a Time object). Some people might suggest patching the aforementioned classes (like Rails does, for parsing relative dates), but this just feels like an incredibly hacky solution.

Now, normally, I’m not much of a Ruby guy, give me Javascript any day. However, there are a lot of awesome projects written in Ruby, and it’s hard to deny that they’ve easily got the best packaging solution for any language. As it so happens, earlier this week I was hacking on a little Sinatra side project. DataMapper was my ORM of choice here, because it’s just so beautifully plug and play.

In the example app we’ll look at, it’s your basic Post/Comment scenario. For each Post/Comment, we want to be able to render the relative time ago that the item in question was submitted (e.g, “16 hours ago”, etc). Rails has conventions for this baked in by default (because they, y’know, enjoy polluting namespaces, go figure). When you’re outside of Rails and want to do this, it’s somewhat more difficult.

Originally I started by storing the creation time as DateTime; makes sense, we should be able to convert this to Time to do easy comparisons against Time.now, right?

Well, uhh, no. Definitely not that simple. After some digging around, I discovered the dm-types gem, which adds some extra types to DataMapper. One of these types is known as EpochTime, which is (you guessed it) the time since Epoch that the entry was created.

With that, we can pretty much stay within the realm of Time. Ripping apart ActionView gives us a good base to work with on the act of getting a relative string; putting it all together, we get the following Sinatra app (two files – the main Sinatra app, and our custom date_helper library).