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

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey, folks, welcome back to another episode of the Ruby
Rogues podcast. This week on our panel we have a Yushnwatya.

Speaker 2 (00:13):
Hello.

Speaker 1 (00:14):
I'm Charles Maxwett from Top End Devs and this week
we have a special guest. It is Joe Mazzlati. Joe,
Welcome to the show. Hello, how are you doing all right?
I think we had you a while back talking about
then Turbo Native now hot Wire Native. But yeah, what's new?

Speaker 3 (00:35):
Yeah, So I am writing a book on hot Wire
Native and it is coming very close to it being
completely done. So getting the word out talking about hot
Wire Native and just getting more and more rails developers
to use it. It's been it's been a fun couple
months for sure.

Speaker 1 (00:57):
All Right. The book is out right.

Speaker 3 (01:00):
Yeah, So the book is out. You can buy it
digital only right now as we finish up the last chapter,
and then when it comes out you know, final version,
you can start ordering the physical copies and like get
it at your bookstore and stuff. But if you buy
it now, you get a discount and then you get
an update email every two weeks with like the new

(01:20):
features and everything that have been added to the book.
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.

Speaker 1 (01:31):
And that's shows it only available on the Pragmatic Bookshelf.

Speaker 3 (01:35):
Yeah then yeah, it's only available directly from my publisher.

Speaker 1 (01:39):
Awesome. And those guys are amazing. I love those guys.

Speaker 3 (01:42):
It has been such a pleasure working with them. Oh
my god. I even just from like the initial calls
with them, I had such a good feeling about them
as a publisher versus everyone else I spoke to and
ooof looking back on it, so glad I went with
a publisher instead of self publishing, because I probably would
have given up now, to be honest, Yeah what I'm

(02:05):
talking about.

Speaker 2 (02:06):
Oh yeah, that was one of the questions I was
going to dig into. His publisher was and no publisher?
We got to be a bit later on.

Speaker 1 (02:12):
Yeah, for sure, we could just do it now. I
was going to say, I mean, I've self published a book.
I know, I used self published a book. I've talked
to the guys at Pragmatic Bookshelf before, but I've never
actually gone all the way to hey, maybe we should
do a book together. But I know a lot of
folks over there. I don't know who you're working with,

(02:33):
but over there as your editor and stuff. But yeah,
it's way back in the day. Ruby Roges was going
to write a book and we were talking to Pearson.
O'Reilly kind of folks. And the reason was was because
we were gonna piggyback on small Talk best practice patterns

(02:53):
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

(03:15):
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

(03:36):
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.

Speaker 3 (03:58):
Yeah, yeah, exactly, and we could talk about it more.
But like if they were giving me zero percent royalties,
I still would have went with them. Oh really, yeah,
the the uh perhaps a little you know, insider knowledge here.
I am not planning on making money off of the book.
It's not my goal to make money like I you know,
I do the I did the math on it. However,

(04:19):
many rails developers there are in the world, However, many
of those are going to do mobile apps. It's still
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

(04:42):
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

(05:05):
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.

Speaker 1 (05:18):
Yeah, it's it's interesting that you bring that up, because
it seems like the only people I really see make
any kind of real money on books are essentially celebrities, right,
so you hear that, like Michelle Obama got a gazillion
dollar and it wasn't royalties, It was an advance on
royalties for the book, and it was because the publishing

(05:39):
house knew they could sell a whole bunch of those
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.

Speaker 3 (05:57):
Exactly it's not going to be a New York Times bestseller,
and I'm okay with that.

Speaker 1 (06:04):
I'm disappointed it should be.

Speaker 3 (06:05):
I mean, never wild if it was. But I don't.
I don't see that happening anytime soon.

Speaker 1 (06:11):
Everybody's doing hot Wire Native these days.

Speaker 3 (06:15):
Hopefully, you know, the broader New York Times audience is
also doing hot Wire Native and they'll understand what I'm
talking about. But maybe the second edition.

Speaker 1 (06:25):
Yeah, well, you know, we are in the rails renaissance,
is what I'm hearing. So but but but let's let's
move in and talk about hot Wire Native, because I
think that's probably where most people want to want to
hear about. I think I think the book Insider Baseball
is helpful for the people who may want to write
a book or you know, maybe they're like, oh, this

(06:45):
publisher does a good job on these things and takes
good care of their authors, and so I want to
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.

Speaker 3 (07:07):
Yeah. So hot Wire Native takes your mobile website and
shoves it inside of an app that you download from
the App Store or Google Play. So your app itself,
the code is essentially a web browser that has you know,
maybe a native tab bar, native navigation, push onification, stuff

(07:28):
like that, but the majority of the content is a
WebView hitting your server, probably your Rails server, and rendering
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

(07:49):
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

(08:11):
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

(08:33):
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.

Speaker 2 (08:49):
I think one key point that also needs to be
made is its separate code basis for iOS and Android,
which I'm a huge fan of because I don't believe
the one code based across money platform thing has ever worked.
So I really like the fact that you have to
separate code bases which kind of share this common engine

(09:10):
off the rails app.

Speaker 1 (09:13):
Yeah, I'll say I have done.

Speaker 3 (09:14):
The two code bases are essentially rappers, right Like there's
until you go into real native implementations of things. The codes,
the code length in the native apps is relatively minimal.

Speaker 1 (09:30):
Yeah, I've done some Turbo or no, not turbinative. I've
done some React Native, and I mean they tried to
sell you on the one code base for everything, but
I think eventually they just had to acknowledge that sometimes
you're just going to have to deviate and have this
for this and that for that, but yeah, it's it's

(09:54):
like a full takeover on the javascripture, building the interface
in the whole nine yards and what I've seen and
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

(10:14):
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.

Speaker 3 (10:25):
And one of the big recommendations I have is to
continue using your web design in the apps. Like if
you're trying to chase iOS specific iOS Native UI and
Android Native UI, you're always just playing catch up. So
doing your continuing your you know, your tailwin CSS or

(10:47):
your Twitter bootstrap, you know styling on the mobile apps
is usually the best approach because you just have too
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

(11:09):
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.

Speaker 1 (11:16):
Yeah, so what's new, I mean besides the name change.
You know, what are we looking at here?

Speaker 3 (11:24):
Yeah? So Turbo Native became hot wire Native a few
months ago, and the big change is that it now
encompasses what used to be called Strata. Strata is or
was the library formerly known as Strata is the way
to communicate to your webue through JavaScript. It's how you

(11:47):
can add It's kind of like stimulus for mobile apps.
You add native sprinkles to your apps. You add a
button in the top right or the top left. You
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

(12:08):
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.

(12:30):
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

(12:50):
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

(13:11):
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.

Speaker 1 (13:34):
That makes sense. I have to say, there's this really
terrific book out there. I don't know if you all
have heard of it. It's called The Rails and hot
Wire Code X and I was going through some steps
in that for Turbonative at the time. And yeah, a
lot of this stuff that you're talking about, like the
extra installation step, it wasn't impossible to figure out, but

(13:57):
it wasn't something that I was regularly doing. So it
felt like it took an inordinate amount of time to
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.

Speaker 3 (14:13):
Yeah, the way I look at it, like Turboonative, the
hot Wire Native is like equivalent on rails to writing
a routes a route, adding a controller, and adding a view.
Those are all wired up magically by their name. Right,
you have a posts controller, it's going to render posts
slash index or post slash show, depending on the method

(14:33):
you're in. Turbo Native required you to manually say okay,
the post, the get request to posts has to go
to the post's index controller, and the post's index controller
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

(14:57):
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

(15:18):
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.

Speaker 1 (15:34):
I wish, how does that make you feel? With all
the stuff you wrote in that book.

Speaker 2 (15:40):
Honestly, it not doesn't make too much of a difference
to me, because uh, like it is it's a false
moving kind of Hey, yeah, and I knew that, and
excuse me, and I kind of And that was the
reason why I decided for the second edition in my book,
I wasn't going to cover the Native stuff anymore because

(16:01):
I'm I've got both my feet firmly in the website
of things, and it was it's quite a lot to
do keeping up with all three platforms. I'm like, yeah,
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,

(16:23):
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

(16:46):
really happy to hear that these changes are being made.

Speaker 3 (16:51):
Yeah. So much of the old way of doing things
was just like totally manual, like here's a link, what
do you want to do with it? There was no
routing in place, there was no modal handling, there was
no dismissing like here's a link, here's a WebView, like,
go for it. It was so thin around the web view,

(17:12):
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

(17:33):
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

(17:53):
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.

(18:15):
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.

(18:37):
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?

Speaker 1 (18:49):
You know?

Speaker 3 (18:50):
And I'm trying to scream from the from the mountaintops
of yes it is. I have many, many clients running
these apps, but it's hard when there's thirty open issues
in the last commit was six months ago. It's not
the case anymore.

Speaker 1 (19:02):
Yeah, So speaking to that, right, speaking to kind of
keeping things up to date and stuff like that, I
will say that one of the things I ran into
pretty fast was that. And I think I was working
off an older version of I Use's book Codex book.
But and I'm looking forward to this in your book

