<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-20 19:25 GMT+03:00 Constantin Mihalache <span dir="ltr"><<a href="mailto:mihalache.c94@gmail.com" target="_blank">mihalache.c94@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 20 October 2015 at 08:38, Laura Vasilescu <<a href="mailto:laura@rosedu.org">laura@rosedu.org</a>> wrote:<br>
> On Tue, Oct 20, 2015 at 12:04 AM, Andrei Tuicu <<a href="mailto:andrei.tuicu@gmail.com">andrei.tuicu@gmail.com</a>> wrote:<br>
>> @Laura: I would suggest giving Constantin commit and merge rights for the<br>
>> repository. I haven't wrote much Python ever since this project and I feel<br>
>> like I'm slowing things down here rather than helping. While I still do<br>
>> encourage that he submits pull requests, so we can discuss things from a<br>
>> functional perspective, or design choices, something missing, etc., I think<br>
>> his contributions show that he can handle the responsibilities that come<br>
>> from such great power. :) Also, a big plus is that he helped Theodor Stoican<br>
>> make his first contribution. What do you think?<br>
><br>
> Sure! I'll do this right away! :)<br>
><br>
> Laura<br>
<br>
</span>First of all, thank you for trusting me with merge & commit rights to<br>
the Robocheck repo. As Andrei said, I'll continue to contribute via<br>
pull requests, so that we could discuss the design issues that may<br>
arise.<br></blockquote><div>You've earned it! :)</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Secondly, the test driven development style sounds appropriate, but<br>
before starting to add new features, I remember we talked about<br>
implementing a kind of common interface for the tools using<br>
AbstractBaseClasses. If you agree this is the next step, my only<br>
question is whether there should be only one interface - AbstractTool<br>
- or three - AbstractTool, AbstractDynamicTool and Abstract StaticTool<br>
- to emphasize the difference between the two types of tools.<br></blockquote><div><br></div><div>Well, I would incline for the 3 class hierarchy, where AbstractDynamicTool and AbstractStaticTool extend AbstractTool and then each individual tool would extends one of the two derived classes. Here, I think you should be careful so that the core and the core utils (especially the modulehandler, which looking back could've been named more suggestively) only know about AbstractTool. So, I think that it's important that nowhere in the code appears something like if (isDynamicTool) ... else if (isStaticTool). Bassically,  they should respect the Liskov Substitution Principle (which is a fancy way of saying no ifs like those from above :) ). Please let me know when you have a design in place with all the methods, fields, etc. for the classes. I would love to check it out. </div><div><br></div><div>Also, please give me a ping when you have the full documentation for the Windows installation.</div><div><br></div><div>I've been looking at the repo a bit, and as far as things nice to have, I could add the following (these are not in any way things that should be addressed immediately, but we should keep them in mind for future development):</div><div><br></div><div>1. Beside the installation scripts for Windows and Linux which should be platform specific, we should consider making the other ones platform independent at some point (aka Python), otherwise we will have duplicated code in bash and batch for each individual script. So from now on anything that can be made platform independent should be implemented in this way from the begining. At some point we should rewrite the unit testing script in Python. Sorry, this was my mistake, I should've thought about this from the beginning. The one wrote by me, if we don't find a real use to it (because it was poorly written from the beginning) we could simply remove it.</div><div><br></div><div>2. For integration with VMChecker purposes, we should make a script that can create an archive like the one that Robocheck requires</div><div>from the one that VMChecker receives. This will be a little tricky, because as far as I know that there is no general format for a VMChecker archive. So this is something open for discussion, maybe a template script that the TA will need to complete with the specifics for individual homeworks?</div><div><br></div><div>3. Move all the ideas from the discussion list to a wiki page in GitHub, so they don't get lost in a thread from the discussion list named Ping. :)</div><div><br></div><div>Cheers,</div><div>Andrei </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""></div></blockquote></div><br></div></div>