Monthly Archives: December 2010

Compiling my digital history

You can get a pretty interesting and comprehensive picture of my online life if you look at the things I write, share, like, tweet, and bookmark. The problem is that all of that information is distributed throughout the internet in various silos, like Facebook, Twitter, Last.fm, Tumblr, and Google. Thanks to things like RSS and Atom, it’s possible to get (most of) that information out of the silos into a machine-readable format. But I still have the issue of compiling it all.

I’ve been using the iOS app Momento for a few weeks now. It does a laudable job of collecting all my activity into one place. Several of the services are built in, like Facebook and Twitter, while a multitude of others are supported via the “web feeds” option. Momento imports these all, ties them to the date on which they occurred, and labels them. I can even add “diary entries” right into the app to provide more context.

The interesting thing about Momento is that it runs entirely on my iPod–none of the aggregated data is stored on Momento’s servers. I have a local copy of everything and that’s it. I can back that up to my computer via iTunes and do whatever I want with it.

Even still, however, Momento is a sort of silo. I can only access its data on my device. This solution isn’t perfect, but it’s a start. It gets me a step closer to having a personal data store where everything I do or post online is under my control.

Using Python and Apache 2 on Ubuntu

This is the first in a series of posts detailing my experiences and discoveries as a TA for Phil Windley’s CS 462 class, “Large-scale Distributed System Design.” Most of the posts will be how-tos, with perhaps the occasional architectural discussion or piece of insight. Enjoy the ride!

We’re using Amazon EC2 in this class. The first thing I managed to do was get an Ubuntu server up and running (using 10.04 LTS). This wasn’t too hard. The next part was getting Apache 2 and Python installed so I can get a basic web server going. This required the following packages:

  • apache2 (and all it’s dependencies)
  • libapache2-mod-python
  • … and a few other python-* libraries that I won’t detail here.

All fine and dandy. It amazed me how fast apt-get install was able to run, since there appears to be an Ubuntu repository hosted on S3 in the same region.

But Apache won’t actually run Python files until you configure it to do so. I did this by editing /etc/apache2/sites-available/default and adding three lines to right section. I put them in the <Directory /var/www/> section, since that’s where my code is going to go.

    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all

        DirectoryIndex index.html index.py

        AddHandler mod_python .py
        PythonHandler mod_python.publisher
        PythonDebug On
    </Directory>

And it works! Awesome.

Facebook, Apple, Google, and the open web

I just read David Siegel’s “Open Letter to Sergey Brin, Larry Page, and Eric Schmidt.” He gives a lot of good ideas about why Google should use a “personal data locker” (something that Phil Windley, Doc Searls, and others have been working on for quite some time) to keep the web open.

David cites the example of Vitamin Water, which has moved its website to a Facebook page. Facebook offers it a lot of data about users, including the ability to tailor pages to the viewers. But even with the lure of those built-in social features, submitting one’s web presence to the control of Facebook is a bad idea for any company.

The problem is that everything is in the hands of that one entity, who, as we are all aware, is free to change the rules at any time. That topic’s been rehashed over and over again, so I won’t discuss it here.

But now take a look at the different approaches adopted by two other big market players: Google and Apple. Google is fighting for an open web (e.g., with Chrome OS); Apple is fighting for a closed ecosystem (iOS and Mac).

The only way to get apps onto a user’s iOS device (barring open web technologies) is by jumping through Steve’s hoops and submitting to his draconian policies. We’ve accepted that; it’s the price developers pay to get native apps into that ecosystem. But look at the Mac App Store. Developers who want the visibility that the Store gives them will submit to the hoop-jumping and policy-abiding necessary to get their software listed. It would be easier for them to host their apps on their own websites and point people there to download them, but they may instead opt to let Apple control it. This is quite similar to Vitamin Water submitting their web presence to the control of Facebook.

Chrome OS is on the other side of the spectrum. Google is trying to drive developers away from native development and toward web development using open technologies. Native applications have their benefits, but there are also costs with supporting multiple platforms, dealing with support and updates, etc. Web applications let developers transcend those unnecessary limitations. Google doesn’t want to control an ecosystem; they want to promote an open web where everyone (including Google) can benefit. That is key to their strategy.

Google has the tools to make the open web succeed. I said a few weeks ago that “Chrome OS will succeed because it’s invisible to the user. People understand the web. They don’t understand operating systems.” By the same token, the web will succeed because it’s not bound to particular vendors (hardware, software, or otherwise). What we need now is for companies like Google to step up and give people enough viable alternatives for personal (and corporate) data management that they won’t feel compelled to be locked in to a single ecosystem like Facebook, Apple, or even Google.

We need the open web to succeed.

Hiding the “personal appeal” banners on Wikipedia using Kynetx

I’ve already seen the Wikipedia banners a million times: “Please read this personal appeal from Jimmy Wales/Sue Gardner/whoever”. I’m not interested in seeing them anymore. So I wrote a simple Kynetx app to get rid of them.

Here’s the code:

ruleset a163x33 {
  meta {
    name "Hide Wikipedia notices"
    description <<
      Hides the siteNotice>centralNotice divs at the top of Wikipedia
      (such as the "personal appeals" from people)
    >>
    author "Steve Nay"
    logging off
  }

  dispatch {
    domain "wikipedia.org"
  }

  global {
    css <<
      #siteNotice > #centralNotice { display: none; }
    >>;
  }

  rule hideNotice {
    select when web pageview "en.wikipedia.org/w(iki)?/(.*)"
    noop();
  }
}

It basically just emits some CSS that will hide all the div tags with the id centralNotice that occur as direct children of the siteNotice divs. Then it does that any time you visit a page on Wikipedia. Really simple.

Now those banners will never appear at the top of Wikipedia articles anymore!

You can get this app on the Kynetx MarketPlace.