1. Every account must have a completely unique password. In the event of one of my accounts getting compromised, I want to make sure that the problem is encapsulated to only one account.
2. Passwords should be hard to memorize by someone other than myself. If a password is revealed in written form, this prevents someone from committing it to memory.
3. There needs to be a healthy mixture of uppercase, lower case, special characters, and numbers in each password.
4. Some times, for some ridiculous reason, systems will say you can’t have special characters in a password. Our password system must account for deviations like this.
5. Last but not least, generating new passwords should be instantaneous. There should be almost no thought involved.

The trick to having each condition satisfied is to have a system. Mine is simple: combine a base “phrase” with some dynamic data unique to each account. This means I’m only required to remember the base phrase. Since every account has a location, identity, and task associated with it; these form the dynamic qualities of the password.

For example…

John Doe is married to his lovely wife Jane. He loves her very much and since he’s a geek, he even involves her into his password scheme, which looks like this: i<3jdVm which if you had to spell it out would be like “I love Jane Doe VERY much.”

Cheesy right? That’s my style. Anyway…

John now takes this scheme and incorporates it into all of his geeky accounts:

• Twitter: jdoi<3jdVmtw (assuming that the username is jdoe)
• Facebook: jooi<3jdVmfa (assuming that the username is john.doe@gmail.com)
• GMail: jooi<3jdVmgm (assuming that the username is john.doe@gmail.com)

See the pattern? <first two characters of the username> + <some base pass phrase> + <first two characters of the domain name>.

Unfortunately, this doesn’t work in all situations.

Some sites (sadly, like almost all bank sites) won’t allow special characters to be used in a password. Since John uses a non-alphanumeric character, his bank won’t let him. This is the reason for rule #4.

John decided that in this unfortunate event that he would substitute “<” with a “L” since it was the closest possible match. Unfortunately, there is no universal solution to this problem. You simply have to have a convention and stick with it. Personally, I see this as an opportunity for greater security: this is yet one more dynamic quality which can be rotated with your password scheme.

“Rinse and repeat as necessary”

Probably the most important thing to remember out of this whole thing is to change your password often. Think of it as something as important as changing your underwear (or socks if you’re not into the underwear thing). I like to set a reminder in my calendar to rotate every two months. It also helps to keep a log of all your accounts which need to be updated. If you’re smart and use a social bookmarking service, create a private bundle/set and just run through the list periodically. This process also helps me prune the accounts which I don’t use anymore, which is another good thing you should be doing.

–

This is a public service announcement from Mike G. with the intent to make the web a better place. If you liked this post, or even if didn’t like it, please share your thoughts by leaving a comment below.

I recall reading a post recently which describes factory methods as a best practice. I can’t tell you how thrilled this made me as I’ve been advocating this for years, even to the extreme view that the author used as an example: new Form().

In my most recent talk at AJAXWorld 2009, I briefly discussed the Factory Pattern as it applies to JavaScript. In my talk, I took a jump away from simple best practices and gave a real-world problem/solution approach to factories in JavaScript.

The problem: JavaScript will allow you to invoke constructor functions as normal functions.
The simplest possible solution: Use a factory method to instantiate everything.

My personal recommendation is to only use constructors internally and to never expose constructors directly.

What the hell? Why are constructors so bad?

Constructors in JavaScript are bad because of one thing, and it’s the same thing that is at the heart of almost all of JavaScript’s problems: implied global scope.

Consider the following code:

// Define our constructor function
var Person = function (name, location) {
    this.name = name;
    this.location = location;
};

// Create one instance of Person
var mike = new Person('Mike G.', 'NYC');

// Create another instance of Person
var alex = Person('Alex H.', 'NYC');

Did you spot my mistake? I omitted the new keyword while creating the second Person instance. If you run this code in any web browser, you’ll notice that the browser will redirect you immediately upon running it.

This is a big problem.

When you invoke any function with the new keyword, it treats it as a constructor and executes within the context of the newly created instance. When you invoke any function without the new keyword, it treats it as a normal function and executes within the context in which the function was defined (typically window).

With that knowledge, go back and re-read the code and tell me why the browser redirects now…

Factories save the day

