Notes on Codecademy “Learn CSS: Browser Compatibility”

Web developers must keep in mind not everyone can see and interact with a site in the same way. This is not just a fundamental of web accessibility, but also the fact there are many different web browsers out there running on a huge range of hardware platforms. They won’t all have the same capabilities, so with that fact in mind we proceed to “Learn CSS: Browser Compatibility“.

The first and most obvious topic is CanIUse.com, our index for features supported in various browsers and an invaluable resource. After that, the course talks about how different browsers have different default style sheets. There are reference resources to see what they are, and there exist tools to mitigate differences with a “normalized” or “reset” stylesheet. But if we simply can’t (or won’t) stay within standardized subset, we can use “prerelease” features via vendor prefixes. Either manually or via automated toolsl like Autoprefixer. This is the first of many tools within a whole category called “polyfill” that implements newer features in a backwards compatible way, making user experience more consistent across older/less supported browsers. I knew there were polyfill tools for transpiling new JavaScript features to run on browsers with older JavaScript engines, but I hadn’t know there were CSS polyfill tools as well. Perhaps I needed to pull in one of them to run Angular on Windows Phone? Codecademy pointed to Modernizr and Polyfill.io as starting points to explore the world of polyfills.

Polyfill tools run at development time to decide what to do. But what if we can adjust CSS at runtime? This is the intent of CSS Feature Query, whose syntax looks a lot like CSS Media Query but for browser CSS feature support. Using this feature, however, is a bit of a Catch-22. Not all browsers support CSS Feature Query and obviously those browsers wouldn’t be able to tell us as such via the very mechanism that we’d use to ask for such information. This impacts how we’d write CSS using feature queries, and a likely place for bugs. Finally: we’d need some ability to debug feature query issues via browser developer tools, but a quick web search came up empty.


Completion of this course also gave me Codecademy completion credit for their “Learn Intermediate CSS” course, which is a packaged compilation of the following set of courses I took individually:

  1. Learn CSS: Flexbox and Grid
  2. Learn CSS: Transitions and Animations
  3. Learn CSS: Responsive Design
  4. Learn CSS: Variables and Functions
  5. Learn CSS: Accessibility
  6. Learn CSS: Browser Compatibility

But Codecademy had even more web styling classes beyond this package! I proceeded onward to learn color design.

Notes on Codecademy “Learn CSS: Accessibility”

During Codecademy’s “Learn CSS: Variables and Functions” course, I was mildly disappointed to learn that CSS custom properties and fixed calculation functions were far less powerful than I had mistakenly thought from the course title. No matter, they are sufficient for their intended purpose, and they are valuable tools for building pages that are inclusive to all users. Which is why the next class in Codecademy’s CSS curriculum is “Learn CSS: Accessibility.

First up is the size of text, the most significant factor in typographical design. This is a deep field with centuries of research from the print world, Codecademy can’t cover them all and correctly doesn’t try. We do get a bit of coverage on font-size, line-height, and letter-spacing. One oddity: a conversation on paragraph width introduces the CSS unit “ch” with 1ch being width of the zero character. (“0”) This allows specifying lengths in a way that scales with the font, but that sounds like what “em” does as well. A quick search didn’t find why we would use “ch” vs. “em”.

Another topic was color and contrast. The expected color wheel discussion talks about selecting different colors with high contrast, but it didn’t talk about color blindness. The course linked to a contrast checker tool by WebAIM, but it didn’t mention color blindness, either. A quick search on WebAIM site found a page for color blindness, but it is incomplete. The page ends with an example: a train map where routes are represented by colors. The page tells us that the different routes would be difficult to tell apart for the color-blind, but it doesn’t give us a solution to the problem! My guess? Maybe we can use different line styles?

This section also taught me there is a semantic HTML tag for denoting abbreviations.

<abbr title='Cascading Style Sheets'>CSS</abbr>

I don’t think this should be classified as an accessibility measure because it would be helpful for all audiences. This information is certainly available to screen readers, but there is some visual indication on a normal rendering. My browser renders it as dotted underlined text by default. (“user agent stylesheet”)

abbr[title] {
    text-decoration: underline dotted;
}

Another topic I didn’t think should be classified as accessibility is a discussion on changing rendering for print media. This should have been part of the media queries course, but at least the concepts make sense. When the user is printing out a web page, we can do things like hiding a navigation bar that wouldn’t have done anything on a sheet of paper. This course also talks about printing the URL of a link, because you can’t click on a sheet of paper.

@media print {
  a[href^='http']:after {
    content:  ' (' attr(href) ')';
  }
}

However, this would only work for short URLS that can be reasonably typed in by hand. Many links of the modern web have long URLS that are impossible to accurately type in by hand. But on this vein, I think it would be worthwhile to print out the content of <abbr> tags as well.

Anyway, back to accessibility and screen readers. A section asserts that there are frequently items that are not useful for a screen reader and should be hidden. I think I understand the concept, but I thought the example was poor: In case of duplicate text, one of them could be hidden from screen readers with the aria-hidden='true' attribute. But it seems like the real fix is to remove duplicate text for all audiences! Another problem is this introduction of aria-hidden without saying anything more about it. A quick web search found this is just the tip of an iceberg called the Accessible Rich Internet Applications specification.

After the lecture, we are encouraged to read “Start Testing for Accessibility.” A short overview of several accessibility testing tools: Lighthouse, WAVE, Axe, and Accessibility Insights.

I know I have a lot to learn about web accessibility, not the least of which is learning about other ARIA properties. But there’s another side to the “not everyone sees the same web page as you do” problem: browser compatibility.

Notes on Codecademy “Learn CSS: Variables and Functions”

Following responsive design in Codecademy’s CSS curriculum is “Learn CSS: Variables and Functions“. I was intrigued by the title of this course, as “variables” and “functions” were features unexpected in a visual appearance style description syntax. I associate them with programming languages! Does their presence mean CSS has evolved to become a programming language in its own right? After this class, I now know the answer is a definite “no”.

First of all, CSS “variables” are far less capable than their programming language counterparts. The name isn’t even really accurate, as a value does not vary (hence not variable) after it is set. A value declared by one CSS rule can be overridden by a more specific CSS rule declaring something with the same name, but that’s more analogous to variable scope than actually varying its value. This mechanism is also known as CSS custom properties, and I think that is a much more accurate name than “variable” which oversells its capabilities.

That said, CSS custom properties have their uses. This course showed several cases where custom properties can be overridden by CSS rules to good effect. The first example I found very powerful is combining custom properties and media queries. It makes for a far cleaner and more maintainable way to adjust a stylesheet based on screen size changes. The second significant example is in the exercise project, where we could create multiple themes on a web page (Light Mode/Dark Mode/Custom Mode) using custom properties.

