So Microsoft killed the Kin, 6 weeks after its release. There is now an unfortunate trend starting at Microsoft, from a consumer perspective, of quitting out of their projects very early on: just last April, it was both the Courrier and the Slate. The Slate was the highlight of Ballmer's keynote to CES.

What's so surprising about the Kin is that it was axed so soon after its release. I mean fail fast is one thing but if your consumers start worrying that every time you put out a new product you might discontinue it, you've got all sorts of problems. This is especially true in the hot-red, media-hyped market that mobile computing currently is.

Recently, I visited a friend of mine that, Jeff, who was thinking about buying a computer. He's never owned one before but uses his partner's Laptop in the evenings to do e-mail, browse Facebook and watch a few YouTube videos. Of course more and more the two find themselves fighting over who gets to use the Laptop and an extra dedicated device would solve the problem. I was there with my iPad and after spending half an hour with it Jeff concluded that this did everything he needed and, since it was cheaper than a MacBook, bought one. He's been glued to it ever since.

This is of course a common tale, and a very encouraging one because an iPad is a lot easier to use and maintain than a Mac. That, combined with the lower price points, mean we have a whole new class of users that are now part of the game. To those users, the Laptop is still the benchmark because it comes down to what this new device can do, more than its specs and features. If Tablets are to truly succeed as a long-term consumer product, they'll have to empower users to similar degrees as traditional Operating Systems have. Simple questions like "can I save the video that was attached to this e'mail" will need to be answered, eventually. Likewise, users will need a way to input text to the device at an acceptable speed, and a way to watch content on it without holding the device up yourself.

Facebook is a poster-child for exponential-growth Silicon Valley startups, and it has been furiously innovating and morphing its product over the last 5 years. About a year ago, it reached that critical mass where your parents and grandparents start being aware of its existence and even mentioning it in every day conversations. Some might even be fortunate enough to now be Facebook friends with your Mother-in-law, as I am.

When web applications start to reach the 'rest of the world' is usually when things start getting seriously profitable. And there we are, with TechCrunch first reporting just last September that Facebook had become profitable, with a whopping 300 million users. I think it's safe to say that it has reached that critical mass.

To just view or download the code, click here.

I love SQLite, I really do. For any quick and dirty development, there is no other relational database like it: it's fast, lightweight, ultra portable, DB-API 2.0 compliant, and baked right into any distro of Python 2.5 or higher.

Using it is generally a very positive experience right up until the point where you need to make any changes to a table's schema. I distinctly remember that when learning Django it was particularly annoying to have to do a little SQLite dance every time I would need to edit or remove a model field.

It is to scratch that itch that I've created Squeak, which is a python module that can be used as a script from the command line or as a library that lets you:

• Drop a table column
• Rename a table column
• Change the definition of a table column (for example foreign key relationships or constraints)

Here is a test scenario where a column gets dropped from a table schema:

$ sqlite3 db
SQLite version 3.6.12
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> CREATE TABLE "my_table" (
   ...>     "id" integer NOT NULL PRIMARY KEY,
   ...>     "name" varchar (20) NOT NULL DEFAULT ""
   ...> )
   ...> ;
sqlite> .quit

$ ./squeak.py db my_table drop_column name
Column 'name' dropped

$ sqlite3 db .schema
CREATE TABLE "my_table" (
    "id" integer NOT NULL PRIMARY KEY
);

For more examples and further details, please visit the project's GitHub page at http://github.com/teebes/squeak

Disclaimer:

Squeak should be used for development purposes only. It is not meant to be used on production systems and is nowhere near fool proof.

Git-Goggles: A series of Git utilities to streamline working with remote branches and reviewing code.

The development team I am in at PBS has adopted a new methodology over the last few months that includes using Git, frequent (2 weeks) release cycles and rigorous code reviews. We spend a reasonable amount of time reviewing every iteration since every line of code gets critiqued by at least 2 members of the team before it gets pushed to production.

We also have a lot of branches. Since git makes branching so inexpensive and easy to manage, we use them to group tasks by functional area. We generally have in between 10 to 15 branches at once that regularly get merged into our master repo, which is the production code.

What is tricky in all this is keeping track of what code still needs to be reviewed versus what is good to go. We wanted a way to get both a nice visual, tabulated view of the state of our branches along with their status from a code review standpoint. It was to scratch that itch that our team lead, Nowell Strite, created git-goggles. The project was open sourced last week under the MIT license.

Here's a demonstration of git-goggles using a basic scenario that utilizes this type of workflow. The goal here is to push a new piece of code to a production repository, while making sure that it has been reviewed and that the branches are merged in.

First I create a new repo, a test file, and push it to github.