Gsoc 18 Project | Collect build statistics
Mojca Miklavec
mojca at macports.org
Sat Apr 7 03:36:52 UTC 2018
Dear Vishnu,
To address some of your earlier non-technical questions with respect
to GSOC, here's what our admin wrote:
As per GSOC policy, we cannot comment on selection process before
April 23rd. We are evaluating all the proposals and might ask some
clarifications if required. There are no set steps or guideline which
confirms a student's acceptance. Students' self motivation to open
pull request and commit changes are always welcome and improves the
chances. Communication also plays a key role.
The technical feedback written below is valid independent of gsoc
schedule (that is: I'm not expecting you to implement what I wrote
below right away as a requirement for anything, this does not in any
way reflect feedback or questions from other mentors etc. and until
the official announcements there is not even a guarantee that
implementing all of the suggestions would guarantee a slot).
On 5 April 2018 at 16:08, Vishnu wrote:
>
> I further improved my demo project based on feedback.
Thank you.
> I am now able to parse the ports(stored in json locally) using the website
> itself(by accessing {url}/port/parser).
> This will read the json file and fill the port table using django models.
Thank you, that's better than writing raw sql statements in any case.
I already wanted to suggest putting the material in a repository, but
you already did that in the meantime
(https://github.com/VishnuM-sopho/demo-macports).
Some feedback related to repository layout:
1.) It's nice if a project contains README.md explaining what the
project does and how someone who's not familiar with django can launch
it to test himself.
2.) It's not clear what test.db is at all. OK, I know it's a sqlite
database after checking the contents, but it makes sense to put the
result of such individual standalone tasks to a different folder in
order to distinguish between the Django app itself and some unrelated
playing with the code, so put python code that's not related to django
to a separate location.
3.) You have some strange file names in the middle of your django app.
Like "aljaz script output.json". And then another file
"testing2.json". The first one is 15 MB, the other one is 5 MB. It's
not clear what file does what, what is the difference etc. In any case
this is data that changes over time. I would generally put it to a
different folder called "data" or something. In the final deployed
apllication such a file should not be included in the repository, it
also gets outdated pretty soon, but it's certainly fine to have such a
file at hand for testing etc., so it is still valuable, it just makes
sense to put it to a different top folder.
4.) Your repository contains some sqlite3 databases. This might be ok
for the initial demonstration of your ability to fill in a small
database, but generally the database itself should not be part of code
repository. Instead, the instructions how to run your code are much
more valuable.
Some feedback related to your app:
1.) I understand this was the fastest way to get the simple site done.
But once your are out of "get this done quickly" mode, you need to put
the css and js out of port/templates/port/port.html (some minor js
might occasionally be needed, that's fine, but don't put all the
zillion of css lines there). Static files should be separate, also for
efficiency reasons.
2.) Use more descriptive names than p1n, d1e, v1a, ...
(portname=p1n, description=d1e, variant=v1a, portdir=p1d)
3.) Your code works for single time import:
c = Port.objects.create(portname=p1n, description=d1e,
variant=v1a, portdir=p1d)
what happens when you do data import for the second, third, ... time?
4.) In port/models.py you need to make the port name "unique"
(https://docs.djangoproject.com/en/2.0/ref/models/fields/) and you
probably need an index on portdir, so that you can later group ports
with the same portdir together and show all ports with the same
portdir together.
5.) In many other projects on your github account you included/left
database passwords in repository. You should absolutely never do that.
In the django project you left some key inside the code. Not sure
where that one is used, but you need to make sure that the production
server uses something else. I don't know yet how Django handle this.
I was surprised that you used some made-up names in the database in
your screenshots. Since you had the full database, I would imagine
there was zero extra effort to simply import them all real data there
eventually :)
Some potential further steps could be:
(a) Static site (I don't see the page itself in the repo, only in the
form of template?)
It might make sense to continue working on that static sample site.
Add all the missing graphs (not the graphs themselves, but specify
what to put there), maybe some further work on layout (just the
basics, not to the perfection).
(b) Study how to do unit tests in Django and try to write some for
that sample site.
One example of a unit test: prepare two json files with two ports. The
second file has a newer version of the second port. Try to import the
first file and then the second one and make sure the result is what
you would normally expect.
(c) You can continue implementing the database model in django with
more properties of individual ports, you can for example add a new
table with categories and add many-to-many relationship between the
two. Then list categories on each port page as hyperlinks to category
view (category view would then list all ports from that category as
hyperlinks to port pages).
Optional: it could be nice to find a suitable place to host the
testing site somewhere. Maybe a service like Heroku would work. I have
zero experience with those services though, so I cannot recommend any
one of them.
Maybe a question to ask when you need some further suggestions about
what to do next could be: if you would want to get something deployed
really soon (not so soon that you would take shortcuts and implement
super ugly hacks to get it done), what do you need to add? What is a
minimum viable product? For example, if you import all ports
(forgetting about statistics for now), add some more fields to the
database to get more useful information, allow basic browsing of ports
and just slightly improve the generic layout, you could probably have
a functional website that would already be useful for users.
Mojca
More information about the macports-dev
mailing list