Wednesday, July 29, 2009

GSoC09: Statistics module 6th weekly report: idling, than back to work :)

It's been a while since my last post. The reason is that I had to travel to Italy (and then back to Dublin) for an University exam that unfortunately kept me busy more than I foreseen.

During those days, I was basically in sync with dev list posts and almost always idling and pingable in the irc channel. So, even if not so productive, at least I mantained constant communication with the community.

Apart from that, I've made a very very little commit for a style fix in Javascript and sent some patches (that Pawel is reviewing) to the mailing list, just to be sure that my first contact with Python side architecture is not totally clueless :P

I've started again to be up and running for a part of the last week, in which, basically, I've generalized a bit the code to produce a visualization in a widget, so now the visualization can be selected from a drop down menu. In this way, even if every widget is created as a Table, it can be switched later to a Pie Chart, a Geo Map or an Area Chart.

Apart from that, I coded (and still coding right now) the Javascript side to have the Organization Home Page map (with markers for students/mentors and their links) finally working... Lennie, expect the patch soonish :P

Tuesday, July 28, 2009

GSoC 2009: GHOP - Ninth Week Status Update!

Hello everyone,
A week of fair productivity again. Started out this week with implementing the actions that must be available to all users. The complete GHOPTask workflow has been implemented now. The code is also up and running in my demo instance at

To explain a bit on how it all works, any user irrespective of whether he is registered as a GHOP Student (except Org Admins, Mentors and Program Host) can request to claim the task, if he has not claimed a task before. Once this is done, the task is locked down and no other user can claim it. Also let us say there is a limit of Max 1 task simultaneously as it is with GHOP. So the User cannot request to claim any more tasks. This is true for registered students also. Now a Mentor/OrgAdmin of that org(irrespective of who created or modified that task) can accept/reject the request. The student can also withdraw from the task. If student withdraws or Mentor rejects the task goes to reopened state.

If the student's claim is accepted, an automatic update Appengine task is spawn, so the task state changes to Action Needed if no work is submitted by student, there by extending the deadline by 24 hours. And after this deadline also is passed the task is automatically reopened by another Appengine task which will be spawn by the previous ActionNeeded Task.

However if student wishes to submit his work, he can provide a link to his work in the Submit Work box along with the comment and action. The Mentor either accepts the work by Closing down the task or requests for more work, optionally extending the deadline. The student in this case can again submit his work.

Along with implementing this workflow, I have fixed a few 505s this week and mentor_list field validation on task edit form. Also the approve button doesn't appear for the tasks that have already been approved on the task edit form. I am currently working on subscriptions and sending out notifications to the users subscribed to the task. This will be over by this weekend and I will start working on implementing views for tags based on taggable.

Monday, July 27, 2009

Ninth Week NewsFeed Update

With the code for the NewsFeed module nearing completion, I'm beginning to focus more on testing and refactoring to increase the readability and general orthogonality of the NewsFeed code. The newsfeed module is unlike some of the other components in the codebase in that outside of the core model, logic, and view code, there needs to be code snippets in each logic and view module that incorporates newsfeed in some way.

That famous Voltaire quote that "the perfect is the enemy of the good" is very relevant to the testing stage of development, since while it can be reasonably easy to be sure that a feature is 95% bug-free, determining that it is 100% bug-free is exponentially harder, since it requires every possible permutation (or at least every significantly different permutation) to be tried, which makes it practically necessary to have automated testing in place. This is especially true for an open source project, where someone else may likely pick up where you left off, and you don't want them to treat your code contribution in the cargo cult manner.

Seed_db serves as a very basic smoke test, since I've added onCreate hooks that in turn create news feed items. While this smoke test does test the creation of new feed items, it does not test the consumption of news feed items, which is at least as important as their creation. Therefore I'll be working on unit tests this week, modeled after the test examples already in the codebase.

I've also done some refactoring, with help from Sverre's code review last week. Instead of a feed item created for each sender-receiver pair, now there is only one entity created for each feed update, with a list of receiver keys. This actually makes it easier to determine which updates should be sent to which users, and reduces the amount of entities that need to be created. Because this makes the feature more simple, it also makes it likely to contain less bugs, and makes it possible to reduce the amount of testing and maintenance required.