Friday, May 26, 2017

Anonymous Functions and Arrow Functions are Closures

Functions in JavaScript and TypeScript are "first-class citizens;" which means that they can be passed as a parameter, assigned to a variable (and passed as a parameter), and may be dynamically created at runtime. The last stipulation is important: not only do many people consider it a major requirement to be a "first-class citizen," but creating new functions at runtime is how JavaScript and TypeScript function is built.

Dynamically creating functions at runtime is good and bad. It is good because it simplifies the code and can make it cleaner, but it is bad because there is a penalty to pay for creating all these functions.

Saturday, May 20, 2017

Safeguarding Development Environments

When I am teaching I often refer to a mistake I made years ago, typing "rm * .o" in a Unix shell while in a project folder. I realized when the shell said ".o not found" that by placing the asterisk accidentally all by itself I had selected and removed all the source for the project!

I am sure that it was not the first mistake that I ever made that corrupted a project, nor will it be the last. You or I do not even have to make a mistake; it could just be that your hardware fails or that today some black-hat exploits a security flaw that nobody has patched yet and voilĂ , all of your files are encrypted and forever beyond your reach.

In fact, it is the WannaCry ransomware attack that prompted this post! Not that it bit me, but something like it could some day...

Monday, March 20, 2017

Oracle Database 12c Perl Distribution and VirtualBox/VMware

The Perl 5.14.1 distribution included with the Oracle 12c Database instance is flawed and crashes when given the true CPUID for the processor. This can happen in several cases, especially when installed on MacOS, VirtualBox, or VMware with newer Intel processors.

This behavior, and solutions, is documented in several places, including here by Laurent Leturgez and here by Danny Bryant. Most noticeably, it occurs when the Perl scripts are run during the creation of a multitenant database using dbca.

The problem hit me hard using virtual computers during a customized Oracle boot camp I am teaching as I write this. The purpose is to document what I found out and how I decided to fix it.

Wednesday, December 28, 2016

Increasing the Performance of React Callbacks

The React framework is typically a very heavy user of closures or arrow functions in the component classes. Especially since JavaScript 2015 introduced the arrow function, putting the functions inline when the component renders the sub-components binds the functions tightly to the components where they are used.

Since React has moved on to JavaScript 2015 a common example of handling a button click to change state often looks something like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import React, { Component } from 'react';

"use strict"

export default class CounterComponent extends Component {

    constructor(...args) {

        super(...args);

        this.state = {

            value: 0
        }
    }
    
    render() {

        return (
            <span>
                Value: { this.state.value } &nbsp;
                <input
                    type="button"
                    value="Increment"
                    onClick={ () => { this.setState({ value: this.state.value + 1}) }} />
            </span>
        );
    }
}

The arrow function on line 25 has a big advantage in JavaScript 2015 over the closure definitions from version 5: when it is created "this" is bound to the same object where it was created, the instance of the CounterComponent. But it is still a closure, and the problem is that a new function is created every time the render method is called.

Monday, February 15, 2016

Pre-Loading AngularJS Controllers and View Templates

My goal is to asynchronously pre-load both view templates and controllers after the application is running and interacting with the user, but well before the router displays the views. In a "normal" load AngularJS eager-loads the controllers and lazy-loads the view templates. I also have a way to lazy-load the controllers, so both controllers and view templates will be loaded just-in-time.

So to achieve my goal first I am going to look at the normal eager-load/lazy-load scenario, and then build on that for a pure lazy-load scenario. That will become the foundation for achieving my goal of pre-loading both controllers and view templates before they are required, but after the application is running.

Normal Controller Loading

This really depends on what your definition of "normal" is, because I am going to use RequireJS to manage the individual scripts that make up the application. In a "traditional" AngularJS application I would load all of the scripts in the correct order in the HTML document. RequireJS helps manage the dependencies between the scripts, most importantly by allowing the dependencies to be define in each script. It also reduces the script tags to just one to bootstrap the application. If you want the details of using RequireJS with Angular I wrote another post about that: AngularJS + RequireJS.

Using RequireJS does not remove the possibility of deploying the application with a monolithic script, in fact it has a tool to combine the scripts. Often doing development with individual scripts is more manageable, but deploying with a monolithic script is cleaner. However a monolithic script can delay application startup, and in this case it would contrary to my stated goal.

My first example has two controllers and two templates and uses Angular-Route to manage them. The operations are logged to the console so that you can see the order in which they take place. I am just showing you enough here to build on as we go along. Angular is bootstrapped programmatically from main.js (not shown). The second controller and view look almost identical to the first. The project is available at the end of the article.

Sunday, February 14, 2016

JavaScript is Single Threaded

JavaScript is single-threaded, that is a well publicized fact. And we are reminded that we should write short operations to avoid problems. But why? More importantly, what is a simple "world-view" of how the JavaScript environment functions in a browser?

Frankly there are plenty of complex diagrams about all the gory details of what happens inside a browser for a page life-cycle. I, however, want a simple, functional view to explain in the JavaScript world the nuts and bolts you need to be an efficient programmer.

Thursday, February 11, 2016

AngularJS + RequireJS

The trick to working with an AngularJS application in RequireJS modules is to get a handle on two frameworks performing dependency injection at two different stages of the application.

So why bother? First of all, even though some of the AngularJS tutorials demonstrate putting your application module, controllers, and services all in one file that really is not the best way to organize your work. Follow the rule of coding one "type" per file and you will not have to put all of your work at risk every time you open up a file to make a change.

Second, once I have modularized my application into multiple source files the number of scripts that get loaded in the document escalates horribly. RequireJS allows each script to declare its own dependencies and with one script load in the document to bootstrap it they all take care of themselves. Plus, when I am looking at a module I know what the dependencies are, they are declared right at the top.