Post Midterm Evaluations

Hi readers,
Finally Midterm evaluations have passed and fortunately I have successfully passed them. As I mentioned in my previous post, phase1 of the project was about to complete as only the testing part was remaining and I am happy that the code is now passing all the tests successfully(sqlite is still failing). Although the code is passing all the tests successfully now but as always there is a problem. Earlier, the styles were stored as python files and all that style manager had to do was to look in certain paths to check for any new styles. As styles are now stored in the database and the testing layer resets the database after each test, we now need to populate the default styles into the database after each test(as create_list function in app/lifecycle.py which is being used in a number of tests requires the 'Legacy Default' style). This has made running tests painfully slow. Earlier running all the tests took about 15 minutes to complete and now it is taking approximately 55 minutes to get completed. Finding a solution to this problem is now at the top of my to do list and I hope that I will be able to find a solution soon.
Besides this, I have started to work on the phase2 of the project(REST API). First step in this direction is to decide where these resources will live in the tree. I am having some ideas and soon I will be discussing them with Barry and others.
There is one more that I forgot to mention that I have again made a small change in the design. As mentioned in earlier posts, styles which used to represent a complete set of attributes are now just a stack a stylets don't need to contain all the styleable attributes.
I am very much excited and ready to get most out of this summer. Stay connected for more.

Thanks,
Harshit Bansal

First Progress Report & Future Plans

Hi readers,
This post is going to be a short one focusing on giving an overview of the work done from the starting of the coding period to the work foreseen up until the next week that is the end of the mid term evaluations. It has been quite some time since the coding period has started and my project has made an ample amount of progress during this period. So let's get started:
I had divided the project in three phases:

• Phase1 : Changes in mailman core.
• Phase2 : Implementing the REST API.
• Phase3 : Front end(Postorius).

Of these I had proposed to complete Phase1 by the end of Midterm Evaluations(i.e., 27th June) and with about a week in hand I am pretty sure that I will be able to complete it according to the proposed timeline.
Work done so far:

• Add new IStyleable Interface(Done): https://gitlab.com/_Harshit_/mailman/tree/IStyleable_Interface

• Design and implement:

1.  IStylet interface(Done): https://gitlab.com/_Harshit_/mailman/tree/IStylet_Interface
2.  IStyletManager interface(Done): https://gitlab.com/_Harshit_/mailman/tree/IStyletManager_Interface
3.  IStyle interface(Implementation part done, testcases remaining): Will be done as soon as the two default styles get ported.
4.  IStyleManager interface(Implementation part done, testcases remaining):Will be done as soon as the two default styles get ported.

• Port the two default styles: Currently working on this.

• Refactor and make some changes in the implementation IMailingList: Almost done. Requires testing which will be done as soon as the above mentioned three works get finished.

Future Plans:

From the next month(coding period 2, three days reserved for tiding up code, make up for any delay and to recieve approval from mentor), I am planning to start working on the implementation of the REST API and will try to complete it within about one and a half week after which I will start working on Phase3(Postorius). I am thinking of submitting the two merge requests related to the phase1 and phase2 at the end of phase2 so that if I feel a need to make some changes in the core while implementing the REST API I would be able to do that.

Stay connected for more.

Thanks,
Harshit Bansal

New design explained

Hi readers,
This post mainly focuses on the design that my project now follows. Firstly, I am going to give you an overview of my previous design and then going to mention the changes that the new design introduces. So let's get started:

So what was the Older design?

This was the design that I proposed earlier in my proposal. A style was considered to be describing a complete set of styleable of attributes. A user can either create a new style or inherit from an existing style and make changes as per the requirements. The inheriting style will also reflect any changes made in the parent style. A style was supposed to have three levels of viewabilities:

1.  System-wide viewability: Style is visible to all the lists.
2.  Domain-wide viewability: Style is visible to the lists present in a specific domain to which the style is associated.
3. List-wide viewability: Style is visible to only a particular list to which the style is associated.

Not only this all the styleable were divided in three categories:

1. Site owner level attributes: Only a site owner would be able to set these attributes.
2. Domain owner level attributes: Only site owner or the owner of the domain to which the style is associated would be able to set these attributes.
3. List owner level attributes: Only site owners, owners of the domain in which the list is present or the owner of the list to which the style is associated would be able to change these attributes.

