Aaron Winborn

At Sony we're looking for a distributed version control system to replace Subversion—primarily Git and Mercurial. I'm very familiar with Git but hadn't done much with Mercurial so it seemed like a good idea to use it for a couple of weeks and learn the quirks. Since I'm stuck using Subversion I decided to see if it would be feasible to use Mercurial as a "super client" working locally then pushing changes back to svn. A little Googling turned up two candidates hgsvn and
hgsubversion. hgsubversion extends the commands pushing and pulling changes, giving a more native experience, so it seemed like the best choice for learning the system.

The setup is actually pretty simple but I'm documenting it for my own future reference.

Use MacPorts to Install hgsubversion:
sudo port install py26-hgsubversion

Enable the rebase and hgsubversion extensions:
printf "[extensions]\nrebase=\nhgsubversion =\n" >> ~/.hgrc

Check that the extension was enabled:
hg help extensions
It should list something like:
    enabled extensions:

     hgsubversion
                 integration with Subversion repositories

Now you're good to checkout from SVN (note: using the svn+ prefix in the URL lets you use passwords stored in your keychain):
hg clone svn+http://example.com/svn/repo/trunk

I actually ran into an issue where the clone was exploding with a stack trace. The bug had been fixed in 1.1.2 but MacPorts hadn't yet been updated so I rolled a patch to update it.

Here's yet another blog post to document something so stupid that I hope to never do it again, but know I will. I spent the better part of the afternoon trying to get the PECL memcache extension working with the PHP 5.2 part of a MAMP installation and finally managed to get it working.

Install XCode.

Open up a terminal and become the root user:
sudo su

Make all the MAMP PHP binaries executable:
chmod u+x /Applications/MAMP/bin/php5.2/bin/p*

Now get the memcache source, compile it and copy the library into PHP's extensions directory:
cd /tmp

wget http://pecl.php.net/get/memcache-2.2.5.tgz

tar -zxvf memcache-2.2.5.tgz

cd memcached-2.2.5

/Applications/MAMP/bin/php5.2/bin/phpize

MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure

make

cp modules/memcache.so /Applications/MAMP/bin/php5.2/lib/php/extensions/no-debug-non-zts-20060613/

Tell PHP to load the memcache extension:
echo 'extension=memcache.so' > /Applications/MAMP/conf/php5.2/php.ini

Sources:
http://www.php.net/manual/en/memcache.installation.php#95063
http://blog.m-schmidt.eu/2010/03/30/develop-memcached-web-apps-with-xamp...

After two days of trying to use OS 4 on my iPhone 3G I'm sad to report that it's a very un-Apple like release. It's slower, it breaks a bunch of games and doesn't offer any compelling features. I'd go as far as to say they should probably have only released it for the iPhone 3GS.

Twice today I've had to deal with writing a SQL query that needed data in a CCK field. The naive approach is to just look at the table and field names and plug them into your query:
<?php
$result = db_query("SELECT COUNT(*) AS count FROM {node} n
INNER JOIN {term_node} tn ON n.vid = tn.vid
INNER JOIN {content_type_date} ctd ON n.vid = ctd.vid
WHERE tn.tid = 25 AND ctd.field_date_value > NOW() AND n.changed > %d", $newtime);
?>
Often this will work just fine but since CCK can dynamically alter the database schema (when you add a field to a second content type or change the number of values) the query may break.

Fortunately CCK provides functions for finding a field's table and column names so it's simple to do it correctly:
<?php
$field = content_fields('field_date');
$db_info = content_database_info($field);
?>

A var_dump($db_info) gives:
array(2) {
  ["table"]=>
  string(17) "content_type_date"
  ["columns"]=>
  array(2) {
    ["value"]=>
    array(6) {
      ["type"]=>
      string(7) "varchar"
      ["length"]=>
      int(20)
      ["not null"]=>
      bool(false)
      ["sortable"]=>
      bool(true)
      ["views"]=>
      bool(true)
      ["column"]=>
      string(16) "field_date_value"
    }
    ["value2"]=>
    array(6) {
      ["type"]=>
      string(7) "varchar"
      ["length"]=>
      int(20)
      ["not null"]=>
      bool(false)
      ["sortable"]=>
      bool(true)
      ["views"]=>
      bool(false)
      ["column"]=>
      string(17) "field_date_value2"
    }
  }
}

After noting that the field has two columns and making our choice, we've got the pieces to plug into the query:
<?php
$field = content_fields('field_date');
$db_info = content_database_info($field);
$result = db_query("SELECT COUNT(*) AS count FROM {node} n
INNER JOIN {term_node} tn ON n.vid = tn.vid
INNER JOIN {". $db_info['table'] ."} ctd ON n.vid = ctd.vid
WHERE tn.tid = 25 AND ctd." . $db_info['columns']['value']['column'] . " > NOW() AND n.changed > %d", $newtime);
?>

The query is a bit harder to read, but you've future proofed your code so you won't be back to fix six months from now when you reuse that date field on another node type.