This is a minor issue, but the last name game was a bit chaotic and too long. Could we ensure for Monday and record somewhere in the mentor notes that if alumni are going to join the circle they need to go after the students have all gone and it's ok for them to do it in pairs to speed things up a bit.

• Mocking HTTP requests in tests
• Sinon/spies?
• We don't need to test the backend if that already has tests

Introduce the concept of testing pure functions and simple utils, to get them in a testing mindset.

https://github.com/oliverjam/learn-html-forms/

• Install Express
• Start a basic server
• Set up GET routes
  • return JSON
  • return HTML

I think we need to decide on a license for our curriculum. We need to re-apply for our Netlify open source account, which requires our "project" to be licensed with a valid open source license. Since the curriculum is our main product this is probably what they care about.

Also I was thinking about other commercial bootcamps using our curriculum (e.g. http://www.turnintocoders.it/en/). I strongly believe that our curriculum should be open source, but I really don't like the idea of my work being used by for-profit entities.

My suggestion would be to use the Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA 4.0) license. This allows others to share and adapt the content, but requires them to give us attribution, not use the content commercially, and to retain the same license.

The Friday afternoon schedule currently includes:

Given recent discussion on keeping presentations to under 10 minutes and FAC18's requests for feedback on their presentations, we may have additional time for other activities. It might be a nice addition to have space for 20 minutes of peer (i.e. team-to-team) feedback on presentations, supported by a README with guidance on things like, scripting (or even pre-recording) the app walkthrough and keeping code snippets and explanations short. We could usefully also add additional time for team-based SGC, which appears to have been missed out of the current weekly schedules.

• Routing
  • All methods
  • URL params
• Static files
• Body parser? External middleware

Cover choosing colour palettes, a11y/contrast, HSL?

Review the spikes topics for every week (they should map to learning outcomes/project requirements)

• Check Node is installed (and at least LTS version)
• Quick overview of running JS in your terminal with the node repl
• Quick overview of running a JS file with node file.js
• Quick look at starting a server with http

Build your own router!

https://repl.it/@oliverjam/minimal-client-router-2

• Hijacking links
• History API
  • popstate listener
• Roughly match Express routing API for familiarity?

• All the different possible states
  • Don't forget "initial" and "empty"
• Spinners/loading indicators
  • Placeholder content

1. Inclusivity/Teamwork/Web dev basics
   Slightly tough one because the LOs are all over the place. This week includes git, a11y, DOM manip, mobile-first CSS etc
2. HTTP
3. Testing
4. Node/server-side
5. Databases
6. Authentication
7. Express?
   Not convinced that a specific server library is really the most important takeaway here. We're going to cover templating in vanilla JS, making a REST API and good server design.
8. Fullstack app

How to POST data with fetch.

• URLencoded & JSON
• Different ways to access form values
  1. Directly accessing querySelector("#my-input").value
  2. Using event.target.elements[name].value
  3. Object.fromEntries(new FormData(form))

Try out TDD and learn map, filter, every, some etc at the same time

Currently, students appear to be deploying to GitHub Pages, Heroku and Netlify, depending on context. Heroku is mentioned in in the notes for the Week 5 project. Netlify is not mentioned anywhere. It could perhaps usefully be added as early as Week 2 as a way to hide API keys (where they are currently mentioned for the first and only time).

In the second half of the programme, I would like to advocate for introducing students to containerisation through deploying Docker containers to GCP. It's conceptually simple and the basics can be picked up in under a day. It's a significant gap in the curriculum and will open up junior DevOps roles to our graduates of which there are many currently available.

A rough and ready intro to Docker and GCS.

https://github.com/oliverjam/learn-testing/

Integration testing to ensure the browser is actually displaying/interacting how you expect.

Based on feedback from past cohorts (and this discussion), it would be a good idea to create a short intro presentation for each week's topic (where one doesn't already exist).

I suggest we check these tick boxes as we add presentations for each week, and close the issue once every week has been covered:

• Week 1 presentation
• Week 2 presentation
• Week 3 presentation
• Week 4 presentation
• Week 5 presentation
• Week 6 presentation
• Week 7 presentation
• Week 8 presentation

Intro presentations that currently exist:

• Intro to Express presentation (created by @reubengt )
• Intro to password management presentation
• Intro to databases presentation

We're going to have lots of complex markdown (tables etc), which Prettier can automatically format to be consistent and readable. We shouldn't rely on contributors have Prettier configured in their editor.

Instead we can set up a GitHub Action that will auto format all markdown files in a PR and commit the change. Here's an example set up

• HTML forms workshop

Component CSS?

Slides and mini workshop covering how the web works, HTTP requests, methods, bodies. Maybe demo curl?

https://hackmd.io/FPs_TDZIT9-dFOWtpJNUkQ?both

3 different ways to render

1. Manual DOM manip with createElement
2. Cheating with innerHTML and template literals
3. Cloning <template> elements

Create testing week intro slides

Just raising this issue so that the HackMD documentation for the T4B project presentations and handover is linked to from the course book repo.

• T4B project presentation guidance HackMD
• T4B project handover guidance HackMD

Hover and focus styles

• What's REST?
• What do we mean by API?
• Build a server with at least GET, POST and DELETE
• Ensure correct headers etc
  • content-length, content-type

@matthewdking was reminding me at the weekend that he, @finnhodgkin and @Karyum developed a method of code reviewing in Nazareth that consisted of projecting one of the projects on the big screen and proceeding to critique and also re-write parts of it as a team, while the class all looked on. Apparently, this was very well-received and became a regular fixture for FACN3.

It reminds me of @besarthoxhaj and @izaakrogan's description of working with Campbell Morgan on one of their early projects back in the day, in what they both agreed was the most useful mentoring they ever received, when Campbell's code reviews would effectively involve him rewriting their code while Bes and Izaak looked on, asking questions as he went.

Could we institute something similar with FAC19? Perhaps we could even persuade Matt and Finn or Izaak and Bes to come in and demonstrate the technique for us before handing over to the in-house team.

Possibly we could fit a 30-minute review into the schedule at 2pm on Thursdays.

• Catching async error
• Notifying the user (toasts?)
• Recovering from bad state

Build your own middleware

• Error-handling
• Request/response logging
• Auth

No idea what. Previously scheduled test mocking but that's in Week 8 now

• Quick history of modules
• CommonJS vs ESM
• Syntax
  • Default vs named
  • Renaming imports
  • Namespace imports

We discussed how we might adapt our intro to testing at the last meeting. I presented my ideas for introducing the concept without any testing framework. I've created a rough workshop for how this might look.

We liked a few things about this approach:

1. We can avoid introducing node and npm before Node week
2. Tests will run natively in the browser rather than node (so no awkward module.exports hacks)
3. It lets students "see behind the curtain" and hopefully demystify testing a bit
4. It will allow us to test more than just pure functions if we want

We also discussed not limiting ourselves to only testing the pure functions/app logic. Currently the Week 2 project has a ton of boilerplate to ensure students are building an app that is unit-testable. This is often a sticking point and people end up spending more time trying to understand the (unusual) structure rather than writing tests.

With browser-based testing we aren't so limited, so we can have them write tests for complete features, which will more closely match user stories. We discussed having them do pseudo-BDD, where we potentially give them boilerplate tests that match the user-stories that they have to fill out then make pass.

E.g.

test("I can add a todo to the page", () => {
  const input = document.querySelector("input");
  input.value = "my todo"
  const button = document.querySelector("button");
  button.click();
  const todo = document.querySelector("li");
  equal(todo.textContent, "my todo"); 
})

Personally testing never clicked for me because unit testing and TDD feel so removed from user-facing features. TDD especially is (mostly) a development tool for solving problems. It wasn't until I started testing actual features as if I were a user that I really got testing.

