Not logged in | Login

My RSS » Planet PHP » December 2009

Feeds

245681 items (663 unread) in 24 feeds

CNN

MSNBC

MSNBC.com: U.S. News (8 unread)
MSNBC.com: Business (5 unread)
MSNBC.com: Technology & Science (3 unread)

PHP

PHPDeveloper.org
Planet PHP (39 unread)
Nettuts+ (18 unread)

Deals

Techbargains.com (20 unread)
dealnews - 20 most recent deals. (281 unread)
Buy.com - Today's Deals (11 unread)
xpBargains.com (232 unread)
GottaDeal.com - Why Pay Retail? (29 unread)

Tech

broadbandreports.com (1 unread)
BetaNews.Com (2 unread)

Web Development

CNN Money

Frugal Blogs

Frugal Dad
The Simple Dollar (1 unread)

Planet PHP

Hello, Analog

Posted: December 31st, 2009, 4:31pm MST by Chris Shiflett

A few months ago, I was on top of the world. The place was called Sjónarsker, and the view was breathtaking. It was the third day of a road trip around Iceland with my friends Andrei and Helgi, and I had just shared some big news with them. I was leaving my former company and starting something new.

They wanted to know what I would be doing next, and although I didn't know, I did have an answer. "Good people. Good work." These four words became a personal mission statement in the months that followed — something to provide focus and clarity.

Good people and good work go hand in hand. I remember how much I enjoyed working with Jon Tan and Jon Gibbins a few years ago when redesigning my blog. The experience is perhaps best remembered with a comment I made shortly after we finished:

Working with both Jon Tan and Jon Gibbins was a joy; not only do they possess the skills necessary to shape ideas and bring them to life, but their rich personalities and keen sense of humor makes the entire process a lot of fun.

Good work isn't work; it's fun. To do our best work, we need to love what we do. We need to surround ourselves with good people who appreciate good work. We need the freedom to break boundaries. We need to be inspired. Above all else, we need to be happy.

I'm very happy to introduce Analog, a co-operative of web designers and developers:

Analog is a company of friends who make web sites. It's a co-operative where imagination, design, and engineering thrive; good people doing good work.

Allow me to introduce you to my friends.
Alan Colville Alan is a user experience designer who has been making the Web a better place for more than a decade, helping companies like BlackBerry, Vodafone, and Visa. Although his professional experience is impressive, we're more impressed by his achievements on a bicycle, like being the runner-up at the Kona Cheddar Bikefest 2009. Andrei Zmievski Andrei is one of the best developers I know, and if you use PHP, chances are you've encountered his work. He's a member of the PHP Group, started PHP-GTK, helped create Smarty, and is the architect of the Unicode and internationalization support in PHP 6. In fact, when Yahoo switched to PHP, they hired Andrei. He's also a talented photographer and brewer, and 100 days from now, he'll be running the Marathon de Paris. Jon Gibbins Jon, also known as Gibbo or the Prince of Kindness, is a multi-talented web developer and accessibility aficionado who has helped companies like Travelodge and National Geographic. His mastery of html, CSS, JavaScript, and PHP is truly inspiring. On occasion, he suspends his kindness long enough to play a mean guitar. Jon Tan Jon is the best designer I know. I first encountered his work long before I knew him as a person, and I still feel extremely lucky to know him. His love of typography is evident in all of his work, and he's one of the only members of the International Society of Typographic Designers who focus on typography for the Web. He's also a former journeyman in the Guild of Indian Ocean Octopus Fishermen. I'm pretty sure the guild is made up, but the stories are real. :-)
Co-operatives are organizations that adhere to the co-operative principles. Jon's description of his personal values — values we all share — helps explain what we're about:

I believe that everyone working on a project should profit equitably from it according to the scope of their
Truncated by Planet PHP, read more at the original (another 2732 bytes)
Midgard in 2009

Posted: December 31st, 2009, 4:23am MST by Henri Bergius
2009 was a pretty active year for the Midgard content repository project, and so it is good to take a look at some of the highlights:
- Midgard2 finally became a reality, bringing us a fully legacy-free modern Midgard implementation. There were two releases: 9.03 Vinland and 9.09 Mjolnir. Midgard2 works just fine also in desktop applications and mobile devices like the Nokia N900
- Ragnaroek, the long-term support version of Midgard1 kept chugging along with four new maintenance releases and total of 566 issues closed. Ragnaroek will be maintained until October 2013
- The Midgard Project turned ten years old in May. A gala evening and party was held in Helsinki, Finland
- Midgard's content repository gained bindings to two new programming languages alongside existing PHP, C and Python: Objective-C in March and Vala in December
- Midgard was one of the CMSs admitted to the EU-funded Interactive Knowlegde project that aims to increase semantic capabilities in content management
- Qaiku, a conversational microblogging platform powered by Midgard MVC was launched in March
- We had two Midgard Gatherings: in March in Linköping, Sweden and in October in Helsinki, Finland
- Ragnaland became a way to bridge the gap between Midgard1 and Midgard2 by enabling running of MidCOM applications on top of Midgard MVC
- Midgard was presented in several conferences including Gran Canaria Desktop Summit, FrOSCon, OpenMind and FSCONS
- Founding meeting for an association to support the Midgard project was held in December. The association will provide membership to all active Midgard contributors, and an alumni membership for people who have been part of the project in the past
Happy new year to everybody in the Midgard world!
PHP Development Environment 2.0

Posted: December 30th, 2009, 7:26pm MST by Derick Rethans
PHP Development Environment 2.0 London, UK Thursday, December 31st 2009, 02:26 UTC
When moving the Xdebug website and my own website to a new server I had to pick a web server to serve the pages through PHP. Up to then I was still using Apache 1.3 with zero intentions to ever upgrade to any later version. I'd heard a lot about lighttpd">[httpd.net] and decided to give that a try—yes, that meant something that I didn't really know to well was going to run in a production environment. Unlike Apache, with li [httpd] PHP doesn't run as a module, but instead you run it out of process with something called FastCGI.

On my development machine I was also running Apache 1.3 with PHP as static module embedded. If I want to test something with a different PHP version, I would start a different Apache daemon. When I had a quick look the other day, I found that I had about 28 different binaries named httpd-{Apache version}-{PHP version} ranging from PHP 4.1.2 to 6.0dev. Some of those I hadn't used for years.

All my PHP installations were installed with the same prefix (/usr/local), where the last built PHP version was available as php and additional versions as php-{version}. An annoyance with this is, is that I had to run make install in one of the PHP source directories before I could compile extensions against a different PHP version than the latest installed one. This combined with the enormous amount of [httpds] and the inability to run multiple versions of PHP at the same time prompted me to come up with something better: PHP Development Environment 2.0.

Multiple PHP Installations

The first thing I wanted to do was to make sure that each minor PHP version (5.1.x, 5.2.x, 5.3.x and 6.0.x) could be installed alongside each other, and that I could compile extensions to all of them without having to re-run make install. I did this by specifying --prefix=/usr/local/php/{PHP version} to the PHP configure call. At the same time, I also removed the --with-apache configure option and for PHP 5.1 and PHP 5.2 I added the --enable-fastcgi option which is default enabled for PHP 5.3 and PHP 6.0. The initial section of the configure invocation now looks like for the PHP 5.2 build:
```
./configure --prefix=/usr/local/php/5.2dev --enable-fastcgi \
  --with-gd  ...more configure options here...
```
Although /usr/local/bin is usually in the path, but /usr/local/php/5.2dev/bin is definitely not. The initial goal was to be able to easily switch between different PHP versions, so I added a snippet to my .bashrc that sets the correct PATH environment variable depending on the selected PHP version:
```
function pe () {
  version=$1
  shift

  if [ "$#" == "0" ]; then
    export PATH=/usr/local/php/${version}/bin:/usr/local/bin:/usr/bin:/bin
  else
    PATH=/usr/local/php/${version}/bin:$PATH $@
  fi
}
```
This bash function is then evoked like pe 5.3dev to set the path in such a way that php runs the PHP 5.3 binary, as well as additional tools such as pear, phpize (required to build extensions) and php-config. If you forget to call the pe function, then when running php you will encounter the warning bash: php: command not found. You could pick a default version if you wanted, but I prefer that I always have to be explicit about which PHP version I pick. Multiple install paths makes it easier to maintain multiple PHP installs, but it also means that you have to install tools such as PHP Unit for each of the installations.

Setting up Li [httpd]

Now that I had multiple PHP installations, I could move on to setting up li [httpd.] As I have mentioned, I never used li [httpd] before and decided to take the easy way by installing it with apt-get install li [httpd] . PHP works through the FastCGI interface with li [httpd] which you can enable with li [httpd-enable-mod] cgi fastcgi simple-vhost (I also enabled CGI and simple VHOSTing).

To enable PHP as FastCGI server, and to be able to run multiple versions at the same time, I modified the /etc/li [httpd] configura
Truncated by Planet PHP, read more at the original (another 2708 bytes)
The ZendCon Sessions Episode 29: PHP – Faster And Cheaper. Scale Vertically with IBM i

Posted: December 30th, 2009, 2:27pm MST by Zend Developer Zone

Welcome to the new, ZendCon 2009 edition of the ZendCon Sessions! The podcast that rebroadcasts sessions/talks from the last ZendCon PHP Conference. This episode of The ZendCon Sessions was recorded live at ZendCon 2009 in San Jose, CA and features Sam Hennessey giving his talk: “ PHP – Faster And Cheaper. Scale Vertically with IBM i”
2009: What a year

Posted: December 30th, 2009, 2:18pm MST by John Mertic
Looking back on 2009, I can say that this has been quite a year for me and my family this year. Just to name a few things:
- Celebrated 2 years at SugarCRM
- Wrote my first book, The Definitive Guide to SugarCRM
- Started speaking at several different conferences; SugarCon, DC PHP Conference, and the Ontario GNU Linuxfest.
- Began the process of an international adoption from South Korea with Spence-Chapin.
I’m looking forward to an even more prosperous and rewarding 2010, including speaking at Confoo.ca in March, more writing, welcoming a new child into our home, and turning the big three-oh . Happy New Year to everyone!
Paging and Sorting Data with Zend Framework, Doctrine and PEAR (part 2)

Posted: December 30th, 2009, 1:40pm MST by Zend Developer Zone

In the previous segment of this article, I introduced you to the Zend_Paginator class, which provides a flexible API for paginating any data collection, whether it is expressed as an array or a database result set. However, Zend_Paginator isn’t the only game in town. There are a number of other open-source PHP pagination widgets, which can be used as an alternative to Zend_Paginator.
Keith Casey on “Joining a Startup”

Posted: December 30th, 2009, 10:49am MST by Paul M. Jones

Keith Casey has a great series of points about joining a startup here, especially the part about founders who “believe in themselves”. To this, I must also add a recommendation to read Gerber’s The E-Myth for entrepreneurial-minded programmers thinking about starting a business of their own.
PHP Mess Detector 0.2 released.

Posted: December 29th, 2009, 3:40pm MST by Manuel Pichler
Today I have released version 0.2.0 of the PHP Mess Detector or short PHPMD. PHPMD is a simple, customizable and user friendly frontend application for PHP_Depend. It takes the raw metrics measured by PHP_Depend, compares them with appropriate thresholds and generates a report that lists those software artifacts with potential problems. Such a report can be taken as a basis for human code audits or you can use it as input for an automated build/reporting tool.

Most concepts behind PHPMD are based on those of the well known Java Tool PMD. It uses so called rule set files to organize different sets of rules. There are two purposes that are accomplished by these xml files. The first is to create custom sets of rules which fulfills the projects requirements. The second purpose is the configuration of each rule with thresholds, warning messages and other things. The format of these files is totally borrowed from PMD, so that the reuse existing rule sets in multi language environments should be easy. At the moment PHPMD has two build-in rule sets. One that detects software artifacts with high code size, and the second one detects unused code in your software.

Now lets start with a small How to use it. PHPMD can be called from the command line by typing phpmd, which prints a general help text.
```
mapi@arwen ~ $ phpmd 
Mandatory arguments:
1) A php source code filename or directory
2) A report format
3) A ruleset filename or a comma-separated string of ...

Optional arguments that may be put after the mandato...
--minimumpriority: rule priority threshold; rules with ...
--reportfile: send report output to a file; default to ...
--extensions: comma-separated string of valid source ...
--ignore: comma-separated string of patterns that are ...
```
Now let's call PHPMD on its own source, with a simple text report on STDOUT and the codesize ruleset:
```
mapi@arwen ~ $ phpmd ~/phpmd/source text codesize

/home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:66 \
  This class has too many methods, consider refactoring it.
/home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:267 \
  The method _parseSingleRuleNode() has a Cyclomatic \
  Complexity of 11.
/home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:326 \
  The method _parseRuleReferenceNode() has a Cyclomatic \
  Complexity of 10.
```
The --reportfile option can be used, to redirect the report output into a file. So let us repeat the previous example that writes the report into a file, additionally uses the unusedcode rule and changes the format from text to xml.
```
mapi@arwen ~ $ phpmd ~/phpmd/source xml codesize,unusedcode \
  --reportfile ~/pmd.xml
mapi@arwen ~ $ cat ~/pmd.xml 
<?xml version="1.0" encoding="UTF-8" ?>
<pmd version="@package_version@" timestamp="...">
  <file name=".../source/PHP/PMD/RuleSetFactory.php">
    <violation beginline="66" endline="417" rule="TooManyMet ...>
      This class has too many methods, consider refactoring it.
    </violation>
    <violation beginline="267" endline="315" rule="Cyclomati ...>
      Method _parseSingleRule() has a Cyclomatic Complexity of 11.
    </violation>
    <violation beginline="326" endline="367" rule="Cyclomati ...>
      Method _parseRuleReference() has a Cyclomatic Complexity of 10.
    </violation>
  </file>
</pmd>
```
This xml file is compatible with those files generated by PMD and PHPUnit's deprecated --log-pmd option. So that it should be no problem to use this files in existing environments like "/>
Truncated by Planet PHP, read more at the original (another 1224 bytes)
The story behind TEK·X’s Charter Ticket program

Posted: December 29th, 2009, 10:14am MST by Marco Tabini

Unless you’re living under a particularly large rock, you’ve probably heard that we are doing a special promotion, which we call Charter Ticket Program, that makes it possible to purchase a full-experience TEK·X ticket—valid for both the main conference and tutorial day—for $650. The catch (if you want to call it that) is that the special is only valid until we announce the schedule—so, effectively, you need to put a lot of trust in our ability to attract top speaking talent and stitch together the schedule of a conference that you will want to attend.

Given the incredible response that our call for papers has received—over 9 proposals for each speaking slot—I have no doubt that we will be able to create a schedule rich in variety and topics that are very relevant to PHP developers from all walks of life. If anything, we’ve had a really hard time finding room for all the talks that we wanted to be part of TEK·X and, although I believe that my colleague Keith Casey will have some hopefully welcome news on this subject to share in a few days, we’ve run out of room much sooner than we ran out of good talks to approve.

The reasoning behing the Charter Program is very simple: we recognize that there is a core of attendees for whom our conferences have become an opportunity to meet up with their peers and learn what’s happening in the PHP world. In fact, there are some who have been to all of MTA’s conferences, so we felt that they deserve a little some extra special.

The Charter Program is designed specifically for these folks: at $650, the current price of the tickets is almost half the price of a regular ticket at the door—and $350 less than the lowest early-bird price. It is the lowest price you will be able to secure a spot at TEK for—an opportunity for a great deal if you put a little faith in the folks who have brought so many memorable events to the PHP community.

To take advantage of the Charter Ticket Program and save as much as 45% over the price of a full-experience ticket, you must sign up for TEK·X before January 6th, 2010, when our schedule will be officially announced.
A great 2009 !

Posted: December 29th, 2009, 4:01am MST by Michelangelo van Dam
It's that time of year again where one looks back to all the things that have happened in the past 12 months. 2009 has to be the most thrilling, fastest ride ever and I'm really surprised to see it's nearly the end of this year.

PHP
The most thrilling part of 2009 was the release of PHP 5.3 on June 30. With this release, PHP has risen to a new level of development implementing some long awaited features like DateTime, namespaces, closures, gotos (who wants to use that ?!?), late static binding and an improved garbage collection. Also new extensions were added to this release like ext/phar, ext/fileinfo and ext/intl.
I want to express my gratitude to all those developers who have made this release possible and to all the participants of PHP Test Fest for making their contributions worth the while.

Zend Framework
It's also worth mentioning that Supreme Allied Commander Matthew Weier O' Phinney, his team and all developers around the world have done a great job improving Zend Framework. With the release of Zend Framework 1.8, lot's of things changed within the way applications are being bootstrapped and provided a more flexible way to deploy feature rich applications with a very modular structure.

PHP Conferences
For me personal it was a very exciting year where I was speaking at some great conferences on stage and in uncon sessions (thank you Keith!). If budget allows it, I'll be attending these conferences again in 2010.
- PHP UK (attendee)
- PHP|Tek (uncon speaker)
- DPC (speaker)
- PHP NW (speaker)
- ZendCon (uncon speaker)
One conference will be added to this list in 2010 since I'll be co-organizing it: PHPBenelux Conference.
If you ever want to catch up on the hottest game in PHP, be sure to check out these and other great PHP conferences on the PHP website. You'll learn so much from the conference itself, the speakers and the audience itself, it's really worth the money.

Macq Electronique
Since March of this year I've been working as a PHP/Zend Framework consultant for Macq Electronique, a hardware manufacturer in Brussels that provides hardware solutions for governments (like automated traffic panels, speed enforcement cameras, tunnel control and pump installation monitors). I would like to thank the company for giving me inside view of these infrastructures and I'm excited to work with them again in 2010.

Thank you !
I would like to express my gratitude to the following people who have thought me a few valuable lessons that I can use in my personal and professional life:
- Cal Evans:
  Cal, to you we now have our own PHP conference in January. Without your support, advise and never ending belief in us, we weren't able to pull it off. Thank you !
- Matthew Weier O'Phinney:
  Matthew, although we never had the chance to sit down and discuss things I do want to thank you for all the good work you have done for Zend Framework and the PHP Community. If it wasn't for you, I'd still be stuck writing crappy code with code replication and re-inventing the wheel all over again. Thank you !
- Keith Casey:
  Keith, thanks to you I was able to talk about stuff that matters to me and being able to inspire people to become interested in things like SPL and Unit Testing. Thank you !
- "/>
Truncated by Planet PHP, read more at the original (another 1314 bytes)
Zend Framework 1.8 Web Application Development review

Posted: December 28th, 2009, 4:33pm MST by Danne Lundqvist

Packt Publishing sent me a copy of Keith Pope’s Zend Framework 1.8 Web Application Development a while ago. In return they asked me to write what I thought about it. I have had it lying on my desk for a while but haven’t had time to read it more carefully. Nevertheless I have actually used it every now and then. Now, after reading a bit more the last few days, I can finally give my opinion on the book.
Programming books in general
I’d better start off with telling you that I haven’t read many “pure” programming books since the mid 1990’s when I was studying at the university. I tend to stick to books on concepts and methodologies and then read online tutorials and articles when it comes to programming. Programming books are rarely worth the money as they are either reference books which gets out of date quickly (I’ve thrown away quite a few Java books over the years…) or learning by example books which you painstakingly slowly must follow line by line to build something thousands open source projects alrady built.

My thought was that this book was probably both outdated (as ZF 1.9 has been around for awhile) and probably boring in that building a web shop isn’t that interesting. I was wrong in all ends.
The book
I especially like the way Pope introduce the MVC concept in Zend Framework. In the first chapter you get a good overview on configuration, the bootstrap process, controllers, action helpers, views and error handling. Chapter two goes deeper into the specifics of the request and routing. He also briefly delves into more advanced topics as plugins and component customization. The reader quickly gets a very good grasp on how to work with MVC applications in Zend Framework.

Another thing I like is how Pope reasons about various strategies; both pros and cons as well as how and how not to do things. Good examples are chapter four where Pope gives a good explanation on the Fat Model Skinny Controller strategy and chapter five with it’s best practices regarding accessing models from views with the help of view helpers. Reasoning and explanations like this is good, especially for unexperienced developers. This - and giving optimization and testing their own chapters - makes the book better. As Pope is thowing in both Zend Tool as well as Ant into the book makes it even better still.
Summary
To sum up my opinions the structure of the book makes it easy to read at leisure as well as using it as reference later. The MVC concept and how it is used in ZF is way better explained than in the ZF documentation. (Truth be told the documentation is hopeless here.) I’ve been working with ZF a “long” time now and whether the book is better for complete beginners or programmers at least a little bit familiar with Zend Framework I really can’t tell. Remembering how I struggled to find a good introduction to various topics found in the book I belive this book is a better introduction to Zend Framework than can be found in online tutorials and articles - or even the online documentation.

However, a beginner will get more out of this book than just learning Zend Framework. He, or she, will also learn about unit tests, build procedures and best practices.
PHP Advent

Posted: December 27th, 2009, 7:55pm MST by Helgi Þormar Þorbjörnsson

With Christmas over it also means the annual PHP Advent calendar has been concluded. As with previous years, there is a good bunch of authors with a great choice of articles, worth reading if you haven’t done so already. You can also read 2008.

I find the idea of article driven advent calendars absolutely fantastic, as it gives authors an interesting venue to write for and readers new quality material to read every day for 24 days. With a lot of my TV shows going on a break in December, I cherish the opportunity queue up a few quality article and putting aside an hour or two to read through, with hot chocolate. PHP Advent is not the only one I read, two other advents I’ve been keeping tabs on is the Web Design Advent and the Performance Advent, and you should as well.

I would like to applaud both Chris Shiflett (@shiflett) and Sean Coates (@coates) for starting PHP Advent and keeping it going. They do a lot of work that goes unnoticed, ranging from finding authors way ahead of time, to cat herding the authors and making sure everyone is on time, over to doing copy writing on our scribbles to make us sound at least mildly coherent, at least they did for me :-)

They are the men behind the scenes, so please show them your appreciation and drop them a line and say thanks, since we all want this to keep on going next year. Chris & Sean, I take my hat off for you for spending countless hours making this happen, especially during those evenings in December where you slaved over copy writing articles and making sure everything ran smoothly.

I would like to point out that I’ve been an author for PHP Advent for the past 2 years, so I’m fairly bias about it being so great :-)
Also a shameless self plug, here are my articles of last 2 years: Coping with the Holiday Shopping Spree (2008) and Designers versus Developers (2009). I hope you have as much fun reading them as I had writing them.
Posted in PHP Tagged: advent, design, performance, PHP, phpadvent, web
$Permalink for 'PCRE Regex Word Matching: "\w" vs "a-zA-Z0-9_"'$
PCRE Regex Word Matching: "\w" vs "a-zA-Z0-9_"

Posted: December 27th, 2009, 11:47am MST by Pádraic Brady

Since I couldn't find a ready answer to this elsewhere, I figured I'd just go dig around myself to check it. It's probably nothing new to those happy in C-land though .

The problem arises in code I've been reading which uses the following assumption, that these two regular expressions are the same:

$string = 'abcABC123_';

$result1 = preg_match("/^[a-zA-Z0-9_]+$/D", $string); // true

$result2 = preg_match("/^[\w]+$/D", $string); // true

You can find the "word" generic character type used in a lot of PHP code including the Zend Framework. The problem is that the assumption above is incorrect. Now, most of the time these act identically because PHP is compiled using its own packaged PCRE library. However, I've seen more than once systems where this is not the case. Usually in some non-English capacity where additional locale support was considered necessary or standard practice.

In these case, PHP is compiled against a custom PCRE compiled lib. One that includes locale support with extended character ranges. For example, many French words will use acute characters (there's one in my name though technically it's a Gaelic fáda). With such locale support, the \w generic type no longer matches a-zA-Z0-9_.

$string = 'abcABCáÁ_'; // french a-acutes

$result1 = preg_match("/^[a-zA-Z0-9_]+$/D", $string); // false

$result2 = preg_match("/^[\w]+$/D", $string); // true

The result? Code using the \w type often needs fixing .

To harmlessly test this out yourself, you can compile your own local copy of PCRE (PHP let's you select it when compiling if you want to go that far). It only takes a few minutes and a locale change. You can change your locale temporarily, but it's nice to have something like a test or virtual instance to try this out. The instructions below are for Ubuntu Linux assuming a locale for French (ISO-8859-1). I haven't tested another locale, but it should work on most of the European ones. I'm not sure whether this works on UTF-8 encoded locales however.

To change your locale, edit /etc/default/locale to contain:

LANG="fr_FR"

You will also need to generate this locale using:

sudo locale-gen fr_FR

This generates the fr_FR locale for ISO-8859-1 (not UTF-8). Restart your system so it can take effect. Running the "locale" command after the restart should show it in effect.

Next download PCRE (the latest version is 8.00) from [ftp:] .

We first need to compile this once since the PCRE locale support needs access to some initial tools like dftables:

tar xvfz pcre-8.00.tar.gz
./configure --prefix=/opt/loc
Truncated by Planet PHP, read more at the original (another 1504 bytes)
New website layout

Posted: December 26th, 2009, 8:13am MST by Derick Rethans
<?xml version="1.0"?> New website layout London, UK Saturday, December 26th 2009, 15:13 UTC
Just like Xdebug's server was moved 1 to a new VPS at XtraHosting so did my personal website (the one you're looking at). Hosting it on my own gives me full control over what software runs it, and which PHP version and extensions I run. I switched most of the code from a PHP 4.1 atrocity to PHP 5.3 goodness.

At the same time, I also moved all the contents from some self-invented XML format to reStructuredText. reStructuredText is a format that can be parsed and transformed into other formats by eZ Components' Document component. Right now I am transforming to html only, but in the future I will also transform certain articles to PDFs. Comments can also make use of some of the reStructuredText formatting options, but there are still some things that need sorting out there.

Besides changing the layout and converting the content to a more manageable format, I also introduced a stream of dopplr, flickr and twitter updates on the right side. This is implemented by parsing the relative RSS feeds from the different sources. If location information is present, this is also shown in this feed. Previously I would only export an RSS feed for all of the content, but with this site update, there is now a feed for every tag that I've used. All RSS functionality is provided by the Feed component of eZ Components (although a patch is currently needed for the location information).

I'm not a 100% happy with the new layout, so most likely I will be doing some changes in the near future.
- 1
  [derickrethans.nl]
Symfony? I like it!

Posted: December 26th, 2009, 7:25am MST by Lukas Smith

Like I mentioned in my last blog post, we have a company internal framework that is quite advanced thanks to the various symfony components we have integrated. Its other main advantage is that it can do a lot with very little code. The net benefit of this is that it's extremely easy to learn and debug. Especially the last point can be somewhat painful with symfony since inheritance trees tend to be quite large and things get delegated to other objects etc. However once you start getting a hang of where things are, symfony is very powerful indeed. The other day we had a little hackday at Liip where we wanted to write a little google maps app. The idea was to have different kinds of markers shown on the map which when clicking on them would both load some data into the classic GMap marker bubbles as well as some additional data into a div below. Furthermore, the markers should be filterable. We choose symfony 1.4 as the basis, mostly because we wanted to learn a bit more about symfony, but also we felt that some of the module generation tools could help us get off the ground faster.

We are not quite done yet as things ended up taking a bit longer than we expected, but I think we lost more time with the GMap javascript simply not being at the same level as other JS frameworks like JQuery or YUI. Seems like Google has some catching up to do. Anyway, in the end a co-worker gave us some key tips in order to make the GMap-YUI-combination work out, but thats not really my area of expertise anyway. In the end we decided on the following communication flow: The backend would (re-)generate a javascript file whenever a new marker gets added or one gets deleted or if the name, latitude or longitude of a point changes. The js file would also store the type of the marker. This way we could quickly show all markers on the map with an icon to denote the type. Whenever the map is repositioned, we would send the boundaries to the server, who can then run a simple query to fetch the data to be shown in all the bubble currently visible on the map in one request. Then when someone actually clicks on the bubble we would load the additional details to be shown below in another request. The filtering would basically just return a full list of ID's of all markers that should still be visible. We figured that this way we could really limited perceived latency to an absolute minimum: You immediately see the markers are you move the map around. Once you let go we load all the information in the visible bubbles so you immediately get something when you click on one and finally if you are really interested to see all the data on the marker, we have some time to load that data as your eyes travel below the map. Most of this has been implemented by my co-workers Memi and David already.

I was mostly working on the backend and the first thing I did was setup the DB schema, for which I choose the Doctrine yaml format. After a bit of experimenting I settled on using inheritance. This way I would define a base "entity" model, form which I could extend all the various custom data types. This way I could also keep the entire logic for regenerating the javascript file with the map markers in this "entity" model class. However Doctrine 1.x inheritance is a bit annoying. You have the choice of either simply lumping together all fields including all specializations into one table (column aggregation) or to keep the data totally separate in one table for the parent and another one each for all the specializations (concrete). Doctrine 2.x will add another inheritance solution, where you actually store the common data in the parent table and only create tables with the additional data for each specialization.

Since Doctrine 2.x isn't ready for prime time yet I decided to use concrete inheritance with some magic. The key thing was to ensure that if a markers gets added, updated or deleted it would regenerate the cached markers javascript file. With a simple preSave()/preDelete() hook in the entity model it was easy to automatically regenerate said file. Actually in the case of an update I only need to regenerate if the name, latitude or longitude changed. So I added a preSave() hook that would check what properties were modified in the case of an update. Generating the file will probably never be such a big deal, but regenerating the file would also cause all users to have to reload the javascript file which just adds traffic and
Truncated by Planet PHP, read more at the original (another 6973 bytes)
PHPUnit Development Moved to GitHub

Posted: December 26th, 2009, 3:45am MST by Sebastian Bergmann
Over the Christmas holidays I took a break from translating and editing the book on quality assurance in PHP projects that I am working on to finally migrate the code repository of PHPUnit from a self-hosted Subversion repository to a Git repository that is hosted on GitHub.
How did I get here?
I was staying at Arjen's place in Brisbane in August 2008 and one day we talked about distributed version control. Although I knew the basic concepts behind it, I was not yet convinced enough to take the plunge and try it out. Our discussion changed that, but it was not until my second trip to Australia later that year that I took the initial code for PHP_ObjectFreezer (which I had on my laptop since I started to hack on it together with Stefan on the flight to Atlanta for php|works 2008) and put it into a bzr repository on Launchpad. I grew comfortable enough with bzr quickly, but never really warmed up to Launchpad.

Around that time, I was hearing more and more positive things about Git and GitHub from my peers. So I took the PHP_ObjectFreezer code base and migrated it to Git and hosted the repository and GitHub to experiment with both the tool and the platform. It was a step that I did not regret and all the projects that I started since then are hosted on GitHub: bytekit-cli, phpcpd, phpdcd, phploc, PHP_CodeCoverage, PHP_FileIterator, PHP_ObjectFreezer, Text_Template, PHP_TokenStream.
Why did I do this?
Let me start with a quote from GitHub.com:
- Git is a fast, efficient, distributed version control system ideal for the collaborative development of software.
- GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease.
Over the last year, I have come to appreciate Git and GitHub a lot and also wanted to use them for PHPUnit.
Sure, I could have used git-svn for bi-directional operation between the existing Subversion repository and Git, but this would have always felt like only going half the way.
The arguments in favour of distributed version control systems are discussed by others far better than I could discuss them here, so I will just quote Ian Clatworthy's paper on distributed version control systems, in which discusses not only the technical differences between traditional version control systems and distributed version control systems, but also the differences with regard to development workflows and developer interaction:
- Developers can collaborate directly without needing central authority or incurring central administration overhead
- Developers can still be productive when the umbilical cord to their central VCS repository is broken, e.g. when travelling.
- Creating and destroying branches are simple operations. This is particularly useful when experimenting with new ideas, e.g. a spike when using eXtreme Programming.
- Ad-hoc collaboration with peers [is facilitated by] intelligent merge tracking [because] merging early and merging often is both possible and surprisingly unpainful. It is difficult to explain just how much of an impact this can make on how co-developers can work together more easily, e.g. when Pair Programming.
What does this mean for you?
PHPUnit is now hosted on GitHub.

In a nutshell, this means that the development of PHPUnit is now more open than it was before. If you want to contribute, you just need to fork PHPUnit on GitHub and create a topic branch for
Truncated by Planet PHP, read more at the original (another 2521 bytes)
Twas the Night before Christmas

Posted: December 24th, 2009, 11:47am MST by Keith Casey

Twas the night before Christmas and all through the house,
Not a peripheral was stirring, not even my mouse.

I with my Xbox and wife with the same
had just settled down to a nice co-op game.
I covered the front, she took the rear
our enemies had a dynamic duo to fear.

At a loud crash, I arose from the chair
wondering "what could be happening down there?"
We entered the room and what did we see,
but two surprised cats and a sad Christmas tree.

"But wait, what is that in the paws of the kitten?"
Something unexpected, something unbidden.
A gift certificate for Amazon, another for Fry's,
both looked like glittering gold in my geek eyes.

My imagination went wild, it just wouldn't stop,
so many ideas, my head might just pop.
But then I wondered "from where did this appear?"
and the wife agreed "this wasn't just here."

I scanned the room and looked for the source,
everything was in order as a matter of course.
Everthing was in place, right where it belonged.
But wait.. that's not right.. that's entirely wrong.

The books were all sorted according to writer,
even the whiteboard was a little bit whiter.
The cables were untangled and sorted with care,
I couldn't move, I stood there and stared.

This didn't make sense, how could it be?
Is this a big joke, is someone messing with me?
I checked my computer but it was fine.
I still had ten bugs waiting.. No, now nine.

Then eight then seven then six, now five,
what is happening is this thing alive?
Another minute and what did I see
but twenty-eight commits in the source tree.

I looked at the code and something was wrong,
I knew my coming nights would be way too long.
The code was small and fast but I wanted to hurl,
the whole damned thing was written in Perl.
Ajax requests using jQuery and PHP

Posted: December 23rd, 2009, 11:17pm MST by Web Development Blog Â» PHP scripts
Our last tutorial about the flickr API was an example on how-to search the flickr photo database for images using some short PHP code. This time we will use parts from the past tutorial together with some jQuery Ajax requests to show our photo search result without reloading the web page.
jQuery’s Ajax implementation
One of the most powerful jQuery functions is the Ajax function. The function provides enough options to make your XM [HttpRequest] flexible enough to define;
- what type of response you need like to handle in your Ajax application (XML, JSON, html, script or text)
- an option about what the script need to do before the request is send (validations, set a pre-loading image, etc.)
- What to do after the request and response are successful
- and options like the request URL (f.e. your PHP script), the time-out value and more. Check the jQuery page for all available options.
The Ajax powered flickr image search
In this tutorial we will create a PHP script that will search the flickr database for posted values using the flickr API. On the client site we will use some simple html search form and some easy to understand jQuery Ajax code to handle the requests. If you like to test this tutorial code your should try our flickr Ajax search demo.
html search form
For this tutorial we create a simple form with only one search field and a button. Below the form we have a DIV container with ID result as placeholder for the images. Inside the header we need to include the latest jQuery library, download a copy from the jQuery website if you haven’t done yet.
```
<form>
	<div>
		<label>Enter keyword</label>
		<input type="text" name="search" id="search" value="" />
		<input type="button" name="submit" id="searchBtn" value="Search" />
	</div>					
</form>
<div id="result"></div>
```
jQuery Ajax functions
We use a click event to process the search if the user had clicked the forms button. Before we post the request to our PHP file getFlickr.php, we perform a test for the search field. If there is no search string we return
Truncated by Planet PHP, read more at the original (another 15044 bytes)
1,500 Lines of Code

Posted: December 23rd, 2009, 10:00pm MST by PHP Advent

Even the best of us can only write 1,500 lines of code a day, so we need to make those lines count.

There were so many great articles in PHP Advent this year, I couldn’t think of a good topic — I like to believe my peers stole all the good ideas. :-)
A decade of PHP
This Advent marks the day I’ve been a professional PHP programmer for a decade. Ten years ago, I was consulting for a startup consisting mostly of Asians, which meant a lot of smoke breaks. During one of those particular breaks, a programmer asked me, “Hey, Terry, have you heard of PHP?”

“No, what’s that? Some new designer drug?”

“Haha! No, it’s a web language like ASP 1, but it’s free. You should check it out; you might like it more than Perl.”

Instead of smoking a pack of this in honor of that day, let’s begin with some startup stories spanning that decade.
The John Henry of C++
A few startups ago, I worked with a guy who was a better programmer than you.

One day, we got into an argument over a piece of open source import code — written in Python — that he had ported to C++. He had just finished telling me how much faster he had made it, when I asked, “What’s the point in that? Now that you’ve rewritten it, you own the maintenance of it. (Stoyan would disagree.) There is no evidence this code is even the bottleneck.” 2

The point? The code was crap, and he had fixed it — the massive improvement in efficiency was an added bonus.

“Look you’re right. It’s true I prefer to use a crappy, ugly, underperformant language like PHP, and you crank out C++ like John Henry drives steel. But, while you’re busting code with a hammer in each hand, I’m the guy with the steam-powered jackhammer. Sure, you win, but your heart will burst, and you’ll die.”

“And here’s the thing,” I added with a devilish grin, “There’s only one you; there are a lot of people like me out there.”
1,500 lines of code a day
That philosophy started out with an observation I made while being the director of engineering at an earlier startup. It was the kind of startup that all programmers have to cut their teeth on at some point — the kind where you, like Laura, have to put in 170-hour weeks and program uphill both ways.

— Who would have thought 10 years ago that I’d be writing a PHP Advent article drinking Château d’chatalé?

Although I did not actually put in 170-hour weeks 3, I did sleep under my desk. I also didn’t program uphill both ways, but I did spend my days programming and my nights integrating all my engineers’ daily commits. It was during this nightly integration that I made a startling observation. No matter what the programming language, no engineer — including myself — wrote more than about 1,500 lines of code a day.

This observation affected my engineering judgements and decisions for the next decade. It is a maxim I live by today. If we can only write 1,500 lines of code a day, then a quarter of a million lines of code takes about a year. If we can only write 1,500 lines of code, we had better choose the right language and use it in the best way to maximize the expression of our creativity.

When I told this to a friend, he added, “1,500 lines a day… except in Java. J2EE programmers only write
Truncated by Planet PHP, read more at the original (another 35795 bytes)
The ZendCon Sessions Episode 28: PHP 5.3 == Awesome!

Posted: December 23rd, 2009, 8:34pm MST by Zend Developer Zone

Welcome to the new, ZendCon 2009 edition of the ZendCon Sessions! The podcast that rebroadcasts sessions/talks from the last ZendCon PHP Conference. This episode of The ZendCon Sessions was recorded live at ZendCon 2009 in San Jose, CA and features Ilia Alshanetsky giving his talk: “ PHP 5.3 == Awesome!”
An Interesting TEKX Promotion…

Posted: December 23rd, 2009, 8:23pm MST by blog.phpdeveloper.org Â» PHP

Thinking about attending a PHP conference anytime soon and looking for an offer that you can’t refuse? Check out this interesting move from the MTA folks (the group that puts on the “tek” conferences each year) for attending the TEK-X conference in the spring. The regular ticket price after the Early Bird pricing time has passed checks in at $1,000 USD per ticket. For this low, low price you get full access to the conference – tutorials and sessions for the full time of the conference. What? You don’t think that’s a good deal? Well, good – because that’s not the deal I’m talking about.

If you’re one of those folks that don’t really care about what the schedule might eventually hold and just want to reserve your spot for the conference, check out this (quite frankly, amazing) deal from the MTAers for next year’s TEK-X conference – sign up before January 6th, before the schedule is announced, and you’ll be rewarded with a 35% discount. That’s a full attendance pass for the whole week for a fraction of the cost – $650 USD. If you were planning on attending the conference anyway, it’s a win win.

There’s only one catch – there’s only 50 of these passes up for grabs so you’ll have to get in quick if you want to snag one, you’ll need to sign up quick. It’s an interesting idea from a group that’s always been keenly aware the pulse in the PHP community. Personally, I think it’s an excellent idea and only reinforces the fact that they know their target audience…PHP community members that are out there to support the community, regardless of the event. It’s nice to see a company putting so much stock in the community itself and not just in the appeal of the discount (not that it’s a bad thing!)
Improve Software Quality By Comparing Apples with Oranges

Posted: December 23rd, 2009, 4:38pm MST by Pádraic Brady

In the programming world, we often come across the phrase "comparing apples and oranges" as a figure of speech exposing the futility of comparing two unrelated sets of code which differ substantially whether due to programming language, intent or some other factor. For example, comparing Ruby On Rails to PHP is like this since ROR is a web application framework (not a programming language) and PHP is a programming language (not a web application framework). No matter how much some Rails folk wish otherwise so they can make PHP in general look like a Bad Idea (TM) for any serious web application without being compared to something more appropriate like Symfony or Zend Framework.

While the phrase appears to make sense, it's nonsensical in other ways. For example, two apparently different sets of code may yet share common functionality which can be compared. Ripping apart the analogy a bit, both types are fruit, both are round, both contain seeds, both are edible, both are covered in a skin, and both grow on trees. They are different yet share common characteristics.

The reason I bring this is up is because, as usual, I want to complain about something! Since many of us are actively involved in open source projects which may, to an extent, reinvent the wheel by writing libraries similar to existing ones, the principle of apples and oranges must not be applied. In fact we should apply the opposite principle. In this case, that principle is learning from the past.

The reason I bring this up is that PHP nearly always has a million libraries all duplicating the same functionality. Yet consistently they often ignore the alternatives they naturally complete with for mindshare. The outcome of this situation is that new libraries often replicate the mistakes of older libraries, not simply in terms of features offered, but more essentially in terms of the bugs, shortcomings and even security vulnerabilities of older or alternative libraries.

As historians might put it, if we ignore the mistakes of the past then we are forever doomed to repeat them.

On a grander scale, this is a cross programming language concern. Just because two languages like PHP and Python are different, it does not immediately follow that they behave different. A library in PHP that implements Protocol X probably behaves identically to a Python library for Protocol X. One such commonality across many programming languages is the regular expression. Whether you are writing a library in PHP, Python, Ruby or Perl - your regular expressions are likely operating on similar principles courtesy of the Perl Compatible Regular Expressions (PCRE) library. There are, of course, exceptions. For example Java uses a non-PCRE regular expression library, java.util.regex, though JRuby folk wrote a PCRE compatible replacement for their Ruby implementation.

Once this is made clear, you can begin see a picture emerging. Let's say you need a library to parse some defined data format. The data format is relatively simple so, in PHP, using regular expressions is likely a feasible means of implementing the parser. You write your library, it passes all unit tests, and you release it.

I'd now say I have a decent chance of locating bugs. Not because of thousands of hours of usage under some extreme conditions. But because, despite the unit testing and the attention to detail in parsing the data format in question, I seriously doubt anyone thought of researching the bug trackers and security vulnerability disclosures of identical libraries either in PHP itself or every other programming language.

These alternative sources of potential bugs and security vulnerabilities are a goldmine of information. Apples and oranges they might appear, but there are enough common threads (like PCRE) and obvious approaches to the problem of parsing the data format that in a very short time I can attempt to replicate Ruby bugs in the PHP library. It's liking having a set of potential shortcuts at your disposal!

This also applies within the same language. Take something as everyday as a template engine. On the face, each appears completely different. Beneath the surface most are probably parsing tags into a PHP form. Like the imaginary data format from earlier they have a common task - parsing something with regular expressions. At that level, one engine's bug in parsing tags represents a bug that potentially exists in all other templating engines of the same type. Why wait for a user to luck upon it when a historical bug report could shortcut you to a confirmation of whether you (or the other guy) made a similar mistake?

But why stop with libraries? The greatest beasts of them all are modern web application frameworks. Has anyone compared bugs reported for say Django with their potentially common workhorse equivelants in Symfony? Has anyone compared Ruby On Rail
Truncated by Planet PHP, read more at the original (another 1324 bytes)
Next magazine topic survey – winner announced

Posted: December 23rd, 2009, 8:20am MST by Michael Kimsal
A few weeks ago, I posted a survey asking for input on the next magazine topic for Web Dev Publishing to pursue. The results were interesting, but unfortunately the results were not definitive, and I’m left with the same quandry as before – which topic to choose.

The winner of the survey, selected at random, was Mark McDonnell. Congrats Mark, I’ll be sending your Amazon Gift Card over today.

The top vote getters were (in no particular order)
- MySQL
- NoSQL
- JVM Languages (jruby, jython, scala, clojure, etc)
- Zend Framework
- Database technologies
The votes were pretty evenly split between all of these topics, which leaves me with no clear direction as to which, if any, of these topics would make sense to pursue (from a demand standpoint). There already was a MySQL PDF magazine, which has transitioned in to a “open source database magazine”, covering more technologies than just MySQL. NoSQL, while interesting, has been criticized as just a ‘flavor of the month’ (though the interest shown in this survey was significant). Zend Framework and JVM Languages are the two that seem the most promising.

Do you have any thoughts on this?
Learning the path of dependency injection

Posted: December 23rd, 2009, 6:11am MST by Lukas Smith

We are currently in the process of updating our company internal framework okapi to use several of the symfony components. The service container component seems to be the one that poses the biggest challenges since there are several conceptual issues to address. As such I am looking for other implementations of the service container to see how things work there. I have posted this on the symfony-components mailinglist a while back, but got no reply (probably because the list wasn't really announced properly), so I am reposting this in my blog to reach a larger audience, but also to bring some attention to the components mailinglist. I guess most of my concerns are not really all that much about dependency injection but the service container approach that symfony provides to make dependency injection use a bit more convenient. We have managed to somewhat answer our questions, but some still remain open: Where to keep the SC instance? How to deal with shared instances that need to be reloaded? How to deal with Service container caching and auto regeneration?

1) Where to keep the SC instance?

First up we were unsure how to deal with optional dependencies and also how to deal with services that load other services. So the first approach that came to mind is that we basically inject the service container with everything. But that seemed ugly and magical. Upon further consideration it became clear that this wasnt needed at all. We now make an instance of the SC container inside the front controller and we pass it into the controller and store it there. Thats all.

There is now a syntax for optional dependencies (though still missing from the non 5.3 version last I checked). If a service really needs to load additional services (say for example various modules who's names are pulled out of the database during the request), then that service should simply create a new service container instance.

2) How to deal with shared instances that need to be reloaded

We have faced this situation in our unit testing framework. Since we are faking a request we need to effectively be able to reload a clean version with new parameters. Obviously we could add some method to do this cleanup, but it seems error prone and adding this feature seems trivial.

3) How to deal with Service container caching and auto regeneration?

We have run into a few issues when caching the service container config into a PHP file. For one there seem to be some issues in regards to handling of parameters. There is also the issue that if you want to automatically want to update the cache when underlying files have changed, that there is no easy way to find out which files were read (this is how symfony 1.3 works in development mode). For example an extension (aka plugin) could define a few services. These config files are bundled with the extension and therefore do not reside in the global configuration directory and imported inside the yaml files via the "imports" directive. Therefore its no sufficient to just scan that directory for the last updated file. Therefore we asked to get the list of files read during a call to load() so that we can cache this information for later reference when determining if the cached file needs to be updated.
Integrating Source Control Into Your Projects

Posted: December 23rd, 2009, 6:00am MST by Brandon Savage

If you ask most developers about source control, they’ll agree that it’s a wise thing to use. They’ll insist that they think it’s important. But yet, why are so many companies out there still not using source control in their projects? A good number of companies that I’ve worked with failed to make use of source control, resulting in issues that would have been trivial otherwise. In this article we’ll explore ways to make sure that if your company isn’t using source control, that you can help make a change to this policy.

Source control doesn’t need to come from the top
The first oft-considered misconception is that source control must be endorsed by upper management in order for developers to use it effectively. This is 100% incorrect. There are a number of ways that developers can make use of source control, even if management fails to embrace it, or rejects it altogether.

Subversion can be set up locally on most systems; a repository can be created in a central location and, as long as you do a regular backup, your repository should be secure. Git is designed to have the repository locally by default; this makes a great source control system if you have total ownership of the project.

Bear in mind that the point of version control is two-fold: first, to make it easy to collaborate with a larger group, and second, to help version your code so that you can see changes over time and possibly roll back if there are problems. Bear in mind that in larger teams, personal repositories won’t work, but in smaller teams or in places where you own your project, you can use source control.

The person that needs convincing is probably not the upper management at all
Many of my friends work for “creative firms” that are marketing first, development last. These firms are set up to provide excellent marketing to the clients, but more or less may not care about the development team. While this is often frustrating, it can also be a blessing in some ways.

As long as the team lead can be brought on board, placing code into a repository can be easy. If the team is larger than three or four people, using Subversion or another VCS is crucial; more likely than not there will be other owners of the project and everyone will need to collaborate.

The cool thing is that most of the time upper management types don’t care how the development is done as long as it is in fact done by the developers. Thus, convincing upper management isn’t the way to accomplish the goal of implementing version control.

Version control is not a silver bullet
A few times in my career I’ve heard someone say something along the lines of “oh, if only we had been able to use version control. Then that project would have been on time.” Bzzt! Wrong.

It might seem obvious that version control is not a silver bullet but it is often treated as such. It’s such an important and ubiquitous tool that it’s easy to think that having it will solve all development problems. But it’s not a replacement for good management, good time management skills, and solid development practices.

Version control should never be cited as a way to make development faster. It doesn’t generally do this (with the exception of generally preventing developers from accidentally overwriting someone else’s work, causing duplication of efforts).

Version control is best utilized before a crisis
Again, this might seem obvious, but there’s a harsh reality amongst developers: most of the time, when they feel as though they’re not permitted to implement version control, have a tendency to say “Well, next time code gets lost, that’ll teach ‘em.”

Don’t think like this! It’s just going to ultimately create more work for you, the developer, when the management wises up, realizes that they need version control, AND that they need the code rewritten that was ultimately lost. You’ll have double the work, and even though you’ll get what you want, you won’t like it.

Fight for version control consistently BEFORE a disaster. This will improve your chances of having it in place prior to some disaster striking.
Convert from and to OpenDocument

Posted: December 23rd, 2009, 5:19am MST by Tobias Schlitt

Yesterday the latest stable release of the eZ Components project, number 2009.2, was rolled. For this release I worked on support for OpenDocumentText (ODT) in the Document component. In this article I show you how you can import OpenDocumentText documents and convert them into any of the supported formats of the component, how to export data into ODT and how to apply styles to the generated documents. You will also see how ODT and PDF can be exported with the very same styling information to make them look almost identical.
Serendipity Upgrade to v 1.5.x Gotcha

Posted: December 23rd, 2009, 12:32am MST by Tobias Hauser & Christian Wenz

Just a quick note: I just updated Serendipity to version 1.5.1 on one of our servers; yet afterwards I could not log in anymore. Also, Serendipity reported that version 1.5.1 was present, although I did not run the update script from the admin console yet. At first I thought I did something wrong, but a s9y forum posting described a similar issue.

The fix was actually quite simple: for some reason—may it be due to my own fault or due to a bug in the upgrade logic—the SQL upgrade script was not run, but Serendipity still thought it had been upgraded already. The file sql/db_update_1.5-alpha1_1.5-alpha2_mysql.sql contains the required SQL commands (in case you are using MySQL). Just remember to replace {PREFIX} with the table prefix you are using (s9y_ in my case):

ALTER TABLE s9y_authors ADD COLUMN hashtype int(1); ALTER TABLE s9y_authors CHANGE password password VARCHAR(64) NOT NULL;

HTH. Once again, Happy Holidays.
OS/X WebDAV and Chunked Transfer Encoding

Posted: December 22nd, 2009, 10:35pm MST by Evert Pot

