GCI 2011 GCI with New Architecture

Hello all,

Apologies for the late blog post.This week I have started off with the url patterns for GCI and Lennard suggested that I move the common functions to the core and leave the GCI related constants in that module and I have done that.I then went onto the GCITask view but before that I had to add another method to the access_checker to check if the task is published or not but looks like, I still need to modify this method a bit to include other cases too.I still have to retrieve work submissions for the Task view and form to edit the task and to subscribe the task.And me and Madhu had a small discussion about the templates and we decided to use the gsoc templates for now and make modifications where needed and use gsoc's css and JS till we get the designs.Meanwhile my other patches have been reviewed.First I had to refactor the gsoc redirects module, as many of the redirects are moved to the core and some methods have to be overridden to set the _url_name.And I was asked to make a little change to the gsoc access_checker as it's DeveloperAccessChecker should also inherit from AccessChecker, and the same was done to the gci access_checker too.Made required changes to the other patches as mentioned.I haven't spent enough time last week, as I had to help a Professor with his coursework and I really could not avoid it, I discussed with him today and took permission till the end of August, So I will cover up this week and will spend extra time on my project.

GSoC 2011 Melange Testing Project: CP W6

Hi,
In the last conference call, I reported my problems to Sverre that most of my time is spent on reading the code itself and that I had problems in deciding about the use cases when writing tests. My productivity has been very low till now and I have written atmost two tests per week. This week I worked hard and I have written tests for all the modules in gsoc.logic and soc.logic except three modules. Though the tests are under review and they need drastic improvements, I have now become comfortable in deciding about the use cases and writing tests. I had a discussion with Leo and he told that I was unnecessarily using DjangoTestCase. I can use seeder_logic and inherit my test classes from unittest.TestCase and this will improve the performance and speed. I was using DjangoTestCase to avoid instantiating the GSoCOrganization, GSoCTimeline and other entities which I could use directly when inherited from DjangoTestCase. But seeder_logic is more useful and its also used in DjangoTestCase. So, I corrected the test for soc.logic.host and used seeder_logic to seed the entities and it was working fine.
     
I tested a total of 8 modules in this week and the coverage has increased by 4%. The present coverage of the tests in my local copy is 70%. The coverage will increase more when I write tests for the soc.views. 

My work for this week is to correct the previous tests, test the remaining three modules in gsoc.logic and soc.logic and then start the view tests.I hope to finish all the logic tests before the mid-term evaluations.

PS: Mercurial queues are AWESOME. Salute and gratitude to the guy who wrote that extension. :)

GSoC 2011 GUI Overhaul: Typical PA Workflow and Admin Dashboard Usage

Hi everyone,

A week ago I asked Madhu about the typical workflow for PA (Program Admin). Madhu was so kind to explain the workflow for PA. I'll summarize the workflow and usage of admin dashboard by the PA. The followings are ordered things that should be done by PA to organize the GSoC program:

1. Initialize the program settings such as program name, document page, or timeline of the program. These settings already provided by site.py and timeline.py views.
2. Invite organizations to participate.
3. Create the organization application survey. I believe this is related to what Madhu's did for survey with form builder. I can easily add the url inside the new admin dashboard to refer to the form builder.
4. PA and her team discuss the organization selection internally.
5. Accepted organization announced. I don't know yet if there's a view or task to accept organization.
6. Student signup period. Students begin submitting proposals to organizations.
7. PA can assign slot in this time or before the accepted projects announced. There's a view for slot assignment.
8. PA can check the duplicate proposal. There's a view to trigger the duplicate proposals' task queue. This queue will iterate each proposals and filter the proposals by the same student that would be accepted by two or more organizations. The resolution was done manually by gathering a meeting.
9. PA can check slot transfer by organization and accept/ignore the request of transfer by org admin. There's a view for this.
10. After all organizations solve the duplication status and agree with the given slots. PA can trigger the accept_proposals' task queue. There's a view to trigger accept_proposals queue.
11. PA creates survey for mentors and students. There's a survey builder committed by Madhu.
12. PA freeze the program after the final term.
    

