Idiot Learns to Code Vol III: 5 Things Codecademy doesn’t teach you about Javascript

(Disclaimer: I’m sure I’ll make a lot of errors in how I describe basic computer science  and code-specific terminology. That’s the “Idiot” part coming through. This is all written in the language of my understanding. I hope it’s yours, too. I love it when people correct me in the comments or via social media. Take everything you read here with a grain of salt the size of an asteroid the size of Texas, which is of course 268,820 sq miles.)

A list post! Hooray!

It was only a matter of time before I created some good old-fashioned clickbait.

Let me start by saying I love Codecademy. I couldn’t have gotten to the level I’m at now without their introductory Javascript course. But as any good web developer will tell you, the best way to learn is by actually building something.

I’m getting there, slowly but surely. My biggest recommendation for Codecademy users is to use it as jumping off point; get the basics under your fingers, then go out and find a decent book dedicated to the language you just got a primer on. For me, that’s Javascript. So without further ado, the most important things I learned about JS after Codecademy.

1: DOM Structure

Theoretically, if you’re teaching yourself Javascript, you already know a little bit of HTML and CSS. I’ve always felt that beginning devs ought to first learn HTML–the building block of the internet–then CSS which styles HTML, then Javascript, which handles data and dictates how CSS and HTML objects are animated or interact client side.

So after I finished Codecademy’s JS course, I wanted to know how it actually functioned in the browser. But there’s nothing in Codecademy’s JS introduction that tells you how to implement Javascript in your webpages. The go-to “print” command in their lessons is “console.log()”, which does just that: Logs to the console, where Codecademy’s preview takes place. In practical terms this works but not in functional terms. The actual display of text and other data output on web pages is done with HTML, which is manipulated by Javascript.

Enter the DOM, or Document Object Model. It’s a convention that specifies how web documents are accessed and modified (usually with JS). Think of it as a hierarchy where the HTML elements are accessed in the order that they’re organized and nested:

Picture 5This graphic (from W3C) shows part of the “DOM Tree”. If you’ve ever used the “Inspect Element” function of your browser, you’ve probably seen a js function called “document.getElementById()”. It’s probably the most important function for Javascript beginners. It gives direction to functions so they get valid data and/or input, moving down the branches of the DOM tree to retrieve information.

So, you write some Javascript in the <head> of your HTML document (another convention you ought to be aware of). Here’s a stupidly easy example of Javascript working with HTML:

<!DOCTYPE html>
<html lang=”en”>
        <meta charset=”utf-8″>
    <link type = “text/css” rel = “stylesheet” href = “Doop.css”/>
        <title> Hello </title>
        <script type = “text/javascript”>
        function greeting() {
            var text = “hello!”;
            var output = document.getElementById(“output”);
            output.innerHTML = text;
        }        </script>
    <h1> Derpy derp derp </h1> /*I title a lot of things “derp” or some variant. It’s my version of “Lorem Ipsum */
        <button type = “button”
                onclick = “greeting()”>
                click me
    <div id = “output”>

So here’s what I did in terms of things Codecademy doesn’t teach:

  • Put some Javascript in our HTML page with the <script> tag. The browser sees <script type = “text/javascript”> and processes what’s in between the tags as a Javascript element. Once it sees </script>, it returns to processing the HTML with respect.
  • In this case, we’ve got a simple function called “greeting()” that outputs “hello” when you click a button. How do we get there? DOM scripting, of course! That little built-in function, “document.getElementById(“output”)” tells the browser to scan the HTML document for an id called “output” contained in a <div> tag. We’re first accessing, then manipulating the DOM.
  • As the browser interprets the page, it interprets our button element which contains instructions to execute our “greeting()” function at “onclick”. When that happens, it triggers the function to access our <div id = “output”> and do…something. We use another simple function, “.innerHTML”, to display the text “hello!”. Through the DOM, we’re accessing the <div> and altering its HTML content through Javascript, taking empty space and putting a greeting tied to the user’s input of clicking a button. Here’s what it looks like:
    Picture 7

So, in so many words, that’s how to get a Javascript working on the page and outside of the Codecademy IDE. Not only that, but you can sort of see the value of js for processing user input.


