wonko.com

I’ve been working from home full time for about five months now. At times it’s been relaxing, other times it’s been stressful; sometimes convenient, sometimes less so. Here are some things I like and some I don’t.

The Good

• No commute. This is huge. My stress level dropped through the floor when I stopped having to deal with 45 minutes or more of California drivers twice a day. The extra time at the beginning and end of my workday can now be used for other things, like sleeping in or cooking dinner. I also save on gas by never having to drive anywhere.
• More time in the “zone”. Without anyone dropping by my cubicle to chat or distracting me by chatting with other coworkers nearby, I find it much easier to concentrate. Email and IM are my biggest distractions now, but they’re easier to deal with than a chatty coworker. This really adds up; I’m a lot more productive working from home than I ever was in the office.
• I eat better. I’ve lost weight over the last few months just by cutting the Yahoo! cafeteria out of my diet and eating fewer lazy microwave dinners.
• More freedom. If I want to take a break in the middle of the day to exercise, cook a meal, play with the cat, or just relax, it’s much easier than when I’m at the office. I definitely don’t take advantage of this as often as I should, but at least I know I can if I need to.

The Bad

• Harder to connect with coworkers. I knew most of my coworkers pretty well before I started working remotely, but it’s hard to establish a rapport with newer team members who joined after I moved. One project manager even asked me who I was when I started to explain something in a meeting during one of my trips to the office. She had never seen me before, so to her I was some random guy who just showed up and started acting like he knew stuff.
• Close collaboration is harder. IM and IRC are okay for loose collaboration, such as when several developers are working on different parts of an application or are acting as individual contributors to various projects. But for close collaboration in which multiple developers need to work on or review the same piece of code, or when a cross-functional team needs to collaborate on hashing out a design change or a feature spec, the inability to be in the same room is frustrating.
• Meetings suck more. I attend roughly the same number of meetings now as I did before, only now I do so by phone, using Adobe Connect for screen sharing when necessary. In addition to all the usual reasons why meetings suck, remote meetings add crappy sound quality and an inability to see or hear the reactions of the people on the other end of the line when you’re speaking.

The Blurry Line Between Work and Play

I write code for a living. I also write code as a hobby. This means I often spend all day sitting at a computer writing code; the first part of the day for work, the second part for fun. It’s easy to let the work part of my day extend into what should be the fun part of my day, so I have to set certain boundaries. I’ve evolved a few life hacks that help.

First, I have two laptops: one is my work laptop, one is my personal laptop. I only use the work laptop for work, and I only use the personal laptop for non-work. When I’m done with work for the day, I turn off my work laptop and put it away to avoid the temptation to check my work email or something silly like that, which would likely result in me getting sucked back into work when I should be relaxing.

Second, when I’m working, I work in my home office with the door closed. When I’m not working but am still doing computery things, I either open the door to my office or go sit on the couch with my personal laptop. The open/closed status of my office door helps change the feel of the room from a place of business to a part of my house, and when even that’s not enough, relaxing on the couch usually does the trick. I’m pretty sure the cat has picked up on this too; she rarely bothers me when I’m working, but she seems to know she’s more likely to get attention when I’m not working.

Finally, I don’t work on weekends or holidays, period. No matter what. Even if I’m bored out of my skull and would rather be working. I’ve been tempted, but so far I’ve always managed to resist. I know that as soon as I start letting work intrude on my days off, I’ll launch myself down a slippery slope.

All things considered, I do prefer working remotely, and I’ve found that flying to California every six weeks to spend five days working in the office helps mitigate the drawbacks.

Unbeknownst to me, Bill Scott captured this brief screencast of a really old Search Assist bucket test I implemented, complete with ugly Yahoo!-only internal messaging. I had forgotten how rough the design was at that early stage. It’s so much more refined now.

How many things can you spot in the video that are different from the current iteration of Yahoo! Search?

Sanitize 1.0.5 fixes a bug introduced in version 1.0.3 that prevented non-whitelisted protocols from being cleaned when relative URLs were allowed. Upgrading is strongly recommended.

The DEFAULT and RESTRICTED configs in previous versions of Sanitize are not vulnerable to this bug. The BASIC and RELAXED configs, as well as any custom config that allows relative URLs, are vulnerable in versions 1.0.3 and 1.0.4.

