# What’s important when developing software?

When talking to other developers, I can’t help but think we spend too much time on tooling and code perfectionism.

When it comes to tooling, I can’t help but think that the things we’re doing could be fairly easily done if more people knew bash and their language ecosystem’s primary build tool; like NPM, MAKE or Maven. I’d jump from one project to another and then on top of all the CLI interfaces, I also have to learn another subset (or set) of options and configuration structure. This isn’t me being a grumpy old man. This tooling problem has been around for a long time.

These tools generally emerge from the needs of a specific large project or code base. They abstract some of their patterns for building, deploying, and testing then release the tool to the outside world. Sometimes, that tool fills a vacuum that needed filling. In the JavaScript world, Grunt and Gulp have some legitimate reasons for existing; but they didn’t have good reasons for being used in so many places.

Speaking of things popping up in so many places, man “code is craft” is nonsense. Code is engineering. We are building stuff so that it works right for the demands on budget. Crafts are where you appreciate the wood and the grain, the tool and the process. Engineering is a process. We have requirements, budgets, timelines, and business goals. There’s some craftiness in engineering and some engineering in craft, but they prioritize different things.

Getting things done to the required level of resiliency is important. Sometimes, a craftsperson will put their foot down on a quality issue, but it might before for the sake of the craft, code “quality”, or purity. For an engineer, we have to be aware of certain minimum standards that are necessary. An engineer may have to put their foot down for quality, but this quality is often about software resiliency and security where people’s lives, financial well-being, or privacy is at stake. We may have to push back against a customer for their own best interest in real, high stakes matter. This is not diminutive of craft. Some great tools (see paragraphs above) have emerged from the love of code and processes, but ultimately, the tools that stick around did so because they were useful.

This all being said, there’s still a lot of good tooling. There’s still a lot of places where craft-like code and resilient software development overlap; just don’t get too bogged down. Make something that something, get feedback and improve it.

# Developer onboarding to Angular Project

## Philosophy of This Project

1. 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.
2. 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.
3. 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.

## Resources

### Get Familiar with @NgModules (Angular Modules)

File Structure Pseudo Code:

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.

becomes something like:

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.

# Gaming to Get Better at Programming

Beyond leveling up in the RPG of a tech career?

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.

#### Sub-Class

You’re Mage might focus on fire spells, your friend the back-end developer may focus on .NET or Java. Maybe there’s sub-sub-classes, Like Angular Front End Developers and MongoDB focused Database Programmers. An application developer may focus on location services, local storage, UI, etc. (I don’t know, you tell me.)

#### 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.

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?

# Using try…catch…finally in JavaScript, follow up

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.

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

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.

• https://blog.grossman.io/how-to-write-async-await-without-try-catch-blocks-in-javascript/
• https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9

# Try…Catch…Finally Error Handling in 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.

• 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.

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.

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?

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.

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.

# Javascript Fundamentals: Number Datatype Part II

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.

You can see all the methods on the Number Instance here.

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:

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.

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.

### 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.

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:

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.

# JavaScript Fundamentals: Number Datatype Part I

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.

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:

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.

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

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

So you can do something like this:

### 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.

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.

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:

Next time, we’ll look at some of the instance methods on the global Number object.

# Should you upgrade to jQuery 3?

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?

• JQuery 3 aggressively implements newer web standards. This means jQuery code and non-jQuery code(plain JavaScript/DOM/Browser APIs) will be more easily interchangeable. Specifically, on AJAX URLs, DOM manipulation, and Promises.
• Animation performance will greatly improve.
• 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.

Upgrading to 2/3 will lose pre-IE9 support, but practically no one uses IE8 and older (.1% of all usage): http://www.w3schools.com/browsers/browsers_explorer.asp

• $.removeAttr use when it should be$.prop(attr, false)