Initialize Content

Author: linda-seiter

.github/workflows/canvas-sync.yml

@@ -0,0 +1,31 @@
+name: Sync with Canvas
+
+on:
+  push:
+    branches: [master, main]
+    paths:
+      - "README.md"
+
+jobs:
+  sync:
+    name: Sync with Canvas
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Set up Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: 2.6
+
+      - name: Install github-to-canvas
+        run: gem install github-to-canvas
+
+      # Secret stored in learn-co-curriculum Settings/Secrets
+      - name: Sync from .canvas file
+        run: github-to-canvas -a -lr 
+        env:
+          CANVAS_API_KEY: ${{ secrets.CANVAS_API_KEY }}
+          CANVAS_API_PATH: ${{ secrets.CANVAS_API_PATH }}

.gitignore

@@ -0,0 +1,52 @@
+# Created by https://www.gitignore.io/api/node
+
+.DS_Store
+.vscode
+
+### Node ###
+# Logs
+logs
+*.log
+npm-debug.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules
+jspm_packages
+
+# Optional npm cache directory
+.npm
+
+# Optional REPL history
+.node_repl_history
+
+# Learn-specific .results.json
+.results.json
+
+# Ignore bundler config.
+/.bundle
+
+# Ignore the default SQLite database.
+/db/*.sqlite3
+/db/*.sqlite3-journal
+
+# Ignore all logfiles and tempfiles.
+/log/*
+!/log/.keep
+/tmp
+
+# Virtual env metadata
+.venv
+
+# pytest cache
+.pytest_cache

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing to Learn.co Curriculum
+
+We're really exited that you're about to contribute to the [open
+curriculum](https://learn.co/content-license) on [Learn.co](https://learn.co).
+If this is your first time contributing, please continue reading to learn how to
+make the most meaningful and useful impact possible.
+
+## Raising an Issue to Encourage a Contribution
+
+If you notice a problem with the curriculum that you believe needs improvement
+but you're unable to make the change yourself, you should raise a Github issue
+containing a clear description of the problem. Include relevant snippets of the
+content and/or screenshots if applicable. Curriculum owners regularly review
+issue lists and your issue will be prioritized and addressed as appropriate.
+
+## Submitting a Pull Request to Suggest an Improvement
+
+If you see an opportunity for improvement and can make the change yourself go
+ahead and use a typical git workflow to make it happen:
+
+- Fork this curriculum repository
+- Make the change on your fork, with descriptive commits in the standard format
+- Open a Pull Request against this repo
+
+A curriculum owner will review your change and approve or comment on it in due
+course.
+
+## Why Contribute?
+
+Curriculum on Learn is publicly and freely available under Learn's
+[Educational Content License](https://learn.co/content-license). By embracing an
+open-source contribution model, our goal is for the curriculum on Learn to
+become, in time, the best educational content the world has ever seen.
+
+We need help from the community of Learners to maintain and improve the
+educational content. Everything from fixing typos, to correcting out-dated
+information, to improving exposition, to adding better examples, to fixing
+tests—all contributions to making the curriculum more effective are welcome.

LICENSE.md

@@ -0,0 +1,23 @@
+# Learn.co Educational Content License
+
+Copyright (c) 2021 Flatiron School, Inc
+
+The Flatiron School, Inc. owns this Educational Content. However, the Flatiron
+School supports the development and availability of educational materials in the
+public domain. Therefore, the Flatiron School grants Users of the Flatiron
+Educational Content set forth in this repository certain rights to reuse, build
+upon and share such Educational Content subject to the terms of the Educational
+Content License set forth [here](http://learn.co/content-license)
+(http://learn.co/content-license). You must read carefully the terms and
+conditions contained in the Educational Content License as such terms govern
+access to and use of the Educational Content.
+
+Flatiron School is willing to allow you access to and use of the Educational
+Content only on the condition that you accept all of the terms and conditions
+contained in the Educational Content License set forth
+[here](http://learn.co/content-license) (http://learn.co/content-license). By
+accessing and/or using the Educational Content, you are agreeing to all of the
+terms and conditions contained in the Educational Content License. If you do not
+agree to any or all of the terms of the Educational Content License, you are
+prohibited from accessing, reviewing or using in any way the Educational
+Content.

README.md

@@ -0,0 +1,29 @@
+# Deserialization : Code-Along 
+
+## Learning Goals
+
+- Goal 1 
+
+---
+
+## Key Vocab
+
+- **term**: definition
+
+---
+
+## Introduction
+
+Introduce topic
+---
+
+## Conclusion
+
+
+## Solution Code
+
+```
+
+---
+
+## Resources

lib/__init__.py

@@ -0,0 +1,39 @@
+"""
+pytest requires that all testing modules, classes, methods, and functions
+contain the word "test" somewhere within them.
+
+The conventions for naming tests in the Python curriculum are as follows:
+
+    - One test module should be created for each class. If there are no classes
+      to test, one test module should be created for each module being tested.
+    - Test modules should be named {classname}_test.py, or {modulename}_test.py
+      if necessary.
+    - Test modules should be located at the base of the "testing" package.
+    
+    In {classname}_test.py:
+        - There should be one testing class, named Test{Classname}.
+        - The testing class should contain the following docstring:
+            
+            '''Class {Classname} in {modulename}.py'''
+
+        - There should be at least one testing method for each instance, class,
+          or static method belonging to the class being tested, including
+          __init__.
+        - Each testing method should be named test_{performs/does_behavior},
+          where {performs/does_behavior} is a clear and concise description of
+          the desired behavior.
+        - Each testing method should only test one behavior.
+        - Each testing method should contain the following docstring:
+
+            '''performs/does behavior when {x} happens.'''
+
+            ...where {x} describes the manipulation that takes place within
+            the test.
+"""
+
+class TestClass:
+    '''Class {Classname} in {modulename}.py'''
+
+    def test_performs_behavior(self):
+        '''performs behavior when something happens.'''
+        assert(False)

lib/testing/__init__.py

@@ -0,0 +1,9 @@
+#!/usr/bin/env python3
+
+def pytest_itemcollected(item):
+    par = item.parent.obj
+    node = item.obj
+    pref = par.__doc__.strip() if par.__doc__ else par.__class__.__name__
+    suf = node.__doc__.strip() if node.__doc__ else node.__name__
+    if pref or suf:
+        item._nodeid = ' '.join((pref, suf))

lib/testing/class_test.py

@@ -0,0 +1,44 @@
+"""
+pytest requires that all testing modules, classes, methods, and functions
+contain the word "test" somewhere within them.
+
+The conventions for naming tests in the Python curriculum are as follows:
+
+    - One test module should be created for each class. If there are no classes
+      to test, one test module should be created for each module being tested.
+    - Test modules should be named {classname}_test.py, or {modulename}_test.py
+      if necessary.
+    - Test modules should be located at the base of the "testing" package.
+
+    In {modulename}_test.py:
+        - There should be one testing class for each function, named
+          Test{Functionname}.
+        - Each testing class should contain the following docstring:
+
+            '''Function {functionname}() in {modulename}.py'''
+
+        - Each testing method should be named test_{performs/does_behavior},
+          where {performs/does_behavior} is a clear and concise description of
+          the desired behavior.
+        - Each testing method should only test one behavior.
+        - Each testing method should contain the following docstring:
+
+            '''performs/does behavior when {x} happens.'''
+            
+            ...where {x} describes the manipulation that takes place within
+            the test.
+"""
+
+class TestFunctionA:
+    '''Function {functionname}() in {modulename}.py'''
+
+    def test_performs_behavior(self):
+        '''performs behavior when something happens.'''
+        assert(False)
+
+class TestFunctionB:
+    '''Function {functionname}() in {modulename}.py'''
+
+    def test_performs_behavior(self):
+        '''performs behavior when something happens.'''
+        assert(False)