OK, and with that, we start. So welcome to our Cooking 101 class. And now you are all here to do some nice bignets and other local New Orleans food. So what's the Drupal con? It's a wrong convention, I mean. OK, yeah. No, this is a future of Drupal performance But we'll do some cooking today. And we'll soon see why. Follow me on Twitter at Fabian France. It would be great if you treat something, if you would mention me, or use some special hashtag. We can find future Drupal or something like that. And yeah. So let's start with a little introduction. Website composing is really like cooking. We are cooking a website. And that means not the development of a website, but actually a page request. Like you're going to some URL like Google or whatever or Drupal.org. And Drupal in the background is composing all this stuff together, like different things. And that's in a way it can be compared to cooking. It's because we have different little ingredients that we're using, which are kind of our content. Then we have cooking utilities that are helping to assemble this content. And we have other things like a can opener, which is like authorization. And then we have obviously cooks doing the work and preparing the meals. So there is only one cook in Drupal. And that gives some problem because that one has to wait a lot. And let me demonstrate that to you a little. So that was visualization of latency. How latency works, how it really makes problems, and how even with caching there still is some latency. Still have to run over there to get that. And the other thing is we are sometimes getting the can opener to open the cream, even if the meal doesn't even have cream, so we don't need the can opener. But we are getting the can opener every single time. And often it's like we run into the seller to get the can opener every single time, regardless if you need it or not. And that's a lot of unnecessary work. So as I said, no one would run a kitchen like that. You would first have several cooks, so if there's even an ingredient missing, someone else would keep stirring so that the meal is continuing, and someone else would get the ingredient. And you would not put your dish to the side and run to the supermarket to get the ingredients. You would plan that a lot more better. And while someone else gets a salt for you, you would prepare the dessert already. So that meal is blocked, you cannot continue with it. But you could do some desserts, meanwhile. Like Drupal could render the food while the database is still busy, because the food might be cashed. We could send it already. And that's also where the big pub work comes in, kind of that whatever is ready we are sending. It's like a restaurant where you order a huge menu, but it doesn't get in order, and you don't really care because you're really hungry, so whatever gets ready you are eating. And as I said, you would not get the can open out of the seller every time, especially not when you don't even need it. But Drupal is kinda doing all of that every request, because we load the service container, we load so, so, so many classes, and we have to load them all again, and we have to compile them, and PHP has to initialize some, and we have 242 services or something like that, so it is a lot.  So we always start from zero. We are caching a lot, and in Drupal ate even more, but we kinda always start from zero to do all of that, so we always start from zero with our meals, there's nothing prepared already, there's no ready-made dishes in the refrigerator. But that in itself is not bad, it's just how the CGI model works, where you have a web server which is accepting your request, and which is passing them on to a CGI, like a PHP, FPM, or ModPHP, or whatever. This is kinda how our world works, but this is not how, for example, the Node.js work works. And it just means we do potentially very unnecessary work. And it just means we wait for IO a lot, especially with PHP 7, and there's no way to have multiple cooks right now, it's really just me running around all the room and getting the ingredients. And yeah, and now we're coming to that, how do we fix that? And that's the next step. So are you ready for some really cool ideas? I hope you are. Then let's go. So at DrupalCon Amsterdam 2014, my render cache session, I shared my vision about how this render caching could all work, and the only thing Drupal ate at that point had was cache tags. And it was a little crazy overall, in a way. But by now, 90% of all that's implemented in core, directly shipped, big pipe in core, 8.1, the placeholders in core, everything. So I'm just trying that again. So the first thing is we really should try to avoid doing unnecessary work. So one of my goals is to bring back kinda the performance of the Drupal 8 cache to the Drupal 7 level. And I've already shown it's possible. There's a special issue, a meta page cache, where I've profiled that and optimized kinda almost everything out of symphony, everything out of the page cache. And then in the end, with some little tricks, we can, it can be possible, plus keeping all the goodies of Drupal 8 to be faster than Drupal 7. And because Drupal 8 is PHP 7 ready, we can even faster than Drupal 7. And so that's one of the goals. And the other thing is we now have this dynamic page cache which is great for caching all the authenticated user page things. And we can bring that kinda to the index PHP level again, which means do it as quick as possible, do it as fast as possible, don't do much work, kinda just load the database, get the cache entry, check it and be done. And yeah, and for that, my strategy or architecture I've designed is to use the same approach as how ESI would authenticate user caching this in varnish. And that means we are caching the cache context. That sounds a little crazy, but it all makes sense if you now or remember that in Drupal 8, the cache context which is how your context, how your content varies, like this context is only cacheable by user, but this context is only cacheable by the face of the moon or by some crazy elven ritual that you're doing. This cache context, you can actually reduce to two things. All of our cache context hierarchy is planned in a way that for simple sites and for more complex sites we have to define some other things. You have a tree, so we have URL, and then we have URL.pass, or we have user and we have user.permissions. So everything in the end comes down to the user or to the URL, and the user in reality is just, there's a one to one mapping between a session and the user. So it all comes down to we have a session or we have a URL. And because of that and because cache context actually declare what they are depending on, like other cache contexts, when they would be reduced in that way, it means we can cache the cache context per session. And that's kind of also how it would work in ESI. You would do a quick restart. The user is then authorized within varnish, and then with some special headers, Drupal can now, this user has user ID too, et cetera. And now the idea is we're doing the exact same thing just within Drupal itself, and retrieve this page with the placeholders, and that's, I'm explaining a little more now. So as an example, we have this shopping card which is user cached. Then we have a normal block, which is just user permissions cached, and we have the user permissions and URL cached. So we don't really have to deal with a normal block because that we can just cache with the rest of the thing, that's not a problem. So but the user cache obviously is a problem because if we didn't placeholder that, it would mean our whole page would be cacheable by user. And that's not what we want. So what we store in the page cache, in the dynamic page cache then is, we are storing our page together with the placeholder. But this placeholder actually has a cache address because it's cacheable. So and in this case, it's a block four, block with the ID four, and the user of two. And this is even if you look at the database and you look at the cache IDs that are stored in the database, whenever you see a bracket, that's a cache context right there, user equals two. But because we have our little mapping that from the session 42, we know it's user two, and we already did this really quick up look into some cache, like a local APC cache or something like that, because that's not really changing. And we get back that this is user two, we can actually know which cache context we need without having to bootstrap all of Drupal or authorize a user by caching the cache context. And that means when we are now retrieving this page with the placeholders out of our cache, there's still some chairs here at the beginning if you could come up in the front if you want, not run. So if you are still retrieving this page with the placeholders and we have this placeholder and this placeholder is cached, then there's no reason why we need to bootstrap Drupal up even further because we can directly compose the page. And that's kind of the trick here, and that's also what is so great about authenticated user caching this manage within CDNs like Fastly, that you can be directly near the user and in the future, even with service workers, you could be caching things at the client, directly at the client, and it's always the same model. We're having dependencies that things are dependent on, we're having these cache contexts which are the dependencies, and we're having placeholders for things that should be out of band kinda. And this is kind of the trick that we can do with an index PHP, we compose the page because it's all cached and we are done, we just send it. And the nice thing is with the architecture, both scales of Drupal profit, it's the same way. The smaller sites just get faster performance for free kinda, and the enterprises, sites gets easier varnish and ESI, so regardless which camp you are in, you will have profit. And all sites, because it's using the exact same mechanism, and we can write all the tests for kinda the ESI with Drupal itself, and then when there's real varnish ESI, it just works because it's the exact same mechanism, there's nothing different about that. And, or if you use NJNX, you would write yourself a module that would do that. And all sites could get faster response times for cached fragments because we have a cache that's sitting so much at the front of Drupal that it's so early in the process that you don't have problems with that. And so with service workers, as I already said, which is kinda like a reverse proxy, like a varnish on the client itself, we can use the same exact mechanism as with ESI, we can send the page with the fragments and then we can display it and then we can cache the other fragments separately. So the whole system kinda works for all stages of that. And so without any additional work or changes in that, and for you as a developer, nothing changes. So service workers would provide from that as well. And the nice thing is we can do what I have shown you almost today. There's kinda a five line patch missing to Drupal kernel, which means to allow precontainer middleware support. So with Drupal request works in the following way, you are actually doing like that, that the container is, the request is coming in, a kernel is created, and then we are going through a middleware chain. But unfortunately before we do starting the middleware chain because the middlewares are stored in the container, we have to load the container and that is even if we were loading it from APC, it's still so much of an impact that it's slower than the Drupal 7 page cache was and because the container is quite big because it has all our services, even if they are not loaded. But because we have a bootstrap container, we can kinda hard code all of that in settings PHP and we can have like, would define precontainer middlewares and then we had true middleware support or you could have index PHP today, today that and with a precontainer middlewares, you could still have like in the bootstrap container, your database, your cache tech servers, even custom request policies for the page cache, even custom middlewares, you wanna really run always and you say, I don't need this additional performance, this middlewares need to run because they're doing essential things. But then the page cache comes in and we can do all this composing and stuff. And we can add this little thing missing in any Drupal 8 major version, minor version. To truly cleanly realize this, the best would be however, to remove bootstrapping completely, just have like middlewares as a system, remove HTTP kernel from symphony, there are other ways possible, obviously, and lazy-lorded services. That means the session initialization, authorization, routing, all of that, where I had to go around the room, is all done on demand. So just when for example, the current user service is used just then the user is authenticated. So we are going even more into a service-based architecture where things are done on demand and we are really at every stage, we know we can get into a booted up stage, but depending on where we are standing currently, we have to do more work or less. So if all this cache, no work at all, but if little is cache, we need to do a little. And another thing we could do, business kind of model is we could even send a page skeleton already and then big pipe the main content as soon as we have it, like stream the main content too. And the vision of all of that and that's so important to me as there should be completely transparent to the developer and SEMA. There should be no intrusion at all, which means it's all backwards compatibility and which means it's all Drupal 8 possible. And the site should just get faster automatically and that's the goal. Obviously you would still as a developer need to declare your dependencies properly, but you need to do this today already. So it's not really something changing. But there's more. Be ready for the future. Because we have this great render tree in Drupal, trees have one great property. They're easily parallelizable. So whenever we encounter a new rendering context and the rendering context is something that's cacheable, which is independently buildable. So whenever we have something where we, in the end when we come back from the tree rendering we would do a cache set. In this case, instead of rendering that directly, we just create a promise, we push that to a queue, replace it with a so-called wait placeholder and return. And then before sending the page, obviously we need to process the queue. But in that all would also work recursively. And then we'd have kind of like an event loop which processes that queue. For example, in Drupal, standard just as a random worker, which would just randomize your order. And then fun begins. So, and obviously if you have a promise, like you have one part of the tree and then you're going down and there's something else in the tree, then this would also work recursively. And then obviously if there's two things, one promise would need to wait on the other. But there's real big possibilities there because now for example with HVM, you could just make an asian queue runner instead. And then like magic, we have asynchronous IO kind of automatically. And because while we are waiting for the IO, we can start rendering another independent fragment. And maybe that's all cached and never needs the database or it's just internal things. And this can really help the performance of reducing our IO thing. Because as I said with PHP 7, things have gone so much faster but IO is starting to become a bottleneck again because of that, yeah. And PHP 7 itself is in the process of implementing asynchronous IO as well. They've worked so hard in PHP 7 to have proper isolation levels and everything that it would work and have kind of prepared everything. So our estimation, what I've heard so far is it might come in 7.4 or later. We'll see, but estimations are, we are pretty sure it will come at some point. And well, someone could base the queue runner based on React PHP or Icicle IO or whatever thing is hot next week. And in the future, we could have something other cool guaranteed response times which is something that CEOs around the world are asking for since forever. So for example, you can say if this block takes longer than 50 milliseconds that's our guaranteed response time for this block then just abort the rendering. So I'll weigh those 50 milliseconds, return a placeholder, a real placeholder in this case and big pipe it later. So we could have a page and we can dynamically, intelligently determine this block here is just really taking way too long. Something has gone wrong. Abort, send a placeholder. We'll send it later when it's ready. And when we add this kind of, and even without truly asynchronous IO we could still already do something of that like yielding back, going back because we are dealing with trees and as I said trees can have many like this properties where we could just measure the time to render that tree and if at that point we have already again over our limit then we can say oh but now rendering the rest of the tree would take even longer so no we are aborting kind of so that could happen in a subtree for example that we are defining such guarantees. So that would not even need HHM or asynchronous IO would be more efficient obviously because well it could take hundreds milliseconds and Signal obviously needs PC and TL extension PHP but at least we could say well but now we don't wanna wait the other 200 milliseconds that the rest would need we've now gone over that would not be guaranteed but it would say once we are over and we are back in control at some point where we can set a placeholder we really wanna abort and we can do that at any time. So if we add this kind of abstraction then the implementation does not really matter at all as I've shown you can use a hard thing of the week and just more little explanations already tried that a little around the placeholders because it's a term like context where everyone is understanding something different about it and it can be defined in so many ways and that's why I used wait placeholders. Normal placeholders in Drupal are replaced as late as possible and they are cached because the reason we are placeholding is we want to remove dependencies like this tree being dependent on the current user. That's why we are doing a placeholder and kinda doing out of band rendering. Wait placeholders are different because they are replaced as early as possible and never cached because the only thing we wanna do is we wanna remove the waiting time. So wait placeholders have been replaced before cache set happens. So that's again why I'm saying it's completely transparent to the developer there's nothing in there. And there's another nice property of our render cache tree because we have hash cache and that can obviously return something cached. So whenever we have hash cache we can safely return just markup and attachments because that would happen if we had a cache hit. And this is where we can do those replacements easily. And again, we could do this today. We would just need to replace the renderer in a module thanks to the decoupled architecture of Drupal 8 and play around with that. Isn't that exciting? I find this really exciting. So the vision for Drupal 9 here would be that Drupal 9 would have at its heart an event loop like Node.js or Golang or whatever. And again, we want this to be completely transparent to the developer or SEMA. It should just get faster automatically if capabilities are available that's ago. And we could change Drupal 9 and learn as a community together to be as much as soon as possible and switch over to the paradigms that most other languages have and win back those people that left for Node.js. But there's even more. So workers everywhere. Because now that we have our nice little queues and things that are independently renderable, why not push the work to a dedicated rendering farm? For that, we need to know which scene we're in, which user we have, which session we have, which route, which URL. In short, we need to know the context how this should be rendered. But we do have this information because that's exactly how that context would be, our content would be cached and how that content varies. And that are our cache context actually. And that you are hopefully all declaring anyway if you're working with Drupal 8. And we would need a way to quickly set that context that's not available right now because as I said, we do all this bootstrapping stuff. You see it's all coming together in the different parts. But as soon as we have that defined, what we can then do is we can do pre-generation of content. So for example, we could have a heuristic that was checking for our most 100 most active users. We are pre-generating content so they have a faster experience and have never to wait for anything. And our heuristic is just iterating the most used blocks, for example, or the most used content nightly. And then we can pre-generate it because we have the full context how we can pre-generate that content. Because we have that available and we can record that because we have a queue and we have independently built things. And that's why when you are building modules, use lazy builders. They are great. And we can do regeneration and serving of stale content. So for example, remember our block we guaranteed the time for. We could either send a block that's kind of saying timed out or we could send some stale content and once the new content is available, just send it. So there's a huge potential in Drupal because we are never deleting caches at the moment except for the database where we are adding some sort of last reason, least reason to use things. But in general, all things that are expiring where you get a cache miss, you can say, I want invalid content and you can get the old content. And that's great. So there's huge possibilities there as well to say, especially in combination with big pipe where you're saying, okay, I still have an old version of that. I send that. I don't care that the user sees a little blip in change like their list of friends, it's there. And then the order changes a little and some other friends appear like 100 milliseconds later but the user directly has a fast experience that's so much more important. And, or you could send the outdated content together with a special class which would gray it out so it's clear it would look like this. And that's a little then like Instagram like those previews of the images where they are just sending the most major color already. And obviously we could have workers in the rendering farm but to make those workers efficient however, we need long running processes. And that's in itself as a paradigm shift I'm proposing here because many things assume and droop that request is short and everything is reloaded. And that's not the case for other systems. Not the case for almost any other system. So, but already now we have long running drush Q runners. So it's not a completely new problem. But you can do baby steps. And thanks to Krell's vision. Thank you Krell, he's here. Some most services we have are stateless and static is almost gone from the code base. And that's so great because he worked so hard from Drupal 7 to 8 to make that a reality to change the community in ways to not only make it object oriented programming that you might love or hate but what all of this gives us is it gives us possibilities to be ready for the future in that. And he made that happen since 2010. So that's amazing. And the rest we should put into a Drupal and the rest kind of what we still have from static state which just should put into a Drupal static service in my opinion. So we could have some kind of scope state or at least resettable state in the future because a Drupal static of Drupal 7 has one big advantage. You can just call Drupal static result and your system state is again in fresh state but if lots of classes have different states that's not so easily possible. So we could for example start as baby steps just with a loop in index PHP that clears all static caches in between accepted work and actually we are needing that anyway for unit testing because we don't really want state to have there. And creates a new kernel every time that at least then all the classes are loaded and that's already is huge because the class loading overhead while not much it is something. And HHVM for example does something similar. It has like a like a warm up phase and once it's warmed up it knows the most frequently used classes and has those kind of preloaded in some special memory segment. And then we could write list all the different services which already now are 100% stateless. Thanks a call. And for example just create a container with just those services already preloaded and then we just need to clone this container and cloning is a really fast operation in PHP and you said kind of as our baseline and then just the services we don't have loaded yet we have to load but if that's still not enough we can be even more crazy and declare cacheable meter data like cache context on the services itself. So for example you have a workout one for user one for user two and you switch around and the worker has to one for user one, one for user two then we could in theory just reuse the current user service for example but stored per user in a different cache bin and again this comes back to the model that this kind of work that is coming in is coming in with in a certain context and a certain context if we define this well enough will be enough to determine all the dependencies of our system. So and even more crazy we could scope two per static with dependencies declared so not the services itself but caches of them but that are just some ideas and there's obviously some definitely race conditions of static caches because if you have long running processes that's something where if you have some cache you can run into cached race conditions but as we said with Q-Runners you can run into the same race conditions already now so but it's just something to take into mind and that's kind of what I wanna get into you now or what I wanna present to you now is a paradigm shift that we stop thinking of websites as being request response and booting up everything but we think of some as applications that are serving our users that are serving our clients and that we get all of that that so many people are doing this JavaScript that we get that in Drupal as one possible way to access the system and we are building our system to be ready for that so to summarize that again we need and that's kind of the vision here for Drupal 9 we are setting and retrieving of the request context we have long running workers and resettable caches and services and again should be completely transparent should just get automatically faster that's a goal and that could be the promising future of Drupal or future of the Drupal performance but again we could start today we can experiment with all that now we should even experiment with that now because when the world is ready for asynchronous service workers events loop and finally going away from CGI for PHP which I think will at one point in time happen because the whole other world is away from it then Drupal will be ready too and that would be pretty sweet thank you so now we have some discussion because it's a core conversation so we can both ask questions in if you didn't understand something but we can also say well this is crap you really shouldn't do this or now we should do this differently or like that we are the community so fire away microphone please so my question is with the long running processes my understanding is that one of the barriers to that is that Apache is based on the short request response cycle so how do we get around that if taking advantage of that would mean major changes to what hosting options are available for the Drupal ecosystem we could talk to that so first of all as I said I want a slow transition of everything so baby steps in that that it's one possibility but not the only one so the boot everything up approach would still work it would just be slower so to make advantage of that obviously I think what will at one point happen and what has happened both for Golang and NodeJS et cetera is that PHP will have a first class web server in itself so you just run like you run a node process you run a PHP process that's one possibility which is then having the big event loop and then retrieving directly requests creating services out of that request and doing that another possibility is that you have your normal Apache web server and you do even some of that Drupal request normally but then you are pushing off work you either know and have declared to be a little longer running or other things you're putting that off to a drush process and there's different services available which might be performant I've played around in 2009 with Gearman to do some really quick Ajax request for anonymous users and that already was working pretty well because I got like 50 milliseconds response times from that so there are definitely possibilities in using several of the other available queue systems and obviously it's always a trade of how much infrastructure do we want do we want just to run a PHP process something somewhere that then obviously what about all this plumbing that infrastructure guys hate about NodeJS that it's just one process and there's no one that checks that it's still running et cetera which I have Apache but I think that are all future questions and the important thing is kind of making Drupal ready that it can be run as an event loop but not necessarily must. Okay so I'm technical SEO by trade and I kind of find my tagline being feed the bot right I want to feed the Google crawler and I think some things that people need to understand is that Google when it comes to your site has a budget of time that it's gonna spend crawling so all of this that you're talking about caching for the user or caching it just is amazing to me and thank you so much and I hope maybe that's one of the baby steps is to help like if we serve a page that has related content it would be fetching all that even if the page is cached but I really like where you're going with this so thank you. Thank you. Hi Pevin, it's Peter Willanen. Just thinking about your steps that maybe we can go forward with Drupal 8 is there a way to use even the Drupal Q system and then couple some background processing so I'm just wondering we again need a system where we can basically use Drupal as is where no background processing is possible but then accelerated if it was and have you thought about is there a way we could use a Drupal Q so basically your request would have to process its own Q entries if there's no worker but if there is a worker in the background then basically all that work would be done by the time it's needed. So yes and no so I would not push that to a Drupal Q database back end because that would be too slow. It should be in memory Q by default and then if you push it back to a worker and the in memory Q should really work like and that's why I wouldn't use it because I don't think that Q is particularly suited to that use case because what I really want to have is these JavaScript or Guzzle or whatever abstracted promises where I'm really just having when this is ready just inform me kind of model. I don't care when it's ready but when it's ready give me the call back that you are now ready and then we can continue with that and I don't think the Drupal Q is suited to that but on the other hand for doing the workers and testing that out obviously for doing that the Drupal Q could still be used together with a Drush Q runner there would definitely be no problem. I doubt so that it would be for many things would be performant enough at the moment but yeah that's a more thinking of like a socket where we are posting the data because most lazy builders and that's why you should use lazy builders are very small having declared the dependencies and then we just need to be as efficient as possible to declare our request context and if you're doing that it should be really simple payload that we are doing but yeah we could still do that all in Drupal 8 it would just be maybe some more needed layers it could even be the same API for Q but for that we would need to see if the Q API is sufficient for that. Hi I'm Les Lim I came in late so apologies you've covered this but are there implications for debugability for long-range processes or across the entire system with several with things that are that are deferred to workers? That's a very good question. I've not yet thought about that in terms of how debuggable long-running processes would be I mean in most cases you would probably just attach your debugger normally in that so that should still work but I've not thought about it but my thing is obviously sometimes in development you would use it but usually you would not it would be more like a QA thing and it should be nothing that should interfere with your development usually because unless you want to specifically test that case. Also sort of related to that profiling tools have they caught up to the concept of having a long-running process as well? Functional? Yes and no so with XH-PROF you can run XH-PROF disable at any point in time and that in theory should reset the state of that at least from my remembering of the code base of XH-PROF when I run XH-PROF enable it should reset all variables so you're starting new and can start at any point in time in the course deck so that should be possible and obviously if you're using XH-PROF sample profiling you could just write up the code base profiling could just write out some samples but if it's not suited for long-running processes I don't think it would be very hard to change because it's really I think there's like five variables that you would need to re-initialize to get XH-PROF running for example. Thanks. Just wanna build on previous question and something you talked about earlier, Fabian. If you're writing code that is proper stateless services and pure functions and so on, the big advantage is you can debug those independently whether they're in an async environment or not you can't test them, those will work the same way whether we do long-running processes or async or native language async or whatever else. We want to have 90% of our code base written in such a way that we can figure out which one of these we actually want to use in three years, in five years and do have two or three different versions of it. So, starting today, actually starting two years ago write code that makes no assumption about its context or its runtime environment and then it'll just work with any of these and you don't have to think about it again. That's the reason you write code that way so that you are flexible for all of these. Yeah. And stateless service means avoid static like the plague in your classes. Because while your end to your service should be recreatable at any point in time, kind of. You should, it's like writing iOS apps or Android apps where you can be suspended at any point in time and recreated and the user just closes your application and you are responsible for holding all of that but if you kind of, but there you also need to store. If you store a state, store it in something consistent which is in our case, always the database. Next question. Discussion, some more cooking? Can you please talk a little bit more on what can we do now in terms of the initialization of the container service and all this stuff? As far as I remember, you reported in the issue that like now in Drupal it takes about 100 milliseconds to make all those initialization and in the presentation you said that we can try to get rid of all of those at all but like kind of, are there any steps that we can try right now? So anything I've talked about we can kind of try now. To be a little more practical, so currently dynamic page cache due to the design decision works with routes but there's no problem in writing a middleware, sorry an event subscriber that runs before HTML subscriber that would store the page based on the route into something together with all the placeholders intact so just push it into the cache and then you just have to hack your index PHP and initialize your database and then you're just doing a query to that, grabbing that and then you check can you fulfill all the placeholders and that would be a fun service to write kind of as a first step and if you can then just return the page and you're done and then try it out and see how many security issues you get. Yeah, there is obviously a risk especially for authenticated users but on the other hand you could have also a sent anonymous pages which are personalized and I think we are even going into that direction more based on session and how cool would it be if it's on session but you know only this little part of your page is dependent on the session and you could still have a page cache that's running as fast as Trooper 7's and you would still have your nicely personalized page and cache it for 10 seconds so only every 100s request you have to actually boot up Trooper so microcaching is also a hot topic that can be done or as I said with big pipe we are keeping the request open streaming everything else out already so why not take the time after the user has everything and do some more work to regenerate some of the content you've just delivered hot content in that. Next question. So obviously this is super exciting because of all the work we've done to enable this in Drupal 8 but the elephant in the room for this is how do we still allow people to install the module on a live site? Anything that rebuilds the container is going to be very problematic for a long running process so are we going to just leave it to the sites themselves to say well if you do that you're going to have to do something about this or are we going to have a front back then? So let's say like this if you install a module and you have a request let's say you have a slow page and you have some little callback that calls to some web service somewhere and that web service happens to take 20 seconds today so and meanwhile this request is serving this user someone else compiles a container we have set race condition today so that's not a concern. For the long running thing what we can use and obviously that's another database hit and that's where I really want to go is atomic counting. Okay the database is not as atomic but it's atomic enough for our needs which means when we install a module we are increasing the counter in the database and then everything that was previously cached and everything is then outdated and we completely restart our long running process and that's a way to synchronize that and that's how we use currently timestamps but I would like to go away from that if you know perhaps you know in Drupal there's a fast chain backend which means you have the consistent backend which is the database and you have APC on several webhands which is the inconsistent backend and whenever there's any write all the caches of that bin are invalidated because there's this timestamp in the database but we can use the same model of versioning things for many more things and I do think when you're deploying code you should increase your version identifier then everything is automatically outdated when you're enabling a module we are increasing this counter and everything is automatically invalidated and that's how I would approach a problem that's atomic counting It'll be interesting to see it work in practice because as you're well aware we had significant issues with all because basically the whole symphony kernel is not built to make that type of change like what code is loaded during your live site actually working so I think you make it sound nice but I think we then have to stop allowing modules to do certain things so it's certain low level things like looking at like providing such middle ways that run before the container we might have to stop from doing that and having something else some form of low level things that work separately outside the module installation so modules which don't have that create databases and stuff like that but they just do these really low level things Yes for sure especially if you want to officially I mean as a contract project every site owner can decide if it's worth the risk or not and they now which request policies they have defined in the container and we could even warn for a big exception if there's a mismatch between bootstrap container and the other thing but obviously there is some application that we are trading for the speed and some modules wouldn't be able to do anything about it about that cache but on the other hand flexibility versus speed is always a trade-off in that but yeah I agree if we do some constraints on that it might be simpler to implement Dr. Mendegan so this is a some of the performance improvements are very very compelling for how we can speed up the public side of the website and I'm wondering if you could talk a little bit about how we could apply that on the admin side of Drupal sites as well my understanding is that the way things are working now all the improvements we've made for caching and things we're not really doing that on the admin side which results in if you've got a a fairly big Drupal site and you've got a fair number of modules installed it can be a very very very slow process navigating the admin side of the website so how can we take advantage of some of these things to make that part of working with Drupal a lot faster it's an interesting question obviously so the admin side has one big problem there's usually a much more huge security concern about admin accessible pages and for other things so even while we could for example cache platforms and even deliver them real fast there are it would be much more cautious in doing so and would at a maximum allow caching that site per URL and per session because everything else which is more granular I would personally ask too much as a security risk that said however slowness on the admin side there's several things in my experience one is that sometimes there's unnecessary work like for example a block is placed always somewhere and it's placed in a region that does not exist but then it was in Drupal 7 sometimes blocks had been rendered because they were enabled for that scene but they weren't even there so it was just unnecessary work so again avoid doing the work and then the other thing however that I would like to see more is render caching of forms and tackling all that form stuff and I would like to see this in a again kind of three step process where first of all we are changing our form things to be true objects and we are making them also available for example to JavaScript to directly manipulate so our widgets are no longer like things that are just there but in the end the form is just an array of objects and every such object could much simpler be cached under certain conditions than the whole form and also what we can do and that's kind of the approach I think we've been designed to be working with Drupal 8 and 9 by now is we can introduce new layers like we could introduce a new kind of form API for example having these widgets or we have a new form API which has some restraints and you cannot do certain things but if you follow those restraints and if you for example register a URL for your form or if you register a callback for your form then we can shortcut certain things and we can cache your form then we can do certain things and with all the other things it was a quite long process but we can do the same for forms too forms are not un-cacheable we've proven them in Drupal 7 to be cacheable even in Akamai and replacing such things that are dynamic just on the javascript side so it's possible, I know it's possible it's just work that needs to be done and someone being crazy enough to say I really want to cache those forms and I'm just trying it out and there will be 30,000 test failures at the beginning but I check every challenge I'm getting and then I'm seeing that and as I said there might be kind of like a new form class cacheable form or something like that which has certain restraints and has certain parameters in being cacheable because currently you could pass a note to a form as a parameter how would you recreate that? it's impossible so forms need to be lazy buildable, they need to be independently buildable they need to have a clear defined input and output and a clearly defined state which is stored somewhere and once you have kind of cleaned that up and made it then it's cacheable and then the admin form and probably forms are like 90% of all admin pages plus listings and listings already have at least some views when they're caching so probably forms are the biggest chunk left and we can tackle that I feel like this would play really nice with like an Ajax-based system where you could just jump right into your placeholder system and say give me this when you have it and you don't have to reload whole pages so like all the groundwork you're laying here could also be used for that kind of stuff yes exactly so in Drupal 8 what you have available is a render strategy service which is by default a change render strategy service so you can just define your own render strategy and you could just have a dummy block and then you have like a render strategy that's replacing that with an Ajax thing and you're done or with something purely rendered by JavaScript and so you can define a custom render strategy that could even play with Ajax really nicely oh and there's even something we forgot in big pipe in 8.1 I've talked with some people here at DrupalCon and told them yeah my initial prototype had a little more and I was like explaining it was like oh I totally forgot so for example at the moment a block is when it's a placeholder it's big piped when big pipe is on but what we can do now nicely and easily is we can just put in a cached render strategy and for all the placeholders that are already cached when big pipe is on we just replace it directly and not big pipe it by if it's cached already why should we do further rendering of it no need to yeah and there's other really really low-hanging food in true if you want to make Drupal 8 faster and don't want to tackle any of that complex stuff there's some very very low-hanging fruit at the moment we are doing if you have a list of 10 blocks we're doing a cache get for each in Drupal 7 there's a cache get multiple on that you can implement that today any one of you can work on that there's an issue for that in the queue and that could be a pretty nice performance chunk for free the only reason neither me nor Wim has tackled that is because we had been so busy of making all the changes that are bc breaking in the Drupal 8 cycle and but yeah there's some low-hanging fruit that can give tremendous performance improvements just for free and as I said the placeholder system is not yet completely implemented how I originally envisioned it I even had it that something that's not a lazy builder could still be placeholder with some little tricks yeah further questions I don't think time is up anyway right okay then thank you so much tell me how it was have you evaluate the session evaluate the cooking sometimes very very seldom


