by ·0 Comments

Today I found a very weird bug in JavaScript – The date function. I never expected to see a bug in the standard JavaScript implementation. Here is my code. It does nothing more than adding 21 days on the reference date:

var referenceDateObject	= new Date(2011, 9, 10);
var deliveryDateObj 	= new Date(referenceDateObject.getTime() + 24 * 60 * 60 * 1000 * 21);
var deliveryDateMonth	= parseInt(deliveryDateObj.getUTCMonth());
var deliveryDateString	= deliveryDateObj.getUTCFullYear() + '-' + deliveryDateMonth + '-' +  deliveryDateObj.getUTCDate();
alert(deliveryDateString);

Given a reference date of September 10, 2011, I expect the date should be October 1, 2011. However, it ends up returning me September 31, which doesn’t exist!

I test that on Firefox and Google Chrome, both give the same problem. A quick fix will be moving the date calculation to the server side.

P.S. MySQL date function automatically convert 9/31 to 10/1, so the data on the server looks fine.

Update – That’s my fault. The Date object treats the month from 0-11 instead of 1-12. Here is a corrected version:

var referenceDateObject	= new Date(2011, 8, 10);   //That's September 10, 2011, not August 10.
var deliveryDateObj 	= new Date(referenceDateObject.getTime() + 24 * 60 * 60 * 1000 * 21);
var deliveryDateMonth	= parseInt(deliveryDateObj.getUTCMonth()) + 1;
var deliveryDateString	= deliveryDateObj.getUTCFullYear() + '-' + deliveryDateMonth + '-' +  deliveryDateObj.getUTCDate();
alert(deliveryDateString);

That will do the trick.

–Derrick

Our sponsors:

by ·2 Comments

I upgraded to PHP 5.3.3 today, and I was shocked! I found a huge security hole default setting change that may leak the source code to public, which never happened in the earlier version.

Here is an example. Suppose my code looks like this:

<?php

echo "This is a good example";

?>

Everything will turn out fine. Here is the result:

Good Example

However, if the open tag is changed from <?php to <?:

<?

//My comment
echo "This is a bad example";

?>

Then PHP 5.3.3 will not recognize the code within the < ? and ?> tag. Instead, it will parse it as a regular text file, i.e., your users will see the code. Here is the result:
Bad Example

I know that it happens on PHP for Windows (XAMPP for Windows), but I didn’t know that they move this new feature to Unix world.

Update:
Thanks for the help from bt garner, it is pretty simple to fill this security hole.

First, open the php.ini. If you are not sure where is it, you can run the following command to locate it:

sudo find / -name "php.ini"

And activate the following parameters:

short_open_tag = On

That’s it!

–Derrick

Our sponsors:

by ·0 Comments

Today, my co-worker found that the web-application he developed worked only in Firefox, and it didn’t work in Internet Explorer(IE). He immediately asked me if we should ignore the IE users or not.

I know that he was working on JQuery(Javascript). It is not surprised that IE does not support the standard JQuery. However, it doesn’t mean that we can simply remove our support to IE users. In fact, IE still have more than 55% of market share today, while Firefox have around 30% only.(See here for more information) It’s too early(and not responsible) to ignore such a large user group.

So, after he complained about how fxxking the IE was for an hour, I tried to find out that the problem. I found that the problem came from his code rather than from IE. He had an extra tag in his code. Firefox was so smart to catch the error and ignore it. That’s why it only worked in Firefox, but not in IE.

So, here are what I’ve learned today:

  • The error catching function introduced in Firefox is so good. But at the same time, it makes some developers lazier by not verifying the quality of their works. They will think it is your problem if you are using IE.
  • IE sucks, but it is not an excuse of leaving the IE users behind.
  • Complaining has nothing to do to improve the problem. Talk is cheap, do it.

Next time before you complain to your manager about how fxxking the IE is, think twice.

Our sponsors:

by ·0 Comments

I was experimenting the salary search engine at Indeed.com today, and I found some interesting result…

“The salaries of Shit in different locations in US”

Here is the result:

indeed-shit

Or you can try to click here to repeat the test….

What makes me couldn’t stop laughing is the statistical conclusion below…

Average shit salaries for job postings in New York, NY are 68% higher than average shit salaries for job postings in Hawaii.

Does it mean a shit worth more value in NYC than in Hawaii?

The reason why I want to put this interesting result is not for making fun on Indeed.com, but I want to understand why the QA at Indeed did not notice this bug, and why the engineer of this search engine is using such a poor algorithm? I am pretty sure NO job has the keyword “shit” in the job title! Where did the search engine get this information? How does it get these numbers?

Do you think your salary is high enough? Try to compare your salary with the result using these keywords: Unemployed and Do Nothing.

indeed-unemployed

Want to know the solution and prevent this embarrassing result? Shoot me an email and we can talk.
(It will require you sometime to find out my email but it is not that hard, huh?)

Our sponsors: