Monday, February 27, 2012

Super Saiyan: Heavy Metal Remix



Based on this:



Which I first saw here:


Sunday, February 26, 2012

Peter Cooper's CoffeeScript Drum Machine

Subscriptions are now closed for Teaching The Robots To Sing, but there's still plenty of cool free shit, including this video by Peter Cooper. Inspired by the first two episodes, he developed this simple CoffeeScript drum machine.

Here's the screencast:



And here's the code:

Friday, February 24, 2012

Teaching The Robots To Sing: Episode 2 (TDD With Jasmine-Node)

Episode 2 of Teaching The Robots To Sing is a gentle introduction to command-line TDD in JavaScript. You can see it here in Flash format:



You can also download it:

episode2.m4v (for iOS, OS X, and Apple TV)

I'm going to build a class on videos like this.

The class itself consists of biweekly videos. The first video was 35 minutes, the second was just under 10; upcoming videos will fall within a similar range.

If you want to see these videos, you need to sign up for my new class, which consists of 3 months of biweekly videos, alternating with biweekly 1-hour Campfire chats. In other words, a chat, then a video, then a chat, etc. Discussions in the Campfire chats will shape the videos I make. It's like Destroy All Software with office hours (plus JavaScript, CoffeeScript, Node.js, Backbone, Socket.io, and, most of all, music). I'm going with office hours because I want to make sure people really learn what I'm teaching; I'm making the videos biweekly because I want them to be FAST AS BALLS.

FAST AS BALLS.

Speed matters, and not just for web sites. I recently talked to a pair of great engineers about screencasts. Many people love screencasts, but not everybody. Of the two hackers I was talking to, one never watches screencasts at all, because he feels they're too slow; the other one watches them, but watches them in QuickTime, and uses QuickTime's adjustable playback rate to speed up the video to twice its normal speed. Personally, I love screencasts, but I use that double playback speed trick myself sometimes.

I thought about this and decided it's about the editing, because I saw something similar while giving presentations. In 2008, I spoke in front of at least 15 conferences and user groups, maybe 20 or more. I developed a rapid-fire presentation style where I kept putting new slides on screen, because I found that if I didn't, people started looking at their laptops instead of paying attention to my talks. I wanted people to pay attention to my talks, so I made my presentations grab their attention. I got great feedback when I did this. I even got a wild standing ovation after my talk at RubyFringe in Toronto. People still email me now, in 2012, four years later, having just discovered video of that talk, to tell me they love it.

People actually love irrelevant distractions. For instance, here is an unnecessary koala.



Don't tell me that koala isn't adorable.

There were over 500 slides in my RubyFringe talk, and I spoke for approx 50 minutes. That's a very rough average of 10 slides per minute, or a new slide every six seconds. In the average screencast, the image on screen cuts much more slowly than that. But people today are used to fast cuts, so I took the time to apply this style to my videos. I counted the cuts, zooms, and transitions in the first six minutes of the above video, the second episode in Teaching The Robots To Sing. I counted about 94 cuts in those six minutes. The style continues like that through the whole video. So 94 cuts in six minutes (360 seconds) means the shot changes every four seconds, on average.

My theory is TV and movies have made a certain pace feel natural to us, with the obvious corollary that anything slower feels unnatural. I also feel zooming in on key pieces of code makes code demonstrations easier to understand, and it's not just me:





So the videos come out biweekly because I want to take the extra time to make them fast, exciting, and incredibly easy to watch -- which means extra time editing on my end to save time on your end with an exceptionally watchable video -- and in addition to biweekly videos, there's also biweekly Campfire chats. They're an hour long max (less, if you bail) and they alternate; you get a video week and a Campfire week. No matter how many people sign up, there will never be more than 11 people in any one Campfire chat -- each chat gets 10 regular participants, max, including myself, plus an 11th empty slot in case somebody misses their own usual chat schedule and wants to sit in on another class's chat. This is because I want to make sure everybody participates. Small class sizes make that easier.

