So, I'm super excited to be here. I actually feel really at home talking about the backbone. So today we're going to explore the little opinions and big possibilities, tools and patterns for building large-scale applications. So this is actually one of my favorite topics to talk about. I feel like it's one of the least known areas of backbone and one that I see a lot of developers struggle with. I guess the introduction has already been made for me, but since the beginning of this year, I've been writing and producing screencasts for a site that I created called Backbone Rails, which basically focuses a lot on these topics, building application architecture. So, today we're going to be talking initially about why I think architecture and backbone is so difficult. And I'll show you some tools and patterns that I've used to successfully build some really scalable apps. And I feel because backbone has a relatively small set of tools and components, I feel like there's an unfair bias on backbone really only being suitable for solving really small problems. When I was looking and submitting a talk here to Backbone.com, I got really excited because the call for speakers emphasized utilizing backbone within a large application. So let's start off by exploring the definition of a large-scale application. And I mean, what do you think it is? Do you think visual complexity, like a lot of moving parts on the page? Perhaps you think maybe it's a really advanced data synchronization model, maybe real-time collaboration like with Google Docs. Or maybe instead, you know, you think in terms of size, perhaps a code base that reaches 100,000 lines is officially large. And Adios Mane in his paper on patterns for large-scale JavaScript application architecture says that in his view, large-scale JavaScript apps are non-trivial applications requiring significant developer effort to maintain, where most heavy lifting of data manipulation and display falls to the browser. He goes on to say that if working on a significantly large JavaScript application, remember to dedicate sufficient time to planning the underlying architecture that makes the most sense. It's often more complex than you may initially imagine. I certainly agree with all of that, but it's still pretty abstract. I don't feel like we're really any closer to really defining what it is. So I'd like to try to define some characteristics of backbone applications that hopefully point us in the right direction. So let me just first start off and just say, what is not a large-scale application? And I really wanted to use to do NBC here as the poster child, because it's unfortunately most likely the first backbone app that most new developers use to understand backbone or even compare it against the other different NBC frameworks. And if you're looking at two NBC trying to foresee what it's like building a large-scale backbone app, this pretty much couldn't possibly point you in a worse direction. And why? Well, so let's see. I mean, you can add some to-dos here, which creates additional rows and you can check them off and clear them. But overall, this is really just a single function app. It just does one thing. And the problem is that this doesn't even come close to modeling or reflecting even what most basic backbone applications need to do. I mean, for instance, there's no routing events, there's no page changes. That means there's no need to manage, like, view hierarchy, figuring out how to replace old views and bringing new ones in. And most backbone apps consist of many multiple pages. One of the first steps in organizing those is breaking those out into distinct modules. If we tried separating out everything into NBC, it would likely lead to a significant over-engineering, probably turn a lot of new developers away for lack of a better understanding. But I think this is a good starting point. So we've identified some characteristics that you don't see present in really small single function applications. So now let's raise the bar way up. And personally, when I think of ambitious applications that I've used, ones which are of sufficient size and scale, undavidably needing to follow solid design patterns, I think of applications like Ardeo, Google Analytics, WordPress, Pandora. While Google Analytics is the only one of these that's not actually built with backbone, I believe without a doubt that it could be built with backbone. And to me, it's probably the single greatest example of the power of a fully client-side application. And so when I sit down and I'm writing backbone apps and code, this is where I set the bar for me. But for today, for our demo product, for our demo app, the one that we'll focus on and come back to throughout this talk is actually gonna be Ardeo, the first one. So I wanna show some examples of what I believe Ardeo is a sufficiently complex and large-scale application. For those of you who don't know or have never used it, Ardeo is just an application that lets you play music through your browser, assemble playlists, and create a music collection. So in this screenshot, I'm looking at my collection of music. And this lists out all the artists and displays that list those songs currently sorted by artist's name. And I can of course change the sort of order to something different. So when I click Play Count, sort by Play Count, it only updates that one portion of the page. And I could alternatively filter by searching or just clicking on any artist from the list there on the left, which instead of sorting, it would just filter down those lists of songs. And Ardeo's some really intelligent guessing and caching based on how large your collection of music is. So after the first time that I sort this list of songs, if I were to come back to this exact same sort order, instead of making a fetch to the server for that data, it would actually just display the cached collection, which would make the UI appear really snappy. And so also note that every single change, though I didn't show it in this demo, every single change that affects the UI, such as changing the sort order or filtering or searching, Ardeo's manually going to use the push state to update the URL. So that means that if we were to hard refresh or open up that link in a new tab, we would actually be returned to this exact same state that we left off at. So that really means that two interesting things are happening is one that state of the page is actually gradually changing as we click different buttons and interact with the UI. But that there's also this other representation of that state that should be able to be rebuilt solely from the URL only. So far, we've just been updating that one portion of the page, but if we come over to the playlist over here on the left, and we click on any item in this collection, say, we click Pink Floyd, then the entire music collection, that main region is gonna be replaced, and we're given a loading spinner to indicate that we're fetching one or more dependencies from the server. And then when those are returned, then our page displays, and now it takes out that entire main region as our collection of music did. So we also go into our settings, and this just repeats the same process. We click settings, it changes out that main region, and there you go. So, we have all of these modules on the screen which are visually orchestrated together, but they're actually all completely independent from one another. Different UI events may replace only a small portion of the screen while others wipe the entire main region. And of course, we've only scratched the surface of RDO and completely left out the fact that it's playing music real time in our browser and synchronizing that across any other device that we have connected. But for the moment, our focus really is on just this UI. So after looking at RDO, I think we can put together some characteristics of large scale apps from pen to paper. We know that there is a strong likelihood that we'll be dealing with multiple, if not many routers. That means that we'll have to rebuild the state of our UI solely from just a routing URL. We'll also need to manage a significant amount of views from small or large state changes in the UI. So we know that we're gonna need a really great system from being able to nest and compose multiple views together within each other. And technically, we need to be able to make sure that we're cleaning up those old views, shutting them down, ensuring they're eligible for garbage collection, AKA no memory leaks. And we know that we should be breaking our application into independently smaller chunks and modules and that these different parts of our system would need to communicate based on a series of complex events. So when an important action happens in one part of our system, another part to be able to be notified about it. So we'll probably have to manage lots of state changes, right? And from my experience, there's a strong likelihood that you'll be dealing with a large quantity of entities. Which is actually the same word that Jeremy was using. And that's the word that I use to refer to either models or collections. These are a significant challenge to manage. I mean, knowing when to pull them from the server, when to catch them, and how to handle things happening in real time. I mean, in the backbone docs, it suggests bootstrapping all your data when your application initially loads. Really, that would only work for really small sets of collections which don't have a propensity to go stale on you. Like in a larger application, you're probably working with like over a hundred different URL endpoints for these models and collections. So really, we just have to be prepared for writing a literal ton of JavaScript files. And that's not hyperbole. In the last 12 months, I've literally personally written close to a thousand JavaScript files for a production application that I'm working on. And of course, when I say JavaScript, I really mean coffee script. So I think we've identified some good stuff here. But where do we go? Where do we go here? Admittedly, there's a pretty significant gap between simple to-do apps all the way up to something like Ardio. There's an abundance of good backbone tutorials and knowledge out there, but it's mostly like in the getting started space. It's pretty sparse in the intermediate or even the advanced areas. But that's okay because building architecture is really about understanding good JavaScript patterns. So let's dive into what those may be. And did you catch that? I mean, I said that really building architecture is about knowing and leveraging good JavaScript patterns. There's no magic or silver bullet that's gonna do this for you. I mean, we're talking about significantly sized, ambitious applications. We're talking about the propensity to have more JavaScript code than any other language in your stack. And so we really have to admit to ourselves that engineering this all together is pretty serious business. I mean, it's a challenge to all developers. So anything new or innovative and worthwhile these days is extremely unique and specialized in a particular niche. So of course, nothing out of the box is gonna do this for you, but I get it. You're frustrated. You've written a gazillion routers and views. You've read a few books on a backbone. Maybe you've watched a few screencasts, though not mine, else hopefully you're not feeling frustrated. You've got memory leaks everywhere and your code base is just really just awful to work with.  You know, and I've been there and I've probably said the same thing.  It's just backbone's fault. I mean, backbone just sucks, right? So let's just scratch everything we've written and start all over with something else. We'll stop blaming backbone, embrace it. I mean, its philosophies are honestly really solid. And while I don't think that they're promoted well or understood, we can blame Jeremy for that. But when he pushed out version 1.0 of backbone, he wrote in his blog that the essential premise at the heart of backbone has always been to try to discover the minimal set of data structuring, models and collections, and user interface views and URL primitives that are useful when building web applications with JavaScript. In an ecosystem where overarching decides everything for you frameworks are commonplace and many libraries require your site to be restructured to suit their looking field, default behavior, backbone should continue to be a tool that gives you the freedom to design the full experience of your web application. I really think this is so perfect in pulling in and I'm a 100% firm believer in his sentiments. In fact, I believe the number one lesson that we should take from this is that if you're building a significant application, your number one priority should be to never give up control because you will need it. We've all seemed like a progressing shift and a good one from the days of monolithic tries to do everything for you frameworks to a much more nimble, simpler, focused set of tools. And I think this really reflects well in terms of building ambitious applications. Applications which are different, which have their own very specific niche and use case are all about creating an experience that's perfectly tailored to that environment. And really in order to do this, it almost always means assembling the tools that are exactly right and perfect for you. The great thing about backbone is that we have an unprecedented amount of tools that fit this philosophy perfectly. So we should leverage every aspect of this ecosystem. When we have a vast ocean of resources and plugins, extensions, we don't have to reinvent the wheel every time. So we can use something that solves one particular problem and does it better than anything else. And honestly, two-way data binding is probably the most overrated feature ever.  All right. So let's get back to application architecture, right? Because while each of those plugins and extensions solve one specific problem, they're still underpinned by our application's architecture. And unless we really solidify that we have a robust plumbing system, a structurally sound frame and a properly wired electrical system, trying to move in and add furniture and nice things in our house would just be an absolute recipe for disaster. So why is this the case? Well, let's take a look at what we get. We get routers, which listen to routing events and are also traditionally, strangely enough, used to manage views. We also get a lightweight event system. I've purposely left out models and collections here because those are actually very specialized objects. So they're the source of truth in your application and they're not really its architecture. Models and collections don't have responsibilities to any other object, just to themselves in their own internal state. So a large application, when we would just die trying to cram all of our code into these few objects. And why? Well, for one, we have like a ton of coupled concerns here starting with this router. So here's some code and it shows 10 routes, which is just a tiny fraction of the number that you'd expect to have in a large application. There's no way that one router could or should manage all of these. But let's just imagine for a moment that we navigate to the user's route, which would fire this list user's callback, right? And that by itself is okay. We're in the router, which listens to routing events. But the problems start here because traditionally, the router is also responsible for fetching dependencies. The right here, it's instantiating a new user's collection. It's also calling that directly, which is a terrible idea. And then it's also responsible for instantiating a view, pass it in that collection, and then determining even where in the DOM does this view should go. It also has to call methods on that view in order to get it there. This is, it's a trivial example, but it's quickly compounded and magnified. And this is where most backbone apps just go wrong. And it's clearly the very first step. And so remember, backbone is about the lowest common denominator of objects. And it's absurd to think that we should only use what we get. So what we'll need in order to build large-scale applications are much more specialized objects with much better separation of concerns. So here's what I'm suggesting. So all of these specialized objects I'm about to talk about are all connected. So I'm gonna first just introduce you to like the name of what each does and kind of a little bit about it. Then we're gonna go into like a deep dive and I'll visually demonstrate the usage of how to use each one. So right, we need to create a lot more hierarchy within our specialized objects and assign them very specific roles and responsibilities. The first thing that we could really use is like an actual application object. This guy will basically act as the container for all of our application-specific code. And that's basically everything minus third-party libraries and stuff that's not just used in this one specific application. So everything hangs off of this object, right? You'll get its own startup and shutdown behavior and it will also act as a great place to store objects that you essentially want globally accessible to all of your modules within the app. But you don't wanna actually make those like global objects on the window. A common use case would be like passing in like a current user, like the logged in user from the server. You're gonna want him like accessible to everything and storing him on the application object and giving like a handler and interface a way for other modules to access that is really a great idea. Application object is also where we're gonna set up like our main like structural regions that we'll insert all the other views into. We'll get more into that in just a second. The next part, the things like immediately beneath the application would be app modules which contain all the code that are the actual user-facing parts of your application. So this is actually where we'll move our routers into. And app modules also consist of all of the controllers and the views which actually make up the UI. So in this way, they're like the gatekeeper for these resources. They're the sole authority for all of the things within the controllers and the view. So like in Ardeo's example, we probably have app modules for like artists, album, album comments, playlist, playlist songs, currently playing, settings, billing, settings payments, settings profile, all of those kinds of things. They're all broken out into their own specific encapsulated modules. All right, so as I said, your app modules contain one or more controllers and your controllers are built in like a restful style. So controllers really are the end of becoming the workhorses of your application. They're the ones that are orchestrating all the business logic and all the application workflow. Really the controller is directly responsible for instantiating all the views that's on the page within its scope, within its concerns. And that those views are given all the dependencies they need, such as like their entities, their collection models, all the things that they need in order to function. All right, so we have specialized view now, not just regular vanilla views. And by doing it this way, now your views and separating out all the concerns and splitting them out into other objects, now your views are just back to, well, just managing the view, just their assigned template, a small chunk of the DOM, a portion of the page. And except we've specialized them, given them certain abilities in order to automate their management, right? Since we need to compose like a visual hierarchy and we need to establish like a pecking order, these specialized views are built to automate cleanup and shutdown, which we'll get more into in just a second. So really it's just this. I mean, this is really just the chain that makes up like application specific code that builds your UI, your interactions, your logic, your events and all that jazz. But we do have some other objects though. And while each of these has its own different role and responsibility, they're really all part of the utilities of your app. They're like this, they're the shared objects that any of your application specific modules can call out to and utilize. So we've got components, mix ins, entities and config. So components, first off, are kind of like services in Angular. Like they have their own controller and usually their own view. And common examples are basically where you wanna take specialized behavior out of views and abstract those up into their own reusable components. You can decorate views and basically give them this behavior with like a clean interface between these two things. So like a common use case would be like forms, loading views, grid views, uploading views, things like that. Mix ins, mix ins are a way to basically just group code that you want mixed into your views really like low level stuff for like DOM manipulation, things like that, which we'll get a little bit more into. Entities we already talked about. Entities are basically just the shared namespace for essentially all of your models and collections. It wouldn't make sense to like, even though we might have like a user's module, it doesn't make sense to store like the user entities in there because we might have like a dashboard module that shows user or an admin module that shows users. So by splitting it out and separating it, putting in its own namespace, that all of the other things can call out to those entities. Then we have just your basic config, right? Just the configuration like the overrides for backbone or anything else or configuration for plugins and stuff that you've brought in, all right. So we also have, I mean, we've been talking about it, but we have this actual specific notion of a module which is like a namespace, a grouping of specific behaviors, specific objects that have us, certain sets of responsibilities. And pretty much the last thing that we have is like a messaging bus for requests, commands and pubs of. So even though we have lightweight events in backbone, the messaging bus is basically the thing that it moves those responsibilities into the application. And instead of calling things directly, you'll go through this. All right, so this is where the fun starts and I'm gonna go through visualizing each one of these. So we have our application object which is like the ultimate container.  Everything hangs off of, right? So the circles on the left would be like app modules. Those are the things that are on the application that are specific user facing. And the stuff on the right is like the shared utilities and these components mix in, config, stuff like that. This will hopefully give you a better idea of what I meant by application regions. So like this is an example, if you have, you can set specific regions on your application that essentially all the other views will go into. Like an audio, we probably have a header, a footer. We have like that aside, which is like where our playlists and stuff go and even like the current playing. So we probably have like five different regions for there. As I mentioned, like having an application instance is a great place to store entities and resources that you want globally available to all the other modules. All right, and next up we have the app module. And the app module really contains one or more controllers and all these controllers are built like in the restful style. So you only have like one list, one show, one new controller. Optionally, if we want the app module to be roundable, it would have a router. If not, it wouldn't and that's totally cool. And this is basically where you would actually put all of the handlers. None of the things inside the app module are directly accessible. You have to go through the app module to actually request those objects. So that's where you would put all those definitions. A visual example of this would be if we had users, admin users, dashboard users. Those are three different app modules. And each of these has their own controllers that they're directly responsible for. They're the sole authority of those. And they're not directly accessible. And these things, that module calls in and instantiates those controllers. And the way that that happens is through routing events. Like traditionally we navigate to users or users ID for the show, users new. So that's a way that an event would happen. Users module would instantiate those controllers. Or it could happen through requests and commands that I just talked about. But nevertheless everything goes through the actual app module. Nothing talks directly to those objects within it. So next up we have the controller. And the controller really now is the visual composer. Its sole responsibilities are to all of the views within its scope within the thing that it's supposed to be managing. So let's talk about controller concerns because it's super important. Most of the code that you will write is honestly in the controller. It is very procedural. So it gives life, it creates new views. So that's obviously an instance of a layout. Creates this layout, stores this over here. And it understands view dependencies specifically. So basically it knows that while this view needs this collection or this model, then it would make requests to another area of the system. It would get back that instance and store it. It listens in response to view events. So like in this case, it would be listening. And actually backbone events are traditionally actually mixed into the controller. So here this scope is actually the controller instance. So we're really saying the controller is listening to the layout. Specifically it's show event. And then it's passing in a call-back list users. And basically we're saying, hey, when our layout gets rendered into the page, then we want to actually create a new instance of a collection view and then passing in that collection that we had requested earlier. So this is the mediator, the true mediator where it's dictating where everything goes and all that stuff. So now we have that collection view and that user's collection. Now we have to tell it where to go. So in this case, we want to insert it into the layout's user's region. And so we do all that in the controller. Controller also needs to understand the shared modules, like the components and stuff that exist outside in our system. So this is what I mean by basically like if we have an item view, a regular view that's sitting out here, but we want to decorate it with certain abilities that we've wrapped up in another object, a reusable component. Then the controller would really do that, it would say, all right, we're going to take this view and we're going to give it the abilities of this form. I'm going to mediate between those two different APIs. And so now we've decorated it. And often, sometimes views don't even know they've been decorated, which is exactly the way that you want it. All right, so that's the controller. So back to our view. So now we've taken all of these other application concerns out of the view, which should have never been there. Now all it has to do is just manage one thing. The thing that it's really good at, just managing the template, the DOM. And basically, views are just completely transient. They can be blown away at any time. And so one of the ways that we can handle this is by standardizing its methods and give them like a set that relates specifically to its lifecycle. So this gives us events and methods which articulate exactly where this view is at. So this is like a really natural way of tapping into these events and methods and controlling the behavior of the view and its templates. And it's so just obvious to look at this to know where you would need to put certain view-related code at, specifically to how it affects the DOM. It's a pretty straightforward. So here's an example of what a view should really look like. I mean, there are sometimes just only a couple lines of code. Right there at the very top, we have that mix-in. I'm not really going to go into mix-ins a lot, but this is kind of like a declarative way that when I'm talking about mix-ins, I'm talking about giving them traits and mixing in those traits, and then automatically handling collisions and stuff on methods. But really, like your methods are really just become the places to store view-related behavior in its lifecycle. And it just makes sense. I don't even really have to explain this. So one of the things that would never pass a code review is we should no longer ever be doing this, no longer ever instantiating an entity or a model directly in the view. That's something that should go on the controller and the controller should pass that specifically into the view. Also, this is instantiating it and calling it directly, and that's a terrible idea. So don't ever do something like this. All right. So we talked about the notion of having specialized views. So I've kind of already used them because all of these are connected. But we have an item view, which is typically paired with a model, which basically just has one thing passed in and it doesn't really have a lot of specialized behavior. We have a collection view, which if it's given a collection, it would automatically iterate on all the models in that collection, automatically instantiating other item views. So it basically gives us the ability to create a list, which is what we're doing all the time. Then we have a layout, which the little gray regions on this guy are actual regions and then any view can go inside of there, even other layouts. So you can have layout, layout, layout, collection view, item view, layout, and then just keep going. And it's basically like a Russian doll to where if you close out one view, higher up the chain, it's gonna automatically iterate down and close out all the other ones. It's gonna cascade. So that gives us like how we can automate, clean up and stuff. And it goes all the way back to having like application regions and stuff. If we're wiping out the main region, then every single view that's been composed in there is automatically gonna be cleaned out. So that's really cool. So now really all the view, we're talking about it's being responsible for the template, it's got methods and stuff, but all it's really doing, it's just listening to events that are being emitted from the DOM, whether it's click, blur, submit, focus, whatever else. And then all it's saying is it's not dictating anything off of that. It's basically just saying, hey, this happened. And whatever is listening to it, like the controller, is then responsible for saying, oh, when this event actually happened, then we need to do something in our application. We need to notify another area or call a method on a mall or something like that. So views have been grossly simplified and that's a wonderful thing. They're really just about getting the right properties into the model. And really a lot of these, if you're using a view model, instead of doing that in the view, you could even have this in another testable area of the model if you wanna have custom computed properties and things like that. So there's many different uses here. All right, so we've talked about a lot of things and it's kind of like, wow, this is a lot, oh my God. How would I ever be able to build this? But really if we go to just backplug.out.com, which lists out all the plugins for backbone, really what we're talking about here is marionette, right? It's the number one listed here by the amount of stars on GitHub. And this is pretty much gonna bank in all these specialized objects that we've been talking about. Marionette's very composite, so you get all these nice new toys and stuff, but you're not forced to use all of them. It's all, they're all completely split up for one another, which is really cool.  So all the things that I've been talking about are ways to use these objects and stuff with a couple extra things like components and everything. All right, so let's talk about this messaging bus in depth. So we all completely understand what it is I'm talking about. So we have this situation here where we have a controller needs to reach out into another area of the system and it needs to get back a new instance of a user's collection. So what's actually really happening is something like this, right? We have, like this is just like a diagram of our model. We have our app modules on the left, so like users or nodes. And then like the controllers list show new, list and new, and then entities, which is part of like our shared utilities way over here. So what we wanna do is something like this. That's why it doesn't make sense to call these directly. And it doesn't make sense to store those inside of just that one module when user entities could be used by anything. But we have this notion of this new messaging bus which gives us the ability to do this, to be able to indirectly call something. And this is actually a really incredibly powerful concept. So I wanna give you an example here. The code on the top is like actually from our list controller. The code on the bottom is, it would be like the actual implementation of our user class. So right here in our initialized method inside of our controller, which isn't really that important, that's incidental. Well, right here we're actually requesting the user's instance. And so at the bottom, what we have is we actually have the handler for that defined right in the entities module. And this is the thing that basically you're creating like an interface too. Like it's responsible for understanding like what this command is. And it's responsible for understanding the implementation of the classes. If you actually look at this closely, we've written this very cleverly. We actually haven't exposed the user's class or the user's collection class publicly. Like these are actually not accessible to be called directly. But by adding the handler in line here, then this is in scope to the handler. So it's able to actually know what you want and be able to call into the classes and stuff and manage them. And this is like exactly what you want. So you can just change your hand alerts or you can change the implementation details of your classes by having to update any other aspect of your page. So these are completely decoupled, right? So what we've ended up creating is basically like an interface around all of our other objects. And everything has to go through this like standard way of requesting instances or commands, things like that through the system. And this is basically given to us by this application instance. In fact, all of these commands are actually set on it. They're registered. All right. So let's talk about folder organization because I can see maybe this is probably a little confusing, still a little abstract, kind of throwing a lot of things out here. This is kind of where it all comes together. So we have this folder organization, typically a root backbone folder. We have the app.js file. This is where you would define that application instance. This is where you would start up your, I'm sorry, you would start it up like in the server, but this is basically where you'd set up like all of the application instance stuff right there. And then you'd have like this apps directory. And the apps directory is where all of your working like app modules and stuff go into. So all the user facing things. Then everything else are just like siblings. And those are all the shared like utilities, config entity components, mixins, maybe base classes. It's usually smart.  So all that would be stored there. So let's pull out this apps folder for a second and look at it in regards to Ardio. So Ardio would probably have like these apps folders for playlists, playlists, songs, album, album, comments, currently playing. So what I wanna focus on are these three, playlists, playlists, songs, and currently playing. So let's look at, see how these work together. So we're here where like on the settings page, right? But what I'm looking at right here is this playlist module. So this is a playlist app module list controller. So that's where the playlist dot list comes from because all that this thing is doing is just iterating on a collection of playlists and listing them out, right? So now, what if we want to create a new playlist?  Well, so this would be the new controller for the playlist and this would be responsible for putting this view together, probably pulling a component for the form. So we have like all the shared form component behavior. So that's what this is. So that's an example of how you'd have a new controller for that, right? So we'll keep going. So now I'll look at like actually clicking an item in our playlist, so we'll click pink load again, right? And so now this page is the actual playlist dot show because why we're showing one model in that collection. And specifically that's what I'm talking about. These are like the additional details for showing just one entity in a collection. And of course we have an edit button, right? So really the same situation here, dialogue pops up. Now this is the playlist dot edit. So all of these are independent but they're connected. They're connected to this like one like ultimate resource which is the playlist, the app model. And then really like the complicated thing here that's fun to explain and kind of like the Eureka moment for a lot of developers is really like this list. Like we have this secondary list that's kind of part of this playlist and what this is is basically you have a collection of playlists, you have models on each one and then this is an example of a nested collection within those. And so we've already defined our playlist dot list and this forces us to now instead break this out into a second module. And the context is playlist but this would be like playlist song. So this other area of the page is in a completely different module. They're just visually orchestrated together. And now this list, this playlist songs out list still just is dealing with one collection. It's only ever dealing with like a top-level collection. And if you have nested stuff, you just break it out. So I mean, it like literally works perfectly. So just the last one here, we have like the current playing dot show. That's what this would be, right? Cause it's showing one song that you're currently playing. And if we click to expand this, you know, now we have like a whole list of things that would just be the current playing dot list controller in that module. So all of these things like really, really work completely well together. In fact, I haven't come across a single situation where you cannot just break everything out into these. So just to show you, so now we've kind of gone back to our folder structure and now like our top-level route now is like app. So we kind of like drilled into that. And so like these three things would be the different app modules, right? And specifically these files are the app module definition. So that's where their router would have been stored. If they're routable, that's where like, how they instantiate the controllers is stored and like handlers for accessing those controllers is stored in there. And then all these folders just contain the controllers, the views and the templates specifically to like what I just showed. So like play list, list show, edit new, play those songs, just the list right there and currently playing. And you would have used like app commands and stuff, for the playlist to communicate with playlist songs, it would have had to have shared like a region of its layout and it probably would have used a command there to basically give access to that region and it would have passed it in that local instance for the layout stuff. So all these things really can be perfectly like coordinate together. So there's a lot of things like we haven't talked about today but hopefully this is kind of like a step in the right direction towards architecting your application. These patterns have worked extremely well for me. So that's it. Anyone have questions? Yes, we do. How do you connect all the views and modules and models and your application? Do you use like requireJS? That's, there's a lot of different ways that you can do it. You can use commaJS models, requireJS. You can just use lightweight modules that come with marionette. That's kind of like incidental. Like as long as you can bundle them up however you want and load them in whenever you want, as long as those handlers and stuff are defined when they're supposed to be defined, then everything will work as is. So that's kind of like that doesn't matter but I've used all three essentially. We have a Rails app. So we use like the asset pipeline which basically handles like the load order of the modules and I actually use headJS rather than requireJS without all the overhead to basically dynamically pull in entire modules when like routing events happen. So when a routing events hits, it will actually pull in like all the module level code. So the UI is only ever pulling in like what you've actually navigated to. Hey, Brian, you said data binding is from hell. Can you just elaborate on that just a little bit? Well, so I guess, you know, it's kind of like always like the whiz bang demo of like, oh, this framework is amazing. Let's just use data binding like, let's just use it everywhere. Why wouldn't it make sense? And you know what I've seen is just like, when we're talking about really granular control of our application, like you can't just like throw data binding at it and expect like everything to just like fall into place whatever you usually need a lot more sophisticated level of control. And I mean, I've used data binding. I can't say like plenty because usually like if you're, if you like architecturally split everything out like into little views and stuff, you really don't, you know, it's usually mostly used like when you have like a massive view and you have so many different concerns, you need to use data binding to basically like go in and only update one part of the page. But if you split everything out into smaller views anyway then you can just kind of like, just tell a view to re-render. So it's almost kind of like to me, it's like a, you know, a giant hammer and it has its use cases, but it's very specific. It's not like an all purpose tool at all. Hey, Ryan, how do you handle with the Marriott modules the automatic starting and stopping if you have multiple modules and you don't know which one might be handling just like something else and you don't necessarily know at the outset what modules currently open. Right, right. There any pattern for that that's kind of prevalent? All right, so I think, I think that question really is actually two concerns. There's the actual technical startup and shutdown of modules, which modules in Marriott, Marriott app modules specifically have the ability to be started up and stopped. And then you can have like events and stuff injected into windows happen. By default, they're started. And to me, honestly, I haven't had a lot of use out of just stopping them. But I think really what you're asking the second concern of your question is just like how do you orchestrate visually like, you know, a module coming in and like eradicating like the previous view and doing a knock like their technical startup and shutdown. And that's really just comes down to like the application regions. I mean, the clever way that Marionette has figured this out is basically views get blown out by other views. And so if you insert, you know, if we have a navigation like users and dashboard or whatever, and we click between dashboard and we then we click to users, the main region is gonna get blown out from the previous one and the new one's gonna come in. The way that I do it is I basically work off of those close events. So like my controllers bind to a top level layout. And those controllers listen to the layouts close event. And therefore I know that basically that this has gone away and I know it to do shutdown and stuff. So it's kind of like in reverse. We actually know, we have a system, a mechanism for knowing when views are closing down. And from there I listen those cascade all the way up. And then so that's how I would do it. Thanks for the talk. I just had a question about maybe reusing views in the directory structure you showed. It looked like they were quite specific to the app section. But in the demo, like the playlist track listing there, very similar to now playing track listing. Yep. How would you structure those things so you're not copying the case? Right, so it's not, I think that's more of a question of, I wouldn't like reuse the view instance. I would reuse the view behavior. And the behavior can be composed like in traits, like in mix-ins that you basically mix into all of your views or you break out the shared behavior view into a component.  So it doesn't, the instances don't matter. You don't have to keep up with those. You don't have to manage the state of those. We just have to take out and extract what they're really doing and then compose those or mix those in. So like gang of four, you know, like composition over inheritance.


