After tolerate long verify time for quite a long, I finally start to fix this. When running verify.build.xml, Unit test and EMMA are both invoked. The unit test is to ensure all unit tests are passed, and the EMMA is to get a coverage of the current system. But both of them need to run junit to execute all unit tests in the system. Exactly same tests are executed twice. It is surely a waste of time, especially when these tests takes several minutes to complete and I have to wait until it finish then I can commit the code. So the idea it to combine these two task together. In the EMMA task, it requires to run the junit and track it to get coverage data. But in our old version, the EMMA task just get the coverage data and discard the test result. So I added code to let it monitor the test result as well and generate junit reports in build directory, which can be used to generate junit results and sensor data. Then I add a task in emma for verify, which invoke emma.tool, junit.report, junit.sensor, emma.report, emma.sensor, emma.echo to complete all task in Unit test and EMMA. Now, the verify.build.xml runs almost twice as fast as before.
The color issue is fixed now. The random colors are selected in a way that colors have maximum difference from each other. This is done under the color wheel conception. If we need to pick n random color. The first color will be selected randomly, the other colors will have 360/n degree away from the preceding one, so that they will be distributed on the color wheel with maximum distance.
Moreover, the stream color mechanism is improve to take more use of coloring. The new rules are:
- If there are more than 1 unit axis, streams will be colored according to the axes.
- If there is only one axis, but have multiple stream names, streams will be colored according to the stream name.
- If there is only one stream name as well. All stream will be colored separately.
Trend interpretation has been improved. Before, only the monotonous trends will be considered as stable, increasing or decreasing. All others will be considered as unstable. This is not the way people interpret trends. People accept a certain amount of vibrate in trends and still consider stable, increasing or decreasing. So I change the system this way. If a point has difference from the preceding point with certain amount, which is calculated as 5% of the average of the stream, will be considered same as its preceding. Otherwise if the point is higher, then it is increasing, if lower, then it is decreasing. Then the system go through the stream. If there is no increasing or decreasing points, the stream is stable. If it has increasing but decreasing points, it is increasing. If it has decreasing but increasing points, it is decreasing. If it has both increasing and decreasing points, it is unstable. In this way the system can accept trends with small vibrations and still classify them as how people usually do. Also the acceptable difference is discussable.
What's more, I added a classifier class to do this job. That means user can write their own classifier to interpret the stream trends, may be using some sophisticated mathematics methods as well.