weblog dedicated to software development, philosophy, and theology

Perseverance: Release 0.5

Leave a comment

A speaker at my church illustrated perseverance as carrying a heavy load and maintaining this over a period of time. He then stated that building endurances requires taking on this load. This project, along with my other last term courses is going to build some major endurance! I just want to share this and to encourage both the people out in the web and DPS911 students (especially the ones preparing for graduation) to keep persevering! Keep fighting, Keep doing the right thing, Keep producing amazing work! You’re building endurance so that you can continue to persevere on whatever load you’re going to carry!

Release 0.5 Reflections Notes

The process of finding where I need to code came from a top-down approach where I started reading the UI layer to find the targeted functions/components (item selection/properties panel view states and the tag persistence layer). The techniques I used are mainly educated guesses/assumptions and debug “alert” statements to help me trace and walkthrough the code. In this release I also leveraged the MXR repository tool to assist in understanding code. For instance there was a discrepancies I found with a method in the Places View so I shifted my focused to MXR for an answer. The last notable highlight of release 0.5 and the code review is the persistence layer. The persistence layer is encapsulated in a XPCOM class called nsITaggingService. I created a mind map but its a hard copy. I still need to get use to creating a soft copy as I like the traditional manual way –the usability and user experience is much better!

Release 0.5 Status

There are three problems I had encountered. Two are bug related while the other is more on process. The bug related problems can be found as a posted comment filed in Bug 412002. I have also attached my latest patch there as well.
My process problem was a possible patch collision. A patch collision problem is when you create a patch from an outdated source tree on your local directory and attempt to apply it on the current source tree in the repository. I consulted my classmate Cesar about this issue. He informed me that testing out my outdated patch on a separate folder containing the updated source tree would be the best idea. Luckily I had only one block that failed during the patch and was small enough to manually fix it.

Now I want to find out a more efficient method in resolving collision problems with patches!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s