If you’re a template designer or extension developer (or if you just like to hack existing extensions), you might want to take a look at J!Dump. I started the project more than a year and a half ago, in the dark ages when Joomla! 1.5 was still in beta. I didn’t have the time to maintain it, but luckily Jens-Christian Skibakk (aka jenscki) stepped up and took over development. This month, a brand new version 1.1 was released.

What is J!Dump?

J!Dump solves some often recurring problems during development. When you want to know what a variable contains, you can use var_dump() or print_r(), wrapped in <pre> tags for readability. With large complex objects, this quickly turns into a mess. Furthermore, the output is mixed in with regular Joomla! output, which makes it even messier. And if you’re var_dump() statement is followed at some point by a redirect, you never even get to see the output.

J!Dump does it differently. When you dump($foo);, the contents of $foo are stored in the session data. At runtime, J!Dump opens a popup window, and shows the dumped variables, using a nice javascript tree. This allows you to dig into the variable a much nicer way than reading hundreds of lines of print_r output.

The best way to get a feel of how J!Dump can make your life easier, is to try it. Simply install both the plugin and the component on your test system and put a dump($some_object); statement in your code somewhere. Check the readme for more info.

Of course there are better ways to debug your applications. The nice thing about J!Dump is that it’s very easy to setup and get started, especially if all you need is a quick insight in the code instead of full-blown debugging.

By developers, for developers

J!Dump is a free GPL extension, which not only means you can use it as you wish, you’re also encouranged to contribute to it. If you want to add some features, let me know, and I’ll add you to the project.

The migrator component makes moving data from your old Joomla! 1.0 site to a shiny new 1.5 site very easy. You can even make it migrate data from third party components, using the so called ETL plugins (for Extract, Transform, Load). But what if the components you’re using don’t supply ETL plugins? Roll your own! You don’t have to be an expert developer — just follow these easy steps.</p>

Find out which database tables the component uses. You can usually find these by looking at phpMyAdmin, or by looking for files in the component’s /table folder.

For each of these table, make a new file and give it the name of the table. Eg. if the table is called #__guestbook, make a file called guestbook.php. Keep in mind that come components might depend on tables from other components or the core, such as the user table. You’ll need to make sure you migrate those tables as well.

Install the migrator component on your old site, and use it’s upload feature to add the plugins. Activate the migration and continue as usual.

Enable Legacy mode and install the component. Make sure to check the XML file, some components have a DROP TABLE statement in there. It’s also good practice to use CREATE TABLE IF NOT EXISTS statements.

This approach should work for most of the components out there. Still, this is only the tip of the iceberg. Migrator plugins are a lot more powerful than that. They allow you to rewrite the tables and the data in them, eg. for when the 1.0 and the 1.5 version of the component have a different database schema. If you want to learn more about that, you should take a look at the actual ETLPlugin class, as well as the core plugins that come with the com_migrator package.

Resources

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

simplicity

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?