Now, I know that sounds like a lot of work, but honestly it’s really not. Github has made contributing to open source projects so trivial that everyone should be doing it. Take for example a recent ticket I got for one of my projects. The gist of ticket was that if there was a space in the project name the library would throw an error. That’s a great bug! It’s also an incredibly easy one to fix. If the person who opened the ticket has actually just submitted a pull request with the fix instead the fix would already have been deployed. Granted it would’ve taken a bit more than the few minutes to open the ticket, but not that much more. [UPDATE: He actually did fork the project and is trying to fix it! Awesome!]

So why should you do this? Why should you take the time to fix your own issues instead of having the library owner/maintainer do it? Well, the reasons are plentiful, but here are a few of my favorites:

• You can have it now! That’s right, if you fork the project and fix the bug or add that new feature you can start using today! Even before the project owner has a chance to merge in the pull request. That’s a total win right there!
• Quicker to be released to the general public. Maintainers of open source projects are busy people and, usually, don’t spend all day working on their open source libraries. If someone submits a good patch or feature then it’s easier for them to pull it in and get it out as a proper release sooner.
• It feels good! It feels really good to contribute back to a project that you use often. After awhile you might even get commit rights to the project and won’t have to maintain a fork. That feels really good!
• Build a name for yourself. That’s one of the ways you land better jobs or contracts. People start seeing your name floating around commit messages. You get to know the people maintaining the projects, they like your work, then when they’re looking to fill a position, guess who they think of?
• It makes you a better developer. By contributing to different projects you learn different techniques. You get to understand the code of the library you’re using and learn little tricks that you might not have known about otherwise.

Those are just a few of the reasons why giving back to the open source community is great. So the question I’m going to leave you with now is are you going to be a player or a hater? Someone who just complains all day, or someone who helps to make the world a better place? I’m hoping you become the latter.

What kind of advice was he asking for, well, he quite simply needed to know how could he become an ‘expert’ Ruby on Rails developer. First, let me say that this post won’t have anything to do with Ruby, Rails, or any other specific programming language. Everything I’ll talk about is valid in ANY language on ANY platform. With that disclaimer, let’s move on, shall we?

While at this company he got introduced to Ruby on Rails and really loved it, coming from a non-Rails background. Since being laid off he’s been trying to land another Rails gig, but everyone is looking for ‘expert’ Rails developers. So the question was, how to become an ‘expert’ developer?

I keep putting ‘expert’ in quotes because, let’s be honest here, that’s a VERY subjective term. As someone who has hired many developers in his day, I can tell you that I’v

e hired newbies to ‘experts’ and everywhere in between. Everyone has their merits and possibilities. I’ve met ‘experts’ that I wouldn’t hire to take out my trash, let alone build my business. I’ve also met people right out of college that I would hire again and again. So your mileage my vary.

So… how do you build up that ‘expert’ reputation? Let’s look at it. Below are some of things I’ve done, as well as some of the things that I look for as a hiring manager. Some are incredibly easy to do, others require work, but in the end they WILL pay off, and you’ll easily be at the head of the pack when going for that job.

Build Something

When you are looking for a job people want to see what it is you’ve actually built. If you haven’t built anything, then how are you an expert? Build a lot of different things and put them up on the web for perspective employers to find and play around with. Use these are a playground for trying out all those cool new technologies you keep hearing about. Want to give NoSQL a try? Great, build an app that uses it. Need to improve your testing chops? Write an application and write all the tests you can possibly think of!

Get a GitHub Account

I can’t tell you how important GitHub has become when trying to make a name for yourself. It seems like unless you’re on GitHub, you’re nobody. While that might not be true, it certainly hurts more than it helps to not have an account. You know those apps you’ve just been building and playing around with? Post them on GitHub! Then put your profile page link on your resume. Yep, you read that right. Give those looking at your resume a link to your code. Let them see how good a developer you actually are. Show them you know how to code all the things you’ve got on your resume. Listing a language, platform, or tool on resume is one thing, but actually showing your perspective employer is another! They’ll love it.

While you’re on GitHub, why not contribute to an open source project that’s up there. There are plenty of them, and they’re ALL looking for people to help out with their projects. Simply fork the projects, make some improvements, and then give those changes back to the projects owner. This looks great on a resume and really helps to show that you are interested and active in the community. Again, employers love this! Plus, you’ll be starting to build a name for yourself, and building a network, and a network is INCREDIBLY important when looking for work.

Blog and Write

I should probably heed my own advice here and blog more often, but do as I say, not as I do. With that said I wrote a book, which looks AMAZING on a resume, but might be a bit out of reach for most people, so I recommend blogging instead. Why should you blog? Well, it shows that you have good communications skills, again very important to most employers. It can also show that you have a deep understanding of whatever it is you blog about.

