Blog posts tagged "php"

New Amazon AWS Signature Version 2 is “OAuth-compatible”

December 30th, 2008

Enigma rotors

Spent a couple hours last night writing the core of a stripped down, PHP4 compatible API library for Amazon SimpleDB (in the style of my flickr simple library. Just not a fan of abstraction for its own sake). In the process I discovered that Amazon had revved the version on their “Signature Method”. Which is good news as SignatureVersion 1 contains a classic crypto-blunder in its design, namely it encourages collisions. (more details, also why you care about collisions) To date the solution was use SSL, and wait patiently, very patiently. So yay for Amazon fixing this! And in fairness, first couple of drafts of the OAuth spec contained a similar issue, though it got ironed out quickly. Yay for many eyes and the open web.

“OAuth-compatible” signing

Great things are more secure, good news and all, but that isn’t what caught my eye. This block of text did:

Here is what’s different about forming the string to sign for signature version 2:

  • You include additional components of the request in the string to sign
  • You include the query string control parameters (the equals signs and ampersands) in the string to sign
  • You sort the query string parameters using byte ordering
  • You URL encode the query string parameters and their values before signing the request

You really have to be an OAuth-dork to find anything special with that paragraph, but if you were, you’d notice that those 4 bullets are an incredibly succinct description of generating an OAuth signature. (in fact a more succinct description then appears anywhere in the OAuth documentation

Which meant that my SimpleDB library can reuse most of the logic from my OAuth library to do the trickiest part of the API call, namely the signing. (Additionally it means that security reviews of both protocols support each other)

So my AWS signing method is a approximately a dozen characters different then my OAuth method and as straightforward as:

    .....

    $signature = aws_request_signature(AWS_SECRET_KEY, $http_method, AWS_SIMPLEDB_SERVICEURL, $parameters);
    $parameters['Signature'] = $signature;

    $encoded_params = array();

    foreach ($parameters as $k => $v){
        $encoded_params[] = oauth_urlencodeRFC3986($k).'='.oauth_urlencodeRFC3986($v);
    }

    $request_url = AWS_SIMPLEDB_SERVICEURL . '?' . implode('&', $encoded_params);

    .....

    function aws_request_signature($key, $http_method, $service_url, $parameters) {
        $base_string = aws_base_string($http_method, $service_url, $parameters);
        return base64_encode(hash_hmac('sha1', $base_string, $key, true));
    }

    function aws_base_string($http_method, $service_url, $parameters) {
        $parsed = parse_url($service_url);

        $host = strtolower($parsed['host']);
        $path = $parsed['path'] ? $parsed['path'] : '/';
        $data = array(
            strtoupper($http_method),
            $host,
            $path,
            oauth_normalized_request_params($parameters)
        );

        $base_string = join("\n", $data);
        return $base_string;
    }

(this uses my personal OAuth library, but your library should have similar methods)

Sure made my jobs of implementing a library easier. If you’re going to invent a new crypto protocol, please consider doing like Amazon, and re-using the basic building blocks. (which also happen to be best practices)

  • December 11, 2008

    My Flickr API library for PHP.

    I’m a big believer in Norvig’s “Code is liability” maxim. Which is how I justify my ugly, but functional Flickr API implementation, in 40 lines of PHP (not the most expressive of languages), which I wrote in about 15 minutes one evening, and I now use for all of my Flickr side projects. And all apropos of digging through other folks Flickr API impls, trying to get them working on GAE. Thankfully blech is already there.

    + 1. (Aside , , , , , , )

AOEMedia Sponsoring Magpie

June 7th, 2008

AOE media, a TYPO3 & open source provide from Germany, recently agreed to become a sponsor on Magpie. Which is very exciting!

Looking around I see being sponsored by AOE Media puts me in good company as they sponsor a number of interesting projects, including my favorite wiki software Doku

I’m hoping this will allow me to actually spend a little time with Magpie, maybe finally find the time to re-vamp the website into something a little more functional.

And last if you’re someone interested in sponsorship work as a whole on Magpie, or specific feature development get in touch.

Thanks again AOE Media.

bceval: arbitrary precision math for PHP without extensions

March 25th, 2008

I needed arbitrary precision math in PHP, and wasn’t willing to rebuild PHP to add the bcmath extensions. All hail backticks.

function bceval($expr) {
  return trim(`echo "$expr" | bc`);
}

Used like so

$end = bceval("$start + $batchsize - 1");

Wet cat territory.

Reading a file backwards in PHP

February 28th, 2008

This morning I needed to read from a file line by line from the bottom. In PHP. Perl, of course, has a module to do this. A quick view source decided that I didn’t want to get into file seeks before breakfast. Very happy with my solution:

$file = popen("tac $filename",'r');

while ($line = fgets($file)) {
  echo $line;
}

OAuth in PHP (for Twitter)

October 16th, 2007

Mike released HTTP_Request_OAuth today, so I spent a little while this evening coding up Service_Twitter as helper class for making OAuth authorized requests against the Twitter API.

Both are early enough in the dev cycle to be called proof of concepts.

Mostly I wrote it because I had always envisioned there being wrapper libraries around the low level OAuth implementations that wrapped the calls, and constants, and as Mike graciously went out and wrote a low level library I felt compelled to write a wrapper.

Also twittclient, an interactive client for getting an authed access token, essential to bootstrapping development.

And nota bene, HRO currently only supports the MD5 signing algorithm, which is undefined in the core spec, and subject to change. (Just in case you didn’t believe me about the early state of things.)

update 2008/4/18

This code no longer works because Twitter has taken down their (slightly non-compliant) OAuth endpoint. When they add OAuth support back in, I’ll link to it.

Looking at PHP5’s DateTime and DateTimeZone

February 27th, 2007

Looking over the PHP5.2 changelog I noticed that somewhere along the way PHP5 seems to have picked up a provocatively named pair of classes, DateTime and DateTimeZone.

There is something fundamentally brash, brazen even, to releasing a class named DateTime. As a calendar geek I imagine upon seeing “new DateTime()” I feel something akin to what an old thespian feels when they see a company putting on a production of the Scottish play — it’s a decidedly mixed emotion. But I’m going to bump my way through learning how to use this new DateTime lib, bringing all my preconceptions about how it should work. The odds of this being interesting to you is probably nil unless you’re in one or two very small cliques, feel free to read on, or browse away.

I’m primarily working in PHP4 right now, so my first step was to grab a copy of MAMP 1.5b getting me a nice PHP5.2 sandbox to play with.

The new objects are documented here, apparently there are functional equivalents for each of the object methods, and they use the PECL timezomedb.

Hey! timezonedb! First fence cleared! A timezone database compiled into a native format based on Olson is the one true solution, and I can update it independently, the most recent release being based on 2007b. Sweet.

Constructor takes an initialization string that it passes to strtotime(), and an optional DateTimeZone obj. Defaults to “now”

$date = new DateTime();
echo $date . "\n";
> Object of class DateTime could not be converted to string 

Oops, no __toString() method defined. You’ll need to use the format() instance method. If you end up using the DateTime objects, you’ll be seeing a lot of format(), more on that in a bit.

format() uses the date() formatting strings (not the strftime format strings). Also takes a number of useful constants, most usefully your pal and mine RFC3339 (aka W3CDTF aka Dublin Core/Atom date format).

echo $date->format(DATE_RFC3339) . "\n";
> 2007-02-22T15:23:47-05:00

Note: thats a constant, if you pass in the string ‘DATE_RFC3339′, and you’ll get odd looking results.

Here we can see the default constructor sets both the time and a timezone — correctly, for the moment, identifying my timezone as America/New_York. That’s somewhat contentious behaviour, some people will tell you that dates with unspecified timezones should either be in UTC or be “floating”, divorced from any timezone. Why? At least in part because across platforms and boxes timezone guessing is going to be non-deterministic — the script that worked when you ran it locally on your Mac laptop in New York, might fail on your ISP’s servers. You get a hint of this reading over the timezone guessing rules on date_default_timezone_get. There is also the fact that I’m currently moving at about 400mph and will be in a different timezone real soon now. However you can set the default to something reasonable in a script, or in the php.ini. (consider this my recommendation)

date_default_timezone_set('UTC');
$date = new DateTime();
echo $date->format(DATE_RFC3339);
> 2007-02-22T20:44:49+00:00

Yay, that worked. Okay, but lets display that datetime in the local timezone. (after all the point of this entire exercise will be the ability to work painlessly in multiple timezones).

$date->setTimezone('America/New_York');
> DateTime::setTimezone() expects parameter 1 to be DateTimeZone

Siiiigh. Not smart enough to cast strings into TimeZone objects (holds true for the constructor as well, so no new DateTime('now', 'UTC')). Now its time to learn how to use DateTimeZone.

Working with DateTimeZone, All Hail Olson

I mentioned briefly earlier that PHP is now shipping with an extension timezonedb, which is a compiled version of the Olson database. The Olson database is a massive, largely volunteer effort to catalog the various timezones both in use, and those that have been in the past. Time is a political issue, particularly day light savings, and as such the rules governing it are arbitrary, whimsical, and subject to frequent change. (p.s. gotten a panicked memo yet about new daylight savings compliance for March 11th? No? Where did you say you worked?)

Note: Olson also uses a longer form of the zone names then we usually see in the U.S., this is to combat ambiguity. See Appendix H for a list of timezone names, including some handy shortcuts.

$tz = new DateTimeZone('America/New_York');
$date->setTimezone($tz);
echo $date->format(DATE_RFC3339) . "\n";
> 2007-02-22T16:02:55-05:00

This is starting to get long winded, but, hey, PHP5 supports object dereferencing on returns. Maybe this will work.

echo $date->setTimezone($tz)->format(DATE_RFC3339) . "\n";
>  Call to a member function format() on a non-object

Nope. Oh well.

Date vs Datetime?

Say I’ve got a nice platonic date, say November 11th. There is no time element associated with this, so timezones are kind of irrelevant. I mean Nov. 11th starts at different times through out the world, but Nov. 11th is universal. (as long as you’re using the same version of Gregorian as most of the rest of us) Ideally this date would float above timezone issues, but that isn’t how PHP does it, 2007-11-11 is treated internally as midnight on the 11th, which is certainly simpler, but disappointing. You can prove this like so:

$date = new DateTime('2007-11-11');
$date->setTimeZone($tz);
echo $date->format(DATE_RFC3339) . "\n";
> 2007-11-10T19:00:00-05:00

The other useful DateTimeZone method is getOffest()

echo $tz->getOffset($date); 
> -18000

Daylight Saving, March 11th, and Why Programmers Are a Grouchy Lot

Note: getOffset, which returns a timezone’s offset in seconds from UTC, takes a DateTime obj because offsets can be date sensitive due to daylight savings. Really without daylight saving this stuff would all be pretty straightforward. Let’s test to make sure the offsets are correct at the boundary.

echo $tz_nyc->getOffset(new DateTime('2007-03-11 1:00')) . "\n";
echo $tz_nyc->getOffset(new DateTime('2007-03-11 2:00')) . "\n";
> -18000
> -14400

(-18000/(60*60) == -5 hours) 
(-14400/(60*60) == -4 hours) 

Yay! They got the memo about U.S. Energy Policy Act of 2005.

The Basics: Accessors and Mutators

So what are some other basic desires?

Get epoch seconds! Except for their kind of limited range epoch seconds are great, and have helped a generation of programmers put off worrying about timezones as long as possible. They’re also the backbone of PHP’s traditional date/time methods.

Alas, there isn’t an accessor method for getting epoch seconds, you’ll have to use format().

In fact DateTime doesn’t expose any of the accessors you’d expect, so you’ll be using format a lot if you want to access pieces of your date. (for you know, display purposes, or manipulation, or building queries, or pretty much doing anything you’d want to do with a date)

examples of the format() as all purpose accessor pattern:

epoch:  $date->format('U'); // 1173596400
year:   $date->format('Y'); // 2007
month:  $date->format('n'); // 3
day:    $date->format('j'); // 11
dow:    $date->format('l'); // Sunday

… etc …

So now you have accessors for the full range of date() formatting strings. You just have to jump through a hope.

Pretty much the only accessor is getTimezone()

echo $date->getTimeZone();   // hope springs eternal!
> Object of class DateTimeZone could not be converted to string
echo $date->getTimeZone()->getName() . "\n";
> America/New_York

Mutators

Speaking of accessors, DateTime is a little sparse on mutators as well: setTime(), setDate(), and the mysteriously named setISODate().

$date->setDate('2007', '1', '1')->format(DATE_RFC3339);  // who am I kidding?
> Call to a member function format() on a non-object 
$date-> setDate('2007', '1', '1');
echo $date->format(DATE_RFC3339) . "\n";
> 2007-01-01T02:00:00-05:00

Now what if I want to set just the day?

Maybe

$date-> setDate(null, null, '11');
echo $date->format(DATE_RFC3339) . "\n";
> -001-12-11T02:00:00-05:00

Nope.

Instead you’ll need to pull out the year and month (using our format() accessors) and pass those back in just to set the day.

$date-> setDate('2007', '1', '1');   // jan 1.  
$date->setDate($date->format('Y'), $date->format('n'), 11);
echo $date->format(DATE_RFC3339) . "\n"; 

Clunky.

setTime() works the same, but for time.

e.g. Setting just the minutes, 33 minutes past, but keep hours, and seconds constant:

$date->setTime($date->format('G'), 33, $date->format('s'));
echo $date->format(DATE_RFC3339) . "\n"; 
> 2007-01-11T02:33:00-05:00

So what is an ISODate? I’m unclear, and so is PHP’s documentation. The docs show the call signature taking a $year, $week, and optional $day, while the description talks about $year, $month, $day. Looking at the code looks like $week is the proper call, $month is cut and paste error from setDate(). So I guess this is a method for setting day by the “week of the year” a concept more popular in Europe then in the US. Not sure what ISO has to do with it. So what is our current week of the year?

echo $date->format('N') . "\n";  // 'N' is new in 5.1.0
> 4 

Jan 11th was in the 4th week of the 2007? Go figure.

$date->setISODate(2007, 4, 5);  // fifth day of the 4th week?
echo $date->format(DATE_RFC3339) . "\n";
> 2007-01-26T02:33:00-05:00

Um. You know what? You’re on your own with setISODate, sorry.

Date Math: Adding and Subtracting Deltas aka $date->modify($str)

PHP5 for better or worse has very limited operator overloading, so no $dt1 + $dt2 * $dt3 / $dt4. Instead the primary method for doing math is modify()

Thankfully PHP’s strtotime() method is a gem, and one of the things it handles is relative dates. strtotime() + relative dates is the secret to doing math with PHP5’s DateTime.

Lets get a basic date to start with:

$date = new DateTime('today');
echo $date->format(DATE_RFC3339) . "\n";
> 2007-02-22T00:00:00+00:00

Note: modify() is destructive. It changes the original datetime object (as the name suggests). You’ll need to jump through some hopes to keep a copy of your original date. More later.

Add/subtract N days:

foreach (range(1,10) as $n) {
   $date->modify("+1 days");
   echo $date->format("Y-m-d") . "\n";
}

> 2007-02-23
> 2007-02-24
> 2007-02-25
> 2007-02-26
> 2007-02-27
> 2007-02-28
> 2007-03-01
> 2007-03-02
> 2007-03-03
> 2007-03-04

$date->modify("-10 days");
echo $date->format("Y-m-d") . "\n";

> 2007-02-22

$date->modify("-1 month");
echo $date->format("Y-m-d") . "\n";
> 2007-01-22
// or alternately
$date->modify("1 month ago");
echo $date->format("Y-m-d") . "\n";
> 2006-12-22

Cloning DateTime objects to work around modify

Of course you usually want to keep the original when doing date math, so modify()‘s lack of idempotentce is annoying. Lets say I’m building a SQL query to select events happening in the next 7 days.

In an ideal world the code would like this:

$start = new DateTime('today');
$end = $start + 7;
echo "select between " . $start->format('Y-m-d') . " and " . $end->format('Y-m-d') . "\n";

The above of course is just a pipe dream. But wouldn’t it be nice?

I’d settle for:

$end = $start->calc("+7 days");

Or even:

$end = $start->clone->modify('+7 days');

None of the above examples remotely work.

Instead use:

$start = new DateTime('today');
$end = clone $start;
$end->modify('7 days 3 minutes 42 seconds ago');

Now format our SQL query for our example:

echo "select between " . $start->format(DATE_RFC3339) . " and " . $end->format(DATE_RFC3339) . "\n";
> select between 2007-02-22T00:00:00+00:00 and 2007-02-14T23:56:18+00:00

Awkward, but it gets the job done.

At least the relative date format is super flexible and expressive. As far as I know the closest thing to documentation is from the GNU tar manual on date input formats. (just like CVS) Btw. if you ever want nightmares, take a look at the scan method in PHP’s parse_date.c and be thankful that isn’t your job to maintain :)

