I would like to hand over to one of our technical steering committee members in Starting X, Greg Wains, who will be telling a bit more about the project. Greg, the floor is yours. Thanks, Ilocco. The Starling X project, deploy and manage distributed edge networks.  A single cloud solution to support both your virtualized payloads and your containerized payloads. It scales from a single server solution to a geographically distributed system of hundreds of edge clouds with strong orchestration tools to simplify things like edge cloud installation as well as simplify configuration of cloud infrastructure across all of those edge clouds. It provides high performance by exposing SRV NICS as well as hardware acceleration devices such as GPUs and FPGAs into the virtualized and containerized workloads. Starling X today has proven deployments in far-edge networks of major 5G telecom providers. So join the team and get involved, be part of the murmuration, join the discussions on our mailing list, participate in our weekly meetings in order to track project activity and contribute. Help us deliver the next Starling X release. Help scale or distribute a cloud solution from hundreds of thousands of edge clouds as well as help secure a solution with enabling mandatory access control and much, much more.


Hello, I'm Lalit Kapoor. I'm at Manipal Hospital, Dhwaka, New Delhi. I would like to share my experience here at this excellent hospital. My dad is 75 years old and he had a history of heart disease and we came in contact with Dr. Mishra who advised TABAR which is trans aortic valve replacement because my dad has already gone bypass surgery 14 years back. So another bypass was not recommended and this is trans catheter which is done through the femoral artery and it's not very complicated and non-invasive procedure where the recovery is very fast. So Dr. Mishra guided and explained the procedure really well to us. I would really like to compliment Dr. Mishra and his entire team in the hospital who did this procedure and this is very successful and I'm so proud and it's an honour for me to share that this is the first tower done on my dad at this facility which is Manipal Hospital, Dhwaka. So I would really like to compliment his staff and entire team of Dr. Mishra. Thank you very much and we are very satisfied and happy with the care and treatment which was given to us. So thank you so much.


Want to upgrade your Ender 5 in 15 minutes or less using only printable parts? We're gonna do that today. My name is Jim and this is the edge of tech. So today we're gonna take this Ender 5 and we're gonna upgrade it in 15 minutes or less using my three favorite printable upgrades. These help bed strain relief, bed flex and protect your back cover right here on the LCD. We're gonna jump into it. It's real easy.  The links are in the description below. Download and print the parts. Then come back to this point in the video and I'm gonna show you how to install them. It's super easy. It only takes 15 minutes or less and these are some of the best upgrades you can do to your Ender 5 and I would suggest doing them as soon as you get it. Let's do it. So the first one is this right here. This is the LCD cover and it covers the back of your screen and this will work on any of the Ender 5s. Along with the Ender 3s, you can print these for the Ender 3s as well, but it's super easy. Once you get it printed, it looks like this. It's really simple. You take it, you put it right here and you just go ahead and push it down. Now something to remember is to make sure you have enough of the cable coming out to the back just to make sure you're not going to pinch anything. Once you get it that far, just push it through. It'll clip into place and now your screen is completely protected. When you're moving this or grabbing it, you're not going to touch the back anymore. Super simple. Only took about 10 seconds to push on and this is something that anybody can do as soon as you print it. Super easy. The next one we're going to do is this bed strain relief. So I have the Ender 5 turns sideways and you can see these are the wires that come off the bed. They are not supported in any way and that is not a good thing. So what you do is you print this. It's a very quick print. It uses some supports underneath. So you take it and you push it right here on the frame of the bed and as you can see, it should be lined up perfectly with these wires. Now that's going to hold that up so this doesn't flop around anymore. Then take a small zip tie. One of the extra ones you got with your printer will work great. Push that through. Pull your zip tie on like that.  The next thing you have to do is just take the blue snippers you got with your kit and cut that excess off and you're done. So this is now really solid. This isn't going anywhere, so it's going to hold those cables. So when the bed goes up and down, it doesn't hurt the connections underneath here. Now that one was quick and that one is going to save your printer in the long run. The last of the three upgrades that I suggest to do right away are these braces right here and they come in two pieces. They're going to print with this and they're going to print with this and eventually that's going to go together on the back and hold it there. But as you can see, this goes against right here, just like that. And it holds onto the bed like this and you just push it on and it'll hold itself there. It does have right hand and left hand when you print them. So that helps a lot. So you want to make sure this piece is pushed all the way in. And then if you look back here, this is sitting all the way against that bar right here. And you're going to do that on both sides. These are the braces, the supports that we just printed. And each one of them will say right and left. As you can see, this is the left one and it'll print a cap like this. And you will also need eight M4 nuts and eight M4 by 20 screws. So when you're ready, you're going to take your M4 nuts and you're going to stage them in the slots that print it out right there. Now that you have the arm on, take the back plate and it can only go on one way. If you put it on backwards, it won't fit right and it won't look right. So put it on the correct way, which is this way here. Then take your M20 bolt, push it through the hole until you find that nut. And with the Allen wrench that came with the kit, tighten that in. I like to push mine up so it's up a little bit higher here. So tighten that in until it's snug and then flip it to the small side of the Allen wrench and do your final tightening with the small side of the Allen wrench. Do that for these three. Follow those steps on the other side and we'll be done. You'll have both arms on each side here. You'll have the bed strain relief, the bed strain support here and the cover on your LCD right here. It was super easy to do 15 minutes or less after you got the parts printed. One thing that I really like about this is these arms here, the reason why we do this is to stop this bed from flexing. Now I haven't had a lot of experience with that flexing myself, but I did these because a lot of people saw when you got something really heavy on your bed, your bed would flex because it's a cantilever. It's only connected back here. It's only a single Z. It's not like an Ender 5 Plus where it has dual Z. So these things really help and it's really rigid now. I mean you really have to crank that bad boy down to make it flex. That's not going to break these wires anymore because this is sturdy and when your bed goes up and down this isn't flopping around in the wind and you're not going to touch the back of your panel because now you've covered it up. So we just went over three really simple principle upgrades that you should do right away when you get your Ender 5. If you've had it for a while you should do them too. I really like these upgrades because they don't take much to put them on. The worst thing you have to do is find those M4 by 20 bolts and those M4 nuts. I really like using the little kits that you can buy. I'll have those in the link down below. You can get them from TH3D, you can get them from Amazon but they come with M3, M4, M5 bolts and nuts and all sorts of different size bolts. So with that being said, you know, this was a super easy install. The longest part about this is actually printing the parts after the parts are printed. This is 15 minutes or less to really upgrade your Ender 5 and you're not changing the mechanics. So you're not changing out a hot end or an extruder or anything like that. So when you get your Ender 5 and you're learning how to use it before you do any of those mechanical changes I would really suggest doing these printable changes first. The other cool thing is that since they're all printable you can do them in any colors you want. I chose the blue for this one. I really like blue. I've done other colors on my other two just to tell them apart. But you can choose any color you can do. This is PLA. I printed these all in PLA. You can use PETG. You can use ABS if you want. I like PLA. It's rigid. It's strong. It's not going anywhere. So that's what I prefer. It does not touch anywhere where it's hot so you don't have to worry about it warping, which is a good thing. And the best thing is it's cheap. It's easy to learn how to print with. And if it's one of your first prints with the Ender 5, you can do it. Well I hope you learned something today. And as always, keep printing. Hey everybody, I hope you liked the video today. If you did, give me that thumbs up. Click that subscribe button right here. There's a little bell right over here if you want to get the notifications when the next great videos or live streams come on. I really appreciate your support. You guys rock.


