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.

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?

MongoShort is a very simple URL shortening service, written with Sinatra and MongoDB. I originally wrote this little app to be used as part of a larger Rails application. However, it was mostly done as a way to do something with MongoDB. Particularly, I wanted to start using the awesome MongoMapper library. It’s really a breeze to use all these tools together, and it makes developing small apps on Ruby really fun. I hope someone can grab a copy of MongoShort and learn a bit of the basics of these wonderful tools.

Go fork MongoShort on GitHub now!

One of the things I love the most about Redis is it’s speed. Believe me, this little database is fast. Redis includes a benchmark tool, so I ran the default benchmark (Approximately 10,000 total requests per command, from 50 simultaneous clients) just to demonstrate its raw speed. These tests were run on a Mac Mini (1.83 GHz Intel Core 2 Duo, 2 GB RAM) under Ubuntu 9.10 Server:


dennmart@ubuntu:~$ redis-benchmark
====== SET ======
10005 requests completed in 0.14 seconds
50 parallel clients
3 bytes payload
keep alive: 1

34.89% <= 0 milliseconds
99.19% <= 1 milliseconds
100.00% <= 2 milliseconds
74111.11 requests per second

====== GET ======
10003 requests completed in 0.13 seconds
50 parallel clients
3 bytes payload
keep alive: 1

34.62% <= 0 milliseconds
99.79% <= 1 milliseconds
99.83% <= 2 milliseconds
99.87% <= 3 milliseconds
99.91% <= 4 milliseconds
99.94% <= 5 milliseconds
99.97% <= 6 milliseconds
99.99% <= 7 milliseconds
100.00% <= 8 milliseconds
74649.25 requests per second

====== INCR ======
10005 requests completed in 0.15 seconds
50 parallel clients
3 bytes payload
keep alive: 1

25.60% <= 0 milliseconds
99.73% <= 1 milliseconds
99.80% <= 2 milliseconds
99.83% <= 3 milliseconds
99.86% <= 4 milliseconds
99.89% <= 5 milliseconds
99.92% <= 6 milliseconds
99.95% <= 7 milliseconds
99.97% <= 8 milliseconds
100.00% <= 9 milliseconds
65392.16 requests per second

====== LPUSH ======
10001 requests completed in 0.13 seconds
50 parallel clients
3 bytes payload
keep alive: 1

37.62% <= 0 milliseconds
99.78% <= 1 milliseconds
99.82% <= 2 milliseconds
99.86% <= 3 milliseconds
99.89% <= 4 milliseconds
99.93% <= 5 milliseconds
99.96% <= 6 milliseconds
99.99% <= 7 milliseconds
100.00% <= 8 milliseconds
77527.13 requests per second

====== LPOP ======
10000 requests completed in 0.14 seconds
50 parallel clients
3 bytes payload
keep alive: 1

34.13% <= 0 milliseconds
99.69% <= 1 milliseconds
99.82% <= 2 milliseconds
99.86% <= 3 milliseconds
99.90% <= 4 milliseconds
99.93% <= 5 milliseconds
99.96% <= 6 milliseconds
99.98% <= 7 milliseconds
100.00% <= 8 milliseconds
74074.07 requests per second

====== PING ======
10000 requests completed in 0.12 seconds
50 parallel clients
3 bytes payload
keep alive: 1

43.79% <= 0 milliseconds
99.80% <= 1 milliseconds
99.85% <= 2 milliseconds
99.89% <= 3 milliseconds
99.91% <= 4 milliseconds
99.93% <= 5 milliseconds
99.97% <= 6 milliseconds
100.00% <= 7 milliseconds
86206.90 requests per second


Yeah, you read that right. On this somewhat low-end computer (by today's standards), Redis still manages to do over 74,000 SET (write) and GET (read) operations per second. Push and pop list operations also do well over 70,000 requests. On bigger hardware, expect these numbers to be much higher. Besides speed, I've also been impressed by the stability of Redis. I've been running Redis non-stop on the Mac Mini for over two weeks, and I've never had a single issue with it.

I got really interested in Redis after Defunkt (of GitHub fame) open-sourced Hurl. Hurl was an entry in this year's Rails Rumble competition. I used it quite extensively when developing with PayPal's APIs. After it was released, I noticed that Hurl used Redis for persistence. I was kind of puzzled why a key-store value was used for this. However, Defunkt wrote an excellent post mostly explaining the SORT operation, but also included some additional details on how Redis was used in Hurl. It made the decision to use Redis clear. Well, I'm also willing to bet that he used Redis because us programmers love to use the new hotness.

I feel that Redis will be something big soon. There are a few open-source projects using it, including the aforementioned Hurl and Resque. I already have a few ideas where I can use some of this functionality for current sites that I'm working on (such as simple counters, or a tag-like system where we can push and pop tags from a list). Check Redis out if you need some quick and simple storage.

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.

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.

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.

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.

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.

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.