Vocabulary and Reading. Exercise 7. Vocabulary study through context. These lessons are designed to teach you vocabulary and context and through exercises. Each lesson consists of a short reading about a U.S. state and provides 10 common words at the intermediate level. Prince Lot Hula Festival in Hawaii. Part 1. Pre-reading. What are some things people associate with Hawaii? Would you like to visit the Hawaiian Islands? What would you like to see and do there? What do you know about Hawaiian culture? What are some ways Hawaiians preserve their culture? Do you know how the hula dance originated? You might wish to pause the video and discuss or think about these questions. This article is about an interesting festival in the U.S. state of Hawaii. Part 2. Here are the words you will see in this article. Repeat for pronunciation. Chant. Cottage. Effort. Exhibit. Facial. Flowing. Perform. Preserve. Quilt. Worship. Do you know any of these words already? Part 3. Match the words on the left with the definitions on the right. I'll read the definitions this time. Maintain or keep something for later use. To act put on a show. Thick blanket. Move smoothly or gracefully. A show. Public presentation. A rhythmic string of sounds, sometimes set to music. Related to the face or expression. A small house in the countryside. Give reverence to something sacred. Work or exertion. Pause the video if you'd like more time. Part 4. Take time to read the article. Prince Lat Hula Festival in Hawaii. For the reading, pause the video and click on the link in the description below. You may wish to read it out loud for pronunciation. Stop the video and return when you're finished reading. Part 5. How was your reading? Talk about what you learned with your partner or teacher. Use some of the vocabulary words from Part 2. Pause the video for your discussion. Part 6. Want to try the quiz again? Feel free to pause the video if you need more time. Part 7. Here are the answers to today's vocabulary exercise. Chant. A rhythmic string of sounds, sometimes set to music. Cottage. A small house in the countryside. Effort. Work or exertion. Exhibit. A show or public presentation. Facial. Related to the face or expression. Flow. Moved smoothly or gracefully. Perform. To act. Put on a show. Preserve. Maintain or keep something for later use. Quilt. Thick blanket. Worship. Give reverence to something sacred. Come back and review these words often. And remember to check out our other videos for reading and vocabulary practice. Thanks for watching. Our websites will help you even more with your English language study.