To install or upgrade Sanitize via RubyGems, run:

gem install sanitize

Thanks to Dev Purkayastha for reporting this issue and submitting additional test cases.

There’s a lovely new Screenshot Tour of Thoth, the awesome Ruby blog engine behind this site, over on Thoth’s GitHub wiki. If you’ve been wondering what the non-public parts of Thoth looked like but have been too lazy to install it and see for yourself, now’s your chance to find out.

I released the first version of Thoth almost a year ago, but I haven’t done a very good job of promoting it. I’m not really the marketing type, I guess.

Sanitize 1.0.4 fixes a bug that made it possible to sneak a non-whitelisted element through Sanitize by repeating it several times in a row. This issue affects all configurations in all versions of Sanitize prior to 1.0.4, so upgrading is strongly recommended.

To install or upgrade Sanitize via RubyGems, run:

gem install sanitize

Thanks to Cristobal for finding and reporting this issue. I’d like to remind everyone that you can always test the latest version of Sanitize right from your browser at sanitize.pieisgood.org. If you manage to sneak something naughty through the filter like Cristobal did, please email me and let me know.

I’ve released version 1.0.3 of Sanitize, my whitelist-based Ruby HTML sanitizer. This version fixes a bug whereby incomplete Unicode or hex entities could be used to prevent non-whitelisted URL protocols from being cleaned.

While this is a non-issue in most cases since the majority of browsers will not decode incomplete entities, IE6 and at least some versions of Opera do decode them, which means that users of those browsers may be vulnerable to malicious script injection via a version of Sanitize prior to 1.0.3.

The DEFAULT and RESTRICTED configurations in previous versions of Sanitize are not vulnerable. The BASIC and RELAXED configs, as well as any custom configuration that allows an attribute containing a URL protocol, are vulnerable.

To install or upgrade Sanitize via RubyGems, run:

gem install sanitize

Goddammit. I was hoping to avoid having to post navel-gazing chain meme crap like this by not befriending other bloggers, but I guess I slipped up somewhere because I got tagged. Now there’s nothing left to do but grit my teeth, power through it, and then tag a bunch of other poor bastards in retribution.

Things you (probably) didn’t know about me

1. I was named “Most likely to be the next Bill Gates” in my high school yearbook. Which could indicate either that people thought I was a huge dork, or that I would get crazy rich. I suspect it was the latter (thankfully), since, on Silly Awards Day at the end of my senior year, my homeroom teacher gave me the “Student whose Porsche I will most likely be washing in five years” award.
2. Yearbook notwithstanding, my money management skills sucked so much after I moved out on my own that I occasionally went weeks without being able to buy food despite having a very nice salary. Eating cold spam with soy sauce because it’s the last food in the house and it’s a week to the next paycheck taught me valuable lessons about managing my spending. Being laid off when the first tech bubble burst taught me even more valuable lessons. Now I’m much smarter about what I do with my money. I still spend it on silly things, but only silly things I can afford.
3. I was nearly run over by a dump truck. After saying “Oh shit” and then spending several seconds thinking, “Hey, I was right all along! My last words really did turn out to be ‘oh shit’!”, I realized I could avoid being run over by taking a few steps back. Which I did.
4. As a wee lad, I was once a clothes model in a Japanese magazine. I’m pretty sure Mom still has copies of the magazine somewhere, which means the scans will eventually end up on Flickr or Facebook. At least I declined to model underwear, unlike my friend Dan.
5. I was an extra in the Benicio Del Toro/Tommy Lee Jones flop The Hunted. I was working as a web developer for the movie’s extras casting director at the time, and he insisted that I spend a day as an extra so I’d understand the business. I was in two scenes: a wide shot of Benicio Del Toro’s standin riding a stolen bicycle across the grass in Portland’s Waterfront Park, and a close tracking shot in which Benicio himself shoves past me and some other park-goers as he runs from Tommy Lee Jones. The close shot didn’t make it into the movie, and in the wide shot I’m a blueish dot in the distance. By the way, if anyone ever asks you if you’d like to be an extra in a movie, kick them in the crotch and run away.
6. My upper lip twitches involuntarily if I drop something I’m fiddling with, like a pencil. No idea why. It also happens if I see someone else do this. Even on TV. Even when I know it’s coming.
7. Once I was eating in a diner and some dude dropped a spoon so I flipped out and killed the whole town. Oh wait, no, that wasn’t me. That was a ninja.

