JavaScript Multi-line Strings

Traditionally I’ve always used something like the following when writing multi-line strings …

In ES6 you can write multi-line strings much cleaner using backticks rather than single or double quotes …

… which is much cleaner!

A backtick is a diagonal single quote which is at the top left of my keyboard.

The latest versions of Chrome, Firefox, Edge and Safari all support this. Unfortunately IE doesn’t.

Connect with me:RSSGitHubTwitterLinkedIn

DataTable v DataReader

Imagine we want to read data from a SQL Server database putting it in a generic object that can be used in a JSON API response. An ADO.NET DataReader should be faster and use less memory than a DataAdapter / DataTable approach. This post details some tests and what the differences are …

Test database

I’m going to test this on the Customers table within the Northwind database. I’ve created 5 copies of the Customers table with increasing number of rows within it.

A script to create the 5 Customers tables can be found here

Test app

The test app can be found here.
The test app reads the Customers tables that vary in size using both the DataTable and DataReader / DataAdapter approaches. The time to read the data and put it in a generic object is captured along with the memory taken by the DataTable object.


As you can see the difference is minimal for <100,000 rows.

Rows DataTable (ms) DataReader (ms) Difference (ms) DataTable size (Mb)
91 0.5 0.2 0.3 0.04
910 5.4 5.3 0.2 0.42
9,100 92.7 68.8 23.9 4.18
91,000 931.7 698.4 233.3 42.10
910,000 12,928 10,060 2,868 423.66
Connect with me:RSSGitHubTwitterLinkedIn

8 Visual Studio Code Tips

In a previous post, I detailed some reasons I have started to use VS code. Following on from this, here are some tips for using VS code:

  1. Shortcut key for the command pallet is SHIFT + CTRL + P
  2. You can open up a 2nd window in VS code using CTRL + 2 and you can set focus to the 1st / 2nd window using CTRL + 1 or CTRL + 2
  3. Switch auto saving on by checking File > Auto Save
  4. Show / hide the side bar using CTRL + B
  5. Whilst in the command line, code . will open VS code in the current directory
  6. To open a file quickly, type CTRL + P and start typing the name of the file
  7. To open an intellisence list, type CTRL + SPACE
  8. Increase the font by going to user settings (File > Preferences > User Settings) and paste “editor.fontSize”: 16, into the json
Connect with me:RSSGitHubTwitterLinkedIn

Why NodeJS?

I’ve been getting into NodeJS recently. Here’s what’s attracted me …

  • Simple. It’s quick to install and really easy to start creating a node app
  • Modules. NPM is a great package manager and it seems like there is a module for most things you want to do
  • Scaleable. Node uses asynchronous execution. This means the CPU can focus on many tasks at once. Node is also single threaded, so, there are no deadlocks
  • Javascript. I’ve really enjoyed programming in Javascript in recent years. It’s great to be able to write backend code in JavaScript as well as frontend code
  • Hosting. There are great hosting options – Azure, AWS and Heroku all support Node
Connect with me:RSSGitHubTwitterLinkedIn

5 Reasons to use VS Code

I’ve recently started to use VS code as my code editor. Here’s why …

Built in node debugger

I still prefer to debug client side code in the browser but it’s great to debug server side code in a code editor. My previous post describes how to do this using VS code. VS code debugging gives you the key stuff that an IDE gives – breakpoints, stepping, watches, call stack, …

Built in Git support

It’s great to have git support inside the code editor. VS code automatically picks up that you are using Git. You can commit, pull and push changes to Git right from within the VS Code editor.

VS Code git

Built in emmet support

Emmet allows you to write html super fast and it’s great that it’s built right into VS code. Just type some emmet syntax, hit the tab key and boom!

VS Code emmet

Built in task runner

VS code can leverage existing task runners like gulp and grunt to run things like babel compilation or maybe some JSHint checks. You can also add watcher tasks so that this stuff can be run automatically as you save code changes.

VS Code task


Last, it’s very fast – much faster than the full blown Visual Studio IDE.

Connect with me:RSSGitHubTwitterLinkedIn

Blog List 2015

I thought I’d share the list of blogs I currently read. For me, blogs are a great way of staying in touch with what’s happening in the software development world.

3 ways to debug node apps

node-inspector + Chrome

Here’s how you can use node-inspector, a node debugger, along with Chrome DevTools to debug a node app …

First install node-inspector globally by typing the following in a command line:

Now run the node app in debug mode:

Chrome then loads, opens DevTools and breaks on the first line of your JavaScript.
You can then step through your code, add breakpoints, watch variables, … as you would if you were debugging clientside JavaScript. You can debug any request to the node application from any browser.

debugging node in chrome

Visual Studio Code

Here’s how to debug a node app using Visual Studio Code

First click the debug icon in the left panel and then click the configure icon.

debugging node in VS code

Change the program attribute within launch.json to the correct name of your root node file.
Select the root node file in the drop down to the right of the play button.
Put a break point in the node code by clicking in the left margin.
Click the play icon and the node app will start and break on the break point.

debugging node in VS code

When you request a resource from the node app, it will break at the line of code where the break point is. You can add watches, see the call stack, … do all the usual stuff in a debugging session.

debugging node in VS code

Web Storm

Here’s how to debug a node app using Web Storm

First, make sure the node plugin is enabled by going to File > Settings … > Plugins. NodeJS should be listed an ticked.
Now make sure the configuration for node is correct in Run > Edit Configurations
debugging node in WebStorm

