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 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.
- 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 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.