Joe Masilotti on Hotwire Native Updates, Challenges, and Opportunities - RUBY_672

So if you're only going digital, it makes sense to buy it now for the discount, but if you want to wait for physical, wait till you know, a few more months, right.

O'Reilly kind of folks. And the reason was was because we were gonna piggyback on small Talk best practice patterns to write Ruby best Practice patterns. And so since we were kind of stealing the book a little bit, you know,

we figured we'd have less legal trouble. But there were six of us at the time, and they wanted to give us like a ten or fifteen percent royalty to splut am on the six of us, and we were just we we kind of did all the looking and feeling and everything, and I mean they they had a clamp down ownership blah blah blah blah blah, and the

royalty was awful. And then I talked to people who have published through Pragmatic Bookshelf and they they're like, oh, these guys are a dream, and you know, they're totally willing to work with you. As far as like ownership rights, I know some people have let them own it and other people have kept ownership I've seen it work both ways.

They've also published books like Abdy Grimm's Exceptional Ruby. He self published it and then they picked it up, and so, you know, and so they're totally willing to play ball. And they're everybody that I've talked to. The royalty rates like forty or fifty percent.

a relatively niche topic. Right Maybe that changes in a few years and I'm singing a different tune. But right now, if I can get one or like two high ticket clients for my consulting business from this book, it will pay for itself, like all the work that I put into it. Like that's all I need is to land two big clients. And that's my kind of marketing plan with all of it, Like when I go to conferences, I am checking a suitcase full of books to bring

with me to just throw into the crowd. Essentially, you know, like I want to get this thing to as many people as possible. So having a publisher that supports really good distribution and getting into local bookstores and kick ass editor like it worked. It works so well. The forty fifty royalties is kind of just a bonus to me.

books and they liked her, and so they figured it out. Whereas, yeah, you know, for us, we're in a small niche, and in your case, it's a small niche of a small niche, and so yeah, you know you're you're doing it for reputational and other reasons that make a lot of sense.

support them. But yeah, let's let's dive in. So hot Wire Native. We've already done a show on Turbo Native, and I don't think the overall thing that it does is change, So just give us a real quick overview on that, and then what I'd like to do is get into what's changed. Sure if that makes sense.

your HTML, CSS and JavaScript. And what it gives you is like almost full feature parody with your Rails app with just a few lines of native code. And once you submit to the app stores, you can continue to add new features to your Rails app, and because the native clients are just hitting your server, they get those features essentially for free as long as there is a

link to that new feature on an existing page. That's been the story for a decade since, like turbolinks, native was around, and there's also opportunity to dive down into native APIs. It's different than like React Native, where it's taking over the entire app and you have to write React native. Hot Wire Native sits next to iOS or Android, and when you want to drop down to you know, Pushmification API or the Haptics feedback or health Kit. You just write that code and then send some data back

to your server or back to the WebView. There's no health Kit plugin for hot Wire Native. You just write health Kit code, so to speak, right, And I think, yeah, it's a little bit like, oh, go ahead.

done with something like hot wired Native. The nice thing is is I can keep the same look and feel if I want people to have the same experience on the web and on the app. Or I've also seen it where people tend, you know, they they kind of pick up a style sheet and kind of figure it out so that it looks more native. If you're in the app, m you get you get a lot of mileage out of it that way, Yeah, you get a lot.

fewer things to worry about. It's like you have your Web UI and you that works on your native and then maybe you show or hide some content that doesn't make sense on the native apps, like your you know, Hamburger menu or whatever. That doesn't make sense in a mobile context because you have a tab bar. But for the most part, you're just like rendering the same stuff styled the same way.

add an interaction with the push notification API. And Strata worked with sending Jason back and forth between the native code and the WebView, but it required like one hundred and fifty lines of code to just integrate into your library because you had to subclass something and pass along messages. Now Strata is part of hot wire Native and has just been renamed like Bridge components lowercase you know, B,

not a capital S for Strata. They're just a part of hot Wire Native now, and what that means is that when you use these bridge components, you just use them. You don't have to worry about like a whole installation step. They're already bundled. That's probably the biggest one. That's for probably more not more experienced hot Wire Native developers, but

more advanced apps. The most relevant change for people that have never used it is that the time to market, Like from starting a new hot Wire native iOS app to running it in the emulator or the simulator went from forty five lines of code to like twelve lines of code to get something running. And Android went from I think like seventy eighty to like twenty five thirty five. And those are the things that we're really looking forward

