We Should Not Bite the Hand that Diggs

I’ve been noticing that Digg has been getting a substantial amount of cr*p about things they’ve done on and with the site recently. Nothing new or exceptional, as every popular Web outfit gets the community treatment once in a while, but now that the dust settled a bit, I just wanted to express the following thoughts.

I had the pleasure to meet with some of the Digg crew in San Francisco last month, coincidentally hours before they released their new commenting system. What I saw was a group of people who, on top of being passionate about their respective vocations, actually believe in the product they bring us. This is a relatively rare and precious thing, and I think that as a community, we should nurture it as much as we can.

I’m definitely not saying we should just fall into blind fanboy-ism and idolize their every actions, but I do think that there’s a [not so] fine line between constructive criticism, which is usually welcomed by any self-respecting professional, and plain old bashing, which can be the most depressing aspect of public releases. And it’s not like they’re not listening (1, 2).

Yes, I do think that a balance between surprise releases and usability testing could gain to be developed. And yes, I do understand that sudden changes to something you enjoy can be offsetting for users. But I also know that they’re cultivating a tight-group/almost-family-like atmosphere amongst their ranks, and that the last thing I want is for the people behind the code to be nudged anywhere close to just being yet another bunch of salary makers, in yet another faceless corporation.

So I say, keep on guys, and thanks for your efforts. I’ll happily keep on digging and watching the site evolve.

And no, I’m not going to submit my own post to Digg. ;)

Amstrad CPC 464

I was recently talking to someone about the first computer I owned: an Amstrad CPC 464 (@wikipedia). Attached is a nice flickr photo of the beast in all of its 64kb-RAM-and-tape-recorder glory.


Good times; good times indeed. I was 12 (1987) and saved my money for around two years to get one. It was my first major purchase on my own. The first computer I used was a Thomson TO 7, and its lovable turtles, at school.

A "man pages" approach to information

It still amazes me how Unix man pages shaped my approach to digesting information.

I first started using Unix-based systems around 1997. My Unix mentor had, in retrospect, a fantastic approach to helping me out on my autodidactic path. Whenever I needed help with a command, he would always prepend his answer with “man”.

I: How do you check your disk space?
Len: man df
I: ???
Len: man man

I am now more than grateful for his wisdom, but I cursed it many times in context.

What amused me the most about the man repository was how it was simply impossible to read one page without reading ten others, by curiosity if nothing else. The same holds true for many subjects, but man pages have this special twist that unlike so many other publications, they never dumb down their content to widen their audience reach, but instead historically assume that the reader is a highly trained operator and knows (or should know) everything about the rest of the system. This shapes an interesting vicious cycle, since it makes for a documentation system with essentially no true beginning or even accessible entry point.

While this might be perceived as a flaw in the man’s matrix, it truly catalyzed my habit of always pushing myself to learn and know more than just what I need for the very task that brings me to a piece of information. To this day, I find myself quasi-incapable of reading anything without going into the research equivalent to a shark’s feeding frenzy, unless I’m on a on a tight schedule, in which case I only limit and control myself.

In the end, two things are for sure: Thank [insert fav’ deity here] for hypertext, and Digg, Facebook , Slashdot, et alii sure do not help one bit. ;)

It's a Love / Hate Thing

It’s days like this I both love and loathe my vocation all at once.

Love it: never bored, always have new things to learn, mentally challenging, great interaction with the many development communities, constant stream of new opportunities, etc…

Loathe it: there are only 24 hours in a day and my body and brain stubbornly force me to sleep for a few of these… Almost every day too…

Thirteen years of web app dev, and still see it it as the World’s biggest playroom. :)

parseMe 20070602 Update

Here’s another update to parseMe (back story), my little GPL’ed PHP-based RSS/Atom feed reader for mobile phones and other web-capable devices.

You can find the appropriate links below:

Release notes:

  • Moved my CVS repo to Subversion (svn), hence the revision number differences. I considered moving to a distributed revision control system, since they’re gaining in popularity, but I got lazy after the major rewrite. ;) Maybe for the next release.
  • This is a quasi-complete code rewrite. In this release, I have moved away from the initial goal of keeping within the 500 lines limit (including comments) and having an “educational” flavour, to focus instead on the code structure, the features, further increased security, etc. The security aspect does account for a lot of the extra lines, when coupled with the new features.
  • The parseMe class has now been substracted from the index.php script and has been moved to lib/php/parseMe.class.php.
  • One of the most significant features, on the user end, is that you can now request any number of feeds to be parsed at once. Keeping in mind that the main target audience for this tool is the mobile market (usually slow, tiny screens, low RAM, etc), the usual total number of feeds offered does not lead to major performance hits, unless of course the sources themselves are slow to answer the tool’s request(s). You can of course still set your feed selection in the cookie-based preferences, which now allow for multiple choices.
  • With the multiple feeds feature, the next logical step was to enable some sort of sorting options. You can sort the entries by feeds, or from new to old (descending) or from old to new (ascending). Your favourite sort order can be saved.
  • You can now opt in or out of using the Google Mobile Gateway for destination links, right from the query form, and save your preferred choice.
  • On the server end, self-contained caching is now done through PHP data serialization, since there is no point in reparsing the same XML at every page load, after all.
  • On the security front, and primarily with the concern that we do have an application-writable directory (cache), there are quite a few improvements. Since the data contained in the cache files is not very sensitive by design (and if it is, I’d suggest using ssl and password protecting the app), this is really more of an exercise in good coding practices. And there is of course the concern of php injection attacks.

    • The cache filenames are now generated as a sha1 sum, with the help of an admin-defined shared secret so that they cannot be easily guessed.
    • All cache files now start with a dot (.) so that most web servers will not even serve them, and to be invisible when directory listing is enabled at the server level.
    • On the other hand, there is still a very strong emphasis on user input sanitazation and usage in the logic itself (EG: no client-defined source URL, source validity tests, etc).
  • Fully valid class documentation can be leveraged in IDEs such Eclipse, auto-documentation tool such as phpDocumentor, etc.