Rails rocks, X sucks: How Provincial

I seem to be coming across more and more [Steve] Jobs-clones or simply no-thinking Apple fan boys lately. I don't mind the Apple fans that thought themselves about why they love their stylish new Macbook Pro, I have just had enough of the no-thinking variety of Apple zealots.

This part of the Rails community appears to be a large population unfortunately. Because these fan boys are actually incapable of thinking on their own, they adopt other people's arguments and say things like: "Rails rules, X sucks because so-and-so said this...". Hmmmm. Need I say more?

On the other side I recently came across a Django fan boy who tried to convince his non-technical manager that Rails "cannot scale period". Hmmmm. How original. A blanket statement like this is not only misleading, it is actually in many ways technically incorrect. This is why in middle school we learned how to qualify our arguments. Why is it that supposed college graduates cannot do this in their 20s and 30s? It is one thing to strip out technical jargon for non-technical managers to understand a situation, but it is quite another to over simplify and mislead them because you have your own tech-religion agenda. Be passionate, but admit to yourself and others when passion is getting the better of you.

Why is acknowledging your chosen solution's weakness bad? Doesn't it actually make the solution implementation stronger if you have thought about scenario-based weaknesses?

How about we each try to *qualify* our positions on technology solutions out there, rather than figuratively urinate all over others without any basic respect for them. I encourage criticism, but criticize constructively. Say why. On the flip side, we should also accept constructive criticism too.

The first step to constructive criticism, need not necessarily be candy coating your critique, but having the right intentions behind your critique. For example, if your motivation for giving criticism is to start a flame war (sorry that is probably a very out of date term now), then you will probably get what you want. However, if you really want to help a project get better because you care, then that is the first step.

In addition, the way you word and tone statements (as Twitter's Alex Payne should have learned all too well by now) has a big impact. For example, Alex Payne's statements about Rails and Ruby cost me a contract at a former Rails shop that had a conniving PHP zealot waiting in the wings to jump on anything and take issue with Rails to upper management. Lucky for him, it worked and he had 3 to 4 months of leading a team to miserable failure using Drupal as a "platform". Not necessarily a reflection of PHP (or Drupal for CMS applications since it was far from a CMS application), but a reflection of this calculating pseudo-coder's inability to lead a project. A "technical" manager who thought the kernel version on his Fiesty Ubuntu laptop was 7.0.4. Enough said!:)

Overall, I hope we can start to have intelligent conversations about software stacks rather than "yours sucks ass". Because the latter in the end favors nobody.

PS Merb rulez and Rails suckz!:) If you want to know why read my teaser entry titled Why Merb is delicious, though I plan on writing more soon.

PPS Merb wouldn't be where it is today without Rails.

Why Merb is delicious

Below are the reasons why Merb is more delicious than other MVC web frameworks I have worked with (including Rails):

• On a diet...It is lighter weight than most, but still has enough oomph to implement common features with minimal code
• Religion-free...It is ORM, JavaScript/AJAX and testing/speccing library agnostic.
• The sum of it's parts...OK that was a lame segway, but parts is a mightily useful feature where a plugin is just total overkill. Just because Java calls something a "component" does not make it the general definition of a component in concept. And now look at the Rails plugin debacle today.
• Precious gems...Plugins are created, distributed and installed in the form of beautiful RubyGems as opposed to the Rails plugin catastrophe with Gigabytes of duplicate disk space and lame version/revision control
• It's exceptional...Merb actually thought about how to do exception handling in controllers before Rails came up with something and also came up with IMHO a better solution.
• Speedy Gonzalez...Compared to especially Rails, Merb performs very nicely indeed.
• Loose threads...Merb is thread-safe unlike Rails, so that means one process can handle multiple concurrent file uploads, where Rails cannot right now.

All together I think most people will find Merb to be a much better thought out (conceptually) MVC framework than Rails. Over the next few weeks I'll be talking a lot about Merb and it's delicious APIs, Plugins, etc. as it nears it's 1.0 release.

Comedy of Errors

Does anyone else find it comical that the Chicago Java Users Group website is written in Rails? And apparently not very well if it is not only sending a HTTP 500 error, but still using the default Rails generated 500.html page. Poor all around.

An IM buddy mentioned it might be JRuby, but I do think it is still very ironic considering the hostility from the Java world regarding Rails in general (whether Ruby on Rails or JRuby on Rails).

I just had to share!:)

Update: Someone fixed it shortly after I reported it to CJUG.

Update: Actually it was only temporarily fixed, it is back to the default 500 Rails error page.

Update: In addition they have exposed their SVN information. See the public entries and from that information you can find their non-password protected source code and check it out if you like.

If anyone from CJUG is reading, you can fix this by reading my blog entry from two months back called Preventing Information Leaks, Part 3. Although it might be useful to read part 1 and part 2 as well. Cheers!

PS I also sent an email to info at cjug.org and received an email delivery error.

Update: I may have read too much into the SVN repository information exposure in this specific case since this is an open source Rails application project (I only just realized), thus the non-password protected repository, but I still stand by the rest!:) It is also not good practice to expose such information from the outset of deploying an web application.

Update (1.5 hours after trying to notify JUG and posting the blog post): The site has been fixed now for over 5 minutes, so good job fixing it CJUG!:)

Update (8 minutes later): Ooooops! It is back to the default Rails 500 error page. Perhaps it is 2 out of three bad FastCGI processes that need to be killed on the server? HTH someone at CJUG, but since I can't look at the system I can't say for sure.

Coding with Explicit Intentions

Recently I have had the [mis]fortune to be working with PHP for integration purposes for a client. A partner of my client's (in the advertising space) sent us some PHP code to add to our servers for resolving the content type of a file based on its extension. The line of code in the PHP script they sent over that was supposed to determine the file extension was:

  $ext = substr($file,-4);

As you can see they are making a pretty big assumption - that the extension is exactly three letters long. The media files that this script *may* support in the future are: Real Media (.rm), MPEG (.mpeg), Quicktime (.qt), etc. These extensions are not exactly three letters long. Why would someone want to write code that is quite likely to fail and also not communicate more explicitly their intentions?

This partner already doesn't support PHP < 4.0.3, so why not substitute the line above with:

  $ext = ".".pathinfo($file, PATHINFO_EXTENSION);

It is standard, will never fail (unless there is a defect in the PHP version you are using for the standard function pathinfo, but what can you do about that?) and communicates the explicit intent of the original author, thus improving code maintainability.

Anyway, just a pet peeve. This is not by any means the only example I see on a day in day out basis, this just happened to be a great example for me to demonstrate my point. While this example demonstrates a minor one-line demonstration, if developers introduce even only 2-3 of these un-explicit intentioned lines of code a day that do not always do what you might want it to do, then the codebase quickly becomes a mine field.