Learning How to Learn

Learning is really difficult. It’s not always a matter of exploring a new concept; sometimes it requires the breaking-up of a long-settled foundation, and replacing it with something more reliable.

The hardest thing about learning, however, is learning how to learn. Sounds weird, I’m sure, but think about it for just a moment. What drives you? What is it that actually makes a topic interesting to you?

Early on in my childhood I was diagnosed with ADD, and drugged mercilessly to combat the general apathy I had towards just about everything. It didn’t really matter what you were trying to teach me, I had no interest in learning.

I remember being perplexed by multiplication. “What is it?” I asked a classmate. They halfheartedly replied, “it’s the opposite of division.” What the heck does that even mean? Now I have to figure out what division is, and then be able to think about it backwards to discover the magic of multiplication?

As an adult, I look back and realize that I had no interest, because nobody was truly communicating with me. They would tell me the answer, but they weren’t successfully getting through. One teacher even had me stay after school on many occasions to explain per-cent; she used the nutritional information on a box of cereal as an example. Who the heck cares about cereal?

It wasn’t until I was in high school that I started showing an interest in learning. I had just gotten a computer and began playing Jedi Knight: Dark Forces II on the Microsoft Gaming Zone. Our clan was totes the best. Shout out to the Golden Warriors, wherever you are these days!

This was the first computer game I really ever played, and I was blown away that people were able to make their own maps. Gamers were able to build their own little worlds, out of nothing. I wanted in on that experience, and nothing would stop me.

Back in the 90’s, the software kind of stunk for this. It was CAD-like orthographic views. You started off your map with a single cube, only it looked like a square on the screen, because you dealt with geometric shapes.

Drawn all across the screen were boxes, lines, and dots. The dots were a means by which you could measure distance, and served also as snap-points. The boxes were sectors, or rooms in your map. The lines were the edge of surfaces, and where those lines met were vertices. It took a little work to get the general vocabulary down, but once I did, I hit the ground running.

Drawn to the idea of creating my own worlds, I began learning geometry. I started thinking about math more. Everything required me to learn some foreign math concept. Want a river with a current? You have to read up on vectors.

This excitement for math stuck with me. Most recently, I’ve found myself learning additional math concepts to achieve certain effects in canvas animations, or trying to manipulate large data.

It took me years to learn how to learn. Nobody was able to teach me; I had to learn it for myself. For me, learning comes by way of creating. I wanted so badly to create that I found a way to scale the once insurmountable mounts that now shrink into the horizon behind me.

My son reminds me a lot of myself when I was younger. He doesn’t want to sit still, he wants to be up, jumping, kicking, and moving around. He wants to be talking about video games, and “smoking turkeys” (pwning n00bs).

I’ve found that he responds well to video games, as I did. Together we play Warcraft II: Tides of Darkness. If a farm feeds 5 soldiers, and we need 10 soldiers to protect our base, how many farms do we need to build? We need to figure that out quickly; the Orcs are coming!

It’s really hard to get into another persons head, and learn what makes them tick. As teachers, adults in my young life sure tried (and perhaps succeeded in some ways). As a father, I’m trying my hardest with my kids. If you’re reading this, you are likely in a similar situation.

I still struggle with attention and focus as an adult. Sometimes working from a public place helps. Sometimes it hurts. Sometimes I’ll need a colored light in my office, and sometimes I need only the glow of my monitor. Sometimes I need music, and at other times I need complete silence.

I am still figuring myself out, as I work to help my son do the same. He and I are fighting this dragon together, side by side. We’re both learning how to learn.

Persistence Will Set You Apart

I mentioned a couple posts back how difficult web development has become. When I started, you had to learn HTML, and a handful of key attributes to style elements (CSS wasn’t yet a thing). Since then we’ve seen a Cambrian Explosion in the industry. Out of nowhere was birthed an immense amount of complexity.

You’ve probably heard about Imposter Syndrome, or the idea that you are not deserving of your professional position and/or accolades. I don’t recall this being a thing in the past, but it quickly became one in the 2000’s. Many of the biggest names in our industry have expressed these types of feelings on occasion, and who can blame them?

As you progress in your career, you will inevitably be faced with complicated technical barriers. It’s part of growing, and it’s part of existing within a field that is itself growing. How you react to these barriers will determine your long-term success or failure.

My son loves video games. He’s been playing them since he was about 2.5 years old. And since he began, I have been working hard to instill within him the idea that he can do hard things.

On multiple occasions he has encountered a boss battle or an obstacle that he simply couldn’t surmount. He would come to me, shoulders shrunken in defeat, asking that I take the controller from his downtrodden grip, and advance him one stage further. Rather than do so, I would straighten his posture, and tell him “you can do hard things!”