to as making those even fewer. Is just like how quickly can we get from brand new excodeor Android studio project to content rendering on the screen in a mobile simulator emulator. And we've made some really big progress with that by just making a lot of assumptions and letting people, you know, giving people some of the higher level abstractions than we used to give them with turbonative.

figure things out when I messed them up. And so it sounds like there are just a lot fewer places where Chuck can mess it up, if that makes sense.

has to render the post index view. Like all of those little places that you could either fat finger or just like miss. That's how we love That's why we love rails. All of those conventions make sense. Configuration, yeah yeah, And like the Turbo Native was way more configuration over convention, and now hot Wire Native is way more convention over configuration. I hope I got those right. You do a lot less code with hot Wire Native, and a lot of it is just assumed for you. But we didn't hide

any of the APIs. They're still public. Like, if you still want to drop down and do all the wild stuff you were doing in a Turbnative app, those APIs are still available to you. It's just like you're, you know, a layer below the abstraction we want you to work with so you have more freedom, but you also are more responsible when something goes wrong.

not anymore. But I'm quite happy that these developments are happening because it makes life easier for other developers. Like when I was writing that the native chapters in my book, it drove me to the edge of sanity, like it was like and I had done native development professionally before, it just had been a few years. I was a bit rusty, like for a beginner, I can imagine the shut tricky that must have been. So I think removing all these hoops that you kind of have to jump

through is definitely a step in the right direction. And really happy to hear that these changes are being made.

go for it. It was so thin around the web view, the wrapper that you know your book, the Codex book, you had to deal with session delegates and like navigating between screens if there's a modal and stuff, and like all of that stuff has been abstracted into just one line where it's like, here's an object, give it a URL, and it will handle everything for you automatically, as long as you have the path configuration set up, which we could dive into if you want. But that just didn't

exist back then. And what's kind of wild is like it existed in Turboonative Android for quite a while, but the iOS library just hadn't been updated in like a year to get up to speed with this. And when I first learned that, I was, well, first I was really upset because I was writing all this iOS code for so many clients. And then I was like, well, this is also just silly, like why have we not

gotten up to speed? And that's around the time I started working with thirty seven Signals directly and started getting contracted by then to bring the iOS library up to speed with Android. That's where the Turbo Navigator library came from. That we then upstreamed into hot Wire Native, like all of this development that was essentially sponsored right by them that I could do to bring the two libraries back

to feature parody. And I'm still working with them, Like we have a really cool new demo site coming which I'm very excited about that's going to be written in Rails instead of JavaScript, so really relevant for rails developers. But like all of that stuff took buy in from thirty seven signals to finally sit down and say, okay, we're focusing on this now. And before that it was just like, what is this turbo native thing? Is it even supported?

But and I'm looking forward to this in your book because Pragmatic Programmers is usually pretty good, I will say, in making sure that what's in the book is pretty close to up to date, but I ran into version issues almost right away, right, and it's like, okay, do you want to run the latest Android? Okay, well, you know the example in this book is you know, a version old or two versions old. And so I guess the question is both for the book and for the framework.

I don't know as a framework the right term for hot Wire Native. I'm going to say framework.

of them. With the libraries, it's easy to release a new version of a library, relatively speaking. For the book, it gets a little bit trickier because I can't just update someone's physical copy of a book, right. I can update the PDF no problem, like the three beta versions of the book that have been out already.

support comes out. So what I'm doing as an author is making sure that I'm not releasing this thing to physical until we are set on both platforms at least for a little while. And that won't always be the case.

Android thirty seven will probably break something when it comes out in a few years, but I see this book as something that will probably need to be updated every eighteen months at a minimum, So I'm making sure that every single time I reference a version code or a version number or an SDK, it's like, by the way, this was tested on version X. If you're using anything newer, like you're kind of at your own, but also join my discord and I'll help you, like join my private

discord just for book owned book readers, and I will help you get through it because someone else is already going to ask that we're already going to be up to speed on it, and maybe that just means like, hey, here's a PDF version of the book, You're good to go. Or it's like, oh, you need to just this one

change and it's like documented somewhere. The short of it is that it sucks, like like there's so many changes all the time, and I'm sometimes the one who's making the changes to the library, and then I know I have to update the book later, so I both have insider knowledge into what's coming next, but I also can

dictate how quickly it happens or slowly. So it's it's also this just like fun mental game that I play with myself where it's like do we include this in the Hotwire native repos but then my book has to mention it or do we not? And like I wait, So it's all this fun stuff I never really had to think about before.

