Ruby tips from me, your idol
Posted by benjohnson in General, UncategorizedApr 19th, 2009 | 22 responsesI feel like I’ve been in the ruby community for a while now and I’ve learned a lot along the way. Taking a step back and looking at what I did right and wrong was interesting. Most of the “wrong” I had to learn the hard way, and it would have been nice to have someone tell me: “Ben, you’re dumb, stop doing that, and go put on your helmet”. So I decided to go ahead and throw together a few tips and share them on my blog. Whether you agree or disagree, hopefully this saves you some time, or at least gets you thinking about some things. Afterall, I am your idol, so you are probably going to agree with me.
1. Find that perfect balance between being OCD and using your time wisely
You can ask anyone I’ve worked with. I am the king of being OCD with my code. I want everything to be perfect and I don’t care how hard it is or how much time it takes. This is by far my biggest weakness and has caused me to waste a lot of time. So I decided to come up with a question I ask myself: Will this change benefit me immeadiately? When I am being OCD the answer is “no”, when I am being productive the answer is “yes”.
Perfect example: neco.com was my first rails project. As a result it used a lot of the old rails practices. It wasn’t RESTful, etc. I really like REST so I decided to go ahead and convert the entire application. I figured if I really grinded it out this would take me a few days. Wrong, it took me about a week and a half, and I was working at least 12 hours a day. Has this benefited me at all? Nope. In fact, our API has some unique requirements and we built an entirely separate application for this. Bottom line, a week and a half wasted. Legacy code is not bad code unless it is restricting you or wasting a lot of your time. neco.com was just fine the way it was. Make the change when you need it, don’t make the change because you are being OCD.
2. Don’t go against the grain in Rails or invent your own standards
I can not tell you how much time I’ve wasted trying to add in some cool feature into rails. I would dig into the rails internals, override methods, do all kinds of tricky stuff. I thought I was awesome. A month later rails comes out with some cool new feature, I update rails and everything explodes. Yes, maybe this cool new feature of yours would make your code cleaner, leaner, and possibly easier to understand, but it’s not worth it. You also lose the advantage of having other programmers easily understand your work, because you are not following standards.
Figure out a way to solve your problem unobtrusively or using the tools rails provides. In the long run, your app will feel much cleaner, it will be easier to understand by other programmers, and you can update rails easily. If you find your self messing around with private methods in rails, 99% of the time that should be a red flag to stop what you are doing.
3. Keep your documentation with your code
This one is more for library design. It’s very tempting to use a wiki, post documentation on your blog, etc., because it seems more user friendly for both parties. Believe it or not, a lot of people find rdoc confusing, and the old rdoc template (before darkfish) was not fun to use. In my opinion this has changed. Thanks to sites like Github, people can now easily fork your project and fix a documentation flaw, which kind of renders a wiki useless for documentation, and rdoc has been updated with a new template format (darkfish) that makes reading documentation MUCH easier. I actually prefer hanna. It’s a very nice theme, I used it for the authlogic documentation.
That being said, you are human, and if the documentation is not with your code you are going to forget to update it from time to time. I made this mistake with my own blog and a lot of my tutorials quickly became out of date. Because of this I’m sure I wasted a lot of people’s time trying to figure out what they were doing wrong. When the documentation is next to the code its hard not to update it when you make changes. If you don’t know how to use rdoc take 5 minutes to learn it. It is better for everyone involved. There is no denying that documentation is a pain in the ass, so the best thing you can do is make it as easy as possible on yourself. If someone doesn’t want to read through your documentation because they don’t understand rdoc, oh well. They are programmers and should take the time to learn something that important in ruby.
4. Think about what you are reading
Just because someone throws something up on their blog doesn’t mean they are right, my blog included. There are a million ways to solve problems in programming. Many times I have been caught by this. I will read something on a blog from someone that is a very good programmer and just go do it. Later it blows up on me because it actually was not a good tip. Had I of thought about what was going on from a big picture perspective, I could have saved myself a lot of time. Instead I put so much trust into this guy that no matter what he says he must be right.
If you start doing this, you will instantly become a better programmer. Think about what you are doing, try to understand it, come up with a better solution, etc. This just adds more tools to your nerdy tool belt, which ultimately makes you a better programmer.
5. Get involved
Unless you are going to work for Initech where there are a 1000 programmers, no one cares about your resume, what college you went to, your GPA, etc. In my experience, this industry focuses on small elite teams. Part of what’s great about ruby is the ability to get more done quicker with less resources. This is the trend. That being said, employers are more interested in what you can do vs your qualifications. Even in today’s crappy economy there are still companies looking for ruby programmers. I recently just got done hiring for my own company. Guess what I looked for more than anything else? Open source involvement and a blog. To me this shows confidence in what you are doing and that you want to show off your abilities. I can openly see how good of a programmer you are, etc. When I got resumes I did not look at what college they went to, what companies they’ve worked for, I looked for their own website, a github account, etc.
All that you need to do to set yourself apart from the competition is put up a blog and have some open source involvement. My only regret is that I wish I would have done it sooner. If you haven’t done anything, at least start with a blog. If you have an interesting post, put the link on rubyflow. That’s it, you are on the radar. Which leads me to my next point…
6. Avoid mephisto
If you’ve seen my blog before you will notice that it has changed. I recently switched from mephisto to wordpress. I’m not going to ramble about this because there is no point. I am just sharing my experience and trying to save people some time and headaches. Maybe I have a little chip on my shoulder because mephisto has wasted a lot of my time, but that’s the point of this post. I believe new people have taken over the project so it will be interested to see where it goes. The older versions of mephisto were very bad to say the least. I had to set up a number of blogs using them, including my own site. I can not tell you how much of a pain in the ass they are. If you want to customize them, feature wise, you are SOL. Don’t bother modifying the source because you will not know what the hell is going on. It literally blew my mind that I was looking at a rails app developed by someone on the rails core. So far I have been very impressed with wordpress. Styling it and extending it has been very easy, and there has been a plugin for just about anything I need to do. Also, it takes up a fraction of the resources on my server.
7. Stay in the loop, RSS is your friend
You should be using RSS, if you are not, you are going to fall behind very quick. Subscribe to important blogs, read the new posts that come in, or at least quickly scan them. Ruby and rails is a very fast paced industry. I feel bad for the people writing books for rails because they quickly become outdated, some become outdated before they even have a chance to get published. That being said, you should spend at least 10 minutes every morning reading through RSS posts. That 10 minutes could introduce you to a new feature that could save you hours. If you don’t know where to start, start by subscriing to Rails Envy. They basically gather all of the important things that happen on a weekly basis and fill you in. If you commute to work, download their podcast and listen to it on the way to work. If you are trying to become a better ruby programmer, there is no reason why you should not do this.
8. Have balance in your life
Take some time for yourself to get outside and away from computers. I find that I am much more productive when I have a good balance in my life. I enjoy work more, my work is better, I am more creative, etc. I’ve been on both sides of the fence and I would venture to say that I probably would have been more productive during those 80 hour work weeks if I had taken some time away from the computer. If programming is your livelihood you should give this some serious thought. The last thing you want to do is establish a career in something that you no longer enjoy because you burned yourself out.
22 Responses to “Ruby tips from me, your idol”
About Me
There is too much kerning between the “e” and the “i” in #1. I measured it with a laser-calibrated jig I just fabricated.
Ben, have you already made the correction that Jay suggested? My kerningKalibrator shows everything to be pixel-perfect now.
Going outside for some Number 8 soon.
None of these are actual Ruby tips. ;-)
Yes, I took Jay’s issue very serious and went to a lab in NY where they have the world most accurate calibrator and corrected the issue.
Mike, how so? I guess they arent *directly* related, but in a way they are. They are tips that I think would make you a better ruby programmer as a whole. A career in programming isn’t just about typing on a keyboard.
Great article, each of the tips are very important (especially the last, more than you would think)! I have three more in this article.
[...] past the hiring manager is a completely different story. Here’s a pretty shocking story of Ben Johnson’s hiring technique from his blog. Unless you are going to work for Initech where there are a 1000 programmers, no one cares about [...]
Damn you number 1!!! Hit the nail on the head buddy. Keep doin what you do.
Wish #5 were true in Switzerland. Truth is, most employees over here have not yet understood this. I’ve worked on projects with devs and even so called tech consultants who had diplomas from well known universities, yet they had never heard of regular expressions or would rather shoot themselves in the head than working on a Bash prompt.
There needs to be something between (low-level) rdoc and (high-level) “the wiki”. Most projects I’ve been on, the non-devs would be totally turned off by rdoc, but they still need some way of grasping high-level concepts. Kinda like README, but with some structure. Any ideas?
Kudos on the great thoughts. Especially the last tip. I find this to be an absolute in life, step back and clear your mind. Andy Hunt suggests this in his ‘Pragmatic Thinking & Learning: Rafactor Your Wetware’ book. Unfortunately many companies do not find value in this. 9 hours straight in a cube != 9 hours of productivity
Since I helped port Mephisto to Rails 2.2, I thought I’d chime in with some advice. There are some good Rails-related lessons to be learned from Mephisto.
1) Mephisto is really two applications: The front end, and the administrative UI. The administrative UI is a fairly normal Rails application, but the front end is really not a Rails application at all. I mean, it uses Rails, but it generally does everything in a non-standard way. It uses Liquid templates, wildcard routes, and one or two monster controllers that basically route requests into an underlying library.
This makes it really hard to customize the Mephisto front end, because the learning curve is steep. Given modern tools, it would have be better to write the front-end as Sinatra application, and share only the model classes with the front end.
2) Mephisto relies heavily on Rails plugins, many of which are currently unmaintained. This means that Mephisto breaks, hard, on each new release of Rails. If you want your Rails application to keep working from one release to the next, you should generally rely on as few plugins as possible, and make sure those few are well-maintained.
3) Mephisto’s administrative UI uses lots of JavaScript, but it doesn’t have any unit tests. So every time we upgrade to a new version of Rails or Prototype, the UI gets a bit wonky.
If you’re going to use lots of custom JavaScript, you need to test it. And this probably means using Cucumber integration tests to drive a real browser, because Webrat’s fake browser isn’t realistic enough.
4) Mephisto has a custom caching scheme for multisite setups, and this requires custom webserver configuration. If you were going to do something like this today, it would probably be better to use Rack::Cache.
So what’s the future for Mephisto? I don’t know. Several people are submitting bug fixes, and adding new features. But nobody’s currently trying to dig in and overhaul the core code.
I’ve been experimenting with a git-based storage engine for blog posts. I’m not sure if my experiments will work out, but I’m convinced that we need to break blogging software down into smaller pieces, and separate out the data model, the front-end server (or static rendering tool), and the back-end UI.
Hi Eric, thanks for taking the time to reply. I agree with everything you said. I just feel like mephisto took whats so great about ruby and rails and took a big shit on it. They took what should be a relatively simple application and made it complicated.
I think the liquid templates were completely unnecessary. Rails allows you to add views into plugins, and before rails had this functionality engines did. Mephisto uses engines. The template editor for word press is retarded, all that it does is open up a PHP file for editing. If you are going to do this why not just open up the real file in a text editor? There is no reason to have this in a blog. Anyways, where mephisto failed miserably was allowing people to extend it and write plugins for it. To me this is what makes word press so great. The worst part is that mephisto had it all along had they of not done all of this crazy magic and completely broke the rails standards.
I could go on forever, the bottom line is that its way more complicated than it needs to be and breaks too many standards. A lot of the functionality built into mephisto should be in “plugins”.
Mephisto may be bad, but what about Typo ?
http://wiki.github.com/fdv/typo/
I have nothing against wordpress, I use dotclear myself :-)
By the way your new theme is really classy, nice work !
Hey Ben, great list — I can’t say I disagree with a single thing in here. Also, thanks for the podcast plug!
I totally agree on the Mephisto thing. It was the first open source rails project that I dived into when I was learning Rails and it damn near scared the pants off me! Here I was doing the DHH 15 minute blog screencast one minute, thinking I had this rails shit down, then I checked out Mephisto and started dribbling!!!
After I eventually removed my “rails training wheels” and decided to start blogging I was very reluctant to use Mephisto as I would have found it embarrassing to be blogging about rails on a rails platform that I couldn’t even maintain. I’m not saying it’s bad code, it’s just not typical rails code.
I ended up going for Enki (http://www.enkiblog.com) as that is super simple and you can hack away on it to implement your own features. I find that much more rewarding, if you’ve got the time to invest.
Yeah, what happened to Typo? There was a lull in Typo development a long time ago, everyone jumped on the Mephisto bandwagon, and Typo never really recovered in mindshare. Typo is being actively developed now. Is it time to take another look at Typo?
@Anton: Enki looks interesting! I may try it.
A lot of you guys clearly know how to code, so how come you all use someone elses code for your blogs?
The blogging app, is the ‘hello world’ of rails, surely you’ve all built your own at some point?
Great article though, but b0ll0cks to wordpress, Type AND mephisto…..
Write your own blogging engine, and use rails plugins to enhance it.
The latest version of Typo rocks. Never like Mephisto at all.
I like reading your blog a lot. However, english is not my native language and I hope you can explain what the abbrevations SOL and OCD mean. Don’t forget your foreign readers :P
@ysf, I apologize, I guess those are typical american acronyms. SOL = shit outta luck, OCD = obsessive compulsive disorder. Ever see the TV show monk? I’m not really OCD, but one might think I am when I nitpick at my code trying to make it perfect and waste hours doing so.
You have some good points, but having a blog as a criteria for hiring? That’s just dumb. Not everyone has the need to show off what they know. Does Jeremy Kemper have a blog? I don’t think so.
Jim, thanks for your comments. This post wasn’t really for someone like Jeremy Kemper. For hiring purposes, he doesn’t need a blog because he already has a reputation. For those that don’t have a reputation, a blog is a good way to get on the map. That’s all.