JavaScript

Roger Cheng

Neural network in JavaScript

When I was first introduced to neural networks, they were considered algorithms with extremely expensive computational requirements. Even the most trivial network required a high-end PC with lots of memory and floating-point math capability.

Of course, at the time a high-end PC processor ran at 90 megahertz, 32 megabytes of RAM is considered a lot, and floating point math required a separate (and expensive) floating-point co-processor.

Now the cell phones we have in our pockets have faster processor and more memory than those powerful PCs of old. Every current processor has floating-point math capability, no extra chip required.

Which means what used to be the domain of specialized programmers, running on expensive hardware, is now possible everywhere: running in a web browser like the TensorFlow playground.

But it’s still hard for a human to grasp what’s going on inside a neural network as it learns and adjusts. While the accessibility of the technology (meaning how easy it is to obtain) has improved, the accessibility of the knowledge (meaning how easy it is to understand) hasn’t.

Computer brains have made great advances in the past years…

Human brains have not.

Roger Cheng

A quick look at Phaser

In a quest for something more substantial, I looked into the HTML5 game engine Phaser. It has a large audience and an impressive set of features. It was fun poking through some of the source to see how it does its magic, but I ultimately decided against making my own Phaser creation because it is at its core a bitmap-based system.

Bitmaps don’t scale as nicely as vectors by their nature, and I place a great deal of importance on ability to scale well. In the modern HTML world, the customer might be running resolutions ranging anywhere from a 320 x 480 iPhone screen to a 3840 x 2160 4K desktop display.

The people behind Phaser isn’t blind to this. Part of the core features includes a ScaleManager class to help the process. There are also ways to load lower- or higher-resolution assets in response to the screen resolution used by the particular user. But it is an imperfect solution, there are still bitmap scaling artifacts around that plainly wouldn’t be an issue at all had the system been based on vector graphics.

Most of the Phaser titles don’t bother with scaling at all, or only scale across a few fixed resolutions. I find myself quite annoyed when I load up a sample app, just to see it take up a tiny 320×480 (resolution of the original iPhone) section of my desktop browser.

sigh

I’ll keep looking.

Roger Cheng

Upsetting the NPM apple cart

Decades-old words of wisdom from a computer science pioneer, proven true once again.

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

– Leslie Lamport

In a coincidence of perfect timing, my education of NPM yesterday came just in time for me to understand the left-pad incident. The short version is simple enough to understand: unhappy programmer took his ball and went home, causing a lot of other people grief in the process. The bigger picture, though, needed a bit more knowledge to understand.

While going through the NodeSchool.io NPM workshop I had noticed a few things. The workshop used a dummy placeholder registry but there was really no technical or policy reason why every Jane and Jack can’t run the same lesson against the global registry. Up to and including the fact that they can clean up (un-publish) their NPM package when the workshop is over.

I found that fact curious. Such open accessibility felt fragile and I was wondering about the mechanisms to make sure the mechanism is fortified against accidents or abuse. It wouldn’t be something covered in a workshop, so I thought I’d see more details of this protection elsewhere.

Nope, I was wrong.

The left-pad story proved that there wasn’t any mechanism in place at all. A hilariously trivial package was yanked, causing many houses of cards to fall down.

For all the wonders of NPM, there are downsides that had its share of critics. This incident kicked the criticism into high gear. The NPM registry owner received a lot of fire from all sides and have pledged to update their procedure to avoid a repeat in the future. But I’m not sure that’s enough for the famously anti-authoritarian OSS purists. For every “conflict resolution policy” there will be some who see “ruling with an iron fist.”

 

Roger Cheng

NodeSchool “How to npm” notes

The lesson of the day is “You get what you pay for.”

NodeSchool.io’s workshop to teach NPM (Node.js Package Manager) is titled “How to npm.”  It has the intention of letting students create a package, set up the proper dependency links, publish it, then publish it again to practice sending out updates. Since it would be bad to pollute the global package registry with a bunch of dummy student test packages, the workshop steps publish against a practice registry running locally instead of the real thing.

As of today, there’s a problem with the practice registry. It can accept updates to packages and track the version numbers, but the portion that tracks labels for these versions (“dist-tag” in NPM lingo) is broken and halts the lesson flow with a HTTP 404 error.