Put a break point in the node code by clicking in the left margin.
To debug the node app, click the green bug icon.
debugging node in WebStorm

When you request a resource from the node app, it will break at the line of code where the break point is. You can add watches, see the call stack, … do all the usual stuff in a debugging session.

Podcast list 2015

I thought I’d share the list of podcasts I currently listen to. For me, podcasts are a great way of staying in touch with what’s happening in the software development world.

Code reviews

I’ve been doing lots of code reviews lately, so, I thought I’d write my thoughts down on this topic …


So, what’s the objective of a code review? For me, it boils down to asking 2 questions:

  • What is being done well?
  • What can be done better?

It’s important that the 2nd point is phased like that rather than “What is being done wrong” because that can lead to negative reviews which can be very demotivating.


The benefits are:

  • Improve team communication and collaboration. If code reviews are part of the development process, the team will naturally start to talk to each other about the code they are writing and work together when solving difficult problems
  • Improving the team. Code reviews will surface coding anti-patterns that some members aren’t aware of. They will also surface code good coding patterns that some members aren’t aware of. So, the coding ability of the team improves quicker than it would do without reviews
  • Improving the quality and maintainability of the code. If the code doesn’t make sense, it will be surfaced during the review. If the code uses an anti-pattern, it will be surfaced during the review. Silly bugs will also be caught. So, the quality and maintainability is better than it would be without code reviews

Tips for reviewers

  • Does the code make sense – can I quickly understand it without asking lots of questions? If not, what can be done to make the code more readable? Point out where you are having trouble making sense of the code and ask the coder to think of a better structure
  • Avoid going through how you would have structured the code – just point the coder in the right direction. Telling the coder that they have done it completely wrong and this is the code they should have written is very demotivating
  • If knowledge and use of a design pattern would have helped, point the coder at resources to learn the design pattern and suggest adding a task to the backlog to refactor the code using the design pattern
  • The code doesn’t need to be improved there and then. The most important thing is that we learn for the next piece of code that is written. Refactoring tasks can generally be put on the backlog
  • Avoid getting emotional!
  • Look for common problems and focus on those. Avoid spending lots of time on one-off issues
  • Look for good things and share these approaches and patterns with the rest of the team
  • Only review up to 500 lines of code in a session. Try to review code regularly so that you don’t have to review more, but if you do, split the review up into different sessions
Connect with me:RSSGitHubTwitterLinkedIn

Sprint review Videos

In my last post , I talked about tips for live sprint reviews. One thing I didn’t mention was videos and how useful they can be …

Why record the sprint review?

Some of the key stakeholders might not be able to regularly attend the meeting (e.g. sales, consultants who are primarily on site with customers, …). Recording the sprint review, gives us a mechanism of capturing feedback, even if a stakeholder can not attend the live review.

Record live review or record separate demos?

Recording the live sprint review is the easiest and least time consuming thing to do. A great thing about recording the live sprint review is that it will include the feedback conversations. The drawback is that the video could be up to 30 minutes long and if the stakeholder hasn’t booked time in their diary to watch this, they make struggle to find that time. You could edit the video and split it up into 1 video per feature – a 5-10 minute video is much easier to squeeze into a busy day and watch.

Another approach is to record the feature demos as separate demos outside the live sprint review meeting. You could do this before the live meeting which doubles up as a practice run for the live review. You can end up with a good quality, to the point, video demos. The downside is that the videos will not include the feedback conversations. However, because the videos will not include conversations that might be sensitive, these videos will probably be more feasible to use as a mechanism to capture feedback from customers.

No live reviews – just videos

It is feasible not to have live sprint reviews in a few of situations:

  • When the key stakeholders regularly can not attend the sprint review meetings (e.g. sales, consultants who are primarily on site with customers, …). When you are at the stage where it is just the development team in the review meeting and maybe just one other stakeholder, it’s time to think of just doing videos.
  • When there are multiple product teams, each wanting a sprint review and stakeholders time. The different product teams could be asking the same stakeholders for their time. So, we are asking a busy stakeholder for a multiple of 30 minutes. Different teams may have the same product owner and same scrum master. So, the scheduling of the review meetings can be a challenge. In this situation, videos may be a better approach.
  • You may be doing kanban or scrumban rather than pure scrum where there isn’t a fixed sprint schedule. In this situation, you can do the videos immediately after a feature has been tested to capture feedback.

Who should do the video demo?

I prefer the developers to do the video demos. The developers will have worked hard to make the features and as a result, hopefully, some passion for the feature will come through in the demo. The product owner should help the developer script the demo to make sure it is targeted to the stakeholders.

Recording software

For recording live reviews, GoToMeeting works well. Camtasia works well for recording demos outside of the live review – it’s really easy to use and has great editing capabilties. Camtasia is a “paid for” product which I think is worth every penny but Jing is free and is a great start point. Jing is limited to 5 minute videos which actually forces the demo to be short and to the point.

Capturing feedback

A real danger with videos is that we lose the feedback – particularly if there is no live review. Remember the sprint review exercise is all about feedback, so, it is critical we get that with the video approach.

The product owner should drive the feedback, chasing stakeholders up for their thoughts.

Online collaboration software is critical with the video approach. You need to be able to upload the videos and allow people to post their comments against it. aCloud Collaborate works well, there are lots of other solutions as well.

Have you used sprint review videos? Have you found them useful?

Connect with me:RSSGitHubTwitterLinkedIn