Getting started with Saros Development - A guide for students

This page acts as a guide to get you started with Saros development and list the first steps you should take on your journey into distributed party programming.

First steps

• Read DPPHowToDevel - it tells you much about the developing process
• Download Eclipse and setup Saros for developing
• Create a sourceforge account if you don't already have one
  • get one of the Saros team members to make you an administrator on the Saros project (you need that to do anything with the project)
• Join the Saros mailing lists
  • saros@lists.spline.de (Mostly internal discussions that the public need not know about.)
  • dpp-devel@sourceforge.net (Any development activities that would be of interest to developers in the wider world. ReviewBoard requests and subsequent discussions are posted here.)
• Register with the TWiki at UserRegistration
  • Put email, phone, chat, Skype, room information and a photo on your TWiki homepage (Main.YourName)
  • Add other useful information (such as a link to your thesis topic)
• Ask one of your advisors to add you to the Main.mi_login_saros (in fact any member of the SarosGroup can do this)
• Ask someone from the AGSE crew to give you access to the local SVN server (for storing your thesis and other data)
• Visit the Saros room (K21), talk to the people
  • Get a key to the room from Gesine
  • Login to our XMPP chat server on saros-con.imp.fu-berlin.de (create a new account first; in-band registration is enabled). Each member's XMPP name is available on DPPInternal.
• Decide on which days you will be present (3 minimum, 4 recommended) and enter your details at DPPInternal

Understanding Saros - Learning to love the beast

• Saros is now the product of more than 20 students and thus no longer small. You won't be able to understand all parts in great depth, but you can get a good overall grasp if you spend some time with the code, documentation and your peers.
• First learn about the basics:
  • Saros is a distributed application and uses concurrency in many places. Spend some time refreshing your Java Concurrency knowledge. There are good books in the Saros room.
  • The Saros architecture is built on the Inversion of Control design pattern. In particular we use PicoContainer to maintain the dependencies between components and classes.
    • CodeRules explains some stuff about PicoContainer. We recommend that you read the Pico tutorial
• Have a look at the Saros documentation
  • There is a requirements document which talks about what Saros is supposed to do. https://svn.mi.fu-berlin.de/agse/sci/dpp/requirements/
  • Watch the videos at https://svn.mi.fu-berlin.de/agse/sci/dpp/video/ which talk about the Saros architecture. The audio is bad, but it still should give you a good overview.
  • Look at the theses your predecessors have written at DPPResearch and read the scientific publications about Saros
• Read the code
  • Being able to read code fast and efficiently is a must to understand Saros (and any other large software).
  • Learn how to use Eclipse masterfully and you will browse through the code in no time and quickly understand how things fit together.
    • Learn keyboard shortcuts for code navigation

• Learn from the Pros
  • Nothing can give you more insights about Saros than sitting down with another developer and talking about Saros.
  • Pair Programming and Performing peer reviews together will much speed up your learning

Read up on special topics

• Riad Djemili's and Christoph Jacob's work for how it all started
• Sebastian Ziller's work for how the Jupiter algorithm works (for multiple people writing at the same time) and how undo works in Saros
• Tas Soti's work about the invitation process
• Henning Staib's and Sandor Szuecs's work on the network architecture
• Sandor Szuecs's work on Sandor's Testing Framework if you want to write integration tests for Saros
• Lisa Dohrmann's work if you want to add additional statistics gathering functionality and add surveys for Saros
• Stephan Lau's work if you want to understand how the streaming service in general and the video sharing in particular works
• Olaf Loga's work for the Voice-over-IP module
• Marc Rintsch's work if you want to understand how color assignment, the EditorManager and the ActivitySequencer works
• Eike Starkman's work if you want to convince people to use Saros
• Edna Rosen's work if you want to coach people who use Saros, in particular in international situations
• Stephan Lau's work will tell you about screensharing and streaming.
• Andrea Haferburg's to learn about version control system integration in Saros.
• Michael Jurke's if you want to learn about the distributed whiteboard.
• Lin Chen's thesis to learn about the latest refinements to the Saros GUI-testing framework.
• Scientific Papers (by other people) about Distributed Pair Programming and special topics such as Jupiter are stored in https://svn.mi.fu-berlin.de/agse/sci/dpp/lit/

Important Rules

• Code
  • CodeRules in the Wiki
• Formal stuff for your thesis
  • ThesisRules
• Saros development process
  • All commits are peer reviewed using ReviewBoard
    • be active, review patches, give helpful feedback!
    • remember to sign-off commit messages (see How to contribute code to Saros)
  • There's a release in the last full week of every month with focused testing beforehand
    • You'll act as tester or as release manager, in turns. Every second time, you'll act as lead.
    • Take a look at DPPHowToDevel
    • Make sure that you are available on these days (Tuesday-Friday). You might have to schedule other work for other days during a release week.
  • We really appreciate if you to do outreach after each Saros release:
    • Look at SarosOutreach
    • Example
      • a news page/blog/tweet that brings a lot of traffic and has high turnover
      • a page that has slow turnover but may bring traffic continuously (e.g. Wikipedia, Dmoz)

Attitude Adjustments

• Ownership: Saros is your baby, too. So if you stumble upon any problems, fix them or report them (e.g. to the Bug tracker)
  • If nobody takes responsibility, ask the bosses (Karl+Stephan) to assign responsibility.
• Simple solutions are better
• 50% of a really good solution are more valuable than 100% of a bad one; give priority to the best solution. Bad solutions later create problems that no one likes (like the problem you have been dealing with last week…)
• Communication, communication, communication: respond to requests, claim responsibility (and act responsibly), always acknowledge tasks.
• If you don't know what to do about a piece of code (Exception handling, etc.): Ask! Don't just ignore it.
• We are a team. We use rules to help us do good work. We can change rules if we think that's helpful (after discussion in the team!).
• You help others, they help you.