Thursday, January 31, 2008

Rails: Aspect-Oriented Programming / Decorator Pattern

Rails implements the Decorator in such an unusual way that its worth asking if it is a good idea or not. In my opinion it isn't. I don't see any advantages in Rails' implementation - do you?

But I do see several disadvantages. The biggest one is that its removes an obvious extension point from Rails. Once two methods are linked together using Ruby's alias method you can't break them apart. For example, if A aliases B then you can't insert C between them. This might not seem like a big deal, but for some extensions it quite important. For example, when I wrote our REST controller implementation last year I struggled mightily to fit it into Rails aliases method calls and finally gave up and took a different approach. Its worth noting that its often possible to work around this problem since Ruby is such a flexible language. Instead of adding a new decorator, in many cases you can replace the original method to achieve what you want. Its not nearly as elegant, but it usually does the trick.

A second disadvantage is that it complicates Rails architecture. What's the difference between a decorator and a filter? Nothing. By using the Decorator pattern you could merge Rail's filter functionality with its method chaining functionality, thereby reducing its overall code base.

A third disadvantage, albeit a minor one, is that the method chains Rails creates are hidden. You can't look at a single piece of code, or configuration file, and see the method chains. The closest is action_controller.rb and action_view.rb, but I can't get a handle on a chain object at runtime and say "please print yourself on STDOUT so I can see what is happening."

Charlie Savage: Rails' Unusual Architecture

"Hello World" In DNA

Yes. Really. (Via the disturbingly keen-eyed Quinn Norton.)

A More OO Alternative To Rails? Components Built On Top Of Rails?

Too busy to blog in detail; but check out this:

And this.

Wednesday, January 30, 2008

Im In Ur Budgets, Wasting Ur Moneys (Twitter Downtime Tantrum)

The (in)famous Twitter lolcats were funny, cheap, and cool.

This is condescending - "thanks for noticing"? oh, you're so welcome - and somebody paid good money to employ an artist to draw it. The artist obviously had talent, and obviously didn't invest a whole lot of passion.

It's also very intellectually sloppy to say that "something is technically wrong" when you mean "something technical went wrong." "Something is technically wrong" implies that it isn't really wrong. But obviously, if the site is down, something really is wrong. Because the site's supposed to be up. If the site's supposed to work, and it doesn't work, that's not a mere technicality. That's actually kinda the nub and gist of the whole brouhaha.

Sometimes "upgrading" to a more professional demeanor isn't really an upgrade at all. They should have just kept the lolcats.

Who doesn't love a good lolcat?

Paul Graham (who finally delivered Arc yesterday) once gave a great speech on "What Business Can Learn From Open Source," and said that the most painful lesson business can learn from open source is that people who program in their pajamas while making fart jokes on the Internet outperform the world's top technology companies just about every single time.

The standard response to an influx of venture capital is to hire graphic designers to create inferior, tiresome, and anonymous replacements to funny, cheap, and engaging graphics. But just because everybody's doing it doesn't mean you have to do it. If I recall Twitter's history accurately, the venture capitalists came to them. If they come to you, it means you get to decide what to do with the money.

Again, going back to Paul Graham, he wrote a great essay explaining that the major goal of technology acquisitions is hiring the people who produced the technology; purchasing a company is really just a socially acceptable way of handing over a truly gigantic signing bonus. So if somebody puts money in Twitter, who says Twitter can only do Twitter? If you can make a kickass product in a very short span of time, and somebody's just given you a metric ton of legal tender, don't hand that money over to some bored graphic designer so they can buy marijuana and expensive shoes they'll have forgotten in a year. Do something interesting with it.

Don't you know the rule? The rule is, if you're bored then you're boring. Don't throw away money making your site less interesting. Make another cool product we'll also use every day.

Tuesday, January 29, 2008

Utility Belt: JRuby vi Bug

Utility Belt exposes a small bug in JRuby. The JRuby team knows about it and are working on it. It involves their Readline implementation and goes beyond the extent of my fu, but I'll be putting a simple fix in Utility Belt svn soonish.

Utility Belt won't have its next release until at least late Feb, due to general scheduling insanity in my life, but for the time being, avoid using vi or emacs from within JRuby's IRB with Utility Belt. (TextMate integration still works fine.)

Update: The simple fix is in svn; that's the good news. The bad news is it's possible the backticks thing is a limitation of Java's ability to communicate with the world outside its virtual machine. One JRuby developer commented that the ticket might be a "can't fix."

Friday, January 25, 2008

Let The System Design Itself

Designing before you build is a very bad habit.

I'm working on an aleatoric music system right now. (And I do mean right now, at 3:30am Friday morning. I am an insomnihacker occasionally.)

I'm using pretty much exactly the design I had anticipated using. However, when I first started, I created a ton of empty files around this design, the design I basically had in my head from go. I laid out the general object architecture as a first step. It was a disaster. The results were bulky, sloppy, and stupid. Then I remembered Ezra Zygmuntowicz saying twice at Ruby East that he believed all great projects start as hacks. So I stopped using my big dumb Object Architecture™ and wrote up a quick hack. Pretty soon it was working beautifully, and I had thrown away like twenty unnecessary files. It only took a tiny little shard of time after that for me to factor out the quick hack into a few classes and end up with nice, clean, well-factored files - the hallmark of good design, if good design even exists.

That's a real question, by the way. Does good design really exist?

Brian Marick told me that Ron Jeffries once said or wrote this of Kent Beck:

Beck has those rules for properly-factored code: 1) runs all the tests, 2) contains no duplication, 3) expresses every idea you want to express, 4) minimal number of classes and methods. When you work with these rules, you pay attention only to micro-design matters.

When I used to watch Beck do this, I was sure he was really doing macro design "in his head" and just not talking about it, because you can see the design taking shape, but he never seems to be doing anything directed to the design. So I started trying it. What I experience is that I am never doing anything directed to macro design or architecture: just making small changes, removing duplication, improving the expressiveness of little patches of code. Yet the overall design of the system improves. I swear I'm not doing it.

Kent Beck is usually my programmer role model. I don't know why I coded my first sketch of the music system in this backwards way. Just before building this system, I hammered out a quick proof-of-concept version of a system which allows you to program Lego Mindstorms robots in Ruby. I followed Beck's rules and never even considered what the design might look like. That system was harder to write, because it exploits language quirks to enable a DSL, but the process of writing it was much smoother - I didn't have to junk it midway through and start over.

