The Puerto Rican Rails Dude

Yesterday morning, someone posted a comment on a post I wrote at the blog of the company I work for. This person, named ‘Tom’, said that our site was filled with lies, and that we had false advertising all over the place. Of course, I don’t get angry about negative feedback, and you shouldn’t either. I politely reply to the comment on the blog, letting this person know that we apologized for any misunderstanding, that what we claim on our site is true, and provided our support E-Mail address in case he has any questions or inquiries. We’re more than happy to listen to what people have to say. Well, Tom replies a while later saying that it’s “not my job to make sure your advertising is true.” Well, obviously he doesn’t want to open any sort of dialog with us.

I show this to my boss, and we started looking around. Obviously, we look into our site, using the IP address from where the blog comments originated from. We notice that there’s a user who registered to our site, named ‘Lucy’, registered with an E-Mail address different to the one used to leave the blog comment. It was a free Gmail address, and of course, the IP address could be the gateway address for a larger company. But we decide to continue looking on, with the E-Mail address of the registered user in hand.

Upon further sleuthing, we notice this person has left comments on blogs and newsgroups, under different names but mostly using one name, Mark, more than the others. He was also touting a particular site in all of his other posts. When searching for the name we found, it turns the perpetrator who left the negative comment on our site: the co-founder - and now VP of marketing - of a competing site. We decided to leave it there, since it’s obvious by his comments left on our blog that this person is trying to hurt us. Plus, it’s hilarious that our sleuthing was sort of akin to a South Park episode, where the boys discover some criminals by searching all major Web 2.0 sites.

I can’t help but laugh at this turn of events. I mean, here you have a co-founder of a competitor, and instead of focusing on how to actually make his product better than ours, he decides to take a stab at others who are competing with him, apparently in hopes of inflicting some damage. To make matters worse, he does it under different guises. To be honest, if this person came forward from the get-go and told us he was from that competing site, and that he thought our site was misleading in any way, I would’ve been happy to open the lines of communication towards him. I’m sure we both would’ve gotten something positive out of it.

I’m not saying that you should be totally oblivious to your competition. Like the saying goes: Keep your friends close, and your enemies closer. You need to know what others are doing, so you can get a leg up on them, do things they’re not doing and make yourself better. That’s the point of having and running a business. But to spend actual time making baseless comments to the competition leads nowhere. Even worse, it makes you seem afraid and desperate to even consider attempting such stunts. And we’re not even close to mentioning something called “professionalism”, which this person seems to be seriously lacking.

I can offer some bits of advice from all of this. Make sure you know who you’re competing against, but don’t spend your time on them. Spend your time where it matters the most: your product. If you’re sure of yourself and the work you’re doing, then you shouldn’t worry at all about someone else. And even if someone is doing better than you, instead of wasting time and energy worrying about someone else, take it and make yourself better. Like I’ve heard before, “A dog in desperation will leap over a wall.”

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!

I just stumbled upon a script that MySQL includes nowadays called mysql_secure_installation. It runs a series of steps to remove some of the default installation options that MySQL installs, like an anonymous user and a test database. When you run the script, it does for the following:

• Prompts you to change your MySQL root password, especially if you haven’t set a root password yet.
• Removes anonymous access to your database server.
• Restricts root access to localhost only.
• Drops the ‘test’ table that’s installed automatically.
• Flushes the privileges so that all changes are taken immediately without having to restart the database server.

Here’s the output when running the mysql_secure_installation in one of my servers.

In all, it’s something that I’ve been doing manually for a while. And I bet that there are many, many developers out there who, even on production servers, don’t even bother to remove these things. Obviously, this isn’t the “be-all and end-all” of MySQL security, but it’s a big step away from the default installation. Go run this script now! Well, unless you’re a security expert who already did this, either manually or with the script. If so, then I salute you.

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.

I was having a quick tech discussion the other day on a non-tech message board I visit on a daily basis. I had mentioned how frustrating it is to have to spend hours developing for good ol’ obsolete Internet Explorer 6.0, and why people are so damn lazy to upgrade. There are countless reasons why people don’t upgrade, which I won’t go into now to avoid a long, long rant on why I think these people should be stripped from their computing privileges. But I was talking about the recent developments in web browsers, in particular how Firefox 3.1 is going to be much faster, or how Internet Explorer 8.0 is promising to play better with web standards, I received this delightful comment from one of the few techies (and one of the few females) in that forum:

He can shove Firefox 3 where the sun doesn’t shine, and if he suggests Internet Explorer 8 in person I will be forced to cram his balls up over his head whilst they are still attached to him.

Just lovely. And I hadn’t even suggested that people upgrade!

The particular reasons she gave me as to why she made this statement are irrelevant to the discussion (“Firefox 3 doesn’t support all my add-ons yet and Internet Explorer lost me a long, long time ago.”), but something slightly ticked me off about this brash statement.

Every single person on this planet has an opinion to express, for whatever reason. People involved in computers aren’t excluded. I’d say we absolutely love expressing our opinions about a myriad of things, leading to sometimes heated (and entertaining) discussions: Windows vs. Linux vs. Mac, Ruby vs. Python, vi vs. emacs… No matter what you say, there will always be someone to express the opposite.

I learned a long time ago to avoid these discussions altogether. Why? It’s not because I’m a poor debater and fear I’m going to lose (which is most likely true). It’s because no one in this world will ever be pleased. That’s why there are choices in this world. To put it as simple as possible, someone wasn’t content with something, so they made another thing. And they’re happy with it.

So if I’m happy with Ruby and Rails, and you’re extremely happy with Python and Django, then I respect your opinion, sir. Just don’t come down on me and run down a zillion reasons why Ruby or Rails suck (which are probably variants of “Rails Can’t Scale“). Be happy with what you have, I’ll be happy with what I have, and we can co-exist nicely in this vast software development universe.

Yesterday afternoon, I had the urge to get a new Rails book, so I went to Amazon and ordered The Art Of Rails. This post isn’t about the book, but I’ll try to write about it after I read it.

This post instead is about the weird shipping service that Amazon provides on its site, at least in my particular case. When ordering something in Amazon, you get the option of how fast you want to get it. Among their options are: Standard Shipping (which is 3 days according to the site), 2-Day Shipping and Next-Day Shipping. I usually choose the standard shipping, since whatever I order isn’t a matter of life or death. I completed my order, expecting the book to arrive on Friday or Saturday, just in time for the weekend.

I just checked the tracking on the book - It’s already waiting for me at home, less than 24 hours after ordering it.

Of course, that’s not happening every single place in the country. It seems the reason I got it so quick is that Amazon has a distributor close to New York City (the tracking indicates it left Bethlehem, Pennsylvania, which is about 90 minutes away), so they received the order and shipped it out UPS Ground, which is just a short drive here. It isn’t the first time this has happened. I usually get books from Amazon one or two business days after I order them.

Obviously, I don’t mind the fast service. That’s why I continue to constantly buy from them rather than any of the other million bookstores I have access to. But take a look at the costs for the different shipping options for the same book:

• Standard Shipping - $3.99
• 2-Day Shipping - $11.98
• Next-Day Shipping - $17.98

So, I spent 14 dollars less than someone who chose Next-Day Shipping, yet got the book as quickly as they did. Pretty sweet deal, but I wonder how many people from this area (and perhaps other areas where shipping is just as quick) keep on choosing those ‘faster’ options unknowingly.

Like I said, this doesn’t apply to every single place in the country, so that’s why there are different options. Also, for someone who really needs an item the next day, selecting the Next-Day Shipping option can serve as a guarantee. But with the millions and millions of orders and a whole lot of stats to go along with those orders, couldn’t Amazon have estimated dates depending on where the items are shipping? This way, the consumer is better informed and can make a better decision. It just seems like the right thing to do.

Oh, and if someone from Amazon is reading this, please don’t purposely slow down my shipments next time.

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.

I’m pretty damn excited by the long-awaited public launch of Dropbox, an online file storage service. Well, it’s more than that. It’s a service that allows you to store, share and synchronize your files, either on the web, or as a ‘dropbox’ folder on your computer. They offer a nice chunk of space - 2 Gigabytes, which to me is more than enough for the things I would usually store in these services.

It might sound like just another online file storage site, but it really is not. It’s ridiculously easy to use. Once you install their client software and create an account with them, your computer will have a special folder, where you can just drop files in and they will automatically be synced on your account. No need to do any manual syncing or waiting for a timed sync to occur. It’ll happen totally transparent from your regular workflow. Provided you have a fast Internet connection, the synchronization process is virtually instantaneous. Then you can either grab the files from a web interface, or by installing and configuring the client in another computer. It’s that damn easy. Take a look at the tour they have on their site.

I must admit, I was a bit skeptical about this service after I read about it in TechCrunch earlier this year. I thought it wouldn’t be anything special compared to any other site that provides similar services. However, after reading more and more about it, the curiosity got the best of me. I scrounged for an invite and eventually got one. I signed up, but to be honest I never used it much. I only have access to Mac and Linux computers at the moment, and Dropbox was Windows and Mac only, so I was rather limited as to where I could use it.

However, the excitement arrived yesterday, when not only I read that Dropbox launched publicly, but they also released a Linux version of their client software! I immediately downloaded the client at work (laptop using Ubuntu 8.04), created my account. and it worked just as it did on the Mac. I started transferring files and got them when I arrived home. Everything went without a hitch. I’m now finding more and more uses for Dropbox, particularly work-related files that I can access at home.

Kudos to the entire Dropbox team for putting out some quality work.