Difference between revisions of "User:Rueen"
(→Open Communities in Own Project) |
|||
| Line 113: | Line 113: | ||
===== Open Communities in Own Project ===== | ===== Open Communities in Own Project ===== | ||
Since my own project involves working with an existing localization community I knew that Mike's presentation would give me more insight into how to work with them. The community in my own project is relatively large and is being led by a few Mozilla employees. They have been leading us with structure and organization by providing us with scripts, tools, contacts and possible approaches to reaching our main goals and objectives. In addition, we have also been following Mike's first maxim, listen to your community, by adding and removing features according to what we believe the community would want as well as their direct input through tools such as Bugzilla. Throughout the development of our project, we tried to keep our tool simple and not overly complex to use. We knew that if we made a complex tool, the community would simply reject it and the project would not progress any further in the future. With the help of Mozilla's Axel Hecht and Michal Berman (deeply involved in localization) and support from our professors Dave Humphrey and Chris Tyler - who have helped us considerably by providing us with strong guidance and contacts - we have been able to get our project off the ground and have built the foundation for a tool that the community can put to good use in the near future. We have also had a small taste of the some negative things from the open community. To put it briefly, our project is somewhat dependent on scripts and tools already built by Mozilla's localization team as well as the surrounding community. Axel Hecht had recommended that we use a particular script to help with a specific aspect in our system. For nearly a month and a half we tried to get in contact with the script's owner for information regarding the Python script. We finally got in touch - through Bugzilla - and are in the process of incorporating their tools with our new tool as recommended by Mozilla's localization team. | Since my own project involves working with an existing localization community I knew that Mike's presentation would give me more insight into how to work with them. The community in my own project is relatively large and is being led by a few Mozilla employees. They have been leading us with structure and organization by providing us with scripts, tools, contacts and possible approaches to reaching our main goals and objectives. In addition, we have also been following Mike's first maxim, listen to your community, by adding and removing features according to what we believe the community would want as well as their direct input through tools such as Bugzilla. Throughout the development of our project, we tried to keep our tool simple and not overly complex to use. We knew that if we made a complex tool, the community would simply reject it and the project would not progress any further in the future. With the help of Mozilla's Axel Hecht and Michal Berman (deeply involved in localization) and support from our professors Dave Humphrey and Chris Tyler - who have helped us considerably by providing us with strong guidance and contacts - we have been able to get our project off the ground and have built the foundation for a tool that the community can put to good use in the near future. We have also had a small taste of the some negative things from the open community. To put it briefly, our project is somewhat dependent on scripts and tools already built by Mozilla's localization team as well as the surrounding community. Axel Hecht had recommended that we use a particular script to help with a specific aspect in our system. For nearly a month and a half we tried to get in contact with the script's owner for information regarding the Python script. We finally got in touch - through Bugzilla - and are in the process of incorporating their tools with our new tool as recommended by Mozilla's localization team. | ||
| − | |||
| − | |||
| − | |||
=== Views on Open Source === | === Views on Open Source === | ||
Both speakers primarily talked about open communities and how leading them can result in greater benefits for open source projects or existing open source products. Although both talks were about different topics, they had similarities when it came to how to manage and maintain an open community. | Both speakers primarily talked about open communities and how leading them can result in greater benefits for open source projects or existing open source products. Although both talks were about different topics, they had similarities when it came to how to manage and maintain an open community. | ||
Revision as of 16:40, 2 November 2007
Contents
Profile
In the Bachelor of Software Development (BSD) program. Favorite Language: Java.
Name: Rueen Fiez
Email: rfiez-mo@learn.senecac.on.ca
Blog: Open Source blog
Projects/Assignments
- Automated Localization Build Tool - we are in currently working on our 0.2 release and are anticipating completion of the release by the end of october. We plan to start the 0.3 release in November.
Automated Localization Build Tool (0.1 Release)
- Software Requirements: Python --> Get it from Python's download page
- Download the 0.1 release here (contains Python scripts and supporting DTD & Properties files).
- System's instructions. Basically, once you have Python installed, double click on the l10nMerge.py script and check the corresponding DTD and Properties files for the changes to the "color" string (which should now be called "colour")
- For more information, check out my blog about the 0.1 release.
Modifying Firefox Lab
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 21:26:23 -0000
@@ -1073,32 +1073,41 @@
<parameter name="aURI"/>
<parameter name="aReferrerURI"/>
<parameter name="aCharset"/>
<parameter name="aPostData"/>
<parameter name="aLoadInBackground"/>
<parameter name="aAllowThirdPartyFixup"/>
<body>
<![CDATA[
+
+
+
+
+
+
var bgLoad = (aLoadInBackground != null) ? aLoadInBackground :
this.mPrefs.getBoolPref("browser.tabs.loadInBackground");
var owner = bgLoad ? null : this.selectedTab;
var tab = this.addTab(aURI, aReferrerURI, aCharset, aPostData, owner,
aAllowThirdPartyFixup);
// Set newly selected tab after quick timeout, otherwise hideous focus problems
// can occur when "browser.tabs.loadInBackground" is false and presshell is not ready
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,19 +1182,24 @@
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);
-
- if (document.defaultView
+
+
+ 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 */
this.mTabContainer.mTabstrip.scrollBoxObject
FSOSS 2007 Report (DPS909)
Introduction
The main purpose of this report is to provide a concise summary of two presentations given at this year's Free Software and Open Source Symposium (FSOSS) as well as highlighting the speaker's view about open source and the surrounding communities in general. In addition, I'll be providing my own views about open source, it's supporting communities, and what I was able to take away from the presentations given at this year's FSOSS. This being my first FSOSS event, I was naturally overwhelmed and somewhat intimidated by all the “big-shots” in the world of open source. I went into this event with one goal in mind - to gain a better understanding of free software and open source and be able to apply what I learned when working on my own open source related projects.
Summary
I chose to attend the following two presentations because I felt – based on their brief description in the agenda page – that they would provide me with knowledge that I could put to use throughout the development of my own open source project. My own project in particular entails much code reading, code reuse, and is supported by a relatively large Firefox localization community. After much consideration, I knew that the following two presentations, as well as their respective speakers, would best complement my existing knowledge about code reading, code reuse, and developing for communities – while adding an open source “spin” on them.
Code Reading and Review
Benjamin Smedberg's presentation outlined the reasons for reading code, difficulties encountered when reading code, code reading in a broader sense, and the different types of code review. He mentioned the various reasons why people read code which included – apart from it being an entertaining activity for “geeks” as he put it – fixing a bug, adding features, writing documentation, or just learning how a system works. Benjamin got down to the point and flat out said that code reading is hard especially when it comes to more complex systems. However, he emphasized that code in an open source context is not an individual activity and is in fact a social one. Code reading requires the participation of the code's author as well as the experts who contribute, maintain, or use the code extensively. The only exception to this rule would be if the system has no documentation, is relatively new, and the author of the code cannot be reached. The presentation also dived deeper into how to fix bugs by looking for common bad patterns such as “off-by-one” or “unsigned/signed mismatches”. I appreciated the advice he gave about mixing software frameworks together. Benjamin cautioned us that mixing frameworks, especially in JavaScript in particular, can lead to pitfalls in design and quality. In addition, Benjamin stressed that you do not have to understand the entire code, but only understand the part of the code that concerns to your end objective(s).
Background & Point of View (B.Smedberg)
Platform Guru is the official title given to Benjamin Smedberg which came as a surprise to me since I've never heard of such a thing and it seems quite unconventional. Although I shouldn't be surprised, I've been told that Mozilla is a unique corporation in many ways – which adds to its appeal. Benjamin's views on open source and its communities shouldn't be hard to guess, he emphasizes that open source as it relates to code reading and reviewing should be a collaborative endeavor. Not simply a lone coder sitting in a dark room straining his eyes over code they don't even understand – as Benjamin put it.
Thoughts About Code Reading and Reviewing in General
Based on what I have seen about open source so far, I believe that code reading is one of the most important skills a developer should be proficient at when working with the open source community. A developer who is able to read code and adapt it for their own purposes regardless of its complexity is able to employ a more versatile array of tools for each iteration. Code review has many benefits and applications, but personally, I perceive it as a skill necessary to deliver quality software to the community.
Product & User Experience Design in Open Communities
Mike Beltzner's presentation was focused on products and the user's experience with those products in an open community context. He essentially summed it up with his three “maxims”. The first being listening to your community which is basically focusing on what the community wants or needs. His second maxim was leading your community which is essentially to provide organization and structure to direct contributions from the community. Utilizing small focused teams is another approach to leading your community. Mike's final maxim is to allow the community to play and experiment with the product. Community feedback is extremely useful to ensure a higher quality of software. He also pointed out how Microsoft was making an effort to gather user's experience with their products by highlighting the “Happy face” and “Frown face” icons that appear in the task bar. Mike's presentation was filled useful information about relatively new software such as CoScripter and TheCoop. His presentation successfully influence me enough to give these products a run and see what the hype is about. I'm happy to say that I found the experience very enlightening.
Open Communities in Own Project
Since my own project involves working with an existing localization community I knew that Mike's presentation would give me more insight into how to work with them. The community in my own project is relatively large and is being led by a few Mozilla employees. They have been leading us with structure and organization by providing us with scripts, tools, contacts and possible approaches to reaching our main goals and objectives. In addition, we have also been following Mike's first maxim, listen to your community, by adding and removing features according to what we believe the community would want as well as their direct input through tools such as Bugzilla. Throughout the development of our project, we tried to keep our tool simple and not overly complex to use. We knew that if we made a complex tool, the community would simply reject it and the project would not progress any further in the future. With the help of Mozilla's Axel Hecht and Michal Berman (deeply involved in localization) and support from our professors Dave Humphrey and Chris Tyler - who have helped us considerably by providing us with strong guidance and contacts - we have been able to get our project off the ground and have built the foundation for a tool that the community can put to good use in the near future. We have also had a small taste of the some negative things from the open community. To put it briefly, our project is somewhat dependent on scripts and tools already built by Mozilla's localization team as well as the surrounding community. Axel Hecht had recommended that we use a particular script to help with a specific aspect in our system. For nearly a month and a half we tried to get in contact with the script's owner for information regarding the Python script. We finally got in touch - through Bugzilla - and are in the process of incorporating their tools with our new tool as recommended by Mozilla's localization team.
Views on Open Source
Both speakers primarily talked about open communities and how leading them can result in greater benefits for open source projects or existing open source products. Although both talks were about different topics, they had similarities when it came to how to manage and maintain an open community.
Open Source Views From Code Reading and Review
Developers must take into account that when they are writing their code, they should be writing it in a way that will make it simple for another developer to come in an read it and understand it in some ways. They can do this through documentation or other means to communicate the code and design decisions that were made throughout development. By making code easy to read, the authors can take advantage of the vast community that accompanies most open source projects by helping potential developers understand the code so they can attempt to contribute to it in some way. Also, its important for open communities to be able to read the code because most projects will have bugs. Often, the community is the one that will find these bugs and rectify them through patches. Developers must make an effort to make their code easy to read so communities can review the code without stopping at every class or method and asking “why do we need this?”. Open source communities also have a tendency to reuse existing code – something that I'm beginning to understand a great deal about. When you write code, there is always a possibility that your code may be used and adapted to someone else project. Proper documentation can make this adaption easier for the developer and increased the quality of the product.
Open Source Views From Product & User Experience Design
Mike Beltzner views the open source community like an unorganized and chaotic group of developers and enthusiasts who all want the product to add a new feature or remedy some bug. He sees the leadership's goal, Mozilla in this case, as turning this unorganized chaos into an organized chorus. He believes that as a result of turning chaos into a chorus, the product will benefit from it in the end. Mike is a strong believer in getting feedback from the community and allowing the community to express their ideas about a particular product. He believes that open source projects and existing open source products should have a streamlined way of getting community feedback, reporting bugs, and learning about the product in general. A good way of leading your community is to identify those who are making “smart” comments about a product then give them positive feedback so that they are more likely to contribute to the product in the future.
Comparison
Although Mike Beltzner and Benjamin Smedberg's presentations differed in terms of focus, they did however have one thing in common – how the open source community can impact a product. Benjamin's presentation focused more on how communities can fix bugs or add features to a product whereas Mike's presentation focused more on how to organize and maintain communities and harness their potential power to elevate products to a higher level of quality. Both speakers also centered their presentation around how communities should be led. Benjamin spoke about how code that is easily read can be reviewed more efficiently for potential contributors whereas Mike discussed how structure and organization can help lead communities. The only differences between the presentations was that Benjamin went more in depth into why code review by the community is beneficial and Mike talked more about creating a streamlined method of gathering user experience data and use that data to increase a product's quality.
Personal Views on Open Source & FSOSS
This being my first FSOSS, I did not have a clue the impact the speakers were going to have on me or even how much of the material presented I would actually put to practical use later on. Afterwards, I'd realized just how much FSOSS had impacted the way I perceive open source projects. In particular, Mike Beltzner's presentation was very informative and illustrated many useful systems I had no idea about such as CoScripter, TheCoop. He also reminded me of some others I'd forgotten about such as Miro, digg, Flickr, and many more.
Post-FSOSS Impact on Own Open Source Project(s)
After reflecting about what I learned during the FSOSS event, I was able to approach my own open source project from a whole new perspective. Looking through the myriad of localization tools – which is essentially a collection of Python scripts, XML files, DTD files, and Properties files – I was no longer intimidated when reading through its many classes and methods. As a result of Benjamin Smedberg's presentation on code reading and review, I knew that to understand everything about the code is not necessary, and that I only need to understand specific parts of someone else's code and use them accordingly. Also, as a result of Mike Beltzner's presentation about open communities, I always kept in mind how the Firefox localization community would react to the design and programming decisions I make throughout the development of the project. Mike's emphasis on open communities made me realize how much I can help potential project contributors by highly documenting every part of my project. Everything from documentation in code, references to locations where code was reused, documentation related to product design, community contacts, and step-by-step processes. Not that I hadn't already documented, but Mike's presentation gave me incentives to document the project as much as I could for the sake of the community. I knew by keeping the community in mind during the course of development, potential contributors would avoid common pitfalls when trying to read or reuse the code.
Recommendation
My first FSOSS experience was a positive one, filled with a lot of colorful and knowledgeable speakers. I was able to take away a lot of information from the presentations and successfully apply what I've learned to my own open source projects. I would definitely recommend going to next year's Free Software and Open Source Symposium to anyone – not just software developers – who even has a passing interest in open source applications, or is affected by the open source community in some way. It is a great way to meet the leaders in the community and learn new ways of approaching projects.
Other
External Links