Good morning, I'm Salvo Bonina, an application engineer at the Steam Mikroelectronics. I'm part of the IoT Excellence Center, based in Santa Clara, California. Today I'd like to welcome you to our booth at the Sensor Expo 2016, where we are showcasing the connectivity solution for the Smart CD and the Smart Tom applications. So let's start with the Smart CD, where we are focusing on the 6-Lopin machine networking, based on our sub-gigahertz transceiver, the SP1, and where the Contiki stack runs on our low-power microcontrollers. The Contiki 6-Lopin can address big network topology or wireless sensor nodes with low bandwidth and long range needs. So with this demo, we want to demonstrate the possible scenario of the Smart CD, where all the nodes are connected together and communicated with a remote server in the cloud. So the remote server will be based on this computer. The Internet-Owned Activity is based on our Wi-Fi module that will connect to the Internet, so it will bridge our wireless sensor network to the Internet. The web application running on the remote server allows to monitor all the nodes that we have in our network. So more specifically, we have three nodes here that simulate the Smart Parking, based on our proximity sensor, so that we can detect the position, the presence of the car, and to learn automatically the lights. Then we have two weather sessions based on our sensor to monitor the environmental data. Then we have another nodes, which is the garbage collector, still based on the proximity sensor, so that we can imagine to call automatically the service when the garbage collector gets full. Another node here is based on our low-power accelerometer, so we can detect the vibration caused by the earthquake in a building and call automatically the owner. So the entire demo is developed using the CN32ODE, which means Open Development Environment, which is the ST ecosystem for the Internet of Things. It is a completely free-of-charge platform that is available on our website. On this side we have the Smart Tom, based on the Brutal Energy Connectivity. We still have a Wi-Fi Gateway here in order to upload this data to a remote web server, and with this demo we are using our partner, which is IBM, so we are publishing the data to the IBM web service. Thank you for your attention and interest on the ST Connectivity solution. For more information, just visit our website at st.com.


