Hello, welcome to the Jenkins configuration as code project meeting today is the June 17th, and we have team Adrienne Joseph me on the call. So we'll just discuss News related to configuration is called in Jenkins and then focus on ongoing development and other topics. I Also wanted to discuss a jkask Roadmap status today just to check whether we have for all option items on the roadmap and whether we need to have these statuses and I guess so that's it Okay, so regarding news one is a kind of ongoing thing we have did only Jenkins configuration which needs a lot more testing and feedback though generally it works It's here So team with any new developments regarding to don their configuration Nothing's the last one who last year it was done during the UX hackathon which we talked about last session Okay Yeah, so one thing Regarding that I finished the demo Jenkins configuration as code while it kind of works and now it has recent plugins and It supports a read-on remote which can be used for testing Of this configuration though, I still need to migrate the demo to jkask because now the demo is largely configured by Groovy scripts, but if anyone wants to test the only permissions it should be basically the same and Yep, I think that we can also Something else Are there any other demos which have been already to configuration as code? I mean to redone the Okay, so other news that the bill of materials is finally up to date So it means that Homa we use as Jenkins plug-in bomb now. There is a recent version of jkask embedded in version 10, right? So, yeah, along with all other plugins we find this in the light of that So thanks to everyone as a special team Getting quit over the line. So now everyone Their plugins with recent jkask without a lot of hustle Okay, any other news. They're missing Well, maybe it's a relatively minor Yes, they released plug-in installation manager Basically, it's a part of our jkask stories and then we released We released a few patches. So firstly and now there is a caching of downloaded plugins which can be used for Utilized for example to speed up docker bills or just common instances, then we have option to skip Downloads if something fails but implementation of retry and I also fixed the issue with transient dependency resolution because actually before this patch The tool was installing plugins, which we're going to decide on the instance And we hit a buck with your themes being installed through a transient dependency in lotion So, yeah, now it should be fixed though. It's just a partial fix the behavior of Dependency resolution is still not optional Reported bugs for example for optional dependencies Not resolved properly in terms of version control and also collisions between trans and dependencies in lower levels It won't be working reliably Still, it's a kind of improvement being compared to the previous state Yeah, as always contributions are welcome okay So I'm going development Joseph you want to to talk about secret resolver, right? yeah, um The only thing that concerns me in the the problem first again is the Introducing something that you might remove or might be confusing to users that exist It might be hidden somewhere. Yeah Yeah um Again, I put a lot of discussions with myself in to actually for anyone reviewing it to hopefully assist with their thoughts, but uh Yeah No The thing you could do is you could go down to like just have it one thing So there's only one key would which would I guess would be base 64 and then it will figure out If it's a file if it's a file it will do the right thing um Or if it's a a string it will try and do that But the problem is that you would get weird behaviors. Let's say the file doesn't exist and then it goes into the other logic and then But then you have to check if it's a path and it gets quite messy Yeah, maybe we should just uh A bit the prefix something like base 64 file and that's one of the other options This this is really a thing where you can combine them actually um Because you might have a file you want to read in and then again Maybe we should just support two and then don't support nested Uh, but then you want to support nested because you might want to have a variable That's not obvious if the file path if you don't want to show where it's it All my experience with a variable handling conjunctions, especially with an object plugins is that let's avoid nested variables But yeah, if there is no real use case for that I would rather prefer to keep it simple Uh, but if you see a use case for that, okay Let's try to implement that could be a use for it where you would have a secret that you want to just base 64 like a string So that would be a secret that you wouldn't have to or a variable you have to resolve So you'd need the nested thing Of course, we could try and prevent the nested thing like you could I could write some logic that would prevent the nested thing Of these two together like the base 64 and the file 64 Yeah, so yeah Maybe we should think about a bit more intellectual macro engine for resolution Because I hit similar issue. So there is a pull request which basically is very related to that about encrypted passwords The one which I still cannot finish though Yeah, so for the decrypting credentials and the So yeah, this is the current implementation. So basically I have strings like that Which is also a kind of weird macro So maybe we could standardize a macro handling It's really You could write a with the current one you can write another Replacer that researches for those things with the current thing that I have in my pull request You can create your own and you can create your own replacers And it could look for those things Um, it is a bit it's another common library, but it has a lot of features for like For like doing string replacements and having multiples and stuff like that So actually I needed to create a secondary replacer for having the luck when people didn't have a secret that was filled So But yeah, it wasn't that hard to to get around that Okay, so anyway, these things are slightly isolated They're slightly rid, yeah Yeah So our resolution logic becomes more and more complex That's why I think that at some point we should think about either a formal macro engine Use extension points, etc. So similarly to token macro plugin Oh Yeah, actually So you want extension points? Okay. Yeah, that that could make sense Well, it would help to break down logic a bit because Yeah, I already hit the number of issues in tests when I was implementing this pull request I'm not sure what I Even submitted the pull request, but yeah, it was mostly stuck because of edge cases. So talking about the plugin, it basically implements logic like that And the full is an extension point. So you can create your own ones We can Yeah, we can we are almost there to have extensions points, but then at some point Why not just use the token thing? The token plugin token micro plugin to to do that work for us If it's supposed to same with stuff Well In principle, yes in practice This plugin had no support even for pipeline for a while So yeah, you can see the extension point right now So I set this macro name, etc. And then for example, it will lead for Abstract project. So it's what we had for Evans And now we also have it will lead for pipeline. Okay. It doesn't really work for our use case Well, yeah, technically we could Introduce it on the configuration as code plugin past configuration as code context But yeah, the thing is that we were almost there actually on the other end and in my pull request I I think it would take like one or two lines to add the extension point to like Resolve those extensions and then because as I said, you can add any replacers And you can then just search for those replacers and then add them in Yeah Plus one for new extension point That would be nice. Yeah It also would enable other stuff That we have had people asking for like instead of the current way of like Creating secret resolvers that way we do now that it would be nicer with more syntax like if you if you could like Divert on that part instead Yeah, like if you have a vault sub path or something Exactly, I would much rather have vault sub path and then like Don't worry vault colon and then something string stuff That would be a lot nicer. Yeah, so something like that So it's the clarity. Yeah, so it's the clarity of like that. It's happening Yeah, kind of like kind of the answer will look up plugins for vault where you kind of embed all of that in line Ah Also for so it's easier to anyone who is a Configurator is an administrator to say, ah, this is current for vault I should probably go look at vault instead of like, where do I look if you're using Kubernetes and vault at the same time and some of them are coming from both Yeah, because yeah, right now it's so easy to fall into whatever false resolution Yes The current logic and really start enforcing something like that That's kind of nice that you can't have multiple strategies though. So like locally you can load it from a file system whereas Um in your actual production system, you can load it from body of a vault system Uh failure points and that is nice. Yeah, that is true so And I'm not in favor of removing old stuff that works because then we would have people that have workflows that gets destroyed Yeah, so Yeah, uh, basically generic, uh, it is a Lucian and it's Prot uh, definitely And we we've definitely been using that For our use case as well. Like yeah, we we use it as well We we have a in our case We have a dug a compose that just have the environment variables loaded in and then yeah off you go Yeah So I think that uh, this approach is don't conflict with each other but yeah Or maybe Introduce another syntax for one off because unlikely you have three sources Well, theoretically if you deploy the same instance, let's say in kubernetes and docker and locally for testing Maybe but yeah anyway I think that we need to review this full request Yeah, this one Well, I think that it's kind of reviewed already but yeah For me I think do you want to implement this extension point? So do you want to just keep it as is and we can build on the top of that? I I don't want to have a rather extend this pr because what it does right now is again it has yeah Yeah Yeah, I don't necessarily like the way it's doing it Okay Good And again, I want to try to have this little less Not not so much confusion like for the users that are using it or would be using it Okay So basically another iteration before we merge with it. Yeah, okay But yeah, thanks for working on that It's a useful feature Yep Okay, system read permission. So do we have anything? Stitched for reviews, etc No I think yeah, the only semi-related one is the log recorder in core for configurations code That's currently the only Thing that we use to take into your life for is not recorders well Makes total sense to support that Yeah, the only problem with it Follow-up recorder we system did permission. Are you able to configure your recorders or not because both approaches kind of make sense Uh with system read can you notice the system read can't configure recorders. It can just view previously configured ones Okay I was just wondering how much it helps because for example, if you want to diagnose something usually you're at a new log recorder and principally Still a key for the don't leave permission because uh, you don't add new functionality You just capture existing folks at the same time No idea. Yeah. I mean one of ours is that we use it. We lose our log recorder configuration as soon as it reboots And it gets reverted whenever patches can apply automatically in any reason Okay, well, anyway, we can figure it out later, but yeah, we only use a safe choice Maybe not great for user experience, but Yeah, at least it's definitely good from permission standpoint Okay, and did we get enough issues Uh for plugins reported Not doing it to the monitor is probably plenty more that could have support the same that issues raised and Yeah, I started running my demos to verify a dark theme and Tables to divs migration But yeah, in principle, I want to use the same demo to do scrap or system with permission and maybe Reuse other demos to have more plugins for example Yeah, we still have this demo for cloud based jinkies distribution and j cask where we can spot check all plugins we have embedded something like 200 ones But yeah, you still need some work But just processing that and the report cases where we hit them will be definitely helpful Yeah Okay So, yeah, what is taking it? Okay, anything else on system rate? Yeah, so for plugin installation management. Yeah, just a quick update. I will be submitting more patches because I really want to get rid of custom plugin installation manager implementation and jinkies file runner And apparently I still heat issues when trying to adopt it So I will be submitting a few patches But I can confirm that yaml configuration etc worked pretty well I also did some experiments with depender bot for yaml configurations using the tool created by olivier for infrastructure And actually it works So maybe I will create such update flow because I'm really keen to use pomeximal as a source for common users It works pretty well for customer packages, but customer packages takes ounce to build And with plugin installation manager now we support for caches. We can actually speed up the bills a lot So I would rather prefer to try implementing automated dependency management for plugin installation manager not for custom work packages So yet to be seen Yeah, hopefully we'll get it over the line Yeah, so depender bot like I think I think it will be just embedded in the plugin installation manager So there will be no new tool for that And yeah, let's see You're not sure does anybody else use plugin installation manager in production now We tried several times So yeah, we tried and didn't work I think you fixed one of the bugs though the unwanted transparent. Yeah, the unwanted plugins I'm sure it would work for us. I don't think we're doing anything that would cause it not to just to see whether it's faster and If it was in the document, we probably just use it. It's because it's not the default in the document Um, and the main reason that would get us to move there would be automatic updates If we could get if we could get that Well, uh, there is already a command which shows updates. Um, I spent some time To get it working and for example, uh, the recent patch for Demaging is configs code was basically produced by the tool So this one is a machine is a machine processable or is it human? Well, it's uh it dumps a text file and then simple regular expression and you get this format So the next step is to put this simple regular expression right inside of the tool So I created An option to generate a new updates file In available updates. So basically The plugin manager will be able to generate the list on its own without all this magic in the yaml or plugins 60 Uh, well technically it might be difficult if we merge Uh Plug-in management yaml and jcask yaml in the same file But yeah, as long as they separate it's not a problem. You can always mention separately like Yeah, one thing I noticed that it still has some well, it still has glitches with trans independence management. So It will get patches before it becomes fully reliable But yeah, at least command for check updates. Well, it's maybe 30 minutes to implement it Yeah, I think I think we just specify everything anyway, just so that we don't get out of date plugins Yeah, nice if you didn't have to but So let's see Anyway, I plan to spend some time because I needed for doing his father honor and for new edition of customer package I want to have Two less and limitations of plugin management. I'm keen. So This tool is a way to go for me Okay, any comments about this story Other things The only thing would be optional to tendencies those would Would be probably another blocker for adopting I would say Yeah, optional dependencies. Yeah, right here Yeah, I come from that. I want to resolve it So yeah, the problem that It needs a complete redesign of how dependency resolution works. So that's why I started from my poor man's patch just Change the top level dependencies Even there I hit some issues. So for example, if you take a look at this pull request You can see that for example If you use maven If you're familiar with maven enforcer, then whatever you do find on the top This is what you get And if you use enforcer if you have trans independence of high version, then you get never And I tried to implement such logic new plugin Sorry in this tool and actually I just Got an error in existing tests after that Because the logic of this tool is quite different. It still tries to pull the recent version from trans independences And I think we should stop doing that instead of that just fail the build And yeah, that's just the beginning because basically we need to redefine completely how this logic works Because There are so many pitfalls in the current resolution So if somebody still remembers graph theory from the university is probably I think to apply it Yeah, I think I will just take a quote from maven enforcer or whatever and embed it in the plugin because Yeah, I think that it's better to not implement Another resolution on our Or maybe junk is called codebase, let's see Okay, but yeah, thanks for the feedback So I definitely want to spend some time on that So any other ongoing development? Nope Okay Let's just take a look at the roadmap a bit. So I wanted to check with you whether we have all stories There So there is definitely no story for plugin installation manager Probably I will call it plugin installation manager to the zero taking the break and changes in how dependencies are resolved And yeah, right, whatever manifesto for this version. I put it on the roadmap But the rest so what do we have now a system read permission then? A pluggable configuration sources, but I guess that's all we have specifically for jcask Yeah Do we want to add something else? Okay, does anybody have something big in mind that you want to implement in the next six months? probably so Yeah, I suggest to spend some time at the next meeting But yeah, I really integrate plugin installation manager and customer packages stories in the roadmap And yeah, basically the same for any other plugin not For jcask So my personal plan is to have a roadmap officially approved at the next governance meeting So not today but in two weeks So if there are big stories you're working whatever Integrations with a vault or whatever we can put it there Because more items we have special specifically user facing items. It would be helpful for the project Anything else for today? Because thanks everyone for your time Thanks Thanks everyone. Thank you. Bye. Okay. Bye. See you in two weeks


