Mid Specialism Course Project Proposal #236
Conversation
| The main concept is to keep a consistent theme across specialisms, but course-specific deliverables. This gives us flexibility if we change or create new specialisms, since they are not dependent on the same implementation details.. | ||
|
|
||
| By keeping the projects entirely specialism bounded (e.g. backend only build the backend, rather then a full stack app), we can keep maintainence of boiler plate/starting codebases to a minimal. | ||
|
|
||
| ### Theme | ||
|
|
||
| We should choose something other than "meal sharing" so trainees have something more unique to work (everyone knows everyone who graduates HYF has built a meal sharing app - it's a little tired now). It should be one well described theme. |
There was a problem hiding this comment.
Thinking out loud here...
- Since the API is the contract between the front and the back end, then maybe the API / data model needs to be decided by us mentors, and laid down in stone.
- Maybe we provide a stub back end (for the front end folks), and a stub front end (for the back end folks), conforming to that API.
- Maybe we create (but don't provide to the trainees) a non-stub, but also not-at-all polished front / back end implementations. Doing this would allow us to mix and match for demo purposes:
- basic front + basic back = a minimal full-stack solution. Maybe show it running (without the code) to the trainees to say, "this is very roughly what we're aiming for"
- basic front + stub back => demonstrates that the stub back end conforms to the API (so can be used by the front end teams when they build their real front end)
- stub front + back back => demonstrates that the stub front end conforms to the API (so can be used by the back end teams when they build their real back end)
And finally... if we need to decide the concept + API before presenting the task to the trainees, then we can just come up with some concept, anchored around whatever kind of complexity level we're aiming for.
There was a problem hiding this comment.
Since as part of foundation/backend they are learning to design data models, databases and APIs, i'd expect they should practice that in projects too. If we decide the API/data model in advance, i think this takes a significant portion of the work away from the backenders, right?
I think the first goal would be to align on the learning goals for this project, and exactly what we'd hope the trainees to learn/practice, and build this plan backwards from that. I've gone back and forth on the ideas of how much to provide vs a blank(er) slate.
There was a problem hiding this comment.
Exploring what we do / don't want to include in the FE/BE-side project
https://docs.google.com/spreadsheets/d/1B_RruWK2cQvXvQm0ALEx7Vt2sw8NDupadn1ML5ivcMI/edit?gid=0#gid=0
(
There was a problem hiding this comment.
Thanks @rvedotrc, that's a good way to visualise it.
Co-authored-by: Soheib <[email protected]>
|
I'm merging this for now, so we can use it as a starting point to plan the details (which can still be changed). The staff team will align on this next and resume moving it forward at the start of january. |
All the info is in the proposal :D Read more below!
Related to #124
It's easiest to read here.