Monthly Archives: November 2013

A few good reads

Quantified Self

I recently signed up with Critter.Co to track some mental/behavioral habit changes.  Liking it so far!



dataset is a new tool for lazy programmers who work with data, in Python.

I can’t help but share this awesome parody, “Up All Night to Get Data”!


Machine learning

This was a neat story.  I hadn’t realized any traffic light infrastructure in the world was capable of the central intercommunication required for this, but it’s an obvious thing to do when the infrastructure can handle it!  Learning to optimize traffic patterns.



You have to scroll down through some detailed explanations to get to rankings of visualization venues.

A template for creating cycle plots in Excel.  I love cycle plots!


Personal Finance

I recently heard about OmniVest.  Sounds intriguing.  Has anyone used it?

Google App Engine (with Django and Google Cloud SQL)

Why cloud computing was a no-brainer for me
I’m an analytics person. I wasn’t even a pure Computer Science major; I did a joint (not double) major with Mathematics. Why am I telling you this?  Because I dislike working with hardware.  In fact, I dislike working with any code or tool that knows anything about the hardware.  I like to stick as close to pure, elegant Mathland as possible.  That’s why I am ecstatic to be building in the time of buzzwords like “cloud computing”.  Someone else takes care of the hardware, infrastructure, and scaling for me!  It’s brilliant!  Obviously there are some limitations that may be relevant to specific domains, and if you have very specific infrastructure or scaling needs it’s probably not as good as rolling your own hosting system.  But it’s great for me to bootstrap on a shoestring budget!

Why Google App Engine
I checked out both Amazon EC2 and Google App Engine, and from the point of view of my service’s requirements, they had almost identical offerings.  My cofounder had some previous positive experience with a project using Google App Engine.  It’s free, and it supports goodies I intended to use, such as Python, Django, SQL, message/task queues, email, and crons.  And it seemed likely to make it easier to allow Google sign-in, or to integrate with other Google services if necessary.  Everyone I talked to seemed to think there was no particular reason for us to choose Amazon over Google, and I saw no particular reason in my researches, so we went with Google.

Getting started is easy
It’s surprisingly easy to get started, despite the complexity of customization available.  You download the Launcher to run your local sandbox, and just point it at the code.  The sample settings files get you off the ground in no time, and you can start building immediately.

That said, it won’t be clear how to tweak settings like the app.yaml file if you don’t read the documentation, and more advanced settings like Google Cloud SQL require a lot more reading than you’d think.  In that case, you have to run SQLite in your local sandbox after adding a line to a local settings file, and the way you access your databases in the sandbox vs your development, staging, or production servers is completely different.  As you get to more advanced or newer features like SQL, you’ll find yourself getting more frustrated with the developer documentation and relying on the copious StackOverflow posts generated by previous frustrated users.

In general, getting started is easy, but adding customizations and additional features takes some research.

Generic deployment is easy
Deploying is super-easy.  You tell it once where to upload your code, and you press the “Deploy” button any time you want to push data to the server.

If you want to set up multiple servers, such as for dev, staging, and production, then you have to do things a bit quirkily.  Some people try to do this by changing the application version, but then you end up with staging and production sharing the same databases.  The popular solution here is to register multiple “applications” with Google, one for each release phase.  Here’s a sample how-to.

Deploying database changes is quirky
Quirks here come in when you’ve added customizations or advanced features.  We’re using Django, so after we hit deploy, we aren’t necessarily finished with our remote update.  We have to run a database synchronization on the command line to force database updates.  In order to do the remote database synchronization, you can’t just hit “Deploy”.  You have to run it from the command line too.  The first time I had to do this I ran into a blocker: something it required called “gflags” was not installed on my computer.  I looked it up and found multiple codebases by that name.  Let me save you some trouble and say you want this one .  And it fails to say so, but you need to install it with sudo.  INSTALL THIS BEFORE YOU ARE UNDER TIME PRESSURE TO COMPLETE THE REMOTE UPDATE.