While OS/X's WebDAV implementation is quite slow, it is mostly pretty decent. The client uses the little used Chunked transfer encoding for PUT requests, which allows it to send big files without knowing exactly how big the file is going to be. A request like this looks like this:
PUT /image.png� [HTTP] Host: example.org User-Agent: WebDAVFS/1.8 (01808000) Darwin/10.2.0 (i386) Accept: */* X-Expected-Entity-Length: 10316 If: (<opaquelocktoken:44445502-c253-02e6-7198-45b36c96e8c7>) Connection: close Transfer-Encoding: Chunked
While this is a perfectly legal HTTP request, webservers choke on it. Both Nginx and Li [httpd] respond with HTTP 411 Length Required. This would have been valid for [HTTP] servers, but if they claim to support [HTTP] they must accept these requests.

Apache + mod_php does this fine, but just recently I got a report from someone using Apache + fastcgi + php. In this case the request body never arrived in PHP which can unfortunately result in silent data loss.

So I guess that's a bit of a warning, so far OS/X WebDAV only plays nicely with Apache + mod_php servers.
Learning new languages harmful?

Posted: December 22nd, 2009, 7:27am MST by Michael Kimsal

After having spent much time with Groovy/Java, and a bit with Ruby and a bit with C#, I have a newer perspective on learning new programming languages. Much of my thoughts are summed up by this post from Gustavo Duartes. I liked his choice of words at the top – “language dabbling” – which largely describes my C# and Ruby experience. I’ve done a little bit in them – some paid in C#, some not – but the bulk of my work is in PHP, with a small but growing bit in Grails.

It’s interesting to note his acceptance of “more than one”, but focusing on the “minimal required set”. We tend to think of languages as Java,C#, Python, etc., but competent web developers need to have a handle on SQL and JavaScript as well. Many also get into Flash/Flex/Silverlight too, and while CSS isn’t a *language* specifically, it’s something most web developers should be acquainted with. So, regardless of your serverside language of choice, there’s going to be 2-4 other technologies you need to be at least competent, if not proficient, with. This may be more the realm of small shop and independent developers – people working on larger teams or in companies with divided responsibilities may be able to get away without knowing any SQL or JavaScript, for example.

One of Gustavo’s points was that you lose momentum on your main language when you start dabbling with others. There may be a point there, but I suspect some people end up looking at other languages when they reach a plateau in one. That was certainly my point I reached with PHP. Having used it since early 1996, there’s only so much more I feel I can do with it. Yes, the language is evolving slowly, and I’m not keeping up with the ‘best practices’ of namespacing and such in 5.3, and I could probably architect my apps somewhat more strictly using some of the bigger frameworks out there. However, one of the things you end up learning when you look at other languages is where some of the defects are in your primary language. You may start to see the new ‘best practices’ as work-arounds in language deficiencies.

It’s easy to point at PHP and talk about how “it sucks” and all that, but I’ve had experiences with some friends who’ve moved from Java over to PHP. While this was a somewhat unwelcome move at first, given PHP’s reputation amongst the ‘enterprise crowd’, at least one of my friends is really enjoying being able to be much more productive – more functionality in fewer lines of code – and rethinking some of his approaches to web development. Moving from any statically typed language to a dynamic one is certainly a shift for people to make (and the reverse movement is true as well!), and rethinking those problems we’ve taken for granted can be a real eye-opener.

In the short term, yes, it’s a productivity loss, as Gustavo points out. In the longer term, it can really provide you with many more tools in your toolkit for attacking new problems.

One caveat I’ve noticed to this is the old saying “choose the right tool for the job.”. Great in spirit, but my experiences have borne out that rarely is the definition of “right” able to be agreed on. ”Right” for who? The DBA? The sysadmin? The developers? I had a project I’d recently prototyped in Grails (after an initial first pass prototype in PHP 6 months earlier). The Grails environment allowed for much more rapid prototyping and modeling of data, relationships, screens, and so forth. However, when it came time to accept it, I was told we could *only* build the app on a traditional LAMP stack (I was looking forward to using PostgreSQL on this project as well). Why? Because the limited system administration staff didn’t have the time to learn new skills to manage the new technology choices.

While initially I was bummed out, I can understand the decision making process. I was able to take the db tables from Grails and wrap another PHP ORM layer around them so I didn’t lose all my work, but it certainly put to rest the maxim “right tool for the job.” Who gets to decide?

So, even if you learn new languages and technology, you might not always be able to use the most appropriate tool from a pure technology/productivity standpoint. And sometimes knowing that there are better options out there that you *can’t* use for various reasons adds a level of frustration to the mix that you wouldn’t have. Perhaps we should all stick to just knowing one language and one language only, right? :)
Object-relational mapping with Doctrine, Flash Builder, and PHP

Posted: December 22nd, 2009, 7:10am MST by Zend Developer Zone

Rich Internet applications built with Adobe Flex and Flash Builder have been steadily gaining a foothold in enterprise development for quite some time. As the platform has grown and evolved, PHP has also made amazing progress toward becoming a mature, powerful object-oriented language with rapid adoption and dozens of frameworks and design pattern implementations. As PHP continues to prosper, developers are able to borrow more and more of the things Java has got right, taking one check after another from the “Java-only” column. One outstanding example of this is object-relational mapping ( ORM ). A few different PHP ORM implementations are available, and all of them have positive attributes. However, after some experimentation, I’ve found that Doctrine is my favorite.
Free weather icons

Posted: December 22nd, 2009, 2:59am MST by Danne Lundqvist

The Norwegian weather service Yr.no is very popular in the Nordic region as they release weather data for free. We (as in the Swedish web development company Dotvoid AB) have used their service to create mashups and services as many others have before us.

Recently Malin Holm converted all our old bitmapped weather icons to SVG and we decided to release two png versions (60×50 and 120×100) licensed under the Creative Commons Attribution No Derivative 3.0 Unported License. All icons are named after the weather codes used by Yr.no but can of course be used for other data.

Download the full weather icon set at the Dotvoid AB icon page.
Weather icons
PHP in Odd Places

Posted: December 21st, 2009, 10:00pm MST by PHP Advent
PHP has traditionally been used to solve web problems, and for this, it excels. Over the past year and a half, I have been doing some unusual things with PHP in a completely new environment, my phone. In this article, I will explain the perils I encountered while exploring the technical depths of making apps for mobile platforms.
The Phone
My phone — an OpenMoko — consists of open hardware and runs Linux. The phone is just a normal ARM platform; you can even install Debian if you are so inclined. Most of the GUI software is written in PyGTK, although they are moving away from that. The phone’s software is rather unstable and not very user friendly, but because it is a completely open platform, you can run anything you want, including PHP. I set out to see whether it was viable to write my own apps for the phone and turn it into a phone that I can use on a daily basis without problems.
PHP
The first task was to get PHP compiling on the phone. The fastest way to compile something for an embedded device is to use a cross compiler — a compiler running on one platform (usually Linux i386) compiling for a different platform, in my case Linux ARM.

With a complicated cross compiler setup, I managed to get PHP compiled, but extensions were awkward, because PHP’s configure system doesn’t support cross compiling. So, I resorted to compiling extensions on the phone itself.

Compiling on the phone opened a whole new can of worms. Although the phone comes with a compiler, almost none of the other tools for building are available. Tools such as Automake, Libtool, and other compiling and linking tools were either not working or broken.

I also learned that compiling on the phone is very slow. There’s not a lot of memory, and the SD card reading speed isn’t great. It took 3 hours to compile PHP 5.2.6 on the phone, and to achieve this, I had to modify the makefile, because some C files — the PHP language parser and ext/date’s string-to-time parser — require so much memory when optimization levels are enabled that the device runs out of memory. The only solution is to turn off optimizations for those files.

Once PHP is compiled, its performance is quite reasonable for a 400 MHz processor. The result:
```
php -i | head -n 4
phpinfo()
PHP Version => 5.2.6

System => Linux om-gta02 2.6.29-rc3 #1 PREEMPT Sun Aug 2 12:17:54 CEST 2009 armv4tl
```
PHP-GTK
Although the OpenMoko has a terminal, using PHP on the command line is not very convenient due to the small size of the on-screen keyboard. The predictive view of the keyboard is good, but the terminal and number views are limited in usability and size, so in order to do something useful with the phone, a GUI toolkit is a must. PHP’s only really workable toolkit is PHP-GTK; luckily, the OpenMoko already has all the GTK libraries available. Compiling PHP-GTK for the phone was a bit tricky, but three hours later, I had a working PHP-GTK extension:
```
php-gtk

GTK+ support => enabled
GTK+ v => 2.14.2
```
In order to enable UTF-8 support, I had to set php-gtk.codepage to UTF-8.

My next obstacle was to actually figure out how to use PHP-GTK. Although I have been working with PHP for ages, PHP-GTK was unfamiliar. It’s event-driven, so things are triggered when you click something. PHP-GTK’s approach to interface design also created some obstacles.

After dabbling with some test interfaces and simple apps, I found that PHP-GTK apps were actually faster than similar PyGTK apps.
Interface
Because the phone’s touch screen is the only interface, you need to pay special attention to the size and placement of buttons, else it’s hard to avoid pressing the wrong one. It’s not a problem when you tap the wrong key on the keyboard, but it is when you accidentally tap a submit button instead of a delete button. It’s best to create buttons that are plenty large and place dangerous buttons away from the others. Asking for confirmation can also help users avoid disaster.

Although the predictive keyboard on the phone is pretty good, it is not nearly as fast as my old Nokia’s T9 system. Just for fun, I implemented T9 as a GTK window. There are still a few issues — like the order of letters on the “
Truncated by Planet PHP, read more at the original (another 11378 bytes)
Zend Framework 1.10.0alpha1 Released

Posted: December 21st, 2009, 3:09pm MST by Zend Developer Zone

For those of you monitoring the Zend Framework SVN the last few weeks, you will likely have noticed a huge surge of activity as contributors have scrambled to complete code in time for the 1.10.0 release. The release is getting close, and I'm happy to announce an ALPHA release of 1.10.0. [framework.zend.com] Please note that the alpha is only available on the ZF site, not from the zend.com CDN.
PHP Advent 2009: GeoIP Wrangling

Posted: December 21st, 2009, 2:39pm MST by Andrei Zmievski

There have been a few kind words and questions about the GeoIP-based blurb that greets the visitors to our Analog holding page, so I wanted to blog about how it was made and what obstacles I ran into. However, while writing I realized that it would be the perfect candidate for this year’s edition of PHP Advent instead of the article I originally planned to write about Git and Github. So head on over and read about GeoIP Wrangling and feel free to leave your comments here.
Protected: 1500 Lines of Code (@phpadvent Draft)

Posted: December 21st, 2009, 11:12am MST by Terry Chay

This post is password protected. To view it please enter your password below:

Password:
PHP-Center got a new home - time to say good bye

Posted: December 21st, 2009, 4:58am MST by ThinkPHP /dev/blog - PHP

Together with Ralf Geschke (and Tobias Ratschiller), we created PHP-Center.de as a home for the German-speaking PHP community back in 1998. Back then, PHP-Center was also the host of the German speaking PHP mailing list (GML) which was founded by Ralf and PHP-Center was the complementary web site that contained news, articles, case studies and a job board for German speaking PHP enthusiasts. Some years later, the mailing list switched to phpbar.de and I continued with PHP-Center.de as a solo project.

Have a look at web.archive.org how PHP-Center was back then: the 1999 pages, 2002 and PHP-Center in 2004

In the last years, we didn't have much time to dedicate for this project and decided we want to give PHP-Center (at least the domains) a new heritage. For this, we found a new host for the domains: Software & Support media who already care for the German PHP Magazin and the International PHP Conference.

I would like to thank a lot of people for their work in the last 12 years: Ralf Geschke, Tobias Ratschiller, Sebastian Bergmann, Christopher Kunz, Markus Wolff, Thiemo Mättig and countless others (especially those mailing list subscribers). You've made PHP-Center.de the No. 1 ressource for German PHP developers in the past decade and I hope Software & Support will continue the journey with its content.
The state of YAML in PHP

Posted: December 21st, 2009, 12:20am MST by Fabien Potencier
My first exposure to YAML was in 2001, back in the days when I was mainly working with Perl. Well, I was not using YAML per se at that time, but rather Data::Denter, a Perl library that provides data serialization/deserialization. I used this library mainly for debugging purposes. From its documentation:

"It formats nested data structures in an indented fashion. It is optimized for human readability/editability, safe deserialization, and (eventually) speed."

At the end of the year 2002, the module was deprecated in favor of a new serialization language, YAML, with the added bonus of being programming language independent. I promptly switched to use the Perl YAML module, and I never looked back. I used YAML as a mean to debug my Perl programs, but I also started to use it more and more to store configuration data.

When I started to use PHP at the end of 2004, one of the first thing that quickly bothered me was the poor support for YAML in the PHP world.

By the way, if symfony uses YAML a lot, it has nothing to do with Ruby on Rails ;) It just happens that Ruby also has some Perl heritage!

But first, what is YAML?
According to the official YAML website, YAML (YAML Ain't Markup Language), is a human friendly data serialization standard for all programming languages.

YAML can be used to describe both simple and complex data structures. It's an easy to learn language that describes data. As PHP, it has a syntax for simple types like strings, booleans, floats, integers, arrays, and even more complex ones like objects.

Nowadays, YAML is a heavily used format for configuration files, mainly because even non programmers are able to understand and modify YAML files easily.

To sum up the benefits of YAML, I often say that YAML files are as expressive as XML files and as readable as INI files.

Since the creation of YAML, another lightweight data-interchange format has come to life: JSON. JSON is quite similar to YAML (and as a matter of fact, JSON is a subset of YAML); but even if it is easy for humans to read and write, I think it is not as readable as YAML, and a bit too verbose.

YAML
If you already know what is YAML and how to use it to describe your data structures, just skip this section.

Besides strings, Booleans, and numbers, let's have a look at one of the simplest configuration structure you can describe with YAML:
```
key: value
foo: bar
 
```
The above snippet is the simplest way to express key/value pairs in YAML. The foo key has a bar value. The equivalent PHP code would be:
```
array('key' => 'value', 'foo' => 'bar')
 
```
And that's pretty much covers what you can do with ini files. Speaking of ini files, you can also group key/values under "sections". Here is how this is possible with YAML:
```
section1:
  foo: bar
 
section2:
  bar: foo
 
```
The equivalent PHP code reads as follows:
```
array(
  'section1' => array('foo' => 'bar'),
  'section2' => array('bar' => 'foo'),
)
 
```
That does the trick because there is several ways to describe key/value pairs. The short notation (foo: bar), and the expanded one, where you use indentation to describe nested structures as above.

The same data structure can also be described as follows:
```
section1: { foo: bar }
section2: { bar: foo }
 
```
The {} is how you enclose a hash. That's one of the greatest benefit of YAML as a description format: you can visually organize yo
Truncated by Planet PHP, read more at the original (another 7619 bytes)
GeoIP Wrangling

Posted: December 20th, 2009, 10:00pm MST by PHP Advent

When making the Analog holding page, we wanted to add a touch of personality to make the experience warmer and more welcoming. One of our ideas was to use IP-based geolocation to create a personalized greeting based on each visitor’s location. The task of making this fell to me, and I wanted to share some tidbits about the implementation and what I discovered along the way.

The source I used for GeoIP data was MaxMind. This company has maintained a comprehensive IP-to-location database for a while, and it offers a number of different versions, some of which are free. The GeoCity database, unfortunately, was “available to established businesses only” and cost $370 per site license, so I decided to go with the free — and less accurate — alternative, GeoLite City.

MaxMind advertises GeoLite City as having the accuracy of “over 99.5% on a country level and 79% on a city level for the US within a 25-mile radius.” What this means is that in the US, 18% of the IPs are resolved inaccurately — more than 25 miles from the true location — and 3% are not covered. For the UK, the numbers are worse; 37% of IPs are resolved inaccurately, and 9% are not covered. I experienced this inaccuracy firsthand after Jon Gibbins’s location was determined to be in London, even though he lives in Barnstaple, about 100 miles away. Surprisingly, less developed countries sometimes have better coverage. In Kazakhstan, for example, only 15% of the IPs are resolved inaccurately, and a mere 1% are not covered. To channel Borat, “much success!”

Regardless, this was “good enough.” The next step was to decide how to handle the data. GeoLite City is available in binary and CSV formats. Using the CSV version requires importing it into some sort of database and performing IP range queries, and this is something I wanted to avoid, both for speed of development and to save memory on the server. The binary version has to be used with the libgeoip library provided by MaxMind. Thankfully, there was already a PHP extension in PECL for this library, complete with documentation. My only concern was performance, because the binary IP data file was 28 MB, and reading it from disk every time would quickly become prohibitive. After perusing the libgeoip source code, I discovered that it supports shared memory caching via mmap(), but the GeoIP extension wasn’t making use of this. So, I patched the extension and built a custom version.

The data provided by GeoLite City contains country, region, area code, metro code, city, and postal code. The region indicates the state (in the US) or the province (in Canada). For other countries, the region is a two-letter code derived from the FIPS 10-4 standard, used by such publications as the CIA’s World Factbook. For example, certain parts of London, UK, will have the region H9. I decided to avoid using the regions outside of the US and Canada, because they don’t necessarily correspond to known geographical boundaries. Imagine greeting someone, “It looks like you're in or near London, H9.” That wouldn’t exactly have the human touch I wanted.

The data also contains the latitude and longitude of the approximate location, and this is what I used for the distance calculations. The easiest way to calculate the distance between two points is via the spherical law of cosines, a well-known formula that gives the distance along the great circle between the points. Just to be sure, I looked up a couple of other formulas. The haversine formula used to be preferred when computational precision was limited, but the simpler cosine one gives good results, even for distances as small as 1 meter. And, although it presumes the Earth is a sphere — it’s not really, of course, varying from 6,378 km at the equator to 6,357 km at the poles — the accuracy is still better than 3 m in 1 km. In other words, good enough. If more precision is needed, Vincenty’s formulae can be used instead.

With distance calculati
Truncated by Planet PHP, read more at the original (another 7515 bytes)
Unmaintainable PHP

Posted: December 19th, 2009, 10:00pm MST by PHP Advent
With the recent unemployment rates, everybody realizes that job security is important. The best way to keep a job is to be irreplaceable. If no one can maintain the code you write, you have a job for life. Writing unmaintainable code is a special skill that seems to come quite naturally to certain developers. For the rest of you, here are some tips and tricks to get you started.
First things first
It all starts with the job posting. You should look for the right company, where you can spread your wings and achieve your unmaintainable potential. You don’t necessarily need to be the PHP guru in the company, but it sure helps. Look for job descriptions that mention migrating to PHP from something else, so you know you’ll be calling the shots. Or, search for misguided jobs posts that require 10 years of PHP 5 experience, plus fluency in FrontPage and Netscape Composer.

Once you land the golden opportunity, be vocal from day one. Speak up at meetings; let your opinion be heard. Talk about object-oriented design architectures, enterprise, shifting paradigms, how “good enough” is not good enough, and, of course, your personal commitment to excellence. Make sure everyone consults your opinion on the important initiatives.
The pillars of unmaintainability
Inspired by the most excellent unmaintainable code — a must-read for anyone interested in keeping their job — here are two important concepts you need to grasp and master:
1. Make it impossible for someone to easily change something without breaking something else. The maintainer doesn’t have time to understand your code. Maintainable code means being able to quickly find something, understand how it works, and change it without breaking stuff. You can’t have that. No one should be able to simply search for something and find it where they expect.
2. Your code shouldn’t look unmaintainable, because someone will suspect something. It just has to be unmaintainable. The code should look normal to the poor souls maintaining it, but take them by surprise when they least expect it.
Best practices
1. Ban coding conventions. Endless flamewars have been fought over coding and naming conventions. You can’t have that in your fine organization. You have awesome projects to build, and you can’t afford to spend countless hours in discussion of tabs versus spaces. Plus, conventions are restrictive. If new hires are not used to your conventions, they’ll be miserable. Unhappy programmers are unproductive programmers; explain that to anyone who asks. Let everybody write in their favorite style du jour. As for your own code, rotate your conventions. Go camelCase on Mondays, all_lowercase on Tuesdays, mix-and-match on Fridays, and Hungarian on every February 29th.
2. No comments. Your code is beautiful; it doesn’t need comments. If someone can’t understand it, maybe they are not so good after all. If, by any chance, you’re forced to write comments, then simply overdo it. Elaborately describe the most obvious and trivial code, and skip the rest.
```
// In the following block,
// we add two variables,
// variable a and variable b.
// Both of them are integers.

// Declare variable a,
// and assign it the value 1.
$a = 1;

// Now, declare variable b,
// and assign it the value 2.
$b = 2;

// Add the two variables, a and b,
// declared and initialized above,
// and assign the result to variable c.
$c = $a + $b;
    
```
3. Standardize on Notepad. Let the others suffer and eventually leave the team. You don’t need to listen to them complaining all the time. And, if someone asks why Notepad is the standard, be ready to explain. It comes with Windows — the only OS for today’s productive programmer — and it doesn’t cost anything. I’m sure you’ll find references on the Web that explain how you can use any editor, including Word, to write code for web pages, but Notepad is for real gurus. And, after all, your company hires only gurus.
4. No unit testing. Explain to anyone who asks that you are hired to write high-quality code that doesn’t have bugs, ergo it needs no testing. (A bit of Latin always makes you sound smarter.) Why would anyone in their right mind spend any time writing useless tests that confirm the obvious, that the code works? Some things in life just are — the sky is blue, the sun rises from the East, and your code works, thank you very much. Move on. (Like with comme
Truncated by Planet PHP, read more at the original (another 6472 bytes)
Trying a Two Step PEAR/PHAR approach to develop and deploy

Posted: December 19th, 2009, 10:03am MST by Benjamin Eberlei
With PHP 5.3 the PHAR extension is a pretty powerful concept for all your deployment needs, however it does not tell the complete story. Frameworks, Libraries and many different of them are used throughout applications and in recent times people even began to chery-pick the best components from each of the frameworks and package them together. With Pirum being a simple PEAR channel server there is also momentum for projects to distribute their code via PEAR.

However PEAR is mostly used in the server-wide configuration use-case, which is not very useful if you plan to distribute your complete application in one PHAR file. I just recently had the idea for this scenario, so please bear with me and add all the feedback and comments you can come up with. I tested this with the ongoing rewrite of my blog software.

First we'll add a new user that we develop our application with:
```
sudo useradd -m -g www-data whitewashing
sudo passwd whitewashing
su - whitewashing
```
Now there is the possibility that with this user PHP and PEAR is not in your $PATH enviroment, so you might have to add it. In my case on Ubuntu i also had to switch the console from /bin/sh to /bin/bash for this user. Then we need to setup our application, I am going to use the Zend Framework project style here but with a little twist. We will add a distinction between vendor and project libraries by adding a vendor directory into the main folder.

But first we create a folder for our application, and create a Zend Framework project in the subfolder "trunk", which will be the focus of our development.
```
whitewashing@desktop:~$ mkdir whitewashing
whitewashing@desktop:~$ zf create project whitewashing/trunk
Creating project at /home/whitewashing/whitewashing/trunk
whitewashing@desktop:~$ mkdir whitewashing/trunk/vendor
```
Now we can configure an Apache virtual host to point to our /home/whitewashing/whitewashing/public directory, i call this "whitewashing-dev" add it to my /etc/hosts and can visit the dummy project page.

We then configure our PEAR installation for the specific application user and re-configure the bin and php library paths:
```
whitewashing@desktop:~$ pear create-config /home/whitewashing/ .pearrc
whitewashing@desktop:~$ pear config-set php_dir /home/whitewashing/whitewashing/trunk/vendor
whitewashing@desktop:~$ pear config-set bin_dir /home/whitewashing/whitewashing/trunk/bin
```
This configuration assumes that we will install all our stuff into our development trunk. From there also the PEAR installed libraries might be copied into branches or tags. PEAR Project tests, configuration and web-files will still be put by default under $HOME/pear/*. We don't need them for our applications.

Now we install all the dependencies our project needs, in this case Zend Framework, Doctrine 2, html Purifier:
```
whitewashing@desktop:~$ pear channel-discover pear.zfcampus.org
whitewashing@desktop:~$ pear install zfcampus/zf-alpha
whitewashing@desktop:~$ pear channel-discover htmlpurifier.org
whitewashing@desktop:~$ pear install hp/htmlPurifier
whitewashing@desktop:~$ pear channel-discover pear.phpdoctrine.org
whitewashing@desktop:~$ pear install pear.phpdoctrine.org/DoctrineORM-2.0.0
```
Now we have all three of the packages installed in our project folder whitewashing/trunk/vendor, see:
```
whitewashing@desktop:~$ ls -aFl whitewashing/trunk/vendor/
total 680
drwxr-xr-x  7 whitewashing www-data   4096 2009-12-13 14:45 ./
drwxr-xr-x  8 whitewashing www-data   4096 2009-12-13 14:36 ../
drwxr-xr-x  3 whitewashing www-data   4096 2009-12-13 14:43 .channels/
-rw-r--r--  1 whitewashing www-data     57 2009-12-13 14:45 .depdb
-rw-r--r--  1 whitewashing www-data      0 2009-12-13 14:45 .depdblock
drwxr-xr-x  5 whitewashing www-data   4096 2009-12-13 14:45 Doctrine/
-rw-r--r--  1 whitewashing www-data 582208 2009-12-13 14:45 .filemap
drwxr-xr-x 20 whitewashing www-data   4096 2009-12-13 14:39 htmlPurifier/
-rw-r--r--  1 whitewashing www-data    629 2009-12-13 14:39 htmlPurifier.autoload.php
-rw-r--r--  1 whitewashing www-data    274 2009-12-13 14:39 htmlPurifier.auto.php
-rw-r--r--  1 whitewashing www-data    545 2009-12-13 14:39 htmlPurifier.func.php
-rw-r--r--  1 whitewashing www-data   9299 2009-12-13 14:39 htmlPurifier.includes.php
-rw-r--r--  1 whitewashing www-data    955 2009-12-13 14:39 htmlPurifier.kses.php
-rw-r--r--  1 whitewashing www-data   8831 2009-12-13 14:39 htmlPurifier.php
-rw-r--r--  1 whitewashing www-data  11901 2009-12-13 14:39 htmlPurifier.safe-includes.php
-rw-r--r--  1 whitewashing www-data      0 2009-12-13 14:45 .lock
drwxr-xr-x  8 whitewashing www-data   4096 2009-12-13 14:43 .registry/
drwxr-xr-x 59 whitewashing www-data   4096 2009-12-13 14:36 Z
```
Truncated by Planet PHP, read more at the original (another 6236 bytes)
Performance for Web Apps

Posted: December 18th, 2009, 10:00pm MST by PHP Advent

When it comes to programming, there are two things that I enjoy doing the most: making things faster and improving security. The two sometimes come into conflict, because security often requires validation overhead, and performance often leads to cutting corners. Balancing the two is often loads of “fun.”

That said, when it comes to security, things are relatively straightforward. Filter your input, escape your output, and don’t trust your users. On the performance side, things are not nearly as straightforward, especially when it comes to web apps.

The basic approach is fairly simple; just profile your app, determine the slow areas, optimize them, and voila, things are faster. Alas, even when this approach is followed, the results don’t necessarily eliminate the “your site is slow” feedback.
Browser bottleneck
For any app, the measure of speed is ultimately all about user perception. In a traditional environment where binaries are deployed on a user’s machine, you control the app, so optimizing the interaction is part of the optimization process. If a report screen takes too long to load, your profiling efforts will identify that, and you speed up the rendering function.

For web apps, things are a little different, because the UI is controlled by a web browser — a 3^rd party app that you have no control over — and it is responsible for rendering your data for your users. Even if you output your content in one hundredth of a second, by the time the content is downloaded, parsed, executed, and rendered, a few seconds may have passed, and the user experience is diminished. This is something most web app optimization attempts miss, since they focus almost exclusively on how quickly content is generated.

In fact, for web apps, it is often better to start your optimization efforts from the user side of things rather than the server.
Making things better
Making the user experience better — and by better I mean faster — is not too complicated.

As with any optimization, the first step is to understand the nature of the problem. Good tools include Firebug for Firefox or Google Chrome. Using either, you can understand how big a page is, what additional resources (CSS, JavaScript, images, &c.) it loads — in what order and how quickly. This will give you a base to work with and identify areas of greatest interest. What follows are some easy improvements, ordered by ease of implementation.
Load time optimizations
Enable compression using something like mod_gzip. It’ll speed up page loading by significantly reducing the size of text content. Send caching headers (Expires, Last-Modified, ETag, &c.) for static content (images, CSS, JavaScript, &c.) to reduce redundant requests. Optimize images; in most cases, you can reduce the size of images by up to 30% with non-visible, lossy compression, color reductions, and the like. Compress JavaScript using tools such as JSMin, and compress CSS using YUI Compressor.
Check your cookies
While broadband connections can download hundreds of kilobytes per second, uploading is another matter entirely; most DSL and cable connections can only upload 20 to 30 kilobytes per second. If your page contains 10 resources, and the size of all the cookies is a mere 1 kilobyte, sending the requests alone can still take over half a second. Keep in mind there are also 400 to 500 bytes of headers per request. Therefore, it is important that you reduce your cookie sizes to just the session identifier. A slightly more complex solution is to move your static content to another domain, so your cookies are only sent to the pages that need them instead of all of the static resources as well.
Reduce request count
Merge your images; rather then sending a dozen 1 kilobyte images, combine them into a single image, and use CSS to show parts of the image. If you are loading more than 2 JavaScript or CSS files per page, considering merging them into a single file. This will makes things faster, but don’t merge too much, otherwise you’ll introduce parsing overhead.
Improve JavaScript loading
After you’ve merged your common JavaScript code into a single file, you may still have other JavaScript files that you load in the specific pages that need them. Unfortunately, browsers don’t load JavaScript files in parallel like they do with images. To prevent dependency breakage, most browsers load sequentially. If you hav
Truncated by Planet PHP, read more at the original (another 649 bytes)
Search for photos using PHP and the flickr API

Posted: December 18th, 2009, 3:25pm MST by Web Development Blog Â» PHP scripts
This PHP tutorial will show how to create a simple PHP class to search the flickr site for some photos. To get the data we use the flickr API to run a simple search and return the results in a serialized array.

We will be using the php function "file_get_contents" to receive data from flickr. The data which we will receive will be a serialized PHP array which means all we need to do is unserialize the array and we will easily be able to use the data returned. As an alternative we can use a cURL function to get the data, for example if the function "file_get_contents" is not allowed on your web host.
API Authentication
The API methods we use in this tutorial doesn’t require any authentication, but we need to use an API key. Get your API key on the flickr web application site (You need an Yahoo account to login).

Provide some information about your application:

and obtain your personal flickr API key and secret (We need only the key in this tutorial)

Flickr PHP Class
First we create the class structure for our class, we define a private variable for the "API key", a class constructor and the function that will search later for the images.
```
class Flickr { 
	private $apiKey = 'YOUR API KEY HERE'; 
 
	public function __construct() {
	} 
 
	public function search($query = null) { 
	} 
}
```
The API method we will be using is "flickr.photos.search", which has a number of possible parameters. We are able to search by tags, full text, tell the API which user to search for, the minimum date it a photo was uploaded and many more. You can find a list of the parameters in the flickr documentation.

So we’re going to run a full text search and limit the number of results to 50.
```
 
	public function search($query = null) { 
		$search = 'http://flickr.com/services/rest/?method=flickr.photos.search&api_key=' .
```
Truncated by Planet PHP, read more at the original (another 8299 bytes)
Say Hello to Analog

Posted: December 18th, 2009, 2:41pm MST by Andrei Zmievski

Wow.

That pretty much sums up my feelings about the response to the announcement of Analog, a web design and development co-operative that I started with a few of my friends. I am stunned and humbled by the many kind words of congratulations, praise, and encouragement that we received about our launch via Twitter, Facebook, and personal communication. Thank you. Many have been wondering what I’ve been up to since leaving Digg in early September, and organizing and setting up Analog has been a big part of it.

The first time I discussed the idea for such a company was when Chris Shiflett and I went to Iceland in June. During that time of renewal, reset, and inspiration, we talked about our desire to work on interesting projects with a great team of peers. People like Jon and Jon, who Chris had worked with on a few occasions. From the start, we wanted to be a bona fide co-operative: an organization owned and operated by a group of individuals for their mutual benefit and adhering to the principles of equality and equitability.

Co-operatives, especially tech ones, aren’t very common — though they are much more prevalent across the pond in the UK — so it took us a while to work out the legal and tax issues of having an equitable company comprised of people from multiple countries. This time was also spent refining our brand identity and brand promise, both of which we believe strongly in. We also needed a short statement to explain who we are and what we do, and in the end it became this (the last part of which harkens back to our original motivation):

Analog is a company of friends who make web sites. It’s a co-operative where imagination, design, and engineering thrive; good people doing good work.

The part about “making web sites” may sound simplistic, but we believe in taking back simple, honest phrases like web site and web developer. They are precise and descriptive despite having been shunned or dismissed by people in favor of things like web application, front-end/back-end engineer, and other seemingly sexier nomenclature meant to sound more important. It’s time to call things what they are. Say it with me, “I am proud to be a web developer.”

Of course, the most difficult thing to decide on was the name. We had a lot more latitude within the .coop top-level domain (TLD), but even then, we must have gone through a hundred or more names looking for one that would somehow reflect our philosophy while being memorable. The flash of inspiration struck while imbibing the potent Bee Sting cider at the inimitable Duke of York in Bristol. The name had an instant appeal, and I imagine we all thought, “Yes, Analog is it.” Jon Tan even left a mark on the table, since he couldn’t wait to see what Analog would look like in type.

Analog appealed to us because of its association with handmade things, craftsmanship, and a “warmer” feeling in general. Somehow it felt good to think that we were going to do digital things the analog way, where a personal touch of each of us would be evident in our work and communication.

The team at Analog is one of the best that I’ve had the honor to be a part of. Alan Colville is an accomplished UX designer and customer experience and usability researcher. He has helped a number of clients in the past, including Vodafone, Virgin Media, BlackBerry, and Visa. Chris Shiflett has extensive background in web development, specializing in web security, and has worked on projects for Ning, National Geographic, Digg, and many other clients during his time as principal of Brain Bulb and OmniTI. Jon Gibbins is an ace developer and web accessibility expert who most recently lent his skills to OmniTI as well. And Jon Tan is simply the best designer and typography maven that I have a pleasure to know, with an extensive body of published work.
Truncated by Planet PHP, read more at the original (another 1934 bytes)
Goodbye, OmniTI

Posted: December 18th, 2009, 8:08am MST by Sean Coates

Today is my last day at OmniTI. From an email I just sent out to my soon-to-be-past colleagues:
I sincerely wish you continued success as a company, and also as individuals who truly make up a significant portion of the best people in this industry. There are many things that OmniTI does very well, and I won't hesitate to refer business your way when the situation arises.

This past year and a half (or so) has been a bumpy road, but I'm absolutely sure I will look back on my time with OmniTI as a net-positive. Thank you all for supporting me and my team with our sometimes-(absurd | stupid | obvious | amateur | tough) questions and requests.
The road ahead for OmniTI doesn't look nearly as bumpy, but after a very long period of thought, I finally decided to pursue other options around 6 weeks ago, and will now join the ranks of the funemployed. Thanks for the opportunities, experience, insight, and tough problems, OmniTI. 2010 will be a great year. I'm already excited about some of the prospects that are in my future. Bonus points if the title of this post seems familiar. (-:
Tweet tweet a year …

Posted: December 18th, 2009, 6:29am MST by Tobias Schlitt

So, it's exactly one year ago that I started using Twitter. I remember that I was always of the opinion that Twitter is one of the most stupid hypes nowadays and that it's so useless to know when other people have a cup of coffee or go to the toilette. Using Twitter actively for exactly one year now proofed this attitude wrong. I'm providing some stats on my live with Twitter in this article and try to explain my personal value of using Twitter in.
PHP Advent 2009

Posted: December 17th, 2009, 10:34pm MST by Ben Ramsey

Six years ago, I became aware of the PHP community. I joined it three years prior to that.

I’m privileged to be a part of the 2009 edition of PHP Advent. This year, my post is about the PHP community. If you have any comments, feel free to leave them here.
You Don’t Need All That

Posted: December 17th, 2009, 10:00pm MST by PHP Advent
I’ve been writing PHP for a long time. I am not one of its dinosaurs, but I’ve been making it do my bidding since PHP 3. I have also seen a lot of trends come and go. As an example, PHP 4 was all the rage for optimizing with references. PHP 3 still had some parts that were so poorly written, it was possible to get 20% performance increases just by changing the way you did something. PHP 5 is obviously trending with object-oriented programming.

Speaking of object-oriented programming, we know the standard drill. A cornucopia of MVC frameworks have rained down on us — some of which actually follow an MVC pattern — and have inundated us thoroughly with the standard request workflow:
1. The web server initiates the bootstrap.
2. The bootstrap initiates the front controller.
3. The front controller initiates the controller method.
4. The controller uses the model.
5. The controller prepares view data.
6. The controller instantiates the view and provides the data.
7. The request completes.
Et cetera, et cetera, ad infinitum. Mind you, this isn’t a bad workflow at all. We have a nice, clear separation of concerns. We always know where to look. It’s great, right?

Well, the idea is great. Allow me to share something I did the other day. I decided that I would benchmark the difference between traditional, hard require statements, and a clean autoloader. Bah! Micro-optimization, right? Well, I beg you to humor me.

I set up a PHP benchmarking environment with an old server, and I wrote a small set of scripts to generate the following components:
- A directory with 100 class files. These classes are simple blanks in the form of class MyClass {}. The actual content of the class wasn’t relevant to what I wanted to benchmark.
- A script that performs a hard require statement for each of the 100 classes and then instantiates them: require './classes/MyClass.php'; $myclass = new MyClass();
- A script that implements a very simple autoloader, registers it, and then instantiates one of each of the 100 classes.
I tried to think of how to introduce as little bias into my benchmark as possible, and I came to the conclusion that I would run the benchmarks against a stock Ubuntu LAMP installation with a concurrency of 1. This seemed fairest, since it’s a close approximation to what what is provided by many hosting providers. The PHP version was 5.2.9. The test is slightly unrealistic, because an app using hard require statements and multiple entry points would not load 100 different files to perform any given task. You would do tend to bundle things a bit more neatly. However, these files would usually contain some wasted code not used by every request. I figured the balance was fair, and I was satisfied with that. The point is to test how far apart require and an autoloader are, not to test the efficiency of your code organization.

I benchmarked the script with hard require statement and the script with the autoloader by using apachebench. Each run was 1,000 requests with a concurrency of 1. For each script, I performed 4 apachebench runs. The first run was to warm APC, the file system, the moon phases aligning with Venus, et cetera. The requests per second of the next three runs were recorded, and the middle value was chosen. I expected to find a difference in performance. There is no question that autoloading takes more time, but the results astounded me. Specifically, the runs for the script using exclusively hard require statements yielded 46.3% more requests per second than the script using the autoloader. That’s a real performance difference.

The above establishes a significant, quantifiable performance difference for the simple operation of including code. There are, however, observable differences in behavior. I will try to enumerate some of these in as unbiased a fashion as possible:
- If your loading mechanism is based on the idea of loading discrete objects one at a time, such as with classes, remember that some objects are very small in size. A number of your class files may not have more than one or two static functions in them. Since the autoload operation is expensive, loading this code becomes an inefficient operation.
- If your loading mechanism is based on the idea of loading families of code, such as with include files, you are inclined to group small classes together in a single file. This of course makes the loading operation much chea
Truncated by Planet PHP, read more at the original (another 4335 bytes)
Former MySQL CEO represents Oracle at EC hearing?

Posted: December 17th, 2009, 5:44pm MST by ThinkPHP /dev/blog - PHP

I just came across several blog posts regarding the Oracle/Sun/MySQL war, including this one. There are a lot of interesting clarifications and opinions, but I want to highlight this comment from MySQL's founder Monty about Mårten Mickos which is worth reading. One excerpt:

That could however explain why he [Mårten] is now so eager to help Oracle buy MySQL and even represented Oracle at the EC hearing.

MySQL's former CEO representing Oracle in the EC hearing? Is it because Mårten converted to the dark side of the planet or is it because he believes MySQL will have a great future under Oracle's umbrella? Or has it to do with stock options as Monty's comment suggests?
Zend Framework Survey

Posted: December 17th, 2009, 7:31am MST by Zeev Suraski

In an effort to improve the frequency of my blog posting, I'm pushing it up today to once every 11 months

On a more serious note - we're running a Zend Framework survey that's in progress right now. The best way to influence the future of ZF is by submitting a signed CLA and beginning to contribute; Filling out the survey is the 2nd best way!

If you're still not convinced - we're also going to be giving away an iPod touch for one of the respondents - and it only takes around 3 or 4 minutes to fill out.

We need your feedback!
PHP’s Not Just a Language

Posted: December 16th, 2009, 10:00pm MST by PHP Advent

“I did not develop the PHP we know today. Dozens — if not hundreds — of people developed PHP. I was simply the first developer.”

— Rasmus Lerdorf1

Six years ago, I became aware of the PHP community. I joined it three years prior to that.
Communities don’t make languages; languages make communities
I’m not a very chatty person, and I abhor small talk (not the programming language, the empty conversation kind). So, if I don’t say much to you when we see each other at a conference, don’t be offended. When I’m in Europe and my ear happens to capture the unique sound of an American accent, however, I won’t hesitate to say “hi.” I’ll even strike up a short conversation. You might even call it small talk. “Where are you from? How long are you here? What sites have you visited?”

I recall one time when I was in New York and heard the distinct sound of a Southern accent. It turned out that the speaker lived only twenty miles from me in Georgia.

Our languages bring us together and give us identity. When we have nothing else in common, sharing the same language gives us the only commonality we need, and if we don’t share that, we’ll find a way to communicate in other ways. I’m reminded of the Star Trek: The Next Generation episode “Darmok.” It’s one of my favorite episodes of the series, and in it, Captain Picard must learn to communicate with an alien captain who speaks only in metaphors. He succeeds, they overcome a dangerous beast, and the Federation gains a new ally. How? Because of language.

It is a natural human inclination to live among people who speak the same language, to seek them out and fellowship with them. After all, you can understand them, and they can understand you. I am no sociologist, but I submit to you that language is perhaps the fundamental building block of community. Without a common language — a common means of gaining understanding and expressing ideas — there can be no community. After all, the word community is right there in the word communication.2 Community is about language.

In much the same way, programming languages create communities. Programmers seek out support and fellowship from those who use the same programming language. We get together. We talk shop. We’ve encountered a lot of the same problems in our work, and we can help each other become better at our craft by sharing our experiences.
Which came first, the language or the community?
I imagine this is a difficult question to answer. As I said earlier, I am not a sociologist. I am also not a linguist, although I do have some background in the study of the English language.

As I stated earlier, language makes a community, but it is often a need of the community to have a common language. This is how languages evolve and become new languages. Historically, cultures that came in constant contact through trading, for example, would develop pidgin languages. Over time, these pidgin languages became creole languages, as parents taught the language to their children as their first language.3 Still, there are languages, such as English, that evolved over time as it borrowed from other languages, and changed according to common usage. It continues to change today.

So, communities require communication. In order to communicate, there must be some kind of language, and if there isn’t, the community will create one, and the language of a community changes over time.
PHP is a language; PHP is a community
PHP is a lot like the English language. It began its life as a utilitarian language, serving a simple purpose: processing forms on a web page. A diverse community grew up around this language, further evolving it and changing it to suit their needs, to aid in communication. After all, a programming language is just another means of communication. The audience may be different — in this case, the language is for communicating with a server, database, and more — but the end goal is the same.

In fact, taking this analogy a bit further, PHP/FI, created by Rasmus Lerdorf is like Old English, while Andi Gutmans and Zeev Suraski brought about their own Norman conquest of PHP, creating Middle PHP (
Truncated by Planet PHP, read more at the original (another 6532 bytes)
PHP 5.2.12 Released!

Posted: December 16th, 2009, 4:00pm MST by PHP: Hypertext Preprocessor

The PHP development team would like to announce the immediate availability of PHP 5.2.12. This release focuses on improving the stability of the PHP 5.2.x branch with over 60 bug fixes, some of which are security related. All users of PHP 5.2 are encouraged to upgrade to this release. Security Enhancements and Fixes in PHP 5.2.12:Fixed a safe_mode bypass in tempnam() identified by Grzegorz Stachowiak. (CVE-2009-3557, Rasmus)Fixed a open_basedir bypass in posix_mkfifo() identified by Grzegorz Stachowiak. (CVE-2009-3558, Rasmus)Added "max_file_uploads" INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion, identified by Bogdan Calin. (CVE-2009-4017, Ilia)Added protection for $_SESSION from interrupt corruption and improved "session.save_path" check, identified by Stefan Esser. (CVE-2009-4143, Stas)Fixed bug #49785 (insufficient input string validation of htmlspecialchars()). (CVE-2009-4142, Moriyoshi, hello at iwamot dot com) Further details about the PHP 5.2.12 release can be found in the release announcement, and the full list of changes are available in the ChangeLog.
Moving On...

Posted: December 16th, 2009, 3:26pm MST by Tony Bibbs on PHP
My guess is this will largely go un-noticed but I felt a formal blog post was in order for announcing my decision to stop contributing to AptitudeCMS and Geeklog.
I owe quite a bit to Geeklog...after installing Linux and PHP for the first time over 12 years ago I ran across Geeklog, learned a thing or two about open source development and started Iowa Outdoors (which I've since sold). Not long after that I was fortunate enough to serve as the project lead for Geeklog before handing it off to the current lead, Dirk Haun. Back then, there weren't many viable options in the now overcrowded PHP CMS market. Sadly, I've watched Geeklog's popularity slowly decline to its current state. That said, I have a few constructive things to say to the Geeklog community and the PHP community at large.
First to the Geeklog community. You've run into rough times. WordPress, Joomla, Drupal and company really are the champions in this space. Without doing more digging than I care to, I know Geeklog is far behind in any of the hard metrics that really matter (code commits, # of active developers, etc). Just a hint of proof is had by comparing Geeklog's Ohloh stats with this, this and this. Then there those things you can't quite quantify, the passion of the community and the level of innovation happening. Right now I feel the Geeklog community is pretty stagnant. Some of this is likely to be blamed on the fork of Geeklog (whose Ohloh stats don't speak well either). Fact is if you combine both glFusion and Geeklog's numbers together it still paints a pretty bad picture. You could argue they don't need to aspire to be like WordPress, Joomla and Drupal which is fine but what I think has gotten lost in all of this nobody has consciously said if that's the game they want to play and, if not, what differentiates Geeklog from the rest? In the meantime, the set of features added over the past year or two suggest, in fact, they are playing catch-up to some of the features found in those other systems. That's not bad, but my point is Geeklog seems to lack a tangible goal. I guess that is part of the nature of open source...the perpetual, organic, itching of scratches but I still feel open source projects need to have long term visions far beyond the next commit, next point release and even next major release. With that said here's some suggestions for Geeklog's community in no particular order:
- Change your name - I attempted to address this with AptitudeCMS and failed but something has to be done. I'm not sure if there is a precedent for a name change in a well established open source project but it has to happen for Geeklog. To me it is branding 101. For anybody outside of a blogger or hobbyist, it's hard to take the Geeklog brand seriously. Pointy haired managers scoff at such a name (I've seen it). Sure you risk confusing or alienating people but I feel Geeklog, as a brand, is hard to sell. That said, even without a name change the remaining points are crucial.
- Change your image - The Geeklog homepage screams mid-1990's era design. It's the first impression we give users. Even if you don't want to compete directly with the bigger kids on the block, you can't argue that Joomla, WordPress and even the Geeklog fork looks better. It's the first impression a user gets. I think improving the Geeklog homepage will lead to more interest. Once captivated, I have now doubt the codebase speaks for itself but, for now, the Geeklog homepage is forgettable for new users.
- Get social - Geeklog is no where to be found on Twitter, Facebook, etc. The missed opportunities here are, frankly, staggering. The PHP community (as well as Drupal, Joomla, etc) all have a strong presence in these areas and I have no doubt the Geeklog community could benefit by joining the conversation.
- Blog - Let's face it, there isn't much in the way of active Geeklog developers. The ones there really need to blog about what's going on behind the scenes. What are you working on? What's a challenge you are facing? Any good commits lately? This in part gets back to the goal setting discussion but it is more todo with giving the community a glimpse of what is going on.
- Find a partner - Ok, this is probably one of the more controversial points and one that is often dodged in open source discussions but behind nearly all successful open source projects is an organization. Sometimes it is not-for-profits but many times i
Truncated by Planet PHP, read more at the original (another 6134 bytes)
Multiple PHP versions on the same IIS server

Posted: December 16th, 2009, 1:45pm MST by Ruslan Yakushev
This post describes how to configure IIS to support multiple versions of PHP on the same server. This kind of setup is useful in development environments where it is necessary to test an application with different PHP versions. Also, it is often used in production environments, where many PHP applications are hosted on the same server and some of them have dependency on a particular PHP version.

In order to setup multiple versions of PHP side by side on the same IIS server it is necessary to install PHP manually by following the steps described in php.net documentation for IIS 5.1 and IIS 6.0 and for IIS 7.0 and later. Do not use PHP Windows installer because it does not support side by side installations.

After a particular version of PHP has been installed in accordance to the instructions, download another version of PHP, extract it into a separate directory and configure it in accordance to Manual Installation Steps. After that proceed to configuring an IIS server as per instructions below:
Note: in all examples below two PHP versions are installed on the same server. PHP 5.2.11 files are located in C:\PHP5211\ directory and PHP 5.3.1 files are located in C:\PHP531\ directory.
IIS 5.1
The FastCGI Extension can be configured on a server and a site level. Since IIS 5.1 can have only one web site, it is not possible to configure it to have two versions of PHP running at the same time. But it is possible to have a configuration that allows to easily switch from one version to another.

Open the IIS FastCGI extension configuration file at %windir%\system32\inetsrv\fcgiext.ini. At the end of the file there will be a section that defines FastCGI applications. It may look similar to this:
```
[Types]
php=php5211

[php5211]
ExePath=C:\php5211\php-cgi.exe
```
This configures IIS to use PHP 5.2.11 whenever a request for a *.php file is made. To switch to PHP 5.3.1, just add another section declaration and then modify the [Types] section as below:
```
[Types]
;php=php5211
php=php531

[php5211]
ExePath=C:\php5211\php-cgi.exe

[php531]
ExePath=C:\php531\php-cgi.exe
```
To switch back to PHP 5.2.11 update the [Types] section by commenting out php=php531 and un-commenting php=php5211. There is no need to restart IIS after the updates to fcgiexe.ini have been made. FastCGI Extension will pick up the changes as soon as file has been saved.
IIS 6.0
FastCGI on IIS 6.0 can be configured on a server level, which would cause all the IIS web sites to use the same PHP version. Configuring FastCGI on a server level and switching between PHP versions is exactly the same procedure as for IIS 5.1.

Additionally FastCGI can be configured on a site level, which would allow using of different PHP versions for different web sites. To assign a particular PHP version to a site, use the following commands. Make sure to replace the <site_id> with real site identifiers.
```
cscript %windir%\system32\inetsrv\fcgiconfig.js -add -section:"php5211" ^
-extension:php -path:"C:\php5211\php-cgi.exe" -site:<site_id>

cscript %windir%\system32\inetsrv\fcgiconfig.js -add -section:"php531" ^
-extension:php -path:"C:\php531\php-cgi.exe" -site:<site_id>
```
After executing these commands open the fcgiext.ini file located in %WINDIR%\system32\inetsrv. It should contain the following sections:
```
[Types]
php:169297538=php5211 ; The actual site id will be different for your site
php:273357939=php531 ; The actual site id will be different for your site

[php5211]
ExePath=C:\php5211\php-cgi.exe

[php531]
ExePath=C:\php531\php-cgi.exe
```
IIS 7.0 and later
FastCGI module in IIS 7.0 can be configured on any level: server, site, application and folder. This means that it is even possible to have two applications using different PHP versions within the same web site.

To configure FastCGI on a server level, use these commands:
```
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI ^
/+[fullPath='c:\php531\php-cgi.exe']

%windir%\system32\inetsrv\appcmd
```
Truncated by Planet PHP, read more at the original (another 2742 bytes)
Zend Framework Survey for 2009

Posted: December 16th, 2009, 9:47am MST by Zend Developer Zone

Please help us shape the future of Zend Framework! We need your input to help us better understand the way ZF is used in the real world, what's working and what isn't, and where you would like us to invest next. With ZF 2.0 work commencing soon - there has never been a better time to provide your feedback.
PageRank In PHP

Posted: December 16th, 2009, 3:00am MST by Ian Barber

Google was a better search engine than it's predecessors for a number of reasons, but probably the most well known one is PageRank, the algorithm for measuring the importance of a page based on what links to it. Though not necessarily that useful on its own, this kind of link analysis can be very helpful as part of a general information retrieval system, or when looking at any kind of network, such as a friend graph from a social network.
Larry Page came up with PageRank as a way of measuring the importance of a page while at Stanford in the mid nineties. The idea is that there is a random surfer, who starts on web page then browses through in a somewhat random way. For each page the surfer visits he randomly chooses one of the links from that page and follows it. From time to time though he gets bored, or hits a page with no links on it, and so jumps to some different page and starts the process again. The PageRank of a page is the proportion of his time that the surfer spends on the page.
This random walk is a Markov chain, a traversal of a matrix that gives the probability of moving to any state from any other state, with the total probabilities for the destinations from any given page adding up to 1. PageRank attempts to extract a vector of weights from that table, with one weight per page - they aren't related to any particularly query, so are only ever going to be a factor in a page being returned on a results page. However, all else being equal, a page with higher PageRank should be a better match than a page with lower PageRank.
As an aside, looking at links is also a convenient for one of the other key advances Google made - indexing pages based on the text of anchors pointing towards the page. This helps in cases where a term that the page might not use itself is searched for - for example the phrase 'big blue' for IBM is unlikely to be on their site, but will be in some links to that site. It also helps for resources which are hard to index themselves, such as videos and images, meaning they can be included in the results.
The general idea then of PageRank is pretty simply - a page hands out its PageRank to the pages it links to - but it leads to a chicken and egg situation. At the start of the process the page has no PageRank to hand out, just whatever it was initialised to. This means that the algorithm must be an iterative process, which converges on the true values.
Each page is initially given 1/the total number of pages of PageRank. At each step this is handed out to all the pages that it links to, and the base PageRank for each page replaced with the total amount it received, minus the damping factor to reflect the possibility of our random surfing typing a new URL in. We loop this until the PageRank is pretty stable, which is normally in the region of 30-50 iterations.
If we assume that we have already done our crawling and parsing steps, we will be left with an index of document IDs for different pages, and the document IDs of the pages that they link to. We don't necessarily need the whole link graph in memory, but for the example we'll assume that it does fit - this is patently not true for truly webscale items where we are likely to be talking billions or trillions of links.
<?php

$links = array(
1 => array(5),
2 => array(4, 7, 8),
3 => array(1, 3, 4, 7, 9),
4 => array(1, 2, 4, 8),
5 => array(1, 6, 7, 9),
6
Truncated by Planet PHP, read more at the original (another 13480 bytes)
South Korea's 'real-name verification law'

Posted: December 16th, 2009, 1:45am MST by Evert Pot

About a week ago, I moved to South Korea. While trying to share some video with the homebase (check my other blog). I wanted to upload some video's to youtube, only to be presented with the following message:

After binging it (or is it bang? I prefer bang) it turns out that any site with more than 100.000 users must require users to identify themselves with their real name and an 'identification number'. Youtube has instead blocked commenting and uploading altogether for South Koreans. I can't find much information on the subject other than some ZDnet articles.

I find this a bit scary. I personally enjoy my anonymity on the net.
Painless Spec and Schedule Development

Posted: December 15th, 2009, 11:00pm MST by Brandon Savage

In the time that I have developed software, I don’t know that I’ve ever met a developer who got excited about writing specs for anything. In fact, most developers loathe writing specs, or developing schedules of any kind. It’s not that they’re lazy, or that they don’t want to be held accountable; most of the time it’s because developers prefer to express themselves via code, or because developers are afraid that if they set a schedule, and then reality doesn’t match up, they’ll be forced to produce sub-standard code. Neither of these is an ideal situation.

This is directly at odds with the business need of specifications and schedules. Businesses need schedules to know when products will be finished and schedule things like trade shows, product launches, and write contracts with clients who need or want a particular product. It’s not as if businesses want to push their developers to insanity by forcing them to schedule and then stick to it; more often than not thousands of dollars hinges on the schedule, and it simply must be met.

Schedules and specs are a core component of software development, and business development; so much so that Joel Spolsky included developing both as core components of the Joel Test. While developers hate writing specs and developing schedules, there are some painless steps they can take to create them.

Specs need not be complete documents
Lots of times, specs need not be complete documents that contain specific, detailed information. In fact, lots of times specs need not contain a single complete sentence to be effective. Specs are, in their most basic form, a description of the way that something should work. A wire frame, if done properly, is an adequate spec. The workflow of an application together with markers, is a spec. My specs are simply drawings of the view that I want together with some notes, arrows, and perhaps some writing on the back; this works well because it describes the way the application should look, and the rest of the spec contains database diagrams and other views to enhance understanding.

Writing a spec doesn’t actually mean opening up Microsoft Word each and every time. And the client shouldn’t be expected to generate a document like that, either (see the third section below). Specs can be representations of functional apps.

Specs are not documentation
There seems to be another push in many groups to be able to use the spec as documentation later on. Don’t do this! Specs are not documentation. They are descriptions of how the thing should work, not diagrams for how it does work.

Actually implementing the details of the spec may result in a disconnect between the implementation specified and the implementation completed. This is normal; programmers often discover logical mistakes in specs when they actually go to implement them, and must make adjustments. This occurs in every field; engineers, for example, must sometimes adjust their underground services to route around unmarked power or sewer lines. Deviation from the spec is normal, as long as the end product looks like the spec.

However, if the spec is meant to be the documentation, and there is no time in the schedule for writing documentation, there’s intense pressure to make the spec and the implementation look identical. This leads to unusable or difficult software, or worse, bugs. Spend time to write documentation, rather than relying on the spec to do double duty.

The development of the spec should be done by the developers, not the client
There’s an old customer service adage: The customer is always right! This is not true, however, when it comes to the details in the spec.

Consider: when you hire an architect, you tell him that you want a house. You do not, however, hand him the blueprints. Instead, he draws up plans and works with you to develop the blueprints for your house. Handing him a set of blueprints and telling him to build the house would eliminate the need to have the architect in the first place! The same is true for the development of specifications.

Developers should work with the clients to make sure that the needs of the client (”I need an invoicing system” or “I need a new website with a blog”) are translated into technical specs (”We need to use Zend_Pdf with Symfony” or “Drupal is the best option here”).
Truncated by Planet PHP, read more at the original (another 4990 bytes)
Managing Bob

Posted: December 15th, 2009, 10:00pm MST by PHP Advent

The interaction between technical people and the project sponsor has common patterns regardless of your employment model. Project sponsors — whether consulting or freelance clients, key stake holders within your organization, or potential users from some vaguely-defined demographic — all have similar needs and issues. I’m going to collectively call these people Bob from now on, because “clients, key stake holders, and end users” is very wordy, and pixels are expensive. Also, it helps to put a human face on a role. (Three quarters of the way through a project, it might help to put a human face, specifically Bob’s, on your dart board.)

Technical people tend to think first and foremost of the technical parts of a project. That seems like an obvious truism, right? If they thought first and foremost of the color of the packaging, or the training users will need, or how best to market the end result, they probably would have gravitated toward a different career.

Effectively managing Bob is a key task that directly leads to project success. Sometimes the relationship has obviously adversarial aspects, such as in a fixed-price contract where both sides are likely to disagree over what is within the project scope, but even the friendliest relationship has the same basic conflict between the technical staff and Bob. The sponsor wants more, and wants it on time. The technical staff needs to restrain their enthusiasm, so that a cross between those wants and the constraints of reality is produced.

Regardless of whether Bob is your employer or client, you need the same basic elements to control the process: an upfront plan (recorded in some way), a way of recording all changes, an agreement on who has the authority to make changes, and the power to update the original plan’s time estimates in the event of change.

Overall project success or failure is only sometimes closely tied to technical factors. Right off the bat, you need to think about who decides if the project was a success, and regardless of whether that determination is made based on measurable, objective factors or more commonly just the person paying the bill’s gut reaction, it probably is not made on the basis of a technical evaluation.

The determination is made by Bob. Bob rarely has the knowledge to judge a project on its technical merits, and even more rarely cares. He has his own internal set of criteria, only some of which you have the knowledge to understand, and even fewer of which you care about, and many of them will go unstated until it is too late, unless you are very good at extracting information from uncooperative subjects without the use of pliers or waterboarding.

I’m not saying you should deliver poor quality code. Non-technical people certainly notice the side effects of good code. Even if Bob would not recognize it if a bus — plastered with beautifully-tested code implementing a cool new design pattern that was only invented tomorrow — ran him down in the street, he notices the results. Bob notices uptime, how long seemingly minor change requests take to implement, consistency in the UI, crashes, revenue, and conversion rates. He will notice the symptoms of bad code, even if he does not have the knowledge to diagnose the root cause, or the vocabulary to request the cure.

My point is that technical aspects are only a small part of overall project success. Extracting real, actionable requirements from Bob, setting realistic expectations, and either meeting those original expectations or keeping the project on track as things change is a big part of success. Manage new information, new feature requests, and change requests while either coming in on time or resetting Bob’s expectations in advance. This keeps him informed about what impact his requests, dreams, maternal attachment issues, and crazy ideas he read in this week’s issue of IT Trends For Steam Engine Manufacturers are having on the project.

If your project is to be a success, you need to effectively and proactively manage Bob. You need to keep him happy, which probably means making good overall progress, but specifically making some visible progress in parts of the project he does understand. You need to deny some of his change requests so that the project reaches completion. You need to accept some of his change requests so that he feels that the power dynamic is correct, but you need to either have allowed the right amount of padding in anticipation of change, or make sure that Bob is aware what effect the request has on the timeline.

One of the best and worst things about software is that it is infinitely malleable. If you don’t like change, perhaps steam engine manufacturing would be a better career for you. Change will ha
Truncated by Planet PHP, read more at the original (another 4016 bytes)
A response to “Better Postal/Zip Code Validation Method for CakePHP 1.2″

Posted: December 15th, 2009, 6:59am MST by Ken Guest

Just a few minutes ago I read Jamie Nay’s A Better Postal/Zip Code Validation Method for CakePHP 1.2 blog post.

Jamie says that “The Validation::postal() method that comes with CakePHP 1.2 is good in that it can handle a number of different country formats, but the problem is you can only validate your data against one country. What if you want to accept, say, either Canadian or US postal/zip code formats? I ran into this problem earlier today, and decided to write my own postal() function that can take either a string as the country, just like Validation::postal(), or an array of countries.”

I’m probably going to have to wait for Jamie to wake up before my comment on that blog-post is approved, but the crux of it is “Don’t”. Don’t write your own code to validate user input, unless of course the input data is specific to a problem domain that others haven’t catered for yet.

I drew attention to two things. The first is that there are Validation packages in PEAR, including the main Validate class and all the Validate_xx subclasses such as Validate_US, Validate_CA and some 22 others).

The second item I drew Jamie’s attention to is that his validation code counts a zip code of “00000″ as valid, when the USPS zip code look up tool correctly (and they should know!) identifies that code as invalid.

Why spend time writing and debugging regular expressions, compiling lists of valid data and so on when other people have already done this work? Especially when it comes down to such things as validating data input which is crucial when you need to guard against cross site scripting vulnerabilities.

Focus on what you need to do rather than reimplementing what others have already done.

Honestly, this probably should be subtitled – “Stop the NIH craziness, please” – though to be fair Jamie might not have known of the solutions already out there.
TAB’s new layout

Posted: December 15th, 2009, 6:41am MST by Marco Tabini

Over the past few weeks, I have toyed with the idea of giving The Accidental Businessman a new look. I don’t dislike the current theme, but, as I mentioned in an earlier post, it’s a bit too “angular” for my taste.

Over the last few days, therefore, I stole a few minutes of free time here and there to come up with a new design. It turned out to be an interesting experience, both because on this site I have a degree of freedom with experimentation that I can’t really afford anywhere else (not necessarily a good thing) and because of the technical challenges of realizing my vision for the site on current browsers (the site works with IE8, FF3.5 and Safari 4).
Maximum space
My first concern was to maximize the space available on the screen for viewing. Screen reading is quite difficult—ironically because there is usually much more space available than the comfortable reading angle that the human eye can accommodate.

The default solution to this problem is to confine the reading area to a small horizontal section of the screen; this works, but it’s also very inefficient: it’s the physical-world equivalent of printing a sixty-character line of point-10 font on an A2-size sheet: inefficient, wasteful and difficult to handle. The way I see it, the typical web layout works if you like scrolling. Me, I like to open a webpage, lean back on my chair and read.

Speaking of real world, it occurs to me that newspapers have already solved this problem—and, in so doing, have established a number of rules to make the task of as much space available as possible in a manner that is both efficient and aesthetically pleasing. Therefore, the new TAB layout attempts to mimic the look of newsprint as much as possible, keeping in mind that, of course, my blog is not printed on paper (therefore, some concessions to life online—such as leaving some room for comments).
Layout
The new layout makes heavy use of Javascript—according to my statistics, practically all my visitors have a Javascript-capable browser and leave JS enabled, so I have absolutely no problem with taking advantage of a bit of scripting to achieve my goals¹. Through the magic of jQuery, the content is automagically laid out across multiple columns—their number determined based on the site of the browser window—and paginated across multiple screen, which you can navigate without a browser refresh².

I decided to keep a comment area on the right-hand side only so that comments can be visible at all times. I am unsure as to how good this is—on a screen big enough, it seems to work fairly well, but at lower resolutions it robs much of the content area from the rest of the article.
Typography
The proper use of type is as important on the web as it is on paper—even more so on the former, perhaps, because of the limited resolution at which we are forced to view type online. Unfortunately, typography is often completely disregarded by web designers—I’m not sure why this is, but the focus seems to always be on graphical elements that, at the end of the day, have little or no importance: if your header looks colourful and has all sorts of bells and whistles, but people can’t read what in the body of your site, they are unlikely to be very happy.

In choosing a typographical design for TAB, I started from the most excellent Baseline CSS Framework, which, much like newspaper typesetters, uses a simple set of rules to ensure that multi-columnar text will line up properly on the font’s baseline. The framework’s setup is actually fairly simple: each style is an integer multiple of the base font size and line height, resulting in a text flow that lines up perfectly across multiple columns—in fact, as long as every element on a page follows the same rule, images and practically any other type of content can be added to an article and still maintain the same baseline alignment.

The script also support a very basic form of orphan and widow control, so that a heading should never appear either at the end of a column, or (even worse) “broken” across two columns. I am investigating ways to improve on this particular piece of technology to improve paragraph control well beyond the basics, but I fear that some of the calculations required will slow things down too much. Unfortunately, the level of control that CSS affords over sub-paragraph data (at least in CSS2, which is the target here) is not quite as good as it could be.

Finally, you will note that the text in the columns is justified. I usually dislike full justification in a browser because hyphenation is not a possibility and, therefore, there are often unsightly gaps between words that make reading
Truncated by Planet PHP, read more at the original (another 2655 bytes)
2009 Conferences Wrap-up

Posted: December 15th, 2009, 3:09am MST by Fabien Potencier
This year, I traveled in 7 countries for PHP conferences, giving a total of 12 talks. It has been a very exiting year of conferences for me. I met old and new friends, I learned a bunch of new things (not always related to PHP) and I had of course very interesting conversations about PHP 5.3, symfony, Twig, the Zend Framework, and various other topics.

In March, I went to the PHP Quebec conference. Three years ago, this was my first PHP conference, and as such it's always a very special event for me. This was also the first conference where I gave a talk about Symfony 2.

In May, I had the pleasure to go to the PHP Day in Italy. This was probably one of the most convivial conference of the year. Italian people are very friendly, and the food is always amazing.

In June, it was the first Symfony Live conference. I was one of the organizer, and also a speaker of course. This was a great success and I had a wonderful time talking with so many symfony users.

In September, I went to Japan for their 10th PHP conference. This was my first time in Japan, and I'm eager to come back someday. This was also the first time I worked with a professional translator.

In October, thanks to Zend, I went to the Zend PHP Conference in San Jose. Needless to say that this was an amazing experience. I have also kind of officially "launched" Twig at this conference, and created Pirum during a night thanks to the jetlag. This is also where I decided that Symfony 2 would only support PHP 5.3. At the end of October, I also went to the PHP Barcelona conference for the first time.

In November, after the Forum PHP conference in Paris, where I talked about PHP 5.3, my new friend, I went to the IPC conference in Karlsruhe. Two great conferences, where I always meet a lot of friends.

Thanks to all conference organizers for giving me these great opportunities.

All my slides are available in the talk section of this website, and also on Slideshare.

Here is a list of the most interesting/up-to-date talks I gave this year:
2009 is coming to an end, and 2010 is already almost here. I'm going to be doing a fair bit of traveling early next year as I will speak at least at these conferences:
- Dependency Injection in PHP 5.2 and 5.3: PHPBenelux conference (January 30, 2010 - Antwerp, Belgium)
- Playing with the symfony components: Symfony Live Conference (February 16, 2010 - Paris, France)
- Symfony 2 revealed: Symfony Live Conference (February 17, 2010 - Paris, France)
- PHP 5.3 in practice: PHP UK Conference (26 February, 2010, London, England)
- Symfony Components: What's in for you?: ConFoo (March 10, 2010, Montreal, Canada)
- Dependency Injection in PHP 5.2 and 5.3: ConFoo (March 10, 2010, Montreal, Canada)
See you next year at one of the PHP conference!
Dæmonize Your PHP

Posted: December 14th, 2009, 10:00pm MST by PHP Advent
Despite the haters, I actually really like PHP. Well-written PHP strikes a solid balance between getting things done and getting things done properly. It also lives somewhere comfortably between development time and performance. It’s — at least in my opinion — the best tool for creating web apps.

Sometimes, though, we’re called on to write bits of code that live outside of our arena of the Web: cron jobs, mail processors, Subversion hooks, or even asynchronous workers.

There are often better tools than PHP to accomplish these tasks. For example, if Procmail can solve your problem, you can avoid writing a lot of nasty mail parsing logic — even if you do get a little help. Although PHP does have some ability to perform tasks normally delegated to systems engineers, most developers with a bit of experience in Python will tell you that it’s a better choice for things like forking and creating network dæmons, and I agree.

In my opinion, there are two major reasons to use PHP outside of the Web — and they’re very good reasons when they’re your main reasons:
1. Familiarity: Many PHP developers will have dabbled in other technologies to pragmatically scratch normal development itches, but — especially at junior- and mid-levels — they’re most comfortable with PHP, because they’re fully immersed in it for their whole professional career. They can crank out PHP code faster than they could even remember the syntax to operate on files.
2. Code re-use: A side effect of full immersion in PHP is that you’ll have plenty of PHP code laying around, ready to be employed in new and unexpected ways — especially if it’s well-designed. There’s no need to reinvent the wheel for most non-web tasks, and doing so is often detrimental to maintenance and predictability. You wouldn’t want to implement password hashing code in two separate languages, in two places.
One unintended place that I’ve been using PHP lately is in long-running processes. PHP 5.3’s improved garbage collection helps in certain situations, but what I really needed was something that would not only keep my processes running, but would also keep track of logging, concurrency, and crash recovery. When an Apache process crashes, or reaches its maximum number of requests, another one spins up in its place with little negative side effect to users. I wanted something like this, but I certainly didn’t want to write it.

Luckily, I’m not the first person who envisioned such a thing. After toying with the ambiguously-named Daemon (which I wasn’t able to compile and execute properly on OS X) for a work project, my friend Andrei Zmievski inadvertently pointed me in the direction of Supervisord, which was created in part by Mike Naberezny, whose name you might recognize from his past gig as the primary maintainer of Zend Framework.

Supervisord, through a very simple configuration system, allows me to create simple long-running processes without having to worry about the the support infrastructure. It handles the things I mentioned above with ease, and keeps my scripts running without worry.

One such script is a fun little service I’ve attached to Twitter called @beerscore. This bot allows me to DM beer names via Twitter, and within a few seconds, I’ll receive a reply with the percentile rating for the beer I’ve requested. This is particularly useful when I’m traveling and don’t necessarily have web access, but I’ve almost always got SMS coverage. (If you’d like to play with it, you must follow @beerscore in order to send a direct message.)

The code behind @beerscore runs constantly to follow-back users and to serve scores. If it crashes for some reason, a new copy is spawned. Its output is logged, systematicall
Truncated by Planet PHP, read more at the original (another 3158 bytes)
Announcing December's ZF Bug Hunt Days

Posted: December 14th, 2009, 6:44am MST by Zend Developer Zone

This upcoming Thursday and Friday, 17-18 December 2009, Zend Framework will host its fourth monthly bug hunt. Each month, the community organizes to help reduce the number of open issues reported against the framework. Past events have netted over 100 issue closures over each two-day period; let's keep up the momentum! The rules and rewards are simple: Supply patches or direct commits that resolve open issues. The individual who resolves or assists in resolving the most issues during the bug hunt wins a Zend Framework t-shirt!
CSS and Other People

Posted: December 13th, 2009, 10:00pm MST by PHP Advent
The road between design and development is fraught with all sorts of peril — as Helgi has already pointed out. Bringing a visual concept to the Web is a group effort that often requires the collaboration of people with different backgrounds and areas of knowledge.

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of html and CSS that will render properly on browsers that are often at complete odds with one another.

This process is a bit like a wicked game of chess; there are only a small number of fast and set rules, but an almost unlimited numbers of ways (both good and bad) to achieve a goal. Like a game of chess, a player who doesn’t understand the rules can end up in serious trouble, which, in the case of front-end development, can easily roll downhill and affect other people on a project.

I have seen (and experienced) this problem tackled in a number of different ways by different teams; while there’s probably no right solution, here’s how we do it.
Establishing a good process
Front-end development needs to be a collaborative effort from the very beginning. A designer who builds comps blindly, without any input from the people who will have to translate the design into code, is asking for trouble. This can be easily compounded by showing the client a concept only to have to go back to them to let them know that it can’t be done in a way that will look good in a browser.

The first step in producing a design, therefore, needs to be a contract between the designer and the developer aimed at establishing whether the former’s ideas can actually be translated into working code. Typically, this is what a wireframe is for. (Personally, I’m not too keen on showing wireframes to customers, unless they have a high degree of familiarity with web design, because you will otherwise, invariably, have to explain why they are paying your firm to draw a bunch of boxes.)

The interaction between design and development shouldn’t end here, however — I would, in fact, argue that a developer should be allowed to review every comp before it is sent to the customer. This makes it possible to catch design decisions that are very difficult to implement in practice — such as gradients anchored to the bottom of a columnar <div> that needs to expand vertically — before the client becomes too attached to the idea.

As a side note, comps should include more than just the visual look of the page template. For example, the designer should create a specimen of all the styles that apply to the design: headings, paragraphs, lists, and so forth. Naturally, the complexity (and completeness) of the specimen should be proportional to the complexity of the web site; an online brochure is unlikely to have the same requirements as, say, an online encyclopedia.
CSS from the inside out
Once a design has been agreed upon, approved by the customer, and sliced to perfection, the process of transforming the comp into a series of files has three primary goals:
1. Minimize the use of images
2. Maximize browser compatibility
3. Minimize code complexity
The reason I like to minimize the use of images in a design is that it makes managing changes much simpler. Making changes in code requires fewer steps and produces more immediate results, leaving more room for experimentation in the implementation phase. This is particularly true with backgrounds (my least favorite design element), which clients seem to particularly enjoy changing. Naturally, minimizing image usage shouldn’t come at the expense of either maintaining good browser compatibility or writing code that is easy to maintain.

Producing good CSS is also a multi-step process that goes from the generic to the specific:
1. Start with a reset template (such as Yahoo’s) to ensure that your code will be based on a common starting point across multiple browsers.
2. Define a grid for your site using either one of the several pre-packaged frameworks — such as the 960 grid system, baseline, or YUI’s — or your own layout, based on your specific needs.
3. Compile a generic stylesheet of all relevant elements that are common throughout your templates: text, table
Truncated by Planet PHP, read more at the original (another 3298 bytes)
Book Review: jQuery 1.3 with PHP

Posted: December 13th, 2009, 4:46pm MST by Ken Guest

jQuery 1.3 with PHP
Before I start this review proper, I need to disclose one nugget of information first: The author, Kae Verens, and I are both currently serving as members of the Irish PHP Users Group Committee and have known each other for quite a few years. If you believe I can remain impartial and objective (as I hope you do – because I am), read on:

This is the first book sent to me from Packt where I wasn’t left dizzy from trying to understand just what it is the author was trying to get across. It looks like their proof-reader was awake for this one – totally awesome.

jQuery, as the vast majority of us already know, is a JavaScript library that simplifies html document traversing, event handling, animating, and Ajax interactions for rapid web development. In other words it does all the heavy lifting and takes care of cross-browser compatibility issues so you don’t have to and thus allows you to focus on the work that you need to do without all those distractions.

“jQuery 1.3 with PHP” is aimed “for PHP application developers who want to improve their user interfaces through jQuery’s capabilities and responsiveness”. Over the course of ten chapters Verens starts the off with an introduction, then a series of ‘Quick Tricks’ that almost immediately help you add some measure of “Web 2.0″ functionality to what I’d term a “web 0.2 application” rather sharply.
The book ends with a chapter on Optimization – some of which you are bound to already know and some which are complete gems.

In the middle are chapters with mini-projects on tabs and accordians, forms and form validation, file management, calendars (and how to make your own google-calendar-like application), image manipulation, drag and drop and data tables.
In each case, projects are analysed and the required steps for each are outlined in the simplest terms – no extraneous buzzwords are used or are the projects over-analysed for the sake of pedantry.

I was a little surprised in some places where, for example, the json encoded output was not created via json_encode; but then thought not everyone is going to have PHP 5.2 or greater installed. Thumb forward a few pages and this is mentioned. So all’s o k.

It was good to see Kae suggesting use of the PEAR Validate package (or similar) in the Forms and Forms Validation chapter (chapter 4). I had to wonder if there was a PEAR package for creating and shunting down jQuery validation rules to the client – and found that there isn’t. That’s something to consider for later on, I guess.

The rest of the book is similarly both easy to read and easy to understand – my first port of call for learning how to do something that I’d almost term exotic with jQuery and with PHP in the background is usually Google but that is going to change (actually it already has).

Honestly, I wouldn’t be surprised if this books working title was “JQuery and PHP: The HowTo” – it is that good.
Now, this book is not for learning jQuery – that is not within its remit, but I would heartily recomend “jQuery 1.3 with PHP” by Kae Verens to anyone wanting to utilise jQuery from a PHP background.
MySQL: from Midrange to the Enterprise market

Posted: December 13th, 2009, 11:31am MST by ThinkPHP /dev/blog - PHP

First of all, I want to link to a blog article written by the founder of MySQL to help MySQL being rescued - everybody can stand up and tell the European Commision why the Oracle/Sun deal threatens MySQL. Second, due to a personal request, I want to make clear that this posting reflects my personal opinion of the case.

Third, I have been thinking about the markets both database systems address and why MySQL really competes to Oracle in one way or another. There are several voices who claimed that MySQL is not a competitor to Oracle, but if you know "Project Peter", Sun (the current owner of the trademark MySQL and its source code) targets Oracle customers in order to convince them migrating to MySQL.

For a long time, I have been watching the rise of MySQL (since 1994 or 1995, I don't remember the exact date anymore). It's not only because myself and our company works mainly with PHP (the scripting language of the Web) and uses mainly MySQL (the database for the Web, although other "database" architectures like NoSQL become popular nowadays) ... I remember back in 2000 when I was maintaining the PHP-Center (together with Ralf Geschke), Germany's first portal where developers could find news, job listing, articles, case studies etc around PHP in German language. At this time, MySQL invited several luminaries and community members including myself to a meeting in Germany where we discussed the new German website and also the idea to create a subsidiary of MySQL AB for Germany (which was later known as the MySQL GmbH).

At this time, MySQL mainly targeted smaller and middle web applications, web sites like microsites for consumer goods, content management systems and the like. Back then, the so called "Enterprise Market" wasn't really a target as Oracle, DB2 and others were deep inside the Enterprise and had features MySQL couldn't compete with.

But in the last decade, MySQL's feature set grew continuously. It didn't grow that much so that it could replace database systems like Oracle. And also, if you look today at the feature sets of MySQL and Oracle, there's a clear difference between them although in some cases MySQL can compete in terms of database size, transaction handling, online backups and the like.

But something has changed in other areas in the last 10 years: the Web has been arriving into the Enterprise. Large customers thought about switching from terminal or desktop apps to web technologies like PHP, and this transition is going on until today and the future. The Web is everywhere - and with it there's also a fair chance that there's PHP and there's MySQL.

Enterprises are looking for cheaper IT infrastructure. With web architecture, they do not only get scalable systems. They are also thinking if they really need an Oracle or DB2 for their systems - or if a PHP5/MySQL5 would suffice their needs. And I can't believe that Oracle's sales force would sell MySQL subscriptions into the Enterprise in these cases if Oracle would own MySQL.

Please don't get me wrong: there are many areas where MySQL does not compete with an Oracle, but due to this transition to the web there are also many many situations where MySQL could become a great choice for an Enterprise customer.

And this is one of the reasons why MySQL must not be owned by Oracle - to give Enterprises a chance to make the transition to web architecture and cheaper infrastructure.
Come on Monty

Posted: December 13th, 2009, 5:33am MST by Lukas Smith

What on earth is Monty (and Richard) thinking? How can you spin around 180 and expect to come of believable? How can suddenly the GPL be the wrong choice? How can suddenly OSS depend on proprietary sales? Anyways, even without this change of minds, I do not believe in their arguments. I also do not hold stock in any of the involved companies (well I do not hold any direct stock in any company only indirectly by way of a few retirement funds I hold), so why do I keep posting on this? The reason is that I think this kind of stuff hurts OSS. It creates the kind of FUD we were worried about Microsoft spreading about OSS. Now that they are shutting up more and more, some seem to feel a void that they need to fill with some FUD of their own. To me Monty is just abusing the lack of understanding but the growing interest from the EU commission about open source to get his baby back on the cheap, or at least as much control as he can, since after all his baby can never be taken away .. its GPL stupid! But just as well anyone can have his baby on the same terms and of course only one company can claim to own the original copyright.

Now he is sending his employees out making bogus claims like that Eben supposedly has stated that "any fork using GPL code has the exact same business opportunities Oracle has is". Well since I do not follow this case full time I can obviously not claim to have read everything that Eben has said and I must admit I have any skimmed his letter for about 30min but I have read nothing of the sort in that letter. All that was said is that MySQL cannot be killed by Oracle and that there are viable business models in the MySQL space. And the more Oracle tries to kill MySQL, the more viable business models arise for competitors.

I do take issue with some of Eben's statements. For one I do agree that the vast majority of GPL projects are not dual licensed, a significant number of the more well known ones (JBoss, MySQL, SugarCRM to just one a few from the top of my head) do indeed follow this model. So I think it hurts his argument to claim to try to relegate MySQL AB's business models to be "atypical". It has certainly been a very effective business models for some of the bigger OSS companies to make it there.

I also take a bit of an issue with his arguments in regards to storage engines. While there might significant truth in there and especially the business model concerns in regards to Falcon are beyond what I know about the internals of MySQL AB's business (why does Eben know?), but overall there are technical reasons that do make storage engines advantageous. Anyways here is the section from his letter I am referring to from (copied from a Groklaw article):

18. "Storage engines," for example, are much discussed in the SO, under the impression that it is a virtue of MySQL that it is designed around replaceable storage engines, which the SO asserts can only be created and implemented by venture-funded firms needing proprietary distribution opportunities in order to recoup development costs. This, I think, is a misunderstanding of the technical history. MySQL's design was an outcome of the need for dual-license revenue, not a pre-condition to it. PostgreSQL, for example, does not have or need multiple storage engines: it contains a single highly-configurable storage manager which is not independent of the database engine. MySQL's use of multiple storage engines resulted from MySQL's need to have something to sell dual-license customers different and better than that provided to users under GPL. The resulting uncertainty that could arise over whether a table had been created using a transaction-safe storage engine or by the original freely-available MyISAM storage engine contributed to the problem with occasional corruption of MySQL databases that was long a primary drawback to the enterprise use of MySQL. MySQL AB contemplated and designed a single multi-purpose high-performance storage engine, named Falcon, that would have substantially replaced all existing MySQL storage engines, but the business-model consequences of that step were sufficiently negative for MySQL AB, because of its need to produce dual-license revenue, that the project was never completed.

I do agree that the entire storage engine stuff did become part of their business model. And yes in some ways it was also a disadvantage in that suddenly in order to get optimal performance/features out of a MySQL install one would have to tune multiple storage engines instead of just one. Or that due to setup mistakes an app would not work as expected. But its also an advantage, in that in PostgreSQL for example you do not get a choice if you want the overhead of transactions (heck I just d
Truncated by Planet PHP, read more at the original (another 720 bytes)
PHP Advent 2009: JSON Gotchas

Posted: December 13th, 2009, 2:03am MST by Tobias Hauser & Christian Wenz

Just a quick note that my JSON Gotchas article has just been published. The editors removed the last sentence, so here it is again: Happy holidays everyone!
Untitled

Posted: December 12th, 2009, 10:00pm MST by PHP Advent
i. An introduction
No one reads anymore, and you’re not going to read this. You’re going to scan it.

We need to more seriously consider how application design evolves in that context.
ii. A list
PHP succeeded because of 4 reasons, in order:
1. mod_php, also known as ubiquity
2. MySQL, and the tight coupling thereof
3. Cheap shared hosting
4. Web script installers on cheap web hosts
iii. B list
Terry Chay once wrote, “what I’m saying is look at the top 100 web sites on the Internet. About 40% of them are written in PHP, and 0% of them are written in Rails.” He apparently just made up this statistic, but no one pointed this out in the one hundred and twenty-three comments on the post.

As a form of procrastination, I went through the Quantcast top 100 and attempted to count those using PHP. I got 39. I wonder what the top 100 Facebook apps use. It’s harder to tell what people run these days, because everybody uses cool URIs with logical structure, even though that doesn’t matter anymore, except Walmart, which uses .gsp, which I’ve never seen before. I guessed on a few.

If you were judging PHP by the .php extension, you would think we were extinct by now. That’s okay. PHP is a means to an end; the more invisible we are, the more we’re doing our job.

“Powered by” has lost meaning. 100% of the top 100 sites run more than one language, somewhere.
iv. Stronger, better, faster, shorter
Technorati have maintained a list of the top 100 blogs since they started, but now they only show 25 per page, presumably to garner more page views. Maybe they know something we don’t about people not reading anymore. Maybe it’s hard to make money as a search engine. The list is updated once per day.
v. Two problems
I learned to program from Mastering Regular Expressions by Jeffrey Friedl. Now he blogs, and I’m happier about that than just about any blog other than Zeldman’s.
vi. Twignette
“You’d think T_STRING means a string, right? Pfft. [php.net] ”

— @tellyworth
I attempted to make a T-Pain joke. The actual page is funnier, “You’re supposed to know what T_SR means. For everybody who doesn’t know that, here is a table with those identifiers…”

Twitter doesn’t include years in their timestamps anywhere on the site.
vii. Copyright 2005
I think the best way to introduce someone to PHP is to take a static html page they have, rename the extension to .php, and put a useful bit of code in it. I wrote an article about this in 2005 with the money snippet telling you how to not have to update the copyright statement on your site every year when you should be sleeping off the celebrations from the night before. I’ve done some neat bits of code in my life, but the most popular page on my site, still, is a random image rotator, which is a glorified array_rand(). People don’t read; they Google.

The API most responsible for the Web’s success is the clipboard. Today’s revolution brought to you by the letters U, C, and V.
viii.
“Don’t tweet about a man crying. Write a tweet that will make a man cry.”

— @zeldman, 2009

We’re spending our time lately on allowing functions and classes to have any Unicode character in their name.

“They’re singing your praises while stealing your phrases.”

— Charles Mingus

MySQL : Drizzle :: PHP : PHP
vi. border-style: dashed;
The PHP.net web site looks — and more important
Truncated by Planet PHP, read more at the original (another 578 bytes)
JSON Gotchas

Posted: December 11th, 2009, 10:00pm MST by PHP Advent
JSON is a subset of the JavaScript language. JavaScript itself is based on ECMAScript, which is standardized in the ECMA-262 standard. Just this month, the 5th edition of the language standard was released. Section 15.12.1.2 gives an overview of the syntactic grammar, which defines values (such as strings and numbers), arrays, and objects. Arrays are delimited by square brackets; objects are delimited by curly braces. Here are a few examples:
```
var a = [1, 2, "three", true];
var o = {"name1": "value1", "name2": 2};
var mixed = [{"day": 13, "month": "December"}, {"day": 24, "month": "December"}];
```
JSON is very useful when building RIAs — what we often refer to as Ajax apps. These kinds of apps are constantly communicating with the server, sending and retrieving data. Since bandwidth is scarce, and unresponsiveness due to latency must be avoided, it is vital that data being sent is serialized in a format that is as concise as possible. Here, JSON comes into play, since it is much less bloated than something like XML. Another benefit of JSON is that it is trivial to convert a JSON string back into a JavaScript value:
```
var a = eval('([1, 2, "three", true])');
var o = eval('({"name1": "value1", "name2": 2})');
var mixed = eval('([{"day": 13, "month": "December"}, {"day": 24, "month": "December"}])');
```
Note the extra parentheses around the JSON strings. These turn the JSON strings into JavaScript expressions.
Notation or not?
If you have a closer look at the specification regarding the notation of objects, you will see that the keys (the parts on the left of the colons) are of type JSONString. A JSONString is defined in section 15.12.1.1 (Lexical Grammar) as an arbitrary list of string characters, delimited by double quotes. This is a more strict definition than what is supported in the JavvaScript implementations of modern browsers. For example, as far as most browsers are concerned, it is perfectly fine to use single quotes as the string delimiters:
```
var o = eval("({'name1': 'value1', 'name2': 2})");
var mixed = eval("([{'day': 13, 'month': 'December'}, {'day': 24, 'month': 'December'}])");
```
If an object member’s key does not contain special characters (and if it also conforms with a few other rules), you can even get rid of its delimiters, saving a few more bytes:
```
var o = eval("({name1: 'value1', name2: 2})");
var mixed = eval("([{day: 13, month: 'December'}, {day: 24, month: 'December'}])");
```
There is, however, an issue with this approach: most JSON libraries adhere to the specification, not to the browsers’ behaviors. PHP’s JSON extension (shipped with versions 5.2+), for instance, expects double quotes:
```
var_dump(json_decode("[1, 2, 'three', true]")); //NULL
var_dump(json_decode("[{'day': 13, 'month': 'December'}, {'day': 24, 'month': 'December'}]")); //NULL
var_dump(json_decode("[{day: 13, month: 'December'}, {day: 24, month: 'December'}]")); //NULL
```
Most frameworks behave identically, both for decoding and encoding. For example, Zend_Json in the Zend Framework requires double quotes. If you are generate a JSON string in your client app and send it to the server for decoding, make sure to adhere to the specification. If you don’t, json_decode() and Zend_Json::decode() will fail to decode the JSON string.
Security
There is a reason that eval has the same metaphone key as evil. The JSON string is executed in the same JavaScript context as the current page. It is an absolute necessity that you trust the source of the JSON data — if the source is untrusted, another safer and more restrictive parser must be used. The 5th edition of the ECMA-262 standard defines a JSON.parse() method which only accepts JSON text, but does not evaluate script code. Until browsers implement the current ECMAScript version, you can use some of the alternatives listed on the JSON home page. The appropriately named json-sans-eval library is a useful alternative, and it even uses the same method signature as JSON.parse(). If you use a different parser, at least check the source code to see whether or not eval() is used.

There are some scenarios in which you cannot avoid using eval(). For example, JavaScript supports met
Truncated by Planet PHP, read more at the original (another 1322 bytes)
Speaking at PHPUK and Sogeti

Posted: December 11th, 2009, 3:04pm MST by Ian Barber

For anyone interested in such matters, I'll be speaking at a couple of events in February next year which could provide valuable Learning Experiences for your continual professional development!
First up on the 6th of February near Utrecht in the Netherlands is Sogeti Engineering World, where I'll be talking about document classification in PHP. This includes discussions of why you might want to classify things, why you'd do it in PHP, and then looks at algorithms including a Bayesian classifier, K-Nearest Neighbour and ID3 decision trees. There's some great talks on the schedule, including my main man Felix de Vliegher talking about gearman, and a whole bunch of other interesting stuff, some of which may contain Dutch. I'm quite looking forward to "Object Oriented Cobol" personally.
After that I'm speaking at the always lovely PHP UK Conference, in sunny London on the 26th of February. There I'll be talking integrating search engines into your applications, and we'll cover a bunch of interesting bits and pieces on how search works, and how you can provide better results than anyone (on your own site at least). The line up is top notch, with gurus abounding, including Lorenzo "Hollywood" Alberton talking about doing trendy things with databases, Lorna talking about webservices, the leads from Zend Framework and Symfony not talking about their frameworks, JRF talking about regex, Derick talking about D-bus, Stefan talking about patterns and Skoop talking about documentation.
Speaking at PHPUK

Posted: December 11th, 2009, 2:41am MST by Lorna Mitchell

I'm pleased to announce that this year I'll be speaking at PHPUK in London in February. I've attended this conference for the last three years, and attend its related user group, PHP London whenever I can find a reason to be in London on the right day. My talk this time is a brand new one, "Best Practices for Web Service Design", which covers the main points (and pitfalls!) of architecting a web service to be as robust and useful as possible. This is something I've been doing quite a bit of in my day job lately and I'm hoping to pass on some of what I've learned.

This conference is well-established and I've had a blast most years I've attended! Although their schedule isn't public yet (it will be soon), the other sessions I've heard about on the grapevine sound good. If you want to attend, the date is Friday 26th February and you can buy your tickets on their site. Let me know if I will see you there :)
Character sets vs. encodings

Posted: December 11th, 2009, 2:29am MST by Kore Nordmann

Todays PHP Advent article iterates the topic of character sets and encodings once more. While I welcome this in general, because each developer should have at least basic knowledge about this, I would like to clarify some points.
Switching from Google to Bing

Posted: December 11th, 2009, 1:47am MST by Evert Pot

For the same reasons as Mr. Asa Dotzler, I'm ditching Google search for Bing.

Especially after looking at "Google Dashboard", and seeing how much of their applications I'm using already, I figured it's probably not a bad idea to at least spread my personal information among a couple evil corporate entities rather than just one.

The first things I'm noticing about Bing is that it appears to give much higher precedence to recently updated pages. It also seems to adhere to the Accept-Language header, which means I don't have to weed through Korean interfaces to switch back to english.

If you don't hear back from me, I'm either a happy user or completely forgot and unknowingly switched back to google.
Learning From Other Communities

Posted: December 10th, 2009, 11:00pm MST by Brandon Savage

Last week, Aaron Brazell posted a blog entry about the state of the Wordpress and PHP communities. At the same time, Keith Casey was in Redmond, Washington, where he was experiencing the Microsoft Web Developer’s Conference. As so often seems to happen with “Aha!” moments, both men came to pretty much the same realization at the same time: the Wordpress and PHP communities need each other, but don’t do nearly enough to work with each other.

Keith made his point clear when I explained to him that I agreed with what Aaron was saying in his blog post, but that Wordpress supporting PHP 4 was Wordpress’ “fatal flaw.” In his…articulate way…he reminded me that Wordpress existed and flourished, in spite of our attempts to attack their support for PHP 4. Their use of PHP 4 was certainly not a fatal flaw, as much as our arrogance as a community seems to be.

The one thing I hate about Keith is that he has a tendency to be right. And he was right this time.

The reality is that you can’t separate the success of PHP from the success of other open source tools like Wordpress and Drupal. As they have flourished, so has PHP; the success of each is interconnected with the success of the others. Yet it seems that the PHP community is fond of attacking and demonizing these communities, which only serves to drive them away from the PHP language.

Wordpress and Drupal could exist independently of PHP, if PHP didn’t exist as a language. The need was there; they would have been written in Python or Ruby on Rails, or Fortran; the language is irrelevant; the need was paramount. The fact that they were written in PHP is an accident of history, not a divine destiny. They were written in a time before PHP was widely accepted. And they were written with the tools available at that time.

In short, we, as the PHP community, need to lay off. And we need to put up or shut up. Hate the fact that Wordpress still supports that “dead language” of PHP 4? Write a patch. Hate that Drupal’s UI would make a geek cry out in agony? Write a patch. These are open source projects; we each can look at the source and make them better. But we should never, ever attack these projects for not conforming to our standards. Especially if we’re not improving them.

And we need to be better about interfacing with the communities that surround these projects. Each has a robust community that doesn’t identify with PHP. They don’t understand PHP, and the reasons it works the way it does. Many of them blame PHP for the troubles of the product. We need to be proactive about reaching out to these groups, and interacting with them. We need to be receptive to their needs. And we need to work with them to improve PHP overall.
World of PHPCraft

Posted: December 10th, 2009, 10:00pm MST by PHP Advent

Dear Santa,

I’ve been a bad girl this year. I haven’t fixed bugs in my extensions. I’ve barely worked on PHP 6. I only attended a handful of conferences. And, my blogging’s been pretty gay. (I can make that joke; you can’t.) I can explain, though. I was working. Who am I kidding? I was saving orphans from a burning building, barefoot, in the snow, over broken glass. No, that’s overselling it. Fine, I got sucked into World of Warcraft (WoW).

Can I still have my Red Ryder BB gun? I promise not to shoot my eye out.
The world
Forgive my comparison, but I’ve noticed something while wandering around Azeroth and watching the guild: Programming — with PHP especially — is a little like a MMORPG.

I’m sure to suffer the slings and arrows of this outrageous analogy, but hear me out. How good is your code when you’re just starting out and reading the PHP.net tutorial for the first time? It’s crap. You’re a newb, a level 1 paladin with a wooden sword and a fear of bunnies. I hope I don’t belabor the metaphor, because it’ll get tiring fast, but each new programming challenge is a quest to gain experience points and develop your character (career).

Some of us level up slowly, slaying the placid demons of personal web sites while studying walkthroughs to see the pitfalls before they show up. Others charge straight into level 40 enterprise instances, finding themselves respawning in the graveyard of performance bottlenecks, security vulnerabilities, and empty mana potions. All of us learn, albeit at different rates and with different battle scars to show for it.

The ones who advance the quickest are the ones who learn from the more experienced, helpful players (developers) around them. There’s an unexpected non-competitive spirit in WoW1 which, I think, mirrors the PHP community. IRC channels on Freenode, EFnet, and nearly every other major network are a testament to the nature of PHP developers to want to help each other out. The massive amounts of effort continuously poured into the online manual — which is second to none — prove this isn’t just a half-hearted chat phenomenon.
The guild
At the center of this collection of aspiring artisans are the level 80s, DPS mages like Rasmus Lerdorf, Zeev Suraski, Andi Gutmans, Wez Furlong, Andrei Zmievski, and many others who’ve brought us some of PHP’s most useful features. These aren’t the only heroes, though. Other include Jani Taskinen (sniper), who’s been standing on the front lines of triage for as long as I can remember, the many healers who desperately try to keep PHP internals drama to a minimum, and the documentation folks — who I can’t find an analogy for — are part of the rich tapestry that makes the World of PHP so enrapturing. Personally, I always fancied myself a warlock — dark, arcane magicks and all that.

Characters enter this circle and leave it. Some just feed off of the generosity of those who contribute, and that’s okay. Some toss one contribution in and walk away. Some would like to lend their abilities, but are worried that they’ll just get in the way or won’t be able to keep up. It’s this last group that I want to reach out to, because there’s room in the PHP guild for all levels. Yeah, you might make some mistakes, but you’ll gain experience, and that’s what leveling up is all about.
Become a mage Subversion contains everything you need to know to get started with the PHP source code. There are articles on DevZone to give you a solid introduction to extension writing and maintenance, and follow-ups like the technical rants that I sometimes post on my blog — check out the right column, under favorites. If you’ve got a few bucks burning a hole in your pocket, you can tolerate my shameless
Truncated by Planet PHP, read more at the original (another 2081 bytes)
Oracle's plan to spend more money developing MySQL than Sun did

Posted: December 10th, 2009, 2:57pm MST by ThinkPHP /dev/blog - PHP

Today, I twittered with Matthew Aslett from 451 group and pointed him to "Project Peter" which lead to a blog post by him (see tweet).

There's an interesting statement in his blog entry:

[...] on the theory that Oracle will not invest in the ongoing development of MySQL, which is something it has publicly committed to doing.

He links to an ad by Oracle. Come on, do you really believe in everything that is stated in an ad by a company who initiated a merger and wants to convince the customers of the company to acquire that the merger is a good thing?

Get a life.
New Zend_Feed_Writer Component And Zend_Feed_Reader Enhancements (ZF 1.10)

Posted: December 10th, 2009, 2:26pm MST by Pádraic Brady

Zend_Feed has always been a thorn in my side, so I'm pretty satisfied with myself (egomaniac!) now that I am building up what I like to consider a pretty good set of components for consuming and creating feeds without needing a hastily kicked together DIY processor on top of Zend_Feed.

For those still (for mysterious reasons) unfamiliar with the new feed components, they are an attempt to bring simplicity to a area of programming that's often messy. Zend_Feed, which has been with us since the Zend Framework's early versions, was one such attempt which presented a simpler interface to feed documents than the incumbent PHP DOM or SimpleXML. However, what it offered in simplicity it gained by sacrificing any understanding of the underlying feed syntax. The result was that Zend_Feed was useful for quick and easy scripting, but posed a challenge when applied to anything else.

Zend_Feed_Reader was an attempt to bring more sanity to the area. It largely bypassed the issue with simple access by standardising on a getter style API. So extracting a feed's title was achieved using the Zend_Feed_Reader_FeedInterface::getTitle() method. No trick curly brackets or simulated methods here - just call the method and get the data. To perform this slice of magic, Zend_Feed_Reader returned to the PHP DOM and with the assistance of a lot of unit tests (800+) attached a programmatic understanding of all the relevant feed specifications, from RSS 2.0 to Atom 1.0 and pretty much any earlier iteration of each including RSS 1.0/RDF. Now, regardless of feed type, you could call getTitle() and you would get a "title". It wouldn't matter if the title were actually a "foobar" element in the "wonderland" namespace of RSS 3.45.6.12 (that's fictional before you get exited ). Point was, it would search the feed for anything remotely relevant to return as a title.

This all worked great but, as I explain below, it was always going to need some fine tuning. Nothing amazingly complicated as it turns out, but the getter style API can be long winder. Return types varied between objects, arrays and strings. Not everything commonly used from a feed was supported. A few other small niggles. These are the sort of things I aim to improve in 1.10 (which we will hear more of in the weeks to come).

Zend_Feed_Writer

The new kid on the block, to be added in Zend Framework 1.10, is Zend_Feed_Writer. A bit like the older Zend_Feed_Builder classes, its purpose is to generate Atom 1.0 and RSS 2.0 feeds. The difference is that, like its sibling Zend_Feed_Reader, it is standards aware and operates entirely using PHP's DOM.

Why another feed generation component? The problem is somewhat similar to the one that Zend_Feed_Reader solved. Generating an RSS and Atom feed is far more involved than sticking a bunch of elements together - each standard has its quirks, its unique features, and its own set of best practices outside of the standards. Using Zend_Feed_Builder, you relied on two things - repetition and validation. Moving away from its core focus required more work, even to the extent of subclassing, and you were always at the mercy of misinterpreting a standard.

Zend_Feed_Writer builds on the simple API of Zend_Feed_Reader (using setters rather than getters) and the concept of having the component understand the standards (so you don't have to). The component is split across two class types - a base data container to store feed data and ensure it conforms to expected formats, and a renderer to actually generate the feeds and provide feedback on standards adherence. For example, in Atom 1.0 the omission of a title will generate an exception - a title is an obligatory element under the Atom 1.0 standard. While this could be interpreted as a nuisance, the fact is that an invalid Atom 1.0 feed is worse than useless. Better you are irritated now, than later when an online validator calls you rude names .

The net result of this approach is that you focus on the data, and let Zend_Feed_Writer worry about what elements and attributes to use. It should, in theory (always a grand thing), be impossible for Zend_Feed_Writer to produce an invalid feed.

Of course, we also throw in the concept of Extensions, as with Zend_Feed_Reader, allowing you to add support for RSS and Atom extensions more dynamically without the need for subclassing or API arm twisting.

If you go looking for Zend_Feed_Writer, it's currently in chunks in the Incubator. I should have it entirely integrated and functional over the weekend. You can howe
Truncated by Planet PHP, read more at the original (another 3945 bytes)
Real-time ZF Monitoring via Zend Server

Posted: December 10th, 2009, 1:51pm MST by Matthew Weier O'Phinney

When keeping tabs on your ZF applications, it's often difficult to separate application errors from general PHP errors, and if you aggregate them in the same location as your web server errors, this can become more difficult still.

Additionally, PHP's error reporting doesn't provide a ton of context, even when reporting uncaught exceptions -- typically you'll only get a cryptic exception message, and what file and line emitted it.

Zend Server's Monitor extension has some capabilities for providing more context, and does much of this by default: request and environment settings available when the error was logged, the function name and arguments provided, and a full backtrace are available for you to inspect. Additionally, the Monitor extension includes an API that allows you to trigger custom Monitor events, and you can provide additional context when doing so -- such as passing objects or arrays that may help provide context when debugging.

Continue reading "Real-time ZF Monitoring via Zend Server"
PHP Advent, xUnit testing with phpt

Posted: December 10th, 2009, 11:13am MST by Greg Beaver

Yesterday, the article I wrote for PHP Advent went live at http://phpadvent.org/2009/testing-with-phpt-and-xunit-by-greg-beaver.

This is a simple, and potentially controversial article about what makes a good testing framework, and an alternative to PHPUnit for PHP users. If you have any feedback, feel free to post comments here.
Microsoft Web Developer Summit

Posted: December 10th, 2009, 8:24am MST by Echolibre

This year, David Coallier and my self were invited to attend the annual Microsoft Web Developers Summit, or WDS for short. For David this was his first time there but for me it was a 3rd year running, and as ever I was excited like a kid in a candy shop.

What is WDS? In short, it’s a summit where Microsoft invites a selective few (roughly 25 people) from the PHP community, during which they basically ask the attendees questions, show case a few new features to get feedback on and utilize the time to help figure out how Microsoft can better serve the PHP community at large. These people tend to be various leaders of either community sites or big open source projects and will thus have a lot of insight into how people use their software on Microsoft platforms and the problems they have.

David Strauss from Drupal was kind enough to compile a Twitter list of the people attending, anyway most of them: [twitter.com] this includes various Microsoft people attending.

Before anyone starts going crazy over the fact they think Microsoft are “evil” and all that non-sense, well just don’t go there, I have covered this before in my other WDS wrap ups and so have other people! Microsoft is trying to work with us to make it a better platform to work with, for everyone. This includes making PHP faster, more stable and secure on Windows, among other things.
I think that’s a great thing that a big company like that is prepared to listen to the community and work with them - And as such we should respect them and their intention, they have yet to show any “bad” behavior. I hope that silences the trolls

The event spanned 1st of Dec till 3rd Dec with a pre event meal on the 30th of Nov. My flight to the event took grand total of 13 hours flying! and so I barely managed to get to the event meal on the 30th to catch up with friends and have some very good food - During which I got the news that David got stuck in New York for the night and would be effectively be missing the first day of talks, so first casualty of the conference and it hadn’t even started!

Before I continue on listing up some of the sessions and my impression of them etc. A bit of a warning beforehand.
Some sessions caught my attention more than others, others I couldn’t attend since I was out in the hallway having very useful discussions with various Microsoft employees and so on, just a small disclaimer.
Ben Ramsey made excellent notes, as always, which can be found here: [tools.benramsey.com]
So I will have varying degree of depth, if any, on session. Also, I will point out bits I did not like about a particular subject as there is no point in praising things I don’t agree with
OSTC - What are they doing with PHP
The first session of the day was given by Garrett Serrack, a Microsoft employee and one of the contributor to recent PHP Windows improvements. This talk was on application installation workflow on Windows vs. Linux and how that affects PHP and indeed other open source projects.
The talk was very unbias side by side comparison, in fact if anything Linux was touted at better at this.

He went over things like how Linux has a good concept of shared libraries, dependency control, easy installation / upgrade process and many other things while Windows application usually have to bundle their dependencies, often are horribly out of date but at the same time pointed out that many applications on Windows will in reality trick itself into thinking it’s running on Linux (multi platform applications) and thus miss out on very good compiling tools, WinQual (error reporting tool) and many other things (see Ben notes).

With the previous things in mind Garrett introduced us to some very interesting work that he’s been heading up internally at OSTC / Microsoft that focuses on making it easier for ap
Truncated by Planet PHP, read more at the original (another 17362 bytes)
Paging and Sorting Data with Zend Framework, Doctrine and PEAR (part 1)

Posted: December 10th, 2009, 8:21am MST by Zend Developer Zone

This article will introduce you to one component that helps you solve the problem of presenting large data sets in a manageable fashion, Zend_Paginator, which is a part of the Zend Framework. However, open source is all about choice and so, a followup article will also discuss two other popular components, PEAR Pager and Doctrine Pager. Come on in, and let’s get started.
PHP Advent 2009: Developers Versus Designers

Posted: December 10th, 2009, 8:04am MST by Echolibre

Helgi, our lead on R&D has just been published on this years PHP Advent. In this article he looks at how web designers and developers currently interact, and offers some ways to improve the web design and development process.

The full post can be found here.
Character Sets: Garbage In, Garbage Out

Posted: December 9th, 2009, 10:00pm MST by PHP Advent

I recently checked on a project, because the developers were having some problems with strange characters displaying on the page. In particular, a number of accented characters were showing up as the Unicode replacement character (). How sad.

A bit of research revealed that their pages were being served in UTF-8, but the data store was using ISO-8859-1. A few patches were applied, and the string in question was fixed. In order to manage character sets correctly, your entire application — from input to database to output — needs to be configured correctly. This can be quite a challenge, and in this article I will introduce some of the problems and provide a few solutions.
Character sets
Character sets are basically sets of symbols that computers use to map numbers to the glyphs you see. You can think of them as tables that contain all of the glyphs you might need — not only letters, but also punctuation, symbols, space, backspace, &c. Here’s an example character set I’ll call Paul’s First Character Set:

0 1 2 3 4 5 6 7 8 9
0 a b c d e f g h i j
1 k l m n o p q r s t
2 u v w x y z A B C D
3 E F G H I J K L M N
4 O P Q R S T U V W X
5 Y Z 0 1 2 3 4 5 6 7
To find a character, just look it up in the chart, across then down. For example, h is 07, and i is 08. If you want to look up a word — Hello, for example — look up each character in the chart — 33 04 11 11 14. Of course, there isn’t just one character set in the world; there are quite a few. Here’s another example character set I’ll call Paul’s Second Character Set:

0 1 2 3 4 5 6 7 8 9
0 0 1 2 3 4 5 6 7 8 9
1 A B C D E F G H I J
2 K L M N O P Q R S T
3 U V W X Y Z a b c d
4 e f g h i j k l m n
5 o p q r s t u v w x
In this new character set, Hello is 17 40 47 47 50. You might already be able to imagine how problems can arise. If your browser tries to display data in the wrong character set, it ends up looking all garbled. Some characters may look right, while others look broken. The reason that garbled text is often mostly right is that many Western character sets put the standard English alphabet — as well as numbers and a few other things — in the same place. (My two fictional examples don’t do this.) So, those characters appear to work fine, but less common characters don’t.

This also reveals another problem. If someone simply tells you that a message is 44 04 02 17 04 19 without identifying the character set, you have a problem. You could decode the message twice and see what you come up with — in this case Secret and i32H4J — then pick whichever one looks best. One is an English word that contextually makes sense, the other could quite conceivably be a password. In the presence of other text you could probably make a decision, but it’s a mess, even when only dealing with two fictional character sets.

In order to avoid generating garbage, character sets must be considered at every step.

"/>
Truncated by Planet PHP, read more at the original (another 5617 bytes)
Heads up, PHP 5.3's Module API is not Backward Compatible

Posted: December 9th, 2009, 2:46pm MST by Sara Golemon

Unlike PHP, C generally resolves function calls at compile time. When you introduce dynamically loadable shared objects, the ability to know their exact address ahead of time goes out the window and you have to fall back on link-time resolution (or in some cases, call-time lazy resolution, but we'll pretend that doesn't exist for now). It handles variables in much the same way; Resolve at compile-time if possible, link-time if not. As you can guess link-time resolution is slower, but necessary.

One of the things that makes this unnecessarily slower is libraries which export a lot of symbols which aren't needed outside of the file they were defined in. More symbols means a bigger lookup table, means more time spent finding that needle in a haystack. In order to balance the need for link-time (or runtime) lookup, C supports the static keyword. This tells the compiler to not bother putting this item into the symbol table, thus keeping it's size down. Since the number of symbols that actually need to be exported tends to be well less than half of the total, this can make for a substantial difference.

PHP Extension authors are lazy
If you look at the PHP source tree, or even the "recommended" skeleton found in ext_skel, you'll notice that few (if any) symbols are flagged as static even though they're only referenced in the file they're defined in. For example:

Continue reading "Heads up, PHP 5.3's Module API is not Backward Compatible"
Presentations Uploaded

Posted: December 9th, 2009, 1:58pm MST by Eli White

A
Funemployment Part 3: Back to work

Posted: December 9th, 2009, 1:13pm MST by Scott MacVicar

This is probably the final post in my adventure since leaving Jelsoft in June, I'm pleased to announce to those who aren't in my inner circle that I'll be joining Facebook as an Open Source Developer Advocate (a position which combines engineering and evangelism).
Now for those wondering what exactly that means, I'll continue contributing to the PHP internals along with this I'll also be working on some Facebook developed PHP infrastructure technologies and tools and generally representing Facebook within the PHP community.
It's no secret that Facebook use PHP to power their site, they're probably one of it's biggest users and I'm really excited to work there. With all the smart people there one should expect some pretty amazing things for PHP in the coming year.
On a personal note it means that I'm moving from England to America, specifically San Francisco. I've already put this into motion and hope to have it completed at some point in January.
2009 has been a popular year for members of the PHP community to become funemployed, some of my current "colleagues" include Andrei Zmievski, Brandon Savage, Cal Evans, Chris Shiflett, Derick Rethans, Eli White, Nick Sloan and Sean Coates.
web2project v1.2 Release Notes

Posted: December 9th, 2009, 9:20am MST by Keith Casey
As of this morning - 09 December 2009 - web2project v1.2 is live!

While there is not a huge amount of new user-facing functionality, the sheer number of fixes and amount of cleanup is staggering. Since the v1.1 release in September:
- Pedro made some major updates to the iCal handling which added the Task Description and Links to the iCal entry for one-stop shop of information.
- Pedro also added the Brazilian Portuguese translation to core. Rumor has it that there's an Italian version on the way next.
- Added some creative caching and pre-calculations to the Task Count, Total Hours, Percent Complete, and Worked Hours to speed up the system significantly.
- Changed the PDF creation for reports to use a randomly generated filename.
- Created a GanttRenderer class to centralize the Gantt chart creation with the goal of standardizing behavior and eventually replacing jpGraph completely.
- We've created strong object validation that happens on save. Whenever you attempt to save a Project, Company, Link, etc, the system makes sure the required fields are actually filled in. Realistically, some would claim that the Javascript already did some of this on the front end, but that could be bypassed... and we needed something more solid for the API.
- The method signatures - specifically for store(), delete(), check(), and a few other calls - have been standardized. This by itself isn't incredibly useful yet... but we needed something more solid for the API.
- We did some major refactoring of the core modules based on a code review we received at CodeWorks 2009. Sebastian Bergmann (phpUnit creator), Stefan Priebsch (OO guru), and Arne Blankerts (security guru) were kind enought to take a look at the code and shared feedback on a number of architectural concepts, OO improvements, and overall code clarity. These changes aren't immediately visible to end users but we needed something more solid for the API.
- Finally, Trevor and I (mostly him) added about 40 Unit Tests since the v1.1 release. While we don't distribute them in the release - you have to get them via SVN - they're useful for testing against the growing API.
Are you detecting the pattern here?

Further, we closed nearly 50 items ranging from 8 crash-level bugs to 20 minor bugs to 4 pre-defined feature requests. Of course, that only covers the things logged as issues. If you want to see everything of interest, check out the web2project v1.2 Release Notes on our wiki.

In accordance with our quarterly release schedule, this is our final release for 2009. The next release will be 1.3 in March 2010 with v2.0 scheduled for June 2010.
Microsoft is and Microsoft does

Posted: December 9th, 2009, 8:15am MST by Marco Tabini

Elephpant does Redmond!

Every year, Microsoft organizes a small event, called Web Development Summit, to which they invite a few members of the PHP community. The WDS is a good opportunity to exchange information with Microsoft, learn about new products they are working on and generally catch up with a number of friends from the community. Several others have already posted their impressions of this year’s meeting, to which I add my own.
Good stuff
Microsoft’s attitude towards open-source has changed considerably over the last few years—a fact that is finally starting to permeate through its historical insistence on vertical integration in favour of more willingness to integrate its products with other platforms. At the end of the day, Microsoft has realized that the key to improving adoption of Windows Server—and, more importantly, stemming the migration away from it—is to play nice with other technologies.

More importantly (at least from my perspective), more people within Microsoft are finally realizing that working within the open-source world requires a shift in the way they establish relationships and position themselves. There are some within the company that have realized this a long time ago and have, as a result, established some strong ties with the PHP community; it’s good to see that this frame of mind is finally permeating through the organization and changing the way it approaches its dealings with us.

The willingness to look beyond its own walls is also making it possible for Microsoft to come up with some truly innovative and useful products. One of the most impressive ones that I saw during the WDS is Expression Web’s SuperPreview¹, which truly simplifies the process of side-by-side comparison between browsers, including multiple versions of Internet Explorer. I was teaching a seminar of html and CSS at a client just yesterday and had an opportunity to show this product to them. It was received with a chorus of wows, followed by significant gnashing of teeth when they realized that their organization’s default Windows install wouldn’t support it.

I also truly appreciated the fact that the evangelists who were at WDS took the time to really drive home the fact that “Microsoft” is not one entity, but, rather, a conglomerate of many different divisions and people—and, therefore, of many different opinions and strategic views that are bound, at times, to be in conflict with one another. To anyone who has had the opportunity to work for (or with) a large organization, this is an obvious fact—but many who are used to smaller work environments don’t fully understand the complexities of interacting with such a large base of coworkers, each with their own priorities and strategies (I always chuckle when I hear someone start a sentence with “You Microsoft guys need to…”).

Finally, I had the pleasure of leading a ten-minute discussion on the status of the PHP community, which, judging from the reactions that it received, was a cathartic experience for some people. I took advantage of the unusual convergence of members from various PHP-related groups, including Drupal, Joomla and WordPress, to point out that it might be opportune for all of these communities to intermingle and work together with the “core” PHP community towards common goals to ensure a good exchange of ideas. After all, what comes down the pipe from core will eventually be of benefit (or not) to anyone whose application lives downstream, so a feedback channel in the form of conversations and participation is going to be essential to the health of the entire PHP ecosystem².
Not so good stuff
The whole point of the WDS was to give Microsoft an opportunity to present their current ideas to a small focus group so that they would have an opportunity to revise and focus their message before presenting it to the world at large; therefore, it would be inappropriate for me to comment specifically on the areas for improvement that we saw.

Suffice it to say that some divisions inside Microsoft are still finding it difficult to let go of the no longer appropriate view of open-source communities are a ragtag group of renegades intent on not-so-subtly subverting the commercial software landscape. By my own guesstimate-based account, the 40 or so people at WDS directly or indirectly represented at
Truncated by Planet PHP, read more at the original (another 1754 bytes)
State of PHP and Architecture

Posted: December 9th, 2009, 7:05am MST by ThinkPHP /dev/blog - PHP

What is the state of the art of PHP Architecture? Our CTO, Johann-Peter Hartmann, wants to know about it. Furthermore we want to know about the relevance of business goals during architecture creation. It would be great if you could help us filling out this survey, of course we'll publish it later. Please answer questions based on real-world experience and not what you would like to see. :-)

The survey can be found here.

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x

Advisory 03/2009: Piwik Cookie unserialize() Vulnerability

Posted: December 9th, 2009, 5:50am MST by Stefan Esser

I released an important advisory about a remotely exploitable unserialize() vulnerability in Piwik today.

                         SektionEins GmbH
                        www.sektioneins.de

                     -= Security  Advisory =-

     Advisory: Piwik Cookie Unserialize() Vulnerability
 Release Date: 2009/12/09
Last Modified: 2009/12/09
       Author: Stefan Esser [stefan.esser[at]sektioneins.de]

  Application: Piwik <= 0.4.5
     Severity: Piwik unserializes() user input which allows an attacker
               to send a carefully crafted cookie that when unserialized
               utilizes Piwik's classes to upload arbitrary files or
               execute arbitrary PHP code
         Risk: Critical
Vendor Status: Piwik 0.5.0 was released which fixes this vulnerability
    Reference: advisory-032009-piwik-cookie-unserialize-vulnerability
               RSS09-WebApplicationFirewallBypassesAndPHPExploits.pdf
               POC2009-ShockingNewsInPHPExploitation.pdf           

Overview:

  Quote from [www.piwik.org]   "Piwik is a downloadable, open source (GPL licensed) web analytics
   software program. It provides you with detailed real time reports
   on your website visitors: the search engines and keywords they
   used, the language they speak, your popular pages… and so much more.

   Piwik aims to be an open source alternative to Google Analytics."

  Piwik recently became sourceforge project of the month and won the
  Infoworld Bossie Award for best open source enterprise software which
  made it quite popular. Therefore Piwik is nowadays installed on many
  high profile websites like: banking websites, political party websites,
  gaming websites, blogs and even security company websites.

  During our research in unserialize() vulnerabilities it was discovered
  that Piwik unserializes data from the user supplied cookie. By
  unserializing some of Piwik's objects it is possible to write
  arbitrary files to writable locations on the webserver which
  can be used to upload e.g. PHP files to writable directories
  within the webserver's document root which usually exist in a
  standard Piwik installation. In newer versions of Piwik it is
  also possible to execute arbitrary PHP code directly.

  Combined with the interruption vulnerability exploits demonstrated
  by SektionEins at Syscan and Blackhat it is possible to disable
  all internal PHP security protections and execute arbitrary code
  e.g. local kernel exploits to become root.

Details:

  SektionEins recently demonstrated how it is sometimes possible
  to execute arbitrary PHP code in an application using unserialize()
  on user supplied data. In detail various exploits were shown that
  work against all Zend Framework based applications that unserialize()
  user input. Part of this research was to find popular PHP open
  source applications that are vulnerable to this.

  During our search it was discovered that Piwik does unserialize()
  data from the cookie and uses parts of the Zend Framework:

  protected function loadContentFromCookie()
  {
    $cookieStr = $_COOKIE[$this->name];
    $values = explode( self::VALUE_SEPARATOR, $cookieStr);
    foreach($values as $nameValue)
    {
      $equalPos = strpos($nameValue, '=');
      $varName = substr($nameValue,0,$equalPos);
      $varValue = substr($nameValue,$equalPos+1);

      // no numeric value are base64 encoded so we need to decode them
      if(!is_numeric($varValue))
      {
        $varValue = base64_decode($varValue);

        // some of the values may be serialized array so we try to...
        if( ($arrayValue = @unserialize($varValue)) !== false
            // we set the unserialized version only for arrays...
            && is_array($arrayValue)
            )
        {
          $varValue = $arrayValue;
        }
      }
      $this->set($varName, $varValue);
    }
  }

  While this allows to unserialize() user input the previously
  demonstrated exploits will not work on Piwik because only parts of
  the Zend Framework are shipped with the Piwik source code. Because
  of this we had to evaluate if Piwik's own classes can be utilized
  in exploits.

  When trying to exploit an unserialize() vulnerability in a PHP
  application the first step is to enumerate the objects that contain
  __wakeup() or __destruct() methods and read their code to analyze if
  these methods are doing something interesting.

  When looking at the Piwik source code one particular class can be
  found that allows writing arbitrary configuration files to the
  webserver. This class is called Piwik_Config and contains the
  following code.

  function __destruct()

Truncated by Planet PHP, read more at the original (another 11020 bytes)

Text Generation

Posted: December 9th, 2009, 3:00am MST by Ian Barber

After a rather technical post last week, something a bit lighter. Text and language generation is a fun topic with applications that run from randomly generating scientific papers for conferences, to the practical tasks of generating speech and automated responses. In this post we'll look at how we can generate some nonsense text based on existing documents, which isn't on the overly practical side, though it can make a fun change from Lorem Ipsum for holding copy. The code is throughout, but you can also grab the lot in a zip. The basic idea is extract a set of probabilities of certain words appearing, and then generate a document based on this probability model. We'll be using pairs of words as our statistical unit of choice, making this a two-word language model. This is really using Markov chain by modelling, for any given word in the text, what the probabilities are of moving to another word. You can imagine a Markov chain as a big table of states. By reading down each column you can see, for the state represented by that column, what the probability is of moving to any of the other states. This means that if we generate text based on walking through this table then much like the real word it's hard to predict the exact outcome, but easy to predict the statistical properties. The way we do this is really pretty simple: tokenise the text, then keep a count for each pair of tokens. For each word, we normalise the counts of the words that follow it to get a probability of moving from the first word to each of the second words. For generating the text itself we just choose a random first word, get the list of paired words and choose a random second word. We keep outputting them until we hit our word limit. In both these cases "random" means a random point 0-1, which we look up in the distribution to find the word - so more common words are more likely to come up. PHP Text Generator The class below does exactly this. When given a file to generate text based from, as an argument to the learn function, it first tokenises the file then stores pairs in an array of [first word][second word]. Each pair is associated with a count, which is then normalised between 0 and 1 for each set - so for any given word we have the probability of moving to each of it's possible pairings, with the possibility of going to any words not seen paired implicitly being zero. This is accompanied by an array, rootScores, for all the first words - so that for the start of the algorithm or if we hit a sentence ender like '.', we can choose a new word to start generating from. The generate function performs the random walk through the probabilities. At each step it tries to pick a word from the pairs for the current word, and it tries to ensure that that word isn't the same as the one it started with, to avoid very small loops. If the current word doesn't have any pairs, or isn't set (in the case of the first word or sentence enders), then it picks a starting word from rootScores. The actual picking is done by the pick function, which just generates a random float between 0 and 1 and returns the corresponding item from the passed array. <?php
class LangGen {
protected $model = array();
protected $rootScores = array();
protected $sentenceEnd = array('.', '!', '?');
protected $joinSentence = array(',', ':', ';');

public function learn
Truncated by Planet PHP, read more at the original (another 46329 bytes)
Why Tracking Bugs In Personal Projects Matters

Posted: December 8th, 2009, 11:00pm MST by Brandon Savage

A lot of time and effort goes into designing processes for development projects when the projects are professional or work-related projects. We spend hours investing in version control, bug tracking, specification design, and process.

But what about our own personal projects, that we do either for money or for fun? Too often, it seems like these development practices are abandoned, especially with regards to the use of a bug tracker. I know I have personally been guilty of failing to use a bug tracker, even though I use things like Subversion and develop specifications. It’s easy to forget, but important to remember. Here are five reasons why our personal projects should utilize a bug tracker.

These are personal anecdotes from coming back into the “bug tracking fold” after being away for a while.

1. Our minds are imperfect repositories of information.
As we work through personal projects, there’s often a much more intimate relationship between ourselves and the product. This often leads to the feeling that bugs and necessary features no longer need to be logged in a bug tracker because we’ll remember them. The reality of the situation is that we cannot remember everything we need to remember. Details will be forgotten, unless we use some sort of a system to remember them later on.

2. Bad development practices can form.
When we opt not to use a bug tracker in our own personal projects, we get into the habit of writing code without one. This is a poor habit to get into, because it is one that will affect us when we go to our jobs. The truth is that habits are easy to form, and conflicting habits will always be resolved to the most lazy habit, because we’re human.

3. It makes it harder to force ourselves to use bug trackers for private paying clients.
Most developers I know have a few private clients that they work with who are not connected to their employer. It is crucial that we employ the same level of process and use the same development practices with our private clients as our employer’s clients, because these clients are still paying for our services and deserve our best work. The problem is that if we have let ourselves slip on the personal projects, we will find it increasingly hard to keep bugs filed for private clients. This will lead to a lower quality product, which is less than optimal.

4. Predicting time to completion becomes more difficult.
When you’re at work, it’s easy to plug on and complete a project – it’s what you’re paid to do. But at home, for personal projects, it’s much harder to plug along without some assurance that the project is nearing completion. Having a task tracker lets you see the things that have been done, making personal projects easier to manage and making it easier to see how long it will take to finish something (which is a reward in itself).

5. Seeing progress being made is that much more difficult.
Along with predicting when it will be finished, using a bug tracker also makes it possible to see how far along you are in a project. I know that when I create tickets for everything in a project, I can easily feel good that I closed six or seven of them; I feel like I’m making progress and I have statistics to show for it.
Game of life with checkboxes

Posted: December 8th, 2009, 10:05pm MST by Evert Pot

I needed to kill a little bit of time, so I decided to write Conway's Game of Life in html.

Try it!
Progress on un-informed.org

Posted: December 8th, 2009, 12:07pm MST by Lukas Smith

I mentioned un-informed.org twice before in this blog. In short we want to make UN resolutions for accessible to the world. Last week I went to Helsinki for a short but very productive meeting with many people from the MCM team, the people behind the un-informed.org project. I showed them the current state of development on the backend. Thanks to Dennis we already have a more or less working Excel import, so that we could look at things with some real world data (note that in absence of a real database the team is currently using Excelsheets). The result of the meeting is that we now have finalized the requirements for a first version of the backend which we hope to complete by March 2010. Since we are hoping that additional developers will join us this month, we have a plan A for this case and a plan B if we remain a two man IT team (Dennis and myself).

The next phase will be starting a symfony 1.4 app from scratch. We will however base this work on the current database schema which needs to be updated with the final requirements. I also hope that we can update the Excel import accordingly this month.

After this we will see if additional developers are joining our effort and decide on if we should work towards plan A or plan B. The plan B being essentially that we will keep using the Excelsheets for everything they currently support and only adding admintools for things not yet supported there. Plan A would be a full migration away from the Excelsheets with an importer to migrate the current data into the system.

So as you might have guessed by now, a large reason for this blog post is to find additional developers to help out. We need someone to help out on the UI, but also people implementing the server side modules. Ideally people could provide an average of 1 days worth of time per week for the next few months.

If you are into social network and/or semantic web stuff, there is also another project in the early planning stages. Currently Drupal and/or Semantic Media Wiki seem the most promising platforms there. So if you have expertise in either of these platforms and are willing to help please also do not hesitate to contact me.

As a side note, I am really quite saddened that all efforts to find professors willing to cooperate with these students have failed so far. I do not understand why professors think it makes more sense for comp-sci students to develop throw applications instead of taking up the opportunity to work on a real project. Sure there are some risks involved, but the rewards are too great to let it pass. I think that universities should really strive to engage inter-department cooperation. This will ensure that students are more motivated, learn how to apply their theoretical knowledge and also make friends in other departments. Especially the last point could help foster so many ideas that currently fall flat because comp-sci students only know comp-sci students, business students don't know comp-sci students, physics students don't know .. etc.
Installing PHP 5.3.1 On Ubuntu 9.10 (Karmic Koala) With aptitude/apt-get

Posted: December 8th, 2009, 9:16am MST by Pádraic Brady

As there was some exclaimation marks on Twitter about this, here's a quick article on installing PHP 5.3.1 on Ubuntu 9.10 using aptitude or apt-get. I use aptitude primarily, but the installation uses normal .deb files.

Since Ubuntu will not officially adopt PHP 5.3 until next April, the PHP 5.3 debs I use are pulled from the Dotdeb Debian "Lenny" repositories. These are perfectly compatible with Ubtuntu 9.10 and only require the manual installation of two extra dependencies which Ubuntu cannot resolve itself.

We'll start with the obvious: adding the Dotdeb repos to your Ubuntu package sources list.

sudo nano /etc/apt/sources.list

Add the following entries:

# PHP 5.3 Dotdeb Sources
deb [php53.dotdeb.org] stable all
deb-src [php53.dotdeb.org] stable all

This will allow you to update to PHP 5.3.1 but we also need to resolve two other minor issues or we will get a lot of errors and a possibly messed up PHP system. PHP 5.3 requires two additional libraries, libicu and libkrb, which Ubuntu will not resolve properly. So we should install them manually. You should download the relevant debs for your system, here I use the i386 variants. You can substitute "amd64" for "i386" if you run a 64 bit system.

[us.archive.ubuntu.com]
[us.archive.ubuntu.com]

Installing these manually is simple, for example:

sudo dpkg -i libkrb53_1.6.dfsg.4~beta1-5ubuntu2_i386.deb
sudo dpkg -i libicu38_3.8-6ubuntu0.2_i386.deb

Once the two libraries are installed, the rest can be performed through aptitude or apt-get. Using aptitude:

sudo aptitude update
sudo aptitude safe-upgrade

You will be warned about installing unauthenticated packages since these are not Ubuntu sourced. Once you've confirmed this, the relevant PHP packages will be downloaded including, of course, the updated Apache 2 mods.

If you are not upgrading but installing from scratch, you can use "aptitude search" and select which package you wish to install as normal.

Once installation is underway you may be asked to replace custom .ini config files. Afterwards you can start performing any necessary cleanup. For example, some config files may require editing - e.g. setting up xdebug as the zend extension. Remember that the extension directory will be different than your PHP 5.2 path. The dotdeb packages I used also had a minor configuration warning over incorrect commenting in the default config files (a minor annoyance but easy to fix - remove the comments).

The rest should be plain sailing!
Dwoo is better than Twig

Posted: December 8th, 2009, 1:58am MST by Jordi Boggiano

It's lame catchy title day, a more appropriate one would be "Think for yourself", but I want to get my point across.

This is a general purpose idea of course, I don't think there is any case in your life where you shouldn't think for yourself, but this particular post is about programming.

I just read someone (and I won't name names, it's not relevant) that was pondering using Dwoo or Twig in his CMS, who ended up picking Twig because, and I quote: "but twig says they're better than dwoo so ...". Now I sincerely couldn't care less if someone decides to use something else over Dwoo - which I'm working on in case you wouldn't know. It's your own choice, and even I wouldn't say Dwoo is the best choice for every damned purpose out there.

What bothers me though, is that obviously the guy read Fabien Potencier's article about php template engines, which was obviously not so much of an objective post, but that has already been discussed so let's not go to deep into it. Anyway, the guy most likely read it, and all it says about Dwoo to dismiss it is "Unfortunately, Dwoo has no sandbox feature and its core is not flexible enough". So.. out of this most enlightening comment, you decide to trust Fabien and just assume Twig is better? I just don't get it.

So again, please, just think for yourself.
BrandonSavage.net Code of Conduct When Commenting

Posted: December 7th, 2009, 11:00pm MST by Brandon Savage

Last month was a record month, fueled by a front-page story at Reddit. This blog had 27,663 unique visitors with 52,343 visits and 125,164 page views. That’s an astounding amount of support from the PHP community and the programming community at large. Thank you. I’m overwhelmed, and excited that this blog has the ability to reach large numbers of people. I enjoy writing, and I enjoy discussing programming best practices, as well as talking about the things that matter to PHPers around the globe.

With this infusion of readers, a number of issues have begun to surface related to the comments, and particularly, the appropriateness of some users’ comments. While many of these comments are left in moderation, and never reach the end user, I believe it is crucial that each and every comment be beneficial, useful, and appropriate. Thus, it is necessary to lay down the criteria I will use to judge the worthiness of a comment before it is approved, or the worth of a comment if it is posted without moderation.

This is in no way an attempt to censor the comments posted here; they are a crucial component of the discussion. It is important to remember that there are no rights when it comes to commenting on a private blog; however, I am committed to honest discussion and debate. This code is designed to encourage that, while clarifying the boundaries of what is acceptable.

1. This blog is about PHP.
Each post here, for the most part, is about PHP (with few exceptions). It is my goal to provide high-quality content about developing PHP, and each post is designed to do just that.

Thus, it is not really alright for people to post comments along the lines of “PHP sucks for this” or comments about why PHP is a poor language choice for whatever it is that I’m writing about. It is alright to discuss how it is done in other languages – provided the discussion enhances everyone’s understanding of the points raised in the blog post. This blog is an inappropriate place to debate whether or not PHP is better than Rails or Python; that discussion has its place elsewhere.

2. This blog is in English.
I’m proud of the fact that readers from around the world come here to read the entries that are posted. I recognize that while PHP may be language-agnostic, others may have a preferred language, and may not be the most competent in English. That said, because this blog is in English, the comments must also be in English. Comments in other languages are not helpful to those that do speak English (which is the vast majority of visitors here).

I have already licensed my content for reproduction in other languages, and you are free to translate it into your language and publish it for discussion in that language. But comments made here must be in English.

For that matter, links posted must also be in English, as must names (no Chinese characters, please; they’re often captured by the spam filter anyway).

3. The anonymous comments feature is disabled for a reason.
I have staked my reputation to what I write here. My reputation lives or dies by my accuracy, my poise, and my ability to generate excellent content three times a week. When I write something, I stand by it; this is because I have to, not always because I want to (and sometimes I write things that are incorrect and have to eat some crow).

With that said, I think it creates a double standard if people try and comment without being linked to their words. Since most comments try and add value to the discussion, it’s important for people to be able to judge credibility. Anonymous comments don’t allow people to determine this credibility.

If I can’t identify you, then your comment stands almost no chance of being approved. This means that if your email address is clearly a forgery, or your name is “Anonymous” or “Won’t Say” or something like that, I’ll probably reject or remove the comment. Credibility and accountability are crucial in the discussion, and I am in favor of both.

4. Discussions are not personal.
Attacking others is just wrong. Please don’t do it. This rarely happens; however, if it does happen, the offending person will have to be banned. The comments are a place to ask questions, and if someone proposes something inaccurate or incorrect, it is acceptable to challenge them. But it’s not acceptable to attack them.

Comments aren’t the place for reporting grammatical or coding errors
Occasionally I make mistakes. When you discover one, use the contact page to let me know, rather than posting it in the comments. The reason? Because once the mistake is fixed, your comment is irrelevant and incorrect; this isn’t beneficial to anyone.

Summary
I’ll probably update this as time goes on, and I look forward to the discussions that will happen in the coming months. There are a lot of exciting posts coming up soon, and I look forward to discussing them. These points will help keep discussions civil, reasonable, and informative for those who come later.
Testing with PHPT and xUnit

Posted: December 7th, 2009, 10:00pm MST by PHP Advent

Recently, I have been splitting my development time between the PHP extension Phar, the next-generation PEAR installer Pyrus, and related PEAR2 packages. I’ve spent a considerable amount of time developing unit tests. Over time, I’ve noticed that testing is becoming increasingly onerous. Sometimes, just running them can take up to 75% of the development time. Because I don’t like to commit changes before I know they work, my development has begun to stall, and this has resulted in longer periods without testing. Worse, others have stopped running the tests prior to committing. Gradually, the code has gotten out of sync with the tests, and this is a bad thing.

When I began developing PHP extensions, I had to learn about PHPT, the standard way to test them. I had come to a personal impasse with PHPUnit. Among other things, fatal errors would bring down the entire test suite, and this made it difficult to find the source of the error. This was back in the early days when PHPUnit was still a PEAR package. It is also worth noting that continuous integration and solutions like CruiseControl — and the PHP implementation phpUnderControl — were not yet written. If you have full access to a CI server, then by all means, use it! The xUnit-PHPT combination can still be used on the client side, prior to commit, for extra reliability.

It was at this time that I designed the xUnit-PHPT combination that I have been using since. In this article, I’ll introduce this approach and show you how it could help.
What is xUnit?
xUnit is an abstraction that describes testing frameworks that adhere to similar testing patterns. The name comes from the first one, JUnit, and the x refers to the programming language. Many xUnit frameworks follow this naming convention: JUnit, PHPUnit, SUnit, FlexUnit, ASUnit, &c.

xUnit can be considered a design pattern for testing frameworks. These frameworks split up tests into test cases, fixtures, and test suites.

A test case is a single test. It contains assertions that test the correctness of whatever is being tested. The xUnit pattern does not specify what kind of test should be written, thus unit tests, acceptance tests, regression tests, and other forms of testing can all be represented using a test case.

A test fixture provides common setup and teardown procedures for a group of related tests.

A test suite is a group of related tests. Often, test suites combine several test fixtures.
What is PHPT?
PHPT is a dirt-simple PHP testing framework that uses simple markup to delineate test sections. Acquiring PHPT is simple; you can either use the run-tests.php tool included with PHP itself, use the PEAR installer’s run-tests command, or Pyrus’s run-phpt command. In addition, PHPUnit 3.3 supports running PHPT tests as a part of test fixtures, which also allows taking advantage of PHPUnit’s other advanced features. It is important to note that there are subtle but important differences in the support for PHPT. PHPUnit uses the same code as the PEAR installer, which is identical to that supported by Pyrus. The run-tests.php tool included with PHP supports some more arcane features needed by PHP developers, and the PEAR implementation supports a few sections such as --RETURNS-- for testing shell script return values that are not supported by run-tests.php.

A PHPT test is a file that ends in .phpt. Each test contains sections indicated by two dashes, an uppercase section name, and two more dashes. (For example, --TEST-- and --FILE--.) The online documentation provides more details about the format.

PHPT tests can lever more control over the environment that a test runs in, including setting environment variables with --ENV--, setting php.ini configuration directives with --INI--, setting $_GET, $_PO
Truncated by Planet PHP, read more at the original (another 11610 bytes)
Funemployment Part 2: What to do with your time.

Posted: December 7th, 2009, 7:56pm MST by Scott MacVicar

After leaving Jelsoft I was in no real hurry to find a job, I was fortunate enough to have some savings from when the company was sold. The end result was me gallivanting around Europe and North America, leaning some new skills and cooking lots. I also did a bit of work towards PHP 6 but that's not too interesting. I might as well blog about what a funemployed person does.
I'll first take a moment to give a nod to dopplr which I use to keep track of all my trips. I'd probably have missed some without it. Photos are included where appropriate and safe for work.
Glasgow, June 30th - July 6th

The first stop was back home for my sister's graduation, she's now a qualified dentist and spends her days inflicting pain on poor children in exchange for money. The rest of the time was spent catching up with friends and family.
NYC / Providence, July 9th - July 15th
My first foreign funemployment trip. I took the time to do some touristy stuff that I failed to when I was in NYC the previous year. The usual suspects were the Statue of Liberty and Ellis Island. I also frequented a few bars and played a game of football with Chris. The last leg was a visit to Providence where I hung out with my high school friend James and generally drank at his favourite bar.
Madrid, August 7th - August 9th

Some consulting work took me to Madrid for the day, but since Amanda (weinermobile girl) was there studying Spanish I decided to stay around for the weekend and explore. The picture is of the best calamari ever from a little tapas place that I've since forgotten the name of!
Sankt Augustin, August 21st - August 23rd

I attended FrOSCon for the first time and gave the initial draft of Getting Involved with the PHP Project. The photo here was from the party later on where it was decided that we should see how large of a glass pyramid we should have. We should have stopped here, the next glass toppled the lot and every glass broke :)
Valencia, August 25th - August 30th

This is the part where I run off with the cute girl and throw tomatoes, Amanda's words not mine. La Tomatina is basically a giant food fight held in Buñol each year. For a whole hour the town centre turns into pandemonium as trucks drop off loads of tomatoes for everyone to throw, one can expect to be knee deep in water and tomatoes, and shirtless by the end. The photo is fuzzy because the waterproof camera got a little steamed up.
After the tomato fight it was back to Valencia for some sight seeing and exploring, unfortunately every August the entirety of Spain essentially shuts down and the locals go on holiday. The end result was a very lazy week, we might as well have been in a cave.
San Francisco, LA, Dallas, Atlanta, Miami, DC, NYC September 19th - October 7th

Codeworks was an epic conference that encompassed 7 cities in the space of 2 weeks, rather than the attendees coming to the speakers, the speakers
Truncated by Planet PHP, read more at the original (another 7119 bytes)
Zend Framework, XSS Vulnerabilities, And The Apocalypse

Posted: December 7th, 2009, 1:16pm MST by Pádraic Brady

See what I did just there? It's going to give you nightmares tonight. If I had more title space, I might throw in Winchester to get the Supernatural fans salivating. But really, what relation do these terms have with each other? Well, nothing...yet. You can fantasise about possible connections though. Indeed, I encourage it. By all means.

Oh right, the introduction. This is another edition of the "Irishman Rants About Zend Framework". You may remember the last few installments. I usually say "OpenID" around now but that's getting old. Besides, let bygones be bygones. It's not like anyone uses Zend_Openid. The rules are simple. Paddy is pissed off. Paddy rants. Paddy drops bombs using letters from half the alphabet. People tend to be flash fried.

On Saturday, I wrote a blog post called Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?. It was a great post. Full of observations about the idiocy of blindly trusting undocumented pieces of shit (also called Zend_Filter_StripTags) to protect you from XSS (Cross Site Scripting). Only without the French wording. It was a simple tale reminding developers to (I stole this from @tommysmithbb) "know the limits of your tools". To back up my advice I made a stupid mistake.

I read the fucking class.

In reading it, I felt a bit uncomfortable. A few tests later I had a list of three reasons why this tool was limited and why you should not use it to protect yourself from XSS. First, it was buggy. Second, it allowed malformed html (capable of taking a dump on a site layout). Third it didn't actually stop XSS attacks.

Armed with this information, I lit a fire under the reader's ass leaving them under no illusions that attempting to use Zend_Filter_StripTags to block XSS in user or externally sourced html data (e.g. comments/RSS feeds) was pointless. Of course, I noted the class actually did exactly what it was supposed to. It stripped tags - it never claimed to be an XSS filter (so I thought).

Secure in the knowledge 99.99999% of developers (everyone except me - doh) were now enlightened about being wary of misusing the ZF class (or any class for that matter), I recommended using htmlPurifier for any sensitive html filtering. That library is seriously cool. Then I signed off at 1:30AM GMT Sunday, and went to bed.

If the story stopped here, I wouldn't be writing this...

I woke up Sunday morning, drank some coffee, got me some religion, and re-read my blog. Then I blinked a little. That afternoon I was discussing it with a few others. I blinked some more. More people weighed in across Twitter, IRC, email, a few IMs...and suddenly I realised something important.

Some of them were a bit...clueless. It was around then it suddenly hit me. There really were people (who really did exist) who really were filtering out XSS using the piece of fucking shit (also called Zend_Filter_StripTags) I spent the night before putting holes through. Not teeny holes - big obvious holes.

I had screwed up...royally.

My blog was written to expose Zend_Filter_StripTags as a limited tool with a lot of potential for misuse by end-users. I had not considered under the influence of caffeine and alcohol, that people actually were using it. That their applications actually were, right now, vulnerable to XSS attack vectors. That I had just revealed what might be considered a massive security vulnerability by application developers. Oh...S...H...I...T.

It's a game of end-user expectations you see. Now the people who have spent today pissing me off (I rant when pissed off - ergo) will bury their heads in the sand. "No security vulnerability here! You...er...read the documentation wrong! Er...we don't have documentation? Ah! You see - now it's definitely your fault! Silly developer - go play with your pebbles.... What do you mean, it says so in the Zend Framework Certification Guide?".

Yeah. Sand. Bury. Head. Move along all ye sheep like developers...

Fact is, it was designed as an XSS filter. It filters tags according to a whitelist. What other fucking reason does it have to exist? I would not expect a reasonable developer to come to any other conclusion unless they read the class, or were really great PHP developers, or someone actually added documentation to the contrary (there isn't any). Zend even made a big deal about XSS the last time a minor StripTags infraction was reported in March 2009. Now, it's discovered it doesn't work (again) - and there's an uproar.

Oh, Paddy you were a naughty boy and revealed a security vulnerab
Truncated by Planet PHP, read more at the original (another 7244 bytes)
PHP Conference Brasil 2009: Wrapup

Posted: December 7th, 2009, 12:52pm MST by Zend Developer Zone

This year, I was honored to be chosen to attend and Keynote at PHP Conference Brasil 2009. It was a very unique experience, and one that I will treasure. The PHP Community in Brazil is very welcoming and it led into a great conference experience.
Brazil: Conference, Vacation, More

Posted: December 7th, 2009, 12:50pm MST by Eli White

A
How to encourage piracy

Posted: December 7th, 2009, 7:06am MST by Marco Tabini

The copyright industry is somewhere around these parts.
As I write this post, I am comfortably slouched on an easy chair in a Seattle area hotel, a guest at Microsoft’s Web Development Summit (about which I shall write more in a future post). Like most visits to the States, this means a stop at Fry’s—a geek’s equivalent of Willy Wonka’s chocolate factory, with wall-to-wall electronic candy, from computers to consoles, from DVDs to floppies (yes, they have some of those, too).

Slave to my own customs, therefore, I joined my friends Eli and Rafael for a trip down to the Electronic Mecca with the idea of finally purchasing an electronic book reader—I’ve wanted one for a while, and now that php|a has an all-new format, we want to focus on supporting these devices, which we think are the way to go looking forward into the future. Translation: I finally had an excuse to get the eReader past my wife (who will probably read this post and promptly strangle me).

I ended up purchasing a Sony eReader Touch Edition. As the name implies, this device combines an ePaper screen and a touch-based interface; I don’t intend to review the device here, other than to say that the screen doesn’t quite have the contrast ratio of decent paper stock (in fact, it’s probably inferior to pulp paper), and the whole user interface seems to always stop one step short of a good UX (plus, the device has no wireless connectivity, which at this point in time is simply inexcusable). Nevertheless, the device does provide a really good reading experience, particularly when you consider that it can go for two weeks between charges and the average fiction book occupies less than half a megabyte.

What I’d like to speak about is the wonderful, wonderful feelings that purchasing content for this device has left me.
The store that almost was… not
I don’t think that you’ll be surprised to hear that the first thing I wanted to do, upon unpacking my new toy, was to get some content for it.

The folks at Sony sure must be falling off their chairs, however, because I simply couldn’t get anything. I had fallen in that DRM Neverland that is purchasing a book from the Canadian store—with a Canadian credit card tied to a Canadian address—while within the United States. In fact, the store told me so—after I had dug my credit card out of my pocket and typed in all my information: “You cannot change your method of payment in a country other than your country of residence.”

There’s a finality, a sort-of “what kind of stupid shenanigans are you trying to pull” attitude to this statement that just drives me up the wall. Why shouldn’t I be able to buy a book from the online store dedicated to my country (which, in itself, is a curious idea to be found on a worldwide network), with a credit card that was issued in the same country and is registered to an address which is, itself, in the same country?

Of course, I understand why this is: rights management. Despite the fact that the US dollar is essentially at par with its Canadian counterpart, we regularly pay much higher prices for books (among other things) than our friends south of the border. Distribution of content in our country is regulated by a government that is intent on ensuring that our cultural heritage is not overrun by Americans—in itself a rather curious attitude, considering that so many Canadians are first-generation immigrants and therefore don’t have a shared heritage to start with. Furthermore, book rights (much like movie rights) are routinely handled by different entities across borders and, obviously, each wants to
Truncated by Planet PHP, read more at the original (another 5436 bytes)
Create custom reCAPTCHA images using their API

Posted: December 7th, 2009, 1:12am MST by Web Development Blog Â» PHP scripts
If you need to spam protect your contact, comment or any other public form you should think about using a CAPTCHA image. A CAPTCHA image is an image with a random text which spam bots can’t read. The visitor need to enter that text into a form field and only if there is a match the form get processed.

Try a search for “CAPTCHA image” on Google and you will find a lot of scripts, some of them are powerful and some of them are not very effective. I’m using reCAPTCHA since several years, their challenge image is very effective and safe and if people can’t read it they can listen to an audio file.

I’m sure you have seen this image before, this is the challenge image you get with their default configuration. if you don’t like this huge RED image (like me) you need a custom theme. The good news is they offer a very powerful API system for the client side and also for the server side. In this tutorial we use some jQuery code together with the reCAPTCHA ajax library to generate the challenge images. The validation process is done by a PHP script that use a simple cURL function to submit the request and response to the reCAPTCHA server to test the submitted match. We use also the jQuery form plugin to process the form fields and client side validation.

If you like to see how it looks like check this custom CAPTCHA theme demo page.
reCAPTCHA client side script
Before we start we need to register a domain name at the reCAPTCHA website to receive a public and private key. To create a custom challenge image the Ajax way, we need to include the external file recaptcha_ajax.js and we use the following JavaScript code:
```
var RecaptchaOptions = {
	theme : 'custom'
};
Recaptcha.create('your public key', 'recaptcha_image', RecaptchaOptions);
Recaptcha.focus_response_field();
```
There is only one option required for this custom function, check this link if you like to set more options.
Next we need a small html snippet to show the challenge image:
```
<div id="recaptcha_image"></div>
<p>
	<input type="text" name="recaptcha_response_field" id="recaptcha_response_field" size="30" />
	<input type
```
Truncated by Planet PHP, read more at the original (another 15249 bytes)
Data Formatting: It IS Our Job

Posted: December 6th, 2009, 11:00pm MST by Brandon Savage
It’s happened to each and every one of us: we fill out a long form, complete with username and password. We double and triple check everything, because want to make sure the submission works. We verify our email address, our date of birth, and even maybe retype our password, just to make sure they’re both right and they both match. And then we fill out the CAPTCHA, with so much care (passing those things is still random, whether you’re a human or not). And then we hit submit.

And we wait. Breathless.

What happens next? Well, our form pops up back in our face, with a bunch of red over it (if we’re lucky) saying that we’ve done something wrong. Seems that we entered our phone number as “1234567890″ instead of “123-456-7890″ or we entered our date of birth as “6/8/1995″ instead of “1995-06-08″.

Oh, and our password is gone (because that’s how password fields work) and the CAPTCHA we beat…we have to beat it again.

Why on earth has this happened? The simple answer is that whomever designed the form decided to place the validation of the data, and its massaging into the proper format, onto the end user. But there’s a more complicated issue at hand here: the fact that the developer either felt it wasn’t his responsibility to do the data formatting, or didn’t realize that not everyone would think to place dashes or format dates the way he does.

The sad thing is that data formatting is both easy and often overlooked. Developers in a hurry will place the data formatting obligations onto the end user, rather than writing code to do it themselves, when really the code is so very simple. Take, for example, a small function that formats a phone number properly:
```
function formatPhoneNumber($number)
{
$phone = filter_var($number, FILTER_SANITIZE_NUMBER_INT);
$phone = str_replace('-', '', $phone); // We want to put our own dashes in the right place
$phone = str_replace('+', '', $phone); // + is a numeric character but doesn't belong in a phone number
//It's possible that this number is a foreign number.
if(strlen($number) < 10 || strlen($number) > 10)
{
return $number;
}

$areaCode = substr($number, 0, 3);
$prefix = substr($number, 3, 3);
$lastFour = substr($number, 6);
$number = $areaCode . '.' . $prefix . '.' . $lastFour;

return $number;
}
```
Admittedly, the above function isn’t perfect; it certainly doesn’t validate the format for each and every number and in fact doesn’t test to ensure that the phone number contains anything more than a single number. But it is a step in the right direction. With a little bit more work we could make it fully functional.

PHP also includes a number of date options, one of my favorites being the strtotime() function. strtotime() takes almost any date and converts it into a Unix timestamp. It even takes arguments like “today” and “tomorrow” and “next Wednesday” and gives a Unix timestamp for those values. PHP 5.3 has improved DateTime object handling, meaning that any value you give to strtotime() can be given to the constructor of the DateTime object, and you can then manipulate that object to format the date in any way you see fit.

Each of these solutions would prevent the user from having to format the data for us, unless the user failed to enter the appropriate data. But in 90% of the cases, the form would submit properly on the first try if it was filled out correctly and the users would be much happier for it.

The bottom line here is that data formatting is our job as developers. We have an obligation to make the forms we create as easy to use as we can; it is not the job of the end user to send us data that matches the format of what we want. We should be prepared to format the data ourselves, and ask the user for help only when the data they submit is incompatible with what we’re trying to accomplish. This is the point of feedback; use it wisely.

Thanks to Marco Tabini for reminding me that this was something I had needed to write about for a long time.
Get a Haircut

Posted: December 6th, 2009, 10:00pm MST by PHP Advent

Getting a job can be a harrowing experience. Many companies run candidates through a gauntlet of tests and interviews in the hopes of separating the wheat from the chaff. They want only the best — not just the most knowledgeable person, but also a person who fits in well with the company.
Trust me
Going through the job search process is very similar to dating. In the beginning, there’s a lack of trust that comes from simply not knowing who the candidate is and what they’re capable of. Questions are asked, and multiple dates — or rather, interviews — are necessary to determine if you’re a suitable mate — or applicant. The process is an attempt to develop a rapport and build enough trust to move on to closing the deal.

If you establish a level of trust before you even step foot into the building, you’re already halfway there. Thankfully, for those of us who make our living on the Web, there are some ways to do just that.
Show ’em what you got
Getting involved in the development community has been — for me and for many others — one of the best ways to demonstrate that you know what you’re doing. It helps establish the trust that employers are looking for. It shows that you have a passion for what you do, and can exhibit key skills such as an ability to communicate effectively.
Blog
It may seem cliché, but blogging is an extremely effective tool that can be used to garner clients or land an interview with that great company. The blog acts like a long-form resumé that highlights what you know, and what you think is important in your life as a developer.

Picking a topic to blog about may seem like the hard part. Think it has all been done before? Think again. Technology is continually evolving, and people are constantly on the hunt for tips and tricks on using these new technologies.

Start up a blog about introductory PHP tutorials, and chances are your content will get lost in an ocean of existing content. However, new language features like namespaces and closures can often be prime targets for a new audience.

Breaking out into other technologies also highlights your ability to deal with integration and shows that you’re on the leading edge of new developments. The NoSQL movement, mobile development, html5, and CSS3 are very hot topics right now.

There are plenty of new developments that need knowledgeable people to help explain them. Create a mix of content between new and old technologies, and basic and advanced tutorials, to keep your blog well-rounded.
Write a book
Writing a book provides a huge sense of accomplishment and pride. It’s a long and arduous process, but it’s a great feeling to walk into a bookstore and see your face on the shelves.

Book writing isn’t the only venue that’s available, either. Look to print and online magazines as alternatives for getting you and your knowledge out there.

In my experience, books don’t do much to get your own personal brand out there unless you’re lucky enough to write a successful book that sells well. However, the clout that comes with having written a book is, in my opinion, still worthwhile.
Contribute to a public project
People usually suggest that you contribute to an open source project, but I contend that — while it is certainly advantageous — it isn’t the open source project that is the key. It’s the fact that there’s a public record of contribution to a project that other people use.

I’ve put together cheat sheets, color pickers, web apps, desktop apps, and, yes, I’ve even contributed to open source projects. But each tool that I built offered up the possibility of getting my name out there in front of yet another new audience of people.
Speak at an event
Public speaking has a number of advantages, and there are easy and hard ways to break into it. I readily admit that public speaking isn’t for everyone. It takes a confident person to stand in front of a room of dozens — if not hundreds — of people and to be able to do it with panache and acclaim, or maybe that’s just what I keep hoping for!

Public speaking gets your name and expertise in front of hundreds of like-minded folks. These folks have employers or run their own companies. If you’re on the hunt for a new job, local BarCamps or user groups are great ways to get your feet wet before diving into larger events. Conferences will often have a CFP a number of months before the event takes place. Alternatively, contact the organizers of the conference and submit a talk idea.
Truncated by Planet PHP, read more at the original (another 2119 bytes)
Funemployment Part 1: Becoming Unemployed

Posted: December 6th, 2009, 9:19pm MST by Scott MacVicar

This post is part one of a few to be published over the next coming days about my current funemployment, the best place to start is the leaving from my previous employer.

I've a small script that I run locally to show me how many days it's been since I left Jelsoft Enterprises (171 at posting), the reason for which I've more or less kept very quiet about. A tweet did recently appear in an article on The Register, oops!

A significant amount of time has passed and I'm now comfortable commenting on this without sounding terribly bitter about the whole thing.

In the summer of 2007, Internet Brands (carsdirect.com) purchased Jelsoft the company behind vBulletin. Nothing changed internally and the engineering team had very little direct contact with our now parent company, this remained for around a year. Jump forward to summer 2008 and a few members of the team were summoned to LA to give a presentation about the future of vBulletin 4.0 and the big re-write that was planned. Most of the progress since finishing 3.8 had been design plans and research. We had looked over the old product for current features and design issues, analysed customer feedback on missing features and checked the bug tracker for common issues. The end result was that the 4.0 re-write was cancelled.

A new project / general manager was installed based out of LA (development was in England) and scrum was the shiny new model that would allow us to refactor the current release of vBulletin (3.8) and have a new version chock full of features in a meager six months. I'm not going to comment too much on why there were problems, but lets just say that it didn't quite work out that way and we're now at 14 months and the beta process is just underway.

With creative control of the project moved to LA and out of the hands of the team that had been overseeing it for the past six years it was hard not to feel like a simple code monkey. I was no longer passionate about the product and had been that way for months. This accompanied by the change in direction of the product and priorities of the company resulted in my resignation in May just before php|tek. My final day at Jelsoft was June 19th 2009.

Since the other UK-based senior developers and I left the code quality has dropped somewhat, there are over 1000 open bugs filed, on a normal day this time last year it would be around 10. Internet Brands have also increased prices, changed the licensing model and shelved the project tools product. A lot has changed in a short period of time and I'm not sure if it was for the best.

More tomorrow!
phpUnderControl 0.5.0 released

Posted: December 6th, 2009, 7:16am MST by Manuel Pichler
After quite some time of silence around phpUnderControl I have bundled the 0.5.0 release today. Beside minor changes, bugfixes and enhancements this release contains one new major feature, the PHP_CodeBrowser.
phpUnderControl integrating PHP_CodeBrowser
The PHP_CodeBrowser is a separate application that collects various XML log files with different project metrics/violations and presents them in a browseable source view with syntax highligting. This tool is a contribution by the Mayflower GmbH, where it was developed and now shared with the Open Source Community. At this point I would like to thank Mayflower as a whole and in particular at Elger and Thorsten, which were responsible for all technical aspects of this contribution.

To use the PHP_CodeBrowser you must add an additional execute publisher to your CruiseControl config.xml file that generates the PHP_CodeBrowser html report and an additional artifacts publisher to move the generated PHP_CodeBrowser report into the projects artifacts directory.
```
<?xml version="1.0" encoding="UTF-8" ?>
<cruisecontrol>
  
  <project name="PHP_Depend" buildafterfailed="false">
    
    <publishers>
      
      <execute command="phpcb 
        --log projects/${project.name}/build/logs 
        --source projects/${project.name}/source/PHP 
        --output projects/${project.name}/build/php-code-browser"/>
      <artifactspublisher 
        dir="projects/${project.name}/build/php-code-browser" 
        dest="artifacts/${project.name}" 
        subdirectory="php-code-browser"/>
      
    </publishers>
  </project>
</cruisecontrol>
```
But why do we use a CruiseControl
Truncated by Planet PHP, read more at the original (another 2446 bytes)
Parenting Versus Programming

Posted: December 5th, 2009, 10:00pm MST by PHP Advent

Advent calendars are about Christmas, and for me Christmas has always been a time for family. This year I have recently joined the ranks of the parents among you. I am taking a short break from work and focusing on being a mother rather than being a programmer. This has led me to reflect on the similarities between parenting and coding. I present these here for your enlightenment, or so you can laugh at me.
Lesson one: smells
Babies, like programs, are associated with a variety of interesting smells. If you try to ignore the smells associated with babies, they only get worse over time. Then the screaming starts.

It was Martin Fowler who popularized the notion of code smells. These are defined as parts of your code that do things in an ugly way, or to put it a different way, they are hacks. Typically, when we find these parts of code, our eyes begin to glaze over, and we enter a strange, zombie-like state. (This will also be familiar to parents.) In this state, we are paralyzed and thus prevented from doing anything about the smell. It is only when we emerge from the cave of code smells into the daylight of clean code that we can again be productive. I am not sure whether it is the horror of the code, a tendency to procrastinate that is endemic among programmers, or simply a fear of breaking things that prevents most people from doing something about the mess. It is always the smelliest parts of the code that are the most fragile.

The lesson programmers can learn from babies, here, is to face your smells and get rid of them as quickly as possible. Then everybody’s happy.
Lesson two: sleep
I have now been programming for mumble years. Not long after I started work at Mozilla, a delightful Canadian journalist asked me what it was like to work with a group of people “so much younger than myself.” While I am not actually that old, I am old enough to have picked up some skills. One of these skills is the ability to survive on 4-to-6 hours of sleep a night for extended periods. Although this is not my favorite hobby, I have gained a certain level of mastery.

Another thing I’ve learned is that surviving on 4-to-6 hours of sleep a night for an extended period makes you mildly deranged. With parenting, as with programming, it is sometimes required. When you achieve a certain level of derangement, you find that very silly things start to sound like good ideas, or they just start to happen, whether you intended them to or not. For example, you find yourself accidentally filing the baby in the filing cabinet or implementing a new framework.

This is a lesson both programmers and parents can learn from the military: sleep when you can do so safely, and as often as possible. If you can snatch a few minutes of nap here and there, it may not make you feel a lot better, but your degraded IQ will recover somewhat.
Lesson three: with great power comes great responsibility
When you set out to implement a new web app or raise a child — and yes, I do realize these things are not quite on the same scale — you have a great responsibility to do a good job. Otherwise, everyone who has to interact with your app or child in the future will curse your name. Repeatedly. Your baby — whether it is human or code — is totally dependent upon you to do a good job.
Lesson four: it takes a village
On that note, it is important to realize that it is very hard to raise a child or write a web app completely on your own. Some things are better done with a little help from your friends. Whether that help is providing a role model, a shoulder to cry on, advice when you just don’t know what to do, or purely someone to vent to, it really helps to surround yourself with people you can rely on.

That summarizes the commonalities between parenting and programming that I have learned over the last 7 weeks. I suspect I have a great deal more to learn.

One final note: If anyone approaches you to work on a web app that will take 18 years, run away as fast as you can, and do not look back.

If you’d like to comment on this article, please visit my corresponding blog post.
Zend_Filter_StripTags: Friend, Foe, or Security Nightmare?

Posted: December 5th, 2009, 5:50pm MST by Pádraic Brady

It's been bugging me on and off for a long time now, that people use Zend_Filter_StripTags. Personally I don't use it for a number of reasons, but what's obvious to me may not be so obvious to everyone. It's a messy world we live in, and blind trust is one of the ways anyone can be led astray. Besides, I'm a genius - my last Facebook IQ test proves that.

So, who is our suspect? Zend_Filter_StripTags is a filter class described as follows in the Zend Framework manual:

This filter returns the input string, with all html and PHP tags stripped from it, except those that have been explicitly allowed. In addition to the ability to specify which tags are allowed, developers can specify which attributes are allowed across all allowed tags and for specific tags only. Finally, this filter offers control over whether comments (e.g., ) are removed or allowed.

Ah well, let's go home and call it a day. It filters html and removes everything except what we define as being allowed. Ergo, it kicks ass and prevents XSS and other naughty things when I pull in html from user comments and external feeds. Right? Right? What do you mean "No"?!

Filters Are Like Hobbits - Tricksome Little Bastards

The problem is an age old one in PHP, we focus on the "strip tags" and proceed to append additional assumptions. Suddenly, we start believing in fairies, leprechauns and the magical ability for Zend_Filter_StripTags to render html safe for output. Let's consider how it operates.

The StripTags filter accepts a whitelist of tag names and attributes which you intend on allowing into the external html source (a user form or content returned from a RSS feed). The filter will then happily kill anything not matching that whitelist. It does it really well too. Got you there, didn't I? Yes, it does exactly what it says on the tin. It strips tags and attributes not on the user-defined whitelist. It's not buggy or anything.

You will of course note, that the tin never mentions XSS. It never mentions "safe" or "clean" or anything positive of that sort. That's because it's a tag stripper - a bit like strip_tags() in PHP, only wrapped in a class with a few regular expressions across 341 lines of code. You can wield it against most things where html might wrongly be included and it will do its job up to a point. After that point however, it gets truly messy - because you cannot, under any circumstances, assume the filtered html is safe.

So a new disquieting question emerges - are you using it to filter html that gets displayed on your website? If you answer no, then take a deep breath and scurry off in relief. If you answer yes, you may want to sit down - because the StripTags tin does not specify its worth in such a role. Indeed, it has precisely zero worth in the role of preventing XSS or html manipulation.

There is one important point to note - technically there is nothing wrong with the filter. It does indeed strip tags and attributes which do not appear on the user defined whitelist. The issue is the possibility that a user may take using Zend_Filter_StripTags too far. I'm not entirely sure to what extent that's even applicable, but seeing as the framework offers no full featured html filter it would not surprise me to find developers mistakenly using it in this role.

So...Foe?

Despite qualifying that the filter technically ticks all of its advertised properties, what I really don't get is what possible use it has? It has an extremely limited focus, is obviously not tested against typical XSS vectors, it quite readily produces malformed html and, at present, seems to be quite capable of ignoring a few whitelist rules. The only thing is does passably is strip tags - which presumably performs some useful function someone somewhere can explain in the comments. The point being...I have no idea.

Typically I want to strip tags because I don't trust users or external html sources (like feeds). It's part of that process to safeguard against dubious html and XSS. The StripTags filter is pointless here - it would need to be supplemented with a proper XSS safeguard - and they all filter html tags and attributes anyway.

Bring Forth The Firing Squad!

Okay, I've been moaning in general terms - so perhaps a demonstration or two would be useful? I'm guessing you're all nodding.

I'll offer three really simple examples. A whitelist bug, a malformed html snippet, and a simple XSS attack. I'm doing all this on PHP 5.3.1 with the current Zend Framework standard trunk.

Okay! Whitelist bug! I'm going to assume I let my users stick a bunch of html img tags into their comments. So I add the img tag, and its src attribute to the whitelist.

Truncated by Planet PHP, read more at the original (another 8228 bytes)
Microsoft Web Dev Summit 2009

Posted: December 5th, 2009, 7:44am MST by blog.phpdeveloper.org Â» PHP

See my pics from the event here!

I had the opportunity this past week to go back up to Microsoft for the second year to attend the Microsoft Web Developers Summit. The event brings together a wide range of people related to web development in the PHP community. This year the group was made a bit more diverse because of the inclusion of a few members of some of three communities of PHP-driven applications: WordPress, Joomla and Drupal. It made for a nice mix and, really, for what I think was one of the more interesting parts of the event (but more on that later).

Over the three days we were there, presentations were given from groups all around the company including the Web Platform Installer folks, the IIS team, the SQL Server team and a pretty cool showing from the Bing group on their mapping offerings. Showing off the products seemed to, usually, be a secondary mission for most of the groups though. Out of the number of sessions crammed into each day, most of them were either the PHP community talking to Microsoft (in the form of free-form discussions) or the Microsofters sitting down and really talking with us and asking questions about what we were doing and how they can help us do it better.

In my opinion, these discussions were worth the cost of the whole conference alone. Last year’s conference seemed a bit more chaotic and less structured. There was a lot of miscommunication (it seemed) and several things that we, as a community, weren’t terribly interested in. This year was leaps and bounds over that in terms of both quality and planning. The sessions that weren’t the discussion times were mostly relevant and almost everyone that represented MS seemed to know at least a little bit about what was going on in the world of PHP (with the exception of the ASP.NET folks but really, they sort of have an excuse – they were very happy to get the answers to their questions, though).

Leaders make all the difference in events like this and we had some of the best – our own Cal Evans helped to keep things on task and get the conversation jump started when it needed it, Karri Dunn (the ringleader and organizer) did an excellent job of making sure things were moving along smoothly and that we were able to talk to other groups in the company too (even those not involved in the summit), Josh Holmes (evangelist extraordinate) who has really jumped into the PHP community feet-first and has become one of our key voices back to Microsoft in general and, last but not least, to the leadership within the PHP community – the represenatives from WordPress/Joomla/Drupal, the core developers, the user group leaders and general community members.

A major thank you to all of you (including those I haven’t mentioned that made the event a success) for taking the MS Web Dev Summit up to the next stage in its evolution. I love the direction the event is heading – don’t lose that momentum and don’t lose touch with the PHP community. Last year everyone took their planes home and there was some random communication between MS and us via emails/twitter/etc but most of the connection was dropped. This year there’s already an effort underway to keep those lines open and to make a real dialogue between the web-related groups of each side flow. This, in my opinion, is a real deal-maker. It’s one thing to have a company that brings you up to talk with them for a few days and that’s it. It’s a whole other thing to have one that’s really excited about what’s going on with you and your community and wants to engage you and get input on their next moves.
Web Platform Installer (WebPI). I seriously hope they consider some of the suggestions we gave them as to its future and what we thought could really make it more than it is without sacrificing the simplicity it already has.
Zend Framework 2.0 Is Coming! Are You Paying Attention End-Users?

Posted: December 5th, 2009, 6:45am MST by Pádraic Brady

It's somewhat common knowledge that the upcoming Zend Framework 1.10 release may be the final minor release in this branch of the Zend Framework. From that point forward many of us will be focused on Zend Framework 2.0. What's interesting, to a degree, is how little attention this seems to be getting.

One of the major focuses of 2.0 is, of course, MVC. The Zend Framework 2.0 Roadmap is up for comment with the following categories:

Mail sending and building enhancements 2.0
Plugin Architectures
Zend_Acl 2.0
Zend_Controller 2.0
Zend_Controller_Router 2.0
Zend_Form 2.0
Zend_Session 2.0
Zend_Soap 2.0 - A Roadmap?
Zend_View 2.0

The comments to date since November 13? There are forty-two on the main page. Most of the others not more than a dozen. Of course, I should mention the mailing lists where this may also be discussed. One of the only blog's mentioning it (outside the obvious) can be found here.

One of the reasons I mention this (I'll be blogging about 2.0 myself as my time frees up) is that there is a very real risk that we'll see areas suffer from an overly concentrated focus. By this I mean, the natural inclination of a small body of developers to cater to their own needs while ignoring the needs of others. This is NOT a criticism! It's a simple outcome of not having sufficient feedback and involvement from people with diverging needs and ideas.

The way I see it, the Zend Framework has already started to suffer from its age. Some of the symptoms include orphaned components, a solidification of expectations, pre-existing conditions like poor source code and unit tests, a growing average ticket age on the issue tracker and an acceptance of obvious flaws. While these are understandable, it's a mistake to tolerate them. Toleration does not work even if tends to be PHP's largest contribution to programming.

So get your comment and analysis hats on and start reading the Zend Framework 2.0 Roadmap. This is the roadmap you'll be stuck with for years to come when using ZF 2.0 so at least pretend to be interested . Feedback is never ever a bad thing but it is in extremely short supply it seems and that simply will not do.
Automate Your Deployment

Posted: December 4th, 2009, 10:00pm MST by PHP Advent

Deploying your web site to a server can be an exercise in frustration and fraught with mistakes. There’s a lot to remember during deployment, from using the correct transfer system to ensuring that caches are cleaned. We aren’t very good at doing the same thing twice, in exactly the same way. Computers, however, are. Automation of deployment steps reduces our stress, and fewer mistakes are made.
Getting your house in order
Before we start, there’s a certain amount of housekeeping that needs to be in place to make deployment easy and consistent.
Source code control
It all starts with control of your source code. If you’re not using a version control system such as Subversion or Git, then sort this out, first! These systems add discipline to your development processes. You should use branches for each new feature (and bug fix) that you develop.

The most important reason to branch is that many clients will approve work in a different order than it is requested. You may have multiple features in development, simultaneously, and need to put them live independently of each other, as they are approved. Branching allows this to happen without accidentally releasing features that are not yet ready.

You also need to be able to handle an urgent bug fix for the live site. This situation always seems to occur when you are in the middle of a significant block of work that has dramatically changed the code in question. A bug that is noticed on the live site needs to be fixed, immediately. If you are not using branches, then you have to separate the work you have been doing, which is not fun and is prone to mistakes.

Using branches ensures that you can always have a version of the site ready to go live. There are two approaches that can be used to organize your source code repository to achieve this: trunk-based deployment, where trunk is always ready to go live, and live-based deployment, where you create a branch called live that is always ready to go live.

With trunk-based deployment, you use branches for integration work that may be required between features. With live-based deployment, you create a branch called live and use trunk for integration work. The latter allows you to cherry-pick and merge just the wanted code into the live branch, and then deploy. In general, for smaller teams, trunk-based deployment works well, and for larger teams, the additional control provided by live-based deployment is very beneficial.
Database considerations
While you are making deployment of the source code easier, you should also pay some attention to your database management strategies. Specifically, you need to control the schema across your live, staging, test, and development servers. As you develop new features on your web site, you will find that you need to change the database schema. The best way to handle this is to version your database with a special table in the schema containing the current version number. You can then write the schema changes that describe how to change to the next version. These are known as up deltas and you should write a corresponding down delta for each of these that describes how to revert to the previous version of the schema.

There are a number of tools that will manage this type of database migration for you. The most commonly used projects are DbDeploy, LiquiBase, and the migration code in Doctrine. Of course, you could also write your own scripts in PHP.
Code considerations
You need to ensure that your source code is prepared for automatic deployment. This means that you need to be aware that the same source is running in different environments, and the code must be able to handle this. Usually, this means that you need to control your configuration, and you should load the correct settings based on where the code is deployed. One mechanism is to automatically detect the environment, based on the URL being used to access the site. This usually means that you have specific keywords in the URL for development, testing, and staging, and then assume that you are loading the live configuration if none of these are present. Another option is to set an environment variable (using SetEnv) within the Apache VirtualHost definition, and then use the getenv() function to retrieve it within your source code.
Automation strategies
When deploying to a server, there are a number of things that you need to consider when planning your strategy. The most importa
Truncated by Planet PHP, read more at the original (another 7362 bytes)
PHP Advent 2009

Posted: December 4th, 2009, 3:58pm MST by Lorna Mitchell

I'm very proud to be able to say "I'm a PHP Advent author" - I've been invited to take part in this year's event and my article One Step at a Time is now live!

My post this year is aimed as a reminder to us all that we can all aspire to better things, and lots of "better" eventually adds up to "pretty damn good"! If you read the post and have comments, add them here - and if you've chosen what one thing you'd like to change next, I'd be delighted to hear it. Whatever your next step, good luck :)
Oracle/Sun/MySQL: Ellison is now willing to create a separate entity

Posted: December 4th, 2009, 12:37pm MST by ThinkPHP /dev/blog - PHP

According to the sources, Ellison is now willing to create a separate entity within a combined Oracle-Sun that houses Sun's MySQL open database software business in order to get the deal completed before a hearing Thursday by the European Commission.

Read more at New York Post. Via Kris Köhntopp.

UPDATE: this has already been declined by Oracle (thx to @janl).
Oracle/Sun/MySQL: Ellison is now willing to create a separate entity

Posted: December 4th, 2009, 11:27am MST by ThinkPHP /dev/blog - PHP

According to the sources, Ellison is now willing to create a separate entity within a combined Oracle-Sun that houses Sun's MySQL open database software business in order to get the deal completed before a hearing Thursday by the European Commission.

Read more at New York Post. Via Kris Köhntopp.
10 years of English blogging

Posted: December 4th, 2009, 9:36am MST by Danne Lundqvist

Even though I’ve lost my earliest blog posts due to an early domain change as well as a later change of blogging software I have been blogging about PHP and web development here for almost 10 years. As it is just over one year since we started our Swedish company Dotvoid AB I felt it was time to start blogging in Swedish as well.

I will continue to blog about PHP, javascript and web development here. I might even try to increase the number of posts. Oh I’ve never promised myself that before, have I Anyway, our Swedish blog will not be as technical as here on dotvoid.com. Instead the blog will focus on the company and what we do as well as web development in Sweden and Europe in general.
Upcoming WebSphere and PHP book reviews

Posted: December 4th, 2009, 9:11am MST by Daniel Krook

With several vacation days to cash in through the end of 2009, I hope to catch up on some reading and learn more about the latest developments in the two areas where I do most of my work as a Web application developer – Java EE Web applications built on IBM WebSphere and PHP Web [...]
URLs or URis, What’s the difference?

Posted: December 4th, 2009, 8:31am MST by Vidyut Luther
A lot of people confuse the terms URLs and URIs. This morning, the PHP Advent post by David Sklar exemplified that. Paul Reinheimer already has a rebuttal for this, and I’m expecting many more.

I agree with Paul, David seems to be missing the point.
- URI: Uniform Resource Identifier/Indicator
- URL: Uniform Resource Locator
The keyword here is IDENTIFIER. Just because you know the identifier, doesn’t mean you know the content/topic yet. An Identifier is normally used by machines to find out where to go. URL Shortening services produce URIs by default, but offer the ability to create URLs. Take for example: http://tinyurl.com/yj432kb and http://tinyurl.com/thirdpartycode . The first one is a URI, a human has no clue what it’s about. The second one, you can guess what it’s about.

The fact that they both end up at the same location may make you think that human readable urls aren’t important, but as the number of shortened urls grow, and the number of services providing these urls grow, we’ll need some way of knowing what’s NSFW, what’s taking you to a phishing site, or what’s just a prank site. As this happens, the chances of someone clicking on jy32kb vs clicking on /thirdpartycode decreases, because people will get burnt too often.

I’m already seeing security teams blocking emails containing tinyurls, twitter clients have the ability to display the end url in your view. URLs do matter, even if they point to the same site, www.cnn.com looks a lot more trustworthy than [tinyurl.com]

Sure, I can manipulate URLs to give a false sense of security, or to try and fool the search engines. But that’s a different topic, and is already being addressed by search engines
Why Great Development Tools Don’t Seem To Be Written In PHP

Posted: December 3rd, 2009, 11:00pm MST by Brandon Savage

Trac. CruiseControl. phpUnderControl. Jira. Bugzilla. These are all intensely popular development tools. And not a single one of them is written in PHP.

Why?

Trac is written in Python. CruiseControl is written in Java, and phpUnderControl is built on top of CruiseControl. Jira is written in Java and is a commercial program. Bugzilla is written in Perl. All of these programs have either been around for a long time, or they have commercial components attached to them.

Some might argue that PHP is a lesser language, and thus incapable of producing the results that Python and Java can produce. Others might argue that other languages are more mature. But the truth is that these applications don’t exist in PHP simply because PHP wasn’t previously capable of producing them. With PHP 5’s object model, PHP is finally able to produce the high-quality applications that developers can use. PHPUnit is a perfect example of that.

Next year, I’m devoting myself to writing and developing open source applications for the PHP community to use. These applications will consist of a continuous integration server, a bug tracker (that doesn’t suck or look terrible), and an SVN browser. These applications will be available for free, and will be community driven. I’m taking the initiative because these applications are great ideas but few people have the time; thus, I’m dedicating myself to writing them and making them available for others.

This will be my big contribution to the PHP community in the next year. I think it’s worthwhile and necessary. And it should be a lot of fun, too.
One Step at a Time

Posted: December 3rd, 2009, 10:00pm MST by PHP Advent

I have the privilege, in my current line of work, to be able to attend quite a number of conferences and other technical events throughout the year. At every event, I meet people for whom this is their first experience at a technical gathering; sometimes they make contact through the pre-conference channels and have many questions about what to expect. For these people, everything is novel; the talks, speakers, and content are all new and often make a big impression on these new attendees. I always advise people not to think that the event finishes when the schedule says it does, and often they will take the opportunity to hang out with the community and make discoveries there as well.

When I chat with these new — or relatively new — additions to our community, I ask them how they enjoyed the event. Almost without exception, they tell me how much they learned, and how much they learned they have to learn! This is the experience I have at every event I attend, and it’s a feeling that fills me with enthusiasm for knowledge and improvement. I have noticed, however, that others take this quite differently.

They tell me that, yesterday, they thought their applications were pretty good, they met their deadlines, their applications worked, and their clients paid their bills. For me, this is a pretty good definition of success, but they will earnestly tell me that they now know this is not the case. After all they see at the conference, they realize there is so much to learn, and their reaction is to be utterly overwhelmed and feel as if “best practice” is something unattainable by mere mortals. (I’m generalizing, in case that isn’t obvious.)

Earlier this year, I was involved in organising the PHPNW conference — the conference of my local user group — where I gave my talk entitled Passing the Joel Test in the PHP World. The Joel Test is a series of 12 criteria that, according to software guru Joel Spolsky, all good software teams should meet. In reality, there are some changes to make to the test, and the original points plus the suggested changes are the features of this talk. I found that after the talk, people came to me and told me that their organizations were only scoring 2 or 3 points out of 12, and many felt that their teams were out of reach of the standards set by the highest-scoring organizations.

This perspective strikes me as being slightly defeatist. The mountain is too high to climb, so the attempt is to be avoided, and the mountain’s existence denied? Nobody who speaks at a conference does so to put people in their place or discourage anyone. Another approach is to take a look at all these new ideas and decide where to begin. Many of the concepts presented at conferences aren’t applicable to every scenario. Some things that you see will rely upon development processes that aren’t currently in use within your team, or may not fit in well. Other things are too advanced to pick up immediately and should instead stay in your mind as ideas to keep reading about, look out for tutorials on, and implement… eventually. “Rome wasn’t built in a day.” This is true of best practices, too.

Improvement is an incremental process, and the next step might be starting to use source control or unit testing or continuous integration or any of a huge raft of other things which would improve our development process or make our lives easier. Making a change like this in an existing development team, which already has deadlines to meet, can be difficult for a number of reasons. One hurdle is that new tools and processes need multiple iterations to select, set up, and implement, and it can be hard to quantify at the outset how much time that will be. New infrastructure may also be needed, which is another barrier. But, perhaps the most frustrating of all is how difficult it can be to implement changes with an existing team. Although we all know that source control (or whatever improvement is under discussion) will make our lives easier in the long run, getting everyone to buy in to the short-term disruption can be truly difficult. Taken altogether, these difficulties can make improvements and better practice seem unattainable.

I’m a firm believer that you can do a lot with only a little. Implementing a new tool is a long and arduous process, or can be, but how do you think those experts got to where they are today? What do you really need to get started with the new improvements? You could install it on your development machine, see how easy (or not) it is to get set up. You could trial it for your own development, or invite a couple of people to try it out for an internal project. Make sure you know where t
Truncated by Planet PHP, read more at the original (another 1952 bytes)
We're looking for experienced Magento and/or PHP/JavaScript developers

Posted: December 3rd, 2009, 3:39am MST by Christian Stocker

For a larger project here at Liip Zurich, we are looking for an experienced Magento PHP Developer. Start as soon as possible. Freelance is ok, but you have to be able to work with the team here in Zurich onsite (most of the time). This also means: No interest in outsourcing, off- and nearshoring or however you call it. We just need a person fully integrated into our already existing Magento team. If you're interested get in contact with Nadja Perroulaz (contact@liip.ch) or me.

Furthermore we're (always) looking for an experienced PHP/Javascript Web Developer. If you're interested in a job where you can learn and develop new stuff almost every day and work on exiting projects and if you have a lot of experiences in the PHP/JavaScript/Web World, do not hesitate to send us your application. The ad linked above is in German, if you don't understand it and want to know more, I'm here to help. Knowing German is no prerequisite for a Job at Liip :)
PHP, SOAP and operation signatures

Posted: December 3rd, 2009, 2:22am MST by Danne Lundqvist

After investigating SOAP further there seems to be a common confusion regarding the difference between rpc/literal and document/literal and how it is handled in PHP. There is even a bug 49169 reported because PHP ext/soap maps all operations defined in the web service with the same signature to the first defined function or method in PHP when using document/literal style.

It is not a bug. The style document/literal is for sending messages with document data. It is not a remote procedure call. For that we have rpc/literal. So if you look at it that way it is completely understandable that only one method should be around to handle one specific type of message (document).

It is also completely correct behaviour according to the specification WS-I Basic Profile.

“In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement.“

As document/literal is the preferred style, and some implementations obviously have a tendency to dislike rpc/literal, a lot of people is going down the document/literal route without understanding the implications and what the real difference really is.

I don’t think this should stop ext/soap in PHP to use the soapAction header for routing when necessary. According to WSDL 1.1 the soapAction attribute is mandatory when HTTP protocol binding is used. Whether rpc/literal or dcoument/literal style is used is of no difference. So is this information just garbage for document style messages?

Anyways, PHP bug 46169 is to my understanding not really a bug. But it is a reasonable feature request.
Do URLs Matter?

Posted: December 2nd, 2009, 10:00pm MST by PHP Advent
I liked how Chris and Sean describe their role as curating PHP Advent, so I thought I’d do a little sub-curation of my own. This entry is a point-counterpoint on the topic Do URLs Matter? The contributors’ thoughts are below, followed by my conclusion.
Of Course!
— J. Random Programmer

Of course URLs matter! Without clean URLs, it wouldn’t be obvious where you are just by looking at the URL displayed in the address bar. Who can remember long strings of jumbled letters and digits to type in compared to something elegant like http://pants.com/blog/my-dinner-with-barack‽

Plus, I’m always noodling around with the URLs I see, so it’s nice when they’re easily hackable. If I see a page like http://pants.com/forum/topic/23, it’s easy enough to swap in 24 or 22 for the 23, and browse around.

It sure does bug me when those URL shortening services transform my beautiful URLs into tiny garbled squibs. How do people even know where they’re going to end up when they click on one of those things? It’s almost as if the URL itself is just a means to an end to those people.
What?
— A. Normal Person

I’m not really sure what a “URL” is but when David asked me to write this, he said something about the way to find Internet web pages, so here’s how I look at them:
- People send me emails with blogs to read or YouTubes to watch, so I click on the blue part of the message to see the blog or the YouTube.
- Sometimes, I’ll make a bookmark when I’m looking at something I want to see later, so I can visit it from the bookmarks menu on the computer. Also, my computer came with a bunch of bookmarks already on there.
- Occasionally, I see one of those .com web page addresses printed somewhere, maybe in an ad on TV or on the side of a bus. If I type that address into the Google, then I get to see the Internet web page that the ad was for.
Conclusion
People don’t care about URLs. The few normal humans who still occasionally type in a URL are going to stop doing that once their iPhones get better at reading 2-D barcodes.

If you’re designing a web service to be used by programmers, then URLs matter as much as function names matter in a well-designed library. Would you rather call strlen() or func_73d3a702db472629f27b06ac8f056476()? This is not something salient about URLs, but just a general principle of human mental capacity. It is easier to refer to 7000 + 14 as “7,014” than as “Máximo Pérez.” (To read more about that, visit this URL: [www.amazon.com] .)

A grumpy “SEO Professional” is reading this right now and saying “No, he’s missing the point! The clients for URLs aren’t humans, they’re search engines! I need to tell Google what my page is about in the URL.”

Mr. Grumps is not entirely wrong, but SEO-friendliness is orthogonal to human-readability. That Amazon URL up there works just as well (from a loading-the-right-page perspective) written as http://amazon.com/dp/0140286802. The rest is just fluff to make some automated system (a search engine, clickstream analysis processing, &tc.) happy.

There are a variety of reasons to structure your URLs a certain way, such as making search engines happy, making developers using your service happy, or keeping yourself sane when you build a web site. Providing utility or aesthetic pleasure to regular people who use your web site, however, is not one of them.
Results of November's ZF Bug Hunt Days

Posted: December 2nd, 2009, 1:54pm MST by Zend Developer Zone

Zend Framework held its third monthly Bug Hunt Days in November on the 19th and 20th. During that time, we closed more than 120 issues in the tracker, many of which made it into the 1.9.6 release the following Tuesday.
Major glob() fail

Posted: December 2nd, 2009, 12:15pm MST by Jordi Boggiano

I just had the pleasure of discovering another of PHP's little quirks and since it's been almost a year since my last post, I thought it would be a good occasion.

Working on some personal project that lists a bunch of stuff on my hard drive, I found out that directories that contain square brackets (those []) don't return any results for the simple reason that glob reads [stuff] as a character class, just like in regular expressions. When you know it it makes perfect sense, but when you don't, the documentation is really not so helpful. Of course it mentions libc's glob() and unix shells, but not everyone knows what that implies at first glance.

My first reaction when I noticed that those directories were missing was to try and escape them with backslashes, which works on unix systems, but not on windows since the backslash is the directory separator. The cross platform solution is to enclose them in brackets (i.e. [[]), which effectively creates a character class with only the opening bracket in it, so it matches correctly.

I then wrote this glob_quote function which, just like preg_quote, escapes the meta characters that glob uses.

glob_quote function function glob_quote($str) { $from = array( '[', '*', '?'); $to = array('[[]', '[*]', '[?]'); return str_replace($from, $to, $str); }

Another detail worth noting while I'm at it is that this problem also occurs when you do glob('*.txt') if your cwd contains brackets, since in this case the cwd is pre-pended to the pattern, the solution being to escape it as well as such:
glob(glob_quote(getcwd()).DIRECTORY_SEPARATOR.'*.txt');

That's it for today, so until next year..

Easy user location with Midgard

Posted: December 2nd, 2009, 7:08am MST by Henri Bergius

Location is an important context that web services can utilize for fun or smarter user interaction. In past getting location used to be difficult, but now thanks to good IP locationing databases and browser geolocation capabilities it is becoming a lot easier.

But to be really easy, the framework you're using should provide user's location built-in, without you as an application developer having to think about it. This is the reason for Midgard's geolocation features to exist, after all. With Midgard, getting user's location is quite easy:

Midgard MVC (Midgard 9.09)

// Read location from session or user's location log
$user_location = midgardmvc_helper_location_user::get_location();
if (is_null($user_location))
{
    // No location found, try to geocode based on user IP via the GeoPlugin service
    $geocoder = new new midgardmvc_helper_location_geocoder_geoplugin()
    $location_parameters = array('ip' => $_SERVER['REMOTE_ADDR']);
    try
    {
        $user_location = $geocoder->geocode($location_parameters);
        midgardmvc_helper_location_user::set_location($user_location);
    }
    catch (Exception $e)
    {
        // Couldn't get location from IP
    }
}

if (!is_null($user_location))
{
    echo sprintf('You\'re in %s, %s', $user_location->latitude, $user_location->longitude);
    // Will print "You're in 60.1633, 24.9279"
}

MidCOM (Midgard 8.09)

<?php
// Read location from session or user's location log
$user_location = org_routamc_positioning_user::get_location();
if (is_null($user_location))
{
    // No location found, try to geocode based on user IP
    $geocoder = org_routamc_positioning_geocoder::create('geoplugin');
    $location_parameters = array('ip' => $_SERVER['REMOTE_ADDR']);
    $user_location = $geocoder->geocode($location_parameters);
    if (!is_null($user_location))
    {
        // Store geocoded location to session or user's location log
        org_routamc_positioning_user::set_location($user_location);
    }
}

if (!is_null($user_location))
{
    echo sprintf('You\'re in %s, %s', $user_location['latitude'], $user_location['longitude']);
    // Will print "You're in 60.1633, 24.9279"
}
?>

The examples above will work with both anonymous site visitors (using sessions) and registered users (using Midgard's position log). In this example we check if location is already available via browser geolocation or some importer like Qaiku or Fire Eagle, and if not we fall back to IP-based positioning using the GeoPlugin service. The resulting user location array or object (depending on Midgard used) contains a textual description of the place and accuracy information in addition to WGS-84 coordinates.

Developing desktop applications by using web technologies

Posted: December 2nd, 2009, 3:33am MST by ThinkPHP /dev/blog - PHP

Looking how to develop a desktop application in a short term, I came accross "Titanium Developer". This Open-Source tool helps you to create desktop apps. The special feature about it is the possibility to use well-known Web-Technologies such as html, JavaScript and PHP. Thus, learning a new programming language is no longer necessary. Another advantage is that you can directly create binaries for Mac, Linux and Windows using the same code.

Continue reading "Developing desktop applications by using web technologies"
Support Vector Machines In PHP

Posted: December 2nd, 2009, 3:00am MST by Ian Barber

When it comes to classification, and machine learning in general, at the head of the pack there's often a Support Vector Machine based method. In this post we'll look at what SVMs do and how they work, and as usual there's a some example code. However, even a simple PHP only SVM implementation is a little bit long, so this time the complete source is available separately in a zip file. The classification problem is something we've discussed before, but in general is about learning what separates two sets of examples, and based on that then correctly putting unseen examples into one of the other set. An example could be a spam filter, where, given a training set of spam and non-spam mails it is expected to classify email as either spam or not spam. SVMs are systems for doing exactly that, but they only care about points in spaces, rather than emails or documents. To this end a vector space style model is used to give each word in a document an ID (the dimension) and a weight based on it's importance to the document (the document's position in that dimension). Given a series of examples of documents in a vector space, each tagged with a 'class' or 'not class' designation, the support vector machine tries to find the line that best divides these two classes, and then classifies unseen documents based on which side of the line they appear. Linearly Separable Classification
It's easy to visually separate the two classes above because the problem is in two dimensions. Once we extend this to thousands of dimensions it becomes trickier for a human, but there are a whole bunch of algorithms that will cleanly separate the training cases by defining a line which divides the two sets - but what are makes one solution better than another? The intuition that drives SVMs is that the line which best divides the two cases is the one that has the largest margin between it and the nearest training examples on either side. Therefore, the important example vectors are the ones that define that margin - the ones closest to the dividing line. These are the support vectors, and it is a combination of them that provides the decision (class or not class) function for an SVM classifier. The function in our example code looks like this: <?php
protected function classify($rowID) {
$score = 0;
foreach($this->lagrangeMults as $key => $value) {
if($value > 0) {
$score += $value * $this->targets[$key] * $this->kernel($rowID, $key);
}
}
return $score - $this->bias;
}
?> Th
Truncated by Planet PHP, read more at the original (another 30176 bytes)
PHP and Web Services - essential reading

Posted: December 2nd, 2009, 2:56am MST by Danne Lundqvist
An old web service implemented in PHP have been giving me some headache the last couple of days. Especially interoperability with clients implemented in other languages (like .NET) are troublesome. It seems to me that PHP is very forgiving. Which is good - sometimes - but not always. PHP let you get away with a lot when creating your web services. So just because your PHP client play along nicely doesn’t mean other clients will work. Far from it.

So after loads of googling I came to realise that even though 2010 is just around the corner there are still very few quality articles on PHP and web services/SOAP available. Most of the stuff I find is rubbish where people who don’t know nothing explain things they don’t understand.

So even though these articles below are old, they will give most people a very good grasp on how, and why, to create a SOAP web service using PHP that will work. (And a very short advice; use document/literal style for better interoperability with for example .NET and don’t use preserved words like “ref” as parameter (message parts) names for better interoperability with for example .NET).
1. Which style of WSDL should I use?
2. PHP SOAP Extension
A comment about the second article is in place though. I generally tend to favour mapping WSDL defined operations to methods in a class. So instead of using PHP methods like $server->addFunction(), use $server->setClass(). More on setClass() in the manual.
Five (Good) Lessons The Government Teaches Us About Object-Oriented Programming

Posted: December 1st, 2009, 11:00pm MST by Brandon Savage

As Benjamin Franklin once famously said, “the only two things that are certain in life are death and taxes.” His point, while political, has a good perspective on one of life’s ever-persistent truths: the fact that governments exist in every country, and, largely, they have some of the same benefits and drawbacks everywhere.

However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.

First a warning: because the purpose of this post (and this blog) is not to discuss politics, comments about politics won’t be approved. Each comment will be moderated.

In reality, government serves as one big object-oriented application in many ways. Government excels in the areas of abstraction, encapsulation, the implementation of dumb objects, decoupling and giving one class a single responsibility. Let’s examine each of these as programming practices and see what we can learn.

Abstraction
Governments are really good at abstraction – almost too good, sometimes. Abstraction is the principle that you can take complexity and break it down internally to ensure that the appropriate object, with the appropriate inheritance and components, does the appropriate task.

Governments do this largely by creating a bureaucracy. Programmers do this by creating parent and sub- classes that have specific responsibilities. Object-oriented applications are, by default, bureaucratic – when abstraction comes into play, you give objects specific responsibilities and abstract out the peripheral things that might otherwise be included when doing functional programming. However, it works well in object-oriented programming because objects follow specific rules absolutely – meaning your “bureaucracy” doesn’t make mistakes along the way.

Encapsulation
This is one area of object-oriented programming that we don’t discuss often enough (I’m not sure I’ve ever mentioned it). Encapsulation is the practice of concealing the inner-workings of an object from the objects that pass messages to it.

Governments do this by creating front-line and back-line workers. Take, for example, the courts: you have clerks, judges, and others who deal with the “customers” – criminals, lawyers, plantiffs, etc. But each court system has hundreds of other workers who file, copy, collate, prepare dockets, update websites, and do other functions that are behind the scenes but are crucial to the operation of the object (the court).

As developers, we can do this by shielding internal functions with the protected and private keywords (in PHP, anyway). These keywords make it impossible for those outside our objects to mess with the inner workings, but still allow those innerworkings to proceed. We have our “front line” (our public API) and our “back line” (our protected methods) which do other crucial, internal work.

Dumb Objects
Lots and lots of people complain about how each department they work with independently requires verification of the same documents before they can proceed. For example, in applying for the proper permits for my business, I had to submit proof that my LLC was established and in good standing before I could get a Home Occupancy Permit, and I’ll have to show the Home Occupancy Permit paperwork before I can get a business license. And this is the same department of Washington’s government – the Department of Consumer and Regulatory Affairs. You’d think that they could work together and share the same database, right?

Not so fast! The government has done something that more programmers ought to do: it’s created “dumb objects.” This is not to say that the workers who do the work are dumb; instead, the departments themselves are dependent on you giving them (dependency injection) the proper documentation.

People have debated for a long time on whether or not this is appropriate behavior for government, but it the undisput
Truncated by Planet PHP, read more at the original (another 3387 bytes)
You Really Need to Learn JavaScript

Posted: December 1st, 2009, 10:00pm MST by PHP Advent
PHP developers have typically worn a few hats. Few of us are “pure” PHP developers, where we only write PHP and don’t scribble together some html at least once in a while, or paste and edit some JavaScript on occasion. A lot of us — myself included — came to PHP as a way of adding new functionality to our flat html web sites, and PHP’s roots as a language that intermingles with html are a big reason for its popularity. It’s likely that PHP wouldn’t be as useful as it is on the web if it wasn’t driven by the practical needs of front-end developers.

For the most part, these skills have suited us well. Web apps have typically been focused on the server side. The web pages we view have been static results of computation done on the server, parsed for presentation purposes on the client side. We might have some flashes of dynamic html (remember that?) here or there. But with few exceptions, all of the real work is done on the server.

In the past few years, this has started to change. Clients are becoming richer, more complex, and are responsible for more aspects of the app. Web apps are becoming more balanced, with more heavy lifting on the client side. The server side is increasingly becoming a service to be called upon when the client needs more data or wants to save something for access elsewhere. Fewer and fewer server-side apps will follow the model PHP has excelled at, where it generates all of the code that’s then parsed and presented by the client. footnote 1

Yeah, you know all that. Ajax, web APIs, Twitter, etc. It’s all very exciting, and you can just have your framework generate that junk for you. You’ll be awesome, right?

Probably not. How well does auto-generated PHP work for you? Not so well. You know how you make fun of PHP “developers” who just copy and paste code, or let a tool write it for them? Well, if you don’t know JavaScript, you’re in danger of becoming that person.

When I say “you need to learn JavaScript,” I don’t mean “learn how to copy and paste an example,” or “learn how to generate JavaScript with PHP.” I mean learn it as well as you already know PHP — or better.

Why? Because JavaScript drives rich clients, and all indications are that clients will be getting richer. You won’t be able to get away with just adding small snippets of JS to add tooltips and simple animations. Complex processing and UI management will require real knowledge of how to write JS, and how in interacts with the client’s APIs — the DOM, local storage, networking, OS features, and more.

The bad news is that this will take a bit of effort. JavaScript’s syntax is fairly similar to PHP’s, but some fundamental stuff is quite different. The object model will probably confuse you at first. The scoping is very different from PHP. The malleability — how you can change fundamental behavior of built-in language constructs at will — is going to freak you out a little.

The good news is this: you will be a smarter, better, and more in-demand developer because of it. Browser makers are investing plenty of time to create better tools for client-side developers. JavaScript runs orders of magnitude faster in most browsers than it did just 3 years ago. footnote 2 Local storage APIs, WebWorker APIs (for spawning JS processes), native JSON encoding and decoding: all of these things are recent additions to most browser engines, and all of them add significant speed and/or capability for developers.

What’s been more interesting to me, beyond browser-based rich clients, is the introduction of Web Runtime platforms (WRTs). These are platforms for building desktop and mobile apps with traditionally web-oriented technologies, like html, CSS, and JavaScript. This approach has some significant advantages over deployment in the browser, mostly related to consistency of rendering and additional APIs. Titanium Desktop from Appcelerator is especially interesting to the PHP developer, as it allows you to develop in PHP (as well as in Python and Ruby) in addition to JavaScript.

Mobile apps seem to be gaining dramatically in popularity as their devices gain market share. WRTs are available for many major mobile platforms, such as:
- iPhone
Truncated by Planet PHP, read more at the original (another 3726 bytes)
PHP Advent 2009

Posted: December 1st, 2009, 4:07pm MST by Chris Shiflett
With the help of Sean and twenty-four fantastic authors from the PHP community, PHP Advent is back for a third year.

Paul gets things started with an article on comprehensible code:

Reading code is hard work. Here are some reasons why, along with some tips on how to make it easier for other developers to understand your code.

Thanks to everyone who has helped spread the love on Twitter and elsewhere, and thanks especially to our authors.

We've got a few surprises this year, so I hope you'll follow along. You can follow @phpadvent on Twitter, subscribe to our feed, or just visit phpadvent.org for a daily dose of tips, tricks, and tidbits.

You can also read previous PHP Advent articles if you haven't already:
- PHP Advent 2007
- PHP Advent 2008
In addition to PHP Advent, you might also be interested in 24 Ways, an advent calendar for web geeks.

Mele Kalikimaka!
Posted Tue, 01 Dec 2009 23:07:47 GMT in Chris Shiflett’s Blog
Profiling PHP applications with XHProf: the path to scalability

Posted: December 1st, 2009, 3:22pm MST by Lorenzo Alberton

My latest article on Profiling using XHProf, a neat tool developed at Facebook. A step-by-step tutorial to install and use XHProf, and some useful hints on how to improve performances and scalability of your PHP application.
Book Review: Zend Framework 1.8 - Web Application Development

Posted: December 1st, 2009, 3:11pm MST by Zend Developer Zone

Packt Publishing contacted me to write a review on Keith Pope's Zend Framework 1.8 - Web Application Development . They sent me the book and enjoyed the time reading it. So here is my review.
A day filled with symfony news

Posted: December 1st, 2009, 1:49pm MST by Stefan Koopmanschap

Great stuff is happening today! I would dare to say that to date, december 1 2009 is probably the most active and important day in the history of the symfony project! Three(!) new versions have been released, amongst which the first of the last branch of symfony 1, and a new book is available in the form of an online advent calendar and a print book.
Comprehensible Code

Posted: December 1st, 2009, 12:55pm MST by Paul M. Jones

My article for PHP Advent 2009, the first in this year’s offerings, has been published: [phpadvent.org] Summary: “Reading code is hard work. Here are some reasons why, along with some tips on how to make it easier for other developers to understand your code.” If you would like to comment on it, [...]
Books I don't recommend if you're starting out

Posted: December 1st, 2009, 9:44am MST by Travis Swicegood

Keith Casey's recent post on a book recommendations got me thinking. I get asked what books I recommend. I whole-heartedly agree with his first recommendation. The Pragmatic Programmer sits on my desk and is often in my laptop bag. I reach for it if I have five minutes and want to flip through something technical without having to load up my Google Reader.

Not on his list is the Passionate Programmer. I highly recommend this book to anyone working in the industry. I've reviewed it on Amazon, feel free to check that out for more information.

But this post isn't about what I recommend, it's what I don't. There are two books that Keith recommends that I no longer recommend off the bat to programmers. PEAA and Refactoring. Both are excellent books, but neither should be read by people starting out.

Why? The books are both excellent. I've read both. I own both. I do recommend them, some of the time. Both are geared toward programmers that already know how to program. Both contain a wealth of information which, in the right hands, can take the development of the reader to the next level.

But they also contain information that can be abused tremendously. For example, Active Record in it's abused, single-world form of ActiveRecord has caused a tremendous about of scaling issues. All because it was a Fowler endorsed method for dealing with data in a database. Developers without an understanding of its limitations started copying what Rails did and in the process mixed business logic and database logic into the same object. What happens when your data needs to be stored in a flat file or a nosql style database? Your business logic is now all tied up in your database and its painful to extract that and retrofit your application to be scalable.

Of course, since you have Refactoring you can fix that. Right? Well, sort of. Patterns and refactoring go hand in hand. Ideally, refactoring code should lead to some more understandable, reusable code; something that's more easily explained to another developer. Patterns fill the bill. Nowhere in Refactoring or Joshua Kerievsky's Refactoring to Patterns will you find anything about pattern hoping. To fix an improper use of ActiveRecord by moving to another pattern, however, you end up doing exactly that.

Couple that with the sweater string issue. We've all had a loose string on a sweater, right? You give it a tug instinctively to get rid of it, and before you know it a hem in gone and the sweater is ruined. Refactoring, in the wrong hands, causes the same thing.

Well, I need to extract this logic out. Next this piece needs to be mutable. I should inject this object so I can replace it out later if I need to. And so on, and so on, ad infinitum.

Both patterns and refactoring are powerful tools, but not in the hands of a novice. Both books should be read, but not when you're starting out. Get your hands on Pragmatic and Passionate, spend some time looking for a mentor to help guide you down the right path. Once you get your feet under you as a programmer, then start learning about the mechanics of patterns and refactoring. Once you're to that point, PEAA and Refactoring are great material.
Original post blogged on b2evolution.
Is it a Developer’s Responsibility?

Posted: December 1st, 2009, 6:35am MST by blog.phpdeveloper.org Â» PHP

Last night, several of us were treated to a dinner as a part of this year’s Microsoft Web Developer Summit (great dinner, by the way – Anthony’s in Kirkland, WA). Seems like there was just about a one-to-one ratio at one point of MS employees to PHP developers attending. It was interesting to see how this played out in conversations and in the general flow of the evening.

At the table I was sitting at there was a MS rep from the Windows team, Ani, who was pleasant, engaging and genuinely seemed interested in what “this PHP thing” was all about. Some of her questions could have been answered by a few trips to Google, but overall it was good to see the interest level from someone not in the usual web bubble PHP normally operates in. There were a few great debates that came out of her questions with the most memorable being about SEO. She had asked about our take on it and if it even played a part in the work that we did. Most at the table were of the opinion that, if it’s going to happen, it was someone else’s job – the responsibility of the front end folks as a part of making the site “pretty”.

This and another comment about application structure got me thinking…with a lot of the sites out there going with an MVC pattern for their structure, does this mean a sort of SEO-friendliness is already built in? I’m not talking that black magic, voodoo stuff that lots of firms pass off as SEO consulting. I mean the good placement of data, good content and a well though out site structure. By default, MVC makes this last one super simple. For most frameworks, it’s just a built in part of their routing to make search-engine friendly URLs. Of course, it’s still up to you to fill those URLs with good meaningful content, but it’s a start.

So, do we as developers still have a responsibility to create an application that will, in the end, make more sense to the outside world and to the major search engines? Should we step outside of our bubble and branch out into the wider ecosystem of the application, making sure that what we’re doing fits with the whole?
News from D2SBridge

Posted: December 1st, 2009, 6:29am MST by ThinkPHP /dev/blog - PHP

Today, we would like to present our modifications and updates concerning D2SBridge during the last weeks.

Plugin Functionality
We implemented a plugin system for D2SBridge. Now, you may change or enhance the base functionality by writing own plugins for D2SBridge. For example, we wrote a Plugin in a few lines attaching data submitted by the webform as an email instead of a note. Currently, we are thinking about additional hooks for the plugins in order to simplify and to enhance the capabilities of D2SBridge.

DimDim Plugin
We are also experimenting with a new plugin (consisting of two parts: D2SBridge and SugarCRM) which can be used to connect the drupal forms with a DimDim-Meeting. The workflow is very simple: You create a webmeeting in SugarCRM (we wrote a new module for this purpose), enter the meeting details like start-time & date, and hit the save button. The entered data is used to schedule a meeting on DimDim. Every time you change the meeting details in SugarCRM, the changes will automatically be submitted to DimDim.
The meetings you entered in SugarCRM, may now be chosen via an autocomplete textfield in the drupal webform settings. If you relate a meeting to a webform, the lead/contact found or created by D2SBridge, will be related to the meeting in SugarCRM and will be invited to the meeting. You are able to open a new window and start the meeting in DimDim by just one click within SugarCRM. This way you are able to see all leads/contacts in SugarCRM who have registered for a meeting.

There are also plans to integrate DimDim CSV meeting-reports in order to add a small note to each lead - if the person did actually participate in the meeting he registered for - but we will tell you more about that in the near future.

← November 2009 (152 items) January 2010 (132 items) →

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x

My RSS » Planet PHP » December 2009

Feeds

Planet PHP

Posted: December 31st, 2009, 4:31pm MST by Chris Shiflett

Posted: December 31st, 2009, 4:23am MST by Henri Bergius

Posted: December 30th, 2009, 7:26pm MST by Derick Rethans

Posted: December 30th, 2009, 2:27pm MST by Zend Developer Zone

Posted: December 30th, 2009, 2:18pm MST by John Mertic

Posted: December 30th, 2009, 1:40pm MST by Zend Developer Zone

Posted: December 30th, 2009, 10:49am MST by Paul M. Jones

Posted: December 29th, 2009, 3:40pm MST by Manuel Pichler

Posted: December 29th, 2009, 10:14am MST by Marco Tabini

Posted: December 29th, 2009, 4:01am MST by Michelangelo van Dam

Posted: December 28th, 2009, 4:33pm MST by Danne Lundqvist

Posted: December 27th, 2009, 7:55pm MST by Helgi Þormar Þorbjörnsson

Posted: December 27th, 2009, 11:47am MST by Pádraic Brady

Posted: December 26th, 2009, 8:13am MST by Derick Rethans

Posted: December 26th, 2009, 7:25am MST by Lukas Smith

Posted: December 26th, 2009, 3:45am MST by Sebastian Bergmann

Posted: December 24th, 2009, 11:47am MST by Keith Casey

Posted: December 23rd, 2009, 11:17pm MST by Web Development Blog Â» PHP scripts

Posted: December 23rd, 2009, 10:00pm MST by PHP Advent

Posted: December 23rd, 2009, 8:34pm MST by Zend Developer Zone

Posted: December 23rd, 2009, 8:23pm MST by blog.phpdeveloper.org Â» PHP

Posted: December 23rd, 2009, 4:38pm MST by Pádraic Brady

Posted: December 23rd, 2009, 8:20am MST by Michael Kimsal

Posted: December 23rd, 2009, 6:11am MST by Lukas Smith

Posted: December 23rd, 2009, 6:00am MST by Brandon Savage

Posted: December 23rd, 2009, 5:19am MST by Tobias Schlitt

Posted: December 23rd, 2009, 12:32am MST by Tobias Hauser & Christian Wenz

Posted: December 22nd, 2009, 10:35pm MST by Evert Pot

Posted: December 22nd, 2009, 7:27am MST by Michael Kimsal

Posted: December 22nd, 2009, 7:10am MST by Zend Developer Zone

Posted: December 22nd, 2009, 2:59am MST by Danne Lundqvist

Posted: December 21st, 2009, 10:00pm MST by PHP Advent

Posted: December 21st, 2009, 3:09pm MST by Zend Developer Zone

Posted: December 21st, 2009, 2:39pm MST by Andrei Zmievski

Posted: December 21st, 2009, 11:12am MST by Terry Chay

Posted: December 21st, 2009, 4:58am MST by ThinkPHP /dev/blog - PHP

Posted: December 21st, 2009, 12:20am MST by Fabien Potencier

Posted: December 20th, 2009, 10:00pm MST by PHP Advent

Posted: December 19th, 2009, 10:00pm MST by PHP Advent

Posted: December 19th, 2009, 10:03am MST by Benjamin Eberlei

Posted: December 18th, 2009, 10:00pm MST by PHP Advent

Posted: December 18th, 2009, 3:25pm MST by Web Development Blog Â» PHP scripts

Posted: December 18th, 2009, 2:41pm MST by Andrei Zmievski

Posted: December 18th, 2009, 8:08am MST by Sean Coates

Posted: December 18th, 2009, 6:29am MST by Tobias Schlitt

Posted: December 17th, 2009, 10:34pm MST by Ben Ramsey

Posted: December 17th, 2009, 10:00pm MST by PHP Advent

Posted: December 17th, 2009, 5:44pm MST by ThinkPHP /dev/blog - PHP

Posted: December 17th, 2009, 7:31am MST by Zeev Suraski

Posted: December 16th, 2009, 10:00pm MST by PHP Advent

Posted: December 16th, 2009, 4:00pm MST by PHP: Hypertext Preprocessor

Posted: December 16th, 2009, 3:26pm MST by Tony Bibbs on PHP

Posted: December 16th, 2009, 1:45pm MST by Ruslan Yakushev

Posted: December 16th, 2009, 9:47am MST by Zend Developer Zone

Posted: December 16th, 2009, 3:00am MST by Ian Barber

Posted: December 16th, 2009, 1:45am MST by Evert Pot

Posted: December 15th, 2009, 11:00pm MST by Brandon Savage

Posted: December 15th, 2009, 10:00pm MST by PHP Advent

Posted: December 15th, 2009, 6:59am MST by Ken Guest

Posted: December 15th, 2009, 6:41am MST by Marco Tabini

Posted: December 15th, 2009, 3:09am MST by Fabien Potencier

Posted: December 14th, 2009, 10:00pm MST by PHP Advent

Posted: December 14th, 2009, 6:44am MST by Zend Developer Zone

Posted: December 13th, 2009, 10:00pm MST by PHP Advent

Posted: December 13th, 2009, 4:46pm MST by Ken Guest

Posted: December 13th, 2009, 11:31am MST by ThinkPHP /dev/blog - PHP

Posted: December 13th, 2009, 5:33am MST by Lukas Smith

Posted: December 13th, 2009, 2:03am MST by Tobias Hauser & Christian Wenz

Posted: December 12th, 2009, 10:00pm MST by PHP Advent

Posted: December 11th, 2009, 10:00pm MST by PHP Advent

Posted: December 11th, 2009, 3:04pm MST by Ian Barber

Posted: December 11th, 2009, 2:41am MST by Lorna Mitchell

Posted: December 11th, 2009, 2:29am MST by Kore Nordmann

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x