kvz.io

Ruby

  • Published on
    Despite testcases, syntax errors still find their way into our commits. - Maybe it was a change in that bash script that wasn't covered by tests. Too bad our deploys relied on it. - Maybe it was just a textual change and we didn't think it was necessary to run the associated code before pushing this upstream. Too bad we missed that quote. Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to change because in the - Best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, as you already moved onto other things. - Worst case: your error goes unnoticed and hits production. Git offers commit hooks to prevent bad code from entering the repository, but you have to install them on a local per-project basis. Chances are you have been too busy/lazy and never took the time/effort to whip up a commit hook that could deal with all your projects and programming languages. That holds true for me, however I recently had some free time and decided to invest it in cooking up ochtra. One Commit Hook To Rule All.
  • Published on
    At our company we use Capistrano for deploys. It reads Ruby instructions from a ./Capfile in the project's root directory, then deploys accordingly via SSH. It has support for releases, shared log dirs, rollbacks, rsync vs remote cached git deploys, etc. It can be run from any machine that has access to your production servers. Be it your workstation, or a Continuous Integration server. So all in all pretty convenient but typically it assumes you know what servers you want to deploy to at the time of writing your Capfile. What if the composition of your platform changes often? Will you keep changing the Capfile right before every deploy? Seems like effort ; )
  • Published on
    If you want to set up Ruby on Rails on Ubuntu Lucid from scratch, there are quite some articles online to choose from. I found most of them involve compiling, only highlight 1 aspect, or are a bit outdated. On top of that, getting it right can be hard as there are a number of issues related to Ruby and Debian/Ubuntu. This is an attempt to put all the sweet info in 1 place.