The panel discusses application performance monitoring, bug reporting, and real world experiences with Innocent Bindura, Snr Developer at Raygun.

Links

Picks

Hello, and welcome to another episode of adventures in dot net. I'm Sean Klaeba, your host. And with me today is cohost, Wai Lu. How you doing, Jay? Hey.

Good day. Good day. Yeah. Yeah. It is a pretty good day.

It's always a good day for you when we record because it's Saturday. Oh, yeah. It's nice. It's not too bad for me. Yeah.

Not too bad for me because it's towards the end of Friday for us. So Yeah. Just call and fetch the pub. Is that right? No?

Well, if if we were doing better for COVID reasons, I'd probably be Right. Yep. Yep. But, the wife wants me to stay safe, so I'm staying home. It's funny.

Alright. We don't like lots of movies. Yep. Alright. So our guest today is, Innocent Ndura.

Welcome, Innocent. Thank you, Sean. Thank you for having me on the show. Oh, welcome. Welcome.

Welcome. Welcome. We're glad to have you. So, to start off, why don't you tell us a little bit about yourself, you know, what you do, how you got into doing dot net development, and things like that? K.

Cool. So, yeah, my career started way back in 2004. Actually, getting into computer science wasn't my first choice. I wanted to be civil engineer, and there was very high competition in the college, back in Zimbabwe where I'm from. And, because I didn't make the cut, my second career choice was IT.

And I think I spent a week brooding over, not going to the civil engineering department, but as soon as I found out what IT was all about, I took to it like duck to the water, and I've loved it ever since. I have worked in a number of companies, from Zimbabwe, South Africa, and now presently in New Zealand. And I think I have grown immensely just experiencing different working with different people, working in different industries, being exposed to all sorts of technologies. And, now finally with Reagan, where I use all that knowledge to help other developers, through building, performance tools. Nice.

Nice. Well, I mean, Raygun's been a sponsor for our show, and we we surely appreciate that. That's been been great to to help us out that way. Why don't you tell us a little bit for those that don't don't know Raygun, what do they do and and how they kinda fit into the, dot net, you know, system? Okay.

Cool. So Raygun, the whole team is passionate about improving, people's people's experiences, particularly with the toolset that they use. So we develop for developers. Primary target audience is developers. And Reagan, doing most of its stuff in dot net, This is where I find myself fitting in, and we've got a couple of dotnet tools that we, offer to the public, mainly around crash reporting, application performance monitoring, and browser performance monitoring as well, which sort of delves a little bit into a little bit of analytics, but not quite the way Google Analytics has it.

So, yeah, Reagan is passionate about the customer experience and the developer experience. Is it similar to that app like, the app app inside in video for you? Yes. So it's more like app insight and more. App Insights will give you more more of your crash reports, and they surface things that are happening within your application, but you still have to sift through a lot of code for it to make sense.

We've got a workflow built into the crash reporting, and we've got some pretty nifty ways of aggregating the errors in the back end behind the scenes so that those errors can be prioritized, is it worked on, maybe you're in a scrum setup. You can iterate through them and, just use the modern workflow to, you know, resolve the biggest pain points that your customers are experiencing. So, it's more than just like an error reporting thing. It's almost like a whole monitoring system. Is that right?

Yes. It's more of monitoring system with a couple of integrations with the other mainstream technologies like Jira, Visual Studio Team Services. I think it's now called Azure DevOps, Bitbucket, GitHub, and so many more. How hard is it to to add that to an existing application? Are you you know, is it just adding a NuGet package, or does it take more than that?

So, yes, speaking from a dot net point of view, it is as simple as adding a new Git package and a couple of lines of code. You're ready to go. And, depending on the experience that you want to have with Raygun, you can do a little bit more to, integrate extra information that would means make sense to your troubleshooting when you look in the, Ray Gun control center or Ray Gun portal. But to get things going, it is as simple as maybe 2 or 3 lines of code, and then you get package. Okay.

Nice. So I I'm I'm I've looked at a lot of monitoring system before, and quite often, there's just so much information that gets fed into them. It's kinda hard to to filter out the important stuff. So, you know, what's the best way to to, you know, you know, kinda, you know, monitor that and and find what you need in all of that, the reports that these systems kinda generate? So I'm gonna break down my answer into the 3 products that we have.

