Tuesday, July 31, 2007

Collective Code Ownership Discourages The Blame Game

One thing that nobody ever wants to see is people scrambling like terrified rabbits as the wolflike specter of blame approaches.

A lot of workplace dysfunction involves blame. We call it the blame game because it isn't really about blame, it's about getting out of doing stuff. If it's not your fault, you don't have to fix it, right?

Collective code ownership can discourage that kind of dysfunction.

The blame game operates on the principle of social proof. If everybody agrees X is to blame, then it's X's fault. Collective code ownership makes tracking mistakes easier, because more people know what the code looks like from the inside. Social proof is still at work, but it's social proof which originates in analysis of the code base, rather than social proof which originates in subjective impressions of clothing style, body language, or tone of voice.

It's important to realize that the blame game's pathetic, whether you win or lose. People who take responsibility and do good work want to be rewarded for that. They don't want to take responsibility, do good work, and then maybe get lucky and win a popularity contest. If keeping good people is a goal in your organization, collective code ownership is one way to achieve that goal.

Healthy Headscratching: Evan Weaver's RailsConf Slides

These slides of Evan Weaver's RailsConf presentation will provoke some head-scratching, but that's the point.

One interesting thing in the presentation is some code to enable using Django's admin interface as an admin interface for Rails applications.

The strategy is simple: use Django's auto-admin setter-upper, and then change the variables in the Python code which identify the columns to use. Actually implementing this is left as an exercise for the reader, but it's a nice alternative to things like Streamlined.

The most interesting part is the idea that databases are a hack for Web apps.

Monday, July 30, 2007

Ruby By Example: Functional Programming With Ruby

If you dig my blog, you should get this book:

It bills itself as a general introduction, unfortunately that's a marketing mistake. The real subject matter is an introduction to Ruby from a functional programming perspective. This is a huge bonus. There are many books about Ruby that emphasize its OO features, but too few with a clear, succinct, powerful approach to functional programming. You'll likely skip the first few chapters, but still, this is one book you should definitely buy.

Thanks to Clinton Nixon for telling me about it at OSCON!

Sunday, July 29, 2007

Generate Models & Associations From A Legacy Schema

Just for the record, I knew this could be done.

(I suggested it as a possible Advanced Rails Recipe.)

Saturday, July 28, 2007

It Isn't X vs Y

So I hate to admit this, but now that OSCON is over, several days after delivering my presentation on Seaside and Rails, I figured out the actual conclusion.

People have taken my posts on Seaside and Rails as if they were discussions of Seaside vs. Rails. That just isn't the case; in fact it's silly. What it's really about is that there are design differences between these two frameworks, and while I don't think either one is the answer, I do think both are way better than everything else out there that I know about.

Rails' assumption that building REST into your app at such a level that APIs are almost auto-generated by default is the right way to do things; Seaside's decision to give Web app developers the same kind of power that desktop developers have is also the right way to do things.

When you look at Rubinius, it's entirely possible Avi Bryant's hypothetical Ruby virtual machine could in fact happen very soon. At that point, features of Seaside which were previously only available via Smalltalk will become available to Rails. At the same time, Gemstone is doing work to make Seaside applications much easier to deploy. Object databases like Gemstone's are pretty much necessary if you want to handle particular problem spaces, such as warehousing and inventory systems. Object DBs already exist for Java, so JRuby will make object databases available to Rails applications, which means you could use Rails for gigantic enterprise problems suited to object DBs. But if you did that, you'd need to rewrite ActiveRecord, since object databases give you active records by definition.

Basically, I'm indulging in some amateur futurism here, and there's lots of interesting things happening on that horizon.

Friday, July 27, 2007

Ola Bini's JRuby Slides Online

One of the best presentations I saw this week at OSCON wasn't even part of the official O'Reilly
event. It was Ola Bini's presentation at FOSCON on JRuby. JRuby is 100% ready for prime time, and JRuby on Rails is more scalable than Ruby on Rails itself. The typical Rails installation tightly couples Rails instances to Mongrel instances in a cluster - they're essentially the same thing (although this can change if you use multi-threaded Mongrel instances with Swiftiply). A JRuby on Rails installation adds new JRoR instances in new JVMs, or the same JVM, and new servers are decoupled from that.

Definitely check out the slides.

Thursday, July 26, 2007


I ran into Tim O'Reilly at OSCON and had a question for him: Is it true that OSCON's held in Portland because of Powell's, the biggest bookstore in the US (and probably the best technical bookstore in the world)?

And he said no.

(The alternate theory is that OSCON's held in Portland because Portland has the highest number of strip clubs per capita of any city in the US. I didn't actually ask him about that one.)

"Time Management for System Administrators" Book and Tutorial Notes

Bought the book after the OSCON tutorial.

I dig it.

Here are my notes:

One system
Conserve brain power
Use routines
Same tools everywhere

Identify your peak time for focus
Use the first hour for high-priority tasks (because everybody else is reading their e-mail)

Always *acknowledge* requests immediately whether or not you can act on them

