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.
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.
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.
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.
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!
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.
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.
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:
- 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.
- It’s not a problem: Despite my paranoia, in practice just because the type system is flexible doesn’t mean it is abused.
- It’s exactly as bad as you think it is. We deal: Oh I hope it’s not this one.