(19:23):
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

(19:45):
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.

Speaker 3 (19:55):
Yeah, framework, it's technically a library, right, but like I
call it a framework because we're building hot Wire Native app.

Speaker 1 (20:01):
Yeah. Anyway, so how how well are they doing staying
on top of those things? Right? So when Apple releases
a new iOS version or Android releases a new version,
you know, yeah it is thirty seven signals or whoever's
working on it keeping that up to date. And then
is your book going to stay up to date? Yeah?

Speaker 3 (20:22):
So right now we're in this interesting part where Android
SDK thirty five is like the default with new Android
studio builds, but hot Wire Native Android works only with
Android thirty four. So if you like, create a new
Android project right now, and you know, this is February twentyeth,

(20:43):
twenty twenty five, we're in really that awkward time where
the new life that became the default last week, and
we have an.

Speaker 1 (20:50):
Up there last week, okay, like last.

Speaker 3 (20:54):
Like the SDK has been around for a while, but
it was became the new default and Android like very
very recently, right, So if you create a new Android
app right now, it will be broken. You have to
drop down to thirty four and you're gonna get all
these warnings from Android Studio. So there's an open pr
already for hot Wire I need of Android. You're just
doing all our due diligence to make sure it works.
But like things like that are we stay on top

(21:17):
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.

Speaker 1 (21:36):
That's why I always buy the digital version from the
Ragmatic Studio and not from Amazon, just because they'll email me, hey, dude, there's.

Speaker 3 (21:43):
A new one exactly exactly, yeah, direct from the publisher.
You get an update every time I update it. And
right now we're in a really good spot with iOS
iOS just released a new version of x code that
changes some things about how folders and groups are related
under the hood, and like, we're using that new stuff,
so we're on up to speed there. But Android, the

(22:03):
book is written for thirty four, not thirty five, because
I have to wait till the hot wire native Android
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

(22:25):
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,

(22:47):
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

(23:08):
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

(23:28):
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.

Speaker 2 (23:48):
Yeah, when new stuff comes out in reales, I'm always
like organizing. I'm still agonizing about what to do with
the second edition, what to include, what takes It's it's
a lot harder when you're when you're a nor book
author as well, which actually segues nicely into another conversation

(24:09):
I wanted to have, which is, you historically were primarily
an iOS develop permise, Am I right in saying that?
And you did Android for this book as well? That like,
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

(24:32):
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

(24:53):
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.

Speaker 3 (25:09):
Oh yeah, And.

Speaker 2 (25:10):
I'm like, how was your experience like learning Android?

Speaker 3 (25:17):
Yeah? I would say that I didn't really start learning
Android until the Java to Cotlan migration like change. Like
once Cotland became the default language for Android apps and
Android Studio, that was when I seriously started considering Android
and started doing Android projects for clients. All of my

(25:40):
public material, like my newsletter, my blog posts, my Twitter
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

(26:01):
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

(26:23):
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,

(26:46):
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

(27:07):
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.

(27:30):
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

(27:52):
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

(28:13):
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

(28:33):
chunk to work on it, and I'm hoping I can
finish it.

Speaker 1 (28:37):
It sounds like the old yarn for programmers, where it's
the first ninety percent of the work and then you
know the second ninety percent of the work.

Speaker 3 (28:47):
Oh my god, totally, And I know that as soon
as I finish the manuscript, the real work starts of
like the editor, get the first round, development editor, the
beta reviewers, then the publishing editor, and then we talk
about typos and layout and it's like grammar, Like, we
haven't even addressed those things yet, you know, and that's
just going to be i know, the most tedious, tiny changes,

(29:08):
but they'll all make a better book. And that's why
I'm working with a publisher.

Speaker 1 (29:13):
Yeah, so, you know, kind of getting into this where
you have a book, you know, you're walking people through
building apps. I guess some of the questions that I
have getting into kind of what you can and can't
do with hot Wire Native, right, And I think we
went into some of this in the other episode. But

(29:35):
the biggest podcast that I do every week is JavaScript Jabber. Right.
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

(29:56):
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?

Speaker 3 (30:07):
Yeah, short answer is yes. The native frameworks. Hot Wire Native,
iOS and Android are platform agnostic. They will work on
any back end, any web rendered content as long as
you are doing your page to page navigation with TURBOJS.

(30:28):
So if you're not doing turbo JS, which is the
default on new Rails apps it has been for a
number of years, you will not get the callback handlers
to the native apps to know to present a new screen,
to know to do the native transition, to give you
the hooks to make changes. So my recommendation is usually like,
if you have Rails and you're using hot Wire, hot

(30:49):
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

