tjduavis.JourneyMan

weblog dedicated to software development, philosophy, and theology


Leave a comment

Perseverance: Release 0.5

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!


1 Comment

Bug 412002 – First Impressions

Here are my mock ups for the multi-edit feature that I am planning to enhance for bug 412002. I have attached the mockups with additional comments under the bug number for the community and Mozilla people to review before I begin any major implementation. This is also gives me a chance to understand what the requirements are and to determine what it takes to provide a solution.The following are a list of first impression plans for providing this bug fix:

  1. Find out the function that displays the properties form when (i) a bookmark item is selected and (ii) when a bookmark folder item is selected.
  2. Find out the function that takes care of persistence management.
  3. Modify the code to include the properties form to be enabled when more than one item is selected. Then update the way the persistence management layer so that it includes the latter operation.
  4. I am not sure how identifying two or more items selected works, so I am going to need some additional research in this field if upon finishing item 1 of this list provides no certain solution.


Leave a comment

Plans for Release 0.5

For release 0.5 I was planning to work on the either the autocomplete or multi-ended bug. But before on deciding which one to start attacking, I wanted to discuss some of my plans and thoughts with my mentor / the team to see if this is the right focus.

During the discussion I found on that the tag editor bug has now gone into limbo. It seems that the tag editor was going to implemented by an external party so Dietrich suggested that its not a good bug to dwell on at the moment. I told him that I was willing to have any replacement for that bug (So it looks like going to have some time available to do more ‘for each’ js fixes on the trunk for mfinkle after all… :P)

So for my plans for release 05, we both agreed that working on the multi-ended bug would be the best focus. What I’m going to do is to first prototype the ability to “select multiple URIs and edit tags”.

Mind Mapping and Code Understanding

One method of researching and understanding code I want to commit to do is to try to produce a mind map. Mind mapping was introduce to me in my 12th grade physics class as a form of brainstorm and test/exam preparation technique. The motivation behind this was during last years work on the Coop. I had difficulties in trying to remember what function called each other and thus my editor was scattered with bookmarks.

My goal for mind mapping is not to produce every occurrences of each function as that is already provided in MXR but rather assist in providing a visual conceptual model view of what functions and components relate with each other within the Places API and Firefox itself.

I’m a visual learner so I hope the extra work in producing this can benefit me in the long run. I will produce this mind map on my main wiki page to share.

I found an open source mind mapping software called FreeMind. It is in its 0.x release so expect some rough edges but overall it does the job. It can export the mind map into various file versions like a doc or HTML.

Action Items Planned

– Find out where the changes need to be applied
– Research proposed solutions (MXR, Google, IRC)
– Try and test out solutions


Leave a comment

Reflections on Release 0.4

Places is very interesting new feature that is going to be included in Firefox 3. Although I don’t quite understand all the ins and outs of the feature…yet!, what I do like is that there is studies and work being done to improve on how Firefox manages information such as bookmarks/history (I think information management and HCI is a field that I think I’m growing a liking for).

My initial research was sifting through documentation on the Mozilla website. I found articles, documents on the goals and requirements for the Places API and was able to find the main channel of the Places developers on IRC. Before obtaining the bugs list, I wanted to try to connect with the Places developers and just let them know that I was interested in helping out the team by providing bug fixes. I want to be able to build a relationship with this community so that I can know how to work with them as a team and meet both my objectives and theirs.

I had a very good conversation in IRC with Dietrich (eventually I learned Dietrich was going to be my mentor), a Firefox engineer working on Places. Dietrich gave me an overview of the Places code location within the trunk:

<dietrich>
Places is split (as you can see on the wiki) between /browser and /toolkit
<dietrich>
places code in /browser is mostly xul and js
<dietrich>
places code in /toolkit/components/places is mostly xpcom services
<dietrich>
some in js, some in c++

He also gave me tips on joining the Places mailing list and watching others handle and attack bugs. Other cool Moz folks helped me to get edit bug status on my Mozilla bugzilla account (Thanks Gijs, mfinkle and gavin!).

Dietrich initially suggested that I work on the multi-ended bug as the tag editor bug had some dependencies that needed to get resolved but we then decided that working on Bug 412600 would be more fitting for me to tackle first. This way it would allow me to do some code scanning of the Places code base and help me to get accustomed to the bugzilla environment. Although the bugzilla interface is quite intuitive and the topic was introduced in last years course, I still wanted to find references to help guide me when submitting my FIRST patch. Here are some articles I stumbled over the Internet that I want to share before ending this post.

