Personas are a powerful tool for helping you to better understand the needs of your users. In this comic, drawn exclusively for Think Vitamin, you’ll learn more about Personas and how they’ll revolutionize the way you design and build web sites.

Come hear Dan Cederholm, Jason Santa Maria, Joshua Davis, Bill Buxton, Daniel Burka, Elliot Jay Stocks and more speak at The Future of Web Design NYC on Nov 16 – 17th.

More about Personas

Putting Personas Under the Microscope
cooper.com/journal/personas

The Origin of Personas
cooper.com/journal/2003/08/the_origin_of_personas.html

Getting from Research to Personas: Harnessing the Power of Data
cooper.com/journal/2002/11/getting_from_research_to_perso.html

Personas and Goal-Directed Design: An Interview with Kim Goodwin
uie.com/articles/goodwin_interview

What’s your customer’s persona?
usatoday.com/money/smallbusiness/columnist/abrams/2005-02-18-persona_x.htm

More from Indi Young:

Book: Mental Models
rosenfeldmedia.com/books/mental-models

Look at it Another Way
alistapart.com/articles/lookatitanotherway

More comics from Brad Colbow:

Misunderstanding Markup
smashingmagazine.com/2009/07/29/misunderstanding-markup-xhtml-2-comic-strip

Alignment in design:
sixrevisions.com/web_design/the-brads-alignment-in-design

The Brads, a weekly web comic
bradcolbow.com

At FOWA London 2009 Bruce Lawson gave an introduction to HTML 5 and how it might be used in the future.

The HTML 5 spec was originally called “Web Applications 1.0″. Most of the attention has been on the new markup elements, but in his talk he takes a further look at the applications side of the spec, covering:

1. Dynamic images and graphs with canvas
2. Eliminating much forms validation with webforms 2.0
3. Local storage automagically saving your data
4. Geolocation
5. Building toolbars and menus.

Editor’s Note: We’ll be covering “How HTML 5 is Going to Completely Change your Web App” at The Future of Web Apps in Miami.

You can jump straight to the video, view the slides, read the transcript (thanks @joeloverton for doing this!), or check out the resources he demos in the talk:

• Eye-candy canvas
• canvas first-person shooter
• canvas first-person gifter
• the excanvas library to port canvas to Internet Explorer
• Filament Group’s jQuerty plugin using canvas for graphing data tables
• Raphaël JavaScript Library to make SVG that also works in Internet Explorer
• SVG Web is a JavaScript library which provides SVG support on Internet Explorer (Alpha code: not ready for production)
• My HTML5 forms demo, including range, date, placeholder, regex validation (Try in Opera and Chrome)
• modernizr – A small HTML5 capability detection library
• HTML5demos.com – Remy Sharp’s demos of geolocation, offline storage and web database and many others
• Video demos

Other useful resources:

• SVG vs. Canvas on Trivial Drawing Application: a comparison of canvas and SVG
• HTML5 Authors spec
• A video of Dean Edwards demoing his unreleased JavaScript library that detects and plugs the holes in current browsers’ HTML5 support

There are some great beginner canvast tutorials on the Opera Developer:

1. HTML 5 canvas – the basics
2. Creating an HTML 5 canvas painting application
3. Creating pseudo 3D games with HTML 5 canvas and raycasting
4. Creating pseudo 3D games with HTML 5 canvas and raycasting: Part 2

The video

Full transcription available at joeloverton.com/html5. We’d like to say a HUGE thank you to @joeloverton for doing this transcription!

The slides

In this video from The Future of Web Apps London (FOWA), Kevin Rose, founder of Digg, WeFollow and Revision3, shares 9 things he did to increase his users to 1,000,000 and beyond.

Here’s a quick bullet-point summary. You can watch the video, view the presentation slides or download the audio.

If you enjoy this article, you’ll love The Future of Web Apps Miami. Speakers include: Twitter, Mint.com, Gary Vaynerchuk, jQuery, Reddit and more. Buy your ticket now.

#1. Ego

1. Ask yourself: Does this feature increase the users self-worth or stoke the ego?
2. If a user is contributing to my system, what emotional rewards do they walk away with? What (visible) rewards will they receive?

#2. Simplicity

1. Stop over building features
2. Pick 2-3 things to focus on
3. Ask yourself: Is there anything I can take out of this feature?

#3. Build & Release

1. Stop thinking you understand your users
2. Learn from what they’re actually doing on your site, not what you think they’ll do
3. Decide on what you’re going to build… and build it (avoid analysis paralysis)
4. Build, release, iterate, and repeat

#4. Hack The Press

1. Invite only system (Pownce, Digg v3)
2. Talk to the junior bloggers
3. Attend parties for events you can’t afford – network w/influencers, bring a demo

#5. Connect with your community

1. Start a podcast (it’s OK if not everyone listens)
2. Throw a launch party, then yearly/quarterly  events – invite the press/influencers personally – don’t tell the bar
3. Engage w/the community, be an active participant your own ecosystem

#6. Advisors

1. What technical problems are you going to have?
2. Advisors can be helpful in a whole slew of areas (marketing/hiring/bizdev)
3. Stock compensation, typically not a board seat, solid advisors help during fund raising

#7. Leverage your userbase to spread the word

#8. Does your product provide value for 3rd party sites?

#9. Analyze your traffic

1. Install Google analytics
2. Entrance sources (search?)
3. Paths through site
4. Top exit pages

The Video

In this video from FOWA London 2009, Francisco Tolmasky will demo Atlas, a new visual tool for building web apps and desktop apps. It will blow your mind and change what you thought was possible with web apps. This is new footage that has not been shown to the public ever before.

Editor’s Note: Only eight hours till we launch FOWA Miami 2010! There’s only 20 Super Early Bird tickets at 47% off, so be quick (only 440 seats total, so the show will definitely sell out early). Speakers include: Twitter, Reddit, Mint.com, jQuery, Palm Pre, FreshBooks, Opera and PayPal. Keep an eye on events.carsonified.com for the launch at 9am EST.

Want to reach more than 500 million users with your social app? OpenSocial is the key. The OpenSocial standard will allow you to build apps that work across a number of massive social networks, including MySpace, Orkut, Ning, hi5 and LinkedIn (complete list).

OpenSocial defines an API for developing social apps and was designed in cooperation with multiple social networks right from the start. Amongst many others, companies like Google, Yahoo!, LinkedIn and MySpace support the interface.

Editor’s Note: Looks like The Future of Web Apps will definitely sell out. Speakers: Twitter, Facebook, Google, Six Apart, digg / Kevin Rose, Mozilla, Dustin Diaz and more.

OpenSocial Tutorial

I’m going to walk you through building a simple chat application using the OpenSocial API. You can download the complete code for the application here.

