Speakers

The cryptocurrency becomes popular in recent years. As a Rubyist, how can we deal with this technology? This talk will discuss blockchain, show an example using Ethereum's geth to direct operate blockchain and demo how to develop blockchain application.

Want to build a Bot without the hassle of provisioning and managing servers? Amazon’s got a service for that and it’s called AWS Lambda - it executes your code only when needed, scales automatically and you pay only for the compute time you consume.

There’s one problem with Lambda - it doesn’t support Ruby! Let’s checkout multiple options on how to build a Ruby Bot and package it into an executable which you can run on any machine without the need to actually have Ruby installed.

We've been debating on the concurrency solution of Ruby for several years. Numerous custom "evented" drivers have been built, but for most of these projects, developers are required to think in the "evented" way to get things work properly, which not only breaks the elegance of Ruby programming, but also greatly increases the complexity of the refactoring process.

We will then think in Ruby, looking for the solution to make your whole web application "evented" with great meta-programming features of Ruby language itself. So that, you could still concentrate on your business models while programming as usual, but the performance may boost to 5 times faster or more without any hesitation.

The Twelve-Factor App is a guideline for modern web app development. Kubernetes is an open-source project for container management that gives you great flexibility around application deployments. With containers and Kubernetes, you can deploy and rollback a version, scale out to hundreds of nodes, copy the same configuration to multiple prod, staging, and dev environments, manage deployments through API, and so on.

This talk will review each of the twelve factors using a simple Rails application as an example and see how Kubernetes helps you run your Rails application. Experience with containers is not required.

Writing a system alone is hard. Building a system with other people is harder. Building many systems with many people is hardest.

As our company has grown, we have tried many approaches to user-friendly, shared development environments and learned what works and what doesn't. We incorporated what we learned into a tool called devly. Devly is used to develop products at Fastly that span many services written in different languages.

We learned that the design of our tools must be guided by how teams work and communicate. To respond to these needs, Devly allows self-service, control, and safety so that developers can focus on their work.

Its better to appologize to one user for the app being down for one request rather than to appologize to 100 user for the app being slow. Circuit breakers are an age old technology which we use to save our hour from burning down, even if we are inconvenienced about it breaking light to one part of the house, we are going to use the same concept to make sure that one faulty code or small instantaneous increase in load doesn't bring down the application.

How do you install Ruby using any tools? There are various solutions such as installing the binary and building from the source package. Did you know how do these Ruby packages come from the Ruby core team? Did you know that you are being delivered to your hands?

For example, if you are using macOS, you think that you are using third party tools like rvm, ruby-build, ruby-install. If you use Windows, You can choose RubyInstaller on Windows. Finally, If you use Linux, You didn’t need third party tool. You only use standard package manager on Linux.

As standpoint of Ruby's Core team infrastructure, I will show you how Ruby's package was created and released at the time of release. In addition, I will introduce your selections of new Ruby experiences. Therefore, Ruby has a lot of build options for linking shared libraries, changing program name, and others. It’s a too complex thing. I will describe these details.

In finally, I will introduce what kind of things inside ruby-build as a famous build tool for Ruby. It has a mechanism of building. I will explain these mechanism. After that, You can choose a best environment and options for your ruby experiences used ruby-build and Ruby packages.

How many times did you run ruby directly except ruby -v for checking version? Ruby was the descendent of Perl, inherited many handy command line features. Such as easy file reading, various global variables and executing directly without file. Let's explore all sorts of little known Ruby Command Line features.

除了用 ruby -v 來檢查版本之外， 你曾經在 command line 直接執行過 Ruby 嗎? Ruby 作為 Perl 的接班人，延續了許多好用的 command line 功能。 像是方便的讀取檔案，各種實用的預設變數，不用檔案直接執行程式碼。 讓我們一起來探索各種鮮為人知的 Ruby 功能。

Humans and data science are flawed on their own. Humans lack the ability to process large volumes of information. Machines lack intuition, empathy, and nuance. You’ll learn how to guide users of expert-use systems by applying data science to their user experience. Layering data science within our systems allows us to take advantage of the human-touch while leveraging our large datasets. In this talk, you’ll learn the process for sprinkling data science into your applications, the challenges we have faced along the way, and how to measure the business impact.

In this workshop, you can learn the following four topics.

(1) Introduction to the data tools for Ruby (2) How to use pycall to integrate your Ruby scripts and Python's data tools (3) Using Ruby for machine learning (4) Summary and how to join the development of data tools

Le Tote has been using Elixir in production for over 2 years. In this talk, I'll touch on the practical problems and suggestions resulting from integrating Ruby on Rails and Elixir/Phoenix. I'll focus primarily on the technology with a few notes on team dynamics and infrastructure. I'll speak from the perspective of a Ruby developer who is new to, but interested in Elixir, and also a team lead managing both Ruby and Elixir developers.

One of the Ruby 3 goals is "better concurrency support". I will talk about the progress report of this goal. I had proposed new concurrency abstraction at RubyKaigi 2016, RubyConf 2016. Our new abstraction is safer than Thread and can run in parallel. This presentation will introduce concepts of our new abstraction and will show demonstration with preliminary implementation.

