November 21, 2024 • 54 mins
Philipp Kief is a German developer who walks through how to manage and capture errors in your Angular application and how to display them to users.
He discusses how he standardized error handlers in his applications and what he does to make sure that they get logged someplace.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
He discusses how he standardized error handlers in his applications and what he does to make sure that they get logged someplace.
Links
Picks
- Charles- Level Up | Devchat.tv
- Charles- PodcastBootcamp.io
- Charles- The Chosen
- Philipp- Web-based editor
- Richard- Material Icon Theme
- Subrat- Start with Why: How Great Leaders Inspire Everyone to Take Action
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hey everybody, and welcome back to another episode of Adventures
in Angular. This week, on our panel we have Richard
c Tole, Howdy Howdy, Subert Nishra. Hello, I'm Charles Maxwood
from devchat dot TV. I'm just going to do a
quick shout out. Got a new thing going podcast bootcamp
dot I go check it out. We have a special
guest this week, and that's Philip. Philip, do you want
to tell us who you are, why you're famous?
Speaker 2 (00:27):
Hey, guys, So I'm Philip and I'm from Stuttgart and jun. Yeah,
I'm I'm so off engineer since three years, since twenty eighteen,
and yeah, I'm really passionated about front and technologies like HTMLCSS, JAVASCRIK,
Angula and yeah, much more things like that. And yeah,
I'm really excited to be in your podcast today.
Speaker 1 (00:50):
Awesome, Well, we're happy to have you. You wrote an
article that we found on the internet. We'll put a
link to it in the show notes, but it talked
about having central error handling an Angular and I love
the subtitles. Learn how to automatically I should I should
pull out my announcer works. Learn how to automatically catch
all errors? You know, web application written in Angular and
(01:11):
process them accordingly. Do you want to just give us
the rundown real quick on kind of the ten thousand
foot view what is generally about, and then we can
dive in and talk about how you've put this together
and what the advantages of disadvantages are.
Speaker 2 (01:25):
Yeah. Sure. So it was when I worked at a
project from my company from where we created a new
Angular application from scratch. And most of the times you
have some aHVP requests to some seconds, and you have
some kind of things which are running into application which
(01:46):
might cause some errors. And then I just was did
some research about how yeah, could be a solution to
handle errors at a central point so that you're not
so that's not necessary to handle each error at a
separate place. And this is when I had the idea
(02:07):
to Yeah, I use Angular intersectors or central components to
display the error mes just in a consistent way for
the user. So, and a big advantage of this is
that when somehow an error occurs in your application, it's
made sure that all errors are catched by this error
(02:28):
handling concept, and so you, as a developer, you do
not need to think about handling each error in the
application so you just write your features and the central
error handling is doing the rest for you. That was
the initial idea of that.
Speaker 3 (02:46):
Or any other like like I got someone defined or something.
Speaker 2 (02:50):
So it's the latter one. So you get all errors
that are thrown in your front end application. And yeah,
and this also includes the HTTP errors.
Speaker 1 (03:01):
Yeah, I want something that says quit screwing up my
app to the user. Right, what do you do?
Speaker 2 (03:08):
Yes? So, sometimes you're not sure when an error could occur.
So maybe you are including a body library and you
do not know the code so good, or you have
something like micro fundans and you have a lot of
lots of small parts that you cannot control all the time.
And then sometimes an error occurs somewhere where you didn't
(03:29):
expected it, and then you, yeah, you're sure that your
global error handler class will catch this error and then
will show a consistent error message dialogue to the user.
Speaker 1 (03:43):
But I just want to clarify real quick. So we're
talking about the user focused experience, not the developer focused experience.
Speaker 2 (03:50):
Yes, so right now, it's mainly the user focused experience.
So if you have an application which is meant to
or to show consistent error messages to the user, and
to make sure that it's one hundred percent of your
error cases, this error message will be shown. Then this
(04:12):
is a good concept to show a consistent error message
as far saddle as a dialogue which will be shown
or an alert something like that.
Speaker 1 (04:21):
Gotcha.
Speaker 4 (04:22):
This is a very actually very interesting topic for me
as well. And I like the way you approach it
in your article. And I guess you know, at this
early stage in the conversation, maybe you can just give
us like a bit side view of how you would
approach this. I'm talking from an application architecture perspective as
(04:43):
well as the file structure. How would you go about
start thinking about this concept and how would you put
it together in your Angler application? Yeah?
Speaker 2 (04:52):
Sure, so in your Angler application you usually have some
structures with modules. You have multiple modules which are containing
multiple components, and the components are responsible for the user interface.
And yeah, for each module, you can define multiple services
(05:12):
and your logic. And next to these modules, to these
feature modules that represent some kind of features of your application,
you have some shared module or one one shared module
and one core module. Usually the shared module is a
module that contains repeatable components or pipes or services something
like that, and your core module is meant to be
(05:36):
there to initialize basic or the main parts of the application.
And as a basic part of your application, I see
the global error handling. So in this core module, which yeah,
as I said, which will be next to your feature modules,
you can initialize for example this h error interceptor or
(05:56):
an error handler class that in the sets all of
your errors in your application. And for example error handsler
class could inject an error handless service and the service
could handle the whole interaction with what your application will
be is doing with the aerosol just joining some aero
(06:20):
dialogue or logging into the console or sending back some
logs to the server and something like this.
Speaker 4 (06:27):
Yeah, I think, yeah, you mentioned something pretty interesting. I
mean when you mentioned initialization, immediately had taken aback and
I'm thinking about the different life cycle hooks for Angular.
So when you talk about initialization, what would be the
best place or best time to do that in the
life cycle hooks. Is that we're talking about the engine
(06:48):
on in it for the app component, or we're talking
about the initializer, so just before the app actually boots.
Speaker 2 (06:55):
Up, Yes, I think so, basically you have to check
that this core module will be included into the app module.
So the app module is your root module of the
whole application, and the core module will be imported into
the app module. And to make sure that the life
cycle is also included or respected with this error handling,
(07:18):
I also showed in my article that you have to
make sure that you are waiting for the zone to
be defined or to be initialized, and then for some
of the error message will be shown in a dialogue
if its obcuous, and for some during the one idiot
methods or after you in it life cycle books, it's
(07:40):
also necessary to show the error messages properly.
Speaker 4 (07:44):
Yeah, because I'm thinking of more of a scenario where
you know, like you want to do some initialization logic way,
depending on exactly what you're doing and your use case,
you might want to do it in an initializer, which
is what happened, which is gets triggered shortly before the
gets footstrapped. So I'm just wondering what if an error
(08:06):
ocared within that during that phase. What do you think
the way that you structured it or the way you've
explained it in your article, do you think that would
be handled in that scenario as well?
Speaker 2 (08:18):
I'm not sure, so I think it is handled right
now like this. It wasn't initially even my idea, but
I wrote the article I think a year ago, and
some weeks or months later some a guy created a
purrikfest at my example repository and told me that it
will be necessary to inject the anchi zone into my
(08:41):
global error handler to open an error dialogue with the
within the callback of the anchie zone and the zone
yeah when when it runs, it will probably open the
aero dialogue if also if the application is initializing.
Speaker 4 (08:59):
Mm hmm yeah.
Speaker 3 (09:01):
Usually what I'm what I'm thinking is harding, Richard ask,
maybe I'm just guessing it that normally you will inject
your component and usually you will get errors from your
component accessing a service or or getting the data to
back to the component, and as you're handling the inside
(09:23):
a service and that extending error handled. So I think
it should catch all the at least temporary irrelated error
or the data related.
Speaker 4 (09:31):
Error because they load. They will load after the service
is loaded.
Speaker 1 (09:36):
But do you have a good way to test this.
I'm curious to.
Speaker 2 (09:39):
Test errors when they are flown while initializing.
Speaker 1 (09:43):
The h yeah, or and the solution that you kind
of pulled together with this in general.
Speaker 2 (09:48):
Yeah, so you can in general test the solution as
I showed in my example application. So for example, you
could just frow some errors in your application with the
big flow error or throw a new error syntypes of
typescript or JavaScript, and then you can check if the
(10:08):
error is catched by your global error handler. Or you
could also try to send weak first to the back
end or to some to some mocked back end which
will return some malicious errow code or status code like
four hundred four or something or five hundred and one.
So these typical error codes from the back end, and
(10:31):
you can check if your error handler's working. And yeah,
for these cases, the error handler should should catch the errors.
Speaker 4 (10:40):
Yeah. There was another thing that I also picked up
from the article, which is well written, by the way,
so congrats on that. I should have mentioned that earlier on.
But you mentioned that in Angular Vision ten it was
not possible using instance of operator within the global error
handler to distinguish if it is an HDP ERA or not.
(11:01):
Is this still a limitation in the latest angle division.
Speaker 2 (11:04):
I'm not not quite sure because I haven't tried it
until then. If it's working, but I think, yeah, the
problem is inside of the the error hander class. So yeah,
so the yeah, the instance of operator was was an
issue to check if the error is an HDP error
(11:25):
or not. So yeah, this somehow was was a problem,
which is why I used the error interceptor or this
HDP in acceptor to handle specifically the HDP errors. But
I think, yeah, right now we are also working on
an Angular application where we catch these error errors within
also within the error handler class, and so I think
(11:49):
it's not not necessary anymore that you have to put
this go into the separate HDP in accept door.
Speaker 4 (11:56):
Yeah maybe for listeners, maybe it will be beneficial just
to explain what was the issue with that instance of
and then also how you were able to wake around that.
Speaker 2 (12:07):
So the issue was that the global just just check
me the name. So the global error hinter class handles
all errors which are thrown in your application, and somehow
you need to separate errors which are coming from your
back end and some errors which are thrown by your
(12:27):
front end applications. Like example, if you the user pits
the wrong button at the wrong time with a wrong
input message and the frontend cannot pass it somehow, or
he types in a wrong character and then somehow it
crashed the front end without any back end into without
any back end action. Then you have some local fronend
(12:50):
errors and you want to separate them between the HGP errors.
The other kind of errors is when you send request
to the back end and back end response is four
hundred or five hundred status code for example, and somehow
you want to separate these error messages because from the
(13:11):
back end it can be that the back end will
return some semantic information inside the error messages which comes
back from the back end. So for example, database is
not available from the back end, or the user already exists,
or the username is not valid, something like that. So
for example, for validation use cases and the other error
(13:34):
messages which are only in the front end, they are
sometimes more cryptical. It would also be that it's it's
just a bukos that developers for got something to implement
and the user will find it out. So it's the
worst case, but it's in them sometimes. And yeah, when
you handle these errors, yeah, you just want to show
(13:54):
some default error messages, so like oops, just something went wrong,
just to indicate the user that indicated a bug which
was not initially planned that the user will reach it. Yeah,
and this is this is the Yeah, the reason why
I separated these two types of errors, So one error
(14:16):
coming from the back end and one raising directly at
the fundant. And yeah, your question was why we had
a botblem with this instance of the things that you
have somehow to Yet the the global error handler class
does not directly know what kind of error was thrown,
so it just checks, okay, there's an error, and somehow
(14:38):
you have to check which which error it is. And therefore, yeah,
I checked if you could verify it with this instance
of operator give this error object, this instance of HDP
know the class name. I think HP responds or so.
And yeah, at the time I wrote this article, it's
(15:00):
was probably working to check if it's an HDP error
or if it's a local error. And this is why
I excluded the detection of HDP rs into the HDP
interceptor class.
Speaker 4 (15:13):
Yeah, because there you you're able to observe every pre
flight request, right, so we and response exactly.
Speaker 2 (15:21):
Yeah, incept way you can check the outgoing requests and
the incoming responses from the back end and you can, yeah,
just simply check the status code and the response messages.
If it's an error or not, and then you could
show some proper error messages to the user.
Speaker 4 (15:39):
Yeah, that's right. I'm sorry, guys. It's not like I'm
plugging the questioning. Yeah, it's It's something that I've dealt
with a lot in the past, so I'm very very curious.
Speaker 1 (15:50):
Good questions.
Speaker 4 (15:51):
Yeah, just one as a follow up with regards to
these error messages. I don't know you mentioned a use
case which basically brought about this article. The I'm thinking
about the error messages themselves, right. I know the back
end guys will probably hate me for this, but I
don't know what's up with them. They're all like this.
They always send some cryptic messages to the front Endy
(16:16):
I sent that, you know what I mean exactly. So, like,
I think one of the solutions was to, yeah, to
do some sort of a mapping so that when you
get this scryptive message, you just give it into some
friendly message that you can display in the in the UI.
Speaker 1 (16:35):
And how you're going to transpile the error messages is
that we were saying into something that the user can
understand exactly.
Speaker 2 (16:42):
So sometimes the language of the developers it's not the
same language as Yeah, the front and developers speak or
to users to see it or want to want.
Speaker 1 (16:53):
To see Yeah, well, and that that actually speaks to
the point that I was trying to make initially, right,
was just developed experience or user experience, because we run
into that, right, we work pretty closely with the business team.
And yeah, the stuff we put in the logs, right,
So we go to DevOps and we say we need
this log so we can see what happened. That's the
(17:13):
cryptic type of message that Richard's talking about. But the
message that they get is basically an explanation of Hey,
here's what happened, and here's what you need to tell
us so we can fix it.
Speaker 2 (17:23):
Yeah, and I think it's from from both sides. So
at the one hand, you can show the user of
proper round messages, but on the other hand, you can
also improve your log messages that you will lock to
the develop a console in your browser, or you could
also write an adopted service that sends lot messages back
to the back end. So each time or every time
(17:45):
an errow queus, you could also send some rown messages
back to the back end for Metrix or to lock
them in a log file at the back end and
so yeah, so I think from the user perspective, but
also from the developer's perspective.
Speaker 1 (17:59):
Yeah, absolutely, I'm curious, Richard, what does your message transpiler
look like? I mean, is it just a service that
just has a key in it?
Speaker 4 (18:05):
It was very very primitive, very very primitive, but like
it was, it got to a point where we're like, okay,
if in the front end guys didn't even understand what
the hell these guys are trying to say. So, okay, guys,
we need to find some middle ground so that we
can all speak the same language or at least convey
the same language, same thing to the end users. But
(18:28):
I'll tell you one story about the one friendly error
message that I saw was more not really quite an
error message. But you I'm not sure if you've heard
about this. So during the beginning of the vaccination drive
here and German in other countries, some people in social media,
like Telegram I think particularly, they started developing these bots
(18:52):
that would go into this website where they offer appointments
for vaccination, and the bots will time and again hit
the API and try to as soon as there's an
opening for vaccination, then it will basically allege these and
then they can book it. And I guess it got
to a point where the developers of the sites realized
(19:14):
it's like, okay, we're being hammered. API is just like
going crazy. And then you open the console you would
see they were like, okay, dear, but programmer, please respect
our API limits something. So, yeah, that was just some
frinny story that I just remember. Now, that's that's awesome.
Speaker 1 (19:37):
I love that. Yeah, by the way you were, you
were saying that, Yeah, the messages were stuff that front
end developers or users wouldn't understand. Well, if it's been
two weeks to back end developers don't remember.
Speaker 2 (19:49):
What I mean either.
Speaker 1 (19:51):
We all know this right because we all write code.
It's like it's like, oh, I've been onto these other
three problems for the last two weeks. And what was
that again? Yeah, you don't look in the code where
it raises it to see Oh this stuffs around it.
That's what it means.
Speaker 2 (20:06):
Yeah, he uses some code and then he can see it.
Speaker 1 (20:10):
Oh there we go.
Speaker 3 (20:11):
Yeah, I remember like that, I have I have I
haven't sent some some keys in the in the object
and I got the whole query backs has accept.
Speaker 4 (20:24):
The really gosh, that sounds funny. The Yeah, there was
also another one that actually popped up as you were talking, Charles,
which is with regards to the possible use cases for
you know, centralizing your error handling in your application, like
would you recommend I'm thinking of someone who's just studying
(20:45):
out or building a small application, so not that metrological
or anything like that, like is this, would this been necessary?
Would you recommend that they centralize their handling of errors
or is it mostly beneficial to large applications.
Speaker 2 (20:59):
That's in my it's better for large applications. So where
you have multiple components, multiple modules, and yeah, even multiple
developers or even multiple teams working working on the same
application in the same repository, and they all have to
handle in some errors. And for example, in my current project,
(21:21):
we have yeah, i think three separate teams working on
the same front end, and we are also working from
Germany and also from Poland on the same application. And
somehow you have to make sure that, yeah, your error
handling is consistent and you show the usable consistent messages
(21:42):
then and knots that each component or each module has
its own error handling. And I think that it's the
best to have. It's in large business applications, yeah, way,
where you have multiple developers. So if if you are
working on a very small application which has just one
what youule and not much logic and just one or
(22:05):
two reaf ust to to some pecnd or so, then
it's not necessary because it's some overhead.
Speaker 1 (22:11):
So I'm gonna ask, then at what point do you
start looking at putting it in? Because what I found
is that the it's just a small application, it only
does this one thing. It never stays there, right, it
doesn't park there and go, oh, yeah, I'm just occupying
space here right, Oh we need this other thing. Okay,
we're going to add this other module in. You go,
(22:32):
do you start looking at this at two modules? Three modules?
I mean two teams, three teams? Where's kind of the
sweet spot where? Because and I'll just back up a
little bit, things like testing or accessibility or some of
these other ideas that kind of permeate the entire application.
If you go in and try and do them later
when the application's big, it's really painful. And so I'm
(22:53):
imagining that this is also one of those things that
it's much easier to implement early. But yeah, you don't
want to come in with a power tool if you
can just tap out your problem in a couple of steps.
So yeah, what's the right answer here?
Speaker 2 (23:07):
It's a great question. So yeah, I don't know if
if there's a hard limits for this kind of depends
on on the application loose cases itself. So for what
this application is meant for, and I think it's not
not a big deal to have it also for for
smaller applications if you might think it will be bigger.
(23:29):
So yeah, it's it's it's a good question. So I'm
also yeah, not that experience. So I've now three years
of experience, so I've ye met some applications.
Speaker 4 (23:40):
Yes, but so.
Speaker 2 (23:42):
Do a generic answer for this? I think? So it
depends on the application itself.
Speaker 4 (23:48):
I think it always.
Speaker 1 (23:52):
Oh I was, I was a consultant for six years,
that I get it.
Speaker 3 (23:57):
So one thing I can say that like if you
if you don't want to write a lot of catcher
or in needs typical, this is good.
Speaker 1 (24:05):
Yeah yeah, what so my rule of on implementing any
kind of broad system like this is that you want
to implement it right before you're going to start feeling
the pain for it. And so it sounds like what
from what you said. You know, once you have a
couple of teams in this and you're getting up to
three maybe four modules, you know where you can't just
(24:25):
keep track of it all in your head. You really
ought to start thinking about this, right. And so when
you're starting to lose track of how is the error
handling happening across these modules, and hey, we've got this
other team over here that may be doing something a
little bit different, that's when you're standardize and that's where
I pick this up. But yeah, it is. It's going
to depend because you might have some module that does
(24:46):
like two really simple things and so it almost doesn't
count towards your complexity, right.
Speaker 2 (24:52):
Yeah, and also think like that. And it was great
when we started developing on a mic whole fund and
application with ang Law and we are just so we
had two separate angular applications with their own logic and
everything else. So there were two monoliths, and after half
a year we started to create some micro funds out
(25:16):
of them and to have some shell or some container
logic in a shell application and in the shell application,
so which which caused microfonds. We had this error handling
concepts implement and it was great to just inject some
microfonance into the application and even if a microfond froze
(25:37):
an error, that global error handling catch this error and
showed the global error message and it was it was
a great experience to see that was also working for
the micro fundans in Angular. So I think one of
the use cases if you want to really make sure
that all errors are handled correctly, and then it's you
(25:59):
can use it for a re application unless many how
many modules you have or how many developers are working
on it. So I think it's not not a bad
way to design nearly all of your applications.
Speaker 4 (26:14):
I tend to agree with that. I think, I mean,
I've been working on a small project, and I say
small inverted commas, the very classic example that Chucks just mentioned. Now,
it also started like yeah, we're going to have a
couple of components, a couple of pages, services and so forth.
But over the years it has actually grown a bit. Yeah,
(26:36):
so it's and I'm thinking now when I'm looking back,
I'm like, actually, I could have actually made use of
it back then when I started developing it. But the
nice thing is that you know, it's angular because it's
not that hard to implement it even after the fact,
as long as obviously you're following the correct patterns and
the best practices and implementing the global era handler class
(27:00):
interface in this case, that it will guide you into
doing it in a correct manner.
Speaker 2 (27:05):
And maybe it's also the wrong question to ask when
to use it, so maybe you should ask so when
not to use it. And so I think you should
not use it if your application requires some really individual
error handling. So if the customer asks you to have
some individual error handling, so if the error messages or
(27:26):
error dialogues should be completely different in the modules or
your components, then it's maybe not the best use case
for that, because yeah, you sell a little bit flexibility
for this, and yeah, so you'll lose the flexibility. And
it doesn't matter if the if the error handling should
(27:47):
be consistent in your whole application, but there might be
probably use cases that are different.
Speaker 3 (27:55):
If you're getting always a different error, then I think
we can use that recharts to transfiler and can make
these messages. At a funny side, like I wondered, like
this all we are able to do because angular implemented
all these patterns what we are having, like you can
(28:16):
use like a provide like STTP interceptor and they can
use it in another class. To those all of the
oriented concepts makes it happen. It's some are like if
someone is just starting out, it may look pretty easy, Okay,
I'm just using using a class. But how it helps
later and how it helps maintaining the application for a
(28:39):
big application. Obviously, if you're following all the patents and everything,
the solid principle, I think very few people may have used.
Everybody should use solid in the front end as well,
but at we haven't seen. It's a big topic in
the application in the big framework or big application point
of view. But this kind the patterns are the best practices.
(29:02):
We're going to help us later or at least it
will reduce our code. How mutual type and for error
handling or for token intextion supporhich.
Speaker 4 (29:13):
I guess one of the key questions, very very important
question is and for those that do not know, Philip
is is very prominent in the open source world, and
is this we're talking before we started the recording, but
this one vs code extension called material icon. It's and
I checked out the code the repository and the question
(29:37):
is do you use error handling or do you say
if you centralized the error handling for that project, you
mean for.
Speaker 2 (29:44):
The material I can feel, yes, yes, or the material
I can fee is a completely different use case. I
think it's really stick to the extension a PI, which
is STUDI code, so which is code provides a specific
a PI with some interfaces which you can use to yeah,
to customize the features of rest the code. And in
(30:08):
my case these are yeah, to inject some some icons
into the into a VUS code to need to show
them probably, and yeah, so the error handling basically looks Yeah,
it's a trycatch chain, so there's a there's a top
level try catch that catches globally the error messages from
(30:29):
from the lower parts of the application. So it's yeah,
it's a little bit difference to this concept which was
described in my article here. But yeah, somehow there's also
a global error handling in this extension too.
Speaker 1 (30:43):
Yeah, we should just use global trycatches for everything. I
like that trycatch around the whole app. Yeah, so broke Man.
Speaker 2 (30:52):
Yeah, so I mean the code for the material ICO
theme is kind of only supportive, So just the support
some some features, like to adjust the capacity or saturation
of some icons. It's it's not not the main part
of this extension, you know. It's just to support some
(31:14):
additional features, and some or or most of people might
say they are not even necessarily these features. It's most
mostly about the icons and that the icons are shiny
and look good.
Speaker 4 (31:28):
Yeah, you can attest to that, because as of this morning,
I'm a proud user of the material icon theme. Thank
you very much.
Speaker 2 (31:39):
You're welcome.
Speaker 1 (31:41):
If you went over Richard, I mean, that's nirvana right there.
Speaker 2 (31:45):
You could also try to try to produce some errors
in his extension and then you can see the arrantling.
Speaker 4 (31:52):
I will try to break it. Yeah, accept it.
Speaker 2 (31:59):
Yeah, but there's also then the error handling of your cootua,
which will show you some error messages which will catch
my extension errors. Yeah.
Speaker 4 (32:10):
Yeah, I guess. I mean you're working within this bubble,
this ecosystem that's Visual Circle provides for you the APIs
so yeah, I guess there is some sort of mechanism
that basically builds on top of that. But yeah, for
the sake of the for the topic that we're talking
about in the Angular framework, it's a slightly different concept.
Speaker 1 (32:30):
Yeah, I did have another question, and this is kind
of tangentially related, but it's more like team practice. So
one thing that I run into with the app that
I work on in the full time job is that
we don't always communicate well, hey, we have this thing,
you should use it, right, And so what will happen
is is because there are two teams that work on
(32:50):
our app, and so the other team will go in
and they'll actually, oh, we need to surface and you know,
when an error comes up, we need to surface the error.
And so then what happened is we've already built that.
Then they wind up kind of reinventing the wheel, and
now we have two systems, right, and so you know,
after they've spent three days engineering it, right and we
(33:11):
get the code view for it, we're going, guys, this
was already in there, right. So I guess what I'm
asking is how do you communicate within the organization to
make sure that everybody knows that, hey, we've got a
framework for this.
Speaker 2 (33:25):
That's a good question, though in my opinion, a good
organization or good communication is similarly important as a good
code structure or good architecture though, because it makes the
project successful, and it makes it successfully also for the
customer too, And so I can also only speak for
(33:48):
my company or or the project set that we are
working on, and it's yeah, it's about communication making knowledge
transfer sessions where we look into our code. We are
doing programming most of the time, and so yeah, and
we have to spread the knowledge to our colleagues. And
(34:11):
but I think it's also it's nowhere, it's it's perfect,
so it can happen here that that some also some
some new colleagues might come into the project and yeah,
do not know everything, so no one expects that, Yeah,
someone is knowing everything, So it can happen there that
that are reinventing the wheel.
Speaker 4 (34:32):
But also can help here.
Speaker 2 (34:35):
Yeah, I think good documentation can help. We are also
writing design documents for each feature, so where we specify
how our features and modules are structured and architectured. And
so it's it's a good base to get the knowledge
to everyone. And I think too gets Yeah, I think
(34:59):
I think the the error handling, which is described in
my article the same as how you could show loading spinners, Yeah,
produces a little bit the complexity and it makes it
easier for new developers or if they know, okay, every
request to my back end, it shows a loading spinner.
I do not have to think about it, and I
(35:19):
do not have to unit test it or care about
It's just there and it's handled somewhere globally. And you're
more complexity, you can move away from feature components or
feature modules. The better it is to make it easy
for new developers or your team to not reinvent the wheel.
Speaker 1 (35:40):
Yeah, yeah, you mentioned documentation, which I didn't want anyone
to say because the company I work for, users Confluence,
would Yeah, it makes sense, right, you put that information
in a central place. And then the other problem that
you have to solve is making sure that everybody checks
there before they go and reinvent, because I know that
my team rarely looks at it, and I know that
(36:01):
the other team never looks at it. So that's the
other piece of it, right, So you have to develop
that practice. Hey, here's here's where the info is.
Speaker 2 (36:10):
And I think I think one of the best ways
for that is pair programming. So for me, so I
think if two guys are working on a feature or
implementing something, and there's yeah, one who is not so
experienced and the other one who is more experienced, and
they can can share the knowledge the best. And yeah,
(36:32):
and everyone can enhance the other colleagues. And I think
if I think it's great if you're working together and
not not everyone separated, So I think it's also works
works for my company or for my project. We are
we're also working from home, so everyone is separated. We're
working from different locations, but we're trying to make calls
(36:55):
frequently to sink ours and to share our ideas and
our non and share our issues where we are working
on and so we are try our best to avoid
these issues so that that someone gets lost and doesn't
know how our things work.
Speaker 4 (37:14):
Yeah, that's true, like almost like each and every time
where I've sat down and work with someone so pay
programming with someone with a feature debugging session. You know,
if you were to contrast that to doing it on
your own. In my own experience, it has always been
the solution that we that we come up with well
(37:35):
pro pay programming is far much more solid, more structured,
more well thought out than had you approach it by yourself.
So yeah, I totally agree with that.
Speaker 3 (37:45):
Here, Yeah, so I can see here you have an
extension called Angula Component extractor and.
Speaker 4 (37:54):
To the clip, it looks pretty cool. Can you please
explain if you regard that.
Speaker 2 (38:00):
I think it was some months ago when I scrolled
through my Twitter feed and then I saw a feature
from a web storm and they showed that they yeah,
they showed in a gift animation that they just selected
some HTML template code with their mouths and yeah, I
think it was a right click and said, okay, reflector,
(38:23):
it's another Angular component, and it automatically happened after that,
and it was excited, and I thought, Okay, why isn't
this available for the study code, and would be a
great feature to just if you want to reflector a
large angular component which which was god too big, and
(38:44):
you want to separate it in it into multiple new
components of most likely dumb components, then it would be
great to just select the code and press one or
two buttons and then it will be extracted in a
separated its componentmatically. And this was the yeah, the idea
when I asked a colleague and a friend of mine,
(39:06):
so lecofocal and we implemented this studio code extension together.
And so it also makes it possible in reals code
to select some temperate code and after that runs automatically
your Angular Cli to to generate a component. And yeah,
(39:28):
right now it's it's really yeah, it's it's still in
a preview stage. So we are had some brainstorming about
what kind of features we could support. So you usually
do not have some htma A texts that should be
extracted into another component, but also input or output events.
(39:49):
You have some type information that you want to extract,
You have some maybe types street code that should be
extracted too.
Speaker 4 (39:56):
And so on.
Speaker 2 (39:57):
So we have lots of still lots of ideas, and yeah,
we are we would be happy for for feedback and
if people will will try it out and and say
it's nice and want to yeah, give us the feedback
that we should focus on specific features or where we
(40:18):
should yeah go further and yeah yeah.
Speaker 4 (40:22):
So basically what I'm hearing is you want to learn
how to do magic?
Speaker 1 (40:26):
Yes, yeah, I believe in miracles.
Speaker 2 (40:32):
Also, yeah, we also experienced why we are way were
thinking about it, so some features would be kind of magic,
So to expect lots of code and yeah, you know
the code is somehow really yeah, nested and connected to
the parts of your application and to just separate it
(40:54):
into a separate component. It's a tricky thing.
Speaker 4 (40:59):
Yeah, and I can already imagine a use case or wait,
this could come in pretty handy. So you remember all
that spaghetti code that you wrote, Charles so many years.
Speaker 1 (41:09):
Ago, I mean in a corn I've never done that.
Speaker 4 (41:13):
Yeah, I mean you can just dive into some of
your old project projects and yeah, you can just like
highlight a couple of head lines and have Phillips Magic
extract all that code into some nice little components.
Speaker 1 (41:26):
Nice. Oh that's at least I'll do that on my
coworkers stuff.
Speaker 4 (41:31):
Yeah, it's pretty cool.
Speaker 2 (41:33):
So right now it's working for basic components. It's working
for components to have some some some variables, and we
can generate an input y. Yeah, I think that's working
right now. You can add an input elements, so the
input is automatically added to the the child component, which
(41:55):
is then generated and the parent components. Yeah, so where
you selected your code is using this input to inject
the variable into the childe component.
Speaker 4 (42:06):
That's pretty cool. So the new component will be created
in the same same directory.
Speaker 1 (42:10):
Or.
Speaker 2 (42:12):
It's generated in the same directory, but it has I
think it I think it has separate it has its
own directory name, so it's it's the same command which
would be executed, which is executed by the Anglo sal I.
So if you would run in the current directory your
anglocal I to generate a new component, that's the same
(42:34):
with what happens under the hood.
Speaker 4 (42:36):
Are you using schematics under the hood for generating the files.
Speaker 2 (42:41):
Yes, we are using anglosil I to generate the files.
So it's just a running a note note command to
call the Anglo cel i on on the autunnel, and
then it's it's you inject requires parameters to the cel
I command and then it generates the component with the CELI.
(43:03):
So the extension expects that the Angler CELI is installed
in your project or otherwise it fallbacks to the MPX
and run CLI from via MPX.
Speaker 4 (43:16):
Yeah, okay, makes sense, so pretty cool. I will definitely
see it out.
Speaker 2 (43:21):
Yeah, yeah, you can try out, and we're happy for feedback.
And you know, you can also always great issues and
can also take a look into our code you find
find bugs or spagetti.
Speaker 1 (43:35):
Yeah, that's only chance. It's okay, that's right, I always
create issues. I mean, I will let you know if
there's a problem.
Speaker 2 (43:43):
Yeah, sure, so I think it's also always great if
people are contributing to open source report stories. I can
see that pretty much for my can extension. So it's
kind of popular, and lots of people are having great
ideas and great suggestions for new icons. You cannot even
(44:04):
imagine what kind of programming languages require an icon for
this extension, and it's great. Yeah, so I got to
know so many programming languages. Fruit is icon. I haven't
even heard before about these languages. So there's just a
programming language which is called Coconut. It's great. So I
(44:30):
love it, and people are really to it and having
these ideas and say, hey, you need that. And sometimes
also people people are creating rekfasts with cool icons, not
even icons, sometimes also code and language translations. And the
project is you have gone only so popular because of
(44:51):
lots of contributions and lots of ideas from the people.
Speaker 4 (44:55):
And Philip is actually being very modest when you say
it's popular, he's he means eight point seven six million
downloads on Vesco, so it is huge. It is a
huge success and and I love it. I've tried it
this morning, and I think it's pretty cool. It seems
(45:17):
very basic and simple, but it works and it's pretty Yeah,
thank you awesome.
Speaker 1 (45:21):
All right, well I'm gonna push us more toward picks
here just because I have a call coming up. But
before we do that, Philip, if people want to follow
you on Twitter, GitHub are usually the ones that people
push to. LinkedIn seems to be picking up steam. But yeah,
if people want to find you on any of those
where they find you.
Speaker 2 (45:38):
And so for me, it's Twitter and getthub, so you can.
So on Twitter you can follow me. I regularly post
some some new new projects or updates on my projects,
and we tweet some of some cool other ideas from
other guys from Twitter. So it's it's it's a great
place to follow my intro as regarding programming. And you
(46:02):
can also follow me on on git up, which is
not a social network, but yeah you can. You can
follow me and check on which project I'm currently working.
And by the way, that there's a cool side story.
So during my studies, some friends wanted to contact me
via WhatsApp and it did reach me because my my
(46:23):
my smartphone was was somewhere on the table on mute
and then they wrote a commit on gitup where they
wrote a Philip, can you please please unswer us on WhatsApp?
And then actually I read this message on this commit
message earlier than on my WhatsApp, so it was kind of.
Speaker 4 (46:41):
Yeah, wow, that is so cool.
Speaker 1 (46:45):
Yeah, that's that's awesome.
Speaker 2 (46:48):
So if you want to really contact me, just just
a bicast and and write some commit messages and then
then I have your attention.
Speaker 4 (46:57):
They pick up your damn phone. That's pretty cool, but
that's what.
Speaker 1 (47:06):
Yeah, Yeah, the damn phone is what what you have
after you've had your smartphone for a while of it
absolutely damn phone. Awesome. Let's go ahead and do some pics, Richard,
Do you have some picks for us?
Speaker 4 (47:20):
Actually I had forgotten about this section of a segment
of the podcast, to be honest. Let me think.
Speaker 2 (47:27):
You know what.
Speaker 4 (47:28):
What is still very fresh and brings a pig smile
on my face right now is the material Icon by
Philip Keith. You might have heard it with this guy.
So yeah, I'm gonna pick that up as one of Yeah,
one of the picks. That something that is still piccutating
in my mind right now, so I'll definitely pick that.
Speaker 1 (47:48):
Awesome, super what are your picks?
Speaker 3 (47:50):
That's so big for this week will be a book again.
So it's a start with why so everyone, Yeah, so
have edady. It will give some meaning at least.
Speaker 1 (48:04):
Yep. Terrific book, especially if you're in any kind of
leadership you're trying to influence your organization things like that, right,
so if you're trying to influence them to write an
error handler in your app. Anyway, it's a terrific book.
I like his stuff. Anything else, I kind of cut
you off there, Yeah, no, no, I think this is done. Okay,
(48:26):
so I'm going to throw out a few picks. I
just want to remind everybody go to dev chat on
TV slash level up if you want to be on
one of the Q and A calls. It's ten minutes
of training and then we just answer questions so we
run out of the time. The other one that I'm
gonna throw out there I mentioned the start of the
show is podcast boot camp. It's four weeks we'll get
your podcast launched. Make you sound terrific, and yeah, all
the details aret podcast boot camp dot io. And then
(48:48):
a few things that are not my stuff that I'm
gonna throw out. Our first, my wife and I started
watching this show, and it's it's free on the online,
so you can just just go look it up and
you can find it. It's called The Chosen and it
is basically a it's kind of a depiction of the
life of Jesus Christ. But it's so most of those
(49:11):
they just kind of showed the Bible stories, right, it's
just like this and then this and this. But what
these folks have done is they've kind of created this
ongoing narrative, and so they created backstories for some of
the apostles and some of the other people that you
read about in the Bible, some of the people for
whom Jesus perform miracles, and then you kind of get
(49:32):
this more fleshed out story and so it's it's really
been interesting. So obviously some of it is fictional, right,
but anyway, it's been a really, really enjoyable way to
kind of connect with the things that we believe here.
So I'm going to pick that because it's just been terrific.
And then completely unrelated, we signed up for a service
at the same time that we signed that we started
(49:53):
watching this, and the service that we signed up for
actually owns the production company that made The Chosen and
we found that out later. But the service is called
did Angel, and effectively what they do is you can
watch shows on Netflix, Amazon Prime, a couple of the
other streaming services. I think Kulu is on there. And
(50:13):
what it does is you can tell it to filter
out certain content, right, So if you want to watch
a show with your kids and you don't want them
to see certain kinds of content, can tell it no
sex or no none of these words or things like that, right,
and it has filters for that. Now somebody has to
go through and actually say the filters apply to these
(50:35):
time codes. Right. So it doesn't have everything on all
those platforms, but it has most of the popular stuff.
And it's been pretty nice because there have been some
shows that I want to watch that I know have
parts that I don't want to watch, like me personally
as an adult, right, and so I just say, hey,
you know what, I don't need to see nudity, I
don't need to hear the F bomb, right, and it
just cleans it up. And it's been really, really nice.
(50:57):
So I'm going to pick that as well, Philip, what
are you pick?
Speaker 2 (51:00):
I think my pig is actually get up code spaces,
So I think it was published the last week or
within the last two weeks. And get up code Spaces
is weist code for web with which you can open
ye git up repositories simply by simply by pressing the
(51:21):
dot button of your keyboard and then you can start
editing code of some repositories. And yeah, navigating through repositories
on guitub with the wes code Web edition. And I
think it's it's really great. Unfortunately, the I can think
is not the capital right now of this, but there
(51:43):
will be an update. I think maybe this evening on
lately tomorrow, so yeah, I will will start to publish
a new version on Edge so that it's also available
for get up code Spaces. And I think that's one
of one of the great things that secured within the
last one or two weeks for me.
Speaker 4 (52:04):
Oh yes, I need to chime in there because I
actually retweeted that tweet from your feed and I tried
it out.
Speaker 1 (52:13):
It is so cool.
Speaker 4 (52:14):
If you thought that was what I mentioned it on
was magic, this is like mind blowing. It's just insane,
very very cool feature from from get up. I think
it's I think it's pretty it's gonna take off it's
gonna pick up very well, I think, yeah, very cool.
It'd be nice to see material icon't theme there as well,
So yeah, it will come up listening.
Speaker 1 (52:38):
Awesome. I just found out too that, and I'd heard
rumors of this, but The Chosen has actually filmed about
forty five minutes from here, Utah. I don't know why
they well, I do know why they picked that location,
and it's kind of an interesting story. I'm just gonna
throw it in real quick because it's fun. But so
the Church, the Church of Jesus Christ, the Latter day
Saints LBS Church, Mormons big presence here. I remember the
(53:00):
but they did a bunch of Bible videos a few
years ago, and they basically built a whole bunch of
like replica sets of Jerusalem scenes and stuff. And they
allow other organizations to come in and film the same
kind of content. Right, if you need kind of that
ancient looking, you know, old time Jerusalem kind kind of
(53:21):
look to your film, you can come film there. So anyway,
apparently they let them come film The Chosen there as well.
Speaker 4 (53:28):
Interesting.
Speaker 1 (53:29):
Yeah, love this stuff. It's fun. It's always fun to
find it like semi personal connection to some and so yeah, Anyway, well,
thanks for coming Philip. This was a lot of fun
and hopefully we inspired some folks to, yeah, kind of
consolidate and simplify some of this stuff, because yeah, if
you're doing a piecemeal, it's kind of a pain in
the neck. But if you can get it all together
in one place, then it's, oh, I'm just going to
(53:51):
lock into these components in these services and I'm done.
Speaker 2 (53:54):
Yeah. Absolutely so. Also, thanks for having me and I
had some great questions and was great to be part
of your podcast.
Speaker 1 (54:01):
Yeah. Well, we're going to wrap up here until next time, Maxim, Bye,
bye bye.
Hey everybody, and welcome back to another episode of Adventures
in Angular. This week, on our panel we have Richard
c Tole, Howdy Howdy, Subert Nishra. Hello, I'm Charles Maxwood
from devchat dot TV. I'm just going to do a
quick shout out. Got a new thing going podcast bootcamp
dot I go check it out. We have a special
guest this week, and that's Philip. Philip, do you want
to tell us who you are, why you're famous?
Speaker 2 (00:27):
Hey, guys, So I'm Philip and I'm from Stuttgart and jun. Yeah,
I'm I'm so off engineer since three years, since twenty eighteen,
and yeah, I'm really passionated about front and technologies like HTMLCSS, JAVASCRIK,
Angula and yeah, much more things like that. And yeah,
I'm really excited to be in your podcast today.
Speaker 1 (00:50):
Awesome, Well, we're happy to have you. You wrote an
article that we found on the internet. We'll put a
link to it in the show notes, but it talked
about having central error handling an Angular and I love
the subtitles. Learn how to automatically I should I should
pull out my announcer works. Learn how to automatically catch
all errors? You know, web application written in Angular and
(01:11):
process them accordingly. Do you want to just give us
the rundown real quick on kind of the ten thousand
foot view what is generally about, and then we can
dive in and talk about how you've put this together
and what the advantages of disadvantages are.
Speaker 2 (01:25):
Yeah. Sure. So it was when I worked at a
project from my company from where we created a new
Angular application from scratch. And most of the times you
have some aHVP requests to some seconds, and you have
some kind of things which are running into application which
(01:46):
might cause some errors. And then I just was did
some research about how yeah, could be a solution to
handle errors at a central point so that you're not
so that's not necessary to handle each error at a
separate place. And this is when I had the idea
(02:07):
to Yeah, I use Angular intersectors or central components to
display the error mes just in a consistent way for
the user. So, and a big advantage of this is
that when somehow an error occurs in your application, it's
made sure that all errors are catched by this error
(02:28):
handling concept, and so you, as a developer, you do
not need to think about handling each error in the
application so you just write your features and the central
error handling is doing the rest for you. That was
the initial idea of that.
Speaker 3 (02:46):
Or any other like like I got someone defined or something.
Speaker 2 (02:50):
So it's the latter one. So you get all errors
that are thrown in your front end application. And yeah,
and this also includes the HTTP errors.
Speaker 1 (03:01):
Yeah, I want something that says quit screwing up my
app to the user. Right, what do you do?
Speaker 2 (03:08):
Yes? So, sometimes you're not sure when an error could occur.
So maybe you are including a body library and you
do not know the code so good, or you have
something like micro fundans and you have a lot of
lots of small parts that you cannot control all the time.
And then sometimes an error occurs somewhere where you didn't
(03:29):
expected it, and then you, yeah, you're sure that your
global error handler class will catch this error and then
will show a consistent error message dialogue to the user.
Speaker 1 (03:43):
But I just want to clarify real quick. So we're
talking about the user focused experience, not the developer focused experience.
Speaker 2 (03:50):
Yes, so right now, it's mainly the user focused experience.
So if you have an application which is meant to
or to show consistent error messages to the user, and
to make sure that it's one hundred percent of your
error cases, this error message will be shown. Then this
(04:12):
is a good concept to show a consistent error message
as far saddle as a dialogue which will be shown
or an alert something like that.
Speaker 1 (04:21):
Gotcha.
Speaker 4 (04:22):
This is a very actually very interesting topic for me
as well. And I like the way you approach it
in your article. And I guess you know, at this
early stage in the conversation, maybe you can just give
us like a bit side view of how you would
approach this. I'm talking from an application architecture perspective as
(04:43):
well as the file structure. How would you go about
start thinking about this concept and how would you put
it together in your Angler application? Yeah?
Speaker 2 (04:52):
Sure, so in your Angler application you usually have some
structures with modules. You have multiple modules which are containing
multiple components, and the components are responsible for the user interface.
And yeah, for each module, you can define multiple services
(05:12):
and your logic. And next to these modules, to these
feature modules that represent some kind of features of your application,
you have some shared module or one one shared module
and one core module. Usually the shared module is a
module that contains repeatable components or pipes or services something
like that, and your core module is meant to be
(05:36):
there to initialize basic or the main parts of the application.
And as a basic part of your application, I see
the global error handling. So in this core module, which yeah,
as I said, which will be next to your feature modules,
you can initialize for example this h error interceptor or
(05:56):
an error handler class that in the sets all of
your errors in your application. And for example error handsler
class could inject an error handless service and the service
could handle the whole interaction with what your application will
be is doing with the aerosol just joining some aero
(06:20):
dialogue or logging into the console or sending back some
logs to the server and something like this.
Speaker 4 (06:27):
Yeah, I think, yeah, you mentioned something pretty interesting. I
mean when you mentioned initialization, immediately had taken aback and
I'm thinking about the different life cycle hooks for Angular.
So when you talk about initialization, what would be the
best place or best time to do that in the
life cycle hooks. Is that we're talking about the engine
(06:48):
on in it for the app component, or we're talking
about the initializer, so just before the app actually boots.
Speaker 2 (06:55):
Up, Yes, I think so, basically you have to check
that this core module will be included into the app module.
So the app module is your root module of the
whole application, and the core module will be imported into
the app module. And to make sure that the life
cycle is also included or respected with this error handling,
(07:18):
I also showed in my article that you have to
make sure that you are waiting for the zone to
be defined or to be initialized, and then for some
of the error message will be shown in a dialogue
if its obcuous, and for some during the one idiot
methods or after you in it life cycle books, it's
(07:40):
also necessary to show the error messages properly.
Speaker 4 (07:44):
Yeah, because I'm thinking of more of a scenario where
you know, like you want to do some initialization logic way,
depending on exactly what you're doing and your use case,
you might want to do it in an initializer, which
is what happened, which is gets triggered shortly before the
gets footstrapped. So I'm just wondering what if an error
(08:06):
ocared within that during that phase. What do you think
the way that you structured it or the way you've
explained it in your article, do you think that would
be handled in that scenario as well?
Speaker 2 (08:18):
I'm not sure, so I think it is handled right
now like this. It wasn't initially even my idea, but
I wrote the article I think a year ago, and
some weeks or months later some a guy created a
purrikfest at my example repository and told me that it
will be necessary to inject the anchi zone into my
(08:41):
global error handler to open an error dialogue with the
within the callback of the anchie zone and the zone
yeah when when it runs, it will probably open the
aero dialogue if also if the application is initializing.
Speaker 4 (08:59):
Mm hmm yeah.
Speaker 3 (09:01):
Usually what I'm what I'm thinking is harding, Richard ask,
maybe I'm just guessing it that normally you will inject
your component and usually you will get errors from your
component accessing a service or or getting the data to
back to the component, and as you're handling the inside
(09:23):
a service and that extending error handled. So I think
it should catch all the at least temporary irrelated error
or the data related.
Speaker 4 (09:31):
Error because they load. They will load after the service
is loaded.
Speaker 1 (09:36):
But do you have a good way to test this.
I'm curious to.
Speaker 2 (09:39):
Test errors when they are flown while initializing.
Speaker 1 (09:43):
The h yeah, or and the solution that you kind
of pulled together with this in general.
Speaker 2 (09:48):
Yeah, so you can in general test the solution as
I showed in my example application. So for example, you
could just frow some errors in your application with the
big flow error or throw a new error syntypes of
typescript or JavaScript, and then you can check if the
(10:08):
error is catched by your global error handler. Or you
could also try to send weak first to the back
end or to some to some mocked back end which
will return some malicious errow code or status code like
four hundred four or something or five hundred and one.
So these typical error codes from the back end, and
(10:31):
you can check if your error handler's working. And yeah,
for these cases, the error handler should should catch the errors.
Speaker 4 (10:40):
Yeah. There was another thing that I also picked up
from the article, which is well written, by the way,
so congrats on that. I should have mentioned that earlier on.
But you mentioned that in Angular Vision ten it was
not possible using instance of operator within the global error
handler to distinguish if it is an HDP ERA or not.
(11:01):
Is this still a limitation in the latest angle division.
Speaker 2 (11:04):
I'm not not quite sure because I haven't tried it
until then. If it's working, but I think, yeah, the
problem is inside of the the error hander class. So yeah,
so the yeah, the instance of operator was was an
issue to check if the error is an HDP error
(11:25):
or not. So yeah, this somehow was was a problem,
which is why I used the error interceptor or this
HDP in acceptor to handle specifically the HDP errors. But
I think, yeah, right now we are also working on
an Angular application where we catch these error errors within
also within the error handler class, and so I think
(11:49):
it's not not necessary anymore that you have to put
this go into the separate HDP in accept door.
Speaker 4 (11:56):
Yeah maybe for listeners, maybe it will be beneficial just
to explain what was the issue with that instance of
and then also how you were able to wake around that.
Speaker 2 (12:07):
So the issue was that the global just just check
me the name. So the global error hinter class handles
all errors which are thrown in your application, and somehow
you need to separate errors which are coming from your
back end and some errors which are thrown by your
(12:27):
front end applications. Like example, if you the user pits
the wrong button at the wrong time with a wrong
input message and the frontend cannot pass it somehow, or
he types in a wrong character and then somehow it
crashed the front end without any back end into without
any back end action. Then you have some local fronend
(12:50):
errors and you want to separate them between the HGP errors.
The other kind of errors is when you send request
to the back end and back end response is four
hundred or five hundred status code for example, and somehow
you want to separate these error messages because from the
(13:11):
back end it can be that the back end will
return some semantic information inside the error messages which comes
back from the back end. So for example, database is
not available from the back end, or the user already exists,
or the username is not valid, something like that. So
for example, for validation use cases and the other error
(13:34):
messages which are only in the front end, they are
sometimes more cryptical. It would also be that it's it's
just a bukos that developers for got something to implement
and the user will find it out. So it's the
worst case, but it's in them sometimes. And yeah, when
you handle these errors, yeah, you just want to show
(13:54):
some default error messages, so like oops, just something went wrong,
just to indicate the user that indicated a bug which
was not initially planned that the user will reach it. Yeah,
and this is this is the Yeah, the reason why
I separated these two types of errors, So one error
(14:16):
coming from the back end and one raising directly at
the fundant. And yeah, your question was why we had
a botblem with this instance of the things that you
have somehow to Yet the the global error handler class
does not directly know what kind of error was thrown,
so it just checks, okay, there's an error, and somehow
(14:38):
you have to check which which error it is. And therefore, yeah,
I checked if you could verify it with this instance
of operator give this error object, this instance of HDP
know the class name. I think HP responds or so.
And yeah, at the time I wrote this article, it's
(15:00):
was probably working to check if it's an HDP error
or if it's a local error. And this is why
I excluded the detection of HDP rs into the HDP
interceptor class.
Speaker 4 (15:13):
Yeah, because there you you're able to observe every pre
flight request, right, so we and response exactly.
Speaker 2 (15:21):
Yeah, incept way you can check the outgoing requests and
the incoming responses from the back end and you can, yeah,
just simply check the status code and the response messages.
If it's an error or not, and then you could
show some proper error messages to the user.
Speaker 4 (15:39):
Yeah, that's right. I'm sorry, guys. It's not like I'm
plugging the questioning. Yeah, it's It's something that I've dealt
with a lot in the past, so I'm very very curious.
Speaker 1 (15:50):
Good questions.
Speaker 4 (15:51):
Yeah, just one as a follow up with regards to
these error messages. I don't know you mentioned a use
case which basically brought about this article. The I'm thinking
about the error messages themselves, right. I know the back
end guys will probably hate me for this, but I
don't know what's up with them. They're all like this.
They always send some cryptic messages to the front Endy
(16:16):
I sent that, you know what I mean exactly. So, like,
I think one of the solutions was to, yeah, to
do some sort of a mapping so that when you
get this scryptive message, you just give it into some
friendly message that you can display in the in the UI.
Speaker 1 (16:35):
And how you're going to transpile the error messages is
that we were saying into something that the user can
understand exactly.
Speaker 2 (16:42):
So sometimes the language of the developers it's not the
same language as Yeah, the front and developers speak or
to users to see it or want to want.
Speaker 1 (16:53):
To see Yeah, well, and that that actually speaks to
the point that I was trying to make initially, right,
was just developed experience or user experience, because we run
into that, right, we work pretty closely with the business team.
And yeah, the stuff we put in the logs, right,
So we go to DevOps and we say we need
this log so we can see what happened. That's the
(17:13):
cryptic type of message that Richard's talking about. But the
message that they get is basically an explanation of Hey,
here's what happened, and here's what you need to tell
us so we can fix it.
Speaker 2 (17:23):
Yeah, and I think it's from from both sides. So
at the one hand, you can show the user of
proper round messages, but on the other hand, you can
also improve your log messages that you will lock to
the develop a console in your browser, or you could
also write an adopted service that sends lot messages back
to the back end. So each time or every time
(17:45):
an errow queus, you could also send some rown messages
back to the back end for Metrix or to lock
them in a log file at the back end and
so yeah, so I think from the user perspective, but
also from the developer's perspective.
Speaker 1 (17:59):
Yeah, absolutely, I'm curious, Richard, what does your message transpiler
look like? I mean, is it just a service that
just has a key in it?
Speaker 4 (18:05):
It was very very primitive, very very primitive, but like
it was, it got to a point where we're like, okay,
if in the front end guys didn't even understand what
the hell these guys are trying to say. So, okay, guys,
we need to find some middle ground so that we
can all speak the same language or at least convey
the same language, same thing to the end users. But
(18:28):
I'll tell you one story about the one friendly error
message that I saw was more not really quite an
error message. But you I'm not sure if you've heard
about this. So during the beginning of the vaccination drive
here and German in other countries, some people in social media,
like Telegram I think particularly, they started developing these bots
(18:52):
that would go into this website where they offer appointments
for vaccination, and the bots will time and again hit
the API and try to as soon as there's an
opening for vaccination, then it will basically allege these and
then they can book it. And I guess it got
to a point where the developers of the sites realized
(19:14):
it's like, okay, we're being hammered. API is just like
going crazy. And then you open the console you would
see they were like, okay, dear, but programmer, please respect
our API limits something. So, yeah, that was just some
frinny story that I just remember. Now, that's that's awesome.
Speaker 1 (19:37):
I love that. Yeah, by the way you were, you
were saying that, Yeah, the messages were stuff that front
end developers or users wouldn't understand. Well, if it's been
two weeks to back end developers don't remember.
Speaker 2 (19:49):
What I mean either.
Speaker 1 (19:51):
We all know this right because we all write code.
It's like it's like, oh, I've been onto these other
three problems for the last two weeks. And what was
that again? Yeah, you don't look in the code where
it raises it to see Oh this stuffs around it.
That's what it means.
Speaker 2 (20:06):
Yeah, he uses some code and then he can see it.
Speaker 1 (20:10):
Oh there we go.
Speaker 3 (20:11):
Yeah, I remember like that, I have I have I
haven't sent some some keys in the in the object
and I got the whole query backs has accept.
Speaker 4 (20:24):
The really gosh, that sounds funny. The Yeah, there was
also another one that actually popped up as you were talking, Charles,
which is with regards to the possible use cases for
you know, centralizing your error handling in your application, like
would you recommend I'm thinking of someone who's just studying
(20:45):
out or building a small application, so not that metrological
or anything like that, like is this, would this been necessary?
Would you recommend that they centralize their handling of errors
or is it mostly beneficial to large applications.
Speaker 2 (20:59):
That's in my it's better for large applications. So where
you have multiple components, multiple modules, and yeah, even multiple
developers or even multiple teams working working on the same
application in the same repository, and they all have to
handle in some errors. And for example, in my current project,
(21:21):
we have yeah, i think three separate teams working on
the same front end, and we are also working from
Germany and also from Poland on the same application. And
somehow you have to make sure that, yeah, your error
handling is consistent and you show the usable consistent messages
(21:42):
then and knots that each component or each module has
its own error handling. And I think that it's the
best to have. It's in large business applications, yeah, way,
where you have multiple developers. So if if you are
working on a very small application which has just one
what youule and not much logic and just one or
(22:05):
two reaf ust to to some pecnd or so, then
it's not necessary because it's some overhead.
Speaker 1 (22:11):
So I'm gonna ask, then at what point do you
start looking at putting it in? Because what I found
is that the it's just a small application, it only
does this one thing. It never stays there, right, it
doesn't park there and go, oh, yeah, I'm just occupying
space here right, Oh we need this other thing. Okay,
we're going to add this other module in. You go,
(22:32):
do you start looking at this at two modules? Three modules?
I mean two teams, three teams? Where's kind of the
sweet spot where? Because and I'll just back up a
little bit, things like testing or accessibility or some of
these other ideas that kind of permeate the entire application.
If you go in and try and do them later
when the application's big, it's really painful. And so I'm
(22:53):
imagining that this is also one of those things that
it's much easier to implement early. But yeah, you don't
want to come in with a power tool if you
can just tap out your problem in a couple of steps.
So yeah, what's the right answer here?
Speaker 2 (23:07):
It's a great question. So yeah, I don't know if
if there's a hard limits for this kind of depends
on on the application loose cases itself. So for what
this application is meant for, and I think it's not
not a big deal to have it also for for
smaller applications if you might think it will be bigger.
(23:29):
So yeah, it's it's it's a good question. So I'm
also yeah, not that experience. So I've now three years
of experience, so I've ye met some applications.
Speaker 4 (23:40):
Yes, but so.
Speaker 2 (23:42):
Do a generic answer for this? I think? So it
depends on the application itself.
Speaker 4 (23:48):
I think it always.
Speaker 1 (23:52):
Oh I was, I was a consultant for six years,
that I get it.
Speaker 3 (23:57):
So one thing I can say that like if you
if you don't want to write a lot of catcher
or in needs typical, this is good.
Speaker 1 (24:05):
Yeah yeah, what so my rule of on implementing any
kind of broad system like this is that you want
to implement it right before you're going to start feeling
the pain for it. And so it sounds like what
from what you said. You know, once you have a
couple of teams in this and you're getting up to
three maybe four modules, you know where you can't just
(24:25):
keep track of it all in your head. You really
ought to start thinking about this, right. And so when
you're starting to lose track of how is the error
handling happening across these modules, and hey, we've got this
other team over here that may be doing something a
little bit different, that's when you're standardize and that's where
I pick this up. But yeah, it is. It's going
to depend because you might have some module that does
(24:46):
like two really simple things and so it almost doesn't
count towards your complexity, right.
Speaker 2 (24:52):
Yeah, and also think like that. And it was great
when we started developing on a mic whole fund and
application with ang Law and we are just so we
had two separate angular applications with their own logic and
everything else. So there were two monoliths, and after half
a year we started to create some micro funds out
(25:16):
of them and to have some shell or some container
logic in a shell application and in the shell application,
so which which caused microfonds. We had this error handling
concepts implement and it was great to just inject some
microfonance into the application and even if a microfond froze
(25:37):
an error, that global error handling catch this error and
showed the global error message and it was it was
a great experience to see that was also working for
the micro fundans in Angular. So I think one of
the use cases if you want to really make sure
that all errors are handled correctly, and then it's you
(25:59):
can use it for a re application unless many how
many modules you have or how many developers are working
on it. So I think it's not not a bad
way to design nearly all of your applications.
Speaker 4 (26:14):
I tend to agree with that. I think, I mean,
I've been working on a small project, and I say
small inverted commas, the very classic example that Chucks just mentioned. Now,
it also started like yeah, we're going to have a
couple of components, a couple of pages, services and so forth.
But over the years it has actually grown a bit. Yeah,
(26:36):
so it's and I'm thinking now when I'm looking back,
I'm like, actually, I could have actually made use of
it back then when I started developing it. But the
nice thing is that you know, it's angular because it's
not that hard to implement it even after the fact,
as long as obviously you're following the correct patterns and
the best practices and implementing the global era handler class
(27:00):
interface in this case, that it will guide you into
doing it in a correct manner.
Speaker 2 (27:05):
And maybe it's also the wrong question to ask when
to use it, so maybe you should ask so when
not to use it. And so I think you should
not use it if your application requires some really individual
error handling. So if the customer asks you to have
some individual error handling, so if the error messages or
(27:26):
error dialogues should be completely different in the modules or
your components, then it's maybe not the best use case
for that, because yeah, you sell a little bit flexibility
for this, and yeah, so you'll lose the flexibility. And
it doesn't matter if the if the error handling should
(27:47):
be consistent in your whole application, but there might be
probably use cases that are different.
Speaker 3 (27:55):
If you're getting always a different error, then I think
we can use that recharts to transfiler and can make
these messages. At a funny side, like I wondered, like
this all we are able to do because angular implemented
all these patterns what we are having, like you can
(28:16):
use like a provide like STTP interceptor and they can
use it in another class. To those all of the
oriented concepts makes it happen. It's some are like if
someone is just starting out, it may look pretty easy, Okay,
I'm just using using a class. But how it helps
later and how it helps maintaining the application for a
(28:39):
big application. Obviously, if you're following all the patents and everything,
the solid principle, I think very few people may have used.
Everybody should use solid in the front end as well,
but at we haven't seen. It's a big topic in
the application in the big framework or big application point
of view. But this kind the patterns are the best practices.
(29:02):
We're going to help us later or at least it
will reduce our code. How mutual type and for error
handling or for token intextion supporhich.
Speaker 4 (29:13):
I guess one of the key questions, very very important
question is and for those that do not know, Philip
is is very prominent in the open source world, and
is this we're talking before we started the recording, but
this one vs code extension called material icon. It's and
I checked out the code the repository and the question
(29:37):
is do you use error handling or do you say
if you centralized the error handling for that project, you
mean for.
Speaker 2 (29:44):
The material I can feel, yes, yes, or the material
I can fee is a completely different use case. I
think it's really stick to the extension a PI, which
is STUDI code, so which is code provides a specific
a PI with some interfaces which you can use to yeah,
to customize the features of rest the code. And in
(30:08):
my case these are yeah, to inject some some icons
into the into a VUS code to need to show
them probably, and yeah, so the error handling basically looks Yeah,
it's a trycatch chain, so there's a there's a top
level try catch that catches globally the error messages from
(30:29):
from the lower parts of the application. So it's yeah,
it's a little bit difference to this concept which was
described in my article here. But yeah, somehow there's also
a global error handling in this extension too.
Speaker 1 (30:43):
Yeah, we should just use global trycatches for everything. I
like that trycatch around the whole app. Yeah, so broke Man.
Speaker 2 (30:52):
Yeah, so I mean the code for the material ICO
theme is kind of only supportive, So just the support
some some features, like to adjust the capacity or saturation
of some icons. It's it's not not the main part
of this extension, you know. It's just to support some
(31:14):
additional features, and some or or most of people might
say they are not even necessarily these features. It's most
mostly about the icons and that the icons are shiny
and look good.
Speaker 4 (31:28):
Yeah, you can attest to that, because as of this morning,
I'm a proud user of the material icon theme. Thank
you very much.
Speaker 2 (31:39):
You're welcome.
Speaker 1 (31:41):
If you went over Richard, I mean, that's nirvana right there.
Speaker 2 (31:45):
You could also try to try to produce some errors
in his extension and then you can see the arrantling.
Speaker 4 (31:52):
I will try to break it. Yeah, accept it.
Speaker 2 (31:59):
Yeah, but there's also then the error handling of your cootua,
which will show you some error messages which will catch
my extension errors. Yeah.
Speaker 4 (32:10):
Yeah, I guess. I mean you're working within this bubble,
this ecosystem that's Visual Circle provides for you the APIs
so yeah, I guess there is some sort of mechanism
that basically builds on top of that. But yeah, for
the sake of the for the topic that we're talking
about in the Angular framework, it's a slightly different concept.
Speaker 1 (32:30):
Yeah, I did have another question, and this is kind
of tangentially related, but it's more like team practice. So
one thing that I run into with the app that
I work on in the full time job is that
we don't always communicate well, hey, we have this thing,
you should use it, right, And so what will happen
is is because there are two teams that work on
(32:50):
our app, and so the other team will go in
and they'll actually, oh, we need to surface and you know,
when an error comes up, we need to surface the error.
And so then what happened is we've already built that.
Then they wind up kind of reinventing the wheel, and
now we have two systems, right, and so you know,
after they've spent three days engineering it, right and we
(33:11):
get the code view for it, we're going, guys, this
was already in there, right. So I guess what I'm
asking is how do you communicate within the organization to
make sure that everybody knows that, hey, we've got a
framework for this.
Speaker 2 (33:25):
That's a good question, though in my opinion, a good
organization or good communication is similarly important as a good
code structure or good architecture though, because it makes the
project successful, and it makes it successfully also for the
customer too, And so I can also only speak for
(33:48):
my company or or the project set that we are
working on, and it's yeah, it's about communication making knowledge
transfer sessions where we look into our code. We are
doing programming most of the time, and so yeah, and
we have to spread the knowledge to our colleagues. And
(34:11):
but I think it's also it's nowhere, it's it's perfect,
so it can happen here that that some also some
some new colleagues might come into the project and yeah,
do not know everything, so no one expects that, Yeah,
someone is knowing everything, So it can happen there that
that are reinventing the wheel.
Speaker 4 (34:32):
But also can help here.
Speaker 2 (34:35):
Yeah, I think good documentation can help. We are also
writing design documents for each feature, so where we specify
how our features and modules are structured and architectured. And
so it's it's a good base to get the knowledge
to everyone. And I think too gets Yeah, I think
(34:59):
I think the the error handling, which is described in
my article the same as how you could show loading spinners, Yeah,
produces a little bit the complexity and it makes it
easier for new developers or if they know, okay, every
request to my back end, it shows a loading spinner.
I do not have to think about it, and I
(35:19):
do not have to unit test it or care about
It's just there and it's handled somewhere globally. And you're
more complexity, you can move away from feature components or
feature modules. The better it is to make it easy
for new developers or your team to not reinvent the wheel.
Speaker 1 (35:40):
Yeah, yeah, you mentioned documentation, which I didn't want anyone
to say because the company I work for, users Confluence,
would Yeah, it makes sense, right, you put that information
in a central place. And then the other problem that
you have to solve is making sure that everybody checks
there before they go and reinvent, because I know that
my team rarely looks at it, and I know that
(36:01):
the other team never looks at it. So that's the
other piece of it, right, So you have to develop
that practice. Hey, here's here's where the info is.
Speaker 2 (36:10):
And I think I think one of the best ways
for that is pair programming. So for me, so I
think if two guys are working on a feature or
implementing something, and there's yeah, one who is not so
experienced and the other one who is more experienced, and
they can can share the knowledge the best. And yeah,
(36:32):
and everyone can enhance the other colleagues. And I think
if I think it's great if you're working together and
not not everyone separated, So I think it's also works
works for my company or for my project. We are
we're also working from home, so everyone is separated. We're
working from different locations, but we're trying to make calls
(36:55):
frequently to sink ours and to share our ideas and
our non and share our issues where we are working
on and so we are try our best to avoid
these issues so that that someone gets lost and doesn't
know how our things work.
Speaker 4 (37:14):
Yeah, that's true, like almost like each and every time
where I've sat down and work with someone so pay
programming with someone with a feature debugging session. You know,
if you were to contrast that to doing it on
your own. In my own experience, it has always been
the solution that we that we come up with well
(37:35):
pro pay programming is far much more solid, more structured,
more well thought out than had you approach it by yourself.
So yeah, I totally agree with that.
Speaker 3 (37:45):
Here, Yeah, so I can see here you have an
extension called Angula Component extractor and.
Speaker 4 (37:54):
To the clip, it looks pretty cool. Can you please
explain if you regard that.
Speaker 2 (38:00):
I think it was some months ago when I scrolled
through my Twitter feed and then I saw a feature
from a web storm and they showed that they yeah,
they showed in a gift animation that they just selected
some HTML template code with their mouths and yeah, I
think it was a right click and said, okay, reflector,
(38:23):
it's another Angular component, and it automatically happened after that,
and it was excited, and I thought, Okay, why isn't
this available for the study code, and would be a
great feature to just if you want to reflector a
large angular component which which was god too big, and
(38:44):
you want to separate it in it into multiple new
components of most likely dumb components, then it would be
great to just select the code and press one or
two buttons and then it will be extracted in a
separated its componentmatically. And this was the yeah, the idea
when I asked a colleague and a friend of mine,
(39:06):
so lecofocal and we implemented this studio code extension together.
And so it also makes it possible in reals code
to select some temperate code and after that runs automatically
your Angular Cli to to generate a component. And yeah,
(39:28):
right now it's it's really yeah, it's it's still in
a preview stage. So we are had some brainstorming about
what kind of features we could support. So you usually
do not have some htma A texts that should be
extracted into another component, but also input or output events.
(39:49):
You have some type information that you want to extract,
You have some maybe types street code that should be
extracted too.
Speaker 4 (39:56):
And so on.
Speaker 2 (39:57):
So we have lots of still lots of ideas, and yeah,
we are we would be happy for for feedback and
if people will will try it out and and say
it's nice and want to yeah, give us the feedback
that we should focus on specific features or where we
(40:18):
should yeah go further and yeah yeah.
Speaker 4 (40:22):
So basically what I'm hearing is you want to learn
how to do magic?
Speaker 1 (40:26):
Yes, yeah, I believe in miracles.
Speaker 2 (40:32):
Also, yeah, we also experienced why we are way were
thinking about it, so some features would be kind of magic,
So to expect lots of code and yeah, you know
the code is somehow really yeah, nested and connected to
the parts of your application and to just separate it
(40:54):
into a separate component. It's a tricky thing.
Speaker 4 (40:59):
Yeah, and I can already imagine a use case or wait,
this could come in pretty handy. So you remember all
that spaghetti code that you wrote, Charles so many years.
Speaker 1 (41:09):
Ago, I mean in a corn I've never done that.
Speaker 4 (41:13):
Yeah, I mean you can just dive into some of
your old project projects and yeah, you can just like
highlight a couple of head lines and have Phillips Magic
extract all that code into some nice little components.
Speaker 1 (41:26):
Nice. Oh that's at least I'll do that on my
coworkers stuff.
Speaker 4 (41:31):
Yeah, it's pretty cool.
Speaker 2 (41:33):
So right now it's working for basic components. It's working
for components to have some some some variables, and we
can generate an input y. Yeah, I think that's working
right now. You can add an input elements, so the
input is automatically added to the the child component, which
(41:55):
is then generated and the parent components. Yeah, so where
you selected your code is using this input to inject
the variable into the childe component.
Speaker 4 (42:06):
That's pretty cool. So the new component will be created
in the same same directory.
Speaker 1 (42:10):
Or.
Speaker 2 (42:12):
It's generated in the same directory, but it has I
think it I think it has separate it has its
own directory name, so it's it's the same command which
would be executed, which is executed by the Anglo sal I.
So if you would run in the current directory your
anglocal I to generate a new component, that's the same
(42:34):
with what happens under the hood.
Speaker 4 (42:36):
Are you using schematics under the hood for generating the files.
Speaker 2 (42:41):
Yes, we are using anglosil I to generate the files.
So it's just a running a note note command to
call the Anglo cel i on on the autunnel, and
then it's it's you inject requires parameters to the cel
I command and then it generates the component with the CELI.
(43:03):
So the extension expects that the Angler CELI is installed
in your project or otherwise it fallbacks to the MPX
and run CLI from via MPX.
Speaker 4 (43:16):
Yeah, okay, makes sense, so pretty cool. I will definitely
see it out.
Speaker 2 (43:21):
Yeah, yeah, you can try out, and we're happy for feedback.
And you know, you can also always great issues and
can also take a look into our code you find
find bugs or spagetti.
Speaker 1 (43:35):
Yeah, that's only chance. It's okay, that's right, I always
create issues. I mean, I will let you know if
there's a problem.
Speaker 2 (43:43):
Yeah, sure, so I think it's also always great if
people are contributing to open source report stories. I can
see that pretty much for my can extension. So it's
kind of popular, and lots of people are having great
ideas and great suggestions for new icons. You cannot even
(44:04):
imagine what kind of programming languages require an icon for
this extension, and it's great. Yeah, so I got to
know so many programming languages. Fruit is icon. I haven't
even heard before about these languages. So there's just a
programming language which is called Coconut. It's great. So I
(44:30):
love it, and people are really to it and having
these ideas and say, hey, you need that. And sometimes
also people people are creating rekfasts with cool icons, not
even icons, sometimes also code and language translations. And the
project is you have gone only so popular because of
(44:51):
lots of contributions and lots of ideas from the people.
Speaker 4 (44:55):
And Philip is actually being very modest when you say
it's popular, he's he means eight point seven six million
downloads on Vesco, so it is huge. It is a
huge success and and I love it. I've tried it
this morning, and I think it's pretty cool. It seems
(45:17):
very basic and simple, but it works and it's pretty Yeah,
thank you awesome.
Speaker 1 (45:21):
All right, well I'm gonna push us more toward picks
here just because I have a call coming up. But
before we do that, Philip, if people want to follow
you on Twitter, GitHub are usually the ones that people
push to. LinkedIn seems to be picking up steam. But yeah,
if people want to find you on any of those
where they find you.
Speaker 2 (45:38):
And so for me, it's Twitter and getthub, so you can.
So on Twitter you can follow me. I regularly post
some some new new projects or updates on my projects,
and we tweet some of some cool other ideas from
other guys from Twitter. So it's it's it's a great
place to follow my intro as regarding programming. And you
(46:02):
can also follow me on on git up, which is
not a social network, but yeah you can. You can
follow me and check on which project I'm currently working.
And by the way, that there's a cool side story.
So during my studies, some friends wanted to contact me
via WhatsApp and it did reach me because my my
(46:23):
my smartphone was was somewhere on the table on mute
and then they wrote a commit on gitup where they
wrote a Philip, can you please please unswer us on WhatsApp?
And then actually I read this message on this commit
message earlier than on my WhatsApp, so it was kind of.
Speaker 4 (46:41):
Yeah, wow, that is so cool.
Speaker 1 (46:45):
Yeah, that's that's awesome.
Speaker 2 (46:48):
So if you want to really contact me, just just
a bicast and and write some commit messages and then
then I have your attention.
Speaker 4 (46:57):
They pick up your damn phone. That's pretty cool, but
that's what.
Speaker 1 (47:06):
Yeah, Yeah, the damn phone is what what you have
after you've had your smartphone for a while of it
absolutely damn phone. Awesome. Let's go ahead and do some pics, Richard,
Do you have some picks for us?
Speaker 4 (47:20):
Actually I had forgotten about this section of a segment
of the podcast, to be honest. Let me think.
Speaker 2 (47:27):
You know what.
Speaker 4 (47:28):
What is still very fresh and brings a pig smile
on my face right now is the material Icon by
Philip Keith. You might have heard it with this guy.
So yeah, I'm gonna pick that up as one of Yeah,
one of the picks. That something that is still piccutating
in my mind right now, so I'll definitely pick that.
Speaker 1 (47:48):
Awesome, super what are your picks?
Speaker 3 (47:50):
That's so big for this week will be a book again.
So it's a start with why so everyone, Yeah, so
have edady. It will give some meaning at least.
Speaker 1 (48:04):
Yep. Terrific book, especially if you're in any kind of
leadership you're trying to influence your organization things like that, right,
so if you're trying to influence them to write an
error handler in your app. Anyway, it's a terrific book.
I like his stuff. Anything else, I kind of cut
you off there, Yeah, no, no, I think this is done. Okay,
(48:26):
so I'm going to throw out a few picks. I
just want to remind everybody go to dev chat on
TV slash level up if you want to be on
one of the Q and A calls. It's ten minutes
of training and then we just answer questions so we
run out of the time. The other one that I'm
gonna throw out there I mentioned the start of the
show is podcast boot camp. It's four weeks we'll get
your podcast launched. Make you sound terrific, and yeah, all
the details aret podcast boot camp dot io. And then
(48:48):
a few things that are not my stuff that I'm
gonna throw out. Our first, my wife and I started
watching this show, and it's it's free on the online,
so you can just just go look it up and
you can find it. It's called The Chosen and it
is basically a it's kind of a depiction of the
life of Jesus Christ. But it's so most of those
(49:11):
they just kind of showed the Bible stories, right, it's
just like this and then this and this. But what
these folks have done is they've kind of created this
ongoing narrative, and so they created backstories for some of
the apostles and some of the other people that you
read about in the Bible, some of the people for
whom Jesus perform miracles, and then you kind of get
(49:32):
this more fleshed out story and so it's it's really
been interesting. So obviously some of it is fictional, right,
but anyway, it's been a really, really enjoyable way to
kind of connect with the things that we believe here.
So I'm going to pick that because it's just been terrific.
And then completely unrelated, we signed up for a service
at the same time that we signed that we started
(49:53):
watching this, and the service that we signed up for
actually owns the production company that made The Chosen and
we found that out later. But the service is called
did Angel, and effectively what they do is you can
watch shows on Netflix, Amazon Prime, a couple of the
other streaming services. I think Kulu is on there. And
(50:13):
what it does is you can tell it to filter
out certain content, right, So if you want to watch
a show with your kids and you don't want them
to see certain kinds of content, can tell it no
sex or no none of these words or things like that, right,
and it has filters for that. Now somebody has to
go through and actually say the filters apply to these
(50:35):
time codes. Right. So it doesn't have everything on all
those platforms, but it has most of the popular stuff.
And it's been pretty nice because there have been some
shows that I want to watch that I know have
parts that I don't want to watch, like me personally
as an adult, right, and so I just say, hey,
you know what, I don't need to see nudity, I
don't need to hear the F bomb, right, and it
just cleans it up. And it's been really, really nice.
(50:57):
So I'm going to pick that as well, Philip, what
are you pick?
Speaker 2 (51:00):
I think my pig is actually get up code spaces,
So I think it was published the last week or
within the last two weeks. And get up code Spaces
is weist code for web with which you can open
ye git up repositories simply by simply by pressing the
(51:21):
dot button of your keyboard and then you can start
editing code of some repositories. And yeah, navigating through repositories
on guitub with the wes code Web edition. And I
think it's it's really great. Unfortunately, the I can think
is not the capital right now of this, but there
(51:43):
will be an update. I think maybe this evening on
lately tomorrow, so yeah, I will will start to publish
a new version on Edge so that it's also available
for get up code Spaces. And I think that's one
of one of the great things that secured within the
last one or two weeks for me.
Speaker 4 (52:04):
Oh yes, I need to chime in there because I
actually retweeted that tweet from your feed and I tried
it out.
Speaker 1 (52:13):
It is so cool.
Speaker 4 (52:14):
If you thought that was what I mentioned it on
was magic, this is like mind blowing. It's just insane,
very very cool feature from from get up. I think
it's I think it's pretty it's gonna take off it's
gonna pick up very well, I think, yeah, very cool.
It'd be nice to see material icon't theme there as well,
So yeah, it will come up listening.
Speaker 1 (52:38):
Awesome. I just found out too that, and I'd heard
rumors of this, but The Chosen has actually filmed about
forty five minutes from here, Utah. I don't know why
they well, I do know why they picked that location,
and it's kind of an interesting story. I'm just gonna
throw it in real quick because it's fun. But so
the Church, the Church of Jesus Christ, the Latter day
Saints LBS Church, Mormons big presence here. I remember the
(53:00):
but they did a bunch of Bible videos a few
years ago, and they basically built a whole bunch of
like replica sets of Jerusalem scenes and stuff. And they
allow other organizations to come in and film the same
kind of content. Right, if you need kind of that
ancient looking, you know, old time Jerusalem kind kind of
(53:21):
look to your film, you can come film there. So anyway,
apparently they let them come film The Chosen there as well.
Speaker 4 (53:28):
Interesting.
Speaker 1 (53:29):
Yeah, love this stuff. It's fun. It's always fun to
find it like semi personal connection to some and so yeah, Anyway, well,
thanks for coming Philip. This was a lot of fun
and hopefully we inspired some folks to, yeah, kind of
consolidate and simplify some of this stuff, because yeah, if
you're doing a piecemeal, it's kind of a pain in
the neck. But if you can get it all together
in one place, then it's, oh, I'm just going to
(53:51):
lock into these components in these services and I'm done.
Speaker 2 (53:54):
Yeah. Absolutely so. Also, thanks for having me and I
had some great questions and was great to be part
of your podcast.
Speaker 1 (54:01):
Yeah. Well, we're going to wrap up here until next time, Maxim, Bye,
bye bye.
Popular Podcasts
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.