Imposterrific - a blog by Jeff Scudder

Go on App Engine Example - Part 1

2011-05-28T01:35:00.001-07:00

The App Engine team recently announced support for Go as a runtime for use in apps. Summary up front, the App Engine SDK for the Go runtime is the easiest way I've found yet to get started with Go. As I change my code, it is recompiled in the background when I make a request to my app, so it feels very much like developing in a scripting language.

I've been excited about the Go language for some time now (specifics on why will have to wait for another post) so I was eager to try it out in one of my favorite platforms: App Engine. I wanted to start with something small, so I wrote a simplified version of a web app that I've been itching to write lately, a site for hosting plain text content. Specifically, I want something that preserves whitespace, allows me to line up columns of text, and supports non-English characters (Unicode). Those are the kinds of things I need to share and talk about code. Also there is a great deal more you can do with plain old monospaced text, maybe you'll find this useful as well.

With that objective in mind I give you the Plain Text Machine. This little app lets you enter a small amount of text, somewhere around 2,000 characters, and gives you a link that others can visit to see an HTML reproduction of your writing. I mentioned I wanted to keep this simple, so here's the odd little bit, this app doesn't store your text anywhere. The URL that is generated contains the text, hence the somewhat low limit on message length. It certainly keeps the app simple, the most complex logic is that which converts the text from the URL into HTML.

A request starts by hitting the Init function:

func init() {
 http.HandleFunc("/", handle)
 http.HandleFunc("/show", show)
}

The main page, at /, is just static content, we're just interested in the /show handler. It looks like this:

func show(w http.ResponseWriter, r *http.Request) {
 w.Header().Set("Content-Type", "text/html; charset=utf-8")
 // Get the message from the URL.
 PrintHtml(utf8.NewString(r.FormValue("msg")), w)
}

The above does two things, sets the content type of our response so that the browser will know it is HTML, and reads the message URL parameter from the request to convert it to HTML.

The PrintHtml method prints out some boilerplate HTML then reads the message one character at a time and converts each character to its HTML-safe equivalent. There's a tiny bit of complexity to make sure that the whitespace is preserved instead of being collapsed as would normally be done with repeated spaces in HTML. Here's the code:

func PrintHtml(text *utf8.String, out http.ResponseWriter) {
 spaces := false
 
 fmt.Fprint(out, textHeader, middle)
 for i := 0; i < text.RuneCount(); i++ {
  currentChar := text.At(i)
 
  if currentChar == 32 && !spaces {
   // A first space.
   fmt.Fprint(out, " ")
   spaces = true
  } else {
   if currentChar == 32 {
    // Space following another space
    fmt.Fprint(out, "&nbsp;")
   } else if currentChar == 10 {
    // Newline
    fmt.Fprint(out, "<br>")
   } else if currentChar == 9 {
    // Tab
    fmt.Fprint(out, "&nbsp;&nbsp;&nbsp; ")
   } else if currentChar == 38 {
    // &
    fmt.Fprint(out, "&amp;")
   } else if currentChar == 60 {
    // <
    fmt.Fprint(out, "&lt;")
   } else if currentChar == 62 {
    // >
    fmt.Fprint(out, "&gt;")
   } else if currentChar < 31 || currentChar == 128 {
    // Skip control characters.
   } else if currentChar < 127 {
    fmt.Fprintf(out, "%c", currentChar)
   } else {
    fmt.Fprintf(out, "&#%d;", text.At(i))
   }
   spaces = false
  }
 }
 fmt.Fprint(out, footer)
}

The textHeader, middle, and footer variables are string constants containing the wrapper HTML which gives style information.

If you're interested in the full source code for this tiny little app, you can find it in the Plain Text Machine open source project. Hopefully this example provides an easy to understand picture of what Go code for App Engine looks like.

I had quite a bit of fun putting together this app. By keeping it simple I was able to go from idea to done in less time than it took me to write this blog post. As an added bonus, having an app with no persistent storage brings up some interesting philosophical questions. For example, if a message is created but no one stores the link to it, does it still exist?

Setup OAuth2 for Google APIs

2011-05-09T13:21:00.000-07:00

Today I'm at I/O Bootcamp and helping out with a walkthrough on how to get starting using Google APIs in a variety of languages.

One of the things I appreciate about the Google APIs is the authorization mechanism which lets me see which applications I've granted access for my data and allows me to revoke access. As an application developer, there are some things that I need to do to identify my application so that Google knows which app is requesting access so that it can show the user more information about my app. The first step, then, in writing an application that uses OAuth2 is registering your app.

You can begin the registration process on the Google API console by creating a project:

Now that you have an application, you'll need to configure it for use with OAuth2 and get the secret tokens that your application will use in its requests. For that create an OAuth2 client ID.

The most vital decision to make during the sign up flow is if your application is a "web application" or an "installed application". If you're a site accessed in a browser and you're able to send the users to a Google web page for authorization and then have the broswer redirect back to your app, then you want web application. For an installed application, the user will still need to authorize your app by visiting a web page, but once authorization is complete, the secret token will be sent to the app either using a redirect to a local running web server or by having the user copy and paste the secret into your application.

For the command line samples I've been playing with I choose installed application.

After creating the client ID you should see information something like this

Client ID:      #######.apps.googleusercontent.com
Client secret:  Amzz5Yip2SJPqqq5Jx
Redirect URIs:  urn:ietf:wg:oauth:2.0:oob
                http://localhost

You'll need to put this information into your application so that it can use the client ID and secret when making requests to get an authorization token from the user. This can be as simple as copying and pasting these strings into your code.

The one other thing that needs to be done before you begin using OAuth2 with one of the Google APIs is to turn on the API for your application. This can be done on the developer console "Services" section.

Let's say that I wanted to access the URL Shortener API. First I would need to enable it for my application.

Then I would need to specify the URL Shortener's API scope when I request authorization from a specific user. The scopes that are requested by my app are turned into a list of APIs that the user must grant access to when they authorize my application.

The scope for an API can be found in the API documentation under authorization.

For an example that brings all of these settings together, see the urlshortener.py example:


  FLOW = OAuth2WebServerFlow(
      client_id='433807057907.apps.googleusercontent.com',
      client_secret='jigtZpMApkRxncxikFpR+SFg',
      scope='https://www.googleapis.com/auth/urlshortener',
      user_agent='urlshortener-cmdline-sample/1.0')
  ...
  credentials = run(FLOW, storage)
  ...
  http = httplib2.Http()
  http = credentials.authorize(http)

Python may not be your bag, but no worries, there are client libraries for the Google APIs in a variety of languages, and even better, there is an API Explorer that lets you try out the underlying protocol without any language specific stuff getting in the way.

