Jackson’s Blog

Today, I stumbled upon a very annoying page. It had an overlay that simply had no options to close it. I could follow the instructions on the pop-up and fill out the 5 minute survey to get to the underlying page, or simply turn off JavaScript. I did the later.

Although JavaScript functionality is pretty much assumed now and days, JavaScript can also allow pages to be VERY annoying. There are times where you need to leave it on, and there are times where it’s best for your surfing experience to leave it off.

There is a practice that I see a lot of web-based applications moving away from and that’s the practice of graceful-degradation. It’s the practice of having fall-backs in case certain technologies don’t exist. This is a practice I think all professional products should strive to have, this way, even if JavaScript is turned off, it wouldn’t prevent a user from being able to access the product. Also, these annoying pop-ups are probably one of the reasons why JavaScript might be turned off in the first place, and if advertisements starting moving towards this direction, I wouldn’t be too surprised if we see more and more javascript-disabled browsers.

In a professional setting, you’ll need at least 3 environments, a development environment, a testing environment, and the live environment (when the product gets released).

The development environment is the environment in which code gets developed. It is the scratch pad, drawing board, sandbox, and etc. The development environment is the birth place and weeding environment of good and bad code. You’ll want to have this environment to weed and destroy all the bad code before you release it into the testing environment.

The testing environment is an environment that isn’t live, it is isolated from live, but as close to being live as you can get. This is the environment where you take the code generated from the dev environment and test it one last time to ensure that the code is behaving properly before you release it out into the live environment.

The live environment is where the final product is released. Hopefully, if the code made it this far, it would be bug free.

Having at least these environment ensures that the code is somewhat thoroughly tested before being released into the live environment. Obviously, the less you test the code, the harder it is to ensure that it won’t break anything or behave in an unintentional manner. Thus, one of the worst environments to have is one where the development, testing, and live environment are the same thing. Remember, the more layers we have the more bug screening the code will go through before it goes it is shown to the public. That’s why having at least a development, a testing, and a live environment is the least a professional development environment should have.

Should we optimize the code so it loads faster, or should we cache it so that it loads faster? The question really shouldn’t be which one you should do, but in what order you should do it. To properly explain the difference, I’ll have to first clarify what I mean by code optimization and caching.

Code optimization is done by doing away with inefficient, memory, processor, and bandwidth consuming practices. While driving, can make forward 1 block, and make 3 consecutive rights, or 1 left. In this example you’re saving mileage on your car, gas, and time.

Caching is done by storing a copy of the data, and when that data is requested, the copy is used instead of re-generating the files. This applies to server result caching, browser caching, gateway caching, and etc. A non-programming example would be like coca-cola. Originally, it was hand brewed, and eventually the cola was copied, and now its machine brewed. A browser cache grabs the data from the server, copies it into a storage location, and then whenever you request that same file, it’ll access the storage location instead of grabbing it from the server.
(more…)