If you want to follow our example in code, a few smaller preparations are necessary. These are necessary mainly because of the fact that OpenSocial development only really makes sense inside of a real social platform which provides the API. Isolated on your home desktop it makes little sense because the basic platform is only available online, from the inside (embedded into) the platform.

For our example, you need a free Orkut account (a valid Google account is also sufficient) and access to the Orkut developer sandbox. The setup of your Orkut account including access to the developer sandbox is described in the document OpenSocial-Tutorial for Orkut in the segment “Running your first Gadget”.

Because chatting without friends isn’t very exciting, it’s vital that you also add a few friends to your Orkut account. If you can’t get any of your colleagues to also register for the Orkut sandbox, you can simply create a second Google/Orkut account, open that one in another browser, add yourself (the other Orkut account) as a friend and then install the app as well.

If you want to program your own Gadget and also make changes to the example code provided, you need a little webspace, including PHP and a MySQL. The other preparations for this are documented in the Readme file in the download archive.

Google Gadgets as a Foundation

The basis for an OpenSocial application is a so-called Google Gadget, which could be familiar already to some developers from experiences with iGoogle, e.g.

A Gadget is an XML document and is merely the frame for an OpenSocial app.
An exemplary Gadget definition could look as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Chat Tutorial">
      <Require feature="opensocial-0.8" />
  </ModulePrefs>
  <Content type="html">
      <![CDATA[
         // here comes our application code...
      ]]>
  </Content>
</Module>

The real application code is defined within the <Content> node of the Gadget and consist of HTML and JavaScript (while the embedding of Flash or Silverlight objects is possible too). All following JavaScript code snippets in this article belong inside of this <Content> node.

Initialize the App

Because we work with JavaScript within our Gadgets, at first we should wait until the page has completely loaded to be able to initialize our application cleanly. From Javascript frameworks like jQuery or Prototype you’re probably already used to getting informed as soon as the DOM is ready and we can begin with the initialization. Google’s Gadget-API also has such a helper function:

gadgets.util.registerOnLoadHandler(function(){
    load_friends();
});

Querying for Data in OpenSocial

An important part of our chat application is a simple list of our friends. To find out who our friends are (and how many we have) we ask our social network container (which is Orkut in our example). The corresponding JavaScript function “load_friends”, which we called on initialization, looks like this:

function load_friends(){
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER), 'viewer');
    var friends = opensocial.newIdSpec({ "userId" : "VIEWER", "groupId" : "FRIENDS" });
    req.add(req.newFetchPeopleRequest(friends, {}), 'viewer_friends');
    req.send(on_load_friends);
}

From this example we see how data queries work in OpenSocial:

In the first line we create a “DataRequest” object. All requests which we would like to have answered are appended to this object subsequently; in our example we first add a query for the profile data of the “Viewer” and then a query for his friends by calling req.add().

Because we work exclusively with JavaScript and HTML here, data queries are also carried out asynchronously through JavaScript (using AJAX).

It’s only in the last line of our example that the request is really sent through req.send(). It’s worth noting that, with this concept of querying, we can immediately take care of several data queries in only one request – instead of needing several AJAX requests and generating traffic and latency several times. Google calls this procedure “batch requesting”.

At the same time, looking at that code snippet, you can clearly see what it’s all about in OpenSocial: it’s about “people data” and the relations of the people to each other. Two types of persons are the most interesting, which is why the API defines them as constants:

One of them is the “VIEWER”. The Viewer is the (logged in) user who’s looking at the profile page on which our application is installed. The other one is the “OWNER”, which is the owner of the profile page on which the Gadget is installed. It is perfectly possible that the Owner and the Viewer at times are the same user – when the owner is looking at his own profile page, using the application.

In addition to Viewer and Owner, it is also possible to request data about other users by their user ID.

As we sent off our requests we had given an additional parameter to the method req.send(). This was the reference to the function “on_load_friends” which is used as a callback and is automatically called as soon as our request was answered and returned data. Therefore, we can access the results of our query – the person data we asked for – inside of the function “on_load_friends”:

function on_load_friends(data) {
    var viewer = data.get('viewer').getData();
    var friends = data.get('viewer_friends').getData();
    ...
}

Accessing our data through the method “get()” is necessary because of the “batch requesting”. While putting together the query, we had provided the strings ‘viewer’ respectively ‘viewer_friends’ as a last parameter. This was necessary because we wanted to request multiple data packages in one go – and of course we want to be able to distinguish them again at the end. Through data.get (‘viewer’).getData () we get the return values which we had named ‘viewer’ when we put together the request.

Now in the next step we want to show our friends in a list:

friends.each(function(friend) {
    friends_html += '<div class="friend_name"> '+ friend.getDisplayName()+ '</div>';
});

Those of you who have already worked with Ruby or the JavaScript framework Prototype will probably know the “each” notation. The OpenSocial-API provides this function, too. We use it here to iterate through the records of our friends.

By calling “getDisplayName()” on each of our friends records we use a special function of OpenSocial.

Most data fields are specific for a certain platform. This means e.g. that a field called “hobbies” that exists on MySpace might not exist in another container like Orkut at all. To at least be able to show a display name – in any case, and on any platform – a sensible return value from getDisplayName is guaranteed by the API.

In other cases we should be more careful by explicitly checking if a certain field that we’re trying to access really exists:

opensocial.getEnvironment().supportsField(opensocial.Environment.ObjectType.PERSON, opensocial.Person.Field.ID);

With this line of code, we can check if there’s a field called ‘id’ for objects of type ‘person’. As soon as we know that our field of choice really exists, we can access it through “getField()”:

friend.getField(opensocial.Person.Field.ID);

A few specialities still have to be considered when sending a chat message:

function send_message(message, user_to, user_from){
    var post_data = { action: 'save_message', message: message, to_user: user_to, from_user: user_from};
    post_data = gadgets.io.encodeValues(post_data);
    var params = {};
    params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT
    params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
    params[gadgets.io.RequestParameters.POST_DATA] = post_data;
    gadgets.io.makeRequest('http://www.example.com/message.php', function(){}, params);
}

Our self-defined method “send_message()” is used to send an entered message via AJAX to a remote server. This remote server then saves the message in a database until it is picked up by it’s receiver.

Inside of this function, the Gadgets-API is used heavily. This is necessary because it’s not easily possible for security reasons to send a request to an other than the origin server with AJAX. Here the Gadgets-API steps in, which makes this possible through “gadgets.io.makeRequest”.

Other Possibilities

The OpenSocial-API offers some more possibilities. With the help of the Activities-API you can, for example, read or write activity messages for a user. Therefore, an application would be able to read or write activity messages like “Mike has a new profile photo” or “Martin and Linda are friends, now”.

A so-called “Lifecycle event” can help developers gear into important points in the life cycle of an application. As a developer, you can for example, be informed when the deinstallation of a Gadget happens and take actions accordingly (by deleting old database entries, for example).