For example, here is getting details and stats about a short URL:

And here is creating a new short link:

For all the details on using these APIs, take a look at the documentation. For example here are the URL shortener docs. The common first step for almost all of the Google APIs that access user information is the registration step we started with. For more details on OAuth2 with Google APIs, there is some excellent documentation here.

Free Verse #397

2011-03-08T07:19:00.000-08:00

Sipping a late,
writing a free verse poem.
Hey look, a haiku!

Mercurial in Five Commands

2011-01-23T22:12:00.000-08:00

Completing any sort of significant programming project can be nearly impossible without version control. For a class project, I recently collaborated with a small group on a large programming assignment. To keep all of our changes in sync while working miles away from each other, we used a centralized version control system.

Since I've been working quite a bit with Mercurial lately, we went with a free private project on bitbucket. It was the first time my teammates had used Mercurial so I gave a crash course that I thought would be helpful for others as well. A distributed version control system has a large number of commands and features, but 90% of the time, you're just dealing with the basics. When working with a team you can get by with just these five Mercurial commands: clone, commit, push, pull, and update.

Setting up the Project

As I mentioned, we were using a hosted repository on bitbucket, so getting a working copy of the repository on our machines started with each of us executing hg clone. It looked a little something like this:

hg clone https://your-username@bitbucket.org/your-username/project

This will create a local repository with a copy of each file and you're now free to make changes. You can edit files locally and Mercurial will track the changes for you. If you want to add new files or remove existing files, make sure to use hg add and hg remove. (Bonus commands!). Once you're happy with your changes and you want to gather them up in a logical unit it's time for:

Local Snapshots

To save a set of changes locally, you use hg commit. Be sure to write an informative description of this change set since you and others will want to remember what this set of changes was all about. There are a few arguments to the commit command that come in handy, often I do:

hg ci -u your-username -m 'Reduces codebase entropy. All tests pass!'

For more options on the commit command and any other Mercurial command you can use hg help <command>. You can also see a diff of your current files compared to the most recent snapshot using the hg diff command. (Bonus times two!)

Pinning your changes locally is a fantastic feature of distributed version control systems. As I work I tend to take a local snapshot several times an hour. These revisions just exist in your local copy, so you don't need to worry about clashing with other people's code at this point or making sure that all changes are usable. Sometimes when I decide I've gone down the wrong path I'll take a snapshot of the ill conceived changes before I roll them back, just in case I decide later on that some of the ideas weren't so bad after all.

Once you have something that's ready for others to use, it's time to:

To get your changes into the hands of others, you can push them back up to the central repository. You do this with the hg push command. Since we created our local repository using clone, your local copy knows where to send the changes. Also, if you'd like to do something different, like push your changes to a different location than where we cloned from, you can take a look at more options of the push command using hg help push.

The push command will upload all of your local commits, along with those handy descriptions, for the rest of your team to see.

Now others on your team are pushing up their changes too and it would be great to get their changes so you are all working on the same code. What's that saying, "It's better to give than to...?"

Receive

To get the changes others have posted to the repository into your local copy, you use hg pull. Running this command copies the change sets that you haven't received yet to your local repository, but it doesn't edit your files or apply the changes just yet. Since you might want to be selective about what changes you apply, Mercurial splits applying the changes into two steps. First you pull, then you use hg update. When called with no additional arguments like that, hg update applies all of the changes.

I recommend pulling and updating often. In our group, since there were just a few of us, we'd post in a chat room when we pushed changes so others would know to pull. If you push before you pull in other people's changes, you might need to use hg merge. Also, you can see all of the changes which are in your repository with the hg log command. (Triple bonus, hey a hat-trick!)

There you have it!

Want more?

I tried to keep this simple and focused, the bare minimum to work on a project with a small team. Mercurial has more to offer. I haven't touched branches yet, or looking at diffs, or creating your own local repository from scratch, or sharing your changes by running your own server locally. All of these are just single commands! For further reading take a look at Mercurial: The Definitive Guide.

There are a few services which offer hosting of Mercurial repositories. For open source, Project Hosting on Google Code is an option as well as bitbucket which I used for the first time this past week. Any other Mercurial hosting providers that you recommend?

Greekish

2010-09-10T22:56:00.000-07:00

I've long been fascinated with other alphabets. All of these strange and unusual symbols, it's almost like a code. This love of secrets was one of the reasons that I studied Ancient Greek. After reading and writing quite a bit of Greek, reading the alphabet became second nature. I even began taking notes using the Greek alphabet but using English words (since my Greek vocabulary is sadly inadequate). Performing simple character substitution sounded like a perfect one-hour project so I whipped up a simple web page to convert English text into a Greek alphabet equivalent. I call it Greekish. For example, the phrase

So long and thanks for all the fish.

becomes

Σο λονγ ανδ θανκσ φορ αλλ θε φισh.

which would be quite confusing to a Greek speaker but perfectly natural to an English speaker who knows the Greek alphabet.

Note that some English characters do not have direct equivalents in Greek. A c would be a κ, a σ, or a χ for ch. The h is one of the more interesting stories. For a leading h before a vowel Greek uses a breathing mark. When combined with a consonant, special characters are used, like θ for th, χ for ch, and φ for ph. I chose to use φ only for the English f, not ph, since ph does not make the f sound in some English contexts. The word uphill is one example. Also, I didn't bother to handle the special case of s at the end of word, for which ς is used instead of σ.

Now that you know more than you ever wanted to about the Greek alphabet, what is a simple project that you can tackle in an hour? Don't just think of one, go do it!

A Simple Testing Library for C

2010-06-22T01:24:00.000-07:00

To prepare for a recent post graduate computer science class, I wrote a small library in C which aids in the creation of lightweight, unit-test-like programs. The code can be found here, and using it looks a bit like this:

#include"asserts.h"

int main(void)
{
  c7e3_assert(1 == 1, "1 should equal 1");
  c7e3_assert(2 == 2, "2 should equal 2");
  c7e3_report();
  return 0;
}

The design follows the KISS principle and I think it is a nice fit to the simplicity of C. While there is not much to it, I wrote numerous tests using it over the past couple of months and all of that testing certainly paid off.

JavaScript Tricks to Speed up Your Site

2010-06-18T00:30:00.000-07:00

One of the techniques which makes the web so powerful is the ability to load code, images, and other resources from all over the Internet. So often though, the process of loading these resources and ensuring that all of the required pieces are in place leads to a slow experience for visitors. With the ability to include so much code from across the web, visiting a site could potentially be like installing a new program when it comes to the amount of stuff that needs to be downloaded.

