I reviewed the coordinates given by existing members and noticed a good number had visibly inverted latitude and longitude; so I inverted them again to place them where it appeared to make more sense (are there really PHP-GTK devs in the middle of the pacific, or near the South pole ?). So you may want to double-check your coordinates to make sure the values are correct, because it's likely I've not found every error.

He's also asking for the Brasil PHP-GTK community to include their information in the map as well as a request for anyone out there that might want to make a "prettier" icon for showing the developers on the map.

First, many thanks to all the participants. Thank you to Zend, Adobe, php|architect and Ibuildings for providing prizes. Thank you to phpwomen.org for being out judges. Thank you to Damien Seguy for creating the elePHPants. Thank you most of all the the PHP community for being such a fun-loving bunch of nuts.

And the winners are:

• First Place - Stefan Koopmanschap, One Fell Asleep
• Second Place - Keith Casey, No, we're not taking any questions
• Third Place - Michelangelo van Dam, An Army of elePHPants

2008 is over, which means the Elephpant World Tour is coming to an end! The contest that started in September got over 240 entries! That is a whopping 60 elephpant pictures a month. The PHPWomen, who we managed to convince to be the judges for the contest, are now going to sift through all the posts and select 3 winners

Prizes include subscriptions to php|architect magazine, a copy of Zend Studio Professional, a ticket to the Dutch PHP Conference and a license key for the Flex Builder Professional software (from Adobe).

Stay tuned for the list of winners when they're posted!

Here's the basic premise. It seems obvious that elePHPants love to travel. Equally obvious is the fact that a lot of PHP developers love to take pictures. So, let's combine the two. If you spot an elePHPant while traveling, like near a landmark, or making it's way through the airport, snap a picture. Upload it to flickr and tag it with ewt08. Thanks in no small part to a bit of Web 2.0 magic and Wordpress, we'll steal the picture from flickr and post it on the blog.

In January of 2009 the PHP Women group will take a look at all of the photos and pick the best ones. There's multiple prizes so far including a copy of Zend Studio Professional and admission to the Dutch PHP Conference '09 (check out the about page for more).

I recently came by this site WorldTimeEngine where users can search the local time of any place using the name, street address or just latitude and longitude. Since that time I was thinking how easily you can make your own. As long there are some good people over there (For Geocoding API) - its a not a big deal, you know?

His script pulls the location of the place (latitude/longitude) from the Yahoo! geocoding API and passes that back into the geonames web service to get the local time. The result is an array with the lat/long, address you submitted and the time output in a standard string.

Whenever someone asks me why PHP is more "agile" than Java, I tell them that in PHP you can break most of the rules your comp sci course told you about and get away with it. Of course this means that you need PHP developers to constantly clean up their code.

He talks about rules for developing in PHP, one being not to change a method so make it incompatible with its parent. He recommends one way to avoid this - the E_STRICT warning to protect against possible conflicts and issues (the same kind of functionality in PHP6 is in E_FATAL though).

Please, lets get the sense back here. Lets not make things that are not fatal an E_FATAL. Lets use E_STRICT for the pedantic, lets add a E_DEPRECATED for all things deprecated. Lets not kill what makes PHP more agile than those other languages that think they know what I should be spending my time on.

The ability to run two or more commands in parallel is totally sexy, but the Web is a different playing field and it doesn't make complete sense.

PHP loses control, once the output is sent and the connection is closed. Multithreading would probably make sense in streaming, but PHP already handles that for you where it makes sense for the function. Furthermore, mulithreading has its purpose in applications that continue to run and not something that closes and cleans up everything after the last command is issued.

He continues talking more about what multitasking is, a more real life example, the goods, the bads, and some of the issues that can come along with it. Finally, he suggests a feature to be added to the core of PHP - an "internal multitasking mechanism" to help aid these kinds of processes.

The things you can get discounts on include:

• magazing subscriptions
• the PHP Essentials Course
• the Professional PHP Course
• tons of PHP-related books

If you've been waiting to make that purchase from php|architect, now is definitely the time to make your move! Remember, it's today only, so hurry!

So far, he's already gathered a few - two from Pxy, one from Stanford, and another from the Secure Systems Lab (at the Technical University of Vienna).

The concept's pretty simple - the form they build submits back to the page and writes the input out to a file. This file is then read by the controller for the LED they have connected and, with the proper input, will turn it on and off. The code for the PHP/web side of things is included, but it might take a little work to get the rest of the hardware interfaced (as the author saw as well).