Hey guys, my name is Boris. I'm a board-certified physician assistant. Welcome to my channel if you're new here. The topic of today's video is going to be Relationships in PA School. So I was doing a little perusing on the Reddit Pre-PA page and the physician assistant page. And I've been seeing a pretty common topic pop up lately since it's been getting colder outside in most of the United States. And that topic is Relationships. Boyfriends, girlfriends, husbands, wives, fiancés, in PA school. So I wanted to talk about that for just a minute. But one giant caveat I wanted to throw in here is one thing that I firmly believe about relationship advice is you should not take it from anybody whose relationship you do not want to emulate. That's one of the few pieces of advice I really, really, really wish I would have learned earlier in my life. That would have saved me so many years and so much pain, you have no idea, and so much money, but you have no idea. So that's definitely one thing that I'd like to throw in here. You should not take relationship advice from anybody whose relationship you do not want to emulate, or at the very least whose relationship outlook you do not agree with. Okay? So with that, I want to tell you that I'm not currently in a relationship. I was in a relationship about the first year to a year and a half of PA school, and it actually ended during clinical year. So if you don't want to take advice from someone whose relationship actually ended during PA school, you should probably turn off this video. And I'm definitely not going to go into the reasons that ended. That's like super personal. I'm never going to put that out to the general public. It's just not something I care to share. It's not what this channel is about. And just to maintain everyone's privacy and dignity, I'm like, that's just not something I'm ever going to talk about. So that out of the way. But the reason that it really ended was we just were not aligned in our beliefs and our ideals and who we were as human beings. My ex is one of the most incredible people I've ever met. And that'll probably never change. And anybody that meets her, I guarantee you will agree. She's an incredible, incredible person. And I was lucky to know her for as long as I did. So it's not like the relationship ended for any reason, like she was a bad person. And I don't think I was a bad person. It just straight up was not a match. It's like that analogy with that like little kids toy with all the different shapes that you have to put into the different cutouts for those shapes.  It's just the fact that it's just not a match, you know, it's just not aligned. So that's the best way I can describe it. It just it was not a match and it had to end and it did. And I think we're both better people for it. So with that out of the way, and also the caveat of if you don't want to take advice from someone whose relationship actually ended during PA school, and if you don't want to take advice from someone who was in a relationship that was not aligned for a little too long, and then finally did end it, you know, shut off this video, I'm just not somebody you should take advice from or really even listen to when it comes to your relationships, we just may not be aligned in that way. But if you are interested in what I'm going to say, here we go, I'm going to say it relationships in PA school. So most of the questions that I'm reading are somewhere along the lines of how does a relationship survive PA school? Do relationships survive PA school? How hard is it to maintain a relationship in PA school? And the answer to all these questions is yes. Yes, relationships do survive PA school. Yes, it is possible to maintain a relationship in PA school. And yes, it is also very difficult because PA school just takes so much time and relationships take time and effort. So therefore, yes, it's going to be a little harder to balance those things. But it's totally possible. My class had 75 people in it. And I definitely don't know how many people were in relationships. I didn't count. But I definitely can tell you that there was a lot of engagements. There was a lot of marriages. There was a few relationships like brand new relationships that were formed. I'm not sure if they're still together or not. Some are some are not. But the point is there were plenty of relationships that did start that were maintained. And there were engagements and marriages and all those wonderful things that ended up coming during PA school and shortly thereafter. So it's definitely, definitely possible just by the many examples that I saw in my own experience in my own PA school class. So I know that doesn't give you like any specific advice on how to do it or what the likelihood is of your relationship surviving. But just straight up by the numbers and examples of other people doing it, you can just kind of be a little more comfortable, a little more confident that if other people's relationships survived or other people began relationships during PA school, you know, maybe the same thing can happen for you. It absolutely can. Maybe it will. And by the way, I just came home. So the light from my car just came on. So ignore that if that's distracting. The next thing I want to say is that PA school, I don't know if you've heard, but it's very stressful. The light just came off. PA school is very stressful. It takes a lot of time, takes a lot of effort. You end up losing sleep. You end up giving up time and weekends.   So not to make you depressed, but my point is PA school isn't really unique in that it's just a giant stress in your life like many other things. And if your relationship cannot handle PA school, maybe it won't be able to handle other big stresses in your life. Like COVID, I think the divorce rate just just spiked during COVID because there was so much stress and so much stuff going on and a lot of relationships were really stress tested and just didn't survive. And maybe that's a good thing because when you stress test something, it either breaks or gets stronger or you know that it is strong. So if the relationship didn't survive because of COVID or because of PA school, maybe it wasn't meant to be anyway because it just couldn't handle that stress. And it's just a matter of time until some other kind of stressful thing happens, and then it breaks, you know, and you just wasted all that time and effort and hope for the future and stuff, only for it to break later. You know, so if your relationship doesn't survive PA school, see that as a blessing because it just wasn't meant to be, you know what I mean? And if it does, you know, conversely on the other side of that coin, if it does survive PA school, maybe it was meant to be or at the very least maybe that is a testament to how strong your relationship is because it just survived this massive really, really difficult thing, you know, so maybe that's a good thing. And the last thing I want to say, I think this video is going to be really quick just because I don't have a whole lot to say on this. I'm not like a relationship expert, not really someone who like gives a relationship advice. It's just not something I do, but it was an interesting topic and I do obviously have some experience with it, so I wanted to kind of give you guys my answer.  And one thing that I've heard over and over again, that's told to people who are starting PA school is this. You have to kind of sit people who are important to you down and tell them and make them understand that these next two years or three years, however long your PA school program is, these next couple of years are going to be selfish. They're going to be very selfish for you because you're doing something that requires a lot of time and a lot of effort and just a lot of you. So if those people are used to you being present, giving them time, giving them effort, seeing them, taking them places, doing things for them, whatever it is that they're used to you being in their life for, maybe for a short period of time, at least they won't have that and they have to be okay with that. They're not allowed to guilt you. They're not allowed to pressure you. They're not allowed to get mad. They're not allowed to give you crap for you not being there because what you're doing is big and important and special and it's you living your purpose and it's not forever. It's just for those couple of years. That's why it's a selfish period being a medical provider is a very altruistic. It's not a selfish thing at all because it takes a lot of effort, but it can be seen as selfish because you just have to study. You have to sit by yourself. You have to do all this stuff that seems like you're doing it for yourself. You know, you have to get the grades. You have to pass PA school so that you can become a PA, but you're becoming a PA to help the world and live your purpose and really like help your community and just be a good person to do good work for other people. So it's not selfish at the end of the day, but it can be perceived as selfish because it seems like you're doing these things for you so you can become a PA.  Look, for these next couple of years, I just straight up will not have a lot of time, energy or effort. And even if I am physically present, I might be so drained mentally that I just, I will not be able to give you the time and energy and presence that you might be used to getting from me because all my energy is going to be put into this thing that is very, very, very difficult to do and very important for me and very important in me living my purpose and making the world a better place. Okay, so I just wanted to explain that piece of advice because I think it's excellent. I think it's very important. What you're doing the next two years is important. What you're doing the next two years matters. And it might seem like it's selfish to people who are used to you giving them effort, but it's not. If they love you, if they accept you, they have to understand that these next couple years are just going to be you focusing on this one big thing, first, second and third priority and everything else has to come after that. It just does. Hopefully that was helpful to some of you about the topic of relationships in PA school. Let me know if you want me to talk about this in any other way. I don't really know how much credibility I have on this because my, like I said, my relationship did end during PA school, but at the same time, I think that does actually give me some credibility to talk about the topic. If you agree, you know, like the video, let me know what you want me to talk about and I'll see you guys in the next video.


