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


NodeSchool “How to npm” notes

The lesson of the day is “You get what you pay for.”’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.

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.

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.

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.

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

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!

Codecademy “Learn the Command Line” notes

This course would be more accurately titled “Learn Bash” though the beginner audience wouldn’t necessarily understand that title. Most of it is broadly applicable to the various command line shells used in Unix & relatives, but some parts are specific to Bash. It’s fine: most Linux distributions default to Bash, and it’s close enough to the command line of the Mach+BSD blend that underlies modern MacOS.

Neither Microsoft’s legacy DOS command line nor the newer PowerShell are mentioned.

The course is a very brief overview of the basics.

  • File system hierarchy traversal
  • File manipulation and management
  • Some of the common command line tools like “grep” and “cat”
  • Trivial Bash environment customization via .bash_profile

The organization of the class is a little different. Most of Codecademy are set up to first teach a concept then ask the student to try it themselves in the class environment. The command line class is the opposite: it asks the student to type in things before explaining what just happened.

I am comfortable learning by hands-on tinkering. After I followed the instructions and typed in stuff like a trained monkey, I stopped and tried to guess what I just did before reading the answer. I believe retain the information better if I successfully reason out the logic during this guessing period.

But it doesn’t fit in the standard Codecademy template so it comes across as a little odd. I personally prefer it but I can understand if some people would not.

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.

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.