Fusion 360 Foundational Concepts Tutorial

foundational-concepts-iconI went back into Autodesk’s Fusion 360 learning resources for a refresher and to set myself up to learn the Fusion 360 CAM modules. The last time I went through the tutorials, I had skipped the CAM functionality because I had no machine tools and were not likely to get time on anybody else’s machinery. Now that I might be able to access Tux-Lab fabrication machinery, I wanted to make sure I won’t break the machine from doing anything stupid in Fusion 360.

Before I got to CAM, though, the “Foundational Concepts” section caught my attention. I either didn’t see it the last time or it made no impression on me at the time. I went through the set of short videos and they were surprisingly informative. Most tutorials for Fusion 360 (and most other software packages in general) are happy to tell users how to accomplish their tasks. This is a slightly different twist – the foundation concepts talk about why Fusion 360 is the way it is. About how they tried to restructure a CAD package for the cloud-based future, about how they restructured the workflow to take advantage of today’s level of computation power at our fingertips, so on and so forth.

I come from a software engineering background and I’m all too aware of the fact that the end user typically has no idea what the software developer had intended as they built the piece of software. It can be argued that the end user doesn’t need to know anything about the intent if the software is sufficiently well-designed. But for something complex like a CAD package, I believe there is value in learning the motivation behind the design.

And even if the user doesn’t need to know, sometimes the user is curious and wants to know. I appreciate the Fusion 360 user education team for putting this information out there available for those who want to know.

Udemy: Product Design in Autodesk Fusion 360

udemylogoTalking with some people at the Hackaday meet taught me that there are some real fans of Autodesk Fusion 360. It was already on my to-do list to evaluate the software, but the enthusiasm pushed it to the foreground.

The first frustration is learning the software. All the resources I found are in the form of tutorial videos. I personally prefer information in written text format, but I’ll watch the videos if I have no alternatives. The videos on Autodesk’s own site is built using a Flash-based video system. I avoid Flash when I can, so as an alternative I chose the udemy.com course titled Product Design in Autodesk Fusion 360 from idea to prototype.

The quality of the course was uneven: different sections in the course were recorded by different instructors each with their own style. Fortunately, the introductory and starting sections about content creation were pretty good, teaching me Fusion 360 basics and then how to create a design. (Sections 1 through 3)

Where these sections fell short was teaching me how to fix problems. That is, beyond hitting Control+Z immediately after a mistake. I know I’ll change my mind on certain design decisions and need to adjust the file later. The class didn’t spend much time over the editing tools and I felt this gap would prove to be a hindrance to my productivity.

Section 4: Rendering, animation, and drawings were very perfunctory and barely enough to get me started. If I actually want to make use of these features, I’ll need to find additional education before I can be proficient.

Section 5: Computer Aided manufacturing(CAM) assumed the student is already familiar with machining and wanted an overview on how to use their existing knowledge inside the Fusion 360 UI. If the student didn’t already know CAM, the section would make no sense.

I think I picked up enough basics for me to start poking around on my own to fill in gaps in my knowledge, so it worked well enough as a brief overview. I’m just a bit disappointed because my expectations were higher.

“Learn Enough Command Line to Be Dangerous” notes

leclThe Ruby on Rails Tutorial was a great way for developers like me to get up and running with no prior Rails experience. However, it does require the reader to have some level of computer software skill so complete beginners could still get lost.

Acknowledging this, the author Michael Hartl has taken on the challenge of getting people up and running in the world of software development under the umbrella of his venture “Learn Enough Society” with a series of titles in the pattern of Learn Enough [X] to Be Dangerous.

I was curious about how his approach, so even though I’m not the target audience I spent some time looking it over.

His idea of starting from Ground Zero is the command line, which I agreed was a fair place to start. The reader is taken through the basics of navigating files and directories and is introduced to some basic command line utilities such as grep.