Date Math: Comparison and Differences

Beyond adding deltas (“+7 days”), the other common date math is comparing two datetimes, to find out which is more recent, and getting the difference between them. DateTime supports no methods for comparing two datetimes. The simplest solution for doing comparison is to compare epoch seconds.

Note: This method only works for dates that can be represented by epoch seconds. PHP uses a signed int for epoch seconds, so the range is limited by the size of the max int on your platform. Generally you get approximately 138 years, 1901 to 2038. There are other schemes besides epoch seconds for mapping dates to an easily comparable number; MJDs, and Tai time being two. See also Rheingold & Dershowitz 1997

$d1 = new DateTime("today");
$d2 = new DateTime("tomorrow");
if ($d1->format('U') < $d2->format('U')) {
   echo "true\n";
} 
> true

If you’re going to be comparing a large number of dates you might consider a memoization technique like the Schwartzian transform.

We can get the difference in seconds using the same hack of casting to epochs.

echo $d2->format('U') - $d1->format('U') . "\n";
> 86400

Ideally we’d then divide the difference seconds to get the difference in hours, days, weeks, or months. However the following naive solution won’t work.

$diff / (60*60*24);  // calculate difference in days, **BADLY**

Why not? Because days don’t always have 24 hours. Sometimes they have 23 hours, sometimes they have 25. Daylight saving strikes again. (If you want to be even more pedantic, minutes are also not 60 seconds long, sometimes they’re 61 seconds long if we have a leap second)

