Archive for the ‘Bugdar’ category

Bugdar 1.2.0 and the Future

Now that Bugar 1.2.0 is out in its final version (you can go grab it from the Bugdar page), it’s time to start thinking about the next major release of Bugdar.

Major releases of Bugdar have been happening about every 9 months: 1.0.0 was released 17 January 2006, 1.1.0 was released 1 October 2006, and 1.2.0 was released 14 July 2007. I have been wanting to use some OOP features in PHP5 for a while in Bugdar (namely the ISSO3 framework) but because I don’t want to cut down on the userbase, I have been wary of doing so. However, with the GoPHP5 project roughly 9 months away, it seems like the perfect opportunity to switch to PHP5.

I do think the next release will be 2.0 as I don’t think there’s enough semi-major features to warrant a 1.3 release. I have some ideas as to what should be in 2.0 and I think it will be an amazing release. You can see just a few of the features that are likely coming in 2.0 here. Unless there is opposition to doing so, I think the next version of Bugdar will be 2.0 and will be PHP5 only. Moving to 5.2+ would mean a lot of legacy code can go away and I can move into much more advanced OOP programing, which would make Bugdar more robust and would help reduce the number of bugs, as well as increase testability.

And a side note: I’ve started moving all my open source SVN projects to be at Sourceforge as a way of consolidating my servers as I won’t have the resources to maintain as many next year in college! You can find Bugdar’s page here.

Bugdar 1.2.0 Last-Call

Bugdar 1.2.0 is almost ready for it’s final/debut release. There are just two outstanding issues that I would like to close before releasing. If you are in a position to do so, please help by submitting as much information as possible about these two bugs:

• #86 – Issue with marking bugs “hiden” that I cannot reproduce
• #82 – RTL/Hebrew emails are showing corrupted characters

Any help would be appreciated in order to move 1.2.0 out the door.

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.

Bugdar 1.1.4 Released

While others may be taking the day off for Thanksgiving, I’m seizing the opportunity to get 1.1.4 out the door. I’m tremendously thankful for all the people who have sent bugs and feedback to me because it’s really helping Bugdar’s evolution and future development.

For those of you who use the SVN sources, I’d like to point out that the 1.1.x line has now been branched (branches/1.1.x) as the 1.2.0 release is now going to be developed on the trunk.

Happy Thanksgiving to those of you in the U.S.!

Updates Ho!

Hot on the heels of 1.1.0 is going to be 1.1.1. There have been a few bugs reported that need to be addressed sooner rather than later, so after I get a few more reports (I’m waiting on a couple) I’ll hopefully release 1.1.1 sometime later this week or early next week. So keep your eyes on the website or on the version checking feature in the Admin CP.

It’s Out!

Exactly a month late (sorry!), Bugdar 1.1.0 out the door. With a completely redesigned website and a new home, this release of Bugdar is very special. It means that the old Iris Studios website can now be shut down because all the products have been transferred over to Blue Static.

Version 1.1 is definitely a giant leap forward in Bugdar’s evolution because its code is significantly cleaner and more secure than in 1.0. I’m already thinking about what will come in 1.2 and beyond and the future looks exciting.

But, for the moment, I’m going to take a break to work on school and college applications. Enjoy the release and please report any bugs in the tracker!

ISSO3

A few posts ago, I mentioned ISSO3. Well, work has been started on the trunk. ISSO3 will require PHP 5 or higher. I know a lot of hosts don’t yet meet this requirement, which is why ISSO 3 won’t be used publicly for quite some time. But that is a Good Thing(tm) because it allows plenty of time to give ISSO the overhaul it needs.

What’s different so far?

There’s now no more single kernel that you instantiate. Instead, you use the BSLoader class (now all classes are prefixed with “BS” for Blue Static) to create a new BSRegister. BSLoader is responsible for loading modules and creating new registers. BSRegister is responsible for setting objects for a given key, like this:

$register = BSLoader::NewRegister();
$register->register('db', BSLoader::LoadModule('DB/MySQL.php'));

Then, you can get the object later:

$register->get('db')->query("SELECT * FROM foo");

BSLoader also has the ability to set a “main register” which is the register that all modules are linked to by default (if they need components from other modules). This allows you to do this:

BSLoader::SetRegister($register);

… and then in some function, you don’t even worry about scope:

function random_function()
{
     $result = BSLoader::GetRegister()->get('db')->query("SELECT * FROM moo");
}

So that’s what’s happening on the ISSO3 front. And because ISSO is no longer installed separately, it will stop getting standard versions (3.0.0) with the release of ISSO3 and instead will be given build/release numbers. ISSO3 will probably be somewhere between #11 and #13.

I’ll post more about ISSO3 development as it happens.

As a side note, Bugdar Beta 1 has been very-positively received with only minimal bugs. If all goes well, we could see another beta sometime next week. I do think we’re on track for a early-September final release.

Burlan 1.1 Beta 1

Well, obviously the new Bugdar 1.1 (“Burlan”) Beta 1 has been released. Accompanying it is this gorgeous new Blue Static web site that will be the new home of Bugdar!

So, about Bugdar 1.1.0 Beta 1:

There are two known bugs. The first is #25 in which deleting a comment doesn’t update the last post information. The second isn’t reported and is more of something I want to fix. The drop-down for product selection will have a blank row inserted when a product has only components and no direct versions. I don’t really know how to fix this as don’t show up without having at least one underneath them.

As for the release itself, I’m quite pleased with how far this has come since the 1.0.0 Alpha days with all kinds of scary code all over the place :P. Bugdar 1.1 will be a huge improvement over 1.0 in that it introduces much more OOP code through APIs and cleaned-up classes to handle notifications, history, and other data. To give you an idea of how many new classes were added, Bugdar 1.0 had 13 files total in the includes/ directory. In Bugdar 1.1, there are 28–more than double the previous amount!

Bugdar 1.1 also takes advantage of version 2 of the ISSO framework, which is excellent because it means that I can finally drop version 1! Even though ISSO2 is just finally reaching full adoption, I’m already thinking about version 3–but that’s a whole different post.

« Older Entries Newer Entries »