Hackathon Prep Guide (Accelerated Developer Journey)

docs/tutorials/hackathon-prep-guide/1-what-is-icp.md → docs/tutorials/hackathon-prep-course/1-what-is-icp.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The Internet Computer (ICP) is a transparent and secure blockchain network that enables developers to create and deploy fully decentralized applications. Decentralized applications are created through deploying smart contracts, which are known as **canisters** on ICP. Canisters are highly scalable to directly serve user experiences. Each canister on the Internet Computer is hosted on an independent version of the blockchain network called a **subnet**.
+The Internet Computer (ICP) is a transparent and secure blockchain network that enables developers to create and deploy fully decentralized applications. Decentralized applications are created through deploying smart contracts, which are known as **canisters** on ICP. Canisters are highly scalable to directly serve user experiences. Each canister on the Internet Computer is hosted on an independent version of the blockchain network called a **subnet**. **Subnets** can seamlessly communicate with each other.
 
 ## Vision of the Internet Computer 
 
@@ -15,10 +15,12 @@ You can learn more about the vision of the Internet Computer in the [ICP deck](h
 ## Architecture of the Internet Computer Protocol
 ### Subnets
 
-An subnet is a collection of nodes that run their own instance of the Internet Computer Protocol's consensus algorithm, essentially running their own blockchain. Each subnet consists of node machines, or nodes, which are used to host canister smart contracts. Each canister's code, along with its state and computation, is replicated across every node on the subnet.
+A subnet is a collection of nodes that run their own instance of the Internet Computer Protocol's consensus algorithm, essentially running their own blockchain. Each subnet consists of node machines, or nodes, which are used to host canister smart contracts. Each canister's code, along with its state and computation, is replicated across every node on the subnet.
 
 Subnets are designed to be highly scalable and host canister smart contracts efficiently. Each subnet operates concurrently with and independently of the other subnets, but can communicate asynchronously with other subnets. Multiple independent subnets run in parallel, allowing the Internet Computer to break through the single-machine barrier that limits traditional blockchains.
 
+![Subnets](./_attachments/subnets.png)
+
 ### Deterministic decentralization
 
 The term deterministic decentralization refers to a concept used to maximize the decentralization and diversity of each subnet on ICP. Deterministic decentralization measures and maximizes the decentralization of every layer of the ICP infrastructure by maximizing the number of different node providers, data centers, geographies, and jurisdictions. The purpose of deterministic decentralization is to ensure that the network remains diverse and decentralized.
@@ -58,7 +60,7 @@ Users can be onboarded into the ICP ecosystem seamlessly through dozens of diffe
 
 - [Developer Journey video series](https://www.youtube.com/watch?v=3WpP8ux1zX0).
 
-- [ICP Zero to Dapp workshop series](https://www.youtube.com/watch?v=P3ngpMedCTE).
+- [ICP Zero to Dapp workshop series](https://youtube.com/playlist?list=PLfEHHr3qexv8hKOJBV1XR10XhUKkyPIBp&si=KqnDuEgJZt51q4e4).
 
 - [Motoko Bootcamp](https://www.motokobootcamp.com/).
 

docs/tutorials/hackathon-prep-guide/10-resources.md → docs/tutorials/hackathon-prep-course/10-resources.md

@@ -4,6 +4,8 @@ To learn more about ICP, a specific feature or workflow, or get help from other
 
 - [ICP developer documentation.](/docs/current/home)
 
+- [ICP Zero to Dapp Hackathon.](https://www.encode.club/zero-to-dapp-hackathon)
+
 - [ICP developer journey tutorial series.](https://internetcomputer.org/docs/current/tutorials/developer-journey/)
 
 - [ICP developer journey video series.](https://www.youtube.com/watch?v=oBUpJ4CqmN0)
@@ -16,7 +18,9 @@ To learn more about ICP, a specific feature or workflow, or get help from other
 
 - [Developer tooling working group](https://www.google.com/calendar/event?eid=MHY0cjBubmlnYXY1cTkzZzVzcmozb3ZjZm5fMjAyMzEwMDVUMTcwMDAwWiBjX2Nnb2VxOTE3cnBlYXA3dnNlM2lzMWhsMzEwQGc&ctz=Europe/Zurich).
 
-- [Motoko bootcamp](https://github.com/motoko-bootcamp/bootcamp-2022), a week-long crash course to learning all things Motoko. 
+- [Motoko Bootcamp - The DAO Adventure](https://github.com/motoko-bootcamp/dao-adventure) - Discover the Motoko language in this 7 day adventure and learn to build a DAO on the Internet Computer.
+
+- [Motoko Bootcamp - Discord community](https://discord.gg/YbksCUxdzk) - A community for and by Motoko developers to ask for advice, showcase projects and participate in collaborative events.
 
 - [Motoko developer working group](https://www.google.com/calendar/event?eid=ZWVnb2luaHU0ZjduMTNpZHI3MWJkcWVwNWdfMjAyMzEwMTJUMTUwMDAwWiBjX2Nnb2VxOTE3cnBlYXA3dnNlM2lzMWhsMzEwQGc&ctz=Europe/Zurich).
 

docs/tutorials/hackathon-prep-guide/2-deploying-first-fullstack-dapp.md → docs/tutorials/hackathon-prep-course/2-deploying-first-fullstack-dapp.md

@@ -103,13 +103,11 @@ A frontend canister hosts the portion of an application that is used to interact
 
 Before continuing, it is important to learn about the several different types of identities and authentication methods that you'll encounter while developing on ICP. 
 
-- **Developer identity**: An identity created using dfx, which contains a private/public key pair, and has a principal data type derived from the public key. It can be compared to a Bitcoin or Ethereum wallet address.
+- **Developer identity**: An identity created using dfx, which contains a private/public key pair, and has a principal derived from the public key.
 
-- **Principals**: A generic identifier that can be used for users, canisters, and potentially other future concepts.
+- **Principals**: A generic identifier that can be used for users, canisters, and potentially other future concepts. It can be compared to a Bitcoin or Ethereum wallet address. Each principal can control multiple accounts in the ICP (and other) ledgers.
 
-- **Principal identifiers**: A principal associated with a user principal ID. Principal identifiers are related to account identifiers, but use a different format. Each principal identity can control multiple accounts in the ICP (and other) ledgers.
-
-- **Account identifier**: The identifier associated with your ICP ledger account, as specified in the ledger specification.
+- **Account identifier**: The identifier associated with your ICP ledger account, as specified in the [ledger specification](https://internetcomputer.org/docs/current/references/ledger#_accounts).
 
 - **Wallets**: Wallets are used to store forms of currency or other assets, such as cycles, ICP, or NFTs. Developers primarily use a cycles wallet to send cycles to and from canisters.
 
@@ -119,7 +117,7 @@ You can learn more about identities and principals [here](/docs/current/tutorial
 
 ### Cycles and cycles wallets
 
-Cycles are used to measure and pay for the resources that are used by a canister, such as the memory, storage, and compute power. For canisters deployed locally, cycles are not charged for the resources used to run that canister on your local hardware. However, once a canister is deployed to the mainnet, cycles are charged to pay for the resources being used on the network. This is known as the ICP's 'reverse gas model', which enables developers to pay for the gas costs of their dapp, rather than end-users having to pay gas fees when using a dapp.
+Cycles are used to measure and pay for the resources that are used by a canister, such as the memory, storage, and compute power. For canisters deployed locally, cycles can be fabricated. However, once a canister is deployed to the mainnet, real cycles are charged to pay for the resources being used on the network. This is known as the ICP's 'reverse gas model', which enables developers to pay for the gas costs of their dapp, rather than end-users having to pay gas fees when using a dapp. This helps aid in onboarding new users onto dapps deployed on ICP, since there aren't prerequisites such as needing a cryptowallet containing tokens to interact with a dapp. 
 
 To get cycles, you can convert ICP tokens into cycles, or you can obtain a [cycles coupon](/docs/current/tutorials/developer-journey/level-1/1.4-using-cycles#acquiring-cycles-using-a-cycles-coupon) if you haven't previously received one before. 
 
@@ -168,18 +166,14 @@ Before you can deploy your first dapp on ICP, you will need to set up your devel
 
 - [x] Download and install [git](https://git-scm.com/downloads).
 
-- [x] Download and install the React framework with the command `npm install --save react react-dom`. 
-
-- [x] Download and install the TypeScript language compiler with the command `npm install --save-dev typescript ts-loader`.
-
 - [x] Download and install [Node.js](https://nodejs.org/en).
 
 Then, to download the template project, first create a new directory, then download the project template using the commands:
 
 ```
 mkdir react-project
 cd react-project
-npx degit rvanasa/vite-react-motoko
+npx degit rvanasa/vite-react-motoko react-project
 ```
 
 Then you will need to start a local replica with `dfx` using the command:
@@ -215,6 +209,10 @@ URLs:
     backend: http://127.0.0.1:4943/?canisterId=a4tbr-q4aaa-aaaaa-qaafq-cai&id=asrmz-lmaaa-aaaaa-qaaeq-cai
 ```
 
+In this example, the frontend of the dapp is deployed to a canister locally. To make changes to the frontend canister, the canister must be redeployed each time a change is made to see the changes reflected at the canister's web browser URL. For quicker feedback loops for changes, this example uses a local development server that features hot module reloading. 
+
+For backend canisters, [`mo-dev`](https://github.com/dfinity/motoko-dev-server) enables hot module reloading for backend canisters, which removes the need to redeploy a backend canister to see changes reflected. 
+
 Before interacting with the React interface running in the frontend canister, start the local development server with the command:
 
 ```

docs/tutorials/hackathon-prep-guide/3-exploring-the-backend.md → docs/tutorials/hackathon-prep-course/3-exploring-the-backend.md

@@ -71,7 +71,7 @@ First, the code defines an actor called `Backend`. In Motoko, programs consist o
 actor class Backend() {
 ```
 
-Next, the code defines a variable (`var`) called `counter` with a value of `0`. This variable is defined with the word `stable`, which indicates it is a **stable variable**. A stable variable is a variable defined within an actor which uses the `stable` keyword in the variable's declaration. This indicates that the data stored in the variable should be stored using stable storage. This tutorial will go further into stable storage in the section [stable memory](#stable-memory) If this stable keyword is not used, the variable is defined as flexible by default.
+Next, the code defines a variable (`var`) called `counter` with a value of `0`. This variable is defined with the word `stable`, which indicates it is a **stable variable**. A stable variable is a variable defined within an actor which uses the `stable` keyword in the variable's declaration. This indicates that the data stored in the variable should be persisted during canister upgrades. This tutorial will go further into stable storage in the section [stable memory](#stable-memory) If this stable keyword is not used, the variable is defined as flexible by default.
 
 ```motoko
 stable var counter = 0;
@@ -132,7 +132,7 @@ When developing a project, certain third-party canisters may be beneficial to in
 
 When integrating with third-party canisters, it is important to test the integration locally to assure that the integration is accurate and correct. Performing tests locally is beneficial since tests executed in a local developer environment do not cost cycles, use non-production data, and have a faster completion time when run locally. 
 
-To test the integration with a third-party canister locally, dfx supports pulling a third-party canister from the mainnet via the `dfx deps` workflow. Using this workflow, you can pull a canister from the mainnet by configuring your project's `dfx.json` file to include a `dependency` of the canister you'll be pulling. Then, define the pullable canister as type `pull` and include the canister's ID on the mainnet. For example, to pull the Internet Identity canister with canister ID of `rdmx6-jaaaa-aaaaa-aaadq-cai`, the following `dfx.json` file can be used:
+To test the integration with a third-party canister locally, dfx supports pulling a third-party canister from the mainnet via the [`dfx deps`](https://fnoix-mqaaa-aaaam-abtca-cai.icp0.io/docs/current/developer-docs/setup/pulling-canister-dependencies) workflow. Using this workflow, you can pull a canister from the mainnet by configuring your project's `dfx.json` file to include a `dependency` of the canister you'll be pulling. Then, define the pullable canister as type `pull` and include the canister's ID on the mainnet. For example, to pull the Internet Identity canister with canister ID of `rdmx6-jaaaa-aaaaa-aaadq-cai`, the following `dfx.json` file can be used:
 
 
 ```json
@@ -167,7 +167,7 @@ For more information on using third-party canisters, check out the documentation
 
 When calls are made on ICP, there are two primary types: query calls and update calls. 
 
-**Query calls** are calls that do not alter the state of a canister, making them 'read-only' operations. Query calls are used to query the current state of a canister or make a call to a method that operates on the canister's state. They are executed synchronously and answered immediately once received. Query calls are executed on a single node within a subnet. The backend canister in this example uses the following query call, defined by the keyword `query` as seen above:
+**Query calls** are calls that do not alter the state of a canister, making them 'read-only' operations. Query calls are used to query the current state of a canister or make a call to a method that operates on the canister's state. They are executed synchronously and answered immediately once received. Query calls are executed on a single node within a subnet. Query methods can be called in replicated mode as update calls. The backend canister in this example uses the following query call, defined by the keyword `query` as seen above:
 
 ```motoko
 public query func get() : async Nat {
@@ -206,7 +206,7 @@ For example, a simple service description that defines a service without any pub
 service : {}
 ```
 
-A service description that does not have any pubic methods is not very useful. To add a public method, you can add a simple `ping` method:
+A service description that does not have any public methods is not very useful. To add a public method, you can add a simple `ping` method:
 
 ```
 service : {
@@ -281,7 +281,7 @@ Additionally, Mops is defined as the project's package manager in the project's
 ...
 ```
 
-To add additional packages to your project's dependencies, you can use the command `maps add` then the package name:
+To add additional packages to your project's dependencies, you can use the command `mops add` then the package name:
 
 ```
 mops add base

docs/tutorials/hackathon-prep-guide/4-exploring-the-frontend.md → docs/tutorials/hackathon-prep-course/4-exploring-the-frontend.md

@@ -236,7 +236,7 @@ In this `vite-react-motoko` example, a JavaScript agent is used. An agent is a l
 
 In addition to the JavaScript agent, DFINITY has developed and maintains a Rust agent, and the ICP community supports several agents for .NET, Go, Python, Ruby, and more.
 
-In your `vite-react-motoko` example, the JavaScript agent file is scored at `src/declarations/frontend/index.js`. This file is generated as part of the `npm run setup` command, and contains the following content:
+In your `vite-react-motoko` example, the JavaScript agent file is stored at `src/declarations/frontend/index.js`. This file is generated as part of the `npm run setup` command, and contains the following content:
 
 ```javascript
 import { Actor, HttpAgent } from "@dfinity/agent";
@@ -284,15 +284,21 @@ export const createActor = (canisterId, options = {}) => {
 export const frontend = createActor(canisterId);
 ```
 
-In this code, the constructor first creates an HTTPAgent which wraps the JavaScript API, then uses it to encode calls through the public API. If the deployment is on the mainnet, the root key of the replica is fetched. Then, an actor is created using the automatically generated Candid interface for the canister and is passed the canister ID and the HTTPAgent.
+In this code, the constructor first creates an `HTTPAgent` which wraps the JavaScript API, then uses it to encode calls through the public API. If the deployment is on the local testnet, the root key of the replica is fetched. Then, an actor is created using the automatically generated Candid interface for the canister and is passed the canister ID and the `HTTPAgent`.
 
 You can learn more about agents in the documentation [here](/docs/current/developer-docs/agents/).
 
-### HTTPS interfaces
+### Serving HTTP content
+
+Smart contract canisters are able to serve HTTP content natively, allowing for dapp frontends to be served directly in a web browser using the canister's URL at `http://<canister id>.ic0.app` and `http://<canister id>.raw.ic0.app`. Frontend canisters can be used to deliver  HTML, CSS and JavaScript pages, and answer API requests.
+
+If a canister wants to serve HTTP content, it should implement a method that consumes a HTTP request, which contains a URL, HTTP method and headers, then outputs a HTTP response  that contains a status, headers and the response body. The canister method can return HTML, CSS and JavaScript content as part of the HTTP response. 
+
+### HTTPS outcalls
 
 On ICP, canisters can communicate directly with external servers or other blockchains through the use of HTTPS outcalls. This is a unique feature of ICP, since traditionally, other blockchain networks are only able to communicate with external servers through blockchain oracles, or third-party entities that relay calls from the blockchain to an external server, then route the response back to the blockchain. 
 
-HTTPS outcalls allow smart contract canisters on ICP to make calls directly to external HTTPS servers. Then, the response of these HTTPS calls can be used by the smart contract in a safe way that doesn't result in the a replica state divergence. 
+HTTPS outcalls allow smart contract canisters on ICP to make calls directly to external HTTPS servers. Then, the response of these HTTPS calls can be used by the smart contract in a safe way that doesn't result in a replica state divergence. 
 
 HTTPS outcalls provide the ability for different use cases and have several advantages compared to using oracles to handle external requests. Some of these are HTTPS outcalls use a stronger trust model since there are no external intermediaries required for the canister to communicate with external servers. Using HTTPS outcalls for communicating with external servers makes using canisters feel much closer to a "traditional" programming workflow that may not use blockchains or oracles. Most real-world dapps have a need for accessing data stored in off-chain entities, since most digital data is still stored in traditional 'Web 2' services.