Ruby on Rails
& Ruby Conf

When working on a Rails app with lots of users and a plethora of requests, you’ll likely soon be addressing how you can have dedicated custom hardware for them.

In this talk, I’ll go over my experiences and lessons learned from working on dedicated hardware for industrial catering services.

Ruby has been a dynamically typed language for 26 years, but it will change next year. Matz declared Ruby3 will give an option for type checking and you would be interested in how the Ruby programming will change.

In this talk, I will explain the overview of “Ruby3 & types project”, the team, goal, and current status. I also will introduce my type checker called Steep and let you know how the Ruby programming experience with type checker will be.

TensorFlow(http://tensorflow.org/) is an extraordinary open-source software library for numerical computation using data flow graphs. It was originally developed by researchers and engineers working on the Google Brain Team within Google’s Machine Intelligence research organization for the purpose of conducting machine learning and deep neural networks research, but the system is general enough to be applicable in a wide variety of other domains as well. TensorFlow comes with an easy to use Python interface and a C++ interface to build and execute your computational graphs. However, it is available only in Python, and due to the strong interest from the Ruby community, I took an interest in porting it. I worked on Ruby API with support from Somatic.io and SciRuby foundation and came across some cool things that I would like to share with you.

Event sourcing is a hot topic in Ruby community lately. But usually at conferences we just get a scratching-the-surface intro. This, in turn, is a story of building a event-sourcing-based product for a production environment, processing millions of events per day.

We spend a big portion of our days doing Ruby, perhaps some of us write more Ruby than we do our native natural languages. Over the past few years, there is a noticed hype of criticising ruby as a programming language without stating solid arguments.

Sadly, the common tendency in our industry is to follow hypes without solid claims backing them. Therefore, I started my project of talking to influential people in the ruby community trying to deconstruct the hype and form a constructive list of problems we as ruby community believe should be addressed in order for us to move forward.

In this talk, I want to talk about the story of my project “What is wrong with ruby?” what is the progress so far? and what can we all do to contribute shaping the future of our technology stack.

Technology, at its core, is a tool. Each language has its own unique benefits and advantages. One thing Ruby is particularly excellent at is prototyping. It’s also easily accessible by non-technologists because of its human-readable syntax. This makes Ruby an extraordinary tool for prototyping impact projects, since impact projects (social housing, the environment, children’s hospital apps) usually require expertise from outside of technology. In this talk Naomi will share an impact project case study and highlight how Ruby’s was uniquely qualified and use for the project. You’ll also take away an understanding of how to introduce Ruby as the best tool in projects you want to work on in future.

A story of one commercial project grown with Hanami:
• Brief comparison major differences between Hanami and Ruby on Rails web apps
• Solving “well known” issues using Hanami and facing “now known yet”
• Recipes for what we used to with Rails: “doсkerization”, Trailblazer, background jobs, caching, WebSockets, etc.
• Vision of the ideal Hanami app, comparison with Elixir/Phoenix
• Hanami as a modular puzzle - an example of building somewhat exotic

Most of the Ruby projects we work on involve text-based protocols and formats: HTTP, HTML, CSS, JSON, SQL. The tooling for that is awesome. But what if we have to work with non-ASCII based protocols? In this talk I’d like to look at what tools are built in to Ruby, what gems are available, how we’re using them in production and what we learned. I will also show how to approach an overwhelming protocol spec and gradually implement the needed parts.

I have been successfully exploring the possibility of compiling ruby to binary, to remove the traditional downside of dynamic languages, namely (lack of) speed.
I will demonstrate the ability to compile ruby, detail this with an overview of the implementation, and outline what has been achieved and what the road ahead entails.
Also i want to elaborate on the possibilities this approach opens up for the community that go far beyond the speed benefits.

Microservices shine in many aspects, but testability. Whenever you deploy a service, no matter how small it is, as long as it has dependencies, you have to keep them in mind. By definition, microservices have lots of dependencies and makes you appreciate how easy it is to test integration in a monolithic code base. In this talk, I’ll show the concept of contract testing that makes testing microservices a breeze. I’ll do it on an example of Pact, an open source library with adapters for many popular languages.