I want people to have a great time with this class. If you're a dude, I want you to think about how much you value, cherish, and protect your own testicles, because it's my goal to make this class something people love so much, it's like you grew a third testicle. Or think of it like a puppy with the power to cure cancer. I want this class to be so exciting you run around in circles whenever you think about it.



In this class, you'll learn how to write a drum machine. You'll learn how to write clean, well-tested CoffeeScript, along with enough Backbone to implement a single-page web app which generates original sheet music. You'll also learn Socket.io and CSS3 animation.

Going back to the idea of participation, you can lurk if you want, of course, but the whole goal is to get you to the point where you can come up with your own cool hacks.

Site licenses are available for companies, and if at any time you are dissatisfied, tell me, and I'll give you all your money back. Any reason is valid.

Signup opens tomorrow, and closes Sunday night.

Thursday, February 23, 2012

Making Music With JavaScript Is Easy: Free 35-Minute Video Shows You How

I recently figured out how to use Socket.io and Node.js to control the speed of a CSS3 animation with a synthesizer:



I also got CoffeeScript playing drums for me with very little effort:



You can do this too.

I've started a new video series called Teaching The Robots To Sing, where I use music hacking to teach new JavaScript web development technologies. The first video in my new series is free, and it's right here. In it, I show you how anyone running OS X can control Garageband with Node.js. It's NSFW, but full of awesome.

You can stream it, in Flash video format:



You can also download it:

episode1.m4v (for iOS, OS X, and Apple TV)

