Hey all, I've merged the reports for week6 and week7. A lot has happened these past weeks, however I also took a break, so there wasn't as much progress as there will be next week.
Summary of weeks 6 and 7 ------------------------ Generally not a huge amount of work was done these weeks. I decided to take a few days off and relax. I couldn't make it debconf, due to the fact that I simply didn't have enough money to travel down (most of my GSOC earnings has gone into saving). However it looked awesome! I would have loved some of the tasty cheese ;) The Project ----------------- The project title is "Improving Accessibility and front-end of Debsources" You'll find the Google Summer of Code information [on their site][1]. For a more detailed project summary see the [Debian Wiki Page][2]. Quick Links ----------- - [Debsources Github Fork][3] - [Trello Board][4] - [Development log][5] - http://sourcedev.debian.net Week 5 Report ----------------------- ### New Mentor Workflow I missed two meetings in a row, and the mentors decided it was time for a new workflow. I agreed and we decided to work without regular meetings. Instead, I am responsible for setting and meeting deadlines, and the mentors will treat me like a standard contributer. They'll still be reviewing my progress but less hands on than before. This will reduce stress for them and I think will make me more productive long term. ### Javascript preperation I've done a lot of research regarding implementing the Javascript Single Page Application (SPA), so skip to the next heading if you want to skip the research. Currently views in debsources are being built with jinja2 blueprints. So every subsite has a seperate blueprint. When a request is made to debsources, we follow the route to the associated view in the blueprint, and build the blueprint. This is essentially a refiend MVC architecture. The model is referenced when a view is being rendered, and the controller is the url & other HTTP stuff (form data, etc). Generally, controllers don't actually affect the model but just how the model is represented in the view. That is withen current debsources. However a movement towards SPA behaviour and a patch editor requires that there be a different method to ask for updates. The most sensible way to do this is probably by _not_ changing current rendering techniques. Instead: every subsite should have, in the routes or __init__, a SPA Blueprint. That will serve as an endpoint for SPA specific views and I will introduce controllers. Once you visit debsources, you'll grab the server rendered material and begin downloading the javascript. If everything is able to initalize, then the page will do the javascript hooks and begin controlling the site through REST and componant based architecture. Otherwise the old site will be used. It's imperitive the core urls are the same, so a reload on the SPA will return the correct view for debsources. These are challanges I'll be approaching. ### Plan for week 8 - Update the branches based on maintainer comments - Begin prototyping the javascript stuff (will do this when reviews have been met). I hope the code review on responsive debsources goes quickly though I imagine it could take some time. In the mean time I will work on SPA-debsources. I hope to have a pretty cool demo browser in the next few days! I will probably end up using React, because I don't know if angular is flexible enough to do what I need to do. Thanks for reading, Aaron Delaney (~devoxel) [1]: https://summerofcode.withgoogle.com/projects/#4593198689157120 "GSoc" [2]: https://wiki.debian.org/SummerOfCode2016/StudentApplications/AaronDelaney [3]: https://github.com/devoxel/debsources [4]: https://trello.com/b/TQEwttbV/debsources-gsoc-2016 [5]: http://www.devoxel.net/log/ [6]: https://github.com/devoxel/debsources/blob/master/doc/twitter-bootstrap.progress.md