some more monitoring back to the monitoring part of our talk and we're going to be doing actually a Q&A session with our monitoring authors later on in the session. So this is Manan Balala, he is coming from Delhi again. He has worked both with not-for-profit companies and for-profit companies so he's seen it from both sides. Today's talk he'll be giving a little bit of experience from his for-profit work on tooling and monitoring for performance critical applications. So please welcome Manan Balala to the stage. Hi everyone. Just wave if you can hear me at the back. Awesome. Alright so thank you for staying back. Hope you got enough coffee and energizers to keep you going until lunch. This talk is about monitoring. My name is Manan and that thing below is the Twitter handle. I'd love some feedback on this talk. I'm trying to constantly improve it. So please if you have any feedback for this talk, write it there and that'll be great. So yeah this talk is about monitoring but it's not about monitoring in any generic context. It's in a very specific context, the context of a large online retail shop, an e-commerce website and we'll see how that changes the equation. We'll see what sort of a monitoring tool we'll need when it comes to an e-commerce website. Have you begun recording? I hope. Alright so yeah it's about monitoring in an e-commerce context. We'll also look at trying to conceptualize the entire monitoring system into phases and we'll see we'll try to divide it into phases and each phase sort of warrants its own tool. There are certain tools out there which cater to more than one phase but hopefully after this talk if you see a tool you'll easily be able to map which phase of monitoring setup does it sort of go in. Right so first a brief about Auto. Auto is a large online e-commerce retail company. It's based out of Germany. It's the second largest e-commerce company in Germany. Amazon basically surpassed Auto in 2014 before which Auto used to be the biggest. A little bit of history began post World War II when this guy decided that he wanted to sell shoes and he took pictures of shoes, pasted them on a catalog, photocopied 300 copies, hand delivered the catalog to the local areas and the orders came in, he delivered them. Over time the guy built enough loyalty that today Auto is the largest mail order company in the world. It's the second biggest e-commerce company in Germany, operates in more than 20 countries. The net net worth of the Auto family is about 18.4 billion and of which about 4 billion comes from from from retail. A big chunk comes from their real estate business as well. That is the Auto premises. This is where I was working with them and essentially so that that campus is about 205,000 square meters. For those of you who aren't able to see how big that is, it's roughly 35 football fields, true football fields put together. It's pretty big but when we talk about scale at Auto, that's definitely not what we're talking about. We generally talk about their online shop Auto.de which records about a million unique visitors every day and about two orders happening every second and given those statistics which are public statistics, we could extrapolate and say that if it takes these screens to place your order, that by the way is the home page of Auto. If you say it's fairly simplistic if you compare it with the Flipkart and Snapdeals, that's because they appeal to a very different persona than what Flipkart or Snapdeals sort of appeals to. They like to keep things simple and that's basically their selling point. But basically if it takes these screens, you pick and pick a product, you add it to cart, you later on you proceed to check out, it takes about eight screens to get your order placed and if one in 30 customers sort of convert, we can say it's about 480 page impressions happening every second. We saw that Auto has their own big billion days and they call it boom days, translated to English, basically in German it's something else. But on these days we saw roughly 1,000 page impressions every second. By that statistic, I'm not really trying to sell that this is large traffic. Of course, there are companies with much larger traffic and facing much more visitor inflow as compared to Auto. But the thing that makes it unique is, so when it comes to e-commerce, the thing that makes that unique is because we're talking money. There is no other context in which it is more easier to relate downtime with direct losses. So we had these numbers being thrown at us that okay, for a one minute downtime, you just lost us 100,000 euros or something like this. So it's very easy to sort of connect the loss value. So essentially we don't want to do anything that affects the money we're making. So we want to maximize that. We want to sort of offer an optimal solution which keeps inflow coming. We want to continue building more features. There are great features coming in, everyone trying to get one up over the other. But we don't want to build any features that don't tie back to the original point. We want to keep building features which add more value, which in turn basically bring in more money. We need to make better decisions and we figured out that whatever features we are building can give us enough insights to basically decide how to go about fixing a bug, for example. So say there's something broke in production and someone coming to you over the top of their head, they just say, hey, this is a massive failure. We need to fix this now. Unless it's backed by real data, unless you know how much of your users are affected by it, it's really hard to judge what sort of priority to associate with it. So it's very important that the monitoring setup we have equips us with an understanding of how big of an impact something has. Lastly, we really want to verify our business assumption. For this, I'm going to take an example. Let's say we were a little late to the game and we decided that we now need to personalize our e-commerce shop. We said that if we personalize one user out of three, we basically expect a revenue increment of X. We make this claim. And using this claim, we're able to sell the feature to the business. And we basically are able to begin development. So on. So forth, we develop the feature, roll it out. And it's great. Everybody's happy, except we never go back and verify whether the claim we made is actually are we performing at that optimal level? So are we able to personalize one and third of users? And without that, it's really just not making any sense. So we're developers. It's not our job to make up numbers. We need to base our numbers on hard facts. And that's what our monitoring tool should give us. So what do I need from my monitoring setup? I need what every other monitoring setup does. I mean, there's no discounting the fact that you need basic database monitoring. We need to know if our queries are not performing well. If basically maybe we need to add an index, maybe some queries are slow, maybe we need to shard. And our monitoring system needs to tell us this much. We need to monitor standard server metrics. Every monitoring tool does that. We need this too. What's our throughput currently? How many requests are we serving? How many what's open connection pool count and whatever, right? And we want to be alerted upon exceptions, right? So this is a no brainer. We need all of this. What we also realize is that what is really important to us is also to measure the state of the system. And while this is a big statement to make, what this essentially means is we want to grasp how the system is performing, not just an infrastructure point of view, but from a business point of view. For example, your website may be performing very optimally at one a.m. at night, but there are no users there. So essentially, you need to know what's happening, right? So it becomes important to also track these other metrics. And for this, we turned over and we said that, okay, let's just ask the product team. Let's just ask the business teams how they would measure the state of the system. And so this whole all of this agile jargon, what it's done is it's broken through those walls. Now you can communicate, right? And they were equally shocked. They were like, okay, thank you for coming to us. Yeah, we'd like to define our e-commerce system using orders per second, and users who are on the website. We're like, okay, these are important metrics, we need to keep a track of them. And so we realized there's essentially two sides to monitoring. There's monitoring of infrastructure, which ensures that you're offering a stable and optimal performance. And then there's the business side of things which measures key performance indicators. Lastly, our monitoring tool should definitely allow us to narrow down when something's broken, to narrow down on the source of the bottleneck, narrow down on the source of the bug. And the thing that helps us here is continuous delivery. For example, with continuously deploying your code on to on to production, what we've essentially achieved is the marginal difference between the last deployment and this one, this change has become smaller and smaller. So it's become much easier to track down what exactly broke something. And it's it should ideally become that much easier to fix it. So our monitoring tool should leverage that. Right? Lastly, tying into the last point, we want to validate whatever business assumptions we set out to achieve, are we achieving them or not? And that brings me to logging. So logging is great, right? Where we developers, we love logging, they point out the exact source of the problem, exact line number down to the character. And they tell you exactly why the error happened, what sort of error happened after the error happened. And that's the inherent problem with logging. So it's inherently reactive. When I get a log based alert, I sort of feel like I'm on this planet, which is about to explode. And somehow I need to figure out something that fixes the situation. I mean, I'm not saying the logs are not good. I mean, logs are great, right? If it weren't for logs, I would probably be having beer on the planet, like I wouldn't be doing anything on the planet. But at least now I know that there's something wrong. But I mean, what about the time leading up to the point when it actually broke? Could I have known that this is going to happen? So that's why I feel that perhaps if you're building a monitoring system today, you don't want to base it on logging. You want to base it on something more explicit. So one more problem with logging is the share signal to noise ratio with the with distributed systems, microservices, the number of systems have grown, their logging has grown. Of course, you have great tools, splunks, kibana, elk stack, all good, very easy to track your logs. But for a newcomer to the system, it's very hard to gauge in a glance what's happening in the system. So even with all these tools, the signal to noise ratio with logs is just terrible. So I like to define this. So if logging is about scattered incidents that happen in the system, accidents that happen at the system, we figured that metrics explicitly collected metrics about the system help you in understanding the state of the system better. And they allow you to gain valuable insights. But the biggest advantage of explicitly collected metrics is that they give you insights at any time. They don't necessarily give you anything after something's broken, but leading up to that point, they're excellent sources. So we we went forward with basing our entire monitoring system on metrics and and proceeding with that. And so we we so this is where we actually get to our monitoring system, which can be divided into four phases. Our first phase is the collect phase where you essentially gather the data. And I'd just like to begin with the disclaimer. We want to gather as much data as we want. But only if it is going to give us any useful insight. It's very easy to collect all the data out there, except you'll be running out of disk. And secondly, you'll just be increasing your clutter. So try and be reasonable about it. Right, so when I spoke about metrics, I was talking about this metrics library. It's a library written by code code, and I think he presented it at a at a meetup. And there's a talk about it called metrics metrics everywhere. I strongly urge each one of you to watch that talk if you haven't already, it's an excellent introduction to the library and why the library essentially makes sense. So metrics is a library that you plug into your system. And it runs with your code, you instrument it in code. And what you're able to achieve is to get collect data while your code is running in production. And that's its biggest selling point. So ours was a closure project, but the metrics port exists in there's Java, there's a Scala port. And I believe there's there's similar solutions available in most languages. But yeah, we figured that it was as easy as just including the dependency. And then there were three parts to it. So first, you have to create a registry or registry is nothing but a container for your system. So if you have a microservices based architecture, each microservice can have its own metrics in its own container. Next, you just create what sort of tool are you going to use from the metrics toolkit gives you five tools will be discussing each of them in just a little brief. But essentially, in this case, we're using a counter. And a counter basically is good when you control when something is increased, decreased, opened or closed. So a counter serves a good purpose here. And finally, it's all about just instrumenting it in your code, just increment the counter where you see things where you see something opening or whatever. But essentially, you know your code better than any third party tool. So that's why this makes sense. This is much more explicit than a third party tool saying, Hey, let me do all your monitoring for you. So the first tool is counters. As I said, it's great if you control when something's opened or closed, particularly good when you want to check connection pools, okay, how many connections right now, open it, increase, close it, decrease. Gages are great if you if you're relying on a third party or an external source, you want to gauge its value at every moment and you see how its value is changing. For example, if you're relying on a certain disk space, you're using Redis, you want to keep track of how the Redis memory is changing over time, you can use gauges. Metals are great for tracking the rate of something. So for example, if you want to track how many requests they're receiving per second, meters are a great tool. While these were good use cases for these tools, we found even better use cases with them tracking actual business metrics. For example, something like counters can be used to track the number of users you're personalizing. And it's as easy as if I'm giving any personal recommendations at all, just increment the counter. And later on, you can visualize how many users are you personalizing? Are you personalizing more than you were just a while ago? Are you not? Similarly for gauges, if you have like a cache of products with which you do a lookup, and you base certain recommendations on that, and you see those recommendations underperforming or overperforming, you can directly correlate. Okay, so the gauge tells me that the cache product count was too little or too much. So that kind of gives you an insight into why a thing is happening. Similarly, meters can be used to track how many orders are being placed every second. And the next one's histograms, histograms are particularly good if you want to measure the count of something or the frequency of something and how that changes across time. So you can check, okay, if you're offering a response, how does the response size change? For example, something goes down, maybe you don't have, I don't know, database or your query gets messed up, your response size just reduces drastically, and you can easily tell. But we'll come to a better use case of this, which is how many of my customers, what quantile of my customers are getting five personal recommendations or less? So essentially, histograms allow you to measure quantiles. What is the main number of recommendation that you're serving, which is an average, what is the median? How many recommendations are 99 percentile of your users getting? So that's worth, so it gives you a lot of insight. Timers are great. Timers essentially have a meter built right in and are able to measure how long it took at that level, at that rate. For example, you can measure page rendering time and you can correlate it with how many requests I was getting. Similarly, a great insight is okay, it took me 80 milliseconds to give recommendations to 99 percent of my users when I had 200 requests per second. But the moment my requests became 800 per second, I suddenly started taking 200 milliseconds. So there's a problem that the timer is pointing out to you and we can take action on it. Again, implementing them in code is fairly straightforward. It's depending on your language, it's always just one command, one line of code or something. So now that we've collected all this data, we want to make sense of it. First, we want to store it somewhere and the choice of storage solutions has been increasing. Luckily, all of these metrics are time series based data. So what makes sense while storing them is a time series database. Of course, a great number of solutions were being discussed today morning and one of those solutions is graphite and others in flux DB. Mostly, all of them sort of have an architecture similar to this one. You'll have some sort of a backend storage where they would be using some sort of database, maybe a SQLite or maybe a different file system all together. They would have an API which gives you a queryable interface.  And then they all have a layer in between, which is your true metric storage, which takes the pain of compressing or also helps in queries. Of course, with metrics, they arrive at a very tremendous rate. They're just a lot of metrics that you gather. So it's not optimal to write them all to disk. So that's why usually the solutions have a cache built in where the data goes first and is regularly flushed to disk. And when reading, you essentially fetch from the cache and from the disk. So you maintain a certain recency. Just some of the characteristics of a storage tool would be it should have a good query DSL. In this case, I think influx is a good job. They picked SQL, which everybody understands, graphite not so much because they picked something like just pure strings and you have to apply mathematical functions strings there. Query editor is pretty prone to mistakes and everything. So yeah, well, take your pick. It should give you the ability to apply functions. So essentially, you want to apply mathematical functions because the same metric may give you different information based on what function you're applying. And for example, a counter may give you a current count of open HTTP requests. But if you check the slope of that talking statistics here, but essentially you check the acceleration, the rate at which the counter is growing, you can easily check, okay, request per second just increased. So essentially I'm facing some traffic now more than before. The solution needs to be scalable. Again, the metrics are coming at a tremendous rate. So whatever solution you have should be scalable. Graphite says it works in distributed. I didn't see it working so much, but maybe there are solutions that works better than that. The data or the query results should be up to date. It's very important. Otherwise your graphs would be just completely silly. Right, and this is a great note to read. The influx DB, how their journey has been. First, they started with using level DB to store their metrics and then they proceeded with a different data structure altogether. Today they use time structural mergers. It's a great block person. There's a link down there. Hopefully you will get it when we share the slides or you could just check it on the influx website. Now that we've gathered all this data, the next phase is to visualize them so that we can finally draw some insights out of the data that I've gathered. And for this it's very important that I'm able to drill down into why certain things happen. So any visualization tool that you use should allow you the capability of drilling down. It should be interactive. I should be able to read what a value of something was at that very instant, what happened at that point. So it should have a good query language and editor, which is not prone to as many errors. So essentially it would be good if you use easier syntax. And you should be able to correlate changes in metrics to certain events that happen. I think this was also discussed today morning when we discussed our annotations feature in Grafana. Similar features may be offered by other tools as well. So given that we need all of this, present to you the oscillator. This is a tool we wrote. It's a D3 based tool. It's written in closure. Of course you may like the language, you may not like the language, but you sure can like the tool. It's very easy to implement a chart. It's very declarative and the charts are highly interactive thanks to D3, which of course is a great library. But the advantages that you get is you can define your charts in basic just data. So for example you can have a simple map defining what your chart is called, what your page is called and what charts it has. So you define tiles and you may have multiple charts on one page. We'll see a demo soon. Essentially each of these tiles, each of these charts you can choose what kind of chart you want to show. For example in this case we're showing just my user requests. I'm pointing it to a graphite target in this case because that's what we were using when we wrote this presentation. But essentially what we also open source was a graphite DSL.  So this minimizes the chance of making an error. So I have a small demo. So it's a random generator that I have and it's generating one request or the other and I'm sort of plotting the count of these requests. If you check the chart it's fairly interactive. At any given point in time you can sort of compare what the value was of one particular type of request and what the value was of another type of request. Moreover you can drill down into the timelines. Essentially you can see what was happening in the past one hour, what's been happening let's say in the past 24 hours. Well it was an application running on my local system which is why you see the brakes. Hopefully your production system does not suffer through the same. But yeah, so essentially you can drill down into timelines. You can also have summarization. So how has the trend behaved? If you summarize over a 10 minute scale. So it seems to be going down a bit. You can also have on the same oscillator you can have all your environments. Essentially you can have your development environment. You can have your pre-production or what you define what your environments are. So you can have as many as you want. And then you can kind of hide one, only see one. You can have as you like. You don't just have line charts. You have all sorts of charts. You can have bar charts, pie charts if you're into that. Maybe stacked charts if that makes more sense. Another great feature is again annotations. So these are events that significantly change something in your application and may lead to variations in these metrics. So it makes a lot of sense to have them on the same graph as the metrics visualization. For example those dots down there kind of point to what happened at that instant that the graph changed. And so it becomes easier to correlate. Okay there was a code change, there was a deployment, there was a provisioning. You can easily correlate why the change happened based on that event. So I had a few learnings based on this sort of flow. The first was to choose the right metric and the first thing when someone talks about monitoring is hey let's just plot the CPU load. And I was often left out of that conversation because I honestly did not know what goes into calculating the CPU load. And so I googled and I figured out that the formula to compute a CPU load is actually very complex and you don't want your metrics to be as complex as that. I googled further and I saw what spikes the CPU load, essentially what makes a CPU load spike. And I figured out that there's this post that says if you're parsing text often times your CPU load will spike which is odd. If my application requires to parse text I will be parsing text. What is a CPU load plot giving me? So essentially choose simpler metrics, metrics that point to exactly what's happening. For example disk utilization, user logins, simpler metrics. Again the second learning was that plotting a mean value of something may be absurd at times. For example we had a contract with the herd party that we'll give them recommendations and they can show them and we had a contract we'll serve in under 50 milliseconds. And when we actually saw it on our graph we were serving in under 20 milliseconds and we were happy. We said okay so that's pretty cool. We were well below 50% of the threshold. So that should be okay. Until they came back to us and they said they're running into circuit breakers and this is you're often going above the limit and that's when we realized what we were seeing on the chart was actually mean and average value. When we plotted against the max which is the max value in every summarization interval. For example the max value in every minute we see a graph something like this. So essentially we were easily peaking over 100 milliseconds every minute and that's why the team was kind of running into circuit breakers. So just choose how granular you want to be. Just don't pick mean because it just sounds cool. So yeah choose wisely. It's important to choose the right tool for the job. Histograms are particularly good. If you want to measure the size of something, the frequency of something, how that changes. And the last phase of the monitoring setup is alerting because we all want to go home and sleep at some point in time. So essentially we don't want to keep added. We don't want to just keep glancing at the charts. So and when it came to alerting again we being the team that we were we didn't like any of the solutions out there and we wrote one ourselves and this tool is called x ray. It's essentially again a tool written in closure in which you can essentially define your condition for the failure of the alert in a simple function. So you can have a function saying if this happens, if it returns true, it's all cool. If it returns false, alert me. And then you can define what sort of alerting strategy you have. Do you want one alert every five minutes? Do you want if it's continuously breaking or do you want to be alerted on each instance of the condition breaking? You can also define what what sort of alert you want to receive. You can have slack integration because it's all code, right? And that's what the advantage you get from having explicitly written down solution. So you could have a slack integration, any sort of emails or text messages. I don't think you want to go for that though. But but yeah, for example, in this, we're simply logging and you can change whatever you can pretty flexible.  This is the middle level. And I've had to blur out the names because it was a live system. I can't share that. But essentially you have all your environments and how the checks are performing on each of those environments. And you could basically drill down into the ones that are read and check, okay, what exactly happened? What was the expected value? What is the value we got? You also have a higher level chart which sort of aggregates all of this and gives you whether the whole system is behaving okay or not. So yeah, we thought it was extremely high importance. Early morning in our standups, the first thing we used to do was decide what's going to happen in the rest of the day based on these alerts. What is the value of the alerts we're getting? What happened over the night? We added these to the definition of done of our story. So any, any new feature that you're adding would not be complete until you add the relevant alerts or change existing alerts as required. We wanted to make it as visible as possible. In our case, we were able to provision a nice little monitor and Slack notifications to ensure. But at the same time, you don't want to spam anybody. So try and choose the right alerting strategy. So the entire solution kind of looks like this, you capture your metrics, you aggregate them, store them in a nice time series database, visualize them using some sort of a graphing tool. And finally you alert and you choose an alerting library for this. There's plenty of solutions that offer all these four phases, the tick stack on what not this, there's enough solutions. But yeah, I mean, just you can take your pick for each of those phases. Just last note on continuous delivery, as I mentioned, since the marginal change between deployments has become so small, it's become increasingly important to find out what broke something. For example, there was this one instance, where we noticed one graphs just shift drastically. And what we realized was we had a deployment. But since the last deployment before this, there had been only 10 commits that went live. So if it's just 10 commits, it's very easy to kind of find out, roll back 10 commits, apply one commit at a time, see which commit broke. So it's a matter of practice as well. No monitoring tool is going to allow you to really do wonders without you following some sort of etiquette. And I think it's important to follow the etiquette of continuous delivery, especially in a retail shop where you constantly want to release features, you don't want to hold back the teams. And a note on software that claims to monitor everything for you, it just seems like they know your system much better than you know your system. I don't know why you want to go for, why would you want to go for something like this, especially because some stack that we saw, there are like 100 alternatives to that, all of them free. Why would you ever want to choose something that doesn't even know your code? So the only way I can think of they could do monitoring is by hooking into individual function calls, I could be too expensive, both performance wise, as well as monetary, because they charge an exorbitant piece. And so really, I mean a great monitoring setup is available for free, really no need to go for such solutions. These are the references that I talked about. The first one is a great talk. Again, if you haven't seen it, metrics, metrics everywhere. The oscillator is available at that link. It's on GitHub and the x-ray, the alerting library is available at the next link. I urge you all to follow the Autodev blog where they publish excellent things about how they're changing their architecture. They're one company that's keeping up with the times and essentially doing great with all of that. That's all I had. Thank you. Does anybody have any questions? Oh, yeah. I have a question about design and how you cascade elements. Because we've got too much knowledge that you can't get it up in actual calls. So we fell into the trap, as well. Honestly, we faced enough lack for that. So initially, when we built the solution, we were spamming everyone. In fact, we were spamming more than just our team. We were spamming even like the organization. So we faced that trouble. Essentially, we left the choice fairly flexible because you may want to categorize based on the priority of the alerts. Since it's all in code, it was a little easier for us because we could essentially see, OK, this particular alert, if something happens, I do want to be alerted and this particular alert don't. On the other hand, you could also have summarizations. OK, I want to be alerted if this thing happens continuously for five minutes. If it's a one-off, I don't want to be alerted. But really, I don't have a perfect answer for that. It's it's really a gray area. But we yeah, we fell into the trap as well. Where are you? Oh, hey, I'd say we really did not. We really did not focus on building a product that was different from Grafana. We think both are great products. Honestly, at the time that we built the oscillator, Grafana wasn't as mature as it is now. That being said, we would probably have still done it anyway. We we love writing explicit charts in code. We like to have more granular control with the language that we are using. I guess those could be the reasons and writing something yourself all the frowned upon. But for larger enterprises, sometimes it makes sense because it offers you the flexibility that no prepackaged tool could offer you. Hello. Yes, hi. So from the top, it looks like the matrix, the library which you're using. Idea is to infer the lot of details from the code rather than from a log file and push it to a system. So what happens is like in a web application at an endpoint, you interact with like 10 other different system and collate the result and finally present to a user. As a result, what happens is like you have two places to infer the information. For example, my web application can infer how much does a recommendation engine took the time. So I can put what to say like inference point at that web application level code or at the inference engine and later you can push to the system. So which style did you follow and is there any reason to choose putting everything at a web application level all at the final system level? We had metrics on both. We were collecting metrics from both. Essentially the rule of thumb that we followed what Kodohil also mentions in his talk is every microservice may have maybe should be capturing their own metrics and you may have up to 30, 40 metrics from each microservice reasonably sized microservice of course, we often go above board. Yeah, I don't know, we just I guess it's one of those separation of concerns thing. The web application did capture these metrics for a third party that was not written by us because we did not have control over them and we did want to measure how that third party is behaving so that we could communicate effectively. We went ahead with the approach of just having every service have its own metrics and container kind of thing. Thank you. Hello. Hi, this is about collecting data on only useful data part. So how do you choose to collect useful data? I understand the intent behind that statement but there's also this fear of missing out and have you run into any situations where you actually missed out on some useful data that might have led to say a new metric? Of course, obviously. I guess what I'm trying to say is yes, you should capture nearly like everything that you think could be plotted on a chart but definitely not something like okay, what's the CPU load at the time? That's why I kind of tied it to the end of the presentation as well. Capture metrics that are simple that really offer you some insight into what's going on into your system. Of course, we missed at times capturing useful insights. At times it was hard to even keep the charts updated because there may have been a change in the feature after which the metric also should have changed accordingly but did not test help us in that situation. I guess that's not your question but yeah, again, that's a great area. We ran into that trouble. I guess you can aspire to be as vigilant as possible when you're building a new feature.  Just do it. But yeah, there's no black and white. I had a follow-up question to that. So when you said that you captured business metrics as well as infrastructure metrics, would you say that looking at the business metrics daily is kind of the only important thing and if there's something wrong with the business metrics then you go into the infrastructure metrics, not otherwise? Why would you say so? So essentially something like if I'm using a Redis, I wanna keep track of how much Redis is filled or for example, have I expired too many keys to suddenly? Am I done? Sorry. Okay. So yeah, so I guess we were keeping track of any of these charts. But by the same logic, if suppose you have Redis at suppose 90% full capacity but your business is going as usual, there's no problem, right? Oh no, you may run out of capacity then your business will not be doing good. That the trigger should be the business related metrics. That's kind of what we're doing. So essentially the entire intention is to not let the business metrics be affected, right? There may be business metrics that tell you that or there may be infrastructure metrics telling you that. So okay, people who want to ask questions can stay back. We'll have speakers Manan, Pooja and Burnt to answer your questions on the stage. The people who are not really interested for the Q&A session can proceed for lunch. So we're taking more questions but combined for all three speakers. Pooja and Burnt, could you please move to stage? So we're up there? Oh. Hi. Where does it happen? You're free, right? What solution? It could be for long-term. Okay. It could be for long-term. Sure. Okay. Well. It could be for long-term. So the first part of your question was how do we get developers to be motivated to maintain the code that they've instrumented just for capturing metrics? So essentially, this is a culture change, right? In this case, we were the driving team. We were the team that went to the business and saying we think this makes more sense. I guess with Agile, the entire point is that everybody's kind of contributing and you don't sort of work in silos. But yes, I do understand that there are teams and there will always be teams which have a clear division and that makes sense for them. But in this case, it was not. So we chose to be explicit and maintain the code. We took that call that we will be happy to do this and the benefit we got was flexibility. The benefit we got was we don't want to actually monitor something that we don't really care to monitor. So I hope that's some sort of an answer. I'm happy to have this discussion afterwards as well. Hello. Hey Manan. Hey. I'm from Goldman Sachs. Sorry, I can't hear you. I'm Pawan from Goldman Sachs. So this is a specific question to process monitoring. So I just want to know what was done in auto or in your space for critical process monitoring because say a process is down, your order rate could go down anytime and if a host is down. Can you put the microphone? Did you get the question? Hello. To some extent. So I think he's asking about critical process monitoring. Right. Go on. Is it him now? Oh, sure. OK, sir. So yeah, so in certain cases there's a host outage and you have a barrage of alerts of process being down and you have to deal with that. So was there any intelligent solution that was kind of adopted? I guess it's not really related to this talk but we essentially implemented something like circuit breaker so that even if some third party or some critical process is down, we still fail gracefully. But yeah, I mean, some would argue that if your critical process is such a critical process, how graceful can you be? To be honest, I was not able to get the question. I'm sorry. Sir, he's asking if a critical process goes down, some sort of outage. So how do you handle that? So your entire order processing is down. What sort of thing can you do to sort of manage or circumvent the entire problem? So in my opinion, also that process is part of an application. Means you can simply monitor if the process exists but it doesn't help. But at the end it should have an effect on an upcoming service and then getting to the root cause you figure out. Means if you think about the first talk going from the top down, thinking about your business as an impact and then seeing what application is responsible then perhaps a process is not working. Means also that it could be fine in the process list. Doesn't mean that the process itself is working. Means process monitoring itself could be easy. Means is the process alive? But how many of them are allowed to be alive? How much memory is consuming? It's probably hard to answer in a single sentence. It could be a complex topic. It is. Yeah, I'm certainly thinking so. Thank you. I think your mic is off. Okay, I'll repeat. So you're saying that it could be expensive to put. So if I understand your question correctly, what he's asking is, so with instrumenting these metrics in code, what if the code itself is unstable in some way? And so saying that if the code is unstable the metrics would not be gathered. And be with respect to purely with respect to performance. In terms of, you know, you're collecting metrics through a risk, imagine a web application like yours. You're collecting metrics through a risk, request is once lifecycle, right? That's going to be expensive again. You would rather sort of push it asynchronously to another system. Okay. So metrics does not push events directly. It does do batches and it won't push every event. So then your infrastructure is probably they're not state, it's very stateful, right? Because... Oh yeah, so there's a chance that if your application goes down you lose certain metrics. Yes, that is true. And it's a strategy that you could go for or you could choose to do one metric at a time which would not work well, I'm sure. Because metrics come at a very high rate and it's better to actually batch them. The second question on that is that every time you want to collect newer metrics, like you have data, let's assume for a moment you have a lot of data, you want to collect newer metrics, you're going to instrument your code every single time to sort of collect newer metrics as opposed to me sort of extraneously collecting that in some fashion, right? I mean, just a question. Yeah, so we thought of it as a part of developing the feature. We did not think of it as an external, I want to collect metrics from a feature that is already there. So we said every feature that gets developed has the metric collection part in place and that is the response way. That is part of the story, part of the feature. So we did not... No, I was just trying to understand philosophically what was the thought process behind doing this which is doing that. We just favored flexibility. So essentially, we don't want to collect certain metrics. We choose not to collect them. And there's an aspect of testing but I guess it could be frowned upon but we tested what metrics we are gathering as well and you could do that because they're in code. Well, let me... I guess I did not say it's not important. I said that you won't be able to get meaningful insights if you see a change in CPU usage. It's, yes, it's important. And I'm just saying that if your CPU load drops, what is that really indication of? So as I understand, CPU load is a function of not one thing. There's multiple things that can bring down CPU load, bring up CPU load. So it going up or down may be caused by five things and you're not pointed to any of those five things. So that's why we chose to go for simpler metrics, which point to only one thing going up or down. But it's certainly not important. It's important. It's just not easily intuitively trackable. With this one, yeah. So essentially we have systems in production, right? And we try and maintain them such that they don't go up to failure. So without having them go up to failure, how do I know what sort of capacity I can get? One, and is any system available which would help me identify bottlenecks in my whole architecture because not everything scales linearly? So maybe right now I can see that everything can go to X, but one of the whole stack will fail much before that. So is there somewhere I can have a dynamic bottleneck identification? So starting with the last question again, are you talking about seeing more services, building an application in a combination? Means having a rule for them? Means that a service consists of others? Or are you talking about the user story question we had before? Means seeing that a specific user request has been- Yeah, essentially, even a very simple web application would have, starting from the load balancer to the application code, to the caches to the databases. Okay, one good way to do it is if you use in a metrics database, so forever influx or graphite, that you put Grafana on top, and then add different sources from different services.  Means it's just a simple idea. But then you can bring all metrics together at the same time, which is an advantage of graphite. Means that you combine different things and also adding to his answer is, then also perhaps load monitoring makes sense. Load monitoring, process monitoring with the correlation of an annotation, for example. To see, okay, we changed something with Puppet and then my load is increasing, then it's available information because you see I have a different load profile, but without any information, it doesn't help you because you can see, okay, no, we have more load, but what now, shut down, reboot. With the annotation to see that some code changed or you see a commit message, for example, depending on your continuous delivery workflow, you immediately see what's happened to a specific part of the infrastructure. Means you can see that a user request, at 10 o'clock was going well and at 11 o'clock after, I don't know, deploying some new software, you see an increase of load at the application server after a request and combining these metrics on a specific time, you can see that some performance profile changed and that I think could be a way to solve it. Okay, so follow up question. What about any way of finding the current bottleneck? Say the whole structure keeps dynamically changing and the code keeps changing. Maybe I'm currently making one database call and then I want to making three different database calls. So in the whole development cycle, can I have an automated system that would tell me in the current scenario, this is the peak load you are able to provide with your current setup? It's kind of a base lining that the monitoring system learns what the load typically is at five o'clock in the morning. I say I just want the peak capacity of my system. Okay, means you would like to know what the maximum number of user requests is. So I'm not on a cloud infrastructure. Yeah, that depends on so many factors. So it depends if your system scales in a linear way, for example, or if garbage collection kills you in some way. So it scales and then it breaks down. So it depends on your, I would say, it depends really on the development language and so many effects. Also sometimes databases scale very, very good in a linear way and at some point, they're not able to write down the IOPS, which is very hard to really promise you can do a specific amount. Means testing helps, of course. There are thousands of testing frameworks also which probably only know 2% of them. But I think it's, I would say it's not possible to say that infrastructure can handle three or four time the user you have right now in the future, except you exactly know what every system involved in that process has a linear scaling aspect. Therefore, I don't have an answer for that. Perhaps you have. Sorry, yeah. I think that's as good of an answer as I can offer. Hello. Oh, thanks. Manat, great talk. Thanks for that and quick question. I didn't know about metrics and I'm gonna look it up. And I keep hearing about tools like Zipkin and all that. Do they play in the same space? Are they comparable? And maybe burned. You can also weigh in it, right? Because I'm confused about the whole aspect about you have monitoring and then you have application lifecycle monitoring or something. So just break that down for me. Thanks. So I'll start and then yeah. So perhaps one can help with the Zipkin if you mention. I am honestly not aware. But there are alternates to metrics. So metrics follows a more push events sort of flow. On the other hand there's tools like Prometheus which have a pull kind of a flow. So essentially your Prometheus server sort of knows where your application is running with all servers and they collect full stator from them. But I don't know about that particular tool that you were mentioning. I'm not aware of it, sorry. Okay, fine. I think these are a class of tools that allow you to trace a transaction across multiple systems. It's more of a, you know. Zipkin? Zipkin, yes. But metrics is more for one kind. It's just one, yeah, I get it. One instance of a, yeah. Okay. I'll ask a question to Pooja quickly. It's probably not related to monitoring but if I understood the whole bot approach that you talked about correctly, right? You had to rely on regex a lot to understand what the user has typed in, right? Had you by any chance looked at natural language processing that are things like api.a that might make it easier? Is that planned? That's the question. Yeah, yeah. Thanks, it's a nice question. Even I had thought initially that we should have some kind of algorithm of natural language processing. But the initial idea was not to go in much details of that. The initial idea was to have a control over the code which was messing up things. And that's where we focused on solving that problem first. That isn't planned but not immediate plans because there are hardly certain questions which are repeatedly being asked. So for example, when is my release? What is there in the release? Which machine I should reply? So there are hardly totally countable 50 questions maybe. So that's overhead to do it at the moment and that's where my priority is continuous integration first and wherein we can actually stop the pull request merge button itself to go ahead. So that's the immediate plan and probably NLP is what is very interesting for me also. So probably I'll have a look at it. Thank you. Hello. Manan, you said don't use any arbitrary measure like me. So I'll just divert here a bit. In whenever you're doing machine learning, so you build models and you will use a couple of algorithms before you figure out which one is best suited your needs or purposes. So if you look at most of the things that we are doing is collecting data and applying certain statistical analysis on that data. So do we have like some heuristic method in which, okay, you apply this statistical model first, see if it works for you, if it is actually getting the patterns out of the data that you want. So is there like step one, use statistical model A, use, okay, not this, use statistical model B, okay, not this. So is there some kind of heuristic flowchart or something like that which you could share with us? If you're using it? And any of you could answer this question. I'll try to. So essentially there's a stream of DevOps called anomaly detection which is heavily making use of knowledge of statistics and applying models. This on the other hand is a fairly straightforward use case. There isn't much derivation that's happening here. Essentially just, yeah, so I'm guessing in this case I am not aware of a lot of statistical models per se that are applied, at least not standard ones. Of course, people might be coming up with ad hoc statistics on top of something, but yeah, but there's a stream of just catching a lot of traction. Of course it's a anomaly detection where you kind of learn from how your particular one statistic had behaved and you kind of make assumptions about whether to alert or not. For example, when it happens again because you can now correlate that this would happen at this time of this month of this day, kind of something like this. That's as best as I can answer, maybe one of you can. I have no answer, but I know somebody who knows it and it's name is Avishya Shalom and you can find a lot of talks on YouTube and I think he's studied math whatever and he's giving crazy talks about math and metrics. I can give you the name afterwards. I don't know how to write it. Can we have? I will have to look it up. Avishya Shalom or something, I give it to you. Okay. So they'll share it with you. Yeah, or on Twitter, whatever. So he's, in his talks are really a good point to start about thinking stats and metrics and he's explaining it very well. Perhaps a good point to start. Okay, I'd just like to remind everyone that we're happy to take more questions if there are, but this is eating into the lunch hour. The lunch finishes at 2 p.m. and the talks resume here at 2.05 p.m. sharp and we're gonna try not to be late. So just to remind you. Now that was it. Oh, food break. I'm out. Yes, I saw your face like you're getting nervous.  Oh, sorry. Oh, yeah. Is your mic on? I, it's hard to, oh, okay. Can you put the mic a little? So you have 100 nodes out of 50? No, I got the question. Yeah, so you want to auto scale? Yeah, so I'm sure it's possible. I mean, yes, I think that is what a lot of providers do. They look at the traffic and accordingly auto scale. Of course, I have no experience doing this and wasn't the subject for say of my talk, but I'm sure, I'm sure. So essentially the tools that we wrote made use of monitoring data and alerted or not alerted based on that. So instead of alerting, you could, you could trigger something else. I'm assuming that should be possible, but maybe, maybe one of you can. Nothing to add. I'm sorry, that's okay.  It's on. Now it is. Okay. Like this, okay. So my question is more about distributed model. So I have a system of tools which logically comprises one tool, right? So my tool talks to a lot of other systems before it can serve a response. It's a general distributed architecture. And these systems interact in different protocols. So it's not like HTTP. Sometimes it may be RPC. Sometimes it may be TCP. So I cannot really weave the HTTP headers and see how the data is flowing. So right now the solutions that we implemented to correlate how a request is served with different systems at a given point of time is to use overlapping groups, group names. So tagging, we're tagging systems with a certain name. Say this is product P1. This is P1's active MQ. This is P1's Redis, probably. This is P1's database. This is P1's MySQL. So when we actually plot a graph, or we want to correlate a graph, we search for the tag P1 and see how all the systems related to P1 are behaving. So in that case, we are actually bound to write, take care of giving correct tags at every point of time. So is there a way wherein I can trace a request that this request flows from system A to B to C to D with different protocols and then have a holistic view without using tags somehow so that it doesn't have any manual dependency? So systems like APM also do it for me, but they are more like only one platform based, say only Java based. So if I go from Java to a different, or go, like a console or probably a Redis, which is written in different language, two systems get, they are blacked out. And it's also very costly to put APM into every system to monitor it. So what do you think? It's like grouping, having overlapping group with the only solution, or can we do something else about this? I don't think there's a tool for that. I don't know. The way you can do it, this means enrich your code base and probably assign kind of a session ID or a random number or a serial number. I know that Flix is doing it that way, tracking their SMS and recommendation action that they gave a talk on Elastic on about that, how they trace a specific request in the infrastructure, means assigning a serial number and then to every lock entry they produce manually or out of a system. The system outside which takes out all the serial numbers and puts them together, weaves them together. But the problem with this approach is that when we have different protocols to talk. So say for example, if a serial number is into my HTTP header and now from HTTP I'm going to a TCP. So I'm losing that serial number because I do not know how to propagate the serial number along with a different protocol altogether. What kind of payload goes through your protocols? So it's like assume a JMS system, I have an active MQ and it has its own protocol, right? So I don't know. I think if you don't enrich your protocol. How do you transfer the session ID? If you don't enrich your data payload which is transferred with that kind of a marker it's hard to identify. I have no better idea. Perhaps, perhaps you? I don't have one. You seem to have already done a bit of research on this. But yeah, I would love to pick your brain on this later. I have no more solution honestly. Okay, thank you. That's it, right? Enjoy your lunch.