The easiest way to fix this problem is to use a factory. Here’s my proposed solution:

var Person = function (name, location) {
    return (this === window)
        ? Person.factory(name, location)
        : Person.factory(name, location, this);
};

Person.factory = function (name, location, instance) {
    instance = instance || new Person;
    instance.name = name;
    instance.location = location;

    return instance;
};

One of JavaScript’s brilliant features is that Constructors can have return values. In this example, my constructor is returning the result of the Person.factory. It is Person.factory’s job to always return a proper instance and set it up properly.

Now it doesn’t matter how you invoke this constructor. You can use new or you can omit it. This is defensive code and it’s JavaScript done right.

As a small experiment, I decided to write a quick system that allows for synchronous execution of functions. In other words, a queue of functions which executes in order and only allows one component to execute at a time. My hopes are that by grouping the initialization routines into segments, the page will become more stable as the effort will be more distributed.

At first the solution sounds simple: just create an array of functions you wish to run, loop over the array and execute each function along the way.

Of course, it just doesn’t work like that. Function 0 may be complex and take much longer to execute than function 1. In this case, the order of function definition matters very little when compared to the time the function takes to execute.

If you’re stumped, I’ve posted the solution and a demonstration to the lovemikeg code repository. The breakdown works like this:

1. Like the first proposed solution, an array is used to store functions in the queue.
2. A next() method is defined which executes the next available function in the queue (if any).
3. Whenever a function is added to the queue it’s wrapped in a function which when executed defines another function passed to window.setTimeout. This inner function executes the original function and then immediately calls the next() method

It’s basic I know: There’s no prioritization… or scope overriding… or configurable parameters. This is however, a great example of the power of anonymous functions and closure in JavaScript. I’m not confident that this will translate over to other languages well, but the pattern certainly will.

Whether this turns out to be a good solution for distributing initialization effort has yet to be determined. As I learn more, I’ll update this post.

Update May 27, 2009: Looks like I’m not the only one thinking about this topic: http://cavaliere.org/async

You can find the talk’s abstract below. I’m still working on the slides so if there is anything you would like me to touch on, I’m open to suggestions.

From the Sessions page:

JavaScript has taken a lot of heat over the last few years for various reasons, one of which being it’s lack of proper object orientation. On the contrary, JavaScript is fully object-oriented, supports many types inheritance and also supports member visibility. This talk will explore the JavaScript programming language and will demonstrate several practical design patterns you can use in your JavaScript/Ajax application today.

On a somewhat related note, I really need to update my speaking bio and head shots. Any photographers in the audience?

Update: Here are the slides for those who missed out.

It’s widely known that the vast majority of JavaScript books that exist are bad. Unfortunately, I have another one to add to the list: Learning Dojo by Peter Svensson.

I fought with myself over whether or not it is a good idea to post this review. I’m afraid that this review may come across as an attack on the author, the publisher, or the reviewers of the book. Instead of looking at all of the errors in the book one-by-one, I am going to try to write an exhortatory post so I can better communicate what I would expect in any JavaScript book in this class.

To be fair, I don’t think that the blame for the book’s poor quality should be entirely on the author. From what I can gather simply from reading it, I would say this book was rushed and not properly reviewed for quality or accuracy. Also, I’m a purest when it comes to the web; so when I see [what I perceive to be] an outright dismissal of best practices, I start to get a little judgmental. Sorry, I can’t help it.

So, after over a month, I have finished reading the book cover-to-cover. I’ll admit that I part of the reason why it took me so long to get through the book was because I  lost interest about halfway through. Chapter 6, Layouts (linked below) is long, tedious and goes against nearly everything I stand for when it comes to building web pages. I simply had to keep putting the book down. Before I get ahead of myself, let me start off start off at the beginning and work our way down.

Source code should always be carefully formatted

Whenever someone asks me to critique a web site they have built, one of the first things I do is view the HTML source. If the developer has taken the time to make sure that the code indented properly and consistently spaced, I see that as someone who really cares about the quality of their project. I see it as a sign of a craftsman at work.

In the real world, this is a “nice to have” as it doesn’t really matter much — just as long as the page functions correctly, I don’t have much to complain about. In the world of tech books, however, properly formatted source code is a requirement. Remember, people learn from the source. Chances are, people will copy that down character-by-character and think that it’s the right way to do it.

