RR 388: RuboCop and Code Linting with Bozhidar Batsov

    0
    869

    Panel:

    • Dave Kimura
    • Charles (Chuck) Max Wood
    • Nate Hopkins

    Special Guest: Dan Mayer

    In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details.

    Show Topics:

    0:00 – Sentry.IO – Advertisement!

    1:07 – Chuck lists the panelists and the special guest.

    1:37 – Chuck: Why are you famous?

    1:41 – Guest gives his background.

    2:13 – Guest: I am passionate about Emacs.

    2:55 – Chuck.

    2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop.

    3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that.

    4:45 – Guest:

    4:49 – Panel: Can you tell us what RuboCop is and why is it important?

    5:00 – Guest:

    There are a few main things that RuboCop is:

    1.) Placement for Ruby minor…

    2.) Lint tool

    3.) Automatic checker for all the best practices outlined in the community

    4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code

    7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it?

    7:49 – Guest.

    The guest talks about RuboCop in detail.

    10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the…in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though.

    12:07 – Guest: Why disable it and not…?

    13:36 – Panel: You could use VS code instead of Emacs! I am just kidding.

    13:51 – Guest: I hope you are kidding!

    13:56 – Chuck: I cannot live without this code…

    14:06 – Guest.

    14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor.

    15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in.

    15:35 – Guest.

    16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS.

    16:57 – Guest: Komodo was a famous editor.

    17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language?

    17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was…

    Guest goes into great detail about this topic. 

    22:44 – Guest (continues): RuboCop offers a bunch of different structure.

    24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient – they will choose the latter option.

    25:47 – Panel: That’s why they get hit with a high AWS bill.

    26:00 – Guest.

    26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all?

    26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this.

    If you give people too many options then it could be a waste of time. I don’t care about the nuances.

    30:06 – Ad: RubyMine! 30-day trial!

    30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team?

    30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it.

    At the end of the day it’s better to have consistency within a project. You are doing great!

    32:57 – Chuck asks a question.

    33:44 – Chuck: Could I modify a rule?

    33:53 – Guest: There are varying degrees to the rule.

    35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks?

    36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating.

    41:05 – Guest (continues): I think we need to commit to the module and the API.

    45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in?

    46:00 – Guest.

    48:18 – Panel: Transition that to Rails and the future of Rails?

    48:27 – Panel: There are big companies that are making changes.

    48:51 – Guest.

    53:33 – Panel: I think that is a common pattern that most companies move towards.

    54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out!

    54:35 – Chuck: Picks!

    54:40 – Advertisement – Fresh Books!

    End – Cache Fly!

    Links:

    Sponsors:

    Picks:

    Dave

    Nate

    Charles

    Bozhidar