I was starting late because of my ghost short, then we'll be on time. I'm really excited to be here. So I took a selfie with the thing, and I'm really mad, like I'm really mad at making slides as you can probably tell they're not very great, especially this, like this, you're never supposed to do like a vertical photo. So I rotated it to horizontal. So it still doesn't look very good. Anyway, as Jeff was saying, my name is Aaron Tatos. I'm also known, I'm also known as Panda Love, and this is what I look like online. It's my online, online photo, that's me. Two cats that I love very much. This one is Gorba Jeff Puff Puff Thunder Horse. He is adorable, and I love him. This is the other one, her name is C-Tac, C-Tac Airport Facebook, YouTube, Instagram, Snapchat. And we just made for that because she does not care about her name at all. So that is her name. And I also noticed that we have some cats out here on the building, which I think is very, very cool. So yay, yay, cats here. And also I have brought stickers of my cats with me. So if you want to come say hello to me and you don't know what to say to me, say, Aaron, may I have a sticker? And I'll just say, yes, here, have a sticker. And then you can either end the transaction here. Or ask me other stuff if you want. I am, in fact, on the Ruby Core team, which is responsible, team responsible for developing Ruby language. I am also on the Rails Core team, which is responsible, the team responsible for developing Rails. And you may even remember me from such talks as Katrina's talk yesterday, where I am, in fact, famous for remembering maximum-signed 32-bit integer. Which is this. I work in a very small company called Git Hub. You may have heard of it. We got acquired recently, and I actually had a change to my desktop background because of that. It is the only legit company I've ever worked for. I love Git, but I will not force push it on you. So people tell me that I really need to branch out on my puns, but honestly, it's just so easy because, like, oh, sorry. It's just so easy because we have, there's another window to do a crash. It's just so easy because we have a pump channel, it works so I can just go in there and cherry-kicks. But I guess what I'm really trying to say is that I'm not a big fan of websites, like buyer stuff, and how to work for us, et cetera. So anyway, yesterday, Git gave a very interesting talk, and he was talking about self-promotion, and I decided that I needed to do more self-promotion.  And she told me, unfortunately, I just can't give myself a promotion like that, so I thought, all right, well, I guess I'd better do better, I'd better do a different type of self-promotion. So this morning, I took my selfie and tried to airdrop it to beat. It was exactly what I wanted. This is a type of self-promotion you do can do. Anyway, I love going to networking events, especially wireless networking events, but unfortunately, the Wi-Fi doesn't work here so well. I decided to do personal networking and tether with my self-promotion. Sorry, I don't write any of these jokes for you, if you're all for me. Anyway, I love local, I love supporting local businesses and local stuff, so every time I go to a new place, I try to have local things there. So yesterday, I decided to have local beer. I'm gonna taste the Rocky. It was delicious. So thank you, all right, so I'm from Seattle, which is an elevation is 187 feet, so it's very close to, pretty close to sea level. Here, we're here in Denver, Denver's elevation is Denver's famous for being a mile high city and we're around 5,000 feet up here. And it's actually really good for a speaker that are coming from out of town because it means that we're under a lot less pressure. And so do you from out of town, like some of you from Europe and stuff, so feet doesn't make sense, so I translated this into furlong. Anyway, thank you, thank you, for having me, I really appreciate it.  So one thing I wanna do, though, is how many of you are here from Turing, how many of you graduated from Turing? Yes, yes, that's amazing, amazing, congratulations. That's really awesome. You passed Turing, yeah, now Turing, sorry, I need to promote, I feel like Jeff isn't doing enough to promote self-promotion here, so I'm doing that thing for him. Okay, all right, all right, let's actually talk about some technical stuff. You paid good money to be here, so I feel like I probably haven't done that. All right, so this talk is titled, the view is clear from here. I'm gonna be talking a bit about Ruby and I'm also gonna be talking a bit about Rails, so we'll talk about Ruby stuff and Rails stuff.  And I know some of you here are not necessarily Ruby or Rails engineers, but I also wanna present some just general software engineering practices too, so that if you don't do Ruby or Rails, at least you can implement these practices in your own projects too. So Rails is an MVC framework and for those of you that don't know, MVC stands for model view of controller and the way that these components actually work together inside of a Rails system is first a request comes in, the controller handles the request, the controller asks the model for data, the model returns data back to the controller, the controller passes that data to the view, registers an HTML, passes that back to the controller, and then finally sends it up to whoever made the request. Now, many years ago, I worked for a company that was building a system to do pop-up locking and the system that we developed there was, it was basically a pop-up locker, but we actually called it a a modal view controller. Thank you, Jeremy. It controls modal views. This is different from total MVC, I'm glad I got one person. All right, so in Rails, the different parts of the system are, here we have the controller that's called action controller, the model area that's called active record, the view area that is action view. Today, we're going to talk about that is action view. Today we're going to focus on the, I usually typically work on active record, and if you see many of my presentations, I'll be talking, I talk a lot about active record, but today I want to focus on the view layer, which is this action view area here. That's the place we're going to talk about today. So, as I said, we're going to talk about action view. Action view has a few different responsibilities. Basically, what it does is it finds templates, compiles the templates, and then executes the views, and we're going to learn about all these different processes. And the first part, we're going to talk about finding templates in detail, but essentially, action view will look for files on your file, templates on your file system, and then compile it. In other words, it will traversal your file system. Wow! Yes! It energizes me. So, let's talk about these view templates. In Rails, we use a thing called ERB, and by default, Rails uses ERB. We're going to talk about ERB today, but in general, all the things I'm going to say here applies to all templating languages, not just ERB. So, ERB was originally developed by Evan Stecchi. He also developed the DRB module, which you may have used. This is an example of an ERB template. So, basically, we just have some HTML tags here and then a couple of these special tags, which all they do is they call a function and then return the value and print that out. So, this is what a template looks like. Now, the way that we... If you've done any Rails development, I'm sure you've seen this. The way that we actually compile these templates is we use ERB like this. We just say, hey, read in the file, call ERB.U that actually compiles the template, and if we say, puts template.source, we can see the source code of the template and then we can actually evaluate the template. Now, all compilation does is it takes that template that looks kind of like HTML and converts it into a Ruby program. That's all it does. So, if we look at the source, if we actually print out that source, it'll look something like this. So, this is the compiled source and it's not the prettiest Ruby code that you've ever seen, but it really is just Ruby code. And if we execute this, we're gonna get an error, but the reason we'll get an error and it's pretty clear from this code is we haven't defined a render form function or a link to function. So, when the code executes, it's gonna blow up there on those lines. So, in this example, what I did is I just defined the render form function and the link to function. These are just functions. And then we can actually execute the template and it'll output the template, the results of the template. So, we can see from the output, this is just a return value of it. So, you can compile the template and execute it all outside of Rails.  And we saw that ERB has a couple translations. There's two, there's the one up at the very top that it just executes something and then outputs the data, the return value of that execution. So, whatever Ruby expression you put in there, it runs it and outputs the return value. Then we have another one here, that second one, all it does is it executes a Ruby code. It doesn't output the return value at all. It just executes it. So, what I wanna show here is a challenge for capturing blocks. You may have seen something like the right-hand side over in a Rails application where you can capture what's inside that block and output it later. So, if we execute this code on the left-hand side to run this template, what is the output gonna be? I don't want you to answer it, just think about it. Well, think about what your answer might be. Which one of these will it be? Well, it's actually gonna be a syntax error. I'm gonna show you why. So, this is what the compiled output looks like. We can see here we have that capture do, and then it tries to do a 2s on that, and then later on we have this in that doesn't actually go along with the do. And the reason is because if we look at these ERB, these ERB tags, ERB isn't smart enough to know that that's actually a block. It just does a straight translation. So, it's translating it straight over into the hey, call this function, and then just print out the results. And then the end is being translated into hey, just call this function. That's the idea about Ruby code and stuff. So, that's why we'll get a syntax error here. But how does this actually work in Rails? How does this actually work in Rails? What Rails has to do is Rails has to detect that inside of that ERB tag that you're actually calling a block. And I'm gonna show you how it does this. I don't want you to read this. You don't need to understand it. I'm just showing you that what it does is basically parse the Ruby code in there, create it, but then call it a block. So, it's possible to trick it and possible for it to get it wrong. Don't read this, don't understand it. It just doesn't. That's what it does. So, we've gone down... We've gone down a rabbit hole a little bit. I want to step back a little bit. We're getting a little too into the weeds there. I want to step back and talk about different ERB flavors. There's a few different flavors of ERB. There's the ERB that's the original one that ships with Ruby. That's the one that we've been talking about. There's another one called Erubis, or Ian Ruby's, I'm not sure how to pronounce it. That's the version that Rails uses for a long time. At first Rails used the ERB version, then we switched it to Erubis because it was faster than ERB. And then now a new one is out called Erubi, which is faster than Ian Rubis, and Rails now uses that third one. It's faster than the previous two, but they're all compatible, so you don't notice a difference. You just write your ERB and it works the same, basically. So, let's talk a little bit about ERB performance. I don't want this to be a Rails-specific or actually temple language-specific. It's not specific to any language or template, but we're going to talk about speeding up ERB, but you can apply these techniques to the building language that you have. So here we've got an example where I'm just going to render a template like we did in the previous slides. It just executes the template and then times it. It sees how many times we can render this template per second. If we execute it, we can render this template about 27,000 times per second. So we can do better than that, and the way we do better than that is we actually cache this. We say, hey, well, every time you call ERB.new on that same template, it's going to have the same results. We don't actually need to do that thing over and over again. We can just do it once and then evaluate the template. So in this case, we compile it once and then evaluate the template each time we execute. If we compare that, we'll see in this case the original case is still rendering about 27,000 times per second. Here we're able to get a 2x performance boost and render it about 63,000 times per second. So we skip that compilation step. We can get a good performance boost out of this. Now, we can go even further. Every time we actually evaluate that template, we're calling the eval function, and calling eval isn't actually a very cheap operation to do. So what we can do is we can actually cache that eval statement. The way that we're going to do that is we'll zoom in on this later. Don't worry. I'm going to read it too closely. So what we do is we take that Ruby code and we define that Ruby code from the ERB template and define a method that contains that Ruby code and then execute it. And if we do that, we're essentially caching the eval. We define a method rather than eval each time. And if we compare all those together, we're still doing about 27k for the original per second and 65k for the cached compilation but for the method call version, we're doing about 1.4 million times per second which is 52 times faster than our original one. So this is the technique that Rails actually uses for rendering your ERB templates. It generates methods from those ERB templates and we're going to take a closer look at that because I think it's kind of important. Basically, this is what it basically does. We have a template at the top. We compile it and then we turn it into a method and we only do that once. Then every time we render your template, we just call a method each time. So here we have the template source. The template source gets compiled here. The compiled source is turned into a method here and then we just call that method. This is what the, as we were to print out the method source, it would look like this. It just looks like a normal method and inside that method body is the stuff we saw from the ERB compilation. So later on, we can just call that method each time rather than define the method. So simply put, templates are translated into methods in Rails. Now since we know these templates are translated into methods, we can do a couple things with that, interesting things with that information. One, if we execute this, let's say we put this template in Rails on the left-hand side here, just put that in Rails and you print out all the methods that are defined. You'll see in the console output a bunch of these strange-looking ones that are like app view users, blah, blah, blah, blah, blah, but you can actually see these generated methods. So you can see that they're generated. The other thing that we can do is we can measure their size. So we can say like, okay, how much memory does this particular template take? Now when it's executing this, when it's sitting there doing nothing, how much does it take? And we can do that by just saying, hey, give me the method and we can ask the Ruby VM for the instruction sequences for that method and then measure the size of those. And in this particular case, it's about 1200 bytes. And if we increase the size of the number of bytes, we get larger, but we can actually measure the amount of memory that our templates are taking. So let's talk a little bit more about template handling in Rails. Everything we've talked to, everything we've spoken about up until this point are just techniques that we can do in Ruby. They're not Rails-specific. They're techniques that Rails uses, but you can use them in your own framework if you would like. So now that we know how these methods are, how these templates are compiled, it gives us some insight into how certain behaviors about the templates. So from here on, we're going to talk about behaviors of these templates inside of Rails, specific to Rails. One thing is instance variable visibility. So say you have two different templates and you access an instance variable, we know that between those two templates they can both access that same instance variable. And the reason they can do that is because we just defined two methods on the same class. They're just regular methods. We know that regular methods on the same class can access some instance variable. And since it's the same instance, we know, oh, this is the same instance, so we can access an instance variable like it's a regular class because it is a regular class. Now, that being said, instance variables in your templates, you can quote me on this, don't use instance variables in your templates. And the reason I say that is because if you look at these two templates, you have to ask yourself, who defined that instance variable? Where did it come from? Do I need to execute a different template before this template in order to get the instance variable that I need? So don't do this, use local variables. In fact, at work, so we're going to talk about local variables now, but at work in our application, we don't allow the use of instance variables in templates specifically because of the reasons I told you before. They're essentially globals in that you don't know where they're defined, you don't know where they're mutated, you don't know what order things are being executed in. So it's best to avoid them, and that's one thing that we do at work is we don't allow that, and we use linting to prevent people from using local variables in the templates. So let's, or excuse me, instance variables in the templates. So let's talk about local variables. Rendering locals looks something like this. In this case, we are rendering a template called content, and we're passing it to locals with a name, with a name, and that's board being my cat. But we have kind of a problem here. Like, let's say, let's look at that content template. So this is what the content template looks like. It says hello, name, right? Now, we have a problem here in that let's, actually, let's take this template and, given the techniques that we used earlier, we know that it's compiled to a method. Let's look at the method that it's turned into. So this is the method that it's turned into. But there's an issue here, this name here. That name is actually a method call. We don't see any local variable named name. So if we executed this, we're going to get an error. Ruby is going to try to call the method name and that doesn't exist. What we wanted was a local variable. So we need a scheme for defining local variables inside of these generated methods. So the way Rails does this is it defines a preamble that declares all of these locals. So, in our previous example, we had this content where we say hello, name and Rails will say, alright, we're going to define a preamble, excuse me, we're going to define a local's preamble here. We have a preamble that basically says we're going to declare a local variable named name and it gets it out of this hash here. So the hash is passed in from the outside template. But what this means, this particular technique causes a couple problems for us and one of the problems is that the templates require context. If we look at this template in isolation without knowing who's calling it, we can't tell, you and I can't tell, or is that a method call? We don't know. And neither does Ruby. And the only way that we can know this is by knowing about the calling context. Is this a method call or a variable? It's hard to tell. So, if we have, if we look at the calling templates, transition, there we go. So we're seeing in this particular case we can actually mix and match this. In the first case here we have a local variable named Warby. But in this case it's actually a method call. We don't have a local. It's going to call a method. So the issue with this is we can't compile templates in advance. Because we don't know the context within which they are being compiled. So we don't know is this a local variable that needs a preamble or is this just a regular method call that doesn't need anything. So we have to actually wait until somebody says hey, render this template before we can go compile it. So this is bad for servers like Unicorn because it means that we can't compile all the templates in advance. Each child process has their own version of the template and it will use up more memory. So it's not very good. The other problem with it is it's not very good for memory usage. The other problem is that we can end up compiling the template too many times. So, for example, let's say we have this situation where we say render content and in these two cases we're passing a friend local. Maybe the template doesn't use it. Maybe it's never using that local variable. But if we look at the compile content, the compile methods, we'll see here we have two different locals, two different preambles. We have one for the name in this case and in the second case we have one for name and friend. But we have to generate two different methods because we have two different locals or two different local preambles. So this is not good for memory usage because now we have obviously we have two different cases where we could only just have one. So you may be asking yourself Aaron, this is nice. This is fun. Interesting information. I'm engaged and enjoying your talk. But what am I going to do in my application today? So we talked about this problem of lack of precompilation in multiple comp... Compiling templates multiple times wastefully. Now there's nothing you can do you as developers can do about the precompilation but that's something that the Rails team, we, me and the other folks on the Rails team are working on a solution for. But as far as the compiling templates multiple times wastefully, there is something that you can do and that is to make sure that when you render a template the labels have the same signature essentially. Make sure they all have the same hash. That way they only get compiled once. So always pass the same locals to individual templates. So let's take a look at the render function next. It's a very high very high level. The render function basically finds a template, compiles a template, calculates a method name and calls the method and we saw this entire process. If we look at it from a logic graph here, whatever these are called we find a template from the cache and we ask hey, have you been compiled? If not then we'll compile you. If you have been compiled then we'll just call the method. That's it. So finding a template, this is the other piece of the puzzle we've learned about how templates are compiled and run. The last bit is just how do we actually find these templates. And finding them, to demonstrate finding issues of finding them, I built a little test application and templates that are rendered depend on the requested format. Oops. Templates rendered depend on the requested format. Rails tries to figure out what template is rendered based on the content type of the descent. So for example we have a controller here, the user's controller and it renders the index template. So by convention we look under the user's view because this is the user's controller and the action is index so actually we're saying please render the index so we'll look for the index template. But in this case in our application we have two, we have the index HTML and index.erb and index.xml.erb. So here's the content of those two templates. One says xml template the other one says users. I probably shouldn't have made that HTML. Sorry. Please remember that is HTML. So if we change the accept header as we say we want HTML or we want xml we'll get different views rendered depending on that accept header. So here's essentially a table of what we say. Say we'll do a curl for xml. The response is xml. We render the xml template. If we curl without any headers we'll get HTML. If we curl with HTML we'll get HTML. So this is what essentially what our matrix looks like. So in order to know whether or not a template has been cached we have to maintain these cache keys. Part of the cache key is the format. Actually I have a list of all of them. The cache key is the local variables because that impacts the generated code. We have a format, the locale because you can have like a .jp or .en or es on the template name. And also the format and variant like if you have an iPhone I can also impact the file name so we have to know all those things. But unfortunately we can't know those things in advance. We have to wait until it's actually being rendered to look those things up and then say oh yes this is compiled enough. So this is another hurdle for us compiling templates in advance. And we also have some strange render migater that I want to demonstrate here. Let's say we have the same controller. But now we have some partials in here. We don't have an xml index anymore. Just an xml HTML. But we have two sub templates here like a ping.erb and xml.erb. And if we look at the index HTML that sort of looks like it just says render my template and inside the ping one it says I guess this is the ping and inside the xml one it says xml is cool. So when we render this template which one of these do you think will get rendered? When we make a request which one of these my templates is going to get rendered? Don't answer. Just think just think we're going to get rendered. So if we say give me xml we're going to get an error saying hey there's no index xml. If we just do a normal curl it's going to render the ping. So it renders index HTML.erb and it says it renders the ping.erb. If we request HTML we actually get an error saying hey there's no HTML templates. I tried rendering HTML. If we use a browser we also get an error trying to render. This is what the browser looks like. I tried to render my template but there's no HTML version of the my temple. So the bad thing about this is if you look at this template we cannot predict what this render will do. Is this going to render a ping? Is this going to raise an error? We don't know. So this is very strange behavior in my opinion. The other thing is here we go. Let's say we have this control this is our bare renderer controller in index. Now let's say we do format.html. Maybe I'm sure you've seen this before. If you do any Rails development you're like I have different formats I'll just do an HTML one. If we do this, if we do this new version and we run that entire test matrix again then actually the responses are more consistent. We get an error for the XML one and then every other request gets an HTML error because we're trying to render HTML. Now if you think about this behavior I think it's kind of crazy. This behavior of this call to render here this call to render depends on what context this render is in and if you're looking at this template how do you know? How do you know what context you're being called? It means we cannot look at this template and understand what it will do next. So in other words templates are not context free. And I've been going on and on about prediction and consistency with template behavior and now I want to talk about why. So in this case we have, this is our graph of the logic that's going on after doing performance testing on our systems at work we found that unfortunately compiling it, asking whether or not a template is compiled, that's cheap. Calling the method is cheap but actually finding the template inside the cache is very expensive because we have to have all these keys. So it would be nice if we could get rid of that if we could get rid of that step there. So in order to get rid of that step what would be neat is if instead of looking up in that template cache if we could just render or if we could just put those method calls in there directly. So for example in this case we know based on all the previous knowledge in this presentation that this render call is eventually going to boil down to just a method call. It's going to boil down to a unique method call and if we knew what that unique method call was in advance we could just put it right there. If we knew what that method call was we could translate it into something like this where we just call some randomly generated method but we know what it is and we don't have to look in the cache anymore. If we knew that we could say, oh you know what I don't even need this step anymore because we already know. And in fact we wouldn't need any of these steps because we already know that is a very slow transition. Oh my god. This is the first time I've given this talk and you can't tell. Oh my god. Let's wait for this transition to crumble. I'm a training professional right here. So anyway, it means that we wouldn't need any of those steps anymore. Unfortunately it would slow down production time because we would compile things in advance but that could be a limited by bootstrap. We could cache that. It would lower our memory because we could compile everything in the parent process and we would actually have a faster run time because we no longer need to check this cache anymore. So I want to take kind of a detail where I know we started late but I'm going to do it anyway. Ha ha ha sorry Jeff. Alright so I was researching Oh it's started on a deep tour. Yes I'm taking a deep tour for the deep tour. So I want to what this prediction technique that I'm talking about we actually use it at work. So it's one of the things we use on our application at work and it's one of the things that I'm working to upstream. So part of the responsibilities my team does is take stuff that we have in GitHub that's not really core to our our business in upstream and make it open source. And we want to upstream this and we want to make it open source so I've been researching how to do that which is why I'm talking a lot about ActionView today. But in doing this research I ran into a very strange issue so I actually filed a ticket for it which you can look up later and you'll see why. So we have three templates here. We have these two templates on the left they both render the template on the right. They're both collection rendering. Now we have a list of customers that is a list of active record objects that are customer objects and there are a thousand of them. Okay. Now if you look at these two you may think to yourself okay which one of these is going to be faster? We have the one on the very left that doesn't know catching and then we have the one in the middle that says cached troops so we're going to do some caching. Now which one of these two templates is going to be faster? Obviously the one on the left is going to be faster because if it was the one in the middle I wouldn't be talking about this. So this one is the slow version. The cached one is the slow one. And you can go look at the benchmark here I'm not going to put it in the slides it's kind of long just the issue. You can go check it out but I will show the benchmark here. Actually the one with cached is 5.6 times slower than the one without cached. When I was running this benchmark I was convinced I was convinced the cached didn't work. I was convinced I was convinced it did not work. How can it work? It's 5 times slower. What is this? So I started debugging it and I found that there were entries in the cached. It was querying the cached and I was hitting the cached. So I said okay well I guess I have to profile this now so I profiled the cached and it turns out like you don't need to read these I'm just showing you that I actually did some work. So I profiled it and I found that what this actually is the very top, that top frame there what it's doing is it's actually calculating a cached key. It's calculating the key for the cached. It turns out that cached key calculation was more expensive than just rendering the template. So then I had to figure out okay where is the payoff? I know we're getting cached hits but there has to be some sort of payoff. So I figured that out the old template is on the left the new template is on the right and I had to do this much work in order for the caching to pay off. So this is our template that runs a thousand times or whatever if we benchmark this then the two are about the same we have a non-cached version. So they're same-ish there which means that you need to increase like if you're going to cache a template you need to have a very complex template that does a bunch of stuff. So in other words, what you can learn from this cached does not mean fast and with that I want to talk about making render fast so I think we have a couple of choices for making render fast we can always make this render call I think we can either always make the render call fast or we can make it usually fast and I'm going to talk about making it usually fast because I think that this making it usually fast is one of the smallest impact on existing applications today. So the technique I want to use for making it usually fast is something I'm calling the same format assumption and what that essentially is is if we're inside an HTML template so this is index.html.erb and we specify a format so we know that one in invents so we can calculate that method in invents but what I want to say is if we're inside an HTML template we're going to assume that if an HTML template exists that matches that name that's the one that we're going to render that's going to be our hit I think this is actually a safe assumption to make actually I'm pretty sure that 99% of HTML templates that render other templates have corresponding HTML templates as well and if you don't have one you probably specify the format now in the case of the ambiguous render ambiguous render problem in this case we have a render my template it's inside of an HTML template and if we look at the file system we see oh we have like pings sometimes we get a ping sometimes we get an exception as we saw from our test earlier so in this case we don't know what the behavior of this one is in this case so we know that this one may actually render or may be a ping this one of course will always raise an exception because there's no my template of an HTML format so the question is do we treat these two the same can we do that and I think the answer is no we can't do that because of backwards compatibility if we did that then your entire application would explode and people would be mad at me so I don't want to do that if we did that if we could do that then we would have what I would call an always optimized situation we know what the renderer is going to do and we can always optimize but I don't want to break people's applications so I don't think I would do that it would allow us to optimize it would allow us to optimize every case but it would also break existing apps and I don't think that's good so my theory for this the only format assumption is that in 99% of cases 99% of templates we do not have an ambiguous renderer issue it's just not a thing it's not ambiguous most of the time we'll have HTML templates most of the time we'll be able to predict them and this is also the same we found this to be true in our application award so I think the same format if we use the same format assumption we can take this index HTML or B and then translate it into direct method calls like this so in this case where we have an ambiguous renderer issue when we know to optimize it we say well you know what I don't actually know what this is going to translate to so the optimized template will just look like this we'll stick with the regular render it'll go through the slow process or the slow rendering process and then just maintain the existing behavior so to wrap this up I presented here some things we do in GitHub but we haven't put them up-screen yet because of corner cases I'm working to eliminate these corner cases which is part of this presentation here today and I want to end with a few lessons that we can learn just in general from this talk first off is when you're writing code, be context free don't depend on side effects it's important that you're able to look at your code and reason about it in isolation you don't need to think about the rest of the system the systems that you're working on are going to be so complex that you can't keep the entire thing in your mind and the only thing, the best thing that you can do is focus on this one particular case and if you have to take into account context you'll have too much mental overhead to understand what's going on the other thing is to be consistent calling a function should always have the same behavior that is essentially the same thing I was saying on the last slide but those render calls that behave differently depending on some other render call over here I don't think that's a good behavior we don't want that, we want to be able to look at our code and say hey I called this function I know it's going to do this and it'll always do that another thing, lesson learned hash does not mean fast it does not hopefully it's faster but that's not necessarily true and the only way we know is to benchmark first so always be benchmarking your applications looking for the actual bottlenecks if I had benchmarked my toy application I would know this is actually not a bottleneck I don't really care to cache it I mean you're not actually going to cache that template introduction but you need to be benchmarking in order to understand where it would be finally this is, I know this is a real specific make your locals match do it, it'll lower your memory overhead have your Friday everybody thank you so much for having me here first question was about what you're saying with instance variables in templates linting to ensure that they're not used in the examples you were looking at partial templates is that true also of the top level templates top level templates that's a very big question because it's tough to pass you design all these instance variables in your controller and then typically the top level the top level template will access those instance variables at work we don't allow that now you do understand the pain yeah how else what is your preferred way to get that data into the top level template so the way we do it at work is we pass in essentially one local and that local is a view a view object we construct a we just construct an object we construct an object that contains all the instance variables or all the context that we have to know about that template and we call that this on there which is nice for us from a testing perspective as well because we can just test the behavior of that object along so this is like an area of my interest I would say in a view template and so forth in my eyes there's always a challenge with view templates that you're essentially changing the paradigm of your programming where we go from very object oriented work on the back end and as soon as you get to the template it's what I would call a functional functional approach our templates today continue to look almost like PHP templates and that we're kind of merging them is that fair is that fair characterization first and then second with now 14 years of Rails or so, 13 years is that the right way to do it actually it's a very good question I think you're absolutely right in your description of the templates and we are it's kind of weird because if you look at if you look at how we actually compile those templates like we went through the presentation today you'll see that they're all just methods on an object so we're technically doing oh it's just you can't see you can't see in my opinion I don't think we're doing it right we know so another motivation for this presentation is that somebody here in Denver who actually gave a presentation at the Boulder RV I think he gave a presentation about a different way of doing views more sort of react style I guess I don't know any react so he's just taking his words for it react style views and he wanted to implement that in Rails too and I've been working with him on doing that essentially the change would be like you'd say render and then you'd give a class name and then some data that you want to pass to that class and it would automatically instantiate that class if you go look at the class it will have a PRB template inside of it that'll get render and you can actually test those in the isolation and do whatever you want to with them whether or not that would get accepted in Rails I don't know I mean I the technique that we're working on together I think it's way better I think it's much better it enforces the isolation the data isolation you literally can't see the other instance variables so it's not limited so I think that's a better style but I don't know if it'll ever be in core it's interesting the problem that's being approached here is like create very complex long strings so do you want to write a complex long thing and then turn it into some complex code and output a complex string or write a complex code like you could do all kinds of insane string interpolations and say like oh we have object-oriented view render right now but drive yourself insane with string interpolation so yeah it's kind of I think sometimes people can look at problems like this and be like this sucks we should do different but coming back to one of the points that kept coming up here seriously you can trade off but this is going to be a ugly problem no matter what you do it's absolutely another problem no matter how you tackle it it's not going to be fun last question for me is historically the view layer in Rails specifically my impression has always been that it is going to be this beginning that no one wants to touch which is also historically the places where you end up individually right the code that everyone else is like yeah it's hopeless just is this now going to be your passion area like you will feel the scene is this going to be the next five years of your life with a smiling action view so yeah your characterization is like 100% on yes it is it is terrible spaghetti code that nobody wants to touch and I like looking at the get history on it I'm like this is old but it's been almost no cheap drink like a few template today you could take back to Rails 1.0 yeah there's been hardly any changes and I think that's actually for the worse I think that in my opinion the code is so complicated that nobody understands it and wants to touch it so yeah I think that will be that is my next area my next area focus right now but I don't think it's going to be as long and arduous journey is working on active record I think once we get this like once we get it to the point where we can take the the stuff that the optimizations that we're doing in GitHub and upstream those into into Rails I think will actually be a really good position hey Aaron I'm DJ thanks for your talk I don't know how to ask this without sounding kind of like a poos kind of like a dirt but it's extra my life as a DJ right now do it so it's 2019 why are we still talking about Rails views I feel like everybody writes job script for the front end now I mean we don't that's true I think a lot of people a lot of people are just writing JS on the front end but there's still a lot of people using Rails views and we use them a lot of work so that's why I'm looking at it do you have any advice for someone who wants to be involved in the Ruby or Rails projects as a new commuter to open source where do they get started Aaron if you know my chance don't so it depends it depends on what you want to do a lot of people say I recommend starting at the edges don't go directly for Rails a lot of people get started a lot of people excuse me you should get started with documentation but I personally hate doing documentation as if you tell for my amazing documentation I prefer doing programming and if you prefer doing programming too it's very difficult to get actually started on Rails and I'll tell you why the reason is because as soon as we get an issue file if the issue is easy somebody hops on and fixes it already because it's such a popular project you'll have a better chance as if you go for dependency and things that Rails depends on so go look at all the things that Rails depends on go look at those gems those things the issues on those there will be more likely to have easy things that you can get started with so I would recommend starting there and once you start there you'll get more familiarity with the you'll start working your way up to getting more familiarity with Rails for itself in that case you'll be able to solve more complex problems in Rails and then be able to contribute in that case too so start on the edges and work your way in it's my advice there's this great project called No Coquetry what's the quote about XML and violence is that your quote? no okay it's one of my favorite quotes that's an old like bash not a word thing hey Erin I'm curious what ramifications for Hamel or Slim or something like that it would have because the lookup obviously has nothing to do with which of those libraries you're using but it seems like there'd be changes in those libraries upstream too no I think those libraries wouldn't have to make any changes at all we could continue so all the changes required in order to do this what I'm talking about are basically static analysis on the ERV that's all going to be inside of the ERV ERV compiler itself so it shouldn't impact any other templating systems it'll probably just mean that ERV is way faster than the other and ERV inside of Rails will be way faster than other engines inside of Rails but that said those other templating engines could apply absolutely by the same technique so I think there's like a reasonable case coming back to DJ's question so template rendering is probably no matter where you do it and like someone has to construct templates it might be the case that you're even if you're not using ERV as like your primary tool you might be using it in a service like fetching those template fragments over the API or whatever there's like a lot of the essential problem that ERV is attacking remains no matter where we're doing our computation somebody's got to do it somebody's got to concatenate the string string cell strings back thank you Erin thank you so much


