Codecademy “Learn Git” notes

While fiddling with my HTML experiments, I start feeling the need to keep different versions around and the desire to undo experiments (successes and failures both.)

I hadn’t planned to dive into version control for a while longer, but this is enough of a motivation for me to dive in starting with the Codecademy “Learn Git” class.

This class has significantly less hand-holding than the last few Codecademy classes I took, and almost no repetition. It also doesn’t go into a reasons why you are doing what you are doing in a class. As a result, I felt this class would not be a good introduction for a raw beginner.

To successfully complete this class, the student needs to:

  • Be comfortable with a command line.
  • Already know why you’d want to use version control.
  • Navigate the in-class environment without instructions.

The last one was annoying. At one point in the class, the student is expected to open a file in the virtual work environment to be edited, but there was no instruction on how to do so.

The class worked perfectly for me – I could handle the above bullets, and the lack of repetition meant I was never bored. The lack of hand-holding meant I had to occasionally look up git commands on my own, or hunt around the UI of the work environment, but it wasn’t bad. I’m just not sure it’s good starting place for a coding beginner.

Setting aside the class material for now: the class implementation was interesting. I had expected the class learning environment to be merely a facade. Something that only accepts text input in the exact order required in the instructions. It turns out not to be the case – it appears to be a real (though restricted) instance of bash, connected to (a limited set of) git commands. I could issue any valid commands in the environment, and they would run!

Of course, if I veer off the course I couldn’t go to the next step, but I was impressed that they have created a sandbox for the student to play in.


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

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

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

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

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

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

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

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

Codecademy “Interactive Website” notes

I left the Codecademy “Interactive Website” class irritated.

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

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

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

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

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


Polyfill: for the gap between theory and reality

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

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

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

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

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

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

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

Codecademy “jQuery” notes

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

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

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

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

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

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


Codecademy “JavaScript” notes

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

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

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

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

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

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