Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. In this session you will learn how you can offset your technical debt with clean code that is readable and testable as well as reusable.

You can listen to this latest session either using the in-page player or by downloading the mp3 directly. The slides (for a similar version of the presentation) can be found on Slideshare.

With Twitter moving its API to OAuth the idea of using tokens rather than passwords for authentication went mainstream. Many explanations of OAuth make it seem complicated whereas in reality the "OAuth Dance" is a series of simple steps executed in sequence. This talk covers consuming and providing OAuth services, includes implementation examples, and is recommended for all technical leads, architects, and integration specialists.

You can listen to this latest episode either via the in-page player or by downloading the mp3. You can follow along with the presentation in her slides.

I've seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

Sessions so far include:

• Ian Barber's keynote How to Stand on the Shoulders of Giants
• Sebastian Bergmann's PHP Tester's Toolbox
• Scott MacVicar's Scaling Your Development Team
• Alistair Stead's Varnish your PHP application, make it fly!
• Jacopo Romei's Many To Many - No Man Is An Island
• Volker Dusch's Stop Wasting Time By Applying Clean Code Principles

You can find the full list in this link bundle complete with author bios, links to the videos and a summary of each session.

Sessions are a tool which helps the web programmer overcome the stateless nature of the internet. You can use them to build shopping carts, monitor visits to a website, and even track how a user navigates through your application. PHP's default session handling behavior can provide all you need in most cases, but there may be times when you want to expand the functionality and store session data differently. This article will show you how the default functionality works and then goes on to show you how override it to provide a custom solution.

They introduce how sessions are stored normally (based on the save path) and what the serialized contents of it would look like. They show you how to take this, normally stored on the local file system, and change it to be written to a "session" table in a MySQL database (via PDO). It includes reading, writing, updating and some garbage collection to clean out old values from the table.

As software engineers, we all have the potential to navigate the history of our industry, tease out the genius from what has come before, and build a platform for our own ideas. By doing so, we can see that little bit further and in turn provide the foundations for others to build on what we have done.

In this session we'll look at how the history of the web itself is rooted in sharing information and how modern giants like Google and Facebook are founded on what came before them, while being driven forwards by the ecosystems they helped build. We'll see how successful open source projects leverage the past, and how by following some simple principles we can make use of the information, projects and people around us to improve ourselves and our careers.

You cab view other videos from the 2010 event on the PHPNW video channel on blip.tv.

Unfortunately even such a system [using MySQL and InnoDB tables] has limits and unfortunately replication is no good solution here to scale further as we will always need a master for writing the updated session data. By using replication we can take some load from it and we can configure a slave which can be promoted to master to keep session alive if the primary master machine fails but at some point in time we need another solution ... but, happy news, again: One doesn't have to look far as MySQL cluster will be happy to help. MySQL Cluster "is a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment," as the MySQL documentation states.

He describes the setup (after pointing to this post about installing MySQL Cluster for memcache) and includes some sample code/SQL/ini settings you'll need to use to get PHP's memcached functionality to cooperate with it.

$_SESSION is a special array used to store information across the page requests a user makes during his visit to your website or web application. The most fundamental way to explain what a sessions is like is to imagine the following scenario: You are working with an application. You open it, make some changes, and then you close it. That is a session in it's simplest form.

They start with a basic "how to use them" example of setting a username value to the current session and pulling the value back out. They also show the use of the session_unset and session_destroy methods for ending the session. Some security tips are mentioned too - timeouts, regenerating the session ID, destroying them correctly and using a more permanent storage option (by default, they store on the local disk).

Tonight I decided to relax a bit and what better way of relaxing is there for a geek then to do some bash scripting?! So for fun and no profit I decided to try and benchmark pages with ab, Apache HTTP server benchmarking tool, which are behind a login. Turns out, it's pretty easy after reading some man pages.

He includes an example of the format of the "cookie jar" and the shell script he used to grab the PHP session ID from it and inject it into the "ab" call. The script is on github.