All right, forward chaining. All right, this is a great behavior. Wow, that was a weird sort of Robin Leach accent. So it's a sort of forward chaining. It is forward chaining. It's how you teach a complex skill, right? So what we're going to do is don't forget behavior chains, right? Behavior chain is step number one. Task number one is a discriminative stimulus for task number two. And task number two is a reinforcer for task number one and also a discriminative stimulus for task number three, right? So that's how a chain works. So if we're wanting to teach someone a complex behavior, using a forward chaining procedure, we would let them do the first task. Then the instructor, the behavior analyst, whoever, is going to do the remaining tasks, right? So last night, my daughter was cooking. So I said, why don't you do the first step and get all the stuff out of the cupboard? And she got all the stuff out of the cupboard, right? And then I cooked dinner, right? If I was doing forward chaining, I wasn't. I was just teasing her and making her do a little bit of her final thinking she was going to cook. But anyway, I digress. So if I was doing forward chaining, tonight I would have her get the stuff out and then portion it out, right? And if we continue that process, it's now portioned out. Now mix it together properly. Now turn the stove on at the right time. Now make sure that dish one goes on the stove at time x and dish two goes on the stove at time y. So everything at the time is properly and don't forget to set the table. And you would slowly add steps from the beginning step until the end step, right? That's forward chaining. You start with the learner does the first step first and then whoever's teaching them does the remaining steps. And then the next time around you do the second, the learner does step one, step two, and the instructor does the remaining and so on and so forth till you teach that person the entire chain. That's a forward chain. You're building the chain from the first step all the way till the end. So let's do it.


My name is Richard Miller and you can find me on Twitter and it is Mr underscore r wool Miller, which is a slightly awkward things I didn't realise how annoying it would want on it. I worked with 18-0 labs in the UK I am based in Shefffield Mae'r ddaf yn oed i ni'n gweithio'r newid yn ymgyrchol rhywuniaeth o gwybod drwy'r ddechrau. Rydw i'n rhan o'n meddwl y syniad bwrdd. Rydw i wneud fy modd o'r rhan o'r cyflawn. Mae ydych chi'n gweld ar ôl i gael. Mae'r rhan o'n meddwl i gael ac yn ystod yn ei gweithio'r rhan o'r cyflawn. Dwi'n dweud ond y cwrdd yn cael ei roi gydag. Yn gweithio'r cyfradd yma, mae'r cwrdd yn cael ei grannu gweld yn meddwl angen. was it's quite difficult to, we're sort of writing code for one customer and I'm wanting to reuse a slight different version of it somewhere else for another customer and sort of running into all kinds of problems about how to, you know, end up maintaining multiple versions of it or having all sorts of kind of complicated code to work out which version of code we should be using for that customer. And it's sort of finding out about dependency injection and how that worked and it really helped me to start to sort out that code base and at the time it wasn't hugely popular as a technique that people used in the sort of PHP world but sort of read about it in blogs and things from Java where it was used a lot more extensively. And then when we sort of came to our senses and realised that maybe we should be using one of these other great frameworks that are out there instead of persevering with our own not so great one. It was one of the things that really sort of, I liked about symphony, so it was the symphony two which we sort of started using, well started investigating and looking at when it was in a beta version. So what is dependency injection? So it's a technique for an object oriented programming where we separate what objects we're actually going to use from how we use them and make that separation. So this is it pretty much. So in this example we've got a stock levels class. It needs to use, it has dependency on a notifier object but it's going to make use of. So instead of creating it inside the class we inject it in through the constructor and then make use of it that way. So when we create a stock, instantiate stock levels object it needs a notifier and constructor is going to force us to pass one in and we're separating that construction from the use of the notifier. And that's it really. So if you want to, so and essentially that is all there is to the basic concept of dependency injection. I'm going to talk about sort of like why we do this and advantages but also where some of the complications arise from and why you've perhaps heard of sort of service containers and dependency injection containers and all these. There's lots of blog plays out about how you shouldn't do it. So why should we do it? I mentioned a little bit briefly but if we're going to a bit more detail. So for this I'm going to use the example of, we've got a requirement that after we update the stock level of a product we also need to email customers who has to be notified about it. Presumably I guess notified that something came back into stock, not just every change in stock level. Okay, so at first thing we might create a lot of code so we're going to update the stock level and then do all this stuff and then I appreciate that's quite small. So if we split because there's a lot of sort of code going on, that's what we split what's happening. And so say this is all happening after we've already kind of done the actual stock level updating persisted that somewhere then we're like okay we better notify those customers that want to be notified. So we're going to do it by email so we set up our mailer object so it's sort of a very tedious sort of configuration code. We're using SMTP, here's the certainly address of the mail server that you thought to use, the username and the password. But it's not my usual password. I don't have a usual password anyway but. So we also need to do the same so our customers we're getting from the database, this list of customers. We're using doctrine for that in this case so we need to configure a set up doctrine so tell it in this case we're just using SQLite. Probably don't want to use that for your production database but for the sake of conciseness in the examples. So we create an entity manager in that and it gives us a repository and now we can finally actually do something with this stuff. So we've got use the repository, ask it for the customers that were registered for stock notifications for that product ID. Then that gives us back a sort of group, a collection of customers. We can loop through that collection of customers using for each in this case. For each one we're going to create a message telling them about this product's come back in stock. Then finally we're going to use that mailer object that we created in the first slide there to send the message. So the code we've created, well I created in this case is quite inflexible so there's a lot of hard coded values in there. All the values for like username, password, where to find the server, the fact that we're using SwiftMailer, the fact that we're using doctrine. It's also kind of reasonably complex to follow if you open a file and find that because you've kind of got to look at, read through the details of what's happening. You can see there's a lot of stuff around the mailer, a lot of stuff around doctrine and finally we kind of get down to what we want to do. So what we could do to improve this is rather than just, I split it across slides but we could have actually split that into separate objects first. But I'll do that now so if we split that up. So if we take our stock levels class again there's some other stuff happening before we get to this point. But instead of showing all that instantiation of SwiftMailer and doctrine we'll hide those inside, encapsulate it inside some objects. We've got an e-mailer object now and a customer's object and then we can see that we're going to find all those customers and then notify them. So we've cut out some of that sort of things to read and abstract it away from it. So we'd end up with an e-mailer class maybe like this that hides that SwiftMailer instantiation and a customer's object which hides the doctrine stuff and delegates to the doctrine repository. So it's there, stock level class looks like this and it's a bit easier to read. We might find that both actually about abstraction level might be even more detailed when we still really need to know. So what all we really need to know if we're looking at the critical dates for stock levels is that at that point we want to notify people that the stock levels have been updated. So we can simplify it right down to saying we have a notifier object that we're creating and we're going to notify people about the product and then in that we shift that code that does the actual looping through the customers and sending the e-mails. So we kind of move that code from being sort of complex into something that's fairly simple especially at the level of looking at the stock levels. We now have two lines where we had sort of 30 or 40 before. So we're kind of simplifying each level of abstraction. We can see what's happening. It's only if we care exactly how it's happening that we then have to dig down and look at the source code for that class. So in terms of following the pathway of the code, we simplify that quite a lot. It's still not doubt at all though with any of the flexibility issues. So it's still all very hard coded. We're using hard coded values a lot for the details like where to find Swiftmail, the mail server. So like this is, well to be honest, this code is going to be pretty difficult to work with. So even aside from trying to reuse it in another project, it's like if we want to have a developer environment, a staging environment, a UAT environment and a production environment, hopefully they all point to different mail servers and things like this. So the first thing we could do I guess is we could have some kind of config object with we use static access to to get some parameter values. And that's going to maybe read in a different config file depending on which environment we're in or which project it is. So we can kind of make it a little bit more flexible here. Well just usable at all because we're now able to set those values differently. Okay, so we now have a different project maybe. They're going to not use email. We're going to use SMS messages to inform those customers that things come back into stock. So what can we do to accommodate this in the code? We could use our config again. So we're asking our config object to tell us what the stock notification method is. And then we're going to, depending on the case of that and the switch don't here, we're going to call a different method. So if it's email, we'll notify by email. It's SMS, we're going to notify by SMS. And then we sort of have these methods inside the in stock notifier. So you see we kind of made it a bit more extensible if we wanted to add another one now we'd have to come in here, add another method and actually add another case statement as well. So again, we're going to have to constantly kind of come back in and edit this class. So maybe we could push that choice further up for class a bit. Well, further up the object, graph a bit and say instead of doing it in the notifier, we can maybe do that in the stock level. So in here we say, okay, so if it's email, then we're going to use an email in stock notifier. And if it's SMS, we'll use a new SMS in stock notifier. So now we might have to create a new object to do that, but the only change we need to actually make to our existing code now is to kind of come in here and create a new case statement for that. Okay, so we've made the code more flexible now, we can respond to different config values and we can sort of have different paths through it depending on how we configure it, in this case if we want to use email or SMS. But we have started to grow the complexity back into it. So we've already got those sort of, we've got to talk to an extra config object, we've also got to kind of switch through the different values in that case and we have to keep adding new cases to the switch statement if we want to support different methods of doing this. So if you're doing this throughout a code base, you can see kind of grow quite a bit of complexity and now it makes the facts of it being a bit more difficult to read. There's more things going on than just making use of that object. So what we can do then is use that sort of constructive injection I spoke about right at the start and say when I create my stock level object I'm just going to give it a fully formed already constructed notify object. I'm going to set it to a private variable in this case and then when we get to the point of updating stock levels all we need to do is say notify people about this product update. So if we want to use emails, we instantiate it like this with the email and stock notifier and if we want to use it with SMS then we can instantiate it like this and just use it with an SMS notifier. In this example it doesn't cope with the fact that maybe sometimes you might want to have email some customers and SMS some others but let's just assume it's one or the other for the sake of this. Okay, so by using that sort of dependency injection we're kind of saying I don't want my object to instantiate to say dependencies and have to worry about what those dependencies are I'm going to create them somewhere else, pass them in, ready formed and the class can just say, just use the one that's there it doesn't care which one it is it just knows what it's going to do with them and one of the other advantages is that we're making explicit how many things are depending on so if you end up kind of saying I need this and this and this and you've got this massive constructor that's growing and growing and it highlights the fact that maybe that class is doing too much work itself and maybe there's something else you could do to kind of simplify it and pass them with that work elsewhere. So there was a problem with that version now so if we look back at this so this is a simplified version we're passing the notifier into the constructor and then we're calling the notifier method fortunately we could do this still when we're creating it and say I'm going to want a new stock levels object and I'm just going to pass you some other object it's not a notifier and then I'm going to call update stock level on it and we're going to see this unfortunately so it's a fatal error, we're getting a call to an undefined method because it's not a notifier object doesn't have a notifier method to call so we better make sure that when we construct our stock levels objects it is an email in stock notifier that we get so we can use instance of it one way to say if there's an instance of an email stock notifier it is great, carry on if it's not we're going to throw an exception at this point fortunately PHP saves us writing someone a boilerplate code and we can use type hints on the constructor to do that so this time we're insisting on an email in stock notifier if I try and run this again then I'll get a different error message this time so now I'm saying it's a catchable fatal error although I'm not sure anyone over does catch them but argument one passed to it must be an instance of email in stock notifier instead an instance of not a notifier was given so it doesn't necessarily help us if we're actually running this code in production we've still made a mistake but it means that when you're doing something in development you get a much clearer error message much more explicit about what the problem was it's not just that something didn't have a method you tried to give the wrong type of thing to something and it kind of documents that code as well so if someone's reading it they can say it needs an email in stock notifier not just it needs a notifier whatever on it we have no idea what that is fortunately if we do that with the concrete implementation of the email in stock notifier and then say actually I want to use my SMS in stock notifier we're going to get the same problem because it's not an email in stock notifier so we've kind of ruined that flexibility for the sake of a bit of safety okay so we can solve this by using an interface and typing on that so our interface just says I'm something that, well I'm a notifier and I have a notifier method we can update the definitions of our email in stock notifier our SMS in stock notifier and any future notifiers that we have to say that they implement the in stock notifier we'll get a fatal error then if we don't actually implement the notifier method when we try and create one of those and then we can update our stock level class to type in on the interface and not on the concrete implementation so now we don't really know what my notifier is we don't really stock level class doesn't care what it is that when you pass me that object I know you've got this interface you have this method I can call it happily it may just do nothing it might call out some third party service that helps us like send this stuff out by traditional mail it may be a whole collection of them that sends it out in all sorts of different ways that you'll wrap together all I care about is it has that method I'm going to be able to call it and I'm not going to run into any problems when I do try and call it so what we're saying is that it's great pull apart these classes this way and then by depending on abstractions interfaces for instance we can avoid tight coupling between the classes and actually get that kind of flexibility to wipe them up in different ways and get more use out of each individual class okay so if any mention we've shown constructor injection where we're passing those dependent objects in through the constructor and there are other types of ways of injecting those dependencies and I'm going to briefly talk about those personally I always try and use constructor injection I don't particularly like these other ways of doing it so and the great thing with constructor injection essentially is that it happens at the time you construct an object in that state and you know that it's ready to be used and that no one else is going to change it under you so one of those is property injection which you may see which is essentially just simplifying it down to this and so we don't have I guess it's when people don't want to worry about writing a constructor you just say I've got a public property that's a notifier and get rid of the constructor and let anyone set it so of course the problem we've got with this is that we lose all that safety of tightpints again we're back to the point where anyone can set the notifier property to anything they want so you could improve on that and say set your injection we should just get a bit more use which essentially what we're doing here is saying that we're back to a private property for the notifier but we're using instead of a construct method a setter method that says it looks the same as our constructor earlier it's saying set notifier to an install notifier and then it may use it a bit that way so there's a problem with this which is if we do this so we're creating a new stock levels class object from the class and then we're updating the stock levels but we've forgotten if we're using such an injection we do also need to call that setter method to give it the notifier so if we run that without making other changes to the class then we're going to find that we've got a null object so the problem with using setter injection setter injection is that you can kind of create a class or create an object from a class in an inconsistent way so in a way where it can then fail in use if we use the constructor injection we wouldn't have got into that situation and there's things you can do inside to make sure that's okay, you could say okay well I only want to notify people I don't always want to notify people so I'm going to make it an optional dependency and then say have I got this statement to say is there a notifier set on this property if there is call it if not don't so that's one of the kind of use cases of setter injection but I don't I wouldn't use it other than that and even then I would consider using like a null implementation of a notifier so we pass in a notifier that doesn't actually do anything but as far as the stock levels class is concerned it's exactly the same as if it had received one that did do something okay so about is it kind of at a class level is all there is to it but how it all works at an application level then does sort of change a bit and becomes interesting because part of the problem we have is not a problem but they're kind of knock on effect of this is that if we're taking all that creation of dependencies out of the individual classes then it has to go somewhere so whenever we say we've kind of had simple examples of I would just call new this the new one of those but as we go we kind of find well if we do this to all our classes so we only looked at stock levels before but in the email in stock notifier we're probably going to need to create we want to inject its dependencies instead of saying new emailer a new customer here we could change that and say actually I want you to give me a customer repository and I want you to give me an emailer service and then I'll make use of those properties rather than instantiating the time I use them and then if in our emailer sort of class we might want to make that an interface so we can switch between Swiftmailer and another emailer so again we introduce new emailer class got Swiftmailer we actually create the Swiftmailer object itself outside of that and pass it in perhaps rather than having that code in there to do the setting up and the new and if we do the same with customers of our doctrine customer repository it's an implementation of customers so we can swap it in and out again and we create the we want to create the doctrine entity manager somewhere else and pass it in so if we do all of this it makes instantiating a stock levels class quite a bit more difficult so it might be quite flexible but if we want to create one we might have all of this case we've got all that stuff saying here's the doctrine configuration here's the doctrine connection configuration we've got our mail server server port user name password we need to create an entity manager we need to create a Swiftmailer transport we need to create a Swiftmailer instance then we can start switching all of this stuff together so we can say new stock levels our new email in stock notifier for customer repository that has an entity manager and a Swiftmailer thing which takes a mailer so it's starting to get quite complicated just to set up all of these classes they might be nice and small but because we've separated that somewhere else in our application we now need to do all the object instantiation do all of this sort of stuff and then we can make use of it and what creates the stock level objects because whatever is using that probably isn't going to want to do all of that code we're probably going to want to actually create it push that up again create it somewhere else and inject it into that object so if we keep pushing all our dependencies up then we find its dependencies all the way up and they all kind of pop out the top of our application and we need to kind of create them all somewhere and then we can make use of it so when we have quite often with things like this we've got there are patterns that can help us deal with this so there's design patterns for this sort of thing so some of the ones that are around for construction that we could use things like builders and factories but nowadays there's a more specific objects sort of pattern that we can use which is that dependency injection container so this is like a container or sort of specific object or in the case of sort of symphonies one a collection of quite a lot of objects that work together to wire up all of our objects and then give it to us in this pre-wired state you might also hear it called the service container in the symphony world because we kind of think of these sort of objects for wiring up like our mailer and we call them services unfortunately services are horribly overloaded word in software engineering so in this case when we talk about services what we're talking about is those sort of objects we've seen pre-wired up that we can just make use of is also quite an overloaded word now particularly with sort of the docker being all the rage so this different use container for that so it's slightly unfortunate naming and you may also see elsewhere like people talking about IOC containers which essentially is just the same thing so IOC here stands for inversion of control and dependency injections like a specific way of achieving a bigger concept of IOC so the inversion of control is that we're taking away the control of deciding what to do from how to do it and pushing it outside and dependency injections is a good way of doing that if you're doing objects or into programming so in a small application if you're writing just maybe like a little command line tool or something like that and you start pulling your code apart in that kind of way it may not, you may just be able to have you've got a bootstrap file at the top you don't mind writing a few like stitching it together with a few new things as that grows and it becomes unmanagable it might be useful to introduce one of these containers so one for sort of smaller and medium size applications we can use is Pimple so with Pimple when we use it it looks something like this so this will be now like a sort of bootstrap file you could say I want a new container so it's a new Pimple and then I'm going to set myself services on that so it has like array access style access so we can say container stock levels is and then tell it how to create stock levels objects so we're kind of assigning like key style things to services so we can refer to them elsewhere and then we're actually kind of doing what it does is use as an anonymous function here to say when I ask for this actually then run this code so we're going to still do the same sort of thing and say a new stock levels thing and ask the container to give us the stock notify email service and create it with that so the reason for using anonymous functions for this sort of thing is as your application grows you may not want to instantiate every single object in it for every request or everything that you use it so by wrapping it in anonymous functions in this way we can just say only if I ask about a particular set of objects should you call that function and give them to me so particularly if you've got any objects heavy to construct it can be useful so we'd have to create something similar for the next level down so stock notify email email is itself an anonymous function that asks for its dependencies from the container and then we can kind of write that code for creating the Swiftmail stuff in there so it gives us a way of organising it and it also differs in the actual time of which you call new and all of it and do that and it also means that the container can keep track of all those things by a config key rather than you creating kind of variables and having to refer back to that particular variable so you could maybe then start to split this up across more than one file so you don't have to keep it all locally in local scope you can kind of set up some of the container in one place some of it in another place and not end up with one huge config file okay so at some point we actually need to get something out of it and make use of it so we might get a whole application or maybe a slightly lower level once you've decided which controller actions being run or which console commander you're using we're going to say give me the whole of that code for that particular key then I'm going to do something with it so at that point everything's all set up for us and then we actually start doing something and sending kind of our maybe console arguments or our HTTP request through the object graph so the pimple is quite simple and easy to understand if you ignore the little bit of noise of the anonymous functions in there then it's actually pretty similar to what we'd have written if we weren't using the container if we do have lots and lots of configs and a larger application and we probably don't want to write all of those sort of functions out so so in a larger application you can make use of a symphony service container or if you're using a symphony full stack framework and this is already there it's going to come with some of its own services set up and then similar I believe in Drupal 8 so here we can use config files rather than writing code in order to actually configure the different services there's a couple of ways different things available to you so you've got XML or YAML I need XML for the examples mainly because it is more of a boast it's more explicit, you can see what's happening with YAML, once you understand it it cuts it all down but you do kind of it loses that explicit you need to know that when you put certain things in the ray with a certain symbol in front of it it means this so in our XML file services the simplest thing we can do is just define like a service like this so again we give it an ID so this is similar to the Pimples kind of array access keys so we're saying we've got a stock level service with that ID and then the class is the actual PHP class here stock levels you could use namespace classes in here and put right out the full namespace so we're saying to a container when I ask for one of those use new on that stock levels class and then give that back to me of course we needed to have some arguments passed into that so our notify email so we can use the argument element to say it's an argument for you it's a service and here's the ID so this is another service and when you find somewhere else when you create a stock levels thing go and find that service, create that and inject it into me so it will kind of recurse through all of these definitions so our stock levels definition we could swap it that was for email if we wanted to use SMS we could just at this point swap it for the SMS service instead so that was that kind of instead of doing it in the code we're just changing an XML file external to the code okay so what you'd probably find so then we can create more services at this level so we're stitching together we add our stock levels our email in stock notify which takes the customer repository doctrine and then email swiftmailer in this other service it's the email swiftmail so it's all pretty straightforward then we will find though if we remember that to create a swiftmailer instance so this wasn't the code we're written it's from the library but we did that through a static method we called new instance and passed it with transport so we can still do this with the service container so it gets slightly more complicated now we can have so well as a class as a factory class of swiftmailer and a factory method of new instance so now the container will know that instead of calling new to create one of these objects it will create it will use swiftmailer new instance to create it and what the container will do is keep track of all these objects as well so it's not going to create a new one every time you ask for this each time it will say have I already got one of these if it has have that back if not now I'll create it and keep track of it so you effectively only ever get one instance of these each instance of these services so setting up the swiftmailer transport thing itself is a bit more complicated than that so here we had various config values in our code the mail server address port number the username and the password and then we again used a static method and we also called some methods on it so having got hold of the transport object we called setUserName and we also called setPassword to set that up so we can deal with the parameters by having a parameter section that's also supported in our config file so the parameters so we've got a key to give it a name that we can refer to and we set the value in there sort of statically and we can refer to that in our service definition so instead of saying our arguments are now another service we're saying it's using these percent signs it's the mail server variable so it will the service container will refer back to that parameter and put it in for us we could also just pass in static scalar values at this point and you can also set PHP like constants out of PHP classes as well we also needed to call a setUserName and setPassword methods on there so and our the service container can do this for us so after we've said the constructor arguments we want to pass to it we can also say here's some methods that we want to call so here's the first method is setUserName and here's the parameter that I want to pass to at the mailUserName parameter and then we can do the same setPassword in this case the parameters you could just pass yet more service in there so if you did want to use a set of injection you can use this as a way of passing services into all the services through setUserMethods so the advantage using like the symphony service container is that we're assembling files from various places so you can assemble your own files the framework itself will provide them so in fact if you're using a symphony framework you wouldn't need to do all this stuff with Swiftmail it's kind of taking care off for you and just opened up as a mail of service so it reads in your parameter files uses those to create those services and it's there for you and the various third party bundles and things that you can add also provide yet more services into the container so you can keep finding preset up things and they'll expose ways of configuring them passing different parameters or you can override the way it's done to stitch it up slightly differently so you don't have to write all of this config just the part safe as your services what it does mean then is that we're kind of like assembling stuff from various parameter files the party bundles the framework itself and taking all those XML files and stitching it all together so that the container knows about all sorts of services so one of the things it does do then is provide us with caching so the caching work essentially all that gets turned into PHP code and it all gets dumped into one file so that every time you kind of using the container firing up your application it just reads in that cached file and not all those XML files and YAML files and any files and things that are scattered around the file system because that would be quite a big performance hit there so it turns it all into one big PHP file which loads pretty quickly and essentially just contains PHP that look quite like the stuff we saw at the start where we just say new this, new that all the way through ok so how do we actually access services out of that we can call just the container has a getter method at the top container gets and give me a service by that service ID so we want to get a whole application out of it or individual controllers or in a controller get individual services but we should try and avoid as we get further down avoid doing that apart from when you have to write up at the top and what I mean by this is instead of we might end up and be tempted to instead of writing code like this where we've got the constructor passed in so the notify pass constructor is to do something like this and say I'm going to pass a container in and then I'm going to get the service out of there and it's tempting to do this but what happens then is that you're creating a dependency not on a notifier anymore but on a particular service container so you can't use this code with a different service container and we actually lose some of that kind of safety again because we're back to relying on the fact that the container was configured with something that implemented our in stock notifier interface but there's nothing inside this class that guarantees that anymore like if someone reconfigured the container we could get anything out of there so I think it's just fine it's really helpful to try and remember that what you're doing is assembling these classes in a simple way the container is there to help you put it all back together it's not rather than something you should actually rely on in the code itself okay so when do we actually use dependency injection this sort of way should we use it for everything and avoid constructing anything directly ever seeing the new keyword and just do it putting everything together in this sort of way well it's good for these sort of reusable stateless services so email it makes sense to pass in because we can use that over and over again once it's set up we can send as many emails as we want for it and it's not going to make any difference each time it will behave the same there's no side effects of using it likewise if it was something like a templating engine so if we're using twig for templating once it's set up we can render lots of templates with twig and we're not going to find that there's any problems doing that it should be the same every time or a router service that generates URL for us for instance so but we do have other things like this in our application so if you've got values that represent things or entities then each one of those is different we don't want one whole application we don't have one customer we have lots of customers hopefully so these are the sort of things we should create directly so each email message is different to the previous ones and we'll still see new keywords perhaps for those if it's a product when we're creating it, product has identity based on its on its skew it's not the same as we can't have one reusable product object customers same sort of thing we may not use new maybe we've got a named constructor that people quite like using nowadays we're using a static method to do that so we're saying customer register this it's still creating a new instance each time so we're not going to use DI for everything but for anything where it does make sense that is that kind of configurable service that we're going to make use of then I like to try to make sure it's used for everything and push everything right out of our application and configure it to somewhere else because as soon as we're not doing that we're tying ourselves into specific implementations okay and when should we use a container so if you're writing a small app that's growing when it becomes too difficult to manage those dependencies directly so whilst you've still only got like a small amount you can kind of keep on screen and keep track of there's no need to introduce complexity of using a dependency injection container once it starts to grow and become unwieldy and you don't want to create everything every time you want to be able to split it up into lots of different files and configure them separately then it makes sense to start using a container and the other thing time of course is if you're using a frame if you're using a full start framework like symphony or using something like Drupal 8 which will use the symphony service container then the container is already going to be that it's already providing services for you so you could use it in a way by saying you should try and avoid and say okay give me the container give me a service to create your own classes that make use of those services and tell the service container how to create them using those services that are already there for you so you tell it that you want to use a mail service rather than saying hey give me the mail the service out of the container so the main things for me is the kind of very important about dependency injection but it is very simple really as a pattern for creating objects there's not very much to it really but you should use constructor injection where possible you can use setter injection and property injection things like this but you lose some of the type safety documentation you get from using typepins and you also get this potential for objects to end up in inconsistent states and it also means you know that once it's constructed it stays the same if you're using something like setter injection then some of the bit of code in your application can change those dependencies under you at one point and then call it again and find that the behavior is changing between constructor injection gives you a form of immutability that means that once you set your services up how you want them to be set up they'll stay set up that way for that request and the other thing is that containers for assembling code only if they're not there to be used throughout the application they're there to help you with a specific problem of how you put all those objects back together okay that's what I've got to say today so thank you time for questions in a minute I just need to say a couple of things which was to promote the sprints on Friday so and I also need to say that so iCOS which is a sort of like a sister company of Central Ireland UK now with both parts the same group is running beers at the booth along with Lingo Tech at that booth tomorrow afternoon about half free so that's a booth 303 where there will be free drinks and snacks okay and you can evaluate this session of this URL here okay cool so does anyone have any questions at all yes yes so the question was can you use dependency injection in legacy applications and wrap them in that so yes you can certainly introduce it and there's certain things you can do so because you can still create your instances of objects of a legacy code it might be that then underneath them they create their own but you can kind of you could create the higher level objects in the container and start to work with it that way rather than you don't have to go full you know whole scale get everything out inject it back in and once you're getting the kind of higher level objects out of the container you can then start to refactor those in a way that the rest of the code doesn't say no about it just knows it gets one of those an instance of your legacy object and can start using it so in your new code you could start using it there you could also can start to I mean I wouldn't do it with new code but you could do things like wrap kind of a way of having static access to the container into your legacy code so you can sort of pull dependencies out of it at different points in that even though you haven't refactored the whole thing to use dependency injection so anyone else well thank you


