walkah

Using Drush to Mass Delete Comments

2012-04-12T21:00:00-07:00

Like many kind, good-natured geeks, I (yes, I was talking about me) host a number of small sites for friends. Many of those sites run Drupal and several don't get a lot of attention. That is, until spammers find their way around Mollom. I've seen this happen a few times, but most recently on a Drupal 7 site. In this particular case, the spam comments had been trickling in over a few weeks undetected. Following a burst of recent activity (enough to notice via monitoring), I checked in to find > 60,000 spam comments.

If this has ever happened to you: you're not alone. At this number of comments, using Drupal's interface (50 comments at a time) isn't really usable. Also, these things tend to happen in bursts - so chances are good there's a block of comments that are all spam (i.e. there haven't been any legitimate comments that you want to save since it started). So, I whipped up a small script here:

<?php $first_comment = 38898; $num_delete = 50; do { $cids = db_select('comment', 'c') ->fields('c', array('cid')) ->condition('cid', $first_comment, '>=') ->range(0, 50) ->execute() ->fetchCol(); print "deleting ". count($cids). " comments...\n"; comment_delete_multiple($cids); } while (count($cids) == $num_delete);

Here's how to use it:

Place the code in a file (say, comment-rm.php) in your Drupal directory.
Find the cid of the first spam comment (exercise left to the reader) and set $first_comment to that value.
Run drush scr comment-rm.php and go grab a coffee.

Hope that helps someone, but at least now I can find it again next time.

Beware: This deletes comments forever, be careful.

SOPA and the Long Haul

2012-01-17T21:00:00-08:00

Today marked one of the Internet's broadest, most visible protests. Several large internet properties, including Google, Wikipedia, Reddit, and Mozilla, participated in a "blackout" in an effort to raise awareness of (and put a stop to) two bills currently before the US Congress: SOPA and PIPA. Chances are good that this isn't news to you.

If for some reason you don't know, here's a (technical, but) good explanation of what can go wrong with these bills.

As I watched the events of the day unfold, I was grateful for the new awareness, had a chuckle at those who don't get it, and of course enjoyed the irony of copyright violations by PIPA supporters. However, I was left feeling uneasy. SOPA and PIPA aren't new problems - they are merely the latest efforts in an ongoing battle. I was pleased to see this article in Read Write Web which spoke to what I was feeling:

Sure, call your representative and senators today. Protest SOPA and PIPA. But beyond that, keep paying attention to what your elected officials are doing. Spend a little more time paying attention to your government, even if it means spending a little less time on entertainment activities.

If you want a quick overview of the broader context, this TED Talk by Clay Shirky is a fantastic quick overview.

This is a long, ongoing battle between last century's media money and the Internet. It's neither new nor is it going away.

#StopSOPA - but don't stop there.

PHP Xdebug with Vagrant

2012-01-11T21:00:00-08:00

I've been asked a few times about getting Xdebug for PHP working in a Vagrant environment. Most people tend to use Xdebug on localhost and IDEs are often able to configure themselves to work without much hassle in that environment. However, putting PHP in a virtual machine makes the setup a little trickier.

Xdebug works by using a protocol known as DBGP over TCP. What makes it slightly confusing, however, is the protocol flow happens in reverse from how most developers are used working: the server makes connections to your "client" (e.g. your IDE). Your debugger actually listens on a port (9000 by default), and Xdebug connects to that. Understanding that makes the setup make a little more sense.

Vagrant generally uses "Host-Only Networking" with an IP for the virtual machine of "33.33.33.10" (see the documentation). In this scenario, your host machine (i.e. where your debugger will be listening on port 9000) is accessible from the VM at 33.33.33.1. That means, we need to tell Xdebug to make it's connections to 33.33.33.1 on port 9000. This can be handled by the following php configuration:

xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=33.33.33.1
xdebug.remote_port=9000
xdebug.remote_autostart=0

I handle this configuration with this xdebug.ini.erb template in my chef-repo.

I have found that this works quite well with my Emacs setup using geben, but I've not yet tested it with other IDEs.

New Year, New Blog

2012-01-07T21:00:00-08:00

Almost 9 years ago, following the launch of my first major Drupal project, I converted this site to run the software that has shaped my career (and my life) for past decade. However, much like my career, this site was ready for a change.

Everything old is new again

This site is now powered by (or generated by) Jekyll - not entirely unlike the homegrown set of scripts that generated this site before it moved to Drupal. Jekyll has become hugely popular over the past few years in large part due to Github pages.

I knew I wanted out of the maintenance overhead of having a dynamic site (security upgrades, monitoring comments, etc) and spent a lot of time looking around at the various alternatives. I nearly ended up using Hyde because I'm generally more comfortable in Python than Ruby, but the Jekyll momentum means that there are plenty of resources around for doing things.

My biggest goal was to get back to writing instead of applying updates (and thinking of more efficient ways to apply updates). I have never enjoyed writing in a browser window. In fact, the handful of blog posts I wrote last year were all written/edited in Markdown in Emacs and copied to my site after. The move to Jekyll is to bring me closer to that writing workflow.

While I've never been much of a "blogger" per se, it's clear from looking through my archives that I used to write in this space far more frequently than I do now.

No comments?

You may notice (particularly if you're reading this on my site and not in a feed reader) that I don't have any comments enabled. This is deliberate - a statement if you will. I don't think we (the internet) have figured out how to do "social" - by which I mean conversations - in a good, decentralized, federated way yet. I have a lot of thoughts on this whole topic that I hope to share in a separate post.

The setup

On to the geeky goods! I've spent a little time here and there over the past week figuring out how I wanted things to work and the best way to make it happen. My full site is available on Github, but I thought I'd highlight some important pieces:

First up, was pulling all of my old content out of Drupal. Because walkah.net was running Drupal 7 - the included migrator (which is based on Drupal 6) didn't work. My modified version is in _import. It's specific to my setup, but should be a good starting point for anyone attempting a similar move.

Next, a lot of my site's traffic is generated from per-tag feeds offered by Drupal's taxonomy system. This isn't something that jekyll provides out of the box, so I created a simple plugin to generate tag listing pages and associated feeds.

When you run a Drupal site through as many major versions as I did, things change. As such, I ended up with a bunch of duplicate path aliases. Jekyll, by default, ignores all "dot files" (file with '.' at the start of their name), so I used this hint to include an htaccess file where I keep any redirects/aliases/etc.

Of course, since I wanted to be able to write my posts in Emacs with markdown-mode, I am making use of jekyll.el from Jack Moffit. Creating a new blog post is now M-x jekyll-draft-post!

Finally, I'm using a very simple Rakefile to deploy new blog posts via rsync.

Now I can blog from the place where I do most of my writing (emacs), publishing is a single shell command, and there is 0 maintenance required for my personal blog. Progress!

Why Vagrant

2011-07-04T21:00:00-07:00

Few things are as frustrating in the life of a (web) developer as those unfortunate times when, despite passing QA and testing, your latest feature, bugfix or completed task stops working when it gets to production. Nobody likes to have the sweet feeling of "go live" victory wasted. While any number of things can cause the embarrassment and wasted time, one way to significantly reduce the number of potential errors is to keep your development, staging and production environments as close to each other as possible.

Lately I've been dealing with my own special, self-inflicted challenge: I have two machines (a thinkpad x201 and an older, pre-unibody macbook pro) that run two different operating systems (Ubuntu 11.04 and Mac OS 10.6, respectively). Now, why I do this is probably a longer discussion, but I do - and I like it. Just to add a little more (minor) variation, my personal projects, experiments (and in fact this blog) all run on linode instances (running Ubuntu 10.04). The end result is, my development and "production" happens across 3 different OS versions. Standard package installations of development tools (regardless of which technology I'm exploring at the moment) are rarely ever the same release version. Throw in some subtle and potentially maddening differences between linux and os x (case insensitive filesystem, what?) and I've lost too much time debugging my own fixes.

As it turns out, I do an okay job of emulating my own little development team (except in productivity, of course).

In a more real world scenario: I have been doing some work lately with Myplanet Digital (a fun team located in Toronto - and they're hiring). One of their portfolio client projects is a fairly large, complex Drupal implementation. The production version is hosted on Acquia cloud hosting, they host their own QA / CI / testing infrastructure, and their (ever-growing) development team uses a mess of mac os x and windows versions. They are continually looking for ways to streamline their development process - and avoid any needless debugging time.

Vagrant Chefs to the rescue!

I've developed a growing interest in two tools to help solve this dilemma: Chef (for environment management and provisioning) and Vagrant (for local, VirtualBox based virtual machine management). Vagrant is super easy to get running, like it says on the home page:

$ gem install vagrant
$ vagrant box add base http://files.vagrantup.com/lucid32.box
$ vagrant init
$ vagrant up

Assuming you have a reasonably functional ruby environment and have a recent version of VirutalBox installed, that's all there is to it! Chef (for provisioning), however, has taken me a bit more time to get my head fully around. You can see my experiments happening live(ish) on my github account.

But I don't use lucid32!

One interesting thing about the Acquia managed hosting platform, is it's all built using Ubuntu Hardy (8.04). In Internet years, it's rather old but has some significant differences from Lucid (and most current packaged versions of the LAMP stack) - PHP 5.2 (vs. 5.3) and MySQL 5.0.x (vs. 5.1.x). To do this right - to actually replicate the production environment for development - it's important to have these versions in sync. There are subtle differences between these versions that can trip you up. Enter veewee. A few weeks ago, I provided a pull request for veewee that added a "hardy32" template - for building a vagrant box with the same version of Ubuntu found on Acquia hosting. For the lazy, I've posted the base box to my dropbox account.

Overall, I've found it requires a bit of tinkering (I'll try to share more as I go), but the result is that I can deploy code with a bit more certainty and that is worth it. I'm here tinkering, so you don't have to.

I should also mention, that all Drupal developers should checkout the vagrant project on drupal.org for a nice general solution for Drupal apps.

Dev Ops!

Every Drupal Site is an Install Profile

2011-05-19T21:00:00-07:00

I've been working with this hypothesis while working on Drupal 7 sites. I don't think it's necessarily revolutionary, but I would like some feedback. Currently, I'm approaching every Drupal site build as its own install profile.

Back when we were running Bryght, we recognized the need for "Installation Profiles" as a way to focus the highly configurable, but largely baffling initial experience with Drupal into making sense. We had lofty dreams of catering to various verticals with streamlined, elegant experiences that took the immense power of Drupal and made it make sense for new users. That was Drupal 4.5... we were maybe ahead of our time. Needless to say, a lot has happened with Drupal since then.

With the release of Drupal 7, one of the things people aren't talking about as much are the vast improvements to install profiles. For the first time ever, Drupal core ships with more than one install profile, which has also meant that for the first time people are consciously aware that such things actually exist. In D7, install profiles behave much more like other Drupal packages (i.e. modules and themes). They have .info file and .install files. They are far easier to create than ever before.

Clearly, I'm not the only one who sees the importance. Development Seed and now Phase2 Technology have invested a lot in install profiles such as OpenAtrium. For creating Drupal products such as Atrium, install profiles are important and central. What I am talking about, however, is to create an install profile for every Drupal site you build. In updating this very blog to D7, I created an install profile for my site to test (and tinker with) my theory.

The theory

What is a Drupal Site? Well, once you've determined a version, core remains unchanged across most sites (you know, don't hack core and all). So what makes a Drupal site your Drupal site is: 1) a theme 2) your selection of contrib modules and 3) any custom code / modules you may have written. If we dig a bit deeper, the things unique about a Drupal site are typically: 1) a theme 2) any custom code and 3) the list of contrib modules / libraries in use. It just so happens that an install profile can nicely encapsulate this information for us. So why bother?