I don't know yet what the task needed by the PA after creating the survey. But the typical workflow should be like the list I mentioned above.

GSoC 2011 Integration with External APIs: Learning new tools - W5

This week i was busy with fixing my patches. Madhusudan suggested me a tool to create mutable changesets : Mercurial Queues (aka MQ). It was  not possible to work on multiple commits without actually commiting them. This great extension makes this possible. You can create a patch, edit it, then create new one and return back to previous patch to edit it. (Patch is a mutable changeset) I benefit from this mostly in two ways : First as i am new to community my commits need to be reviewed. When i send a patch for review, i can start to work on another while first one is in review and mutating. Second reason which also will make me use MQ even after i'm good enough to send my commits without review is it helps divide and code! I can divide a job into parts which are slowly growing (each part corresponds to a commit). So i have a working job which is not complete but each parts are still growing and making working job better. Instead of finishing each part in order and trying to make them perfect as i dont have chance to go back, i'm working on every task at the same time synchronously. I also wrote on my Turkish blog about MQ :)

Another tool i was introduced was {{less}} which helps writing CSS in a hierarchical style, without requiring to write full selector path for each block. It also allows defining variables which prevents redundancy when using same values multiple times. It's clearly more programmers way to CSS.

While being little late for proposal syncing feautre. I still could find some time to think on it and send a mail to community to discuss on it. There is no harm to copy/paste my current idea here :)

• When user goes to '.../proposal/submit...', represent a sub-page with two buttons : Edit HTML, Sync with GDocs
• Go to a different page for each selection, each represents different form. (e.g. '/proposal/submit/gdocs', '/proposal/submit/default') One page requires to login GDocs and a gdocs flag will be True for proposal entity after saved. 
• For updating part, 'edit proposal' link's destination will be changed with regards to proposal's gdocs flag (either go to '/proposal/update/gdocs/id' or '/proposal/update/default/id').
• Widget 'GDocs Link' will have a 'sync now' button near it. When user pastes link to field and presses "sync now" button, an ajax request will be executed. Text area 'Content' (which is not editable) will be updated with result of that AJAX request. So actually, in server-side, we won't process document link again and treat form like its content edited by hand. 

GCI 2011 GCI with New Architecture

Hello all !!

This week I have worked on the views after completing the conversions tasks.I first started off with RedirectHelper for constructing redirects in GCI.Each of the methods in this helper returns the RedirectHelper object after setting certain parameters like _no_url, url_name, _url, args and kwargs.The clear method clears the current internal state and urlOf method returns the resolved url for name using current internal state for args and kwargs.At this stage certain field from GSoCProgram like about_page, events_page, events_frame_url, connect_with_us_page etc are required for GCI too and hence they are moved up to soc.models.program.Program.The RequestData patch for GCI got reviewed and I am about to commit it now after making a couple of changes.
I then proceeded to the Access Checker for GCI.For this not much is needed at the moment and more methods will be added as we move on with the views.For now, I have to written a couple of methods one is access_checker.Mutator.taskFromKwargs which sets the task entity in the RequestData object and the other is access_checker.AccessChecker.isTaskInURLValid to check if the task in the url exitst or not.After acess_checker I have moved onto site menus for GCI.I was told that I can use the same site menus as that of GSoC for now.So I went ahead and have written a smiliar site menus for GCI which contains siteMenuContext to generate URL links for the hard-coded GCI site menu items and Header, MainMenu and Footer templates.I have then finally moved onto RequestHandler for GCI.The render method of the soc.views.base.RequestHandler is overridden to extend the context object with header, mainmenu and footer values which are rendered Templates for the current RequestData object.I have now started with the Task view.

GSoC 2011 GUI Overhaul: The Admin View's Design

Hi everyone,

From my previous post I've talked about colorbox approach for admin dashboard. If you want to try, visit my demo instance at http://melange-new-dashboard.appspot.com/ using the following account:

username: melangetestdashboard@gmail.com

password: melangetestdashboardpassword

