Merge pull request #182 from omahs/patch-2

Fix: typos

Author: briangershon

pages/lessons/projects/1.mdx

@@ -12,7 +12,7 @@ icons: ['solidity', 'remix']
 
 We’re going to build a **smart contract**, but what on Jupiter is a smart
 contract? And what on Earth would we use one for? Well, you wouldn’t find a
-smart contract on either Jupiter, or Earth, and although you maybe grounded to
+smart contract on either Jupiter, or Earth, and although you may be grounded to
 the latter, you are going to deploy yours on a **blockchain**. Not a real
 blockchain, well not at first. Hang on!
 
@@ -25,7 +25,7 @@ and bundled into blocks of a limited capacity and they keep getting added on to
 make a continuing _block chain_. Each transaction contains quite a limited
 amount of information, but gives us transparency so that anyone can trace the
 _money trail_. And this was one of the main intentions of blockchains.
-Transparency. There are ever growing use cases for the types of transactions,
+Transparency. There are ever-growing use cases for the types of transactions,
 financial and non-financial. Let’s move on. The blocks are secured to each other
 with cryptography. A similar type of encryption that is used to secure the
 Signal or Telegram apps on your smartphone…..(any other examples???) If someone
@@ -54,7 +54,7 @@ resistant. Think about that for a second. And it gets better…..
 Really? What’s so special about all of this? Well until recently, we only
 transferred data on the internet. Yes, you could send money too by using some
 kind of banking app, or financial services app like Western Union, but with the
-advent of crypto currencies we can now send _digital_ value… permissionlessly.
+advent of cryptocurrencies we can now send _digital_ value… permissionlessly.
 That's quite a thing! In the early days of crypto we could only transact with
 digital tokens such as BTC and then ETH and soon later, with thousands of
 different coins. But new ideas continue to emerge and we’re going to be building