(31:11):
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

(31:32):
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.

Speaker 1 (31:45):
Right. So the other question that I have is, I
know that some people have a tendency to like they'll
run into some some weird gotcha's. I think my favorite
one is that you have a form submit and a
lot of times it'll met with turbo turbo stream and
then you know, the way that you put your page together,

(32:05):
it doesn't actually reload anything, and so then people just
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.

Speaker 3 (32:21):
Yeah, So anything that's happening on the same page that,
like I use the example is your URL changing. If
your URL is changing, that will trigger most likely a
new page, a new screen getting pushed on the native
apps because you're doing like a full on TURBOJS navigation.

(32:43):
If you're doing something where you have a turbo frame
and that's making a request that's happening inside the turbo frame,
that's not going to push a new screen onto the stack,
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

(33:04):
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

(33:24):
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

(33:47):
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

(34:09):
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.

Speaker 1 (34:22):
Yep.

Speaker 2 (34:24):
Do you want to talk briefly about the I don't
know if these are still a thing that there are
three pods which are drawn in rails specific of a
hot wire native received historical location, Resume historical location, and
refresh historical location. I don't know if those are still
a thing and scenes relevant. We could probably chat about

(34:45):
that as well.

Speaker 3 (34:46):
Yeah, for sure. So those are the historical location routes
and the turbo rails GEM includes those by default. It's
also what exposes the hot wire native question mark helper
to essentially say, is this request coming from a hot
wire app to do conditional logic. Those three routes were
something that I didn't know about for a number of years.

(35:07):
They've kind of flown under the radar. They kind of
were shoved in turbo rails because base Camp needed them,
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

(35:27):
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

(35:50):
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

(36:13):
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

(36:36):
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.

(36:57):
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.

Speaker 2 (37:11):
Yeah. I found that the integration with the redirect helps
really really isful because you could just do something like
receid or redirect to.

Speaker 3 (37:21):
Exactly. Yeah, exactly.

Speaker 1 (37:24):
So I have another tangent other question that's not in
this vein at all. One of the things that I
see people talk about, you know, when they're talking about
the different options, right, usually it's in the jobscript world,
and so they're looking at like ionic capacitor kind of thing,
which is sort of kind of in this vein and

(37:46):
sort of kind of not in this vein. And then
you've got the React native, and then you've just gotten
like straight up native where you're writing swift or Coughlin.
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

(38:09):
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

(38:29):
are there mechanisms that allow you to do some of
these things.

Speaker 3 (38:33):
Short answer is, if you need an offline first app,
howt wire native is on a good choice.

Speaker 1 (38:39):
Okay, You're you're gonna.

Speaker 3 (38:40):
End up having to build out so much of the
code base natively to do offline access first that it's
not worth trying to kind of shove hot wire Native
into it. If you have an app, you know, kind
of moving along the spectrum here. If you need an
app that is mostly web connected but has like one
or two offline features snapping a photo and uploading it

(39:01):
when you have Wi Fi, you build a hot wire
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,

(39:24):
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

(39:45):
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,

(40:07):
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,

(40:28):
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

(40:50):
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.

Speaker 1 (41:00):
Right. So I have two use cases that I'm thinking
of here, and one of them is kind of like
that where I've talked about, Hey, I'm politically whatever whatever.
I'm not going to get into all that, but we
have an issue where we have a caucus night in
Utah every two years, and last year we tried to
do a registration and that was a web app, and

(41:22):
then we wanted to be able to scan people's QR
codes and check them in, and the Wi Fi at
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

(41:42):
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

(42:04):
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,

(42:26):
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

(42:46):
cash those pages or I can yeah things like that.
Just let that run as a regular app.

Speaker 3 (42:54):
Yeah, yeah, exactly. And offline cashing is like a whole
another topic that is not supported right now but is
supported in like base camp and hay if you notice that,
So that is something that like maybe there's opportunity to

(43:14):
upstream that. Maybe there's opportunity for thirty seven signals to
get like a public Here's how you could enable caching.
There's been some open prs that have been closed over
the Reese over the last year or so that it
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

(43:36):
then you try to access that same page without Internet access,
like you get a cased version right.

Speaker 1 (43:42):
Well. The other thing that I can see is, and
I've seen this in another apps, and you can do
this with PWA's you should be able to do with
Turbo Native is you've got the offline storage kind of thing,
and so you just you just cram the state up
into the offline storage and then when they browse, Yeah,

(44:04):
it checks to see if you have access to the Internet,
and if it doesn't, then it just loads the data
off of what's you know, what's held in memory essentially.

Speaker 3 (44:12):
Yeah, yeah, exactly, Yes.

