Tag Archive: JavaScript


You are good enough

continous improvementKaizen. It’s a word that  I learned a long time ago. One that I have tried to apply every single day.

“Japanese for “improvement” or “change for the better”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, supporting business processes, and management” – Wikipedia

With regard to programming, continuous improvement is the name of the game. There are tons of libraries coming out that for me, can get a bit overwhelming. It can sometimes feel that if you don’t know about X library/framework, you will fall off into the blackest hole of the universe and have “everyone” ahead of you. It’s especially painful when you are doing your best and some eight year old is developing software you only wish you could.

It’s ok, you are good enough and will only get better (if you want to).

If you do any form of programming development, kudos to you. This field is not easy. There are some incredible minds out there that continue to blow my mind with what they put out. This does not dissuade me from crafting my art, it only inspires the limitless opportunities of what is possible – what I can make possible.

We are all students. There is always an opportunity for to learn something new and/or strengthen our current abilities. For me, having the student mentality keeps me on my toes and allows me to be humble. Sure, there are “experts” out there that everyone respects. They’re “internet famous”, have tons of followers and are considered the top in their field. I have much respect for their accomplishments. That being said, they were once also considered a “novice”.

We all start out sucking (literally). Then we get better. Then some of us are satisfied just to get a paycheck.

Then there are those who want to improve, no matter what level they are in their field.

That’s where I am, and that’s where I think all developers should be. Keep your mind fresh and your head high. The world is at your fingertips.

Advertisements

Super geek Paul Irish posted an excellent video about his finding from the (not so) magical, jQuery source. If you have yet to indulge yourself in syntactical art, take a look at the source: bit.ly/jqsource, it’s not as scary as you think it is. Among the amazing things he goes over, I found the setInterval “loop” the coolest.

There are two JavaScript functions that are usually grouped together when doing anything with timing: setInterval and setTimeout. As their name suggests, setInterval executes a piece of code in intervals. setTimeout excecutes a piece of code after a certain amount of time. Each one is pretty awesome in it’s own right, however the way you use it can really bring out it’s true awesomeness. Thankfully, they use the same code format:

setTimeout(function(){alert("POW!")}, 1000);

setInterval(function(){alert("BANG!")}, 1000);

Each function takes two parameters (code, delay).
NOTE: The delay is in milliseconds, so  5 seconds = 5000.

Oftentimes, it’s necessary to execute a piece of code repeatedly. For example, lets say that in order for your application to start, you need to make sure that the application is connected to the Internet. You want to check more than once because the user may be having connection issues; their connection may not be immediately available when they start your app, but rather it may take about 5 seconds for a valid connection to establish.

You can use setInterval() to continuously check the connection every millisecond. Once a connection is established, your app can run. You could use setInterval(). Or, your can be a Badass Super Power Ninja and check this Zef knowledge Paul drops.

Let’s say that you want to use setInterval to perform some action at an interval (hence the name!). What if the function you want to execute takes longer than your interval? Take this awful example as an example:

setInterval(function(){
alert('yayQuery!');
}, 500);

For arguments sake, lets say that this alert will take over 3 seconds. This means that every half second your function will execute. But if your alert takes 3 seconds… the interval is set for every half second… what is an engine to do?? Crash, thats what (,,,will happen, eventually). Now what?

Use setTimeout recursively like so:

function beAwesome(){
alert("I am awesome");
}
(function doIt(){
beAwesome();
setTimeout(doIt, 500);
})();

Let’s break this down:

We first have  beAwesome(),a function that I want to continuously run in an interval. I then have a self invoking function (a function that immediately runs) that calls my beAwesome() function. After half a second, it calls itself (doIt()) to do it (execute) all over again.

The beauty about this technique is that no matter how long beAwesome() takes to execute, it won’t fudge up your process. Since it’s a linear execution, within the doIt() function, beAwesome() is called and executed. AFTER it’s done doing what it needs to do (which might take longer than half a second), it then calls it’s parent (doIt()) to rerun the code again.

Make sense? Of course it does!

For your brain:

I recently purchased (yes, I actually paid for it) a group of ebooks from extraordinary devs Amy Hoy and Thomas Fuchs (creator of script.aculo.us). These books come jam packed with JavaScript goodness. It’s written very well, even for those who hate reading. The authors make learning about JavaScript entertaining as well as informative.

This isn’t a book to learn JavaScript; it’s about JS performance and how you can get the most out of your code. Let’s face it, JavaScript is becoming more and more popular everyday. It’s everywhere. It’s on this site, it’s in your email client, it’s probably in your toaster. If you think you are a pretty decent JavaScript developer, you are probably wrong; there is always room for improvement (always).

Not only do you get four (yes, 1,2,3,4) action packed ebooks with priceless content, you also get the infamous DOM MONSTER! (muhahahahahha!!!). It’s a DOM inspector tool that you can add as a bookmarklet and call to any page. It works on all major browsers and provides extremely helpful hints on your mark up. Sure, I can post it here, but that’s just not cool. Get your own copy! It’s $39.99, don’t be a cheapo.

Finally, the best part about this awesome package is the goodies! What JS book would be complete without code examples? Your copy will come with a goodies folder that has everything you need to kick ass (figuratively).

I haven’t gone through all of the material yet, but from what I have so far, it’s pretty damn epic. There are jokes, code examples, and pretty pictures – what more can a lazy reader ask for?! They have seriously made learning fun again. I highly recommend you pick up a copy at javascriptrocks.com.

Do it, or a kitten will die. It’s true.

Closure is a simple concept that tends to be overly explained. You like keeping things simple and organized, right? (Nod). Good. Now keep your variables within it’s respective code block and everything will be all right.

Exciting things can happen within blocks of code. From validating form data to making unicorns pop out of nowhere, blocks of code can be awesome. But if you piss off code blocks by introducing unwanted global variables, then it’s gonna kick your ass and step on your shoes.

Code blocks in JavaScript are defined by a set of opening and closing curly braces {//where the magic happens}. Variables defined within these braces (using reserved word var) live privately within block; they can only be modified by code within the current and child code blocks.
Let’s look at the following:

var wack_mc = "Yo yo. A-yo check it. Yo.";
var you_cant_touch_this = function(){

var hammer = "Yo, I told you. You can't touch this.";
alert(hammer);

}(); // The parenthesis here invokes (or calls) the function immediately.
// You can alternatively call this function by using: you_cant_touch_this();

There are three variables defined:

  1. wack_mc : Implied global variable of type string
  2. you_cant_touch_this : A typeof function variable
  3. hammer : a string variable that is enclosed within the you_cant_touch_this code block

Sounds simple…

It is. Now lets say you had the cojones to actually step up hammer and kick a flow; change the value of the hammer variable by overwriting it with your own value. Now that’s gangsta.

hammer = "Your rhymes are so wack, I'm bout to have a heart-attack!";

If you were to put the code above outside of the you_cant_touch_this block, nothing would happen; the value of hammer will not be altered because it is defined within  the warm and snugly closure of the you_cant_touch_this function. Because you_cant_touch_this is a function variable, you can use the braces required for functions to define variables that can be hidden from code outside the function code block.

At this point hammer is very upset. He can’t believe that someone would actually try to step to him with such atrocity. This is what he did:

wack_mc = "If you can't groove to this, then you're probably dead.";

Guess what happens. Yeah, that’s right. wack_mc had his ass handed to him by hammer. The wack_mc variable was altered because it wasn’t wrapped in the braces of closure. If this was the only code provided, it is implied that the wack_mc variable can be globally accessed by other code in the application, thus being susceptible to getting overwritten by code after it’s declaration assignment.

Using closure in your applications will not only make it easy to read and understand, it is the safest way to ensure that your variables do what you intend on them doing: being awesome.