No, JSON is not the weird spelling of some alt-dude’s stupid band. JSON stands for JavaScript Object Notation, a language-independent data format used by a lot of APIs. It follows the basic method of how objects are notated in Javascript (maybe that’s why they call it Javascript Object Notation! Neat!)

An example:

name: “Frank”,
favoriteSandwich: “Too Much Tunafish” }

Simple enough, but websites can build enormous databases with this simple tool. I first encountered JSON when I got a hair-brained scheme to build a widget for Discogs, an online database that allows vinyl junkies and music collectors of any physical medium to create a digital catalog of their collections. Their API is JSON-based, so you can access objects for artists, releases, master releases, tracklists, rawk-hairstyles(?) and infinity. A handy tool for someone looking to expand their collection or share it with friends, families and jealous fellow-collectors. But I digress.

JSON isn’t mentioned in Codecademy’s Javascript course, but might be referenced in some of the API tutorials that I haven’t browsed yet. But since Javascript’s most powerful attribute is it’s ability to access data and convert it into an HTML-usable format, you may want to take the time to learn a bit more about how JSON functions in the real world. The real world being the internet.


AJAX is another fun abbreviation that sounds scarier than it actually is: Asynchronous Javascript and XML (XML being a script-based data storage method). With Asynchronous I/O, web applications can function without having to contionously refresh a page. For example, when I listen to 89.3 The Current’s web stream (like the good hipster I am), they have AJAX built into the web tool that allows the stream to continue playing while changing the information it displays, such as the current track and album art. The XML document receives information in real time about what song is on the air, the artist’s name and so on.  Meanwhile, Javascript has instructions on when to access the XML document and updates the page accordingly–without altering the navigation menu on the right hand side:

Picture 8Picture 9




To be honest, I haven’t spent a lot of time working with AJAX or its syntax yet (You saw my example program…), but it’s important to know that AJAX exists for when you start building more complex apps. Ain’t data fun?

4: Node.js and other JS branches

In the most dumbed-down explanation possible, Node.js is a port built in C that allows Javascript to run as a server-side language.


(Remember the difference between client-side/server-side?)

Node can make server requests and is event-oriented. I’ll get to events in my next Dum-Dum summary of computer science terms.

For now, don’t expect to truly understand what Node is before you have a decent understanding of what Javascript and backend languages do. I certainly don’t. The most important lesson to glean from Node.js is how dynamic Javascript is as a language. It’s constantly in a state of branching and development. That’s something that blew my mind when I began to learn how to code; not only are there a virtually infinite number of programming languages, but they’re constantly changing and morphing into crazy new languages that can do more and more powerful things. Node is still in its infancy, but developers appear to be excited for its potential, and it’s good to keep developer developments on your radar as they develop.


For other branches, check out CoffeeScript, Dart and ActionScript. Or don’t. I’m not your dad.

5: jQuery

I know, I know, Codecademy has a chapter devoted to jQuery. That’s why I have it as the final item on the list; they don’t integrate it into the Javascript chapter. I’d rather have it as part of the Javascript course material considering how a lot of the cool stuff people want to do with JS is handled by jQuery. That includes animating text on events like mouseovers, showing and hiding divs and so on.

jQuery is a “write less, do more” Javascript library. I think of it (perhaps incorrectly?) as having an analogous relationship to HTML and CSS. CSS styles HTML using built in elements and guides, and jQuery uses Javascript methods to guide JS functionality; CSS tells HTML what to do, just as jQuery tells Javascript (and by extension, CSS & HTML) what to do.

Codecademy has a decent intro to jQuery as well, but as with everything, supplement your knowledge with books and more online resources.

And remember, Knowledge is Power!


IDIOT LEARNS TO CODE VOL. II: Update, CS Glossary Part I

I’m very glad I chose to write this post because I got a lot of information clarifying points I wasn’t clear on. Remember that software engineer friend I mentioned in my first blog post? That’s Ben Hansen, and he sent me a follow up message on facebook which turned into a productive conversation. I figured it was worth sharing. He also brought me up to speed with procedural programming, which is probably worthy of its own definition in a follow up post.

Ben Hansen has had the same facebook profile picture since 2008, and he's one of my favorite people.

Ben Hansen has had the same facebook profile picture since 2008, and he’s one of my favorite people.

