Weeks 4-7

[hdrdavies]

No description provided.

[naazy]

@sohilpandya @Conorc1000

week 4: node, database, backend testing learning. write tests for next week's project on friday.
week 5: project

week 6: node, sockets, authentication learning. write tests for next week's project on friday.
week 7: project

[hdrdavies]

@katpas @jackcarlisle @hdrdavies

For weeks 4-5

• Trial 2 weeks of node and see what the feedback is - whether we can run '2 week' projects again
• Only 'introduction to node.js' week should be a 2 week project otherwise time will run out very quickly
• First week of that is intro to node and backend TDD
• Second week is a node project- similar to the autocomplete project from FAC5. Possible features to the project:
  • Deploying to Heroku
  • Repo badges
  • Querying a simple API without a key (TFL?)

week 6:

• Introduction to Databases. Possible project:
  • FAC6 Twitter week using socket (we felt StackOverflow project didn't help much)
  • Database is Redis
  • Bin cookies
  • Hopefully by this point people will be fluent enough in node to implement socket well

week 7(-8?):

• Introduction to Authentication and Cookies. Possible project could be:
  • Github API, creating a Project Management tool or
  • Instagram - because your hiding your key

Possibly 2 weeks on Auth because it's so hard

[thegsi]

@mantagen

• Autocomplete - Update list of words to worknik.
• Twitter and socket projects combined. Including TDD
• voting did not happen
• PostgresSQL??

[naazy]

@rug1 @naazy

week 4: node, backend TDD, heroku
week 5: database, sockets (and touching on pusher API?)
week 6: authentication 1 and cookies/local storage
week 7: authentication 2 and payment (stripe API)

[Jbarget]

@Joshua-Ronan-Phillips @mk4111 @sohilpandya @mantagen @thegsi

week 4: node & tdd & testing whole week learning
week 5: project
week 6: node auth pushr
week 7: project

TBD

[hdrdavies]

@katpas @jackcarlisle @hdrdavies @rug1 @naazy @Conorc1000

@katpas @jackcarlisle @hdrdavies @rug1 @naazy
-Agree on principles behind 2 week project for node (4-5), then intro to databases after that (6), and more time on auth after database project (7 to maybe 8)

@Conorc1000 (& @sohilpandya but he wasn't present)

-Stood by @naazy's comment above

[hdrdavies]

FAC6 wide discussion:

API selection:
-Ensure we choose a simple API and the project leaders for the week write an introduction to the API and the data you get back so FAC7ers would be in an easier position to write tests.

Projects in general:
-Focus less on extra features and focus more on writing a good amount of quality tests:
SMALL SCOPE, TDD
-Keep to 1 week projects
-Show a best practice example by the end of the week (stretch goal for project leaders)
-Project leaders should be code reviewing every week
-If FAC7ers are unsure about code, they can assign a project leader to a PR (if the alumni is super busy they can pass it on to the next leader) so they review the code quality.
-Should we get in the habit of assigning PRs across teams for more cross-team communication and shared learning?
-in the 'resolve issues' section of the morning, assign a PR (or comment) that fixes the issue to the person that raises the issue. This will require a lot more organisation, as to do this properly, everyone will need to be a owner / collaborator on the project.
-In the same vein, patterns could be improved in terms of refactoring where people pair up - the person who wrote the code is not the one who refactors. @rjmk please add to this as you put it in a better way than I have here.

Nelson's week 2 project idea: @nelsonic
-Use real time API to make Stopwatch
-Instead of starting stopwatch on your machine, it syncs to simple API (which Nelson can show)
-FAC7 would get access to that API
-Firebase allows you to include URL with a function inside it and that's acts as an API
-When you start the stopwatch it links to people on the same page as you, and you can play a reaction game

[iteles]

@hdrdavies This is looking good and I'm really happy about

Focus less on extra features and focus more on writing a good amount of quality tests [and code]

I would note that understanding an API is a very useful skill to have so I might suggest that we err on the side of guidance rather than spoon-feeding in that section (i.e. figuring out the data you get back is pretty crucial and a worthwhile skill to gain).