Hello Rustaceans, welcome to the second episode of this series. In case you missed the first episode, check it here.

Quick Recap

During the last episode, we were able to:

1. Set up our dev environment (cargo, rustc).

2. Write our first Rust hello world program.

3. Compile and run the program using rustc

In this episode, we dive into some more detail, where we explore the elements of the Rust Ecosystem.

Let’s dive right in.

The Rust Ecosystem

From the previous episode, we interacted with a number of elements in the Rust toolchain, namely rustc, rustup and cargo.

rustc

At the heart of the Rust ecosystem is rustc, the Rust compiler. It's responsible for translating Rust code into machine-readable instructions. rustc ensures strong memory safety, preventing common bugs like null pointer dereferencing and data races. It enforces ownership, borrowing, and lifetimes, allowing developers to write efficient, safe, and concurrent code.

You can directly use rustc to compile Rust programs by invoking it from the command line. For example:

➜  ~ rustc your_program.rs

The above command compiles the Rust source code in the your_program.rs file into an executable, that you can then run to execute.

rustup

rustup is Rust’s toolchain manager, allowing easy installation and management of different versions of Rust. It simplifies the process of switching between Rust toolchain channels, i.e stable, beta, and nightly builds. rustup also manages associated tools like cargo, the package manager and build system for Rust.

rustup is the equivalent of nvm in the NodeJS ecosystem, pyenv + virtualenv in Python, rbenv or rvm in the Ruby world, and gvm from Go-land.

As mentioned above, there are typically three Rust release channels — stable, beta and nightly. Rust maintains a pretty rapid release cycle — with features being released every six weeks (I am not sure what Rust’s philosophy is on the six weeks release cycle, but I have seen a similar release cycle in Shapeup, a technique developed by our good friends over there at Basecamp. Check it out).

• Stable Channel: The stable channel provides a version of Rust that is considered stable for general use. It is recommended for most users, especially those who prioritize stability over having the absolute latest language features. Code written and compiled on the stable channel is expected to have long-term compatibility. This is the default channel, unless you switch to either of the other two channels.
• Beta Channel: The beta channel contains versions of Rust that are in the testing phase before being marked as stable. Features and changes that have been stabilized in the nightly channel are usually available in the beta channel for wider testing by developers. This channel allows users to experiment with upcoming features while providing feedback and testing before they become stable.
• Nightly Channel: The nightly channel is where the most bleeding-edge features and changes are available. This channel receives updates daily and includes the latest work being done on the Rust compiler and language. It’s primarily used by contributors, early adopters, and those who want to experiment with the newest features. However, code written on the nightly channel might not be stable or fully compatible with future versions.

To identify which channel/toolchain you are running in, issue:

➜  ~ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/shalomz/.rustup

stable-x86_64-apple-darwin (default)
rustc 1.73.0 (cc66ad468 2023-10-03)

To switch between the various toolchains, issue:

➜  hello_rust git:(main) ✗ rustup default <toolchain>

Where toolchain is either stable, nightly, beta or any one of the available toolchains.

cargo

cargo is Rust's package manager and build tool. It simplifies the process of creating, building, and managing Rust projects, handling dependencies, and ensuring a consistent and reproducible build environment.

Rust packages are referred to as crates, and are usually held in https://crates.io.

cargo is Python’s pip + pypi and NodeJS npm or yarn .

You can use cargo to build your Rust programs, generate project structure as well as run tests.

• To check what version of cargo you are running on, issue:

➜  ~ cargo --version

cargo 1.73.0 (9c4383fb5 2023-08-26)

Project Setup: hello_rust

Time to meet our new cargo managed project: hello_rust.

➜  ~ cargo new hello_rust

Created binary (application) `hello_rust` package

➜  ls

hello_rust

➜  cd hello_rust

