Testing Rails: the learning curve
Max and I are trying to learn how to write tests for our rails apps. Like many things in rails, testing seems intuitive to those who understand what’s going on already, but people who claim there’s no learning curve are deluded. The first three times I opened up my test directory and started trying to write test code, I grew incredibly frustrated and confused and gave up. “What’s assigns() do? How do I write my fixtures? Why do I always stick my colon in the wrong place when going back and forth between yaml and ruby code? What should I be testing anyway?”
“Who needs tests?” I thought. “That’s what QA is for! No one can figure this stuff out! I have no frackin’ clue what is going on here, and I never ever will.”
But I kept trying. When Max and I sat down this morning to write tests for our current project, we quickly grew, yes, frustrated and confused. We snapped at each other. Max squinted a lot, and I pointed accusingly at the screen a number of times. “See! See! Do you SEE what we are doing here?!” We couldn’t get one teeny tiny little test to pass. We wanted to do pretty much anything else.
But okay, we said. Learnd-ing is hard, as Ralph Wiggum (or a certain George) might remark. We are frustrated, but we will get it.
Eventually, we got our test to pass.
Now we just have about a zillion more tests to write, and we’ll be all set.
A Word On Job Descriptions
I look at a lot of job descriptions. If the perfect employee jobs came up, Max and/or I would take them. We are also always on the lookout for interesting contracts, cool companies, and weird projects. For clients who want the work done, and don’t care if I bring a nursing infant to a meeting…For work opportunities with the potential for exponential and renumerative growth. For a fast-paced, take-no-prisoners, work hard-play hard up-and-coming, learning organization. Wait, no, scratch those last two sentences.
__What we’re looking for is job descriptions that are not full of crap.__
Most job descriptions are as tedious to read as most resumes. Do they say *anything*? Can even the people who write them stand to read them? I’ll be honest - I cannot bear to read my own resume, or Max’s. Or anyone else’s really. Even the best-written resumes I’ve seen are so bland my four-year-old would eat them without complaint. That’s *bland*, baby. Same for job descriptions. Occasionally I send my resume to a company because they had a puzzle in their job description — Athena Health had a fun one) or because they have an opening for “General Rock Star” (ZoomInfo’s clever recruiter Martin Burns attracted me with that one). The rest of the time I think, “eh, I’d rather be wiping up baby poop.”
I would like a world in which no one was counseled to pepper their resume with impactful verbs, and companies did not seek “ideal candidates” who “posess excellent communication skills” and are “self-motivated.” Resumes and job descriptions would be formatted in a kind of work-yaml:
That’s it. I couldn’t resist putting in some jokey parts, but if you take those out I think we’ve really got a solution to the heartbreak of job and contract-hunting. Let’s stop bombarding one another with “Implemented Tracking System that increased revenue by 17% in 6 months” and “Must be a team player.” Let’s quit with “Detail-oriented”, “compensation package”, “in search of talented individuals” and “demonstrates expertise”. Please, no more “performs a variety of tasks” or “helped to grow the business”. Let’s ban “methodologies”, “proactive”, “interpersonal skills”, and “highly motivated”. I’ve been reading Jakob Nielsen’s website, and he has a nice quote from Winston Churchill: “Short words are best, and the old words when short are best of all.”
The thing about resumes and job descriptions is that there’s really no hope that most of what we say in them is going to be particularly useful in matching people to work. All the interesting, useful things to know about jobs, and about people doing jobs, come out later, after everyone’s already committed. So can’t we all just cut the crap?
JSON, XML, and REST
Last time I paid attention, XML-based web services were the next big thing. My informatics department was very cutting-edge, implementing web services for our apps to talk to one another and to our company’s intranet portal. XML was the big thing you had to know. It seemed enormously complex and confusing, and yet at the same time, simple. At the bottom, XML was data. People piled more and more stuff on top of the data, and made more and more tools to parse the XML that surrounded the data, and insulate us all from the XML, even though the whole point of XML was that it was supposed to be human-readable data.
It got to be that every single job posting you ever saw demanded that you be an expert in XML. This was ridiculous, since to the extent that XML is simply data it means nothing to be an expert in it, and to the extent that it was all the crap you threw on top of the data, it was impossible to be an expert, because even the experts weren’t experts.
Anyway, now all the cool kids are throwing XML out the window, and using JSON to send data back and forth to each other. JSON sounds incredibly dubious since it’s based on Javascript, and you all know what I think of *that*. But even javascript can’t quite manage to screw up the basic data structures, so maybe it’s fine. In addition to throwing XML out the window for data transfer and remote procedure calls between apps, the cool kids now hate it for configuration files (Rails people use YAML, for example.) And also, everyone’s web apps must be RESTful, a thing I don’t totally understand yet but which definitely means *hyperlinks should never, ever have side effects*.
The moral of this story is that by ignoring the world of software for a couple of years while being on the mommy-track, I have avoided, I hope, ever having to figure out what all those fifteen thousand XML standards meant, and jumping in now, I am no further behind on technology than all those other people who are still trying to grok what it means that Rails Edge now supports fully RESTful URL routing.
