Creating a Closest Store Locator in PHP

Over the past year, one of my side projects has been the development of shopping directory sites for categories such as wargames, sports cards, videogames and farmers markets, the last of which I launched over the weekend. The sites are running on LAMP (Linux, Apache, MySQL and PHP) using my own code and the Smarty template language, which keeps me from cluttering up my web pages with PHP.

As I prepared the newest site, I decided to implement a feature that takes a user-submitted address and finds the closest stores. This functionality was the original impetus for the project -- I thought it would be cool if Wargames.Com had a store locator that could find the closest wargame store when I'm out of town.

To accomplish this, I needed to split latitude and longitude into their own fields in the MySQL database and use the following SQL query to find the closest stores to a user-submitted latitude and longitude:

SELECT *, (3959 * acos(cos(radians({$user_latitude})) * cos(radians(latitude)) * cos(radians(longitude) - radians({$user_longitude})) + sin( radians({$user_latitude})) * sin(radians(latitude)))) AS distance FROM stores HAVING distance < 250 ORDER BY distance LIMIT 0, 10

This query, which I found in a PHP/MySQL tutorial by a Google Maps engineer, employs the Haversine formula to compute distances between two pairs of coordinates on a sphere. The fields latitude and longitude are from the MySQL database. The PHP variables $user_latitude and $user_longitude contain the coordinates of the user address.

An address can be specified many different ways, but most people don't know the latitude and longitude of their location. Fortunately, Google Maps offers a web service that can take an address in a wide variety of formats and attempt to determine its latitude and longitude. The web service, which is a simple URL request, returns the information in either XML or JSON format. It requires a Google MAPS API key:

http://maps.google.com/maps/geo?q=ADDRESS&output=json&oe=utf8&sensor=false&key=YOUR+API+KEY

Plug the address and your API key into the request, changing "json" to "xml" if you want XML data. Here's example output for Disney World in JSON and XML.

I chose JSON over XML because it's easier to work with in PHP. PHP 5 has built-in support for JSON, but my sites are on a server running PHP 4, so I installed the Services_JSON library. After a brutal hour of trial and error that made me question programming as a lifestyle choice, I figured out that the following four lines of PHP code will pull a latitude and longitude out of Google's JSON address data:

$json = new Services_JSON();
$json_data = $json->decode($this->get_web_page($url));
$addr_latitude = $json_data->Placemark[0]->Point->coordinates[1];
$addr_longitude = $json_data->Placemark[0]->Point->coordinates[0];

The get_web_page() function returns the contents of a web page as a string.

I've added the closest-store search to all four sites, which you can try on the home page of Sportscard-Stores.Com. The next project will be to create mobile versions of the shopping sites so users can hunt stores with their phones.

Syndicated 2010-02-01 20:37:30 from Workbench

Book Giveaway: Teach Yourself Java in 24 Hours

My newest book, Sams Teach Yourself Java in 24 Hours, Fifth Edition, recently hit bookstores. The book is a for-absolute-beginners guide to programming Java, and this section from chapter one's Q&A section shows how much license I get from the publisher to have fun with the series:

Q. Do you only answer questions about Java?

A. Not at all. Ask me anything.

Q. Okay, why is Prince mad at the Foo Fighters?

A. Prince is unhappy that the Foo Fighters performed a cover of his song "Darling Nikki" and released it as a B-side single in Australia. He told Entertainment Weekly they should write their own tunes and wouldn't let the band release it in the United States. This became a pretty meaningless distinction as the song became a radio hit around the globe and was played regularly during their concerts.

When Prince performed at Super Bowl XLI a few years later, he covered the Foo Fighters' "Best of You," an artistic decision that surprised the Foo Fighters as much as everybody else.

"It was pretty amazing to have a guy like Prince covering one of our songs," Foo Fighters drummer Taylor Hawkins told MTV, "and actually doing it better than we did."

Although playing someone else's music is an odd way to exercise a grudge, this was a better option for the 5-foot-2 Prince than challenging the band to a fight.