A Drupal site rarely only gets installed in one place. Best practice suggests that we use development, staging and production for our websites. If we work on a team, "development" will actually be a separate install for each developer on the team. Being able to reliably install and replicate your site will actually make things much easier - whether it's just you or your whole team.
Drush Make works well like this. Your profile can have its own makefile (as openatrium does). Drush make will recursively make install profiles, and will add all contrib modules and libraries into your profile's directory. Maintaining nice separation.
Make the most of multi-site. Since your core version remains constant (at least for major versions) across all the sites you work on, why do you keep installing core? In my development environment (which I will write more about soon), I have 2 virtual hosts d6.dev and d7.dev. All of the sites I'm working on fall under one of the two. Thanks to drush make, I can have a single makefile for each major version that recursively grabs each profile (i.e. site or group of sites) that I'm working on for that version. The same can be used in production or not - the install profiles can move independently to production.

The end result is, I have very small custom repositories - containing usually a drush make file, a custom module or two and a custom theme. Checkouts are a breeze and I have a clear manifest of any other other code I'm using.

Objections

Now, historically this isn't how people have approached Drupal sites. Historically it's not even how I've approached it. Generally, we have single repositories with all of core, our modules etc. Generally, a single repository containing all of the core, contrib and custom code - for years in subversion and now folks are transitioning to git. An argument for continuing this way (I received from webchick herself), is that a single repository makes it easy to see things like if someone has made changes directly on production (?!?!) or that just by having a single checkout all developers / installations have the exact same code.

While I think "hot fixes" in production are a bad idea (no matter how small the site), the latter objection (exact same code) is worthy of a little more discussion. Keeping things in sync with Drush Make is a bit more work (always pin your versions!), I think it's a worthwhile habit to establish. Yes, git is fast enough that those long, painful svn checkouts are largely a thing of the past so having all of your code in a repository isn't as punishing. For me, the hosting considerations above are significant, but another thing came up for me recently:

If you build a lot of Drupal sites, chances are good that there is some overlap. Say there is a patch that you need for a favourite contrib module, drush make means that you can explicitly apply the patch (and maintain it outside of your repository - or pull directly from the issue queue). Similarly, using independent feature module features allows for similar mixing and matching. Each module (or theme) should have a single, canonical source and a Drupal site is simply the combination or collection of them.

It seems to me there are real gains in being explicit with makefiles, being smart about hosting and re-using core, and being modular in our repositories (using drush make to pull it all together).

Am I crazy?

Where's walkah been?

2011-04-07T21:00:00-07:00

It was brought to my attention some time ago that this space has been rather shamefully quiet. I have also spent a lot of time facing the "so, what are you up to?" question lately. In a "two birds, one stone" manner, I'm gonna try to get into writing a bit more as well as provide a bit of an update.

So, what do you do?

This has long been one of my most dreaded "light social" questions. Ironically, I found myself tossing it out at a recent event, perhaps in some passive aggressive sort of revenge. It's always been difficult to explain what I do, particularly in in non-technical company. For many years "I work on Drupal" was an answer that got the most amusing blank stares. Of course, these days that tends to be less baffling to people, so naturally I've stepped out and been doing lots of non-Drupal things.

For those playing along at home, StatusNet Inc. and I parted ways last November. I actually consciously did not post about it publicly because this blog was starting to feel a little more than a broadcast space for my shuffling between companies. While I don't have an official involvement these days, it looks like I will be doing some Summer of Code mentoring and am still very interested in the Federated Social Web and the protocol, OStatus that we developed.

No longer having a full-time job means that, yes, I am doing freelance work (hire me!). It has also meant that I'm getting back involved in the Drupal community again a bit more. Some folks noticed that I've been to the past two DrupalCon's (after taking a few off) and have been working with a few Drupal-based clients.

The thing that I'm probably enjoying most these days is the freedom from focusing or specializing. For the past few months, I've been working with the Mozilla Foundation on the platform that runs the Drumbeat website (implemented using Django). I've followed and tinkered with Django for a long time and it feels great to have a "real" excuse to spend more time with it!

While a lack of real "focus" (at least amongst open source projects or even programming languages) has really appealed to my inner tinkerer, it's made answering "what are you up to" a far more involved conversation; some days it's consulting, some it's teaching/training, and some days I just hack on code. I also fully expect the answer to change and evolve over the course of this year and moving forward.

More writing!

Doing more (and different) things also means I'm learning a lot these days, and I feel compelled to share, because that's the way I am. However, writing has always been challenging for me. I work really well verbally (preferrably face to face, though I've done alright talking to a camera). I have always wanted to be a prolific writer, though. For the past few months, I've been trying to practice more. I started with a paper journal, but after losing one and finding that my handwriting no longer keeps up with my brain well, I decided to try writing on my computer. Ultimately, though, I found it hard to establish a good routine and stick with it.

A few months ago, though, I gave 750words.com a try and I love it. After a few false starts, I now have a daily 750 word routine that I'm finding helps get me writing (and thinking) for the day. I highly recommend the service (and the practice of writing regularly). The practice has already translated into an article for the Linux Journal and will hopefully result in more!

At the very least, I'm hoping to make better use of this space. Welcome back, me.

Local development for external APIs

2010-08-19T21:00:00-07:00

Lately I have found myself doing a lot of development against external APIs, several of which require those services to be able to access my dev site directly. Traditionally, I've set up my dev sites on a public server (usually my personal VPS), mirrored the site locally, and used rsync to push incremental changes from my local machine to the server.

This is a pain for two reasons:

It means I have an extra step (to rsync) after each change. Yes, it's the same command over and over, but it gets repetitive. Also, if I forget, I spend a few minutes trying to figure out why the change I just made doesn't appear.
I'm also left with old dev sites (that I generally forget about) out on the public web - generally not getting proper attention for security updates, etc. This leaves my VPS open to attack.

I also spend a lot of time tweaking my local environment to be just-how-I-like-it(tm).

Recently, I had an idea that, in hindsight, seems obvious. However, in talking with a few people, it seemed just novel enough to warrant the high bar of intellect that is a blog post. So here is the magic:

What you need:

A wildcard DNS entry (i.e. *.home.example.com). I'm lucky that my home ISP allows me to have a static IP address, but a DynDNS or similar account would also work.
A linux/mac computer attached to your home/office network that is not currently running a web server (i.e. port 80 is unused) - preferably connected via ethernet. I happen to have an old mac mini that serves as my "media server" at home that I'm using.
Ports 22 and 80 forwarded from your router to the aforementioned computer. (This is left as an exercise to the reader).

The "magic":

Given the above, the rest is really quite simple (and perhaps obvious to some). A simple ssh port forward does the trick. Here's the command I use:

ssh root@home.example.com -R 80:localhost:80

For the unfamiliar, that says ssh into home.example.com as root and send all the traffic coming to port 80 at home to port 80 on my localhost.

Voila! Now all requests to home.example.com will come to my local server and I can setup vhosts, etc accordingly. Also, if I just end my ssh connection, I no longer have to worry about the big, scary Internet accessing my dev sites.

TODO

I'm not 100% happy about allowing root ssh into my home network, so I may spend a rainy Sunday afternoon and setup an HTTP proxy at home that forwards to something like 8080 on localhost (and perhaps gives a nice "we're not home" message if I'm not ssh'ed in). That way, I wouldn't need to ssh in as root (which is necessary to bind the "low number" port).

If you do much tinkering with remote services (particularly OAuth-based services or webhooks, etc.), I hope this makes life just a little bit easier for you.

One wedding and a camera

2010-05-26T21:00:00-07:00

My little brother, Chad, and the awesome Elisa got married this past weekend. It was an amazing weekend by the sea in Rockport - the weather was great, the food was incredible and I had a wonderful time.

Since my whole clan was in the wedding (Camryn was flower girl, Andrew a groomsman, and I was best man), I decided to rent a "real camera"(tm) for the weekend to capture the experience. It was my first time really experimenting with a nice camera. I'm glad I did! I had a lot of fun. Check out the results on flickr:

Feedback welcome - especially from you real photographers out there. Now to start filling my piggy bank for a real camera...

Joining StatusNet

2010-01-14T21:00:00-08:00

In case you missed the announcement yesterday, I have taken a position with the Montreal-based startup StatusNet. For the unfamiliar, StatusNet Inc is the company behind the StatusNet open source micro messaging platform.

I think StatusNet is a very interesting project and one I've been following for a long time. It's a true Open Source project that seems to be a perfect storm of technologies that interest me and a commitment to openness that I admire.

What really excites me about StatusNet, though, is challenge of federation. StatusNet installs currently ship with an implementation of a protocol known as OpenMicroBlogging. This means that you (or your company / organization or book club) can have your own real-time, micro messaging site (read: your own twitter) and if there's someone not on your site you'd like to follow, you can do so without having to register (and monitor) multiple sites.

We're currently planning a major update to the protocol to take advantage of some of the exciting new stuff like PubSubHubbub and ActivityStreams. I'm excited to get to work on the protocol and implementation and tell you all about it :-)