What's up everybody? Jayce here for jayspeakscasebreaks.com. This is our last filler guys. Three random team select spots being given away here With this 21-22 Prisman be a hobby pack breaker we're 28. Now again guys Just like any other filler we'll randomize because we're names teams. We'll distribute the hits out of the hobby pack Then at the end we'll take the original list of names I bought in and the top three get spots into this team random And you'll have a chance to get some pretty big teams like the Warriors, Cavs, Thunder, Raptors at the top right there But you are guaranteed a team though no matter what so that's the good thing. So here we go guys dice roll it and It is a four to four eight times good luck One two, I think I got stuck two three four five six seven eight Lewis down to Lewis eight times eight times one two three four five six seven Mavericks down to the San Antonio Spurs And getting quick pack filler so no trading. I got some color for you guys. Let's see what we got here though LeBron and a it's nice to Jean-Tain Murray blue So hey a little more right there for the Spurs We're San Antonio Spurs at Lewis Now let's switch scenes and let's do the main giveaway now of course remember top three get in top three dice roll it it is a Come on round or There you go eight times again. This time. It's a six and a two eight times. Good luck one two three four five six seven eight Boom eight times eight times Actress at times for number four, which is Jose almost in there, buddy almost Unfortunately not in though top three though Lewis Lewis and Daniel Smith sneaking in there at number one. There you go. So top three are in Let's paste your guys's name into the team random here now and Coming up next though guys is the team random for 13 teams and that would So I'll select Pikachu number three. So appreciate you guys. Jasper's case rich calm