If we think linking to slides from the coursebook is a better approach than putting content into the gitbook (shame gitbook doesn't have slide mode), we might want to think about consolidating on a single tool for creating them.

Introduce sync vs async, callbacks, promises and fetch

https://github.com/oliverjam/learn-promises/

• CSS variables
  • 2-step assignment
  • --red: hsl(0, 50%, 50%), --primary: var(--red)
• Dark mode? (prefer-color-scheme)

Becoming good at technical interviews is a critical skill. It could also become somewhat labour-intensive if we were to offer more opportunities for students to practice if done in the traditional way. It also requires the interviewer to have a modicum experience to be effective. Let's explore peer led approaches.

Perhaps we could set aside 90 minutes at the same time each week from Week 11 to trial peer-led approaches to interviewing.

Here is what it could look like:

Team of 4 + mentor

• Interviewee
• Interviewer, pairing at laptop
• Assistant, providing support to interviewer, upon request, but not communicating directly with interviewee
• Observer, saying nothing, but taking note of interactions and feeding back on them at the end of the interview
• Mentor, sits in on interviews and can either take the role of meta-observer or can just get on with their own work. Their main role is to say nothing, frown from time to time and generally unnerve the team. They can join the feedback session at the end of the interview, if they want, but they don't have to.

Library of interview challenges

Library of challenges with associated documentation

Documentation

• description of the problem
• Pre-populated codepen or similar environment, if needed
• List of FAQs and allowable responses
• Outline model solutions

Process

1. Mentors pre-prepare 4 problems and associated FAQs
2. All members of the team should prepare for their role as interviewer by memorising one problem, the associated FAQs and by attempting to solve the problem themselves before looking at the model solution
3. Interviewee sits at laptop and casts their screen
4. Interviewer sits with candidate; assistant and observer sit at side
5. Interviewer describes the challenge; If the assistant is not happy with the description, then they will offer clarification
6. Interviewee asks questions; interviewer responds to questions without referring to FAQs; if they are unsure of the appropriate response they will ask the assistant, who may respond using the FAQs as a reference;
7. The observer will take note of any interactions that they want to feedback on and any questions that they or the assistant think need to be added to the FAQs
8. The interview ends after 15 minutes
9. The observer then leads a feedback session for all participants and makes a PR for any suggested updates to the FAQs
10. Everyone changes roles and the interview proceeds with a new challenge

Not sure about this one. Build a simple prototype with no CSS/JS? Excalidraw?

Could we consider introducing the basic principles of estimation and issue management in Week 1?

Terms

• Scrum(TM) - a widely-used software development method, that uses some of the terms below
• sprint - The fixed period of development time between planning and review
• velocity - the projected team capacity (expressed in points )for one sprint
• user story - an action that a user wants to perform
• estimate - how long you think a user story will take to develop
• points - the (somewhat arbitrary) unit of estimation
• chore - something you haven't done yet, but needs to be done, not directly related to a story
• bug - something broken
• feature - something that was not in the original spec
• refactor - an improvement to your existing code
• project board - which you are going to use to visually track your project

Labels

To be added to GitHub issues

• E1 - Small story, estimated
• E2 - Medium story, estimated
• E3 - Actual story, estimated
• A1 - Small story, actual
• A2 - Medium story, actual
• A3 - Actual story, actual
• story, chore, bug, refactor, feature
• in progress, done (stretch: use triggers)

The project

Provide 6 user stories, 2 points each. Velocity: 12 points

• Stretch: Use the automatic triggers in the project board

Code review:

• incoming issues should be correctly labelled as chore, bug, refactor or feature

Presentation:

• show estimates vs actual points
• show issues correctly labelled
• show project board

Build an a11y spinner. Don't use booleans for state

As referenced in @jameslevine 's mentor feedback here:
#997 (comment)

fac16 and fac17 found the introduction to express on day 1 of express week quite long and wordy, and it took longer than expected because mentors were waiting on everyone to read through.

With @bobbysebolao 's approval, I made some slides and did a test run for fac18.
and they have given positive feedback about receiving the information as a presentation.

weeks 6 and 7 on the old curriculum (postgreSQL and authentication) do have presentations to introduce the week.

Having intro presentations from week2 onwards might be a good idea, an opportunity to introduce the main topics for the week and the learning outcomes and open the room to discussion and questions.

however, this relies on the mentors for the relevant weeks preparing to deliver these presentations, thats a possible downside.

initially started this suggestion just for the express week introduction.

I'm happy to assist creating the presentations if we decide to implement this.

Concept of scoping variables. var vs let/const. Block scope vs function scope. Script tag global scope

Short workshop on CSS layout to follow the Design Burst

Couple of minor things but wanted to raise them here. Happy to self-assign these if all agree.

• Course schedule links to the old coursebook, needs updated to link to default schedule in GitBook
• Can we replace intro to consensus-based decision making with a practice sociocracy circle? Think this is what Bobby did and since we're perhaps changing our business meeting model this might be more apt
• Revisit the presentation guidance for days 2 and 5. Relates #14 #64 #72

I've created a few extra slides on spikes, jigsaw and roles.

Can we fit both the intro to project management and Spike! into the Week 1, Day 2 schedule?

Based on when both parts (weeks 1 and 2) of the original talk were presented together, I would guess that the first slide deck would need 10 minutes to present and 5-10 minute for questions. The second talk is shorter and simpler. 30 minutes is probably realistic for both together instead of the 15 minutes currently allocated.

I am a little unsure about the Research presentation guidance and "splitting the allotted time for research 50:50 - between carrying out your research, and preparing your presentation", which--after our discussion this Friday--may be asking too much for what we might want to be a shorter presentation than we have asked for in the past.

New London curriculum

Present: Michael, Aisha, Oliver, Kristina, Dan

4/9/19 TO DO

• go through existing curriculum and add bullet points to the list below

Overall approach

1. learning outcomes will describe testable functionality
2. code reviewers will test for those learning outcomes
3. if a learning outcome is not introduced in an associated workshop, then it will be a spike/research topic

1. Concept: static website
   PROJECT:

   • semantic HTML
   • accessibitility
   • performance
   • git/git workflow

   Tools

   • debug CSS
     JS
   • dom manipulation
     CSS
   • responsiveness (mobile/desktop)
   • transitions
   • flexbox (navbar)
     testing
   • manual QA

2. Concept: HTTP
   PROJECT:

   • req/resp
   • fetch

   Tools

   • debugging js
   • (chrome) network tab
   • postman
     JS
   • array methods
     CSS
   • grid (render a grid of data)
     testing
   • make DOM tests pass

EXTRA: FAC api for Weeks 2+3

3. Concept: build systems
   PROJECT:

   • npm

   • automated testing

   • searchable api / form

   • error handling

   Tools

   • linting
   • prettier?

   JS

   • object manipulation
   • client-side validation
     CSS
   • client-side validation
     testing
   • automated unit tests?

4. Concept: node
   PROJECT: vanilla HTML form

   • vanilla server
   • buffers/streams
   • core node modules
   • CommonJS modules system
   • forms/posting/redirecting

   Tools

   • debugging server
   • nodemon
     JS
     • error-first callbacks
       CSS
     • forms-more than just text input
       testing
     • server testing -> response?
     • TDD with supertest

5. Concept: Databases
   PROJECT:

   • schema design
   • SQL
   • db setup/management

   Tools

   • psql
   • environments
     JS
   • abstraction
     CSS

   testing

   • db testing

6. Concept: Auth
   PROJECT:

   • hashing/salting
   • jwt
   • sessions/cookies
   • bcrypt
   • ssl
   • stateless vs stateful sessions

   Tools

   • application tab (chrome)
   • CI (GitHub actions or travis)
     JS
   • promises (roll your own)

   CSS

   • logging-in UX
     testing

7. Concept: Express
   PROJECT: User profile?

   • templating
   • design patterns (MVC)
   • REST APIs
   • middleware (as a concept)

   Tools

   • more postman
     JS
   • template literals
     CSS
   • a CSS preprocessor?
     testing
   • mocking

8. Concept: Full-stack app
   PROJECT:

   • full stack error handling
   • handlers
   • build steps

   Tools

   JS

   • throwing and catching errors
     CSS

   testing

WEEKS 10-16 (FOR LATER)

Possible learning outcomes:

• Build a PWA with service workers and localstorage
• Using D3 for Data visualisation
• Deploy on Netflify (and possibly AWS)

Student project

UI/UX
- 
DevOps
-
QA
- 
Scrum
- 

Tech for Better project

UI/UX
- 
DevOps
-
QA
- 
Scrum
- 

Explain the concept of functions being "first-class" in JS. Lay the groundwork for callbacks. https://oliverjam.es/blog/first-class-functions/