Record it OR
Delegate it OR
Do it

Active listening - confirm your interpretation
Scheduling is like a hug - it confirms that people matter

Written emergency policy
Written escalation policy

Without a ticket tracker, you need manual tickets
Solution: Trac? NO! Don't use bug-tracking software for ticket-tracking. Different things.

American English/British English as metaphor for nontechnical/technical communication

Turn chaos into routines:
- Buy gas every Sunday
- Schedule key meetings/regular schedule
- Routinize everything you frequently forget

System administration is like gardening

A routine is like a cron job

Habits: hesitate before you hit enter
- Run commands as echo statements first
- Test before coding
- Ping b4 & after disconnecting any cable
- Always backup file b4 editing (version control)

Fire drill:
- Automated random restore request ticket
- Awesome

To-do lists about perfect followthrough
Long-term and life goals: get where you want to be

Zillions of scattered notes: bad
Never-ending list of doom: bad

One to-do list each day
All in one place (vi, PDA, notebook, Franklin, whatever)
Easy to access

x Done
- Moved (record when)
NO Refused (record why)
. Delegated (record who)

<5/23> More info on page for May 23rd

A/B/C - Have to/should/don't

Each morning, routine: check As, check meetings, figure how much time, add Bs and/or Cs if possible

Four pm each day - recheck committments for the day. Contact stakeholders by phone if delayed.

If it has to be done every day, do it first.

Anything which could grow into a huge task, schedule it to the end of the day. That way you get other stuff done first.

Start every day by planning.

Schedule fun things as well as work things.

Unsuccessful people assume opportunities appear. Successful people write down opportunities that they want to see.

Category: | Goal: | Actions:

1 Month
1 Year
5 Years

(chart for graphing next actions on long-term/lifetime goals)

IP address list, like in a bagel place or a butcher's

Work on life goals 5 min each morning
THEN plan the work for the day

End of day - check back in with scheduling system


Why RailsConf's Fundraising Effort Succeeded

I wrote this in an e-mail to somebody today:

...competition between open source communities was the absolute core of RailsConf's fundraising effort. Chad Fowler introduced the idea by bringing up the fact that many people in other open source communities perceive people in the Rails community as kind of arrogant, because we all think Rails is so much better than everything else. He was saying, let's show everybody that we're not about being better than other people, we're about making the world a better place. It was very much about answering the question, what do we want the other open source communities to think that the Rails community is about? The reality is, all open source projects are about making the world a better place - they're all driven by volunteers doing work for free which benefits lots of other people - so in a sense a lot of competition between open source communities is already about who's doing the best volunteer work. It's kind of a strange way to look at it, but it's being able to see a new way to look at something that enables you to do something people haven't done before, which is why RailsConf was able to raise such a massive amount for charity. Friendly competition between open source communities was the driver of RailsConf's fundraising success.

Kind of didn't realize it until I wrote it.

Wednesday, July 25, 2007

Liveblogging JavaScript Performance / Yahoo Performance Sessions From OSCON 07

500K = practical upper limit of JavaScript

Write less code
- Profile
- Minimize

Load it as late as you can
- Bundle

Work hard now to be lazy later

Draw UI as late as possible
Never pre-draw hidden UI
- Including loading relevant JavaScript

CSS very top of your page
JavaScript very bottom of your page

Load your app in stages

Always want to show a quick response acknowledgement
- UI should RESPOND quickly even if it can't RESPOND quickly

onmousedown feels a lot faster

All data requests should go to data-manager code which knows whether or not a network request is actually necessary.

Use range caches; only fill in missing pieces.

Balance local updates vs. re-fetching from APIs

Perf optimization as much about APPEARING fast as being fast

Be pragmatic: do the wrong thing if it has a better result

Cheat when it works for you
- Slow app theoretically more extensible in future not actually useful

Firebug == Tivo

Bottlenecks abound and are usually not obvious

Browsers bog down - restart for consistent benchmarks
Firebug Profiler

Don't be clever
- Consider when it is and isn't worthwhile

Browser more like mobile phone than desktop

Small, quick-loading pages with Ajax interactions is best

Eat your own dog food
- (Getting Real: build apps you actually want and need)

//////////////Yahoo Web Performance Session

14 Rules

Exceptional Performance Team

5% of "loadtime" is HTML - 95% is everything else (CSS, images, JavaScript, etc.)

80%-90% of end-user response time is spent on the front end. Start there.

Far-future expires header on Web server.

25-50% improvements

1. Make fewer HTTP requests
2. Use a CDN (Content Delivery Network)
3. Add an Expires header
4. Gzip components
5. Put stylesheets at the top
6. Move scripts to the bottom
7. Avoid CSS expressions
8. Make JS and CSS external
9. Reduce DNS lookups
10. Minify JS
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags
14. Make Ajax cacheable

(Roughly in order of priority.)

Get a clear idea of how users use your site and specific pages

images "sprites" ?

Book coming from O'Reilly with whippet or greyhound or something

