This year, EuRuKo was hosted in Salzburg, Austria. We haven’t been to a Rails or Ruby conference since wroc_love.rb and we were pumped to go there! I’ll just remind you, that the previous EuRuKo was canceled for political reasons and to secure the safety of attendees.
Matz started with some history behind Ruby and how he began developing it on a machine with specifications that would sound like a joke nowadays: 16MHz, 8MB RAM, 158MB HDD. In his talk, the chief designer behind ruby focused mostly on concurrency. He first admitted that threads aren’t enough, because they were designed when multiple CPUs were a dream, and then explained that the problem needs to be thoroughly discussed on a higher level of abstraction. What does that means for us? In my opinion, the Ruby core team is looking at other languages that have already solved the issue and are thinking what to take from where. Matz showed that he cares about concurrency and that they’re experimenting with it, but we have to wait as no deadlines or roadmaps were presented. That sounded like he just wanted to buy some time before people switch to other platforms. On the other hand, he promised compatibility with Ruby 2.0.
I can’t forget to mention the Japanese lessons that were great breaks between parts that required focus and concentration. They were really fun!
Here we’ve got a show about Sonic Pi. Honestly, it was fun and all, but I have to say that, Nicolas Dermine at wroc_love covered it better. At EuRuKo, not a single line of code was really explained. Joseph showed us the possibility to perform, but Nicolas taught us how we can start. The music itself was more interesting, but that’s a matter of taste.
Bradley explained to us that rocket science doesn’t have to be that hard. The most common problem behind rocket science software is that we’re thinking programmatically when you actually have to think in a mathematical way. He then explained vectors and matrixes and went on to derivatives! With basic examples I think everyone could get the message that Bradley wanted to send - rocket science ain’t that hard, it’s just a bit of a different approach. We also learned that we can crush rockets using ruby! That has to be fun.
It was great to hear that ruby is getting some making games love. We learned that there’s an opportunity to do that in ruby. We all know that it’s not the most in demand skill on the market, but it might be fun and rewarding. Lydia wanted to show us that „Your tech stack doesn’t determine fun”. What’s more, it felt more like a workshop than a lecture, which was absolutely great!
René started off with explaining different in-line documentation like YARD or TomDoc. He was a first time speaker at such a conference, but I must admit, he sounded confident and very well prepared. Nowadays, our documentation or test coverage is calculated by dividing the documented or tested amount of eg. methods by the total amount, then it is illustrated by percentages. That system got smashed by René because everyone will always aim for 100%. We, developers, feel bad when we get 99%, or 95%. It’s a really good score, nearly the best possible. But that ‚nearly’ really hurts us. So, what’s better than that? René proposed a grading system, that he’s using in inch-ci. A bit similar to an educational system, with As and Bs, but there’s also a U - Undocumented. You can read more about it here (http://trivelop.de/inch/). But what the hell is inch-ci? It’s a docs measurement tool for Ruby. The main purpose is to grade our documentation. The presentation was well prepared and it was a good finish for day 1.
We were really waiting for day 2, as we were waiting for some more ruby staff, as most of the presentations were around ruby and not really ruby-related.
We got some info about the dispatch method and the logic behind it. The lecture was full of content and I’ll have to watch it again later to really understand it and think it through. There was one sentence, though, that I have to quote. But first, I’ll remind you that Koichi is a member of Matz’s team at Heroku.
I don’t remember what protected really does, it’s too complicated
The talk from Richard was about refactoring your code using ASTs. It really looks promising. If you have to rewrite your code, checkout synvert first. It can save you hours. Eg. it can help you convert your code from Rails 3.2 to 4.0 or use Ruby's new hash syntax.
For me, it was the best talk on EuRuKo this year. Really. The main message was that everything can fail. Also we shouldn’t forget that we build our system from some components, especially in the ruby world, and they can fail too. Simon went through every layer of an application and showed us that every layer can fail. It wasn't very optimistic, but eye-opening for sure. We’ll be joking about bit flips as an excuse for our mistakes for a long time. I think you should read about ToxiProxy and Semian. I’ll definitely be looking into them. The first one is a tool that simulates network and system conditions and helps us detect how our system is reacting. Semian, on the other hand, helps us control access to external services in order to avoid cascading failures. It’s Github’s readme is really thorough and descriptive. The main purpose is to fail faster. Simon also opened our eyes to the topic of application failing. The point here was that the application shouldn’t fail as a whole. With his example, when there are problems with a session, a user is simply logged out, it really makes sense to let the user browse the rest of the application, which in his case is a shop. I’m definitely going to look further into both of the gems.
The closing presentation was about cryptography and all the acronyms behind it. Concepts were well described - I have to say, I definitely learned something. Not to publish my private key.
A really big high five to all of the organizers. Everything was first class and we could completely focus on the talks. Thanks! And we’ll definitely visit Sofia for next year’s EuRuKo! While analyzing the conference on our way home, we became a bit dissapointed. There were some talks that didn't really relate to ruby or our work at all. Maybe I just expected a bit more. Especially after a great wroc_love earlier this year. I couldn't get the comparisions out of my head. But when I started writing this post, I really focused on what I've learned. With every paragraph, I was more and more convinced that it was worth it. I've definitely learned some things, but what’s more, I've learned the things that I want to learn.
PS. After reading the schedule for another Ruby conference in Europe, we’re considering going to Turin for RubyDay2015. Are you going?