On PHPRiot.com there's a new tutorial showing you how to use the Douglas-Peucker algorithm to make the pathing on your map the simplest possible (the fewer points the better) having serious benefits a wide range of users, most notably those on mobile devices.

When drawing a path on a map (for instance, the directions from point A to point B) it is important to consider the limitations of the device you're drawing the path on. In this article, I will show you how to reduce the number of points in a path so the path can be displayed with minimal loss of quality on devices such as iPhone or Android-powered devices that may struggle with an extremely large set of points.

Using the GTFS service's data, he's been creating maps for an iPhone application. Naturally, a path with 700 points would take a lot of resources to render. Using the Douglas-Peucker algorithm he can reduce it down to a much more manageable 70 points. He explains the algorithm briefly and hows how to implement it in PHP with three classes - ShapePoint, Shape and ShapeReducer. The resulting reduced dataset is then passed directly over to a Google Maps for plotting.

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

Mike Lively has posted a few choice words about one of the most popular and most used design patterns out there - the Singleton.

One of the most derided, yet most loved and used patterns is the singleton pattern. Its supporters continually praise its ability to limit instantiation of objects and its opponents continually chastise its tendency to be little more than a glorified global. While programming in many ways boils down to a matter of preference (you can always find someone that agrees with you,) I thought I might as well document my opinion so that those who don't care can have one more thing to ignore.

He starts by (correctly) defining a Singleton and why, because of that definition, they are evil - they become a "global point of access". Why is that such a bad thing, you ask? Mike By their design they mask dependencies, making it harder to do future development and/or maintenance.

I personally do not see very many viable uses for singletons and I know there are many people that agree with me (google evil singletons). It's simplicity seems appealing, but they are incredibly easy to use in a damaging way. This is the danger you risk with any concept that is easy to understand and easy to abuse.

New from PHPRiot today, there's this new tutorial showing you how to combine a PHP interface with the Google Maps API to do some geocoding of your own.

Geocoding is the process of finding the longitude and latitude of a given address or location. The Google Maps service gives developers and web site owners free access to their geocoder, both using the Google Maps JavaScript API, as well as using the web service. In this article I will show you how to access the geocoder web service using PHP so that it can be used in your own applications.

The tutorial walks you through every step of the way - from getting your Google API ID to making a simple request all the way out to using placemarks to store locations to fetch later on.

This is a great, very detailed summary that anyone wanting to work with the Google API in PHP should definitely check out.

On the DeveloperTutorials website, there's a new tutorial posted that warns against the perils of floating point comparisons between PHP and Javascript.

The problem is if you've done any calculations to arrive at these numbers they might actually be stored as 71.00000000001. Now if one of them is stored that way and the other isn't and you compare the two to see if they are equal you'll get a FALSE as the response, even though they should be the same. This isn't a bug, it's how floating point comparisons are designed to work.

In order to help combat this, he's provided two functions - one in PHP and one in Javascript - that compare the numbers in a more "sane" way that someone using them to store, say, currency values might want to use to compare them.

On the DeveloperTutorials website, there's a new tutorial posted that warns against the perils of floating point comparisons between PHP and Javascript.

The problem is if you've done any calculations to arrive at these numbers they might actually be stored as 71.00000000001. Now if one of them is stored that way and the other isn't and you compare the two to see if they are equal you'll get a FALSE as the response, even though they should be the same. This isn't a bug, it's how floating point comparisons are designed to work.

In order to help combat this, he's provided two functions - one in PHP and one in Javascript - that compare the numbers in a more "sane" way that someone using them to store, say, currency values might want to use to compare them.

Matthew McCool has a few reminders for developers out there thinking of using Ajax in your applications - mainly to remember that it has the potential of adding another vulnerability to your application.

Consider a registration form built out of PHP. Any aspect of your script that accepts and processes data is a potential point of attack. If you add Ajax, what you’re doing is increasing the complexity of the application and, by extension, introducing greater vulnerability. More points of entry equal a larger attack surface, and that means potential problems for your application.

He continues his login form example and mentions a few things you could do to help protect your application and its users (including using the escaping functions built in to PHP to help remove some harmful input).

Matthew McCool has a few reminders for developers out there thinking of using Ajax in your applications - mainly to remember that it has the potential of adding another vulnerability to your application.

Consider a registration form built out of PHP. Any aspect of your script that accepts and processes data is a potential point of attack. If you add Ajax, what you’re doing is increasing the complexity of the application and, by extension, introducing greater vulnerability. More points of entry equal a larger attack surface, and that means potential problems for your application.

He continues his login form example and mentions a few things you could do to help protect your application and its users (including using the escaping functions built in to PHP to help remove some harmful input).

In a brieft post to the PHP 10.0 Blog today, Stas looks at a topic several PHPers out there have had to struggle with in their math-centric applications - how floats/doubles are handled in PHP.

Just wanted to write about the topic discussed elsewhere - how one could do money calculations with PHP? PHP has no BCD type and no arbitrary precision float type either. And for money calculations is it important to have it very precise - accountants can not allow even single penny to slip by (remember the plot of the Office Space movie?)

He basically says that the precision that PHP alone offers just isn't enough for some kinds of functionality. He also offers his own kind of solution proposal - switching the values back to (arbitrary-precision) integers and making all calculations in hundredth or thousandths of a cent.

Not that, according to Ron in the comments, there is in fact a BCMath extension already built for PHP.

In a brieft post to the PHP 10.0 Blog today, Stas looks at a topic several PHPers out there have had to struggle with in their math-centric applications - how floats/doubles are handled in PHP.

Just wanted to write about the topic discussed elsewhere - how one could do money calculations with PHP? PHP has no BCD type and no arbitrary precision float type either. And for money calculations is it important to have it very precise - accountants can not allow even single penny to slip by (remember the plot of the Office Space movie?)

He basically says that the precision that PHP alone offers just isn't enough for some kinds of functionality. He also offers his own kind of solution proposal - switching the values back to (arbitrary-precision) integers and making all calculations in hundredth or thousandths of a cent.

Not that, according to Ron in the comments, there is in fact a BCMath extension already built for PHP.