Every chapter ends with one reader question that has bupkiss to do with Java. I used to be the Fort Worth Star-Telegram's Ed Brice, an answer man who fielded random questions, so old habits die hard.

My book has been fully updated for Java 6 and has new chapters on JAX-WS and game programming. I have 20 copies I'd like to give to people who want to learn Java, and there's still time for me to mail them before Christmas.

If you know someone who wants to learn Java, or you can make a convincing case for why Santa owes you this book after the year 2009 you just endured, please leave a comment here on Workbench or in a Twitter post to rcade. Make sure I have some means of contacting you, so I can get the address of the person getting the book.

I'm planning on mailing these out on Wednesday morning in the pre-Christmas scrum at the post office. I will mail the books directly to the people receiving them and can put your name and address as the sender and wrap them if necessary. No one needs to know I was involved.

Please note that I'm expecting the people who get this free book to teach themselves Java in a single contiguous 24-hour period. For too long, Sams has coddled readers who devote one hour a day to a subject and learn it at their leisure.

Syndicated 2009-12-14 18:10:10 from Workbench

Saving Bandwidth on RSS Feed Details

With the current interest in rssCloud and PubSubHubbub (PuSH), I've been thinking about all the bandwidth that's consumed by the RSS elements that describe the feed. When a client requests an RSS feed 10 times in one day, it gets the basic details of the feed over and over again. When clients request the Workbench feed, they get 1,800 characters containing optional RSS elements that I haven't changed in years, except for the PuSH element I added last month. Workbench has 1,900 feed subscribers, so if they average 10 checks a day, they're consuming 32 megabytes every day on information they know already.

James Holderness directed me to RFC3229+feed, a method to request partial RSS feeds that omit elements that a client has already seen. That's useful and has been adopted by some feed publishers and clients, but as far as I can determine, the approach still sends all of the channel elements that describe the feed itself. I wanted to float an idea here to see if it would be useful:

<rssboard:feedDetails>
  http://ekzemplo.com/feedinfo.rss
</rssboard:feedDetails>

This channel-level RSS element identifies a URL that contains the full details about the feed. The details would be expressed as an RSS feed without any item elements.

An optional ttl attribute could contain the number of days the publisher would like clients to cache the information before checking it again:

<rssboard:feedDetails ttl="30">
  http://ekzemplo.com/feedinfo.rss
</rssboard:feedDetails>

A feed publisher who wished to make use of this could move all channel elements except for title, link, description and atom:link to the detail URL. Title, link and description are required in RSS, and atom:link identifies the feed's URL so it can't be moved.

Syndicated 2009-10-13 13:01:25 from Workbench

PubSubHubbub is a Lot Easier Than It Sounds

I've begun digging into PubSubHubbub, the real-time RSS update protocol created by Brad Fitzpatrick and Brett Slatkin of Google and Martin Atkins of Six Apart. I was under the impression that it's harder for RSS publishers to use than the RSSCloud Interface, but that isn't the case. The specification is simple and precisely written, adopting conventions like RFC 2119 that make a spec considerably easier to understand, and it communicates using basic HTTP requests.

I wrote the software that runs the Drudge Retort, so I decided to add Pubbub support to it this morning to see how it works. (I'm tripping over the name "PubSubHubbub" like crazy, both when I write and speak, so I'm giving the protocol a nickname.) Pubbub delegates all the work required for update notification to a server called a hub. Google offers a hub at http://pubsubhubbub.appspot.com/ that's free for use by all feed publishers, so I'm relying on it.

First, I added a link element to the Retort's RSS feed that identifies the feed's update hub:

<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />

Because this element comes from the Atom namespace, I had to make sure it was declared in the feed's top-level RSS element:

<rss version="2.0"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:sitemap="http://www.sitemaps.org/schemas/sitemap/0.9">

The bold portion is the Atom declaration. I already was using an Atom element in the feed, so I didn't need to change this.

