Philosophy of This Project

Use the tools that fit the job. For Developers, this means you can use whatever code editor or IDE you prefer. For DevOps this means it’s easy to put in various environments, because the interface is a Browswer, NPM and Node.

Small Modules. A module should do as little as is sensible. Methods should have simple interfaces and do or change one thing. The app will be composed of many small modules. Small modules are easier to test and change because they use fewer dependencies.

Solve Actual Problems. Build to today’s requirements, not for some issue that may or may not come up in the future… However, unit testing and a healthy amount of E2E should be considered today’s problems – they are part of how we verify that our code works and requirements are met. The future looking benefits of testing are like gravy, they’re a bonus, the icing on the cake.

There’s a lot of new vocabulary in Angular, but mostly it’s just new names to indicate slight differences.

These terms sometimes have broader, general meanings. The definitions below are in regards to angular.

Current JavaScript Features often thought of as unfamiliar:

importandexport: tells the javascript interpreter to get this file (the build system handles this in angular)

class {}: used for instantiating objects in JS also used by typescript to help with suggestions.

{ key1, key2 } = object: destructuring, used in importing

Future JavaScript Experimental Feature:

@Decorator: a wrapper that lets the interpreter know how to use the thing it’s decorating. This is notated by putting the @ in front of a method or class. Example: @Input() el means ‘el’ is decorated with an @Input() class. @Component({...}) export class TestComponent means that ‘TestComponent’ is going to be a component with the metadata passed in to the Component parentheses.

()=>{} and val=>val==com: are arrow function notation. They are more performant when you don’t need binding to a new context (a new this);

TypeScript:

Type: Types are optional to the JavaScript

When you combine these new concepts it can look like a whole new language but it’s not.

TypeScript/Newer JavaScript Version

JavaScript

1

2

3

4

5

6

7

8

9

exportclassClassEx{

constructor(val){

this.val=val;

}

factory(newVal:number):(com:number)=>boolean{

return(com:number)=>this.val+newVal===com;

}

}

becomes something like:

JavaScript Version

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

functionClassEx(val){

this.val=val;

}

ClassEx.prototype.factory=function(newVal){

varoldVal=this.val;

returnfunction(com){

returnoldVal+newVal

}

}

module.export=ClassEx;

They’re not that different, the new JavaScript one (with types from TypeScript) is a lot easier to write automated tests for, gives you better linting, and is easier to turn into modules. It also gives you much better type hinting and auto-suggestions in your favorite text editory.

Many times, when talking to other developers, we bring up “leveling up.” The idea is simple. You do the work, put in the time and you hit new levels where skills are unlocked. While this might be motivational for people who grew up playing JPGs in the 80s and 90s, I think it might be useful to augment that metaphor a bit.

It’s just a fun metaphor about programming, why ruin it?

I’m not trying to ruin it. I think it’s great fun and still can and should be used. But the landscape of modern programming is big and complex, there’s many different task, jobs, roles, and skills. It’s not just enough to be good at a language any longer.

Clans and Alliances.

You probably sit near people who do similar work to you. Sometimes, you work directly with them on projects and tickets. More often, you probably work on similar projects and sub-tasks apart from them. These are the people you talk to, eat with, car pool, and share knowledge with.

Classes

Many people in the clan probably belong to the same class. Web Developers, Sysadmins, DevOps, etc. There’s some mixing, as someone knows Front End and Back End is with someone who’s done some Graphics in the past.

Skills

Overtime, your skills improve. Along with the classes is a skill tree. At the roots are soft skills, general computer skills all the way up the branches of stacks and teams, to the libraries and third party tooling you’re working with. While you may notice a great increase once in a while, and it feels like a level up, you also gain points each time you do the same thing and more points as you learn something new. Over time, your class and sub-class become more evident as skills you learn both help you figure out what role is best for you and creates new needs and opportunities for you to continue specialization.

Elite Class and Dual Class

Final Fantasy I and XI had a system where a lower class would metamorphose into a new class. For instance fighters became knights, white mages could be summoners. In other Final Fantasy games, once you sufficiently filled out your skill tree/grid you’d have places where you could jump to other skill sets and start learning other skills. This isn’t so different for IT, once you’re doing JavaScript/HTML you find your self working in ASP, JSP and PHP templates and you’ve now become an elite Front End Engineer who can code in the browser (plain vanilla JS or any Framework) and do the UI Layer on a server application… Which opens up new opportunities to learn some back end coding.

