Fearless Play. Or, What We Did in 2007

Posted by amy on January 01, 2008

This morning I just rediscovered a year-old post on James Gray’s (of Textmate: Power Editing for the Mac fame) blog, in which he answers the question “How do you get so much done?”

I can’t tell you how often I see people say things like, “I’m not really qualified to do that,” or similar excuses. Oh hell, neither am I, but I wouldn’t let a little thing like that stop me! You learn as you go, you drag in the help you need, or whatever. Passion will conquer so care enough to have some. Be the driving force and the rest will take care of itself.

He fingers both fearlessness and passion as important to getting things done.
Me, I don’t much care for passion. I distrust passion. Except, as I pointed out in August, as regards cheese:

I still think passion is overrated, though. Except where cheese is concerned. I am passionate about cheese. For example, this Vermont Brie is really fantastic. If only someone would make a truly artisan domestic parm…! But I digress…

I like interest, friendship, love, playfulness, curiosity, satisfaction, absorption, and joy. Maybe that’s because passion implies a kind of singlemindedness that I’ve finally accepted that I just don’t have, and don’t want. Maybe it’s because I find that I cannot be passionate and fearless at the same time: passion makes me cautious. My best work, my best ideas, and my best productivity come when I am playing with something that is not excruciatingly important to me. It’s a spirit of fearless play, not passion, that drives what I do.

Not, note, that I am claiming to actually accomplish an awful lot. I’m just pointing out that, to the extent that I accomplish anything, it’s because I don’t take it too seriously. The second I start taking something seriously, I completely freeze up.

For example, this time last year, I’d just had a baby. I hadn’t worked for pay in about three years, and I had no plans for that to change anytime soon. Then Max had a contract end and decided he wanted to learn Ruby on Rails (this was back when he thought he really wanted to be an app developer, before he realized that his sweet spot is all the technical stuff that has to do with app development that isn’t actually about writing application code.) Anyway, so he was having a hard time motivating himself to do the AWDR tutorial. Fine, I said, I’ll do it too, maybe we can motivate each other.

Then I convinced him that we should try to start consulting together, and we started the blog. Hey, I thought, no one is reading this thing, I can write whatever I want. For example, here’s a quote from my very first blog post, in March:

Someday soon we’ll be able to say “yep, we know Ruby on Rails” and we’ll have our fantastic contributions to the open source world to prove it. “Right,” you’ll say, after reading this blog. “We’re looking for someone with five years experience with Ruby on Rails. You have three months.” And we’ll say “That’s the way it goes, suckas. You want to hire people who don’t actually exist. We, on the other hand, exist.” About Ruby. We’d originally decided that Max would pick up Ruby on Rails, and I would freshen up my Java skills with STRUTS, which was just coming out last time I did serious Java coding and which I am, by all rights, long past due for learning. This felt very serious and sensible. Also not fun.

And then, later that day, the key to it all:

How are we able to be so marvelously decisive? We just pretend that everything we’re doing is fake, and therefore of no consequence.

If we’d been really passionate about the whole thing, and utterly convinced that this was our calling in life, that our business absolutely had to succeed, that everything had to be done right, we would never have gotten anywhere. But we started out not caring. We did not know ruby on rails. We did not know any ruby on rails developers. We had no idea where we would find clients. I hadn’t done any programming whatsoever for nigh on three years, having devoted my time instead to recovering from the nervous breakdown I had when I was pregnant with Ari, learning to garden, grinding my own wheat for baking bread, writing a political blog, rediscovering my love of painting, visiting and eventually applying for and receiving visas for permanent New Zealand residency and, finally, being bedridden and anemic and puking during most of my second pregnancy. So hey, why not try something new? Who knows if we’ll like it? Who knows if we’ll be any good at it? Who knows if it’ll work out? Who cares?

Here’s me a month after we started the blog, in April:

I don’t know where this all is going, exactly. I’m not ready to work full-time right now. I’d rather Max not work full-time either. I want us to find a way to work together, and not all the time. I want everything — the perfect setup! I am not sure how we’ll get to our dream work from where we are right now. Will we find a job to share, or will we be laughed out of any company we tried to convince to hire us for one? Will we do some consulting, or will it turn out that we can’t stand all the self-promotion required to consult? Will blog.thirdbit.net end up going to that great bloggie graveyard in the sky? Will I work for pay again, or spend my days sitting in the park snickering at the bugaboo strollers? Is the final cylon really who we think it is, or was this year’s season finale a red herring?

In May, we got our first clients. In July, I saw a post on the Boston Ruby Group that someone needed a TA for a Ruby on Rails class at Harvard Extension. Hey, I thought, I’ve been a TA at extension before, maybe I could do that. I went to the interview and was like “yeah, I’ve been using RoR since, uh, March.” And John, bless his heart, was like “oh that’s cool, whatever.” He wanted a TA who already knew how very much work it was to grade all those programming projects, and how very little money Harvard thought all that work was worth.

In August I wrote a blog entry about method_missing which somehow got Reddited and then mentioned on Ruby Inside, which resulted in a huge spike in blog traffic.