Hey, welcome to my talk. It's called Ember CLI Rails, an integration love story. I wrote the title before I wrote the talk, so the love story thing has been done better by other people. So this is more of a history of the interaction between Rails and Ember. So the title is not necessarily relevant to the rest of the talk. My name is Jonathan Jackson. I work at a place called Hash Rocket. It's pretty cool. You can reach out to me at these relevant links if you want to take the time to go back to maybe 2014 or so. You can visit my blog. That's probably the last time I blogged there, yeah. And email me anytime you want if you have any questions. So I mentioned I work at Hash Rocket. There are these clowns in front. They're pretty cool. They're very supportive. I think that's the thing that I would define them the most. So this is my project manager right here. This is the first thing he said to me before I started this talk.  He's kind of like being a waste of wash of hair. And then, you know, it's not just the rocketeers that are currently in service. We have rocketeer alum that try to jump in here and help out, obviously. And then this morning, about two hours ago, I said I was excited and nervous and the picture's not there, but it's me being very excited and nervous. And the T-Mock 12, Taylor Mock, he's working with me on a very large Ember app and he said as long as you use a lot of gifts, you'll be fine, but I don't have any. So now I failed him. Once again, Hash Rocket. It's pretty cool. We're also hiring. Okay, so a bit of an Ember fanatic. I've been interested in Ember for a long time. And to that end, recently, I organized a group called Ember Jacks. This is a Jacksonville Ember Meetup group. And with the help of Tildy and Lindsey Wilson, we were able to get this really cool tomster made up for us. It's a paddleboarder. If you've never seen a paddleboarder, come to Jack's Beach. If you're ever in Jack's Beach, you should come to our Meetup. It'll be fun. I also co-host Ember Weekend, which is a podcast on Ember. Talks about Ember-related topics. Mostly news stuff and things that we've learned while dog-fooding Ember apps. So check that out. And maybe there'll be a shameless plug at the end if we have time. Yeah, so, yeah, so I'm Jonathan Jackson. And a little bit about my history with Ember lately. I've been working on a very large Ember app with just a lot of complexity. And it's been really challenging and fun. And to that end, we've created the titular gem, Ember's Deli Rails, and we're dog-fooding it in this large, complex app. So I just wanted to mention that real fast.  It's going to be pretty basic. I was lucky enough to have Sandy Metz help me with this talk a little bit. Just some basic slide etiquette and how to talk to the crowd. And she said, give the talk that you would have wanted to see six months ago. And to that end, I've tried to do that here. But kind of before I can do that, I need to give you a brief introduction to Ember.js just so that we're all on the same page and we're speaking the same language. But after that, we're going to talk about the history of Rails and Ember and how these two tools have interacted and historically and how Rails developers have used and utilized this front of framework. And then I'm going to introduce you to the Ember CLI Rails gem, which I am a co-author of and maintainer along with Sean Doyle and Pawful Prophecyd. And it's our attempt to kind of help facilitate and smooth over some rough edges that will become more clear soon. And then I'm going to talk about the goals of the Ember CLI Rails project and what we want to accomplish. It's not necessarily that simple, but this is kind of the end of the talk and it won't take too long. So yeah, so yeah, so a brief introduction to Ember.js. Luke Melia mentioned a quote in a talk in 2012, I want to say, saying that 98% of building an app is understanding your layers and knowing where your code should go. And I think this is something that resonates a lot with Rails developers. Very frequently, we want to get up and running quickly with new apps and new ideas and once you know where things should go, all of this process becomes a lot easier. So Ember takes this to heart and it's part of its main philosophy is just trying to compartmentalize this stuff and make sure that things are known. You have a place to put this piece of logic. And to that end, many people call this an MVC framework, front end MVC, which kind of gets a bad rap from some people. But it's only kind of MVC. It's kind of more like MVCR+, and I had another slide before where essentially this all breaks down and the acronym no longer makes sense. But yeah, anyways, so if you want to think about it in the terms of MVCR, let's talk about the router first. And I know that's at the end of the acronym, but I'm putting it first because Ember puts it first. The router is the way that you serialize your data. It's the way you nest your UI and things should be copy and pasteable. You should be able to copy and paste your URL, and the URL is at the forefront of all Ember apps. You should be able to copy and paste your URL, give it to someone else, and the applications should be able to boot into the exact state that that person was in. So it deals with application state, and it uses HTML5 APIs and some fallback stuff to ensure that the URL is updated per route transition. So you're always able to use the back button in the way that you'd expect. Yeah, so now the M in MVCR+, models are for persisting objects. This is not entirely accurate, or at least it's not quite detailed enough. There are other objects that are actually responsible for doing the serialization and deserialization, and then also doing the persistence on the back end. Those are serializers and adapters. So I like to think of models as a schema for those other objects to have the minimum set of information they need to do their jobs correctly. And then you have views, and views deal with DOM interactions. Views and controllers are going to be kind of merged soon, but I'm not going to talk about that now. Views are responsible for DOM interactions and transitioning DOM events into semantic events. So when I click on an action, I should handle the click event with a function, and then I should transition that click function into a add user so I can refer to that inside my system semantically rather than having just all these random click handlers. So controllers. So now this is the C. This is kind of the last bit of the overview here. And this is really just for presenting the data for the view layer to render. It handles computer properties, so you're able to give these to templates and they're long lived. So they don't disappear when you transition routes. They only disappear when you do a hard refresh or manually tear them down. That's important. The long lived nature of Ember gives you a lot of power and flexibility. So now you have your little primer of Ember. I know that's too basic. There are talks that I can point you to that'll give this a little bit more meat to it if you're interested. But why is Ember JS appealing to Rails developers? And I think this is a really interesting question. It's one that I found myself wondering when I see all these other frameworks around, why would I choose Ember as a Rails developer? Yeah, so the first one is Yehuda. So Yehuda Cats is, or was rather, Rails Core started Rails Core in 2008. And then for two years worked on the Merb Merge. During this time, Rails was in, there was a lot of work to be done with Rails. And he was pushing a lot of that. And then in 2010, the Merb Merge happened and we got Rails 3. So that happened in 2010. And then he remained on Core doing a lot of really good work until 2014. And in 2011, Ember was released and he's the co-author of Ember. So I think what I'm trying to say when I say Yehuda specifically, is that there's a lot of crossover ideas. So a lot of the pain that he was feeling in Rails were the solutions that he was trying to implement were brought over into Ember. So that's pretty important, I think. Yeah, and then this is the mantra that all new Rails developers are taught, convention over configuration. You should be able to get up and running with Rails. And you should be able to get up and running with Ember very quickly.  You shouldn't have to waste it making all these micro-decisions at the onset of a project. A lot of decisions should be made for you. And they should be made with the community at large in mind so that you get a rich and varied understanding of the problem space. And I think this is something that really resonates with a lot of Rails developers. Shared nomenclature-ish, kind of, there's an asterisk there. So views are not views and controllers are not controllers. But I think it gives us enough understanding, shared understanding to start very quickly tying the connections as Rails developers. You see Ember and you're like, oh, okay, I'm used to seeing logic, I'm used to seeing structure. I'm used to seeing knowing where to put things and all this stuff. And the shared nomenclature allows you to quickly draw out that little mind map so that you can start building things. And this is something I mentioned earlier. Obviously it's on meaningful URLs. Rails does this really well. It's restful typically, and the idea is to keep the URL focused on resources. And there's just a slight shift in Ember to basically making the URL represent UI nesting. But the importance here is that Rails developers are already taking the URL into account, and it has to be first class. And then the final and probably most important is that there's a focus on testing. Ember really tries very hard to ensure that you're able to test everything. And Rails, that's the other focus. You know, Rails really wants you to be able to test your things and have this like security and the knowledge that your code will work when it's deployed, that you can bill a client and confidently say that their product is what you said that their product would be. So that's something that Ember and Rails definitely have in common. Yeah, so Rails loves Ember. I don't know why I have that recap slide. So to that end, I wanted to mention this real fast. In EmberConf, 201 created a consultancy in New York City, released a survey that many people who are going to EmberConf partook in. And this is one that I thought was particularly apt, especially for this talk. I don't know if you can see, it's probably really tiny. But the big bar over on the left is Rails. And this is all of the people who are using Ember at EmberConf. What do they prefer to use for their server side? And the overwhelming percentage is Ruby with over 50% using Rails as their back end of choice. Because it's just productive. There's just a lot of things that Rails gives you. It's great, it's awesome. There's really, you can get up and running and be productive very quickly. So, I don't know, I think that's why Rails loves Ember. I think people see these commonalities and they just dive into it and they're like, I'm going to try very hard to see where these pieces will fit. And if you get it to fit, then you're going to have this explosion of productivity. It's pretty cool. Yeah, so now we're going to move into the meat of the talk here. Talk about a history of Rails in Ember. The history, sorry, I had changed it from an indefinite to a definite article because I'm actually describing real things that actually took place, not just kind of, you know, hand-wavy stuff. So yeah, so the first, in the beginning of Ember, Ember used global inline templates. So, once again, the slide is probably a little too small, I expected, I should have zoomed in. But you can see that there's actual inline templates being embedded into the HTML. And then you do some include tags to ensure that you have all of Ember and all of Ember's dependencies loaded. And then you can just create the JavaScript on the right. It's a very simple Ember application that all it does is loop over that model there and print out red, yellow, blue. And this is interesting, right? So this is still possible now. This was from just the other day. I encourage you to go to emberjs.js-ben and fiddle around. It's very valuable. And frequently, if you discover a bug in Ember, they'll ask you to go into an Ember.js-ben and recreate it here. Because if you do it here, it's a problem with Ember. And it's not a problem with your dependencies and your situation. So it's actually a really cool tool that you're able to still do this. And this is still supported. Yeah, so this is what Ember is doing in circa 2011, I want to say. And right around the same time, Rails developers kind of caught this. And they're like, we need some tool to integrate these things. How are we going to do that? So they create the Ember Rails gem. I mean, simple enough. You'll see the common pattern here when we just affix Rails to the end of whatever Ember is doing. And that's the new thing. So these boxes here represent kind of the things that, and it's not always applicable. It's kind of imperfect. I wanted the slides to kind of look right. But these are the things that you generally need for a successful web application. You need to be able to deal with your APIs. You need to deal with testing and asset compilation serving. And it's really nice to have generators to help you get up and running very quickly. So yeah, so this is globals. It's using globals, and it gives you a way to define those globals in a solid file structure. And then it uses, I believe, like string concatenation and just puts them in the asset path and allows you to serve them like you normally would. So it does pre-compiled templates in the asset pipeline. So some of the problems here are that upgrading Ember JS dependencies was kind of difficult because you had to rely on the gem to maintain this relationship. So your dependencies were difficult to keep in sync with what you want. And it's important to note here, and this is something that's common through a lot of these new transitions, is that this is still maintained. This was used from 2011 until 2013, or as the only way, really, like there weren't any other options until 2014, 2013. And it's still receiving updates from Ember Core now. So you'll see some of the Ember Core people come in there and try to make sure that the legacy apps that are still using Ember Rails still works. This is something that you see a lot. You see a lot of this extra work coming back to try to make everything compatible, Core Team, super cool. Yeah, so this is what Rails is doing, and now we're going to step back over to what Ember is doing. So I think, I'm trying to remember the dates, 2014, StepPenner starts Ember AppKit, and it's a precursor of Ember CLI. So it's really alpha software, and what the goal of this project was, was to ensure that there were solid ways, solid answers to a lot of these questions that kept arising. So as you're building these projects, how do you answer JavaScript is really difficult to develop in at the time, and probably still now. So how can we make this more pleasant? How can we make people more productive? And this was the first attempt to try to do some architecture, some build tooling around Ember to make the experience better. I use Grunt build tooling, which Grunt is a build tool that allows you to do all of this really cool stuff, including ES6 versioning. I don't have my slide clicker, so I apologize. I have to keep stepping back over to the podium. Yeah, so ES6 Transpletion. So this is when now we're able to write modular pieces of JavaScript code and explicitly import the dependencies. So we're able to start thinking about things much more modularly and working with JavaScript in kind of like more like sophisticated way. So you're not just concatting things. You're doing some intelligent things to kind of make it more enjoyable. It gives you a solid project structure, so it gives you the skeleton of all of this, the places like what Luke was talking about. It gives you these places for you to put the logical chunks of your code. So you know where and what to do and how to start building your project. And this is a plus or minus. It's front and back in package management with NPM and Bauer. This is kind of asterisky. They do good stuff, but yeah, they're pain points. And this next slide, I am only including because I spent a lot of time in Pixelmator making it, but that's Bauer. That's Austin Bauer, sorry. Yeah. And something I want to make clear about how Ember AppKit worked is when you installed it, its goal was to give you a skeleton structure. So you would actually clone Ember AppKit and then delete the .git directory and then get in your own repo and then you just build inside of that. And that's fine and all, but there's no upgrade path, so upgrades are really hard. And this is kind of a problem. This is a really big problem. So people who are early adopters of this software had difficulty trying to get the latest and greatest. So people were asking these questions and saying, well, this didn't work or this works and whatever. And as the project's maturing, they're finding more and more solutions to these problems, but people who already implemented it found it really difficult to find a way to get those new changes in. So it's very important. And of course, Rails, once again, the Rails community kind of rallied and said, okay, Ember AppKit is a thing. Let's make a gem to let us use it right now. So it has Rails generators for AppKit resources. This is something I really want to stress. These generators were not just shelling out to grunt. They were actually rewritten in Rails. So there was double work here. Not only were the people working in AppKit trying to get grunt to do all the right things, there were other people and sometimes the same people working on this project to make sure that the generators stayed in sync with what was available at Ember AppKit. This is really painful. This is not a very good workflow because getting these things, keeping these things in sync ended up costing a lot of people a lot of time. But yeah, anyways, those are kind of negatives. I'm trying to explain the cool parts of it. The tests are accessible in Rails land. So you can write QNet tests and you can access them via an engine, I think. That's really cool. So you're able to kind of do QNet tests and test your JavaScript in a sensible way and you can kind of view it in Rails and have it be accessible via the command line. It's pretty cool. It did some simple API versioning, which I think talks to some of the maintainers of this gem. And the simple API versioning was great for the majority of cases, but there were some edge cases that were a little weird. And it compiled AMD. So this is from Ember AppKit, but it compiled AMD. They had to write the way that this compiled AMD by hand in order to get some speed boosts over grunt. So that was another pain point where there's a lot of double work. And upgrades are hard. Upgrades are really hard. So once again, if you start an Ember AppKit Rails project, getting the latest and greatest Ember AppKit stuff is just hard. It's not easy. So that's what Rails is doing. The Rails community is doing to pull in this Ember work. And it's a really solid effort. I think it's a very noble goal to do. And then we see the successor of Ember AppKit, Ember CLI be announced at EmberConf 2014. And I think the work began a few months prior to that. And it changed a few things, including the build tool, which before was grunt, as I mentioned. But now is Broccoli. And Broccoli is this really clever abstraction for dealing with the asset pipeline problem. And it's very extensible. So they were able to build really robust toolset for quickly building assets and quickly building and rebuilding assets. It had a testing harness out of the box. So did Ember AppKit. But this is a much more robust solution. So you have test them straight away. Test them allows you to run your test against multiple browsers in your command line. And that's really cool. And I think it's really cool because you can even do things like spin up a VM and have your tests run on an IE virtual machine. Just really, really highly configurable, very robust. You can still access it via an Express server so you can actually go to a browser and run Cunit tests there. There's constant improvements. So in 2014, when Ember CLI was released, there were maybe five or six Ember shared libraries. Libraries that if you started an Ember app over here and you started over here, you would be able to share eight-ish libraries. And three or four months after Ember CLI was announced, they announced that they were going to incorporate add-ons. And add-ons allow you to write really super compartmentalized code and customize your Ember CLI experience without having to actually get changes merged into Ember CLI. So it allows you to make Ember CLI work for you in like a much richer variety of ways. And now add-ons, there are over a thousand add-ons. So within the space of a year, people have really gotten busy putting these new tools and making Ember CLI more robust. So now I'm able to start a project and incorporate things. I need a button. I need this kind of simple auth or something. All of these things. If I need these things, I can just pull them in with one command line rather than having to reimplement it myself. And upgradeability. The upgrade story was the main focus, I think, of Ember CLI. That's my personal opinion. I don't know if that's actually true. So Ember CLI is a command line interface, obviously. And it provides you a command called EmberNet. So once again, the skeleton structure was kind of the goal. Ember AppKit tried to build this way for you to clone in a project structure, make it your own, and then start building right away. And Ember CLI is trying to do the same thing, but now to create that skeleton, it uses these things called blueprints. And then when changes are merged upstream of Ember CLI, you're able to get these changes pulled into your code by doing this guided upgrade with blueprints used as diffs. So for each file in the default skeleton, you're going to see a diff of what was pushed on to the latest version you're upgrading to and what you have. And you're able to actually reconcile those two things so you can very smoothly upgrade. It feels a little clunky at first, but once you do this two or three times, this turns out to be a very elegant way to keep on the latest and greatest thing. So we got here to this Ember CLI land and everything's kind of good and everyone's pretty happy. So how do the Rails developers decide to use this and utilize it? Well, they didn't build a gem. They just completely separated everything. And in an ideal world, if you start talking about architectural purity or the kind of where things, where the separations should live, this kind of makes sense. So both sides are tested independently. It allows for greater specialization. So you're able to focus on your strengths and you're able to hire for very specific sections of your code. The test independently means that you have to write your integration tests stubbing out the back end in Ember and then you write your API tests in Rails. And that turns out to work okay. It gives a flexible back end. I know we're all Rails people here, so we want to use Rails and I think that's a good choice. But if you wanted to write it in something else, you can do that. And it's kind of separation of concern at a system level. So you kind of keep things completely separate. So this sounds great, but what are the kind of perils or pitfalls of using this style of approach? I know DHH mentioned monoliths. This is not a monolith. These are disparate things and trying to keep them in sync becomes difficult. So this is not an integrated system. I'm sorry, integrated system. So there's no full stack acceptance testing conventions. It's not that you couldn't do it. You can do it. I'm going to show you a slide in a minute that shows you some of the ways that we work around things. So there's no full stack acceptance testing conventions. But you could use Forman to spool up either side, the Ember app and the Rails app and then proxy one to the other and then point QCumber to it. But you can see already if I go to another project, I'm going to have to reintegrate this. This is not what we were talking about earlier where this convention over configuration. We don't want to make these micro-decisions at the beginning of the project. So it's ad hoc development workflows. This goes along with the same thing. A lot of conventional problems here where you just don't know what to do. People are struggling. People are investing a lot of time finding the answers to these questions. So it's cool. People write things like this. This is actually out of one of my original apps that I did separate. I don't know if you can see the code here, but can everyone see it? Cool. So it's a rake file that you run just rake and it's going to spool up the things because it assumes that back end and front end, back end being the Rails app and front end being the Ember app live in the same directory and it boots them up and points them and hooks them all up together and then you can develop. But once again, I'm having to do this and I'm probably not going to do this the same way twice. Two teams are probably not going to do this the same way. And it doesn't work well with existing applications. So what people try to draw here is when you start working with Ember CLI if you say, oh, I have an existing app and I want to use Ember CLI, people will tell you just do a rewrite and separate your app and have this complete separation. But that's not possible for a lot of people. A lot of people have invested years building these applications and have teams that are Rails focused and need transition periods to learn new technologies and proficient at these advanced things. And once again, a learning curve is not always easy. So it doesn't work well with current applications. Complete separation doesn't work well with existing applications. Deployments can become more complicated. So once again, this has to do with conventions. A lot of this has to do with conventions. There's knowing what to do and when to do it. But you can see that it gets pretty complicated. So Ember CLI deploy and Ember CLI add-on that is geared towards deploying Ember CLI apps with XYZ back-end. Rails is very common. And a diagram for that looks a little bit like this. So I'm not going to go into too much details. This is actually an excellent architecture and once you get this running, it's amazing. But you can see that you have to do a lot of upfront work trying to understand why these things need to be done this way. A lot of this has to do with cores. You want to serve your index HTML from your Rails server, your API server and then you want to serve the assets from CDN behind CloudFront and trying to make sure that those things both know because the assets are fingerprinted know about each other. You have to use Redis as an intermediary. Once again, this is actually a really great solution but it's a little more complicated and it would be nice to wrap this up. So yeah, so that's the pitfalls. So where does Ember CLI Rails and the gem sit? Well, this is my favorite part of the talk. It's the only animation I have in all my slides. Hold on. Someone say whoosh. Yeah, there we go. Okay, so the responsibility of Ember CLI Rails kind of sits like this and you'll see that this looks immediately very familiar to the way Ember App Kit did it. Ember App Kit Rails did it. The gem to utilize Ember App Kit. It's even thinner. So it's not trying to rewrite the generators. It's not trying to do the job of Ember CLI. All it's doing is it's doing the bare minimum that it needs to do to allow you to close the air gap between the front and the back end with Climbsley Separation. And it's trying to let both Ember and Rails do their own thing, independent of one another. So all of the commands that you use for Ember CLI still work. You still use Ember generators. You don't use Rails generators. You still write your API and everything kind of works great. And then this testing block kind of sits right in the middle and it allows you to do both integration tests and use unit tests just like you would with Ember and Rails. So you write your RSpec API tests and QUnit and integration tests for Ember and then you can write full stack QCumber tests if you want to or whatever acceptance testing framework you'd like. Yeah. And the goal here is once again to avoid the double work of trying to keep these two rapidly moving ecosystems together and unified. So it's really just trying to be a very, very, very thin layer. The thinner the better layer to just kind of give you some of those conventions and solve some of those pitfalls of complete separation while still allowing you to kind of know where your code belongs. So how does it work? It's a... This is kind of a... This is not a hand drawn. This is a hand drawn sequence diagram. There's actually a tool called JSSequence that lets you do this and it looks all hand drawn. It's awesome. I recommend it highly. So the user will request a page from Rails. Rails intercepts it and say, okay, I know that I need to start or restart the Ember build process and wait for the assets to be built so Rails knows where the Ember apps live. Oh, apps plural. I should say that. This, unlike all the other tools, allows for you to include multiple Ember apps. So you can have multiple, you can have an admin panel filled with all of your... an entire Ember CLI app that is only dedicated to your admin panel and then, you know, your rest of your front end can be in another Ember CLI app and Rails still is the one place, the one hub and it's just thin layer. So it's just saying, okay, request a page, start or restart Ember. Ember builds and then when that's done we do some locking stuff to make sure that you don't refresh and get a weird invalid state and then you read the assets and you serve them back to the user via the asset pipeline. Yeah, that's... So how do you use it? So you start with an Ember app and then you can actually place the Ember app anywhere you'd like but I prefer to put mine inside the root level of the Rails app under a directory called front end and then any subsequent also in the root of the application because it just makes things a little bit easier and then you run break Ember CLI in it and that produces this initializer and you're just telling Ember... or you're telling Rails rather where the Ember app lives and then there's many configuration options here to make this a little bit more customizable and work for you better and then this is from the Readme and you can actually do this by putting the... well, I'll explain that in a second. So you put a root path and then you render an index and then in your index page so now when you go to slash the app this ERB template is going to be rendered and it's going to load the... with the two helpers there it's going to load the Ember assets so that your Ember app can be loaded. So Ember CLI will have already built your assets into this nice AMD and then it's going to be included in the top of your file when you come from Ember CLI are also going to be included. I'm actually really close to the end of the talk so we might have time to do some demos. So the goals of the Ember CLI project the thing that I want for people to kind of understand about this project is that first off this is a graph of commits over time to the various projects we talked about in this talk. So the blue line starting in 2011 is Ember Rails and then the red there is Ember AppKit and you can see that that was almost two years where the way you used Ember was you used Ember Rails if you wanted to use it with Rails. Then Ember AppKit came on unseen and at EmberConf 2014 it was announced that Ember CLI was going to be kind of the way forward and it was eventually going to be included in the Ember like ecosystem officially with actual core team support the explosion of commits that happened after that and this is only from January when I initially created this this graph becomes even more impressive when you start seeing how much work is being pushed into Ember CLI and it's really important that you know that this is not going anywhere that's the kind of thing. So Ember CLI is here to stay it's going to be a thing that we use to utilize Ember and it's really really cool it does some amazing things so with that in mind you know Ember has some 15,000 commits or so and Rails has like 50,000 commits I don't know, a bunch maybe 5,000 a year for 10 plus years I want to say and these ecosystems are vibrant they're filled with energy, they're filled with people like you going out there and contributing to the code and it's awesome and I want to use both of these technologies but I don't want to have to keep rewriting these things and doing the double work I want a very thin wrapper that allows these two ecosystems to work together but evolve independently that's the real thing so that's the goal of the Ember CLI Rails project and to that end I think we're going to continue pushing and asking questions on how we should integrate these two services I would like to see I would like to see Ember CLI Rails become even thinner and the interaction just be those conventions right now we're having to use the asset pipeline pipeline in Rails and we're also using an asset pipeline in Broccoli and that seems like double work, why are we doing that so we're probably going to push that even further out but there's a lot of questions to be asked but right now you can use it right now and start using Ember CLI in your Rails apps so yeah so maybe we have time for some demo first off I'd like to thank HashRocket for the time to kind of work on this talk and some design help and obviously all the support that they give me and then I want to personally thank Sandy Metz and Terence Lee who helped me kind of refine these slides yeah I think that's it do we have time for demo? how much time? two, three minutes? okay cool I thought I had changed that so I mentioned earlier that the URL was the URL was at the forefront of Ember's philosophy and kind of to that end I noticed something and this is not a poke at your Jabbit Rails conf particularly this is something that happens to conf a lot of things it happened to Ember conf website acted the same way but you can see when I changed this with JavaScript I'm getting all the new updated schedule right but the URL is not updating so if I go to Thursday and I scroll down a little bit and I press refresh it just kind of like takes me back to Tuesday I go back in time and you know something like this is the shameless plug so this is the podcast site that I mentioned that I work on and you can see that when we go into things the URL is updated we're not actually doing full page refreshes and if I refresh I'll be on the same page and the URL is at the forefront so I don't know that's the kind of quick demo I wanted to show hopefully this will get you really inspired to kind of start looking at Ember's CLI it's an awesome tool and you can use it now in Rails apps so thank you very much


