wonko.com

Crass: A Ruby CSS Parser

Fri, 04 Oct 2013 22:23:21 GMT

Crass is a pure Ruby CSS parser that implements the 2013 draft of the CSS Syntax Level 3 specification. I created it because I needed a good Ruby CSS 3 parser and there wasn't one. Now there is!

Features

Pure Ruby, with no runtime dependencies other than Ruby 1.9.x or higher.
Extremely tolerant of broken or invalid CSS. If a browser can handle it, Crass should be able to handle it too.
Optionally includes comments in the token stream.
Optionally preserves certain CSS hacks, such as the IE "*" hack, which would otherwise be discarded according to CSS3 tokenizing rules.
Capable of serializing the parse tree back to CSS with perfect fidelity, maintaining all original whitespace, comments, and indentation.

Installing

gem install crass

More Details

Head over to the Crass project page on GitHub for more details, including documentation and examples.

Add the tools your toolbox lacks

Sat, 29 Jun 2013 04:08:48 GMT

Frameworks are foundations, not straitjackets.

To an inexperienced programmer, a framework is an invaluable security blanket. It hides the rough edges of an unfamiliar language or platform, it guides you toward pre-established and pre-packaged patterns and best practices, and it wraps complex concepts in simpler abstractions.

A good framework does the hard things and the boring things so that you can concentrate on your things.

Too often, inexperienced programmers choose a framework based on how many things it will do for them without requiring them to write code. The more code they're forced to write themselves, the less happy they are.

This is natural, because when you‘re inexperienced, you aren’t comfortable writing code. But it's also a trap.

If you don't challenge yourself, make mistakes, learn from those mistakes, make more mistakes, and learn from those mistakes, you will remain an inexperienced, unconfident programmer perpetually at the mercy of the frameworks and libraries that are available to you.

Avoiding this trap is hard. Many — perhaps even most — programmers fall into this trap early in their careers and remain there for years, if not forever. Give them the frameworks and libraries they‘ve grown accustomed to and they can connect the dots and create useful, possibly even beautiful things, but put them in front of a blank editor with nothing at their disposal but a compiler or interpreter and a flashing cursor, and they’re lost.

Not that frameworks and libraries are to be avoided. Carpenters don't forge their tools from scratch before each job. But the best carpenters know which tools to use, and when.

A good programmer, like a good carpenter, knows when she lacks the right tool for the job at hand and isn't afraid to add it to her toolbox.

Use a framework or a library if it makes you more productive, more organized, or more happy. But when the framework lacks something you need, consider adding it instead of asking for it.

Start small. Challenge yourself. Get better. Get bolder. Add to your toolbox. Before long it‘ll feel natural and easy, and you’ll feel a freedom and a confidence you never felt before.

Because now you‘re not just using, you’re crafting.

On working remotely

Sun, 24 Feb 2013 05:35:00 GMT

Yesterday, Yahoo! internally announced a new policy: no more remote workers.

[…]

Beginning in June, we’re asking all employees with work-from-home arrangements to work in Yahoo! offices. If this impacts you, your management has already been in touch with next steps. And, for the rest of us who occasionally have to stay home for the cable guy, please use your best judgment in the spirit of collaboration. Being a Yahoo isn’t just about your day-to-day job, it is about the interactions and experiences that are only possible in our offices.

[…]

— Leaked Yahoo! email published by AllThingsD

This new policy is shockingly shortsighted, and is a significant step backwards for Yahoo!.

I worked remotely for Yahoo! for over three years, and I currently work remotely for SmugMug. During my time at Yahoo!, many of my most brilliant, passionate, and productive coworkers also worked remotely. Some of them are still there, and they’ll be affected by this policy.

The shocking thing about this policy is not that Yahoo!’s management thinks employees will be more productive, communicative, or creative if they work together in an office. In many cases, this is true. What’s shocking is that they seem to think this will be true in all cases.

It won’t, and I’d like to explain why.

Some people can’t work remotely