Enjoy!
http://www.bugzilla.org/docs/2.18/html/lifecycle.html

http://developer.mozilla.org/en/docs/Creating_a_patch

http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree

http://fdiv.net/2007/05/15/the-secret-life-of-a-thunderbird-patch/#more-74


Leave a comment

New Year New Project

No more social networking integration… at least for now…I’ve been assigned a new project to work on Places API Bugfixing. It’s disappointing not to see The Coop being carried to 1.0 but the reality is there aren’t enough of a user base to continue developing (Another example of how marketing and evangelizing is crucial to a product life cycle). Maybe The Coop will have a re-birth somewhere down the line but wherever it goes I hope I can have the opportunity to be apart of it.

Despite the disappointment I think taking this project is a great opportunity for me to build on skills and principles of software development. All software have bugs and being able to have the right mindset, methodology, skill to manage and handle bugs is really important.

Whats even more cooler is that the work that I am contributing will be included in the release of Firefox 3!


Leave a comment

The Coop with Twitter Support: Release 0.3

For release 0.3, I performed another “polishing” iteration on what I had produced from the previous release.

This iteration was divided into two objectives: The first was to resolve known bugs or unexpected results that carried through from the previous releases and the second was to continue enhancing the user interface / user experience.

The following is an outline of the changes with additional personal comments describing my overall process, experience and lessons learned during this release. For information on obtaining the source code and installation please refer to the Desktop Social Networking Integration project wiki page.

Bugs that have been resolved based on release 0.2:

timestamp-fix.jpg

  • The timestamp is now synchronized with twitter.com. I originally thought that the timestamp of their messages were converted into local time but I believe they are all converted into UTC format. The problem that I did in the previous release was not include the timezone into my Date.parse function.
  • Logging into Twitter upon a first install caused the the main panel to be blank. The user would have to close/hide the side bar and re-open it in order to populate their list of friends. This problem forced me to further investigate how Ajax processes events. Although I have a solution, I still do not fully understand how events work with Ajax. It seems to be like a stack that is generated from a recursive function, as the next line of code can be called and processed despite not completing.
        this._fbs.updateFriends(); //uses an ajax call that processes based on events
        this.buildFriendsPane();
  • Logging into Twitter on the same browser and profile but with a different account would create a problem of displaying the previous logged in users friends. This has been resolved and been tested. I ensured that the correct user id drove the relationship of data being used in the database upon logging in.

User interface and user experience enhancements:

main-console-release03.jpgfriend-console-release03.jpg

  • Replaced the textbox xul element used for displaying the status update messages of the user’s friends with a description xul element. This was the original design but I had stuck in trying to wrap the text value. The problem was that I was setting the text value as an attribute instead of a children of the description xul element. I researched examples on programmatically creating a child “node” for an xul element and the a little snippet can be seen below:
          var timeStampDescripElement = createXULElement("description", { width: "80" } );
          var timeStampTextNode = document.createTextNode(msgTimeStamp);
          timeStampDescripElement.appendChild(timeStampTextNode);

          statusMessage.appendChild(timeStampDescripElement);
  • Once the description element was in place, I noticed that it needed to further esthetics enhancements as it was very plain and dull. The textbox revealed how it looked with straight borders so I wanted to try something new. To be consistent with the theme I used the existing design scheme of the fade and added that CSS class for the description xul element.
  • The last touch up was the aligning / spacing of the messages and the timestamp. For the main friends view I placed the timestamp from the bottom and aligned it to the right as it seemed like a more pleasing appeal and balanced the existing composition. For the friend view I made the timestamp and messages structured row by row, with the timestamp being the first column and the second is the actual message. I wrapped both timestamp and messages in order to have a clean spacing desite the length of the content.
  • During my testing I noticed that my friends in Twitter posted hyperlinks on their status messages. I noticed that these hyperlinks did not wrap around despite it being included as text node. I thought that the problem was the hyperlink needed to be set in a proper anchor tag element so then I did so more overtime work. I have to give credit to Start IT Up and a couple of MozDevs (Ted and Mfinkle) for helping me generate ideas and tips to solve my dilemma. Despite the solution for setting the hyperlink in an anchor tag the problem still occured. So my next idea for a solution was to determine if the hyperlink was greater than the space allowed and if so I would cut in half the text and appended a “…”. The code for this is really ugly but I just wanted to mockup this up and see if it provides any value or could be elaborated.