Basically you need to break yourself of thinking of datetime units as being fungible. You can’t simply calculate minutes from seconds, or days from hours. Just like you can’t divide days by 30 to get an accurate number of months. There are solutions, but they’re a bit beyond this blog post.

new DateTime from Epoch Seconds

So, non-fungible, remember that.

But sometimes you’ve cast DateTimes down to epochs to do math. And then you’ll want to cast back to a DateTime.

Alas DateTime doesn’t have a constructor that takes an epoch, and passing a epoch to the default constructor will throw an exception, rather you want:

$from_epoch = new DateTime(date('c', '-568080000'));
echo $from_epoch->format('Y-m-d') . "\n";
> 1952-01-01   // expected result

Conclusions

DateTime/DateTimeZone get timezones right, and for solving that hard problem they deserve all possibles accolades.

The rest of the API however is kind of simplistic, awkward to work with, and verbose.

Single most useful change: have DateTime methods actually return the object making it possible to use a slightly more abbreviated calls.

I had thought about writing up a few more recipes, like nth dow of the month, and such. But we were coming in for descent, and it was time to be done. Might happen in the future.

Also if anyone has any power to enhance the DateTime object, I hope some of the above can act as a road map for a more expressive and powerful core library. Or ping me, happy to chat.

Magpie 2.0-alpha-alpha-alpha

