Welcome to Access a Trader, the number one community for those who are committed to taking control of their trading in order to achieve success, profitability, and longevity. Thank you for joining us. Here's Dan Shapiro to help you find your edge, master your process, and own your future. Hey guys, good evening everybody, and welcome to another edition of the Access Trader.com nightly update show. Hope everybody is doing well. If you could be so kind, take a moment and click like, share. If you haven't done so, subscribe, come aboard guys, and thank you very much for spending a few minutes with us. So kind of a weird day, right? So if you watch the weekend update, I came in today, my number one, number one idea, number one setup going into today's session was Tesla, right? Tesla just the last, you know, three, four days has just been kind of putting in lower highs, lower lows, been basing below the five day moving average. And you know, like I talked about in the video, I was waiting for this bottom channel to confirm. Obviously it didn't confirm, and not only didn't confirm, it started actually going higher. And this is where really we try to reiterate this point every single time, whatever your game plan is. Okay, if it doesn't confirm, there is no trade, right? It's a setup. There's a big difference between a setup and a trade. And this is what we talked about on the weekend update. Don't put yourself in a situation that you're anticipating, right? When a stock confirms, it confirms. When a stock doesn't confirm, it's just a trade setup that just hasn't confirmed.  I'm like, all right, you know, this thing looks really, really good. And then out of nowhere, the stock just literally takes off. We'll get to individual pivots in a second. But it really does show you you always have to have a two-sided game plan. It's okay to be wrong theoretically. I don't know one trader walking this earth not wrong on a daily basis. The key is don't be wrong financially. Again, you could be wrong theoretically every single time. It's like somebody putting a gun to my head and say, what do you think is happening to the market tomorrow? Going up or going down? I go up. Who cares, right? It's irrelevant. The most important part is if your levels are not confirmed, there is no trade. And that's why you continuously set alerts, reminders, whatever you want to call them into future prospects of price action. But today kind of played out really, really on the very way. If you look at the indexes, all major benchmarks, you know, down a little bit, nothing really at the right home about. You have the Dow down 62 points and Nasdaq down 20 and S&P down 200. A lot of names basically rested, right? Yet Amazon rested yet Meta rested. You had Microsoft not necessarily rested, but, you know, again, still within the range. The biggest issues came from names today like Google, right? Google today apparently is having second thoughts about how this whole Gemini AI is going to work for them. The market didn't like that because, again, if you remember this whole run up on a lot of these names, whether it's semiconductors, whether it was Oracle, Microsoft, whatever the case may be, it was AI driven. So the idea that their AI capabilities, not the par, really sold off the stock. And when it did sell off the stock, look how close it is now to the bottom of the range here. So this is something we definitely want to watch for tomorrow. Apple, right? We've been talking about Apple for several days, another name that just cannot rally.  I'm still watching the bottom of this range, guys. Again, it's not something that's imminent. Maybe it'll finally be imminent by tomorrow, but it's not something imminent that you have to watch every single day. But if you do respect technical analysis and you do respect the bottom level here, if Apple finally winds up losing the bottom channel here and starts losing the 200-day EMA, it could get nasty very, very quickly. And there is a spillover for potential ramifications in other areas. One group that obviously stood out today were these AI stocks, right? Look at AI, right? AI, say, had a big, big move. Even the smaller names, look at SUN, right? Look at this move on SUN. We actually had a pit on this SUN, believe it or not. SUN, right? AI names going absolutely nuts. ARM woke up today, right? We're talking about ARM on the Weekend Update Show. ARM woke up today. But the most important part, and this is kind of where we should kind of take a little bit of a step back, look at the bigger picture is what we want to talk about with the indexes. So people always try to pick a top. No matter how good the market is, people always try to pick a top. I don't look for tops. I look for, what's the word I'm looking for? I look for a heavy rotation of a rolling situation that takes three, four days for the pensioner to play out. And that starts happening when you get rejected off a top of a Bollinger Band. If you notice, on Friday, we got rejected off the top of the Bollinger Band, and today put in a higher low. There's not really an emphasis to be careful for tomorrow. It's not like one of those scenarios that sometimes I'll record a video and go, hey guys, the market closed on the five day, the market closed on the 10 day, the market better not give up the 50 day, let's watch for tomorrow. It's not really a case like that. I just kind of want to bring it to everybody's attention that we did see kind of a rejection on Friday, and we put in a lower high today. The key is for tomorrow, if we put in another lower high and we start taking out Friday's lows, that's when you could get yanked a little bit. It's just something you really want to watch. Same thing with the semiconductors. Semiconductors, they've been pretty much carrying the load in this market for a very long time now, and definitely in the last calendar year. Continue to watch that area, guys, that 206 level we discussed on the weekend update. If this thing starts losing 206, it's going to correlate with the queue. So it's just, again, it's not something that's imminent. It's not something that has to happen tomorrow. We just want to be aware. And if we are aware, again, you have to put yourself in a situation. You have a two-sided game plan every single day, and when one channel doesn't confirm, the other channel probably will. And there's no better case for that today than Tesla, right? So Tesla, again, we had, as you can see here, these are all the pre-market pivots, right? All the pre-market pivots. Some did really, really well today. Some didn't confirm. But here's kind of my point, right? So we had, this was my number one idea for going into today. 191 held twice. And let me show you why. 191 was such a big deal, right? Forget about today's session. You see these last two candles? That was Thursday and Friday. The bottom of Thursday and Friday held 191.30s, and Friday's low is 191.50s. And that's also the rising support here, right? That's the rising support, which is the 20-day Bollinger bands, right in between. So if we would have lost that 191, I really thought we could have like a move to that 175 level. But that didn't happen. That's the whole point of being prepared and not being afraid to be wrong when another side of the channel confirms. And when you go up here, right, once Tesla didn't confirm the bottom side, well, that's when we turn around and be adults and say, well, listen, if the bottom didn't get confirmed, well, maybe the top of the channel gets confirmed. And the top of the channel confirmed here. It went from 198 and a quarter. It went all the way up to the 201.75, which was the linear regression line. So the moral of the story is here is very simple, guys. I know a lot, especially new traders are very, very, it's important for you guys to be right. Okay? It's important for you guys to get your opinion, have it play out. The problem is the market guys don't care what your opinion is, at least for that day. Okay? We could be having this conversation three days from now and go, guys, remember that 191 level? That 191 level is still valid. It's not like Tesla's running away from us. We did see today 205 and 210 weekly calls coming in for Tesla. We'll see what happens. Obviously, it needs to take out last week's highs for this thing to get going. We'll see if that happens for tomorrow. Arm today was a big, big mover, right? It's one of the names we covered on the weekend video. Arm upgraded today. 138.75 needs to confirm. Here was Arm, right? So it took out that 138.75 and traded right to 150. Big, big move on Arm. If it starts taking out today's channel, it could get a bigger move multiple day. But again, really, really good move here. SMCI, as we discussed on the weekend video, I was prepared. Well, at least I got everybody else prepared. Again, I just don't trade SMCI. For that potential reversal, obviously didn't come. Qualcomm never confirmed. Tesla to the downside never confirmed. Amazon, if you talk about technical analysis, it doesn't work. My head's going to explode. The pre-market high was 176.40 needs to confirm. Look what the high of the day was today. 176.37. Again, these guys, these are not coincidences. Technical analysis is real. And in the voice of the Seinfeld episode in Terry Hatcher, they're real and they're spectacular. And that's exactly what TA is. That worked out really well, right? Really well example. Other than that, here is the upside move on Tesla 9823. It went to 2170s and talk about a name that we would never trade, right? But something caught my attention today. There was option flow came in. They were coming in for the four and a half dollar weeklies. They were coming in for the $5 for next week. So, and again, one of these AI stocks 435 needs to build. Look at this move on S-O-U-N. I mean, this is crazy. It went from 435 all the way up to six bucks. Congratulations for you guys who caught that as well. And I believe that is it, right? I believe that was it.   Going in for tomorrow, a couple of names I do like in case the market has another day of fire. I like this channel on Qualcomm. Again, I don't know if it's going to confirm tomorrow, but the channel itself does look pretty good. If it could confirm the top of the range, you might get a run here. So, keep an eye on that. Coinbase went absolutely nuts today. Bitcoin, I think it was what, $54,000, $57,000. I don't keep up with it. But Coinbase went nuts today. Let's see if tomorrow could be a day two. Obviously, I'm watching a day two of selling potential for Google. I'm watching the bottom of the range for Apple. Obviously, we're watching Tesla for tomorrow. If it could get above the Bollinger brand and take out last week's highs as well. The most important part is, folks, just watch the leaders. A name like NVIDIA, it needs to rest. It doesn't need to go down, but it needs to rest. Use them as a gauge. For example, if you're watching the semiconductors and you're watching the SMH, if you're watching that 206 level, obviously you're going to want to watch NVIDIA. Obviously you're going to want to watch SMCI. Set an alert on this 206 level for SMHs. If NVIDIA and SMCI gets hit, everything's going to get pulled down with it. One really cool note today. If you guys remember when Nancy Pelosi or her husband bought a crap load of NVIDIA stock and then all of a sudden, what we all know when NVIDIA did, it was a filing that she bought a million dollars worth of Pan-W. Obviously, when people heard that, they started building up. The ironic part about this purchase on Pan-W, and we saw some pretty big call buying come in we saw some end of the month, 350s come in, but the weird part about this bet was she did it before earnings. Her bet blew up on earnings. It really does show you, you can't just go blindly into something without really looking at the chart or really just looking at something that has a catalyst. Because again, if she bought stock anywhere in the last month, she's really heavily underwater. Again, just be careful. Don't just start buying because Nancy Pelosi is long. There really needs to be a nice correlation between a chart breakout and sentiment in the process. Just another note on Google, just for tomorrow, not to kind of beat a dead horse on Google, but a big notable bet on Google was the May 130 puts, and that traded 15,000 times for roughly $5.1 million. So I definitely, definitely want to watch Google tomorrow for a potential day two. Maybe we could get a rejection into strength on the 60 minute, but at least something to be completely conscious of. Other than that, guys, that's a wrap, right? That's a wrap for Monday. Very, very solid action. Very, very solid action today. We had a nice Amazon balance, arm when nuts, Tesla was pretty good. Good stuff, good stuff. Nothing wrong with that. Guys, have a good night. God bless, and I will see you all tomorrow. Take care.


