Categories
Dev JavaScript Optimising Process

Express snippets

Since I’m playing with Express at the moment I’ve updated my collection of snippets to include a few things I seem to be doing regularly:

Express setup

I use the shortcut “myExpressSetup” to kick off all my new Express projects. It has basically all the parts I need to get the project underway, and means I dont have to remeber each bit. This is more or less the Express equivalent of the HTML boilerplate I’ve mentioned in the past.

  'Express Setup':
    'prefix': 'myExpressSetup'
    'body': """
    "use strict"

    var express = require( "express" );
    var app = express();
    var bodyParser = require( "body-parser" );

    app.use( bodyParser.urlencoded( {
      extended: true;
    } ) );

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

    app.get( "/", function( request, response ) {
      response.render( "home" );
    } )

    $1

    app.get( "*", function( request, response ) {
      response.send( "404 page not found );
    } )

    // Tells express to listen for requests (Start server)

    app.listen( 3000, function() {
      console.log( "The server started on http://localhost:3000/" );
    } );
    """

Get route

Shocking no one, if there’s one thing I seem to be doing a lot it’s displaying content on an HTML page. Using the shortcut “myGetRoute” this one basically says if the URL fits this pattern take it and display it using the “project” template.

'Express Get':
    'prefix': 'myGetRoute'
    'body': """
    app.get( "/project/:thing", function( request, response ) {
      let thing = request.params.thing
      response.render( "project", {
        thingVar: thing
      } );
    } );
    """

So, for example, I could have a URL like geekpulp.co.nz/project/banana and have it populate the project templates H1 with “banana”. If the URL was then geekpulp.co.nz/project/apple it would populate the project template H1 with Apple. Obviously later in the course, I’ll start populating things from a database and this will all make a lot more sense.

Post route

This one’s all about collecting data from a form and adding it back to the page. Again this sort of thing will make a lot more sense when I’m actually posting the data to a database. At the moment if you refresh the page everything will just return to defaut values because nothing is being saved to the backend.

'Express Push':
    'prefix': 'myPushRoute'
    'body': """
    app.post( "/addteam", function( request, response ) {
      let newTeam = request.body.newTeam;
      teams.push( newTeam );
      response.redirect( "/teams" );
    } );
    """

These new snippets are certain to change in the next week or so as I expand to doing things that are actually useful. At this stage, a lot of this stuff is just code that facilities learning. Having said that, I find making snippets for repetitive tasks a good habit to form. Ultimately the whole point is being as efficient as possible.

Categories
Dev JavaScript Optimising

Constantly letting down my variables

As it turns out I’ve been doing everything wrong. Well, maybe not everything, but at the very least I’ve been declaring variables incorrectly.

There are actually three different variable types in JavaScript, var, let, and const. I’ve been using var exclusively and it’s actually bad practice. So what’s the difference between each and which should I be using when?

const

Where at all possible you should use const. Unsurprisingly const is short for constant and without going into to much detail that means it’s something you know will not change. You won’t be able to use this all the time obviously because a lot of the time you need to vary the content of variables. It’s always good pratice to minimise mutability in your code and const is the ultimate example of that.

let

This is how most of your variables should be declared the majority of the time. The strength of let variables is their scope is limited to the block level. For example:

let numberOfPowers = 1;

if (numberOfPowers === 1) {
  let numberOfPowers = "1 more power than Batman"
  console.log(numberOfPowers);
}

console.log(numberOfPowers);

In this example we have two variables named the same thing, but because we are using let their scope is limited to different parts of the code so they don’t collide. So in the console, we’d see both “1” and “1 more power than Batman”.

var

This is the option you should use least often and that’s because of its scope. Unlike let, var has a very wide scope. This is either the function it’s inside of, or if it’s declared outside any function, global. Obviously, that’s not ideal because it creates a greater opportunity to have your variables collide, especially as your projects grow in size. So to revisit our example with var instead of let:

var numberOfPowers = 1;

if (numberOfPowers === 1) {
  var numberOfPowers = "1 more power than Batman"
  console.log(numberOfPowers);
}

console.log(numberOfPowers);

This time the console will only read 2x “1 more power than Batman”. This is because having a global scope means we are writing over a single global variable rather than creating two different variables with different scopes but the same name.

I can see when you’re learning why this concept might be more of an intermediate level concept. Scope can be a bit tricky to get your head around. At the early stages of learning it’s probably better to focus on core concepts rather than nuances like this, but as your skills grow I think this is an important practice to do with variable declaration.

Categories
Dev JavaScript Optimising

How to write modern JS

So you’re learning JavaScript (JS), cool. Putting all this effort in, you’ll want to be learning the modern usage of the language right? Time to get strict.

“use strict” is something I recently stumbled across, and it seems like a really important thing to be using. So much so that I’m a bit surprised it hasn’t been mentioned in the course I’m doing. As it turns out, JS is full of legacy thinking. In an effort to keep new versions of the language compatible with older versions, much of this legacy thinking was/is retained. Obviously this limits JavaScripts ability to overcome its past and improve as time goes on.

Evidently, in 2009 a decision was made to start to modernise JS with the release of ECMAScript 5 (ES5). This meant breaking compatibility with older version of JS if you decided that was what you wanted to do. This is where “use strict” comes in. To enable this “modernisation” you include “use strict” at the top of your JS files like this:

"use strict";
// code below this will be implemented the modern way
...

Since it’s been 10 years since that decision was made, all modern browsers now support ES5. So unless you need to support browsers before the dawn of IE10 then you should be turning strict mode on for all of your JS development.

This of course begs the question, why? Well, aside from staying current with the language, there are also a number of practical benefits:

  1. Modern JS throws errors on things that where previously ignored. This helps you write better, more secure code
  2. It can improve the performance of your code, sometime significantly. Sometimes the code itself is identical and you just get a free performance boost, nice!
  3. It prevents some syntax being use that future version of the language are likely to use. AKA it future proofs your code

So from here on in, I’m going to be using strict mode exclusively and only avoid it when a situation presents itself that I can’t.

As always MDN is a good source of information on both strict and sloppy mode. Now go forth and write strict code!

Categories
Dev Optimising Udacity XR (AR/VR/MR)

Optimising C# scripts in Unity 🏎

C# logoThe more I create C# scripts in Unity the more I learn about optimising those scripts. With code there are 100s of ways to solve a problem, not all of them efficient, so learning to check your codes performance seems like a must.

Things to look for

So far I’ve come across a few simple things to look out for on the projects I’ve been coding. I’ll post more as I come across them in future.

  • Anything that’s called every frame creates consistent load on the CPU, GPU or both. If what’s called is inefficient or large it will have a negative effect on frame rate. In VR this is particular bad given low frame rates can make your user physically sick. Be sure to look at what’s in the Update and FixedUpdate methods and do your best to optimise the code as much as possible.
  • Working on mobile we will almost always be maxing out the graphics capability of the device. This effects the performance of the Update method. On the other hand FixedUpdated runs in sync with Unity’s physics engine. This will make sure your physics will be the most accurate and consistent. FixedUpdate is called every “physics step”, so is regularly used for adjusting physics (rigid body) objects. Make sure you always put your physics code in FixedUpdate.
  • Avoid using GameObject.Find. It basically requires the system to cycle through all of the GameObjects in the game to find the right one, which obviously is expensive for the CPU. If you know what object we are using ahead of time, define the object at the top of the script and reference it that way. GameObject.Find is useful for testing out ideas, but that’s about it.