Hey everybody, it's Sam at Mixed Up Graph. Thank you for watching my tutorial today and happy World Card Making Day. So I do like to mark this day and to do that, I have made all these cards. So these ones here are using some of the edge dies from my latest collection. I want to show you different ways to use them. You don't just have to use them on the tower fold dies. You can use them on their own to create nice cards like this. So I've kept a kind of theme. You can see I've got those kind of rainbow colors throughout, but you can adapt these to any color you like. You can have them as more masculine colors. You can turn them into Christmas cards. It's entirely up to you. So if you do have the collection, you have the edge dies. I will link everything below and I'm going to show you them as well in a moment. But you will be able to create really nice cards like this. So you can see I've doubled up the balloon edge dies there and then I've used my large party stamp through the middle and I've done some embossing. Lots of stars and then Nuvo drops and bits and pieces. It's a very tactile card and you just open it up and inside there you have space to stamp and write your message. So this is a five by seven top fold which I've made myself. And again, I'll show you that later. I've got this one here using the stars and I've just stamped awesome through the middle there. And again, you open it up and you've got your space to write and they stand really nicely as well. And then I've got this one using the dragonflies. We've got whoop, whoop down the center. Again, lots of space, stands up really nicely. And then these ones here are using the six by six. So you've got those lovely butterflies. I really like this one. Yeah, it's your day. And then I've done some different Nuvo colors there which I'll show you. And again, you can see that one. And then this one, time to party and I've got the hearts all down the side and I've added glossy accents to all the hearts. So they're very shiny. And again, you can see inside there. So let me show you everything I've used and how you can make those cards. So these are my edge dies or border dies. So these are the excellent edges and this is the portrait. The portrait and the landscape references to the tower cards. You don't really need to worry about that. The five by seven in the landscape and the portrait, they're just five by seven. So they're gonna work on your five by seven cards. But you can see there, you've got the stars, the balloons and the flower on that set. And this one here, you've got the flowers which are a different style, the dragonfly and the presents. And the presents work great for birthday or Christmas. So that's a nice set. And then here you have the butterflies and the hearts which I showed. And you also have that wonderful big bow which would look great as well. Today I'm gonna show you using the flowers from this set here. So you would have seen the balloons, the stars and the flower. And then the flower is gonna be similar to this one that I'm doing now, but the dragonfly and the presents I used on the Christmas tower card which I've already shared. And then the bow again, you can see that one in other card styles. And then these are the stamps. So this stamp set here unfortunately is currently sold out. So we're waiting for more to come back in. But this is the one that I've used today. I love the yay. And lots of people are using that one. And they're actually fussy cutting it out. It looks really nice when you cut that one out. And then you've got the party there. And you've got the different things. You've got let's party or time to party. Whoop, whoop, which I've done, verticals. You don't just have to have it in that landscape orientation. And then you've got it's your birthday and you can have yay, it's your birthday. Or you can have it's your birthday yay. You can change all these around. And you can mix the two as well for those that do already have those. Okay, so because I'm doing this as a five by seven top fold. You know, you don't really tend to get those. They're not a common style because they're so tall. If you were to make that, you'd need 14 inch length card stock. So I'm going to make this one up myself. So I've got one piece here, which is five by seven. That's this piece. And then this piece here is five by seven and a half. And along that seven and a half inch side, you want to just score at seven. And then you're going to fold that. And that is basically now going to be the hinge for us to be able to attach this piece here. Okay, so what you want to do first of all is you want your actual edge die here. So I've got all the flower ones here. So you only have to run them through once. You know, if you're doing one color, it's not like we've given you one flower and then you've got to run it through six times. They are all there.  And I'm just going to grab some washi tape here. And you just want to kind of, but it should, because it's exactly seven inches high. It kind of, it clips itself on the ends of the cardstock there. So it's not actually going to cut there. It's just because it's hanging over the edge. So now I can just move this and I want to get it right to the edge like so. I'm going to pop some of my washi tape, just hold it in place. Now for the five by seven, you will need a larger format cutting machine because we're putting this in landscape. If you're using the six by six edge dies then that will go through a smaller ones. That's okay. So I've just got my plates here. So what we want to do is we'll partially die cutting. All I want to cut is the edge of the flowers here. I don't want to cut any of this cut line and these are overhanging anyway. But I'm just going to sit, I'm going to turn it so it's this way actually, just so I can see it a bit better. Make sure everything's nice and straight. And then I'm just going to sit my plates over like so. You want to make sure they cover all of that flower detail there. Like I said, these are overhanging so it's not going to cut that paper anyway. But I just don't want it to cut this line here. I'm going to pop that in here and let it grab the plates. I'm going in this way. I know it's the longer way in but it's just going to cut that edge and it's not going to touch any of the cardstock there. So you'll feel it when you get that. So I'm going to carefully just take that one through. So now I remove this, keep that tape on there so I use it again in a minute. That should just now fall away. And it's just cut out all of that detail for us. So now we're going to repeat that on this side. So again, I'm just going to let it catch there. Get it right up to the edge and then pop that down. And then again, plates on. Just make sure they're covering all of the flower. Plates are nice and straight, that's through. Now that's all the cutting done. Take that all away and then take that away. So now we have this cool piece which has those two edges on. So next I'm going to stick down my flowers. So I've died cut already all of these and I've got two of each color. So I'm just going to arrange, you know, I think I'm going to have them opposite. So I'm going to have the red at the top on that side and then I'm going to have the red at the bottom on this side. And then I'm not too worried about doing them actually in rainbow order. I'm just going to put them wherever. So I'm just going to use some of my quick grab glue and I'm just going to pop a little bead of glue in the center there. Line up the outer edge so you get a nice even white border and then just pop that in place. I'm just going to quickly stick them all down. Okay, like so. Now I want to decorate it. I'm going to keep it like this before I stick it to the base. So I'm just going to grab my stamping platform just so I can get a nice crisp image. Pop that one in there. Then I'm going to pop the magnets on the flowers there. And then I'm going to grab the stamp set. And I'm going to see if the, yeah, will the yay fit in? No, it won't quite. Let's do the let's party again. So I think I heat emboss the last one. So we do, we stamped this one. I've stamped it in black on the six by six. So yeah, this is, let's do it in the five by seven. So I might have let's party from the top and then have four. And now actually I do get your birthday. So I want to make sure I've got an equal kind of white at the top and at the bottom. So I'm going to stamp this all in one go. Mine has stained my stance because I've used red pigment ink or pink pigment inks, you know, in different cards. So you can get rid of that, but it doesn't affect the stamp itself. Okay, I'm happy with that. So let's pick all that up. I'm just thinking that up. I just dropped my ink pad on the lids there, but it doesn't matter. This is a nice juicer. I've new, not long ear re-inked this one. Lay that one down. That's nice. Let's do one more. That's why I like the platform because you can go in again and there we go. That looks so nice. I love that stamp. Okay, so this is the five by seven and a half piece. So this is where I said at the beginning.  And once you've added a mat layer inside, if you choose to, you might like that. It's kind of backed behind the flowers. But what I've done is I've just trimmed in a bit from each side and then stuck it. So if you kind of get a pencil and where, if you pull it down a little bit from the top there, put a pencil where it kind of starts there and then I'm going to do it there. And then with my trimmer, I've just trimmed that all off. So that's why I've given you the measurement for the five by seven and a half piece. But if you do decide to take it off then you might want to cut it to that size straight, you know, from the beginning. So you're not wasting any card stock. But now I can just add some glue to this bit here. I can add my mats and layers inside the card but I'll do that later on. And then that will line up now perfectly with the top there. And now it's not backed but you just see the flowers. I prefer it this way for the way that I've done them but if you're going to add a mat layer, like a coloured mat, then the flowers would really pop out anyway as well. But I just like that. I just think it looks quite unusual. It's just a little bit different. And now you have your card already for you to do some more mats and layers and obviously it stands out nicely there. But I do want to finish it off with some Nuvo drops. So these are the ones that I've been using on all of the cards. They were the closest colours I could kind of get to the papers that I have. So I'm just going to do a little cluster up here, maybe have a few more cascade down. And I'm also going to add a sparkly little gem in the centre of the flowers there as well. Okay, so there is the finished card. You can see the sparkle in the centre of the flowers which looks really nice. I think it works well with the Let's Party and then you can see all the glossy accents there which are drying now so I don't want to move it too much. And I think it's turned out really nice. So I hope this has given you some more inspiration on ways to use my edge dice and happy World Card Making Day. Thanks for watching. See you soon.