Hey, everyone, welcome back to theCUBE's continuing coverage day two, Snowflake Summit 22 live from Caesars Forum in Las Vegas. Lisa Martin here with Dave Vellante bringing you wall-to-wall coverage yesterday, today, and tomorrow. We're excited to welcome Matthew Carroll to the program, the CEO of Emuta. We're going to be talking about removing barriers to secure data access, security. Matthew, welcome. Thank you, have me, appreciate it. Talk to the audience a little bit about Emuta.  Yeah, absolutely, thanks. Yeah, if you think about what Emuta is at its core is we're a data security platform for the modern data stack, right? So what does that mean? It means that we embed natively into a Snowflake and we enforce policies on data, right? So the rules to be able to use it to accelerate data access, right? So that means connecting to the data very easily, controlling it with any regulatory or security policy on it, as well as contractual policies, and then being able to audit it. So that way, any corporation of any size can leverage their data and share that data without risking leaking it or potentially violating a regulation. What is the key as we look at industry by industry challenges that Emuta is helping those customers address and obviously quickly since everything is accelerating? Yeah, and you're seeing it because the big guys like Snowflake are verticalizing, right? You're seeing a lot of industry-specific concepts. With us, if you think of where we live, obviously policies on data, regulated, right? So healthcare, how do we automate HIPAA compliance? How do we redesign clinical trial management post-COVID, right? If you're gonna have billions of users and you're collecting the data, pharmaceutical companies can't wait to collect that data. They need to remove those barriers so they need to be able to collect it, secure it, and be able to share it, right? So double and triple blinded studies being redesigned in the cloud. Government organizations, how do we share security information globally with different countries instantaneously, right? So these are some of the examples where we're helping organizations transform and be able to kind of accelerate their adoption of data. Matt, I don't know if you remember, I know you remember coming to our office, but we had an interesting conversation and I was telling Lisa, years ago I wrote a piece of, how to build on top of AWS. There's so much opportunity. And we had a conversation at our office at the Cube Studios in Marlboro, Massachusetts, and we both sort of agreed that there was this new workload emerging. We said, okay, there's AWS, there's Snowflake. At the time we were thinking, and you bring machine learning, at the time we were using Databricks as the example. Of course, now it's been a little bit more of a battle with those guys. But, and so you see them going in their different directions. But the premise stands is that there's an ecosystem developing new workloads, developing on top of the hyperscale infrastructure, and you guys play a part in that. So describe what you're seeing there because you were right on in that situation. Yeah, yeah, it's nice to be right. Yeah, so when you think of this design pattern, right, is you have a data lake, you have a warehouse, and you have an exchange, right? And this architecture is what you're seeing around you now is this is every single organization in the world is adopting this design pattern. The challenge that where we fit into kind of a sliver of this is, the way we used to do it before is application design, right? And we would build lots of applications and we would build all of our business logic to enforce security controls and policies inside each app and you go through security and get it approved. In this paradigm, any user could potentially access any data. There's just too many data sources, too many users, and too many things that can go wrong. And to scale that is really hard.  So Snowflake, Databricks, BigQuery, Redshift, Synapse, on and on, natively underneath the covers. So that was BI tools. Those data science tools hit Snowflake. They don't have to rewrite any of their code, but we automatically enforce policy without them having to do anything. And then we consistently audit that. I call that the separation of policy from platform. So just like in the world in big data when we had to separate compute from storage in this world because we're global, right? So we have a distributed workforce and our data needs to abide by all these new security rules and regulations. We provide a flexible framework for them to be able to operate at that scale. And we're the only ones in the world doing it. So the key there is, I mean, Snowflake is obviously building out its data cloud and the functions that it's building in are quite impressive. But at some point, a customer is going to say, look, I have other stuff, whether it's in an Oracle database or a data lake or wherever.  And if I'm hearing you right, you participate in all of that. Correct. Yeah, we're able to just natively inject into each and then be able to enforce that policy consistently. So, hey, can you access HIPAA data? Who are you? Are you authorized to use this? What's the purpose you want to query this data? Is it for fraud? Is it for marketing? So what we're trying to do as part of this new design paradigm is ensure that we can automate nearly the entire data access process, but with the confidence and de-risk it. That's kind of the key thing. But the one thing I will mention is I think we talk a lot about the core compute. But I think, especially at this summit, data sharing is everything. And this concept of no copy data sharing, because the data is too big and there's too many sets to share. That's the keys to the kingdom. You've got to get your lake and your warehouse set with good policy so you can effectively share it. Yeah, so I wanted to just to follow up if I may. So you've mentioned separating compute from storage and a lot of VC money poured into that, a lot of VC money poured into cloud database. How do you see snowflake differentiating substantially from all the other cloud databases and how so? I think it's the ease of use, right? Apple produces a phone that isn't much different than other competitors, right? But what they do is end to end, they provide an experience that's very simple, right? And so yes, are there other warehouses?  I think other vendors are obviously gonna have the same capabilities, but I think the user experience of snowflake right now is top tier, right? Is I can, whether I'm a small business, I can load my data in there and build an app really quickly, or if I'm a JP Morgan or, you know, a West Farmers, I can move legacy, you know, monolithic architectures in there in months. I mean, these are six month transitions. Think about 20 years of work is now being transitioned to cloud in six months. That's the difference. So measuring ease of use and time to value, time to market. Yeah, it's everything is time to value. No one wants to manage the infrastructure.  Those days are completely over. Can you share an example of a joint customer where really the joint value proposition that immediate in snowflake bring are delivering some pretty substantial outcomes? Yeah, what we're seeing is, and we're obviously highly incentivized to get them in there because it's easier on us, right? Because we can leverage their row and cum level security. We can leverage their features that they built in to provide a better experience to our customers. And so when we talk about large banks, they're trying to move terror data workloads into snowflake. When we talk about clinical trial management, they're trying to get away from physical copies of data and leverage the exchange as a mechanism so you can manage data contracts, right? So like, you know, when we think of even like a company like Latch, right? Like Latch uses us to be able to oversee all of the consumer data they have. Without like a snowflake, what ends up happening is they end up having to double down and invest on their own people, building out all their own infrastructure. And they don't have the capital to invest in third-party tools like us that keep them safe, prevent data leaks, allow them to do more and get more value out of their data, which is what they're good at. So TCO reduction I'm hearing. Yes, exactly. Matt, where are you, as a company, you've obviously made a lot of progress since we last talked. Maybe give us the update on, you know, headcount and fundraising. Yeah, we're just at about 250 people, which scares me every day, but it's awesome. But yeah, we just raised $100 million. I saw that, congratulations. On the series E, thank you with Night Dragon leading it. And Night Dragon was very tactical as well. We're moving, we found that data governance, I think what you're seeing in the market now is, is the catalog players are really maturing and they're starting to add a suite of features around governance, right? So quality, control, observability, and just traditional asset management around their data. What we are finding is, is that there's a new gap in the space, right? So if you think about legacy, it's we had infrastructure security. We had the four walls and we protect our four walls. Then we moved to network security. We said, oh, the adversary's inside, zero trust. So let's protect all of our endpoints, right? But now we're seeing is data is the security flaw. Data could be, anyone could potentially access it in this organization. So how do we protect data? And so what we have matured into is a data security company. What we have found is, there's this next generation of data security products that are missing. And it's this blend between authentication, like an octa or an ortho, and authorization, like a muta where we're authorizing certain access and we have to pair together with the modern observability like a data dog to provide a layer above this modern data stack to protect the data, to analyze the users, to look for threats. And so a muta has transformed with this capital and we brought Dave DeWalt onto our board because he's a cybersecurity expert. He gives us that understanding of what is it like to sell into this modern cyber environment? So now we have this platform where we can discover data, analyze it, tag it, understand its risk, secure it to author and enforce policies, and then monitor, the key thing is monitoring. Who is using the data? Why are they using the data? What are the risks to that in order to enforce the security?  Okay, well that's a new vector for you guys. I always saw you as an adjacency, but you're saying smack dab in the heart. Yes, yeah, we're jumping right in. What we've seen is there is a massive global gap. Data is no longer just in one country. So it is how do we automate policy enforcement of regulatory oversight like GDPRCCPA, which I think got this whole category going, but then we quickly realized is, well, we have data jurisdiction. So where does that data have to live? Where can I send it to? Because from Europe to US, what's the export treaty? We don't have defined laws anymore. So we needed a flexible framework to handle that. And now what we're seeing is data leaks upon data leaks and the snowflakes and the other cloud compute vendors, the last thing they ever want is a data leak out of their ecosystem. So the security aspects are now becoming more and more important. It's going to be an insider threat. It's someone that already has access to it and has the rights to it. That's going to be the risk. And there is no pattern for a data scientist. There's no zero trust model for data. So we have to create that. How are you, last question, how are you going to be using 100 million raised in series E funding, which you mentioned? How are you going to be leveraging that investment to turn the volume up on data security? Well, and we still have also another 80 million still in the bank from our last race. So 180 million now and potentially more soon. We'll kind of throw that out there. But the first thing is M&A. I believe in a recessing market, we're going to see these platforms consolidate. Larger customer vars are driving us to say, hey, we need less tools. We need to make this easier so we can go faster. They're even in a recessing market, these customers are not going to go slower. They're moving to the cloud as fast as possible, but it needs to be easier, right? It's going back to the mid 90s kind of Lego blocks, right? Like the IBM, the SAP, the Informatica, right? So that's number one. Number two is investing globally. Customer success, engineering, support, 24 by seven support globally. Global infrastructure on cloud, moving to true SaaS everywhere in the world. That's where we're going. So sales, engineering and customer success globally. And the third is doubling down on R&D. That monitor capability, we're going to be building software around, how do we monitor and understand risk of users? Third parties, so how do you handle data contracts? How do you handle data use agreements? So those are three areas we're focused on. How are you scaling go to market at this point?  Yeah, well, I think as we're leveraging these types of engagements, so like our partners are the big cloud compute vendors, right, those data clouds. We're injecting as much as we can into them and helping them get more workloads onto their infrastructure because it benefits us. And then obviously we're working with GSIs and then RSI's to kind of help with this transformation, but we're all in. We're actually deprecating support of legacy connectors and we're all in on cloud compute. How did the pivot to all in on security, how did it affect your product portfolio? I mean, is that more positioning or was there other product extensions that where you had a test product market fit? Yeah, this comes out of customer drive. So we've been holding customer advisory boards across Europe, Asia, and US. And what we just saw was a pattern of some of these largest banks and pharmaceutical companies and insurance companies in the world was, hey, we need to understand who is actually on our data. We have a better understanding of our data now, but we don't actually understand why they're using our data. Why are they running these types of queries? Is this machine logic that we're running on this now? We invested all this money in AI. What's the risk? They just don't know. And so yeah, it's going to change our product portfolio. We modularized our platform to the street components over the past year, specifically now, so we can start building custom applications on top of it for specific users like the CISO, like the legal department, and like third-party regulators to come in as well as going back to data sharing to build data use agreements between one or many entities, right? So when SMP Global can expose their data to third parties and have one consistent digital contract, no more long memo that you have to read the contract, like a muta can automate those data contracts between one or many entities. And make it a checkbox item. It's just a checkbox, but then you can audit it all, right? Yeah, yeah. The key thing is this, I always tell people there's negligence and gross negligence. Negligence, you can go back and fix something, gross negligence, you don't have anything to put into controls. Regulators want you to be at least negligent.  Matthew, it sounds like great stuff that's going on at a mutated. Lots of money in the bank, and it sounds like a very clear and strategic vision and direction. We thank you so much for joining us on theCUBE this morning. Thank you so much. For our guests on Dave Vellante, I'm Lisa Martin. You're watching theCUBE's coverage of day two, Snowflake Summit 22, coming out alive from the show floor in Las Vegas. You right back with our next guest.


