WattWaiter 2.1 is now released. Version 2.0 had some issues as far as the user interface was concerned. These issues mostly dealt with very small resolution screens (1024x768). We have since fixed this and changed the overall appearance to reflect a more standard interface without much eyecandy.
If you are wondering what WattWaiter is read here:
"Wattwaiter is a web application that provides a visual display of carbon intensities for a given day. This information can be used by consumers to adjust their electrical usage and become “smart” consumers. By observing carbon intensities, consumers can determine which times during the day are most efficient for electrical usage. This benefits the consumer by allowing usage of lower costing electricity and the electric company by balancing their load."
This project was a learning experience. It seems that abstraction using Wicket, when dealing with web technologies, takes you away from what is really going on. It claims to offer state on top of the stateless protocol HTTP like it invented sessions or something. While it does do this, you must specifically implement this feature, otherwise users will share the same instance. PHP offers this right out of the box and spawns isolated threads for each connection. Wicket claims that it decreases development time and while it may after a lot of experience with it, it seems that recompiling all your files just to see the changes in your HTML, CSS or Java each time you edit source is quite annoying and time consuming. PHP compiles files on the fly, meaning I can change the a file and just refresh. When dealing with elements such as lists, you have to go through quite a process just to make that work.
However, I am quite biased since I have years of experience with the php/mysql/apache stack and find that it there is much more documentation and tutorials (which Wicket really lacks). That said, Wicket is a framework and should be treated as such. It aims to provide a better way to create web applications and for some I guess it does.
If I had to choose a framework for PHP, I would choose CodeIgniter because it is lightweight, easy to learn (a few hours and you've learned the whole framework) and provides various classes that you are likely to use often. It offers everything you could possibly need as well as easy object oriented interfaces to databases. It provides the abstraction you want with a MVC design and benchmarking is part of the package. It also allows you to create an app and package it up to bring it anywhere, you just edit the configuration on the new server and you are ready to launch.
Other PHP frameworks are a huge mess and have enormous libraries to drag around and load like PEAR. If you want rapid development in PHP, I suggest this lightweight option.
Stepping off the soapbox....
During the development of WattWaiter, I enjoyed the company of my co-developers, we seemed to work together quite well. As we divided up the work, everything fell into place because of good communication. We had daily meetings on IRC with a bot I wrote in Python that screenscraped the commit log from Google Code into our channel. It helped a lot because we wouldn't have to repeatedly say "I committed, update, see if that works"..."What did you update?....." etc. We used issue management to manage our tasks like any developer would and although we all know who is doing what, due to the small size of our group, it still served as a good reminder. If this wasn't there I would probably do someone else's work.
Here is our 2.0 screenshot:
Here is a 2.1 Screenshot:
