On the MyBuilder.com Tech blog they've posted a tutorial from Edd Mann looking at the use of constraint-based ordering in PHP applications.

An interesting problem arose last week when we wished to generate a listing of recently completed jobs (along with their shortlist fees). Upon review of some earlier attempts, we did not like the aesthetics present when many of a particular shortlist fee were clustered together (i.e. two or more adjacent jobs with the same shortlist fee). What we were instead looking for was to create a constraint-based ordering that when applied to the recently completed jobs, would give an even distribution of shortlist fees (data-set permitting).

Initially he tried a "low-high" ordering method based on their "fee" value. Instead, to make the solution more "random" he reframed the need and broke it down into three separate actions: sort, partition and interleave. As PHP only has one of those, he came up with his own solutions for the other two (code included). He explains briefly how it all works together and what kind of benefits it has over the low-high solution originally created.

Matthew Turland has posted about a topic that was the subject of a recent cover story in php|architect magazine - EAV modeling.

The mental image that came to me when reading about this approach to data modeling was taking the traditional relational table and turning it on its head. [...] EAV actually has to circumvent, work around, or reimplement features that most mainstream database servers today provide "for free" to the traditional relational counterparts of EAV in order to get equal functionality.

He talks about features the structure has (including row-level referential integrity and schema metadata) and points out some of the other document-focused database systems like Lucene and CouchDB.

Check out the story in the June 2008 issue of php|architect for that cover story from Carl Welch.

It's always good to finish a rather large project, and Robert Peake shares his joy in this new post on his blog nothing that not only is the project off and running, but it was all created based on a best practices/standards-based approach with respect to PHP development.

I spent over 18 months architecting the system, from dedicated hardware to software including eCommerce, CRM, subscription management, recurring billing, and content management systems. I had great help from a small, dedicated, and very talented in-house team of artists and programmers. Absolutely everything is implemented on a LAMP stack.

He notes several of the things they used along the way, including:

• Design patterns
• Ajax
• Optimization
• Coding standards
• Extreme programming tactics

I consider it a kind of real-world treatise on how to effectively implement enterprise best practices with LAMP technologies. No books, no debating, no theory -- we did it.

It's always good to finish a rather large project, and Robert Peake shares his joy in this new post on his blog nothing that not only is the project off and running, but it was all created based on a best practices/standards-based approach with respect to PHP development.

I spent over 18 months architecting the system, from dedicated hardware to software including eCommerce, CRM, subscription management, recurring billing, and content management systems. I had great help from a small, dedicated, and very talented in-house team of artists and programmers. Absolutely everything is implemented on a LAMP stack.

He notes several of the things they used along the way, including:

• Design patterns
• Ajax
• Optimization
• Coding standards
• Extreme programming tactics

I consider it a kind of real-world treatise on how to effectively implement enterprise best practices with LAMP technologies. No books, no debating, no theory -- we did it.

Rahim Sonawalla has posted part two of his series on The OC Food Review blog covering the creation of a location-based search using geocoding.

We got geocoding out of the way in the first part, so now it's time to talk distances. To figure out how far apart two places are, we could use the traditional method of calculating distances between two points, but that damn Columbus didn't fall off into the Twighlight Zone when he passed the horizon. Turns out the Earth isn't flat, go figure. Oh, and since it isn't flat, assuming that it is will cause your numbers to be off when calculating distances using normal geometry—sometimes by miles.

He links to a formula for finding the difference when the distances are short as well as a PHP implementation of the Haversine formula when the distances get long.

He combines this new knowledge with the information already obtained by the geocoding in the first part and a SQL database to help narrow down the items in the list. Then, for each of those, he compares the latitude and longitudes to get the difference between them (in miles).

Rahim Sonawalla has posted part two of his series on The OC Food Review blog covering the creation of a location-based search using geocoding.

We got geocoding out of the way in the first part, so now it's time to talk distances. To figure out how far apart two places are, we could use the traditional method of calculating distances between two points, but that damn Columbus didn't fall off into the Twighlight Zone when he passed the horizon. Turns out the Earth isn't flat, go figure. Oh, and since it isn't flat, assuming that it is will cause your numbers to be off when calculating distances using normal geometry—sometimes by miles.

He links to a formula for finding the difference when the distances are short as well as a PHP implementation of the Haversine formula when the distances get long.

He combines this new knowledge with the information already obtained by the geocoding in the first part and a SQL database to help narrow down the items in the list. Then, for each of those, he compares the latitude and longitudes to get the difference between them (in miles).