Comedy of Errors

Written on 10:23:00 AM by S. Potter

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

Written on 10:34:00 AM by S. Potter

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 shows just a minor one-line example, 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.