<div dir="auto">Hello, <div dir="auto"><br><div dir="auto">First thing. I am. Not clear about what document you are talking about perfecting.</div><div dir="auto"><br></div><div dir="auto">And i will now focus attention on django as mentioned in my earlier mails. </div><div dir="auto"><br></div><div dir="auto">And thanks a lot For that in depth reply. Will work on all things related to Html after I complete working with django.</div><div dir="auto"><br></div><div dir="auto">Thanks </div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 3, 2018, 9:04 PM Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Vishnu,<br>
<br>
Thank you very much for sharing the document. The purpose of this HTML<br>
was two-fold:<br>
- demonstrating your skills<br>
- first step of the planning phase for the actual implementation<br>
<br>
Below I'm providing some feedback, but I would suggest to concentrate<br>
on a simple django app at this moment and then return back to this<br>
html once you are "done" with Django to address (some of) the<br>
comments. In short: if selected, I'll insist to make this document<br>
"perfect" before proceeding (and to address all the feedback + more I<br>
didn't yet bother writing), but there's no point in asking you to<br>
spend a week making this document ten times longer and fixing tiny<br>
unimportant details that don't really demonstrate the skillset :)<br>
<br>
On 2 April 2018 at 23:32, Mojca Miklavec wrote:<br>
> V pon., 2. apr. 2018 19:49 je oseba Vishnu napisala:<br>
>><br>
>> In the database.<br>
>> Because then it would be very easy to count the number of os for that<br>
>> port.<br>
><br>
> I'll explain tomorrow why this is suboptimal. (But there's no need to<br>
> further optimise the database design right now.)<br>
<br>
There are probably better resources that explain this, but here's the<br>
first hit from Google:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Don%27t_repeat_yourself</a><br>
<a href="https://en.wikipedia.org/wiki/Database_normalization" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Database_normalization</a><br>
<br>
In extreme case, imagine that we decide to send a questionnaire to our<br>
participants of statistics collection, asking them some 100 optional<br>
questions, including anything from gender, age, country of origin,<br>
country of current residence, education, favourite animal, ... Then we<br>
decide that we would want to compare the age distribution of users of<br>
package A vs. age distribution of users of package B.<br>
<br>
Your idea that allows "very easy number counting" would mean that:<br>
<br>
At the moment you only have (submission id, port, port version,<br>
variants) in the table. You would need to extend the table to contain<br>
    (submission id, submission time, user id, port, port version,<br>
variants, os version, stdlib, xcode version, age, gender, country,<br>
education, favourite animal, ...)<br>
And if the user has 1000 ports installed, you would need to store<br>
100x1000 cells (repeat that same information one thousand times and<br>
then again in any subsequent submission from the same user) instead of<br>
having a single copy in a separate "questionnaire" table. Multiply<br>
that with 10.000 users submitting statistics and you end up with tens<br>
of gigabytes of data each month, just to store results of that<br>
one-time questionnaire.<br>
<br>
On top of that, once the user submits a questionnaire, if you keep<br>
those answers in a separate table and use proper SQL queries, you<br>
could easily get the answer to question "what was the prevailing<br>
gender of users of package A" even for submissions that were made many<br>
months ago. If you store everything into a single monstrous table, you<br>
would either need to modify plenty of old submissions or you would not<br>
be able to get that information for old submissions at all.<br>
<br>
Additionally, it could happen that while you are updating old<br>
submissions, the database crashes. You could end up with half of the<br>
entries updated and the other half left at their old value, in<br>
inconsistent state. There are plenty of problems if you don't make<br>
sure that you keep your database design in a good shape from the very<br>
beginning.<br>
<br>
<br>
That's a super common use case in databases that has already been<br>
solved. One should use table joins and views. Random link (I'm sure<br>
there are better ones):<br>
    <a href="https://db.grussell.org/sql3.html" rel="noreferrer noreferrer" target="_blank">https://db.grussell.org/sql3.html</a><br>
<br>
I don't know how Django handles joins and views (some hints I skimmed<br>
through are here <a href="https://stackoverflow.com/a/1281051/585897" rel="noreferrer noreferrer" target="_blank">https://stackoverflow.com/a/1281051/585897</a>), but one<br>
should certainly make sure that the database design is done well.<br>
Learning more about that topic is part of the process.<br>
<br>
<br>
On 2 April 2018 at 23:50, Vishnu wrote:<br>
><br>
> Please go through this <a href="https://jsfiddle.net/vishnum98/3r4vL4L3/21/" rel="noreferrer noreferrer" target="_blank">https://jsfiddle.net/vishnum98/3r4vL4L3/21/</a><br>
><br>
> I did some changes.<br>
<br>
Thank you very much. The chart looks ok. For the remaining (missing)<br>
charts just add a section (and optionally an empty box) and describe<br>
what kind of chart goes there (no need for a long paragraph, just make<br>
it clear what's on the Y axis).<br>
<br>
I don't think we need a drop-down to select a version, but now that<br>
you put it there, what I think would be helpful to have there is<br>
something to switch between:<br>
- absolute number of installations in that month<br>
- number of installations of that port divided by total number of<br>
submissions in that month<br>
That is: having both absolute and relative numbers available.<br>
<br>
To make it clear: don't bother actually implementing this now. You can<br>
add a placeholder to remind you about that later (or just change the<br>
contents of that drop-down to do this instead), nothing else.<br>
<br>
We are mainly interested in the cumulative number of installations of<br>
a particular. Version does tell something, but not *that* much, except<br>
that the user did not update the ports for at least a month. We could<br>
potentially make a cumulative diagram listing all versions, random<br>
example:<br>
    <a href="https://kanbanize.com/blog/wp-content/uploads/2014/01/Cumulativeflowfinal.png" rel="noreferrer noreferrer" target="_blank">https://kanbanize.com/blog/wp-content/uploads/2014/01/Cumulativeflowfinal.png</a><br>
but I would worry about that *at the very end*.<br>
<br>
What would be a much better *global* measure would be the time since<br>
the user last updated PortIndex, but I have no clue how to get that<br>
information in a reliable way (and it's certainly not your task to<br>
worry about it).<br>
<br>
<br>
Further comments:<br>
<br>
* Some more items from the proposal are still missing, like whether<br>
the package is outdated, latest commits, link to tickets, ... No need<br>
to do anything fancy, just put some placeholder there.<br>
<br>
* Build statistics will need more work. I mean: the table as it is<br>
looks nice. But we'll probably want to represent the information in<br>
two different ways. One way listing all builds the way you did now.<br>
And the other one in approximately this way:<br>
    <a href="https://trac.macports.org/ticket/55978#Viewnr.3:Overviewofhistoryofbuildsofaparticularport" rel="noreferrer noreferrer" target="_blank">https://trac.macports.org/ticket/55978#Viewnr.3:Overviewofhistoryofbuildsofaparticularport</a><br>
<br>
* I'll save more nitpicking for later :)<br>
<br>
Mojca<br>
</blockquote></div>