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.

New Type of Redesign

When I normally think of redesigning a site, new color schemes and layouts are usually the first things that come to my mind. However, when I decided to spruce up the Blue Static website about a week ago, I wanted to pose myself a design challenge: I did not want to use anything but existing design elements to create my refreshed design.

To accomplish this redesign, the first thing I did was I found and isolated the elements and colors that I liked the most. Some people say that a good design starts out in black and white and then colors are added so that it’s color-agnostic. However, I find that when I’m designing–both for print and the web–if I don’t have a vague idea of the final color scheme, the design just won’t work. So I picked a few elements (namely the striped background and the navbar) to reuse all over the place. I then went to work on a design on paper.

Any good designer will start out on paper just to get a rough idea of how things should look. I have paper designs for Bugdar, Kalens (the demoed calendar product), and this website and the paper looks almost identical to the web version. Designing on paper is important because it allows you to visualize your design without having to write any code. Can you imagine creating an entire website and then scrapping it because you don’t like the way it looks?

I feel that whenever you are _re_designing something, you’re doing it because you did something wrong with the current design. Therefore, before I finalized the paper design, I decided to go through the old website and pick out elements I didn’t like and I made sure I addressed them in the final design. What didn’t I like about the old design? The navigation bar was far too large, so the new design cuts out about 80px of it; many of the banner images had a greenish color which really jarred with the blue, so now the images have all been hued to a more bluish tint; the text was too low-contrast, and so I changed the background to be white.

And when you look at the final design, those are really the only major changes. Everything else has just been ever-so-slightly lightened to make the design more welcoming (darker designs are generally harsher too look at).

Here’s the before-and-after shot: bluwww-redesign-dec06.png (172 KB)

So what’s to learn from this redesign?

1. Keep your design goals clear.

2. Do your layouts on paper first.

3. Don’t change things that don’t need to be changed.

On a side note, Bugdar 1.2.0 is coming along steadily as is ISSO3. I hope to have both of those finished by late April or early June.