Mutability: A style can be made immutable. Once set to immutable, any of its styleable attributes can't be changed by anyone and it can't be set to mutable again.

Style Deletion: If a user deletes a style which is parent of another style then that style would only loose its presence in the list of styles visible to the user but it will not be deleted from the database till any of its child is present in the database. As soon as all of its children are deleted from the database then that style will also get deleted.

So what changes does the new design introduces?

Earlier, a style which was supposed to be describing a complete set of attributes continues to do so but now instead of acting as a container for all the styleable attributes, it now acts as a stack of partial set of attributes known as stylets. These stylets contain only a partial set of attributes describing only a handful of settings that the user wants to change in a style. A stylet when applied to a style changes the value of the common attributes of all the previous stylets.

Inheritance: A style can still inherit from another style. The inheriting style(and consequently the mailing list using that style) will reflect any changes made in the parent style.

Viewability and attributes categories: Both styles as well as stylets are having same three level of viewabilities, same as before and attributes are also categorized same as before.

Deletion: Earlier a user was allowed to delete a style even if it is was parent of some another style but now a style can be deleted only if it is neither being used by any mailing list nor by any of the style. Similarly, a stylet can be deleted only if it is not in use by any of the style.

Advantages: Makes modification of style easier since the user can now change a handful of attributes that he wants to without caring for other attributes and also apply the same modification to other styles as well.

Stay connected for more.

Thanks,
Harshit Bansal

Pre Midterm Evaluation

Hi readers,
It has been a long time since my last post, in fact I have missed the deadline for my first progress update. I am sorry about that. It was because my project was lagging behind the timeline due to some design and it became my first priority to get the project back on track and I was so much busy in doing so that I almost forgot I also have to maintain my blog. As all of us know, coding period phase 1 has come to end. It was a great time involving intense discussions, coding, roadblocks as well as brainstorming and now its time for midterm evaluations.

Discussions:

During this period, I had an intense discussion with Barry. In first week of the coding period, I was working to implement the new IStyle and IStyleManager interface according to my proposal. While implementing the new IStyle interface I felt that in order to ensure that the attributes dictionary passed to the __init__ method contains all the styleable attributes(since previously, I was assuming styles to be a complete set of attributes), I will need to have a list of all the styleable attributes. So I decided to go for code refactoring by moving all the styleable attributes to a new interface 'IStyleable' interface which then can be extended by the existing IMailingList interface and the new IStyle interface. I asked Barry for his permission for this refactoring and he agreed but he also said that it would be good if I make styles composable in terms of small set of attributes(stylets) as the current IStyle interface supports. We then had a long discussion on what would be the behaviors of these new stylets and how can these stylets be used to compose styles. Subsequently, the new design was finalized(I will be explaining the new design in my next blog post) and I got to realize that my original design was having a large number of shortcomings that I would have to face while implementing the REST API and the frontend.

Brainstorming:

Now I needed to devise a mechanism such that if an user updates any stylet or style, then, any mailing list using either the updated style or a style composed of the updated stylet will get updated automatically. For accomplishing this task I was having an option to override the __setattr__ method and trigger a stylet/style updated event whenever this method is called but as this would trigger the event for each and every assignment, an instance managing a large number of stylets/styles would come to its knees within seconds.
After wasting some time in devising some way of solving this problem, I cam to know about SqlAlchemy's mapper level events and after reading their documentation, I decided to use them.

Roadblocks:

Unfortunately, during this period I faced two major roadblocks:
1: During the time of discussion, Barry was busy in PyCon 2016 and was not available on IRC for a real time discussion. So I had to contact him via email which was very time consuming and I was not able to make much progress during that week. But I have to say that in-spite of being busy, Barry tried to answer all of my queries as clearly and as fastly as possible(Thanks to him!).
2: When I was testing the new event system I came to know that even after changing a style/stylet the events aren't getting fired. Then after spending some time in trying to figure out the problem, it came to my notice that if I fire a query after changing a style, the events are fired in proper order. I was unable to figure out any possible reason for this kind of behavior. I found a solution to this problem on stackoverflow. Events in sqlalchemy are fired when a flush occurs and a query causes an auto-flush to be triggered which causes the events to be fired. It took about three days to figure it out and caused a lot of frustration.

Overall it was an amazing experience to see my project taking shape and solving those roadblocks was the most interesting part although it caused some frustration as well but I loved it. Keep connected for more.

Thanks,
Harshit Bansal