Hacking Redis To Save Money Jan 3

Check out my latest post on redis!

Site note – I’m kind of diggin’ medium for writing.

Scaling the 8tracks Music Player Dec 24

I started using medium to see if I would write more. First post is Scaling the 8tracks Music Player. check it out!

MacVim Tip: Tabs Per Project Nov 20

I dislike having too many windows open on my desktop. If I can consolidate them then I will. Here’s a tip to do this with MacVim.

Use :lcd path/to/proj instead of :cd path/to/proj in the new tab.

:cd will change the working directory for the whole window, while :lcd does it for the current window.

My vim setup uses ack.vim, NERDTree, and command-t plugins. These depend on the current working directory. If you’ve ever decided to open another project in another tab instead of another window, you know that running these plugins will not search within the new project directory. Well, now when you open a new tab use :lcd to move to that directory first.

For more info on :cd and :lcd you can run :help current-directory to find out more.

To ORM Or Not To ORM Jul 23

I spend most of my time building/fixing/maintaining the infrastructure at 8tracks, but every now and then I have the opportunity to do some good old fashion ruby web application programming. This week happens to be one of those times. Everything was glorious … until I needed to make a decision.

Do I use a gem or roll my own library to handle feature X?

I hate making this decision. It’s amazing when it’s easy. For instance, choosing to use the aws-sdk gem over rolling my own AWS library (it sucks just generating the stupid signature much less making an normal API call). I face so many facets dealing with choosing a gem vs. rolling my own. I always tell myself to suck it up and choose one so I can move on, but I never fail to change my mind shortly afterwards. And then change it again. And again. And again.

I was in this horrible state yesterday. Working on an internal sinatra/backbone.js/mongo application I had to choose whether or not to add a mongo object relational mapping (ORM) gem or roll my own. For the past several months I didn’t need to have any ORM as simple procedural code was more than sufficient. The application logic mostly existed in the browser with Backbone.js. Sinatra was a simple pipe to load mongo data to the browser. It was extremely efficient and simple.

But I needed more logic in ruby land. I thought I could add more helper methods to manage hashes, but that soon became unmanageable (for me anyways - I have a hard enough time remembering two variables much less 10 different helper methods). The features I wanted to add begged for more behavior that suits a model class. I attempted to add one of the mongo ORMs, but some of the conventions I used in the application conflicted with the way the ORMs behaved and would require that I write code to massage the gem into place. I decided to attempt rolling my own ORM that behaved like ActiveRecord. This was fun until my Superman ego deflated and I realized the scope of what I was trying to do. As usual, the scope was huge. I was sad. I spent many hours yesterday trying out each approach but to no avail. It’s hard replicating these huge libraries!

Then something clicked last night. What I really needed was a class around the hash that would allow me to CRUD it. All other access to the hash would behave like a normal hash. This concept basically made normal ruby hashes in to super hashes. Hashes with logic. Hashes with awesome. And if you’ve ever worked with mongo, that’s basically what is stored in that database. Hashes!

I had been asking myself the wrong question the whole time. It’s not to ORM or not to ORM, but rather CRUD this hash and add a few domain specific logic to the hash. That’s not a question, I know. It punted me out of the horrible decision making though.

So, I spent my time today crafting a small library that would make it easier to manage mongo documents. It was glorious. It even has tests! And I hate writing tests.

Unix `cat` For File Creation Apr 26

I spend copious amounts of time on the servers at 8tracks.com. On occasion, I upload a ruby/base/etc script to the server to test. In the past I normally fire up vi on the server, paste the code in, save it, and execute it. When the script fails because of a bug, I fix the file on my local editor, copy the code, reopen the file on the server with vi, save it, and execute it. This is slow. Here’s a faster way using cat and the CTRL+d keyboard shortcut in a terminal.

$ cat < my_new_file
Hello, world!
<hit CTRL+d here>
$ cat my_new_file
Hello, world!

This removes vi from the equation. This works for my previous tip about executing arbitrary ruby code on the shell.