My Personal Kanban Experiment (Part 1)

I'm starting a new job, and with a new job comes an overwhelming number of personal, on-boarding and regular work-related tasks that need to be completed. I need a way to manage these numerous, evolving priorities.

This is a good time to start applying principles of Kanban and Getting Things Done. I want to make a good impression, and being able to master all the new responsibilities I have taken on in addition to fulfilling other obligations would be a good start. I am also feeling somewhat overwhelmed lately with all the things I need to do, and I think having a system for managing it would enhance my sense of control and overall mood.

To do so, I started by creating a free account at kanbantool.com to manage my work-related tasks. The free account lets you create one board. I named it after my client. We'll refer to it as "Client".

I opted for a simple 3-column Kanban board (To-Do, In Progress, Done).

It became clear that some of the things I need to do can be grouped into related projects (a la GTD). For example, I am assembling a standup desk and that could be a separate project. Since I started that on the first board already, I decided to leave it there.

In any project, there are task-based and external dependencies which sometimes make it difficult to move forward in a linear sequence. Kanban to the rescue! I can only focus on one or two things at a time anyways (WIP limit), so having this system lets me focus on the things I can accomplish right now, without losing sight of all the other things that need to get done.

I upgraded to the account which allows me to create an unlimited number of boards for all these various projects.

I then created additional boards for various projects -- some work, some personal, some hybrid:

• Job Change Paperwork
• Development POC: Tasks related to creation of a new project based on discussions we had recently
• Garage remodeling
• Work backup kit: I forgot my earbuds today and have resolved to never be without certain items at the office, in case I forget to bring something again. Here's what I need to do to finish that project.

During this experiment, I will blog about a typical day and how I used Kanban to push items through from To-Do to Done, while dealing with blocks and thinking about priorities. In the end, I want to determine whether it's worthwhile enter all this information into a tool like this. I also want to be able to look back at what I accomplished and think about whether this system helped me manage it all.

So far, I'm finding that there is very low friction to using kanbantool, so it seems like it's worthwhile to use. The only difficulty I can foresee is if I am without my computer.

I just need an HTTP server!

If you ever need a very basic HTTP server to serve static files in a pinch, Python comes to the rescue. Just use:

$ python -m SimpleHTTPServer

Credit: http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python

http_sequence

I created a gem for replaying sequences of HTTP requests from HAR (HTTP Archive) files. It could be useful for testing or automating repetitive web interactions (ie. bots or scraping).

Some of the things I'd like to do to improve http_sequence:

• Add PUT, DELETE and other methods (currently supports POST, GET)
• Add hooks for modifying requests at runtime
• Add hooks for extracting parameters from responses
• Add logging

Suggestions are welcome.

Why I love bots and scraping

My interest in web hacking has been revived recently with a project that involves content distribution to various sites that don't offer API's.

Besides pushing content out, one can automate content pull using a "scraping" approach. This is an excellent way to automatically acquire all kinds of useful data for various purposes, ranging from checking the daily special at your favorite restaurant, to identifying patterns and extracting information from very large data sets.

There are some very compelling reasons why one should not use API's to interact with 3rd-party websites:

• API's change: There is nothing more annoying than sites that make breaking API changes, except when those changes are not announced or documented anywhere.
• API's are sometimes not very well-documented.
• API's are limited. Most provide only a subset of the functionality of the actual website.
• There are a couple of somewhat complicated (and flawed) delegated authentication and federated identity schemes (OpenID, OAuth) to get around trust issues. If your user trusts your app enough to allow access to their data, couldn't the app be trusted with user credentials, too? This is a thornier issue, but one worthy of exploring on a case-by-case basis. For example, our project involves automating account creation. For sites like Facebook, we might look at whether we want to leverage the user's existing social network, or we might create a "fake" account in order to post. I would argue that the fake account has much less value to the user than the real one, so there is less concern about compromising credentials and therefore a less compelling reason to jump through the Facebook Connect hoops.
• Websites don't change often enough to be concerned about breaking your scripts. It's surprising, but true (see this for an anecdotal testimony).
• It's fun to write bots, spiders and scrapers.
• It sharpens the saw. If you didn't know that much about the Internet and HTTP before because you were relying on your web framework to do everything for you, you will learn a lot by reading through Fiddler logs and trying to write a script that acts like a web browser.

I can't remember when I wrote my first HTTP client but I know I must have done it when I was into Perl many years ago. Mechanize is a very popular framework that we used at a previous company to implement an automated test suite, and it would be equally useful for scraping. Happily, it has been ported to Ruby. There are all sorts of options and techniques one can use today, which I will write about in a subsequent post.

For a great talk on this subject, checkout Asheesh Laroia's talk at PYCON US.

Jiro Dreams of Sushi

Saw Jiro Dreams of Sushi. Great movie about the purpose of life, the fulfillment obtained from perfecting your craft and, of course, food. I found myself comparing my own motivation and talents (software) to his. Hopefully I will still be motivated when I'm 70+ years old to continue working on my craft.

A Better JSONP

JSONP is a popular workaround for browser cross-origin restrictions. JQuery's popular $.ajax implementation supports JSONP, but it has some serious drawbacks.

REST API's rely on HTTP status codes to communicate errors. However, $.ajax with the jsonp data type uses script tag injection, so if the API call successfully returns with an error, such as 401 (Unauthorized), the 'error' callback never gets called.

Here is a JQuery plugin that promises to solve this problem:
https://github.com/jaubourg/jquery-jsonp

As I'm currently wrestling with JSONP vs. other cross-domain solutions for a client project, I will try this out and post the results soon.