Couple months ago, I published an article about Ruby On Rails. I was wrong.
The idea of Ruby On Rails is really good. You can create a very simple database-driven web application (i.e., User can add, browse, remove and search records) in less than half an hour. There is no way to do something similar in such a short time using other programming languages. However – perhaps this is the tradition of the Rails development team, it comes with surprise (“Rails Surprise”) every time after upgrading the Ruby gems component. They either make your Rails application couldn’t start, or some features in your apps are not functioning after the upgrade.
What kind of people should stick with Ruby On Rails?
- Someone is big fan of Ruby/Gems/Rails.
- Someone has plenty of spare time.
- Someone likes to sharpen his/her debugging skill – To debug the backward incompatibility mess introduced by the Ruby/Gems/Rails core development team.
- Someone is patient and is willing to spend number of hours(could be days) to look for workaround.
I am neither. I think I already have enough “Rails Surprise”. And I will make my own web application framework from now on (The code name is called ICEPIZZA by the way). It will be simple, elegant and backward compatible.
I haven’t upgraded my Ruby On Rails and related Ruby gems for 5 months. One of the reasons is that Rails development team likes to break the backward compatibility, such as:
NameError: uninitialized constant ApplicationController
To avoid this kind of surprises, I tend to stick with a working, stable version.
Recently, I upgrade the entire Ruby On Rails family(2.3.2 -> 2.3.4), and surprisingly, my Ruby On Rails apps work perfectly fine! One exception is that the Mongrel server behaves a little bit slower than before. One way or the other, we need to use the load balancing technique to host the Rails App anyway. So it really doesn’t matter.
In case you want to try upgrading your Ruby Gems and other things:
Update the Ruby Gem Engine:
sudo gem update --system
Update other Ruby Gems:
sudo gem update
Recently I developed several projects using Ruby on Rails. One of the cool features of it is the built-in test tools. With this amazing tool, I can test my web page such as data validation in few seconds by myself. It reminds me the time how a software was tested in the company I worked for previously.
In the formal company I worked for, they had a very well Quality Assurance Team for testing the software functionality(The ratio of developer to QA is about 3:2). Usually we (developer) need to come up many test cases for them (e.g., testing the data field with positive, negative or invalid value) because the QA team does not have any technical background. Other than that, the QA team would only focus on the GUI level testing, such as whether this control is aligned with the label or not etc. One of the key components that has been ignored is the stress test.
I still remember that I developed a resource-consuming feature, and I was worrying about its impact of overall performance when many uses are using this feature at the same time. So I talked with my QA and see what he think. Initially I expected that he would run a stress test (e.g., simulating 100 thousands of users to use the feature at the same time), and guess what his answer?
I can schedule an appointment with the rest of the QA team, we can sit down together and try to use your feature at the same time.
No, this is not a joke. In fact, about a month later, someone from other application team really does something fancy about it. They sent out a mass email and ask people to sign up. They end up having about 900 uses to use the application at the same time. That’s about 1/3 of the whole population in the company!
I think it is kind of stupid to ask 1/3 of the whole company to do a simple test, which can be done using computer automatically! Think about how expensive is the test:
900 people x $40/hr x 2 hour = $72,000
With this amount of money, they can probably hire one to two QAs to work on the test for a year!