From the guide:
Week 1 focuses on HTTP, web security, APIs and testing. In week 1 you will:
- Build your own HTTP server to understand the fundamentals of the HTTP protocol
- Defend your HTTP server against attack to understand classic web security vulnerabilities
- Support API access to your server to understand HTTP from a non-browser perspective
- Build a Github client that encapsulates API requests in objects to prep you for work in a service-oriented architecture
##Challenge: Building an HTTP Server ###Branch: HTTP, Methodical Aproach ###Description Students build an HTTP Server from scratch (TCP). This a long project (2-3 days) with a lot of moving parts, so refactoring is a major component.
###Competencies Covered Nearly all of the HTTP branch is covered. Does not cover:
- REST specifically, though HTTP methods and their purpose are identified, discussed, and must be used appropriately
- Sinatra or Rails
- AJAX
Refactoring in the Methodical Approach branch is covered (see description).
###Adaptation for P1-3
We could adapt this challenge by having students build "Sinatra Jr" on top of Rack. Used at its most bare-bones, Rack provides parsing of headers and requests with no abstractions on top. Students could write code to handle:
- Request routing
- Cookie reading and setting
- Basic templating (gsub, nothing fancy)
- Sessions
Like the HTTP Server challenge, I would ask students to first interact with their server by hand using netcat. Later they could graduate to the browser, seeing that the browser is doing the same thing they were doing typing text into nc.
##Challenge: Web Security ###Branch: HTTP ###Description Students identify common client-side exploits of cookies by exploiting each others' servers and fixing vulnerabilities in their own.
###Compentencies Covered No existing mapping to the skills tree.
If we had compentencies this challenge represented they would be:
- knowledge of XSS
- insecurity of raw cookies
- encryption of cookies
- cookie hijacking
- script injection
- dangers of third party JS
###Adaptation for P1-3
The server could already be provided, leaving students to only accomplish the exploit. This would be a tiny wargame. I would implement the first and second exploits — modifying cookies on the client to demonstrate the client can't be trusted, and using script injection to lift cookies. I think this is entirely possible in P2 if we decide it's important, and I don't think it would take very long at all (with guidance, perhaps 1-3 hours or less).
##Challenge: Supporting an API ###Branch: HTTP ###Description Students build out their servers further to response to the Content-Type header
###Compentencies Covered This doesn't appear to map to any other existing competencies directly, though it does cover the idea of headers indirectly, generating appropriate server responses, and the client/server roles.
###Adaptation for P1-3
This could be an extension of their Rack server (or they can be given a reference solution). It's a short challenge, and could be simplfied if they were asked to simple present some static data as HTML or JSON based on content-type. This could be a very short challenge.
##Challenge: Github API Client ###Branch: HTTP ###Description Students build a Github API client around Net::HTTP, similar to ActiveRecord in its construction.
###Compentencies Covered Given docs for an HTTP API, create a client that can interact with the API server.
###Adaptation for P1-3
I've heard teachers already doing something like this in P2 in Chicago. I think a simplified version of this challenge with reduced requirements is perfectly tenable in P2.
From the guide:
In Week 2 you will learn about and implement several Abstract Data Structures. You will analyze their characteristics, and their pros and cons by determining the Big-O complexity of their operations.
Your capstone project will require you to leverage your new found knowledge to produce a maze solver and pathfinding AI.
You will:
- Learn about and discuss fundamental data structures from an abstract perspective so that you can discuss them in a language-agnostic manner on your team
- Implement data structures in multiple languages to understand how they work
- Learn the strengths of weaknesses of various data structures in order to make informed choices Apply your knowledge of data structures to produce classic algorithms
There are currently 11 data structure drills, followed by three algorithm-heavy challenges. These don't appear to map to any existing skill branches.
All challenges require students to implement the data structure along with its classic operations. Students are asked to analyze and describe the Big-O of each method in their solution.
Data structures can only be implemented using the data structures the students create themselves. For example, the ArrayList leverages the FixedArray. FixedArray is the only exception, which uses a Ruby Array under the hood.
###Competencies Covered
All of the ADS drills cover:
- Big-O analysis
- Technical comprehension (reading a spec, producing an implementation)
- Algorithmic thinking
- Abstract reasoning
###Adaptation for P1-3
If we were to adapt these challeneges to P1-3, we should consider providing the RSpec tests and asking students to conform to them. This gives students a clear idea of how one uses the data structure, and will help guide them. An explanation up front of Big-O would also be necessary.
FixedArrays through Sets (inclusive) are challenging but relatively simple.
Map, Trees, Graphs and Hashes are more difficult and time consuming.
##Challenge: Fixed Arrays ###Branch: Unknown ###Description Produce a simple "Fixed Array" that has a static size once it is created. This will mimic "true" arrays as they exist at a lower level. The FixedArray students create forms the foundation for the data structures that follow.
##Challenge: Array Lists ###Branch: Unknown ###Description Produce a basic Array List, i.e. an array that grows dynamically as items are added. The Array List uses a Fixed Array underneath and students must implement an underlying growth strategy.
##Challenge: Linked List ###Branch: Unknown ###Description Produce a simple Linked List. Later releases require students to create a double linked list. We may prompt them to produce the DLL instead of asking them to figure it out. Currently the challenge only specifies that they achieve certain Big-O for certain operations, a DLL is necessary to achieve this Big-O.
##Challenge: Stack ###Branch: Unknown ###Description Produce a simple stack, determine which of the data structures they have created would be the right one to use in their implementation.
##Challenge: Queue ###Branch: Unknown ###Description Produce a simple queue, determine which of the data structures they have created would be the right one to use in their implementation.
##Challenge: Set
###Branch: Unknown
###Description
Produce a simple Set, conforming to the set interface and its characteristics. Determine the correct data structures to use underneath, and implement basic set operations like union and intersection.
##Challenge: Map ###Branch: Unknown ###Description Implement a Map. The Map does not need to be a HashMap (constant time is not necessary), it just needs to support key/value pairs.
##Challenge: Graph ###Branch: Unknown ###Description Implement a graph and basic graph search with DFS. Students are pushed to implement search recursively, not iteratively.
##Challenge: Tree & TreeList ###Branch: Unknown ###Description Implement a basic tree. The tree does not need to be a binary tree, nor does it need to be ordered.
Later, students are asked to implement an ordered TreeList. The TreeList should use an ordered binary tree under the hood. Tree and TreeList could (should) be separate challenges.
##Challenge: HashMap and HashSet
###Branch: Unknown
###Description
Implement a hashmap that can use strings as keys. Students are required to use some basic string hash function. The discovery or creation of the hash function is limited to 30 minutes, and if nothing else they can use Object#hash. Collisions should be resolved using linked list chains off each hash bucket (aka "separate chaining".
Later, students are asked to implement a HashSet conforming to the Set interface. The HashSet uses a HashMap underneath to achieve constant-time set operations.
##Challenge: Maze Solver Challenge ###Branch: Unknown ###Description
Implement a maze solver. The solver, given a map, should determine whether a path exists from the entrance to the exit.
Students are asked to implment two versions, each that explore slightly differently. These are DFS and BFS, though they may not know it!
###Competencies Covered This challenge doesn't seem to map to existing compentencies. If I had to describe more high-level takeaways they would include:
- Code organization
- "Algorithmic thinking"
- Abstract reasoning (the solution is language agnostic)
###Adaptation for P1-3
I made a P1 adaptation while in SF as an experiment. I think it might have been too easy, but since I wasn't there to deliver I don't truly know.
##Challenge: A-Star Challenge ###Branch: Unknown ###Description
Students are asked to implement DFS, BFS, simple heuristic, and A* pathfinding algorithms. In addition to the challenges of algorithmic and abstract thinking, code organization is critical given the scope of the project.
###Competencies Covered
- Code organization
- "Algorithmic thinking"
- Abstract reasoning (the solution is language agnostic)
- Technical comprehension (reading algorithmic specifications)
###Adaptation for P1-3
I don't know if this is realistic for P1-3, however it could be a good stretch for students that need to be pushed outside their comfort zone.
#Testing
All challenges in Onboard require complete test coverage, including some situations that are difficult to test. In this sense, all of Onboard covers testing.
To address web application testing directly, students are given the "Flying Blind" challenge.
##Challenge: Flying Blind ###Branch: Testing ###Description
Students must build a fully functioning Rails app without opening the browser. They are required to fetch data from Github as their backend to simulate Wealthfront's service-based backend (no database at the Rails layer).
Students use their Github API clients from Week 1 to fetch the data required to produce a "Github Lite" — this includes basic profile pages, repository creation and repository pages.
Students are required to write model, view and controller tests.
They must also write JS client-side JS tests. They use QUnit to test their Javascript, and view tests to prove the JS they're using is in place and being produced correctly.
###Competencies Covered This challenge maps more naturally to the skill tree than the others. I believe the following competencies are covered:
- Lists benefits of testing-driven development.
- States the conventional name of an RSpec testing directory.
- States the command line command and flag for setting up RSpec.
- Explains what makes a good test.
- Explains the red-green-refactor cycle.
- Explains the benefits of testing objects in isolation.
- Explains the benefits and risks of using doubles.
- Explains the benefits and risks of using mocks.
- Explains the benefits and risks of stubbing.
###Adaptation for P1-3
A vastly simplified version of this, with ActiveRecord, could work in P3. It would force more fluency and discipline with Rails MVC tests. We might ask them to build a trivial version of twitter (even as little as "read a tweet, post a tweet").
#JS
##Challenge: A-Star to JS ###Branch: Javascript ###Description
Translate the A* implementation to Javascript. Students are required to properly separate concerns, allowing them to create terminal (node-based) and web front-ends to the solver.
###Competencies Covered
I think A* in JS is a larger JS project than students are typically exposed to in P1-3, and it's in "pure" JS — the DOM only enters the picture later, and it's not necessary that it does.
Students will be required to be effective with JS fundamentals: object creation and organization, first-class functions, async programming (setTimeout), string manipulation, control structures and basic mathematical computation.
###Adaptation for P1-3
I don't know if this challenge is reasonable in P1-3, but I do like that they have to use "pure JS" without the DOM. I think we lack that somewhat in the existing curriculum. We might take the P1 version of a maze solver and have them do it in node only (ignoring HTML/DOM).
##Challenge: DBC Inbox ###Branch: Javascript, HTTP ###Description
Students are required to build a single page app that represents a simple email inbox. The API server is provided to them, they need only implement the HTML and JS.
The API is purposefully inefficient, requiring them to make nested asynchronous calls. Most students have not been exposed to this.
Students need to make use of deferreds to create pipelines to manage the complex asynchronous situation they're presented with, including use of then() and passing/receiving deferreds through their program.
###Competencies Covered
Not sure how neatly this really maps, but if I had to describe the competencies I needed it to cover, they would be:
- Interacting with an API from the client
- Handling asynchronous situations
- Handling nested asynchronous situations
- Effective use of Deferreds/Promises
- Client-side templating
###Adaptation for P1-3 A one-off P2 version of this was created for the Squirrels. It was too difficult for the general cohort. The key here is dealing with more complex async situations, and to gain a little experience with single page apps. I think a significantly simplified version of this could be made for P2, but only if we determine the lessons it's teaching are reasonable for P1-3. I'm not sure.
#Functional Programming
While I believe students can get a great deal of benefit from the functional programming challenges, they don't remotely map to anything we do in our 9-week program.
Nonetheless, if I had to describe what I want students to get out of it, I would say:
- Achieve complete comfort writing recursive code (students cannot use loops in these challenges)
- Break out of the imperative and OOP mindsets.
- Understand functional concepts like function passing, higher order functions, recursion, immutability, pure functions, function composition, currying
- Understand that solutions can be composed of pure functions
- Understanding that widely-scoped state is not a requirement in building software
- Understanding that mutable data is not a requirement in building software
By using a purely functional language like Racket (Lisp), I'm trying to break a multitude of preconceptions and assumptions students have acquired by this point in their learning. It's a fundamentally different way of thinking, and I don't think it will be easy or comfortable.
I have not yet delivered this unit.
These challenges are in a rough state, but I still think the intro can serve as a basic primer in functional programming and Lisp.
I fear the Enigma challenge is too difficult for Onboard, but we'll see.
###Adaptation for P1-3
In a perfect world I get to throw Lisp at our students, but I'm a realist ;)
A series of restrictions on a Ruby project could accomplish goals similar to those of the functional programming unit. For example, I have considered asking students to implement Sudoku without classes, using only pure methods, using small methods and composing them, never re-assigning variables, and never mutating values. If we determine that it's important (and I think it is, but it's debatable), a P1 challenge could be accomplished.
A live-code that hits some, but not all, of these principles was produced for the Columbus Sea Lions.