Saturday, June 25, 2011

GSoC 2011 Melange Testing Project: CP W5

Hi,

This was quite a busy week. Learned a lot and worked a lot. I worked on writing the tests for soc.logic.tags and soc.logic.models.base. I had attempted to test soc.logic.tags during the pre-GSoC era but failed because I did not understand properly what 'scope' and 'fields' parameters were. I asked Madhu what a 'scope' is and he explained it to me that it was a solution adapted by Melange during the early days of development to define a relation such as a GSoC project belongs to a Student. So, a GSoC project entity was scoped under a Student profile. But, as the developers understood more about the Transactionality and other stuff in GAE, they switched to using 'parent' argument of an entity to define the scope. But, scoping will stay for tagging.

   Earlier during the week, after Leo reviewed my patch for soc.logic.accounts, I pushed the code without first updating my local repo. So, I first pushed the patch and then pulled. But, then I could not find the test I had written in the online repository. So, I pushed it again and as a result to this, I ended up creating two heads in the repository. Sverre asked me to take care of the extra head I had created. I did not know how to do that. So, I googled and asked some friends. Some suggested using the 'strip' extension, 'merge' and some 'mercurial queues'.
Ultimately, I asked Madhu how to revert what I had done. He looked at the case and asked me if I do not rebase my patches after pulling. rebase!!!???What is it??. I then asked him what rebase here refers to. He gave a very nice tutorial on the concepts behind rebasing and the two schools of thought which I will never forget, the 'Purists' and the 'Whatever-ists'. :). I like Madhu's way of explaining things. Things get so easily printed in the mind.

   What I learnt about the 'parent' argument from the discussion with Madhu, helped me to extend the old tests for soc.logic.models.base authored by Sverre and Leo. The tests reported errors when I ran because it could not find test_model module which I also thought does not exists and may be it has been removed. So, I defined my own dummy class TestModel extended from soc.models.base.modelWithAttributes, added some more tests to the module and submitted them for review. After this, when I was looking for other module to test, I saw that there was a test_model in old_app.soc.logic.models and this was the reason why it gave ImportError. So, lets see what Leo says :).

 I now plan to re-use the old tests which Leo had written last year. The goal of my project has been re-scoped to write the unit tests until mid-term evaluations. I had written in my proposal that I will start writing functional tests in June. But, there are modules which have to be unit tested before. So, the target until mid-terms is to add as much unit tests as I can.


Monday, June 20, 2011

GCI 2011 GCI with New Architecture

Hi all !

This week I have committed the GCIProfile and GCIStudentInfo models.And currently I'm working on the script to convert GCIStudent data to GCIStudentInfo and as I had some troubling understanding certain things I spent a couple of days in going through the Oreilly - Programming Google Apps Engine book.I've spoken to my mentors sometime back and got a better idea as to what to do.Instead of querying for the profile that each student entity points while creating the GCIStudentInfo entity, it can be created when the Profile for each entity is created,the parent-child relationship can be obtained easily like this.Besides this I have also written a basic RequestData object that will be created for each request in GCI and will add more properties and fields as we go ahead in the project.The patch is under review along with the script to convert roles and update references in the models.This week I haven't worked upto the mark.I will finish the conversion works and start with views at the earliest this week.

GSoC 2011 Integration with External APIs: OAuth Demo - Week 4

This week i'm finishing Open Auth integration and will start to work on proposal syncing with Google Documents next week.

A demo view that uses Google Docs Service is available here. I made a few modifications for OAuth workflow diagram that you can see here.


After login process is complete, Google documents of user are listed.
Currently, tokens are stored by memcache. Access tokens are long-lived. So i marked a TODO to store access tokens in datastore (with Sverre's suggestion). Memcache is not a convenient way to store  a token for such a long period. After talking to Mario (my mentor), we decided to put a 'remember me' checkbox with login button, so when user logs out access token will be preserved for next login ( that  is also current behaviour). These are changes that i can work asynchronously while i work on proposal syncing feature.

Proposal syncing feature is the first deliverable of my project. There are few potential problems awaiting:
  • Integrating a full-html document which also has seperate image, css files. 
  • To sync proposal without user signs to site, a task must be implemented to sync proposals when user is offline.

GSoC 2011 Melange Testing Project : CP W4

Hi!
I had submitted two patches last week: one for test of app.soc.logic.dicts and the other for app.soc.logic.accounts. There were lot of mistakes and issues pointed out in the review. I have corrected soc.logic.accounts and submitted it again for review today. I also missed some functions to test in soc.logic.dicts and will do it this week.
  I wrote the test for app.soc.logic.system this week and I had a long discussion with Madhu whether to use DjangoTestCase or unittest.DjangoTestCase. Madhu suggested using the DjangoTestCase and I insisted that I could test the functions with the help of unittest.TestCase itself. I had to test the soc.logic.system.getHostname(data=None) function and for this I needed a data object which had a 'site.hostname' attribute. After some grepping and exploration, I came to the conclusion that it should be a soc.views.helper.request_data.RequestData() object and the 'site' should be a soc.models.site.Site() entity which Sverre told me. But then I had a problem in instantiating the Site entity and the traceback reported that a link_id property is missing. So, after struggling for some time I told Madhu the problem and he referred me to test_utils.DjangoTestCase which had a site and data attribute which he said I use in my tests. He also said that RequestData entity should be populated and seeded to efficiently test it. My point was that all the entities of RequestData object are set to either False or None and also I do not need all of its attributes in testing. I only need the data.site and data.site.hostname attributes and this I could accomplish without using the DjangoTestCase and directly handling the RequestData and Site objects. Finally he asked me to go ahead and write the test with unittest.TestCase.
    85% of my time is spent on reading codes and there are multiple windows that remain open almost all the time. I have to hibernate my system to avoid opening so many windows again.
   I did not do much coding this week but hope to do more this week. Me and a friend of mine are planning to participate in ACM-ICPC regionals this year. So, we spent most of the time in studying for ICPC only.