Archive for category ruby
Discussion with a Java switcher
Posted by Matt Aimonetti in Misc, rails, ruby on August 22nd, 2010
For the past 6 months, I have had regular discussions with an experienced Java developers who switched to Ruby a couple years ago. Names have been changed to protect the guilty but to help you understand my friend ‘Duke’ better, you need to know that he has been a developer for 10 years and lead many complicated, high traffic projects. He recently released two Ruby on Rails projects and he has been fighting with performance issues and scalability challenges.
Duke is a happy Ruby developer but he sometimes has a hard time understanding why things are done in a certain way in the Ruby community. Here are some extracts from our conversations. My answers are only based on my own experience and limited knowledge. They are probably not shared by the entire community, feel free to use the comment section if you want to add more or share your own answers.
Threads / Concurrency
Duke: Why does the Ruby community hate threads so much. It seems to be a taboo discussion and the only answer I hear is that threads are hard to deal with and that Ruby does not have a good threading implementation. What’s the deal there? If you want concurrent processing, threads are important!
Me: This is a very good question and I think there are two main reasons why threads and thread safety are not hot topics in the Ruby world. First, look at Ruby’s main implementation itself. If you are using an old version of Ruby (pre Ruby 1.9) you don’t use native threads but green threads mapping to only 1 native thread. Ilya has a great (yet a bit old) blog post explaining the difference, why it matters and also the role and effect of the Global Interpreter Lock (GIL). Also, even though Rubyists like to say that they live in the edge, most of them still use Ruby 1.8 and therefore don’t really see the improvements in Ruby 1.9 nor yet understand the potential of fibers.
The other part of the explanation is that the Rails community never really cared until recently. Yehuda Katz recently wrote a good article on thread safety in Ruby and if you read his post and Zed Shaw’s comment you will understand a bit better the historical background. As a matter of fact, the current version of Rails is not multi-threaded by default and developers interested in handling concurrent requests in one process should turn on this option. Thread safety appeared for the first time in Rails 2.2 but from what I saw, most people still don’t enable this option. There are many reasons for that. First, enabling thread safety disables some Rails features like automatic dependency loading after boot and code reloading. A lot of Rails developers take these two features for granted and don’t understand that they are technically “hacks” to make their lives easier. I do believe a lot of Rails developers don’t understand how threads, thread safety, concurrency, blocking IO and dependencies work. They care about getting their app done and meet their deadlines. They usually use and know Rails without paying too much attention to how Rails extends Ruby. Imagine what would happen if their code wasn’t thread safe and Rails wasn’t not using a global lock by default. Now you see why things are not exactly as you expect and also why some Rubyists are getting excited about new projects like node.js which takes a different approach.
The other thing to keep in mind is that at least 90 to 95% of the Rails apps out there don’t get more than a dozen requests/second (a million requests/day). You can scale that kind of load pretty easily using simple approaches like caching, optimize your DB queries, load balancing to a couple servers. As a matter of fact, compared to the amount of people using Rails on a daily basis, only a very little amount of people are struggling with performance and scalability like you do. This is not an excuse but that explains why these people don’t care about the things you care about.
Rails is slow
Duke: I don’t understand why Rails developers are not more concerned about the speed/performance penalty induced by Rails.
Me: Again, Rails is fast enough for the large majority of developers out there. As you know, as a developer you have to always make compromises. The Rails team always said that development time is more expensive than servers and therefore the focus is on making development easier, faster and more enjoyable. However to get there, they have to somewhat sacrifice some performance. What can be totally unacceptable for you is totally fine for others and your contribution is always welcome. This is probably the root cause of the things you don’t like in Rails. Rails was built for startups, by startup developers and you don’t fall in this category. People contributing new features and fixes are the people using Rails for what it is designed to do. There is no real ‘Enterprise’ support behind Rails and that might be why you feel the way you feel. Since you find yourself questioning some key Rails conventions and you are struggling with missing features, it looks to me that you chose the wrong tool for the job since you don’t even use 70% of the Rails features and are dreaming of things such 3 tier architecture. Sinatra might be a better fit for you if you want lower level control, less conventions and less built-in features.
Object allocation / Garbage Collection
Duke: I recently read that Twitter was spending 20% of its request cycles in the GC, am I the only finding that concerning?
Me: Most people don’t realize how the GC works and what it means to allocate objects since Ruby does that automatically. But at the same time, most of these people don’t really see the affect of the Garbage Collection since they don’t have that much traffic or they scale in ways that just skips their Ruby stack entirely. (Or they just blame Ruby for being slow)
If you are app deals with mainly reads/GET requests, using HTTP caching (Rails has that built-in) and something like Varnish/Rack-cache will dramatically reduce the load on your server apps. Others don’t investigate their issues and just add more servers. As mentioned in a previous post, some libraries like Builder are allocating LOTS more objects than others (Nokogiri), use the existing debugging tools to see where your object allocations occur and try to fix/workaround these. In other words, Ruby’s GC isn’t great but by ignoring its limitations, we made things even worse. My guess is that the GC is going to improve (other implementations already have better GCs) and that people will realize that Ruby is not magic and critical elements need to be improved.
Tools
Duke: I really have a hard time finding good tools to help scale my apps better and understand where I should optimize my code.
Me: It is true that we area lacking tools but things are changing. On top of the built-in tools like ObjectSpace, GC::Profiler, people interested in performance/debugging are working to provide the Ruby community with their expertise, look at memprof and ruby-debug for instance. Of course you can also use tools such as Ruby-prof, Kcachegrind, Valgrind and GDB. (1.9.2 was scheduled to have DTrace support but I did not check yet). Maybe you should be more explicit about what tools you miss and how we could solve the gap.
ActiveRecord
Duke: ActiveRecord doesn’t do what I need. How come there is no native support for master/slave DBs, sharding, DB view support is buggy, suggested indexes on queries is not built-in and errors are not handled properly (server is gone, out of sync etc..)?
Me: You don’t have to use ActiveRecord, you could use any ORM such as Sequel, DataMapper or your own. But to answer your question, I think that AR doesn’t do everything you want because nobody contributed these features to the project and the people maintaining ActiveRecord don’t have the need for these features.
What can we do?
We, as a community, need to realize that we have to learn from other communities and other programming languages, this kind of humorous graph is unfortunately not too far from reality.
Bringing your expertise and knowledge to the Ruby community is important. Looking further than just our own little will push us to improve and fulfill the gaps. Let the community know what tools you are missing, the good practices you think we should be following etc…
Take for instance Node.js, it’s a port of Ruby’s EventMachine / Python’s twisted. There is no reasons why the Ruby or Python versions could not do what the Javascript version does. However people are getting excited and are jumping ship. What do we do about that? One way would be to identify what makes node more attractive than EventMachine and what needs to be done so we can offer what people are looking for. I asked this question a few weeks ago and the response was that a lot of the Ruby libraries are blocking and having to check is too bothersome. Maybe that’s something that the community should be addressing. Node doesn’t have that many libraries and people will have to write them, in the mean time we can make our libs non-blocking. Also, let’s not forget that this is not a competition and people should choose the best tool for their projects.
Finally, things don’t change overnight, as more people encounter the issues you are facing, as we learn from others, part of the community will focus on the problems you are seeing and things will get better. Hopefully, you will also be able to contribute and influence the community to build an even better Ruby world.
Ruby object allocation & why you should care
Posted by Matt Aimonetti in Misc, rails, ruby on July 29th, 2010
Recently I was tasked with finding how to optimize a web application with heavy traffic. The application (a Rails 2.3.x app) gets about 3 million requests per hour and most of these requests cannot really be easily cached so they go through the entire stack.
This is probably not the case of most web apps out there. None the less, my findings my help you understand Ruby better and maybe think differently about memory management.
This is certainly not an advanced GC blog post, I will try to keep it as simple as possible. My goal is to show you how Ruby memory allocation works and why it can affect your app performance and finally, how can you avoid to allocate to many objects.
Ruby memory management.
Rubyists are quite lucky since they don’t have to manage the memory themselves. Because developers are lazy and Matz developed his language for people and not machine, memory is managed “magically”. Programming should be fun and managing memory isn’t really considered fun (ask video game developers or iOS programmers 
).
So in Ruby, the magical memory management is done by a Garbage Collector. The GC’s job is to run and free objects that were previously allocated but not used anymore. Without a GC we would saturate the memory available on the host running the program or would have to deallocate the memory manually. Ruby’s GC uses a conservative, stop the world, mark-and-sweep collection mechanism. More simply, the garbage collection runs when the allocated memory for the process is maxed out. The GC runs and blocks all code from being executed and will free unused objects so new objects can be allocated.
Joe Damato did a great talk on that matter during last RailsConf
Garbage Collection and the Ruby Heap
The problem is that Ruby’s GC was not designed to support hundred thousand objects allocation per second. Unfortunately, that’s exactly what frameworks like Ruby on Rails do, and you might contribute to the problem too without even knowing it.
Does it really matter?
I believe it does. In my case improving the object allocation means much better response time, less servers, less support and less headaches. You might think that servers are cheaper than developers. But more servers mean more developer time spent fixing bugs and more IT support. That’s why I think, memory management is something Ruby developers should be aware of and should take in consideration, especially the ones writing frameworks, libraries or shared code.
I am using Ruby 1.9 so I could not profile my Rails 2.x app using memprof, instead I wrote a simple and basic middleware that keeps track of the memory allocation/deallocation and GC cycles during a web request (Ruby1.9 only). One of my simple Rails2 actions (1 DB call, simple view) is allocating 170,000 objects per requests. Yes, you read right: 170k objects every single request. At 3 million requests/hour, you can imagine that we are spending a LOT of time waiting for the GC. This is obviously not 100% Rails fault as I am sure our code is contributing to the problem. I heard from the memprof guys that Rails was allocating 40k objects. I decided to check Rails3.
After warming up, a basic Rails3 ‘hello world’ app clocks at about 8,500 objects allocated per request, forcing the GC to run more or less every 6 requests. On my machine (mac pro) the GC takes about 20ms to free the objects. A Rack ‘hello world’ app clocks at 7 objects per request and a Sinatra app at 181 objects. Of course you can’t really compare these different libraries/frameworks but that gives you an idea of the price you pay to get more features.
One thing to remember is that the more objects you allocate, the more time you “lose” at code execution. For more developers, it probably doesn’t matter much, but if you should still understand that concept especially if you decide to contribute to the OSS community and offer patches, libraries, plugins etc…
What can I do?
Be aware that you are allocating objects, for instance something as simple as 100.times{ ‘foo’ } allocates 100 string objects (strings are mutable and therefore each version requires its own memory allocation).
Make sure to evaluate the libraries you use, for instance switching a Sinatra XML rendering action from Builder to Nokogiri XML Builder saved us about 12k object allocations (Thanks Aaron Patterson). Make sure that if you are using a library allocating a LOT of objects, that other alternatives are not available and your choice is worth paying the GC cost. (you might not have a lot of requests/s or might not care for a few dozen ms per requests). You can use memprof or one of the many existing tools to check on the GC cycles using load tests or in dev mode. Also, be careful to analyze the data properly and to not only look at the first request. Someone sent me this memory dump from a Rails3 ‘hello world’ with Ruby 1.8.7 and it shows that Rails is using 331973 objects. While this is totally true, it doesn’t mean that 330k objects are created per request. Instead that means that 330k objects are currently in memory. Rubygems loading already allocate a lot of objects, Rails even more but these objects won’t be GC’d and don’t matter as much as the ones allocated every single request. The total amount of memory used by a Ruby process isn’t that important, however the fluctuation forcing the GC to run often is. This is why my middleware only cares about the allocation change during a request. (The GC should still traverse the entire memory so, smaller is better)
The more object allocation you do at runtime/per request, the more the GC will need to run, the slower your code will be. So this is not a question of memory space, but more of performance. If your framework/ORM/library/plugin allocates too many objects per request maybe you should start by reporting the problem and if you can, offer some patches.
Here are some hints about memory allocation:
Creating a hash object really allocates more than an object, for instance {‘joe’ => ‘male’, ‘jane’ => ‘female’} doesn’t allocate 1 object but 7. (one hash, 4 strings + 2 key strings) If you can use symbol keys as they won’t be garbage collected. However because they won’t be GC’d you want to make sure to not use totally dynamic keys like converting the username to a symbol, otherwise you will ‘leak’ memory.
Looking at a GC cycle in the Rails3 hello world example shows what objects get deallocated:
GC run, previous cycle was 6 requests ago.
GC 203 invokes. (amount of cycles since the program was started)
Index 1Invoke Time(sec) 25.268
Use Size(byte) 4702440
Total Size(byte) 7307264
Total Object 182414
GC Time(ms) 22.35600000000204090611
## 56322 freed objects. ##
[78%] 44334 freed strings.
[7%] 4325 freed arrays.
[0%] 504 freed bignums.
[1%] 613 freed hashes.
[0%] 289 freed objects.
[5%] 3030 freed parser nodes (eval usage).
I did not list all the object types but it’s pretty obvious that the main issue in the case of Rails is string allocation. To a certain extend the allocated arrays and the runtime use of eval are not helping either. (what is being eval’d at runtime anyway?)
If you use the same string in various place of you code, you can “cache” them using a local var, instance variable, class variable or constant. Sometimes you can just replaced them by a symbol and save a few allocations/deallocations per request. Whatever you do tho, make sure there is a real need for it. My rule of thumb is that if some code gets exercised by 80% of the requests, it should be really optimized and avoid extra allocations so the GC won’t slow us down.
What about a better GC?
That’s the easy answer. When I mentioned this problem with Rails, a lot of people told me that I should use JRuby or Rubinius because their GC were much better. Unfortunately, that’s not that simple and choosing an alternative implementation requires much further research and tests.
But what annoys me with this solution is that using it is not solving the issue, it’s just working around it. Yes, Ruby’s GC isn’t that great but that’s the not the key issue, the key issue is that some libraries/frameworks allocate way too many objects and that nobody seems to care (or to even know it). I know that the Ruby Core Team is working on some optimizations and I am sure Ruby will eventually get an improved GC. In the meantime, it’s easy to blame Matz, Koichi and the rest of the core team but again, it’s ignoring that the root cause, totally uncontrolled memory allocation.
Maybe it’s time for us, Rubyists, to think a bit more about our memory usage.
I did it wrong
Posted by Matt Aimonetti in Misc, ruby on March 15th, 2010
The Ruby community is a well known for at least two things: being passionate and being arrogant .
Two characteristics that often go together but I am not going to defend or justify anything in this post, instead I will try to reflect on my own experience and will share with you my own view point.
Very much like the Ruby community, I am also quite passionate and can be arrogant at times. A few months back I was in Brazil for RailsSummit and I was chatting with David Chelimsky after a nice evening with the RailsSummit attendees. I was thinking about how cool it was to have people from various non-Ruby communities to come to a Ruby community and share their experience and knowledge while observing the ways we do things with Ruby.
David and I got to talk about technical evangelism, how RSpec became very popular, the whole Merb vs Rails situation which turned into Rails3, as well as MacRuby and Apple. I was interested by the fact that I couldn’t remember David ever saying something bad about test/unit or trying to tell others they were doing it wrong. Instead, he has always tried showing why people might be potentially interested by RSpec.
As an early RSpec adopter, I often thought that people were wrong not to use the solution that I thought was the best. As part of the Merb ‘propaganda’, we spent a lot of time comparing Merb with Rails and showing why Merb might be better for you and why you were doing it wrong if you would fit in Merb’s target and still use Rails.
Even before that, I remember thinking that if you were not using Ruby, you were doing it wrong. PHP & Java developers were, for me, just developers who did not know any better (and I thought that Python-ers were just too lazy to learn a “better” language that takes OOP seriously ).
Since then, things have changed. I have gotten involved with other projects, met different people and maybe, just maybe, matured a little bit. Going back to the discussion I had with David, he pointed out to me how often people talk about a piece of technology or an idea to just quickly conclude: “it sucks” and it has got even worse lately with the ‘you’re doing it wrong ‘ meme.
Basically, we judge people’s actions without knowing them or even having a clue about the problem they are facing and we just tell them that if they don’t do like us, they are wrong. If they are not using this plugin or this gem, they are doing it wrong, and if they are using this other one that sucks, they are also doing it wrong. Also, be careful, something that’s hot today will probably turn out to be ‘the suck’ soon enough, keep up with what the cool kids tweet about
But of course, this is something human and much bigger than the Ruby community. Look at the whole SQL/NoSQL pseudo fight and you will notice the same attitude. Look at the editors war, look at the OS war or even look at the TV with shows like ‘Marriage Ref‘ making money off of people wanting to prove their partner that he/she is doing it wrong. But that’s also the root problem of most religion wars and even the motivation for some people to go ‘invade/colonize’ other countries to eventually force their world vision upon them.
I realize the irony of writing of blog post to tell my readers that telling others that they are doing it wrong is, in itself, fundamental wrong, but maybe next time you think something sucks or is totally wrong, you might want to try to understand the motivation behind why some people decided to go this way. I know I will personally try harder.
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..
-
-
You are currently browsing the archives for the ruby category.
MacRuby Book
Read the draft of my upcoming MacRuby book for free: http://macruby.labs.oreilly.com.
Add comments online or via the book's mailing list