That Puerto Rican Rubyist

It’s been a few months since my last post around these parts. I’ve mostly been keeping busy with fitting into the whole West Coast lifestyle and, of course, busy at the job. Although I do miss New York City from time to time, particularly while watching older episodes of How I Met Your Mother, I’ve really enjoyed my time in the Bay Area. People here are interesting, and tech is such a huge part of the culture. It’s been a fun ride.

This post, however, is not about the adventures of a Puerto Rican being thousands of miles from home (although it could certainly make for an interesting story for another day). This post is about me pulling the trigger on something I’ve wanted to do for a long time – switch my VPS (which is where this very blog is running) from Slicehost to Linode.

To begin, I wanted to state that Slicehost is very, very awesome. I’ve been a customer of theirs for more than two years, and never had any major issues with them. With the exception of some outages, their service ran smoothly for the most part. This is more than anyone can ask for. So, if Slicehost is so awesome, why didn’t I marry them? I was perfectly content in staying with them.

However, as I was experimenting more and more with Ruby, Rails, Python and other languages / frameworks, my VPS – which was the smallest slice available at 256 MB – was obviously starting to suffer under the memory constraints. Since these were mostly experiments, I didn’t want to splurge and pay almost double for a 512 MB slice. That’s when Linode announced that they would be increasing the RAM sizes of all their slices. So it was either to stay with Slicehost and have my VPS struggle to keep up with my experiments (or pay more per month), or switch VPS providers. After reading all around the Internet about how good Linode was, I decided to go for it.

I opened an account with Linode and instantly had my sparkling new VPS running. I transferred all my files from the old Slicehost VPS and just had to point my domain names to the new Linode VPS. My main concern initially was that Slicehost had really spoiled me with their control panel, especially for DNS management. It was what had initially drawn me into their service to begin with, so leaving that behind was a bit scary. Thankfully, Linode has their own control panel that’s equally great to use. I was able to configure and point my domain names to the Linode VPS, and had everything working quickly.

As far as performance, I had been reading for years how Linode has faster I/O performance than Slicehost. Turns out that those tests seem to be true – The VPS as a whole feels much snappier, from logging in via SSH to serving up this very blog.

One of the major issues people had against Linode in the past was that they lacked any integrated backup system, a la Slicehost. They actually introduced backups a few months ago. This wasn’t a major concern for me (I’m using Tarsnap, which deserves a blog post of its own), but for those who need this sort of service, know that they have you covered.

Like I mentioned, Slicehost is great, and I wouldn’t encourage people to not use their services. I just had different needs that Linode seems to be handling as well as I expected. It’s only been a couple of days, but I think I’ll be shutting down my Slicehost VPS for good.

Well, after writing in my last post a month ago that I was officially unemployed, I was blessed with acquiring a new full-time job just four days later. Best of all, it’s where I always wanted to be, the Bay Area!

Tomorrow will officially be my first day as a Rails developer for RepairPal. I was in their offices last week to meet them personally, and everyone seemed very friendly and the company seems to be doing some cool stuff, so I hope I’ll be a part of all the awesome stuff that’s to come. It’s really a dream come true for me to be where I’m at right now, at this very moment. It’s proof that if you really want something bad enough, and you work hard for it, whatever you want will come true.

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?

It’s been quite a while since I last updated this blog. I should seriously start writing more often. So, what have I been up to? With the cold weather here in New York City, it gets difficult sometimes to go out and have fun in the city. As usual, most of my time is spent on technology, software development, stuff like that. Here’s a brief recap of what I’ve been working on:

Got a new MacBook Pro, and I love it – I finally gave in and bought myself a shiny new MacBook Pro. I’m having a blast with it. For the open-source developer in me, this has everything I could ever want. It’s a beautiful and sleek machine that has gotten me highly motivated to start expanding my knowledge in different directions. While I still consider these laptops to be pricey, they’re really great.

Learning Objective-C for Mac and iPhone development – Since I got a nice Mac, I figured I should start learning Objective-C, then eventually get into Cocoa and the iPhone SDK. I’ve always been impressed by some nicely-done open-source Mac applications, and iPhone apps have always seemed to be so creative, so I wanted to learn how to build some myself. Since I’ve been working for so many years on dynamically typed languages (like PHP and Ruby), it’s kind of a total change of pace to go back to a somewhat-statically typed language like Objective-C. It’s been a bit of a challenge, since I last used a C-based language back in my college days. But it’s going along well so far.

I’ve compiled quite a few resources for learning all of these things. I recently purchased a book called Programming In Objective-C, which seems like the de-facto book on Objective-C, as it’s pretty extensive..And there are a few good screencasts – PeepCode developed a screencast dubbed Objective-C for Rubyists, and The Pragmatic Programmers have a screencast series by Bill Dudney called Coding in Objective-C. Of course, Apple has done a fine job with their Objective-C documentation. All of these resources should get you coding in Objective-C in no time.