It's possible that good design is kind of like good ethics. There's a reason we say both designs and people can have integrity. Using the language of design patterns to design a system before you build it literally undermines the design's integrity. Just as there are hypocrites in the world doing brutal violence in the name of a man who preached kindness, there are programmers building bulky, inelegant systems while thinking about good designs. But if you're thinking of one thing and doing another, you don't have integrity, and if you're thinking of one system and building another, your design doesn't have integrity.

And it literally happens like that. If you're building design-first, you're saying, "The system will do XYZ - I'll put that here." But just because you know it'll do XYZ, you don't necessarily know how or where, and deciding ahead of time imposes an arbitrary and unnecessary structure on your code. So then you have a file called XyzFile, which is supposed to do XYZ, and then you have other code elsewhere in the system which actually does XYZ, and it's in some other file, because the design you imagined will always be different from the design which emerges. It's like coding in Java. There's the structure of your actual program, and the structure that Java requires you to accomodate. That second structure is just unnecessary mental overhead, and the bigger your system gets, the more wasteful that overhead is. You'll have a structure that emerges naturally, whether you want to or not. It's as inevitable as gravity. You might as well just let the macro follow the micro, like it's supposed to, and get the good design which emerges naturally as a byproduct of that process.

It's important to realize that just because you can forecast what the likely design will be doesn't mean that starting off with that design is anything but a horrible, time-wasting mistake. They're called design patterns, not design templates. Designing to them is bad; seeing them emerge is good.

Wednesday, January 23, 2008

The Mecha Theory Of Consciousness

A very rough under ten-minute "documentary" (video of me rambling) which started when I was building some Legos and expanded over the course of several groggy breakfasts. It really is totally unfinished but just in case it entertains somebody, here it is. 20MB MP4 because I couldn't be bothered with YouTube (sorry).

Speaking 3/2008: MountainWest RubyConf, Emerging Technologies Philadelphia

I'm speaking at MountainWest RubyConf in late March.

Pat Eyler's posted a mini-interview with me about my talk and about which other talks I'm most interested to see. (One addendum: Jim Weirich's keynote wasn't posted, and now that it is, it looks to be a highlight.)

I'll also be speaking at Emerging Technologies For The Enterprise, in Philadelphia, just days before.

Hope to see you there!

Tuesday, January 22, 2008

The Most Important Benefit Of TDD/BDD: Scope Reduction

An excellent post on scientific research validating the TDD/BDD methodology notes one of the methodology's benefits:

Since the scope of a single test is limited, when the test fails, rework is easier.

In my opinion, this more than anything else is the benefit of TDD. How do you eat an elephant? One bite at a time. TDD sizes problems down to the smallest possible bite. It may be a journey of a thousand miles, but if every single step is buoyant, light, and easy, you'll be there before you know it.

Extremely Informal Dynamic Music Demo

So I haven't been blogging as much as I usually do, at least not about Ruby or programming. Here's what I've been up to. It's a useful but very informal screencast, purely in case you happen to be curious. It relates to my experiments generating music via Ruby.

Unfortunately the actual audio sounds like crap, because I set the music-generating code to a higher process priority than the screencast video capture code, which was pretty unwise of me. But it could be interesting. The first interesting part is that I created a way overkill Object Architecture™ and had to scuttle it in favor of a quick hack, based on Ezra Zygmuntowicz' saying that everything great starts as a hack.

The other interesting part is that my first implementation took arrays of notes arranged in the order to play and played them, whereas my new hack implementation takes an array of notes arranged in no order at all, but each one has a programmatic rule about when it likes to be played, and the new hack version plays the notes by testing against the programmatic rule.

However, it's just a quick progress report, some people might dig it, some might not, so I just threw it together real quick.

115MB QuickTime .mov file.

Monday, January 21, 2008

Ruby: Strategy Pattern / Dispatch Tables

Something I'm working on stores Procs in objects a lot. I started out using a dispatch table and then realized I'd have a much cleaner system if I encapsulated the dispatch table within an object. Then I realized the object would need two additional dispatch tables, and created a Struct to store them in, and gave the object the Struct. (The additional dispatch tables were very closely related in theme and the variable names were just infinitely cleaner that way.)

At this point the fact that I'm using dispatch tables is a lot less obvious. Further refactorings will probably emphasize this effect. There's a question here: when does a set of dispatch tables encapsulated for convenience within objects become a Strategy pattern?

The Rails community is notoriously disrespectful of its competitors, and because of this there's a great deal of people who scorn design patterns as a relic of Java's pre-Ruby Jurassic Age. The alternative point of view is that design patterns are some of the valuable discoveries of the object-oriented avenue of investigation. My interest in dispatch tables comes from the Lisp world via Perl, but the fact that it ends up in design patterns territory seems to validate the whole concept of design patterns to some degree.

Inspired Obama Rant By Jennifer Lynn Larkin

He's still all "think about the children!" I don't want to vote for anyone who is out there talking to evangelical churches saying that the solution to many of the world's troubles is to build strong families. I just read his stance on "strong families and fatherhood" on his website and it even cites irrelevant statistics. It's rhetoric designed to sucker in people who stand for "family values" and not only do I not stand for "family values," I dislike political maneuvering like that. Clinton is even worse in that regard.

"Family values" are anti-homosexual, anti-single parenting, and pro-domestic violence. There is no data that suggests that the crime rate or the fall of the economy or anything bad at all is caused by single-parent child rearing or single sex paired child rearing but there IS data to suggest that people who stay in abusive relationships rear violent and criminal children. It's a religious issue and it makes me very mad that people use this "rational" posturing to promote a religious issue for which the rational posturing is either not truly rational or does not support the religious stance. His plan for "strengthening fathering and families" includes domestic violence prevention, increasing child support, and ensuring that child support payments don't go to government collection fees. None of those "strengthen fatherhood," so why is it called "strengthening fatherhood?" Because it's a ploy to make the plan fall under "family values" and thus get support from religious conservatives and religious liberals who think that divorce and homosexuality are evil. Because I see the ploys, I hate the stance.

I don't like candidates who use their religion as a political platform and I don't like candidates to try to hide their religious political platform in some areas by claiming that it is not a religious platform. I further don't like religious platforms designed to mimic more popular religious platforms in order to garner support.

Besides, these people are senators, people who know that the people of the US mandated that the US get out of the Iraq war and know that the Democratic control of Congress was intended by the people to end the war in Iraq, yet almost all of them continue to vote for the war and if they make a gesture vote against it, they don't follow up when the president vetoes it. They have already proven that they have no interest in following the will of their constituents in any meaningful way. I just don't see how I can trust someone to follow the will of the people in running the nation when they can't bear to do it in their current job. They need to grow some fucking balls.

