PHP Throw Down - Three Hour Spree Report

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

PHP Throw Down - Three Hour Spree Report

Post by Ollie Saunders »

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...

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');
...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:
  • 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.
So in fact I'm shying away from XSLT for something this high paced. Smarty and Zend_View will be the better options, my preference being the nice and simple Zend_View.

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.php
and 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.
ChatLog 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
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 cool :)

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?)
I'm completely against having any actual code written before hand, even XML structures. I don't think we should risk breaking the rules.

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 :(
User avatar
CoderGoblin
DevNet Resident
Posts: 1425
Joined: Tue Mar 16, 2004 10:03 am
Location: Aachen, Germany

Re: PHP Throw Down - Three Hour Spree Report

Post by CoderGoblin »

ole wrote: 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.
I'm confused... As I'm a user of the Zend Framework can you be more specific as to "run the app directly in the document root directory". Surely from a site point of view that is the correct location to run it from ? If not you can modify it

An example:
http://machinename/Myapp will work (use at home with machine name as localhost)
http://machinename/¨user/Myapp will work
http://machinename/~user/misc/Myapp will work.

If you need additional "models" simply include them in the PHP include path within the index.php (my default shown below).

Code: Select all

<?php
define('DS',DIRECTORY_SEPARATOR);
define('PS',PATH_SEPARATOR);

// Define Pathing and errors
set_include_path('.'.PS.'.'.DS.'library'.PS.'.'.DS.'application'.DS.'models'.DS.PS.get_include_path());
?>
Glad you had a useful experience though.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Just to confirm: you are saying that you aren't required to have the app exist (index.php at least) in the document root directory of http://someHost/?
User avatar
CoderGoblin
DevNet Resident
Posts: 1425
Joined: Tue Mar 16, 2004 10:03 am
Location: Aachen, Germany

Post by CoderGoblin »

Confirmed
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

I can't help but continue to advocate the XSLT method for collaborating. Even though we had a bit of a rough time yesterday, I would attribute that to equal parts lack of planning and "ironing out the kinks" as it were.

Having an XML "backbone" that is agreed upon at he beginning allows the front-end and back-end people to start working towards one another right away, and thus not wasting any time. I think having a decent model of this XML structure at the beginning will also help give people a goal to work towards and help focus everyone in their job.

Also, I think the 3 hour time limit was a little short to see any of the real benefits of what we did. I'm convinced that another few hours would have produced something quite worthwhile. We should definitely plan plan plan to make the most of the upcoming 24 hour contest.

SVN was great, as was the skype chat (although I wish it had better tray notification support).

Keep leading us oh exalted (exhausted?) leader!
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Do another writeup for the next session! And get a blog! :)

I'd say you all did pretty well. Three hours is very short to get much done since planning the approach will consume a lot of that. Over the course of 24 hours, it's a small thing. Most of all I think the practice session was a brilliant idea - at the real event you'll have a better idea of your roles and abilities.

The lack of unit testing is a shame, but since time here is all important I'd suggest keeping tests minimal - just check the class works for what you need it for and drop any edge cases, or in depth checking. Not perfect, but it offers a smaller comfort zone for less time spent. If it is possible, use a framework like the ZF (hopefully the team is familiar with it?).
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.
Shoot them now ;).
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 cool
You need at least one coordinator, not simply to lead, but also to keep an eye out that everything needed is being worked on and is slotting together correctly. Also, there's going to be those times when someone needs a little help, or finished code needs reviewing by a second pair of eyes. I'd watch the clock though - one person doing this full time is not coding. Still, it's often an invaluable role so spend some time in it if possible.

Good luck, guys!
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