Listen, JavaScript source code can be complex enough by itself. It’s an author’s responsibility to make sure that it’s as clear as possible so that good habit patterns are established from the jump. In nearly every source code listing in the book, I found something inconsistent, oddly spaced, full of errors, or simply impossible to read. This to me is completely unacceptable and was one of the first things I noticed while reading this book.

Even JavaScript books should encourage web standards

Almost every HTML document in the book was invalid. This was mainly due to the fact that Dojo itself encourages the use of custom attributes. Some may argue that there’s nothing wrong with this practice, especially when making use of a custom DOCTYPE. What’s worse is that the author made no effort to provide any alternative techniques let alone even discuss the dangers of deliberately writing invalid code. This may have been excusable ten years ago, but not in this day and age.

At the very least, I believe the author should have demonstrated an alternative technique for defining custom attributes — for example, using a combination of dojo.addOnLoad and setAttribute, or even better: not use custom attributes at all and use each respective dijit’s constructor.

eval is Evil

There is only one circumstance where the eval function should be used: parsing an Ajax response; and that’s only allowed after the response has been properly sanitized via a regular expression.

This is a concept which is well known and documented in every programming language with an eval function. Nothing further needs to be said about this.

JavaScript is deep; spend extra time on complex topics

Because I’m also working on a post where I explain closures in JavaScript, I was very pleased to see that the author had taken the time out to explain them in this book. Unfortunately, the explanation of closures in Chapter 2 left me more confused than when I had started — and I’m quite familiar with the topic.

Admittedly, the problem of JavaScript closures is two-fold: closures are incredibly abstract and secondly, almost nobody knows JavaScript’s full capabilities as a functional programming language. Source code helps to illuminate the complex topics, but a practical example should be carefully chosen. Two examples are given by the author, however one is broken and the other is completely misleading. This book is better off not even mentioning closures at all.

It also should be mentioned that your explanations should be technically correct. Let me quote the author’s explanation of how Ajax works:

In practices, what happens is that the browser opens a new iframe with zero height and width. Each iframe is capable of loading and posting data independently of each other, and so the accesses of the ‘invisible’ iframe will not affect the main page to be reloaded.

I’m not sure if the user was explaining how Dojo does Ajax or if he was trying to simplify the topic into familiar language, but the explanation is just wrong. This makes for a wonderful segue into the next, and equally important topic: proper terminology.

Never use improper terminology — ever

Programming is as much of a science as it is an art form, and as a result any sort of educational material should make use of proper terminology. In areas of introducing new concepts, it’s quite acceptable to use an analogy or reference another topic in order to build a frame of reference. For example, the author likens JavaScript objects to associative arrays. This is great because the name/value structure of objects in JavaScript are very similar to associative arrays; however, they are not the same thing. All throughout the book, the author uses the term “associative array” when he really means “use an object-literal as an associative array.”

In other instances, the terms “parameter”, “property”, and “attribute” are used interchangeably when referring to HTML attributes. Switching up vocabulary is just as dangerous as using incorrect terminology. Why? Because it makes you sound like you don’t know what you’re talking about. This is really bad when the people you teach start parroting this back.

Concluding Thoughts

There you have it, five simple things to keep in mind while reading this book or while attempting to write your own. I’ll say it again, I don’t want to attack anyone involved in the publishing of this book. That said, I won’t apologize for my response. The above mentioned topics are basic and there is simply no excuse for them to have slipped through the cracks.

At the time of this writing, absolutely no errata has been published for this book. This only adds to the reasons why I simply cannot recommend this book anyone, regardless skill level.

Believe it or not, I’m actually looking forward to this book as Dojo is one of the few libraries that I haven’t spent a great deal of time with. I’m certainly a fan of component libraries like Dojo, YUI, Prototype (YUI being my favorite) so at least the territory is familiar. I do remember there being a few things about the library that were immediate turn-offs to me, but seeing a few best practices mentioned in the book (that’s the secret to my heart, by the way) and also after the Dojo + Zend partnership announcement of last year, I think giving the library a second try is in order.

Chapter Summary

1. Introduction to Dojo
2. Useful JavaScript and Dojo Tricks
3. Basic Dijit Knowledge
4. Ajax Communication
5. Forms
6. Layout (PDF)
7. Data, Trees, and Grids
8. Real-World Dojo

The book itself seems to offer a pretty good introduction to the library (and JavaScript too). Check out the table of contents and see for yourself.

I will say this though: 2008 was an incredible year. Here are some quick notes to myself that I intend to keep in mind for this new year (listed in order of importance):

1. I worked entirely too much. Life is too short to spend all my time working for someone else’s profit. I need to have more Mike G. Time.
2. I hate front-end. It’s true. I admit it. Front end web development sucks and I think that it always will. I need to move on.
3. I miss PHP dearly. I spent way too much time focusing on JavaScript.
4. I don’t write enough. In 2007 I published 49 posts. In 2008 I published only 15 (see note 1 for an explanation why).
5. Longboarding is therapy. There is something incredible about catching a natural rhythm of carving back and forth along a nice smooth path.
6. JavaScript is beautiful but I need to give it a rest. In 2007 I fell in love with it. In 2008 it turned into an obsession.

With all this in mind, I am confident that 2009 will be an even greater year than 2008. The goals that I’ve set for this year are quite ambitious, but that’s just my nature. I have no doubt that I will be able to accomplish most, if not all long before the end of the year.

Health

I really plumped up at the end of 2007 and I continued to swell until around October of 2008 (that’s when I got my gym membership). It’s incredible how easy it is to let yourself go and not pay any attention to the food you ingest or the amount of exercise you get (or don’t get, in my situation). I’m happy to say that I am already much more aware of my health and will continue to improve as long as I am able.

This year I will:

• Improve my diet by learning to cook at home more and eat out less.
• Get to bed early so I can wake up early and go to the gym before work.
• Become more agile and increase my endurance by adding cardio to my workout.
• Become more flexible by stretching before, during, and after my workouts.

Finances

I have always been terrible at managing money. If I see something I want, I buy it… even if I know it’s on an impulse. I firmly believe that making a lot of money entitles one self to enjoy their hard-earned money, but balance and moderation are always the best choice.

This year I will:

• Invest heavily and diversify my portfolio by adding more non-tech securities.
• Start planning for retirement by contributing more aggressively to my 401K.
• Learn to save my money by analyzing spending patterns and eliminating frivolous, wasteful spending.

Work

I take my work very seriously, almost to a fault (see point 1 again in my 2008 notes). This year I will enable myself to work less by focusing a lot of effort in optimizing my team’s workflow. Of course this will not just help me, but will also help anyone else who puts the effort forth to achieve these goals.

This year my team and I will:

• Eliminate thrashing by raising overall awareness levels (IE: killing autopilot).
• Introduce architecture by treating all projects (big and small) like actual software development.

Personal

This past year I felt like I hadn’t really accomplished anything. I didn’t launch any new sites or announce any new projects in my list. Starting this year I won’t let that happen again.

This year I will:

• Improve my writing by blogging once per week.
• Begin organizing regular Refresh NYC meetings (Note: this has already begun so stay tuned for details).
• Attend more conferences as a speaker by actually submitting proposals to CFP’s (instead of waiting for opportunities to find me).

So there you have it. Like I said, I don’t have any problem saying that I can accomplish all of these. I hope that everyone else out there has done themselves a favor by conducting a personal retrospective like this. With that knowledge you can really see areas of your life which need improving. Setting goals (even ambitious ones) also really help motivate people to improve themselves and their quality of life.

Happy 2009 everyone.

Some people would be completely satisfied hiring the first buzzword-emitting person who makes a good cultural fit. I however, don’t share the same sentiments. I like to make sure that the people who I work with, and share code with, are going to do a good job. I will be the first to admit that there is a great deal of inherited technical debt that I’m trying to work through (as is the case with most people in my position), and I am certainly not trying to create any more. By creating an entrance exam, companies like the one I work for can, at the very least, insure that the people that they hire are able to perform the tasks in which they were tested.

The Format