Kucinich may look like an elf but he has balls the size of his head. That's why he gets the totally hot wife.

The Other Reason The Media Blocks Ron Paul

There's a candidate on either side getting downplayed systematically by the American media - Edwards and Paul. Each is consistently represented across the mainstream media as winning less than he wins, having less supporters than he has, etc. In each case, the main reason the media blocks him, of course, is because people with money don't want to broadcast his views, and in the United States, people with money control the systems for broadcasting political views. (Even YouTube; the reason YouTube makes available a much wider variety of political views than most American systems for making political views available is because YouTube makes Google money.) It sucks that the media does this, but it's awesome that libertarians and progressives are finally becoming part of the mainstream political debate in the US.

But as much as that cheers me up, and as much as I want to support his struggle against The Man, with Ron Paul at least there's an additional reason the media shuts him down: a history of controversial, unpleasant remarks which appear to indicate bigotry pretty conclusively. The people who own and operate the media are isolated from those kind of sentiments, whereas many other people in the US have to deal with them regularly. Nobody in the media class wants to be reminded about the fact that there are still people all over the place supporting those views also. It's not just censorship; it's also distaste.

I'm not an expert on Paul, but if you're thinking about his campaign, that's one thing to keep in mind.

Update: Stolen from Ara T. Howard:

Friday, January 18, 2008

Thursday, January 17, 2008

I Shook Obama's Hand Yesterday

Porn Bot Vs. Turing Test: Porn 1, Turing 0

I've blogged before about scammers and pranksters beating the Turing Test. Turns out that technically I was wrong:

In a true Turing Test, the humans aren't blindly conversing with the assumption that their conversant is human -- they're actively seeking to verify the presence of a human.

I got that from a blog post about a Russian porn bot which beats the informal Turing Test:

Russian crooks have unleashed an artificial intelligence, called CyberLover, that poses as a would-be paramour in sex chat rooms, enticing randy gentlemen to reveal personal information that can then be put to criminal use. Amazingly, the slutbot appears to be successful in convincing targets that it's a real person.

(via Ara Howard)

Just to brag a little, I predicted this somewhere between two to five years ago.

The difference between a bot which successfully pretends to be human and a bot which successfully pretends to be human even though people are actively trying to catch it is a big enough difference that we can still call the Turing Test unbeaten, but that difference is only a few years away from becoming a matter of splitting hairs.

Tuesday, January 15, 2008

Fanboy Beta Hardware

CrunchGear's sharp-toothed and cantankerous review of the Apple thin laptop - whatever it was called - totally misses the point:

the Air is an extremely impressive piece of technology. The miniaturization, the optimization of space, the blatant disregard for current standards — it’s everything a revolutionary machine should be. Except it isn’t one. It’s a flight of Apple vanity that is completely impractical for anyone who needs to do more than the most basic functions with their computer.

A whole page of commentary follows, explaining why the Air is impractical. Like somewhere out there on the Web, there was some puzzled idiot who actually believed up until this minute that $3000 for a 1.8GHz processor and 60GB of hard drive space could somehow be practical. Now that idiot has been set straight. Wonderful.

My latest toy is equally impractical - it's shiny and cool but the software support is so minimal that as a consumer appliance it hardly even works - and the only way I'll be able to use it at all is if I code a driver for it.

So guess what I'm going to do? Duh. I'm going to code a driver for it.

The market for this device comes from the salivating that its big brother caused as a design prototype.

Both the Optimus Mini 3 and the new Apple wafertop are fanboy beta hardware. The iPhone came very, very close to being the same thing, and the iPod Touch obviously is the same thing. Fanboy beta hardware is for the people who get excited about something even though they know it isn't useful yet. Think of the Sony Aibo.

Yes, I need to spend $3000 on a robot dog, because otherwise. Because. Otherwise. Oh. Wait. There is no good reason to buy a Sony Aibo.

But there is a market for one.

Consider advances in manufacturing which make short runs more feasible financially. If you've got fanboys worldwide peeing their pants in excitement over something you haven't even finished yet, you don't wait until it's perfect. You take their money the minute they're willing to spend it. Because manufacturers are businesses with fans. Have you ever noticed how, with famous writers, their early books are perfectly spelled, tightly structured, and grammatically precise, while their later works apparently skipped the editing and proofreading phases completely? It's because the publishers already knew the books would sell.

Just because Apple's selling the whatever-it's-called doesn't mean it made very many of them. The world is not overflowing with people willing to spend that kind of money on what is essentially not a computer but a trailer for one - a preview of coming product attractions. But the world does have those people, and Steve Jobs is happy to take their money. It's as green as anyone else's. And you have to remember his philosophy - "real artists ship." All Steve Jobs is is Warhol plus electricity and math skills. A proof-of-concept which people are willing to spend serious cash to play with is high art in Jobs' book.

The CrunchGear thinbook attack/review misses the point completely. CrunchGear, of course, is a spinoff of TechCrunch, and like TechCrunch is basically run by and for monkeys who make their money by "managing" programmers. So they see something for sale, they assume its goal is to take over the world. Its goal is much simpler: cash, bragging rights, and the beauty of the thing itself. They're not trying to give you something practical. This is what Apple will have on every lap and desk a few years from now, and if you're wiggy enough in the brainpan to want to buy it before it becomes genuinely useful, Apple will not nobly decline to line their pockets with your cash.

The thing is, that's cool. Fanboy beta hardware exists because it makes fanboys happy. In 2008, hardware is a type of entertainment, like movies and music, and just like with movies and music, there are fanboys who love everything their favorite creators do, and there are vibrant underground scenes full of creative people who prefer to do it themselves. That's fine. That paired dynamic, the fanboys and the underground, is the engine that drives every other group of creators in our society, and it's the engine that drives hardware too.

OS X: Turn Spotlight Off

