RubyC 2017 – Kiev Thoughts

I’m still in Kiev, Ukraine right now and I had the opportunity to attend RubyC 2017 conference over the weekend.

Despite having written Ruby professionally for a few years now, this was my first Ruby related conference. The tickets were only $100 so I figured that it would be a great opportunity to attend a software development conference as well as doing something productive and career related over the weekend.

Both Ruby and Ruby on Rails is over 10 years old at this point and one can make the argument that both the programming language and the web framework are both stable and mature. Due to it, the language has been “evolving” so to speak for the last few years and not too many ground breaking changes and/or features have been introduced. Also, the reason Ruby became popular at all is due to the rising (and eventual dominance) of Ruby on Rails. Ruby on Rails is essentially the “elephant” in the room. In fact, this was emphasized in many of the talks that were presented at the conference.

Pouches for speakers to sit for open talk session

One of the talks that I found to be the most thought provoking was “Ruby 4.0: To Infinity and Beyond” by Bozhidar Batso. He’s apparently the author of RuboCop which I found to be impressive. I love that library  as it helps me write cleaner code and makes me adhere to the basic programming and syntactical that I set for myself.

One thing Bozhidar Batso mentioned was that not much has changed in the last few version of Ruby. He had a few slides where he listed the major list of changes from Ruby 2.0 – 2.4 (I think he started from 2.0) and he did have a point in that each release since Ruby 2.0 has been incremental. In fact, the only change that I could think of that has been made from Ruby 2.3 – 2.4 (and this was listed in Bozhidar’s slide) was the unification of Fixnum and Bignum into the Integer class which generated a lot of deprecation warnings in some gems. Aside from that, nothing major sticks out in my mind.

Bozhidar also mentioned that Ruby is the only programming language where certain features and changes made are driven by the web framework that dominates the language, in our case Ruby on Rails. He mentioned how insane this is and a web framework shouldn’t influence the design of the programming language that it’s written in. He had a point there, but this made me notice that there was a lot of, “WE NEED AN ALTERNATIVE TO RAILS” mentality not only in the speakers but also by a lot of the audience. For example, when a statement about some negative aspects of ActiveRecord was mentioned, there were a few cheers made by the audience.

This is something I do not understand. The fact that as soon as something gets popular, we humans have a natural tendency to immediately start hating on it. This doesn’t just happen in technology stacks but even in coffee chains in Starbucks. How many times have you heard Americans say that they hate Starbucks and the coffee served is terrible? I personally think Starbucks coffee is pretty good, especially if you get it fresh in the morning. It’s strong and consistent.

Same goes for Ruby on Rails. As soon as it became the default go-to web framework for Ruby, there have been many talks about the need to replace it and that it’s inappropriate that something so dominant. During the conference, the Hanami web framework was proposed as something that could give Rails some competition.

Personally, I like Ruby on Rails. I think it’s well designed, easy to work with, and the most productive web framework in the market right now. Is it perfect? No, of course not. But is it a good tool for building web applications? Yes, it’s excellent.

There was an open talk session where the audience had an opportunity to ask the speakers any questions they had. One of the speakers mentioned that despite other speakers demoting Ruby on Rails and promoting something else, if he was the one paying for the software project, he would go with Ruby on Rails every time due to its emphasis on productivity and set of sane default configurations that it comes with. I completely agree with this. If I’m paying other developers to write a web application, I’m going to go with whatever is most productive and gets the job done in a timely manner with reasonable code quality. Also, due to its convention over configuration philosophy, new developers on the team can get acquainted with the codebase very quickly. Despite being over 10 years old, Ruby on Rails still hits on these points better than other technology stacks out there.

The speaker who gave the answer in terms of, “If I’m putting up my own money…”made me think of a training curriculum that all software developers should be required to go through. I think all software developers should have to go through a phase in their career where they have to manage a project from beginning to completion and through maintenance cycles where the team members are switched once every few months. Essentially, the training regimen should replicate a professional work environment as much as possible. I think a lot of software developers put too much emphasis on the engineering aspects of software development rather than the pragmatic side of it. Maybe, the training regiment should also include a portion where the participant loses money if he/she doesn’t complete the training regiment successfully. I’m willing to bet that a lot of participants will opt for tried and true technologies like Ruby on Rails than to Hanami or “enter the cool new shiny programming language/framework of the week” if their own money on was on the line.

About the Author Chris Jeon

Software developer currently focusing on Android development.