So my beautiful people, I am back with another Cyberpunk video and today I bring you yet another 10 facts you need to know about this game. How's it going guys? My name's DP, Jane. If you enjoyed the video, leaving a like really helps me in the channel out and I do appreciate that support. And if you're new around here and want more Cyberpunk, be sure to subscribe. Also guys, stay tuned until the end of the video to find out about my giveaway. Okay, so 10 things you need to know about Cyberpunk. Now if you've missed any of my previous episodes, I think this is like episode 5 now. You'll find the other episode linked within that video description via my Cyberpunk playlist. So let's get into it people and let's start with quests. Now quests have a ton of optional tasks that you can do within them, which means there can be several different outcomes for each quest. Now it is said also that this can determine the certain reward you get for said quest too, which is pretty cool to think about. Multiple quest outcomes, multiple different rewards. Next up, the more you use a weapon, the more you can specialise in it. Now if you guys have ever seen that skill tree, and you'll see the different branches here, to actually level up a weapon you have to use it, which makes sense. But the more you use it, the more you can specialise in it and I love that kind of thing I really do. Okay so the trauma team, you guys know who these are. Well if you get downed and you need reviving, these guys will come and help you out.  Okay so next up you can talk to every single person, every NPC, and you can even get random side missions from random NPCs. Now as we know it said the world is alive with NPCs, and a lot of them go about their daily routines, they wake up in that morning, they go to work, they head home, they live their life whether you're there or not. But just talking to a random NPC, you can get yourself a side mission, pretty cool. Also gun shops can also offer you missions, and you can understand why now they say this campaign can be close to 60 hours, depending on how you take your route to the end. If you want to do all these missions or decide missions, I think it will take you a lot longer. Also people, full damage. Now with cyberware being a thing in this game, we can have plenty of augmented limbs, no doubt is why you can upgrade said augments which allow you to take less full damage, pretty cool. Okay so moving on, and you can undertake vigilante missions to help out the Night City Police Department by foiling crimes, and arresting gangers, fogs and cyber cycles. So you guys want to play the role of a cup? Well you can indeed.  But also, waste someone near a cup or a local gang, or cause enough trouble, and say gang or law will deal with you, but another one. The NCPD might not intervene when you commit a crime in a gang controlled area, which is pretty cool to think about too.  Okay so next up, fixers can and will contact you, but this depends on your street cred level. And also guys, there are some items in stores and from vendors that you can only buy if you're renowned within Night City, i.e. have a higher street cred level. Now if you're not sure what street cred it is, or street cred, it's a type of experience you can acquire by completing side missions, and like I said, it's used to unlock new vendors and content throughout Night City. And even some items guys, like jackets, clothes, whatever, can passively increase the amount of street cred players can accumulate, with like bonuses, unsaid items. Which means if you do a side mission, you'll earn what, 5, 10, 15% more because of said thing you are wearing, so that's pretty cool to think about guys. But yes, 10 plus facts about Cyberpunk, I feel you should know. Now like I said, if you've missed any of my other episodes, you will find them linked within that playlist down within that video description. But guys, the end of the video is near, but before we go, let me tell you about my Cyberpunk giveaway. So if you want to be in the chance of winning this game, if you haven't pleaded it yet, it's simple, drop a like on this video, leave a comment down below and make sure you are subbed. The more of my Cyberpunk videos I see you are supporting, the more of a chance you have of winning. I will announce winners a week before this game releases, so hopefully that is the first week in December. Because as of right now, this game is releasing on December 10th, but we will see guys. But yes, good luck on that if you do decide to enter, and hopefully people you enjoyed this video, hopefully I see you again, and with that, hopefully I will catch you on that next one.