So firstly, with crash reporting, I think every application out there generates some exceptions of any sort. And the way Reagan takes that is we've got an internal grouping system, which makes it easier for the developer to find out where that error is happening. We group our errors based on the stack trace. So meaning if there's one point in your code base that keeps generating a ton of errors, that area is very easy to get to. And, when you look at the information, instead of seeing a 100,000 lines of the same thing, you only see 1 and with a count.

And if the same error is happening in another section, that would be another error group that you see. So when you are working through those errors, you're only dealing with things or rather certain points within your application that are known to be failing. You're not overwhelmed with the amount of information that's being fed into the system because that information has been aggregated and processed on your behalf so that you can quickly focus on where the problem is. Furthermore, with integrations like Bitbucket and, GitHub, we take you straight down to the line of code. And then with, APM, there's also a lot of information that comes out of traces.

I mean, if we're looking at big customers who generate millions of sessions every day, And if we were to monitor their servers using APM, that will be a ton of information coming through. So we can tone that down and tune it way down, through our sampling rates so that you can continue keeping an eye on things and see how they're going, but not necessarily receiving every single trace that every customer of yours goes through. So in that way, if there's an issue, it's bound to surface itself up in one of the traces. And again, through the other integrations to GitHub, Bitbucket, you can drill down right down to the line of code. I think when we compare Reagan to the other providers out there, Reagan, does monitoring right down to method level.

The other profilers that I have seen out there sort of give you an indication that, you know, things are not really going well. But when it comes to diagnosing the issues, you're not really able to delve down to the line of code where the issue is really at. And then with RAM, we do take everything because with real user monitoring, you really want to see the true performance. And, what we are after here is not per se, but, just the general health of the application as an overhaul. So you are interested more in aggregated information.

So we do take everything in, and then we process it, and we present it to you in a dashboard manner. And you are able to drill down, to the individual sessions and actually see the specific experience that your user had. And, I think one of the things that Reagan really does well is having that user focus or that customer focus. So if you are experiencing an issue with, either crash reports or slow load times in your website, we can tie that down to a user, and you can actually drill into the session and see the number of exceptions that that user has experienced, and, also see their location, their vision of operating system, the browser, and so forth. There's a wealth of information that enables the developer to diagnose the issues correctly and have them fixed once and for all.

So you use the acronym APM. What was APM? Application performance monitoring. Okay. It sounds sounds like this is actually quite a comprehensive piece of software.

So is it just for dot net, or does it work for all other languages? So we are currently expanding to other languages. Just recently, a few months back, we launched crash reporting and APM for Ruby. And, I think coming on the 1st March, to general availability is APM and crash reporting for Node. Js.

Dotnet is a more mature product in the market. So it's actually a suite of products that work well when they're put together so that you get that holistic view of your customer experience. Yeah. Yeah. I think I think it'd be pretty useful, I think.

So, like, is the data stored on the cloud, or is it stored on premise, or do you get a choice of where you'd wanna store the analy data? So currently, Reagan is operating as a software as a service. So we put our infrastructure up in the cloud in AWS. Everything is hosted in AWS. So we deal with companies that have got strict compliance codes when it comes to data retention and so forth.

And I think we have complied with every single customer need or anything necessary for us to do for those customers. We have been able to do so. And as far as, PII or personal identifiable information is concerned, we are also quite flexible in the way we collect the data. The data is by default anonymized, and then if you opt in to give us the full credentials of your customers, We take them in. By credentials, I just mean email, first name, last name, not anything to do with passwords or, anything that could expose you on security concerns in that respect.

I think we have got some customers in the health sector, so they don't send us their patient information. What we receive is a token that they can then associate with the patient on their end. So we are quite flexible in terms of the amount of information that we collect. And I imagine HealthHab. Yeah.

That'd be a that that personal identifiable thing would be a major issue when they've been designing an analytical portal. In fact, just designing just the data schema and all that stuff in general, keeping that in mind. I don't know how you when you do it. Just make sure that, you know, if if there's a data breach or whatever, that the sensitive data isn't isn't leaked or if it Yeah. So we've got layers of, encryption on our databases.

Some are applied on the operating system level so that, anything that's coming in or going out is encrypted. And then the data itself, when it's stored, it is also encrypted. So if we were to be hacked, for instance, whoever the hacker might not be able to fully make sense of the data because they don't have the encryption keys that unlock that sort of information. So it's you you talked about application performance monitoring. You also talked about real user monitoring.