Battle Cards/Beast Companions/Summons

When working professionally, you often find yourself working with 3rd party APIs, Version Control, and complex tooling. These are handy little side skills and companions in your career.

Menu Systems

Here’ you go to wiki, documentation, and ticketing systems to manage your parties and equipment.

What do you think about this analogy? Too much? I think it’s too much. Any other fun stuff to add? What about MMO Events to Confs? Are bugs on the Kanban like side quests?

The last post was an overview of how developers use try…catch. Here’s a quick overview so you don’t have to click back.

Not too long ago, try…catch wasn’t used much in JavaScript. The only time where I was encouraged to use try…catch blocks was where we were using outside data. I was told not to do this for three reasons, 1) it was ugly (this is an inadequate reason alone, but we’ll discuss it anyway), 2) it wasn’t optimized for performance, and 3) if something you did was asynchronous (gets executed or returned later) errors wouldn’t be handled. These flaws have been overcome since the bad old days and we’ll be discussing this in the next part. – Earlier post about try catch in JavaScript

It’s not ugly. A handful of developers think try…catch is ugly. Wow, that’s not very nice. The idea of “pretty code” confuses “easy to read and manage code” with code that looks good from far away. Usually this means short variable names and lines, not too much deep indentation, simple control flow structures, and short blocks. Some of these traits do make it easier to read and manage code, but often times this doesn’t come from the right place. A little over a decade ago, the web was all the rage with servers using Python and Ruby. Very different languages, but both languages lend themselves to both of these concepts. Many useful features were built into these core languages and their frameworks and going back to JavaScript in the browser could be jarring with all those long object names, c-like syntax, and extra symbols. I’m going to be honest, I don’t like this reason. You can have easy to read code that’s ugly and vice-versa. I am an amicable polyglot. I like all these languages.

It’s optimized. People used to say it’s not optimized. This was true at some point for Chrome but it is not the case any longer. Ultimately, the good use of try…catch…finally blocks are often more important for the overall app than optimization gains.

If we go back to 2013, we’ll see there was a moderate consensus against repeated use of try…catch. https://stackoverflow.com/questions/3217294/javascript-try-catch-performance-vs-error-checking-code

Inside that question was a link to a jsperf, which saw several iterations. https://jsperf.com/native-try-catch-vs-custom-trycatch-loop/6 in particular saw that the difference between try catch in a loop and not in a loop was negligible. Even removing it altogether barely effects performance. If you goto revision 13, you can measure various ways of doing a try…catch. There, you’ll see that other things impact performance more than whether or not you’re using try…catch.

It’s good at working with asynchronous stuff. For real. It’s a synchronous block. Just like all blocks in JavaScript. Each expression gets evaluated and it moves on. If there’s a promise or something with a callback, the block will finish up before the execution of that asynchronous code. More so, due to the nature of “finally,” it may close up shop before the call backs are done. Well, it would have before. Now, you can use async functions! Prior to async functions and await, the pattern was to use the try…catch inside the callbacks. This was not optimal for two reason.

An error has occurred. Please try again later.

That’s a lot of layers, call backs, calls to other places. Now lets use more modern syntax.

Try catch error message.

1

2

3

4

5

6

7

8

9

10

11

// With a working url and good response, it does something with the response.

I don’t know about you, but to me this is much more straight forward, easier to read, and (dare, I say it?) not as ugly. Now, imagine this cleaner syntax when it’s nested, invoked, again and again. Less error handling code. Mixing this with other useful things to look into like currying and memoizing and you can create very concise error handling with clean and legibly.

Summary

Ultimately, try…catch works well, not only because of it’s built in functionality, but also because of it’s a universal, built in way to handle errors with modern JavaScript.

Part 1, What is it? What is try...catch? Why use try...finally or try...catch...finally?

Finally. We can use try…catch.

