RUG::B

Many software projects follow their own versioning scheme. Before you actually use the software, you go ahead and read up how their versioning scheme is working, which versions are compatible to which versions, which are meant for development purposes only, which are safe to use and most importantly which introduce breaking changes. When you upgrade existing software, you find yourself often in the position to ask "Can I safely upgrade this library to that version? Does this break anything?”. Finding an answer here can be very tedious for a big software project using many libraries.

As a software author you always ask yourselves the same question when you release: “What is the version number for the next release?”

Semantic versioning introduces a set of rules which help you as a software author to pick the right number. No need to think about this for hours anymore. For the users of your software it also gets a lot easier. They’re able to define rules for their package managers which updates are safe to perform and which are not. This allows them to update their libraries without problems.

The largest e-commerce Rails engine in Existence, SpreeCommerce, was built in North America. North America has different rules for taxing Sales on-line than Germany (most of the rest of the world, actually).

For a client I had to refactor Spree's taxation system so that it can do some of the weirder things Germany / the EU need. This is a fascinating story with lots of funny code!

In October 2015, Spree Commerce Inc. ceased maintaining SpreeCommerce. As a result, a large part of the community moved to the fork Solidus - but my code hadn't. So I embarked on a side project to refactor taxes there as well, given I'd done it once before, and this time do a better job at it.

This talk is great for - first-time contributors (because I didn't have a lot of GitHub bathroom tiles when I started this) - anyone working with large legacy codebases (because it has some fun insights on what to do and what to avoid) - Ruby trivia addicts (because there's some really really undecipherable code in there)

I will give this talk at SolidusConf in May this year. The Rug::B edition would be somewhat reduced in scope, as I can't expect the audience to be as familiar with the codebase. It is a technical talk, by all means.

Taxes are, btw, boring. Doing them well in Ruby - not so much!

Elixir and Phoenix are all the hype lately - what's great about them? Is there more to them than "just" fast, concurrent and reliable?

This talk will give a short intro into both Elixir and Phoenix, highlighting strengths, differences from Ruby/Rails and weaknesses.