And I ended up TA’ing this class. And it’s been absolutely a blast, and John hired Max to do some systems consulting work (migrating his company over to a new bug database).

And after John introduced me to Steve Yegge’s blog I started feeling I was just a completely crap developer who knew nothing about anything, and that gave me an idea for a book one night when I was up with Aya who was teething, and wrote up a proposal the next morning, and sent out the proposal, and got a book contract. So now I am writing a book, about which more soon.

And since I was TA’ing the RoR class I made sure to show up to the Boston Ruby Group meetings and eventually everyone got used to me being there and started to know who I was, and I started corresponding a bit with Greg Brown over email so when he came up to speak at the December Ruby Group meetingI was like, what the hell, and invited him to dinner, which was a lot of fun.

And Max and I each got more clients doing exactly the kind of thing we each like most to do right now. ( Obligatory self-promotion: Look here for more info if you might want to hire one or both of us!)

Anyway, it has worked out for us. Not exactly the way we imagined it might, but nothing ever does. And since we weren’t all that invested in what we’d imagined in the first place, it didn’t bother us that much to change it.

I don’t know what will happen next. But I do know that everything great that we’re getting to do, all the good stuff happens when we treat our lives like a game, and play, fearlessly.

Popularity: 46% [?]

Joel Spolsky Gets It Wrong

Posted by amy on December 28, 2007

Joel Spolsky recently posted the transcript a speech he gave to the Yale CS department on November 28th. It reads a bit like an extended recruiting pitch, which, of course, it is. Because why would he give a talk at Yale CS and not attempt to pick up some smart people to work for him while he was there?

Anyway, one section of the talk is all about how it sucks to write in-house software. Joel says it sucks because, first, you don’t get to work with cool technologies, because no one will let you:

you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be. You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done.

Second, it sucks because you don’t get to work on a project past the point where it minimally solves the business problem at hand and because of that, you’re stuck building and fixing ugly, broken things for not enough money and no respect.

The key point about in-house development is that once it’s “good enough,” you stop. When you’re working on products, you can keep refining and polishing and refactoring and improving, and if you work for Facebook, you can spend a whole month optimizing the Ajax name-choosing gizmo so that it’s really fast and really cool, and all that effort is worthwhile because it makes your product better than the competition. So, the number two reason product work is better than in-house work is that you get to make beautiful things.

Third, it sucks because no one thinks in-house developers are very important:

Once at a Viacom Christmas party I was introduced to the executive in charge of interactive strategy or something. A very lofty position. He said something vague and inept about how interactivity was very important. It was the future. It convinced me that he had no flipping idea whatsoever what it was that was happening and what the internet meant or what I did as a programmer, and he was a little bit scared of it all, but who cares, because he’s making 2 million dollars a year and I’m just a typist or “HTML operator” or whatever it is that I did, how hard can it be, his teenage daughter can do that.

Therefore, says Joel, serious programmers should work at software product companies, like, say Fog Creek Software.

I’m sure a lot of in-house software development jobs are just like Joel says. But there are plenty of really rewarding in-house positions available. For example, what he describes is not at all what I experienced while working at Millennium Pharmaceuticals (2001 -2003, with some consulting work on and off after that). Informatics was pretty crucial to the company’s vision of how it would revolutionize drug research and development. Developers were respected, and we tried to make our software, if not very beautiful, at least not completely butt-ugly. There was room for plenty of innovation in what technology we used. It was a great place to work, and I worked with some amazing people there. I felt like the software I was making was actually helping people do their work, and it was work that they cared passionately about, and I understood how they could be passionate about it, even if I wasn’t myself passionate about it. Most of the code I wrote went to helping the molecular pathology department manage their experiment workflow. I thought the domain (biotech, and as far as what molpath was doing, basic disease research) was interesting. I was really happy there.

Conversely, I’ve found that I’m not really at my happiest working on consumer products. I don’t get excited about consumers. I think that their consumption is pretty much the least interesting aspect of people, and I think that when people are acting as consumers, they tend to be at their most demanding, irrational, and childish. I also don’t think that people like that Viacom executive who had so little respect for Joel are found only in big companies with big in-house software teams.

I like to help people get their work done. I like the philosophy of ‘good enough’. I don’t really care that much about ‘really fast and really cool’ unless someone convinces me there’s a very good reason to care about it, and the reason is better than “well, people will think it’s cooler and buy more of it.” I’m just not a very good capitalist that way.

In any case, plenty of software product companies make butt-ugly software that’s only just good enough, using awful techonology, so I really don’t think the distinction is a valid one. And I think that we’ll see that an increasing proportion of in-house software written in ruby on rails. Maybe it won’t have cool AJAX livesearch widgets in it. So what?