This is Jesus' plan. I remind you about the lesson in the workbook of A Course in Miracles. Myself is ruler of the universe. My capital self is ruler of the universe. Christ is the ruler of the universe. If any of you think the ego is ruling this universe, you better think again. Because JC Central, man, they handle everything. You don't miss a thing. I do. You see every move I make. Jesus is in charge. He's not only following like Gary said. Oh boy, is he in charge. He's really in charge of time and space. And he can handle anything in your life. The power of prayer from cancer, financial issues, whatever. If you link in with that internal teacher, you've got a good link. And your problems don't have a chance against the power and the glory of God coming through Jesus Christ. Jesus tells you in A Course in Miracles, ownership is a dangerous concept if left to you. What is the copyright? Ownership. It's just a symbol. But it's dangerous if you identify with it in any way. If you had the slightest thought, I am controlled now of that book. Oh boy. Oh no, JC Central is in charge of absolutely everything. And anything that you try to do that goes against JC Central will result in difficulty. The lesson is forgiveness. The lesson is not being identified with anything. You must realize the impossibility of ownership. All ability. Because in heaven there is no ownership. You don't get to heaven and say, oh, where's my acreage? I got a lot of abundance. I did a great life on earth. Do I have some abundance going on here in heaven? Well, you don't have any real estate. You have just the real. It's called spirit. So, you know, people talk about this stuff. But basically, you know, when I talk about the community that I've set up is basically, it's not based on personal ownership. People say, that's a cult, that's radical. No, it's not. Come on now, let's get honest. Let's look at the teachings of a Course in Miracles. You know, basically, freely you have received now freely gift. Haven't all the mystics and saints been telling us to share? Just share. There's plenty here if we let the Holy Spirit to leave the way.