YUI blog
YDN blog

YSlow will be open source

Response time and page weight very strongly correlated
YSlow doesn't track response time, but YSlow grade and response time strongly correlated

IBM Page Detailer

Avoid The Free Food At Conferences

Trust me.

Tim O'Reilly's Keynote: Some Livebloggy Notes

Tim O'Reilly:

Owning your personal identity/data:

"There's a race to own these things, and therefore, there needs to be a race to open them."

The Open Genome Project was doing that for genetics; OpenID is racing to keep identity open.

Of course Congress needs version control.

Tim O'Reilly said that Ruby on Rails has only had 14 contributors. I think he means COMMITTERS. Rails had over 100 contributors in 2006, when I went to Canada on Rails, and it's EXTREMELY likely that the number has grown since then, rather than shrunk.

New platforms: Web 2.0, like open source, is all about leveraging network effects.

Open source business model - Stumbleupon sold to eBay for millions, a Firefox plugin, open source, sold their user base (essentially).

Openads - open source ad network builder.

memcached - open source infrastructure.

Hadoop - open source version of Google filesystem. Extremely cool. Yahoo's getting behind it. David Filo called Tim O to talk about it (no detail! arrgh!).

Open source hardware: new frontier.

Nat Torkington is right now announcing that O'Reilly is soliciting donations for charities, just as we did at RailsConf. That was my idea! W00t w00t. (Obviously it was really RailsConf's idea. But I e-mailed Nat and got him into it.)

As thrilling as that is to a dork who actually cares (e.g., me), I have to say, I don't know if they're going to be able to do it. They really pushed it at RailsConf, and the community there was one community with a very cohesive sense of identity. They're not pushing it as hard here, and the community here is much less united. There was a lot of one thing there; there's a little of everything here.

Now Simon Peyton-Jones is talking about task parallelism. SPJ is extremely smart, and quite funny in a very dry, eccentric English way. I had dinner with him and Andy Gill (another big Haskell guy). Pretty much everything went over my head but it was very interesting. He's talking about a method of handling task parallelism (optimistic concurrency) which massively simplifies its hard problems.

JRuby Is Ready For Prime Time

This is huge news. The JRuby team is kicking ass. If you want to deploy a JRuby app in the context of some mega-corp enterprise system, you can do that today. And JRuby scales in a much better way than regular Ruby on Rails.

More coming soonish.

Monday, July 23, 2007

The Business Advantage of Rails

It's important to realize that the greatest strength of Rails is not what but who. Rails places huge emphasis on making programmers happy. What makes programmers happy? Elegant systems which make them productive and take tiresome, tedious bullshit out of their daily lives. People who value that are the people you want to hire.

The technology you choose will shape the people you hire, and the people you hire will shape your culture. People who get tiresome, tedious bullshit out of their way forever are great people to work with. Conversely, tolerating tiresome, tedious bullshit without ever fixing it is absolutely not a character trait you want your hiring process to be biased in favor of. Think about the effect that this decision has on your corporate culture. You want to bias your corporate culture against wasting time, and against putting up with problems that could be solved gracefully and easily. It is infinitely easier to bias your organization's culture in favor of these traits by hiring Rails programmers than it is to filter Java programmers for those same traits (for example).

Joel Spolsky's hiring rule is "Smart and Gets Things Done". The implicit hiring rule if you're hiring a Rails programmer is "Smart, Gets Things Done, and Is Happy." This is very very much better, as a hiring rule. The reasons are utterly simple. Interacting with other people is a huge part of working. Corporate politics are inevitable, because politics is really just the art of getting people to agree on what they're going to do. But even though corporate politics are inevitable, dysfunctional corporate politics are not. The politics of happy people are infinitely preferable to the politics of unhappy people.

It sounds touchy-feely but "Is Happy" should be a hiring priority right up there with "Smart" and "Gets Things Done", and Rails is one way to make that happen. Programmer happiness is a guiding design principle in both Ruby and Rails. One reason people work with Rails is because they value their own happiness. If everybody you hire prioritizes their own happiness, the corporate culture which results will probably be a healthy one. If you want to get something done, give it to the busiest person you know; if you want the process to be fun, make sure the busiest person you know is also somebody very happy.

Sunday, July 22, 2007

Ultimate Idiotic Productivity Boost: Auto-Generate Pasties From IRB

This Pastie was auto-generated with itself.

It's so meta I can feel my head caving in.

The clipboard code comes from Projectionist. If you put this code in your .irbrc file, you can do the following:

1. Copy some code you like in a TextMate window
2. Type the word "pastie" in a Terminal window running irb
3. Have the URL for that Pastie in your clipboard

If you use Pastie a lot, and you're on OS X, you'll find this absurdly handy. For the truly impatient, add one more line:

alias :p :pastie

Note that this will kill the normal built-in p alias for puts, so don't do it unless you're feeling reckless. You can always do this instead:

alias :pst :pastie

Naughty Capistrano

