pegasus

I wanted my next post to include a video that shows some of the new admin tools. Unfortunately I discovered earlier this weekend that the microphones for 3 workstations are either broken, defective, or missing. So if I were to post such a video it would be sound-less and probably somewhat boring. I have placed an order for new microphones that should be arriving by the middle of the week.

In the mean time, this gives me the opportunity to talk about other changes, specifically to our workflow, that I believe improves our coding efficiency and will serve to make VaultWiki 4 more reliable than its predecessors.

Offline Development

In the past, we performed all development on our live server. The intent was to be able to immediately see the results and the effect they have on a production environment.

With VaultWiki 4, this was simply impossible. VaultWiki needed to be rewritten from the ground up and doing so in a live environment would take our demo wiki offline for several months, cost potential sales, and detract from whatever image we have earned since first starting to offer VaultWiki.

Instead we created a number of forum installations on an offline development server, running each major version of vBulletin, Invision, and XenForo.

We pointed all installations to the same VaultWiki repository. This way we only need to make changes to one instance of VaultWiki and can still see the effects in any of the various environments. This saves a lot of time that was previously spent manually merging changes to each test installation separately.

Using an IDE

While in the past we edited VaultWiki's files in a standard text editor, files in the central repository are now modified through an Integrated Development Environment, specifically Eclipse. After installing a few plugins, we found that Eclipse actually supports all of the features we need, so we felt that for us, the cost of a paid solution like PHPed or Zend Studio was unjustifiable.

Like the other IDEs we tried, Eclipse identifies errors in the code in real time – that is, while the developers are still typing the code. This practically eliminates many syntax and parse errors from appearing in the final release. In previous releases, these types of errors happened relatively frequently, especially in the upgrade system and other areas of code that were hard to test exhaustively.

Closing Thoughts

There are also another number of changes regarding coding practices and overall design that also contribute to efficiency and product stability. These are probably best discussed in a more developer-targeted entry. However, should the new microphones arrive in a timely manner, I will be back to discussing new features for the foreseeable future.