From Java CoG Kit

Contents 1 Abstract: Summer Roadmap 2 Team Work 2.1 Weekly Reports 2.2 Tasks 2.3 Terminology: Project, mini project and task 2.4 Terminology: Completed 3 Assigned Miniprojects 4 Random final notes not yet integrated into the above document

Abstract: Summer Roadmap

This document is here to assist in the many activities that go on over the summer and to let everyone know some of the tasks that I expect we will be doing. I hope to update this document so we can use it as an introduction to what needs to be done to make this summer activity more productive.

Team Work

It is sometimes not important that you understand what the other team members do, but in some cases it is essential. It is also essential that we do not replicate code, but instead reduce the code in case we detect overlap. Reusing each others code will have the effect that a) the overall code becomes smaller, b) we harden the code that is already available.

In order to work in a Team it is important to use some tools for communication. The tools we will be using are:

• wiki http://wiki.cogkit.org
• sourceforge http://…
• instant messanger or a like
• subversion

If you are not familiar with any of these technologies, you must make yourself familiar with it.

Weekly Reports

In addition you are ‘’’required’’’ to keep a weekly log about your activities in order not only to let other team members know what you have done and potentially indicate where you are stuck, but also to assist yourself in organizing your work. As we in general like to achieve a goal, the weekly reports help assisting you if we have achieved the goal and in case we have not allow us to see if others could help. The weekly reports are short and should be done in less than ten minutes. If it takes you a day to write one, you do something wrong.

• What have I done this week?
• What did I not achieve this week?
• What do I want to achieve next week?

The Weekly reports are to be maintained in reverse chronological order.

‘’Look for examples of others on the Wiki’’ </blockqoute> Now you would think that an excellent team member would get all its tasks assigned for the week done. Wrong. This is only rarely the case. In fact if you get all tasks done and run out of tasks it shows one of the following a) the assigned tasks were too easy for you b) there are too few tasks assigned to you c) you have not put energy into finding new tasks either while helping others or by asking Gregor, Mike, or Deepti. <bockquote> ‘’For those of you that will get evaluated the weekly reports will be part of the evaluation in a category “professionalism at work”. If you fail a weekly report your professionalism ranking will go down. If you can do all tasks assigned to you and you do not ask for more work, your professionalism ranking will o down, …. And so forth, apply common sense.’’

Tasks

In addition I like that you use the <task> </task> list feature to organize your tasks. This has the advantage that others can see what you do.

An example would be

= Task: Implement a qstat parser for PBS =
<tasks>
[ ] qstat pbs: implement a qstat parser that reads in the information from a pbs qstat command (Gregor)
[ ] qstat pbs: update the documentation on the Wiki or create one (Gregor)
[ ] qstat pbs:complete the Java Doc (Gregor)
[ ] qstat pbs:design meaningful junit cases (Gregor)
[ ] qstat pbs:check in the code (Gregor)
</tasks>

The tasks can be seen in a summary document, but you can query also your own tasks. Tasks can be included in any document on the Wiki. Links to them can be found at: ???

If your name is not here, please make sure to update the page. Also if a task is assigned for a team such as GATEAM, the team has to assign the task to a person. This way it is made sure that the task is done. Once a task is assigned to a person it does not necessarily mean that he or she is the only one working on it, However, unfortunately I believe that the current Wiki does not allow to assign tasks to more than one. Hence we will use for now the convention that one person is assigned to a task.

Terminology: Project, mini project and task

The word task and project in our project has in the past meant different things to different people, so we need to clarify what we mean:

a) A task is a small peace of work that has a number of subtasks to be completed b) A miniproject contains multiple tasks.

   a) A Project contains multiple miniprojects to complete the task. 

Terminology: Completed

In the past I had some problems with team members that did not understand when a project or miniproject was completed. It is not sufficient to just develop the code and to include that peace of code undocumented into SVN. Instead you must make sure that

a) the code is completed and checked in. b) the documentation is completed c) it has been verified that the code works not only for you but others. d) It must be made sure that the documentation can be understood by others (at least one more person). e) code and documentation are spellchecked (I am pretty bad in that myself.)