Finding answers instead of another one to blame Negative thoughts are raised back to where they came You can do it, you can do it, you got everything that came Traces of my grandmother etched in my brain That kind of loss will make you go insane But I go through it, nothing's impossible Just do what you got to do the first steps The hardest after that thing not stopping you The motivation had a lighter How was the flame you added to the fire? Reaching for the things that I desire If you aspire to take it higher than your passion But I'm still staying focused The way to hate a swarm, somebody like a pack of lotus I tell them no, that's when life can be demanded But then I look down and I see I'm still standing up I used to be in situations where I'd freeze Man, I mean I was stiffer than a manic And my best friends were telling me to breathe And if it's not for you then you should think about your family Lisa's looking after me five but like a tambourine When I'm like a sampleine Construction that is of my wheelbase The rabbit plate We are building a new base We are building a new wheelbase here We are just basically using some exterior four inch screws Some lag bolts for seat sliders We have two five foot sections Two by four A bunch of 18 inch sections of two by fours And some two by sixes for upwards angles So we're going to be building a new base So I'm going to go through kind of the steps on how I'm building it And give you guys an idea of the new base The new setup with seat sliders and everything That we're going to be doing So I'm going to get the plans Show you guys quick rough drawing of it And then now we'll get to building it So this is kind of the rough idea of what we're doing It's a very simple style design Very rough sketch Of course we're going to have another bar going down from here to here For support and stuff like that So basically we're going to build the base And then I'll kind of explain it after I put it together And then I'll go step by step Explaining all the ins and outs about it And everything that you would need Other than screws, screwdriver and drill And wood Because we're building this out of wood We're probably either going to stain it, wood burn it, paint it Not sure we're just going to get it assembled first And then we're going to get everything all hooked back up So we can get back to slime Alright so we got the base pretty much put together We just added our 18 inch section in between Our two 5 foot and two 18 inch flats That are flipped sideways so that we can actually mount Our Corbeau seat sliders Which will go straight to our energy innovation seat So we're going to get these mounted in And get the seat set up And then work on the upper brace For the actual wheel and pedal placement And stuff like that Alright so we got the NRG seat Mounted onto our base With our seat sliders So now we have movement Back and forward for shorter drivers Now we're working on pedal placement And the simple pedal placement We're doing floor mount pedals So I'm going to be using Some more 18 inch pieces And putting them at an angle So that I can raise the pedals up at an angle And screwing them down Onto those And then probably putting a board underneath So it's not sitting on the ground That's what we're doing for the pedals So I'm going to get them mounted up And angled up And then I will come back to you guys Show you guys exactly how I did it And we'll go from there NRG seat Nice seat sliders So now we got Full movement In our seat forward and back So we're good to go Alright so we got pedals mounted At an angle based We basically took two more Two by fours And screwed them right in 18 inches long Just like that crossbar and everything Mounted the bottom one Lower to the ground Screwed it in on the sides And now the other one A little bit angled up To give the pedals a little bit of an arc For the floor mount pedals So the Fandatech pedals are all mounted Seats all mounted Sliders good to go Next is to get our Wheel base mounted up So we're going to have to Basically mount that to our crossbar first And then we're taking Two by sixes and doing an angle To give us that angle part To mount the base on there So you have leg room to sweep in Of course we'll put a brace on there too So we're going to go with the next step We're going to get that thing mounted up And we're going to continue this project So just like I said A quick overview Bases all together Two by fours Two by fours on the seat sliders And on the pedal mounts For floor mount pedals And we're going to go to the next step Which is getting this Wheel mounted This time consuming part Is getting the angle right And the feel of where I want it to sit But we're going to go through that And we will continue this build On our new sim base With our energy seats And we're going to go with that Alright so we've got Angle pieces mounted At a degree that I felt was Comfortable for my wheel base They're not going to be this long These are going to get cut down Once I actually set the base In between where I want it to be With my knees And then that will What will hold it up This will be like I said A lot shorter To get in And you don't have to worry about that I may have to angle it up A little bit higher So that it's Not as small of a V here But this is the trial and error Where I got to Kind of change the angle of things And figure out where it fits So we're going to keep going Figure out where I want to put it at And then go over there Alright so we made A good amount of progress on it Just to show you what I did I did two by sixes Screwed down on the bottom Angled upwards And then a two by six across Just screwed in two sides For the wheel to mount on to And it is angled backwards So I don't have to use the riser So the wheel is sitting How I want it to sit The hardest part of I believe this build is to get The angling of this two by six Where you want it in proportion to You know your seating placement So this is how we have it set Now we have two braces here Keep it from Making it a little more sturdy But it actually works really well So this was the basic design We're going to do a little bit more work to it But this is the hardest part Is getting the angle for these Up braces for the wheel base Basically you just want to put one screw in there And kind of move it up and down Sitting in there trying to get it Where you want it just moving up and down You might need a second hand to do it But so far this is What the base looks like as of the moment We're going to keep working on it And I'll show you guys more Once I get more built into it All right so we got all the Fanatec stuff finally mounted up On to it kind of in position where I want it We get the handbrake right up top by the wheel Shifted down the bottom on basically A little console nothing major Just out a one by six and some Two by six is up against it Screwed to the whole base So just a quick overview We had our base which is 18 inches wide By five inches long Or five inches five feet long And then this The angle parts are going to be different height Based on your position Where you want it to have Seating position and angle and all that So these will be Whatever length you feel fit comfortable For you and we just have a Fanatec mount You can mount any type of wheel there G920 clamp it on there Whatever G29 whatever you have And we did some angle bracing To keep it from sagging up and down And of course we have our pedals mounted Which you can mount other pedals This way as well So basically this is the new sim base I do have to Now take all the Hardware and Fanatec stuff off it To finalize it with Staining it and maybe doing Some custom work on it Well not myself my buddy And then do wire You know wire tucking And making all the wire nice and clean And hiding it on there Which I had ordered Which I'll show you guys in another video Of course once I finalize this whole thing But I just wanted to bring this video to you guys To show you guys on the new base How I built it So you guys can build your own base like this If you want very solid, very sturdy Super excited about it Can't wait to get sideways on it But that's going to be another video So I hope you guys enjoyed it Make sure you tap that like button Subscribe I do appreciate all the support The Graham links and everything down there below So as always We will rabbit, I'll see you guys On the next one


