I am attending Friendlyrb in Bucharest. In addition to being fascinated by the overwhelming magnificence of the architecture here, I am having a super nice time around fantastic Ruby people, inspiration, and enjoyable talks about Ruby and friendly technologies.
These are some short summaries of what has been talking here today:
Rosa is principal engineer at 27 Signals. And she is from Spain, I didn't know, great, there are plenty of good developers in Spain, I see among the attendees many are also from there :)
Rosa is sharing with us their experiences, challenges, discoveries, and fights with encodings and decodings.
This subject is one of the most frightening for me. Each time I have found a bug based on an encoding problem, I have found myself in hell.
Rosa took us through history. The original ASCII, based on 7 bits and with its multiple code pages. The ISO-8859-1 (aka Latin 1). The Windows 1252. The US-ASCII. All the other standards for Asian languages. And then, the Unicode with support for a charset of 1.1 million code points (actually only 150_000 are in use).
We were through a rain of concepts such as charsets, planes, blocks, and encodings. To bring us to UTF-8 (The actual real king of encoding)
Rosa explained the magic of UTF-8, which uses a dynamic number of bytes (from 1 to 4) per code point (character pointer). The trick is to use the first bits to communicate the number of bytes that correspond to the character.
We were being enjoyed with some real world experience cases were encoding and decoding were causing interesting headaches and the solutions they found to solve them.
Security, good practices, take away suggestions and more. Nice speed light talk covering many security subjects when building a Rails app.
- Rate limits
- Loggin filter
- Secure passwords
- 2MFA
- Update dependencies
- Secure authentication in side services (Sidekiq, ...)
- Sql injection (and other injections) Especially attention here to sql injection using params as `order_by` or `columns`
- Second-level SQL injection (when the injection takes place in a background or service)
Things to read:
- https://rails-sqli.org/
- https://owasp.org/
- "This week in Rails"
Nabeelah was showing us their real world experience with a latency problem in one of their services and how a small change in a query was reducing it from 9 seconds to 3 milliseconds. Even if the change was minimal she showed us the full debugging process until finding the issue. It was, of course, including an intensive use of `EXPLAIN` and `EXPLAIN ANALYSE` (Mental note, the analyse version implies actually running the query, so be careful if it is making updates or any writting edition on your data.)
The talk was remembering the amazing book about indexes https://use-the-index-luke.com
Inspiring talk about SaaS endeavors, from a person that has been leading a team dedicated to sell SaaS projects since the 90s. Creator of:
- Buzzsprout
- StreamCare
- TICK
- DonorTools
- Msites
A lot of thing inspired by 37 signals and their "Getting real" (https://basecamp.com/books/getting-real). Nice to be reminder. Divided in two big categories:
-
Optimize Mass
- Have a mantra—a sentence explaining why your project is here. It helps to decide which features get in and which remain out.
- You will never know less than you know right now. Don't make decissions now if you can do them latter, when you have more experience and more knowledge (You are dum now, don't make decisions yet)
- Be uncomfortable with your first release. Classic.
- Run experiments. Don't build the feature, make a fake landing page to simluate it, test the market, taste the water before you commit to a full development.
- Don't solve problems you don't have. Avoid pre-optimization, hypothetical problems.
-
Look where you are going (visualize the Moon)
- Define success
- Software isn't all software. Marketing, customer support, competition analysis, Market fit, ...
- Maximize happiness, not profit. Profit it not going to make you happy.
Great. Building games using Ruby is nothing new for me, but it's nice to see it in action on stage. Julian ended the talk by presenting a multiple-player online game based on Dragon Ruby, using Rails and ActionCable to stream inputs from online users to the game.
Billions of DB records have to be synched into ElasticSearch for complex and optimized search features. The process took 7 days. With an architecture based on producers, consumers, and our friend Kafka, they managed to reduce it to 20 hours.
Gems used:
- Racecar
- DeliveryBoy
Challenges were Ruby was supporting the process with success:
- Testing
- Flattering DB records
- Ruby Kafka ecosystem
- Instrumentation
- Interaction with four different services: MySQL, Kafka, Redis, and ElasticSearch
With people from high teams, including Zendesk and Github, we discussed Ruby's ability (or not) to scale. Even if the concept of scaling ended up being very ambiguous, all agreed on a quick "yes" about whether Ruby scales.
The conversation was around:
- Performance
- Happiness
- Monitoring
- Progressive Refactoring
- DB Optimization
- Caching
- Rubocop-performance
- Working with big Ruby teams
- Code-owners
- Feature-flags
- After deploy monitoring
- Progressive deployment (deploy to 2% of the users, then to 6%, ...)
- Canary users
- RBS:inline (strict types in Ruby?)
- Sorbet (type check)
It was a nice day, with great ambient, nice corridor talks, guided city tours, great food, and great beer.
SQLite in production is not only possible, but it is also a great addition to our toolbox. Building great applications with light technology barriers has always been one of the Rails mottos. We take for granted that we need an external service to hold our database.
Stephen guided us through the process of tuning Rails and SQLite to have a stable production environment. Out of the box, it is not working. Some defaults prevent high load performance and concurrence.
Stephen has been working on tuning this setup for 6 months. He showed us the before-and-after of the performance and the errors found. He reached a point where performance was not only similar to Postgres but also better in some cases. Many of his discoveries and configuration changes will be added by default in Rails 8.
Having our DB run in the same process as our application has its benefits, starting with low connection latency and ease of deployment. It offers simplicity, control, and speed.
Some of the subjects touched:
- write-ahead loging (Default in Rails 7)
- IMMEDIATE TRANSACTION
- non-GVL-blocking timeout mechanism
We were solving problems as the SQLite production biggest pain: SQLite3::BusyException
Some gems:
- Solid Queue for background jobs
- Solid Cache for caching
- Solid Cable for WebSockets
Backups
- Litestream. It pipes all DB changes to an S3 bucket. You can restore it in a time machine. It has a mechanism to test the restore setup and a web dashboard.
- Solid Error. To store and monitor errors without the need for an external service. (Rails engine)
More gems in the oven:
- Solid Metrics. Ala Newrelic as a Rails engine.
- Solid Login. Same for logs.
Book: "SQLite on Rails: The Workbook"
Hana Harencarova - Building for web and mobile in 2024: Production story and brighter future with Rails 8
Hana took us over her experience in building a small app for her children's school communication.
They built a hybrid application:
- Web version
- Android version
- IOS version
The push notifications was one of the biggest challenges. They also had to implement browser push notifications.
Gems
- excid3/noticed
- pushpad/web-push
Book: https://railsandhotwirecodex.com/
Deep dive into optimizing a mathematical algorithm
- Binet's Formula
- Constant time
- FloatDomainError
- PHI**1475 => Infinity
- Rounding issues
- BidDecimal (arbitrary precision)
- Rational (performance and precision)
- Tail_call optimization
- RubyVM::InstructionSequence
From a simple recursive function to matrix multiplications.
- Repeated Squares algorithm
- Bitwise operator
- Fast doubling algorithm
- Hash default procs
Yaroslav is one of my actual Rails heroes. His YouTube channel SuperRails helped me to really understand Hotwire and start using it in my pet-projects. I had the opportunity to thank him personally for making me a better developer.
He was going through a list of suggestions and recommendations about setting app a web project using Rails.
- Hotwire
- Layouts first
- Spacing
- Sub-layouts
- ViewComponents
- Stimulus
- OpenGraph
Some links:
James is working at Stripe. They are working in a repo with 1.5 Million tests. If they want to run all the tests, it will take 60 days.
He was going through some of the workarounds and practices that helped them to still be agile.
For example, he explained how they implemented a C++ library that scans what files a test touches. This way, when they change a file, they know what tests they have to run. Or, better yet, the CI workflow knows and runs the specific tests. They go a bit further with this concept that they have a hierarchy of modules/services, and they know what is the tree of dependencies so they know that when they make a change in a module/service, they have to run only the tests of the modules/services that depend on this one.
AWS spot instances, with quick setup, to run the tests in parallel.
There were more experiences shared about:
- Builds
- Deployment
- Staging
- 20 ~ 25 deploys per day
- blue/green deploy with gradual traffic shifting
Accessibility is a subject that is always in our minds but never in a high top priority. Well, things are about to change. As of 28 June 2025, companies must ensure that the newly marketed products and services covered by the Act are accessible
In summary, newly marketed product websites will be required to have:
- Keyword navigation.
- Screenreader support. aria roles, alt texts.
- Color contrast.
Gems:
- accessibility (not recently maintained but still working)
- rubocop-rails-accessibility
Online tools:
- Lighthouse
- Wave
https://rubyeurope.com it is a new initiative to help local Ruby groups to start or get restarted. It is trying to create a centralized community forum for all the local Ruby groups in Europe.
One interesting initiative is promoting and financially supporting the exchange of speakers between local Ruby meetups and groups.
Uncertainty is an itchy evil that can corrupt us, causing us to succumb to stress and de-energizing situations.
Benjamin is talking about how the brain is dealing with uncertainty, how danger it is, but also how inevitable it is in our profession and in our day-by-day as developers. He is bringing to us motivational words and tips to overcoming uncertainty no by avoiding it but by embracing it as a partner for our growth.
- Decision fatigue
- Process incomplete information
- Working memory
- Hypervigilance
- Fragmented attention, pulled toward irrelevant information
- Frear and stress responses
- Biases and heuristics. Confirmation bias.
- Book "Thinking fast and slow"
- Imposter syndrome
Uncertainty is inevitable, and if we manage to make it our ally:
- Creativity thieves in environments where the usual rules don't apply anymore.
- Managing discomfort.
- Reduce reliance on cognitive shortcuts.
- Associate uncertainty with the experience of something new.
- Compartmentalize complexity. Observe the blocks from a high perspective.
A new concept for me: The historian (a member of the team who knows everything about the history of the code and whys of whens)
The creator of FreeAagent, which ended up in IPO. Also working in the 37 signals team for a while.
Olly gave us an inspirational talk about: "Build pet projects, dammit!"
About overthinking and how to stop doing it because it prevents to building of amazing things.
- Creativity is good for you
- Build pet projects
- Book: "The Creative Act. A Way of Being"
- Creative hobbies are associated with better-performance developers.
- Everybody is creative. Programming is a creative act.
- Nowadays, design is democratized.
- Book: "Refactoring UI"
- Pet projects are in the golden area of the Gann diagram of Low-risk, Low-pressure, Labor of love.
- Pet projects make you a better developer.]
- As a programmer, you have magical superpowers: use them.
- Just build, copy something, and give it a personal twist. Don't make plans. Just start and keep diving.
- Finish it! Finishing our work is a good habit to develop.
- You are a creator.
- Pet projects make you happy.
- The Rails ecosystem is at its best time.
Some pet projects he has personally working on:
And with this, the conference has ended. It was organized with love and featured a well-selected group of speakers, inspirational and technical talks, great people around, plenty of time, and opportunities to meet other Ruby fellows and interact with the speakers.
Thanks to all. And to Ruby ;)