Android is fairly new to you for this book. What was that experience like? Because from my point of view, Android has been the bane of my life for years and years and years, like everything on Android has been more difficult to do than iOS. Uh. And I think for me, the final straw that made me decide to exclude Native from the second edition was when Strata had just come out and I needed to update my book

to include Strada. I was on holiday at my parents' house in India, and I opened up the uh, the Android Reaper for the book, and I included the Strata library and there instantly everything broke. I fixed it. Know how I fixed don't know how I fixed it, but I fixed it. Closed Android Studio, got back, got back home to the UK, open Android Studio again and it was broken again.

and everything. I usually talk about iOS because it's such a majority of the market and the code is just way simpler most of the time, Like there's way less quids, like you don't worry about some x random XML file or some factory just to wire a little button up or whatever. So I usually talk about iOS because it's just more elegant and markets better. I've been doing Android for a long time, but I've never taught Android in

the way that I'm teaching it in this book. So what I've had to do is get I have an editor, or not an editor. I have a beta reviewer who is a like hardcore Android developer, doesn't know rails, doesn't

know hot wire Native. They do Android day in and day out, and they are giving every single line of Android code like two or three REA read throughs in this book, and that has pointed out some small things about like where I use it Ruby term instead of a Cotland term, but also some larger things where like I've made mistakes in the book that are just straight up wrong, like I outlined a function and was like, here's how you write it in Scotland, and he applied

and was like, I, no, that doesn't even compile. It's like, thanks for that. But he's also bringing up more conventions that are more akin to the Android developer or experience. And you do things in rails a certain way, you do things in iOS a certain way, you do things in Android a certain way, and I'm not as privy to those because I'm mostly just like slapping what I

can together. He's coming out and saying, hey, you're managing your versions the wrong way, Like you're essentially not adding any version numbers to your gem file, Like you should probably have a version number in the equivalent for Android. Stuff like that. That's just like really helpful to pass on to my readers. It'd be really tough without that. And also just like the book would be worse because it'd be wrong in some places and I looked like

an idiot. So very grateful for that editor, for that beta reviewer. It still doesn't change the fact that writing Android chapters usually takes me two to three times as long as writing iOS chapters. I have half a chapter left to finish my manuscript. All of the content it'll still need to go over to through two or three rounds of editing. But like the content, I have half a chapter left. It is an Android half a chapter. I have been writing this half a chapter for three

weeks and it is killing me. And it's just like I wrote the iOS chapter in like two hours, the iOS side of the chapter, but the Android side has been such a pain in the butt because I just like skip a step or forget something, or get locked out of my Google Play account because I like said that my name was Joseph Mazzilotti instead of Joseph Anthony Mazzolotti, and like little silly, nippicky things like that are causing

this chapter to just take forever. But as soon as this call is done, I have a nice three hour chunk to work on it, and I'm hoping I can finish it.

Until you've got the React developers and the view developers, and then you've got other people that you know, they're kind of into JavaScript, but they're not really like deeply, right, so they might have instead of a single page app with React and React Router, they've got, you know, something that looks a little bit more like a Rails app and they've got express or sales or something on the back end. And so my question is is can you do a hot wire native app if it's not Rails?

the hooks to make changes. So my recommendation is usually like, if you have Rails and you're using hot Wire, hot Wire Native is a very easy add on to it. You don't have to make many changes to your server. If you have a React front end and you have like adjase, your Rails app is supplying a Jason endpoint type thing, You're going to have a much harder time kind of hammering that to make it work with hot

Wire Native, And honestly, i'd just recommend React Native. But if you have a view app or a lower of a app, if you change the page navigation to use TURBOJS, hot Wire Native will work as if it was a Rails app and there's very little that you'll need to add to your non rails back end to get some of the niceties, like you'll have to create your own hot wire native app helper that just checks the user agents like things like that that are actually not that

hard or not that much code. But the most important thing is if it's running TURBOJS, you're good.

turn it off. Does that make it not work with turbo native when you do that kind of a thing, or are there other things that people may be doing with their rails apps that are going to cause them trouble if they try and adopt this approach.

and that's ideal. Like you think about a lazy loaded frame. You don't want when that frame loads to push a new screen. You just want that content to appear inside the website. Turbo streams have their own custom handling, and there's some documentation about it on Native dot Hotwired dot dev.

But the short of it is like, if you're submitting a form, you'll most likely want to push a new page for the mobile apps because it will create a better experience for your mobile users, mostly related to when you click a link, it opens a form in a modal.

It slides in from the bottom to give you that context of like you've kind of broken out of the standard view, and then when you submit that form, it dismisses the modal and either refreshes the page underneath the original page you're on or pushes a new screen onto the stack, and all of that is handled out with the framework. You don't have to do anything custom except one line of configuration to say that these screen should

be presented as modals. But the best part about all of that is like all of the caching of the previous screens, because you made a post or a non get request, all that caching is destroyed. So when you go back, that content will be fresh. If you go forward, that content will be new. You have all this default sane handling around form submissions that didn't exist before. That really makes it like most folks won't even know what I'm talking about because you never have to deal with it.

And that's and that's like the way we want it, you know.

and they were never publicly exposed or documented. You found those in your book, and when I was reading your book, the Codex book, I was like, Wow, these are really powerful, but didn't really understand how to use them because you had to set up a lot of default handling around them. And there's an open pr right now. Hopefully by the time this podcast is released, it's merged in and the new version is released where this handling will be automatically

included in the native wrappers by default. And what that means is that at any point you can redirect to one of these three special routes and the hot Wire Native Apple Tape custom actions receide, refresh, resume, So recede will pop the top screen off the stack, kind of navigate backwards. If there's a modal presented, it will dismiss the modal. Refresh will do the same thing, but then refresh the previous page and then resume. Essentially just says

like don't do anything. I still haven't found to use case for that one, so if you're listening and no of one, I'd love to hear it. But these are really really helpful when you're doing form submissions because like most of the time, when you submit a form, you're like on the index page, you show the new page,

and then you go back to the index page. You want that index page to refresh to show the new entry or like the flash message or whatever, and you can use this refresh historical location to dismiss the screen and then refresh the one underneath, and your mobile apps behave as if it was a rails app, just like perfectly.

There's also some helpers built in that let you do these routes only for hot Wire native apps, but then do a normal redirect for reil for your web apps, so you actually don't even have to have any conditional logic. You can just use these helpers and pass in a new route, which make it even easier on your rail server because there's less changes to manage. You're essentially changing that one line of code instead of you know, anfl statement.

And with the React natives and the and the others base. One of the things that people get into then is what if my app has to be offline? Right? What if I have to deliver content or or stuff like that offline, or you know, I'm working in a place where there's not really good connection, but I need to use the app to I don't know, upload pictures or crap like that, right, so it needs to cash it And then when my WIFEI turns on, then it says, oh,

here's all the activity I needed to do. Yeah, is that just not a good fit for Turbo Native or are there mechanisms that allow you to do some of these things.

native app and you just build those features natively. So maybe okay, twenty percent of your app is native, the rest of the eighty percent is driven by the web. That's a really good use case because you still get all the benefits of hot wire Native and then you have this little offline experience. For a very specific use case, I did exactly this for a client last year, two years ago. At this point, where they were a tour

guide like reseller. They sold tickets to tour guides to tourists going on tours, and oftentimes they were traveling, so they didn't have Wi Fi right or internet at all. So they would open the hot wire Native app in the background, it would download all of their tickets, and then when they opened the app without service, it would switch into offline mode with some native code and show through a native screen all of the tickets that they

have purchased that are stored on the device. When they click one of those, it would show the QR code and the map, all this stuff that they needed to get to the tour and then show the tour guide, Hey, this is my ticket. But all of it was offline, All of it was cash to the device, and none of it was dealt with with Turbo Native or hot Wire Native. It was all done with manual code. And then as soon as they got internet access again, it would switch to online mode where there was a link

to the same experience on the web. That's like the really I think the best best of both worlds essentially, where you have this offline experience for a very important specific use case and then everything else is powered by hot Wire Native. For complexity, the hot wire Native implementation versus the native code, hot Wire Native was about five percent.

Native implementation was out in ninety five, so like that's the level of you know, native code you'll need just to build those two screens versus what you need for hot wire native to access your entire rail server.

the schools was not ideal. And so what you're saying is is we could have had the people who were scanning QR codes right the QR code scanner and having a list of people who have already registered, having that that could be a native component, but the rest of it's all turbonative, and then the same thing with people showing up with a QR code. The other use case that I'm looking at is a little different, and that

is for top end devs. And incidentally, I made it into a multi tenant app, So if you wanted to run your podcast network on what I'm running. You know, I want to open that up to people, and I

want them to have an app. But one thing that I've seen is if you're putting out videos or other content, yeah, some people want to access that offline, right, And what I've seen from other apps is you kind of hit the button and then it says, okay, I'm downloading it, and then once is downloaded, it just kind of has a flag on it that says this is available offline.

And so what you're saying is is I could just have it then load a native player and play the video or a native player for the audio, and then the rest of the app, So browsing and knowing what you have access to and everything else, I can either cash those pages or I can yeah things like that. Just let that run as a regular app.

wasn't right for public use. But I wouldn't be surprised if there is something like that in the future for hotwire and Native, where if you've visited a page and then you try to access that same page without Internet access, like you get a cased version right.

web in like Safari dot app. So to make those work well, like with service workers and you know, offline storage and background processing and all that stuff, like, we have to do something either to hot wire native or it won't be possible because of WK webew until they update that. And it's usually a security thing because you're just like injecting JavaScript and stuff into it. But from the literature that I've read around this, like WK web is actually the biggest blocker on PWA like features in

an embedded web app. And that's not a hot that wouldn't be a hot wire native limitation. That's like an embedded web browser limitation.

same issues. And so yeah, this is this is not an isolated issue, and there are people outside of the Rails community that are working on workarounds for a lot of stuff.

book directly. My goal is to get clients and exposure and you know, solidify myself as the expert in the space. Having another couple of thousands of dollars, maybe tens of thousands of dollars if I got really lucky by self publishing was not worth it compared to what I could be making off of a couple of clients. So the benefits of self publishing were like, not really benefits at all.

The benefits of having a publisher were having an editor I didn't have to hire, having someone keep me to a timeline, someone making sure that the last eighty percent after I finished the first eighty percent actually gets done, you know, things like that, and having someone to review cover art, with having a team of beta reviewers that are platforms specific that can help me with stuff, having a distribution network, talking to my local bookstore to make

sure my book is on the shelves there instead of having to walk in and be like, hey, can you stock this for me? Like, the list of going with a publisher of any publisher, were just aligned so well to my goals of the book book that self publishing like didn't stand a chance once I really once I finally understood that that was my goals. Those are my goals. At the beginning, I didn't really get that. I was like, I want to write a book and I want full control over it, so I was leaning for it towards

self publishing. I want to make sure that the margins are exactly what I want the code cop the codes looks like this, the cover looks like that. But those things didn't really matter because of all the extra work I would have had to have done going self publishing.

kind of clinch I was creative control. I wanted one hundred per and creative control top to bottom, from everything to do with the cover art to the fond size, to content, to silly jokes that I had in the text, Like I ended the book with a kling onward. It's like, just silly, silly, stupid things like that. And I didn't want anybody over my shoulder telling me we can't do that or we can't do that. So for me, that was the clincher. And yeah, it came with a hell

of a lot of additional work. And another thing I think what kind of pushed me toward self publishing is I knew was going to be ebook only. The way I've written the book. For anyone who's read it knows it's full of hyper links to stuff, It has links to other parts of the book, it has links out to the Internet. It was never written to be a print book, and I knew that from day one. So what with an ebook only distribution model as like, and the fact that I wanted creative control, I was like, yeah,

just to get on gum ruth and be done with it. Yeah, but obviously it comes with a lot more hard work in terms of marketing and self editing and stuff like that. So yeah, I just wanted to give the listeners a bit of contrast because there's no right onset to this, and Joe and I had different goals and I think we both found the right both for us. And yeah, if you're thinking of writing a book, doing just take someone else's answer.

reado the book entirely for hot Wire Native. So I'm glad that it's took longer because I was able to do that during the editing process, not during the like post published process, but if you want to get something out, like you have something to say that you need to get out in the next couple of months, like you can't go with a publisher. Most likely it's going to be way too long. It's going to take that long to find a publisher.

the goal was. I thought for sure that I would just put the book out there and a whole bunch of people would buy it. Yeah, And so I experience, having done that now is, Yeah, if I were going to write a full on book or manual or you know, something that that you know, you kind of think of as that technical book you put on your shelf, I would one hundred percent go talk to the folks over at Pragmatic Bookshelf. I mean, I might shop at to Manning.

Manning's royalties are higher than like Pearson and them. I've got a pretty good relationship with them as well, But you know, I'd probably go with one of the two and use a lot of their distribution network. One thing you have to understand, though, is no matter who you go with, most of the marketing and sale of your book is going to be down to you and what you can do to go get the word out right.

So you're going to be doing what Joe's doing, coming on a show like this and you know, and maybe you know, publishing stuff to YouTube or a blog or places like that and making sure that people can find it. And you have to do that with self published too. The difference is is that the book publisher will you know, they'll provide you an editor and a lot of those

other things. And in some cases, like Manning has reached out to me many many times for their authors, and so you know, they may help you figure out some