Another area of the API deals with data persistence. This functionality is exciting because OpenSocial apps – being “just a frontend” at first hand – come without their own backends and therefore have no database by default. Every social network can decide for itself to which extent it allows applications to persist data for a viewer.

The concept of “Views” is also an interesting part of OpenSocial development: An OpenSocial-Gadget can have different views. This depends on where the Gadget was integrated, respectively in which view a user is at this specificmoment. The current view can be requested at runtime so that, e.g., different functionalities can be offered depending on the currently active view of the Gadget.

Basically four different view types are defined in OpenSocial: The “Profile” view is active when it is viewed on the profile page of the user. The “Home” view is active when a Gadget is viewed on the personal homepage of the user (on which the above mentioned viewer and owner constants are always identical, because only the account owner has access to his personal homepage). The “Canvas” view is a view in which the Gadget is more or less alone on the page and therefore has a lot of space available. Finally, the “Preview” view has limited accesses and is intended for demo purposes.

Publishing your SocialApp

The development of an OpenSocial application always begins in a sandboxed developer environment where you can work on your application without interruptions. During this time, however, the app is only accessible to the developer himself (or other developers) – but not publicly to normal users.

Then – after some time of development and testing – when your SocialApp has a sufficient level of maturity and is ready to enrich the world, you can submit it to the respective social network to be checked and (hopefully) approved.

Though the submission process is a little different in every social network (as an example you find Orkut’s application form here), it always serves the same purpose: to put your submitted app through their paces.

If then, after several days or weeks, your application was found to be nice enough, it is included into the platform’s list of applications – and can be installed by all users of the platform.

Summary

Google’s OpenSocial-API only really offers the functionality that Facebook developers are already accustomed to. However, with OpenSocial, you can reach a wider and larger audience of 500 million people.

In day-to-day development, in spite of the wholehearted promise “Many sites, one API”, caution is advised: some of the networks don’t implement the complete specification or take awhile to implement updates to their APIs. Sometimes some minor differences in the API implementation force you to adapt to special situations (hi5, for example, requires the Gadget scaffolding to be a little bit more detailed).

The result so far that OpenSocial can present, however, looks good: excellent documentation, more than 30 involved social networks all over the world, and more than half a billion users.

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it’s vital that you understand the process thoroughly.

This article breaks down the fundamentals of debugging in PHP, helps you understand PHP’s error messages and introduces you to some useful tools to help make the process a little less painful.

Editor’s Note: We’ll be running workshops like “How to Build a Web App from A-Z” at The Future of Web Apps London.

Doing your Ground Work

It is important that you configure PHP correctly and write your code in such a way that it produces meaningful errors at the right time. For example, it is generally good practice to turn on a verbose level of error reporting on your development platform. This probably isn’t such a great idea, however, on your production server(s). In a live environment you neither want to confuse a genuine user or give malicious users too much information about the inner-workings of your site.

So, with that in mind lets talk about the all too common “I’m getting no error message” issue. This is normally caused by a syntax error on a platform where the developer has not done their ground work properly. First, you should turn display_errors on. This can be done either in your php.ini file or at the head of your code like this:

<?php
ini_set('display_errors', 'On');

Tip: In these code examples I omit the closing (?>) PHP tag. It is generally considered good practice to do so in files which contain only PHP code in order to avoid accidental injection of white space and the all too common “headers already sent” error.

Next, you will need to set an error reporting level. As default PHP 4 and 5 do not show PHP notices which can be important in debugging your code (more on that shortly). Notices are generated by PHP whether they are displayed or not, so deploying code with twenty notices being generated has an impact upon the overhead of your site. So, to ensure notices are displayed, set your error reporting level either in your php.ini or amend your runtime code to look like this:

<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);

Tip: E_ALL is a constant so don’t make the mistake of enclosing it in quotation marks.

With PHP 5 it’s also a good idea to turn on the E_STRICT level of error reporting. E_STRICT is useful for ensuring you’re coding using the best possible standards. For example E_STRICT helps by warning you that you’re using a deprecated function. Here’s how to enable it at runtime:

<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL | E_STRICT);

It is also worth mentioning that on your development platform it is often a good idea to make these changes in your php.ini file rather than at the runtime. This is because if you experience a syntax error with these options set in your code and not in the php.ini you may, depending on your set up, be presented with a blank page. Likewise, it is worth noting that if you’re setting these values in your code, a conditional statement might be a good idea to avoid these settings accidentally being deployed to a live environment.

What Type of Error am I Looking at?

As with most languages, PHP’s errors may appear somewhat esoteric, but there are in fact only four key types of error that you need to remember:

1. Syntax Errors

Syntactical errors or parse errors are generally caused by a typo in your code. For example a missing semicolon, quotation mark, brace or parentheses. When you encounter a syntax error you will receive an error similar to this:

Parse error: syntax error, unexpected T_ECHO in /Document/Root/example.php on line 6

In this instance it is important that you check the line above the line quoted in the error (in this case line 5) because while PHP has encountered something unexpected on line 6, it is common that it is a typo on the line above causing the error. Here’s an example:

<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);


$sSiteName = "Think Vitamin"
echo $sSiteName;

In this example I have omitted the semi-colon from line 5, however, PHP has reported an error occurred on line 6. Looking one line above you can spot and rectify the problem.

Tip: In this example I am using Hungarian Notation. Adopting this coding standard can aid with debugging code while working collaboratively or on a piece of code you wrote some time ago. The leading letter denoting the variable type means that determining a variable type is very quick and simple. This can aid in spotting irregularities which can also help highlight any potential logic errors.

2. Warnings

Warnings aren’t deal breakers like syntax errors. PHP can cope with a warning, however, it knows that you probably made a mistake somewhere and is notifying you about it. Warnings often appear for the following reasons:

1. Headers already sent. Try checking for white space at the head of your code or in files you’re including.
2. You’re passing an incorrect number of parameters to a function.
3. Incorrect path names when including files.

3. Notices

Notices aren’t going to halt the execution of your code either, but they can be very important in tracking down a pesky bug. Often you’ll find that code that’s working perfectly happily in a production environment starts throwing out notices when you set error_reporting to E_ALL.

A common notice you’ll encounter during development is:

>Notice: Undefined index: FullName in /Document/Root/views/userdetails.phtml on line 55

This information can be extremely useful in debugging your application. Say you’ve done a simple database query and pulled a row of user data from a table. For presentation in your view you’ve assigned the details to an array called $aUserDetails. However, when you echo $aUserDetails['FirstName'] on line 55 there’s no output and PHP throws the notice above. In this instance the notice you receive can really help.

PHP has helpfully told us that the FirstName key is undefined so we know that this isn’t a case of the database record being NULL. However, perhaps we should check our SQL statement to ensure we’ve actually retrieved the user’s first name from the database. In this case the notice has helped us rule out a potential issue which has in turn steered us towards the likely source of our problem. Without the notice our likely first stop would have been the database record, followed by tracing back through our logic to eventually find our omission in the SQL.

