The Puerto Rican Rails Dude

For some reason, I wasn’t too much into podcasts until recently, when long trips in the subway made me find something constructive to do while traveling to work. So I’ve been downloading a ton of podcasts that have been out there for a while now. My favorite has to be Ask A Ninja - it’s just hilarious. But as far as tech podcasts go, the Ruby On Rails Podcast is one I’ve been going way back to download and listen as many as I can.

One particular podcast (or rather, two podcasts which were from the same interview, just split in two) that caught my attention was a roundtable discussion about women in development (Part 1 / Part 2).

I found this discussion interesting, as I have to admit I haven’t encountered that many female developers myself. During my university days, I probably saw less than 10 different females taking Computer Science courses during my nearly five years there. Half of those were in the introductory programming courses, from which they rapidly switched their major when they realized they didn’t like it. The other half stuck around, but most of them didn’t seem to enjoy it much. It could probably be due to the fact that they were female.

No, I’m not saying that because they’re women, they immediately shun all types of advanced technology or science courses. I say this because in one course, I was paired with a female student for a class project. At the end of the project, while at the library finishing up on some details, she said she was surprised during this project with me, When I asked why, she said that in every Computer Science class, in every single project she’s been teamed up with boys, the guys either dumbed down what was given to her to work on, or she would be constantly be getting hit on. This was the first time someone from the opposite sex seemingly treated her as an equal, which I did.

This is a sad truth in those academic fields where men outnumber women greatly. They’re either perceived to be dumb, or simply viewed as a potential mate. And I honestly never viewed one of these girls who took classes with me like this. Okay, maybe once I took a liking to one girl, but I still would’ve liked her no matter which major she was, so I feel like I’m clear of all charges against me. I’m not sure if this has to do with the extremely-low number of Computer Science students who are female, but I’m suspecting this has something to do with it.

Trying to put myself in their shoes, I’m sure it’s difficult to deal with these things when all you want to do is just learn and be a software developer like any other. Still, I find it somewhat odd that the women need to start off groups like DevChix and PHPWomen. It’s cool to see enough females get together and form these groups and get recognized for it. But I think these groups just label them as a different breed of developer, instead of just trying to get themselves being viewed as equals. Or maybe these groups are really necessary to combat all the obstacles I mentioned that women in this field encounter. It doesn’t seem like there’s an easy way for this behavior to end.

In any case, I’m all for the females getting their voices heard, showing the world what I have known all along: women are awesome developers. Their genetics don’t have a damn thing to do with their abilities, so stop viewing them as “that programmer chick”.

I just read a post by Joan Planas Illas titled “Be proficient in one programming language“. In this post, Joan gives some advice that developers should stick to one programming language, get really good at it, and make a career out of it. He does offer some good points, such as software development not being just about learning programming languages, and how employers actually prefer if a prospective employee is well-versed in the programming language they’re looking for.

But for me, those who follow the advice of just mastering one programming language are usually day-coders: those who only think about software development from 9 to 5, nothing else. Don’t get me wrong, I’m sure there are a lot of day-coders who are awesome at what they do. But usually these people don’t have much passion for what they do. They’re happy being in their own groove, not expanding their knowledge, and just do their job because it pays well and nothing more. These are probably the worst types of software developers any company can hire. No passion almost always leads to a sloppy job.

But the best software developers I’ve seen show an insatiable amount of curiosity to learn every single thing out there. Of course, it’s not possible. While I don’t have any sort of scientific proof to back me up on this claim, I’m fairly sure there’s a direct correlation between how effective a programmer is with what they’ve learned. A person who reads and stays up to date with different programming languages will have a broader vision on how to get things done. A person who only knows one thing will most likely know only how to solve problems the way their language does. Sadly, a lot of programming languages have their own conventions on doing things their way, which sometimes isn’t the right way to do. These bad habits are then embedded to the developers, who are unfortunately ignorant to recognize there are better ways of solving a problem.

I have yet to meet or read about a kick-ass or famous software developer (well, at least famous in my mind and geeks around the world) who is an expert with just one programming language. Martin Fowler didn’t just stick with C. Yukihiro Matsumoto didn’t stay with C++. Zed Shaw definitely didn’t ‘get married’ with Ruby. These are just a few examples. But just think of any well-known software developer, and one common trait they’ll have is that they at least have experimented with many programming languages, and I’m sure that helped them be as knowledgeable as they have been.