Well, it's a pleasure to come and join you all this morning when I was in the state legislature in Oregon I was immersed in energy issues. So Oregon has a conservation ethic and a renewable ethic going back to bills were passed 30 years ago bills such as Making the beaches public beaches throughout our state such as having the first recycling bill in the nation And third a major land use bill where all of Oregon is zoned with essentially growth boundaries around every city to Be able to create more sustainable Livable metropolitan areas while protecting farmland and forest land those are some of the ancestors of the energy and the environment conversation we continue to have in Oregon and certainly Part of the reason and driver in Oregon now is that we also see it as economic opportunity an opportunity to create products That we can sell outside of the state and hopefully outside of the United States Opportunity to create our own power and thereby keep our energy dollars inside the boundaries of our economy Rather than seeing them exported. So that's a little bit of the background with which I brought to to DC and It is a pleasure to be able to come and be part of a national and really an international conversation about energy and the environment and for so long and I think the the skit that you were referring to captures it it well for so long we in America have Recognized the downside of our addiction to oil through many many presidencies We have recognized and that the fact that shipping dollars overseas is not this not strengthen our economy When I was a campaign for the Senate because of the spike in oil prices That was about two billion dollars a day now It's about a billion dollars a day a billion dollars a day shipped overseas Which is very good for the economies abroad selling the oil But very bad for the United States in terms of those dollars leaving our economy not continuing to circulate through our retail stores And through our families and creating jobs here Meanwhile in terms of national security it becomes an imperative When your energy economy is dependent upon resources ranging around the world to protect access to those resources And that's a very high national security cost Various experts have estimated it and translated it into dollars per gallon I think the highest estimate I've ever seen is equivalent of five dollars per gallon for a gallon of gas in terms of Security apparatus necessary to sustain the flow of oil And indeed there's another national security angle in which the Petro dollars find their their way into the hands of terrorist organizations as Some national security experts have noted that the wars we're fighting now. We are funding both sides Which is something to make a stop and think about the national security implications of our energy policy so Since there's been so much conversation about The challenges of our oil addiction Why not have a plan to address it? Part of the challenge we have in a democracy is we change presidents and teams every four years How do you sustain a plan that will take a couple decades to implement in that regard the the plan that I've laid out with my colleagues Tom Udall and Tom Carper and Michael Bennett is to create a national Energy Security Council that would be in the office of president and that would have the role of continuing to bring to bear ideas and proposed legislation proposed Regulations proposed policy initiatives that would keep us on the course to ending our dependence on Now the estimates when we look two decades down the road the estimates of how much oil would be imported from overseas So this is not including Canada potentially Mexico Mexico is probably not to be an exporter two decades from now That's about in the range of six million barrels per day six to seven million barrels per day Therefore we need a plan to be able to Reduce our consumption by at least that much and hopefully a significant amount amount more And the plan that we put together calls for reductions Equivalent to 8.3 million barrels per day, and that's just the number that Float out of the the best estimates the various policies that we can bring to bear And one of those policies is to change the consumption in motor vehicles We all recognize that that is a the biggest consumer of petroleum We are right now Tremendous market opportunity that opportunity first. We have hybrids. We've come well familiar with We have plug-in hybrids that are about to become part of the market We have the the strategy the technological strategy Characterized by the Chevrolet Volt, which is to have electric car with a back up Motorized engine that can recharge the batteries of the electric car if you find yourself out of range if you will so you're not you're not stranded We have the Nissan Volt Excuse me leaf, which will be arriving in short order and some of you has anybody been following the Tour de France You see the Nissan leaf ads with Lance Armstrong saying you know for his entire lifetime. He's been cycling behind Cars or trucks and everything they always had in common was an exhaust exhaust pipe sitting right in front of it And finally he has the opportunity to cycle behind the cars that that don't and so they're they're putting significant marketing emphasis or weight into the Nissan leaf The process of pursuing plug-in cars Gives us an opportunity to save the cool with a 3.2 billion barrels per day That's the single biggest factor to pursue that senator Lamar Alexander Republican from Tennessee Senator Byron Dorgan Democrat from North Dakota and myself put together an electric vehicle bill that will create electric vehicle deployment communities to try to Solve the problem of the chicken and the egg in which you need Plug-in infrastructure along with the deployment of plug-in cars until it kind of has the significant Market share to take off and we hope that what we will learn from those deployment communities And that the emphasis in the bill is that those communities would all be very have different sets of characteristics Would enable us to have the best possible strategies for the nation in terms of encouraging this this transition A second piece is the efficient movement of freight We have out in Oregon a non-profit in the Cascade Sierra and it is Harder to the trucking industry and it brings together all the latest technological opportunities to make trucks more efficient from automatic tire inflation To small portable generators that enable trucks to power up their electronics without running their diesel engine and to plug-in stations where Truckers stop to airfoil technology and all that when you save a Mile or two or three per gallon adds up to a tremendous amount of savings We can also proceed to encourage a shift of a significant share 10% of the freight That would otherwise be carried on trucks onto barges and rail Some of you may have heard the statistic, but I think it's a stunning statistic, and it is how far Can a single gallon a Fuel propel a ton of freight on rail Anybody know the answer to that Right down here our expert panel them anybody anybody anyone else want to 436 I hear down there and You're referring to 436 meters 436 miles miles Well over 400, and I don't know if that's the latest number. I've seen various numbers 436 472 But over 400 miles with a single gallon in the so so moving freight by rail and by barb is enormously Efficient but having strategies that encourage in that in addition to making freight on the roads more efficient and save 2 million barrels of oil per day The third strategy is to have smarter metropolitan transportation options And if any of you folks been out to Portland, Oregon Fair number, okay. Well, I tell you we have they've been experimenting in Portland, and we have a light rail system We have now created a Streetcar system that is growing and there are communities around the country that are looking at the possibility of adding streetcars The advantages they operate like a bus line But they are most both more energy efficient and because they are permanent infrastructure They really encourage development along with the lines and so they're very interesting economic development Opportunity in Eugene, Oregon. We have rapid transit buses. Many communities are experience experimenting with moving to more electrification of buses or Natural gas which produce less carbon dioxide amount of energy expended providing simply the opportunity for bicycle paths and Other mechanisms in the metropolitan area all of these things can combine a new term has been coined in Oregon to try to capture that whole set of Opportunities and the term is the intertwined and so I don't know that it's spread beyond Oregon yet But if you hear something about the intertwined That's the complex of alternatives for transportation that get people off the off the roads This is the third Largest potential strategy of course of 1.75 million barrels per day savings Alternative fuels isn't all about If you will the process of being more efficient It also includes Substitution and natural gas and advanced biofuels create a substitution opportunity that keeps dollars here in America And we've had a tremendous growth through new drilling technologies in the availability of natural gas so that is a significant possibility now since I was a Knee high to a grasshopper We've had natural gas compressed natural gas being used on on forklifts We have certainly some bus transportation systems that employ it But it could be used in a much wider way for medium and heavy-duty vehicles Certainly in Oregon, we're very interested in cellulosic ethanol We have one of the first commercial plants going in it converts popular trees into fuel in Boardman, Oregon Now if that's successful, it will pave the path for other opportunities that will include our forest which Millions of acres of second-growth forest that need to be thin and to provide a lot of biomass that could be converted in this in this fashion and then finally Homes and buildings and this is a small factor because not a lot of homes and buildings are heated with heating fuel But for those that are it makes sense to pay attention increase the energy efficiency of their homes because there's savings of about 200,000 murals a day now Our our panel will have a lot more details and a lot more information but this is kind of the the bones of a strategy and What's really lacking is not the technology what's lacking is the political will There are economic interests that certainly would like to see us continue our dependence on overseas oil But if we think about our responsibility as a governing community our responsibility is to Think about how to position the United States strategically and how to take on not only the financial issues National security issues, but also our stewardship of the environment and energy planning is deeply connected to all three of those And if we think in terms of strategic positioning and we're looking down the road We're looking at China which is going to have a vast increase in its demand for oil other growing economies We can only anticipate that the cost of fuel is going to go up We hit a peak of about four dollars per gallon out in Oregon and now we're down a little below three dollars But I have no doubt that in five years or ten years. It could be six or seven or eight Better for us to shift from that overseas oil To energy created manufactured right here in America and when we shift to electricity We shift and have the opportunity to shift to indeed forms of renewable energy wind wave Geothermal solar and so forth. So That's the outlines. Thank you for the opportunity to come and give an introduction to it And thank you to all the panelists for coming with their expertise to help drive the energy conversation forward