4. Fatal Errors

Fatal Errors sound the most painful of the four but are in fact often the easiest to resolve. What it means, in short, is that PHP understands what you’ve asked it to do but can’t carry out the request. Your syntax is correct, you’re speaking its language but PHP doesn’t have what it needs to comply. The most common fatal error is an undefined class or function and the error generated normally points straight to the root of the problem:

Fatal error: Call to undefined function create() in /Document/Root/example.php on line 23

Using var_dump() to Aid Your Debugging

var_dump() is a native PHP function which displays structured, humanly readable, information about one (or more) expressions. This is particularly useful when dealing with arrays and objects as var_dump() displays their structure recursively giving you the best possible picture of what’s going on. Here’s an example of how to use var_dump() in context:

Below I have created an array of scores achieved by users but one value in my array is subtly distinct from the others, var_dump() can help us discover that distinction.

<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);


$aUserScores = array('Ben' => 7,'Linda' => 4,'Tony' => 5,'Alice' => '9');
echo '<pre>';
var_dump($aUserScores);
echo '</pre>';

Tip: Wrap var_dump() in <pre> tags to aid readability.

The output from var_dump() will look like this:

array(4) {
  ["Ben"]=>
  int(7)
  ["Linda"]=>
  int(4)
  ["Tony"]=>
  int(5)
  ["Alice"]=>
  string(1) "9"
}

As you can see var_dump tells us that $aUserScores is an array with four key/value pairs. Ben, Linda, and Tony all have their values (or scores) stored as integers. However, Alice is showing up as a string of one character in length.

If we return to my code, we can see that I have mistakenly wrapped Alice’s score of 9 in quotation marks causing PHP to interpret it as a string. Now, this mistake won’t have a massively adverse effect, however, it does demonstrate the power of var_dump() in helping us get better visibility of our arrays and objects.

While this is a very basic example of how var_dump() functions it can similarly be used to inspect large multi-dimensional arrays or objects. It is particularly useful in discovering if you have the correct data returned from a database query or when exploring a JSON response from say, Twitter:

<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);


$sJsonUrl = 'http://search.twitter.com/trends.json';


$sJson = file_get_contents($sJsonUrl,0,NULL,NULL);
$oTrends = json_decode($sJson);


echo '<pre>';
var_dump($oTrends);
echo '</pre>';

Useful Tools to Consider when Debugging

Finally, I want to point out a couple of useful tools that I’ve used to help me in the debugging process. I won’t go into detail about installing and configuring these extensions and add-ons, but I wanted to mention them because they can really make our lives easier.

Xdebug

Xdebug is a PHP extension that aims to lend a helping hand in the process of debugging your applications. Xdebug offers features like:

• Automatic stack trace upon error
• Function call logging
• Display features such as enhanced var_dump() output and code coverage information.

Xdebug is highly configurable, and adaptable to a variety of situations. For example, stack traces (which are extremely useful for monitoring what your application is doing and when) can be configured to four different levels of detail. This means that you can adjust the sensitivity of Xdebug’s output helping you to get granular information about your app’s activity.

Stack traces show you where errors occur, allow you to trace function calls and detail the originating line numbers of these events. All of which is fantastic information for debugging your code.

Tip: As default Xdebug limits var_dump() output to three levels of recursion. You may want to change this in your xdebug.ini file by setting the xdebug.var_display_max_depth to equal a number that makes sense for your needs.

Check out Xdebug’s installation guide to get started.

FirePHP

For all you FireBug fans out there, FirePHP is a really useful little PHP library and Firefox add-on that can really help with AJAX development.

Essentially FirePHP enables you to log debug information to the Firebug console using a simple method call like so:

<?php
$sSql = 'SELECT * FROM tbl';
FB::log('SQL query: ' . $sSql);

In an instance where I’m making an AJAX search request, for example, it might be useful to pass back the SQL string my code is constructing in order that I can ensure my code is behaving correctly. All data logged to the Firebug console is sent via response headers and therefore doesn’t effect the page being rendered by the browser.

Warning: As with all debug information, this kind of data shouldn’t be for public consumption. The downside of having to add the FirePHP method calls into your PHP is that before you go live you will either have to strip all these calls out or set up an environment based conditional statement which establishes whether or not to include the debug code.

You can install the Firefox add-on at FirePHP’s website and also grab the PHP libs there too. Oh, and don’t forget if you haven’t already installed FireBug, you’ll need that too.

In Conclusion …

Hopefully during the course of this article you have learned how to do your ground work by preparing PHP for the debugging process; recognise and deal with the four key PHP error types and use var_dump() to your advantage. Likewise, I hope that you will find Xdebug and FirePHP useful and that they will make your life easier during your development cycle.

As I’ve already mentioned, and I really can’t say this enough, always remember to remove or suppress your debug output when you put your sites into production after all there’s nothing worse than all your users being able to read about your errors in excruciating detail.

Got a great debugging tip to share? Do you use a great little PHP extension that makes your bug trapping life easier? Please tell us about them in comments below!

In the first part of this series we went over how a cookie works and what can be done to secure them. In this section we’re going to go over ways to add additional security to the session beyond the cookie itself.

By the end of this article we will written our own wrapper class for “session_start” that protects our session from a number of attacks while taking into account some of the unique challenges presented by modern ajax-heavy websites.

Session Specific Attacks

Through the use of sessions your identity is maintained as you use a website, and just as in real life identity theft is a concern. By taking over your session an attacker would essentially become you on a website, with access to all of the actions, information and privileges that entails.

The main thing that an attacker needs to steal a session is the session ID. There are three ways an attacker normally goings about doing this, all of which can be protected against but are, by default, completely open.

• Guess the ID: most session handlers generate ids that make this impractical.
• Steal the ID: by using malware, sniffing the network, or exploiting javascript exploits attackers can get the value from the cookie itself.
• Set the ID: rather than steal or guess the ID an attacker may try and set it to a value they choose.

Starting the Session

The default session setup is not at all secure by itself, so we’re going to create a wrapper to add the security we need. To make this code more portable we’re going to build it as a static function of a php class called SessionManager.

To begin our sessionStart function is going to set the name cookie options for the session. Like all cookies we’re going to need to make some decisions about what is going to need access to the session ID. Since these options depend on the application itself lets add arguments we can change based on our specific needs.

For security we can hardcode the “HttpOnly” argument, as session ids are often the juiciest target for cross site scripting attacks.

class SessionManager
{
   static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
   {
      // Set the cookie name before we start.
      session_name($name . '_Session');

      // Set the domain to default to the current domain.
      $domain = isset($domain) ? $domain : isset($_SERVER['SERVER_NAME']);

      // Set the default secure value to whether the site is being accessed with SSL
      $https = isset($secure) ? $secure : isset($_SERVER['HTTPS']);

      // Set the cookie settings and start the session
      session_set_cookie_params($limit, $path, $domain, $secure, true);
      session_start();
   }
}

