What's going on guys welcome to another video actually out here on the river today, and if you guys know what it's anything I'm not in my boat. I'm actually out here with my boy chants and Katie And we're out here run try to catch some overfish supposedly some fire right now There's a lot of tournaments going out today. So I mean, I don't know how I mean There's there's literally when we pull up to this first spot right here. There's like four boats It's a little later. I think it's like 10 o'clock right now, and we're gonna get out here We're gonna try to catch some fish and hopefully we can some mac them, but let's go ahead and get started It's gonna be the shot Fish number one guys literally one minute in pretty little guy look at the colors Nothing big, but they'll do Man, I was very amazed by how deep these fish were out here Yeah, I was dragging remember the day we were dragging them.  I can't believe that I was a really good fish Just came loose my real is having a little bit of problems, too And he just came off of me. So absolutely. He's definitely one of my top five top 10 He said he hangs out a few times. Hey, can I turn the boat off? I appreciate it. Just having a little trouble starting up trolling motor batteries dead, too I appreciate it. Thank you. Thank you guys Oh my god I ain't even a point fixing on I'm just All right guys. So long story short. I'm here at this little canal pond Long story short. I'm going to explain later on the video and I think you guys should watch it A lot of stuff went down the river. We didn't even get the fish really and the time that we did fish You know, we hooked a lot of fish surprisingly We were going to have an amazing day on the water But therefore that did not get to happen But there's this canal me and uh, katie actually hit this before we met chance With the boat for like five minutes and she actually caught a six pounder this morning Literally right before we hit on the river. I'll pop up the picture right here And we're hoping to catch some big ones. I actually had one swirl on my swim bait I caught one that was like two pounds. We only fished here for like five minutes and uh I had one that was probably about eight. I'm assuming like just come up on. I mean his mouth Like they're a big fish here. No one fish is here. So we're gonna let's see. Let's see what we can do I literally just saw like a six foot gator just hopping the water right there. I'm not even kidding We saw a turtle a minute ago, but literally a huge gator just crawled in the water I don't even know that is freaky I'm gonna look around now. That is weird You can see where it hopped in guys like mud.  I've been in that current There you go guys pretty little pound and a half pound and three quarter fish It's a thick one these fish are so thick over here staying that current super healthy and strong Well, I wasn't even recording All right guys, she's just lost like a giant first cast in here The bank is very high. So it's gonna it's gonna be very interesting if I end up hooking like a good one This place is weird Oh There's a catfish What? It's a catfish I'm scared. Oh, you got my line on nasty. It's like really what what I do, huh? There's no way that was a bass. It had to have teeth. Look at the freaking dust it made in the water It grabbed my bait off that and literally It broke the I mean it was running that was a it literally when I hooked it it felt like a brick I'm out. This place has given me the weirdest like feeling I've ever felt. Uh-oh What in the heck was that we thought this part was creepy That was like messed up creepy All right guys, we are getting out of here. I don't know if you can tell by my skin. Oh my god. I'm like a little lobster We're about done this. Yeah, you're pretty bad too This place.    Yeah, that was actually something walking out there. I don't know. Yeah, it was kind of a turtle or something but like The creepiest part is like we literally have not seen one Not one car passes. I don't know but I'm getting out of here I've had enough of this place This is a weird video. This is very Very weird video, huh? So let me deep breathe for a minute here very quick because but he's already kind of long So got on the river my boat's already in the shop as you guys know My boat's in the shop Chance wanted to go on the river. We wanted to go on the river. So me katie and chance we're gonna go on the river And his boat ended up having problems when we went out there his trolling motor battery is completely fried And his boat did not want to crank up. So we pretty much pulled up to our first spot And we're stuck through the whole day until we were able to find someone to help us out. Um I'm pretty much us all the whole day went Then once that happened me and katie went to this other pond chance had to go home But we went to this other pond and it is just it gives you the Weirdest vibe like I'm not just playing it. It's just it's an area that you just feel like I can't explain it. I've never really went and been to an area where you just feel like You're not supposed to be there. You're just not like something's watching. I can't explain it. It's just weird I know you guys probably like why Like but I would think someone else is weird too. They're saying something like this, but like Seriously, like when I was there, you just feel weird You just get this weird feeling and you don't see like any cars Even though it's like a main road with a bunch of houses And you saw you see like zero like when we were Like sitting there fishing you never saw any cars or heard any cars go by But like once you got in your car you started to see cars on the street That's what was just it just gave me the weirdest feeling in the world And there was like tons of species like a fish in that pond. So that was very weird But guys, unfortunately, we didn't get a killer river fishing video But I did get some footage for you guys. I thought you guys would enjoy So if you enjoyed it, be sure to smash that like button comment below and hit the sub Whoa hit the subscribe button and press the little bell guys That will send you post notifications about every upload I upload so you guys don't miss an episode But thank you guys so much for the support. I love you guys so much Thank you guys for all the comments likes and everything on my social media and all the kind messages you guys send me Thank you guys so much more videos coming soon about the heavy gunners bill this week And I got a lot of homework to catch up on but thank you guys so much for the support I'll catch you guys in the next video. Please like this video.  Don't be normal. We're gonna change the world guys Thank you guys so much for the support. I'll catch you guys in the next video