Are there other things that it does besides those? So sorry. I don't think I understood the question correctly there. So you've you've talked about APM, application performance monitoring, and you talked about the real user monitoring of Raygun. Yes.

What else can it do besides those? There's the crash reporting, side of things, which is our flagship product. Yeah. Okay. Can Reagan help you do anything, like help you figure out scaling?

Well, when you look at the metrics that do come through, they can definitely be used in making a decision in terms of scaling. For example, we'll take you to the RAM products. When you are looking at the general health of your application, you can already see what the load times are. So if you were to scale, suppose you are having a Black Friday sale, and you are an ecommerce site, and you are expecting your traffic to triple, you already have the metrics of how you're currently performing on your current infrastructure. So as you plan for, that increased load, you can use those metrics to plan out just how much capacity to provision before beforehand, and, you can scale back down.

So in terms of setting up your infrastructure and scaling, there's really no insights we can give you. But in terms of giving you data on your current performance and how you're currently doing, you can certainly leverage that to make a decision on how you want to scale, your application for load. Can can any of these things kinda help you along like, a lot of times when I'm developing an application, I I I'm in the planning stage, and I need to figure out, you know, what what how's my architecture gonna be laid out for all the different applications? How can it do do things like that? Can it can it help me there?

So I think one of the key tools that Dragon provides that I would recommend to be used as part of the development cycle is the application performance monitoring tool, and I'll qualify my suggestion there. The way I have approached coding in the past is I have read a lot of books. I've read a lot of articles on how to write scalable code, and how to or which tools to include in my application to help speed up the development cycle, things like object relational mappers. When you are putting the application performance monitoring tool into your development cycle, you can quickly run some simulated tests, and you see the behavior of the application. And one that really quick jump jumps out is the n plus one queries when you're using object relational mappers.

That's when you are loading an object graph. It references another object that then requires the ORM to reach out to the database to load more information. And that child object switches out to another, and to another, and to another. So you end up with these queries that could potentially take a long time. And we all know that the best way to pull out information, from a database is not multiple round trips to the database, but a single round trip.

So you would then look back into your code, and you ask yourself how you would deal with those n plus one queries. Maybe your ORM supports joins. So you then tell the ORM that when you load this object, rather perform a join instead of sub queries. So that's where I find the power of APM influencing my architectural decisions. And then it might surface things up that really make your application slow.

And you then, look at the mission critical parts, and you ask yourself, do we really need to process everything synchronously, or we can defer processing for later? And in the past, since I joined Reagan, I have found myself needing to, you know, accept incoming traffic from users and not process it right through, but just accept it and return a 2 or 2 codes to them to say we have accepted the information. And then behind the scenes, I have got a number of workers that crunch through all that incoming traffic and then pumps it down the pipeline until it's information that can be presented to the customer. So you'd find that we probably have 4 or 5 servers receiving incoming requests, and each of them with a capacity of processing 2,000 requests a second. And the that capacity of 2,000 requests a second is found through just accepting the information and then delegating processing to other workers downstream.

We found out earlier on that if we received a crash report, for instance, and we wanted to process it so that it's ready to be presented as information, synchronously as it is coming through, we would lose a couple of seconds through waiting for all the processing to finish, and that would have reduced the capacity of us receiving, you know, these crash reports coming from our customers. Just to put things into perspective, we receive, anything from 250 to 300,000,000 crash reports from all our customers a day. And if we were to process them synchronously, we wouldn't even be able to crunch through half of them. But through the architecture, that was influenced by looking at APM and the data that was coming out of our own APM tool. We quickly found that, you know, the synchronous way of processing things is not scalable.

Therefore, a delegated, more like event sourcing, type. So also helped me circle back into those development principles and see which one best fits the way we need to do things. What's mission critical? What's not mission critical? What can we defer for processing later?

What can we process in the client side, when you load your application, when you view the information? Not everything is kept in a information presentable format. Some of it is actually delegated to your browser to process so that when you, look at the information, it now makes sense. So without APM, those kind of decisions, we wouldn't have been able to make them. It would have been a painful process to go through the cycle of outages and fed customer experience for us to come to those decisions.