I applaud the focus on repeatedly prodding the reader to use the man command to learn more information. The manual pages displayed by man were written by programmers for programmers, which meant they tend to be densely packed with jargon difficult to pierce even for experienced users. But that’s where the information is, so one has to dive in to find answers. The tutorial tries to ease readers into man pages by teaching how to search for specific information so the reader is not overwhelmed trying to understand the full text. Baby steps.

Not being the target audience, I can’t judge how effective the tutorial is. I’m sure there are problems that didn’t stand out to me because I already knew the information, almost certainly because it didn’t stand out to the author either.

I did notice one example, though: The tutorial used the computer term argument without explanation. This might cause confusion: “I don’t want to argue with anybody, I just want to learn the command line!” (UPDATE: I e-mailed the author about this observation, and he has added explanations to the tutorial. Very cool.)

Rails Tutorial (Take 2)

RailsTutorial-cover-webWith all the fun and excitement around 3D printing, I’ve let my Ruby on Rails education lapse. I want to dive back in, but it’s been long enough that I felt I needed a review. Also, during my time away, the Ruby on Rails team released version 5, and Michael Hartl’s Ruby on Rails Tutorial was updated accordingly.

Independent of the Rails 5 updates, it was well worth my time to go through the book again. On second run, I understood some things that didn’t make sense before. It was also good to look at the first do-nothing “hello app” and the second automated-scaffold “toy app” with a little more Rails knowledge under my belt. The book is structured so the beginner reader didn’t have to understand the mechanics of the hello or toy apps, but readers with a bit of understanding will get something out of it.

The release notes for the update mentioned that a few sections were rearranged for better pacing and structure, and added more exercises for readers to check their progress. Both are incremental improvements that I appreciated but neither were especially earth-shattering.

Action Cable, one of the big signature feature of Rails 5, was not rolled into the book. Hartl is handling that in a separate tutorial Learn Enough Action Cable to be Dangerous which I will go through at some point in the near future.

Towards the end of the book, Hartl introduced an optional advanced concept: using Amazon Web Services to store user image uploads. I skipped that section the first time through, and decided to dive into it this time.

I quickly found myself in a deep rabbit hole. Amazon Web Services has many moving parts designed for a wide range of audiences and it’s a challenge to get started without being overwhelmed.

Which is where I am now. Lots more exploration ahead!

“Ruby on Rails Tutorial” notes

RailsTutorial-cover-webTowards the end of the Getting Started with Rails guide, there was a link to the Ruby on Rails Tutorial. I had missed it the first time I went through the Getting Started guide, but when I reviewed the guide a second time (things made a lot more sense) I noticed and decided to check it out.

I’m very glad that I did!

For the most part, this book (available as paper edition, but the author had made it freely readable online on the web site) was exactly what I had hoped to find for Ruby on Rails. The book went through the process of making a Rails app three times, in exactly the progression I wanted:

First pass: A simple “hello world” that does nothing much but lets the student experience all the standard overhead around creating and deploying a Rails app. It’s barely a Rails lesson at all: it’s really a lesson for learning the surrounding infrastructure before digging into the meat of learning Rails.

Second pass: A simple “toy app” that does a lot… but the student is rushed through without understanding what’s going on behind the scene. It’s really a demonstration of what’s possible via Rails helpers & scaffolding and less about learning Rails. It reminds me of what the Codecademy Ruby on Rails “class” was like. A lot of incomprehensible fancy flash. However, unlike Codecademy which left me asking “now what?” Rails Tutorial follows up.

Third pass: Over 80% of the book is spent building the “sample app.” Starting from a site that can serve a few static pages and grows, bit by bit, into a mini clone of Twitter. It had creation and maintenance of user accounts, authentication, posting 140-character messages, following & un-following users, all the core bits we associate with Twitter. (Which, the author asserted, was also originally built using Ruby on Rails.)

The Codecademy Rails class left me confused and feeling like I’ve wasted my time. (About a day.)

The Rails Guides left me with a basic level of comprehension of what goes on in a Rails app. My time (About half a week) is well spent, but I didn’t feel like I could build anything on my own yet.