of that marketing. One thing that I'm gonna kind of back up on a little bit is I've talked to a number of friends who have released like shorter versions of things, right, so you know, it's like a thirty page book on Hey, here's just how you get the thing to run, right, you know, so instead of building a car, you know, or building the frame of the car with turbine or with hot wire native, right, it's just basically a bare bones here's how you get turbo

running in your app in you know, in thirty pages. And typically the publishers aren't so interested in those. Usually if you're trying to build your reputation on something like that too, like you can crank one of those every month and you can build some reputation for putting stuff out. And so again, there are a lot of approaches you

can take. But yeah, if it and I think even if you're doing kind of the short content or if you're doing podcasts like this or something like that, like having that full length technical book on something that you know, like Joe saying that he can he can go find clients for and build business for, it really will pay

off for you. But then you can do the other things to kind of you know, build your reputation and then go back to that and the fact that you went through a publisher that helped you make it the best thing possible is actually a good thing overall for your reputation. And so if I were to go back and write my book again, I would have gone to prag Prague and I would or you know, and I would have said, hey, look, guys, this is the book I want to write. Here's kind of an out line.

They might have given me some other ideas. We don't know if we could sell it, or hey, you haven't covered this, or if you changed the direction of this a little bit. We think it's a better fit for the market, which is all healthy. And then they would have helped me get the book out and had to be the best thing possible. Yeah.

of weeks. In terms of writing the Android book's going to take me a couple of months, and if someone wants both, they'll buy both both, and they'll be like some duplicated content on the rail server. And I could have easily filled tw hundred fifty pages for each and gone much more deeper with both.

less educated decision. What I wanted to do as a second pass was like section one was all iOS and then section two was all Android, and you would build the full iOS app and then build the full Android app. And that kind of makes sense to how you're building it.

You know, you're less likely to build both at the same time, but when you're learning, it's actually better to learn and build both at the same time because you can learn and compare and contrast the two frameworks and the two platforms, so every chapter is either is like Rails than iOS than Android, and that little change in the structure of the book book from my editor has made the book so much easier to read and understand

and things like that. I just can't imagine having to have full control over and doing it on my own. And there's probably countless other ones that I don't even remember because we've made you know, we talk every couple of weeks on like how the direction and making sure that we're aligned with the goals of the book and the audience of the book and stuff like that that I would have gotten way distracted by now and probably just pushed whatever I had and called it done and not been happy with it.

I'm not deciding between self publishing and publisher. I'm deciding between self publishing and PRAG, like that was the option. It was so clear that PRAG was the best fit for me from talking to folks about my writing style, about what they valued, about how they manage code, about how they do promotions, royalties was great. It was kind of just icing on the cake. How they gave me an editor and beta reviewers and all this stuff. Like it was never is it PRAG or O'Reilly or whatever,

it was like, self publish or go with PRAG. So once I got to that, the decision was actually pretty easy. Once I decided my goal of getting more clients, okay PRAG, Yeah.

didn't fit in with their strategy. They're like, if you want to do just an iOS app or just a rails app, like, we would definitely like to talk more, but this weird cross platform thing is not what we're looking for right now. And Prag got back to me within like twenty four hours and was like, let's go. So that was pretty awesome. I was talking. I was talking to Dave within like a week, the you know, person who owns and runs Prag, and was just like, yes,

this is this is great. We're really excited about this.

whatever it's called. You know, they have a handful of books in that space, and so they know that they are already in front of people who will buy this book exactly. And yeah, and so you know, I don't want anyone to be thinking, ho, well, you know, they blew it over there. They're selling to a different audience. It's the same with Manning or Packed or any of the other ones that you went to.

best way possible? And what I find with a lot of these books is it's not that I couldn't go figure it out on my own, right, I'm a smart guy. I go figure it out on my own. But the difference is is that you've gone through and thought through enough of the use cases that I'm gonna run into an issue and go, oh, what do I do here? And then it turns out it's in your book.

and I'm like, well, what the hell just happened? And you realize that you like forgot one line of code that almost every developer misses when they build tabs, and we walk through that together, so you know that not only did you learn that one line, but you will never make that mistake again because you saw the problem of the blank screen and then you fixed it yourself.

And I have one of those, at least in every single chapter that I adds a lot of content, of course, but I just really love it because it really enforces the learning, not just the copy pasting from the book of code. It's like you're learning how this works.

leave the mistake in? And I was like, well, I talked to people after they watch my videos, and I asked them if they ran into the same mistake, and like half the people they follow along as I go and they make the same mistake I do, right, and then and then they fix it when I come back with the fixah, and the reason is is because it's a common thing. It's a real easy thing to do. And so yeah, I like that. I really like that.

