“You know CSS, right?”

Posted by amy on June 29, 2007

Sure, I know CSS. Just like I know Javascript. But then your CSS does something weird, and you can’t figure out how to fix it, and you look online and you find stuff like this:

Be aware that most of the demos in this site employ the Holly hack to work correctly in IE, but now IE7 fails to read the old star-html hack which was the vehicle for feeding the Holly hack hasLayout fix. Further, IE7 cannot be shown a small height to trigger hasLayout as has been customary.

Or this:

Liquid layouts have their own problems in the wide screens, stretching both text lines and designs beyond belief in some cases. Besides the obvious, Explorer for Windows can also have very nasty bugs in liquid layouts when rigid content that shares space with floats happens to “lock up” the page width. When that happens, the bad old 3px bug induces content dropping, and the only cure is to use min-width to stop the shrinkage before lockup happens.

Unfortunately, IE does not support min-width as well as it supports the 3px bug, so a JavaScript is then needed to coerce compliance in IE. It’s a big pain in the you know where.

Really?That’s a big pain? You’re kidding me.

Anyway, all I want is for my footer to stay at the damn foot. This is only possible, apparently, if I can tell you in advance which one of three columns will be the longest. Or maybe there are some weird hacks that no longer work in IE7 that I could use. I’m not quite sure, because it turns out that CSS is not, as I’d previously believed, a mere aid to ensuring that your design is consistent across web pages and your html not too big, but an arcane alchemical pursuit, complete with footnotes.

More thoughts on this, but it’s my birthday, and apparently my son has bought a cupcake to share with me, that must be shared RIGHT NOW!

Popularity: 9% [?]

Adobe hatemail

Posted by amy on June 27, 2007

Dear Adobe:

I hate your website. I hate that none of the apps I’ve downloaded trial versions of can be installed without installers on my Mac. I hate looking at urls like


. They are ugly. I hate that every single time I try to download something, you make me fill in the same damn form about how many people are in my company and how long it will be before I make a purchasing decision. I hate that you try to get my phone number on that form. (Note: if you make a phone number mandatory but do not validate its format, don’t be surprised if people write “hah!” in the form field. As in “hah, why would I possibly want you to call me to bug me about what I thought about your bloated proprietary software?”) I hate that you automatically check a box that says the best way to contact me is by phone. I am a geek. The best way to contact me is never, ever, ever by phone.

All of this to try out AS3. C’mon Adobe, you want me to use your platform or not? Stop making me fill in your stupid forms.

Popularity: 6% [?]

Testing in Rails: Way More Trouble Than Flossing

Posted by amy on June 27, 2007

So the other day Max and I had a joint interview for a Rails job, and the hiring manager obviously felt that our knowledge of testing in rails left something to be desired. Too true, too true. But he also told us that he thought that learning to test in rails, and learning TDD in general, was basically straightforward and simple. As in, “you are idiots that you flubbed your answers to my questions about it.” I am sure we are idiots for some other reasons, but not completely grokking TDD should not be one of them. If TDD were easy to grok and easy to do, there wouldn’t be so much evangelizing around it. There wouldn’t be courses and lectures and demos and new articles every day about why you might want to bother doing it. Here’s Gregory Brown, just a couple weeks ago, still having to argue that rails testing is Not Just for the Paranoid.” :

The real issue most people have with testing is not that they think it’s a bad idea, but that it often means a whole lot more configuration, a whole lot more to learn, and lots of things that smell like extra work. Folks who have been in that crowd will be pleasantly surprised when working with Rails.

Thanks Gregory, but no, they really won’t be pleasantly surprised. Or at least, not immediately. We’ve been working with rails testing since March, and it still smells like more stuff to learn and more work to do. I’m sure it’ll start seeming easy in the future, but right now, not so much.

First off, there’s fixtures. Apparently everyone important agrees that rails fixtures suck. But mostly no one tells you this when you’re first learning to write tests. They reload before every damn method, which would be useful, except that they slow your testing down amazingly. I was feeling very proud of myself for using a Rails Recipe for erb in my fixture files to generate lots and lots of test data for very little effort, and wow, did it show in test slowness, not so much on my machine, but on Max’s, which is older and slower. Then there’s that whole weird transactional fixtures flag that Max wrote about, that no one tells you about but that can cause your db not to look anything like what you expect at the end of a test method. Lots of people refuse to use fixtures at all, or only use them to, hmm, load data directly into the test db, not for testing. Other people point out that fixtures are a pain to keep updated when you make changes to your db, so every time your model changes, all your tests may break because your fixtures no longer work properly. So then a model change involves: change your model. Make a db migration. Change your fixtures. Change your test code. Someone has written a nice little fixture migration task, but at this point, I think we’ll just change our testing strategy to not involve much in the way of fixtures.

Then there’s the TDD/BDD and third-party testing tools thing. Do we invest our efforts in TDD even though BDD is the new big thing, so should we just skip straight to RSpec? Do we learn Test::Unit really well before we switch over to ZenTest‘s Test::Rails? What about MonkeyTest? And rcov?