Upcoming episodes will teach command-line TDD in CoffeeScript, building a Backbone app which generates sheet music, and of course the hack where I use a synthesizer to set the speed of a CSS3 animation. (If you don't have a synthesizer, I found a great free MIDI controller which allows you to control the animation with your trackpad instead.)

The web site, singrobots.com, is not live yet, but the second video is already finished. It's shorter and funnier than this one, and it shows you how to get started with excellent TDD in JavaScript.

I'll post that here on my blog for free as well, on Friday afternoon. But after that, if you find that you love this video series, you'll need to sign up to receive the other episodes, and you'll have to sign up sometime this coming weekend, because I'm closing signups late Sunday evening.

Rails Went Off The Rails: Why I'm Rebuilding Archaeopteryx In CoffeeScript

Ever been to one of those parties where your work friends and your college friends don't talk?

I posted a great video on my Tumblr which I would never post on my Facebook:



It's a guitarist shredding along to "Bangarang" by Skrillex. I wouldn't post it to Facebook because on Facebook I've got high school friends who I know from Spotify are listening to Skrillex, as well as rave scene friends from when I lived in San Francisco. I don't actually know their opinions on Skrillex for a fact, but if I had to guess I'd assume a certain disdain, because some of my old rave scene friends are hard techno purists, as well as huge music hipsters, who distrust popular music, grow bored very quickly, and knew about dubstep years before Skrillex. In fact, I heard some extremely early proto-dubstep records in London in 2000, and I probably wasn't the only one of this particular group of friends to do so -- which means at least a few of us knew about dubstep a decade before Skrillex.

My old rave scene music hipster friends would probably hate that video for the same reason my musically naive high school friends would love it: Skrillex built huge, phenomenal success on a style which is essentially a join table pulling columns from both rock music and rave music. Posting something like that on Facebook could mire me in a situation where I'm trying to get two utterly disparate groups of friends to get along with each other, despite having utterly opposite opinions, and despite the fact that I haven't seen any of them in years. Total waste of time.

It reminds me of an old Why the Lucky Stiff quote:

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

I bring this up because I saw an otherwise great presentation at LA RubyConf which featured a staggering number of catty remarks about almost every other language but Ruby. The only exception I remember is Smalltalk, which got the kind of reverence you sometimes see when the Ruby community talks about Smalltalk. I used to be pretty excited about Smalltalk too, but I distrust exclusionary reverence. I also remember buying an old Mac Mini from an LA Rubyist who collects so much weird old computer stuff he's like a tech historian. One item in his collection: a staid, dull, lifeless manual for IBM Smalltalk, one of the most bland corporate documents I've ever seen in my life, and a strong counterpoint to the Ruby community's small but vocal "Smalltalk was the best thing ever" cult.

A few years ago, Rails was as crazy hot shit as Skrillex is today. But in 2012, a Hacker News post asked this question:

Which one should I learn deeper, Node.JS/Express.JS or Ruby on Rails?

Many offered positions asks for Rails knowledge but looks like Node is getting a nice spot in Web development for the very near future


In other words, should I learn the dominant paradigm, which will make it easier to get a job, or the new hotness?

We all know what the opposite of new hotness is.



And indeed the Hacker News thread features this response:

Rails is over. It's a bloated meta framework that requires enormous amounts of peripheral knowledge to understand.

You should take anything you read on Hacker News with a grain of salt, if you take it at all, but what does it mean for Rails to be over? It doesn't make sense at all if you look at Rails as an application development framework, but if you look at it as a fashion trend or a party, it makes perfect sense. Rails was the height of fashion a few years ago, which made for a quite a party, but it isn't any more.

People decry the degree to which tech is a fashion-driven industry, but there's a reason for it. As Smalltalk creator Alan Kay said, "Once you have something that grows faster than education grows, you’re always going to get a pop culture."

Rails is old and busted; Node.js is the new hotness. But people hate Node.js because of "the hype." This amuses me, because the only things I know about the hype around Node.js come from people who hate Node for that hype.

I'm not surprised to hear that Node is bratty. When Rails was Node's age, it was bratty as hell. RailsConf 2007 featured incredible tech, but to me it also felt like the epicenter of the world's most powerful douchequake. I ignored Rails douchery then, as much as I could, and recommend doing the same with Node now. Here's why.

The sulky, bratty teenage Rails had three big things it made fun of the Java old folks for: design patterns, the JVM's long startup time, and overly ceremonial code which had nothing to do with the day-to-day experience of writing web apps. Today Rails has a startup time which is so long, the Rails community actually created Spork, a gem which keeps your Rails environment alive between test runs, because otherwise it's hard to use TDD with Rails. Rails tests can take so long to run that by the time a test run completes, you're liable to forget what you were doing, and, in fact, your name. The Rails community mocked design patterns relentlessly when it was Node's age, but look at how ActiveRecord::Base hijacks inherited and you'll realize that this:

class User < ActiveRecord::Base; end

really means this:

User = ActiveRecord::Base.new

kind of like this:

User = Struct.new(:username)

We use a bizarre, convoluted mechanism for attaching ClassMethods and InstanceMethods modules to ActiveRecord::Base because if we attempt to subclass it in a gem, we don't get a subclass in the purest sense. What we actually get is a new class which ActiveRecord::Base creates. ActiveRecord::Base is an ActiveRecordClassFactory in denial.

And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk.

I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user, particularly considering that the whole reason I'm a user of this particular thing is because I work in a language which was designed to optimize for programmer happiness? Of course not. It's not productive or helpful to say that, so I simply type bundle exec rake balls and scratch my balls in sullen silence.

Typing bundle exec every single time I want to scratch my balls is the epitome of the overly ceremonial code which Rails defined itself against from 2005 to 2007. The Rails community has become everything it used to make fun of. Despite that, it's also managed to utterly transform web development for the better, and not just in Ruby, but in nearly every language. When Rails was new, it sprouted clones in other languages on an almost daily basis, and now that it's matured, the outsider response has matured as well. You don't see a new Rails clone in a new non-Ruby language every Tuesday like you used to in 2006, but you do see the Rails community implementing code generators, convention over configuration, and tidy routers every time they venture into unknown territory, and CoffeeScript took obvious inspiration from both Ruby and Rails in making developer happiness a priority.

Consequently, I think listening to Node.js hype at all is foolish. It's just not worth having an opinion about. It leads to a foolish brattiness in those who believe it and an equally foolish hostility in those who harp on its flaws. Hype is hype. It's bullshit. Let it go. Node will change course to accomodate all its critics sooner or later, just like Rails did, and in the meantime there's a lot of exciting work going on. People are building very interesting things, and the browser landscape is changing so fast that by the time Node grows up a little, web development will be an entirely different world.



This was true of Rails, too, and it's what made Rails fun when Rails was a party, and what makes Rails powerful and useful today, now that it's only a tool.

However, going back to the Why the Lucky Stiff quote, it's pointless hating on Rails for not being as fashionable as it was. It's possible to see Rails as a fashion trend which has run its course, but it's actually a lot more intuitive to see it as a useful tool for building things. But there you also run into some problems. Let's take "Rails is over" out of the equation, but revisit that Hacker News comment:

Rails is... a bloated meta framework that requires enormous amounts of peripheral knowledge to understand.

The first thing this reminds me of is an inane rant which called Rails "pants on head retarded." I can't recommend this rant, because a large number of its criticisms apply only to how the official documentation instructs you to use Rails, not how serious, well-known, best-of-breed Rails developers actually use it (except of course for DHH). I think the "enormous amounts of peripheral knowledge" criticism is dead on. Chief among this vast range of peripheral knowledge: knowing the difference between what the Rails documentation says Rails developers do, and what Rails developers actually do.

For instance, I don't think anybody but DHH and maybe one or two other members of Rails core really use Rails tests the way Rails says you're supposed to. I don't think anybody but DHH and maybe one or two other members of Rails core even takes the official Rails approach to testing seriously at all. Rails unit tests aren't really unit tests, Rails integration tests aren't really integration tests, and Rails functional tests aren't really functional tests. Most people create a spec directory, install RSpec, and throw all that other bullshit away. So it's kind of a waste of time for an anti-Rails rant to go on and on and on about the clothes we politely agree to pretend our emperor is wearing.

The "old" part of "old and busted" is not really worth thinking about. "Old hotness" means "classic." But "busted" is something to address, and there's busted shit in Rails. Consider what happens if you set up your Gemfile without source :rubygems on the first line:

Your Gemfile doesn't have any sources. You can add one with a line like 'source :rubygems'

Are you fucking kidding me?

This is what Google's "Did you mean" functionality would look like if the Bundler team had implemented it:



Bundler makes dependency management much, much less painful than before, but because source :rubygems isn't the default, even though Bundler knows it should be, Bundler also fails completely at convention over configuration. I don't mean like, "that isn't perfect." I mean "grade F, you cannot graduate, you have to repeat this year." Like the way you would fail at wearing clothes if you showed up to work at the office in your underwear, and nothing but your underwear, and your underwear wasn't even clean.

Bundler isn't the only problem. With Rails 3, Rails went off the rails.



The link's ironic; it takes you to a gigantic page full of things you have to do before you can start writing your app.



Consider this discussion:



You can read the whole thing here if you want. I'm just going to give you some excerpts.





To paraphrase Jose here, Rails 1 and 2 were releases for application developers. Rails 3 was a release for plugin creators and maintenance programmers. This is cool, but building application frameworks without application developers as the primary audience was one of the things Rails made fun of Java for in 2006. Jose's a member of Rails core, and he wrote a terrific book which showcases the incredible power of Rails 3's newer, more modular APIs, but there are times when tweets speak louder than books.



Ward Cunningham is kind of a big deal.

My answer to the Hacker News guy who wanted to know if he should learn Node or Rails is the same answer he'd get from Jeremy Ashkenas: learn Node. (Actually, I can't speak for Jeremy, but I'd say learn both, but prioritize Node over Rails.) There are times when it's fun to be a partyhopper, and the music next door is better right now. It's more important to learn Node.js, CoffeeScript, and Backbone these days, because the work going on in those communities changes paradigms. The work going on in Rails is mostly just tidying up after the paradigm-changing work which used to go on in Rails -- except that Rails 3 introduced as many rough edges as it removed.

Speaking of rough edges, the browser is turning into the operating system. If you're on a new version of Chrome, you can already play with in-browser drum machines, as well as filters, compressors, and synthesizers. You'll risk crashing your browser now, but it's going to be pretty awesome pretty soon. It's also likely mobile apps are going to make web apps look pretty dated, and Node is better poised to take advantage of this than Rails is.

Also, when you're learning something, you want to have fun. Rails is still useful, but it's no longer exciting. Although there's a ton of awesome all over the place, there's also some "what the fuck were they thinking?" here and there. Fixing that shit isn't fun. If you're looking to do work you can get excited about, it's Clojure, Scala, or Node.js. Clojure and Scala both run on top of Java, which holds horrible memories for me, while Node.js involves a language I've mostly had a lot of fun with, despite its frequent idiocy. CoffeeScript is far from perfect, but it's a joy to use, because it reduces JavaScript's WAT factor down to a tolerable level of mild background noise.

Rails just isn't the future any more; it's the past.



Although I think you can get much better jobs with Node.js than you can with Rails these days, I'm much more interested in creating my own projects, and I'm having more fun with Node.js there as well. So I'm creating a series of videos which use making music to teach Node, CoffeeScript, Backbone, Socket.io, and most importantly of all, jasmine-node, a Node.js port of the Jasmine BDD library for JavaScript. With jasmine-node, you can run your specs server-side most or all of the time (depending on factors I'll explain in these videos), and the payoff is fucking awesome.

