tjduavis.JourneyMan

weblog dedicated to software development, philosophy, and theology


Leave a comment

Milestone 1 – Release 0.1a Deliverable Outline

The following needed to be changed as unexpected results were encountered with how I provided twitter messages during feedback for release 0.1.

Feature 2 now includes a status message per corresponding friends I have in Twitter.

Feature 3 now includes 20 most recent status messages. The maximum limit the Twitter API returns for a user’s status messages is 20.

coop-twitter-viewmessage-friend.png

Notes and Thoughts:

I have an issue in listing the status messages. I would imagine the timestamp and status messages per friend would be arranged in a descending order but I have some design issues to consider that could affect my current logic in adding my friend’s messages. The first issue is whether or not the messages is going to be deleted in the sqlite database since the friends do not get deleted. My tests in determining if the database contents get deleted upon exiting the program is when I tried to login into the twitter account unsuccessfully, (both The Coop authentication dialog and the http dialog) my twitter friends are displayed and the coop loads the main pane.

My second issue is with the user interface. I just used a textbox to simply display the messages for protoype purposes, but in terms of visual design and usability the textbox just does not work.

Lastly, there needs to be a visual and usability design in how various network services like Twitter should get initiated. Currently the user must select login from the “friends” menu (I have to find out how to change Login to be more distinct to Twitter as I used existing code for the default login name value for Facebook). Should the Coop refresh the sidebar panel to reflect the friends per social service, should it completely aggregate all friends for any successful logged social services, or should it be combination of both where the user can hide and un-hide friends per social service?

The above are my major design issues that became relevant to me once I started developing, so if you have any ideas or suggestions please let me know. The first applies directly to The Desktop Social Networking Integration project since the goal is to create a generic API/engine for The Coop and the other two just strictly applies to The Coop.

You can find the latest source code and patch from my project wiki. The code is very rough and requires a lot of refactoring.


Leave a comment

Bugs Bugs Bugs

This is the first entry of my katch-up…

cc’d myself to the following interesting bugs that I would like to investigate to understand how open source manages bugs:

All these bugs don’t relate to my project (couldn’t find any bugs posted… but would probably post as I get deeper in creating development bugs…:S)

https://bugzilla.mozilla.org/show_bug.cgi?id=335289
– i’ve seen this beltzner in #seneca!

https://bugzilla.mozilla.org/show_bug.cgi?id=391863
– just seems interesting…

https://bugzilla.mozilla.org/show_bug.cgi?id=400240
– I choosed this as I can learn more about sqllite since I’m dealing with a sqllite issue with my release 0.1


Leave a comment

Desktop Social Networking Integration – Contribution Opportunities

  1. log into twitter and be my friend.
    • I mostly have random Brazilian and European friends that don’t interact. I have mfinkle but he already admits that he does not go on much.
    • tjduavis is my user id
  2. research oo-techniques and design patters in javascript
    • Not too familliar with JavaScript but my design patterns and 00-techniques I learned would be useful so any sample codes and resources would be great!
  3. help to research BigBoard and Firefox 3 Journal as I look to integrate the generic API
    • Anything right now: API; languages; blogs; code walkthroughs; technical experts


Leave a comment

Milestone 1 – Release 0.1 Deliverable Outline

The following attempts to describe and provide an outline using screenshot examples of the deliverable of release 0.1 for The Desktop Social Networking Integration (DSNI) project. More information about DSNI can be found in the project wiki.

coop-release0.1

The above shows an example of The Coop application with basic Twitter support. When The Coop is loaded the user is prompted with a login page. The prototype release (Coop 0.1) prompts the immediately prompts the user to the Facebook login page, the default social service, however this is not the case with DSNI release 0.1.

1. Login
In order to log into Twitter, you must click the pop-up drop down “log in” menu item of the “Friends” menu located on the top left corner of The Coop pane.

coop-twitter-logincontrols.png

When selected The Coop will routinely open an authenticate window that loads the corresponding social service login page, which in this case its http://twitter.com/login.

coop-twitter-login.png

2. View Friends
Upon a successful login, The Coop will build the pane with a list of friends I have in Twitter.

coop-viewfriends1.png

As you can see from above I have a total of five friends. Below is an updated screen shot of my friends pane that during an added mock-up friend used for development purposes called “tjduavisDev”.

coop-viewfriends2.png

3. View Messages
When the user selects one friend from the list, The Coop will transform that pane to contain only the selected friend with two additional controls: “back button” and the “more button”.

The below diagram shows the ability of viewing messages when the “more button” is selected. As specified in The Coop release 0.1 the default location of the “more button” points to the web service accounts message box page.

coop-viewmessage1.png

I did not have any messages from my new friends so in my mock up friend account, “tjduavisDev”, I sent a message to my own account “tjduavis”.

twitter-sentmessage.png

Now you can see below that I can access my message through The Coop.

coop-viewmessage2.png


Leave a comment

Milestone 1 – 0.1 Lessons Learned

1. JavaScript is crazy / powerful. Mozilla the strong foundation.
Enough said! I’m not too sure about the origins of JavaScript but Mozilla’s got a strong source of reference.

2. Code walkthrough while researching and testing.
If you understand basic syntax and the general logic use debugging techniques then “hack away”! Don’t separate the tasks of researching, reading code and unit testing. I think its better to have something ugly then spend all day dreaming of something beautiful; you can always go back and refactor.

3. When performing code walkthroughs have clear objectives.
Document what you want to achieve as it walking through code can be very confusing and exhausting. Expect to have multiple drafts and to take various notes.

4. Use top-down and bottom-up approaches during code walkthroughs.
Don’t go too far in the bottom if you don’t need to.

Notable personal accomplishment
• Basic debugging knowledge and skill with Venkman
• Basic knowledge of console debugging (@mozilla.org/consoleservice;1)
• Basic working knowledge of component classes
• Basic working knowledge of json, xml, and web service interaction (Twitter API, AJAX technology)

Final thoughts
I still got a lot to learn and improve on. Not trying to develop a code walkthrough methodology. I am just documenting and reflecting on my past experiences in hopes to better myself. So I look to have fun, stay positive and find challenging interesting programming projects/tasks to build myself on.