Before we get into how this applies to todays JavaScript code in the next article, let’s review what try…catch…finally is and isn’t. What we won’t cover in this or the next part of this series is the scoping of try…catch. There’s some important stuff going on with try…catch…finally with block scopes. Because scope is another intermediate lesson in JavaScript itself, I’ve left it out.

We’re going to discuss what each part is and when to use it.

Errors and exceptions

In JavaScript, errors and exceptions are treated the same. They are pretty much the same except in name. JavaScript has Errors that are instances of the global Error object or an object that inherits from it. You can extend the global Error. The DOM has errors too, these are usually called exceptions, though in JavaScript, they are syntactically treated the same. User created errors are usually called exceptions. I’ll try to use Error in this article, because we’re discussing all Errors and Exceptions and that’s what JavaScript calls them.

What is try…catch…finally.

(Feel free to follow along in the console.)

A try block allow you to try to execute code that you’re not sure will work. A catch block follows the try block, it accepts an argument, which is the error thrown (It “catches” the thrown error, get it? I find the terminology convenient and amusing). Then, at last, we follow it with a finally block. I’m going to execute all of these example in an immediately invoked functional expression. The try requires at least a catch or a finally block.

Without try…catch, we have a couple problems.

Without try... catch

JavaScript

1

2

3

4

5

6

7

8

(function(){

console.log('before');

throw(newReferenceError());

console.log('after');

})();

// before 2:5

// Error

Our code stops executing. We never see the “after” message.

We don’t get any information about the error, no stack trace (lines, functions, etc.).

We have no way of dealing with the error. Here we’re manually throwing the error, which can be desirable some times. Other times, code may throw an error synchronously. This means, the code will stop executing and it won’t be a feature, it’ll just be a problem.

Let’s try try…catch out.

First try...catch

1

2

3

4

5

6

7

8

9

10

11

12

13

14

(function(){

try{

console.log('try')

throw(newReferenceError());

}catch(e){

console.log(e)

}

console.log('after');

})()

// try

// ReferenceError

// ...stack trace...

// after

What’s the difference when we run the try…catch?

The “after” gets run, even though we have an error thrown. The code after the block keeps executing.

We have more info about the error, we can view the stack trace. The debugging info can be really handy.

You can execute code after an error, using the information from that error. A library can provide important feedback to the developer, or you to yourself. You can also use the info in the error to decide what to do next; for example, if it’s a type error you can ask the user for different data.

You can execute code after an error, unrelated to what was in the try…catch block or at least the error.

Still following? Let’s review.

The try block lets you execute code and if there’s an error, your code can analyze the error, respond to the user, try something else, or just continue on. This is the basic control-flow pattern that we will build on to do even more with try…catch.

Breaking from other control-flow structures.

You may find yourself in a situation where you 1) may have an unexpected error, 2) want to respond to that error, but 3) don’t want to just continue on as normal. Here’s some patterns for that using try…catch

Returning.

Here, we’re going to do something, and then return back if it’s successful, but return back after handling an error if there is one. This is probably the most straight forward use of return. If it works, we return from try, if it fails, we return from catch.

Returning results.

JavaScript

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

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

(function(){

try{

throw(newReferenceError());

return't';

}catch(e){

returne;

}

console.log('after')

})();

// returns the error.

(function(response){

let defaultData={data:'default'};

try{

if(response.data){

returnresponse.data;

}else{

throw(newReferenceError());

}

}catch(e){

returndefaultData;

}

console.log('after')

})({data:true});

// true

(function(response){

// another way to express the previous one.

let defaultData={data:'default'};

try{

if(!response.data){

throw(newReferenceError());

}

returnresponse.data;

}catch(e){

returndefaultData;

}

console.log('after');

})({data:true});

// true

(function(response){

// ... same function

})({data:false});

// 'default'

Notice, in all of these, the code after the try…catch block doesn’t run. You never see the console.log(‘after’) execute. In your real app, if both the try and catch return, you won’t put code after, because it’s confusing.

You can use the catch to return the error or return default data, you can also use the catch to gather other information the application may need.

Executing code after the try…catch block

But what if, sometimes, you’ll need to do something after the try…catch block? How does that work? When would you use it?

Executing Code after the try catch block

JavaScript

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