Moving on to “CSS functions”, I was disappointed to learn that we’re talking about a fixed set of data processing/calculation functions implemented by the runtime environment. We can’t actually declare our own functions in CSS. CSS functions are nowhere as powerful as C++ functions. They’re not even as powerful as Microsoft Excel functions, as CSS style sheets are not spreadsheets.

Like almost every standard associated with HTML, we see a specification that tried to rationalize a lot of ad-hoc evolution and failing to hide all of the seams. The one inconsistency that annoys me is the fact some function parameters must be separated by commas, and other functions require parameters to be separated by spaces. It is especially jarring when the two styles are used together, as in this example used in the course:

filter: drop-shadow(10px 5px 0.2rem rgba(236, 217, 203, 0.7));

The drop-shadow() parameters are separated by spaces, while the rgba() parameters are separated by commas. What a mess! How can we be expected to keep this straight? Still, these functions should suffice to cover most of the intelligence we’d want to put in a style sheet. I was most impressed that calc() tries to handle so much, including the capability to mix and match CSS units. I know the intent is to allow things like subtracting a pixel count from a percentage of width, but I see a debugging nightmare. The course covered only a subset of the set of functions, but of those that were covered my favorite is clamp(). I expect to use that a lot.

One unanswered mystery is the class recommends that we set global custom properties using :root pseudo-class as the specifier. The instruction said this is usually the <html> tag, without explaining exceptions to that rule. When is :root not <html>? The MDN documentation unfortunately doesn’t answer that question either. I’ll have to leave it as a mystery as I proceed to learn about web accessibility.

Notes on Codecademy “Learn CSS: Responsive Design”

Following a quick tour through CSS transition animations, next course on the Codecademy CSS curriculum is “Learn CSS: Responsive Design“. Up until this point, Codecademy CSS curriculum had primarily demonstrated concepts using unit measurement of pixels. This course brings us into the real world where pages have to adjust themselves to work well on devices ranging from 4.5″ cell phone screens to 32” desktop monitors.

The first focus is on typography, since most pages are concerned with delivering text for reading. Two measurements work based on font size: em is relative to the base font size of a particular point in the HTML tree, varying relative to its hierarchy. rem ignores the hierarchy and goes directly to root <html>.

Next, we move on to percentages, which are calculated based on the parent width of an element. There were a few paragraphs dedicated to how height calculations are based on parent width instead of parent height, but I didn’t understand why. There was an example of how parent height could be affected by child height so using percentages would cause a circular reference problem, which I understood. But wouldn’t the same problem occur on the width dimension as well? We can specify child width as dependent on parent width, and parent width dependent on contents (child width.) Why wouldn’t this cause the very same circular dependency? I don’t understand that part yet.

When I first started trying to write a HTML-based UI for controlling SGVHAK and Sawppy rovers, I learned of a chunk of HTML that I needed to put into phone-friendly HTML. I didn’t understand what it meant, though, it was just “copy and paste this into your HTML”.

<meta name="viewport" content="width=device-width, initial-scale=1">

With this class I finally got this item checked off the “need to go and learn later” list. Codecademy even included a pointer to a reference for viewport control. This viewport control reference mentioned a few accessibility concerns, but I don’t really understand them yet. I expect to learn more HTML accessibility soon as it is listed later in Codecademy CSS curriculum.

Viewport led into media queries, another essential tool for pages to dynamically adjust between desktop, tablet, and phone usage. Most of the examples reacted to viewport width, which I understand to be the case most of the time in the real world. But this barely scratched the surface of media features we can query for. The one most applicable to my rover UI project is the “orientation” property, because that will let me reposition the virtual joystick when the phone is held in landscape mode.

Most of this course consisted of making changes in CSS then manually resizing our browser window to change viewport width and observe its effects. But again, width is but one of many media features that can be queried, and it’s not obvious how we can explore most of the rest. I wish this course included information on how to test and debug media query issues using browser developer tools. Such a walkthrough was quite informative in the JavaScript course and its absence here is sorely missed. A quick web search found the Media Query Inspector which looked promising at first glance, I’ll have to dig into that later. For now, it’s onwards to Codecademy’s CSS Variables and Functions.

Notes on Codecademy “Learn CSS: Transitions and Animations”

After an interesting and occasionally challenging time with Codecademy’s “Learn CSS: Flexbox and Grid” course, I followed their recommended CSS curriculum onward to “Learn CSS: Transitions and Animations“. It was an interesting and worthwhile unit, and thankfully shorter than the previous course on flexbox + grid. This is in part helped by a narrower scope: the CSS animation system does not attempt to cover all possible animations anyone may want to put on screen. It only animates a specified subset of CSS properties, but doing so covers majority of animation effects useful for adding visual interest and improving the user experience. As opposed to early HTML <BLINK>, a design misstep which definitely did not improve user experience.

Every animation system shares some fundamentals: what to change, where+when to start, where+when to stop, and how to move between start and stop points. That’s quite a few parameters to change and managing them quickly becomes cumbersome as the number of adjustable knobs increase. But CSS animation has a narrow scope, limiting the complexity somewhat. It also has a benefit: the start and stop state are specified by existing CSS mechanisms, leaving the transition system to deal with the animation-specific parameters.

This actually plays into an advantage of using CSS shorthand, which usually annoys me as presenting multiple ways to describe the same thing. Here multiple transition parameters can be collapsed into a single transition. It has all the annoyances of shorthands: it is another way to describe the same thing, and it requires memorizing an arbitrary order of parameters. But here transition has an advantage. We have the option to list multiple transitions in a comma-separated list and they will all execute simultaneously when triggered. The course called this “chaining” animations. I don’t know if the word “chain” was part of CSS specification or just a word choice by the author of this Codecademy course, but I found it misleading because “chain” implies animations that run consecutively (one after the other) instead of all animations running simultaneously in parallel.

Another way to specify multiple animations that run simultaneously is to specify “all” as the animated property. (The “what to change” parameter.) This would apply the same animation duration, easing function, and timing delay to all transitions that apply to an element. This is possible because the start & stop states were specified elsewhere in CSS. I see this as a very powerful mechanism in an “easy to shoot myself in the foot” kind of power. By specifying “all” we commit to animating all applicable property changes now and in the future. Which certainly means surprising behavior in the future when we add another change then surprised to see it animate. Followed by a debugging session that ends with “Oh, this transition applied to ‘all’.”

One thing I did not see is a way to create animated transitions between different layouts, for example when triggered by mechanisms covered in the CSS Responsive Design course. Perhaps that is not a scenario the CSS people deemed important enough?