Yes, so thanks everyone. Thanks for organizing and like accepting me to give a talk. I'm Vladimir Hannesian and I'll be talking about the enhancing spin-spin correlators in mixed field icing due to stochastic resetting. So the thing is, I mean, I got curious in the stochastic resetting processes motivated by my collaborators, Petresca and Sandev and I just started kind of learning about this and those are some of the results that we got along the way. Nobody... Go forward, I mean. It's okay, I'll just... Yes, try with the... I'll just try from here. Should be fine, I guess. Yeah, I'll be resetting it all the time to the beginning. Okay, so I'll give kind of like a quick overview on classical and then also quantum resetting. Then I'll introduce the model of mixed field icing. Then I'll also introduce the reset protocol there and I'll be talking about two different resetting functions. One of them is Poisson resetting and the other one is a power low resetting function. Well, so I mean, by now I guess everyone is familiar with the idea of stochastic resetting in classical systems was kind of like introduced in the 2011 and the idea is you have some diffusive process and beside the diffusive kind of like known process you add some constant probability for the particle to return to its initial condition. So this is like a constant probability at every position in space and time. And this is the delta function that is for the resetting to the initial state and this was explained in the first day how it works in classical systems. It gives a rise to a non-equilibrium steady state and also for example, if you kind of like monitor the mean squared displacement, it's fine with resetting, which is not the case if you just have a diffusive process then it diverges. Well, it's obvious that I haven't given like a talk in a long time in front of people. So for quantum systems, it's kind of like a similar idea. It's quite interesting that it was introduced by the same alter of the classical resetting in 2018. So now what we have is some quantum system, the dynamic that's evolving with some Hamiltonian H and you have some initial state psi zero and then you evolve the system unitary, of course, but then at every time point, you give it a constant probability R for the system to go back to its initial state. So you have something like unitary evolution and then a reset can happen to the initial state. And now I won't go into too many details, but what really matters here in this reset is basically how much time has passed since the last reset all the way until TM, which is a measuring time here, like the time where we're interested about the system. And this can be kind of like casting a renewable equation concept where you kind of like get the expression for the density matrix and also for the expectation value of an operator in this form. So kind of to understand quickly what's this, this is kind of like a probability, it's a sum of probabilities. So this is the probability that the system will not be reset all the way until the measurement time where the second part is you're integrating over the resetting to happen at each tau here with a certain probability. So if you have a constant probability R here that gives a rise to a Poissonian resetting function and then I'll introduce later another PDF which will bring some interesting properties in the system. Okay, so here are similar to a classical system. What happens is that you're getting a stationary state for the density matrix. This was also kind of like introducing the 2080 paper of quantum resetting. And the interesting thing is here that you know that if you let the system evolve uniterially at the very late times like if you take the measurement time at infinity you get the diagonal basis. However, here once we have resetting in the system we kind of like get off diagonal terms that lead, I mean that give rise to some kind of like non-trivial correlations in the system and also would manifest that into the expectation values of the operators which is something I'll be talking about. Now the model that we are studying though this was kind of like very optimistic it's the mixed field ising where you have like a chain of spins and you have coupling between neighboring spins in the ZZs and then also you have like a some type of field that's like magnetic field in the X direction and also in the Z direction. Here those capital letters are basically same as the Pauli matrices X and Z but it's just kind of like a condensed version. And like depending on the parameters there are different models. So you can have like the non-interacting which is kind of like a trivially solvable and then you have the interacting model which has a chaotic regime and also transversing model where the HZ is zero. So I mean we plan kind of like to talk about everything but there won't be time for that. So I'll focus mostly on the non-interacting system which even though it's non-interacting it has some interesting properties thanks to a recent paper that was by Matteo Perfetto. Okay, so now the reset protocol is the simplest one that you can have. Like as I said I'm learning about this so we just take the simplest one where we start with the state that it's all up and then it's also the reset state. So we set the system to an all up state and then we let it evolve. I mean how you can kind of like see this if you're setting protocol physically is like you have some pulses, the stochastic pulses or very high magnetic field. So for example if you turn them on regardless of the spin configuration it will tend to kind of like flip all of the spins up. And they're also, I mean also like the resetting is kind of like some special type of measurements where probability one you kind of like measure the system into the initial state. And then for some other reset protocols you can check for example like one of Perfetto's papers. Yes, we said that. Okay, so I said like I'll talk about non-interacting systems here, the magnetic field this is some constant that will appear but just so you know that it's kind of the combination of the magnetic fields and those are the observables that we will be interested in. So it's the one point function of X and Z and also like the two point function of X and Z. Because we don't have interacting system they don't, so this is the time evolution they don't depend on the position. So even, so that's why no I or J appears here. Sorry, I have a conceptual question. What is the meaning of a two point correlation function if the spins are independent? Wait for a second. Okay, wait. Yes, so this is the whole idea. So for example you can compute all of those things and for example you compute the full two point functions and you can analytically compute those things as a function of the magnetic fields and also the resetting rates. So this is already in the stationary state. And then here we have the X, X correlators. Here we have the Z, Z correlators. And we see that kind of like some interesting thing happens that depend on the resetting rate. I mean it's kind of like not difficult to see that. Like here initially the state when, when magnetic field X is kind of like zero the spins are really just all up and the reset rate it also brings them to all up so nothing happens. But here you get kind of like an interplay of scales because you have this reset rate which is kind of like a very strong magnetic field along the Z direction but then also you have this magnetic field along the X direction which is a transverse one and that's why you are getting those kind of like bumps. But this is the full one. This is the full one and now we didn't even pay attention because we thought like it's not interacting systems so like why considering the connected part because there won't be a connected correlator. And then there was like Mateos and Perfetto's paper and some of their other collaborators and basically a very recent paper. It's a very interesting one. So they realized basically that if you compute the connected part in the stationary state there is kind of like an emergence of correlation of connected correlators. So they were studying this part. They were studying the ZZ correlators and they're also kind of like interesting but then they saturate and that's because like there you don't see the interplay between the X, the X. And then because before we were thinking about the XX correlators in an interacting system we thought okay let's see what happens here. And then what you can realize is that basically here some maximum of correlations happen and they depend on the reset rate. So we thought okay let's see like how is the dependence of this maximum. I mean the maximum of the fields where this maximum happens and also like the maximum of the correlators as functions of the reset rate are. And then an interesting thing, I mean it's just the derivative to zero and it's interesting that it's kind of like you get some optimal reset rate at which the field for maximal correlations happens but also even more interesting you get kind of like maximal correlations at the given reset rate here. So this is some row star. Okay so like this is kind of like the dependence of the maximum of the peak on the reset rate and you see that there is kind of like enhancement of those correlators at some reset rate. Good so here is kind of like in an interacting system but they won't present this it's on the right side and you see it kind of like you get like much richer structure when you turn on interaction because there is another energy scales that appears and that gives kind of like rise to some interesting things but that will be for some other conference I guess. And now as I said because this is kind of like a non-mercovian processes conference we will be talking about another probability for the reset to happen and that's a power law. And in order to analyze that we need to use kind of like I mean we were using methods from the review paper by Majumdar of 2020 and that we can extend it to operators and this is again like thanks to Perfetto which pointed it out to me. And the idea is here that this p star is basically the survival probability. The survival probability means that the state won't be resetted all the way until time t. And now for this to get like a stationary state the only requirement is for this integral to not diverge. And then also you're getting kind of like expectation value of those operators. And now why we are interested in this is because like in classical systems there were some research studies of the power law function which is this one and this is the survival probability. And even more recent study kind of of one of my collaborators sounded so they explore kind of like what's the dependence of the diffusive classical process on this parameter gamma. And they saw some different interesting regimes when you monitor the mean square displacement. So basically if gamma is smaller than zero then you get kind of like some diffusive process and that diverges but then for example if you have other extreme gamma larger than two then you get like a stationary state. And now the idea was like just to see how this manifests in quantum systems. This is a computation that we can do for quantum systems and then we realize basically that due to the divergence of this integral for gamma smaller zero also in quantum system sorry here it's one. So it's gamma smaller than one or zero then we have like it's not defined the stationary state is not defined. And then we can do the whole thing for the correlators. For example with this power law it's expressed by the tritium conflict hypergram metric function. And then we can again like study what are the maximum correlations as a function of the reset rate but now also this gamma. And here we see and this compared to the exponential behavior and then the interesting thing is we see for example if you go to larger resetting rates for example the exponential one you have kind of like this maximum decreases it's kind of like logical because if you reset the system with a higher rate that means that it will be aligned more and more in the Z direction so you lose the correlators in the XX operators. But here for the power law it seems it kind of like either go ups or it saturates or and we are still not sure what happens even at higher things and that's something to be checked. Well, I maybe went a bit too fast but thanks a lot and you've seen this like a couple of times but anyways, take some attention. Thank you very much for the talk. Are there questions here? No, there is nothing. Oh. Sorry, I have no, no, you need to have the microphone. Sorry. So I have one curiosity about the last thing that you presented. Is it possible to cure up the regime gamma smaller than one to introduce some sort of cuts in normalization in the resetting protocol such that this regime is well defined the steady state is well defined? Because when I think about the easy model for instance if I have long range interactions if I have gamma smaller than one then I put the cuts in normalization and then the energy becomes. Gamma larger than one? Smaller than one. Smaller than one, you mean in the power? Yes, in your case is it possible at all or is it just curiosity, huh? I really don't know, like I really can't say because this is something that. You try, you put that in normalization and you check. This is something that's quite fresh, right? I mean it's like maybe a week. Yesterday night, you know, I did it. I mean to be fair, like some of the results were like two days ago after I talked with Perfetto and Mancetta. I see, okay. So add the normalization and check. That's why it's very useful to have this like kind of like in person conference and I really appreciate that. I don't know, but I mean, okay. So then given also, we are running way too late. I think let's thank you all. We thank you again for the talk and we go towards the last. Yeah, what is this? Oh, okay, okay, so we have a, I don't know, bread, I don't know.