Welcome back viewers. Got a couple things here to disassemble and of course their sealed objects. Got a filter dryer which came out of a ice machine. If you talk to Manitowoc they'll tell you that their dryer is better than a standard dryer because they have a screen in there to protect any backwash if you want to call it that when it goes into a harvest. We're going to cut it apart and see if there's any truth to that and then I have a TXV here that went bad, had real high super heat and high subcooling. It would not work in the heat mode. It was a heat pump slash geothermal. I've replaced quite a few of these. We're going to see how it looks on the inside. You can see the screen doesn't look very good. I actually cut it out of the system. I didn't sweat it out. I don't think that happened on trip home. I turned it back to the truck. A good grief that looks like it's all the way around. And then we got a reversing valve. This is a little bitty one. I think enough you can stick your whole freaking thumb in there. It's an inch and an eighth I think or inch and three eighths one or the other. But we're going to split that puppy down the side and take a look inside of it. I've got to be honest I've never really split a TXV open like this before. Usually I like to take them apart and take a look inside when you can unbolt them. This one was not able to be done that way. You can see the plates right there on the left hand side where that's the diaphragm and that pushes in there against the piston there. That right there is a spring.  I'm going to say that screen was pretty nasty.  Well if you know or heard at one point Copeland had some issues with some oil that they put in the compressors. Now they claim that a lot of these aren't affected by it. But it was an oil that was made to keep the compressor from rusting while it was setting around to be used for manufacturing. Well it ended up having some ill effects once they got the POE oil in there. And it seems like I've got a lot of these TXVs that get gummed up. And don't know for certain if this was one of them that was affected by it. But I've seen this happen over and over again. Now obviously some of this garbage in here is going to be from cutting it with the grinder. Yeah you can see that crud is in that screen. Problem is it was not serviceable. Can't take it apart to clean it. So you're going to replace the whole thing when you're doing it. These are the springs. Push back up on the diaphragm. Right there. And that's your port. Its job is to equalize it out and the unit shuts off. Gotta admit this is the first one I've had like this. The little bulb there is definitely a little odd. Normally it's like a pin. There's the whole number on the valve. Just cut apart the Dan Foss. There's the felt. It goes up against the screen. You can see it comes in. Okay I'm just tearing the living snot out of this thing. You can see what the desk it looks like which I'm sure quite a few have seen. I'm going to keep on busting this thing out of there. And lucky they're felt on the other side. So they weren't kidding. They actually have felt on both sides. Yep. Got a fine mesh screen there. That is the outgoing side. Get the felt there. Then you had the desk in after behind it. And had the felt on the other side which was that piece right there. I do know that the Sporlin basic Sporlins do not have that felt on both sides. Okay. And now we have the reversing valve. That one's going to be a little more interesting. You can see the U-bend in there. That's a big ol' burger. This is on that. I know it was 30 ton unit so it was 15 ton a piece. Yeah I'm going to see if I can't split it down down the side here and then down the other side. Tell you what guys it makes a heck of a mess. Not real.  But got her apart. Check that out. I think that fancy orange hog snot. Hell yeah. So you've already seen these I'm sure cut apart on a picture diagram. But here is the tubes that shift back and forth. It blows the refrigerant one side or the other. It slides back and forth. Which this one was stuck. It's kind of like a metal. That's a rubber. It's got a rubber feel to it. And here's the little diverter just loops it in over. So that's what you got. Now this don't look too good. Check that out. I would say that this right here was supposed to have probably white plastic all the way around it. That don't look good. I would say that's probably some of the reason why it might have failed. I could be crazy but I don't look good. And this piece here stays stationary as you can probably imagine. You see right there is a little port. And the other port should be right there. There it is. There's that port. So basically depending on how this little burger here shifts, it's basically a miniature version of what the big part is. It shifts this way or that way. And it directs the flow from here to there. That's what your solenoid does when it's on there. That piece there should come out. Here's the other half of that piece. Okay I pulled that piece out and you can see right there it went down in that area there. That right there basically shifting back and forth just like the big part. Real scientific I know. You can see where she's been rubbing back and forth. I love shack of NEM. Yes. Well what did we find out? Well we found out our screen was plugged up for whatever reason for material of some sort. Did it in. It's not serviceable. Luckily the new one is able to be taken apart.  How was I to know?  And um yes there is a difference in the dryer the way it's built. I mean Mexico. So there is a difference in the dryers. They're not crazy just wanting to sell you their dryer. Go figure. And then there was a thermostat here. There was word that it might have been sticking. We can pop it apart. Ain't a whole heck of a lot to that. You can check contact points on it. What the heck. Let's tear it apart. Okay now we got this part coming apart. If you noticed it's basically got spring mechanisms in there. That kind of makes click on and off of your switch mechanism there. Now you can see right there looks like it's got a little burnt. And the contact points don't look really good. There it might make a little better. You can see where it's been arcing on that piece right there. Contact points are inside there. Let's pull them out of there. And there's contact points. Now I didn't condemn the switch so I was kind of curious whether it was really a problem or not because it was running when I got there. And there's a couple other things I found too but that definitely it's not good. You can see how that could stick on or possibly not make contact. But you got all the amperage of the compressor going through these little dinky contact points which is why a lot of them are now using isolation relays. So you're not putting all the amperage on the little dinky switch. And the only thing we haven't cut apart is that TXV bulb. So let's go ahead and take a peek at that and then we'll wrap this up. All right, that's kind of interesting. Got the bulb open. It looks to me like there's some sort of felt in there. Let's see if we can pull that out of there. Let me tore it apart. That is a piece of felt. It does smell a little funny. But it really ain't nothing in there but a big old chamber with that felt thing in there probably because it's liquid refrigerant I'm sure of some sort. They never have told us exactly what it is as far as I know. But that's what's inside there. A lot of times what I'll do is I'll cut the sensing bulb just to see if it was dead when I'm done. Just to kind of see, you know, was it the bulb that went bad? Was it the piston stock? Was it something else? Who knows. But there's our little miss. And yes, we did wear not only safety glasses but we wore a shield. I wear mine like that. Anyway, I got the hard hat and the safety glasses and I can take that off if I don't need it. Can't show you the other side because I don't want you to see any names. We're in the witness relocation program right now. And yes, that's my cheap junk grinder for at the house. My DeWalt and Bosch are on the truck. I didn't feel like using battery operated when I had outlet set in there.


