MEAN web development #2: Node.js in the back

A series on MEAN and the first actual article in which we’ll get some web pages served starts with the N, the very last letter of MEAN! Yes, it’s true, we’re starting in the back, literally and figuratively speaking. Node.js will be your server side software and you’ll use it to handle incoming HTTP requests. Once we’ve got this going we’ll be able to get to the other letters of MEAN (MongoDB, Express and AngularJS in case you forgot). And in fact we’ll already be looking at some of that E, for Express, in this post!

For a change I won’t mention you should follow me on Twitter because that’s where I tweet on anything software, MEAN and Node.js related and I won’t mention my Twitter handle is @sanderrossel either.
So now that I haven’t mentioned that I am going to mention my GitHub account because that’s where you’ll find the source code for this blog post. You can find the repository for this post in the SanderRossel/mean2-blog repository.

By the way, if you’re just dropping in and you haven’t read the first post in this series yet you really should.

  1. MEAN web development #1: MEAN, the what and why
  2. MEAN web development #2: Node.js in the back
  3. MEAN web development #3: More Node.js
  4. MEAN web development #4: All aboard the Node.js Express!
  5. MEAN web development #5: Jade and Express
  6. MEAN web development #6: AngularJS in the front
  7. MEAN web development #7: MongoDB and Mongoose
  8. MEAN web development #8: Sockets will rock your socks!
  9. MEAN web development #9: Some last remarks

Getting started

Maybe the title of this post seems familiar? I’ve written on a back-end technology before, Web development #4: PHP in the back. In that blog post I explain how to write PHP and how to get it working on your own machine by installing some web server software, XAMPP. Here’s the cool thing about Node.js. It is a web server already, so you don’t need to install anything besides Node.js (which we did in the first part of this series). You can just write JavaScript and run your server!

So let’s look at the “Hello world” example from the first article again.

var http = require('http');
var server = http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello, Node.js!');
});
server.listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

I’ve written it a bit different from my first post, so we can see what’s going on just a little bit better. There are a few things going on there. First of all is the ‘require‘ bit. With require we can load a module which we can use to implement certain functionality. So what’s a module? Node.js has a pretty cool module system, where a module can be compared to classes like we have in C# or Java. We’ll look at modules in more detail in a next post. So anyway, with the first line of code we’re telling Node.js that we need the http module and we store it in the http variable.

So now that we have this http module, or class-like thing, we can invoke functions on it. And the first (and only) function we’re going to call is createServer. So createServer takes an (optional) callback function as parameter. The callback function takes a request and a response as input parameters which we can use to see what the user requested and to return anything back to the client.
As you can see we’re writing to the header of the response, using writeHead, to tell it that everything was handled correctly (HTTP code 200 is OK) and that we’re sending back some plain text. By calling response.end we’re telling Node.js we’re done and that the result is ready. Response.end must be called on each request (or our client will be waiting on a response forever) and it must be called as the final operation on our response object, since it signals that the response is complete (all headers and content have been written to the response). In this case we’re passing our response text directly to the end function, but alternatively we could use the write function and simply call end without parameters. That would look as follows.

res.writeHead(200, {'Content-Type': 'text/plain'});
res.write('Hello, Node.js!');
res.end();

Or, if you want to build up some response text, you can do something as follows (using write n times).

res.writeHead(200, {'Content-Type': 'text/plain'});
res.write('Hello,');
res.write(' Node.js!');
res.end(' [This text is optional]');

And, of course, we’ll typically return HTML rather than plain text. Notice I’ve changed the header too.

res.writeHead(200, {'Content-Type': 'text/html'});
res.end('<h1>Hello, Node.js!</h1><p>This is a paragraph...</p>');

So now that we’ve called the createServer function and we’ve specified what to return we have a Server object. This Server object has functionality to listen for incoming HTTP requests and handle them accordingly. To start listening simply call the listen function and pass it a port and an IP address. I’m still using 1337 and localhost from the Node.js website example.

Last, and actually also least, is the console.log, which just logs some debug info to your command window when starting your Node.js app.

You can run each example by opening up a command prompt and typing in (exluding double quotes (“”)) “node pathToMyFile\MyFile.js”. If your file path contains any spaces be sure to wrap it in double quotes.

Debugging

