Video recording and production done by Svitla Systems
It's not a secret, that Ruby is a powerful, super flexible and at the same time extremely laconic language. Ruby on Rails is the most popular framework for web applications, and it certainly deserves its honour. But as you may already know, there is no silver bullet, and every tool fits best for a certain type of tasks. And Rails is not an exception. In this topic I'm going to tell about criteria of good and bad architectures, common approaches of good architecture and how to apply them in the ruby ecosystem. We will go through the basics: a heart of software development, intention-revealing programming, SOLID principles and TDD, and will end with more advanced technics such as domain-driven design and functional programming. The overview will come with examples and resources applicable to the ruby ecosystem.
Growing communities is all about activating untapped potential. Typically, this is done by creating expensive advertisement campaigns or hiring community managers. But this is hard for free and open-source projects: Usually, both money and time are scarce resources. The effects of this are often visible: overworked maintainers, a constantly growing number of open issues and glacial response times. This leads to a spiral: potential helping hands turn away from the project, even if they continue using it. For that reason, thinking about growing community early is important for all projects. This talk is going to present effective, inexpensive and time-saving approaches to tap into community potential for projects of many sizes, collected as part of the Rust community team, the work at Ruby Berlin e.V. and within the Padrino framework. It will also explain base techniques to get creative with community action.
Ok, Everybody knows it, microservice is great. I am confident on this too, for 5 years the all Clever Cloud architecture is based on it. But, as all the new trendy buzzword, it’s not a silver bullet, and there is several problems to manage. One is the authentication, distributed authentication is hard, and there is many ways to achieve it. Configuration is the second issue to be managed when dealing with distributed micro application strategy. This talk is a concrete return of experience to build a strategy on microservice and problems we will have to deal on this occasion.
We’ve come a long way with rom-rb and changed the way people can work with data in Ruby. In this talk I’ll introduce you to rom-rb and explain why this alternative way works better than Active Record. We’ll take a look at functional data processing, flexible data transformations, altering data using changesets and the importance of type-safety. You’ll see how rom-rb is evolving and where we’re going with this big effort!
DB optimizations is a topic that 10% of speakers touch in some way. But some of them are focused on the best Database or Hardware configuration. I will try to be more specific on the application side and show how to optimize queries using different techniques: from avoiding the query completely to in-depth SQL query execution guides.
ERROR: Failed to build gem native extension" - every ruby developer encounters this some time at his/her career. But have you ever wondered how many gems uses native extensions? What kind of dependencies a gem requires? Have you ever struggled searching what system library gem needs? What package in your OS provides it?
Have you ever dreamed of a programming language which is as beautiful as Ruby yet as fast as C? Enter Crystal, a Ruby inspired programming language with blazing performance. Created by fellow Rubyists at Manas, Crystal will make you fall in love with Ruby, AGAIN! Kemal is a fast, effective, simple web framework written in Crystal. In this talk, we'll start from the beginning with Crystal, how Kemal is born, what you can achieve with Kemal and why you should consider using Kemal for your next shiny web application.
Writing good object-oriented code is hard: object boundaries are not always as clear-cut as we’d like, their responsibilities and reasons to change tend to grow over time, inter-object coupling makes isolated testing complicated – and emergency refactorings are tiresome, gnarly and seem to always happen too late. At the same time it’s often hard to see the exact moment when a simple refactoring would save a given class from taking the wrong turn, and real-life projects tend to have real-life sad lines with their tireless chants of ‘let’s refactor this in the next sprint’. Ruby’s dynamism means static code analysis is tricky (to say the least), but tools like RuboCop and Reek bravely show it’s not impossible. This talk shows how to effectively use such tools, make informed decisions on when and how to refactor, and – most importantly – learn over time to spot potential code smells right when they’re introduced.
Published on Jun 27, 2017
Using real, selected snippets that Xavier has found while doing open source and consulting, we'll talk about concepts such as idiomatic Ruby, concise code, readable code, and exact code. We'll look at how they apply, and how subjective and social they are. A talk, indeed, with maybe more questions than answers.
In my talk I am going to tell how developers might go with integration of React (popular JS lib for buiding UIs) into existing Rails application. I am going to cover 3 common ways how to do that. In addition I will cover how to move from rendering HTML on server (through erb as most existing legacy Rails apps do) to SPA app through that integration. Topic has to dispel any fear which developer think about when he thinks about integrating modern JS lib/framework into legacy Rails application. I will present a step by step detailed guide with examples of code and bright presentation.
Areas to cover:
- 3 ways to integrate React into Rails application;
- React related ecosystem (webpack, es6, node + npm) and how to use it in combination with rails app and shall we ommit the asset pipeline or not?;
- How to move from hybrid React + Rails (erb) app to React (FE) + Rails (back-end API);
- Particular caveats and problems which can be faced during the migration.
An exploration of the challenges that Ruby faces today, combined with ideas regarding how we can change things for the better. We'll talk about the language, its ecosystem and its community. While on this bold adventure we'll plot a course towards Ruby 4.0 - a mystical and magical Ruby release that would ensure Ruby's dominance to infinity and beyond! Oh, and did I mention we'll have a ton fun while doing so? We'll most certainly do!
The elixir language has been proceeding recently as a better script for Erlang machine and the Elixir-based Phoenix framework has become another Rails competitor with all the features of Erlang. We have got a bunch of exciting videos about mightiness of Elixir and Phoenix processing 2M user sessions on one machine. One of the biggest wins of Elixir is full support of OTP – open telecommunication platform from Erlang – with its abilities to create, monitor and supervise processes, to scale, and to be fault-tolerant. With all these capabilities why not to try create an Elixir-based ruby server? We have tried and you'll see what we've got.
We all know that tests are among the most significant constituents of the stable app performance. However, unfortunately, good test coverage affects the speed of the test completion in the long run. Of course, one can leave everything as is, in the condition where everything works in the canonical approach, and have a countless number of guaranteed coffee breaks. But for those who do not drink coffee, I have an alternative approach to tell about!