With this in mind, there are a couple of nifty tricks that can help make your app more responsive and I've written up an example site and testing server that shows some ideas for speeding up the user experience when you need to wait for the DOM to load or for additional JavaScript to be fetched and run. We'll begin with document operations.

Often the JavaScript running on a page manipulates the DOM, using document.getElementById here and document.createElement there. In order to ensure that all the pieces of the page are in place, web programmers often take advantage of the onload callback. It might be used like this

<body onload="runMyCodeNow()">

Using this technique ensures that all of the things your code might want to read and write from the page are in place. All images have been downloaded, CSS rules have been applied, the layout is all there. However, all of this comes with a cost, your code doesn't run until every last resource has been fetched and rendered. Even the little footer at the bottom of the page, for example, that your code doesn't care about.

There is a another way, we could request that resources be loaded in parallel and start executing our code before the page is fully loaded. Chances are, your code doesn't need the complete page to be loaded before it starts running, and running before onload will reduce the delay for your users. Before I dive into how this can be accomplished, lets look at an example which uses the old fashioned way.

Lets say you have a web page, a little HTML which includes five JavaScript files. One may be a library used to do animation, another one for loading the users data. In any case, all of these files need to be loaded and some of them depend on others.

The biggest bottleneck for your users is almost certainly having all of these resources load. Network latency is a killer, and something that is often overlooked during development. To create a simulated network environment which can give a more realistic (or even pessimistic) view of the cost of loading these resources, I wrote a "slow server" which can introduce a delay to the file requested. Here is the code for my testing server (designed to run on App Engine):

def FilePath(path):
  """The requested path into a local file path."""

  return os.path.join(os.path.dirname(__file__), 'files', path[1:])


class SleepyRenderer(webapp.RequestHandler):
  """Serves the requested page with a client configured delay.

  Delay is given as a URL parameter in hundredths of a second to delay.
  For example, 200 means wait 2 seconds before responding.

  Example request:
  http://localhost:8080/hi.html?delay=300&contenttype=text/html
  """

  def get(self):
    path = self.request.path
    delay = self.request.get('delay')
    content_type = self.request.get('contenttype') or 'text/html'
    if delay:
      time.sleep(int(delay)/100)
    http_status = 200
    requested_file = None

    try:
      requested_file = open(FilePath(path))
      self.response.out.write(requested_file.read())
      requested_file.close()
    except IOError:
      http_status = 404

    self.response.set_status(http_status)
    self.response.headers['Content-Type'] = content_type


def main():
    application = webapp.WSGIApplication([('/.*', SleepyRenderer)],
                                         debug=True)
    util.run_wsgi_app(application)


if __name__ == '__main__':
    main()

With the above code we can introduce a delay on each individual file. To see this in action with our example, here is some HTML which shows a traditional approach, include script includes and an onload callback when everything has loaded.

<html>
  <head>
    <script src="/testa.js?delay=500&contenttype=text/javascript"></script>
    <script src="/testb.js?delay=400&contenttype=text/javascript"></script>
    <script>
      function init() {
        document.getElementById('output');
        output.innerHTML = [
          'a is ' + a,
          'b is ' + b,
          'c is ' + c,
          'd is ' + d,
          'e is ' + e
        ].join('<br>');
      }
    </script>
    <script src="/testc.js?delay=300&contenttype=text/javascript"></script>
  </head>
  <body onload="init()">
    <script src="/testd.js?delay=200&contenttype=text/javascript"></script>
    <div id="output"></div>
    <script src="/teste.js?delay=100&contenttype=text/javascript"></script>
    <script src="/testa.js?delay=500&contenttype=text/javascript"></script>
  </body>
</html>

With the above, the page takes several seconds to load and when the very last script has loaded, the 'output' div gets its contents. In many cases, the code really doesn't need to wait for all resources to load, only the ones that are necessary for the code to run. In this case, since the information is added to the output div, we need the output div to exist in the DOM, but we may not need the entire page to load.

If you look at this loading process in a profiler you might see something like this:Now for our first nifty trick. One way to check to see if the necessary prerequisites are present, is by polling the DOM or the JavaScript environment, to see if conditions are right for the code to run. Here is an example of how this code might be rewritten when using some polling helper functions:

    <script>
      loader.whenNodePresent('output',
        function() {
          var output = document.getElementById('output');
          loader.whenReady(function() {return window['a'];},
              function() {
                output.innerHTML += 'a is ' + a + '<br>';
              }); 
          loader.whenReady(function() {return window['b'];},
            function() {
              output.innerHTML += 'b is ' + b + '<br>';
            }); 
          loader.whenReady(function() {return window['c'];},
            function() {
              output.innerHTML += 'c is ' + c + '<br>';
            }); 
          loader.whenReady(function() {return window['d'];},
            function() {
              output.innerHTML += 'd is ' + d + '<br>';
            }); 
          loader.whenReady(function() {return window['e'];},
            function() {
              output.innerHTML += 'e is ' + e + '<br>';
            }); 
        })
    </script>

The code to track the prerequisites and poll is quite simple:

loader.waiting = [];


loader.whenReady = function(testFunction, callback) {
  if (testFunction()) {
    callback();
  } else {
    loader.waiting.push([testFunction, callback]);
    window.setTimeout(loader.checkWaiting, 200);
  }
};


loader.checkWaiting = function() {
  var oldWaiting = loader.waiting;
  var numWaiting = oldWaiting.length;
  loader.waiting = [];
  for (var i = 0; i < numWaiting; i++) {
    if (oldWaiting[i][0]()) {
      oldWaiting[i][1]();
    } else {
      loader.waiting.push(oldWaiting[i]);
    }
  }

  if (loader.waiting.length > 0) {
    window.setTimeout(loader.checkWaiting, 200);
  }
};


loader.whenNodePresent = function(nodeId, callback) {
  loader.whenReady(function () {
    return document.getElementById(nodeId);
  }, callback);
};

In the above we use the whenReady function which takes a couple of functions, one to return a truthy or a falsey value, and one to call back when the first function evaluates to true. If the condition function isn't true when this first call is made, we check back every so often to see if it is ready.

With these changes, we shave several seconds off of the user perceived loading time. Specifically we no longer need to wait for the duplicate load (of the testa script) at the end of the body. The page also appears to be more responsive because the later script's messages appear just after they load but before the page is complete.

Now that we've seen a way to work around the need for an onload callback, lets look at another place we can tweak the browser's behavior to make a web page more responsive: dynamic script loading.

The most straightforward way to include new code in your page is to use a script tag, something like:

<html>
<head>
<script src="some_great_sites_javascript">
...

When the browser's JavaScript interpreter encounters this script src, it stops whatever it's doing and fetches that resource. It doesn't do any more rendering or executing of code until it's finished. This behavior varies a bit in different browsers and is likely an artifact of an old design in which this kind of single threaded behavior was the only option. Since some sites might depend on this linear behavior to get a script's dependencies all in order, this quirk might be with us for a long time. Most of this time, waiting like this is a really silly idea. How often do the scripts that you include depend on one another?

There are a few parts to this trick. The first is to not put all of script includes in the HTML, you could have JavaScript add new script elements to the page which will cause new code to be loaded as needed. In this way, you could load only the resources that are needed at the moment, perhaps some resources would not end up being requested at all. Including a new script could be done in two ways:

document.write('<script src="somefile.js"></script>');

var newScript = document.createElement('script');
newScript.src = 'somefile.js';
document.body.appendChild(newScript);

Each of the above is appropriate in different situations. Document write adds HTML directly into the page at the point where the page is being loaded, it should only be used for script tag inclusion if the page is not yet loaded. If that page is loaded, using document.write to add the script tag will wipe out the existing body entirely. I've seen this issue in the wild, if you assume document.write is always safe, you'll be bitten when using it after the page has loaded.

Instead you can perform a check to see if document.body exists, if it does then use document.body.appendChild. If it does not yet exist, use document.write. The code for this loader logic might look something like this:

loader.loadScript = function(url) {
  if (document.body) {
    var newScript = document.createElement('script');
    newScript.type = 'text/javascript';
    newScript.src = url;
    document.body.appendChild(newScript);
  } else {
    document.write('<scr' + 'ipt type="text\/javascript" src="' +
                   url + '"><\/scr' + 'ipt>');
  }
};

Now we can request that new JavaScript code be loaded on the fly and it works when the page has not yet finished loaded as well as after it has.

There is one more trick we can add to this loader. Some browsers will interpret the JavaScript in the order in which the scripts were requested, not the order in which they finished loading. That means that a fast loading script further down the list won't be run until a slower script, which appears above it, is loaded. One way we could defeat this delay, is to break the script includes out of linear execution in the JavaScript. If you use setTimeout to introduce a delay in adding the script include to the page, then the code which sets up the script requests can finish quickly and the browser will get back to the script requests later without the same linear constraints. In our code, we wrap the section of loader.loadScript in a short timeout as follows:

loader.loadScript = function(url) {
  window.setTimeout(function() {
    if (document.body) {
      var newScript = document.createElement('script');
      newScript.type = 'text/javascript';
      newScript.src = url;
      document.body.appendChild(newScript);
    } else {
      document.write('<scr' + 'ipt type="text/javascript" src="' +
                     url + '"><\/scr' + 'ipt>');
    }
  }, 1);
};

With the above changes in place, our example page from before now loads like this when profiled (note that the messages appear in the order that the scripts were loaded, we don't have to wait for everything before we edit the page):Through the course of this post, I've written a small library for using these tricks when loading JavaScript dynamically in the page as well as a server for trying it out. These are available here as open source code. There are some improvements that could be made here. Off the top of my head, the checkWaiting function could eventually time out if a condition continues to not be met. Also the loader could do more to check to see if a requested script has already been loaded. Any more ideas?

Quite a View

2010-03-12T20:26:00.001-08:00

I recently had the privilege of working out of an office near the beach. The sun, the ocean breeze, the pounding of the surf. Laptop makers should really come up with a way to sand-proof these machines.

I fully expect that this will draw some inside jokes from a few of you in the #googleajaxapis IRC channel.

New Blog Template

2010-02-08T22:51:00.001-08:00

With the growing popularity of mobile phones and lower resolution netbooks, a fixed width blog format is looking less and less appealing. I decided to work on a new look for this blog. The main feature I was looking for was a set of CSS rules that would allow the main content to scale with the viewer's browser window width. If the window is too narrow, the less important content on the sidebar should flow down below the main content.

I began with an existing theme for Blogger, Tekka, that pushes the right sidebar down beneath the main content when the window is narrow. I then made some CSS changes to tweak the look to fit my tastes.

First things first, the default fonts must go! I drew much of my inspiration from Nick Johnson's blog, specifically the way that serif fonts are used in some places for accent while sans-serif is used for most of the content. This is a technique that I experimented with a bit in a graphic design class in college.

For titles I added:

h1, h2 {
  ...
  font-family: Georgia, 'Times New Roman', Times, serif;
}

h3 {
  ...
  font-family: Trebuchet MS, Verdana, Sans-serif;
}

To change the font used for the main text in the page, I set a template variable as follows:

<Variable name="bodyFont" description="Text Font"
  type="font" 
  default="normal normal 100% 'Lucida Grande', 
    Verdana, Helvetica, sans-serif" 
  value="normal normal 100% 'Lucida Grande', 
    Verdana, Helvetica, sans-serif">

Next I set about changing the style of the title link. You see, when someone is viewing a single post, the blog title becomes a link to the main blog page. So, the blog's title is styled like a link and I found the default link styles a bit jarring. This might seem like a minor change but so often it's the little things that matter. I set this style using

h1 a:visited {
  ...
  color: #505050;
}

Now that the text styling is done, the layout could use a bit of adjustment. I changed the margins on the main content to the following:

#content-wrapper { 
  margin-top: 20px;
  margin-$endSide: 30px;
  margin-bottom: 30;
  margin-$startSide: 35px;
 }

I removed the padding from the h1 title style and the date header. I also removed the style rule entirely for the description.

We're nearing the end! The sidebar wasn't quite to my liking so I changed the border style. Lastly, in order to get the sidebar to flow down beneath the main content I set a minimum width. Here is the final style for the sidebar:

#sidebar {
  text-transform:none;
  background-color: $sidebarBgColor;
  color: $sidebarTextColor;
  padding-$startSide: 20px;
  width: 30%;
  min-width: 215px;
  float: $endSide;
  font: $bodyFont;
  border-$startSide:1px solid $mainTextColor;
  word-wrap: break-word;
  overflow: hidden;
}

I debated about posting the whole template here, but I'm not sure that it would be very readable. If you would like the whole thing, leave a comment and I can email it to you.

DOM Manipulation in JavaScript, a Utility

2010-01-13T23:45:00.000-08:00

In my latest addition to the q12 JavaScript library, I have added a simple function to construct a nested document structure. I grew tired of writing repetitive and difficult to follow code like this

var div = document.createElement('div');
div['id'] = 'outer-div';
var link = document.createElement('a');
link.href = 'http://blog.jeffscudder.com';
link.appendChild(document.createTextNode('my blog'));
div.appendChild(link);

Using the new tree function this would become:

var div = tree([
    'div', {
        id: 'outer-div'}, [
      'a', {
          href: 'http://blog.jeffscudder.com'}, [
        'my blog']]]);

In the process of writing this utility function, I came across another small oddity in editing HTML using JavaScript related to the style attribute. Most HTML attributes are simple text properties, however when editing the CSS style of a node, you cannot set the full content of the style attribute.

// You cannot do this:
div.style = "color:red; font-weight:bold";

Instead, you set each sub item in the style attribute:

// This works:
div.style.color = 'red';
div.style['font-weight'] = 'bold';

The tree function that I've written handles this nested style structure as well. Here's an example:

['div', {
    'id': 'foo', 
    'style': {'color': 'red', 'font-weight': 'bold'}}, 
  'This works too!']

Now that you have an idea of how to use this utility, here's the code. Minus the comments it's only about twenty-one lines.

/**
 * Creates a DOM tree from a simple list.
 * The structure of the tree passed in is as follows:
 * ['elementTag', 
 *      {attribute1: value,
 *       attribute2: value,
 *       style: {property1: value,
 *               property2: value}},
 *    'child text node',
 *    ['elementTag',
 *         {property: value},
 *       'grandchild text node'],
 *    'third node']
 * The above will result in a DOM node which has three child nodes, the
 * first and third will be text nodes because the values were strings.
 * The second child node will be a DOM node as well.
 *
 * @param {Array} t The tree's structure as a collection of strings, lists,
 *     and simple objects. The structure is as follows
 *     ['elementTag', {attributes}, child, child, child, ...]
 * @return {Element} Returns a new DOM element.
 */
function tree(t) {
  // Create the node using the tag which is first in the list.
  var domNode = document.createElement(t[0]);
  // Add all HTML attributes to the node.
  for (var key in t[1]) {
    // The style attributes get special treatment.
    if (key == 'style') {
      for (var styleAttribute in t[1].style) {
        domNode.style[styleAttribute] = t[1].style[styleAttribute];
      }
    } else {
      domNode[key] = t[1][key];
    }
  }
  // Iterate over all child nodes, converting them to either text or HTML
  // nodes.
  for (var index = 2, child; child = t[index]; index++) {
    if (typeof(child) == 'string') {
      domNode.appendChild(document.createTextNode(child));
    } else {
      // Buid recursively.
      domNode.appendChild(tree(child));
    }
  }
  return domNode; 
}

What do you think, is there anything you would add?

On a realted note, if you're interested in a more powerful templating system, you might want to try Closure Templates which were recently open sourced.

The joys of onKeyDown

2009-10-22T16:00:00.000-07:00

I recently found myself in need of a way to detect when a user presses enter when typing in a text input box and happened upon one of the quirkiest of browser features, key press detection in JavaScript. Searching the Internet provided a few ideas but nothing that quite fit what I was looking for, so I thought maybe I should get the word out about what I've learned.

Lets assume that we have a form with an input box and we want to perform some special action when the user presses the enter key while focus is on the text input box. We begin by adding an onKeyDown event to the input box (you might also consider onKeyUp, but onKeyPress seems like it might be somewhat quirkier).

<form>
  <input type="text" id="my-input">
</form>
<div id="output"></div>
<script>
  document.getElementById('my-input').onkeydown = function(e) {};
<script>

Now the first hurdle is that in IE, Safari, and Chrome you can access the ASCII character code for the key which was pressed in window.event.keyCode but in FireFox you'll need to get the event object and look at the which member.

<script>
 document.getElementById('my-input').onkeydown = function(e) {
   var keyCode = 0;
   if (window && window.event && window.event.keyCode) {
     keyCode = window.event.keyCode;
   } else if (e && e.which) {
     keyCode = e.which;
   } else {
     alert('fail');
   }
   document.getElementById('output').innerHTML = 'You pressed ' + keyCode;
 };
<script>

Now there is one gotcha with what we've written so far. Each key that we press when focus is on the desired input causes our code to be run, but the browser also performs the default behavior for that key. If our input is a simple text box, the characters pressed will show up in the text box. If the input is part of a form with a submit button, pressing enter will cause the form to be submitted. If the form is submitted then the browser is sent to a different page which in this case is not what we want.

There are a few ways to prevent the key presses from also triggering the default behavior and do only our behavior. One of the simplest ways is to return false from the onKeyDown function. If we change our handler to the below, characters will not show up in a text input box because our handler consumes them.

 document.getElementById('my-input').onkeydown = function(e) {
   var keyCode = 0;
   if (window && window.event && window.event.keyCode) {
     keyCode = window.event.keyCode;
   } else if (e && e.which) {
     keyCode = e.which;
   } else {
     alert('fail');
   }
   document.getElementById('output').innerHTML = 'You pressed ' + keyCode;
   return false;
 };

With the above, the last key press is displayed in the output, but in most cases we probably do want the user to see the chracters they've typed showing up in the input box. We just want to prevent the form submit when the user presses the enter key. To accomplish this behavior, we can return false when we don't want the key press to propoage and return true when the default behavior should also be performed.

 document.getElementById('my-input').onkeydown = function(e) {
   var keyCode = 0;
   if (window && window.event && window.event.keyCode) {
     keyCode = window.event.keyCode;
   } else if (e && e.which) {
     keyCode = e.which;
   } else {
     alert('fail');
   }
   document.getElementById('output').innerHTML = 'You pressed ' + keyCode;
   if (keyCode == 13) { // 13 is the key code for the enter key.
     return false;
   } else {
     return true;
   }
 };

There you have it, a way to detect when the enter key is pressed in our input box while also preventing the form from being submitted.

Journaling

2009-09-28T22:16:00.000-07:00

This evening I found my long lost journal. In dusting it off and cracking it open I learned that my last entry had been over a year ago. With the exception of this last year long hiatus, I've regularly kept a journal since sometime in 1999 or 2000. I've found writing my thoughts helps me crystallize them and I tend to deal with thoughts and emotions internally, mulling them for hours or days. This is one of the reasons I think I've stuck with blogging.

Keeping a private journal is a completely different feeling than keeping a blog. When I write here I'm intensely (sometimes even paralyzingly) conscious of my audience. Not that it's a large one. Here I tend to focus on software related discoveries and creations. It is one creative outlet, but one decidedly different from when I journal.

It was refreshing to scratch blank pages with pen, writing for an audience which understands me better than most.

Okay now how many of you, when you saw the title, thought that I was going to talk about a file system or database? :-) How about you, do you keep a private journal?

