Commit df31bec7 authored by Rob Muhlestein's avatar Rob Muhlestein 🎧

initial

parent 368450e5
......@@ -44,7 +44,6 @@ distros
dk
docker
domain
drivers
eastereggs
ed
editor
......@@ -82,6 +81,8 @@ jobs
kbase
knode
knowledge
knowledge/cicd
knowledge/git
languages
learning
lfh
......@@ -91,6 +92,7 @@ localrepos
logistics
markup
md
motivate
mvkb
netlify
networking
......
......@@ -2,11 +2,20 @@
Title: Change Log
---
Aere are the major changes to this [knowledge app](/pka/). Refer to this rather than `git log` since other [smaller changes are made frequently](/knowledge/git/).
## Wednesday, May 20, 2020, 9:56:06AM
* Change log introduction
* [Long term todo list](/todo/#long-term)
* [Git Knowledge](/knowledge/git/)
* [CI/CD of Knowledge Source](/knowledge/cicd)
## Tuesday, May 19, 2020, 5:02:14PM
* Added *Make a Learning Plan to Day 1*
* [TODOs](/todo/)
* [Early Drivers for Tech Learning](/drivers/)
* [Early Motivators for Tech Learning](/motivate/)
* [Set Up Local GitLab Project Repos](/localrepos/)
* [Git Host Service Ping](/gitping/)
......
......@@ -38,11 +38,19 @@
<main class=content>
<a id=top></a>
<h1>Change Log</h1>
<p>Aere are the major changes to this <a href="/pka/">knowledge app</a>. Refer to this rather than <code>git log</code> since other <a href="/knowledge/git/">smaller changes are made frequently</a>.</p>
<h2 id="wednesday-may-20-2020-95606am">Wednesday, May 20, 2020, 9:56:06AM</h2>
<ul>
<li>Change log introduction</li>
<li><a href="/todo/#long-term">Long term todo list</a></li>
<li><a href="/knowledge/git/">Git Knowledge</a></li>
<li><a href="/knowledge/cicd">CI/CD of Knowledge Source</a></li>
</ul>
<h2 id="tuesday-may-19-2020-50214pm">Tuesday, May 19, 2020, 5:02:14PM</h2>
<ul>
<li>Added <em>Make a Learning Plan to Day 1</em></li>
<li><a href="/todo/">TODOs</a></li>
<li><a href="/drivers/">Early Drivers for Tech Learning</a></li>
<li><a href="/motivate/">Early Motivators for Tech Learning</a></li>
<li><a href="/localrepos/">Set Up Local GitLab Project Repos</a></li>
<li><a href="/gitping/">Git Host Service Ping</a></li>
</ul>
......
......@@ -4,4 +4,4 @@ Subtitle: Capturing, Maintaining, and Sharing Knowledge as Source Code
tpl-hdsearch: true
---
We live in a time when the amount of human knowledge has reach unprecedented levels and grows exponentially, but we are at risk. So much knowledge is being produced in different forms that strategies for maintaining and archiving it in a way that is not owned by proprietary interests have been all but ignored. By applying the best practices and lessons learned from managing and distributing opensource software source code to *knowledge* source we can leverage all the same successes these projects have enjoyed. This begins by capturing the knowledge is a [simple form](/basicmark/) such that source management and version control tools can work with it and then building building [knowledge applications](/pka/) from the that source.
We live in a time when the amount of human knowledge has reach unprecedented levels and grows exponentially, but we are at risk. So much knowledge is being produced in different forms that strategies for maintaining and archiving it in a way that is not owned by proprietary interests have been all but ignored. By applying the best practices and lessons learned from managing and distributing opensource software source code to *knowledge* source we can leverage all the same successes these projects have enjoyed. This begins by capturing the knowledge is a [simple form](/basicmark/) such that source management and version control tools [can work with it](git/) and then building building [knowledge applications](/pka/) from the that source.
---
Title: Continuous Integration and Deployment of Knowledge Source
---
Due to the amount of frequent changes made to knowledge source and the necessity for testing to be done by humans it does not make sense to automate integration of testing. Instead create tools for auditing and checking broken links, spelling, grammar, and such that are used during the content creation process, while it is being written.
## Single Editor
Like most traditional publications knowledge source applications benefit most from a single editor making all the final decisions and often doing the actual work of placing the content into the application. This is a stark contrast from the [wiki](/wikis/) approach and ensures the overall [PKA](/pka/) maintains all the advantages of traditional publications:
* Coherent voice
* Single final decision maker
* High quality
* Attention to spelling and grammar
* Less redundancy
## Keep Things Static
Keeping all content pushed to the Git hosting provider and then indirectly to [Netlify](/netlify/) is essential to maintain what would otherwise be an overuse of processing power to build out the changes during the deployment process.
## No Merge Requests
The ultra-dynamic nature of knowledge source development does not lend itself well to the merge request process --- particularly because each release must include a full meta data generation process to create the localized `meta.json` file. Content developers must coordinate their efforts in ways that are not conducive to the typical merge request process. Use issues instead.
## Issues as Errata
Issues can and should be opened containing corrections and suggestions that a *single* editor can then place into the main content. Since the issues themselves using the same [Markdown](/md/) format used for the knowledge source itself this becomes a matter of cutting and pasting from the issue into the master source branch.
<!doctype html>
<html lang="en">
<head>
<title>Continuous Integration and Deployment of Knowledge Source | RWX.GG</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate"/>
<meta http-equiv="Pragma" content="no-cache"/>
<meta http-equiv="Expires" content="0"/>
<!-- link rel="shortcut icon" href="/assets/img/logo.png" type="image/png"-->
<link rel="preload" href="/assets/styles.css" as="style">
<link rel="stylesheet" href="/assets/styles.css">
</head>
<body>
<div id=pagebg></div>
<header class=nav-bar>
<nav>
<div class=sidebar-button></div>
<div id=bwtoggle></div>
<a class="homelink spy" href="/">r<span class=hideable>wx.gg</span></a>
<div class="nav-right">
<!-- div id=search-box></div -->
<ul class=nav-links>
<li class=nav-item><a class=nav-link href="/overview/">Overview</a></li>
<li class=nav-item><a class=nav-link href="/schedule/">Schedule</a></li>
<li class=nav-item><a class=nav-link href="/books/">Books</a></li>
<li class=nav-item><a class=nav-link href="/changes/">Changes</a></li>
<li class=nav-item><a class=nav-link href="/contrib/">Contribute</a></li>
<li class=nav-item><a class=nav-link href="https://twitter.com/rwxrob">Twitter</a></li>
<li class=nav-item><a class=nav-link href="https://www.youtube.com/playlist?list=PLrK9UeDMcQLrO5fwV5smfNvau0PAP16-I">YouTube</a></li>
<li class=nav-item><a class=nav-link href="https://discord.gg/9wydZXY">Discord</a></li>
<li class=nav-item><a class=nav-link href="https://twitch.tv/rwxrob">Twitch</a></li>
</ul>
</div>
</nav>
</header>
<main class=content>
<a id=top></a>
<h1>Continuous Integration and Deployment of Knowledge Source</h1>
<p>Due to the amount of frequent changes made to knowledge source and the necessity for testing to be done by humans it does not make sense to automate integration of testing. Instead create tools for auditing and checking broken links, spelling, grammar, and such that are used during the content creation process, while it is being written.</p>
<h2 id="single-editor">Single Editor</h2>
<p>Like most traditional publications knowledge source applications benefit most from a single editor making all the final decisions and often doing the actual work of placing the content into the application. This is a stark contrast from the <a href="/wikis/">wiki</a> approach and ensures the overall <a href="/pka/">PKA</a> maintains all the advantages of traditional publications:</p>
<ul>
<li>Coherent voice</li>
<li>Single final decision maker</li>
<li>High quality</li>
<li>Attention to spelling and grammar</li>
<li>Less redundancy</li>
</ul>
<h2 id="keep-things-static">Keep Things Static</h2>
<p>Keeping all content pushed to the Git hosting provider and then indirectly to <a href="/netlify/">Netlify</a> is essential to maintain what would otherwise be an overuse of processing power to build out the changes during the deployment process.</p>
<h2 id="no-merge-requests">No Merge Requests</h2>
<p>The ultra-dynamic nature of knowledge source development does not lend itself well to the merge request process — particularly because each release must include a full meta data generation process to create the localized <code>meta.json</code> file. Content developers must coordinate their efforts in ways that are not conducive to the typical merge request process. Use issues instead.</p>
<h2 id="issues-as-errata">Issues as Errata</h2>
<p>Issues can and should be opened containing corrections and suggestions that a <em>single</em> editor can then place into the main content. Since the issues themselves using the same <a href="/md/">Markdown</a> format used for the knowledge source itself this becomes a matter of cutting and pasting from the issue into the master source branch.</p>
</main>
<footer>
<p><a href="/copyright/" id=copyright>© 2020 Rob Muhlestein. This written content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Any code is released into the public domain with no warranty.</a>
<br>Does something seem to have changed? <a href="/changes/">Check the change log.</a>
<br>See something wrong? <a href="https://gitlab.com/rwx.gg/README/-/issues">Open a ticket</a>
</p>
</footer>
<script src="/assets/main.js"></script>
</body>
</html>
---
Title: Git for Knowledge Source Management
Subtitle: Commit Often, Don't Branch, Log Changes
tpl-hdsearch: true
---
[Git](https://duck.com/lite?q=Git) is the world's best tool for managing source code and is therefore the best for managing knowledge captured as [Pandoc Markdown](/pandocmark) source. However, much of Git's functionality does not apply to the much more dynamic work of maintaining and editing knowledge source. Knowledge source is also much less able to benefit from the same level of fully automated [CI/CD](/knowledge/cicd/) because of this and the essential need for *human* editors to do what might otherwise be automated unit testing. Here are a few guidelines to get started:
* Commit often
* Create a `save` command
* Don't bother branching
* Work entirely on `master` branch
* Log changes to a [changes](/changes/) [knode](/knode/)
* Consider a different group just for knowledge source to prevent flooding those watching your Git activity on your hosting service.
<!doctype html>
<html lang="en">
<head>
<title>Git for Knowledge Source Management | RWX.GG</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate"/>
<meta http-equiv="Pragma" content="no-cache"/>
<meta http-equiv="Expires" content="0"/>
<!-- link rel="shortcut icon" href="/assets/img/logo.png" type="image/png"-->
<link rel="preload" href="/assets/styles.css" as="style">
<link rel="stylesheet" href="/assets/styles.css">
</head>
<body>
<div id=pagebg></div>
<header class=nav-bar>
<nav>
<div class=sidebar-button></div>
<div id=bwtoggle></div>
<a class="homelink spy" href="/">r<span class=hideable>wx.gg</span></a>
<div class="nav-right">
<!-- div id=search-box></div -->
<ul class=nav-links>
<li class=nav-item><a class=nav-link href="/overview/">Overview</a></li>
<li class=nav-item><a class=nav-link href="/schedule/">Schedule</a></li>
<li class=nav-item><a class=nav-link href="/books/">Books</a></li>
<li class=nav-item><a class=nav-link href="/changes/">Changes</a></li>
<li class=nav-item><a class=nav-link href="/contrib/">Contribute</a></li>
<li class=nav-item><a class=nav-link href="https://twitter.com/rwxrob">Twitter</a></li>
<li class=nav-item><a class=nav-link href="https://www.youtube.com/playlist?list=PLrK9UeDMcQLrO5fwV5smfNvau0PAP16-I">YouTube</a></li>
<li class=nav-item><a class=nav-link href="https://discord.gg/9wydZXY">Discord</a></li>
<li class=nav-item><a class=nav-link href="https://twitch.tv/rwxrob">Twitch</a></li>
</ul>
</div>
</nav>
</header>
<main class=content>
<a id=top></a>
<h1><a href="https://duckduckgo.com/lite?q=Git for Knowledge Source Management">Git for Knowledge Source Management</a></h1>
<h2>Commit Often, Don’t Branch, Log Changes</h2>
<p><a href="https://duck.com/lite?q=Git">Git</a> is the world’s best tool for managing source code and is therefore the best for managing knowledge captured as <a href="/pandocmark">Pandoc Markdown</a> source. However, much of Git’s functionality does not apply to the much more dynamic work of maintaining and editing knowledge source. Knowledge source is also much less able to benefit from the same level of fully automated <a href="/knowledge/cicd/">CI/CD</a> because of this and the essential need for <em>human</em> editors to do what might otherwise be automated unit testing. Here are a few guidelines to get started:</p>
<ul>
<li>Commit often</li>
<li>Create a <code>save</code> command</li>
<li>Don’t bother branching</li>
<li>Work entirely on <code>master</code> branch</li>
<li>Log changes to a <a href="/changes/">changes</a> <a href="/knode/">knode</a></li>
<li>Consider a different group just for knowledge source to prevent flooding those watching your Git activity on your hosting service.</li>
</ul>
</main>
<footer>
<p><a href="/copyright/" id=copyright>© 2020 Rob Muhlestein. This written content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Any code is released into the public domain with no warranty.</a>
<br>Does something seem to have changed? <a href="/changes/">Check the change log.</a>
<br>See something wrong? <a href="https://gitlab.com/rwx.gg/README/-/issues">Open a ticket</a>
</p>
</footer>
<script src="/assets/main.js"></script>
</body>
</html>
......@@ -39,7 +39,7 @@
<a id=top></a>
<h1><a href="https://duckduckgo.com/lite?q=Knowledge as Source">Knowledge as Source</a></h1>
<h2>Capturing, Maintaining, and Sharing Knowledge as Source Code</h2>
<p>We live in a time when the amount of human knowledge has reach unprecedented levels and grows exponentially, but we are at risk. So much knowledge is being produced in different forms that strategies for maintaining and archiving it in a way that is not owned by proprietary interests have been all but ignored. By applying the best practices and lessons learned from managing and distributing opensource software source code to <em>knowledge</em> source we can leverage all the same successes these projects have enjoyed. This begins by capturing the knowledge is a <a href="/basicmark/">simple form</a> such that source management and version control tools can work with it and then building building <a href="/pka/">knowledge applications</a> from the that source.</p>
<p>We live in a time when the amount of human knowledge has reach unprecedented levels and grows exponentially, but we are at risk. So much knowledge is being produced in different forms that strategies for maintaining and archiving it in a way that is not owned by proprietary interests have been all but ignored. By applying the best practices and lessons learned from managing and distributing opensource software source code to <em>knowledge</em> source we can leverage all the same successes these projects have enjoyed. This begins by capturing the knowledge is a <a href="/basicmark/">simple form</a> such that source management and version control tools <a href="git/">can work with it</a> and then building building <a href="/pka/">knowledge applications</a> from the that source.</p>
</main>
<footer>
<p><a href="/copyright/" id=copyright>© 2020 Rob Muhlestein. This written content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Any code is released into the public domain with no warranty.</a>
......
---
Title: Early Drivers for Tech Learning
Title: Early Motivators for Tech Learning
Subtitle: Keeping It Fun
tpl-hdsearch: true
---
Having a specific thing in mind makes learning the boring stuff easier because you know what you are *eventually* going to get out of it. People are motivated and driven by different things. Here are a few examples of part project goals that tend to motivate early-stage technologists.
Having a specific thing in mind makes learning the boring stuff easier because you know what you are *eventually* going to get out of it. People are motivated by different things. Here are a few examples of project goals that tend to motivate early-stage technologists. Consider picking one and [writing](/w/) it down as part of your [learning plan](https://duck.com/lite?q=learning plan).
* Set Up a Minecraft Server
* Develop a Game
* Create a Web Site
* Hacking and Defending (CTF)
* Hack and Defend (CTF)
* Get a Job
<!doctype html>
<html lang="en">
<head>
<title>Early Drivers for Tech Learning | RWX.GG</title>
<title>Early Motivators for Tech Learning | RWX.GG</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
......@@ -37,14 +37,14 @@
</header>
<main class=content>
<a id=top></a>
<h1><a href="https://duckduckgo.com/lite?q=Early Drivers for Tech Learning">Early Drivers for Tech Learning</a></h1>
<h1><a href="https://duckduckgo.com/lite?q=Early Motivators for Tech Learning">Early Motivators for Tech Learning</a></h1>
<h2>Keeping It Fun</h2>
<p>Having a specific thing in mind makes learning the boring stuff easier because you know what you are <em>eventually</em> going to get out of it. People are motivated and driven by different things. Here are a few examples of part project goals that tend to motivate early-stage technologists.</p>
<p>Having a specific thing in mind makes learning the boring stuff easier because you know what you are <em>eventually</em> going to get out of it. People are motivated by different things. Here are a few examples of project goals that tend to motivate early-stage technologists. Consider picking one and <a href="/w/">writing</a> it down as part of your <a href="https://duck.com/lite?q=learning%20plan">learning plan</a>.</p>
<ul>
<li>Set Up a Minecraft Server</li>
<li>Develop a Game</li>
<li>Create a Web Site</li>
<li>Hacking and Defending (CTF)</li>
<li>Hack and Defend (CTF)</li>
<li>Get a Job</li>
</ul>
</main>
......
......@@ -13,6 +13,11 @@ Here are the upcoming planned changes and new content to RWX.GG. This TODO list
1. Update [main.js](/assets/main.js) to progressively enhance any URLs pointing to duckduckgo lite version such that they are change do remote `lite` and point to full version
1. Write an `audit` script that combines [check](check) with validation of consistent use of [callouts](/styleguide/) and any other style guide violations that might creep in.
1. Write an `audit` script that combines [check](/check) with validation of consistent use of [callouts](/styleguide/) and any other style guide violations that might creep in. Have check only run on files that have changed since the last run of `check`.
1. Add *spoiler* mode that will automatically hide all the code rather than give away the commands so that it can be used to review as you go.
## Long Term
1. Replace [TLCL](/books/tlcl/) with *Linux Terminal Mastery*, a knowledge app that can double as a book, PDF, or whatever. The world needs a *true* terminal mastery book that weaves together deep knowledge and skill in using the fastest human-computer interface physically possible. The rather shallow and inexperienced "Keyboard Tricks" chapter in TLCL was really the trigger. It is disastrously bad and uninformed.
......@@ -45,9 +45,13 @@
<li><p>Review all for consistent use of FAQ styling</p></li>
<li><p>Add CSS styles for <code>.see</code> so that bullets can be used for Lynx, etc.</p></li>
<li><p>Update <a href="/assets/main.js">main.js</a> to progressively enhance any URLs pointing to duckduckgo lite version such that they are change do remote <code>lite</code> and point to full version</p></li>
<li><p>Write an <code>audit</code> script that combines <a href="check">check</a> with validation of consistent use of <a href="/styleguide/">callouts</a> and any other style guide violations that might creep in.</p></li>
<li><p>Write an <code>audit</code> script that combines <a href="/check">check</a> with validation of consistent use of <a href="/styleguide/">callouts</a> and any other style guide violations that might creep in. Have check only run on files that have changed since the last run of <code>check</code>.</p></li>
<li><p>Add <em>spoiler</em> mode that will automatically hide all the code rather than give away the commands so that it can be used to review as you go.</p></li>
</ol>
<h2 id="long-term">Long Term</h2>
<ol type="1">
<li>Replace <a href="/books/tlcl/">TLCL</a> with <em>Linux Terminal Mastery</em>, a knowledge app that can double as a book, PDF, or whatever. The world needs a <em>true</em> terminal mastery book that weaves together deep knowledge and skill in using the fastest human-computer interface physically possible. The rather shallow and inexperienced “Keyboard Tricks” chapter in TLCL was really the trigger. It is disastrously bad and uninformed.</li>
</ol>
</main>
<footer>
<p><a href="/copyright/" id=copyright>© 2020 Rob Muhlestein. This written content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Any code is released into the public domain with no warranty.</a>
......
Script started on 2020-05-19 13:22:29-0400
rwxrob[38;2;100;100;[email protected]live:~/repos/gitlab.com/rwx.gg/README$ ls
404.html cicd dk flow interface mvkb prereqs server styleguide vimgo
annotations cli docker fsf iotdev netlify preview serverless sublime vimisms
appstores clinstall domain gfm jamstack networking process services syntax virt
assets cloud eastereggs github jobs notothers programming setupsshd sysadmin vscode
atom cogdiss ed gitlab kbase occupations pwa shell terminal w
authpubkey commonmark editor gnulinux knode opencourse r sme times webdev
autodidact contain electron goals knowledge opensource readme socratic tmux whitespace
bash contrib emacs grok languages opinions README.md spaghetti TODO.md wikis
bashcomp copyright essentials gui learning overview _redirects sre typescript wk01
basicmark corrupt executed hci lfh paas repl ssg typing wk02
bias cred faas html lfs pandoc rotating sshkeys ubiquitous wk03
books daas failfaster iaas ligature pandocmark rules stats ui worker
build daemon faq impostor logistics pka rwx streamers unix wsl
c dev films index.html MANIFEST pkg saas streamlink users x
changes devops find infra markup platform schedule structure ux
check distros flipped installgo md popos secops stupid vi
rwxrob[38;2;100;100;[email protected]live:~/repos/gitlab.com/rwx.gg/README$ cd
rwxrob[38;2;100;100;[email protected]live:~$ cd -
/home/rwxrob/repos/gitlab.com/rwx.gg/README
rwxrob[38;2;100;100;[email protected]live:~/repos/gitlab.com/rwx.gg/README$ exit
exit
Script done on 2020-05-19 13:22:40-0400
......@@ -24,7 +24,12 @@ Subtitle: Week Three
* How to view a PDF
* Overview of Week
* Introduction to OverTheWire.org
### Learning Project Ideas
* <https://OverTheWire.org/wargames/bandit>
* <https://exercism.io>
* <https://typing.com>
### Part 1: Learning the Shell
......@@ -42,18 +47,21 @@ Subtitle: Week Three
* Redirection
* Seeing the World as the Shell Sees It
* Advanced Keyboard Tricks
* Advanced Keyboard Tricks (`set -o vi`)
* Permissions
* Processes
## Day 13
*Read and practice everything through Page 161*
### Part 2: Configuration and the Environment
* The Environment
* (Reminder that you need to know how to type)
* A Gentle Introduction to `vi`
* Customizing the Prompt
## Day 13
## Day 14
*Read and practice everything through Page 250*
......@@ -65,7 +73,7 @@ Subtitle: Week Three
* Searching for Files
* Archiving and Backup
## Day 14
## Day 15
*Read and practice everything through Page 362*
......@@ -76,9 +84,3 @@ Subtitle: Week Three
* Formatting Output
* Printing
* Compiling Programs
## Day 15
* Review
* Assess
* Game: <https://OverTheWire.org/wargames/bandit>
......@@ -59,7 +59,12 @@
<ul>
<li>How to view a PDF</li>
<li>Overview of Week</li>
<li>Introduction to OverTheWire.org</li>
</ul>
<h3 id="learning-project-ideas">Learning Project Ideas</h3>
<ul>
<li><a href="https://OverTheWire.org/wargames/bandit" class="uri">https://OverTheWire.org/wargames/bandit</a></li>
<li><a href="https://exercism.io" class="uri">https://exercism.io</a></li>
<li><a href="https://typing.com" class="uri">https://typing.com</a></li>
</ul>
<h3 id="part-1-learning-the-shell">Part 1: Learning the Shell</h3>
<ul>
......@@ -75,18 +80,19 @@
<ul>
<li>Redirection</li>
<li>Seeing the World as the Shell Sees It</li>
<li>Advanced Keyboard Tricks</li>
<li>Advanced Keyboard Tricks (<code>set -o vi</code>)</li>
<li>Permissions</li>
<li>Processes</li>
</ul>
<h2 id="day-13">Day 13</h2>
<p><em>Read and practice everything through Page 161</em></p>
<h3 id="part-2-configuration-and-the-environment">Part 2: Configuration and the Environment</h3>
<ul>
<li>The Environment</li>
<li>(Reminder that you need to know how to type)</li>
<li>A Gentle Introduction to <code>vi</code></li>
<li>Customizing the Prompt</li>
</ul>
<h2 id="day-13">Day 13</h2>
<h2 id="day-14">Day 14</h2>
<p><em>Read and practice everything through Page 250</em></p>
<h3 id="part-3-common-tasks-and-essential-tools">Part 3: Common Tasks and Essential Tools</h3>
<ul>
......@@ -96,7 +102,7 @@
<li>Searching for Files</li>
<li>Archiving and Backup</li>
</ul>
<h2 id="day-14">Day 14</h2>
<h2 id="day-15">Day 15</h2>
<p><em>Read and practice everything through Page 362</em></p>
<h3 id="part-3-common-tasks-and-essential-tools-continued">Part 3: Common Tasks and Essential Tools (Continued)</h3>
<ul>
......@@ -106,12 +112,6 @@
<li>Printing</li>
<li>Compiling Programs</li>
</ul>
<h2 id="day-15">Day 15</h2>
<ul>
<li>Review</li>
<li>Assess</li>
<li>Game: <a href="https://OverTheWire.org/wargames/bandit" class="uri">https://OverTheWire.org/wargames/bandit</a></li>
</ul>
</main>
<footer>
<p><a href="/copyright/" id=copyright>© 2020 Rob Muhlestein. This written content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Any code is released into the public domain with no warranty.</a>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment