A reader asked me if I could explain to him how to create the Bavarian flag in Illustrator. Instead of explaining this with text and images I decided to capture another screencast tutorial instead.

As usually there are probably other ways of doing this. I’m only showing one way. It basically comes down to these simple steps:

1. Draw 2 squares: 1 black and 1 white
2. Turn them into a Symbol
3. Apply Transform effect to repeat them horizontally
4. Apply Transform effect to repeat the line of squares vertically
5. Expand everything and move squares to make 1 prefect rectangle
6. Skew and resize the checkerboard (to match the Bavarian flag)

• Download the video tutorial from Xtreak (1130 x 860 pixels)
• Download the video tutorial from Vimeo (1130 x 860 pixels)

How to create a skewed checkerboard pattern in Illustrator from Veerle Pieters on Vimeo.

Maybe turning the squares into a Symbol (step 2) might not be needed if you’re expanding the squares again, but I thought I show this anyway. If you don’t expand the the Symbols and you only expand the Transform effect you can change the color of the squares in one instance by changing the color of the symbol. However, if you decide to expand all the Symbol’s instances, all squares become editable and so you can give each one of them a different color.

The Module Pattern is the use of closures to create, in essence, private functions that are only accessible by other functions created within that closure. Functions can be attached to an object and returned outside of that function call. This establishes a public API and only the functions defined within that public API will have access to those hidden functions.

The YUI blog documents this well but here is a simple example of the Module Pattern:

var ManageChildren = (function(){
    var children = [];

    return {
      addChild: function() { /* add to children array */ },
      removeChild: function() { /* remove from children array */ }
    }
 })();

In this example, the ManageChildren object will have two methods: addChild and removeChild. From outside the wrapper function, you cannot access the children array that is defined within.

After having worked with and used this pattern for some time, I now avoid it.

Debugging

When it comes to troubleshooting a particular troublesome page, I like to crank open Firebug’s console and play around willy-nilly. The ability to reshape objects lets me test theories before putting them into practice with real code. It also allows me to inspect things to make sure they’re working as they should.

Going back to that example I just showed, what if you needed to determine the length of the children array? It’s not exposed. Which means you have to insert logging code, or create a breakpoint. In either case, you’re forcing a page refresh to re-execute the code.

Now imagine this code was minified and deployed to a live server. It works locally but stopped working on a live server. How much do you feel like trying to add logging code or breakpoints? (Try adding a breakpoint to minified code in Firebug.)

Avoiding the Module Pattern makes debugging easier.

Make extending easier

Another frustration I have with it is the difficulty in being able to extend that object. You can’t just add additional functions onto it because you won’t have access to the properties defined within.

Take a look at this attempt to extend our object:

ManageChildren.getLength = function(){
    return children.length;
 }

That won’t work. Neither will this.children.length, or anything else you try, because children is a variable that’s only available to any function declared within that closure.

Aspect-oriented Programming

One other trick with JavaScript that I sometimes like to take advantage of is similar to aspect-oriented programming. While aspect-oriented programming is a deep subject, the key thing I took away from it was the ability to append code before or after a function call. It feels like an event handler. Here’s another fun example:

var oldChild = ManageChildren.addChild;
ManageChildren.addChild = function(){
    /* do what you need to */
    oldChild();
}

See what I did? I took the old function and replaced it with my own. Then I proceeded to call the old function. With the module pattern, though, I wouldn’t have access to any of those hidden properties. I could never actually add an element to the children array because it’s private.

JavaScript should be malleable

One of the features that attracts me to developing in JavaScript is the ability to manipulate objects so readily. As a result, the module pattern is something I try to avoid.