Vim - change colorscheme based on iterm profile

I like to change my (neo)vim colorscheme quite frequently, and when I do I want it to match my iterm colors. Many colorscheme authors also provide an iterm color palette, so you can import the .itermcolors file, create a new iterm profile with that palette, start a new session and you have the same vim colorscheme in your iterm. But then, when you launch vim, you still have to type :colorscheme somecolor.

If you have many colorschemes - like I do - you might become bored of doing all of this every frickin time. Wouldn’t it be really cool if, when launching vim from within an iterm session with profile “solarized”, then the solarized vim colorscheme could be used automatically?


Vim - sort ruby methods by name

Yesterday I had to refactor a very large ruby class. It had a lot of methods and, to make it cleaner, I decided to sort methods alphabetically.

Is there a way to do this in vim? Of course there is, and it’s quite tricky - so let’s see how we can do it.

The basic idea is taken from this post on, I just adapted it for ruby. All credits to this guy for his work :)

We’ll use the same approach of the original post: first we’ll collapse each ruby method on a single line, using a defined pattern to replace line terminators. We’ll proceed sorting the one-lined methods, and finally we’ll expand them back to multi-line.

These are the three commands, we’ll explain them in detail later:

      :'<,'>g/\vdef\ /,/\v^\s*end$/ s/$\n/@@@

Let’s do it step by step.


Mocked - a minitest pattern

Minitest is good for mocking, right? Well…

Minitest is gaining a lot of popularity and can actually be a 100% replacement for RSpec. It’s a pure ruby testing framework, it’s fast, light weight, and it supports both a test-unit like syntax and a spec engine with Rspec like syntax.

Still, when it comes to mocking, it can be a little painful. You have to initialize mocks and verify them manually after running the code under test.


Command pattern in ruby and rails

The problem

If you have a growing Rails application and you feel your models are getting too fat you might have a problem. We’ve all been educated with the “fat models, thin controllers” dogma - but sometimes putting all the domain logic inside the models has its downsides.

As an example, the typical flow of an ActiveRecord object through a Rails request involves:

  • fetching the object from the DB based on the params you receive (controller);
  • doing something with the object inside the model (model);
  • when something goes wrong, you set errors onto the model attributes (model);
  • you finally return the object to the view, and present it accordingly (view).

This is gonna tangle a lot of the domain logic to your model (scopes to retrieve objects, validations, and in the worst case even some presentation logic).


Git: preview conflicts

Hi everyone!

What we’re trying to tackle today is a very common problem, that I’m sure all of you encountered. Suppose you’re on your git feature branch, you want to merge it into another branch (being it master, staging, production, whatever) and you’re asking yourself: will there be conflicts?.

If you’re using Github, you can simply open the Pull Request page for your feature branch and look for the following box:

This is informing you there will be no conflicts and a merge will run smooth.

But what could you do if you didn’t use Github, or you were just too lazy to open it? Creating a new branch just to do the merge is a solution, but I was pretty sure git had something better to offer ;)


Null objects in Rails

The problem

Recently I’ve seen in a project I work on a lot of occurrences of this code:

if user.privacy && user.privacy.enables_page?(...)

The first part of the condition above is a bad practice in object oriented design. It forces collaborators of user to know a part of its implementation - it could have a privacy or it couldn’t.

What we want

Wouldn’t it be much better to just write this:

if user.privacy.enables_page?(...)

Hiding the responsibility inside the user class? It would be much cleaner and follow the Tell, don’t ask principle.


Fluentd usage example with bash and ruby



Easily change the path for your Paperclip attachments

Today after releasing an app to production environment I saw a couple of paperclip warnings like this in my production.log file:


Vim regexp example: make a variable out of params

Today I wrote a regexp to change params[:page] into page. Here you are:


Add bundle dir to your ctags

Ctags are a great way to improve navigation between large codebases. Used together with vim they allow to quickly jump to any method definition with just a keystroke - C-]. Adding your bundle dir when generating the tags file will allow jumping to the internals of the ruby gems you are using. Let’s see how to do this.