I have been working as a Ruby Programmer for over a year. Now I am thinking about how much I have learnt and how happy it has made me.
In this post I will briefly go over the history and community of Ruby, then give a small example that I think demonstrates why Ruby is made for developer happiness. This is not a tutorial, more like an introduction to Ruby.
History
Yukihiro Matsumoto, known as Matz, in 1993 conceived of the a programming language that is made for developer happiness and productivity. This makes Ruby older than Java, Javascript, and PHP; all created in 1995.
Matz took inspiration from the languages Perl and Smalltalk. From Perl he took things like the optional parentheses and the close shell integration; from SmallTalk he took object orientation and its emphasis on message passing.
The first Ruby implementation, known as the “Matz Ruby Implementation” (MRI), was initially seen as the reference implementation of Ruby. From MRI many other implementations were created:
- JRuby: Java Virtual Machine implementation
- Rubinius: Mostly pure Ruby to LLVM machine code
- IronRuby: .NET implementation
- MagLev: SmallTalk implementation
Note: recently MRI has been replaced as the Ruby standard by RubySpec. This is a suite of tests of Ruby semantics to better enable the standardisation of semantics between implementations.
Community
Matz is nice, so we are nice.
The community of Ruby I have found to be very open and inviting, as well as self moderating in those ‘get the pitch-fork out’ type of controversies. A lot of this is because the philosophy of Ruby is geared towards your happiness as a developer.
The community has many interesting resources to learn Ruby and general software development. Including books like Confident Ruby by Avdi Grimm, interactive tutorials like exercisim.io, and screencasts like RailsCasts. However, I really like the many ‘soft’ discussions that the Ruby community has about how to be a developer, with talks like:
- Disabilities by James Edward Grey II
- Developers and Depression by Greg Baugues
- Loyalty and Layoffs by the Ruby Rogues
This is summed up by James Edwards Grey’s statement at GoGaRuCo:
Learning how to program, thats the easy part. Learning how to be a programmer, thats the advanced stuff. Thats what gets you to the next level, I think we should work on that.
On a personal note, interacting with a community cane be difficult for many programmers as we are often introverted or isolated. One way which I am trying to interact is by writing this blog, and giving talks about the topics. So please comment and join the conversation :)
Productivity
When cycling, either there is a headwind or you are having a good day. I am always ready to take a wind assisted ride as my accomplishment, as if I really am that strong. But I can’t forget that if my doppelgänger was out riding the same road in the same conditions but in the opposite direction, that she would work just as hard but accomplish far less
— Sandi Metz Tells your Future
This is Sandi Metz talking about the feeling of productivity that you get when you write Ruby, and how it is like cycling without a headwind. However, she talks about the fact her productivity is not her own doing, but she is a benefactor of others work to make her life easier.
The productivity that you feel when writing Ruby is down to two things:
- Ruby being very malleable to a particular problem and developer
- The ability to quickly re-use Ruby components, called Gems
A Ruby Gem is a Ruby library/component unit for distribution. It describes the environment that is required for its use, including its dependencies on other Ruby Gems.
There are two separate topics to discuss here, writing gems and using gems.
Writing a Gem
To describe the environment and distribution of a gem a gemspec file is used, which looks like:
Gem::Specification.new do |s| s.name = 'spellchecker' s.version = '0.1.0' s.summary = "This is a spell checker" ... s.files = ["lib/spellchecker.rb"] s.add_development_dependency 'testinggem', '~> 2.1' s.add_runtime_dependency 'wordsgem', '~> 1.1' s.homepage = 'https://rubygems.org/gems/example' end
An interesting thing to note is that this file is actually Ruby code.
Note: the full specification for a gemspec file is here
Using a Gem
To effectively use RubyGems, the standard tool to use is bundler. bundler calculates the gems to install and encapsulates them into sets so that each project you create can use different versions of any Gem.
To describe the Gems you want to use, you use a Gemfile:
source 'https://rubygems.org' gem 'nokogiri' gem 'rack', '~>1.1' gem 'rspec', :require => 'spec'
Then you can bundle install, this will install all the selected Gems and their dependencies. It will also create a file called Gemfile.lock this file includes the exact versions that are installed, so others can use your exact environment.
You can explore the available Gems on sites like RubyGems and Ruby Toolbox.
Performance
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. — Matz
People sometimes dismiss Ruby because Ruby is slow. Well it is, and I don’t care. The biggest performance bottlenecks that I have day to day is the database, the file system, the internet and bugs. These are not problems with Ruby, so speeding it up will have a negligible effect.
If I was writing a matrix transformation application, I would write it in C because it will be very performance intensive. However, if I was writing a web app that needed a matrix transformer I will write it in Ruby and call the C library, because I would find the Ruby code much more fun and productive.
Additionally, hardware is cheap and developers are not. If you can use a programming language like Ruby to make your programers more productive, then you can increase the performance of your code with better hardware. You can buy the better hardware with the money you saved by making your developers more productive.
Killer App: Rails
You call a libraries code, a framework calls your code
Ruby on Rails (or just Rails) is a web application framework that provides lots of useful tools to use. Rails implements many helpful patterns like Active Record (from Martin Fowler’s Patterns of Enterprise Application Architecture) and Model View Controller (MVC) patterns. It also includes many helpers like routers and useful methods, and provides a standard way in which to use them.
The core philosophy of Rails is:
Convention over Configuration
That is, instead of spending a large amounts of time configuring a project, do it in a standard way and only specify the unconventional. This Rails philosophy is aligned to the core Ruby philosophy, to make developers happier. I think this is a significant reason why Rails has seen so much success.
The reason why I use Rails is because I can create a complex web application in hours rather than days. It also helps with getting to the core problem of the application, not some sideline problem like setting up a servers configuration correctly.
I will not go into an example of how to use Rails in this post. I will try an fill this gap later with the typical ‘Blogging Site in 10 Minutes’, for now I will just mention two of my favourite features:
- The Asset Pipeline: The asset pipeline takes a list of assets that need to be pre-compiled like coffeesciprt and sass assets, and then manages their lifecycle in development and deployment lifecycles.
- Engines: A Rails Engine is a RubyGem that includes parts of the MVC pattern. It enables a Rails application to be separated into components.
I fully intend on writing three blog posts with an intro to Rails, the Asset Pipeline, and Rails Engines, but this post is about Ruby.
Fun With Ruby Dates
To quickly demonstrate the power of Ruby I have decided to implement two of the best helper methods that Rails provides, day and ago. These methods sit on a Numeric class, and lets the developer say 1.day.ago and have it return yesterdays date.
Compare this to code for Java to get yesterdays date:
Calendar cal = Calendar.getInstance(); cal.add(Calendar.DATE, -1); System.out.println(cal.getTime() + "");
What part of this code makes you happy? Where is the bit thats says what it is doing?
After seeing that horrible Java code, lets make ourselves happy by implementing day and ago in Ruby.
The first thing to know about Ruby, you can open any class or module, anywhere, and add anything! The way you do this is just define the class again, it does not override the class but add to it. So lets open up Numeric (the top level number class) and add day
class Numeric def day self * 60 * 60 * 24 end end
day returns the Numeric multiplied by the number of seconds in a day. This is because we use seconds as the atomic unit in dates. Lets now add the ago function to Numeric:
class Numeric def ago Time.now - self end end
ago returns the Numeric subtracted from the current Time. Now 1.day.ago returns yesterdays date. Due to us defining it this way addition and subtraction work with these numbers, e.g. (1.day + 1.day).ago will return 2 days ago.
There is one more thing I want to do, saying 2.day.ago looks silly, and does not read very well so..
class Numeric alias :days :day end
This final addition means when the days function is called it is passed to day so that 2.days.ago will work.
How easy was that? Now in you have made your Ruby code more readable and saved yourself heaps of time. This is why Ruby will make you happy. Now you could go and implement methods like week, hour, second and from_now to fill out the rest of these helpers.
Note: There are many problems with this implementation, but as an example of power in Ruby I think it serves its purpose. Still, please comment with the problems!
Conclusion
Ruby makes me happy, just about everyday I am finding a new better way to do something I thought would be tedious. I think this is because Ruby does nothing unexpected, yet constantly makes me surprised at its ability.
Learn More
The Ruby Rogues podcast is one of the best software engineering podcasts out there. This podcast uses Ruby more as a backdrop to talk about how to write code, and be a developer.
Programming exercises at exercisim.io, where you can feedback for your code.
Sandi Metz: Practical Object-Oriented Design in Ruby
Martin Fowler: Patterns of Enterprise Application Architecture