First, let’s acknowledge the obvious: not all jobs can be done remotely, and not all people are good remote workers.

My experience working remotely has been as an engineer. At times my job has involved close collaboration with many people — sometimes as a team lead — and at other times my role has been as a self-directed individual contributor. The latter is much easier to do remotely, while the former required a great deal of attention and care both on my part and on the part of my coworkers.

In general, I would not recommend trying to lead a team or manage a highly collaborative project as a remote worker. It’s possible, but it’s hard, not just for you but for the team.

Working remotely as an individual contributor has its own set of challenges, and still requires significant discipline, self direction, and communication.

I’ve known brilliant engineers who were terrible and unreliable remote workers because they were undisciplined or didn’t communicate effectively when not in an office setting. It’s virtually impossible to know whether someone will be a good remote worker until you try them.

Some people, when left to their own devices, lack the discipline to stay on task. Absent supervision and the physical presence of coworkers, they relax — consciously or unconsciously — and get less done.

They may justify it to themselves (“I got a lot done yesterday! I deserve a day off.”), or they may encounter an obstacle and use their remoteness as an excuse to procrastinate (“Crap, Sara’s the only one who knows how this code works and she’s not online right now…”), or they may simply be lazy.

I suspect this is one of the reasons behind Yahoo!’s policy shift. It’s notoriously difficult to fire someone at Yahoo!, and for that matter at many large companies. If you hire a remote worker and it later turns out they’re not cutting it, the best you can hope for is to require them to work from the office or try to get them transferred somewhere else in the company so they’ll be someone else’s problem.

Remote workers are more of a risk than non-remote workers, and you’ve got to be willing to let them go if things don’t work out.

Some people are much more effective remotely

Some people, when left to their own devices, become unstoppable forces of productivity.

I’m one of those people. Dav Glass is one of those people. So are Luke Smith, Eric Ferraiuolo, and others I’ve had the pleasure of working with over the years. The four of us all worked remotely for Yahoo! (Dav and Eric still do), and would occasionally take trips to the office.

We all found it virtually impossible to get anything done during our time on site. The difference in productivity was staggering, to the point where I ended up doing my best to finish as much work as possible before a trip so I wouldn’t fall behind while spending a week at the office dealing with constant interruptions and distractions.

Not everyone is like this. Some people thrive on face to face interactions and random hallway chats, and can handle frequent interruptions. The four of us, and many other remote workers like us, thrive on long stretches of quiet time alone, with limited interruptions.

But, most importantly, we have the discipline to stay on task, get our work done, and communicate frequently and effectively with our coworkers even though they aren’t physically present.

It’s about people, not locations

People are different. Jobs are different. Remote doesn’t work for everyone, but the office doesn’t work for everyone either. Some companies understand this and some don’t.

There was a time when Yahoo! seemed to understand this. They didn’t let just anyone work remotely, but they didn’t prohibit everyone from working remotely either. They understood that on a case by case basis, some people, in some jobs, could be excellent remote workers.

Telling effective and responsible remote workers that they can no longer work remotely — not because they’re bad at it, but because some other people might be bad at it — will only make those people less effective at their jobs.

Or it’ll make them leave and find better jobs at companies that see them as people with unique strengths and weaknesses rather than as homogeneous cogs in a corporate machine.

rawgithub.com

Tue, 29 Jan 2013 18:16:00 GMT

GitHub has always exposed raw source files in public repos via the raw.github.com domain, but — presumably for security reasons — they serve most files with a text/plain content type. This prevents all browsers from rendering HTML, and prevents some browsers from executing JavaScript and CSS.

I‘ve always thought this was unfortunate. Being able to point directly to raw files in a GitHub repo can be useful for testing and for quick demos. I especially want it when I’m writing jsPerf tests and want to compare the performance of code in different branches.

So I threw together rawgithub.com.

It's essentially a proxy for raw.github.com that serves things with the correct content type based on the file extension. Just replace raw.github.com in any GitHub URL with rawgithub.com and you can render HTML, execute JavaScript, and apply CSS right from your GitHub repos.

