Code Review: FirstOrDefault()

I regularly review the code that I maintain. Recently, I’ve come across code like this fairly often:

someCollection.FirstOrDefault().Id

I cannot rightly comprehend why anyone would do this.

FirstOrDefault() returns the first item in a sequence or the default value if it doesn’t exist (i.e. the sequence is empty). For a reference type (classes, basically) the default value is null. So using the value returned by FirstOrDefault() without a null check is only valid for when the sequence contains a value type (e.g. int, decimal, DateTime, Guid, etc.)

In the example above if someCollection is an empty list/array/collection/whatever then FirstOrDefault() will return null and the call to the Id property will fail.

Then you are left with a NullReferenceException on line xxx but you don’t know if it is someCollection, or the returned value from FirstOrDefault() which then wastes your time (or the time of someone else who is having to debug it).

So, if the sequence must always contain items then use First(), in the exceptional event that it is empty the call to First() will throw a more appropriate exception that will help you debug faster. If it is perfectly valid for the sequence to be empty then perform a null check and change the behaviour appropriately.

Previewing Config Transforms

Curiously, I didn’t know about this until recently and it is such a useful thing too.

You can preview the results of your configuration transformation from within Visual Studio.

First of all, right click the transform file and select “Preview Transform”

Then it will show you the differences between the original web.config file and the transformed file.

Really getting the latest changes with TFS

TFS Source Control doesn’t always get the latest changes. It gets what it thinks are the latest changes (and for the most part it gets it right if you work exclusively in Visual Studio). However, there are times when it gets it wrong and you have to force its hand a little.

So, if you have issues getting latest code then what you need to do is:

  • Right click the branch or folder that is problematic
  • Go to the “advanced” sub-menu and click “Get Specific Version…”
  • Then in the dialog check the two “overwrite…” boxes
  • Finally, press “Get”

At this point VS/TFS will retrieve all the files in the branch/folder selected and overwrite existing files. It will also retrieve files it didn’t already have, even although it thought it had them.

How to recover deleted files, folders and branches in TFS

In Visual Studio go to the menu item Tools–>Options…

Then navigate to the Source Control –> Visual Studio Team Foundation Server section.

In that section is a check box that says “Show deleted items in the Source Control Explorer”

Once you’ve ensured that the checkbox is checked, press “OK”

Then navigate to the Source Control Explorer and you’ll see that deleted files, folders and branches are now displayed with a large red cross next to them.

Right click the item you want to recover and select “Undelete” from the menu.

At this point Visual Studio stops responding to input. It displays a wait spinner briefly, but mostly it just looks like it has hung.

When Visual Studio does come back to life you can go to the Pending Changes to see the newly recovered files, folders, or branches.

If you are happy with this change, you can check it in to TFS as normal.

DunDDD 2014: Introduction to Node.js–From Hello World to Deploying on Azure

Thank you for those that came to my talk. As promised here are the slides, code, and links given in the talk.

Slides and Code

The slide deck is available as a PDF file.

Links from the talk

Many slides have a link at the bottom, but if you didn’t catch them, here they are again.

Deploying a Node.js with Express application on Azure

By the end of the last post, there was enough of an application to deploy it, so let’s deploy it.

Prerequisites

  • An FTP client to get at the files on Azure.
  • A GitHub account (or other source control, but this walk through uses GitHub) to deploy to Azure.
  • And an Azure account – this walk through does not require anything beyond the free account.

Setting up Azure

Log in to Azure, then click the "New +" button at the bottom right and Quick Add a website

When that’s okayed a message will appear at the bottom of the page.

Once the website has been provisioned it can be modified. From the starter page or dashboard, source control deployment can be configured

Above the starter page for new websites, below the side bar on the website dashboard.

Then select the desired source control. For this example, the deployment is in GitHub

The choose the repository and branch for the deployment.

Then press the tick icon to confirm.

Once the Azure website and source control are linked, it will start deploying the site…

Once finished the message will change to indicate that it is deployed.

 

At the point the website can be viewed. However, there are issues with it – It isn’t serving some files, as can be seen here.

What went wrong?

It is rather obvious that something is wrong. Images are not being rendered, although it looks like other things are, such as the CSS.

By examining the diagnostics tools in the browser it looks like the files are simply not found. But, there is no content.

A few blog posts ago, it was noted that if Node.js didn’t know how to handle a route then it would issue a 404 Not Found, but also it would render some content so that the browser had something to display to the user.

Here is a 404 Not Found that gets as far as Node.js:

The the browser window itself is the message that Node.js renders. It is returning a 404 status code, but it has content. Also, note that there is an X-Powered-By: Express as well as the X-Powered-By: ASP.NET from the previous example. This immediately suggests that the 404 is being issued before Node.js gets a chance to deal with the request.

It is for this reason that FTP is required so that some remote administration of the site is possible.

When the site is deployed to Azure, it recognises that it is a Node.js site and will look for an entry point. Normally it looks for a file called server.js, however, it can also work out that app.js is the file it is looking for. So, normally, the entry point into the application should be server.js for installing into Azure.

Azure creates a web.config for the application which has all the settings needed to tell IIS how to deal with the website. However, it is missing some bits. It does not know how to deal with SVG files, so it won’t serve them, even although the Node.js application understands that static content resides in a certain location.

The missing part of the web.config that is needed is:

    <staticContent>
      <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
    </staticContent>

 

Accessing the files on Azure with FTP

This example uses FileZilla as the FTP Client.

First, the credentials need to be set for accessing the site via FTP. In the Website dashboard, the side bar contains a link to “Reset your deployment credentials”.

When clicked a dialog appears that allows the username and password to be set.

Once this is filled in and the tick clicked, the details for connecting via FTP will be in the side bar on the dashboard.

These details, along with the password previously created, can be used to connect via FTP.

Once connected, navigate to the location of the web.config file, which is in /site/wwwroot and transfer the file to the source code directory. The file can now be edited along with other source code and that means that when it is deployed any relevant updates can be deployed in one action, rather than requiring additional actions with FTP.

The changes to the web.config are to add the following

    <staticContent>
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
</staticContent>

to the <configuration><system.webServer> section of the file.

Finally, add the web.config file to the repository, commit the changes to source control and push it to GitHub. It only takes a few moments for Azure to pick it up and then the portal will display a new item in the deployment history.

Refreshing the site in a browser window finally reveals the missing graphics.

The project on GitHub

This was marked as a release on GitHub as part of the Xander.Flashcards project.

Node.js with Express – Come to the dark side. We have cookies!

So far, so good. At the point the application displays a list of languages and will display the language that the user picked. However, for the flashcards to work, that selection will have to be remembered. As there is so little state, it is possible to store that in a cookie.

Express handles the creation of cookies without the need for middleware. However, in order to read back the cookies a parser is needed.

Setting and Removing the cookie

To set the cookie with the language that is received from the form on the page:

var language = req.body.language;
var cookieAge = 24*60*60*1000; // 1 day
res.cookie("flashcard-language",language,{maxAge:cookieAge, httpOnly:true});

In the above code, the language is set from the form value, as seen in the previous blog post. The cookieAge is set to be one day, after which it will expire. Finally, the cookie is added to the response object. It is named "flashcard-language".

When the route is requested the HTTP response header will look something like this:

HTTP/1.1 200 OK
X-Powered-By: Express
Set-Cookie: flashcard-language=ca; Max-Age=86400; Path=/; Expires=Mon, 17 Nov 2014 23:22:12 GMT; HttpOnly
Content-Type: text/html; charset=utf-8
Content-Length: 18
Date: Sun, 16 Nov 2014 23:22:12 GMT
Connection: keep-alive

To clear the cookie, call clearCookie and pass in the name of the cookie to clear.

res.clearCookie("flashcard-language");

The HTTP Response will then contain the request for the browser to clear the cookie:

HTTP/1.1 304 Not Modified
X-Powered-By: Express
Set-Cookie: flashcard-language=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT
ETag: W/"SuG3Z498eJmmc04TIciYHQ=="
Date: Sun, 16 Nov 2014 23:29:25 GMT
Connection: keep-alive

Reading in the cookie

In order to read in the cookie some middleware is required. The changes to the app.js file are:

// Requirements section
var cookieParser = require("cookie-parser");
...
// set up section
app.use(cookieParser());

And in the route function that responds to the request, the cookie can be read back like this:

var language = req.cookies["flashcard-language"];

Code for this post

The code for this can be found here on GitHub.

Node.js with Express – Getting form data

Now that view engines are wired up and working on this application, the next area to look at is getting data back from the browser.

By default Express doesn’t do anything with form data in the request and a piece of “middleware” needs to be added to get this to work. The reason for this is that there are many ways to process data from the browser (or perhaps it is data from something that is not a browser), so it is left up to the developer how best to process that data.

The view now has a form element and a submit button. It also has an input which will contain the name of the language the user wants. This information is transmitted to the server when the user presses the submit button.

In order to read this information a piece of middleware called body-parser is added.

