Real-Time Web with Node.js Real-Time Web with Node.js

Adding Help

Kyle Simpson
You Don't Know JS
Check out a free preview of the full Real-Time Web with Node.js course:
The "Adding Help" Lesson is part of the full, Real-Time Web with Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Most command-line programs have a help system that provides instructions for how to use the program. Kyle adds a printHelp() method that will display these help messages. Hey also spends a few minutes talking more about the "middle end" area where he sees a place for Node.

Get Unlimited Access Now

Transcript from the "Adding Help" Lesson

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kyle Simpson: What's another thing that we oftentimes find with command line programs? What happens if you use a command line program but you don't pass the right parameters, what does it do?
>> Speaker 2: It shows [INAUDIBLE].
>> Kyle Simpson: It shows some sort of help, right? Why don't we make our own help?

[00:00:20] So let's write ourselves a function, I'll call it print help. And this is the dumbest and simplest way to do it. There's packages out there that automatically make these helps for you. I'm just showing you how we might do it. I could say, console.log 1.js is the name of my program.

[00:00:37] And for good measure, I'll go ahead and make sure to put my copyright statement on there or whatever. Then I could say console.log and give myself a new line and console.log usage and console.log that I want it to take in the help. When I have help, I want that to print this help screen or if I were to pass in name, I want it to print, I'm sorry, say hello to name.

[00:01:22] Okay, so this is just a simple stupid way of creating myself a little help program or a little help printer.
>> Kyle Simpson: [COUGH] So what we could say here, rather than before we assign to that name function, what we could do is we could do some checks. We could say if args.help, which means that you passed in that help parameter, or you did not pass in an args.name.

[00:01:54] If either one of those things is true, let's print the help and then let's exit our program. And here's another thing that you need to know if you're writing kind of these command line node environments. How do you end a program? In JavaScript in the browser, you usually just return but that doesn't really quite work here cuz we're in a global scope.

[00:02:14] So the way you do it is to call process.exit(), which is a function, and you can give an exit status code like one or zero or whatever. So when you call process.exit(), it will immediately terminate our process for us. So now we have a program that's actually gonna validate that we're gonna use it correctly and it won't allow us to get into one of those conditions where we have that unnamed thing.

[00:02:36] Let's try. Let's go back to our command line, I'll say node 1.js. And I won't pass anything to it. And it prints out my help for me. Or I do node 1.js and I actually manually ask for the help. It also prints out the help. Or I say node 1.js and I actually do it but I give it the wrong parameter name.

[00:03:01] Still says nope, you're doing it wrong. But when I finally figure out how to do it correctly, now my program works. So, in just a few lines of code, we've been able to create a basic first pass at a command line tool that we could do any sort of utilities or reusable work with.

[00:03:21] For those of you that are just joining us online, we were discussing more about the middle end stuff over the break and a few people rightly called me on it and said, well, that's all well and good but organizations struggle a lot with the internal politics and trust issues and things like that.

[00:03:36] And is it even practical for them to do something like what you're suggesting? It's tough, it is a battle you're gonna have to fight as I said yesterday. You lose 100% of the battles you never fight and only 99% of the battles you do fight. So it's tough.

[00:03:49] You're gonna have to have some tough conversations with them that say things like, why is it that you don't trust that I could write the data validation rule in a way that you could rely upon it? Why is it that you feel like you need to do your own data validation even though the code is already within our server infrastructure and it's auditable and it's provable that it's correct, why is it that you don't trust it?

[00:04:11] There's some internal trust issues, there's some internal communication issues that are certainly happening. So one of the questions that was being posed is, what exactly do you mean by this middle end? Or what is the scope of it? The way I like to describe it is that I call the middle end the bottom 10% of what happens in the browser and the top 10% of what happens on the server.

[00:04:32] And everything in between, i.e., all of the Ajax communication and loading headers and caching and all of that stuff, that's middle end to me. So if you suggest to me, if you say, which is rightly true, there's no current job postings for middle end architects. If you go and look for it, probably not gonna find it, right?

