Forum Open

After many requests for a forum, I have decided to put one up. I chose to use Vanilla as the forum software because I think it is a far superior solution for what I want. I do not want a whole bunch of staunchly-defined categories delineating discussions, because then the number of topics in each would be few and sparse. With Vanilla, everything can appear in the same category (though you are not limited to this) which makes discussions flow. It may be slightly unconventional, but I think it will work the best.

The style for the forum is not yet done (let alone started), but one day it will match the rest of the Blue Static website. I just wanted to get it open so people are free to use it.

And please do not report any bugs or formal feature requests in the forum, please use the bug tracker for that.

Without any further adieu, this is the forum.

Release Candidate 1

It’s been a long time since I’ve written. I’ve been rather busy with choosing the university I’ll be attending next year, graduating, and then attending an endless stream of parties. But now it’s time to talk about Bugdar.

Initially, I was intending to release the final version of Bugdar this week, however due to a major database change (in the upgrade script, you will be asked to convert your MySQL database collation to utf8_general_ci) a Release Candidate was necessary because I did not feel comfortable releasing a final version with such a big change without a previous public release. I ask all users, though especially those running Bugdar with a non-English language, using the 1.2.0 beta to please upgrade to RC1 and evaluate using the database conversion script and then running their board with utf8_general_ci.

If all goes well with this Release Candidate, then I hope to release the final version of Bugdar sometime next week.

Feature Change for Bugdar 1.2

In my last post, I mentioned a workflow system for Bugdar 1.2. I have since changed my mind about this. The workflow interface would have required a lot more work and testing than I have time for right now, but instead I have added a feature that I think is just as important: an authentication API.

This API will allow developers to create authentication modules to allow Bugdar to authenticate against an arbitrary database. You can make a module for LDAP, ActiveDirectory, or anything that PHP supports–be it another product or a stand-alone database. Currently I have written a module for vBulletin 3 and I intend to do ones for phpBB, Drupal, and Joomla.

So what does this allow you to do exactly? This will allow you to log in at your main site/product and then have those login credentials recognized by Bugdar, and vice versa. It tells Bugdar to not use its database for logging users in, but rather the authentication system you choose. It links together a record in the Bugdar user table to a record in your authentication database and then keeps their emails (and any other fields you specify) in sync.

And that’s a quick update about how Bugdar’s doing right now!

Optimizations in Bugdar 1.2.0

Over the past few weeks, I’ve been working away at Bugdar 1.2.0 and I’ve noticed that the release isn’t going to be as feature-centric as 1.1.0 was. Instead, in 1.2 I’m putting a lot of emphasis on optimization. There, of course, will still be some important and highly-requested features added (namely custom column display and saved searches) but most of the work will be spent on optimizing the code. Bugdar 1.2 is almost done, save one feature that I’m still investigating–which I’ll talk about later.

Some of the minor optimizations are putting conditions around queries to make sure they don’t get executed unless really necessary. But by far the biggest speed improvement I added yesterday:

I made a drastic improvement to the template system that speeds up Bugdar’s average page loading time by roughly half a second. In previous versions of Bugdar, a page would typically load in about 0.7s – 1.0s. Via debug mode, I could see that rougly 0.2s – 0.5s of that time went to caching templates for display. I thought (wrongly) that this was because it was loading templates directly from the filesystem, and the disk access was causing the slow-down. However, after investigating a little, I discovered that the processing and parsing of the template was the true culprit.

To speed up this process, I added code into ISSO’s template system that queries a list of requested templates from the database cache table. If a record exists for a given file, it then checks to make sure that the timestamp stored in the cache is greater than or equal to the last modified time of the actual file on the disk. If it is, then it simply returns the pre-parsed and pre-processed template from the database. If not, then it loads and parses the template from the filesystem and puts it back into the database so that future page loads use the newly-cached template.

While this is relatively minor change, it has drastic consequences for speed: the template caching process is now on average 0.004 seconds–a 100% decrease in template processing time. This improvement makes Bugdar feel much snappier and will reduce the time it takes to load a page, and it will reduce the work put on the server. Now, a Bugdar page completes loading in about 0.1s – 0.4s.

As for the last major feature for the 1.2 release: I’m investigating a workflow system. What this would do is it would allow an administrator to define a strict path of statues that a bug would follow, allowing it to only be advanced one step forward or backward at a time, limited by the assignee of the bug (or the group of the assignee of the bug). The back-end work is relatively little, the major problem occurs when figuring out what to filter and what not to filter, etc. on the user-end display (showreport.php) and what to control when saving changes to a bug. This was a user-requested feature so it’s not as fleshed-out in my mind as it could be (as I didn’t think of it), so if you have suggestions or input, let me know.

I’m not making any guesses as to when Bugdar 1.2 is going to be released; major work is nearing completion, but it really depends on the workflow feature and then squashing any bugs found in the beta cycle. I am aiming, however, to have major work completed by the end of the month.

PostgreSQL Build Script

I’m currently working on a Cocoa project. It requires a server-client system. The current iteration of it uses a very complicated Distributed Objects system to send query objects across the network to a single instance of SQLite… and it’s rather flaky if I do say so myself. So I have decided to change it to a PostgreSQL system.

Obviously, however, PostgreSQL is not a standard component of Mac OS X–especially not a universal binary version. So, I had to devise a way to create a packaged version.

After fiddling with build settings for hours, I have come up with a shell script to build a universal version. It is meant to be run on a PPC platform to cross-compile for i386/Intel–not vice versa (though with a bit of modification you should be able to do it).

If you’re interested, you can download it here: build-pgsql-uni.sh (4KB)

And if you’re still interested, my application works like this: the server will broadcast over Bonjour a Distributed Object connection, as well as spawning this special distribution of PostgreSQL. The client will accept this and will receive a NSUrl with the database connection URL and then the rest will be handled by BaseTen. I think this will significantly improve the performance, and it will decrease code base size because I can use Cocoa Bindings.