Archive for February, 2008
Software engineering is the practice of using selected process techniques to improve the quality of a software development effort. This is based on the assumption that a methodical approach to software development results in fewer defects and, ultimately, shorter delivery times and better value. The collection of policies, processes and procedures used to practice software engineering is called its software development methodology (SDM).
There are a lot of SDMs. The oldest, and most frequently used one is the one where the client defines his requirements. Based on these requirements an extensive analysis (UML diagrams, workflow diagrams, …), is made. Once these steps are completed a development team starts developing on a first version, and after 9 to 12 months a first version will be shown to the client. The steps I described are some steps from the waterfall model, a sequential software development model.
Working with such an SDM could work in a big software factory, but not in open source projects. For open source projects — as well as closed source projects, there’s an SDM that could be better suited: agile software development.
Agile software development is an SDM that promotes development iterations throughout the life-cycle of the project. The modern definition of agile software development evolved in the mid 1990s as a part of a reaction against “heavyweight” methods. The use of the waterfall model were seen as bureaucratic, slow and inconsistent with the ways that software developers actually perform effective work. Therefore, agile methods were also called “lightweight methods”.
Agile methods are a family of development processes — not a single approach of software development. Some of the principles of the Agile Manifesto are:
It quickly becomes clear that working versions of the software are delivered on a regular basis. This shows that iterative development is one of the key aspects of agile software development. Analysts don’t create an extensive analysis document. Instead, the end user creates user stories. Once the user stories are finished, developers pick their user story and start implementing them. Once the iteration is done (which can be from 1 to 4 weeks) a working version of the software is deployed. This version will be shown to the client, and based on his input on the current version, the software gets modified.
By using iterative development, defects will be rapidly detected, as well as the changing needs of the client. Also, the client will be heavily involved in the development process. Also, this has as a consequence that there is a continuous integration: the build must be working at every moment, because implementations of other developers are dependent on your code.
At Joomlatools we are heavy proponents of agile development. Each of our client development projects gets it own “incubator-project” and divide the development into iterations or milestones of 2-4weeks depending on the nature and scope of the project. Right before each iteration ends, we deliver a working build of the project to the client.
This has a number of advantages: the client is heavily involved — even clients with a lack of technical know-how. A second advantage is that requirement changes can be made after each iteration at very low costs. We just needs to make sure that we can provide a working version at the end of each iteration, and that’s it! A certain milestone could only have implemented 5% of the initial goals, which isn’t a problem. By releasing often and early main defects detection and client input are increased enormously. After all, isn’t this what open source development is all about?
Joomlatools would like to announce the immediate availability of DOCman v1.4.0RC2.
Recently, a CSRF vulnerability was discovered in DOCman. An attacker can have the same access permissions as the administrator. In the right circumstances, this can be exploited to change data or obtain shell access. All 1.3.x versions, as well as 1.4.0BETA2 and 1.4.0RC1 are vulnerable. Therefore it is recommended to all users to upgrade to the new v1.4.0RC2.
CSRF or ‘cross site request forgery’ is a relatively unknown exploit. Many extensions, as well as older Joomla! versions, are vulnerable. We strongly recommend to upgrade all sites to either Joomla! 1.0.14 1.0.15 or Joomla! 1.5.1, and only use extensions from trusted sources. Always log out after using your site in either front- or back-end.
We’d like to take this opportunity to thank everybody who tested DOCman, reported or fixed bugs, made translations, or helped out users on our forums. Our special thanks goes out especially to Zinho from Hackers Center , who discovered the vulnerability, Krisstoffer, our forum moderator, and Chris, who submitted patches.
DOCman is almost completely developed and maintained by volunteers. If you want to contribute to DOCman, in any way you can, please join our growing user community on the Joomlatools forums!
Mathias Verraes (aka mjaz)
DOCman Lead Developer
Joomlatools Team Member
The Joomla! project is calling for white papers for the next big release, Joomla! 1.6. This is just one of the recent attempts to make the development process of Joomla! more structured, better organized, and more controllable. I’m all for that… kinda.
The white paper submission process, as well as the recently announced maintenance procedures, risk turning the project into one big bureaucracy. As ibnhafsun noted, that’s fine, as long as you can manage it. In companies, where employees are paid to fill in forms, this can work. Joomla! however is made by volunteers. Potential contributors will be scared off by reading the procedures, let alone actually having to go through all that. You also need people who read the submissions, filter them, organize them, etc. Does Joomla! have the manpower for these processes? And more importantly, where’s the fun in that?
Do we really need a white paper for adding a button? It’s just one of the proposals on the white paper forum. (Andrew, I don’t mean to downplay your proposal — it just happens to be a good example.)
What happens if ten great papers are submitted for additional buttons? That’ll clutter up the user interface big time. A better idea here would be to find someone with in-depth knowledge of usability. Someone who can tell us how we can make Joomla! more intuitive. Someone who can come up with a conceptual overview of what Joomla!’s UI should be like. I bet that person won’t tell us to ‘add more buttons’.
With more of an ‘incubator’ approach, similar to what Zend and PEAR do, we can replace the white papers with a more organic process. If you want to build a certain feature, simply start coding in a separate branch of the codebase. Find some people who share your interest and make a first working version. As soon as you’ve got some basic functionality, you can let users try it, and get other developers to review your code. It’ll be much easier to discuss it, when people have had hands-on experience, instead of by reading your white paper. You’ll get feedback that’s actually worth something. When the code reaches a certain maturity, it can be integrated in the core (be it 1.6, 1.7, …). Or possibly, you’ll find out that it’s better kept as a separate extension and let the end-user choose whether he needs it.
The big advantage is that the different incubator projects can be developed more or less independently. New Joomla! releases don’t have to wait until all planned features are done. Instead, when an incubator project is stable and good to go, that can trigger a new Joomla! release. I’m sure this incubator approach will speed up Joomla! development, and result in higher quality code. I also believe this creates a healthy balance between developer-driven, and community-driven development. And more importantly, it’ll bring the fun back.
So here my proposal for the next stage of Joomla! development:
Less talk, more code!
On February 5th, Robert Douglass announced the GoPHP5 project has come to it’s finishing mark.
Congratulations are in order. Since the launch of GoPHP5.org, over 100 software projects and over 200 web hosts have come on board to support the adoption of PHP 5.2. As opposed to just a few months ago, it is now easy to find a hosting solution that supports PHP 5, and software developers can turn to the attractive new features that PHP 5 offers without the need to worry that they are leaving their end users without options.
Robert gives credits to Larry Garfield and Marc Delisle for their hard work towards making the project a success. The community pulled together to make development, and the platforms we build on, that much better.
At Joomlatools we are happy to announce that we will be following the lead of the GoPHP5 initiative. As from today all new code and Joomla! extensions will be written for PHP 5.2 and Joomla! 1.5 only. Only DOCman 1.4 will still be maintained for Joomla! 1.0/1.5 and PHP 4.
What about Joomla? We believe the Joomla! project cannot stay behind. With all major CMS systems moving to PHP 5.2 and with the announcement that PHP 4 will be completely abandoned on 08/08/08, there is no reason for Joomla! to keep PHP4 compatibility. Unfortunately there haven’t been any serious discussions inside the Joomla! community so far about moving to PHP 5.2. We would love to hear your opinions. Let’s put this on the agenda for 1.6!