from the material design team. My name is Zachary Gibson, a senior designer. This is you and Chen, also a designer on the material design team. And Addie from Polymer. We're going to talk a little bit about adaptive UI with material design and what's happening with paper elements. So let's just jump right in. I am no mathematician, I'm a designer. But I can tell you that the trick to arithmetic is not simply to solve problems. Five times five will always be 25. The trick is to understand all of the various rules and systems and stuff that exists that allows us to solve any mathematical problem, so height, width, area. And the same thing is true when we design adaptive UI. We can design for any screen. We can make things for any screen. But the trick is to understand the systems and all of the patterns and all of the stuff that exists that allows us to design for everywhere. So in the next 30 minutes, Ewan and Addie and I are going to show you some of the stuff that were hard at work to define how material design works everywhere. I'll keep going. We have a couple little clicker fumbles here. Go ahead, Ewan. If you're unfamiliar, material design is a visual language created by Google that unifies classic principles of good design with innovation and possibility of today's technology. By sharing a conceptual metaphor, a visual style that's bold and graphic and volume motion design, it is a single underlying system that allows for a unified experience across platforms and different screen sizes. First launched at Google I.O. in 2014, which is a year and a half ago, material has received great press. We really like this quote from Armin. Material has the potential of being one of the most significant visual improvements to the web. Nearly a quarter million Android apps have gone material since we first launched, while Android is Google's vehicle for bringing material design to native apps on mobile. Polymer is Google's reference implementation for material design on the web, including things like components and layout and other components, things like the iron element set or the neon animation set. You guys have downloaded the paper element set. You've looked at it over 2 and 1 half million times. It's kind of crazy, right? And you're using paper elements in over 100,000 pages at the moment, and this number is going really fast. Now, we think that adaptive UI, material design, and Polymer are a really great fit, because when you're developing a web app, you want to make sure that it works really great across device. You want to be able to build something that looks like a native app on mobile, but when you go to desktop, it adapts and uses the best of your hardware abilities and all of your screen real estate. You also want it to look fantastic on tablet. Now, the Polymer material design teams have been working really closely to try making sure that the paper element set works great across device, and we've got tons of examples and demos that we're going to talk about in just a bit, showing you how you can apply adaptive UI principles to your Polymer apps. So what is adaptive design? We're all familiar with responsive design. Blocks reshuffling mostly based on media queries, but I think adaptive design takes this a little bit further. We are enabling containers to fit in the right form and are just appropriate to the right content. And adaptive design is based on context, like how a person is using a certain screen or device. It's based on content, just respecting why a user is looking at something when they're looking at it. Input methods, like varying from fingers to mouses to mice, is it mice or mouses? Mice. Mice, keyboard and voice, a lot of just various input methods. We also have user needs like accessibility and internationalization, and even device limitations like processor or bandwidth constraints. So obviously, that's a lot of stuff to take into consideration when we're trying to make a web app. And the web is pretty wild. It's not a controlled ecosystem, like designing something for Android. So it becomes difficult to just standardize UX patterns across form factors. But we're trying to tackle this issue, the material design team and Polymer. And I'm going to walk you through some of the stuff that we're trying to do. And I really think that it starts with naming. We need to be able to codify our UI's nomenclature. So to show you how we're doing this, I'm going to play a little game here. I'm going to describe a material design component. And we're going to see if Addy or UN knows which component I'm describing without showing it. So this is a temporary panel. It's on the left side of the screen. And it contains navigation. Paper drawer panel. I think he knew the answer at a time. This is the paper drawer panel. But here's what we did. We described the behavior. We described the structure. It's a panel. And we gave it certain descriptors. It's on the left. It contains navigation. So let's go again here. This is a toolbar. It's at the top of the screen. It's in front of all other content. So things might come behind it. And it contains actions and a title. It's the paper toolbar. Yeah. So this is like the paper toolbar or what we call the app bar in material design. So we did the same thing. Followed the same pattern. There's structure, behavior, and certain descriptors. We can define pretty complex UI following this pattern. So you have a group of surfaces. It's displayed in three vertical columns. The group is centered on stage. And each surface contains a summary of content that can expand. And other surfaces might reflow around this. So this is something like it might make G+, or Pinterest, or Google Keep. So you can see that by defining certain structures, like our material design components. You have a toolbar, a sheet, a panel. With various descriptors, it's on the left. It's on the right. It's in front of, behind, or above, below. With various behaviors, like something is persistent or temporary, we've created a matrix so we can just accurately talk about our UI. So you have a toolbar. It's at the top. And it's permanent. That's our app bar. You might have a sheet that's at the bottom. And it's temporary. We call this a bottom sheet. So with a consistent nomenclature to be able to describe the structure and what might be in that structure and how we should expect it to behave with certain behaviors, both verbally, just like how we talk about our UI and in code, we can accurately define how our UI should get built. So what is a grid? The main purpose of a grid is to set up limitations to layout. But with those limitations comes many great qualities, like style, familial placement of items and content, and a cohesive feeling across product. Let me walk you through some of the rules and patterns that our grid follows as we create a structure of material design interfaces. Our 12-column grid system allows for a wide variety of layout. Here you can see we're combining components like a toolbar, a list, and a card. The list takes out four column of the grid. We have one column of negative space, six column card, and another column of negative space. This next example is very similar, but that we have an extended header and a card that goes over the ad bar. And it follows the same grid. Now let's remove the list. Here we have a six column card. We can introduce something like a left panel, which you can see squids the grid to the right. Notice that we still have a six column card. The grid system isn't just limited to layout with cards. Here we have a left panel, a list, and a detail view. And it follows the same grid as we just mentioned. This last example, there's a left panel that overlays the grid. There's an extended ad bar and a persistent right panel. Notice that the left panel has no effect on the grid or the content. I'll talk more in detail about behaviors in just a moment. For now, the most important thing is the fertility of laying out various material design apps using the same grid system. We've also defined guidance for common margins and gutters. Here you can see we're using age, 16, 24, and 40 dips, margins, and gutters. If you are unfamiliar, a dip is a unit of measurement in which the numbers are dependent of the density of the screen. Dip, density, independent pixel. The most important thing here is that we're focusing on the margins and gutters to create consistency in our layout, rather than defining the column width. There are more grid patterns at our disposal. Here, the first example, the grid is full width and it squeezes content block as the screen size changes. In the second example, the grid is centered where blocks reflow. When a navigation is very important to the flow of an app, a left panel can be permanently on screen. I'm going to talk about two type of behaviors here. The first one is persistent. The second one is temporary. In the first example, there is a persistent panel coming from the left. Here I can still interact with the content and choose to remove the panel. The second example, the panel is temporary. Here I'll need to snap out in order to get my content back. This last example is another variant of the temporary behavior. Here you can see a left panel can simply overlay content. Successful handoff. So we have this idea of a consistent grid. And now we need to know what happens to that grid as different parameters, adaptive parameters change. So to do that in material design, we've started to align around certain breakpoint systems that work across material products. It looks pretty complex, a little like this. It's kind of complex. But what we've done here is we've done a detailed study of our device landscape, ranging from small phones to super large desktop displays. Let me break this down a little bit here. So on desktop, we looked at window sizes. So you have an extra small window. And that goes all the way up to an extra large window. On mobile, we have three basic sizes. They're small, medium, large. Small is like your Android One devices. Medium is like an Nexus 5 or an iPhone 6. And large is, yay, phablets. We also looked at tablet sizes. So we have small tablet sizes, like a 7-inch. And large is like a 10-inch tablet. And then for landscape, we calculate the smallest width in either orientation as the defining value. So here's how landscapes look. And getting to some of the stuff that Ewan was showing with the grid, we've also defined a few key points at which that default grid starts to change based on the screen size. So you can see above 840 here, it's a 12-column grid system always. Sometimes more when it gets bigger above 1,600, but for the most part, 12 columns. And then below that, 840 to basically 480. It's an 8-column grid. And then below 480, we use a 4-column grid. This helps us create consistency in our layouts and consistency in UI patterns. There's two other things being pointed by this one here and the two on 1,600. So basically at 600, what we found was it's quite a small size. So what we try and say there is that you can sort of have one level of content hierarchy on the screen at a time. So you have a list or a detail. And those need to be sort of layered at that screen size. So once you go above that screen size, those can share the same screen space. So you have your list, which might be emails, and your detail, which might be looking at one email. And above 600, those can share the screen space because we have enough space for things like typography line length. And so that's just some of the things that this is helping us define. Also noted at 1600, the grid can sort of hit a max width and it can either become centered or it can stay left aligned or it can continue to grow as the screen space grows. So I know what you're thinking. You're thinking, wow, that is the most beautiful illustration of breakpoints I've ever seen. I want to buy this man many stoop waffles. But please, dear God, show me the code. So implementing breakpoints with Polymer is actually pretty straightforward and there are two core concepts behind this. One that you're probably already familiar with and one that you might have played with before. The first is CSS media queries. How many people here have used CSS media queries before? Basically everyone. So this is even Zach's use CSS media queries. God. So media query is really powerful. Now all of the breakpoints that Zach was walking you through in his beautiful illustration are currently available in Polymer Starter Kit. So you don't have to go wondering, okay, what number is that? How do I fit this in? It's all already available. And the other primitive that we think you'll find useful for building adaptive UI is iron media query. Now we've had this around for a while, but iron media query basically gives you data binding on top of CSS media queries. It's an element that's built on top of the HTML match media API, which lets us parse out media queries and do intelligent things with them. Did I pronounce that correct? HTML. You're in charge. HTML. Yeah, you're in charge. You guys say HTML or HTMS? I'm just gonna assume I'm right. Okay. Right, so you can see the API here. We've got a few tributes. So we've got query, which is a bare CSS media query. We've got query matches, which is a boolean for just letting you know whether or not a particular media query's been matched. And then we have an event that lets you hook into whether that media query's been reached called on query and matches changed. Now together with these two primitives, we can actually build pretty powerful things. This is a new template that we've been working on for blogs. And we call it super cool blog, which is, that's the right way to pronounce it. That's the right way. That's the right way, great. I get my paycheck this month, fantastic. So here we've got super cool blog and basically what we just saw was a grid of lots of different types of content adapting to fit the context that it's now in. So we've adapted from a desktop view over to a mobile view. We're now just like stacking these cards on top of each other. Because we're using our media query, we're also able to achieve more complex effects like this kind of fancy header that you see at the very top. Another thing that I've been working on lately is a material music prototype that looks a little bit like this. It's basically built using neon animated pages.  But the idea is that you have a slightly more complex looking grid on desktop. We have a lot more screen real estate here. Anytime you select an album, we show you this view. But let's say that you switched context and you moved over to a mobile device perhaps. Here we've adapted this grid to make better use of the space. It's a slightly different type of grid, slightly simpler, makes more sense for your thumbs to be able to touch these items. And we also, when you select an item, we just show and hide UI to make best use of that screen real estate that we've got available. So, as we mentioned, when defining adaptive UI, sometimes the best user experiences take more than just reshuffling blocks on a page. And so what we're currently in the process of doing on the material design team, like the past couple months, the next couple months, we're in the process of doing this stuff right now, is defining UI patterns and working with Polymer to help us build some of these patterns into components. So I'm gonna walk you through some of those and Addy and I are gonna try to trade the clicker without fumbling it, which we've done so far. But we've been pretty hard at work on the material design team reviewing hundreds of apps before they've launched their material reviews. And what we've found is that apps share common architecture. A lot of apps are lists and just different variations of lists. So what we're trying to do is define this as a pattern and be able to provide those things baked in with our guidance so you can use it a lot easier. So there's just a lot of themes that we found that reoccur in the reviews. So the first theme is basically position. The position of elements can be core to the discoverability and the usability of an app. When screen sizes change or we change from using a big clunky finger to a mouse, our expectations change with where we expect to find certain UI elements. So here's a good example of that. In material design, we have this big pink button. Sometimes it's not pink, but we call it the floating action button. And sometimes it's like the most hierarchically important button on a screen. It's also called the fab, so you might hear me say that. On mobile, this is pretty discoverable because you're not that far away from it, right? But when we move up to a larger screen, sometimes that thing, if it stays in the bottom right corner, is a million pixels away from everything else on the screen. So what we're saying is you can move that thing. It doesn't need to stay in the bottom right corner. And I'm not trying to say here that here's the new location of it, but it can be relative to UI that is appropriate to the context of the app that you're showing. So things can reposition. There's other things that reposition. So basically we take that theme and we're looking through all of the various components in spec and saying, what else moves? So there's things like snack bars and menus and a lot of other components. So let's take a look at how this was possible here. Cool.  And when someone does that to me, I usually say, yeah, yeah, sure. If by as good as you mean not at all. Thankfully, when you're building adaptive apps with Polymer, it's not really like that at all. Here we've got desktop view where we're positioning our fab in the very top hand corner and we're achieving this just using CSS, just using some position absolute. When we change our context and we switch over to mobile, we can actually display this closer to your thumb. Again, just using a very simple CSS media query. I'm using one of the break points from the material spec and I'm just positioning it closer to the bottom corner of the screen so that it's actually closer to somewhere that you can reach. Let's take a look at another example. So here we have a menu. We've got a paper menu that you can go and you can select to have it expand. Now this type of UI probably makes sense on desktop because we've got a lot of available screen real estate. But if you switch context once again to a mobile device, maybe you want to make sure that that's a little bit closer to your user's fingertips. And to do that, we can use a media query that will just stretch that menu, change its position from the top part of the screen to the very bottom. It will stretch its real estate so it's taking up all the available space. And this is an example of us reusing the same content in a component but just changing its container around a little bit, just making sure that it's in the right position for your users. So that's a good transition here, right? When we change containers, we find this happening a lot in material design apps, especially when things just change drastic form factors, right? So transformation patterns can also be technically the most complex adaptations of UI. And also from a UX perspective, it's sometimes difficult to understand when to do certain things. But we believe that components sometimes need to transform from one form factor to another. So here's an example of that. We have a left nav on mobile. Because of Android, our users are familiar with this pattern of navigation coming from the left on mobile. It's been built into a lot of apps. But when that same navigation is a responsive web app that scales up to desktop, we can transform what was in that left nav into something like tabs. Because it's more discoverable. It's not a hidden menu when it doesn't actually need to be hidden. So there's a lot of things like this of components transforming that we're looking at. We have things called bottom sheets in material design and it's basically like a menu that comes from the bottom of the screen on mobile. And when you touch something here and something moves up very small amount, like that's not that far. But when you're on a big desktop screen and you touch something way up here and a small bottom sheet comes from the bottom, doesn't work. So that needs to transform into something else that's relative to the context of an app. And there's a lot of other stuff. So here we have an example of this pattern implemented using Polymer. On desktop, we've got some horizontal navigation that are using tabs and have that sweet in effect. And then if we switch context over to mobile, you'll see that we now have moved all the navigation into the drawer rather than repeating our different forms of nav. Now, this makes sense because of the context that we're using. We accomplished this using iron media query. It's really, really powerful. So here we can use the on query matches changed event to hide the drawer if the user happens to be, if the user is a developer basically and they're resizing the screen. But we can also make sure that we're using computed properties in this case. Computer properties look a little bit like this, which basically allow us to trigger tabs to be hidden if we're on a smaller screen. So here we're just doing a little bit of class switching. So reflowing is commonly what we think of when we think of responsive design. Things move as our screen size moves.  But we're just trying to bake this theme into the system. So for example, we have this little Polymer clock widget. And on the top is this digital header and on the bottom is an analog clock. And it's a small vertical screen, but when we go to a larger, more horizontal screen, the architecture changes and we have the clock on the left and the analog part on the right. So lots of reflowing will just naturally happen. Another common occurrence of this that Addy's gonna walk through is grid lists. Grid lists are, you know, well, I'll let Addy walk through it. But first, let's look at this clock here. Okay, so Zach was just talking about a clock example. We're in adapts from being horizontal to vertical depending on your context. Now the good news is that the adaptive UI portion of that example is pretty trivial to implement using Polymer. The clock itself took me many, many hours to do and we're no longer on speaking terms. But in Polymer, we can achieve this effect once again using iron media query. And we're using it to sort of trigger a change in layout, once again using Polymer's layout classes or layout attributes, so that you can switch from horizontal to vertical. Depending on whether you know you're on a small screen, like a phone or tablet, or you're on desktop. Let's take a look at another example. So most of you have probably visited the Polymer Summit sites and you've taken a look at the schedule. If all of this is completely foreign to you and you're wondering what you're seeing on screen, you were probably at the wrong conference, but stay around and maybe you'll learn something about Polymer. Let's focus in on this grid for a moment. So we've got a grid here implanted using Polymer and this actually reflows. So on desktop, we have these really thick cards that have a lot of information, lots of interesting stuff going on. But as soon as we switch to a device with smaller screen real estate, we actually reflow this. So we're now displaying all of these cards, not just vertically, but we've also sort of collapsed them. So if you're scrolling on your device, rather than having to scroll through the full length card for every single session, the users can control deciding whether or not that expands. So we have three elements that power this. We have our iron media query, of course. We have our schedule grid and we're using iron age access to power the data behind this. So let's focus in on just the grid part of this. So we've got our schedule grid here and it's got media query definitions for all of the breakpoints that we're trying to target and it basically will change the maximum width of each of the cards as we decide to switch between viewport sizes. Also defines defaults for margin and padding because those things might also change depending on the type of context that you're in. Now we're taking advantage of narrow layout over here, which basically allows us to use a useful pattern. So rather than having an iron media query definition inside of every one of our elements, we're just using one and we're passing its state down the whole way through our data binding system. It's kind of neat and that just lets us decide whether or not we're going to collapse this card or keep it expanded. So a couple more patterns that I'll get through a little quicker here. There's, you know, we're familiar with this pattern of revealing UI as screenspaces grow, but here's a small example. Let's say I have this sort of CMS or text editor on mobile and as screenspace grows, we reveal more powerful UI, maybe because we went from finger to a mouse or just because we had the additional screen space to reveal more UI. So here you can see we added the font editing and a few parameters for justifying text. Revealing can also apply to a lot of things. Like imagine you have a small card that there's a lot of content behind a click or behind a touch on mobile, but on desktop we reveal more information in that same card container. Looking at divide, which is another theme, this starts to get to the structure of our applications. So here's a good example of the divide where you have this thing on the left here is basically three layers to an app. You have a left nav that's hidden. You have a list and a detail. Imagine this as Gmail. But when this grows, you might have something that's like a left nav and a list and a detail just dividing into the space. And these kinds of things that we know how these patterns work, we're trying to wrap these as components. And a lot of the stuff that you and showed earlier, those are a lot of component mashups that we're trying to provide as responsive adaptive elements to all of you. Because as we heard earlier from Rob, I heard that you're a little lazy. So we're trying to give you that stuff for free. Yeah. The other thing that we're looking at is just respecting natural scrolling directions. So on mobile, we scroll vertically and we scroll horizontally. And on tablets, especially, I scroll like this. And, but when you go to a larger desktop and you're using a scroll wheel, that doesn't feel right. So we're just in the process of asking the question, like can we make an adaptive component that changes scrolling direction based on a breakpoint? And then just very simply and lastly, surfaces expand. So you have a card on mobile and that card might expand to either a column width or it might expand to an incremental width. So, yeah, I'll just go. Cool. So we've been working on another example of adaptive UI and Polymer. This is the greenest application in history, but basically the idea is that we're demonstrating a few different patterns here. We're demonstrating transformation, reflow, and position. So if I switch up and say that I'm on a tablet, like a Nexus 7, you'll see that we started off with a slightly thicker header bar at the very top, but we still kept that same effect on scroll. We switch up to a Nexus 6, you'll see that we've changed the position of that fab so it's in the very bottom corner, the user can easily access it. And we've also got a slightly different paper drawer panel in place as well. Both of these things are possible thanks to CSS Media Queries and Iron Media Query. Every time you guys talk about UI patterns, I want it to pee. We took all of your time. So where were we? It is our goal to make making material design apps easy. Let me introduce some of the tools and resources that you might find useful in building your apps. The app layout collection created by the Polymer team is available on GitHub for people to explore and build their own templates. And if you haven't checked out the paper elements in the Polymer catalog, you really should. We also created a device matrix reference. Using this reference, designers can quickly get key dimensions, the densities and other matrix they need. The latest tool in the works is the recizer. By previewing web app in FamilyShot, you can examine and compare if any UI elements adapt appropriately across devices. You can input any URL or choose some of the preselected size in the side drawer. If you wanted to preview per device, you can navigate through the key breakpoints that we'll introduce today for desktop, mobile and tablet. Should I go back? Yeah, we also have the material design spec. You can feel free to check that out too. We're constantly updating and refining the material design spec. So what's next? The future of the web app looks really amazing. And we're looking forward to all of the stuff that you guys are gonna make. And the material design team and Polymer are just trying to make it easier for you to build things that we already know about. And we already feel like we have good system for defining. So with Polymer, we're creating lots of demos, like Addy was showing. We're creating more templates so that you can inspect these things and pick them apart and understand why we're doing certain things that we consider to be best practices. You can also follow the material design team and just design, all things designed to happening at Google. Talk about design at a developers conference. But we're doing a lot of stuff here.  There's one coming up in London and one coming up in New York. There's a lot of new articles. There's one that's a great read about the new Google logo that we just launched. And some new resources, like the one that you and was just showing there. And these tools and all this reference and guidance and stuff, we're trying to make it easier for designers and engineers working together to build really awesome things with material design. So with that, thank you all for coming out. Yeah.