A Matrix Sim in JavaScript

2009-08-26T23:49:00.000-07:00

Do you ever find yourself working on a large project with a long lead-in time before you have visible results to show? I had been frustrated by this feeling recently. I had been focusing on a personal project which will likely be a long time in the making, so I decided to pick up a short, simple, and quick project to keep things lively and fresh. So our story begins.

During high school, I was wowed by the movie The Matrix. The special effects were mind blowing (for their day) and the story line was something I could really get behind (not so with the sequels, but I digress). I imagine this is how my elders felt when Star Wars was first released.

One of the most memorable visuals in the movie is the code of the matrix zipping by vertically on the screen in a retro green on black. Cypher, makes a statement, which seems to be a favorite among programmers, that he no longer sees the code itself, but what it represents. He has become fluent to the point of transcendence - a geek nirvana experience.

At this point in my life I had written a few moderately complex programs, mostly using Turbo C, and I thought: "Why, I could make my computer look like the matrix." It was one of the more involved programs I had written at the time and I was quite pleased with the result. I brought it in to the computer lab at school, loaded it onto all of the machines, and had the whole lab running it at once. I'm pretty sure that Ben, Yed, and Roman G. remember it. Sadly I doubt the code would run on the DOS emulator that ships with Windows XP and higher. I recall vaguely that Roman ported it to Win32 or something in our high school computer science class. Now that I think about it, I guess you could say that this was my first open source experience.

In thinking of something quick and easy to create with some immediate visual payoff, I decided to recreate my little DOS matrix sim, but this time in the browser. Behold: The matrix in JavaScript.

It turns out that the CSS rules needed to keep columns at a fixed width and height was actually quite complex and took longer than expected to get right. The vertical line height was still elusive in Chrome and Safari, but worked in Firefox and Opera. I don't think that this works yet in Internet Explorer. Though if past traffic is any indication, none of you would have noticed had I not said something :-)

Many thanks to Scudmissile for his mighty CSS kung fu. Oh, and that whirring sound that you hear may be your CPU fan trying to take flight. Apparently rendering a vertical text flow like this using DOM manipulation, CSS, and Math.random may be a bit more processor intensive than my obsolete C code.

A Test Client for App Engine

2009-08-01T00:38:00.000-07:00

I created a simple utility library in Python to help anyone debug their App Engine application. Many of the App Engine apps that I've seen use HTTP, HTML form posts, and the Users API and the easiest way to test these features is to fire up the web browser and click through the web pages generated by the app. However this can be a bit slow and repetative and it is difficult to determine exactly what is being sent over the wire (though this is greatly helped by using wireshark, fiddler, tcpdump, or antoher network packet sniffing tool).

Enter my little App Engine HTTP module. It provides a simple interface for making arbitrary HTTP requests and will print the full request and response to the terminal (though you can turn the noisy printing off if you want). Download, copy the http.py file to you working directory and try it out in your Python interpreter.

For our first demonstration, let's try to visit the Google search page.

import http
client = http.Client()
resp = client.request('GET', 'http://www.google.com')

You should see your request and the server's response (with the HTML for the Google Search page) in your terminal window. This should work with just about any website out there.

Other HTTP debugging tools can show you the request and response like this, but I find that this kind of simple Python client can be useful in writing end-to-end or integration tests which contact your App Engine app remotely.

Along those lines, one of the things which standard HTTP debugging tools do not provide, is a way to sign in to an App Engine app with a Google Account so that the App Engine Users API can identify the current user. I wrote an extremely simple app which illustrates the Users API, try it out here:

http://jscudtest.appspot.com/user

After signing in, the page should simply say, "Hello yourusername (yourusername@yourdomain.com)" You'll notice that during the sign in process, you signed in on www.google.com/accounts and were asked to approve access to the app. This kind of interaction works great in a browser, but can be tricky when you are using a command line, browserless, client.

It is possible however, to sign in to an App Engine app without using a browser. You can use the same technique used in appcfg, use ClientLogin and use the authorization token to obtain an app specific cookie which indicates the current user. This simple HTTP library can do this for you and all subsequent requests will use this cookie to tell the App Engine app who the current user is. Try it out by making the request to the simple user app that you visited earlier:

import http
client = http.Client()
client.appengine_login('jscudtest')
resp = client.request('GET',
                      'http://jscudtest.appspot.com/user')
print resp.body

You should see the following text displayed in the terminal:

Hello, yourusername (yourusername@yourdomain.com)

You can use the appengine_login method with your own app, just change the argument to the App ID of the app you want to access.

Along with simplifying access to apps which use Google Accounts, I wanted this library to simplify the process of using another feature used by many web apps: HTML form posts. Now I'm certain you've used HTML forms before, here's a simple example:

http://shoutout.appspot.com/

The above app uses both the Users API and a simple form. As an alternative to visiting this page in the web browser, you can post your shout-out using the following:

import http
client = http.Client()
client.appengine_login('shoutout')
client.request('POST', 'http://shoutout.appspot.com/',
    form_data={'who': raw_input('From: '),
               'message': raw_input('Message: ')})

If you've even wondered what gets sent across the wire to post on a form like this, look back in your terminal to see the request from your computer and the response from the server (this is of course just the HTTP layer, wireshark will show you traffic on the IP and Ethernet layer as well).

That's really all there is to it. I designed this as just a simple script to use on the command line and I wrote it in less time than it's taken me to write this blog post about it (I borrowed atom.http_core from the gdata-python-client as a foundation). With some tweaks to remove the interactive (getpass and raw_input) calls and replace them with parameters, I could see this module as a utility layer in a larger, more complex, App Engine client application. If you're creating on I'd love to hear about it ;-)

For more information on how the appengine_login method works behind the scenes, see this presentation I gave a few months ago:

Many thanks to Trevor Johns and Nick Johnson for helping me to understand how this ClientLogin-to-cookie exchange works.

I'm sure that App Engine's Java runtime users would appreciate a port of this simple library to Java, if you feel so inclined.

New version of my Dirt Simple CMS

2009-07-14T23:01:00.000-07:00

I have just uploaded "version 2" of the dirt simple content management system which I developed almost a year ago. For those who don't recall, scud-cms is an extremely thin layer on top of App Engine with a plain text box based editor for creating web pages. The only new feature in this release is the ability to page through all of the content in your app by visiting the /content_lister page. I implemented the pagination system using "key only" queries and order-by-key which are fairly recent features in App Engine. For more potential designs to page through datastore entities, see this article on pagination.

