FiveRuns Blog

Welcome to this week’s edition of Rails TakeFive, our weekly conversation with Ruby and Rails developers from around the world. This week, we spread our wings to the Czech Republic and welcome Karel Minařík, an independent web designer, developer, instructor, and organizer of the Czechoslovakian Ruby Users Group.

FiveRuns: Welcome Karel, and thanks for taking the time to share your thoughts with our readers. Let’s get started by talking a bit about GitHub. The community has really taken off, especially now that the Rails repository has been moved over. Can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Karel Minařík: I think Github is the true Facebook for Ruby and Rails developers now. Starting to use Git alone was a small revolution in how I see version control. Previously, having been using Subversion, it was more like necessary evil — a good practice, precaution and a way how to collaborate on codebase. Git changed everything about that, in the way it blends into my workflow with its easy branching and merging, remote repos, transparent ignore rules, …

“Automagic” branching and merging really is a killer feature for me — when I start working on a new feature now, I regularly create a new branch, write the code and tests and then merge back into master. I keep a “deploy” branch for every project, so it’s easy to provide hotfixes, etc etc. Very hardly would I undertake such adventures in branching and merging with Subversion. Also, the distributed nature, being able to work with the repo on limited connectivity, and knowing that every repo copy is self-sufficient, is very, very nice.

But Github is just another story. Github and the community around it pushed Git usage on a completely different level — in the way it blends “Sourceforge like” code repositories with the “social” features pioneered by Flickr and others: commenting on commits, subscribing to notifications about projects, exchanging messages, …

It’s lot more fun to publish some code when you know there are thousands of other people possibly interested, eager to learn something new and even to help you out. It happened to me with my demo app for the new Rails localization API — instantly Sven Fuchs of i18n core picked it up and was helping me to keep up-to-date with the fast pace of changes to the API, tried a couple of tricks with the complex pluralization rules, etc. I also got people writing me about some “gists” I posted, using the snippets in their code… It is very, very inspiring experience.

Important is, that it puts emphasis on the source code itself, as in Linus Torvalds’ dicto: “Talk is cheap. Show me the code.” The focus shifts from the plain “what does the code do? is it useful to me?” point of view to the code itself: how well architected is it?, how well documented?, has it got a README?, are there any neat Ruby tricks I could learn?

I even find myself more compelled to publish code instead of articles, thanks to Github. You can find great amounts of code on Github, people publishing their own blog engines, packaged solutions, and more. I envision even, there will be a time, when whole contracted (i.e., “commercial”) applications will be open-sourced. Because contrary to what the developer may be thinking, the code “doesn’t matter” in a sense. (As well as stating “but it works” doesn’t matter. When the code doesn’t “work”, it is not even code, it is some sequence of characters: that the code “works” is a pre-requisite for everything else.) The ideas expressed in code matter. There will be no need to guard code in some vault: the ideas embedded in it are very, very hard to “steal”.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Karel Minařík: Well, I think the idea of getting “fresh perspective” just by using another programming language for a while is quite exaggerated to some extent :). It’s a pretty low-level point-of-view, that just by coding something in Erlang you’ll pick up some magic powers elevating your skill. What’s quite more important in my opinion and what this topic leads to, is the stress on practicing.

The web programming we do daily is much more craft than science, math and best fine-tuned performance-optimized database query. When you play guitar for example, you’ll know, that your skill deteriorates pretty fast when you’re not practicing, experimenting, learning new licks, fooling around with gear. Jimi Hendrix used to practice almost all the time. It’s the same with programming. It’s essential to practice, experiment and explore your skill aside from the “regular” work.

Here I found much reluctance from my peers to do so: “there’s no time” is the usual statement. Regularly I find the “I am not proud of this piece of code” attitude as well, which is related. Imagine if you would be a guitarist and played only gigs, or worse, played only as an anonymous studio musician. Your skillset would quickly become very limited and your happiness from playing guitar would quickly drop near zero. I attribute this “unwillingness to play” to much failures and dead-ends we encounter daily in software development.

FiveRuns: Beyond Rails, beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Karel Minařík: Sinatra, definitely. Sinatra is such an awesome concept: let’s just drop everything and focus on the very basics of a web application. Let’s drop routing, helpers, database abstraction, everything and focus just on getting some URL, run some code, and return back some response. It is related to the practicing topic above: Sinatra makes it unbelievably easy to do some exploratory programming, try out a concept, while still following the best practices like MVC separation of concerns and RESTful orientation. Sinatra is the true “all you need, none you don’t” to me. Of course, Camping was probably the initial kick, “hey! let’s just make something different and have some fun, should we?” — which is the regular pattern with almost everything Why The Lucky Stiff does.

Merb itself doesn’t bring much conceptually new to the table. The idea of “agnostic to everything” is quite refreshing nevertheless, because it’s in direct contradiction to Rails. But Rails to me was and still is about the best practices in web development. Implementing MVC properly and painlessly (the famous “no XML sit-ups” quote), baking in testing from the beginning, embracing RESTful point of view, abstracting common things like dates calculations to transparent domain specific language, things like that. That was the punch delivered by Rails to everyone in the “web applications” field. That is the true sense of “opinionated” to me and I think the web-application space needs such opinions. But Merb to me is above everything a much needed competitor to Rails. Because without competition you risk inertia — the only motivation factors remaining are pride of your work, commitment to users, such things. You obviously still can deliver amazing “product”, but it’s more and more fragile as time goes. So “Go, Merb!” (particularly the slices and parts ideas), as far as I am concerned :).