Live from Las Vegas. It's theCUBE, covering Knowledge 16. Brought to you by ServiceNow. Here are your hosts, Dave Vellante and Jeff Frick. Welcome back to Knowledge 16, everybody. ServiceNow's big customer conference, about 12,000 people registered here this year. Mike Nappy is here. He's the Senior Director of Product Management at ServiceNow. Mike, welcome back to theCUBE. Good to see you again. Thanks, Dave. It's great to be here. I got the pleasure of seeing a little preview at the Financial Analysts Meeting on Monday. People are very excited about ITOM. You guys have made some acquisitions in that space, but give us the update. Yeah, so ITOM's actually been around, some of the technologies have been around since the early days of ServiceNow. Really, I'd say our current strategy towards the market really started with the acquisition of Nebula back in 2014. And that acquisition was really strategic for us because what it'll allow us to do is take this premature ITOM market and really disrupt it. And the way we're disrupting it is we're viewing everything through kind of a services lens and ServiceWatch allows us to do that. Instead of managing at the compute storage and networking layer, which is kind of the traditional ITOM market for the last couple decades, what we're doing is we're taking our service DNA, if you will, and we're applying it to the world of infrastructure and operations management and managing services directly is kind of the primary object. So ServiceWatch brought you automated mapping and my understanding is that that's dynamic to change. Is that right? Can you explain that? Yeah, that's absolutely right. I mean, the idea of having a service maps in your CMDB is not a new concept. It's been around for as long as CMDBs have been around. But the traditional methods of building those services are incredibly manual and the resulting service definition is brittle. If the infrastructure changes, it's some poor soul's job to go in and do the care and feeding of that service and make sure it stays up to date. So the bottom line is it's just not really scalable. And so people gave up on service mapping pretty early on and just it's just not really practical. ServiceWatch really changes that because not only does it automate the mapping process itself and make it easier, but once it's mapped it and it's stored in the CMDB, ServiceWatch itself takes care of updating itself when the infrastructure changes. So now you got a service map that's actually reliable and you start building automation around it. So break down the ServiceNow ITOM portfolio. What's in the suite? Yeah, so currently we've got a set of technologies for taking data out of our customers' hybrid infrastructure. So we've got our traditional discovery product, which is the primary way that our customers populate their CMDB. So that runs out across the network and essentially finds everything that's connected to the network and records it in the CMDB. We then have ServiceWatch mapping, which allows you to describe the relationship between all those artifacts and a business service. In addition to that, we've got orchestration. Orchestration is our primary automation tool. It's essentially an extension of the ServiceNow workflow engine that allows you to drive work into external systems from ServiceNow. And then on top of that, we've built an event management product and the cloud management product. Right, okay, so I want to go back to the link between infrastructure and apps and ultimately the business process. So how are organizations taking advantage of that? Because in the old days, at least, people who have a business process, they'd have an application portfolio and they have a bunch of infrastructure and they really didn't understand the relationship between the three. There was no link between the value of an app, the infrastructure was running on and how it served a business process. And it sounds like you're changing that. Describe how customers are taking advantage of it. Absolutely, yeah. I mean, it turns out there's actually more use cases for having the service mapping than we even envisioned at the time. The original and kind of primary use case is when you have an understanding of the service and what it's comprised of from an infrastructure standpoint, if something goes wrong in a data center, you lose a server or a database, it gets locked up. You can immediately understand what the impact is to the business because you understand what services that database is actually supporting. This is huge in terms of triaging your response, figuring out what do we need to tackle first. And the other aspect of it is just because you have that understanding of all the dependencies. An operations engineer is able to understand root cause of an issue much more rapidly so that they can fix the issue and get the service up and running. So the kind of primary use case for the service mapping is around service availability and keeping services operational. But we've had customers that are using it for data center migration planning. They wanna just inventory all the services in their data center before they move. They're using it for audit, for BCDR activities, compliance activities, you name it. The bottom line is that having a good understanding of how your business services are supported by your infrastructure is absolutely huge. And I think just to add one other, you talked earlier with Sean Convery in the security business unit. Security's another prime example of where understanding what the service impact is of a security event is just huge. Well, as I was gonna say, Lauren Dutson from EY talked about, people have no idea what the total cost of an application is when they're making a decision whether to end of life and swap it out or whatever because they don't usually calculate all the back end processes behind just the server license and the maintenance fee that's actually supporting that. And then they can make an informed decision based on the business value and supporting whether it's worthwhile to keep that in play. He said that their eyes are like, wow, we had no idea. It was just a bucket of money in the infrastructure before. Yeah, yeah, that's another great use case. I mean, just understanding the cogs behind a service. Another thing that's happening is our customers are starting to look at a cloud strategy and moving some subset or in some cases all of their existing services into the public cloud. So first understanding how those services are currently comprised really informs how they wanna do that migration strategy, how they wanna put that together and what services they wanna move first in the cloud versus others. So, well, two points. One is you're right on on the value piece. That's very clear. People used to struggle with sort of the value of IT. You're sort of demystifying that clearly. I wanna understand more about orchestration, the automation and the cloud management. Can we unpack that a little bit? Kind of what's the difference between sort of orchestration and cloud management and what exactly does service now do there? Sure, absolutely. So orchestration first off is kind of a general purpose automation tool. So it's like a Swiss army knife. You can pretty much use orchestration to automate any kind of process. On top of orchestration, we built cloud management and it started off being fairly simple automated provisioning of VMs in Amazon or in VMware. And the idea there would be that you'd be able to templatize certain types of VMs, put them on the service now service catalog and a developer could walk up to that catalog, order the VM they wanted and it would automatically get provisioned in the cloud. Huge use case. There's a lot of companies out there are still doing this manually and it takes weeks to provision it. We would do that in minutes. We've evolved way past that now. We now support not only Amazon but as you heard earlier this week, we have a partnership with Amazon around Azure and other cloud providers. Microsoft around Azure. You said Amazon around Azure. Oh yeah, that's a good point. Sorry, sorry, Microsoft. You want to make that? My ears went, whoa! Did I miss some news? Yeah, Microsoft around Azure. So in any event, we can provision not only VMs in those environments, we can provision entire services in those environments but the flip side of it as well is very important. We integrate with those environments to be able to generate a dashboard that shows you cost and utilization across your company of your cloud providers. And that's really huge for making informed decisions around how am I going to use my different cloud providers? It's kind of like supply chain management. It's huge because you can get those metrics from any one individual cloud supplier but as you do inter-clouding, we like to call it sometimes, you don't have an apples to apples comparison, you're providing that obviously. And then the ITAP acquisition gave you entrance into OpenStack, Zen. And then you're, people are sometimes confused. Is service now doing what Chef and Puppet do? You can but you don't have to, right? That's right, no. In fact, we have a good partnership with Chef and Puppet and other configuration automation tools like that. And our orchestration can certainly connect to those environments where our customers have them and connect them to service now processes. And Ansible too, we don't, sorry, Red Hat, we didn't mean to leave you out of the discussion. You don't care. Yeah, no, we're pretty agnostic on that. Orchestration where you put the slider bar, we can go right to the last mile to the metal or we can go to another orchestration product to drive that. So the planes are backing up here in the cube. A lot of people want to get on, Mike, I'll give you the last word, just sort of Knowledge 16, iTom, give us the bumper sticker from your perspective. Yeah, well, iTom's really huge for service now. We've seen amazing traction over the past year. We've essentially doubled our attach rate with our existing install base. And this kind of message around service-centric operations management is really resonating with our customers. The holy grail that everybody wants is that service help dashboard. It shows you all your mission critical services and the real-time health of those services. And that's really what we're after. And it's really disrupting, I think, traditional iTom as we know it today. All right, Mike Nappy, thanks very much for coming back to theCUBE. Appreciate your time. Absolutely, thanks, guys. All right, keep it right there. We'll be back with our next guest. This is theCUBE. We're live from Knowledge 16. We'll be right back.


