Category: ruby

  • Sending Build Output to Vim [ruby, rust, vim]

    Vim is actually quite easy to build from source with a make install. You can edit src/Makefile to enable features and custom language extensions. Turns out, I hadn’t scrolled through that file in a while, since version 8.0.1295 comes with an interesting addition – the compilation flag --enable-autoservername.

    Running the editor with a --servername parameter allows remote connections from a different instance using command-line flags or function calls. I’ve been using this functionality to build a custom testing framework in Ruby, but you have to knowingly launch it with that flag. Now, each instance can be available to connect with by default.

    It’s not necessary, exactly – you could always make yourself a shell alias like alias vim="vim --servername VIM-$RANDOM". But the discovery gave me an idea of how to remove a tiny bit of friction from my Rust workflow, and I might end up using the same technique in the future. Read on to learn how to send your build output to a Vim instance for easier processing.

  • The New(ish) Facebook Authentication Process [facebook, rails, ruby]

    Facebook changed their authentication process fairly recently. Instead of using a global user id, users would now get an app-specific id instead. This took me by surprise, and I had to jump through some hoops to get stuff to work with our setup. This is a short post that outlines what we did to work around the problem.

  • Small Refactorings [rails, ruby]

    A common piece of advice for dealing with bad rails code is to avoid making huge rewrites all at once. Instead, make small fixes whenever you see a problem. An often-cited variant of this is the “boyscout rule” – leave the code better than you found it.

    This is solid advice. Putting hacks and workarounds would only make things worse. Rewriting swaths of code for even small features would take a long amount of time and introduce risk. The best approach is to make small refactorings and build new features with new, better, code.

    As with most good advice, this can still backfire. Ever seen an app with five different caching mechanisms and seven different event tracking approaches, all slightly different? This may have been a result of multiple developers going “this is horrible, I’ll fix it”. In the end, they created an even larger mess, despite their good intentions. How did this happen?

  • Thoughts on "Half a Model" [rails, ruby]

    In ActiveRecord, you can use the select method to run the underlying database query with a SELECT for particular fields. As a result, the object simply doesn’t have the rest of its attributes. Depending on the particular table and the use case, this could speed things up. Even without the performance argument, the idea to “get only the things you need” seems perfectly reasonable. This has never quite clicked with me, and I recently realized why. I’ve never encountered the problem viewed from this angle, so I figure it might be worth sharing.

  • Driving Vim With Ruby and Cucumber [ruby, testing, vim]

    One of the more exotic features of Vim is its remote control functionality. Basically, if you invoke Vim with --servername SOME_NAME, you’ll be able to send commands to it with another Vim instance. Using this, I’ve recently attempted to fix a common annoyance with vimscript – its limited testability. By spawning a remote instance and controlling it through ruby code, we can use cucumber to perform simple integration testing for Vim plugins.

    This is not something I’d do for all code I write, but in some cases, it could be a life-saver. My splitjoin plugin is one example of a project that I wish I had a good test suite on, considering the amount of regressions I’ve had when modifying functionality. In this blog post, I’ll describe some ruby code to drive a Vim instance remotely and a few sample cucumber steps you could write to make use of it.