I was inpired to work on this in part by a comment from Jason Worley (swirleydude on twitter) who has been using it and appears to like it quite a bit. At some point I plan to do a version 3 release which will include file uploads (great for images) just as Jason has done in his own modifications. Having someone use your software, enjoy it, tweak it, and build on it is rewarding in a way which is quite unique.

Updating my OLPC XO laptop

2009-07-07T23:01:00.000-07:00

For a few months my XO laptop was my primary personal machine. I've written before about some of my favorite features, and after a year and a half with it, my favorites are still:

A screen that is readable in full sunlight or glare
Linux
Long battery life
Runs absolutely silently, no fans or spinning hard drive

However, there were a few drawbacks. It is a bit short on ram and processing power but most of the time I'm using simple programming tools, so I don't need much. Web browsing on some sites was a bit slow though. The biggest pain point in my book was the lack of copy and paste capability. I often found myself needing to retype a lengthy command in the terminal. On other systems I would have just copied and pasted from the web browser. For a while, I worked around this by using screen, which has a built in copy-paste buffer.

It turns out, in a recent release, the OLPC team has assuaged my number one annoyance. It is now possible to copy text from any of the activities (programs) and paste into another (like the terminal). In order to use this new goodness, I needed to update my XO operating system from the current version (656) to a newer build (802).

The process of updating turned out to be quite simple. If you are undertaking these same steps, please note, this does wipe out some parts of the operating system. New programs which you've installed using yum or rpm's might be erased depending on where they are installed. It looks like everything in the /home/olpc directory is untouched. For complete instructions, see the laptop.org wiki page for olpc-update.

To update, open the terminal and become root by executing

su

After that, make sure that your laptop is plugged in to a source of electricity and connected to the internet as this next step involved downloading the new operating system and overwriting your existing OS. Probably not something you want to lose power during.

To download and install the new OS run

/usr/sbin/olpc-update 802

Once you run this your laptop will spend the next several minutes to hours downloading and installing. A few exciting status messages will appear on your screen. Things like "Deleting old pristine version" - yikes!

I've found 802 to be a significant improvement over 656. The copy paste functionality is great and the UI looks and feels cleaner. Selecting applications and switching between them is easier than it used to be. With copy and paste now firmly in place I plan to use my little green machine quite a bit more.

Partial Function Invocation

2009-06-25T14:15:00.001-07:00

My wife tells me that I often jump into an explanation by starting at the beginning of my train of thought without giving any indication of where I'm going. It would be better if I began with the point I'm trying to make, then explain how I reched my conclusion, How am I doing so far? Oh wait, right... Here is my conclusion:

Allowing a function to be partially invoked, to allow some of the arguments to be specified at different times, can allow for code which is more flexible than by just using objects or pure functions.

I've been thinking about this lately as I refactored the gdata-python-client which is a library which can be used with AtomPub services. I'll spare you all the gory details, and offer a simple example of how partial function invocation might come in handy.

When making a request to a remote server, you might need the following information, just for example: username, password. URL, message body, and content type. So we start out by writing a stateless function to take this information and open a connnecion to the server, format our inputs, transmit our request, and parse the response. We'll call it post, and using it looks like this:

serverResponse = post(url, data, contentType, username, 
                      password)

This is all well and good, but suppose the final request, as shown above, is preceeded by a whole series of function calls. Each function would need to dutifully pass along parts of the request. Say for example that the user types in their username and password long before the request is made, so these get passed as parameters to lots of functions which only receive them so they can pass them on. In addition, the username and password are almost always the same from request to request, so the same values are being passed to the post function over and over. In cases like this, we will often use an object to hold common values.

class Requestor {
  username
  password

  method post(url, data, conteentType) {...}
}

Now our request will look like:

client = new Requestor(username, password)
serverResponse = client.post(url, data, contentType)

What we've effectively done here is specified some of the information in advance and left other pieces of information to be specified at the last minute. I would argue that this make the code better (cleaner, less chance of human error in listing lots of parameters, perhaps less data on the call stack, etc.).

Now the question becomes: Did we extract the right pieces of information from the function call into the object? Suppose the code you are writing needs to use a different password for each service you are making a request to, but the content type of the data is always the same. Then it would have made more sense to design our class like this:

class Requestor {
  username
  contentType

  method post(url, data, password) {...}
}

Since we've established that not everyone who is using our code has the same usage patterns, lets design for utimate flexibility. Every parameter can be specified either in the object, or in the function call. Also, if the object has a parameter already, we could override it by passing in that parameter when we call the method. This is not too difficult in in Python, so here is a non-pseudocode example:

class Requestor(object):
  
  def __init__(self, url=None, data=None, 
               content_type=None, username=None, 
               password=None):
    self.url = url
    self.data = data
    self.content_type =  content_type
    self.username = username
    self.password = password
  
  def post(self, url=None, data=None, 
           content_type=None, username=None, 
           password=None):
    url = url or self.url
    data = data or self.data
    content_type = content_type or self.content_type
    username = username or self.username
    password = password or self.password
    # Now we have our inputs, code to make 
    # the request starts here
    ...

If you think this seems a bit excessive, I would agree. I didn't go nearly this far when designing the library that started me thinking about this. There was one request parameter in particular though that does use this pattern. (Five points to the first person to post it in the comments. ;-)

To use the above class, you would do:

requestor = Requestor(username='...')
requestor.password = '...'
...
server_response = requestor.post(url, data, content_type)

It will also handle our alternate usage where we want to give the password to the post method and set the content type at the object level:

requestor = Requestor(username='...', content_type='...')
...
server_response = requestor.post(url, data, password='...')

We can even override parameters which are set in the object:

requestor = Requestor(password='...', content_type='...')
requestor.username = '...'
...
# Override the content_type, just on this request.
server_response = requestor.post(url, data, content_type='...')

With the above example we end up with a lot of code just to let us specify each parameter in either the object or as a function argument. In fact, this can introduce so cases where the user forgets to specify in either, which is possible because all function arguments are now optional. Wouldn't it be better if we could instead specify some of the function parameters, pass the half-specified function call around, and fill in the ramaining values when we finally invoke. For this illustration, I'm using the following syntax to show a partial invocation, < > around arguments instead of ( ).

function post(url, data, contentType, username, password) {...}

started = post<username, password>
...
serverRespense = started(url, data, contentType)

Recall our case from earler, what if the contentType is constant but the password is instead more variable:

started = post<username, contentType>
...
serverRespense = started(url, data, password)

