Si Wilkins

Escaping the Bubble

| Comments

At SxSW interactive this year, the big hype was about location-based social software, with a number of apps (examples here and here) focused on exposing your location, or finding people nearby who shared similar interests to you.

All this provoked a variety of reactions in me. The first question I found myself asking was why would I want to use this. I couldn’t really find an answer. There are plenty of existing methods of notifying people of my whereabouts which offer the flexibility of a) not telling people who I don’t want to know, and b) not kidding me into believing that anyone outside my immediate circle of acquaintance would be that bothered anyway.

Secondly, this “social” technology didn’t actually seem very social. Why would I want to focus my social interactions around just my interests, political leanings, biases and prejudices? To do this is to remove a lot of what’s fun in life - interacting with people who disagree with you, who find the flaws in each others thinking. This is how ideas get tested and refined and people grow through positive interaction.

And yet the tech crowd were seemingly all-a-flutter with this upcoming, supposedly life-changing new paradigm. This was all about making individuals’ lives easier, more fun and more productive.

I think the hype and then lack of traction with these apps in the months since is testimony to the inherent flaw here. You see, SxSWi is itself a gathering of a fairly specific segment of society. This isn’t a problem in itself, but when the sub-culture doesn’t recognise itself as a subculture then things get a little bit weird.

Firstly, and most obviously, virtually everyone there was of a techie/futurist bent. This can warp the underlying collective subconscious. A response might be, “but by being futurists we are just the kind of people that everyone will be in the future”. To an extent this is true - the technologies that us techies are now adopting may be the technologies that in a few years will be used by everyone (take Twitter in 2007 for perhaps the closest this comes to truth). But what will not be shared by those who didn’t bother to make the trip to Austin is the futurist psyche - otherwise in five years time they won’t be using the technologies we are using today, they’ll be using the technologies we’ll be using in five years time.

More significantly in this case is that there seemed to be a failure to recognise the shared purposes of those experiencing the excitement. Yes, those at SxSW were there to have fun, learn things, be inspired and the like but many also had something else in common: they were there to sell something. And that is the real use case for these apps - they are great for someone attending a tech conference for a few days along with 20,000 or so other enthusiasts and trying to find those people most likely to want to buy their product or service.

Despite society as a whole becoming more technologically proficient, I can’t help but feel that the technological community continues to fall into the trap of finding ideas which seem useful or fun to them and then trying to sell them to the rest of the world as if they are all on the same page. This seems particularly to be the case post-Facebook and post-Twitter - apps whose success is thanks to their ability to encompass so much of our lives. There seems to be a clutching-at-straws to fool ourselves into believing that a tool we’ve created which may be useful for one or two use cases will revolutionise our whole existence.

Anyway, this was supposed to be a post about app.net - that will have to wait till later.

Ruby for Java Programmers - Inheritance and Modules

| Comments

Inheritance in Ruby is provided by the < symbol. For instance. Here’s a common use case:

1
2
3
class User < ActiveRecord::Base

end

This creates a new User class which inherits from Rails’ ActiveRecord::Base class. User has all the methods and attributes provided by Rails. Additionally it “knows” about it’s place in the class hierarchy:

1
2
3
4
5
6
7
8
User.class
=> User
User.superclass
=> ActiveRecord::Base
User.is_a?(User)  # This goes without saying
=> true
User.is_a?(ActiveRecord)
=> true

But hang on a second. What’s this :: all about? Well, Ruby has another feature which provides functionality similar to inheritance: modules.

Modules provide two features…

Firstly, modules provide namespaces. So, the ActiveRecord::Base class above will have been declared along the following lines:

1
2
3
4
5
6
7
module ActiveRecord

  class Base

  end

end

So this ”Base” class will not conflict with a class just class Base, or a Base class which belongs to another module. It will need to be referred to as ActiveRecord::Base unless the reference itself is within the ActiveRecord module. This enables code to be easily divided into neat discrete sections (along the lines of Java packages).

But that is not all that modules do. They also provide the ability to group methods for reuse.

For example,

1
2
3
4
5
6
7
8
9
10
11
module MyModule

  def do_something
    puts "I am doing something"
  end

  def do_something_else(arg)
    puts "I am doing something else, and I have an argument: #{arg}"
  end