Hello and welcome to this session in which we will discuss the price elasticity of supply. In the prior session we looked at the price elasticity of demand. So it will be helpful if you can view the prior session because the formula is basically the same except we are using with supply rather than demand but you have to understand the difference between supply and demand. So the price elasticity of supply measures the responsiveness of the quantity supplied relative to change in its price. So when we change the price how much with supply changes? What's the what's that measurement? So we're going to quantify the percentage change in quantity supplied relative to the price percentage change in price. Simply put change in quantity delta and quantity which is a percentage divided by the delta and price percentage but here we are dealing with supply not demand. Basically the formula for demand is the same except rather than here we are dealing with supply in the prior session using the same formula for demand. I'm going to go over the formula in details a little bit more. So a higher price elasticity of supply indicates a greater sensitivity of suppliers to prices and change. So if we have a higher greater sensitivity a higher sensitivity it means supplier can react quickly to prices. Lower elasticity suggests a less responsive response. Now we need to know why some suppliers can react quickly to prices and changes and others cannot. There are reasons for that. Technically it's business reasons, resource reasons, limitation reasons, input reasons. We'll look at those later but this is what we're going to be discussing. So next we're going to look at the formula we're going to look at a few examples and factors that will affect price elasticity. Let's go ahead and get started. Before we proceed any further I have a public announcement about my company farhatlectures.com. Farhat accounting lectures is a supplemental educational tool that's going to help you with your CPA exam preparation as well as your accounting courses. My CPA material is aligned with your CPA review course such as Becker, Roger, Wiley, Gleam, Myles. My accounting courses are aligned with your accounting courses broken down by chapter and topics. My resources consist of lectures, multiple choice questions, true-false questions as well as exercises. Go ahead start your free trial today. Starting with the formula, the formula is the same as price elasticity of demand. It's the percentage change in quantity supplied which is the change in quantity which is the percentage change in quantity divided by the percentage change in price and this is how we find the price elasticity. Now again if you don't know how to find the percentage change how do you find the change? You subtract the initial value or the old value from the final value or the new value you will take the change whatever you find in one divide the result by the initial value then you multiply by 100 to express it as a percentage so simply put if we told you the price of a product increase from 50 to 60 first you compute the dollar change the dollar change is 10 and you the change divided by the initial value of 10 and we say the change is 20%. Now bear in mind as I mentioned earlier it's not the same as going from 60 to 50 here the change is 10 but you're dividing by 60 and the percentage is 16.67% so just be careful be aware use a calculator. So let's take a look at an example that applies the formula and specifically I'm going to tell you we're going to find elasticity in this example less than one I already gave you the answer but we have to see how we compute it and more importantly what does it mean to us what does it mean to us suppose you're a farmer who grows apples currently you produce 1000 kilograms when the price is two dollars per kilogram this is this is the current production and the price is two dollars now there was a recent increase in demand you know why well the consumer taste for apple changed there was some report that apples is good for you so the price of apple is rises to three dollars per kilogram as a result you decided to increase your apple production now you produce 1200 kilograms of apple so let's compute the price elasticity of demand again how do we compute this the percentage change in quantity divided by the percentage change in price so let's do that the quantity the percentage changes the quantity went from 1200 kilogram to from 1000 to 1200 it's 200 divided by 1000 the initial value the quantity increased by 20 percent let's look at the price the price went from three dollars from two dollars to three dollars so the change is one divided by two well that's 50 percent times 100 equal to 50 percent now we can find the elasticity 20 percent divided by 50 percent so the change in quantity divided by the change in price again percentage we'll find out the price elasticity in this example point four point four is less than one what does that mean it means the elasticity is relatively inelastic it means the producers can't keep up with the prices the prices went up by by 50 percent the farmer was able to to increase their production by 20 percent this means a 50 percent increase in price led only to a 20 percent increase in quantity now let me ask you why why do you think that's the case i mean my parents we grow apples so i'm familiar with this industry why do you think that's the case do you think you could just grow more apples now it takes time it takes years to do that so farmers my face limitation and responding quickly to price changes to the factors like the growing season limited land availability you may not have enough land and if you have enough land maybe you don't have you have to put apple trees and it takes time or the time required to expand production let's take a look at an example where elasticity is equal to one which is seldom that's the case but for the sake of mathematically illustrating this it's a good idea suppose you own a factory that produce t-shirts currently you manufacture 10 000 t-shirts per month when the price is 10 so you're happy supplying 10 000 when the price is 10 however do to demand decline i don't know somebody else producing t-shirts people don't like t-shirts anymore for whatever reason the price the price drops to eight as a result you decided to do what reduce your production i'm not gonna produce at eight dollars i'm only gonna produce eight thousand so let's see what is the price elasticity in this example well if we find the percentage change in quantity supplied which is negative 20 percent two thousand divided by negative two thousand divided by ten thousand and the price is negative two divided by negative 10 is negative 20 again negative by negative equal positive so when you always when you compute the price elasticity it's going to be a positive but remember whether that's positive or negative we look at the absolute value which is one the the price elasticity is one okay what does that mean it means there's there's nothing it's the same in this example the price elasticity is one indicating unit elasticity the decrease in price by 20 percent lentor proportionate decrease in quantity by 20 percent so suppliers were able to adjust their production exactly the same as the price seldom that's the case in the real world but for the purpose of the mathematically computing it's a good idea let's look at an example where elasticity is greater than one what does that mean before we do the computation it means you can as the price goes up you can produce more you can produce more let's consider an example a company that produces hand-knit sweaters suppose the initial price is $50 and the company is producing 1000 of those sweaters per month again the sweaters the sweaters are popular there was an increase in demand and as a result the company decided to increase the price to 70 because there's an increase in demand well as a result you have to increase your production you have to expand your production now we can produce 1500 sweaters per month let's compute the price elasticity for this company well the change in supplied $500 the 500 units divided by 1000 50 percent increase in quantity supplied the price is the difference is $20 divided by the initial price is $40 if we compute the price elasticity it's 1.5 1.5 is greater than one greater than one what does that mean it means the quantity supplies is relatively responsive to changes in price it indicate elasticity of supply the quantity supplied is relatively responsive so as soon as the price went up by 40 percent we jacked up our production by 50 percent now why can we do that why can we do that why can we do that well it could be that we were able to hire more knitters increase knitting hours or people working with us increase their hours or source additional knitting material to ramp up production so in order to do that you have to have the resources you cannot have any limitation because you need to increase this because a 40 percent increase in price you increase quantity supplied and 50 50 percent it's an elastic supply let's take a look at summary but basically just to make sure if it's a greater than one it means the supply is elastic it means that the quantity supplied is more responsive to change in price in other words a small percentage in price lead to a proportionally larger percentage in the quantity supplied less than one in elastic supply the quantity supplied is relatively less responsive to changes in price in other words a given percentage change in price leads to a proportionally smaller percentage in quantity supplied now what factors what factors influence the price elasticity what one factor is the availability of inputs if you don't have inputs if you don't have enough knitters then you cannot ramp up the production of the sweaters so if the input required are readily available suppliers can respond more quickly to a change in price resulting in higher elasticity of supply on the other hand if the input wherever you are producing if you don't have the raw material are limited or specialized it may be difficult for suppliers to adjust production level leading to lower elasticity now even if you have lower elasticity in the real world what you hope to do is to if you cannot produce hopefully the price is increased enough to offset that shortage for you shortage in profit because you want to produce more you can't hopefully the increase in price will make the difference suppose there are two companies a and b both producing wood and furniture right here company a has easy access to a variety of high quality wood suppliers while company b relies on a single specialized supplier for their woods so company a is more diversified they have more resources company b not as much let's assume there's an increase in demand for wood and furniture leading to a rise in market price as a result both companies fade the decision whether to increase their production or not of course you want to increase your production what's the difference here company a it has wide range of suppliers that can easily switch between supplier or negotiated a better deal to obtain more wood and therefore expand production and sell more wood and furniture not for company b not for company b so availability of inputs will influence the price elasticity of supply another example that will that will not not not example another factor that influence the price elasticity of supply is time horizon how much time you have okay the time horizon refers to the length of time given for suppliers to adjust their production in general the price elasticity of supply tend to be higher and the long term compare to the short run of course always in the long run companies can adjust find new raw material find new suppliers but what matters is in the short run you want to how long how much time do you have for instance if a price of oil increases it may take some time for oil producer to explore and develop new oil fields or invest in alternative energy sources because you cannot just produce more oils like that in the short run the supply of oil may be relatively inelastic but over the long run they can find new land they can build they can extract that oil new sources are discovered and alternative technology are developed and the elasticity of supply increases so although in other words initially in the short run you might have in elasticity but suppliers always find ways to increase their production if we go back to covid same thing with covid uh companies that were not producing enough enough wipes alcoholic wipes well you give them enough time they will do it or not enough oxygen tanks well you give them enough time they will increase their production in fact all and other factors that influence the price elasticity of supply is production capacity in a sense they are related production capacity input just tell you this in different perspective if the supplier have access or underutilized capacity they can respond more quickly and more readily to changes in price so if you have access capacity and there is more demand that demand is always that demand can be met easily because you have access the best example is consider an airline that operate flight with empty seats or not full they don't have you know full full trips empty seats what's what happened if the demand for air travel increase the airline can accommodate more passenger by utilizing its spare capacity in this case the price elasticity of supply will be higher due to availability of unused production capacity but if all the seats were taking and there was an increase then you cannot take advantage of that all what you can do is you can increase your prices and hopefully increase prices will offset some of that also production time and complexity how can how complex is what you are producing the time required to produce and the complexity of production if you need to change your production and your processes are complex then you're not elastic because you need more time if the production process is time consuming or interact if the production process is time consuming or intricate suppliers may find limitation in adjusting production levels quickly because it gets more complicated for example if you are if you have handcrafted luxury goods that required skill artisans well guess what you mean have a lower elasticity of supply compared to a company that's mass producing item because it's more difficult for you to expand your production why because it's considered more complex you need to require more time and special skills also barriers to entry could influence the price elasticity of supply the presence of barriers what could be a barrier of entry well high capital requirements for example if you want to produce cars okay if you want to start a car manufacturing company well you're gonna you're gonna need billions and billions of dollars well if you want to start a consulting company the barriers of entry is much more a much more much much more easier or you want to start an accounting firm you could have regulatory restriction for example if you want to start a pharmaceutical company you have to go through the FDA or you might need patents certain patent that could impact the price elasticity of supply when the barriers up to entry are high the number of supply number of suppliers may be limited resulting in lower elasticity of supply for example for talking about pharmaceutical industries faces strict regulation and lengthy approval process for new drugs well you cannot just say well another company can produce it it's not that easy this would restrict the number of suppliers and in the response of this supply to changes in price even if the prices go up for a certain drug but because it's in high demand you cannot create overnight a pharmaceutical company that can research the drug produce it get the FDA approval first of all it's expensive to its time consuming therefore if there's a barrier barriers of entry it could impact negatively the elasticity of supply what should you do now go to farhat lectures and work mcqs that's gonna cover this topic elasticity of supply price elasticity of demand those are important topics on the cpa exam important and easy topics where you can pick up what answers quickly and gain points as long as you practice multiple choice my job is to help you understand this concept your job is to learn it invest in yourself good luck study hard and stay safe


