I feel like a teenage girl the way I can’t make up my mind lately. First I post an article on why the Droid X sucks, then I post an article on why I bought it anyway, and now I’m posting an article announcing that I returned it on the 30th day of ownership. So why did I return it? Simple: Motorola is a dick.

I already talked about the encrypted bootloader and the eFuse, which are meant to cripple the device if anyone tries to load any unauthorized firmware on it. This pissed me off, but I bought it anyway. But Motorola keeps throwing shit in the face of Android enthusiasts who want to push their device to the limit and help improve the Android operating system.

Recently, a leaked image of the Android 2.2 update found it’s way onto the web, and immediately Motorola launched a cease and desist and take down requests on the leaked image. Today they’ve announced that anyone who has applied that update is screwed, and will no longer receive any OTA updates to their device.

You might be thinking: it’s their choice how their software is used and applied. But it’s my device, and once I own it, I should be able to flash any custom firmware on it I want. Because I bought it. I don’t care if the carrier offset the cost by me signing a two year contract; I own it.

Compare Motorola’s policies with HTC, who was in a similar situation: a leaked 2.2 update was installed on an unknown number of devices, and when the official update hit, those devices were unable to update. HTC posted via Twitter that they were working hard to help those early adopters (beta testers?) and very quickly modified the update to work for those who had installed the leaked version.

So I returned my Droid X, not because I didn’t enjoy the device, but because I strongly disagree with the policies of the manufacturer, and would rather support a manufacturer that encourages and works with consumer innovation.

The Samsung Fascinate is about to hit Verizon, and I might just buy that, but more than likely, I’ll wait for the newly rumored 4.3″ HTC device. Because HTC sounds like a company with policies I’d like to support.

Thus ends the Droid X saga.

In my last post, Four Reasons I Don’t Care About the Droid X, I whined about… well, four reasons I didn’t care about the Droid X. Open mouth, insert foot: I just back-ordered a Droid X. Bah!

So I present to you, Four Reasons I Bought the Droid X:

1. Big Fucking Screen
   The screen is just absolutely huge. While I wish it was a tad shorter, and a tad wider (like the beautiful EVO 4G), it’s still great. Initially, I was worried how it would feel in my hand or if it would fit comfortably in my pocket, but after using it for 45 minutes, I wasn’t worried anymore. I went back and forth, looking at an Incredible and an X, and the Incredible just felt atrociously small after playing with the X.
2. It’s Possible to Remove the Software Ugly
   I complained a lot in my last post about how damn ugly the phone was, software and form factor. There’s not much you can do about the actual phone itself besides dressing it up with a case, but it is much more possible to make the software look better by removing all the MotoBlur widgets, installing a 3rd party launcher, and downloading some other widgets (namely the Fancy and Beautiful widgets) to make it look more appealing.
3. HDMI Out
   While it can only be used for viewing pictures and videos right now, I’m hopeful that someday it’ll support being able to put whatever is on your screen on your television or monitor. Couple that with some Bluetooth keyboard and mouse solution, and I’m hoping this phone will eventually be my computer.
4. It has the Bigger GBs
   Okay, this really doesn’t matter at all as you can easily upgrade the SD card in the Incredible, but the fact that the X comes preloaded with 8 GB internal and a 16 GB SD card is just boss.

So after my whiny bitching about it being ugly and locked down, I still bought the Droid X.

I’ll be honest: there are a lot of reasons to be excited about this weeks release of Verizon’s Droid X by Motorola. The device has some massively awesome specs: 4.3″ screen, 1Ghz processor, 24 GB of storage out of the box, an 8MP Camera and HD video recording. Sounds great, but there are some definite show stoppers.

1. It’s Ugly
   Let’s just get this out of the way: the phone looks terrible. It looks like it’s straight out of the early 90s. When you compare it to the beautiful phones rolling out of HTC, like the Droid Incredible and EVO 4G, this thing looks like an outdated hunk of crap. And while I know I shouldn’t judge the phone based on how it looks, this odd-shapped, button popping monstrosity is almost too much to deal with.
