├── README.md └── homework-reviews.md /README.md: -------------------------------------------------------------------------------- 1 | # Teaching tips and tricks 2 | 3 | The main goal is to inspire other teachers and share information about how to give a fun class. 4 | 5 | ## Contents: 6 | 7 | - General Teaching Techniques 8 | - [Live Coding](#live-coding) 9 | - [Let students create the schedule of the day](#let-students-create-the-schedule-of-the-day) 10 | - [Give broken applications](#give-them-broken-applications) 11 | - [Other Teaching Tools](#other-teaching-tools) 12 | - [Homework Reviews](#homework-reviews) 13 | - Energizers: 14 | - [Unique game](#any-module---energizer-unique-game-can-be-used-as-intro-getting-to-know-each-other) 15 | - [One lie two truths](#any-module---energizer-one-lie-two-truths-can-be-used-as-intro-getting-to-know-each-other) 16 | - Module specific tips: 17 | - [CLI - Game: I go on holiday and I take with me](#cli---game-i-go-on-holiday-and-i-take-with-me) 18 | - [GIT - OS concepts and Live coding](#git---os-concepts-and-live-coding) 19 | - [Javascript array remembering trick](#javascript-array-remembering-trick) 20 | - [JavaScript: `map` `filter` `=>`](#javascript-map-filter-) 21 | - [Javascript callstack and eventloop visualisation](#javascript-callstack-and-eventloop-visualisation) 22 | - [Javascript apis](#javascript-apis) 23 | - [JavaScript OOP: build a IMDB web scraper with real time code collaboration](#javascript-oop-build-a-imdb-web-scraper-with-real-time-code-collaboration) 24 | - [Javascript Promises: Learn how to use promises by cooking pasta 🍝](#javascript-promises-learn-how-to-use-promises-by-cooking-pasta) 25 | - [RobotApp](#robotapp) 26 | - [React - drawing components](#react---drawing-components) 27 | 28 | # General Teaching Techniques 29 | 30 | ## Live Coding 31 | 32 | by [@ChrisOwen101](https://github.com/ChrisOwen101) 33 | 34 | A preferred teaching technique is Live coding and it involves walking through each line of code and physically writing each line to show how the code is written. 35 | 36 | Particularly good for new students as it’s good to see in practice how the code is written and it takes away some of the "Code Scare" effect when writing code for the first time. 37 | 38 | This is really good when you involve the students in the process by acting as the “hands” and they are the “brain” telling you what to type. This reduces syntax errors when you want to move quickly and cover broad concepts in the lessons. 39 | 40 | #### Additional note 41 | 42 | by [@mkruijt](https://github.com/mkruijt) 43 | 44 | Just like Chris I use a lot of live coding in my classes. 45 | I would try and keep this around 15-20 minutes and follow it up by actual coding. 46 | 47 | - You can ask students to implement the code you have written while live coding, in teams of two. 48 | - You can also do one of the below mentioned assignments like a presentation or the research exercises. 49 | 50 | I repeat the combination of live coding and practical coding throughout the entire class. 51 | 52 | During the practical coding exercises I walk through the class. When students ask me questions I almost never give them the correct answer, I ask them a question back if they can explain to me what they are trying to solve. And let them google and find the answer themselves. 53 | 54 | During live coding I try and involve them in the code we are working on. 55 | 56 | - You can do this by asking students to explain certain concepts or parts of the code. 57 | - I also ask students to tell me exactly what to type. For example in HTML/CSS "what if I would like to have a list in my page, how would I do this?" I always follow exactly what they tell me, even if it is incorrect, I like that the rest of the class gets the opportunity to correct possible mistakes. 58 | 59 | > In general when live coding I (sometimes) on purpose make mistakes, I think it is a nice way to keep the group sharp. Also It's just really cool if you can correct your teacher right?! 60 | 61 | #### Let students create the schedule of the day 62 | 63 | by [@mkruijt](https://github.com/mkruijt) 64 | 65 | In JavaScript but also in other modules in general, sometimes it makes more sense to spend time on concepts that are unclear then simply just continue with other topics that are on the agenda. 66 | 67 | I like to include the group in what needs to be discussed on a given teaching day. This mostly results into covering some unclear concepts from previous weeks, but the class often also writes down topics of the current week. 68 | 69 | An exercises I sometimes start my class with: 70 | 71 | - Write down for yourself in 1 minute: What did you learn this week? 72 | - Share with the group what you learned this week 73 | - Write down for yourself in 3 minutes: three questions you have from last week. 74 | - Write down for yourself in 3 minutes: three things, what would like to learn this week? 75 | 76 | Give them 10 min to write down what it is they would like to discuss in class today on a board, they have to do it together as a group. 77 | 78 | Give them one more chance, they get five more minutes to decide together which three topics they want to be discussed today. They also have to get out the duplicates from the board and prioritize on importance. 79 | 80 | ## Give them broken applications 81 | 82 | by [@KevinTss](https://github.com/KevinTss) 83 | 84 | A good approach to make students more able to get programming concept is to let them have problems, be stuck and have to look for solution on internet. Like just let them search and find a way to repair something. 85 | 86 | When I'm talking about `app` I'm talking about exercice, could be pure HTML, CSS, JavaScript or more... 87 | 88 | Good example of exercices : 89 | 90 | - Give a app with synthax errors (coma missing, case mistakes,...) 91 | 92 | ```javascript 93 | // Synthax error (very simple) 94 | /* 1 */ 95 | const firstname = "John"; 96 | const lastname = Doe"; 97 | 98 | /* 2 */ 99 | const sayWelcome = function { 100 | console.log("Welcome guys!"); 101 | } 102 | ``` 103 | 104 | Don't hesitate to give lot of exercices like that, because it's simple, students will be proud of themselves. 105 | 106 | - Give little script with logical errors (like mathematics, algorithmic mistakes,...) 107 | ```javascript 108 | // Logical error (synthax validation or conversion needed) 109 | const age = prompt('Enter you age'); 110 | if (age * 2 > 36) { 111 | console.log('Enjoy the website!'); 112 | } else { 113 | alert("Sorry buddy, you're a bit young!"); 114 | } 115 | ``` 116 | 117 | ## Other Teaching Tools 118 | 119 | ### PythonTutor for JavaScript 120 | 121 | [A visualization tool](http://www.pythontutor.com/javascript.html#) that helps you understand how JavaScript steps through your source code and manages program state behind the scenes. Copy any snippet of synchronous JS code (just plain simple JS scripts, no dom or api calls) and study the visualization to learn how the JS thread works. PythonTutor has live chats and a beta collaborative coding feature. Here is a (work in progress) [collection of curated js snippets](https://github.com/janke-learning/js-in-order) for studying on pythontutor. 122 | 123 | PythonTutor is a great complement to [latentflip's loupe](#Javascript-callstack-and-eventloop-visualisation): loupe visualizes everything that happens around the thread, and pytut visualises only what happens on the thread. 124 | 125 | ### Control Flow visualization 126 | 127 | These two sites dynamically create flow-charts for your code to help study or debug your code. They don't allow you to step through the code or track what's happening in memory, but using these flow charts along-side pythontutor can be very helpful. 128 | 129 | - [code2flow](https://code2flow.com) - this one allows you to share permalinks 130 | - [bogdan-lyashenko](https://bogdan-lyashenko.github.io/js-code-to-svg-flowchart/) - this one has cleaner diagrams 131 | They're both good, try them and decide for yourself. 132 | 133 | ### The Parsonizer 134 | 135 | Turn any snippet of code into a [parsons problem](https://computinged.wordpress.com/2017/11/17/parsons-problems-have-same-learning-gains-as-writing-or-fixing-code-in-less-time-koli-calling-2017-preview/). The parsonizer will mix up the lines of code you provide and ask you to drag them back into the correct order, it will give helpful feedback if you make a mistake. Parsonizing is a great way to learn the most from a single piece of code whether you're learning basic syntax or you're already studying advanced algorithms. 136 | 137 | - [the parsonizer](https://janke-learning.github.io/parsonizer/) 138 | 139 | ### Live Dom Viewer 140 | 141 | Like PythonTutor and Loupe, but for the dom. Copy-paste html into [this website](https://software.hixie.ch/utilities/js/live-dom-viewer/) and it will show you your code, a representation of the dom, and what is displayed in the browser. It's like the devtools inspector but beginner-friendly. 142 | 143 | ### Presentations 144 | 145 | by [@ChrisOwen101](https://github.com/ChrisOwen101) 146 | 147 | Often it is nice to have an outline of your lesson in a presentation as it gives the lesson some format. It’s usually best to not rely on it to much though and to use lots of different teaching methods! 148 | 149 | ### Research Exercises 150 | 151 | by [@ChrisOwen101](https://github.com/ChrisOwen101) 152 | 153 | Give the students a topic they should research in teams for 10-15 minutes. When the students have completed the research topic they report their findings to the class and share what they have learnt. 154 | 155 | ### Videos 156 | 157 | by [@PGorvitzSH](https://github.com/PGorvitzSH) 158 | 159 | Videos are good to break up the lesson and to refocus the students. Never use a video that is longer than five minutes long and try to avoid ones that are just somebody talking over code, you can do that yourself! 160 | 161 | It's often good to turn on subtitles in the videos so that students can match up the spelling of words to the pronunciation which can be good for non-native English speakers. 162 | 163 | ### Collaborative Coding 164 | 165 | by [@PGorvitzSH](https://github.com/PGorvitzSH) 166 | 167 | Using a website such as [SyncFiddle](www.syncfiddle.com) to have the students work together on a piece of work can be a fun way to break down the barrier between student and teacher. Simply set up a shared workspace on the SyncFiddle website and then send the students to it on Slack. From here you can all work collaboratively on a single piece of code. 168 | 169 | ### CodePen Tasks 170 | 171 | By [@kostasx](https://github.com/kostasx) and [@KPouianou](https://github.com/KPouianou) 172 | 173 | Constructing a small task on CodePen and distributing to the students to complete during the lesson can be a good way to reinforce what the students have just learnt in a lecture. 174 | 175 | See an example for While and For loops here: [CodePen Exercise](https://codepen.io/KPouianou/pen/VQLaVo?editors=0010) 176 | 177 | ## Homework Reviews 178 | 179 | _By [@remarcmij](https://github.com/remarcmij)_ 180 | 181 | This write-up documents the homework review workflow that I (Jim Cramer, @remarcmij) use when reviewing homework submitted as GitHub pull requests for the JavaScript 2 and 3 modules. 182 | 183 | ...continue reading [here](./homework-reviews.md). 184 | 185 | # Energizers: 186 | 187 | > the goal of energizers is to have a small break while seeing similarities between students. And have a quick laugh. 188 | 189 | ## Any module - Energizer: Unique game (can be used as intro 'getting to know each other') 190 | 191 | _By [@daanaerts](https://github.com/daanaerts)_ 192 | 193 | Everybody stands up, has to tell something about himself that is unique, if someone else in the group has the same unique thing the person who said it needs to sit down and does not participate in the game any more. The game is that whoever stands up last wins the game. To make the games shorter you can let the sitting down students still "participate" if they have something in common with one of the students that are still in the game they can still kick someone out of the game. 194 | 195 | ## Any module - Energizer: One lie two truths (can be used as intro 'getting to know each other') 196 | 197 | _By [@M3kH](https://github.com/M3kH)_ 198 | 199 | Everyone stands up. Everyone tells three things about him or herself. Two out of three have to be true, one is a lie. The group has to guess which one of the three is a lie. 200 | 201 | # Module specific tips: 202 | 203 | > These tips can of course be used in multiple modules, they are more about different ways you can interact with your class and make your students involved and participate. 204 | 205 | ## CLI - Game: I go on holiday and I take with me 206 | 207 | _By [@unmeshvrije](https://github.com/unmeshvrije)_ 208 | 209 | _"I go on holiday and I take with me"_ with CLI commands from the week before: 210 | 211 | - They have to repeat the commands said before them. 212 | - Add a new command and explain what it does. 213 | - Let the round continue twice otherwise the students that went first don't have to repeat all the commands. 214 | 215 | E.g., first student says _"ls : lists commands"_. Second student must say _"ls and cd: change directory"_. Then third student must say _"ls, cd and pwd : show print working directory"_ and so on. 216 | 217 | ## GIT - OS concepts and Live coding 218 | 219 | _By [@unmeshvrije](https://github.com/unmeshvrije)_ 220 | 221 | - The teacher should explain the file system if they have no idea about it. 222 | - Students often get warning about new lines (CR and LF characters) because they create UNIX-like files on their Windows machines. In this case, teacher should explain the different between interpretation of new lines in UNIX and Windows. 223 | - To keep the students' attention, create files with funny names and ask students for the contents of files and commit messages. 224 | - For lesson 1, every student along with the teacher, creates a repository **MyFirst** in his/her GitHub accounts. 225 | Together, they create an SSH key, configure email and username. 226 | It is important to make sure **at every step** that no student is lagging behind. It is easy to lose motivation for a student who is lagging behind the class. 227 | - For lesson 2, following online tool is very helpful: http://git-school.github.io/visualizing-git/ 228 | - For lesson 3, students often clone the repository of teacher. Teachers should stress that they should clone the repository which they forked. 229 | 230 | ## Javascript array remembering trick 231 | 232 | _By [@benna100](https://github.com/benna100)_ 233 | 234 | Pop, push, unshift and shift which does what. Well the longest of the word pairs (pop, push) (shift, unshift) makes the array longer, really easy to remember that way. 235 | 236 | ## JavaScript: `map` `filter` `=>` 237 | 238 | _By [@joostlubach](https://github.com/joostlubach)_ 239 | 240 | All students write a little JSON-object for themselves. for example: 241 | 242 | ```js 243 | { 244 | "name": "Joost", 245 | "age": 34, // Hierover mochten ze liegen :-) 246 | "livedIn": [ 247 | { 248 | "country": "The Netherlands", 249 | "town": "Groningen" 250 | }, 251 | { 252 | "country": "The Netherlands", 253 | "town": "Delft" 254 | }, 255 | { 256 | "country": "Canada", 257 | "town": "Montreal" 258 | } 259 | ] 260 | } 261 | ``` 262 | 263 | ## Javascript callstack and eventloop visualisation 264 | 265 | _By [@benna100](https://github.com/benna100)_ 266 | 267 | [http://latentflip.com/loupe/](http://latentflip.com/loupe/) is the perfect tool for visualizing the call stack and event loop. You can as of right now only write es5 javascript, but apart from that there is no limit. 268 | 269 | you can build a small webapp. where they can send in the JSON. you can download all objects as an array. and than you can procces the array with `map`and `filter`. First you can filter out the invalid input, for example people who have put their age in a string, or people who have only filled in one town. 270 | 271 | ## Javascript apis 272 | 273 | _By [@benna100](https://github.com/benna100)_ 274 | 275 | We have had some fun using these apis: 276 | 277 | - The giphy api: [https://developers.giphy.com/docs/#operation--gifs-search-get](https://developers.giphy.com/docs/#operation--gifs-search-get) 278 | - How many people are in space: http://open-notify.org/Open-Notify-API/People-In-Space/ 279 | - Space X launches: https://api.spacexdata.com/v2/launches 280 | 281 | ## JavaScript OOP: build a IMDB web scraper with real time code collaboration 282 | 283 | _By [@M3kH](https://github.com/M3kH)_ 284 | 285 | Start of by letting them all install Atom so they can have live screen sharing and editing. make sure everyone has atom [pair installed](https://atom.io/packages/atom-pair) 286 | 287 | The teacher can start of with live coding and explanation. In the second part of the day we ask students to participate in pairs. They form a team, one is the driver and the other students tells him what to code. The idea is that they add a piece of functionality to the code made in the first half of the class. All of this is of course shown live on the screen in front of the class. 288 | 289 | for example: 290 | 291 | ```js 292 | class Actor { 293 | constructor(name = '') {} 294 | } 295 | ``` 296 | 297 | ```js 298 | class Movie { 299 | constructor(title = '', actors = []) { 300 | this.title = title; 301 | this.actors = actors; 302 | this.finish = false; 303 | this.startDate = new Date(); 304 | } 305 | addActor(actor) { 306 | if (actor instanceof Actor) { 307 | return this.actors.push(actor); 308 | } 309 | } 310 | } 311 | 312 | const Ocean11 = new Movie('Ocean11', [Clooney]); 313 | ``` 314 | 315 | ## Javascript Promises: Learn how to use promises by cooking pasta 316 | 317 | _By [@razpudding](https://github.com/Razpudding)_ 318 | 319 | > Async can be hard to understand without real live example. Cooking is a great example of mixed synchronous and asynchronous tasks. In this assignment we'll cook pasta with promises 💍 320 | 321 | Let's say we want a programme to cook some pasta. Some of the steps involved in cooking pasta are: 322 | 323 | 1. Gathering the ingredients (pasta, garlic, tomatoes, sage, butter) 324 | 2. Cutting the garlic 325 | 3. Cutting the tomatoes 326 | 4. Cooking the water 327 | 5. Cooking the pasta 328 | 6. Baking the garlic 329 | 7. Baking the tomatoes 330 | X. Mixing the pasta with sauce 331 | 332 | If we do this synchronolously there is no chance of it becoming a good meal because the pasta would be cold by the time the vegetables are ready. It would also take way too long this way. So let's fix that! 333 | 334 | 1. Think about how to do this asynchronously; which tasks could be run at the same time? What steps should wait for what other steps? Try to write down a basic recipe (don't write any code yet!) 335 | 2. Now convert your recipe to pseudocode (in markdown). The point is to name functions and show which functions call which other functions. The logic should be there but we'll write the code in the next step. 336 | 3. Write the actual code using promises. Add timeouts to each task (estimate how many minutes a task would take and then set the timeout to that many seconds so 8 minutes for cooking pasta would be 8 seconds in your programme) 337 | 4. Can you get the code to work like you would cook pasta in the kitchen? Try using Promise.all if you want to wait for several tasks to finish. 338 | 339 | 340 | 341 | > Async await really helps simplify asynchronous (promisified) code. The previous example can be improved by applying it. 342 | 343 | 5. Try rewriting your previous attempt using Async/Await. ⏰🍝⏰ 344 | 345 | 346 | 347 | ## RobotApp 348 | 349 | _By [@remarcmij](https://github.com/remarcmij)_ 350 | 351 | The project in [RobotApp repository](https://github.com/HackYourFuture/RobotApp) (mirror at: http://roverjs.taalmap.nl/) was inspired by the [RoverJS](http://roverjs.com/) app developed by @joostlubach. 352 | 353 | The objective of the project is to write a (plain vanilla) JavaScript single page application that rebuilds the RoverJS game board and adds ways to direct the robot towards the flag, using buttons or commands rather than through user-provided JavaScript functions. This is done step-wise through eight different, progressively more advanced versions of the application. 354 | 355 | This project was originally intended for use throughout the JavaScript 1, 2 and 3 modules but soon proved to be far too ambitious, as it attempts to introduce ES6 Classes, the MVC pattern and the Observer pattern in the more advanced versions of the application. Still, the repo may be of interest to JavaScript 3 students who have played with the real RoverJS game and want to know more about how some of its aspects could be implemented. 356 | 357 | ## React - drawing components 358 | 359 | _By [@joostlubach](https://github.com/joostlubach) and [@spirosikmd](https://github.com/spirosikmd)_ 360 | 361 | Draw a sketch of the final app on the flipover, and then students took turns in taking a colour pen drawing boxes around what they considered a component. When we were done with that, we draw a component tree hierarchy. This helped a lot when explaining the input (props) and output (prop handlers) of each component with arrows. Also helped a lot with explaining the data flow between components. What we found handy is that one of us was working with the computer, writing code, explaining the concepts by building an example app, while the other was drawing on the flipover explaining mostly the design decisions we made during the class. 362 | -------------------------------------------------------------------------------- /homework-reviews.md: -------------------------------------------------------------------------------- 1 | # Homework Review Process 2 | 3 | This write-up documents the homework review workflow that I use when reviewing homework submitted as GitHub pull requests for the JavaScript 2 and 3 modules, but I think it is applicable to the other HYF modules too. 4 | 5 | > Recently, I have started to use the VSCode **GitHub Pull Request** extension to streamline the review workflow. With this extension you can quickly check out pull requests without having to individually clone and `npm install` each student's repository. 6 | 7 | When I'm assigned to teach a module I set myself up to **Watch** ('Be notified of all conversations') the corresponding repository on the HYF GitHub organization account, so I get notified when Pull Requests come in and again when they are updated. (I generally **Unwatch** when done teaching.) 8 | 9 | If there are still pull requests from a preceding class I close them so we can start with a blank slate. 10 | 11 | When a new pull request comes in, then, if not done already, I add the GitHub label `homeworkN` (where `N` is 1, 2 or 3) and the label `to review` to the pull request. 12 | 13 | I generally start my reviews on the Friday (in the JS modules we have set the deadline for the pull request on Thursday evening, although only a portion of the students will meet that deadline). I continue the reviews on Saturday, but anything coming in on a Saturday night or Sunday morning will not get a timely review. 14 | 15 | I start by opening my local (cloned) version of the module's HYF repository, say **JavaScript3** in VSCode (make sure that you run `npm install` after cloning). 16 | 17 | Then, for each pull request, starting from the bottom (oldest pull request) working up (newer pull requests) I follow these steps: 18 | 19 | 1. I click on the GitHub Pull Request icon in the VSCode task bar and expand the **All** option. As shown in the picture below, you will see a list of the most recent Pull Requests for this repository. 20 | 21 | ![all-Prs](assets/all-PRs.png) 22 | 23 | **Figure 1**: GitHub Pull Requests extension 24 | 25 | 2. I right-click on the pull request I want to review and select the **Checkout Pull Request** menu option. This will create a local branch in the local repository, e.g. `pr/veliataseven/273` as shown in the VSCode status bar here: 26 | 27 | ![vscode-status-bar](assets/vscode-status-bar.png) 28 | 29 | **Figure 2**: VSCode status bar 30 | 31 | 3. While the VSCode Github Pull Request extension allows local commenting on the pull request, I prefer to do so online, directly in GitHub. To open the pull request in GitHub I right-click again on the pull request in VSCode and select **Open Pull Request in GitHub**. 32 | 33 | 4. On the GitHub pull request page I assign myself as Assignee, and change the label `to review` to `review in progress`. This to ensure that fellow mentors helping out with reviews do not start on the same pull request. (Of course, I'm expecting fellow mentors to do the same). 34 | 35 | 5. I now switch to the regular code window in VSCode by clicking on the Explorer icon in the VSCode task bar and start my actual review. 36 | 37 | > If the student installed additional dependencies in `package.json` you will need to run `npm install` again. For the JavaScript modules this should not be necessary. 38 | 39 | 6. If there are any unit tests as part of the repository I run them and review the results. 40 | 41 | 7. I also run the code (in Node for a CLI app or in the browser with the console open for an HTML app) to ensure that it at least runs without run-time errors. 42 | 43 | 8. On GitHub I then go through the code and insert comments in the pull request. When making the first comment I select **Start a Review**, instead of making single comments. Note that for each single comment GitHub sends out an email notification to all repository watchers. It will only send out a single notification for a complete review. 44 | 45 | 9. Because the JavaScript modules lay the foundation for much of the rest of the curriculum, I tend to comment a lot: 46 | 47 | - Naming: avoid generic names such as `data`, `item`, `element` if more descriptive names are possible; use plurals for arrays and a corresponding singular for an element of that array; avoid cryptic or ambiguous abbreviations; verb-based names for functions, noun-based names for variables and parameters etc. 48 | - No nested named functions, pass all required data through the parameter list. 49 | - In general I try to bring across best practice programming style, and give the rationale for doing things in a particular way. 50 | 51 | 10. I point out fragments of code that do not work, or do not meet the requirements of the assignment. I expect students to follow-up on these comments before their pull request can be approved. 52 | 53 | 11. Sometimes I make recommendations on how things can be done better, more elegant, more efficient, etc. However I don't consider these showstoppers for approving the pull request. 54 | 55 | > Before suggesting a non-trivial coding alternative to students, I try it out by modifying the code in the current branch and running it. When I'm satisfied I copy the relevant code snippet in a comment on GitHub and discard the local changes using the VSCode **Discard Changes** option. 56 | 57 | 12. When done I select **Review changes** in the pull request, add an overall assessment in the comment box and either **Approve** or **Request changes**. 58 | 59 | 13. Finally, I remove the label `review in progress` and either add the label `reviewed` in case the pull request was approved, or `needs work` if I requested changes. 60 | --------------------------------------------------------------------------------