Category: Education

EuRuKo 2015 Review – conference in a nutshell

EuRuKo has just ended. After 7 hours of driving we're finally home. I guess, it’s a good time to summarize and review the last days on one of the best Ruby conferences in Europe.

Arriving in Salzburg

Before we jump into talks/lightning talks, let me start with Salzburg: what an amazing town! No wonder Humboldt considered it one of the most beautiful in the world next to such pearls like Neaples. I wish we had arrived 1-2 days earlier. We would spend a lot more time sightseeing and enjoying really good Austrian cuisine.

For those who don't know, Salzburg is the fourth-largest (148,420) city in Austria and the capital of the federal state of Salzburg.

It takes about 7-8 hours to get there from Cracow (by car). Since Austria has really good highways, driving there was a pretty nice experience. Salzburg's old town is internationally renowned for its baroque architecture and is one of the best-preserved city centers north of the Alps. The only thing that I would change about it was the temperature and humidity ;). If you weren't there during EuRuKo it is still worth visiting.

DSC_3996DSC_4071

Salzburg Congress building and surroundings

EuRuKo took place at the Salzburg Congress building at Auerspergstraße 6. This congress center is located near the old town, so during the lunch break, there was enough time to try out some local cuisine (and to do a bit of sightseeing). I can't say a bad thing about the location and general organization. Everything was almost on time, the stuff was friendly, there was enough coffee and sweets, so there's almost nothing I can complain about. But, there are still two "buts":

  • Not enough Internet - the internet connection was really, really bad (pings up to 5000 ms). I can imagine that it is not super-easy to prepare infrastructure for so many IT people, however organizers should just assume 2 WIFI devices per person and organize everything, keeping that in the backs of their heads.
  • Not enough power cords - same as the one above. I know that we all have laptopts that run 6-10 hours on a battery, however there are clumsy people like me, that forget to charge it beforehand ;)

DSC_3537

Day 1 Speeches

Matz - Keynote

What can you say about Matz presentations if not: "really good". He spoke about some interesting stuff that the Ruby Core team is planning to add to Ruby. He also said that despite the fact that everyone knows that we need better concurrency and parallelism  solutions, it is yet unclear what kind of approach Ruby Core team will take. @cyberpoet summarized this speech really well:

Tl;dr #matzkeynote Ruby concurrency needs to get better. We have looked at how others do it. We have no plan yet. #euruko

Joseph Wilk - Programming as a Performance

A totally different point of view on a programming. Joseph showed (and proved by developing music live) that programming can become a key part of an art performance. Did I think about programming by dancing before what I saw? Never. Do I consider that now? Definitely!

Bradley Grzesiak: Simplify Challenging Software Problems with Rocket Science

I often hear from my programming friends this sentence:

Oh come on, it can be done. It's not rocket science.

But this time it was. It turns out that "doing" rocket science is not that different from "doing" programs and programming. Bradley showed many techniques and tools that have been developed for aerospace engineers to help them solve problems. It was really inspiring to learn that their tools and a way of working does not differ that much from what the software developers use to simplify and automate their work.

Satoshi Tagomori - Data Analytics Service Company and Its Ruby Usage

IMHO the most interesting speech during the whole conference. I would just change its title or remove "Ruby" out of it. "Ruby" wasn't the main topic. It was more about the infrastructure, open source software and other solutions that Satoshi uses in Treasure Data company. Sure, he mentioned that they use MRI (CRuby) and JRuby here and there, but many people that I've talked during the after-party expected more Ruby vs Data Analytics things.

Zrzut ekranu z 2015-10-19 14:13:21

It was really, really interesting to hear from Satoshi how they structured (on a high level) their whole system to handle 50 bilion new records per day, how they are able to sustain the whole infrastructure and what are the key components of their software stack. It was also really inspiring to see a company that is based mostly on OSS solutions. Big plus for Big Data ;)

Lydia Krupp-Hunter - Ruby Game Building Throwdown

I won't lie: I didn't attend this one - Salzburg won.

Hanneli Tavante - Humanising Math and Physics on Computer Science

TL;DR: "I will teach you how to teach". And this is the core of the topic. Hanneli talked about making boring things interesting by combining them with way more interesting things (like programming!). This is a must see for anyone who wants to teach other people. Luckily she did this speech also @ eurocamp 2015 so you can see it here:

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

The next subject that I strongly identify with because of PolishGeeks Dev Tools. René found a more humane way to encourage programmers to document their code. If you want to see how to do this, just visit the Inch CI website and play with it.

Lightning talks

I don't remember speakers names or subjects but I had one general feeling about the lightning talks: not enough Ruby there. Some advertisement, some funny things but where were you Ruby lang?

Day 2

Koichi Sasada - Lightweight Method Dispatch on MRI

A really interesting talk! It seems that in terms of topics, Japanese speakers totally ruled @ EuRuKo. Speeding up method dispatch by introducing a caching layer can be a really good move. Same goes about improvements added to dispatching methods with keyword arguments. The only thing that worries me is a lack of statistical research on how the whole community uses Ruby. I feel that RDoc and internal Ruby usage inside Ruby development team might not be enough. Maybe if we would look deeper into how people use Ruby, the Ruby Core team could discover more places that could benefit from extra optimization.

Richard Huang - Refactor ruby code based on AST

