Hi,
Here are a few suggestions of mine:
- FTP/SCP for the embeded version in a transparent manner. In case of IntelliJ, the EAP testers are programmers, and for them is not hard to FTP a file. In most of the real cases however, this is too much required from a normal tester. The tester would press only a button : "upload snapshots", and an upload progress bar would appear. Under the hood, the snaphsots are taken, and the upload process is started.
- Integration with Some widespreaded Bugtracking systems (ex: JIRA), where the uploaded file gets an Item ID, to attach the snapshots. JIRA has a very simple API for this. This feature would bring you more publicity, directly at those "integrated" sytems .
- BZ2 or a better compression method for the snapshots. There are plenty of java implementations for higher compression than ZIP.
- J2ME integration, but with GOOD examples, since in the case of J2ME, one would call the process "extreme profiling" .
- Automated snapshots, treggered by some special events. Here commes into my mind the Automated testing framework Marathon too.
Jake.
small feature list :).
-
- Posts: 1624
- Joined: Tue Aug 10, 2004 7:52 pm
we are planning this feature for next major versionFTP/SCP for the embeded version in a transparent manner. In case of IntelliJ, the EAP testers are programmers, and for them is not hard to FTP a file. In most of the real cases however, this is too much required from a normal tester. The tester would press only a button : "upload snapshots", and an upload progress bar would appear. Under the hood, the snaphsots are taken, and the upload process is started.
this is really interestingIntegration with Some widespreaded Bugtracking systems (ex: JIRA), where the uploaded file gets an Item ID, to attach the snapshots. JIRA has a very simple API for this. This feature would bring you more publicity, directly at those "integrated" sytems Smile.
Do you have any experience with them? Actually we are afraid that using on-fly compression might dramatically slow down snapshot saving.BZ2 or a better compression method for the snapshots. There are plenty of java implementations for higher compression than ZIP.
already working on itJ2ME integration, but with GOOD examples, since in the case of J2ME, one would call the process "extreme profiling"
good idea, thanks!Automated snapshots, treggered by some special events. Here commes into my mind the Automated testing framework Marathon too.
-
- Posts: 8
- Joined: Mon Nov 01, 2004 5:59 pm
My experience is that, indeed, better compression alone is slower. However, "good compression" + "slow internet connection" is overall much faster than "normal compression" + "slow internet connection" .Vladimir Kondratyev wrote:Do you have any experience with them? Actually we are afraid that using on-fly compression might dramatically slow down snapshot saving.BZ2 or a better compression method for the snapshots. There are plenty of java implementations for higher compression than ZIP.
I was working in a GIS project were such a compression was used.
1.The point was there to know the connection speed first (like in video streaming).
2. At transfer time we knew the overall uncompressed size of the information (you know that too, since is a memory snapshot)
2. Based on the streaming speed and the size, the content was eventually sliced in smaller parts and packed with better algorithms, or just ziped and send as one file if the speed was good enough or the size was too small. Most of the constants were calculated a priori and used in each session.
It seems really more complicated than it is , but we had very big map files and only 5% of the uses had fast ADSL connections, so it was a spectacular speed difference if this feature was turned off.
Jake.