The First-Person Sequel and Roda Insights from the Lead Dev: an Exclusive Interview with Jeremy Evan

Introduction

Jeremy Evans is the lead developer of the Sequel database library, the Roda web toolkit, the Rodauth authentication framework, and many other Ruby libraries. He is the maintainer of Ruby ports for the OpenBSD operating system, and has contributed to CRuby and JRuby, as well as many popular Ruby libraries. We are happy to present a brand-new interview with Jeremy to our readers. Hope you enjoy it!

The Interview

Evrone: You became a Ruby committer and received the Ruby prize 2020 with your work on keyword arguments separation. Could you tell us how did it happen, how did you feel about that?

Jeremy: I was overjoyed to both become a Ruby committer and to be the recipient of the RubyPrize in 2020.  In terms of how of those happened, I'll start with becoming a Ruby committer.

I have been contributing patches and bug reports occasionally to Ruby since 2009. However, I started to get more involved with Ruby in early 2019 when hearing about the direction for keyword arguments in Ruby 3. The original proposal for keyword arguments in Ruby 3 was for full separation, so that passing a hash to a method that accepts keywords would raise an error, but also that passing keywords (a hash without braces) to a method that accept an optional hash argument would also raise an error. I thought this proposal went too far, by breaking compatibility with Ruby code that did not use keyword arguments at all. I built a patch on top of the original proposal that was more backwards compatible. I ended up presenting this proposal with Yusuke Endoh at the developer meeting at RubyKaigi 2019. While waiting on a decision from Matz about keyword arguments, I started sending in patches to fix other Ruby bugs, and after quite a few patches, Endoh-san recommended I become a committer, and Matz approved.

In regards to RubyPrize, I originally was nominated in 2019 for my work on keyword arguments and general bug fixing. I was ultimately selected as a final nominee in 2019. I continued to work on general Ruby bug fixing in 2020, fixing many long standing bugs in Ruby's object model, as well as working on some important performance enhancements for keyword arguments and the generation of partial backtraces. I was again nominated for RubyPrize in 2020, and this time I was selected as the recipient. I believe this is the second time a Ruby developer has been the RubyPrize final nominee one year and recipient the following year, with Takashi Kokubun (the developer of Ruby's JIT implementation) being the RubyPrize final nominee in 2017 and winner in 2018.

Evrone: You are an author of Roda and Rodauth, a maintainer of Sequel and a Ruby committer. Which of your open source activities do you find the most rewarding and interesting for you right now?

Jeremy: This is a hard question to answer, since I find all of my open source work rewarding. However, if I have to choose, I think my work on Ruby itself is probably the most rewarding, for a few reasons.

First, it affects the largest number of developers. While I'm happy with the popularity of the Ruby libraries I maintain, there are many more users of Ruby itself than users of the Ruby libraries I maintain.

Second, working on Ruby is personally more challenging for me. In many cases, this is because it is written in C and not Ruby (for changes to core Ruby or C extensions), or because it involves parts of the Ruby standard library that I am not as familiar with. Most of the other libraries I maintain are written in pure Ruby and I'm very familiar with them, so fixing bugs in them or adding features to them is generally not as difficult.

Third, it gives me a sense of accomplishment to be able to fix bugs in Ruby that have been known but unfixed for many years. That's a situation that doesn't happen in my other open source projects.

Evrone: Your projects have lots of tests and high test coverage. What do you think about Ruby 3 type signatures: can they help you write better software?

Jeremy: Unfortunately, I have to admit my ignorance in this area. I haven't used any of the static typing tools available for Ruby, and therefore I am not qualified to comment on whether they help write better software.

I will say from my brief time reviewing the documentation for such tools, that they have limitations I think would be too restricting. I extensively use plugin systems in my libraries, and heavily use singleton classes, and last I looked there was not good general support for these in any of the available Ruby static typing tools. However, such tools may have improved since then, as this is not an area that I have followed closely.

Evrone: You are currently responsible for OpenBSD's Ruby ports, including JRuby and Rubinius. From your point of view, how is OpenBSD used in 2021 and what is its niche compared to Linux-based distributions?

Jeremy: I don't think I can speak to general OpenBSD usage. However, in terms of my personal experience, I run OpenBSD on all of my personal desktops and laptops, and for all security sensitive servers at work. From a security standpoint, I think OpenBSD is the best general purpose operating system available. I make heavy use of OpenBSD-specific security features such as pledge and unveil in my Ruby web applications.

I also appreciate that it is very easy to administer OpenBSD systems, even more so in recent years. In my experience, using OpenBSD since 2002 both personally and professionally, OpenBSD is very stable, not just in a system-uptime sense, but also in terms of not making pointless changes.

OpenBSD does not perform as well as more popular operating systems, but in my environment, I am happy to trade performance for better security and easier maintenance.

Evrone: How closely do you keep track of other web frameworks, auth frameworks and database toolkits?

Jeremy: For web frameworks, I usually look at the release notes for Rails and Hanami when they release new significant versions, mostly to see if there are new useful features I would want to add to Roda. However, I do not follow the development of either beyond that.

I don't follow the development of other authentication frameworks at all. When I started working on Rodauth in 2015, I reviewed the frameworks available at the time to gather ideas. However, I haven't done any review since then.

For database libraries, I review the ActiveRecord CHANGELOG every few months to see if there are useful features I would like to add to Sequel. Lately, I've been finding out about new significant ActiveRecord features via Twitter after they get proposed as pull requests. In a couple of recent cases, I've thought the features sounded useful and have developed implementations for Sequel. This is how the async_thread_pool database extension and column_encryption model plugin were developed. I also read the release notes for major ROM releases, though more to see how they are using Sequel instead of for ideas to improve Sequel.

Evrone: In recent years lots of new features landed in Ruby: pattern matching, numbered parameters, keyword arguments, type signatures, ractors, async fibers, rightward assignment and more. What are your favourites and have they affected the way you develop Ruby software?

Jeremy: I'm very conservative in my use of new Ruby features. Most of my libraries still support Ruby 1.9+, and my production applications run on Ruby 2.5+. I would say the newest Ruby feature I've been using in my applications that I've found quite helpful is the lonely operator, which was introduced in Ruby 2.3.

Evrone: You maintain Sequel and its ORM layer for more than 10 years. What do you think about the main challenges ORM developers face nowadays?

Jeremy: I'm not sure I have a good understanding of challenges that other ORM developers are facing these days. In terms of personal challenges with Sequel, the last few years have been fairly smooth and challenge free. I would say that in general, there are aspects of Sequel where the internal complexity is high and working with the related code is challenging. One of these areas is Sequel's prepared statement and bound variable support, which is because Sequel was never originally designed to support those features. Another of these areas is Sequel's advanced association support, especially support for eager loading limited associations. However, I don't think I've had significant issues in either of those areas in the last few years.

Evrone: For what use cases would you recommend Ruby developers to use Roda, Rodauth and Sequel? Where do they fit perfectly and where developers would want to choose other frameworks?

Jeremy: From a technical perspective, I think Roda, Rodauth, and Sequel are the best Ruby web framework, authentication framework, and database library. In all three cases, I think the performance, architecture, and flexibility are significantly better than the more popular frameworks. If the primary consideration for choosing frameworks is technical, I think Roda, Rodauth, and Sequel provide clear advantages. I think this applies regardless of the size of the application.

However, in many cases, technical considerations may be less important than other considerations. If you compare Roda, Rodauth, and Sequel to Rails, Devise, and ActiveRecord, the Rails stack has several advantages.

First, more developers know the Rails stack, so it is easier to find developers that are already familiar with it. It is going to be more challenging to find developers that are already familiar with a Roda/Sequel stack.

Second, more external libraries are designed to work with the Rails stack, so it is easier to find libraries compatible with the stack. With a Roda/Sequel stack, instead of having many gems that could handle a particular need, you are likely to have just one, or possibly none in an extreme case.

Third, I think the Rails stack involves less risk. This less risk manifests itself in two ways. One is, "No one ever got fired for choosing Rails", or something like that. Another is, at least for Rails and ActiveRecord, there are simply more developers actively working on the libraries. While Roda and Sequel often get high quality patches merged that were submitted by external developers, the majority of the development for both happens by me. I would like to think in my absence, due to the 100% line and branch coverage, an interested developer would be able to take over my libraries, similarly to how I took over maintenance of Sequel, but that may be optimistic.

Overall, I think the choice of using a Roda/Sequel or a Rails stack mostly depends upon the relative value you place on the technical considerations versus the non-technical considerations.

Evrone: Recent worldwide pandemic forced developers to work from home and conferences to take place online. How did that affect your work-life balance, your projects and open source contributions?

Jeremy: I consider myself very lucky that the pandemic did not have a larger impact in my life.  There were a couple months where I worked remotely from home, but otherwise my job was much the same as before. I worked on the same projects and my open source contributions were not significantly affected. I do miss attending conferences in person, and look forward to the end of the pandemic so that I can start doing that again.