end

As they stand, these methods cannot be called. However, this module can now be included in a class, eg.

1
2
3
4
5
6
7
8
9
10
11
12
13
class MyClass

  include MyModule

end

my_object = MyClass.new

my_object.do_something
=> "I am doing something"

my_object.do_something_else(123)
=> "I am doing something else, and I have an argument: 123"

The methods in MyClass weren’t written directly in that class, but they exist due to MyModule being included. So modules obviously provide a useful mechanism for code re-use. In fact they effectively provide something like multiple inheritance. It is only like multiple inheritance since MyClass is is not a subclass of MyModule:

1
2
3
4
MyClass.superclass
=> Object
MyClass.included_modules
=> [MyModule, Kernel]

Modules therefore provide a powerful way of mixing-in functionality to a class or object.

Ruby also provides some callbacks which are helpful. One of these is the Module.included method. This gets called when a module gets included in a class, and takes the class which includes the module as a parameter.

Here’s a common pattern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
module MyMixin

  def self.included(base)
    base.extend ClassMethods
  end

  def i_am_an_instance_method
    # Do something instance-methody
  end

  module ClassMethods

    def i_am_a_class_method
      # Do something class-methody
    end
  
  end

end

class MyClass

  include MyMixin

end

The extend method does a bit of magic here. In simple terms, the extend call is equivalent to self.class.send(:include, ClassMethods). This means that in addition to instances of MyClass having the methods defined in MyMixin, MyClass itself will have the methods defined in MyMixin::ClassMethods.

In less simple terms, what actually happens is a little more subtle. include adds a module’s methods into the specified class’s instances. extend adds a module’s methods into the object which it is called on. So in the case above, that object is the MyClass class. Similarly in this case:

1
2
3
4
5
6
7
8
9
10
11
12
13
module SaysHello

  def say_hello
    puts "Hello"
  end

end

class AnotherClass

  extend SaysHello

end

We can now call AnotherClass.say_hello (but not AnotherClass.new.say_hello since the methods are added to the class rather than the classes instances).

But now we can do something rather magical:

1
2
3
4
my_string = "I am a string"
my_string.extend SaysHello
my_string.say_hello
=> "Hello"

In this case, the object which extend has been called on is an instance, and so that string - and that string only - will have the new functionality. So we can dynamically add new functionality to existing objects.

The abilities described in this and the previous one become amazingly useful when they are put together, as will be shown in the next post.

Ruby for Java Programmers - Open Classes

| Comments

There are two Ruby features which users of Java tend to baulk at most, and they are both animal-related.

The first is “duck-typing”. It will no doubt have been noticed from previous code examples that there is no type-checking of ruby objects except for whether an object has a given method when it is called.

The merits of duck-typing have been much argued over, and no doubt will continue to do so. Personally, I subscribe to the view that every execution path (and this includes variations in objects which will receive a method) should be well tested, and in this sense duck-typing does no harm - in fact it avoids the false sense of security of “Well the code compiles”.

The other controversial feature is what is often referred to as “monkey patching” or open classes.

Ruby classes are never set in stone. Neither for that matter are Ruby methods. At any time a class can be “re-opened” and new methods added, or existing methods overridden. For instance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class MyClass

  def a
    "a"
  end

end

class MyClass

  def b
    "b"
  end

end

my_class = MyClass.new
my_class.a
=> "a"
my_class.b
=> "b"

class MyClass

  def a
    "I am the new a"
  end

end

my_class = MyClass.new
my_class.a
=> "I am the new a"
my_class.b
=> "b"

So firstly, a new method b has been added to the class. Then the existing method a has been overridden. Ruby doesn’t mind this and doesn’t throw any warnings or errors. In fact, it’s the kind of behaviour Ruby expects from a programmer.

Lets take an example. The apache commons StringUtils class provides a number of useful methods for handling strings. An example is the isBlank method. This checks for values which are null, empty or all-whitespace. But why is a separate class needed for this method? Really it belongs with String. But String is already defined and cannot be modified. What happens when I need to define a new method for processing strings which is not provided by StringUtils? Then I need to create a new class, say MyStringUtils. The result is a proliferation of classes containing static methods which all really should be instance methods of the relevant class. Java (and the vast majority of other languages) don’t allow this. Rails actually provides a number of additional “core extensions”, including this isBlank functionality. The result is that despite Ruby not having the functionality itself, when using Rails you can do the following:

1
2
3
4
5
6
7
8
nil.blank?
=> true
"".blank?
=> true
" ".blank?
=> true
"abc".blank?
=> false

To take another example, Ruby provides a method Array#include?, which tests whether an array contains an object, eg.

1
2
3
4
[1, 4, 2, 8, 3].include? 8
=> true
[1, 4, 2, 8, 3].include? 5
=> false

In practice, however this method is not intuitive. I often want to check whether an object belongs to an array - checking whether the array contains the object seems rather backward.

So I simply re-open the Object class and add a method:

1
2
3
4
5
6
7
class Object

  def in?(array)
    array.include?(self)
  end

end

Voila, my code is now much more intuitive, as I can write code in this form:

1
2
3
4
5
if answer.in? correct_answers
  puts "Well done!"
else
  puts "Hard luck"
end

Ruby for Java Programmers - Syntax: Methods

| Comments

As discussed before, this isn’t intended to be a tutorial for the Ruby language. Instead it’s more of an overview of what makes it fairly unique, and the advantages which some of these features bring.

Python famously rejects Perl’s approach of ”There’s more than one way to do it”, and instead takes the view that ”There should be one - and preferably only one - obvious way to do it”.

Java generally fits with the Python philosophy. Ruby on the other hand, takes the Perl approach, and this is most obvious when it comes to methods.

Ruby makes some very simple assumptions when it comes to methods. In particularly, it treats method calls and local variables uniformly. So when you reference a “name”, it could be a local variable or a method call.

1
2
3
4
5
6
7
8
9
10
11
    a = 23

    def b
      24
    end

    a
    => 23

    b
    => 24

(def is the keyword used by Ruby to define a method - although in this case it could be viewed as a “mere function”, it is in fact a method of the main object)

Ruby (like Java) makes method referencing a fairly “power-user” feature (Javascript is probably the most obvious language which exposes method references). For this reason, the brackets which could be used for method calls are rather redundant. Ruby takes this to its logical conclusion and makes them optional (as shown above). So the following two calls are (in most cases) identical:

1
2
    my_method()
    my_method

But what about method arguments? Well, for one thing, as it happens, the brackets are still optional:

1
2
   my_method(1, 2, 3)
   my_method 1, 2, 3

There is one more nifty bit of syntactic sugar which Ruby allows: when the last argument to a method is a hash, then it does not need to be wrapped in curly brackets.

On first hearing this may seem like a really arbitrary, and awkward rule. Let’s take a look at some examples:

1
2
3
4
my_method(a, b, {:c => 1, :d => 2})
my_method a, b, {:c => 1, :d => 2}
my_method(a, b, :c => 1, :d => 2)
my_method a, b, :c => 1, :d => 2

There is a very sensible reason for this however. Actually, Ruby’s design is intended to encourage developers to write readable code. You see, there are few worse code smells than a method call with a list of parameters whose purpose is only defined by their ordering (especially if some of the arguments are optional)

1
doSomething("some text", true, true, false, 34)

Ruby makes the use of option-hashes natural and readable. A common example is Rails validation macros:

1
2
3
  validates :forename, :surname, :presence => true
  validates :email, :format => EMAIL_FORMAT, :allow_blank => false

As it happens, there are some loose conventions for how these syntactic sugars get used, for the sake of readability. More often than not, method calls will be written with brackets. Curly braces are however rarely used when not necessary. One place where method calls will often not use enclosing brackets is in declarative method calls (like those shown in the above example). There will be more on this in future posts.

Ruby for Java Programmers - Objects

| Comments

Ruby, unlike Java, is a pure object-oriented language. This means that everything is an object, including what in Java would be primitive types - so primitive types are effectively syntactic rather than semantic constructs.

These “syntactic data types” are:

  • strings, eg "i am a string", 'so am i'
  • symbols (similar to strings, but immutable and global singletons), eg. :i_am_a_symbol
  • numbers, eg. 1234, 1.234
  • arrays, eg. ['a', 1, "b"]
  • hashes (a key-value data structure), eg. {:forename => 'Simon', :surname => 'Wilkins'}
  • boolean, ie. true, false
  • nil