I'm Anthony Johnson, this is a video and written response to a video recently published by Richard Cooper. To fans and patrons of 21 Studios, on January 31, 2019, we published a promotional video trailer for an upcoming 21 convention live event in Orlando, Florida. The video has since gone viral and received nearly 100,000 views across all platforms. The response from our speaker team and fans was extremely positive, including speakers featured in the video itself. Some of the speakers from the trailer, Richard Cooper, even agreed to cross-publish this video to his platforms and further expand its reach. In spite of Richard speaking twice prior, successfully, and with his strong endorsement, he expressed brand new safety concerns for the event that quickly deteriorated into dictates and demands. This became problematic for the following reasons. 1. After repeated questioning and writing and orally to the witness of Rola Tomasi and team members at 21 Studios, Richard failed to provide evidence of a single, violent, or otherwise credible threat to his safety at any event, time, or place. This would be a serious matter that would need to be reported immediately to YouTube, Google, and law enforcement. To my knowledge and repeated inquiry, no such action has been taken and no such comments exist. In spite of this lack of evidence, I heard his concerns and responded with the following security investments and measures on behalf of 21 Studios. This is a partial list and some measures must remain private for security purposes. A. Increase our professional, licensed and armed security team from two to six guards. B. Further increase the guards from six to eight. C. Hiring an armed, personal bodyguard for Richard throughout the entire event. D. Offering Richard a level 3A body armor throughout the entire event. Also available in 2018 and 2019 for all speakers seen right here. E. Any attendee or speaker carrying a concealed weapon must present a valid concealed weapons license to demonstrate lawful possession of the weapon. F. Hiring a uniformed Orange County Sheriff's Deputy to be present for the entire event. G. The on-site security director for the Orlando venue I have selected for this event is retired United States Secret Service. H. Our event venues are kept hidden and released to pay ticket holders only. This is standard for all 21 convention events. 3. The security professionals we work with agree that these measures vastly exceed our actual threat level, which as stated it has included no evidence of violent or otherwise credible threats. We are extremely far ahead of any potential problems. 4. Richard dismissed and declined all of these measures and with zero security qualifications to my knowledge then and now made his own recommendations into non-negotiable demands. At no point were security specific recommendations from Richard considered because he is not a professional in this domain and holds no qualifications for making them. 5. These demands explicitly violated recommendations from actual security professionals and made clear that submitting to these demands would make the event less safe for all participants. 6. These demands which included mandating all attendees be personally unarmed and defenseless represent a major change to the way 21 convention events have operated since 2010. They also violate core guiding principles of the company that I have an unshakable conviction for including personal freedom, personal responsibility and self-defense. Principles I have been explicitly advocated for on our platforms numerous times by our speakers. Check the video description for links to these videos. 7. Under no circumstances am I willing to make our events, attendees, speakers and staff less safe, defy recommendations from actual security professionals and abandon core principles that guide the company. We walk our talk at every step. We are a professional organization that takes safety and security very seriously for every individual at our events. I take self-defense so seriously that I lawfully conceal carry a firearm, this one right here. At our events to protect myself, my friends, family, speakers and customers should a highly unlikely situation require it. Richard Cooper is not special, but has been offered excessive additional measures given his stated concerns. Our focus in this context is 100% on building a safe and secure event for all. Other personal emotions on the matter are of zero importance. We value safety over feelings. To the closest point, I have been building 21 convention events since July of 2006 and over 12 years, 15 conventions, 1,000 attendees and 140 speakers across four countries. We have never had a single incidence of violence, not so much as a fistfight. Our safety, security and privacy record for our events is literally flawless, including the two Richard spoke at and endorsed, fully aware of principles guiding the company then and now. Regarding the video trailer and patriarch edition of the 21 convention, we have complied with all reasonable requests in a timely manner, including removing him from the event speaker list. I have judged Richard's request to remove the promotional video trailer from the web that included him, among many of the speakers, as unreasonable, and instead have made proper updates to inform viewers of the sudden and surprising self-remover from speaking at the event. The video is property of 21 studios. It was paid for and filmed 100% by 21 studios. We had every reason to believe Richard would follow through on his word to speak at the event as he has before multiple times. He has put extensive effort into being in the trailer just days before publication, much to his approval on completion. The video is released in good faith and its continued existence on the web was never contingent upon a surprising reversal of decisions. The trailer is beautiful, badass, and made history in the hemisphere. It will never be removed from the web under any circumstances. I stand by our work completely and hope you continue to enjoy the video as many times as you wish. In summary, we are sending a cease and desist notice to Richard Cooper immediately for his baseless disparaging comments about the safety and reputation of our events that are completely unfounded, have no basis in evidence or fact, defy recommendations from actual security professionals and flagrantly undermine core values of 21 studios in a 21 convention. Richard's public comments are more than disparaging to me. Our team and events, they are insulting to our attendees and speakers who use their own judgment and trust us 15 times over to run a safe, secure, professional event for men every time. I am the sole founder of 21 studios and I'm proud to say the 21 convention is both the safest and greatest event in the entire history of the hemisphere. Richard Cooper no longer has any affiliation with 21 studios and I hereby withdraw any and all endorsements of him ever made and all pending speaking invitations to him have been permanently revoked. I'm Anthony dream Johnson. I approve this message and make zero apology for my decisions in this matter. I'll see you soon at the 21 convention. Take us in information or in the box below as well as a link to the transcript for this video. Have a safe day.


