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?

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.

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.

This is obviously not my first time that I have shilled the PeepCode website. I truly think that for any Rails developer, this is one of the most invaluable tools for learning available anywhere. I’ve purchased many of their screencasts already, and once I get the opportunity, I’ll even spring for their PeepCode Unlimited subscription. I know I will fully get my money’s worth.

If you haven’t been following what they have been doing recently, they have also added PDF books to the mix. These books provide a lot of wealth, just like their screencasts, but only in text form, perfect for printing or, for the environmentally-conscious of you, just keeping in your flash drive and reading it whenever you need it. I just recently purchased two of their PDF books: Git Internals and ActiveMerchant.

I purchased the Git Internals book to satisfy my own curiosity. As many of you should know by now, Git is a distributed version control system (a la Subversion) that’s taking the software development world by storm. I’m slowly getting into Git, thanks to a PeepCode screencast on the basics of Git, and even decided to pay for an account on GitHub (which I will write about in the near future). But I’m usually not content to just know how to get my work done. I like exploring beyond that, knowing how it actually works in the inside. Most of the times, I fully understand its strengths (and weaknesses – nothing is perfect!), making me more efficient. This PDF book does exactly that. If you’re a curious being, and are using (or planning to use) Git, I wholly recommend this book.

The ActiveMerchant book, I actually bought out of necessity. The web application I’m working on has the ActiveMerchant Plugin installed, and some work with that plugin done. However, since the developers who implemented those features aren’t working for the company anymore, and some core functionality has changed since I’ve arrived, it needs to be changed. I didn’t want to start from scratch, so I bought this PDF book to see what should be the “right way” (as per the author, who undoubtedly has tons more experience with the plugin as I have). I really got into this book, because it’s really, really easy to understand (thanks to the plugin actually being easy to implement) and it explains everything you need to know about the entire payment process. This is a must-read for anyone who’s building Rails applications where money needs to get to you.

The guys over at PeepCode are doing an excellent job, so why don’t you head over to their site and check them out? If you’re a web developer, particularly using Ruby and Rails, you’ll definitely find something interesting, or even necessary.

If there’s one positive thing I can take out of having to ride the subway to work for one hour each way every single day, it’s that I’ve been able to catch up on a lot of reading. I love to read a whole lot, particularly about technology. So lately I’ve been able to finish a couple of books I had around, plus I’ve been able to afford more books to read, so I’ve been buying more. While I haven’t read a library’s worth of books, I think I’ve read more than the average software developer has read. I would go into a long discussion about that fact, but maybe another day.

With a myriad of books out there, it’s difficult to know which ones to read. I first got inspired by Jeff Atwood’s Recommended Reading For Developers list. Since then I’ve purchased and read many of the books Jeff recommends, which are still pretty relevant and really good reads.

So I decided to dedicate some time to write some mini-reviews about the books I’ve read, in case someone wants an honest opinion on them from my perspective. I’ve already written about a couple of books before (like the upcoming Advanced Rails Recipes book, and my not-so-popular opinion about The Pickaxe Book), so I hope to expand on that.

Also, I added a nifty text widget on my sidebar which I will update constantly on which books I’m currently reading and into, with a link to Amazon (no referral link!) for more information. I hope you all find it interesting to see where I’m focusing now.

Any suggestions on recommended reading for a software developer like me? While I like programming-specific books, I would really like to get into more books that focus not on one single piece of technology, but as a whole. Any recommendations will definitely be appreciated.

Well, well, even a week after Zed Shaw’s infamous rant on the Ruby and Rails communities, all the talk generated by it continues. While it has died down enough, I feel that the repercussions of the rant are still going on. And I’ll be writing about one I’ve been disturbingly seen more and more in the past week.

One of Zed’s problems with Dave Thomas was due to his book, Programming Ruby (or “Pickaxe” – weird how some people know that book only by the Pickaxe name). Here’s one of the paragraphs he wrote about that particular book:

That’s right, take a look at the original topics and you’ll see that Dave’s book is nothing but a giant me-too book that seems to appeal to the average OOP coder of 2001. However, the average OOP coder using Java, C++, or C# wasn’t doing much meta-programming then, and what Dave presented was nothing more than a book that said, “Hey look, you can do all the stuff you’re doing now, and make NO money at it.”

He goes on to explain a lot of the shortcomings of the book, like the fact that the chapter about classes was demonstrated by designing some sort of Karaoke jukebox machine. I do agree with these specific points Zed makes. I remember reading the book for the first time, and just skimming the classes chapter because it felt awkward that these very important terms were being explained this way. It was also confusing as well. I just read the basics (how to create classes, inheritance, access control, etc.) and skipped most of it. Also, failing to include one of Ruby’s strong suits (which is the ease of meta-programming in this particular programming language) seems very weird.

However, this isn’t what I wanted to talk about. My issue is that after Zed pointed these things out in his rant, I’ve been seeing a lot of negative comments towards this book – something I hadn’t encountered before. In fact, I bought this book because everywhere I read on the Internet, it specified that this was the book to own on Ruby. In fact, let me show you a screenshot of the current reviews this book has on Amazon.com:

See anything interesting there? Yeah, there are only 52 reviews, but 43 of those reviewers – a whopping 82.6% – gave this book either four or five stars. To me, for a supposedly “shitty” book (as I’ve read a lot of people call this book in the past week), this is a rather high positive rating.

So, are these people honestly criticizing the book by their own will, or simply just want to “follow the leader” and bash Dave’s book without thinking for themselves? I find it extremely odd that a lot of criticism is aimed towards this book in such a short period of time – the past week since Zed’s rant. Were people scared or something of giving their honest take on this book for fear that the Ruby zealots would find out where he/she lived and crucify them or something? Something just doesn’t seem right.

