Programming Languages

Roger Cheng

RailsGuides “Getting Started with Rails” notes

rails_guides_logo

It is my opinion that RailGuides’ Getting Started with Rails is a far superior educational resource than the Codecademy class on Rails which I did not care for at all.

The only thing I can say in favor of the Codecademy edition is the completely browser-based Codecademy learning environment. To run through the Codecademy tutorial mystery show, one only needs a browser. RailGuide has no patience to set up a virtual machine for you. It wants the reader to set up their own fully functional Ruby environment to follow along. (Don’t worry, instructions are right up front in Section 1.) If people are just surveying the technology, this may be more than they are willing to do. But those who are serious about getting their hands dirty will want it anyway, so I didn’t see that as a barrier.

Getting Started with Rails does a far better job of describing what Rails is, what it does, and the components that the students will be activating in the lesson. It explained the directory structure. It explained the relationship of the view and the model and the controller. It explained how the database relates to the model. On and on, tons of info I failed to get out of Codecademy.

The best part was when the class went into partial forms. (Codecademy didn’t cover the topic at all.) First the student did it the hard way, then the student is instructed on how to clean up after themselves and simplify the structure with partials. See the original – then work the magic yourself – makes for superior comprehension.

Ruby on Rails is a big complex machine and there’s still lots to learn. Like routing… the link_to routes are still magic to me. But I feel like I have a solid foundation now, which I didn’t feel before.

Onward to more Rails adventures…

Roger Cheng

Learn Ruby with the Neo Ruby Koans

ensoThe Ruby language site lists some resources for beginners in their Documentation section. Most of them followed the usual pattern of online language courses, but the Ruby Koans stood out. It is a language lesson by the way of test-driven development. The entire course is in the form of a single Ruby program full of test cases (280-ish when I downloaded it) that all fail. The job of the Ruby student is to look at the test case, understand what the test requires, modify the test case so that it succeeds, and proceed to the next one.

The very first test case is simple – true versus false. Then it progressively built up from there. Data types, flow control, object hierarchy, the works. While this covers much of the same ground as the Codecademy course I took a few days ago, the presentation and the format kept me engaged in a way the Codecademy course did not.

One reason was that it’s possible to “fast forward” through sections I understood: The test cases are all there in Ruby source files. So once I understood the concept covered by one test case, I can continue editing the similar test cases and have them all passing in one batch instead of one case at a time. In contrast to something like Codecademy where, even if I understood the concept, I still had click through the pages one at a time.

Bonus: after I finish the lessons, I have a bunch of Ruby files exercising various Ruby concepts that I can go back and look at for reference. It is much faster to scan through a Ruby file than it is to click through a Codecademy lesson.

This Ruby Koans approach to learning Ruby might not work with everybody, but I loved it.

Roger Cheng

RVM makes Ruby installation easy(*)

logo

(*) As long as you are running some flavor of Unix.

Ruby has a reputation for being difficult to set up. Looking at the setup documentation, I can see where that reputation came from. I suspect most of the reputation I heard came from Windows users, since that’s the camp I’ve historically been in. Windows users aren’t used to being treated as afterthoughts… and the Ruby community certainly does treat Windows as a second-class citizen. Most information applied to various flavors of Unix. Random aside: This surprisingly included the very-remotely-Unix-based Mac OS X. Mac instructions are more about ‘updating’ and I eventually figured out that recent versions of Mac OS X included Ruby. (An older version recognized to be stable but out of date.)

Back to Windows: Everything I found can be summed up as “Eh… look at this forum post, some people had good luck with XYZ. But you’re on your own, pal.”

After reviewing my options, I decided my first steps to the Ruby world would be:

  1. Ignore all the Windows hacks instructions.
  2. On my Windows development computer, install Ubuntu in a Hyper-V Virtual Machine.
  3. Inside the VM, follow the directions for installing Ruby on Ubuntu via RVM

RVM (Ruby Version Manager) is an utility some Ruby users wrote to help them keep the various Ruby versions straight. The fact this even exists and considered necessary is a little disquieting. Ruby users have to use something like RVM to switch versions around to match the version of whatever they need to get done that day. This implies that backwards compatibility is not exactly a strength of Ruby. (Possibly not even a design goal…)

I spent most of my professional career to date worrying about backwards compatibility day and night. This is a very different world. I’m not sure I’ll like it here, but I’m sure going to give it a try.

 

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

Neural network in JavaScript

When I was first introduced to neural networks, they were considered algorithms with extremely expensive computational requirements. Even the most trivial network required a high-end PC with lots of memory and floating-point math capability.