The symptoms match a bug in the workshop that was acknowledged, analyzed, and purportedly fixed. However, the fix is incomplete because some people are still seeing the same error in the updated version of the workshop.

Including myself!

I tried to look at the code behind the lesson and try to see if I can come up with a fix for the bug, maybe this can be my first open source contribution! But alas, I’m not yet good enough with Node.js programming to understand what’s going wrong.

Fortunately I’ve already learned a few useful things before I hit this roadblock. I believe all the material useful to somebody consuming packages has been covered. And I don’t expect to publish any packages myself soon.

But if I do, I’ll come back to this workshop again before I commit. Maybe it’ll be fixed by then.

Roger Cheng

NodeSchool “learnyounode” notes

After making my first pass through the jQuery Learning Center (I’m sure I’ll be back again) I moved on to another free learning resource: NodeSchool is a collection of resources for learning Node.js, including some self-training tutorials.

At the top of the page they point newcomers to the workshop titled “LearnYouNode”. This workshop has the subtitle “Learn You The Node.js For Much Win!” This raised my eyebrows. It wasn’t immediately obvious that the broken English was a running gag of some sort. I don’t know what it is… maybe LOLcat?

Not knowing it was a gag, I thought maybe the tutorial were written by people for whom English was not their primary language. I was worried I would get stuck trying to figure out if I’m misunderstanding broken English or misunderstanding Node.js.

Fortunately, it only took a paragraph of two of tutorial instructions to make it clear the lessons are not, in fact, broken English. Which was very good news because there was very little hand-holding. The audience is presumed to be competent developers off the bat. It actually assumed JavaScript skill level a bit higher than what I have! Fortunately close enough I could get through with some educational web searches.

The overview workshop sped me through some Node.js basics. Even better: After I successfully completed each challenge, it will show me the official answer which inevitably differed from my solution. I learned a lot from the answer key source code which I hope will help my JavaScript skills going forward.

One of the things LearnYouNode introduced me to is NPM. The Node.js Package Manager came up repeatedly in many of my previous explorations, and I knew I had to get a handle on it soon. I’ve only got a taste so far, and there’s a whole other workshop dedicated to the topic. I think that’s a good place to go next.

Roger Cheng

jQuery Learning Center

After Codecademy got me off the ground with jQuery, I moved on to the jQuery Learning Center put together by the people behind the jQuery project. The learning center assumes some level of existing knowledge, so I was glad I got the Codecademy primer first.

As expected, the jQuery Learning Center went into more depth on topics that were outside of a quick primer such as Codecademy.

Implementation: The learning center gave some details on how jQuery works behind the scenes. This helps programmers understand and debug when things go wrong, and sometimes leads to information on code performance.

Performance: Hand in hand with implementation details, the learning center teaches some basics on writing efficient jQuery code. This is different from writing terse jQuery code. What looks like small amounts of jQuery code might end up triggering a lot of work for the computer behind the scenes. A programmer unaware of the implementation and performance consequences can get tripped up.

History: The learning center occasionally switches into history lesson mode. It is moderately enlightening to understand the evolution to the current implementation. More importantly, it helps people recognize and understand old legacy jQuery code they might end up having to maintain.

Code organization: This section was not jQuery specific. It covered a few ways to use JavaScript to implement classic object-oriented programming concepts. I was intrigued by this section, because it didn’t match what I saw in the Codecademy JavaScript class. It is useful to get a different perspective on how to solve the same types of problems.

It was good timing. My own JavaScript practice program had not been written under any semblance of code organization, just building as I go, and it was growing out of control. Seeing how messy things were turned out to be great motivation to put organization concepts into practice and tame my hairy beast.

Roger Cheng

JavaScript closures make my head spin

Coming from a world of strongly typed programming languages, JavaScript is weird. And the deeper I get, the weirder it got.

I’ve had brushes with JavaScript closures in my learning to date, and the fragments I saw looked like evil black magic. Today I dove in headfirst to learn more about it.  With my new found knowledge, it no longer feels like black magic.

It still feels evil, though.

Closures have all the appearance of something that “fell out” of the flexibility of the JavaScript type system. It felt like somebody, in an effort to solve some unrelated problems A, B, and C, accidentally opened a Pandora’s Box and closures emerged. With some bizarre behavior and huge potential for difficult-to-diagnose bugs. I’d hate to think it was designed to be that way. I prefer to believe it was an accident.