Ch-ch-ch-changes

2010-01-05T21:00:00-08:00

This year promises to be an exciting one - and one that proves to be full of changes galore. As I mentioned in my last post, much of my 2010 change began late in 2009.

Cue the Bowie...

Leaving Lullabot

Although it's been largely quiet (and really not a huge deal), before the rumours spread too far: I've left my position as the Director of Education for Lullabot. I'm leaving behind a totally awesome team and a wonderful job (in the midst of a recession). Why on earth?!

Let me be very clear: Lullabot isn't in danger, stopping Drupal training, nor is there any backroom drama. The 'bots are wonderful people and chances are very good that we'll continue to collaborate in the future (at the very least, there's still hugs).

This was a very personal decision - and one that was a long time coming. For the morbidly curious, it boils down to three things (and those of you who know me well, know it always comes down to three things):

Travel: Anyone who is friends with a 'bot on Dopplr or Tripit knows that the job entails a lot of time on the road. With over 230 days on the road in the past 2 years, I needed and my kids deserved a break. While we (Lullabot and I) largely worked around this - it's still just part of the gig.

Drupal: I stood up in front of a rather large group of Drupal folks almost a year ago and explained why I hate Drupal - so it's obvious, right? While I feel the points I tried to make still face the community at large (such as smallcore/drupal is not a product, or even rethinking the maintainer structure), I don't actually hate Drupal (as those of you who grok sarcasm might have noted).

However, Drupal has been my full-time job for 6 years. In that time, the community (and the software) has grown and changed considerably. It has been an amazing ride. As Dries mentioned to me on the phone a few weeks ago, "once a Drupal guy, always a Drupal guy". This is probably true - I have no intention of leaving the community, but I am ready for some new challenges.

Open Web: One thing people may have noticed is that when I have had the chance to hack on Drupal lately - it tends to involve "open web" or "open standards" implementations (notably, OpenID etc). Many folks have also noticed that my contributions have trailed off lately. When your "after hours" time starts including more things like "sleep" - your after hours projects take a hit.

