GSOC Proposal: Usage Data Collection for Code Completion

Hey all. As you probably all know, this is the Code Recommenders project blog we typically use to announce new features, releases or other noteworthy topics related to Code Recommenders. This blog post series will be a bit different: In this series we will have a set of (wannabe) GSOC students presenting their projet proposals to the Eclipse Community in the large to get your feedback. If you like these ideas please post your ideas and comments here. Students would be glad to hear what you think!
Best,
Marcel

_______________________________________________________________________________

Hello,


my name is Timur and I want to participate this year on Google summer of code 2013 (GSoC) extend the Eclipse Code Recommenders project by a specific dialog, which shows user specific statistics how they use the Eclipse code completion. This data will be graphical presented in an own dialog. Eclipse developers thus have the possibility to see how effectively they work every day with their IDE. 


Project Description

Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).

With this project various metrics could be created, which provide the developer interesting facts about his work. For example, we could show how many keystrokes are saved from a developer through the code completion engine that would have to type manually without this engine. With this additional data we could also evaluate the developer activity. On which days/weeks is the developer more productive and show this interesting information in a chart (or block diagram). So we can see which days/weeks are the real working days/weeks and the other one. This stats center could extend through other Eclipse data, like the Eclipse shortcuts and something else. The following data we could show about the using of the code completion engine in a specific dialog:

• Number of times code completion triggered, concluded and aborted 
• Number of saved keystrokes by using the code completion 
• Types on which the code completion was used (fields, local variables etc.) 
• In which classes code completion was used 
• How much time code completion saves

Mockup

The dialog for this additional information could be split in several tabs. The first tab contains all metric data about the use with code completion. The next tab “Charts” could contain a few graphical analyses about the use of the code completion engine based on days or weeks. The “Conclusion” tab contains some summarized data about the developer himself and some suggestions how developer could be more productive with the Eclipse IDE. For this use case we could analyse in the background the used Eclipse shortcuts. With this data we know, which shortcuts are often used and which one are not used. With this information we could suggest which other common shortcuts are used by another proficient developers. This could help some Eclipse newbies, because they can learn very fast, which is the common way to develop productive software. But also real Eclipse experts will hopefully give some good tips.

Deliverables

In the final stage, of course, the implemented plugins should have been tested and checked out for their functionality (through the mentor). For this project I have planed the following milestones:

• Milestone 1 (25. May): 
• Create UI Mockup with the community
• Study the documentation and the code base 
• Milestone 2 (20. June):
• Integrate various metrics and implement the infrastructure for this project
• Pimp the dialog, e.g. with ui.forms and some cool icons etc. 
• Milestone 3 (15. July): 
• Integrate the charts and conclusion tabs in the dialog 
• Milestone 4 (10. August):
• Create tests for this project, if possible I will do this parallel 
• Maintain the wiki and document the new created code 

Public Checkpoints

• Checkpoint 1 (31. May):
• Announce the UI Mockup in a blog post or Wiki 
• Checkpoint 2 (30. June):
• Announce the dialog with the first tab (contains metrics) 
• Checkpoint 3 (31. July):
• Announce the chart and conclusion tab 

Tech-Spec

Here are some tools or frameworks are listed, which I would to use:

• Attractive look & feel in the dialog
• SWT, JFace und UI.Forms 
• Persist user data 
• JSON: persist the java objects on the file system
• Plugin: com.google.gson.Gson 
• Create charts
• JFreeChart (Open Source under LGPL)
• http://www.jfree.org/jfreechart/ 
• Tests
• JUnit, JUnit Plugin Tests and SWTBot tests