Time Travel Toaster

I’m pretty frustrated by the available Mac text editors out there these days. I prefer Vi-style keymappings, which I’m willing to give up if it’s really worth it, but currently I’m fastest with those. I also want it to be a real Mac app and look sorta nice and modern, not like it was coded in the 80’s. Other hard-to-live-without items are the ability to save all open files when the window loses focus, and of course the no-brainers like reliable syntax highlighting and some handy language-aware auto-completions for the main Rails languages (Ruby, CoffeeScript, JavaScript, HTML, ERb, CSS, Sass, etc.). Again, I’m willing to compromise those if I get something really good in exchange.

• (Mac)Vim – Needs lots of configuration and plugins to be awesome. Something like Janus or yadr is pretty nice, but also very complex and brittle. Getting ctags to work consistently, as one example, is a pain. It’s so big and patched-together, there’s always something not working quite right. It can also be pretty slow at times once you’ve got all the plugins and config setup. Doesn’t look very awesome.
• Vico – Very cool concept, but updates are often slow to materialize with little communication from the author in between. And it’s not open source, so there’s not much anyone can do about it. It’s very new and so a lot of things don’t work quite right (syntax highlighting is somewhat inconsistent, for example). At least it looks semi-nice. Probably the one I hate the least currently, however.
• Emacs – Very awesome editor that can do a LOT. But also extremely complex to configure and get working well (needs lots of plugins like Vim) and seemingly can’t do some simple things that I have a hard time living without (such as saving all open files when the window loses focus). And I just cannot see how its keybindings could ever be as pleasant or efficient to use as Vim’s. Also, it’s ugly as hell. /me dons his Stallman attack suit.
• Sublime Text 2 – I’ve tried it a couple times, but the Vi emulation is pretty flaky and the configuration is a terrible mess of text files. There are already two hard-to-configure editors in the world, we don’t need another.
• TextMate 1 or 2 – 1 is old and busted, and 2 is still pre-release. Not enough of a win to make me give up Vi keybindings. Is there any sort of Vi emulation for TM1 or 2?
• Coda 1 or 2 – This blog post sums up the situation perfectly: http://jeffcroft.com/blog/2012/may/22/on-coda-2-and-diet-coda/
• BBEdit – Not great language support. Doesn’t seem to be aging well.
• Kod – Doesn’t seem to be maturing very quickly. Still at version 0.0.3.
• Any Java app – No. Just no. Ugly, slow, crashy, and awful.

I really wish there were something clean, simple, and powerful out there. Right now I’m going to continue to keep my eye on Vico while every once in a while popping back into MacVim (with yadr).

I’ve seen a lot of advice around the web to disable TLS or turn off certificate verification when using Ruby 1.9 and the openssl gem. This is motivated by seeing the error “hostname does not match the server certificate” in log files and application crashes.

What’s happening is that OpenSSL is trying to establish a secure connection (using SSL/TLS just like your web browser when accessing a URL that starts with “https://”) but it fails because the hostname the certificate claims to be for doesn’t match the hostname of the server you’re connecting to. Now, when this happens in your web browser, it means something really bad could be happening and you should NOT proceed. Someone could be impersonating your bank, for example, ready to intercept your access credentials and steal your money. So why on earth are so many people recommending circumventing basic security in Ruby 1.9* apps?

Here’s how you REALLY fix this problem:

Figure out what hostname OpenSSL is trying to connect to. I’ve submitted a pull request to the Ruby Github mirror to address this, but until or unless they actually incorporate that into a released version of Ruby, here’s how you can make openssl a little more forthcoming with the details:

Open up the file lib/ruby/1.9.1/openssl/ssl-internal.rb in your favorite text editor. Go to line #121 which should look like this:

def post_connection_check(hostname)
  unless OpenSSL::SSL.verify_certificate_identity(peer_cert, hostname)
    raise SSLError, "hostname does not match the server certificate" # <= line 121
  end
  return true
end

Now edit that line to say this:

raise SSLError, "hostname \"#{hostname}\" does not match the server certificate"

(Add the \“#{hostname}\” part. The backslashes are important.)

Now do whatever you were doing to trigger the SSLError before, and you’ll see what hostname OpenSSL was expecting the certificate to match.

If it says “localhost”, then you can probably safely disable SSL/TLS like everyone else is recommending. If it says anything else, you probably want to keep it secure. The Internet is a weird, wild place.

If you’ve decided to go the secure route, then the next steps are just like securing a website. You need an SSL certificate for the exact hostname you’re trying to secure (the same hostname output by OpenSSL’s new error message you just created). You can get those from a variety of sources around the web. If you don’t know where or how to get one, just Google around a bit. You then need to install that certificate into whatever server is on the other end of that connection. So, for example, if you’re trying to send email via ActionMailer, then you need to install the cert into the mail server listening on the host and port you’re connecting to. You’ll have to consult the docs for your mail server software for the details.

*Ruby 1.8 defaulted to not caring if the hostname matched or not. That’s why this is a new error message for those converting from 1.8 to 1.9. In 1.9, the Ruby devs decided to be “secure by default,” and I applaud them for it.

Update

My pull request has been accepted into Ruby core, but I don’t know when it will actually show up in a released version of Ruby. Maybe 1.9.3-p[next], maybe 1.9.4, maybe 2.0. Who knows!?

I just tried to assign a label to each of my GitHub issues, and wow, was that a mistake. When you select more than one issue and then click the Label dropdown, it pre-selects every label that any of your selected issues has. So when I added one more label and hit Update, it assigned every label that was assigned to any issue to every issue. My labels are useless now and I have to start over. What a mess.

While I certainly share some of the blame for not noticing that before clicking the Update button, that is a pretty braindead system that GitHub has built. There is never a time when I want to assign the union of every issue's labels to all selected issues. But I do often want to assign one label to many issues. Terrible.

UPDATE: Here's GitHub's response to the problem:

From: Petros Amiridis (GitHub Staff)

Subject: Rollback Issue labels?

 

Ooops! That sucks! I am sorry about that, but this is how it works currently. I don't think you can add one label to all issues currently.

So yeah, watch out for that!

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 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!