YouTube CEO just did an interview with Fortune, discussing her recent goals for YouTube, and she has some pretty interesting insights and plans. And we have a new winner on today's $100,000 sponsorship for small channels powered by freedom. Let's go. The CEO of YouTube, Susan Wojcicki, just did an interview with Fortune, discussing how her team is going to narrow their focus into just a few things instead of trying to do everything at once. How YouTube, I think, is similar to Google, which is if there are 50 things you want to do and you only have enough resources for 10, you don't want to peanut butter your team. You want to make some hard choices and say these are the things that we're going to do. These are the things we're going to do really, really well, and then do them well and hire the right people, give them the resources, give them the funding to make that happen. And one of my favorite points from this interview that she makes is how YouTube is giving a voice to people that otherwise would not have one. You know, there are few use cases that I think are super important to YouTube and as I've been there, I've come to really appreciate them and realize how meaningful they are to the world. So I think one of them is that it gives a voice to people who otherwise would not have a voice. And we have a new winner today. Today's winner was picked by Heartbeat. Click here to see how to get Heartbeat so you can also contribute and help us pick deserving winners. And today's winner is JM, the third MC. Look behind me. JM helps in the comments by providing channel reviews, shout outs, and he hasn't given up on trying to help the freedom family. Your efforts haven't gone unnoticed, JM. So great job, my friend. You get to pick from one of these five prizes that'll get shipped straight to your door if you follow these steps. Click this video and follow the steps in order to claim your prize. This is freedom and this is simply day 51 out of 365 days, a full year of sponsorships for people that help small channels become bigger channels. That's how you win. Down there in the comments below, offer tips, graphics, advice, or motivation to your fellow members of the freedom family. You are part of it. I am part of it. We're all part of it. I've been Alex Adams, Senior Manager at Freedom, and you've been watching. Click Get More Views to learn how to build your audience faster on YouTube. Click Get More CPM to learn how to make more money from your channel. And click Get More Music to learn where to get more music to spice up your videos. Click the first playlist to watch The George Show on Freedom. That's my show. Or watch The Anthony Show or The Alex Show also on Freedom. And we will grow together as a family because this is the freedom family. You are part of it. We are all part of it. And we're all growing together. So grow with us and partner with Freedom. That play now button right there on the video bar is all you need to click to get started. What happened to being your brother's keeper?


Like certain blogs, they be doing certain things.    So it's like that almost drove me crazy one time. But it's like, you know what, whatever.


We're up here at TDY in Alpina. We're primarily using Grayling Range is where we're flying out of and training out there. Just doing some air-to-ground tactics, practicing basic bombing patterns, kind of dropping unguided dumb bombs if you will, just dropping 500-pounders, inerts and lives, shooting about 200 rounds on the gun for each jet, just kind of practicing getting that air-to-ground training. We are able to fly up to Grayling Range from home base, but coming up to Grayling, TDY and flying out of here, the big thing is it saves us a lot of gas. You get to use that at the range, so you have a lot more range time and get a lot more gas spent on training itself. It increases our air-to-ground proficiency and just basic bombing skills, hand-eye coordination on the range itself, not relying on laser-guided weapons or stuff because those can all fall and you might have to default back to those basic tactics of air-to-ground dumb bomb training and dropping, so it's really good to hit those and kind of keep those currencies up. The good thing with this range is we're able to do low-angle strafe, so you can get to at some point about 100 feet above the ground, so real close as close as you'll ever get in the jet. And that's always fun shooting the gun. We get about 200 rounds, which is about two seconds of gun, so they get expended quick, but definitely fun and every good goal. Being able to bring the iron up here, put it on the ramp and have our maintainers and every other support activity right here, we come up here, obviously you're away from home, so the challenges are, you don't have the assets and all the equipment that we're accustomed to back at Toledo at the Guard Base, all of our airmen have been responding brilliantly to the challenges of fixing aircraft, which happens every day. It's a $35 million asset, it's got one motor and one pilot. The core of maintenance is safety, so anytime we work on the airplane, we make sure that anything that we do is properly completed. We ensure that we do it properly and safely.