Who wants to know about me

Sara Golemon, my coworker and (when I’m actually in California) cube neighbor at Yahoo!.

Tag, you’re it

• Felicity Shoulders
• Loren Bruns
• Steve “Mookie” Kong
• Luke Smith
• Chris Chan
• Sam Sanchez
• Stoyan Stefanov

The rules of the game

• Link your original tagger(s), and list these rules on your blog.
• Share seven facts about yourself in the post — some random, some weird.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

Now that Ruby 1.9.1 is out, a lot of Ruby developers are going to want to run it alongside a 1.8.x build to test their apps. Here’s how to compile and install Ruby 1.9.1 alongside an existing Ruby installation on Mac OS X Leopard without disturbing that installation or any gems.

Note: You’ll need to have Xcode installed, since it provides the development tools necessary for the compilation step. If you don’t already have Xcode, you can install it from your Mac OS X installation DVD or download it from Apple for free.

First, download and extract the release:

curl ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.9.1-p0.tar.bz2 -o ruby-1.9.1-p0.tar.bz2
tar xjf ruby-1.9.1-p0.tar.bz2

Next, compile Ruby, specifying a suffix for the binaries. This will create binaries named ruby19, irb19, gem19, etc., which will coexist peacefully with the stable ruby, irb, and gem binaries:

cd ruby-1.9.1-p0/
autoconf
./configure --program-suffix=19 --enable-shared --with-readline-dir=/usr/local
make && sudo make install

That’s all there is to it.

Update: Updated to resolve potential readline-related errors.

Update 2: The stable release of 1.9.1 is now out, so I’ve updated the instructions accordingly.

In November I wrote about how Chase Auto Finance lost the title to my car and was unable to send it to the Oregon DMV so I could register the car after moving here from California. As a result of their incompetence, I’m technically breaking the law by residing in Oregon and owning a car that’s still registered in another state.

Today I got two letters from Chase. The first one, dated December 18th, says their records indicate they sent the title to someone (either me or the DMV, they’re not sure who) and goes on to stress, with some urgency, that it is apparently my responsibility to tell them where they sent said title.

The second letter, dated December 19th, says that the title was sent to the DMV and makes no reference to the first letter.

Merry Christmas, Internets! My gift to you this year is Sanitize, a whitelist-based HTML sanitizer written in Ruby. Given a list of acceptable elements and attributes, Sanitize will remove all unacceptable HTML from a string.

Using a simple configuration syntax, you can tell Sanitize to allow certain elements, certain attributes within those elements, and even certain URL protocols within attributes that contain URLs. Any HTML elements or attributes that you don’t explicitly allow will be removed.

Because it’s based on Nokogiri, a full-fledged HTML parser, rather than a bunch of fragile regular expressions, Sanitize has no trouble dealing with malformed or maliciously-formed HTML. When in doubt, Sanitize always errs on the side of caution.

Using Sanitize is easy. First, install it:

gem install sanitize

Then call it like so:

require 'rubygems'
require 'sanitize'

html = '<b><a href="http://foo.com/">foo</a></b><img src="http://foo.com/bar.jpg" />'

Sanitize.clean(html) # => 'foo'

By default, Sanitize removes all HTML. You can use one of the built-in configs to tell Sanitize to allow certain attributes and elements:

Sanitize.clean(html, Sanitize::Config::RESTRICTED)
# => '<b>foo</b>'

Sanitize.clean(html, Sanitize::Config::BASIC)
# => '<b><a href="http://foo.com/" rel="nofollow">foo</a></b>'

Sanitize.clean(html, Sanitize::Config::RELAXED)
# => '<b><a href="http://foo.com/">foo</a></b><img src="http://foo.com/bar.jpg" />'

Or, if you’d like more control over what’s allowed, you can provide your own custom configuration:

Sanitize.clean(html, :elements => ['a', 'span'],
    :attributes => {'a' => ['href', 'title'], 'span' => ['class']},
    :protocols => {'a' => {'href' => ['http', 'https', 'mailto']}})

For more details, see the Sanitize Documentation.