coop-release03-hyperlink1.jpgcoop-release03-hyperlink2.jpg

I recognize that there still needs to be a lot more testing and further feedback on the existing user interface / usability is needed, so please feel free to try to break my release or butcher me with comments on the overall appeal and usability… Happy “hacking”!


Leave a comment

Brainstorming for Release 0.3 – Polishing Iteration 2

For this release I will focus on providing user interface / usability enhancements. I will also look to resolve any development bugs or unexpected results that have occurred.

The brainstorming list of possible enhancements are:

  • For the current message display of friends and friend view, should I invest time in getting the messages as a description XUL element or should I leave it that way and try to beautify it a bit more?
  • I think I should try to find away of translating the timestamps from UTC to local time? My original assumptions are that Twitter’s API is translating the time a message is published, from local time to UTC. (Basically blaming Twitter’s API) Would there be a way to convert this back? Or is my assumptions wrong (And I’m the one to blame :P)
  • Drag and Drop. Any comments? Room of improvements? (Always I know but I’m up for it!) I notice that when you drag the person to a textbox in the actual browser it drops its Coop user number, should it drop its home page link? But if it drops its home page link then what about multiple accounts. Maybe it should drop something else? Or maybe we should let the user decide? But I think we got to build a managing use case for that.
  • Login? Thoughts on the new design? (I have to give credit to my coworkers for helping me brainstorm this!)
  • One known bug or unexpected results is the Facebook service currently being down. That needs a certain amount investigation but it would be cool to include the Facebook service with the drag and drop feature!

    Food for Thought: brainstorming ideas to stimulate both the Coop and the Desktop Social Integration project for DPS909:

  • In regards to researching and reflecting on the future of this generic social engine API …thingamabugger… based on my own experiences writing release 0.1 and 0.2, and the community ideas found in the Coop Mozilla Labs forum:
  • I agree with Myk Melez statement about differentiating the core functionality of the Coop from the services that integrate with it but I still stand with being cautious about overkilling the Coop and the concerns of raiph. But maybe a good action item is to compile a table of possible features in Coop and features with social services and their features that could be integrated with the Coop. So that it easy to communicate and manage this to both technical and non-technical users. This table should be interactive where editing is available. Maybe it could be built in a wiki! Because I agree with Myk Melez statement and also based on my own experiences that “…The challenge, of course, will be designing that core functionality and aggregation interface in a way that makes it possible to integrate all those sites and useful to do so.”

    I am also wondering how the architectural highlights of AllPeers resource framework could help and if there are any steps for the concerns of remote service-provided content from feeds. I haven’t had a chance to explore it but the the original discussion initiated from a post by an AllPeers team member but I thought I should mention this to stimulate ideas.

    Discussions of Service Manager from Stevo Bengston and lilmatt is another good place to do some researching and exploring in terms of reflecting on building a generic social API. Which brings me to my next point that I would like to share.

  • I casually got in contact with a developer/supporter of Flock couple nights ago and pointed me to the Flock code base and its IRC community. I want to share this resource as well.
  • <jeremy>    tjduavis: i still have to read scrollback here, but fyi, we have our own 
    IRC server (irc.flock.com). feel free to come by and make inquiries ...    
    
    <jeremy>    tjduavis: also, we have lxr @ lxr.flock.com and 
    viewvc / trac @ svn-mirror.flock.com

  • In terms of looking forward to the future of Desktop Social Networking Integration, in my attempts to frame the problem and solutions by researching and reflecting about RH’s Online Desktop Project I would like to share some thoughts and findings.
  • One idea for the involvement of The Mugshot project is to provide some sort of server aggregator for the Coop handling content management.

    For my own reflections I would like to see personal information management type applications like Chandler, Thunderbird/Sunbird, or other vendor based products (Windows, Linux, Mac) get integrated. I think its important not only in the realm of network socializing but also in terms of organizing and managing contacts and its associated content (photos, videos, etc.) with daily workflows back into the browser. Building up on the idea of AllPeers’ view on contact lists being based on the browser as oppose to the IM, the desktop should be the intermediate between native desktop applications and browser based applications. Therefore the Coop and its generic API provides a bridge or adapter (not getting into the actual specific design pattern) to the browser.