Development is much more than just opening a text editor and writing some code. This is how most developers start, of course, and may be what an individual developer's day to day duties entail at a large corporation, however when viewing the "big picture" there are many other decisions that must be made in the course of building a software package for release that clients often don't realize were even considered. We thought you might be interested in hearing about some of those decisions that were made regarding 4.0, prior to ever writing a single line of code.
Minimum Supported Versions
One decision that has to be made relatively early in the development process is what dependencies will the software require. For software developed in PHP, this typically means what version of PHP will be the minimum, and (often) what will be the minimum required version of MySQL.
PHP 5.3.0 was released in June of 2009, and includes functionality that we intend to utilize within the 4.0 Suite. Subsequently, this was an easy decision to make.
We were leaning towards requiring MySQL 5.5, which was also released in 2009. We feel that 3 years is long enough on the web to incorporate updated software within most hosting environments. Upon investigating the functionality we intend to utilize in MySQL, however, we have determined that MySQL 5.0.3 and above includes everything we need, so MySQL 5.0.3 will be our minimum required version.
Profiling and Benchmarking
If you are a PHP developer and have ever attempted to profile your code, you probably realize it can be challenging. Many IDEs support some level of profiling built in, however it is almost always manually invoked. xdebug is a powerful tool for profiling, but again it requires you to enable profiling, run a request, and then view the results. In a live environment this is nearly impossible as profiling adds a lot of overhead to page loads and creates hundreds of profiling files quickly.
Our goal is to be able to profile changes as they are committed, right away. We have decided to install Zend Server to the server that will host our staging environment for 4.0, which supports automatic rule-based built in profiling. This will allow us to easily profile requests automatically, even those that we may not "know" how to trigger manually (e.g. a specific task in a specific circumstance takes a long time to execute).
Improving automatic deployments
While automatically building and deploying the software to our staging environment itself is not a challenge per-se, a lot of times changes occur that require some sort of manual intervention to enact. We may have exported updated skin templates, language files, or there may be SQL queries that need to be run. We are developing an automatic deployment routine that can handle all of this easily and programatically, ensuring our staging environment is truly always up to date with the latest changes.
Website and forum organization
Not directly related to 4.0, another area we had to consider was our organization on the website and on our community here. This extend to all areas of the community, from the organization of our feedback and support forums, to our marketplace categorization, to our bug tracker categorization. The approach with 4.0 will be that we have one suite with modular applications that can be enabled. We need to market the software this way, and we need to ensure that the logical work flow for our clients reflects how our suite is designed. You will be seeing changes to categorization throughout our sites based on 4.0 in due course as a result.
Loose ends
And beyond all of the stuff directly related to 4.0, we felt it prudent to tackle a lot of loose ends before we jumped into a major overhaul of our entire software line up. There were a lot of smaller tasks that have been pushed off for a while but which we've finally sorted through which we feel will afford us less distractions as we work on the next release. Most of these tasks were minor, but not unimportant. Examples include:
- Moving our documentation to the main website
- Improving minor areas of IP.Downloads and IP.Nexus to allow clients to better help themselves, or to allow a smoother work flow within the administration areas our employees utilize every day
- Scripts on our end that allow us to better manage certain services
- Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server
None of this directly affects 4.0, however the less distracted we get with minor tasks during 4.0 development, the better we can focus and deliver the product in a timely manner and with less chance of distraction-related bugs.
Of course hundreds of other decisions have gone into 4.0 as well, some of which we will talk about in future blog entries. We thought you might be interested in hearing about some of the smaller things us developers do here at IPS, however, besides developing great software products to power your communities!