(function(response){

// another way to express the previous one.

let defaultData={data:'default'};

try{

if(!response.data){

throw(newReferenceError());

}

}catch(e){

returndefaultData;

}

returnresponse.data;

})({data:true});

// true

(function(response){

// another way to express the previous one.

let defaultData={data:'default'};

try{

if(!response.data){

throw(newReferenceError());

}

}catch(e){

console.log(defaultData);

return;

}

console.log(response.data);

})({data:true});

// true

Here, the try block’s only purpose is to thrown an error if needed. If there’s an error, it is thrown inside of the try block and the catch returns the default, then returns before the code after executes. Functionally, this works with returning data or displaying data. You could return the response.data or defaultData or do something with them. The upside of moving the rest of the code out of the try…catch, is that you keep the try…catch logic contained to that part where you may have bad data, there’s less nested code (which leads to fewer errors). If there’s any errors thrown in the part of the code outside of the try…catch block, then it will act as that normally would – that could be a pro or con, depending on what you want the application to do.

Finally, let’s talk about finally.

The finally block executes whether try finishes or an error is thrown. The stock answer online when I was reading this was “to clean up.” That might be true but it’s not helpful, and when you dig deeper, there’s a lot of people claiming that “finally” is the same as running code after the try…catch block.

Finally runs before the try…catch…finally block moves on to the next thing. Even if you return from catch or try.

Finally can be used to reduce repetition without introducing new functions. Here “cleaning up” may be removing a modal from view or closing a connection.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

functiontask(response){

// another way to express the previous one.

let defaultData={data:'default'};

try{

if(!response.data){

throw(newReferenceError());

}

}catch(e){

returndefaultData;

}finally{

console.log('finally');

}

returnresponse.data;

}

task({data:true});

// finally

// true

task({data:false});

// finally

// 'default'

Never mind cleaning up, with or without catch, finally can keep a tidy set of process regardless of what else happens in the try…catch block and before anything else can break. Finally is where you’ll clear out any potential memory hogs, open connections, or UI loose ends.

Is that it? What else can try…catch be used for?

You’re not limited to use in functions, try…catch…finally can be used in other control flows, you can use them to safely continue or break a loop or inside conditionals.

Reviewing

Try – This is where you put code that might fail

Catch – this is where you handle exceptions, take corrective actions, or gather more information

Finally – this is where you put code that must be executed regardless of whether the try fails or not.

Code after the block – the app then continues on with it’s normal business.

Closing note.

Not too long ago, try…catch wasn’t used much in JavaScript. The only time where I was encouraged to use try…catch blocks was where we were using outside data. I was told not to do this for three reasons, 1) it was ugly (this is an inadequate reason alone, but we’ll discuss it anyway), 2) it wasn’t optimized for performance, and 3) if something you did was asynchronous (gets executed or returned later) errors wouldn’t be handled. These flaws have been overcome since the bad old days and we’ll be discussing this in the next part.

ES2015/ES6 came with the built in datatypes that are really handy. They’re so handy, that they are part of a strong argument for using ES2015 and transpiling, along with Arrow Functions, block scope, destructuring, spread operators, and defaults. ES2015 includes the Number type. This is super handy for dealing with your numbers in a consistent way across different environments and, as you’ll see, even locales.

To review, last time we talked about the JavaScript Number type, we talked about the Number object and it’s handy qualities, properties and methods. We talked about how the constructor worked: what gets when you use new Number(val). We took a deep dive into the methods on the global Number. So we learned about using Number to check values to see if they’re compatible with numerical calculations. Number also exposes some of JavaScript’s number constants as properties, where different operating environments have proven difficult; where one environment may tolerate larger integers, Number.MAX_SAFE_INTEGER provides a standard way to check against a constant.

This time, we’re going to dive deep in to the instances of Number. We’re going to look at the method on Number.prototype. When we instantiate an instance of number by calling new Number(val), JavaScript is going to take the prototype on Number and attach it to our new number instance. We’re also going to discuss Number compatibility with native Math functions.

We’re going to talk about the Number.prototype.toFixed and Number.prototype.toLocale. There’s other methods, but these two are likely why you’d create an instance in the first place.

Using Number.prototype.toFixed

This works the same way as the old toFixed, which lives on (lowercase) numbers.

