A basic level of understanding for JavaScript includes:

• Knowing the syntax of basic programming tools such as loops, if statements, try/catch, etc.
• Understanding function definitions including the various ways they can be defined and assigned, as well as anonymous functions
• Understanding basic scope principles, global (window) scope versus object scope (closures excluded)
• Understanding the role of context and the use of the ‘this’ variable
• Understanding the different ways to instantiate and declare an object as well as functions as objects
• Understanding JavaScript comparison operators like ‘<', '>‘, ‘==’, ‘===’, what is falsy, and how object and string comparison works, as well as casting
• Array indexing for object attributes and functions and how this differs from actual arrays (object literals vs. array literals)

An intermediate level of understanding includes:

• Understanding timers, how they work, and when/how they can be useful as well as asynchronous method execution
• In depth knowledge on callbacks and function application such as the ‘call’ and ‘apply’ methods for controlling context and function argument passing
• Understanding JSON notation and the ‘eval’ function
• Understanding closures, how they affect the performance of your code, and how they can be used to create private variables, along with the lovely (function(){})() call
• AJAX and object serialization

An advanced level of understanding includes:

• Understanding a methods ‘arguments’ variable and how it can be used to overload functions through arguments.length and make recursive calls through arguments.callee. It should be noted that use of arguments.callee can be dangerous as ECMAScript 5 Strict Mode doesn’t support it, although both jQuery (up to 1.4) and Dojo take advantage of it.
• Advanced closures such as self-memoizing functions, currying, and partially applied functions
• Function and html prototyping, the prototype chain, and how to use base JavaScript objects and functions (e.g. Array) to minimize coding
• Object type and the use of instanceof and typeof
• Regular expressions and expression compiling
• With statements and why you shouldn’t use them
• The most difficult part of all, knowing how to tie all these tools together into clean, robust, fast, maintainable, and cross browser compatible code.

-Michael Woloszynowicz

I also recently started using TextMate for a lot of my development work, and I needed it to do the syntax highlighting for LESS, so I found this LESS TextMate Bundle on Github that does the highlighting, but also has a nice built-in command that automatically converts the .less file you’re working on every time you save it. Unfortunately the bundle is really out of date (I think the last commit was from mid-2010 or so), so that save command didn’t work anymore. Since the command is just a script that gets run when you hit Command-S, and I thought it would come in handy, I decided to just open up the bundle and fix it myself.

You can download and use my modified TextMate LESS Bundle on Github. It requires you to have the LESS node package installed, and it just converts the .less file into an identically named .css file in the same folder. I like it means I don’t need to have Less.app running, and more free memory is always a good thing. Hopefully, you’ll find it useful.

As you can see, I have the three sorting functions there. Then an array literal that contains a few object literals with some common keys that I’ll be sorting by. The output to the console is where the action is though. When I was looking it in Safari, the output was exactly the same in for all of the console.log statements. No matter what the sort function, the array of objects was always output in the same order. But when I looked at it in Firebug, the sorting functions were doing exactly as expected. Has anyone ever come across this behavior before? Is there something I’m missing? Let me know on twitter

It looks like I’m definitely not the first one to notice this. Guess I should look for the bug someone may have filed about this issue.

So while I was trying to figure out a way that would allow me to organize my projects independently of what MAMP requires, I came across an article about using Virtual Hosts in MAMP. That essentially solved my problem, so that now I can put the root folder for each project wherever I want and just use *.local in my browser.

Of course at that point I start thinking that, since this is something I’ll likely be using pretty often, I should probably find a way to automate it. You know what that means? That’s right, Shell Scripting! I probably haven’t even tried to touch a shell script in at least 10 years, so this one took me a few hours. It could definitely use some more love, but since it’s already working for me, I may not touch it much, for fear that it will blow up. Right now it takes the domain name (without the .local part) and the file path to the root directory of the site, it’ll back up the /etc/hosts and the MAMP httpd.conf files first before writing to them, and make the necessary additions.

I figured I’d put it up on Github just in case someone else may find it useful. Of course YMMV, since you’ll need to modify a few parts to run on your own system. You’ll also need to use sudo, since root access is required to make changes to /etc/hosts/. I saved it into /usr/local/bin because that just seemed the simplest way to go. Enjoy, suggest improvements, and please let me know if it works for you.