In anticipation of RubyC, which will be held in Kiev on May 31 – June 1, 2014, we offer our visitors to learn more about its honorable speakers. The first interview is with Jeremy Evans – a leading developer of California Bureau of State Audits.
The operating system I use on all of my personal machines is OpenBSD. When most people think about OpenBSD, they think about security, and while that’s important to me, the main reason I use OpenBSD is that it is easy to administer and rarely breaks. I’ve been an OpenBSD user in some capacity since 2002, and have been using it on all of my personal machines since 2008. In 2010 I became an OpenBSD developer, and I’m currently responsible for OpenBSD’s ruby ports, including JRuby and Rubinius. My preferred text editor is vim, though even after a few years of use I still only use the basics (no vim plugins). I occasionally use SciTE for simpler coding tasks that don’t require a lot of editing. I use fluxbox as my window manager. It’s simple and gets out of the way, and I like the way window tabs and keyboard shortcuts work.
I definitely get some personal satisfaction from knowing that people are able to solve their problems using software I wrote. I think in many cases I feel a sense of camaraderie. Most of the time I am helping people, I’m helping them learn how to use the software I wrote, to solve similar problems that I have faced. I also remember what I was like when I was starting as a programmer. I remember how much I appreciated when other programmers helped me learn, and so helping others is a way to pay back for the help other programmers have given me. In many cases while I’m helping people, I get a better understanding of what the problems are in my own software. These may be missing or incorrect documentation, or things that just plain don’t work the way they should. I get frustrated when software I use doesn’t work correctly, so I try hard to make sure that my software does work correctly, so that other programmers don’t feel frustrated when using it. Helping other programmers helps me improve my own software, which benefits all of the programmers that use the software I write. In addition to getting frustrated when software doesn’t work correctly, I also get frustrated when I ask for help from other programmers when using their software, and they take a long time to respond or don’t respond at all. I think it would be hypocritical if I expected other programmers to respond quickly when I asked for their help, while not responding quickly when other programmers ask me for help.
While it is not and may never be the most popular ruby ORM, since it is not the default ORM for Rails, I think it is still widely respected in the ruby community. I’m certainly most proud of my work on Sequel. I took over maintenance of the Sequel project in March of 2008, after only using it for about a month. It was the largest project I had worked on at the time I took over maintenance. While the overall architecture of Sequel was good and in general persists to today, the implementation was a mess and there was very little documentation. However, the test coverage was excellent, which gave me confidence in refactoring and improving the implementation. Under my maintenance, I think Sequel has gone from a simple database library for quick database access, to the premier ruby database library and object relational mapper (ORM). While it is not and may never be the most popular ruby ORM, since it is not the default ORM for Rails, I think it is still widely respected in the ruby community.
While I’ve never worked for them or any other start-up, my favorite start-up is Heroku. In addition to using Sequel extensively in their internal systems, they also host many of my personal web applications for free.
In general, I test code in all my projects before every commit, or at least before I push changes to GitHub. For Sequel, this testing is quite extensive, as I’m testing on about 6 ruby implementations, over 10 database adapters, and over 10 databases, with the total number of test suites run probably numbering over 100. In terms of the testing library itself, I usually use RSpec. The test style I use hasn’t changed much since RSpec 1, and many of the libraries I work on, including Sequel, will run on RSpec 1, 2, or 3. I do use Travis-CI on Sequel and another project, but in general I’ve found it reports more false positives than actual issues. Still, for my more popular projects, I still think it is a net benefit to use Travis.
I did have very brief exposure to programming as a child (some basic graphic programming when I was around 10), and some additional exposure during college (C++ and Java), but I didn’t start programming professionally until I was 23. I would probably be a much better programmer now if I had started younger. I’m not sure I would advise my children to try programming at all unless they showed an interest in doing so. However, if they wanted to learn programming, I’d probably try to start them on Ruby or Python.
I think reading is important, but like many things, programming is something that requires a large amount of experience to do well. I read a lot of free programming books, and while I’ve definitely learned things just from reading, I’ve learned far more by trying to build something after reading.
I plan to continue working on Sequel. It’s been a little while since I tried learning a new programming language (my last one was Io), so I may take some time to learn a new one. I’m looking at Smalltalk, Nimrod, Elixir, and Forth as possible new programming languages to learn. Usually I try to implement a small library or application in the language. It needs to be small enough that it doesn’t take too much time, but large enough so that I get a good feel for the language.
Thank you and see you at RubyC!
April 18, 2014