Essentially, these two snippets do the same thing:

JavaScript

1

2

3

4

5

varn=5

console.log(n.toFixed(2))// 5.00

varm=newNumber(5)

console.log(m.toFixed(2))// 5.00

If we tried to implement a real program, you’d have a bunch of custom coded checking, formating and alternatives. With the Number type, we can easily implement a standardized way to check for values as we saw in the first part of this series.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

functiontoVariableFixed(data,places){

// set values

data=Number.isFinite(data)?data:0;

places=places||0;

n=newNumber(data);

returnn.toFixed(places);

}

toVariableFixed(4)// "4"

toVariableFixed(4,3)// "4.000"

toVariableFixed("A")// "0"

toVariableFixed("A",3)// "0.000"

To do this with a plain number, you’d either have more blocks or have to do some too-clever logical expressions. Either way, readability and maintainability goes down. Here, we have a number, we check it’s ability to be worked on with the object we’re going to instatiate from. It’s consistent, plain and (probably) fairly safe.

Number also allows you to fail gracefully without try/catch blocks.

1

2

3

4

5

varn="A"

n.toFixed(2)// Returns an error: Uncaught TypeError: n.toFixed is not a function

varn=newNumber("A");

n.toFixed(2)// Returns a string: "NaN"

toLocale

If you work with an international audience, you can use Number to handle your localization and currency.

For instance, if you want a string formated for a known locale, you can do this.

1

2

3

4

n=newNumber(5.25)

n.toLocaleString("en-us",{style:'currency',currency:'USD'})// "$5.25"

n.toLocaleString("en-us",{style:'currency',currency:'EUR'})// "€5.25"

n.toLocaleString("en-us",{style:'currency',currency:'JPY'})// "¥5"

In the case of number internationalization, you can also use the NumberFormat object as part of JavaScript’s Internationalization Object, Intl, if that’s appropriate.

This concept is foreign to many of us US based devs (pun intentional), but these skills are very valuable. Your ability to understand and work with localization (and accessibility) is a very marketable skill in some industries. Does everyone need to be a Localization Master? No, but I do recommend learning the basics of internationalization and localization.

Math and Numbers v. math and numbers v. JavaScript and Numbers

One of the points of confusion I’ve encountered while using Number over simple number values is the way the Number instance appears when you inspect it in developer tools. Consider the following:

JavaScript

1

2

3

4

5

6

// in the console.

vara=newNumber(1);

console.log(a);// Number {[[PrimitiveValue]]: 1}

varb=2;

console.log(b);// 2

This concern isn’t an issue outside of the console. When JavaScript expressions are evaluated or native JavaScript functions and methods are executed, the Number PrimitiveValue is automatically retrieved.

Every few weeks, I catch code where the programmer (sometimes me) is bending over backwards to try to solve a problem that ES6 (or sometimes even older versions of JavaScript) already solves. In fact, the interviewers who interviewed me for my current job, ask interviewees for a method on a built-in datatype that’s been in JavaScript for a long time. No one ever uses the built-in method, we all try to write it from scratch. That experience reminds me to always learn and refresh on the basics of your skill set. The Number type is new-ish, but is widely under utilized for some very common functionality. (It’s not the subject of the interview.)

The ES6 Number datatype. Keep in mind the Number and it’s methods are not available in Internet Explorer and mobile browsers (12% or so of users in December 2016) without shimming or transpiling. If you’re not shimming or transpiling for a professional app, you probably should because of browser compatibility and cross-browser inconsistencies; though there are exceptions depending on your audience and performance requirements of course.

The Number Object goes well with HTML5’s number. There’s not a lot of use of this input because it’s ugly and confusing, but it’s something to keep in mind.

Otherwise, if you’re not sure the value is a number or not, you can use the Number constructor to explicitly and predictably cast it as an instance of Number.

The Constructor of the Number Object

In this example, we convert data from an unpredictable source like a text input or AJAX response.

JavaScript

1

numberObject=newNumber(data);

These result of using this will be mathematically consistent, but the convenience of using the Number datatype is most valuable to prevent the developer from having to think about math. So here’s some common uses:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

newNumber(1)// Number {[[PrimitiveValue]]: 1}