But through utilizing the APM tool, you can quickly see how your application is behaving. And because you're still in the development phase, you can make the hard call to say, we need to change this so that it's more scalable, it's more performant. It is in general having more data, I guess, allows you to make decisions about well, Arctic's decisions because you can see you get more visibility about what's going on. Yeah. Does Ray Gun like, I'm thinking, like, one thing that'd be really good and cool is if Ray Gun did some metrics across all customers to find, like, common problems that people have and, you know, try to help out and identify those kind of common problems that people run into before they actually experience it, or maybe even being able to report back to, you know, a company that their product is being used by all of our all these customers that are reporting to Raygun, and we're seeing the same issue across all these different customers you might wanna look into.

Like, maybe Microsoft had a bad library or something like that. And you could you since you've got all that data, you could, identify that and, you know, help, you know, get rid of bugs and things like that. Yeah. So that sounds, like an interesting part. I once had our research and development department talk about, applying artificial intelligence across all the datasets that we have.

And, quite possibly, that would have been one of the outcomes. And I think one of the things that they were alluding to was an integration with Stack Overflow, such that if we see that there's this a common problem, we can now include the Stack Overflow link as part of the resolution workflow that you go through. So instead of the developer searching for a crash report on in in Google, we already have done, the lookup at Stack Overflow for possible solutions to those kind of things. So, yes, it does sound very interesting, and I have heard our research and development department talk about, developing, towards that direction. I haven't kept tabs on them and found out, how far they got with that project, but certainly it does sound interesting.

Alright. Well, I would personally love that such a feature, Murugan. Like, in fact, it would be better if you guys can even suggest the fix and even have the code there to to fix it for you. But Yeah. But if it's if it's common in in a third party library or something like that, then, you know, you could, you know, provide, you know, some some metrics back to that company that, hey.

This is a this is a bug that we found that's that everybody's experiencing. You know, you might wanna fix it. Yeah. Because that's one thing about programming. Right?

That's never gotten better. The the error messages and all that stuff are still obscure. So that experience hasn't improved for a programmer, even from the beginning. So Yeah. I often laugh when I talk to other developers because you're not looking at their work.

You know, everybody wants to come across as an elite developer, and the only thing that exposes them or rather that helps them improve is by actually being open with the kind of work that they're doing. And I think Reagan could play a role in terms of improving software in that regard. We receive a lot of, information from our customers, and it wouldn't cause us any pain to look at common third party libraries that people rely on and, you know, point out some pain points that everybody is experiencing and better off even suggest fixes for them. What I wanna know is, you know, how these tools can kinda help you identify, you know, the common problems that that people run into, you know, and and, you know, fix that so people are have better knowledge and become a better developer and maybe even get some some recognition. Alright.

I think that is now speaking into, curating some information and some techniques of overcoming those problems. Based on the work that I have done previously for AIGAN in the APM space, I was tasked with working with the Postgres database and processing large quantities of data. And quite early on in the development process, I found that, you know, using an object relational isn't going to work, mainly because when you reference an object in an ORM, it loads even the unnecessary bits, and that just creates an overload on, the memory requirements of the server that you're using. So if I were to curate information from Reagan, that would be beneficial to developers. I would start looking at the common trains in, APM traces that come through and some of the issues that we automatically identify and, try and categorize them and, you know, maybe do 1 or 2 blog posts on how to work around some of those issues.

But at this point, unfortunately, that's not something that Reagan is currently looking at, but I do see the value in terms of educating developers out there before they run into some of these pitfalls. I guess I've I've kind of run out of questions for myself that I can think of right now. What what kind of things have we not gone over that are important for developers to know and and for getting performance or bugs out of their code? I think based on my experience in the industry as a software engineer, the one thing that I can relay to developers out there that really makes life simple going forward is keep things simple, keep things short. I have read Principles in Programming by Robert C Martin.

It is a very useful book where he talks about Bob. Right? Yeah. Yeah. That's uncle Bob.

When he talks about the solid principles, they are a difficult thing to master earlier on in your in in your career as a developer. And as you continue on, you get those moments. And it's a book that you have to keep referring to. You keep reading it and refreshing your mind on how things are supposed to be done. And then you quickly find yourself in this situation now where you are writing efficient code and keeping classes specific to one thing and keeping your methods very short.

They're just supposed to do one thing, and you don't pass parameters in simply to pass them on to the next method. You you start, you know, decoupling your application so that if one section is not working when you want to implement a fix, you're not tearing apart the entire application. You're, you know, you have just focused on that one area. And better still, if you want to talk about the Liskov substitution principle, you start, you know, developing your application in something like an onion structure where services are plugged in. And if the service is not working, it's a simple thing as pulling it out and putting a new one in.