It’s not that I think appearances aren’t important. It’s not that I don’t think that there’s a place for consumer software products. And I know that lots of in-house software development sucks. But I think Joel is over-generalizing in order to make a stronger recruiting pitch. And I think that he wrongly assumes that what makes him happy is going to be what makes everyone else happy. That’s true at the level of basic human needs, of course, but not at the level of what floats your boat at work. Or rather, not in the way that Joel talks about it. Your satisfaction at work probably has a lot more to do with the length of your commute, whether you have clear goals and a sense of control, and if you have friends in your workplace than about whether you get to work with cool technology or make things faster and better just for the hell of it. Respect, sure, that’s important to have. But plenty of software product companies respect sales and marketing over development, and plenty of non-software-product corporations respect their developers.

Joel’s not really wrong here, of course. He just over-generalizes. He thinks his own experience must be everyone’s experience. He is sure that what he wants must be what everyone else wants.

Actually, it’s probably not that at all. He just really, really wants to pick up the cream of the Yale CS crop. He needs good developers, and gosh darn it, he’s gonna make his pitch to get them.

Popularity: 36% [?]

Ari invents recursion

Posted by amy on December 28, 2007

“Mom, let’s play the wishbone game!”

“Okay, here we go. Pull! … Oh, look, you won!”

“You know what I wished for, mom?”

“No, what?”

“I wished for the bigger piece of the wishbone!”

Popularity: 28% [?]

O, Happy Solstice, and Business

Posted by amy on December 23, 2007

Kieran Healy of Crooked Timber, talking about the giant Celtic clock at Newgrange, and the Winter Solstice:

A society—a civilization, if you like—is a hard thing to hold together. If you live in an agrarian society, as the overwhelming majority of people did until about two hundred years ago, and you are on the western edge of Europe, few times are harder than the dead of Winter. The days are at their shortest, the sun is far away, and the Malthusian edge, in Brad DeLong’s phrase, is right in front of you. It’s no wonder so many religious festivals take place around the solstice. Here were a people, more than five millennia ago, able not only to pull through the Winter successfully, but able also to build a huge timepiece to remind themselves that they were going to make it. It’s astonishing.

I am in a post-Christmas-party fog this morning, so I can’t do my usual “really, this is totally related to software development even though it seems to be a cute story about my kid or something else off-topic” thing. Crooked Timber is a group academic blog having nothing to do with software (though some of the academics on it do research on web stuff; here’s a recent note about some research being done on social networking sites, for example.)

Actually, I’ll at least try to relate this to work/software/consulting/business: Sometimes you hear people lament the December slump in productivity, and blame it on the ‘holiday season’. As though if there were no pesky holidays to get in the way, then we’d all be going full-bore on our goals. The other day I read a post about how I could be using this holiday lull in billable hours to get a bunch of really useful stuff done. “Oh man,” I thought, “We totally need to do that stuff.” All the extra stuff on our site, for example, (the non-blog stuff) has not been updated for months, because we’ve been too busy working to change it to reflect more accurately the work that we’re actually doing these days. (And we are rapidly approaching the time when we can no longer claim to be in ‘really-real beta rather than google-style fake beta’, as it says in the sidebar.) And we need a better invoicing process. And so on. But the truth is that, like most everyone else, I’m not that productive right now, even though I don’t have the excuse that I have too many holiday commitments, or that I’m traveling.

People who think that it’s the holidays that cause a December drop in productivity have it totally backwards. It’s the December drop in productivity that causes the holidays.

We don’t live in the stone age anymore. We do not spend the long dark winter starving and freezing, huddled together in our huts. But we are still part of that rhythm. Our artificial lights and central heating and snowplows and de-icers do not entirely erase the feeling we have that now is the time to huddle together around a fire, not go to meetings and launch new projects.

Which is to say that the site will not come out of beta until 2008. Happy Holidays, everyone!

Popularity: 25% [?]

REST vs. SOA: thoughts from a member of the unwashed masses

Posted by amy on November 27, 2007

I have no recollection of how I ended up here:

On the REST front, if you’re claiming that it’s harder than the alternatives, to me that’s just a sign that you don’t understand it. Is REST simple? No, but neither is SOA. However, unlike SOA, which is fairly wishy-washy, noncommittal, and loose, REST’s constraints provide real, actual guidance for developers, and those same constraints also provide opportunities for significant flexibility, extensibility, performance, scalability, and serendipity. SOA’s contracts come with no rules or constraints, and thus can easily result in a system that’s extremely brittle, tightly-coupled, and virtually impossible to upgrade. SOA itself isn’t inherently bad, as it’s certainly a step above the “every application for itself” mode of development that’s so widely practiced. Unlike REST, though, SOA doesn’t go nearly far enough to provide real, useful guidance to the poor developer who has to actually write the stuff, make it work, and keep it running.

The author was responding to this guy:

This is the reason I am against dynamic languages and all of the fan-boy parts of IT. IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal, because the smart guys can always cope.

And that guy was responding, in turn, to this guy, who said that REST was like dynamic languages because both are loosey-goosey and flexible and don’t enforce contracts and type-checking.

The SOAP/WSDL/WS-* SOA view of the world is like a statically typed programming language, i.e. C++ or Java — everything is pre-defined, contracts govern everything, nobody can interact without following formal rules … and ideally, everything violating the rules (and policies) will get caught before even going into production.