newNumber(1.1)// Number {[[PrimitiveValue]]: 1.1}

newNumber('11')// Number {[[PrimitiveValue]]: 11}

newNumber('11.1')// Number {[[PrimitiveValue]]: 11.1}

newNumber(true)// Number {[[PrimitiveValue]]: 1}

newNumber(false)// Number {[[PrimitiveValue]]: 0}

newNumber(null)// Number {[[PrimitiveValue]]: 0}

newNumber('a')// Number {[[PrimitiveValue]]: NaN}

newNumber('11,1')// Number {[[PrimitiveValue]]: NaN}

newNumber(undefined)// Number {[[PrimitiveValue]]: NaN}

newNumber(void0)// Number {[[PrimitiveValue]]: NaN}

// notice these three throw developers off from time to time.

newNumber(true)// Number {[[PrimitiveValue]]: 1}

newNumber(false)// Number {[[PrimitiveValue]]: 0}

newNumber(null)// Number {[[PrimitiveValue]]: 0}

// but thankfully, there's only one level of implicit conversion.

newNumber('true')// Number {[[PrimitiveValue]]: NaN}

newNumber('false')// Number {[[PrimitiveValue]]: NaN}

newNumber('null')// Number {[[PrimitiveValue]]: NaN}

This is great, it’s predictable: you’re going to get a Number Object and it’s either going to have a value of a number or “not a number.”

Numbers you can use

When you want to see if a value passed as an argument to a function is a usable number? Before ES6 you had the global isFinite function. You can still use it, but it’s hard to remember all of the built in globals, they’re more likely to get written over, but perfectly acceptable. I prefer using the new ones built on the Number object. I like code to be intentional and explicit. Further, there’s potential for JavaScript runtimes to lack the window methods; for instance, NodeJS doesn’t have the window object, if you’re using window[method] notation, your code wouldn’t be reusable unless you account for global[method]. Native run times may eliminate global methods altogether, since they’re not as chained to the Browser API.

JavaScript

1

2

3

4

5

6

// Check to see if a value is safe to use.

if(Number.isFinite(value))...

// is the same as

if(isFinite(value))...

Here’s some examples of what you get using Number.isFinite(value):

JavaScript

1

2

3

4

5

6

7

8

9

10

Number.isFinite(1)// true

Number.isFinite(1.1)// true

Number.isFinite(NaN)// false

Number.isFinite("a")// false

Number.isFinite(Infinity)// false

Number.isFinite(-Infinity)// false

Number.isFinite(undefined)// false

Number.isFinite(1/0)// false

Number.isFinite(null)// false

The first thing you can do is use the Number constructor to explicitly recast strings consisting only of a number to a Number type.

JavaScript

1

2

3

// if you want to accept strings consisting only of a number,

// you can get that by using the Number constructor like this.

value=newNumber(value);

So you can do something like this:

JavaScript

1

2

3

4

5

6

7

8

function(arg){

// if you want to accept strings consisting only of a number...

numberObject=newNumber(arg);

if(!Number.isFinite(numberObject)){

// throw, reject, return, etc.

}

// the rest of your code.

}

Using the number

If you want to work with that number like you would a number literal, you can get the value back by using the “valueOf” method.

JavaScript

1

value=numberObject.valueOf();

You can use the “value” just as you would any number literal or trusted variable. Otherwise, you can use the “numberObject” (the instance of Number holding our value) and all of the methods that live on the instance (covered in future posts).

Other Global Number methods

Number also includes methods for checking a number to see if it is an integer and safe integer.

1

2

3

4

5

6

7

8

9

10

11

Number.isInteger(100)//true

Number.isInteger(-100)//true

Number.isInteger(.1)// false

Number.isInteger(1000000000000000000000)//may be true, may not. I got true.

Number.isSafeInteger(100)// true

Number.isSafeInteger(1000000000000000000000)// false

Number.isSafeInteger(1.1)// false

Number.isInteger(Infinity)// false

Number.isInteger(-Infinity)// false

Number also has methods for the globals isNaN, parseInt, and parseFloat.

Number’s you can’t lose: Constants

My audience is unlikely to use these Constant properties, but here they are:

JavaScript

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Number.MAX_SAFE_INTEGER// Largest integer guaranteed by all JavaScript runtimes.

Number.MAX_VALUE// Largest number guaranteed by all JavaScript runtimes.

I recently sent out this suggestion to some of my clients. From my client’s perspectives, investing in upgrading libraries can sometimes be a hard sale. It cost money to have people go through and change working code and it opens up the opportunity for new bugs.

Should we upgrade to jQuery 3?

Compatibility with future code. It will be much faster and cheaper to change the website in the future because 3.0 is more standards compliant and is easier to debug. Why is it better?

Method signature and return values changes are sensible and help write more concise code and are easier to debug. Specifically, the $.post/$.get methods now accept options, and that DOM ctor now returns an empty array instead of a null value.

Real Promise support means interoperability with Promise debugging now and Async Functions in the future.

It seems that the Maven installation instructions around the web are convoluted or out of date. (I kept getting: “Error: ACould not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher”) Here’s how I did it with v.3.3.9 on Windows 10, I see no reason why this wouldn’t be the same on Linux or Mac with the relevant parts changed.

1. Download the -bin.zip (the full zip is missing stuff.)(If you’re on linux, use the gunzip file.)

2. Set the JAVA_HOME environmental variable. The dependency on JavaSDK must explicitly be referred to with the environmental variable JAVA_HOME = C:\Program Files\Java\jdk1.x.x_xx (in my case: C:\Program Files\Java\jdk1.8.0_91) or wherever you keep your Java SDK.

3. Unzip Maven, I put my portable executables in C:\tools\ so mine was extracted to C:\tools\maven.

4. Add Maven bin to PATH, in my case C:\tools\maven\bin
(see below this article, if you need instructions on that).

5. Test it out in the command prompt, by typing: mvn -v

And your done!

Errors to Avoid:
1) Older versions required setting M2_HOME, M3_HOME, and/or MAVEN_OPTS. The should be blank and not exist. 2) Tutorials often tell you to install the full file, just download the bin. If you need the rest of Maven, you’ll know you need it and you probably won’t be reading this tutorial.

2) “Error: ACould not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher” is popping up because you’re missing packages, if you install the “full” version, it’s missing this. If you install the -bin version suggested above, it is not missing.

3) Setting/Editing Environmental VariablesIn Windows, it’s easiest to access from the start menu. Open Start and search for (or just start typing) Environmental Variables… and you’ll see suggesstions from Windows to the right place by the time you get to “Envi.” Click one that says something like, “Edit the system environmental variables” or “Edit the environmental variables for your account.”

I like to use the account level, not the system level variables. To change a variable, you click on it and select edit. This will give you a prompt with the variable name and the value. For path, pre-Windows 10 mid-2015, you needed to manually add in the path by editing the PATH variable. c:\existing\paths;c:\existing\paths;c:\path\to\maven\which\you\added

Make a copy and save the existing path if you’re doing it this way. You don’t need to accidentally ruin your PATH variable. No it’s not the worst thing to recover from, but just save a copy first. Make gramps over here happy.

Notice the semicolon before your new one.

Windows 10 makes it even easier. When you edit PATH you get a cool interface that makes it easy to do and hard to mess up.

Command line? Don’t, but if you insist: set PATH=%PATH%;C:\path\to\maven\bin (this adds it to the beginning, this is like doing “path = new + path;” in other languages).Linux/Bash? PATH=/data/to/maven/bin:$PATH

These are some very minimal changes to the standard express.js generated app.js file. It looks nice, “=>” syntax is getting easier to read the more I use and get used to it. Note: I took out a lot of unrelated code to isolate the topic of the blog. This example is for getting a development, learning environment ready to use Babel.js with Express on the back and front ends.

How’d I do it?

Using Babel’s “babel-node” cli tool, its compiling in real time in the development env. For production, do not use babel-node, you’ll want to compile with Babel.js then run with node. Just use “npm install -g babel-cli” and babel-node is already there and built in.

I also included eslint for good measure. Make sure to “npm install –save-dev babel-eslint” and set the parser to “babel-eslint.”

What else do you suggest that can I do to the app.js to take advantage ES6 features, without straying too far from the default?