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 55 - Joe Masilotti
When Joe Masilotti scanned a conference badge QR code at RailsConf, he was immediately uncomfortable with how it added someone's phone number directly to his contacts. That friction point sparked the creation of Ruby Friends – an innovative app transforming how developers connect at conferences and meetups.
In this illuminating conversation with Drew Bragg, Joe reveals how Ruby Friends provides a "lighter touch" approach to networking, letting users create shareable profiles with conversation starters and contact preferences. The technology works through both QR codes and NFC tags, creating an almost magical experience where simply tapping a badge can instantly connect two developers. With nearly 400 profiles created in just weeks, it's already gaining traction in the community.
Joe also takes us behind the curtain of his two-year journey writing the Hotwire Native book. What began as documenting Turbolinks Native transformed mid-project when Hotwire Native was released, requiring a near-complete rewrite. His candid discussion about working with publishers, managing complex Git histories, and balancing documentation with rapidly evolving technology provides valuable insights for anyone considering technical writing.
We also explore Joe's difficult decision to shut down RailsDevs after nearly three years and $250,000 in revenue. His thoughtful analysis of changing market conditions and knowing when to sunset a successful project reveals the business acumen required alongside technical skills.
From creating privacy-focused analytics solutions to implementing NFC technology for seamless connections, this episode demonstrates how Ruby developers continue creating tools that strengthen community bonds while solving real-world problems. Whether you're interested in mobile development, writing technical books, or building community-focused applications, Joe's experiences offer valuable lessons about innovation and adaptation in the ever-evolving tech landscape.
Links:
HoneybadgerHoneybadger 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 your host, drew Bragg, and I'm joined once again by Mr Joe Mazzalotti. If you haven't listened to Joe's previous episode before, I highly recommend you go back and do that. But for anyone who hasn't listened to that episode and doesn't want to go back now, I will have Joe do a quick introduction For anyone new to him. Joe, please introduce yourself to the listeners.
Speaker 2:Hi everyone. My name is Joe Mazzolotti. I am a Hotwire Native developer, consultant, content creator I guess you want to call it that. Do a blog, youtube, all that stuff, newsletter. And I just got back from speaking at RailsConf on a workshop and will be also at RailsWorld doing a talk on HotWire Native there as well.
Speaker 1:So Joe knows how this works, since he's a repeat coding coder, but anyone new to the show. The way this is going to work is I'm going to ask Joe three questions. I'm going to ask him what he's working on, what kind of blockers he has. If he doesn't have a current blocker, he can talk about the most recent blocker he had and the steps he went about to solve it. And then the last question, my personal favorite, is what is something cool, new or interesting that you've recently learned, discovered, built? It doesn't have to be coding related, but this is code and the code encoders who code it. So it totally can be Without any further ado, because there's lots to get into with you. Always, joe, what are you working on?
Speaker 2:So, the stuff that just finished, which I'm super excited about, is my book on Hotwire. Native is with the not the copy editors, but the layout editors right now. So that is the last step of the book before it hits the printer and on Monday I'm supposed to hear back from them. I give them one big thumbs up that everything looks good, unless I find some minor tweaks, and it goes to the printer on Tuesday or Wednesday of next week, which is really exciting. It's been two years since I started writing that, so that is kind of the big relief there, which has been fun. But what I'm working on now is something called Ruby Friends. It's rubyfriendsapp and this was inspired from RailsConf.
Speaker 2:Everyone had their badge at RailsConf that had a little QR code on it, which I thought was awesome. It was like scan this QR code, maybe get someone's email address or social profiles and stuff to keep in touch. But the way that it was implemented by the badge maker or whatever was that it opened up your address book with that person's phone number and it was just a little too much for me. It was a little too aggressive. Like I met someone for the first time six minutes ago, I don't really want to add your phone number to my address book. Sure, that's a little aggressive, so I didn't end up using it very much.
Speaker 2:But I realized that I saw people scanning the QR codes the whole time and then kind of getting freaked out. So I was like, well, what if this was just a little bit lighter touch? What if, when you scanned a QR code, it was a couple of links that you provide, maybe a sentence about what to talk to you about at the conference, your picture, so people remember who you were when they see you the last conference you were at? Like things like that. That would just help foster relationships a little bit better and kickstart them past that awkward icebreaker phase where it's like hi, I'm Joe, what do you want to talk about? And it's like, oh cool, it says right here that you like here that you do cool stuff with SQLite. Tell me about that. And now someone's five layers deep and you just met this person. So I'm building that. It's a Rails app, ios app is in the App Store and working on Android now, which has been really fun.
Speaker 1:Yeah, I think that's a great idea. I mean, the Ruby community is awesome. There is always that little bit of awkward. How do we start this conversation? But to a lesser degree in the Ruby community, because we're all just friendly, yeah, but it is, without a doubt, the number one question that comes up anytime. New people are like we ask hey, what do you want to know about going to conferences? New people are always like well, how do you talk to people? How do you know what to talk about, how do you engage? And it's like well, this sounds like a perfect solution to that. It's like these are the things to talk about with me.
Speaker 1:And I really like that last conference idea too, because that's a really good way of going. Where do I remember you from? And, instead of having that weird back and forth, be like oh, I remember you from this conference where we talked about X and that is a very cool idea. So was that just an experience that you had with RailsConf, or was that people talking about their experience? How did that idea go from? Meh, okay, this is a thing to let's build an app.
Speaker 2:It was primarily from me being from scanning someone's qr code and just being like I want to keep in touch with you but I don't want to call you or text yeah, sure, I want your email address.
Speaker 2:I want to follow you on twitter or whatever. I want to maybe connect with you on linkedin, and I saw people doing it at the conference, like scanning QR codes and being like, oh, it goes to my address book. It showed the exact emotions that I was feeling from it of this is done well or this is the right approach, but it's implemented the wrong way. For me, for developers Like maybe at a business or a sales conference, a phone number is the right choice, but as a Ruby developer, I'm not texting my Ruby friends, right. I'm talking to them over email or on Blue Sky or tweeting at them or something about a question that I want public. It's a different relationship. And if it goes six months a year and I'm still still talking to that person, like, yeah, maybe then I'll text them or whatever, but that's not. I just met you, let's do this. At least that's how I felt.
Speaker 2:And yeah, as of this morning, there's over, I think, almost like 400 profiles on the site, which is really exciting, and people are using it. For someone used it at a local meetup the other night, which was fun. I ran a local event in Portland. That was, the four of us just grabbed a coffee and one person was already on it, which was cool. They like scanned my QR code and then someone next to me I scanned theirs, and then the fourth person created an account and we all hacked on some NFC scanning for the app together as well, which was really cool.
Speaker 2:So the idea is like, instead of a QR code, you could actually just tap your phone to a badge and it would open in the app that person's profile, which is wild because you don't even have to like unlock and open the camera and point it. It's just like you just tap someone's badge and you have their profile right there. So it's even less friction than a QR code. I'm excited to get that out because I think it's something that is unique on the market. These exist, these make a friend at a conference type things, and they're mostly centered towards sales folks and that type of conference, but there's nothing specific for the developer or even the Ruby community.
Speaker 1:I'm sure there's a lot to it outside of just cool. We have an idea for an app and we build the app. And now what that would be where, like, yeah, I can build this, but getting it into people's hands I feel like you're almost the right guy to do that. You have a fair amount of experience building stuff and then getting it to people. Last time we were on the show, you were doing Rails devs, which was pretty successful. You got a lot of people hired that way, and that was really cool. You got a lot of people hired that way, and that was really cool. You want to talk a little bit about what happened to Rails devs and anything you learned from doing Rails devs that you think you can apply to Ruby Friends.
Speaker 2:So Ruby Friends started as a for fun thing. Maybe there's an angle that I talk to conference organizers and they pay to have it integrated into their badges or whatever, but like right now it's kind of just a for fun thing for the community. Maybe it'll be open source, I'm not sure. Rails devs was more of a business and for those that haven't heard earlier this week, so the end of July I shut down Rails devs. I announced that it'll be shutting down and on August 15th it will be no more.
Speaker 2:The decision to do that after running it for over two years almost three years there was really hard. It was a really hard decision. But I did it for two big reasons. The first one was that when I launched Rails devvs we were in a very different market with hiring, especially in the Ruby community and the Rails community, and there were more developers than there were jobs to get their profile in front of businesses and for businesses to save money on hiring fees by just finding the person and connecting with them and then taking a small cut instead of a 25, 30% cut that a recruiter would. And the market has changed. There are way fewer Ruby and Rails jobs out there right now for full-time gigs and the business model of RailsDevs was to take a hiring fee percentage to keep it afloat. And it made good money. It made over almost $250,000 in those years. It was no joke.
Speaker 2:But the problem now is that to shift it towards where the market is, which is more part-time and consulting and not W2, but 1099 employees. I don't want to shift the business model and try to pigeonhole all the developers that are in it looking for full-time work to then be just expected to do part-time work. And it felt dishonest for me to keep it running when there isn't a paid customer. This month, for the first time since the business started, this is the first month that it won't bring in revenue. In all the years that I've been running it, every single month I've had a paying customer or a signing fee, and this is the first time that no one is paying.
Speaker 2:So I was like, okay, if I'm going to do it, now is a really good time, because this is the least upset people are going to be. So that was the big reason. The second one is that, even if it didn't take a lot of time for me to manage and run, it still took non-zero and I don't want to focus on something that is not best for the users that are using it anymore and not best for me. So I'm focusing on what supports my family and what brings in money, which is my consulting business, my bridge component library that's paid and the book and all that stuff things that actually can support my family, not I have and don't want to get rid of.
Speaker 1:It is definitely something sad to see go. I'm sure even more for you, having built it from nothing, but totally understand the reasonings and the rationale behind shuttering it. What are maybe not business marketing, since they're two different apps, but going from no one knows what Rails Devs is to people are using Rails Devs. What are potentially some of the things that you learned that you think might help make Ruby friends? I mean, you said there's already people using it and there's already people on it, so you already have some visibility there. But is any of that because you already know how to market from Rails devs or is it more organic and here's things that you might do? Is there any crossover there?
Speaker 2:I think that one of the things that really helped with getting Rails devs off the ground was that folks could create their profile and share it with the world. And the same thing is happening with Ruby Friends. Developers are getting in there, they're adding their profile, they're adding all their links and they're saying here's my Ruby landing page, essentially, and they're posting it on social media. They're putting it in their bio sometime, which is really cool to see. And something very similar happened with Rails devs at the beginning, where developers were just so excited to have a public profile for this type of stuff. Obviously, the goal there was different, because they were getting hired right. The end goal was that they were getting hired. The end goal with Ruby friends is that they're going to have friends at conferences. For some folks, that's way better someone who's happy at their job.
Speaker 2:It's interesting how the market is bigger for Ruby friends than it was for Rails devs, and not just because it's Ruby versus Rails, but because everyone who is in the community could be on Ruby friends. Only folks that wanted a job or wanted to get hired or didn't you know, were okay, their boss, knowing that they were looking for work, could be on Rails devs. So I think that the market is actually bigger, but is there a way to monetize this and turn it into a business? I don't know. I have a lot of ideas. We'll see. Right now, it's just been a lot of fun. I want to get all of the features on iOS and Android out the door. I've only been working on this for like three weeks at this point, so it's been fast Redscum was not that long ago.
Speaker 2:Yeah, if it ever becomes a business and I end up paying my render bill every month, that's fine, but I've already used it myself and gotten value from it, so I broke even there already.
Speaker 1:I know you've talked a lot about in your own social profiles. I've heard you on other podcasts talking about it, so I don't want to rehash those conversations completely, but I would be remiss if I didn't just ask about the book. I'm excited for it. I think it's the end of august, right that it should be physically going out. I have it on pre-order. I'm excited because I'm still physical books. I've tried eBooks. I just can't do it. I've tried so hard. Very excited for it. So you've been working on it for two years. What has been, I don't know, the most challenging, the most rewarding, the most interesting part of writing a book, this book.
Speaker 2:The most interesting thing is working with Pragmatic Bookshelf. They're my publisher for this and one of the most interesting things is that I write the book in Markdown with some special XML tags the PDF, the web version, the physical print book and they have this huge proprietary thing that I can't really even say more of about. It's like under NDA. It's wild. But what's been so fascinating for me is that I've always owned my own tool chain. I've always published to a blog. That's like written with Jekyll, or I'm doing button down for a newsletter and it's just marked down or what have you To have? To use someone else's build chain and to use SVN versus Git has been this like whole layer of what the F on top of writing the book. That has been really fun to learn and pick up. That's been really interesting.
Speaker 2:The most surprising thing was how much of this book I had in my head before I started writing. I've been doing Hotwire Native. I've been doing it for seven something years Hotwire Native, Turbolinks Native. When I started writing, the first six of 10 chapters just fell out of my mouth essentially and into my hands. I have been thinking about this and writing about it and doing this for so many years that I got the first drafts of the first couple of chapters done in a few months and everything else was editing and screenshots. And Hotwire Native went to a 1.1 release during that time so I had to redo an entire chapter.
Speaker 2:Android Studio was updated, so I had to redo all my screenshots like always things like that. Ruby was updated four times. Rails 8 came out, so like there's all these things that I had to do during the process, but that first just word vomit of pretty coherent text was so inspiring to get me that zero to one and I was in beta very quickly, like compared to how long I expected to be out of, like pre beta, like before anyone could actually see it. So I don't know if anyone's thinking about writing a book. If you have a lot to say and you could write a lot about it, like go for it. Lot to say and you could write a lot about it, like go for it. But I can't imagine taking any longer than two years because I am so ready to have it on my bookshelf.
Speaker 1:It's been so long. So you just mentioned technology changes pretty quickly, which caused a lot of edits for the book. What, if any, is the plan for, as Rails continues to release, ruby continues to release Kotlin, swift, the other technologies that are adjacent to the book continue to grow. Like, is it a okay, every year we'll cut a new release with just a couple of tweaks, or is it no, you're on your own for figuring it out, or we'll wait until they're super major? Like, is there a plan and, if so, what?
Speaker 2:so prague's been doing this my publisher for decades. At this point, like, yeah, like they have their own plan for like they're writing books about technology. They know this stuff changes and what we've decided on for this book is that every time there's a feature or like a new language or framework or gem or whatever introduced, there is a version attached to it for the book and the idea is that book not in its current state, but like that book with those versions will always be correct. Because you know that you're running rails 8 0, not 8 1, not 8 0, 1. It's like it's running rails 8 0. Or you know, whatever the version number is, we're running hot wire native 1.2 on ios.
Speaker 2:1.2.1 just came out, I think yesterday, and it doesn't introduce a breaking change that's related to the book, but like, if you're on 1.2.1, well, you're not running the version that's with the book. So things might be different and there's no guarantee. So that's the first step. The second step is when breaking changes are introduced. Every single page has a link at the bottom on the PDF to report errata and that page will say hey, here are all the breaking changes since Ruby, whateverx, was released.
Speaker 2:Here are the breaking changes that Hotwire introduced at this version. You can also type in manually if you're on the physical book, but there is a RADA that is reported, reproduced and then outlined on the site, so that's kind of like a living document. That's the stop gap for the physical book owners until the next version is released, because the PDF, if there's a breaking change, the PDF will get updated. If it's a couple lines of difference, like, we'll just update the PDF and release a 1.1 or whatever. Long term, there will most likely be a second edition of this book in maybe it's a year, maybe it's two years, maybe it's when Hotwire Native 2 comes out or whatever, but I don't see this being the last version of this book.
Speaker 1:How drastically in your experience, since you are the Hotwire Native guy, in your experience thus far, how drastic are the changes when a new version of it's a long list right, it's Rails, it's Ruby, it's Kotlin, swift, it's the Android Studio, oh yeah, x tools, I guess I don't know, I don't do when those things change how drastic. I know you had to update the book so that it was current, but how much A whole chapter's worth, a couple of pages worth, like how drastic changes are happening in this ecosystem yeah.
Speaker 2:So let's start low level and go up. Ruby none like recent versions of ruby. There's nothing really fancy that's happening that I had to change at all. Swift is pretty stable. There hasn't been anything really new there. A bunch of new stuff was released recently and like the next one is going to be Swift 6, which breaks a lot of stuff with concurrency, like two things happening at the same time and threads and stuff. But I'm hoping that will actually all be handled internally in like the Hotwire native library. So all you have to do is say I'm running Swift 5 or Swift 6 and that'll be fine.
Speaker 2:Kotlin 2.0 came out not too long ago, so I made sure to update to Kotlin 2, which was nice, and I did that before I started the Android project, which may save me a lot of configuration issues. But then we start to get to the ones where actual changes were made. So Rails was updated a few times during this and I don't think I had any changes that I had to apply, which was crazy. Like if I had created a project with a new Rails 8 generator, I would have gotten like the PWA stuff and the authentication and all that built in. We're not doing a PWA. I rolled my own authentication to show the shortfalls of it and how to improve it. So that didn't matter. And we're using Noticed for sending push notifications, so the action notifier not that it deals with iOS or Android like wasn't an issue. So the Rails update didn't really matter either. The Rails update didn't really matter either.
Speaker 2:Hotwire Native was bumped from 1.0 to 1.1, 1.1.2, 1.2. Eventually 1.2 introduced a whole new layer of managing tabs, so I have an entire chapter on tabs. That entire chapter had to be rewritten, the whole thing. And like I knew that it was coming, I built the Hotwire Native one for iOS. Like myself, as a maintainer of the library, I knew it was coming, but I had to write it as if it wasn't out yet because I didn't know when it was going to be released. So that was kind of rough.
Speaker 2:But the worst part was that I started writing this book before Hotwire Native came out. So when I started writing this book it was still technically Turbo Native. So the pitch that I had to Prague was Turbo Native for Rails developers, blah, blah, blah, blah. So halfway through, maybe six to nine months through writing, the book, hotwire Native comes out, is public. I have to not only rename all the files, all the things from Turbo to Hotwire. But I have brand new concepts to cover and things to explore and that was almost a full rewrite of the book because so much changed from Turbo to Hotwire In a good way. I got to delete a lot of stuff because Hotwire Native handles a lot of the stuff for you now. In a good way I got to delete a lot of stuff because Hotwire Native handles a lot of the stuff for you now. But I pretty much started over.
Speaker 1:Wow, that's wild.
Speaker 2:Yeah.
Speaker 1:Not fun, yeah, especially with something like as cohesive as a book. You don't just write a chapter and then move to the next chapter and the other chapter is just gone. You build on top of each chapter. Each chapter potentially can reference the other. Any breaking change in a chapter might influence countless others, so that's wild.
Speaker 2:So a little bit of insider knowledge here. Each chapter adds a feature to the apps. So one adds authentication, One adds push notifications, One adds modals and stuff like that. But each chapter you're building one app, so you're building on the previous chapters 100% Like. You can't just open chapter six and like do chapter six.
Speaker 2:You could take the code from chapter five because I have it all public and you can just download the source code and start there. But you need that as a starting point because it's referencing all the other stuff in the book. As a starting point because it's referencing all the other stuff in the book which made for the first time in my life, my Git history actually mattered. I had to have perfect commits because each commit said chapter one, checkpoint one, blah, blah, blah, chapter one, checkpoint two. And then I had a script that walked through each of those commits and created a snapshot in time of the entire code base in a folder.
Speaker 2:So if at any point in time you could say, hey, I'm on chapter four, checkpoint three, I open chapter four, checkpoint three, folder. I have the Rails app, the iOS app and the Android app at that current state that I can then play with or kick off with, or compare it to, my local version. So no matter where you pick up the book, you can have a reference point, but you've also, if you get stuck or have a typo or whatever or miss something, you have it all as the safety net every step of the way. I think there are 70 something commits throughout the book. So I got really good at interactive rebasing.
Speaker 1:Really good. I was going to say, if you weren't already, you got really good with Git through that process.
Speaker 2:A lot of interactive rebasing.
Speaker 1:Yeah, it's funny because you hear I'm writing a book and you wouldn't think like I'm also writing an app. I'm also getting ridiculously good at Git. I'm also learning SVN now because why not when this proprietary markup converter? It's just because, why not when this proprietary markup converter is just so funny to be like, yeah, writing a book, you just write it, right, yeah.
Speaker 2:And that's what I was like I wanted to do. Right, I still, even though I learned all that and I had to do all that, I still did way less and focused way more on my writing than if I'd self-published it, Because if I self-published it, I would still have to do all of that, but then I would also have to worry about finding an editor and finding a copy editor and a layout person and a designer and publishing it and finding someone to publish. All of these things that Prague is doing for me, that I definitely did not want to deal with.
Speaker 1:I do want to change gears a little bit. You brought it up in your intro you just recently gave a workshop at the last RailsConf on unsurprisingly Hotwire Native, but you've also spoken at conferences before. This isn't necessarily your first Roto. Was this your first workshop?
Speaker 2:This was my first workshop at a conference.
Speaker 1:Yeah, okay, I know you had done some workshops on your own. I was referring to conferences. So I remember having the conversation with the program committee about like hey, what talks would make for good workshops, and I saw yours and know your experience. Now I'm interested in real time live, putting you on the spot. What do you think about giving conference talks versus giving conference workshops?
Speaker 2:I have a lot of different points of view, so I'll start from the audience. The. What I taught, I think, was way better for a workshop for the audience. They were able to follow along and build an iOS and an Android app in those 90 minutes and walk away with something that they had on their machine, that they wrote the code for, and that is not what you can expect from a talk, no matter how good your talk is Like, no one is going to be live coding with you. So, from an audience perspective, I think that they walked away with a ton of the stuff that, matt, like the muscle memory they walked away with. Oh, I actually feel comfortable in Xcode, or I know that this little button is supposed to be over here in Android Studio and not over there like in my IDE. You know that I write my Ruby in, so I think that was extremely effective for what I taught, which was how to get started. I do think that they left with more questions than when they came, though.
Speaker 1:Well, I mean to to be fair, it's a pretty deep topic. I almost wouldn't expect this to be like that. Everyone walked away from the. I know everything there is to know about hotwire native now, but like I definitely just opened up cans of worms there.
Speaker 2:The tricky part is that I told everyone in slack, like, make sure you have xcode downloaded, make sure of android studio, and a lot of people did, but, but some people didn't, and I had a hard drive that I just passed around that had both on it, like had Intel version, had a Mac or Silicon version, and I think like seven or eight people were able to download it from that. The problem is like as soon as you open Android Studio, when you create a project, it has to do a bunch of networking to download dependencies, things that you can't expect someone to do on their own. So what? I think the worst part was that, no matter how good the hotel Wi-Fi was, if you have 45 people downloading something at the same time like a couple hundred megabytes each at the same time it's going to be a bad experience. So that was really tough because, short of spinning up our own network in the room that we were in, I don't know how we could have made that better. And that's the stinky part about doing native development is like you need to do Android, you need to do iOS and you have to have those IDs open and they have dependencies. So that was a little rough, because I'm not sure how many people actually made it past the android studio install, because there's the first person who downloaded it, got all the bandwidth and like good luck everyone else.
Speaker 2:From my perspective, preparing for a workshop especially that workshop versus preparing for a talk was like one% as difficult, because I have done this workshop in some shape or form, online or to local groups or to businesses as they hired me for. I have done most of that. I could do that with my eyes closed at this point. So you got a cheat code. Yeah, like in terms of okay, so my Rails world talk. Two years ago, I spent 90-something hours preparing for it, for this talk, for this workshop, I think I only spent 15 hours. That is a drastic difference in terms of a talk versus a workshop, and I love to spend less time and get the same value out of it. Of course, absolutely same value out of it, of course, but I also think, if I'm thinking long-term, I got a lot of developers in that room that will go on and make their own apps, which is great. I taught them how to do something new and exciting that day.
Speaker 2:But for my business. I want to be talking to the CTOs, the founders. I want them to hire me to have me build the apps for them. So there's also conflicting business of doing a workshop versus a talk because of just who is going to be listening the most. So short answer I loved it. It was great to do a workshop. It was way less pressure for me. I'm glad I got to go to Philly and not pay for a ticket or a hotel. I can't complain about that. I had some great cheesesteaks. For my business is a workshop the best thing to do? I?
Speaker 1:don't know.
Speaker 2:Maybe not, but it was fun to experiment with and it was fun to try.
Speaker 1:Yeah, I wonder how many of those devs might bring the Hotwire native basic knowledge back to their job that will springboard. Hey, we should build native app because we can actually do it. Hey, let's bring Joe in to get the whole team up to speed or to get us past the. This is the easy part, I wonder. Yeah, we'll have to check in a little bit and see if any. I assume you like when you take on a new client, they tell you where they met you or heard of you from. So I'd be interested to see if that workshop does end up helping the business.
Speaker 2:Me too. I totally agree this was an experiment, like I have assumptions on it, but who knows, maybe this will actually be that those were all lead developers who are now leading their Android, ios projects and they need me to come in and help them. Like a free workshop in a public space was a new experience for me. Free in terms of the people who got there didn't pay for me to teach them something, they paid for the conference. So, talking six months, talking a year and see if anyone found me that way.
Speaker 1:So the next question on the docket, now that we've covered a lot of the things that you're working on or have recently worked on, what is a blocker that you currently have or, given everything that we just talked about about, what is a blocker from one of those things that you had that would be good to talk about?
Speaker 2:I have on the ruby friends app. I have like a really small admin dashboard and it just kind of sums up some database columns and I was like, oh, there's this many people on it and there's been this many friendships and this many confirmed users and I wanted wanted to do page tracking, I wanted to do analytics, but I also didn't want to add Google Analytics.
Speaker 2:I didn't need something even as intense as Simple or Fathom or whatever, and I wanted to control everything. So I experimented with kind of like my own version of Ahoy, with like my own version of server side tracking. But then I realized that Ahoy is actually extremely inaccurate now because of Rails default prefetching. So Rails 8 prefetching is on by default. If you hover a link, it makes a get request Because it's a server. Ahoy will count that as a visit and then when they actually click the link, they'll load it from the cache and your server won't be touched at all. So it's like do I want to disable prefetching just to use Ahoy? I don't think so, and right now accuracy doesn't really matter. So I was like going back and forth about all these different solutions and finally it was just like you know what, what if I just built it on my own? What if I just built it on my own? What if I just built it? And I ended up having a JavaScript stimulus controller that on every page load essentially posts to analytics slash track or something like that Analytics slash events.
Speaker 2:And what I got stuck on for a really long time was how to uniquely identify the user without associating them with a real person. I didn't care that like user three visited these pages. I just wanted to know that a user visited these set of pages, but I wanted to count uniques, so I needed a way to uniquely identify them. On the client side, I didn't want to use IP addresses, you know all that stuff. So that's where I was stuck for a very long time just trying to figure out a way that was privacy focused, hopefully didn't require me to do a GDPR, whatever banner across the bottom for cookies and stuff. And yeah, it took a long time to get through that with feeling happy about that.
Speaker 1:So what are you doing?
Speaker 2:feeling happy about that. So what are you doing? So I have this stimulus controller and what it does is it writes a with the crypto not crypto, like crypto in JavaScript, like first party crypto it can generate a UUID that's random. So I generated a random UUID and then I write it to session storage. So this is now public. Someone could open up their cookies and they could see it. They're not encrypted or anything.
Speaker 2:It's just like in your session storage of like a random GUID, a random GUID, and then when a user requests a page, I check if that is there and if it is there, I then don't generate a new one and I pass that along with the request and then I rotate that every 30 days so a user would not be considered unique 30 days later or whatever, which I felt like was a pretty good way to just like give them a little bit more privacy. I don't want to track someone across that long. I might even drop that to a week. And on the server I track two things. I track a page view model, which is a path, and account. So every time a page view is hit, I just increment that count with a dot increment call, which is pretty cool because I never used that one before from active storage, which actually does an increment under the hood with SQL, not just a find and update or whatever.
Speaker 2:And then I have a page view visitor model which associates a path with a day with a unique ID from the user, so a user can only track one view per page per day. Like I have a unique constraint on that, which is perfect. I only care about daily uniques to a specific page. If you visit the same page twice, I don't need to track that twice. So it actually has this really nice balance of like. Okay, this page was visited by seven users unique users on this day, and then also this page was visited 42 times. So I get page views and I get unique views. And then I started adding UTMs and I have a little dashboard that I actually just tweeted about today that has the last like 48 hours of analytics in there and it's just enough to know the vanity metrics that give me an endorphin rush.
Speaker 1:Sure, sure. I love hearing that kind of stuff where you kind of started the whole thing off with, like I was stuck on this for a few days and then the solution just sounds so simple, it sounds so straightforward, it's not complicated, it's not overly verbose or overly engineered, it's just simple. And it's the weirdest part in our jobs. I struggle with this still, close to a decade later, of like it took me so long to get to this very simple answer. The work that I ended up doing does not reflect the time I spent figuring this problem out. I love hearing it, but at the same time, it's maddening how much that happens.
Speaker 2:Yeah it's very true. I think it's like if you don't count the migration and the models, which have just validations on them, they don't even think there's any scopes. It's 40 lines in a controller and 40 lines in the stimulus controller, like that's it. And then most of that code is actually around generating that, that session variable with the crypto thing. Because I can't use a cookie, because a cookie would have taken two lines of code, because I could have said an expiration date Right.
Speaker 2:But if I put it in a cookie then, according to my limited research, I would have needed the cookie banner and all that stuff, and because it's I don't know, I'm probably wrong about that, but maybe not. So, yeah, I totally agree. It's like days that's even days with going back and forth with chat, gpt. That's not even just days of me alone banging my head on it. I'm like pair programming with someone the whole time. Well, what about this? Well, what about that, what about this? And it still takes that long. I probably had five solutions that technically worked before I got to this one, but they were so complicated or they were using some third-party gem that I didn't really need to have, or they had trade-offs like I could have slapped Ahoy on this and be done in five minutes, but then I would have had all the inaccuracy from prefetch. It's all about trade-offs, right.
Speaker 1:Yeah, that's so much of our job, right, it's just balancing those trade-offs, figuring out what works best. Wild, that's a good blocker. That is a fantastic answer, I think. Yeah, good takeaway it doesn't matter what the blocker is. Find that simple answer and you'll be frustratedly happy.
Speaker 2:I wish I didn't spend this time but. I'm so happy, I did I am curious for those that are listening if this would be helpful or just interesting to see as either a blog post or a video walking through the code, because I feel like there's just a lot of little things in there that on their own are so easy to understand, but when it's all together, you're like oh, it's like, oh, I got it, I got it, and I'd be curious to see which medium would be better to explain that in.
Speaker 1:I would be interested to watch a video, just getting it out in the. I can confirm. I'm pretty sure I speak for a bunch of people. Yes, I want to know more, yeah, what the best medium is. I don't know. I think videos for me, just because I spent so much time with GoRails when I was learning Rails.
Speaker 1:Definitely, I think videos is like oh, you have a video on this Instead of having to read a blog post, let's go. But yeah, listeners, there's a way to reach out. There's a link that you can send me a text directly and I can get it to Joe. Or you can reach out to Joe directly and let him know. If you have an opinion or a preference, hit us up, because that is a content creator dilemma, right Of how I probably had to do both. What content? Yeah, right, it's probably the safest way to make sure it hits everybody, yeah, okay. So my favorite question is always what is something cool, new or interesting that you've got going on, that you've found that you're loving that you've got going on that you've found that you're loving that you're building? You're not allowed to use Ruby Friends app because we already talked about that.
Speaker 2:But other than that, what is something that you want to share? I know I want to talk about NFC scanning and stuff. So May I went on a guy's trip with three of my best friends from college and we went up to Canada and did some hiking, did some mountain biking and just kind of hung out. Right. It was great, got away from my boys, my two kids for a little while, had a long weekend and as we were biking, we were like we all really like biking but we're not too serious about it. So we decided to sign up for a century. A century is a 100 mile bike race, that's a lot of miles.
Speaker 2:It's like a marathon, right, it's like it's like the equivalent of a marathon, I think.
Speaker 2:So over the past few weeks I've been getting really into cycling and I have a hybrid like a couple hundred dollar bike from REI, which serves me totally well, but I'm starting to realize how limiting it is and how I won't be able to ride it for a century. So what I am excited to start learning is all of the many ways that I can spend lots and lots of money on unnecessary bike equipment and accessories and go from there, because I just looked up prices of the bikes that were recommended to me and they are about an order of magnitude more than I want to spend. But you know, I have the prices and until May, so I do have some time, definitely have a lot of time, and I figure I'm just going to start saving up for it and get a real awesome bike to use there and probably just spend way, way too much time researching on the perfect stuff to only be told, hey, this one's 10% off and just grab that one off the shelf.
Speaker 1:Yeah, probably, Bikes are crazy, can be crazy expensive. I've done some mountain biking with a friend who was a downhill mountain biker not professional level, but he did it a fair amount. He had multiple bikes and multiple bikes cost more than my first couple of cars. They get crazy, they're crazy. It's so funny that you bring this up because at RailsConf I talked to multiple people who were super into biking and talking about it, Sandy Metz is well known for being super into bikes. And what is it about engineers and biking? Because I like mountain biking but I prefer trail running. But there's a lot of bikers in our community.
Speaker 2:Yeah, there is. I'd be curious to see if that is a Ruby thing or if that is a programmer thing. My guess is that it's a programmer thing. You know you can give yourself the excuse that you're getting exercise, which you definitely are but you can spend hours and days and weeks tinkering with your bike. It's like tinkering with code that you know isn't going into production, right, you can just do whatever you want to it. You can tinker around with your bike as long as you want. You can switch how the brakes feel or where your your shifting is aligned, or just get new shifters entirely, or like change your gear ratio or get new tires, for it's like endless combinations and accessories and equipment. It's just like how much can you optimize, but also how much can you have fun tinkering? I think that there's a lot of that with trail running.
Speaker 1:It's like you got a pair of shoes yeah, I got shoes and like how I carry my water and my fueling. I definitely spent way too much time tinkering with how do I get calories while I'm running.
Speaker 2:Yeah, that makes sense. It's another thing to tinker with, right, but when I am doing this ride I'm going to also have to figure out the whole calorie thing, because I've run half marathons before but never a marathon, so I'm familiar with the taste of gels. Yeah, I can't do.
Speaker 1:Yeah, I have done a couple of ultra marathons oh wow, it's a trail running. I've done 250ks of 50 miler and I attempted 100k, which is the only time that I have not finished a run. 100k oh my yeah, it's a lot. My recommendation is look into a company called Tailwind, not the CSS framework Familiar, I know it's familiar.
Speaker 1:Look into Tailwind in both lives, because Tailwind CSS is awesome, but also Tailwind the fuel it's a completely drinkable calories and electrolytes and varying levels. And that was after too many hours of tinkering and playing with and gut bombing on the trail. I never had a problem with Tailwind.
Speaker 2:Okay, I'll check it out so yeah, definitely check that out.
Speaker 1:That's cool. Okay, you said you wanted to talk about it and I want to talk about it too, so, if you have time, the nfc tapping. I was like what are you talking about?
Speaker 2:that scared me the nfc tapping like yeah nfc tapping that sounds so cool it's so cool and it's so easy. I never knew, okay. So if you have an iphone I don't know about android, sorry, I'm still figuring that out but if you have an iphone and your phone is unlocked and you put your phone on an nfc that is encoded with a URL, your phone pops up the URL at the bottom as a notification.
Speaker 1:I think Android works the same way. Okay, awesome.
Speaker 2:So right there you have an entry point into a website with no configuration or anything, it's just a URL. So I have these.
Speaker 1:That looks like about the size of a credit card.
Speaker 2:It's solid black. It probably is like what you would use if you worked for a big bank or something and you had a tap to get into the door, right like your key card.
Speaker 2:Yeah, it's that, and it's nfc writable and readable. I downloaded an app called nfc cool and wrote a url to this nfc and now if someone taps it with their phone, they get the the Ruby friends URL right to my profile. They open it from their lock screen, it goes to the web the magic of the internet. I don't have to do anything, there's no configuration, it's just. It opens a URL. It's just like scanning a QR code. The real magic comes in is that I can register those URLs as universal links on both platforms, which means if they have the apps installed, that URL will not go to the web but will go right into the app and push that screen onto the stack. So now and that requires some native stuff and some web stuff so now I have this integration where users can write their own NFC.
Speaker 2:So all someone has to do is buy an NFC thing. These are a dollar, $2 each. They buy one of these, they can do whatever they want to it. They can slap a sticker on it, they can wear it as a necklace. I have the app Write that NFC as a URL and now anyone walking around, whether they have the app installed or not, can just take their phone and tap that NFC and they now have that person's profile without any previous. Not even knowing what Ruby friends is, they can just tap that. So all of a sudden now it's this like acquisition strategy also, where folks are making friends and spreading the app with this social degree because they're acquiring new users. For me Sounds like a disease.
Speaker 1:The phrasing is unfortunate post pandemic, but I get it yeah.
Speaker 2:So it opens up this just like world of. I don't have to have say to someone like, oh, you want to be Ruby friends, all right, cool, go to the app store, download the app, sign up and then, like, you can friend me. It's like no, tap this little necklace or this bracelet that I have and it just opens the browser and everyone has a browser on their phone. So I'm really excited about that. It's kind of where you know title back, it's the magic of having a Hotwire native app that is really just a wrapper around your Rails app, because 90% of that magic is the fact that it's a website. The only part that's native about that is the deep linking into the app and that's just cool, right, it doesn't actually provide maybe you're signed into the app, maybe that's the better experience, but for the most part, it's just like taking advantage of existing technology that our phones can scan nfc's and open urls.
Speaker 1:So really excited about that the really important follow-up question is that in the book? No, oh, definitely not right. We're definitely gonna need a blog post about it then. So what I'm doing?
Speaker 2:I'm building out the nfc reader straightforward couple lines of code. The nfc writer is the harder part because there's a lot of errors to handle, like the device and the tag could be different. So what I'm doing is I'm extracting all of the generic implementation of the nfc integration into a bridge component and I'll put that bridge component on my bridge component library. So bridge components dot dev is, I think it's like six, 15, 20 components that you can just drop into your Android and iOS app and some of them are free and some of them are paid and push notifications, qr code scanning, location tracking, all that stuff. You just copy paste it into your Hotwire native app and you have those features. So this will be another one of those. It's like oh, I need NFC interaction, let me just use the NFC component. So I'm just working on now making it bulletproof for other folks, not just for my implementation, that's so cool.
Speaker 1:How much data can an NFC tag hold when you you tap it? Is it like restricted to just a URL of X size, or like could you put other data on there if you wanted?
Speaker 2:I don't know the exact number, but it's not small, like there's a fair amount of data that you could store in there. I know that you can also store multiple entity types, like a URL and text and an image or blah, blah, blah, blah, blah. But like a URL and text and an image or blah, blah, blah, blah, blah. But when you get into that, you need special readers to cycle through those. Essentially and unless, at least on iOS, the only way it will show up on your lock screen is if it is a URL and only a URL. So if you have other data encoded in there, it won't give you, like, the whole experience. Other data encoded in there, it won't give you the whole experience. But if you're building your own NFC reader and you need to store metadata or a barcode type stuff, you can just do all of that. It's pretty much a black box.
Speaker 1:That is so cool. It's funny because NFCs exist. They have for so long, and every time someone says they're doing something cool with it, I'm like why aren't we using this technology more? I know it sounds so cool.
Speaker 2:now you got my brain swimming with ideas, not good it's fun and they're just like it's just a piece of plastic, right like it's a credit card. It looks exactly like a credit card I'm holding in my hand and I could. You have no idea what's on this yeah, you have no idea.
Speaker 1:Is there anything else before I let you go, because I know we're coming up on time. I want to respect your time but also give you the opportunity to talk about anything, will I see you at? Railsworld, not at Railsworld. I will be on vacation with the family. Next conference I will be at is Rocky Mountain Ruby in Boulder, colorado, which I'm pumped for. Great conference, yeah, that sounds like a lot of fun.
Speaker 2:I'll be at Rails World and I was trying to go to Irina's conference down in San Francisco because I'll actually be in San Diego that weekend, but we're going to be there for the holidays so I'm like I can't swing it off. But yeah, sure We'll catch up at a conference in the future.
Speaker 1:Absolutely.
Speaker 2:You can find me on my website, mazzalotticom. I got the blog, the newsletter, the link to the Bridge Component Library link to the book, all that stuff link to socials, so just check me out there and best way to keep in touch is through my newsletter. I respond to everyone.
Speaker 1:Awesome, great. Well, it was awesome having you on the show again. It sounds like we already have an excuse to catch up in another six months to a year, so we'll get that scheduled and we'll check in with you again soon and learn about all the other cool things that you're working on Awesome. Well, thanks for coming on the show, joe, really appreciate it and listeners. I'll see you in the next one.