Notes on Codecademy “Learn CSS: Flexbox and Grid”

After I took Codecademy’s “Learn CSS” course, I figured out it packaged together four shorter courses. Some of these short lessons were all material I’ve learned before and are just a review, so I flew through them quickly enough that putting together in a single “Learn CSS” made sense to me. This situation changed dramatically for the next item on the list: “Learn Intermediate CSS” is again a packaging of several shorter courses, except now the material is new to me and started with CSS flexbox. This was a new and challenging concept for me to grasp, so now I’m in favor of going by the shorter courses instead of the (now quite hefty) package.

Learn CSS: Flexbox and Grid covers the first two lessons of Learn Intermediate CSS. As soon as we started with CSS flexbox I could tell it was a powerful tool. However, this particular course fell short of the normal Codecademy standards. For each function of flexbox, we run through simple illustrative examples, which is good. Unfortunately, these small examples were too simplified for me to understand how they would be applied. In other words, we see a lot of small pieces but the course never pulled them together in a bigger picture.

My personally attempt at summarizing flexbox is: a CSS construct that attempts to capture rules for laying out child elements in a way that is flexible to changes in screen size and aspect ratio. Since there’s no way to capture every possible way to lay things out, the subset supported by flexbox thus becomes a de-facto prescription of best-practice layout from the people who designed this CSS feature. Nevertheless, there are more than enough (possibly too many) knobs we can adjust to build a layout.

While going through the simple examples, I did see certain values that appealed to my personal style. They were, however, usually not the default value. For example, when covering justify-content I thought space-between (evenly distribute available space between elements, spread across available width, leaving no wasted space at left and right edges) looks best, but the default value is actually flex-start (pack elements to the start of flow (left) and leaving empty space to the end (right)). I understand choosing a default value is challenging and I’m ignorant of many of the concerns that went into a final decision. Sometimes the default behavior to “makes sense” are actually inconsistent. For example, the default flex-shrink value is 1, but its counterpart flex-grow has a default value of 0.

After the chaos of JavaScript shorthands, I thought I was freed from that thinking in CSS. No such luck. To specify dynamic scaling behavior in a flexbox, somebody thought it would be useful to combine flex-grow, flex-shrink, and flex-basis parameters into a single flex shorthand. As a beginner, I am not a fan of memorizing an arbitrary order of numbers, but maybe I’ll grow to love it.

The feature of flexbox that most surprised me is ability to flip its two axis with flex-direction. Not only would this let us build right-to-left layouts (for Hebrew, Arabic, etc.) this even hints at the ability to build layout for traditional Chinese layout. (Words top-to-bottom in a column, then columns laid out right-to-left.)

The Codecademy project for flexbox “Tea Cozy” is simultaneously really great and really awful. They gave us a set of images, most of which are pictures to use in a layout except one image which is actually the specification for laying out a page. So we are given a picture of what the result should look like, including some key dimensions, and told to go make it happen. I understand this is highly representative of the workflow of a web developer in charge of laying out a page according to a design specification, so that is really great. But given this course has been short on the “why” of things (each lesson is “do X and Y” instead of the much more useful “Do X and Y to accomplish Z.”) it was difficult to figure out which of the tools we just learned were applicable. I faced a wide knowledge gap between course material and building “Tea Cozy”. Still, I enjoyed the challenge of this exercise. And for better or worse, I did come out of “Tea Cozy” with a better understanding of flexbox.


Outside of Codecademy, I was told about Flexbox Froggy, an interactive game for teaching flexbox. It was fun and the frogs were cute. I doubt anyone could learn the full power of flexbox just from playing this game but seeing how some of the concepts were applied was good review after my course.


The next lesson introduces CSS grid, for layouts where regular spacing makes more sense than the dynamic rules of flexbox. Laying out elements in a grid was very familiar to me, it reminded me of the early days of HTML where I would hack a layout using <TABLE>. The bad news for me is that shorthand-itis is even worse for grid. We started with grid-template-rows and grid-template-columns, then we learn the two can be shortened to grid-template. Similarly, row-gap and column-gap become gap.

Aside: I was annoyed we didn’t have consistency on whether column/row are used as prefix or suffix for these parameters.

Back to the shorthand infestation: Not only do we have shorthand, now we have multiple levels of shorthand. We start with grid-row-start and grid-row-end, which are shortened in grid-row. But that’s not all! Their was the expected counterparts grid-column-start and grid-column-end shortened to grid-column. Then grid-row and grid-column — already shorthand themselves — are shortened into grid-area. Gah!

But CSS grid has more to offer over <TABLE> than just annoying shorthand, it also has ability to control justification and alignment of elements within the grid. But the names of these control knobs are pretty unintuitive and confusing. While I can see how justify-item controls justification of items inside a grid, I don’t understand why justify-content moves the entire grid. Why is the entire grid considered ‘content’? Adding to this confusion is justify-self, which is how an item inside the grid can override justification settings from the container grid. I look at all of this and think “here be dragons.”

I had hoped the project associated with grid would be as hands-on as “Tea Cozy” but it was “merely” laying out the grid in a to-do list, far more straightforward than “Tea Cozy”. Ah well.


Outside of Codecademy: the people who made Flexbox Froggy also made Grid Garden.


After this instructive though occasionally challenging course, CSS Transitions and Animations felt a lot easier.

Notes on Codecademy “Learn CSS”

After going through Codecademy courses on HTML and JavaScript, the next obvious step for me was to visit the third pillar of the modern web: CSS. There’s a bit of weirdness with the class listing, though. It seems Codecademy is reorganizing offerings in this area. I took the “Learn CSS” class listed at the top of their HTML/CSS section and afterwards, I discovered it was actually a repackaging of several smaller CSS courses.

Either that, or the reverse: Learn CSS course is being split up into these multiple smaller courses. I’m not sure which direction it is going, but I expect this is a temporary “pardon our dust while we reorganize” situation. The good news is that their backend tracks our progress through this material, so we get credit for completing them no matter which course was taken.

Anyway, onward to the material. CSS determines how things look and lets us make our pages look better even if we don’t have professional design skills. My first nitpick had nothing to do with appearance at all: in the very first introductory example, they presented a chunk of HTML with DIV tags for header, content, and footer. My first thought: Hey, they didn’t use semantic HTML and they should!

Most of the introductory material was vaguely familiar from my earlier attempts to learn CSS. I hadn’t known (or had forgotten) that attribute selectors had such a wide range of capabilities, almost verging on regular expressions. The fancier pattern matching ones seem like they could become a runtime performance concern. Selector chaining (h1.destination covers all H1 tags with class=”destination”) is new to me, as was descendant combinator (.description h5 covers all H5 tags under something (not the H5) with class=”description”). I foresee lots of mistakes practice keeping them straight alongside multiple selectors (.description,h5 covers H5 tags and tags with class=”description” equally, without requiring any relation between them.)