Using the new class is as easy as including it and running one line but additional options can make it more restrictive.

SessionManage::sessionStart('InstallationName');
SessionManage::sessionStart('Blog_myBlog', 0, '/myBlog/', 'www.site.com');
SessionManage::sessionStart('Accounts_Bank', 0, '/', 'accounts.bank.com', true);

Lock the Session to a Host

Now that our wrapper class is in place and functional we can start building in additional security by restricting the session to the same IP address and User Agent (or browser) as when the session was first opened. This way if the session ID is stolen or guessed the attacker still has to get ahold of the user agent (admittedly not too difficult if they got the session ID) and somehow find a way to get the same IP address.

These attacks only help if the user is not on the same network. The user agent check only adds minor security, since many attacks that compromise the cookie are going to do the same to the user agent. If an attacker is on the same network as the target there is a good chance they already have the same external IP address, as it is pretty common for a network to use private internal addresses while presenting only a single IP address to the internet. This is why it is important to evaluate the need for SSL.

We’re going to add these new checks to our class in the function preventHijacking. This function will return false on new sessions or when a session is loaded by a host with a different IP address or browser. preventHijacking will true if the session is valid and false otherwise. This means it will return false not just on malicious attempts but completely new sessions as well.

static protected function preventHijacking()
{
	if(!isset($_SESSION['IPaddress']) || !isset($_SESSION['userAgent']))
		return false;

	if ($_SESSION['IPaddress'] != $_SERVER['REMOTE_ADDR'])
		return false;

	if( $_SESSION['userAgent'] != $_SERVER['HTTP_USER_AGENT'])
		return false;

	return true;
}

Now that we have a way to identify hijacking attempts we need to set up a way to respond to them. For us this means two things- clearing out the old session data and inserting the IP address and user agent into the new session.

static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
{
	...
	session_start();

	if(!self::preventHijacking())
	{
		$_SESSION = array();
		$_SESSION['IPaddress'] = $_SERVER['REMOTE_ADDR'];
		$_SESSION['userAgent'] = $_SERVER['HTTP_USER_AGENT'];
	}
}

Session Fixation

So far we have effectively eliminated the possibility of brute force guessing. We’ve also made it so any attempts at capturing the session ID would require the attacker to be on the same network as the user in order to take advantage of that ID, while also discussing enforcing SSL to make capturing the session more difficult through traditional means. However, what if the attacker could set the session ID themselves?

By getting the user to follow a link with a session ID in it the attacker can trick the user into starting a session with the ID of the attacker’s choosing. Rather than guess or steal an ID the attacker will have it right from the start. Many web environments, including PHP, allow session ids to be set through the URL, primarily to get around systems which do not support cookies. Just like with regular cookies the value sent by the client is the value used for the ID, so in this case the value in the URL becomes the session ID.

The solution to this is to change the session ID. How often you do this is tends to be a matter of great debate, but at the bare minimum the ID should be changed when new sessions are created and when the user changes privileges (logs in or out).

A First Attempt At Regenerating the ID

Regenerating the ID is fairly simply in php. Deceptively simple one might say. The function “session_regenerate_id” lets us tell the system to use a new ID. It can also optionally delete the old session.

// Leaves old session intact
session_regenerate_id();

// Deletes old session
session_regenerate_id(true);

If you don’t delete the old session then it is still vulnerable to hijacking and whatever access it had can be granted to an attacker. If you’re changing the session ID often without deleting the old ones you could be creating more holes by leaving a trail of old, but valid, sessions.

Regenerating the ID in the World of Ajax

If an application creates a lot of quick connections to the server some interesting things can happen. PHP, and many other languages, restricts access to the session data to one running script at a time, so if multiple requests come in that try to access the session data the second request (and any other) gets queued up. When the first request changes the ID and deletes the old session the second request still has the old session ID which no longer exists. This results in a third, new session being opened and generally means your user gets logged out.

This bug is ridiculously hard to diagnose as the timing of not just the requests but the ID regeneration has to be just right. In sites that don’t make requests to the server using javascript this type of bug may never be encountered at all, as the time between page loads is more than long enough for the browser to have updated its session info. For sites that make use of ajax techniques, however, this issue will have a chance of occurring whenever the session ID is changed.

In our final update to the SessionManager class we’re going to write a fix for this problem. Rather than delete the session immediately when we change the ID, we’re going to mark the old session as obsolete and mark it to expire in ten seconds. This way any queued up requests will still have access to the expired session but we don’t have to leave it open forever.

To accomplish this we’re going to add the regenerateSession function. This function adds the obsolete flag and expiration to the session, regenerates the ID to create the new session and saves them both. It then reopens the new session and removes the obsolete flag. Unlike our other internal functions we are leaving this one open for use outside the class so that it can be tied into login scripts.

static function regenerateSession()
{
	// If this session is obsolete it means there already is a new id
	if(isset($_SESSION['OBSOLETE']) || $_SESSION['OBSOLETE'] == true)
		return;

	// Set current session to expire in 10 seconds
	$_SESSION['OBSOLETE'] = true;
	$_SESSION['EXPIRES'] = time() + 10;

	// Create new session without destroying the old one
	session_regenerate_id(false);

	// Grab current session ID and close both sessions to allow other scripts to use them
	$newSession = session_id();
	session_write_close();

	// Set session ID to the new one, and start it back up again
	session_id($newSession);
	session_start();

	// Now we unset the obsolete and expiration values for the session we want to keep
	unset($_SESSION['OBSOLETE']);
	unset($_SESSION['EXPIRES']);
}

We need to add another function to check for the obsolete flag and to see if the session has expired.

static protected function validateSession()
{
	if( isset($_SESSION['OBSOLETE']) && !isset($_SESSION['EXPIRES']) )
		return false;

	if(isset($_SESSION['EXPIRES']) && $_SESSION['EXPIRES'] < time())
		return false;

	return true;
}

Finally, in the last change to our SessionManager, we need to update our SessionStart function. It needs to call the regenerateSession function on new requests and periodically after that, as well as destroy the session if it is invalid. Here is the complete SessionStart function.

static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
{
	// Set the cookie name
	session_name($name . '_Session');

	// Set SSL level
	$https = isset($secure) ? $secure : isset($_SERVER['HTTPS']);

	// Set session cookie options
	session_set_cookie_params($limit, $path, $domain, $https, true);
	session_start();

	// Make sure the session hasn't expired, and destroy it if it has
	if(self::validateSession())
	{
		// Check to see if the session is new or a hijacking attempt
		if(!self::preventHijacking())
		{
			// Reset session data and regenerate id
			$_SESSION = array();
			$_SESSION['IPaddress'] = $_SERVER['REMOTE_ADDR'];
			$_SESSION['userAgent'] = $_SERVER['HTTP_USER_AGENT'];
			self::regenerateSession();

		// Give a 5% chance of the session id changing on any request
		}elseif(rand(1, 100) <= 5){
			self::regenerateSession();
		}
	}else{
		$_SESSION = array();
		session_destroy();
		session_start();
	}
}