First, it has to be installed into the application:

npm install body-parser --save

Then the application need to know about it. The following changes are made to the app.js file:

// In the requiments section
var bodyParser = require("body-parser");
...
// In the set up section
app.use(bodyParser.urlencoded());
...
// Set up the route as an HTTP POST request.
app.post("/set-language", setLanguage);

Since body-parser can handle a few different types of encoding the application needs to know which to expect. Browsers return form data as application/x-www-form-urlencoded parser, so that’s the parser that is used by the application.

There are some limitations to body-parser but it is good enough for this application. For example, it does not handle multi-part form data.

The route function can now read the body property that body-parser previously populated.

module.exports = function(req, res){
    var language = req.body.language;
    res.send("set-language to "+language);
};

This will now return a simple message to the user with the language code that was set on the previous page.

Viewing the full source code

Rather than paste the source code at the end of the blog post, I’ve released the project on to GitHub. You can either browse the code there, or get  a copy of the repository for examining yourself. There may be changes coming, so it is best to look for the release that corresponds with this blog post.

Express for node.js – View Engines

In the last post, Express Hello World, I talked about getting started with an Express application in Node.js. In it, the output was rendered by writing HTML directly. In most situations that is undesirable and some sort of view or template engine is better suited to rendering the output.

This post follows on directly from that, so any modifications will be based on what the end result was at the end of the last post. The final output from this post will be shown at the bottom.

There are quite a few view engines out there. A popular one for express is jade, but personally I find it too far from HTML to be useful. This is especially true if you work with graphic designers whose tools will output HTML that the developer has to mould into a view for the application to run. The less rework there the better, in my opinion.

So, I’m going to use EJS in this post. It is a bit like the ASPX view engine in .NET applications, but its actually a derivative of Ruby’s ERB.

To install EJS add the "ejs" package to the application.

npm install ejs --save

Configuring the view engine

Express needs to know which view engine is going to be used, it also needs to know where you are going to store the views. So the following lines are needed in the app.js file from the previous post

app.set("view engine","ejs");
app.set("views","./views");

Changing the route to render the view in the response

As express has been told to look in a directory called "views" to get the views, the view is going to go into that directory. At this time all that is going into helloworld.ejs is the HTML that was derectly sent form the route in the last post. The helloworld.ejs file now looks like this:

<h1>Hello, World!</h1>

And the route looks like this:

module.exports = function(req, res) {
    res.render("helloworld");
};

This will now give the same output as before.

So far, this has done nothing new for us. The power of views is the ability to pass data to them and for them to render it nicely for the user.

Sending data to the view

This is relatively easy. All that needs to happen is that the response.render call needs an additional parameter which contains the information.

module.exports = function(req, res) {
    res.render("helloworld",{name:"Colin"});
};

In order to render the information the view has to be changed too.

<h1>Hello, <%= name %>!</h1>

Adding a layout

EJS, out of the box, does not support layouts (or master pages as .NET’s ASPX view engine calls them). However there is a package that can be added that adds layout support. To install:

npm install express-ejs-layouts --save

And the changes in app.js file

// in the requirements section
var ejsLayouts = require("express-ejs-layouts");
...
// in the set up section
app.use(ejsLayouts);

And that’s it. Your application can now use layouts, by default it uses the file layout.ejs in the views folder, but this can be changed if you prefer.

To demonstrate this, here is a layout:

<!DOCTYPE HTML>
<html>
    <head>
        <title>Express with EJS</title>
        <link rel="stylesheet" href="/css/bootstrap.css"/>
        <link rel="stylesheet" href="/css/bootstrap-theme.css"/>
    </head>
    <body>
        <div class="container">
            <%- body %>
        </div>
        <script type="application/javascript" src="/js/bootstrap.js"></script>
    </body>

The <%- body %> indicates where the body of the page should go. This is the view that is names in the response.render function call.

Running the application at this point now shows that the view with its layout are now being rendered. But there is a problem. The styles are not showing up correctly.

Accessing static files

By default Express will not serve static files. It needs to be told explicitly where the static files are so that it can render them. While this may seem a little bit of a pain over something like an ASP.NET MVC application, where IIS will server anything in the folder that it recognised (and it recognises a lot), it is actually somewhat comforting that it won’t serve up files by accident.

To set up a folder to be served add the following line to the app.js file:

app.use(express.static(__dirname + '/public'));

What this does is tell Express that a directory called public contains static content and files should be served directly when requested. The __dirname is the directory where the current file is located. So what this means is that public is a directory located in the same directory as the app.js file.

