Last Friday, Eclipse 3.3 (code name Europa) was released. As an enthusiast for Eclipse Framework, i cannot wait take a first taste. From my point of view, the most attractive feature, besides other numerous improvements, is the integration of Mylyn, a task focus tool. Some opinions are to be given in the rest of this review, which are NOT intended as an tutorial of this tool. Anyone searching for a tutorial can see [1, 2]. A few high level characteristics of Mylyn are going to be discussed, together with some thinking why it is beneficial.
Mylyn in 3 Aspects
Mylyn is currently described as "task focused UI" officially [4]. However, it is much more than UI. Benefits provided by the tool can be categorized into three aspects:
Task-focus UI Overlay
A task is something like a bug or feature requirement, which is usually the unit of work programmers face with everyday. The motivation of task-focus is to easy programmers out of so-called information overloading, which is the case when lots of time is spent solely on navigating and searching for relevant elements(e.g., packages, classes, aspects, or methods) due to numerous projects in workspace or large enterprise projects. The idea of task focus, inspired by Aspect Oriented Methodology [5], tries to separate out elements (concerns of tasks) , which are usually scattered throughout project(s), into units of tasks. Furthermore, the seamless integration with Eclipse GUI makes Mylyn an undoubted success. The use of Mylyn can be pervasive in Europa. You can find it in, just to name a few, package browser, java editor, synchronizing view, context menu, and etc. All the visual elements have an overlay of task-focus, which mainly does filtering and folding, leaving only elements relevant with current activated task.
Adaptive Relevance Discovery
The UI overlay works all fine, in presence of task relevance data that maintains all elements relevant with each task. Then, where does such information come from? Mylyn employs a quite smart way: all user interactions are intercepted and recorded. Thus when a task is activated, the knowledge of relevance can be learned gradually. Intuitively, the relevance can be measured simply by counting the references(selecting and editing), while decaying old statistics over time. In fact, Mylyn adopted a tree-structured degree-of-interest model [5]. Since the knowledge of relevance learned by recording programmer activity, is valuable as domain expertise. For example, if someone has to work with legacy issues originally handled by others,
it would be just too nice to have the relevance data available. That is what Mylyn does: relevance data (called context of task) can be stored and shared via issue tracking systems (see the next section). We call this type of explicit management of domain expertise expertise as asset. It is especially valuable for teamworks (e.g., community driven projects), in which knowledge transfer is expensive.
Tracking Repository Integration
It is always good to stand on the shoulder of giants. Bug/Issue tracking systems are necessary components of most of the open-source projects today. Mylyn is finely integrated with systems such as Bugzilla, Trac, and JIRA. It provides nice GUI based ticket tracking repository access from IDE. Operations such as query, task submission, automatic notification and offline editing are supported. According to our experience, integration with IDE not only speed up productivity, but also encourages use of tracking system in internal projects ( no requirement for public ticket submission). As we stated earlier, Mylyn stores the context (relevance data) in Bugzilla, and allows patches for contexts. Therefore, expertise is not only shared but also co-worked on.
Lessons Learned
Separate Concerns: it is our old friend. From procedures to classes, from scattered crosscutting codes to aspects, we are always employing the divide-and-conquer again and again. Although algorithmically divide-and-conquer does not always lead to better solution, it is almost always good to decompose problems to reasonable sub-tasks in software engineering.
Expertise as Asset: reuse is really a main issue in improving productivity and reproductivity of a business. For code reuse we have components/libraries; for design reuse we have Model Driven Architecture (model as asset) ; now we have expertise reuse, not for automation but for knowledge transfer or documentation. Code communicates, but easier form of communication is even better.
Integration Is Good: interoperability between softwares or data repositories is long asking for a solution. The result of successful interoperability usually turns out to be integration. Data Warehouse, Enterprise Application Integration, Service Oriented Architecture can all be deemed as replies to answer such requirements.
Conclusion
I get excited over the appearance of task-focused UI and believe it will eventually become standard for IDE's to acquire such functionalities.
References
[1] Mik Kersten Task-focused programming with Mylar. Available at http://www-128.ibm.com/developerworks/java/library/j-mylar1/
[2] Mylyn User Guide. Available at http://wiki.eclipse.org/index.php/Mylyn_User_Guide
[3] Mik Kersten, Rob Elves and Gail Murphy. WYSIWYN: Using Task Focus to Ease Collaboration. CSCW Workshop, 2006.
[4] Mylyn Project. http://www.eclipse.org/mylyn/index.php
[5] Mik Kersten and Gail Murphy. Mylar: a degree-of-interest model for IDEs. Aspect Oriented Software Development, 2005.
No comments:
Post a Comment