Evrone: Roda recently passed 1 million downloads, becoming the fourth Ruby web framework to pass that threshold. Sequel now has over 25 million downloads, and these numbers mean a lot of feedback on your open source work. What are the main technical lessons you learned from it through all these years?

Jeremy: I think the most important thing I've learned from my open source work is the importance of testing. Having a test suite that you can rely on is critical to confidently fix bugs and develop new features. Before I started maintaining Sequel, I did not have a good appreciation for how helpful a good test suite was. I think the main reason I was successful in taking over maintenance of Sequel was its comprehensive test suite with almost 100% line coverage, since it allowed me to easily make changes and see if those changes caused regressions elsewhere in the library.

Evrone: Your popular open-source projects and OpenBSD work expose you to alternative Ruby implementations: JRuby, MRuby, Rubinius to name a few. How popular are they and how do they affect the projects you maintain?

Jeremy: Testing my libraries on JRuby has been very helpful in terms of finding bugs, especially thread-safety bugs that do not occur on CRuby due to CRuby's global VM lock. I'm not sure exactly how popular JRuby is. I get a feeling that the overall percentage of Ruby web applications running on JRuby is small compared to CRuby. However, the percentage is probably significantly different if you only consider large Ruby web applications running in enterprises.

I don't do embedded work, so I haven't had a chance to use MRuby, beyond the experience of packaging it for OpenBSD. From my limited knowledge, it's not that popular in the United States, but it is quite popular in Japan.

As far as I can see, Rubinius as a project is dead. I think TruffleRuby has taken its place in the overall Ruby ecosystem. I do some CI testing of my libraries on TruffleRuby, but I'm not sure TruffleRuby runs on OpenBSD, and I haven't tried it personally.

Evrone: VIM has been your favourite text editor for years. Have you checked VSCode? Many developers think that it's a good modern VIM alternative that can mimic all the keyboard navigation we are used to. What’s your opinion on that?

Jeremy: I haven't tried VSCode. VIM still meets my needs. Truth be told, for all my years using VIM, I'm still not an advanced VIM user. However, VIM works well enough for me that I haven't bothered trying an alternative.

Evrone: Are there any plans for your future work that you could share with our readers?

Jeremy: My plans are fairly boring. I plan to continue to maintain the libraries I'm currently maintaining for at least 15-20 more years, and probably beyond. I also plan to continue working on Ruby itself for the same time frame, primarily focused on bug fixing.

Evrone: Web development has recently made a full circle and returned back to its roots with projects like Hotwire that render all HTML on the backend. What do you think about that "HTML-over-the-wire" and "Fullstack without JavaScript" hype?

Jeremy: I've been actively promoting limiting JavaScript usage to the absolute minimum for many years. Most of my applications are Web 1.0 style request-response applications with server-rendered HTML and standard HTML forms. I only use JavaScript where it is necessary. When I need something beyond request-response, in most cases my need is unidirectional (server->client), so I use MessageBus and not WebSockets.

That's doesn't really answer the question, though. I haven't used Hotwire or a similar libraries, and when I do use JavaScript in my application to submit requests, I'm probably just as likely to use JSON as HTML. So in a certain sense, I would say I hope the trend goes even further in terms of simplicity.

If you do need to use JavaScript, I don't think it makes sense to be dogmatic about JSON vs. HTML. You should pick whatever makes the most sense in that particular case. Generally if you have to replace the content of an entire element, then HTML works better, otherwise JSON can work better. It's also possible to mix the two. I have applications where I'll have a dynamic request return a response that is a JSON object that contains HTML snippets, in cases where I want to update multiple HTML elements.

Evrone: If you could change one thing in any of your projects or Ruby without having to care about anything, what would it be?

Jeremy: If I could change one thing about Ruby without having to care about anything, I'd probably start removing features, starting with refinements and Module#prepend. Both of these significantly complicate the Ruby object model and implementation. Both have been the cause of numerous bugs, and in some cases the issues they cause may not be fixable. This is a selfish answer, as I don't use either feature in my libraries or applications, but I have spent extensive time fixing the issues caused by the features. So in terms of personal use, the features are all cost and no benefit. I certainly see the advantages they offer to other projects, though.

The conclusion

We had a great talk with Jeremy and learned more about his projects & life. At Evrone, we often use Ruby to develop custom solutions for our clients. If you love it as much as we do — just send us a message via the form below, and let's have a chat!

Previously published here.

The author of the story is the Chief Editor at Evrone.