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.”
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.
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.
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.
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.
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.
It still feels evil, though.
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.
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:
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!
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.
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.
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.
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.
- 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.
- 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.