What's going on everyone? Sam here with late in sports cards for 22 puny flawless football hobby 1 box break number 2 Random left side serial numbers. Here is a look again at your ran results as always You can find those on the website under the results tab as well as the link in chat. Let's do it Yeah, Matt Canada would be on the trash list for sure.  God. It was so annoying, dude Good luck here everybody. Let's see something big See something big. That's a good inner man That's a good inner that's kind of wild actually, but we got the guy who's on the track again here Sean that's Jersey number 5 of 15 mr. Drake London grads to the five-spot Viviana Viviana nice one here is gonna be Austin Echler and Ladanian Tomlinson going to the five-spot again 5 of 15 Player Warren Echler very nice Congrats on that one. We've got a one of eight Steve young go into the one-spot Congrats Ben P There you go, Ben Steve young Ben's also gonna get this scary Terry, but one of five that's number and logo patch for the commanders Terry McLaurin Player Warren scary Terry Another one going to the one-spot that is gonna be Johan Dotson on the rookie diamond signature For the commanders one of ten Nice one here going to Kuniaki tea at the three-spot three of five is Christian Watson on the rookie auto can Magnus Watson going to the two-spot How about a juice Landry Jarvis Landry two of 20 that is game worn from 2021 flawless football Jarvis Landry juice Landry the jungle Congrats to Mark D. All right on to our inner now our outer I suppose We've got going to the eight-spot eight of ten is Sean M. Nick Chubb did this spot one absolutely nuclear going to the one-spot that is Patrick Mahomes Congrats on that one of there. That is game-worn Patrick Mahomes really one of two game-worn Patrick Mahomes One of two go to Ben at the one-spot That's that's disgusting man. I Don't know anywhere else you're gonna find my home's game you stuff honestly at this point in time Again you could see Game-worn slash used material One of two and then going to the one-spot again dude one of eight Kenny pick it on the Blue diamond auto congrats to Ben at the one-spot absolutely went like I said nuclear Absolutely nuclear That's what happens on these left side serial numbers man If you hit something that you get like four or five guard unreal It's like getting a personal box of flawless to some degree. All right, let's do a quick recap everybody. That is empty empty empty Case is now gone All right, we've got dual patches of Austin Echler and Lydanie and Tomlinson. That's a patch of Drake London got Jarvis Landry two of 20 game used John Dotson one of ten scary Terry one of five Steve Young one of eight That is gonna be eight of ten Nick Chubb Got three of five that is gonna be Christian Watson Nice one there. You've got one of eight Kenny pick it and One of two patch for my home's game use patch and patch On real dude that is gonna do it for the break guys. Thanks again for getting that filled up Next up is number three


