Google Summer of Code 2013

phillipuniverse edited this page Mar 29, 2013 · 14 revisions
Clone this wiki locally

Google Summer of Code 2013

Welcome! This page hosts ideas for Google's 2013 Summer of Code. This should be used as a starting point for student's that are interested in contributing but feel free to expound upon these ideas or come up with your own! Additional ideas should be posted/discussed at our forums

Information for Students

Thanks for expressing interest in contributing to Broadleaf! If you have any questions or would like to connect to us directly, please feel free to post on the forums or send us a direct email. We recommend that students that would like to contribute to Broadleaf have at least some Java experience, while the ideal student would have some experience with the following (some of which is dependent on your specific project idea):

  • Spring Framework and Spring MVC (a huge plus)
  • Hibernate
  • Familiarity with web technologies
  • Familiarities with other web frameworks
  • Java web application development in general (a big plus)
  • Maven
  • Git

We have also pointed out recommended experience specifically for each suggested project. Again, this is recommended experience but not required. If you are a self-motivated person then you should be able to pick up specific domain knowledge as you work throughout the summer.

Write a mobile application to exercise/demo our REST APIs

We have optimized most of our Heat Clinic application (which serves as our demo site and can be viewed at http://demo.broadleafcommerce.org/heatclinic) for the mobile web using media queries. This way, if you are on your phone and go to a Broadleaf site (or just the Heat Clinic application) you'll have a mobile-specific experience and different elements will resize themselves to support the smaller screen. However, we do not have a good demo of our REST APIs (which we offer in XML and JSON) which could also be used in mobile applications. Ideas for utilizing this could be:

  • Create an iOS, Android (Java), Javascript (think JQuery mobile) client framework to utilize our APIs
  • Using the previously created client framework, build a demo application that allows for product/category browse, add/remove/update cart and checkout completion. This would represent the most basic functionality but this could also be enhanced to include viewing your account (like order history)
  • Through this process, identify gaps in what we offer for our REST APIs and what would be required to fill in the gaps (for instance, our content management system is not REST-enabled)

Recommended Experience

  • Familiarity with using REST APIs
  • If you are developing a mobile application, some experience in that domain is preferred

Add security to our REST APIs

This could technically be wrapped up into the previous idea but could also be tackled as a separate project. We do not offer any security (either OAuth or generic API security outlined by http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/). For a little more detail:

  • API Security - security on an application level. Individual sites that utilize Broadleaf might want to implement some sort of security level for which REST clients have access. This would prevent unauthorized REST client access to the APIs of a Broadleaf site.
  • OAuth Security - this could be either OAuth v1 or v2. This is slightly different than general API security; rather than authenticating a particular REST client as a whole, this would authenticate a REST client for use of specific Customer data (like username/password and obtaining order history).

Recommended Experience

  • Databases - you will likely be making domain changes to support any kind of security you are adding
  • Spring MVC/Spring Security - Some modification in this domain will likely be required
  • Jackson - this is the server-side framework we use for our REST APIs that you will likely need to deal with in order to properly implement any type of REST security

Fix/Update our Grails plugin

We started on a Grails plugin but it has fallen into disrepair. This targets Broadleaf version 1.7 (latest stable version: 2.2.0) and Grails 2.0.3 (latest stable version: 2.2.1). This would be a great project for someone that wants to learn Groovy and/or Grails which has been steadily gaining traction in the Java community.

Recommended Experience

  • Groovy/Grails/Gorm

Improve Broadleaf's Test Coverage

Our test coverage is currently pretty lacking and could definitely be improved. A good solution to this would look like the following:

  • Get our test coverage to above 70%
  • Ensure that there are at least some tests for each of our core modules (for instance, our admin code currently has 0% test coverage)
  • Write better tests for our Spring applicationContext merge process
  • Hook up Broadleaf to something like Sonar or Cobertura (which has a maven plugin we are using in some of our integration modules). This well help us publicize our test coverage and identify exactly what areas of Broadleaf are missing tests

Recommended Experience

  • Some previous eCommerce experience to write good tests

Write new integration modules

We are always looking to enhance our third party integration offerings. These could be separated into different categories such as:

  • Payment Modules (PayPal, Authorize.net)
  • Shipping Modules (USPS, FedEx)
  • Fulfillment/OMS (ShipWire, Order Harmony)
  • CRM Integrations (SugarCRM, SalesForce, Zoho)

Recommended Experience

Java. If you have integrated with a provider in a different language or for a different project and would like to port that integration over into Broadleaf, that would be awesome but that is certainly not required.

Integrate with new services that have a non-US focus

While the Broadleaf organization is in the USA, we have a lot of interest from international markets, mainly based in Europe where open source (and Java) is very attractive for various organizations. Any additional integrations that have a specific focus on sites based outside of the US (for instance, UK mail) would be great.

Other more concrete ideas for possible integrations that we do not have currently:

Support additional features in existing integration modules

For example, we built a UPS integration and utilize their rate estimation (calculating cost of shipping). There are many other services that UPS offers that we do not have support for. This applies to other integrations we have built like Authorize.net; we built the standard authorize+debit but did not build splitting up authorize and debit at different times or handling refunds.