October 16th, 2006

Probably surprises no one but me, but the work on Magpie has been moving slowly again lately. Rather then continue futzing with it in the rare spare moments, I’m going to push it out in a very raw state, where folks can give some feedback. (and because folks keep asking about it) This is a preview release, very alpha.

Alpha

Alpha means its broken, there are missing features (many of which are actually in the current Magpie 0.7x releases), and stuff will change. Whether you find that exciting or off-putting is a personal thing.

Getting Started

So um, yeah, as of yet no documentation. That said I’ve included the classic magpie_simple.php script, unchanged except for the require statement. For really simple scripts that is all that is required.

Grab the current code, Magpie 2.0-alpha-PR1. This isn’t its final home, but I am taking this opportunity to finally break free of Sourceforge which has been a long standing goal.

(I know, we all prefer a good var_dump() plus source reading to docs, but their current non-existence won’t continue)

Goals for 2.0

There were three over-arching design goals in this rewrite, plus a slew of secondary goals.

1. Support new namespaces and elements, easily

Rather then go on trying to push the universal rules for mapping unknown elements to datastructures (the Magpie 1.0 approach) I’ve focused on making it simple to register custom parsing logic, and having intelligent defaults. (aka more like what Feedparser.py does) I expect that we’ll handle most known namespaces in short order, and barring another total upheaval of the landscape ala the Pie/Atom project should sit us in good stead as feed use continues to become more sophisticated.

