Posts Tagged ‘frameworks’

The Point of the Rails Outreach for Women Workshops

Posted on: by mejarc 1 Comment

The past week has seen some discussion on the mailing list for a local Ruby Meetup about this weekend’s Rails Outreach for Women workshop. One message from the workshop organizer, requesting a wireless hotspot accessible to Windows users, prompted a strange but revealing departure from the subject when people responded. Those of us lurking on the list didn’t find out who provided the hotspot, but we did find out what other subscribers think is the point of this workshop.

The point of the Rails Outreach for Women workshops

…is not, despite apparently common belief otherwise:

  • to give participants incredibly detailed information about the Ruby programming language
  • to give participants deep instruction in computer science topics
  • to convince participants of the superiority of open source software
  • to shame users for their reliance on GUI clients
  • to berate the people Sarah Mei wryly terms “operating system minorities” for using something the rest of us find inconvenient.

The point of the Rails for Women workshop is to make a cultural exchange.

It’s like going to a country where you don’t speak the language. You prepare by learning basic phrases which will help you ask directions to the train station, order food from a restaurant menu, and be polite in that country’s etiquette. You don’t start with the pluperfect tense, historical study of that language’s divergence into regional dialects, or intensive scrutiny of the country’s avant-garde poets. Your goal is to enjoy your trip to that country, and, if you do, you might return and gain more facility in its language.

The stated goal of the Rails for Women workshop to increase gender diversity in the Ruby community by helping women learn Rails. By the end of the workshop, however, what’s happened is a lot more positive and enduring than fifty or sixty people inspecting http://localhost:3000 on their laptops.

image © okhiroyuki

Instead, there’s an exciting, contagious mood of self-confidence in the participants and volunteers. People might not remember how to generate a scaffold the next day, but they will remember that they did it once before–so it can’t be that hard, can it?

Anybody who believes the tech industry is egalitarian should spend time working in it as a non-programmer. Only a few moments on the job as an admin, HR person, marketing person, or designer will quickly reveal how the people in these roles are consigned to the lowest castes in tech companies, while programmers are encouraged to swagger like feudal lords.

Many of the participants in the Rails for Women workshops identify themselves as this sort of tech-but-not-techie, in that they’ve been around the artifacts of programming culture, but not able to make sense of them. Once in the workshop, they handle things like–the command line! Version control! Databases! Maybe at the end of the day they don’t have every concept mastered, but they do have a greater self-regard that is moving to observe. They might go on to volunteer at the next workshop, or even attend a Ruby Meetup. They feel entitled to learn more.

The cultural exchange isn’t one way. As the participants work through the workshop curriculum, they discover where the Rails Way isn’t clear. Install Night is especially revealing: every volunteer helping gets exposed to at least one error message he or she’s never seen before, at least one bewildering installation problem for which no amount of Googling can provide solutions, and at least one nonsensical incompatibility nobody bothered documenting.

The Rails community gains from these frustrations. It gains when a workshop participant points out the inadequacy of a tutorial, README, or wiki page. It gains when installing an upgrade or gem becomes simple. Consider how friendly Rails could be for a programming novice: there’s so little futzing and configuration to do (once past the install hurdle) before you get to see something display in the browser. Why not make the Rails community as accessible?

The San Francisco Rails Outreach for Women Workshops are organized through the SF Ruby Meetup.

The jQuery Juggernaut

Posted on: by mejarc 1 Comment

Last night I felt very lucky to have a seat in the biggest meeting room Microsoft offers in its San Francisco office. The occasion was a remarkably well-attended (over 150 participants) event of five different Bay Area Meetup groups. Our common ground was a discussion of jQuery.


Image © the jQuery Project

New Wave JavaScript


