Day 5: Server-side programming and future directions

March 7, 2014

This article is the fifth (and final) in a 5-day series about teaching beginners how to program. Read the introduction.

If you've made it this far, then you've learned enough to be an effective Javascript web developer already. You can put together interfaces on the front end, hook them up into an interactive web application using a framework, and load and save data to a database. You also understand the basics of HTTP, REST, and object-oriented programming.

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.

Node.js : walk before you run.

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.

The command-line

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)"

This tells Node to add 1 + 1 and log the response to the terminal. Next step: have students create a Javascript file with some log statements in it, and get Node to execute the file: node filename.js. If they can accomplish these tasks, then they know enough about the console (navigate the file system, list files, etc.) to move on. They'll also understand that you test a Node application by re-executing it in the terminal, just like you test a web application by refreshing the browser.

Modules! So many modules...

Node.js has an extremely rich collection of modules that extend its capabilities. You can download and install modules to connect to databases, format dates, and even send emails.

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.

Welcome to the server side.

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.

A note on scaffolding.

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!

High-speed development with the Express framework

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.

Express is another NPM module that extends the capability of Node. Once you include the Express module in your Javascript application, you unlock the ability to easily create a web-server, define URLs that it responds to, describe custom behaviour for every URL (like receiving form data, or retrieving a record from a database, etc.), and use templates to easily format the responses that are served. It can also be easily adapted to behave like an MVC framework, which learners should already be familiar with from Day 4.

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.

Climbing up the ladder

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.

Where do we go from here?

My mission was to produce a course of study that would prepare newcomers for the industry we're trying to grow, and the jobs we'll need over the next decade. Our focus was on Javascript and web technologies, as this provided the broadest foundation of skills, and exposed learners to the widest array of specializations possible.

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.

Did you enjoy the unit on front-end development? Perhaps you want to pursue HTML and CSS in greater depth, and become a great designer. Did you like databases? Consider looking into data science some more. Are you interested in making games? There's plenty of game engines available for Javascript. Maybe you want to build a robot? You can program robots using Javascript. Do you want to build a mobile app for an iPhone or Android device? Javascript has you covered.

You have the foundation you need to learn all kinds of programming languages and technologies now. You can stay with Javascript, or you can branch out. Revisit Day 1 and look at that intimidating list of servers, databases, programming languages and frameworks. That's a list of challenges waiting to be conquered.

Good luck, and stay in touch.