In the realm of box model and layout, I have never found the default HTML content box model to be intuitive to my brain. I always thought of the border and padding as part of the element, so I expect I’ll have better luck using box-sizing: border-box; instead for my own layouts. What I don’t expect to have a luck with is positioning. I’ve played with this before and relative/absolute/fixed/sticky always felt like voodo magic I didn’t fully understand. It’ll take a lot more practice. And a lot more examining of behavior in browser development tools. And if that fails, there’s always the fallback layout debug tool of putting a border around everything:

* { border: 1px solid red !important; }

And finally, I need more practice to get an intuitive grasp of how to specify values in CSS. Most of this course used pixels, but it would be nice to design style sheets that dynamically adjust to content using other units like em or rem. (Unrelated: this URL is in the MDN “Guides” section which have other helpful-looking resources.) I also want to make layouts dynamic to the viewport. We have a few tools to obtain such values: vw is viewport width, vh is viewport height, vmin is the smaller of the two, vmax is the larger of the two. On paper vmin+vmax can tell me if the screen is portrait or landscape, but I haven’t figured out the logic for a portrait layout vs. landscape layout. Perhaps that is yet to come in later Codecademy CSS courses.

Notes on Codecademy “Learn Intermediate JavaScript”

After going through Codecademy’s “Learn JavaScript” course, the obvious follow-up was their “Learn Intermediate JavaScript” course, so I did and I liked it. It had a lot of very useful information for actually using JavaScript for projects. The first course covered the fundamentals of JavaScript but such knowledge sort of floated in an abstract space. It wasn’t really applicable until this intermediate course covered the two most common JavaScript runtime environments: browser on the client end, and Node.js for the server end. Which, of course, added their own ways of doing things and their own problems.

Before we got into that, though, we expanded the first class’s information on objects in general to classes in particular. Now I’m getting into an objected-oriented world that’s more familiar to my brain. This was helped by the absence of multiple different shorthand for doing the same thing. I don’t know if the course just didn’t cover them (possible) or the language has matured enough we no longer have people dogpiling ridiculous ideas just to save a few characters (I hope so.)

Not that we’re completely freed from inscrutable shorthand, though. After the excitement of seeing how JavaScript can be deployed in actual settings, I got angry at the language again when I learned of ES6 “Default Exports and Imports”.

// This will work...
import resources from 'module.js'
const { valueA, valueB } = resources;
 
// This will not work...
import { valueA, valueB } from 'module.js'

This is so stupid. It makes sense in hindsight after they explained the shorthand and why it breaks down, but just looking at this example makes me grumpy. JavaScript modules is so messed up this course didn’t try to cover everything, just pointing us to Mozilla.org documentation to sort it out on our own.

After modules, we covered asynchronous programming. Another very valuable and useful aspect of actually using JavaScript on the web. Starting with JavaScript Promises, then async/await which is an ES8 syntax for writing more readable code but still using Promises under the hood. My criticism here is JavaScript’s lack of strong typing, making it easy to make mistakes that wouldn’t fall apart until runtime. This is so bad we even have an “Avoiding Common Mistakes” section in this course, which seems like a good idea in every lesson but apparently only important enough here.

Once async/await had been covered, we finally had enough background to build browser apps that interact with web APIs using browser’s fetch() API. The example project “Film Finder” felt a lot more relevant and realistic than every other Codecademy class project I’ve seen to date. It also introduces me to The Movie Database project, which at first glance looks like a great alternative to IMDB which has become overly commercialized.

After the Film Finder project, this course goes into errors and error handling mechanisms, along with debugging JavaScript. I can see why it’s placed here: none of this would make sense unless we knew something about JavaScript code, but a lot of these lessons would have been very helpful for people struggling with earlier exercises. I’m sad to think of the possibility that there might exist people who would benefit from this information, but never got this far because they got stuck in an earlier section because they needed help debugging.

The best part of this final section is a walkthrough of browser developer tools to profile memory and CPU usage. There are a lot of knobs and levers in these tools that would easily overwhelm a beginner. It is very useful to have a walkthrough that focused just on a few very common problems, and how to find them. Once we know a few places to start, it gives a starting point for exploring the rest of developer tools. This was fantastic, my only regret is that only applies to browser-side JavaScript. We’d have to learn an entirely different set of tools for server-side Node.js code.

But that’s enough JavaScript fun for now, onward to the third pillar of web development: CSS.

Notes on Codecademy “Introduction to Javascript”

After reviewing HTML on Codecademy, I proceeded to review JavaScript with their Introduction to Javascript course (also titled Learn Javascript in some places, I’m using their URL as the definitive name.) I personally never cared for JavaScript but it is indisputably ubiquitous in the modern world. I must have a certain level of competency in order to execute many project ideas.

The history of JavaScript is far messier than other programming languages. It evolved organically, addressing the immediate need of the next new browser version from whoever believes they had some innovation to offer. It was the wild west until all major players agreed to standardize JavaScript in the form of ECMAScript 6. (ES6) While the language has continued to evolve, ES6 is the starting point for this course.

A standard is nice, but not as nice as it might look at first glance. In the interest of acceptance, it was not practical for ES6 to break from all the history that proceeded it. This, I felt, was the foundation of all of my dissatisfaction with JavaScript. Because it had to maintain compatibility, it has to accept all the different ways somebody thought to do something. I’m sure they thought they were being clever, but I see it as unnecessary confusion. Several instances came up in this course:

  • Somebody thought it was a good idea for comparison to perform automatic type conversion before performing the comparison. It probably solved somebody’s immediate problem, but the long-term effect is that “==” operator became unpredictable. The situation is so broken that this course teaches beginners to use the “===” operator and never mentions “==”.
  • The whole concept of “truthy” and “falsy” evaluations makes code hard to understand except for those who have memorized all of the rules involved. I don’t object a beginner course covering such material “this is a bad idea but it’s out there so you need to know.” However, this course makes it sound like a good thing “Truthy and falsy evaluations open a world of short-hand possibilities!” and I strongly object to this approach. Don’t teach beginners to write hard-to-understand code!
  • JavaScript didn’t start with functions, but the concept was so useful different people each hacked their own ways to declare functions. Which means we now have function declaration (function say(text) {}) function expression (const say = function(text) {}) arrow function (const say = (text) => {}) and the concise body arrow function (const say = text => {}). I consider the latter inscrutable, sacrificing readability for the sake of saving a few characters. A curse inflicted upon everyone who had to learn JavaScript since. (An anger made worse when I learned arrow functions implicitly bind to global context. Gah!)