Why jQuery has so many infatuated practitioners:

  1. It’s designed to help front-end developers do the things we really need to do. As Yehuda Katz remarked, “We write software for humans.” By re-purposing CSS syntax for JavaScript tasks, John Resig returned browser-side scripting to front-end developers. The framework, and most jQuery documentation, are refreshingly oriented to using jQuery for those humdrum DOM manipulations we’re assigned.

    Five minutes with the average JavaScript tutorial will give you, maybe, some prose to recite about objects, data types, and the prototype method. Fifteen minutes–perhaps some acquaintance with the built-in Math object, rarely used in your daily work as a front-end dev. In contrast, five minutes’ reading of an introductory jQuery tutorial will get you to the point of answering that deathless question: how can I apply an onclick highlight color to every other table row?

  2. It’s (mostly) backwards compatible. Since you’re using the hosted version of jQuery from either Google or Microsoft (you are, aren’t you?), you might be anxious that an upgrade to the latest jQuery release will break your carefully wrought scripts of yore. Yet the framework is designed so that new functionality won’t meddle too much with older. Your zesty accordion menus from 2007 will thrill your site visitors for years to come.
  3. It will always be open source. The jQuery project is a member of the Software Freedom Conservancy. It cannot be purchased by any corporation and then sequestered into a proprietary format. You will never have to pay to use .mouseleave() or .fadeIn().
  4. It has an enthusiastic community of plug-in developers. Like as not, you could develop an entire Web project without writing a single line of your own JavaScript. In addition to the plugins hosted on jQuery.com, there are countless scripts and gists on GitHub, and who knows how many others stored on people’s blogs.

    It’s not that I advocate avoiding writing your own scripts, but if you’re solving a tediously common problem and you have the typical ridiculous project deadline, you can pull in someone else’s lightbox, autocomplete, or carousel, and move on to the more interesting work you have to do.

  5. Our feedback matters. An amusing test of this happened a couple of years ago, when jQuery.com unveiled a new branding effort. Gone was the tagline “Write less, do more,” replaced by “Be a Javascript Rock Star.” Manga-style graphics supplanted gradients and color blocks.

    Reactions tended to the furious, and the jQuery team quickly removed the elements generating so many complaints.

Why aren’t you using jQuery?

12+ People I Owe

Posted on: by mejarc 2 Comments

So here’s a pretty satisfying thought experiment/daydream: if uncountable buckets of money suddenly landed in your bank account one morning, who would you invite to share the windfall? Just in case this happens to Yours Truly, I’m writing up a list of people who devised things which made my professional life easier over the years, so that I can compensate them appropriately before I retire to a villa in Tuscany.

This villa is absolutely positioned. Photo by Maney Digital

12+ People I Owe

  1. Jesse Ruderman, for the Web Dev bookmarklets
  2. Felix Ritter, for View Formatted Source. Yes, Firebug has assumed its function, but I’m nostalgic for the day this add-on removed tons of guesswork from my project.
  3. Eric Meyer, for his Reset CSS, which introduced us to a sparkling world clean of browser defaults
  4. Joe Hewitt, Rob Campbell, et al., for Firebug
  5. Mike Buckley and Lorne Markham, for Pixel Perfect
  6. Kevin Freitas, for MeasureIt
  7. Lorenzo Colitti and Philip Chee, for FlashBlock
  8. Alex Sirota, for ColorZilla
  9. James Anderson, for Leechblock
Who will receive your gratitude?

Finger Busting

Posted on: by mejarc 1 Comment

The other night my husband and I indulged in some old-fashioned diversion by picking through our collection of 78 r.p.m. records, playing the selections on the 1947 Delco phonograph. He surprised me with a record I’d forgotten we had: Jelly Roll Morton, late in his career, playing Willie “The Lion” Smith’s “Finger Buster;” B-side, “Creepy Feeling.”

Creepy Feeling. Digitized by Michael Knowles

We listened to “Creepy Feeling” first. Here was all of Morton’s legendary talent in one side–the ragtime and jazz piano styles he excelled in and defined. We had great expectations for “Finger Buster.”

Finger Buster. Digitized by Michael Knowles

This piece was also rendered with impressive virtuosity, but ultimately left us cold. The point of it seemed to be for the pianist to cram as many notes into every moment as possible, a challenge Morton met and bested. But getting all those notes in meant he discarded tone, mood, contrast–almost everything that makes a piece of music memorable. “Finger Buster” had no hook.

I’m reminded of “Finger Buster” when I look at some of the ways people write JavaScript. I see cryptic, single-character variable names, rigid adherence to object literal syntax, disdain for whitespace and for comments. Some people seem to treat their applications as the Web equivalent to the Apollo moonshot: everything must be rigorously minimized, milliseconds shaved off like millimeters, as if, say, the rendering of the lightbox on the regional sales division’s intranet login has profound, mission-critical implications.

