Javascript Predictions For 2016

Typescript

Will be big. It's not just the combined power of Microsoft and Google pushing this forward. Angular 1.x / React excel at 'Todo' applications. Unfortunately, real business logic is rarely as simple as this. Once an application develops into 100k to 500k lines of code, javascript can be fragile. Successful applications inevitably get this large, and Typescript will offer a way forward.

Ruby

Will wane. The agile world will continue to move on to Node and Javascript. ASP.NET Core will gain momentum, more specifically the ability to write .NET applications that work reliably on Linux. Something that was once a bulky, enterpris-ey, toolset now works incredibly well with npm and a text editor. Sadly, Ruby needs a large corporate sponsor to move forward. I don't see one emerging.

Grunt, Gulp or npm?

Undecided. 2016 will continue to be a dark and muddy field of build tools. I still like Gulp and bower. I have no reasons to back that up other than resistance to change. (Ha! Bower has only been around since 2012). My biggest gripe with just using npm is that things are placed in node_modules, and I get a better separation between browser-side and server-side using bower along with npm. Webpack is nice. The problem is, as Kyle Simpson explained in You Don't Know JS: ES6 & Beyond, once we have http/2 small javascript files will once again be more performant than bundling them all into one large file.

So that's perplexing enough, let's add transpilation into the mix. ES6 via Webpack and Babel seem like good way to go, but will bundling go out of style next year as Kyle suggests? Maybe just Typescript?

I'm still using Angular 1.x. I've started to tinker with Angular 2 but haven't deployed any code professionally with it. I'm waiting to see what the 'official' Angular 2 build-and-deployment chain ends up being before I sort out my build procedures. After raving about Typescript just three paragraphs ago, I'm not sure I want to use it.

Honestly, the goal isn't finding the 'one true way,' it's just finding a good 'one button build' for my current workflow. One button builds have been 'best practice' since at least the C++ Coding Standards written by Herb Sutter and Andrei Alexandrescu way back in 2004. That much hasn't changed. I just want to hit 'ctrl-S', and watch my browser refresh with the latest content. That's all ;)

Will another language replace Javascript in the browser?

Nope. In 2016, it will still be javascript. To paraphrase Churchill: “It has been said that Javascript is the worst form of language for the browser, except all those others that have been tried.”

read more / comment

Links. 1/19/16

Feynman's Derivation of the Schrodinger Equation (Fermat's Library)

Fermat's Library is a great website that breaks down important research papers and provides a place for people to put commentary.

Writing Fast Code 1

Writing Fast Code 2

Andrei Alexandrescu's lessons learned after writing C++ at Facebook... And quitting to work on the D language full time.

How to run ASP.NET 5 on a Raspberry Pi 2

ASP.NET formally hosted outside of Windows will be a big deal.

read more / comment

k-Nearest Neighbors

How it works

k-Nearest Neighbors (kNN) can appear to be a black box. Naively using it on complex data sets makes it seem magical. That's why looking at the simplest 'base case' can be illustrative. Once you understand the underlying idea, you can make sense of the results for larger data sets.

To make this incredibly simple, we'll just take the first nearest neighbor, so the k in kNN will be 1. We will also categorize our data set with two classes: Red and Blue. Keeping with the simplistic use case, we will plot two features: one that goes from 0 to 3 and the next that goes from 0 to 180.

Click and drag any point to find your k-nearest neighbor. The graph will dynamically update. Can you see why the 'Test Case' starts off Blue and not Red? Doesn't the red case appear closer?

To find our '1 Nearest Neighbor' we simply find the Euclidean Distance between each sample in the training set, and our Test Case we want to classify as being 'Red' or 'Blue'.

The Euclidean Distance formula in our simple example is the same as the Pythagorean Formula:

\( d(test,q) = \sqrt{(test_{1} - q_{1})^2 + (test_{2} - q_{2})^2} \)

The Scale Problem. What's an order of magnitude among friends?

In the interactive demo above, can you see a potential problem?

Even though we used the correct distance function, our two variables have very different ranges (from 0 to 3 and from 0 to 180). You can have a Test Case be very distant on the y-axis and still be the nearest neighbor. Mathematically using the Euclidean distance algorithm, this is correct - our y-axis changes little so its distance will have a small impact on our nearest neighbor. In data analysis, is this correct? The answer... it depends!

Cathy O'Neil brings up the following example. Image you are designing a kNN algorithm for a website where you have to suggest products to new users who have just visited your site for the first time. Imagine your new user has the following data:

{age: 25, salary: 55,000 }

Your nearest neighbor may be:

{age: 78, salary: 54,000 }

In other words, you are associating your new user, who is 25 years old, with an existing user who is 78, because the salary feature dominates the Euclidean Distance algorithm. In the example above, without a scale factor, you might as well only use the salary information.

You might scale the salary by 1,000 and use 55 and 54 instead of 55,000 and 54,000. But does this under-represent your salary data? Knowing if the scale is correct and noticing if you are over-emphasizing or neglecting features is arguably more art than science. Like most things, the simple base case becomes fabulously complex in the real world.

It's easy to poke holes in our easy example, but on large datasets, persuasive models can seem accurate against test data - but realistically be no better than flipping a coin.

Basic KNN d3.js example on Github

read more / comment