Use at your own risk. Code responsibly. This is a little code recipe you probably shouldn't follow. It's a Capistrano recipe which defines a little

cap deploy:my_naughty_app

command. When you run this recipe, you'll deploy your new code and restart your Mongrel cluster, after first clearing your image and HTML caches.

So far, not actually so naughty. Seems like a regular law-abiding citizen.

The naughtiness starts when we get to the Unix command handling. First of all, the cache clearing is done with an explicit rm -rf. There's a Ruby rm_rf method somewhere in Capistrano that you should use instead, but I got lazy. Secondly, and more dangerously, the code uses a little helper method to enable you to go ahead with your recipe even if a Unix command within it fails. The danger there is putting something crucial in the failproofed section. (Bad thing, don't do it.)

The usefulness is that you could conceivably deploy right after clearing your cache, or conceivably start a Mongrel cluster on a new server that's never been running before. Depending how frequently you're doing that, and how many other people besides yourself are using your Cap recipes - and how fully they understand your backend system - it's a real practical concern.

The standard method for invoking commands on remote servers in Cap is invoke_command. But invoke_command throws an exception on failure, bringing the whole deployment to a halt. The helper method in the recipe gives you the option to reserve that level of response for mission-critical Unix commands. (It also demonstrates that since Capistrano recipes are written in Ruby, helper methods are easy and useful to add.)

Little Rails Image Caching Caveat

If you want to serve a jpg from a database with a url like:


...you can do that, sending jpegs from jpegs_controller.rb with send_data, but if you then do something like:

caches_page :heres_a_jpeg

...then Rails will assume you're serving HTML instead of jpegs, because it doesn't know any better, since you haven't told it.

In my case, I didn't notice at first. What I did notice is that my jpegs started looking terrible. I did a manual export in the Rails console with something like:

File.open("picture.jpg", "w") {|pic| pic << Image.find(:first).data}

...and then from the OS X Unix command line:

open picture.jpg

...and the pic was gorgeous.

What was happening is that when Rails cached my images with .html extensions, it corrupted the images. Some subtle snafu in the MIME type translation process, maybe.

Fortunately all this is easy to fix: just set your routes to assume a .jpg extension from that heres_a_jpeg action, and make sure your URLs pointing to that action all end in .jpg. Then Rails will cache it properly and no problem at all.

Saturday, July 21, 2007

FOSCON 2007: Making Music With Ruby

OK - I'm also making a brief (ten-minute) presentation at FOSCON in Portland next week on using Ruby to make music. Should be all kinds of fun.

Friday, July 20, 2007

Political Pedantry

I've been seeing stuff like this a lot:

Bush Abolishes Fifth Amendment

That's actually inaccurate. An accurate version would be "Bush Violates Fifth Amendment." The distinction is very important. The Constitution is the first law of the land. Any law which contradicts it is invalid. Any action which violates it is illegal. Bush can violate the Fifth Amendment, but he cannot actually abolish it.

Total semantic distinction, but one worth remembering.


Going crazy at work getting things ready for my absence, but stoked for this conf. Just thought I'd mention it. Mega looking forward to my presentation, and to tutorials and presentations on Rails, Haskell, Perl, all kinds of stuff.

Update: Avi Bryant's doing his Web Heresies talk!!!!!!!!!

Update 2: No he isn't. I'm a monkey.

Sunday, July 15, 2007

Smalltalk, Outside The Ivory Tower?

If you went to RailsConf, you saw Avi Bryant explain how Ruby can be seen as essentially just a Unix dialect of Smalltalk.

It's a meme. You can see an example of the same idea on Ramon Leon's blog, and in this quote from Kent Beck:

I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby.

One way to look at the Ruby on Rails success story is to say that constraining Smalltalk within a virtual machine trapped it. By transferring Smalltalk to a Unix environment, Ruby let the genie out of the bottle. The minute Smalltalk left the confines of its virtual-machine ivory tower, it turned out to be not the doddering academic many people had remembered it as - and indeed forgotten it as - but instead an elderly kung fu badass, like a dude from a 70s movie who can still kick the crap out of thirty different people at once when he's in his 70s.

Not this:

Bueller? Bueller? Anyone?

But this:

Smalltalk definitely contained ideas so powerful that you could change the world forever by commercializing them.

Maybe that's still the case.

There's just one problem with this idea, however: Matz himself might not agree with it. The creator of Ruby named Ruby after Perl, and has said he wanted a language "more powerful than Perl and more object-oriented than Python." Matz' comments in a recent discussion about Ruby's block syntax on the ruby-talk list referenced CLU, not Smalltalk, even though Smalltalk's blocks have a lot in common with Ruby's.

One thing I'm sure of, however: writing Smalltalk will make you a better Ruby programmer, even when you're still just barely making sense of it in your tiny fragments of spare time. The need for small, concise, atomic methods becomes not just clearer to understand but simpler to satisfy.

How To Talk To Your Boss: Corporations And Small Companies

I've worked for huge corporations and tiny firms, and whenever I switch from one to the other I have to do a certain amount of unlearning and re-learning when it comes to social habits.

