Most websites employ a simple authentication mechanism generally consisting of a username and a password. While this method is certainly acceptable and secure for most applications, I want to take a minute to explore a more complex and, if employed correctly, more secure method of authenticating a user to a website.

This method employs the public key infrastructure (PKI) via client based SSL PKCS12 certificates.

First you need to make sure your server is conigured to use SSL properly. Setting up SSL in Apache is beyond the scope of this post, but here is a great HOWTO on it. You’ll also need to make sure you configure Apache to export the SSL variables it gathers to PHP.

What About Reuse? The best way to attack the essence of building software is not to build it at all. Package software is only one of the ways of doing this. Program reuse is another. Indeed, the promise of easy reuse of classes, with easy customization via inheritance, is one of the strongest attractions of object-oriented techniques.

As is so often the case, as one gets some experience with a new way of doing business the new mode is not so simple as first appears.

High-level language. The chief reasons for using a high-level language are productivity and debugging speed. We have discussed productivity earlier (Chapter 8). There is not a lot of numerical evidence, but what there is suggests improvement by integral factors, not just incremental percentages.

The debugging improvement comes from the fact that there are fewer bugs, and they are easier to find. There are fewer because one avoids an entire level of exposure to error, a level on which one makes not only syntactic errors but semantic ones, such as misusing registers. The bugs are easier to find because the compiler diagnostics help find them and, more important, because it is very easy to insert debugging snapshots.

Here is an excellent comment attached to a recent story posted on Slashdot:

So why are people – especially those in the industry – opposed to software patents? It’s not because they don’t think software is inventive. It’s because they think that the patents are a drag on the industry. That they’re pointless at best, and actively harmful at worse. And comparing us to our foreign rivals who lack these patents seems to confirm this.

For the past few years I’ve adopted an attitude and corresponding strategy when it comes to information systems which is basically this.

Stuff happens.

Computers break, drives crash, kids try to see if CD drives will cure play-dough, “somebody” causes virus infestations to occur.

In short. Stuff happens.

So I’ve decided that rather than try to prevent any of these things from happening. A truly impossible feat. It is better to plan in advance for these events. In other words, view information systems as if their malfunctioning is a foregone conclusion and plan accordingly.

Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.

Fred Brooks, in his excellent work, The Mythical Man-Month, has this to say about why we enjoy programming.

The Joys of the Craft Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts different superset of the specifications. It is the specifications that should be generous, not their interpretation. - Doug McIlroy, quoted from The Art of UNIX Programming, pg 21

This is the reason web development is so difficult. Every now and then I run across someone who considers web development to not be “real programming”. I suppose that is because web developers are not only faced with being generous in what they accept by way of input but also because they must account for a wide variety of environments (browsers), each of which requires slightly different output in order to achieve the same effect.

I’ve been working on a rather large web application which is responsible for combining data from a variety of sources and presenting the data to the end user in a clean, unified fashion. During this process we sometimes run into cases where multiple related calls are made, each to perform some transformative work on a single set of data. We decided these calls could be made in a more parallel fashion and as such started looking into ways of parallelizing PHP so that relatively expensive operations could be performed at the same time and then the results combined in the end.

Simple JSON-RPC has been updated to 1.0.0. This new version includes a brand new event messaging system making it possible for classes to react to events generated by the Simple JSON-RPC framework.

Through simple event messaging, your RPC classes are now able to react to and even interact with servlet configuration, context, request, and response objects. To use this facility your class needs to extend the new JSONRPCEventListener interface and implement the messageReceived method, accepting one argument of the JSONRPCMessageEvent type.