Hello everyone. Thanks for coming to my talk. Thanks for listening and thanks to the organizers for the invitation. I'd like to speak today about joint distributions and probabilistic semantics. So probabilistic semantics is a subject that goes way back to I guess around the early 80s, late 70s early 80s, starting with a discovery by Jerry of the so-called Jerry monad, which is very important in probabilistic semantics has been for quite a while. It was actually known to Lavere back in 62, although it was before the relationship between monads and adjunctions were discovered. Around that time, early 80s, there were a lot of papers developing the semantics from different points of view. Here's some of them that are listed. This is can consider this to be prehistory. And the subject lay dormant for a while until the discovery that the probabilistic programming languages would be useful, very useful in machine learning and statistical analysis of large datasets. And there's been a renewed flood of interest since around the early 2000s in this area. Some of the features that are required in modern probabilistic programming languages that were not available in the early versions were our Bayesian inference, very useful in machine learning and conditioning. You would like to do samples and then update a prior to a posterior guess of some probabilistic model based on the outcomes of your samples. In addition, there's interest in higher order constructs. Since the early 2000s, people have started looking at programming languages for this kind of probabilistic programming and a very long list of programming languages has been developed since that time. Just a few of them are listed here. There's also a renewed interest in probabilistic semantics to deal with conditioning, Bayesian inference and higher order programming. Here are some list of a few more modern approaches. These spaces are a little bit more categorical in nature and higher order, as I say. They all relate to each other at some level, but look very different in practice. And it's still kind of an open question exactly how they relate to each other. To model Bayesian inference, most of the approaches, at least the ones that I know about, use a technique called disintegration. And it's become a very important concept, very important technique for modeling conditional probabilities, conditional expectation and Bayesian inference. I'm going to talk about this a little bit later on in some detail. In this talk, I would like to go back to a model of Bramsky, Blut and Penn and Gauden from 99 called P-REL, which is a category, symmetric manoidal category of joint distributions. And P-REL limited those spaces to spaces that allowed disintegration so that they could compose these probabilistic relations. And what I want to do here is show that you can actually do this without disintegration. And in so doing, I'm going to generalize the category to other spaces that, including spaces that don't admit disintegration. We want disintegration so that we can do the composition. And in order to do that, we have to make some restrictions on the category. Typically, you restrict categories to standard Borel spaces. What I'll do is I'll give a faithful embedding of a category called Kern of Markov kernels into the category of joint distributions. And in fact, limited to standard Borel spaces, the two categories are equivalent. The advantages of the joint distribution category are that there's a symmetry between input and output. So you don't really need disintegration. And it's a step towards a point-free approach. As an added bonus, I'll give an enhanced Radon Nicodine constructed construction. This is a standard technique for producing a derivative of a measure. And we'll show how it can be done in a little bit more generality. And it's actually necessary for the construction to do this. Okay, let's go back to the original system that was used to model probabilistic programs. And that's Markov kernels. They have lots of names, stochastic kernels, stochastic relations, measurable kernels in literature. And they're defined as follows. So if you take two measurable spaces consisting of a set of points or outcomes and a set of events or measurable sets, take two of these things. And a Markov kernel going from X to Y is a map that takes a point in the input side, in the X, in the set X, and a measurable set on the output side and gives you a real number. And it has to satisfy two properties. For fixed first argument, the function of the second argument must be a probability measure on Y. Sometimes you take subprobability measures, but in this talk, I'll just restrict to probability measures just to add an extra point in which you stick all the non halting probability. And then the second property is that for fixed second argument, the function in the first argument is a measurable function on X. And the reason why you want that property is that you want to be able to compose these things sequentially by Lebesgue integration. That's how they get composed. It's an analog in measure theory of multiplication of stochastic matrices. The morphisms form, these Markov kernels form the morphisms of a category called S-REL, which was studied by Ben and Godin and Dobrikat in the early 2000s. And I'll write P X to Y when I'm thinking of it as a morphism in this category. This category, S-REL, is actually isomorphic to the Klyzly category of the G-R-E monad. Okay, so this is what a Markov kernel looks like. It's a little bit unsymmetric in the sense that on the input side, you just have a point. On the output side, you have a measurable set, B. And the value of the kernel on S and B gives you the probability that, you think of it as the probability that if you start in state S and run this process P, then the probability that the output state will land in the set B, or equivalently the event B will happen upon output is the value of the function PSB. And this is a Klyzly arrow of the G-R-E monad. You compose these things by integration up the middle. So what you do is if you have two of these things, P and Q, two kernels, you use the fact that P is a measure in its second argument for a fixed first argument. And Q is a measurable function in its first argument for a fixed second argument. And to get the value of the composition on S and B, you integrate up the middle. So I'm going to divide the space, Y, the mediating space into little infinitesimal regions in which the value of the function doesn't vary too much in a region and take the value that I get into B from T and then sum up over all of these little regions and take the limit. And that's the Lebesgue integral. You can also lift, you can do Klyzly lifting for the G-R-E monad. That's what this is. So you instead of an input point, you can assume that there's a measure on input, let's say mu, that comes in. And again, you integrate. So you divide up and take the sum over infinitesimal regions and take the limit with respect to mu. And that makes, and I denote that by mu semicolon P. So sort of like composition, sequential composition. And what you get is a measure B that's defined this way. Again, it's just Lebesgue integration. And this becomes a bounded positive linear map from measures on X to measures on Y. So this map of the, of a map of whose inputs are, are measures. Now this was made into a category called Kern by Dalquist et al. in 18 couple years ago. This was at MFPS two years ago. The objects of the category are probability spaces. X, A, where X is a set, A is a set of measurable sets. And typically you take a standard Burrell space. And mu is a probability measure on that space. The morphisms are equivalence classes, modulo mu null sets of Markov kernels from some space of this form to some other space of this form. Such that mu, the probability measure on output is mu composed with P. And what they show in this paper is that Kern is a dagger so-called involutive category with an involutive functor going from Kern to Kern op. And this is done by disintegration. So what this does is it allows you to take this map, which is, looks like a Markov kernel, and turn it around in the other direction. And that's done using disintegration. And it satisfies these two properties that if mu is the output measure on input mu from P, then if you apply the transform here, the involution to P, then mu will be the output now and mu will be the input. And it goes in the opposite direction. So here's the picture where P goes from left to right. P dagger is going from right to left. And you can think of P dagger of T and A as the probability that the input state was in A when T was the output state. So in this way you can draw inferences on the input distribution based on some sample that you took from the output distribution. And this is used to model Bayesian inference. And the nice thing about doing this way is that it works for continuous distributions even when the outcomes can occur with probability zero as you would have with a continuous measure. It still makes sense. Now I want to talk about joint distributions. And this was done by Abramsky et al in 99. And the way what they did was they observed that P and P dagger can both generate joint distributions on the space of the input space, the product of the input space and the output space. So the way you can do this is take the kernel P and just make a new kernel P hat that remembers its input state. So on measurable rectangles A cross B, its value on the input state S will be the value of P SB if S is in A and zero if not. Okay, very simple. And we can do the same thing for the for the dagger for the symmetric for the transpose. And if I lift then using an input measure mu, I get a measure I get a joint measure on X cross Y. And if I lift P dagger, I also get a joint measure on Y cross X. If I lift the output measure, if I lift P dagger by the output measure, I get a joint measure on Y cross X. And it turns out that these things are the same measure or actually just transposes of each other. So what we get is a joint distribution in both cases.  Okay, so I got mu P hat, which is a measure on X cross Y and U P dagger hat dagger, which is a measure on Y cross X. They have marginals mu and new. And they satisfy this property that they're just transposes of each other. Okay, so using this idea, it was suggested that well, maybe we should come up with a category that has these objects or has morphisms, these uncountable stochastic matrices, if you will. And Abramsky et al did this, and they called it PREL. The objects again were the same as in Kern and restricted to, we have to restrict to standard Borel spaces so that we can do disintegration. The morphisms are the joint distributions. And the question is now, how do you compose these things? You can't really multiply uncountable matrices. But what you can do, if you can do decomposition, is you can decompose and then use integration. You know, I'll show you how that works. So before I do that, I have to say what disintegration is. So you disintegrate. And what disintegration is, this is a little bit different from the standard presentation, but it's equivalent. Disintegration is the inverse of the operation that I did before where I took a kernel and an input measure, and I lifted it to a joint distribution.  And if I take mu and nu now, and if I now lift this, if I take this kernel that I get by disintegration, and now I lift it again, and now I lift it again, I get theta back. And p is unique up to a mu null set. So mu and nu are parameters of this construction. I'm given a joint distribution with marginals mu and nu, and I can construct this p, and that's unique up to a mu null set. Unfortunately, this doesn't work for all spaces. There are counter examples. So people typically restrict to standard Borel spaces, and that's what everybody does. And without loss of any practical applications, you can do that because it's about all spaces you ever care about are standard Borel spaces or finite spaces or discrete spaces. The most general result that's known in this area is you can do disintegration for spaces that are countably generated. And if the measures are perfect, that's a recent result of Culbertson and Sturz. Now, once you can do disintegration, then you can compose in p-roll. And the way that works is if you have two marginals, if you have two joint distributions with marginals mu and nu, and nu and c, so the mediating marginal nu is the same in both cases, theta from x to y and eta from y to z, then you can disintegrate to get two kernels. You can compose the kernels in the category kern using Lebesgue integration to get a kernel from p, semicolon q, and then lift again to a joint distribution on x and z. And that's how it's done. Okay, so our main result that I want to show you is that you can actually do this composition independently of disintegration. You don't need disintegration at all. So you don't need to restrict to standard Borel spaces. This holds for all measurable spaces. And the technique I'm going to use is an enhanced reton nicotine theorem for derivatives. Okay, so I'll define a new category that's a generalization of p-roll. The objects are all measure spaces, super category of kern and p-roll. Morphisms will be joint distributions from the space to the space with mu and nu, and the joint distribution has to have marginals mu nu. Those are the morphisms. And I'm going to get a faithful functor from kern to j-dist, which is the identity on objects. And it just takes a kernel or a equivalence class modulo null sets of mu of kernels and lifts to this, lifts to the joint distribution as I showed before. And I get a joint distribution with marginals mu and nu. And this gives a, I'll show this gives a symmetric minoidal category with joint distributions as tensors and transposes symmetry. So it looks just like this. It's just, it's the real transpose of that uncountable matrix. So it's got a very pleasing symmetry unlike kern and p-roll. Sorry, unlike kern, not unlike p-roll. It's the same as p-roll. Okay, so the lemma we need to prove, one lemma we need to prove is that the following are equivalent, that p and q as kernels are equivalent in modulo a, I didn't actually define this equivalence relation. It just means that p, that the set of, that for any measurable set in the output space, the set of input points, which cause p and q to be different is of measure zero in the measure mu. And that is equivalent to saying that p and q have the same image under this functor j that takes you up to j dist. And what that says is that this functor j is going to be faithful for that reason. Okay, we need to use right on Nicodemus approximants. So here's the definition. So let's let mu and mu be finite measures and then consider this set of quotients for all measurable set C in a measurable, subsets of a measurable set B such that mu of C is greater than zero, is nonzero. And the set is nonempty if mu of B is greater than zero. And if that happens, then it has a finite infimum since this is a member, but it may be unbounded above. I'm going to take all of these quotients between mu and mu and mu and mu. And I'm going to look at the sets of the sets of these quotients for over taken over all subsets of some measurable set B for which the value of mu doesn't vanish. And for any epsilon greater than zero, I can come up with a countable measurable partition of D of the input space X such that for all nonempty or all B whose measure is positive, the set GB is bounded, the set of these things is bounded. And moreover, the difference between the supremum and the infimum is bounded by arbitrarily small epsilon. And then this other inequality here is I also show for technical reasons. Okay, moreover, these are preserved under refinement. So this refinement, this is refinement of countable measurable partitions of the space. That's what that inequality is. And using these definitions, I get these radon nicotine approximants. And these are the same approximants that you get in the proof of the radon nicotine theorem. You're going to get step functions here based on these values. And it's going to turn out that you can prove this enhanced version of the radon nicotine theorem, which is the first statement says that you get Lebesgue decomposition out of it. So you get a Lebesgue decomposition that says you have a, if you can decompose a measure into two measures on which the value of some measurable set F, this measurable set F is zero, and then mu is also zero. And the radon nicotine theorem, which is a derivative, you get a derivative S such that V zero is the integral.  And mu vanishes outside of F. Now these two parts of the radon nicotine theorem are what you can find in any textbook. But what you don't find and that what I need is some uniform convergence property of these approximants. So usually when you see the statement of the radon nicotine theorem, you don't see the approximants anymore. They kind of go away. So what this says is that there's a lower approximate, a set of lower approximants that is monotone non-decreasing on F and an upper approximate that's monotone non-increasing and both converge point-wise to F and point-wise to the function F and converge uniformly on F. And F is a set of measure one, mu measure one. Okay, so if you take, if phi is absolutely continuous with respect to mu and you take these values for, sorry, mu is absolutely continuous with respect to mu and you take mu zero and mu one to be nu and zero respectively, then you get the classical radon nicotine derivative d nu over d mu. There's really nothing new in anything I've done here. The standard references, a cert one and two, without reference, this is the scaffolding that goes away when you state the theorem. But all of the stuff that I mentioned is implicit in the proof and you just have to go in and dig it out. Unfortunately, I need it. I can't do without it for what I want to do. Okay, I'd like to note that the value of the integral is independent of the choice of this countable measure, the sequence of countable measurable partitions. But F and F are not, and there's nothing that works for all sequences, which is why the radon nicotine derivative is only defined up to a mu null set. Okay, so here's how you do composition in J-dist. Given two joint distributions, okay, with theta and eta, with theta having marginals mu and nu and eta having marginals nu and xe, you compose them this way. You take the value of the composition on a measurable rectangle, A cross C, as the limit over all countable measurable partitions of this sum. Now, I have to emphasize that this is a kind of a weird limit because you can't have anything that works.  There are too many of them. But what you can show is that if any one of these sequences of countable measurable partitions, if you have a sequence that converges and another sequence that converges, then they converge the same value, and moreover, there's a least common refinement of the two that gives you the same value. So you get a unique limit, if you get a limit at all. And it's just defined this way. Okay, so you have to show that this limit exists and that comes from this use of the radon nicotine approximants that I mentioned last time. You have to go through the argument that everything works out and converges the way you would like. And then we only defined it on measurable rectangles, but that extends to a joint probability measure on the product space using the Karat Theodori Han-Komogorov extension theorem. So what we get is a faithful embedding of current into J-DIST, a bona fide symmetric minoidal category. Okay, it's completely symmetric in the input and output space, so no difference. You can just turn things around. It's a symmetric minoidal category. The tensors are the joint distributions. I would like to get some kind of a closed structure on this, if I like, because after all, joint distributions are distributions and that's what the objects are. So there might be a possibility of getting some kind of closed structure. And it's also a dagger category or an evaluative category that has an involution or a symmetry. And that's just composition with the transposed operator on the underlying space. So in conclusion, I've given a definition of composition of joint distributions without references to disintegration, so it holds in more generality than previously known. You don't need to assume standard Burrell spaces. You get a symmetric minoidal category, not closed J-DIST of joint distributions. The Markov kernels are faithfully embedded. And for the future, I'd like to give a point-free treatment and a closed structure, if possible. Okay, thanks very much. And thanks to these people you see listed here, all of who helped out. And especially to Sam, who caught a serious error in an earlier draft of this paper. Thanks very much. See you soon.


