bookmark_borderrm -rf

A short while ago, I was having problems uploading files in wordpress. It seems that it was trying to write to /tmp, even though in my php configuration the clearly specifies the upload directory to be something completely different.

During the process of basically trying to solve this issue, I decided to have a little spring clean and remove some unneccesary redundant folders from my web server directory, which is when I typed in the following:

rm -rf htdocs

Safe to say, I wasn’t very pleased with the results. Not to mention, I haven’t done any recent backups, so my lovely customized version of wordpress more or less vanished in an instant.

The good news however is that I managed to more or less get everything working again. I even took the time to upgrade to the latest version of wordpress (which even included the sidebar widget functionality, which left me with one less thing to install).

So I guess the motto of this story is: BACKUP! BACKUP! BACKUP!

Until next time…

bookmark_borderThe JavaScript Bandwagon

A few month’s ago, I decided to hop on the Javascript bandwagon. I wanted to find out what it could do, how well it could do it, and what limitations I would bump into.

What I discovered was not what I expected.

Incompatibility

First and foremost, one of the first problems one bump’s into with javascript is that all the major web browsers implement it differently. Code can work perfectly in one browser and fail miserably in another. For example:

var myList = {
tea: 1,
coffee: 2,
};

Seems perfectly fine to me. In fact, it worked fine in Firefox. However, it didn’t work in Safari, Apple’s flagship browser.The only clue in the JavaScript console I got was “SyntaxError – parse error”, which eventually led me to this solution:

var myList = {
tea: 1,
coffee: 2
};

Yes that’s right… all that fuss was over a single little comma.

Simple? Not!

After figuring that Javascript was a pretty simple c-style programming language, I thought I had it all figured out. However, after checking out Dogulas Crockford’s presentation ”The JavaScript Programming Language”, I was left a bit dumbfounded. What I thought was a simple boring run-of-the-mill scripting language was in fact a pretty extensible and interesting programming language. Neat!

Frameworks

The first time I tried writing something in JavaScript, I decided to go “all-pro” and not use any of the numerous development frameworks that have popped up over the years. This was a big mistake. After a long period of writing everything from scratch (whilst only half knowing what on earth I was doing I might add), I stumbled across the mootools framework. Selecting elements? simple. Handling events? simple. Making complex object-oriented front-end’s? simple. Having it all work in every major web browser? priceless. In fact, pretty much everything was ten times easier to work with, and solutions took less than half the time to be implemented.

Slow, yet fast, yet slow

Sadly, since JavaScript does not have a single implementation, performance varies a lot between browsers. For simple things, the difference was hardly noticeable. For more complex things though (e.g. interfacing with the WhatWG canvas), differences definitely became much more noticeable, although I would not like to speculate which browser has the fastest implementation of JavaScript as I have not done any conclusive benchmarks yet.

Single Threaded

Sadly for the most part, there is no support for threading in JavaScript. You can only do one thing at once. Whilst this is not a bad idea, it does become a little bit of a problem if you are running multiple time-out’s and intervals. Everything has to wait for its turn in line so to speak, which is pretty much bad news if you really want something to happen in X amount of time, irrespective of whatever else happens in-between… …oh well, I guess I can live with it.

Safe to say, i’ll be experimenting a bit more with JavaScript in the future.