After the Ruby on Rails Tutorial (which took me over a week) I feel like I have all the basic tools I need to start playing in the Rails playground. I feel like I have an idea how to get started, how to experiment, understand what the experiment does behind the scenes, and debug whatever goes wrong while I experiment.

And with that, it’s time to practice using my new tools: Let’s build something!

Codecademy “Learn Sass” notes

SasslogoWhile learning Ruby on Rails, one of the things I put on my “look into this later” list was Sass. I knew it was related to CSS but didn’t know the details, I just noticed when the Rails generator created a controller, it created a .scss file under the stylesheets directory.

So when I received email from Codecademy notifying me that they have a new class on Sass… the “look into this later” became “let’s look into it now”.

Unlike Ruby on Rails, Sass is not a huge complicated system. It solves a fairly specific set of problems typical of CSS growing unwieldy as it grows with a project. It introduces some very nice concepts to keep CSS information organized. After banging my head on lots of walls with Ruby on Rails, it is refreshing to tackle a smaller-scope project and be able to understand what’s going on. The Codecademy format is well suited to teach a smaller scoped concept like Sass.

I was also mildly amused to learn that Sass is apparently written in Ruby. I don’t think it particularly matters what the implementation was, but it’s amusing to me to see Ruby applied in an entirely different way from Rails. The bonus is that, if I should try to debug or extend Sass myself, I wouldn’t be starting from scratch looking over its source code.

Being a fresh course, the Codecademy class had a few minor problems that still need to get ironed out. The flashcard example was supposed to flip on mouse hover… it never did anything for me. Too bad, because I think the effect would have been interesting.

I haven’t gotten far enough with Rails to think about making my web app pretty, but when I do, I know how to keep my style sheets manageable with Sass.

Codecademy PHP notes

elephpant

I just zipped through the PHP course in the Codecademy “Language Skills” section.

As is typical of beginner-friendly Codecademy language skill courses, it starts from the beginning with variables, flow control, etc. If the student is already aware of such basic concepts, this can get very tiresome.

This PHP class flew through basic topics. This is great for experienced programmers already familiar with the concepts and just wanted to see how PHP differs from the other languages. The downside is that, if a student is truly a beginner, they wouldn’t have received much help and would probably be lost.

I thought the class would get into more difficult topics, or areas specific to PHP and web development and… it didn’t. After covering the basics of declaring classes and class inheritance, the class stops. Even though the introduction mentioned that PHP web apps can contact databases and other server-side resources, this class didn’t cover any of the meat-and-potato of writing web applications with PHP.

Overall, the class is a superficial skimming of the surface for PHP. Good for somebody who just wants to see a quick view of PHP basics, and I appreciated it for that, but bad for somebody who actually wants to figure out how to do useful things with PHP.

I’ll have to look elsewhere for that.

Loopiness

Unrelated to the skimpy curriculum is a problem with the interactive learning development environment. In other Codecademy courses, the student writes the code and presses a button for it to be executed and evaluated. In this class, evaluation is constantly happening before the button is pressed. The upside is that feedback for errors are instant, no waiting until the end. The downside is that it’s easy to make it go into an infinite loop.

Example: If this was the goal:

$abc = 1;

while ($abc < 10)

Just before we type “<10” the state would be:

$abc = 1;

while ($abc)

Which is an infinite loop that sends the evaluation code spinning uselessly. So when the student actually presses the button later, the gear just spins.

Workaround: copy the newly-typed code into the clipboard, hit refresh on the browser to reset and reload the page, then paste the code in.

Codecademy “Learn Ruby on Rails” notes

Codecademy RailsThis class rushes through the basics of setting up a Rails app without explaining the bulk of what happened. This is not itself a bad thing: it let me see that Rails has a large surface area of machinery, pre-built components that can be put to work quickly.

But the majority of the course is of the “type this and look at the results” without much explanation of what I just typed and why. Example: After writing a few lines of Ruby code, the student is instructed to go into the command prompt and type “rake db:migrate” followed by “rake db:seed” before instructed to marvel at the result of the magic.