what's going on everyone Sam here with late in sports cards and I'm ripping 15 father's day packs for George why I'm just gonna recount these out again and make sure we have 15 here 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 perfect so good luck here George see what we got in here for you man make sorely looked awesome dude I love trace McSorley I know everybody knows that but Alan Iverson and Desmond Ritter rookie is a Cincinnati a bear cat yeah I mean they're still gonna be a good team George or Bob but it's just a matter of you know like it's almost one of those things you'd rather have him and not have them more than anything you know Don Mattingly and Freddie Freeman on the base yeah I pulled one-of-one Malik Willis out of this yesterday which is kind of wild I couldn't believe that yeah yeah you always get some nice numbered stuff in here too John Marant and Matt Corral Ole Miss we are Willis did look really good against a pretty good defense to my Ravens Marchase and Leonel Messi nice one there Arjan Tina I didn't want I didn't get to watch too much of the Falcons but I have to imagine rare looks decent I know London got her which kind of sucks but the mellow ball and Garrett Wilson Ohio State got your first Seahawk Russell Wilson nice there we go is it the is it this the Silverpacks Bradley Charles Barkley and Omar Yurt 7 rookie not numbered heat so I'm assuming that's what the red if that's the Silverpacks got Ricardo Pepe father's day gotcha gotcha gotcha and we've got Patrick Mahomes 101 out of 199 nice as a Texas Tech Red Raider crats on that one George Badger color match gotcha yeah I think what they said is they avoided the worst case scenario yogi which is good I'm glad that you know you get sucks when your guy goes down in a free season it's the worst man got Justin Herbert and Drake London USC hopefully he comes back healthy too got Kevin Garnett base and John Morant on the insert got Aaron Donald base and Julio Rodriguez rookie nice Mariners there you go nice J rod there George Tom Brady nice Michigan and Jaden Jaden Hardy to 99 on the red very nice oh that's good Morgan I didn't see the extent of it I just know he left so Bruce me that's pretty much fine so that's good at least he's not injured got Henry Davis and Evan Mobley rookie USC nice Mobley three to go here good luck George got LeBron and Jason Tatum nice one there got Julio Rodriguez rookie nice one there again couple of J rods now and a can he pick it for pit before he was a stealer nice one there what product are you guys looking most forward to this year for football I'm really excited for gold standard personally Nolan Ryan and Palo Ben caro to end it for Duke that will do it for your packs there George congrats on all the hits we'll get them right out to you thanks again buddy


If I was a year 7 going into high school for the first time, what would I do? I would be the nicest person I could possibly be. I would be my authentic self as much as possible. I wouldn't try to fit into the most popular groups or impress everybody. I honestly would just do my thing. When I was at school for real, I tried to impress all the kids and that didn't really work for me. It took me a couple of years to realise that I just needed to express what I was genuinely interested in. And it wasn't actually footy. I didn't really like hanging out with the footy crowd. I actually enjoyed video games, playing board games, doing all the nerdy stuff. And the kids that I thought were a bit weird when I first got to school, I actually became more friends with later on because we had a lot of common interests. And because of that, I have now best mates for life. Be yourself and you'll be able to find the right people to hang out with all throughout high school.


Cube presents UiPath Forward 5, brought to you by UiPath. We're back in Las Vegas live. You're watching theCUBE's coverage of Forward 5 UiPath's customer event. My name is Dave Vellante. I'm here with David Nicholson. Our third Dave Espinoza is here. He's the director of transformation at Cushman and Wakefield. And Marshall Seed is also here. He's the co-founder of Ashling Partners. Guys, thanks for coming on theCUBE. Thanks for having us. Thanks for having us. I know Cushman, Wakefield, huge real estate firm. We'll come back to that. I want to dig into some of the industry trends. But Marshall, what is Ashling Partners all about? Great question, Dave. So Ashling Partners was founded with modern automation and continuous improvement in mind. So a lot of us used to implement large ERP systems, accounting transaction systems. We viewed RPA and broader intelligent automation as kind of the wave of the future. So everything we do has continuous process improvement and automation in mind together. So we don't want to decouple, we want to bring those together in an agile way. It was interesting. Rob Enslin this morning on the stage was talking about the waves of industry tech. He used ERP, he was where he started, and et cetera, et cetera, internet. And now automation, he's sort of drawing that analogy. It's interesting that you're seeing the same pattern. Were you fist bumping in the back of the room? Absolutely. Well, I mean, there's a lot of opportunity there. A lot of money to be made on both ends. Dave, talk about your firm. What's going on in the industry specifically? You joined sort of as we're exiting the isolation economy, right? So what's happening in the industry now? I mean, real estate has been up and down and wild ride with COVID. What are the big trends in the industry that are informing your automation strategy? And actually I joined probably like right in the middle of the isolation economy. So it was a really interesting time to get to, I'm sure for most people also onboarding into groups, but coming on to Cushman. Cushman itself is an organization that formed predominantly through acquisition and through merger, right? So three large companies came together. And so a lot of the times the sort of headaches and the opportunities that we find are probably no different than other legacy organizations have when they're merging three companies together, right? So lots of disparate process, lots of paper, lots of process that isn't really very standardized. And so really it's a lot about us trying to make sure that we're continuing to double down on really that continuous process improvement, but also bringing technology, lots of different types of technologies to bear to solve different problems throughout the organization. Was the pandemic a catalyst for the automation initiative or actually you guys started before that? I think Marshall started about 2018, but was it like a rocket booster during the pandemic or was it more sort of steady state? I think it was actually a little bit of both Dave, because the reality is there was already top-down executive support at Cushman pre-pandemic. So Cushman was already moving on this in a big way and they had executive sponsorship across the C-suite. Pandemic came, never a good time for a pandemic, but it came at a decent time for Cushman because they were prepared, they had the foundation of governance, everything you need in a large enterprise to run a program, they had that in place. So they were able to kind of just put kerosene on the fire when the pandemic had with certain automation candidates. Because I often said that pre-pandemic, you know digital transformation was kind of this buzzword, a lot of firms were sort of giving it lip service. But it sounds like Cushman actually had started down the digital transformation path and then obviously everybody was accelerated. If you weren't digital business, you were out of business. But how tightly aligned, because we heard this in the key notes today, I'd like to test it, how tightly aligned is automation and digital transformation at Cushman? They're pretty synonymous really for us, right? It is really about bringing different types of technologies, whether it's like NLP, there's the other really interesting thing and we were talking about the keynote, right? There's just so much that is going into the UiPath platform that is enabling us and enabling the things that we want to do across the organization, right? So like natural language processing, document understanding, cloud-based items, like there's just so much that we can leverage. And it's really about that continuous process improvement, it's trying to make sure that we're aligning ourselves with the strategy that the organization is absolutely pushing, but making sure that we're doing it in smart ways, right? And that we're empowering our employees as we do it, right? So it's not just very top-down from a COE, it's also very bottoms-up, very citizen-led throughout the organization. So I think of this as a strategic initiative that happens over time. But how does Ashlyn and Marshall, how do you engage with Cushman? Do you engage on a project-by-project basis? Do you have sort of a long-term strategic arc that you're working to? Absolutely, yeah. How does that work? No, that's a great question. So we started project-based. So we were a part of the co-establishment of the Intelligent Automation COE. So very outcome-driven top-down approach, as Dave mentioned, but we also had a wider aperture than just RPA. It was a broader end-to-end automation experiences. That was project-based. We had so much kind of quantifiable evidence at that point that we wanted to go bigger with the program. Over time, we matured into more of an agile DevOps methodology with the Cushman team. And Dave should certainly speak about the size of the Cushman team and how that's evolved over time. Because the two of you are in a partnership in terms of proving out the ROI of what you're doing. Oh, absolutely. Right? Every day. Every day. We all have numbers we got ahead, right? And that's just the reality of it. But in order to do that agile DevOps approach, where you're releasing every two weeks into production, you need a dedicated team that has a longer-term roadmap that is coinciding with the Cushman objective. So that's what we have in place today, something we call Build as a Service at EmRoc. So kind of think of that as plan, build, and then run. We're infused. You have to be infused with your clients if you're going to run an agile DevOps program. Is automation more self-funding? Marsha, I want to draw on your experience with ERP. Is automation more self-funding than other technology initiatives? And if so, why or if not, why not? It is, and it's a double-edged sword, actually. We talk about this all the time at Ashling. We've never worked in an enterprise technology space where there's more accountability to value delivered because it's so quantifiable and measurable. So every time a transaction runs, you can measure. How are we doing? Yeah, exactly. I mean, the ERP day is nobody questioned. They thought we just have to move to S4HANA. We just have to move to Oracle Cloud. I'll let you know in a couple of years. That's it. Yeah, the stuff that we just saw earlier from Javier Castellanos, from Orange, it is very much like each transaction has a value associated to it. Each part of that transaction has a value associated to it. We're constantly monitoring the numbers and looking at our performance. There's very real value associated to maintaining business as usual for the 50-plus automations that we have in production. The business is really counting on us to maintain and to make sure that we're continuing to perform, but also that we're continuing to work with them to find additional value and additional opportunities to make sure that we are saving money and finding dollars. But it's dropping hard dollars to the bottom line that are quantifiable to your point. But what's the governor or what's the barrier to your ability to absorb, whether it's new automation? Is it just expertise and talent or bandwidth? Is it the prioritization exercise and thinking intelligently about, you know, not facing it? Yeah, it's not all of that, so. How do you, I guess you guys work together, but take us through that a little bit. I mean, we're constantly refining our approach. So we were just talking about our DevOps approach. You know, we started with, I think, maybe five or six different teams based on specific service lines. We modulated that recently to go to two teams, right? One specific to build and one specific to enhance. So we're constantly looking for and building new automations throughout the organization. And then also looking for incremental value to enhance the automations that we've got out there, right? So making them better, faster, making them more resilient, so resolving technical debt, doing a lot of different things to make sure that we're as stable as we possibly can be. But it's not only that, it's really like making sure, like we're just as pinched by everybody else in terms of like the great resignation and looking for talent. I think everybody here is basically looking for the exact same talent. And so it's really making sure that we have interesting work, we're doing interesting work, we're making people feel valued, and we're bringing value throughout the business. So I remember a Bobby Patrick called me when he joined you, I probably goes, you're not going to believe what I'm doing now. You got to get on this train. And so I started to look into it and we actually downloaded the package and started playing with it. And we tried to do it with the competitors, you know, we couldn't. It was like call for pricing kind of thing. We were like, oh, that's interesting. But what we saw was in my perspective, this bottoms up adoption. I know there was top town as well. But then I remember I was in the meeting when they announced the sort of process gold acquisition and then started, I said, okay, they're going for platform now. And then Microsoft came in to the market, like, okay, they got to differentiate there. Now you're seeing everybody, all the software companies think they should own every dollar that's ever spent on software. So SAP's doing it, the service now. And so Marshall, from your perspective, how has this platform evolved? And then Dave, to the extent you can talk about it, how is that platform adoption taking shape within the organization? I mean, platforms are much more complicated than products and they require integration. How is UI path doing there? I think they're doing fantastic in that category. If you think about it, and it's been a natural evolution. They're not fighting inertia. They're following challenges of their clients. All right, so RPA obviously came onto the scene hot. Everybody understands the business rule-driven automation value. Easy to make a quantifiable, tangible evidence with RPA. But exceptions happen in a business. And upstream processes break that cause challenges with downstream automations. So what do you do? You have to go upstream. You have to have more automations. You have to have process discovery, process mining with process gold. You need to have the ability to have a better user experience interface, which we've definitely incorporated into Cushman when we didn't get adoption with certain automations that we like. You build low-code apps. People want that consumerization of technology in the enterprise. And that allows them to adopt more of the automation, which triggers the robots and then you report analytics on it. So that expansion has been pretty natural with UI path. And I think this next acquisition they just made with re-infer is really interesting because now you're going even more upstream with communication mining, turning that into structured data that you potentially could automate or analyze. So it's been natural. It's truly the only platform that we've encountered that can do all of this at this point. So a couple of things there. One is the nuance of adoption is not just the function of the potential savings or revenue production or productivity. It's the experience. So you got to have a great UI. And then what are you going to do with re-infer? I don't know if you guys are adopting re-infer, but what do you see as the potential? Marshall and Dave, if you guys have visibility on it. I know we've talked about it, Dave. So the potential is huge. I think it's going to be more of a question of change management for each organization just to feel comfortable with that. But I mean, think about all of the communication and the semi and unstructured data in an organization that comes via slacks, teams, emails. It's huge and it's significant if you can figure out the right identifiers that you want to trigger for your business and then figure out, is that something downstream we can automate or can we just analyze and make our business more effective, more efficient or provide a better experience? So I think it's huge. We don't know how big this is yet, but we know that it's something that, I mean, think about Cushman, get brokers all day long that are communicating with clients and third parties. So it could be extremely significant. That sounds like a potential to eliminate email hell, but I've heard those promises before. Maybe that's like the paperless office eventually. Well, in our organizations, like 40,000 to 50,000 people globally, right? And there are definitely service lines within our organization where probably it doesn't make sense for us to leverage UI path and provide them studio and low code, no code automation tools, but a lot of this NLP stuff and a lot of the content mining and the communication mining stuff really has the ability for us to be able to sort of pinpoint opportunities at levels that we couldn't possibly do it before. So it was really very exciting to see the stuff that we were in there. I think when you start your organization, a lot of times you're a hammer looking for a nail, right? And you need to quickly move away from that. And so I think a lot of the stuff that UI path is introducing, a lot of the stuff that they're bringing into their platform really helps us to be moving away from that sort of orientation. Well, when you think of this in terms of CICD, people maybe have a better understanding of sort of the life cycles and the iteration calendar. Can you give us an example of something that went from an idea, something like, hey, I think we might be able to automate this process through, okay, yeah, let's do it. You try it. At some point there's sort of quality testing involved to make sure that it's achieving that we want to do. Can you give us an example of a process that you've gone through? And then how long do those things usually take? Are we talking weeks, months? What are we talking about? From idea to establishing that, yeah, this is something we want to keep in place. We always want to make it faster. So especially always trying to find ways, especially up front parts of the process. So a lot of the analysis, requirements gathering, stuff that's not actual building. We want to make sure that we're shrinking that as much as possible, that we're also being comprehensive so that we're not building something that doesn't meet someone's needs, right? Or that just completely misses the mark. But I mean, invoice processing is a good example. We do that internally. Obviously we have corporate accounting. We also do that on behalf of clients. And so a lot of times, we're bringing some of the internal processes. We're using the technologies for document understanding, optical character reading and machine learning. And we're doing that on behalf of clients, but we're also doing that internally. So to be able to use some of those processes and automations, sort of client facing, plus externally, are big changes for us. But I think the other thing too is like, we're always trying to make it faster and better. I think that's one of those also processes where we put something in place and we're constantly looking to enhance it, and make it better based on the process that's out there. And you're applying automation to that up front piece, the planning phase, is that right? Yeah, yeah. So a lot of it is about sort of the work that we do on behalf of clients. And there are teams who are specifically tasked to accounts. And so we're looking to find ways to make it easier for those accounts to get their bills paid, to get visibility into, you know, accounts payable, accounts receivable, their full end-to-end accounts life cycle. And so yeah, we're doing that directly on behalf of clients. And then we're doing that internally. How about the why UiPath question? Marshall, I think I heard you say that you're pretty much exclusively UiPath as your automation partner. Why, why not play the field? Why UiPath? So I think it started in like 2017, 2018 for Ashling. We did an analysis of kind of an outside in of what at that point was the big three of RPA. The vision and the roadmap and the open platform architecture of UiPath and just the self-awareness that, hey, we need to operate with other technologies in order for our clients to get the most value from automation, that was really the main reason. Outside of the fact that we like working with UiPath, but it was just that complete vision of a platform as opposed to a tool. We felt like everybody else was more of a pointed tool and then UiPath had this platform approach and it was going to be necessary to go end to end like we all are trying to achieve. And UiPath continues to deepen that, right? They're continuing to support us with tons of new technology. How so, can you be specific? I mean, when we're talking about document understanding, I mean, we're trying to leverage that for manual handwritten time sheets. We're also using it for, you know, Kronos integration, right? So like there's a lot of stuff that we're using it for and we can go to a single shop, right, to be able to do it, a single platform from a scalability and a supportability perspective. It's also a big game changer for us, right?  You really got to invest and be smart about it and UiPath for us was a really smart play. Is, are you budget limited relatively, you're competing with other initiatives within the organization? Where's the funding come from? Is it from the business? Is it from IT? Is it a combination? It had been centrally funded and we are now moving into a different model. So we are constantly looking at, you know, the justification of value, speed to value and proving it out to our business partners from all service lines and within all different functions of the organization. So we're at an interesting inflection point, but I think we also have a really good background that we're building on. I've been saying it all day. I've said it for years at the UiPath events. They are awesome about putting customers on theCUBE and we love to hear from the customer stories because we get to sort of map what we hear in the keynotes and then test it, right? In the real world. And I also really love the fact that Marshall, UiPath always brings implementation partners so we can get the expertise and you have a wider observation space. So guys, thanks so much for coming on theCUBE and sharing your stories and good luck in the future. Thanks for having us. Appreciate it guys. You're very welcome. All right, keep it right there. Dave Nicholson and Dave Vellante, live from Las Vegas, UiPath Forward Five. We'll be right back right after this short break.