Of course, at the time a high-end PC processor ran at 90 megahertz, 32 megabytes of RAM is considered a lot, and floating point math required a separate (and expensive) floating-point co-processor.

Now the cell phones we have in our pockets have faster processor and more memory than those powerful PCs of old. Every current processor has floating-point math capability, no extra chip required.

Which means what used to be the domain of specialized programmers, running on expensive hardware, is now possible everywhere: running in a web browser like the TensorFlow playground.

But it’s still hard for a human to grasp what’s going on inside a neural network as it learns and adjusts. While the accessibility of the technology (meaning how easy it is to obtain) has improved, the accessibility of the knowledge (meaning how easy it is to understand) hasn’t.

Computer brains have made great advances in the past years…

Human brains have not.

Roger Cheng

Onward to Unity Adventures

After deciding to move on from Phaser, I looked around for other game engines to generate web games. I came across Unity again and again. Unity is not new to me, but I also knew their web support was via the Unity web player browser plug-in. This is a problem, as browser plug-ins have fallen into disfavor. All the major desktop browsers Firefox / Chrome / IE, are moving away from plug-ins.

So… dead end (or at least dying). Plug-ins are not the future of the web.

Because of the web player, I dismissed every mention of Unity for web development I encountered, until I came across information that slapped me upside the head and woke me up. The web player is not the only Unity web target: Unity now has another web-friendly build target: WebGL, no plug-in required! Wow!

This warrants a closer look. While WebGL might be immature and inconsistent across browsers, it is a shared goal of many interests to evolve and mature the platform and I share their high hopes. The browser plug-in model is going away. WebGL may or may not take off but all the signs today look promising.

Unity had been on my to-do list of research topics, but it ranked lower than HTML-related technologies. (This is why I started with HTML, JavaScript, Node.JS, etc.) There are many interesting areas of development I can explore with Unity. Graphics, networking, user interface design, virtual reality, Android development, iOS development, the list goes on.

And now I learned that I can even explore some parts of the web world with Unity. It is quite the Swiss Army Knife of software development. With this latest discovery, Unity has moved to the top of my to-do list. It is time to roll up my sleeves and dig in.

This should be fun.

Roger Cheng

A quick look at Phaser

In a quest for something more substantial, I looked into the HTML5 game engine Phaser. It has a large audience and an impressive set of features. It was fun poking through some of the source to see how it does its magic, but I ultimately decided against making my own Phaser creation because it is at its core a bitmap-based system.

Bitmaps don’t scale as nicely as vectors by their nature, and I place a great deal of importance on ability to scale well. In the modern HTML world, the customer might be running resolutions ranging anywhere from a 320 x 480 iPhone screen to a 3840 x 2160 4K desktop display.

The people behind Phaser isn’t blind to this. Part of the core features includes a ScaleManager class to help the process. There are also ways to load lower- or higher-resolution assets in response to the screen resolution used by the particular user. But it is an imperfect solution, there are still bitmap scaling artifacts around that plainly wouldn’t be an issue at all had the system been based on vector graphics.

Most of the Phaser titles don’t bother with scaling at all, or only scale across a few fixed resolutions. I find myself quite annoyed when I load up a sample app, just to see it take up a tiny 320×480 (resolution of the original iPhone) section of my desktop browser.

sigh

I’ll keep looking.

Roger Cheng

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.”

 

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

jQuery Learning Center

After Codecademy got me off the ground with jQuery, I moved on to the jQuery Learning Center put together by the people behind the jQuery project. The learning center assumes some level of existing knowledge, so I was glad I got the Codecademy primer first.

As expected, the jQuery Learning Center went into more depth on topics that were outside of a quick primer such as Codecademy.

Implementation: The learning center gave some details on how jQuery works behind the scenes. This helps programmers understand and debug when things go wrong, and sometimes leads to information on code performance.

Performance: Hand in hand with implementation details, the learning center teaches some basics on writing efficient jQuery code. This is different from writing terse jQuery code. What looks like small amounts of jQuery code might end up triggering a lot of work for the computer behind the scenes. A programmer unaware of the implementation and performance consequences can get tripped up.

History: The learning center occasionally switches into history lesson mode. It is moderately enlightening to understand the evolution to the current implementation. More importantly, it helps people recognize and understand old legacy jQuery code they might end up having to maintain.

Code organization: This section was not jQuery specific. It covered a few ways to use JavaScript to implement classic object-oriented programming concepts. I was intrigued by this section, because it didn’t match what I saw in the Codecademy JavaScript class. It is useful to get a different perspective on how to solve the same types of problems.

It was good timing. My own JavaScript practice program had not been written under any semblance of code organization, just building as I go, and it was growing out of control. Seeing how messy things were turned out to be great motivation to put organization concepts into practice and tame my hairy beast.