I cannot express in words how much joy I feel to see him return to the game, try 2 or 3 more times, and then erupt in excitement when he succeeds. He is internalizing the belief that he is capable of great things.

I have to coach myself in a similar manner. Just a couple of days ago I was looking for a new hosting provider. First, I went to Azure. Within 10 minutes, I was ready to give up. I couldn’t make heads or tails of the dashboard.

Next, I went to Digital Ocean. They wanted me to learn about “Droplets”, or something. They had a “one-click install” for WordPress, but it left me only with a gateway to a UNIX console. It’s been a while since I rolled around in one of those. I was tempted to just give up.

What kind of example would I be setting for my son if I gave up? Am I not capable of hard things too? Certainly I am! I have spent a decade telling clients that Nothing is hard; but some things take more time. It’s time for that ideology to be more than a sales pitch; it’s time for it to be the foundation upon which my efforts are established.

There are generally two types of people in this industry: those who can do hard things, and those who shy away from hard things. I want to strive to be the former. I want  you to do the same. After all, we’re in this together.

Persistence will set you apart.

Learn Together

Learning is one of the most essential keys to succeeding in web development these days; you have to continue to evolve with the ever-changing topography of the industry.

In the 90’s, when I started learning to build websites, there weren’t a lot of resources online. I WebMonkey and HTMLGoodies for the most part. I spent hours on these sites, learning all that I could. And for everything else, there was View Source.

The great thing about View Source was that it gave you a look into the mind of another developer. While I’d pick up the primitives from WebMonkey and HTMLGoodies, I learned creative approaches and applications in View Source.

I had very few friends that showed in interest in web development back then. I was raised in a small town set off a river in Southern Illinois. We were mostly interested in sports and video games. Today that isn’t the case; I have a large network of friends who are obsessed with building for the web.

Learning in a group is powerful. It lightens the load on each individual. And nowhere in history has it been more necessary than it is today. Web Development isn’t about hacking together some HTML and tossing it up on Geocities, like it was in the 90’s.  Today you have to figure out pre-compilers, deployment strategies, version-control software, and more; and we haven’t even gotten to the actual development process yet.

Years ago I used to meet regularly with some friends to catch up on life, and find out what they were learning. We’d walk each other through code we had written during the week, and explain new ideas. This was how I would become introduced to many JavaScript frameworks, Node.js, and more. We’d even revert to studying Math we had long forgotten to solve certain problems together.

Learning requires hours of slugging through lengthy documentation, manuals, and more (assuming good documentation even exists; it often doesn’t). There is often a frustrating process of trial-and-error that leaves you aggravated, before it leaves you enlightened. But when you come out on the other end, you’re able to save others the heartache by leading them along the path of least resistance.

It’s often said that a 2 horses don’t pull twice as much as 1 horse, they pull 3 times as much. There’s power in the unity of mind and effort. This is shown in group-learning, as well as in pair programming. So find a few friends, and meet regularly.

Learn together.

Mentor Somebody

Just a couple brief thoughts about mentoring.

Whether you’ve been a hobbyist for 6 months, or a professional for 6 years, you have something to offer. It may be as basic as explaining what HTML is, or something a bit more advanced like explaining how prototypes work in JavaScript. The bottom line is, though, that you have something to offer.

Back in the 90’s, when I got my first computer, I began to show an interest in web development. I didn’t know anything about programming, computers, or the Internet. I had just gotten a Hotmail account not too longer before that, and spent at least a few months thinking HTML was pronounced “Hotmail”.

A buddy of mine started learning web-development a little before me, and would mention it from time to time. It didn’t take long for me to get interested, and offer him $20 to build a website for me (big money, I know). He politely refused, and told me to “learn the code yourself”.

The code? What was the code? I suspected it was a series of numbers and letters that I type into the scary black part of the computer (cmd.exe). “Can you tell me the code?” I asked. He chuckled, and began to open up my understanding.

That particular friend invested maybe 20 minutes into my life. From that 20 minutes came 20 years of industry experience. I’m thankful for his willingness to be inconvenienced for a few moments. It changed my life.

Get out there, and change somebody’s life.

IE doesn’t have an emulation feature

“I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.”

Document Modes in Internet Explorer are probably one of the most misunderstood features of the browser itself. The cause of the confusion doesn’t lie exclusively on the end-user either, Microsoft has shipped a Document Mode switcher in the F12 Developer Tools under an Emulation tab for a while now. As a result, it’s not uncommon for people to think that Internet Explorer 11 can emulate Internet Explorer 8 for the purposes of testing simply by switching the Document Mode.