That really leads to your software working cohesively and reducing the amount of bugs that people have to deal with. And it also makes your delivery cycles easy and straightforward. That said, setting up a new project in that manner can be quite daunting. So that's where tools like Reagan really come in and shine, you know, and they expose some of the issues, technical issues that you might have overlooked. They surface quite earlier on in your development cycle.

So if there's one thing that I would want to leave developers with out there is keep things simple. Yeah. I can I think I can totally agree with that? I think we'll try to do it wherever we can. But but, yeah, maybe a tool like Ray Gun or something like that would really help.

Is there a way for people to to just try out Ray Gun and see if that's something that they would really wanna go with long term? Yes. So if you visit our website raygun.com, anybody can sign for a 14 day trial. If you do want to extend the period, by all means, reach out to me. Reach out to any of our business development teams.

They'll be more than happy to extend out the trial and work with you through, you know, finding, the value in, RHEA gun. Wouldn't it take more than 14 days to integrate into into your application? So most of it is quite simple and straightforward. In 5 minutes, you can have Reagan plugged in and working. For dot net, for example, you reference then you get package, you pull it down, you compile your application, you add one line maybe in your global ASX or in your startup class, and that's configured as a catch all.

And then if there's any unhandled exception within your application, Reagan captures those and pushes them through. That's the easiest form of setting up, Reagan crash reporting. With real user monitoring, it's just a code snippet that you put in your shared class or one of those shared artifacts that get delivered to the client side, and then a reporting starts almost instantly. As soon as the page is loaded, we start getting information. Okay.

What about database do you have to creating on database level? How would it know database calls and things like that? So we know about database calls only on the APM side, which is a little bit more involving than the other 2 to set up. There is a requirement for you to set up an agent, which is what pushes Mhmm. Through to Reagan.

And then depending on what platform you're on, if you're on, .net, or if you're on Ruby, or if you're on Node, there are different things that you have to to hook them up. For dotnet, it is as simple as opening up the configuration tool, and then you point to the IIS application pool that's currently running or rather to the dotnet core process that's running your application. And we automatically start receiving traces for your application. Things sort of work in a magic way there. There's a server variable that we set that tells the run time that we are going to be profiling this application, and then the right time run time hooks into the ray gun profiling, library that then pumps the information out through a UDP port.

For Ruby and Node, it is as simple as including the gem file in your Ruby and pulling in the NPM package for Node and requiring just the rig and HTTP in your code. So in terms of setup, it is quite minimalistic to get it working. And then depending on the amount of value that you want to get out of Reagan, there are some more customizations that you can do within your code to inform Reagan of what's happening with your application. Yeah. Cool.

So if if my application isn't crashing, I don't have an any unhandled exceptions, does that mean everything's good? It's more like life. Right? The absence of sadness doesn't mean you are happy. Either yeah.

Everything's good or you just haven't set up Ray Gun. Right? No. So in that respect, no unhandled exceptions, but you still want to know if you're experiencing exceptions. Right?

So in your catch block, you would then manually send something to Reagan. But what I often encourage people to do is write a reaper class. Right? And that reaper class is the one that is glued to the Reagan client, such that if you are running your application and you want to turn off Reagan for a bit, you simply swap out Reagan for a dummy, and you don't have to change your code base or you don't have to rip out Reagan because you've got things controlled through a repa class. And, that way you can now include that repa class if you you've got a catch clause that is handling all your exceptions, and you are pushing the information through to Reagan.

Yeah. I think that's important for, I guess, unit testing as well. Right? You probably don't wanna put that as a dependency in in any of your tests, you know, write stuff to a an external source. So Yes.

Exactly. Yeah. And of of course, you know, things could be slow, but no errors. So that could be a problem that you wanna watch out before watch out for. So it'll help you with that too, yeah, it seems.

Yes. It would help you out with, with that too. But that said, to get the most value, there are 3 products that Dragon offers. You would have to integrate all 3 to get the best value. So if you want to see, performance metrics in terms of speed, load times, and things like that, we're talking APM and real user monitoring.

And then if you want to understand a little bit more about your crash reports, we have been talking about, the Reagan crash reports integration with your application. And all the information that is collected by all three products is accessible through a single portal. And, I think it's also important to highlight that in the inner workings of, Reagan, once you have integrated all 3, we can actually map your user journey from every request they made on the front end to the crash reports that we generated at the front end, crash reports generated server side, and then right down to a step in the session that they had, and the load time wasn't so great. And then you navigate all the way down to the trace on the server side, and you see what the application was doing, why it actually took that long for it to complete. Okay.