In addition you should follow code format guidelines as given in the maven trunk. E.g. 2 space indentation, no tabs, all Javadoc defined.

‘’The worst scenario would be you would work on a peace of code and its not documented, but for some reason you would not have time to complete it. This means for those that get evaluated you loose professionalism points.’’

Assigned Miniprojects

Here the current lit of people and their likely miniprojects they will work on in the next weeks.

Full time:

• Mike (expert in lots of things, workflow)

1. make water application work on teragrid with karajan
2. VDL2

• Deepti (expert in Databases and chemistry application)

1. Karajan Workflow repository and panel (together with Mike)
2. CMCS
3. I2U2

• Gregor (trying to coordinate things)

Masters thesis:

Guru: The title may be something like this: Deployment of Grid software with application to MPIAB

1. sysinfo and sysstat for linux and cygwin / windows without cygwin,

  caching of attributes in memory

Summer REU students (Matt and Chris):

1. fix many little bugs in Cog, and some bigger once. JavaCoG Kit REU
2. use Java reflection to create karajan workflow programs from "well formed" Java classes. (see code in Maven repository, this could be done by Mike in a matter of a couple of hours.).
3. transform CoG Kit from Ant to Maven component by component for a selected number of modules
4. create a number of different jar files with different focus: example: one could include Guis the other one could include only the workflow stuff (low priority)

First task will be to fix the grid ftp . and .. problem

GATEAM: Kamal Ashish Amandeep Nimish

1. Karajan Workflow almanac
2. JobCal and RSS feed (alternatively this could be done by Chris once the ftp component works)
3. qstat parsers for cobalt, pbs, lsf, and sge (this could be done by matt once the ftp bug is done)
4. depends on how the group performs (the better, the more interesting the tasks)

Deepak:

1. Revisit with Gregor the project assignment next week Starting on June 5th

Vignesh:

1. implementing a secure Grid execution service for windows with clients for Linux and Windows.

Random final notes not yet integrated into the above document

As you can see there are many tasks to be done. So there is no shortage of opportunities to participate in something. Once you run out of work, you may want to definitely check back with me, Mike and Deepti, so we can coordinate the next task to be done.

During the first quarter we will have an evaluation of the performance of each team member to give you feedback on what to emphasize next. This means essentially after three weeks you must have something that I can evaluate.

Criteria of evaluation are based on a statement that you will honestly delver to me.

• a) Have you understood your project assignment?
• b) Have you completed a small task to 100%, if so, put pointers to the SVN and the ocumentation that you have written. In case you co-wrote it indicate the other persons name.
• c) Have you enhanced your mission. E.g. did you help others or did your implementation extends the original mission (was this discussed with Gregor, Mike, or Deepti?)
• d) Have I conducted proper engineering practices in regards to plagiarism and code copying?
• e) What other things should be known to Gregor that can help assess my performance.
• f) What weaknesses did you discover in yourself that need to be addressed to work more efficiently?
• g) How many hours did you spend per day in average on the project?
• h) How many hours did you spend on learning technologies?
• ....

From my experience these are not difficult questions to answer and if it takes you more than an hour to answer these questions, I am sure you do something wrong. The availability of this self evaluation will help you to discover shortcomings by yourself. In many cases you will find. If you feel uneasy about something I am sure I feel the same.

As we work in such a large team distributed code management in the svn is a must. In my previous mail I stated you must learn how to use svn. I also recommend that you use eclipse for java programming as it comes with some nice features. One word of warning. subclipse has a couple of bugs. One of which is related to renaming, deleting and refactoring filenames. So if you do so, do it with care. Other things that do not work for me is the GUI design tool from IBM, but than I am working on a Mac and that may be the problem.

Also make sure that no one works in parallel on your peace of code. In general make sure you program compiles and runs before you commit it. However there are exceptions when we try to merge a peace of code written by different people. learn what update and commit does. learn how to deal with conflicts. Use messaging tools such as IM to communicate with others in case of a problem.

At this time I am using the trunk/maven directory and make notes in it for some iof the things that need to be developed.

With this I like to check out for the day and hope you enjoy the summer with us. I am looking forward for your valuable contributions.

Thanks

Gregor</pre>