Running specs in a browser has always felt like bullshit to me. It's an incredible pleasure to run them lighting-fast on the command line instead, in a context where you can hook them up to continuous integration, or indeed anything, via Unix status codes. There's really no excuse not to write your JavaScript TDD/BDD in 2012.

Going back to the topic of JavaScript drum machines, I wrote a library in Ruby called Archaeopteryx. It's a combination MIDI interface, drum machine, and probabilistic breakbeat improviser. I've started to rewrite it in CoffeeScript. The new version is called Clyde, and the code's much cleaner.



I've also already cooked up some really fun hacks.



I chose the name Clyde partly because I got way too many questions about how to pronounce Archaeopteryx, but mostly after legendary drummer Clyde Stubblefield -- not just a funky drummer, but THE funky drummer James Brown was singing about -- who coincidentally will be SPEAKING at Madison RubyConf this year, the same conference where I last year freaked out at a panel for saying you don't have to test JavaScript. I can't even describe how excited I am for that.

To be fair, Ari Russo wrote a fantastic MIDI library in Ruby called Unimidi, which looks better than anything I ever did, but I'm sticking with JavaScript for this project. This is partly because investing my time in this language looks wiser today than investing it in Ruby (especially since I'd be repeating stuff I already did in Ruby), and partly because of bona fide technological superiority.

