12 Jan 2009

Developing Internal Business Applications with PHP

PHPImage via Wikipedia

Recently, my company has decided to go full (or mostly) open source by moving away from Microsoft technologies. This is a particularly exciting venture to be part of, but in order to explain what I mean, I need to go back a bit and explain the history of the company.


Since its inception, the company has been a traditional LAMP stack. Over time, some internal business applications were needed to be developed. The initial platform to solve this requirement was Microsoft Office and specifically Access database and some Excel sheets. Later on, more and more VBA programming was added to the Access database. At some stage, a decision was made to move to VB.NET and port the VBA/VB6 code to it.
So far, this story is not that unique and I am sure many of you reading this can either relate to it or know of examples from other places.

There were issues moving to VB.NET from the start. It took over a year to finally move to it with many complications and a lot of resources invested in it during that time. After some time, the resources depleted and 1 developer was left to maintain the system.
With time, the application stagnated and the 1 developer could not keep up with the bugs and requirements for new features.

The Present

At this stage I came into the company and I decided that some serious work had to be done to improve the internal business application. I had made a plan to fix and improve the existing code base but saw that it would take a considerable amount of time and energy as well as expertise that we did not have.
At this point, I took a look at other parts of the company. The company has a very good history with open source products. The relatively new PHP team was accomplishing quite a lot of things. All the servers are on various flavours of Linux and maintained well.

The only parts that were holding the company back were closed source technologies. Specifically, incompatibilities between 3rd party applications, printers and forced networking standards that come with closed source. The cost for .NET developers was also an issue.
It seemed to me that the culture of the company is more aligned with open-source and ultimately, that would be the direction the company should follow. The only problem was that, because of initial convenient and easy-to-use application, the company was locked in to a now costly and constricted system.

The system that was chosen was PHP. From one point of view, PHP was the obvious choice, considering the expertise the company has. From another point of view, selecting a web-based technology to replace fat clients with rich GUI, isn’t the most obvious choice.
Considering all the different points (and after being grilled by the executives a bit), the decision was made mainly because of our strong history, achievements and expertise with PHP and Linux. The difficulties that PHP might have to replace the VB.NET system were researched and solutions were offered.

The Official Reasons to Move to PHP from VB.NET

  • To cut down costs and unify technical support expertise. It is difficult and costly to support multiple systems technologies.
  • To reduce complexity and speed up development time. The company has had a lot of success delivering products and features with PHP and believes that this success can be replicated for the internal business application.

Full Steam Ahead

When making this system it is very important to make sure that the system will be very stable, maintainable and flexible for future changes. It would need to prove that it can overcome the difficulties that the old system had troubles facing. After that, development speed is crucial as all new features will have to be put on hold until all the system (or at least some parts of it) is rewritten.

So the important factors were the quality and flexibility of the code as well as speed of development. I decided that in order to achieve these goals, we would need to use frameworks, tools, add-ons and coding standards. The idea is to leverage existing open-source products and best practices to save time and ensure quality. It is also important to make sure that by using the same tools and following the same coding standards, the code will be maintainable for many years to come.

The List of Technologies

I have compiled a detailed list of technologies, open-source products, frameworks, tools and coding standards we plan to use to get this project done properly. All of these are supposed to lay the foundation for a rigid and structured development process.

  • LAMP Stack - PHP 5, MySQL 5.1 – for improved replication and partitioning, Ubuntu Server and Apache Web Server
  • Zend framework – This is something the company has chosen a long time ago and it’s something we plan to continue with.
  • APCPHP accelerating to speed up bootstrapping.
  • Memcached – To speed up database interactions. We came to the conclusion that memcached sped our whole system by a factor of 40.
  • Doctrine ORM – I didn’t want us to spend a second of a developers time on mapping database tables to classes, so I wanted an ORM. Doctrine seemed to have a better website then Propel, so we chose that. So it’s literally a case of judging a book by its cover.
  • YahooUI Javascript Framework – After my developers being biased to jQuery and I was biased for ExtJS, we decided to choose YahooUI as it was somewhat close to the rich GUI that our VB.NET uses now. We chose this framework to try to keep javascript development to as low as possible by using already made widgets and libraries from the framework.
  • PHPUnit – This is one of the important parts of the foundation we need to start building the new system. If we cannot have some guarantee that the system is stable then what is the point of the whole thing.
  • phpUnderControl with CruiseControl (Continuous integration server) – “Continuous integration describes a set of software engineering practices that speed up the delivery of software by decreasing integration times”. phpUnderControl uses PHPUnit, PHPDocumentor, PMD, PHP_CodeSniffer and CheckStyle.
  • Subversion SCM – We obviously, need source control management and we are already familiar with subversion. We had considered Git, but didn’t choose it in the end.
  • Zend Coding Style – The development team decided that in order to organize and standardize their code, they want to use the Zend Coding style. I also understood that it will later help with phpUnderControl with its style checking.
  • Scrum with ScrumWorks – We use Scrum and we find it very effective. The application we use for it is ScrumWorks Basic. Even though we don’t think it’s the best one, it works for most cases and is quite convenient.
  • Selenium with PHPUnit extension – for front-end testing. Selenium can test front end pages/forms and javascript functionality. Selenium can be called from PHPUnit which will fit with the automated testing suite.
  • Acceptance Testing for our User Stories – This is a standard we liked. We like to specify with the user stories the acceptance test or success criteria for this user story to be considered done.
  • Fat-Models, Skinny Controllers – A standard we are all in agreement is a very good practice.
  • PHPUnit TestDox for documentation - I wanted the tests to be the actual documentation. All the requirements and behaviors of the system should be the actual tests of the system. PHPUnit has a way to extract the test name and generate documentation for them. We will also use PHPDocumentor and Dokuwiki for anything else.
  • SOAP/REST– We will use SOAP/REST for any component that might need to be called from another location. With all the talk about SOA, I decided to just implement the minimum use of it, which is to use it when other locations need to use this functionality. This is instead of having the code in 2 places and both try to get data from the same database as the point of integration.
  • FireFox/Prism - We can dictate which default browser we plan to support. Prism is also quite a cool application to make our application look like… a real application.
  • Validations for HTML and CSS – Even though we don’t need to make our internal business application SEO friendly, it still might be a good idea to run some validation on it.
  • LDAP (linux) - We though it might be a good idea to have this for user logging and authentication, but the brightest idea would be that we would then know which printer is closest to that user.
  • Nagios for Web Page monitoring – We can monitor if the website is up and get advanced warning if something is wrong.
  • Log4php – a ready made logging library ported from java.


We are all quite pleased about the decision and look forward to start working on this project. I hope to learn as much as I can from this experience and I am sure the development team feels the same way.
I strongly believe that PHP with the addition of other open source products can deliver the same if not better results then VB.NET/ASP.NET would and I plan to put my money where my mouth is.

For writing this article, I did some research into Enterprise PHP, but did not find too many (current) articles about them. I hope to start seeing a bigger trend towards Enterprise PHP applications
I will keep bloging about the project when interesting things come up and I keep the right to update the list I made in case we decide that some parts of it are not as good as we thought