Speaker 2 (44:15):
That was actually gonna be My next question is how
do you feel about using like service workers for offline access.

Speaker 3 (44:22):
Yeah, service workers are something that I have very little
experience with, so I can't comment on anything like firsthand,
but I do know.

Speaker 1 (44:33):
That it adds it adds to service workers chs in
RAILS eight, So I'm assuming they're I mean, I'm giving
you access to that kind of exactly.

Speaker 3 (44:41):
Yeah, so like PWA stuff without how you know, hot
wire Native removed is already on a great path with
Rails eight. The Android side has actually a better story here.
Service workers work better in an embedded web view. Right now,
there's this issue with WK WebView, which is the WebView

(45:01):
that powers the iOS apps, and PWA like features don't
exactly work in the way that they work on the
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

(45:25):
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

(45:49):
embedded web browser limitation.

Speaker 1 (45:51):
Yeah, JavaScript Jabber. We did an episode where it was
mostly Dan, but he he basically just ripped into Safari
because there are a lot of features that make web
enabled apps better, cleaner, easier to run that Safari just

(46:11):
doesn't implement, and where it causes issues on their end
on the JavaScript end is that yes, you can get
Chrome or Brave for your iPhone and it's basically a
dressed up version of Safari, and so you have the
same issues. And so yeah, this is this is not
an isolated issue, and there are people outside of the

(46:32):
Rails community that are working on workarounds for a lot
of stuff.

Speaker 3 (46:36):
Yeah, not specific to how our native just Safari, even
though it's my browser of choice, is a kind of
a pain in the butt.

Speaker 1 (46:45):
Yep, you can say, Wow, you're the only person I've
ever heard say that.

Speaker 2 (46:53):
I kind of want to go back to something we
kind of we touched on at the start of the talk,
and that like more about the process of a writer book.
I know, if I remember correctly from your social media,
you weren't sure whether you wanted to self publish or
go with the publisher, and eventually you did go with
the publisher. And I have personally self published, so I

(47:13):
just wanted to compare notes, What made you go with
the publisher? What have you liked? What have you not liked?

Speaker 3 (47:19):
Yeah, there's two big re I guess, one big reason
for going for a publisher and one big reason against
self publishing, which both led me towards using a publisher.
The big reason against self publishing is that going self published,

(47:40):
the benefit is getting one hundred percent royalties or ninety
x percent royalties, right, like, you make more money per sale.
My goal was not to make money off of this
book directly. My goal is to get clients and exposure
and you know, solidify myself as the expert in the space.

(48:00):
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.

(48:21):
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

(48:43):
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

(49:07):
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

(49:30):
I would have had to have done going self publishing.

Speaker 2 (49:34):
Yeah, man, self publishing is a hard wack, just to
kind of give our listeners the other side of the kind.
Because I decided to solve publish, and I honestly went
through the same kind of decision process, And yeah, marketing
myself as a freelancer was a huge part of why
I wrote my book as well. But for me, the

(49:56):
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

(50:19):
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

(50:42):
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,

(51:02):
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

(51:23):
someone else's answer.

Speaker 3 (51:26):
Yeah, I think that if your goal is to just
like get something out as quickly as possible, also, like
you have to self publish. It's going to take me
almost to the month two years from the time I
started writing this to the time it will be a
physical you know, I can hold it in my hands
done with the printing press.

Speaker 1 (51:44):
Like.

Speaker 3 (51:44):
That's a really long time. And I mean it actually
worked out for me because during those two years, Tribonnative
became hot Wire Native. Like I would have self published
a book for Turbo Native and then had to like
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,

(52:08):
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.

Speaker 1 (52:18):
Yeah, one a couple of other things I wanted to
just push in here. So the book I wrote it
was on building your career and finding your next job.
And to be honest, I mean at this point I
would go back and I would put add a whole
bunch of stuff about using AI to understand your resume
and line it up with the job postings and things

(52:41):
like that. You know. There was a bunch of other
stuff in there about building your personal brand. That is
a separate book. But yeah, I didn't really understand what
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

(53:04):
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

(53:27):
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

(53:48):
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

(54:09):
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

(54:30):
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

(54:51):
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

(55:12):
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

(55:34):
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

(55:54):
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

(56:14):
have helped me get the book out and had to
be the best thing possible. Yeah.

Speaker 3 (56:18):
I think that that last point is something that I
haven't spoken about, so it might be interesting to cover here.
One of the first things that I talked with Pragmatic
about was the structure of my book. I went in
wanting to do two books, an iOS book and an
Android book. That was like my original pitch. I was like,

