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.netWeek 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