What should you write about? If you’re stuck on a topic, might I make a recommendation or two. First, when you’re building those applications I mentioned early if you run into a bug or something else that got you a bit stuck, blog about it! Others could really benefit from your experience. Explain the problem and how you went about solving it. Another great thing to write about is your favorite libraries or plugins. Pick a different one each week and dissect it. Write about how it works, what it does, etc… This is a great exercise in both writing and learning about how things work. Very valuable.

Network

I mentioned earlier that a good network is INCREDIBLY important when looking for work, and I wasn’t lying. It’s the most important thing. A good network will constantly be feeding you new opportunities, or putting you in touch with those who can. So how do you develop that network? A few ways, I mentioned contributing to open source earlier, that’s a great way. Another great way is through conferences, hackfests, rumbles, and whatever other local (and non-local) events are being held in your development community of choice. Attend these events, participate, introduce yourself, speak, buy drinks, whatever! Just get out there and NETWORK!!

Conclusion

The gentleman who emailed me said that he was reading a lot of books in hopes of becoming an ‘expert’. While I’m not going to tell you not to read books (you should!!), I will tell you that there is no substitute for doing. All of things I’ve talked about above are ALL about doing. Reading is not doing, it’s reading. It’s passive and will not get you further in your career. There’s no place on a resume for the books you’ve read. Take what you’ve read and put it into action, then you’ll be on your way to becoming an ‘expert’ developer.

Why do the open source projects always seem to get the ax? Well, let me start by saying that they don’t always get the ax, but they certainly jump to the top of the list. There are certain libraries I’ve written, cachetastic and configatron, are the two most prominent that I use day in and day out. They will always get the love the deserve. Then there are projects like APN on Rails. I wrote it because I had an iPhone app (no longer available) that I wanted notifications for, and there was nothing else available for Ruby to do the job. The plugin took off like crazy and I was overwhelmed with patches, questions, bugs, etc… That was great, and I was happy to help, for a time, but alas, I haven’t written an iPhone app for ages, and I just don’t have time to maintain a plugin that I wasn’t even using.

A while ago I realized that the best thing for APN on Rails, myself, and for the community was to find someone to take over the project so that it got the love it deserved. I put out the call and the good folks over at PRX (Public Radio Exchange) answered the call. The folks at PRX have written some great iPhone apps, including the very popular “This American Life” app.

So I’m happy to announce that the new official home for APN on Rails is now at: http://github.com/PRX/apn_on_rails. I ask that you continue to show the same support to PRX that you have shown to me over the life of this plugin.

Again, thank you to everyone, and thank you to Rebecca Nesson and the folks over at PRX for picking up the project and giving it renewed life.

While I don’t want to give too much away about the contents, everybody loves a good surprise, let me say that part one of the book will be the most comprehensive guide to DRb and Rinda that you’ll find anywhere. Including the source code!!

I’m working hard on part two of the book which focuses on third party tools, frameworks, and libraries. It’s quite a fun part of the book to write as there are a great deal of choices out there, including my own Distribunaut. (PS. I released a new version of it on GitHub a week or so ago.) Writing about different libraries is quite fun as I get to really delve into the source code and see the good and bad ways people like to write code. Plus some of the libraries have really great features, or really turn things on their head.

When the book is available as a “Rough Cut”, I’ll certainly keep you all informed. In the mean time keep watching this space and have a great weekend!

In the next version of Mack, which should be out in the next day or two, I’ve broken out support for ActiveRecord and DataMapper into their own gems, http://github.com/markbates/mack-orm/tree/master. That means you’ll be able to still use ActiveRecord, if you want. The default ORM, however, will be DataMapper. That’s what you’ll get out of the box with Mack.

Now, keeping with my original post, I’ll be actively maintaining the mack-data_mapper gem, and when I can I’ll make similar changes to the mack-active_record, but I’m not promising anything. Now the good thing here is that since the repos for these gems are on GitHub, anyone can contribute changes/additions to them. I’ve even put a stub in there for Sequel support, that’s definitely something someone else will have to support.

This also has a nice advantage in keeping the Mack core clean and simple. Hopefully this will all lead to faster development time turn around for Mack.

It’s also worth noting that when I talk about ‘native’ support, all I mean is some Rake tasks and some generators. There’s nothing stopping anyone from using ANY ORM with Mack. You could even create your own, if you really wanted to.

Here’s to hoping this makes everyone happy!

I took Sam up on his offer and I’ve already made several contributions. This is GREAT news for the Mack Framework. When the best technologies start working in concert, only good things can happen.

I’m really excited about what’s happening with DataMapper 0.9.0, and I know it’s only going to make Mack a better framework. I’ve already started working on upgrading Mack to use, the yet unreleased, DataMapper 0.9.0 code base.

I’ll keep you all posted.

http://github.com/markbates/mack

If you would like to pull it down you can clone it with:

git://github.com/markbates/mack.git

For those of you interested in contributing you can create an account with GitHub, fork the Mack project, go nuts with your changes, and then send me a pull request. It’s all very well explained on the GitHub site.

Enjoy!