Accident or not, it is a very powerful mechanism and people are using it in the world. Which means I will need to be able to read and understand code that uses closures. It is irrelevant whether I personally believe closures are evil.

It’ll take a few more rounds of practice before I’m comfortable with the nuances. In the meantime, I’ll be reviewing this page frequently as I found it to be the most helpful. The author emphasized repeatedly that hands-on experience with real closure code is more illuminating than reading a lot of rigorous academic style description of closures. So that’s exactly what I intend to do.

 

The best I can hope for is to start feeling comfortable with the power and pitfall of closures. Maybe I’ll even come to appreciate it as a necessary evil.

But I doubt I’ll ever come to think of it as A Good Thing.

Roger Cheng

Compilation of JavaScript resources

The benefit of JavaScript is that there are a ton of resources. The downside of JavaScript is that there is so much, it’s hard to figure out where to start and who to believe.

After the expected period of beginner fumbling, I now know a few things to be incorrect. But more importantly, I now know many things to have no single Right Answer(™). JavaScript is so flexible that there are many ways to do many things and not much to differentiate one from another except personal preference.

This makes me wary of advice compiled on somebody’s blog, because that’s really their personal opinion and I don’t know if I necessarily agree with that person’s priorities.

But if the collection of resources was assembled by a group of people, that makes me a little more comfortable. So I was happy to stumble across JSTheRightWay.org.

The name seemed pompous and arrogant, but the introduction made me feel like I’ve found a good thing:

This is a guide intended to introduce new developers to JavaScript and help experienced developers learn more about its best practices.

Despite the name, this guide doesn’t necessarily mean “the only way” to do JavaScript.

We just gather all the articles, tips, and tricks from top developers and put it here. Since it comes from exceptional folks, we could say that it is “the right way”, or the best way to do so.

I’ll be coming back to this page quite frequently. May it live up to my hopes!

Roger Cheng

The other “cloud development”

When I set out on this adventure, I knew I wanted to eventually cover the basics of the major cloud services. Write some sample services to run on Amazon Web Services, Microsoft Azure, Google cloud services, etc.

I was surprised to stumble into an entirely different meaning of “cloud development”: writing code in a browser. I had seen the educational coding playgrounds of Codecademy, and I had seen small trial tools like JSFiddle, but I had no idea that was just the tip of the iceberg and things can get much fancier.

I had started a project to practice my newly-learned jQuery skills. Just with a text editor on my computer and running the HTML straight off the file system. As soon as I learned of these web-based development environments I wanted to try it out by moving my project over.

The first I tried was Codenvy, whose whitepapers are quite grandiose in what it offers for improving developer productivity. Unfortunately the kind of development Codenvy supports aren’t the kind of things I know anything about today. But I’ll revisit in a few weeks to check again.

The second I tried was Cloud 9, which does support simple HTML+CSS+JS projects like what I wanted to do. Working in Cloud 9 gave me some tools for static analysis and serving my file off a real web server. It also integrates into Github preserving my source control workflow.

After a JavaScript project of around 300 lines of code, I can comfortably say I’m quite impressed. In the areas of development-time tooling and integration experience, it far exceeded my expectations. However, there was an area of disappointment: the debugging experience was either hard to find or just wasn’t there at all.

When my little project goes awry, I resorted to loading up the project in a separate browser window and using the web browser debugger. This is on par with the simpler tools like JSFiddle and JSBin. I had hoped for better.

I’m cautiously optimistic I’ll find a tool with better debugging experience as I continue to explore.

Roger Cheng

The cross-site rabbit hole

Wow, cross-site issues are huge cans of worms!

In the absence of first-hand experience dealing with network-centric development, my knowledge of cross-site vulnerabilities has been limited to broad descriptions covered in tech press.

While educating myself in the jQuery Learning Center, I came across the JSONP utility functions of jQuery. Trying to understand the utility meant I had to look up JSONP. Trying to understand JSONP required learning what problem it is trying to solve. Which dropped me into the rabbit hole of web security. Starting with a web browser’s same-origin policy, through cross-site scripting (XSS), cross-site request forgery (CSRF), and others.

The short version: Communication across multiple web domains is a very powerful thing. And like everything that’s powerful, there are people who will use it for evil. The various browser policies are efforts to shut down such activity to protect users from evil.

