As I currently work on a distributed team and we’re trying to do more and more pair programming I decided that it’s time to give Emacs a try again. Using tmate in combination with either Emacs or Vim seems to be the way to go due to the lower latency than a proper screen sharing solution.

Right now my Emacs configuration is rather basic, but I think it could be a good starting point for other people, too. This is why I made it available as a Github project.

If you have any problems with it let me know and more importantly (at least for me personally) if you notice anything that I should do differently I’d love to hear from you.

Working with Ruby on Rails in my projects I’m used to running continuous integration on Travis CI. As this is free of charge for open source projects projects I wanted to set it up for my Rust project Iomrascálaí, too.

At first I used the setup provided by Rust CI, but as the project page doesn’t seem to be working 100% anymore and because the Debian package they provide of the rust nightly snapshot for some reason strips the Rust version number I decided to use the official nightly snapshots instead.

or “Help me learn Rust by pairing with me”

After years working in interpreted languages (Ruby, JavaScript) I recently discovered Rust. As I sadly don’t have the opportunity to use Rust directly in a client project, I decided to come up with a toy project to help me learn the language.

As Rust is supposedly good for programs that actually need raw speed (unlike the web apps I generally write) I decided to come back to one of my old time favourites: an artificial intelligence for the game of Go.

I had already tried writing a few of those in recent years (including helping Jason House with his bot written in D), but every time I had the problem that working alone wasn’t very motivating so I never managed to produce a working program.

To combat this I’m trying to pair program with people (i.e. you) to keep me going. So if you’re interested in either learning Rust with me or writing an AI for the game of Go, please get in touch!

For most of my professional life as a programmer I’ve been either working alone as a freelancer or in small teams that didn’t practice pair programming. To improve my skills I want to start to pair program regularly with other people. If you’re interested please contact me or just schedule a session on my dedicated calendar.

I’m open to almost any topic and programming language but I know Ruby and JavaScript (both in a web development context) best so that would be good starting point for me.

As I live in Grenoble, France we’re probably going to pair program remotely. I don’t have much experience in doing that so please bear with me being a bit slow and having technical difficulties :)

I always found it interesting to see what other people in our field are reading. In that vain I thought I’d share my reading list, too.

At this point it’s very much a work in progress and I’ll fill in more details as time goes on. Feel free to suggest new titles in the comments of this blog post or on the reading list page itself.

Land of Lisp by Conrad Barski is the second book in the Ruby Rogues book club. As I enjoyed Eloquent Ruby (which was the first book we read) very much I thought I’d give that one a try, too. And of course I hadn’t used Lisp for a long time so I thought it would be a good refresher.

The first thing you see when you pick up the book is the awesome cover. The somewhat poorly drawn Lisp Alien that Conrad Barski created some years ago as the mascot of Lisp sets the tone for the book: This isn’t just another dry textbook that explains everything that Lisp (Common Lisp in this case) does. It contains drawings and you learn not by writing yet another calculator but by writing games.

Of course he’s starting with the basic elements of Lisp so the first games are quite simple, but as the book progresses (he’s even covering macros and lazy programming) they get more complex and in the end we’re even presented with a board game with a GUI that you play in a browser against three computer players!

Ideally you should follow along by typing in the code and experimenting a bit to really understand all the concepts. But up to a certain point in the book it’s also OK to just read along. That’s what I did because I read the book in the evening on the couch or in the bed. Of course I didn’t understand everything with this approach, but it worked well enough for me as most code examples are explained in detail.

All in all it was a fun read and it was great so see how you program in a language where code and data are more or less equal. I’m not sure how much of that will translate into my Ruby or JavaScript programming but what the heck it was a fun read!

I’m currently upgrading one of the Ruby on Rails apps from Rails 3.0 to Rails 3.1. As it so happens we’re using ActiveAdmin with it which requires sass-rails on Rails 3.1. At the time of writing the latest version of sass-rails is 3.1.5 and it requires the asset pipeline to be enabled. But I don’t want to upgrade from jammit at this time so I have to disable the asset pipeline. But with the asset pipeline disabled the app can’t start due to sass-rails. So here’s what I needed to do to make it work.

config/environment.rb