(56:40):
I can knock out the iOS book in a couple
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.

Speaker 1 (56:57):
And that was why I can tell you I want
one book.

Speaker 3 (57:02):
Exactly that, and that's where we kind of it's exactly
where we ended up, like questions being asked of me
of like, well, what does the audience want to read?
Is the audience doing is ninety percent of the audience
doing iOS and never touching Android? Okay, well, then Android
goes second. Like all of these little decisions that I
would have either hemmed and hawed over for months and

(57:23):
just never made a decision on or made a just
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

(57:45):
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

(58:08):
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

(58:30):
not been happy with it.

Speaker 2 (58:33):
Yeah. Could you talk about a little bit about the
process of finding a publisher what it entailed.

Speaker 1 (58:41):
Yeah.

Speaker 3 (58:42):
I A lot of my looking for a publisher phase
was actually do I want to self publish or go
with a publisher, So most of my research was spent
talking to folks who had self published or folks who
had gone with a publisher, you know, in casual calls.
I think I spoke to like ten people either through
a zoom call or like a Twitter conversation or email.

(59:05):
And once I had spoken to everyone that had self
published or gone through a publisher, I was like, Okay,
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,

(59:26):
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.

(59:49):
Once I decided my goal of getting more clients, okay PRAG, Yeah.

Speaker 2 (59:57):
Is that just like to send them an email?

Speaker 3 (59:59):
And yeah, I ended up sending an email to PRAG.
I submitted an official pitch to O'Reilly, and I submitted
an official pitch to one more publisher that I can't
I can't recall the name of. The third one that
I can't remember the name of never got back to

(01:00:20):
me at all, and O'Reilly said that they aren't looking
for such a like cross platform book right now. It
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

(01:00:41):
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.

Speaker 1 (01:00:59):
Let's let's gets to talk to He is so funny.

Speaker 3 (01:01:03):
He's awesome. I just did an interview with him like
two weeks ago and it just got published for this week.
We chatted for like an hour and we cut it
down to twenty minutes of just like what the books about,
what hot Wire Native is, and he is such a
delight to talk to and seeing those little clips of
him asking like you know, these these naive questions is
so much fun.

Speaker 1 (01:01:24):
Yeah. I think the other thing you have to because
I think some people are probably going to be thinking oh, well,
you know O'Reilly or you know Pearson owns O'Reilly. But
you know, they just don't get it that that may
not be the case. They know the audience they're trying
to sell to. Yeah, and so does prag right, and
so Pragmatic Bookshelf. I mean, they know they have pick acts,

(01:01:47):
They've got you know, agile web development with rails or
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.

(01:02:12):
It's the same with Manning or Packed or any of
the other ones that you went to.

Speaker 3 (01:02:15):
Yeah, Packed, that was the one I reached out to.

Speaker 1 (01:02:16):
Packed.

Speaker 3 (01:02:19):
So y, yeah, I mean, my book's been came out
like officially about a month beginning of January, like January
sixth or ninth or something, and it's been in the
best seller list and since then it hasn't dropped out,
So like there's clearly something aligned with their audience and
my book content, which is awesome to see.

Speaker 1 (01:02:40):
Yeah, and they do a good job too. Like if
it's coming out, you know, because you said you haven't
quite finished it, Yeah, you buy it now. You get
a good deal on it for one and then you
get the finished product anyway, And so if you want
to get started and get you know, ninety five point

(01:03:01):
nine percent of the way down the road and then
you get that last piece that Joe's working on, yeah,
it works out pretty well.

Speaker 3 (01:03:11):
Yeah, it works out pretty well. And like you just
got it early, you're going to get the rest of
the content eventually. You just got it early. And for
cheaper You do have to deal with a terrible layout though,
because coad snippets are are are smushed across multiple pages
because the layout editor hasn't gotten in there. So if
you can deal with that, it's a pretty good trade off.

Speaker 1 (01:03:31):
Yeah. So a couple of things that I'm just going
to throw out there as well. So with Ruby Geniuses,
we're doing a book club every month. For March, we're
doing a book on prompt engineering because a lot of
people want to learn AI. But I've already decided that.
In April and May we're doing the hot Wire Native

(01:03:53):
book by Joe, and then We're also going to do
the Rails and hot Wire Codex because a lot of
people are kind of looking for that front to back,
soup to nuts, how do I build this thing the
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.

(01:04:15):
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.

Speaker 3 (01:04:28):
Yeah.

Speaker 1 (01:04:28):
That's why I like the books is because you you
steer me off of the tracks so that I'm not
heading into an oncoming train that I didn't even know
was out there. Yeah.