Like every effort to control great powers that can be used for good or evil, both sides continue to find ways to do what they want despite the walls erected to block them.

  1. Because it is so powerful for nefarious purposes: Hackers continue to find ways to circumvent cross-domain protection with clever exploitation. To keep me grounded in jQuery education, Wikipedia helpfully pointed to a cross-site security issue in jQuery itself. Problems can hide anywhere.
  2. Because it is so powerful for legitimately useful purposes: Developers continue to find ways to communicate across domains in a relatively safer manner. (Usually until a creative hacker comes along to prove why it isn’t safe.) JSONP, which started my whole adventure, is one such method.

Like everything else I’m learning about web programming, this will have to be a brief overview and I have to come back later. Right now I don’t even understand all the vocabulary yet.

I’m unsettled by this topic. The importance of network security grows with every passing day. This feels like a very fundamental area of network security, and it is a huge nasty hairball that has proven to be difficult to untangle. This can only be a recipe for more security vulnerabilities in the future.

Maybe even one that I inadvertently create.

Ugh.

Roger Cheng

JSFiddle

After completing the Codecademy jQuery class, I felt I had a decent overview but wanted more depth. I found that the jQuery project offers a jQuery Learning Center. I’ll likely write a dedicated post once I’m done, but that’s not today.

After reading a certain amount of documentation, I start feeling out of touch with the concepts: Too much theory and not enough practice. I tried to create a small project to play with jQuery but I made rookie mistakes with basic boilerplate, wasting a lot of time instead of learning.

That’s when I remembered something I saw while reading documentation for the Facebook React project: JSFiddle. I don’t have enough understanding to use React yet, but they embedded JSFiddle in their documentation so people can play with code as they go.

A fresh fiddle already has the HTML, CSS, and JavaScript all properly linked up. To use a framework or extension like jQuery, selecting from a drop-down box activates it with no fussing with tags, links, or URLs. Once the code snippets have been typed in, a click on “Run” will render to the output window. No upload to web server necessary.

This is a huge advantage when testing small pieces of code. No need to get bogged down in repetitious boilerplate, just focus on the interesting bits. I had a great time putting the various bits of theory into practice.

A downside for me was that debugging got messy. When I’m debugging just my own HTML with the browser’s built-in debugging tools, I have only a tiny bit of code to examine and all of it is mine.

But when I launch the browser debug tools on a fiddle, the debugger puts the whole JSFiddle page under examination. Even though my code is only a tiny part of the page. It gets tiresome trying to separate out my item of interest from everything else going on with the JSFiddle page.

But still, JSFiddle looks like a great tool for experimentation.

Roger Cheng

Codecademy “Interactive Website” notes

I left the Codecademy “Interactive Website” class irritated.

In their “Make a Website” class, it was a fun overview of HTML and CSS by building a specific project. No previous knowledge required. If people want, they can then go into the “HTML & CSS” track and learn in more depth.

I thought “Interactive Website” would work the same way, an introduction to the JavaScript and jQuery classes with no prior knowledge required.  But the first interactive exercise felt otherwise: It asks the student to create a program skeleton by writing a JavaScript function, which beginners coming straight from “Make a Website” class wouldn’t know how to do.

I thought to myself “Huh, this feels out of sequence. I’ll go through some other classes and come back later.” I went through the JavaScript and jQuery classes before returning. After I got past that first exercise, I saw the rest of the “Interactive Website” actually does introduce beginner concepts for JavaScript. Such as: how to write a function.

Why does the first exercise require knowledge people wouldn’t learn until later in that class? That feels like a poor way to structure the class. Looking in the forums, I saw I was not the only one. Several other people complained about the class structure, dating back several months.

Sometimes I  get reinforcement that I get what I paid for. Ah well, time to shrug it off and move on.

 

Roger Cheng

Polyfill: for the gap between theory and reality

Today was a fun day hopping from one educational site to another. Since I just completed the jQuery track on Codecademy, I thought I’d look around for additional jQuery resources before I dive into another Codecademy track. The jQuery Learning Center sent me to the Mozilla Developer Network which in turn sent me to Google Developer resources which set me to…

Every one of those sites would occasionally mention some kind of polyfill. It’s not the first time I came across the term, but I had assumed it was a vector graphics concept: Draw a polygon and fill it with a color, or something along those lines. As I came across more and more polyfill references, though, I started to realize my original assumption was wrong.