This is shuttle launch control. We have now joined history's largest crew of astronauts in the operations and checkout building as they wait for their breakfast. The seven-person crew is the largest ever to be launched in this space by any nation, and in fact is as large as the entire Mercury program astronaut corps was 21 years ago. At the head table in the center is mission commander Bob Crippen and and the other members are displayed about him on either side. To Bob Crippen's immediate left is Sally Ride on her second trip into space. Bob Crippen of course has completed three trips. This will be his fourth mission in space. Seated to commander Crippen's right is Kathy Sullivan. She's a space rookie of course on her first mission and to her right is Canadian Mark Garno and we'll be panning around a table here to see the other crew members as well. This is John McBride and Paul Scully Power noticeable for his beard. He's the payload specialist and John McBride is the pilot on this particular flight. At the opposite end of the table was mission specialist three David Liesma and we understand that the crew is at this point beginning to make their way out of the crew quarters and we see commander Bob Crippen and Sally Ride leaving the crew quarters followed by Kathy Sullivan and Mark Garno of Canada distinctive with a maple leaf flag on his flight suit. Paul Scully Power with the beard and also followed by George Abbey several of the support team astronauts and security personnel all climbing into the elevator to go down to the ground floor. Crew now leaving the operations and checkout building led by the two women on this flight Kathy Sullivan and Sally Ride. Commander Crippen and all the other crew members for history's largest astronaut crew climbing into the Astro van which is a modified camper style vehicle. Incidentally the camper vehicle was purchased by NASA because of the increasing size of shuttle flight crews. The former vehicles were proving just too small to carry all the people for the nine mile trip out to the flight bed to launch pad. Crews being sent off by a crowd of media representatives and employees which traditionally gather at the walkway leaving the operations and checkout building and the Astro van will move off in just a few seconds for the nine mile trip out to launch pad 39A. Bob Crippen now donning his helmet he'd already put on his his vest. This procedure of course is very familiar to Bob Crippen. He's had three launches already in space and numerous tests where he's done this equipment. Commander Crippen at 47 years of age is the old man of this particular mission. He was born in Beaumont Texas and he joined the astronaut corps in 1969. He was selected to be the pilot of the first space shuttle mission with John Young and has since flown two other space missions for a total of three. This makes him NASA's most experienced shuttle astronaut. He's one of the five members of this mission with naval backgrounds. Commander Crippen is listed as a Navy captain. He was a naval attack pilot aboard the carrier USS independence for more than two years before joining NASA. Mission Specialist 1 Kathy Sullivan now boarding Challengers cockpit and Dr. Sally Ride is now entering Orbiter Challenger for her second flight into space. The technician wiping down the soles of her shoes to make sure that no excess dirt would be tracked into the Orbiter Columbia Challenger rather. About to enter Challengers cockpit now is Canadian Mark Garno who is the first Canadian selected to fly in space aboard a space shuttle. Garno is also a PhD with a specialty in electrical engineering. He's an employee of the Canadian Navy and is along on this mission to perform primarily 10 experiments in three different scientific fields for Canada. He's one of six Canadian astronauts selected earlier this year for training an eventual flight. And now entering Challengers cockpit is Paul Scully Power. Scully Power is the most recent addition to this crew list. He's a civilian employee of the US Navy and he has considerable experience and time performing oceanographic research as a senior scientist or chief scientist on 24 research cruises. He was born and educated in Australia and has since become a United States citizen. He will be conducting a wide range of oceanographic studies for the Navy during the flight. Inclination with the crew heads down and wings level any two percent to 65 percent Q of maximum dynamic pressure on the ship feet per second now altitude 11 miles distance down range eight miles engines are running at 100 percent of rated thrust APU performance nominal altitude 4200 feet altitude 18 miles 19 miles velocity 100 feet per second distance down range 29 miles cursor to SRB separation which should come momentarily copy go for command pass the RF and PI setup and that'll be in work in just a second. Make that correction the payload they cameras on if if you want to play with us but you really can't fit seven people in here. A bit crowded though. Houston challenger we're all squared away and ready for set whenever you guys are. Roger Crip we'll be with you momentarily. He's back in the arm off of the. Okay run ahead the pictures that you see now. Yes that movement looks surprisingly smooth for a structure like that. Challenger you've been with you through Hawaii for eight and a half minutes. We have a teleprinter message coming up at this time. We'd like for you to leave the TV control and panel. Individuals into the into the picture now that's that's a great shot. Okay we're watching. See the only spot that's a good close-up thanks. Holder to that dark state but it looks pretty black. Well we're going LLS and we won't be talking to you until Vandenberg at nine plus three zero. We'd like you to dump tank A down to 70 percent and Bravo down to 20 percent. That should be about 30 minutes. Okay at a time at your convenience. Challenger Houston with you through TDRS. How do you read? Okay we read you loud and fair. How was run? We read you loud and clear. Go ahead USIA commentator. This is Houston Press Center again. Do you read us USIA studio? Okay this is the Houston Press Center Challenger. We're ready for questions now from Houston. Okay we're ready now for questions from Houston. If I don't identify you by name and affiliation please do so. Paul Racer Associated Press.  I'm wondering for Bob Crippen when you return are you going to really recommend that seven crew members again are flown aboard the space shuttle? That's a very tough question and one that I considered a lot prior to taking properly disciplined and at least with the kinds of tasks. Martin Dean, Bob Crippen, how difficult or discouraging has it been for you to deal with a mission that has had so many troubles, problems? By follow-up is this a mission? Yeah we've had some probably been more tough for the ground to deal with. The problem we ran into with the KUVN antenna I know is certainly all their data. I believe that marvelous job that it normally does and coming up with work around a lot in the general tenure of the way we do business no work out we'll make the best of what we have. I believe we're getting good data for them. We had a little problem with our tests I think that we've got that on. This is for Commander Crippen and Sally Ride. Could you compare this mission with the other missions that you've been on comparing the problems and the the crowded conditions and the heat as well as the accomplishments of what you think you're doing up there? We've got there eight hours a day you're spent conducting experiments and another eight hours if you're lucky you're sleeping. Are you getting much time just to gaze out the window and wonder at the splendor of it all? Sort of look like that at first. Should play EMU number three, checked out no problems at all and so far on EMU's number one and two has had absolutely no problems. See now Dave and everybody down there the two EMUs that we're going to use for the EVA tomorrow. Dave being EV one and Cathy being EV two. Now we're going to hook up the lower torsos at the helmet, hook up the FPUs and we're going to go through a pressurization check make sure that everything works. Check me to read up that attitude or Ron I'm just going to call for it. Okay that's easy way. You're Houston you're loud and clear Crippen. Reversal as they approach the Florida State already 3,000 feet. Velocity 6,300 feet per second in the shape of a space shuttle older named Challenger. Now at a velocity of 4,200 feet per second altitude 104,000 feet, 109 nautical miles from the runway for Houston 75,000 feet 46 nautical miles to touchdown velocity now 1800 feet per second sink rate 226 feet per second altitude now 73,000 feet. We're seeing long range obstacles from Cocoa Beach Patrick Air Force Base Challenger right on her ground track now 1500 feet per second 34,000 feet degrees onto the hack per second altitude 27,000 feet 13 nautical miles 179 22,000 feet now sink rate 223 feet per second 4.5 degrees 994 feet per second 800 feet range 1.3 nautical miles TSE but the beers when the time coming out of the mission control room here is the crew exits the orbiter commander Bob Crippen second hands of the ground crew pilot John McBride Kathy Sullivan Mark Grono Sally Ride Paul Scully Power