It turns out I'm not the first person to think of this pattern, not by a long shot. Functional programming often makes use of this pattern, referred to as function currying. I found the following example for Scheme which also shows how easy this is in Haskell. The prototype library for JavaScript includes a bind function which can accomplish the same thing. Here's a paper on the topic in C++: (pdf, Google cache HTML). I also found PEP 309 which was a proposal for this in Python. Perhaps I should have called my Python example above: Function Currying using Classes. If you can think of other examples, I'd love to see them.

Recently completed: our half-US tour

2009-05-17T13:11:00.000-07:00

With stops in

Auburn CA
Reno NV
Winnemucca NV
Wells NV
Metropolis NV
Bonneville Salt Flats UT
Salt Lake City UT
Green River WY
Cheyenne WY
Denver CO
Littleton CO
Centennial CO
Lincoln NE
Omaha NE
West Des Moines IA
Indianola IA
Sigourney IA
Fairfield IA
Hannibal MO
Fenton MO
Crestwood MO
Sikeston MO
Memphis TN
Little Rock AR
Texarkana AR
Texarkana TX
Plano TX
Dallas TX
Garland TX
Wichita Falls TX
Amarillo TX
Albuquerque NM
Williams AZ
Bakersfield CA
Plesanton CA
Milpitas CA

(Edited) Here's a map of our approximate route:

View Larger Map

Anticipating "it's all crazy..."

2009-05-17T13:06:00.000-07:00

One of my favorite bands is releasing a new album tomorrow and I though I'd take a short moment to gush about it. I've been a long time admirer of mewithoutYou's work. Their abstract poetry filled with vivid imagery combines with highly energetic rich sounds and hits a sweet-spot. Certain lines tend to resonate with me. I find "O Porcupine" in particular to be moving.

I like to think of myself as having broad musical tastes, but if I do tend to be critical of a song it is very often overly simplistic lyrics which I fault. I don't know that I've ever sat down and thought through why that is, perhaps another time.

From listening to a few preview release tracks from this album, I don't think mewithoutYou runs any risk of that sort of problem. In fact, while listening to "the Fox, the Crow and the Cookie" I found myself pulling out the dictionary to look up the words canzonette, corvidae, and escadrille! Some of those rhymes are absolutely majestic. I think this album may satsfy even Xirzec's bombastically erudite lexical tastes. Thanks again to Andy for introducing me to their music.

A Two Pun Day

2009-05-05T23:16:00.000-07:00

If I were a rock, I wouldn't want to be marble because I wouldn't want people to take me for granite.

I told one of my good friends that I was allergic to milk and he said, "No whey!"

I would estimate that I make at least two puns per week. Something someone says will just strike me at an odd angle and the pun percolates out effortlessly. The other day I thought of the above two. I'm not sure if the first is original, but we were in an elevator debating whether the stone walls were made of marble or granite and I couldn't resist. Later that day, someone mentioned cottage cheese and I thought of the second. It's a certified groaner, five out of six friends agree!

Our New Pi Day Laptop

2009-03-17T23:16:00.000-07:00

To commemorate this year's pi day, we've christened our newly purchased laptop PiPuter. It's an Acer Aspire. We were looking for a super cheap full sized laptop with decent spects and found a good deal at the MicroCenter. Vanessa says that our computer has graduated magniu cum laude from its factory and it is currently watching us - watching, watching, always watching.

Septoplasty

2009-03-05T07:21:00.001-08:00

I never dreamed that I too would be undergoing septoplasty just a few short months after Joe Greogorio had his operation. It turns out I had a pretty severely deviated septum which likely contributed to the annual sinus infections which I have been experiencing. My allergist recommended I have this operation to straighten the inside of my nose, as my left nasal passage was almost completely blocked near the bridge of my nose. In looking for a possible sinus infection I had a CT scan of my sinuses which revealed just how severe the deviation was. By the way, looking at a slice by slice cross section of your own head is fascinating.

This past Wednesday I had the surgery and I will have the stitches and splints removed next Tuesday. It's been a bit different than I expected. I anticipated some pain but, surprisingly, the part that hurts most is my upper front teeth. I also didn't expect quite so much bleeding. In any case, I'm not feeling too bad and I am looking forward to the long term benefits. Also, this has been my first experience BWOV (blogging while on vicodin).

Two Guys Arguing - Five Questions

2009-03-01T21:00:00.001-08:00

I noticed that my friend Ben is participating in a new blog named Two Guys Arguing (in addition to blogs one two and three :-) and I thought I'd piggy back on a recent ice-breaker post.

What are you currently hacking on?
What are you currently getting better at?
What do you do when your computer is asleep?
Describe that ‘big fish’ project that’s been stewing in your brain.
What are you gonna post about this coming week?

On to the answers:

As a small part of my day job I'm currently working on a rewrite of significant portions of the gdata-python-client to support version two of the Google Data API protocol (check out the v2 branch).
I've been trying to focus on writing speedier unit tests. Unit testing is great, but sometimes it is necessary to write end to end tests which can take a rather long time to run. Slow tests are run less often, so I've been thinking of some ways to cache some of the more expensive pieces of these end to end tests while still preserving their utility.
Playing with Claire is easily one of my favorite non-computer related activities. I have a wonderful wife who keeps me company and there's nothing like relaxing with the family. Aside from the yard work, remodeling, and other house related items, I do very much enjoy playing guitar now and again. I even have a somewhat regular weekly gig.
I have a few side projects I like to hack on here and there in my spare time. One of them I've been thinking more about recently is a computer language I've decided to call "Headspace". I wanted to try an experiment and see what the effects would be of applying the rule of seven to programming.
I've been planning to write a bit about the surgery I've recently undergone so stay tuned ;-)

Two Guys Arguing seems like it's off to a great start and I look forward to reading along.

Google Tweets

2009-02-25T21:20:00.001-08:00

Earlier today, Google posted the following on Twitter

I'm 01100110 01100101 01100101 01101100 01101001 01101110 01100111 00100000 01101100 01110101 01100011 01101011 01111001 00001010

This looks suspiciously like ASCII, so I set out to render it in a more human readable form:

Bin       Hex ASCII
0110 0110 66  f
0110 0101 65  e
0110 0101 65  e
0110 1100 6C  l
0110 1001 69  i
0110 1110 6E  n
0110 0111 67  g
0010 0000 20    (space)
0110 1100 6C  l
0111 0101 75  u
0110 0011 63  c
0110 1011 6B  k
0111 1001 79  y
0000 1010 0A  \n

I doubt I'm the first to post this, but there you have it :-)

Brief Haitus

2009-02-01T21:29:00.000-08:00

I'm taking a short break from posting here to study for the GRE. I'm planning to apply to grad school in the not too distant future, and figured I should study. Apologies for the pusillanimously prosaic post.