A few months ago, the Google Summer of Code 2008 program officially came to an end. I don’t think I can name all the things that I’ve learned throughout the summer, since there’s just so many! But I thought I’d mention a few:

• Reading – It wasn’t until this summer, had I realized how much reading a developer does. I devoted more time familiarizing myself with the Cytoscape code base than actually developing myself. I’ve also realized that reading external resources like books and discussion boards often facilitate your ability to work independently.
• Documentation – Over the summer, I’ve truly learned the importance of documentation. Spending the time to document your code while you develop it will save a lot of time for yourself and others that will have to work with your code in the future.
• Communication – In open source projects, developers are often located in all parts of the world. It is very important to have good communication skills so problems, ideas, and concerns can be addressed and brought to the others’ attention regardless of where they are. Read the rest of this entry »

Ever since my last post, I’ve been busy finishing off my plugin by implementing various additional features. These include the first two suggestions from the previous Refinements post, as well as:

• Allowing users to specify separate Spring Length and Spring Coefficient parameters for node and label edges. This further improves the label layout plugin’s ability in enhancing network readability.

• Allow users to reset the label position of all their nodes. Without this option, users will have to reset the label position of each and every node manually in order to undo the change in position.

In addition to implementation, I’ve also been:

• Editing the Cytoscape User Manual on the Cytoscape Wiki to let users know how to use this label layout plugin
• Cleaning up code and adding more documentation
• Issuing tickets on Cytoscape’s bug tracking system regarding what still needs to be done/fixed
• Testing, testing, and more testing..

This will be my last week of Google Summer of Code 2008. It’s been an awesome summer, and I’ve definitely learned a lot! For the rest of this week, I will continue wrapping up this project, and I will be working on making my ScreenCast.

Gary kindly dropped by my office this morning to take a look at what I’ve got up and running so far for my plugin. It seems like the both of us are quite happy with the general functionality of the plugin, and how well our approach turned out. So what’s next is a few new features that I will be adding to my plugin:

• Of the total number of iterations of the algorithm, users can specify what percentage of these iterations they would like the network nodes to be moved as well. [Kindly suggested by Greg :)]
• Reposition the labels (and network nodes as well, taking the previous feature into account) only for the selected nodes.
• Implement some sort of smart label wrapping which will wrap long labels into more of a square/circular shape.

In addition, I will also be spending some time testing out my label plugin to see which default values will work best for the plugin.

With a week and a half left of my GSoC summer (I will be volunteering at the Agile Conference next week), I am going to implement as many of these as I can. :)

As of last week, I’ve completed my first label repositioning plugin. It successfully repositions the labels of the network so that the networks are more readable. However, it is currently tied with the Force-Directed layout algorithm in Cytoscape. Also, this current approach creates too many additional temporary edges, which are later removed. So after meeting with my mentors last Friday, we’ve decided to take a new approach:

• Make a copy of the current Force-Directed layout class (this will also copy the Tunables over so that constants that the algorithm needs can still be set by the users)
• Convert each label to a LayoutNode as well
• The list of LayoutNodes that will now be used will contain both network nodes and labels
• Modify the algorithm so that it only needs to look at the x and y coordinates of various LayoutNodes

So this is what I will be working on for the next little while. :)

Here is an example of how networks look after the current label plugin is applied:

Before:

After:

This year’s Cytoscape Retreat is being held on campus (University of Toronto – Terrence Donnelly Centre for Cellular and Biomolecular Research Buildling). It’s been a good chance to meet others that are also working on Cytoscape. And it is also a good place to practice giving demos.. :)

For the past week or so, I’ve been reading more source code! But this time they were graph drawing classes that others have already implemented in Cytoscape. My mentors have suggested that I check if I can use an existing graph drawing algorithm if they’re suitable, instead of writing my own if it already exists. So I’ve been reading the Spring-Embedded JGraph layout code that Cytoscape currently offers through JGraph. I was planning to copy the source code over and make slight modifications to them in order to implement my own plugin. However, the current Spring-Embedded algorithm relies heavily on other JGraph classes within their layout packages. This has become a problem in the development of my plugin, because my plugin will be a Cytsocape plugin and it will not be offered under JGraph. So in order to make this all work, I can either:

1. Take whatever classes that the Spring-Embedded algorithm relies on, and include them in my label plugin’s jar file.
2. Write my label plugin based on the Cytoscape plugin template, and copy pieces of the implementation in the Spring-Embedded layout algorithm over to my label plugin, wherever they are relevant.

The first approach does not work out very well. Like as I mentioned above, the Spring-Embedded layout has been implemented in such a way that it relies heavily on its fellow JGraph classes. Hence, if I were to copy over the necessary classes needed in order to make the Spring-Embedded layout run as a simple Cytoscape plugin, I will have to copy over a lot of classes due to the complex dependencies involved. So I’m most likely going to give the second approach a shot, unless I can find a third approach that will be even better. Taking the second approach should not be too difficult since the Spring-Embedded algorithm is quite simple.

I will continue to speak to other Cytoscape developers at the retreat, and see what others think about this problem. I’m sure I will get some interesting feedback on this issue, and maybe even some interesting solutions!