Oauth is an open standard for authorization that allows secure authorization from web, mobile and desktop applications. This standard allows a third-party application to gain access to a HTTP service, i.e. it enables users to share their resources from one website with another website without having to give out their credentials (usually username and password). [...] Oauth authorization is carried out in 3 steps: obtain a request token, authorize request token and exchange request token for an access token.

They introduce you to some of the basic concepts behind OAuth and how the process works (complete with a handy graphic). They then show how to use OAuth to connect to the Facebook API, both in Javascript then PHP. This is followed with two other examples referencing popular social sites Twitter and Foursquare, hitting their APIs with simple authentication requests.

If we are working within a Symfony2 application or a PHP application that uses the Symfony's Dependency injection container component you can easily integrate this simple script in the service container. I will show you the way that I use to do it.

His sample code uses the Guzzle HTTP library and some configuration options from a YAML file to create a new service hooked into the Twitter API with his credentials. He then imports it via his services configuration and shows an example of it in action - getting the latest contents of his timeline.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

• Response codes not matching the content (ex. 200 on an error)
• NullPointerExceptions
• Different endpoints for single vs collections
• Order-sensitive XML in requests
• Poor error handling
• Bad documentation
• Incorrect content type handling

So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.

Bootstrap is a well known and powerful front-end framework for fast prototyping, it uses LESS and it can be easily integrate in your Symfony applications with the help of assetic. In this post I'll show how to: Install bootstrap in you Symfony application, load it using assetic, and compile bootstrap LESS files with lessphp.

Using Composer, creating a new Symfony2 project is just a single command away. The just update the "composer.json" and run the install to get the other needed libraries (LESS and the Twitter Bootstrap). They help you set up some Assetic filters for LESS and provide a simple page to output the Bootstrap in your header.

Yesterday an ex colleague tweeted something that captured my attention, so I started thinking to a Twitter-powered code golfing competition. Looking for other examples.

Tweets included in the list are snippets like:

• A dependency injection container
• A super simple web framework
• A microframework
• Bypassing array_intersect

There's some game rules included in the post so you can contribute your own to the the comments. Several have already been added including a base64 encoding variant and getting the extension of a file.

A brand spanking new Forms component has been rolled out with ZF2. The long and the short of this new component meant that I had the opportunity to hand roll a new way of making my forms work with Twitter Bootstrap. So, a little tinkering, a quick pull request to ZF2 to allow the definition of arbitrary options and I came up with some useful View Helpers that can be dropped into a project and used.

He includes the code for the sample class ("MyForm") and highlights the "bootstrap" portions of each element's configuration and walks you through some other handy features of his helpers: auto-rendering forms, a "row" helper and a "collection" helper to help organize the form structure.

GrUSP is organising a tweet contest and its prizes will be two tickets, one for each conference. The contest will start today (March 29th) at 1pm CEST and will end April 1st at 7pm CEST.

Anyone can enter - all you have to do is tweet a post with a few things: the "#grsup" hashtag, a mention of the twitter accounts for the events, a link to the conference site and something about the event. Be sure and get those tweets posted before April 1st a 9am CEST - they'll pick the winners soon after! (Oh and multiple entries are accepted so the more you tweet, the better your chances!)

Unfortunately the Symfony documentation does not provide any details on how to configure Assetic to use LESS. There is a blog post by Dustin Dobervich that gives some pointers, but after following the instructions, Assetic issued the following error: Cannot find module 'less'. We searched around without much success. After several tries, we nailed the configuration.

It's an easy two-step process: first you be sure you have "npm" (the package manager) installed on your system, then you modify your Symfony app.yml file to point to the Node modules path.

All of the stories on PHP Quick Fix (you can also follow it on twitter) are still hand-selected out of the mounds of PHP content that shows every day to ensure the best quality. There's no automatic syndication here - just more good, useful PHP (and related topics) to add to your day.

Additionally, if you're interested to see how it all works (thanks to a GimmeBar backend) check out this post on blog.phpdeveloper.org.

Earlier today, more for my own interest, I asked the question on Twitter "What programming rules should you ALWAYS follow, regardless of the scenario you're working in?" In other words, are there programming rules that you ALWAYS should follow. It doesn't matter if it's a script to copy a bunch of files for a one time migration or if you're building the next Facebook (DON'T try to build the next Facebook. You will fail miserably. Build something else). In other words, what was the purist of programming rules.

Responses he received ranged from the simple to slightly more complex including:

• Always comment your code
• Test your code
• Use source control
• "Think. Think again. Then write code"
• Use a good debugger to help track down problems
• Make effective use of logging/output