Summery

At times it amazes me how complex something as simple as an ID- what is essentially just a string of random characters- can turn out to be. While you can certainly use this class for all of your own projects here is what you need to remember when building your own session manager.

Session IDs are attacked by guessing, capturing or setting the id. You can protect against this in your own applications by …

• Securing the cookie to make stealing the ID harder
• Limiting the session to a specific host to make attacks more difficult
• Changing the ID when escalating privileges and throughout the session life.

Here is the complete Session.class.php file for your reference.

Securing cookies and sessions is vital to keeping an application secure. Many tutorials have been written on the subject, but as the internet (and browsers loading it) evolve so do the methods you can use to keep your application secure.

In this article we’re going to break down the various components of a cookie and what they mean for security. This will include limiting the cookie to certain domains and paths on those domains, choosing what information to store, and protecting the cookie from cross site scripting exploits. In a second article we will go into more depth in how to protect everyone’s favorite cookie, the session ID.

How Cookies Work

Cookies are simply key/value pairs that let us get around HTTP being a stateless protocol. When a developer has data they wish to last for more than one connection they can use cookies to store that data on the client side. While this tends to get handled by the programming language being used it is accomplished using HTTP headers.

When the server wants to set a cookie it passes back a header named “Set-Cookie” with the key-value pair and some options.

View larger

On subsequent requests the client will send along its own header to let the server know the name and value of its stored cookies. The server will not continue to send back the cookies, it will only send them if there is a change.

View larger

You can see all the headers for yourself using the LiveHeaders plugin for Firefox.

The Problem

This data is completely in control of the client- it is trivial to change the values of a cookie. That means that, just like post and get data, all cookie data must be validated in some way. At the same time you’ll want to avoid storing sensitive information, such as passwords, as cookies are stored in cleartext and anyone with access to the computer later can easily pick those up (I know of at least one security forum that was hacked in this way). It is also important to note that HTTP does not encrypt the headers in any way. If the connection isn’t over SSL then it will not be protected from snooping eyes.

Session cookies are no different than any other cookie- their value is just a simple ID. Those IDs are susceptible to all of the same limitations as other cookies. The real power behind sessions happens server side, where the ID is used to pull out data stored on the server. This has many benefits over storing data directly into the cookie itself- data can’t be manipulated by the user, large amount of data can be stored without having to send it back and forth with each request, and you can store data you otherwise wouldn’t want the client to have access to.

Getting Started

The first step towards securing your cookie is to restrict that cookie to only your application. This is especially important in environments that support multiple sites or applications (the type of shared hosting you often see on corporate or university domains). By restricting the cookie to only the applications that need it you reduce the chances of it being sniffed while also keeping the cookie namespaces clear for other applications that use them.

There are three options that can be sent along when creating a cookie that, when used properly, will keep the cookie limited to only your application. Before setting these options you will need to ask yourself a few questions-

• What parts of the website need access to the cookie?
• Will the cookie need to work across sub domains?
• Will the cookie need to persist if the user leaves an SSL portion of the site?

There is also a forth option used by newer browsers to restrict access to cookies by javascript.

As you will see, how exactly to restrict the cookie really does depend on the exact purpose for that cookie. A banking or ecommerce site may restrict their cookies to only SSL, while a blog or news aggregator may want to leave things more open.

Cookie Options

Send The Cookie To Only Your Application

The Path argument specifies what paths on the site to send the cookie. The default value of “/” means every request will get the cookie, while “/forums/” would limit the cookie to just that path. This path is going to be based on the actual URL the browser uses, before any mod_rewrite or other URL mapping.

Don’t Share With Sub Domains

The Domain option allows you to specify whether or not to send the cookie to subdomains. Setting “www.example.com” will mean only the exact domain “www.example.com” will be matched, while “.example.com” will also match again any subdomaim (forums.example.com, blog.example.com).

Require a Secure Connection

Using the Secure option you can tell the browser (or other http clients) to only send the cookie over SSL connections. This means the cookie will not be available to any part of the site that is not secure will not have access to the cookie, but it also makes it much less likely that you’ll accidentally send the cookie across as cleartext.

Protect Against XSS Exploits

This HttpOnly flag is used to tell the browser that it should not allow javascript to access the contents of the cookie. This is primarily a defense against cross site scripting, as it will prevent hackers from being able to retrieve and use the session through such an attack.

The HttpOnly option is not by any means full proof. As a client-side defense mechanism it relies on browser support to work, but is only supported by a few browsers (Firefox 3+ and IE 7+, with partial support from Opera 9.5, IE6 and Chrome).

Configuring the Cookie

In PHP, setting the arguments for cookies is done through some optional arguments on the “setcookie” function:

setcookie( name, value, expire, path, domain, secure, httponly);

// Open
setcookie( 'UserName', 'Bob', 0, '/', '.example', false, false);

// Locked Down
setcookie( 'UserName', 'Bob', 0, '/forums', 'www.example.com', isset($_SERVER["HTTPS"]), true);

To change the cookie values for the session cookie requires the “session_set_cookie_params” function, which needs to be called before the session is started.

session_set_cookie_params($expire, $path, $domain, $secure, true);

// Open
session_set_cookie_params(0, '/', '.example', false, false);

// Locked Down
session_set_cookie_params('o, /forums', 'www.example.com', isset($_SERVER["HTTPS"]), true)

Summary

Cookies remain the basic method of identify tracking on most websites and keeping them secure is a vital part to keeping applications as a whole locked down and secure. In this article we went over four methods for protecting cookies on a general level.

When using cookies its important to remember to:

• Limit the amount of sensitive information stored in the cookie.
• Limit the subdomains and paths to prevent interception by another application.
• Enforce SSL so the cookie isn’t sent in cleartext.
• Make the cookie HttpOnly so its not accessible to javascript.

Please check out the second half of this series, where we’re going to take the next step with an in depth guide to securing sessions.

If we look at web design today, it’s anything but simple. Sometimes you need that extra Photoshop knowledge in order to achieve the look we need.

In this step-by-step tutorial, I’m going to show you how to create five killer effects for your site.

When I was choosing examples for this article I visited some design galleries and roundup posts and took screenshots of design details that are used (sometimes overused) in web design. I don’t encourage you to follow trends but rather develop your own style. Nevertheless, it is always useful to polish your Photoshop skills a bit more. Let’s get rockin’!

Editor’s Note: Andy Clarke will be teaching an interesting session called “How to Design in the Browser” and Elliot Jay Stocks will be showing you how to design the “The Perfect Portfolio” at The Future of Web Design Tour.