Have fun with it, but don't use it for anything important! It's slow and it might break occasionally.

Oh, and the source is on GitHub, naturally.

How to run Continuum (SubSpace) on a Mac

Sat, 12 Jan 2013 07:00:00 GMT

Continuum (also known by its original name, SubSpace) is a ridiculously fun massively multiplayer online space shooter that I‘ve played off and on since its public beta in 1996. The original game wasn’t commercially successful, but in the years since it was abandoned, community servers have sprung up and the game client has been rewritten and released as freeware.

For an online game that‘s been around for over 16 years, it’s withstood the test of time well, and is just as fun as it ever was. I recently had a hankering to play it again. Only problem: Continuum is a Windows game, and I use OS X these days.

In the past I‘ve run Continuum in a VirtualBox VM, but that’s a pain and it‘s not as fast as I’d like. This time I decided to see if I could get it running in Wine, which would make it easier to play, and faster as well.

It turns out a fellow calling himself spiffyguy on the SubSpace forums had already gotten this working!

Using WineSkin, spiffyguy bundled Continuum and the necessary Wine runtime and config into a standalone OS X app. Here's how to get it running.

Download Continuum.app. I‘ve hosted the file on my server so you don’t need to dig through the SubSpace forums to find it.
Extract the zip file, copy Continuum.app to your Applications folder, and run it.
If you're running Mountain Lion, you may be prompted to install XQuartz as described here. Install it, then run Continuum.app again.

That's it! You should now have a working Continuum client on your Mac. I've been playing happily for the last few days with no problems. It runs smooth as silk on my mid-2011 MacBook Air.

If this is your first time playing Continuum, this quick start guide should help get you going.

And if you'd like a few pointers on how to rack up kills in Trench Wars, the most popular Continuum game type, you might enjoy this Succinct Guide to Trench Wars Badassery I wrote back in 2004.

Pie Trip Down Under

Tue, 25 Dec 2012 21:53:00 GMT

A few years ago my dear friend Loren, who you may remember from such films as The Pie Trip, Pie Trip II: Pie Harder, and Pie Trip 2.5, met a wonderful Australian girl named Caitlin. She was so wonderful that Loren moved to Australia and, earlier this year, they were married.

Pie Trip II was an epic cross-country road trip to reach a wedding in Wisconsin. What better way to top it than with an epic international journey to reach a wedding in Australia? This trip had sequel written all over it.

The result is Pie Trip Down Under, starring Kyle Kingsbury, Tyler Schuett, Andy Howe, Felicity Shoulders, Loren Bruns, and my creepifying disembodied voice. I hope you enjoy it.

The Video

Behind the Scenes

Technology has advanced somewhat since 2004, and so have production values. This was both a blessing and a curse, in that it enabled us to shoot so much footage with so many different cameras in so many different time zones that it took me months (admittedly, lazy months, but still months) just to wade through it all and even longer to make something interesting out of it. And yet, in keeping with Pie Trip tradition, we managed not to get any usable footage of anyone actually eating a pie (although I assure you that many, many delicious meat pies were et).

It's amazing to think that on Pie Trip II we had a single camera—a bulky, clunky thing that recorded crappy SD video onto actual magnetic tape, which then had to be captured to a hard drive in real time. Tape, hard drive space, and actual time were serious limiting factors in the making of that video.

On this trip we had more HD cameras than we knew what to do with (everyone literally had one in their pocket), shot hundreds and hundreds of gigabytes of footage, and never gave a single thought to storage space. We live in the future.

The majority of the video was shot on a Canon XA10. This was my first major project with this camera, and in hindsight there are a lot of things I would now do differently. For one, I shot at 24fps, which turned out to be a bad idea because the XA10 has major autofocus lag at that framerate. I now shoot at 60i instead, which produces much better results and still allows me the freedom to adjust the framerate in editing.

