Wednesday, January 31, 2007

Sunday, January 28, 2007

Bandwagon Blues

I've decided to go vegan, following the examples of Joi Ito and Xeni Jardin. More news as events warrant.

Life is Short, the Art is Long

So I'm taking a new job, giving up my independence, and it isn't a startup. It's a consultancy in Los Angeles, and I'm taking the job because I think they'll make me a better programmer than I am, and I also think they'll make me a better programmer than any startup or large corporation I know of would. This is a lot of pressure on them -- high expectations -- but I think it'll turn out to be worth it. More about this coming soon -- right now I've got a lot of packing and relocating to do.

Seaside Screencasts

So I followed a great example and cooked up a couple screencasts.

The first presents Seaside as a Web app IDE, one of the very cool things about it which sometimes gets overlooked in the discussion about it -- and I sometimes suspect the number of people talking about Seaside is larger than the number of people using it -- and the second addresses that whole Rails vs. Seaside thing in much greater detail. (I promise it isn't another language war.)

First screencast: 4 minutes:
Seaside is a framework and an IDE

Second screencast: 12 minutes:
Seaside and Rails

Update: turns out I'm wrong -- you can do REST in Seaside.

Update 2: I moved the screencasts to S3.

Saturday, January 27, 2007

Close To The Action == Close To The Silly

Been reading a bunch about screenwriting, and one of the funny things is that Hollywood executives are so wrapped up in the deal-making, marketing, and other things associated with making movies that they often ask really stupid questions.

When Ted and I turned in our first draft GODZILLA screenplay, the studio was pretty happy with it. The usual story concerns, clarifications, character issues, etc. But one executive had an odd note -- almost an insistence. He wanted us to include a 'third monster' in the story. Our plot involved Godzilla (call him 'monster one') battling an adversary (call him 'monster two'). So, with the script at 128 pages and budgeted out to $150 million, why add a 'monster three' to the mix?

The reason, it turned out, was that the studio didn't own the sequel rights to GODZILLA. If they were going to spend all that money on a film, they wanted a character they could license, and star in a sequel. So we were supposed to write-in a buddy monster for Godzilla to pal around with.

Again, I outlined this logic to my (non-film) friend. His immediate response: "Who's going to watch a sequel to GODZILLA that doesn't have Godzilla?"

As stupid as this sounds, people wrapped up in the world of venture capital often fall prey to the exact same kind of mistake -- paying so much attention to the deal-making behind the scenes, and the concerns motivating it, that they lose sight of simple common sense.

John Battelle's not stupid, not by a long shot, but he is close enough to the silly to seriously ask questions like "Will Google Buy Second Life?" I mean come on, why would anyone even consider that question? How is that question even supposed to be worth asking? I realize people think the bubble has returned, but it would have to return pretty fucking hardcore for that to make any sense at all.

Battelle's answer is no, and his reasons are pretty logical, but the question is so silly from the get-go that you wish instead of going to Davos to get buddy-buddy with the movers and shakers, he'd just gone to Cleveland instead, or Toledo for the love of God, and taken a weekend among mere mortals for the wonderful reality check of boring Midwestern life. I'm sure he's having a great trip, but personally what I want from him is a great blog, and blogging is essentially writing. Hemingway said the key to writing is a powerful bullshit filter. You're more likely to develop that in Cleveland than in Davos.

John Battelle's a very smart man, but he just got booted from my RSS aggregator. Sorry dude.

Friday, January 26, 2007

Don't Build Anything From Scaffolding!

This one's for the newbies. Mr. Jamis Buck says:

scaffolding is a great learning tool, like training wheels or parachuting in tandem with an instructor. But when you do the real thing, those training wheels come off. You jump from the plane alone. You design the UI first.

And just for the record, you'll see the "start with UI" advice in Getting Real as well.

Quantum Computing And Military Tech

Quantum computing is pretty weird, and has lead at least one thinker to suggest that NP-complete problems cannot be solved in the physical universe. Latest developments include a team at the University of Rochester which was able to store an entire image on a single photon, and a quantum-encrypted network developed by a Swiss quantum computing company and an Australian encryption firm.

Meanwhile the American military has developed a heat-ray gun which causes intense pain without, apparently, any concomitant injury. The device looks pretty much exactly how you would expect sophisticated American military technology to look:

Although military robotics is already a flourishing field, which, although in some cases utterly terrifying, will very probably ultimately result in very, very compelling civilian benefits, Singapore is upping the ante with a tech contest. The challenge is to create a robot capable of performing the roles of a soldier, and the reward is about $700,000. Considering the millions -- probably billions -- that Japanese companies have already spent on anthropomorphic robots, less than a million dollars for a robot which is functionally anthropomorphic, even if not visually so, that's frankly a bit like offering somebody a sandwich for a car.

My weird tech news generally comes from I&T Weekly.

Thursday, January 25, 2007

Interesting Thing

Gave a little talk about Seaside today, and a Smalltalker disputed the whole href/goto thing. Now again, this isn't really my idea, but what was interesting was that he said he thought href wasn't so much a goto as a message passed to an object. I disagree, I think, but I do think this is actually the whole point of Rails' approach to REST -- to set Rails apps up as objects simply passing messages to each other, and (in some cases) doing so over HTTP.

Monday, January 22, 2007

Uh-Oh, He Went There

Ramon Leon did the unthinkable and wrote a blog post called Rails vs. Seaside.

Of course with a title like that, you're going to get some traffic; unfortunately, just like Pat Maddox's blog post today, Java People Must Be Stupid, a title which draws in traffic doesn't always necessarily draw in a whole lot of thoughtful comments as well. Must be some astrological thing, it's a good day for provocative titles that result in minimally thoughtful discussions.

The big theme in the dumber comments on Ramon's post was that Rails is obviously better than Seaside, because you can generate HTML programmatically in Rails too. The thing is, Seaside's advantage is not the ability to generate HTML programmatically. That's like, you're packing for a trip, so you compare a black sweater and a white spacesuit, and you say the sweater's better because it's hard to keep white clothes clean. These are completely different things. The sweater might be easier to wear on the plane, but if your destination is above the atmosphere, the spacesuit is going to be your only option.

Seaside doesn't generate HTML programmatically because that approach has some inherent superiority. Seaside generates HTML programmatically because it's necessary in the context of Seaside's design, and Seaside's design is the interesting part. Seaside uses a completely distinct paradigm for Web applications, and it's a paradigm where template files are much less useful. You could add templates to Seaside very, very easily, but it would be a bad idea.

Here's why. Think about named routes. Jamis Buck praised these today, and his praise certainly had some merit. Jamis Buck is, of course, a very, very smart programmer. But think about named routes. What is a named route, exactly? If your Web application could be conveniently and comprehensibly viewed as a single codebase, what would a named route be?

Named routes would be labels, the last relic of goto still surviving in Java and Perl -- and probably many other places as well -- like a Loch Ness icthyosaur lurking somewhere in Scotland, millions of years after the extinction of all its cousins. There's a reason that the guy who created Seaside calls his blog HREF Considered Harmful. An explicit, hard-coded href is completely identical to a goto. It is the same thing. And although the implementation of named routes is beautiful, the basic idea is only slightly more elegant than the basic idea of a named goto.

Say you've got an app which you're building first without Ajax, and then with Ajax. This is a very common development practice, because Ajax is often a pain in the ass to debug. Assume you're building such an app, and assume further that all the hard stuff happens on the server side, and the Ajax stuff is just cosmetic. If you build this app first without Ajax, you get to code all the hard parts in the context of standard Rails error messages -- in effect using your server and browser almost as a de facto IDE. Then when you do the last little Ajax bit, the cosmetic bit, all you're really doing is changing the views and a few controller render calls.

If you were in Seaside, you wouldn't have to do that. Seaside views HTML as a stream, and the same component can generate the same HTML on the stream whether the stream's sent out as a complete page load or an incomplete page load. Different divs in the page can come from different objects in Smalltalk, and the same set of objects can be used for rendering as Ajax or in the original Web 1.0 style. It makes no difference at all. You have complete control. And while you can emulate that kind of componentized system in Rails, with multiple levels of nested partials, it isn't elegant at all. In fact it's so heinously inelegant that you can really only do it for trivial cases. It's kind of like the way you can really only do trivial flow control if you're using goto.

But let's take it even further. Say something changes. You have a series of steps to fill out, in a form. If Pat Maddox is working for you, you can already fill out those steps in any random order, and it's not going to matter. But in most cases, you'll have to revise your system. Like say you've got a form, and the form has twenty fields, and those fields all live inside one form which you display to the user with a render call. And suddenly you want the user to be able to enter the form fields in any order, and have them saved immediately. And further, you want these form fields to be accessible at any point, anywhere in the application, where before they were only accessible at specific points, on specific pages.

To transform a code base this way, it might be possible in Rails, if you have a good team. In fact I think that's the whole point of the restful approach, and if I understand correctly, that's why people are so excited about it.

But to transform a code base this way, in Seaside? There is no transformation. You get all that for free. It's built in. That's the whole point of Seaside. Dismantling your entire design just to save form fields in a different order isn't necessary if you aren't using the 2007 goto anywhere in your code base.

At best, a Web application framework built on URLs gives you a command-line interface in the "Location" box. At worst, you get a tangled nest of gotos. But with a continuation server, you get an entire app on every page load. Everything you need is right there. The type of flexibility and detailed control which users take for granted in desktop apps is absolutely achievable in Web apps -- but it might not be achievable with Rails.

That is the question that makes Seaside interesting. Is what Seaside does without breaking a sweat even possible with Rails?

I still work with Rails. I love Rails. I'm just saying all this to offset the stupidity of the comments in Ramon's blog about Rails being able to generate HTML programmatically. It's not about being able to generate HTML programmatically. It's about being able to generate Web apps programmatically.

irb Ninja Shit

Amy Hoy's overview
Wirble (syntax coloring, tab completion, saved history)
Ultra fucking ninja, get it now
Apprentice ninja

Also useful for Rails console.

(Fair warning, in the "ultra ninja" one, you use it by copying and pasting a code sample. Problem is, the code sample is tainted with curly quotes and Wordpress devoured the slash in a newline sequence at the end of a string. Does require some very minor hacking.)

Update: the "ultra ninja" thing actually requires more hacking than I thought it would, so if you want to skip that effort, you can use this code sample instead. By the way, if you took a look and you're thinking, well, what's so ninja about that anyway, the answer is that it takes regular expressions as arguments. Is it convenient to be able to search any object's available methods with a regex? Of course it is.

A Favor

Pat Maddox wrote a post called "Java People Must Be Stupid," and unfortunately, his irony blew up in his face. The point of his post isn't really that Java people are stupid -- it's that Java people coming to Ruby often seem to arrive with the crippling assumption that their fellow programmers are stupid.

What worries Java immigrants to Ruby is that Ruby doesn't have any of the protection mechanisms Java has, and the protection mechanisms it does have are easily circumvented. Pat's point is basically, "let it go, don't be afraid," but his phrasing put him right in the middle of a language war.

Anyway, I posted a comment there, and Reg Braithwaite asked me to post it on my own blog, so he could link to it without including all the shrapnel and debris from the language war, so here we go:

It’s not really stupid people, it’s people who’ve accepted a stupid idea. Java’s design is based on the idea that a language can prevent misuse by making bad things hard to do. It’s defensive thinking. Java people are caught up in this paradigm; that’s where these questions come from.

It might be more accurate to say that Java people are smarter than they give themselves credit for.

The thing is, telling people they’re stupid, when their problem is an equal mix of bad ideas and defensive thinking, that’s not the most persuasive argument available.

I think the only compelling argument, from a Java perspective, at least, in terms of Java people I’ve talked to, is that nobody ever actually accesses the stuff inside Rails which, if it were inside Java, would be hidden. The door isn’t locked, but still nobody goes in.

In any OOP language you do want to keep client programmers only using the API, not the internals of the objects the API is made of. That’s a good design principle. Java makes it happen by building a fort, locking everything down, the theory being they can’t steal it if it’s nailed to the floor. Their goal is legitimate, but their way of achieving it is kind of paranoid. Ruby’s got the same goal, but a radically different approach to achieving it. It doesn’t enforce any kind of security, but makes it easy to build such elegant APIs that entering the “forbidden zone” never even occurs to people, because it just isn’t necessary.

It’s like the opposite of thinking defensively isn’t thinking offensively; the opposite of thinking defensively is thinking creatively.

How To Throw Away Billions

This is amazing. It's the story of Yahoo vs. Google, and here's how it starts. Both companies discover the concept of targeted ads. Yahoo hires a Hollywood CEO with zero tech experience -- "a guy who doesn't even read e-mail," according to the Wired story -- and the Hollywood guy decides it would be easier to buy two startups and integrate their technologies than it would to build a custom system.

Meanwhile, Google builds a custom system, and it's so much better that most people don't even know Yahoo ever even entered the targeted ads space in the first place. Yahoo bought the company that developed the idea, but everybody thinks Google invented it.

And the thing is, if you think about it, the technology is trivial. The only challenging element in building a system like Google's would be recreating the GFS, and then doing all the analytics and data mining. The system itself is just an auction. It's a weighted comparison. It's algebra. So this is the challenge on each company's plate, and Yahoo's Hollywood CEO fights with his engineers for months to persuade them that integrating outside technology would be easier than coding something from scratch.

What on earth were they thinking? It's just unbelievable. You take a guy who doesn't use e-mail, put him in charge of an Internet company, and he makes bad decisions because he doesn't know anything about building software. How could they not have seen that coming? It's like hiring an atheist to run a church. You can't even blame the guy, it's the people who hired him that you have to wonder about.

If you ever want proof that it's better to be brains in search of bucks than bucks in search of brains, this could be the most obvious example ever. It's definitely one of the funniest.

Sunday, January 21, 2007


I finally found some time to get back to work on a simple demo app in Seaside -- just a blog, built by following along with Ramon Leon's screencast. When I left off I had hit some snags; Ramon helped me figure some of them out, and I just solved the last remaining one. The answer turned out to be pretty easy; slightly more detailed blog post coming soonish. (I hope!)

Just Studying Is Never Enough

Peter Siebel presents Common Lisp at Google, and explains why it's not enough to just learn a new language, you have to actually use it. Found via the Google Research Blog, and by the way, there's plenty more where that came from.

Saturday, January 20, 2007

Canada Duane FTW

As far as I can tell, every Rails app on earth already uses his paginate_collection code. Now he has a Rails plugin for generating complex and/or conditions in SQL based on conditional flow control in Ruby.

Basically it allows you much, much more granular control over your queries than standard Rails methods, in a much, much more maintainable way than the usual hard-coded ':conditions => "this AND that OR the_other_thing"' SQL strings. Instead of generating the strings conditionally, you generate the conditions themselves, and the plugin builds the actual SQL. Not only more maintainable, therefore, but also potentially more portable as well.

A very, very good idea.

SHA-1 Cracked


Friday, January 19, 2007

Background on Symbols

One of the things that takes a bit of getting used to in Ruby is the symbol datatype. It seems like they're the same thing as strings, but they're not. There's a really good explanation on O'Reilly's Ruby blog, but it gets into such an involved digression on metaprogramming while setting up its examples that it's almost more useful for understanding metaprogramming instead.

Another thing that helps -- maybe helps more -- is to look at the background. As far as I can tell, Ruby's symbols are a nearly direct transliteration of Smalltalk's symbols. There's a good post on lazy initialization in Smalltalk where Ramon Leon says, "Symbols are often used where strings might be used in languages that lack them." That's a very partisan description of a language feature, but it also really tells you everything you need to know -- if you take the time to think it through.

Take a quick look at Ramon's example code in C# and Smalltalk. Unfortunately you'll have to actually click the link, because Blogger has a number of flaws that make it essentially not useful for a code blog, and I obviously chose it pretty randomly, since a programmer whose blog is not useful as a code blog cannot be said to be somebody who researched all available blogging platforms before making his choice. But let's skate past that, since it obviously highlights my foolishness, and get to the point.

The point is that in the C# example, Ramon uses a string ("AddressSearch"), and in the Smalltalk example, he uses a symbol (#AddressSearch). Just for completeness, the Smalltalk #AddressSearch is pretty much identical to the Ruby :address_search, the only differences being capitalization and trivial syntax.

Now, I don't know C#, but I do know Java, and I do know further, that in Java, if you read Josh Bloch, you don't write your Java that way. Using Strings as flags indicating state is a big, big no-no in Bloch's book, and there's a very good reason. It's an extremely bad habit. If you have a piece of code which uses Strings to represent state, and this code is invoked very frequently, your program will create a new String with the exact same content every time it needs to represent that state. In a performance-sensitive application, the overhead will be painful. Painful in the sense of ridiculously wasteful object initialization and garbage collection, and painful also in the sense that it is ridiculously simple to avoid the problem in the first place.

Bloch's solution is to create a Java Class representing the state information, and to make state or type info within such a class static, so that it's only instantiated once, and never garbage collected. In one of his books he describes creating a very significant performance improvement with this very simple change.

It's pretty easy to see that what Bloch is actually doing is adding symbols to Java. These objects are instantiated once, and since they remain instantiated, if the program needs to represent state the same way again, it doesn't have to create a new String each time. Likewise, you don't have to deal with the pecularities of String comparison -- which in Java has more pitfalls than you might think -- because when you compare these objects to each other, you're not comparing different String objects that might hold the same value, you're simply comparing two objects which either are exactly the same object, or not. That's a lot faster for the JVM, it's less error-prone for developers, and it's also exactly what you get for free with symbols in Smalltalk and Ruby. Even better, you don't have to watch a mission-critical app slow to a grinding halt and give you pathetic performance, at a consulting gig where you're representing the company behind the language, to figure all this out. It's built in from day one. You never even need to think about it.

Ramon's statement, that strings are often used for symbols in languages that lack them, is partisan but totally true. In fact, not only is it true, but further, programmers working in languages without symbols really have to choose. They can either add symbols to their language, or the result will be applications with massively inferior performance. And companies marketing languages which lack symbols have to pay really good programmers lots and lots of money to develop "design patterns" whose sole purpose is bolting on features which Smalltalk had in 1979 (and which, for that matter, Lisp had in the 50s). That's an expensive way to design a language.

Anyway, if you're a Ruby newbie and you're still not quite sure when you should use symbols instead of strings, the answer is really, anywhere that using strings would be a hack. That is to say, if strings are only for text processing, and you're using a string in some internal, programmatic way, such as to represent state or to influence flow control, there you go, that's it, that should be a symbol. Strings are for text processing, and symbols are for everything you used to use strings for because you didn't have symbols.

By the way, the actual subject of Ramon's post -- lazy initialization -- is one place where Ruby makes even Smalltalk look clunky. This is lazy initialization in Smalltalk:

^foo ifNil: [foo := #bar]

And this is lazy initialization in Ruby:

foo ||= :bar

A Better Use For Referrer Search Terms

Hopefully people have decided to avoid referrer search term highlighting. Does that make referrer search terms useless data? Absolutely not.

Thursday, January 18, 2007

Really Smart People

Finally caught up on some of my blogs today, and found some amazing stuff.

First, Pat Maddox uses a declarative style to push Rails very close to Seaside's clean and effortless modularity:

Your app is still generally useful because it's not tied to the workflow. You can bypass the entire workflow by just POSTing all the attributes of a Supermodel. You can combine steps by PUTting just a couple of the attributes at once.

The workflow is just a bunch of objects, so you can store workflows in the DB. Then you can do cool stuff like create an admin interface to maintain workflows. Imagine you're at a page that has all the possible workflow steps. Add/delete/rearrange steps with some AJAXy goodness.

A workflow can easily cross multiple controllers, it's not limited to the current controller.

The funny thing about this post is that Pat spends so many words of it beating himself up for not adhering strictly to the RESTful dogma that I don't think he has the faintest idea how brilliant what he's done actually is. That's something I'd be impressed to see coming from Jamis Buck.

Next up is Reg Braithwaite, consistently one of my favorite bloggers, with a very compelling argument that computer science matters more than ever:

You know how bit-twiddling in Java is irrelevant because you’re waiting for the database any ways? Well, we can’t afford to wait for this particular function, it’s one of those AJAX-y things that happens in real time. We can’t wait to go back to the database. So we have to load something into memory on the server, build a compact data structure, and traverse it quickly. And oh yes, we can’t have a lot of layers of crap, we need to get a response back to the browser with every key press.

For another client, we had to build a task dispatching system. It was like building a piece of a very lightweight fault-tolerant operating system. That operated across data centres in three different cities, moving jobs around from centre to centre. If you were in an interview and someone posed one of those hypothetical “how would you design a …” problems, would you think they stole the problem from some Amazon programmer’s weblog? Would you think “you don’t need that for business programming?” Well, we built that. For an ordinary, brick and mortar business that makes physical stuff.


Standards are rising. We’re doing more and more work that steps outside of the usual CRUD development.

Here’s the big reason why. Have you read people grousing about interviews where they’re asked about how to implement a search? And about what a waste it is because 99% of the time the database does it, and the rest of the time they stick it in a hash table? Well, in 2007 search matters. The database is a big part of that, but it’s not as easy as SELECT foo.* FROM bar WHERE ... any more.

Google has become the “start page of the internet.” As a result, everyone now thinks that the way to find stuff is to do a full text search. Everyone thinks that relevant results should be first. And I mean everyone, not just your “early adopter” users, you now have Joe Average calling your customer support hotline and complaining that the search page on your application—the one with a different field for each column in each table—is too hard and why can’t he just type something and get an answer?

Very cool.

Burning Man Countdown Dashboard Widget

There's an OS X Dashboard Widget which counts down the days until Burning Man. You do have to set the correct date by hand -- it defaults to the date of Burning Man 2006, and when you install it, it plays a Timothy Leary audio sample because it thinks the burn is on -- but it's still utterly great.

Download it if you've got OS X.

Wednesday, January 17, 2007

Dynamically Generated Code

One of the things I don't get is why dynamically-generated code is supposed to be such a big deal. The experience of writing code to generate code should be extremely familiar to anybody who's ever had to make a non-trivially complex Web app, and even to many people who've only made trivial ones. I've personally always avoided PHP like the plague, so the vast majority of Web apps I've built, especially during the bubble, used Perl to generate HTML and JavaScript. Some trivial scripts used Python to generate only HTML, some used JSP inline HTML within the context of larger frameworks, some used other systems or other languages, sometimes the JavaScript was always the same, sometimes it changed from page load to page load, yadda yadda yadda -- the point is, in every case, the fundamental experience of building Web apps is writing code to generate other code. Even the simplest PHP script will have conditional display of particular bits of HTML.

The current fervor for metaprogramming ultimately traces back to this. It's possible that it could even be the cause of Java's apparently-impending demise. I think generating code from code is harder in Java than in any other language I really know. If you cut your teeth writing CGI scripts which conditionally generate various bits and pieces of HTML, it's really pretty much inevitable that when you mature as a programmer, you'll gravitate to objects whose methods are defined at runtime, higher-order functions, and what the Pythonistas call "monkey-patching". I know I'm not the only person who turned aside from a "creative" career to learn programming at the start of the bubble ("creative" in the corporate sense -- obviously, in reality, programming is a very creative career). You've got an entire generation of programmers who see their work as essentially the art of constructing code from code.

Anyway, this line of thinking is a response to these:

Digging Into Ruby Symbols
How Ruby Sucks (by Matz!)

The first contains, as an example, what has got to be the single most obvious, most lucid "hello world" of Ruby metaprogramming I've ever seen. The second was a presentation at RubyConf in 2003, and covers changes that have happened since then, as well as changes still yet to come.


Coderpath Screencast

Cool idea; like Peepcode but free!

Only one episode, it's DHH with a very newbie-friendly intro. It's extremely different from the content of this blog, which tends to the high end of intermediate, or at least I like to think so. Much more newbie-oriented, but the theme song's entertaining, and I think this whole trend of screencasting is very interesting.

Stop Highlighting Referrer Search Terms!

Please, ANYONE who reads this, don't do it. Every web page out there has the option today of automatically highlighting search terms used in the Google search which brought people to your page. Just because you can do it doesn't make it a good idea! This is another god damn blink tag.

I frequently use Google to "find" pages which I've visited 100 times, and in some cases, whose URLs I do in fact know. I do it because it's easy. And the thing is, I'm a Web developer. I have a higher knowledge of URLs than the average person. Many people don't even know (or care) what a URL is. They use Google to find stuff too, because they have a URL box and a Google box, and they don't know what either box does, but the Google box throws errors less frequently. So they use the Google box instead of the URL box, and I do it too. I do it because it's quick, they do it because it's easy -- really these are the same reasons, but the long and the short of it is, using Google to find something you're already familiar with is actually a very common use case.

In this use case, you don't need highlighting to show you the search term. Specific example: I need some documention on the acts_as_ferret Rails plugin. I google it, I get the right page, click, boom, good. Except how many times does "acts_as_ferret" appear on the acts_as_ferret site? More than once! And nearly every time it appears, it's in an H1 or some other kind of emphasized context. The additional emphasis of the highlighting is redundant and unhelpful.

And while I'm ranting against stupidity, can I just paraphrase the blogger who complained that acts_as_ferret has a totally inaccurate name? Wouldn't is_searchable have made a lot more sense? It's not as if acts_as_ferret smells funky, bites people, and tries to eat rabbits, is it?

Seriously, the "acts as" convention is good, but let's not go crazy here. If you look at the more rational uses of it, like acts_as_taggable, it's actually a very specific thing. Anything which acts_as_taggable conforms to an interface called Taggable. I understand all the hero worship around DHH, he's very smart, he's very good-looking, and he's got balls you could knock down bowling pins with. That's great. But a little less "monkey see, monkey do" and a little more high standards of rationality in method names, would that really hurt anybody? Let's take this thing back to its Smalltalk roots. isFoo is a very common naming convention in Smalltalk and it exists for a reason. Giving acts_as_ferret a more logical, simple, and descriptive name like is_searchable would have made life easier for everyone.

Anyway, back to usability stuff. The whole assumption behind highlighting referrer search terms is that the search term is what people are actually looking for -- and further that it's going to be sufficiently buried in additional text that highlighting could have some usefulness in the first place. But obviously that isn't the case in this example. I can tell you, in my own personal experience, there are many examples where it isn't the case.

Further, in my own personal experience, even when it is the case, I'd still rather use the find function in my browser. The find function in your browser will highlight whichever search term you're looking for, and unlike highlighting referrer terms when the page renders, the find function only keeps the text highlighted for that brief moment when you're trying to find it. It doesn't remain highlighted indefinitely, while you're trying to read an entire paragraph located around it.

Any typographer can tell you that highlighting a random word won't make the surrounding paragraph easier to read. It's 2007, and we all know Web usability has a lot to do with typography. Referrer search term highlighting is a really dumb mistake, and after more than ten years of Web UI, it'd be nice if the dumb mistakes could stop happening.

Personally, whenever I encounter a page with referrer search term highlighting, I copy the URL, close the window, and open a new window with the URL. It's a pain.

Look at it from another perspective and it still looks like a blink tag, or worse. Think about the difference between what Google is and what Google says it is. It says it's a search engine. What is it really? It's the primary navigation system for the Web. When you're highlighting search terms from Google, at best you're setting up a blink tag -- a useless, irritating distraction. At worst, you're exposing the internal mechanics of the Web to people who have no idea what they're looking at.

In conclusion, stop highlighting referrer search terms. Please!

Tuesday, January 16, 2007

Rails and the Starship Enterprise

A little back there was a big ridiculous blog war about whether or not Rails was ready for the enterprise. Things got a little out of hand and David Heinemeier Hansson ended up saying that the enterprise wasn't ready for Rails. I'm paraphrasing here, but honestly, the whole thing was silly in my view. It all got started by a real bottom-feeder of a consultant, who was obviously trolling for blog hits and willing to say any random bullshit that happened to cross his mind, and it's really an embarassment to the Rails community that anybody ever responded to him at all.

There's a funny irony to the whole thing, though.

At the time, DHH said:

James McGovern's ill-conceived rant made a strong attempt at rendering the word 'enterprise' equal to, pardon my french, bullshit

The effect of this on the Rails culture was unfortunately quite one-sided. It's now become utterly commonplace among Rails developers for the word "enterprise" to be considered entirely synonymous with the word "bullshit." In other words, the general Rails community interpreted this very broadly, operating under the assumption that McGovern's attempt had succeeded, and the word "enterprise" therefore had successfully been rendered equal to "bullshit."

Here's where the funny irony comes in.

Probably the single best idea in the whole of Rails -- and it's a framework filled with great ideas -- is the clean, elegant implementation of ActiveRecord. I say implementation because ActiveRecord the software is based on Active Record, a pattern identified by Martin Fowler in his book Patterns of Enterprise Application Architecture.

See the irony? The whole idea of ActiveRecord comes from enterprise software development; yet many, many passionate Rails advocates dismiss anything connected with enterprise software development as bullshit because it's connected to enterprise software development.

If DHH had been operating from such a closed-minded, foolish vantage point, he never would have written ActiveRecord in the first place.

Anyway, why do I bring this up? Because Rails still has an enterprise community, and notwithstanding the stigma they've been given, this community is beginning to conclude -- and prove -- that Rails is absolutely enterprise-ready.

Transformers Clips Found On YouTube

So I'm pretty stoked for the upcoming Transformers movie, even though I'm mad at the liberties taken with the franchise. But what can I say. I love Transformers. I have a Decepticon logo tattooed on my left arm.

Transformer based on original Optimus Prime design
The disco Transformer we all know and love
Transformer discovered in old junkyard
Misogynistic but funny Japanese Xerox Transformer
Giant Nike shoe Transformer from Japan
Main trailer for the movie
Teaser trailer for the movie
VW New Beetle Transformer
Actual Working Prototype Transformer From Robot Expo

The most interesting thing there of course is the working prototype. I wasn't expecting to find that. But there are two caveats.

First, I don't actually know it's a working prototype. It just appears to be.

Second, it's tiny. The real challenge in building working Transformers is a materials challenge. Although it's pretty obvious that in the next few decades we will easily have computers which are cheap, tiny, and abundant enough to accomodate the type of complex simultaneous automated mechanical activity that Transformer designs require, it is a lot easier to build a Transformer six inches tall than a Transformer sixty feet tall. The reason is that smaller designs require orders of magnitude less structural support. It's the same reason those 50s movies with giant nuclear-mutated spiders were ridiculous; the structure of a spider is very much matched to the scale of a spider. In real life, a spider the size of a house would collapse under its own weight.

Similarly, although it is very exciting to see an actual working prototype of a Transformer, don't expect to see Optimus Prime anywhere other than a movie screen or a video iPod (or this blog) for quite some time yet.

Anyway. More videos:

Cheeseball ad for the original 80s movie
Screen test with Transformer based on original Sideswipe?
Movie hype from MTV
Cheeseball intro from original series
Original series' second-gen intro (my fav)
Actual episode (total cheese)
Classic breakdancing Soundwave from a few years ago

OK, actual programming content coming soon. Although there is a kickass episode of the 80s series out there which revolves around the Combaticons (Decepticons based on military machines) taking over the Middle East to turn oil into energon cubes. And I do love these pictures.

Second Life: Anti-Racism Protest

From BoingBoing. I used to think Second Life was just kind of silly and self-indulgent, but check this out. A French racist group opened an office in Second Life and it was only a matter of time before flying saucers were bombing it with pig grenades. A protest escalated almost immediately into utterly surreal political violence. I'm often tempted to laugh off Second Life, but you have to admit, this could never happen in World of Warcraft, and for once, the freedom in SL actually fulfills its promise, making WoW look like a gated community of Republican Baptists. No disrespect to any actual Republican Baptists reading this, but you must admit, the range of social expression among your people tends to be more conventional and less imaginative, and tainted with a corresponding authoritarianism. If you encounter racism in WoW, the most you can do is report it to a Blizzard employee. In Second Life, you can express your outrage by pelting the motherfuckers with exploding pigs.

The funny thing, though, is that this blog post, and the BoingBoing post which brought it to my attention, they both refer to this situation as a political protest that turned into something else. But that's not accurate at all. Nobody in the world was hurt by the exploding pigs. It wasn't really a political protest that turned into an exploding pig riot. It was a political protest in a simulated space. The protestors started out by simulating a real-world protest, and the neo-Nazis responded by using "weapons" which set off explosions that can lift your avatar and send it flying off through virtual space. Essentially, they sought to silence the protestors, and this is when the protest turned "violent." But in reality, the protest wasn't violent at all; it was merely theatrical.

Anybody who's ever heard of Gandhi knows that Second Life didn't see the invention of the theatrical protest. Gandhi's non-violent protests were based to a very large extent on the awareness that the British soldiers beating up his non-violent protestors would have to answer to ordinary British citizens who would hear about it. Gandhi and the British military were already on stage when that happened; it's just the British military didn't notice the audience, and Gandhi did.

This political "battle" in Second Life was in fact a very theatrical political protest. What's interesting about it from the standpoint of developers of social software is that nobody planned the event; its highly theatrical nature was an effect of its highly theatrical context. That's actually a very interesting thing. I've been skeptical for a very long time about these virtual worlds, because it seems like nobody except curious intellectuals ever seems interested in them. The only virtual worlds regular people go for are World of Warcraft and Quake, and the user experience in those worlds is extremely structured. The emergent behavior Second Life chases after is much more constrained in those contexts.

This, however, this political protest is absolutely an emergent behavior. It's a new thing, and if future MMPORGs offer similar freedom, we'll see similar things happen in the future. That being said, it isn't necessarily a victory for justice or whatever. The protestors weren't interested in hearing the neo-Nazis' point of view, and while I can't blame them, consider if Second Life were a Christian-themed MMPORG, and you're a member of one of the extremely large number of additional religions in the world. A victory for peer pressure is not necessarily a victory for justice. That may have happened this time, but the overall effect does not actually make Second Life a more democratic place.

Movie Titles

Motion graphics, graphic design, and animation -- basically, best of movie titles. Very nice work.

Monday, January 15, 2007

Saturday, January 13, 2007

Ryan Davis Interview

Filmed at Canada on Rails, in Vancouver; interesting because he's a kickass hacker with a Smalltalk background.


So there's a kickass object-modelling system in Smalltalk called Magritte. Magritte is basically like, imagine if you had ActiveRecord, minus the database part; and imagine further that it could change its shape aribtrarily and at will. From the main Magritte page:

Most applications consist of a big number of model- or so called domain-objects. Building different views, editors, and reports; querying, validating and storing those objects is very repetitive and error-prone, if an object changes its shape frequently.

The goal here, basically, is to be totally prepared if you run into a situation where you do know that you're going to need to do all kinds of things with a certain piece of data, but you don't know what form that data will have in the future. The perfect example of this kind of thing is Dabble, where you can record a date as a string, and then decide at some arbitrary future time that all these strings are in fact dates, and you need them mapped onto a calendar.

There's a great podcast where Avi Bryant describes the problem Dabble is designed to solve. It's a very, very common problem: spreadsheet abuse. DSL experts will tell you that the domain-specific language in Excel is actually the most popular programming language in the world. It's not actually because Excel is so good; it's also because it's an easy tool to use to represent a very wide range of data. One of the first Rails projects I worked on involved turning a de facto work orders system that consisted entirely of a manually-updated Excel spreadsheet into a nice Ajax-y Rails app which put almost exactly the same business process into a new context (the Web) and format (HTML). The idea behind Dabble is, you've got all this data people like to put into spreadsheets, because spreadsheets make sense visually, and yet these spreadsheet-driven systems inevitably get very ugly, because spreadsheets are the wrong technology for this kind of solution, so, let's give these people a spreadsheet with the ability to turn itself into a database further down the line, when the time comes, as it inevitably will.

Now the obvious thing, when you see Magritte, is to wonder about the database side. If it's ActiveRecord minus the database, that's kind of weird, because it's almost like the whole point of ActiveRecord is the database. Ramon Leon is working on an ActiveRecord for Smalltalk, which is basically Magritte meets Glorp, but the interesting thing here is, besides Dabble itself, when I first discovered this, I thought, my God, this Magritte thing, this is incredibly powerful. And then I thought about, what can I build with it? How can I learn this? And I couldn't think of an answer.

And I puzzled over this, but I'm puzzling no longer, and here's why. On Wednesday I met with one of the smartest companies I've really ever had the pleasure to meet with, and the funny thing is, they don't do a whole bunch of glamorous Web 2.0 stuff with VC funding. They build enterprise systems. And they told me why they think "enterprise" isn't a dirty word after all, despite the way the Rails community feels about it. They said that "enterprise" doesn't just mean big -- it means massively complex.

The example they gave me was inventory systems. Say you need to track a very large number of different items, structured as a very large number of different sets, in a very large number of different boxes, on a very large number of different palettes, in a very large number of different warehouses. Say further that you need to be able to reconfigure the sets these items are arranged in. You end up with a tree set, and you need to be able to represent that tree set in a database, and run reports on that database, and those reports need the kind of performance that allow you to get reports on very large data sets in a very small amount of time.

In a situation like this, you have a complex problem. But let's take it one further. Say you have some data in there which seems inessential; and that your clients or business users then give you new requirements which involve being able to reconfigure the whole system around that previously inessential data.

Sounds like a fucking nightmare, right? You have this gigantic tree set in a database, which is insane to begin with, since tree sets are best handled with linked lists, not relational rows; and you need to be able to move entire subtrees across the tree set, and of course you have to implement that in a relational database. And the whole thing has to have the type of indices and such that make databases capable of reporting on large data sets gracefully.

Enter Magritte, and assume for the sake of argument a fully mature Smalltalk ActiveRecord -- or a translation of Magritte into Ruby, and further one which allows precompilation of SQL calls, to optimize slow processes in Rails. In either case, your problem may or may not be entirely solved, but it's certainly streamlined. Because this is exactly the problem Magritte solves, on the code side. It still leaves you with the database side of the problem to solve -- and it could be that the database side is the really hard side anyway -- but what you have that you didn't have before is an elegant way to approach the problem.

It's pretty cool.

Friday, January 12, 2007

Google Video: Code Generation w/Ruby

Cool video. The presentation's interesting, I've always wanted to read the book, but the Q&A session seems entirely concerned with Rails. There's very little in the Q&A about the actual presentation topic, which is kind of silly. First half is cool though.

Old Post By Jamis Buck

this is how it should be done
this style is identical to none

Thursday, January 11, 2007

Literary Aspirations

I have a separate blog I use for my cultural stuff, music and writing, etc., and I think I'm going to have to change that. I think I may have to unify these things and put them all in one blog. The reason I think that is because I have an idea, tonight, which really belongs in both blogs.

The idea is this. An idea for a character in a book or a movie. This character is a philanthropist, concerned very deeply and very sincerely with halting the spread of disease. And yet, despite his philanthropy, he is, at heart, evil. And it comes out over the course of the story that he made his money by using ruthless and even illegal business practices to ensure that nearly every computer on the planet came pre-installed with software that was so bad it made life worse for anyone who used it. And of course the reason the story holds together so neatly is that his desire to rid the world of disease is really just a reflection of his subconscious awareness that by forcing people to install terrible software on every computer they sold, he was doing something very similar to spreading a terrible disease.

I think that might make an interesting story. It would be very interesting to create a character like that, show him to be indisputably and thoroughly evil, yet in the end inspire not just hatred, but also pity. I'd like to do that. Pity it's already been done.

Incredibly Useful Rails Console Trick

There are already tons of kickass Rails console tricks, but this one is new to me: you can easily instantiate a Logger with STDOUT as its stream. So if you want to know exactly what SQL ActiveRecord is generating, it is utterly trivial to find out.

Least Advisable Prediction Ever

From Foghound's Predictions for 2007:

Virtual worlds explode and get branded. While Second Life continues to boom, companies will offer more manageable and intimate virtual worlds, like CokeStudios. Private branded virtual worlds not only appeal to people who are overwhelmed by Second Life expanse, but give marketers a new way to connect directly with customers and capture new types of customer data and insights.

I'm not saying it won't happen. It might happen. But what a honking mess it will be if it does. Remember 1997? Remember how many companies built stuff that marketing companies told them they should build? Remember how few got anything out of it?

Clay Shirky explained the problem with this idea in December. I made an inarticulate attempt at explaining it in Wired in 1996. And by the way, if you follow the link, I have to tell you, that's not the version I gave them. The version I gave them was also inarticulate, but not quite that inarticulate. Editors do not always actually make writing better. The real reason blogs are so interesting could in fact be the absence of editors.

Anyway, that's enough of that. The point is, this mistake's been made before. It was dumb then, it's dumb now, and if there's one thing I've learned about dumb mistakes, people make them over and over again. It happens all the time. How many albums has Britney Spears sold?

So now the question. Let's say it happens. Virtual worlds become the new marketing ploy. Yet virtual worlds are dumb. And you're a programmer, which means that if some idiot wants to build a virtual world, they come to you. So. You might be thinking to yourself, well, many marketing-based web sites are dumb, yet I still learn something every time I make one. In fact marketing seems to be a system whereby corporations with lots of money hire good-looking people to make them feel good about themselves. They are the court fools of modern corporate imperialism, and pretty much everything they do is foolish. But so what? That's tautological. Why not just play along with this virtual world crap? I'll make some money and learn some skills. Yay me.

I apologize for attributing such cynicism to you, the hypothetical reader, but let's go into it and explode it, just for the sake of argument. Plenty of people mistakenly believe that this is what marketing is for, and that for this reason, there's really no harm in building virtual worlds for people that accomplish nothing -- because really, what kind of idiot would ever expect a Coke-branded virtual world to succeed? -- and not only is there no harm in it, but there's profit in it. But they're wrong. That's not what marketing is for, and collaborating with this type of thing is not good for your career.

The first counterargument to this cynicism is a great book by Henry Hazlitt called Economics In One Lesson. The basic idea of this book is that economic consequences of any decision must be explored not only in terms of what does happen but in terms of what else doesn't happen, that might have happened otherwise. For instance, people think natural disasters benefit some sectors of the economy, because repairing broken windows is good for people who sell glass. What such people are missing is that building new buildings is also good for people who sell glass, and in fact better in the long run, and that any given sum of money can only be spent once. If people are spending it to repair damage caused by natural disasters, they can't invest it in new buildings.

The downside of building an idiotic Pepsi-branded virtual world isn't the virtual world itself; it's also the absence of what else could have been built instead. Likewise the effect of working on such a moronic project isn't just the skills you learn in the process; it's also the skills you don't learn, which you would have if you had been doing something else. And if you believe, with Seth Godin, that new features are marketing, then you need to realize what a tremendous disservice you would be doing for your clients if you built them some abysmally stupid 7-Up-branded virtual world.

The iPhone is the perfect example of new features being a form of marketing because nobody else in the portable mp3 player space or the cellphone space has anything to compete with it. The Danger Sidekick seemed pretty cool before yesterday. It's nothing today. The Zune seemed like it maybe stood a chance in hell before yesterday. Not any more. It's pretty obvious Zune is fucking doomed. This is the kind of product that wipes out entire sectors.

Long story short, don't build retarded Dr. Pepper-branded virtual worlds. They'll fail, and you'll be ashamed of yourself. Build iPhones. And don't build them because it's good for your career. Build them because you can.

Really Good Question

Jason Fried from 37 Signals says of the iPhone, "how do I dial it without looking at it?"

Tuesday, January 9, 2007

Ruby and Smalltalk

OK, so first, my background: lots of Perl, a little Java, working with Ruby on Rails.

That out of the way, I've been playing with Smalltalk, and working with Ruby has definitely been a very useful stepping stone. Ramon Leon told me that Smalltalkers consider Ruby to be Smalltalk--, and Avi Bryant has said that Ruby is essentially a Unix dialect of Smalltalk.

I've only been playing with Ruby for a year, and only working with it professionally for about six months, and I really only began playing with Smalltalk very very recently, but so far, the two big similarities I've noticed are that the blocks in Smalltalk look very, very similar to Ruby blocks, and the object model is also very similar.

The object model in Ruby is a frequent source of confusion. Most of the hype about metaprogramming either comes from Ruby's Lispy features, or from its mysterious object model. But the object model really isn't that mysterious. A class definition is itself an instance of Class. Everything else just flows from that. As simple as this idea is, it's still very counterintuitive to a lot of people coming from other languages. (Including me, to some extent.) The dominant paradigm in OOP is the C++/Java idea where class definitions do not exist as objects themselves, and most OOP implementations -- even Perl's unorthodox and fairly lightweight approach -- conform to this paradigm. But the mechanics of Ruby's OOP paradigm are virtually identical (as far as I can tell) to Smalltalk's idea of a class side and an instance side. In a way, it's very gratifying, because, having wrestled with this a bit, I then found it immediately in the next language I learned.

Anyway, all this makes me sound very clever, so I really should point out that my experiments with Smalltalk have fallen apart a great deal. My grasp on the syntax is still pretty appalling, as I haven't yet taken the time to properly read up on it, and a big part of the reason is that all the books I've found so far are in PDF. I know lots of people prefer PDF, personally, I like something I can read comfortably on a sofa, and PDF just doesn't get the job done there. Also it's a lot harder to scribble in the margins of a PDF. There is one real-world book I'm dying to get, but until then, I still have some stumbling to do.

Learning From Failure

This is an extremely kickass post. Not only is it vitally important for anybody developing software to understand this post, it's also very courageous; how often do you read programmers blogging about their failures? If you're wondering how to make a software project succeed, you need to read this.

Fuck Yes I Want One

Steve Jobs just announced the iPhone at Apple WWDC this morning in San Francisco.

Monday, January 8, 2007

Funniest Ruby Gem Ever

Heckle, from Kevin Clark and Ryan Davis, deliberately modifies your code and then runs your tests to make sure they break. Why? Because if your tests don't break when you change the code, then you don't really have test coverage.

I love the idea of this. It's like having your own little pet gremlin.

Bullshitting The High Notes

Joel Splosky has a neat essay called Hitting The High Notes, explaining why he treats his programmers like stars.

Zed Shaw has an inspired rant called Fortune Favors Big Turds, explaining why he thinks Joel is full of it.

Zed kind of has a bad attitude, but you should read both these things, and then you should keep in mind that while Joel is trying to hit the high notes, with his company's proprietary software, Zed is actually hitting them with his open source project Mongrel.

The argument of Hitting The High Notes is that a great programmer won't just outperform an average one, a great programmer will do things an average one will never even think of. This is a popular idea. One of the great examples, ironically, is Mongrel's extraordinary security. Mongrel outperforms most web servers, including Apache, for security, and the irony here is that Zed didn't even care about security when he was building Mongrel. The security is just a side effect of a good design decision. Zed decided the quickest way to build Mongrel would be to use Ragel to conform exactly to the HTTP spec, and when he did this, he bypassed a huge number of security problems most servers have, which are simply due to inconsistent HTTP parsers. I heard him on a podcast explaining how a security consultant asked him what he had done to make Mongrel so secure, and technically the answer was nothing. He just wrote good code. (And knew what a state machine was.)

I don't have a conclusion for this, and I held off posting it for a long time, but I think it's really interesting, so maybe if anyone reads this, they can reach their own conclusions. I will say this, the contrast here definitely has me very sincerely doubting Joel's hiring process. If you hired Leonardo da Vinci to do anything, you'd probably have him underperforming. I think people who can hit the high notes do best when they decide for themselves what to sing.

The other thing, I guess, is that there's a real underpants gnome quality to Joel's business plan, which is, hire the best programmers, give them the best working conditions, this will automatically lead to the best software, and that will automatically lead to profit. The first problem is that sometimes the best software comes whistling out of left field. The second problem is that sometimes inferior software wins in the marketplace. I think Joel's theory is a great theory if you want to build a great place to work, but as a business plan, it's hit and miss at best.

Meta Schmeta

David Black with a little common sense about the unnecessary glorification of "metaprogramming":

Nothing is gained by putting class_eval on a pedestal and getting all worked up about how “meta” it is. All you have to do is study it a little and then use it when it’s the correct choice for accomplishing what you’re trying to accomplish.

My take on this is that the phenomenon is entirely cultural. A lot of people coming to Ruby are coming from either PHP or Java. I don't know very much about PHP, and this is a very deliberate ignorance, but I wasn't so successful at avoiding Java, and from a Java perspective, Ruby accomodates "normal" OOP, while also giving you all kinds of unaccustomed freedoms. The idea that certain uses of Ruby are "meta" is probably a way of pigeonholing the new stuff. If you call it "metaprogramming," you don't have to learn how to use it; you just put a little velvet rope around it, call it high wizardry, and continue solving problems the way you're used to. In other words, it's a cop-out; a way to keep thinking the same way you did in Java, and essentially write Java in Ruby.

This kind of thing has probably been happening ever since the first time a programmer migrated from one language to another. Everyone knows the Fortran joke. It's actually the reason I have my doubts about Pat Maddox's optimism:

I think a lot of programmers are going to find themselves looking for jobs in the coming years, and not because their jobs are getting sent to India. In fact, fewer and fewer jobs will go to India for the same reason these guys will be out of jobs. In the past, and increasingly less so now, the knowledge of how to configure different frameworks and technologies to play well together was mistaken for the ability to develop. Programming jobs are filled with people who are more admins than developers. With things like Rails obviating the need for these pradministrators, the jobs will go to the guys who know how to build valuable software.

The sad truth of this is that if it were true, Smalltalk would be king, Lisp would be emperor, Microsoft would never have stood a chance against Apple, and Baywatch would never have even taped a single pilot episode. But that's not how it works. Whether due to inertia in the culture of business, or the general proliferation of stupidity, or God knows what reason, the vast majority of people simply do not choose the best technology available to them (as I've said before). If you choose to be something more than a maintenance programmer, or pradministrator as Pat calls them, or adminigrammer, or whatever, that's a great personal choice, a great career choice, an all-around good decision. But expecting all those other idiots to promptly disappear in a puff of logic, it might not be entirely realistic.

Speaking of Fortran, the programming language most used in production environments today is either Fortran or Cobol. Business isn't only about technical elegance; it's also about people, and people are often slow to change. Anybody who's ever had the experience of discovering something marvellous and life-changing which makes everything in their lives better has also shortly thereafter had the astonishing experience of discovering people who don't want to know about it. This is the whole point of the Total Perspective Vortex.

There's a paradox to this. If you take the time to learn "metaprogramming" in Ruby, you will discover how totally it is nothing other than simply programming; and you will also see people just as intelligent as you are calling you a wizard. The thing is, this is the same paradox anybody faces when they think for themselves. It's just the way the world works. The only way to avoid it is to go back to being a sheep.

Stupidest Design Decision Ever

Fucking Apple. Check this out. Pages comes with my MacBook. I use it, because I'm planning to buy Keynote, because Keynote is worth it. I write about 30 pages of a story I'm working on (I write a lot; see my culture blog for more about this sort of thing).

Then I get to a point in the story where I need to make some changes, but I've got some good stuff I'm throwing away, and I'm not sure about throwing it away. As a geek, I know how to solve this kind of thing; it's called version control. So I already have Subversion installed; I set up a repository and I'm good to go. Right?

Wrong. The fucking geniuses at Apple decided that Pages would save its files as .pages/ directories, which means, first, that setting it up under Subversion involves the hidden pitfall that the dir must have the correct name or Pages won't recognize it, and second, the much more serious flaw that every time you make a change, it overwrites your .svn/ subdir, making it impossible to put word processing documents created in Pages under version control with Subversion.

What kind of fucking monkey thought that was a good idea?

What do you bet Keynote has the same problem?

(Update: it does.)

Am I really the only geek in the world who puts other things besides code under version control?


(Note to Apple engineers: nothing personal, but that was some stupid-ass bullshit. Anyway, I apologize for posting in such a furious mood, but I'm not actually taking this post down, because honestly, what the fuck were you thinking?)

Shirky on Second Life

Clay Shirky validating my skepticism.

Wednesday, January 3, 2007

Installing RMagick on OS X

Two links, one bad, one good.
(The bad one's there just so you know better.)

Installing ffmpeg on Mac OS X


23C3 Videos

Straight from boingboing:

Lawrence Lessig
Joi Ito

Google == Overlords

Nice, smart analysis.

Getting Merb Up And Running

OK. So Merb is the new black. If you're wondering how to use it, well, so am I. So I'm installing it and seeing if I can get it going. Here's a couple stumbling blocks you might see if you're in the same position. (This is all for OS X, btw.)

First, the install instructions here are slightly off. You have to edit dist/conf/merb_init.rb, not conf/merb_init.rb. Very minor distinction. Also, you don't do merb start -t, just merb start; merb doesn't seem to recognize -t any more. These instructions are from October, Merb 0.0.3, and the current version is 0.0.8, so there's no blame in this, btw. I'm not even sure I'm looking at the right page. Anyway, I'm pretty sure the point of -t was some kind of backgrounder, like the equivalent of -d with Mongrel.

Luckily, Merb itself is written in Ruby, and pretty easy to find -- merb-0.0.8/bin/merb -- and it uses the popular and very useful OptionParser library. (Dave Walz-Burkett, who runs the Albuquerque Ruby users' group, uses this all the time, so I've seen it before.) The nice thing about OptionParser is that it's got a very readable syntax and for that reason it's effortless to find the command-line options in Merb.

From reading this, it looks as if the backgrounder option is now -d, like in Mongrel, and the reason is it stands for --daemonize. Depending on your Unix background this will either clarify everything or mean nothing, so, well, hope it helped. Anyway, I made a cool little discovery while I was in there hunting this down. It turns out there's also an -i option. Guess what that's shorthand for? --irb-console. Yup. You can run the whole thing in console mode, just like Rails. Very nice.

Anyway, the next stumbling block, and by the way there are very few, this is a very painless process, but the next one is, having gotten the example app running, it doesn't seem to actually do anything except display a picture of a cute little dog.


Cute though this dog is, I know for a fact that displaying its picture is not the upper limit of Merb's capabilities. I know this for two reasons; first, I read a great post on ruby-talk from Ezra Zygmuntowicz, the framework's author, about its purpose -- that is to say, Merb's purpose, not the dog's -- and second, I spoke to him in a conference call with one of my clients about using the framework for parts of my clients' site. Long story short, there's power under the hood here, but either I'm missing something or the example app is really just a "Hello World" so you can say for a fact that your install succeeded.

As far as the power under the hood, basically, Merb means Mongrel plus ERB:

Merb is faster lightweight replacement for ActionPack which is the VC layer for the rails MVC. Merb still uses ActiveRecord for database persistence. But it can also use Og or Mongoose(pure ruby db). It is integrated into mongrel for http serving and has its own controller and view abstraction with sessions filters and erb. It is just a lot smaller and closer to the metal then ActionPack. I wrote it mainly to use in conjusnction with rails applications. To have a small merb app stand in for performance sensative portions of an application.

(From Ezra's post, copied here on my blog.).

Anyway, here's something from the Merb documentation which explains why I'm installing Merb, and what I hope to use it for:

*File uploads* This is one of the things that Merb was written for. Rails doesn‘t allow multiple concurrent file uploads at once without blocking an entire rails backend for each file upload. Merb allows multiple file uploads at once. Start the server and browse to localhost:4000/files/start and you will get a file upload form. This uses the mongrel_upload_progress gem so that must be installed first. There is a very simple upload controller example that handles this upload with a progress bar. When a file is uploaded with Merb, it gets put in a Tempfile. So you just want to copy it to the right place on the filesystem.

And the nice thing about that, it also explains what else the sample app can do. Basically the whole purpose of this is to handle file uploads in a scaleable way. I know the word "scaleable" is not hugely popular in the 37 Signals worldview, but it's something my client needs.

Anyway, this is just an intro, hopefully it's useful.

Tuesday, January 2, 2007

Cool Ad

Courtesy of Boris Popov.


I just got an e-mail from Google asking if I was interested in a job.

Unfortunately, if the answer is yes, that would make me a huge hypocrite, but I must admit I'm curious.

Monday, January 1, 2007

Kickass Intro To Quicksilver Video

If you read about it, you might wonder wtf the point is. Watch this video and you'll understand right away.