PHP :: a programmer's best friend

Clay Loveless recently posted a small rant [1] about loner applications, and that inspired me to write up a comment of sorts.

I think that the interoperability Clay wants requires out-of-the-box thinking, but sadly most of the programming world lives in tight boxes. To change that tide would require a lot of dedication and time, both of which I for one am not prepared to invest.

It is really quite sad, but the time and effort I need to get the author(s) of any piece of software to become aware of the non-interoperability with software XY I prefer to invest in getting a solution done - especially since the answers are usually "works for me", "don't need software XY", "it's open source, fix it yourself", "nobody needs that except you", "no time, maybe this winter". I usually try contacting the authors in case I should get lucky, but tend to avoid those kinds of discussions as they lead nowhere.

I think that one of the core reasons for the lack of interoperability is the reprogramming the wheel syndrome. I did that quite a few times myself, and while it may often be because the programmer feels he can do it better, I think there is more to it than just that. These are a few issues I can think of on the spot:

• Lack of knowledge/training in development paradigms
• Mislead prioritizing of featuresets
• Ignorance of existing tools, either willing or unwilling
• Lack of interest/motivation to find out if there are existing libraries for task XY
• Confidence that it is easy and fast to develop on one's own (like database abstractions and authentication layers)
• Unwillingness to conform to existing APIs
• Lack of understanding of existing APIs
• Stressed work environments that do not allow for research of existing tools (or training, for that matter)
• General mistrust of external libraries

I am sure a psychiatrist specializing in modern software developers would be able to find quite a bunch more issues, but I am not sure I want to know about that in such detail after all.


Expectations, Approaches

This is one more issue that I feel compelled to write about, since it is the reason why I have reprogrammed the wheel a few times in the past, and actually still do: different approaches to a problem.

As an example, have you ever wondered why there are really that many CMSs out there? Is it really because someone said "I can do it better"? That may very well be the case, but why did he/she think so? I think it is because that someone had a different idea of how a CMS should work, dismissing the other system because it did not match his expectations. Like the users using a software like a CMS will be more at ease with one or the other system, developers will be more at ease with one or the other library. PEAR's HTML_QuickForm [2] essentially does the same than patForms [3], but in a different way - why does one developer choose the one over the other? The choice is not always based on the featureset.

I know that when I look at a library and it does not work the way I expect it to, I am easily tempted to find another (if possible) or think of writing one of my own. My friends and colleagues have largely succeeded in curing me of the syndrome, like by teaching me how to use wrappers to overcome the awkwardness of using an "alien" API. Now I usually only program a new wheel when there are not really any good libraries for the task at hand, or the library of choice has serious issues.


Real life and productivity vs interoperability

When I started my own business, I knew I would need an application that would help me build the websites for my customers, so I started looking around. There are many great frameworks and CMSs out there, and I took a good look at them. My decisionmaking was based on a few simple rules:

The system had to

• allow complete freedom of layout
• feature a multilingual frontend and administration
• be extensible to add any kind of features
• have enough modularity to allow frequent structure changes
• be secure
• work under PHP4 (most of my customers run on shared hosting)
• be open source for easy adjustment to custom needs
• have a user-friendly and self-documenting interface for endusers
• have an administration sdk to easily add new administration features
• take care of all redundant website building tasks
• allow me to let loose my customers in the administration interface
• allow me to use third-party libraries (interoperability )
• be around for a while

In everyday use, the goals were

• to empower me to keep the quality as high as I want it to
• to allow me to reduce my prices to lessen the gap with the discount offers of the competition
• to give me an edge on development times versus the competition

I don't want to turn this post into a feature comparison, so I will skip that step. After reviewing several frameworks and CMSs, I realized that none would fit what I wanted. Only a custom solution would work, because for the rate of development I targeted I needed a tool that functions on a level I can comprehend. Inspired by patPortal, I planned and started the development of SimpleSite [4]. As a strictly solo project at first and due to the development timeline priorities, interoperability was the least of my worries. Even now, after about a year and a half of constant development it is still lacking in that regard. However, I have made sure that it is interoperability-ready: all the required interfaces and structures are built to allow swapping components as you see fit.

I think that knowing how to prepare for interoperability and adding it to your application development plans is much more important than actually offering it, as it makes the job for other developers that much easier. I also know that it is not always that simple either however - in SimpleSite, the templating engine of choice is patTemplate. While you can use any template engine you like in your modules, the main structure is always handled by patTemplate, and there are related helper methods that only work with patTemplate. It is sometimes really a matter of weighing the development effort and related costs against the added value interoperability would add.


Related links
[1] Clay loveless' "Stop writing loner applications" post
[2] PEAR HTML_QuickForm
[3] patForms
[4] The SimpleSite development portal

If like me, regular expressions are constantly nagging at you because you just can't get the knack of them, you'll be happy to learn that I have finally found that software I have been waiting for all these years: RegexBuddy. Behind this mindbogglingly dull name hides a very nice visual regular expression editor, debugger, tester and optimizer. Regular expression nirvana!

I am a completely lost case regarding regexes, so I have purchased a copy - and I can honestly say that's the most well spent money I ever spent on software (with the exception of Photoshop, I think). The integrated regexp parser tree view shows you exactly what a regexp is made of, what it matches, where you could optimize it as well as correct common errors. It supports Perl-Compatible regexes as well as POSIX extended ones, has integrated PHP syntax highlighting... I'll stop here before anyone thinks I am affiliated with the creators of the software (but you were probably already thinking just that).

As pictures tell more than words, I'll let these screenshots speak for themselves:



The regex wizards out there will probably laugh at this, but I can highly recommend it if you want to learn regular expressions or simply to be able to make some of your own without external help

Yesterday we released the first beta of patForms, following our second alpha release. There has been a lot of activity around patForms lately, and most notably a new lead developer has joined the team: Sven Fuchs. Among other things he has added a complete layer that allows patForms propel integration, and has contributed new renderers.

Quick overview of changes:

• A lot of bugfixes, subpackages more stable
• Propel integration
• New renderers: Smarty, PHPTal and HTML_Template_Flexy
• Form namespaces
• New rules and storages
• Enhanced parser
• Minor enhacements and new features

With all the bugfixes and enhancements in this new version, the whole package has become a lot more stable and along with the new functionality has taken a step more towards making working with forms fun We are planning to make a first stable release in october, so we need your help in weeding out the leftover bugs!

If you are using patForms in your projets, please upgrade and test the new version (please see the section on upgrading further down in this post for additional notes). If you do not know patForms yet, I think this is a good time to discover the projet. With the extensive and comprehensive examples collection, you can start working with it in a breeze!

You can report any bugs or feature requests in our new Trac-powered project manager, where you can also find a documentation wiki.

[1] Download via our PEAR channel server
[2] Download via the traditional download page
[3] Project manager (bugs, feature request, wiki)
[4] Online examples collection