What did that do? The class didn’t really say beyond “made database”. Afterwards I went back and dig into the documentation to come up with a guess at what’s going on:

The lines of code turned out to be a way to define schema for a database table. After the schema is updated, the table itself is migrated from the previous schema to the new schema. In this case there is no existing table, so ‘migrate’ creates a new empty one. Then “db:seed” inserts some information pre-generated by the Codecademy course author into the just-created database so it is not empty.

And “rake”, which I had inferred to be some kind of database tool, is actually a general task running tool like “make” for C. I got the wrong impression since all I saw were database tasks.

That’s one example, there were many others. With this lack of explanation I’m sure I have quite a few misconceived notions on how Rails apps are built. Heck, what I described above with ‘db:migrate’ etc. might be wrong! I’ll learn my errors in due course.

If it was titled “Interactive demo of Ruby on Rails” I would be satisfied with what I got, but I don’t think it deserves the title “Learn Ruby on Rails” when actual learning has been left as an exercise for the student.

Codecademy “Learn Ruby” notes

Upside: Despite being the last in the list of language skill courses, the Codecademy “Learn Ruby” course does not assume the student knows anything about programming. It will start at the very beginning with variables, functions, flow control, etc.

Downside: If you already know basic programming concepts, the first few sections will be a complete bore as it teaches the concept of variables, function, flow control, etc. The only reason to put up with any of it is to learn the Ruby syntax for these basic concepts.

Fortunately, the class doesn’t take terribly long before getting into the interesting stuff. Like how Ruby’s basic data types have a lot more tools attached to them than other languages I’ve seen. All kinds of ways to traverse an array. The crazy number of things built in for various string manipulation. Things that, in other languages, a programmer would have to get from utility libraries outside of the language base.

That said, I’m not sure I see how these differences explain the enthusiasm I read from some Ruby champions. At the basic level covered in the Codecademy class, it doesn’t seem significantly different from any of the other object-oriented programming languages out there. Yes, it has a lot of built-in capabilities for common operations, but is that really enough to get people excited?

I haven’t seen the debugging facilities (or lack thereof) for Ruby. I’m also wary of the reputation Ruby has for being difficult to get up and running on a computer. Inside the Codecademy learning environment, it’s already set up. Getting it up and running on your own has been repeatedly warned as a nontrivial process.

No matter, I wasn’t learning Ruby for the sake of learning a new language. I was learning it as a foundation to build on learning a non-basic-library: Ruby on Rails.

That’s next.

Back to Server-Side Education

It’s fun trying to bring an old DOS game into the web world, and now I’m getting to the point where I think it makes sense to do part of the work on the server side.

I went into some Node.js classes earlier, mostly because I wanted to learn about NPM. But Node.js isn’t the right tool for every job. Specifically, it isn’t a tool I can use if I want to host with shared hosting services – the power of Node.js conflicts with the constraints to make sure everybody plays nice on a shared web host server. (Specifically those on Dreamhost, where I have my domains registered.)

So… time to learn something that I can use to put on a Dreamhost shared web server and visible to the world. The bullet point on their sales pitch says “Perl, Python, and Rails”. I already know I don’t particularly care for Perl. It is a very terse and concise language that I find to be unnecessarily difficult to debug. Python is supposed to be a more human-readable language, and I don’t know much about Rails at all.

In the spirit of adventure, time to roll the Codecademy courses on Ruby, followed by Rails, to see if I can use it for the server-side work of my little personal project. Either I learn how to do what I want, or I learn enough about Ruby & Rails to be able to articulate how it does not suit me.

Upsetting the NPM apple cart

Decades-old words of wisdom from a computer science pioneer, proven true once again.

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

Leslie Lamport

In a coincidence of perfect timing, my education of NPM yesterday came just in time for me to understand the left-pad incident. The short version is simple enough to understand: unhappy programmer took his ball and went home, causing a lot of other people grief in the process. The bigger picture, though, needed a bit more knowledge to understand.