With a corporation, you should only tell your boss about success you've attained or problems you need him to solve. This is because corporate managers deal mainly in delegations, introductions, and schedules. If you tell a corporate manager about a problem only you can solve, he/she will think, ah, they're telling me about a problem they have, I don't know how to solve it, so I'll delegate this to XYZ person. Then you end up with XYZ person tripping all over the problem space, trying to figure it out, while you try to implement the solution.

You could have thought, aha, here's my manager, I'll just keep them up to date, but if you don't keep them up to date in the right way, your schedule could be compromised by their very attempt to help. Many people respond to this by blaming the manager, but that's because the tech culture has a very irresponsible attitude towards communication. If you're on schedule, you say something to somebody, and now you're off schedule, that's your doing.

Now conversely, with a small business, you need to justify your time. Small businesses are more budget-conscious. This is true even for prosperous businesses on expensive projects with well-funded clients; it's not a matter of being on a budget per se, but of focus. Large corporations aim for economies of scale. Small businesses aim for efficiency. This is why innovations always come first from small companies. It also means your client or manager will need a different level of detail.

Small companies also have much smaller social networks, so your higher-up will not be thinking in terms of, is this under control or do I need to do some delegating or make some introductions? Your boss, or client, or whomever, is going to be thinking more in terms of, is this done, and how long will it take, and what steps remain? (Also, if you charge a hefty rate, your client may want to be sure you're not doing anything simple or basic that they could offload to one of their more affordable people.)

It's important to keep this in mind. Talking to a corporate manager the way you talk to a small business owner results in the corporate manager thinking you're overwhelmed and don't know what you're doing. Talking to a small business owner the way you talk to a corporate manager results in the small business owner thinking you're self-important and wasting time. (And this is, of course, assuming in either case optimal corporate managers and optimal small business owners. Any dysfunctions in either case can of course mean further compounded communication errors.)

Update: somebody cursed me passionately on reddit for my comment about innovations always coming from small companies. They seemed like they were foaming at the mouth, but they had a point. They mentioned 3M, and Apple's another big company famous for innovating. But there's definitely quicker adoption of innovations among smaller companies.

Wednesday, July 11, 2007

Haml Looks Very Familiar To Seaside Coders

HAML is sweeping the rails world like a wildfire of chicken, and everyone wants the biggest piece.

New Web Framework in Lisp


The framework is similar in spirit to UCW and Seaside. It is heavily based on widgets. I probably would have ended up using Seaside if Smalltalk supported multiple method dispatch and didn't force me out of Emacs. I didn't use UCW because of a serious attack of a "Not Invented Here" syndrome.

I did not yet implement modal requests. When I do I will likely not use continuations. I have a pretty good idea on how to achieve modal programming style with coroutines.

I make very heavy use of closures and multiple dispatch. Some parts of the framework also put more esoteric features of CLOS and MOP to the test. I use introspection heavily to generate HTML - I couldn't stand using template engines anymore so I wrote code that does the dirty work for me. Macros are put to very heavy use via Edi Weitz's excellent CL-WHO. I suspect I'll use them heavily to implement coroutines.

Serving Rails On OS X Over An Internal Network

This post's kinda noob-oriented, but hey, noobs need love too.

According to Western astrology, there's this thing called Mercury retrograde. During Mercury retrograde, messages are jumbled, meanings are confused, and computers break. Currently, we're in a period of Mercury retrograde.

Whether Mercury retrograde really exists or not, computers have been breaking a lot recently in my neck of the woods. Just as soon as I brought one app back to life following a total hardware meltdown, the server for the app I'm developing started throwing crazy errors, with hundreds of sleeping httpd threads for no known reason.

I'm at a large company and all authority for this machine rests with other people. Meanwhile, I've got an app to develop, and people need to be able to see it over the network. The obvious logical choice here is to give them my IP address - but first I have to knock out the OS X firewall. Doing this is very easy.

Go to System Preferences, go to Sharing, and go to Firewall. Hit New, and specify a service called Rails which runs on port 3000. (You can specify a range of port numbers if necessary.)

While I was in there, I set up a Seaside "service" as well on port 8080.

Then go back to System Preferences and hit Network. The first thing you see should be your Network Status. If you're connected via Ethernet, you've got your IP address on the same screen. If you're connected via Airport, click TCP/IP.

Easy - even when the planets aren't in the right alignment.

And All The Little People

Monday, July 9, 2007

Blocks vs. Procs in Ruby

It's one of the weird questions - when do you use a Proc instead of a block, and why? A discussion on the ruby-talk list about alternate block semantics in future versions of Ruby included comments from Charles Oliver Nutter of the JRuby project, which cleared things up for me:

yield is a keyword whose function depends on having access to the current call frame. Since any method you might define and call would execute in a new call frame, there's no way to provide a method that does what yield does. This is why if you ever want to pass a given block to another method, you must capture it in a block argument, and also why yielding to a block is much faster than calling a proc (since there's less overhead in yielding than in calling a free-standing proc).