Clyde isn't just easier to pronounce. A lot of people complained that Archaeopteryx was hard to read. Clyde, although still very much a work in progress, is already much simpler to read. First, I had to snag a lot of low-level MIDI interface stuff for Archaeopteryx from a great book by Topher Cyll called Practical Ruby Projects. (Ben Bleything later rewrote it, creating a cleaner interface library called MIDIator.) To set up MIDI for Clyde, however, I just installed a great Node.js library and wrote some really simple code. Archaeopteryx also devotes a bunch of code to implementing an equivalent to JavaScript's setTimeout(), and aliases Ruby's lambda to L so that it can freely assign methods to objects, the same way you can pass functions around in JavaScript.

JavaScript's basically a better language for this type of project, because Archaeopteryx uses a lot of hacks to make Ruby work like JavaScript, and while JavaScript itself is hideous to read, CoffeeScript is so beautiful it sometimes even makes Ruby look clunky.



My tech reviewers have also found Clyde's techniques easy to copy in Garageband, which means anyone with a Mac will be able to get Clyde working very quickly, whereas I had a lot of people puzzled out of their minds trying to get Archaeopteryx to work on their machines. An open source project which only works for the guy who wrote it is no use at all.

Because my videos are going to be a fun way to learn about cutting-edge technologies, I'm pretty excited about them. They may in fact become the best, most exciting and engaging way to learn modern JavaScript development. I think it's important for software development training to be fun, because I want to inspire people to come up with their own hacks, because you learn most when you're paying the most attention, and because this idea is built into the language hackers use: when we explore a technology, we say we've been playing with it. I'm releasing my first video for free tomorrow afternoon, so check back here Friday to see it.

