The Puerto Rican Rails Dude

After two years, yesterday was my final day of being a developer for BarterQuest. As anyone living in expensive New York City in the same situation, I have been focusing part of my energy looking for a new gig. I’m pretty confident, despite the current economy, that I will land on my feet sooner rather than later. I have a few leads, with one in particular that I am really hoping will come through.

In the meantime, I’m not just throwing my resumé in the face of companies everywhere in the U.S. I have also decided that since now that I have quite a few extra hours in my days, I should really do productive things instead of sitting on my couch and re-watching all previous seasons of 24 (believe me, I would watch all 7 seasons in a row if I could) or jamming away to Guitar Hero. This is a perfect chance to do lots of technical things I’ve been wanting to do for months, but just never got the time to do so. Here’s a short list of some goals I’d like to get started on.

Learning new stuff

For the past two years, I’ve been exclusively using Ruby and Ruby on Rails at my day job. I’ve always wanted to broaden my skills by doing other types of programming, but when you take into consideration that I would usually be at work more between 9-10 hours per day, plus a commute that would sap an additional two hours, there wasn’t much time for me to be able to do personal things, let along learn new stuff. Now that I’m finally free, I can now spend more time with those things I’ve wanted to experiment with.

I’ve always wanted to learn iPhone application development. I know the basics of Objective-C, and have the book iPhone SDK Development by Bill Dudney, but I was never able to sit down and code something up. I have a few ideas for apps, so even if I can make a simple app that’s accepted to Apple’s App Store will be an achievement for me.

I’ve been very interested in implementing Push technology to web apps, like Comet or Web Sockets, using nginx’s Push Module and Orbited.

Although I’ve never had the opportunity to work with extremely large data sets, I’ve always been curious about frameworks like Google’s MapReduce and Apache Hadoop, particularly how well they can “crunch” the data thrown at them.

Keep on with what I already know

As I mentioned, I’ve been using Ruby for years now, and I know Ruby on Rails and Sinatra pretty well. However, just because I want to learn new things doesn’t mean that I want to abandon this awesome language. In fact, I want to keep using it more with the latest toys.

Thanks to Ruby Version Manager, I was able to safely install the latest versions of Ruby 1.9 and MacRuby and start learning their new features. I was also able to check any possible compatibility issues in my older applications with different major Ruby versions. Seriously, if you are a Ruby developer using a Mac or Linux, install RVM now if you haven’t.

Recently, there have been more and more news about Ruby on Rails 3, the next major release for the wonderful framework. I’d like to stay one step ahead of the pack and start learning about the new changes before it officially hits the web. One of the leaders of the newest Rails changes, Yahuda Katz, has written lots of blog posts relating to the changes in Rails 3. They’re definitely worth a read.

Strengthening my shortcomings

There are quite a few things – development-wise – that have been bugging me for a long time, yet I’ve never taken the proper steps to correct. Now is as good a time as any to take on these things and finally conquer them.

My main weakness, as a web developer, is that I’m pretty bad at design. I know CSS and its properties, I know about browser incompatibilities (having been a victim many times before by the evil and immortal Internet Explorer 6 browser) and all that stuff. But as far as design goes, like font sizes, element placement, usability and colors, these things are not my strong suit. I’ve actually stocked up on some books about these subjects (like Don’t Make Me Think by Steve Krug and Web Design for Developers by Brian Hogan), so I hope that by the time my unemployment ends, I’ll be much better off making my work look good – or at least decent.

Another weakness I consider is that I get distracted from development from time to time. It’s not frequent enough to affect the quality of my work, but it’s enough to annoy me when I do it subconsciously and I then catch myself in the act. I have read some people who had some success using the Pomodoro technique, so starting tomorrow I decided that I’ll give it a try. There’s a nice little app called Concentrate for the Mac that seems to be just the thing I need during those times when I need to get stuff done and not get distracted.

Beef up my GitHub profile

I have to admit that I’m a little bit ashamed to see my GitHub profile virtually empty. For a long time, I’ve been wanting to add more of the projects that I have in my laptop to GitHub and see if some of them take a life of their own. Sadly, for whatever reason, I haven’t done that. Most of the times I’m a bit too critical at my code and think it’s embarrassing to make public, but that’s really what I need to do to get better as a developer. I can take criticism with the best of them, so there’s really no excuse. I need to make more of my code open-source, period.

