tjduavis.JourneyMan

weblog dedicated to software development, philosophy, and theology


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.

    Advertisements


    Leave a comment

    Is History Repeating Itself? Mainframe == Web Browsing

    My boss at RBC told me that mainframe computing is a demand because of the need to preserve legacy systems and to consider the prospective future – this future he was alluding to was the web. He compared the web browser as a modern day terminal connected to mainframe boxes. This perspective lingered with me throughout my extended co-op experience with the bank in where I deal with mainframes. Initially I was very lost and frustrated in understanding mainframes. The struggle was not so much in understanding the concepts but more in trying to find appreciation in learning and respecting this technology.

    During my studies with DPS909 I was both directly and indirectly surrounded by fascinating technological trends. From the many listed projects in DPS909 (source symbol service, localization scripts, distcc, etc.) to the latest and the great in this years FSOSS (Miro, Pure Data (PD), Linux as a Desktop).

    Furthermore, Coop is an extension that I am currently working on for my DPS909 project called Desktop Social Networking Integration. My interests in this project was not so much the growing trend of social network tools out there but the problem in trying to manage all these mash-ups of connecting people in the virtual world with the existing methods of social interaction – whether it be virtual or physical.

    During my research and reflections on the Coop after releasing 0.2 I stumbled on a forum posted by Stevo Bengtson, a software developer for Songbird (I’ll get into Songbird a little later on). Stevo was sharing his thoughts on componentizing the Coop and shared his ideas based on work that has been done on a new browser specifically focused on social networking called Flock (Basically the Coop with a whole bunch of services and features mashed-up in one browser…I wonder what’s Mozilla’s reactions to this? I guess that’s why the Coop initiative was developed…well quoted from a brief chat with Shaver he seems not to focus on the competition but rather on the mandate of Mozilla which is being open and cultivating choice in the web.

    <tjduavis>just really curious of the bat, how is
    mozilla's response to flock, i figure it seems
    like a threat since it has firefox
    
    <shaver>"winning" for us isn't the whole world
    using Firefox
    
    <shaver>it's the whole world being able to choose
    any browser, and the market having a number of
    healthy and active choices in it

    My response was:

    <tjduavis>interesting!

    Well as you can see its just that but I think I still have a lot to comprehend on being “open”. As you can tell from my proud report about FSOSS, I am very much intrigued in the business/economics/marketing side of open source. I wonder if I can get a MBA specializing in Open Source hahaha)

    My other collection of interesting trends and technological projects that I been fascinated and intrigued about ever since getting into open source are:

    1. Coscripter
      • Cool approach on testing the web sites, a tool I recommended my boss and team at RBC to test their internal web applications.
    2. Chandler and The Chandler Hub
      • Indirectly pointed by a reply from Chris Cooper regarding potential work with an OSAF project: based on GTD …Something I need to apply on my DPS909 labs!
    3. Amazon’s Cloud project with Red Hat
      • A crazy product released by a book company? I believe a DPS909 classmate of mine is working on a project related to the Cloud!
    4. Songbird
      • ‘Songbird promises to be the Firefox of media players.’ – Aaron Boodman, Greasemonkey Creator”…Pretty powerful statement Mr. Boodman!

    How does this all relate back to mainframes? Well on one side most of technology is depending on the web. It’s now going from a desktop centric approach of computing to back into a distributed model. It’s easy to get intimated with catching up with all these technological trends but I think its easy to agree with another point my boss made about the information technology industry. For the most part current and future technological initiatives have been already conceptualized / materialized in some form in the past and its just a matter of how one language or platform implements it differently.

    So maybe the importance is not necessary in learning the ins and outs of a platform or technology but rather respecting and understanding history…no matter how dull that terminal screen blinks at you…


    2 Comments

    Unleashed: Release 0.2

    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.


    Leave a comment

    Ready for Release 0.2!

    So I’m ready to get this release 0.2 started and on the way so I just wanted to update you all on whats going down.

    Got my requirements and specs drafted:

    • Fix bugs introduced in release 0.1
    • Fix bugs informed by stakeholder during their attempt to test release 0.1
      • After the login dialog, login process fails and produces a blank sidebar
    • Clean up features and functionalities
      • Order list of friends alphabetically
      • Use XUL description element for messages
      • Remove icons in The existing Coop
      • Replace release 0.1 timestamp format with user-readable timestamp (ex: “2 Days ago”)
      • Provide ability to merge users existing in different social services, with the same identity using drag and drop.

    And I got the mozilla lab community to provide support.

    Now want to get the Seneca Computer Studies open source community to get involved, so here are is another formal invitation to get on The Coop band wagon and sign up to contribute.

    Get in contact with me in anyway!

    Thanks and best regards!