Good morning everyone and welcome to your first session of DrupalCon Baltimore. I'm Josh Mulliken, this is Toby Hagler. We'll be talking about building a platform for MBA.com on Drupal8. The theme of the latest incarnation of MBA.com was and continues to be nothing between the fan and the game. And you'll see that theme repeated throughout the presentation. So for this morning session we're going to talk about four key areas that really help us meet this goal. First of all it's important to know that MBA.com is more than just a desktop website. It's more than tablet and mobile. It needs to help support other devices. PlayStation, Roku, Apple TV, Smart TVs. It's all about providing a very consistent digital experience for the fan. And content is keying on MBA.com. We have to integrate live scoring data, editorial content, live video, edited down video clips. And of course the video is very, very crucial. It's everywhere on the site. Yeah, video and content. It needs to be something that editors can be able to bring all of these things in a very fast pace and efficient way. The editors have to be able to knock down the wall between the fan and the game and get the content to them as quickly as possible. And serving something like basketball the site has to be fast. From editorial performance to front-end performance and server-side Drupal performance everything has to get there as quickly as possible. So there's a lot of different pieces that make up MBA.com. There's live scores, there's game and team data, there's editorial content, there's video. And those are crucial things to the website. There are some services that are just going to handle these things better than Drupal can like live scoring, video processing. Plus that's just kind of where it lives. That's where some of this stuff originates. A lot of this stuff gets reused and syndicated through other Turner systems. So it's important that those things continue to live where they've always lived because that's where other systems are going to need it besides Drupal. But the nice thing is Drupal 8 specifically plays really, really nicely as a multi-tiered content stack. It works really well in the content ecosystem. It doesn't necessarily mean that everything has to be managed in Drupal. It can play well with others. It's a good team player. It was one of the themes of Drupal 8 was that getting off of the Drupal Island when we try to integrate with Symphony, trying to incorporate over the things. And so that's just one of the things that Drupal 8 does really well. So we try to let Drupal play to its strengths. So all this is designed to seamlessly bring the game closer to the fan, regardless of where the content originates or lives, which we're going to show through the rest of this presentation. So one of the initial thoughts was, we're going to do decoupled or headless Drupal. We knew we were going to have to rely heavily on Drupal themed components though. So it made sense to let Drupal take at least some of the theme work, just as much of the site as it knew about anyway. In most cases, Drupal is going to be responsible for rendering about 60 or 70% of any given page on the site. And so you see in the slide, it's kind of color coded to where maybe some of content is going to originate from. So the render stack basically looks like this. Drupal renders the content on the page that it knows about. It renders this in origin. Then the page travels through the CDN. The CDN is going to be responsible for merging. Edge site includes fragments on the edge and hand that on in a very efficient manner. And then live content, other external content, other external data is going to be assembled into the page using Angular 2 apps. Also, you want to keep in mind the fact that PHP is essentially single threaded. So the use of ESI and Angular 2 to help let us assemble these things, let's just do so in a very effective manner. We're able to use multi-threading essentially, since PHP is responsible maybe for building some of these other fragments at different times, we're able to offload a lot of that out of the initial thread. All right, and we started developing Drupal.com, MBA.com on Drupal 8 in late 2015, early 2016, and none of the technologies we wanted to use were actually done. So the theme of this slide is pretty much nothing between us and abject failure, because Drupal wasn't even in alpha yet when we got started. PHP 7 was not quite out of the gate. Angular 2 was in alpha and had some big breaking changes after that. AWS wasn't playing great with Docker yet at the time, and the modules for Redis and some other things weren't ready for Drupal yet either at the time. So it was very interesting world developing while all of the technologies we were building on were also being developed. So with all of these technologies, now that we've got these in place, we've kind of worked through the kinks of getting these things to work together, that let us focus on the editorial experience and content management aspects of building MBA.com, so that way we were able to bring a finally curated game experience to the fan. So it's important to note that we didn't want to limit ourselves to just the traditional page, there are quotes. So much of what's on MBA is fluid in that what Drupal renders initially but the final pages that fans receive are not going to be the same thing. There's going to be continuing enhancements to that page along the stack for rendering that content. The site's not made up of a traditional set of node pages and views and terms. Literally anything should be able to be placed anywhere that makes sense on the site given the context of what the fan is looking at that given time, regardless of where it comes from. And that really is in keeping with the theme that nothing should be standing between the fan and getting to the content no matter where it comes from. So to do this, one of the tools that was in our arsenal is we've made heavy use of the paragraphs module. In a lot of ways this frees up the editors from having to think about things like templates and layout and being constrained to those very limiting concepts in a lot of ways and gives them a lot of power to add whatever piece of content makes sense at the time. So paragraphs leads to componentized content. These components then let us render pieces of content either directly into the page or to reuse later as ESI fragments. So now each piece of content can be rendered at the appropriate point in the page assembly whether it's Drupal rendering the page or ESI tacking that on later, pulling things in with JavaScript fragments. So there's very much this modular layout concept that you can mix and match content at will based on how content relates to each other. So the next big concept that we had to come up with for NBA.com was our content collections. Our editors work very, very fast to keep up with the games and they can't meticulously go through and curate every collection of content they want but they don't want to lose the power to do so. So we developed the content collections which kind of combines the functionality of a node queue and views. The editors are able to select a number of or in number of content items they want pinned to the top of a collection which is kind of the node queue type part and then the views type functionality they're then able below that to say and I also want to load anything that's tagged with these four taxonomy terms but maybe there's a sponsored section of content they don't want to include and they can actually exclude other content or other taxonomy terms as well so they're able to get really fine-grained control but still have the content show up as it's published and not have to be manually hand-holding a node queue. And then video of course is very important and this is one of those places where we had to have Drupal be a good neighbor to other systems. Turner Broadcasting is at its core a broadcast company. We handle video, we handle lots of it, we have existing systems that handle video so our challenge here was to make sure that Drupal can hold on to some of the metadata about video and make the Drupal ecosystem aware that a video exists but play nice with that being handled with our outside encoding systems and storage on our high availability CDNs because honestly the scale of video that we're serving out Drupal would fall over if it had to handle all of it. Let's leave pass integration. I forgot what we were going to say about that. So there are several types of videos that come into plays. There's a lot of video clips. Man, did you see that foul last night? That was terrible. That kind of thing, that's the thing that fans want to see all the way to watching live games. This was actually last night's game. In Mosaic View when you can watch the game, you can keep the camera on the leader for each player, for each team and get even the goal shot. You can watch video in a lot of different ways all the way to League Pass which is a pay service that NPA provides. I think there's some television cable entitlements involved and so all of that integrates to let the fan truly get immersed in video and keeping with having nothing between the fan and the game. So in order to bring all of this content to the fan, one of the most important things is the editorial experience. So basketball games are fast moving and the face of the game can change in a split second. So just as live games can change momentum, the editorial staff has to kind of keep pace just as fast, right? And so really nothing should stand between the editors and bringing the game to the fans. So to that point, we dedicated a pretty serious chunk of fan power to the editorial experience itself, not just to the fan-facing's website, but to the editorial experience. So we even had developers sitting in a control room during launch where as these games are going on and as things are occurring, we're able to react to things in real time to help make improvements on the fly. So in many ways, the editorial UX was just as key to the project as the website itself. So editorial experience, it's so important that we're still making continuous improvements just as we keep adding more features to the website. So one of the key things that we use for the editorial experience, of course, is the use of paragraphs for layout. So paragraphs, I don't know how many people are actually familiar with the paragraphs module and use it for a lot of content layout, but it's pretty powerful. So it's essentially, you think of it as a container of field of data that lets editors pick from a variety of content types that they can swap in and out on the page. So this is one of those things that, you know, you have a lot of field of data and lets you, based on the context of the page you're trying to build, you can arrange things on a one-off basis because editors really shouldn't care what an entity's type is, they just want it and they want to be able to drop it in quickly. So paragraphs lets you drop content in, you can nest paragraphs if you want, you can drag and move things around, but essentially it just lets editors have that content at their fingertips. We even used a lot of paragraph fields for configuration, so each individual block on the website, for instance, can have a lot of tweaks made for it, letting them, you know, rapidly adapt to the content's needs. A lot of people ask, you know, why no panels? Well, it's quite simply, it's just because it wasn't ready in early 2016 for what we wanted to do, but beyond that, the editorial staff wanted a very simple and minimal UI. They desired speed over power because that was just kind of the ultimate thing that the editorial staff needs. So, you know, in keeping with this fast pace, right, editors need media at their fingertips, and so we developed a couple of things that were really powerful tools, one of which was the content bin, which we'll see in a second, and the ability to embed media and syndicate content. So in this screenshot, what you see here is just a typical note edit page. We have a content bin, it's a drawer that slides in and out, just using a little bit of JavaScript. But what, in that content bin, it uses views to be able to search for different media entities and other pieces of content. So just using a little bit of custom theme magic, we're able to kind of show and hide the content bin on any note edit form, and then just using super simple drag and drop API HTML5 markup, we're able to make those media entities draggable out of the content bin and directly into the WYSIWYG. So there's no custom WYSIWYG plug-ins. There's nothing really all that fancy, it just kind of worked because of the drag and drop API. And then we make use of the embed module. The embed module and the embed entities module both will let you embed any sort of entity on the website, whether it's another node, a media file, or whatever. And it keeps those things as field of data so that even though you're embedding things directly into the WYSIWYG, it's completely parsable, it's not just dropping a bunch of markup in there. So you're able to, an editor is able to find what they want, drag it into the WYSIWYG and go. What's more is the content bin has another tab to let you search for content upstream. It doesn't necessarily have to live in Drupal. So one of the things we did was the same content bin can now allow an editor to search for content in an external media management system. Something that, you know, imports from, like, what, Getty images? Yeah, Getty is a really good example. Uh-huh. So, you know, a lot of upstream syndication systems that let you, you know, so you can search on keywords and a few other things. Um, so you get a paginated overlay that lets you choose which image or images to import. Uh, when you import these, they're made immediately available in Drupal. So when you, when you select this awesome dunk, you import it, it's going to be at the top of your content bin right away. Um, the nice thing is because of the system, uh, the editors never actually lose their place. So it's not like they're having to go anywhere else in another page and then have to come back and save changes. It's all happening right there in the interface. Uh, so these media items, they get pulled in as just regular media file entities, uh, directly in Drupal. So that way the next time you need it on another story, it's already in Drupal in the content bin. Alright, uh, so we also started, um, very early on with Angular 2, uh, game pages in particular need a lot of data from a lot of places. And it doesn't make sense to grab live game data that's stored in an external system, pipe it through Drupal on every page load, and push it out to the user that's gonna take us forever. Uh, so we went back and forth with a bunch of uh, front-end frameworks, uh, ended up settling on Angular 2, um, which we briefly regretted early on, um, until they got to uh, release candidate 6, which fixed all of the problems that we had been talking with the Angular team about. Um, mostly that it was early on. Uh, pretty much, uh, monolithic single page app focused. Um, but it just did a really good job of being able to pull content from our structured data systems for live data, being able to get updated content from Drupal, um, being able to go out to our other media systems to grab video content. Uh, it just worked really well for us. And the Redux model of data storage, I mean, I both need to talk a little bit on this one. Um, so, so one of the, one of the things that you run into any time you're dealing with live data, especially, you know, client-side assembly, fetching live data can be very taxing. So until a score changes, there's no need to keep requesting data over and over again, just because a user's clicked through to another game, right? So the, the data that you, you pull in, uh, using Angular, uh, gets put into a local data store. This data store is going to travel with you throughout the site. So Angular stores this data in local storage. It carries it across multiple pages. Uh, it also shares the same data with other Angular apps.  And so if you have multiple apps on the site, or even multiple apps on the same page, they're all sharing the same bit of data. So there's no need to go and fetch it out. Uh, also when one app says, hey, the score's changed, let me update the score, then it's immediately available to any other Angular app on the page. Uh, so that's just, you know, one more way that this kind of keeps the fan closer to the live game experience and allows them to seamlessly track games. So I think we've, uh, mostly come around here, but here's just an example of where, uh, the Redux model comes into play. Uh, if you look at the, uh, left-hand side of that screenshot, this is a game page playing a live game, and when the user came into this page, the schedule was able to render very quickly on this new page load, because all the data to build it was already in the local data store. We didn't have to make any additional, uh, API or data calls, uh, because the page already had the information it needed. And that also means that when you have that, uh, brief flash of out-of-date data on a new rendering, that it's a couple seconds old, instead of however old the cached version of your page on the server is. Okay, so this actually gets into the part, well, I'll be speaking a little bit more. Um, early on, we started on this before Drupal started the whole API-first initiative, and early Drupal 8 didn't have a whole lot available, uh, when it came to powerful APIs, so and we also decided we didn't want SQL queries getting between the fan and the game, um, in generating our content. So we have set it up so that we actually de-normalize all of our data as it's updated and push it into an elastic search instance, which is the backing store for our content API. This allows us to build as many different microservices as we want in need for various types of APIs. Uh, we have a standard JSON output content API that we built and actually have already created our version API, a version 2 API which sits alongside it. And this has also allowed other teams uh, within our development group to spin up a Facebook instant articles service in Node.js, a an Apple news uh, service, and, uh, service all without bloating our Drupal code base. And all of these things can depend on the de-normalized data structure in elastic search and get very fast results. And because Drupal is updating the data in elastic search every time there's a change, it stays up to date. Alright, and then the cloud. We actually, this was our first foray into hosting anything in AWS and our first foray into Docker. Um, and previously within Turner we were very siloed and we had a database group. We have server ops. We have, um, other operations teams. We've got a few people that used to be siloed for that but we've moved more towards a DevOps uh, infrastructure and workflow and going into Docker and AWS has really allowed us to become the masterverse of our own destiny and respond quickly and really tune the infrastructure of the site and be able to develop both the infrastructure and the code to work with each other. And so uh, Docker, it allows us to run the same Drupal infrastructure with the same version of Linux, the same version of PHP, the same version of Nginx, everything on the local development stack as we're running in production. We don't have to worry about a developer's NPM version being older or newer than the one we have in prod and it really allows us to miss some of the or not even have to think about some of those version mismatches you get when you're doing local development in a more traditional sense. Uh, also allows us to control our compute density and spin up or down as many or a few containers as we need to serve the traffic that we're getting. Docker also makes continuous integration very easy and we use Docker Compose to build our local environments, which is helpful. Um, we don't have too much time to go into the intricacies of serving Drupal on AWS. Uh, probably deserves its own complete session, which was actually little, um, saddened that none of any, uh, Drupal and AWS sessions this year, but if any maybe next year, but if anybody is interested in sharing thoughts, you can come up to us afterwards, um, and if there's enough interest, maybe we can, uh, get together and put a, put together a bot. Alright, and another thing, everything about this has been making things fast. We want to serve our content fast, and we want users getting to the game fast. So, so yeah, oftentimes, uh, that, that means you have to develop fast, too.  So just as kind of a, a bonus slide, we wanted to talk, you know, uh, really quickly about, uh, uh, our get branching strategies, uh, that we used to, to help us do a lot of things, not lose track of what we are, uh, not introduce a lot of things into, into production that we don't want. So, because of the fast pace of development and the need to keep our mainline branches pure and, and as free as, of untested or unapproved changes as possible, uh, we used what we, we dubbed, uh, continue flow. Uh, it's kind of a derivation of wonder flow as our get branching strategies, and so if you're familiar with things like, uh, like get flow, for instance, we threw that out, uh, because that just wasn't going to cut it out. Uh, we have a, a very widely distributed team, um, and, and things, you know, move very quickly, um, and, and so things like, uh, tent pull events, you know, like the all star game, for instance, uh, it's a very good use case, uh, because you have development going on, you know, one developer may be doing a couple of bug fixes here and there, and some feature enhancements, uh, but it, all the while also working on some parallel work in a, in a separate ethic branch, essentially, uh, that may last and so the ability to get things out in integration testing without interfering with the rest of development is, is, is really critical. So the, the analogy we would try to use, uh, very frequently is that if you have an integration mainline branch, uh, a staging or a QA mainline branch, and a production mainline branch, these things never, never intersect. They're, they're running in parallel. And as a developer works on a particular feature, uh, they, they pull it in for master, they do a whole lot of work, they make things better, uh, and they, they'll merge that into integration, uh, first, so that that's up on the integration server, uh, you're able to test it, someone says, ooh, no, no, no, look, look, that creates a regression with this other feature here.  Let's, let's face it. Uh, so that's okay, you can let that go in the integration environment, because that's a, that's a transient mainline branch anyway. Uh, but once you get it working in integration, and you're happy with it, then you move it on to you merge the same feature branch back into, uh, the QA branch. The QA branch then is what the QA team is actually doing all of their testing with. There's a combination of automated and manual testing that occurs there, and everything that's there is assumed to be ready for production. Once QA is signed off on it, then that feature branch is merged a third and final time into, uh, the master branch, into the production branch. Uh, at that point then it's ready for production, and you can absolutely trust that anything that's in master, uh, doesn't need to be re-evaluated for any kind of further QA, it's ready to go. Now the key thing to this is that you never merge a mainline branch into your feature branch or the master, right? You get flow, often times the process is you know, you create a branch from develop, you make some changes, you try to merge it back in through a pull request and you get a merge conflict, a big yellow exclamation point that just ruins your day, and so a lot of times the fix is real simple, right?  Well the problem is you've now introduced a whole lot of unknown changes to your feature branch, couldn't go into QA or stage. So we worked out a lot of other ways to resolve merge conflicts that keeps things very unidirectional. Alright, um, and I don't know if there's a lot of other performance geeks in the room, um, I personally, uh, stay up uh, awake at night, uh, thinking about not only milliseconds but nanoseconds. Um, so some things that we discovered to help make Drupal 8 faster, number one, run PHP 7, and make sure you turn opcache on. Uh, opcache, um, even though the underlying uh, performance of PHP 7 is greatly improved, and there's some opcache-like things built into the core of PHP 7, in practice, opcache still about doubles the performance of PHP 7. Uh, another, another key thing is get cache, get temporary and transient data out of SQL. If it's not content, if it's not config, you don't want it in there. Um, there's no need to have, um, you know, anonymous page requests, you know, essentially writing to the database. Uh, so, so get that out of, out of SQL as much as possible. Yeah. Uh, also you want to write size your caching. Uh, my best example of this is if you've gotten a block that lists related content, and you've got maybe five different uh, derivatives of that block for five different main content sections, and you've got about a hundred pieces of content in each of those. Uh, if you just, um, use the defaults and let your cache context be the URL, you're gonna be rendering and caching five hundred separate copies of something that you only really have five different um, varieties of. So it's very important that, uh, as you're getting into tuning your performance, learn how to create your own cache context, learn how to create your own cache keys, and when your cache keys should be cleared as the related content changes, and you're gonna save yourself, uh, a lot of time in the page rendering. Yeah, speaking of page rendering, uh, just in time or, uh, you know, assembling content where it's appropriate is really crucial, too. So, you know, let Drupal render the things that it knows about. Don't let Drupal spend a whole lot of time worrying about things that live outside of Drupal. Uh, you can use, uh, you can use Akamai or Varnish or any number of CDNs that support Edge Side Includes to pull things in for you that assemble on the edge. It's gonna be much faster than letting Drupal go and fetch those things and try to merge it into the page. Uh, it also eliminates a lot of cache issues, um, when you use Edge Side Includes because you can serve a cached page from Drupal, and then conditionally add content based on user preferences, geolocation, uh, and that sort of thing, uh, to a cached page, so Drupal's just serving the cached page, ESI adds things conditionally, um, you know, and then delivers that to the user, which then of course, you know, Angular and other JavaScript, uh, Magic will, will finish the page for you. It adds the polish. Um, horizontal database scaling is also something that we've put a lot of work into. Uh, that in and of itself isn't necessarily a performance booster. You can also scale vertically, uh, but especially if you're moving into the cloud, vertically scaling your databases gets very, very expensive. Uh, before we started working on horizontal database scaling, um, I think about 75% of what we were spending in AWS was just on a really, really big uh, Aurora DB instance. Uh, and so unfortunately, horizontal database scaling is easier said than done in Drupal 8. Um, we had to do a lot of work, as Toby mentioned earlier, to get the all the transient data out of SQL so that our web containers, which we'll talk about the splitting of containers in a minute, but so that, uh, public traffic isn't trying to write to the database, which allows us to take those containers that are serving to the public and just point them to a read-only database and, uh, Amazon's Aurora DB, uh, gives us a, an endpoint that will automatically scale across read replicas uh, which makes things very nice there. Um, I guess I'll go ahead and talk about the roll separation as well. Um, we, we also wanted to fire, kind of firewall the different tasks that Drupal does, so that if the editors are doing something really heavy, we got a couple dozen editors in there, fast and furious, adding new content, adding new videos, that they're not taking up all of our compute space from the fans that are trying to get to the new content for the game. Um, and I don't know if you've ever dealt with um, Drupal cron tasks in Drupal. Drupal cron can get really heavy, so we actually separated out a third role of a utility container that will run all of the Drupal cron tasks that, that's where we will put out API endpoints for other internal systems to push content into Drupal, uh, and anything automated and back indie that doesn't actually interact with users. We put on that separate thing so that we're not bogging, again, not bogging down the compute that is serving the fan with automated tasks that they don't care about. You know, earlier when we were talking about getting cache and other data out of the database, um, trying to horizontally scale, one of the things that really helped was we actually even moved PHP sessions out of the database uh, into Redis. Um, and that was, that was uh, that was a particularly interesting lift and we learned a lot about service decoration. Um, that, that probably alone deserves another session. But um, uh, yeah, so, so, once we were able to move PHP sessions out of the database because even anonymous users still can potentially trigger a session that gets written to the database, that was sort of the last key piece to be able to put the database into read-only mode. So, most of what you see on NBA.com is actually getting served from a, a read-only uh, database. Um, another interesting point is the, uh, the Redis Sessions module that we did uh, could potentially let you extend to using other PHP um, session, uh, session handling systems, uh, using a lot of the built-in symphony, uh, native session handler, uh, plug-in. So you could use, uh, the stock PHP session management again. You can use file systems, you can use uh, MongoDB, you can use Memcache, uh, all of these things based on, uh, service decorations and, and using the Redis Sessions module as sort of a template. I've actually been talking to uh, Sasha Burdeer, um, as most people are gonna know him, uh, who maintains the Redis module about, uh, helping with uh, maintaining the Redis module, um, as a result of some of this work that we've been doing, um, and contributing back the Redis Sessions module as a drop-in replacement for, uh, session handling in Drupal. Um, the other nice thing is, is it does keep all of the optimizations that Drupal has made over the last couple of major versions, uh, including session migration, uh, session deletion, uh, preventing anonymous users from creating sessions that get saved and so on. So that sort of thing is, is, is something that it is quite literally just a drop-in. You enable it immediately, uh, using, um, sessions, uh, out of Redis. Alright, and here we've got a, a nice little graph of some, uh, performance changes that have happened over time on site. Um, ignore the big green blob at the beginning. That was, um, kind of happening as we were importing all of our data from our legacy CMS, blowing it all away, importing again, um, but the first really interesting thing is after the big green blob falls off, um, and we go up that one little spike and then back down. There were a few performance, uh, some, there were some bad performing code that got put out and then fixed. Um, and then you see that third little spike there, uh, that's actually when we went live and went from an average of 50 to 100 requests a minute from all of our QA testing up to, uh, depending on the time of day anywhere between two and 6,000 requests per second that make it through to our origin, um, after all of our, um, Akamai offload. Um, so we were actually very surprised that we got just about a 25% uh, bump in our response time there. Uh, things kind of go along. We weren't very happy with our performance there. We made a few tweaks, uh, and we actually upside that first fall off, we upsized our database and started spending way too much money on Aurora DB. Um, and then go along and that first drop before the end of daylight savings time, we turned on OpCache, thanks to, uh, James over there, and also made our first set of pulling, uh, things that Drupal doesn't, uh, easily and automatically move out of the database when you turn on a Redis module or a Memcache module. Um, and that got us down to about 250 milliseconds and uh, through various code releases that maybe released something that wasn't very well optimized and re-optimizing. Uh, we've hovered around 250 milliseconds uh, since then. Um, but we've got another round of improvements coming soon uh, for the just a few more tweaks that should hopefully be pulling us down to, um, consistently staying right about 150 milliseconds and 50 milliseconds on a response, which makes me very happy. Um, so as Toby mentioned, um, we wanted to get our cache out of SQL and, uh, we learned that SQL is not the best place to store a cache. Um, and about halfway through our optimizations, uh, we're looking at New Relic, if you don't have it, get it or another high performance, uh, uh, profiling application and service. It will save your life, uh, because you don't know what to fix unless you know what's happening in production. There's gonna be problems in production that will never occur on your other environments just because of the scale of traffic you're getting and it really changes the landscape. But about halfway through optimizations, uh, we saw that most time we were spending talking to SQL was that the dependency injection container queries were taking more time than looking up nodes, uh, running views, loading the home page, anything, um, and thanks to uh, document we found on, uh, platform.sh's website, so thanks to you guys if there's any of you in the room, uh, we were able to uh, take the dependency injection container and move it uh, into the chained fast backend, which means about 99.9 and several more 9% of the time it's being served from local memory, and so there's no network requests that have to be made and it gets that dependency injection container very fast. And then it will also use Redis now for consistency of that container. If it doesn't have it, it'll go grab it from Redis and put it back into uh, local memory. Um, not gonna really go into this in detail, we just really included uh, a sample configuration for Redis in here, so that if anybody wants to see how to set it up, you can go download the slides, uh, probably tomorrow, um, and have something to get started with for getting all of those uh, caching pieces and transient data out of SQL into something that uh, works a little bit better for that. Yeah, we also promise we're gonna try to blog more about this kind of stuff. Yes. Alright, uh, so does anybody have any questions? Uh, if there's a microphone right here in the middle of the auditorium in the room, that'll help with uh, getting those questions recorded for austerity. So when a bug comes out or a new feature happens, um, obviously sometimes you might need to clear the cache and with so many different layers of caching, what is your, I guess, cache clearing strategy when you have that many hits all the time? Um, so our strategy is we clear cache as little as possible and try to only clear the cache that needs clearing. Uh, that can present some challenges. Um, if you are needing to clear some of your code caches or your CSS or your JavaScript cache, uh, one thing we do is uh, each build we take a hash of all of our code and pop it into a uh, setting in the database so that we can check it and we, during our post deploy, we will uh, compare the previous hash and the current hash to see if any code has changed. If the code has changed, we clear all the code caches. Uh, we also make sure anytime we update the PHP in a module or update any CSS or JavaScript that's included by a library, that we update the versions of either the module or the libraries, and Drupal will automatically handle clearing those caches for us. It'll put um, it'll, if you're serving the files individually, it'll put a little version decorator that will, um, cache bust, uh, or it'll all again clear the container injection and module as cache. Uh, if you're, and other caches, it's kind of knowing your site using, uh, Drush or, uh, Drupal console to clear caches, just learning which caches need to be cleared when. Uh, and as you get a better picture of that, automate as much of it as you can so that when something needs to be cleared on a build, you clear that cache on that build. Thanks. Hi guys, thanks for a great session. Um, we had a, recently a project where we were a lot of developers, a lot of continuation, continuous deployment. How did you handle configuration management? Because we've been seeing a lot of issues where people didn't get updated configuration or overwrote stuff. Um, we use the, the features module which, um, is much more like, uh, configuration management in Drupal 8, uh, than it is any previous, uh, iteration of features. Uh, but that really helps us split the configuration management out into the modules that that configuration is appropriate to. Uh, now there is, at least in the version we have, I don't know if it's been, uh, fixed since then, I haven't checked on if there's any updates lately. You do run a little bit of a risk of getting, um, duplicate configuration between modules, so you gotta keep an eye out for that and make sure that you're not, uh, creating a the same YAML file in multiple places because it gets confused. Um, but that's really helped us keep that separate and reduce the collisions. Yeah, one, one, one thing that we've, we've also talked about, uh, uh, there's a, there's sort of an emerging best practice with using features in configuration management is that for, for the course of development, uh, it's best to store all of your information for a particular feature in an exported features module, uh, and that's, that's the same exact, um, you know, CMI, uh, YAML files. It just, it keeps it there. But when you're getting ready to go from making the leap from your staging environment where you've queued everything and you're happy with, with everything, do a single pickup of the entire CMI and drop that into, uh, production. And, and that's something that could be easily automated as well. So that's, you know, one for here and it's kind of an emerging best practice on a lot of other, uh, features, you know, there's a, there's a blog post about, you know, using features and CMI and how they kind of work together. And so you, you can do the, the fine tuning of configuration management using features and then when you're happy with the entire site and it's just a matter of picking up that and, and, and dropping it into production. Thanks. Great. Hey guys, thanks for all the good information. Setting metrics for your speed testing. So a couple of years ago there was a study about Walmart and when they optimized speed on their site, they found that dropping the speed, I want to say it's two seconds, it might have been two milliseconds, it had a, a result of increased sales and increased cart, uh, by just a ridiculous amount. So I was wondering if you guys had any metrics that you were looking at, bounce rate or a user, uh, engagement or sales or anything like that. Um, we, we do, I don't, uh, have all of that, uh, data ready in my head right now, but, uh, we definitely looked at how it affects, um, the end user and been, um, more so than even that though, we just focus on what our worst behaviors are and, uh, try to improve those. Okay, thanks. Hey guys, thanks a lot. Uh, I'm curious a little, to hear a little bit more about your kind of ESI strategy, uh, and maybe, I have a couple questions, maybe what kind of cash off load from origin you've been able to achieve, uh, and if there have been any concerns about maybe the ways you've used ESI, uh, leading to like vendor lock in, having to use a certain CDN. Um, let's see, I'll actually address the vendor lock in, uh, piece first. Um, changing vendors is always painful. Um, once you've chosen a vendor, if you're going to take advantage of the reasons you chose that vendor, then you're gonna get vendor lock in. Um, and being a, you don't want to do fear-driven development. That's a mistake that our group has made a lot in the past and we've suffered severe limitations because we were afraid to take advantage of the technology we had at our fingertips, because what if we wanted to change? Um, so that's my take on that. Um, and as far as the, uh, ESI were, um, we've since, it's very similar to the way that you would do something if you want an Angular app in your page. You, you take a block or whatever other piece of content, uh, you create a, an endpoint or a route in Drupal that will serve the HTML that you want to go in that place, and then when you're rendering a page, your template for that thing is just the code for the ESI include that Akamai or Varnish or whatever service would come back to Drupal and get. Uh, one, one, one way to, to think about it is if you were to take a block, uh, add a bunch of fields to it for configuration, you know, some sort of like set of settings for that block, uh, then place the block on the page, um, you could, you could designate for every country code, for instance, uh, use this separate fragment. And so we do a lot of geocoding because NBA is, is, is worldwide and so we want to be able to show different content to different countries, uh, based on where you're at. So if you're in Canada, for instance, uh, you might get, um, a, a block at the top of the page that's dedicated to content about, you know, Canadian players or, or something that might be of more interest. Um, so you can use blocks to use sort of the, like, you can manage which fragments you're gonna get displayed, uh, all in the UI. So you don't have to do a whole lot of, you know, code tweaks later.  Uh, and then, uh, you know, you can just manipulate that in, in that block configuration. Uh, and then the template for that block is essentially just pulling together the ESI, uh, include the, the, the, the, that include, you know, with the appropriate fragment from your configuration. Uh, and it's all conditional based on, uh, the geo-targeting, uh, ESI code. Thanks, guys. Thanks for the talk. Uh, I have two questions. First one, I'm curious, um, what made you choose uh, Angular 2 over the other frontend frameworks? Um, I mean, in the end we, we did a lot of comparison. Uh, we were kind of hanging uh, right on balance between Angular and React. And we were coming up on the deadline where we had to choose and had to start uh, developing and just kind of on gut went with Angular. Yeah. Uh, early on there was, there was sort of a, uh, there was sort of a, I don't know game is the right word, but it was basically find an Angular developer, make them write something in React, and find a React developer and make them write something in Angular 2. And depending on how well they were able to pick up the nuances of the new language that was going to help influence. And because Angular 2 was a little bit easier to pick up because it has some things from Angular but a lot of concepts from React uh, it was, it was one of those things that was kind of the push over the edge a little bit. I had actually forgotten we did the bake off. Yeah. Um, also it also helps to note that we actually did spend a little bit of time talking with some of the developers of Angular 2. Uh, and you'll find that Angular 4, which is out now, uh, has baked in a lot of the things that, that we ran into and they used that to kind of fine tune the development of Angular 4. We found out recently. Yeah. Thanks. And second one, do you guys use Preview? Um, so like Preview of, of Node content? Node content. Yeah, I'm just, um, curious if you had any issues, uh, working with Preview and microservices and frontend framework. Um, yeah, we, we had a number of issues with Preview. That was, uh, that was one of the things that we, we, we spent a lot of time early on, um, trying to get, you know, like, like the Preview of an article page, for instance. Uh, right, so editors are working fast plays. They don't want to save it yet. Um, so they will, uh, want to Preview that. So, we actually we had a lot of trouble getting Preview to work, um, with all of these other pieces. Um, there were just a lot of things that were interfering. We could probably revisit it now and, you know, resolve a lot of other issues. Uh, but one of the, one of the things to, to Preview is that we actually use a little bit of, like, work bench moderation to have editorial workflow. So, uh, an editor will make a change and it will actually save it as a draft and then they can just view the draft. Uh, so that way they're getting a much more live representation of that page. Um, and just another note on Preview from our journey, uh, not only on MBA.com but also uh, work we've done with Preview on the MBA team sites. Find out what level of Preview your editors need. Um, sometimes not even what they want but what they need. Because the more you have to Preview you almost end up with a hockey stick graph of effort. Um, when you start having to Preview the home page with all of the articles that are saved in a draft state uh, it can become quite a mess and a whole nother level of content management just to manage your Previews. So the simpler you can keep your Preview um, where it still meets your editor's needs is very important. Thanks a lot. So this is gonna be a kind of vague and broad question but what were some of the big aha moments you guys had while developing the site where the light bulb went off and the clouds parted and just something major happened for you. Yeah, um, one of the biggest ones that popped into my head is cache contexts. Um, there again, there's a few out of the box and they seem, they're the ones that you always need uh, but they're very broad and writing your own can make a giant difference uh, in not only the performance of your site but when your content becomes available because if they're too narrow stuff doesn't get updated. Uh, that's one of the biggest ones. Um, another one is listen to your editorial staff. Uh, let them dictate what their, because think of your editorial staff as a consumer of your product, right? So getting prototype code in front of, in the hands of an editor is going to let you fail early, you know, fail fast.  It's not, it's a little bit sluggish.  Um, in a previous life actually worked in a newsroom, you know, I was looking at journalism and I got into web development and then Drupal development, working with newspapers and other editorial staff. Editors think completely different than developers. And so working with them one on one getting their feedback is that was a really key moment. Uh, and that really changed the game for us in a lot of ways with how we built the admin interface. One quick follow-up question. What is one incident that would show up on the nba.com development blooper reel? Things were surprisingly smooth given the effort. Yeah. Um, I mean obviously, you know, OpCache was a, you know, some choice words I think were had when that was discovered. Um, I think another one, you know, along the lines of caching was storing user specific cache in between pages, instead of static cache for instance. You know, when you should be using static cache. I mean, it causes a lot of issues. If you have multiple administrators logged in as the same user suddenly you start getting a lot of cache collision because it's trying to share that in the database. So if you use, you know, Drupal static cache it can make you walk a lot easier. That was another thing we found as a performance issue. Thank you. Hello. Thanks for the great presentation. My question circles around, you talked about using local cache for some of the displays and I was wondering what was your strategy for updating these because you showed an example of the live event page. So I'm thinking like when this call changes this is supposed to change in real time. So what was your strategy for that? I'm talking about the strategy for updating live-scores. How were you updating the live-scores in the local cache? Were you pushing it out? Yeah, so in Angular 2 we developed services for each data source. And between the services and our Angular components they're aware of kind of how time sensitive that particular piece of data is. So something like the entire schedule for the season we're not going to be updating that every 10 seconds. We're not going to be looking at that feed on every page load. I think we may look at it every 10-15 minutes to pull a new copy in but things like live-scoring for the game that is live right now we go and check every few seconds and it's really just in how you configure your services. Another good strategy for doing live-scoring too is if you have a service that is capable of establishing a web socket then the browser can make a web socket connection and use that connection open between you and the service. It's a little bit trickier if you're bouncing between page and page but it's a really common strategy for live-scoring too where you keep a socket connection open and during times of no transmission then it's just open but nothing's happening so it's a very low bandwidth thing. And then when the service, the scoring service sees that a new score is updated it's able to say hey everybody who's listening broadcast out the new score and so my browser then gets that ping from the open web socket that the live score is updated in the page and then update that score in the local data store and then you can also use like a long pole effect so you can you know if say after 15 seconds I haven't received anything from that web socket communication let me go double check and make a new request and re-establish the web socket. So those are some of the features to live-scoring as well. Thanks. We're almost 5 minutes over time so I think and we've run out of lines so I think that's a good time to cut off the questions so thank you very much everybody. And if you're interested don't forget to check out Toby's other session at the opposite end of today on Dungeons and Dragons in Drupal. Yeah Yeah So you can get as you use MemoFan and so like by default in the name of the coffee you can use it to point to your server all of your big patches are stored there so Drupal you know like you know like you want to put that in the configuration and stuff.


