Code and the Coding Coders who Code it
We talk about Ruby, Rails, JavaScript, and everything in between. From tiny tips to bigger challenges we take on 3 questions a show; What are you working on? What's blocking you? What's something cool you want to share?
Code and the Coding Coders who Code it
Episode 52 - Vladimir Dementyev
What happens when you put Rails in a browser? Vladimir Dementyev (Vova) is pushing WebAssembly to its limits by creating an interactive Rails playground that runs entirely client-side. This groundbreaking project aims to eliminate the frustrating installation barriers that often discourage newcomers from trying Ruby on Rails.
"I asked myself the question - can I run Rails on WASM? And that's when you feel yourself like a pilgrim software engineer, experiencing something for the first time that no one ever experienced," Vova shares. The project isn't just a technical curiosity but serves a vital educational purpose - allowing anyone to learn Rails through the official tutorial without wrestling with Ruby version managers or environment setup.
As principal engineer at Evil Martians, Vova balances multiple innovative projects simultaneously. Beyond Rails on WASM, he's organizing the first San Francisco Ruby Conference (coming November 2024), building a custom open-source CFP application, expanding AnyCable to support Laravel, and updating his technical book "Ruby on Rails Applications." His creative problem-solving approach extends to production environments too, where techniques developed for experimental projects help solve real client challenges like making libvips fork-safe for high-performance web servers.
Vova's philosophy on productivity is refreshingly practical: work when inspiration strikes rather than forcing creativity during arbitrary hours. "If I have no desire to sit at my desk and stare at the laptop, I'm not going to do that. I wait for the moment to come, and then I sit and work, and it's really efficient."
Ready to see what Ruby and Rails can do in previously impossible environments? Follow Vova's work, attend his RailsConf talk, or join the growing San Francisco Ruby community to witness how Ruby's flexibility continues to break new ground in unexpected ways.
Honeybadger is an application health monitoring tool built by developers for developers.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Hello everyone and welcome to another episode of Code and the Coding Coders who Code it. I'm joined today by Vladimir Dementyev, also known as Vova, and would you please do two things for me. One introduce yourself and then also explain for people like me who do not understand how Vladimir turns into Vova, because when I found out, I was very interested. Hey everyone, the good question. So my name is.
Vladimir Dementyev:Vova because when I found out I was very interested. Hey everyone, the good question. So my name is Vova, that's a short version of Vladimir, and I actually don't know why. I know it's common in the States, in American names, many names like Robert and Bob. They have some similar letters but it's not truly the same word. It's the same mystery for us again, for foreigners, to understand why Bob is becoming Robert and vice versa. And it's actually closer because if you write Bob and Volvo in Russian it's going to be the same letters because V like V, the sound V in Russian is looking like B. So maybe there is something here. I don't know. But yeah, we usually have many names and many Slavic Russian names. They have two or three or four variations, so you're free to choose one you prefer. So in mine preferred name is Vlava and Vladimir is an official name.
Drew Bragg:And for the record, it is not shortened to Vlad, which is what I learned today, Because in my head it was always oh, Vladimir, Vlad, because I've heard Vlad is like a Russian name.
Vladimir Dementyev:Yeah, that's what happens to Vladimir. All Vladimirs that come to the States, they want to be, you know, more accessible in terms of like naming things. So they shortened themselves to Vlad because it's easy, but in Russia that's a different word name. So Vlad is a short version for Vladislav and that's not me. So I did that mistake.
Vladimir Dementyev:Actually, at my first RailsConf I presented myself as Vlad, just to, you know, be closer to the audience, easier to remember, whatever. Because, oh, vlad, whatever, what is it? So then, after I moved to the States, I realized that, oh, actually, people here don't care about assimilating names. Let's say, everyone's using their names, most people, and you have to learn how to pronounce names in different languages, especially when I live in New York. So we're the community's most diverse, I think in the States. So, and I found out, oh, I should not call myself by a different name, I should use my name. So that's when I started slowly, like gradually, teaching I would say my friends that, oh, okay, actually I'm Bova, so it's yeah, it's harder to say. I understand that, but so that's why I'm fine with Vladimir and even Vlad is fine, I don't worry about that.
Drew Bragg:I was always curious whenever Irina would like talk about you to me or like whatever, she would use Vova and it's one of those like we call Richard Dick at times and I'm like wait, I know there's a story there, I just don't know what it is. So, and now I learned, today I learned, and hopefully audience someone out there also learned.
Vladimir Dementyev:Yeah, and actually for the record, we don't call Irina Irina, we called her Ira. So the thing I'm learning, see I'm doing terribly- and I'm actually encouraging her to use this name when she's presenting somewhere. So not Irina, ira, just people going to learn that at some point.
Drew Bragg:Yeah, yeah. Well, some of us are dumb and take a minute to learn things, but we will eventually learn them. So, ira, yeah. Okay, so anytime she no good stuff, but okay. So, vova, please introduce yourself to anyone in the audience who is not familiar with you or your work.
Vladimir Dementyev:So I'm working as a principal engineer, evil Martians consultancy. Nowadays we're focusing on dev tools, startups and all cool stuff around us. We do a lot of stuff in the Rails world, frontend world or whatever. Personally, I'm responsible for the backend team, so I'm not doing anything useful for clients directly. I'm just mostly doing research work, marketing work. Sometimes I join clients just to brainstorm ideas, but these days I'm focusing on conferences too, in particular. So RailsConf is just in a month and we have three Martian speakers there and I'm including and I'm preparing a talk on Rails, on Basm Not a new version, but a new kind of projection of Basm. Not a new version, but a new kind of a projection of Basmification of Rails, because this time we're trying to put the Rails tutorial, the whole tutorial, into the browser so you can try and build something with Rails to get an idea of what Rails is, without leaving your browser from databases, web servers, tests, everything. So just in your window, and I think that's an important step for making framework more, again, I would say, accessible to people who are not familiar with Ruby and Rails, who don't want to deal with oh, rbn and Stone doesn't work, or what's wrong with my Ruby version on Mac OS or whatever. So we have every server-side language has these problems and we want to eliminate this steep learning curve. It's the entry curve, I would say, and that's what we're working on, and I want to present that at RailsConf. So that's one of my primary tasks today. And another one is also related to conference. We just announced San Francisco Ruby Conference. So it's kind of the evolution of San Francisco Ruby Meetup, which we've been holding for more than a year and every month in San Francisco. It just actually happened yesterday or two days ago. And this November we decided, okay, we should go with a conference Two day, probably single, two track, we don't know yet, but that's going to be the whole feature conference. We preparing for that. I'm personally responsible for technical stuff as well. So we just built a CFP application from scratch for the conference because, well, there are a lot of reasons we can talk about it later. So, yeah, that's what I'm doing now. And, of course, another field of interest in my continuous work is AnyCable. So this project that's actually turning nine years in a month. Yeah, like from the day that the name came out right. I came out with the name, it was right after I joined Evil Martians. So it's nine years since I joined Evil Martians and that was my first open source project. I decided to build within the company and, yeah, that's like one of the primary projects and products right now for us, so it's real time server. If you don't know, performer is powering WebSockets for Rails apps and not only Rails, because this week we announced our initial Laravel integration and we are looking to make any table.
Drew Bragg:Jason Tromp will be so excited about that.
Vladimir Dementyev:Well, yeah, like Laravel, is underwriter of many Ruby and Rails developers for many years. We know that Chris Oliver, for example, got inspiration for his PayJam from Laravel PayJam version I don't remember how they call it, but it's something they had built in into ecosystem for a long time. So they had a lot of great ideas. They've been like a Rails descendant in some sense. They actually chose Datapath and we can learn back from them and we do that sometimes. And then Cable decided okay, we can actually now again bring something from Rails to Reliable like a powerful WebSocket server. It's going to work easily with their existing tooling.
Vladimir Dementyev:So, yeah, that's how I kind of scared some people on Twitter last week when I showed some screenshots of me doing Laravel and I got some replies oh no, what are you doing? Are you going to abandon Rails? What? No, I'm not going to do that. We wanted to share what we built for Rails community with others, and one of the goals is actually to make the tool we build in AnyCable and everything around it better, because the more use cases you have, the more ecosystem you try to integrate your software, the better it becomes, and we want this any part of AnyCable. So that's kind of philosophy which is in the name, is to be truly any and many directions. So it's like for any backend, any framework, whatever, any protocol. So that's just fits our vision for this open source tool and we just try to make it better and help others building better cool things with it.
Drew Bragg:That's awesome. You are a man of many projects. People also might know you from your book Laird on Rails applications, and you have a newish version. Let's say it's in the works. We'll go within the works.
Vladimir Dementyev:Yeah, I haven't mentioned that as my project because, well, something I try to put at the end of the backlog every day, but I promised to myself actually to start writing, updating existing chapters, writing new chapters this weekend, like just tomorrow. I don't know if it's going to be like that, but because we want to get it out around Rails world, I'm not coming this year, but maybe someone will make an announcement, I don't know. So, yeah, the second edition this year, but maybe someone will make an announcement, I don't know. So, yeah, the second edition. It seems like, oh, it's just an upgrade. You already have the content, so it should be much simpler, but it's not so.
Vladimir Dementyev:When dealing with the book, it's just some state of mind. You just need to find yourself, to find the right I don't know mood or whatever to get into writing a book, to getting back into loading all the context back into your brain, which is not as large as LLMs of today. I can't just load the whole book into my brain, because it's not just a book, what's written, and that's okay. We're switching topics, I'm talking about LLMs and that's just an idea that came into my mind. It's not enough to load the text content of the book into the context of whatever brain, llm, whatever. To get an idea of what's going on, you need to actually load into your brain's context everything that happened when you were thinking about the book you were writing it, and the amount of that data is enormous. It's not reading right, it's not set in stone, it's just something. It's more like feelings, something like that, it's like inspiration, and it's not something you can just digitalize right and put into a neural network. So that's the hardest part of it.
Vladimir Dementyev:That's another project of mine today writing a book and one of the reasons for that is you know that you remember that a couple months ago at Sin City Ruby, we had an auction to support Jason Sweat with his initiative to having this amazing conference and sweat with his initiative to having this amazing conference, and my lot was a copy of my book with the draft of the new chapter, like before the release. So I can't just waste that. I have to do that. That's my responsibility. So I hope in a week Jasper will receive this copy and the draft of the chapter, because I already have this chapter in my mind. It's going to be cool, I think. I hope so. I like it. That's something I originally wanted to include in the first edition. But yeah, well, we'll see. So a lot of things going on so we can talk whatever you want. What's on your plate? Do we have any intersection here? Sure, yeah, are you writing Laravel?
Drew Bragg:Yes, I am not writing Laravel. Laravel has always been one of those because it's so adjacent to Rails, it's like a descendant, it's so influenced, and then it went a step further with everything else it has going on. Laravel's always been one of those. Like man, if I couldn't write Rails anymore, what would I do? And I still think I'd pick a Ruby-based framework, but I would definitely give Laravel a try. It seems so cool, it seems so fun and it seems like it has a pretty great ecosystem and community like rails. So yeah, it's on the list. I haven't, though. Php is just daunting to me because ruby has ruined me for other languages. Like I look at other languages and like I don't know if I can, just I don't know.
Drew Bragg:But the way that the show normally works for anyone who's listening for the first time is normally what would happen is I would ask vovo what he's working on, what kind of blockers he has and what's something cool, new or interesting that he's recently learned or discovered. I'm pretty sure his intro covered the what are you working on question, which is the too long didn't listen version is a lot. Long didn't listen version is a lot. You've got a RailsConf talk. You've got a San Francisco Rubyist meetup group that you help run, and the conference coming up that you're building tools for, and you're working on the AnyCable to Laravel stuff and you've got the update to your book coming up. So there's a lot. Is there anything I missed on the? What are you working on? Actually, I have an everyday work, so there's a lot Is there anything I missed on the?
Vladimir Dementyev:what are you working on, Actually? I have an everyday work.
Drew Bragg:On top of everything else, you have a day job. Got it.
Vladimir Dementyev:Meetings, calls, whatever, explorations. That's the boring part. It becomes less boring when I write about it, so in a book or give a talk and something like that, but in the moment it's usually boring stuff. I try to finish as soon as possible so I can have some time for all the cool stuff. Yeah, so that's actually my blocker, if you ask me what's my blocker.
Drew Bragg:There you go, we're moving right along here. You've got plenty of work. You're working on and your blocker is your fucking day job. Oh right, it's Friday. I working on and your blocker is your fucking day job. Oh right, it's Friday. I'm in a mood, it's fine.
Vladimir Dementyev:I don't know that you can find a better word to explain it. Well, I like my job, but sometimes we have too many calls. They are all important because, well, my work on conference talks or even book doesn't help the company I work for and so that's kind of a bargain. Yeah, sure, I had tons of calls and they allowed me to write the book, you know the open source work, there you go, that's a fair trade, in my opinion.
Drew Bragg:So I'm currently in because, as of recording, right now it is Friday, june 6th, which means we are rapidly approaching one month away from RailsConf. So I'm starting to get pumped for everybody to come to Philly and have a cheesesteak and talk about Ruby and Rails and all that jazz. And your talk is on Ruby on Rails in the browser with Wasm, which is super cool. Ruby on Rails in the browser with Wasm, which is super cool, and you're building basically the Rails tutorial interactively because of Wasm, not just like hey, read and look at this example, but read, look at this example and then interact with it. Can you tell us a little bit about some of the challenges on getting Rails into the browser, the state of Ruby, wasm, things like that?
Vladimir Dementyev:Yeah, so we started exploring this idea of putting Rails on WASM about a year ago Actually I think it was the very first South Ruby meetup. I presented the first talk when I managed okay, I can run a Rails application like very minimal Rails application, almost like Rails new, with some database interactions in the browser. It kind of worked enough to present a meetup. But it actually was just a very proof of concept and we started exploring this idea. And well, we started facing challenges and we started to explore this idea. And well, we started facing challenges Because Ruby is not truly a fully solved problem like a fully solved task. We have an official VASM support in Ruby which means it's possible to compile Ruby C code, like MRI code, into VASM. There are some C macros and ifdef whatever stuff over on the code base to make it compilable into VASM. There are some C macros and if-dev whatever stuff over on the code base to make it compilable into VASM. And that means you can run Ruby VM within VASM runtime browser or not only browser and that's cool. But there are some limitations like no networking, no other stuff and so on, and when it comes to like everything in Ruby world, you kind of measure the applicability of some new idea, some new tool, some language addition by the matter, if it's possible to run Rails on that. For example, we had Rectors right, rectors has been around for five years already, something like that. But the true measure of whether Ruby is Rector-ready is whether we can run Rails on Rectors. And the answer is not, not yet and maybe never. And the same could be applied to any new stuff that comes out. Actually, because Ruby heavily depends on Rails as its primary driver for attracting developers, engineers and so on. So we can just avoid this fact, right? We're not going to talk about whether it's good or not being like single framework-centric language. That's just the fact and we should live with it. So the same could go with VASM. So, okay, we have Ruby on VASM and actually Ruby VASp has much more application than just Rails being a Rails playground. But I asked myself the question okay, can I run Rails on Wasp? And it turned out that there were a lot of cool stuff. That's when you feel yourself like a pilgrim software engineer. You experience something for the first time that no one ever experienced that. Because who's crazy enough to try running on VASP why? A lot of people are trying to ask the question why? Why do you need this? Why to run Ruby on VASP? A lot of people don't understand. But I think those people also don't understand that. Because why not? That's the answer. That's how my mind works.
Vladimir Dementyev:I like the phrase coined at Rails World or RailsConf by Xavier Noria once. He also was talking about something like that and he stated that it's just a joy of problem solving. It's something like he explained that because of mathematics, mathematician roots, and I am a mathematician as well, so I love abstract stuff and all that and I just love solving problems. So it doesn't matter if there is a practical outcome of the solution right, I believe it's kind of academical kind of stuff right, it doesn't matter if you prove the theorem or whatever or some theory and it doesn't make sense today. One day some people discover it and they build something cool out of it. You never know how it's going to be used. That's where the combination of this and the joy of problem solving brought me to this Rails on VASM, and I was like a kid in a candy store because there were a lot of problems I didn't know how to solve and that's where there were a lot of blockers.
Vladimir Dementyev:But the good thing is that we're still dealing with Ruby and I believe that in Ruby, everything is possible, whatever you can imagine. You can do that Just because the language, the ecosystem, the language itself is flexible. It's an open language, which means that, oh, if something doesn't work, you just put a patch, a hack it or something to find a way out. It doesn't matter what is it. Oh, you don't have socket support in the browser or, like Nakagiri, let it just add a tab class with pure Ruby implementation, or just block it and make it look like it works, and it's probably going to work and it's enough for running something in the browser. And we have a lot of that stuff.
Vladimir Dementyev:And we were just trying to solve all the problems one by one, because Rails is not just Ruby. So you have extensions, you have databases, you have web server and you need somehow to put all of that into the browser. It's not just Ruby. So you have extensions, you have databases, you have web server and you need somehow to put all of that into the browser. And every component of Rails requires just some special attention. And at the first step, by the end of the previous year 2024, we managed to solve the problem, I think, of putting production application into the browser, but what I mean is that you can just pack your application to a VASM module, add some JavaScript scripting that we made generic enough to run any Rails application and just put it in the browser, and it's going to work up to some point. We already have databases in the browser, so it's not a big deal. And the fact that Ruby is open language and Rails is a kind of modular framework and with a lot of stuff abstracted out the Rails concepts, most of them at least, abstracted out from the implementation, so we can just swap them and replace, like, for example, sqlite database, for example, a SQLite database regular database, which is just a file. You can replace it with a JavaScript external interface and still use the same ActiveRecord connection class and most of it to build queries and do all the stuff, and it's just going to work because Rails allows us to do that. And the same goes about any Rails component, and we managed to build adapters and wrappers for running Rails in the browser.
Vladimir Dementyev:Again, the question still holds why do you need to run Rails in the browser? And after giving this idea some time just to age, well, we found that okay. Actually, how do others use in-browser technologies? For example, we have JavaScript and while it's natural for them to run a lot of stuff in the browser because that's their runtime, but actually more than JavaScript, it's not just a browser right, it's like full stack nextjs and all that stuff and serverless stuff. They still need some kind of server and in JavaScript world they kind of solved it by putting notjs into the browser, also by the means of Basm and the project one of actually our EvoMotions clients that's why we know about that is called StackBlades. It's an online IDE that fully runs in the browser so you can run almost any JavaScript project with server and client right in your browser, with previews, hot reloads or whatever. It just works and it doesn't require any servers, containers, whatever. It's not like Cotspaces or something like that where you have a real server, right, it's really in your browser.
Vladimir Dementyev:And we were thinking like, okay, why can't we have the same for Ruby? Right, because we found it very useful. You can trash issues for open source projects or share some working examples, how to do stuff. So, oh, it's not just copy-pasting text, you just send a link where you have a reproduction and people can try it with both server and client. And we found that, okay, probably this aspect of basmification, educational aspect today is most valuable. So that's where we can get benefit right away just by making Ruby and Rails browser ready so people can try with it, can share some snippets, whatever. And that's where we started working in that direction.
Vladimir Dementyev:And Rails getting started tutorial is a good starting point. That's like a milestone If we can't put Rails getting started tutorial is a good kind of starting point. That's like a milestone If we can't put Rails getting started into the browser so people can just run Rails, new Rails like tb, migrate Rails, test, whatever, everything right in their browser without dealing with installations or whatever. We can identify all the problems we find along the way and later on.
Vladimir Dementyev:So that's our plan we can actually make this framework for building tutorials for Ruby projects generic enough so we can use it for your library, for your framework not only Rails and so on. So we're using Rails as a playground and we plan to go further from there, and that's what we're going to talk about at RailsConf. We already have half of it running in the browser, so I'm teasing some snippets every week on Twitter and they're actually lagging like a couple weeks of work, so we're closer to the end than it seems. So, yeah, and I'm pretty excited about it because, let me be honest, when we proposed this talk so I'm doing this talk with my colleague who's actually working on StackBlade's project and we had nothing, we just had an idea. So it's a typical, I guess, like a conference. Well, I had this idea years ago and I started playing with it, actually for Action Policy Jam, because I wanted.
Vladimir Dementyev:Well, it's pure Ruby Jam, so it's much easier to put into the browser and create an interactive tutorial on how to write policies and so on. And I kind of knew, well, it should be doable. And then we got accepted to RailsConf and like, ok, let's start working. So that's why I'm doing that.
Drew Bragg:Now we actually have to build this thing.
Vladimir Dementyev:Yeah, yeah. So that's conference driven development. It's really cool. I don't think it works for everyone, but for me it's the best way, kind of promise driven development. Right, I'm writing the book because I promised to write a new chapter right, and I'm writing this Rails on Buzz because probably the Laravel stuff I mentioned is the only thing that came kind of from the inside because I wanted that for myself. I don't promise that to anyone. I just wanted to distract myself actually from this Rails stuff and the book, so put myself into something new.
Drew Bragg:Yeah, what's the old saying? It's amazing what a developer can build when they're working on something other than what they're supposed to be working on. Laravel benefits from you having a lot on your plate. You need a distraction. You build something for them. That's awesome. I'm super excited for your talk. It was definitely very highly ranked when we were talking about it in the programming committee of like. This fits so perfectly with the future side, because that was the goal for RailsConf.
Drew Bragg:Let's talk about the past, present and future of Rails at the last RailsConf, and what a great topic for the future of Rails is like. Oh yeah, by the way, rails in the browser is a thing. Look here you can do interactive tutorials and who knows what else and we probably can't even begin to imagine what someone's going to eventually be able to do with Rails in the browser. It's such a new concept that we're limited by our imaginations right now, and someone's imagination is going to be like I wonder if I could do, and the answer is going to be yes, and it's going to be super cool. So, yeah, I'm excited for that one Amongst others at RailsConf.
Drew Bragg:Railsconf has such a great schedule and program. Normally I'm a hallway track kind of guy, and this is probably going to be more talks than I've attended since my very first one, just because there's so many good ones that I want to see and I know I probably won't end up watching them on YouTube Not all of them at least. In addition to speaking at Rails railsconf, you help with the san francisco ruby meetup, which, from what I hear, is a mini conference in and of itself. You guys have multiple hundreds of attendees for each meetup, let alone now you're also doing a conference in november.
Vladimir Dementyev:Yeah, the meetup we just said. It's a huge success and we have a lot of attendees. It's not always hundreds, I think Sometimes it's a hundred. It really depends on location, I can be honest, because we have rotating locations, so actually a lot of companies in San Francisco want to host the meetup, so our popular locations would be like GitHub headquarters, I think that's where we get it.
Drew Bragg:No, shock there.
Vladimir Dementyev:yeah, yeah, that's where we started and that's the first meetup had like probably a couple of hundreds of people and I usually get a lot and we have Chime. I only attended GitHub and Chime, I don't know about others, I know actually but I know that the next one in july is happening at figma and we expect it to be packed as well. We've been in talks with them for a long time to host this meetup and finally we got the date because it's san francisco. Companies have schedule planned for the whole year and like like, oh, you want to meet up at GitHub? Okay, we have something for 2026 March. We don't even know if it's going to be a meetup.
Vladimir Dementyev:Well, luckily, a lot of options and even if the plan has changed for some company and they're busy with something else on that day, we can find a backup. So, given that the meetup got a lot of attention and positive feedback, we decided that we should go with a conference, and one of the reasons for doing it this year is actually the fact that they're not going to be RubyConf this fall. So we found that, okay, there is a huge gap. No Ruby conferences this fall in the States, I think. Rocky Mountain announced also their conference.
Drew Bragg:Yeah, that's in October.
Vladimir Dementyev:So we're going to be in November. So we want Ruby conferences to be spread across the year kind of evenly. So we have RailsCon this summer and no RubyConf. So we said RailsCon this summer and now RubyConf. So we said, okay, there is a sit available, why not fill in it? And we'll see what's going on next year. But I think it's going to be not just a one-time thing. Well, we don't want it to be a one-time thing. So we're really excited about it. It's a lot of work. We never did anything like that. We'll see. So far, I would say it's good. We expect a lot of cool speakers. We try to make it not just a Ruby conference but a themed Ruby conference around San Francisco and their values, right, startups, ruby builders we want to see people who build with Rails especially new companies and not only new, like major companies as well how they use Ruby, why they chose Ruby and so on. So it's more about highlighting Ruby as a cool productive tool for your business than just talking about Ruby itself. So that's our goal. So so we'll see. I'm kind of excited about it.
Vladimir Dementyev:We just announced it and it's usually for bigger conferences you need a lot of time for preparation, so we have a very short, I would say, like runway for the conference. So we just announced CFP. Cfp is open at cfpsfrubycom and that's something I've been working on recently because we decided to go with a custom application for CFP. So we built it from scratch. That was fun. It was fun and stress, stress and fun literally the day of announcement. We only had functionality ok, we can accept applications, we don't have anything yet. We don't have functionality for reviewing applications and all that stuff. I already started working on that, but that's cool and we want to actually open source the application eventually, probably after the CFP ends, to share it with the communities.
Vladimir Dementyev:Maybe someone else will decide to pick it up and deploy somewhere instead of paying CFP services tons of money for I don't know what, why. So I remember RailsConf used to use this Ruby CFP app that's still in use, I think by RubyKaigi, maybe some other conferences. So it's like an old Rails application and RailsConf and RubyConf used to use them and it was cool. Well, it was like old school UI, whatever. Yeah, yeah, just HTML driven, but it was much easier to work with than everything that happened next, like sessionize, paperclip they're all so bad, right, and you know like conferences tend to use them. So we want to release our open source projects and make it kind of once like thing, right, so you can just grab it, deploy like update styling text and go and build a new version every year.
Vladimir Dementyev:I want it to be intentional because I don't want people to just copy all the services aggregator services, that you have a list of your proposals and when another conference announced CFP, you can say, oh, I want to pick these proposals and send it to this conference. I think it's just. I don't want that. I want people to craft a new proposal, at least copy-paste it manually, because as a reviewer, I recently took part at Yuruko a program committee member, so we had 150 proposals and 50 to review by each member. But you clearly see that, oh, I saw this proposal somewhere. It's just the same, nothing like no word changed. I don't like that. I don't like that. I don't like that attitude. If you're proposing something to the conference, try to address the conference you're proposing to Make it fit the topic, the location, whatever. I think it's important. That's why we're building this one-time CFP app Just to encourage people to fill a new application every time, so maybe they come up with a better idea.
Drew Bragg:As regional conferences. I mean they're already getting more and more popular. With RailsConf going away, I expect that having only one major Ruby conference in the States next year will hopefully drive even more people to do even more regional. It'll be very helpful for them because unless you're going to do an Andy Kroll with Brighton and just hand select all of your no CFP process, I just want this person and this person speaking at this conference. Conference like unless you're going to do one of those, you are going to need a tool, and not having to pay for sessionize or deal with the clunkiness of their UI is definitely a good thing, especially when there's so many other things that go on in planning a regional conference. That'll be a great open source project for folks.
Vladimir Dementyev:Yeah, we hope so, and we also want it to be an example of building with Rails and Inertia Rails. That's what we chose for that project. The actual reason why we chose Inertia is that because the UI and front-end was mostly AI-generated using boldnew. That's actually the same. That's a project by StackBlades, I already mentioned. That's where you can just build JavaScript projects and run it in the same. That is a project by StackBlitz, I already mentioned. That's where you can just build JavaScript projects and run it in the browser.
Vladimir Dementyev:That's how we built conference website, like its initial version and UI for the CFP app. And well, it requires some manual tuning, but that's why we managed to get everything just in a matter of of week, not months. Right, right, Sure, and it looks pretty good. I think it's better than we could afford. So that's actually well, some kind of spoiler. Another idea I keep for this year we want to release a few internal Rails apps over the year showcasing different. I just want to release, I just want to open source some stuff I work on. I think for me it's just a burden when I work on some private repository for the company. So we have the CFP app, have some internal. We have AnyCable Plus app, which is our managed AnyCable solution, and actually we want to open source it as well. Maybe part of it Because why not?
Vladimir Dementyev:I want to share some code I wrote for that, for example, I share it in the blog post or in the talk, but I can't send the link, for example. So I just can't resist that. I don't want it to be hidden inside our tiny world. So and that's probably going to be serious of open source projects with some blog posts, of course, but we're going to just tell them oh, that's how we do form wizards, for example that's a code you can run and try, or that's how we style emails or configure queue components or whatever.
Vladimir Dementyev:So those apps are tiny, but they all have some cool ideas I would like to share. We'll see, we'll see. So that's the plans. That's actually part of my job as a principal engineer. I need to think about spreading the word, increasing awareness of what we're doing, what we can, and just continuously remind the community engineers that we are here on this planet.
Drew Bragg:You briefly talked, or at least mentioned, some blockers, and that is the next portion of the show is when I would normally say what are blockers that you have? So you've briefly touched on a little bit of them, but is there one in particular that you currently have that's interesting to talk about or maybe work through, or one that you've recently had that you've already solved and we can talk about how you went about solving it, like what went on to go from I'm blocked to I'm unblocked in general, my primary blocker is time, yeah sure, and destruction sure, everyone's blocker is time, and that's actually something that we can talk about a little bit is how do you organize your time, because you have quite a bit on your plate and you're a principal engineer.
Drew Bragg:You've been doing this for long enough that you've come up with your own ways of handling ongoing projects and a lot of different projects. But how do you handle managing your time when you have this many things on your plate concurrently?
Vladimir Dementyev:Well, sometimes it's just working after hours. Sure, it's not just working after hours, it's working when you're mostly capable of achieving the results. So for me, it's usually early in the mornings because I have to wake up early. We have a team in Europe and Japan. Japan is actually more important.
Vladimir Dementyev:I have to wake up at 7 am to attend some calls, so people in Japan can not wait till the very night, and that's what productivity sparks and I try to do some focused work this time. And then another productivity segment is actually closer to the night, and that's when everyone has stopped working and I can just be sure that no one's going to bother me. So I would say it's more about distributing work and effort. So if I know that, okay, it's middle of the day, it's sun outside, I'm not going to work on anything, I just want to. I just want to hang out with family, take a walk, listen to something, read the book, because I know if I start, if I have no desire to sit at my desk and stare at the laptop, I'm just not going to do that.
Vladimir Dementyev:So I better wait for this moment to come and then I sit and work and it's really efficient. So I think it started six years ago when I was my parental leave first time. I expected, okay, I'm not gonna have time for anything now. Right, I have a small human, where is that? And I can't just leave it on their own. And and I can't just leave it on their own. And it turned out that distribution of work time and do not even try to work time. That's when it appeared and it turned out to be more productive than just, okay, I have this nine to six work day. I'm going to try to fill it with useful stuff. But if you try to fill it, maybe we would think about okay, I need to fill it with useful stuff. That's doing something wrong. You just need to do that when the moment comes.
Vladimir Dementyev:And for me, of course, I've been working remotely for the last 10 years and without a strict schedule like working hours, so it was natural just to go and sit and park and start coding because oh, okay, I know how to solve this problem and then again just spend two hours and do nothing If I have a blocker and I have no idea how to overcome it, I just let it go, let it stay. Maybe someday later I will come to that. And given that I mostly work open source stuff and that's where I see blockers, because when I work on projects usually I don't have blockers, I just all I need is time. But for all this open source, like VASM challenges, there are a lot of blockers appears, but I just keep them somewhere on the surface of the mind. So I think about it all the time, even if I'm not doing any work, and at some point, okay, if I have an idea worth trying, I just sit and try.
Vladimir Dementyev:But I'm not staring at a blank page when I have no idea. When I have a blank page, I only know how I'm going to fill it. So that's the process. And actually, speaking of the blockers, right now I have one related to the Rails weapon, boson, which I haven't yet figured out, and that's why I haven't started working on that. There is one gem that Rails depends on, that's been causing issues to many developers, and it starts with N. You probably know the name of this gem Nokogiri yes.
Drew Bragg:Yeah, okay.
Vladimir Dementyev:I was going to say, if it's a major gem that starts with N, it's Nokogiri. Yes, yeah, okay, I was going to say if it's a major gem that starts with N.
Vladimir Dementyev:it's probably Nokogiri yeah so unfortunately right now I don't know how to make it work on RASM. So the Nokogiri C extension, at least as far as I know it's not compilable to RASM. It requires some C coding probably to make it work. I'm pretty sure it's doable, but my level of my C knowledge is not enough. I don't want to waste time on that because that's the kind of work when I don't know what's going to be the result. I try to avoid that. I try to explore other options.
Vladimir Dementyev:But at this point we have an action text part in the Rails tutorial options. But at this point we have an action text part in the Rails tutorial. Action text depends on Nakagiri for parsing HTML and unwrapping attachables and I don't know how to make it work. I already made one attempt to solve this problem. I found pure Ruby Jam that does HTML parsing and transformation. It's kind of abundant. I updated it to modern Ruby version. It kind of works, but it's not like API compatible with Nakagiri and I managed to make it probably 70, 80% work.
Vladimir Dementyev:Extra text work with this Jam, but it's always the last 20% that's most difficult. So I just stopped and that's another probably way of managing time. I agreed with myself so that I have two hours to try this approach. If I'm not going to make it work or see the light in the end of the tunnel that I'll just stop it here. I'm not wasting my time on that anymore. Maybe next time maybe I'm gonna ask some of my effect engineers who in between projects to do that. But that's where I'm at right now and I don't know. I'm gonna do that. Well, we still have a month to rails conference to solve this problem and I always have a plan B. Oh, if I'm not going to solve the action text problem, that's going to be a few slides and my talk. Oh, the problems we have and they are not solvable yet. Oh, action text.
Vladimir Dementyev:And we're just going to skip this part of the tutorial Not a big deal. So yeah, that's an example of actually blocker. That kind of bothers me. I always think, I keep it in mind but still haven't had a solution. I'm thinking, actually, when Mark Roth announced his new herb project, which is a ERP parser, whatever an HTML parser, I started thinking maybe that's the way to go. Maybe we should just make action text, not Kagiri less, but use like herb instead. So I have some ideas to try, but I just let this blocker itch me from the inside to the point that I either give up and just throw it away completely or I find a cure right. So right now I don't have the answer to this problem, but that's going to be interesting, I think. Maybe.
Drew Bragg:It doesn't solve the problem of solving it before RailsConf. But worst case scenario, if you do show up at RailsConf, going well, we don't have action text working, but everything else does. I'm pretty sure Mike D'Alessio and Aaron Patterson will be at the last RailsConf. You can just say, hey, any thoughts of making Nokogiri WASM compatible? Maybe they'll be like, yeah, well, I don't know, They've been working on that gem forever and a day, so they probably know the ins and outs.
Vladimir Dementyev:Well, actually I don't even know. Maybe it's actually WASM compatible, but it's not just easier to compile, I don't know Well. Well, the whole building pipeline for ruby vasm is just a black box for me, because when you like, try to compile vas model including your dependencies and c extensions. Some extensions are compilable, some not. I don't know why. I don't know what's happening on the hood, because there's a lot of commands, like with some compilers, tons of flags. I don't know how to do that, and maybe someone smarter than me will eventually make it less tricky, because we want Ruby Wasm to be. There is a concept of component model and Wasm when you can actually compile dependencies independently and then stitch them together into a single WASM module or even load independently into the runtime and connect to each other through the interfaces, and that should solve the problem of having everything compiled separately. Probably that will simplify the flow, but I'm not there to just contribute to that. Unfortunately. That would require a lot of time just to learn how things work, even in the age of AI everywhere. I'm not sure it's going to be helpful for me. You need to learn a lot of stuff for that. Speaking of blockers and I started talking about this. I want to share one interesting blocker we had at the project actually where we managed, I think, to find a solution and I think it could be useful. Maybe it's kind of relevant to many Rails projects. So we have a client with well, it's a pretty large Rails application and we help him with performance issues and that's the performance issues of this, to give you an idea, idea what we're trying to do. So we're trying to tune Garbage Collector at the level where we fight for every dozen of milliseconds of latency, so it's not just M plus ones and all that stuff. So it's more about at the VM level.
Vladimir Dementyev:And right now we're exploring switching from Puma to Pitchfork, which is Shopify's web server. We expect it to give us a better utilization of resources and better results in terms of latency, first of all because we don't really like threads that are not good for latency, especially like B95 and so on, so they affect that because, well, we have this chill, so we want to go all in with processes, but we want processes to fork and share memory efficiently, and that's where pitchfork is coming from. And we found that for typical rails application like modern, it's not possible to use pitchfork due to the vips, leap, vips dependency, because it's not kind of fork safe, so it runs a lot of c threads internally and they're not forkable. And that's was the blocker. For us to give pitchfork a try, or the same new as a kind of Moldfork, I don't know what is it. Okay, that's again something I haven't touched myself, just my teammates.
Vladimir Dementyev:But we were thinking about okay, how can we simplify the problem? If you have a Ruby process with Sleepweeps running and doing some processing and then you want to fork it and continue using it as a web server, the WIP's integration is going to be corrupted the one that was in the original fork and in the new fork there is some problem at the C-level, so we cannot really fork it. You just need to kill the process and spawn a new one, but you cannot refork. So refork is not possible. And refork is important because we can share as much memory as possible. So we don't need to and not just share memory. There is no like warming up memory stage, so latency is not increasing when you refork. And we were trying to think okay, what do we do? We can fix WIPs. But we found that actually Jean Bousiel already approached WIPs offers, mentioned this problem and they were discussing it, and it turned out that it's much trickier than it seems because there are a lot of non-shareable resources and at the WIPs level there is no just easy way to do that. And now we came up with the idea and my team is going to implement it and see if it's going to work.
Vladimir Dementyev:But that's actually the beauty of again, the Ruby openness and Rails openness. So we have an image processing gem that uses libvips through native extensions. But technically, image processing has just a few APIs that are called by active storage to transform images or get some information. What we can do instead of calling directly the C extension, we can put this tiny Ruby daemon with VEAPs running into a separate process and communicate with it through GRB, for example. And just generating a new adapter for image processing is going to be not just VEPS but VEPS daemon, and in this case we don't need to fork the VEPS process. It's going to be just running every time and we can fork the Rails process and refork is going to work because we don't have VEPS loaded anymore. That's what we're trying to achieve and that's actually similar to what I do for Basm.
Vladimir Dementyev:If something doesn't work, we go layer by layer from the implementation to the Rails and find the layer that we can hijack, inject our implementation, keep the API compatibility and just instead of weeps, for example, in the browser, if we want to have image processing work in the browser, which is I don't know if we want, but anyway for Rails we can just, instead of calling T extension or internal process, we can just call WIPs compiled into VASM and running in the browser outside of the Rails VASM through the JavaScript interface and that's going to work. So that's the kind of thing that we can do when a language is open, like runtime is open, right, ruby is open and B the framework is kind of well-architectured in terms of high coupling between implementations because Rails is not coupled In most places. We have layers in Rails, naturally, because most Rails abstractions are pure Ruby abstractions, and then we go down to the actual implementation and this combination. That's what makes it possible to do many things with Rails. On VASM, not on VASM, the same idea applied. Something we learned from dealing with VASM was applied to production application on regular Rails. So that's just the same idea, the concept which we ported there.
Vladimir Dementyev:I'm not sure it's going to work. If it's going to work, we're probably going to write about it because it's cool. That's very cool. That's why why coming back to the fact that I mentioned about Laravel, so why we go into that direction? Because we want to try new things, try to see how our tool, our software, works in a new environment. Probably we're going to find some problems that could later be ported back to Rails to solve similar problems, right? So that's like traveling across the world and learning from different cultures and then accumulating the best parts, or trying to reuse someone else's knowledge to solve your particular problem, because you can see someone else's or whatever, and that could be done in software as well.
Drew Bragg:That's awesome. That's an awesome way of figuring out your blocker and sharing those learnings from. I don't want to call the Rails on Wasm project like a toy project, but this is not client work. This is not your primary job. This is something you're doing for a conference talk, but it's giving you those learnings that are helping you solve a real client problem and that's the best when you are like I got myself unblocked and I've learned this new way of doing it and now we've got this whole new way of solving a problem that we were completely stuck on before.
Vladimir Dementyev:And I think that's actually an important aspect of learning and why we should continue learning and not just orchestrating AIs and whatever, because it's not important that I have learned how to do some crazy stuff as Rails and VASP. It's important that I learn the technique right and that kind of a critical thinking. So that's why important actually to learn even like abstract things like mathematics. I learned a lot of stuff that I never gonna use in my life right, who cares about that? But I learned how to solve abstract problems and the technique I learned I could apply to real-world problems, and the same here. When you solve in one problem, what's important is the experience of something that's left not in the code but here in your mind, and that's what we should aim for, I think, as engineers.
Drew Bragg:I can agree with that wholeheartedly. The last question is going to be a really tough one, because you have talked about so much cool stuff. So much cool stuff that borders on new too, like I have heard of the Ruby Wasm. I knew about your talk because I'm on the programming committee. It's not terribly new, but there's probably a fair amount of people who are listening to this going wait, you can do what in who with the what, but because the question does not require it to be coding related, but it can be, I'm going to ask it anyway and you can take a minute to think about it if you'd like. But what is something cool, new or interesting that you've recently learned, discovered could have been built? Doesn't have to be coding related, but it can be just. What is something that you want to share that you're just like. This is cool and made me excited and I want to share it A few weeks ago I attended a large BriggsCon.
Vladimir Dementyev:It's called Briggs Cascade, it's like LegoCon in Portland, oregon, and I was born and raised in Russia and we had Lego years after everyone in the world had it and we just had a few stores in the country and so on. But attending an event and seeing that people doing cool stuff actually. So there are different kinds of people. Like someone preserving old collections you can see Lego from the 70s, 80s, 90s, from your childhood and someone just building huge installations with a lot of stuff. And that's something that was new for me because, well, I've never seen anything like that.
Vladimir Dementyev:I'm not attending any conventions, except for Ruby and Rails conventions, right, but that's a different kind of hobby. I don't think it's a hobby actually for them because I take a lot of time, but that's the way of living with this technology idea, whatever. Like passion, I've seen people passionate about Lego bricks as something new to me because like, wow, it's a bit of envy because, well, I could not afford dealing with, like building a million pieces, copy of some building in Lego or whatever, but it's really cool to see people doing that. They're not doing that for money, obviously, right. They're doing that because they love that and that's always cool to see people enjoying what they're doing, right? Yeah, I can't say that about myself all the time, right? Any software engineer, engineer? I don't think a lot of people enjoy that, to be honest. So seeing that there is another way of enjoying what you're doing is cool.
Drew Bragg:I'm with you. Yeah, as a kid who grew up with Legos, I can confirm they are awesome and fun and probably influenced my decision to become a developer. There's a lot of parallels between you're just taking a bunch of bricks and building something by layering on on top of one another, and so I've never been to a Lego convention, but it's always been on my list of like. That would actually be kind of cool to go just because I've seen pictures, but seeing it in real life is always better. Of some of the stuff these guys can do with legos is like I've been playing with legos for over 30 years now well, over, holy crap. I'm not gonna do that math.
Vladimir Dementyev:I don't think I could do that, and these guys are building huge and I think it was even better than legoland, for me at least, maybe not, maybe not for kids, because we also went to Legoland this year with my son. It was cool oh, I guess something you saw on TV when he was fighting. Now you're there, but the convention is just different and we actually have one big coming to Seattle in September. I guess it's one of the largest in the States. So I would definitely recommend checking that kind of events locally. Yeah for sure, just to hang out, just to shift the environment, to see something different.
Drew Bragg:Building a Lego set feels a lot like building software, but it's much more tangible and you can probably learn from that.
Vladimir Dementyev:Now, when you know both, you can see how people build. Now, when you know Buff, you can see how people build Legos and you can say oh wait, I can structure my application like that.
Drew Bragg:That's going to work, why not?
Vladimir Dementyev:I can't imagine that as parallel universes, they all work by the same rules, actually under the hood. Fundamentally, we just need to dig deeper to find this.
Drew Bragg:Yeah, there's a lot of overlap in places. It all comes back to like you were saying with mathematics, like that joy of problem solving. Yeah, that I think a lot of developers have just like this joy of solving the problem, figuring it out. That is not unique at all to software engineering. That goes everywhere. So you can practice your software engineering skills by getting better at problem solving, by doing other things, so that you're not burning yourself out.
Drew Bragg:Oh, I just worked 10 hours on my work project and now I'm going to work another five on my personal project and then the next day not want to look at code ever again. Like you can say, I'm going to go build a Lego set and still be helping your brain figure out how to be a better problem solver, a better builder, better at thinking through layers of abstractions without actually continuing to stare at a screen or code. I think that's a good one, very cool. So where can people find you and all of your projects and all of the cool things you work on on the internet? Where is the best way to connect with you?
Vladimir Dementyev:I'm on GitHub mostly, so that's the browser tab. I have all the software and that's my social network. That's what I communicate the most and social coding. I post some stuff on Twitter and evilmartianscom, so, where we have also other announcements and stuff coming on, I think it's just free primary.
Drew Bragg:Yeah, I'll put your links to your github, your twitter, evilmartians. I'll put a link to SFRuby's meetup and the conference all in the show notes. So if anybody was inspired after listening to the episode, check out the show notes and you'll find all the links there. It was awesome having you on. I feel like we could have talked for another hour on all the things that you're working on, so we'll have to have you on again, maybe a little closer to the San Francisco conference and we can talk a little bit about the conference actually yeah, there you go.
Drew Bragg:We'll talk about some of the cool things you learned during that whole process, but thanks for coming on.
Drew Bragg:I really appreciate you taking time out of the day, great, great talking to you, great conversation hopefully I'll see you at the last rails, conf and listeners, hopefully I will see you there too. Tickets are still on sale even as this episode is coming out. You should definitely come to Philly, have a bang and cheese steak with me, and Andrew Mason and Chris Oliver and everybody else in the community hope to see you there and we'll see you in the next episode. Bye.