These were just the three that I thought worth ranting about. Did I mention I didn’t care for JavaScript? But it isn’t all bad. JavaScript did give the web a very useful tool in the form of the JavaScript Object Notation (JSON) which became a de facto standard for transmitting structured data in a much less verbose way than XML which originally promised to do exactly that.

JSON has the advantage it was the native way for JavaScript to represent objects, so it was easy to go from working with a JavaScript object to transmitting it over the network and back to working object. In fact, I originally thought JSON was the data transmission serialization format for JavaScript. It took a while for me to understand that no, JSON is not the serialization format, JSON is THE format. JSON looks like a data structure for key-value pairs because JavaScript objects are a structure for key-value pairs.

Once “every object is a collection of key-value pairs” got through my head, many other JavaScript traits made sense. It was wild to me that I can attach arbitrary properties to a JavaScript function, but once I understood functions to be objects in their own right + objects are key-value pairs = it made sense I could add a property (key) and its value to a function. Weird, but made sense in its own way. Object properties are reduced to a list of key-value pairs, and object methods are special cases where the value is a function object. Deleting an entry from the list of key-value pairs allows deleting properties and methods and accessing them via brackets seem no weirder than accessing a hash table entry. It also made sense why we don’t strictly need a class constructor for objects. Any code (“factory function”) that returns a chunk of JSON has constructed an object. That’s not too weird, but the property value shorthand made me grumpy at JavaScript again. As did destructuring assignment: at first glance I hated it, after reading some examples of how it can be useful, I merely dislike it.

In an attempt to end this on a positive note, I’ll say I look forward to exploring some of the built-in utilities for JavaScript classes. This Codecademy course introduced us to:

  • Array methods .push() .pop() .shift() .unshift() .slice() .splice() etc.
  • Iterators are not just limited to .forEach(). We have .map() .filter() .reduce() .every() and more.
  • And of course stuff on object. Unlike other languages that need an entire feature area for runtime type information, JavaScript’s approach means listing everything on an object is as easy as .keys().

Following this introduction, we can proceed to Intermediate JavaScript.

Notes on Codecademy “Learn HTML”

Almost seven years ago, I went through several Codecademy courses on web-related topics including their Learn HTML & CSS course, long since retired. The knowledge I learned back then were enough for me to build rudimentary web UI for projects including Sawppy Rover, but I was always aware they were very crude and basic. And my skill level was not enough to pull off many other project ideas I’ve had since. Web development being what they are, seven years is long enough for several generations of technologies to rise in prominence then fade into obscurity. Now I want to take another pass. Reviewing what I still remember and learn something new. And the most obvious place to start is their current Learn HTML course.

As the name made clear, this course focuses on HTML. Coverage of CSS has been split off to its own separate course, which I plan to take later, but first things first. I’m glad to see that basics of HTML haven’t changed very much. Basic HTML elements and how to structure them are still fundamental. The course then moves on to tables, which I had learned for their original purpose and also as a way to hack page layout in HTML. Thankfully, there are now better ways to perform page layout with CSS so <table> can revert to its intended purpose of showing tabulated data. Forms is another beneficiary of such evolution. I had learned them for their original purpose and also as a way to hack client/server communication. (Sawppy rover web UI is actually a form that repeatedly and rapidly submits information to the server.) And again, technologies like web sockets now exist for client/server communication and <form> can go back to just being forms for user-entered data.

The final section “Semantic HTML” had no old course counterpart that I could remember. HTML tags like <article> and <figure> are new to me. They add semantic information to information on the page, which is helpful for machine parsing of data and especially useful for web accessibility. This course covers a few elements, the full list can be found at other resources like W3Schools. I’m not sure my own projects would benefit much from sematic HTML but it’s something I want to make a natural habit. Learning about semantic HTML was a fun new addition to my review of HTML basics. I had originally planned to proceed to a review of CSS, but I put that on hold in favor of reviewing JavaScript.

Notes on Reinforcement Learning Algorithm Implementations Published by OpenAI

OpenAI’s Spinning Up in Deep RL guide has copious written resources, but it also offers resources in the form of algorithm implementations in code. Each implementation is accompanied by a background section talking about how the algorithm works, summarized by a “Quick Facts” section that serves as a high-level view of how these algorithms differ from each other. As of this writing, there are six implementations. I understand the main division is that there are three “on-policy” algorithms and three “off-policy” algorithms. Within each division, the three algorithms are roughly sorted by age and illustrate an arc of researchin the field. The best(?) on-policy algorithm here is Proximal Policy Optimization (PPO) and representing off-policy vanguard is Soft Actor-Critic (SAC).

These implementations are geared towards teaching these algorithms. Since priority is placed on this learning context, these implementations are missing enhancements and optimizations that would make the code harder to understand. For example, many of these implementations do not support parallelization.

This is great for its intended purpose of supplementing Spinning Up, but some people wanted an already optimized implementation. For this audience, OpenAI published the OpenAI baselines a few years ago to serve as high water marks for algorithm implementation. These baselines can serve either as starting point for other projects, or benchmarks to measure potential improvements against.

However, it appears these baselines have gone a little stale. Not any fault of the implementations themselves, but merely due to the rapidly moving nature of this research field. The repository hosts implementations using TensorFlow version 1.0, which has been deprecated. There’s a (partial? full?) conversion to TensorFlow 2.0 in a separate branch, but that never merged back to the main branch for whatever reason. As of this writing there’s an open issue asking for PyTorch implementations, prompted by OpenAI’s own proclamation that they will be standardizing on PyTorch. (This proclamation actually led to the PyTorch conversion of Spinning Up in Deep RL examples.) However, there’s no word yet on PyTorch conversions for OpenAI baselines so anyone who want implementations in PyTorch will either have to optimize the Spinning Up implementations themselves or look elsewhere.

Of course, all of this assumes reinforcement learning will actually solve the problem, which I’ve learned might not be a good assumption.

Notes on Deep Reinforcement Learning Resources by OpenAI

I’m going through the Spinning Up in Deep RL (Reinforcement Learning) guide published by OpenAI, and I found the Introduction to RL section quite enlightening. While it was just a bit too advanced for me to understand everything, I understood enough to make sense of many other things I’ve come across recently as I had browsed the publicly available resources in this field. Following that introductory section was a Resources section with the following pages:

Spinning Up as a Deep RL Researcher

This section is for a target audience that wishes to contribute to the frontier of research in reinforcement learning. Building the background, learn by doing, and how to be rigorous in research projects. This section is filled with information that feels like it was distilled from the author’s experience. The most interesting part for me is the observation that “broken RL code almost always fails silently“. Meaning there are no error messages, just a failure for the agent to learn from its experience. The worst part when this happens is that it’s hard to tell the difference between a flawed algorithm and a flawed implementation of a good algorithm.