What's up, Navigation Traders? Welcome to this week's video update. Today is Friday, April 26th. Hope everybody had a great week of trading. This is our weekly recap of all the trade alerts and positions exclusively for you, our pro members. Before we jump into the alerts, let's check out who got caught being hot this week in the community. This week goes to Jonathan Thomas. Jonathan's brand new to the community but has wasted no time in jumping in and getting involved with different trade ideas, helpful comments, great questions. So great stuff, Jonathan. Keep up the good work. You got caught being hot. And we sent you a private link to grab some Navigation Trade Hacker swag, so enjoy that. Keep up the good work. All right, let's jump into the alerts for the week starting with Monday the 22nd. We had a closing adjusting trade in ZW, which is wheat, and we just simply closed out the call vertical side as price moved down, passed the break even to the downside. We just closed out that untested side. And so if we take a look at our friend wheat, it's a bit and just kind of bounced it around the last few weeks here. And we've got two pieces on here. Here's a full iron condor that we ended up putting on here on a later alert this week. You can see it's still fairly centered. Give it more room to the downside than we did the upside. And the reason being is because we've got this piece on where we've got room to the upside is what we need. And so you can see prices still barely out of range, but if we can get a little bit of up movement, get back in there and hopefully book a profit on that one. Next trade was an opening trade in Walmart. So we did a pre-earnings long call in Walmart. And we did this, Walmart's got a little ways until expiration, let's see here. The date is 516 before market. So we want to be out of this by 515. Now, Walmart did have a little slap today to the downside. So we're actually, you know, we're just looking for a little bit of a push higher and we would have booked a nice profit on this. Unfortunately, we woke up and Walmart was down. And so that's not good for our position. So we're down a couple hundred bucks on that at this point. You know, if we really at this point now, if we can get back to break even, we'll probably exit or try to get a small profit out of the trade, but we are looking for this to really push higher, get some of that momentum going into earnings. Obviously that didn't happen, but hopefully we can still get out of this trade for a break even to small profit. Next trade was an opening trade in XBI. So we put on a long put vertical, which is a bearish play in XBI. And I just really like the setup that we saw here. So if we take a look at the chart, what you're gonna see is we had this big push down in XBI and then we've just kind of bounced higher. And it was on this day right here that we got short. And so we're just looking for, I like when you see these big push moves down and then a little bit of a bounce and look for that continuation to the downside. And same thing on the upside. If you get a big push up, you get a pullback and then the continuation to the upside. I just liked how that set up. So the other thing is XBI hasn't been as strong as the overall market. This is the biotech ETF. And so we've had a lot more two-sided action here. So I just wanted to add a little bit of short delta. We were at this point, we were below our five to one range on our short delta to theta ratio. So still within our range, which is why I didn't have a problem putting it on in addition to just liking the look of the set up for a continuation to the downside. And so we'll see what happens. Hopefully we get a little bit of a push down and we are able to book a profit on that. Now, speaking of short delta to theta ratio, we are currently at about three and a half to one after the last couple of days here. We've got some nice movement in oil and some of the other stocks moving down and videos down almost five and a half percent today. So at this point, that really benefited our account based on the amount of short delta that we had. And now it's pushed us back into an even more reasonable range. We're at about three and a half to one. So in good shape there. Next trade was a rolling adjusting trade in SMH. So we rolled one set of our short strangles from May to June. We had 23 days left, but with SMH just really climbing high, we had very little value left in those puts. So we wanted to roll those up and we're not gonna stay in May with just 23 days. So we rolled out to June with 58 and then we're still holding our other piece. So let's take a look at SMH. Nice relief from that rally today down almost 2%. So that's always helpful when you've got short delta. So here's the roll that we made. We rolled up our puts to the 115, kept our calls at 85. So we've got this inverted strangle. Now with just the move today, look how much we've gotten over $800 in profit back just today with this down move. So that's definitely benefiting that position. And then our other piece is still in May. And you can see we've got a, it's also inverted, but it's a little bit tighter. Oh, I'm sorry. No, it's not inverted yet. We've got the 108 call 104 put. So we did roll up our puts, but it has not gone inverted. And so just looking for a little bit more downside to get back into range here. Now our May position has 21 days to expiration. Didn't roll it today cause we did quite a few different trades. I like to spread those out across duration as well. And so we will be rolling this one early next week since we're now getting to the point where we're under 21 days to expiration. Next trade was an opening trade in Facebook. So we did a post earnings short put vertical and what we're looking for here is when a stock announces their earnings and the stock price opens well above the expected move, we look for a continuation kind of steady prices to grinding higher in the stock price. So Facebook, if we take a look at the chart first here, you can see it gapped up and then it came down and it's coming down again today. So the price has actually moved against us as far as our position goes, but we just need a little bit more continuation to the upside to benefit this trade to get back into range. So we'll see what happens there. Next trade was an opening adjusting trade in IWM. So implied volatility, the percentile popped above that 50 level. So we added an iron condor in IWM in the June cycle with 57 days left. And then we still have our full iron condor in May as well. So we've got two different iron condors in different expirations. Here's our May one price kind of hanging out near the upper end of the range. Could use a little bit of downside to get back to center there. And then if we take a look at that alert I just mentioned, which is the one that we added in June, you can see this is pretty well centered. So just waiting for some time to pass there. Next trade was a closing adjusting trade in ZN. That is the notes. So we had two positions on in ZN. We had a short strangle that hadn't been adjusted at all and we reached 45% of max profit on that. Nice move up in price today, giving us the chance to book that one. And then the other pieces, we had this adjusted strangle, which was actually a straddle. And so we booked over 20% of max profit on that piece and took that one off as well. So booked both of those back to back and we are out of ZN and we'll wait for implied volatility to pop back up. Now, when we took this off, implied volatility, the average percentile was at 41. I was looking at it a little bit later after I placed that trade and now it's down to 17. And so had we waited a little bit longer or if you didn't get the alert until a little bit later, you probably got at it even better prices than us, but that's just part of trading. So we're out of there, booked a nice profit overall and we'll wait for implied volatility to pop its head back up before we get back into any bonds or notes or TLT. Next trade was an opening trade in Intel. So Intel announced earnings last night or this morning. Anyway, before the market opened today and they had a big move down. I'm not sure what happened, they missed. I know there's some headlines going on with their integration with different Apple products and it looks like they're getting the blunt end of the deal, but if we take a look at a chart of Intel, you can see it's down 10% today. And so they announced earnings dropped like a rock and when that happens, a lot of times implied volatility won't get crushed as much and so implied volatility is staying bid. At the time we put this on IV percentile was at 52. So we sold a strangle. Now this is a lower price stock around $51. So we pushed our short strikes in a little bit tighter towards the price. So it's not as high of a probability of success, but we collected a really nice credit on this and with just a five point wide strike. So we're looking for price to settle down from implied volatility to start contracting, which it already has and hopefully we can book a quick profit on this one. Next trade was a rolling adjusting trade in CL, which is oil. So we have two sets of short strangles, both inverted, both in June. And we're at the point in these contracts where we're at 20 days to expiration today. And so we wanted to start rolling this. I was hoping for a little bit of down move and we got a big down move today, which was awesome before we did the roll. So we rolled this so that our strikes are at 56 and 61. So we've got the 56 call and the 61 put, and that's now out in July with 52 days to expiration. So let's take a look at that one first. You see, we've already got a little bit more down movement. We're already up another $400 since we did that roll this morning and just looking for some more downside to benefit that trade. And then this one, which is still in June, you can see it's a bit out of range, hoping for that one to get back into range here, regardless of what happens with price, we're gonna be rolling this one next week as well. Cause like I said, we've only got 20 days to expiration. And on these uncovered options, once we get under that 21 days, that gamma, that risk really starts to accelerate. So we like to roll out to the next expiration cycle, collect a credit and keep the dream alive. So that's where we're at on oil. And lastly, we did a closing adjusting trade in IYR. So the real estate ETF, we had two different iron condors on here, one in May, one in June, and the one in May got to a point of over 30% of max profit. So we went ahead and booked that one. If we take a look at IYR, you can see that's zeroed out cause that's the one that we closed. Let me reset this so I can get the appropriate boxes checked for you. And let's uncheck those. And so here's the one that we still have. This is our June iron condor, kind of a tight iron condor. And just waiting for some more time to pass, a little bit of a down movement in IYR would also be beneficial. And so those are all the alerts. Let's take a look at some of the other positions. I mentioned oil, ES, we've got a long put vertical. You can see it's just out of range, just looking for some downside to get back into range there. We're holding that for that short delta exposure. Natty gas finally making a nice move in our favor, up one and a half percent today. You can see these are both of our positions. You can see our puts are both at the three strikes. So that's why those are together. So we can, these are such similar positions so we can kind of view these together. But the bottom line is we need some upside to get back into range of nat gas. And we've got 32 days to expiration. So we've got some time before we need to start considering rolling there. In wheat, I already mentioned that one. In DIA, we've got an iron condor. You can see prices hanging out near the upper end of the range. Need a little bit of downside movement. Won't take too much to get back to profits on this piece. And so that's what we're looking for in DIA. EEM, we've got this short call vertical. It's come down since we did that roll and just waiting for some more downside to benefit that piece. I mentioned Facebook, I mentioned Intel, IWM. Did I mention this one? Yeah, we've got two iron condors here. One is centered and the other is, let me reset this. I don't know why TOS does this, but anytime you have a couple different positions in different expirations, it'll make you reset to check those boxes. But this one, the price is just hanging out in the upper end of the range. So need some down movement on that part. I mentioned IYR, NVIDIA, nice move today. We've got this short call vertical and got a nice move at prices actually way up here at a range and it's come all the way back in the last couple of days to a point where we've got a profit on this piece. Overall on the trade, we're still down a little bit. So just waiting for some more down movement or steady prices. If we take a look here, you can see just had a huge rally and then it's just kind of been bouncing around and we're getting some downside relief today from that rally, which is good. Two-sided action is our friend. QQQ, Q's have been really strong. I had a little bit of a blip of downside today, but not too much. We've got two sets of short call verticals which are both out of range. So looking for some downside to get back in. These are in May with 20 days to expiration. So we don't like to be in a negative theta position, which we are right now, very small, but yet it is negative. And so we might look to roll one of these out to June here in the next week or so, but we'll see what happens. If price makes a nice move down, we will just be back in range in a positive theta position. So we'll see what happens. SMH, nice move down today, 2% move down. So we've got two pieces on here, one of which is this inverted, I already went over this one, sorry. Little slow today. We need that piece to get back in range and then we already rolled the other one. SPX, we've got this calendar spread on. You can see prices hanging out right here. No profit or loss, need a little bit of downside, need a little bit of an expansion in implied volatility to benefit this trade. So hopefully we get that in the next week. SPY, we've got this short call vertical spread. Just looking for some more downside to benefit that. Wells Fargo, this is one that we put on after the earnings announcement. They had this big move down and implied volatility stayed high. Now price is starting to bounce back up and so we're just waiting for a little bit more time to pass. We've gotten the contraction and implied volatility that we want but just not quite enough profit. So if we get just a slight up move in the next week, we'll go ahead and book this one. I mentioned Walmart, XBI, looking for some downside in XBI. I mentioned that one. XLK, this is a technology ETF. We've been holding on to this one for that short delta. Unfortunately, technology's been strong but just looking for a little bit of downside to get back into range there. Again, this is one where we may consider rolling this out to June to get back into a positive theta position unless we get a quick move down here next week. XLV, healthcare. So I did a video on this. Healthcare stocks have been beaten up a little bit after the CEO of UnitedHealthcare came out with some statements during their earnings call. So we ended up trading the ETF, which is XLV, bounced really hard off that bottom. And so we actually could use it to settle down or actually go down a little bit to benefit our trade before we book a profit there. And lastly, XRT. Interestingly enough, XRT is up today whereas Walmart and Target and some of these big retailers are taking a pretty decent hit. So not sure what's going on there but retail is, as far as the ETF goes, it is up. We needed some downside movement to get out of this XRT position. Implied volatility is pretty low so we're not looking to add at this time but that's where we're at in XRT and that's where we're at in all of our positions. So hopefully we get a little bit more volatility next week, a little bit of downside but it would be great and let's keep this going. So everybody have a great weekend. Talk to you next week.