(note: Ruby 1.9 introduces an alternative syntax for hashes: {forename: 'Simon', surname: 'Wilkins'}. Using this syntax the hash keys will be symbols. The “old” syntax allows keys of any type).

As said above, everything in Ruby is a class. This can be seen in an irb (the Ruby REPL) session:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
> "i am a string".class
=> String

> :i_am_a_symbol.class
=> Symbol

> 1234.class
=> Fixnum

> 1.234.class
=> Float

> ['a', 'b'].class
=> Array

> {:a => 1, :b => 2}.class
=> Hash

> true.class
=> TrueClass

> false.class
=> FalseClass

> nil.class
=> NilClass

`

What is less obvious is that classes are also objects. For example:

1
2
> "i am a string".class.class
=> Class

So String is an object of the class Class (as it happens String.class.class.class will also return Class as Class is itself an instance of the class Class, ie. itself)

At first this may seem on the one hand very odd, but also not very useful. When thought about further this is not really the case however. In terms of oddness, it is more just that Ruby is consistent: ultimately there is really only one kind of “thing” in Ruby, and that thing is the Object. Using the superclass method (which returns what a class inherits from), this can be seen clearly:

1
2
3
4
> "i am a string".class
=> Class
> "i am a string".class.superclass
=> Object

(Object actually does itself inherit from further classes, although this is a fairly philosophical point).

As for usefulness, this will be seen in later posts, however as a teaser, perhaps it’s most useful implication is the way a Ruby class’s class methods are themselves methods on an object (ie. the class). This allows for the extremely declarative nature of some Ruby code.

Out of interest, can you think of any profound statement which could be made about Ruby methods. If you haven’t guessed, here’s a big clue:

1
2
> "i am a string".method(:length)
=> #<Method: String#length>

Yep, that’s right - Ruby methods are objects. Just to explain the syntax, the code above is calling the method method (!) on the string, passing in the argument length. And the output is an object of type Method, ie. the String#length method.

Rich Hickey - Simple Made Easy

| Comments

Despite its content being far from simple, this talk from Rich Hickey is spot on in highlighting the perils of prioritising ease in software whilst ignoring complexity.

I recognise the full talk might be a bit much in one go, but minutes 14-18, along with their accompanying slides provide a good abstract.

A choice quote:

Apparently, I heard in a talk this morning, that agile and extreme programming have shown that refactoring and tests allow us to make change with zero impact. I never knew that. I still do not know that. That’s not actually a knowable thing. That’s fooey.

Hickey goes on to show how every bug in the field shares two characteristics. Firstly, that it passed the type checker, and secondly, that it passed all the tests.

Therefore…

Your ability to reason about your program is critical to debugging

ie. programs really need to be simple enough that the detail of any faulty components pertaining to a bug - and any dependent components - can be held in the programmer’s consciousness and logically reasoned with.

What kind of runner can run as fast as they possibly can from the very start of a race? Only somebody who runs really short races. But of course we are programmers, and we are smarter than runners, apparently because we know how to fix that problems We just fire the starter pistol again every 100 yards and call it a new sprint. I don’t know why runners haven’t figured that out.

It is my contention, based on experience that if you ignore complexity you will invariably slow down over the long haul.

Announcing Redis-central

| Comments

So, you’ve built yourself a nice little Ruby app which interfaces with Redis. Perhaps it’s doing something like storing user data using a key format along these lines:

users:<id> = {<data>}

All well and good, but what if you need to deploy another instance of the application on the same server? Or re-use your user model in another app (perhaps you’ve built an authentication engine)? Or perhaps you rightly just want to ensure that your app is future-proof and not going to cause problems with any other redis clients already using the server?

Step forward, redis-central. The simple purpose of this gem is to provide an easily-accessible, namespaceable redis client instance. Simply include it in your model, thus:

1
2
3
4
5
6
7
require 'redis/central'

class User

  include Redis::Central

end

The User class, and User instances now both have a redis instance. This will by default return a Redis instance. To make the most of it, however, it’s worth setting a namespace. So, in a Rails initializer you can put:

1
2
3
require 'redis/central'

Redis::Central.namespace = "my_app"

Now calls to redis in your objects will return a Redis::Namespace instance (see here). So the user key format above will now be:

my_app:users:<id>

The suggested implementation is actually to go one step further and use a format for the namespace like <app name>:<app id>. An obvious implementation of this for a Rails app could be achieved using RAILS_ROOT, eg.

1
2
3
require 'redis/central'

Redis::Central.namespace = "my_app:#{RAILS_ROOT.split(File::SEPARATOR).last}"

(HOWEVER, it should be noted that this implementation will not be suitable where a Capistrano-style deployment mechanism which makes use of symlinks is being used. In this scenario, the namespace will change on each deployment, and the data will therefore not persist between deploys).

Ruby for Java Programmers - the Runtime Environment

| Comments

Ok, so the first obvious difference between these two languages is that Ruby is interpreted directly whilst Java is compiled to bytecode. At first this might seem to count heavily against Ruby, but it’s important to get a bit of background on the language’s history, and the motivations of its creator.

Yukihiro Matsumoto, commonly known as Matz, first released Ruby in 1995. It takes inspiration from a number of other languages, particularly Smalltalk, Perl and Python (although it’s ethos differs substantially from that of Python).

A good sense of Matz’s motivations comes through in this interview from 2003. One of the statements quoted there is this:

For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy.

It goes about this in a number of ways, but one of Matz’s answers later in the interview has particular relevance here:

We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

Many languages (C being the most extreme example) have a strong focus on the machine. And in these cases, pre-compiling to bytecode is an obvious approach. However, Matz decided to have the machine as the primary focus. Instead he concentrated on designing the language around the programmer. And so, considering that compilation adds an overhead to the developer’s work and prevents them from seeing the results of their efforts immediately, it is perhaps not surprising that Ruby is interpreted.

At this point a Java programmer might lose interest - however, I would then point them in the direction of this quote from Donald Knuth:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

The fact is that poor application performance can be down to a number of factors, including:

  • resource limitations (memory, CPU etc.)
  • infrastructure issues (eg. network latency)
  • poor design
  • poor implementation

Of these, design and implementation will be the chief concern of the developer. And the other factors will be easier to mitigate against if the code-base is well-designed and well-implemented.

So Ruby’s philosophy of focusing on the programmer rather than the machine has a lot in its favour. Typically, software projects will change direction during development - requirements will change and new requirements will be added. I would argue that requirements should change: as the once hypothetical product becomes actualised, its role in achieving its goals can be refined and focused.

In such situations a codebase which is designed around the machine can be a nightmare to maintain; one which is designed around the programmer can be modified easily and can adapt to the changes. When the requirements have stabilised or performance becomes problematic then optimisation can be applied to the hardware, platform, and yes, the software.

The fact is those who have bad-mouthed Ruby on the basis of performance concerns have always had to contend with the successful high-traffic applications which run on Ruby. Almost without exception, where failures can perhaps justifiably be pointed at Ruby, the fact is that the application would likely never have become so huge without the flexibility which Ruby provides.

As it happens there has been a great deal of competition both in terms of ruby interpreters and application servers, the result of which is that Ruby is performing better and better. And… as it turns out, the currently best performing Ruby implementation runs on the JVM and integrates with Java libraries.

Ruby for Java Programmers - Introduction

| Comments

As of four weeks ago, I now work in an environment where the programming lingua-franca is Java. This is quite a change for me, since for the past seven years my work has almost exclusively been with scripting languages, particularly Ruby. Traditionally, there’s been quite a lot of antagonism between the Java and Ruby/Rails communities, especially due to Ruby’s chipper new-kid-on-the-block status and Java’s enterprise hegemony (with both communities counting this in their own favour).

Well, nowadays Ruby isn’t the new-kid-on-the-block and some have made comparisons between where the Rails community is now and where Java web development was a few years ago. Nevertheless, Ruby is a great tool (as is Rails), and so I’d like to give a bit of a whirlwind tool of why that is.

I don’t intend this to be a tutorial, or a language reference, but more of a historical, theoretical and philosophical reflection, with some code samples thrown in for illustration.