I had to change it so that it looks like the code snippet below. Basically this fakes the asset pipeline for the benefit of sass-rails.

1
2
3
4
5
6
7
8
9

# Load the rails application
require File.expand_path('../application', __FILE__)

Webanalyzer::Application.assets = Struct.new(:context_class) do
  def append_path(*args); end
end.new(Class.new)

# Initialize the rails application
Webanalyzer::Application.initialize!

config/application.rb

Disable compilation of the assets alongside disabling the asset pipeline as a whole.

1
2

config.assets.enabled = false
config.assets.compile = false

Done!

The two small changes fixed sass-rails without the asset pipeline for now. Hopefully pull request #84 will be merged into sass-rails soon and a new version will be released so that this hack won’t be necessary. Until then this is the most basic fix I could come up with.

This will be my final post on Eloquent Ruby by Russ Olsen. All in all I really liked the book and I think that if you’re serious about being a Ruby developer this book should be in your library.

It is a valuable book for several reasons. First of all it is as close as humanly possible to a definite style guide for programming in Ruby. This doesn’t just cover formatting your code and if or when to use camel case but more importantly when and how to use certain parts of the language. Secondly, it contains a lot of best practices, especially on the use of modules, classes and meta-programming. And thirdly it explains some of the more advances parts of Ruby extremely well. For example I never knew the difference between lambda and Proc.new and what hooks Ruby provides to help you with meta-programming.

So please do yourself a favor and read the book. More than once!

In this post I’m focusing on chapter 13: Get the Behavior You Need with Singleton and Class Methods. This chapter was a nice wow moment for me, but also a bit embarrassing as this isn’t really advanced Ruby knowledge but I’ve managed to never really learn it. So what does the chapter talk about? It talks about Ruby singleton and class methods and that they’re basically the same thing under the hood!

What?

So we all know that we can define class methods like this:

1
2
3
4
5

class DennisMoore
  def self.riding_through_the_night
    # ...
  end
end

And we also know that this is equivalent to the following:

1
2
3
4
5
6

class DennisMoore
end

def DennisMoore.riding_through_the_night
  # ...
end

Now let’s compare this to defining a method on an object instead of a class (aka defining a singleton method):

1
2
3
4

obj = Object.new
def obj.bla
  # ...
end

Quite similar that code, isn’t it? This could just be a coincidence, but of course being a nicely designed language it isn’t.

So how does it work?

Quite easily actually. As you know Ruby is an object oriented language down to it’s core. So it comes naturally that classes are just objects, too. So when you are defining class methods you are actually defining singleton methods on the instance of Class that defines your class (DennisMoore in this case) which is no different from defining singleton methods on “normal” objects!

And where are those methods stored?

Now that we know that we are just defining singleton methods the only question remaining is where these methods are stored? Remember, when we are calling a method on an object, Ruby searches for the method in the class of the object, then the super class and so on until it finds it. But of course we can’t put our singleton methods into the class as we only want these methods to be defined for that single object. So we could come up with some hack that stores the methods somehow in the instance. Or, we could do the elegant thing and add a special class to each object that sits between it and the “real” class of that object. This way we can use the normal rules of inheritance for singleton methods. This is of course what Ruby does. It calls it the singleton class even.

Wrapping up

So to summarize: Each Ruby object has a singleton class in the method lookup path between itself and its class. That’s where singleton methods are defined. And class methods are just a special case of this as classes themselves are just objects (and instances of class Class).

In this second post we look at chapter 10: Construct Your Classes from Short, Focused Methods. The first thing that comes to mind is of course that methods should be short. Some years ago my rule of thumb was that a method should fit on the screen. But now that I’m using a 27’‘ screen that doesn’t hold true anymore, of course. Also this misses the important point of the chapter and that is: use the composed method technique for your methods. Paraphrasing the book the method written using the composed method technique should have three characteristics:

1. They should do a single thing only
2. They should operate on a single conceptual level, i.e. they shouldn’t mix high-level and low-level things
3. They need to have a descriptive names, i.e. names that describe the purpose of the method

Adhering to these rules gives you nicely structured methods that should be easily understandable and as a side benefit they are also easily testable as each method only does one small thing and therefore there’s no need for extensive mocking and setting up context.