I’ve set aside some time to take some online courses at FrontendMasters to deepen my understanding of various engineering principles as a personal continuing education goal. While taking courses I focus by taking notes, and figured I may as well share them with the world, so welcome to the Learning Series!
This writeup got a little long because I found so much of the course interesting, so here’s an outline – feel free to jump to the bits you find interesting:
Introduction and Background
For those that are excited about licenses and things, Crockford also famously used the MIT license in his tools but with a slight modification: He adds the line “The Software shall be used for Good, not Evil“. This is part of the licensing in JSLint as well as JSON. Yay for Good, is your JSON used for Good?
- Left or right curly braces? Right is better, some cases of using left will silently break your code and you could waste time diagnosing the simple fix. So consistently use curly braces on the right, because you will never have this problem.
- Always manually add semicolons – don’t rely on the computer to automatically add them because they sometimes get added in unintuitive ways which can dangerously break your code if you leave it up to the machine.
- Don’t use “with” statements in order to avoid confusion on how “with” loops work slightly differently than others.
- Always use triple equals
Not using some of these smart best practices is the equivalent of pointing a gun at your foot and saying “Watch this, I almost never miss!” You might miss, but you might not and the more times you do it, eventually you don’t miss. That would be a tad uncomfortable.
History of HTML
HTML also has a long meandering history. There was a markup language used for print called Runoff. This led to another called ROFF. To standardize a few things they came up with Generalized Markup Language. Then Standard Generalized Markup Language (SGML) brought angled brackets and attributes from another markup called Scribe. Hypertext Markup Language was also influenced by apple’s hypercard. XML then came in to make a claim to standardizing the markup.
It’s very interesting to me to look at this example of GML and see how clearly it influenced HTML. I feel like a digital archeologist looking through old code to better understand current code.
Fun Fun Functions
There is an entertaining and educational part of the course where we are provided with a synopsis of a fairly simple function, given time to write our own, and then discuss the “best” solutions. It ended up being nearly 50 exercises and accompanying functions. They tended to build on each other as well, so it was a nice programming challenge and throughout I learned a good deal and through discussing them began to see the simplicity and even genius of functional programming even more. Below is a gist I created showcasing the functions I tried to write the requirements for each function in the comments. The function exercises I most enjoyed were the recursion and curry functions but they also touch on higher order functions, closure, generators, factories and factory factories.
A quick dive into scope and closures
When a variable is defined in a function it is scoped to that function and can be used within. For example below, the variable a can be used within the green and the yellow functions. The variable b can only be used in yellow. The a variable will stick around in memory as long as there is a function with a reference to it.
Many principles of security come from cryptology and ciphers. Auguste Kerckhoffs, author of a military cryptology book in the 19th century, states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Today we still follow this principle.
The web does get an important security issue right that much other software does not. It doesn’t blame the victims. In other platforms we see a lot of “blame the victim” security models. It’s where we’ll ask the user a question that the user cannot possibly understand or answer correctly. And then when things go wrong it’s the user’s fault for having agreed to this. That’s not a security model, that’s just…stupid! It’s similar to signing every right to privacy away in a legal document before using a product. The browser doesn’t do that (by default). Now the price of that is that the browser is limited in some ways. It’s up to us, the builders of the web, to be smart about how we reduce those limitations in responsible and secure ways. For the sake of security, we must think “Whose interest does the program/website represent?” The user, the site owners, the third-party ads?
In the end, we as engineers are emotionally connected to our code and as irrational as any other human. We like to think we are smarter than average, but really we’re all human. We should use things like JSLint (or the 10up eslint code styles) to help us write better and more secure, cleaner code.
I found the course entertaining, educational. It helped me understand the ecosystem of the web by seeing a little more clearly the history of the technologies. The top points of the course for me were the history lessons and the function exercises. I recommend taking this course if this subject matter sounds interesting to you, be aware though that Douglas is as opinionated as JSLint and at times projects a smarter-than-thou attitude which some may find off-putting.
Have you taken the course? Read his book? What were your highlights?