1484511 – Andrew Forward
1
CodeSnippets Plug-in to Eclipse, Introducing Web 2.0 Tagging to Improve Software Developer Recall Andrew Forward,
[email protected]
Abstract — Putting aside the marketing hype of Web2.0, a few central themes have emerged. User generated content, software to enable users (not restrict them), building a community and instant feedback. Many of these concepts can equally apply to rich client applications, and our focus is on software development teams. The initial motivation for Code Snippets was to fulfill our personal needs as software developers. At times, you need to reuse the same coding constructs, library access, method calls, web services, and recalling (or finding) this information is sometimes difficult. Drawing on similar success as online tagging libraries like del.icio.us and flickr.com, we have developed an Eclipse plug-in called CodeSnippets to allow software teams to document, store, share and search communal code to help answer the question, “How do I code that?”. Index Terms— Software tools
Q
Documentation,
Software
engineering,
I. INTRODUCTION
uickly, how do you instantiate an object in JavaScript? How do you do client side http redirects? How do you connect to a MySql database in PHP? How do you compare Dates in Java? None of these questions are particularly hard, and most are probably not even new to you, but it still requires a large cognitive load to attempt to maintain all of the information organized for easy access in the future. Software developer recall presents a major problem to practitioners and huge opportunity to those servicing the software industry. For example, O’Reilly’s book publishing business provides several API-style books for almost all programming languages and frameworks [1]. One of the reasons for its popularity is that knowing the exact syntax, semantics, and pragmatics of programming is difficult. Not only do developers rely on generic constructs and general API documentation, each project team and individual developer builds their own mental model of common solutions to common programming situations. Generic documentation (such as provided in the O’Reilly books) provides little support in capturing this team culture of coding preferences. Let us now draw a comparison to popular Web2.0 technologies. Web2.0 was defined (and continues to be Manuscript received December 14, 2006. This work was supported in part by the Ottawa Carleton Institute of Computer Science (OCICS). Andrew Forward is with the School of Information Technology and Engineering (SITE), University of Ottawa, 800 King Edward Avenue Ottawa, Ontario, Canada, K1N 6N5, phone: 613-236-6240, fax: 613-2485039, email:
[email protected].
defined) around 2001 when the major Internet boom faltered. Web2.0 relies on technologies that enable the Internet to act as a platform where users are in control of their data, and software is delivered as a service, not as a package. Major themes like tagging versus taxonomy, rich client experience, and user as contributor have emerged from Web2.0 software [2]. Many of these concepts need not be solely applied to the Web and it is our belief that we can improve rich client applications by porting several Web2.0 ideas as discussed above. In particular, our focus will be to bring these ideas to software development teams. And, CodeSnippets was born. The software we are presenting in this paper is a plug-in to the Eclipse platform. CodeSnippets acts as a repository for software developers to store tidbits of source code that is tagged with relevant keywords and shared between team members in an effort to alleviate developer recall and act as an informal API-like documentation resource. CodeSnippets can be used in a multi-developer environment and supports sharing and searching between developers – acting as a valuable communication tool. Our software, CodeSnippets, is an open source plug-in to Eclipse [21]. CodeSnippets is currently being hosted by Google Code at [3] and has been available since November, 2006. The current version of CodeSnippets is 1.1. A. Problem The current process of remembering how to perform a lowlevel coding task (such as traversing a hash table in Ruby) is to either recall from memory, attempt to locate a similar instance in your current (or potential recent past) projects, to visit your favourite search engine, or to reference an API document – all of which can yield positive results. The primary drawback with any of the search solutions above is that none of the mechanisms are optimized for the task of locating example code outlining the necessary syntax, semantics and pragmatics of your coding question. There is also a smaller issue that apart from memory recall you must break from your current development context to seek your answers, an inefficiency that prolongs the development effort. Apart from generic how-to questions that we have outlined above, each software development team employs its own coding style, custom framework modifications and has its own rich set of how-to guidelines – most of which are available in the code, but not necessarily well documented [4]. This lack
1484511 – Andrew Forward of documentation is not necessarily a poor reflection on the team itself, but rather a poor reflection on the tools to help capture and share this informal knowledge.
2 sense of pride in the delivered system. The third goal is to experiment with the ability to test-drive an Eclipse plug-in, in particular to apply test-driven design (TDD) approaches to the user interface components / widgets.
B. Motivation CodeSnippets was motivated by our personal frustration of facing a particular coding scenario that we had already faced (sometimes in the not too distant past), but could not recall the required syntax, the exact semantics or the preferred pragmatics of resolving our scenario. If only there was a mechanism to tag tidbits of software source code for later reuse this issue of recall would be reduced to remembering the appropriate keywords of a code snippet as opposed to remembering the snippet itself. Context switching can be slow and inefficient for individuals to do. The issue of recall is augmented for software practitioners that work in several environments (i.e. Windows, Unix, Mac), in many different programming languages (Java, JavaScript, Sql, Ruby) and within different programming paradigms, frameworks and coding standards (Struts, Java Server Faces, Rails, Fusebox). A secondary motivation was to experiment with integrating various Web2.0 features [5] that have been very successful in the web niche into a rich-client application. The Internet has deployment advantages over conventional rich-client applications, but with the rising popularity of the Eclipse platform ([6], [7]), deploying rich-client functionality via plug-ins has become very straightforward. C. Goals A successful software project can have many qualities and attributes. In our case we focused our definition to software that is deployed and used; is of high standard of quality; provides proper separation of concern; and, provides internal feedback about itself - how it is used (and perhaps not used). Software is meant to be used. Secondary efforts such as requirements, design, architecture, and documentation are also important aspects to ensure that a software system can continue to be used, maintained, and enhanced. But, it is important not that to lose sight of the fact that that even a well-specified, architected, designed, documented and feature full software application is of limited use if it is not widely adopted and well used. Our primary goal in developing CodeSnippets is to create software that is easy for people use, and find useful. We want software practitioners to use CodeSnippets as a platform for dealing with recall issues without enforcing style or semantics on the way in which the tool is adopted. Software construction, like other more physical forms of construction, can create a sense of accomplishment (or unfortunately disappointment). Software practitioners take pride in their work and so the secondary goal of CodeSnippets is to employ the appropriate tools and approach to software development to create a system of high-quality to foster a
D. Objectives Our objective is to create an implementation of the CodeSnippets software that is purposefully light. It is intended to act as a tracer bullet [8] into the world of community based rich client applications where feedback from real users will be the ultimate driving factor of new development. By providing an unobtrusive, multi-user plugin to eclipse that can ease developer recall we hope to meet our goals. CodeSnippets consists of an Eclipse plug-in for the current release version 3.2. As well, there is an associated CodeSnippets feature and update web site to facilitate deployment [3]. CodeSnippets was developed using testdriven design (TDD) and these tests will be integrated within the plug-in and available to all future developers. Finally, CodeSnippets is released as Open Source software available under the MIT license [9]. E. Outline This paper follows with a brief analysis of existing, competing and complimentary tools and services. We will focus our attention on Open Source software to ensure our audience will have access to all software mentioned in this paper. Next we will outline our approach to designing, constructing and testing CodeSnippets. This section will describe various software decisions and tradeoffs that were made in order to fulfil our goals, align with our motivations and address the identified problem. Once we have provided a sufficient background to our problem, as well as addressing our approach to the issue, we will document our results and provide some validation to our goals outlined above. Finally, we will conclude with a brief review of the goals we set out to achieve and the contributions we have made to the software community. We will also identify areas of improvement and future work providing interested readers with follow-up research and implementation ideas for CodeSnippets. II. BACKGROUND A. Related Open Source Software CodeSnippets is a specialized repository of tidbits of software source code. Related rich-client open source software includes any software that can store textual data, allows keyword searching and / or can be shared own others. In a broad sense, most open source applications apply, in
1484511 – Andrew Forward particular wikis, email software like Firebird and even word processing software like OpenOffice or Notepad++. CodeSnippets is also related to a less structured search approach using a search engine like Google, and targeting keyword searching. Google has also introduced a specialized source-code search engine [10]. Google Code Search searches all public source code based on license, language, package, files or text within the code itself (including software comments). Finally, CodeSnippets is related to several online code snippet web applications. Although these applications are not Open Source, they are open and available to the public for free use. These sites include [12], [13], [14], [15], and [16]. The primary area of differentiation between the above related open source software is that 1.
CodeSnippets supports explicit keyword tagging, whereas search engines provide implicit keywords – which may not align with your personal tagging habits.
2.
CodeSnippets is integrated within your Eclipse development environment. This integration reduces the context switching required to transfer between writing software and searching for relevant source code tidbits.
CodeSnippets represents your personal lost-and-found repository of relevant software source code. Search engines may provide you with the necessary depth to locate your answer to a lost question, but once found you can store that search effort in your own CodeSnippets for easy recall for next time. It should also be noted that CodeSnippets can easily be extended to wrap an existing code snippets service provided that that the service legally allows it and an appropriate API (for example using web services) is available. III. APPROACH Software engineering is a systematic and disciplined approach to building, maintaining and deploying a software system. Software engineering is also about automation – productivity applications to automate pen and paper, ecommerce applications to automate business transactions, embedded systems to automate things like temperature and pressure. Embodying the philosophy that software is about automation; our team has diligently applied the design principles of TDD [17] – test driven design. TDD, a process that was first introduced by Kent Beck as TFD (test first design) is a surprisingly efficient approach to software construction. Although it is usually mentioned in parallel with agile software methodologies like Extreme Programming, it is a fairly methodology neutral approach for software construction; most approaches to building software can benefit from applying test-driven techniques. The premise of TDD is that most software is meant to be consumed – either
3 explicitly as a component or library or implicitly as your user interface is the liaison between the software and its users. Assuming a three-tiered architecture, the user interface must accurately and efficiently use the business tier, and the business tier must do the same with the data-access tier. Based on the notion that most software is for consumption, our approach to software construction should begin by stating how the software should be used (i.e. writing an automated test that uses your yet-to-be-developed feature) followed by actually implementing the feature (i.e. getting your automated test to pass). Anecdotally, test-driven development is the only way to ensure that your unit tests will actually be written – as you write them before anything else. And as you will see in the following sections, test-driven development can also be successfully applied to testing user interfaces. Test driving your code also creates an excellent regression test suite to enable future optimizations or feature enhancements. Software is difficult to optimize early and to implement relevant new features without user feedback. Indeed you can follow certain guidelines and heuristics to minimize performance bottlenecks and deliver highly used and usable software - but end user use provides the ultimate demonstration about what is actually used in a software application, and how it used. CodeSnippets has an integrated high-level footprint mechanism (which is more abstract than an internal logging mechanism) to track all user driven features to accurately capture how users tag and search source code. The expected result of tracking the usage of the application at a feature level means that we can optimize high traffic features, and that we can improve (or even remove) unused and unloved features. By removing unused (and nonuseful) features we can reduce the overall complexity of our software. A. Design CodeSnippets is available as an Eclipse plug-in to the Eclipse platform version 3.2. CodeSnippets is geared for software developers. By developing a plug-in to the Eclipse platform, CodeSnippets will be available to Java developers and to a lesser extent PHP, C #and Ruby developers. CodeSnippets provides several views (access points) into the Eclipse platform and uses the Standard Widget Toolkit (SWT) and JFace components to render the user interface.
Figure 1: CodeSnippets Plug-in Integration with Eclipse The user-interface is available as four interconnected views, NewUserView, TagEntryView, CodeSnippetSearchView and StatisticsSummaryView as shown in Figure 2 below.
1484511 – Andrew Forward
4 Issues like scalability, performance and implementation are well encapsulated behind the interface. The primary methods of the persistence layer are outlined below.
Figure 4: CodeSnippetRepository Interface Methods Figure 2: CodeSnippets High Level Class Diagram Each view communicates with a CodeSnippetRepository – which is an encapsulation of the underlying persistence and search mechanism. The repository’s primary business objects include a Tag which represents the title, keywords and source code of a tagged code snippet and all actions are carried out by a User class. The primary focus of CodeSnippets is the storage and sharing of software source code. To maximize the potential adoption of this tool, we wanted to ensure that the plug-in was simple to deploy, simple to configure and simple to use. The secondary focus was to track actual usage of the plug-in to drive future development. Without adding unnecessary complexity to the plug-in, we isolated the data persistence mechanism as a candidate for future optimization. As of version 1.1, a very lightweight (and un-optimized) persistence mechanism is available for storing and searching your code snippets. Two implementations are currently available, one for testing, and one that is an xml-file-based storage. By fully encapsulating access to the data we were able to draw our attention away from the less exciting features (such as persistence) and concentrate on the core of the code snippets - sharing and searching little tidbits of always-needed-never-remembered source code. The encapsulation also means that out of the box, our users have very little (if any) configuration to get the plug-in up and running.
To demonstrate how to extend CodeSnippets with a new implementation of the CodeSnippetRepository, we will present an abstract implementation of Google’s Code Search for the CodeSnippets application. Readers interested in implemented this feature can download the latest CodeSnippets source code from Google Code at [3]. The first step to integrate Google Code Search into CodeSnippets is to create the appropriate implementation to the CodeSnippetRepository.
Figure 5: GoogleCodeSearch Interface Methods Google Code Search provides only a search interface, and not a repository. As such, the GoogleCodeSearchRepository can only provide access to the getAllTags() method; all other interface methods should return an unavailable exception. Next, is to become familiar with the available Google Code Search API at [20]. Google provides a Java client library and a Google code search within CodeSnippets would resemble: CodeSearchService myService = new CodeSearchService("CodeSnippets"); URL feedUrl = new URL(“http://www.google.com/codesearch/feeds/search ?q=” + searchQuery); CodeSearchFeed resultFeed = myService.getFeed(feedUrl, CodeSearchFeed.class); // Convert CodeSearchFeed into Tags
Figure 3: CodeSnippetRepository Interface
Figure 6: Calling Google Code Search in Java
1484511 – Andrew Forward
As commented above in Figure 6, you will need to create an adapter to convert the CodeSearchFeed result set into an array of Tag objects as defined in CodeSnippets. By using a generic interface to encapsulate the mechanism of searching and storing tidbits of code, it is fairly straightforward for future development to extend the CodeSnippets plug-in by: integrating with existing services (like shown above with Google Code Search), improve existing implementations, or provide more accessible or scalable alternatives (such as a database backend). The following section will outline a few key decisions that were made in the design and development of CodeSnippets. These decisions directly impacted the ability for CodeSnippets to achieve its objectives outlined in the first section.
5
public boolean lock() { File lockedFile = new File(_filename + ".lock");
}
for (int i=0; i lastModified) { lockedFile.delete(); } }
Figure 9: Cleaning up expired locks Figure 7: Accessing all files via a FileAccessor To be a true locking mechanism, the actions performed to lock a file must be atomic. To achieve this atomic action we chose the operation of creating and naming a file to represent our lock (an action which is atomic).
It is important to note that once we completed version 1.1 of CodeSnippets, we discovered that Java’s new IO (java.nio) package contains a similar ability with the FileLock class. The trade-off becomes using a standard library to implement locking (i.e. using java.nio.channels.FileLock) but having to rely on the underlying operating system to manage locks. We decided to stay with our working (and tested) implementation,
1484511 – Andrew Forward but are open to future refactorings. The current file-based persistence mechanism outlined above of CodeSnippets provides the most accurate view of the underlying file system data. By providing no caching of data, individuals are always presented with reliable data but the CodeSnippets application is vulnerable to scalability issues, but as is the case in [19] we do not have a scalability issue, yet. The no-caching approach to data access also avoids complex synchronization issues.
6 revolutionary features can only have an impact on the software community if it is adopted, used and useful. To maximize CodeSnippets potential at being adopted we took several explicit steps. We released CodeSnippets as an Open Source application available under the MIT License [9]. The source code is hosted with Google Code [3] where other software developers can access its implementation. The plug-in is available for download from within Eclipse.
IV. RESULTS / VALIDATION Success of the CodeSnippets project involves several facets including: • Building a mechanism to share and tag software source code snippets to improve developer recall • Deploying the application in a real-world environment with a real team and gathering real feedback about relevance and usefulness of the software. • Building a specialized user-event tracking mechanism to monitor the usage of the plug-in to provide facts about what is really being used, and the patterns by which it is being used.
Figure 10: Updating CodeSnippets Within Eclipse The plug-in can also be downloaded (current release is V1.1) directly from the Internet at Google Code [3].
• Demonstrating that test-driven design of user interfaces (in particular SWT widgets) is possible using a generic testing frameworks like JUnit. CodeSnippets has introduced the Web2.0 community to a rich client platform using an Eclipse plug-in. Web2.0 is about sharing, user-driven content organized more by keyword tags then strict hierarchical structures. CodeSnippets has met this challenge by giving up control on how code snippets are stored (for example, the data entry screen only tracks title, keywords and the snippet itself) and enabling user to build their own collections of source code tidbits. CodeSnippets also provides a mechanism to search not only your own snippets, but also those within your team. From a functionality perspective CodeSnippets delivers as promised. But, for our validation we also wanted to ensure that (a) the tool was useful, (b) the tool was used, and (c) we could discover the gap between how it is actually being and how it was programmed (intentioned) to be used. CodeSnippets ships with the ability to gather data about how (and how often) the tool is being used. This will pave the way for additional empirical studies about the impact of integrating Web2.0 community features into a rich client application. A. Used, Useful and Improved Software with neat, cool, exciting, relevant and / or
Figure 11: Downloading CodeSnippets Directly To further simplify the deployment process, the CodeSnippets plug-in is preconfigured to a default file-based repository (so no external database is required or must be installed) and the only additional configuration is to select a user name. To configure CodeSnippets, there is a preferences page available under Window, Preferences, and CodeSnippets. Once we ensured that the deployment, installation and configuration were easy to accomplish, we started spreading the word. We have received a few unique inquiries from the download site that have showed an interest in the plug-in. We have successfully installed the plug-in within an 8-person development team. Currently only four team members are
1484511 – Andrew Forward using Eclipse, but the feedback received to date has been positive. And, individually we have fulfilled our personal need and have started to build our own repository of code snippets for PHP, JavaScript, Java and HTML. B. Testing, Including the User Interface To deliver high quality, we followed a strictly test-driven approach to our software development. The results have been great. The plug-in hosts over 280 unit tests that span from testing the repository, helper methods, core model classes as well as the user interface.
7 units. From a non test-driven approach, it is much more common to see hard-to-test code tightly coupled with easy-totest code. In such situations you may argue that testing non user interface components is difficult. But, it is not sufficient to merely say something is difficult because current coding practices make it difficult. Instead of throwing our hands in the air and proclaiming testing is hard, that is why we do not do it, we can start with our desired outcome and say testing is easy, and let us ensure it stays that way. Now the issue is no longer that testing is hard, instead the issue is how we can ensure testing remains easy. A (mostly agile) software community introduced the notion of test-driven (originally called test-first) design. This approach to software development centred on the concept that the first code we write should be code to test how we think our software should behave. The truly revolutionary (and unfortunately controversial) approach to software construction meant that all code being written was already well-tested – even before it was complete. Welcome side effects of testdriven design include low coupling between external (and hard-to-test) components, systems and resources, as well as the slow accumulation of a large regression test suite. package ca.kooki.codesnippet; import import import import import import
org.eclipse.swt.widgets.Display; org.eclipse.swt.widgets.Shell; org.junit.After; org.junit.AfterClass; org.junit.Before; org.junit.BeforeClass;
import ca.kooki.codesnippet.*; public class SwtTest { public Shell parent; public static Display display; @BeforeClass public static void setUpBeforeClass() throws Exception { display = new Display(); } @Before public void setUp() throws Exception { parent = new Shell(display); Activator.loadDefaultAsRequired(); }
Figure 12: CodeSnippets Unit Tests The remainder of this section will concentrate on an interesting facet of testing an Eclipse plug-in: the User Interface. Supposedly testing user interfaces is difficult. In some circumstances that may be the case, but let us draw similarities to testing non user interface components. Prior to the formalization of test-driven (or test-first) design, it was much easier to couple hard-to-test aspects of a software system with easy-to-test aspects. Hard-to-test examples include database / persistence access code, external resources like web services, ftp or email, asynchronous operations, as well as poor method signatures. Easy-to-test examples include verifying calculations, ensuring to save the right data, formatting messages properly and isolated business
@After public void tearDown() throws Exception { parent.dispose(); Activator.resetDefault(); }
}
@AfterClass public static void tearDownAfterClass() throws Exception { display.dispose(); }
Figure 13: A Unit Testing Superclass for SWT components
1484511 – Andrew Forward We can now apply a similar approach to testing user interfaces by starting with the notion that testing user interfaces is easy, and let us ensure it stays that way. Our goal was to apply this mentality to testing Eclipse’s Standard Widget Toolkit (SWT) user interface objects with ease. As it turns out, very little extra infrastructure was require. The two primary issues to deal with were that you need a basic UI parent (i.e. Shell) for your UI components (like a ViewPart, or PreferencePage) to attach to. And, you also need a Display to enclose your interface. Above in Figure: 13 is an SwtTest framework class that manages your Display and Shell objects from which all of your SWT tests can extend to enable unit testing. The figure below shows the CodeSnippets preference page. It tracks two properties: where is the snippet repository located, and the developers’ user name.
8 In the example, we used the provided Shell parent to attach our preference page to, then we executed the performOk() method. After which we asserted that the preferences were actually saved and that the user interface provides positive feedback to the user that “Your repository is configured properly”. For more complex user interface components, like ViewParts (which is a typical plug-in extension point to Eclipse), the process is slightly more involved. For each view we created a handler class where we delegated most view actions (like search, save, or reset). Below is an outline of the necessary classes for a MyView component.
Figure 14: CodeSnippets Preference Page An example unit test is shown below that ensures that after clicking on Ok the preferences are properly associated to Eclipse’ preferences mechanism. @Test public void performOk() { page.createContents(parent); page.inputCodeSnippetFile.setText("y"); page.inputUser.setText("z"); page.labelStatus.setText("p"); page.performOk();
Figure 16: Using Handlers To Test SWT Components The MyViewTest is responsible for basic user interface tests – like ensure the labels are properly initialized. The MyViewHandlerTest contains the actual controller tests that ensure the control between the user interface and the underling models is functioning properly. For example, the CodeSnippets plug-in contains a SearchCodeSnippetView.
PreferenceFacade preferences = Activator.getDefault().getPreferences(); String filename = preferences.getString("repository_file"); String username = preferences.getString("user"); String actualStatus = page.labelStatus.getText(); Assert.assertEquals("y",filename); Assert.assertEquals("z",username); Assert.assertEquals("Your repository is configured properly", actualStatus); }
Figure 15: Testing a SWT Component with SwtTest
Figure 17: CodeSnippets Search View The functionality that is delegated to the view above includes search, show/hide, edit and tag. The SearchCodeSnippetView can now delegate listening functions to the handler in the following manner:
1484511 – Andrew Forward
CodeSnippetSearchViewHandler handler = new CodeSnippetSearchViewHandler(inputSearch, outputResults, buttonSearch); buttonSearch.addSelectionListener(handler);
Figure 18: Delegating to a View Handler We can now test that, for example, a search that returns no relevant code snippets lets the end-user know that no search results were found.
Figure 19: No Search Results Found The associated test to verify the above situation is outlined below. @Test public void searchNoResults() { Event e = new Event(); e.widget = buttonSearch; SelectionEvent event = new SelectionEvent(e); handle.widgetSelected(event); Label labelNoResults = (Label)outputResults.getChildren()[0]; Assert.assertEquals("No results found, sorry!", labelNoResults.getText()); }
Figure 20: Testing No Search Results Although not all aspects of the user interface can be fully tested using the approach outlined above, our team was able to add almost 50 additional automated tests to our suite that focussed solely on interacting with the UI – all by adding just a few additional lines of code (i.e. SwtTest super class). By approaching the issue of testing user interfaces by assuming doing-so will be easy, we were able to add several valuable tests to ensure that the UI controllers were properly delegated to, and that the views were properly painting the underlying business models. V. CONCLUSIONS Web2.0 is much more than rounded corners and pastel colours. It is more than having a blog, creating an RSS feed and using AJAX to provide fancy client side scripting. At its core, the Internet software of Web2.0 is about providing an interactive playground for users to share thoughts and ideas within an online community. The foundation of this paper was to bring the key aspects of sharing and community to the rich client platform of Eclipse to help solve the very real problem of developer recall – How do I code that? In an effort to reach the widest audience the developed plug-in, Code Snippets, was geared towards
9 software practitioners enabling them to store, tag and search relevant tidbits of software. A. Review Goals and Contributions We set out to build an Eclipse plug-in to help alleviate the cognitive load on software developers to efficiently remember and access syntax, semantics and pragmatics of day-to-day coding scenarios. To achieve our goal we explored how similar issues of managing large amounts of data are resolved within web-applications. Our approach then adopted many attributes of community-based web applications into the richclient environment of Eclipse using their plug-in mechanism. We wanted to ensure that CodeSnippets was easy to deploy and install. We wanted to ensure that it was easy to use and enabled its user base to share, search and tag code snippets. Finally, we wanted to ensure that the plug-in was built to a high level of quality, even from the first release. We believe these goals have been met. The application can be downloaded directly from within Eclipse using its built-in find and install features mechanism. CodeSnippets data is stored in a file-based repository with a simple but effective locking mechanism. This repository architecture means that you can use CodeSnippets out-of-the-box. Using a test-driven design approach, our first release (CodeSnippets 1.1) shipped with over 280 unit tests – including almost 50 user interface tests. Finally, the plug-in is being used (although to a limited extent so far) by real developers in commercial software development environments – and those users anecdotally find the application relevant and useful to their daily programming tasks. CodeSnippets has demonstrated that Web2.0 functionality such as user-driven content, simple tagging and associations, instant feedback, and enabling (not restricting) user can successfully address issues like developer recall in a richclient environment like Eclipse. This demonstration should convince others to continue the trend – that Web2.0 can be applied to problems in the rich-client domain. B. Future Work The CodeSnippets plug-in has created several distinct paths for future work. The first area of work is studying the effect of using CodeSnippets within a development team as well as studying how the application itself is being used. CodeSnippets is currently available with a user-action footprint to track usage. Working within a controlled environment, experiments could be conducted to both analyze the use of the software (through observation, surveys and focus groups), as well as study the usage-footprint of the software. A second area of future work is to enhance the CodeSnippets feature list. Deciding on which features to implement could be the result of future research as describe in the previous paragraph.
1484511 – Andrew Forward
Potential features include •
Implementing the integration with Google Code Search as outlined in this paper.
•
Implementing a web-application or web-service based CodeSnippetRepository to enable storage and sharing over the internet as opposed to within the same network.
[12] [13] [14] [15] [16] [17] [18]
•
Augmenting user authentication to prevent impersonation attacks. This feature is only relevant once the plug-in itself can be shared within a larger audience.
•
Improving search algorithms. The current implementation provides a lightweight keyword comparison approach to search with much room for improvement.
A third area of future work is to further investigate and experiment with user-interface testing of the Standard Widget Toolkit (SWT). The CodeSnippets plug-in provides a simple SwtTest class to enable some interface testing. By building on this mechanism, we will continue to promote the idea that that testing user interfaces is easy, and let us ensure it stays that way. ACKNOWLEDGMENT Andrew Forward thanks the University of Ottawa, and in particular his PhD thesis supervisor Dr. Timothy Lethbridge for his academic mentoring. Andrew also thanks Carleton University and Dr. Dwight Deugo for his guidance as a course professor. REFERENCES [1]
10
O’Reilly Book List, http://www.oreilly.com/store/publisher/oreillycomplete.html [2] What is Web2.0, http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-isweb-20.html [3] Google Code for CodeSnippets, http://code.google.com/p/codesnippets/ [4] Andrew Forward, Timothy Lethbridge: The relevance of software documentation, tools and technologies: a survey. ACM Symposium on Document Engineering 2002: 26-33 [5] David E. Millard, Martin Ross: Web 2.0: hypertext by any other name? Hypertext 2006: 27-30 [6] S. Cowley. (2006, September) Eclipse foundation touts its development platform’s rising popularity. [Online]. Available: http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId =192600126 [7] E. Foundation. (2006, September) Second annual eclipse global enterprise survey. [Online]. Available: http://www.eclipse.org/org/pressrelease/20060905rcp.php [8] Hunt, Andrew and David Thomas. The Pragmatic Programmer, Addison Wesley Longman, Inc. 2000. [9] MIT License, http://www.opensource.org/licenses/mit-license.php [10] Google Code Search, http://www.google.com/codesearch [11] CodeSnippets Plug-in, http://www.kooki.ca/codesnippets/
[19] [20] [21]
Code Snippets, http://www.bigbold.com/snippets/ DaniWeb CodeSnippets, http://www.daniweb.com/code/ Source Code Snippet Library, http://www.phpbuilder.com/snippet/ OO-Snippets, http://codesnippets.services.openoffice.org/ Symfony Snippets, http://www.symfony-project.com/snippets/ Steven Fraser, Kent Beck, Bill Caputo, Tim Mackinnon, James Newkirk, Charlie Poole: Test Driven Development (TDD). XP 2003: 459-462 David Janzen: Software architecture improvement through test-driven development. OOPSLA Companion 2005: 222-223 37 signals (2006). Getting Real, the book, https://gettingreal.37signals.com/ Using the Google Code Search Data API, http://code.google.com/apis/gdata/codesearch.html Eclipse Framework, http://www.eclipse.org/