This is one of many ways you can get a sizable environment mismatch between your sandbox and your servers.  Not ideal.

Git integration is halfway there
When we first started, Google did not support any kind of integration with git.  Now they have a Preview release of a feature called push-to-deploy. This is a promising start!  I’m a big fan of having my issue tracker integrated with git integrated with my deployment process, so this is a good first step.  Unfortunately, we already have our code hosted in a git repository that’s linked to an issue tracker, so I’m waiting for that next step before I switch to a Google repo.

Frequently updated
Sure, it has the odd issue here and there, but there are frequent updates to the GAE Launchers, and that first step toward Git integration is also quite new.  Always a bonus when your platform is pretty good and threatening to become better every moment!

Of course, not every update brings full stability.  And again, there are some quirks to update.  For example, to use SQLite locally, we have to update a settings file.  Unfortunately, every time we upgrade the Launcher, we have to re-update that file before our local databases function again.

Lots of goodies available
There are loads of goodies to customize and extend your app.  And if Google doesn’t supply them, they’re often available for free, open source, though the quality varies.  There’s a lot you can do with what’s available, though!

No mobile support yet for Launcher
I was a little sad, though unsurprised, to find that I couldn’t run the GAE Launcher on my Nexus 7.  Maybe someday!

GTD dreams

Right now I’m dreaming about a GTD-style system with an extra layer.  Instead of saying “Item 123 must be done by [date]”, I want to be able to say “One of the highest priority/most urgent items in bucket A must be completed by [date]; pick whichever works best”.  Each of the items in bucket A could still have their own due dates and priorities, but the entire bucket can be treated as a recurring todo item.

I also want to be able to schedule that N unspecified items from a named bucket should be completed weekly.

Example 1: I have a list of products and services to review on my blog.  Some of those are more urgent or more important than others, but many of them are in equivalence classes and I could do any one of three, say, on any given date.  But I must do one a week.

Example 2: I have loads of front end items, backend items, marketing items, HR items, etc to do for my startup.  I’d like to be able to prioritize the buckets and then just schedule myself to “Do at least N items from this bucket and M items from that bucket per week”.

Example 3: irregular house maintenance items should be done “once in a while”.  Ideally I could set some sort of “don’t repeat before” date when I complete each one, and then say “do one irregular maintenance chore per month if the bucket is not empty”.

Does this sort of todo list system exist?  Many GTD systems allow you to put things in buckets, but you can’t schedule buckets as recurring obligations without kludging things in difficult-to-maintain ways.  Right now I’ve completely given up on them and just use some combination of GQueues and Evernote to do it all manually.  Not quite cutting it.

A few good reads

I’ve been way behind on my RSS feeds.  Trying to catch up lately.  Here are some recent good reads.



Stephen Few verbosely explains the same issues I’ve been seeing in recent research on chart junk in visualizations.


UI Design:

This is a great site for reminding you of design principles.

As an aside, though, in its own design it misses the excellent idea of “table of contents” or “collapsible sections” for insanely long pages.  I’ve been to a lot of startup sites that subscribe to this absurdly long page design, and they almost always lose my interest before the action item appears.  It’s almost as bad as making me watch a video just to maaaaybe find out whether the product has three features I require.



This explains the concept and importance of price elasticity for pricing your products, how Apple can get away with jaw-dropping prices in some markets, but must rein in the prices just a bit in other markets.  Likewise manufacturers of facial tissue or twist ties must price largely according to competitors’ prices and the fairly minor differentiations in the products.


Quantified Self:

Whitney Erin Boesel led a breakout session with Jakob Eg Larsen at QS Global 2013 on “QS Researchers”, focused on the intersection of academia and Quantified Self.  She posted an excellent report on the discussion, including some possible action points.



A handy overview of how to arrange for a digital executor, potentially in addition to your estate executor.