Finally PHP 5.1 Beta 2 is live. I'm very excited about PHP 5.1 which is another big step for PHP.
Some of the key improvements of PHP 5.1 include:
* PDO (PHP Data Objects) - A new native database abstraction layer providing performance, ease-of-use, and flexibility.
* Significantly improved language performance mainly due to the new Zend Engine II execution architecture.
* The PCRE extension has been updated to PCRE 5.0.
* Many more improvements including lots of new functionality & many bug fixes, especially in regards to SOAP, streams and SPL.
* See the bundled NEWS file for a more complete list of changes.
Everyone is encouraged to start playing with this beta, although it is not yet recommended for mission-critical production use.[Read More]
phpblog 110000AD5E 1,202 Views
I presented an introduction to
One question which came up during the presentation was to do with the Relational Database Access Service and whether it optimizes the SQL queries it creates in order to remove redundancies. The short answer is, "no", but that's simply because it doesn't have to; SDO does the optimization for it.
The first thing to note is that SDOs keep a change summary, however, this summary only holds the information required to re-create the data object's original state, not any intermediate states. This is important when it comes to understanding how the updates are optimized.
Consider an example of a contact database (as described in this article). The contact database table contains a "shortname" column (e.g. "Fred") and a "fullname" column (e.g. "Frederick Flintstone"). Let's assume we've retrieved a set of contact SDOs from the database into the variable
The create and delete cancel each other out and the intermediate value of "Sally Smith" is not recorded, so the resulting change summary would only show that "Sally Barker" had changed her name to "Sally Jones". Consequently, when the Relational Data Access Service is asked to apply the changes back to the database, the only update it would see and perform is the name change.
The resulting SQL UPDATE statement would look like this:
with a parameter list of ("Sally Jones", primary key value, "Sally Barker")
SDO for PHP Project
SDO for PHP documentation
Relational Data Access Service documentation
phpblog 110000AD5E 1,166 Views
One of the most popular articles I've ever written has been about Preventing Image 'Theft'. I wrote it several years ago, but people are still reading it (evidently) and contacting me about it.[Read More]
I've recently had call to use this sort of thing myself, and what I've got now is rather more advanced than described in the original article. For instance, now I transparently intercept images 'going offsite' and replace them with a correctly-sized blank box containing text about the copyright. And for images I want to be basically previewable but not really usable (if people want a usable version they need to contact me) I watermark 'em.
Watermarking a digital image means adding information to the existing pixels. It can be involve adding invisible information for identification purposes, such as the Digimarc technique, or it can be to to visibly degrade the quality of the image, perhaps with a message. I've used both, but it's the latter mechanism I needed most recently.
Watermarking for degradation is an interesting challenge. There's nothing you can do short of actually destroying data to keep a really determined perp from gatting past your defences, but you can make it pretty difficult.
For instance, the degradation watermarking I set up recently uses a watermark with built-in noise, so there isn't a single same-colour region that can be undone. A perp would have to figure out what the watermark pixels are, pixel by pixel, in order to create a mask to remove it. And since I'm using it on dense JPEG images, that's a little difficult.
In addition, the watermark is repeated across the entire image, and not at regular intervals. Each one is jigged a bit at random, so no two previews of the same image should be identical. (Well, modulo repeats of the random sequence.) This keeps a perp from figuring that the watermark is repeated at fixed intervals, and using that to help remove it. Of course, if it accesses multiple previews of the same image, it can eventually probably figure out the pixel settings by comparing them. But I suspect that would be a major chore, too.
Both the replacement-with-notice and the watermarking are done in realtime as part of Apache's response to a Web request. The replacement is very low impact indeed, and doesn't cause performance to deteriorate noticeably, but the watermarking involves actual image manipulation, of megapixel images, and so can slow things down. So you can use the former on almost any server, but the latter really needs a machine with a lot of oomph to keep visitors happy.
You can, of course, get rid of the performance impact by watermarking the images ahead of time, and sending the results normally. That decreases the random factor, though,
and possibly makes the watermark more easily removed.
phpblog 110000AD5E 1,061 Views
I use PHP extensively on almost all of my Web pages. (Just about the only ones that don't use it are on servers that don't have it installed. Mine, of course, all have PHP installed.) In a lot of cases I store the real content in a database, and PHP pulls it out and formats it; sometimes the content is built directly from scanning files and directories.[Read More]
This has advantages and disadvantages, of course. On the pro side, the content is visible immediately. On the con side, the content is visible immediately. :-) Having every page be interpreted has definite performance implications and not just on the origin server. Unless care is taken, the dynamic nature of the page can result in it rarely or never being cached, which hits you in the system and the network. If you pay for your bandwidth by the byte, that can be a huge deal.
Like Sam, I use a mix of languages. For Web pages, I use PHP almost exclusively; for standalone apps I use C, PHP, bash, or Perl, as seems appropriate. In general I use Perl, but if I'm frobbing a database, chances are I'll use PHP unless there's something in CPAN that argues for Perl.
When I first got involved with blogging, in December 2002, I decided to write my own software from the ground up. In PHP. Of course, I'm a bit-twiddler, and did it that way so I'd understand what this 'blogging' thing was all about and how it worked. (Almost as soon as I brought it online, Sam challenged me to take the next step. :-) The result can be seen at my blog.
I hope to go into this subject in more detail in the future, and I definitely intend to say some things about how I'm using PHP to automatically guard my Web servers, but this is just an introductory note after all.