2. Pluggable components

You should be able to easily swap out the caching layer (database caches anyone?), the HTTP layer (multiplexed curl?), even the parser. Besides the added flexibility, the theory is this will make embedding simpler.

Who knows, maybe someone will even contribute a pluggable parser that can handle something other then well formed XML.

3. Mostly backwards compatible

For simple stuff, you’re scripts should go on working. There is still a 1 function interface (if you liked that), still bust everything down into a couple of nested arrays for easy looping and echoing. Even where different it should feel familiar.

Known Issues

  • Parser doesn’t support xml:base nor xml:lang nor Atom inheritance. It will, but these features still annoy me, and as long as no one is using the code I can’t seem to motivate to support them.

  • I’m also not doing all the normalization between feed types that I do in “Magpie classic”. Again, its coming.

  • Not sanitizing content yet.

  • Not just a new parser, but a new HTTP client as well. Basic HTTP auth support is there, digest isn’t. Haven’t added back in SSL support yet.

  • No documentation per se.

Incompatibilities and Gotcha

  • Just use $item['content'] instead of $item['content']['encoded'] or $item['atom_content'].

  • If caching is turned on, and Magpie can’t write to it’s cache, it will throw a fatal error, rather then quietly working in a degraded state. This might change, but its been a major support issue.