I want to switch out. That was good. I feel like I've been deep peed all game long. That was risky. How's it going everybody? DottoDoy here back with another round of Dragon Ball Fighter Ranked Badges. This time playing a team of Cooler, Super Saiyan Goku, and base Goku. The team itself wasn't suggested, but I actually had quite a few requests for Cooler because it has been a while since we've played him on the channel. And you know, why not? Dude, I think Cooler is slept on in this game. Not even that people think he's bad. I just think he's even better than what people say. Or, you know, stronger than I. That was not the right move. I switched out out of panic. It's always good to have a talking about a character and then just absolutely get rid of the character right away. But yeah, the assist here just to back him up. Nobody really wanted to see Super Saiyan Goku. I'm gonna go for two. Oh, I can't really get much here. Oh, I don't know why I was so confident he would fall with a button there. But I didn't think Cooler would come out from that side, but that was a long way back. Are we getting snapped? Nah, we're just gonna go down. Don't make me click a DP, bro. I will DP. I will DP when scared. I have no shame. Can't really. I wish they gave Cooler a longer jab. Maybe that would be too good, but I feel like he has so much range that it would be nice for him to get a little more. That's not how characters were. If that was how characters were made, Krillin would just be absolutely screwed. Hey, Krillin doesn't have any range. Why not take away even more? Oh, let's go. No, the lag. Oh, no, switch. All right, we're good. Not going to kill, though. Ah, wow. Game started slipping. He is running low on health. So I'm going to tag, watch out for any mix ups. Six M's can't get me from over there. Super Dash, that's all I wanted to see. Beam assist is going to stay in, though. No switchouts. All right, bro. All right, you were getting hit too much. Oh, I'm so upset. Let's go. Put this man in the dirt. I was worried I was going to let him actually get away and keep the assist. That would have been terrible. Air to air, we got those. Keep this man blocking. Okay, I can't do much here. No techs. Oh, no techs for me either. I'm going up. Okay, oh, he missed. Oh, look at the work. See, that's what I'm talking about. Look at the range on that standing medium, dude. It does not get better than that. That was sick. Just jab him out for all the way over there. Beam assist on the ground. Oh, baby, this is. That's going to be a nice safe setup. Please. I'm busy. I'm just going to grab him up here. I think I'm just going to grab him up here. Say goodbye now. It wouldn't be a maids ending if I didn't DP him on wake up. Okay, no, I need two bars. I need two bars. Help. Help. I want to switch out. How confident are you that I was going to? I feel like I've been dp'd all game long. That was risky. I was I was going to say you can't be you can't continue office like that. I might DP at any second. I was like a wild animal rematch. Want to fight. Yeah, I'm down. I'm down to go a few more rounds. I'm so glad ARX has changed the way online matchmaking works so you can actually continue playing with people instead of just having to. Okay, that was kind of I did not plan that. Oh, that's super dash was not good. Well, time for me. I was getting hit by that. We got to play a bit of defense here. Watch the six M like always. That's that's usually how vegeto is going to have to open you up here. Dragon rush works as well though. Vigito only has the two universal tools. He's got dragon rush and he's got six M. He's not really going to get you any other way unless he catches you trying to mash out early, which, you know, definitely gets results with Vigito specifically. Nice. I'm just going to go for the so basically this allows me to just with that and then I can immediately make him guard. I'm so I'm so upset with myself. I really messed that one up. I was too busy to focus on that setup over here going to snap me out. No, just keep me in the corner. I'm not going to do anything too. That's not that that shouldn't have worked, but it did. I'll take it. Nice reflect. I didn't think you'd have time. Honestly, if you use the beam assist, he could get us out here. Oh, it's not. Do you want to be missed? Never mind. He didn't. In fact, he didn't even need any bar. I was sleeping on Vigito there. I was like, oh, well, you know, if he gets an assist, we're dead. Nope. How about if I just do something? You're dead. I'm out. I'm out. You messed around for too long.  All right. You're getting mixed, bro. Kyle mix. What I was going to grab him. I was just going to raw command grab him. See if that worked. It did not. He started acting up before that could happen. Vigito with the kicks down into a level three. Probably go Jita's. Yep. This is a lot of damage. This is a ton of damage. Enough damage that yes, I am forced to use spark. Oh, no, that's fine. He can't do anything here. I can't believe this man just did that right now. All right. Watch the setup. Watch the setup. Oh, what? Oh, no, we didn't even slip at the back. Talk to me. Talk to me. Talk to me. Talk to me. Talk to me. Oh, talk to me. Oh, too slow. Go down. The people's hope. The spirit bomb. Let's go. I'll meet you up here. Why not? Get him down. You should have watched that for the spirit bomb. Now watch what we call the round star panic. Kaioken mix. I had to get out of there real quick when I saw I blocked that. Two supers. Did he do something? Nobody did calling it says. Oh, yeah, that's nice down heavy. Man, that was definitely a read. He knew I was going to jump and he was waiting on that level three. Final comment. How may I but again, what is the mix? He can only go overhead from here. No six and followed up. I'm expecting a dragon rush honestly at this point. I thought it would clash. We're dead. Goku has died and we've moved on to the old rocky planes shields up. I'm just going to go ahead and land a command grab.  I was definitely dead if that missed. He did the same thing I wanted to do, but just better timed. Drop it, drop it, drop it, drop it, drop it. Drop we're dead. Unfortunate May. Hi, goodbye, Goku. And hello, Super Saiyan 3 Goku. Oh, unfortunate beginning with cooler there. I'm just just taken out by that Vigito combo. We got to get back in though. We got to get back in and get these points back. Too many points are on the line to be losing. No way. Oh, you went. He went for like something real. I would have just done the auto there. He didn't block the low. All right, guard cancel. We got to keep the pressure up. Let's go. Dragon rush. We're going to start throwing them out there now. We haven't done it most of the set and that's because we like to keep them nice and. We like to keep him scarce. Now all of a sudden he's like, wait a minute. Do I have to be looking out? Do I have to start trying to take these? Watch this. See, look, he's easy. We put him in a different mind state now. He's like, I got to watch out for dragon rush. But we're done. We're actually limiting ourselves from drag rush now. Switch. And we're going to have to switch them out to beam here. That just makes the most sense. Gives us that incoming. There we go. He's looking like, where is the dragon rush?  He could have definitely punished that. I think we just got lucky. We are in business though. Oh, I thought he was going to vanish. Okay, we're going to have to take sliding. I wonder when he's going to try to spark though. Try something there. Try to get a little risque. That's fine. We'll take damage. But I'm not really worried about anything here because he'd have to get so much damage off. Yeah, even that's fine with me. He didn't combo it by all this sparking time off and this fine with me again. Reset the neutral. The sparking time is going down. The bar is going down. As long as we don't panic here, if we can really exploit the fact that we have such a big lead. But now this is where it gets a little antsy here. Where was the level three? Still mine. No way. We're losing it. We're losing it. See, even our sister starting to hit a little differently. EXTP there. He didn't want to face the fear. Oh, no, the pressure. I don't know if this is where we sparked to be honest. Now we're good. Don't fail me now. Three, four, go quickly. Let's make this a quick one. Oh, the Kyle Ken. Now, if we could just score this last win, that would be deluxe. If we could do what we did there again. But it's unfortunate that we had to play the Dragon Rush card so fast. That's that. That was like so early and so often. That's going to really stick with him now that I think we lost that option from the table. All right, he did click rematch.  Cakes in the air that was smart. All right, he's looking like he's a little more comfortable, honestly. So you know what that means. You know what that means. It's time to run. It's time to run with it. Oh, come on, go. Where was the dash? My man was just sitting there. All right, comment. Okay, is this no meter or just a little bit of meter? Oh, I thought that was cooler. Why did I bring in base crew? Why did I not bring in the cooler? That's fine. That's fine. That's fine. That's fine. That's fine. That's fine. We can still... There we go. Dragon rush, snap into this. Cooler, where are you at? Oh, bring him down. That was risky. One, two. Keep it nice and safe here. Let's go. The beams are too nice. We are just flying across this screen. The adjustments have been made. We are zooming along here. Oh, yes. Oh, yes, dude. It is. Okay. I could have done heavy there, I think. Oh, we got hit by the turn around lights. You hate to see it. It is a part of the game. I should have been blocked. I should have been more safe. Okay. Okay, I got hit. I was trying to mash in a vanish. Trying to mash in a quick radius. Just try to end the game as fast as possible. That's going to be it for the cooler. We still have a lead though. Did you see it, Spark? No, no, no, no. We go, we go, we go, we go. We are definitely good. This is probably it, huh? All right, well, I think this is the end.  That's going to be the end of this video. Hopefully you guys enjoyed it. And thank you so much for watching all the way to the end. If you want to go down below, let me know your favorite moment if you have one. And also hit the like button and subscribe if you like the stuff we put out here on the channel. You can also check out some more videos right away. They should be on top of your screen. So definitely check those out if they catch your eye. I have been Dr. Doa. Thanks once again for making it to the end. And I will see you in the next one.


