If you are programming in JavaScript, the odds are that you come from C/C++/Java background and have been bitten by the web development bug. This might cause a couple of problems however, mostly because JavaScript is "Lisp in C's Clothing". So you might find yourself a little disoriented with the familiar syntax and sometimes very unintuitive execution. One thing that is not quite so easy to understand is the fact that functions are first class in JavaScript and that they do create closures. Couple that with lexical scoping and you can get some really unexpected results.
Connected to the concept of functions being first class is the notion of variable hoisting. Dictionary definition of "hoisting" is lifting or raising something up. And this exactly what JavaScript engines do. Any variable that is declared (be it initialized to a primitive data type, an object or even a method) anywhere in a function will actually be run as if they are declared in the beginning of that function. That is, they are raised to the top of the scope they are in. Initializations for that variable will not run however, since this is not what you normally expect, and because it would have caused rather unexpected run time peculiarities.
Consider the following JavaScript snippet:
function foo() {
// Some other stuff.
// blah blah blah
if (false) {
var myVar = "bar";
}
alert(myVar);
}
foo();
When you run above code, you will get an alert box with "undefined" in it. Even though what's inside the "if" conditional is not executed, the variable is nevertheless declared in the beginning of the function. So, in effect, the above code is equivalent to:
function foo() {
var myVar;
// Some other stuff.
// blah blah blah
if (false) {
myVar = "bar";
}
alert(myVar);
}
foo();
Note how the variable is taken and declared at the top while the initialization is left where it was.
But wait, there's more. Since the condition for the "if" is never true, execution does not enter inside the block, and thus it doesn't matter where it is placed in our function. Thus, below is equivalent to the two code fragments above:
function foo() {
// Some other stuff.
// blah blah blah
alert(myVar);
if (false) {
var myVar = "bar";
}
}
foo();
Contrast above executions with the below where you'll get a ReferenceError exception because myVar has not been declared.
function foo() {
// Some other stuff.
// blah blah blah
/
if (false) {
var myVar = "bar";
}
/
alert(myVar);
}
foo();
Variable hoisting is actually quite logical when you think about it, but you have to get into the mindset of functional programming. And because of such properties, variable hoisting is asked a lot on JavaScript quizzes found on the web.
I have to admit that the above example does not seem very likely in any code, but believe me you will one day come across it if you start coding complex JavaScript applications. When you do find yourself with bugs caused by hoisting, you might also understand the reason behind the coding convention where all variables are declared at the top of the scope, even if they are used at the very bottom. Don't be afraid though, JavaScript is still a beautiful language, if you try to understand it and use "the good parts".
I recently found out that the directory we kept PHP session files had more than 2 million files. Now that's a lot of files and even though it is less than ~55 million maximum allowed on a typical linux system, we had to act fast. On Linux boxes number of files allowed is determined by the number of inodes and this can be viewed with the following command:
$ df -i
Which will give you number of inodes you are using and how much more you can use.
I went through PHP documents on sessions and checked our PHP configuration file php.ini. It turns out that Debian systems does not want PHP to do its garbage collection itself and tries to remove old sessions using a simple cron job. The problem was we were using another directory for storing sessions and not the default "/var/lib/php5". So PHP wasn't removing old sessions because "session.gc_probability" was set to 0 by Debian and Debian cron job wasn't removing these sessions because the sessions were not in their default location. We enabled PHP's garbage collector and modified the cron job so that it uses the correct folder now. Now we have two checks in place for removing old sessions.
This is something to keep in mind if you find yourself with a lot of session files. Hope this helps others.
If you look at trends in software, you see a macabre parody of Moore's Law. The expense of giant software projects, the rate at which they fall behind schedule as they expand, the rate at which large projects fail and must be abandoned, and the monetary losses due to unpredicted software problems are all increasing precipitously. Of all the things you can spend a lot of money on, the only things you expect to fail frequently are software and medicine. That's not a coincidence, since they are the two most complex technologies we try to make as a society. Still, the case of software seems somehow less forgivable, because intuitively it seems that as complicated as it's gotten lately, it still exists at a much lower order of tangledness than biology. Since we make it ourselves, we ought to be able to know how to engineer it so it doesn't get quite so confusing.
From the book Dreaming in Code, quote by Jaron Lanier.
... One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.
From Tony Hoare's Turing Award speech (emphasis mine).
I have lost sometime trying to solve these errors so I better document it here. So, if you are running phpunit but getting errors of the sort:
PHP Fatal error: Cannot redeclare class Config in /opt/local/lib/php/PEAR/Config.php on line 44
PHP Stack trace:
PHP 1. {main}() /opt/local/lib/php/bin/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /opt/local/lib/php/bin/phpunit:52
...
Then you can get rid of this error by simply deleting the Config.php file inside the PEAR directory. Config library inside PEAR directory is not up to date it seems, with many deprecation warnings also being shown. After you remove the Config.php file everything should be good to go.
On an unrelated note, "php --ini" shows you the ini files used by php and "php --ri xdebug" for example shows you information about the xdebug module. These commands are indispensable if you are trying to troubleshoot your php problems.