Speaker 1: How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at patreon dot dot NetRocks
dot com. Hey guess what it's dot net Rocks twenty
twenty five edition. I'm Carl Franklin, I'm Richard Campbell. Happy
New Year everybody, and what's how did you? How'd you
do your New Year's?
Speaker 2: We did New Year's up on the coast because we
went down to the city for Christmas, right, spend time
with the girls. The youngest is pregnant, so called the
baby bump. Christmas very nice and uh, and then New
Year's we came back up. I had a party in
the boathouse with a little mixing of the worlds. You know,
we're building friendship groups up on the coast, so a
few of those couples showed up and a few from
back on the mainland.
Speaker 1: And yeah, I saw the pictures on Facebook. Looked a
lot of fun. Yeah, you know, the best thing you
can hope for in the new year. Belly laughs, like
laughing so hard you're crying. That's what we did overde
That's great. Yeah, awesome. Well we just had a quiet
New Year's here. It was nice, you know, just the fam.
It's always good. Yeah. So let's start this show with
a better know of framework, which is interestingly about last year.
Speaker 2: Roll the music. Interesting, man, what do you got?
Speaker 1: It's a video by the Visual Studio team our favorite
new visual studio features of twenty twenty four. So they
took a look at all the things that were added
a visual studio in twenty twenty a lot.
Speaker 2: Yeah, right, Like it's constant.
Speaker 1: Yeah, And you know, if you're like most of us,
you don't know about these new features until somebody says, hey,
you know Scott Hanselman says, hey, do.
Speaker 2: You know this?
Speaker 1: Yeah, and then you look it up.
Speaker 2: People make whole talks about this, just showing features in
studio you didn't know about because it's just so darn
many of them. Right.
Speaker 1: Yeah. It's because the word of coding, hasn't it the
Microsoft word?
Speaker 2: Yeah?
Speaker 1: Yeah, Well, anyway, it's a good video and if you
have how long is it? Well, Anyway, it's a good
video and if you got about twenty minutes to kill
check it out. It's good stuff. So that's what I got.
Know it, learn it, love it. Who's talking to is?
Speaker 2: Richard grabbed a comment of a show nineteen sixteen then
when we recorded with our friend Rendel called how simple
is as simple as possible? Yeah? And another friend of ours,
Richard ra Chima, also known as codeputer, had a good
comment here, mostly about Blazer, where he said simplicity and
web application development it's not a simple conversation Blazer server
and transitioning to WASM is also not simple. So why
are we doing web app development anyway? App distribution to
maintenance is why we wanted it. Web apps over the
client side app installs. Yeah, definitely always running the current version,
don't need to deploy running in a sandbox like there's
good things makes sense. Yeah, So we leveraged the distribution
model of the browser and then got busy building apps,
this time without easy acts to what we had before
the mistley client side resources. Nothing that fifteen megs of
JavaScript can't fix with a sprinkless CSS to really challenge
that street.
Speaker 1: He's our age too, so he's talking experience here.
Speaker 2: Chris Love would have words with you. Oh yes, So
let's take application development, make the super puke it all
into a browser box and give it a solid stir
for fun, while dumping in new app features or ingredients,
more JavaScript frameworks and such as the goodness and all
the joy of distribution. HTML was never supposed to be
used as a U as a user experience interface for
application development amidst the formatting and presentation of electronic documents.
It was about scientific papers with iperlinking.
Speaker 1: Right.
Speaker 2: Then there's Blazer server. Let's not worry about WASM for
a now, just about using the server environment to create
HTML documents that are rented. A browser does not even
need a page refresh, It builds the page. Choosing marshal
or components. Click in the browser is meaning less without
the context of where it happened. A keystroke has the
same requirements in both cases. The event requires context. That
is simple. HTML is simple, but stupid. Why are we
making it more complicated? Somebody says server overload. Server load
for service side rendering using cloud resources not the same
as a web farmer's service. True applications never used servers
that use service is provided by servers. Your application needs
hosting resources from the cloud. Why are we thinking about servers?
And once again, Blazer server framework is nothing more than
moving the context of the client side event and exposing
that in the context of the application. Mix it an
application code, update the component of the dock, and render
just tailored bytes back to the document being viewed in
the client. It's nice, simple and with a minimal byte
count to transport. And that's my definition of web simplicity. Yeah,
I can't argue that. Shame we make such a messment.
Speaker 1: I've seen the light.
Speaker 2: Yeah, he's trying to anyway. Yeah, i'd rich thanks so
much for your comment. I'd send you a copy of
music Code by but you got one. Yeah.
Speaker 1: He's going to be a guest in a couple of
weeks at fall as well.
Speaker 2: And he's going to be a guest to shortly too,
so we'll be here from anyway. I'll tease them the more.
Speaker 1: Yeah, very good.
Speaker 2: And if you'd like a copy of music Code, I
write a comment on the website at dot NetRocks dot
com or on the facebooks. We publish every show there, and
if you comment there and I read it on the show,
we'll send your copy. Music code by.
Speaker 1: And music to code by, of course, is a series
of twenty four minute twenty five minute music pieces that
you can listen to while you code that helps you
focus and keep you from getting distracted. And if you
want to pay for it, it's at music tocode by
dot net. Also, you could get a copy by sending
us a message on the social media's other than facebooks.
We've been on ex Twitter for the longest time. We're
also on masted On and Blue Sky and some variation
at Carl Franklin and at rich Campbell.
Speaker 2: Right right, yeah, blue Sky seems to have all the
action these days. Man, Like I realized I was. I
was scrolling through Blue Sky today and it looks so
much like the old Twitter. I forgot I was on
blues guy.
Speaker 1: Yeah, except it's not dumb.
Speaker 2: Well, it's kind of the like the old Twitter.
Speaker 1: Yeah yeah, all right, let's bring on our guests. Nathan Westfall.
He is a senior no history. Oh you know what
I so, here's the thing I looked at nineteen thirty
five in the history and it's so jam packed, like
we can't even cover it all. But maybe I'll ask
you Richard what is your.
Speaker 2: I only pick one thing, you know me, I'm gonna
pick one thing. Yeah, and the one thing is James
Chadwick's proof that the neutron exists.
Speaker 1: How amazing.
Speaker 2: Yeah, well think about this. That's nineteen thirty five and
within ten years the first atomic bomb would go off. Yeah,
and you need neutrons like that's how fast?
Speaker 1: Yeah, So it's amazing the things that happened in this
relatively short time period. It was just explosive.
Speaker 2: Yeah, literally in so many different ways, right like between
between the Great Depression, the rise of fascism, the explosion
into World War two, like that was a tumultuous ten
plus years and it just happened to be doing shows
in those show numbers right now.
Speaker 1: And a byproduct was a lot of innovation, a by
product of the war and all of that stuff.
Speaker 2: Yeah. Well, for better or worse, the military spends a
lot and a lot of that funding was military.
Speaker 1: Highway system because of the military fifties in America.
Speaker 2: We got a little time yet for that. Yeah, it'll
be later this year.
Speaker 3: Yeah, yeah.
Speaker 2: Yeah.
Speaker 1: Still, it was Eisenhower's idea because he wanted mobility. Yeah,
all right, enough of that. Yeah, that's coming, Let's bring
on Nathan Westfall. As I started to say before, he
is a senior software engineering manager at Tyler Technologies, leading
the Cloud operations and mobile development team for student transportation.
He started development journey with Php and Ruby on rails,
but fell in love with the dot net ecosystem once
leaving college early for his first job outside development. You
can find him mixing audio at your local bar or
fishing on a frozen lake. One of those things.
Speaker 2: I do all the time.
Speaker 1: I wonder which one it's not fishing.
Speaker 4: Welcome, Yeah, thanks for having me.
Speaker 1: So you've been listening to the show for a while,
you said.
Speaker 4: I have been. Yeah. Yeah, kind of the way I
learn is podcast everything else, and you guys are fun
to listen to, So that's good. It's kind of as
Richard was saying earlier. It's nice to now see how
the sausage is made.
Speaker 1: So yeah, well it's good to have you at the table.
Nice past the sausage.
Speaker 2: So what have you been working on, Nathan.
Speaker 4: Yeah, so Tyler Technologies. What I work on in student
transportation is you know a yellow school bus you see
on the road in the US and Canada. You know,
we interact with so we're in one of every four
school districts uses Tyler system. And the app that I
here to talk about is the public facing app, so
the one that any parent who has a kid on
the bus that we integrate with can use called myrid
K twelve And it's an app that we rewrote earlier
last year, so in the beginning of twenty twenty four
it started to roll out, and it is a Blazer
Maui hybrid application works on web iOS, Android, and it
is much Blazer as you could possibly imagine shoved into
this app to have it run at scale and everything else.
Speaker 1: I've already got a man crush on you. Man that
is that is you're speaking my language here.
Speaker 2: What was it before it was Blazer?
Speaker 4: Yeah, good question. So it was examinant Forms. The original
version of this app actually came out a couple months
after dot net one, so dot net Core one was released.
That's how early we were to dot net core and
everything else. And what we learned early on was I
can do examer reforms pretty well. But then when I
have to make those same features on web in dot
net core and Angular JS at the time, my feature
drift became insane, right. It kind of became worse and
worse over time to try to do something in forms
for iOS, maybe something a little different for Android, and
then also then change languages entirely for Web. So we
got the opportunity to rewrite it in twenty twenty three,
released in twenty twenty four, and went full blazer, so
we could share about ninety five percent of our code
between iOS, Android, Web is all the same.
Speaker 1: That's fantastic.
Speaker 2: Yeah. What also means you battle through the tough times
at zamorin too, right, because that was oh yeah, those
were early bits.
Speaker 4: Yeah, correct, Yeah, when I even used examined it before
I joined Tyler, when Microsoft had only had acquired it,
like very very recently. So I mean I've been using
examined for almost as long as it's been help.
Speaker 2: Yeah.
Speaker 1: We I thought it was going to be a lot
smoother ride than it actually turned out to be. I
was so excited when when Zamoran you know, came on
the scene. Yeah, and the promise of jam forms and
all that stuff was just amazing and then just just
warm me down.
Speaker 2: Sorry, yeah, Well, and I wrestle with is it the
problem with the tool learning? Is it just a problem
with building mobile apps like this separation between working on
a machine different from the day app with the app
environment like that, cycle's just hard and it's diverse like that,
that combination just doesn't matter what the tools are. It's
a battle compared to any other.
Speaker 1: It is, and whether the tools keep you up to
date or you have to keep up to date, you're
always going to end up doing some kind of tweaking
on one platform you're not doing on the other. And
that's why I think the road that you took, which
is Blazer Hybrid, gets rid of all that because the
cross platform this is done in the browser, which is
had many many years to go to get its cross
platform story done, and it's there.
Speaker 4: No, I'm with you. I think the biggest part of
Exhibit Forms that was tough is even that you had
all this shared code and c sharp code at the time.
I'm fighting iOS at the time, you know, releases were
in June. Android was later in the year. I'd have
to update all my Android dependencies just so forms would
work right. And to your point, Karl, if I'm just
using a browser which I know will render my CSS
the same way, my dependency is just shrunk. And you know,
so small.
Speaker 1: So yeah, so if you can do a web app
in Blazer, you can do a mobile app in Blazer, right, yep,
that's what it comes down to.
Speaker 4: And we're testing it both because we even went the
whole route. We're not using Blazer server at all. We
went full web assembly. Yeah, I went the full If
I don't have to host the server, why would I? So, yeah,
sure that's what we're doing. Yeah.
Speaker 2: Well, and you've got a I mean, it's not really
public facing app in the sense that it is a
known set of users. It's parents of students, but it's
still a lot like the server load on that. I
think Blazer server makes a lot of sense with an
internal app with a certain number of employees done. Yeah,
to make that public facing it's really hazardous.
Speaker 4: Yeah, yeah, And our traffic's really predictable, right, Like we
can see different time zones come online because buses normally
roll in the same morning the same time East Coast
and then Central and then west.
Speaker 2: Right, right, you know when it's going to be busy. Right.
Speaker 4: Parents are going to check the f twice a day,
when their kids going to school and when their kids
coming home, and everyone's doing it at the same time.
Speaker 2: Almost, so aren't you then making an argument in favor
of server sign.
Speaker 4: Ah kind of you know, but the costs at the
end of the day for web assembly to support all
of this is I have we're partnered with AWS here
at Tyler, so we're using dot net on AWS. But
the whole web server for hundreds of thousands of parents
is an S three bucket and then a CDN and
I'm done.
Speaker 2: That's it.
Speaker 4: That's all I got.
Speaker 1: Yeah, that's great.
Speaker 2: Nice.
Speaker 1: So I got to ask, what are you using for authentication?
Speaker 4: Cognito Actually, huh, tell.
Speaker 1: Me about Cognito.
Speaker 4: Yeah, so Cognito. We we're going back and forth what
we should use. There's a whole bunch of obviously authentication
providers you can use Cognito. We just wanted to stay
within the Amazon ecosystem because we don't have huge requirements
for authentication. They have a nice portal for users self registering,
which is our big use case. It's not like we
create these accounts for parents. They can self register and
give us the option to do social logins down the road. So,
you know, we're over six hundred and fifty thousand users
that have been created in Cognito, and then even so
Cognitio create a nice pipeline because we were not in
cognito common examinineforms and they let you actually in real time,
So once a user tries to log in for the
first time, we can migrate those users in real time.
So no password change, no nothing.
Speaker 2: If you're going to run on AWS, you should use
AWS as authenticator, just the same way that if you're
going to run on Azure you should be using Azure AD, right.
Speaker 4: Like, yeah, I'm a big fan of peeping it together.
Speaker 2: Yeah yeah, yeah, it's just not worth the pain. Yeah, Like,
it's very challenging to build a unified authentication strategy across clouds,
fighting that a lot, right.
Speaker 1: And so I imagine that all the credentials are kept
out of your reach, Yeah, so that you don't you're
not liable for you know, break ins or anything like that.
Speaker 4: Correct, which is another big benefit. We used to host
it ourselves with dot Net's identity server and handled all
that and that's all gone now and all everyone got
migrated over and again that real time is nice because
you can use landa when they log in, Oh, this
user doesn't exist, let me check your existing user store
and the user never had to change their password. It
just moves right over and that's great. Nice starts working.
Speaker 2: So you did that, very nice migration. They never knew
you changed authentication strategies. Doesn't matter.
Speaker 4: Yeah, no idea.
Speaker 2: Then and then one day nobody's hitting that identity server anymore.
You can turn it off one day.
Speaker 4: Correct, Well that was I had the pleasure of a
couple of months ago finally turning everything off, and it
felt so nice to go through and web servers off,
APIs off, everything got shut down.
Speaker 2: Why do we feel good when we turn stuff off?
Speaker 4: It's like calming, right, Yeah, No, it's.
Speaker 1: The money goes back into your wallet, reversing the flow
of money.
Speaker 2: It's also it's also an end of pain, right, Like,
that's weary. It's not going to hurt you anymore because
it's the stuff.
Speaker 4: I know. There was a there's a brief period where
we were rewriting it, and I always hated getting a
you know, an issue come through and I'm like, I
got to open examin forms again and I got to
go through and fix this. And after using Blazer for
so long, rewriting it's it was hard to go back.
Speaker 2: Oh yeah, wandering back in his zamm reforms like walking
into a dark forest. Yeah, I remember why I left
this place. I appreciate that.
Speaker 1: I it's on my list of things to do to
open up uh MAUI in dot net nine and take
a good hard look at it.
Speaker 2: Again.
Speaker 1: I don't because ever since I found you know, the
Blazer hybrid MEI hybrid stuff, I'm I just don't. I
haven't gone back.
Speaker 4: Yeah, basically, so yeah, we've done. We've done a few
to play around with it, but I every time I
do it field and need of like I could just
do this and blaze and I'm used to it and
it's works just as good.
Speaker 2: Right yeah, yeah, well yeah, if you're getting the results,
if the customer is happy, which is parents, which are
who are never happy, then you're doing all right right right.
Speaker 4: Yeah, you can definitely say that again.
Speaker 2: So yes, yeah, yeah, don't mess with it.
Speaker 1: And how many users did you say you had?
Speaker 4: We currently have over six hundred and fifty thousand uh
registered in our active counts daily active counts prett high
on the top of that.
Speaker 2: So wow, you do not want to do tech support
for six hundred fifty thousand people. That's not good. No,
they got to be all self service, They got it,
but also they don't care. They just want to know
where the kid is.
Speaker 4: Correct, which is a whole other set of problems that
we had to do in a way that's helping both
the district, who is really our customer, right, The school
district is the one that uses our technology.
Speaker 2: Those the ones you're paying you, right, But.
Speaker 4: They're servicing the parents, and we also have to serve
the parents and the district. So how do I explain
to the parent, hey, this bus is out of commission, right,
and this is why you can't see where your kid is, right,
and solving all these problems to someone who's not in
the operation of school busing, right, making them not come
back at us. Obviously, we want to protect our operatings
as much as possible and be like, hey, your app's
not working, But at the end of the day, it's
you know, your bus didn't drive today because it's a holiday.
True story, right.
Speaker 1: So is that what your app does primarily as track buses?
Speaker 4: Yeah, so it does two different things. So you can
find your kids' schedule all through self registration. So if
I had my kid was in elementary school, I could
register them to the app and see, hey, the bus
is going to pick them up at this corner every
Monday through Friday at eight twenty in the morning. This
is my driver's name and what bus is coming. And
then if the district allows it and has the capability,
you can actually see when your bus is coming in
your real time. You get notifications kind of like Huber
if your bus is about to arrive, it's five minutes away,
it's running late, and kind of provides that experience. So
parents can just really quickly say, I mean, it was
a cold day up here in New York. I was
outside and realize how windy it was. I would hate
if I had to go stand at the bus stop
for twenty minutes hoping the bus would show up. No,
it's nice if I can get that notification just walk outside.
Speaker 1: What about kids fourteen and older, Let's say, can they
use the app as well?
Speaker 4: They technically can. We obviously try to restrict it as
much as possible as it's meant for the parent, But
there's parents have the ability to share that information with
any other account, right, so they can even say, hey,
for the day, the babysitter can have it to make
sure that my kid gets off the bus.
Speaker 1: Nice the kid wouldn't necessarily be waiting at the bus
and it's late and be able to flip up the
app and say, oh, yeah it's ten minutes late.
Speaker 4: Yeah, we have some kids that do it, but primarily
it's the older kids are kind of left on their own.
As you know as a parent, they kind of you're
becoming more of an adult. It's a lot of kids
in elementary school, right, because even in some states, depending
on your age, you have to be at the stop
for the kids to get dropped off. True, so I
don't want to wait outside.
Speaker 1: Plus there's the Kappa thing, right, Yes, the Kapa against
kids using software. If you were going to allow kids
I think it's fourteen and younger or under fourteen.
Speaker 4: Yeah, it's somewhere like that. Thirteen fourteen, Yeah.
Speaker 1: Thirteen and under, if you're going to allow them to
use it.
Speaker 2: Not that there's any sensitive information here, it's the location
of a bus.
Speaker 1: Yeah, you'd have to go through hoops yet that Yeah, And.
Speaker 2: We happen to be recording this when there was a
pretty big snowfall through central US. So I got to
think that impacts bus as a whole bunch. And that's
when everybody's going to be hammering on the app, like,
have we seen the maps?
Speaker 4: Correct?
Speaker 2: He's the bus running?
Speaker 4: Is it?
Speaker 2: Is it moving?
Speaker 1: Have you seen the maps? Like this white band all
the way through the Midwest from the from the west
coast to the east coast. Unbelievable. Yeah, quite a piece
of weather anyway.
Speaker 2: So do you present it as a map or is
it just a table of this is the bus, this
is where it'll be?
Speaker 1: Yeah?
Speaker 4: No, good question time. So it's it's all configured by
the district because different districts have different policies. And you know,
some districts have a policy where they don't want to
show the parents the bus just don't it's about to
arrive soon because they don't want angry parents getting in
their car and chasing the bus down because they miss
their kid and so on and so forth. Right, But
if they allow everything, Yeah, you can see your bus
on a map. We use signal R to broadcast that
information and then show it live within the app. You
can interact with it, follow it in three D all
this other fun stuff.
Speaker 2: Yeah. I like that. Yeah, I know that's yeah, so
you can go but very that's very like uber esque
in that sense. You can literally watch the vehicle emotion.
But I can also see why certain districts would say,
you know, that's probably a little too much information, that's
a creepy Yes, exactly.
Speaker 4: You get both extremes. I want to see everything and
I want to see nothing, right.
Speaker 2: Yeah.
Speaker 4: The Uber thing is is when we've been trying to
deal with for a while. Because Uber is obviously great, right.
I mean I've gone to the airport so many times
and I go to a conference, I'll pull up Uber
get where I need to go. But people don't quite
understand all the time, is that Uber is nice because
you as a driver, except that I'm carrying my one
passenger somewhere else. While a school bus is if it's
all configured properly, because the driver can't do any interaction
while they're driving. They can't have a screen up, they
can't have all this other technology that a taxi driver
UBI driver can have. I can't just notify one parent.
I have to notify sixty kids maybe and their families,
and not also share where those fifty nine other kids
also live, right? And how do I do that in
a different way?
Speaker 1: Challenge?
Speaker 2: Yeah, No, it's great, and it's great. Question. It's like
what's the right thing to do there?
Speaker 1: So you have let's count the clients. You have a
web obviously and mobile. Do you also have Windows and
Mac clients.
Speaker 4: We don't have Windows because actually all of the development team,
including myself, we only run max. I do have it
running on a Mac locally, though, because that's how I
do development is mostly in the Mac.
Speaker 1: Right okay, because you're using the Mali hybrid model.
Speaker 4: Right, correct, there's nothing stopping us.
Speaker 1: It's more uh, nothing stopping you.
Speaker 4: Yeah, it's more because of you know, got to go
through enterprise hoops. I don't want to fight that, yeah, exactly.
Speaker 1: I mean that comes back to Richard Rukima's point is
that we love these mobile things because you can just
pull them up, you get the latest version, you don't
have to install them and ye WPF who needs it?
For this guy?
Speaker 2: Apps that? Yeah? Yeah, that's you don't want to run
WPF on now? That would be gosh.
Speaker 1: Did you also take a look at some of the
other sort of you know, multi client frameworks out there
before you decided on this or was it a natural
progression because you were always using zamor and already.
Speaker 4: Yeah, it was obviously we were leaning this way. We
were using Blazer already, Uh since what was it done
in a core three three one depending on whethery're using
web assembly or not, so we kind of were already
familiar with Blazer. Tyler also has a internal UI library
that we use, and of course it's web components only,
so it's do I want to port that something else
or keep using web We did look at things like
Flutter and Ionic for a little while, but really we're
a dot net shop through and through, even outside of
mobile development, so it kind of just made sense for
us to stick with dot net. And I've never had
any issues with Blazer, which I know people have their
opinions on necessarily using web assembly and all this other stuff,
but it's at least I know what can be wrong,
so it's familiar.
Speaker 2: Yeah, But I mean, MAUI was supposed to be the
logical successor to zamorin forms like you are making a
bigger leap here to jump over to Blazer.
Speaker 4: We are, and we definitely walked through that. So we've
actually had two apps and we did them differently. So
ride through sixty now known my ride K twelve, we
did that whole Blazer rewrite, right, We took things in
and forms through the way it did everything a blazer.
We have another application called my Stuff, which is for
a different application that we support kind of same functionality,
but for a different on prem solution basically uh bus srouting.
That one went from examer Informs to Maui. There was
no blaze or anything we write. That one went through
what Microsoft wants you to do with progressing straight over
to Maui and it because of how that app operated.
It didn't have anything overly complex. It wasn't difficult, but
it definitely was not as easy as it is made
out to be.
Speaker 2: Well, both products had their challenges, right, Yes, Yeah, and
I would argue if you still had a Zamora Informs
app today moving to Maui on done at nine, he's
a heck how a lot less painful? Totally agree. Yeah,
definitely if you jump when they wanted you to jump,
you jumped into a pifle of glass like.
Speaker 4: Correct, correct? Yeah, we only did that migration from Forms
to Maui within the past six months, right, so when
all that stuff got worked out and learning curves and
all that.
Speaker 2: Yeah, if you can wait, wait you it will. Yeah,
it's a benefit without it's like, if your app's not
currently on fire and people aren't going to kill you,
you know, stay with what you got and let the
bugs be worked up by somebody else.
Speaker 4: Yep.
Speaker 1: Well, and also you know, you don't really he's not
really going from Maui to Blazer. He's using Blazer inside
a Maui app, So so it is Maui Blazer essentially.
But I was thinking of something like Avalonia. I mean,
do you look at that?
Speaker 4: Oh yeah, yeah, and that we did look at too,
So I think some confusion has a couple of libraries
that we were looking at, and you know all those
cross platform cross uh you know, whether it's Web or
Maui UI frameworks, and again, what it what it came
down to us was we wanted to stick with the
UI components that here at Tyler Tech someone has built
and they were all web components. So we were kind of, yeah,
do we want to take that and replicate it somewhere
else or do we just want to keep using web components.
Speaker 1: And it totally makes sense, as you said, because you know,
the cross platform part is already done. Yeah, yeah, you're
not worrying about this platform that.
Speaker 2: Plus you've got six hundred thousand users that are used
to a look and feel correct. Don't mess with that.
That's just cost for you. The more you mess with that,
the more trouble you're going to get.
Speaker 4: Yeah, and we want to be good partners at Tyler. Right.
So Tyler does everything public sector right, whether it be
courts injustice or public safety or healthcare to student transportation.
You know, there's bunches of apps that Tyler reproduces, and
we want to make sure that if a parent happens
to also be in a district where I can pay
my electric bill through Tyler Tech, right, that that look
and feels kind of the same.
Speaker 2: Oh interesting, Right, So literally you can have multiple products
in this space and they're like, oh I know this already.
Speaker 4: Yep, Yeah, that's cool.
Speaker 2: That makes sense.
Speaker 1: All right, that sounds like a good place to take
a break. We'll be right back after these very important messages.
Did you know you can lift and shift your dot
net framework apps to virtual machines in the cloud. Use
the elastic beanstalk service to easily migrate to Amazon EC
too with little or no changes. Find out more at
aws dot Amazon dot com slash elastic beanstock and we're back.
It's at Rocks. I'm Carl Franklin, It's Richard Campbell, hey,
and that's Nathan Westfall and we're talking about his application
hosting six hundred and fifty thousand plus users with an
S three bucket and a CDN all in Blazer for
mobile clients and for web and not looking back.
Speaker 4: Not at all, not at all, not at all.
Speaker 1: So no web forms here, no Windows forms, no WPF,
no native client code for iOS or Andrew, you don't have.
Speaker 2: To deal with that.
Speaker 4: Yeah, definitely not UI native code. Right. So, I think
the only things that we got stuck with, and I
say stuck with, they were not major to begin with
at all. But in terms of either you know, browser specific,
iOS Android specific, you got push notifications.
Speaker 1: Yeah that's a problem, right, always.
Speaker 4: Right, push notifications and authentication actually had to have a
nice little hack to get to work in all of
them because we wanted to use what Blazer does for authentication.
But how I log in auto mobile device is not
going to be the same on the web. So how
do I make sure I can still use Access Token Provider?
How do I still use that on MAUI?
Speaker 1: So let's talk about push notifications. Yeah, so I'm not
talking about signal ar can send you a message and say, hey,
how you doing. We're talking about when your app is
minimized and you're getting messages in the background and you
want that number with a red circle with that number
to increment that. That is not trivial to do and
an Android. I figured out how to do it by
doing an actual fore ground service that works as a
background service. Yep, but that adds another service, and on
iOS forget about it, like you have to, you know,
draw three courts of blood and sign over your firstborn
and right, and then they don't even have it for
Blazer as far as I'm concerned. They didn't last time
I checked. So how how on earth did you solve
that problem?
Speaker 4: Yeah? So we this is I guess saying outside of
the ecosystem. I know we talked about being inside of it,
but we use ad your notification hub for push notifications.
Part of the reason was because the older application Examined
Forms already had it because it was Adure first, and
we wanted to just keep the same system in case
parents had both apps. Right, So it was a decision
we made to just just keep it around.
Speaker 1: But how does that notification service interact with your dormant
yes app.
Speaker 4: So we had to write code specific for Android and
iOS to tie into both push notifications. So on Android
it's firebased FCM now right, they officially retired GCM unfortunately,
and then iOS is always messing with delegates and all
this fun stuff that if it doesn't work how as
you said, it doesn't work how the docs work, I'm
kind of out of luck because it's not like I'm
getting an help from Apple Lane time soon. So tie
into both and just kind of have the native push
unification system work. And then if they happen to click
the application, you know, we're doing some things with session
state too, kind of if Blazer then wants to detect
that I have a message safe, then I can prompt
that in a totally different way or manage it totally separate.
Speaker 2: Yeah. Wow, but now you're using notification AUPs like you
now describing a cloud hybrid app too, because you're also
using is three.
Speaker 4: Yes, yeah, a little bit of both on that one.
Speaker 2: Not complicated at all their data Imagine you have any problems? No, no,
but no, I see how you got there. Totally makes sense, right,
and there's nothing bad about notification apps they were.
Speaker 4: Yeah, I've honestly out of alved the Azure services. I've
used them. We used to do Azure probably at this
point seven years ago or so, right from everything that
they have to offer, and I've never had any complaints
iuthentification of it. It's honestly nice how easy it works
from an API perspective. If I have to generate a notification,
how to send it to them, and then how to
managing devices, which I've had to do before in terms
of my you know, P and S token on Apple
and my fire based token on Android and which messages
can you get and can't you get. I've written that
code before to manage it, and I'd rather never do
it again.
Speaker 3: So you also hint did a thing that I've talked
to a bunch of mobile devs about, which is making
sure the Android and iPhone versions are utterly in sync.
Speaker 2: Like if you had a parent's one with an iPhone
more than an Android and the app was much different. Yeah,
like that that, I'm surprised how upset people get. Yeah,
why does iPhone have this and I don't have it
on Android?
Speaker 4: Yeah, And for us, before Blazer was the web was
incredibly honesting like, I can't emphasize how bad you could
see your live busting on web because it was just
it was never built, that never had priority of what
was there. And now what's nice is because we have
all of our shared code and a shared class library.
If I have to add a new button, I'm putting
it in one spot, I'm quickly testing all three devices
and it's out to production right after that. You know,
it's it's quick.
Speaker 2: And what are the three devices? iPhone, Android and browser browser? Okay, yeah, yeah?
Do you do you much phone specific testing? Like do
you care which iPhone or which Android device?
Speaker 4: We more sot Android because of the possibilities almost being endless, right.
Speaker 2: Yes, we recall it the drawer broken dreams for a reason.
Speaker 4: For for iOS, we only care really about the version
of iOS that we support. I don't know if you know,
but iOS had a breaking change between iOS seventeen and
eighteen that impacted Mali Hybrid because of that IP address
zero do zero do zero dot zero bug and they
took that away, but Maui was using that to spin
everything up, and you know that encouraged us to do
more testing around that. But yeah, really, just always changes at.
Speaker 2: That point, well, and Apple is so insisted on getting
into the latest version of iOS all the time, which
is I think a little annoying for consumers but pretty
good for devs.
Speaker 1: And it's good. It's good for consumers because security, you know,
and fewer problems. Apple is still the most secure mobile
platform there is because they own it top to bottom,
and it's.
Speaker 2: Part of that. Part of that is enforcing homogeity. It's
always the latest version. Yeah, yeah, and with you and
it's certainly from a dev perspective if you're willing to
jump through iOS hoops because they are iOS hoops, at
least it's one os you more or less have to
care about, correct. Yeah. But I've definitely talked to folks
who they have to have a Pixel device, they have
to have a Samsung device, yeah, you know, and then
it gets questionable after that, like those are those are
the two? And it's at that point you're like at
seventy percent.
Speaker 4: Yeah, and foldables whole other.
Speaker 2: Yeah, you do you do foldable testing? Good? Lord? Really,
I just held up a foldable nice.
Speaker 4: Yeah, only because our product owner has one, so he'll
tell me immediately if something doesn't work.
Speaker 2: Because that's what he's testing on, so he cares about Yeah,
well that's all that changes your media queries completely, right, Yeah,
you have to change the rendering.
Speaker 4: Yeah, and some of it's nice in terms of most
of the mobile devices kind of work immediately on tablets
and larger screens because I'm writing the same code for
web anyway. Right, we kind of have that mindset as
a developer from dam one because all of my code
for IYO with Sandre and the browser are coming from
one spot. I'm already thinking about twenty device screen sizes
as I'm going here, right, so you know, making sure
that works, localization works, all this stuff is now up
in the forefront of a developer instead of kind of sure.
Speaker 2: And they're absolutely iPad fanatics. Yes, if it's not perfect
on the iPad, they lose their minds.
Speaker 4: Yes, yep.
Speaker 2: Yeah. So it's just that that issue continues to exist
and it's not simple, like you really do think about
how you make your UI in the different board screen
constrained correct, much less tested.
Speaker 4: Yeah. No, we even on some of our differences between
like mobile and web. Right, we might write a component
that renders some UI content, but then we have other
logic that's Hey, if you're in a browser over this size,
I'm prompting it in a dialogue, as opposed to if
it's on iOS, it's just a full screen new page
and blazer for it to work. Right, And yeah, yeah,
gets complicated, But.
Speaker 2: It sounds like you have a tooling team because you
guys have multiple products, so it makes sense to have
a tooling team that just worries about Okay, I'm going
to make this new collecting text from the user interface.
Here's how we'll render on an iPhone. Here's how it'll
render on an iPad. Here's how it'll render on on
pixel and so forth, like it's and how render on
web like. You are making different versions and still make
it look close to the same.
Speaker 4: Yeah, yeah, a lot of that's still on us in
terms of how we want it to look. But the
components are nice and effective. They all have accessibility in mind, right,
they all have different screen sizes in mind and all
that stuff, So how we use them. It's kind of
hard to mess up, I'll put it that way, right,
we can, but it is harder to mess up.
Speaker 1: Yeah, And you can test, right, you can test the
mobile device just by shrinking the browser, right, right, and
it's essentially what you do, you test the reactivity of it. Yep, Richard,
do you remember when we used to do shows on
mobile and the Tablet Show and all that stuff. Yeah,
and we would always say, you know, what is the
trade off between making your UI look like the platform UI,
like iOS Android and looking like your branded thing? And
it seems like people were more concerned back then about
making an iOS app look like an iOS app and
making an Android app look like an Android app. No,
I just don't think that's such an issue, do you.
Speaker 2: I don't think I think you're right. I think Jobs
was big on skemorphic design, and he wanted you know,
there was always a threat they wouldn't let it go
through the store if you didn't make it look like
an iPhone app. Yeah, And so there was a time
when that mattered. And then Facebook came along and said nope,
Facebook looks like Facebook. Yeah, and some and then corporate
internal You're like, no, it looks like corporate internal. Yeah.
And I mean, and I do think Tyler falls into
this category. You have a bunch of different apps and
you see an advantage to a common look and feel. Absolutely,
But I'm not going to let you go, Nathan on
the whole accessibility thing. So do you spend some time
on visually impaired or audible player, like how different folks
can use this app?
Speaker 4: Yeah, we do. We Again, what's nice is a lot
of the components kind of have support for that already, right,
all the area labels and what's there the other pieces.
Because we're on a whole bunch of buses across the
US of Canada, we see laws coming out all the
time that kind of require this, right Colorado, if you've
worked with something in that state recently, you kind of
know that they have this initiative right now that on
June of this year, people are starting getting fined if
it's not accessibility out of the box. Right, So we
kind of have that in mind, knowing how public facing
it can be and all that sort of stuff.
Speaker 2: And often public sector expected to be the forefront of that.
Speaker 4: You need to sell it first, yeah, correct, Right, the
law comes from the government, the better the government better
be compliant, right, So.
Speaker 2: Totally yeah, So and yeah, when you think about phones, like,
there's a lot of different ways to do that. You
could you could provide this whole interface as audio only,
correct theory if you think it through properly.
Speaker 4: Yeah, And we've talked about that before. We're we were
going through the app a couple months ago. We're like, yeah,
you know, we can improve a few areas and really
start and dial in some things in. What gets complicated
is the map, Right, how do I open gl screen
kind of explain what's going on? So we've talked about
how we can kind of accomplish that.
Speaker 2: Yeah, I think you would. I mean in the end,
if somebody else was operating that app on behalf of
somebody and describing what was going on, they don't be
that precise. It's like, yeah, the bus is in motion,
it is this far away from the stop is expected
at this time? Correct?
Speaker 4: Yeah, And it's it's kind of how we want to
see how far we can go with. It's kind of
what we're starting to play around with, right, because I
might have a kid in sixth grade and a kid
in tenth grade, and one's going to the middle school,
one's going to the high school. How do I explain
now both buses and the relationship to where I am
and where they're going.
Speaker 2: Yeah, that's actually I think it'd be a really cool project.
That'd be really fun. It's like, how do I do
this well where people are wowed? Yeah? Yeah, I kind
of like the idea of using that interface because the
parent is driving and does want to know where their
kid is and you don't want to take their eyes right, Like,
can I pump this through bluetooth and tell you safely? Yep? Yeah,
the bus is fine, Yep, it's good.
Speaker 4: Yeah. We have some experience in this already because another app,
this one's examined because it's only for Indurid, but we
actually put tablets on school buses, and once the tablet
goes on a school bus, a lot of them, I say,
a fair amount of states have the rule where the
screen just has to be black when the bus is
in motion, So we are almost audio only from this
point on right, how far away am I from my stop?
Where am I taking my directions? So we basically a
lot of our testing is done with just the screen
off and how well can you understand what's going on
with it being completely blocked out?
Speaker 1: That's really cool?
Speaker 2: Yeah, and have some great user acceptions testing to just
watch what does a driver need in motion from my app?
What will make them the most benefit?
Speaker 1: Did you actually go around with drivers, not you personally,
but somebody in the company go around with drivers and
get their feedback.
Speaker 4: I actually did, and there's some people in the DEB
team that did so. I before I was a manager.
I was actually one of the lead devs on that project,
and I went across the US riding buses with you know,
all sorts of kids on different districts, and you know,
got to see it firsthand and how it can both impact.
But how my mind is, I don't know. I think
did the right thing putting a developer on a bus,
because now all of a sudden, I think of twenty
more problems I have to fix, seeing like what can happen.
Speaker 2: Right, I've always been a big fan of this putting
putting the developer into the position of the user. Yeah,
because they do come away with exactly that. Oh I've
seen how they actually use this, and we've been thinking
about this entirely wrong.
Speaker 4: Yep, yep.
Speaker 2: It's powerful and it also connects up like we can
get really abstracted from our software. Yes, like when you
see it in the field helping people, it's pretty powerful.
Speaker 4: Yeah. No, it's great to see the kind of the
impact you can make, right, I mean I did not realize.
I you tell people, before I worked at Tyler, I
did not think this much about school buses. I started
working at Tyler when I was when I was twenty,
so I was only in a school bus two years
before this, and I still did not think of a
school bus as much as I do.
Speaker 2: That you were more school bus savvy than most. Yeah, right,
that's really funny. That's cool. Yeah, it's one of those truths.
Like the great thing is when we do this kind
of tech, right, it's it's almost invisible. Yeah. Yeah, you
know the fact that they know you have to sort
of have a moment ago. Wow, I whipped out my
phone and it told me where my kid was. Yes,
you know, it's seconds, including dealing with all you know,
it's a it's a heavy snow day, but no, the
bus is in motion and fine, yep, that's what you
wanted to know, right, And that's really thinking about all
the pieces that had to work together to make to
give you a good answer. It just was impossible that going.
Speaker 1: Back to the notifications thing, if what kind of notifications
do you have? Obviously, like if the bus breaks down,
side of the road, accident, whatever.
Speaker 4: Yeah, so we support a whole bunch. So there's a
couple of them are actually integrated directly with the tablet, which,
again talking about saving computing resources, it's the tablet on
the bus with the district's local map and where the
bus currently is, where they're going next. Is the one
doing all those ETA calculations. Right, here's the ten parents.
I need to notify that I'm about to be at
their stop, because I, as a driver, said it's my
next one, and I got three more turns to make.
So that's awesome, right, the tablets doing all the work
for the mobile device.
Speaker 2: Yeah, the nice little localized service there, it's the best
position to know. The workload's not more than a tablet
can handle.
Speaker 1: It's well, I imagineflove bus breaks down. There's could be a
there could be a marriad of reasons that you won't know.
So the driver can type into the tablet. I'm sure
ran out of gas in a tree, dog, you know,
hit a deer or whatever.
Speaker 2: Yeah.
Speaker 4: Yeah, now they can let dispatch. No dispatch can let
x number of parents know whether they based off the
bus or even you know, we track how far along
the buses and the route, so I only need to
notify parents after said stuff. Right, I've made it halfway
through and now I can tell the other half. We're
working on next, and I'm interested to see how we
can do this with Maui. But we're working on doing
those live activities. Right. So if you've ever done an
uber and you can kind of see live update, it's
not quite a push notification, right, it's one of those
live tracker ones. We're trying to play around with that
to see how far we can take it. Where if
you don't even have to open the app and now
you're fully functioning off push notifications, that's kind of awesome, right,
I kind of have less resources on my side and
you're getting this up to date information without even opening
the app.
Speaker 2: Right.
Speaker 1: You takes coordinates and stream them to a service somewhere
and pick them up on the client, yeah.
Speaker 2: Yep, just to be able to say, tell me when
they're ten minutes out, yep, I can get there on time.
That's clever. And again that would actually save resources and
not leading on the app all the time. You're wasting
anybody's time that way.
Speaker 4: Correct. If I can get everything from that live activity,
it's all technically feeding from that tablet device and then
they never open the app. I mean, I'm like, we're
not checking anything, right, it's all coming directly from the
bus YEP.
Speaker 2: All right, what have we talked about on this app?
What is your testing strategy? Like? What tools are you
using when you when you do a bill?
Speaker 4: Yeah? Good question. So we do fare money unit testing.
Our API is also in dot net, So that's all
unit tested with X unit because all of our UI
could have shared. We're using b unit to test as
much as we can, right, So as much as I
can test in terms of rendering or business logic I
might have on the client side, testing that kind of
like I would an API, right, And then we also
use browser stack to kind of run into end tests
on here, right, So launching a couple of devices, making
sure they can do X number of user functions? Right?
Can I add my student? Can I load the bus?
Can I create a new account? All that sort of
stuff on number of devices and let us know. So
we don't have obviously coverage everywhere. I don't think anyone
ever does anymore. Just development moves so quick it's hard.
But those unit tests, especially the unit knowing that I
can kind of have the same rendering and the same
functionality really quickly. Is good to see.
Speaker 2: Absolutely, it's great. Anything you don't mean the same mistake
again and again make new mistakes correct. It's enough testing
in place to capture the last mistake so it doesn't
happen again.
Speaker 4: Correct. Yeah, we tried to raise many tests upfront, but
we have a policy here where if you get a
bug or something client reported, it has to get fixed
with the unit test. Right, It's always that regression case.
Speaker 2: Yeah, first make a test that fails, then fix it
and the test doesn't fail. Now it's actually fixed exactly.
Speaker 1: Yeah, we love the unit, love the gal Yep, just
good stuff.
Speaker 4: It's a great product. Yeah.
Speaker 2: Well, and also I try I appreciate you not fixating
on test coverage. Is that it is its own kind
of crazy.
Speaker 4: Yeah. If you were trying to shoot fround percent test
coverage and it's kind of you're never going to get
it right. Yeah. So the nice thing that developers can
understand is we give them all the tools and they're
able to do it upfront, because sometimes it is faster.
If I'm building an API service and I don't want
to keep trying to mock all this data from the tablet. Yes,
I'm going to write a unit test because I can
grab something that's usable and keep integrating over it. And
then the simple requirement of just if you're fixing a bug,
you have to write a test to something that people
can kind of swallow.
Speaker 2: And those auld end up being the best tests anyway. Yeah,
they were ones with a bug that made it to
the field and you wrote and the testing for it
is more complicated than you think. You would never write
that test out of your head just considering it. So
you write this better test and then you know, go
through that process and fix it and maybe it never
ever hits it again, but at least you won't have
that problem.
Speaker 4: You do mocking, We do, yes, well, we do mocking
because a lot of this data comes from our main application,
student transportation, right, and I don't want to have that
running for this, so we mock a lot of the
database and kind of just core data.
Speaker 2: Right.
Speaker 4: So the way this app works is a lot of
it's read only anyway, parents not really obviously updating their
location for the bus and all that. So we kind
of can get away with a little more mocking than
you might be able to.
Speaker 1: So you have like bogus services that run and send
mock data that kind of thing.
Speaker 4: Yeah, yeah, bogus services we use. I forget that. I
think it's called test containers. So even some of our
implementations with redtis and how we you know, not kill
our services by having one hundred thousand parents watch buses? Right,
how do we kind of scale that efficiently? We can
kind to do that cool mocking it, Yeah.
Speaker 2: And a lot of it, I think a lot of
Just because you've got a dozen parents want one bus
doesn't meaning you can catch that once. It's also correct,
very granular.
Speaker 1: Yea, sounds like a fantastic, very successful product.
Speaker 4: I appreciate it's It's been a fun one to work on.
I I selfishly like, uh like being involved in this project.
It was a really fun one for me to work
on the team, to work on you know, kind of
even development kind of picking this up from what we
do day on to work on this. Everyone's kind of
enjoyed the dev life cycle more than anything else. Right,
It's kind of easy to get going. We had someone
start a month ago and they were making fixes in
the app a couple of days later. Right, it was
just easy to pick up.
Speaker 2: That's a great metric. How many days to productivity for
a new worker. Yeah, great metric.
Speaker 1: Well, Nathan, what's next for you? What's in your inbox?
Speaker 4: More Blazer? So this has been this has been a
little test for us, and it's been successful enough where
we've got a few more around the corner that we're
working on. And I hope that, you know, dot net
kind of sees the benefit of Blazer as we get
more and more to this space and keeps dumping time
and energy into it, so hopefully I'll keep using as
long as I keep working here.
Speaker 2: So that's great.
Speaker 1: Well, thanks for sharing the story with us, and congratulations.
Speaker 4: Yeah, thanks for having me. It was fun being able
to talk to you guys and kind of share what
we did right here. You talk about Blazer all the
time at dot net rocks, so I wanted to be like, oh,
I got a story for that.
Speaker 1: He'll love you certainly, all right, Thanks again, and we'll
see you next time on dot net rocks. Dot net
Rocks is brought to you by Franklin's Net and produced
by Pop Studios, a full service audio, video and post
production facility located physically in New London, Connecticut, and of
course in the cloud online at pwop dot com.
Speaker 5: Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two.
Speaker 2: Thousand and two.
Speaker 5: And make sure you check out our sponsors. They keep
us in business. Now, go write some code, See you
next time.
Speaker 4: You got jam Vans
Speaker 2: And