REST

REST stands for REpresentational State Transfer and is an architectural style used for web applications and HTTP related domains. REST is based upon five key principles (from http://www.infoq.com/articles/rest-introduction):

• Provide a URI for every resource/noun/thing
• Use links (URLs) to provide more information on a resource
  
• Utilize standard methods (GET, POST, PUT, DELETE)
  
• Provide multiple representations of a resource
  
• Communicate statelessly (separates the client and server to simplify interaction)
  

In general, some of the benefits of using REST include:

• Caching support
• Simplifies the client side application
• Independent of the server which allows for greater server scalability
• Easier integration of parts and applications
  

Should the Visual Studio Sensor project provide a RESTful interface?

The Visual Studio Sensor relies on the Hackystat SensorShell to transmit data to the Hackystat SensorBase. Because of this the Visual Studio Sensor project does not have to provide a RESTful interface as it needs only to successfully communicate with the SensorShell (which then in turn transmits data to the SensorBase). Since the SensorShell is a client-side "middleware" library that is an independent module of Hackystat (and subsequently part of another project under the Hackystat domain), whether the SensorShell provides a RESTful interface or not is beyond the scope of the Visual Studio Sensor project.

Does the Hackystat API obey REST design principles?

The Hackystat API does obey REST design principles. It utilizes URIs for users, projects, sensor data types, and sensor data. In addition, the sensor data type resource collection incorporates links to point to more information for each individual resource. The Hackystat API also uses standard methods which are the HTTP protocol methods GET, POST, PUT, DELETE, and HEAD. Lastly, communication is handled in a stateless fashion as it does not have to keep track of client states in order to communicate. All in all, the Hackystat API seems to follow the REST design principles to the letter.

Does the Hackystat ProjectViewer obey REST design principles?

The Hackystat ProjectViewer does not obey REST design principles and instead relies on RPC (Remote Procedure Call). It still incorporates the use of URIs but relies on methods or "verbs" rather than on resources or "nouns" like a REST design would.

Introduction to Hackystat Framework

I was able to successfully complete all tasks in regards to introducing myself to a software engineering measurement collection and analysis (through Hackystat). I read through the relevant tutorials and documentation, successfully installed the Eclipse sensor and Ant sensor, and was able to send data to my public Hackystat server account using the example system StackyHack.

Overall, it took me about 3 hours to read through the documentation, install the system, and troubleshoot. There are numerous tours, tutorials, and user guides that are provided with Hackystat. The documentation provides a solid introduction and foundation from which a user can learn about and get a feel for the Hackystat framework. Because of all the documentation, it took me about 2 hours to go through all the various parts. Installing the system was actually relatively simple consisting of just unzipping archives, creating environment variables, and moving files to appropriate directories. This portion did not take more than 20 minutes. I did have to spend about 40 minutes to troubleshoot my Hackystat connection to the server. The connection worked perfectly with Eclipse, but Ant proved to be a little more difficult. Turns out that you can't put the quotes for the ANT_ARGS environment variable that are shown in the documentation . Also, I had the sensorshell.properties in the wrong directory which did not help matters. Other than those general issues of familiarizing myself with a new framework/system (terminology, following setup instructions, etc.), those were the only issues that I encountered.

Somewhat ironically, Hackystat will help me to develop additional sensors for it. The reason I say that is because it will help track my software development process, so that my teammate and I can determine whether our development process is following a healthy trend (when viewed through the telemetry viewer). If our development process is following a healthy trend, then we can continue following our current procedures and processes. However, if the trend is not healthy, then adjustments will need to be made otherwise our sensors will most likely not be any good because our development process is flawed (too little coverage, too many code issues, too few commits, etc.).

All in all, Hackystat seems to be a good example of the three prime directives for open source software engineering:

1. The system successfully accomplishes a useful task.
2. An external user can successfully install and use the system.
3. An external developer can successfully understand and enhance the system.

It satisfies prime directive #1 because the system provides useful metrics on software engineering processes which is extremely helpful and useful to software developers. It satisfies prime directive #2 because I (who for the most part am an external user) have just successfully installed and used the system. Lastly, it satisfies prime directive #3 because you can join the project, check out the subversion repository and work to improve the current features, or in the case of myself, add new sensors to the framework.

After formally introducing myself to Hackystat, I look forward to the opportunity I have to improve the framework (by adding new sensors) and to utilize its abilities/metrics to improve my own software development process.