by, for, and about women in science, technology, engineering, & math

[cross-posted from git init and get in it]

In my last post, I complained about autotest being broken. Well, it’s not actually broken. I’ve just fixed my problem, and it turned out to be one of the perils of the way I went about the conversion of my project to the new version of Rails, and not at all related to the Rails upgrade or the autotest gems.

The Missing Piece

The missing piece was that in my new project folder, I didn’t have a .rspec file. That file contains one crucial line of code, --drb. That’s all. (Ok, I actually have a second line in mine, --color to show red/yellow/green for fail/pending/pass, but that’s not the important part.)

That one invisible file with the one short line of code is, approximately, the connection that allows spork to load the project for testing and allows autotest to recognize the location of the tests. The rspec wiki page regarding autotest explains that having a .rspec file in the project root “tells RSpec to tell Autotest to load RSpec’s autotest extension.” Thank goodness I found the advice of the third responder on a year-old StackOverflow question!

How It Happened

This problem was only tangentially related to my Rails version upgrade. Because I created a fresh project and copied over only the relevant bits of the code, it was easy for me to miss the invisible .rspec file. (For my fellow noobs, any file or folder beginning with a period will be invisible in the default file navigation view of your system. A lot of system files are named this way to prevent people accidentally altering them.) By copying over most of the code I needed, I may have actually blocked myself a bit. I think that if I had set up RSpec properly, it would have created the file for itself based on my system-wide preferences for it. The dangers of cutting corners, eh?

[cross-posted from git init and get in it] The hubby (a longtime PHP developer and fellow Rails n00b) is super-excited about the recent release of the Rails 3.1 beta because it has support built in for things like Sass (a.k.a. SCSS) and CoffeeScript. These things are nifty, although besides Sass, I’m only vaguely aware of most of the things he lists off. I agree, the new version of Rails will be fun. Where we differ is how much fun trying to use it in beta is.

I’m used to how things work in Rails 3.0. I didn’t have any real issues with how it worked, because I don’t do enough scripting (read: almost none) to care about CoffeeScript, and I was content getting the hang of regular CSS before branching out into Sass. My projects weren’t of a scope where I needed those features. So switching to 3.1 for a project the hubby wants to work on with me was more a favor for him, and I thought it would be an opportunity to get used to some of the features a little earlier.

Hoo boy.

I forgot, or perhaps didn’t really know, how difficult bugs can be to track down in a beta, especially when I make plenty of new and exciting mistakes on my own at this point that I have to diagnose. And there are some fun ones to make when moving a project from one version to another!

For example, after I renamed my old version of the project, I had to copy over “just the essential files” to the new version of the project. First try, I copied over way too many things and broke it. Rather than try to roll back the changes I’d made, I just started over. Second try, I copied over only the page code and the routes file. When I tried running my site locally (just on my own browser, not on the web), I found I needed to copy over my javascripts, stylesheets, and images. So I added all those things into the ‘public’ folder where they lived in 3.0, but it turns out they live in a new place in 3.1, the ‘app/assets’ folder. And then I had to change the lines of Ruby in my application layout that called the stylesheets and the javascripts that I use because the syntax changed! And finally, I needed to copy over my ‘db/migrate’ folder and run “rake db:migrate” to make my user model work again.

Then the hubby found out that in 3.1, password encryption is a built-in feature (which is an AWESOME change), so I rolled back two migrations in which I had implemented my own password encryption. Then I spent a while looking at the one blog post everyone linked to on the topic and trying to figure out what the heck they meant by “Your model will need a field called password_digest”. Where was I supposed to add that, and how? Well, it turns out that means you need to add a column to your database table with a migration: class AddPasswordDigest < ActiveRecord::Migration def up add_column :users, :password_digest, :string end

end And then run “rake db:migrate”.

So I did that, and then I wanted to annotate my models to see if the changes had gone as I expected, at which point I ran into a whole new problem: I couldn’t run the command “annotate”. So I tried to add it to my Gemfile. It was already there, it seemed, but I tried moving it into a different group. I tried different annotation gems. I tried destroying my Gemfile.lock and re-running “bundle install”. Nothing worked. I thought the beta had broken something badly. I finally gave up on Google to answer the question and was writing up a question on stackoverflow.com when the hubby looked over at my screen and asked what was going on. With his greater experience in debugging, he found out that the problem was that I hadn’t quit my text editor between when I deleted my first attempt at the project and when I created a new attempt of the same name. Basically, the version of the Gemfile I’d been editing was the version in the trash. D’oh! But come on, how un-intuitive is that?

And now, annotate is STILL broken! It shows up as being installed now, but it still gives errors when I try to run it. It hasn’t been updated since November 2009, so it may just be broken with the new version of Rails. Ick.

Also busted in the beta: autotest. This makes me very, very sad. Having constant reporting on whether my tests pass is really nice, and would have been extra-nice now, when a bunch of stuff is broken and I’m going to have to rewrite at least half of my tests. At least running “rspec spec” still runs my tests, but doing it manually after each of my adjustments is going to be a pain in the butt.

[cross-posted from gitinit.wordpress.com]

Ha! For once, the default title of a WordPress blog is relevant! Because as all programmers know, and anyone dipping their toes in the field will quickly discover, the first program of just about any language you learn to write is one that produces or displays the text “Hello world!”

So, yes, hello world. I’m Joan, and I’m teaching myself Ruby on Rails with the help of the fantastic Ruby on Rails Tutorial. There are always more “rabbit holes” though, and I’m also learning about version control with Git and hosting copies of my open source code on GitHub, and scalable hosting on Heroku (free for small projects). I run up against various problems with my code, then have to track down the source of my errors and figure out how to fix it, and often get side-tracked with other things I’m learning as I dig into the problem. Bugs in my code are annoying (I didn’t get it right!) but I definitely learn a lot from solving them, and hopefully I can share that knowledge with other people here. I expect the technical level of the writing to start fairly low and go up over time as I run into more challenging problems than “Where did I end up with a typo?” or “Why does Heroku make it so hard to find their relevant support documents?”

The ACM’s Dot Diva initiative is seeking technical women in their 20s to profile on their site in order to inspire high school girls. (And while we’re on the topic of profile of technical women, don’t forget that Stemming wants to post a profile of you too for next month’s Ada Lovelace Day.)

In San Francisco, Sarah Allen has an internship opportunity for a new Rubyist.

Also in San Francisco, featuring Sarah Allen (and Sarah Mei), and Ruby-related: the San Francisco Ruby on Rails Outreach Workshop for Women is back next weekend! There are only a few spots left, so sign up now if you’re interested. I was a TA at the Boston version of this last fall, and I cannot recommend the workshop highly enough — it’s free, completely newbie-friendly (whether you’re totally new to programming or just new to Ruby), childcare is available, everyone is nice and friendly, and it’s overall a super-fun way to get started with Ruby and meet some great people.