initialize lesson

Author: professor-ben

.gitignore

@@ -0,0 +1,51 @@
+# Created by https://www.gitignore.io/api/node
+
+.DS_Store
+
+### 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,107 @@
+# Intro to CLIs
+
+## Learning Goals
+
+- Use your Python skills to build an interactive command-line application.
+- Follow best practices in CLI design in Python.
+
+***
+
+## Key Vocab
+
+- **Command Line**: a text-based interface that is built into your computer's
+operating system. It allows you to access the files and applications on your
+computer manually or through scripts.
+- **Terminal**: the application in Mac OS that allows you to access the command
+line.
+- **Command Shell/Powershell**: the applications in Windows that allow you to access
+the command line.
+- **Command-Line Interface (CLI)**: a text-based interface used to run programs,
+manage files and interact with objects in memory. As the name suggests, it is
+run from the command line.
+
+***
+
+## Introduction
+
+Now that we're in the home stretch of Phase 3, it's time to prepare for your
+project. You will see the rubric for the project in the next page in this
+module, but before we get there, let's take some time to explore the format for
+the project: a **command-line interface** (or **CLI**).
+
+A CLI is a program that is run from the command-line and provides a text-based
+interface to allow you to carry out various tasks. While the functionality of
+CLIs is limited by the capabilities of Terminal (in Mac OS) and Command
+Shell/Powershell (in Windows), _everything you have learned in Phase 3 can be
+carries out through a CLI._
+
+***
+
+## Lesson Section
+
+Lorem ipsum dolor sit amet. Ut velit fugit et porro voluptas quia sequi quo
+libero autem qui similique placeat eum velit autem aut repellendus quia. Et
+Quis magni ut fugit obcaecati in expedita fugiat est iste rerum qui ipsam
+ducimus et quaerat maxime sit eaque minus. Est molestias voluptatem et nostrum
+recusandae qui incidunt Quis 33 ipsum perferendis sed similique architecto.
+
+```py
+# python code block
+print("statement")
+# => statement
+```
+
+```js
+// javascript code block
+console.log("use these for comparisons between languages.")
+// => use these for comparisons between languages.
+```
+
+```console
+echo "bash/zshell statement"
+# => bash/zshell statement
+```
+
+<details>
+  <summary>
+    <em>Check for understanding text goes here! <code>Code statements go here.</code></em>
+  </summary>
+
+  <h3>Answer.</h3>
+  <p>Elaboration on answer.</p>
+</details>
+<br/>
+
+***
+
+## Instructions
+
+This is a **test-driven lab**. Run `pipenv install` to create your virtual
+environment and `pipenv shell` to enter the virtual environment. Then run
+`pytest -x` to run your tests. Use these instructions and `pytest`'s error
+messages to complete your work in the `lib/` folder.
+
+Instructions begin here:
+
+- Make sure to specify any class, method, variable, module, package names
+  that `pytest` will check for.
+- Any other instructions go here.
+
+Once all of your tests are passing, commit and push your work using `git` to
+submit.
+
+***
+
+## Conclusion
+
+Conclusion summary paragraph. Include common misconceptions and what students
+will be able to do moving forward.
+
+***
+
+## Resources
+
+- [Resource 1](https://www.python.org/doc/essays/blurb/)
+- [Reused Resource][reused resource]
+
+[reused resource]: https://docs.python.org/3/

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)

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))

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)