Now, while I’ve expressed before how much I enjoy the work of Dave Thomas and others who publish the Pragmatic Programmers books, do know that I’m not biased in any way, shape or form. I’m probably one of the most objective guys you’ll ever meet. If I think something sucks, I’ll gladly say so, as long as I can back my words up. But honestly, I don’t think the Pickaxe book sucks. Far from it. This book has helped many (myself included) find out about the awesome features of Ruby (well, most of them, at least). To ignore the fact that this book helped jump-start Ruby usage in the in the Western Hemisphere is really a disservice to it.

I think Programming Ruby is an awesome book and an excellent reference to the Ruby language. As a book to learn the language, I wouldn’t count on it to be the “be all to end all” Ruby book. To those who think there are programming books like this, you’re totally wrong. In my short programming career, I’ve come to know that one book for a specific language or technology isn’t enough. Obviously, that doesn’t mean you should buy all the books on a particular topic. But more than one, at most two or three books, should help you greatly. No two authors think alike, and there’s always some stuff missing from one book that another has, and vice versa.

So to all those newly-minted Pickaxe “haters”, I suggest you take an honest look at yourself and think if you’re really hating this book because you didn’t like it. If you didn’t like it from the get-go, good for you. I hope you find another book that helps you learn Ruby. But leave the rest of us who learned a great deal from this book alone. We don’t need a Zed-wannabe running around this joint.

UPDATE: After I posted this, I immediately E-Mailed David Heinemeier Hansson (yes, the creator of Rails), because I was curious on how he learned the Ruby language. I was surprised he responded in mere minutes, and his response was even more surprising:

I learned Ruby in large parts from the original Pickaxe and thought it was a great book. No, it didn't cover everything. And I picked up some metaprogramming tricks form The Ruby Way, especially Chapter 5, as well. But I was very happy to have it at the time.

Seems like David agrees with my thoughts on this subject. I bet that most of the big names in the Ruby world also learned the language from Dave’s book. I thank David for that quick and honest response.

Like I mentioned a while back in this blog, I really like the books released by The Pragmatic Programmers. They’re pretty easy to read and teach a lot in the process. Although Programming Ruby (known to many on as the ‘Pickaxe’ book) is getting some flak after Zed Shaw’s take on it (which I agree on, although I’ll give my own take on it in the near future), you can’t deny their books are among the best in their specific topics.

I’m a big fan of the Rails Recipes book (and no, it’s not because they actually put a pilón, a typical Puerto Rican food prep utensil, on the cover). When you learn a specific technology, be it a programming language, database engine, framework, or anything else, you’ll want to find some real-world usage to apply what you’ve learned. Books like Rails Recipes give you an entire list of specific things you probably thought of doing for your own application, but didn’t know how to exactly do it. It’s a great tool when you’re developing your own stuff.

Of course, thanks to the speed of Rails, that book is a bit outdated. So I was really psyched that a new version, named Advanced Rails Recipes, was going to be released in March 2008. So psyched, that I actually went over to their site and purchased the beta PDF (and, of course, I’ll be getting the paper book wne it’s released). I couldn’t wait to read it and apply some recipes to my current projects.

First, I would like to discuss the current system that’s used for beta PDF’s in the Pragmatic Programmers site. The site is relatively easy to use, and really well done. Once I created an account and purchased the PDF and paper book, I received an E-Mail stating that my PDF was ready to be downloaded. That was it. Withing a few minutes, I already had my PDF, with “This book was prepared exclusively for Dennis Martinez” in the cover – neato! A couple of days passed by, and I received an E-Mail stating that the beta PDF was updated. All I needed to do was to go into my account on their site, and a link immediately appeared in the main page, which took me directly where to regenerate the PDF (which apparently is run by gerbils – no joke!). A few minutes passed, and the gerbils sent an E-Mail with a link to my updated PDF. Okay, so they might not really be gerbils who work on the PDF’s, but I really like it when companies go with these informal jokes while still be very helpful. Kudos to these guys for making a very user-friendly site.

This book is filled with recipes from various Rails users all around the globe who have contributed their work to this book. One thing that took me by surprise is the fact that I expected this book to be pretty much incomplete, with tons of errors all around, but it really wasn’t like that at all. I found one or two spelling errors, and the recipes I tried worked straight out of the box. That’s a great thing, because this is why I went ahead and purchased the book three months in advance. I wanted to read up on the techniques used by people with much more real-world Rails experience than I.

In particular, I wanted to read up on the chapter about Capistrano and deployments. This, to me, is one of the most touchy issues in Rails nowadays. It’s something that everyone seems to do differently with mixed results. The recipes included here aren’t de-facto deployment strategies, but nice techniques, such as how to generate config files on the fly when deploying to a remote server, how to safeguard your database passwords so that they’re not in your source code repository, and many other techniques.

Sure, most of these recipes are readily available on the Internet, if you search hard enough. But when you’re developing a major web application, the last thing you want to do is to fire up Google and spend the next 15+ minutes searching and trying out pieces of code to see if they work for you. This book avoids all that. Not only does it show you how to do things, it also explains why and when you should use them.

Major kudos to the author, Mike Clark, for making such an awesome book. Even though it’s still in beta, I really recommend this book to anyone who wants to expand their Rails knowledge with bits and pieces of information from major Rails players. Once the ‘full release’ of the book is out in March, I’ll make sure to do a more informative review. For now, don’t be afraid to get this book because it’s tagged as ‘Beta’. That’s far from the truth, it seems.