#1 Awesome Buttons

Now what is a site without a great “Call to action” button? The design style and colors will depend on your overall site style and importance of each button. Here is one example of a simple but effective button that we’ll be trying to recreate (taken from transmissionapps.com).

Step 1

Open New Document, set canvas to 470px wide and 350px high. Create a new layer and draw in this shape with Rounded Rectangle Tool with radius set to 80px.

Step 2

Right after that we will add some layer filters to make this button immediately awesome. Drop Shadow – Color: Black, Opacity:65%, Distance: 2px, Size:2px, the rest leave by default.

Step 3

Gradient Overlay. Just copy these hex codes for gradient colors and place color buckets in approximately same position as you can see in the image.

Step 4

Inner Shadow will make this button stand out even more. Notice that this is just a subtle effect. Inner Shadow – Color: Black, Opacity: 15%, Distance: 0px, Size: 5px;

Step 5

Finally add some Stroke. You will notice that this is a Gradient Stroke with same colors as our buttons Gradient Overlay. The only difference here is that gradient direction is set -90, which is the opposite of buttons Gradient Overlay. With this little trick we made a nice light effect to our button and made it stand out a bit more.

Step 6

Done with effects, time for some shine! Create a new layer above others.

Step 7

Cmnd (Ctrl) + Click on Button shape layer. We have made a selection out of it.

Step 8

Choose Marquee Tool. Hold down the Alt key and Subtract the half from selection.

Step 9

Choose Black to White Gradient Tool, set the layer mode to Screen and pull upwards from bottom of selection to about 30px outside the selection. There you have it! A nice shiny button.

Step 10

Add some text like I did here. Draw in a circle and position it like you see it in the picture. Add a Gradient Overlay with same values like shown in the screenshot. Finally give it a 2px white Inside stroke.

Step 11

Choose Shape Tool. From presets choose an Arrow. Rotate it.

Step 12

Like the image says, position the arrow in bottom direction.

Step 13

Now choose Direct Selection Tool and select the shape. Next, select two points from upper part of the arrow and move them with Arrow Keys few pixels to the right. Do the same with the right top side of the arrow, just shift it to the left. This way our top part will become a bit thiner. With the same tool adjust the bottom part (triangle).

Step 14

This is how it should look like. You can also see the layer structure.

#2 Navigation Menus

The most important part of a website: the navigation. I’ve chosen the example that uses some transparency and fade out effect (taken from legacylocker.com).

Step 1

Open a New Document, same dimensions from previous example. Create a New Layer and fill it with Gradient Overlay using the color hex values you can see in the image.

Step 2

For the purpose of this example I added few clouds :)

Step 3

Draw in a Rectangle, paint it with #6bb9ec and set Opacity to 65%.

Step 4

Add a Quick Mask to this layer. Choose 200px radius Soft Brush, set the color to Black and mask the ends of this rectangle, like you see it in the image.

Step 5

Draw in another Rectangle, but much higher. Put it under the small rectangle. Use the same color and Opacity. Again add a Quick Mask to this layer.

Step 6

Choose 600px Soft Brush and carefully mask bottom of the rectangle os that top line stays visible across the document.

Step 7

Now we can play a bit with the small Rectangle by adding some light and shadows. Cmnd (Ctrl) + Click small Rectangle to make a selection out of it. Go to Select>Modify>Contract and enter 1px. Create a New layer and set Mode to Overlay. Choose 200px Soft Brush, color white and click few times the top part of the rectangle just like you see in the image.

Step 8

Do the same with bottom part just change the Brush color to Black.

Step 9

Here you can see how this looks like. It’s really a subtle effect of light and shadow which you can use wherever you want.

Step 10

With Line Tool draw in a line just the same width as small rectangle. For color choose #8dd1fe.

Step 11

Mask the ends of the line just like we did in Step 4. Copy this line and shift it to the bottom of the small rectangle.

Step 12

Finally I added some Navigation items and that’s it!

#3 Typography Inset

Even though we’re used to seeing this technique now, it’s still a good skill to add to your toolbox. Please use it only if you have to :) The example was taken from forabeautifulweb.com.

Step 1

Same New Document filled with #aa8e5c.

Step 2

I added some floral brushes just to recreate the same background from the example :)

Step 3

Choose Type Tool, set font to Times New Roman. Choose color #591e0d and type something.

Step 4

Add Inner Shadow filter and use settings like shown in the image.

Step 5

Add 2px Outside Stroke with color set to #bc9f6c.

Step 6

Done! What, that’s it? Yes, that’s it! Simple and effective.

#4 Faded Shadow

With a little bit of Blur and Quick Mask we can create shadows that fade out in any direction we want to. With this effect you can make boxes look like they pop out of the background. This example is from mint.com.

Step 1

First thing first, the background. As usual by now, within New Document same dimensions like previous ones.

Step 2

Draw in a white Rectangle.

Step 3

Create a New Layer and place it under the white rectangle layer. Cmnd (Ctrl) + Click white rectangle shape. Fill the empty layer with Black.

Step 4

Go to Filter>Blur>Gaussian Blur and enter Radius: 12px.

Step 5

Add a Quick Mask to this layer. Select a 300px Soft Brush Tool and carefully mask all

Step 6

Now this was pretty easy, don’t you think? Now you can play around with this technique and who knows what awesome results you’ll get.

#5 Depth and 3D Space

More and more interesting 3D elements are being used in web design lately. Here you can see how with just few extra layers, you can create an illusion of 3D space. This example is from mosaiko.com.br.

Step 1

New Document filled with Black.

Step 2

With Rectangle Toll draw in rectangle and fill it with #21262a.

Step 3

With same tool selected draw in another, this time smaller rectangle and fill it with #191b1d. These two rectangles will create our space on canvas. It will look like a wall is passing through it.

Step 4

Cmnd (Ctrl) + Click bigger rectangle shape to get a selection. Create a New layer. Choose 300px Soft Brush, color Black and click few times in top center of the selection.

Step 5

Do the same with smaller rectangle but this time click on bottom center part of the rectangle.

Step 6

Now, do the same for the background layer itself just use White as Brush color.

Step 7

Draw in a 85×20 px rectangle, fill it with #555759.

Step 8

Add following effects. Drop Shadow – Color: Black, Opacity: 25%, Angle: 90, Distance: 1px, Size:4px. Inner Shadow – Color: White, Opacity: 7%, Angle: -90, Distance: 1px, Size: 2px. Gradient Overlay, use values provided in the image.

Step 9

Choose Pen Tool and draw in a shape like you see in the image. Fill it with #555759.

Step 10

With a little use of Quick Mask and some Brushing we will create the illusion of 3D space. First add a Quick Mask to the layer and with 100 px Soft Brush mask the sides of the stripe.

Step 11

Next, select the whole stripe and choose 100px Soft Brush again. Create New Layer, set color to white and click few times at the beginning of the path but only with the top of the brush just like shown in the image.

