Monday, November 30, 2009

Unit Testing Your Brain

This post has been stewing around in my brain for awhile. I've wanted to write about memorization and it's role in being a productive programmer. For many a developer, the web acts as a useful crutch (and I'm as guilty as anyone).



As an example, I noticed that every time I wanted to do some type of regular expression operation in java, I almost always resorted to googling for a java regex tutorial to relearn how to do it. It's really quite an easy api to use, but it was one of those things that just wouldn't stick in my head for more than a few days at most.

There is a class of general programming tasks that I don't do frequently enough to have them automatically committed to memory, but at the same time I do use them frequently enough that I found myself wasting time relearning things over and over again. After relearning the same thing 3 or more times, I started asking myself if there wasn't some tool I could use to improve the situation.

I had a discussion about this with Curtis Dunham, who introduced me to a really neat, but hard to pronounce application called Mnemosyne.

Mnemosyne is a GUI app, written in Python and runs on all the popular platforms. It acts as a system of flash cards. You create a "deck" of cards with questions and answers, and invest a few minutes of your time each day answering them. As you answer each question, you rate your memorization on scale of 1-5. Mnemosyne then uses this information to create a dynamic schedule of questions for you based on what you're having the most trouble memorizing.

The way I use it is analogous to a common unit testing technique, where whenever you have a program fault, you create a unit test for that specific fault, and then implement a fix. I apply this same technique with Mnemosyne. If I am faced with a programming task that I can't remember how to perform, but I at least know that it was something I had already learned once before (a memory fault), into the deck it goes. The deck acts as a suite of unit tests for my brain this way.

Now if I want to do a pattern match in Java, I no longer spend time looking for examples in old source code or hitting up search engines. Mnemosyne is a free app, that with a small investment, can pay large dividends.

Saturday, November 21, 2009

Personal Update

I've been too busy lately to keep the blog updated, but life will be getting back to normal shortly. My family has just finished relocating from Dallas, TX to Dayton, OH.

I've been working fulltime at TuneWiki Inc since August, developing some very exciting products. I'm now working out of their central development hub with fellow Android hacker Zach Hobbs.

The team here is great, I expect to be both contributing and learning a lot. I've got a backlog of blog articles I need to hammer out.

Saturday, August 22, 2009

Building location aware applications

There are 3 basic ways your typical smart phone can acquire a location fix, these being :

  • Cell Tower Triangulation
  • GPS
  • WiFi Scanning
Cell Tower Triangulation is the least accurate of the 3 methods. The accuracy varies by about 2-5 km in my experience. But it does have a couple of advantages, it works fine indoors and is quick to compute.

GPS is the one most people are familiar with, and it offers the highest accuracy. It can pinpoint your location down to a few meters. However, it typically doesn't work well indoors (if at all), and acquiring an accurate fix can take up to several minutes. The longer the GPS is running the more accurate a fix can be obtained.

WiFi Scanning is relatively a new idea and is pretty interesting one. Imagine sending out a fleet of vehicles down every major thoroughfare, each armed with sensitive WiFi detection equipment. You then record the location of every WAP they detect along with the relative signal strength. Once you've collected enough data, any WiFi enabled device in the area can look around at the nearby WAPs (it doesn't actually have to connect to them), and use the data to deduce a reasonable approximation of the device's current position. It's fast to compute, it works indoors, and has decent accuracy (I typically get about 200m). Another interesting aspect of this type of system is that it can correct/improve itself. If you have a WiFi fix and a GPS fix at the same time, that information can be recorded to improve accuracy in the future.

You want to avoid writing any type of application that requires continuous/real-time location data for extended periods of time. The bottom line is, if you're crunching GPS data, the CPU is not sleeping, and you're running down the battery. The best you can do is to wake the device up at repeated intervals, get a fix, and then let it go back to sleep. This is a realistic technique and it works, but is not without limitations. An application designed to alert you when a friend is "nearby", would always have the chance of not polling for a fix was while your friend was within range. So you have to find a balance between the polling frequency, and the granularity that your app requires.

Also never underestimate the finicky nature of users regarding battery life. If they feel their device's battery is suddenly under-performing, they will look for an application to blame. If they see a flashing GPS icon, it's usually the first thing that raises an eyebrow.

Wednesday, August 19, 2009

blog relocation

This blog has been relocated to http://foo.jasonhudgins.com/, if you try and hit the old blog page you'll be redirected here. I'm currently swamped with work and falling behind on my blogging, but I've got a couple of new posts floating around in my head.

Monday, August 3, 2009

HTTP connection reuse in Android

Alright, time for something new and hopefully useful, re-using HTTP connections in your application.

I've yet to write an Android application that doesn't make any HTTP requests, and they tend to do it frequently. Since all of my applications are also heavily concurrent, passing around a default HttpClient instance will give you thread contention issues and possibly bad dreams later that night. Establishing a new TCP connection to the same server for each request is wasteful, so I'd like to be able to re-use those connections, via the same HttpClient, and do so in a thread safe way.

This is easily accomplished with a singleton/factory thingy like so:


public class HttpClientFactory {

private static DefaultHttpClient client;

public synchronized static DefaultHttpClient getThreadSafeClient() {

if (client != null)
return client;

client = new DefaultHttpClient();

ClientConnectionManager mgr = client.getConnectionManager();

HttpParams params = client.getParams();
client = new DefaultHttpClient(
new ThreadSafeClientConnManager(params,
mgr.getSchemeRegistry()), params);

return client;
}
}

Now whenever you need an HttpClient instance in your app, you can just do this:

HttpClient client = HttpClientFactory.getThreadSafeClient();

Like most things in HttpClient 4.x, it's very easy to do, the hardest part is just figuring out exactly how to do it. A buddy @google told me that 4.x just performs so better than 3.x that was the reason for the behind switch (early versions of Android used the 3.x releases). Until next weekend..

Saturday, July 25, 2009

Blogging Again


I've been neglecting this blog for far too long, so it's time for me to get off my lazy butt and write some posts. To kick things off I've revamped the TrivialGPS tutorial I did back in Xmas 2007. I thought it looked trivial then, now it's really trivial, but here's a link to that old post entitled 'Crusing around with android'

I'm also promising myself that I'll write up a new blog post every weekend. I don't know if I'll actually be motivated enough to pull this off with all the other stuff I've got going on, but feel free to send me a scolding email if you think I'm getting too much like the above pictured bear... Rawr..

Tuesday, February 3, 2009

Startup Happy Hour

I met Paul Urbanas at the startup happy hour last night, who created the game Parsec for the first computer I ever had, the TI-994a. That game came out in 82, way back when I was in second grade, and I played the hell out of it.

If you're in Dallas and haven't checked out the startup happy hour events at the infomart, you should definitely consider attending, you never know who you'll run into!