Rails 3 App Deployment Observations
I already have two Rails 3 apps that are in production. While deploying these, I observed the following.
- Painfully obvious, you need to add a task to perform bundle install in your Capistrano script.
- When deploy hangs, it’s usually because Bundler is prompting for password.
- Haven’t found anything significant different from Rails 2.x.
- Ruby 1.9.2 really is much faster.
- While it solves a ton of problems, Bundler manages to piss me off on regular basis.
- Having multiple Ruby versions with Passenger is not a good idea. Besides, VPS’s are cheap these days.
I’m sure you guys are feeling the Capistrano screencast coming. However, the reason why I’m holding up the screencast is that PeepCode has that subject covered rather thoroughly. Check out Geoffrey’s good work, it’s only $9 and if you can’t invest that little in yourself, then I have nothing good to say.
Working From Home vs. Onsite
Since I use pomodoro, I decided to see how many pomodoros I can get done between working from home vs. in the office. For my experiment, I wanted to do it over a period of several days since in the course of human events… well, you get the idea.
I’ve heard some stories where people just couldn’t get anything done at home, especially with a wife and kids. Sure, they can be distracting, but I wouldn’t think about working at home unless I have a quiet office and sheltered from my personal life. I have my office in the basement where it’s quiet and somewhat sound-proofed from upstairs.
Well, to make the long story short, here’s the result. On average, I get little less than twice pomodoros done at home than in the office. You also have to be aware that I have two hour commute each way to NYC, so that’s 4 hours total that I can put to good use. Here are some of the factors I observed.
- At the office, I have very interesting conversations with others and get insights to other areas of development.
- I can bounce off ideas and get immediate feedbacks.
- When I’m home, I can get things done without much interruption and can take shorter breaks.
- I’m more comfortable at my home office. Usually puts me in good, productive mood.
- There are less meetings at home.
- The concentration level is extremely high at home.
- I miss people at home.
- People should turn on the video when using Skype.
I now firmly believe that companies should not choose just one over the other. Instead, there should be a balance between facetime and working remotely. Considering how expensive office spaces are, especially in NYC area, I think it’s silly to have a large offices for technology-related positions. We have Skype, IM, GoToMeeting/WebEx/Yugma, and VNC among other tools.
Pomodoro Technique
As long as I can remember, even when I was a kid, I always used 50/10 technique. If you don’t know what that is, it’s focusing intensely and working on a task for 50 minutes and take 10 minute break. I did this unintentionally and when found the “official” technique, it basically confirmed my belief that this is what made me very effective.
I then found another technique, Pomodoro. It’s basically the same as the technique I mentioned, but it’s broken down to 25 minutes and 5 minute break. I was shocked to find that it’s highly effective, and it’s even more enjoyable.
To learn about this, you can read the free book at http://www.pomodorotechnique.com . Listed in posts are the resources I found helpful.
Videos
The Pomodoro Technique: can you focus – really focus – for 25 minutes? – Staffan Nöteberg
Software
- On my Mac, I use Pomodoro Desktop and always have it on when my computer starts. It’s simple and free.
- On Linux, I just use timer applet and have three presets; pomodoro, short break, and long break. Because I use 64-bit version, I found too many issues with any AIR based apps.
What I Say During Ruby Code Review
“hmmm… that’s interesting” -> “ok, ok, ok…” -> “what the fuck?” -> “what the fuck?” -> “ugh, ugh, yuk” -> “ok” -> “cool!”
This pattern always repeats, and yes, even with my code!
Don’t Try To Be A Great Developer
Before becoming a great developer, we should all be decent human beings.
Don’t be a jerk
Whenever someone asks for help, never, ever, respond with “read the fucking code”, “read the documentation”, or “google it first”. Instead, say, “you can find it in xxx section of the code” or “the feature is documented in xxx”. I especially get pissed when a jerk says “google it first”. Why? Considering the fact that Rails change faster than any other framework I’ve seen, blog posts get dated and a half of them are just outright incorrect. I know this because I myself have very outdated posts that show up in searches.
What’s obvious to you might not be obvious to others
The way I define a “stupid question” is a question that is asked by someone that is so painfully obvious to me, I can’t understand why someone would even ask this question. The key here is that the nature of the question is based on your skill level and your understanding. Therefore, before you answer any stupid questions, put yourself in other’s shoes and try to understand where they’re coming from. Answer with a question to figure out why someone would ask that question and answer or point them to the right direction. And do it nicely!
Don’t assume anything
Please don’t assume that people know your shit because they know the framework or the language. We all speak the same language, but I sometimes can’t understand a word of what someone else is saying. What that means is that it’s all about the context, not the language. It’s not how, but why that creates confusion. If you do things one way, don’t assume everyone else does it the same way as you do. Arrogance is very subtle trait that is how to detect by yourself.
Trouble Recruiting Ruby/Rails Developers?
I’ve been at the both sides of the fence, so I can say that it’s not easy finding talents and even harder to find a good gig. Here are the factors I think is affecting this weirdness these days.
Economics 101
I have a degree in Economics and Finance, so naturally, I point the problem to disequilibrium in the market. If we were to achieve the perfect equilibrium, people hiring will have to pay more. However, there’s a nasty thought out there that Ruby and Rails developers are cheap. That’s not true. They are cheap because we can produce more bang for the buck. Until this misunderstanding is cleared, we’ll continue to have disequilibrium.
By the way, don’t compare us with developers working on other language/framework.
Working Conditions
As I mentioned in my “sweatshop” post, people hiring us demand that we work in shitty environment and work ourselves to death for their own benefits. Granted that Rails is used mostly by the startups, but provide your co-workers with the necessary tools and the environment.
The Treatment
Grow up! Don’t be an asshole!
DHH and others have criticized about being “professional”, but the fact of matter is, you have to treat people with kindness, understanding, and yes, professionalism. I’ve seen some behaviors that makes me want to puke.
People generally don’t want to be treated like a commodity. Treat them well and be amazed at what they give you in return. This is one lesson I learned throughout the years of managing that got me through incredible challenges.
Thoughts on Scaling (ToS) – Part I
I’m extremely proud to say that I, along with extremely talented people, built a system that runs on every continent except Antarctica. I know scaling is a subject that discussed when it comes to Ruby and Rails, but the fact is, it’s not just us, but it’s a beast to any other language/framework/system.
People mostly associate scaling with a system, but that’s not true. Scaling involves the people, including the end-user experience, policies and standard operating procedure in addition to code and system. If you think about it, it’s much like the security where all these things matter.
Take a look at the lessons learned from eBay. It will give you a brief insight to what they’ve done, especially at item #3.
I’ll be tackling some of the scaling issues as I create upcoming screencast series on deployment. Look for it at teachmetocode.com as well as here.
If You’re Using Windows…
Do you see ^M characters whenever you’re working on code written by others? Do you get weird gem errors? Do you hear another developer complaining about your code breaking?
Well, these are the painful truth you have to live with when you have to deal with people Ruby and Rails code using Windows. I learned it hard way because I ended up spending too much time getting things to work on Windows.
In this screencast, I show you how I develop Ruby/Rails apps using Windows. I did it as a joke, but it really is the only way to do it.
Considering the fact that both VMWare and VirtualBox are free, there’s no reason to struggle with a Windows machine. Just download the latest Ubuntu image and go at it. In fact, for a client with existing codebase that requires funky stuff, I spin up a new VM. It helps me isolate bad project and keep my machine clean.
So if you’re on Windows and have no choice, really consider using a virtual machine.
Database During Tests
Since every apps I’ve worked on that deals with a database is in Rails, I really didn’t have to think about transactional fixtures. I also use sqlite3 db in memory, so persistence was never an issue for me. Therefore, I admit that I completely forgot about the state of the test database since Rails’ default is to use transactional fixtures.
Here’s the deal, when you run tests outside of Rails, the fixtures are NOT transactional. Rspec will not clean up after itself by default. Take a look at below.
Before running this, I created a file named rtest.sqlite3 in the same directory.
Now, here’s the test I run:
This test passes without a hitch the first time, but when I run it again, it fails. Why? The record test added is still there. It does not roll back. In order to resolve this, you’ll have to make it transactional. To do this, I rewrite the test as follows. I’d like to thank Remi at remi.org for this.
In Rails, you can turn off transactional fixtures by setting config.use_transactional_fixtures to false, but I really don’t recommend that.
The Origin of RubyHead
I don’t know if I mentioned before, but the name “RubyHead” came from “CocoaHead”. Many many years ago before the iPhone, I was thinking about going “indie”. At the time, people were saying crap like “oh, Apple is going to declare bankruptcy…” and Michael Dell even said that Apple should return the money to the stockholders.
The reason why I didn’t make the jump was the fact that I got married and had to think about my lovely wife. Being a CTO was very good to my financial health and lifestyle, and it’s really hard to give that up because I wanted to do something I enjoy. How selfish of me. If you want to know what it’s like, take a look at Drunken Batman’s video. Just google it and you’ll see.
This me brings back to today. I have made the jump to do what I enjoy, working with Ruby. Sure, I always work with the code that makes me wonder why they even wrote it in Ruby, but nevertheless I enjoy the challenge, somewhat.
So, next time you meet a “Ruby Guy” or “Java Guy”, ask them where they’ve been, you’ll find it interesting.