So if you have the time, get to know a programming language of your choosing, preferably one that interests you and not one that all the ‘cool kids’ are using so you need to learn it too. Once you get a firm grasp of that language - not master the language, there’s a huge difference - take the time to learn a new one. For example, if you know Ruby pretty well, get into Python. They both are similar, yet have different ways of doing things. Just don’t choose Ruby and stick with that for the rest of your life. You’ll earn no real benefit at all, and when the next big thing comes along, you’ll be get left behind. Unless you’re happy with that, day-coder.

Here in New York, I’m working at a start-up company that is a few months away from their initial launch. This is a refreshing change of pace from where I used to work. In my previous job, I was the sole programmer, but not for a company whose main purpose was build software. Now, I’m part of a group of people, where we’re all working together to complete a software project. It’s an interesting experience for now, and I know it’s going to be an awesome experience for me.

As many of you should know, working at a start-up that hasn’t launched yet is hard. Really hard. Trying to build something that hasn’t been done yet will definitely have its setbacks, and there’s a high risk involved in the whole deal. Just a look at TechCrunch’s so-called DeadPool, start-up companies who had to shut down for one reason or another - usually because they didn’t have enough money to finish. Also, since these companies aren’t actually generating any revenue while building their product, most of the times there’s not a whole lot of people working at any given time. That means a ton of work for those involved.

Of course, I’m not saying start-up life is bad. On the contrary, it’s been fun and exciting for me. I’m doing what I want to do for a company that has a great idea that, if all goes smoothly with no major bumps on the road, will enjoy massive amounts of success. And being one of the main persons to actually have constructed part of that success, it means there will definitely be rewards down the road. With this being said, lately I noticed a couple of articles with some people saying some… Well, I’m tempted to say ’stupid things’, but I’m not one to pass judgement, especially to those I don’t know personally.

The first one comes from Mike Mason, a software consultant, who advises start-ups to fire their original development team when the company has a successful launch. Of course, now that I’m part of a dev team who’s with a start-up that hasn’t launched yet, I definitely wouldn’t want to be fired. But this article offers absolutely no valid points whatsoever as to why firing the original people who helped get the company to the “Promised Land” is a good idea. His main gripe is apparently this:

The problem I’ve found when working at startups-turned-enterprises is that the guys who built v1 of that web site are now running the IT department.

Yeah, this is a problem, definitely. But guess what? Who put the developers in charge of running IT? It’s not the developers themselves - it’s management. Why on Earth would a manager put a software developer in an IT role - a main position, at that - if they’re not actually qualified to do the job? In this case, the developer who built the first version of the site should stick around, possibly as the lead developer for newer hires, while they’re making their product better. For IT, hire someone who’s actually qualified for what you want. That way, you have someone who know about your codebase actually working with code, while someone who knows about IT tasks can focus on that. Like the ol’ lightning rod him, Zed Shaw, said in his blog about this post:

If you want to fire someone, it’s management. Fire the assholes who focused on making everyone cram for some shitty demo to moron VCs instead of focusing on the quality of the mother fucking code in the first place.

You just gotta love Zed, even if you don’t agree with him most of the times. If you read Mason’s blog post, he also has some more ‘advice’, like “Hire an expensive consulting company to help you build your systems better, and allow Chief Architect dude to ignore their recommendations” and “The minute you’re successful, plan to rewrite your software from scratch“. I admit I haven’t had years of experience in the software development world, but honestly, it seems like this is just a plain bad idea mentioned by Mike here, and just reeks of being counter-productive to the entire company.

Another article I read that left me wondering what the hell the author of the article was thinking was written by Jason Calacanis, CEO of Mahalo, some human-powered search engine, who wrote some tips on how to save some cash when running a start-up. Most of the ideas sound really good, and I agree with most of them. But there was one item that caused a lot of debate around some other sites. Here’s the original quote, as apparently the author noticed he put his foot in his mouth and edited it to sound “less harsh”:

Fire people who are not workaholics…. come on folks, this is startup life, it’s not a game. go work at the post office or stabucks if you want balance in your life. For realz

Whoa, so if I work for you, you’re going to fire me if I don’t work 12 hours a day, at least six days a week? For realz? Sorry, but I definitely wouldn’t want to EVER work for you, even if you pay me ten times as much as I’m earning now. This idea of being a workaholic is just plain idiotic. Overworking leads to so many problems, it’s not even worth it to mention all of them. Stress, bad productivity, bad decision-making, all of these are caused by people working more than they should.