Hi guys, welcome back to our Kickstarter for Discover Hungarian Wine of Is There Friendly Guide. We just added a new tier and I think this is going to be really exciting for you. So my friends at Kniv Bar, in English Kniv Bar and Restaurant, I think in English it would look like Koni V bar. But Hungarian is Kniv Bar. I've offered to do a two hour tasting package with a signed special edition copy of our book. So this is really cool. This tasting is normally two hour tasting for 50 euros. So it's around 55 US dollars. And we have a special price on that and a special deal coming up. To get this tier launched, we have a flash sale going on right for the next 36 hours starting at 10 pm central European time tonight. You can get the two hour tasting and the special edition signed copy of the book for only 76 Singapore dollars. That's 50 euros, 55 US dollars. I'm sorry. Sorry to put it in Singapore dollars. That's where our company is registered. So that's what we had to do. That's going to last 36 hours only because after that, the price is going to go back to the regular full price. Jump on board, scoop that up while you can. This restaurant is phenomenal. The food is great. But the cool thing is you're going to find rare and unique vintages that you can't find anywhere else in Budapest. A lot of these bottles are exported and our friend, the owner, picks up these scoops up these bottles before they even make it overseas. So you're not going to want to miss it. Check it out. Get that tasting. I will see you soon. Share this with your family and friends. We need to get this book launched and make sure that we bring hungarian wines to the world, but it's going to take all of us. So back us, share it with your family and friends, and I will see you with the next update.


