Timeline

check-in will be open until 9:00

Open to all

Address from EFREI and ParisRB

Yukihiro Matsumoto

This talk will use ideas from the fields of “transactional analysis” and “moral psychology” to shine a light on the interpersonal games that play out during the every day interactions of a developer going about their daily work. Once we are able to recognise them, we are better equipped to reflect on our interactions, and engage more usefully with those around us.

The talk combines the two academic fields, with a focus on empathy and communication - traits I believe are key to building great teams and thus great software.

First, we hear both the internal monologue of a developer and dialogue between them and the people they interact with. I’ll be illustrating their feelings and (secretly) illustrating their lack of perspective. I’ll lean a little on the real-life cliches of the ‘working developer’.

Then, once we introduce the models from transactional analysis, I’ll re-examine the conversations to see the emotional/ego states of the participants and illustrate the games.

Imagine your legacy production Ruby application is highly dependent on a third-party API — until you learn your vendor deprecates your current connection. What do you do when you’re forced to make a change? Accept the challenge by embracing abstractions, switching libraries, feature flags, edge-case testing while developing new features. Game on.

Will focus on: Famous example of third-party dependencies that have broken application; Abstracting the API interaction; Utilizing Ruby switching libraries; Feature flagging; Testing for edge cases (QA & customer service); and much more!

Have you ever need to write a piece of code that can fail in so many ways that you do not know how to handle it? Do you know monads?

Monads are a classy way to write code in a structured way, step by step, and taking care of error handling very straightforward. Sometimes we have pieces of code that are tightly coupled and hard to replace, using monads we will be able to exchange any piece of code we want.

In addition, dry-rb is a collection of gems that intend to help developers to write clear, flexible, and maintainable code based on OOP concepts and functional programming.

Monads are a big part of this set of gems like dry-monads and dry-transaction. I will give you a glance of these gems and the things we can do with them.

Yum!

We all went through this situation when it’s 6pm on a Friday night and your monitoring system starts to complain about the latency of your background queues.

You start to look at your sidekiq instance then you find out that some queues are blocked and you absolutely have no idea why.

Then you look at the code but your queues host different kind of jobs.

Next step, you dig into your metrics and try to find the culprit. You realize then that all API calls to some thirdparties are really slow and there is nothing you can do about it.

Your only solution now is to throw more workers in the mix.

But wait, there must be some other solutions. HTTP servers have solved this problem for years where all the workers are blocked by slow clients.

Non blocking IOs and event loops are proven solutions to handle such problems. What if we could build an asynchronous background job system?

Once upon a time, a large and slow test suite haunted engineers on a mission to improve the lives of US veterans. Every day, they wasted time running tests locally and waiting for CI builds to finish. They threw parallelization at the problem, and eventually forgot it was supposed to be a temporary solution.

One day, they decided to do something about it, and declared, “We will not rest, until we speed up our tests!” They found the congestion in a single file, and relieved it permanently using an unconventional method. They also discovered other ways to permanently speed up the tests. In the end, they gained an extra 15 days every year to have a direct impact on a veteran’s life.

Through this real-life story, you’ll learn analytical approaches for finding and fixing bottlenecks in a test suite in situations where generic profiling tools can’t help. You’ll also learn how to use behavorial science to craft a persuasive message and increase team adoption.

Developer’s life in a cutting-edge market is quickly creating stuff, scaling the ones that actually work and keep some others that you simply have to. Repeat this a hundred times and either you are spending your days extinguishing fires, either you have more confidence than ever in your software.

So what’s the key to manage complexity ? How to accumulate things without losing the capacity to innovate ? What makes a choice good, years after it has been made ? How to gradually transform things without stopping the time ?

I will explain how we try to achieve this with Ruby, love and a little of pragmatism.

In this talk I am going to look closer at the negative consequences of working with dis-empowered teams in what has also become known as the feature factory organization. I will show how the most innovative product companies of today seem to work very differently, and talk about two examples from my personal career that have been very eye-opening in that regard. With this talk I hope to encourage people with an engineering background to make themselves more familiar with “state-of-the-art” product management to help make our software product companies more successful together.

Software has taken over the world. Many aspects of our lives and of how society works are controlled by software.

This brings a big questioning: How can we assume the great responsibilities that come with this great power of making software? In this talk I will discuss how we can answer that and show some ethical and moral decisions we must make when creating software. What can be considered ethical? What is the moral responsibility of the person who writes the code about effects that this code may have on society?

The goal of this talk is to make us think about our craft of making software in an ethical way.

Why only other languages have web app/Jupyter notebook plotting libraries? Need interactive plotting? No JavaScript code again, please! With daru-view, you get to plot Google charts, Highcharts, HighMaps, HighStock, Datatables, D3.js and compare them using only few a lines of Ruby. Amazing, Right?

daru-view is developed as a plugin-gem for daru and is designed for interactive plotting of charts and tables. It is basically developed but not limited to the visualization of daru dataframes and daru datavector. We can provide other inputs too like Array, Array of Array, hashes, etc.

Overview of daru-view (sciruby.com/blog/2017/09/01/gsoc-2017-data-visualization-using-daru-view/)
Enhancements in GSoC 2018 (github.com/SciRuby/daru-view/wiki/GSoC-2018---Progress-Report)
daru-view IRuby notebook examples (nbviewer.jupyter.org/github/SciRuby/daru-view/tree/master/spec/dummy_iruby/)