2. No Front Facing Camera
   Why does this matter? Front-facing cameras are a great new feature to a lot of phones rolling out (EVO 4G, iPhone 4), and for one very good reason: video chat/phone. Both the EVO and iPhone sport this functionality, but it’s completely impossible without a front facing camera, because with a back facing camera, you won’t be able to see the screen, and thus, won’t be able to see the person you’re talking to. Tsk, Tsk.
3. Motoblur
   I know they’re touting it as a new, revised Motoblur, but the damn thing still looks ugly as sin, from the UI to the widgets; it’s just awefull, especially if you compare it to the HTC Sense UI. Even the stock Android UI looks so much better. This isn’t a big deal, because you can just flash it with a custom ROM, right?
4. No Custom ROMs (yet)
   The Droid X suffers the same fate of the Droid Milestone: an encrypted bootloader that prevents loading custom ROMs on the phone. For the average consumers, this doesn’t even matter, but for tech heads and developers like me, this sucks all the fun out of Android.

I was dead set on purchasing this phone as soon as I am eligible at the start of August and was totally willing to deal with #1-3 on this list, but #4 killed it for me. If I can’t install and play with custom firmware on an Android phone, I don’t want it.

Now I’m going to sit on the waiting list for the Droid Incredible and bask in the glory of a sexy phone, with custom ROMs, with a smaller screen and less than stellar specs. You almost had me Motorola; you almost had me.

The Droid X by Motorola on Verizon was announced today (regardless of the fact that almost everything about it was already know for months due to leaks). Here’s the skinny:

• 1GHz Processor
• 8gb internal memory
• 16gb MicroSD included
• 4.3″ 854 x 480 screen
• HDMI out
• 8 MP HD camera with dual flash and 720p video capture
• Android 2.1 with a new version of Motoblur

This sounds great on the surface. But why am I skeptical?

For one, it doesn’t ship with Android 2.2, but that was just released today, along with Flash mobile 10.1, with promises that it’ll be rolled out to the device in “late summer.”

But more importantly, the thing is just terribly ugly. The actual phone is just hideous, especially the physical buttons on the bottom that stick out like a phone straight out of 2004. Just look at it’s biggest Android competition, the HTC EVO 4G. Now that phone is hot. Compare the two, and the Droid X looks like vomit. Whoever was in charge of the phone design at Motorola should seriously be fired. You suck.

On top of that, it runs Motoblur, which is down-right hideous. Even the new version of it (from the leaked screenshots), just look terrible, even compared to the stock Android UI, and especially compared to the beauty of HTC’s Sense UI. Come on, this thing looks hideous. You did the right thing by not putting that crap on the original DROID (maybe Motoblur wasn’t out at the time), why do you have to ruin a decent operating system this time around?

But the specs are absolutely phenomenal. The only thing I have to complain about is that it doesn’t have a front-facing camera (boo!). Other than that… HOLY STORAGE SPACE, Batman. I know the iPhone has up to 32gb, but not the stardard cheap model. You have to pay extra for that. This baby comes with 8gb internal with an included 16gb card. NICE…

So will I get one? We’ll see. When I’m up for renewal at the end of July, I’ll have to stroll into Verizon and compare the Droid X and Droid Incredible side-by-side and see who wins.

I completely loathe Zend_Form and it’s silly validation system, but I’ll save that for another time and just concentrate on a specific example: You can only have one validation callback per form element.

There’s the awesome Zend_Validate_Callback which allows us to try to make up for other validation shortcomings by allowing us to define our own validation rules.

But apparently you can only add one callback validator per form element.

Why is this an issue?

Zend_Validate_Callback provides silly error messages (“% is not valid”). So it’s desirable to override this message, but if you’re doing multiple custom validations, you’ll want multiple messages depending on how validation failed. Well, you can’t add multiple messages, so the intuitive (as close as you can get to intuitive with ZF) thing to do would be to break it out into multiple validators and add a helpful message for each. You can’t do that!

Thanks, ZF.

A possible solution would be to pass an instance of the object to the callback via setOptions(). But the messages are private, with no method to change them.

Hackish solution: create our own validator.

<?php
require_once 'Zend/Validate/Abstract.php';
require_once 'Zend/Validate/Callback.php';
 
class My_Validate_Callback extends Zend_Validate_Callback
{
 
    public function setMessage($message, $value)
    {
        if(isset($this->_messageTemplates[$message]))
            $this->_messageTemplates[$message] = $value;
    }
 