My conclusion: favor blocks over Procs. I don't quite understand everything here, but the implication is that calling a free-standing Proc requires getting a different call frame, while yielding requies the call frame that you already have. This means that working with blocks fits the natural flow of the language better than working with Procs.

Sunday, July 8, 2007

How Would You Automate Graffiti?

I love graffiti. With the vinyl toys phenomenon, graf in art galleries, and artists in corporate ads, graffiti's recently attained the very mixed blessing of respectability.

Little thought experiment: if you were going to automate graffiti, how would you do it?

Here's how I imagine I would handle one particular key component - generating the actual letters, and the permutations those letters can take.

Yep, those are letters.

These are letters too:

(They say "Sucka Free City.")

My hypothetical code would open up a font, extract its vectors, and define each letter in the font as its own Ruby class, with its vectors defined as class attributes. I'd also write a base class these classes would inherit from. The base class would include some math in initialize() to generate permutations in the forms defined by the vectors. The math would probably use fractals in a not-obvious way.

Then you'd have a method draw() which took a string and turned each character into a unique permutation on an existing font.


And then you'd have to figure out how to do the colors.

Politics Considered Inevitable

Raganwald says:

Shipping software on time was and is a very hard problem. Actually, there are two hard problems involved. The first is knowing how to plan and manage development. The second is convincing stake holders that your plan is optimal and that any interference on their part—be it feature creep, dictating overtime, advancing the ship date, whatever—will make things worse. Please don’t consider the second part as me just trying to make a funny to capture your interest. It is a very hard problem in the real world.

There's a great book called Ship It! which is my favorite resource for this general problem. I prefer to focus on infrastructure, rather than management. I really don't know how to plan a project, not in any official sense, but I do know how to set up a project so that developers can work at their maximum possible productivity while ensuring their mistakes have the minimum possible consequences.

The specific subset of the problem emphasized here, though, is a pretty thorny one. It can range from a minor hurdle to a towering obstacle. It's essentially a political problem. It'll depend on your reputation, your luck, your organization's culture, and, in a few Dilbert-office cases, the personal day-to-day emotional lives and whims of the stakeholders in question. Developing a plan which really is optimal and really can't be improved by interference from stakeholders outside the project is definitely a less nebulous problem than convincing such stakeholders that you've done it, once you actually have.

The only book I know that really addresses these topics is Machiavelli's The Prince, which I haven't read since high school. (And of course the entire Dilbert ouevre.)

I do, at least, know one very good, very simple way to convince your superiors in an organization that your plan is golden: establish a kickass track record somewhere else, and if they question your plans, simply refuse to even discuss it. The downside to this method is that it basically draws a line in the sand, which makes it crazy overkill in most cases. The more subtle art of building buy-in from your stakeholders isn't really documented anywhere, but I'll agree with Raganwald, it's important, and it's far from effortless.

It's really a more general problem: how do you manage a team of people who speak one language, while working for a team of people who speak another? There's an ancient saying in Latin which means "Translators are traitors." It comes from the fact that the two words, in Latin, are nearly identical, but there's a modern equivalent. You've seen it if you watched the first season of "The Sopranos," when Tony Soprano sat down in his daughter's college and looked up to see the words of Nathaniel Hawthorne behind him:

No man for any considerable period can wear one face to himself and another to the multitude, without finally getting bewildered as to which may be the true.

Programmers should avoid modeling their social skills in the workplace on Tony Soprano's methods of dealing with stakeholders, co-workers, and competitors. But the essential problem, of being able to speak in business terms to business people and technical terms to technical people, is a problem which challenges anybody who puts one foot in each world. After a while, you wonder which world is home.

Planning for software requires equal parts planning for artists, in that you have to accomodate bursts of creativity offset by periods of no progress where people think about problems in the shower; planning in the usual corporate sense, in that you have to get people together and make sure they understand each other; and planning in the style of building a house, in that different kinds of interoperating systems will be built, by different kinds of people, and also in that a project without version control and automated testing is as secure as a house built without a foundation. Finally, once you meet all these requirements, you then need to defend your delicate balance from people who love to poke Jenga towers to see what they'll do.

I think the best thing to do in the event of Jenga-poking is to assume it will happen, and plan accordingly. I recently started on a project which had no version control. The first thing I did, I downloaded all the code and got someone to set up a Subversion repository. Literally a few days later, the entire system hit a hardware failure, and my manual backup was the only copy of the code we had access to. I hadn't anticipated that; I just saw the absence of version control and went on autopilot. It's just reflex - you see a system without version control, you add version control. Like spotting dirty dishes in the sink, you know what to do and it doesn't take long. Preparing for Jenga-pokers and their mischief should probably be as automatic and as reflexive. Expect interference, and have a recovery system in place for when it occurs.

What that recovery system should actually be, though, I don't know. That's the real question.

Friday, July 6, 2007

Quick Blogs Roundup: Boing Boing and Coding Horror

