Why Ruby & Rails Needs Enterprise and Regulations
During the Pragmatic Studio I attended, a subject came up where I voiced concern over the fact that Ruby allows the programmer to override behaviors of “core” components. Dave Thomas explained that the other language designers assume that people are idiots and that’s why they put all the constraints. Although I disagree, I do love the fact that Ruby gives me a great deal of power.
I fell in love with Rails when I saw that Rails lowers the barrier to entry in web application development. What I didn’t realize at the time was that when you put out goodies in the wild, you tend to attract lots of wild animals. I’m finding out that convention over configuration can be abused to a point where I’m constantly trying to look for convention that once existed since Ruby allows you to smash convention.
I’m now accepting the fact that I’ll always be hired to solve problems. That means just about all my projects will be unscalable, full of technical debt, and design dead codes. Considering how young the language and the framework is, I find it somewhat shocking that so many projects are design dead at such early stage.
Now that I think about it, Rails is popular among startups where they have to constantly put up screens to impress investors and change business model. I accept that this is the nature of the beast. Until the time when Rails is used for any enterprise system or any app that is under regulatory constraints, this will remain to be the fact.
Let’s face it, putting out well-tested quality code requires lot more time and effort than just throwing shit on the wall and see what sticks. We all give lip services to TDD or BDD, but when you have a deadline to an investor who wants to see something moving next couple of hours will not allow you to dick around with the quality. Something always gives.
Is this only limited to startups? Absolutely not! However, it is more likely that any enterprise system will be better planned and properly resourced. Sun spent ton of money to get people to follow standards because I remember in early days of Java when this was happening as well.
So, next time you hear a young Railer trashing “enterprise”, please tell him to stop.
Struggling With Testing?
We all know that we need to test our code since we don’t have a compiler in Ruby world. The issue that I come across is NOT how to write the tests, but what to test and how it should be approached. If you think about it, we have plenty of resources on the syntax and the mechanism of testing frameworks, but it ultimately comes down to what your testing strategy is, if there’s any.
I for one, do not subscribe to “test everything” bullshit some Rubyists are pushing. I get annoyed whenever I see tests that do not have any value whatsoever and are completely redundant. I know this will raise uproar but it’s true. When you see it, you’ll know what I’m talking about.
My tip if you’re struggling with testing is to read OPC. With the GitHub, all you have to do is point your browser to test/spec directory in any project. You’ll see both good, bad, and ugly. Form your own strategy based on your exposure, and remember, this is NOT religion! The ultimate goal of this whole thing is to write quality code. As I said before, all is not lost by looking at bad codes.
Hope this helps.
Upgrading Your MongoDB
This morning, I got the notification that MongoDB 1.2.3 was released. Nice!
Unfortunately, I’ve been carrying around my Lenovo ThinkPad X200 running Ubuntu 9.10 since the New Year and completely forgot to update my MBP. It was still running 1.0! When you upgrade from very old version as I did, you’ll be greeted with an error message. What do you do? It’s dead simple, just do the following:
mongod --dbpath
That’s all there’s to it. You can go and upgrade every db files you have.
Are Down With OPC?
Other People’s Code, or OPC as I’d like to call since I am a child of the 80′s, is defined by me as crappy code. Of course I was joking to some extent, but I believe it’s something we need to address.
I always hear about learning to writing good code, but hardly ever hear about learning to READ the code, both good and bad. I was so happy when my fellow teachmetocode.com expert Chuck interviewed JEG (that sounds so much cooler than James Edward Gray III) in his podcast where JEG spoke about reading OPC. If you haven’t checked out his podcast, please do it NOW by going to http://www.railscoach.com.
As a software architect, I read lots and lots of code. I saw some excellent code as well as what can only be described as something only the mother would love.
You see, the code is same as any writing. It tells you what the code is trying to achieve and tells a story. I would compare it to any other fine literature or a junk novel. It has personality and style. It also tells the story of what was happening at the time of writing. For example, when I see that unit tests are missing when the rest of code base isn’t, it’s a sign of something being pushed out in a hurry.
Having said all that, I’d like to share my method for reading code. The most of this will be “duh, no kidding”, but I think it’s a good refresher.
- Before sitting down to read the code, I get an understanding of the final outcome.
- Understand the convention, design pattern(s), and the opinion of the framework.
- Have the language reference, API docs, and any other reference material
- Identify the entry point. I came from C, leave me alone!
- Identify the prerequisites.
- Start reading
- As I read, try to put myself in the same shoes as the person writing the code. e.g. what is his thought patterns, why did he do this way, is this guy a beginner or expert, is he trying to say “fuck you” to anyone reading the code, why is he writing Java code in Ruby, and etc.
- Follow the steps and write them down on a writing pad
- Absorb and appreciate, even if I think it’s a pile of crap
Next time, I may actually create a screencast going over a code review if I can find the time. Let me know.
