Skip to main content
Jump to: navigation, search

Difference between revisions of "Recommenders/Attic/ContributorTopics"

m
m (Developers who looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector)
Line 5: Line 5:
  
 
== Developers who looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector ==
 
== Developers who looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector ==
''Partially In Progress. Stefan works the selection listener as part of his GSOC; SS 2011''
+
''Partially In Progress. Stefan works on the selection listener as part of his GSOC; SS 2011''
  
 
While developers learn how to solve a specific task they need to learn about the given API. Assuming they found a starting point they have to figure out if there are additional things they must know about or which would help them. This is something every developer will be confronted with again and again. For instance, if a developer is looking at the implementation of Wizard#addPages he might also be interested in looking the methods Wizard#addPage or Wizard#setNeedsProgressMonitor.
 
While developers learn how to solve a specific task they need to learn about the given API. Assuming they found a starting point they have to figure out if there are additional things they must know about or which would help them. This is something every developer will be confronted with again and again. For instance, if a developer is looking at the implementation of Wizard#addPages he might also be interested in looking the methods Wizard#addPage or Wizard#setNeedsProgressMonitor.

Revision as of 02:28, 20 May 2011

"Clean Code" Method Sorter / Code Formatter for Eclipse

In Progress. Mateusz, Fabian; SS 2011

Coding conventions as discussed, for example, in Clean Code recommend that methods should be ordered in the sequence they get called. This drastically improves the readability of your code, since the amount of jumps in code required to understand the code are reduced to a minimum. Manual ordering is an annoying and time consuming task. During this hands-on you will develop an Eclipse Code Formatter that sorts a class' members according to Rober C. Martin's Clean Code style guide.

Developers who looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector

Partially In Progress. Stefan works on the selection listener as part of his GSOC; SS 2011

While developers learn how to solve a specific task they need to learn about the given API. Assuming they found a starting point they have to figure out if there are additional things they must know about or which would help them. This is something every developer will be confronted with again and again. For instance, if a developer is looking at the implementation of Wizard#addPages he might also be interested in looking the methods Wizard#addPage or Wizard#setNeedsProgressMonitor.

But how do you get the information what you should have a look at? Webshops like Amazon follow a pretty simple approach. They just look at how their users interact with their webapp and collect the information what the user looked (i.e., clicked) at and then run some mining techniques on this data to extract valuable data. During this hands-on you will create an Eclipse plug-in that collects the information what API elements developers investigated and publish this information to a central knowledge repository. In a subsequent step this data will be analyzed to find valuable patterns in this data - howerver, this is not part of the hands-on :)

Example Code-Search Engine 4 Eclipse

In Progress. Katrin; SS 2011

Finding good code examples is a difficult task. Code-search engines like Krugle or Google code-search aim to support developers during this task. However, their search capabilities are somewhat limited. Recently, the Code Recommenders project published a first prototype of next generation code search engine tightly integrated into Eclipse.

However, due to copyright and license issues some companies prohibit the use of code-search engines that work on untrusted codebases. Thus, during this hands-on you will design a local, lucene-based code-search engine that works on the local Eclipse installation an workspace only.

Callchain Completion ++

In Progress. Christian, Ingo, SS 2011

Query Builder for Code Search

In Progress. Niklas; SS 2011 In our current implementation of Code Search we use Code Completion as input to build search queries. This is an easy and intuitive way to create queries, but it is limited in flexibility and adjustment of terms. So we think that a view allowing developers to define the elements of the query in an intuitive way will be a necessary supplement.

Additionally it is possible for the client to determine which feature weights should be used for scoring on server side, but as a view is missing to edit those weights this feature is not usable, yet.

Flexible Configuration of Content Assist lists

In Progress. Thomas, Gerrit; SS 2011

The preference page for the Eclipse Completion Engines currently allows you to enable multiple engines on the default tab. But for cycling multiple tabs it is only possible to have one engine on each cycling tab. As Code Recommenders adds multiple engines, we faced the problem that we must aggregate our engines to provide useful configurations to developers. This change is filed and accepted as feature request by the JDT team. There are some adapted screenshots attached to the feature request to give a hint of how this could be implemented: https://bugs.eclipse.org/bugs/show_bug.cgi?id=340876

Synonym based completion engine

Open.

When working with unknown APIs developers may use the code completion to search for methods applicable to what they currently want to do. Probably they already have a keyword they are looking for and just search the list of proposed methods matching that one. For example the developer already knows about arrays, but is new to collections and wants to know how many elements are contained in a collection. As known from arrays the developer starts to search for length and types in the prefix “len” to reduce the list of proposed completions. As we know there will be no proposals matching “len” as the method he is searching for is named size in collections. But if the completion engine would allow using synonyms it could propose size knowing that size and length are exchangeable words.

Highlighting of related methods

Open.

The eclipse editor already introduces highlighting for usages of the selected variable or method in the open document. Think of an extension to this concept that also highlights methods of interest based on similarity to the current selected method. Similarity of methods can be introduced by comparing what methods get called and which fields and types are used. The outline view may highlight related methods by making them bold if they are related to each other - for example, if a user selects a method compress() inside the class, the Outline view may highlight the method decompress() since it is using the same fields.

Web-Crawler for stacktraces

Open.

We are currently implementing a platform where developers got stuck on an error can search for their stacktrace to get help. Current search engines don’t fit very well with stacktraces. So we set up an optimized search with an index of stacktraces pointing to help resources on the web. To find those stacktraces on the web we need crawlers for all kind of structured resources. We currently have a crawler for bugzilla for example. An interesting type to crawl is a RSS-Feed as lots of discussion and help platforms provide them.

Subwords Completion Engine

From Stackoverflow we received a request for a fulltext autocompletion engine. See this blog post and this forum thread for details. A first prototype is implemented but a few features are missing like

  • Relevance Sorting. Sort proposals that match the prefix entered by the user higher in the list than those that match the simple regular expression. A first guess how to implement this may be to use the Jaro-Winkler string distance measure and rank the proposals accordingly.
  • Make it work for any proposal. So far, it works for method call completions only. But it should be straight forward (and useful) to implement this for any kind of proposal.
  • Track what tokens user enter to get the 'right' proposal. Imagine: If you learn what people mean if they write 'pb' or 'opn' you can create an incredible fast code completion engine that seems to read your mind. To see a great example of that check out [1] and [2] :)

Back to the top