PHP Throw Down - Three Hour Spree Report
Posted: Thu Jan 25, 2007 10:06 am
Last night Kieran, aaronhall and I agreed to do a practice session for the throw down. For 3 hours we were trying to write a "film collection manager database application" (no user accounts). We used PHP, MySQL, XSLT and SimpleTest. Communication was done over Skype.
After 9 man hours (minus a few because people had to leave to do things) we had almost no interactive functionality at all! Did you guess as much? The experience was invaluable though. We all agreed that Subversion rules and we couldn't have done without it. OK here's an account of what happened:
We decided upon the app to write and I set up a subversion server (that'll be done for us next time). I wrote this short script......designed to ensure all the development environments were correct. It later turned out that Kieran forgot to run
it but he only had to download SimpleTest to get it working. We all used the release version of SimpleTest because I've had problems with the CVS versions before and not everybody has CVS.
We decided not to use the Zend Framework because the project was so short and I was concerned about the limitation where you have to run the app directly in the document root directory. I'm pretty sure this was a bad decision as I had to spend a fair amount of time writing a front controller that ZF would have already provided. I tried to emulate the ZF one but because it wasn't around for the first hour. Aaron ended up writing code in the main index.php instead of the models as a result and that had to be moved later.
In case anyone is interested Kieran has started hosting a subversion server accessible by HTTP. All the code can be viewed on there. This was the front controller I knocked up.
Before the timer actually started Aaron planned out a DB schema for us. I think it took Aaron and kieran a far bit of time to set it up and populate it with some data, perhaps we could have postponed filling the database with example data until it was really needed or maybe only put a single record or two in each table.
I decided that in order to make the app easy to install we needed a configuration file that when not present would be created by completing a form. The file would contain database credentials. I also wanted the database schema to be created by PHP if the specific database didn't exist but we never got round to that and instead all shared of Kieran's MySQL server using the same credienials.
That form and the creation of the config file was handled by Aaron and to be honest this was the only real functionality that ever got completed. At this time Kieran was working on a simple function that would allow us to bind XML strings to XSLT files and I was still writing the front controller. The idea was we would generate XML in the model and use that function to pass the XML to XSLT that Kieran would write. The XSLT would handle all the view responsibilities. I wanted to do it this way because then it easy to tell one person to write the business logic for something and someone else to write the presentation code. But there are several problems with this:
It was about this point that I set up a special controller for running unit tests. This was ready and going at about half way into the endeavour and then I found out that Aaron wasn't really a fan of unit testing and Kieran has never done it! I used it only once or twice but I think it could have been useful and I've certainly no reason to believe that a 24 hour project is too short for writing unit tests. 3 hours is! but 24 definitely isn't.
It was unfortunate that I had to write the front controller before I could get unit testing up and running because then I couldn't really be bothered to test the front controller having already written it. With ZF this obviously wouldn't be an issue. Also in that code I've got a group tests with test files being loaded in from an array when in reality it would probably be much better (esp. considering people will be adding tests pretty frequently) to use a glob() to load all the test files.
We used the standard mysql_*() functions for database access. I wrote a class to put all our queries in sorta like prepared statements. I'm sure this would have worked better with MySQLI. Being able to pass around result sets and other objects could be a real advantage so I'm recommending MySQLI over MySQL for the real thing. Not everyone has access to or experience with PDO, including myself, so I think that is a step too far.
For the real thing I propose the following directory structureand a CamelCaps convention for files and directories. We only did this on directories but it was a bit weird when app/frontController.php contains the FrontController class, for instance. Whilst I'm on the subject of conventions; we used the Zend Coding Standards; there were no problems there.
Communication over Skype seemed to be quite good but I am concerned at the amount of time we were just chatting and organising things. I would often be distracted by chat between Kieran and Aaron that wasn't really related to me and I'm sure Kieran and Aaron experienced this too. This can only get worse with more people. Lots more PM I think is the solution to this. Perhaps reserve the main chat room for big announcements.
I played quite an autocratic role, delegating and making decisions frequently, and both Kieran and Aaron seemed to appreciate this.
If I go with that kind of methodology it would be really great if I could get some detailed information on all the team members' experience levels in all the different technologies. In fact that would be useful information to have no matter how we go about it.
I think all of us agreed more planning was required. I'm not really surprised about this, seeing as there was really very very little at all. For the real thing I think we definitely need:
OK, I'm done hope you enjoyed reading all this as much as we enjoyed doing it. Hope to see you for the throw down itself!
P.S. Nothing is really happening on the private forum front
After 9 man hours (minus a few because people had to leave to do things) we had almost no interactive functionality at all! Did you guess as much? The experience was invaluable though. We all agreed that Subversion rules and we couldn't have done without it. OK here's an account of what happened:
We decided upon the app to write and I set up a subversion server (that'll be done for us next time). I wrote this short script...
Code: Select all
<?php
if (!extension_loaded('xsl')) {
echo 'No XSLT support<br />';
}
if (!class_exists('DOMDocument')) {
echo 'No DOM<br />';
}
if (!extension_loaded('simplexml')) {
echo 'No SimpleXml<br />';
}
if (version_compare(PHP_VERSION, '5.1.2') < 0) {
echo 'PHP version too old<br />';
}
if (!function_exists('mysql_query')) {
echo 'Standard MySQL functions not enabled<br />';
}
if (!function_exists('spl_classes')) {
echo 'No SPL<br />';
}
if (!include 'simpletest/unit_tester.php') {
echo 'Simpletest subdir not in include path<br />';
}
if (!(int)ini_get('display_errors')) {
echo 'display_errors directive turned off<br />';
}
exit('<hr />Finished testing');We decided not to use the Zend Framework because the project was so short and I was concerned about the limitation where you have to run the app directly in the document root directory. I'm pretty sure this was a bad decision as I had to spend a fair amount of time writing a front controller that ZF would have already provided. I tried to emulate the ZF one but because it wasn't around for the first hour. Aaron ended up writing code in the main index.php instead of the models as a result and that had to be moved later.
In case anyone is interested Kieran has started hosting a subversion server accessible by HTTP. All the code can be viewed on there. This was the front controller I knocked up.
Before the timer actually started Aaron planned out a DB schema for us. I think it took Aaron and kieran a far bit of time to set it up and populate it with some data, perhaps we could have postponed filling the database with example data until it was really needed or maybe only put a single record or two in each table.
I decided that in order to make the app easy to install we needed a configuration file that when not present would be created by completing a form. The file would contain database credentials. I also wanted the database schema to be created by PHP if the specific database didn't exist but we never got round to that and instead all shared of Kieran's MySQL server using the same credienials.
That form and the creation of the config file was handled by Aaron and to be honest this was the only real functionality that ever got completed. At this time Kieran was working on a simple function that would allow us to bind XML strings to XSLT files and I was still writing the front controller. The idea was we would generate XML in the model and use that function to pass the XML to XSLT that Kieran would write. The XSLT would handle all the view responsibilities. I wanted to do it this way because then it easy to tell one person to write the business logic for something and someone else to write the presentation code. But there are several problems with this:
- Business logic (model) has to generate XML. This certainly takes longer than just assigning values to properties of a view object such as Zend_View
- The XML generated by the business logic has to be known to a resonible extent before the XSLT can be written. This is fine when one person is doing it but demands a lot of communication between two people.
- Only Kieran really knows XSLT, I've only dabbled.
It was about this point that I set up a special controller for running unit tests. This was ready and going at about half way into the endeavour and then I found out that Aaron wasn't really a fan of unit testing and Kieran has never done it! I used it only once or twice but I think it could have been useful and I've certainly no reason to believe that a 24 hour project is too short for writing unit tests. 3 hours is! but 24 definitely isn't.
It was unfortunate that I had to write the front controller before I could get unit testing up and running because then I couldn't really be bothered to test the front controller having already written it. With ZF this obviously wouldn't be an issue. Also in that code I've got a group tests with test files being loaded in from an array when in reality it would probably be much better (esp. considering people will be adding tests pretty frequently) to use a glob() to load all the test files.
We used the standard mysql_*() functions for database access. I wrote a class to put all our queries in sorta like prepared statements. I'm sure this would have worked better with MySQLI. Being able to pass around result sets and other objects could be a real advantage so I'm recommending MySQLI over MySQL for the real thing. Not everyone has access to or experience with PDO, including myself, so I think that is a step too far.
For the real thing I propose the following directory structure
Code: Select all
App/
Views/
Controllers/
Classes/
Tests/
NotesAndDocs/
Gfx/
Css/
Js/
index.phpCommunication over Skype seemed to be quite good but I am concerned at the amount of time we were just chatting and organising things. I would often be distracted by chat between Kieran and Aaron that wasn't really related to me and I'm sure Kieran and Aaron experienced this too. This can only get worse with more people. Lots more PM I think is the solution to this. Perhaps reserve the main chat room for big announcements.
I played quite an autocratic role, delegating and making decisions frequently, and both Kieran and Aaron seemed to appreciate this.
So I think we could capitalise on this further. Perhaps I should play a role of of co-ordinator and reviewer, barely writing any code of my own. I can make sure that nobody is left behind and that all the components are actually going to communicate properly. So it would be may job to know exactly what we are going to write and how to divide it into pieces and tell everyone what pieces they are writing. I could also write unit tests for people to fulfil with code, now isn't that coolChatLog wrote:Aaron: i'm glad we did this ole (i'll learn to trust your decisions, oh leader) lol
ole: was i too bossy?
Aaron: no no no. not at all
If I go with that kind of methodology it would be really great if I could get some detailed information on all the team members' experience levels in all the different technologies. In fact that would be useful information to have no matter how we go about it.
I think all of us agreed more planning was required. I'm not really surprised about this, seeing as there was really very very little at all. For the real thing I think we definitely need:
- Complete DB Schema
- User interface designs
- Class diagrams and sequence diagrams if possible (are we allowed to do those?)
OK, I'm done hope you enjoyed reading all this as much as we enjoyed doing it. Hope to see you for the throw down itself!
P.S. Nothing is really happening on the private forum front