Step 12

I added some navigation links, copied few more stripes, modified the perspective a bit and there we have it.

I hope you enjoyed it and hopefully learned something new. Watch out for Part 2 where we will be covering more interesting Photoshop techniques.

Thanks to some very nice open source libraries for quite a few programming languages, interacting with the Twitter API has become exceedingly simple. In this article we’ll be looking at different ways to pull in data from Twitter.

The libraries page of Twitter’s API wiki is a good place to start. For these examples I’m going to use the php-twitter class, but I’ll include the requests and responses so this doesn’t turn out to be all PHP. After all, the API itself doesn’t care which language I’m using.

The php-twitter zip archive contains some nested folders and finally a file: class.twitter.php. You’ll eventually get to it, so keep opening those folders!

Getting your timeline from Twitter

With this library you don’t have to worry about data exchange formats (the default is JSON), but if you’re still stuck with PHP 4, you might have to set the $type variable to ‘xml’. But, let’s face it: if you enjoy XML you’re kind of insane, aren’t you? If your host is still using PHP 4, chances are that they’ll update you to the latest version if you ask them nicely.

The API method we’ll be using is user_timeline. You can check out the output by pointing your browser to http://twitter.com/statuses/user_timeline/karipatila.xml. Notice the “.xml” — that’s the data exchange format. You can use “json”, “rss” or “atom” there as well. That URL is the GET request the API is responding to, which could be made using any programming language.

So, using the library, this is all we need to fetch my timeline:

<?php
header('Content-type: text/html; charset=utf-8');
require_once 'class.twitter.php';
$t = new twitter;
$data = $t->userTimeline('karipatila');
?>

First we make sure the script can handle unicode characters and then we include class.twitter.php. Next we’ll set up a new instance of the php-twitter class, which can be used to pull in some data.

The script loads the timeline from Twitter and stores it into the $data variable. Along with some user information it contains the tweets themselves, which are what we’re really interested in. Let’s take a look at what kind of information we’re getting. This is one of my tweets in the $data array:

[truncated] => 
[text] => TomTom Nordic, 69,90€: http://bit.ly/wX51t (App Store link) - wonder how expensive the car kit is?

[in_reply_to_status_id] => 
[created_at] => Mon Aug 17 07:55:51 +0000 2009
[favorited] => 
[in_reply_to_user_id] => 
[id] => 3358348095

[in_reply_to_screen_name] => 
[source] => <a href="http://www.atebits.com/" rel="nofollow">Tweetie</a>

We can use that information to make a script that lists my recent tweets. The API method statuses user_timeline returns the 20 most recent statuses posted from the authenticating user. I also wanted to link back to the accounts that are being replied to, so I’m looking for an @ symbol followed by one or more word characters and linking them to their respective Twitter profiles:

<ul>
	<?php foreach($data as $d){ ?>
	<li><?php echo preg_replace('/(^|\s)@(\w+)/','\1<a href="http://twitter.com/\2">@\2</a>', $d->text); ?></li>

	<?php } ?>
</ul>

A short note on rate limitations; caching the output from this script will become necessary sooner or later. The technical details are beyond the scope of this article, but you might want to consider saving the output into a database or a file and checking for updates every couple of minutes or so. A limit of 150 requests per hour applies to the REST API.

Get the source for fetching a user’s timeline here.

Let’s look for treasure

For example, let’s do a search for the hashtag “#carsonified”. They have recently announced Hello App, so there should be some chatter around that subject. We can add terms to the search like this:

$data = $s->search('#carsonified OR #HelloApp');

The search API method requires the query to be URL encoded, so we replace # with %23 in the request: http://search.twitter.com/search.json?q=%23carsonified&rpp=5&page=1. The search API accepts either “json” or “atom” as the exchange format.

If we break that request down, we find it contains the following information:

q=[query string]
rpp=[results per page]
page=[page number]

The search API has virtually no rate limits, so you don’t have to worry about your app getting throttled. Note that this time we’re also creating another instance with

$s = new summize;

which refers to the search class found in the php-twitter library.

<?php
header('Content-type: text/html; charset=utf-8');
require_once 'class.twitter.php';
$t = new twitter;

$s = new summize;
$data = $s->search('#carsonified');
$data = $data->results;
?>

In this example one tweet stored in $data might contain the following information:

[text] => Just trying out Matt by #carsonified. uniquely designed site with workable UI.
[to_user_id] => 
[from_user] => _midnightshad
[id] => 3284756132
[from_user_id] => 2270963

[iso_language_code] => en
[source] => <a href="http://themattinator.com" rel="nofollow">Matt</a>
[profile_image_url] => http://a1.twimg.com/profile_images/60040548/panda_normal.jpg

[created_at] => Thu, 13 Aug 2009 11:50:01 +0000

We can use this to make a simple listing based on the results:

<?php
header('Content-type: text/html; charset=utf-8');
require_once 'class.twitter.php';

$t = new twitter;
$s = new summize;
$data = $s->search('#carsonified');
$data = $data->results;
?>
<ul>

<?php foreach($data as $d){ ?>
	<li>
		<img src="<?php echo $d->profile_image_url; ?>" alt="" />
		<?php echo preg_replace('/(^|\s)@(\w+)/','\1<a href="http://twitter.com/\2">@\2</a>', $d->text); ?>

		<em>by</em>
		<a href="http://twitter.com/<?php echo $d->from_user; ?>"><?php echo $d->from_user; ?></a>
		<?php echo $d->created_at; ?> <em>from</em> 

		<?php echo html_entity_decode($d->source); ?>
	</li>
<?php } ?>
</ul>

This script outputs the tweets containing the word #carsonified along with profile images, timestamps and links to the client used.

We Love Typography uses similar formatting to pull in tweets with the hashtag #WLT.

In the following source file I’m using a function for formatting the created_at field, so instead of “Fri, 14 Aug 2009 14:24:58 +0000″ you will get something like “3 days, 17 hours ago”.

Get the source for searching Twitter here. You’ll also need the file with the time_passed function for this one.

When the library just isn’t good enough

The search API returns 50 results by default, which might not be convenient for everyone. The class php-twitter doesn’t set the results per page variable in the query strings, so let’s add that. You need to open the class.twitter.php file and replace line 844 with this:

function search( $terms=false, $rpp=false, $page=1, $callback=false )

Finally we add these three lines starting from line 854:

if( $rpp )
$qs[] = 'rpp=' . $rpp;
$qs[] = 'page=' . $page;

After these changes:

$data = $s->search('#carsonified', 5);

would only return the five latest results, and it would set the pagination to page one, whereas

$data = $s->search('#carsonified', 5, 2);

would set it to start from page two.

Know your API

The API Documentation is pretty well done, so make sure to read it. Check out the methods like searching for current or daily trends or listing your followers and go make the next big Twitter app!