Have we covered everything? I think we have covered quite a lot. We didn't get into some of the examples that I I had wanted to highlight. Go ahead, Shay. No.

So what are some good good examples? So there was this time I worked for a company which had a 9 o'clock bug, and we had no idea what that bug is. And this was actually my first time of being exposed to Reagan. At 9 o'clock every day, our customers would call in and say, you know, the service is unavailable. We can't access it.

And it was quite critical for them to use that service at that time. And, plugging in Reagan, it quickly became evident that we were having win 32 errors with, MS SQL Server, and, it would then cause, slow queries. And then those slow queries would just grind everything down to a halt because the database would become nonresponsive. And we had no clear insight into what queries were running at that time. So through using APM, you know, I was able to see those large auto generated queries kill the database.

And the easy straightforward fix that I did was I simply took out the object relational member and replaced it with a direct query. And that saw the 9 o'clock bug that had plagued the company for almost 2 years, get resolved. So was it just a job running at 9 AM, or was it because, like, people were coming into the office at 9 AM and triggering this this cause of events or something like that? So it was firstly a poor database design decision that was made when the application was commissioned, and that just resulted in a recursive call on 1 database, on 1 database table. And, given 1500 or so people trying to access that table at 9 o'clock and everyone having to go through their recursion, it quickly ground the entire database to a, you know, to a to a dead stop.

We would often need to restart, the the the SQL Server for the system to come back online. And immediately after restarting it, 10, 15 minutes later, it would be down again. So we I had no idea what was causing it to slow down like that. I did try to inspect things using some database inspection technologies, but they didn't quite point me, to where it was failing. By the time those tools were supposed to pull out the information I needed, the database would be dying, and there was no way for me to get that information out.

But plugging in APM, I quickly saw what was going on and, came up with the solution. And then over time, we obviously restructured the application and got rid of the the recursive call. Yeah. Cool. I think that's a really good pretty good example.

Yeah. I know I know. It sounds yes. It does sound like that's a that's a load issue then. I it was it basically from people coming to work because it was 9 AM?

Or is it 9 AM or 9 PM? 9 AM. So it was basically caused by people coming into work. Yeah. That's interesting.

Looking at their schedule of what their day is supposed to be like. And then this one week, I would go into the database and start running recursive queries. Any other examples? I think this was one of the best one where I got to use Reagan. The other one wasn't solved through using Reagan, was also a very painful thing to go through.

But I did manage to use Datadog because Datadog allows you to send those arbitrary metrics to it, and then they graph it over time. So what I was really interested in was the performance of, in particular, a couple of methods over time to for me to see what was going on, and, also to give me a clear indication when things were starting to stall. So I would see the graph start trending down instead of staying staying up and steady. So it just helped me look at when things were going wrong, I would see the graph would start dropping. And it was a clear indication that, you know, I need to go back into my code and do something.

And that's not something that Reagan could have helped me with. So I think the importance of highlighting this example is although Reagan does a lot in terms of surfacing issues, it is not a silver bullet that is going to solve all your problems. It will get you there to some extent, but when used in conjunction with other tools, you will find better value in terms of finding quick resolutions for your problems and then keeping an eye on other things that Tran doesn't necessarily monitor. Okay. Cool.

Cool. If there's nothing else, any questions? I think we should move on to picks. What do you think? Yeah.

Let's do it. Alright. So, my pick this week is actually gonna be OBS Studio. You know, why is and and the why, Caleb's been using his little, you know, YouTube channel for doing, you know, recordings and things like that. I think he's using OBS Studio for it as well.

And then, also last week, I was asked to be a presenter at a local user group. So I did a talk on on Angular and then and using dot net for the back end and things like that. So I've hooked up OBS Studio with my camera and a little green screen behind me so that I can, you know, be have my little head over in the corner while sealing seeing my code window, you know, in the project in the in OBS Studio made that, real easy for me to set up and get that going, and it was free. So so it was great to have that kind of flexibility in my my recording and my my presentation. So if you're trying to do recordings of live, streaming and things like that, look into OBS Studio for that.