So the chain is: 1) REST is very flexible compared to SOA, and that presents the danger that things that don’t work will be put into production. 2) REST is too complicated to be implemented by ordinary dumb programmers, and should be avoided. 3) REST is easier than than SOA because it provides very strict constraints.

So is REST easier or harder than SOA? Is it looser or stricter?

I just implemented my first REST API. I don’t see how anyone could say that it is ‘harder than the alternatives’, or that it doesn’t constrain developers very much. So I agree with the first quote, above. REST seems like a great idea to me. Anything that allows me to mostly avoid the complications of this many standards is good.

And also, obviously, I’m a big fan of dynamic languages now. I think I’d rather look at someone else’s crappy Ruby code than someone else’s crappy Java code, because at least there’s less of it. But I am, arguably, a Ruby fangirl right now, and given that I don’t have a CS degree, I guess I also count as one of the unwashed masses. And as a member of the masses, I can attest that no programming language in the world will stop us from doing something stupid. So we may as well enjoy ourselves while we’re doing it!

Popularity: 22% [?]

Amy’s guide to choosing and using rails plugins (With Bonus Checklist!)

Posted by amy on November 19, 2007

Last week a student asked for advice about rails plugins: where to find them, how to evaluate them, and how to use them. I promised a blog entry on the subject, since it’s been on my topic list for three months and I’m behind on blog entries anyway. so here it is.

Where to find plugins

www.agilewebdevelopment.com is one of the main rails plugin directories. It has a stars and comment system for the listings, but given the number of rails developers out there in the world, there is surprisingly little community activity, so you have to take both the stars and the comments with a grain of salt. (And many of the comments are of the “I installed your plugin and it does not work. How do I fix it?” variety.) Nevertheless, it is the largest plugin directory I know of. And here’s the ruby-on-rails core plugin repository.

After that: google is your friend.

When should you look for a plugin?

Lots of people use acts_as_authenticated or restful_authentication as their starting points for user authentication, so it’s a good idea to become familiar with them yourself, even if you plan to roll your own auth code, because people frequently talk about general auth issues in the context of those plugins.

If you have to implement something that every single web 2.0 site out there has, it’s worth looking for a plugin. DHH wrote the quintessential web2.0 plugin, acts_as_taggable, although there’s also the popular acts_as_taggable_on_steroids. Rick Olsen aka technoweenie, who is a busy plugin bee, provides attachment_fu, which is an easy way to provide gravatars and other image upload/processing capability to your app. will_paginate is the current pagination code flavor of the week (You know not to use rails’ built-in pagination, right? It’s getting yanked out in rails2 anyway). There are a bunch of tutorials on adding star ratings to your app with one of the rateable plugins and some CSS.

Some plugins are more general-use and are meant to make your life as a rails developer easier and more fun. Sexy migrations, for example, DRY up migrations, and were such a popular plugin that they’ve been integrated into rails 2. Annotate-models is a plugin Dave Thomas wrote that adds some comments to your model objects telling you what precisely their database tables look like, so you don’t have to dig around in schema.rb. There are some plugins to improve active record finds, which are generally useful. There are helper plugins, builder plugins, markup plugins, and just plain silly plugins (acts_as_enterprisey).

When you first start using rails, you can go a little plugin-crazy. OMG, I never have to write any code again! you think, and get lost in an orgy of plugin downloads and installations.

Don’t get too excited yet.

I just had a discussion with Robert Oliver of OCS Solutions, rails fellow-traveler and current collaborator on a client project, about the value of plugins. He doesn’t use ‘em much. (“And I don’t use capistrano, either!” he says. “I am a rails heretic! Burn me at the stake!”* ) Anyway, so Robert says plugins are rarely exactly what you need, and it’s too much trouble to put them in and then rip them out when you discover they’re not precisely what you wanted. I say that if they save you time when you start out, and later you have to modify them to suit your purposes, it’s still saved you time, as you probably would have had to modify whatever you wrote yourself too. He says, yeah, but it’s easier to mod your own code than it is to mod other peoples’ code.

Robert has been developing in rails longer than I have, and the more I think about it, the more I think he’s probably right, and that I am only now coming out of the newb over-reliance on plugins phase. Some of the advantages of publicly available plugins fade as you get more familiar yourself with how to make things happen in rails. Rather like scaffolding, which seems awesome at the beginning, and then you realize that the generated code is not that useful. (Note that the advantages of the plugin format for your own code re-use remain after the first flush of newb plugin-love fades.)

For a rails newb, though, plugins do serve some important purposes. Their very lack of documentation and YMMV nature forces you to read the code. sometimes repeatedly. Not all plugin code is worth a damn, of course, but, especially for some of the plugins put out by rails-core members or other luminaries, a lot of it is good stuff. Complex good stuff, full of ruby idioms, metaprogramming, and other stuff the newbie rails developer thinks of as magic. After a while, when you’ve looked at similar magic sixty different times, it starts to become slightly less magic. Oh yes, you think, when you see something like ActiveRecord::Base.send(:extend, Technoweenie::AttachmentFu::ActMethods), there they are mixing themselves into your models for you. And, of course, generous use of plugins is an excellent way to convince non-technical clients that you are a total rails ninja. Hey, look ma, I implemented full-text search in 20 minutes!