Since this blog post is to some extent an ad for these videos, and truth in advertising is important, I want to confess that I don't really have a rake task to scratch my balls. However, it still feels as if I have to type bundle exec whenever I want to scratch them, and that feels like the kind of horseshit a cursory knowledge of Unix environment variables and paths could resolve. (To rant even further about Bundler, if you type bundle && foo, you never get to foo; it appears Bundler doesn't even support status codes.)

Going back to the larger issue, Rails definitely went off the rails. Cleaner, more modular APIs are an important goal, but they're way less important than speedy development, a modern feature set -- why is Rails not staying up to date with HTML5 the way it did with Ajax? -- and, above all else, programmer happiness. The Merb integration rewrite was a giant, time-wasting threadjack with only a few small payoffs, and DHH, who wrote two whole books about why you should turn down feature requests, should have nixed the whole thing. I'm still going to keep using Rails, because it's still a terrific framework, and I still enjoy it a great deal, but I think it's absolutely fair to say that Rails 3 is a step backwards from Rails 2, and that Bundler, although very useful, is clearly not even close to finished. They say they're at version 1.0, but I don't think they're fooling anybody.


Update: Yehuda Katz from the Bundler team and Rails core sent me this helpful gist:



Update: Yehuda's apologized for the phrasing, and the point he raises is in fact completely valid. Meanwhile, I've created eight episodes of a video series on making music with CoffeeScript and Node.js. The first two are free.

Awesome VJ Tech: Turntable Projection Mapping



via create digital motion

Monday, February 20, 2012

Hacker Newspaper Now Screens Out All YC Content

A few days ago I added a regex to the code which generates Hacker Newspaper:



Unfortunately, a YC job ad made it past this filter almost instantly:



(If you're wondering why the comments page looks different: omgwtfhax.)

I felt tricked. I also felt the tactic was a little sleazy and desperate. And the whole reason I added this regex to my HN filter in the first place was to screen out a job ad for Curebit, a company which is best known for seeming a little sleazy and desperate as well.

YC job ad posts, and similar posts on Hacker News, appear with no comment link. This privilege makes an easy target. It should be possible to filter out such content based on that characteristic. However, it's much easier to simply filter out any story where the comments URL is the same as the story URL, i.e., any story which links back to Hacker News itself.



This also excludes "Ask HN" and "Tell HN" stories, along with a few random polls. Not long ago, I would have called that a side benefit, but today I'm not as stridently disdainful of the Hacker News community as I used to be. Instead, I'm going to call it a very acceptable cost for the convenience of not having to spend serious time hacking anything complicated.

However, if you've got the time, the project's on GitHub, and patches are welcome. Also, while I'm at it, I'm very interested in hacking in automated comment elitism -- basically, a way to show comment links when (and only when) comments appear from people I consider more interesting than average. It's a bit obnoxious, but I'm a busy guy, and since discussions wander, I only want to see links to discussions which have a strong likelihood of not wasting my time.

Thursday, February 16, 2012

I Wouldn't Learn Ember In 2012

If this pointless debate continues kerfuffling any further, I may go into technical detail, but for now I want to explain exactly why I think this debate should not even be happening.

First, in the IRC chat log, Ember project lead Yehuda Katz admits to trolling. Actual verbatim quote: "I saw [Backbone creator Jeremy Ashkenas] in the audience and was trolling a bit."

Second, Ember vs Backbone is like Rails vs Sinatra. If a developer can't decide between Rails or Sinatra for an upcoming project, that developer either knows nothing about Rails and Sinatra, or knows nothing about the upcoming project itself. It's apples and oranges.

Third, and more importantly, Backbone vs Ember is like Brad Pitt vs who?

So you've got two utterly dissimilar things being compared. One of them gains credibility among developers just by being compared to the other. The person who made that comparison happen benefits from it. And that same person admitted openly to trolling in a very closely related discussion.

Is this how we all got excited about Rails? Or was it the badass screencasts?

Any project which wants attention that much is going to release some badass screencasts the moment they can.

Until then, don't feed the trolls.

Wednesday, February 15, 2012

Google Is Flowers For Algernon

I sometimes think that Silicon Valley is this weird abstract hunting ground where Neo-Victorian aristocrats hunt and kill good ideas for sport, the same way their ancestors would have killed foxes.

It's really hard to explain project managers and technology executives without postulating that higher education and corporate management exist to preserve aristocracy. They certainly don't exist to increase efficiency or productivity. To be fair, this is the Marxist angle, and there's definitely room for consideration of its polar opposite, the Ayn Rand angle, but Google's current condition is pretty fucking hard to explain in a world where the only powerful forces are excellence and amphetamines.

In 2004-ish, a recruiter from Google emailed me saying "we can't hire smart people fast enough!" I remember hoping it was exaggeration, since the only logical conclusion was that they would have to either slow down or start hiring stupid people, and they didn't seem to be slowing down. Since then, every programmer has noticed the growing useless of Google's "search product" (remember when Google's "search product" was called Google?), and the company has embarrassed itself repeatedly with Google Wave, Google Buzz, and now Google+. Google+ is, admittedly, the company's most credible effort to date, but it's still not impressing everybody.



Between two or three failed Facebook clones and an operating system which supports a huge range of iPhone clones, it's tempting to think of Google as a middle-aged guy with a pathetic combover who left his wife a few years ago and spent every moment since then driving around in a Ferrari, asking younger guys what music he should listen to, and begging various 19-year-old girls just to notice him at all for longer than two seconds. The best model for Google, however, is Flowers For Algernon, a tragic sci-fi novel aimed at a teenage reading level. In the book, scientists transform the life of a mentally disabled man by injecting him with an experimental brain-boosting drug. He discovers art, poetry, literature, science, and mathematics, but the drug wears off -- and kills him in the process.

It's a tragic story, but the most tragic thing of all is that Google has decided to present a live theater version to us all over the Internet, and with a bold, innovative stroke, they have cast a web site in the starring role. That web site is Google's search product (the web site normal humans outside of Silicon Valley refer to as "Google"), and they have fucked it up so badly it's like they built a Frankenstein monster using no other parts but the ass cheeks of a hundred different cadavers. This undead buttocks homunculus once awed us with its genius, but in its present, retarded state, it is a horror to behold.

I hope for the sake of the children that somebody shoots it, burns it, and scatters the ashes.

Sunday, February 12, 2012

Mark Suster At The Future Of Television

I usually disagree with almost everything this guy says, but this presentation is dead-on.

Friday, February 10, 2012

Playing Drums With CoffeeScript In GarageBand And Reason

"I Get My News From Phil, I Don't Get It From TV"

Phil de Franco makes $100K/yr making YouTube videos.



Reddit AMA

background on TubeFilter

Thursday, February 9, 2012

Controlling A CSS3 Animation With MIDI



Explanation coming soon, in entertaining instructional video form.

Wednesday, February 8, 2012

Secrets of Superstar Programmer Productivity: Flow

I'm working on a bunch of new videos, and a new site which makes it easy to find and buy the ones I already have. I'll be posting some freebies along the way. Here's the first, one of four which I made to promote my Time Management For Alpha Geeks video, which is not currently available for sale. (Expect a reissue soon.)

Flow



original blog post, with notes

Sunday, February 5, 2012

Thursday, February 2, 2012

New Videos Brewing