@@ -286,21 +286,21 @@ contract WAGMI {
 
     ### Visibility of State Variables
 
-    In Solidity , there are 3 types of variable visibility modifiers that a developer can use :
+    In Solidity, there are 3 types of variable visibility modifiers that a developer can use :
 
     - **Public**: If a state variable visibility is marked as `public` then those variables can be used within the smart contract and can be accessed by other contracts as well. Compilers automatically generates functions to read its value when calling the contract, they are called 'getter' functions.
 
-    - **Internal**: A state variable with an `internal` visibility can only be accessed within the smart contract and its derived contracts. It can *NOT* be accessed externally. This is the default for state variables when no visibilty is specified.
+    - **Internal**: A state variable with an `internal` visibility can only be accessed within the smart contract and its derived contracts. It can *NOT* be accessed externally. This is the default for state variables when no visibility is specified.
 
-    - **Private**: When a state variable visibility is marked as `private` it is only meant to be used within the defined smart contract . No derived contract can read a variable with a `private` visibility.
+    - **Private**: When a state variable visibility is marked as `private` it is only meant to be used within the defined smart contract. No derived contract can read a variable with a `private` visibility.
 
     <Callout emoji='💡' size='md' variant='info'>
     While private and internal are not readable or modifiable from other contracts, its values are set on a public blockchain, making its values visible from the outside world.
     </Callout>
 
-    #### Which visibility should I use ?
+    #### Which visibility should I use?
 
-    A simple answer to this is , start with giving every variable a `private` visibility then as you move further in contract developement modify variables to `internal` visibility as a next step of modification. Try to use `public` visibility as little as possible in order to be gas efficient and making less vulnerabilities in the smart contract.
+    A simple answer to this is, start by giving every variable a `private` visibility then as you move further in contract development modify variables to `internal` visibility as a next step of modification. Try to use `public` visibility as little as possible in order to be gas efficient and making less vulnerabilities in the smart contract.
 
 </SideDrawer>
 
@@ -332,7 +332,7 @@ symbols:
 // ...
 contract WAGMI {
 
-    // Don't delete our state variables here !
+    // Don't delete our state variables here!
 
     function getMessage() public view returns(string memory) {
         return message;
@@ -542,7 +542,7 @@ in future lessons, so no worries!
 
     In the Ethereum Blockchain, whenever we run or execute a transaction it stores a log with the results and data of the transaction. Solidity provides us with **Events** so we can write data to said logs.
 
-    Applications can subscribe and listen to this events, or even search for past logs using filters.
+    Applications can subscribe and listen to these events, or even search for past logs using filters.
 
     Whenever a function calls (**emits**) an event, the values passed as parameters are stored in a special data structure in the blockchain: the transaction log. It is worth noticing that Smart Contracts cannot access the log and its event data.
 

pages/lessons/projects/2.mdx

@@ -256,7 +256,7 @@ delegates to transfer them, etc).
 </SideDrawer>
 
 All of it is pretty much for our project, but luckily OpenZeppelin has developed
-a lot of contracts that implements these standards and more, they are widely
+a lot of contracts that implement these standards and more, they are widely
 used and audited and, the thing we love about them, they are open-source and we
 can use them to leverage our learning process. With that in our heads, we are
 going to use them inside our contract.
@@ -401,7 +401,7 @@ So, to let our inherited contract know where our NFTs will be stored, we have to
 you look into OpenZeppelin's documentation. There’s a good reason for
 everything. Well, lots of things. And this is one of them!
 
-Here's the modifications we will add and i'll explain them below:
+Here's the modifications we will add and I'll explain them below:
 
 ```solidity
 // SPDX-License-Identifier: MIT
@@ -506,7 +506,7 @@ collection to have as NFTs. Each of them will have as a minimum a “name”,
 
 As you see in the example, under “image” we have a link to a file on the web,
 which we will refer to as Web2. So, if this website were to go down, our NFTs
-would loose their images, showing us the limitations of the centralization of
+would lose their images, showing us the limitations of the centralization of
 web2 data storage.
 
 ![nft.pepe.jpeg](/assets/lessons/2/img_11.jpeg)
@@ -518,7 +518,7 @@ going to have to go to the moon…
 
 Literally.
 
-There are many services that lets us store files in a decentralized manner. We
+There are many services that let us store files in a decentralized manner. We
 are using the one called IPFS. Inter-Planetary File System. Yep, no joke.
 
 ![ipfs.jpeg](/assets/lessons/2/img_12.jpeg)
@@ -540,7 +540,7 @@ To ease our path into the IPFS network, services for *pinning* content (e.g.
 Pinata) offer paid and free tiers that ensure that the files we upload are
 *pinned* in IPFS.
 
-So, go ahead and grab yourself a free pinata account in this
+So, go ahead and grab yourself a free pinata account at this
 [link](https://www.pinata.cloud/).
 
 One of the peculiarities of IPFS is that files, or better called ‘content’, are
@@ -828,7 +828,7 @@ password (the one you use to open it, NOT your seed phrase). It also shows you a
 notice so you know that you are entering the danger zone. Confirm and you'll be
 able to copy your private key. Paste it in to our `hardhat.config.js`
 
-Please, if your are already a developer and you plan to use git to store your
+Please, if you are already a developer and you plan to use git to store your
 project, don't store your `hardhat.config.js` on it, because you will have your
 private key there.
 
@@ -852,7 +852,7 @@ This is the output i got in my console:
 ![deploy.rinkeby.png](/assets/lessons/2/img_19.png)
 
 Remember we are deploying to the actual blockchain, a testnet, but a blockchain
-none the less.
+nonetheless.
 
 Now that we have run the deploy script, delete the private key and the RPC API
 key from `hardhat.config.js` to minimize the handling of the wallet. In the next
@@ -869,4 +869,4 @@ and [Opensea](https://testnets.opensea.io/collection/d-d-academy)
 ![opensea.png](/assets/lessons/2/img_20.png)
 
 And that's it! You have created your own NFT collection from scratch! What a
-super star!!
+superstar!!