Not only do I want to show my own work, I also want to give back to the community. I have used so many open-source projects over the years, yet I’ve only submitted a handful of patches to very few projects. I don’t want to be a person who takes, takes, takes and never gives anything back in return. So I’m going to take steps to correct that. I’ve started cloning some repositories of my favorite projects from GitHub to my computer to start reading their code more in-depth, which I had been doing anyway. I’ll check if these projects have Lighthouse pages with open tickets, or if there are any open issues on their GitHub page. A few years ago, Dr. Nic wrote an excellent post titled “8 steps for fixing other people’s code” that inspired me to start finding features or defects that I can handle.

I have to say, I’m only one day into this routine, and I don’t remember the last time I felt this free and liberated doing what I wanted to do. Full-time employment is great for earning money and making substantial stuff, but sometimes there’s a feeling of emptiness due to not being able to explore on your own. Being unemployed doesn’t mean that you need to spend all your time looking for work. Unless you’re truly struggling economically and can’t pay the bills in the next couple of weeks or even days, why not spend part of your time gearing up for the future?

Today I stumbled upon a site which shows how to create a ‘magical’ user registration form, using a little bit of CSS and jQuery magic. Go ahead, play around with it once. I’ll wait.

Are you finished? Good. Now please don’t ever do this in your own websites. Ever.

Have you ever been around other websites where you need to register, only to see a humongous form that needs to be filled out? Chances are, as soon as you saw that huge form, you clicked on the ‘Back’ button of your browser, never to return again.

Now, imagine the same site and it still requires you to fill out that huge form. However, instead of showing you upfront about the time you need to spend filling out that info, it only shows you two fields. You immediately think “Cool, I’ll be registered in no time at all!” Then you click on the ‘Registration’ button… And more fields pop up. Begrudgingly, you fill out these additional fields… Only to be shown more fields. Do you see where I’m going?

Don’t torture your users into filling out needless information. Unless you’re working with some government or financial entity, you really don’t need all that information, do you? Keep it as simple as you possibly can. For example, I loved Heroku’s sign up process, where just an email address is required. They send you a link through email, where you click and voilà, you are now a registered Heroku user. Simple and effective.

Another alternative is what’s called “Lazy Registration”, where you can actually use the main functionality of the site without registering. Only when you need to actually register for something (like to save the information for future use), the sign-up form will appear. By this time, the user will know how much value your site gives to them, so if they were happy with what they saw with the non-registration parts of your site, they will gladly register and continue to use your site in the future. Also simple and effective.

You ultimately decide what needs to be in your registration form. Just don’t be surprised when you find that your 5-step registration process isn’t gaining any new users to your site. We’re not really dying to use your site, you know.

Update: As soon as I posted this, Jason Fried from 37signals wrote a post about signup form redesigns for their products. I thought I would add it here, as 37signals is a company I respect and appreciate for writing these kind of posts.

One of the not-so-joyous moments of being a web developer is the fact that we still need to support browsers that are ancient (by technological standards). Specifically, I’m talking about Internet Explorer 6.0. A quick look at the site statistics of one of the major websites I’m currently working on says that 16.9% of users visited our site using Internet Explorer 6.0. That’s obviously not the majority – Internet Explorer 7.0 takes that honor with 38.4%, followed by Firefox 3.0 with 19.8%. But it’s still a large enough number for the higher-ups to decide not to ignore it.

Since I never, ever use Internet Explorer 6.0 for any regular browsing (and you shouldn’t, either – read why on sites like Browse Happy), this past week I decided to give the site a test run with Internet Explorer 6.0 (using IEs 4 Linux). Besides the frustration of finding some incompatibilities with standard CSS on this browser, everything else seemed to work well. I then triggered an error on purpose, just to make sure our error handling would be handled properly (display our custom 404 error page instead of a nasty -yet customized – 500 error page). To my surprise, Internet Explorer 6.0 decided to render its own friendly error page instead of our custom one.