There are some changes in the JS, CSS and template. Some of these were just new files. I'll talk about code that make a sense to review. Before that, I'll divide the topic into two sections so you can skip a topic that you don't want to read.

Changes in admin's view

If you've tried the admin dashboard from the link that I gave above. You should try to toggle the colorbox or click the "Program settings" link. If you click the "Program settings" link, the dashboard will change its content. The case is the same for "Manage organizations" link. If you inspect the page with firebug, you'll notice that it just switching between div elements. Let's call this a sub dashboard.

So, a link that have sub links at the bottom of its description will point to the div that hidden at that moment, that's a sub dashboard. When we clicked "Program settings", the div with id "program-settings-dashboard" will be shown, the "disabled" class was removed. And the "main-dashboard" will be hidden. I figured out what's the best solution to reorder the links or reorganizing sub dashboard without coupled too many files. So I came up with the idea that these links and sub dashboards should be managed inside soc.modules.gsoc.views.admin. I managed to create a new class named Dashboard that inherits Template class:

class Dashboard(Template):
"""Base dashboard for admin page
"""

def __init__(self, request, data, subpages=None):
"""Initializes the dashboard.

Args:
 request: The HTTPRequest object
 data: The RequestData object
 subpages: Subpages of current dashboard
"""
self.request = request
self.data = data
self.subpages = subpages

def getSubpagesLink(self):
"""Returns the link to other dashboard that appears
on top of the dashboard.
"""
return self.subpages

def templatePath(self):
"""Returns the path to the template that should be used in render()
"""
return 'v2/modules/gsoc/admin/dashboard.html'

def _divideSubPages(self, subpages):
"""Returns the subpages divided into two columns.
"""
middle_ceil = int(math.ceil(float(len(subpages))/2))

return [
   subpages[:middle_ceil],
   subpages[middle_ceil:],
]

Currently there are three dashboards that inherits Dashboard class, they are: MainDashboard, ProgramSettigsDashboard and ManageOrganizationsDashboard. To get you the clear idea, here's the MainDashboard and ProgramSettigsDashboard classes:

class MainDashboard(Dashboard):
"""Dashboard for admin's main-dashboard
"""

def __init__(self, request, data):
 """Initializes the dashboard.

 Args:
   request: The HTTPRequest object
   data: The RequestData object
 """
 super(MainDashboard, self).__init__(request, data)

def context(self):
 """Returns the context of main dashboard.
 """
 r = self.data.redirect
 r.program()

 manage_orgs = ManageOrganizationsDashboard(self.request, self.data)
 program_settings = ProgramSettigsDashboard(self.request, self.data)

 subpages = [
     {
         'name': 'lookup_profile',
         'description': ugettext(
             'Lookup profile of mentor or student from various program.'),
         'title': 'Lookup profile',
         'link': r.urlOf('lookup_gsoc_profile')
     },
     {
         'name': 'allocate_slots',
         'description': ugettext(
             'Allocate slots (number of acceptable projects) per '
             'organization'),
         'title': 'Allocate slots',
         'link': r.urlOf('gsoc_slots')
     },
     {
         'name': 'slots_transfer',
         'description': ugettext(
             'Transfer slots for organizations'),
         'title': 'Slots transfer',
         'link': r.urlOf('gsoc_admin_slots_transfer')
     },
     {
         'name': 'duplicates',
         'description': ugettext(
             'Calculate how many duplicate proposals'),
         'title': 'Duplicates',
         'link': r.urlOf('gsoc_view_duplicates')
     },
     {
         'name': 'manage_organizations',
         'description': ugettext(
             'Manage organizations from active program. You can allocate '
             'slots for organizations, manage invitations for '
             'org admin/mentors, and withdraw/accept students/mentors '
             'from various organizations'),
         'title': 'Manage organizations',
         'link': '',
         'subpage_links': manage_orgs.getSubpagesLink(),
     },
     {
         'name': 'reminder_emails',
         'description': ugettext(
             'Send reminder emails for evaluations.'),
         'title': 'Send reminder emails for evaluations',
         'link': r.urlOf('gsoc_survey_reminder_admin')
     },
     {
         'name': 'program_settings',
         'description': ugettext(
             'Edit program settings and timeline'),
         'title': 'Program settings',
         'link': '',
         'subpage_links': program_settings.getSubpagesLink(),
     },
     {
         'name': 'participant_locations',
         'description': ugettext(
             'Show all participants (students and mentors) in a '
             'clusterer map. You can also view a single profile map '
             'after clicking the marker.'),
         'title': 'Participant Locations',
         'link': '#'
     },
     {
         'name': 'report_statistic',
         'description': ugettext(
             'Reports and statistics of program'),
         'title': 'Report/statistic',
         'link': '#'
     },
 ]

 return {
     'title': 'Admin Dashboard',
     'name': 'main',
     'subpages': self._divideSubPages(subpages),
     'enabled': True
 }


