PortLAMP Courses: Monday

by Daniel Smith


Here's a look at sliver of Monday's OSCON activity. I went
to an Advanced PHP talk, a Jabber "Bootcamp", and a BOF
where we talked about a range of Open Source issues (acceptance
in corporations seeming to be a point we kept coming back to).



PHP





Sterling Hughes gave a talk on Advanced PHP today.
The slides are online.
Sterling loves performance tweaking, and let us know that up front.
He's a very informative and entertaining speaker.




The major areas of PHP he went over were: Testing & Debugging
Documentation, Error Handling, Security, and Performance. I will
touch on some of the highlights. Some aspects of this
tutorial (and other PHP sessions) will be weaved into a roundup
of PHP impressions at the end of the week.




PHP Testing





Sterling is a proponent of writing unit tests before writing code.
He believes that writing code, and then writing tests afterward,
is a slower way to develop in PHP. In order to do unit testing,
he suggests using PHPUnit,
which can be installed via:



% pear install PHPUnit




Another angle is stress testing. Sterling is working on a tool
named "Cherry", which should be ready in about a week (watch the
php.net site for details)





PHP Documentation




There are many forms of documentation, ranging from comments
in the source, pretty architecture diagrams that don't
map well to reality, bug reporting tools (BugZilla), wikis,
and so on. A few tools that Sterling recommends:




Another area is API docs. Sterling advocates using a JavaDoc
style of documenting the API, and running phpDocumentor on it. This can be installed via:



% pear install PHPDoc





PHP Error Handling





Any sufficiently advanced bug is indistinguishable from a feature.


- Rich Kulawiec




There are four main areas of error handling: receiving errors (lots of "if"
statements are inefficient), exceptions (use try / catch), shielding (set the PHP variable display_errors=off, use a custom error handler), and logging (watch out for tabs! Be sure to escape your data that goes to a log).
There's a lot more to say on this, so please check over his slides. He has some very good tips.




PHP Security




Sterling showed some of the security pitfalls that can easily trip
up a developer. A big problem area is command and SQL statement injection,
where an evil end-user is able to add commands and/or database
statements to a script. Problems are made worse by running
Apache as root (don't do that!), since a command injection
attack can do anything at that point.




Some other security highlights:


  • always turn off magic_quotes_gpc

  • always turn off register globals

  • escape shell commands with EscapeShellArg() and
    EscapeShellCommand()

  • encrypt cookies that have sensitive data

  • run as an unpriviledged user



Another big one is infrastructure. It is one thing to have
Apache & PHP configured to be secure, but do not forget the
machine they are running on! The machine must be locked
down as well. (my emphasis: think in terms of "what is
the weakest point in the system?")




PHP Performance Optimization





Premature optimization is the root of all evil


--Donald Knuth




I think Sterling likes to talk about performance optimization more
than any other aspect of PHP. A recommended tool is APC - Alternative PHP Cache. It can be installed via:



% pear install apc




This is very important, because it can often take
PHP longer to compile classes than to execute them.




Know how to set Cache-Control headers, in order to cut down
(dramatically, in some cases) the number of hits being passed
through to PHP.




Another area is benchmarking and profiling. The Xdebug extension is
very helpful: http://xdebug.derickrethans.nl/




Two pear packages to use in benchmarking may be installed via:





% pear install Benchmark_Timer
% pear install Benchmark_Iterate






A not so obvious costly operation in PHP4 is hash table lookups.
Every time you reference a hash index, a check is done to see if
the index is numeric. This can really slow things down in
a loop. Sterling says this is much better (faster) in PHP5.




Again, these are highlights. See the slides. If you ever get a chance to see Sterling talk
about PHP, go see him!





Productivity




The Jabber Bootcamp was very technically oriented, but
there's a huge productivity angle to it as well. This
may not be so obvious to those of us who know it
just from instant messaging functionality. My only exposure
to Jabber before this conference
was the Exodus client
on Windows, and Gaim
on Linux.




Some tech notes: A couple of preliminary things to know about Jabber, aside from the
bridges it provides to many IM systems, is that it is an open
protocol, and that it uses a pair of XML streams to transfer data. The complexity
resides mainly on the server side, making clients easy to write.
Jabber is great at passing structured data around. It is also
good at detecting the presence of people AND machines (think
of a buddy list for an app that can open a connection to
a Jabber server, or to you personally)




Getting back to productivity, I can see Jabber coming into
further use in these areas:


  • group chat. Jabber has a better control hierarchy
    than IRC, which prevents abuse/takeovers.
  • videoconferencing: there is a draft for a method of doing
    stp/ng videoconferencing.

  • running commands remotely: Jabber can handle multiple logins
    from a person or machine, with each one implementing different
    functionality (called a resource in Jabber). A resource
    that parses incoming info queries can easily map them
    to commands, run them, and return the output.







I won't include the notion of Web Services directly into
productivity at this point of the week (is WS a trend,
productivity enhancer, or dessert topping?) I will say
that Jabber, being a pair of opened XML streams (one connection
from each side), has great potential in this area. It
is faster than HTTP, and also handles a wide range of
encryption options. It can also compress the streams
to save on bandwidth (though, I am told, one or more
of the forms of encryption it uses also handles compression)




More info on Jabber for developers can be found at jabberstudio.org. Users can go to jabber.org to see a list of clients.



Trends




Open Source, in my mind, is beyond my idea of Trend. It's
a permanent reality. An old project of mine was organizing
a huge collection of what we used to call "public domain
software" at Autodesk in the early 1990's. I made a lot
of packages available from a local network mount point of
/usr/local/pubware (public, beer...) So for me, the idea
of getting a large company going on non-commercial
software packages (in this case, for in-house use) goes
way back. A lot of the talk at the "Daily Debriefing"
BOF, presented by Steve Mallett (the webmaster of opensource.org) and Matthew Langham, revolved around
the idea of how Open Source is making inroads into large companies.
The trend here is simple: lots of decision makers are starting
to "get it".






"No one should buy their first copy of Linux, but they should buy their second"


-- Steve Mallett





Matthew answered some questions about how German companies
respond to Open Source. He states that some leading German
Telcos are using Apache/Cocoon. Munich will save a lot
of money when the local government switches from Windows to Linux,




There is a feeling that small companies are more in touch with OS.
Large companies often don't see the value of using
OS software, or of making changes available back to the community.
They want their proprietary systems, etc. The idea of
"free" scares managers, because they think "free" denotes
"bad quality" (one of the factors in how "Open Source" got
its name - Open Source is inclusive of Free Software, but
not the other way around)




I asked about the possible "splintering effect" of so many
Linux distributions out there. How does a company choose?
They have one provider of Windows, one of Mac OS X, and a
multitude of Linux offerings. One reply from an attendee
was that his large company went with Red Hat, in part
so that they have a responsible contact to fix problems,
but also so that their money would be spent to develop
software which would go back to the community.
Companies want someone they can call (and perhaps blame).
The trend is that many organizations seem to be in
an evaluation stage. Decision makers in those places
will be swayed by financial impact, but will want to cover
their legal bases ("who's responsible for developing this?"),
and will want to be assured that Open Source will around for
some time to come.




If you are at OSCON, what are your impressions so far?