Author: Roger Cheng

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.

 

Roger Cheng

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.
Roger Cheng

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.

Roger Cheng

Unexpected find: ThingLink and its business

A Science News article online experimented with interactivity not possible in their print edition. It was fairly simple at first glance: when a cursor hovers over certain places in the image, additional information pops up. Seen all over the web, like the little pieces of trivia behind bing.com background picture of the day.

What caught my attention is the link in the corner: “Made with ThingLink, Learn More” What I had thought was a simple piece of HTML is actually a business built around the concept.

A brief exploration found that ThingLink hosts the image (and associated server storage and bandwidth) plus the interactive scripting. The package of content is then available to be served alongside content hosted elsewhere, such as WordPress.com. I can embed a ThingLink right here in this post, if I had something interesting to show.

There’s a basic level of the service for free. To make money, they sell higher tiers with features like customization, branding, and analytic information. I’m ignorant on how this information might be valuable, but ThingLink has an idea: they believe the full set of features is worth over $200/month to some people.

So definitely not just a trivial piece of HTML. It is the tip of the iceberg of a corner of web commerce I didn’t even know existed before today.

Roger Cheng

Peek under the hood of Bootstrap

After completing Codecademy’s “Make a Website” lesson, I decided to go explore a side track to look under the hood of the Bootstrap framework used in the lesson. I’m not going to dive deep (yet), but I wanted to break it down into a short list of names I expect to encounter again as I explore.

The actual run-time components of Bootstrap appears to be two Cascading Style Sheet (CSS) files and one JavaScript (JS) file. One of the two CSS files is an optional theme. This confirms that Bootstrap has no client-side requirements, just a web browser that can understand standard CSS & JS files.

On the developer side, things get more interesting.

Grunt is the build system used by the Bootstrap project to build the project code, the documentation files, and run the unit tests.

It’s not clear if the JavaScript files are worked on directly, but the CSS is definitely not. It is done with Less and compiled to CSS. Some parts in the documentation listed “Less/Sass” implying Sass is a similar thing. Maybe look into this later.

Once the product is rebuilt, the JavaScript code is automatically reviewed by JSHint. Then tests are executed in the PhantomJS headless JavaScript runtime orchestrated by QUnit testing framework for JavaScript.

The product documentation pages were generated by Jekyall. Don’t know what the input for Jekyall would look like, but the output is static HTML pages. It claims to be the engine behind GitHub pages, so I know I’ll run into this again when I explore GitHub.

Several package managers were listed. Looks like NPM is required for actually working on Bootstrap itself, though it can also be used for projects consuming Bootstrap. Bower and Composer are two other package managers that seem to apply only to Bootstrap consumers.

That’s the first cut. Some things are still fuzzy, and some things I thought were clear may actually be wrong. We’ll see!

Roger Cheng

Codecademy “Make a Website” notes

I’ve just completed the “Make a Website” lesson on Codecademy, because it made sense to start at the beginning and (re)learn the fundamentals. I knew some simple HTML going in so I had expected part of it to be review and part of it to be new material.

The review part was expected: the lesson went over basic concepts of HTML tags and their hierarchical structure, then went into fine-tuning appearance via CSS.

But the new material was a surprise. After the CSS unit completed teaching about backgrounds and borders and spacing, it promised the next unit is about content and page layout. I thought “OK, good, now we’re getting into stuff I don’t know.”

The next unit began by introducing the Bootstrap framework to manage page layout. It was still an informative and fun interactive lesson, but I was left disappointed by the departure from HTML fundamentals.

It felt incomplete, like a math class that skipped doing addition with pencil and paper and instead going straight to using a calculator. Yeah, I’m probably not going to do it by hand ever again, but I wanted a lesson to teach me how to do it at least once. I would have preferred the lesson to go a bit into doing HTML layout the hard way, then say “Now that you know how to do it the hard way, let’s do it the easy way with Bootstrap.” Doing it both ways would give me a better feel of how HTML layout works and how Bootstrap makes it easier.

The Codecademy lesson worked as advertised, I’ll just have to fill this hole in my knowledge with something else.

Roger Cheng

War of Currents… again?

Every engineering degree covers electricity, it’s kind of important to everything engineered by man. Same with a science degree: electrical interactions are a large part of nature. In chemistry, biology, and propagating to all the other sciences.

Outside of scientists and engineers, most college physics courses would cover electricity, at least the principle differences between alternating current (AC) and direct current (DC).

Even outside of that, AC vs. DC gets mentioned in the occasional web comic.

As part of any coverage of electricity, there would be a chapter, a footnote, or some mention of the War of Currents: An ideological battle between backers of each form of electrical power, each convinced their side is superior to the other. The history lesson usually concludes with AC winning the battle around 1900. As AC works better with our power generation, power transmission, and power consumption.

Or more precisely… AC works better with power generation/transmission/consumption technology of 1900. The world has changed a lot since.

Machinery of 1900 run on AC, but modern electronics run on DC.

Old inefficient lights run on AC, but modern LED lights run on DC.

Coal-burning power plants churn out AC, but solar panels generate DC.

We never had a practical energy storage mechanism with AC, electric batteries have always been DC.

We tolerate AC-DC conversions on all of these things. Computers have an AC/DC power supply brick. LEDs make similar conversion. Solar panels have to use an inverter to convert their DC output to AC for use. All because our power grid is AC. And that’s not going to change for as long as AC is superior for power transmission.

But today I learned that, thanks to advancing technology, the economics of long-distance power transmission is tilting in favor of DC.

This is very interesting, because photo-voltaic solar power plants need a lot of real estate so they tend to be out in the middle of nowhere. A big factor in the economic viability of such projects is long distance transmission of power to population centers.

Combine the two, and it looks like all the pieces are in place for DC to make a come back.

I’ll be watching this space with fascination.

Roger Cheng

WordPress clients everywhere

The first step of documenting my experience on WordPress is… talking about WordPress itself. Self-referential, yes, but it actually served as a great introduction into a different mindset: Software as a Service (SaaS).

WordPress is itself a content management system designed to run entirely over the web. Not only is the content stored on a remote server, the management UI (like the text editor I’m typing this in) is served by the WordPress service over the web. There is no application to install on my computer. When I want to work on my WordPress site, I use my web browser.

SaaS is gradually taking over a lot of the software world, and as a Windows developer, I’ve been missing a lot of the action. It’s time to get to know this new cloud-based world. A world where the service is available anywhere there’s a web browser, because a browser is all the client software you’d ever need.

Or… is it?

It turns out the client-side software concept is not dead, not quite. And not even at WordPress. While it was no surprise to learn that WordPress have mobile apps to access the service on iOS and Android, I was greatly amused to learn they have also introduced desktop client software for Linux, MacOS, and…. Windows.

Yep, Windows client software.

What is old is new again.