it's it's all handled for you. And then I can just write like in one file and images of course, and my code write it all in one file, and then when the layout editor gets in there, they can add their own special markup that I don't even like, know or care about. That's going to make sure that

we don't have or like orphans or and whatever. The other opposite of an orphan is or code snippets spanning across two pages, or images that are too small or too big like all that's just going to be handled by the by the layout editors, and I can just worry about writing really good content. And that's a huge weight off my shoulders because that's something I don't have I do have to worry about when I do, like my newsletter or my blog posts. It's like that whole

last thirty percent is just spent doing producing. I can just skip all that with the publisher and just write.

that it's from the book, that's totally fine. The thing that didn't bother me about that is that, like a lot of the content from my book exists in the wild already, you'd have to piece together every one of my newsletters, every single one of my blog posts, every single one of your tweets, because that, yeah, like my private discord server where I'm answering people's questions, get hub issues,

discourse discussions. Like if you pieced all of that together, you'd have fifty plus percent of the content of the book, right, but it all be disparate, and it wouldn't be connected to the same app that you're building, like it all itould be like spread across and code snippets. So them owning the content of my book seemed less. I'm less worried about it because I know that I can recreate this in my own different, like not my own voice,

but from my own platforms. When it makes sense when I a whole chapters on tabs, If I write tabs on my blog, I'm not going to use the same techniques that I wrote about in the book. Sorry, I'm going to use the same techniques I'm going to write about in the book, but it's not going to be the same content. By the time you get to tabs in the book, you already have an app that does a bunch of stuff and we're just adding stuff on top.

If I write that for my blog, it's like, Okay, new ex Code project, new Android studio project, here's how to add tabs. And that is a totally different piece of content, even if I'm teaching the same concepts and like, you know, approach, because of the audience and the context that's built into that.

So if people want to get the book, is there a link people can follow? You said there was a discount. Is that discount just built in? Or is there a coupon code? Do you want to tell us about that?

to my website, Mazziladi dot com. There's a big bounder up at the top that links to the purchase page on the publisher's website, which is the best way to buy it because, as Chuck mentioned earlier, you'll get an email from them on any update through the beta every two weeks, and then also once the book is published, any errata that gets changed, you'll get an email saying like, hey, these are all the changes, and a new version of that PDF or MOBI or epub for your readers.

done with them. But yeah, So if you go to Ruby rogues dot com, I'm adding in the email form literally this week, so by the time this is published, you'll be able to join the email list. Right now, the email list has like one hundred and thirty people on it, so you have a decent chance of getting the book. I took my old list and I segmented it. I just sent an email out and said, if you want to be on the Ruby only list. That's why

they're only one hundred and thirty people on it. But anyway, if you want, if you want that, I mean, I'm going to be sending out content on doing whatever it is that we're in, you know, in the membership, but and then you know, dropping hints and tips and stuff

like that. That'd be a bunch of good content. But besides that, if you're on the list, I'm gonna let it run through the end of I guess it's February now, so we'll let it run through the end of March, and then whoever's on the list, I'll take that list, I'll drop it into some random picker and we'll we'll give away two copies. So if you're interested, Yeah, go to Ruby rogues dot com and just join the me email list and yeah, I look forward to hearing from you there as well.

by Devin Townsend. It's a metal album, but it kind of transcends genre. Really. It's like it's predominantly metal, but there's a whole lot of other kind of styles on there as well. And I think that's what makes it interesting for me because I'm not really that much of a metal fan, but I absolutely love that record. So yeah,

I check that out. Mpath by Devin towns End came out in twenty nineteen, and I'm rewatching a TV show at the moment, which is one of my favorite TV shows called The Good Place, and yeah, I love it. I'm just doing a rewatch because I'm bored. Since I contact of anything else, I'll choose that as one of my picks. Yeah, that's all I've got today.

Came out in ninety three, ninety three even better, right, it's more than thirty years old. So anyway, in the game, he goes through and relives the same day over and over and over again until he has kind of the perfect day, right, you know, he gets the girl, he you know, all the things right. And so groundhog Day the Game is the same, the same premise. And so you have a perfect day if you play all of all seven cards in a day as red cards, right, and the red cards are for four heart cards, and

if so, if you do that, you win. The way you play on the on each day is you can play any number higher than the last number played, and then day today, your days have to get better. Right. So there are great cards that have no hearts. There are blue cards have one heart, there are orange cards that have two hearts, and there are yellow cards that have three hearts. Some of the yellow cards get more red cards into the deck, so when you pass them