Never have I said the supernatural does not exist not in this debate nor anywhere else and it's dishonest of you to suggest that I have What I have pointed out as I have tonight is that we I don't know of any way to confirm the supernatural I'm not saying Jesus did not rise from the dead. I'm not saying I know Jesus did not rise from the dead because the supernatural is real I'm saying you cannot Demonstrate as far as I can tell that Jesus rose from the dead and the claim that someone rose from the dead Whether it was by supernatural means or natural means is far more extraordinary than that Those two claims cannot be established on the same standards of evidence


Trying to pack on 10 to 15 pounds of muscle the next year. Watch this. Our first caller is Cade from Washington. What's up, Cade? How can we help you? Hey, so I just had a question regarding basically Optimizing muscle growth because so for I've been consistently training for about 10 years with a goal of Just health and longevity, but recently I found myself in a really good spot So I'm about five ten about one fifty four one fifty five So I'm like ten ish percent body fat and I just I don't know I got it in me that I kind of want to see if I can push my body to do something like a Physique competition. So I was trying to see what would be a checklist that I could do to basically optimize Muscle growth over the course of one or two years to put on maybe like 15 20 pounds Okay, this is definitely Justin's wheelhouse. Yeah, I was gonna say I'll go ahead and feel this I think I think there's a lot more we need to know right so I would like to know Kind of what you're currently doing training wise. Are you following any sort of program regimen? Do you follow any of the maps programs currently right now? And if you don't yeah, so I have for you guys programs I have anabolic performance aesthetic and power lift, okay I'm just finishing up anabolic, but I've kind of tweaked it To where I'm still working out. It's not really trigger sessions. I'm working out seven days a week basically where I'm kind of splitting Some of the end of the workout because I don't really feel like I can give The like I'm in the third phase right now So like the super set with the the arm workouts I kind of push that off on its own day with maybe Either a chest workout or a shoulder workout and then do some very light accessory stuff Just to get a little bit more volume. Okay, so you're pretty much falling on a ball You're just kind of splitting it up, which is totally cool I do that sometimes where I split it up on the other days But you're still following what's in the program. Yes So the other question I'd have too is that if you know, if you're a client of mine I would love like a an off-season kind of bulking, you know stretch with you And then we would do show prep and get ready So if I could get like a year of your time I would want to run like anabolic power lift try to pack on as much muscle and we'd do that in a bulk So I at 10% body fat. You're already pretty lean In fact, this is kind of like right when I was in season and off season off season I like to hover right around that 10 maybe I let myself go as high as 12% But I like to keep myself close to single digits getting ready for a show So I didn't have to do a long cut so your body fat percentage is perfect kind of where you're at and I would love to run like a power lift and a Bolic split type of routine within a calorie surplus to pack on some good size for you for and I would want to do that for about three to six months depending on You know where our body fat is hanging around and stuff and then Switch you over to like a maps aesthetic and lean you out and get you ready for the show and maps aesthetic was really inspired by Kind of my show prep heading into a show and and I would start it off Still in like a calorie surplus or maintenance and then towards the you know final six to eight weeks I would transition into a cut and when you're this lean when you're right around 10% You don't need to be cutting longer than about probably six weeks I think that's the mistake that some of these competitors make is they won They allow their body fat percentage to get so high and then when it's time to cut They're doing like these 16 week cuts. I I never cut longer than four to six weeks Because I maintain my body fat percentage about where you're at if you're around 10% You can easily drop four or five percent in six weeks No problem, especially if you got a healthy metabolism and you're in your dialed in so that's kind of what I would want to do with you Yeah, to add to that I'd say a big thing to focus on is gonna be your your calories Obviously want to get about a gram of protein per pound of body weight, but you you should be increasing your calories by about 500 to a thousand over what your maintenance is so do you know what your maintenance calories are? Do you know how much you're eating right now? So actually it's kind of so I've been probably about three four months now Where I've been just like intuitively eating. I have a good idea that I'm around Anywhere I mean it fluctuates, but I could be anywhere between like 27 to 3000 calories and I've actually been basically recombing for a couple months where I've Consistently seen that I'm a little bit bigger and losing body fat at the same time. So yeah, so estimates are Notoriously inaccurate even for experienced people. I mean I estimate and then when I go count and add things up I find that I'm off by oh, that's me. That's me counting like I have an idea of how much the food I eat is I just didn't like actually write it down. Okay. Yeah, cuz that's obviously that is a I mean That's the first step. So I'm glad you went that way is that you know, if we you and I were working together I would need you to know yeah to the calorie, right? So I mean I encourage people using like fat secret or my fitness pal So we can log it and we can make subtle adjustments. So yeah track it and then once you get the exact number I'd go actually I'd probably go are you are you more of a I'm assuming you're more of a hard gainer than an Easy gainer considering your your body weight and your height. Is that would you say that's fair? Oh, yeah, okay? I would go a thousand calories over maintenance now if you start to put on too much body fat You could always bring it down to 500 over maintenance But I would add a thousand over what you're doing and then you know go back to your training The food is gonna make the biggest difference obviously if you're following one of our programs is probably working all right for you But it's gonna be the food That's the big challenge and if you're eating close to 3,000 calories, I mean we're talking close to 4,000 calories That's that's a bit challenging for people to consistently what people tend to do As they'll do 4,000 calories for a few days and then you know They'll drop off for another few days and actually totals out to be not that much of a of a surplus so consistently a 1,000 calories surplus per day Go with that and then if your body fat starts to climb too quickly You could cut that in half But you got to be in that surplus to really pack on you're talking about 15 pounds of muscle and to be honest with you Been working out for 10 years 15 pounds of muscle in a one year after 10 years of training to be hard. It's gonna be really hard I would say more realistic would be closer to seven, but who knows at the end of the day I wouldn't get too hung up on that stuff anyways like really my goal with you is if we're gonna do our first show and get ready for it It's okay.  I'm eating as much as I can and it's awesome. I'm not putting on really body fat I'm hovering around this 10 to 12 percent We're in a really good place to transition you into a cut because your calorie intake is so high I can peel you down 500 calories tell you to walk a thousand more steps a day and you're gonna start to lean out real nice And that's where we'd like to be and the lot the other thing I would add if you're not tracking this right now Is to start to track your steps.  Um, it's not that much I mean I go for a couple walks and so honestly, that's the majority of it. Maybe like five six thousand Okay, cool. So that's a room to be much more active. Yeah, that's a great That's a great put for so for what you're trying to do That's a good place to be because that gives me a lot of room to increase your steps and I wouldn't do that yet right now We're we're bulk phase put on size add the calorie style sayings Transition into one of the other programs that you finish anabolic I was talking about trying bulk for the next program and get your calories up as high as you can maintain your steps We're at and then when we switch into your cut The first thing we're gonna do is reduce your calories by about 500 calories and increase your steps by say just 2,000 steps a day. Yeah through walking one other thing too is a lot of people especially if you're natural so if you're not Enhanced with any anabolic or anything like that Most people gain more mass with about four days a week of resistance training maybe five at the most Even though you're taking the volume up and splitting it up You might be better off Reducing the overall volume doing about four days a week. Maybe in the gym the other days you could stretch and That's good work. That's a really good and you'll probably see yourself pack on more muscle And I know it's hard to imagine especially been working out so long But you'll know within the first couple weeks Yeah, if you try that go four days a week for the next couple weeks Focus on you know kind of getting stronger bumping your calories You my guess is and I would bet and put money on this that you're gonna see a nice little bump in Muscle and how young are we? I don't what's our age on 28th. Okay. Yeah Yeah, I agree with Sal and in fact 28th about when I started to piece this together In my mid 20s and early 20s. I was seven day a week It was about intensity and thinking the more I train the more muscle I'd put on I'll never forget switching to a three-day a week program And it was a hard transition because I was like this just didn't feel like I'm putting enough work in But then my body started to pack on muscle and that's all I needed. I needed to actually lay off a bit And and and just follow good programming and eat and recover and I started I started to see myself put on a lot more size after I'd already been training for over a decade So you may be in a similar situation been training as long as you have you're still young you probably you want to get after it and Honestly scaling back a little bit and only training three times three times a week May do you really well so and then what's great about that, too Is that also leaves us a lot of room to add into your cut, right? So it's a burn call. Yeah. So when we get into the cutting phase, it ain't about packing on any more muscle It's about maintaining the muscle that you work so hard for and moving more and burning more And I would that's I would use those extra days to get you more active and burning more calories when we get into our cut phase Well Quick do you have any like small checklist of things that you would do outside of like nutrition sleep and Exercise to kind of try to optimize gains outside of sleep exercise and nutrition. I mean I'm being honest On your own don't go that route but but if you do it's gonna be hard to come back from but not okay So all joking aside stress And then supplements can help creatine is gonna be probably the most Official supplement that you can take and if you're not hitting your protein targets with your food You could supplement with protein powder, but aside from what you just said. There's really not much else I mean I assumed that yeah, that's the cornerstone and then just if there was any other like small little tidbits that maybe I could add But yeah Yeah, manage stress pay attention to what your your stress levels and sleep looks like if you're if you're if you're not Optimizing sleep. That's a that's one of those things that when you're in to your 20 you tend to overlook He included that he said sleep training and nutrition. Yeah side of outside of that. I would say just stress You know, yeah, I can't think about is actually Through you guys I got an ruler unit, but it started leaking so I had to send it away So my sleep has been less Restful, okay, well when you get it back, it'll make a difference. Definitely All right, man. Well, thanks for calling in. All right. Yeah, thank you for having appreciate it Yeah, I know I know I've said this many times, but There's a difference between How much training you can tolerate and how much training? You know what the appropriate most effective amount of training is right? Yeah, those are two different things You can almost always tolerate more training than what is considered optimal and once you go outside of optimal Whether you go below or above optimal you're getting you're slowing down your progress. You're not gonna get as many gains Okay, so so and what we tend to do especially when we're very experienced and we were trained for a long time when we love The process is we tend to inch towards what we can tolerate. Oh, I can do more. Oh, it's not affecting me negatively Oh, I can do more. Oh, it's not but without realizing that you're actually reducing your body's ability to you know Build muscle and improve so that's that's the part because most instances you provide more work a lot of times You get a lot more benefit that way So this is why it's a little bit of a challenge mentally To to scale and find that that sweet spot where you're actually gonna move forward I think that's great advice because he's he's at that age when this is most likely, right? I remember I remember being ten years deep into training and stuff and like that was in the heart of yeah more More is more is better more intense is better and you can handle a lot Yeah, and it was right around it was maybe a little bit before 28, so I was probably like 26 When I did that like cut I never might literally from 17 when I started lifting to probably 26 so nine years or so nine ten years Seven days a week, you know and a bad week and only if I did five It was because I couldn't get to it or I was doing something like snowboarding or wakeboarding something else on that day So I was so active and thinking that the more effort more work I put in the more muscle I would get and I remember like I can't remember what what it was that I read and I was like I backed off to three days a week and it was hard I remember thinking like oh, this isn't working like right away because you're not you're not getting the pump every day You're not getting pumped every day, so you're like oh, I'm shrinking and we get bad I'm like no I'm gonna stay the course trust the process for like a month and it was pretty quick after about a month or so I Noticed strength, and that's what really started me. Oh, let me hang here for that I remember hitting like dumbbell bench press bigger numbers than I'd ever within a couple weeks Yeah, and so I was like, okay, let me let me stick this out for a little bit So he's probably right in that age where it's you still at that I want to do more my story is a little different in that I read Mike Mentzer's heavy-duty book Doreen Yates was the reigning Mr. Olympia He talked about over training all the time And so I went high volume and I brought the volume way down and the frequency down and I saw great gains I still still would consistently inch towards that doing as much as I could tolerate That's how insidious that tendency is so check it and here's the Okay, always do this what this what helps me. I always ask myself. What's the worst that could happen, right? So I'll cut down. I just recently did this so I cut down my volume I said, what's the worst that could happen after a few weeks? I notice it's not working I go back to what I was doing before and I'll bounce back real quick So let me give it a few weeks and they don't like clockwork less work work better for me So it's very insidious. So consider that if you're in a similar situation, you know something I didn't tell him to do that I did That I remember I was a lot of my peers were kind of criticizing I thought was they interesting that they thought this way They were they encouraged me to like get on stage right away like oh and I get why because they're like Get the nerves out see what it's like. Just who cares what you look like just do the next show You can get on to and I didn't I wanted to win like so I was like I'm not ready, you know I need to prepare so I spent a year of Practicing cutting for a show before I cut for my first show because a lot of Competing is timing it's Learning learning how to manage your calories and your your burn and intake and then how to manipulate that to get your body To peak on a day. It's a lot more than you think it is. Oh, it's weird Like you get when you it's you know what it is It's when you get really lean, you know when you're like 10% 9% you look good at the beach You know holding a couple pounds of water Whether or not your muscles have glycogen or not you can tell but not really you're down to 3% body fat on stage a Little bit of water a little bit of a lack of fullness in your muscles You look like a different person and you'll see people the day before the day after look way better because they missed their timing I mean, so that's I mean what you're saying is like so on point. I think people have no idea They don't realize that when you compete It's not just about all the basics you got to know all that stuff But it's like how do I time this and not just for the day by the way Literally for the morning when I'm doing the pre-judging or what I'm doing I mean, I practice for a year and then I went and did six shows with a course of two years And I tell people that I don't think I ever brought my best physique to stage I always looked better the day before the day after the night of I just it's hard It's really hard to and if you're constantly building and you're manipulating changing things It's very inconsistent and so it's tough to peak Right at that time when you're supposed to so I encourage somebody who's thinking About competing to do a dry run when you don't have to get on stage with that and just say hey I'm gonna try and get the leanest ever got I'm gonna try and get my physique and pick a date and say I'm gonna try and get perfectly shredded at this time and see what happens and what you'll find is I bet you Two days before or two days after or the day before or after you find that your physique ends up looking better And you learn a lot about how your body responds to all those little subtle things you're talking about Hey, if you enjoyed that clip you can find the full episode here or you can find other clips over here and be sure to subscribe