Certain scenic shots and many shots in the animal montage were shot on a Canon EOS Rebel T3i, which was also new for this trip. This turned out to be pretty good for static shots, but I was disappointed by the obvious compression artifacts and noise in the T3i's videos at wider focal lengths. In spite of the much better lens flexibility and control over depth of field available on the T3i, footage from the XA10 often ended up looking better simply because it suffered from fewer compression artifacts.

The opening motorcycle scene and the Sky Tower jump POV footage at the end of the video were shot with a GoPro HD Hero. Kyle actually shot hours and hours of motorcycle and ATV footage with the Hero, much of which is gorgeous, but sadly I wasn't able to fit it into the narrative of the video.

And of course, several scenes were shot on a humble iPhone 4S (or rather, on one of several humble iPhone 4Ses), which shoots passable HD footage and has the distinct benefit of being easy to carry and quick to use, especially in airports and other places where larger cameras are less convenient to carry or just harder to get to at a moment‘s notice. The iPhone was also easy to smuggle into a footie match in Melbourne where cameras were forbidden, although I didn’t end up using that footage.

The video was edited in Final Cut Pro X, which I absolutely love and have been using happily since it was released. It was mastered in 1080p (a massive jump in quality compared to the grainy SD of the previous Pie Trip videos). I did quite a bit of audio sweetening and color correction for this project, all of which was painless and intuitive. It's clear why many professional editors are upset over the changes in FCPX, but I apparently fall precisely in the prosumer sweet spot that Apple was aiming for with their rewrite.

YUI from the inside

Tue, 11 Dec 2012 20:01:00 GMT

Remember when I complained about YUI‘s opaque governance model and lack of external committers? They’ve fixed it!

These changes have been a long time coming and most of them were already in the works when I wrote that post, but I want to thank the YUI team for listening to me and to others in the community and making things better.

New contributor model

At YUIConf last month, Dav Glass announced YUI's new contributor model in his keynote. He also announced the first two non-Yahoo! committers in YUI's history: me and fellow SmugMugger Luke Smith.

The contributor model is based heavily on the Meritocratic Governance Model and outlines the distinct roles (users, contributors, committers, and reviewers) within the project, as well as their rights and responsibilities. It also defines a decision-making process based on lazy consensus, which is designed to prevent roadblocks.

But perhaps the most important thing Dav announced—and certainly the most surprising—is that most of the YUI team are committers, not reviewers. This means that even though they're Yahoo! employees paid to work on YUI, they have exactly the same rights and access as external committers, and any significant changes they want to make must be approved by a reviewer. It also means that their votes carry no more weight than the votes of external committers.

This is a bold move designed to ensure that the YUI project is truly in the hands of the community and can't be too heavily influenced by Yahoo!. While there‘s currently only one reviewer—Dav—I’m told the team hopes to add non-Yahoo! reviewers in the future. This fills me with joy.

More transparency

In addition to posting more development details on YUI's GitHub wiki, the team at Yahoo! has opened up their weekly meetings to external contributors and users via Google+ Hangouts On Air.

Every Thursday at 2pm Pacific Time, YUI users can join the hangout (or just watch it live on YouTube) and discuss project decisions, pull requests, and more with members of the YUI team at Yahoo!. This is the same weekly meeting I attended while I was on the team, and the same discussions take place, only now they‘re open to the world and recorded for folks who can’t catch the live hangout.

The weekly hangout isn't the only forum for discussion, though. Ad hoc hangouts occur frequently and are announced on IRC, Twitter, and the YUI Blog. Pull request activity has increased, and the new contributor mailing list is spinning up.

Eric Ferraiuolo held a great community town hall at YUIConf in which he laid out his vision of how the YUI project can embrace its community and be more open.

Gallery 2.0

YUIConf also served as the backdrop to Dav's introduction of a vastly improved process and tools for contributing and maintaining YUI Gallery modules. Everything I complained about was addressed, and because he‘s Dav, he also added a significant helping of awesomeness that I hadn’t anticipated.