around to everybody is a cooperative game. Anybody can jump in at any time and play a number. So on your first day, you're usually playing the gray and blue cards because they're lower hearts, and so maybe you get a day that has four hearts. So the next day, you know, you take the rest of the cards, you shuffle them, and you pass them out again, and all of those lower value cards are gone. So now you maybe have a five hard or six heart day if you get too far ahead of yourself, right, because you

has to go up. So if you can't play on the day and you need more cards in the day, you lose. And then if you don't ever get a day full of red cards, you lose. It's a pretty simple game. Board game geek says it's a one point too. To wait two is like complex ish games. So I mean this is one. I think we were playing around in like fifteen minutes with five of us. And anyway, it's really fun because you literally just pass out the cards, fill up the day, shuffle the cards, pass them out again, right,

and you get fewer cards every round. Here's the other thing that comes in and so yeah, so our strategy was at the point where you know, somebody has a couple of red cards and one of them is reasonably low, and you think they're good odds that there are eight seven eight cards in the stack in other people's hands, right, because you don't deal out all the cards, then you go for it. So anyway, fun game really enjoyed it,

and so I'm going to pick that. In the show notes, there will be a link to board game Geek where you can kind of check out what other people have thought, and then there's going to be an Amazon affiliate link so that you can go go check it out. A couple of other picks here. If you're watching the video, you can see I have a little bit of a split lip. So we have cold, dry winters here in Utah, And that's just the way it goes. I'm gonna pick Chapstick just because it's made my life better the last

few days. And then, oh, there was something else I was gonna pick, and I just can't think of it. But anyway, I guess I'll just throw out Ruby Geniuses. Real quick, we're doing calls every week. I'm doing the all the calls in March, and then I'm starting to bring in experts in April and may probably for two or three out of the four or five weeks, so we'll get people like Joe or and Ayush and you know,

some of our other guests. I'm probably going to ask the guests from the show to just come on and you know, we can hear what they're working on, and they can kind of help us figure out how to do what they're working on and whatever we're working on. I'm getting way into AI, and so there are going to be some videos as well in the system for AI, just everything from here's how you just kind of get started with the fundamentals, either with a chat GPT that you don't have to set up, or Olama and some

of the other tools that are out there. That was what I was going to pick, but I don't have the link in front of me, so I'll pick it next week. But there's a web interface that sits on top of Olama that you can just basically run it like chat GPT, except you're not paying for it, and it's slightly less capable because chat GPT will go search the web for information and this really doesn't do that, but anyway, good stuff. And yeah, so those are my picks, Joe, what are your picks?

home planet through this fax machine. And it's told in really digestible, like two three paragraph chapters of her life experiences of her growing up from living in Philly to like getting a going through high school, getting a job, having friends along the way, and it gives this really unique point of view of how aliens look at our

life as humans. And there's a really awesome chapter on New York City, where I used to live that's very nostalgic but also just like very ironic and really makes you think about some of the things that we value, and like bagels are a big part of it. It's really really good and a pretty quick a pretty quick read as well and scratches that sci fi itch that I that I really love. My board game is in the background right here, Slay the Spire. It is a board game based off of a video game based off

of a board game. So the video game is called Slay the Spire, and it's essentially you play a board game of a rogue Light deck builder, so you're like, you know, you're buying cards, playing them against the computer, and like trying to build the optimal deck. The board game is exactly that as a board game. I think the only thing that changes are some of the scaling of the numbers. But like if you've played the video game, it is an awesome board game to play because it

plays really well solo. It's one of the few games that I think is like better played on your own against the game than playing with other people cooperatively. So I really love it because in the evenings that I'm wiped and want to just watch TV, I can set up a board game and play around by myself and not like sit in front of a screen for an hour before I go to bed. And it's really challenging. It's not too hard to learn if you already know

the video game. It just does take a little bit while to set up physically, but definitely recommend that it's a lot of fun.

You can get the uncensored version of deep seek. It's fun to ask it about like Kenneman square and stuff because the data they trained it on it doesn't know anything about anything that China sensors, right, but any it's a it's a decent model. It runs fast, and it's it's pretty good. So yeah, but it's open open you open WebUI, open dash WebUI, and so yeah, you can just run that on your local machine. I had somebody ask if you can do cursor on it, and cursor

does other things too, so you really can't. But yeah, all right, Joe. If people want to find you on the internet, where do they find you?