Merge pull request #39 from hmmdeif/language-fix-1

Use `fortunately` instead of `hopefully` for clearer language

src/basics/building-contract.md

@@ -28,7 +28,7 @@ thing to do.
 ## Aliasing build command
 
 Now I can see you are disappointed in building your contracts with some overcomplicated command
-instead of simple `cargo build`. Hopefully, it is not the case. The common practice is to alias
+instead of simple `cargo build`. Fortunately, it is not the case. The common practice is to alias
 the building command to make it as simple as building a native app.
 
 Let's create the `.cargo/config` file in your contract project directory with the following content:

src/basics/execute.md

@@ -865,7 +865,7 @@ call. Now, as we have an error value, we can check if it matches what we
 expected with an `assert_eq!`. There is a slight complication - the error
 returned from `execute_contract` is an
 [`anyhow::Error`](https://docs.rs/anyhow/1.0.57/anyhow/struct.Error.html)
-error, but we expect it to be a `ContractError`. Hopefully, as I said before,
+error, but we expect it to be a `ContractError`. Fortunately, as I said before,
 `anyhow` errors can recover their original type using the
 [`downcast`](https://docs.rs/anyhow/1.0.57/anyhow/struct.Error.html#method.downcast)
 function. The `unwrap` right after it is needed because downcasting may fail.

src/basics/good-practices.md

@@ -9,7 +9,7 @@ Due to Rust style, all our message variants are spelled in a
 but it has a drawback - all messages are serialized and deserialized by serde
 using those variant names. The problem is that it is more common to use [snake
 cases](https://en.wikipedia.org/wiki/Snake_case) for field names in the JSON
-world. Hopefully, there is an effortless way to tell serde, to change the names
+world. Fortunately, there is an effortless way to tell serde, to change the names
 casing for serialization purposes. Let's update our messages with a `#[serde]`
 attribute:
 
@@ -125,7 +125,7 @@ pub enum QueryMsg {
 ```
 
 You may argue that all those derives look slightly clunky, and I agree.
-Hopefully, the
+Fortunately, the
 [`cosmwasm-schema`](https://docs.rs/cosmwasm-schema/1.1.4/cosmwasm_schema/#)
 crate delivers a utility `cw_serde` macro, which we can use to reduce a
 boilerplate:
@@ -283,7 +283,7 @@ I encourage you to go to generated file to see what the schema looks like.
 
 The problem is that, unfortunately, creating this binary makes our project fail
 to compile on the Wasm target - which is, in the end, the most important one.
-Hopefully, we don't need to build the schema binary for the Wasm target - let's
+Fortunately, we don't need to build the schema binary for the Wasm target - let's
 align the `.cargo/config` file:
 
 ```toml

src/basics/query-testing.md

@@ -171,7 +171,7 @@ mod tests {
 ```
 
 We needed to produce two entities for the `query` functions: the `deps` and `env` instances.
-Hopefully, `cosmwasm-std` provides utilities for testing those -
+Fortunately, `cosmwasm-std` provides utilities for testing those -
 [`mock_dependencies`](https://docs.rs/cosmwasm-std/1.0.0/cosmwasm_std/testing/fn.mock_dependencies.html)
 and [`mock_env`](https://docs.rs/cosmwasm-std/1.0.0/cosmwasm_std/testing/fn.mock_env.html)
 functions.

src/cross-contract/map-storage.md

@@ -240,7 +240,7 @@ pub fn donate(deps: DepsMut, info: MessageInfo) -> Result<Response, ContractErro
 
 If I had to write a contract like this, and this `donate` would be a critical,
 often called flow, I would advocate for going for an `Item<Vec<Addr>>` here.
-Hopefully, it is not the case - the distribution does not have to be linear in
+Fortunately, it is not the case - the distribution does not have to be linear in
 complexity! It might sound a bit crazy, as we have to iterate over all receivers
 to distribute funds, but this is not true - there is a pretty nice way to do so
 in constant time, which I will describe later in the book. For now, we will