Monday, September 29, 2014

Can You Remember my Password for Me?

Let's talk for a minute about bad password policies. In today's comic, some shady pythons are using social engineering to steal passwords and other important information from the unsuspecting frogs. But in real life, there are plenty of frogs and too many snakes trying to trick them. You are more likely to have your network compromised by a user falling victim to a social engineering attack than you are having a machine run some algorithm to guess a password.

And no password policy is going to fix that. In fact, it might make the problem worse.

Today I'm forced to create passwords that are terrible. Terrible in that I can't remember them. But they are "good" by someone's standards.
  • At least 12 characters long
  • Containing upper and lower case characters as well as special symbols
  • No dictionary words
  • No more than 2 of each type of character in a row
  • Has to be changed every 60 days
  • Can't be re-used for 6 years
  • Can't be remembered for more than 6 minutes
I lose hours of productivity waiting for someone from IT to reset my password every other month when it expires. But what are my other options? Write my password on a sticky note and put in on my monitor? That seems like a poor choice too.

Sometimes I forget the password after a month. Yes, after typing it in every day for a month, I can no longer do it. My fingers just want to mash random keys instead. I've had this problem as far back as I can remember. How far back is that? I forget. But for reasons I can't explain, I would forget my locker combination several times per year in high school. The combination never even changed. I had the same one all year. I just lost the ability to remember it every once in a while.

Today I can tell you the license plate number from my first car, but I can't reliably remember my passwords. I only had the license plate for 4 months, and it was 19 years ago. There is something wrong with my brain.

I really want to switch to randomly-generated multi-word passphrases (read this PDF), but unfortunately I don't set the security policy. comic for September 29, 2014

Friday, September 26, 2014

Why Do I Write Code in [insert language here]?

Starting this past Wednesday and continuing today (it will go on into next week if you must know), the frogs in my comic have hired some pythons to write software because they heard it was trendy. For the record, the Python programming language was named after Monty Python, not a snake, but that makes little difference when you are trying to select a language for a new project.

So the question is, do you pick a language to code in because it is practical or because it is popular?

And how do you even measure a programming language's popularity?

It turns out there are several groups that try to measure language popularity utilizing different methods. Take a look at the following...
So by most measures, Java and C remain very popular. It's important to see this in real objective data, because sometimes our understanding of programming language popularity becomes skewed by media attention. Often, languages that people talk about very much are used very little in production systems.

I found that all very interesting, but when I am starting a project (or re-starting, or upgrading) I try to pick the most appropriate language for the job. If there is more than one viable language for my system requirements, I pick the one that is most familiar to the team (which may be just myself). In other words, I tend to take a very practical approach to language selection.

Sometimes there is little choice. If you want to create an iOS application, your options are very constrained. This kind of specialization in certain product spaces is nothing new. When I was writing BBS Door Games in 1995, nearly all development was done in Pascal. I don't know why, I didn't really question those types of things back then. Of course, I only knew of 3 programming languages at the time...

Other times there is too much choice. If you want to build a web application, your options are nearly limitless. Personally, I have written REST web service applications in Java for a WebLogic application server and in JavaScript for Node.js. The JavaScript ones tend to be easier to write, but that doesn't mean that it's always the better choice. Knowing your particular requirements and the properties of a number of languages are the keys to making the right decision.

The take away from this is that if you want to be an extremely effective software engineer, you should be familiar with many languages and not be afraid to learn new ones. If you pick a bad one for a project, at least it's a learning experience. Don't make the same mistake again, even if it means learning something completely new. comic for September 26, 2014

Wednesday, September 24, 2014

It's the Age of Asynchronous

I'm not sure how many people have noticed this yet, but Firefox 30 deprecated synchronous XHR on the main thread. They said that it leads to a degraded user experience, and they're correct - in most cases. But I've used it on occasion without any serious side effects, I just had to be careful about what I was doing.

Still, I should probably stop doing it. How can I call synchronous XHR Ajax if the A in Ajax stands for Asynchronous? Take away the A and it's just Jax. Not cool. Of course, the X stands for XML and most people use JSON instead these days. But what is Ajaj? That doesn't even make any sense! Let's move on...

A common use of the synchronous XHR is to ensure order of operations. If you have to make calls to get data from 2 URLs before doing some kind of processing, you can't guarantee which one will return first. If you can't use synchronous XHR anymore, you could stack up the calls inside callbacks so you only ever do one at a time...but then you're still only doing one at a time. If one call takes 3 seconds and the other takes 2, you have a total wait time of 5 seconds before you can continue. If you could somehow call both at once but still make sure the results are processed in a certain order, your total wait time is only 3 seconds. Saving 2 seconds might not sound like much, but it can really add up. And when you have a human being waiting for some on-screen response, 2 seconds is an eternity. Plus, performing the calls sequentially in callbacks might be fine for 2 or 3 calls, but it gets crazy when you need to stack 5 or 6 callbacks deep.

