Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "RT Shared Editing"
(first initial fleshing out - this is a very big work-in-progress) |
|||
| Line 1: | Line 1: | ||
| + | <!-- Introduction --> | ||
'''Project Lead''': Mustafa Isik | '''Project Lead''': Mustafa Isik | ||
'''Mentor(s)''': Scott Lewis, Ken Gilmer | '''Mentor(s)''': Scott Lewis, Ken Gilmer | ||
| − | * Meeting Notes | + | ==Motivation== |
| − | + | The ''RT Shared Editor'', which I'll dub ''Cola'' ('''col'''l'''a'''borate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE. | |
| + | |||
| + | The term ''pair programming'' describes an activity in which two developers simultaneously work on a single development machine. | ||
| + | |||
| + | Even though not new to the development community, ''pair programming'' has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of [http://www.extremeprogramming.org/ eXtreme programming (aka ''XP'')] practices. Thus ''pair programming'' is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the ''XP'' methodology. | ||
| + | |||
| + | The reasoning behind ''pair programming'', as articulated by software developer, author and ''XP'' figurehead [[RT Shared Editing#Resources|Kent Beck (2005 p.42)]] is manifold and pair programmer's acivities are described as | ||
| + | *keep each other focused and on task | ||
| + | *brainstorm refinements to the system | ||
| + | *clarify ideas | ||
| + | *take initiative when their partner is stuck, lowering frustration | ||
| + | *hold each other accountable to the team's practices | ||
| + | |||
| + | From my own experience I can add, that programming in pairs has proved to beneficial in | ||
| + | *widening developers' horizon and perspectives on perceiving and tackling problems | ||
| + | *increasing trust in one's own skills and generating awareness for areas requiring improvement | ||
| + | *learning from more advanced developers | ||
| + | **improving through working with less experienced devs, motivating to reflect on the essence of one's own practices | ||
| + | *refining one's own communication skills | ||
| + | |||
| + | ===Current Situation=== | ||
| + | Tool-support for ''XP'' in [http://www.eclipse.org Eclipse] is pretty much non-existent. | ||
| + | ===Limitations & Problems=== | ||
| + | Geographical limitations: open-source community, distributed teams and offices | ||
| + | Even when developers are located at the same work site, the effort to get two people set up together in front of a computer proves not to be worth for a quick ten minute programming task, which sometimes is all that is required. | ||
| + | |||
| + | There are inhibition thresholds which keep individuals from pair programming. | ||
| + | |||
| + | ===Resolution=== | ||
| + | Support collaborative work on code from disparate locations, minimizing organizational impact. | ||
| + | ==Tasks== | ||
| + | Concerning the development of the shared editor | ||
| + | ===Consistency Maintenance=== | ||
| + | ====Challenges==== | ||
| + | *divergence | ||
| + | *causality-violation | ||
| + | *intention-violation | ||
| + | ====Algorithms==== | ||
| + | Approaches: | ||
| + | *GROVE | ||
| + | *REDUCE | ||
| + | *JUPITER | ||
| + | Even though a single algorithm will eventually be implemented to ensure consistency in the shared document among | ||
| + | ===Protocol Review=== | ||
| + | ===Integration into Eclipse Communication Framework=== | ||
| + | ==Resources== | ||
| + | ===Meeting Notes=== | ||
| + | *[[Monday May 29, 2006]] | ||
| + | ===Papers & Books=== | ||
| + | *Beck, K 2005, ''Extreme Programming Explained - Embrace Change'', 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42 | ||
| + | *Sun, C & Ellis, C 1998, [http://citeseer.ist.psu.edu/sun98operational.html ''Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements''], Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68 | ||
| + | *Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, [http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=215706 ''High-Latency, low-bandwidth windowing in the Jupiter collaboration system''], Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120 | ||
Revision as of 16:05, 2 June 2006
Project Lead: Mustafa Isik
Mentor(s): Scott Lewis, Ken Gilmer
Contents
Motivation
The RT Shared Editor, which I'll dub Cola (collaborate) for now, is supposed to be a tool enabling developers to reap the benefits of pair programming within the Eclipse IDE.
The term pair programming describes an activity in which two developers simultaneously work on a single development machine.
Even though not new to the development community, pair programming has witnessed a significant rise in adoption over the last years. One of the main reasons being the inclusion to the set of eXtreme programming (aka XP) practices. Thus pair programming is especially, but certainly not only, popular among developers utilizing the values, principles and practices propagated by the XP methodology.
The reasoning behind pair programming, as articulated by software developer, author and XP figurehead Kent Beck (2005 p.42) is manifold and pair programmer's acivities are described as
- keep each other focused and on task
- brainstorm refinements to the system
- clarify ideas
- take initiative when their partner is stuck, lowering frustration
- hold each other accountable to the team's practices
From my own experience I can add, that programming in pairs has proved to beneficial in
- widening developers' horizon and perspectives on perceiving and tackling problems
- increasing trust in one's own skills and generating awareness for areas requiring improvement
- learning from more advanced developers
- improving through working with less experienced devs, motivating to reflect on the essence of one's own practices
- refining one's own communication skills
Current Situation
Tool-support for XP in Eclipse is pretty much non-existent.
Limitations & Problems
Geographical limitations: open-source community, distributed teams and offices Even when developers are located at the same work site, the effort to get two people set up together in front of a computer proves not to be worth for a quick ten minute programming task, which sometimes is all that is required.
There are inhibition thresholds which keep individuals from pair programming.
Resolution
Support collaborative work on code from disparate locations, minimizing organizational impact.
Tasks
Concerning the development of the shared editor
Consistency Maintenance
Challenges
- divergence
- causality-violation
- intention-violation
Algorithms
Approaches:
- GROVE
- REDUCE
- JUPITER
Even though a single algorithm will eventually be implemented to ensure consistency in the shared document among
Protocol Review
Integration into Eclipse Communication Framework
Resources
Meeting Notes
Papers & Books
- Beck, K 2005, Extreme Programming Explained - Embrace Change, 2nd Ed., Addison-Wesley, Boston MA (USA), p. 42
- Sun, C & Ellis, C 1998, Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements, Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Seattle WA (USA), pp. 59-68
- Nichols, D, Curtis, P, Dixon, M & Lamping, J 1995, High-Latency, low-bandwidth windowing in the Jupiter collaboration system, Proceedings of the 8th annual ACM symposium on User interface and software technology, Pittsburgh PA (USA), pp. 111-120