Transcript from the "Review and Q&A" Lesson
>> Jem Young: That is the end, we have learned automated deployments, we learned about databases, we learned about containers. This link slide is empty cuz I will fill with whatever questions or things you want more resources to. I'll look them up, try to find some quality ones.
>> Speaker 2: If you're gonna talk about maintainability.
>> Jem Young: I can talk about maintainability. Not related to this course, but I'm very passionate about it. I was in Brazil JS maybe about a month ago, and I was speaking and I have a whole talk on maintainability. Well, it's called Zen and the Art of Code Maintenance, cuz at the end of the day, all I care about it is running maintainable code.
[00:00:33] People say I want to be fast, I want to be sexy, I wanted to use the newest things. I just care about it being maintainable because I'm gonna be the one that has to fix it. So one of the most heated things, most contentious things that I said was that you need to comment your code.
[00:00:46] And so many people came out to me afterwards and they're like, what do you mean? I don't have to comment my code, I read this book by some person and they said, good code is self documenting. I've heard that so many times. And I disagree. You don't have to comment on every line on your code, but it's a general rule.
[00:01:03] Comment your code, always comment your code. Yeah, a lot of people disagreed with that very strongly. I don't comment my code. I don't know if it's laziness or huberous or what it is, but I'm not that smart to remember where my brain was at six months ago. So I wrote a comment just saying here's why I did this.
[00:01:23] That's it. But.
>> Speaker 3: Are you mostly thinking about commenting on certain parts of your code that somebody else might not understand, or is it just like,
>> Speaker 3: Like a bookmark, just a reminder kind of thing?
>> Jem Young: Yeah, it's things that if it took me probably more then a few seconds to reason about, it's probably worth commenting for future me.
[00:01:48] I mean forget everybody else, I care about future me, my laziness and my ability to go back and fix that. Things that should always be common, regular expressions. Always comment your regular expressions. Not everyone has the same skill level on quickly partitioning regular expression. But if you said, hey this is an email validation regular expression, that's so much faster than let me copy and paste this into some regular expression break down which may or may not tell me what it's doing in the long run.
[00:02:12] That's an easy one. What else should be commented? Don't comment your variable names all the time, but that's like overboard. Not every line but in general. If it took you time then reason about, it's worth putting a comment in there, helps just about what's happening. So that's our answer for maintainability.
[00:02:29] [LAUGH] It's comment your code, it's like the easiest one, yes.
>> Speaker 4: What's your recommendation on the tools that will enable developer develop something for the mobile apps, like Ionic framework.
>> Jem Young: Or Cordova for jobs, things like that. I don't really have recommendations. That's not my strong suit. We recently had a very long debates, at least on my team about, do we go React Native or do we go Native Native.
[00:03:16] And I know a lot of people are using React Native today. But I do lean slightly towards Native Native. Because at the end of the day, there is functionality in React Native that you're just not going to get. But here's what I always say for everything. Do whatever's best for you.
[00:03:33] If you don't want to use Vim and you want to use emax, do that too. I'd never tell you what to do, I'd just tell you how to think about it and are you solving the right problem. Let's say, do I want to use Ubuntu or Fedora instead of Ubuntu?
[00:03:47] Do that too. Like, we're just using Ubuntu. So as far as what tool to use as for building a mobile app, do whatever's fast for you. Like I said, I don't have much recommendations. But I do know that React Native is very popular, and it's doing quite well because it's half React and half actual code, like Native code, which makes it load faster than some of the alternatives.
[00:04:09] Yes, any other questions? Throw it up there.
>> Speaker 5: Yeah, could you talk about services workers a little bit cuz you kept, I mean I have looked into them. Actually saw Steve and I can't remember the other guys name. Took a Master's course on it.
>> Jem Young: Yeah.
>> Speaker 5: And it was awesome.
[00:04:27] What resources do you use to.
>> Jem Young: For service workers?
>> Speaker 5: Yeah, I mean can you just talk a little bit about it for people who don't.
>> Jem Young: Yeah, so everybody kind of know service worker, heard of it? So have you heard of a web worker? Okay, just quick high level recap.
[00:05:03] It has one thread. That's how we have to know about async and callbacks and things like that because it's just one thread running over and over and over again. Included in that thread is the ability to render the user interface. So when someone clicks that has to get rendered.
[00:05:29] So the difference between a web worker and a service worker is, the service worker is, once you install it, the service worker is still there. It's persistent, it doesn't go away unless you manually delete it. Whereas the web worker, once you close the browser, the web worker is gone.
[00:05:41] The whole process shutdown. The powerful thing about service worker being there persistent, it can read and write through a cache and it can intercept request story off from your browser. So all the thing we did with different caching, I could do that with a service worker. It's a bit, I won't say easier.
[00:05:59] There's different mechanisms for caching. That's a powerful thing about service worker because I can create an entire offline application. It doesn't have to make any calls to the server, it just works.
>> Speaker 5: And in your eyes, does that kind of replace some of the stuff you're doing with caching and headers?
[00:06:15] Or is there a place for them to coexist?
>> Jem Young: I think there is a place for them to coexist. Like we did with the expire centers, you don't always want to do that. Sometimes you want your data to always be fresh. You don't always want to cache all your work on the server.
[00:06:27] The service worker is a good way of saying I want to build our application we just built, but I want to make it work offline. Then the service worker is a great way to do that, because there are no server calls. That need to be done if you load up your resources correctly.
[00:06:40] But to do that you need to use you have to have HPS enabled which we do. And the one powerful thing about servers which we haven't really talked about is server push. It's fairly complex but it's the ability to push data to the client. I can update your cache even if the browser, isn't open even if you're not on my website.
[00:07:00] Just I'm on my phone chilling next time you come to Jem.party I can have a fresh copy of that data and you don't have to do that for you it does that in the background for you. That's a nit more complex because as you can imaging the ability to push arbitrary data to the client is very, very, very dangerous.
[00:07:16] If someone got a hold of that you can do some nasty work, but that's one of the strongest things about service workers right now. That's why I'm a big fan of them. You can also do things because it intercepts all of your requests going out and coming in.
[00:07:29] You can parse data for them. I can return data arbitrarily, if I want. I can kinda do whatever I want. It's like the last bit of control you have. If we control the file, we control the server, and now we control the browser a bit that was coming in and out of the page.
[00:07:47] So I was talking for like a year in 2015 or so, 2016, on service worker, so I can go on all day though.
>> Speaker 5: What'd you use to learn about that?
>> Jem Young: Trial and error. A lot of trial and error. When I was doing it there wasn't all the resources there are now.
[00:08:02] Now Google's pretty solid.
>> Speaker 5: Just like their articles and docs.
>> Jem Young: There's lots of articles and docs but when I was doing a lot of stuff was undocumented. It's just trying it, failing, trying it, failing and then learning. Mozilla has serviceworkers, so service workers, as a cookbook of useful recipes.
[00:08:20] Now if you're talking about serviceworke.rs, the stuff they have in there is pretty advanced. But now that you have HTTPS you can run a service worker just fine, and you can start implementing things like that. But I encourage you to look at service workers, I think they're very powerful, probably one of the more powerful tools to come out.
[00:08:36] Since Ajax every Ajax, the thing that lets you load data in without refreshing the page, its pretty cool. But yeah, that's what service worker ran.
>> Speaker 6: Another kind of rule of thumb question.
>> Jem Young: Yeah.
>> Speaker 6: Pertaining to containers, I'm guessing your average brochure website or whatever, not super useful.
[00:08:57] In your experience is there a tipping point in terms of features at which point it makes sense to begin looking at containers [INAUDIBLE].
>> Jem Young: Yeah, for one I'd say if your company architecture is structured in a way that you're using micro services, that tends to lend itself well to containers.
[00:09:16] Micro services are of course just individual time services running instead of a model with a stack. Make sense? Everybody, micro services, yeah. So instead of like one massive Django stack, I could run a bunch of little node application, a bunch of flask applications that only do one thing, that's micro services for you.
[00:09:35] I'd say if you use a lot of micro services and you need to scale broadly, it's a good way to go. The downside of containers are the more complex you make your deployments, the more things that can go wrong. Because you're just adding more and more complexity to your entire stack.
[00:09:51] Some people don't like containers for that reason cuz it's just easier to bring up, just Ubuntu server. With everything you need for the vagrant script or nacipal script and everything like that. It's just as easy. And if you don't have a lot of high, like down time is not a big deal for you or you just have good deploys or good fail overs, then containers are probably a better way to go.
[00:10:12] But again, the deeper you go, the more complex you go. So we're running Ubuntu. It's not necessarily the fastest version of Linux but it's probably the most user friendly. We could run something like RedHat, which is Enterprise Linux which is much much faster. It's optimized for these things but it's not as friendly.
[00:10:29] And that's kind of the trade off you always make is you want speed, you want efficiency but you also want full tolerance and things not to go wrong horribly for you. But, good question.
>> Speaker 7: The front end put a lot of thought into how to manage state. Is there an equivalent to that on the backend?
>> Jem Young: Can you explain it like, what sort of state?
>> Speaker 7: So as you, you always want to have either, you stayed isolated when you mutate it or it's shared across different aspects of the application. I just don't know if there's an equivalent in the backend. Or if state is something that's kind of just for frontend people.
[00:11:13] Do you know what I mean? Yeah it seems like, it seems like if you had your server you could just restart your server and then kind of always control where, if everything's clean and if there's not gonna be any sort of unexpected errors occurring but I just wanted to make sure.
>> Jem Young: That's essentially true.
>> Speaker 7: Okay.
>> Jem Young: One of the hardest parts when I first started learning about the web a long time ago was that it's stateless. Because for me coming from Java and C # that's a weird concept of being stateless what I do now doesn't necessarily hold on the browser.
[00:11:44] The back end is fairly stateful, as in what you do is gonna persist and persist and persist unless you take down the server and start over again. There is not really an equivalent of that for thinking about state management. But now you're talking about the difference between micro services and a monolith.
[00:12:00] In a monolith it's much easier to keep track of state because everybody knows about the state. It's shared across all of the services you're gonna use versus micro services you have to think much carefully about. What's the API that's on for my node servers talking to my logging servers, things like that, where the logging server could lose state very, very easily versus, in the nodes it was like, what happened?
[00:12:23] I sent you all these logs just drop them. That's pretty nuanced, but does that help at all?
>> Speaker 7: Yeah, you still have to very carefully design certain things so that you're not fucking things up I guess.
>> Jem Young: Yeah, and that's why like you see the trends in the Internet.
[00:12:42] It was like micro services, that was probably two years ago. It's like we are going to micro services. They didn't need to necessarily, like a javastack works just fine. Running rails or jenga works just fine. Not everybody needs to do micro services, because again, it's that introduces complexity of state, how you design APIs for all these services.
[00:13:01] Whereas, a monolith, not as sexy, a bit harder to maintain over the long period of time, but it all works, you don't have to worry about things like that. Great questions! Anything else? Anything about computers? NetFlix? I'll tell you everything I know, things I don't know.
>> Speaker 8: Heard that they only hire senior engineers.
[00:13:21] Is that true?
>> Jem Young: In a way. So everybody at Netflix that's an engineer is a senior engineer. Like we only have one role. It's a very flat structure. So it's basically, I can tell you the whole structure, that's how easy it is. It's [INAUDIBLE], manager, director, VP, probably another VP.
[00:13:40] There's like senior VP and then there's like c levels, this like that. And that's it, that's the entire Netflix structure there. So if you're hired at Netflix, you are a senior engineer. Just graduated college, that's pretty unusual for us to hire someone with no experience. But you're senior and the benefit of this I prefer over things like he's a tech lead, she's a senior architect things like that is that when everybody's the same level, I have to listen to what you say.
[00:14:08] I would do that anyways, but you have to acknowledge what you say versus if someone say a junior engineer, I'll be who are you? A junior engineer, I'm not gonna listen to your suggestion, what do you know? And that's an attitude a lot of people have. So when everybody is the same, it makes everybody's opinion equally valued, which I really really enjoy.
[00:14:25] So it doesn't matter if you been there five years, it doesn't matter if you've been there a day. You're all senior engineers. Yeah, yeah, all right, yes.
>> Speaker 9: So I was gonna ask what kind of, you mentioned like there're trade-offs and more monolithic structure versus my micro services, what would you look at to sort of determine what architecture makes sense for a given company?
>> Jem Young: Yeah, great question. So how would I determine if I wanna use a monolith versus microservices? I would look at the programming skills of the team. That's kind of an unusual question, but what are they good at? Facebook saw that, when they started, they had a bunch of PHP developers.
[00:15:05] PHP was much more popular back then, and it's still pretty popular. But they're saying well PHP's maybe not most efficient thing we want to use. So they wrote a compiler that compiles PHP to C or C++, I forget which one. The compiler. And that's an instance of knowing the seals of your team and knowing what they're showing at.
[00:15:36] Where is the business gonna go in the future? Do you want something that's easily maintainable? So if we all know node let's just make a monolith out of node because we all understand how that works. Or if we're gonna grow in the future so we say, the part that logs transactions, we're gonna make a lot of money really processing credit card transactions.
[00:15:53] Maybe that's for your micro servers cuz we can scale that out as opposed to having to scale the entire monolith, even though it's only one portion that needs to be scaled. So it's a hard question, it's really dependent on your business. But hopefully that helps and guidance. But as with all things, don't jump on things because people say so and cuz it's popular, make an informed decision.
[00:16:13] And then that's as good as we can do for most things. Think about it.
>> Jem Young: All right, if there's no more questions, I will wrap this up, let me know, I'll throw in some links at the end to other Frontend Masters courses about service workers and bash and things like that.
[00:16:33] Send me an email. Gem@Netflix.com, if you have any trouble, some people do. You can Tweet at me, send me a message on Twitter @JemYoung if you like, just say hello. I always appreciate good feedback. People that say you could have done this better or I really like this.
[00:16:50] My favorite at the people that finish the course and now have jobs because of maybe some portion they learnt. Or they brought website or sever because of something they learnt. That always makes me happy cuz it takes a long time to put these together so it's good to know that it's worthwhile.
[00:17:03] And if you have any courses you wanna hear about, like full stack three if you wanna do that, just anything at all something that you wanna go more in detail, sum it up. I am here, I'm pretty slow to respond, but I will respond eventually. If there are no more questions, thank you!