There must be a better way.

There is! If you use jQuery, the when().done() functions can handle the difficult task of making multiple asynchronous calls and keeping the responses in order.

The when() function takes as arguments as many Deferred or Promise objects as you want to pass it. When all of them have completed, the function passed to done() is called with the results of the Deferreds as arguments in the order they were given to when().

Since Ajax calls return Promises in jQuery, they can be used as arguments to when(). For Ajax Promises, the results passed to the function given to done() will be 3-element arrays. The first element in the array will be the returned data, the second will be the status text, and the third will be the jqXHR object. I've thrown together a working example of this...

Here is my test HTML page. The JavaScript starting on line 20 is the important part.

<!doctype html>

<html lang="en">
  <meta charset="utf-8">
  <title>Async Order Test</title>


  <p>when().done() test page</p>


<script src=""></script>

$(function() {



    ).done(function(a, b) {






And here is my Node/Express server app.

var express = require("express");
var app = express();

app.get("/something/a", function(req, res, next) {
    // simulate a long response time for this path.
    // we won't send the response for 3 seconds.
    setTimeout(function() {
        res.status(200).send("this is a");
    }, 3000);

app.get("/something/b", function(req, res, next) {
    res.status(200).send("this is b");

// ------------ static content

// ------------ start the listening
var server = app.listen(3000, function() {
    console.log("listening on port %d", server.address().port);

I've set up the /something/a resource to take a long time to respond. The /something/b resource should respond as quickly as possible. Therefore "b" should pretty much always return first even though it is second in the list passed in to when(). Looking at the console output, it is clear that the "a" response is printed out first despite returning last.

The when() function can be used for other types of Deferreds as well - it is not limited to Ajax calls although these are perhaps the most common uses.

If you're not using jQuery (perhaps you have a similar issue on the server side in Node), there are other libraries available that provide similar functionality. Check out Async.js for a good one. If you are a hardcore computer science fanatic, you could implement something yourself. Here is an example I quickly threw together for doing it in Node...

var http = require('http');

function waitFor(urls, cb) {

    var countDown = urls.length;
    var retVals = new Array(countDown);

    function processResponse(idx) {
        return function(response) {
            var str = '';
            response.on('data', function(chunk) {
                str += chunk;
            response.on('end', function() {
                fillInData(idx, str);

    function fillInData(slot, data) {
        retVals[slot] = data;
        if (countDown === 0) {

    for (var i = 0; i < countDown; i++) {
        http.get(urls[i], processResponse(i));


var urls = [ 'http://localhost:3000/something/a',
             'http://localhost:3000/something/b' ];

waitFor(urls, function(results) {

My example is not quite as flexible as what jQuery or Async.js offer, but you can see the basics of how it works. Given an array of URLs and a callback, my waitFor function will request data from all the URLs asynchronously but only call the callback when all the requests have completed. The array of data passed to the callback will be in the same order as the URLs were given. It works using a countdown latch mechanism. For each response received, the countdown in decremented. If the countdown reaches 0, all responses have come in and the callback can be called. The callback is passed an array that has been populated with each response's data. The data went in the proper array index because the index of the URL was passed along to to the function that handled the response. The only unusual thing is how the processResponse callback is given to the http.get function. Calling processResponse and passing an index actually returns an other function which is the real callback for http.get. The reason for this is to create a new closure for the index so that the response callbacks are not affected by the for loop continuing to run and incrementing the index. Without that extra function, the data from all responses almost always goes into the same position, 2, in the retVals array.

Working with lots of asynchronous functions can be confusing and frustrating sometimes. A good library like jQuery can help make it less painful. comic for September 24, 2014

Monday, September 22, 2014

When Computed Styles aren't Computed

I noticed something unexpected the other day when working with jQuery to read CSS dimension properties. Maybe everyone else in the world is already aware of this but I'll talk about it anyway.

Typically, whenever you use jQuery to read the value of a height or width property of an element, the value is always returned in pixels. You can set the value in %, px, em, cm, whatever. But it always comes back to you in pixels. It will actually be a string with "px" at the end.

Except when it's not.

I was relying on this behavior. I would grab the value, remove the "px" from the end, and turn it into a Number. But sometimes I was getting "NaN" as my value. Upon closer inspection, it turned out that I was getting a value like "82%" instead of "435px" which was throwing everything off.

Technically, jQuery is giving me what is known as the computed value of the property. Sure, sometimes getting the value in pixels is not what you want, but as long as it's consistent you can deal with it. I was encountering the problem that sometimes it was in pixels and sometimes it was the value that I set it from, which happened to be percent.

It took me a while, but I finally figured out what was going on.

When the element's parent (not the element itself) has a display value of "none," the browser can't give me the computed dimensions because it has no way to compute them. Instead, you get whatever value the CSS says.

Check out this test page I put together to demonstrate the issue.

<!doctype html>

<html lang="en">
  <meta charset="utf-8">
  <title>CSS Test</title>


  <div id="container" style="width: 400px;">
    <div id="test" style="width: 50%">test</div>


<script src=""></script>

$(function() {









Here is the console output.

As you can see, the test div has a width specified as 50% but when the value of the "width" CSS property is printed out, it is "200px". This is exactly correct, since 200px is 50% of the 400px width specified on the parent container.

After I toggle the visibility of the parent container (the jQuery .toggle() function) and print the width of the test div again, I get a value of "50%". That's what the style attribute says.

Toggle the parent container visibility again (make it visible) and you see "200px" on the console again.

Once I learned this and restored my sanity, I was able to fix my problem easily by making my elements' parent visible before I tried to read the dimensions. Originally I was trying to read them, perform some calculations, and then make the parent visible. There were no real issues with switching the order around a little in my case, but your mileage may vary. comic for September 22, 2014

Friday, September 19, 2014

Talk Like a Pirate

Today is International Talk Like a Pirate Day. In honor of this occasion, I will present a short list of  my favorite pirate words and phrases for you to use. I use some of these year-round.
  • Avast ye! means pay attention!
  • Hornswaggle means "to cheat"
  • Cackle fruit are chicken eggs
  • Blimey! is something said when one is in a state of surprise
  • Scallywag is a name that is used as an insult to someone
  • Son of a biscuit eater is another insult
That's pretty much it for today. comic for September 19, 2014

Wednesday, September 17, 2014

Simple Animation

In my web comics, I wanted to be able to take full advantage of the web as a medium. Not like the size between small and large, medium like the singular of media. Like the stuff we use to communicate.

I just wanted a simple and extensible way to make some parts of the comic cells move or change color or things of that nature. I use jQuery which has some animation features, but they are mostly geared towards the changing of CSS properties. I may want to do that sometimes, but not exclusively.

Here's what I came up with.

When I set up a type of animation on an img object, I set a few attributes on it. First, I set animated = 'true' to flag the animated images in a way that's easy to grab them using jQuery. Then I set another attribute that specifies the animation function to use. Something along the lines of animationType = 'flicker' for example. Then I set other attributes specific to that type of animation.

I might end up with some HTML like this:

    <img src="something.png" />
    <img src="frog.png" animated='true' animationType='flicker' flickerSpeed='1.5' />
    <img src="whatnot.png" />

I then have a setupAnimation function which performs the initial setup for my animated images. Here is a simplified version of what I use.

function setupAnimation() {

    window.animated = [];

    $("img[animated='true']").each(function(idx, elem) {

        var aType = $(elem).attr('animationType');

        if (aType === 'flicker') {

            // assign a function here. function must
            // be defined somewhere. we can also perform
            // any necessary initialization here.

            elem.aniFunction = flicker;

        } else if (aType === 'something else') {

            // other types can go here

        } else {

            // unknown animation type value
            elem.aniFunction = function() {
                // no op





In this function, I am basically searching for all the animated elements, setting their animation functions, and performing any initialization that may need to happen. Then I save them in an array which I can later use to find them without having to use the jQuery selector again. I call this setupAnimation function once when the page is done loading.

As you see above, when the animation type is "flicker" I set the element's animation function to be "flicker." This implies that I have a function named flicker defined somewhere. I like this simple method of assigning a method to perform a certain type of animation because it allows me to easily add new types or modify the internal workings of existing types independent of the HTML. If tomorrow I want the "flicker" animation type to use a new "flicker2" function that I make, I can do that. If I want to totally change how the "flicker" function works, I can do that too.

As a future enhancement, I could have animation types self-initialize and put themselves in a map or something so I could get rid of the if...else if...else block here. Writing code that does not contain if...else statements should be the ultimate goal of every programmer, but I prefer to keep things simple at first and then refactor to better patterns later. I know it might sound like procrastination, but it works. It's a thing I do.

Anyway, once I have the animation set up, I have to kick off some kind of animation loop.

$(function () { 

    var lastTime = null;

    function run(timestamp) {

        window.requestAnimationFrame(function(e) { run(e); });

        var elapsed;
        if (lastTime === null) {
            lastTime = timestamp;
        elapsed = timestamp - lastTime;
        lastTime = timestamp;

        animated.forEach(function (elem, idx) {


    window.requestAnimationFrame(function(e) { run(e); });


I leverage the window.requestAnimationFrame function to ensure smooth animation. The general contract of requestAnimationFrame is that it calls the given callback function and passes a really really accurate timestamp in milliseconds as the parameter. And if you want it to run again, you have to call it again from within the function that it calls. That's why I define a run function that takes the timestamp as a parameter and then call it from an anonymous function declared as the parameter for requestAnimationFrame.

In my run function, I use the timestamp argument to calculate the elapsed time since the last call, and pass that to the aniFunction of the elements in the animated array. The general contract of one of my animation handler functions is that it will receive a single argument indicating the elapsed time in milliseconds since the last call. This elapsed time value can be used to calculate how far an element should move, how much it should change color, if it should toggle its visibility, if it should change to a different image, or whatever else imaginable.

Here is my flicker animation function, so you can get an idea of what I am talking about.

function flicker(e) {

    if (typeof this.timespan === 'undefined') {
        this.timespan = -1;

    if (typeof this.counter === 'undefined') {
        this.counter = 0;

    if (this.timespan === -1) {
        // pick a new timespan value, based on speed
        this.timespan = Number($(this).attr('flickerSpeed')) * 1000 * Math.random();

    this.counter += e;
    if (this.counter > this.timespan) {
        this.timespan = -1;
        this.counter = 0;


It is a fairly simple animation that produces a flickering effect like an old fluorescent light bulb. After making sure that the timespan and counter properties are initialized, I check to see if I need to calculate a new wait time before toggling. It will be a random number between 0 and flickerSpeed seconds. In all cases, I add the current elapsed time to the total counter. If the counter is greater than the last calculated timespan, the element's visibility is toggled and timespan is set to -1 in order that a new timespan will be calculated the next time through.

It all works great, with one small catch. There are still web browsers out there that don't support the window.requestAnimationFrame function. I've found that at the very least, iOS Safari prior to version 6 does not. Since iPhones still running iOS 5 are not that uncommon, I needed to do something to provide them with animation.

The answer was to include a polyfill. A polyfill? Like pillow stuffing? Not quite. Polyfill in this context means "a piece of code that provides the technology that you, the developer, expect the browser to provide natively". That definition is from Remy Sharp, who explains the origin of the term on his blog. I basically had to check to see if the browser already had a requestAnimationFrame function defined, and if not, define it myself. The backwards-compatible solution is to use window.setTimeout and call the given callback function with a single argument representing the current timestamp in milliseconds. Here is what I use:

if ( !window.requestAnimationFrame ) {
    window.requestAnimationFrame = ( function() {

        return window.webkitRequestAnimationFrame ||
               window.mozRequestAnimationFrame ||
               window.oRequestAnimationFrame ||
               window.msRequestAnimationFrame ||
               function( callback, element ) {
                   window.setTimeout( function() { callback((new Date()).getTime()); }, 1000 / 60 );

    } )();


I originally found that in a Gist written by Paul Irish, but it didn't pass the current timestamp to the callback function. So I added that part and we're all good now. Try it on your first-generation iPad. It will work. I have one. I tried it.

And that, my friends, is how I do simple animation in my web comics. It doesn't actually seem that simple now that I've written it all up, and I even simplified it for this post. Maybe I should refactor? comic for September 17, 2014

Monday, September 15, 2014

You Don't Need Ninjas

No, you don't need ninjas.

Or rock stars.

Or yetis, or unicorns, or oscilloscopes, or whatever crazy new metaphor somebody comes up with for a software engineer with some kind of magical talent for exactly what you think you might need at this very moment.

I get frustrated when I see a job listing looking for someone with an extremely specific skill set. It's usually something trendy. Unless you were someone ahead of the trend by starting to work on Technology X years before normal people ever heard of it, you don't qualify.

This is the tool. The only tool.
The best analogy I ever heard to describe this situation is the following. Try to hire a carpenter to build you a house. But he must have 15 years of experience with Black & Decker Model #CS1014 circular saw. Sounds silly, right? You just want a guy who knows how to handle any saw or drill or whatever tool. Maybe he has a preference for a certain brand or model, but that's probably based on his experience as the guy doing the actual building. This kind of thing happens all the time for software jobs.

What ever happened to hiring competent software engineers who were capable of learning new things? People who can stay with you long-term, and use their lifetimes of knowledge to enhance any project on which they work?

I've worked projects in Pascal, C, C++, Visual Basic (I don't know why I admit this one), ASP (or this), Java, and JavaScript. I've never worked a real project in Python or Ruby, but I don't think I'm incapable of doing so. I know programming. I can probably learn any language quickly, at least well enough to be a useful contributor.

And in this environment, we supposedly have some kind of software engineer shortage. The data to support those claims are not clear, if you ask me (see here and here for starters). But if you believe there is a shortage, maybe it's because everyone has unrealistic expectations. Maybe it's really just a shortage of ninjas, rock stars, and unicorns.

But you don't really need them. Just don't hire rodeo clowns. comic for September 15, 2014