More features

  • fetch_rss() now supports taking per feeds options. This was the most requested feature, ever. (e.g. cache age, output encoding, user-agent, etc)

  • Parses enclosures, this was the second most requested feature.

  • Handles repeated elements properly. (dc:subject, link, whatnot)

    echo $item['dc']['subject'];
    foreach ($item['dc']['subjects'] as $subj) { ... }
  • Atom 1.0 support modulo known issues.

  • Tests. Most of them based on Mark’s FP tests. More added all the time. Currently not distributing with Magpie as I haven’t really figured out the license issues.

  • Confusing new licensing. Stated goal is to license under a dual GPL/BSD license. That means you get to choose if you’re using the software under the GPL, or the BSD. In addition you can upgrade your license to GPL from BSD (as you can with any BSD licensed software) merely by wishing it to be so.

  • Lots more, really.

Other then that, its just like Magpie :)

Tagged: Uncategorized , ,
  • September 21, 2006

    “Bloody stupid useless semicolons.”.

    Tim Bray, on why its nearly impossible to go back once you’ve coded Ruby. I’ve been writing PHP all day, every day for 3 months now, and I still can’t remember the damn semicolons.

    + 0. (Aside , )

Did blogs kill the online magazine star?

August 18th, 2006

Realized the other morning that I had half an article written just looking at my notes from some recent PHP hacking. Looked around a bit for somewhere to publish it, but most of the places I might have sent a PHP article a few years ago don’t seem to be around, or at least not accepting submission. Suggestions on a good venue?

