More from Posts on Nikita Lapkov
Whether we like it or not, email is widely used to identify a person. Code sent to email is used as authentication and sometimes as authorisation for certain actions. I’m not comfortable with Google having such power over me, especially given the fact that they practically don’t have any support you can appeal to. If your Google account is blocked, that’s it. Maybe you know someone from Google and they can help you, but for most of us mortals that’s not an option.
I had the chance to speak at RustLab 2024! I will be honest, this was the point I realised that 4 conferences in one year was a bad idea. I was exhausted and overwhelmed, but I still had a blast meeting new people and answering the questions after the talk. It had the following abstract: Rhino: Low-latency Key-value Database in Rust Rhino is a key-value database optimised for low-latency edge workloads.
I had the pleasure to speak at EuroRust this year! This was my third and final talk about elfo, an actor system written in Rust. As I’m no longer an active contributor to elfo, it feels a bit bittersweet to finish last thing related to the project. I wish maintainers of elfo well as they continue to push one of the most hard-core Rust code I’ve ever seen :) The talk had the following abstract:
This year, I was invited to speak at P99 Conf. The format of a virtual conference was new to me, but hats off to the organisers as it went very smooth for me. I presented a talk with the following abstract: Low-Latency Mesh Services Using Actors We’re transforming elfo, our Rust actor system, into a distributed mesh of services. Learn how we tackled message serialization, compression, and back-pressure to optimize for high-frequency trading.
More in programming
We build a minimal X86 assembly program, run it… and hit a crash. But that crash is exactly what makes this program worth writing.
In 2023 I attended RubyKaigi for the first time and also wrote my first recap, which I’m pleased to say was well-received! This was my third time attending RubyKaigi, and I was once again really impressed with the event. I’m eternally grateful to the conference organizers, local organizers (organizers recruited each year who live/lived in the area RubyKaigi is held), designers, NOC team, helpers, sponsors, speakers, and other attendees for helping create such a memorable experience, not just during the three day conference, but over my entire time in Matsuyama. What is RubyKaigi? RubyKaigi is a three-day technology conference focused on the Ruby programming language, held annually “somewhere in Japan.” It attracts a global audience and this year welcomed over 1500 attendees to Matsuyama, Ehime. The traveling nature of the conference means that for the majority of the attendees (not just the international ones), it’s a chance to take a trip—and the days leading up to and following the event are full of fun encounters with other Rubyists as we wander around town. Checking social media a few days before the conference, I saw posts tagged with “RubyKaigi Day –3” and started getting FOMO! Talks RubyKaigi featured 3 keynotes, 51 talks, 11 Lightning talks, the TRICK showcase, and Ruby Committers and the World. There were talks in the Main Hall, Sub Hall, and Pearls Room, so you frequently had 3 options to choose from at any given time. Despite being held in Japan, RubyKaigi is an international conference that welcomes English speakers; all talks in the Sub Hall are in English, for example, and all the Japanese talks also have real-time translation and subtitles. Organizers put a great deal of thought into crafting the schedule to maximize everyone’s chances of seeing the talks they’re interested in. For example, every time slot has at least one English and one Japanese talk, and colleagues are scheduled to speak at different times so their work friends don’t have to split their support. The power of pre-study One great feature of RubyKaigi is its esoteric talks, delivered by speakers who are enthusiastic experts in their domains. I’m more of a Ruby user than a Ruby committer (the core team who have merge access to the Ruby repository), so every year there are talks during which I understand nothing—and I know I’m not alone in that. One of the topics I struggle with is parsers, so before the conference I created these sketch notes covering “How Do Computers Understand Ruby?”. Then, as I was listening to previously incomprehensible talks I found myself thinking, “I know this concept! I can understand! Wow, that’s cool!” Sketch notes on "How do Computers Understand Ruby" My plan for next year is to organize my schedule as soon as RubyKaigi’s talks are announced, and create a pre-conference study plan based on the talks I’m going to see. Just when I thought I’d leveled up, I attended Ryo Kajiwara’s talk “You Can Save Lives with End-to-End Encryption in Ruby,” where he talked about the importance of end-to-end encryption and told us all to stop using SMTP. It was a humbling experience because, after the first few slides, I couldn’t understand anything. Ruby taught me about encoding under the hood This year’s opening keynote was delivered by Mari Imaizumi, who took us on the journey of how converting the information you want to convey into symbols has been a thing since basically forever, as well as how she originally got interested in encoding. She talked about the competing standards for character encoding, and her experience with Mojibake. It made me think about how lucky I am, that the internet heavily favours English speakers. Even when I was exploring the Web in the 2000s, it was rare for me to come across content scrambled by encoding. TRICK 2025: Episode I There was a point at which it seemed like the awards were going to be a one-man-show, as Pen-san took the fifth, fourth, and third places, but the first-place winner was Don Yang, who until then hadn’t received any awards. The moment that stood out for me, though, was when Pen-san was talking about his work that won “Best ASMR”: code in the shape of bubbles that produces the sound of ocean waves when run. Pen-san explained how the sound was made and said something like, “Once you know this, anyone can write this code.” To his right you could see Matz waving his arm like, “No, no!” which captured my own feelings perfectly. Drawing of Pen san and Matz ZJIT: building a next-generation Ruby JIT Maxime Chevalier-Boisvert started her talk by apologising for YJIT not being fast enough. Because YJIT is hitting a plateau, she is now working on ZJIT. While YJIT uses a technique called Lazy Basic Block Versioning, ZJIT is method-based JIT. It will be able to “see” more chunks of code and thus be able to optimize more than YJIT. Ruby committers and the world There were humorous moments, like when the panel was asked, “What do you want to depreciate in Ruby 4.0?” Matz answered, “I don’t want to depreciate anything. If stuff breaks people will complain to me!” Also, when the question was, “If you didn’t have to think about compatibility, what would you change?” the committers started debating the compatibility of a suggested change, leading the moderator to say committers are always thinking about compatibility. Matz ended this segment with the comment that it might seem like there’s a big gap between those on stage and those in the audience, but it’s not that big—it’s something that you can definitely cross. Sketch notes for Ruby Committers and The World Eliminating unnecessary implicit allocations Despite this being an unfamiliar topic for me, Jeremy Evans explained things so well even I could follow along. I really liked how approachable this talk was! Jeremy shared about how he’d made a bug fix that resulted in Ruby allocating an object where it hadn’t allocated one before. Turns out, even when you’re known for fixing bugs, you can still cause bugs. And as he fixed this case, more cases were added to the code through new commits. To prevent new code changes from adding unnecessary allocations, he wrote the “Allocation Test Suite,” which was included in the Ruby 3.4 release. Optimizing JRuby 10 JRuby 10 is Ruby 3.4 compatible! What stood out to me the most was the slide showing a long list of CRuby committers, and then three committers on the JRuby side: Charles Nutter (the speaker), his friend, and his son. This was one of those talks where the pre-study really helped—I could better understand just what sort of work goes into JRuby. Itandi’s sponsor lightning talk Usually sponsors use their time to talk about their company, but the speaker for Itandi spent most of his time introducing his favorite manga, Shoujiki Fudousan. He encouraged us to come visit the Itandi booth, where they had set up a game in which you could win a copy of the manga. Sponsors This year there were a total of 102 sponsors, with so many gold and platinum-level sponsors the organizers held a lottery for the booths. To encourage attendees to visit each booth, there was once again a stamp rally with spaces for all 46 booths, although you could reach the pin-badge goal with just 35 stamps. It also helped keep track of where you had/hadn’t been. Since sponsors are an invaluable part of the conference, and they put so much effort into their booths, I always want to be able to show my appreciation and hear what each of them have to say. With 46 to visit, though, it was somewhat difficult! Each booth had plenty of novelties to hand out and also fun activities, such as lotteries, games, surveys and quizzes, and coding challenges. By day three, though, the warm weather had me apologetically skipping all coding challenges and quizzes, as my brain had melted. For me, the most memorable novelty was SmartHR’s acrylic charm collection! Since they missed out on a booth this year, they instead created 24 different acrylic charms. To collect them, you had to talk to people wearing SmartHR hoodies. I felt that was a unique solution and a great icebreaker. Collection of SmartHR acrylic charms I actually sent out a plea on X (Twitter) because I was missing just a few charms—and some SmartHR employees gave me charms from their own collection so I could complete the set! (Although it turns out I’m still missing the table-flipping charm, so if anyone wants to help out here . . . ) Hallway track (Events) Every year RubyKaigi has various official events scheduled before and after the conference. It’s not just one official after party—this year there were lunches, meetups, drinkups, board games, karaoke, live acts until three a.m., morning group exercises (there’s photographic proof of people running), and even an 18-hour ferry ride. I need sleep to understand the talks, and I need to wake up early because the conference is starting, and I need to stay up late to connect with other attendees! The official events I attended this year were SmartHR’s pre-event study session, the Women and Non-binary Dinner, the RubyKaigi Official Party, the STORES CAFE for Women, the Leaner Board Game Night, RubyKaraoke, RubyMusicMixin 2025 and the codeTakt Drinkup. I got to chat with so many people, including: Udzura-san, who inspired my Ruby study notes; Naoko-san, one of STORES’s founders; and Elle, a fellow Australian who traveled to Japan for RubyKaigi! The venues were also amazing. The official party was in a huge park next to Matsuyama Castle, and the board game event took place in what seemed to be a wedding reception hall. Compared to the conference, where you are usually racing to visit booths or heading to your next talk, it’s at these events you can really get to know your fellow Rubyists. But it’s not just about the official events; my time was also full of random, valuable catch ups and meetings. For lunch, I went out to eat tai meshi (sea bream rice) with some of the ladies I met at the dinner. I was staying at emorihouse, so following the after party we continued drinking and chatting in our rooms. After RubyMusicMixin, I didn’t want the night to end and bumped into a crew headed towards the river. And on day four, the cafe I wanted to go to was full, but I got in by joining Eririn-san who was already seated. That night I ended up singing karaoke with a couple of international speakers after running into them near Dogo Onsen earlier that day. Part of the joy of RubyKaigi is the impromptu events, the ones that you join because the town is so full of Rubyists you can’t help but run into them. I organised an event! This year I organised the Day 0 Women and Non-binary Dinner&DrinkUp. We were sponsored by TokyoDev, and we had a 100 percent turnout! I’m grateful to everyone who came, especially Emori-san who helped me with taking orders and on-the-day Japanese communications. With this event, I wanted to create a space where women and non-binary people–whether from Japan or overseas, RubyKaigi veterans or first-timers—could connect with each other before the conference started, while enjoying Matsuyama’s local specialities. We’re still a minority among developers, so it was exciting for me to see so many of us together in one place! Group photo from Women & Non-binary Dinner and DrinkUp! I’d love to host a similar event next year, so if you or your company is interested in sponsoring, please reach out! Matz-yama (Matsuyama) Last year’s RubyKaigi closed with the announcement that “We’ve taken Matz to the ocean [Okinawa], so now it’s time to take him to the mountains.” (Yama means “mountain” in Japanese.) Matsuyama city is located in Ehime, Shikoku, and its famous tourist attractions include Matsuyama Castle and Dogo Onsen, which is said to have inspired the bathhouse in Spirited Away. RubyKaigi banner on display at Okaido Shipping Street Ehime is renowned for mikan (蜜柑, mandarin oranges), and everywhere you go there is mikan and Mikyan, Ehime’s adorable mascot character. Before arriving, everyone told me, “In Ehime, mikan juice comes out of the tap,” which I thought meant there were literally pipes with mikan juice flowing through them all over Ehime! However, reality is not so exciting: yes, mikan juice does flow from taps, but there’s clearly a container behind the tap! There’s no underground mikan juice pipe network. 😢 RubyKaigi also highlighted Ehime’s specialties. This year’s theme color was red-orange, break-time snacks were mikan and mikan jelly, the logo paid homage to the cut fruit, and one of the sponsors even had a mikan juice tap at their booth! Also, included among this year’s official novelties was a RubyKaigi imabari towel, since Imabari city in Ehime is world famous for their towels. I’m an absolute fan of how RubyKaigi highlights the local region and encourages attendees to explore the area. Not only does this introduce international attendees to parts of Japan they might otherwise not visit, it’s a chance for local attendees to play tourist as well. Community In Matz’s closing keynote, Programming Language for AI Age, he touched on how it’s odd to delegate the fun tasks to an AI. After all, if AI does all the fun things and we do all the hard things, where’s the joy for us in that? To me, creating software is a collaborative activity—through collaboration we produce better software. Writing code is fun! Being able to connect with others is fun! Talking to new people is fun! I’ve met so many amazing people through the Ruby community, and RubyKaigi has played an important role in that. Through the community I’ve gotten advice, learned new things, and shared resources. My sketch-notes have been appreciated by others, and as I walk around there are #rubyfriends everywhere who all make me feel so welcomed. RubyKaigi attracts a variety of attendees: developers and non-developers, Ruby experts and Ruby beginners. It’s a fun conference with a wonderful community, and even though it’s a technical conference, non-technical people can enjoy participating as well. Community growth comes with its own issues, but I think attracting newcomers is an important aspect of RubyKaigi. As someone who first came as a developer completely new to Ruby, every year I learn more and am inspired to give back to the Ruby community. I hope that RubyKaigi continues to inspire participants to love Ruby, and encourages them to understand and improve it. By growing the Ruby community, we ensure Ruby will continue on as a Programming Language for the AI Age. Looking forward to Hakodate next year, and to seeing you all there! PS: Surprise, Detective Conan? I really love the Detective Conan series. This year RubyKaigi Day Three and the 2025 Detective Conan movie premiere were on the same day . . . so as soon as Matsuda-san said, “It’s over!” I ran out of the hall to go watch the movie at Cinema Sunshine Kinuyama. And next year’s RubyKaigi location, Hakodate, was the setting for the 2024 Detective Conan movie. What a deep connection RubyKaigi and Detective Conan have! Detective Conan decorations set up at the cinema in Kinuyama
In my article about Espressif’s Automatic Reset, I briefly showed UART output from the bootloader, but did not go in more details. In this article, I want to go just a bit further, by showing some two-way interactions. We’ll use the initial basic “real” UART setup. Note that I did not connect DTR/RTS to RST/IO0. … Continue reading Talking to Espressif’s Bootloader → The post Talking to Espressif’s Bootloader appeared first on Quentin Santos.
When smart people get their high from building complex systems to solve simple problems, you're not going to have a good time
I loved this talk from Alexander Petros titled “Building the Hundred-Year Web Service”. What follows is summation of my note-taking from watching the talk on YouTube. Is what you’re building for future generations: Useful for them? Maintainable by them? Adaptable by them? Actually, forget about future generations. Is what you’re building for future you 6 months or 6 years from now aligning with those goals? While we’re building codebases which may not be useful, maintainable, or adaptable by someone two years from now, the Romans built a bridge thousands of years ago that is still being used today. It should be impossible to imagine building something in Roman times that’s still useful today. But if you look at [Trajan’s Bridge in Portugal, which is still used today] you can see there’s a little car on its and a couple pedestrians. They couldn’t have anticipated the automobile, but nevertheless it is being used for that today. That’s a conundrum. How do you build for something you can’t anticipate? You have to think resiliently. Ask yourself: What’s true today, that was true for a software engineer in 1991? One simple answer is: Sharing and accessing information with a uniform resource identifier. That was true 30+ years ago, I would venture to bet it will be true in another 30 years — and more! There [isn’t] a lot of source code that can run unmodified in software that is 30 years apart. And yet, the first web site ever made can do precisely that. The source code of the very first web page — which was written for a line mode browser — still runs today on a touchscreen smartphone, which is not a device that Tim Berners-less could have anticipated. Alexander goes on to point out how interaction with web pages has changed over time: In the original line mode browser, links couldn’t be represented as blue underlined text. They were represented more like footnotes on screen where you’d see something like this[1] and then this[2]. If you wanted to follow that link, there was no GUI to point and click. Instead, you would hit that number on your keyboard. In desktop browsers and GUI interfaces, we got blue underlines to represent something you could point and click on to follow a link On touchscreen devices, we got “tap” with your finger to follow a link. While these methods for interaction have changed over the years, the underlying medium remains unchanged: information via uniform resource identifiers. The core representation of a hypertext document is adaptable to things that were not at all anticipated in 1991. The durability guarantees of the web are absolutely astounding if you take a moment to think about it. In you’re sprinting you might beat the browser, but it’s running a marathon and you’ll never beat it in the long run. If your page is fast enough, [refreshes] won’t even repaint the page. The experience of refreshing a page, or clicking on a “hard link” is identical to the experience of partially updating the page. That is something that quietly happened in the last ten years with no fanfare. All the people who wrote basic HTML got a huge performance upgrade in their browser. And everybody who tried to beat the browser now has to reckon with all the JavaScript they wrote to emulate these basic features. Email · Mastodon · Bluesky