Bonus Checklist for choosing and using rails plugins

  • Who wrote it? Are they a big name in the community?
  • Or: do big names use it and talk about it?
  • What kind of documentation, both original and blogged/forum’ed can you find about it?
  • What do people say about it?
  • What’s the code look like?
  • Is it really worthwhile for you to use it, or should you just review it for a general approach to the problem you’re trying to solve and then write your own code?
  • Does it have tests? Do the tests run?
  • Do you really need what the plugin gives you, or are you just putting it into your app because you can? (does every single thing on the web really need to be friendable? )
  • Any glaring security issues? SQL injection, passwords in the clear, unescaped html, etc.?
  • Read the readme. It may be thin. But it should tell you at the very least the steps you need to take to get going with it, which might include generating some code, running a migration, adding a line or two to a model class, etc.
  • You have to read the code. Did I mention that? Look at the code. Don’t use a plugin whose code you haven’t looked at! And also, read the code.

Further Resources

Geoffrey Grossenbach’s Nuby On Rails offers an excellent two-part tutorial on plugins: Part 1, and Part 2.

There’s a whole short cut (or whatever it’s called — you know, one of those mini-e-books) about Rails Plugins. It looks pretty good, but i’ve only skimmed it on Safari. If you plan to write your own, check it out.

On the Proliferation of Crappy Plugins

Dear readers: please think twice about releasing your own plugin into the wild just so you can check off the ‘wrote plugin’ item on Working With Rails. Please make a plugin you release generally useful, reasonably well-tested, secure (don’t leave your plugin finder methods vulnerable to sql injection, for example), and documented. If it’s similar to another plugin already out there, be sure to point out how yours is different in a way that helps people choose between them. Plugins are a fantastic way to re-use code on your own projects, but not all such code really wants to be free. Is this a heretical anti-Open-Source comment that I should not be making? I am not sure. Anyway, I am sure that someone will turn around and suggest that I quit littering the internets with my crappy blog posts.


robert says: “as for capistrano.. Do you really want anyone who has the source to be able to deploy your app? That’s dangerous! Use custom scripts.. They’re easier to write than capistrano tasks and you must have access to the servers to run them!”

Popularity: 23% [?]

Database Constraints, Stereotypes, Rails, Culture, Talmud, Gender, MINASWAN, Religion. But ABSOLUTELY NO BONDAGE PLAY

Posted by amy on November 02, 2007

This post started out with a plan to compare constraints in software to bondage play, and suggest that DHH is a top who likes to constrain others (“opinionated software”) but is extremely uncomfortable being himself constrained (by, say, the database). I was going to suggest that DHH maybe needs to get a little bit more confident and comfortable being a ‘bottom’.

Now, that would have been a wildly, wildly inappropriate post, don’t you think? So it’s lucky for me that as I was writing it, I realized that not only was it inappropriate, it was completely unfair. So this post is still about rails culture, and still about database constraints, but I am not, I repeat, NOT arguing one way or another about DHH’s predilections in bondage play (assuming he has any, and if he does, not that there’s anything wrong with that ), about which I am, and hope and plan very much to remain, ignorant.

That out of the way, how did this all come up? Yeah, my mind’s a little twisted. But here you go:

My friend and partner-in-teaching-crime* (well, boss in teaching-crime, technically, and is teaching really a crime? To my students: do not answer that!) John complained recently about the difficulties of writing a migration to turn a plain HABTM join table (two foreign keys, no primary key, nuthin’ else) into a join table with state, linking two other tables with the :has_many :through association. Unfortunately, as he describes, ActiveRecord won’t let you add a primary key column to an already-existing table, so he had to migrate all the data over to a new table.

Couldn’t you just drop down to “execute ‘db-specific sql here’”? I asked.

Yeah, but you wouldn’t be database-agnostic, of course. John likes to be agnostic. He has historical reasons for that, just like I have historical reasons for thinking that ads comparing servers to who won’t give blow jobs are kinda offensive. But anyway, I don’t have those reasons that John does to prefer agnosticism. I figure that in most cases, people are sticking with the database they’ve got, so database agnosticism isn’t that important to me. The ORM is one of Mr. Spolsky’s leaky abstractions, and while that’s no excuse to start poking extra holes through just for the fun of it, I don’t have any need to pretend that the holes that exist aren’t really there.

In any case, I drop down to the database to put in foreign key constraints.

