Hello Readers,
Its been some 20 days of intense discussions, coding, deadlocks, discussions again, confusion, and a moment of discovery. BUT it has been fun altogether.
As I mentioned in my previous blog, the integration part was done, as per me. And I felt things were moving fast, thanks to our preparation and design discussions during the community bonding period. WELL not so early! *silly me* :p .
SOME TECHNICAL STUFF - CAN SKIP
//////////////////////////////
When I actually implemented the message queue part, I noticed that the emails were being archived at only one of the archive using my interface. umm, big problem. I went codebase hunting again, searching through modules, which led to call other modules, further on. Finally, I made a small discovery. There was a python dictionary bring built, with the key_name being the interface name. What this meant was that the interface object created, was being instantiated only once.
Another issue was how to let my interface object know what archive it needs to send mail to?
This led me to intense discussions with Florian,and asking for advice on the developer mailing list. I was suggesting him that we could add a field in the cfg file where the archivers are registered, checking for this field in the IListArchiverSet interface, and changing the dict key for the instance. After some toying around with the mailman core codebase, I overcame this with changing the name. But Florian pointed out that we should go for a more generic design in the interface. This led us to change name for all the interface instances, irrespective of the name. DONE!!! The major hurdle was overcome .
//////////////////////////////
In the above section I mentioned some grave issue I faced, and how we(me and Florian) came out with a solution. Though we still need to discuss this with Barry, but the final solution seems to be somewhere around this.
After this, I restructured my interface code into better functions, and was done with the archiver interface.
Next was the time for test writing. Florian had been pushing for this since the beginning, and I had read about tox and unittest, and even planned about what all tests would be required to be written. But now when I actually set out to write them, I faced difficulties with how I was going to deal with RabbitMQ api calls.
Now "unittest.mock" came to our rescue, and I read a tutorial about it. CONFUSING it was.
I read more tutorials on mock, tried writing the tests, but was facing a block, like a writer's block. I approached people in my college for help on this, and a senior did try to help, but he was in US for intern, so our communication over chat wasn't very effective. 3 days were spent without writing a line of code, but only reading tutorials, and trying to think how to approach. I felt as if this was becoming a mental issue for me, and I was overthinking. Finally I approached Florian with the issue, and he agreed that our case was quite complicated to use mock, and that mock in itself was not very straightforward. Right after chatting with Florian, with somewhat feeling not sorry for myself anymore, I tried a few things with mock, and used tips accross 2 tutorials I had read over n over again. While actually writing tests for the first time in my life, I actually realized how they go a long way in modifying the code structure, and help us modularize things well. FINALLY IT WORKED OUT!!
Next moves were made quickly, with me preparing tox environment file, running nose2 tests, and cleaning out code for meeting pep8 standards. The job was done, and I feel I've well covered the goal I had set for mid term evaluation.
I must say that this journey has caused confusions and frustrations, but always rewarded with new learnings and joy.
I hope to pass the evaluations, and get the most out of this summer.
Thank You
Its been some 20 days of intense discussions, coding, deadlocks, discussions again, confusion, and a moment of discovery. BUT it has been fun altogether.
As I mentioned in my previous blog, the integration part was done, as per me. And I felt things were moving fast, thanks to our preparation and design discussions during the community bonding period. WELL not so early! *silly me* :p .
SOME TECHNICAL STUFF - CAN SKIP
//////////////////////////////
When I actually implemented the message queue part, I noticed that the emails were being archived at only one of the archive using my interface. umm, big problem. I went codebase hunting again, searching through modules, which led to call other modules, further on. Finally, I made a small discovery. There was a python dictionary bring built, with the key_name being the interface name. What this meant was that the interface object created, was being instantiated only once.
Another issue was how to let my interface object know what archive it needs to send mail to?
This led me to intense discussions with Florian,and asking for advice on the developer mailing list. I was suggesting him that we could add a field in the cfg file where the archivers are registered, checking for this field in the IListArchiverSet interface, and changing the dict key for the instance. After some toying around with the mailman core codebase, I overcame this with changing the name. But Florian pointed out that we should go for a more generic design in the interface. This led us to change name for all the interface instances, irrespective of the name. DONE!!! The major hurdle was overcome .
//////////////////////////////
In the above section I mentioned some grave issue I faced, and how we(me and Florian) came out with a solution. Though we still need to discuss this with Barry, but the final solution seems to be somewhere around this.
After this, I restructured my interface code into better functions, and was done with the archiver interface.
Next was the time for test writing. Florian had been pushing for this since the beginning, and I had read about tox and unittest, and even planned about what all tests would be required to be written. But now when I actually set out to write them, I faced difficulties with how I was going to deal with RabbitMQ api calls.
Now "unittest.mock" came to our rescue, and I read a tutorial about it. CONFUSING it was.
I read more tutorials on mock, tried writing the tests, but was facing a block, like a writer's block. I approached people in my college for help on this, and a senior did try to help, but he was in US for intern, so our communication over chat wasn't very effective. 3 days were spent without writing a line of code, but only reading tutorials, and trying to think how to approach. I felt as if this was becoming a mental issue for me, and I was overthinking. Finally I approached Florian with the issue, and he agreed that our case was quite complicated to use mock, and that mock in itself was not very straightforward. Right after chatting with Florian, with somewhat feeling not sorry for myself anymore, I tried a few things with mock, and used tips accross 2 tutorials I had read over n over again. While actually writing tests for the first time in my life, I actually realized how they go a long way in modifying the code structure, and help us modularize things well. FINALLY IT WORKED OUT!!
Next moves were made quickly, with me preparing tox environment file, running nose2 tests, and cleaning out code for meeting pep8 standards. The job was done, and I feel I've well covered the goal I had set for mid term evaluation.
I must say that this journey has caused confusions and frustrations, but always rewarded with new learnings and joy.
I hope to pass the evaluations, and get the most out of this summer.
Thank You
