GitHub Satellite Tokyo was held for two days through June 12th to 13th, 2018. Our Sider team requested an exclusive interview with GitHub’s Aaron Patterson who came to Japan for this event. Aaron, who is friendly and speaks Japanese fluently, answered many of our questions in Japanese with a warm smile. Enjoy!
Life at GitHub — From Upgrade of Rails to Improvement of GC
Soutaro: I’m wondering if you can tell us about what you guys have been up to at GitHub.
Aaron: I’m just an application developer at GitHub actually.
Soutaro: What? So you are actively writing production app code?
Aaron: Just kidding. It’s a joke.
At GitHub, I’m working on improving memory usage of the application as well as improving website speed. In other words, my primary task is system performance. I’m not a full-time Ruby committer, but I develop the application and Ruby.
Soutaro: Is it something related to GC you were talking about at RubyKaigi and RubyConf? Does that mean the improvement of GC was necessary at GitHub?
Aaron: Yes. GitHub’s application uses lots of memory, so we’ve been looking for ways to reduce memory usage of Ruby programs.
About a year ago, I started doing research when I heard the support team at GitHub Enterprise (GHE) saying “our application’s memory usage gradually increased.” GHE and GitHub.com share some application code, but GHE runs on clients’ hardware. The clients’ computer memory is smaller than GitHub.com, so it is more constrained.
Soutaro: I understand. I think Sider’s on-premises version will eventually deal with resource problems.
Aaron: It is the same as our problem.
Soutaro: I was wondering why you have been working on memory a lot lately.
I think the compacting GC you talked about at RubyConf 2017 is great. Up until then, I thought it was pointless to do compaction with Ruby. But you made me think “we can actually implement effective compacting GC!”
Aaron: Thank you. Development is in progress. We have tried it out in the production, but we haven’t released it yet. There are still bugs, so we haven’t submitted to Ruby core. When we tried it in a portion of GitHub production, we found bugs, so we reverted it.
It is so much fun working on GC, but that work is about 20% of what I do at GitHub. Normally, I solve problems on Rails. I fix Ruby errors found during GitHub development.
Soutaro: And do you fix the code on GitHub at the same time?
Aaron: That’s right. GitHub’s current Rails version is 4.2, but it was 3.2 a year ago. We are currently upgrading to 5.2. We have found various problems.
Soutaro: I see. When you started working there, it was 3.2, but you felt an upgrade was crucial.
Aaron: Yes, that’s right. Because I wanted to try out Rails master and Ruby trunk in the production, I had to upgrade Rails. If we use Rails master, I think upgrading will be easy. We can constantly upgrade, and if someone adds a bug to Ruby or Rails, we will know right away(laughs).
Soutaro: OK. Well, it’s a significant advantage of GitHub that the company has people who understand Rails and Ruby in its team. Any issue can be fixed and deployed by themselves.
Aaron: Yes, I think so too.
I think improving the performance of Ruby will probably not give us the results we want without understanding Rails. Nowadays, the performance bottleneck for web applications is Rails, not Ruby. I believe understanding both Ruby and Rails can lead to better results.
Soutaro: What made you decide to join GitHub?
Aaron: GitHub has invited me to work there maybe three times. At the time, I wanted to be a full-time Ruby committer. During the interview, they told me that I could be one at GitHub. Considering it was their third invitation, I thought there will be no fourth chance. So, I thought I had to join then. That was the reason.
Also, another reason why I decided to join was that I wanted to see the code of GitHub.com.
Soutaro: How was the GitHub’s code?
Aaron: There are some problems, but I’ve seen worse code many times before. So, our codebase really is not too bad. But, of course, we do have problems too.
What was exciting was when I fixed a bug written by defunkt (Editor’s note: GitHub’s co-founder and CEO). It wasn’t a serious error, but I was excited I could fix his bug! The bug was in old code, and I wanted to know who wrote it. I performed
git blame and found out defunkt wrote it!
Styles of Ruby and Rails
Soutaro: The other day, when we interviewed Akira Matsuda, we asked about code review for Ruby and Rails and coding styles. Is there anything you want to add? Do you have any opinion on those topics? Was there anything you disagree?
Aaron: That article was fascinating.
The coding styles between Rails and Ruby are entirely different. For example, Rails use only space, but Ruby uses both space and tab.
Aaron: Wow! I didn’t know that.
Soutaro: I’ve talked about this to three Ruby committers, and two of them didn’t know about this… How did that happen?
Aaron: I don’t care much about space or tab, so I didn’t really pay attention. I don’t have any problem with styling because Vim automatically fixes the style.
There is a specific setting in Vim that automatically chooses spaces or tab, but it is not well known because people don’t use both space and tab in the same file.
Soutaro: And Rails has been using two spaces from the beginning, right?
Aaron: Two spaces.
There is one thing I’m not too crazy about, which is when you write
private. When you write
private, you have to enter two spaces under the line of
private. I think it is unnecessary. We don’t do that at GitHub. I’ve seen that in another projects, but the developer was a Rails core team developer.
Soutaro: Do you think there is any benefit in DHH indentation?
Aaron: … I don’t know.
DHH claims the extra indentation enables people to find private methods easily. But if you see
private, you can tell right away. I think there is no problem without two spaces because we know whatever below
private is private.
Soutaro: I agree.
Aaron: Speaking of styles, Seattle.rb users don’t use parentheses.
We don’t add parenthesis for arguments when defining methods. Most people don’t like this style, but I love it. I don’t understand why they don’t like it.
Soutaro: Ummm. I don’t like it either…
Aaron: Why not?
Soutaro: It looks like C. I can’t explain well…
Aaron: The reason why I’m not using parenthesis is that Ruby is similar to Lisp. Lisp looks cooler without parenthesis. Lisp has too many parentheses.
Soutaro: I also write OCaml, so that might have an influence on my preference. In OCaml, to define a function with multiple arguments, we can use a tuple or make it a higher-order function. They have different types like
int * int -> int and
int -> int -> int.
Aaron: Ahhhh, I see. You need parenthesis in that.
Soutaro: Right. I also heard that there are lines where you can omit parentheses without causing ambiguity in Ruby. That was very convincing.
Aaron: I think most people who prefer parentheses are used to languages similar to C. Probably, that’s why they don’t feel comfortable without parentheses.
Anyway, the most important thing is using the team’s coding style. When I develop Rails, I follow Rails’ style. When I’m developing GitHub, I follow GitHub’s style. I have my own style preference, but my feelings are not that strong for keeping my style.
I would tell people to work on their own projects if they want to use their own styles.
Soutaro: Isn’t it confusing when styles are different depending on the project?
Aaron: Not really. Most of the projects have RuboCop installed. And if I make a mistake, someone will tell me. So, there is no problem.
Soutaro: Do you like RuboCop?
Aaron: Actually, I didn’t like RuboCop when I started using it. But I’m used to it now.
At first, I felt “I don’t like the RuboCop pushes the style on me.” If you think about it, the best thing to do is follow the same style your team is using. I think RuboCop is okay now because I understand why I should use RuboCop. The most important thing RuboCop provides is coordination for the team.
Soutaro: Yea, I think so too.
Could you tell me about reviewing Rails?
Aaron: Oh, yea. The review process for Rails is easy in my opinion. Because no one reviews my code!
There is no review because I push to the master branch directly. Even when I break something, someone else will fix it for me. It’s not a good practice though.
Soutaro: So the situation is like Ruby.
Aaron: Yes. I recently started creating pull requests. I didn’t use pull requests before because it was kind of a pain.
But, when I pushed directly and CI started failing, it was way more of a pain to fix; I started creating pull requests.
GitHub’s Development Process
Soutaro: We talked about Rails and Ruby so far. How are you guys reviewing code at GitHub?
Aaron: I think the review process is similar to others. Usually, when we create bugs and features, we cut a branch, develop, review, then fix.
We deploy the branch to the production. If there is no error, we merge it. In other words, the master branch is always stable.
Soutaro: So, at GitHub, you guys deploy before you merge pull requests.
Aaron: Each programmer creates a feature branch, creates a pull request, deploys to the production after approval. If there is no problem, s/he can merge it. If there are more errors or some issues, s/he deploys the master branch to the production.
When deploying, the new version will be pushed to 3% of the machines and deployed. Then, we check for errors. If there is no increase in the number of errors, we deploy completely and merge to the master branch. 3% is a bit much as the absolute volume of the traffic, but it is not as much as the volume of the entire traffic. If there is any error, we can quickly roll back.
So, the master branch is stable all the time and enables us to roll back. This is something different from other companies.
Soutaro: Yes, Sider’s process is different from yours. We review a pull request, merge it, then deploy. When we want to roll back, we click the “Revert” button on the GitHub screen.
Aaron: Yea, that makes sense.
Soutaro: By the way, how long does it take to complete deployment at GitHub?
Aaron: It is becoming a big problem right now. Deployment itself takes about 10 minutes to 20 minutes. But the problem is we have a queue for deploying, so we have to wait for a long time in the queue. Five to ten releases are in a queue. Each deployment takes about 10 to 20 minutes. You end up waiting for one or two hours.
But there is no one in the queue now because I’m in Japan and there is the time difference. Everyone is on the West Coast so it will take about 10 minutes to deploy.
Soutaro: That’s great. It is like an “all you can deploy” buffet.
Aaron: Yes, exactly. Since it doesn’t take that long to deploy here, I message people on Slack: “You guys should move to Japan!”
Currently, we are trying to come up with a solution to this problem. Probably, we will use something like a microservices. If the application is broken up, there will be more queues and the waiting time could be shortened.
Soutaro: Right. That is about deployment, but do you guys review in a standard manner?
Aaron: Yes. We are also using RuboCop. We are not using the default setting though. We have the GitHub Style Guide available to the public, so we are following that.
But GitHub’s style uses double quotes. I used to use single quotes, so it was a little inconvenient when I started working at GitHub. RuboCop used to get mad at me.
Soutaro: Hrm? I thought Rails used double quotes too.
Aaron: I think you can use either double or single quotes.
Soutaro: Are you sure?
Aaron: Mmmm… I might be wrong.
(Soutaro shows https://github.com/rails/rails/blob/v5.2.0/.rubocop.yml#L120-L123 on his device to Aaron)
Aaron: Oh, no!
Soutaro: Hrm… I wonder why you didn’t notice… Maybe, you don’t write string literals often?
Aaron: Probably, I don’t…
Speaking of double quotes, I don’t like the fact I have to press the shift and quote key on a conventional keyboard when I want to type a double quote. On my keyboard, I only press one key to type a double quote. It’s because I made my own keyboard.
Soutaro: What! That’s amazing.
Aaron: Also, with my keyboard, I can type parentheses in the home position. Press this button, then, D and F to write a parenthesis. They are the opening and closing parenthesis.
(Editor’s Note: We couldn’t help ourselves to see his keyboards. We checked his Instagram and saw many keyboards there! If you are interested, visit here!)
What’s important in Code Reviews?
Soutaro: Are there any differences when reviewing code at GitHub and open source projects such as Rails?
Aaron: To me, there is no difference. But I think people try to do better reviews on open source projects. They tend to write thorough comments and give feedback. But when it comes to in-house reviews for companies, people don’t do that. They write shorter comments or don’t review as well.
So, I try to give high quality and thorough reviews at work as I would do for open source projects. But I’m not sure if that’s what everybody does. So I think that is the difference.
Soutaro: What do you think about the reason why there is a difference in the quality of comments?
Aaron: It might be because you and your co-workers get to know each other at work so you can review a lot faster. But in an open source project, you don’t know the other people, or they work at different companies, so you can’t review like in-house. You have to communicate more.
But I believe that’s a good thing. So I try to do that at work. There might be a situation when I want new employees to read or I, myself want to go back to the code. It is better to have something written down in case I forget about the details of the code.
Also, another difference is the development velocity. Companies don’t have much time for development as open source projects. I think that impacts the style of comments.
Soutaro: What’s the most important thing while you review code?
Aaron: The most important thing in reviewing code is understanding changes in code. I think it is most important to understand how the code is changing the program’s behavior or what it is doing. But if you are looking at just diff, you can’t really tell sometimes. I think that is the difficult point of reviewing pull requests: how you understand the whole system.
Soutaro: I think GitHub’s pull requests improved the efficiency of reviews. But do you think it is not sufficient?
Aaron: Pull requests are convenient such as writing review comments.
But you cannot tell how the program functions sometimes just by looking at the diff. When you read diff, you can see what changed in the code, but you don’t know how that change impacts the whole system because you can’t tell how it affects the other code. It will be nice if we can see that automatically.
Soutaro: Is that like something goes wrong at where another code is referred when changing the definition of a class?
Aaron: Yes, it will be very convenient if we can see that automatically.
If there is something that can analyze code in Ruby, it will be very beneficial for a big project.
Soutaro: Like a type checking tool?
But… I don’t want to write types…..
Thank you Aaron, for taking time out of your busy schedule to talk with us!!
For more information about Sider, please go to our website.