As Davey Shafik noted recently, he and I have been working together on some web services for the Zend Framework. In doing so, I've become very familiar with PHP 5's Reflection API, and am coming to love it.
When I first read about the Reflection API in a pre-PHP 5 changelog, my initial reaction was, "who cares?" I simply failed to see how it was a useful addition to the language. Having done some projects recently that needed to know something about the classes they are using, I now understand when and how it can be used. It shines when you need to work with classes that may not be defined when you write your code — any code that dispatches to other classes, basically.
Except when an apt-get based install goes bad, that is, like it did Saturday evening. This is the tale of how I got it back up and running.
I may work at Zend, but I've never been a fan of IDEs. They simply don't suit my programming style. I can usually keep track of file locations in my head pretty easily, and what I really need is a blank slate on which I can write, and one that doesn't consume resource that can better be used running web servers and other programs. Syntax highlighting, good indentation — these are important, but you can get these from good, minimal text editors very easily. Vim is my editor of choice.
I will admit, though, that one area where I have had IDE-envy is the area of code completion. I often find myself doing quick lookups to php.net or perldoc to determine the order of arguments to a function or method call, or checking for the expected return value. Most of the time, this doesn't take much time, however, so I just live with it.
Today, however, cruising through the blogosphere, I came across an article showcasing some new features of Vim 7.0, and discovered Vim 7's code completion.
Basically, while in insert mode, you can type
<C-x> <C-o> to have vim attempt to autocomplete the current keyword. If more than one possibility exists, it shows a dropdown, and you can use your arrow keys to highlight the keyword that you wish to use.
But it gets better! Not only does it do this kind of autocompletion, but it also opens a small 'scratch preview' pane showing the function/method signature — i.e., the expected arguments and return value!
I thought I had little need for IDEs before… now I have even less! Bram and the rest of the Vim team, my hat's off to you for more fine work!
In response to Scott Johnson's request for advice on variable functions, I decided to run some benchmarks.
<rant>Writing benchmarks is easy. Yet I see a lot of blog entries and mailing list postings asking, "Which is faster?" My first thought is always, "Why didn't they test and find out?" If I ever have a question about how something will work, I open up a temporary file, start coding, and run the code. It's the easiest way to learn. Also, it teaches you to break things into manageable, testable chunks, and this code often forms the basis for a unit test later.
Back to benchmarking. Scott asks, "Is there a real difference between
call_user_func_array and the variable function syntax i.e.
The short answer: absolutely. The long answer? Read on.
I upgraded Serendipity today, due to the recent announcement of the 1.0 release, as well as to combat some rampant issues with trackback spam.
I've been very happy with Serendipity so far; it just runs, and the default install gives just what you need to get a blog up and running, and nothing more; any extra functionality comes via plugins which you, the blogger, get to decide upon.
Additionally, it's incredibly easy to upgrade. Unpack the tarball, rsync it over your existing install (I rsync it, because I don't use 'serendipity' as my directory name), visit the admin, boom, you're done. I've upgraded several times, and never lost data, nor configuration settings.
My primary reason for the upgrade was, as noted earlier, to combat trackback spam. As of this morning, I had 15,000 pending trackbacks, none of which appeared to be valid (if any of them were, and you're not seeing yours, I'm very sorry; I deleted them en masse). These had accumulated in less than a month — that's an average of about one every 3 minutes.
Since upgrading, and using the Akismet service, I've received not a single spam trackback. Needless to say, I'm happy I performed the upgrade!
If you're a Serendipity user, and haven't upgraded to 1.0.0 yet (or one of it's reportedly very stable release candidates), do it today — you have nothing to lose, and a lot of lost time to gain!
This is the second in a series of Cgiapp2 Tutorials. In this tutorial, I cover creating what I call 'Pluggable Applications', applications that can be distributed and customized to work with other sites.
I ran across a blog post entitled "Why the Light Has Gone Out on LAMP" earlier today, and felt compelled to respond.
First, a rant: somehow, this article got posted on Slashdot. I've never heard of the guy who posted it, and some quick googling shows that he's a pythoner. He's simply fueling the language wars, and the slashdot post opened up a huge debate that need not have occurred. I think it was irresponsible of the Slashdot editors to post it.
In the post, the author makes an analogy of using PHP + MySQL as the equivalent of using BASIC, and then uses a quote that claims BASIC "has become the leading cause of brain-damage in proto-hackers."
I'm sorry, but using a language doesn't cause brain damage. And there are many levels to programming. And using Python, Ruby, C, C++, Java, etc., does not automatically make you a better programmer than those using one of "those other languages". You can write crap code in any language. You can also write great code in just about any language.
Programming takes practice; programming well takes a lot of practice. You get better at it by learning more about programming practices, and applying them to your language. Part of programming is also learning when a particular language is suited to a task, and when it isn't. Python works for the web, but it's not particularly suited to it; similarly, you can write web servers in PHP, but that doesn't mean you should.
Stop the language wars already! Stop writing incendiary pieces about a language you don't use regularly or never gained particular proficiency in, and code already!
This is the first in a short series of tutorials showcasing some of the new features of Cgiapp2. In this tutorial, you will see how easy it is to switch template engines in Cgiapp2-based applications.
If you're not familiar with darcs, it's a revision control system, similar to GNU Arch and git; changes are kept as patch sets, and repositories are branched simply by checking them out. This makes darcs repositories very flexible, and incredibly easy to implement. Static binaries are available for most systems, which makes it easy to install on systems to which you have no administrator rights.
A perl CGI script is shipped with darcs, and provides a web-based repository viewer. It utilizes darcs'
--xml-output switch to create XML, which is then transformed using XSLT. However, there are some issues with the script; it is somewhat difficult to customize, and makes many assumptions about your system (location of configuration files, repositories, etc.). To make it more flexible, I ported it to PHP, using Cgiapp2 and its XSLT template plugin and Phly_Config.
I have released this PHP darcs repository browser as Phly_Darcs, which contains both a Model and Controller, as well as example XSLT view templates. It is currently in beta as I'm still developing PHPUnit2 tests for some of the model functionality, as well as debating the ability to add write capabilities (to authenticated users only, of course).
Update: fixed links to internal pages to use absolute urls.
After several months of testing and some additional work, I've finally released the first stable version of Cgiapp2.
It is available at both the Cgiapp site as well as via my Phly PEAR channel.
There were a ton of changes while creating the Cgiapp2 branch. From the release notes:
The 2.x series of Cgiapp completes a PHP5 port of Cgiapp2. PHP5 compatibility changes include visibility operators for all properties and methods, declaration of many methods as static and/or final, and the use of exceptions for catching run mode errors. Most notably, though, is the fact that Cgiapp2 is now an abstract class, with one abstract method, setup(); this enforces the fact that you must subclass Cgiapp2 in order to create your application.
New features include:
Callback hook system. Cgiapp2 is now an observer subject, and has hooks at several locations within the application. Additionally, it provides a method for registering new hooks in your applications. The callback hook system replaces the plugin system introduced in Cgiapp 1.7.0.
Template engines are now relegated to plugin classes, and should implement the Cgiapp2_Plugin_Template_Interface. Shipped template engines include Smarty, Savant2, Savant3, and XSLT.
Improved and more extensive error handling, which has been expanded to exceptions as well. Cgiapp2_Exception and Cgiapp2_Error are both observable subjects, with interface classes for implementing observers. This allows the developer to tie into exceptions and errors and perform actions when triggered (Log and Mail observers are implemented for each).
Cgiapp2_FrontController class. This is a simple front controller that dispatches to public static methods in registered classes. Included is a 'page' controller for handling static pages.
I have included migration notes, for those migrating from the 1.x series of Cgiapp; there is very little that you need to do, but some PHP5 changes necessitate some compatability breakages, and the new callback hook architecture and the ability to separate the template engines into plugins introduced some slight changes as well.
In testing the release, I have been writing some apps that take advantage of some of the new features, and I will be writing some tutorials in the coming weeks.