Key Papers in Deep RL

This was the completely expected directory of papers, roughly organized by the taxonomy used for the introduction in this guide. I believe the author assembled this list to form a solid foundation for further exploration. It appears that most (and possibly all) of them are freely available, a refreshing change from the paywalls that usually block curious minds.

Exercises

Oh no, I didn’t know there would be homework in this class! Yet here we are. A few problems for readers to attempt implementing using their choice of TensorFlow or PyTorch, along with solutions to check answers against. The first set cover basic implementation, the second set covers some algorithm failure modes. This reinforces what was covered earlier: broken RL code fails silently, so an aspiring practitioner must recognize symptoms of failure modes.

Benchmarks for Spinning Up Implementations

The Spinning Up in Deep RL guide is accompanied by implementations of several representative algorithms. Most of them have two implementations: one in TensorFlow and one in PyTorch. But when I run them on my own computer, how would I know if they’re running correctly? This page is a valuable resource to check against. It has charts for these algorithms’ performance in five MuJoCo Gym environments under conditions also described on this page. And once I have confidence they are running correctly, these are also benchmarks to see if I can improve their performance. For these implementations are written for beginners to read and understand, which means skipping some of the esoteric hard-to-understand optimizations that readers are challenged to put in themselves.

For people who want optimized implementations of these algorithms OpenAI has them covered too. Or at least, they used to.

Notes on “Introduction to RL” by OpenAI

With some confidence that I could practice simple reinforcement learning algorithms, I moved on to what I consider the meat of OpenAI’s Spinning Up in Deep RL guide: the section titled Introduction to RL. I thought it was pretty good stuff.

Part 1: Key Concepts in RL

Since I had been marginally interested in the field, the first section What Can RL Do? was mostly review for me. More than anything else, it confirmed that I was reading the right page. This section proceeded to Key Concepts and Terminology and that quickly caught up then surpassed what knowledge I already had. I was fine with the verbal descriptions and the code snippets, but once the author started phrasing in terms of equations it became more abstract than what I can easily follow. I’m a code person, not an equations person. Given my difficulty comprehending the formalized equations, I was a little bemused at the third section (Optional) Formalism as things were already becoming more formalized than my usual style.

Part 2: Kinds of RL Algorithms

Given that I didn’t comprehend everything in part 1, I was a little scared at what I would find in part 2. Gold. I found pure gold. Here I found a quick survey of major characteristics of various reinforcement learning approaches, explaining those terms in ways I (mostly) understood. Explanations like what “Model-Free” vs. “Model-Based” means. What “on-policy” vs. “off-policy” means. I had seen a lot of these terms thrown around in things I read before, but I never found a place laying them down against one another until I found this section. This section alone was worth the effort of digging into this guide and will help me understand other things. For example, a lot of these terms were in the documentation for Unity ML-Agents. I didn’t understand what they meant at the time, but now I hope to understand more when I review them.

Part 3: Intro to Policy Optimization

Cheered by how informative I found part 2, I proceeded to part 3 and was promptly brought back down to size by the equations. The good thing is that this section had both equations and a code example implementation, and they were explained more or less in parallel. Someone like myself can read the code and try to understand the equations. I expect there are people out there who are the reverse, more comfortable with the equations and appreciate seeing what they look like in code. That said, I can’t claim I completely understand the code, either. Some of the mathematical complexities represented in the equations were not in the sample source code: They were handed off to implementations in PyTorch library.

I foresee a lot of studying PyTorch documentation before I can get proficient at writing something new on my own. But just from reading this Introduction to RL section, I have the basic understanding to navigate PyTorch API documentation and maybe the skill to apply existing implementations written by somebody else. And as expected of an introduction, there are tons of links to more resources.

Old PyTorch Without GPU Is Enough To Start

I’ve mostly successfully followed the installation instructions for OpenAI’s Spinning Up in Deep RL. I am optimistic this particular Anaconda environment (in tandem with the OpenAI guide) will be enough to get me off the ground. However, I don’t expect it to be enough for doing anything extensive. Because when I checked the installation, I saw it pulled down PyTorch 1.3.1 which is now fairly old. As of this writing, PyTorch LTS is 1.8.2 and Stable is 1.10. On top of that, this old PyTorch runs without CUDA GPU acceleration.

>>> print(torch.__version__)
1.3.1
>>> print(torch.cuda.is_available())
False

NVIDIA’s CUDA API has been credited with making the current boom in deep learning possible, because CUDA opened up GPU hardware for usage other than its original gaming intent. Such massively parallel computing hardware made previously impractical algorithms practical. However, such power does incur overhead. For one thing, data has to be copied from a computer’s main memory to memory modules on board the GPU before they can be processed. And then, the results have to be copied back. For smaller problems, the cost of such overhead can swamp the benefit of GPU acceleration.

I believe I ran into this when working through Codecademy’s TensorFlow exercises. I initially set up CPU-only TensorFlow on my computer to get started and, once I had that initial experience, I installed TensorFlow with GPU support. I was a little surprised to see that small teaching examples from Codecademy took more time overall on the GPU accelerated installation than the CPU-only installation. One example took two minutes to train in CPU-only mode, but took two and a half minutes with GPU overhead. By all reports, the GPU will become quite important once I start tackling larger neural networks, but I’m not going to sweat the complexity until then.

So for Spinning Up in Deep RL, my first goal is to get some experience running these algorithms in a teaching examples context. If I am successful through that phase (which is by no means guaranteed) and start going beyond small examples, then I’ll worry about setting up another Anaconda environment with a modern version of PyTorch with GPU support.

Installing Code for OpenAI “Spinning Up in Deep RL”

I want to start playing with training deep reinforcement learning agents, and OpenAI’s “Spinning Up in Deep RL” guide seems like a good place to start. But I was a bit worried about the age of this guide, parts of which has become out of date. One example is that it still says MuJoCo requires a paid license but actually MuJoCo has since become free to use.

Despite this, I decided it’s worth my time to try its software installation guide on my computer running Ubuntu. OpenAI’s recommended procedure uses Anaconda, meaning I’ll have a Python environment dedicated to this adventure and largely isolated from everything else. Starting from Python version (3.6, instead of the latest 3.10) and on down to all the dependent libraries. The good news is that all the Python-based infrastructure seemed to work without problems. But MuJoCo is not Python and thus not under Anaconda isolation, so all my problems came from trying to install mujoco_py. (A Python library to bridge MuJoCo.)