In the current web development world, there’s the grand theory of HTML5, the gold standard by which all of the web will flourish. But in the real world, we are hampered by the fact that none of the browsers fully implement web standards in all the same ways. There’s even a web site set up to document all the ways in which various browsers fail to fully implement these standards.

The gap between theory and reality is bridged by polyfill, a category of tools created by various frustrated developers to make individual real-world web browsers work closer to somebody’s idea of perfect browser.

Coming from the world of operating system development, I know of this concept by the name of “compatibility shims” and I’ve even had the misfortune privilege of writing a few of them myself. Since they’re bridging the ideal world and the ugliness of the real world, shims are never great pieces of code. A shim is always constrained by some inconvenient reality, written to solve a very specific problem, and never quite live up to the ideal.

So I was not terribly surprised that we have many, many polyfill libraries floating around. Each can solve a specific problem under a specific circumstance, none are capable of solving all the problems perfectly. To solve a specific problem, a developer would have to comb through the list and test to figure out which polyfill to use. I’m sure some end up writing a quick-and-dirty solution to their one Problem of the Day instead of using a library.

But I do admire the ideal of having a centralized resource!

Roger Cheng

Codecademy “jQuery” notes

The “jQuery” class track was my first Codecademy class where everything is new to me. It was a lot of fun!

I’m very amused that the “new HTML” has ditched a lot of the mechanisms of the “old HTML” yet they’re all together in one big bucket of HTML. There were input forms using the input fields that I had known before, but they don’t bother with the form submit at the end. Entirely different script code is executed to replace the old-school form submit.

A whole lot of “new HTML” is hitched to the <div> element. Which, in the old world, does nothing. (That’s not a sarcastic remark, read the official specification.) But with CSS and jQuery, the empty placeholder of a <div> becomes the starting point for visuals, actions, responses, all kinds of things impossible in old static HTML.

This was also the first Codecademy class that referenced API documentation for the class material. I was a little annoyed with the previous classes that lacked a pointer for students to get more information.

Towards the end of the class, they introduced jQuery UI, which is a separate library built on top of jQuery. I think the fact they were two separate entities deserved more emphasis, and the class didn’t get into why they were two separate things at all.

Once I understand how the design philosophies differ between the two, I will have an idea if I should look in one or the other for any specific thing I might be researching. But I don’t have that yet! So I’ll have to look in both places until I do.

 

Roger Cheng

Codecademy “JavaScript” notes

The Codecademy class for Javascript covers a lot of ground. It teaches the JavaScript language alongside some programming fundamentals. I thought it was a decent introduction but it’s hard to gauge what it would look like to fresh eyes.

A side effect of the style meant the pacing can be frustrating when I’m already familiar with programming but not familiar with the JavaScript specifics. Some places would have a lot of repetition on general concepts I knew (“yes, yes, move on”) and followed by a brief mention of something uniquely JavaScript (“wait, I wanted more information on that.”) before moving on. Example: JSON.

The class covered some basics of object-oriented programming, but not much explanation on the why behind it. In the context of simple programming exercises, OOP looks like unnecessary overhead. Maybe the creators of the class decided that is out of scope. People will learn about organization and object hierarchy as they get exposure to more complex tasks sometime down the line.

As a C/C++/Java/C# veteran, I look upon JavaScript’s type system with some suspicion. It is extremely flexible, which can be very powerful when used correctly, but it seems very easy to shoot myself in the foot. The fact that most efforts to improve JavaScript (Dart, TypeScript, etc.) introduce a stronger type system tells me I’m not alone in this suspicion.

In the web world, where projects are built on top of a set of libraries talking to each other via JavaSript, the type system means there’s nothing really keeping one library from trampling all over (uh… “adding features to”) the types defined in another library. The chaotic churning of types sound like a very tough class of problems to debug. That’s the theory, anyway. I expect real-world practice to be one of three possibilities:

  1. It’s under control: There are conventions in place, or maybe there are tools to manage it, or at least debugging aids to detect chaos in progress.
  2. It’s not a problem: Despite my paranoia, in practice just because the type system is flexible doesn’t mean it is abused.
  3. It’s exactly as bad as you think it is. We deal: Oh I hope it’s not this one.