It’s sad to see that in this day and age, there are still people who view borderline slavery (i.e. making them work way too much) as the only way to be successful. People like these shouldn’t be running companies at all. It’s not about how much you work, it’s how smart you work. David Heinemeier Hansson over at 37Signals’ Signal Vs. Noise blog gives his take on this, and brings up some great points to do, what he says, “Fire the people who are workaholics!”

Of course, after a backlash around the Internet, especially in TechCrunch’s aptly-titled post Calacanis Fires People Who Have A Life, Calacanis back-peddled and wrote a follow-up post where he said didn’t actually mean it that way, and that he meant that the TechCrunch headline should be “Calacanis fires folks who don’t love their work”. This, I can agree with a bit more, but still, the post was just plain back-peddling, even if he doesn’t want to admit it.

Calacanis goes on to ask two questions: “Can you have a life and work at a startup?” and “How do you manage stress?” The first one is easy: Yes, I can. I’m currently working in a start-up, and still have more than enough time to explore New York City, keep in touch with my friends and family, work on personal projects, and even write long, interesting blog posts. The second question, about managing stress, it’s also easy: Don’t be a workaholic. If you work all the time, if work is your life, of course you’re going be stressed. Take some time away from work. Go do whatever relaxes you (please don’t say work relaxes you, you liar). Take one day off, it won’t be the end of the world or your start-up. Come back feeling refreshed and hopefully stress-free.

Working and/or managing a start-up is definitely no easy task. But don’t think that working all the time or firing your original people because they’ll run the rest of the operation to the ground will help. Work smart, keep your good people around and treat them well, and you’ll see that your start-up will be successful. As long as your idea is good and you have the funding, of course!

Just wanted to write a quick post this morning about something amusing I found. I was checking out my site’s stats through Google Analytics (which is a great free service, by the way - I just wish they would make it a real-time stats tool, even if I have to pay for that service), and found this in my ‘Keywords’ Traffic Sources:

Of course, I don’t have any porn on this site (sorry, please be redirected to one of the trillion other sites out there that do have some), but I simply have a post titled “All the porn you want! (Not really)“, which was a post about my experience with the Akismet Plugin for this blog.

Lesson learned here: If you only care about numbers and want to boost traffic to your legitimate website (without caring that you’ll only attract horny people who will immediately click the Back button once they realize you have no porn), just add the word “Porn” in your blog post. That being said, I’ll refrain from using the word in this blog. Who knows what those people are looking for?

When I was in Puerto Rico, I started this blog because I thought that virtually all programmers out there had their own blog somewhere in cyberspace (or whatever people call the Internet nowadays). Since I was searching for a job, I thought this would help me get at least on par with others in the job-seeking market. Even though I already have a job, I decided to keep this blog active as a hobby, since I do like writing about anything that interests me.

Currently, the company I work for is looking for more Ruby On Rails developers to help with the development and maintenance of ths site we’re making (note: if you live in New York and are looking for a job using Rails, contact me and I’ll let my employers know about you). It hasn’t been easy, since it seems that seasoned Rails developers - although I don’t consider myself a ’seasoned vet’ - are scarce, probably because they already have jobs elsewhere. But that’s another topic I’ll write about soon.

In my case, my boss asked me to check some sample code from someone out. After checking the code, I was curious to see who the person was, so I searched on the Internet (which I truly implore all employers to do when scouting prospective talent) to see what kind of profile this person had. There were some posts of him asking some questions about Ruby and Rails, a mostly empty profile at Working With Rails, but nothing else. No web site, no blog, nothing. I found it weird that a person with years of professional programming experience has nothing that they regularly maintain.

Sneaky spy that I am, I also checked some previous employees at this company, and to my surprise, none of them had blogs or anything else that they keep up-to-date. It’s really surprising that in this day and age, when blogs, websites and domain names are so cheap (or even free) to acquire and maintain, that they don’t spend a couple of minutes to set something up.

Of course, I’m not saying that you need to set up a blog or website if you’re a programmer. It’s definitely not a requisite. But in an era where your electronic identity is more important than ever, it’s a great thing to have for many reasons. Like I did, you could be job-hunting, or looking for work on the side. Having a place where people can freely go and checking out your work (or your personality - something that’s overlooked a lot) is a bonus. It’s like a pre-screening, but you’ll have the advantage over others who don’t have sites set up. Provided that your site is decent, of course. If I were an employer looking for a web developer, and found that their website was full or animated GIFs, MIDIs and scrolling marquees, I would most likely pass.