Did you try out all those examples? Did you have to restart the command prompt and type in “node pathToMyFile\MyFile.js” a couple of times? Tiresome, isn’t it? Luckily there are tools that automatically restart your Node.js app when changing a file. You really should install one and save yourself time and trouble! I’m going to use nodemon. You can install it using npm. Open up a command window and type “npm install nodemon -g”. The -g tells npm to install nodemon globally. That means nodemon isn’t some library that this one project uses, it’s a global library from which all your projects can benefit! Whoohoo, never again restart your Node.js app manually because you’ve made a minor file change! To make sure nodemon installed correctly open up a command prompt and type in “nodemon -v” and you should get the currently installed version of nodemon.
Now instead of starting your Node.js app using “node pathToMyFile\MyFile.js” use “nodemon pathToMyFile\MyFile.js” (simply replace node with nodemon). Now go ahead and edit your file. Watch the command prompt and see how your app is automatically restarted. Browse to your website (localhost:1337) and see that the Node.js app has indeed restarted.

For some more tips on debugging web apps in general (no matter if you’re using Node.js, C# ASP.NET, Java or what have you) you should read a previous blog post I wrote, which has a little section on debugging web pages from your browser, Web development #8: Where to go from here.

Doing a little more

So here’s a nice one for you.

res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Requested: ' + req.method + ' - ' + req.url);

Try putting that in the createServer callback. Now browse to localhost:1337/SomePage or localhost:1337/AnotherPage?someParam=someValue. You should see whatever you put after localhost:1337 echoed in your browser window.

So let’s say we have some HTML pages that we want to show based on the requested page. This is now pretty easy. Here’s a first, and rather naive, implementation. In case you got my source from GitHub, the final implementation can be found in the file nope.js (that kind of gives away the ending, doesn’t it?).

var http = require('http');
var fs = require('fs');

var server = http.createServer(function (req, res) {
    switch (req.url) {
        case '/about.html':
            res.writeHead(200, {'Content-Type': 'text/html'});
            var buffer = fs.readFileSync(__dirname + '\\about.html');
            res.end(buffer.toString());
            break;
        case '/index.html':
        case '/':
            res.writeHead(200, {'Content-Type': 'text/html'});
            var buffer = fs.readFileSync(__dirname + '\\index.html');
            res.end(buffer.toString());
            break;
        default:
            res.writeHead(404, {'Content-Type': 'text/html'});
            res.end('<h1>404 - Page not found!</h1><p>What were you even trying to do...?</p>');
            break;
    }
});
server.listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

So there’s some new stuff in there. First we require(‘fs’), which gives us some control over the file system (fs is short for File System). After that we do a switch statement on the request url. We support no url (just localhost/1337, we’ll get url “/”), /index.html and about.html. Everything else will get a 404, page not found. Note that no url and index.html both give you the index.html page. So make sure you have an index.html and an about.html page in the same folder as your Node.js app. If you got this from my GitHub account you’ll be fine, otherwise you’ll need to create those files and put some HTML in them.
So if you browse to localhost:1337/index.html or about.html we’ll first set the header to 200 and text/html. After that we’ll use the fs object to read either the index.html or the about.html file.
Notice that I’m using readFileSync. Remember that I explained, in my first post in the series, that Node.js runs a single thread to handle all incoming requests? Because any synchronous action (meaning it just runs on the same thread) is blocking that one thread everything in Node.js is asynchronous by default. So any non-asynchronous (synchronous) method is suffixed with ‘Sync’. If, like me, you’re coming from C# that’s just the other way around from what you’re used to!
So anyway, we read the file and we now get some buffer object. To get the actual contents as a string simply call the toString function on the buffer.
We also see the __dirName variable, which is a global Node.js variable which contains the directory in which your Node.js JavaScript file resides.

There is an overload for the readFileSync that will return the string value instead of the Buffer object.

var content = fs.readFileSync(__dirname + '\\index.html', 'utf8');
res.end(content);

So there are a few problems with this code. First of all we are reading files synchronously. Suppose this takes 50 milliseconds. No big deal you’d say, but suppose you have 100 requests per second, that’s 5000 milliseconds, or 5 seconds, for the 100th visitor! Imagine that every 100th visitor had to wait 5 seconds, at least, for your page to load. That’s rather disastrous for a web page! So we really want to read that file asynchronous. Luckily that’s pretty easy. We can use the readFile function which takes a callback function as last parameter. The callback function gets an error object and the returned data as input parameters. So how would that look?

fs.readFile(__dirname + '\\index.html', 'utf8',
    function (err, data) {
        if (err) {
            // Handle exception...
        } else {
            res.writeHead(200, {'Content-Type': 'text/html'});
            res.end(data);
        }
});

Second, we’d best put the file handling in a seperate function. We now have this ‘huge’ piece of duplicated code! So let’s tidy it up a bit.

var http = require('http');
var fs = require('fs');

var readHtml = function (fileName, res) {
    fs.readFile(__dirname + '\\' + fileName, 'utf8',
        function (err, data) {
            if (err) {
                // Handle exception...
            } else {
                res.writeHead(200, {'Content-Type': 'text/html'});
                res.end(data);
            }
    });
};

var server = http.createServer(function (req, res) {
    switch (req.url) {
        case '/about.html':
            readHtml('about.html', res);
            break;
        case '/index.html':
        case '/':
            readHtml('index.html', res);
            break;
        default:
            res.writeHead(404, {'Content-Type': 'text/html'});
            res.end('<h1>404 - Page not found!</h1><p>What were you even trying to do...?</p>');
            break;
    }
});
server.listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

So, all fixed, right? Well, actually, this looks more like Nope.js! Well alright, I suppose it’s not that bad, but once your app starts to get bigger this approach might get a little messy. Let’s add some Express and see how it can help make things easier.

Just a little remark on the 404 HTML. Of course it would be better to create another HTML file for the 404 page, but I just wanted to show you that you can use multiple methods of returning HTML even if you’ve already used another method.

Adding some Express

In the first part of this series we’ve installed Express in our project, so I’m assuming you’ve got it set up. As said Express just makes working with Node.js a lot easier. It handles routing, rendering of HTML, sessions, template engines and all that stuff. So let’s rewrite the above code so it uses Express.

var express = require('express');
var app = express();

var options = {
    root: __dirname
}

app.get(['/', '/index.html'], function (req, res) {
    res.sendFile('index.html', options);
});
app.get('/about.html', function (req, res) {
    res.sendFile('about.html', options);
});
app.get('*', function (req, res) {
    res.send('<h1>404 - Page not found!</h1><p>What were you even trying to do...?</p>'); 
});

var server = app.listen(1337, '127.0.0.1');

First we’re requiring Express. This actually doesn’t return an object, but a function, also called the express function, and as you can see on the second line we just run the function and store the result in our app variable. This app variable now denotes our Express application. After that we use the app.get function multiple times to handle our routing. I think it’s pretty straightforward. If “/” or “/index” are requested we return the index.html file, if “/about” is requested we return the about.html file and if anything else is requested we send back the 404 HTML.
It’s worth mentioning that the send and sendFile functions set the header of the response object. sendFile sets the header based on the file extension (in these cases .html) and you can override it in the options object. We only use the options object to set the root of the files though, in our case that’s the same folder as our app resides in, but for bigger projects it would be wise to create a /views folder or something like that.
Finally we call app.listen and pass in our port and IP address. Notice I’ve used the same port and IP as the nope.js example, so you can’t run them both simultaneously.

Here’s another thing Express handles pretty well. Parameters and queries. Using the request object we can ask for any parameter or query that the user sent our way. Here a little example.

app.get('/echo.html', function (req, res) {
    res.send('<h1>Echo</h1><p>This is an echo... ' + req.query.say + '</p>');
});

Using the query object we can get the value of any query parameter. In this case we expect a parameter called “say” and its value will be echoed to your browser. So just browse to localhost:1337/echo.html?say=someValue.
Pretty neat, right?

There are some other best practices, like putting your routing in a separate file and exception handling, that we haven’t discussed yet. No problem, since we’ve only scratched the surface anyway. Don’t worry, we’ll go in a little deeper yet in my next post!

And as always I’d like to give you some reading recommendations. Syncfusion has an awesome free ebook on Node.js, Node.js Succinctly. Just sign up and get them free Succinctly books! They have lots more, like JavaScript Succinctly and HTTP Succinctly, which might come in handy when working with Node.js.
And it also just so happens that Manning Publications has quite a few books on the MEAN stack as well! They’re not free, but when you really want to do some Node.js heavy lifting I can really recommend getting one of them. So they’re Node.js in Action, Node.js in Practice and Express.js in Action.
And, of course, you could also just keep following my blog, which is free and a lot less to read.

Stay tuned!

MEAN web development #1: MEAN, the what and why

Yes, a new blog post and a new series! I apologize for not writing a post last week, I was a bit busy. I’ll try to make it up to you by starting an awesome series on MEAN web development.
I’ve been tweeting on MEAN and related technologies on Twitter, so be sure to follow me @sanderrossel as well.

But what is MEAN and why would you want to know and use it? That’s what we’ll look at in this first episode. We’ll also set up our environment. In the following posts we’ll look at each technology involved with MEAN in more detail.

  1. MEAN web development #1: MEAN, the what and why
  2. MEAN web development #2: Node.js in the back
  3. MEAN web development #3: More Node.js
  4. MEAN web development #4: All aboard the Node.js Express!
  5. MEAN web development #5: Jade and Express
  6. MEAN web development #6: AngularJS in the front
  7. MEAN web development #7: MongoDB and Mongoose
  8. MEAN web development #8: Sockets will rock your socks!
  9. MEAN web development #9: Some last remarks

 The what

So what is MEAN? I could call you dumb for not knowing, that would be mean (and unjustified, because you’ll know within seconds), but that’s not quite the mean I’m talking about! MEAN is actually an acronym (because we love acronyms in IT) and it stands for MongoDB, Express, AngularJS and Node.js. Chances are you’ve heard of those and if you read a previous blog post of mine, Web development #8: Where to go from here, you even know a little bit about what they are (although you could’ve got that from other sources too, of course).
In short, MongoDB is a NoSQL Document Model database, Node.js is a platform that allows you to run JavaScript on/as your web server, Express is a library that simplifies working with Node.js and AngularJS is a front end framework that let’s you create Single Page Applications (SPAs).

Don’t worry, we’ll look at all of them in much more detail later. In fact, I’ve already written on MongoDB in an earlier blog post, A first look at NoSQL and MongoDB in particular. Actually I’m going to ask you to read that post in a little bit.

So here’s the deal, MongoDB is a database that doesn’t use SQL, but JavaScript, as a query language, Node.js is a platform that let’s you use JavaScript on your back end, AngularJS is a JavaScript library for your front end and Express is just a library for Node.js. So that’s JavaScript across your entire stack! That’s pretty awesome, especially when you’re a fan of JavaScript.

You’re probably going to use more than just MEAN. MEAN is just a starting point, but, of course, you’re free to add (or remove) whatever you like. Perhaps a little jQuery UI, a HTML generator like Jade,  or sockets.io, a library for working with sockets in Node.js.

The why

So why would you use MEAN over other technologies? Here’s the thing, I’m not religious about any technology and you can probably do anything you can do with MEAN with other technologies as well. SQL Server and C# would do nicely, especially when throwing in SignalR, but then of course you’d have SQL in your database, C# on your back end and JavaScript in your browser. So just being able to stick with one language (unfortunately that language is JavaScript) could be considered a pro.

Let’s look at why you’d want to use any of the MEAN letters seperately.
MongoDB is a very flexible database that looks a little like the relational databases you already know. MongoDB is schemaless though, so adding any field becomes a breeze (no production downtime!). That’s especially neat when you have huge tables with lots of data. I know adding a field to any SQL database can be quite a challenge on big tables, because your entire table has to be updated. On top of that MongoDB scales well, much better than most SQL databases. Actually let’s stop on why you’d want to use MongoDB, just read my NoSQL and MongoDB article, A first look at NoSQL and MongoDB in particular.

Node.js is really an alternative to popular web servers such as Apache or IIS (Internet Information Services). So how is Node.js different than those two (and others)? Well, Apache and IIS both listen to incoming HTTP requests using threads. So that means a number of different little ‘processes’ (the threads) are listening for incoming requests and handle them. That means that if all threads are busy no new requests can be handled at that time and your server response becomes slower.
Node.js, in contrast, uses only a single thread to listen for incoming HTTP requests. What it does is listen for an incoming request, put it on a stack, and handle it on a different thread. This process is so fast (if you do it right) that Node.js should be able to handle more concurrent connections than Apache or IIS. Of course if you mess up in Node.js you’ll be blocking the server for everyone else too.
And if you’re going to use Node.js you’re probably going to use Express as well as it really makes Node.js development easier (but you’re entirely free to do a little ‘MAN’ development, of course 🙂 ).

And why would you want to use AngularJS? AngularJS is a framework for creating Single Page Applications. On ‘traditional’ web pages your page needs to refresh entirely for each server request. So imagine you’re at some web shop and you’re reading product reviews. There’s ten reviews per page and you’ve just read the tenth. When you click on ‘next page’ the entire page gets refreshed. So the server sends the entire HTML, the product images (if they’re not cached by your browser), the product description, other recommended products, etc. to your browser. That’s a whole lot of information you already had! In a SPA you’d only send the ten new product reviews and replace the old ones with the new ones in your browser (for example using jQuery, or AngularJS).
So a SPA, when done well, is a lot faster and better usable than a traditional application. Of course you may use jQuery for AJAX requests and DOM manipulation, but AngularJS is a framework that was kind of built to handle these exact cases, whereas jQuery is more general. So AngularJS could be a good choice when building SPAs. Of course you can replace AngularJS with another framework if you like, perhaps Ember.js or Backbone.js, you could be doing MEEN or MEBN development (I’m really just making that up, but why not, right?).

So put that together and MEAN is just an all-JavaScript stack that’s fast, responsive and flexible. Did I mention it’s all open source, so free to use? That’s pretty awesome!

Setting up your environment

MongoDB

Let’s get to work, shall we? Let’s start with setting up MongoDB. As I mentioned I’ve already written on MongoDB in a previous post, A first look at NoSQL and MongoDB in particular. As luck has it I’ve also described how to set up MongoDB, so I suggest you read that post and especially the “Getting started with MongoDB” bit (you can skip the C# part). Little has changed since I wrote that post some months ago, but I’ll briefly discuss the differences. You can download MongoDB from the downloads page. The default install path has changed to “C:\Program Files\MongoDB\Server\3.0\bin”. You can run MongoDB through the command line or by running mongod.exe directly.
You should also install MongoVUE, as described in the blog post. I’ll be using it for this series anyway. When first starting MongoVUE you need to specify a connection. Give it any name you like, set ‘localhost’ as server and you’re good to go. Other than that I think MongoVUE is pretty self explanatory, especially when you’ve used SQL Server.

Node.js

So let’s set up Node.js next. Head over to nodejs.org and click the big green install button. It should give you the installer for your system (I’m assuming you’re on a Windows machine). You can, of course, also select an installer manually by heading over to the downloads page. Then just run the installer and make sure you also install the npm package manager. Actually, just install everything. Once it’s installed you can run any Node.js application (which is really just a JavaScript, or .js, file) from the command prompt. And while we’re on the subject I want to coin a new term CPDD, Command Prompt Driven Development (ok, that was a joke). Why are we still using command prompts in 2015!? So I’m not a fan of command prompts because it’s a lot of typing and I always forget what to type. If you’re like me, no worries, I’ve got you covered!

So while we’re at it let’s create a very simple hello world! We’ll see Node.js in action and we’ll be able to fire it up using the command prompt. So first we’ll create a folder for our ‘project’. I’ve put it in C:\dev\hellonode\ and there I’ve created a file called hellonode.js. Now put the following code in that file.

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello, Node.js!');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

As you can see it’s just JavaScript. The example was taken from the Node.js homepage. So we first create an instance of the http module by invoking the require function and pass in the string (id) ‘http’. When we have our http object we invoke the createServer function and pass in a function as only parameter. The function has a request (the HTTP request) and a response as parameters. So whenever the server receives an HTTP request this function is called and we can inspect the method (GET, POST etc.) and any parameters and basically anything that was sent with the request. We’re not really interested in any of that here though since we’re just going to send the same result every time a request is made. We write HTTP code 200 (OK) and the content type text to the result header and we end the request by invoking the end function and passing it the text ‘Hello, Node.js!’.
The function createServer returns a Server object. We invoke listen on this Server object, pass in a port and IP address (localhost in the example) and at that point our server goes up and running and listens for requests.

Don’t worry if you didn’t get that. We’ll look at Node.js in much more detail in a later post. So now to get this running. Open up a command prompt and type in the following (excluding double quotes “”): “node C:\dev\hellonode\hellonode.js” and you should see that your server is running. Now browse to localhost:1337 and you should see “Hello, Node.js!” in your browser window.
Congrats, you just created your first Node.js app!

Express and npm

So next we need to install Express. We’ll do this using npm. npm is a JavaScript package manager and it’s the default package manager for Node.js. There are alternatives, like Bower, but let’s just stick to npm. So open up another command prompt (argh!). First we want to make sure npm is on the latest version. We can issue an update command with the following command “npm install npm -g”. After that move to the folder that holds your project using command “cd C:\dev\hellonode” and then use the command “npm install express” to actually install Express to your project. To uninstall express you can use the command “npm uninstall express”.
Alternatively you can create a small file called package.json and put the following JSON in it.

{
  "name": "hellonode",
  "version": "1.0.0"
}

Now when installing or uninstalling a package add –save at the end of your command, like so “npm install express –save” and “npm uninstall express –save” and npm will keep track of dependencies in this file. For example when installing Express your packages.json file will look as follows.

{
  "name": "hellonode",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.12.3"
  }
}

So to make sure it really works you can create a JavaScript file called helloexpress.js and try out the Hello world example from the Express “Hello World” example page. Try it out by running the following command from a command prompt: “node C:\devhellonode\helloexpress.js” and browsing to localhost:3000.

So that’s it! We’ve got a little bird’s eye view on MEAN and we’ve got both MongoDB and Node.js up and running and we’ve installed Express using npm. I’m not discussing AngularJS here because we’ve seen how to add front end libraries to our pages in previous blog posts, for example Web development #6: Getting interactive with JavaScript. We’ll get to setting up AngularJS anyway when I post about it.

In next posts we’ll look at MongoDB, Node.js, Express and AngularJS in much more detail and we’ll see how they work together.
In the meantime, if you’re interested in knowing more about any of those I can really recommend the free ebooks by Syncfusion (yeah, here we go again). They have books on all the MEAN parts, MongoDB Succinctly, Node.js Succinctly and AngularJS succinctly.  You have to sign up, but it’s free and really worth it.
If you really want to get into it I can recommend some books by Manning Publications. They have books on all the seperate technologies, but they also have an upcoming book on the entire MEAN stack, Getting MEAN with Mongo, Express, Angular, and Node.
I’m looking forward to reading your comments and I hope to see you back with the next installment.

Stay tuned!

How to learn and polyglot vs. specialist

Welcome (back) to my blog. This weeks blog is going to be a little different than my other blogs. Unfortunately I’m a little short on time this week, too short to write up a small web page using some cool technology and write about it too. However, I still want to deliver you the blog you may have been waiting for.
If you read my blog every week, or at least regularly, please drop a line in the comments and let me know, I greatly appreciate it!
I also Twitter other articles that you might like @sanderrossel, so be sure to follow me if you haven’t done so already.

So what do I have in store for you this week? Well I recently got a question from someone who asked me what’s the best way to learn a new technology. I’ll answer that question at the end of this article, but first I’ll tell you why I think you need to learn new technologies from time to time.

Specialized vs. polyglot

One of the reasons I want to write about why you need to learn and how to learn effectively is because lately I’ve been in a few discussions with people about being a specialized programmer versus being a polyglot, or all-round programmer.

A few months ago I switched jobs. One of the reasons for me was that my previous employer wanted everyone to specialize. My specialization would be C# WinForms and Entity Framework, while other colleagues specialized in SQL Server. Sounds nice, right? Except that, next to a C# certificate, I also have a SQL Server certificate that wasn’t going to see any use in that setup… Besides, I had seen quite a bit in C# WinForms and I wanted to move on.
So I applied for another job at another company. Their motto is “we specialize in being all-round.” Put differently, everyone does everything. At one time you may be working with C# and SQL Server, while at another time you may be working with Java and Oracle. Now that’s something I could get into!

Let’s first define these terms, specialized and all-round, or polyglot, and see why you would want to be the one or the other.

I don’t think many people will disagree with me when I say a specialist is someone who has gathered a large amount of knowledge and experience in a specific field. The more specific this field the more specialized you are. Your expertise may be C#, which is a little broad, hardly an expertise actually. C# WinForms with Entity Framework, my specialization, is more specific. You could be as specific as specializing in a single Control, for example the C# WinForms DataGridView. Now that’s a specialization.
I recently read the book Soft Skills by John Sonmez from Simple Programmer. It’s a great book that I can really recommend. John talks in length about why you really need to specialize. In short, if someone has a very specific problem and you specialize in that specific field you’re worth a lot to that someone. The more you specialize the smaller the chances you’ll find someone with the exact problem you can solve, but that also means that the people who have such a specific problem will have trouble finding someone to fix it for them. Therefore, once these people find you (or you find them), and you are one of the few who can really solve their problem, they are going to want you, no matter the costs (to some degree).

So how about all-round, or polyglot. You may have heard about the polyglot programmer and how amazing they are. But what’s a polyglot anyway? The dictionary describes a polyglot as someone who speaks several languages. So a polyglot programmer is someone who knows his way around multiple programming languages. Let’s extend that a bit and say a polyglot programmer also knows multiple paradigms (Object Oriented Programming, Functional Programming,  Aspect Oriented Programming…) and probably lots of libraries too, because different languages require different libraries.
The good thing about being a polyglot is that each new language or technology is easier to learn. Is this a managed language? You’ve seen it before. Is it unmanaged? You’ve seen it before. C or BASIC syntax? You’ve seen it all before! So, in theory, you could work for just about anyone. Except that you’re probably not very good at all of these languages, so why would someone hire you over someone who has the exact knowledge they need? But when you think about it, how often do clients know exactly what they want or need.
On the other hand, once systems become real complex and need different languages, databases and paradigms in different parts of the system, well, you’re good to go.

It seems the world is pretty divided on which is best. As said, John Sonmez really urges you to take on a specialization, and it could really work out for you. But if you Google for “polyglot programmer” you’ll find websitesblogs and videos dedicated to that subject as well (both for and against)…

Why not both?

So here’s my view on both specialized and polyglot programming. They’re both great and everyone’s right. I’m usually not that politically correct, so let me explain.

Expertise is great, right? When you’re doing any kind of serious development you’re going to run into issues that can only be properly solved if you really know your stuff. For example, in WinForms you may need to create your own user control. That’s really specialized work, you really need to know the design time implications associated with creating controls. As coincidence would have it just last week I inherited a Form with a DataGridView on it. Upon setting some property I populated the DataGridView with columns. What happened at design time? Everytime I did a build or I opened the WinForms designer it would re-populated the DataGridView, but didn’t actually throw away the old columns! Before I knew it I had over 100 columns on my Form! So apparently I’m no specialist in WinForms Control development. Luckily I was knowledgeable enough to recognize the problem and fix it right away. How did I get that knowledge? You may not like the answer, but I’ve been building non-trivial WinForms apps for over four years and I’ve been reading up on books and blogs dedicated to WinForms development. Could I have solved my problem without knowing what I know? Sure, just duplicate a lot of code in every Form I have so I don’t need Form inheritance. Or maybe make a fix for the bug, which then requires another fix, etc. etc… And I’ve seen these ‘solutions’ lots of time!

So if you need four years to learn any language and/or framework to be able to build non-trivial applications with it there’s not much sense in being a polyglot, right? That’s just going to take ages and by the time you’ve mastered your second language your knowledge on the first will be outdated. Well, here’s the trick, you don’t have to be that sufficient in any language. I get my daily work done in either Visual Basic.NET or C# with WinForms, and more recently ASP.NET MVC, Entity Framework and SQL Server, and I’m pretty good at all of them. You could say that’s my specialization and it comes kind of natural as I’m working with them every day from 9 to 5. Once in a while I may need to read up on some stuff at home, and you need to keep challenging yourself, but overall, when you’re working with a technology that much you tend to get a little good at it.
To become truly specialized, an authority in your line of work, you’d need to put a lot of free time in it as well. But what if you spend that free time on learning other technologies? Well now we’re going a little polyglot while also being a little specialized! And here’s the good part, being a polyglot will make you a better specialist!

Wait, what? That sounded pretty contradicting. Let me put it this way. When all you’ve ever known is C# are you truly aware of its strengths and weaknesses?
I’m currently learning Haskell, a functional language, for my university study. When I saw the Haskell implementation of the quick sort algorithm that made me question all I ever knew about C# and object oriented programming. You may be familiar with the C# implementation, or you could maybe guess what it looks like. I can’t post it here, because it’s simply to big, but a quick Google search will give you lots of different implementations, like Iterative Quick Sort (haven’t checked if it’s actually the best out there). Beware that a lot of what you’ll find is recursive, which will give you a StackOverflowException in C# for large lists.
Now here is the Haskell implementation.

qsort []      = []
qsort (x: xs) = qsort smaller ++ [x] ++ qsort bigger
                   where
                      smaller = [a | a <- xs, a <= x]
                      bigger = [a | a <- xs, a > x]

You don’t actually have to understand it, but the takeaway is that this Haskell implementation is so much more concise, and ultimately readable, than any C# implementation you can come up with.
But there’s more. Are you using .NET LINQ? Well, where did you think that came from? Yes, the functional programming paradigm! Functional languages are also pretty good at multi-threading because values are immutable.
Does that make you want to throw C# out of the window and do everything in Haskell (or, since you’re a .NET dev, F#, or Scala if you’re a Java dev) from now on? No, and neither should you. But you should see what’s out there and if there’s some language or technology that solves your problem better than the technology you’re (ab)using now. Even if there isn’t you’ll have gained new insights that might help you on your current job. Just by taking a more functional approach in your object oriented language can help you in writing better and more readable code.

How about another example? So as said I do quite a lot of work in SQL Server. I have plenty of experience in developing databases (I even got certified) and some experience in maintaining them (I’m what they call an accidental DBA). SQL Server was just that one tool that could solve all my problems. And then I spend just a few evening with MongoDB (I wrote a blog about that, A first look at NoSQL and MongoDB in particular). NoSQL just blew my mind. All the troubles I had with SQL Server (and SQL in general), that I took for granted, had been solved by other databases. Those few evenings with NoSQL gave me another perspective on SQL and, I dare say, made me a better SQL programmer because I was now much more aware of SQL’s strong and weak spots.

One last example. I started out as a Visual Basic programmer. Many of you now shudder in disgust. I never understood what all the VB hate was about. Sure, a lot of bad VB has been written, especially pre-.NET VB. But I’ve seen equally bad code in C# as well. And nowadays VB does almost everything C# does and vice versa. It’s just a different syntax. Now this may come as a surprise to some, but not all languages use curly braces! VB is one such language, and because I know VB learning another such language may be easier. But there’s more. In VB there’s a thing called “Option Strict”, which is set to “Off” by default. This makes VB a lot more “forgiving” than C#. For example, the following code would run fine (except for the call to MethodThatDoesNotExist() which gives a runtime exception).

Dim s As String = 42
Dim i As Integer = "42"
Dim o As New Object()
o.MethodThatDoesNotExist()

You may not like it, but this taught me a lot about implicit and explicit casting and late and early binding (which helped me get into JavaScript later). And on the subject of late binding, there’s times when it’s pretty handy. In fact, C# introduced the dynamic keyword for it in .NET4.0. Well guess what, as a VB programmer I was way ahead of you! Optional and named parameters, introduced in C# in 2010, came straight from VB. And what about those new cool Exception filters in C# 6.0? VB has had them for years.
Of course the same can be said for C# features that were introduced in VB, like Iterators (yield), but the takeaway is, that even these two very closely related siblings take stuff from each others, and knowing one can make you better at, or more prepared for, the other.

So why not spend a few hours with some new language once in a while? Just get something up and running in a language you’ve heard about, but don’t know yet, use a framework you haven’t used before, or get a taste of some NoSQL database. Make sure you pick one that’s popular as you’ll be able to find lots of documentation.

How to learn

So I may have convinced you that learning new languages, paradigms or frameworks can be fun and that it can actually help you get an edge as a programmer. But how do you learn a new language or framework? I mentioned Soft Skills before, but I am going to do so again. In this book John Sonmez has a ten step plan for learning just about anything as quickly as possible. I know it works, because John’s approach to learning closely resembles my own method. So here’s what to do.

Read up on the topic you’re interested in. Get a feel of what’s important and what you need at the very least to get started. Also get a feel of how big this thing is you’re learning. Is it a few days of work, or will years of study go into this? Don’t spent to long on this though.
Once you have a picture of what it takes to become proficient at whatever it is you’re trying to learn determine what parts you want to do. Set some bigger goal you want to reach and some smaller goals that will take you there.
After that find resources, books, blogs, videos, whatever it takes to get your started. And then filter them so you can get started with reaching your first goal.
For most languages and frameworks my first goal is to set up the environment. Once I’ve done that I need some “Hello, world!” kind of application, so I know I can actually write and run code with it. Usually that’s not too difficult with all the pre-reading I’ve done.
After that just play around a bit, get familiar with the syntax, the libraries, the tools, etc. After that you can do whatever you want. I’d repeat those last few steps, keep setting new, small goals, and just get there.
Don’t spend to much on any tool you won’t be using though. Just get a feel for it and see how you can use certain elements from it in your day to day programming.

 

That’s my approach to learning. John does a much better job at explaining it than I do, so I suggest you buy his book, or order his course 10 Steps to Learn Anything Quickly.
Now John’s 10th step, one I didn’t have, is rather interesting. Teach! Of course I’ve been doing that by writing my articles, but I’ve never thought about it as a part of the learning process. So how can you teach? Well, start a blog! And, as you might’ve guessed, John has a (free) course on that as well. If you’re interested in learning and teaching I suggest you sign up for his three week email course on blogging.

I’ve successfully used this approach (including teaching) while learning web development. Try learning that, “web development”. No way you can pull that off! Web development is such a broad topic you’ll be overwhelmed, discouraged, and, ultimately, you’ll probably fail. Unless you start by learning HTML, then learning CSS, etc. Just take it one step at a time.
And you can see how I did this by reading up on my series on web development. In eight easy lessons you’ll have learned the ‘impossible’ task of “learning web development” and it wasn’t even hard.

I did the same with NoSQL. First I needed to know what NoSQL is. So apparently there’s different ‘flavours’. Then I needed to pick one, so I picked the one that’s closest to SQL (easy starting point!). Then I picked a database, MongoDB was listed as most popular, so that means I can find a lot of stuff about it. Then I needed to know how I can install it, after that run it, then try to insert some data, read it, edit it, read it again, delete, etc. And finally try doing that from C#, first connect, then read, then edit. Step by step. I’ve blogged about the result, A first look at NoSQL and MongoDB in particular.

There you have it. Get started now. Pick up that language you’ve been interested in, but that you never got around to doing. It might benefit you in more ways than you know. Now is as good a time as any. And on that subject, John’s book Soft Skills also talks about how to stop procrastinating and just do what you should be doing (actually the book talks about a lot).
Next week I’ll be back with hopefully a ‘normal’ technical article again. So stay tuned!

Happy coding!