I personally never use Spotlight, but its indexing process mds still runs on my box. (It's possible that I turned it off completely using a different hack before I upgraded to Leopard, and the Leopard upgrade restored it.) Occasionally mds will use a lot of CPU. Here's a simple way to fix that.

Now Spotlight will not index anything. The process still runs, but obviously it doesn't have any reason to take up a lot of CPU any more.

Update: To remove Spotlight's menu bar icon, do this:

sudo chmod 0 /System/Library/CoreServices/
killall Spotlight

(May only work on Leopard.)

Update: I have a couple new machines. One's an older MacBook I bought cheap off Craig's List as a backup box in case anything else breaks. I think it's still got some files in there from Tiger, although I could be wrong. So when mds was churning away despite my chmoding the binary into oblivion, I also did this and this.

Monday, January 14, 2008


What do I want from Apple, both tomorrow at MacWorld and then over the coming months? Easy. I want to see fewer cool features...

A Simple Solution For Fradulent Voting Machines

Here's how you - yes, you, whoever is reading this - can fix the fradulent voting machines problem in America forever.

Hack the machines. Make Porky Pig the next President of the United States by an unanimous vote.

Do that, and everything else which is necessary to fix the problem forever will happen for you.

"δος μοι πα στω και ταν γαν κινάσω." - Άρχιμήδης

Control Is A Business Disadvantage

A lot of businesses on the Web seek control - for instance, the otherwise awesome Instructables, which normally gives you a sequence of steps in a how-to article. If you want to see every step at the same time, you get an idiotic and insulting pop-up:

As far as I can tell the only reason to see every step at the same time is to eliminate the tiresome busywork of clicking "next" a dozen times - in other words, to save time. If I take an action to save time, and you tell me the only way I can do that is by starting a whole separate task of user-registration busywork, so I can have a login I'll never use again in my life, and another password I won't remember - or more accurately, for most users, another place where the same password I use for my bank account will be stored, possibly in thief-friendly plaintext format - then I'm not going to be happy.

I'm not going to do it, either. Instead I'll give your Web site the finger and post it a rant about it a few days later when I'm feeling particularly grumpy, and I'll put the words "jackass bullshit" in a filename along with the name of your Web site, which means that if users google "instructables jackass bullshit" in Google Images a few days or hours or minutes after the blog post, they'll see exactly what I'm talking about.

You can't buy that kind of publicity.

ThinkGeek lost some business from me this way in October. I order a few hacker toys from ThinkGeek once every two or three years - usually at the holidays, usually for my dad, who, despite his years, has a real appreciation for USB-powered dart guns. I order from ThinkGeek frequently enough to have an order history, complete with redeemable geek points. In fact I recently got a free USB plasma ball with my geek points. That's cool. But I also order from ThinkGeek infrequently enough that practically every time I order anything from these guys, I have to have them e-mail my password to whatever my e-mail address was two or three years ago, and then see if I can still log in to that to retrieve my old ThinkGeek password. It's time-wasting bullshit, and in October it cost ThinkGeek money. It may have cost them money other times that I don't know about.

It's awesome. Buy it from ThinkGeek, if you have the patience.

Meanwhile, a site called Topix found that "registration keeps out good posters and attracts trolls." Removing the registration requirement on their forums improved the signal-to-noise ratio and dramatically increased the volume of posts. And a programmer who built a zero-registration free dating site to teach himself ASP.NET made $10 million with it in 2007. People like to skip registration, because it's an insulting waste of time. It's like when Radio Shack asks you your phone number before they'll sell you AA batteries.

Here you go, sir. Now all I need is a sample of your DNA. Please give me one of the hairs on your balls.

What's funny about this is that technology companies are making the same mistake they have laughed at entertainment companies for making every time entertainment tries to "embrace" new technology - overemphasizing control at the expense of profitability.

Overemphasizing control at the expense of profitability is insane for companies to do, yet companies are doing it all the time. For whatever reason, the culture of business makes certain assumptions about your relationship to your customers which just aren't true. You don't need control. It's bad for your business. Attempts at obtaining it fail, costing you money in the process. When you give up control, you make more money.

Always favor respecting privacy over asserting control. It's not just good usability. It's not just the right thing to do. It's not just a good business decision. It's all of the above.

Update: Control is a business disadvantage because one size does not fit all. Saying "they can have any color they want, as long as it's black" is perfectly okay as long as they can always go out and buy a can of paint and a brush.

Get Ready For Urban Wildfire

1967 in 2015. No matter who wins 2008.

Count on it.

Sunday, January 13, 2008

Flight 404 Speaking At UCLA

The Processing wizard will be at UCLA on January 24th.

Seaside Screencasts Back Online

After months of delay, I finally quit procrastinating and uploaded my Seaside screencasts to S3. In my defense, I thought they were on an external hard drive in storage in Pecos, New Mexico, but in my non-defense, they were sitting on my laptop all along.

Here they are:

Seaside / Rails screencast
Seaside: Framework And IDE screencast

Saturday, January 12, 2008

Program Lego Mindstorms NXT Robots In Ruby (Rubotz v0.0.1)

Announcing Rubotz, a Ruby code generator for Lego Mindstorms NXT.

First, download and install NXC.

Then gem install rubotz.

Then fill out the config YAML (it only takes a second).

Next write your program in Ruby, and use the Rubotz.compile command to generate an executable .rxe file in your NXC bin directory.

Finally, use a third-party library like NXTBrowser to transfer your executable to your Mindstorms NXT brain.

Boom: robot. Programmed in Ruby.

However please note: Rubotz v0.0.1 is a proof-of-concept developer release only. It currently only supports one sensor, synchronized motor functions, and single-threaded NXC. The full complement of available sensors, motor functionality, and threads should become available in future releases, and if you want to help that happen, go for it.

RubyGems: Gem::Specification#autorequire= Deprecated; Use Require Instead

Packaging up gemspecs which up until now had been trouble-free produced two warnings for me:

WARNING: no rubyforge_project specified
WARNING: deprecated autorequire specified

The no rubyforge_project one doesn't check to see if you've already declared a rubyforge value for homepage:

s.homepage = ""
s.rubyforge_project = "rubotz"

But if you don't do both, you get either a no homepage specified or a no rubyforge project specified warning.

The deprecated autorequire warning is a little weirder. It's pretty obvious that you can just use require instead; what's less obvious is why you have autorequire instead. My gemspec was initially generated by Hoe, so like with any generated code, there's a certain air of mystery involved. You have to wonder if require is enough, because if it was enough, why did autorequire exist in the first place?

Fortunately, Google can find you an excellent explanation from Jim Weirich:

The autorequire feature is a holdover from the days when regular requires didn't work in rubygems. It avoided the need to do a require_gem *and* a regular require. Since the regular require is all that is needed today, autorequire is a holdover from the past.

Long story short, just use require.

Friday, January 11, 2008

Basic Training

I’ve gotten a fair amount of feedback from the Ruby community that my book is an ‘advanced’ Ruby book because I talk about things like open classes, method_missing, DSLs and metaprogramming. I have to say that I think that we Ruby people need to stop describing these techniques as ‘advanced’; all we are doing is scaring people. We need to shout out to the world our little secret: we only use those scary-sounding ‘advanced’ techniques because they make our lives easier. We use them because we are a bunch of lazy sods (as all good programmers are) and they let us write programs that work, with less effort.

Take metaprogramming for example: It’s not easy to write that first metaprogramming program. Metaprogramming is one of those techniques that you need to work at when you first try it. Well, my son is studying algebra, and he occasionally has trouble wrapping his head around ideas like simultaneous equations or open intervals, but that doesn’t make algebra advanced mathematics. Fundamentally the concept of metaprogramming is really quite simple: in order to solve the problem at hand, your program modifies itself at runtime. Anyone who can write code at the keyboard can learn to write programs that write code at runtime. It’s just not that complex. Writing guidance software for a Mars probe, now that’s advanced programming. Metaprogramming, not so much.

This is important because there are a lot of programmers out there who are massively frustrated with trying to solve problems with the traditional programming languages and are looking for an alternative. I think we Ruby folks have a professional responsibility to shout out, “Hey, for many of your problems there is an easier way.” Now that easier way involves some programming techniques that seem strange in the beginning, but once you get used to them they stop being so strange and all you are left with is easier.

-Russ Olsen

One of the great accomplishments of Ruby is that its object and class model bring about a wonderful unity and simplicity. Even things that might seem like they should be hard or obscure are actually very transparent, once you have the hang of how the model works.

Unfortunately, there’s a trend toward drawing an increasingly sharp line between regular programming and “metaprogramming” in Ruby discussions, where metaprogramming is understood to mean… well, I’m not sure what it’s understood to mean, the way it’s getting used in connection with Ruby, and that’s the problem.

There’s no natural separation between programming and metaprogramming in Ruby, and no reason to make life harder by breaking them apart. The thrust of Ruby’s design is to dissolve complexities, so that even things that appear to be “wizardly” or full of “dark magic” actually make perfect sense in terms of a relative small number of underlying language principles.

I’m not saying it’s all a snap to learn. But I do consider it counterproductive to posit some kind of special barrier or fortification surrounding a particular set of Ruby programming techniques. Learning Ruby isn’t like scaling a mountain. It’s more like exploring a plain, with interesting features and a distant but very attractive horizon. One thing leads to another, but not in a way that requires you to fight gravity to get there.

-David Black

You might be inclined to think that metaprogramming is another hacker word and was first overheard in private phone calls between fax machines. Honest to God, I am here to tell you that it is stranger than that. Metaprogramming began with taking drugs in the company of dolphins.

In the sixties, a prolific scientist named John C. Lilly began experimenting with his own senses, to uncover the workings of his body. I can relate to this. I do this frequently when I am standing in the middle of a road holding a pie or when I am hiding inside a cathedral. I pause to examine my self. This has proven to be nigh impossible. I have filled three ruled pages with algebraic notation, none of which has explained anything. The pie, incidentally, has been very easy to express mathematically.

But the scientist Lilly went about his experiments otherwise. He ingested LSD in the company of dolphins. Often in a dark, woeful isolation tank full of warm salt water. Pretty bleak. But it was science! (Lest you think him criminal: until 1966, LSD was supplied by Sandoz Laboratories to any interested scientists, free of charge.)

Drugs, dolphins and deprivation. Which led to Lilly’s foray into things meta. He wrote books on mental programming, comparing humans and computers. You may choose to ingest any substance you want during this next quote - most likely you’re reaching for the grain of salt - but I assure you that there’s no Grateful Dead show on the lawn and no ravers in the basement.

When one learns to learn, one is making models, using symbols, analogizing, making metaphors, in short, inventing and using language, mathematics, art, politics, business, etc. At the critical brain (cortex) size, languages and its consequences appear. To avoid the necessity of repeating learning to learn, symbols, metaphors, models each time, I symbolize the underlying idea in these operations as metaprogramming.

-John C. Lilly, Programming and Metaprogramming in the Human Biocomputer, New York, 1972.

To that end, you could say programming itself is a meta-language. All code speaks the language of action, of a plan which hasn’t been played yet, but shortly will. Stage directions for the players inside your machine. I’ve waxed sentimental on this before.

But now we’re advancing our study, venturing into metaprogramming, but don’t sweat it, it’s still just the Ruby you’ve seen already.

-why the lucky stiff

Telling people that metaprogramming isn't that hard is a public service, but it's kind of like telling people to read SICP: anyone who will listen when you say it was probably going to figure it out for themselves sooner or later anyway. SICP has 82 5-star reviews on Amazon, 53 1-star reviews, and virtually nothing in between. Of course two of the five-star reviews come from Paul Graham and Peter Norvig.

Some of the reviewers complain that SICP doesn't teach the basics of OO design, and so on. In a sense they are right. The book doesn't directly tell you how to design and write an object-oriented program using the subset of object-oriented principles that show up in the syntax of Java or C++. Rather, the book tells you what those principles are, how they came to be selected as worthwhile, how they can be implemented from the ground up, and how a different combination of principles might be more appropriate for a particular problem. This approach requires you to understand the range of possibilities, and to think about trade-offs as you go through the design process.

Programming is a craft that is subject to frequent failure: many projects are started and abandoned because the designers do not have the flexibility, experience and understanding to come up with a suitable design and implementation. SICP gives you an approach that will succeed, but it is an approach based on principles and wisdom, not on a checklist. If you don't understand the principles, or if you are the kind of person who wants to be given a cookbook of what to do rather than to think creatively, or if you only want to work on problems that are pretty much like the problem you worked on last time, then this approach will not work for you. There are other approaches that will be more reproducible for a limited range of simple problems, but there is no better way than SICP to learn how to address the truly hard problems.

-Peter Norvig

SICP is a great book for beginners, as long as what they're beginning to do goes beyond cut and paste.

Metaprogramming is not an advanced technique, unless you treat "advanced" and "new" as synonyms.

Thursday, January 10, 2008

An Utter Disregard For Freeloaders

Emboldened by Zed's fine example, Dreamhost is letting off some steam:

the solution from the Rails community itself was quite honestly, stupid. They said to stop using Apache and FastCGI (a combination that successfully powers bazillions of websites, just not Ruby on Rails ones) and instead to entirely retool our servers with Lighttpd and SCGI (a FastCGI like protocol that may be technically superior, but next to nobody uses). That suggestion shows either a complete lack of understanding of how web hosting works, or an utter disregard for the real world. It’s all good and fine to recommend that users use higher end dedicated server hosting for their commercial applications but you simply cannot ignore the fact that nearly everyone will want to use lower cost shared hosting for getting started. It’s just simple economics. Additionally, people who use systems like Ruby on Rails want to spend time programming and not time setting up servers. Recommending technologies that are not widely used or supported by any major web hosting company is putting too much of a burden on your users, the people you want to keep happy!

An interesting, somewhat weird thing about the Rails community is that everybody knows Rails is a free open-source project created because somebody wanted to have a really cool Web framework, yet people complain that Rails is hard to use for some reason or another. Rails is not a sofa. It is not designed for your comfort. It is designed for usefulness to the people who develop it. The basic idea is that if you want to make it better, go for it. Complaining is simply disregarded as noise. There are code contributions and there is noise. That's basically how it works.

Since anyone can join the ranks of the people who develop Rails the framework, the fact that Rails is designed for the people who develop it is not a bug, but a feature.

It's not a Bug, it's a feature.

Everything I just quoted Dreamhost saying came from a paragraph which started off like this:

These issues were later mostly mitigated by a single user of Ruby on Rails who wanted it to work better on our servers

That's how it's supposed to be. Open source works in the same way markets do: supply and demand. If the demand exists for a patch, it will come into being, guaranteed. That's why complaints are just noise. If they were worth paying attention to, they would be expressed as patches.

I'm not saying the Rails core team is perfect. I'm saying the whole idea that Rails ought to be easier or different or whatever is only true if you make it true by (to use Ghandi's phrase) being the change you want to see in the world. If you think the world needs somebody to fix Rails, then be that somebody.

I've come across this idea before:

And responded before as well.

DHH responded too, and said almost exactly the same thing:

Most Rails contributors are not big users of shared hosting and they tend to work on problems or enhancements that'll benefit their own usage of the framework. You don't have to have a degree in formal logic to deduce that work to improve life on shared hosting is not exactly a top priority for these people, myself included.


The Dreamhost guys in particular sounds like they're experiencing a lot of hurt running Rails in their shared hosting environments. That should be a great motivator to jump in and help improve things.


they have a substantial economic interest in making the shared hosting scenario for Rails easier.


That's both a personal motive for having a less stressful day and a profit motive for making your business more money. Sounds like a match made in heaven for someone like Dreamhost to get involved and help do the work to make Rails a great shared host experience.

Although I think he's a brilliant programmer, I have to say DHH might not be the greatest diplomat, because he followed this excellent common-sense reasoning with a request for Dreamhost to shut up and quit whining:

Don't treat the current Rails community as your unpaid vendor. Wipe the wah-wah tears off your chin and retract the threats of imminent calamity if we don't drop everything we're doing to pursue your needs.

But then again, given the title of this post, for me to call DHH a lousy diplomat is at best the pot calling the kettle black, and at worst the black object calling the grey object black. That's not the point, anyway. I bring in his post because I initially wrote this a few days ago, before his response, and the response I predicted is pretty much the response the world got. It's probably not worth yammering on about, except for one important piece:

Open source projects accurately reflect supply and demand. This is why they clobber commercial software so frequently.

This whole Rails attitude of "I'm only going to work on something if it makes a difference to me personally, so don't expect me to do work for you unpaid to make your life easier, and don't expect me to care if you complain but don't contribute code" is actually a perfectly reasonable attitude to drive an open-source software project with. The self-interest which motivates code contributions is, in a way, a nice, dependable metric for determining demand for a feature. If enough demand for the feature exists, the feature comes into existence. There's a tautological nature to it that makes it very clean and neat. Supply and demand are so closely linked as to become almost indistinguishable.

The huge irony of commercial software development is that commercial software development by its nature cannot capture the market efficiencies that make capitalism so valuable. In software development, it's only free, open source projects that get free-market effects. That might seem like a contradiction in terms, but only if you don't really understand capitalism. Capitalism is effective not because greed is inherently good; capitalism is effective because market efficiencies can only exist where freely-operating agents act for their own benefit. Greed is just one mode of leverage which can create that kind of situation. Capitalist economies are systems where freely-operating agents act for their own benefit, so they get free-market efficiencies. But open-source software projects are also systems where freely-operating agents act for their own benefit, so they get free-market efficiencies too.

It's not really about the market; it's about the efficiency. The capitalist free market uses greed to achieve that efficiency; open-source software projects leverage convenience. In either case, you get a system with the required freely-operating independent self-interested agents, so you also get the inevitable concomitant efficiency. (Technically even the process of evolution is another example of this same fundamental dynamic.)

The nature of commercial software development is such that nobody really writes commercial software for their own benefit. They write it for some hypothetical customer. The customer's hypothetical nature means any and all features match their needs. Since the customer is hypothetical, their needs are hypothetical too. This is a big reason so many pieces of commercial software are chock-full of garbage features that could clearly only ever have originated with some soulless human gerbil who wanted to prove that when they came to work they were in fact awake throughout the entire day. Or at least most of it.

(Yes, Adobe Photoshop developers, I saw what you did there. You can fool some of the people some of the time, and apparently you can fool all of Adobe's project managers all of the time, but if I ever find you, I'm gonna kick your ass.)

I too have been emboldened by Zed's fine example. Everybody's getting punk rock on the Web in 2008.

(Probably because nobody ever has to put their money where their mouth is. Yay the Web. Now everybody can be a tough guy.)

Anyway, if you really want to understand what I'm talking about, you need to get this book:

Linux is clearly a decentralized system, since it has no formal organization and its contributors come from all over the world. What decentralization offers Linux is diversity. In the traditional corporate model, top management hires the best employees it can, pays them to work full-time, generally gives them some direction about what problems to work on, and hopes for the best. That is not a bad model. It has the great virtue of making it easy to mobilize people to work on a particular problem, and it also allows companies to get very good at doing the things they know how to do. But it also necessarily limits the number of possible solutions that a corporation can come up with, both because of mathematical reality (a company has only so many workers, and they have only so much time) and because of the reality of organizational and beauraucratic politics. Linux, practically speaking, doesn't worry much about either. Surprisingly, there seems to be a huge supply of programmers willing to contribute their efforts to make the system better. That guarantees the field of possible solutions will be immense. There's enough variety among programmers, and there are enough programmers, that no matter what the bug is, someone is going to come up with a fix for it. And there's enough diversity that someone will recognize bugs when they appear. In the words of open-source guru Eric Raymond, "Given enough eyeballs, all bugs are shallow."

In the way it operates, in fact, Linux is not all that different from a market, as we saw in Chapter 2 on diversity. Like a bee colony, it sends out lots of foragers and assumes that one of them will find the best route to the flower fields. This is, without a doubt, less efficient than simply trying to define the best route to the field or even picking the smartest forager and letting him go. After all, if hundreds or thousands of programmers are spending their time trying to come up with a solution that only a few of them are going to find, that's many hours wasted that could be spent on something else. And yet, just as the free market's ability to generate lots of alternatives and then winnow them down is central to its continued growth, Linux's seeming wastefulness is a kind of strength (a strength that for-profit companies cannot, fortunately or unfortunately, rely on). You can let a thousand flowers bloom and then pick the one that smells the sweetest.

The long and the short of it is that free-market efficiencies aren't really about capitalism. Capitalist economies are just one way to harness the fundamental dynamic. The fundamental dynamic is essentially that good decision-making emerges naturally from any context where large groups of people operate freely, acting for their own individual benefit. Capitalist economies are one such context, free open-source software projects are another. Science, as Surowiecki explains in the book, is another. Every scientist who puts forward a successful new idea or who finds a flaw in an existing idea or who validates an existing idea sees their career improve as a result of the accomplishment. So science is an arena in which large groups of people act independently for their own individual benefit, and blam, we get electricity, TiVo, spaceships, and sliced bread. Or whatever it is science has given the world. I don't know off the top of my head but I'm sure there's something.

LSD. Science has given the world LSD. Good call, Science. Now give us sex robots, world peace, and cholesterol-free hot dogs. Daylight's burning, Science. Look alive.

ANYWAYZ...I forgot my point. But dammit, I had one, and it was worth making, probably.

Oh yeah. People who complain about Rails are silly. You must be the change you wish to see. You must invent the cholesterol-free hot dogs you wish to eat.

The general superiority of open-source software to commercial software is intrinsic and inevitable. Capitalism is not the defining example of free-market efficiencies, and harnessing free-market efficiencies by giving things away for free makes a lot more sense than you might think, primarily because "free-market efficiencies" is a misnomer. It's really "efficiencies due to the free operation of independent agents acting for their own benefit." (You can see why the less accurate phrase is nonetheless the more popular one.) Capitalism isn't the definitive example for situations where good decision-making operates as an emergent phenomenon from the interaction of independent agents; it's just one example of a broader dynamic which can be harnessed economically but which is not actually intrinsically economic in nature. Thus commercial software development serves a capitalist purpose but operates in a manner very unlike capitalism, while open-source software development operates in a manner very similar to capitalist free markets but has very different outcomes and goals. ("Market efficiencies" are not inherently market-oriented.) Where commercial software development is not inherently powered by people who are being the change they wish to see, open-source software development is. Finally, Science has given the world LSD, but not sex robots, yet.

I'm sure they're working on it.

Wednesday, January 9, 2008

iTunes Desperately Needs This Feature

You need to be able to have iTunes treat your laptop's hard drive as a virtual iPod. The reason is simple. There's no way in hell my entire music library will ever fit on the hard drive of any laptop at any time in the immediate future. At no time in the iPod's existence has my iTunes storage strategy ever been anything but putting my media files on an external drive. I don't want to lug my external media drive everywhere I go, but I do want iTunes to be useful software for listening to music.

It's probably possible to do this by creating a partitition on your hard drive and then giving it all the usual "iPod_Control" magic files and folder names. I wonder if anybody's tried this yet. (Unfortunately, though, even if you did that, you'd still have the usual thing with iTunes where if you open it without your media drive attached it starts labelling files as missing.)

Note to self: add virtual iPods somehow. Fix iTunes.

Monday, January 7, 2008

Harder Better Faster Stronger


The Problem In A Nutshell

RIAA -> Napster == Catholic Church -> Galileo

(Paraphrasing a Yahoo! VP.)

Sunday, January 6, 2008

Drive Propellerhead Reason With Ruby

In 2006 I wrote a couple MIDI code generators for Ruby. The cooler of the two I unfortunately lost to the mists of time; it could generate simple ambient soundscapes in Reason. The more experimental one, v0.0.1, I put on my old Web site,, which still houses a lot of my art, video, and music.

Topher Cyll's mind-bogglingly cool Ruby book contains code to drive Pete Yandell's SimpleSynth with Ruby, but if you want to drive Reason instead, it's really easy. Assuming you're on OS X, download MIDI Patchbay, also by Pete Yandell. Then just set up a blank MIDI input and a blank MIDI output.

Next you'll want to set up something equally basic in Reason. Go into Preferences, and in Advanced MIDI, select the output bus you just created in MIDI Patchbay. Make sure you've got some kind of actual instrument plugged into a sound output in Reason - usually this'll happen if you just create a Subtractor synth - and in the Hardware Interface wire up MIDI channel 1 to your actual sound-making instrument.

Voila. You can now make music in Reason by generating MIDI in Ruby.

Therefore You Need Street Smarts

Sketch: Dance Music Generator Design

This awe-inspiring compendium of awesomeness provides what is probably (haven't actually put it to the test yet) a workable skeleton:

I think a framework for generating dance music would probably best be implemented as either a set of self-permutating code generators or, as it appears to be in the book and the article, a stack of permutations. I think a set of self-permutating code generators is actually a much more powerful design, with the caveat that you would want some way of prioritizing, tracking, and correlating the existing permutations. (After all there has to be a meta-pattern to the selection of permutations.)

What I have in mind here is not necessarily a giant music-generating code-brain, as much as a musical equivalent to Rails scaffolding - something you can use to auto-generate a skeletal "song" which you then work on manually.

Anyway, I'm just thinking aloud, but it could be pretty cool, especially when combined with Live's controller-mapping facility, which would make operating a device of that nature in real time pretty easy. As long as you had good patches to work with in the live context, a combination of knob-twiddling for sonic shaping and drumming for sequencer control would be pretty cool. (I initially wasn't going to mess with Live, since I don't own it and it's beaucoup dinero, but the MIDI controller mapping is just way too cool.)

Saturday, January 5, 2008

The Looks Or The Lifestyle?

A Pop Will Eat Itself album - not their best.

When I was younger, I had a steady corporate job, and I wore raver orange all the time. I sat at a cubicle for eight hours a day wearing baggy jeans and looking different. Sitting in a cubicle for eight hours a day means something special when you do it wearing baggy jeans.

These days, I move around a lot, I study acting, I take time off working to draw, and I dress so normal people could think I was a cop.

It's a false dichotomy. (As much as I loved them, pretty much all the questions PWEI ever asked revolved around false dichotomies.) But I've fallen into it, and chosen the lifestyle, not the looks. In the past I was also trapped in the same false dichotomy, but back then I went with the looks, not the lifestyle.

If you're facing the same false dichotomy, trust me when I say the only good answer is: both.

Friday, January 4, 2008

Zed Freaks And The Chat Logs Go Nutz

Shoes Is Not A Ruby GUI Platform

I see this misconception from time to time, so here's a quote from why the lucky stiff on that very question:

I really only have two reasons for writing Shoes: (1) to act as the new runtime for Hackety Hack and (2) as an experimental programming platform for beginners. I don't think Shoes appeals at all to GUI programmers or to the marketplace. I don't even use the acronym GUI anywhere in Shoes docs or materials.

I want Shoes to get in the hands of hobbyists and kids!!

I think it's safe to say that Shoes is a toy - not in the dismissive programmer-slang sense, but in the literal sense that its primary design goal is to be fun. I think toy design is probably more important than people realize.

Thursday, January 3, 2008

D. Ramirez Future Music Production Videos via Google

The really amazing thing about my programming career is that I even have one. I put programming very much on the back burner for several years where all my brain power went to music, writing, and art. The total lack of commercial and critical success I had during that time doesn't speak well of my brain power, but these things remain an interest for me. Here's a pretty excellent series of videos from Future Music found on Google Video (via BijouBreaks) where successful English electro-house producer D. Ramirez walks through the process of building a remix.

Part 1:

Part 2:

Part 3:

Zed Shaw's Marketing 101: How To Carve A Market Niche

Over the past few days, who do you think just became the worldwide "expert" in everything that could possibly be considered a bug in Rails?

Giles Doesn't Need Coffee In The Morning

Keeping it allllllllll natural.

Why Some People Dig Zed

Saw a couple tweets between Dave Thomas and Tim Bray expressing surprise over positive Web response to Zed Shaw's rant.

It's easy enough to understand.

There's a rule in business called The Asshole Rule. It's a simple rule: don't hire assholes. The problem with the rule, however, is that everyone is an asshole at some point in their lives. Asshole isn't really an identity; it's a state of mind. It's not an intrinsic quality like the color of your eyes; it's a thing you do. And some people do it more often than others. Those are the people not to hire. But everybody does it sometimes.

The benefit of a rant like Zed's is that you get to find out exactly when; we now all know what leads to asshole mode for Zed Shaw. Apparently it's six months of financial struggle and Rails programmers. That makes him less patient than Mother Teresa and more patient than Ben Stiller, who, if the trailer for "Heartbreak Kid" told the truth, can do zero to asshole in only thirty seconds of mariachi music.

Some people do asshole very publicly, very loudly, leaving you in very little doubt as to whether or not they're doing the asshole thing. Some people do asshole very quietly, with great subtlety, and you can still be wondering if they were really an asshole years later, even though you know for a fact that the money is gone, or the woman is gone, or things at that particular job really were never the same. It's the difference between the sixty megaton asshole and the X-Files ninja asshole.

The X-Files ninja asshole is a serious problem. The sixty megaton asshole is fun to watch. I could believe it if somebody told me that even Koz enjoyed Zed's rant. I think even its major targets had to appreciate the sheer sincerity of it. And let's face it - six months of financial struggle could do that to anybody, and six months of Rails programmers could do it to a lot of people. It definitely does depend on which Rails programmers, and how you interact with them.

There's a tiresome, unpleasant cliche type of Rails programmer. This programmer mocks "enterprise" and Java the same way DHH does, but that whole thing DHH did with, like, actually reading Fowler's "Patterns Of Enterprise Architecture" and owing his primary career-making stroke of genius to that book? Not so much so. Not so much with the actually learning about the things they criticize. Not so much with the being diplomatic, considerate, or fair-minded either. Or knowledgeable, for that matter.

My grandmother once described driving a small British car through a huge automatic car wash as like being assaulted by teddy bears. Disagreeing with the cliche ex-PHP know-it-all Rails programmer is like getting lectured by Teddy Ruxpin. (I apologize that I was not able to link in any videos of Teddy Ruxpin playing a Metallica tape. For once YouTube has fallen short of its promised greatness.)

The tiresome, unpleasant cliche ex-PHP ignorant know-it-all Rails programmer is a serious fucking asshole. Some people dig Zed because watching the sixty megaton asshole take on the asshole who had it coming is like watching Godzilla battle a giant robot. It doesn't matter who wins; either way, it's still bad for the whole city of Tokyo, and it's still fundamentally watchable entertainment.

I've got nothing againt either Koz or Kevin Clark, but that's not the point here. They point is why do some people enjoy this rant even though they don't have anything against those guys either.

Wednesday, January 2, 2008

I'm In The Advanced Rails Recipes PDF

With LA Times co-worker John Dewey. Neato!

Like Tim Bray, Except Cool

Tim Bray hinted at it; Ola Bini explains it:

I have a firm belief that the end of big languages is very close. There won't be a next big language. There might be some that are more popular than others, but the way development will happen will be much more divided into using different languages in the same project, where the different languages are suited for different things. This is the whole Polyglot idea. And my take on it is this: the JVM is the best platform there is for a Polyglot platform, and I think we will see three language layers emerge in larger applications. Now, the languages won't necessarily be built on top of each other, but they will all run on the JVM.

Just Another Seaside Hacker

I really think that anyone that is looking at Ruby On Rails for a startup should consider Seaside as well.

Tuesday, January 1, 2008

TechCrunch Comments About Zed Shaw


The night is starry
and the stars are blue and shiver in the distance.

The night wind revolves in the sky and sings.

Hey Kid, Want A Crappy OS X Screensaver?

Here you go. Stick that in your /Library/Screen\ Savers/ and smoke it.

Grr Apple Grr Arrgh Etc.: Video Out Hoops To Jump

In 2005, if you wanted to use a simple Radio Shack cable to plug your iPod into a TV, you could - but you had to juggle the standard red-yellow-white cable colors in a particular order, matching red to yellow and yellow to white arbitrarily, like learning the cheat codes to a Nintendo game.

In 2008, if you want to plug an iPod into a TV, your iPod will first check for the presence of a tiny Apple-approval indicator chip on the physical cable.

Computer companies have been making moves like this for years. What a lot of people don't realize is that such activities violate the spirit and in many cases the letter of antitrust law. But the law is only relevant when enforced, and today antitrust law is very rarely recognized for the incredibly valuable resource it is. Even the allegedly liberal Clintons studied under Robert Bork, who's made dismantling antitrust law his life's work.

The good news is that anybody with a decent amount of Perl experience should find setting up GNUpod really easy. More news as events warrant.