Okay, this is MXUX. This is a little list I put together That a lot of people say well, what's what what's the big deal with the hub mode as well First of all, it's completely new technology first time on the planet. It's been on a commercial production vehicle but This is an illustration which I said earlier. I believe I made this illustration Just real quickly go through this tire Rotor stator Tire rotor stator. This is how a conventional Electric motor looks like in a Tesla and this is how The motor looks on a Lord's time endurance Hub motors the most valuable IP because they create margin and revenue So Everybody's saying well, you know big deal, you know, so what so what why why does it matter? It does matter number one Yeah, go down this list reduces the part count You can look at the you can look at the part count you look at the parts in that Ford What is a drivetrain part count? You know I've gone through it in the video. You know a thousand parts It reduces the bill of material Okay Fewer parts shorter list of materials with mass production The bill of materials costs will be lowered. Okay, so you got a mass produce these motors and Nobody takes into account when I go through the cost. It's not motor to motor. It's motor Versus motor CV joints reduction gearing and every other component that goes into place Um Number three the hub motors simplifying manufacturing It was easy to put on basically as mounting a tire The amount of work stations required compared to The conventional, you know tesla drivetrain is you know reduced probably down from, you know If you if you count sub components 10 to 1 So When they simplify manufacturing They lower unit cost They reduce weight all the extra weight Is gone From the drivetrain from actually the sprung weight Is completely eliminated and this is unsprung weight which still has to be moved by the drivetrain but The overall weight is reduced substantially by eliminating all those components The reduced maintenance can be removed installed with normal hand tools. Okay faster manufacturing Okay more output The enlarge is plant capacity Okay, that can you know by what a factor of what? 50 percent you can Increase your capacity because you can put more models more vehicles through quicker Um, and this optimizes mass production And it optimizes profit By optimizing mass production consumers get f1 style performance, which is You know no one's talking about it, but it's all there See it in the moose test a more responsive truck safer torque vectoring and so forth The lord's time motor is the optimal battery electric vehicle drive unit There is I don't I don't see how there can be any more reduction in this And this is exclusive ip any us unique selling point for lord's time motors so I mean There's so many and you could go on and on on this now. I just want to mention This drawing here, which I have seen all over the internet Is my creation It is from a video. I believe it's titled how how motors work So but I think it it does a good job People just can't wrap their mind around how this works because it's such a unique solution And they can't believe all the parts That are eliminated by this and that it works and lord's town has it not only the hardware but the software And it's in production So this is a game changer. All right, let's get back to the video here Okay, what follows is an example of a lightning drivetrain By santa munro a tear down look how many parts lord's town eliminates Okay, this is mx ux.  I just want you to see This is the front motor only of the Lord's town. I'm sorry the port f-150 lightning And you can see the number of parts here There's just no end to the knobs and things and gears and I wish I could get to the part with the differential here And there's the planetary gears and the sun and the planets and There you go. There's another shot of the planetary gears and then There's this shot of This I believe is the differential for the front wheels You can see here the number of parts the nested gears And uh, you know, this is just one component From that giant table full of components here. Let's see. There's a shaft that fits in and these are all part These aren't even all the parts of the motor That's the transfer gearing reduction gearing You got your stator over there They delaminated the rotor Let's see. What else do we have here? That's mostly about the And then you have of course you have all of these seals and multiple multiple fasteners and And So on and so now here's a great discussion. They're talking about the difference between the tesla pump and the Ford pump here And then this is a lubrication channel guide They're comparing tesla and then and there's your there's your stator And then Let's see. What else do they have here? And again, here's your stator coming apart and you can see now. This is just a front wheel motor There's more of this for the rear wheel as rear wheels as as well And uh, I don't know what what this parts count is on this table here. Let's see what this is Oh, this is a locking differential for the rear motor. I believe no, this is for the front motor too No, this is the rear motor. Well in any case, it's a component of the rear motor Maybe Okay, so how many how many parts do we have here? I mean I I I wouldn't even venture to guess now. Here's some more. Let's take a look at this. There's there's a casting and and More gears and You know There's just a never-ending supply of parts here Let's just look through here And see what else is here. Anyway, you get the idea Um, I mean if we were going out this is a commercial they did that's the What you call it? Anyway, take a look at those parts. All right now We're going through this you can see all those parts now, hopefully If I did this, right We'll be able to see That's an alofi hub motor. That's the whole motor That's it Nothing else That's contained One of those goes on each wheel. There's three electrical connections when cooling system connection those four bolts mounts onto a suspension and the endurance it's a Straight axle in the rear and a you know, a wishbone suspension in the front The wheel bearing the disc brake everything is contained in that unit as well as the stator and the rotor That's it those are all that's the parts Here's a picture of the outside That's what more or less what the endurance motor looks like on the outside That is the rotor the black thing that is the rotor That's what the endurance Chassis frame looks like and you can see those are inverters that are mounted Amid ships there and there's the cooling system The radiator up front. That's it No differentials No reduction gearing No cv joints No drive axles. No half shafts No cv boots. No cv seals. No All those millions of parts for the differentials. They have a parking brake Um, what is the parts reduction there and these motors each motor has a bearing a rotor and a stator. That's three parts So one two three four. What is that 12 parts compared to And that was the front motor only and I got to say that's 500 parts There is a hub motor installed that is What they look like installed That's the whole thing No drive shaft. No cv joint. Nothing like that This is very interesting This illustration hub motor versus traditional ac dc motor as in tesla and it shows you here Um, how now this would be the tire And this would be the tire And this is a conventional motor here So this the tire would hook on to the rotor the tire hooks on to the rotor of the luffy The rotor goes inside the stator Here the rotor goes outside the stator It's kind of an inside out induction motor Instead of having the rotor inside the stator the rotor is outside the stator These are the parts. These are all the parts for the thing. That's it. There's the rotor. There's the stator There's the wheel bearing. This is the disc brake if you want to count that as a motor part. It's not That is a suspension knuckle. That is not a motor part. So this these are your parts here Wheel bearing rotor stator. This is very interesting It says Wordpress is abtero scam Ha I did this illustration Probably a year and a half ago Someone stole it and appropriated it. I've been looking to find it. I didn't I couldn't realize which video it was in But this I think explains exactly what's going on with the luffy And you got the wheel the wheel the rotor the rotor the stator the stator you see how that is It's like an inside out regular induction motor And I just my drawing someone stole it Whatever This is another piece here on the endurance Just to show you where these motors are installed that And here's yet another Emobility engineering that is the wheel knuckle Now we're going to call this part of the motor even though it's not really but it is Wheel bearing that's the disc brake. That's the stator. That's the rotor Okay, we've got three parts here Five parts if you include the brake in the suspension knuckle versus 500 for the Ford let's see if we can go back to the Ford. There's your Ford Okay, there's your Ford And here That's your luffy on the top there Ford kind of uses this with all the induction gearing and cv joints and everything. This is the luffy again That's the luffy installed. That's what the most kind of endurance frame looks like That's the hub motor that's the whole thing and that's the whole thing And and that's the whole thing It's your all examples of different types of hub motors, but this is the hub motor that's in the luffy hub motor that's in the Endurance this is being manufactured on site at the lord's town facility Lord's town motors owns the manufacturing line lord's town motors has the rights to this motor. I believe in north america And fox con is operating this line. They are manufacturing these motors at lord's time So That's the endurance and you see these are the four bolts the wheel bearing is inside there. These are the four bolts that mount to your either your wishbone suspension Arm or whatever it may be and in the case of the endurance to straight back axle your axle versus And that ain't even all the parts Get do you get my feeling here? There let's see. Let's see if we can get it there That's all the parts there cooling and power and control Okay What's this? Oh my goodness. That's about half the parts For the front motor only Of the four diff 150 like this is why And I am going to try to go back to my original drawing here So that you can get a grip on this This is why The Lord's town endurance Is A better vehicle. Oh sorry There it is Hub motor versus traditional acdc motor tire tire stator Rotor rotor Stator stator you see that that's that's equivalent to that That's equivalent to that and there's your tire Okay, that's your elafi. That's your lord's town motors And you know what I think lord's town motors ought to change this The name of this component to the lord's town motor Okay, it's the lord's town motor from lord's town motors And there's the fort again There is the elafi There's the fort again. All right, you get the point. This is mxux. I just wanted to shoot this out there real quick Thanks a lot for watching Good luck in the market