Thinking one of my colleagues removed it for whatever reason, I fired up Firefox and triggered the same error. The custom 404 page appeared correctly. Heading over to a Windows laptop, I had the custom error page on all browsers, including Internet Explorer 7.0. This left me scratching my head for a while. Although I’m already used to Internet Explorer 6.0 to act in different ways, standards be damned, this act seemed to be stupefying.

I was about to give up, thinking that Internet Explorer 6.0 used to hijack everyone’s custom error page just to hawk their own, I did a search on 404 error pages. Lo and behold, Wikipedia came through with a response that I would have never guessed:

Internet Explorer (before Internet Explorer 7), however, will not display custom pages unless they are larger than 512 bytes, opting to instead display a “friendly” error page.

Wow. Who knew that size mattered? On a custom error page, of course.

Our custom 404 was basically just a regular HTML with the standard tags, and one image and it weighed less than 300 bytes. I couldn’t modify the design or anything, so I just padded the error page with a long, boring and senseless comment, explaining why said comment was there. After ‘fattening up’ the file to more than 512 bytes, the error page started appearing on Internet Explorer 6.0.

It turns out that older versions of Internet Explorer had a threshold value in the registry which decided whether to display their own error page or a custom one. Why? I have no idea. Thankfully that was fixed for recent versions. But for all of the unlucky ones who still have to support ancient technology, this is another special Internet Explorer 6.0 quirk that needs to be taken into consideration.

For more information, including the default size limitations for other error pages, read this site (aptly named ‘404-error-pages.com’) has all the information you need.

Today I had a pretty frustrating moment. I made some new changes in the morning, which included the addition of a new column in the database. This field wasn’t required, but I needed to limit the amount of characters a user could enter in that string. So I did the proper thing and set this in my model:

validates_length_of :locations, :maximum => 200

I did a quick test, and the validations worked great. So I promptly committed the code to our repository. A few minutes later, our Continuous Integration system sent me a nasty E-Mail: I broke the build.

I frantically searched the errors in the test, and it seemed that the tests were expecting that field I just added to have something. I was stumped, thinking that unless you specify validates_presence_of, set a range of characters in the validates_length_of or perhaps some regular expression validations in the model, that would be the only time a model would require the field to be there. I hadn’t done any of these.

Frustrated, I added a simple string to the fixtures and the test code for this field, and the tests passed. Not content in just making something work, I needed to know what was up. So I started digging around, and found something that now seems obvious, but I totally ignored before.

Whenever you submit a form for a model in Rails to insert a new record in an ActiveRecord model, all the fields you have set in the view are passed in the POST request. However, if you didn’t enter anything in a field, the parameters for that field would simply be sent blank. In this case, validates_length_of doesn’t bitch about the missing field, because it’s there. As long as the number of characters – in this case, zero – isn’t more than what I specified in the model, it’s all good. However, the tests were failing because since I hadn’t specified that new field in the fixtures, the parameters were sending that field as nil, which caused the previously mentioned validation to scream out.

So just as a quick review:

• validates_length_of – Verifies if the field is within the amount of characters specified in the validation code. If no minimum is set, it won’t mind blank fields, but it will mind nil fields.
• validates_presence_of – Verifies if the field is nil or blank.

Like I said, it’s obvious now, but not so much when I was getting alerts that the build failed for some silly reason.

Today I noticed that whenever using some of the Prototype Helpers in Rails (such as link_to_remote or remote_function), it was setting by default the evalScripts parameter to true. For those who don’t know, Prototype uses evalScripts to evaluate anything in <script> tags from the response text. This was giving me major headaches in a piece of code today.

Looking at the previously-linked API page for the Prototype Helpers, there was no mention on how to set this parameter to false. I thought that simply passing :evalScripts => false as an option to the helper would do the trick, but it didn’t. So I had to dig into Rails source code to see if there was any way to set this to false.

When reading the prototype_helper.rb file, which houses the helpers that generate the HTML / JavaScript code, I noticed that there’s an option named :script that allows the developer to set the value of the evalScripts parameters in the generated JavaScript code.

In short, passing :script => false as an option to your Prototype Helper code on the view will correctly set the evalScripts parameter to false.

Hope this helps someone!