[Aside: John said in email:

"There is a distinction to be made between this narrow case of
agnosticism (fiddling with keys) and the general case. The narrow case
is easier to disregard. In the general case, it is very difficult to
argue against agnosticism, because the primary driver is: You get to
know less. That is frequently (more frequently than not) beneficial,
right? In the general case, I would rather write
user.find_all_by_last_name rather than the raw SQL. etc."

I agree wholeheartedly, and in that sense I too am in favor of database agnosticism. But obviously we have different levels of allegiance to the idea, because I would never have put in the effort to come up with a database-agnostic migration from a HABTM to a has many through relationship, and he did. Maybe it's just that I am lazier than he is, though...]

So this post was going to be about how it is the rails way not to use foreign key constraints at all, but to rely on ActiveRecord and your own unit testing to maintain data integrity. (hah!) And I was going to say “that’s freakin’ insane and evidence of all that is wrong with the whole culture of Rails.” But while it would be fun to see what this temporarily did to my site stats, (assuming it got dugg or reddited or something) it wouldn’t be fair.

I found very little evidence that not using foreign key constraints is considered to be a best practice by most people in the rails community. The main thing is this caboose posting, from last year. This was mostly a complaint about how big of a pain in the ass foreign keys are, especially where fixtures are concerned. But it actually only at the end claims that foreign keys are not needed, if you are using ActiveRecord Associations correctly. And even then, it’s a weak claim, about foreign keys in the development database:

The time thing sold me on not using foreign keys in development. I’m sure there are a number of arguments that can be made for using foreign keys etc etc, but it’s just stuff that gets in the way in a framework like rails. Do we test w/ foreign keys in place before milestones(what I’m leaning towards)? Do we test w/o the fks in place(obviously not :])? Maybe somebody can come up with a better way to handle them, but I don’t really think you need fks if you’re using rails associations correctly. If you are forced to use them though, the above approach might be a good place to start.

Okay, I found one other posting, from a guy who gave up his foreign key constraints (and wept) because they were too hard to use with fixtures. But most people in the comments of that post seems to think the problem there is not foreign key constraints, but fixtures, and that dropping the reliance on fixtures would be the smarter thing to do. Or fixing the fixtures, or whatever.

DHH has nothing to say on the matter that I could find. In AWDR, Dave Thomas explicitly advocates the use of foreign key constraints (2nd Edition, p. 324). Mostly what I found on the web about rails and foreign key constraints was a bunch of people talking about how they do use them and you’d be crazy and irresponsible not to. Yes, people differ on when in the development process they put them in (in fact, right this minute I have a development database with a near-complete lack of foreign key constraints, my rather pathetic excuse being that the client’s requirements are so changeable right now that we can hardly keep up with the foreign keys themselves…), how they use them with fixtures, and other details, but I really found very little evidence that anyone in the rails world seriously advocates putting into production web applications backed by databases without foreign key constraints. Relational database technology is mature, it’s well-tested, and it’s logical. I trust it much more than I trust either my own code or DHH’s. Database constraints are easy to use and good for you, just like flossing. And that appears to be the majority view.

So the evidence wasn’t there, and I had to rethink this post entirely. And so it’s become, in part, a post about stereotypes, and about culture, and about the ways that people confuse technologies, creators, fans, and users.

Rails is a technology. The technology exists in the context of a culture. The culture is greatly influenced by the fact that a single, very opinionated, um, strong personality developed the technology. Certain kinds of people are attracted to the opinionated personality, and become involved in the technology and its culture because of that. This is great for adoption of the technology. But then you get the fanaticism: rabid pro-Rails trolls who jump down the throats of people they perceive to be deviating from the One True Way of DHH. And equally rabid anti-rails trolls, screaming “Twitter”!

Now, is all this clash of personalities and hue and cry integral to the development of the technology, or is it epiphenomenal? (Is that a word?) I’m not sure. The anthropologist in me says it is, and that the culture of rails in some sense IS rails — drives its development, ensures or prevents its success, etc. The Marxist in me thinks perhaps the structure of rails itself is responsible for the culture surrounding it: the culture reifies the framework. And the poststructuralist in me suggests that, however determined things appear to be, however narrow and defined and boundaried and opinionated and one-true-wayed things appear, there’s always space for something else to arise.

There’s the One True Way of DHH. There are rabid fanboys. We talk of drinking the kool-aid, and we laugh at video advertisements comparing the separation of concerns, database-agnosticism, and ease-of-use of Rails to PHP, Java, et. al. “With rails, I can build a blog in 10 minutes,” we say. With rails, we never have to code again! Let’s just go to the beach instead! There was the Twitter developer scaling scandal, and the CDBaby switched-back-to-php-from-rails scandal, and a bunch of scandals I haven’t even heard of, no doubt. There’s the rails bandwagon, the rails hype, rails lets crappy developers wreak havoc quickly, rails is too slow, and rails is not ruby.

And that’s all fine and part of the fun, and part of the DHH Is Opinionated and So We Are Opinionated – ness of Rails culture.

But then there’s the technology, and lots of quiet, not-so-opinionated, flexible people who are using Rails because it’s a pretty good, pretty easy framework that helps them get their work done. There’s plenty of that too. And there’s no need to decry the partisan atmosphere of rails culture with a great big rending of garments about how the culture really has to change if it’s going to achieve more popularity, and it’s scaring people off because it seems too hyped, and badly executed rails projects are giving rails a bad name and how can we police that, and so on.