HighCharts official (www.highcharts.com/blog/post/i-am-ruby-developer-how-can-i-use-highcharts/)

Computer programming comes from a dream and a war. The dream is the notion that a machine can think. The war is an intellectual clash between two rival factions.

The first faction, the “symbolists”, gave us modern programming languages. The other faction, the “connectivists”, were disgraced for tens of years–only to come back with a vengeance a few years ago, wielding the magical results of modern deep learning.

That epic war of ideas lasted for over 60 years, and it shaped today’s computing. It involved a lot of geeky inventions, technical challenges, and good old-fashioned human flaws. It’s an amazing story, and every programmer should know about it.

Let me tell you that story, with some juicy technical details.

Feel free to mingle!

check-in will be open until 9:00

open to all

Luca Guidi

Is it possible to fall out of love with a programming language? The seven-year itch led me away from Ruby, enticed by languages that promised to give me what Ruby couldn’t.

Come and listen to a journey in search of productivity, efficiency, and effectiveness which led to some interesting places. From back-end to front-end and back again; from framework to brain work; from ease and complexity to difficulty and simplicity. From Rails to Ember to Elm to Ruby. A newfound appreciation for what was always there but lay unnoticed.

When most people think of government programming, they don’t think of Ruby, and certainly not Ruby without Rails. This presentation will examine my government department’s transition to Ruby and Rails, and our gradual transition off Rails, first to Sequel and Sinatra, and later to Roda. We’ll discuss the technical reasons behind the transitions, and the advantages we’ve found using our current Roda/Sequel stack.

The Doctolib mission is to improve the healthcare system globally. Today, it is used by more than 30 millions people in France and Germany. Behind the patient and practitioner platforms, 60 developers are working hard to improve the service. The software engineering team has experienced a 100% growth over the past year and further growth is expected.

In a context where teams have to assimilate new joiners pretty fast, how do we manage to onboard them on our ruby on rails stack? Half of our new joiners don’t know anything about ruby when they arrive. Find out our strategy to help new joiners be as productive as possible in less than 3 months.

Once they are productive, we still have to work on the same code in our monolith. How do we manage to share the knowledge when we - software engineers - don’t like to write anything but code? We tried many things, we’ll share what has worked best like our Gotcha, automatic comments on pull request, or our Starsky & Hutch mentoring programs.

Software development is the anticipation of a thousand dangers: regressions, edge-cases, exceptions, attacks, downtime, the list is endless. The first part of this talk draws from a range of disciplines to build and test a simple model for quantifying danger. As we bump into some of the pitfalls of the model, we’ll also explore what neuroscience tells us about decision making. Finally, we’ll work through a number of practical and familiar code problems, while also catching some mental fallacies along the way. There will be at least one science.

My goal is to help every developer ask a little more critically: what could go wrong? Not only so we can make better decisions, but also so we can disagree more rigorously about the dangers inherent in our software projects.

Yum!

Ekechi “Iyke” Ikenna

A lot of people learn to code for different reasons. For a lot of people I know, it’s not just the love of technology and creating things. It’s also about how much social change it can bring about in their lives. In a place like Nigeria with very high unemployment, expensive and spotty internet, poor electricity supply are a few hurdles some developers have to scale to teach themselves to code and join the profession of their dreams

It’s pretty easy to get burned out in OSS, as we all know! Since starting working on Kiba ETL (a ruby data processing framework) in 2015, I made a number of decisions to avoid this at all cost, and make sure my research on this would be funded sustainably, in a way or another.

In this talk, I’ll give feedback on which conscious design decisions & trade-offs I made over time, I will explain the various business issues (legal, billing, hosting, licensing, pricing) I met on the road, and I will explain where I stand at the moment.

A look back to why the lucky stiff, a quirky and unique developer who helped shape the Ruby community. 10 years later, what is _why’s legacy?

You wake up one morning and realise your test suite randomly fails on your CI for no apparent reason. At first, you stay in denial and just re run your test suite again and again, waiting for some luck.

Day after day, the disease spreads and finally becomes out of control: your test suite does not succeed anymore.

You have to face the truth: there is something wrong with your test suite 😱

This talk will tell the story of our own test suite debugging, why we had ourselves in this scary situation and what we learned thanks to it.

Do you write tests? Of course you do, otherwise you’d get tons of errors after each deploy because Ruby is super dynamic.

Do you write integration tests? I bet you should but they are slow right? They are unless you use new capybara driver - Cuprite and Ferrum which controls Chrome by devtools protocol.

I will tell you why Selenium is slow. How to write reliable tests that work. What CDP (Chrome devtools protocol) is and how to use to control Chrome and finally how to save time and debug your tests.

Getty Ritter

In June 2019, Stripe open-sourced Sorbet, a fast and powerful type checker for Ruby and a tool that has come to be indispensable for writing Ruby code at Stripe. We’ll discuss why and how we built Sorbet, including how specific choices and tradeoffs affected its design and adoption, as well as the experiences we’ve had in adopting, using, and open-sourcing Sorbet, and where we plan to take Sorbet from here.

… is from ourselves. I will share the true story of a bug. By looking at it across different realities, we’ll try to focus on the what our guts tell us. I’ll try to show you that emotions offer valuable feedback. This is a story about stress, uncertainty, and trust. It’ll be a warning about blind spots. And, it will promote well-known practices that we can use in response to this feedback.

Stay and Mingle!

Live Jazz by Yannick Benoit
http://yannickbenoit.com/index.php/groupes/