Involved with the project, an overview of the project and the areas being affected with this project. Go over some frequently asked questions and look at a timeline for what the project looks like. So, your project team includes myself Brenda, I am the project manager. My phone number is<PHONE_NUMBER>. Again, that number is<PHONE_NUMBER> and my email address is Brenda, period, at 4th word, Texas dot gov. And the engineering design consultant we have on board for this project is Jane's engineering and Brian is the project manager on their end. So, why are we doing this project worth worth prior ties is water and sewer line replacements faced on available data, which includes the water, main break, break history. Leak history, close circuit TV inspection, the age of the line, the material of the line. If there are any large services on that line, or if the line is made of cast iron. So project overview, these lines specifically for this project were selected because the water lines are made of cast iron. And the sewer lines are old and in deteriorated condition. So the project area is found by South Hills Avenue to the north. Manderley place to the south. Bellar circle to the west and Carolyn road to the east. Landmarks include the McLean middle school, West Cliff shopping center. Trail Lake Montessori preschool West Cliff elementary school and West Cliff park apartments. Project scope so on the map you see on the right hand side. The black lines show the areas being affected by the project so existing water and sanitary sewer remains will be replaced. And 9 streets and for Eastman. So the project is in council district 3 construction will impact the West Cliff neighborhood association and West Cliff West. Neighborhood association so now we'll kind of go through each individual street or area being affected. So we have trolley drive from South Hills Avenue to Manderley place and we will be replacing the water and sewer. Norfolk road from Brighton road to Caroline road, we will be replacing the water on the street. Caroline road from Brady Avenue to South Hills Avenue, we will be replacing the water. Right and road from Brighton road to Trolley Drive, we will be replacing the water. Right in road from Bella circle to Trolley Drive, we will be replacing the water. The easement between Brighton Road and Somerset Lane from Beller Circle to East 914 feet, we will be replacing the sewer. South Hills Avenue from Beller Circle to Caroline Road, we will be replacing the water. The easement between Winslow Drive and Trolley Drive from south 170 feet of the soulful drive south 65 feet. We will be replacing the sewer. The easement north the soulful drive from Trolley Drive West 605 feet, we will be replacing the sewer and soulful drive from Winslow Drive to Trolley Drive will be a water line replacement. Eastman between soulful drive and Mandorley Place from Trolley Drive West 1260 feet, we will be replacing the sewer Mandorley Place from Winslow Drive to Trolley Drive. We will be replacing the water. I need to avenue from Cordo Avenue to soulful drive. We will be replacing the water. So, now I'll be going through some frequently asked questions to construction, which we will be having a public meeting later on for the construction of the project, but these aren't just some frequently asked questions. We want to touch base on. So, will our water be turned off the water will be turned off for about 15 to 30 minutes when the services are being transferred from the existing line. To the temporary water line, and again, when the water line is being transferred from the temporary water line to the new line and these switchovers are done during the day. The contractor will knock on your door and let you know when they're going to be turning the water off and the transfer typically takes about 30 minutes. Her household how does the temporary line impact my home and water bill. So, the temporary water line ensures that you are not without water during the construction of the contract in the summer months. The continuous flow keeps the water from becoming stagnant in the above ground line. During the winter months, water must be continuously flowing through the temporary line to keep the water from freezing and customers should make sure they keep their faucets dripping. The bill for your water usage will while you are on the temporary line is based on the average of the previous month's usage. So, will you need access to our properties construction will be in the streets and easements. We are going through acquiring some easements. As we speak, if we need an easement from you, a land agent should be reaching out to you. If the 4th worth water needs access to your property, we will be contacting you directly. If an easement is needed, the city land agent will be contacting you. And that should be Austin lobes. Will our sewer service be disrupted? The sanitary sewer service will not be interrupted. New sewer cleanouts will be installed at the property line or easement line. If you are sewer line is located in the back of your house, the sewer cleanouts provide our field operation cruise easy access if for some reason you have a backup or blockage. And that just kind of lets the field operations truth go in there and determine if the blockage is on the private or public side. The sewer line from the cleanup to the house is the owner's responsibility to maintain. Will I have access to my driveway and inspector will be assigned to the project when we are ready to start construction. The inspector and contractor will work with the residents who need driveway access during active construction hours.   So the trash collection vehicle can pick them up. Will there be lane closures during construction? Yes, signs will be posted to alert motorists. We don't have a traffic control plan yet as this is a design meeting. Once we have our construction public meeting, we'll have more information on the traffic control. What are the construction hours? The hours of construction are 7 a.m. to 6 p.m. Monday to Friday. And if requested by the contractor, we also allow them to work 9 a.m. to 4 or 5 p.m. on Saturdays timeline. So, this project is still in the design phase. We are working on getting easements for some of the sewer lines in the project. We expect to finalize the design advertise for bid and select the contractor before spring of 2024. And we will be hosting a community construction meeting. Once we do have a contractor on board and we can provide more information. So, where can you get more information as the project moves forward? You can go to www.forthward, Texas dot gov and type in the project number, which is 1, 0, 3, 4, 2, 1. Again, that number is 1, 0, 3, 4, 2, 1. In the search bar on the home page, the headline West Cliff and West Cliff, West area, water and sewer improvements should pop up and that will take you directly to the project page to get project page updates. You can scroll down to the bottom of that project page and click on subscribe to this page. The link to the project summary frequently asked questions will be linked to the project page as well as a video of this presentation. How do I report an emergency or non-emergency for non-emergency? You can call our water call center from 7 a.m. to 7 p.m. Monday to Friday. That number is 817. 392. 4, 4, 7, 7. Again, that number is 817. 3, 9, 2, 4, 4, 7, 7, and they are closed on city holidays. But if you do have an emergency, our emergency number is the same number. It's 817. 3, 9, 2, 4, 4, 7, 7, but you select option 1 and the emergency number is for water main breaks, sewer backups, and they are open 24 hours a day. You can also download the MyFW app, the MyFootboard app, from the app store or Google Play. On the app, you can report sewer overflows, leaks, water main breaks, missing or broken meter lids, theft of water service, water violations, lack of water service, water pressure issues, or any other sewer concerns or water concerns you may have. Here is my contact information. Again, my name is Brenda Oropeza. I am the project manager for this project. I can be reached at<PHONE_NUMBER>. Again, that number is<PHONE_NUMBER> and my email address is Brenda.Oropeza at www.FordWordTexas.gov and our engineering design consultant is the engineering with Brian Darby. They are a team from MyFWord as the project manager. All right, thank you. I'll hand it over to Sally so she can go through the questions that may have been asked on the chat. We don't have anything in the chat now. If you all would rather put your questions in there, you can. Everyone is muted, so I'm going to unmute all. So, if you have a question, go ahead and ask. A lot of you on there tonight. Oh, and also welcome to Katy Wary. use your district director for council district 3. Scott, did you have a question? I do. I dialed in just a little bit late, so I understand you're in the design phase now, so what's your anticipated let date and start date for the actual project and how long do you anticipate it'll take? So right now, our main delay will be those easements that we're working on acquiring. I know Austin Lopez has been in contact with some homeowners. To talk to them about acquiring those easements, so I think that will be the main delay to the project right now. We're anticipating to start construction in spring of 2024. But it will really depend on those easements. Sure, once you do secure them and you get going on the construction, what's your anticipated. Completion, how long do you think it'll take to get the job done? I think we're anticipating about a year. Brian, can you speak on that? Brian's on the call as well. I was trying to double check our last estimate, but I believe a year is a safe estimate from start to finish of all the streets, water and sewer. Okay, thank you. Let me just go back to the map so everyone can kind of see the areas. We will be working on and we do have 60% plans if you're. Being affected by this area, you can reach out to me and I can kind of tell you what we're proposing on your property. I have a question. Yes, ma'am.  And you said the project may take a year, but for each segment. Do you have any idea how much, how long you're talking about? So, for each usually the 1st street, it takes about 2 weeks to install the water or sewer lines. And then they usually put down temporary pavement. And we will be doing full width pulverization and overlay of that street. But for the water and so it should be about 2 weeks. Okay, and then you said there's temporary pavement and then you come back and put permanent or. Yes, they'll do the full width of the street though pulverize and overlay the street. So it'll be new asphalt pavement on there. Does that include curbs or just depends on what they have to do? It really depends, but on this project, it'll most likely just be damaged and based on the condition of the current. Urban gutter. Okay, thank you. No problem. You don't have any questions in chat. Can can everybody ask a question? Are you unmuted? Yes. Okay. All right. Let me run down the list just a second. Bob Stewart, do you have any questions? Any questions? Mitigation to damage to trees and. You know, any other kind of floor that might be in their way? How did I handle that? So, I do submit my percentage every time we have a submittal from Brian, we do submit also to. Craig Fox, who's our forester. Okay. So, where of the areas. Being impacted, if there for some reason needs to be a tree moved or anything, we do go through Craig Fox for him to make that determination. And, uh, Mr. Fox last name is F. A. L. K. S. No, um, F. O. X. Oh, Fox. Yes. Sorry. And he's a forester. Yes, he's the city forester. He's the city forester. And do you have his contact information along with you've given us the other. Can you share it or is it available through the city website? Can you share it on the chat selling or I might have to set out of the PowerPoint. I just looked it up. I'll put it on chat too. It's 817. 3, 9, 2, 7, 2, 9. Thank you so much. Okay. I know you mentioned Bob Stewart was on the line. I know he was reaching out to me earlier about if we were going to be doing any drainage improvements. I'll respond to his email, but I was reaching out to our storm during department, but they don't have any drainage improvements planned for that area for South Hills Avenue and trawling intersection. Just a second. Okay. The city foresters phone number is in chat. All right. So, oh, let me see. We've got Jennifer and we've got Lauren Baxter and Sally's Michael crane. I just signed on. Oh, hey there. You were the beat then. Yes. Welcome, sir. Thank you. Michael crane is your district three council member. If you have not met him yet. And are you are you welcome, Kate? Oh, good. I'm glad she was able to get on. I didn't have the passcode, but go ahead and keep going. I don't want to interrupt your presentation. Okay, that's okay. Thank you. Where are we? We're at Jennifer or Lauren Baxter? I may, I may mess this up. Is it Rion McWire? Yes, it's Ryan Ryan. Okay. I think, I think he answered my question. I was just asking if you were just going to patch where you were placed in the water line or was it a complete re overlay of the street? Yes, it'll be a complete re overlay of the street, but no drive approaches. All that will just remain the same for the most part. If there's a meter on your driveway, we will be relocating those meters out of the driveway. So we will be redoing those drive approaches. Okay, and so it's an asphalt street now. So you just replace it with asphalt not concrete. Yes, that is correct. Okay. That was it. Thank you. Okay, uh, Sally McCoy. I already asked my question. You did. I should remember them. My name is okay. All right. Let me run back up the list. Um, I've got someone by the name of X and your hand is in the air that looks like you might have a question. Andres, we have several calling users. So if you are a calling user and you can't see the screen, go ahead and ask your question. Does anybody else can can y'all see the chat with the contact information? Yes. Okay. Does anyone else need any information to copy down from that chat? We've got the forester. We've got Brenda and we've got the link to the project page. Did we miss anything? Brenda, did you say when we might be coming back for a construction meeting? Well, park. Um, that's really dependent on the easements, but it'll probably be February next year that we can have our construction meeting. And Carol, you're very welcome. Thank you. Okay, Terry. I appreciate the early information. You're welcome. The Charles Nixon. Do you have any questions? You came in late. So if there's something you want to go back to, let's know. Rob Stewart, your hand is still in the air. And X, you had no questions. All right. If you can give us, this is what Monday, probably by Wednesday, we will have the, um, what we do is we make a YouTube link to the WebEx and that goes on the project page. And again, we have the summer written summary FAQs. If you just rather read it are in English and Spanish. And the map is already on the page. And also there's a new thing you can do. You can subscribe to that page. So we usually monthly updates. And if you sign up, what you do is you scroll down to the bottom of that project page and you click on the subscribe to this page and put in your email. So anytime that I go in there and I do an update to the page, you get an alert that the page was updated. Now, it won't tell you what was updated. So you might have to, you know, look around a lot of times. It'll actually the new project meeting that we have, the construction one will be listed on that page under the project meeting tab. But you will also get a mailer. If you've got a mailer this time, you'll get a mailer next time. All right, Brenda, did we miss anything? Oh, I'm sorry. Heidi Swartz, did you have any questions? Do you have a new one? Okay. Okay. Thank you. Oh, wait a minute. Okay. How do you say no questions? All right. Thank you, everybody for coming out on this rainy night. We really appreciate it. Thank y'all. Appreciate it. Thank y'all. If y'all have any questions, my contacts on there. And if you have any specific questions about your property, feel free to reach out to me. All right.


