Cookies
Diese Website verwendet Cookies und ähnliche Technologien für Analyse- und Marketingzwecke. Durch Auswahl von Akzeptieren stimmen Sie der Nutzung zu, alternativ können Sie die Nutzung auch ablehnen. Details zur Verwendung Ihrer Daten finden Sie in unseren Datenschutz­hinweisen, dort können Sie Ihre Einstellungen auch jederzeit anpassen.

Engineering

Zweitag at EuRuKo 2015
Minuten Lesezeit
Blog Post - Zweitag at EuRuKo 2015
Patrick Oscity

This year’s EuRuKo took place at the Salzburg Congress, which is located in the city center of Salzburg. We arrived by train on Friday and since there was no official pre-party, we took the opportunity to meet some friends from Berlin for dinner at Urban Keller. The conference started on Saturday, where we picked up our badges and t-shirts and then spent the whole day at the venue. At the end of day one, there was an official after-party at a place called Fuxn where we had the opportunity to meet some of the other attendees and speakers while enjoying delicious free food and beer. Day two was packed with great talks as well and ended with the voting for the city of next year’s host city. In the evening, we had some tasty burgers at Burgerista and finally took the train back home on Monday.

Yukihiro Matsumoto: Keynote

In his talk, Yukihiro shared some of the ideas he has for the future of Ruby. His talk was sprinkled with some amusing Japanese lessons, which he interjected in order to prove his point that concurrency is hard. Most importantly, he noted that Ruby will need to get better at concurrency. Several years ago, a single core approach might have been perfectly fine, but today’s computers are equipped with increasingly more CPU cores. He went on to briefly explain how others handle concurrency using actors and immutability, but at this stage it remains unclear which approach will fit Ruby best. Currently, he is using his new experimental programming language called streem as a playground to explore new ideas.

Joseph Wilk: Programming as a performance

Joseph started his inspiring talk with a brief overview of some of the things that are going on at the intersection of arts and computing. The possibilities are endless, which he demonstrated with great examples, including Brainfuck „poetry“, Hacking Choreography and a performance of the Cybernetic Orchestra. The grand finale of his talk was an impressive live coding session. Using the open source software Sonic Pi, he created atmospheric sounds and interesting visuals on the fly. (video)

Lydia Krupp-Hunter: Ruby Game Building Throwdown

Lydia showed us how to use Ruby for building basic computer games. Specifically, she introduced us to a few gems that can be used to build games: gosu provides the game loop and primitives for drawing items on the screen, hasu extends gosu with some convenience wrappers and hot code loading, and chipmunk is the physics engine that brings her games to life. She demoed a little game with „plant physics“ that showed some of the capabilities of the aforementioned gems. It was certainly interesting to see what can be done with Ruby in the GUI since we often tend to think of Ruby as a language that is only useful for writing web backend servers. She finished her talk with a brief introduction to ActionCable, the websockets library which will soon be part of Rails, and some ideas how this could be used to build browser games.

René Föhring: One Inch at a Time - How to get people excited about inline docs

René’s talk was about raising awareness for the importance of inline documentation in the Ruby community. Many of us follow the mantra that good code documents itself, but in some cases the code alone is not enough. Even if you are not maintaining an open source project where others need to understand your code, your future self will thank you for documenting the complex parts of your app. It is often unclear where to start documenting existing codebases, and the current tools seem not to be very helpful. René set out to find metrics which reveal the spots that would benefit most from added documentation. His approach expresses quality in grades, which are simple to understand and less likely to encourage useless micro-optimizations. The possible grades are A (good), B (room for improvement), C (error – when the docs no longer match the code) and U undocumented – neutral, because some things are not worth documenting). He built a slick command line tool called inch, which gives you a documentation quality report right from the shell. In order to encourage continuous improvements, he started a service called Inch CI which works much like Travis CI for documentation. The service also provides badges that you can tack onto your project’s Readme. It was great to see how much thought and passion he put into his project: the psychology behind the grades, easy to use interfaces, and his efforts to get the community excited about the topic. Now it’s up to us to go out and write some great documentation! (slides)

Koichi Sasada: Lightweight Method Dispatch on MRI

Koichi, member of the Ruby core team, brought us up to speed with some of the latest improvements that made it into the current Ruby version 2.2, including the new hash syntax for complex symbols, several garbage collection optimizations, and speedups regarding keyword arguments. He noted that if you are using 2.2, you should stick to the latest version since 2.2.0 has some bugs related to symbol GC. He then went on to explain some of the new things in the upcoming Ruby version 2.3, which is scheduled for release around Christmas this year. He mentioned a new magic comment that will freeze all string literals, but most importantly he talked about the method dispatch optimizations he is currently working on. Especially simple function calls, which make up for 90% of the calls in a typical Ruby program, have a lot of room for performance improvements. He is also working on re-implementing internal parts such as the method table with custom data structures, which should make Ruby go even faster.