Speaker 3 (01:04:39):
A lot of my book, I think at least once
a chapter, you'll do something and you'll get a you know,
air quotes, unexpected result. That's how I've seen developers try
to build hot Wire native apps, and you know, during
the tab when you build tabs, the first time you
launch the app, the app is just a completely white
screen and I have a screenshot of that, you know,

(01:05:01):
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

(01:05:22):
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.

Speaker 1 (01:05:35):
Yeah. I used to do that when I did the
Teach Me to Code screen casts. I'd leave the mistakes in,
like I would cut the googling the solution out. But yeah,
I'd have people ask me all the time, why'd you
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

(01:05:56):
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.

Speaker 2 (01:06:13):
Yes, you mentioned briefly just like the layout of it
iffy and stuff right now. So another thing, another huge
challenge which you'll have if you're self publishing, is literally
just producing a PDF and an e pub Like it
is stupid hard to just convert something you've written into
a PDF and EPUB And I was surprised, it's just

(01:06:35):
how difficult it was. So when you work with the publisher,
is that something that do they give you some tools
to make life easier with that.

Speaker 1 (01:06:44):
Yeah.

Speaker 3 (01:06:45):
PRAG has its own markup language and it's like proprietary
you know, nd under nda all of this awesome stuff,
and it handles just I write one file and it
then can output to PDF, to moby, to epub to
physical copy like it does all of these amazing things

(01:07:06):
with its own markup language that I don't have to
worry about like should this be a link on mobile
but actually a page number on a physical book? Like
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

(01:07:28):
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

(01:07:50):
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.

Speaker 2 (01:08:14):
Yeah, that's sounds like a huge case for a publisher.

Speaker 1 (01:08:18):
Yeah, yeah. So on one thing that I used brought
up was the content ownership. So who has rights to
your book?

Speaker 3 (01:08:29):
Yeah, PRAC has rights to my book. They have rights
to the content in the book, and I am able
to repurpose that content if I want to. So I've
been thinking about doing like a course that would be
very similar to the content of that book, but I can't.
I can't reproduce like the whole content and sell it
or publish it on my blog or anything. There's also

(01:08:51):
exceptions to that, like if I want to sneak peak
a chapter or two, I can get permission and republish
it word for word, and as long as I outline
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

(01:09:14):
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,

(01:09:34):
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

(01:09:55):
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,

(01:10:15):
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.

Speaker 1 (01:10:30):
Awesome. Well, we're at about an hour and ten minutes.
I think we pretty well covered this too. It seems
like there's a lot there definitely an option worth looking at.
If you're looking at putting a mobile app on your
rails app and you're not super keen to oh now
I have to add an API and I have to

(01:10:51):
authenticate the API, and then I have to turn around
and write an app that consumes the API, and I've
got to build new interfaces and blah blah blah blah blah.
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?

Speaker 3 (01:11:10):
We will put the coupon code in the show notes,
because there is one. I cannot remember it right now,
but you can get the book at if you go
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

(01:11:34):
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.

Speaker 1 (01:11:54):
Yeah. And then I'm also just going to put this
out there. I have an email list for the show,
and I have two codes to give away free copies
of the book. And so if you want a copy
of the book for free, and I'm sure Pragmatic bookshelf's great,
So if you buy it and then you win a copy,

(01:12:14):
they'll they'll figure it out with you. I say that
confidently without any authority to make promises for him, because
they've just been so great with everything that I've ever
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,

(01:12:34):
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

(01:12:56):
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,

(01:13:17):
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.

Speaker 3 (01:13:38):
Yeah, and the discount code is Ruby Rogues hot Wire.
We'll get you that thirty five percent discount from the
Pragmatic bookshelf upsite.

Speaker 1 (01:13:48):
Awesome. All right, Well, let's go and do some picks
and then we'll go ahead and wrap up. I usual,
do you have some picks for us?

Speaker 2 (01:13:57):
Yeah, so actually thinking of them during the show because
they didn't think of any before. A couple of non
technical picks. Again, I always started to do a music pick,
so I'm going to continue with a music pick. And
there's an album that I used to that I loved
when it came out in twenty nineteen and kind of
fell by the way, so I don't like discovered it again.

(01:14:17):
A couple of weeks ago and I was like, Daddie Ill,
I forgot how amazing the album is. It's called EmPATH
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

(01:14:38):
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

(01:15:01):
contact of anything else, I'll choose that as one of
my picks. Yeah, that's all I've got today.

Speaker 1 (01:15:09):
If you're bored, I've got plenty of stuff that you
can do for me.

Speaker 2 (01:15:14):
Else, I mean lazy and can be bothered to do
the actual stuff I should be doing.