“I have a very bad feeling about this.”

So what the heck is this feature? Why does it exist, and what should we call it if not “emulation”? I recently discussed this on twitter with a friend, and my frustration over the matter drove me to really sit and think about a proper way to illustrate the purpose of this feature. After some thought, I arrived at a comparison with an A99 Aquata Breather. You know what that is, right? No? Let me explain.

The A99 Aquata Breather (seen in Star Wars, episodes I and III) allowed Jedi to survive for up to 2 hours in an otherwise hositle environment. For instance, on their long-swim to the underwater city on Naboo Qui-Gon Jinn and Obi-Wan Kenobi used Aquata Breathers to stay alive long enough to enter the Hydrostatic Bubbles of Otoh Gunga (I really hope this is making sense…).

Lets bring this back to Internet Explorer and Document Modes. Just like Qui-Gon and Obi-Wan weren’t able to breathe under water (unassisted, that is), a site constructed in/for Internet Explorer 8 may not necessarily work in Internet Explorer 11 unassisted. So to ensure a more enjoyable experience, and avoid certain death, Jedi swim with an assisted-breathing device, and web developers send x-ua-compatible headers with their HTTP responses (or a meta-tag, if that’s your thing).

“That’s no moon. It’s a space station!”

So that Document Mode switcher in Internet Explorer’s F12 Developer Tools is not for seeing how well your modern site will work in a legacy browser, but rather how your legacy site will work in a modern browser.

Suppose a developer built an intranet application for her client in late 2009, when the client was running Internet Explorer 8 internally on a thousand machines. Several years later, the client calls the developer and informs her that they are planning on moving to Windows 8.1, and Internet Explorer 11. At this point, the developer can open Internet Explorer, navigate to the application, and see how well it will work for her client in a modern version of IE. Should she encounter differences in layout or scripting, she could switch the Document Mode to that of Internet Explorer 8 and see if this resolves the problem. (See also Enterprise Mode for IE)

Note the directionality — Document Modes are for making older sites work in modern browsers by creating (to some degree) environmental configurations the site relies on. This doesn’t turn the browser into an older version of itself; it merely satisfies a few expectations for the sake of the application.

“This is some rescue! You came in here, but didn’t you have a plan for getting out?”

Like the A99 Aquata Breather, a Jedi developer should only be expected to rely on a legacy document mode for a short period of time. The x-ua-compatible approach should be seen as a splint to keep your broken leg together until you can get some serious medical attention for it. It’s meant to keep you upright with the intent that you should be able to soon stand alone, unassisted. Don’t use a breather unless you’re swimming to a place that has air to breathe, and don’t use x-ua-comptabile headers or meta-tags without intending to fix whatever breaks your site in a modern browser.

If you develop in a modern version of Internet Explorer and do need to see how your site will render in an older version of IE, your best option is to download a free virtual machine from modern.ie, get an account on browserstack.com, or do your testing the next time you visit Grandma’s for dinner.

Simple Throttle Function

When you’re handling events like window resize, keystrokes, mouse movement, and scrolling you need to be careful how many times you call heavy-handed functions. For instance, if you’re leveraging JavaScript to create responsive UIs in legacy browsers you probably don’t want to run complicated DOM-altering handlers 10 times a second when far fewer runs would be sufficient. Enter throttling.

Throttling is a means by which we can limit the number of times a function can be called in a given period. For instance, we may have a method that should be called no more than 5 times per second.

function callback () {
    console.count("Throttled");
}

window.addEventListener("resize", throttle( callback, 200 ));

In the above, our throttle function takes a callback, and a rate limiter. It will fire the callback at most once every 200 milliseconds, or at most 5 times per second. So what does the actual implementation of the throttle function look like?

function throttle (callback, limit) {
    var wait = false;                 // Initially, we're not waiting
    return function () {              // We return a throttled function
        if (!wait) {                  // If we're not waiting
            callback.call();          // Execute users function
            wait = true;              // Prevent future invocations
            setTimeout(function () {  // After a period of time
                wait = false;         // And allow future invocations
            }, limit);
        }
    }
}

The above is fairly straight forward, but let’s discuss it briefly anyway.

The overall solution is to replace the user’s function with our own function. This allows us to add extra logic to the mix, such as how frequently the function can be invoked. This is why our throttle function inevitably returns a new function.

We manage our state with a variable called wait. When wait is true, our door is closed. When wait is false, our door is open. So by switching this value from true to false, we can allow the user’s function to be invoked. And by switching wait from false to true, we prevent any calls to the user function.

