Sider is happy to announce to welcome the RuboCop committer, Masataka Kuwabara, as known as Pocke, Sider as our technical adviser from April 2018. Since he joined Sider in September 2015, he had been involved in the expansion of Sider’s analyzer. He took a full-time position at Cookpad Inc. from this April and still be part of Sider as the technical adviser. To celebrate his exciting career path, Sider interviewed Pocke. Pocke told us stories about RuboCop to Bozhidar Batsov (@bbatsov) and advised future committers in a very relaxed interview. Read on to find out more!
– Let’s start with a basic question. What is RuboCop?
If I were to describe what exactly RuboCop is, it is a static code analyzer for Ruby. RuboCop includes a style checker, Linter, and other elements. One example of “other elements” will be something that can value the metrics.
One funny feature is that a line from the Hollywood movie RoboCop — Role models are important — is the first sentence in the readme file.
I believe Ruby Style Guide also cites the same line.
Pocke’s Journey to Become a RuboCop Committer
– What was the story behind your involvement with RuboCop?
Since I joined Sider in the fall of 2015, I started using RuboCop. In 2016, I sent a pull request to RuboCop for the first time. At first, I was just sending minor pull requests. As I was more involved, I found more bugs in RuboCop. It was fun fixing them.
– What are your major tasks for RuboCop?
I am simply fixing bugs.
For instance, this pull request is for fixing the bug where RuboCop crashes when if the body is empty.
Other than that, I used test-queue to speed up RSpec a little while ago. https://github.com/bbatsov/rubocop/pull/4544
At the time, continuous integration (CI) was painfully slow so I was happy that I could make it faster. It got two to three-times faster.
– What was the starting point of you becoming a RuboCop committer? Was there any particular event leading to that?
I don’t recall anything particular. Just one day, out of the blue, I got an invitation. The readme history says it was eight months ago.
I wasn’t doing anything special. But I’m pretty sure I was most actively sending pull requests at that time.
– Is there any difference between before and after becoming a committer?
Not really. Big differences would be the fact that I can publicly say I’m a committer for RuboCop and I can put labels on issues.
It was not fun when five same issues were submitted. Of course, it is not a big deal because you can close them immediately. Since I am a committer and have the control to label, issues are my problems now. I wish people do a quick search before they submit issues.
Who is Bozhidar?
– What’s Bozhidar like?
I think Bozhidar is VP of engineering at a recruiting agency somewhere in EU. I’ve never met him in person,but he was one of the speakers at EuRuko last year. He is not actively coding RuboCop nowadays. It doesn’t mean he lost his interest in it. In fact, he actively sends reviews. He responds rather quickly, judging from his reactions to pull requests. Only when he is traveling, his response doesn’t come back right away. Other than that, he is pretty diligent.
I have an overall impression that he is a neat kind person. For example, when he says something in his review, the same thing is written in the same code repeatedly. It really helps me remember. He also merges most of the pull requests. In that sense, I think he is very tolerant and can accept any trouble he faces. When a pull request is too big or has no explanation, he cannot do much but ping the person and close the pull requests if there is no response from them after a while.
– It seems there are many references to the movie RoboCop such as the name RuboCop and the readme file. Whose idea was it?
I think it was Bozhidar’s idea. “Role models are important” is in Ruby Style Guide. Bozhidar also worked on that.
One thing I found interesting was the rule groups in RuboCop. Group such as Style and Lint used to be referred as cop_type. All of a sudden, it was changed to department.
<<PR: Replace `cop_type` with `department` https://github.com/bbatsov/rubocop/pull/3842>>
“Department” supposedly refers to police department*. There are terms related to police such as teams under Commissioner, force, offense, etc. Force does not have anything to do with programming jargons but indicates something that traces variables. It took some time to memorize the structure.
(*Source: 2016/12/30 https://github.com/bbatsov/rubocop/pull/3837#issuecomment-269750599
In this comment, Bozhidar says “And I think we’ve strayed from out fun police references! cop_type? A cop should have a department, not a type! :-)”)
What Takes to Be Part of RuboCop Development
-How do you review codes for RuboCop itself? Please tell us about that as a reviewer and a reviewee.
There are no designated reviewers. Someone in the community does it. But Bozhidar usually merges everything. A significant number of people who are not committers are reviewing and actively part of RuboCop.
There are no strict rules, but we want people to follow the template for pull requests in the repository as much as they can. There are projects that we want people to follow specific steps such as creating a pull request after creating an issue. But there is no rule like that with RuboCop. We want people to run additional tests, though.
What to be careful while reviewing depends significantly on the reviewer. There are plenty of people who comment on coding style. People often comment on names and English. In the beginning, I couldn’t write English well. I frequently received messages on offense saying “This English sounds incorrect.”
– Do you have any advice for new contributors?
I think it is important to run the pure Ruby code and check whether it crashes or not. So, I would advise them to test what they created with as many types of code as they can. When I do thorough testing, I test on big Ruby projects such as ruby/spec (github.com/ruby/spec) and GitLab(github.com/gitlabhq/gitlabhq) to check whether it crashes and whether there is a certain number of correct offenses.
– Do you have any suggestions on where to start with RuboCop?
RuboCop crashes easily on custom settings so you can find problems pretty quickly. RuboCop checks itself, but it is usually in its default setting, so it can be quite difficult to find problems.
Other than that, in ruby/spec that I mentioned earlier, you can find some interesting code. If you let RuboCop read the code, you can crash RuboCop easily.
Also, there is something like this (#4910).
After I created an issue to request examples in the documentation, people started following this issue. It is easy to do, just adding a comment. But without it, without seeing a test case, it was hard to tell what the cop does. Probably, something like this was easy to start with RuboCop.
There are many issues accumulated. Over 300 issues are still open, and many have been open for a while. If you look closely at those issues, you can probably find something that you can work with.
– Do you have a new goal or plan with the RuboCop development team?
There is an issue recently created, called “Bump to 1.0”. I’m wondering if we are going to start working on this.
RuboCop is 0.53.0 now. Seeing from Bozhidar’s comment, he seems he doesn’t want to bump it up to 1.0 yet. He says the quality is not there yet, but I don’t know what direction he wants to take. Maybe he wants to keep crashing RuboCop. In my own opinion, I want him to release 1.0 soon and crash that, then release 2.0.
I’m personally interested in working on autocorrect. I want to improve RuboCop’s autocorrect such that it can fix the code in ruby/spec without changing the result of running the test. Currently, RuboCop doesn’t run well when you input ruby/spec.
There is also another demand for a Rubocop feature where you can autocorrect a selected portion of the source code, but it is not supported yet. It will be great if I can answer this kind of demand.
– I know there are some RuboCop developers in Japan. Do you meet and talk to them in person?
I meet them relatively often at meet-ups. I’ve been meeting with koic (github.com/koic) who has been throwing pull requests lately and talk about RuboCop together. Last year, when I attended RubyKaigi, he came up to me and said “Hey I’m trying to make something like this. What do you think?” So, I checked his pull requests while talking with him.
To RuboCop Users
– Do you have any suggestions or advice on how to use RuboCop?
I have a piece of advice: Do not expect too much of RuboCop. Some people think RuboCop is a silver bullet. They guess installing RuboCop improves your code automatically. It doesn’t work that way. You have to know the purpose: what you want RuboCop to do. Otherwise, you can’t optimize RuboCop.
For example, you want to unify the coding style with RuboCop. To do so, you either need to start from making the coding style guide yourself or use RuboCop’s coding style. Just installing RuboCop will end up with many errors and fail to unify the coding style.
You should think about what you want to do with RuboCop first then set it up according to your purposes.
– Can you elaborate on how they should set up RuboCop?
I’ve been writing a column called Ruby Doki-Doki Tankentai on WEB+DB PRESS since 2017. In Vol.102, I wrote on that in detail, so reading the article might help.
Generally speaking, if you want to unify the coding style, you just need to work on it diligently. We have a system called .rubocop_todo.yml (http://rubocop.readthedocs.io/en/stable/configuration/#automatically-generated-configuration). You can use that. The system writes out errors from the current source code as ToDo first then stops displaying errors. This allows you to ignore the errors at first and create your own rules gradually to apply to RuboCop. After all, you have to do the work. There are always points where you have to put your work on RuboCop.
Looking for bugs is easier to do. There is an option called DisabledByDefault. I recommend disabling everything once except Lint rules that look for bugs. The setting of ruby/spec is similar, so, it might be a good reference for that.
– Do you have any requests for RuboCop users other than reporting the same bug repeatedly?
I do want them to report as many bugs as they can find. Particularly for the Japanese users, I made an organization called rubocop-jp(github.com/rubocop-jp/issues), so they can report bugs there. I used vim-jp(github.com/vim-jp) as a reference. It will be ideal to translate whatever comes up in rubocop-jp into English and throw them at Bozhidar.
I was the one who was hesitant to write in English, but without English, I couldn’t throw issues at Bozhidar. So, I accumulated many issues on my end. I just got tired of maintaining them by myself, so I created rubocop-jp.
– Using RuboCop on Sider seems useful. Can you tell us about that?
Looking at the current state, Lint tools tend to create false positives. But it seems pretty easy to enable the false positives by running on Sider.
If you don’t have Sider, you need to execute either locally or execute in the CI process. Locally executing one by one is tedious, so it seems it is better to execute in the CI. But that creates only two options: you get 1 or 0, meaning RuboCop might execute or fail. I think that can create inconvenient conditions. With Sider, you can have an option whether you close errors that RuboCop indicates. By making the errors acceptable, you can make RuboCop more flexible and easier to use.
(From Editor: On Sider, you can do individual settings whether you fix the errors indicated by Lint tools such as RuboCop or ignore at the moment. You can actively inspect tools efficiently because you can decide whether to fix or not while checking the indicated errors.)
If I can talk about something that hasn’t been implemented yet, autocorrect can be improved. It will be very useful to have a UI that can interactively correct when you don’t have a clear idea of what to correct automatically.
After the interview, we took a picture of Sider’s CTO, Matsumoto, and Pocke together.
We appreciate your continuous support, Pocke!
For more information about Sider, please go to our website.