On the IBM developerWorks site, there's a tutorial from Vikram Vaswani showing you how to connect to Wikipedia's API in your PHP application. It shows how to fetch, search and update entries through their backend. The tutorial's a little bit older (from May 2011) but the content is still relevant.

Wikipedia is the ultimate online encyclopedia, containing millions of entries on different aspects of human knowledge. Web application developers are able to access and search these entries through the Wikipedia API. This article introduces the Wikipedia API and demonstrates it in the context of a PHP application, explaining how to search and retrieve different elements of Wikipedia content with PHP.

He starts with a general introduction to the API including example feed results and URL request formats. From there he moves into the code - a mostly Zend Framework-driven example that uses the REST client. He shows how to make requests for categories, full-text search, grabbing raw page content and adding/editing the content of pages.

Maarten Balliauw has announced the release of a PHP port of a powerful tool for server-side introspection of your applications - Glimpse for PHP.

A few months ago, the .NET world was surprised with a magnificent tool called "Glimpse". Today I'm pleased to release a first draft of a PHP version for Glimpse! Now what is this Glimpse thing… Well: "what Firebug is for the client, Glimpse does for the server... in other words, a client side Glimpse into whats going on in your server."

He includes a of how the introspection works and some sample code using a phar to add it to your PHP application. You can see it in action in this screencast based on the PHP Azure Contest website. He also shows one very cool feature that allows for cross-device tracking of requests. You can find this PHP port of Glimpse on github.

In a recent post to CodeForest Luka Peharda shows you how to create a JSON-RPC frontend for your application based on the Zend Framework.

XML-RPC rules, but the amount of data it generates is its big disadvantage. This is where JSON-RPC steps in. Data it generates is significally smaller, but this isn't suprising as JSON is known as fat free XML.This articles is based on my earlier Android XML-RPC article. Its PHP code and Zend Framework setup will be used so you should go through it if you haven't earlier (at least as far as XMLRPC Android client chapter).

You need to have some of the base code from the previous article in place to follow along, but if you're experienced with Zend Framework, keeping up won't be a problem. He uses this JSON-RPC client that was made for use with a ZF application and creates a basic jsonAction to handle the request. He then uses this Android JSON-RPC library to connect from the Android application and fetch some basic data.

In a follow up to his previous post on using Neo4j with PHP, Josh Adell looks in a bit more detail about how to find paths in the data via a REST interface to the database.

The thing that makes graphing databases useful is the ability to find relationship paths from one node to another. There are many algorithms for finding paths efficiently, depending on the use case.

He includes some code showing the REST request (made via this client) to fetch these street-based relationships. He then creates a little sample script that provides driving directions from one intersection to another with a "findPathsTo" call. He modifies it a bit later on to use the Dijkstra algorithm.

Michael Dowling tipped us off to Guzzle, a RESTful web service client framework that lets you build testable web service clients quickly and easily.

Guzzle helps you speed up the process of creating a RESTful web service client by giving you full control of HTTP requests and access to advanced features like persistent HTTP connections, parallel requests, exponential backoff, over the wire logging, MD5 validation, cookie jars, and a caching forward proxy.

Installing the framework is as easy as grabbing the phar archive and including it in your application. Some sample code examples are included right on the front page - a simple client pulling down an XML file, grabbing Amazon S3 content, working with the HTTP request on a finer scale and making parallel requests.

New on DZone.com today there's an article from Bas De Nooijer talking about a new tool he's created to allow PHP to work directly with Solr (the popular searching platform from the Apache project) as a result of research he'd done from a previous article. The result is < href="https://github.com/basdenooijer/solarium">Solarium, an open sourced PHP client for Solr.

I've worked on a lot of Solr implementations in PHP applications. There are multiple solutions: manual HTTP requests, the solr-php-client library, custom implementations etcetera. However they all have one issue in common: they only handle the communication with Solr, many other important parts like query building are not covered at all. And the parts that are covered are usually over-simplified. [...] At first I developed it as a library for my own projects, but I've decided to turn it into an opensource project. The project is called 'Solarium' and can be found on github: https://github.com/basdenooijer/solarium

You can find complete details about the project over on its wiki including basics concepts of query flow and using the ping/select/update query methods to access your Solr server.

Gonzalo Ayuso had previously shown how to dynamically add watermarks to your images with the help of a mod_rewrite rule. One of the side effects of this is that, with a high load on your server, things can get bogged down quite quickly. His alternative? Add the watermarks to your images with Gearman workers.

In this second solution I will use a gearman worker to generate the watermarks. The benefits of gearman is the possibility of use a pool of workers. We can add/remove workers if our application scales. Those workers can be placed even at different hosts, and we can swap easily from one configuration to another.

He includes some sample scripts to illustrate the process - a Gearman client that'll call the watermarking process and a worker that takes in the image and transforms it with GD to add a new layer for the watermark.

Chris Jones has posted more information to his Oracle blog about the caching and other improvements that come along with the Oracle 11gR2 release that can be used in PHP applications.

Oracle 11.2 brought several improvements to Client Result Caching. CRC is way for the results of queries to be cached in the database client process for reuse. [...] PHP OCI8 as a "client" of the database can use CRC. The cache is per-process, so plan carefully before caching large data sets. Tables that are candidates for caching are look-up tables where the network transfer cost dominates.

Like many of the other server-side tools Oracle has to offer, it's pretty simple to enable this caching. Before you had to add a custom bit to your query to tell it to enable the caching. Now it's as simple as setting it up on the CREATE or ALTER for the table - nothing extra for the developer to do.

Cal Evans has posted the eighth tip in his six-tip series (but who's counting) about how a client can coordinate better with a developer and make a better relationship for the project. In this new tip, he suggests that the client "own it".

No, I'm not talking about own it as in Point 7 - "Do your part", I mean make sure that at the end of the project, you own the project, not your developer.

He mentions two of the aspects you, the client, will need to worry about once the last line of bug free code has been committed and delivered. Be sure that you own the domain name for the project and have a clear understanding of any intellectual property concerns that might come up (what codebase is it built on, who owns the code - client or developer, etc).

Cal Evans has snuck in a seventh part of his six-part series looking at what you, the client, can do to help make the relationship and contract between you and your developer better. This new post talks about doing your part.

robably the second most common reason I've seen projects fail is because the client fails to live up to their commitments. No I'm not talking about hitting your payment milestones, I'm talking about delivering your content.

Without everything they need to get the job done, the developer(s) cannot hit the marks you both laid out in the contract. Show them that you're committed to the project by delivering your side of things too.

Don't be the reason that it misses it's delivery date. Also, don't expect your developer to work extra hours to get the project back on schedule just because you failed to meet your obligations.