A couple of weeks ago Full Stack Fest took pIace in sunny Barcelona, a weeklong event about programming. Conferences like these give you so much to learn and think about. It’s a great way to meet like-minded developers and heroes in the community, plus it gives you lots of inspiration and energy for your daily job.
The most interesting parts for me were the talks about Ruby, Rails and HTTP/2 and thinking about how these could affect my day-to-day job. Here are some detailed insights about these upcoming versions and what they can mean for our projects.
The conference started with the keynote from Yukihiro Matsumoto (Matz in short), chief designer of the Ruby programming language. Ruby was released in 1995 and it’s current stable version is 2.2.3. A problem language designers face when developing a new version is called “second system syndrome”. This can happen when the new version is over engineered, rewritten entirely, or stalled from release for too long. Matz’ goal is to not let this happen to Ruby. His rules to achieve this are: never start from scratch but improve and replace one-by-one, don’t let the version numbers scare you, and have some migration bait for developers so they all want to upgrade (performance is always a big one). For Ruby 3, for which development started in 2014, three mayor ideas were presented:
For developers working with a programming language it’s nice if the language just makes you feel at home and provides nice little features and possibilities to improve development speed and quality. Static typing can be a foundation in a language to improve man machine collaboration. But Ruby is not statically typed and reading between the lines of Matz’ talk, it won’t be in the future. He feels it’s basically a violation against the “don’t repeat yourself” principle which stands highly in the Ruby community and it will make Ruby less dynamic. But of course statically typed programming languages also have advantages over dynamically typed languages. Problems with wrongly assigned variables or methods not returning the expected types can be detected a lot sooner than at runtime. It would also allow for inline documentation and type or variable hints in our programming environment.
A concept Matz does like is called soft typing, which basically could give these advantages to the otherwise dynamic Ruby language. Soft type checking, or “best-effort” type checking, would infer a type from variable assignments and methods signatures to be able to see exceptions.
Ruby is an interpreted language instead of a compiled language, which comes with a performance loss. To improve Ruby’s performance Matz is looking at JIT compilation, which could result in speed improvements of 2 - 4 times. JIT is “just in time” compilation of the Ruby code to native machine code at runtime. It looks at methods in your code that are called frequently (hotspots) and will queue those methods to be compiled. But the tracing JIT that is being tried out now has the problem of consuming a lot of memory. Especially combined with Rails applications which are known to consume a fair amount of memory as well. But there are more ideas left, so there is good hope some form of JIT compilation could speed up our apps in a future version.
When the Ruby language was designed computers had only one CPU. Nowadays we have multiple cores and to utilize these we need concurrency. At this time Ruby can use other cores for IO operations, but for the rest Ruby can only execute code on one core at a time because of the global interpreter lock that is implemented in the language. This technique is in place to make sure the executed code and data is safe from modification so no unexpected behavior will occur. Although concurrency and thread-safety is very complex the Ruby team is working on implementing these. They already created an experimental language called Streem as a proof of concept for a possible concurrency model for Ruby. Also JRuby and Rubinius, two other implementations of the Ruby language, are already concurrent. So it’s just a matter of time Ruby will support concurrency.
Along with lots of other improvements, Rails 5 (expected in Q1/2 of 2016) will come with Action Cable, Turbolinks 3 and Rails API merged in core Rails.
David Heinemeier Hansson, creator of Ruby on Rails and founder of Basecamp, extracted Action Cable from Basecamp and will include it in Rails 5. The Action Cable framework provides an open and two-way streaming connection to the browser using web sockets. This can be used everywhere in sites and applications where you want to show real-time data.
Turbolinks is a feature in Rails which is tricky, but can be very powerful. If implemented the user will experience a noticeable speed improvement. This is accomplished using some smart JavaScript and DOM manipulation techniques which results in less data needed from the server, less time compiling the JavaScript and CSS, and less time needed for rendering what you see in your browser. In short: if you click on a link, the current page is kept intact, but the <body> (and the title) is replaced by the target page content.
The new version of Turbolinks will be even smarter and doesn’t require the entire new page to load, but just the parts that are changed: partial updates.
Sometimes you don’t need the entire Rails framework. The Rails API provides a subset of all the Rails features with trimmed down controllers, less middleware etc. The main purpose is to be able to create your own API applications which can provide data to other systems, frontends or mobile apps. Frontends can include JavaScript frameworks like AngularJS or Backbone.js.
At the conference Aaron Patterson, member of both the Ruby and the Rails core team, talked about the request and response lifecycle in Rails, combined with HTTP/2, from an app developer’s perspective.
A short intro to HTTP/2; The new specification was published in May 2015 following up HTTP 1.1 from 1997. If you are interested you can read the full specification in RFC7540. It’s based largely on SPDY, which was developed by Google to create a faster and safer web protocol. At this time most major browsers support the new specification and if the client doesn’t have support, the server falls back to HTTP 1.1.
Some key features of HTTP/2 are:
Multiplexing provides multiple requests and responses going over one socket. This reduces a lot of overhead and allows loading of a full page and it’s assets (images, scripts, styles etc.) all over the same open connection between the client and the server.
Server push gives the possibility to pre-send assets that the browser needs instead of having to wait for the browser to parse the HTML and asking for the assets.
When can we use HTTP/2? Our webservers run on NGINX to serve our websites and webapplications. NGINX 1.9.5 added HTTP/2 support on September 22nd which we started testing on our staging servers and will be rolled out on our production servers if found stable. This will allow use us to use some of the new HTTP/2 features. Server push is not supported yet and probably needs to be supported on the application level as well, so we will have to wait a bit longer for this feature.
These were some of the highlights from talks at Full Stack Fest and I look forward to implementing these new features in the coming months, making our projects perform better than ever.