Oh, and how about assert_select? I turned around the other day and suddenly I was knee-deep in the DOM. All I wanted to do was check to make sure that when my user was viewing an item that belonged to him, he also saw two buttons, ‘edit’ and ‘delete’. And that when he wasn’t, he didn’t. It wasn’t obvious how to do it, and it turns out that if I want to make it easier to use assert_select, I probably need to be putting way more ids in my html tags. And then, I added a new feature, and a new button, and my tests broke.

Of course, tests are always breaking. I understand that it is a feature, not a bug, to be forced to understand all the implications of new code. Still, it’s frustrating.

Finally, and this is, perhaps, the root of the problem, there’s all the additional decision-making overhead imposed by the very act of testing. Not all this overhead is ‘good’ overhead — that is, not all of it ultimately contributes to the quality of your code. Most of it is just one niggly decision after another. How do I organize my test code? What do I test? How many tests are enough? What should be its own test method, and what should just be a couple of lines in some other test method? Should I use setup or not? Fixtures or not? Which frameworks? There are fifteen different assert methods that will do what I need them to do, in slightly different ways: which one should I use? Oh wait, is that one deprecated? How come this assert method doesn’t work? Oh, because it’s a Test::Rails method, and I’m not actually using Test::Rails, I just saw it somewhere. All those decisions are exhausting.

Bitch. Bitch. Bitch. I realize I may now have destroyed all my credibility as a test-driven-developer by complaining about all the things I don’t get and don’t like about TDD in rails. But I think it’s annoying to be struggling with something and read nothing on the internet about it other than “it’s easy and awesome”. I have drunk the TDD kool-aid, obviously, because if I hadn’t I wouldn’t bother with it since it obviously causes me a fair amount of pain. And maybe in six months I too will say “hey, yeah, testing in rails is easy and fun!” But right now, it’s neither easy nor fun. But right now, today, I am saying it loud and saying it proud, to you, the internets, to you, other struggling Rails developers, to you, the world: TDD is good for you, like flossing, but it is much, much harder.

The moral of this story is that every night as you floss your teeth, you should thank your lucky stars that something so good for you is also so easy to do. I know I will.

Popularity: 12% [?]

Transactional fixtures in Rails: a head-banger

Posted by max on June 26, 2007

Amy and I were banging our heads today over some model unit tests we were running in Rails. Why on earth did the following updates not show up in the database after the test suite ran? The assertions all behaved as expected.

    item.postal_code = "02138"
    assert item.valid?
    assert item.save

I mean, consarn it, we saved the record! Shouldn’t it be in the database?

Well, the answer turned out to be fairly simple. ActiveRecord’s fixtures, will, by default, rollback everything that was done on the database during the method in question, unless you set

    self.use_transactional_fixtures = false

in your test class. I had strongly been under the impression that the fixtures were loaded once at the beginning of each method within a test class.

Now that we know that the logic is actually behaving as expected, we are back to the default behavior (i.e., using transactional fixtures.)

Reference here.

Popularity: 12% [?]

Typo to WordPress migration

Posted by max on June 25, 2007

The Stuart Johnston posting Automatic migration from typo to WordPress got us part of the way from Typo to WordPress, but a number of things have changed in Typo since those scripts were written, so it took some jiggering to get working. We were at Typo 4.1, and the database schema was somewhat different.

This is what I did to export the data from Typo:

bash$ mysqldump -u username -p name_of_typo_db articles_tags tags categorizations categories contents feedback > dumpster.sql

Then I imported that data into the WordPress database (just did “source dumpster.sql” within mysql), then sourced typo41_migrate.sql, which is modified from Johnston’s typo_to_wordpress_with_utw.sql script.

Comments welcome on the utility of my process.

Popularity: 11% [?]

Stupid Job Postings: Worst Job Title Ever

Posted by amy on June 25, 2007

“MS/SQL Developer/Anal”

I swear to god I did not make this up. What, you couldn’t spare the extra three letters?

Also: why do you ask for our salary history? Do you really want to hire someone who is un-savvy enough to send you their salary history along with their resume? Do people actually provide salary history?

Popularity: 7% [?]

Moved to WordPress

Posted by amy on June 17, 2007

So we’ve moved the site over to WordPress from Typo. We experimented with two rails-based blogging engines, Typo and Mephisto (which seems more popular in the rails world right now), but WordPress is a mature and widely adopted platform and in the end it made more sense to us to go with it. We’d rather not be solving software problems others have solved a million times over. (Which is why we also won’t be producing a to-do-list app any time soon. Online to-do lists! A billion to choose from, and yet somehow, none of them make my work get done. Though actually, I just bought a copy of the PDF book Flexible Rails, since I’ve decided to pick up AS3/Flex in my spare time, and the tutorial project in the book is, of course, an online to-do list.)

