diff --git a/common-content/en/energisers/binary/index.md b/common-content/en/energisers/binary/index.md new file mode 100644 index 000000000..cff1fd2e6 --- /dev/null +++ b/common-content/en/energisers/binary/index.md @@ -0,0 +1,36 @@ ++++ +title="Binary Line-Up" +emoji="⬜ ⬛" +time=20 +[tasks] +1="Convert decimal to binary using people" +2="Practice quick mental math with powers of 2" +[build] +render = 'never' +list = 'local' +publishResources = false ++++ + +### ⬜ ⬜ ⬛ ⬜ + +Let's count in binary using human beans! + +Assign roles randomly. 1️⃣ One person will be the **caller**, 4️⃣ four people will be the **beans** and #️⃣ the rest will be the **counters**. + +First four **beans**, line up facing away from the group. **Counters**, get in any kind of order so you know who is next. + +The **caller** will say a number between 1 and 15. +For example, 8: 😀 ⬜ ⬜ ⬜ + +First **counter**, you will turn the beans around to represent the binary number. If you get it right, go back in the counter group and let the next person count. If you get it wrong, you must become another bean, and the range of numbers will increase! + +
+Example of range increase + +🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧 Round 1: Numbers 1-15 (4 beans) +🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧 Round 2: Numbers 1-31 (5 beans) +🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧 Round 3: Numbers 1-63 (6 beans) +🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧🧑🏽‍🔧 Round 4: Numbers 1-127 (7 beans) +...And so on until only one counter remains! + +
diff --git a/common-content/en/module/decomposition/adding-like-dislike/index.md b/common-content/en/module/decomposition/adding-like-dislike/index.md new file mode 100644 index 000000000..d7f750691 --- /dev/null +++ b/common-content/en/module/decomposition/adding-like-dislike/index.md @@ -0,0 +1,64 @@ ++++ +title = "Adding like/dislike" +headless = true +time = 120 +facilitation = false +emoji= "👍👎" +objectives = [ + "Identify what data needs to be stored and exchanged between a client and server.", + "Devise a scheme for differentiating messages with different meanings (e.g. a new message vs a new like).", + "Contrast giving updated values as absolute values or relative changes.", + "Implement an end-to-end feature involving data updates and reconciliation across a client and server.", +] ++++ + +The last requirement we have for our chat application is the ability to like/dislike a message (and see what messages have been liked/disliked). + +{{}} +Think about what information a client would need to provide to a server in order to like/dislike a message. + +Think about what information a server would need to provide to a client in order to display how many likes/dislikes a message has. + +Think about what information a server would need to provide to a client in order to _update_ how many likes/dislikes a message has. + +Write these things down. +{{}} + +### Identifiers + +One of the key new requirements to add liking/disliking a message is knowing _which_ message is being liked/disliked. + +When a client wants to like a message, it needs some way of saying _this_ is the message I want to like. + +This suggests we need a unique identifier for each message: +* When the server tells a client about a message, it needs to tell it what the identifier is for that message. +* When a client tells the server it wants to like a message, it needs to tell it the identifier for the message it wants to like. +* When the server tells a client a message has been liked, it needs to tell the client which message was liked, and the client needs to know enough about that message to be able to update the UI. + +### Message formats + +Now that your server will be sending multiple kinds of updates ("Here's a new message", or "Here's an update to the number of likes of an existing message"), you'll need to make sure the client knows the difference between these messages. The client will need to know how to act when it receives each kind of message. + +### Changes or absolutes? + +When new likes happen, a choice we need to make is whether the server should tell a client "this message was liked again" or should tell the client "this message now has 10 likes". Both of these can work. + +{{}} +Write down some advantages and disadvantages of a server -> client update being "+1 compared to before" or "now =10". + +Choose which approach you want to take. +{{}} + +{{}} +Implement liking and disliking messages. + +If a message has a non-zero number of likes or dislikes, the frontend needs to show this. + +The frontend needs to expose some way for a user to like or dislike any message. + +When a user likes or dislikes a message, the frontend needs to tell the backend about this, and the backend needs to notify all clients of this. + +When a frontend is notified by a backend about a new like or dislike, it needs to update the UI to show this. + +You may do this in your polling implementation, WebSockets implementation, or both. +{{}} diff --git a/common-content/en/module/decomposition/websockets/index.md b/common-content/en/module/decomposition/websockets/index.md new file mode 100644 index 000000000..c5b94d293 --- /dev/null +++ b/common-content/en/module/decomposition/websockets/index.md @@ -0,0 +1,116 @@ ++++ +title = "WebSockets" +headless = true +time = 120 +facilitation = false +emoji= "🔌" +objectives = [ + "Stream live updates from a server using WebSockets.", + "Discuss the trade-offs of using WebSockets or polling.", + "Describe properties of message formats (e.g. including a command name).", +] ++++ + +WebSockets are an API and protocol which allow creating a bi-directional communication channel between two programs. + +They are commonly used in websites to establish a channel so that a backend can send updates to a frontend. + +You can read [an introduction to WebSockets](https://docs.developer.tech.gov.sg/docs/data-engineering-initiative-playbook/Chapter5/Introduction_to_WebSockets), as well as roughly [what a client looks like](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications), and [what a server does](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers). + +On the server side, we will be using the [websocket npm package](https://www.npmjs.com/package/websocket) which lists a server example in its README. + +> [!TIP] +> +> This sprint, you will need to submit _both_ a copy of your code which supports polling, _and_ a copy which supports WebSockets. +> +> You probably want to make a copy of your polling code, and have two separate (similar) pages in your repo. + +On the backend, you can create a WebSocket server by adding this code: + +```js +import { server as WebSocketServer } from "websocket"; +const server = http.createServer(app); +const webSocketServer = new WebSocketServer({ httpServer: server }); +``` + +You will then need to follow the example in the `websocket` npm package's documentation to have your server handle requests. + +On the client-side, you will need to make a new `WebSocket` connection to the server. + +Some things to think about when implementing WebSockets updates: + +### Learn new APIs in isolation + +It will be easier for you to learn a new API (like WebSockets) with a simple example. + +At the end, you will want your WebSocket to stream new messages from the server to the client, but maybe to explore WebSockets you want the server to always report the message "Hello" when it's connected to, so you can test things out more easily? Or even write a whole new website which _only_ makes a WebSocket connection and displays a message? + +Once you have an example WebSocket working, and understand how it works, it should be easier for you to apply that to the real problem you're trying to solve. + +### Think about the protocol you want + +WebSockets let you send arbitrary text (or binary) messages. + +In our quote server, we switched from our backend returning a pre-formatted string of a quote, to returning a JSON object so we could get the parts ourselves. + +Think about what structure would be useful for our client and our server to know about. + +If we're going to add more messages in the future (e.g. for "liking" a message), how will the receiver of the message know what kind of message the one it receives is? + +One thing we often do is wrap our message in an object, with a field specifically saying what the command is. + +e.g. instead of sending: +```json +{ + "user": "Azin", + "message": "Hello!" +} +``` + +we may send: + +```json +{ + "command": "send-message", + "message": { + "user": "Azin", + "message": "Hello!" + } +} +``` + +This means that if we add new commands in the future, we don't need to change our existing code. + +### Think about timings + +When we first load a page, we need to get all of the messages that already exist. + +After that, we can ask to be notified of new messages. + +There are a few ways we could do that. An interesting question is what happens _between_ these events? + +Imagine we made an HTTP GET request to ask for all of the messages, then created a WebSocket to get new messages. What happens if someone sent a message between when we got our response, and when the WebSocket was connected? How can we make sure we don't miss any messages? + +Or imagine we made a WebSocket request, and expected to receive a list of all previous messages, and then to keep receiving updates. Does the server need to remember which messages have already been sent to each client? + +{{}} +Write down your strategy for how to make sure that after initially getting the existing messages, your client won't miss any new messages. +{{}} + +### Remember WebSockets are bi-directional + +Now, we're using a `POST` request to send a new message, and a `WebSocket` to stream receiving new messages. + +But we know that WebSockets are bi-directional - we can both send and receive information on them. + +We could change our sending logic to also use our WebSocket. Or we could keep using HTTP POST requests. Both of these approaches work. + +{{}} +Think: What advantages does each approach have? + +Why might we want to change our implementation to use a WebSocket for sending messages? + +Why might we want to keep using POST requests for sending messages? + +Why might we want to support _both_ on our server? Why might we only want to support one on our server? +{{}} diff --git a/common-content/en/module/logic/_index.md b/common-content/en/module/logic/_index.md new file mode 100644 index 000000000..732bb3356 --- /dev/null +++ b/common-content/en/module/logic/_index.md @@ -0,0 +1,8 @@ ++++ +title="Logic" +description="Mental models for logical reasoning" +emoji="🧑🏾‍💻" +layout="block-viewer" +hide_from_overview="true" +noindex="true" ++++ diff --git a/common-content/en/module/logic/abduction/index.md b/common-content/en/module/logic/abduction/index.md new file mode 100644 index 000000000..5d3796810 --- /dev/null +++ b/common-content/en/module/logic/abduction/index.md @@ -0,0 +1,51 @@ ++++ +title = "Abduction" +time = 60 +emoji= "🔎" +[build] +render = 'never' +list = 'local' +publishResources = false +[objectives] +1="Define abduction" +2="Use evidence to reason to the best explanation" ++++ + +> Abduction is reasoning to the best explanation for all the evidence we observe + +```mermaid +flowchart TD + ev1[Evidence 1] --> h1[Hypothesis A] + ev2[Evidence 2] --> h1 + ev3[Evidence 3] --> h1 + ev1 --> h2[Hypothesis B] + ev2 --> h2 + ev3 -.-> h2 + h1 --> be[Best Explanation] + h2 -.- be + style h2 stroke-dasharray: 5 5 + style ev3 stroke-dasharray: 5 5 +``` + +In [Sherlock Holmes: Consulting Detective](https://www.spacecowboys.fr/case3-the-murderess), we think like detectives. Each case presents us with mysterious evidence that needs explaining. Unlike deduction which proves only what _must_ be true, or induction which only finds patterns that are probably true, abduction seeks the most complete explanation. + +> _Given_ a woman was found dead in her apartment +> _And_ her jewelry was untouched +> _And_ there were no signs of forced entry +> _Then_ the killer likely knew the victim (but we can't be certain) + +Each lead we follow adds new evidence. A witness statement might support our theory, contradict it, or suggest a completely different explanation. We must: + +- Keep track of all evidence +- Form multiple possible theories +- Test each theory against _all_ the evidence +- Choose the explanation that best fits everything we know +- Be ready to revise our theory when new evidence appears + +It's quite a lot like problem solving we've done before, isn't it? Now go solve a case: + +{{}} diff --git a/common-content/en/module/logic/binary-logic/index.md b/common-content/en/module/logic/binary-logic/index.md new file mode 100644 index 000000000..f490bae05 --- /dev/null +++ b/common-content/en/module/logic/binary-logic/index.md @@ -0,0 +1,51 @@ ++++ +title = "Boolean Logic" +time = 45 +emoji = "🎭" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define binary logic and its role in computing" + 2="Express logical statements as truth tables" ++++ + +> Boolean logic uses only **true** or **false** to reason about the world. + +In the real world, we use logic to make decisions all the time. For example: if it's raining and you don't have an umbrella, you will get wet. This can be represented as a truth table: + +{{}} + +| Is Raining | Has Umbrella | Is Wet | +| ---------- | ------------ | ------ | +| F | F | F | +| F | T | F | +| T | F | T | +| T | T | F | + +Truth tables show all possible combinations and all possible outcomes. +<---> + +> _Given_ A is true (1) +> _And_ B is true (1) +> _Then_ A AND B is true (1) + +{{}} + +In computers, we use binary logic to derive conclusions from data. Each bit can represent a logical state: {{}}Represented as 1 in binary{{}} or {{}}Represented as 0 in binary{{}}. + +| Raining | Umbrella | Wet | +| ------- | -------- | --- | +| 0 | 0 | 0 | +| 0 | 1 | 0 | +| 1 | 0 | 1 | +| 1 | 1 | 0 | + +This is fundamental to how computers work. Every operation a computer performs, from simple addition to complex decision-making, ultimately comes down to chains of basic logical operations on 1s and 0s. + +Try building some truth tables yourself in your notebook. Here are some examples to get you started: + +- "You can get a loyalty reward if you have the app AND have made 10 purchases" +- "The alarm will sound if the door is open OR motion is detected, UNLESS the system is disabled" +- "Trainees pass the course if they complete coursework AND attend class AND complete their steps" diff --git a/common-content/en/module/logic/bisection/bisection.svg b/common-content/en/module/logic/bisection/bisection.svg new file mode 100644 index 000000000..56779cacc --- /dev/null +++ b/common-content/en/module/logic/bisection/bisection.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/common-content/en/module/logic/bisection/index.md b/common-content/en/module/logic/bisection/index.md new file mode 100644 index 000000000..f3b23133c --- /dev/null +++ b/common-content/en/module/logic/bisection/index.md @@ -0,0 +1,37 @@ ++++ +title = "Bisection" +time = 10 +emoji= "✂️" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define bisection search" + 2="Apply binary search to guess a number" ++++ + +> In bisection, we start with a large problem space and cut it in half with each guess. + +![bisection.svg](bisection.svg) + +In software development, bisection helps us find exactly when a change occurred. For example: + +> _Given_ our code worked last week but not today +> _When_ we test the middle version and it works +> _Then_ the problem must be in the newer half + +With each test, we: + +1. Select the middle version +2. Test if it works +3. Eliminate half the versions +4. Repeat until we find the exact change + +This [binary search](https://www.khanacademy.org/computing/computer-science/algorithms/binary-search/a/binary-search) technique is remarkably efficient. Even with thousands of versions, we'll find the problematic change in just a few tests. Git and other version control systems include [built-in bisect tools](https://git-scm.com/docs/git-bisect) for this purpose. + +{{}} diff --git a/common-content/en/module/logic/deduction/index.md b/common-content/en/module/logic/deduction/index.md new file mode 100644 index 000000000..e962370f4 --- /dev/null +++ b/common-content/en/module/logic/deduction/index.md @@ -0,0 +1,40 @@ ++++ +title = "Deduction" +time = 25 +emoji= "🚥" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define deduction" + 2="Use deduction to solve a matrix puzzle" ++++ + +> Deduction is reasoning from **general** rules to a **specific** conclusion that is _definitely_ true + +```mermaid +flowchart LR + d1[Rule 1: If A then B] + d2[Rule 2: We have A] + d1 --> dc[Therefore we must have B] + d2 --> dc +``` + +In [Murdle](https://murdle.com/), we use deduction to solve murders. Given general rules about the crime scene and specific clues, we can {{}}Use rules you know are true to prove something specific _must_ also be true.{{}} who the murderer must be. + +> _Given_ the body was found in the kitchen +> _And_ only Miss Saffron had been in the kitchen +> _Then_ Miss Saffron must be the murderer + +This is deduction: starting with general rules and arriving at a specific conclusion that must be true. Unlike guessing or inferring patterns, deduction gives us certainty. If our premises are true, our conclusion must be true. + +In Murdle, every puzzle can be solved through pure deduction. There's no need to guess. The clues and rules will lead you to a single possible murderer. + +Go play Murdle. + +{{}} diff --git a/common-content/en/module/logic/demo/index.md b/common-content/en/module/logic/demo/index.md new file mode 100644 index 000000000..77811d0a6 --- /dev/null +++ b/common-content/en/module/logic/demo/index.md @@ -0,0 +1,52 @@ ++++ +title="Docendo Discimus" +emoji="🎤" +time=60 +[build] + render = 'never' + list = 'local' + publishResources = false + ++++ + +This sprint you should have prepared to teach one of the following topics: + +
+Topics + +- **Deduction** +- **Induction** +- **Abduction** +- **Falsification** +- **The Problem Domain** +- **Bisection** +- **Binary Logic** +
+ +## ⏰ Timekeeper + +The timekeeper will keep the groups on track. + +## 📚 Instructions + +Split into pairs. Each person will have 3 minutes to present their topic. After the lesson, you and your student will discuss the topic for 3 minutes. Then the student will become the teacher and present their own topic. + +## 🧑🏾‍🤝‍🧑🏻 Pairs + +### 1. Model + +You will explain your topic to your student. You will have 3 minutes to communicate, in whatever way you have prepared. You can use a drawing, a game, a conversation, or anything you like that will help you communicate the concept, except a computer! + +### 2. Check understanding + +After your lesson, you and your student check your understanding for another 3 minutes. Then you will switch roles. + +### 3. Add yourself to another group + +At the end of both lessons, join another pair. Pick one of your topics and explain it to the other pair. They will do the same for you. At the end of both lessons, join another group of four and repeat the process. + +## 💡 Tips: + +- **Practice** your lesson before class. +- **Keep it simple**. Just choose one concept to explain. +- **Keep it short**. Three minutes is enough. diff --git a/common-content/en/module/logic/falsification/index.md b/common-content/en/module/logic/falsification/index.md new file mode 100644 index 000000000..e051d5a26 --- /dev/null +++ b/common-content/en/module/logic/falsification/index.md @@ -0,0 +1,72 @@ ++++ +title = "Falsification" +time = 45 +emoji= "❌" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define Popper's falsification principle" + 2="Use elimination to reduce possibilities" ++++ + +> Falsification is an efficient _reduction_ strategy. It means making predictions that **eliminate** possibilities, rather than gathering evidence that supports them + +{{}} + +```mermaid +stateDiagram-v2 + state "All Possibilities" as AP { + state "Theory Space" as T1 { + state "Remaining" as T2 { + state "Survivors" as T3 + } + } + } +``` + +<---> + +> _Given_ many possible rules +> _Make_ a prediction that could eliminate some +> _When_ the prediction fails +> _Then_ we can discard those possibilities + +{{}} + +This is a subtle distinction: _dis_ confirmation is the mental model we must build here. In 20 Questions we discovered our problem space by confirming _and_ disconfirming our guesses. In [Zendo](https://www.looneylabs.com/games/zendo), we will try to discover the rule governing pyramid patterns not by _confirming_ our guesses, but by _eliminating_ what's impossible + +Here's a [classic example](https://simple.wikipedia.org/wiki/Falsifiability): + +```mermaid +flowchart TD + T["🦢 Theory: All Swans Are White"] + O["Observe Next Swan"] + D{"What Color?"} + W["Theory Holds..."] + F["Theory Falsified!"] + + T --> O + O --> D + D -->|⬜ White| W + D -->|⬛ Black| F + W -->|"Keep testing"| O + +``` + +Popper explains that each additional white swan appears to confirm our wrong idea that all swans are white. A single black swan disproves it, and ends the loop. This strategy shows us that: + +1. Only gathering confirming evidence leaves too many possibilities, or too large a problem domain +2. However, each failed prediction narrows our search space by discarding possibilities +3. We learn _more_ from being wrong than being right + +It is more efficient to find a way to disprove your hypothesis or falsify your proposition, if you can. This is because you only need to disprove something once to discard it, but you may apparently verify a hypothesis many times in many different ways and still be wrong. + +Now, practice eliminating possibilities in [Zendo](https://www.koryheath.com/zendo/). For this game you need a group, so post in Slack to find others to play with. + +{{}} diff --git a/common-content/en/module/logic/induction/index.md b/common-content/en/module/logic/induction/index.md new file mode 100644 index 000000000..71b5b559c --- /dev/null +++ b/common-content/en/module/logic/induction/index.md @@ -0,0 +1,49 @@ ++++ +title = "Induction" +time = 45 +emoji= "🍱" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define induction" + 2="Use induction to form general theories about the best strategies in Sushi Go" ++++ + +> Induction is reasoning from **specific** examples to form **general** patterns that are _probably_ true + +```mermaid +flowchart TD + sp1[Specific Example 1] --> gp[General Pattern] + sp2[Specific Example 2] --> gp + sp3[Specific Example 3] --> gp + gp --> pc[Probable Conclusion] +``` + +In Sushi Go, we use induction to build winning strategies. By observing specific outcomes across multiple hands, we form general theories about what works. For example: + +> _Given_ collecting 3 tempura scored 10 points +> _And_ collecting 2 tempura scored 5 points +> _And_ collecting 1 tempura scored 0 points +> _Then_ tempura probably works best in pairs + +Unlike deduction which gives certainty, induction helps us form educated guesses about patterns. The more examples we see, the more confident we can be in our general conclusions - but we can never be 100% certain. + +In [Sushi Go](https://en.boardgamearena.com/gamepanel?game=sushigo), every game teaches us something new about card combinations, timing, and player behavior. Through repeated play, we inductively learn strategies like: + +- Watching what others collect helps predict what cards will come around +- Early puddings often pay off in the final round +- Chopsticks are most valuable when saved for high-scoring combinations + +Play a few rounds of [Sushi Go](https://en.boardgamearena.com/gamepanel?game=sushigo) and practice inductive reasoning. Try to: + +1. Notice specific scoring patterns +2. Look for recurring situations +3. Form general theories about good strategies + +{{}} diff --git a/common-content/en/module/logic/introduction/index.md b/common-content/en/module/logic/introduction/index.md new file mode 100644 index 000000000..01c9d9a64 --- /dev/null +++ b/common-content/en/module/logic/introduction/index.md @@ -0,0 +1,33 @@ ++++ +title = "Introduction" +time = 5 +emoji= "🧠" +[build] +render = 'never' +list = 'local' +publishResources = false ++++ + +Welcome to Logic. For this module, we will get out of VSCode and build mental models we can use anywhere to reason more effectively. + +### You will need + +📓 Notebook and pen +🧠 Your wonderful brain +🔍 And you will still need the curriculum and Google, that's not banned, don't worry. + +### Learning by teaching + +In this prep you will build a series of mental models necessary for logical reasoning. You likely already know some of these pieces. We will start to build each model by playing a game. Pay attention, because... + +In class this week _you_ will be teaching something. You will be explaining one of these mental models. You will not use a computer to explain this, but something else. This could be a drawing, a game, a conversation, or anything you like that will help you communicate the concept, except a computer! + +### Mental models + +1. **Deduction**: Reasoning from general rules to a specific conclusion that is _definitely_ true +1. **Induction**: Reasoning from specific examples to form general patterns that are _probably_ true +1. **Abduction**: Reasoning to the best explanation for all the evidence we observe +1. **Falsification**: Testing a theory by trying to prove it wrong +1. **Problem Domain**: Identifying the bounded space that contains all possible solutions to a problem +1. **Bisection**: Reasoning by reducing a problem space to the smallest possible size +1. **Binary Logic**: Reasoning with only two possible states (true or false) diff --git a/common-content/en/module/logic/problem-domain/index.md b/common-content/en/module/logic/problem-domain/index.md new file mode 100644 index 000000000..dd16ec978 --- /dev/null +++ b/common-content/en/module/logic/problem-domain/index.md @@ -0,0 +1,49 @@ ++++ +title = "The Problem Domain" +time = 15 +emoji= "🗺️" +[build] + render = 'never' + list = 'local' + publishResources = false +[objectives] + 1="Define the problem domain" + 2="Learn to constrain problems before solving them" ++++ + +> The problem domain is a bounded space that contains all possible solutions to a problem. Everything outside the problem domain is impossible or irrelevant. + +{{}} + +
+ +```mermaid +stateDiagram-v2 + state "Everything Possible" as EP { + state "Numbers" as N { + state "1-100" as H { + state "Even Numbers" as E + } + } + } +``` + +
Each constraint reduces our problem space
+
+ +<---> + +> _Given_ no constraints +> _Then_... the answer could be anything in the universe! +> _When_ we add "must be a number" +> _Then_ we constrain to the domain of numbers + +{{}} + +Before we can solve a problem, we need to understand what's possible. In [Twenty Questions](http://20q.net/) we start with everything in the universe, then ask questions to reduce our problem space. We might start with "Is it alive?" to constrain our domain to animals, then "Is it a mammal?" to reduce further. + +{{}} diff --git a/common-content/en/module/logic/read-binary-logic/index.md b/common-content/en/module/logic/read-binary-logic/index.md new file mode 100644 index 000000000..d9771476c --- /dev/null +++ b/common-content/en/module/logic/read-binary-logic/index.md @@ -0,0 +1,24 @@ ++++ +title = "Binary Logic recap" +[build] + render = 'never' + list = 'local' + publishResources = false +time = 60 +emoji= "📖" +[objectives] + 1="Add together two binary numbers without converting to decimal" + 2="Identify which of two binary numbers is larger without converting to decimal" + 3="Identify whether a binary number is a power of two" + 4="Write a truth table for a given logic gate" ++++ + +Read the learning objectives listed on this page: Bear in mind what you're trying to achieve while reading this text. If a topic isn't making much sense, and isn't in the objectives, you can probably skip over it. If a topic is listed in the objectives, you should keep studying it until you are confident you've met the objective. + +{{}} +Review chapters 1, 2, and the "Binary Addition", "Signed Numbers" and "Unsigned Numbers" sections of chapter 5 of How Computers Really Work. This time focus on the Binary Logic section that you might have skipped before. + +Do every exercise listed in the chapters that you haven't done before. You can skip the projects. +{{}} + +Check you have achieved each learning objective listed on this page. diff --git a/org-cyf-sdc/content/decomposition/sprints/3/prep/index.md b/org-cyf-sdc/content/decomposition/sprints/3/prep/index.md index e482b33ee..82a7cfe64 100644 --- a/org-cyf-sdc/content/decomposition/sprints/3/prep/index.md +++ b/org-cyf-sdc/content/decomposition/sprints/3/prep/index.md @@ -6,6 +6,12 @@ emoji= '🧑🏾‍💻' menu_level = ['sprint'] weight = 1 [[blocks]] +name = "Websockets" +src = "module/decomposition/websockets" +[[blocks]] +name = "Adding like/dislike" +src = "module/decomposition/adding-like-dislike" +[[blocks]] title = "Different experiences for different users" src = "module/decomposition/different-experiences-for-different-users" [[blocks]] diff --git a/org-cyf-sdc/content/logic/prep/index.md b/org-cyf-sdc/content/logic/prep/index.md index 04a4e5536..b9c6f484b 100644 --- a/org-cyf-sdc/content/logic/prep/index.md +++ b/org-cyf-sdc/content/logic/prep/index.md @@ -1,11 +1,11 @@ +++ title = 'prep' -description = 'Developing understanding of data groups' +description = 'Mental models' layout = 'prep' emoji= '🧑🏾‍💻' menu_level = ['module'] weight = 1 [[blocks]] -title = "Coming soon" -src = "blocks/coming-soon" +name="Recap binary" +src="module/logic/read-binary-logic" +++ diff --git a/org-cyf-sdc/content/logic/sprints/1/_index.md b/org-cyf-sdc/content/logic/sprints/1/_index.md index 71e2223c3..1cdc4de97 100644 --- a/org-cyf-sdc/content/logic/sprints/1/_index.md +++ b/org-cyf-sdc/content/logic/sprints/1/_index.md @@ -5,5 +5,5 @@ layout = 'sprint' emoji= '⏱️' menu_level = ['module'] weight = 2 -theme = "Solving logical problems well, considering edge-cases, and playing computer" +theme = "Solving logical problems efficiently" +++ diff --git a/org-cyf-sdc/content/logic/sprints/1/backlog/index.md b/org-cyf-sdc/content/logic/sprints/1/backlog/index.md index d23d2978e..c5f4db65a 100644 --- a/org-cyf-sdc/content/logic/sprints/1/backlog/index.md +++ b/org-cyf-sdc/content/logic/sprints/1/backlog/index.md @@ -4,6 +4,5 @@ layout = 'backlog' emoji= '🥞' menu_level = ['sprint'] weight = 2 -backlog= 'Module-Template' -backlog_filter='📅 Sprint 1' +backlog= 'Module-Logic' +++ diff --git a/org-cyf-sdc/content/logic/sprints/1/day-plan/index.md b/org-cyf-sdc/content/logic/sprints/1/day-plan/index.md index 820884264..b101d8cdd 100644 --- a/org-cyf-sdc/content/logic/sprints/1/day-plan/index.md +++ b/org-cyf-sdc/content/logic/sprints/1/day-plan/index.md @@ -8,9 +8,12 @@ weight = 3 name="Morning orientation" src="blocks/morning-orientation" [[blocks]] -name="Study group" +name="Energiser" +src="energisers/binary" +[[blocks]] +name="Workshop: Binary Search" src="blocks/workshop" -time="115" +time="120" [[blocks]] name="Games, rules, logic and strategy" src="blocks/games" @@ -20,17 +23,9 @@ name="lunch" src="blocks/lunch" [[blocks]] name="demo" -src="blocks/demo" -time="25" -[[blocks]] -name="Study Group" -src="blocks/study-group" +src="module/logic/demo" time="60" [[blocks]] -name="Code Review" -src="https://github.com/CodeYourFuture/Module-Template/pulls" -time="0" -[[blocks]] name="Afternoon break" src="blocks/afternoon-break" [[blocks]] diff --git a/org-cyf-sdc/content/logic/sprints/1/prep/index.md b/org-cyf-sdc/content/logic/sprints/1/prep/index.md index 13942b820..122e60480 100644 --- a/org-cyf-sdc/content/logic/sprints/1/prep/index.md +++ b/org-cyf-sdc/content/logic/sprints/1/prep/index.md @@ -1,11 +1,32 @@ +++ title = 'prep' -description = 'Overview description of the prep work for the sprint' +description = 'Mental models for logical reasoning' layout = 'prep' emoji= '🧑🏾‍💻' menu_level = ['sprint'] weight = 1 [[blocks]] -title = "Coming soon" -src = "blocks/coming-soon" +name = "Introduction" +src = "module/logic/introduction" +[[blocks]] +name = "Deduction" +src = "module/logic/deduction" +[[blocks]] +name = "Induction" +src = "module/logic/induction" +[[blocks]] +name = "Abduction" +src = "module/logic/abduction" +[[blocks]] +name="Problem Domain" +src="module/logic/problem-domain" +[[blocks]] +name="Falsification" +src="module/logic/falsification" +[[blocks]] +name="Bisection" +src="module/logic/bisection" +[[blocks]] +name="Binary Logic" +src="module/logic/binary-logic" +++