Anytime we switch this, we setup a timeout that will toggle it back to false after a period of time. This is where the 200 milliseconds comes in – we’re allowing the user to determine the length of time our door should be shut.

You should also use throttling for function that get called dozens, or hundreds of times. It’s rare that you actually want things to be called that often. The implementation in this post is fairly simple (I was shooting for conciseness), but more complicated solutions exist such as those in lo-dash, underscore, and more.

I created a fiddle with a throttled and and non-throttled callback. Tying this to the window resize event, I adjusted my window width/height briefly and let the number of calls speak for themselves:

Throttled results vs Non-throttled results
Throttled results vs Non-throttled results

Emulation Accuracy in Internet Explorer

Early preview versions of Internet Explorer 11 lacked Emulation features that we saw in Internet Explorer 9 and 10. When Windows 8.1 shipped, Internet Explorer 11 was found to have the Emulation features shipped with it. These tools are helpful, though they can be misleading at times.

My general workflow in the past when using these tools goes like this: A user reports an issue in Internet Explorer x. I instruct the latest version of Internet Explorer to emulate the reported version. If I encounter the same issue, I can debug using the modern version of Internet Explorer. If emulation does not reveal the same issue, I need to load up a virtual machine, or use a service like BrowserStack.

The problem with these tools is that it’s not entirely clear where the line of reliability resides. To what degree this emulation replicates the native experience is unknown (to me, at least). Due to this, I’ve decided to do a deep dive into Emulation and see just how reliable it is, and in which areas.

Computed Styles

The first dive wasinto Computed Styles. Does Internet Explorer generate the same computed styles as IE10 and IE9 when it is emulating those versions? Surprisingly, yes. Granted, I’m running instances of IE10 and IE9 in a Virtual Machine (compliments of modern.ie), so that should be considered. Also other important thing to note is that this pass-through assumes Standards Mode.

The comparison tables are being maintained in a Google Docs spreadsheet. Click the preview below for the full view.

comparison.table

Window Object

My next focus was on cycling over enumerable properties on the window object and laying those out for comparison. A cursory glance of this next table will reveal that Internet Explorer 11 emulates the window object from IE9 and IE10 very well. Granted, there are some very clear examples of where it brought along a couple extra methods and properties.

comparison.table.window

It’s worth noting that this particular table had to be done a couple of times. Some of these members don’t attach themselves to the window object until certain actions are performed. For instance, this table is front-loaded with a bunch of BROWSERTOOLS members that are pushed onto the window object when various portions of the developer tools are opened. Other members, such as $0, don’t exist until you perform an action like selecting an element in the DOM Explorer.

More on GIFs and Painting in Internet Explorer

About a week ago I wrote a post demonstrating the use of UI Responsiveness functionality in Internet Explorer 11 to determine how the browser handles animated GIFs in various states. This post was a fairly well-received so I wanted to expand a bit more upon it and cover a few more scenarios.

For the most recent round of testing, I setup a simple interval to change the className of the body element every few seconds. This, in turn, affects the placement and layout of a single image element within the document.

(function () {

  "use strict";

  var states = ["", "opacity", "visibility", "offscreen", "perpendicular"],
      container  = document.body,
      cycles = 0,
      nextState;

  function advanceState () {
    // Advance to next array index, or return to start
    nextState = states[++cycles % states.length];
    // Indicate a new performance mark in our developer tools
    performance.mark(nextState ? "Starting " + nextState : "Restarting");
    // Update the body class to affect rendering of image
    container.className = nextState;
  }

  setInterval(advanceState, 3000);

}());

I used the performance.mark method to add my own indicators in the performance graphs to help me identify when the demo was transitioning into a new state. These performance marks are represented in Internet Explorer by small upside-down orange triangles.

performance.ticks

Let’s walk through each of these triangles left to right, discussing the state they represent.

GIF Untouched

This state is represented by all activity to the left of the first performance mark. Not much needs to be said – Internet Explorer continued to paint the GIF as it sat animated on the screen.

performance.ticks.0

Setting GIF Opacity

This step is represented by all activity between the first and second performance marks. In this step, the image element has its opacity property set to 0. Even though the image is no longer visible, the browser continued repainting the region occupied by the image element.

performance.ticks.1

Setting GIF Visibility

This step is represented by all activity between the second and third performance marks. In this step, the image element has its visibility property set to hidden. Once the visibility property was set to hidden, the browser made one final repaint (presumably to hide the element) and no further paint events took place during the duration of this state.

Of relevance here is that the hidden attribute on the image itself has the same effect. When this attribute is present on the element, Internet Explorer will cease to repaint that elements occupied region.