Let’s just all get on with our work, using rails, or not, as the work dictates. And in a mild-mannered matz-y way, talk about what we are doing, and why, and how, and what we like, or don’t, about it.

For me, rails is a web framework, not a religion. I know that not everyone feels or acts that way, and that’s fine for them. They can wave their hands and argue about what constitute a ‘scale’ for the purposes of determining if a fish is kosher, or if one should use foreign key constraints. Me, I’ve got to get dinner on the table.


* Max would like it noted that he thinks there’s something very trite about the expression “partner-in-crime”. He’s right, of course, but I think I’ll leave it in anyway, to annoy him.

Popularity: 25% [?]

In Which Amy Encounters a Superior Mind, Recognizes (Again) Her Own Incompetence, and Rededicates Herself to Alleviating the Problem, Though Not Without Some Concern About When She’ll Actually Find the Time to Do So

Posted by amy on October 29, 2007

A few weeks ago, I was introduced to Stevey’s Blog Rants. I started reading them, and I realized, yet again, that I am a crap developer.

I am a hack. I know nothing. I claim not to be a script kiddie, and I’ll stand by that claim, but only because those of us who are just competent enough to know that we are incompetent are EVER SO SLIGHTLY more competent than people who don’t realize that they are utterly incompetent.

I know people whose lack of ability to solve programming problems is always, always caused by some quirky gotcha in the language being used, and never ever by their utter lack of understanding of the most basic, fundamental aspects of programming. They’re sure they’re just misusing the subjunctive, and in reality, they’re babbling in gibberish that is less comprehensible than my 10-month-old’s. (Those people are always certain that everyone is simply misunderestimating them. Would that it were true!)

So I’m not that incompetent.

Still.

[ Ack, I am being attacked by a babbling infant. She has noises for "nurse now, mom" and noises for "check it out, mom, I'm turning on the stove!" and noises for "I'm sitting in a big poopy puddle" and noises for "stop typing now, mom, or I am going to jam the caps lock permanently on." That's the noise she's making right now, in fact, SO I BETTER GO BEFORE I FIND MYSELF YELLING AT THE INTERNETS ALL THE TIME. Back later.]

Right, back to how bad a developer I am. Can you believe I’m supposedly using this blog to drum up business? Hi, prospective clients! I suck! Let’s talk. Before you turn away in disgust and say “why should I talk to you, you sucky developer?” let’s get some perspective. Steve Yegge, who works at Google, and before Google worked at Amazon, also claims he sucks. Suckage is like wealth: graded on a curve. Steve Yegge says he sucks because he’s measuring himself against all the other developers there at Google. I say I suck because I’m measuring myself against Steve Yegge (though, don’t get me wrong, I also suck as compared to many developers suckier than Steve Yegge. Steve Yegge is several levels up in developer competence than I am. Several.) The principle holds, however. Developers who don’t think they suck are only hanging out with crappier developers. And not only does that mean that they don’t even know how incompetent they are, they also have no way of getting less incompetent even by osmosis, because they’re not putting themselves in a position to osmose anything from anyone else. ( I read a sample chapter in Chad Fowler’s My Job Went To India… about this, which made a huge impression on me:

Legendary jazz guitarist Pat Metheny has a stock piece of advice for young
musicians: “always be the worst guy in every band you’re in.”


Attempting to be the worst actually stops you from selling yourself short.
You might belong in the A band but always put yourself in the B band,
because you’re afraid. Acknowledging outright that you’re not the best
wipes away the fear of being discovered for the not-best person you are.
In reality, even when you try to be the worst, you won’t actually be.

This is why Max joined an orchestra this year, even though it’s a lot of effort and feels very far over his head. He’s learning a lot more than he would learn just playing by himself. It’s also one of the great disadvantages of independent contracting — the reduced opportunities to be part of a team of your betters. You really have to make more of an effort to seek out your betters to work with them, because you don’t always get to do it on your paid work.)

Anyway, you don’t want developers who don’t think they suck, dear prospective clients/employers. Stop looking for people who self-identify as ninjas and experts and superstars, and find some nice modest developers who have some sense that there’s stuff out there that they don’t know, and will admit that they don’t know that stuff not because they don’t NEED to know it, but just because, hey, they don’t know it. They’d be better developers if they did know it. They’d like to know it. Maybe it’s even on a list of things they’re going to learn. Maybe that list is far too long, and maybe they only have fifteen minutes every other week to even get the list out and look at it, but they have a list of stuff they don’t know that they think they SHOULD know.

In fact, what I’d do, if I were you, prospective employer/client, is ask: “Where are the holes in your technical knowledge?” I suppose that if people started doing that, we’d all start picking one or two safe-ish things to reply, like how everyone says, when asked what their weaknesses are, that they’re a perfectionist who hates being late. “Oh, I always get confused by my splay trees.”

Of course, Steve Yegge would probably tell me that splay trees are not a safe-ish reply at all. Everyone should know about splay trees. Fundamental stuff, splay trees are. He’s probably right. I don’t remember covering splay trees in my one data structures course, but that doesn’t mean I didn’t. I’ve never had occasion to use them in my developer life, but that doesn’t mean I wouldn’t, if I knew what they were and when I might. For all I know, I am using splay trees every day. So now I have to go learn about splay trees.


