RubyConf_au According to a Noob - Day 1 Part 2

Posted on 13 February 2017

Second half of day one of RubyConf_au! I really want to try organise my notes into these blog posts before my notes become more inscrutable as memory fades - so here goes!

Open Source: The Power and the passion

Pat’s talk was a thoughtful and reflective piece on the state of open source software. He opened with a quote from Nadia Eghbal Modern open source is about 1) building and 2) collaborating in public.

Pat talked about some of the great things about open source. For many of us, creating is a source of joy. Open source is also a productivity boost. May of our tools come from open source. They’re not perfect - but this also gives us the option to fix them when they don’t work. Open source also gives us a sense of community.

Pat discussed some of the barriers to contributing to open source software. He used a quote from Sarah Mei to illustrate this

When we recognise that not everyone is in the position to contribute to open source it becomes apparent that using github contributions as a hiring metric is going to exclude certain people.

Pat also discussed entitlement amongst people who use open source software, with many people in the twitter hashtag agreeing that they had experienced entitled jerks in the process of supporting their creations. Additionally, there is the costs of servers and developers for services such as rubygems.org

We do a poor job of recognising and compensating emotional labour involved in software. Pat referenced a Jacob Thornton analogy - open source is not free as in “free beer” or “free speech”, it’s free as in “puppy”.

Pat made the case for a ruby tax. Being free has it’s benefits - especially the low barrier to entry. But the benefit of a tax is that it allows people to contribute at different levels. He also raised the possibility of companies allowing their devs to work on open source on company time.

Most of the talk was geared towards people already contributing to open source - but what about newbies (like me!) who haven’t yet contributed? It can be a pretty daunting task. Pat’s advice is to go for low hanging fruit first, like documentation improvement or bug reports. Also “Your First Pull Request” which is a resource I’ll be checking out.

I appreciated Pat’s ending note. Without actively thinking about the best way forward, a diversity debt will be created in the same way that one creates a tech debt. And if one defers it until later they will have a bigger and more difficult task to solve.

Functional Programming for the Anxious developer

Julian Doherty’s talks honestly about anxiety at the beginning of his talk. As someone with anxiety I appreciated the open and honest talk about it. He linked to several resources, and pointed out that if you think you don’t need help it’s very possible that you do - which has been true in my experience.

He tells the story of a plucky young developer and a scaling project. Anxiety can be analysis paralysis - as programmers there’s so much that can go wrong that we can lose our ability to reason about them. Outages produce the same “fight or flight” response that “maybe lions” produced in our hunter gatherer ancestors.

Functional Programming is 1) Values and 2) Pure Functions. Immutability means that instead of changing an object, a function creates a new object. Julian suggests that this is a way to reduce anxiety, less things to go wrong.

Functional programming is something I’d like to look into more over the next few days as most of what I’ve done has been object oriented.

Actors in Ruby! Why Let Elixir Have All The Fun?

Marcos Castillo da Costa Matos talk was on a subject I hadn’t come across much - so I hope my notes make sense.

He opened on the subject of concurrency - when you ask a ruby dev about concurrency they have four possible answers.

1. I use Unicorn!
   • ie. Relying on a gem to do it for you
2. Of course not!
   • Ruby is not buit for that
3. I can spin up a new AWS instance
   • ie. The startup response
4. Have you tried Elixir?

Marcos then went on to talk about the Global Interpreter Lock - something which I know exists but I don’t understand all the intricacies and implications of. So that’s one topic for further reading for me.

Next Marcos went on to talk about using Celluloid to create an active object running within a thread which is termed an actor. This is something else I’ve marked for further reading.

The Power ⚡️ And Responsibility 😓 Of Unicode Adoption ✨

Katie McLaughlin presented a very enjoyable talk on unicode and emojis.

Katie points out that we should all be using UTF-8, and launched into a discussion of the history of emojis - which I had no idea about. Apparently they were a popular feature on pagers in Japan - so when Apple were making a smart phone for the Japanese market they created emojis. It was a hidden menu on iPhones in other markets for a while - until people started discovering them and sending them to each other.

Now, we can even set variables to emojis - and it looks like markdown supports them too while I’m writing this. They can also be used in git commit messages.

Incidentally, one of her tweets in the morning was shown on one of the MCEC screens - but whichever program was used to do so did not parse the unicode for the emoji in it correctly - resulting in a seemingly random string at the end of her tweet. This provided some interesting extra material for her talk.

The Unicode consortium decides which emoji are included - and Katie goes into some of the reasons an emoji may or may not be approved. She also talks about how different platforms render emojis differently, and brings up some of the funniest failure points - such as Android’s hairy “yellow heart”. This also means that emoji will have a different semantic meaning on different platforms.

She also comes down firmly that party parrot is not an emoji. Having it act as one hurts cross compatibility - as people expect similar functionality across platforms.

Katie has also created emojificate which is a small piece of code to make emojis accessible to screen readers - super useful.

Persistence Pays off: A New Look at rom-rb

I have to admit that by the last talk of the day I was a bit tired and my notes are a bit lacking. This is high on my list of talks to got back to and watch again once the video is uploaded.

Piotr Solnica gave a talk on rom-rb which covered:

1. Why rom-rb was created
2. How does it work?
3. How does it differ from typical ruby gems?
4. And the philosophy behind it.

rom-rb was created to separate persistence from the domain layer. ActiveRecord makes the assumption that your database schema is, more or a less, your domain model. How we store data is optimised for our database but not necessarily our applications.

I haven’t worked on anything large enough to have run into this problem personally - but it was still interesting to listen to.

Piotr makes the point that application data is the most important part of your system, and that data integrity is crucial for healthy applications. He says that OOP treats data as ugly and tries to hide it.

rom-rb was created to address common problems in Ruby ORMs.

At this point Piotr got into how ron-rb worked - which I is another topic I want to read more on. So much learning after RubyConf!

Well that’s my notes for the rest of day one! Hopefully I’ll get to my day two notes soon.