What's the potential motivation of blocking for a guy like that, like Adrian Pete?  You know, he's been great. He came out to the number this last night, you know, run our offense and play ball. Who played? Excuse me? Who played? I forget who it was. It was at Taylor's house, so. It's not, we don't know whether Vaughn Miller's going to play or not, but what kind of challenges does somebody like him present while on the same defensive front is there? Yeah, he's an elite player, you know, one-on-one, the best of our generation. It's going to be an awesome challenge. If he's in there and playing, I expect that he will be.  I mean, they're proud as a whole, not just Tim, but I was thinking of some other guys who produced. What's the challenge for you guys this week? They have a very talented front, good defense. Guys that play all over the place, play hard. You know, Donald Vaughn, all those guys are, you know, really good players and it's going to be a great test for us. Have you had a chance to talk to Derek? And I guess what's the kind of feeling that the star of the week can get loose, and I know you've got a few more, but how tough is that to deal with for you guys? It was a blow. I think probably the hardest part was in the locker room in Indy after that game. That was when we finally did find out to Derek. It was tough just because he's still competitive. He worked so hard, you know, he was on-faces through a lot of special things and, you know, he was pretty emotional as a lot of guys were. There's been a lot of talk about how this is a long season with the 17th game. Do you maybe tweak your schedule through the week to maybe help make sure you're ready for the final game of January 9th? You know, you definitely got to focus on recovery. That's a big part of, you know, being able to play the weekend we got this week. But for me it's always just focused about the next game. You can be completely 100% in to play your best ball just the next week. Does it help that the bye for this team is December 2nd? Kind of maybe give a chance for a refresh for the final stretch? Yeah.  You know, the bye week is the bye week. It's a chance to get your body right and get rest. And then, you know, final push for the season in class. How many guys, like, 12 and 3 maybe in your last 15 on the road? Any particular rhyme or reason to that? That's pretty selfless. You know, we've got a gritty team. We come to play no matter where it is. We do our best to play physical or playing football no matter where it is. Whether it's in Nashville or around the country. How do you guys are in obvious passing-down situations with two guys like Donald? How can they kind of, how do you guys kind of expect them to come in? Are they going to be on one side of the formation together? Do you think they'll spread them out across the front? We'll see, man. We'll see. I expect we'll probably get, sometimes on either side, sometimes on the same side. I think they're going to mix it up and hit us a lot of different things. We've got to be ready for whatever they bring. You mentioned the mood after the Colts game in the locker room. How much did the energy and kind of the mood pick up this week, the addition of Peterson? Yeah, it's exciting. You know, it really is exciting. You know, everybody's very, you know, heartbroken about Derek, but we understand where we're at as a team.  And so he's rolling when he does come back. How much did things change for the group? Yes. Go for Derek, who's carrying the load and now potentially Adrian, John, Tays, and Jeremy. I mean, is there an adjustment there in dealing with different box and different styles? Yeah, absolutely. It's subtle. You know, Derek runs like Derek and nobody else runs like him. So there's little things here and there, just the way, you know, Derek, my hit is different than the way Adrian, my hit is. So we definitely, there's some, there's some gelling that's going on there and we're learning about him and he's learning about us. That's a, but I enjoy that part of football. You know, really having everybody's different styles kind of coming together and, you know, finding a rhythm. You helped the whole chemistry process.  Does that help? I think so. I always thought the best teams were also the ones that were the closest, you know, than the best kind of camaraderie. Yeah.  You know, just kind of spend, you got to put the work in, you know, kind of outside of the building and stuff to really know who you're playing with and get that time together. So I really enjoy O-line dinners. Do you guys eatie-wise? Yeah. Yeah, you can hold us on there, too.


