Posts for the month of January 2009

ITERATION_03 Summary

With the conclusion of ITERATION_03 comes our usual summary as to what has been done. At a first glance, the results of our work might not appear as especially impressive. However, the number of successfully completed tasks is much higher than in previous sprints.

The server team finished all of their coding tasks including one from ITERATION_04. As a result we now have a functional Hudson build server (www.sophie2.org:8080) and operational Sophie2 testing server (www.sophie2.org/s2s). Our other Sophie project teams have also done a good job and we now have Sophie 2.0 Author deployed via JWS.

On 15 December we launched our first release, which is now available at http://sophie2.org/trac/wiki/Download. We are now looking forward to our second release, which is planned for February 13.

The list below summarizes ITERATION_03:

What went well:

  • The arrival of additional hardware and software for the expanded team
  • The Server team completed all of its tasks
  • The overall team was successfully organized into separate groups with specific tasks
  • Progress checks proved useful
  • More discussions took place
  • The utilization of additional facilities for the team
  • The successful integration of new team members
  • The addition of some outstanding new members with a "global" vision of the product

What could be better:

  • Discipline and respecting the process
  • Even better organization
  • A higher percentage of completed tasks
  • Even higher productivity

After discussions in which all team members participated, we decided that we need to work in several directions in order to implement improvements:

  • Improve self discipline - we must respect the process and follow the established rules strictly (commit daily reports, use internal backlogs, etc.)
  • Better coordination between the teams - all team leaders need to improve their communication with their team members and other teams
  • Circulation of ideas concerning improvement - all team members have been encouraged to propose different ways for improving productivity (the proposals may concern all aspects of our work process)
  • Work towards the overall goal - we need to have an even better overall view of the project and its future
  • Team leaders to do daily reviews - this is one of the ways to improve the team communication and improve discipline

Best regards from the Sophie team!

Design problems, general descussion, hints etc.

20.01.2009

start: 14:50

pro_lib = - designed to help people! If they are not helping, either something should be fixed or people do not understand how to use it.

  • attibute - self responsible.
  • do not care about initializing order.
  • good practices:
    • defaulty constructors.
    • avoid final properties.
    • push updates - instead of updating things manually, provide these things the ability to auto-update.
    • avoid trying to use unconventionally the pro_lib since this is error prone.
  • Property improper use cases:
    • accessing an AutoProperty WILL NOT invoke its compute() method!
    • resource properties:
      • create method should depend on NOTHING => it is invoked once and will not update things.
      • setup methods are designed to keep things synchronized for people. @Setup may be put to split setup things in different methods, so that they are updated in groups.
      • destroy methods are not working.
  • List properties.

core_modularity

  • extensions are now sortable by comparator.

base_visual

layout

  • this is a new module to split the layout and menus from the main.view things.

base_skins

  • provides things to simplify things that are registered for a single skin => currently a map with (id, value) entries.

global things

  • few people have a global vision about things.
    • people should get a better overall idea.
  • supercool model.
    • not only implement a great library but find a task to actually use it and also do that task.
      • this will improve the library.
      • things that are error prone will appear.
  • the "not my task/class" problem (people tend to do only things that are tracked and planned):
    • the code is owned by everyone!
    • fix things that need to fixed in order to implement you things, otherwise the next revision of the task will fail.
    • if the things are complicated to be fixed, ask the others, make discussions about it.

end: 16:05

  • Posted: 2009-01-20 16:32 (Updated: 2009-01-20 16:32)
  • Author: peko
  • Categories: (none)
  • Comments (0)