This article is the fifth (and final) in a 5-day series about teaching beginners how to program. Read the introduction.
Guess what? There's even more to learn if you want to round out your knowledge of web technologies more fully. The one major topic that's missing from this list is server-side programming. You'll recall we touched on the idea of client-server interaction when we covered CouchDB (which is a database and an HTTP server). So, you should have some understanding of HTTP headers, requests and responses, etc. Today, we'll build on this knowledge by creating our own web servers and server applications, using Node.js. We'll also conclude our curriculum with a look at some of the directions students can go from here.
We're introducing learners to a few genuinely new concepts and tools today: the command line, modules, and programming without a graphic interface. It might be necessary to pause and get our bearings, before pushing on with the rest of this unit. We'll return to our mantra of quick results soon enough.
You may have some familiarity with the command-line already, having used CouchApp to send design documents to a CouchDB server. However, this is still a newish concept that requires some explanation. Since we'll be dealing with the command-line a lot with Node, it's important that we feel comfortable in it. Once you have Node installed, have learners type the following into the command line: node -e "console.log(1 + 1)"
You can obtain these modules, and thousands more, using a command-line tool called Node Package Manager (npm). This should be installed right after Node itself. Students must become familiar with finding and installing modules, and including them in their applications. As a simple exercise to confirm they can do this, choose a module that has a unique capability and have students write a simple application that uses it. You could have them send emails using node mailer, fetch their Facebook profile info using facebook-graph, or retrieve data from a CouchDB database using nano, cradle or couch-client. If they can successfully write a script to leverage a node module, then we're ready to rock and roll.
Now that we're familiar with the new tools, resources and workflows required to write programs in Node, let's look at how we can use it to build a web application. Learners will need to understand that Node is not a server, and so they'll need to build an application that bundles a server with it. To illustrate this point, demonstrate the famous, simple Hello world! server application.
Based on everything we've learned to date (which is a lot), students ought to be able to understand everything that's going on in that example, and even recognize that we're setting HTTP header information like status codes and content-types manually. Now, we can pick up the pace.
As I've stressed again and again throughout the past 5 days, getting meaningful results quickly is more important than understanding how. This is why I recommended using Bootstrap instead of learning HTML and CSS from scratch. It's also why I recommended using the Ember framework for building complex web applications. These tools act as scaffolds to support learners and help them achieve more than they could on their own. As learners grow more confident and experienced, this scaffolding slowly falls away as they learn to support themselves.
As educators, our job is to provide guidance and support to learners when they need it, and pull back when they don't. We do this by sequencing instruction, choosing appropriate tools, prescribing meaningful challenges and tasks, and filling in the blanks when necessary. This is why we slowed down to explain the basics of Node.
Now it's time to speed up again!
Just like we leaned on Bootstrap and Ember so students could do more faster, we're going to use a server-side web application framework called Express to blaze ahead with this unit of study.
Undoubtedly, we'll need to familiarize ourselves with this framework just as we did with Ember yesterday. A simple challenge to focus students would be to get them to create a simple, 3-page application, just like they did with Ember. This will give them an opportunity to try out the URL routing, templates and views in Express. These all ought to be familiar concepts from Ember.
An intermediate challenge might be to create an application that reads data from a database and displays it on screen, optionally with the ability to edit and save items back to the database. This will require learners to set up both GET and POST URL routes, and define dynamic URL routes just like they did with Ember. It also requires them to rope in a database client and get their application to perform a set of actions before sending a response.
At this point, we're pretty advanced programmers with plenty of diverse experiences. If you haven't given learners the chance to work together yet, I suggest giving them the opportunity now with an advanced challenge. Working in groups of 2-3, ask students to come up with idea for a web application, and try to implement it together. They'll need to organize themselves as a team, and break out roles and responsibilities like designing the interface, building the front end, managing the database and writing the server-side code to serve the application. Sensible division of labour and collaboration are essential programming skills, and a complex application is the perfect opportunity to develop them.
As an added benefit, requiring students to work together on a project will force them to evaluate and compare their workflows, and try to find a way to contribute to the same codebase. This is the perfect way to introduce a distributed version control tool like Git, and perhaps get students to sign up for a free Github account. No time like the present to discover a worldwide community of open-source developers.
When developing a curriculum, it's important to be mindful that your learning objectives and outcomes span a range of complexity. Bloom's taxonomy is a good yardstick to determine whether your learning activities are sufficiently diverse. Bloom identifies a cognitive (and affective and psychomotor) hierarchy for classifying learning objectives: knowledge, comprehension and application on the low end, and analysis, synthesis and evaluation on the high end. It's easy to remember a set of facts (knowledge). It's harder to 'understand' a fact than it is to recall it (comprehension). It's more difficult to 'apply' knowledge than it is to comprehend it (application). It's more challenging still to critically reflect on something than it is to apply it (analysis). Producing something new by pulling together everything you've learned is even more difficult (synthesis). And finally, the most challenging cognitive task is to assess the value of what you've learned (evaluation).
The wonderful thing about programming is that we're consistently building new things by applying what we've learned about various technologies. Throughout this course, we've had to know, understand, and apply different programming concepts, analyze both documentation and our own code, and synthesize our learning to build applications.
But what about evaluation? The ability to evaluate and assess the value of knowledge only comes after substantial learning and experience. After everything we've learned over the past 5 days, we're at a point where we have enough knowledge and experience to begin determining what's valuable and what's not. For example, after having compared Ember to Express, some students may decide that they prefer building single-page applications to using server-side frameworks. Individual preferences may lead some students to choose one NPM module over another. As students collaborate, they'll compare their coding habits to their peers, and determine which habits are better than others.
In other words, we've transitioned from complete novices to experienced developers, able to reflect critically on tooling, processes and technologies.
Over the past 5 days, we've learned about front-end development, databases, HTTP and REST, object-oriented programming, MVC architectures, client and server-side frameworks, modules and version control. This is about as broad a foundation as it gets. Now, it's time to pick a path.
Good luck, and stay in touch.
Try Git : Codeschool
This tutorial will teach learners how to use Git as a version control system to collaborate with their peers. It's put together by the excellent teachers at Codeschool, and flows very well from one topic to another.
This website provides command-line-based tutorials designed to bring beginners up to speed on all aspects of Node programming. There are core concepts and electives, one of which is a tutorial on Express, which might be a great way for students to learn the ins and outs of the framework. And, if they're looking to use version control to collaborate with their peers, there's also a course on Git.
Thank you for following this series. If you're an educator, I hope you consider implementing aspects of this curriculum in your classrooms and schools. If you were following along because you're interested in learning how to program, I hope I've given you sufficient guidance to proceed with confidence. If you're an industry stakeholder or an employer, I hope you'll consider endorsing this curriculum to your professional network.
Let's work together to ensure the next generation has the right skills to achieve prosperity for us all.