Roger Cheng

JavaScript closures make my head spin

Coming from a world of strongly typed programming languages, JavaScript is weird. And the deeper I get, the weirder it got.

I’ve had brushes with JavaScript closures in my learning to date, and the fragments I saw looked like evil black magic. Today I dove in headfirst to learn more about it.  With my new found knowledge, it no longer feels like black magic.

It still feels evil, though.

Closures have all the appearance of something that “fell out” of the flexibility of the JavaScript type system. It felt like somebody, in an effort to solve some unrelated problems A, B, and C, accidentally opened a Pandora’s Box and closures emerged. With some bizarre behavior and huge potential for difficult-to-diagnose bugs. I’d hate to think it was designed to be that way. I prefer to believe it was an accident.

Accident or not, it is a very powerful mechanism and people are using it in the world. Which means I will need to be able to read and understand code that uses closures. It is irrelevant whether I personally believe closures are evil.

It’ll take a few more rounds of practice before I’m comfortable with the nuances. In the meantime, I’ll be reviewing this page frequently as I found it to be the most helpful. The author emphasized repeatedly that hands-on experience with real closure code is more illuminating than reading a lot of rigorous academic style description of closures. So that’s exactly what I intend to do.

 

The best I can hope for is to start feeling comfortable with the power and pitfall of closures. Maybe I’ll even come to appreciate it as a necessary evil.

But I doubt I’ll ever come to think of it as A Good Thing.

Roger Cheng

Compilation of JavaScript resources

The benefit of JavaScript is that there are a ton of resources. The downside of JavaScript is that there is so much, it’s hard to figure out where to start and who to believe.

After the expected period of beginner fumbling, I now know a few things to be incorrect. But more importantly, I now know many things to have no single Right Answer(™). JavaScript is so flexible that there are many ways to do many things and not much to differentiate one from another except personal preference.

This makes me wary of advice compiled on somebody’s blog, because that’s really their personal opinion and I don’t know if I necessarily agree with that person’s priorities.

But if the collection of resources was assembled by a group of people, that makes me a little more comfortable. So I was happy to stumble across JSTheRightWay.org.

The name seemed pompous and arrogant, but the introduction made me feel like I’ve found a good thing:

This is a guide intended to introduce new developers to JavaScript and help experienced developers learn more about its best practices.

Despite the name, this guide doesn’t necessarily mean “the only way” to do JavaScript.

We just gather all the articles, tips, and tricks from top developers and put it here. Since it comes from exceptional folks, we could say that it is “the right way”, or the best way to do so.

I’ll be coming back to this page quite frequently. May it live up to my hopes!

Roger Cheng

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.

Roger Cheng

The cross-site rabbit hole

Wow, cross-site issues are huge cans of worms!

In the absence of first-hand experience dealing with network-centric development, my knowledge of cross-site vulnerabilities has been limited to broad descriptions covered in tech press.

While educating myself in the jQuery Learning Center, I came across the JSONP utility functions of jQuery. Trying to understand the utility meant I had to look up JSONP. Trying to understand JSONP required learning what problem it is trying to solve. Which dropped me into the rabbit hole of web security. Starting with a web browser’s same-origin policy, through cross-site scripting (XSS), cross-site request forgery (CSRF), and others.

The short version: Communication across multiple web domains is a very powerful thing. And like everything that’s powerful, there are people who will use it for evil. The various browser policies are efforts to shut down such activity to protect users from evil.

Like every effort to control great powers that can be used for good or evil, both sides continue to find ways to do what they want despite the walls erected to block them.

  1. Because it is so powerful for nefarious purposes: Hackers continue to find ways to circumvent cross-domain protection with clever exploitation. To keep me grounded in jQuery education, Wikipedia helpfully pointed to a cross-site security issue in jQuery itself. Problems can hide anywhere.
  2. Because it is so powerful for legitimately useful purposes: Developers continue to find ways to communicate across domains in a relatively safer manner. (Usually until a creative hacker comes along to prove why it isn’t safe.) JSONP, which started my whole adventure, is one such method.

Like everything else I’m learning about web programming, this will have to be a brief overview and I have to come back later. Right now I don’t even understand all the vocabulary yet.

I’m unsettled by this topic. The importance of network security grows with every passing day. This feels like a very fundamental area of network security, and it is a huge nasty hairball that has proven to be difficult to untangle. This can only be a recipe for more security vulnerabilities in the future.

Maybe even one that I inadvertently create.

Ugh.

Roger Cheng

JSFiddle

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.

Roger Cheng

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.

 

Roger Cheng

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!

Roger Cheng

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.