Life

The Law Enforcement Against Prohibition blog just announced that the Senate will be removing the ban that they have had in place against their voters since 1998.

In 1998, the voters of Washington D.C. voted for Initiative 59 to allow medical marijuana. This was challenged by using something known as The Barr Amendment which effectively prohibited D.C. from lowering any penalties on schedule I controlled substances. Not only did it stop the initiative from passing, it disallowed the release of the vote tally information.

Now, 11 years later, voters are finally getting what they asked for. In the FY 2010 Consolidated Appropriations Conference Report: Financial Services Summary, dated December 8th, 2009, under the “Important Policy Items” section, you can find the following:

“Removing Special Restrictions on the District of Columbia: Eliminates a prohibition on the use of local tax funds for abortion, thereby putting the District in the same position as the 50 states. Also allows the District to implement a referendum on use of marijuana for medical purposes as has been done in other states, allows use of Federal funds for needle exchange programs except in locations considered inappropriate by District authorities, and discontinues a ban on the use of funds in the bill for domestic partnership registration and benefits.”

Sounds like things are going to change in D.C. for the better.

Looks like the federal government can’t ignore medical marijuana anymore. This is a huge step in the medical cannabis and cannabis legalization movement as it forces our federal government to be faced with this issue right outside their front doors. Hopefully this will not only help the people of Washington, D.C., but also spark good conversation and reformation for draconian, damaging, and irresponsible laws that currently govern cannabis.

If you liked this post, then please consider subscribing to my feed.

Geekery

While working on a PHP project, I found myself occasionally switching between using empty() or !strlen() when I was dealing with strings. In PHP, there are often multiple solutions for the same problem and this was one of those cases. I didn’t really have a reason to use one over the other and, as most PHP developers know, you should be careful when using empty() for strings because you can run into this problem:

<?php
    // Here's a string that isn't "empty", it's zero
    $string = '0';
    if (empty($string)) {
        echo 'Oops!';
    }
?>
 
Oops!

Being that I felt capable of being careful with empty(), I wanted to know if there was any speed advantage to using it over strlen(). I wrote a little function and was very surprised by the results:

Checking "if (!strlen($string))" VS "if (empty($string))"
 
unset($string);
Average speed gain using empty() instead of strlen(): 84.62%
 
$string === false;
Average speed gain using empty() instead of strlen(): 57.25%
 
$string = '';
Average speed gain using empty() instead of strlen(): 47.02%

Repeating the test yields similar results every time. Keep in mind, we’re talking fractions of seconds here, but it all adds up. I was expecting there to be a much smaller difference in speed between the two.

Here’s the test I wrote. It’s nothing spectacular and there may be a better way to do it but it gets the job done:

<?php
function test_strlen_vs_empty($string) {
    /* We occasionally have oddities so I wanted to make them observable and count them properly so our avg is accurate */
 
    $oddities = 0;
 
    /* We want to be able to test an unset variable */
    if ($string == 'unset') {
        unset($string);
    }   
 
    /* We'll do 100 tests */
    for ($i = 0; $i < 100; $i++) {
        /* Start our first timer */
        $start_time = microtime(true);
 
        /* We want to check each function 100 times */
        for ($ii = 0; $ii < 100; $ii++) {
            /* Check if the string is empty() */
            if (empty($string)) {
            }   
        }
        /* End our first timer */
        $end_time = microtime(true);
 
        /* Calculate how long it took */
        $time_for_empty = $end_time - $start_time;
 
        /* Start our second timer */
        $start_time = microtime(true);
        for ($ii = 0; $ii < 100; $ii++) {
            /* Check if strlen() returns something equal to false */
            if (!strlen($string)) {
            }   
        }
 
        /* End our second timer */
        $end_time = microtime(true);
 
        /* Calculate how long it took */
        $time_for_strlen = $end_time - $start_time;
 
        /* If strlen() was faster (which doesn't happen often) we want to record it */
        if ($time_for_strlen < $time_for_empty) {
            $oddities++;
        } else {
            /* Otherwise, it's as normal. We want to grab a nice percentage of how much faster empty was than strlen */
            $slowers_total += round(100 - (($time_for_empty / $time_for_strlen) * 100), 2); 
        }   
    }   
    /* Output the results with an average taking into account any oddities that may have occurred */
    echo "\n" . 'Average speed gain using empty() instead of strlen(): ' . round($slowers_total / (100 - $oddities), 2) . '%';
    if ($oddities) {
        echo "\n" . 'Number of times where strlen() was actually faster: ' . $oddities;
    }   
}
 
echo "\n\n" . 'Checking "if (!strlen($string))" VS "if (empty($string))"' . "\n\n";
echo 'unset($string);';
test_strlen_vs_empty('unset');
echo "\n\n" . '$string === false;';
test_strlen_vs_empty(false);
echo "\n\n" . '$string = \'\';';
test_strlen_vs_empty('');
?>

This works by calculating how long it takes to run a check on the string 100 times using each function. It compares the times, and works out how much faster one is over the other in a percentage. This is performed 100 times. At the end, each of the 100 percentages are averaged out to discover how much faster empty() was over strlen(). We check this for three different instances of of empty strings:

  1. When the $string variable is not set
  2. When the $string variable is set to false
  3. When the $string variable is set to a string with no characters (”)

If you look at the code, you’ll see I added handling for “oddities.” Occasionally, strlen() would actually perform faster than empty(). It was random and didn’t happen on every test but it was something that I wanted to observe and properly handle so it’s in there.

So, you may be wondering, why empty() seems to be so much faster. Here is a simple explanation for you. empty() is faster…

“…because empty() is a language construct built into the Zend engine, while strlen is implemented as a standard extension function.

Conclusion: if you are careful enough with empty() you should probably try to use it over strlen() if you’re trying to squeeze all the speed you can out of your application.

If you liked this post, be sure to subscribe to my feed.

Geekery

While doing some programming I came across an interesting predicament. While I understand it’s evil to make it hard for a user to leave a page, I’m not here to argue the merits (or lack thereof) of onbeforeunload.

On a particular form, we are forcing the browser to not cache the information to avoid potential AJAX/JavaScript problems if they should leave the form and come back as browsers don’t all act the same (eg IE leaves checkboxes checked but doesn’t remember changes that have occurred to the page due to JavaScript). As such, we warn our users when they’re about to leave the order form to let them know they’ll need to fill it in again.

The function was simple enough:

window.onbeforeunload = function () {
    return "You are about to leave this order form. You will lose any information...";
}

Unfortunately, this would also be triggered if the user submitted the form which, is obviously not what we want. After searching around on the Internet I came across a simple solution that I thought I would share:

// Create a variable that can be set upon form submission
var submitFormOkay = false;
window.onbeforeunload = function () {
    if (!submitFormOkay) {
        return "You are about to leave this order form. You will lose any information...";
    }
}

Since onclick appears to register before onsubmit when clicking a submit button, we can add a little variable declaration to our submit button so that submitFormOkay will be set to true before the form submission happens:

<input type="submit" id="submit_button" onclick="submitFormOkay = true;">

Problem solved! I hope this post can help others solve the same issue in the future.

If you liked this post, then please consider subscribing to my feed.