Friday, June 18, 2010

Week 4: Final touches to User Pages

It is going to be almost a month since GSoC has started. I have made decent progress. The almost-finished version of User-Page is now at

I have created a dummy program,org,org_admin,mentor, a couple of students. I am still working on adding the "past projects" data for some of my dummy students and mentor roles so everyone can take a look soon.

I have enabled mentor sign up and student sign up currently. So everyone can sign up and meddle around with it. There are bound to be bugs turning up, please let me know if you find something weird happening. Also, suggestions and feedback is welcome.

I am facing a teeny weeny delay with the User tags and profile_picture uploads which will be integrated into my GAE over the weekend.

Over the weekend:
  • wind up remaining functionality issues
  • do some testing
Next Week:
  • Start work on the Calendars

GSoC 2010 Data Seeder - Views

My project drifted away a bit from the original timeline due to some unforeseen complications, so I'm now almost a week late. Melange has been built from the ground up heavily supporting the View-Logic-Model layers and in this way reusing a lot of code. However, so far, all views and logic classes have been tied up to a specific entity which dictates all this behavior.

Unfortunately, the data seeder project doesn't involve any specific model in order to build functionality around it, but rather it collects data regarding all other models in the application. So there's now a need for a new type of view that is not centered around any model. Initially, I thought that setting up a new general-purpose view is as simple as registering some patterns and some methods, but this doesn't seem to be the case. Instead, some of the code in soc.views.models.base had to be adapted to a new type of view (soc.views.base) that is not model-centric. I have used this new type of view to create the backend side of the AJAX API implementation. An example of the JSON data that is collected by the backend can be seen here [0]. The current version might seem a bit too big (mainly because the list of possible countriy choices is repeated for several models), but that might change.

Next stop: Build a basic web interface

Sunday, June 13, 2010

GSoC 2010 Melange Testing Project: Week 3 of the Coding Period

Last week, I finally got Django test client working with the help of Sverre (my mentor). In this week, however, another problem arose. For some urls, e.g. /cron/poke, the response returned by the test client is a Django http response object; for other urls, e.g. /user/show/a_user, however, the response is a dict. After failing to figure out what had caused the problem, I asked Sverre for help again. Sverre suggested that it might be due to the stubout code (pymox) in tests/app/soc/views/models/ After I commented the code, however, the problem still did not go away. Later, Sverre found that the problem was due to that the fact that the stubout in tests/app/soc/modules/ghop/views/models/ has not been unset. So, he added the unset code to tearDown methods and also helped me reviewed/improved and merged my code of refactoring the stubout code into a helper class. Thank you very much, Sverre!

After solving these problems, I started to do view tests for soc.views.models.user using Django test client. I have almost finished it. Yesterday, I pushed the code into my online clone. Today, I asked Sverre to have a quick look to see if it is alright and he was satisfied with it. Though I am still behind my original schedule, I am confident that I can catch up soon. This is because I have solved all major obstructions and have finished adding tests for one logic (base) and one view (user) so that I can follow similar patterns to add tests for other logic and views very quickly.

This week, I also came across the trace module of python when I tried to find another problem I met. It can be used either in command line with python -m option or in your program. This module save you time to code a call back function for sys.settrace by offering some common functions. One useful function is to trace the execution flow of your program. It traces every statement, so be aware the output could be quite large. For example, the output of tracing a single statement of Django test client in Melange testing environment is more than 100MB. Another disadvantage is that the output only shows the module name without package path which could confuse you when you have many modules with the same name or you have a big project and do not know the package of every module. Another useful function is to trace calls. The output of this one is quite small compared with the first function and also has full package path. This function, however, is not perfect either. The problem is that the calling functions are ordered by their module name rather than by their calling order which is arguably more useful. And you have no options to change the order. Besides, you can only use it in command line.

Document Editor: Week 3

This week I worked on revision implementation. As proposed by Lennard I tried to refactor, but found out that Work is also the base class for Quiz, Proposal, Documentation, Question and Survey. Daniel also proposed to implement revisions as three different models. That's why I decided to leave Work for models that doesn't support revisions and implement separate revision-related models.

In a couple of days I plan to implement logic for revisable models, refactor create function and implement view to list all the revisions.