15-539 Week 5 Team Homeworks

Homework 5: Backend

Small Tasks

• Add token expiration
• Add a development and production settings.py file
• Remove namespaces from file storage api
• Secure key storage solution (environment variable)
• Add error code for bad request types (messed up path, invalid content type, etc)
• Launch an instance of the backend on AWS

Large Tasks

• Permissions design meeting + finish technical spec for permissions
• Implement file ownership
• Create an integrated demo with frontend

Homework 5: UX Design

IDE Team

• Meet with Kosbie to discuss prototype (just sent email to schedule this)
• Revise IDE based on meeting
• [Erika] One person: begin prototyping Student Portal, where Student Portal is how students sign in, view their progress, and access units, exercises, and lessons

• Meet with Sean of the Teacher Portal Team to discuss similarities/differences, key features + anti-features

• [Luca] One person: Meet with a Matt of the Lesson Plan Team to figure out how lessons fit into the IDE (if at all)

• Work with Matt to develop lesson plan wireframe

• [Helen] One person: Meet with Zach and Chris to discuss how exercises fit into the IDE

• Work with Chris and Zach to make wireframe of IDE + exercises

Lesson Plan/Tutorial

• Meet with a members of the IDE team to figure out how lessons fit into the IDE

• Work with member of IDE team to build first wireframe of a lesson plan integrated in

• Review and give feedback on exercise team's work

Exercise Team

• Meet with a members of the IDE team to figure out how exercises fit into the IDE

• Work with member of IDE team to build first wireframe of a exercise integrated in

• Review and give feedback on teacher portal team's work

Teacher Portal Team

• Meet with member of IDE Team who is doing Student Portal to discuss similarities with Teacher Portal + lessons learned from our meeting with Erin

• Develop wireframe of teacher portal

• Review and give feedback for lesson plan team's work

Homework 5: Frontend

Due: Monday, October 2nd, 11:59pm

Frontend Team Meeting

This is Sunday from 12:30-1:30pm, location TBD.

Prototype team

Please message me individually to determine next steps. Please fill out this when2meet by Thursday, noon, so we can schedule some super-quick sync-up meetings.

Training

We are almost done going through the stack! This week, there's only one new topic to learn. For a deliverable, submit a version of your multiple choice app that you've been working on with the addition of asynchronously loaded elements (using Fetch, of course).

• Fetch:

• Fetch is a promise-based, asynchronous, HTTP API. (Click those links if you don't understand those terms)
• Fetch is on its way to becoming a web standard, but you might have to npm install whatwg-fetch --save
• Read how to handle async actions in Redux.
• Find a free, web api (like this Cat image API for example), and use the fetch api to asynchronously load things on your multiple choice app.
• Be diligent in handling errors (i.e. see the fetch( ... ).catch( ... ) documentation)

To help bring together all the concepts we've learned so far, the second part of your hw5 training is to build an entirely new component, using the full stack! Divide yourselves into 2 teams and tackle the following high-priority components.

• Navigation framework

• First, checkout out the mockup. (awesome work from UX!)
• The goal is to replicate as much of the view and functionality as possible.
• Navigation framework refers to the components in blue which make up an 'L' shape spanning the top and left edges of the screen. If you think of a better name, please let me know.
• The main thing here is supporting a 'flow' of content and displaying where a user is in that flow.
• Don't worry about the 'IDE' portion (text editor, console, and canvas)

• IDE prototype

• First, checkout out the mockup. (awesome work from UX!)
• The goal is to replicate as much of the view and functionality as possible.
• The 'IDE' refers to the canvas, text editor, submit button, etc. (essentially everything not 'navigation framework').
• Use Ace Editor (check out the react-ace project) for the actual text editor portion.
• Start with JavaScript: hook up a 'Run' button to eval the code in the editor and output it to a console.
• Then start on the canvas work.
• Do not worry about autograding yet.

Timeline/Deliverables

• Team formation by end of lecture, Thursday

• One person from each team should email me with the full list of team members.

• Architecture proposal by Friday midnight:

• This document, 1 per sub-team, should contain the proposed state tree(s) of the entire application.
• It should also identify the components that are going to be implemented, what slices of the state tree they need, and what actions they dispatch.
• I would recommend meeting as soon as possible to whiteboard an implementation plan.
• This document should be emailed to me, and I'll reply with feedback by noon on Saturday.

• Delivery to the frontend-hw repo, and on Autolab by the due date. There is a folder for each project.

• To practice collaboration, use the following git workflow:

• Branch off of master, using a branch name reflective of the component being implemented.
• Make changes, add, commit, and push.
• Open a PR, and add your team as reviewers.
• Wait for review (these are important! don't be afraid to push back, but always be respectful)
• After review approval, merge the branch into master. (I've given everyone permissions to merge PR's into master now.)

General tips

• Think about how the state tree looks like before writing any code.

• Note that if your team does this well, you'll be able to work very efficiently in parallel.

• Design your components with as little data coupling as possible.

• This means that your components should be as independent as possible. For example, the text editor shouldn't need to access what's currently in the console (or vice versa).

• Strive for simplicity. Someone should be able to deduce the high level what a file/component does in a few seconds. This means keeping one main component per file, and naming things well (which is arguably one of the hardest problems in software engineering).

Homework 5: Autograder

• Pixel matching autograder

• Finish implementing the pixel-matching based autograder prototype using the new animation framework.
• The ImageData API seems promising.

• Fuzzy object tree matching autograder

• Begin a prototype autograder that hooks into the animation framework to populate an internal object tree.
• Decide on a tree-specification syntax, paying special attention to how to handle the 'fuzzy' cases. I.e. If we wanted a rectangle, do we care what color it is? What if they drew an 8-pointed star using 2 rects instead of the start function? (Hard, but interesting questions)

• And of course, keep evaluating any new exercise ideas that come through against our autograding framework options. Summarize any new results (can be pretty informal) in a document named report.md.
• Delivery: on Autolab and the autograder-hw repo (make a hw5 branch).

Homework 5: Graphic Design

• Continue working on component designs (3)

• I'll give you an update on the UX design team's status as soon as possible
• In the meantime, you can choose components that you think have top priority

Homework 5: Textbook

Assignment

• This assignment will be very similar to the last set of assignments, except this time you will ALL be working together (to some degree) on the same product.
• You will meet to decide on an overarching topic to cover for the next two weeks. For example, if you are interested in doing for and while, your choice would be a chapter on loops.
• You will decide on a separate lesson within the chapter to cover as well as the order that each lesson should be taught. For example if you chapter is on conditional code execution you would cover if before else before elif.
• You will then work on an outline of your lesson (similar to hw3) which you will then peer review with the students at either (read both) side of your lesson.

• That is to say: If you are the second lesson you will be peer reviewed by lesson 1 and lesson 3. This is to make sure each lesson is fluid in transition.
• If you are an edge lesson (i.e. 1 or 5) you will peer review with your adjacent lesson and with each other.

Few things to remember:

• Each of you experienced the difficulty in judging just how much each student knew by the time they got to your individual lesson. You will take this into account for this assignment. While judging textbook layout might be harder, you must be cognizant of this within your chapter.
• For example, if the lesson goes object->constructor->method->... you cannot talk about a method if you are in the lesson for constructors (unless of course you reference it as future material, but you cannot go in-depth or demand too much).
• Storyboard this week if possible. While only the chapter outline and text is due this week try to have a general idea about what tool you will be using next week. Furthermore, feel free to include rough ideas for graphics/widgets inside your outline!

What to submit:

• All of this should be inside a separate folder name Textbook-Submission:
• Your own lesson outline, along with your thoughts on this design process. Critiques, suggestions, complaints etc. (txt, pdf, or md).
• The peer reviews by your two partners (txt, pdf, or md).
• The final chapter outline and writeup (txt, pdf, or md).
• (optional) Challenges/Ideas/Revelations or other cool things that we should be aware of! (Separate folder within Textbook-Submission)

Looking forward to your chapter!

Homework 5: Accessibility

Last week, you condensed our guidelines into a document that we can pass along to our other teams. We now have a basic outline for best practices when it comes to designing accessible web content.

This week, I’d like to expand on that a bit further. First, I’d like you to do some more research. Spend some time on this website researching how to make web content accessible. In particular, there are two sections that I think would be valuable to read:

• Developing Organizational Policies on Web Accessibility 
• How People With Disabilities Use the Web: Overview

I’d like you to thoroughly read these sources and take detailed notes. If you feel like you’ve read something that needs to be reflected in the course guidelines we wrote last week, take special care to make note of that so we can keep up-to-date documentation.

The first article is especially important. Right now, we have a rough set of guidelines. But I want to have a way to enforce that our content is actually accessible, not just give a loose set of rules to our developers that we hope they will follow. After reading the first article, I’d like you to find some time to meet briefly as a group to define a strategy we can follow to ensure that all of our content is accessible before it gets released. I’d like there to be one document for the entire group that we can go over at our next meeting.

What to Submit?

• Your notes from the readings
• A link to a Google Doc containing your strategy proposal for how we will enforce that our content is accessible and in compliance with the guidelines we laid out last week

Homework 5: Video Team

Group work:

• The bulk of the work this week will be done collaboratively (going over last week's work, recording/editing a sample video, etc).
• Grading for group work will be based on attendance at and participation during group meetings/work sessions (which will be scheduled soon)

Individual work:

• We need to determine whether or not it's feasible to do captioning ourselves (without using a paid service).
• Using the attached starter file (YouTube's initial captioning), follow along with the original video and fix the issues that you find with YouTube's automatic captions.
• Make sure to time yourself when you do this! We're trying to find out how long the process takes, so exactly how long it took you to fix the captions for this video (as well as the updated captions file).

Homework 5: Media Team

Last week, you continued to organize our media content. This week, I’d like to expand on that a bit more, and also account for some logistical/administrative things related to how our team will operate.

One idea that I saw in a homework submission last week was to include in all of our folders a small writeup about where similar content could be found online. So for example, if you open up one of our folders looking for a sprite, and none of them are quite right, you have resources to search online for the exact media you need. I like this idea, and think that we should start to implement that this week.

On a more logistical note, we should also decide on standard file formats for different types of media. For example, should all of our backgrounds be PNG files? Should our sprites be GIFs? These may not be the most interesting questions but they are ones we need to answer. I have no experience in this area, so I am interested to hear your research about what best practices are for these sorts of things.

What to Submit?

• Add writeups (as PDF documents) to the Google Drive detailing where to find similar media

• One for each media folder
• Divide this work amongst yourselves
• For each writeup, include the author in the heading

• A proposal for what format to use for different media types so that we can be consistent going forward

Homework 5: Extended Framework

Due Monday October 2nd 11:59PM (via Autolab)

The great thing about web APIs is that they can bring a heavyweight punch to a small piece of code. For us, this means we can bring truly exciting content into our lessons without having to write a bunch of complicated code ourselves. This assignment aims to show you how using external APIs/extended frameworks can be a tool that makes learning more fun for students.

In the past few assignments, you have been working with data-centric APIs. This is great practice for learning APIs, but we want you to take it to the next level for this assignment. Now that you know how to use a web API, find one with a real WOW factor that would excite students, and use it to make an engaging Python lesson. A good way to engage students is to provide them with a small piece of code that they can edit, a "plugin function", that greatly changes what the output of an advanced program (the one using the API).

Ideally, the plugin function that students edit would be flexible enough so that a created/motivated student could make something different from their classmates, and maybe even get competitive with who can make the coolest plugin. Strive to make an app whose output is cool enough that students would want to stay after class to explore it further, to write it a different way, to keep write code for the fun of it. It's a tall order, but we should try to make assignments that don't just teach students how to code but teach them to love to code. Extended frameworks are a great way to make learning to code a lovable experience.

Here are some categories for exciting APIs that might help you get thinking about how to use APIs to build engaging experiences:

- Multimedia - how can we use video, sound, or images to engage students? Maybe they'd like to auto-tune their voice, make music, or add visual effects using something like deepart.io. Maybe even Snapchat filters!

- Natural Language Processing - Interactive experiments can be text-based too. Check out text to speech, speech to text, sentiment analysis, and translation APIs.

- Trends - Twitter hashtags? Trending Google searches? These APIs might still deal with raw data,  but they can be engaging because students can relate to current trends and events.

What to turn in:

Your deliverable should consist of 2 documents, in an "Extended Frameworks" directory within your zipped homework handin:

• A python file, with a main() method, so we can run it, that does something "exciting" with an API. Hopefully, this means that it will be making noise, popping up a cool display, or having some other visible interaction. Please provide at least 2 implementations of your plugin function to show that it can create a variety of outputs if students are creative in what they implement.
• A PDF file describing how to turn the program you wrote into a lesson. Writing a detailed lesson plan is beyond the scope of this project, but please indicate what skill the assignment would help students build (e.g. for-loops, conditionals). Also, include short descriptions of how your >=2 plugin implementations work.

Unlike previous assignments, you won't only be graded on completion, we are also grading you on how engaging your activity is. Post in slack about APIs you plan to use so we can collaborate to find exciting ones, and to avoid duplicates.

Good luck, and have fun!

Homework 5: CS Pedagogy & Competitive Analysis

• Competitive Analysis

• In groups develop a rubric that we can use to write reports on the different products to be able to compare them (develop one rubric as a group)
• Use the rubric to write a report about Karrell program to judge how the rubric is useful
• Keep looking into competitive analysis and finding useful information to present

• Pedagogy

• Keep doing research but in more specific areas

• Pair Programming and development in classrooms
• Psychology of 9th graders
• Math classes for 9th graders in general and example tests and such