I'd like to get back to building cool, new stuff. While I certainly get a lot out of teaching people how to make the most of the tools available, I'm passionate about building the next tools (which doesn't exclude Drupal). These are interesting times on the internets, I wanna have my nose in the middle of it.

Now what?

Officially, I will be freelancing (technically have been for a few weeks). I've already got some interesting things lined up that I'm excited to start talking about soon.

In #2010...

2009-12-31T21:00:00-08:00

It's that time of year - for reflecting and resolving - and, naturally... blogging about it.

2009 was not awesome. Not a terribly awful year, nor my worst ever. It was, however, a year full of challenges - all of which have been opportunities for growth. 2009, though, got off to a rough start and didn't end much better. As much as I've grown, I'm definitely looking forward to moving forward.

I don't know if I have resolutions this year, per se. I do have two words that have been on my mind a lot lately:

CREATE I am eager and excited to do more, to make more. I would like to write more, build more tech and (dare I say it?) write some music. I want to look back next year when doing this blog post and be able to see all the things I've created - good and bad. I'd like to have fewer ideas left swimming in my head otherwise untouched.

OPEN I've long been an advocate, user and developer of open source software. In part, it's a renewed passion for free and open technologies. Beyond that, however, continuing to move towards openness in my life, my heart and in my relationships.

2010 promises to be another year of great change for me. Lots of which is already underway (more on that soon).

Here's hoping you and that you stick to your resolutions and reach your goals and have an awesome year!

Now on Android

2009-12-27T21:00:00-08:00

Almost exactly one month ago, I made the switch from my old, 2g, jailbroken iPhone to a brand new fully legit android phone: the HTC Hero.

My reasons for the switch were varied - it's a platform I'd like to support, hack on and one I generally find interesting. I've also grown increasingly frustrated with my suite of Apple products and, in general, am looking to "live open" (more on that later).

Treats

There are some things that I absolutely love about the Hero: way more than the iPhone:

It is an aesthetically pleasing device. This is one thing that has kept me on Apple gear for a long time. I appreciate quality design - particularly in the products I use constantly every day. The Hero is a good looking device and feels good in my hand.
Multi-tasking. Yeah, this is the big "killer feature" over the iPhone, but it's really handy. I consider my phone primarily a communications device and I can see instantly and easily who is emailing, texting, IM'ing or mentioning me on twitter all without quitting the app I'm currently running.
Contacts a central. On a contact's record, I can see all phone calls, emails and texts with that person - and even their Facebook status (or birthday - nice touch).
Really great sync. Now, let me start by saying - I'm a google apps user. That said, all I did was add my gmail account information and instantly I had all mail, contacts and calendar entries seemlessly sync'ed to my phone. Oh, and (unlike "mobile me") there was no additional cost.

Frustrations

This isn't quite the ultimate phone yet. Here are my top gripes:

No paid apps in the Android Market in Canada. I'm confused as to who is really to blame here - whether it's the big US companies or the Canadian government or a combination of the two, but living in Canada can be a real drag sometimes.
Lag. It's not a blazingly fast phone and when you add running multiple simultaneous apps, the interface can get laggy after a while. A good "task killer" app on Android seems to be a best friend. (I'm currently using TasKiller, FYI).
Lots of the apps just aren't as good. Twitter apps are a significant comparison - there just is not a tweetie 2 comparable app. That said, there is a google voice app ;-)
Version lag. This seems to be particularly bad on my HTC Hero (which currently uses Android 1.5), but in general handset manufacturors seem to be slow to roll out the latest version of android for their handsets. Doing so yourself, requires rooting (how is that an advancement from iPhone?).

Conclusion

Overall, though, I'm happy about the switch. I think the Android future is bright and hopefully I'll have some spare time here and there to hack on some things in support of the platform.

Change Medium Toronto

2009-10-18T21:00:00-07:00

Calling all social web "hackers"! I've been asked to help put together an awesome event:

Change Medium Toronto

If you love hacking on emerging technologies and recognize the effect they're having on society. I'm talking about things like Activity Streams, OpenMicroBlogging, and PubSubHubbub. We'll be looking at the latest microblogging and real-time web technologies - with the very simple goal of building something new.

The truly awesome Evan Prodromou will be there representing StatusNet. You should join us too.

Toronto, let's get our geek on and make stuff! Sign up here - and I will see you there!

Living in the browser

2009-09-21T21:00:00-07:00

For a long time I've maintained that I hate web applications. It's good for a laugh (in certain circles), but has been mostly true. Web interfaces have (traditionally) been clunky, lack integration with the desktop, don't work offline, and are generally just unpleasant to use.

Lately, I've been re-testing that theory and have surprised myself with the results:

I'm living in the browser.

OK, not entirely. But my currently running applications include: Firefox, Emacs, Terminal, Adium and iTunes (sorry, songbird).

The frequent, attentive readers among you know that I've been tinkering with "Single Site Browsers" lately as part of this experiment - because, if I'm using Firefox for development - I don't want "other stuff" cluttering that. Well, a recent article on lifehacker made me rethink my approach.

The article outlines a way to have "permanent" tabs(i.e. tabs that automatically reload when you restart yoru browser) that only appear as a favicon (thus saving screen real estate). My current lineup looks like this :

That's gmail (personal and work), remember the milk, google voice and google reader.

For the last few weeks, I've been trying out this system and have found little reason to want to switch away from it. There are some properties that appeal to me: my application list is entirely cross-platform (substitute pidgin for adium) and free software. Application management, setup and configuration is minimal and I have to do very little application switching throughout the day. In fact, with my external monitor, I can fit everything on one screen where I can see it.

Ditching a desktop mail reader was obviously the biggest shift. But in the case of gmail, rtm and google reader there are a few things in common that make these "work" for me as desktop replacements: offline mode (thanks to google gears), extensive keyboard shortcuts (better than their desktop equivalents), regular updates / improvments and APIs / methods for extensions.

Here's my current list of Firefox extensions, let me know if I'm missing any great ones:

1Password
Better Gmail 2
Better GReader
Evernote Web Clipper - still determined to use evernote effectively
FaviconizeTab
Firebug (always)
Gmail S/MIME
Google Gears - offline goodness
Greasemonkey
PermaTabs Mod
Remember The Milk for Gmail - to help solve the problem of my todo list not getting enough 'focus'

How much of your life do you spend living in your browser?

The rebirth of customer service

2009-08-06T21:00:00-07:00

I am a fairly frequent traveller. As such, I have seen the worst of airline industry - an industry that has all but lost the notion of customer service. (Those of you currently hating on United - flown American lately?). For months, I have considered blogging a lengthy rant about just how atrocious the employees of the major North American airlines are to their customers. However, I'd like to try something different: A glowingly positive, upbeat blog post:

I recently (at last!) took my first flight on Toronto-based Porter Airlines. Porter operates on Toronto's Island Airport - which is already a big win (saving me a trip out to the western suburbs). Their motto, which has intrigued me since their launch, is "flying refined" : they deliver.

My trip started with frustration: due to a hectic morning (setting kids up with gramma for the week, attending a meeting, packing, etc), I was running late and decided to call a car. Said taxi service (who get no points for customer service) showed up 25 minutes late. I began dreading the potential hassle I faced by arriving last minute at the airport.

Enter Porter.

I made it to the check-in counter 35 minutes to flight time (a full 10 minutes after the 45 minute check-in cut-off for US flights). Expecting the usual condescending lecture about leaving more time before my flight, I approached the counter. I was greeted with a pleasant smile and, after showing my passport, I was asked if I preferred a window or an aisle seat. No lecture. No condescending "sorry, there's nothing I can do". No re-booking charges. In less than 5 minutes, I was all checked in for my flight to Newark.

After breezing through security, I entered Porter's piece de resistance: their Toronto waiting area. This place is everything I'd heard it to be: ample seating for everyone, comfortable leather chairs for reading, desks for those who need to get some work done, chairs with tables for eating, and power outlets everywhere (hear that, LAX?!).

I looked around in awe for a moment, before heading to the cafe which offers complementary espresso drinks, juice, water and snacks. With capucino in hand, I grabbed a seat at one of the desks and plugged my laptop in to send a few quick emails on the free wifi.

Next came the on-time boarding (you reading, ORD?), via another smiling Porter employee. In-flight, I enjoyed a complimentary Stella and meal (when was the last time you got free food on a North American flight?) and swooned.

I believe in small companies with great service. Making customers happy simply makes people happy. Porter, you made me happy. Thank you.

Open, Social for the rest of the web

2009-04-21T21:00:00-07:00

This past weekend, I had the privilege of being one of the chosen attendees for Social Web FooCamp. Needless to say, I was flattered and had an amazing time (thanks again, @daveman692 and @davemorin ) . One thing, however, became very apparent: the conversation, currently, is being dominated by the 'big players' (Google, Yahoo, Facebook and Myspace predominantly). In several discussions I found myself increasingly dropping the phrase:

... on the rest of the web

the big guys

First off, this is not a critique of the Google's and Facebook's of the internet. They are incredibly valuable to the growth of the openweb. The fact that Google, Yahoo and Myspace all three have various OpenID and OAuth initiatives in the wild and are actively pursuing additional ways to open their data is awesome (and Facebook wants to get there). It helps raise awareness and bring (slash confirm) "legitimacy".

The big guys also have resources. They can attend the conferences (and camps!) and have dedicated resources to write the standards, participate in the discussions and help shape the future.

However, they are only part of the discussion.

perspective