Okay, so lots of people keep asking me how to make baby food. And now that I'm well rested and showered and my baby is like feeding himself with his hands, now I finally have the time to sit down and tell you what mistakes you should avoid when you're trying to make baby food in a Vitamix. One mistake people make is trying to add several ingredients all at once. Your baby needs to try one thing at a time to test for allergies. So make one ingredient blends and then you can always add those blends together later. The second thing is you don't want to make too much. Your baby is only going to eat purees for a few months. Ours ate purees probably for two or three months and then he was over it. He wanted more solid food. So I have a freezer full of frozen food that he's really not that interested anymore. So don't make too much when you first start. There's lots of different ways to prepare fruits and vegetables, especially if you know how to cook, you're a good cook, but for babies you really just want to steam them. So don't make the mistake of making some crazy preparation, just simple steaming that keeps most of the nutrients in. That's the way you want to go. Stick with a really smooth texture at the beginning. You don't want any chunks. I personally made this mistake with our baby. You want everything to be as smooth as possible at the beginning.  So if you're trying to give them a chewy applesauce mixture, they're not going to like it. It's weird. So as smooth as you possibly can, I even went further than like a baby food that you would buy at a store and made it as liquidy as possible at first. That really helped him kind of transition from breast milk to purees. With that being said, I added breast milk or formula if you want to the actual puree. That way, when he's tasting peas for the first time, he's also got kind of a familiar flavor, which is my milk, as kind of the background of that food. So it's something he's familiar with. It's more likely that he'll take it that way. Once you steam and blend your puree, the best and easiest thing to do is to put it into small ice cube trays. So I made the mistake of putting my purees into a traditional ice cube tray. First off, really hard to get out. Second off, way too big of servings for a four, six, eight month old. So I used the tiny silicone trays that you can pop out. I started with one cube, then he started eating two, then he started eating three. But the best thing to do is to freeze everything into tiny servings. And then you're going to pop those servings out the night before and let them just defrost in the refrigerator. That's the easiest way. So I would make a blend, keep a little in the fridge for that day and maybe the next day freeze the rest and then the night before pop a few out and defrost in the fridge. So when I put them in the fridge, I made the mistake at first of figuring I would just remember what I made. I didn't. I'm tired. I have a new baby and lots of fruits and vegetables are green. So I started labeling my freezer bags, peas. I made these in April, mid-April, whatever it is, so that I know what they actually are because eventually I'm going to start mixing those. I'm going to mix peas and pears. And so I want to know when I made them and what they are. The reason I want to know when I made them is that they only really last for about three months in your freezer. So you might make the mistake of thinking, oh, they're frozen. They're going to last forever. They kind of start to lose their nutrients and start to taste like freezer burn. So three months is about the amount of time your kid's going to want to eat a puree anyway. So it's a pretty good amount of time to freeze. So you might make the mistake of not taking them out of the freezer the night before, like every parent does. If that's the case, take them out, set them on the counter. And what I did is I put them in a little glass tray and I put hot water in a bowl under it. And it kind of re-steamed those frozen little nuggets. So in a glass jar, in a bowl filled with hot water, and it took probably five, six minutes for them to defrost like that. And if your baby is screaming and starving, it's okay to throw them in the microwave if you need to. Yes, the microwave makes them lose some nutrients, but just having food and some sort of sustenance is sometimes more important than having full nutritional palate available. Microwave it if you have to. Something I was told when I first started making baby food is that you should keep trying. Leni's sister Alana told me this, just keep trying because your baby might not like something 10 times and then on the 11th try, really likes it. This definitely happened with our kid. I gave him oatmeal over and over and over and over. Didn't like it, didn't like it, didn't like it, and then one day he just liked it and now it's kind of a staple of his diet. So just keep trying. They don't really know what they like yet. They're just kind of trying to figure it out. You're going to want to use the most fresh and seasonal ingredients you can.  The more in season it is, the fresher it is, the more nutrients your child is going to get, but also it's a really good way to kind of challenge yourself to eat healthier too. You're not going to go to the farmer's market and pick up a bunch of fresh produce for your baby, steam it, blend it, and then go through the McDonald's drive-through. You're going to want to make yourself a fresh healthy salad or a fresh healthy soup because you're already doing the work of steaming some asparagus. You might as well have some asparagus for dinner too. One of the major, major benefits of making your own baby food is a cost savings. So you might figure, oh, okay, these packets, these pre-made packets are only about $1.50 each.  So save yourself the money by making your own. Now don't make the mistake of buying a single-use appliance like a baby food maker. I'm sorry, these are silly. All these do is make baby food, which means unless you're going to have 15 kids, which God bless you, there's just no reason to have an appliance for one thing. The reason I have a Vitamix on my counter and that it lives on my counter is that it does everything. It makes my smoothies, my green juice, my soups, it does my chopping, it makes my baby food, makes my dressing, it makes my ice cream. It does everything and that's why it lives on my counter. You don't want to go buy a $50, $75, $150 appliance that's only going to be used for three months. I see these baby food makers on sale, used on all of the different platforms, almost always they say used a couple of times. If the larger container seems daunting to you using it for baby food, you can always grab the eight ounce cup. So that's this accessory, an eight ounce cup. I use this exclusively to make baby food because it's just the perfect size. So it comes with its own little blending adapter set here. The one trick with using this particular accessory is that you have to use enough liquid because obviously you can't use your Vitamix tamper. And once you're done making baby food in it, now you can use this to grind spices, to grind your coffee in the morning. I use this weekly, I would say, to make dressings. I don't want to make 48 ounces of dressing. So I use my eight ounce container to make dressing all the time. So quick note, this eight ounce container is only compatible with the Ascent Series models. So if you've got an Ascent Series, this will work perfectly. If you've got one of the older generation models, then you can still do this with the 20 ounce cup and the cup adapter set. It's obviously the same concept. It's the 20 ounce instead of an eight ounce, much more compatible when you're making baby food. And then you can use it for your to go smoothies. I really, really wanted to be an overachiever when it came to making my own baby food, partly because I knew you were going to expect a video like this from me. One thing that I learned is that my kid does not need to try every single fruit and vegetable. It's okay. My dog's barking. Hi Lucy. It's okay if he doesn't like papaya. That's okay. A lot of adults have never tried papaya. I needed to find enough things that he liked so that he was getting the rainbow, but without going overboard. So I really wanted to make sure that his palate was getting expanded, that he was being introduced to a lot of different things and that I was ruling out allergies. That was really important to me, but I did not need to feed him everything under the sun. With that said, once you start making some peas and pears and applesauce and Brussels sprouts and broccoli, you're going to be making all of those individually. Eventually you're going to want to mix and match. You can mix oats and bananas. You can mix peas and pears, which I already said. You can do sweet potato and carrot. Those are simple blends that you can put together. While you're doing that, it does not hurt to throw some herbs, some seasoning, some spice in there for them. So I don't want to eat plain oatmeal, do you? I put some cinnamon in there for him and that makes it tastier for him and also kind of introduces him to a new flavor. So when I did sweet potatoes, I made sure it wasn't allergic. Then I added a little bit of thyme. Then I tried a little bit of rosemary and that really helps them kind of get interested in an array of flavors. I think that kind of worked. He's 16 months old now and he really, really likes flavorful food. One of his favorite things is when I make chickpea and cauliflower curry for dinner. So it worked. I cooked dinner most nights. Even when I was exhausted with a newer baby, I still tried to make dinner a few times a week. When I'm making dinner for Lenny and I, the easiest thing to do is to pull aside some of the fruits and vegetables that I'm using for our dinner and just use those for baby food. I don't need to grocery shop specifically for, okay, I need broccoli and Brussels sprouts so that my baby can try those this week. They were part of my meal plan already for us to eat as adults and I just pulled some aside, steamed and blended those so that my kid could try them. With that said, I did a lot of that and I had a freezer full of stuff that my kid was kind of over at a certain point. Like I said, they last three months, but he was kind of over eating purees before that. So another trick that you can use is to throw those cubes of baby food back into your own smoothie. So I had a lot of sweet potato cubes that I would just throw back into my morning smoothie and that's a way to not be wasteful. Also, there are some baby foods that you don't need to blend up in your high powered Vitamix blender. We do a lot or did a lot of just bringing a banana with us. You can mash a banana with a fork wherever you are and that's a puree. Same thing with avocado.  All wrapped up, throw them in your diaper bag, grab a spoon and can I just make a suggestion and I am not a nutritionist and I am not a pediatrician. But introducing kids to high allergy foods the younger they are, I think at this point has been pretty proven correct. So give them peanut butter. Just make sure with every food that you're trying that you're really watching them closely. That's why they say give them three days, let them try it, have a reaction if they have the reaction and then you can really narrow down what it is. If you're on the fence about starting to make baby food by yourself, they say about four months, four to six months is when they start eating purees, start. If your baby is showing any interest in eating food, start. For us it made a really big difference with him sleeping through the night. He felt full, he didn't wake up for feedings, that maybe an old wives tale, they may not be connected at all, but it really felt like it worked for us. So start doing it as long as they're showing some interest, they can hold their head up, do it. If you do not have time to make your own baby food, you are not a bad parent. Go ahead and buy it at the store. That is okay. If you do have the time, if you have one Sunday where you can steam some stuff and you can throw it in the freezer, great. You can do a lot in a little bit of time. This isn't a complicated recipe with a bunch of different ingredients and steps. It really is buying produce, washing produce, steaming produce, blending produce, freezing produce. You can do all of that really quickly. It does not make you a bad parent if you don't do that. And if you're making your own baby food, you can supplement with store-bought baby food. We do this for a living and you will find baby food packets in our pantry. Sometimes you just need something quick. That's okay. A lot of my friends that are having babies lately text me and say, I want to start making baby food, give me all your tips and tricks. And I do and I share those things then I check in a couple of weeks later and I say, did you do it? And they say, no, not yet, I'm waiting. There is no right time. You're tired, you're busy. Just set aside a half hour and do it. It's important. Your kid wants to start. Do it. They'll love it. So with all that being said, here's the first five things that you should make for your baby. Oatmeal, cook some oatmeal, add some breast milk or formula or nut milk of your choice. Sweet potatoes, steam some sweet potatoes, blend them on up with some sort of liquid. Once you know they're not allergic, add some spices to them. Pears, really easy. With pears, I would still steam them. Remember that your kid doesn't have the digestion that you have, so steaming them helps them break those things down. Peas are an excellent one. They're sweet naturally, so kids like them. They're also packed full of protein. Pea protein is like the new big thing and you can get them any season in the freezer section. And carrots are something that kids almost always love. The only thing with carrots is they take longer to steam than the other vegetables do. One of the biggest complaints of parents that make their own baby food is that it's a little bit more messy. That is true.  That is totally true.   To me, it was worth it to not have to worry about additives and preservatives and all of that to wash a few extra dishes. You just have to agree that that's going to be annoying.  That is so, so fun to see. And it didn't take that much work. So if you appreciate videos like this, if you like hearing how to make baby food in your Vitamix, hit the thumbs up on this video. Definitely subscribe to our channel if you haven't already. And thanks so much for watching. See you next time. What if you have to feed your adult baby and blend all your food too?


