I'll vouch for Tree. We've been friends since 2001 and we worked together for a couple years. Your skepticism is understandable; Tree may be a bit of a free spirit who doesn't use github as much as he should, but he is also honest.
Incidentally, when gmail was first released back in 2004(?), Tree dug in and reverse engineered a basic version of it in a couple of weeks. That was before libraries like Prototype were available. His Javascript skills are formidable.
I'm from NYC; this past Saturday there was a secret Night Market. Not a Winkel and Balktick event per se, but with some of the same people involved.
A Night Market is a collection of box trucks, rented for the evening and parked together in a deserted neighborhood of the city; each truck is kitted out with some form of experience/entertainment: one gave out perogis, another served tea; one was called "Thunder Cube" and hosted big pillow fights; the most elaborate one had a functioning hot tub.
The event's location was kept secret until the last minute, and attendance was limited.
My girlfriend and I produced a truck; it was called the "Peek-a-Boo Lounge" and was simply a place for people to sit and socialize. We used lumber, fabric, and sofa cushions to decorate the back of a 24-foot box truck, turning it into a two-level maze where people crawled around on their knees. There were 2 sets of day-glo Connect Four, a pair of naughty dice (leftover from a Valentine's Day event) and a day-glo stuffed carrot (leftover from Bugs Bunny costume).
It took the two of us a couple of days and about $600 to build (including truck rental). People seemed to enjoy it, judging from the laughter we heard in back; it was childlike. We received donations to help pay for the project.
I've found it's critical to find projects with good "bang-for-the-buck"; you want to enjoy yourself even when you're working.
These sort of "experiences" work because of the community they foster, and because they rely on imagination; much of the 'entertainment" is really just a cheap trick and that's part of the fun.
Of late, I've paid attention to how many letters I must type into "google" before it generates an auto-completed phrase I'm searching for.
I am profoundly impressed by how little typing is required. It certainly feels like communicating with an artificial intelligence.
This feels like value created on a giant scale.
My father was one of the first computer programmers: starting sometime around the late 50's, he wrote code in a language called octal, using vacuum tubes and wires. One of his first projects was to write a routine to calculate square roots.
Fifty years later, a computer knows that when I type "toc", I'm probably looking for the "Tournament of Champions Squash Tournament" presently being held in Grand Central Station. Remarkable.
The existing codebase, and the fact that I'm charging by the hour on a project who's budget is 3x initial estimates.
The site was, and still is, stuck at Rails 2.1.1. And, at the time, I was not using RVM or Bundler. Meanwhile, I was putting out fires on a daily base on a live system.
With Cucumber, I was unable to run even a simple feature against the codebase. I'd get an exception, fix it somehow, then get another. After 20 minutes of that, I started looking for other options.
And on top of that, I did not know the codebase: brand new project.
The quickest path to stable ground was Selenium IDE. Just hit the record button and start writing integration tests. I quickly gained enough confidence to change the underlying code. And I was working within a budget of only a couple thousand dollars a month.
What I've grown to love about Selenium, as opposed to Cucumber, is its complete separation from the site it's testing. An integration testing framework can take a long time to master; I'd rather 1) minimize that time, 2) learn a tool that can be applied to as wide a variety of projects as possible.
Last summer, I took over a troubled Ruby on Rails project; the code was a mess, overly complex and bug-ridden, lack of meaningful unit tests, and an unhappy client.
I needed integration tests. After trying and failing with Cucumber, I switched to Selenium IDE.
A year later, I'm very happy with Selenium. The project is turning around and I sense the client is warming up to me.
I've done Rails consulting, full-time, for 5 years; I haven't used use scaffolds since probably 2006. Instead, most of my productivity gains have come from learning to use third-party gems, better understanding the framework's ever-evolving capabilities, and Texmate snippets & commands.
However, a site such as this, where popular scaffolds could be voted up to the top of a pile might produce some worthy projects.
I can imagine myself using scaffolding when using a gem for the first time, one of the more involved gems like carrierwave, uploadify, or devise. These gems can take a while to get working - you may be targeting a different version of rails than the blog post you find, or you're deploying to heroku and need some custom tweaks - the details can slow you down and make you reconsider whether to use the gem, especially if you're billing by the hour.
If, on scaffoldhub, I could find a scaffold for something quite specific ('rails 3.1 and compass on heroku' or 'devise, haml, coffeescript, simple_form') that would be really, really helpful.
I'd quickly get something working on my dev machine, which saves me frustration and gives the first charge of coding pleasure, an important component to our work. It would enable me to more liberally experiment with new libraries and coding practices.
Perhaps, also, a rake task to generate a scaffold from a working rails app. That way, a scaffold, once working, can be extended. For example, first I install the uploadify scaffold, verify that it's working both locally and in production, then I add compass and devise. I run rake scaffoldhub:snapshot rails_3.0_uploadify_compass_devise_heroku, then scaffoldhub:publish to upload my work.
The points brought up in these slides directly reflect my experiences over the past 3 years of doing my own CSS.
If you're familiar with the CSS precedence rule, these slides might read like blog post; they did for me.
Strangely, I rarely see the precedence rule brought up in CSS documentation or tutorials. Not until I read "The Ultimate CSS Reference", by Tommy Olsson & Paul O'Brien. I highly recommend this book.
"Coding by Firebug" as it's called in the slides, probably refers to what I used to do before reading the above-mentioned book: tweak styles, wonder why they weren't taking effect, then add classes or IDs to the markup until something sticked. This is the "increasing specificity" also noted in the slides.
Once I understood the CSS rule of specificity - inline, id, class, element - I stopped polluting my markup and CSS.
Nowadays, I generate CSS with SASS partials (templates within a Ruby on Rails app), compiled together by Compass. Each partial starts with an ID at the top, with other ids, classes, or elements nested underneath. These are compiled into CSS - and I'm sure at the CSS level there is TONS of duplication - but this doesn't worry me one bit; my source code is DRY.
I suspect this is what Facebook and the other sites mentioned in the first few slides do too, so the rule duplication is probably not such a code smell as one might think.
Incidentally, when gmail was first released back in 2004(?), Tree dug in and reverse engineered a basic version of it in a couple of weeks. That was before libraries like Prototype were available. His Javascript skills are formidable.