There are more and more web applications with multi-tenant features these days. Such as online forums and e-commerce stores. To accelerate the development, major web frameworks often have multi-tenant plugins for fast-developing prototypes. The gem "Apartment" is the most representative one for Rails applications. It provides fast and isolated multi-tenant environments by making use of PostgreSQL schema functionality. However, when the number of schemas is too large, the drawbacks of using multi-schema database often outweigh the advantages it brings. In this talk, I will share my experience on using Apartment in a production project with over 130000 database schemas, and how I save the system from being paralyzed by the huge number of schemas.

There are many use cases where the ActiveModel::Errors interface is tedious to use, such as message formatting and testing. This talk presents these cases, and explains why the limitation can be simply solved by taking an object-oriented approach, which results in the AdequateErrors gem. The gem's implementation is explained, and the talk will showcase examples on how it can make your coding life easier.

We all know what the acceptance testing is. However it is difficult to really adopt this into your real-life work. I want to show you how I introduce this technique and solve the problems.

As web applications grow in scale and complexity, people start realizing that many parts of their domain-specific code do not fit neatly into Rails’ MVC structure. In recent years certain patterns emerged that try to rectify this situation and this talk tried to shed some light on them. Additionally it will explore some of the newer additions to the Ruby web development scene, like Hanami and dry-rb.

RDoc has some steps for generating documents. First, lexical analysis for Ruby code. Second, parsing methods, classes, documentation comments and others from lexical items, and creating their objects. Third, building HTML and lexical analysis again for syntax highlighting of documented code. I'll introduce the internal steps of RDoc. I'll introduce modern Ruby lexical analyzer and parser for documentation.

It’s incredibly fulfilling to know your code makes a difference. But, when your code needs to move millions of dollars daily, it can be terrifying. Imagine how dreadful it is when you find a small bug that cost hundreds of millions of dollars. I’m on the payment engineering team at Gusto. We build systems that move money for people’s payrolls: money people depend their lives on. Come and hear me share how we build systems striving for correctness and robustness with Sidekiq and Slack bots. You will learn about best practices and engineering principles we distilled from past expensive lessons. They give us confidence in our code so we can sleep well at night.

I believe most of us love Ruby, but I also believe most of us don't think Ruby it's perfect. So what'd your own version of Ruby look like if you can create your own one?

As some of you may know, I created a language called Goby about a year ago. It's largely inspired by Ruby, and looks very similar to it. But it also have some design choices different than Ruby or have some unique features that Ruby doesn't have. In this talk I'm going to discuss some important things we should focus on when designing a language. And I will also share the design choices made when developing Goby, as well as the philosophy behind these choices.

In software engineering, repeating things is usually considered harmful. We start our projects with a testing framework to keep running tests without repeating manually. Instead of copy and paste a code snippet, we define a method to make our code structured. When we find ourselves repeating a code review suggestion several times, we try some automation!

This talk will cover the design and implementation of our review assistant tool, comparison with other LINT tools, and how our reviewing workflow has been changed.

In Ruby 2.6, we're planning to merge JIT compiler to MRI experimentally. In this talk, you'll see how it's going, and how it performs better.

When DevOps team was established in 2016, development teams in Rakuten Travel were working in silos. Development teams had had separate development processes (build-automation tool, release-automation tool, site-operation tool). Also the development environment which all teams used together had infrastructure restrictions and development processes which slowed down the development in the organization level.

DevOps team talked with each development teams and found issues to solve. Then DevOps team standardised the development processes by delivering software in the topic of System/Application Data Centralisation, Multiple Development Environment, High Availability, Data Visualisation, Table Definition Management. Most of our software is written in Ruby. After 2 years of DevOps activity, all development teams follow the standardised development process. Also, operational processes such as release automation and site operation are now consolidated to 1 team. As a result the productivity of our organisation improved dramatically.

In the process of developing software, DevOps team faced many issues. As many members did not have a developer background, we did not write unit-test for our Rails application. So we learned how to write rspec testcases and also introduced guard to achive TDD. Then, as the number of our Rails application increased, many duplicated codes exist such as getting server related information from cross-company internal API. So we learned to package duplicated code into rubygems and store it in internal gem repositories. When we faced a performance issue in our program, we tried to solve it by using multi-threading function. However Ruby was unfit for it and we ended up using Java instead.

Another important part of this DevOps activity was to adapt the standardised software to each development team. Development teams had their own development processes which were already efficient for them. So when we tried to adapt the software, while most development teams were supportive, some were not. In the latter case, we had to do many of the heavy lifting such as making code changes to the product code and testing products on our own. The most difficult part was actually creating testcases and executing testcases which are normally responsible by other development teams. This is mentally tough but very challenging part of DevOps activity.

Ruby has toolchains to parse Ruby code into abstract syntax trees (ASTs) and process. Software such as an IDE, a linter or a formatter) is buit on them. But do you know these toolchains can be useful for your own daily development? This talk will show you how to boost your development with AST toolchains.

In Rails 5.1, webpacker gem now directly supports Javascript front-end framework such as React and Angular. However, I am running React on the Docker environment without webpacker gem. React has many advantages for making dynamic views. Especially, One way flow provided by React is similar structure with Rails data flow. So It's easy to understanding for server side engineers.

In this session, I will explain the purpose of using React in View, Pros & Cons.