Speaker 1 (01:15:19):
Nice. Oh, okay, never mind, then I'm gonna jump in
with some picks. My first pick I always do a
board game. I don't think I picked this last week,
but I'm picking groundhog Day the game. Now. Groundhog Day
is a movie that came out in what ninety something,

(01:15:43):
ninety six, I don't know, I'm totally guessing. Anyway, funny movie,
Bill Murray, classic movie. And I feel no compunctions whatsoever
in putting out spoilers because the movie is so freaking old.
Came out in ninety three, ninety three even better, right,
it's more than thirty years old. So anyway, in the game,

(01:16:08):
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

(01:16:32):
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.

(01:16:52):
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

(01:17:13):
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

(01:17:34):
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

(01:18:00):
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

(01:18:21):
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,

(01:18:41):
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

(01:19:03):
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

(01:19:24):
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,

(01:19:46):
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,

(01:20:06):
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

(01:20:30):
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?

Speaker 3 (01:20:44):
I have two picks, a book and also a board game.
The book is Beauty Land. I read it. I just
finished it a few nights ago. It is the tale
of a girl grows up in Philadelphia and has kind
of a troubled childhood and she gets a fax machine

(01:21:05):
and she starts faxing and slowly finds out that she's
an alien living in Philadelphia and she communicates to her
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,

(01:21:27):
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

(01:21:49):
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

(01:22:09):
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,

(01:22:30):
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

(01:22:51):
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.

Speaker 1 (01:23:08):
So I'm just going to ask a couple of questions
because one thing that I've run into is I've bought
games have the solo player mode and it's totally different
from the regular game, and it's usually not as good.
So how close does the solo game align with the multiplayer.

Speaker 3 (01:23:25):
It's the exact same game solo, and then when you
play with multiplayer, it adds two rules, so it's actually
meant for solo play, and then multiplayer is like a
mode almost that lets you play cooperatively. So all of
the rules, everything is meant to be played solo, with
a few exceptions.

Speaker 1 (01:23:44):
Yeah. Board game Geek has this one at a weight
of two point ninety three.

Speaker 3 (01:23:49):
Yeah.

Speaker 1 (01:23:49):
It says it can take anywhere from thirty to one
hundred and fifteen minutes. It says age twelve plus, So
it sounds like it's a little involved but probably isn't
terribly hard to pick up. Is generally how I would
read that.

Speaker 3 (01:24:03):
It's it's easy ish to play, it's really hard to master,
So like learning the rules is reading a couple of
cards and knowing when damage happens and not being good
at it and actually beating one of the four levels
requires a few playthroughs.

Speaker 1 (01:24:20):
Okay, it looks like fun though.

Speaker 3 (01:24:22):
It's a lot of fun. It's a lot of fun.
I back to the Kickstarter version, so I have like
metal coins and a little pouch and stuff for it.

Speaker 1 (01:24:29):
It's like, oh, yeah, that's always fun.

Speaker 3 (01:24:31):
Yeah, it's cool.

Speaker 1 (01:24:33):
Yeah. I'll buy a game at the game Store or
on Amazon, and then I'll play it with my friend
and yeah, the same game will have all these nice
little pieces in it, and I'm like, did you make
these or something. It's a Kickstarter version, yep, yep. Yeah.
Board Game Life. Yeah, that one came out in twenty
twenty four. That's probably part of the reason I haven't

(01:24:55):
played yet.

Speaker 3 (01:24:56):
It's a good one.

Speaker 1 (01:24:58):
Yeah, I did come up with the other thing. I'm
just going to throw it out real quick. It's open
WebUI and it's really easy to run on top of Olama.
So you install Olama, you tell it which model you
want to run. If you've heard about deep Seek, that
one made a splash. You can run deep Seek versions.
You can get the uncensored version of deep seek. It's

(01:25:19):
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

(01:25:42):
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?

Speaker 3 (01:26:00):
Easiest spot is my website Mazzilati dot com. I got
links to all the socials there, my newsletter, my blog posts,
and also the book.

Speaker 1 (01:26:10):
All right, well, one more time. That code if you
want twenty percent off is Ruby rogues hotwire. That's correct,
and you just go find it on the Pragmatic bookshelf.
It's pragprog dot com. And yeah, all right, folks, we'll
wrap it up here until next time. Max out

All Episodes

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

Episode Transcript

Popular Podcasts

Stuff You Should Know

My Favorite Murder with Karen Kilgariff and Georgia Hardstark

The Joe Rogan Experience

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Joe Masilotti on Hotwire Native Updates, Challenges, and Opportunities - RUBY_672