In the last couple of months I’ve been playing a lot with Go and did what I always do when learning a new language: use it for a small project. That project has been open to the public on GitHub for a few weeks now and is now in a usable state: Watchgopher.

Watchgopher allows you to watch certain directories and run custom commands whenever a file in a specified directory changes. It is supposed to be simple and give you control of what happens to your files: it only notifies one of your commands whenever something happens it should know about.

Let me guide you through a simple example to show you what Watchgopher can do. But first, make sure you have Go installed and then run the following command to install Watchgopher on your system:

1

go get -u github.com/mrnugget/watchgopher

Now the watchgopher command should be available on your system and it’s time to tell Watchgopher which directories to watch and what to do about any file events occurring in them. So let’s create a simple configuration file in JSON format:

Being disciplined seems to be hard, something you are or not, no matter what. People certainly talk that way. What I found is that being disciplined is quite easy. It just takes some tricks and practice.

From time to time someone tells me I’m disciplined, mostly because of something I did or said about something I’m doing. And after being called disciplined, more often than not, I hear: “I could never do that, I wish I could, but I’m too lazy.” But here is the thing, you see, I’m lazy too, but I don’t want to be. So I keep myself from being lazy.

When your harddrive is running out of space, chances are good that there are files you can safely delete in order to free up some of that space. A safe bet are archive files, like ZIP and RAR-files, you’ve already decompressed.

I went on a little ride to put together a command that shows me how much space a certain type of file take up. There first thing I did was finding those files…

The next time you’re trying to think of something you could put into code and you shrug of ideas because they’ve already been implemented, try this: Write a cover version) of a piece of software.

Try to imitate software. A project you like, a project you use, a project that implemented the idea you just shrugged of. Imagine yourself in a software cover band and try your best to replicate it.

Why? It’s surely a waste of time, I hear you say. And if we’re talking about paid software development I fully agree. But consider yourself having a couple of hours to spare and you’re eager to write some code: covering a piece of software proves to be a great way to gain knowledge and become a better programmer.

I’ve been a Vim user for a long time but only in the last year I actually started to really use it. No, I don’t mean to say that I spend years of my life with an opened editor on my workspace and just stared at it. What I really mean is that those early years of my Vim usage and knowledge mostly consisted of h, j, k, l, :wq and :%s/replace/this/g. That and syntax highlighting was pretty much Vim for me.

One of the things that makes Vim so great for me is that it doesn’t force you to use or understand something. I was able to get work done with just the basic knowledge I had. But then came that moment when I stumbled upon a blog post about Vim’s text objects and my jar dropped on my keyboard: “So that’s how it works?!”

Vim has a steep learning curve and there are bumps on the road where you can get stuck. And I know a lot of people do get stuck. You may like it there, being stuck, but keep in mind: sometimes it’s just a little tip that can get you forward. A small push that gives you an AHA! moment. Thankfully there are a lot of these available everywhere, though sometimes they are not that easy to find, which is the reason I’m writing this post.

The following is a list consisting of screencasts, video tutorials, blog posts, tips and tricks concerning Vim and how to master it. The items on the list are the ones that got me forward when I was stuck on my way to Vim wizardry (mind you, I’m not there yet, not even close but I’m wearing the nice hat anyway). I bet someone can find some use in this.

In my last post I explained how to implement a search autocompletion backend using Redis. This week I used the described implementation with its add_movie method to put thousands of movies into my Redis database in order to use them for the autocompletion on anygood.heroku.com. It’s the same method as described in the last post, but with important change I didn’t think about too much: I did not overwrite the score of the members in the sorted sets. The method I used for adding movies looked like this:

1
2
3
4
5
6
7
8
9
10
11

def add_movie(movie_hash)
  prefixes    = prefixes_for(movie_hash[:name])
  hashed_name = data_hash_key_for(movie_hash)

  prefixes.each do |prefix|
    score = REDIS.zscore(index_key_for(prefix), hashed_name).to_i || 0
    REDIS.zadd(index_key_for(prefix), score, hashed_name)
  end

    REDIS.hset(data_key, hashed_name, movie_hash.to_json)
end

Adding movies took suspiciously long, longer than I thought it would. Looking at it now it’s pretty easy to tell why: it was exactly that small change that lowered the speed of my importing process, I did cache the member score in every prefix set and then used in the REDIS.zadd line. Every time a movie was added, for each of its prefixes the score of the correspondent sorted set member was saved and used again. That’s not bad at all, no, it didn’t slip in there either! Heck, I wrote tests for this. But looking at the code I concluded that it was not a feature I needed. Using the code above, every movie would have a different rank in the autocomplete output according to the user input. One movie could be ranked higher when the user typed in the and ranked lower when the input was dark. That is pretty cool, but I wanted a different behaviour: the sorted set members associated with one movie should have one score, the same one in every set. And after running some benchmarks I found out how implementing the wrong behaviour slowed me down.

I spent the last weekend building a caching system for AnyGood using Redis to save API responses for certain amount of time. Since the next item on my TODO list was autocompletion for my search form I started googling around looking for solutions involving Redis. I stumbled upon two great posts examining this particular topic: The first one written by Salvatore Sanfilippo is a great explanation on how to use Redis for autocompletion and goes in great detail when explainin the algorithm. The second one by Pat Shaughnessy is a great help when explaining Sanfilippos algorithm and comparing it to Soulmate, “a tool to help solve the common problem of developing a fast autocomplete feature. It uses Redis’s sorted sets to build an index of partially completed words and the corresponding top matching items, and provides a simple sinatra app to query them.”

So I spent a good amount of time studying those articles and reading through the source code of Soulmate before I decided to write my own solution. Why? Because it was a rainy sunday afternoon, playing around with Redis is fun and I wanted to learn more about it. Plus: I wanted multiple phrase matching and search result ordering. Soulmate did all that and a bit more but just setting it up wouldn’t have the same learning effect. And since I was out to play, I might as well have fun. So let’s see how to this…