That seems to be that seems to be what everyone, like, from the research I've done, but most YouTubers are just using, which is awesome because it's free and seems to be the the product that everyone uses. So Yeah. Yeah. People So it'll be a learning curve. But, well There's a lot of configuration, things like that.

I did, you know, have to read a few, kinda setup instructions and and, like, one of the guys at my company had already kinda set it up his, for his recordings. So he was able to put together a little blog post, and and I just followed that to to get things set up so that it was being it was sharing the right video Mhmm. Where it was, you know, it's combining your camera with what's getting recorded off your desktop. So it's gotta you combine those 2, and then you have to set up a chroma key for for a green screen. So if you're using a green screen behind you, you have to set that up as a chroma key, or there's actually ways to set up a use a virtual green screen.

So it somehow gets a green screen behind you with Oh, okay. You know, plus the desktop to get going along those. So you don't actually have to have a real green screen. It just makes it easier if you do have a real green screen by yourself. Mhmm.

I noticed a lot of these be it like if you use Teams and stuff, you don't need a green screen, but it'll still do the background. Just got the intelligence to figure out where you are and where the what the background is and things of that. Yeah. Yep. Alright.

What do you got for a pick? Domingo? Yep. Yep. Okay.

Cool. So this week, I thought I'd pick a movie that I saw during the week. It's called Greenland. I think it's on Amazon Prime. And it's about a it's kinda like a deep impact, Amalgam movie where there's, like, a comet that hit the earth.

And I think it was good. It was an entertaining I don't know. I'm not sure how scientifically accurate it was on the heat, but it was just an entertaining watch, I guess. So it's Yeah. There was the Mars Lander landing this week.

Did you, Wipe? No. I did it. Was it successful? Okay.

Yeah. I I knew it was coming. That was just yesterday. Yeah. Just yesterday.

So it landed. It's already sent back some pictures, so that's really cool. They even had a, a VR, stream going on YouTube. So if you had a VR headset, you can You can you know, go on there and watch, you know, the the Mission Control Studio in Nice. Wasn't it wasn't 3 d.

It was it's 3360 instead of 3 d. So Okay. It's still kinda cool. Yeah. Cool.

No. I hope I got to check it out. So Alright. Alright, Innocent. Do you have something that you'd like our listeners to know about that, you've been interested in lately?

Yeah. So, my life has all been about family, family, family. So my young kids are in school now, all 3 of them. And quite amazing how they are catching up with technology in schools. So there's an app called Extra Met that the kids here in New Zealand are jumping on.

It's a fun way for them to learn. Not as cool as, the mass rover landing, but just interesting to see these young people catching up with technology. I think for myself, it wasn't until I was 23 that I first laid my hands on a computer. And my kids are all under 10 years, and they already have a laptop each. So it's quite amazing, to see what the schools are doing with technology and, teaching the young kids technology.

I would really, really recommend, the extra maths app. It's a fun way for kids to learn maths. The people who present it are not as cumbersome as I thought they would be, and kids really love it. Cool. Well, I've got I've got young kids, so I'll definitely check it out.

I've got I we use one called, I'm not sure if it's in New Zealand. It's called Reading Eggs. It's I think the school recommends it, and, yeah, they're definitely using it. They use that one too. What's I use that one, though.

Is that available in New Zealand then? Yeah. It's interesting what you're saying. I think, kids get it's it's it's touchscreens, I reckon. Touchscreens are so so intuitive.

Like, kids and old people and people that don't know much about computers can can just interact with it really easily now. It's just it's just natural. So Yeah. I'm old enough that, they didn't even have computers in the schools until I was, like, 13 or 14. Yeah.

Same. Much Alright. Cool. Thanks, Innocent. Thanks for coming on the show, and and let us know about all the different things that that Raycon can help people out with and and also some real world, you know, experience, with problems that that that you see.

It was great to have you on the show. Thanks, Sean. Thank you. And thanks, Wei, for having me. No worries.

Alright. If people have questions, how how can they reach out? Should they they can easily find me on innocent at raygun.com. That's innocent not guilty at raygun.com. So, yeah, if you do find my name funny, please ping me.

You might get a day or 2 extra of, Reagan trial. Awesome. Awesome. Alright. So for listeners wanna reach out to the show, we'd love to hear from you.

We wanna get your feedback. Let us know how we're doing, how we can improve. You can reach me at at.netsuperhero on Twitter. Thanks, everybody, and we'll catch you on the next episode of adventures in dot net.