Skip to content

Google Code In 2013 Tasks

wstrinz edited this page Oct 27, 2013 · 57 revisions

Attention: Please provide as much detail as possible for tasks. Remember, these are secondary school students, and some may have limited programming experience. Tell them what they need to do to succeed, and where/whom they can ask for help.

Example Tasks Grouped by Category

Code Tasks

  • Get all YARV-compatible gems in the SciRuby umbrella project (especially Statsample, NMatrix, Distribution, Minimization, Integration, Plotrb, Rubyvis, PubliSci, etc.) working together. Right now, dependency conflicts exist, particularly surrounding NArray and Ruby/GSL. We have versions of both of these gems (gsl-nmatrix and narray-nmatrix) which work with NMatrix, but they need to be listed as dependencies in place of the old versions.
  • Switch the Distribution, Integration, and Minimization gems to work with gsl-nmatrix instead of gsl (YARV only). These must be done before Statsample can be changed over, as Statsample depends upon these. Each of the three counts as one task (three tasks total). John Woods and David MacMahon will mentor for these tasks.
  • Get Statsample working with NMatrix instead of NArray. This requires replacing the gsl requirements with gsl-nmatrix, and switching NArray references to NMatrix. John Woods and David MacMahon will mentor for this task.
  • Cross-list all SciRuby gems as biogems, so they'll be listed on biogems.info. (Don't rename them with the bio- extension.)
  • Fix NMatrix issue #151, by getting NMatrix to start compiling with the latest version of LLVM. This task actually involves no C or C++; there's a bug in extconf.rb which prevents it from finding the correct compiler version. NMatrix can't compile without certain C++0x and C++11 extensions, and so a more-recent-than-default compiler must be available. It works fine with G++ v4.7, but seems to have problems with LLVM. (This task does not mean NMatrix has to compile properly with the most recent version of LLVM. There may be separate issues that need to be resolved. Your task is only to make sure that the extconf.rb can find the correct compiler.)

Documentation & Training

  • Create a git repository template for an empty Ruby gem to supplement the instructions listed below. It should also follow the SciRuby gem inclusion draft guidelines.
  • Clean up the C, C++, and Ruby function comments throughout NMatrix so they render in beautiful HTML when RDoc is run. Each source file is worth one task. John Woods, Colin Fuller, and Carlos Agarie can mentor for this task.
  • NMatrix non-API method documentation. Many of the methods throughout the C++ extensions for NMatrix lack clear documentation on parameters, what they return, and sometimes even what they do; this makes it harder for new contributors to jump in and start coding. Pick a less than fully documented method, explore what it does, and add documentation clarifying what you've figured out. NMatrix mentors can suggest simpler or more complicated methods, depending on how deep you want to dive into the code.
  • Write instructions in this wiki for creating a simple Ruby gem with no C or Java extensions. John Woods, Colin Fuller, or Pjotr Prins can mentor for these tasks.
  • Dependent Task: Write instructions for creating a Ruby gem with a C or C++ extension. Use NMatrix as your model.
  • Dependent Task: Write instructions for creating a Ruby gem with a Java extension. Use Ruby-Band as your model.
  • Create video instructions (kind of like a Railscast) on how to install NMatrix and its dependencies (e.g., ATLAS). The instructions have already been compiled in the NMatrix wiki. You just need to try them out yourself and walk people through it on different systems. If you need access to a Linux machine or something similar, you can ask the mentors. Anna Belak can mentor for this task.

Outreach & Research

  • Find an answer to this StackOverflow question about the volatile keyword in C++. Colin Fuller will mentor for this question.
  • Find an answer to this StackOverflow question about Travis-CI and GCC versions. Colin Fuller will mentor for this question.
  • As a preliminary task, research Cucumber and other test frameworks. Add to NMatrix issue #150 information on best practices for standardizing our testing framework. Anyone can mentor for this task.
  • Ensure all of the SciRuby gems meet the proposed standards for inclusion in SciRuby. Keep track of what needs to be changed. We will generate additional tasks based on the outcome of your research. John Woods and Pjotr Prins will mentor for this task.
  • Find a simple algorithm for Cholesky decomposition on sparse matrices. You should use Google Scholar as your resource. The algorithm should not be a parallel algorithm. Ideally, it should be useful for linked-list matrices or Yale matrices (Yale is preferable), which are also known as CSR matrices. Anna Belak and Alex Emly can mentor for this task.

Quality Assurance

  • Development on most Ruby projects is test-driven. That is, people write specs describing how the code should behave; and then go back and write the code. We need someone to rewrite the NMatrix specs as outlined in the NMatrix issue tracker. Currently, they're organized by features (roughly on the basis of when we added features). Instead, they should be organized by Object#method. Mentors for these tasks are John Woods and Colin Fuller.
  • See the research task above on researching Cucumber and other test frameworks prior to embarking on one of these tasks.
  • Each existing spec file rewritten counts as a single task (13 files/tasks in total).
  • Find a bug in any SciRuby project and write a spec which demonstrates the bug. Send a pull request. The spec should be written as outlined in NMatrix issue #150, and according to the research task mentioned above. The mentor for this task depends upon where you find the bug.
  • Stress tests for NMatrix code. NMatrix has a lot of back-and-forth between ruby and C++ code, and this sometimes leads to subtle bugs (for example, bugs that only happen when garbage collection runs at a particular time) that aren't caught by the unit tests because they only show up on long-running or complex programs. Pick a functionality and write stress tests that perform that function many times, on huge matrices, etc. Try to break things in unusual ways. (Keep these separate from normal unit tests so that the long-running tests don't get run with every commit.)

User Interface

  • Create a new gem called plotrb-ui, and using the Rubyvis-based SciRuby::Plotter module in the old SciRuby gem as a model, try to create a very simple GUI for Plotrb. Basically, when people edit a plotrb file, the plot should update. Believe it or not, this is a pretty simple task — most of the work is already done in Plotter. If you don't want to create the gem structure, talk to John Woods, and he'll do it for you or show you how.
  • Write a Plotrb function and rake task / generator for quickly creating jsfiddles for plot code. Zuhao can help with this.
  • Update our website to include a Like button for our Facebook page. John Woods can help you with this, and you'll need to ask him for instructions on how to edit our website via github pull requests.
  • Develop standard 'stylesheets' for people wanting to make pretty plots in Plotrb or Rubyvis. How thick should the lines be? What fonts look good (serif versus sans serif)? What about the rules (the axes and such)? What about stroke versus fill? This topic might also fall under the UI category, as we expect some coding will be required and you might be able to devise some shortcuts for Plotrb as well. It's divided into several individual tasks.
  • Preparation: Devise a simple Plotrb API for applying a stylesheet to plots. Research/design for this task is worth one point; implementation is another point. Zuhao will mentor for these tasks.
  • Screen plots: Devise a stylesheet for screen plots which can be applied with the API.
  • Print plots: Devise a stylesheet for print plots which can be applied with the API.

Issue trackers which have tasks listed

These primarily contain tasks in the categories Code, Documentation, and Quality Assurance. While any issue is a valid task, mentors have -- as much as possible -- tried to mark issues by difficulty level.

Note: you may notice many of the projects here have the prefix bio-. This refers to Biogems and does not mean they are exclusively biological packages.

Clone this wiki locally