Favorite new posts:

Coding Horror: Technology Backlash
Coding Horror: Avoiding Walled Gardens
Boing Boing offsite link: Copyright Office says unlocking phones is legal
Boing Boing: Sicko Audience Response in Texas
Boing Boing: iPhone Swiftly Unlocked

Just a note - the walled gardens thing - the counterpoint to it is that what happened to Kathy Sierra's blog is a great argument in favor of walled gardens. I have no doubt that a writer as prolific as Kathy is still writing - we just don't get to see it any more.

How To Use Rails Migrations From The Console

Sometimes you want to run a Rails migration in only one environment. Say for the sake of argument you have a messy legacy app and you need to add database sessions immediately, without going into the cleanup you have to do on the development environment side.

There's probably a more elegant way to do this, but this is the quick and dirty shortcut.

(Got the idea from the Rails wiki.)

RailsForge: If You Have To Ask

What is jazz? Man, if you have to ask, you'll never know.

- John Coltrane, responding to a reporter

A classic line in software development is that it's better to beg forgiveness than ask for permission. There's a new site on the web called RailsForge, intended as a Rails equivalent to RubyForge. RailsForge's first step is to ask the community, "should we exist?"

My prediction is that a whole ton of discouragement will be headed their way. Any time you ask permission without even giving people something concrete to evaluate your proposal with, the inevitable result is not just negativity, but often irrelevant negativity. Since you're not giving people anything concrete to respond to, they're responding to what they imagine you might do.

Likewise, since you're not giving people anything concrete to respond to, you usually don't get any responses from busy people, who are usually the source of the most useful responses. I don't mean to sound grumpy or self-important, but busy people often have more common sense than to evaluate hypotheticals when there's so much real stuff to do.

Starting something which fails sucks, but putting your toe in the water is just silly. Do it, or don't do it. Asking for comments when there's nothing to comment on just leads to divisive arguments at worst and being ignored at best. After all, starting something which fails might suck, but it sucks a lot less than never doing anything because nobody ever gave you permission.

And check out this book:

Verily and forsooth, it is nifty.

Wednesday, July 4, 2007


I have a tattoo of the Decepticon logo on my arm. I've had it there for about ten years. I got excited when I heard they were making a movie, even though I knew it would be a mixed blessing.

Michael Bay's made some really bad movies. He's also had a couple hits: Bad Boys, Bad Boys 2, and The Rock. The way the movie industry works, this means lots of people are still willing to gamble on him.

The funny thing about Michael Bay is that people will probably start to use him as anectodal evidence that Hollywood underestimates the importance of screenwriting. The Rock in particular already shows up in screenwriting books as an example of how to write a great screenplay. I've watched one sequence in The Rock at least ten times - the half-hour stretch from Sean Connery's initial onscreen appearance, to his escape in San Francisco, to his eventual recapture. It's one of the best examples you'll ever find of character and action being perfectly intertwined, so much so as to become almost indistinguishable. It's so good that instead of watching the rest of the movie, when it's over, I just rewind and watch that particular sequence again.

But the big irony of The Rock is that its fundamentally anti-governmental, anti-militaristic story, peopled with characters brutally wronged by evil men in positions of undeserved authority, plays out against the backdrop of flag-waving jingoism that boggles the mind with its sheer baldness. There's a contrast there, a stark contrast between the imagery and the script, between the theme and the visual backdrop, and when you count all the American flags, military vehicles, heroic soldiers, and respectable Presidents in Michael Bay's other movies, it's pretty easy to guess where that contrast comes from. You kind of even have to wonder why he bothers making movies at all. He seems like he'd be much happier working for the Pentagon.

This obsession dominates the new Transformers movie, so much so that an Australian signal-processing expert who works for the Pentagon, looks like a supermodel, and dresses like a horny teenager gets more screen time than Optimus Prime. The actress who actually plays a horny teenager gets more screen time than all the Transformers combined. She even gets a scene which is supposed to play like an old-school nudge-nudge-wink-wink 60s sex comedy, but instead just comes off as pornographic.

I can't blame Michael Bay for being into hot chicks, but that's one of the perks of being a director: if you have any game at all, you can fuck the hot chicks who work for you, and then when it's time to make the fucking movie, you can get over it and make the fucking movie.

It's like, yeah, she's sexy, sexy is good, but we paid to see giant robots, for fuck's sake. As sexy as she is, she is neither giant nor a robot. It's like you go to get a gourmet meal and they give you a Picasso. That's great, Picasso, who can complain, but it's not like you can snack on a painting. Staring at Megan Fox partially undressed is definitely entertaining, but it's not entertaining in the same way that seeing giant robots is entertaining, and we paid to see giant robots.

What's really silly about all this is that even when we do get to see giant robots, they aren't the giant robots we know and love. Even though there are still people doing amazing work with the original Transformers characters.

The Dreamwave comics are fucking gorgeous.

More importantly, they're clearly the work of people who loved the original series.