➜  hello_rust git:(main) ✗ ls -al
total 16
drwxr-xr-x  6 shalomz  staff  192 Nov 19 12:55 .
drwxr-xr-x  3 shalomz  staff   96 Nov 19 12:55 ..
drwxr-xr-x  9 shalomz  staff  288 Nov 19 12:55 .git
-rw-r--r--  1 shalomz  staff    8 Nov 19 12:55 .gitignore
-rw-r--r--  1 shalomz  staff  179 Nov 19 12:55 Cargo.toml
drwxr-xr-x  3 shalomz  staff   96 Nov 19 12:55 src

So, what just happened?

Well, we just instantiated our first project — hello_rust. By issuing cargo new hello_rust, the following happened:

1. Created a new project and folder named hello_rust
2. Created four items inside the hello_rust folder:

• .git (folder)
• .gitignore (file)
• Cargo.toml (file
• src (folder)

Obviously, .git and .gitignore are concerned with Version Control. That is outside the scope of this series, so we move our focus to the other two: Cargo.toml and the src folder.

➜  hello_rust git:(main) ✗ cat Cargo.toml
[package]
name = "hello_rust"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

Anatomy of Cargo.toml

The [package] section basically indicates that it wields information as pertaining to the configuration of our package.

name: is the name of our program — hello_rust

version: is its version — 0.1.0

edition: indicates which edition the Rust compiler should use for our code. As at the time of writing, there are three Rust editions — Rust 2015, Rust 2018 and Rust 2021. We are using Rust 2021 for our project.

The [dependencies] section indicates the packages (crates, in Rustland) that our project needs to run. Since we do not need any at the moment, it is empty for now.

Into the source: Exploring src

Navigating into the src folder, we can see one file: main.rs

➜  hello_rust git:(main) ✗ cd src
➜  src git:(main) ✗ ls
main.rs

Let’s explore the contents of the Rust program main.rs:

➜  src git:(main) ✗ cat main.rs

fn main() {
    println!("Hello, world!");
}

Remember our first Rust program in Episode 1? See anything similar?

Building with cargo

We built and ran our first program using rustc. In this episode, we are going to explore building and running with cargo instead.

For cargo to build and run our programs, we should always ensure they are within the src folder.

From within our hello_rust folder, run cargo build:

➜  src git:(main) ✗ cd ..

➜  hello_rust git:(main) ✗ pwd

/Users/shalomz/Projects/rs/hello_rust

➜  hello_rust git:(main) ✗ cargo build
   Compiling hello_rust v0.1.0 (/Users/shalomz/Projects/rs/hello_rust)
    Finished dev [unoptimized + debuginfo] target(s) in 7.65s

What happened?

1. Running cargo build generates two additional items:

• Cargo.lock (file. This file keeps track of the exact versions of dependencies within our project. Automatically managed by cargo)
• target (folder)

The target folder contains:

• CACHEDIR.TAG (file)
• debug (folder)

Running cargo build uses the debug profile by default, and hence our generated binary will be found inside the debug folder.

➜  hello_rust git:(main) ✗ ls
Cargo.lock Cargo.toml src        target

➜  hello_rust git:(main) ✗ cd target

➜  target git:(main) ✗ ls
CACHEDIR.TAG debug


➜  target git:(main) ✗ cd debug

➜  debug git:(main) ✗ ls -al
total 912
drwxr-xr-x  10 shalomz  staff     320 Nov 19 13:55 .
drwxr-xr-x@  5 shalomz  staff     160 Nov 19 13:55 ..
-rw-r--r--   1 shalomz  staff       0 Nov 19 13:55 .cargo-lock
drwxr-xr-x   3 shalomz  staff      96 Nov 19 13:55 .fingerprint
drwxr-xr-x   2 shalomz  staff      64 Nov 19 13:55 build
drwxr-xr-x  10 shalomz  staff     320 Nov 19 13:55 deps
drwxr-xr-x   2 shalomz  staff      64 Nov 19 13:55 examples
-rwxr-xr-x   1 shalomz  staff  462632 Nov 19 13:55 hello_rust
-rw-r--r--   1 shalomz  staff     113 Nov 19 13:55 hello_rust.d

Our interest should be drawn to the hello_rust executable that we can then run like this:

➜  debug git:(main) ✗ ./hello_rust
Hello, world!

Apparently, building and running our programs this way is not ideal — we can use cargo runto improve this.

From within the hello_rust folder, issue cargo run:

➜  hello_rust git:(main) ✗ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/hello_rust`
Hello, world!

cargo run builds the program then runs it. Easy, right?

To build with the release profile, explore cargo build --release.

Wrapping Up

In this episode, we have explored rustc, rustup and cargo.

We have seen how each one is useful to us in building and compiling our Rust programs.

Furthermore, we have been drawn to:

• Rust channels and release cycles.
• How to set up projects using cargo new.
• General anatomy of Cargo.toml files.
• Build projects using cargo build
• Run our Rust projects in one go with cargo run

See you in the next one. Stay Rusty!

The question of whether computers can think is like the question of whether submarines can swim. — Edsger Dijkstra

As at the time of publishing, Rust has been voted as the most loved Programming Language on StackOverflow for 8 years in a row.

Rust is a promise of robust and efficient code. It’s a language designed for the modern world, addressing the ever-present challenges of software development. But, like any journey, it starts with a single step. Allow me to walk with you in this journey.

This episode will introduce you to Rust, why you should care about Rust as well as how to set up your environment and write your first “hello world”.

The aim is to be concise, and that’s exactly how we shall do this.

Why Rust?

In the rapidly evolving landscape of programming languages, Rust stands out for a multitude of reasons. Here are a few:

• Memory Safety: Rust was built from the ground up to provide robust memory safety. It practically eliminates null pointer dereferencing, data races, and other common sources of crashes and vulnerabilities. When you write Rust, you can trust your code to be safe.
• Performance: Rust’s zero-cost abstractions and fine-grained control over system resources make it a top choice for systems programming, embedded systems, and high-performance applications. You don’t have to choose between safety and performance; Rust offers both.
• Concurrency: Rust’s ownership and borrowing system allows for safe and efficient concurrency without the usual pitfalls of race conditions and data races. You can write concurrent code with confidence.
• Community and Ecosystem: The Rust community is vibrant and welcoming. You’ll find a rich ecosystem of libraries and tools, all backed by a community committed to open-source collaboration and quality.

Setting Up Your Environment

Install Rust

For *Nix users, it is recommended to install Rust usingrustup.

On your terminal, run:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

The current version of Rust as at the time of publishing is1.73.0 and that’s what we install. If you already installed Rust before, update it by running:

rustup update

For Windows users, please refer here.

Meet Cargo

The rustup installation comes with cargo, Rust’s build tool and package manager. For those coming in from the JS world, cargo is like yarn or npm.

In summary, we use cargo to build our Rust code and dependencies. More on cargo in the next episodes.

To ensure you have cargo installed, run:

$ cargo --version
 
cargo 1.73.0 (9c4383fb5 2023-08-26)

Hello World

To ensure our toolchain is all tied together, we are going to write our first line of code: the hello world.

First, let’s make sure we have installed Rust properly:

$ rustc --version

 rustc 1.73.0 (cc66ad468 2023-10-03)

Setup Project Structure

Let’s begin by setting up a directory to hold our code:

mkdir ~/zero-to-one-rust

cd ~/zero-to-one-rust

mkdir ep1

cd ep1

Inside the directory, let’s create our first Rust file, main.rs

touch main.rs

Inside it, let’s add our code:

fn main(){
  println!("Hello, world");
}

Compiling & Running

To run the code, you have to first compile it.

$ rustc main.rs
$ ./main

Hello, world

Conclusion

To keep things short and sweet, let’s wrap up Episode 1 here. Over the next few episodes, we shall explore the anatomy of Rust functions, syntax and concepts in Rust.

Until next time, stay Rusty.

If we forget, we’ll waste memory. If we do it too early, we’ll have an invalid variable. If we do it twice, that’s a bug too — Steve Klabnik

A workman is as good as his tools

Programming languages are just but tools. You can solve a myriad of problems using most of the available programming languages.

Each language thrives in different areas and struggles in others. It all boils down to a workman knowing his tools and which ones to use for which job.

As such, here is my own extension of the saying:

A workman is as good as his tools, and his ability to correctly identify which one to use for the different problems at hand.

Rust

Those who have known me for a while can attest to the fact that I am a huge Python fan. I have utilized (and still continue to utilize) Python to solve lots of problems around me on a daily basis. Matter of fact, I actually contribute to the python open source community once in a while.

So, why Rust?

I do not wish to be embroiled in Programming Language fights (hey GoLang friends, I see you! ) so I will rest the case with one statement: Rust is yet another programming language that you can use to solve your problems. It is not a silver bullet — none is, so contextualize your problem before jumping to use Rust, or any other language in earnest.

This will be a 7 part series that I will share to mirror my journey from zero to one in Rust.

I hope to provide a step by step guide on mastering the Rust fundamentals that can be used as a launching pad for engineers looking to take off in their Rustlang journeys.

Feel free to follow me to get notified as soon as I post.

In other news: are you looking for a space to work from, for those days when your home office just doesn’t cut it? Or are you a startup with no designated office spaces yet? Well, Launchpad by Impact Africa Network is exactly what you need. Check them out! The address is 29 Westlands Avenue, Nairobi, KE.

See you in the series.

Let’s get Rusty. Over and out.

Given a time series of the price of a stock ticker symbol at millisecond granularity e.g. [12, 23, 34, 55, 2, 51]
Objective:
Find the best time to buy and sell, given the time series, and the maximum profit
Assumptions:
1. You may only buy and sell at most once
2. You may only sell after you buy
Return a tuple of the best time to buy, the best time to sell as well as the maximum profit

Test Cases:
[12, 23, 34, 55, 2, 51] should return (4, 5, 49)

Hey engineers, does the above excerpt sound familiar? I bet it does!

In the course of human existence, problems do arise as an inseparable part of our life’s rich tapestry. A complex equation here, an intricate puzzle there, or a difficult situation here— we have all faced challenging situations in our day to days. I have learned to take problems head-on and use them as opportunities for growth.

As a software engineer, you are always faced with technical problems — be it in interviews or at work.

Consider the above problem: finding the best time to buy and sell assets given a time series of the price of a stock ticker symbol.

Simple problem, right?

The Approach

Just by reading through the problem statement, you may instantly begin to develop probable paths of action to solve this problem.

I have, over time, learned that despite the constant urge to instantly dive into start writing the code, this may not be the best approach.

Disclaimer: I don’t claim to have invented the techniques highlighted below. My intention is to tell you how I approach (most) problems and what has worked for me so far😜

In summary, I have come to resort to the following approach:

1. Understand the problem and state it clearly.
2. Establish the Inputs and Outputs. Look through the provided inputs and outputs. Make sure they align with the problem statement.
3. Edge cases. Be sure to add test cases for inputs that should capture the edge cases.
4. Algorithm — Establish a solution for the problem statement in (1) above in English. Focus on correctness first
5. Code — Implement the solution and feed it with the test inputs and edge cases. Capture and fix bugs if any.
6. Analysis and Optimization— How efficient is the algorithm? How do we optimize its performance?

1. Understand The Problem

We first need to understand the problem at hand and clearly at that. More often than not, it helps to express the problem in our own words.

A problem well stated is a problem half solved.

— John Dewey

Here, we also need to define the function signature. The body of the function will be empty to start with (unless you have been provided with a function signature as part of the problem).

The function name should be descriptive of the purpose of the function.

For instance:

def find_best_buy_sell_time(): # Empty for now
    ...

We obtain the parameters for this function (a listof prices — price_list) and the expected return value (a tupleof the best buy time, best sell time, and max profit) from the problem statement:

from typing import List, Tuple

def find_best_buy_sell_time(price_list: List[int]) -> Tuple[int, int, int]:
    """
    Given a python list representing a time series of the price of a stock ticker symbol at millisecond granularity, find the best time to buy and sell and the maximum profit.
    Rules:
    1. You can only buy and sell at most once
    2. You may only sell after you buy
    3. The buying price does not necessarily have to be the minimum in the list. You should make some profit

    Args:
        price_list (List[int]): The price list

    Returns:
        Tuple[int, int, int]: The tuple containing the best time to buy, the best time to sell and the maximum profit
    """
    ...

2. Establish Inputs and Outputs

We then proceed to retrieve the provided inputs and expected outputs from the problem statement, if any.

In addition to this, we should define additional inputs and expected outputs for cases not covered by the provided test cases. There are always edge cases, and we should always strive to provide solutions that cover all the bases. Murphy’s law applies here folks.

Anything that can go wrong will go wrong.

It is recommended to do this at this moment since by now, you do have a clear understanding of the problem and can define what outputs should be expected given a set of inputs. This makes it easier to identify the edge cases beforehand.

You could define the input and output test cases in a list of dictionary scenarios to ensure visibility:

from typing import List, Tuple

def find_best_buy_sell_time(price_list: List[int]) -> Tuple[int, int, int]:
    """
    Given a python list representing a time series of the price of a stock ticker symbol at millisecond granularity, find the best time to buy and sell and the maximum profit.
    Rules:
    1. You can only buy and sell at most once
    2. You may only sell after you buy
    3. The buying price does not necessarily have to be the minimum in the list. You should make some profit

    Args:
        price_list (List[int]): The price list

    Returns:
        Tuple[int, int, int]: The tuple containing the best time to buy, the best time to sell and the maximum profit
    """
    ...


tests = []
test = {
    'input': [12, 23, 34, 55, 2, 51],
    'output': (4, 5, 49)
}
tests.append(test) # Append other tests here. Summarized for brevity.
# You will then proceed to run the test cases into your function 

3. Identify Edge Cases

We then proceed to define test cases for the edge cases.

PS: It is NOT MANDATORY to always exhaustively identify ALL the edge cases at the first run. You can always revisit this step and add more edge cases.

We need a clear understanding of the programming language and its data structures since that knowledge helps us pre-empt some common errors, for example, in Python, whenever we are dealing with alist or a dictionary we need to ensure we take care of common exceptions such as IndexError, ValueError, etc.

Some edge cases could include:

i. The price_list list may be empty.

ii. The price_list may contain values with no combination that results in a profit.

iii. Sometimes, there may be scenarios whereby the buying price does not necessarily have to be the minimum in the price_list list.

We append the edge case scenarios to the tests list.

4. Write the Algorithm (Plain English)

Since this is the first iteration, we are aiming for correctness — meaning that our proposed solution, given the defined scenarios and tests, should solve the problem without fail. Our proposed solution should just work. We can focus on fine-tuning it for efficiency later.

Here, we think of the simplest and most obvious solution:

1. Initialize max_profit, buy_timeand sell_timeat 0. Initialize an emptyprofits dictionary
2. Iterate over the elements of the price_list list
3. For each element, capture the profit of buying that element and selling the other elements and store that in the profits dictionary
4. At the end of the iteration, find the key with the highest profit value from the profits` dictionary and return its associated buying_time, selling_time, and max_profit.

Writing down the algorithm in plain English helps us to think clearly about all the factors in question. As such, the clearer we piece down our thoughts here, the easier it then becomes for us to churn out the associated code.

5. Code

For those of us who have been itching to write some code, now is the time.

Here, we should proceed to implement our solution by filling in the function skeleton we defined in step (1) above:

def find_best_buy_sell_time(price_list: List[int]) -> Tuple[int, int, int]:
    """
    Given a python list representing a time series of the price of a stock ticker symbol at millisecond granularity, find the best time to buy and sell and the maximum profit.
    Rules:
    1. You can only buy and sell at most once
    2. You may only sell after you buy
    3. The buying price does not necessarily have to be the minimum in the list. You should make some profit

    Args:
        price_list (List[int]): The price list

    Returns:
        Tuple[int, int, int]: The tuple containing the best time to buy, the best time to sell and the maximum profit
    """
    profits: Dict[
        int, Dict[int, int]
    ] = {}  # Dictionary to store all possible profits for each buying and selling pair
    
    # breakpoint() Start debugger
    for i in range(len(price_list)):
        buy_price: int = price_list[i]
        profits[
            i
        ] = (
            {}
        )  # Create a nested dictionary to store profits for the current buying time

        for j in range(i + 1, len(price_list)):
            sell_price: int = price_list[j]
            profit: int = sell_price - buy_price

            if profit > 0:
                profits[i][j] = profit  # Store the profit in the nested dictionary
    print(profits)
    # Find the highest profit and corresponding buying/selling times
    max_profit: int = 0
    buy_time: int = 0
    sell_time: int = 0

    for buy, sell_dict in profits.items():
        for sell, profit in sell_dict.items():
            if profit > max_profit:
                max_profit = profit
                buy_time = buy
                sell_time = sell

    return (buy_time, sell_time, max_profit)

tests = []
test_1 = {
    'input': [12, 23, 34, 55, 2, 51],
    'output': (4, 5, 49)
}
tests.append(test1) 
test_2 = {
    'input': [],
    'output': (0, 0, 0) # Assuming there are no elements in the list
}
tests.append(test_2)

# Append other tests here. Summarized for brevity.
# You will then proceed to run the test cases into your function
# This code does not cater for all the cases. It only serves as a pointer

We then proceed to run our test cases to validate the logic in our solution.

Should we find any failing test cases, we should revisit our function and update our code to cater for those scenarios.

Given the above function, can you already identify a possible scenario that will fail? Don’t be shy — let’s engage in the comments section😁.

6. Analysis and Optimization

The next step we need to take is to analyze our defined algorithm’s complexity and optimize it.

Here, we concern ourselves with the time and space complexities of the algorithm.

We shall explore complexity in another follow up post.

You can read more on it here.

Conclusion

Throughout this post, we have delved into the intricacies of problem-solving by exploring a 6-step technique.

I acknowledge that it is not a silver bullet, but it should be sufficient for most scenarios — whether you are tackling a technical interview or solving that task at work.

I appreciate your thoughts and feedback.

If your only tool is a hammer, then every problem looks like a nail.

— Abraham Maslow

As I typed the very first print(‘hello world’) statement and hit run on my battered Dell Latitude E5400 laptop, (the said machine truly deserves a standing ovation😁) my eyes lit up with excitement. I was following along Mark Lutz’ masterpiece — Learning Python (5th Edition).

The year was 2014, and I was a meagre 2nd year Computer Science student. And that, ladies and gentlemen, is how I thrust myself into the world of Python and software engineering.

It feels so yesterday now, although it has been a solid 9-years-later. I now write more structured code, running across multiple servers and doing more than just echoing a simple hello world on the console. With this, my focus has shifted to writing solutions that are more performant, scalable and maintainable.

It has and still continues to be a learning journey. Every day is an opportunity to grasp new information and I have made this my mission — to understand as much as possible about my line of work, and how to do things better.

“Learning never exhausts the mind; it only ignites the flame of curiosity and fuels the desire for knowledge.” — Unknown

My Journey

I will highlight my journey in two broad steps:

1. Campus

The first stint I had at Python was my campus’ group project. This was during my 2nd year. Introduction to OOP by Mr. Odiyo (I was at Egerton University, Njoro) and the subsequent group project, you know the drill.

I have no idea how, but together with my buddies Silas, Epiphany and Cyrus, we somehow settled on Python (Django) for our group project, instead of Java — which the course work was based on. The project was a simple document management system that included a couple of “cool” features like Optical Character Recognition (OCR). We dubbed it docusys. The codebase is still somewhere within my old Github profile. Amateur, clunky even— but got the job done.

Our presentation was mired in a myriad of tough questions — mainly revolving around our choice of Python, and not Java. Of course, we being naive, argued our way out of the conversation by pulling out the “Python is short and concise” card. I mean, you obviously can get hello world on your console faster in Python than in Java, eh?

I subsequently went on to build multiple other interesting projects in Python and Django. There was so much to learn, and YouTube was (and still is) a very good friend during those moments. I learnt a lot, from basic problem solving, first principles all the way to reverse engineering and debugging code written by others. All these have proven useful over the years.

My campus journey culminated in my final year project — a real time code sharing platform, complete with real time chat and comments. In hindsight, I got lots of things wrong (as far as building scalable and performant code is concerned), but we live and learn. And such is life.

2. Post-campus

I got my very first engagements before completing campus, but let’s focus on how the journey went immediately after school.

I got two interviews, all within days apart from each other. The first interview was organised by Savannah Informatics. They were recruiting on behalf of Safaricom, I believe. Now, back then, Java was largely the standard — especially for established entities like Safaricom and a majority of the banks.

You can imagine the shock on my face when I got presented with a Java-centric written interview. All those years of me throwing shade on Java flashed before my eyes, and all I could feel was deep regret on why I neglected the language. I settled down and scribbled away the much I could remember. Luckily, most programming languages are founded on the same principles. I obviously struggled with the syntax, but eventually got into the second round — a practical session at Safaricom HQ in Westlands. Requirement: Carry your laptop.

At this point, I still am with my old and faithful servant — the Dell Latitude E5440. Its health had deteriorated significantly, and getting it to power on at the first attempt was more on luck. A hit or miss. All interviewees were given access to internet, and a simple (simple might be relative, but here goes) problem statement — to implement a CRUD API, test it using Postman and submit the code and Postman collection for evaluation. I smiled. There was no way I was failing this one. Just no way.

Needless to say, I did not make it. Two hours later, after settling down, I was still fumbling with my laptop. My not-so-faithful servant had decided to not wake up when I needed it the most. My footsteps were heavy that evening, as I trudged sluggishly to the bus stage to board a matatu to town, knowing I had blown that chance. Well, I had another interview in two days, and I consoled myself that I still had another opportunity elsewhere, and that I there was no way I was gonna code in Java anyway😁. A classical example of Aesop’s proverbial fox that misses the grapes and calls them bitter.

I mauled the second interview, which, luckily, was in Python, and my journey took off. The rest, as they say, is history.

Several months later, I decided to go freelance. Interacting with other engineers from other countries really does open your eyes in all aspects in terms of culture, knowledge and experience.

For the past two and a half years, I have been leading an Engineering team. The journey is interesting and exciting, since there is more to learn every single day. Taking such a drastic change — from being an individual contributor to providing leadership to teams working on multiple diverse projects — is not an easy feat (comes with its fair share of challenges), but I have benefited from lots of help from amazing people. I am looking forward to writing a bit more on this over the next few months.

Over the years, I have dabbled in med-tech, fintech, blockchain, data and DevOps. All along, I have leaned heavily on Python and its ecosystem to build out infrastructure — from consuming APIs, to exposing APIs, to developing reusable modules and libraries, to implementing Infrastructure as Code (IaC) tools.

I contribute to the Open Source community whenever I have the time, and am the chief nut behind dfuse-python — A Python wrapper for interfacing with dfuse, which, quoting from their website, empowers developers with capabilities to build modern blockchain applications with fast, fluid interfaces that deliver exceptional user experience. Go ahead and `pipenv install dfuse` it. Code is here.

I also contribute to the django-localflavor codebase — where I implement the Kenya-specific Django helpers.

Whenever I am not learning on how to be a better Engineering lead, you will catch me exploring a couple of interesting tools and languages, especially within the Rustlang ecosystem.

Above all else, I have learnt to appreciate the hunger to learn, ask (meaningfully intelligent) questions as well as benefit from the experiences of others.

Stay hungry. Stay foolish.

It has been quite some time since I posted anything here.

A lot has changed over the past two-three years, and I have taken slightly a different path in my career.

I got an opportunity to transition to leading a young and growing Engineering Team at Impact Africa Network. I have had a lot to learn and unlearn.

I intend to revisit writing, and I will be sharing a clear path soon enough.

Cheers!

Hello there! Welcome to this series. It is meant to be an introductory piece, for those getting into EOSIO.

We shall go over a number of concepts as relates to EOSIO, though some of them are not EOSIO-specific, and are applicable in other similar technologies.

I will take a dumb approach, and will assume that you are not familiar with EOSIO concepts. Feel free to skip to consequent parts, as you deem fit. This article will be updated continuously with the addition of each new part of the series.

So, let’s dive right in!

Wait, what exactly is EOSIO?

So, before we get ahead of ourselves, let’s first identify what EOSIO is:

EOSIO is software that introduces a blockchain architecture designed to enable vertical and horizontal scaling of decentralized applications (the “EOSIO Software”) and can be used to launch private and public blockchain networks. This is achieved through an operating system-like construct upon which applications can be built. – https://developers.eos.io/eosio-home/docs/10-big-picture

EOSIO is a Blockchain platform developed to host and run decentralized applications in a scalable manner.

Vertical scaling: this means adding more power/resources (CPU, memory) to a setup to increase throughput.

Horizontal scaling: this entails adding more machines/nodes to the pool to increase throughput.

Ah, and what exactly is this “blockchain” thing?

It looks like, in our haste to jump into EOSIO, we may have skipped the core concept: Blockchain.

PS: if you are already familiar with what blockchain is, feel free to skip this section.

Blockchain is basically a digital ledger, containing records (referred to as “blocks”) that are cryptographically linked to each other.

Evidently, the advantage of Blockchain technology is that it offers security, immutability, traceability and no single point of failure.

For in-depth introductions to what this Blockchain animal is, check out the following links:

• Introduction to Blockchain technology | Set 1 - GeeksforGeeks
• Blockchain Technology Explained: Introduction, Meaning, and Applications | HackerNoon
• A simple introduction to Blockchain technology

Why EOSIO?

In this section, we shall highlight the prominent features of EOSIO.

1. C++/WASM Virtual Machine

To develop applications to run on the EOSIO environment (smart contracts), you will use C++. This is a very mature language that is already being used by many developers and entities globally.

In addition to this, EOSIO uses a web assembly (WASM) virtual machine to execute the smart contract code.

Smart contract – this is a piece of code that can execute on a blockchain and keep the state of contract execution as a part of the immutable history of that blockchain instance.

2. Scalability

The EOSIO software has been implemented in a way that makes it possible to achieve a high throughput. Currently, EOSIO has been proved to sustain over 4000 transactions per second (TPS).

High throughputs are attractive to enterprises processing huge numbers of transactions per second.

3. Speed – EOSIO is faaast!

EOSIO has been designed to have low transaction confirmation latency (500ms). As such you do not have to wait for an entire 30 minutes for confirmation that your transfer has gone through😊.

4. Permissions

EOSIO has an elaborate accounts and permissions system.

Account names are normally 12 characters long, though there are exceptions. Accompanying this account name system, is the permissions system.

EOSIO allows users to create custom permissions (that can only be used to perform certain actions, for example) or even split authorities across multiple accounts with different authority weights (multi-signature, or, as commonly known, multi-sig).

For a comprehensive walkthrough on permissions, check out these series by EOS Canada.

The building blocks of EOSIO

1. Nodeos

This is the core EOSIO daemon, responsible for p2p networking, smart contract execution as well as data persistence. (You can read more on EOSIO data persistence solutions here, thanks to cc32d9)

Nodeos is usually run with various plugins to achieve the various functionalities.

2. Keosd

This handles key management on EOSIO.

3. Cleos

This is a command line (CLI) tool for interacting with the EOSIO ecosystem. It provides functionality such as pushing transactions, getting information from the chain et cetera et cetera.

There are a number of other tools to interact with EOSIO, such as EOSJS (JavaScript SDK used to interact with EOSIO via the RPC API), eosc by EOS Canada and pycleos by EOS New York.

Wrapping it up

Phew! That must have been quite a ride.

For the technically oriented readers, there were no bones to chew here, and you may have found this piece quite a bore.

Nevertheless, sit tight and wait for the consequent parts. I assure you, we shall have fun!

PS: Watch out for part 1 – where we shall reveal what we shall build in the course of this series.