Or is that why I’ve got a personal publishing platform?

Tagged: Uncategorized , ,

OSCON: First Day of Sessions

July 27th, 2006

The day started out right, if a bit bleary-eyed, with Gnat giving OSCAL a lovely plug during the keynote. Also got to see Rael’s latest project, tres cool. (and in Rails, of course)

Morning

Embedded databases in browsers turned out to be a bit more theoretical then I was in the mood for, but the backchannel was buzzing about Justin Erenkrantz’s modproxytalk, so I skipped over there. Jackpot. mod_proxy has done gone and grown up. Elegant, serious, flexible, built in caching (with multiple backends), pluggable protocols. Squid’s days as a reverse proxy are numbered. Now if someone would just hurry up and package Apache 2.3 we could do without Pound. (I’ve misplace the slides link)

Afternoon

Tim’s talk on atompub was good, if basic. I’m still trying to figure out how to push it beyond basic publishing. An interesting challenge, but later Tim pointed out that there are is some intentional wiggle room left in the spec, and one or two holes that you could drive a truck through with enough determination. (don’t think there was a slides link?) Oddest new thought, we need a mime type for Markdown, or maybe a container type for the whole class of human readable markup.

Briefly met Chad and Jeremy, something I’ve failed to do at work.

On The Floor

Wandered the exhibit hall a bit. Blah. Just not feeling the vendor love. No surprise, but its slams home what a commercial conference OSCON is, with very little of the raw delite and innovation of the smaller events. All the good shirts cost $$ this year — wonder what that means for t-shirt driven development, and the t-shirt economic metric. Finally met Jason from Apress. They have a Flickr book out in August.

Too Many Codepoints

Andrei’s PHP6 and Unicode talk was impressive, and overwhelming. ICU is being baked deep into the core string object. An .ini setting to determine default behaviour, with Unicode (UTF-16) and binary string types. Automatic stream oriented encodings from input/output/file/cli etc. Look for a preview release this Fall. (Eclipse gets all the glory, but ICU is another amazing IBM open source contribution, worth checking out in its own right) I’m not sure anyone is thinking about the “How do I make charsets work across the PHP4, PHP5, PHP6 spectrum in an open source library?” Doesn’t seem like that out there a question. Looking forward to catching up with him back in Sunnyvale.

Ruby Rodeo!

FreeGeeK goes on being one of the coolest, most inspiring community projects anywhere. Packing it to gills with hyper excited [Ruby hackers] certainly didn’t detract. Lucas Carson’s talk on dRB/Rinda was cool and inspiring. Not as polished a delivery as some talks, but he coded up a server-client architecture for discovering primes and automatically deployed it to those of us in the audience running irb. In about 20 minutes. The hilight though was finally getting a chance to catch up with Scott after all these years. (Rinda may just be good old Linda retreads, but Ruby is so damn slow that distributed computing is with the effort)

Didn’t Make It

Most disappointed to have missed in retrospect, Kevin Henrikson Ajax Optimization Techniques: Working with Large Ajax Applications. Got rave reviews.

Tagged: Uncategorized , , , , , ,

Simple Test

July 4th, 2006

Recently started using Simple Test for a couple of projects (even slipped it in at work, but sssh! don’t tell them!). So far I’m very happy with it. Using PHPUnit was always a bit of a non-starter, it felt heavy, and even which version (fork?) to use was ambiguous.

Simple Test’s documentation beyond the basics start to trail off, but the code is eminently readable (better then docs any day!), and I found writing a harness to work with the feedparser tests pleasantly straightforward.

Recommended.

Tagged: Uncategorized , , ,