I completely disagree with this point of view. If I write code which is not intended to generate Notices, then as the developer I want to know if and when Notices are being generated in any environment.

Notices are very helpful in tracking down logical errors or bugs, which cause the script not to function as expected. In PHP they are normally generated when using a previously undeclared variable. Technically speaking there is nothing wrong with this in PHP, other programming languages are not so forgiving.

I personally started declaring all variables when I began to focus on the security implications of using undeclared variables (we’ll save that information for another post). After getting in the habit I found that I was able find logical errors during development even before I noticed that a bug existed. After realizing this, I now never release code which is know to generate notices. I have also started setting error reporting to E_ALL in all environments.

I understand that this is not feasible for everyone. It may not be possible in a professional working environment because of dealing with legacy code. Another issue could arise if you use third-party code which has not subscribed to this way of thinking. Although personally, I feel this is not an excuse there is no reason you can’t get in there and ‘fix’ their script.

A word of warning

I was once hired to fix numerous bugs on a site, all were a fairly obvious fix, but one in particular had me stumped. I turned on notices when attempting to debug the problem and ended up with an error log that contained over 250 notices for every page load. Since this was a dev environment setup by the client for my use, it was no big deal, but if it were a heavily trafficked live site, there could have been some serious implications.

UDID – User Designed/Defined Information Directory
(Of course it is an acronym, you expected something else?)

There is a legitimate reason for naming the project before even setting up the development area. The project will be stored under the ‘Udid’ directory, and all of the class names will reflect the position of the file within the project’s directory structure. I will explain more about this when we get into writing classes and actually coding, but if you would like more information about this type of setup you can read about the Zend Framework naming conventions for classes.

OK now we have a name and it’s time to setup the directory structure. First we create the ‘udid’ directory and beneath that we create a ‘project’ directory; such as:

udid
|-> project

The ‘project’ directory will hold all the files directly associated to the project. The reason I have created this directory and did not just store the project code within ‘udid’, is because we will be using some third party applications to help with development and I do not want that third party code to actually be associated to the project code. For example we will be using Simple Test for unit testing. We will be placing Simple Test within ‘udid’, but not within ‘project’. So now we have:

udid
|-> project
|-> simpletest

As you know we will be using SVN to store the code, so we are going to be using what I learned as the traditional setup for a SVN project, not because it is the traditional way, but because I’ve used it before and it has worked well for me. This structure is:

project
|-> branches
|-> tags
|-> trunk

These three directories have very specific purposes:

• branches: Experimental development branches. Branches are used when you decide to make some dramatic changes to the code base, but your not really sure how it is going to work out, so you do not want to code within the ‘trunk’ but you may want to merge the code within the trunk at a later time.
• tags: This directory is used to store the project at certain milestones, i.e. version releases.
• trunk: Main development thread

So this is what our directory structure looks like so far:

udid
|
|-> project
|  |-> branches
|  |-> tags
|  |-> trunk
|
|-> simpletest

OK, for the rest of this post we will be working in the ‘trunk’ to setup the actual directory structure for the project code…

At some point a long time ago I got into the habit of creating a subdomain for each new project I work on, this I find convenient because the subdomain’s document root is its own and is not cluttered with other directories, files, etc. As an added bonus the document root can be anywhere on the system. Consequently the directories below ‘trunk’ look like this:

trunk
|-> public_html
|-> Udid

Obviously ‘public_html’ is the document root, and ‘Udid’ will store all the back-end PHP code. Notice the PHP code will be stored outside the document root (where a browser is unable to access it directly). I prefer to setup my projects this way as an added security measure. For more information about the security aspects of this; check out Chris Shiflett‘s article: Security Corner: Secure Design (be sure to read the comments).

For now ‘public_html’ will remain empty and ‘Udid’ will hold the directory structure for the application. So this will be the development directory structure we’ll be using…

udid
|
|-> project
|    |-> branches
|    |-> tags
|    |-> trunk
|         |-> public_html
|         |-> Udid
|
|-> simpletest

Please note, I have still not imported the project into SVN, you can actually do the import as soon as you have the first directory created, but I like to wait until I have the basic structure of the application set, which brings us to the topic of the next post. What is the directory structure of the application itself; or what directories will be created below Udid: ‘udid->project->trunk->Udid’?

I will post this structure in the next few days, and import the project into SVN, so we can finally get down to some code! Thanks for reading.

Even if we try to account for all aspects in the design phase, I know there will be situations where decisions made early on will have negative effects later down the road. I will document everything as it happens, because I find that I learn more from mistakes, and hopefully you will to.

I will mainly be working on this project solo, which means I will not only be dealing with PHP and MySQL, but also HTML, CSS, JavaScript, etc. Since I believe many developers work alone I hope that this will interest most readers.

I personally like to start a project with a name, simply because it gives the project an identity, but… In this case I cannot decide on an appropriate name so I am going to skip this step for the moment and move onto some actual code design, one of the most important and exciting steps.

First let’s set down some general guidelines:

• Version Control: Subversion (SVN)
• PHP Version: The project will be written in PHP5 and will not support PHP4. Let’s face it PHP4 is dead and if your server is still running 4 you NEED to upgrade.
• MySQL Version: I will be using MySQL 5, again if your not on 5, what are you waiting for?
• HTTP Server Platform: Apache
• Browser Support: Firefox, Internet Explorer, AOL Browser, Netscape, Opera, Safari. This is just a list off the top of my head, basically we are going to attempt to support as many browsers as possible.

Again these are just general guidelines; eventually the project will be able to support multiple database servers, different HTTP server platforms, etc. Initially these are our targets for support; no reason to bog the development process down with attempting to support everything under the sun, but… Since we want the project to be as flexible as possible, we will need to account for this NOW in our framework design.

OK, now that we have our guidelines; the next step will be to start coding right? Wrong, next we will decide on a directory structure, and create the SVN repository to hold our project.

I hope you are as excited as I am to get this thing underway, please check back soon.