The first time I ever experienced an entrance exam was at Yahoo! when I was shooting for a Front-end Engineer position back in 2006. This began by a series of Engineers calling me up and asking me technical questions to get a feel for how much I actually know. After a few days of this, I was flown out to Sunnyvale, CA where I continued my interviews in person. I met with several different teams of people, each of which asked me questions testing my knowledge in XHTML, CSS, JavaScript, PHP, standards, semantics, accessibility, and so on.

My company’s core competencies don’t match that of Yahoo’s, so I can’t quite implement the same tests; I can, however, implement a format similar to theirs. At MCD, candidates are given a 15 to 20 minute phone interview to find out whether or not they can keep a conversation going about the web. I also ask them questions pertinent to the level of developer they are applying for (Developer, Sr. Developer, etc.). Generally questions cover XHTML, CSS, and JavaScript at the minimum, but I always taylor the conversation since obviously no two candidates are the same.

After the phone interview, if the candidate proved him or herself, I arrange for them to come in for an in-person interview. During this interview, we of course go through the normal motions of a traditional interview, but we also administer a practical exam. I won’t disclose the details of the exam, but I will say that they are required to demonstrate their skills at solving common XHTML, CSS, and JavaScript problems.

Feedback… Please.

I’m curious if anyone has created a professional entrance exam for their company, or maybe even been on the receiving end. We are in the process of refining the tests to better hone in on the tasks that each developer level is expected to perform.

What are your thoughts? Is this a good format? What would you do if you were tasked with something similar?

For those of you who missed it, you can view it on SlideShare or download the PDF. Since the majority of the slides are code, you would probably be better off just downloading the PDF with my presenter notes.

Overall, the conference went really well. Since I had never been to a Sys-Con event before, I didn’t know quite what to expect. If I had to compare it with previous conferences I’ve attended, I would say that this was definitely one of the better ones; they really know how to put on a good show. There were lots of really smart geeks, lots interesting talks and yes even a fair share of interesting product demos. Normally, I’m not one to pay attention to vendors taking up valuable podium time, but I’ll admit that there were some really awesome products that I saw first-hand.

I do have one regret though: not attending Billy Hoffman’s Ajax Security Bootcamp sooner. I walked in about half-way through and only caught the tail-end of it. Billy was youthful, energetic and too smart for his own good (maybe that’s why he’s so into security). If you ask me, his workshop was the best out of them all.

I also got to see Douglas Crockford speak live for the first time. That was pretty amazing too. Granted, it was a talk I had already seen before (and I also read the book too), but it’s a completely different experience hearing and seeing it right before you.

I’m not sure when or where AjaxWorld will appear next, but I’m hoping it will be in NYC like it was earlier this year. There is a SOAWorld that I’ll be submitting my long-awaited Consuming Web Services in JavaScript talk to.

We shall see.

The Lazy Function Definition pattern was discovered and named by Peter Michaux.

Motivation

Generally there are two main reasons for wanting to defer defining functions until a later time (although with any pattern, many other applications exist):

1. Resources required for a function to be fully defined are not available until the page fully loads or until a user-driven event (for example, determining page scroll).
2. The resources created by defining the function are particularly taxing and may not even be needed (for example attaching event handlers).

Implementation

The Lazy Function Definition solves these problems by defining resources upon the first invocation of the function and then redefining itself so that they are not recreated during subsequent calls. All resources are stored via closure so they remain available to the inner function (which becomes the new definition for the outer function).

var getResource = function () {
    var resource, counter;

    resource = 'foo';
    counter = 0;

    getResource = function () {
        return resource + ' has been accessed ' + (++counter) + ' times';
    };

    return getResource();
};

In the code above, a getResource function is defined. When the function is called the first time, resource and counter are created to store important information which is needed in future calls to getResource.

The function which immediately follows redefines the original getResource function, but because resource resource and counter are defined in the same scope as the inner function, they remain available.

Finally, the new getResource is executed and it’s value is returned. Now any future calls to getResource will use the inner function.

Conclusion

The Lazy Function Definition pattern allows for deferred function definition as well as insuring that resources that only need to be created once, are created once.

• Sunday: Self-invocation
• Monday: Load Time Configuration
• Tuesday: The Module
• Wednesday: Lazy Function Definition