Happy Tuesday and welcome back to phone phenom every single Tuesday where we come to you to make you better on the phone. I believe that the telephone is the number one sales tool on planet earth and that most people use it incorrectly. So today for all you new agents out there, we're going to talk about the top five mistakes that new insurance agents are making on the phone. If you're watching right now, I would love to know your thoughts below. Okay. So I'd love some comments today during today's show. I'd also love for you to tag an insurance agent that you think is making this mistake. Maybe they're in the cubicle beside you and you've heard them make this mistake. Dude, let's let's remedy that. Tag them and we'll fix it from now on. So the top five mistakes, let's jump in. Okay. So mistake number one is a, that a lot of ages make, you're probably making. I'd love to know if you're making it. And that's a poor greeting where we're unsure of our greeting or greeting changes every time. Or we're not saying the same aggressive, confident, enthusiastic greeting that puts you in control of the call. So most people struggle with the greeting. Most people say we're trained, right? Cause most telemarketers do this. And that's the thing about the, about life in general and business.  In fact, generally speaking, what I think about it is if someone is doing something, I tend to think about doing it a different way naturally. I don't know why, but that's just the way I'm wired. Okay. So a poor greeting, for example, is this Betty? Hello, are you Betty? Hey, hello, I'm looking for Betty. Is this the Smith residence? You know, whatever, right? Those do not, those are not confident statements to open up a call. That's a question, right? So instead, instead, hello, Betty, right? Hello, Betty. Also to include in the poor greeting, most agents will say your first and last name from a certain insurance company. Instead, it's too much information, right? So instead of that, a solid greeting that is not a poor greeting is hello, Betty. This is Cody. I'm getting back to you. Okay. That is a strong, aggressive, confident, enthusiastic greeting that you need to be using. Okay. That's the first thing out of the top five mistakes. That's mistake, the first one of the five. And I would say that most of them, I would say that we're going to go from one to five in the order of importance, as in five is probably the most common one, right? And the one you should be doing. Okay. So poor greeting, you can overcome it. I can call Keith and have a poor greeting, but I can also overcome that poor greeting in the call. Okay. So there's other ways, right? But it doesn't get the call started off correctly. And they always say Harvard says you have four seconds to get someone's attention when you make a call. And a poor greeting exhausts that four seconds. So let's stop doing that, number one. Okay. This is phone phenom, in fact, right? Mistake number two, a lack of control. I would say that naturally, most people are not in control when they make phone calls. In fact, the prospect or the customer is typically in control. When it doesn't have to be that way though. Okay. So you need to be in control. Whoever's in control wins, seller be sold. Whoever is in control will get what they want. I believe a sale is made when I believe that I'm going to make the sale more than they do. I also believe that I'm not going to make a sale if the prospect believes in the fact that they're not going to buy more than I do that I'm going to sell them, right? I think the same thing we said on the phone. When I believe that I'm going to get what I want and I believe that I'm in control, there's a better chance of me getting what I want just like you when you're calling someone and most people are not in control. That's the reason you get objections. That's the reason you end up with extremely short phone calls. That's the reason that a customer lies to you. That's all those things typically goes back to the fact that you are not in control, which is mistake number two, a lack of control. So I would encourage you to be in control of your phone calls. That'll remedy a lot of these other mistakes, right? A lot of people make mistakes in the call or they say the wrong thing or they hesitate. They don't know what to say. Just being in control and a controlling presence on the phone will actually alleviate some of the mistakes that you have on the phone if you are in control and being that way. So that's tip number two, lack of control. Number three, out of the top five insurance mistakes that new insurance agents make on the phone, number three is that we provide too much information. I think this is a major problem in the insurance industry and that I also noticed when I was a brand new agent is that insurance agents tend to, they tend to, we tend to vomit as I'm about to do, right? As I'm coughing, right? We tend to vomit. We tend to, we tend to puke on people. We tend to provide too much information. If you give them everything, then guess what? If they ask you how much is it and you tell them. If they ask you this, this, this, this and this and you tell them and you're not trying to sell over the phone, then guess what? They don't need you anymore. If you give them too much information, what's the point of them sitting down with you if they already know what it cost? If they already know what company you're going to put them with?  Most people fail because they don't get in front of enough people, hence a personation, right? And that comes from the fact that most agents do not get in front of enough people and I think a lot of it is that we provide too much information on the phone. Naturally, we want to just give away information when in reality I want to give as little as I can. And I even believe in this in the sales process, not even just over the phone. I believe that when I provide too much information, they have a less likelihood of making a decision because I'm clouding their brain from actually being able to make a decision and decide. Same thing on the phone. If I provide too much information, there's a less likelihood that they're going to pull the trigger and make a decision. I believe that I want to give them just enough information for them to make a decision, not any more than that. So whatever that is for you, quit giving too much information away. Mistake number four is not barreling through mistakes. I always think of mistakes as like a giant or I'm sorry, objections. I always think of objections or mistakes if you screw up, right? Doesn't matter. You can't think about it. Same thing as an objection. I always think of a mistake as a giant boulder is dropped between me and you. And I got to get to you, okay? You can barrel through it. You can step around it, okay? But if you try to fight it and you try to like push it up the hill, right? It's going to make it a little tougher.  So when they give you an objection, most agents believe it. They give validity to it by when someone says I'm busy and you say, well, when's a better time? You are giving validity to that lie because they ain't busy, right? Or everyone's busy. So what's the point in saying it, right? Or they wouldn't answer the phone. So just barrel through, step around, ignore it, and move forward. Be in a state of agreement. Finish with a question. And like we said with tip tip mistake number two, get back in control, okay? So that's what I notice a lot is giving validity or not barreling through or ignoring or moving past an objection. That's a big one. Objections tend to paralyze insurance agents on the phone. They don't know what to do. They don't know what to think.  Are they really interested? Oh my gosh, these leads are horrible, right? They're supposed to say that. It's human nature. It means the lead, like honestly, what most people don't notice and what most people don't talk about is I like objections. My best clients were the toughest ones to sell. My best clients gave me objections. If they were too easy or they meet with everyone or they didn't give me an objection, it bothers me. It worries me.  I may not keep this client forever because somebody else is going to come in and they're going to go with the next salesperson that isn't near as good as me, but they buy for everybody, so who cares, right? I prefer that they're tough. So view an objection as a little bit of resistance because when they buy they're loyal and that's who you want. So just barrel through it and get them, okay? So mistake number five is I believe that great salespeople, they don't ask someone to do what they want to do. They don't say, are you interested in this?  What great salespeople do is they tell you, okay? You need this. You want this. You can afford this and we need to see if we can get you approved. What's your full legal name? I didn't ask if they wanted to do it, right? This is the best decision. It solves your problems, correct? You need this. You want this. This makes perfect sense. This is what you should do. This is what I recommend. This is what I'm prescribing to solve your problem and that's mistake number five is most insurance agents aren't, they don't tell someone what they should do, okay? They ask them, well, what do you think, right? That's dumb. What do you think makes sense? Does this make sense to you? Are you interested? Do you like this?  So that's the top five to run through them again. Top five mistakes that new insurance agents are making on the phone, okay? Poor greeting, lack of control, too much information, not barreling through objections and not telling someone what they should do. You fix those mistakes and you will be a phone phenom, okay? Have a great rest of your week. Thanks for watching Phone Phenom. Appreciate you tag an agent below that needs to hear this message and which one, I'd love to know really quick, comment below which one of these do you struggle with the most and which one are you going to fix moving forward?