The iPhone development part is mostly being learned because at my day job we would like to create a nice iPhone app for users of our site. I truly think that a mobile interface will expand our user base easily, even if people say they don’t really use mobile interfaces for a lot of things. I find myself using Facebook and Amazon’s iPhone apps more than I visit their sites.

BarterQuest is getting better and better – It’s been a wild ride on BarterQuest since we launched. We’ve been featured all over the place, from blogs to television shows, and we’re getting more and more users visiting, registering and trading on our site every single day. I’ve even traded twice already, and everything has gone as smoothly as it possibly could. It’s a great way to get the stuff you want by getting rid of the stuff you don’t want.

If you haven’t checked out our site yet, or haven’t done so in a while, I highly recommend you visit us soon. We’re going to be adding support for Real Estate in a few weeks, so our range of tradable items will greatly expand. And stay up to date with all that we’re doing by following us on Twitter.

Learning (and liking) CouchDB – My curiosity with CouchDB started when people were mentioning it quite a bit, and some Rails libraries like CouchRest were gaining some attention. So I checked it out for the first time, and I had no freakin’ clue why someone would use document-oriented databases, when relational databases did just fine.

Then a week I was working on a side project, and when trying to design my classes, I noticed that I would either have to denormalize my database tables, or be strict with normalization, but have a rather messy database schema. Then it just hit me – I finally knew the reason why CouchDB would rock in this scenario, where the data I was storing wouldn’t always follow the same structure. So I got into it, and I’m really liking it a whole lot. It’s something different, yet really useful in some situations. Seeing that there’s a market for databases like these, like Amazon SimpleDB, it seems like CouchDB (and document-oriented databases in general) will gain much popularity in the foreseeable future.

These are just a few things I’m playing along with. It seems like there are a lot of fun times ahead in software development and computing in general. I’m just happy to be able to ride the wave.

Note: Unfortunately, due to some lack of time, plus a large amount of spam comments being targeted at that site, I decided to take it down. Hopefully in the near future I’ll be able to continue this small side-project.

I recently deployed a small Rails app I built in a weekend, called RubyEveryday. In it, I’m posting one article a day about any Ruby-related news, whether it be current news or some code snippets of work I’ve done. My goal is to have it updated every single day, so it should be relatively fresh. Go check it out now, and follow the site’s updates on Twitter. Oh, and don’t forget to follow me on Twitter, too.

Don’t worry, I’m not shutting this blog yet. This will continue to be my main writing source for whatever is on my mind in the techology world, so keep an eye out for new stuff coming your way soon.

A couple of weeks ago, I wrote a short post about the first Envycast released by the guys over at Rails Envy. I really enjoyed their first foray in the world of screencasting, so I was looking forward to see what else they would offer us in the future.

With the imminent release of Rails 2.2 (Release Candidate 1 was announced last week), it makes complete sense that the new Envycast would focus on Rails 2.2. In the Ruby on Rails 2.2 Screencast, Gregg Pollack and Jason Seifer talk about all the goodies that have been included in Rails for our use. Even if you’re currently subscribed to Ryan Daigle’s blog and follow the Rails commit history, it’s still nice to have everything in one easily accessible place. While an Envycast in itself should be awesome, they decided to also have a PDF available, detailing all of these changes.

Screencast

Clocking in at 44 minutes, this screencast takes you through the changes in Rails, divided by component (ActiveRecord, ActiveSupport, ActionPack, ActionController, Railties) and specific topics (Internationalization and Performance). Like the first Envycast, all the action (well, as much ‘action’ as you can get in a Rails screencast) is done in front of a green screen, with either Gregg or Jason explaining what’s on the screen. As I mentioned previously, this gives the screencast a nice, personal feel, making the learning (and retaining the information) experience enjoyable and much easier – at least to me – than other screencasts. The infused humor also helps a lot with the learning process, making you feel comfortable and in a relaxed setting, which is key for learning new stuff.

Considering all the changes that have occurred in the six months between Rails 2.1 and Rails 2.2, this screencast does a good job in explaining all the new stuff. Although it doesn’t go too much into detail with some new features (thankfully so – I prefer short and simple, just like my Ruby and my Rails), my major gripe with this screencast is the lack of more detailed explanation on one major feature I (and I’m sure hordes of other Rails developers) was looking forward to: Internationalization. While I do understand this would need sufficient time to explain this new feature properly, I thought this was too big of a feature to just briefly touch on. They do encourage viewers who want to learn more to download and play with the Internationalization Demo App that was created just for this purpose.

Besides that, Gregg and Jason do an awesome job with this screencast. They explain these new features really well, make good use of the green screen (well, besides dodging pigeons and running away from Godzilla – trust me, you’ll see when you get this screencast) There were many “Whoa, I’m so going to use that in my next project!” moments for me, which for some reason didn’t happen when I read about these changes in Ryan Daigle’s blog.

After my short review of the first Envycast and liking it a lot, I was anxious to see if the Rails Envy crew would continue along these lines. I’m glad to see that they still produced a great screencast that’s easy to learn from and fun to watch.

