User:Vbala

Welcome to Vijey's Page

My Name's Vijey; I am currently in the seventh semester of BSD and enrolled in DPS909.

Lab Notes

• The diff file that was generated after the changes were made to tabBrowser.xml.
• The changes were made to open a new tab in between tabs rather than having it opening at the end like it usually does.

Index: tabbrowser.xml
===================================================================
RCS file: /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v
retrieving revision 1.243
diff -u -8 -p -r1.243 tabbrowser.xml
--- tabbrowser.xml	18 Sep 2007 00:59:41 -0000	1.243
+++ tabbrowser.xml	15 Oct 2007 22:15:13 -0000
@@ -1088,17 +1088,17 @@
             if (!bgLoad) {
               function selectNewForegroundTab(browser, tab) {
                 browser.selectedTab = tab;
               }
               setTimeout(selectNewForegroundTab, 0, getBrowser(), tab);
             }
             if (!bgLoad)
               this.selectedTab = tab;
-            
+            var position = currentTabIndex + 1;
             return tab;
          ]]>
         </body>
       </method>
 
       <method name="loadTabs">
         <parameter name="aURIs"/>
         <parameter name="aLoadInBackground"/>
@@ -1173,17 +1173,18 @@
             t.maxWidth = this.mTabContainer.mTabMaxWidth;
             t.minWidth = this.mTabContainer.mTabMinWidth;
             t.width = 0;
             t.setAttribute("flex", "100");
             t.setAttribute("validate", "never");
             t.setAttribute("onerror", "this.parentNode.parentNode.parentNode.parentNode.addToMissedIconCache(this.getAttribute('image')); this.removeAttribute('image');");
             t.className = "tabbrowser-tab";
 