    public function isValid($value)
    {
        $this->_setValue($value);
 
        $options  = $this->getOptions();
        $callback = $this->getCallback();
        $args     = func_get_args();
        $options  = array_merge($args, $options);
 
        $options[] = &$this;
 
        try {
            if (!call_user_func_array($callback, $options)) {
                $this->_error(self::INVALID_VALUE);
                return false;
            }
        } catch (Exception $e) {
            $this->_error(self::INVALID_CALLBACK);
            return false;
        }
 
        return true;
    }
}

All we’re doing here is extending Zend_Validate_Callback and (1) adding a method to override the message templates and (2) passing a reference to this object to the callback method.

Complex. Insane. Should be unneeded. Zend Framework.

Ditz is an issue tracking system for command line junkies. For those of us who live on the command line already, using vim, psql or mysql, svn, bzr or git, this makes us feel right at home tracking our issues. And I love it.

Ditz creates a directory within your project (or anywhere else you want it) and a config file in the project directory. Each issue then becomes a file in this directory. A powerful command line interface allows you to setup releases and components, and assign those to issues, as well as edit, complete and comment on issues. It even provides the ability to generate HTML files of issues.

The only thing Ditz doesn’t allow you to do is have your information stored in a remote location, which pretty much kills effective project collaboration as one would have to commit their Ditz directory ASAP, and other developers would have to update their working copy before managing issues.

But for solo projects, it’s perfect for command line junkies to track bugs, tasks and features for their project.

See if you can spot the logic error:

<?php
    require_once "mnnl.pnnl";
 
    $tkkl = new $fkkl($_POST["wkkl"]);
 
    $tkkl->pkkl()->jkkl(14, 15, blt);
 
    foreach($tkkl->lkkl($tkkl::BkklBokkl) as &$jkkl)
    {
        jkkljokkl($jkkl);
 
        if($jkll->brkll == blt)
            hbblhobbl($jkkl);
 
        $skzzl = "SELECT fkkl, fakkl FROM frzzlz WHERE frzzlor = 'fazzor' AND fwippl IS NOT NULL";
 
        $hobbl = new hobblDobbl(hobblDobbl::$swbbl("fraaa"));
 
        $hobbl->hwaah($skzzl);
 
        $jkkl->hzrnn($hobbl->fkkl, $hobbl->fakkl);
 
        $tkkl->znnado($jkkl->twng);
    }
 
    $mbnf->swmlel($tkkl->ploo());
?>

Yesterday, while trying to figure out the best way to deal with PostgreSQL arrays in PHP, I came across the new str_getcsv() function in PHP as of 5.3. This function works much the same as fgetcsv to parse a CSV line, except that it works on a string instead of a file.

For quick reference, CSV looks like this:

"My Name",14,"32,000","2009-04-15"

And the return value of a PostgreSQL array looks like this:

{"My Name",14,"32,000","2009-04-15"}

Notice the similarities?

We can use PHP’s trim and str_getcsv to turn this PostgreSQL array into a PHP array:

<?php
    $data = str_getcsv(trim($record->value, "{}"));
?>

Simple as simple does. As long as your array has only a single dimension. If you’re using multidimensional arrays in PostgreSQL then you’re dead to me.

At first when I saw the Zend Framework recommendation of omitting the closing tag in PHP files I thought it bizarre and stupid. Afterall, you close every other syntactic character in programming: parenthesis, brackets, HTML tags, ifs, loops, etc. So why wouldn’t you close the PHP tag at the end of the document as well?

The Zend Framework reason is, of course, to white space data from being sent to the browser prematurely, which messes up sending header information to the browser. My first thought was “this is lazy and encourages bad coding.”

But the more I think about it, the more it makes sense. It isn’t laziness, but a fool proof way to prevent a common mistake from happening. And apparently the closing tag isn’t required at all, so why not?

I don’t think I’ll be quick to adopt this practice, but maybe eventually, and maybe as I write new code. We’ll see.

While building MySQL database support into the OpenAvanti PHP framework, I came across an interesting quirk in MySQL that I thought must be a bug. Apparently, after submitting a bug report and getting a response from MySQL, it’s a documented feature (and later, referred to as a limitation).

Continue Reading →