Past weekend, we went to Utrecht to attend Joomladay NL 2008. On the community day, I gave a presentation about the Eclipse project. The presentation included a short introduction to the project, an overview of the different ways of developing PHP applications in Eclipse. At the end I explained how PHP developers could debug their PHP applications using Xdebug.
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
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:
- user satisfaction by rapid, continuous delivery of useful software
- working software is delivered frequently (weeks rather than months)
- even late changes in requirements are welcomed
- close cooperation between end-user and developers
- projects are built around motivated individuals — who should be trusted
- regular adaption to changing circumstances
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?Read more
Last week I was at the Dutch Joomla BootCamp, which was organised by our friends from Jira. Johan gave one of his famous unstoppable sessions about the Joomla framework and the MVC model. Jisse talked about templates, and brought along the very first copy of his new book on templates (a rather thorough one I must add, it goes beyond any book on templates I’ve seen — too bad it’s in Dutch only for now).
Finally, I gave a presentation about migrating a Joomla! 1.0 site to Joomla! 1.5, and took the opportunity to announce the migrator plugins for DOCman.
Com_migrator is a component written by J! Core developer Sam Moffat. The latest version 1.0RC6 was released this week. You install it on your old J!1.0 site (or even Mambo!) and it will take a snapshot of your database. During the installation of J!1.5, you can upload the snapshot (an SQL file). The new site will now contain the contents of the old site. A great feature of com_migrator is the ability to load additional plugins for 3PD extensions, such as DOCman. These plugins expand the snapshot with the data from the extension.
With a little knowledge of phpMyAdmin, you can also use the migrator to copy data from a DOCman installation on a site to an existing J!1.5 installation.
You can download the DOCman migrator plugins at Joomlacode.org, where you can also find the com_migrator component. Extract the plugins’ zip file and read the included README.php file for detailed instructions. We’ve also opened a new forum category where you can discuss DOCman migration.
Good luck migrating!Read more
When you’re defining one or more tables to use in your component, it’s always a good idea to put some thought in how you’ll name them. First of all, we have of course the #__ prefix, which Joomla! replaces with the user defined prefix. The default is jos_, which stands for ‘Joomla! Open Source’, a leftover from the Mambo days.
Next, we want to prevent name collisions. Component names in Joomla! are unique, so using that for the first part of your table names will fix that: #_mycomponent. Don’t use #_com_mycomponent, that’s unnecessary luggage.
Let’s take a classic example: a component that manages a book collection, called com_library. The table name should reflect the contents of the table. This is always plural: you use a table to store multiple items.
Even if your component uses only one table, you shouldn’t use #__mycomponent. You might need more tables later, eg #__library_authors and #__library_publishers.
Finally, you always need to define a primary key. Most people simply use id for this, or something like bId for the books table, aId for the authors etc. A better idea is to use the table name, in singular, followed by id.
#__library_books -> library_book_id
#__library_authors -> library_author_id
There are some very important advantages to this naming strategy. It’s easier for you or other people reading your code, what tables belong to what component, and what’s in them. Relations between tables are now very clear as well. #__library_books for example has two additional fields called libray_author_id and library_publisher_id, which of course link an author and a publisher to the book.
But more importantly, it’s easy to write code now that can detect those relations automatically. As your com_library becomes smarter, you could add data mapping functionality that can understand the relations between tables, without the need to hardcode them.
Finally, in most situations, you’ll want to use auto_increment for primary keys. As we’re all moving to PHP5.2 and along with that, hopefully MySQL 4.1 or 5, we can make use of new feature: the SERIAL keyword. SERIAL is just an alias BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE. This allows your primary keys to be as big as possible (and it’s easier to remember as well).
In Joomla!, we’re still stuck with backwards compatibility, but hopefully, these coding conventions will be picked up in a future version. Component developers can already start using them. The possibilities are endless.Read more