A couple of weeks ago I wrote about Ruby Heroes. I thought I would write a post about my Ruby Hero – Konstantin Haase. He is one of the busiest people I know in the Ruby community- his output is amazing – just check out his github profile!
Konstantin describes himself as an ‘open source enthusiast’ and contributes to a number of Ruby projects, including Ruby on Rails, Rack and Rubinus. Konstantin is also the current maintainer of Sinatra, and under his guidance it has matured into a wonderfully stable and minimalist web framework that is capable of running sites in production environments. He also, literally, wrote the book on Sinatra (along with Alan Harris). I don’t think there is anything he doesn’t know about the nuts and bolts of Sinatra’s internals.
Like a true hero, he doesn’t keep all this knowledge to himself – he is always answering questions on the Google Groups page, no matter how dumb they are (I should know!) as well as helping out in the IRC channel(#sinatra), and on Stack Overflow.
I caught up with him last week and asked a few questions over email.
Q: Hi Konstantin, thanks for agreeing to answer these questions.
No Problem. I’m flattered that you think I’m a Ruby Hero.
Q: So what are you up to at the moment?
I’ve spent the last few weeks fund raising on my new venture – helping Travis CI to go full time.
Q: Could you tell us a bit more about Travis CI and what they do?
Sure. Travis CI was started by Sven Fuchs and Josh Kalderimis in 2011. It is a completely open source and free Continuous Integration as a Service application. You set it up for your open source project with a single click and it will run your tests whenever you push to Github. It supports a ton of programming languages by now, and for some, like Ruby, Node.js, PHP or Erlang, it even supports a couple of runtimes. I use it to test Sinatra on all the different Ruby versions and implementations and in different setups.
Travis CI has run 406,714 tests for 5,442 open-source projects to date, including Ruby itself, Rails, Rubinius, Rubygems, Bundler, Leiningen, Parrot, Symfony, and many more.
Q: It sounds great, but what was the motivation to become a fully registered company?
Well, the idea came from Sven and Josh. There are two motivations for this: First of all, it allows us to get donations from all those enthusiastic developers and companies using it and second, we plan on offering private build support, targeting companies that don’t want their code or test results being published. This will support the continued development of Travis CI without having to rely on future donations. By the way, if you want to donate, you can do this at the Travis Crowd Funding Campaign.
Q: How did you get into programming and web development?
I did a lot of non-web programming for a long time, without ever publishing code or getting payed for doing it. When I was about ten years old, I started programming in Basic and Pascal. My main motivation: My computer sucked, so I couldn’t play all those fancy games my friends in school were playing. I somehow [stuck] with it.
Q: How did you discover Ruby?
Mainly due to Why’s (Poignant) Guide to Ruby
Q: What do you think sets Ruby apart from other languages? Is it your favourite language?
Define favorite language. It’s far from perfect. It’s not the most consistent, nor clean, nor expressive, nor performant language. However, it’s comfy (I like expressing myself in Ruby) and has an amazing community.
Learn PHP for free!
Make the leap into server-side programming with a comprehensive cover of PHP & MySQL.
RRP $11.95 Yours absolutely free
Q: How did you get involved with Sinatra?
I don’t really know. For some reason I thought it would be a cool thing to play with. I started writing extensions for it, added some features, fixed some bugs and went on my way. I came back, fixed more bugs, saw that the current core team did not have enough time to go through all the existing patches, so I looked through them, pulled all that made sense into my fork, did some clean up, prepared it for a release, sent a major pull request (> 140 commits or so) and people started using my fork. There simply was this urge to see Sinatra do well, my goal wasn’t to become maintainer. Since no one had time to review and merge my pull request, I proposed giving either Markus Prinz or Chris Schneider a commit bit (both had multiple patches accepted and had been contributing before I even knew about Sinatra). Instead I somehow ended up with one.
Q: If you were to build Sinatra yourself from scratch, would you change anything and if so what?
Some of the internals. I have been thinking about rewriting Sinatra from scratch with a different approach, but it works quite well the way it is now and I always had more important/interesting things to do than start over from scratch.
Q: What plans do you have for the future of Sinatra? How do you see it developing?
Stability, performance, scalability, simplicity are the main areas where Sinatra already shines and will continue to shine. I also have high hopes for the sinatra-contrib project. There will be some changes internally for the successor of Rack, which Sinatra will of course support, but it’s all too early to really talk about.
Q: You’ve just finished writing a book about Sinatra, How did it come about?
Well, Alan Harris started working on the book and at one point I helped him with some code example (without knowing him back then). He asked me wether I’d like to become a technical reviewer and well, one thing led to another, and soon I joined him in writing the book. I have yet to meet him in person.
Q: And how did you find the experience of writing a tech book?
Fun. The only real writing I did before were academic papers. When writing a book, you have editors, and a lot of people actually read it and you get amazing feedback afterwards. Also, writing a book together with someone else was a really nice experience.
Q: Do you use any other web frameworks? What do you like or not like about them?
Of course I do. I use Rails a lot and it’s nice how well integrated it is and how there’s a solution for everything. I also used Seaside for a few projects. Every web developer should use Seaside at least once, to get another perspective on web apps and programming in general, though I would not use Seaside for any production app (see http://rkh.im/seaside for details). I’ve played with a lot of other frameworks and languages, too, but apart from Merb never used one for any real application.
Q: You do a lot of speaking at various conferences (I counted 10 in total last year, including a mini-tour of South American RubyConfs!) Do you enjoy it and are there any places that you have enjoyed visiting in particular?
Yes, speaking at conferences is awesome. I mean, speaking itself is fun, but getting to know people all around the world and seeing so many different places, that’s just amazing. All the places I’ve been to were really, really fun. I’ve especially enjoyed Edinburgh. And Lyon. And Boulder. And San Francisco. And New Orleans. And Portland. And how I nearly went to a conference in Mexico. And Sao Paulo. And Buenos Aires. And Montevideo. And Moscow. And… well… everywhere. The world is such a fun place.
Q: Any chance of a Sinatra Conf in the future?
I actually don’t like framework focused conferences. I prefer broader but regional conferences. Talk to people. Talk about technologies and paradigms rather than about libraries and announcements.
Q: What development environment do you use?
A rather timeworn macbook with Snow Leopard, TextMate 2, rvm, homebrew, well, all the standard stuff, really.
Q: You seem to contribute to a lot of open source projects, are you a big believer in open/free software?
Yes! And no. I don’t believe software has to be free for ideologic reasons. But it’s so much more fun to work with open source code and projects that are being developed openly than with projects being developed behind closed doors. It’s not just being able to dive into the system at any point (but that, too, oh yes), but also to be able to jump into the development process, that it’s the passion for the code that keeps you going, not some contract. I feel that if you truly develop out in the open, not if you just publish the code under some OSI license, you stop making painful sacrifices. It’s like agile development on steroids, without so many rules and overhead. You don’t do shitty solutions only because you wont meet a deadline otherwise. You don’t have to get something approved in some conference call that lasts for hours. You don’t work by the clock. You’re salary is not your motivation. Your motivation is that some code just has to be written.
Q: How do you find the time to contribute so much to the Open Source community?
Why do people ask always ask me that? I don’t know, I just make the time. If you have the urge to write some awesome fun code just for the sake of doing it, just do it. I don’t really have a solution for this other than that. Maybe earning a little less this month by spending less time on your job is acceptable for that. If that’s not possible, maybe it would be if you had a different job. Maybe it’s fine if you don’t know if you’ll have enough money to pay the bills in a few months from now, you probably will. If you do awesome work, there will be people paying you for it. Maybe not learning for exams is an option. I don’t own a TV, nor do I play video games, but I don’t necessarily do that on purpose, working on OSS just gives me more pleasure. I prefer spending my time on things I love. That includes spending time with my girlfriend or going out with friends, but it also includes solving the problems I love to solve instead of solving some problems for some company that I don’t care about, probably don’t even understand. Choose your problems. Does this even make sense? Scratch that, I have no idea how I make time. And to counter widespread rumors: Yes, I do sleep.
Thanks a lot for taking the time to answer the questions in so much depth Konstantin … But I’m sorry, I don’t believe that you actually do sleep!
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers
Jump Start Git, 2nd Edition
Your First Year in Code