The first problem was apparently expected by the project’s authors, as I got a prompt to set my LD_LIBRARY_PATH environment variable. The script that gave me this prompt even gave me its best guess on the solution:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/roger/.mujoco/mujoco210/bin

That looked reasonable to me, so I tried it and it successfully allowed me to see the second and third problems. Both were Ubuntu packages that were not explicitly named in the instructions, but I had to install them before things could move on. I did a web search for the first error, which returned the suggestion to run “sudo apt install libosmesa6-dev libgl1-mesa-glx libglfw3” and that seemed to have resolved this message:

/home/roger/anaconda3/envs/spinningup/lib/python3.6/site-packages/mujoco_py/gl/osmesashim.c:1:10: fatal error: GL/osmesa.h: No such file or directory

The second missing package error was straightforward to fix, running “sudo apt install patchelf” to resolve this message:

FileNotFoundError: [Errno 2] No such file or directory: 'patchelf': 'patchelf'

The final step was to install dependencies for MuJoCo-based Gym environments. The instruction page said to run pip install gym[mujoco,robotics] but when I did so, I was distressed to see my work to install mujoco-py was removed. (!!)

  Attempting uninstall: mujoco-py
    Found existing installation: mujoco-py 2.1.2.14
    Uninstalling mujoco-py-2.1.2.14:
      Successfully uninstalled mujoco-py-2.1.2.14

The reason pip wanted to do this was because the gym packages said they want mujoco_py version greater than or equal to 1.5 but less than 2.0.

Collecting mujoco-py<2.0,>=1.50
Downloading mujoco-py-1.50.1.68.tar.gz (120 kB)

Fortunately(?) this attempt to install 1.50.1.68 failed and pip rolled everything back, restoring 2.1.2.14 that I had already installed. Leaving me in a limbo state.

Well, when in doubt, try the easy thing first. I decided to be optimistic and moved on to “check that things are working” command to run Walker2d-v2 environment. I saw a lot of numbers and words flashed by. I only marginally understood them, but I didn’t see anything I recognized as error messages. So while I see a few potential problems ahead, right now it appears this mishmash of old and new components will work well enough for a beginner.

Window Shopping: OpenAI Spinning Up in Deep Reinforcement Learning

I was very encouraged after my second look at Unity ML-Agents. When I first looked at it a few years ago, it motivated me to look at the OpenAI Gym for training AI agents via reinforcement learning. But once I finished the “Hello World” examples, I got lost trying to get further and quickly became distracted by other more fruitful project ideas. With this past experience in mind, I set out to find something more instructive for a beginner and found OpenAI’s guide “Spinning Up in Deep RL“. It opened with the following text:

Welcome to Spinning Up in Deep RL! This is an educational resource produced by OpenAI that makes it easier to learn about deep reinforcement learning (deep RL).

This sounds exactly like what I needed. Jackpot! At first I thought this was something new since my last look, but the timeline at the bottom of the page indicated this was already available when I last looked at reinforcement learning resources on OpenAI. I had missed it! I regret the lost opportunity, but at least I’ve found it this time.

The problem with finding such a resource a few years after publication is that it may already be out of date. The field of deep learning moves so fast! I’m pretty sure the fundamentals will still be applicable, but the state of the art has certainly moved on. I’m also worried about the example code that goes with this resource, which looks stale at first glance. For example, it launched with examples that used the now-deprecated TensorFlow 1 API. (Instead of the current TensorFlow 2 API.) I don’t care to learn TF1 just for the sake of this course, but fortunately in January 2020 they added alternative examples implemented using PyTorch instead. If I’m lucky, PyTorch hasn’t made a major version breaking change and I could still use those examples.

In addition to the PyTorch examples, there’s another upside of finding this resource now instead of later. For 3D environment simulations OpenAI uses MuJoCo. When I looked at OpenAI Gyms earlier, running the 3D environments require a MuJoCo license that costs $500/year and I couldn’t justify that money for playing around. But good news! MuJoCo is now free to use.

Window Shopping: Google Machine Learning Crash Course

I’ve learned some machine learning fundamentals through Codecademy Pro, and I took a quick look at what Kaggle offered for free. There’s another option, from another name that (for better and worse) taken leadership in monetizing machine learning: Google. Their freely available Machine Learning Crash Course supposedly started as a way for Google to get their own developers up to speed, and has since been made suitable for public consumption and now available for all.

My favorite part of this course was their prerequisites & prework page. I used this as a guide to choose some of my courses on Codecademy Pro, it’s how I knew Numpy and Pandas were important to the field. However their linked “UltraQuick Tutorial” for those libraries were a bit too terse for me. I have no doubt they provided enough background for people smarter than I am. Personally, I needed help from Codecademy to get ramped up on NumPy and Pandas.

For interactive learning, these courses use Google Colab. Which feels a lot like Kaggle in the sense that they are both cloud-hosted Jupyter (or at least Jupyter style) notebooks. They differ by the server-end hardware, and the software images running on their hardware. I’m too new at this to have any feel of the tradeoffs between those two options, but I do understand the storage difference: Google Colab uses my Google Drive account for storage.

The primary reason I didn’t go with this Machine Learning Crash Course was the fact that instructions came in the form of video lectures, and that turns me off. For self-directed education I prefer the written word because I can go at my own pace and I can easily search and skip around. Many people prefer video lectures as the most direct counterpart to in-person instruction, but I don’t see it that way. For me the most valuable aspect of in-person instruction is the interactive question-and-answer aspect, which is completely lost in a video lecture.

And finally, this course does not cover reinforcement learning, which is my primary interest in applying machine learning. A search for RL on Google developer site leads to the Agents library and associated documentation, but that material was written to help apply reinforcement learning instead of teaching it. I’ll return to the TensorFlow Agents library after getting ramped up on deep RL somewhere else.

Window Shopping: Kaggle Courses

Over the past few months, I’ve spent much of my free time learning with a Codecademy Pro subscription. I was on a self-curated curriculum starting with “Learn Python 3” and ending with “Building Deep Learning Models on TensorFlow”. I felt it was time (and money) well-spent, helping me get up to speed on a lot of concepts and vocabulary on machine learning with deep learning. I enjoyed it a lot and can recommend going through the same path I did, with upsides and caveats documented over the past few blog entries.

But no one path is best for everyone, so I thought it’s worth noting a few alternative approaches. Top of the list is the learning or “Courses” section on Kaggle. They are free of monetary cost and does not require equivalent of a Codecademy Pro subscription. The course materials are Kaggle’s interactive documents that resemble Jupyter notebooks. (Whether Kaggle was inspired by Jupyter or actually cloud-hosted Jupyter I don’t know.) But it provides an interactive learning environment of a different style than Codecademy’s learning environment. In hindsight I can see how this approach might be better. Codecademy course tells us about Jupyter and Kaggle and encourages us to learn them, but going with Kaggle courses means we can start with The Real Deal immediately. Another upside is that I found it much easier to navigate/skip/skim through Kaggle course sections in their notebook format. In comparison I thought it was cumbersome to navigate through Codecademy units whenever I want to go back and review material.