PDF

Like I mentioned, they not only released a screencast on Rails 2.2, they also released a PDF to complement the screencast. The Ruby on Rails 2.2 PDF was written by Carlos Brando, a Portuguese Rails Core contributor who also wrote a similar (and excellent) e-book on Rails 2.1.

While the screencast goes over the new features in Rails 2.2 briefly, the PDF goes more into detail, with explanations and code examples throughout the book. There’s even an entire chapter on Internationalization, compensating for the lack of explanation in the screencast. At 118 pages (of which 86 are in-depth explanations of the Rails 2.2 features, 9 pages detailing the bug fixes in this release and 14 pages of the entire changelogs by component), it gives you all the new details in Rails 2.2, perhaps much more than what you need.

While the content is rock-solid, the formatting of the guide wasn’t too much to my liking. The PDF is in landscape orientation, which usually isn’t a big deal for me. However, the author didn’t seem to take advantage of this fact, as I think it could’ve been printed in portrait orientation without much formatting changes. Also, the PDF is just straight text (well, not counting the cover page, for those who like to nit-pick). There are no diagrams or anything similar – just explanations and code samples. Some diagrams or other illustrations wouldn’t have hurt to be included.

As a matter of example, if you see any of the Peepcode PDF’s (like the one on Unobtrusive Prototype.js), you’ll see they took advantage of the page sizes, filling it up without making the pages feel too loaded. These make reading less boring, while still keeping the core information there. It’s a nice combination.

Aside from some very minor gripes, these are quality products that will further your knowledge of everything Rails. I definitely recommend them to any Rails developer who is interested in keeping up to date with the rapidly-changing Rails world. Kudos to the Rails Envy crew for putting up another great product. I’ll be looking forward with what they come up next.

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!

On a recent Rails project, I was asked to verify if the visiting user’s browser has cookies enabled, and display a message on top of the screen if they don’t. While I don’t want to get into the reasoning why, or get into a flame war whether the site should still be accessible regardless if the user’s browser has cookies, I still needed to implement it.

Since it’s a Rails project, I thought of checking if the session cookie that Rails sets in the Application controller was set. But Rails sets the session after the view is rendered the first time (I have a more detailed explanation somewhere but don’t have it with me, so maybe next time). This means the first time the user visits the site, it will incorrectly display the warning message. Subsequent views will test correctly, but this obviously won’t work.

So I decided to implement a redirect, thanks to ideas given by this blog post. It worked, but it left me with a parameter in my URL the first time the user visited the site. It didn’t seem clean, and the higher-ups didn’t like it either, so off it went.

Then I was given the idea to check it via JavaScript, and with some slight tinkering I think I got what I wanted:

Basically this uses JavaScript to set the cookie when the page is rendering and immediately checks for its availability using a regular expression. If it’s found, then the user has cookies enabled and we can safely delete the test cookie (provided the user has their system clock set after January 1, 2001). If the cookie isn’t set, that means the user doesn’t have cookies enabled in their browser, so we display the ‘cookies_disabled’ element with our message inside.

This function is called in our application layout, between the <head> tags, meaning it’s called for every single page that renders the default layout. I haven’t observed any type of performance issue this might have, but I might have missed something along the way. And there’s probably a better, more efficient way to handle this as well, so if you have any suggestions, feel free to dtop a comment and let me know.

Last night I was in the mood to just review some of the stuff I already work with on a daily basis. I’ve been reading up on a lot of new stuff that I’m dying to play with, so a quick review of familiar concepts would be a welcome change of pace. Plus, it always seems I’m learning new stuff whenever I go back to an old concept. So I was searching around to see what I could get. I’ve already exhausted most of my Ruby and Rails books, gotten most of what interests me on PeepCode, and seen virtually every single episode of Railscasts, so I wanted to see something different.

That’s when I remembered that the guys from Rails Envy started producing their own screencasts, originally dubbed Envy Casts. As you can see with what I wrote above, and what I’ve written previously, I absolutely love screencasts. And since I’m an avid listener of the Rails Envy Podcast, I thought I would give these guys a try.

So after viewing the screencast on my way to work today, I have to say that Gregg Pollack and Jason Seifer have a good thing in their hands. Their screencasts are totally different from everyone else’s, which is immediately apparent. Instead of just a voiceover of how something is done, they actually have the guys (mostly Gregg) in front of a green screen. While it would virtually be the same if they went the regular screencast route, this adds some sort of personal touch.

Of course, the guys inject their humor as usual (with Jason usually appearing on screen for comedic purposes and nothing else). It even has quick educational breaks, with Gregg posing as a doctor to give us lessons on how our brains work. It has absolutely nothing to do with Ruby, Rails, Active Record, or anything related to software development, but as I mentioned, it provides quick breaks between topics.

So far, they only have one screencast covering Active Record. But I’m definitely looking forward to subsequent screencasts, as long as they’re as good as this first one. Perhaps we have the new hotness of the screencast world in our grasp.