A super useful talk, too bad that I knew nothing about this during the Rails 2 -> Rails 3 migration. Automatic refactoring based on the AST (abstract syntax tree) will be definitely used by me in case of any bigger gems/libraries API changes.

Michał Taszycki - Learn to program Commodore 64 this year!

I didn't attend it.

Tworit Kumar Dash - RFID Technology with Internet of Things

Well to be honest, the RFID Technology is not exactly what makes me exited but I must say: Tworit had a really interesting speech and he showed how he uses Ruby together with RFID to collect really interesting data and connect the low level hardware world with higher level abstractions.

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

Did you know about fold and cut theorem? It states that it is possible, given a piece of paper and any polygonal shape, to find a series of folds of that paper such that the given shape can be generated with a single cut. Some say that whatever you can imaging, there's probably already someone doing that. And for fold and cut theorem there's Amy! She's not only doing that, but she's also doing that using Ruby. Despite the fact that it is a scientific theorem - for me, when Amy demonstrated this, still felt like kind of magic ;)

Simon Eskildsen - Super-Reliable Software

For me, the main idea of this presentation is: Everything can and will fail. It is just a matter of time. However, in software development it is more about trying to figure out all the points of failure and making sure that when something bad happens, it won't have a critical impact on the whole infrastructure. Simon told us how they deal with serious problems with parts of their infrastructure and how we can try to predict (and test) various scenarios including those with the key components failing.

 

Zrzut ekranu z 2015-10-19 16:18:41

Christopher Rigor - Cryptography for Rails Developers

I didn't attend it - had to get back to Poland :(

Summary

More than decent but not perfect. It's another Ruby conference that leaves me with mixed feelings because of many speeches not related to Ruby. Does it mean that there's nothing really interesting going on that is directly related to Ruby? I don't think so. Does it mean that people expect less technical talks? Maybe. But is that a good enough reason to pick so many (good) talks that are only slightly related to Ruby on a Ruby conference?

Exceptions should not be expected – stop using them for control flow (or any other logic handling) in Ruby

If your exceptions aren't exceptions but expectations, you're doing it wrong. Here's an example what programmers tend to do:

def validate_status(user)
  case user.status
    when 'active' then return user
    when 'inactive' then fail InactiveUserError
    when 'invalid' then fail InvalidUserError
    when 'deleted' then fail DeletedUserError
    else
      fail UnknownUserStatusError
  end
end

begin
  validate_status(user)
rescue InactiveUserError
  # do something
rescue InvalidUserError
  # do something else
rescue DeletedUserError
  # do something else 2
rescue UnknownUserStatusError
  # do something else 3
end

I've seen also few cases, when exceptions parameters were used to pass objects that the programmer was later on working with!

As you can see, the whole flow of this piece of code is handled with exceptions. In this post I will focus on a performance reason why it is bad, (but if you're interested in how to refactor code like this, at the end of this post you will find some external links about that. That's why I've prepared a simple benchmark

require 'benchmark'

elements = [0, 1]
big_ar = (1..10000).to_a

TIMES = 100000

Benchmark.bmbm do |x|
  x.report('break') do
    TIMES.times do
      elements.each do |i|
        break
      end
    end
  end

  x.report('catch throw') do
    TIMES.times do
      catch(:benchmarking) do
        elements.each do |i|
          throw(:benchmarking)
        end
      end
    end
  end

  x.report('catch throw heavy') do
    TIMES.times do
      catch(:benchmarking) do
        elements.each do |i|
          throw(:benchmarking, big_ar)
        end
      end
    end
  end

  x.report('fail') do
    TIMES.times do
      begin
       elements.each do |i|
         fail StandardError
       end
      rescue
      end
    end
  end

  x.report('fail heavy') do
    TIMES.times do
      begin
       elements.each do |i|
         fail StandardError, big_ar, {}
       end
      rescue
      end
    end
  end

  x.report('raise') do
    TIMES.times do
      begin
       elements.each do |i|
         raise StandardError
       end
      rescue
      end
    end
  end

  x.report('raise heavy') do
    TIMES.times do
      begin
       elements.each do |i|
         raise StandardError, big_ar, {}
       end
      rescue
      end
    end
  end
end
ruby benchmark.rb

                        user     system      total        real
break               0.040000   0.000000   0.040000 (  0.040243)
catch throw         0.080000   0.000000   0.080000 (  0.082100)
catch throw heavy   0.080000   0.000000   0.080000 (  0.082422)
fail                0.300000   0.000000   0.300000 (  0.298863)
fail heavy          0.470000   0.000000   0.470000 (  0.476829)
raise               0.300000   0.000000   0.300000 (  0.305635)
raise heavy         0.480000   0.000000   0.480000 (  0.475377)

And this is how it looks on a chart:

time_taken

Based on this benchmark we can see following things:

  • Catch/throw performance is not influenced by the size of  passed attribute - it doesn't matter if we pass a huge structure or a simple object
  • Performance of fail and raise is almost equal, for both normal and heavy case
  • Fail/raise can be up to 12 times slower than break
  • Fail/raise can be up to 6 times slower than catch/throw

So, from the performance point of view, handling flow with exceptions can be much more expensive than in other ways. Exceptions are heavy because they are exceptions. They aren't suppose to happen all the time, that's why the implementers of compilers nor the designers of the language focus on their performance.

Refactoring

If you've noticed code like this in your apps, here are some great blog posts on how to fix that:

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