When a new story is posted on the Retort, the Pubbub hub must be notified that a change has occured. This is handled by sending a ping to the hub with the URL of one or more feeds that have been updated.

I've written an open source Weblog Pinger library in PHP, so I upgraded it to support these pings. A Pubbub ping employs HTTP requests (REST) instead of XML-RPC, the protocol used by Weblogs.Com and similar services. I wrote a new function, ping_rest(), that can send a ping to any Pubbub server.

By the time I was done, I'd spent an hour on the code and a few hours testing it out. So now when I post a new item on the Retort, Google's Pubbub server sends the full text of the item to all readers that support the protocol. This is faster and simpler than RSSCloud, which tells readers to request the feed again.

To give you an idea of how fast Pubbub can be, when I posted a new story on the Retort, it showed up 20 seconds later on FeedBurner, one of the first RSS services to support the protocol.

Syndicated 2009-09-17 20:01:54 from Workbench

RSSCloud Should Not Be Controlled by One Person

I posted a call for comments last night on RSS-Public, the mailing list of the RSS Advisory Board, asking what people think the board should do in response to the ongoing effort to revise the RSSCloud Interface.

The interface has been a part of the RSS specification since the publication of RSS 0.92 in December 2000. It determines how software can use the cloud element in an RSS feed to connect to a server that offers real-time notifications when the feed has been updated. In a nutshell, here's how it works:

• A user subscribes to an RSS feed that has a cloud element which identifies its cloud server.
• The user's RSS reader contacts the cloud server, asking to be notified when the feed is updated.
• When the feed has been updated, the software publishing the feed sends a ping to the cloud server.
• The cloud server sends a notification to the IP address of all RSS readers that asked for updates.
• The RSS readers immediately request the feed.

Cloud communications can be sent using XML-RPC, SOAP or REST aside from pings, which are sent using XML-RPC.

Dave Winer recently began an effort to revise RSSCloud, persuading WordPress founder Matt Mullenweg to adopt the still-in-progress proposal on all 7.5 million blogs hosted on WordPress.Com. Winer has made three significant changes to the interface.

First, he changed the fifth parameter of a notification request on the REST interface to a series of named url parameters (url1, url2, and so on upwards), each containing the URL of a feed monitored by the cloud.

Next, he added a new ping format to contact cloud servers using REST.

Finally, he has proposed adding a sixth parameter to the notification request, but only for REST requests. The sixth parameter, called domain, identifies a server that will receive notification updates from the cloud server. It's an alternative to using the IP address for notifications.

Winer, the lead author of several versions of the RSS specification and one of the best-known authorities on syndication, is making these changes unilaterally.

Because RSSCloud has been a part of RSS for nine years, I thought it wise for the board to decide what, if anything, it should do regarding this effort. My personal belief is that it's extremely unwise to give a single developer the authority to revise this interface and author its specification.

Ideally, a group should decide what changes should be made to the next version of RSSCloud. This group could be the RSS Advisory Board, which deliberates in public and has 10 members from across the RSS development community, or it could be an ad-hoc group formed strictly to work on the effort.

As a member of the board for five years, I've had a lot of experience dealing with the consequences of a specification process that is closed to public participation and drafted with imprecise language. It leads to situations like the long-running battle over the enclosure element, which carries podcasting files and other multimedia over RSS. As described in the board's RSS Best Practices Profile, the RSS specification doesn't make clear whether an item can contain more than one enclosure. Developers disagree over what the specification means, so interoperability suffers as some allow more than one enclosure and others don't.

I realize that I'm tilting at windmills to suggest that Winer let the RSS Advisory Board get anywhere near the effort. Jon and Kate have a better chance of getting together. But as developers such as Mullenweg implement RSSCloud, they should insist that the revision process take place in public and involve a group of software developers and feed publishers who have the power to approve or reject each change. The group should write the specification together.

Letting Winer make all the decisions by fiat will just buy years of arguments over what his spec means and why no one should ever be allowed to change it.

Syndicated 2009-09-15 20:47:36 from Workbench