Hello, everybody, and welcome to this talk titled, When They Go High, We Go Low. My name is Tal Tzvik, and I'm a developer at MetalBear, where we develop Miradee. So this talk is about solving a seemingly high-level problem using quite low-level techniques, specifically the problem of cloud-native developer experience. And more specifically, we will discuss Miradee, which is a DevTool written in Rust that is for developing cloud-native applications. Miradee enables cluster-connected but local execution of cloud-native applications. And what that means and what it looks like will become clear as we move on. So as I said, the high-level challenge Miradee addresses is cloud-native developer experience. And more specifically, just being able to run your code while developing it. And the solution Miradee deploys is at the operating system process level. First, we're going to talk about what Miradee is for. Once that is out of the way, we're going to take a look at some of the low-level technical details of the implementation of Miradee.  And during this talk, I hope you'll understand why we went in this very low-level direction for Miradee and also how it works in general terms. So first, what Miradee is for. Running the code you're working on while developing is useful and helpful. And with many types of software, there is a simple enough task. But often when it comes to cloud-native applications, that can become not so trivial at all. But I believe that we shouldn't abandon useful development patterns and practices because they're harder to implement with cloud-native applications, which is just develop a tooling to make them easy. But how do you run your cloud-native application while developing the application if it, for example, accesses files that only exist on the cluster? Or if it uses other services in the cluster over IP? Or if you need another service in order to generate requests to your application? And besides, running your code often is good. And you might not want to spend time containerizing and deploying it after every little code change you want to test out. So there are multiple existing approaches to solving that problem. They don't all offer the same capabilities, and they don't all result in the same kind of workflow. But other tools, for example, try to just enable remote debugging in the cloud or there for running everything locally on the development machine. The approach mirror detects is to enable local development with remote access. Now, there are other tools, like telepresence or GIFIRA, that also belong to the remote call category. A term I learned in Daniel Bryant's talk yesterday. So but unlike those other tools, Meridae works on the process level and not on the machine or maybe container level, which results in a different workflow for development. And it also results in some nice content for technical talk. Now, the idea is to have optimal development experience for running the code. And for us, that means really just as simple as running non-cloud code, so as simple as just clicking the Run or Debug button in your IDE or some very simple shell invocation. In the same time, we want developers to be able to run with meaningful data, realistic conditions that are similar to the conditions the code will meet in production, and also just being able to utilize existing environments. So with Meridae, developers can execute their code locally, either in a shell or in their IDE. And when the application accesses resources from the cluster, it gets actual traffic and actual data from the cluster, even though it's actually running directly on the developer's computer. And developers can run their code very easily and do things like stepping through breakpoints, but still take advantage of realistic cloud environments, like maybe some shared staging environment that is maintained in the team, all the while being non-intrusive and not even changing the application that is currently deployed on that cluster. Now, Meridae does that by running the software just in a simple process on the developer's machine and adding a thin layer of transparent virtualization, connecting the application's IEO points to the cluster. And the way Meridae achieves that magical effect is by injecting a dynamic library into the application's local process and hijacking some key operations made by the application, which leads us to the next part, the cool technical details. So here we'll take a look at key steps Meridae takes in order to hijack an application's calls and make them magically succeed even when trying to access resources that don't exist on the system it's running on, but do exist on the Kubernetes cluster the developer is working with. So the first thing we need to do is to get our code into the processes memory. The way we do it is when a user tells Meridae to run their application, Meridae executes that program. But first, it asks the dynamic linker to also load our dynamic library into the new processes memory. You might know it as the LD preload trick on Linux. On Mac OS, the equivalent environment variable is DYLD insert libraries. And Meridae just adds a path, like the path of its dynamic library to that environment variable. And the dynamic linker loads our code into the new process in addition to that process's own code. OK, so now our code is in there, but we need it to run. Just by virtue of being in the process that doesn't mean our code actually runs as the user's application doesn't call it as it isn't and shouldn't be aware of Meridae. So in order to ensure our code runs, we use another feature dynamic linker's offer, which is what is sometimes called a constructor. And that is basically the feature that code that is placed in a section, a specific section of a binary, will be executed on startup. So Meridae just puts some code in that section of the binary, and that code gets executed directly on process start. Now, as mentioned before, Meridae is written in Rust. So that's the syntax we're seeing here right now. And Rust has this nice package that basically lets us just mark this section using this little attribute about our function. So all we need to do in our code, in Meridae's code, is to define such a function, write whatever we want to run on startup in the body of that function, and that will run when the process starts. OK. So now we have code execution. And now there's a question, what do we use that ability for? But before we answer that question, just to make sure we're on the same page, a quick introduction into Alip C. So it's the C startup library. It implements some useful low-level operations that most applications need. It is used indirectly by almost every programming language. So when writing Python code, you might not be aware that that code, when running, will result in calls to libc. But when running, for example, file.read in Python, when that code is executed, at some point there's going to be a call to libc's read function or some other similar libc function. And that is the case for most programming languages, with a notable exception of Go and Linux, which is why we had to do some extra work in order to also support Go and Linux. But that is a bit outside of the scope today. So this indirect call to libc means that most languages don't actually include some programs written in most languages, don't actually include syscalls directly in their code. More typically, they would include calls to libc. And libc, in turn, makes syscalls whenever it's necessary. And that makes libc a very good choke point for us, for hijacking operation that are done by the application. Because basically almost or virtually every application will use libc for those operations. OK, so now that we have code execution in the user's process, what we do run on startup is code that utilizes freedom to hook libc functions. First of all, freedom. That is a dynamic instrumentation toolkit. And that means it gives us an SDK for manipulating the processor's code while it's running. And what I mean by hooking is that we use freedom in order to replace the first couple of binary instructions in the functions code with a jump to our code. So for every such libc function we want to hook, we just define our own replacement function. We call them detours in our Rust code. And we use Frida in order to make sure that whenever the user application calls those libc functions, our detour functions will be executed instead. So what we have to do there is basically to create a Rust function with an identical signature and also notably the C calling convention. And basically, yeah, whenever that libc function is called by the user application, our code will be executed instead. Now, the code that we put in those detours right there isn't run on startup, right? On startup, it's just the Frida code, like our code that uses Frida, that makes those hooks. But whatever we put inside of those functions will only run when the user's application actually makes those calls to libc. So now, what do we do inside of those detours? Is, first of all, we check the configuration or a flex that the user passed to mirad. And then we decide if this operation should be carried out locally on the developers machine or in the cluster. Everything is kind of configurable. So for example, you can tell mirad you want to read some files locally and other files in the cluster. Or the user might want to read everything in the cluster but only write locally, et cetera. So after we made this decision, mirad will send the operation to an agent running in the cluster. Now, that agent is spawned just in time when we start the mirad run. And it is deleted automatically once the run is over. And basically, that agent will get that operation from the locally running dynamic library of mirad. And it will perform that operation in the cloud, return the data or the results back to mirad that will in turn make it available to the unsuspecting user's application. So for example, if a user's application tries to read from a file, mirad will check the configuration if it decides that it should be read in the cluster. It will send a message to the agent in the cluster. The agent would read those bytes from the file system that is available to the deployed application. Return those bytes back to mirad. Mirad will populate the application's buffer with those bytes. And the application basically just doesn't even know it's not running on the cloud because further application is the exact same effect as running in the cloud. Now at this point, you might be wondering how we even access the deployed application's data, its file system traffic, et cetera. So first, we need to know where to get the data from. For that, users can specify a target for mirad so that's either a pod, a deployment, or an argorollout optionally with a specific container. Now the most common use case for mirad is for working on a new version of an existing microservice. And in that case, you're going to have the stable, like the current version, of that application already deployed in the cluster. So that application is what you would typically use as a target for mirad as that's the resource that's the application that has the data that your local application needs. Now, the next thing that is important to know is that our agent runs on a pod on the same node as the target or as one of the pods of the target. It then joins the target's Linux namespaces. Now here it's important to know that those are Linux namespaces that are unrelated to Kubernetes namespaces. And in order to read files from the target's file system, the mirad agent accesses paths relative to the target container's root path. So that was the cool do-it-yourself way to get this data. But ever since ephemeral containers were introduced, we also support just running the mirad agent in an ephemeral container. And we'll probably be moving to make that the default. So since ephemeral containers are designed, are meant to enable debugging a running container, they already get all of the container's data. So they access the same resources. So over there, we don't even have to do any cool tricks or anything especially in order to access that data. So I mentioned resources that mirror the access of the target. And the main ones that we support are networking. So that's both incoming connections and also initiating connections. And also, DNS resolution in the cluster. And then there is file system access and also environment variables. So zooming out a bit, we can see that the main components of mirad, are first the mirad binary installed on the developer's machine, or maybe also a plug-in for their IDE. Then there's the dynamic library that is injected into the user's process. And there is the agent running in the user's cloud. So the dynamic library hijacks the calls by the user's application, sends them to the agent. The agent sends data back to the dynamic library. The dynamic library makes that data available to the user's application. OK, now after we've been to this short journey through some of the technical details of mirad, let's see how it looks like when users use it. And for that, we have this little example setup with some custom microservices written in Go, together with a Redis and a Kafka service, all deployed in our cluster. And we'll go through a scenario of a developer that is working on the IP visit counter microservice. So now let's go to GoLand, work over there, and see if the Wi-Fi will let us work with the cluster. Can you also hear me with this one? No? Can I have this one? I need both hands for typing. Does this work now? That one? OK, that one works. OK, so right now we're in the GoLand IDE, the JetBrains IDE for Go. And I already have the miradee plugin installed on my IDE. So I have this little miradee icon that indicates that miradee is enabled. And let's also take a look at the resources on my cluster and see that we recognize the same ones from that diagram we saw earlier. So just a quick look at this application we're going to debug. Like a couple of functions it has here in this main Go file, there is a setup Redis and setup Kafka in order to set up connections to those services. We have a load config method function that loads a configuration for this application. GetCount is kind of like the main function that is going to handle the requests, incoming requests, HTTP requests. And there is the main function that starts the server. OK, so we got miradee enabled. I have my breakpoint here in the main function. I have some very basic miradee configuration file, which is almost like the default configuration file. And now I'm just going to hit Debug and start running. Now, of course, what's happening right now is that miradee is spawning an agent pod in my cluster so with bad connectivity that might take a bit. But we're already there. So first of all, let's step into that load config function and see what that looks like. So here we can see that the application uses Viper, so a Go package in order to populate the fields of a config object with values it gets from environment variables. Now, I actually don't have those environment variables defined on my machine, also not in this launch configuration. But if we step through and go to the end of this function, we can see that the config was successfully populated with values that came from those environment variables. And the reason for that is that miradee fetched those environment variables from the cluster and made them available to my application here. So if we step out, we can see that now the application uses those values from the environment variables. So the value is in the configuration in order to do the next operations. So first of all, it's going to read a file from a path that was passed in this configuration. And right here, we can do a little verification and see that this path, of course, doesn't actually exist on my system. But when this application reads that path, it actually succeeds and it gets data and, of course, we now know that this data came from the cluster. The application doesn't know it, right? It isn't aware of miradee, but it's just like it's running in the cluster and has access to that file system. OK, the next thing, the application is going to set up a connection to Redis. We're going to step in and we can see that it uses another value from the configuration as the Redis host. Now also there, if I just try to connect to that Redis host directly from my machine without using miradee, Curl is going to tell me that it can't even resolve that host. And that makes sense because that name is internal to the cluster, but the application is able to create the connection so it's able to resolve the host and also to send Redis ping. And that is, of course, because both of those operations happened, were carried out in the cluster, so both DNS resolution and initiating an outgoing connection to that Redis service. OK, moving on, I'm going to skip over that setup Kafka function because it's really probably very similar to that setup Redis function. And the next thing the application does is to define the two routes it's going to handle. So one is for the health checks defined on the cluster and the other is the main one, the actual one that is going to handle. So let's just let the application start and start receiving requests. And if I go over to that console, I can see that we can already see incoming health checks from the cluster. And if we go over to the terminal, we can also generate requests to the cluster, right? So it's not to local host, it's to the actual cluster exposed in the internet. And I'm going to generate that request and we can see that my local breakpoint was hit because we already forwarded that request to my local application. And now I can basically step through this function and see how my application handles a real request that was actually sent to the cluster. Now, if I go back to the terminal again, so this response that Kirill received here was actually not generated by my local application but by the remote request, a remote application. And that is because in its default mode of operation, MirrorD just mirrors the traffic from the cluster to the local application, which means it duplicates that traffic, sends it over to the local essence of MirrorD, and it is actually the remote application that handles those requests. There is also a steel mode where MirrorD steals that application away from the remote application. And for that, there's also HTTP filters in order to steal only some of the requests. For example, you only want to steal requests that you generated and not teammate, or maybe you don't want to steal all of those health check requests because they're not interesting for your debugging. OK, so that's that. I'm going to go back to the presentation. We'll take a second. Nice. OK, so yeah, I think we still have a little bit of time. So let's look at another very low-level challenge we had to overcome in order to create MirrorD. So at one point, I mentioned injecting a dynamic library on Mac OS. But this is actually not at all as simple as it is on Linux. So in order to demonstrate that or short that challenge, this is like the minimal example for injecting code. So we have, on the left side, a very simplistic binary. It's a Rust code that I compiled to a binary called HelloBinary. And in the right side, a code that I compiled into a dynamic library that prints a line on startup. Now, if we just run that binary by its own, this is what it looks like. This is to be expected, right? And once we inject that dynamic library, we see both of those prints. And that is basically like this very simple principle is the same method of injection that MirrorD uses. But now what happens if I try to run some other program, maybe in a non-compiled language like Python? And reminder, this is all only on Mac OS. So what happens when I try to inject that same library into that code? So now that we can see that it doesn't work, right? We only see the print of that original application. And we don't see the print from our dynamic library. So it means that injection failed. Now, the reason this happens is basically because of a security mechanism on Mac OS put in place by Apple, where when a binary meets some set of not very documented criteria, this environment variable is not respected and is also stripped off of any of the descendant processes of this run. Now, over here, what I ran was like a Python script, right? And you wouldn't expect it to be protected by those criteria. And you'd be right. Because this Python script, as an executable right here, is not the actual binary that is executed, right? Because when we have this script, we have to look at the Shabang. That's like the hash exclamation mark in the first line. And this is what determines what binary is going to be executed. In this case, it's just n and n versus Python 3 as an argument. So n will decide what binary to execute next, like depending on that argument. And for many tools, for many interpreters, that doesn't even end that. So for many Python distributions or no distributions, just running a script results in a very long chain of executions. So first, you actually execute n. n of executes some script that then searches for the right installation on your system that then executes n of again. And n of will then find at the end of this point the right binary. So in this case, some Python binary will be found and will be executed. So what happens in this situation is that n is that binary that is protected by Apple or by the mechanism on Mac OS. And this is why injection doesn't work in this case. But of course, we do want to support all languages also on Mac OS. So we did have to find a solution for that. And while the complete solution is quite involved and complicated, and if you're interested, you can see it in our code and GitHub, or also we wrote a blog post about it. But in very general terms, in very simple terms, what we do is we first extract just the binary code out of the executable binary. We then write it into a new file. We sign it on the go, and we basically run that new file instead of the old one. And now you might remember that many files or many runs are actually chains or executions of multiple binaries. So in order to also support that, we hook another libc functions called execve so that we can do all of that process on the go every time a binary executes a new binary. OK, so that was a quick tour through the internal of MirrorD. MirrorD has a lot more interesting implementation details and also cool features that I didn't have time to go into today. But if you're interested, please just check out our code and GitHub or our website. And now you've seen how easy it is to just test out. I hope you'll try it out and let me know what you think. And I also recommend joining our Discord for live MirrorD support and questions or also just to chat. And if you have any questions or want to talk to me personally, please just feel free to come to me after the talk and say hi or anytime. Also, I have some limited amount of MirrorD and Melbert swag with me. If anyone's interesting, just come to me after the talk. So thank you very much for your attention. I think we might have time for a couple of questions. Yeah, so we do have time for a couple of questions. So yeah, if there are any questions, we can do that now. Hi, thanks for the talk, really nice. How does the traffic from the cluster flow into the application running on your laptop? I don't think you went through that part. Right, so when the start runs, MirrorD first spawns the agent in the cluster and then it creates a connection with that agent. Now that connection is basically based on port forwarding into the cluster. So MirrorD creates kind of like a TCP connection directly with the agent that runs in the cloud and then communicates with the agent in its own protocol. Thank you for the talk, very interesting. The question is, that sounds fantastic. Is there any reason why this would not work for specific use cases? MirrorD. So any use cases that wouldn't work? Yes. Yeah, so there are some edge cases. So first of all, the most obvious for a basic one, we do it by hooking libc functions. So if you were to write your own assembly code that directly does syscodes and doesn't include any libc codes, any libc calls, then you couldn't use a review with that. Yeah, I guess we don't even try to support that. There are static binaries. So because the whole thing is like the whole mechanism is built around injecting dynamic libraries, static binaries are not good like that. It's not going to work for static binaries. But I think there are simple enough work rounds for that, like maybe just forcing a dynamic binary built. And I think we might have, if there are other cases, I think we probably already have them documented on our website. And if we don't, we welcome contributions also to the documentation. Hey. Good talk. Hey. Is the mirror this solution for the local machine is bounded by Linux or Mac only or is it also Windows enabled? So for Windows, you can run it over WSL. WSL, so Windows Subsystem for Linux. Yeah, I think we might one day also have kind of more native support in Windows. Yeah, we accept contributions on that issue. I think it's a very popular issue on GitHub. But the one the team is most afraid of, of ever being prioritized. So yeah. Another one? OK, hi. Yeah, I actually wanted to ask the same question. On top of that, do you have any idea to support bare metal or it's only about Kubernetes? Are you asking because of the name or? Oh, no, actually not. OK. I think right now we only support like Kubernetes also maybe like similar solutions like similar distributions, right? But I am not aware of any like plans for bare metal. But feel free to suggest it on GitHub, ask it on Discord. Yo. So Gilep C has versioned symbols. So what happens if I call a symbol that is not available for its version in the pot that you spawn on Kubernetes? What happens in the case? So the libc hooks all like happen on locally. They're not like they don't happen in the cloud at all. They're sorry, did I misinterested the question? That's not my question. In my Gilep C locally, the symbols are versioned. And they can be newer than on a remote host. OK, so basically we implement the operations not like one to one. So the operation that the agent carries out on the cluster is not just run that exact same libc. There is some level of abstraction. So basically, it would still work. Like also it doesn't depend on the libc versions being the same or whatever. I have two questions. Is this particular to the GNU libc or also support muscle or the other libc implementations? Which version of libc? Yeah, just the GNU version or does it also support muscle? Oh, actually I'm not sure. Do you know how? Sorry. Yeah, it should also work with older ones. If it doesn't, please let us know. But it should be supported. We're not aware of any problem with older libc versions. And the traffic that's forwarded between the Kubernetes cluster and your local. Is that encrypted in any kind? Right, yeah. So it's worse over port forwarding. So by the same encryption of the kubectl port forwarding. OK, thank you. Thanks. Cool. OK, we're out of time for today. If you have any more questions or just want to say hi or secure some swag, just let me know.