Time Travel Toaster
Sending household appliances twirling through the 4th dimension since twenty aught five
-
Rails app, continuous integration, your database, and you
I recently setup a Jenkins CI server for a client and put their Rails app in it. When someone committed a change, it ran a CI build. However, when someone committed a migration, rake would abort with the dreaded "pending migrations" error. So I just added a db:migrate step to the ci:build task, and all was well…
…or so I thought. In this particular case, the CI server builds anytime someone pushes code to either the "develop" or "master" branch (using git). Pushes to develop happen much more often than master, because master is the "stable production release branch" and develop is the "push everything here when it's ready to be shared with the rest of the team and integrated into the bleeding edge version of the app" branch. One consequence of this is that master builds will often assume an older database schema than develop builds because those migrations haven't been merged with the master branch yet. So running "rake db:migrate" in the ci:build task broke. The migrate task doesn't understand moving the schema backwards and forwards unless you explicitly tell it what to do. However, there's a much better way to do this. The file db/schema.rb is a current snapshot of your database and it should be checked into your code repo. So if you just load that into the test DB before each CI build (via the handy "rake db:schema:load" task), then you're golden. Master has its snapshot, and develop has its snapshot. Everything's fixed! Er... Here's the wrinkle: When you run rake spec after doing that (within the same rake ci:build über-task), it executes the following tasks: ** Invoke spec (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load
** Invoke environment** Execute spec
So what? It runs db:schema:load again, no big deal. Nope. Chuck Testa. If you look closely, you'll see that while db:schema:load is *invoked*, it is never actually *executed*. And that's because rake remembers that it has already been executed when we ran it manually before. So the last thing that's been done to your test database is db:test:purge. If you look at your test database at this point, you'll see that is has no tables. And your tests will fail (at least they better). Why are there no tables? Why didn't the manual db:schema:load put all the tables into the test database? Because it put them into the development database. Remember that most tasks default to the development environment when you don't specify one. So we loaded the DB schema snapshot into the development database, and then later when rake is asked to run db:schema:load on the test database, it doesn't run it. So what's the solution? We need to tell rake to re-run db:schema:load. (Don't be tempted here to force Rails.env = 'test' and use the test database for everything. This comes with its own issues and you'll be fighting against the way rake spec is designed to work.) Here's what my final rake ci:build task looks like: namespace :ci do
desc 'Setup CI environment'
task :env do
ENV['CI_BUILD'] = 'true'
ENV['RSPEC_FORMAT'] = 'progress'
ENV['CUCUMBER_FORMAT'] = 'progress'
ENV.delete('http_proxy') # need cukes to be able to connect to localhost
end desc 'Run a continuous integration build'
task :build => ['ci:env'] do
Rake::Task['db:reset'].invoke # drops, re-creates, loads schema.rb
Rake::Task['db:schema:load'].reenable # so it can be run later on the test db
Rake::Task['spec'].invoke
Rake::Task['cucumber'].invoke
end
end That line "Rake::Task['db:schema:load'].reenable" is the key. Once you add that, rake spec will happily resume loading up your test DB's schema and you'll be off to the races.Be the Change
"Be the Change you wish to see in the world" is a common quote attributed to Mahatma Gandhi. But he never said it, and in fact didn't believe the smug, apolitical sentiment it communicates. That and other awesome gems in this NYT article.
My favorite excerpt on the fake Gandhi quote:Here, Gandhi is telling us that personal and social transformation go hand in hand, but there is no suggestion in his words that personal transformation is enough. In fact, for Gandhi, the struggle to bring about a better world involved not only stringent self-denial and rigorous adherence to the philosophy of nonviolence; it also involved a steady awareness that one person, alone, can’t change anything, an awareness that unjust authority can be overturned only by great numbers of people working together with discipline and persistence.
Hmm, great numbers of people working together with discipline and persistence. Why, that almost sounds like organizing!
WTF? No, I don't.
Hey Earbits, heard of HTML5 audio? It's a big hit with the modern browser kids. And it works, these guys are streaming audio with no Flash whatsoever.If you don't have an integration test, you haven't tested it
People doing test-driven development talk a lot about mocking, stubbing, FakeWeb, unit tests, and other mechanisms for testing code in isolation. But that conversation drowns out a fundamental truth: If you don't have an integration test, you haven't tested it. And by integration test, I mean that it hits all the live third party services the production app hits, it hits your database, it runs your daemons (forked in the background, not running in the foreground), and it doesn't mock, stub, or fake anything. If you haven't done that, then your code isn't tested. Period.I've been running into this a lot lately at my day job. In the first instance, I refactored a bit of code to simplify it (by sending it a piece of information already encoded for the API it was headed to), but I neglected to notice (and no test caught) the fact that one line of code in that method (also, don't write long methods) depended on the old format of that datum. This caused reporting records to not be created because they silently failed to validate. No test caught this because all the tests were mocked and stubbed with successful responses. Had there been an actual integration test, it would have tested for the one thing that actually mattered: the damn records get created in the fucking database.I have other recent examples, but I won't belabor the point. Write integration tests first. Write integration tests only, if you have to. But write 'em.Hashed method args
Is there a reason Ruby can't work like this:def do_something(first_arg, second_arg) puts "First: #{first_arg}" puts "Second: #{second_arg}" enddo_something(:second_arg => 'blah', :first_arg => 'yeah') => First: yeah Second: blah
...while still supporting this:do_something('yeah', 'blah') => First: yeah Second: blahIt sure seems like it would be the best of both worlds.Instead you have to do this:def do_something(params) puts "First: #{params[:first_arg]}" puts "Second: #{params[:second_arg]}" end...but that's stupid and terrible because then your method signature tells you nothing (NOTHING!) about what arguments you can give it. And that makes me sad.And positional parameters are a major pain in the tukhus once you have more than three or so. Does the database_mode argument go here? Or is it the address hash? Yeah, fun times.There's probably some reason it can't work the way I want it to.Object#tap considered less readable
Boy am I tired of seeing this in Ruby 1.9 code:find(:id => id).tap { |foo| foo.do_things something_else(foo) if foo.has_bar? this_thing(foo) else that_other end }When writing this:foo = find(:id => id) foo.do_things something_else(foo) if foo.has_bar? this_thing(foo) else that_other end foo
...is both the same number of lines of code and WAY more readable. Friends don't let friends use Object#tap.(But seriously, if you've ever seen a use for it that makes code better--i.e. more succinct and more readable--then I'd love to see it.)Lots of users is not enough
The tech startup world is very focused on building things that attract a large number of users. Startups like this one: http://likealittle.com/ are full of talented programmers and are recruiting madly. Their appeal to fellow entrepreneurial geeks is that they are coding fast and furious and deploying an app that is growing like crazy. Wow, sounds like a cool job, right?But, what does the app *do*? It lets college students flirt anonymously with each other.Yeah. Not interested, thanks.I've spent nearly my entire (post-college) technology career working for political organizations. These places are _not_ geek meccas. They are top-down, management and process-driven dinosaurs. However, they try to actually impact the world for the better. I'll take that any day over interesting technology for an uninteresting purpose.But man, I sure would love to find a place that had both. A tech startup culture with a focus on real, positive social impact. That would be my dream job.GNOME 3 releases alpha live CDs
http://gnome3.org/tryit.html
Hacker News downvoted that shit, because they're stupid. I totally want to try this out. High five for open source innovative desktop paradigms.
Update: The live CD didn't work. It loaded a standard-looking GNOME desktop in OpenSuSE. Guess that's why they call it alpha.Testing exceptions in Cucumber
Here's a handy step for testing exceptions in Cucumber:Then you can test that any When step raises any exception of your choosing. Handy!Then /^it should raise (.+?) when (.+)$/ do |exception,when_step| lambda { When when_step }.should raise_error(eval(exception)) endThe new deficit hawks
From today's New York Times: "The federal deficit cannot be closed simply by rooting out waste and fraud, and Mr. Issa readily acknowledges that many examples he cites will save what amounts to relative pennies in a $3.5 trillion budget."You get what you vote for, America.
-
wesmorgan's Posterous