[00:04:52] I coined the term middle and like four or five years ago. It basically never went beyond my blog posts, right. So there isn't middle end architect as a specialty. There's middleware, people do middleware, but you don't really find people being a specialist that does nothing but middleware stuff.

[00:05:08] What do we do about the fact that we're not staffed, as you said, I was asked? We're not staffed to have people to handle middle end. Well, what I pushed back a little bit and I would say, you already have somebody writing that code. The question is whether or not that person is properly skilled to be writing that code.

[00:05:26] Because right now, you have backend people that do not like markup, I'm painting with broad strokes, forgive the generalities but you have backend people that generally speaking don't like the complexities of cross-platform, cross-browser, markup issues and C.S.S. and stuff. And so instead of dealing with that stuff, they write a servlet it or whatever to automatically generate that stuff for them.

[00:05:50] That doesn't mean that that's the proper way for that stuff to get architected, it just means that that was the only guy on your team that at the time you were willing to trust to write markup and he didn't want to do it so he found a tool to do it for him.

[00:06:03] Well, then you do probably, in most companies, do have JavaScript developers who are writing jQuery and they're modifying your page at runtime and things like that. Aren't they more aware of the structure of the page and how things work? And aren't they more well suited for understanding cross-browser issues and rendering and CSS and stuff?

[00:06:24] Isn't it that person that really should've done the markup? And perhaps if you can answer even a remotely close to yes to that answer, then perhaps that's the person that should be handling all of your templating, instead of your backend developers using servlets. So I don't necessarily think that I'm suggesting that you need to go out and hire a whole batch of middle end architects.

[00:06:48] I do think you might need to retool some people. There might need to be some people that give up on stuff that they've been holding onto as their sacred cows of saying, this is what I get to work on, they might need to give some of that up.

[00:07:00] You might need to have some people crosstrain on different skill sets. You might need to have some people learn JavaScript that have never learned before. But I do think it's possible to retool an existing team to use this architectural concept well. Yeah.
>> Speaker 3: There was a question from Oliver K, if there's a way to integrate node as a middle end for various CMSs?

[00:07:22] I think he's looking for just a simple, yes there is or no there isn't or it depends. But obviously I think a detailed explanation would probably be [LAUGH] out of scope for this workshop.
>> Kyle Simpson: A detailed explanation would be its own week-long workshop. I did write a blog post specifically about this topic that I can point you to.

[00:07:42] That was asking the premise, what would it look like to middle end WordPress? And the premise or the thought process behind that post was, what does WordPress do well? And what does WordPress not do so well? And I know that's a flame war waiting to happen. But the simple answer that I gave to that question is I don't think WordPress does so well at theming and display.

[00:08:10] But it does do a pretty decent job, at least for what it's designed to do, of managing the back end data and the database and all of that. So could I turn WordPress into a headless black box? Could I turn it into a state management machine that didn't do any display at all but it did what it does do really well?

[00:08:28] It manages log-in sessions and other state and things like that. And what would it look like? And it turns out there was already a plugin written for this, but I theorized that you could write a plugin for WordPress or theme plugin for WordPress that instead of doing any kind of markup generation or anything, all it did was present the data that it would've normally marked up as rendered markup.

[00:08:52] It just presented the data as JSON. And then you could have a middle end here in Node or whatever that consumed JSON from your backend, your black box back in WordPress, or any other CMS, for that matter. And it receives the data, and then you'd pump that data into your own templating engine and that puts you in control of the presentation rather than your CMS.

[00:09:14] So that's just a 50,000 foot view of how you might go about that. I think it's quite possible and I think more people should do that. All right, [COUGH] I like the questions about middle end, it lets me think that even if even it offends you or if you disagree with me, at least you're thinking about it.

[00:09:32] So that's good.