You have to wonder about that. For the movie, they threw away the designs of the original series, and even many of the most popular characters. Bumbleebee isn't even recognizable as Bumblebee. Optimus Prime might look different, but he's still basically the same guy. Bumblebee is just a different character who happens to have the same name and the same color paint. Why would they even do that? People aren't going to see Transformers because they loved Armageddon. They're going to see Transformers because they loved Transformers.

The standard answer is, "That's Hollywood," except the truth is, it's not Hollywood. I'm obviously kind of going to town on Michael Bay here, but it's not Michael Bay in my opinion. In fact the movie's got some straight-up evil government characters who the Autobots literally piss on, so if anything I'm being unfair to Michael Bay here.

For years, I've kept up to date on Transformers by lingering in toy aisles at Walgreens and googling Transformers on eBay. Pathetic? Probably. But here's what I learned: Hasbro has been doing this for years.

When Dreamwave released their Transformers limited series about five years ago, it blew up in terms of popularity. It was way more popular than anticipated, and Dreamwave quickly got a deal from Hasbro to do a real ongoing series. (Comics have limited series and regular series, kind of like a mini-series and actual show on TV.) But when they launched the ongoing series, they also launched a series using new characters with new designs as well, corresponding to the toys that were in stores at the time. It was so lame it would actually make you limp if you read it. Just looking at the covers could paralyze your leg.

I'm pretty sure they had to do that shit series as a condition of their deal with Hasbro to do the real series as well.

Meanwhile, over in Japan, where the Transformers are owned by Takara - the company that originally designed them - there's no shortage of toys celebrating the original designs.

Hasbro changes the designs every year because even after twenty years, they just can't admit how much they suck compared to Takara.

Everybody who knows what Creative Commons is, or has heard the Negativland U2 story, knows that corporate ownership of intellectual property limits the potential of culture at large. It's pretty obvious that this usually happens because a corporation wants to retain or exert some kind of power. The "insidious corporations" angle on that kind of thing is obvious, and if you pay any attention to copyright debates on the Web, the "insidious corporations" angle is so obvious and overplayed that it's almost a little tiresome. It's like, yeah, corporations, evil, yadda yadda yadda. We got it already.

The reality is that corporations can be evil, but in Hasbro's case at least, they're often just petty, insecure and disappointing. If there's any argument for overturning copyright law, it's that it's illegal to make a Transformers movie without Hasbro's approval, despite the fact that Hasbro itself doesn't respect the original characters and designs, or the passion that those original characters and designs evoke in the legions of nerds like me who have attached all kinds of personal significance to them. I mean think about it - my tattoo is probably illegal. My tattoo probably qualifies as trademark dilution. If Hasbro sued me to have it forcibly removed, under current US law, they'd probably win.

The Transformers shouldn't belong to people who resent their success because it makes them look inferior to the Japanese company they are in fact totally inferior to. The Transformers should belong to the people who love them. If they did, the new Transformers movie would be a much better movie.

It's still lots of fun, though, at least the first half. Go.

Sunday, July 1, 2007


So I'm not in Los Angeles or New Mexico right now; I'm in the Bay Area.

The Bay Area's a great place to live. I've lived here before - about six or seven years total, mostly in my twenties, when my life was all about music (and a mistaken idea that building Web sites would change the world).

But I'm not partying now. I'm working for a big big company, maintaining code somebody else wrote.

Maintaining somebody else's code base often involves cleaning it up.

Of course there's always the adorable little bugs to fix.

And then there's always the bug that turns out to be a little fiercer than you'd expected.

In my case the underestimated bug wasn't really a bug at all; it was an architectural issue with the application's deployment. An RMagick-intensive application storing all its image data on the server's hard drive hit the limit of its storage capacity and fried the entire filesystem. We had to send the hard drive to a retrieval facility to recover the data. Worse yet, I'm the sole programmer on the project, and the issue never happened before, so, to a lot of people, the whole thing looked like my fault.

Of course it really isn't about fault. The original developer knew the architectural issues were there; he just didn't anticipate how big the site would get, or how fast. It was a victim of its own success.

And there's a flipside to this, and it's pretty cool.

In fact it's awesome. Like a high level of awesome. Japanese lowrider awesome.

Whether I avoid scapegoating or not, it's definite that people in this Big Big Company have realized they have a very compelling interest in bringing their Rails infrastructure in house. Big Big Company really is a big big company - so big that if I told you who it was, I'd be overstepping my rank in the corporate militia (as it were). If/when BigBigCo brings its Rails infrastructure in house, the fact that BigBigCo has in-house Rails infrastructure will itself become newsworthy for the Rails community. (Not Capistrano 2 newsworthy, but more newsworthy than some things you hear about.)

So, I've been working crazy hard and it's not over yet. I know some of my readers seriously dig this blog, and I'm hella flattered by that, but the blog's still going to be slow for a bit. Stay tuned, though. Maybe, just maybe, things will get very cool. Like Daim on a truck cool.

(PS: Although my blog's slowed down, my tumblelog's speeding up.)