You should join us Mauggy!
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Kieran Huggins wrote:I can't help but continue to advocate the XSLT method for collaborating. Even though we had a bit of a rough time yesterday, I would attribute that to equal parts lack of planning and "ironing out the kinks" as it were.
OK clearly we are going to need to talk this out a bit. I want to make sure we make the right decision on this.
Having an XML "backbone" that is agreed upon at he beginning allows the front-end and back-end people to start working towards one another right away, and thus not wasting any time.
It separates people out into front-end and back-end developers where we could separate by any number of other things. My concern is that front-end devs will need to talk to back-end devs so much that all the time spent discussing will nullify any of the other advantages.
I think having a decent model of this XML structure at the beginning will also help give people a goal to work towards and help focus everyone in their job.
I not sure it is feasible to have pre-planned xml structures, we aren't 100% sure what we are going to be writing yet. Also it's could be construed as "code" in which case we'd be breaking the rules.
Also, I think the 3 hour time limit was a little short to see any of the real benefits of what we did. I'm convinced that another few hours would have produced something quite worthwhile. We should definitely plan plan plan to make the most of the upcoming 24 hour contest.
Yes absolutely 3 hours wasn't particularly realistic. I'd like to hear more people's comments on XSLT. Because I am no longer sold on it. It's a lot of extra complication that only you are properly familiar with. If we have 4 or 5 other devs writing back end will you be able to keep up? With my help you probably could but then I can't co-ordinate.
Keep leading us oh exalted (exhausted?) leader!
Please...Grand Lord Master will do just fine ;)
Maugrim wrote:Do another writeup for the next session! And get a blog!
Afterwards perhaps.
Most of all I think the practice session was a brilliant idea - at the real event you'll have a better idea of your roles and abilities.
Why thank you :)
The lack of unit testing is a shame, but since time here is all important I'd suggest keeping tests minimal - just check the class works for what you need it for and drop any edge cases, or in depth checking. Not perfect, but it offers a smaller comfort zone for less time spent. If it is possible, use a framework like the ZF (hopefully the team is familiar with it?).
We are using ZF and I imagine the natural fast pace of everything will make everything skimpy.
You need at least one co-ordinator, not simply to lead, but also to keep an eye out that everything needed is being worked on and is slotting together correctly. Also, there's going to be those times when someone needs a little help, or finished code needs reviewing by a second pair of eyes. I'd watch the clock though - one person doing this full time is not coding. Still, it's often an invaluable role so spend some time in it if possible.
You're saying pretty much what I'm planning on doing. We will get done what we can. If I can keep people working efficiently we can't really hope for anything better than that.
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

Just how many devs are there? I count 4 so far, including our recently-sofa'd Grand Lord Master himself.

An XML target specification isn't any more "code-like" than a database plan, or a visual concept for that matter.

Also, it would be good to plan out a URL scheme. Like:

Code: Select all

/user/$id (get) returns user all account data for user $id
/user/add (post) posts new user data to be added to the system as a new user, redirects to /user/$id
/user/$id/delete (get) deletes user with id $id
The XSLT is a one person job, along with the interface work.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Just how many devs are there? I count 4 so far, including our recently-sofa'd Grand Lord Master himself.
6:
  • Kieran Huggins
  • ole
  • aaronhall
  • DaveTheAve
  • The Ninja Space Goat
  • d11wtq
In case anyone is wondering I recently got a new sofa from Ikea :)
An XML target specification isn't any more "code-like" than a database plan, or a visual concept for that matter.
OK. I accept that point. Do you want to be in charge of doing that then?
The XSLT is a one person job, along with the interface work.
If you are happy with all that responiblity then I'm cool.
Also, it would be good to plan out a URL scheme. Like:
Well if we doing class diagrams that will be determined anyway. Here's some news from the horses' mouth
Elizabeth Naramore and I wrote: > > > - You mention DB Schema is fine to have ready but what about user
> > > interface designs or UML?
> > I think something sketched out on paper would be acceptable.

> Well nothing is going to be on paper because this is a forum team. All
> the members have met only on the PHP DevNet Forum. So it is still ok?
> I suppose we could include them in the submission. I'm keen not to
> break the rules here but I'm finding them a little vague.


I'd say as long as you're using them for planning purposes (such as "who's doing what" and "what's it going to look like"), then it would be acceptable. As far as I'm concerned, I think you should be able to do anything and everything to get you and your team ready to start coding on minute 1 of the competition. However, if you don't mind - I'd like to take a quick poll from the judges to see if anybody sees a problem with it.

I know the rules are vague - part of that is to allow flexibility and the other part is because we've never done this before, so we're going to see how it goes. :)
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post by Kieran Huggins »

fair enough - I'll draft up an XML map and a URL map (open to changes, of course) tonight or tomorrow morning.
Post Reply