Actually, dear readers, I do have a plan for a fun, exciting, and exhausting project that will help me get some of that CS knowledge I am lacking. The project remains, right now, in super-secret stealth mode, except if you know my mom, in which case she’s told you all about it already. As it takes shape, I’ll reveal more details about it.(Or if it doesn’t end up taking shape, I’ll pretend I never wrote this and look at you all confused if you ask me whatever happened to my mysterious and exciting project I mentioned on the blog. What project? I’ll say. I never said there was any project. You’ll show me the actual words in which I said “oh, there’s a project”, and I’ll look you straight in the face and say “nope. Never said that. Didn’t write it. No project.” And you’ll shake your head and roll your eyes and let it slide, because that is what we do these days. )


Also: I think that I am getting way too obsessed with Steve Yegge. And given that Steve Yegge basically thinks I’m crap*, that’s probably unhealthy, don’t you think?* No, steve yegge did not drop by this blog and say “amy, you are crap.” But he did say “If you don’t know how compilers work, then you don’t know how computers work.” I don’t know how compilers work. And he frequently talks about how woefully deficient he considers programmers to be who are lacking a long list of skills and knowledge that I, too, lack. I would not, for example, pass his phone screen. If I had a job interview with Steve Yegge, he would skip the hello and go right to Do you have any questions for me?”. So I’m pretty sure he thinks I’m crap, even if he might be too polite to say it to my smiling avatar face.

Popularity: 14% [?]

how did I ever live without xkcd?

Posted by amy on October 10, 2007

John mentioned the webcomic xkcd in a post on our course site about his feeds, and now that I subscribe, I have absolutely no idea how I ever lived without it. Sudo make me a sandwich is hanging in our kitchen now.

heh heh, sanitize your database inputs! (imagine me pushing up my glasses while snorting, revenge of the nerds style.)

Popularity: 14% [?]

Airport Extreme is a big disappointment. Or, (10?) Things I Hate About Apple

Posted by max on October 05, 2007

I bought the elegant little Apple Airport Extreme back in the summer. Network disk (pseudo-NAS) support! Printer sharing! Fantastic! Besides the fact that our last wireless router was puking to death again (why does that always happen to us after <2 years? Do I emit gamma rays from my head?), I was excited to enable USB printer networking and shared network drives.

Only in both cases, they don't work. At least not in a way that is useful to me.

1) Printer sharing

There are two defects here: one design, one implementation. After trying to figure out why I couldn't do anything that my fancy-ass new multifunction printer that Canon sells as a loss leader for its pricey ink cartridges, I discovered that it it normal that non-printing functions don’t work unless the unit is directly connected to the computer. Networks are for printing only. No scanning, no ink maintenance fancy stuff, just printing. That’s the design problem, and it’s a major bummer, but it wasn’t a deal killer. (OK, well, nothing was a deal killer; I bought the damn thing.)

Nope, what ended network printer sharing for me was that the shared network printer would periodically disappear or otherwise become unavailable for users on the network. Had to delete the printer and re-add it, or at the very least power down the router and printer and power up again. That’s crap. So now the way I provide reliable-ish network sharing is to connect it directly to my computer and share it as a network printer.

That’s crap.

Grade: F. I would blame Canon, because they make great hardware and execrable software, but I had a similar problem with my old HP Laserjet 6MP printer.

2) Drive sharing

I finally got my ass in gear and moved my old 250GB USB drive from my slowly-decommissioning Windows machine onto the Airport Extreme. After many slow reboots of the router (yeah, any change requires a reboot; couldn’t it at least boot faster, damnit?! I’m not even getting a DHCP lease from my ISP — it’s static.), I discover that the Airport Extreme is unable to share NTFS volumes. Well, that’s not so multi-platform, now, is it? FAT32 is insecure and doesn’t work for big volumes, say, any hard drive created after about 1998. HFS+ would have been an option if this drive were originally on a Mac, but it wasn’t. So my best options are:

  • Copy all of the data off the drive and reformat to HFS+; remount on the Airport Extreme after getting their wonky SMB networking
  • Abandon the project, as the USB drive is already 5 years old and isn’t worth spending a lot of time monkeying with

Guess which one I picked?

Grade: D+. You’ll note that the spec sheet mentions nothing about not supporting NTFS. I’d like to blame M$ for that one, but there are plenty of NAS vendors that offer NTFS support.


While I’m at it, let me complain about Apple file sharing. You seem to be able to choose between a yucky slow SMB implementation and AFP (which does appear to be much faster, at least for authenticating). I have grown frustrated with both and am now very, very happily using instead sshfs, which is great both on the LAN and across the Internet. Too bad ‘Doze doesn’t support user-space filesystems; so no sshfs for Windows.

(To run SSHFS, I use Google’s MacFUSE project and their SSHFS executable. I don’t remember exactly why, but the MacFusion GUI doesn’t work on my machine.)

Popularity: 19% [?]