I think the primary reason for people not doing this is probably their perceived amount of time they think they need to spend maintaining a blog or website. To be honest, it takes virtually no time at all. My usual blog posts take around 15-20 minutes to write up, since they’re just thoughts that come to my mind during the day, and I take the time to write them up later on. I don’t need to sit down, write a first draft, think how I’m going to write my blog, etc. I just sit down and do it. I also don’t feel the need to update the blog every single day. It’s not about quantity, but about quality. If you can write a kick-ass blog post every two or three weeks, I appreciate it more than reading a deluge of uninteresting blog posts every day.

If you’re a developer who wants to make a name for yourself, either for professional or personal reasons, I really suggest at least creating a blog (it’s not like you have to pay - Blogger and WordPress are two good starting places) and trying to write something from time to time. Not only will prospective employers thank you for it, I believe it’ll also let you grow as a professional.

It’s been more than a month since I’ve written anything here, but it’s with good reason. This past January 28, I started working in New York City - with Ruby on Rails, nonetheless! I’m really, really excited for this new opportunity, since I spent at more than half of 2007 trying my luck to land something outside of Puerto Rico. While I am a bit sad having to leave all my family and friends behind, they understand how much I wanted this and fully support me. I’m just happy I’ll be able to showcase my skills here in the United States, where undoubtedly I’ll have much more opportunities to do everything I wanted to do.

I wanted to write this post, in case someone lives outside the U.S. and is looking for a job here for whatever reason - like looking for more money, looking to work with some specific technology, etc. Trying to land a job outside of your native country is really difficult, as I personally found out these past months. Here are a few pointers that you can use as a guideline if you’re in the same boat as I was.

Have a strong desire to move and be away from family and friends

This doesn’t have anything to do with programming or anything related. But this is a major hurdle you’ll need to clear before even thinking about anything else. I know a lot of people in Puerto Rico who wish they could go to the U.S., yet when I ask them why they haven’t planned it, they say they can’t (or don’t want) to leave their families behind, or maybe they don’t have the cash to plan something, or some other issue. While I understand them, though I can’t relate to them (I’m single, never been married, no kids), I truly think that if they really want something, they can achieve it, no matter what. There should be no types of excuses at all if they want to move. When there’s a will, there’s a way.

Also, make sure you let any prospective employers know about your desire to move, most likely on your expense. I have a feeling I was overlooked by some employers because I lived so far away. Also, it seemed like a lot of people thought Puerto Rico is a Third World Country on the other side of the globe, possibly millions of miles away from the U.S. I even had one prospective employer E-Mail me saying that they liked my resumé, yet before interviewing me, they wanted to know if I had a valid passport to enter the U.S., along with a work visa. For those who don’t know anything about Puerto Rico: we’re a U.S. Possession, meaning that we are American citizens. We don’t need passports to enter the country, nor work visas to be employed here. So make sure the people you’re sending your resume to know that.

Don’t have your sights set on one place only

When I first took my decision to move to the United States seriously (at New Year’s Eve last year), my heart was set on California, specifically San Francisco. I wanted to go there because it seems like all the tech companies are stationed there, or at least the ones using the “coolest” technology (well, at least cool to me). I did get a couple of phone interviews with some companies, but nothing ever came out of it. It’s when I started to send resumes all over the U.S. where I got even more responses, until I landed my current job in New York. It turned out to be even better, because after I got the job, my cousin called me to let me know there was a spare room in his house in the Bronx, which is where I’m at until I get my own place. I have absolutely no family in California, which meant that if I got a job there and my employers didn’t help with the relocation costs, I would be looking at getting a hefty loan just to fly out there and find a place to live. In short, look everywhere you can, everything will sort itself out in the long haul.

Make yourself known

In this world of Open Source, it’s relatively easy to join up on a project and help out. There are even some projects that are on the death bed, since the original author doesn’t have time to continue working on it. So this is a great way to achieve many things at once, like getting more practice in a particular technology, and helping out with the Open Source movement. This is an excellent way to have your code out in public, where prospective employers can check your skills out first hand.