Hey guys welcome to SSUnitex to see this side and this is continuation of Power BI tutorial. So today we are going to discuss matrix visualization in the Power BI. So this is very important visualization in the Power BI by which we can see the detailed information as well as the summarized information in the same page. So how we can use this let's go to on the Power BI desktop and we will see in the practical. So this is our project by which currently we are working on. So first of all let me use the matrix. So we can click on this and let me try to make it bigger. So here as we have already created the hierarchies. So I am going to delete that one and try to create the new one. So that will be helpful for you guys. So I have created two hierarchies. So let me delete the second one as well and here now we don't have any hierarchy. So first we want to create the hierarchy for country name then city then postal code. So we need to drag and drop the city to the country name. So it will create the hierarchy. So here you can see the country name and city. We want to drag and drop the postal code. So postal code can be dropped in this hierarchy which we have created. So now you can see country name, city and postal code which we have created. Now let me try to drag and drop in the rows. So here we can see we are having Australia. If we expand that then we will see all these cities which belongs to the Australia and if we expand then we will see the postal code for that. So this is the rows data. Now in the columns we want to see the data as per the order date. So we can drag and drop the order date right here. So here it by default has the hierarchy for the year quarter month and day. So that is fine and in the values let me try to drag and drop the order quantity and it should be some so it is already some so that is good. Now you can see we are having this matrix. Let me try to little bit format this. So go to on the format and here go to on the style. We can choose any style which we want. So this might be good. Now go to on the grid and try to make the font size bigger so we can do that. So this is the font size that is enough I guess. So now here you can see we are having all the countries so let me try to expand that. So here you can see the cities if we will expand then we can see the postal code. Here the order quantities for the cities and postal code and country that displaying over here. So this is how we can drill down from the rows. Here we can see in the columns it is displaying the year but we want to drill down up to day. So how we can do that. So first of all we have to select that visualization that is matrix. Here you can see drill on. So here we need to select the columns. Now we need to select this drill down option. Now here we can press the control and click on this. So it will have the data for quarter 2 quarter 3 and quarter 4. Now let me click on the quarter 3. So it will have the months like July August and September. Let me try to click on the July. So this time we will have all the days so we can see 1 2 3 up to 31st. So this is that we can drill down from columns as well. So go to on the first level. So this is the first level. Now if we don't want to see the quarterly data we just want to see the data for month and year. So how we can do that. So for that go to on the fields and here in the hierarchy we can delete anything like we don't want to see the data for the quarter. So we can delete the quarter. Now here we can see the days. So we don't want to see the data for days so we can also delete that. Now let me try one more time. So here we have this year and here we can see all these months. If we click any month then it will not further drill down. Next here it has only order quantity. If we want to see the data for other quantity with the values so how we can do that. Here let me try to drag and drop the second that will be the I guess sub-total. So let me try to drag and drop in the values. So here it will have two columns. First is the order quantity and second will have the sub-total. We can add a number of columns as per our requirement. So here I am very happy to use only these two columns. So here we have years. Now let me click on this. So here months and again it is having two columns for the order quantity and sub-totals. So this is in the matrix and if you have any doubt then you can drop your question in the comment box so I will try to answer on your questions. So thank you so much guys for watching this video. If you like this video please subscribe our channel to get many more videos. Don't forget to press the bell icon to get the notification of our newly uploaded videos. Thank you so much.