FiveRuns: Obie Fernandez’s startup Hashrocket is all about being ultra-productive in 3 days. Obie has written about ultra-productivity here, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Karel Minařík: Hmm, “ultra-productive”. Sounds dangerous to my ears, all this emphasis on productivity, getting things done (“in no time”), and such. You’ll find lots of people picking up Rails recently only as a tool to deliver some functionality very quickly, with very low cost, with little deliberation. Just a “bigger chainsaw”, hacking down more trees in less time. But what is productivity? Number of features implemented versus time? Does it really lead to durable code? And more importantly: does productivity in this sense really matter so much? Isn’t it important to leave an application some room to grow instead of focusing on “building” it quickly?

The idea of Hashrocket, on the other hand, is plainly awesome. That’s just what the clients would love most: having an idea implemented quickly into some “deployable prototype” to try out how it works. Because you hardly know how something interactive works until it is implemented. It’s an awesome marketing incentive and I have great respect for Obie for coming up with that. This “ultra-agile” approach, when done in small steps and lots of iterations, is the way to make the kind of web applications Rails is destined for. I would just not put it in the same bag with “productivity”.

As for my own tips, I have one: I have found that to be able to come-up with something quickly and not be scared of it, is to do it the “right way”. It means no hacking around, no “I have no time to research this”, things like that. When I had to design a solution for a localization-heavy website recently, I had studied all the tutorials on the new Rails i18n stuff, and came up with a public demo application for it, played around with model translations then, and generally researched the “right way” to do it. To my own astonishment, it didn’t eat as much time as I anticipated, and I had incomparably bigger confidence in the code and my knowledge afterwards. Which in turn “boosts your productivity”, because you’re not constantly mentally tracking everything and you are feeling plainly “much better” about everything. This “feeling” may be hard to pin down and probably is not “measurable”, but essential nevertheless. It’s the “happiness as productivity factor” David Heinemeier Hansson stressed from the beginning.

And writing tests, of course, writing tests :). I don’t see tests as some magical weapon against bugs (there always will be bugs). I don’t see much point in elaborate Selenium-based setups for common apps, but I do see tests as a wonderful protection against myself: “oh, I have changed the attribute name or method return value here, where are the places I should have changed the implementation?”, “I should refactor this code but I am scared that I’d knock something out”, “the code in this app I made half a year ago is kinda embarrassing but let’s rather leave it as it is”. Moreover, in Ruby’s dynamic environment, tests are just a part of your code like everything else. (And here lies the spot where I see the “refactoring features” of IDEs miss the point almost completely.)

FiveRuns: What do you think about Ruby’s role in education? Do you think Ruby is suitable as an introductory language or even as a general instruction language?

Karel Minařík: Well, this is an important topic that deserves much more light that it currently has. I do think Ruby would be very much suitable as an introductory language to programming. I have spent one semester teaching “Programming 101” to non-programmers (New Media students) last year, and I have used Ruby to great result. The students didn’t have nearly any previous experience with programming — the only “programming” some of them did was making HTML pages.

We have covered topics like what is an algorithm, basic “vocabulary” like variables, functions, conditionals, loops, why object-oriented programming matters and is the sane way to go now. In the end they were able to perform some trivial text-analysis and write an Hpricot-based web parser. Some of them picked up interest in Ruby and started writing some console-based programs just for fun. Almost everyone walked away with fundamental understanding of “what those programmers do all the time anyway?”

I attribute much of that to Ruby principles: expressiveness and succinctness. I suspect a course drop-out rate of 80% if we would constantly bang our fingers and heads against public static void main. Ruby just makes you focus on the important things: what is it you’re trying to express and how transparently the code expresses it. It’s much more easier to just “show the code” to illustrate something than to write pseudocode or draw diagrams. In Ruby you can see the essence of writing code very clearly, “without all the curly braces” so to speak.

There should be some activity to get “more Ruby in schools”, I guess :). There was the great attempt with HacketyHack by _why, but that never really got “out of beta”. Moreover, I think the browser is the ideal platform for beginners, not desktop applications: you get instant gratification, you can easily show it, it is properly sandboxed, … So if services like Heroku or “never outta beta” IsOnRails would mature more, that would enable us to teach programming much more effectively.

Ruby’s strong “philosophical background” makes it ideal in my eyes for advanced education as well, because a) of the aforementioned lack of overhead and because b) its focus on domain-specific languages (and language in general), which I suspect will become a much more common approach –– you can see it in the popularity of JavaScript frameworks like Prototype or jQuery. Current academical computer science is very much pre-occupied with the low-level, technical aspects of programming, and too little with its essence: grasping reality and converting it to a set of rules, descriptions and procedures. As Wittgenstein would say: “The world is the totality of facts, not things.”

Karel Minařík is an independent web designer and developer with focus on clean architecture and user interface with rich interactivity. When Ruby On Rails re-ignited his passion for programming, he left Information Architect position at an agency to get back to development. He abandoned his Czech blog about Rails recently, and has some better ideas on his mind now. He lives in Prague, Czech Republic with his wife and two daughters, who are making it all possible. Find his website at www.karmi.cz.