Your heart begins to race. Suddenly, it's stifling hot in here. Your palms begin to sweat and your knees are threatening to give up and flee to a vacation in Cancun without you. The dull rhythmic thump-thump in your ears heightens to a frenzied jack-hammer. You can't remember a time when your mouth has been this dry. It's time to begin - and your voice cracks. It's public speaking time and you're the next one up. In this article I'll cover the basics of why presenting PHP is important, who can present about PHP related topics and what you can do to make your presentation stand out.

He starts off by answering the "why" question - why even give a presentation at a conference or local user group? His answer has a few parts and involves things like giving back to the community and being considered an expert in the field. He follows this with a few ways to help your talk stand out - include code samples, give live demos and be entertaining.

As quoted from the LWN review of the book:

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about.

It contains real experience from real developers that work on FOSS projects with chapters titled:

• "Code First"
• "University and Community"
• "Love the Unknown"
• "Quality Assurance"
• "Good Manners Matter"
• "Stop Worrying and Love the Crowd"

The book is licensed under a Creative Commons license (CC-BY-SA) and can be downloaded in multiple formats - ePub, mobi, PDF and paperback, if you prefer that.

I would rather not have to convert these weird characters to the HTML character entities, if possible. I'd rather be able to use these characters directly on the web page. If this is for some reason a bad idea, let me know. This might be more of a general web design question (i already posted it there), but I figured it is still appropriate to post here as well since PHP is used to pull an entry from the database, and I figured a lot of you here would know the answer to the question.

The general consensus is to use UTF8 in this case, but there's a few reminders for the poster too:

• Don't forget to make the database UTF8 too
• Be sure you're sending the right Content-Type for the UTF8 data
• an link to an article about what "developers must know about unicode/charactersets"

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

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.

strip_tags is one of the common go-to functions used for making user input on web pages safe for display. But contrary to what it sounds like it's for, strip_tags is never, ever, ever the right function to use for this and it has a lot of problems.

Specific problems mentioned include "eating" of valid text, not preventing typed HTML entities, the whitelist of tags opening holes and character set issues that could have security implications. Other tools are recommended in both the article and the comments like HTML Purifier, the option of BBCode and Markdown.

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

Every now and then, I get asked by developers who are just getting started in the trade if I have any suggestions to help them out - favourite language, tips and tricks, and the like. None of these things matter, really, but there are a few things I wish I had known when I started out that have nothing to do with the mechanics of software development.

His tips each come with a paragraph or so of explanation:

• Be humble
• There is no magic
• Programming is a craft, not an art
• Software solves problems
• Code doesn't leave sawdust

Recently on twitter, @johncongdon asked me about proposals for conferences. Specifically, he asked if I had any examples that I can share because he was considering submitting to a conference. While I don't have any examples to share, I can give you some advice on the topic.

He offers some recommended reading of one of his other posts and points out that there's not a single version of a proposal that'll work for all events. He also recommends finding a way to be noticed immediately, whether it be by name or by catchy content.

While cleaning out my desk, I found an old copy of a PHP Quick Reference I helped make a few years ago. On the front page are a few performance and security tips that I thought I'd share. (Performance tips are from George Schlossnagle.)

Performance tips include profile early/profile often, cache when possible and don't over-optimize. The security hints include some of the usual suspects - trust nothing, filter input/escape output and use prepared statements.