What is interesting here is that the path to the static resource is a full server path. That means the public files can be anywhere on the server, or addressable by the server. The path in the URL will be translated to the full server path as needed. So that means that even although I have a directory called public in my Express application, the browser doesn’t see that directory. It only sees what is in it.

So, from the browser’s perspective the bootstrap.css file is located at /css/bootstrap.css but my application sees it as …/public/css/boostrap.css.

Summary

In this post the Hello World application was advanced with the EJS view engine along with layout support and the ability for static files to be rendered to the browser.

The app.js file now looks like this:

// Requirements
var express = require("express");
var http = require("http");
var ejsLayouts = require("express-ejs-layouts");
var hello = require("./routes/hello.js");

// Set up the application
var app = express();
app.set("port", process.env.PORT || 3000);
app.set("view engine","ejs");
app.use(ejsLayouts);
app.set("views","./views");
app.use(express.static(__dirname+"/public"));
app.get("/", hello);

// Run up the server
http.createServer(app).listen(app.get("port"), function(){
    console.log("Express server listening on port " + app.get("port"));
});

The routes/hello.js file now looks like this:

module.exports = function(req, res) {
    res.render("helloworld",{name:"Colin"});
};

The views/layout.ejs file looks like this:

<!DOCTYPE HTML>
<html>
    <head>
        <title>Express with EJS</title>
        <link rel="stylesheet" href="/css/bootstrap.css"/>
        <link rel="stylesheet" href="/css/bootstrap-theme.css"/>
    </head>
    <body>
        <div class="container">
            <%- body %>
        </div>
        <script type="application/javascript" src="/js/bootstrap.js"></script>
    </body>
</html>

The views/helloworld.ejs file looks like this:

<div class="row">
    <div class="col-md-12">
        <h1>Hello, <%= name %>!</h1>
    </div>
</div>

And twitter bootstrap was installed into the public directory. The project structure now looks like this:

Express for node.js walk through – Hello World

While both Visual Studio and WebStorm have templates for node.js Express applications in this post (and and subsequent few posts) I’m going to walk through setting up an Express application so that you can see how it fits together.

Installing Express

To start with I created a folder with just a package.json file in it, then in a command line I ran npm to install Express:

npm install express –save

Express "Hello, World!"

At this stage an app.js file is created. It will bootstrap the Express application. It will configure the environment and start the HTTP listener.

In both the WebStorm and Visual Studio templates there is a line of code that looks like this:

app.set('port', process.env.PORT || 3000);

What this is doing is getting the port to run the application on. By default it will take the value in the "port" environment variable, and if not found it will default to port 3000 within the scope of the process. Although it is setting back the value of the environment variable it isn’t persisted outside of the application, so it really just serves to set up a default value without you having to check for a value and supply a default value when ever it is actually needed.

The full application, at this point is this:

// Requirements
var express = require("express");
var http = require("http");

// Set up the application
var app = express();
app.set("port", process.env.PORT || 3000);

// Run up the server
http.createServer(app).listen(app.get("port"), function(){
    console.log("Express server listening on port " + app.get("port"));
});

The HTTP module is the bit that communicates with the outside world, so we require it for our application to work. We create the server and pass it the app which is a function HTTP’s request event can call. The createServer then returns a server object. As we want to start listening immediately we can just call listen on the server, passing it the port we want to listen on, and a callback function that will be called when the server fires the listening event to indicate that it has started listening for requests.

At this point, browsing on localhost with the defined port will just result in Express responding with a terse error message. But at least it proves that it is listening and can respond

It seems to be a convention, not one that is enforced by the framework, that handlers for the routes are put in a folder called routes, so a file is created called hello.js and it simply looks like this:

module.exports = function(req, res) {
    res.send("<h1>Hello, World!</h1>");
};

req is the request, and res is the response. Very simply the response can send some content back to the browser. In this case it is hand crafted HTML (and very simple at that).

Back in the app.js file, a require line is added to bring in the hello.js module, and further down the route is added to the application.

var hello = require("./routes/hello.js");
...
app.get("/", hello);

Now the application will respond to a GET request on the root URL of the application. The function exported by hello.js will be run whenever this URL is requested by the browser.

The whole app.js file now looks like this:

// Requirements
var express = require("express");
var http = require("http");
var hello = require("./routes/hello.js");

// Set up the application
var app = express();
app.set("port", process.env.PORT || 3000);
app.get("/", hello);

// Run up the server
http.createServer(app).listen(app.get("port"), function(){
    console.log("Express server listening on port " + app.get("port"));
});