I’ve been delaying posting this notice because I keep looking for a blog post I read a month ago which convinced me I ought to think about WordPress, as it was an explanation for a rails blog running on WP, and a damn good explanation at that. But I can’t for the life of me find it again. I found several other people who moved to WP after experimenting with the rails blogging engines, but not the post I remember. The explanation was, basically: right tool for right job. WP is good tool for blogging. No need to reinvent. Etc. Except the post was more eloquent than my restatement. Oh well. Lost in the ether.

Also, Max had to run a cron job doing some voodoo the details of which I forget to keep the Typo instance in good shape. WordPress is faster, and, we hope, more stable. (No, I am not making a comment about the stability and speed of Ruby on Rails in general, just a statement about one instance of one app on one host. YMMV.)

Anyway, Max has a script for migrating the database from Typo to WP, and he’ll post it any second now.

Popularity: 9% [?]

Email is not a fat pipe. We forget this at our peril.

Posted by amy on June 11, 2007

The other day we put a prototype build of a web app up for our clients. Fire away at it, we said. Tell us what is wrong with it! We even had a section in the release notes called “How to be a QA person” (It’s a small project, we don’t have QA, hence our clients are, basically, QA).

Of course, we were pretty proud of our app. Of course, they came back with lists and lists of embarrassing bugs, complaints, features they didn’t understand, etc. The lists were not bracketed by nice polite “we love the app, we’ve just got a couple of teensy little issues with it.” Although the emails they came back in were entitled “Bugs 1, 2, 3, etc.” not everything in the lists were actually bugs. Developers are very defensive about “bugs”. The typical user considers anything that doesn’t work the way he wants/expects it to to be a bug. The typical developer considers bugs to be only things where they, personally, wrote code whose logic was not correct.

So Max comes in to me and says “wow, what do we do about the clients and all their bug reports?!” Our immediate emotional reaction to their emails was that they were irrationally pissed at us and didn’t understand anything about how software development works and were a pain in the ass and were probably going to fire us for giving them such buggy code.

But then we were able to sit back, take a deep breath, and reason together:

First, our clients did exactly what we asked them to do, and they did it well. They gave us fantastic feedback on the app that would help us focus on the most valuable changes we could make for them. When clients don’t give feedback, you’re screwed, because you don’t know how to make them happy. Our first emotional response is normal, and we’ll probably never get rid of it. In fact, we probably shouldn’t get rid of it, because the emotional response is there to kick our asses.

However. (And this is my completely based-on-popular-science-books-by-eminent-yet-readable-professors-theory). When dealing with other humans, we humans expect a fat pipe. We evolved for person-to-person, face-to-face contact. Our faces, bodies, and voices are unbelievably expressive. Compared to the fat pipe of person-to-person contact, words in email are a trickle of information. So when we get an email that elicits any kind of emotional response at all, our brains start flailing around wildly, looking for all the meta-information we expect to come along with it: the expression on the face, the tone of voice, the direction they were looking, and so on. And when we can’t find it, we make stuff up. In no time, we’ve filled up the fat pipe and satisfied our “what do we do now?” programming with _entirely false, absolutely imaginary information_. Those of us who are naturally pessimistic generate false, depressing information. This makes our initial, proper and correct ass-kicking emotional response escalate into a neurotic, counterproductive, self-perpetuating emotional response. Not good for business.

One moral of this story is that developers should not take user complaints personally. This is obvious but easily forgotten. The other moral of this story is the one I’m really interested in: when our brains don’t have the information they expect to have, they just make it up. And it’s really easy not to notice when it happens, because the made up information looks just like all the actual-based-on-fact information our brains have collected. Hence the unreliability of witnesses.

The lesson, then, is that, for stuff that matters, _don’t assume your brain has the facts right_. Take the time to sort out what you can possibly have evidence for from what you just made up because you _didn’t_ have any evidence.

Popularity: 7% [?]

Meta-object-class-thingies in Ruby

Posted by amy on June 08, 2007

Today I read RubyFleebie on the Ruby Object Model :

Objects are instances of Classes, which are, of course, also objects. Object methods are stored inside the instance of their Class, but Class methods are stored inside something called a meta-class. The superclass of a meta-class is a meta-object-class. Or something like that.

Or just say, like the famous (to parents of preschoolers, anyway)three singing pigs: “la, la, la, everything’s an object!” and file it under “huh?!” along with dependency injection.

Anyway, the most important takeaway from this blog post (and yes, Max, I did use the term “takeaway” just to annoy you!) is that in Ruby even things that do not look anything like objects are objects. Unless they’re methods, even when they don’t look like methods. Which is why you can use the simply gorgeous construction 5.times do { #some stuff }. Look ma, no primitives!

quack. quack.

Popularity: 5% [?]

Code Quote

Posted by amy on June 04, 2007

From a fascinating blog called Coding Horror:

It’s painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can’t get away with no code, the next best thing is to start with brevity.

Popularity: 4% [?]