performance.ticks.2

Setting GIF Outside of View

This step is represented by all activity between the third and fourth performance marks. In this step, the image element is positioned absolutely at top -100% left -100%. In spite of the fact the element is positioned outside of the viewport itself, the browser continued to run paint cycles.

performance.ticks.3

Setting GIF Orientation Perpendicular to Viewport

This step is represented by all activity between the fourth and fifth performance marks (the fifth mark is the ‘Restarting’ mark). In this step, the image is rotated using the transform property so as to set it at a right angle to the viewport, effectively hiding its content from the viewer. This orientation did not affect the browser paint cycle, and Internet Explorer continued repainting the region occupied by the image element.

performance.ticks.4

Conclusion

As a general rule, it appears Internet Explorer will run paint cycles for every animated GIF in the document, unless that element has its visibility property set to hidden. This is fairly reasonable, since setting visibility to hidden is the only explicit way to tell the browser not to render the element. Keep this in mind when performance is of key importance.

After running through and investigating this further I was curious what the same test would reveal in Chrome. I was pleased to see that Chrome would cease to paint for the opacity, visibility, and offscreen configurations. No performance marks are revealed in Chrome’s developer tools, but you can identify the timer functions by the presence of a small orange mark.

performance.ticks.chrome

Tracking GIF Repaints with UI Responsiveness

I recently came across Paul Lewis’ article Avoiding Unnecessary Paints: Animated GIF Edition on HTML5 Rocks and wanted to contribute a bit to the message. If you aren’t a regular reader or HTML5 Rocks I would definitely encourage you to visit often.

The summary of Lewis’ post is that animated GIFs can cause repaints even when obscured by other elements. So even though you may not see the GIF, the browser may continue to repaint every frame of it.

As far as browsers go, Lewis shared with us the “Show paint rectangles” feature in Chrome. When enabled, this feature will visually outline regions that are being repainted. This obviously makes it very easy to determine whether paints are happening on obscured elements. Chrome, Safari, and Opera all repaint. Firefox does not.

In his discussion of various browsers, Lewis calls Internet Explorer 11 a “black box,” suggesting it gives “no indication whether repaints are happening or not.” As a result, no statement was made speculating whether Internet Explorer was in the camp of Chrome, Safari, and Opera, or Firefox.

I quickly did a scan of the comments to see if anybody addressed these words regarding Internet Explorer, but at the time nobody had. I saw this as a great opportunity to introduce my friends to the new UI Responsiveness tool in Internet Explorer 11.

The UI Responsiveness tool in Internet Explorer’s Developer Tools will actually give us pretty granular information about frame-rates, script timing, styling changes, rendering, and even repaints. Given the novelty of this feature in Internet Explorer, I felt it would be good to provide a quick example of how Internet Explorer 11 can indeed tell you whether obscured GIFs cause repaints or not.

A Single Visible GIF

My first experiment consisted of nothing more than a single GIF in the body of my document. By profiling the page for a few seconds I could see that there was constant repainting. This was expected of course, after all there’s a GIF on my screen spinning.

Below is one second of activity. As you can see, constant repainting.

gif.1

Toggling Visibility of a Single GIF

Next up, toggle the visibility of the GIF by way of its display property. I setup a interval to flip the visibility every second. The results were also as expected. For roughly one second, we had constant repainting. Following this we saw a set style event, followed by a single repaint (to hide the element). At this point, it was silence for a second before the element became visible again, and thus began causing additional repaints.

gif.2

Routinely Obscuring a Single GIF

The last experiment was to add another element, a div with a solid background-color in this case, and obscure the animated GIF on an interval. This was done by positioning both the div and the image absolutely within the body, and giving the div a higher z-index.

As can be seen in the image below, repainting did not cease even when the layout was adjusted every second. This demonstrates that when obscured, animated GIFs will continue to cause repaints in Internet Explorer 11. Whether this will be the case for future versions of Internet Explorer remains to be seen.

gif.3

Conclusion

So as we can see in these examples above, Internet Explorer 11 is capable of sharing vital information about costly repaints. Additionally, IE falls into the Chrome, Safari, and Opera camp. It sure would be nice if all browsers followed Firefox’s lead here and stopped repaints on obscured GIFs, but perhaps there is a good reason they haven’t, who knows.

I hope you can see the enormous value the UI Responsiveness panel in Internet Explorer 11’s Developer Tools brings to the debugging experience and use it to make your projects more responsive and performant in the future. The team behind Internet Explorer really have been doing amazing work lately, and the UI Responsiveness functionality is but one example of this.

UPDATE: More on GIFs and Painting in Internet Explorer