While going through the NodeSchool.io NPM workshop I had noticed a few things. The workshop used a dummy placeholder registry but there was really no technical or policy reason why every Jane and Jack can’t run the same lesson against the global registry. Up to and including the fact that they can clean up (un-publish) their NPM package when the workshop is over.

I found that fact curious. Such open accessibility felt fragile and I was wondering about the mechanisms to make sure the mechanism is fortified against accidents or abuse. It wouldn’t be something covered in a workshop, so I thought I’d see more details of this protection elsewhere.

Nope, I was wrong.

The left-pad story proved that there wasn’t any mechanism in place at all. A hilariously trivial package was yanked, causing many houses of cards to fall down.

For all the wonders of NPM, there are downsides that had its share of critics. This incident kicked the criticism into high gear. The NPM registry owner received a lot of fire from all sides and have pledged to update their procedure to avoid a repeat in the future. But I’m not sure that’s enough for the famously anti-authoritarian OSS purists. For every “conflict resolution policy” there will be some who see “ruling with an iron fist.”

 

NodeSchool “How to npm” notes

The lesson of the day is “You get what you pay for.”

NodeSchool.io’s workshop to teach NPM (Node.js Package Manager) is titled “How to npm.”  It has the intention of letting students create a package, set up the proper dependency links, publish it, then publish it again to practice sending out updates. Since it would be bad to pollute the global package registry with a bunch of dummy student test packages, the workshop steps publish against a practice registry running locally instead of the real thing.

As of today, there’s a problem with the practice registry. It can accept updates to packages and track the version numbers, but the portion that tracks labels for these versions (“dist-tag” in NPM lingo) is broken and halts the lesson flow with a HTTP 404 error.

The symptoms match a bug in the workshop that was acknowledged, analyzed, and purportedly fixed. However, the fix is incomplete because some people are still seeing the same error in the updated version of the workshop.

Including myself!

I tried to look at the code behind the lesson and try to see if I can come up with a fix for the bug, maybe this can be my first open source contribution! But alas, I’m not yet good enough with Node.js programming to understand what’s going wrong.

Fortunately I’ve already learned a few useful things before I hit this roadblock. I believe all the material useful to somebody consuming packages has been covered. And I don’t expect to publish any packages myself soon.

But if I do, I’ll come back to this workshop again before I commit. Maybe it’ll be fixed by then.

NodeSchool “learnyounode” notes

After making my first pass through the jQuery Learning Center (I’m sure I’ll be back again) I moved on to another free learning resource: NodeSchool is a collection of resources for learning Node.js, including some self-training tutorials.

At the top of the page they point newcomers to the workshop titled “LearnYouNode”. This workshop has the subtitle “Learn You The Node.js For Much Win!” This raised my eyebrows. It wasn’t immediately obvious that the broken English was a running gag of some sort. I don’t know what it is… maybe LOLcat?

Not knowing it was a gag, I thought maybe the tutorial were written by people for whom English was not their primary language. I was worried I would get stuck trying to figure out if I’m misunderstanding broken English or misunderstanding Node.js.

Fortunately, it only took a paragraph of two of tutorial instructions to make it clear the lessons are not, in fact, broken English. Which was very good news because there was very little hand-holding. The audience is presumed to be competent developers off the bat. It actually assumed JavaScript skill level a bit higher than what I have! Fortunately close enough I could get through with some educational web searches.

The overview workshop sped me through some Node.js basics. Even better: After I successfully completed each challenge, it will show me the official answer which inevitably differed from my solution. I learned a lot from the answer key source code which I hope will help my JavaScript skills going forward.

One of the things LearnYouNode introduced me to is NPM. The Node.js Package Manager came up repeatedly in many of my previous explorations, and I knew I had to get a handle on it soon. I’ve only got a taste so far, and there’s a whole other workshop dedicated to the topic. I think that’s a good place to go next.

Codecademy “Learn the Command Line” notes

This course would be more accurately titled “Learn Bash” though the beginner audience wouldn’t necessarily understand that title. Most of it is broadly applicable to the various command line shells used in Unix & relatives, but some parts are specific to Bash. It’s fine: most Linux distributions default to Bash, and it’s close enough to the command line of the Mach+BSD blend that underlies modern MacOS.

Neither Microsoft’s legacy DOS command line nor the newer PowerShell are mentioned.

The course is a very brief overview of the basics.

  • File system hierarchy traversal
  • File manipulation and management
  • Some of the common command line tools like “grep” and “cat”
  • Trivial Bash environment customization via .bash_profile

The organization of the class is a little different. Most of Codecademy are set up to first teach a concept then ask the student to try it themselves in the class environment. The command line class is the opposite: it asks the student to type in things before explaining what just happened.

I am comfortable learning by hands-on tinkering. After I followed the instructions and typed in stuff like a trained monkey, I stopped and tried to guess what I just did before reading the answer. I believe retain the information better if I successfully reason out the logic during this guessing period.

But it doesn’t fit in the standard Codecademy template so it comes across as a little odd. I personally prefer it but I can understand if some people would not.

The other “cloud development”

When I set out on this adventure, I knew I wanted to eventually cover the basics of the major cloud services. Write some sample services to run on Amazon Web Services, Microsoft Azure, Google cloud services, etc.

I was surprised to stumble into an entirely different meaning of “cloud development”: writing code in a browser. I had seen the educational coding playgrounds of Codecademy, and I had seen small trial tools like JSFiddle, but I had no idea that was just the tip of the iceberg and things can get much fancier.

I had started a project to practice my newly-learned jQuery skills. Just with a text editor on my computer and running the HTML straight off the file system. As soon as I learned of these web-based development environments I wanted to try it out by moving my project over.

The first I tried was Codenvy, whose whitepapers are quite grandiose in what it offers for improving developer productivity. Unfortunately the kind of development Codenvy supports aren’t the kind of things I know anything about today. But I’ll revisit in a few weeks to check again.

The second I tried was Cloud 9, which does support simple HTML+CSS+JS projects like what I wanted to do. Working in Cloud 9 gave me some tools for static analysis and serving my file off a real web server. It also integrates into Github preserving my source control workflow.

After a JavaScript project of around 300 lines of code, I can comfortably say I’m quite impressed. In the areas of development-time tooling and integration experience, it far exceeded my expectations. However, there was an area of disappointment: the debugging experience was either hard to find or just wasn’t there at all.

When my little project goes awry, I resorted to loading up the project in a separate browser window and using the web browser debugger. This is on par with the simpler tools like JSFiddle and JSBin. I had hoped for better.

I’m cautiously optimistic I’ll find a tool with better debugging experience as I continue to explore.

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.

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.

 

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.

Codecademy “HTML & CSS” notes

UPDATE: Codecademy has revamped their introductory “HTML & CSS” class. The notes below reflect the old version which is no longer available.

Just finished the Codecademy “HTML & CSS” class. It helps me get a feel of how Codecademy lessons are organized. There is a lot of overlap in material with the “Make a Website” class I finished earlier, but their structure is different.

“Make a Website” is focused on the goal of the AirBnB-like page they advertised up front, and the steps are laid out to reach that goal. While it starts with basic HTML concepts, it doesn’t go into HTML areas not relevant to the goal. It’s also happy to deviate from basic HTML in service of the goal, using the Bootstrap framework instead of getting mired in the complexities of handcrafting HTML layout.

“HTML & CSS” is less focused on the goal (though it does have mini-goals in each of the units) and so has fuller coverage of basic concepts. On the CSS side, I liked the fact it gets into more gritty details of layout, but far short of what I can do with Bootstrap. There’s still a sizable gap in my understanding before I can explain how Bootstrap does the layout magic it does with just CSS.

There’s a lot more repetition in the “HTML & CSS” class. Since it was mostly review for me, the repetition got very tiresome. I’ll keep this in mind when we get into things new to me, perhaps I’ll appreciate the repetition for new concepts.