programminglife2017 / dynamiteandbutterflies Goto Github PK

In order to display the graph properly an ordering based on layers has to be made. This will improve the readability of the graph
13.3 Explains the concepts
https://cs.brown.edu/~rt/gdhandbook/chapters/hierarchical.pdf
http://chianti.ucsd.edu/svn/coreplugins/tags/cyto-2_3/AutomaticLayout/src/csplugins/layout/algorithms/hierarchicalLayout/Graph.java

When zooming in to a place, and the centre and radius textfields are updated. Pressing the button go to this node moves you while I feel like that shouldn't happen.

issue?

Currently the parser only saves the information about the edges and nodes for the graph. In the future we might need the offsets and other relevant data.

sprint planning:

• I do not like the comment that you will do something later in pull request #41. Add a TODO or something else to make sure it will not be forgotten.
• Good job with the discussions in most of the pull requests!
• Add labels to issues to indicate the priority/time estimation. This will give a better overview in the project board. Use the description in the issues to describe the issue instead e.g. when is the issue considered to be done? Obviously you can keep the description of the responsible person there.
• Nice to see that the github usage has improved.
• Tasks are not divided equally ranging from 20-40 hours.
• Retroperspective looks good again although I am not sure what ‘sort of’ indicates. Put yes or no there. You could always give a short discussion that it is done as it was defined but has evolved and will be evolving in the next sprint. If anything went wrong this week e.g. a task was not completed, discuss how to improve in the next sprint.

code evaluation

• Testing coverage is 20% (branch coverage). Big improvement! Also good to see that Travis is working.
• You do not close the inputstream in your GFAparser.
• Naming has been improved.
• Some class variables are missing comments (or could be named better to make it more clear what they do).
• MenuController and GraphDrawer have commented lines of code.
• Some modules are already starting to pop up in your application. Document them in the architecture design so one knows what each module/package is doing and how they are communicating to each other.
• Add pictures to your README.

There are still a lot of crossing edges.
We can use the strategy previously used in layout_algorithm.

Plan:
Topological order
Add dummy nodes
Barycenter heuristics
Coordinates

sprint planning:

• I said it last week but I’ll mention it again: Make sure your backlog is converted to issues and added to the project next week. We grade your project only and the backlog / retroperspective for the retroperspective part. The use of Github projects is a mandatory part of the project and it is a waste to get a low grade, because your backlog document is very good.
• Make one person responsible for a task. You can do this multiple ways e.g. assign only one person, discussion the description who is responsible, link back to the user story which has only one responsible team member.
• Make sure to prioritize your issues. Ranking them from top to bottom is not enough. You could create a tag to indicate if it is an A or E for example.
• A limited amount of issues have a description. Make use of this feature. You could use it for the responsibility as mentioned or to link back to the user stories.
• Make sure to convert the entire user stories into issues or labels in your projects and link the task issues back to these user stories in some way.
• There is no indication of the time is takes to complete the tasks.
• Good retroperspective! Make sure to also include a discussion on why tasks took longer and how you will improve your planning to be more accurate in the next weeks with this experience.

code evaluation:

• The amount of architecture that you can apply is limited at the moment (for the project, not for you). - Try to discuss more on how you enforce some goals e.g. maintainability.
• Are you missing the org.biojava dependency in your Maven project? It does not build for me.
• Where is your continuous integration?
• There is commented code, even an entire commented class, in your source code.
• There are comments in the methods and above one class. Make sure to use javadocs and put comments in complex classes.
• Do some research on magic numbers and remove them from your code. For example, 200 in GraphMaker.
• The overall method and variable naming is good but can be better e.g. Node2, header2 etc.
• You have unused variables.
• Your Github usage is okay, but I do not see any indication that you are using other tools. If I am correct you have setup checkstyle so make use of it.
• I see that you are doing some code reviews which is good. However, the discussion are minimal. IT is okay for the 2 pull requests that you have done but extend on this in the future.
• Branching it OK, but try to minimize the amount of direct commits into the master branch.

Jasper is responsible
Jasper and Lex
15 hours
Priority B

Jip is responsible
Jip and Marc
10 hours
Priority C

Now that we have succesfully configured tools, time to use them! Lets make sure everywhere has javadoc comments and adheres to our checkstyle rules.

Here is the feedback for the first sprint. I will enter all your grades here so you can track your progress ;)
https://docs.google.com/spreadsheets/d/1Iwh3c_7h7nLzIZ6U_ZYzfnZ9fsl8cEb9FierR_zhicM/edit?usp=sharing

Some overall feedback:

• Make sure your backlog is converted to issues and added to the project next week. We normally grade your project only and the backlog + retroperspective for the retroperspective part.
• Nice to see responsible team member!
• Clear priorities and estimations! When adding them to your project try to use the tools from Github to keep it this clear e.g. use labels and assign team members to tasks. The issues should also link back to your user stories.
• You should spend 28 hours per person per week.
• Split the work so that every team member does the same amount of effort.

The grades were given on the snapshot taken on the deadline. However, I will give some feedback on it already since I see you already changed it a lot.

• Columns are properly defined. You could add another column like ‘waiting for peer reviews’ to enhance your pull based development process.
• Who is (end)-responsible for a task that is assigned to multiple users?
• How are the tasks prioritized?
• What is the time estimation of a task?
• Use Github labels and other tools to the priority and time estimation clear.
• Link back to your user stories in your issues.
• Side note: it is no longer required to put every sprint in a new project board. Use one project board instead!

When loading the test gfa file and invocation target exception is thrown.