Richard Huang: Refactor ruby code based on AST

Richard spoke to us about ways to automatically rewrite Ruby code in order to automate tedious refactorings. He explained how some of the known tools that perform static analysis and code rewriting work, including flog, flay, brakeman and rails_best_practices. The first step these libraries perform is to convert Ruby code into an Abstract Syntax Tree (AST), which is a representation of the Ruby code that can easily be processed and transformed on the fly. After the analysis and transformation steps, the AST can then be converted back to actual Ruby code. Some libraries that can be used to obtain an AST are ruby_parser, ripper and parser, the last of which also supports transforming the AST back to ruby code. These tools seem kind of hard to use, so he introduced us to the synvert gem, which aims to lower the barrier for developers who need to build such tools. Finally, he demoed some of the things that were built using synvert, including automatic upgrades from RSpec 2 to 3 and even from Rails 3 to Rails 4. Every developer who has ever done such an upgrade by hand know the pain that is involved in this tedious and repetitive process – let’s all hope this will be a thing of the past! (slides)

Amy Wibowo: Fold, paper, scissors – an exploration of origiami's cut and fold problem

Amy introduced us to the fold-and-cut theorem which states that any shape consisting of straight lines can be cut by folding a single sheet of paper and one single straight cut. During a live demo she showed how to create a simple pumpkin shape with one single cut. After some historical background, that the first published references to folding and cutting could be found in a japanese book called Wakoku Chiyekurabe (Mathematical Contests) from 1721, Amy went on to describe the Straight skelton method which she implemented in Ruby. Using the Shoes! gem, she wrote a GUI application that can solve the problem for user defined shapes, returning a visual representation of the necessary folds to the user. (slides)

Simon Eskildsen: Super-Reliable Software

Simon is a passionate developer who works on site reliability, performance and infrastructure at Shopify. With 300 Million unique visitors Shopify is one of the biggest players in the e-commerce industry. He pointed out that any kind of system depends on a layer of hardware that can fail for a wide variety of reasons, which means that any system is likely to experience failures at some point. The idea behind super-reliable software is that even if something unexpected happens, we need to make sure that failures are as isolated as possible and do not affect the whole system. For example if a service handling user sessions goes down, the entire web site might be unresponsive. As a sane alternative, one could however degrade the system to a state where all users are logged out, but can still use the web site. Simon showed us great insights on how they introduce reliability at Shopify including a way to predict and test the whole stack. They use a resilience matrix to identify dependencies between systems and how these behave in case of failures. Specific scenarios can then be tested using toxiproxy, a proxy to simulate network and system outages. (slides)

Christopher Rigor: Cryptography for Rails Developers

Christopher explained the basics of symmetric and asymmetric cryptography and recapped some best practices regarding cryptography and Rails. He also showed some of the attacks that have been done on SSL/TLS including BEAST, POODLE, Heartbleed and FREAK. Because these attacks exist, he advised us to use SSLv23 as opposed to SSLv3 (vulnerable to POODLE) and TLS 1.2 in conjunction with AES-GCM and ECDHE to provide perfect forward secrecy. Unfortunately, the insecure default in Ruby’s OpenSSL library for certificate verification is VERIFY_NONE, which should be set to VERIFY_PEER. Finally, he showed some possibilities to encrypt data in Ruby with ActiveSupport::MessageEncryptor and the RbNaCl gem, which provide secure defaults instead of letting us make severe configuration mistakes like the core Ruby libraries do. (slides)

Conclusion

We definitely had a great time at EuRuKo 2015. The city of Salzburg was a great place for the conference, as was the Salzburg Conference Center. While some people criticized the lack of Ruby code in quite a few talks, we think it was a nice twist on the classic Ruby conferences. The overall quality of the talks was very high, and every attendee, regardless of their skill level or profession, could certainly learn some new and interesting things. It should be mentioned that the conference tickets were the relatively inexpensive, which opened up the event to a wider audience. Nevertheless, the line-up was great and everything was very well organized. Thank you to all the speakers, organizers, sponsors and attendees – and hopefully see you all next year in Sofia!

Ihr sucht den richtigen Partner für eure digitalen Vorhaben?

Lasst uns reden.