What's going on guys welcome back to the channel critical overload here So we're talking about Christina Carpeter in this video here again today and going over a way her reveal could still be shocking despite Many people in the fandom expecting that outcome in screen 7 So obviously her being the killer can be done But for a lot of people it would need to be done in a shocking way And I think you can do that despite a lot of people expecting her to possibly be the killer To preface this I want to say you can swap out characters if you'd like to for certain aspects of this story But Christina of course is someone that again many people within the fandom Wouldn't find shocking if she's revealed to be ghostface as with anyone you wouldn't find it shocking unless You successfully sell your audience on that person being a victim or a target depending on how far they make it So for Christina, I'm going to have her run the gauntlet Effectively establish her as someone who can't be the killer because she'd be attacked on screen by ghostface Ghostface would appear during instances where it can't possibly be Christina So you want to actively continue to just plant those seeds of doubt in the viewer's head as they are watching screen 7 And I just keep that up the whole movie until the finale when Christina Sam Sydney Gale possibly Tara are cornered by ghostface for the inevitable reveal Then as you were leading up to it. It's so undeniably Fact it like it's so undeniable undeniably evident that Christina isn't the killer because you've set up so much prior That renders her not a possibility anymore. That's how you sell your audience on it So here's where you would go from there in my finale Christina would have two partners. Those are who would be revealed both Partners that are revealed were hired by Christina to kill the survivors Christina met these individuals in Woodsboro. They can be two newbie characters who despise stab They despise highly woods exploitation of real tragedies Especially the Woodsboro ghostface murders since it stems from their hometown They also hate the survivors because in their twisted mind as long as the survivors live It seems to be destined that ghostface will strike again and some other innocent life suffers while they keep running and hiding In these people's minds our survivors deserve to die because it would encourage Because it would encourage Hollywood to pull the plug on the newly announced stab relaunch Since they already had cold feet due to the last two sprees in screen five and screen six But Hollywood recently decided, you know what? We're gonna go ahead and actually do a stab relaunch Christina's partners believe that a new ghostface spree will result in Hollywood pulling the plug on that relaunch and all things ghostface For the time being they see it as like a step in the right direction to get Hollywood to stop exploiting real-life tragedies and of course this spree would rid the world of the angels of death the characters that Continuously always have someone popping up to target them So these two would undoubtedly unfortunately Ultimately be disposed of after their plan to kill everyone and let Christina escape fails Once they once they are killed you get this false ending because their reveals would convince the viewers that Christina was innocent until she picks up a gun One of her partners had and tells Sydney Gayle Sam Tara to not move a single muscle Sam can go mom. What are you doing? Christina would then explain? Did you really think it would be that easy? I can't let you guys walk out of here.  She can go over how those two hated Hollywood and thought the survivors dying would send a much needed message to Sunrise Studios To pull the plug on all things ghostface She can then give her motive which is good old-fashioned revenge Christina hates Sam because she ruined her attempt to have a family with Tara's dad And she stole Tara from her by making Tara side with her after the events of Scroom 5 Christina hates Gayle because Gayle has profited off the demise of Billy for years Even if she's forgotten about it Christina certainly hasn't she hates Sydney because Sydney killed the man She has always wanted which results in her having to settle for Tara's dad Christina will explain how she and Billy were supposed to run off together after the Woodsboro murders and Revealed that she knew what Billy was up to when he plotted to kill Sydney's mom and frame cotton weary This would be a big bombshell because if Christina hadn't let her love for Billy blind her so much Several lives could have been saved including Sydney's mother and cotton weary probably could have been in a very different Predictment in his life. If not for Christina's silence Sydney ruined those plans, but things went well with Tara's dad Until Sam ruined that and over time between Scroom 5 to 7 Christina just simply snapped Christina will also mention how her two partners that are now dead We're willing to get caught and take the fall for everything But she'll have to get her hands dirty for once in order for this all to work out So I would like it to be poetic in a lot of ways for Christina because she didn't get her hands dirty For the events of screen 7 you primarily would just have two active killers The third one as an accomplice would be revealed to be Christina. She never dawns the ghost face costume though She's just revealed as someone who was in cahoots. She hired them But she never actually did anything.  So that's how it would be poetic Now you finally have to get your hands dirty because your plans for once again, they did not work They didn't work in 90 they didn't work in 95 or 96 after Billy and Stu were killed and they're not working now So you have to get your hands dirty Ultimately, of course, she's not gonna get away with it Christina will be killed And that'll be the end of it first green seven That is how I would propose you can do a Christina reveal while still keeping it shocking You can do it in a way that props up that she undoubtedly It's very evident. It can't be her then you pull the rug out from under us And a big way by revealing that she knew entirely what was going on the whole time because she hired the two killers That's what I think would work in order to effectively sell it to the viewer who was already going in expecting Christina Christina should not get her hands dirty. That's what should happen But then again, if you're listening to this video, you're not gonna find it shocking anyway Because I probably already spoiled it for you if they take that route But you guys can let me know what you think about that down in the comment section below Do you think that would be an effective way to get? Christina as a surprising reveal. What do you think about those motives? I cooked up for her to accomplices who basically have the same Desire as her Minus the fact that she really doesn't care about sending a message to Hollywood as much as these two goons who hate true crime and hate stab And all things that deal with exploitation do let me know what you guys think about this down in the comment section below If you haven't already course make sure you subscribe turn on post notification You never miss a video in the description. I'll have links on social media accounts I'm on Facebook Twitter and Instagram you can message me there Of course limits any movies news or reviews you like me to cover in the future and with all that in mind guys I will see you in the next video