tjduavis.JourneyMan

weblog dedicated to software development, philosophy, and theology

Unleashed: Release 0.2

2 Comments

For release 0.2, display aesthetics were placed to increase the user interface appeal, additional features were included based on the first release and resolving bugs were also accounted for.

I changed the timestamp to be more reader friendly and the I disabled the textbox as I had issues getting the description element formatted properly. The current twitter api sets the timestamp as a UTC with the following format “Thu Nov 22 20:05:49 +0000 2007”. So the current parsing will be UTC instead of local time.

display-aesthetics1.jpg

Drag and Drop Features

The drag and drop feature was motivated by release 0.1 and how multiple services could look like. Myk Melez, Dave and I agreed that the Coop with multiple services should not have a feeling of separation but rather give a sense of coherence, so that when one network services connects the Coop will aggregate the list of friends to the existing friends.

Our idea in giving a sense of coherence was to allow the user to merge identical users in different social networks by dragging and dropping one friend icon to another. Then the next time the user logs-in, the Coop will recognize this relationship. If a friend has multiple accounts associated to them then in the “friend view” you will see a drop down menu called “detach accounts” allowing the user to unmerge associated accounts.

merge1.jpg

merge2.jpg

Unfortunately the Facebook service in the Coop is down which also appears in the current production test release therefore I could not perform testing for Facebook friends so the merging/unmerging only happens with Twitter friends (as it is still possible to have friends in one social network acting as one person).

Lastly I changed the the method of logging-in by replacing the login button with a drop-down menu and including a the two services in the “friends” drop down menu.

 

login.jpg

 

login2.jpg

 

Process, Interesting Observations and Challenges

This release gave me an exercise in researching and understanding the existing Coop code as I had to resolve bugs and include more features. Editors, such as Visual Studio that have a bookmarking tool are a great asset in tracing various function calls.

 

I had exposure in ajax technology and advanced “hacking” using Javascripting when trying to resolve a bug. One of the bugs that I had to look into was suppressing the authentication prompt dialog when an unsuccessful authentication login was made and a twitter service call was attempted since Twitter currently uses basic http authentication scheme (so don’t use password reuse on Twitter as it is sent over clear text). I did my initial research and I found few articles suggesting that Ajax could not suppress this as the browser reads the authentication response before Ajax performs handling. I then attempted to research for a component in XPCOM that could provide this sort of handling. I found one but before attempting to test this I wanted to discuss my issues and research within the Mozilla developer community via IRC. Luckily Myk Melez knew a hack and pointed me to a piece of code within the Mozilla code base via LXR which was ironically implemented within the Coop.

 

Another interesting note was to see how the observer pattern was effectively implemented in the Coop and how mozilla created XPCOM to help facilitate – the drag and drop feature was a prime example. The drag and drop benefited me in two ways: (1) allowed me investigate how dragging events are used with XUL components and (2) get into the details of the database design.

 

For my investigation of the dragging events I was a bit more confident in researching and testing out my assumptions as I had experience with events in the past with various programming languages (.NET / Java) which allowed me to approach my problem more systematically. I also used LXR to help find code samples in restricting data values that are not url’s being passed from the drag to the drop as each friend in the “Friends List” sends its ID to drop for the merge processing. For the database design I built a simple cross reference table that joined the multiple to multiple relationship of the friends table and accounts (social network) table. I originally had issues with the query which prompted me to look for support with SQLite database (which I got immediate feedback from the author) but upon closer examination the issue was the query itself and not the mechanism of Sqlite. Although I want to examine further into the Mozilla’s XPCOM storage wrapper as I want to know exactly how the method/attribute .params.[parameter variable] functions. Currently I am getting unexpected results when passing values that contain a “,” and it used within the IN operator. I have a current work around but in terms of remaining consistent with the existing code layout I would like to get it to work.

 

One last bug that seemed to surface (I don’t recall testing this during release 0.1) was the refresh of friends upon a new install of the Coop. During an install a Sqlite database has not been created so therefore when upon a successful Twitter login the Coop will update the friends and messages and proceed with generating them in the corresponding tables of the newly create Sqlite database file, and lastly populating them in the sidebar panel. However the sidebar panel does not get populated and it takes a closing of the Coop (not necessary logging off or shutting the browser) to get a successful populated sidebar.

 

Final Thoughts: Reflections of the Coop

 

Contrasting from release 0.1 this project had numerous unknowns in terms of how the generic social engine would be designed and developed. Scope creeping was the strategy agreed for the solution to the dilemma. Some progress was made by providing a more detailed look on how the persistence layer could look like. What else is surfacing are component patterns that could appear in a social network engine. They are: authentication management, user and content management.

 

For the next release what can have the most value? Will implementing the core service in other online desktop projects provide measurable project value in creating a generic social engine? Or should work be allocated to either refactor existing code to be component centric or should scope creeping remain a feasible approach. How would the final core engine look like? An XPCOM component written from an OO language such as C++/Java or would it the remain as a Javascript component – if so how would external applications access the engine? I know personally I would like to perform more unit testing and assistance / feedback in code review for not only in effectiveness but also efficiency purposes.

 

On the last note I think the best value for the Coop as an extension application would to act as a bookmarking tool for friends connected through various social networking tools from Facebook, Twitter, to your email and personal information management applications. Although I envisioned emailing to be aggregated, my discussions about the Coop with my coworkers changed some of my perceptions. While I received positive and enthused feedback on the idea and concept of the Coop, they both expressed concerns of overkilling it with features and creating knockoffs of existing messenger applications.

Advertisements

2 thoughts on “Unleashed: Release 0.2

  1. Pingback: Is History Repeating Itself? Mainframe == Web Browsing « tjduavis.OpenSource

  2. Pingback: The Coop with Twitter Support: Release 0.3 « tjduavis.OpenSource

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s