Still others want to impress with their scripts’ obscuring structure. They don’t want you to understand it readily; they don’t want to provide the f*cking manual for you to read. They want to dazzle you with their finger busters.

Okay, time for a test.

Quick: hum the riff for the Kingsmen’s “Louie Louie.” Now do the same for any of Steve Howe’s solos on Tales from Topographic Oceans. Maybe a few of us can do the latter, and some would even prefer it. I confess to a bone-deep dislike for prog rock, and admit bias for “Louie Louie.” I’m not alone–which recording do you think has great influence?


The Kingsmen, “Louie Louie”.


Steve Howe in 1971 BBC documentary.

A trick question. Both do. Punk arose in the 1970s from both emulation of the do-it-yourself, technically simple example of 1960s garage bands like the Kingsmen, and contempt for the pretentious, technically complex example of prog groups like Yes. The original punks knew finger busting really doesn’t signify great music. If the music can’t make its point quickly, if you need lots of post-production and exotic instruments and huge concert venues to create it, and if nobody can easily recall what it sounds like, then it’s failed–doesn’t matter how many notes it has.

It’s high time finger busting JavaScript met its punk counterbalance. Too many blog posts, presentations, framework docs, and lines of code seem written with complete disregard for the basics of communication, as if hoarding information makes the writer more powerful. Just as you don’t need conservatory training to make good music, you don’t need an MS in Computer Science to write good JavaScript. My stress is on “good”–is it good if nobody understands it? If nobody can reuse it, add on to it? No. Web development isn’t a cutting contest. Let’s save finger busting for novelty records.

I Still (Heart) RichInStyle

I’ve been perusing a lot of job postings, which is, I know, inefficient, if my goal is to find a job, but it’s interesting to see what employers are putting in their requirements.

More and more frequently I’m seeing a call for skill with frameworks–not just for Ruby on Rails or Prototype, but also for CSS. There are by now a few of these to choose from: the skins for the Yahoo! User Interface Library, Blueprint, Nicole Sullivan’s “Object Oriented CSS” (excellent work, but oh! for a less trendy name), and so on. All of them: good to use. But it depresses me that employers don’t want to hire someone who can develop CSS by hand.

Hand tailoring
Photo by Bradley Allen

I’ve barely used any of the frameworks; I haven’t needed to. I guess I’m like a Savile Row tailor in preferring to make my own measurements and to follow my own procedures. But I can’t really say “my own,” since I was the benefactor of other CSS developers, those who worked in the earliest days of the technique—Web 0.9?—and discovered its patterns.

One of these pioneers was Matthew Brealey, who contributed to the W3C CSS discussion list. In between posts he maintained RichInStyle, a one-man compendium of frontend development tips and tutorials; I had it bookmarked, if not always open in a separate browser window. Brealey somehow had the time to investigate the browser support for every proposal in the CSS 1 specification; generously, or self-aggrandizingly, he posted his findings.

He also devised a way of writing a stylesheet that, with few adjustments, I still use. Brealey’s “Masterclass” show signs of age (remember uppercase element names?), but outlines one of the most logical ways to write CSS I’ve seen yet.

A couple of his most enduring principles are, simply:

  1. Use the cascade. Start with the most general rules at the top (HTML elements), and only then follow with those for classes and IDs. Put the toughest cases–the most obstreperous browser hacks–at the bottom of the CSS text, processed last.This rule seems obvious, but I can’t believe how many stylesheets I see beginning with class or ID rules.
  2. Ease human usage of the stylesheet with alphabetization. Brealey wrote before we had Firebug, or even View Formatted Source. Yes, we were flying with instruments in those days; you never knew where that pesky text color was coming from, nor why your document’s h3s were in italics. But a stylesheet organized as Brealey proposed gave up its secrets more readily: the rule for h3, for instance, would be reliably beneath that for a and above that for p, and its font-style would be beneath border and above margin. Maybe the importance of this approach has diminished as far as debugging goes, but it still shows thoughtfulness, the developer’s hand.

Developed by hand, old-fashioned; an artifact, not a commodity. Sure, I’m biased in favor of hand-tailored CSS, but then I’ve seen nothing but benefits from its skilled usage. Note “skilled.” It’s thanks to Matthew Brealey and others like him that I know what that means.