Basically, some of us know each other. I work for ActiveSphere. I'm going to talk about Node.js programming patterns. I know you probably had an overload of Node.js earlier, but I'll try keeping it not really basic. I hope you know all the basics. But a little bit ahead of that, some of the issues we had when we started playing with Node.js, who am I? Mostly do Ruby. Sometimes I kind of dabble with Node.js. In one of those long hacknites, we basically built this thing called ActiveNode, which I kind of talk about some point in time. So I do a lot of small Node.js projects. Have you used Redback earlier? I guess the red is anybody? OK, so I'm the only guy. So Redback is a Redis data structure provider sort of thing. Everybody knows Redis? OK, how many? Oh, cool. That's awesome.  Just ask me. So basically, this is about patterns we learned on a bunch of small slash large projects. We'll sort of come to that. So about questions, it's really hard to answer some things that don't have context. So ask me right away, stop me. If it's not relevant or if I don't know the answers, I probably say, sorry, I don't know, and time out the conversation, but ask the questions right away. So mostly I'll be skipping the Node.js basics. It's pretty hard here, but I think it's a question that's been asked pretty much everywhere. Why Node? Have you been convinced about the Node argument? Anybody who's not convinced or who's still on the borderline sort of thing? OK, so all web apps, I do web apps. I mean, I hardly ever do anything else. All web apps are IO bound. Deal with that. I mean, it's like a cardinal rule. IO is everything that you do. Talking to the database, file access, every time you talk to my SQL, it's IO. Every time you're reading a config file, it's file IO. DNS, looking up your name to host IP resolution is even require express is blocking. Anyway, there's a require async, which does that. But general thumb rule, this is not some random statistic I kind of made up. This is reality. This is observing a lot of things, and there are lots of paper that talk about what CPU gets actually utilized.  And I haven't seen more than 10% of CPU. So basically, that means 90% of your time is basically waiting for IO. Returning data, passing the data, stuff like that is basically where your time is being spent.    So the only way forward is, can you see it? OK. Yeah, like somebody else said, I think the fonts on my machine look much better than on this. So basically, if you want to scale your servers, basically you have to use non-blocking. So Google actually targets, Google in its data center targets 80% CPU utilization. Like from 10 to 80 is like a big jump. But the only way you can do it is not by using blocking calls in Ruby or Rails or whatever. So there is a big, big move towards anybody who's doing high performance apps basically is moving towards non-blocking, whether it's a Ruby event machine or Node.js. So this is an interesting tweet that somebody else mentioned in one of the other sessions. Basically, LinkedIn went from 15, so this is, if you read this, it's their LinkedIn mobile app site. Basically, it was running Rails. They had 16 instances, and they just replaced it with Node.js, and they basically could handle 2x load with just four instances, like reduce the instances by four times and increase the bandwidth throughput by two times. That's like the things that we're seeing. And I mean, this is not like, I mean, there's always further than like hype associated with these things, but we're seeing that on our servers as well. I mean, we kind of had Nginx just fronting some of our static content, and we saw, well, Nginx is actually really good, Nginx release. It's also a reactor pattern, so it's actually quite fast. But we could actually do a lot more, like in 1.5 times more than with Node.js than with just plain Nginx. So it's really interesting. So I'm a Ruby dev. How many of you are Ruby? Like, do Ruby or play with Ruby? OK, not much. Python? Wow, OK. So I have no idea about Python. I only know enough from CoffeeScript to translate to Python, but I have no idea. But I guess Event Machine has some history behind that comes from Twisted. So Ruby has Event Machine, Python has Twisted, and obviously JavaScript has Node. So I'm just going to talk about Ruby, actually, because I don't know much about Twisted to talk about. Ruby, not all gems are blocking.  So if you want to make a HTTP request, you can't just take REST client and say REST client.get something in an event loop, because that sucks. Because if a reactor has blocking bits, then it's not scaling anymore. It's still blocking. So the only alternative is to use EM understanding stuff like a EM HTTP request or sort of do a EM differ, which is both of them kind of hacky. You have to replace a lot of code. Anyway, it's not really built to do that stuff. Or that's my opinion. I think a lot of people will disagree with that, but that's fine. So Node's pretty much, to me, it seems like the obvious choice. Has anybody seen this earlier? This is the classic XKCD about learning curves. Like the Emax is really interesting, because I don't understand what that means. Anybody use this Emax? Well, I use a little bit, but OK. So this is my version of learning curves. Ruby is very nice and easy. Like, user beginners can start off very easily. Then they hit the curve where they start following conventions, and they go to the next one, then they start metaprogramming, and it's all nice. C++ is like every day you learn something new. Anyway, get to Node.js. I don't really understand. It's just confusing async programming, right? It's really, really like basically that's a fuzzy mess there. OK, I'm going to take a short detour. Yeah, it's really bad. So we did, me and Neela sitting here, we sort of participated in this thing called Node Knockout. Anybody know about Node Knockout? Some people, yeah, cool. So basically, it's a 48-hour hacking contest. Basically, you write some application in 48 hours. Basically, don't sleep, do whatever you want. Just finish it in that time, like 29th August. And so we built this thing called Active Node. I'll just sort of show some pictures of it. Basically, it's a monitoring application. Has anybody heard of New Relic? Ruby guys? Yeah, so I mean, it's sort of trying to do New Relic. Except because Node is so isync and very dynamic, we want to do really, really, real time. So basically, you just do that in your code, and it just does magic, like almost real time magic, monitoring what's going on with your website, what kind of browsers connect to you, what are the slowest bits. It's still not there yet. I mean, it's still in the work. We don't know what we are going to do with that. Maybe release it some point in time. But yeah, we'll see. We're not really sure about that right now. Some of the learning is basically from Active Node. Like when you compress so much learning in 48 hours, for example, when you have to get stuff done and you're learning certain things, you sort of remember it. You just don't forget it, even if you hacked it in the night in half a sleep sort of form. So this is another tweet that I saw recently. It's really funny, but it's also true. I mean, it's funny because it's true. Can people relate to that? Because I definitely relate to it. I do all tested, everything nicely written Ruby. But when it comes to JavaScript, I'm like, oh, WTF. I'm sure some people agree with me on that. It's just not intuitive. JavaScript, there's so many gotchas that you don't. So this is Pit Luga. So Pit Luga is an ex-colleague of ours. And he tweeted about this, basically says, they also do a big-ish node system, which is like a payment gateway. So basically it says it creates unmaintainable soup. Yes, no. I think there are some patterns that you deal with to you start using. Some of them are just about getting your domain models right and your abstractions right. So I'm going to talk about some of that. That's basically what I'm trying to get to. I think programming is not intuitive. But if you want high performance, just with like you get so much power with node, you have to just take that responsibility and say, yeah, deal with it and do something else with it. So one thing I tend to do is like one at a time. And the first one I'm trying to target is basically use coffee script, period. There was this session, I think, in the other room about coffee script. It was like not equivocal about it. Just do it. Just use coffee script. If you're starting a new project, just use coffee script. Don't bother about JavaScript. I mean, it doesn't mean you don't understand JavaScript. I mean, coffee script needs you to understand the innards of JavaScript, what are good and what are bad. But just don't bother about writing JavaScript. It's got all the good parts, no curly braces, no functions, whatever. It's really easy to read. And I think it really generates much nicer JavaScript code than I can write. I don't consider myself like the alpha JavaScript writer. But I do OK. But still, I think it's really nice. If you have old projects, then I think my recommended path is not to do that converter thing, because it sucks. It won't work. Just basically start all your new code with coffee script. Keep your old JavaScript code. Do this fancy required coffee script and write everything in coffee. Basically what it does is it hooks into Node.js and basically registers an extension. It says anything that has coffee script is coffee.coffee associated, compile it. And it does it automatically. So all this stuff is really coffee files. I'll probably show some of them. So yes and no. So what I tend to do, I think I sort of recommend it. With coffee script, it's kind of hard to find errors, especially when you do that thing I'm recommending. So what I tend to do in my development environment is just compile it and use the, because if it sees a JavaScript file, so if I say, if I see a host.coffee and if I see a host.js, it'll preempt the JavaScript. So it'll load the JavaScript up front and not do the coffee. So in my debugging compilation, like development time, I tend to compile it and then use the JS and not check the JS in. So that works as well. But yeah, this is a caveat, though. I mean, there's no, as long as I think V8 doesn't support natively coffee script, we'll still have to deal with it. I mean, I don't know if there is a better solution to that. So I'm just gonna sort of take a step ahead and say, so there's a small problem we had with... So we embed our application in somebody else's Node.js code and it's sitting there monitoring stuff, doing current jobs to publish information about what your CPU usage is, what your memory usage is, and stuff like that. So there's a small daemon that we call tracker that runs. So this is how I first implemented. So by the way, I mean, there's a lot of code coming in front, so danger ahead. So this is my first implementation. This is really my first implementation. So one good thing I did was basically didn't write it in line in that monitor itself, but actually abstracted this thing called host.info and had a method called info. That's the only good thing that I can say of this code. I mean, anything else that you can see good here? Probably not. So this is the nature of the beast. I mean, this is the callback mess that we talk about. So one, the API is actually quite bad. The API that I used, sorry, I'm gonna have to drop it. This is apiinfo.node.getversion. Take a callback that has a result in it and basically that's a result for getversion. Oh, by the way, this is coffee script. So you have to sort of understand coffee script a little bit. Sorry, I didn't warn you earlier, this is coffee script. This is not JavaScript. So basically what it's saying is, take a callback, take a callback which does this rest of the graph. And ditto, it's like every time you see that arrow, basically that's sort of a callback. I'm sorry? With the result as an argument. With the result as an argument. So basically the background is pretty much the same. So you just have to look in the file. But can I start sticking that information into the data? Clear? Everybody seems to have an answer. Just makes no way. So the requirement here is basically I can't, I can't make callbacks to my server to post this information. Like every, oh, get environment post to the server. Get version post to the server. Get memory usage post to the server. I wanna get all that information and then post because that's really horrible. If I get 15 requests like this in like one second, I'm screwed. My server is gonna go down. So basically the idea is collect all the information and then call this callback right at the bottom. Right? This is the guy who's doing major chunk of it. Clear, right? Yeah. This is how it gets to see. I don't think anybody understands this code. This, yeah, I don't claim to write this code, but yeah, that's fine. Everybody can see this code, right? I mean it's not like really cool. Cool. So this is the second, but less complicated version.  With this thing and then do a callback. Anybody see any issues with this code? This is like a classic noob JavaScripter, right? I mean, this won't work. This doesn't work. I mean this is totally wrong. This is my classic noob mistake. So because it's async, this responses come back much later and this callback is called with empty data. So I'm basically seeing no data at all. And this is again the asynchronous nature of the piece. You just can't call the callback before getting all the data. The interesting thing though is if you go debug or something, you'll see the data in like two seconds later. It's there. But what was posted to the server was empty.  So this is my favorite part of the slide by the way. When in doubt hack. So hack another version of it. By the way, I don't know whether I showed underscore. Yeah, basically the underscore is underscore.js. I guess everybody knows that. So my second version basically is slightly more complicated but does the right thing. It works. It works because I'm doing a count. Basically, this, oh, sorry, yeah. Yeah. So basically this is trying to synchronize certain operations basically saying every time you get the result, callback here. And there I basically decrement a count. And if I see that count is less than this whole thing, I'm done, right? Am I making any sense at all? Maybe, yeah. So this is like, this is almost like a classic pattern in asynchronous design. You see this in Event Machine. You see this in Node.js. You probably see it in Twisted as well. So yeah, so this is, so basically count the pending. There are, it's kind of complicated. This is really simple because I just want the hash, right? I mean, if you want to sequence these operations as in get environment should run first and then get prefix and then get version, then it's tricky. Then you basically have to see, basically have to clone the array and do stuff. So maybe it's a reader exercise to sort of do the sequenced version of this. There are other ways of doing it. Next stick is another way. Basically, instead of doing the callback, you basically say, in the next stick, when the next reactor loop runs, schedule this, get version, or the next method. So basically, pop off the array and basically schedule methods. So that's one version of it. So as you can see, basically, there's stuff happening in parallel. There's stuff happening in sequence. Like the collection and sending to the ready server or to the server needs to be sequenced after all the parallel calls have run. So you see this pattern a couple of times and then a new flow control thing is run.  Basically, abstract this away into some sort of looping mechanism, right? And that's why they are like, I think I did a WC minus L for this and I got like 40 flow control modules which do async node.js stuff. So basically, drop that idea right away. Don't do a new async module for yourself. Understand the plumbing and scratch whatever I said and just use this thing called seek. Has anybody used seek? Well, so I'll show you the code again. Like I said, there are 40-ish async modules that run. Yeah, you just do a require seek. So it's really simple. Back again, dropping it. Basically say, wrap my execution flow in this thing called sequence. For each, it's basically parallel. Run all these pattern parallel. Don't bother about when they run. How does the order sound like? How does, sorry, what's the, no, I don't know. You want to remove these async, right? Yeah. How does the order matter? So the exact order of this doesn't matter. It doesn't matter. What matters is this callback should be called at the end of all of these. So yeah. So that's why I say this. All this should be parallel. I don't care about the order of execution. It's just this. So parallel is all of this sequence, this one. So what it does, it's quite interesting because it sort of creates a stack of all the results that each gets and it stores in this thing what this one was. So yeah, so basically it's really, I mean, I just looking at this code, this is really intuitive. I mean, there's no compromise, there's no magic. Is it like the map-reduced concept? Pretty much. That can be, like all the codes pretty much can add, say, a bunch of boxes here. Like if you can have those map-lasts, it doesn't have that. You can actually. So the same sequence is your reduce. But also, I would not think of it as map-reduced. I mean, you can do maps and reduce it and everything. There's a method called reduce but yeah, there's no, I don't think there's a correlation with the cloud map-reduced or the map-reduced. It's basically almost like regression. It's reading certain things, waiting for certain things to happen and instead of recursion. Yeah, so I think one of the other things that you could do, like I gave the next step pattern, right? Actually recursion is another way of moving it. I mean, this is like we follow, this is like a movie programmer, this is like a movie programmer, do you know what I'm writing? Yeah. Yeah, so the other thing you see is this catch-l. Basically, this takes care of your stack issues around, like if you have an error in Node.js, basically it will crash out or you'll have to handle it separately. But what this does is it lets you handle each exception at the right place and handle whatever for usage sort of thing. So basically it builds exception handling in as well. So I think like all the code probably is over now. Like, why is that? Yeah. Like, catch-error is depending on the parallel space, what happens? So, yes, so all the parallel ones continue? Anything that is parallel will continue, will not, there's no break or something. But say a couple of them change, and then a couple of errors. Yes. And still have categories moving back. Yes, so if you basically can choose to throw out, I mean like say raise from here, and say I don't want to deal with this at all, you can also say move your catch, this is like a catch on everything. You could move your catch to somewhere here, or sorry, just before sec, and say I only want to deal with this catch applies only for this parallel request and not for this sequential request. This catch will apply for everything that it gets executed. Yes, unless you throw it like you're deep with it. This basically means I'm eating it away, and I'm not doing anything, I'm just logging it. So sequential will happen, with some random junk data or bad data. Cool. Oh yeah, so the other patterns, I mean I think a lot of stuff. So I'm not a big client-side developer, so I don't do a lot of jQuery sort of thing, but I've done enough jQuery to know, like this is a classic jQuery pattern in that sense.  It's also like a classic way of abstracting your code away, like as in breaking it into multiple modules. So in Node, it's called event emitter. Everybody can see the code? Okay, cool. So basically, you do all the boilerplate stuff to set up your event monitor, and basically I could have run all the spaghetti here, and like do if remote addresses this, do this, and that, and that, and so on. But basically I chose to say, this is not the right place to handle, this is just a controller, this is not the place to handle all the request stuff. I'll push it somewhere else to deal with it, and somewhere else there's a code that is controller.onrequest, do this, right? It just, this is, this is to me, this is one pattern that I use to break out of this, that wirey nested loop, nested callback nest. Obviously it's useful to modularize your application as well. So I mean, if you take one thing away from this, basically it's like the constructs may be different, but the way you design your node application is exactly the same as you design your Ruby application or anything else. Basically think of the abstractions and abstract it away. The implementation may be different, different by maybe using event emitter or maybe using like SAC or Flow Execute, Flow Control sort of thing, but get to the right abstractions and you don't have to worry about it. It's really that simple. So this was an example of internal sort of, sort of eventing, so basically we're saying the node application itself talks to parts of the component inside the node, but it could, and we use it, we use Redis in the background, back end to sort of store all the information. And we event with Redis, well we don't use PubSub, PubSub is a really cool way of doing it as well, but we use the monitor. Has anybody used the monitor on Redis? Basically you say you register a monitor and say send me everything that's coming to the database, like any change that happens to the database, give it to me. And I think the code sort of was here. So basically you say on monitor, just give me all the stuff. So basically as somebody else is writing data to Redis, I'm sort of streaming that into this part of the code. And all it does basically is like pipe this data to socket IO, like right to the browser. So it's not even like understanding what data it is, it just takes that data, pipes it into socket IO. Yeah, so it's sort of a node I think. Like when you start working with node, there are lots of options. I could, we could choose to use MySQL for instance. But personally I think it's not evented in that sense. You tend to choose architectures that are evented. Like change happens, I got to know it. Like you don't want to put a loop around or a polling thing that says oh, if check for, keep checking for updates from MySQL and if something happens, do this sort of thing. So prefer architectures that are evented. And that's why Redis kind of fit in for us. CouchDB has a similar infrastructure in that sense. Basically it has the underscore changes which let you feed into, like see what the changes are pretty much real time. So for me, and this is my personal opinion, I don't know whether people will like read to it. But basically it's definitely, I mean like when you're using node, think about what tools you're using along with it. You can't just take a 18th century thing and like stick it along with node. Maybe MySQL is not, but yeah. So one thing to also understand is like know what, how to use common JS modules. There are a couple of patterns. I mean that's very simple. I'm just throwing it out so that you know how to do it. Like this is how you require active node. And it just exports one method called request tracker. That's about it. This is okay if you're using like one or two methods when you're exposing one or two methods. But if people know this, does everybody know what common JS is? Okay, common JS is like this common abstraction for all the JavaScript servers in that sense. So there are a lot of people who support this and this modules.exports is basically a common JS directive.  I don't know whether it's what shape it is in, but node kind of half-heartedly accepts it. I know Ryan has like a big issue with it, but fine. So it's good.  Like, yeah, I'm sort of. So the other thing that we tend to run into was node memory issues. Has anybody dealt with node memory issues at all? I mean, how many use socket IO? Yes, socket IO is known to be a big leak. So node, so I don't know. This is, I'm trying to make a controversial statement here, but having the closures and not understanding when things go out of scope leads to a lot of memory leaks. I mean, that's what my personal view is. I don't know whether like all the hardcore JavaScript guys agree to it, but node just has some issues. Socket IO, definitely. Like we just ran socket IO just, like in four days, I think it just crashed running out of memory without doing anything, without actually even publishing an event. Anybody use node inspector? Yeah, pretty cool. Yeah, I think this is my best bet with... So personally, I don't debug node too much, but when I'm running into memory issues, and like sometimes once in a while, I do. So it gives you like a nice, this is Chrome. Probably works with Chrome and Safari, yeah. So you put breakpoints. You can just sort of step in, step out, look at call stack, and yeah, lots of... You can do lots of things with it, but basically it lets you see what's on your call stack, what's lying around, stuff like that. So do that really early, because we've seen this over and over again with node, like it just runs out of memory and dies. Like my status, so there's this status dashboard thing I work on, which is looking at my production servers and saying whether this is up and this is up and this is up, but like in a few days it dies. Like I don't even know which one to monitor what with. So it's kind of funny. Like my status dashboard keeps dying, and most of the culprit is actually socket IO. I can't sort of blame node, but keep watching that. Deploy early, I mean this is like going into that agile stuff. Each platform has its own idiosyncrasy. So when we were doing active node, we sort of went to node.d, which is a joint node, and WebSocket sent work, some of our IP resolution stuff can't work, and like we said, no, we can't use node IO, sorry, node d, and like we went to join, and joined half of the other stuff can't work, and like we didn't know what to do. So at some late night debugging sort of helped us to fix it, but we went back to node.d. Yeah, WebSockets and socket IO is like pretty much, like all the socket IO needs all these ports to be open, and like it works, but if it starts falling back on long polling, so everybody knows what socket IO is, right? It's like real-time updates, whatever, yeah. So it will fall back to long polling if it can't find the ports open, or if it's not Chrome, for example, when WebSockets are not turned up. So if it's long polling, basically you're screwed, so don't bother about long polling and socket IO. So if you debug these issues right away, it will be useful. Sort of winding down now. So use a deployment node hosting sites, don't deploy on your own. It's pretty basic right now, like even node guys say, don't front it with NGINX, don't just use the node.js HTTP server because it's still not really complete, so don't bother about fronting with NGINX, like doing it on your own. Like node crashes all the time, like because if you don't do the right exception, handling it will crash, you'll need somebody to restart it when it dies. So maybe NGINX, maybe these guys are really good, so yeah, just pick one of them and stick with them. That's pretty much the end of it. Thanks. Yeah, so if you have any questions, there was like too high or too low. Sarif? Because you have to. Okay. What's your company Ruby? Oh, okay, we're into consulting mostly Ruby. It's like, I think 90% of our work is Ruby. I mean Ruby means JavaScript and everything else. And we choose to do node.js when we can. Basically, that's, yeah. So you develop a device, so yeah, we worked with PIC, we didn't actually do it, yeah. We worked with PIC to develop that. So mostly our customers tend to be like early startups and yeah, cool, thanks.