-            this.mTabContainer.appendChild(t);
+            var currentTabIndex = this.mTabContainer.selectedIndex;
+			this.mTabContainer.insertBefore(t, this.mTabContainer.childNodes.item(currentTabIndex + 1));
 
             if (document.defaultView
                         .getComputedStyle(this.mTabContainer, "")
                         .direction == "rtl") {
               /* In RTL UI, the tab is visually added to the left side of the
                * tabstrip. This means the tabstip has to be scrolled back in
                * order to make sure the same set of tabs is visible before and
                * after the new tab is added */
@@ -1952,17 +1953,17 @@
           this.mTabListeners.splice(aIndex, 0, this.mTabListeners.splice(aTab._tPos, 1)[0]);
 
           var oldPosition = aTab._tPos;
 
           aIndex = aIndex < aTab._tPos ? aIndex: aIndex+1;
           this.mCurrentTab._selected = false;
           // use .item() instead of [] because dragging to the end of the strip goes out of
           // bounds: .item() returns null (so it acts like appendChild), but [] throws
-          this.mTabContainer.insertBefore(aTab, this.mTabContainer.childNodes.item(aIndex));
+          this.mTabContainer.	Before(aTab, this.mTabContainer.childNodes.item(aIndex));
           // invalidate cache, because mTabContainer is about to change
           this._browsers = null;
 
           var i;
           for (i = 0; i < this.mTabContainer.childNodes.length; i++) {
             this.mTabContainer.childNodes[i]._tPos = i;
             this.mTabContainer.childNodes[i]._selected = false;
           }

Bug Fix ThunderBird Lab
The following is the patch file that was generated by conducting a CVS diff -u8p . > tbirdPatch.txt. Here are the contents of that patch file

? tbirdPatch.txt
Index: streamconv/converters/mozTXTToHTMLConv.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp,v
retrieving revision 1.85
diff -u -8 -p -r1.85 mozTXTToHTMLConv.cpp
--- streamconv/converters/mozTXTToHTMLConv.cpp	11 Mar 2007 00:17:00 -0000	1.85
+++ streamconv/converters/mozTXTToHTMLConv.cpp	11 Nov 2007 18:03:20 -0000
@@ -181,17 +181,17 @@ mozTXTToHTMLConv::CompleteAbbreviatedURL
   if (pos >= aInLength)
     return;
 
   if (aInString[pos] == '@')
   {
     // only pre-pend a mailto url if the string contains a .domain in it..
     //i.e. we want to linkify johndoe@foo.com but not "let's meet @8pm"
     nsDependentString inString(aInString, aInLength);
-    if (inString.FindChar('.', pos) != kNotFound) // if we have a '.' after the @ sign....
+    if ((inString.FindChar('.', pos) != kNotFound) && (inString.Find("..", 0) == kNotFound)) // if we have a '.' after the @ sign....
     {
       aOutString.AssignLiteral("mailto:");
       aOutString += aInString;
     }
   }
   else if (aInString[pos] == '.')
   {
     if (ItMatchesDelimited(aInString, aInLength,

FSOSS REPORT FOR DPS909

Introduction
The two talks I decided to write about which I attended in the FS0SS 2007 gathering were Benjamin Smedberg’s Open source code review and Mike Beltzner’s talk on Designing for and with a community.

Benjamin Smedberg's Open source code review
Focusing on the first talk that I attended; Benjamin Smedberg’s key main reasons behind code reading were as follows:

• Identifying Bugs
• Identifying and implementing features
• Creating documentation or revising documentation that is available for the code
• Understanding how the code works
• And the last and according to Mr.Smedberg the most hardest part of it all; keeping track of the patches or understanding what patches have been done on the software by other people in the community
  

All of the above points in my opinion are very valid points; which will play key roles in a person’s life as a programmer in some way or another. Identifying bugs is one of the main reasons for reading code; and this is why Benjamin agreed that every school in the country teaching computer programming related courses should teach students how to read code and get them involved in some sort of code reading before they leave school and are released into the business field. In his second point of implementing or identifying features Benjamin pointed out the need for properly placing a feature or finding a necessary spot to implement a piece of code in order for it to enhance the user experience requires code reading and code understanding; putting a feature or a piece of code anywhere is not going to produce the most desirable results, in many cases or almost all cases this would just mean inefficient processing time or the system crashing as a whole.

Creating documentation for today’s world of complex and never ending lines of code is key for other programmers who later wish to add to or enhance the already existing code base. This can only be accomplished through code reading and understanding of the correct points at which the documentation should be placed. This documentation could also be later revised as the code is changed or enhanced.

Not so surprising to me was the last point where Mr. Smedberg pointed one of the hardest parts of code reading was to understand what other people’s patches did to the software the original programmer created. To Mr. Smedberg this was one of the hardest or if not the hardest and most frustrating part of code reading, decrypting other people’s code and coding styles.

Mr. Smedberg also pointed out the importance of LXR/MXR as shown to us and stressed on many times by professor David Humphries in our DPS909 class. Mr. Smedberg also talked about tools such as Eclipse, and grep which are useful in finding code parts which are necessary for code reading and understanding. Benjamin regarded himself as the “Guru” of code review, and coding in it self. Mr. Smedberg’s views of the open source world was beginning to sound more and more like the cathedral and the bazaar literature I read back at the beginning of the course. Although he did not quite come out and mention this himself; I got the impression, maybe it was my misunderstanding, especially during his talk about reading other peoples code and patches to bring a consistency to the code base felt like he was drawing parallels to bringing order to chaos and finally producing a product that can help people all through out the world.

Mr. Smedberg also gave some good tips on finding a bug’s source. But before he got into those three points he mentioned one key thing that stood out to me, he (Benjamin) said “You do not always have to understand all the bugs or know how to fix it all”. This drew parallels to something Albert Einstein once said and it seemed to stick in my mind always “Why should I remember something that I can just look up?” That being said the three tips he gave for identifying bugs location are

• Look for common bad patters
• Look for uncommented code bits
• Look for code which was changed recently or something that has being undergoing consistent change
  

Benjamin also told us about checking version control systems, if I remember correctly, these are systems that are in place that people can use to go back in time and look through the code changes as they progressed through time. Then we moved on to “Reading to Learn” or reading to code to learn its layout, structure, and purpose. The objective of this reading to learn method is to understand the big picture, the technologies, functions, object models and function names being used in the system. Benjamin also suggested a programmer should read the unit tests if it is available.

Another part of learning the code is to learn to write test programs that will work with or add to the main code base. These little test programs or code inserts will help the user get a better grip over what a certain function or code set does. Mr. Smedberg repeatedly stressed in this community and this type chaos it is crucial to ask questions. Not everyone can understand the programming style or the purpose behind a certain code set or functions; so in order to clarify the doubts or misconceptions it is best to ask questions and get an answer from the community. Another point Benjamin stressed on was that code reading should be a “social exercise”; it should not be viewed as a process or in the word of Mr. Smedberg himself “It should not be just some geek, sitting in his basement reading code and understand it, people should take a general interest in it and move beyond just coding by themselves but do it in groups or as an activity with friends”.

Mr. Smedberg then got into the reasons why people bother with code reading. These reasons are as follows:

• Code reading is necessary to insure quality in code
• It creates a culture of responsibility where people who participate in any form or nature are responsible for whatever they contribute; good or bad.
• Reviewing code allows for mentoring of newer programmers and allows for more participation of others by inviting people into the community.
• Gets more involvement. When multiple people get to know about the code, it removes the dependencies on one person alone knowing the intricacies of the code.
• The main purpose being for code reading and reviewing is for better human comprehension, better readability and better maintainability.
  

Mr. Smedberg completed these reasons by saying something that really stood out in my opinion. He said everyone is going to have problems therefore never try to solve everyone’s problems because there are some problems that are too complex or too trivial to be solved. He also cautioned to be on the watch out for what he termed as “Code Astronauts” people who try to do too much or try to be perfectionists. He (Benjamin) later on went on to the types or code reviewing and reasons behind it. Some of the major types of reviews he discussed were: (in no order)

Goal Review: What is the problem with code in the system? Is it worth solving the problem? Should an entire system be rebuilt in order to sort out one bug? What are the tradeoffs in achieving the goals? These were some of the questions Mr. Smedberg addressed under the goal review criteria.

Maintainability Review: the main concern under this review is coder understanding of the already existing code base. Documentation is key in this stage and every piece of code should be documented well. Making sure the code is consistent or correct through out the system and ensuring there are no warnings or errors in the code.

Security Review: If the code is being exposed to unknown and or un-trusted people; make sure there are proper function wrappers in order keep the data well protected.

UI Review: Make sure the user interface does what the user expects it to do and is well placed in areas where users will check for it. Make sure the font size and type of text used is consistent through out the UI layers and is easy to understand.

Integration Review: Make sure the modules work with each other properly, and make sure all the dependencies are addressed in the integration review. Also check to see if the final product is localizable and do a review of the documentation at this stage to make sure everything is documented well for the user. This documentation is more of help documentation not code documentation as end user will be highly unlikely to be looking at code documentation more so at documentation on what the systems key functions are and how they can be executed or called.

Testing Review: In this type of review a check is done to see if there are tools to evaluate the code. Check for code inconsistencies and or incorrect function calls, placements, or other code related issues.

Mr. Smedberg also talked about “using the experts” which correlates to the previous mention of asking questions in this report. Always ask the experts if something is confusing or beyond a beginners understanding. From his talks I gathered Benjamin Smedberg’s opinion of the best thing that is part of Mozilla is the extension infrastructure which is in place.

To finish off I would say many important points were covered by this speaker; especially the reasons for the reading code, the purpose of reviewing and the constant inference on quality of the code. Documentation was yet another major emphasis made by this speaker and in my opinion I believe this is a very important thing for any coder to practice. Documentations is the only link that other have sometimes when people are trying to understand and decipher some other persons code. Nothing that happened in this talk changed my view of open source or what the entire community is all about.

Mike Beltzner’s designing for and with community
I must say I have never attended a speaker’s talk that was filled with so many “weeeeees” and other funny expressions as Mike Beltzner’s talk about designing for and with the open source community. A very intriguing speaker who captivates you with his interest, presentation style and overall funny demeanor; something I think is very attention grabbing for me at the least.

I remember the first and foremost thing Mike talked about, he said designing in open source is not something that is ready for primetime. I must honestly say at first I had my doubts about what he was referring to in that statement; but then it occurred to me; maybe it is the way of how designing and implementing is done in the open source community drawing parallels to cathedral and the bazaar. In today’s world of organization and control the bazaar type of software development is yet to be embraced by the major corporations and companies; and in my foreseeable future at the least I do not see this trend of developing software changing. Maybe this is what Mike was referring to when he said “Designing in open source is not something that is ready for primetime” I could be wrong.

One of the major things Mike talked about was embracing the chaos of open source. There are always many different perspectives out there and many different ideas on how people want to help out. Some might just be condescending while others are generally out to help the new comers feel at home. He then went on to talk about the three main points of designing for and with the open source community. They were as follows:

• Listen to your community (because if you do not do so, they will get alienated by the lack of listening and therefore grow to hate the product)
• Lead your community (setting examples and most importantly standards by which work should be done in is key and very important in this type of open source environment)
• Let the community play and experiment (in order to build a strong community support and gain loyalty the company must allow the community to fully take apart and understand the underlying code base of the software. This will allow for people to experiment with their own knowledge and therefore creating their own extensions or add on that can benefit the rest of the community or in some cases even the original creators of the software).
  

Mike also pointed out a key point that caught my attention; he said thirty seven percent of code that came into Firefox between November 2006 and April 2007 were from outside contributors and not from within the company developers. He also pointed out certain factors that are part of the open source community and people should learn to accept this. They were as follows:

• There are no easy buckets (meaning like every company or organization no one will give you credit right away; credit has to be earned and one has to prove themselves as a worthy contributor)
• Strong leadership structure (major contributors and creators of the code should be strong in their leadership of their community otherwise the community will loose strength and support)
  

Mike seemed to stress a lot on “listening to the community”. He talked about providing multiple well defined channels where people can actually come together, share ideas and contribute their code and feedback to others. But he also bought about another concern that has been around in every community not only the open source community. With this sort of open listening system per se comes the reality of camps. Camps are when people begin to form into groups and most of the times groups of people tend to agree and disagree with other groups of people. Usually these types of camps have a leader who argues their side of the argument against the other leaders of other camps; this often leads to people being one sided in their view or aligning themselves with one camp or side. Also people tend to make offensive or condescending remarks towards others in different camps that are not in agreement with their camp. Mike said the best way to get around this sort of camp propaganda or misinformation is to do the following:

• Educate yourself of the different topics out there that the camps are disagreeing over.
• Find the people who are making the smart comments and read what they have to say instead of listening to anyone and everyone.
  

Another topic Mike touched on which was interesting was how to bring order to chaos. Again drawing parallel to the cathedral and bazaar. Mr. Beltzner said some ways of keep order amidst the chaos is to

• Create small teams, led by strong contributors and give them responsibilities to complete.
• Always offer data to elevate discussions about topics of concern or importance.
• Never treat disagreements as an adversarial notion. Instead look at it as a negotiation to attain the ultimate goal.
• Use an onion layer model for releasing (always get different levels of input from the community and analyze different ways of solving a problem before committing to a release; at least that is what I gathered from the explanation he gave)
  

Mike Beltzner also talked about a very interesting extension which I have not heard about called CoScripter. From my understanding this is an extension that is used to record actions on the web and then share them with other. If my understanding is correct this extension writes script to automate certain web actions in order to make the user experience a quick and efficient once. Also CoScripter displays the actions in readable text format. I maybe wrong in this interpretation but this is such a useful extension to have in my opinion.

Conclusion
After attending these two talks, I can say most of my perceptions and views of open source were unchanged and nothing major really was told or occurred in order to obscure my view of what open source is today. I must say Dave Humphries suggestion on reading the cathedral and the bazaar was quite the best way to start of this course; because it gives a beginner a clear idea of what to expect in this sort of development environment.

When comparing and contrasting the ways the two speakers conducted their talks; there seem to be more similarities than there were differences. Both speakers were clear in touching on the order to chaos points. Both shared a very great enthusiasm for what they were doing and how they were helping the community in doing what they were doing. The only noticeable difference was Mike Beltzner took a very casual and funny approach to his talk where as Benjamin Smedberg took a more formal approach to his talk. Both these speakers are ‘Gurus’ in their own right in what they do; definitely a very worth while experience for me as a beginner.

This FSOSS imposium was a definite eye opener to me; it showed me the type of leaders who are out there striving to keep the open source community up and alive. It also opened me to the many different facets and possibilities there are in this open source community and how these facets and their founding principles can help in the improvement and spreading of technology, learning and knowledge to the under privileged communities of the world we live in.

Contact Info

vbalasun@learn.seneac.on.ca
or
vijeybala@gmail.com

My Blog

my blog