Archive for category ruby
Lots of rubies, now what?
Posted by Matt Aimonetti in ruby on November 30th, 2009
If you were at RubyConf 2009 or looked at the schedule, you saw that the big thing happening in the Ruby scene is the maturation of a many of the Ruby implementations:
BlueRuby, HotRuby, IronRuby, JRuby, MacRuby, Maglev, MRI, REE, Rubinius, SmallRuby…
Ruby developers really have plenty of choice when it comes to choosing an alternative Ruby implementation.
Is that a bad thing?
Turns out, Matz , Ruby author mentioned one ore time during RubyConf that it was actually a good thing for the Ruby ecosystem.
But maybe we should take a step back and look at the big picture. So here are some of my thoughts on the topic. (disclaimer: being part of the MacRuby team, I’m certainly biased)
Stop comparing alternative Ruby implementations against Ruby 1.8.x.
Even though a lot of people are still using Ruby 1.8.x, it’s totally unfair to compare against such an old version of Matz’s Ruby.
Ruby 1.9 is what people should compare against and believe me, Ruby 1.9.2 is going to change the game (much faster, cleaned up version).
Hopefully, all the Ruby alternative implementations will quickly become 1.9 compatible.
(On a site note, Rails 2.3.5 was released a few days ago which fixes some of the last few remaining Ruby 1.9 bugs)
Don’t trust the benchmarks
As we all know, there are lies, damn lies and statistics. Evan Phoenix explained that very clearly with lots of examples during his RubyConf talk and I totally agree with him.
Micro benchmarks only help implementers know where they are standing and find performance issue.
Let’s take a very simple example: JRuby.
What you might not know is that most JRuby benchmarks are usually ‘warmed up’. Basically, to get the results you see in most reported benchmarks, you need to run the benchmark in a loop X amount of times and then run the benchmark. The reason for that is that JRuby uses HotSpot which needs to process the code to optimize the JITting and finally get your code to run faster.
The problem is that it is not a fair comparison. I was benchmarking Rails3 for instance and JRuby starts way slower than Ruby 1.8.6 and takes a little while to get as fast/faster than 1.9.1.
This is something you need to take in consideration since each deployment will slow down your app and you probably shouldn’t use JRuby if you are not using long running processes.
Another example would be MacRuby, even though the MacRuby project never released any benchmarks, it’s known to be a fast implementation.
Currently, the allocation of objects in MacRuby is actually still a bit costly and if you benchmark that, you can show that MacRuby is slow. Other operations are super optimized and both Rubinius and MacRuby will be way faster than anyone else. (check Phoenix’s talk at Ruby conf for more examples)
So, before choosing an implementation for performance reasons, benchmark against the code you are going to use.
There is only one real original Ruby
I think nobody will disagree with the fact that there is only one Ruby reference and that’s Matz.
Therefore is only one “real” Ruby and that is Matz’s. (Matz actually disagreed with me when I said that, since all the other implementations are also “real” but you get the point)
There is nothing wrong with Ruby’s alternatives but they stay alternatives to the original
MRI might not be the best option for every single case out there but it is and will stay the reference.
During RubyConf, I was joking with Matz and Koichi that maybe they should claim a Ruby tax to the Ruby implementations.
The reality is that Ruby is maintained by 5 to 10 contributors, most of them doing that on the side of their full time job.
Most of the other implementations have full time staff working hard on their implementations. That’s exciting but sad at the same time.
During the different talks given by the Ruby core team, it was clear that they really want to bridge the West/East gap and asked for help. It’s very honorable on their part and I hope we will see more contributions coming from outside Japan.
Finally, I think that even if people work hard to write the best Ruby implementation ever, let’s not forget to respect Matz’s project, team and achievements. People spent hours/weeks/months creating the Ruby language we love and even though there are some aspects that could be and are being improved, let’s not forget that when criticizing/comparing their work.
There is not only one way to do things
I don’t know where that’s coming from, but some people in our community seem to believe that there is only one way to do things and if you don’t do it their way, you do it wrong.
I personally have a hard time believing that and I even think it goes against what Ruby was designed for. (However, I must admit that sometimes I did/do think that some approaches were totally wrong :p)
It reminds me of people trying to convince you that God exists, other people trying to convince you that their religion is the only true one, or finally the other people trying to convince believers that they are wrong.
Maybe it is just that as humans we have a hard time dealing with people coming to a different conclusion than us and therefore we have to convince them that we are right and they are wrong.
The way I see it, for any new Ruby project, you should start be using with Ruby1.9. If it doesn’t fit your needs, then, consider an alternative. Here is how I look at the other alternatives (feel free to disagree):
- BlueRuby – use if you are writing a SAP app
- HotRuby – use if you want to use Ruby to write a Flash app
- IronRuby – use it if you want to integrate with .NET and/or write a silverlight app
- JRuby – use if you want to integrate with the Java world
- MacRuby – use it if you want to integrate with Cocoa/want a native OSX application
- Maglev – use if you want to use an object persistence layer and a distributed shared cache
- REE – use if you have a ruby 1.8 web app that uses too much memory
- Rubinius – use if you want to know what’s going on in your code
- SmallRuby – don’t use it yet, but keep an eye on it
This is the way I see the various existing implementations and I think this is where they shine and why they were created in the first place. They are all complimentary and help bring the Ruby language further. The goal is always the same.
The future is exciting
Ruby is getting everywhere or almost. Matz’s Ruby is going to get multiVM support, various other improvements and get even faster and faster.
Alternative implementations are getting more and more mature and they grow the community by bringing people from different communities (.NET, java, obj-c/cocoa)
At the end of the day, we are all beneficiaries of the work done by all the implementers, thank you guys and keep up the good work!
The Ruby Revolution, take II
Posted by Matt Aimonetti in Misc, ruby on November 16th, 2009
Mohandas Karamchand Gandhi
My recent ‘Ruby revolution being over‘ blog post generated quite a lot of comments.
Let’s be honest, I did not expect less from the readers.
However, I noticed three types of reactions I would like to address:
- It was not a Ruby revolution, it was a Rails revolution
- The revolution has stalled due to no major enterprise backing
- The revolution will only be over when we will reach a greater adoption
First of all, as Joe correctly mentioned, for me, the revolution is not about specifics or individuals. It’s really about the big picture.
The influence Ruby had and still has on the IT world seems to be undermined by some.
Ruby is a dynamic, truly Object Oriented programming scripting language designed for humans first.
The real paradigm shift is in the fact that Ruby was designed to make programming fast, enjoyable and easy instead of being optimized for the machines running it.
This is for me the essence of the revolution and it is meant to transcend the scope of the Ruby language.
The way I see it, Yukihiro Matsumoto (Matz) is more of an artist than a technician. He had a vision for software development. Programming languages cannot be optimized/designed for both machines and humans, the language designer has to choose which one he wants to privilege.
Most programming languages believe that it’s up to the programmer to make an extra effort since he is smarter and easier to optimize than a machine. Matz questioned this approached and decided to turn things around. The result is one of the reasons why developers seem to just fall in love with Ruby.
It was not a Ruby revolution, it was a Rails revolution.
I am not denying that there *also* was a Rails revolution.
But if you look at it, Rails and its revolution are a direct effect from Ruby’s revolution.
One might argue that it is actually an extension of Ruby’s philosophy. But what is Rails if not a web framework designed to make web development fast, easy and enjoyable?
Without Ruby there would not have been Rails and that was my point, the underlying revolution comes from the language itself.
The revolution has stalled due to no major enterprise backing.
That’s an interesting comment. It is true that .NET and Java are still dominating the enterprise world. But let’s be clear, Ruby was not designed to please “suit people”.
And to this day, there is still a strong feeling, from some individuals against the enterprise.
In the past, DHH openly said that he did not care nor wanted to hear about the enterprise, more recently, Obie Fernandez, during one of his talks said: “Fuck the enterprise” (49:39).
But the truth is that Ruby and the so called enterprise, both, are changing.
The smart people in the enterprise world saw potential in Ruby and decided to give it a chance. An easy way to include Ruby’s philosophy without breaking the fragile enterprise equilibrium was to inject Ruby in the midst of well known and respected technologies such as Java and .NET. The enterprise can now use “re-branded Ruby versions” with “new taste or ‘improved’ flavor” like JRuby, Scala, groovy, IronRuby.
I work for some enterprise clients and I can tell you that they ‘also’ use Ruby. Mainly because developers love the language.
Microsoft, Apple and SAP investing in their own implementation of the language is yet another example that the enterprise recognizes the value of Matz’s work.
Nobody can blame them to try to make Ruby fit more their requirements.
So, at the end of the day, Ruby is not the #1 enterprise language and Rails isn’t used by the large majority of enterprise web apps, but that is NOT the point. Ruby has influenced the enterprise and we will see its effects for many years.
The revolution will only be over when we will reach a greater adoption
Saying that is missing the point entirely. A revolution is a step towards a situation change. Things don’t change right away after a revolution. It takes a long time for mentalities to evolve and for people to change their habits.
The consequences of a revolution are to be studied over the decades following the event. Take smalltalk for instance. Smalltalk adoption was not that great, however it brought a paradigm shift that directly influenced languages such as Ruby, Python and Objective-C.
So, again, do not focus on the adoption but instead look at the influence of the Ruby revolution and the ripple effect around it.
The Ruby revolution is over
Posted by Matt Aimonetti in Misc, ruby on November 9th, 2009
According to wikipedia, a revolution (from the latin revolutio, “a turn around”) is a fundamental change in power or organizational structures that takes place in a relatively short period of time.
Somehow, I believe this is exactly what Ruby has done in the programming world, especially with the help of Rails. Over the last few years, Ruby lead a mini revolution in the midst of software development. Thanks to Ruby, developers now look at software development differently. One thing for sure, it pushed DHH to write Rails and then convinced thousands of people to develop Ruby based applications on a daily basis.
How did it happen?
Let’s take a look at history of revolutions. Some people get frustrated their situation, they try to find workarounds until it’s just too much and the revolution kicks in.
Ruby came up with a new holistic perspective on things. Unlike most other programming languages, one of the main key value of Ruby is that writing code should feel right for the developer. You feel good about it because the language was written for humans and not machines. Basically, the language was designed to make you productive because it’s designed to please you.
As people were discovering web 2.0, Ruby also came with an opinionated framework, pushing for productivity, testing, simplicity and elegance. People started to see a new way of doing things and it quickly became the new, cool technology. Rails became a buzz word, developers were hired to work on cool projects, and books were selling by the thousands.
What did it change?
If you ask my mom, she would probably say: nothing, except that now my son works from his home office and he seems to really enjoy what he does for living.
Relatively speaking, Ruby did not change the way we work or live. However, I believe that it has influenced many software developers around the globe. Why else do you think that companies like Microsoft, Apple or SAP are working on their own implementation of the Ruby language?
When I first discovered Ruby, I was amazed at how “right” it felt, at how much fun it was to write code using its syntax and idioms. Now, if I don’t get that feeling when testing a programming language, I think there is something wrong.
The Ruby community also revived the Agile/XP world. Testing being a strong value of the community, we spent a lot of time discussing TDD, BDD, integration test as well as other practices such as pair programming, code review, sprints etc..
A few years ago, when people were asking me what programming language I would write their app in, I would reply Ruby and had to explain what it was, why it is great and would have to answer a lot of questions from potential clients. Nowadays, people don’t even argue, sites like hulu.com, twitter.com, yellowpages.com and many others are written in Ruby and it’s just part of the tools known to work very well.
The revolution is over!
Yes, Ruby made it’s revolution and the world “has changed”. But a real movement doesn’t die after its revolution, that’s actually when it has to be strong and defend its values.
This doesn’t mean that Ruby is dead or that Rails is “passé”. To the contrary, Ruby imposed itself as a new valued and respected player, a new standard if you will.
Ruby is certainly not the “new kid in the block”anymore nor the “popular kid”, however lots of older kids seem to want to have her on their team. (.NET, Java, Objective-C can all use Ruby)
The TDD + Ruby combo doesn’t surprise anyone anymore and the Enterprise is slowly but surely adopting Ruby. Ruby is now just getting better, tools and libraries are improving and the amount of users is growing.
Certainly the Ruby community is still small compared to other software developer communities, but the fundamental change was done and we are now working on improvement and keeping things running smoothly, growing and getting new ideas inspired by our experience and other communities.
Long live Ruby!
Ruby, Rack and CouchDB = lots of awesomeness
Over the weekend, I spent some time working on a Ruby + Rack +CouchDB project. Three technologies that I know quite well but that I never put to work together at the same time, at least not directly. Let’s call this Part I.
Before we get started, let me introduce each component:
- Ruby : if you are reading this blog, you more than likely know at least a little bit about, what I consider, one of the most enjoyable programming language out there. It’s also a very flexible language that lets us do some interesting things. I could have chosen Python to do the same project but that’s a whole different topic. For this project we will do something Ruby excels at: reopening existing classes and injecting more code.
- Rack: a webserver interface written in Ruby and inspired by Python’s WSGI. Basically, it’s a defined API to interact between webservers and web frameworks. It’s used by most common Ruby web frameworks, from Sinatra to Rails (btw, Rails3 is going to be even more Rack-focused than it already is). So, very simply put, the webserver receives a request, passes it to Rack, that converts it, passes it to your web framework and the web framework sends a response in the expected format (more on Rack later).
- CouchDB: Apache’s document-oriented database. RESTful API, schema-less, written in Erlang with built-in support for map/reduce. For this project, I’m using CouchRest, a Ruby wrapper for Couch.
Goal: Log Couch requests and analyze data
Let’s say we have a Rails, Sinatra or Merb application and we are using CouchRest (maybe we are using CouchRest and ActiveRecord, but let’s ignore that for now).
Everything works fine but we would like to profile our app a little and maybe optimize the DB usage. The default framework loggers don’t support Couch. The easy way would be to tail the Couch logs or look at the logs in CouchDBX. Now, while that works, we can’t really see what DB calls are made per action, so it makes any optimization work a bit tedious. (Note that Rails3 will have some better conventions for logging, making things even easier)
So, let’s see how to fix that. Let’s start by looking at Rack.
Rack Middleware
Instead of hacking a web framework specific solution, let’s use Rack. Rack is dead simple, you just need to write a class that has a call method.
In our case, we don’t care about modifying the response, we just want to instrument our app. We just want our middleware to be transparent and let our webserver deal with it normally.
Here we go … that wasn’t hard, was it? We keep the application reference in the @app variable when a new instance of the middleware is created. Then when the middleware is called, we just call the rest of the chain and pretend nothing happened.
As you can see, we just added some logging info around the request. Let’s do one better and save the logs in CouchDB:
Again, nothing complicated. In our rackup file we defined which Couch database to use and we passed it to our middleware (we change our initialize method signature to take the DB).
Finally, instead of printing out the logs, we are saving them to the database.
W00t! At this point all our requests have been saved in the DB with all the data there, ready to be manipulated by some map/reduce views we will write. For the record, you might want to use the bulk_save approach in CouchDB which will wait for X amount of records to save them in the DB all at once. Couch also let’s you send new documents, but only save it to the DB every X documents or X seconds.
As you can see, our document contains the timestamps and the full environment as a hash.
All of that is nice, but even though we get a lot of information, we could not actually see any of the DB calls made in each request. Let’s fix that and inject our logger in CouchRest (you could apply the same approach to any adapter).
Let’s reopen the HTTP Abstraction layer class used by CouchRest and inject some instrumentation:
Again, nothing fancy, we are just opening the module, reopening the methods and wrapping our code around the super call (for those who don’t know, super calls the original method).
This is all for Part I. In Part II, we’ll see how to process the logs and make all that data useful.
By the way, if you make it to RailsSummit, I will be giving a talk on Rails3 and the new exciting stuff you will be able to do including Rack based stuff, CouchDB, MongoDB, new DataMapper etc..
MacRuby, changing the Ruby ecosystem
Posted by Matt Aimonetti in macruby, ruby on May 27th, 2009
What’s MacRuby?
MacRuby is an Apple-sponsored, open source, full Ruby implementation on top of Objective-C runtime. In other words, whatever code runs on Ruby 1.9, should/will run on MacRuby. Yes, you read correctly, MacRuby can/will be able to run all your Ruby code. That means that eventually you will even be able to run your Rails/Sinatra/new-sexy-ruby-framework app on MacRuby.
Unlike RubyCocoa, MacRuby is not a bridge, it is a full implementation of the Ruby language on top of Apple’s Objective-C runtime. Taking a huge shortcut, MacRuby implements the Ruby syntax by aliasing it to the Obj-C language counterpart. A Ruby string instance is really in fact, an instance of NSMutableString. This is obviously transparent for you as a developer since you have the same Ruby API, but it also means that MacRuby can make use of the various Objective-C’s goodies such as native threads, garbage collector in the background as well as the runtime performance.
On top of that, you have full access to the Obj-C API from your Ruby code. (tip: in macirb, try “my string”.methods(true, true).sort to see the available Ruby + Objective-C methods on your String instance) The reason why having access to Objective-C is important is because it gives you the possibility to write native Cocoaapps using Ruby. For those who don’t know Cocoa, is a set of APIs for MacOSX development.
However, note that even though, the Cocoa support is almost complete and stable, MacRuby is still in development, especially on the Ruby side of things.
What is it not?
- MacRuby is not a fork of Ruby. Full rubyspec compliance is expected! It’s true that MacRuby supports smalltalk/Obj-C method selectors so it might be considered a language superset.
- MacRuby is not limited to the OSX platform. All its dependencies are open source and could possibly be compiled for other POSIX-based systems such as Linux.. (not done yet)
- Even if MacRuby’s primary goal is to allow you to write efficient Cocoa apps, it does not mean that MacRuby is limited to that.
- MacRuby doesn’t require you to learn Objective-C in order to develop Cocoa apps. (you just need to understand Obj-C selectors)
What’s coming up?
The current version of MacRuby (today being the 27th of May 2009) is version 0.4. You might have heard of things about MacRuby crazy performance, LLVM, AOT compilationAOT compilation etc… This is all happening in the ‘experimental’ branch.
What’s going on is that up to MacRuby 0.5, MR was using YARV (Ruby 1.9 interpreter) on top of Obj-C and which obviously limited MacRuby’s to YARV’s performance. After RubyConf 2008, Laurent Sansonetti, MacRuby’s lead developer, decided to try removing YARV to only keep its AST and experiment with using LLVM instead of the 1.9 interpreter.
This switch turned out to be very promising and was noticed right away by influential people such as IBM’s Antonio Cangiano. Since then, performance and compatibility have increased. Laurent even started working on an Ahead Of Time (AOT) compiler: http://pastie.org/485095 What’s really impressive is that in this specific example (Fibonacci sequence), MacRuby’s compiled code is faster than Objective-C! But let’s not jump the gun. First this is a very very early prototype and most of your apps won’t be using Fib. sequences 
In this case, MacRuby’s recursive method dispatch is faster but again, this is just a proof of concept and even though MacRuby is getting close to Obj-C speed, it’s still far from matching Obj-C’s impressive performance.
What this basically means is that you will be able to compile your Ruby code down to binary code. Imagine, taking your Rails app and compiling it down to a binary file that you can just push to your server 
But really, what’s almost more important is that Ruby will get closer to Objective-C’s speed.
Why will MacRuby change the Ruby ecosystem?
As a web developer, getting better performance is great. But Ruby is already fast enough. Rails is faster than any PHP framework out there and when doing Merb’s benchmarks we proved that Ruby for the web can definitely be fast.
Now if MacRuby ends up running 3-7X faster than Ruby 1.9 (no one can tell for sure), existing Ruby developers will certainly be really pleased but it will probably affect more people outside of our community than within. Let’s face it, our community isn’t that big but it’s growing fast and people are mainly coming to Ruby for its web frameworks. But Ruby has much more than that to offer. Desktop applications, video games, scientific computation and even embedded apps. Apple is betting on Ruby probably because of the fact that they see the potential in the language itself.
Would people still use Java if Ruby is as fast/faster than Java? Probably! Would they think about using Ruby for their next project? I would certainly hope so!
Ruby is viral, it’s such a great language, people who have started using it are having a hard time going back to what they used before. But to spread the ‘love’, we need to give people the opportunity to discover why Ruby is so great and to do that, we need to make sure Ruby is relevant to them. By making Ruby a realistic option to write desktop/mobile applications, we are targeting a new audience. An experienced audience which will be able to bring a new perspective to our ecosystem and help it grow.
Of course, MacRuby isn’t the only implementation out there trying to do that. JRuby and IronRuby are also very interesting projects. My take on it, is that MacRuby will be able to change things because of its new approach and potential community. It will more than likely be the first Ruby implementation compiling down to binary code, it will more than likely be the fastest implementation and it will more than likely draw a different type of developer.
Does it mean that JRuby, IronRuby, BlueRuby will be useless? Absolutely not! Matz is the first one to encourage diversity and I agree that this is a great way to move forward. These projects solve different problems and all have pros and cons, but they also all share a similar goal: making Ruby a better and more popular language outside of its original community. JRuby, IronRuby and MacRuby bring Ruby to the respective Java, .net and Cocoa communities, and indirectly bring fresh developers to Ruby. These implementations are critical in the way they actually bridge existing communities and in the end, all Rubyists will benefit from it. Also, even though MacRuby and IronRuby are in active development, JRuby is the only mature alternative to MRI/YARV at this point and it proved that Ruby can coexist in a different community as well as contribute a lot of interesting things back to the Ruby community.
To summarize, I see tremendous potential in MacRuby. There is the obvious technical aspect of the implementation, but also the indirect affect MacRuby could have on our community. I believe that MacRuby is an agent of change and will help bringing more diversity to our community. It will change mentalities and push Ruby to places where it’s being struggling to make a mark. I can see the so-called “Enterprise” people looking at Ruby differently. I also think that MacRuby has the potential to be at the origin of a new type of hybrid application, mixing desktop/mobile/distributed applications with centralized web applications. Why not dream of p2p applications/games using a subset of Rails to communicate between each other and with a central server?
If you are interested in learning more about MacRuby, check the list of resources available on the MacRuby site.
Rich Kilmer and I are also working on a documentation application for Cocoa and HotCocoa as well as a MVC framework for writing Cocoa apps using HotCocoa (HotCocoa is a thin, idiomatic Ruby layer that sits above Cocoa and other frameworks).
Make sure to keep an eye on @macruby and the MacRuby website if you want to keep track of the latest news.
CouchDB with CouchRest in 5 minutes
Posted by Matt Aimonetti in ruby on May 17th, 2009
The other night, during our monthly SDRuby meetup, lots of people were very interested in learning more about CouchDB and Ruby. I tried to show what Couch was all about but I didn’t have time to show how to use CouchDB with Ruby.
Here is me trying to do that in 10 minutes or less. I’ll assume you don’t have CouchDB installed.
Install CouchDB, if you are on MacOSX, you are in luck, download and unzip the standalone package called CouchDBX.
That’s it you have couch ready to go, press play and play with the web interface.
Next, let’s write a quick script. Let’s say we want to write a script that manages your contacts.
First, let’s install CouchRest:
$ sudo gem install couchrest
Now, let’s open a new file and write our script.
In line 4 and 5 we are just setting up the server(by default, localhost is being used). If the database doesn’t exist, it will get created.
SERVER = CouchRest.new
DB = SERVER.database!('contact-manager')
Then, we define your ‘model’, we set the default database to use and define a list of properties. Properties are not required, but they generate getters and setters for you. They are also used to set default values and validate your model. Line 11 shows how to use an alias that will provider a getter and a setter for the property name and the alias name:
property :last_name, :alias => :family_name
Line 14 does something that might seem strange at first. We are casting the address property as an instance of the Address class. Here is what the implementation of the Address class could look like:
Address is just an instance of Hash with some extra methods provided by the CouchRest::CastedModel module. (If you wonder why it’s called CastedModel instead of the more grammatically correct CastModel, the answer is simple: I suck at English grammar :p )
So here is a quick example of how to use a ‘CastedModel’:
That’s part of what’s great with CouchDB, you don’t need to worry too much about storage. Just define your properties, cast to models if needed and save everything as a document.
For more examples checkout the CouchRest spec fixtures and the examples.
To learn more about couchdb, read the (free) online draft of the CouchDB book and of course you probably should read the CouchRest source on GitHub.
-
-
You are currently browsing the archives for the ruby category.
Meet Me
