You are here: Wiki>SE Web>SarosDevGettingStarted (05 May 2017, FranzZieris)Edit
Attention: This page's content is out of date. It is still kept because its mission may deserve a revival.

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
  • 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 SarosGroup (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 SE.DPPInternal.
  • Decide on which days you will be present (3 minimum, 4 recommended) and enter your details at SE.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.
  • Have a look at the Saros documentation
  • 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

Important Rules

  • Code
  • Formal stuff for your thesis
  • Saros development process
    • All commits are peer reviewed using ReviewBoard
    • 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 SE.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 SEi.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.
Topic revision: r14 - 05 May 2017, FranzZieris
 
  • Printable version of this topic (p) Printable version of this topic (p)