Hello and welcome to the session in which we will keep working with the cyber security framework specifically, we're gonna be looking at the four tiers and Discussing the profile and the prior five sessions. We looked at the five core functions, which is those three component basically consist compose Hello and welcome to the session in which we will discuss the cyber security framework and Specifically, we're gonna be discussing the four tiers and the profile of the cyber security framework in the prior five sessions We discussed the five core functions, which are identified detect protect respond and recover So if you have any questions about those concept, please go back to the prior session because I'm gonna be assuming You understand what a function is what a category is one is what a subcategory is Because we are gonna be using the knowledge that we learned from the five Core functions or the five core tenants in order to create a profile and from the profile We're gonna classify ourselves as an organization under which of the four tiers Do we belong in the ecosystem of the cyber security world? Before we proceed any further. I have a public announcement about my company farhat lectures calm Farhat accounting lectures is a supplemental educational tool That's gonna help you with your CPA exam preparation as well as your accounting courses My CPA material is aligned with your CPA review course such as Becker, Roger, Wiley, Gleam, Miles My accounting courses are aligned with your accounting courses broken down by chapter and topics. My resources consist of Lectures multiple choice questions through false questions as well as exercises go ahead start your free trial today No obligation no credit card required Looking at the big pictures once again, we're gonna start with the core functions Which we have five of them and we're gonna I'm gonna go over them extremely briefly The first one is identify and what are we identifying? Identifying what we have to protect what we need to protect identifying our assets such as hardware software Network processes and including personnel then once we identify those we are going to protect them How are we going to protect them? Well, we're gonna need to learn how to defend them Whether we use firewall or any other cyber security techniques protecting then we need to detect What is detecting detecting is an ongoing process making sure of someone if there is a breach We are aware of it. We are detecting the breach For is respond and as the word respond imply looking on how to respond now again each one of these Functions will have categories and subcategories then at the end we recover and what needs to be done at the recovery To do what to get back online in quote or working at full capacity So these five core functions we discussed 23 categories and they are separated Among those five then we have 108 subcategories for the 23 categories now How do we use this information as an organization the first thing that the organization will have to do? They will have to create what we called a target profile and what is a target profile? based on based on our business based on our Mission based on our risk management based on our priorities What we do is we create a risk assessment to determine What should be our? Desired cyber security outcome. How do we do so? Well, we're gonna be looking at those categories and subcategories based on our business Which categories and subcategories do we need to select now? We're not gonna There's a good chance. They may not all apply to your company But the point is you want to know which one are relevant applicable to your company and basically list them These are the categories and subcategories, which is the controls that I need to have for my company This is my target profile. How that how did I create this? Well? I reviewed the functions their categories and their subcategories Then what you do is you're gonna be truthful with yourself You're gonna assess your current cyber security practices And how do you do so you will map your current cyber security practices again to the functions and to the categories now You have the target. You have the ideal where you should be. What's the ideal? Target, which is the target profile you look at your current profile and guess what the difference between them is what we call gap analysis What does that mean? It means you need to analyze The differences. Where are you lacking in cyber security between? How do you know? Well, you look you selected This should be the best for me based on what I do. This is what I have right now current profile The difference is the gap analysis Then you're gonna have to look at the gap analysis and prioritize actions to close the gap Simply put you have to implement based on the organization Priorities you'll have to develop an execute action plan to achieve the desire cyber security Which is your target profile now? This is important for a business because businesses will take this Will take this very seriously and the reason is you are trying to protect yourself Remember if you if you got a cyber security attack, it might put some businesses out of business So it's very important that businesses take their cyber security seriously and that's why this topic is relevant for CPAs CMAs accountant people because we they they are treated as business advisors So that's why you need to know this for your CPA exam That's why you need to learn about this on your CMA on your CMA exam So basically but basically you have to understand under your current profile You have to have basic basic security like data security data backup data encryption if you don't have them Well, you should have them if you don't have them then there's a gap analysis You have to you have to basically get those basic protection now After you have the profile then you have to classify yourself basically under 40 years Okay, where do you stand? Are you partial? Are you risk informed? Are you repeatable or are you adaptive? So simply put you have to basically determine what level are you in the cyber security? So at least you're aware of where you are. So that's very important What we need to do now is go over through each one of these tiers separately to determine To explain them now bear in mind. This is the least mature Like basically here you are a novice. You are an amateur and this is you are most mature And we're gonna see what each what each level implies tier one is called the partial tier at this level The organization cyber security practices are reactive. They're ad hoc. What does that mean? It means they have no plan They're waiting for something to happen and hopefully they're hoping that nothing will happen Then they will react based on that They're not aware of the cyber security risk or they have limited awareness of the cyber security risk and Risk management is performed on an irregular basis or they don't even have a risk management For cyber security, there is no formalized process for identifying and responding to incidents and there may not be clear Understanding of the organization risk tolerance. Simply put here what you're doing. You are driving blind You're hoping for the best You have limited awareness of what's going on and who would have something like this? Typically a small business without a dedicated IT department or cyber security personnel They're relying relying on basic antivirus software and not having comprehensive risk management in place So when you are in under those circumstances, you might be under this Tier which is tier one partial now tier two which is risk informed again Each tier is more mature than the prior one Under this tier organization have developed some rather than limited some risk management processes and have a basic Understanding of the risk profile. So you have to you understand what's out there. That's basically what this what this tier is It's not that much better, but it's better than Tier one which is partial however These processes may not be consistently applied across the organization So the problem is it's that that risk informed some of the risk management may not may not apply for every section of the company And there's some collaboration between different departments to address cyber security and Management is aware of the need for risk management.  You're you have more knowledge. That's basically it Usually a mid-sized company with an IT department. That's aware of the cyber security But like a comprehensive and organization-wide risk management approach and have a limited incident response capability So they don't know what to do in case something happened If you belong to tier three, which is called repeatable Organization at this level they have established and documented cyber security risk management processes Now they have it on paper what needs to be done and they are consistently applied across the organization Versus the prior tier where even if you have some of that, it's not consistently applied Here you don't have the proper tools to deal with the attacks in real time So you're aware of it you have it on paper, but you don't have the tools That's the problem. You don't have the tools to deal with it You have a clear understanding of the risk tolerance and its potential impact You are aware, but you don't have the weapon to fight back. That's that's what tier three is So the organization management is actively involved in risk management process and Fosters a culture of cyber security awareness Here you might have a large enterprise with the dedicated cyber security team that they implemented risk management program conduct regular risk assessment and have an incident respond and provide regular cyber security training for employees, but You can do better. Where can you do better?  You just wanted to predict. Where's the next attacks gonna come from? Basically patching your furnabilities using advanced technology and threat intelligence notice here You have also the tools you're aware you have everything documented, but you also have the tool here You are actively collaborating with external partners and sharing information to enhance cyber security posture of Both their organization and the larger community here. You are practically Involved who can afford something like this a multinational corporation now when I say small versus large versus medium It doesn't mean you could have a small corporation and it could it could have an adaptive tier I'm just giving you an example to kind of get you close to it But usually an adaptive is a multinational with a lot of resources could have that That's why I'm saying this but you could also have a multinational or a large corporation tier three or tier two Hopefully not tier one But the point is just to kind of give you a more realistic so you'll understand this a multinational corporation with a robust cyber security program that uses advanced threat detection systems actively participate in an industry-specific cyber security group continuously adopt its cyber security strategies based on real-time threat intelligence and risk management and Every company you want to be in tier four. Why because you are well protected. You are active You are not waiting for the attack to occur. You are trying to identify Vern abilities trying to identify those Attacks before they occur predict them. They have a looking for predictive indicator based on intelligence What should you do now go to far hat lectures and look at MCQs? That's gonna help you understand this topic as a CPA a CMA Accounting students you want to understand this topic inside out for Your exam as well as for The real world because you could be in charge or you could be involved in committees that deals with cyber security Good luck study hard and of course stay safe


Llein i everything, my name is Neil I live right here in Edinburgh I came for university and never left so I love it that much here and I hope people who have travelled to Edinburgh have had a chance to look around I work just up the street at a start up and have been doing coding for many years and one thing that seems to be a constant is python is a tool that you can pick up and get stuff done with. So I've got, I've used python in all sorts of areas. I even have it running in my house where we have high up windows that open and a raspberry pi is controlled by Alexa to open close these windows. OK, is that better? OK, I'll lean forward a little bit. So a problem came up earlier this year. We have a system, quite a complex application and we needed to write system tests that really talk to the public API. We don't want to do anything that kind of pokes in the sides or anything. We want to write tests that talk to the published interfaces. And I looked around and I naturally picked up python. That's my go-to tool to get things done and found really quite a good set of things that came together and we can write very powerful system tests in very clear, concise code and I'm going to show you how that works. So I will give a little description of the system or testing because it needs some context and then we're going to jump into some coding and see the testing at work. So hopefully this slide doesn't frighten anyone. We have a client and service application and I would hope that when you're building something like this, you want to push the code down into the server side, particularly when you've got multiple clients like web and mobile so you don't want to repeat any logic. And if you analyse what happens in that server side, quite often what you see is there are low level operations that carry out the things your application does and there is another facet which is this authorisation or logic that governs what can you do and when can you do it. And one thing we're seeing is some developer, some businesses want to separate these two aspects in a service. That the authorisation and the logic of what can happen when sometimes is a different development life cycle, maybe even different owners to the low level right stuff for the database and all those types of operations. So we're seeing a separation of the service into two layers. This was exacerbated in a customer where as a legacy bank and they have their big old IBM mainframe at the back and they've implemented all these channels that talk to the banking system and yes, the low level operations cannot be delegated into that legacy system but the authorisation logic is repeated in each channel. So that's definitely a problem for big older organisations that are maybe being challenged by the monsters of the world to be able to move more quickly. So we take our client server, we add a couple of new components. I think in the middle enforcement point, it sits in between the client and the service and when the client makes some request, it is going to turn that request into what we call a decision request. And it'll make the decision whether this request can even be carried out before the service is invoked. And then the service just becomes a sort of set of the low level operations, pretty dumb. We move the actual evaluation that they're working out or of the answer to that decision request into a separate component. And obviously if you have multiple of those channels, that component can be shared. So that's the reason for doing that. So this decision point answers questions like can client X do operation Y with resource Z? And it says yes or no, permit or deny is the terminology we use. And it can go out to other services that are available. Say the request was in a bank for a customer to make a payment. The decision may actually go and check the customer's bank balance to make sure they have enough money to make the payment. And the last part of this is there's an authoring system. You can think of those two boxes in the bottom left as a as a software development system for authorization logic. And that's what we're going to focus on. We want to write system tests for a system where we can write rules for authorization where and then make requests for authorization that will evaluate those rules and possibly go out to an external service to answer those questions. And one of the things about this system is that the external services that it talks to are really defined by the rules are not intrinsic to the system. And that's a particular challenge for testing it. Right, so enough of the slides. We've got an application. I'm not going to use the real application because it's far too big and complex. I've made a simple version of it that kind of captures the architecture. So it's a spring boot application written in Kotlin. Now is your time to boo if you don't like my technology choice. And it is all obviously given the talk. It's dockerized so we can look, simple docker files. Who uses docker by the way? Anyone? Oh, quite a lot. So I don't need to explain what docker does. That's good. We have a docker compose, which brings up my two parts. So my simple version, my offering point is called the compiler. It's not your standard compiler. It's a web service where you post code to it and it returns the data blob that you stick on the engine that evaluates the rules, but it captures the architecture. So I can go in here. That the font on the terminal and visual studio codes a bit weird that chops the tops off. So if anyone doesn't like it, give me a shout and I'll try and do it in another terminal, but it's nice to have it all in one window. So I can bring the app up. We should see a couple of spring boot applications up. They come very slow, not like Python. So here's possibly the simplest rule set you could give it is for any request always permit. I can send that to the compiler and it comes back with some meaningless Jason. I can bring that back down and it's gone. So docker is great. Let's just clean it up. I can even run it, of course, this background it so that I can do other things. So the first challenge I'm going to have in testing the system is I want my test to bring the app up. So I could in Python, of course, use sub process or talk to the shell shell out and run these Docker compose commands and bring the app up and down. But anyone's ever written code that does that sort of thing. You know, it's not the most robust. You don't want to put it on your CI server and then have to fix it three times a week when it falls over. So enter the Docker SDK for Python. This is a brilliant library. Really easy to use. That gives you pretty much all the power of Docker compose, but with a nice Python interface. So we'll go back to our code. I've got a little example. Let's get rid of the app. Don't want to see that again. So using the Docker library, I just need this one initialization line. I've made a class. Which is a Python context manager, which is great because however you use it, except if there's a normal exit or exceptional exit, we definitely will close down the Docker container. So that's good for robustness. And you can see the enter and exit are really, really simple. We just want to container run the thing we're running and kill and remove the container afterwards. And then we just use it in this with block. So it's great inside the block. The Docker container is running and after the block the Docker container is gone. So we can go in here, just run that. And there you go, up comes a application. You can see the Python code there is just streaming the standard out from the app and dumping it to console. I can do that and it's gone. There's just the two that I ran in the background earlier. So that's good. That's going to be how we bring the app up and down for testing it. So the next thing, we were in here and we sent this request. So we're going to need some HTTP client to talk to the library, talk to the application, sorry. And if you're doing HTTP in Python, request is your obvious answer. So we're going to use that. And then you need some sort of testing. Framework, testing infrastructure and PyTest is my favorite testing infrastructure. So I'm going to use that. So what does a test look like? Let's go and have a look at one there in here. That's a test that brings up a Docker container, talks to it over a rest and verifies the result. That's pretty cool. We can run it. If you go to the right directory, it's called test compiler. It takes a little while to bring that up, bring it down. Great. So now I meant to explain why PyTest is my favorite testing framework. And I'm going to show you, create a new file. Sometimes when you've written tests in the past, there's a whole bunch of ceremony around subclassing based classes and writing set-ups and tear-downs, but a PyTest looks like this. Oh, does anyone use PyTest? Yeah, loads of them. So you all know about PyTest. Good. I like this one. Let's save that in really good. I didn't have to write enough lot of code that wasn't related to the test. Like calling my failing on this on that again. Let's do the minus V because then you get a little bit more. And so you get quite a nice output there showing exactly what went wrong in the test. So this is really good. The other thing I really like about PyTest are fixtures. And we can write simple code like this, call it foo. Just return some data. And I can write a test and I name the function that I just created, decorated with fixture as a parameter in the test. Okay. That's useful. Obviously that particular case is not the most useful, but you can do quite a lot with passing things into your test that way. We're going to elaborate on it in a minute. Another thing you can do. I can write another fixture that depends on an existing fixture. Great. Okay. So that's the fundamentals, but there's more you can do it with it than that. Let's make a new module. I'm going to write one which depends on a built-in fixture in PyTest, which is a temporary directory for every test that uses this fixture. I need to put my decorator on. And what I'm going to do is make some path to a file. Let's save this. I get some syntax highlighting. There we are. There we go. We're going to depend on a whole file and I can, what I'm going to do, open read. Let's run that one. I got it wrong. I called it path there. There we go. So the fixture created a file. I can actually go and look at that file. And the default place is in here. It was the most recent one, nine, 10, 11. There's my hello file. So that's quite interesting. I can write files, but I can do another more interesting thing, which is to yield instead of returning there. And what does that mean? It still works, but of course yield means I can write more code after this point. And the test still works, but we just have a quick look in the terms actually around 13. Now the file is gone. So the file existed when the test ran, but it's gone afterwards. So you can see these fixtures are really good way to set up some kind of resource and tear it down after the test. Where could I possibly be going with this? I'm going to use a fixture that runs a Docker container. So rather than write it all out because it's getting a bit slow to do that. Let's go in here in my test framework. So my Docker class here is a little bit more complex than the one I showed earlier, but it's really just about capturing the logs, dumping them out, giving the diagnostics you need to debug a failing test and also things like networking and other things you might need. So my test compiler I showed you earlier depends on this fixture compiler and that's defined here. So I'm just using this function which uses with my Docker container and then I yield the Docker container or rather the REST client for it once it's ready. And I can write tests that when the test runs, we know that Docker containers up and that we have an API client that can talk to it and then when the test finishes, it's gone. So what else have we got here? We've got this REST client, which is really just a wrapper around a request session makes the sort of get some posts a little bit more test friendly. We can automatically fail on HTTP errors. And that allows me to also in the in the fixtures to subclass that REST client and add sort of high level functions that talk to my API. So I'm not writing tests that deal with, you know, posts to REST endpoints and that sort of thing. I can do it at the sort of level of specification. So that's what we saw there. Okay, let's do a more interesting example because that doesn't do very much. Here's one that depends on the compiler and the engine. So I'm going to compile some rules, same rule, always permit.  We can do that manually. Yeah, that was it there. So we get that compiled blob of Jason. We can load it into our engine app and then we can send it an empty request. It's a Jason object, the request, but doesn't depend on there's nothing needed in it.  Right. That's what you should do. Slightly more interesting example in my rules language that I'm writing here. I can write variables and this says variable my value depends on some key in the request object called my value. And there's two rules. When it's foo, I permit. When it's bar, I'm going to deny. So I can compile that. We get a big blob of Jason, which I can then load. Where are my query? If you send it a foo, it permits. Send it a bar, it denies. So we can send it other things. And it's undecided because there's no rule for that. So there's those three things as well as errors that the engine can return. So we're going to automate that test. Where are we? That one wasn't great. So here we are. And we're going to use a couple more features. I didn't mention the module scoped fixtures. Module scoped fixture lets you create a fixture and then all the tests in a module that depend on that fixture will run within essentially in that yield block. So I don't have to bring up and down the docker container, which is pretty slow. I can bring up once and run all these tests. So there's the same code. I'm going to compile it in the offering point. I'm going to load it into the engine. And I've written a fixture here to factor out the common parts of the three tests I want to write. So the fixture depends on those things defined globally to all the tests. And it's going to set up the engine and return it. And then I can just write all these tests engine with rules and I can just send it queries and expect responses. Let's run it a little bit of a delay on the first one as it brings up those docker containers. Then you can see they all run very quickly and a delay to shut it down. That's pretty cool. If we go back here, the last example, I can also get my value from some external system. So I can do a get request to this URL. And when that's a foo I'm going to permit, when that's bar I'm going to deny. So I can compile that. We can load it, paste it in there.  So what can we use to build a little mock web service? Anyone use Flask? Or is Flask? Really like Flask because you can write whole web apps in this, but also for very small amounts of code, you can write little test services and mock services. So let's go and do one. This live code of web service on stage. Let's call it Europe Python. Use decorators again. We say app.root. Let's use the my value one. I'm going to try to function. Place. Overwrite that one. Did I get that right? Looks okay. So, but now we can go to, maybe a little web service running. Was that six lines of code? Pretty cool. And we go back here. We can now let's try a test, testing it. Localhost 5000. Yeah, returns foo. So now my service, which a little bit I've maybe lost over, the URL it's talking to is his external. Because remember this app is running in a Docker container. If we go back and look at the Docker compose, for the engine, I added an extra host line in there, which basically says, if you talk to that host name inside the Docker container through the magic of Docker networking, it will talk to the host machine outside the container. So I can now send that. I'm not sorry, that's the compile. Let's query it. We'll get a permit. And if we change our service, we get it tonight. Great. But how can we put a little mock web service like that right in a test? So you could make another Docker container, wrap up all the, with the Python environment and bring that up. That would work. But as I said at the beginning, the service that we're talking to really depends on the rules that we're writing to test. So you don't really want to break these two things apart. You want to define a service in a test and implement it right there in the test. And that is exactly what we're going to do. I'm going to write a fixture, which is a service that's going to create a flask app. I'm going to wrap it in the service class, which we'll look at in a minute. The test depends obviously again on the compiler, the engine, and now on the service. And when I build that URL that I put in the manual testing client, I could just write external. But that's kind of depending on the way that the test framework sets up networking. So much better to provide a method that, given a path, will give you that full URL.  And then the service again is only brought up inside a context manager. And that's handy because if you write a test that fails, anything that was brought up in that way automatically gets taken down again. Ideally, you want to... This was all created to write tests that go in our CI system and run nightly. And we don't want to have to fix it every morning. So let's stop that. A long pause while Docker comes up. There we are. We passed. So we write a test that defines a service. We can define the service right there in the test code. And you get this nice, really succinct test description. So how does this work? This is maybe the most complex part of the thing. When you wrap... This is the service class. When you wrap a flask app in the service, it adds an extra root on it. Service control with get and delete methods. When you get, it just has a response. When you delete, it uses a little bit of flask magic. It finds this function from the environment that shuts down the server. There's a URL implementation. It's not that interesting. It just builds up from the things it knows. And running the flask server is really a matter of kicking off a background thread and doing flask app.run like that. We start the thread. And then a bit like the Docker container, we have to wait till it comes up. So we just pull on that service control until it responds okay. When we want to stop it, we send it at the delete. And off it goes. And then we wait for the thread to exit. So maybe the most complex part, but it's not that complex really. There's a little bit of extra... The instrumented cluster up at the top here is a WSGI wrapper that records all the invocations and the responses that that mock service received, which allows us to do things like verify that the engine we're testing definitely invoked that service once and not 100 times. And that's kind of it. We end up with this. I don't know if I can make that fit. We end up with this really, really powerful testing system. You remember all the things this is doing in 30 lines of code. We are bringing up two Docker containers. We're running a web service in a background thread. We're configuring it all to talk to each other and running a test against it. So we've been building tests in this way for the last few months. And we're quite a big library of them now. And it's looking really good. It's really reliable. And it runs on our CI system every night. So we'll be a little bit early, but any questions? I think a nice talk. Quick one. Will the code be on GitHub? The code is on GitHub. I'm sure you've heard me in my last slide actually. We'll write through to... There we are. There's the URL. You can get me on Twitter too. Sometimes it's about coding, and sometimes it's pictures of cats and stuff. Any more questions? The Python Docker module that you said, subs sort of for compose. Will that let you do the compose type functionality of specifying multiple servers, multiple Docker containers and stitching them together? Essentially, yes, but you have to code it yourself in Python. So when you bring up a Docker container with the Docker library, you specify all the networking rules and the hosts and any volumes you want to map into the container. And then you have to do that for each one. So it's kind of like you're doing Docker compose, but you have to go through all those steps for each container, just kind of as you do in Docker compose too. Name, thank you for the talk. What makes in this specific use case Docker necessary and why is it preferable to writing a series of py tests using the request module to test your API? So the application was Dockerized already. But another good reason is because there's two parts to the application, we have an authoring part and a runtime part. And they have different environments. The runtime part is in a high availability environment. The authoring part not so much. So when we do a new release, maybe we do a new authoring release to fix a bug and the customer doesn't want to update their live environment. So we can do a test that the new version can compile the, build the rules and run against the old version of the runtime. And we can automate all those tests of all the version, you know, cross compatibility that we support. Thanks. Any more questions? Well, I guess that's it. So let's thank Neil again for this great talk.