Granted, I didn’t actually do this, as I didn’t have much time to hack away at some project at the time. But I did try to make myself known with other tactics. Blogging, for example, is ridiculously easy to do. You can write articles about what you know about programming, showcase your writing skills (which I think is very important, but more on that some other day) and even allow a glimpse of your personality, all in one swift move. I really recommend employers looking for new talent to check if they carry a blog, if you don’t do so already. Of course, this shouldn’t be the only thing to taken into consideration when hiring, but it can tell you a lot about a possible future employee before even talking to them personally.

Another thing I did was try to make my own web application. Unfortunately, I haven’t finished it yet. It’s more than half-way through. But I had to stop once I got my current job and had to prepare for the big move from the small island to the big city. But returning to the subject, creating an application using your desired programming language for, no matter if it’s freeware or some type of paid service, will definitely give you an edge over others who don’t take the time outside of their job to do such a thing.

Don’t think twice, and have fun!

As with every drastic change in your life, it’s perfectly normal to be freaked out at getting into brand-new things. But as I mentioned above, you need to have a strong desire to do this. I think it’s also normal to question yourself from time to time, but if it’s a constant preoccupation in your mind, then simply don’t try to get a job outside your country until you come to grips with it. I was nervous when I arrive to New York. I just kept thinking on the plane “How will my life be over there?”, “Will I like the city?” or even “Will I be happy at my job?” But in the three weeks I’ve been here, I’m happy to say that my life has been great so far, I love New York City and I couldn’t be happier working with a cool technology with some very nice people. It’s been a blast up until now, and I have absolutely no regrets at all.

So this definitely is not a complete list of things your should consider if you want to move to the United States. But these are things that I had to work with myself, and I hope someone could benefit at least a tiny bit by them. So best of luck to any and all of you who want to make the “big jump” like me!

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.

Over the past week and a half, I’ve been busting my ass trying to learn the ropes of Behavior-Driven Development with RSpec. I had been interested in learning either Test-Driven Development or Behavior-Driven Development for quite a while, so I just jumped on one of the two and test the waters out for a while.

I’ve been reading a lot on TDD and BDD for the past couple of months, yet never took the time to implement it to my current projects. The main reason is because I thought it would take me too much time to learn and would bog me down too much, when all I wanted was a workable application running as soon as possible. But, an opportunity presented itself (more on that in the future), so I chose the development technique that seemed better for me: BDD.

Reading about RSpec through other blogs on the Internet, it just seemed so intuitive to use that for testing, I kinda thought it was too good to be true. So after installing RSpec and getting it running on my application, I realized it was true after all. It’s ridiculously easy to write your own tests with RSpec, and it’s almost plain English (just like good ol’ Ruby). It includes built-in stubs and mocks to simulate parts of code, so you can even drop fixtures if you want (although admittedly, a lot of the shortcomings fixtures had were fixed with Rails 2.0). In fact, here’s a simple controller test:

describe ProductsController do

  before(:each) do
    @product = mock_model(Product, :to_param => "1")
    Product.stub!(:find).and_return(@product)
  end

  it "should call the action successfully" do
    get :show, :id => "1"
    response.should be_success
  end

  it "should find the product" do
    Product.should_receive(:find).with("1").and_return(@product)
    get :show, :id => "1"
  end

  it "should assign the found product for the view" do
    get :show, :id => "1"
    assigns[:product].should eql(@product)
  end

end

This test actually works for testing the show action in a controller. I wrote this just to show how readable the code is. I never knew testing would be so readable! And like I said, once you wrap your head around mocks and stubs, it’s ridiculously easy to implement. As a great bonus, RSpec can also integrate with rcov, a tool that actually checks what parts of your code are tested. It’s a great tool for making sure you achieve 100% coverage of your code.

Unfortunately, I didn’t actually do any BDD this time around, as I already had a good chunk of my application up and running already. But now that I have discovered the joys of RSpec, all my upcoming products will be fully done using BDD techniques: I won’t write a line of code until I write the behavioural test before.

A couple of ceveats, though. Hey, nothing’s perfect! First off, if you use different types of plugins for your application, you’ll find some parts of it difficult to test in RSpec. Most plugins use the Ruby’s own Test::Unit testing framework to test their own functionality, but parts in your code where you use these plugins can get you the first time around. Also, if you’re like me, and already have written code for your app, you’ll start finding different ways to fix your code to conform to RSpec testing. This isn’t necessarily a bad thing, as this is most likely a warning sign that you need to refactor that piece of your code anyway. But it’s takes a bit of your time away, so be prepared for this.