The Future

I‘m excited about YUI’s future. Yahoo! has shown a willingness to listen to criticism and address the project's problems. The community asked for more transparancy and more control, and Yahoo! gave it to us. Now it's up to us to make YUI what we want it to be.

Like any long-lived project, there are parts of YUI that are new and awesome, and there are parts that are old and crufty. Those old and crufty parts have often been frustrating to YUI‘s users, because it hasn’t always been clear how we can improve them.

In my YUIConf talk, I advocated not using certain parts of YUI and thinking carefully before using others. I‘m eager to tackle YUI’s “bad parts” and improve them, especially now that I feel like I really do have the power to influence the course of the project despite no longer working for Yahoo!.

As I said during Eric's town hall at YUIConf, “the YUI team” used to mean "the Yahoo! employees who work on YUI". Now, that's no longer the case. There are still Yahoo! employees who work on YUI, but referring to them as the YUI team feels wrong, since that “team” now includes anyone who contributes a pull request or takes part in a hangout or offers a suggestion on the mailing list.

It sounds corny, but we‘re all the YUI team now, and that’s exactly how it should be.

Video: When Not to Use YUI

Fri, 30 Nov 2012 00:00:00 GMT

The video of my YUIConf 2012 talk, When Not to Use YUI, is now available.

The slides were apparently captured with some kind of crufty VGA capture hardware that made them look muddy and dark, so you may want to follow along with the slide deck if you care about that sort of thing.

Respawn

Thu, 29 Nov 2012 00:00:00 GMT

I finally got around to rewriting my ancient Ruby blog engine in Node. You're looking at it. Say hello to Lectroid.

It‘s not that I’ve stopped liking Ruby or anything like that. But the old blog was a crufty and complex beast built on an old and defunct Ruby web framework and backed by an actual honest to god database (remember when blogs used databases?) and bogged down by features like comments (remember when blogs had comments?).

I dreaded writing blog posts because it meant typing them into that old complex beast I had created and no longer had any desire to maintain, and that meant seeing all the things about it that I hated, and that meant wanting to change them, and that led to depression because, seriously, who the fuck wants to maintain a goddamn blog engine? I sure don't.

But I want even less to use someone else's goddamn blog engine, so here we are.

The only thing special about Lectroid is that I don‘t yet hate it, and I’ve tried to build it in such a way that I'll hopefully be able to completely ignore it for years and years without it breaking.

It was also designed to allow me to host my blog on Heroku, which I‘m now doing, as part of a gradual effort to stop maintaining my own server. We’ll see how that goes.

Oh, and naturally I've taken the opportunity to redesign everything. There are these things called smartphones now, and also tablets, and these things have tiny little screens. This blog looks less shitty on them now.

Also I‘ve increased the font size to, like, a million, because I’m getting old and my eyes don't work anymore.

When Not to Use YUI

Fri, 02 Nov 2012 23:39:40 GMT

YUIConf 2012 is coming up in Santa Clara on November 14th and 15th. I usually avoid public speaking like the plague, but this time there’s something I really want to talk about: When Not to Use YUI.

I’ll provide code samples and real-world anecdotes to illustrate how to decide when to use YUI, when to use vanilla JavaScript, when to consider other libraries, and what the tradeoffs are in terms of performance and maintainability. Advice will range from simple rules of thumb to more nuanced discussion of complex architectural decisions, with examples drawn from my time working on YUI at Yahoo! and using YUI at SmugMug.

Come see the fireworks in the main room at 9AM on Thursday, November 15th!

Update, 2012-11-15: Here are the slides from my talk. This was a talk in which the slides served mainly as background to me saying stuff, so keep an eye out for the video as well, which I’ll post as soon as it’s available.

Update, 2012-11-30: The video of my talk is now available. The slides in the video were apparently captured with some kind of crufty VGA capture hardware that made them look muddy and dark, so you may want to follow along with the slide deck if you care about that sort of thing.