 Ground control the major Tom. Hello. Can you hear me? Okay. Okay. It's on right good So yeah, I'm James long. I work for this company called skybox imaging. We make imaging satellites I got to go through a little bit of a primer So we're all kind of on the same page and then we'll get into the case study kind of about you know flying satellites or browsers So I'm just kind of get us started off here this There's things in here that the government likes to regulate that I can't necessarily go into topic about So others this organization called itar or the international traffic and arms regulation And they have a lot of concern about things like guidance systems Go figure so there'll be some things around the talk that I can't necessarily go into exact detail on you'll find that There's not like specific huge code chunks that might have things like spacecraft telemetry in it things of that nature Yeah, but I think I'll get the concepts across the you know from our case study here So basically skybox we process and take Satellite images, so we kind of you know supposed to be this big data aerospace company But we'll take you know like a picture of a parking lot count how many cars are and then can sell that information for example Which could be pretty useful depending on who your competitor is right There we have licenses right now to launch two imaging satellites We're on 80 people and we've raised about a hundred million dollars. So yeah, so that's kind of a quick introduction to the company So let's get to start it here a little bit about satellites and telemetry and all that jazz our satellites are going to be in a low Prolar orbit right so basically this means you got the earth floating up here and satellites kind of go All the way around and it's rotating as it's going around and it's taking pictures of the earth as swaths kind of going around You can see kind of in this photo Low polar orbit, but I mean low earth orbit puts us in around here. That's like no gravitational pull That's like the moon. That's like GPS satellites So we're right down in here. So you can kind of get an idea of where our satellites will be There's some caveats to this thing since the things always floating around right you don't always have radio contact with this thing Right, so they we basically have this thing known as a communications cone Or it's like a window of time that you're allowed to talk to the satellite because that's the only time they can get a radio signal up through the atmosphere to go. Hey, how you doing this guy sat one and And So due to that we have like these contact windows that could range from you know Maybe eight to 15 minutes depending on what the weather is and stuff like that So that kind of impacts how you write software, right? So keep that in mind So telemetry so this is what this whole dang thing is about right? This is basically those bit streams that data that comes down from the satellite and basically References some kind of sensor on the ground station or in the satellite itself And that could be anything from like a temperature sensor to ohms of resistance It could be to amperes it basically tells us everything we need to understand about that satellite and there is a lot of them I can't go into detail how many but there's a lot trust me So important to remember now when we're basically so what what happens is that? Says the satellite's floating around and as we get into that communication code Cone the ground station and all the little dishes point up at and go hey sky said one How you doing and then they they open up this bit stream communication back and forth this comes into basically a magical black box Which is the ground station and an antenna ray you guys don't need to worry about that at the end of the day All you need to know is that this converts it into json? so Yes, and then we can do whatever we want with it Okay, and this is two-way by the way, so this from the browser goes all the way up through so think about that Okay, so like I said, this is a case study So basically our first project with skybox is basically building like some kind of user interface for Purchasing satellite images and then our product team comes up to us and goes hey a friend and engineers. How you doing? I need you to build mission control. I See okay Interesting so these images start popping up through your head, right? I mean you got like 1960s NASA and the Apollo missions and kept caught on you know And all this other stuff kind of going on back and forth and you got modern NASA with Mars and Hubble and all that stuff happening And then of course David Bowie pops in your head and you can think as major Tom to ground control but It really is serious business at the end of the day, right? And it's kind of an exciting opportunity because you think about it, right? I'm writing software that could work on my phone that controls a satellite in orbit. Okay. That's kind of cool So the first part of this project is basically in which is what this case study is about is basically building telemetry screens So this is what you basically see in like those 1960s NASA photos of a bunch of people floating around a terminal screen And it's got all these things coming up and this is where they like the the mission operations manager Excuse me mom Actually goes, you know status check and they're like check and they go back and forth that okay We can launch the rocket press the big red button, right? That's the kind of thing they're floating around so they're monitoring those different aspects of the spacecraft or in the ground station to Say everything's within tolerances and we're ready to go and this goes as well for the communications of the satellite and you Know making messages across so it's very important that they have an easy way to access telemetry data That's extremely seamless to them, right? So we went about this there's some you know core requirements at the end of the day we had to build a very strong prototype because Building mission control for an imaging satellite, you know over a browser not really been done before So we'll use the prototype to help found or some of our finish off our product specifications We'll also use it to test the type of software. We're going to be using the right that aren't thing, right? Performance the thing has to be fast. I shouldn't even have to go any more top one to that I mean it's given what it is right time. I You know using the old just get time and JavaScript or pulls off the client not going to suffice Apparently they want the mission operations control system to have the same time as a satellite How the heck you do that? That was kind of interesting has to be reliable. Obviously if the thing breaks Not good See and of course it needs to have a very quick and easy to use interface because they have an 8 to 15 minute window If something happens during that 8 to 15 minute window and they need to change up with telemetry They're looking at they have to be able to go in real quick build up a new screen or get some new data And then get that going in that same time slot So it's very important that an operator can go in there and manage this quickly and At the last but not least and probably the most important you have to test it. Oh, man Yeah, so that one's fun. Okay, so getting started. So we started off with the dang prototype, right? Couple big things that we were testing for here, right? How much can the browser? Process when it comes to DOM manipulation because we have a lot of telemetry in there And there's a lot of things I get updated every second, right? So we just wanted to see what we could handle there the communications mechanism How are we moving data back and forth between that magical black box and the browser? So, you know, this is like, you know, your comet versus web sockets versus magical Browser smoke signals. I just invented that protocol actually Yeah, so, you know again time management stuff. How do we handle that? We need to create some kind of real quick framework. We need to play with new HTML five features So this is put in for my manager because he wanted HTML five in there And we need to pick a browser. Oh, well, isn't that awesome? So we're building grounds ground control. We have the hardware We get to specify what browser to use and what version it. Yeah, I just kind of giggly about that All right, so going on so some lessons we learned with this prototype first of all, I Get some responsibility for this horrible back axe Outwards design. So this is what the first prototype look like as you can see it was hideous In fact the admission operations people like the engineers. I would see them occasionally looking at me doing one of these And I was always afraid to start my car So we had to do something to correct it But at the end of the day, honestly, though prototyping is one of the best ways to learn because we were able to test all this Functionality we learned before we actually started the real thing. We created a lot of throwaway code at the same instance There's a lot of stuff that was reusable. It came out of it totally worth the effort So talking about that prototype and performance the things that we kind of learned so the prototype originally just you know Keep in mind prototype was dynamically creating like 15,000 DOM objects on the fly Representing different aspects of telemetry about 10% of that would be updated every 10 seconds. Well damn So Firefox didn't hold out too long Chrome did okay So what we did is we attached, you know, we need to do you those ID lookups are supposed to be fast, etc So the lookup would take 3% of the CPUs time in Chrome Then to update just the DOM value. We'd be looking at 2.5% of the CPU cycles. That's ridiculous 5.5% of the time just updating the DOM. Come on, right? Some of the nodes Shame to talk about this one So we had there's some clocks on the page, right? Just to make sure they get the they're always up to date, right? They let you know what the latest time is from the packet that we receive This is really good if you're a mission operations person because then you can see everything's in sync and working properly Well, like an idiot. I said every single time we get a packet update the DOM Yeah Yeah, I thought my computer was gonna fly the Mac Pro CPU fans very sturdy devices. I tell you Firefox crashed like that But yeah, Chrome actually lasted in there a good five minutes that kind of helped kick it in for which browser we use them But that quickly changed. So what the heck do you do to kind of correct? You know bad stuff like that So first thing is come to find out You don't need a Gmail like application when you're building telemetry screens because you only have a few points You're really actually ever looking at and if they want multiple screens What they do is they just open up new tabs or new windows and then they tile them together in those big Displays they have up at mission control Well, awesome. Cool. So I didn't have to display as much in the DOM next thing we did is We shouldn't do the look up each time So we actually created a DOM reference object when the page is initially admitted Which actually will pull all the reference to the related telemetry store that in memory And so that way whenever you have to do an update It's just a quick command do an inner HTML and so we went from like a 5.5% of the CPU cycles updating the DOM to point zero four Not bad not bad So Yeah, so then the other thing with that crazy clock mechanism where it was making the machine fly literally So basically just do this very carefully. So what you want to do is interval So you'll you'll store that every single time that packet comes through Yeah, update something in memory, but never display in the DOM put some kind of a timeout on it Have it update every, you know hundred milliseconds or something like that They probably won't notice that and machine operations, right? Okay Yeah moved over to CSS animations So there was some a JavaScript animations because they wanted things like if the data was stale to fade out Makes sense, right? So we moved over to CSS animations. I gotta say huge performance it I mean performance increase excuse me The we moved away from sprites and we base six and four coded all of our images and hard-coded them into the CSS files It's like sprites, but better So basically there's some really great tools for doing that. I'm sure most of you guys are familiar with that process So moving on here back to performance. Oh, this is my favorite part of this So so you're trying to think communications mechanism with the browser over some kind of a magical black box server How do you do that? Right? What's in the course? You know engineering management comes to you and says this needs to be rock solid reliable and it needs to be implemented yesterday What do you do? Right? And so the first thing that comes up is rock solid reliable something that's tried and true Obviously it's comet architecture. It's been around for ages. It's just native Ajax It works works on every browser debugging is easy because it's an Ajax call, right? It's not a whole lot to that Yeah, it's you know, like I said, it's tried and true The other thing that helps and this is a big plus out to the jQuery folks out here is that active mq Which is our part of our magical black box Actually had a built-in long pulling driver of Britain and jQuery So that was pretty quick to plug in Yeah, just a common web model so you're all familiar So basically sends out a request There's a timeout in that if it doesn't receive the request in that time period it'll bounce and create a brand new request and Then when it receives an event within that timeout period sends that data back to the front end front end will then instantiate a new Ajax request that goes back up to the server and waits So what ends up happening is you get this middle wear a layer of just communications time back and forth and that was that was fun So this created some issues with us So the request for asynchronous which is awesome. It's the nature of Ajax, of course, right? No figure. So we had to have like architecture in place for like keeping sequence numbers Doing time checks on the packets to make sure things under of auto order Because you know the operators might be a little ticked off if the batteries fluctuated Yeah, things like that So and also created some serious latency in the request because you have the communication time back and forth And it's making the request back and forth back and forth and reopening. It was a little bit rough The the thing also was buffering back onto our middle wear a layer So we actually had a pretty robust middle wear a layer with a lot of memory to handle the wait time So you'd open up a connection It would it would open up a contact with the back end and it would say okay I'm waiting for you to send the next question. So the next the next Next Ajax request so in the meantime, I got a buff for this data So I don't lose it and then I can send it to you when you open up your Ajax request back to us So this is when you start talking like 50 terminals connected It was starting to add up and putting some serious stress on hardware One other thing that was just bizarre active mq wrapped all their objects on XML for the Ajax request So we had XML wrap JSON That was awesome. Yeah, and it was like we'd had to recompile the thing because it's in Java, so Firefox had huge memory issues like when it was processing these large packet requests So like the initial when the satellite first makes contact it goes. Hey guys that one. How you doing? And it would say hey here's a ton of data and it would come down and then Firefox would go Holy smokes, and then it would actually break the JSON parse. I don't know explain it We try to valve a bunch of all other things we'd actually get returned from that native function a half String like it was just messed up only in Firefox Web kit worked fine Anyways the parsing of all this the Ajax request all this stuff was taken up basically 8% of the CPU cycles on one satellite What if you had contact with like two satellites? You can start seeing the issues here, right? So the developer stood up and said no, we can't take it anymore. You're crazy We need a sprint just to redo this and rethink it and so we finally finally got that and oh Web sockets. Thank you. Love you web sockets. I came into play So basically it's a full duplex TCP IP connection the handshakes done over port 80 or port 443 so you can do secure web sockets Might be important when you're maintaining spacecraft telemetry that it's secure, right? Okay, and supported by all the major a gray browsers except for IE of course And IE you can get to work with a flash hack. Let's see here It's got an easy set of methods and events You can read up about there. Just a quick example so you can see how the thing works open up a web sockets Create a message send the message receive the message close the connection Wow That was easy Okay, so so we learned some lessons though with web sockets that are kind of important to share because this is a case study Remember this isn't like a theory web sockets 101. This is real real world stuff Create a centralized event library for your web sockets this data needs to be Accessible anywhere inside your application anytime you get data through have a populate an event that's globally accessible very important You don't want to repeat this Let's see jetty eight which we're using those are in middleware. We're not using node I know cringe you can feel free to get out of the way cringe So jetty eight was what we're using Part of the issue with jetty eight is it actually time out after five minutes if it doesn't receive a message from the client Some kind of a we had to figure out some way to keep these kind of connections open also the browser didn't time out So we started a two-way heartbeat So like every second or so the the server would send a message to the client and say hey, I'm alive And I'm gonna send you some other important information that I'm gonna talk about later and then we reply back and say hi server and so that was great and So we went from an 8% hit basically to something like a six point six percent hit just managing communications so also a sizable difference and We don't need nearly that has heavy of a middleware layer at this stage. So very cool stuff. I highly recommend web sockets Architecture also very important, right? So we started off of course, you know because we're prototyping We start off with this model where the modules are data independent They can call anything they need and get access to anything they need I seem like a great idea at the time because they can go anywhere do anything they want You know just kind of like two-year-old kids in Kmart but This turned into a bad idea You end up getting this thing where things are calling similar data sets and they're doing funky things They're all asking for different click events and it would just became this giant soup And I got really complicated when they came back and said how the hell you test that and I was like, oh You're kind of right. So we switched that out to more of an adventure of an architecture So basically the modules and so in the application level itself We have standardized libraries for your timer restful API calls the web sockets and then event delegation Which all happens at the page level actually or can be attributed to module level depending on how heavy it is So anything you get spawned out goes out to like an event dispatcher I know I was talked about earlier that you shouldn't use your document You can specify whatever you want for that event dispatcher But documents what everybody's familiar with So once you get so basically any data that comes in gets broadcast out to this global scope Then anything else any module can listen for that data and then do something with it Right, which was a huge improvement because then all of a sudden things started working like Unit test like I could simulate clicks on things globally and it would work I could you know Process data because all the data was driven by an event too, right? So I could false falsify data in there was very cool and then other applications could also tie in so We basically dropped it on a callback hell out of it and it's been a huge performance improvement for us Moving on to the event-driven model. So I'm kind of more of a repeat of what we just talked about here drop the callbacks So, you know Any basically anything that's reusable on the page gets a standardized library Which then we'll rewrite back out to a page level event So any module or any part of the application or even externally of the application you have access to that data Which makes it yeah ridiculously easy Moving forward one thing that might be a little controversial as we moved away from a we moved over to a prototype inheritance model from a like a module pattern You can just see the specs on this if you haven't already I suggest you do Yeah, I'm gonna go into more detail on that Okay, managing time how the heck do you sync? Skysat one and my browser It's not a magical get Skysat one time native dump and that native JavaScript function apparently So what we did for that is? Yeah, first thing don't ever try to create your own timer just just a bad idea It'll wander very quickly because of the processing time to actually increment. It's just it's stupid. Don't try it Yeah, so next part so well then it's like oh, it's obvious right because the server time is already kept in sync through some other Process will pull the server time off and then when the page of nets will do that We'll just pull that so that's great But then you can't always guarantee what the the time is to execute the JavaScript on the page The clock's actually inaccurate So that kind of was like hmm. What do we do with that? Oh? Yeah, we put that heartbeat thing in right just send the server time on with the heartbeat And then we can use that to re-sync to completely synchronize our clocks across the front end Well sweet it actually worked really well, so web sockets in time. It's a marriage made in heaven You know, there's just some simple logic in the JavaScript Basically does a comparison with the internal JavaScript timer to figure out what the actual accurate time is And then you get the nice little you know QTC time down here that anybody can trust One other thing that's important to think to is in our initial application We had a little set timeouts throughout the S throughout the apps to make things fade in and out or to Update like different monitoring tools and stuff like that. It was extremely jarring to the user watching things Like that was a bunch of camera flashes happening So what we did is created a global event library so basically every 500 milliseconds of broadcast the time to the application and also would Act as a place for any module to tie into and set increments on so you can say like I want this to happen in Two seconds afterwards tie into that event increment to you know four times and then you got your timer There's one set timeout for the entire app Which was pretty slick And then all of a sudden all the modules across the page Sort of working like that very saying to very synced up But this was a very clean approach and also probably saved us a little bit on the memory footprint We went on The reiterating basically some of the stuff we talked about here Reliability the event driven architecture got us a lot web sockets, of course The one other thing I want to mention here, too Is that we want to provide Proper user interface because at the end of the day this has to be reliable, but it's probably gonna fail I mean things like that stew fail So we have things like red alerts in our application that let you know that something bad happened And we're very specific and let you know, you know the Web socket connection failed They were just proper air reporting has gotten us a huge very far with that Okay, yeah, the dynamic interface. So this is that seamless interface that Operations engineers will understand learn and love And of course products want it goes. Oh, this is the product manager's dream And I'm sure you've all heard I want drag and drop interfaces and to be super dynamic and yeah I want I googled 3.8. Yes. Okay, great So that's what they kind of came up with us and you know, we're like cool We can work with that because we're using jQuery, right? So we utilize the UI library for things like drag and drop Autocompletes and external widgets like the data table to show certain Certain things as well. Honestly jQuery. We love you. Thank you so much You made our life so much easier on this regards One other thing since they wanted a dynamic interface Well, we need this kind of your separation of your data in your view and stuff like that So what we actually did is all those different telemetry screens are actually report back to a JSON object that's stored on the database and Then that's used across the board for display purposes or updating or anything of that nature or editing it It'll just update the same JSON object will get stored back to the database Also makes it super quick for things like security, right? Because you can just say you just don't have access to certain objects and The one of the other things that we do with it, too With the web sockets is anytime that you like are working on a page and you edit something It's real-time save so it's like Google Docs, you know, I mean so anytime you update or there's a change event fire Just a new version off to the database and we have a complete change log of everything. That's actually happened in the screen So it's kind of slick Let's see going for here. Okay. Now the fun stuff the demo, right? So we went from this horrible God awful prototype to basically forming telemetry screens Just took a little bit of work to get you guys just even see something because Yeah, all that itar restriction stuff So if you're a mission operator, you're gonna come into this the first thing you'll see is like some kind of a dashboard terminal It's like, hey, what kind of screen do you want to monitor today? Oh, I think I want to monitor the ground station status Oh, and then these are your telemetry points. Oh crap Yes, you're missing the special glasses that let you see anything Can you see that Yeah, yeah, oh, oh, yeah, no Of course All right, well, I blame that on jQuery, of course That is their auto complete So just easy so we did modify obviously the jQuery auto complete here to do some fancy stuff So it's really quick to ground whatever And so that's the ground station. Of course, this is a quick. No, you can resize this guy This should plus up. Oh, well, that's a little better, huh? Okay, so that's that's a telemetry screen Of course, I can't get telemetry flowing back and forth here But I do have a playable demo for you. But first we'll move on to the actually no one I'll try that first. Let me get the pull the video over here Okay, so your admissions operations and you need to understand what the ground station is doing because you need to say When do I have a contact so I can send data? So this is simulating a satellite contact with the ground station We can't show satellite telemetry with some ground station. Deflametry is considered okay to demo So see if I can get this to blow up full screen here All right, so there's a little bit of a so there should be a countdown here. It says basically This is from the right spot. It is not. Yeah, I think video All right So basically what's happening is these these modules on the side here will light up and let you know when Ground stations are about to receive contact and that syncs up and says okay. I got contact now You have this along with the satellite and then things will start lighting up in here and say hey This is saying that we have an active connection and then the mission operator person and go so hey mom It's okay to start sending commands now. We're good. We're good And so that's this is like a typical screen that they would sit around in that room and monitor singing an idea So not quite as fancy as like the joystick or the PlayStation control. I'd hope to originally build on top of but That's what mission operations likes so And this is that seamless interface we're talking about so of course with the help of jQuery You get things like drag and drop you can add new modules and You can delete out things and this makes it really easy for them to create a custom screen that monitors telemetry So that's a lot of fun So all right Back to the demo in hand here. So last thing. That's obviously the most important is how do you test this thing? one of the things our engineers have built for us is anything we recorded back from test beds or satellites that are kind of Is that we have a telemetry replay feature? So this basically what it'll allow us to is Force feed as much data from the spacecraft as we want through the Web socket Yeah, it's kind of the death nail actually so you can say like I want you know 100 days worth of data into the browser in five minutes That's fun. So it's very good for stress testing for doing that kind of stuff The one other thing that's very important that we I don't think gets enough credit as grease monkey is a testing tool So one of the things we do is we'll actually inject a grease monkey script which can simulate events inside to test the interface So if there's telemetry that hasn't been say a new parts coming into the ground station hasn't been installed yet But we have to test the interface so it works out the door We can actually generate that telemetry and then force feed it using grease monkey script into the browser to simulate the interface so That's been a huge help for us and our QA actually loves that Q unit test on any of the major libraries G unit tests on any of the pipeline stuff that's happening on Selenium of course for spot checks on the interface great QA that understand user interfaces is a huge plus and then standard release plans This is all standard stuff you guys are used to So in conclusion remember Web sockets are greater than all If your manager ever comes to you and suggests long polling We have a win at 100 number that we came up with to take them out and make them an offer. They can't refuse Yeah, utilize standard libraries the venture of an architecture At the time is also vitally important keeping those things in sync and DOM management So again reducing as much lookups to the DOM and as much input to the DOM as possible So any questions, you know, feel free to hit me up