The issues the major providers face are different from the rest. They have a few sites with large numbers of users (hundreds of millions). Out here on the rest of the web, we have millions of websites, each with a "small" number of users (hundreds or thousands). We all understand the necessity for open data, identity, standards and protocols, but our reasoning tends to be slightly different.

The big guys recognize the benefit of exposing their data and most are providing OpenID and various levels of OAuth. How many are consuming it?

Sure, the big players want to be the primary authority for your identity and your information. In some cases, it is their business. But, rather than ranting against 'the man', I ask: have we - the rest of the web - given them a compelling reason to yet?

open source platforms for the open web ###

It's one thing for a major site (with hundreds of millions of users) to act like a silo, but on the rest of the web it amounts to isolation.

Those of us working on open source web platforms have an enormous potential for influence here. Implementing the various open standards "from scratch", while possible, is not realistic or even necessary. Increasingly, individuals have Wordpress blogs or perhaps their company, organization or club has a Drupal site. Web developers are increasingly turning to these platforms, or development frameworks such as Rails and Django. These platforms all have a real opportunity to bake in implementations of these open standards. The DiSo project offers a central place for co-ordination around these efforts.

We have data - gobs of it. We also, collectively, have the users and, in most cases, have more authoritative information about them (we know ourselves, our employees and our members).

We - the rest of the web - need to join the conversation: attend the events, participate in the mailing lists, and build the code to power the open, social web.

On Passion

2009-03-23T21:00:00-07:00

Things tend to happen for a reason, right? That is certainly how last night went. I spent the afternoon at CSI and noticed several local friends all a-twitter as they showed up for the stay fresh event happening downstairs from me.

The main presentation of the night was Peter Flaschner (aka @flashlight) talking about Passion. So, I decided to crash the party.

Passion is something very much on my mind lately: specifically finding, cultivating and making space in my life for it. I am the kind of person who is cursed (or blessed) by having a really hard time doing things without passion. Lately, I've seen a dip in my personal productivity (and happiness) - not unrelated.

In his presentation (check it out), Peter talked about research from Robert J. Vallerand on the topic. Specifically, the nature of harmonious passion, and why it's so important. When we do things autonomously (i.e. not for social acceptance, etc) purely for the challenge or pleasure of it, we can achieve happiness. Happiness for not only ourselves, but those around us. Harmonious passion needs no further motivation, and the rewards are plentiful.

Tim O'Reilly has been spreading a new mantra (as he does so well): work on stuff that matters. Less catchy, but the very important first principle that Tim outlines is: work on stuff that matters to you.

Fear, self doubt, other external pressures and responsibilities, however, can make the pursuit of harmonious passion so tricky.

Both Tim and Peter bring the relevance of passion and "stuff that matters" directly to the present: the environment, society and (of course) "these economic times". We can not only make our own lives better, but affect those around us and even the world. Seems like a no-brainer, no? To borrow a tag line from Chris Messina:

This can all be made better. Ready? Begin.

I am hereby actively renewing dedication to my harmonious passions. Are you?

SXSW '09: Meet Me in Austin

2009-03-12T21:00:00-07:00

In a few short hours, I'll be on a plane to Austin, TX for another edition of SXSW Interactive. I'm looking forward to connecting with a bunch of folks that I don't otherwise get to see often. Here's a list of things I'm hoping to catch (in addition to the on-schedule panels):

Activity Streams meetup - looking forward to diving into more DiSo :-)
XMPP/Jabber Meetup - I still believe that XMPP is one of the most important protocols moving forward on the 'net. Looking forward to syncing back up with this community.
OMB Meetup - I'm excited to help bring OpenMicroBlogging to Drupal via the Knight Initiative.

I'll also definitely be at the party that Lullabot is co-sponsoring : 32bit.

If you're in Austin for the next few days - ping me on twitter or identi.ca.

Off to finish packing :-)

Why I Hate Drupal

2009-03-08T21:00:00-07:00

I'm back home from a truly spectacular DrupalCon DC and have been reflecting this morning on some of the feedback from my talk: Why I Hate Drupal.

See the slides and watch the video

I first got the idea for this talk several months ago watching the DjangoCon 2008 keynote Why I Hate Django by Cal Henderson. I had several ideas for things to address, but aside from the session description I intentionally said very little about my talk publicly. This, of course, lead to some interesting speculation and negative feedback. All part of the plan.

As it turned out, I was not lynched and nothing rotten was thrown.

What I was not expecting (and what the video doesn't capture), though, was all of the interesting discussion that followed. I was overwhelmed by the positive response and the number of people who agreed with several of the points I tried to make:

Drupal is not a product. To grow into a "movement", we should focus on becoming a better platform, adopt some better practices around development, be a better framework, and create more space for the creation of "products" (install profiles, etc) on top.

What do you think? How to we "fix" this project?