TLO what's poppin We are on twitch. We are not live, but you can leave a like comment subscribe turn on your post notification bells Let's continue to grow the family from Chicago to the UK speaking of growing the family.  I'm your favorite big sis miss Renice K. Bell. I'm also the CEO of blueprint What else do you do? You know what I do a show called supercharger morning, and I'm a brand architect So I help small business owners grow start and develop their companies And then we have a morning show to make sure you on the right path every day You can find me on Instagram and all the other platforms as well as my website at Bernice K. Bell I'm gonna leave that down in the description. I know y'all didn't get that Okay today we're gonna be talking about It's controversial Andrew Tate Andrew Tate funny and offensive moments. Yikes. Are you ready for this? I barely Let's see what happens. I Do not hold on. Let me go back go back. I do not support Tate in any way YouTube that is for me to please do not Give me any type of restrictions on this video.  Oh, I'm sorry. That threw me off That's that's interesting. I was not ready for that like I Don't write get back play That's a rough take. I'm telling you. Jesus. Holy Jesus activate Because I don't believe it If you're asleep in your bed, you know, but I can hear a noise and you believe in ghosts Now you're afraid, but you don't believe in those Scots the wind you go back You give the ghost power by believing Your house is only haunted if you believe in ghosts believe is a powerful thing It's been fact right now. You know, that was the first thing that he said that I'm like, okay I'm get on board with that. This is thank you Fracturing and say the splinter into your heart would you allow me to try I believe I can't I believe I can hurt any man on the planet And that's why people are afraid of and you believe depression is a crippling And that's why you're afraid of it Well, you got a good point there. He'd be dropping some Jim's but like the Jim's be in the mix of Paka Hey, if you guys hear an echo, it's cuz we don't have headphones. I didn't bring my Split thing today. Oh my bad, and I'm hanging out with him the day y'all. Yeah It's the same guy What I've been on lots of trips to Dubai never had that Tanks rich call strong smart Yeah, sorry sorry to break it to you You're to see my dick it hurt you more than Let's say This is this is a lot going on Okay, he got 50 million I mean 500 million I guess when you get there you can say what you want Precisely right guys would be devastated I'm gonna try my best to not get my My airplane shower He better not right trying to avoid mirrors What is the point of this one? This is the shower aboard Listen first-class. Oh, this is oh Emirates I don't want that explains it I said it like I knew what was it? That is he's never heard of it. Yeah I fly spear writ. No, I know you plan. I have not your spirit with a flavor play. Yeah, I got Sit down Right, I'm scared this war is gonna come out cold Ah, but that's a Dubai right by right what is Dubai writing? What do you mean Arabic ah, it's Arabic. It's a Dubai right. I'm done Whatever I didn't come in It's not working. I just got dressed to go get the lady and then I thought I bet it's because I haven't closed the door So I don't want to get cold. That's what I'm forcing you to get cold My ninja brain He had a blonde moment, yeah, but he's bald. That's a smart shower. I never heard of a smart shower You know you save clean up. Hmm shower time This is very suss my bad That's cool There's no way to turn the shower on and let it get boring before you get in there No, because then you can't you can't turn it on A little bit cramped.  I can't believe I'm watching another man shower on the plane How much time on the ground? I'm definitely living wrong. I need to be on this flight. Yeah, I never never flew anything with spirit. So I don't Spirit is like frontier for y'all or something No spirit is like um a legion For the ryan. No ryan air ryan air is like the the the Equivalent to the spirit is ryan ryan air. No, I've lived in Europe. I've lived in Germany Okay, I've never been on the Emirates like it. What is he watching? Scout What is this done we're not gonna shower at all the plane We're on the ground Is that we've got a shower on a plane? You're in the air Think about it Technically that's obvious. I'm flying right now We're a lot like a shower on the ground. I wouldn't be flying. Think about that. That's the main difference Man we are the edge of our seats trying to figure out what he's gonna say. I thought it was gonna be philosophical That's all right You got me saying it wrong.  I was fast Okay, it's about 45 more seconds my bad job The seat works It's right on the edge of burning my skin forever and feeling okay I heard women take very very hot showers.  I don't think there's anything intrinsically wrong with women in open house As long as I had influence control over it Look at me, there's a bit of photography to get the angles in No, no, no, no, I'm not doing any real work. I'm just thinking all the work Huh, you know what? What? No, absolutely not like No, like I I do like his opinion though. He's like you could do it if I control it now The problem came in when you talk about if you're going to take the money That's the issue. Well, you know that if he is hypothetically, that's his girl Yeah, and she's doing only fans. You're showing What's mine right as my girl that's mine. Well, not technically If you had a man and he was just gray sweat pants in it all day like come on now. Yeah, exactly I definitely do Why women is going to give you eight rounds?  You're doing only fans. I'm selling my products to the funk You're put up. Yes, correct Next question I'm totally serious. How am I going to let my chick do only fans to keep all the money? That's disrespectful What woman is ever going to give you that? That she's going to do only fans. Duh Some child is outside enjoying it That is insane. Like you going to go to work and give him half your money You want to you better bring in six figures? No, I'd rather not work and then he could just pay everything And he doesn't have a problem with doing that though. Oh, okay. Well, you were 500 million Well, you know, then, you know, when you like can what people ask and then have all the money I guess you can do it. Say what you want.   Anyway, somebody get this little microphone They're all losers. We've discussed this before.  Don't talk to him.  We say bag, right back me up, right I've seen many women leave the club with top g's No, we come together. We leave together the real ones the real friends. We come together. We leave together. So how about girls trips? We come together. We leave together You know, I can't do girls We definitely I definitely do listen, that's part of the deal That's part. I do girls trips every year. It's part of the deal How keep my sanity? I gotta be a fifth wheel or something. I'm I'm coming I get a separate hotel You better wait at the airports. I get back Oh, that's his brother It's two of them Why did you choose a insult? Why do you call people worms? And it's very very clear to me at least why I call people worms Worm is a pointless creature the only So that bigger more important animals can eat something They don't do anything They can't see They sit in the dirt and they just move around in the dirt and they try his alarm's purpose I don't know He's right A little bit and then a birdie And most people they're food then that's what he said But no, they're supposed to move the dirt around like they'd be in the dirt Like shifting them around and we're not keeping it loose down there. Their bodies are in the dirt and they're not moving though Hopefully You don't do anything important.  Wait, he calls some people worms.   You know what you what's up worm?  It's very disrespectful Yeah, a hero defensive mechanism A worm is absolutely not really useless I've never heard of a story of valor That involves a worm People use animals as insults.  I know female dogs You have a female police dog that will charge you bullets where you have a fire dog that run in a burning building What's the wrong with being a female dog? The dog can do something Being a female worm would be much worse. Are there even female worms?    So I'm taking your girlfriend. You could do very little about it.  Yeah at heart What? Yeah, big word. You ain't even know. Yeah, he's philosophical, Joe Tla leave a like comment subscribe turn on your post all her information is down in the description if y'all want to follow Anything to say peace y'all. All right