Change task to allow a value for unmatched bonus #91
Conversation
jonodrew
force-pushed
the
set-unmatched-bonus
branch
from
6dfdfc2
to
a8083a4
Compare
✅ Result of Pytest Coverage---------- coverage: platform linux, python 3.9.13-final-0 -----------
|
|
@johnpeart - I'd love your opinion on this please! Where should we put the form asking for the Another approach I'm thinking of is to have a form that asks something like.... "Would you like to optimize for:
And then let the system work out the optimal approach by running multiple trials with different numbers for the unmatched bonus? What do you think? |
|
Sorry for the delay. I agree, adding a page in would be a good way of managing this. The page could be expanded, in future, to add other customisable variables. I also like the idea of giving people human readable options to select, and letting the system working out the best weighting. It seems a more 'user centered' option, to me at least. Do you need me to do anything specific to enable this? |
|
If we take the second option, I'll need a wee form for the user to select their preferred option. That's all I need from you. For me, I'll need to work out how to run multiple attempts separately. A very interesting engineering challenge! |
|
I'll have time to put the form together at the weekend, if that works? |
|
It shouldn't need any js - as long as we use the design system we can keep using I'm going to try and work out the backend this week. We're aiming for the highest total score (measured by summing the successful |
app/classes.py
Outdated
|
|
||
| def map_model_to_output(self, data: dict): | ||
| data["job title"] = data.pop("role") | ||
| data["email address"] = data.pop("email") | ||
| # data["email address"] = data.pop("email") |
|
Forgive the mess of commits - I'm going to redo them so it's clearer what's actually happening here. The important part is this line - the system now expects a true or false value passed to it. It's where we use the javascript to start the matching process, if you remember? True will kick off the the divining process, where it spins up every possible iteration of the entire, three-round grid. It's an absolutely mammoth task that takes almost ten minutes to run. |
|
Result of 6 minutes of work on the MacBook - the ideal, mentor-focussed outcome with the sample_data |
|
Quite a lot of this is going over my head! But if I understand it at a rudimentary level, we want the form that toggles the 'true' or 'false' value to appear on the Is that right? |
|
Perhaps. I think the issue we have is that when the user clicks the button,
some Javascript runs. If there's a form on the page the JS will need to
pick the answer off it, and I'm not sure how to do that. If you can work it
out I think that's the preferred method.
My approach would be a new page before this one with the standard form, and
then saving that value to the cookie/passing it back to the frontend
somehow.
…On Sat, 18 Jun 2022, 22:26 John Peart, ***@***.***> wrote:
Quite a lot of this is going over my head!
But if I understand it at a rudimentary level, we want the form that
toggles the 'true' or 'false' value to appear on the process.html page
template, where I've added the commented out HTML in commit 910534c
<910534c>
.
Is that right?
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2ATLURHW4HFDUJODAQSPDVPY5I3ANCNFSM5XE7SSWQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
That makes sense – though that is probably beyond my knowledge to do the routes, etc. I can make it look nice though! Capturing the value of a radio button is relatively trivial in JS, so if you want me to do that instead, then I can do that. |
|
I think we introduce a risk, because if a user has Javascript turned off it
might not work...?
It'll take a little longer but we should do it properly. If you can work up
a new HTML page in a fresh PR I'll fix up the routes to put it in the user
journey
Can't wait for you to try out this new functionality!
…On Sun, 19 Jun 2022, 17:53 John Peart, ***@***.***> wrote:
That makes sense – though that is probably beyond my knowledge to do the
routes, etc. I can make it look nice though!
Capturing the value of a radio button is relatively trivial in JS, so if
you want me to do that instead, then I can do that.
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2ATLXMGDTCQ5G76XUB2ADVP5GAPANCNFSM5XE7SSWQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Moving the requirements installation step towards the beginning of the file means it takes less time to rebuild it when testing, improving speed
jonodrew
force-pushed
the
set-unmatched-bonus
branch
from
910534c
to
ebb68c5
Compare
|
I've added some very rough routes and a page template which I have put at Hopefully that helps?! |
jonodrew
force-pushed
the
set-unmatched-bonus
branch
2 times, most recently
from
982322e
to
e9f29c5
Compare
Pickle is Python's own serialisation library. It's not without its risks, but it does massively increase speed and enables passing around complex data objects - which is what we have here. It enables us to expose our "most mentees with a mentor" functionality. To enable this I've added the `connections.setter` property in `CSPerson`, to allow pickle to load the data back into the object when it deserialises it. I've added some tests, but they need expanding - there's likely something around patching the long-running matching tasks to improve visibility of how everything is working. The `run_task` route now takes a "pairing" variable, which indicates which function will be run to calculate the outcomes. The default is to use the quicker, one-round loop with an unmatched bonus of 6.
Various fixes here that make it easier to test the system locally
jonodrew
force-pushed
the
set-unmatched-bonus
branch
from
e9f29c5
to
5aaaa6b
Compare
[2.3.0]
Changed
the machines you're running this on you could really get yourself into trouble.
97s when we were using JSON to serialize data.
Added
UnmatchedBonus. This functionality isuseful if you want to ensure everyone gets at least one mentor. It calculates a lot of values - one client is
calculating 37 different iterations of a three-round program, requiring 111 rounds of matching - so it takes a bit
longer to calculate. Exposing this functionality in the front end will be patched very soon, but in the meantime
dig around in the routes section or add a
"pairing": Truekey-value pair to your JSON call to the appropriateendpoint.
enough time to make several cups of tea - on my hardware, it's clocking in at around 7 or 8 minutes. That's a long
time to stare at the same screen. We'll be updating the frontend to give more feedback soon, but for the moment,
either check the logs from celery or accept that you'll be here a little while.
stopping when it got to the approach that scored above a specific threshold. I see two problems with this. First,
assuming that each matching process takes n seconds, in the worst case iterating upwards takes Mn seconds. In
the best case, of course, it takes n seconds!
This is therefore generally faster, although not in the case where the first outcome is the one we want. Given
that I can't predict things will be perfect every time, I've opted for the apparently longer approach.