One downside is that these courses assume more background than Codecademy does. For example there’s nothing to teach basic statistics and probability — the student is assumed to know them (or learn them elsewhere.) A final downside for me personally is that there’s very little here on applying deep learning to reinforcement learning. Their “Intro to Game AI and Reinforcement Learning” unit has just a single notebook “Deep Reinforcement Learning” that opens with the disclaimer:

In this notebook, we won’t be able to explore this complex field in detail, but you’ll learn about the big picture and explore code that you can use to train your own agent.

Given that what I find interesting is missing, I don’t think I’ll spend very much time on Kaggle. In principle, there’s value in seeing Kaggle instructors take on the same fundamentals for a more well-rounded foundation. In practice I’m impatient to get closer to my target. Perhaps I’ll return later for a refresher. In the meantime, Kaggle Learn might be a better option than Codecademy Pro for those who (A) already have a stronger background in the area, or (B) who prefer the notebook learning format, or (C) could not justify spending money for Codecademy Pro.

And for those that prefer video lecture format, there’s Google’s Machine Learning Crash Course.

Notes on Codecademy “Build Deep Learning Models with TensorFlow”

Once I upgraded to a Codecademy Pro membership, I started taking courses from its Python catalog with the goal of building a foundation to understand deep learning neural networks. Aside from a few scenic detours, most of my course choices were intended to build upon each other to fulfill what I consider prerequisites for a Codecademy “Skill Path”: Build Deep Learning Models with TensorFlow

This was the first “Skill Path” I took, and I wasn’t quite sure what to expect as Codecademy implied they are different than the courses I took before. But once I got into this “skill path”… it feels pretty much like another course. Just a longer one, with more sessions. It picked up where the “Learn the Basics of Machine Learning” course left off with neural perceptrons, and dived deeper into neural networks.

In contrast to earlier courses that taught various concepts by using them to solve regression problems, this course spent more time on classification problems. We are still using scikit-learn a lot, but as promised by the title we’re also using TensorFlow. Note the course work mostly stayed in the Keras subset of TensorFlow 2 API. Keras used to be a separate library for making it easier to work with TensorFlow version 1, but it has since been merged into TensorFlow version 2 as part of the big revamp between versions.

I want to call attention to an item linked as “additional resources” for the skill path: a book titled “Deep Learning with Python” by François Chollet. (Author, or at least one of the primary people, behind Keras.) Following various links associated with the title, I found that there’s since been a second edition and the first chapter of the book is available to read online for free! I loved reading this chapter, which managed to condense a lot of background on deep learning into a concise history of the field. If the rest of the book is as good as the first chapter, I will learn a lot. The only reason I haven’t bought the book (yet) is that, based on the index, the book doesn’t get into unsupervised reinforcement learning like the type I want to put into my robot projects.

Back to the Codecademy course…. err, skill path: we get a lot of hands-on exercises using Keras to build TensorFlow models and train them on data for various types of problems. This is great, but I felt there was a significant gap in the material. I appreciated learning that different loss functions and optimizers will be used for regression versus classification problems, and we put them to work in their respective domains. But we were merely told which function to use for each exercise, the course doesn’t go into why they were chosen for the problem. I had hoped that the Keras documentation Optimizers Overview page would describe relative strengths and weaknesses of each optimizer, but it was merely a list of optimizers by name. I feel like such a comparison chart must exist somewhere, but it’s not here.

I didn’t quite finish this skill path. I lost motivation to finish the “Portfolio Project” portion of the skill path where we are directed to create a forest cover classification model. My motivation for deep learning lies in reinforcement learning, not classification or regression problems, so my attention has wandered elsewhere. At this point I believe I’ve exhausted all the immediately applicable resources on Codecademy as there are no further deep learning material nor is there anything on reinforcement learning. So I bid a grateful farewell to Codecademy for teaching me many important basics over the past few months and started looking elsewhere.

Notes on Codecademy Intermediate Python Courses

I thought Codecademy’s course “Getting Started Off Platform for Data Science” really deserved more focus than it did when I initially browsed the catalog, regretting that I saw it at the end of my perusal of beginner friendly Python courses. But life moves on. I started going through some intermediate courses with an eye on future studies in machine learning. Here are some notes:

  • Learn Recursion with Python I took purely for fun and curiosity with no expectation of applicability to modern machine learning. In school I learned recursion with Lisp, a language ideally suited for the task. Python wasn’t as good of a fit for the subject, but it was alright. Lisp was also the darling of artificial intelligence research for a while, but I guess the focus has since evolved.
  • Learn Data Visualization with Python gave me more depth on two popular Python graphing libraries: Matplotlib and Seaborn. These are both libraries with lots of functionality so “more depth” is still only a brief overview. Still, I anticipate skills here to be useful in the future and not just in machine learning adventures.
  • Learn Statistics with NumPy was expected to be a direct follow-up to the beginner-friendly Statistics with Python course, but it was not a direct sequel and there’s more overlap than I thought there’d be. This course is shorter, with less coverage on statistics but more about NumPy. After taking the course I think I had parsed the course title as “(Learn Statistics) with NumPy” but I think it’s more accurate to think of it as “Learn (Statistics with NumPy)”
  • Linear Regression in Python is a small but important step up the foothills on the way to climbing the mountain of machine learning. Finding the best line to fit a set of data teaches important concepts like loss functions. And doing it on a 2D plot of points gives us an intuitive grasp of what the process looks like before we start adding variables and increasing the number of dimensions involved. Many concepts are described and we get exercises using the scikit-learn library which implements those algorithms.
  • Learn the Basics of Machine Learning was the obvious follow-up, diving deeper into machine learning fundamentals. All of my old friends are here: Pandas, NumPy, scikit-learn, and more. It’s a huge party of Python libraries! I see this course as a survey of major themes in machine learning, of which neural networks was only a part. It describes a broader context which I believe is a good thing to have in the back of my head. I hope it helps me avoid the trap of trying to use neural nets to solve everything a.k.a. “When I get a shiny new hammer everything looks like a nail”.

Several months after I started reorienting myself with Python 3, I felt like I had the foundation I needed to start digging into the current state of the art of deep learning research. I have no illusions about being able to contribute anything, I’m just trying to learn enough to apply what I can read in papers. My next step is to learn to build a deep learning model.