class ProgramSettigsDashboard(Dashboard):
"""Dashboard for admin's program-settings-dashboard
"""

def __init__(self, request, data):
 """Initializes the dashboard.

 Args:
   request: The HTTPRequest object
   data: The RequestData object
 """
 r = data.redirect
 r.program()

 subpages = [
     {
         'name': 'edit_program',
         'description': ugettext(
             'Edit your program settings such as information, slots, '
             'documents, etc.'),
         'title': 'Edit program',
         'link': r.urlOf('edit_gsoc_program')
     },
     {
         'name': 'edit_timeline',
         'description': ugettext(
             'Edit your program timeline such as program start/end date, '
             'student signup start/end date, etc.'),
         'title': 'Edit timeline',
         'link': r.urlOf('edit_gsoc_timeline')
     },
 ]

 super(ProgramSettigsDashboard, self).__init__(request, data, subpages)

def context(self):
 """Returns the context of manage organizations dashboard.
 """
 subpages = self._divideSubPages(self.subpages)

 return {
     'title': 'Program Settings',
     'name': 'program_settings',
     'backlink': {
         'to': 'main',
         'title': 'Admin dashboard'
     },
     'subpages': subpages
 }

To set the links, we need to set it into subpages context. If you want a link to another dashboard inside MainDashboard, such as "Program Settings", just create another class that inherits Dashboard, supply the backlink to refer back to the parent's dashboard and set the subpages of its own dashboard inside the new class. In the parent dashboard's subpages context supply the subpage_links to indicate this is a dashboard link. How about the icon itself? This is where the CSS rules. The name you supply for each link inside the subpages content will be rendered as a class name of the link's container. Everything's that related to the style of admin dashboard is defined inside v2/gsoc/admin.css file. I got the icons from Tango Desktop Project which is licensed under GPL.

The next thing that you might need to know is the addition of colorbox base layout. A colorbox base layout is minimalistic template without sidebarmenu and header. The rest is the same. To make any page rendered in colorbox layout, you need to pass cbox query string. The RequestHandler will take care the base layout. Each page that extends the base.html template need to change the extends tag to base_layout, {% extends base_layout %}. The rest of changes inside soc.modules.gsoc.views.admin were new handlers with list.

What's done and what needs to be done or in-progress

I promised to finish the admin dashboard before the mid-term. This means the code it self should be reviewed lately in this week. The scope for the deadline before the mid-term was a fully functional admin dashboard that the mockup already given before. Okay, here are what's done in the admin dashboard:

• New admin's view architecture that I've discussed in the previous section
• Handling colorbox template
• A few handlers inside soc.modules.gsos.views.admin

Here are what needs to be done and in-progress:

• Submit my code for review, possibly after writing this post.
• The test_slots was failed because I created new template and changed the list template for accepted organizations. I refactor the list for accepted organizations inside admin's view so other handlers can use it. I'll fix the test after my code being reviewed.
• Adding test for soc.modules.gsoc.admin. By looking at other view tests, it just a test case to make sure the template is rendered with the right context.
• A participant locations to mark all participant into a single map using MarkerClusterer. This is not a critical requirement and can be skipped.
• Refined toggleable list patch as suggested by Mario.

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.