Read our conversation below (full of punctuation glitches, spelling and two swear words. Hooray!

Ben Hansen:

Nice post. Your definition of OOP is pretty accurate, but should also mention that (in most languages) objects also know how to interact with you and other objects via functions defined specifically for them. Like, I have a dog object and a cat object. The dog knows bark() internally and returns ‘woof’. All objects of type dog know this function. Cats know mewl() and return ‘meow’. All cats know this. They do not, however, know or have access to the other species functions.

Some languages don’t have this feature, but as far as I know that means that they aren’t truly oop

Frank Merchlewitz:

are you describing inheritance?

seems like in this case the class is animal

objects are species?

so the cat object inherits basic functions of animal, but has its own specific methods, properties, as does dog

that’s called inheritance right? That’s a prototype command in js


No. That is a concept related to what I’m talking about though. It follows from what I was getting at. But what I am saying is that objects are both data(properties/variables) and actions. Basically, saying that an object is a collection of data is incomplete.

But yeah. Following on my example you could create a parent class of object called animal. If we are looking at inheritance properly, then we alter the example a bit. Instead of bark() and mewl() the class animal would have a function called speak(). Both dog and cat would inherit method speak, but would overwrite the functionality to their specific output (woof or meow).

This let’s you do some cool things. For instance, if we had dogs and cats who are children of the common class animal, we could put them all in one array of type animal. Let’s assume that we didn’t overwrite a common function from animal called speak() but instead kept cat and dog with the functions meow() and bark(). To have an object in the animal array say it’s thing, we have to find what type it is first, then tell the program that type, then we can perform it’s function. But if we inherit speak() and and overwrite, then we can just tell the object in the animal array to speak() and it will perform the action specific to its type.

I don’t know if that made any sense.


nah, it’s good. Yeah, I know objects can contain actions (methods?), probably was just considering that a form of data, which it isn’t, really. Somewhere I read that objects are nouns, methods are verbs, and that didn’t sound right to me based on what I already know


That isn’t necessarily wrong but ‘pure oop’ is decentralized code. So everything takes care of its own shit and you tell them when to do their stuff. Procedural programming is centralized, where you micromanage everything. That phrase is ambiguously in between there, because realistically, you will make bunch of objects but still need to micromanage some things with global methods.


Could you explain that a little more? What do you mean by micromanage? And when you say everything takes care of it’s own shit, is that largely accomplished by concepts like inheritance and global methods?

(Also, would you hate it if I published this convo as a micro-blog/follow-up post?)


A big part of object oriented programming is the concept of encapsulation. This is when you keep data and functionality restricted. So if I want a cat to be able to scratch() as well as speak() , but a dog shouldn’t be able to do that I will define it in the cat object in addition to the inherited methods of animal. I have successfully encapsulated scratch(). Similarly data that is stored in objects is encapsulated. So when I say everything handles itself, I mean that objects don’t draw from a giant public library of functions. They only have access to one’s relevant to themselves.

Micromanagement (not a real CS term) would be putting the scratch function in a global setting (main function) and telling the cat to scratch but making sure the dog never did it.

In the first example the dog literally cannot know how to scratch. In the second, it could know but you won’t let it.

Also, obligatory picture of us from high school prom…



BOOM. For the record, neither of the men pictured were my date.


Idiot Learns to Code Vol. II: Computer Science Glossary (Crazy Abridged, Part I)

^ This dum-dum hasn't posted anything in a month!

^ This dum-dum hasn’t posted anything in a month!

[DISCLAIMER: I am an idiot. The following is a personal exercise that I’m sharing about my attempt to understand the dense field of computer science. I’m making progress. Kind of. I do not vouch for the accuracy of anything that I write on this subject. If this were a blog about sandwiches, this disclaimer would not exist, for I have a profound understanding of the art of the sandwich. I’m a sandwich artist if you will. Read on if you want to share my epic(?) journey. ]

Long time no blog! Coding is a lot like exercise, in that I’ve done neither for about two weeks.

And I suppose it’s difficult to gain progress in both coding and fitness without consistent effort–even just 15 minutes a day. So that’s what I’ve been doing during the week, slowly but surely (with programming, not exercising.) I’m done with my HTML/CSS refresher and set to delve deeper into python.


Even though I’ve been busy making videos for the past couple of weeks, I’ve kept up with my computer science research, taking notes on some terms that kept popping up that were out of my depth. For now, I’ll ignore the easy stuff that Codecademy covers well–conditionals, loops, the various data types.

The following are terms that you may have heard before but don’t quite have a grasp on. In keeping with the format of this blog, neither do I, but here goes nothing:

Object-Oriented Programming (OOP)

OK, this is something that everyone needs to have a basic understanding of, and you may have one already. OOP is programming oriented around–wait for it–objects.

What’s an object?

It’s easier to think about objects by what they’re made up of–a combination of variables, functions, properties, all sorts of data. These data are stored within the object in the form of keys and values (In JavaScript, this looks like ‘var obj: {key: value}’). Let’s say my cup of coffee is an object. I’ll write it out here in object literal notation for js.

var coffee { temperature: 160, color: black, sugar: “Papa didn’t raise no sissies.” };

It’s like data, but, y’know, more so.


OOP revolves around the construction/structure and interaction of different objects to build a piece of software.

Module (Modular Programming)

A fancy term for the simple elements–functions or subroutines, classes, variables–that build a much more complex program. When we talk about modular programming, we’re talking about the way different pieces interact, how code elements are interdependent.

Many applications are built on modular programming with a single module file containing class and function definitions that are accessed or imported by other files. It’s a convenient way to keep the nitty-gritty details of code in one easy-to-find place when building out something to scale.

Client-Side Scripting

Scripting executed in a user’s web browser. HTML/CSS and Javascript are the classic examples. The computing is done on your end. I usually think about this in relational terms to front-end development; I see the information on my end, interact with it, and provide my own information which is processed on the back end. Which brings us to…

Server-Side Scripting

If client-side is closer to front-end, server-side is the back-end. This is computation performed on a host server. Think about it logically; if all the data you saw on your computer screen was processed on your end, load times would be impossibly long. But a server can only process so much information at a given time (Remember Some data is stored exclusively on these servers and presented client-side only when it is being accessed.

No idea what happened to this woman...

No idea what happened to this woman…

This sounds simple (maybe even patronizing!), but again, that’s the purpose of this blog. Examples of server-side scripting include Java, C++, ASP.NET, and all of the more complex languages that build highly functional, cool apps/software.

Application Programming Interface (API)

Odds are you’re using several right now. APIs are the stuff that cool web functionality is built on. Technically speaking, they’re a set of programming instructions that dictate how users can access and utilize a web tool. When software companies release public APIs, it allows developers to build tools and applications–Twitter, Facebook, Amazon. Streaming a Netflix video on your DVD player, using your mobile device to pay for concert tickets–simple enough, but it requires different devices with potentially different data structures to work together.

Mega tl;dr

APIs allow software to talk to other software seamlessly, without the user noticing.

Integrated Development Environment (IDE)

Also called an Interactive Development Environment. IDEs are a mixed bag, one-stop-shop for everything you need to write code. Most feature an editor, compiler/interpreter, debugger and a GUI builder (GUI is Graphical User Interface…Does this need a definition?). IDEs let you get a look at your code in real time as you write it, plus troubleshoot problems as you go.

“What You See Is What You Get” (WYSIWYG)

WYSIWYG looks like a Welsh swear word. To some programmers, it is (…a swear word. Not necessarily Welsh).


Think of WYSIWYG as writing code in reverse. Adobe’s Dreamweaver gets a lot of flak from the dev community; it allows you to design a web page and creates the code after the fact, fielding it out based on the design. Seems simple enough, and it works for a brave few. But it makes a mess of the code, often resulting in something referred to as “tag soup”–improperly nested HTML tags and jumbled, overly-complex code.

The appeal of WYSIWYG builders is clear to the uninitiated, but it can create a lot of problems. I’ve found that Dreamweaver works well for me as an IDE, growing code from the root up and being able to view it in split screen mode as I build. But I imagine this gets more difficult as projects scale.


I threw this one on here because it was really bugging me–just kept seeing it without understanding what it was. I’m least confident in my explanation of this term. Hold on tight.

A stack is a type of data structure that holds elements in a particular order. Those elements are accessed LIFO, an acronym for “Last-In-First-Out.” Stack structure is important in understanding a program’s workflow, how it sees, accesses and uses data.

A good example is the undo command (with which I am all too familiar). Type a sentence. Copy-paste something. Whoops, didn’t mean to, undo. The copy-paste action–stored as the most recent function executed–is removed (or “popped”) from the top of the stack. If you select undo again, your typed sentence is deleted, emptying the stack (or creating a new stack in the redo action menu).


I’ll follow this post next week with a few more comp-sci terms to butcher. Leave any questions or comments below, or on Facebook/Twitter. I’d also like to know what topics you think I should cover.
Drop me a line!


Franky “Flapjacks” Merchlewitz


Idiot Learns To Code Vol. 1

(Disclaimer: I’m sure I’ll make a lot of errors in how I describe basic computer/code-related terminology. That’s the “Idiot” part coming through. This is all written in the language of my understanding. I hope it’s yours, too.)

Over winter break, I made a decision: In the coming months, I would learn everything I needed to know about being a web developer. The biggest obstacle? My own ignorance.

During high school I took a few programming courses (Perl, Java and Robotics). My crowning achievement was making a lego-bot spin in a circle while playing John Williams’ “Imperial March”. But I was easily discouraged. My coding frustration generally amounted to giving up on projects all together, or turning in work that my friends shared with me. One of those friends is now a full-time software engineer at a company in the Twin Cities.

I attribute my ignorance to a fear of failure. That fear is definitely still there. And back-end languages are still incredibly intimidating to me. Sometimes I think if I had taken an HTML/CSS course first in high school, I would have stuck with it. In fact, what prompted my newfound interest in web development was Chris Snider’s web design course–taken far too late into my college career. I was fascinated with how excited I was to code, to solve problems.

With a busy schedule the following semester, I let it slip. A lot of the basic info fell out of my brain, and now I’m trying to get it back. Today I finished my first Codecademy course: Javascript.

Big Money


Codecademy, though, comes with it’s own set of problems. It holds your hand, and the Javascript function left out virtually everything related to how it works in web development. Not the best, but it’s a start.

It’s like Jenga. But, y’know, harder.

My personal site and the two Drake ones I manage are built on WordPress. That’s fine; it’s a simple-to-use CMS that looks pretty nice, and it’s hard to screw up. But if I do want to edit my sites–to truly customize fields, divisions, widgets–I have to delve deep into the PHP code that WordPress themes are built on. All of this server-side business involves a lot of conversation between different files, functions and the WordPress API itself. Then add in plug-ins, different themes and the constant updates from everything involved. If I make a change somewhere in the code–eliminate a function, a variable placement, re-size the footer or navigation menus–it brings my jenga tower crashing to the ground. Without an inherent knowledge or ability to understand someone else’s development style or the parameters they’re working in, I can’t make something the way I want.

That sucks. It’s almost harder *not* to code.

How to not use WordPress

So, my modest goal? To build a personal website from the ground up with the same functionality as my current one. That includes a simple CMS, portfolio style navigation and a blogroll. (I am, by the way, fully aware of the irony of using WordPress to publish my goal to move away from using WordPress.)

I will also build one simple application that let’s me do something else I love–music, video, cooking–more simply. Languages I plan to learn:

  • HTML/CSS (refresher course)
  • Python
  • PHP
  • jQuery

Resources I’ll be using:

  • Codecademy (not the best, but it provides the fundamentals)
  • Github (I never said I wouldn’t use open source!)
  • W3Schools
  • The  good people of the DSM startup community. Everyone has been so kind to me since I stumbled into the scene via amazing gigs with Silicon Prairie News and the Welch Avenue Show.

Why, you idiot?

I hope this blog encourages people like me–who have a cursory interest in coding–to ignore the collective voice in their heads that says “You can’t do this!” It’s a place for me to vent my own confusion and frustration. Forums are a godsend to beginner programmers, but I’ve found they can be also be filled with bro-grammers who post just to feed their own egos–to patronize and condescend.

This blog will be a weekly exercise in “Explain-it-to-me-like-I’m-five.” Except it’s more like “Explain-it-to-me-like-you-and-I-are-both-five.”

But I prefer to think of it this way: I know that I know nothing. Ignorance is only bad if you do nothing about it. That’s what this blog is. Consider me the proverbial cat who must “Hang in there baby”. It’s going to be a bumpy ride, but I’m looking forward to it.