What's up, y'all? Chris from Jasper's Case Breaks dot com doing our R&B for top definitive baseball one box break number six The R&B for this includes Yankees, Reyes, Royals, Asher's, Dodgers, and Marlins. Just a quick heads up This R&B does not count towards it. Let's credit each spot. We'll get a random number for this break from zero down to nine Any and all redemptions will go to spot zero even if they are a known one-on-one on the checklist Spot one will get any and all active one-on-ones along with any number that ends in 11 21 31 and so on all the way from two to nine So here's our dice. Here's our players from Steven Andy, Harry, Nick, and Lonnie. I'm grabbing six spots Lonnie Thank you very much. The rest of y'all Steven, Andy, Harry, and Nick. Thanks again Here are our numbers from one to zero. Let's roll this dice for both lists. Good luck. Thank you again Six and three is nine. So nine times for both. Here is one two three four five six seven eight and last one nine Six and three Isn't that at the bottom? So Harry down to Lonnie. Lonnie with the I don't know what to call last spot mojo This and our numbers nine times again y'all good luck one two three four Five six seven eight and last one nine times Right here two down to one. Let's grab this real quick All right, so Andy grab spot zero. That's all of our redemptions Lonnie with that last spot mojo ends up getting spot one Nice Harry has two Lonnie has three Steven has four Lonnie five Nick with six and Lonnie with seven eight and nine All right, that's the R&B when we come back real real quick We'll get that definitive box break going. Thanks again. Josh's case breaks calm. Bye. Bye