This week I've been using phpMyAdmin for what feels like the first time in years. I'm happier at the command line, but needed some graphical representation of information and easy ways to export example queries for the book I'm working on. I noticed that phpMyAdmin now has a Designer tab, which shows relationships between tables and allows you to define them.
I have been writing a bit about Gearman lately, including installing it for PHP and Ubuntu, actually using it from PHP and also how I use persistent storage with Gearman. I'm moving on to look at adding jobs of different priorities.
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.
doHighBackground() and the
doLowBackground() methods insert jobs into the queue and checking out my persistent storage I see that the priorities work like this:
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!
We might still be in the thick of the summer conference season, but there's an event coming up this autumn which has me very excited: PHP North West 2011.
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:
A couple of weeks ago I had the pleasure of speaking at php|tek in Chicago. As usual there were a few great talks, a good crowd of new folk and a selection of established speakers all at the event and I had a great time. This year, there was one particular highlight that I wanted to share: the hackathon.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. This post is the third in the series, following on from the ones about the initial requirements and how to how to handle request tokens.
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.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post.
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.
OAuth Provider Code
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();
Following the principle of "release early, release often", I put live a very early version of the v2 API for joind.in today (so that I can use it in another project!). I haven't updated the documentation yet but in case anyone was thinking of consuming data from joind.in, this at least gives you an idea of the direction of the project so I thought I'd share.
Things you need to know:
- The service is an HTTP Web Service. Meaning it's RESTful apart from when it isn't
- The endpoint is here: http://api.joind.in
- You can fetch data about events and talks (read-only) at this point
- Formats available are HTML or JSON. The service will guess from your accept header but you can override it with
- If you need more columns than you get by default, you can add
?verbose=yesto your request
- Pagination is available, with parameters
resultsperpage(default 20, set to zero for no limits) and
- The service supports OAuth1.0a, which isn't useful at this point as we're read-only but it will come into play as we add functionality
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
disclaimer: I am not underestimating the universe's ability to produce idiots, the point I'm trying to make is that I haven't managed to make any deploy mistakes using this approach. Yet.
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.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I'm sharing my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post.
OAuth Pages and Endpoints
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:
If you are attending my Web Services tutorial at PHP Community Conference (if not, probably nothing for you to see here) later this week then you might like to download the sample code. I'll be referring to this and inviting you to "play along" as I go creating services during the session on Thursday - see you there!