I use Gearman entirely as a point to introduce asynchronous-ness in my application. There is a complicated and image-heavy PDF to generate and this happens on an automated schedule. To do this, I use the GearmanClient::doBackground method. This inserts a priority 1 job into my queue.
Using the doHighBackground() and the doLowBackground() methods insert jobs into the queue and checking out my persistent storage I see that the priorities work like this:
| priority | method | 0 | doHighBackground() |
1 | doBackground() |
2 | doLowBackground() |
|---|
Gearman works out which task is the next highest priority and will hand it to the next available worker – which means that I can set my automated reporting lower priority than the reports requested by real live people wanting them now, and everyone is happy!
The problem arises because if we simply check that there’s a positive return value from the function, we’ll miss the case where the string appears at the start of the other string since the character offset will be zero:
$tagline = "PHP Made Easy";
if(strpos(strtolower($tagline), 'php')) {
echo 'php tagline: ' . $tagline;
}
This code won’t find the “if” to be true, since strpos returns zero and PHP will type juggle that to be false (debates about dynamically typed languages can be saved for another day)
This is a great example of where the === operator really helps, as it can tell the difference between false and zero:
$tagline = "PHP Made Easy";
if(false !== strpos(strtolower($tagline), 'php')) {
echo 'php tagline: ' . $tagline;
}
This time, we’ll correctly get into the “if” even if the string appears at the start of the other string.
Not a particularly complex example but I think one that is simple enough to serve as a reminder as to what that extra = is for!
This is a regional PHP conference based in Manchester, UK, and I’ve been involved with it since it began (I’m surprised to find this is our fourth edition, it still feels like a shiny new adventure!). This year the dates are 8th and 9th of October and with an added tutorial day on the Friday, it is bigger (and of course better) than ever. In case you missed the announcements, here are the main things you need to know:
This phase is probably the most familiar to us as developers, as it’s simply a login form. The consumer will send the user to us at the URL we provided in the request token, and the user will have the request token key as a parameter. The access control on this page will look the same as on the rest of the website; if the user has a session already then the page is displayed, otherwise they must be logged in to see it.
The consumer requests a request token (see my earlier post about consuming OAuth), and as a provider, we need to handle that request. In my example, I chose to pass the variables as GET parameters, but you could adapt this to handle POST variables or information contained in HTTP headers.
We have the same block of code called on every request where we’re negotiating OAuth, and it looks like this:
$this->provider = new OAuthProvider();
// set names of functions to be called by the extension
$this->provider->consumerHandler(array($this,'lookupConsumer'));
$this->provider->timestampNonceHandler(
array($this,'timestampNonceChecker'));
$this->provider->tokenHandler(array($this,'tokenHandler'));
// no access token needed for this URL only
$this->provider->setRequestTokenPath('/v2/oauth/request_token');
// now check the request validity
$this->provider->checkOAuthRequest();
Things you need to know:
?format=json or ?format=html?verbose=yes to your request
resultsperpage (default 20, set to zero for no limits) and start (default zero)Events list: http://api.joind.in/v2/events
Information about DPC11: http://api.joind.in/v2/events/603
Talks at DPC11: http://api.joind.in/v2/events/603/talks
Comments are welcome on this post. Bugs and feature requests should go to http://joindin.jira.com, read more about Joind.in and its community at http://joind.in/about
Once upon a time, a long time ago, I went onto a conference stage for the very first time and said that I thought I might be the world’s ditsiest PHP developer. I actually still think that is pretty true, and if you work with me then you will know that I mostly break and fix things in approximately equal measure. With this in mind, when I launched my own product recently (BiteStats, a thing to automatically email you a summary of your analytics stats every month), I knew that I would need a really robust way of deploying code. I’ve been doing a few different things for a few years, and I’ve often implemented these tools with or for other organisations, but I don’t have much code in production in my own right, weirdly. I decided Phing was the way to go, got it installed, and worked out what to do next.
OAuth has a little more baggage with it than just passing a username and password to an API. As well as your standard service endpoint you will need:
Continue reading