Since my last post I’ve learned…

I’ve been busy, and living means learning, so what have I been learning? Among other things, I attended a lecture on Planned Serendipity that got me thinking about all the ways information from various times and places suddenly clicks. Let’s see what happens if I throw it all down here and then look for the connections…

in the “careful what you wish for department: at work, a project we shelved in April because it will be superseded by another initiative this coming spring was resurrected. I was glad powers that be recognized the added value of getting the information to the public in spite of impending changes (mainly to layout and branding), yet at the same time it’s changing horses yet again, the stream unmistakably forming rapids just ahead!

Back in April I was about to add fully ARIA-compliant keyboard accessibility to my multilingual elearning interface. I had identified an excellent, fully object-oriented methods-based model for a template at the OpenAjax Alliance‘s examples page, but concluded that I’d either have to re-write their code or mine in order to integrate it. Picking up from there with only weeks until a public reveal I’ve opted for a devil I know… I’m writing my own behaviors on top of everything in a way I won’t have to tamper with anything that already works. Everything I’m learning about key clicks will need a post of its own, but a Google search led me to see something new in a place I’d been many times before, which led me — serendipitously — to solve a problem I wasn’t thinking about when I Googled.

From this department I learned: – Sometimes things really do come back off the shelf. Be prepared. –  There may be an analogy between the serendipity of human networks and the serendipity of connections within bodies of information. – I’m consistently able to get useful results in the first few results using Google, and I think many of the sites I already visit may rise to the top of Google results because they consistently give useful information. – How Focus and tab key navigation work, and also how long 2 years is in the tech world.

In the seemed like a good idea at the time department: The way I write code leaves plenty of room to ” Step back, look at your code, and DRY things up a bit!” as Ben Alman wrote in an article I found by Googling for examples of jQuery code related to keystrokes. (This is not the first I’ve heard of “Cowboy” Ben Alman. If you have even a faint interest in JavaScript you need to follow @cowboy, bookmark his web site, discover his plugins, …and help support his work when you use them!). “DRY” in this case means “Don’t Repeat Yourself.” One effort I made even before reading this particular article was to try to condense some debugging code. Programmers need to keep track of variables as they write code.  As many surely have done, I once relied very heavilyon the alert('myVariable currently = '+myVariable); method of debugging.  Using Firefox and Firebug you can write messages to a console, but if you then look at the code in a browser with no console you get an error. To prevent that I would write

if ( window.console && window.console.log ) {  window.console.log('myVariable currently = '+myVariable)  } /* if ( someConditionIsTrue ){ Do something. } */

That prevents popups and errors, but it’s not much of a time or space saver. I eventually began to make it a habit to add three variables to every script I work on, right at the top to make them globally available…

var DEBUG=true, LOGREADY = (window.console && window.console.log), myLog = LOGREADY ?  window.console.log : null ;

With those up top, what I had before becomes  if ( LOGREADY) {  myLog('myVariable currently = ' + myVariable)  }and you can turn it completely off by setting DEBUG = false in one place at the top of the script.

What wasn’t the best idea, as it turned out, was to try to assign the built-in alert function as a fallback. Instead of the above I tried myLog = LOGREADY ?  window.console.log : window.alert() ;  That means “if the log is ready use the window.console.log method to write to the console, but otherwise use the alert method to make a popup. It actually worked in Firefox and IE. But it crashed Chrome.  I temporarily wrapped it in a try{} catch(){}, which effectively turned it off in Chrome. In emergencies with deadlines I’ll ask for help, but as long as it wasn’t crashing it was no  emergency, and I always feel more in control when I figure it out for myself.  Today I took a look. My intuition said it was something about appropriating one global function to create another, and I vaguely recalled Douglas Crocker explaining that JavaScript’s loose declaration style could be a blessing and a curse [video]. I haven’t actually consulted with the gurus, but I made sure my function looks like a function and now it works in Chrome.


var DEBUG=true, LOGREADY = (window.console && window.console.log),
myLog = function(entry){ if (DEBUG && LOGREADY) { window.console.log(entry) } else if (DEBUG) { alert(entry) } } ;

myLog is now explicitly a function, you have to pass it an entry like so:

notVariables = ', but not variables,'; /* setting up a variable to make a point below*/
myLog("Wrap all text in quotes" + notVariables + " nor numbers like " + -5 + ", " + 0 + ", or "+ 13 + ".") ; /* plus signs are needed to string strings together.  Fancy word for it: concatenation   */

which prints out as: “Wrap all text in quotes, but not variables, nor numbers like -5, 0, or 13.”

…and, if you have DEBUG set to true and the condition tested and stored in LOGREADY was true when it tested for the presence of those features, it will print the entry you sent it to the console—otherwise it will pop up an alert.

This makes it important to set DEBUG to false again before uploading the code to a live server, but at the right stage in development it could be useful to open another browser or computer and quickly check a variable.  If the alerts are just too  much remove ” else { alert(entry) } “. You’ll want to leave the other side wrapped in the if (){ ... }. That way if DEBUG is false or the browser lacks the console logging feature the implicit ” else ” is to do nothing.

From this department I learned – not to assume Safari, Chrome, Firefox, and IE all handle the newer features in compatible ways… in some ways just a lesson re-learned, but I think I’m now able to discern between “it crashed” and “it crashed because the browsers use different error handling (and apparently Firefox’s and IE’s are better than Chrome’s in this case!))” and if I’m right I’ve connected it to the “loose” nature of the JavaScript language itself, a piece of information that has been floating about in my mind for some years..

*   ———    *

* Published early. Was that a happy accident? I’m going to leave it and keep working on it.

My idea is to link the learning from each “department” to 1 or more level according to the SOLO taxonomy

1 Pre-structural: here students are simply acquiring bits of unconnected information, which have no organisation and make no sense.
2 Unistructural: simple and obvious connections are made, but their significance is not grasped.
3 Multistructural: a number of connections may be made, but the meta-connections between them are missed, as is their significance for the whole.
4 Relational level: the student is now able to appreciate the significance of the parts in relation to the whole.
5 At the extended abstract level, the student is making connections not only within the given subject area, but also beyond it, able to generalise and transfer the principles and ideas underlying the specific instance.

Read more: SOLO taxonomy (Under Creative Commons License: Attribution Non-Commercial No Derivatives)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: