2009 Dice Career Fair in Seattle

Posted on March 24th, 2009 in Career, Rants | No Comments »

Fun fact: Last month I was laid off from my job at a startup, along with about half the company. Now, I’ve been sending out resumes and interviewing, and although I’ve never been to a career fair before, I figured I might as well go just in case. Why not, right? Well, I’ll tell you why not.

The thing ran from 11 AM to 3 PM, and I got there around 10:45 only to see a very long line forming. The line stretched longer and longer leading up to 11; at least 100 people were there when it opened.

As we slowly shuffled up to the registration table, I came to the realization that there were a grand total of four companies at this so-called “career fair”. FOUR. In the e-mail about the event, they had a list of companies but I thought it was a representative sample—not the entire list.

Isn’t there some agreed-upon or understood minimum number of participating companies for these things? When the entire career fair could fit inside a hotel room, as opposed to a ballroom, I think it’s time to call it quits.

The utterly depressing thing is that almost every candidate there was a middle-aged man in a suit. These are guys that have families to feed, all competing over what amounts to scraps… the desperation was pretty palpable.

Anyway, I just left.

Quick tip: Converting DMG to ISO

Posted on December 6th, 2008 in Bash, Code, Mac OS X | No Comments »

Save this as dmg2iso and run from the terminal:

#!/bin/bash

if [ -z "${1}" ]; then
    echo "Usage: ${0##*/} <file>"
    exit 1
fi

FILE=${1%.dmg}
hdiutil makehybrid ${FILE}.dmg -o ${FILE}

Zend_Search_Lucene: Not enterprise-ready

Posted on November 7th, 2008 in PHP, Zend Framework | 3 Comments »

Zend Framework has been attracting more and more attention from the PHP community lately, and while it lacks certain things (like code generation) that other frameworks (like Rails) have implemented to great effect, Zend Framework 2.0 is slowly taking shape and it looks like it will be the framework of choice for startups and enterprises alike. (Yes, it will even have code generation.)

But despite having several “enterprise-ready” components, I’ve found that one in particular is not: Zend_Search_Lucene, Zend Framework’s native PHP implementation of Apache Lucene, written in Java.

Don’t get me wrong; Zend_Search_Lucene is great for a small site or blog. However, from extensive personal experience, it is not appropriate for a site with a medium or large index. I think this should be noted upfront in the documentation.

Against my better judgment, the company I work for migrated our previous search solution to Zend_Search_Lucene. On pretty heavy-duty hardware, indexing a million documents took several hours, and searches were relatively slow. The indexing process consumed vast amounts of memory, and the indexes frequently became corrupted (using 1.5.2). A single wild card search literally brought the web server to its knees, so we disabled that feature. Memory usage was very high for searches, and as a result requests per second necessarily declined heavily as we had to reduce the number of Apache child processes.

We have since moved to Solr (a Lucene-based Java search server) and the difference is dramatic. Indexing now takes around 10 minutes and searches are lightning fast. What a difference a language makes.

Stop validating e-mail addresses

Posted on October 31st, 2008 in Rants | 2 Comments »

Because you’re doing it wrong. At least, that’s what I’ve discovered to be the case with Borders.com, JustFlowers.com, and a number of other sites.

My personal e-mail address has a .name top-level domain. Dot-name, of course, being one of the 280 (at present) valid TLDs. Your rinky-dink regular expression that checks (com|net|org|gov|mil) does not cut it.

This morning I tried to order a book from Borders. I couldn’t. They didn’t like my e-mail address. I also tried to change my password. Couldn’t.

Ultimately, I had to change my e-mail address in order to do anything. Now all of my personal e-mail goes to one address, and all the Borders mail goes to another that I use for technical mailing lists.

Look, e-mail addresses are complicated. More complicated than you think. See Phil Haack’s enlightening blog post on the subject if you don’t believe me.

Did you ever consider why you are validating e-mail addresses in the first place? It’s in the customer’s best interest for an order confirmation e-mail to get to their inbox. Why do you put two text fields to confirm an address? It’s to help prevent the user from making dumb mistakes, right? The fact is there’s no need for rigid validation—either the e-mail gets there or it doesn’t.

If you must validate, do this instead: .+@.+. That’s guaranteed to be future-proof, and people like me won’t write you ticked-off e-mails telling you to fix it. ;-)

PHP gets lambda methods, closures

Posted on September 26th, 2008 in Code, PHP | 1 Comment »

Not one month after I wrote about the future of PHP (June 2008), I was quite happily proven wrong.

For my part, I’d like to see first-class functions and closures included in the language. [...]

But none of that will happen, because PHP is a language in decline. Not a decline in usage—it will only continue to expand its reach—but in the addition of innovative features from other languages. There will be no need to evolve; most of the agitators for change will have moved on.
Me

It’s always been in my nature to own up to it when I’m proven wrong, so consider this my mea culpa. PHP has always been a klugey language, borrowing from other languages and implementing those ideas in somewhat endearingly clunky ways. I naively believed that that dynamism was coming to an end, but as you can see from the link above, that’s demonstrably not the case. Despite that, I still think there is a slow but steady “brain drain” from the ranks of the top tier of PHP developers—I’ve seen it first hand in the last few years and the overall trend should make PHP developers at least a little uncomfortable.

Anyway, the closure implementation coming in PHP 5.3 is, like namespaces, a little clunky.

function replace_in_array($search, $replacement, $array) {
    $map = function ($text) use ($search, $replacement) {
        if (strpos($text, $search) > 50) {
            return str_replace($search, $replacement, $text);
        }
        return $text;
    };
    return array_map ($map, $array);
}

Yeah, you have to manually link the variables to make them available to the closure. Not ideal, but neither is having to manually specify your scope in JavaScript (via Function.apply()).

There are a few of other differences in PHP 5.3’s implementation of closures and other languages:

  • First, like other functions, they have access to the global scope with the global keyword. Do yourself a great big favor and just avoid doing that.
  • Second, you can choose which variables are linked by reference and which are not.
  • Finally, you can declare an anonymous function static if it’s declared in a class but doesn’t use an instance of that class for anything. If you have a large object, this would prevent the closure from retaining a reference to that instance (and therefore, its memory footprint) after it has outlived its usefulness. This will probably be the least understood aspect of PHP closures for most developers.

Currying is now possible as well. Ryan Timmons wasted no time in writing a method for doing just that:

function curry($function, $argument) {
    return function() use ($function, $argument) {
        $arguments = func_get_args();
        array_unshift($arguments, $argument);
        return call_user_func_array($function, $arguments);
    };
}

Between this, namespaces, late static binding, and a bundled packaging method (ext/phar), the next version of PHP is looking more like a major release instead of a minor one.

PHP 5.3 is scheduled for final release in October [update: it's been pushed back to the end of Q1 2009].