In short, RSpec is so easy to use, I don’t see why people shouldn’t use it in their own projects. I suggest every Rails developer should look into RSpec (or any other testing method, really) and stop being lazy. I know I was, but never more!

RSpec References

Ryan Bates from Railscasts has a great screencast that can serve as an intro to testing controllers. And the best part is that it’s free!

* Testing Controllers - http://railscasts.com/episodes/71

Geoffrey Grosenbach over at PeepCode has an excellent three-part series on RSpec, with about three hours of RSpec goodness! No, they’re not free, but the $9.00 per episode is truly worth it. This was my secret weapon in learning RSpec in less than two weeks - The best 27 bucks I’ve spent in my software development career!

* RSpec Basics - http://peepcode.com/products/rspec-basics
* RSpec Mocks and Models - http://peepcode.com/products/rspec-mocks-and-models
* RSpec Controllers and Tools - http://peepcode.com/products/rspec-controllers-and-tools

Before I begin, I just want to wish everyone a Happy New Year! May 2008 bring happiness, peace and prosperity to all.

I’ve been keeping myself very busy lately with RSpec and Behavior-Driven Development, basically learning the ropes and how all the pieces fit together. For now, I’m totally enjoying it. But more on that in a future post.

Now, I know that everyone who read Zed Shaw’s rant towards most of the Ruby and Rails communities will have an opinion on this. But I’ll give my own thoughts on it. All I hope is that someone doesn’t read this and think “Who the hell is this guy to give an opinion?” I might not be a ’somebody’ in the Ruby or Rails communities at the moment, but I would really like to be part of those communities sometimes in the near future.

Upon first glance, Zed’s rant seems like a completely immature piece, just looking to damage the reputations of certainl people and companies. But if you read closely, ignoring the unprofessional language scattered throughout the text, there’s a whole lot of valid thoughts and reasoning to this entire rant.

Most of his attacks are aimed at two people: Kevin Clark and Dave Thomas. Kevin Clark has been a pretty big part of the Rails community, regularly contributing code and such, and Dave Thomas of course is the author of possibly the most well-known Ruby and Rails books in the market. His story on Kevin is that they possibly never got along and clashed multiple times, while the story on Dave is that supposedly Zed had a fix for a pretty serious bug in Ruby, yet Dave and others ‘threatened’ Zed to not release it. For what reason, it’s not clear in the rant. Now, about these allegations, I don’t know whether they’re true or not (there’s always two sides to a story). But from my own views, I think any environment has these types of problems all the time. My own workplace can be used as personal experience on these manners. There’s always someone who wants to be smarter and better than you, and for some unknown reason they go out of their way to make sure they come out looking better than you can. It’s stupid, but it’s just human nature, I guess. I bet almost any other open-source community is the same.

He also goes on to write about Thoughtworks, a software consulting company that jumped on the Rails bandwagon a while back. Zed’s beef with them is the fact that they charge a shitload of cash while providing not-so-great work in return. Isn’t this is the case with almost all software consultancy places? I can name a few off the top of my head here in Puerto Rico. In fact, all you need to do is go to a website one of these ‘expert software consultants’ made, look at how the site is built, and anyone with an eye for software development standard practices can name a dozen things they would change immediately. This is no surprise here.

I do commend Zed for not making this a 100% negative jab towards Ruby and Rails. He included some people who he knows and have helped him out or were unlike those who he vilified before. Like I said, all communities have their share of bad apples, mostly people who want to be most widely known at your own expense. So the fact that he names some people who were cool to him shows that.

I’ve read a lot of other blogs where people are dismissing Zed for the way he expressed his views, that he burned his bridges and what not. But that’s what he apparently wanted. He said he’s not happy being part of the Rails community, so he wants out. This is his way of getting out. Now, I may not agree with the way he did this at all. You never know when you need to cross a bridge you burned in the past, after all. But being in the position he was, seeing and knowing a lot of things that went down, he has a valid opinion, and he’s simply entitled to it.

I think Zed partly wrote this rant not to bash everyone associated to Ruby or Rails, but to try and help out, in his own way. He knows a lot more about the community than most of us will probably ever know. So hopefully some good comes out of him exposing some dirty details on how the Ruby and Rails world is run. In the end, it simply boils down to this: It’s one man’s opinion. No matter how important he is (or rather, was) to the Rails world, one man isn’t enough to kill it, in my opinion.

Zed, if you miraculously read this, best of luck to you in the future, buddy. Hope the rant was worth it!