Tag: php
Telcos are Attacking the Internet
I generally try to stay out of politics on this blog, but this time something has to be said, as it affects anyone who uses the internet, at least in the US.
Basically, a number of telcos and cable providers are talking about charging internet content providers — the places you browse to on the internet, places like Google, Yahoo!, Amazon, etc. — fees to ensure bandwidth to their sites. Their argument is that these content providers are getting a 'free ride' on their lines, and generating a lot of traffic themselves, and should thus be paying for the cost of bandwidth.
This is patently ridiculous. Content providers already have to pay for their bandwidth — they, too, have ISPs or agreements with telcos in place, either explicitly or via their hosting providers. Sure, some of them, particularly search engines, send out robots in order to index or find content, but, again, they're paying for the bandwidth those robots generate. Additionally, people using the internet are typically paying for bandwidth as well, through their relationship with their ISP. What this amounts to is the telcos getting paid not just by each person to whom they provide internet access, but every end point on the internet, at least those within the US.
What this is really about is telcos wanting more money, and wanting to push their own content. As an example, let's say your ISP is AOL. AOL is part of Time Warner, and thus has ties to those media sources. Now, those media sources may put pressure on AOL to reduce bandwidth to sites operated by ABC, CBS, NBC, FOX, Disney, PBS, etc. This might mean that your kid can no longer visit the Sesame Street website reliably, because AOL has reduced the amount of bandwidth allowed to that service — but any media site in the TWC would get optimal access, so they could get to Cartoon Network. Not to slam Cartoon Network (I love it), but would you rather have your kid visiting cartoonnetwork.com or pbskids.org? Basically, content providers would not need to compete based on the value of their content, but on who they can get to subscribe to their service.
Here's another idea: your ISP is MSN. You want to use Google… but MSN has limited the bandwidth to Google because it's a competitor, and won't accept any amount of money to increase that bandwidth. They do the same with Yahoo! So, now you're limited to MSN search, because that's the only one that responds reliably — regardless of whether or not you like their search results. By doing so, they've just artificially inflated the value of their search engine — without needing to compete based on merit.
Additionally, let's say Barnes and Noble has paid MSN to ensure good bandwidth, but part of that agreement is a non-compete clause. Now you find your connections to Amazon timing out, meaning that you can't even see which book provider has the better price on the book you want; you're stuck looking and buying from B&N.
Now, let's look at something a little more close to home for those of us developing web applications. There have been a number of success stories the last few years: MySpace, Digg, and Flickr all come to mind. Would these endeavors have been as successful had they needed to pay multiple times for bandwidth, once to their ISP and once each to each telco charging for content providers? Indeed, some of these are still free services — how would they ever have been able to pay the extra amounts to the telcos in the first place?
So, basically, the only winners here are the telcos.
Considering how ludicrous this scheme is, one must be thinking, isn't the US Government going to step in and regulate against such behaviour? The answer, sadly, is no. The GOP doesn't like regulation, and so they want market forces to decide. Sadly, what this will likely do is force a number of content providers to offshore their internet operations — which is likely to have some pretty negative effects on the economy.
The decision isn't final — efforts can still be made to prevent it (the above link references a Senate committee meeting; there's been no vote on it). Call your representatives today and give them an earful. Tell them it's not just about regulation of the industry, but about fair competition in the market. Allowing the telcos to extort money from content providers will only reduce the US' economic chances in the world, and stifle innovation and choice.
Automating PHPUnit2 with SPL
I don't blog much any more. Much of what I work on any more is for my employer, Zend, and I don't feel at liberty to talk about it (and some of it is indeed confidential). However, I can say that I've been programming heavily on PHP5 the past few months, and had a chance to do some pretty fun stuff. Among the new things I've been able to play with are SPL and PHPUnit — and, recently, together.
PHP error reporting for Perl users
On perlmonks today, a user was needing to maintain a PHP app, and wanted to know what the PHP equivalent of perl -wc script.pl was — specifically, they wanted to know how to run a PHP script from the commandline and have it display any warnings (ala perl's strict and warnings pragmas).
Unfortunately, there's not as simple a way to do this in PHP as in perl. Basically, you need to do the following:
-
To display errors:
- In your
php.inifile, setdisplay_errors = On, or - In your script, add the line
ini_set('display_errors', true);
- In your
-
To show notices, warnings, errors, deprecation notices:
- In your
php.inifile, seterror_reporting = E_ALL | E_STRICT, or - In your script, add the line
error_reporting(E_ALL | E_STRICT);
- In your
Alternatively, you can create a file with the lines:
<?php
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', true);
and then set the php.ini setting auto_prepend_file to the path to that file.
NOTE: do not do any of the above on a production system! PHP's error messages often reveal a lot about your applications, including file layout and potential vectors of attack. Turn display_errors off on production machines, set your error_reporting somewhat lower, and log_errors to a file so you can keep track of what's going on on your production system.
The second part of the question was how to run a PHP script on the command line. This is incredibly simple: php myscript.php. No different than any other scripting language.
You can get some good information by using some of the switches, though. -l turns the PHP interpreter into a linter, and can let you know if your code is well-formed (which doesn't necessarily preclude runtime or parse errors). -f will run the script through the parser, which can give you even more information. I typically bind these actions to keys in vim so I can check my work as I go.
If you plan on running your code solely on the commandline, add a shebang to the first line of your script: #!/path/to/php. Then make the script executable, and you're good to go. This is handy for cronjobs, or batch processing scripts.
All of this information is readily available in the PHP manual, and the commandline options are always available by passing the --help switch to the PHP executable. So, start testing your scripts already!
Cgiapp dual releases
Today, I have released two versions of Cgiapp into the wild, Cgiapp 1.8.0 and Cgiapp2 2.0.0rc1.
Cgiapp 1.8.0 is a performance release. I did a complete code audit of the class, and did a number of changes to improve performance and fix some previously erratic behaviours. Additionally, I tested under both PHP4 and PHP5 to make sure that behaviour is the same in both environments.
However, Cgiapp 1.8.0 markes the last feature release of Cgiapp. I am deprecating the branch in favor of Cgiapp2.
Cgiapp2 is a PHP5-only version of Cgiapp. Some of the changes:
-
Cgiapp2is an abstract class, with the abstract methodsetup(). Now it is truly non-instantiable! - Cgiapp2 makes extensive use of visibility operators. Key methods have been marked final, some methods are now protected, others static. See the changelog for more information.
- Cgiapp2 is now
E_STRICTcompliant. - Cgiapp2 implements the CGI::Application 4.x series callback hook system. This is basically an observer pattern, allowing developers to register callbacks that execute at different locations in the runtime.
- Cgiapp2 adds some extensive error and exception handling classes, including observable errors and exceptions.
- I created a template interface. If implemented, a template engine can be plugged into the architecture at will — at the superclass, application class, and instance script level, allowing developers to mix-and-match template engines or choose whichever matches their taste, without having to rewrite application code. Three template plugins are included:
Cgiapp and Cgiapp2 are available at Sourceforge.
Keep reading for more information on the evolution of Cgiapp2.
XP + Cygwin + coLinux == Productivity
I wrote earlier of my experiences using Windows XP, a move I've considered somewhat unfortunate but necessary. I've added a couple more tools to my toolbox since that have made the environment even better.
Cgiapp 1.7.1 Released
I was able to roll a long-needed (and by some, long awaited) bugfix release of Cgiapp this morning. Cgiapp 1.7.1 corrects the following issues:
-
Cgiapp5::run()was corrected to callquery()instead ofcgiapp_get_query()(which caused a fatal error) -
Cgiapp::__call()andCgiapp5::__call()now report the name of the method called in errors when unable to find matching actions for that method.
As usual, downloads are available on my site as well as via SourceForge.
Update: The link on my site for downloading Cgiapp has been broken; I've now fixed it.
Simple Caching for PHP
I ran across an article on "How to build a simple caching system, with PHP" on PHPit today. Overall, it's a fairly decent article, and uses some good principles (using the output buffer to capture content, using a callback to grab the captured content). There are a few minor improvements I'd make, however.
Zend PHP Expo Presentation
Mike and I have just finished our talk on "Setting Up PHP". The number of attendees was N + 1, where N is the number of speakers… which was to be expected, as we were presenting opposite a session on web services, Shiflett's PHP Security talk, and a crash course on the ZCE. However, it's undoubtedly the best presentation missed by attendees. :-)
Review: php|architect's Guide to PHP Security
I flew in to San Jose today to visit Zend, and later attend the Zend/PHP Conference and Expo (two days left… register now if you haven't, and have the time to attend; the conference sessions promise to be very interesting).
During the flight, I had plenty of time to go through Ilia's Guide to PHP Security, which I'd ordered several weeks ago, but hadn't had time to read since.
Zend Conference
Around the time I was hired by Zend, I was asked, along with Mike Naberezny, to fill in for a tutorial session entitled 'Setting up PHP' for the upcoming Zend/PHP Conference and Expo. The basic premise of the session is to give a step-by-step tutorial on how to setup and configure PHP for various scenarios, such as development, testing, and production.
Mike and I have been working in parallel developing ideas and outlines for the session, and I'm fairly excited to have the opportunity. However, if you're attending the conference and, in particular, this session, I'd love to hear any input you might have — any tricks you'd love to learn, configuration settings you don't understand, use cases you might need. Leave a comment!