Evrone.com

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