DEV Community: Pan Chasinga

Taking Back Control in 2024

Pan Chasinga — Wed, 08 Jan 2025 16:58:28 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

In 2024, I hit a significant milestone, or rather, a ginormous roadblock. I turned 40, birthed my second child, and faced a year-long depression. Well, the only milestone I could think of was the 10-year anniversary of my programming journey.

I started writing code as a hobby to experiment with creating graphics on computer. I was always a visual person -- I still am. Then as I became more adept to experiment, I used code to control hardware. Then I used code to fight tyranny. My relationship with the computer used to be fun and adventurous.

Then, life knocked on my door. It was time to make a living out of it. Either I had to abandon code or turn it into a real career. I started learning more conventional languages and frameworks and got better at writing web apps and servers. Years later, I successfully started my own open-source project. Then I joined Recurse Center while doing nothing but coding and raising my first child for a month. It was peak fun.

Then, I was flown to Silicon Valley for my first real engineering position with a YC-backed start-up. Silicon Valley! In my mind, I must have felt like a young Brad Pitt getting his first role in Hollywood. My excitement was overflowing. I thought my life was skyrocketing like TSLA stock in 2021.

But I was wrong. That was the peak, and it was about to fall. I didn't like the life in the Bay Area. I was comfortable with much better earning and my wife could afford to stay home to raise my child, but something was missing. My relationship with code changed. It felt transactional, because I was in the confines of requirements and proprietary software. I could no longer contribute to open-source. My commit streak suddenly went out like the Christmas lights on the 26th of December.

And that was also when I began to stop writing. What's the point? There was nothing to tell.

This strained relationship would continue regardless of how many jobs I changed. Sometimes, I could feel it returning for a while, working on a fun project, but it never lasted. I realized I was burning out. It was well-documented in this 2018 blog post.

Eventually, I moved out of the Bay Area to where I could afford a home, and I welcomed the change. After all, living in a place where people's goals were to get a job in the FAANG and the moms were left with their children in the playground was boring.

Then, the house became an enormous burden. I was tired of maintaining it. So, in 2024, I took up DIY. I learned and spent a ton of money and time on things from restoring cars to woodworking to soldering. I wanted to feel the maker in me once more. And if coding or writing cannot give me that, manning a power saw and cutting wood will. I took a lot of time in trial and error but much more time idling in fear. I gradually learned that it's my mind that's been betraying me the whole time. Wired for comfort, it was constantly fighting against my will. My will to write, code, and take apart cars. I constantly found myself feeling exhausted without having done much daily.

Then, I started talking to someone I could trust. I read books on topics in healing. I stopped drinking entirely. I went back to working out, and when I couldn't, I committed to take 10k steps every day. I realized that to gain control of my mind, I have to feel good about my body. I wasn't going to let anyone -- Not even my family -- Stop me from taking care of myself.

I'm happy to report to you that, after 4 months of actively and mindfully taking care of myself, I'm back writing again in 2025! I don't care about what to write about, I just write. I published my first Rust crate to crates.io for everyone to see and use. I'm actively working on remodeling my boy's room.

Taking back control of my life has been my best accomplishment so far this year.

I hope everyone is making the best of 2025, but if you aren't, that is okay. Life is never a straight road, and it's full of detours and climbs. As long as you know yourself, you will be just fine.

I will be seeing you quite often from now on. If you like to read more about mental health and taking care of yourself as a technologist, please follow me. If you're struggling with personal life and career, please follow me or drop a comment. I intend to write about these topics much more.

How to set better 2025 Goals

Pan Chasinga — Mon, 06 Jan 2025 20:26:58 +0000

For me I've realized that, going back through my failed resolution goals, I have never set a higher value to change my behaviors. These are examples of those goals:

Learn a new programming language X
Learn how a computer works
Become 10x more productive

They are shallow, unmeasurable goals that are rather by-products of some higher-level behavioral changes that need to happen first. For instance, these are way better goals:

Make decisions I won't regret (my goal)
Walk 10k steps each day
Drink 10+ glasses of water
Wake up at 4 am every morning

Granted these are just examples that are not for everyone. But to make a point - You won't be learning anything new or becoming 2x productive without changing yourself and/or your environment. It is foolish to think we can force our brain to take on something different without training it to adopt better, positive thinking. And that, my fellow devs, is because of your brain.

Our brain is an ancient machine that's been programmed for comfort over hundreds of thousands of years of evolution, taking as little risk as possible to stay in its safest state. Before the Industrial Revolution, which was barely hundreds of years ago, our race was geared toward basic survival. We are basically carrying around an arcane, self-sabotaging CPU into the world where AI is increasingly becoming more powerful.

So this New Year, instead of setting another unrealistic set of goals, set small but repeatable ones that compound to change your outlook and behaviors.

What are some of these goals you can set for yourself?

What is Semantic API?

Pan Chasinga — Mon, 06 Jan 2025 19:38:26 +0000

💡 Semantic API is the strict practice of using literature and various design methods to curate, guide, guard, and improve the understanding of the user of a programming interface such as a library, command line tool, etc.

I have been writing code for a good decade and what I have most struggled with (and convinced that the majority of developers are) was the opaqueness and obscurity of the libraries’ API and other interfaces, like command line tools. The user experience has been studied thoroughly on the user-facing software, but it is rarely a topic of serious discussion among developer communities when it comes to library, SDK, and tooling development.

I’m convinced that the common UX methods cannot be simply applied to developers’ experience (that’s likely why XCode has a poor review). After all, the implicit goal for developers is to learn about the inner workings of what they are building. UX methods commonly strive to hide and abstract away the details in favor of friendliness to increase user retention. We have been applying the same principles to development with “developer-friendly” APIs that glaze over the greasy parts and hide them away by providing opinionated defaults for the users. We have built a magical culture of sloppy development clobbering together bits and pieces of dependencies into software that barely stands up on its own, all to gain short-term productivity.

I believe the missing link to building sustainably is to Semantic APIs and toolings that encourage developers to learn more about the libraries they have downloaded from npm, pip, cargo, or any other package managers. Of course, this inevitably will require some sacrifice to the short-term gain in productivity, but the long-term gains will far outweigh the immediate friction. To design a semantic API, one has to put on a literature hat on top of an engineering one. Every names will have to effectively communicate the intention of itself.

Let me give an example by demonstrating a subset of UInt256 package I’m working on in Rust. It is a zero-dependency, from-the-ground-up implementation of a 256-bit integer type commonly used in Ethereum Virtual Machine. There are a few implementations out there, but they all do the same thing — Glazing over the potential knowledge of n-bit integers and ignoring the potential of users learning. Through their API and method designs it is clear the goal is to help experienced developers get things done without reinventing the wheel — In this case, implementing their very own 256-bit integer type. And thus, that was what I set out to do.

let bytes = [
  0xff, 0x45, 0x67, 0x89, 0x0a, 0xbc, 0xde, 0xf1, 
  0x23, 0x45, 0x67, 0x89, 0x0a, 0xc2, 0x03, 0xd5,
  0x12, 0x34, 0x56, 0x78, 0x90, 0xab, 0xcd, 0xef,
  0x12, 0x34, 0x56, 0x78, 0x90, 0xab, 0xcd, 0xef,
];

let num = UInt256Builder::new()
    .with_endian(Endian::Big)
    .from_bytes(bytes)
    .build();

Note the following:

Without calling with_endian(Endian) this operation will panic. There is no assumption of a default endianness. You are responsible to learn about and configure it. There is just no shortcut to not understand endianness or the user will quickly hit a roadblock converting between number types.
from_ bytes([u8; 32]) takes a bytes array of exactly 32 bytes, not vectors. Fixed-size bytes array ensure correctness of data, but more important, it ensures the user actually understand byte data. Vectors would have completely glazed over this for the sake of friendliness. But real friends expect the best from you and put you on the spot, not letting you off easy so you can have a beer early.
If you want to pass a vector, you will be required to call with_padding(Padding) to pad the "missing space" of the bytes vector provided. This check once again check the user’s understanding of what he’s doing. Check out the following example.

let num = UInt256Builder::new()
    .with_padding(Padding::Left(0x00))
    .with_endian(Endian::Big)
    .from_partial_bytes(vec![0xcd, 0xef])
    .build();

This code is equivalent to passing the following raw bytes array to build a UInt256:

let bytes = [
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xcd, 0xef,
];

However, it is really hard to miss what one is doing when they are required to call with_padding(Padding) .

Hopefully this is enough to whet your appetite in designing a more semantic API and tooling for your users. They will surely hate you first, but the tough love is going to pay off and your users will appreciate you more as they gain long-term productivity and something immensely more powerful — knowledge — without having to rewrite something from scratch.

What are Big and Little Endians?

Pan Chasinga — Thu, 07 Nov 2024 12:00:41 +0000

Are you familiar with Big and Little Endian, or have you heard about it somewhere along your programming journey but didn't pay much attention to it? In this short post, I will explain the concept in simple terms.

Endianness is the order in which bytes are stored and read in a computer's memory. It's a fundamental part of how computers understand and read bytes or any information input from the outside world.

When a computer needs to read data like this:

If the computer reads the string of digits in Big Endian, it reads the most significant digits first. This means, 6, 5, 6, 6, 6, and 9, in that order. Therefore, the computer represents the data as the string of digits 65669, translated as "sixty-five thousand six hundred sixty-nine" or whatever you, the user of computers, wish it to represent. For instance, if the computer is told to read the string into ASCII, you would get it to spell ABE for you.

character	decimal	binary
A	65	100 0001
B	66	100 0010
E	69	100 0101

On the other hand, a small endian computer read the least significant digits first, meaning 9, 6, 6, 6, 5, and 6. This is a different string of digits, 966656.

In reality, computers only read in bits and bytes (8 bits). For example, if we are to read the integer 330 into a computer program in Big endian, it would begin with the true bit representation of the integer:

integer	binary (in 2-byte word)
330	0000 0001 0100 1010

integer	MSB	LSB
330	0x01	0x4A

A Big-endian computer (or program) will read the most significant bytes first, which is 0x01 followed by 0x4a. So you end up getting the exact readable order of the bit string.

A small-endian one, on the other hand, will read the least significant bytes first, which is 0x4A then 0x01.

In order to retrieve the right data, we have to know if a computer reads in which endianness. That's because you can get different data from when it was read. (0x014A = 330 while 0x4A01 = 18945).

Here is a very simple test in Rust to prove it. We simply use the standard methods of a 16-bit (or 2-byte) unsigned integer type in Rust to read two-byte arrays which we intentionally swap the byte places.

fn test_both_endians() {
    let a = u16::from_be_bytes([0x01, 0x4a]);
    let b = u16::from_le_bytes([0x4a, 0x01]);
    assert!(a == b);
}

Endianness starts to become handy once you have to build a program that serializes and deserializes data. The concept is very simple. Let me know if you have any questions.

Getting Started with Goblins

Pan Chasinga — Wed, 31 May 2023 14:57:25 +0000

What is Goblins?

Goblins is a library for building distributed, peer-to-peer applications in Racket and Guile. It is a part of the Spritely ecosystem of ambitious projects attempting to fix the centralized internet.

Goblins adopts the principle of CapTP (Capability Transport Protocol) and OCAP (Object Capability). This guide aims to be a first practical introductory programming guide in Goblins for Racket programmers. Some experience programming in a Lisp dialect is useful, otherwise the general sections on OCAP and CapTP are still a good read.

What is Object Capability (OCAP)?

OCAP has been around for decades, but it hasn't been easy to find introductory resources on the internet. The most accessible one being Mark Miller's paper Capability Myths Demolished.

According to this Pony tutorial:

A capability is an unforgeable token that (a) designates an object and (b) gives the program the authority to perform a specific set of actions on that object.

The unforgeable token is, at the language level, just a reference to an object. In Object Capabilty's speak, "if you don't have it, you can't do anything with it".

The core idea of it is that programs are built with Principle of Least Authority (POLA), instead of starting out with the complete opposite (maximum authority). But before we get ahead of ourselves, let's step back to talk about how programs behave today.

When a user runs a program on the computer, that program is likely being run with that user's privilege level. That means aside from doing what it's supposed to do (like displaying a game window and interacting with I/O device for a game app), it can potentially do much more--whether it's reading and writing to local files, connecting to the network, and etc.--All under the radar of the unsuspecting user.

This generic authority to do many things implicitly is known as ambient authority, and it comes with today's operating systems' access control list (ACL).

In object capability, every entity that attempts to create some side effect to interact with the world needs access to specific objects in order to do so. To give an example in a fictional programming language; To manipulate a window, a scaleWindow(window: Window) procedure needs to be passed a Window object. To access a file on a file system, a readFile(file: File) procedure needs a File object handed to it. This way, one can be certain that a program won't be capable of doing anything other than what it is requested to do.

What is Capability Transport Protocol (CapTP)?

Similar to OCAP, it is quite difficult to find a gentle introduction to CapTP out there. CapTP takes the cue from OCAP and applies it to security of distributed, possibly networked systems. In CapTP, objects known as actors live in event loops known as vats. There can be one or more vats running on a machine's OS process, vats running on a machine's different processes or different machines entirely.

Actors that live in the same vat are said to be near one another, while those that live in different vats are said to be far from one another. Nearby actors can communicate with one another by synchronously call each other (or immediate call), while faraway actors have to communicate asynchronously with one another through message-sending (or eventual send) and promise-resolving, as you will see in the next examples. In common scenarios, the network boundaries are abstracted away so that the programmers won't have to worry about them. For example, objects living in two different vats on the same machine and in two different vats on two different networked machines should appear analogous to the programmer.

Quick Setup

Before anything else, make sure you have DrRacket installed and the IDE opened. You will need to install Goblins by going to File > Package Manager and type "goblins" in the Package Source box and hit enter to install the library.

Immediately Calling an Object in a Vat

In this first example, we will be creating a car object that knows its location with a 'where method and is able to move to different ones with a 'move-to method. The object will be bootstrapped to live in a vat using an a-run procedure. This way, it is simple to experiment on DrRacket's interactive prompt without having to run full vat programs.

Paste the following code in the DrRacket editor, then hit run:

#lang racket
(require goblins)
(require goblins/actor-lib/bootstrap)

;; Define a vat constructor.
(define a-vat 
  (make-vat))

;; Define a vat runner.
(define-vat-run a-run
  a-vat)

;; Define a car object constructor.
(define (^car bcom [x 0] [y 0])
  (lambda (msg [next-x 0] [next-y 0])
    (cond
      [(eq? msg 'where) (cons x y)]
      [(eq? msg 'move-to) (bcom (^car bcom next-x next-y))])))

Let's take a closer look at the ^car factory procedure (The ^ is called the hard hat symbol; A naming convention for object factories). Without fuzzing too much over bcom ("become"), let's just think of it as a wrapper that creates the next version of the object. As you'll see, when creating an object with ^car, the caller won't have to supply bcom with a value.

The outer ^car procedure is called to spawn or create an object (Note the optionalx and y arguments for the car's location which both default to 0). The procedure returns an anonymous procedure, which takes a symbol message and two optional arguments next-x and next-y. The message acts as a method or instruction within the cond block. Currently, it accepts two messages 'where and 'move-to. The 'where message returns a pair of current x and y coordinate of the car, and 'move-to, along with next-x and next-y arguments, transition the car's location to a new state.

In the interactive prompt, try creating a car object and calling it with messages like this:

;; Create a new car object and assign to `my-car`.
> (define my-car 
    (a-run (spawn ^car))

;; Call the object with 'where symbol.
;; `$` stands for immediate call.
> (a-run ($ my-car 'where))
;; Returns a pair '(0 . 0)

;; Call with 'move-to symbol and a new coordinate.
> (a-run ($ my-car 'move-to 20 30))

;; Calling with 'where again to check the updated location.
> (a-run ($ my-car 'where))
;; '(20 . 30)

;; Move to a different coordinate.
> (a-run ($ my-car 'move-to 3 5))

;; Check the new location.
> (a-run ($ my-car 'where))
;; '(3 . 5)

Note the a-run procedure that was required to "simulate" a running vat in the prompt.

Another way to define the car factory is through a method macro, which is a syntactic sugar to make it more familiar to OOP programmers. The objects created are analogous to the previous ones and can be called in a similar fashion.

;; Import the methods macro.
(require goblins/actor-lib/methods)


(define (^car bcom [x 0] [y 0])
  (methods
    [(where)
      (cons x y)]
    [(move-to next-x next-y)
      (bcom (^car bcom next-x next-y))]))

Eventual Send and Handling Promises in Many Vats

In the case that two object lives in different vats or even on different machines, we invoke them using the eventual send <- procedure instead of immediate call $ procedure.

When we eventually send a message, the program returns a promise immediately without blocking. Then, we call the on procedure with the returned promise and a callback. This shouldn't be a surprise if you have programmed in JavaScript before.

#lang racket
(require goblins)
(require goblins/actor-lib/bootstrap)

;; Define a vat constructor.
(define a-vat 
  (make-vat))

;; Define a vat runner.
(define-vat-run a-run
  a-vat)

;; Define another vat runner.
(define b-vat
  (make-vat))

(define-vat-run b-run
  b-vat)

;; Define a receiver constructor.
;; A receiver either receive a 'ping or 'pong message 
;; from a sender and respond with a contrary message.
(define (^receiver bcom name)
  (lambda (msg)
    (cond
      [(eq? msg 'ping) (format "pong from ~a" name)]
      [(eq? msg 'pong) (format "ping from ~a" name)]
      [else (format "~a doesn't understand you" name)])))

;; Define a sender constructor.
;; A sender take a receiver and message as arguments, then 
;; just immediately call the receiver object with that message.
(define (^sender bcom name)
  (lambda (recipient msg)
    ($ recipient msg)))

Now let's run the new code and return to the interpreter to experiment.

;; Define alice in a-vat.
> (define alice
    (a-run (spawn ^receiver "Alice")))

;; Define bob in b-vat.
> (define bob
    (b-run (spawn ^sender "Bob")))

;; Now Bob wants to send a 'ping message to Alice.
;; Bob being in the b-vat, we call `b-run` to bootstrap the vat.
> (b-run ($ bob alice 'ping))

;; not-callable: Not in the same vat: #<local-object ^receiver>

We got a not-callable: Not in the same vat error because inside the definition of ^sender it immediately calls the recipient with the $ but the recipient is an object that lives in a different vat (a-vat). Recall that objects living in different vats cannot immediately call one another. To prove the point, let's try to immediately call alice from b-vat:

> (b-run ($ alice 'ping))

;; not-callable: Not in the same vat: #<local-object ^receiver>

To fix this, we have to change to eventual send with <-. This call is non-blocking and returns a promise to the caller. Let's try invoking alice directly from b-vat again, but this time with <-:

> (b-run (<- alice 'ping))

;; #<local-promise>

You get a promise in return! From our b-vat land, we can handle a promise with the on procedure, which takes a promise and a callback as arguments. Here is a callback that only prints out the respond from alice:

> (define my-promise
    (b-run (<- alice 'ping)))

> (b-run (on my-promise
             (lambda (respond)
               (displayln respond))))

;; Prints "pong from Alice"

So to fix this just replace the sender definition with the following so a sender in one vat can "remotely" call (send) a receiver in another vat:

(define (^sender bcom name)
  (lambda (recipient msg)
    (<- recipient msg)))

Conclusion

We have learned what OCAP and CapTP are and get our hands dirty coding with Goblins and learning immediate object calls in a single vat and sending messages between objects in different vats. Somehow, we have baredly scratched the surface.

Currently Goblins is in rapid development and there will be changes along the way. Check out the repo for project updates.

Grokking Partial Application

Pan Chasinga — Thu, 02 Jun 2022 23:03:10 +0000

If you started programming in an imperative language such as Java like I did, learning to grok functional programming can be a daunting endeavor.

What partial application, or known by some as "currying" after the late mathematician Haskell Curry, is applying a function to a value, which returns another function yet to be applied to another value.

Look at the following function in JavaScript:

const add = (a) => (b) => x + y

As you first apply this function to the first number 9, it replaces a and returns the function (b) => 9 + b:

const addNine = add(9)
// -> (9) => (b) => 9 + n2
// -> (b) => 9 + n2

We end up with a half-applied function addNine that, when applied to another number, will add it to number 9 which is being stored on the stack. In another word, the computation was being suspended until the next application.

This is indeed different from the following function:

const add = (a, b) => a + b

If we partially applied this function to a single value 5,a would be substituted with a number while b will be undefined, resulting in an execution of 5 + undefined which equals to NaN, a very obscure result to ever be returned by a language.

Functions in functional languages such as Ocaml and Haskell are curried, which means they apply to each value at a time no matter how many parameters they have. Take these two Haskell functions, which are similar:

add1 :: Int -> Int -> Int
add1 a b = a + b

add2 :: Int -> Int -> Int
add2 a = \b -> a + b

The line above each function's definition is the function's type declaration. They show that both functions are in fact the same—a two-step application process to the end value.

Build a Decentralized App on IPFS using WebAssembly

Pan Chasinga — Fri, 04 Feb 2022 15:58:47 +0000

Gimme Proof by Picklehart Liverthief

In this fun and short tutorial, I'll show you how easy it is to build a fast front-end web app entirely in Rust, compile it to WebAssembly, and host it on the decentralized IPFS network. Yes, this is a Tutorial-to-learn-on-the-weekend-and-boast-to-your-DevOps-on-Monday you don't want to miss.

O, Wasm Fun!

You may have heard in passing of WebAssembly. You may have thought it sounded pretty cool, but like other gazillion other techs of recent, it was cutting-edge and not ready for primetime.

Well, now the time has passed, and although it might have not reached v1 yet, because many have been hacking on and building useful things with it, tooling has matured quickly. Now, it is very easy to start writing a web app entirely in Rust!

For the unadulterated minds, Wasm is a new binary instruction format that lets your program run on the browser at native speed. You might not know it, but as you're reading this, your browser is hustling millions of lines of JavaScript code in real-time, occasionally hanging to clean up values that aren't being used. The fact that this website runs smoothly is due to hours of sweat and tear from developers on both the browser and the app you are using.

One of the browser developers we interviewed

Wasm is not specific to Rust. There are currently libraries in many languages that help compile native code to Wasm. However, Rust by far has the most matured tooling and ecosystem. Some benefits in writing Wasm apps in Rust are:

Rust is similar to TypeScript, but with a more robust type system and ownership tracking that enables developers to create fewer runtime errors typical to JavaScript and TypeScript.
Rust has a good balance between low-level control and high-level developer ergonomics.
Rust does not have a runtime, making .wasm files small and downloading faster over the network.

💡 Fun experiment
Try an under-developed, under-funded website, like paying for your utility bill on your municipal's web app or updating your benefits on your HR department's internal app. Record your observations.

Ok, but why IPFS?

Because we think Jeff Bezos has enough of our money to launch himself to space, and it is time to help host a better, less monopolistic internet. And what's a better way to start contributing to the cause than hosting our web app on each other's computers!

IPFS, which stands for solar-system-dominating Interplanetary File System, is a vast, global network of computers helping one another store and serve files. Sounds familiar? It's kind of like BitTorrent, except with much cooler and interoperable ways to link data and objects (which we will touch on later).

IPFS and Wasm app are a perfect match because IPFS is decentralized, meaning it is more likely to cache and serve content on the "edge" nearer to the users while the Wasm app makes it even faster for the browser to load.

Convinced? Let's begin

Here are a few things to get you set up for success:

Install Rust
Follow the Yew's Project Setup
Open up your mind

To sanity-check before we wander off climbing El Capitan without a rope, run the follow commands in your terminal:

cargo --version
> cargo 1.56.0 (4ed5d137b 2021-10-04)

rustup target list | grep 'wasm32-unknown-unknown'
> wasm32-unknown-unknown (installed)

trunk --version
> trunk 0.14.0

Your displayed versions will likely differ from here, but as long as none of the command makes the shell says "command not found" you should be good to join this quest.

Now, when you're ready, create a new app by typing cargo new --bin counter-app into your terminal, and check out the directory with cd counter-app.

From now on, when I say "root", it will mean inside this tada-app directory.

At the root (I said it), run cargo run. Without fail, the sample app Rust created for you should print out "hello, world".

Open up the Cargo.toml file, and add Yew crate as a dependency under the dependencies section:

[package]
name = "counter-app"
version = "0.1.0"
edition = "2021"

[dependencies]
# Add this line
yew = "0.19"

Then run cargo update to install the crate.

Create an index.html file with the following HTML content and save the file:

<!DOCTYPE html>
<html>
<head>
  <!-- UIkit CSS -->
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/uikit@3.10.1/dist/css/uikit.min.css" />
  <!-- UIkit JS -->
  <script src="https://cdn.jsdelivr.net/npm/uikit@3.10.1/dist/js/uikit.min.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/uikit@3.10.1/dist/js/uikit-icons.min.js"></script>
  <meta charset="utf-8" />
  <title>Counter App</title>
</head>
</html>

This HTML file is the base document of our app.

Get familiar with Yew

Yew is a library that glosses over all the nitty-gritty of building Rust into Wasm. If you have done some building in React, Vue, Angular, or Elm, and especially if you have with TypeScript, you will be up and running at full speed.
Otherwise, back off on that gas a bit.

Open up src/main.rs, which is an entry point for all Rust app, and let's start with a counter app that consists of a button to increment a number value.

/// Import all goodies from Yew.
use yew::prelude::*;

/// Our app's state. It is now just a unit struct with no property
/// because our state will be encapsulated within the Counter component.
struct App;

/// A Counter functional component ala React.
#[function_component(Counter)]
fn counter() -> Html {

    // Initializing the component's state.
    let counter = use_state(|| 0);

    // The onclick callback function.
    let onclick = {
        let counter = counter.clone();
        Callback::from(move |_| counter.set(*counter + 1))
    };

    // The component written in plain-old HTML, thanks to html! macro.
    html! {
        <div class="uk-position-center uk-text-center">
            <button 
                {onclick}
                class="uk-button uk-button-primary uk-button-large"
            >
                { "+1" }
            </button>
            <p>{ *counter }</p>
        </div>
    }
}

/// The main App container.
impl Component for App {

    // The internal types that are required to be implemented to comply Component trait.
    type Message = ();
    type Properties = ();

    // The constructor function, which instantiates the App.
    fn create(_ctx: &Context<Self>) -> Self {
        App
    }

    // The view lifecycle function, which renders the App.
    fn view(&self, _ctx: &Context<Self>) -> Html {
        html! {
            <Counter />
        }
    }
}

/// Start the Yew app
fn main() {
    yew::start_app::<App>();
}

I hope you can guess a lot from just reading the code. If you are new to Rust, some things might have stuck out, like the #[...] just above the Counter component function and html! { ... } surrounding the HTML code. They are macros, the magic dragons that keeps Rust code simple and boiler-plate free.

Note that we could even include a class attribute to the button element to style our button with our CSS styling library. Neat!

Now, for the moment of truth, run trunk serve and watch in awe as the super speedy web app unwinds on port 8080 (or whatever port it listens on).

Fun with buttons

Now that we had our morale boosted, it is a good time to learn about props and states. Let's add two more buttons - one for decrementing the number and another for resetting it to 0.

First of all, let's change our App component into a functional component, instead of a struct. Replace the App struct and its lifecycle methods (everything within impl App block) with the following functional component:

#[function_component(App)]
fn app() -> Html {
    let _state = use_state(|| 0 as u64);
    html! { 
        <Counter />
    }
}

One thing that React did well was to promote functional over class-based components. Functional components are stateless and easier to understand, and Yew carries on with that convention.

We are using use_state hook, which behaves similarly to the one in React. Instead of providing 0 as the initial state, we pass an anonymous function (or as Rust calls a closure) with a value of 0. Because Rust infers 0 as a 32-bit integer (i32) type by default, we have to coerce it to a 64-bit unsigned integer type by using the keyword as.

We need to communicate with the DOM inside the Counter component since all the buttons are wrapped in there. This is where we pass props in. Our props will only contain the state because we just want the child components to change it from inside Counter.

On top of counter function, define a TodoProps struct with a state field:

#[derive(Properties, PartialEq)]
struct TodoProps {
    state: UseStateHandle<u64>,
}

Note the macro clause #[derive(...)] before the struct definition. It implements Properties and PartialEq traits, generating necessary implementation at compile time. All props are required to implement these two traits.

Now, add the props as a parameter to counter.

#[function_component(Counter)]
fn counter(props: &TodoProps) -> Html {
    // ...
}

And now, miraculously, Counter now accepts a props name state:

#[function_component(App)]
fn app() -> Html {
    let state = use_state(|| 0 as u64);

    html! {
        <Counter {state} />
    }
}

Let's head back to counter function. We want to increment the state when a button is pressed. Let's define an increment callback to do that.

#[function_component(Counter)]
fn counter(props: &TodoProps) -> Html {
    let increment = {
        let state = props.state.clone();
        Callback::from(move |_| state.set(*state + 1))
    }
    html! {
        <div class="uk-position-center uk-text-center">
        <button 
          onclick={increment}
          class="uk-button uk-button-primary uk-button-large"
        >
          { "+1" }
        </button>
        <p>{ *props.state }</p>
        </div>
    }
}

With these changes, if you run trunk serve now, you should see a button incrementing the number like before. In fact, saving the changes should reload the app in the browser automatically!

All we have to do now is to repeat, add decrement and reset callbacks, and two more buttons that take them as callbacks. Here is the complete code with three buttons:

use yew::prelude::*;


#[derive(Properties, PartialEq)]
struct TodoProps {
    state: UseStateHandle<u64>,
}

#[function_component(Counter)]
fn counter(props: &TodoProps) -> Html {
    let increment = {
        let state = props.state.clone();
        Callback::from(move |_| state.set(*state + 1))
    };

    let decrement = {
        let state = props.state.clone();
        Callback::from(move |_| state.set(*state - 1))
    };

    let reset = {
        let state = props.state.clone();
        Callback::from(move |_| state.set(0))
    };

    html! {
        <div class="uk-position-center uk-text-center">
            <button
                onclick={increment}
                class="uk-button uk-button-primary uk-button-large"
            >
                { "+1" }
            </button>
            <button
                onclick={reset}
                class="uk-button uk-button-primary uk-button-large"
            >
                { "0" }
            </button>
            <button
                onclick={decrement}
                class="uk-button uk-button-primary uk-button-large"
            >
                { "-1" }
        </button>
            <p>{ *props.state }</p>
        </div>
    }
}

#[function_component(App)]
fn app() -> Html {
    let state = use_state(|| 0 as u64);
    html! {
        <Counter {state} />
    }
}

fn main() {
    yew::start_app::<App>();
}

The latest counter app should look like this:

Before we wrap up app building, peek into the dist. You will likely find a .js, .wasm, and a .html files. Trunk had built and compiled the app into a bundle of files in this directory, ready to be served with any HTTP server.

💡 Fun experiment
If you have Python installed, try running HTTP server within dist with the command python3 -m http.server 8080 or python -m SimpleHTTPServer 8080 for Python2. Alternatively, Node http-server works too.
What are your observations? Epiphanies? Record them.

Deploy to IPFS

IPFS network consists of many nodes running IPFS, coordinating with each other to help store and distribute digital content over the internet. At a high level, the only different you need to know is that IPFS is:

Content-addressed
Unlike the world wide web today, which mostly serve content at a location address like https://coolapp.com/public/cat1.jpg, IPFS identify a piece (or pieces) of content based on its hash, or Content Identifier (CID). It does not matter where the file (or bits of it) is located on the internet. IPFS will retrieve that file based on the hash you provide. For example, on IPFS-compatible browsers like Brave or Puma, check out NFTSchool website on IPFS with ipfs://bafybeicsyilnu4rxrjlerad5kzstvgio3n62qlxektwqudj4x53vaexxiu.
Immutable
Because you retrieve content on IPFS by its digital fingerprint, contents on the network are unchangeable. There is no way to save a puppy JPEG at https://coolapp.com/public/cat1.jpg to troll with cat lovers or even remove the image and leave them with a 404 Cat Not Found.

The trickiest part of hosting content on IPFS is its "garbage-collecting" nature. To avoid congesting the storage, unused contents are pruned from the hard disk(s) of the storage node(s). To keep a piece of content online and available, we must pin it to the persistent storage.

Run IPFS locally

We will deploy and serve our Wasm counter app on a local IPFS node running on our machine. Download the IPFS Desktop node, which gives you a nice UI on top of the IPFS server.

Open IPFS Desktop app, navigate to the File tab, and drag the dist folder from our project into the app window. Once it's loaded, you should see the directory appears in the app:

Click on the ellipsis icon to the right of the item (the three-dotted icon), click Share Link, then click Copy. Paste the URL in a browser, then you should be able to see your counter app!

💡 Fun experiment
Try pinning the app by clicking Set Pin from the same menu. Read up quickly on pinning, then come back here a changed person.

IPFS Gateway

You might have noticed that the link you got starts with HTTPS protocol, like https://ipfs.io/ipfs/QmNtFreJ5pn6dH1xeNYYdqmYnWuWgLn5akijeFxrE5giad. Because IPFS is not supported in some browsers, there are several HTTP gateway that acts as a safe passage into the IPFS-hosted content via HTTP. This link connects to a gateway provided by ipfs.io.

In browsers like Brave or Puma, users will be able to browse using IPFS natively with ipfs://QmNtFreJ5pn6dH1xeNYYdqmYnWuWgLn5akijeFxrE5giad. We can think of these browsers as the direct gateways to IPFS without a "web2" middleman sitting in the middle.

Pinning services

Running the IPFS node locally and serving the app on your own is a fun exercise, but if you shut down your computer, your node and your app will likely go down. The fastest way to get up and running is to upload your app to a pinning service such as Estuary, Web3.storage, or deploy directly to Fleek.

Immutability's crux

If you have been thinking it through, you would have realized what a headache it would be to update our app. If you just removed a single line or a print statement from your app and re-deployed, you will end up with a completely different CID. That's why the current internet is based on mutable addresses - So users can always find their way back regardless of the content.

Check out Interplanetary Name System (IPNS) and DNSLink on how to link a static CID and domain name to your IPFS app.

Building an NFT Store on Flow: Part 2

Pan Chasinga — Mon, 31 Jan 2022 19:42:54 +0000

This is a sequel of the two-part tutorial. If you have not, check out part 1 and work your way back here!

In this second part of the tutorial, we will work on building the UI with React.js and Flow's fcl.js library to interact with the on-chain smart contract we deployed in the first part.

Because learning React is unfortunately out of the scope, if you need a quick introduction or brush-up on React, head over to Intro to React.

Very often, especially for decentralized applications whose back-ends rely heavily on blockchains and other decentralized technology, the user experience is what makes or breaks them. Quite often, the user-facing part is the only crucial part in a dapp.

In this section, we will be working on the UI for the pet store app in React.js. While you're expected to have some familiarity with the library, I will do my best to use common features instead of advanced ones.

After we are done, we will have built a simple marketplace app on the local blockchain that users can mint and query their NFTs, which looks like this:

Setting up

Make sure you are in the project directory (next to package.json). Install the following packages:

npm install —save @onflow/fcl @onflow/types nft.storage

The Flow packages will help in connecting our React app to the Cadence code. The nft.storage package will help in uploading the image during minting and retrieving data from Filecoin/IPFS network. In order to do so, you will need to sign up and generate an API key. After you have signed up, navigate to the "API Keys" tab, and click to create a new key, as shown here:

Copy and save the key as we will need it later on when we work on the minting logic.

To get styling out of the way, let's download Skeleton CSS, unzip all the CSS files into the src directory, and import all the .css files in the App.css main stylesheet in the project:

/* App.css */

@import "./skeleton.css";
@import "./normalize.css";

/* import all other CSS files if there are any */

Now, run the app with npm run start, the React app should open in the browser on http://localhost:3000. Keep the browser open to see the updates as you save your code progress.

Let's make the app our own by removing the template from React. In your editor, open App.js and remove all the current HTML, leaving only the <div className="App"> DOM tags.

function App() {
  return (
    <div className="App">

        {/* DOM code removed */}

    </div>
  );
}

After you saved the file, the app in the browser should reload and appear empty.

Now, create a new directory named components inside src to keep our reusable components with mkdir -p src/components.

Inside the newly created components directory, create a new file named Form.js and add the following code below. This component will be with which users can submit and mint new NFTs.

// components/Form.js

// Import the `FileSelector` module, which does not exist yet. 
import FileSelector from './FileSelector';

// Collect the information of a pet and manage as a state
// and mint the NFT based on the information.
const Form = () => {
  const [pet, setPet] = useState({});

  // Helper callback functions to be passed to input elements' onChange.

  // Update the state of the pet's name.
  const setName = (event) => {
    const name = event.target.value;
    setPet({...pet, name});
  }

  // Update the state of the pet's breed.
  const setBreed = (event) => {
    const breed = event.target.value;
    setPet({...pet, breed});
  }

  // Update the state of the pet's age.
  const setAge = (event) => {
    const age = event.target.value;
    setPet({...pet, age});
  }

  return (
    <div style={style}>
      <form>
        <div className="row">
            <FileSelector pet={pet} setPet={setPet} />
            <div>
            <label for="nameInput">Pet's name</label>
            <input
              className="u-full-width"
              type="text"
              placeholder="Max"
              id="nameInput"
              onChange={setName}
            />
            </div>
            <div>
            <label for="breedInput">Breed</label>
            <select className="u-full-width" id="breedInput" onChange={setBreed}>
              <option value="Labrador">Labrador</option>
              <option value="Bulldog">Bulldog</option>
              <option value="Poodle">Poodle</option>
            </select>
            </div>
            <div>
            <label for="ageInput">Age</label>
              <select
                className="u-full-width"
                id="ageInput"
                onChange={setAge}
              >
                {
                  [...Array(10).keys()].map(i => <option value={i}>{i}</option>)
                }
              </select>
            </div>
          </div>
        <input className="button-primary" type="submit" value="Mint" />
      </form>
    </div>
  );
};

const style = {
  padding: '5rem',
  background: 'white',
  maxWidth: 350,
};

export default Form;

We will get an error since the FileSelector.js component we imported in the code does not yet exist. So, create the FileSelector.js file next to Form.js to handle the image uploading.

// components/FileSelector.js

import { useState } from 'react';

// We are passing `pet` and `setPet` as props to `FileSelector` so we can
// set the file we selected to the pet state on the `Form` outer scope
// and keep this component stateless.
const FileSelector = ({pet, setPet}) => {

  // Read the FileList from the file input component, then
  // set the first File object to the pet state.
  const readFiles = (event) => {
    const files = event.target.files;
    if (files.length > 0) {
      setPet({...pet, file: files[0]});
    }
  };

  return (
    <div className="">
      <label for="fileInput">Image</label>
      {/* Add readFiles as the onChange handler. */}
      <input type="file" onChange={readFiles} />
    </div>
  );
};

export default FileSelector;

If you import Form.js component into App.js and insert it anywhere inside the main App container, you should see your form that looks similar what you see here:

Minting

Here comes the most crucial step of all NFTs--Minting. Minting an NFT is officially creating it and establishing its existence and initial ownership on-chain, making the token "authentic". For this step, we will hook up the Mint button to actually mint a token based on user's input.

First, let's head over to /src/flow/transaction and create a new JavaScript file named MintToken.tx.js. This module acts as an interface between the Cadence code in MintToken.cdc instead of the Flow CLI we used previously in part 1.

Here I create a JavaScript module that interacts with each Cadence transaction or script and name it to reflect the Cadence code, appended by .tx.js or a transaction or .sc.js for a script. This is not a requirement and you're free to name them however you want.

Since there are quite a few things involved in the minting process, we are going to go through a bit slowly on this one. We will create a mintToken function that takes a pet object and does the following:

Upload to NFT.storage. This uploads the metadata and image asset to NFT.storage, and retrieves the returned metadata that includes the CID of the data.
Send a minting transaction with the metadata to Flow (in this case, the name, age, breed, and the CID of the data stored on IPFS).
Return the Flow transaction ID if successful.

First, let's sketch up some placeholder functions to outline the steps:

// MintToken.tx.js

async function mintToken(pet) {
  let metadata = await uploadToStorage(pet);
  let txId = await mintPet(metadata);
  return txId;
}

// We will fill in these functions next

async function uploadToStorage(pet) {
    return {};
}

async function mintPet(metadata) {
    return '';
}

1. Upload to NFT.Storage

Next, fill in the body of uploadToStorage function. You will need to replace the placeholder string with your API key from NFT.Storage. Note that in production, you will be reading this key as an environment variable for better security.

NFTStorage.store(...) takes an object with arbitrary attributes and two required attributes, image and description. (Contrary to its name, the image attribute does not require an image file. It takes a File object which can contain any type of asset.)

The description attribute can be any arbitrary text up to $MAXLENGTH.

Then, we return the metadata returned from the call to the caller.

// Import required modules from nft.storage
import { NFTStorage, File } from 'nft.storage';

const API_KEY = "DROP_YOUR_API_KEY_HERE";

// Initialize the NFTStorage client
const storage = new NFTStorage({ token: API_KEY });

async function uploadToStorage(pet) {
  // Call `store(...)` on the NFTStorage client with an object
  // containing all of pet's attributes, and required image and
  // description attributes.
  let metadata = await storage.store({
    ...pet,
    image: pet.image && new File([pet.image], `${pet.name}.jpg`, { type: 'image/jpg' }),
    description: `${pet.name}'s metadata`,
  });

  // If all goes well, return the metadata.
  return metadata;
}

2. Send a minting transaction

Once we have the metadata uploaded to NFT.storage, we will have to send a transaction to mint the token with the metadata. Let's fill in the mintPet function.

import * as fcl from '@onflow/fcl';
import * as t from '@onflow/types';
import cdc from './MintToken.cdc';

async function mintPet(metadata) {

  // Convert the metadata into a {String: String} type. See below.
  const dict = toCadenceDict(metadata);

  // Build a list of arguments
  const payload = fcl.args([
    fcl.arg(
      dict,
      t.Dictionary({ key: t.String, value: t.String }),
    )
  ]);

  // Fetch the Cadence raw code.
  const code = await (await fetch(cdc)).text();

  // Send the transaction!
  // Note the `userAuthz` function we have not implemented.
  const encoded = await fcl.send([
    fcl.transaction(code),
    fcl.payer(fcl.authz),
    fcl.proposer(fcl.authz),
    fcl.authorizations([fcl.authz]),
    fcl.limit(999),
    payload,
  ]);

  // Call `fcl.decode` to get the transaction ID.
  let txId = await fcl.decode(encoded);

  // This waits for the transaction to be sealed, which is a recommended way.
  await fcl.tx(txId).onceSealed();

  // Return the transaction ID
  return txId;
}

// Helper function to convert `pet` object to a {String: String} type.
function toCadenceDict(pet) {
  // Copy the pet object so we don't mutate the original.
  let newPet = {...pet};

  // Delete the `image` attribute that contains a `File` object.
  delete newPet.image;

  // Return an array of [{key: string, value: string}].
  return Object.keys(newPet).map((k) => ({key: k, value: pet[k]}));
}

As you can see, our mintPet function is a little involved.

The first step we took was to convert the pet data to a type our Cadence contract understands, which a dictionary of type {String: String}. Basically, if the object looks like this:

{
    name: "Max",
    age: 3,
    breed: "Bulldog",
    // ...
}

We then have to convert it to an array of {key: string, value: string} in JavaScript:

[
    {key: "name", value: "Max"},
    {key: "age", value: "3"},
    {key: "breed", value: "Bulldog"},
]

This was what toCadenceDict function did, plus deleting the image attribute from the pet object because we didn't need it for minting on Flow.

After properly converting the object, we had to build a payload by calling fcl.args and pass an array of arguments. In this case, the metadata of type [{key: string, value: string}]. To facilitate this, we used types from fcl.types library.

Next, we fetch the corresponding MintToken.cdc code as a raw string. This is a standard way of fetching raw text from another module.

Now comes the meaty part of this function: Sending a transaction.

const encoded = await fcl.send([
  fcl.transaction(code),
  fcl.payer(fcl.authz),
  fcl.proposer(fcl.authz),
  fcl.authorizations([fcl.authz]),
  fcl.limit(999),
  payload,
]);

There are a few FCL functions to send a transaction, but fcl.send([...]) is the most straightforward one.

We pass the Cadence code to fcl.transaction, and any integer from 0 - 999 to fcl.limit for the gas fee limit we are happy with. The payload is the metadata we converted previously.

The payer, proposer, and authorizations accept a function known as authorization function, which decides the account (and effectively the keys) used to authorize the transaction. (If you're interested in deep-diving into this, check out Authorization Function). Here, fcl provided an authz default authorization function to makes signing with the emulator account easier.

3. Return the transaction ID

Now all that is left to do is to return to the main mintToken function with a transaction ID:

// This is a fallible function.
async function mintToken(pet) {

  // The metadata contains the attribute `url` which is an IFPS URL
  // pointing to the data.json.
  const { url } = await uploadToStorage(pet);

  // We want to include the IPFS URL to the blockchain, so we can
  // "unpack" the token data when we query it later. So we create
  // a new object with all of the pet's attributes plus `url`.
  const txId = await mintPet({ ...pet, url });
  return txId;
}

// Don't forget to export the function.
export default mintToken;

Our mintToken function is now ready. Let's return to Form.js, add a handleSubmit handler (right after setAge function), and pass to the onSubmit prop on the <form> element.

// Form.js

// On the top most of the module
import mintToken from '../flow/transaction/MintToken.tx';

const Form = () => {

  // ... setAge function ...

  const handleSubmit = async (event) => {
    event.preventDefault();
    try {
      await mintToken(pet);
    } catch (err) {
      console.error(err);
    }
  }

  return (
    <div style={style}>
      <form onSubmit={handleSubmit}>

        {/* ... other elements ... */}

      </form>
    </div>
  );

This wraps up token minting. Now you can test the UI, select an image file, fill up the metadata on the form, and click the mint button to mint NFTs on the local net.

Now is the time to fill up your coffee and take a well-deserved break before we move on to the last bit of the tutorial--Querying tokens' data.

Querying the token

Now that we can mint our pet tokens, let's build another form UI to query them for metadata and image.

We are going to reuse the minting form. Once we're done, it will look similar to this:

I know Mary is obviously not a Bulldog, but you will get a chance to add your breed options later.

Let's start by creating QueryToken.jsx file inside the /components directory.

import { useState, useEffect } from 'react';

// QueryForm.jsx

const style = {
  padding: '1rem',
  paddingTop: '5rem',
  background: 'white',
  maxWidth: 350,
  margin: 'auto',
};

const QueryForm = () => {
  const [selectedId, setSelectedId] = useState(null);
  const [metadata, setMetadata] = useState(null);
  const [allTokenIds, setAllTokenIds]  = useState([]);

  useEffect(() => {
    let getTokens = async () => {
      // Set mock IDs for now
      setTokenIds([1, 2, 3]);
    };
    getTokens();
  }, []);

  // Empty handler for now...
  const handleSubmit = async (event) => {
    event.preventDefault();
  }

  return (
    <div style={style}>
      <form onSubmit={handleSubmit}>
        <div className="row">
          <div className="">
            <label htmlFor="idInput">Pet's ID</label>
            <select
              className="u-full-width"
              type="number"
              id="idInput"
              onChange={(event) => setId(parseInt(event.target.value))}
            >
              {
                // We want to display token IDs that are available.
                allTokenIds.map(i => <option value={i}>{i}</option>)
              }
            </select>
          </div>
        </div>
        <input className="button-primary" type="submit" value="Query" />
      </form>
      {
        // We only display the table if there's metadata.
        metadata ? <MetadataTable metadata={metadata} /> : null
      }
    </div>
  );
};

const MetadataTable = ({ metadata }) => (
  <table className="u-full-width">
    <thead>
      <tr>
        {
          Object.keys(metadata).map((field,i) => (
            // Skip the `url` attribute in metadata for the table headings.
            field === 'url' ? null : <th key={i}>{field}</th>
          ))
        }
      </tr>
    </thead>
    <tbody>
      <tr>
        {
          Object.keys(metadata).map((field, i) => {
            switch (field) {
              // Skip displaying the url.
              case 'url':
                return null;
              // Display the image as <img> tag.
              case 'image':
                return (
                  <td key={i}>
                    <img src={metadata[field]} width="60px" />
                  </td>
                );
              // Default is to display data as text.
              default:
                return <td key={i}>{metadata[field]}</td>;
            }
          })
        }
      </tr>
    </tbody>
  </table>
);

export default QueryForm;

As usual, we need to create JavaScript "bindings" to two Cadence scripts GetTokenMetadata.cdc and GetAllTokenIds.cdc. We will start with GetAllTokenIds.sc.js.

// GetAllTokenIds.sc.js

import * as fcl from '@onflow/fcl';
import raw from './GetAllTokenIds.cdc';

async function getAllTokenIds() {

  // Fetch the `GetAllTokenIds.cdc` script as text.
  let cdc = await(await fetch(raw)).text();

  // Read the script, send it, and wait for the response.
  const encoded = await fcl.send([fcl.script(cdc)]);

  // Decode the response into a JavaScript array of IDs.
  const tokenIds = await fcl.decode(encoded);

  // Sort the IDs in ascending order and return the array.
  return tokenIds.sort((a, b) => a - b);
}

export default getAllTokenIds;

Hopefully, by now you are already an expert. It's worth switching back and taking a look at GetAllTokenIds.cdc to see how the Javascript bindings and Cadence scripts interact.

Next up, we create GetTokenMetadata.sc.js to execute the GetTokenMetadata.cdc script.

// GetTokenMetadata.sc.js

import * as fcl from '@onflow/fcl';
import * as t from '@onflow/types';
import raw from './GetTokenMetadata.cdc';

async function getTokenMetadata(id) {
    let script = await(await fetch(raw)).text();
    const encoded = await fcl.send([
        fcl.script(script),
        fcl.args([fcl.arg(id, t.UInt64)]),
    ]);
    const data = await fcl.decode(encoded);
    return data;
}

export default getTokenMetadata;

Again, you can review GetTokenMetadata.cdc to see the relationships between the interfaces offered and how we used them in this function.

Now we are ready to return to QueryForm.jsx. Import the functions we worked on:

// QueryForm.js

import { useState, useEffect } from 'react';

// Import these functions
import getAllTokenIds from '../flow/script/GetAllTokenIds.sc';
import getTokenMetadata from '../flow/script/GetTokenMetadata.sc';
import { toGatewayURL } from 'nft.storage';

const QueryForm = () => {
  const [allTokenIds, setAllTokenIds] = useState([]);
  const [selectedId, setSelectedId] = useState(null);
  const [metadata, setMetadata] = useState(null);

  useEffect(() => {
    let getTokens = async () => {
      // Instead of dummy token IDs, we call `getAllTokenIds`
      // to get real IDs of all existing tokens.
      const ids = await getAllTokenIds();
      setTokenIds(ids);
    };
    getTokens();
  }, []);

  const handleSubmit = async (event) => {
    event.preventDefault();

    // Add this block to the submit handler.
    try {
      // Call the `getTokenMetadata` function and extract the
      // IPFS URL from the data returned.
      let metadata = await getTokenMetadata(selectedId);
      let dataURL = toGatewayURL(metadata.url);

      // Fetch the URL to get a JSON response, which contains
      // an `image` attribute.
      // create a new metadata object and set the metadata to the value.
      let { image } = await (await fetch(dataURL)).json();
      let newdata = { ...metadata, image: toGatewayURL(image) };
      setMetadata(newdata);
    } catch(err) {
      window.alert('Token ID does not exist!');
    }
  }

  // ...The component code unchanged...
}

In the useEffect callback, we replaced the stubbed ID array with the call to
getAllTokenIds function, which executed GetAllTokenIds.cdc and returned an
array of existing token IDs. We then call setTokenIds to set allTokenIds to
the array. This is used to fill up the <option> element with the IDs and act as
the UI guard to make sure users can only choose the available tokens to query.

In the "empty" handleSubmit handler function, which is called each time the query button
is clicked, we added a try-catch block which called getTokenMetadata with the ID user
selected in selectedId, and return the metadata of the selected NFT.

Remember that as part of metadata in minting, we included the url attribute from the
NFT.storage upload. This url is an IPFS URL in the form of ipfs://<CID>/data.json.
We are interested in this URL because it points to the JSON data containing the URL to
the pet image we uploaded to IPFS. To fetch it using JavaScript, we had to convert the IPFS
URL to the HTTP gateway URL with toGatewayURL. Once we fetched the JSON and convert to an object, we access the
image attribute, convert it to HTTP URL, and include it along with other data in the new metadata
object we set the state with setMetadata. It is then ready for the MetadataTable component
to display.

Note that in the case of error, handleSubmit would call window.alert and display a simple popup
window to notify the user.

There was no change needed for the component code.

Now, try to mint an NFT with the mint form, and query it with the query form! Hopefully, it should all work as intended.

Congratulations! You have single-handedly built a NFT minting and querying marketplace on Flow. This has been a great achievement!

Next steps

Flow's focus on developer's experience and the accessibility of its smart contract language Cadence, plus its low gas fee and high throughput, make it an extremely promising blockchain to build NFT-related apps on.

Because NFTs have assets that need to be stored off-chain permanently, using NFT.Storage to store them on the Filecoin network is a natural way to go as the first step to launch your NFT app on Flow quickly.

If you are still hungry to learn more about Flow and NFT.Storage, here is a non-exhaustive list of the resources to tackle next:

Dive into the Cadence Language Reference.
Explore Flow Client Library, especially the authorization.
Familiarize with NFT.storage documentation.

Last but not least, if you would like to contribute to make this tutorial better, start by creating an issue on the repo or just leave your comment. No contribution is too small.

Building an NFT store on Flow : Part 1

Pan Chasinga — Tue, 28 Dec 2021 16:58:03 +0000

This tutorial will teach you how to create a simple NFT marketplace app on the Flow blockchain from scratch, using the Flow blockchain and IPFS/Filecoin storage via nft.storage. The finished project is a React app that lets you mint pet NFTs and query on-chain metadata and the photo of the pets:

The tutorial is broken into two parts:

NFT and blockchain basic, understanding Flow and Cadence, and interacting with the smart contract using the Flow command line tool.
Building a front-end React app and using the FCL library to interact with the smart contract.

This is the first part of the tutorial.

Who this is for

Although this tutorial is built for Flow blockchain, I am focusing on building up a general understanding of smart contracts and Non-fungible tokens (NFTs). If you have a working familiarity in JavaScript and React, but a passing familiarity with blockchains, you will be just fine catching up.

If you are very new to the concept of smart contracts and NFTs, it's worth checking out this quick guide on NFT School.

Set up

Before we begin, you will need to install a few things:

Node.js and npm (comes with Node.js)
Flow CLI
Docker and Docker Compose

You're free to use any code editor, but VSCode with Cadence Language support is a great option.

What you will learn

As we build a minimal version of the Flowwow NFT pet store, you will learn the basic NFT building blocks from the ground up, including:

Smart contracts with Cadence Language
User wallet authentication
Minting tokens and storing metadata on Filecoin/IPFS via NFT.storage
Transferring tokens

Understanding ownership and resource

A blockchain is a digital distributed ledger that tracks an ownership of some resource. There is nothing new about the ledger part—Your bank account is a ledger that keeps track of how much money you own and how much is spent (change of ownership) at any time. The key components to a ledger are:

Resource at play. In this case a currency.
Accounts to own the resource, or the access to it.
Contract or a ruleset to govern the economy.

Resource

A resource can be any thing — from currency, crop, to digital monster — as long as the type of resource is agreed upon commonly by all accounts.

Accounts

Each account owns a ledger of its own to keep track of the spending (transferring) and imbursing (receiving) of the resource.

Contract

A contract is a ruleset governing how the "game" is played. Accounts that break the ruleset may be punished in some way. Normally, it is a central authority like a bank who creates this contract for all accounts.

Because the conventional ledgers are owned and managed by a trusted authority like your bank, when you transfer the ownership of a few dollars (-$4.00) to buy a cup of coffee from Mr. Peet, the bank needs to be consistent and update the ledgers on both sides to reflect the ownership change (Peet has +$4.00 and you have -$4.00). Because both ledgers are not openly visible to both of Peet and you and the the currency is likely digital, there is no guarantee that the bank won't mistakenly or intentionally update either ledger with the incorrect value.

💡 Your bank probably owes you
If you have a saving account with some money in it, you might be loaning your money to your bank. You are trusting it to have your money for you when you want to withdraw. This is why if you had a billion dollars in your account and you want to withdraw today, your teller will freak out. Your money is just part of the stream of digital currency your bank is free to do anything with.

What is interesting about the blockchain is the distributed part. Because there is only a single, open decentralized ledger, there is no central authority (like a bank) for you to trust with bookkeeping. In fact, there is no need for you to trust anyone at all. You only need to trust the copy of the software run by other computers in the network to uphold the legitimacy of the book. Moreover, it is very hard for one (or more) of the computers to run an altered version of that software to bend the rule.

A good analogy is an umpire-less tennis game where any dispute (like determining if the ball lands in the court) is distributed to all the audience to judge. Meanwhile, these audience members are also participating in the game, with the stake that makes them lose if they judge wrongly. This way, any small inconsistencies are likely caught and rejected fair and square. You are no longer trusting your bank. The eternal flow of ownerships hence becomes trustless because everyone is doing what's best for themselves.

"Why such emphasis on ownership?" you may ask. This was leading to the concept of resource ownership baked right into the smart contract in Flow. Learning to visualize everything as resources will help in getting up to speed.

Quick tour of Cadence

Like Solidity language for Ethereum, Flow uses Cadence Language for smart contracts, transactions, and scripts. Inspired by the Rust and Move languages, the interpreter tracks when a resource is being moved from a variable to the next and makes sure it can never be mutually accessible in the program.

The three types of Cadence program you will be writing are contracts, transactions, and scripts.

Contract

A contract is an initial program that gets deployed to the blockchain, initiating the logic for your app and allowing access to resources you create and the capabilities that come with them.

Two of the most common constructs in a contract are resources and interfaces.

Resources

Resources are items stored in user accounts that are accessible
through access control measures defined in the contract. They are usually the assets being tracked or some capabilities, such as a capability to withdraw an asset from an account. They are akin to classes or structs in some languages. Resources can only be in one place at a time, and they are said to be moved rather than assigned.

Interfaces

Interfaces define the behaviors or capabilities of resources. They are akin to interfaces in some languages. They are usually implemented by other resources. Interfaces are also defined with the keyword resource.

Here is an example of an NFT resource and an Ownable interface (à la ERC721) in a separate PetShop contract:

pub contract PetShop {

    // A map recording owners of NFTs
    pub var owners: {UInt64 : Address}

    // A Transferrable interface declaring some methods or "capabilities"
    pub resource interface Transferrable {
      pub fun owner(): Address
      pub fun transferTo(recipient: Address)
    }

    // NFT resource implements Transferrable
    pub resource NFT: Transferrable {

        // Unique id for each NFT.
        pub let id: UInt64

        // Constructor method
        init(initId: UInt64) {
            self.id = initId
        }

        pub fun owner(): Address {
          return owners[self.id]!
        }

        pub fun transferTo(recipient: Address) {
          // Code to transfer this NFT resource to the recipient's address.
        }
    }
}

Note the access modifier pub before each definition. This declares public access for all user accounts. Writing a Cadence contract revolves around designing access control.

Transaction

Transactions tell the on-chain contract to change the state of the chain. Like Ethereum, the change is synchronized throughout the peers and become permanent. Because it takes computing power from many computers to do so, a transaction is considered a write operation that incurs a gas fee to be paid to the network. Transactions require one or more accounts to sign and authorize. For instance, minting and transferring tokens are transactions.

Here is an example of a transaction which requires a current account's signature to sign an action and mutate the chain's state. In this case, it is just logging "Hello, transaction", which would be a waste of resource.

transaction {

    // Takes the signing account as a single argument.
    prepare(acc: AuthAccount) {

        // This is where you write code that requires a 
        // signature, such as withdrawing a token from the 
        // signing account.
    }

    execute {
        // This is where you write code that does not require 
        // a signature.
        log("Hello, transaction")
    }
}

Script

Scripts are Cadence programs that are run on the client to read the state of the chain. Therefore, they do not incur any gas fee and do not need an account to sign them. A common use case is a blockchain explorer that queries the state of the chain.

Here is an example of a script reading an NFT's current owner's address by accessing the on-chain owners map by the token's ID:

// Takes a target token ID as a parameter and returns an 
// address of the current owner.
pub fun main(id: UInt64) : Address {
    return PetStore.owner[id]!
}

Nevermind if you don't understand the syntax. As long as you understand the overall steps and recognize the similarities to another language, you will be fine. We will talk more about Cadence's syntax later.

Both transactions and scripts are invoked on the client side, usually with the help of a command line tool or JavaScript library, both of which will be covered in this tutorial series.

Building pet store

Now that we had a glance at Cadence, the smart contract language, we are ready to start building some of the features for our NFT pet store.

We will create and prepare a project structure for our React app for the second part. Make sure you already have the tools(#set-up) installed.

Now, create a new React app by typing the following commands in your shell:

npx create-react-app petstore; cd petstore

And then, initialize a Flow project:

flow init

You should see a new React project created with a flow.json configuration file inside. This file is important as it tells the command line tool and the FCL library where to find things in the project. Let's take a closer look at the newly created directory and add some configurations to the project.

Project structure

First of all, note the flow.json file under the root directory. This configuration file was created when we typed the command flow init and tells Flow that this is a Flow project. We will leave most of the initial settings as they were, but make sure it contains these fields by adding or changing them accordingly:

{
    // ...

    "contracts": {
        "PetStore": "./src/flow/contracts/PetStore.cdc"
    },

    "deployments": {
    "emulator": {
      "emulator-account": ["PetStore"]
    }
  },

    // ...
}

These fields tell Flow where to look for the contract and the accounts related to the project so we will be able to run the command line to deploy it to the blockchain. Note that we are opting for an emulator account, which is a local blockchain emulator.

Now we will need to create some directories for our Cadence code.

Create a directory named flow under src directory, and create three more subdirectories named contract, transaction, and script under flow, respectively. This can be combined into a single command (make sure your current directory is petstore before running this):

mkdir -p src/flow/{contract,transaction,script}

As you might have guessed, each directory will contain the corresponding Cadence code for each type of interaction.

Now, in each of these directories, create a Cadence file with the following names: contract/PetStore.cdc, transaction/MintToken.cdc, and script/GetTokenIds.cdc.

Your src directory should now look like this:

.
|— flow
|   |— contract
|   |   |
|   |   `— PetStore.cdc
|   |— script
|   |   |
|   |   `— GetTokenIds.cdc
|   `— transaction
|       |
|       `— MintToken.cdc
|
...

`PetStore` contract

it is about time we write our smart contract. It is the most involved code in this project, so it is the ideal place to learn the language.

First, create the contract block that defines an NFT resource within:

pub contract PetStore {

    // This dictionary stores token owners' addresses.
    pub var owners: {UInt64: Address}

    pub resource NFT {

        // The Unique ID for each token, starting from 1.
        pub let id: UInt64

        // String -> String dictionary to hold 
        // token's metadata.
        pub var metadata: {String: String}

        // The NFT's constructor. All declared variables are
        // required to be initialized here.
        init(id: UInt64, metadata: {String: String}) {
            self.id = id
            self.metadata = metadata
        }
    }
}

Note that we have declared a Dictionary and stored it in a variable named owners. This dictionary has the type {UInt64: Address} which maps unsigned 64-bit integers to users' Addresses. We will use owners to keep track of all the current owners of all tokens globally.

Also note that the owners variable is prepended by a var keyword, while the id variable is prepended by a let keyword. In Cadence, a mutable variable is defined using var while an immutable one is defined with let.

💡 Immutable vs mutable
In Cadence, a variable stores a mutable variable that can be changed later in the program while a binding binds an immutable value that cannot be changed.

In the body of NFT resource, we declare id field and a constructor method to assign the id to the NFT instance.

Now we are ready to move on to the next step.

`NFTReceiver`

Now, we will add the NFTReceiver interface to define the capabilities of a receiver of NFTs. What this means is only the accounts with these capabilities can receive tokens from another addresses.

To reiterate, an interface is not an instance of an object, like a user account. It is a set of behaviors that a resource can implement to become capable of performing certain actions, for example withdrawing and depositing tokens.

Add the following NFTReceiver code to the existing PetStore contract. I will begin the comment for each method with "can" to make this clear that we are talking about a capability. Moreover, we won't be displaying all the code written previously. Instead, Comments with ellipses ... will be used to notate these truncated code.

pub contract PetStore {

    // ...

    pub resource interface NFTReceiver {

        // Can withdraw a token by its ID and returns 
        // the token.
        pub fun withdraw(id: UInt64): @NFT

        // Can deposit an NFT to this NFTReceiver.
        pub fun deposit(token: @NFT)

        // Can fetch all NFT IDs belonging to this 
        // NFTReceiver.
        pub fun getTokenIds(): [UInt64]

        // Can fetch the metadata of an NFT instance 
        // by its ID.
        pub fun getTokenMetadata(id: UInt64) : {String: String}

        // Can update the metadata of an NFT.
        pub fun updateTokenMetadata(id: UInt64, metadata: {String: String})
    }
}

Let's go over each method together.

The withdraw(id: UInt64): @NFT method takes an NFT's id, withdraws a token of type @NFT, which is prepended with a @ to indicate a reference to a resource.

The deposit(token: @NFT) method takes a token reference and deposits to the current NFTReceiver.

The getTokenIds(): [UInt64] method accesses all token IDs owned by the current NFTReceiver.

The getTokenMetadata(id: UInt64) : {String : String} method takes a token ID, reads the metadata, and returns it as a dictionary.

The updateTokenMetadata(id: UInt64, metadata: {String: String}) method takes an ID of an NFT and a metadata dictionary to update the target NFT's metadata.

`NFTCollection`

Now let's create an NFTCollection resource to implement the NFTReceiver interface. Think of this as a "vault" where NFTs can be deposited or withdrawn.

pub contract PetStore {

    // ... The @NFT code ...

    // ... The @NFTReceiver code ...

    pub resource NFTCollection: NFTReceiver {

        // Keeps track of NFTs this collection.
        access(account) var ownedNFTs: @{UInt64: NFT}

        // Constructor
        init() {
            self.ownedNFTs <- {}
        }

        // Destructor
        destroy() {
            destroy self.ownedNFTs
        }

        // Withdraws and return an NFT token.
        pub fun withdraw(id: UInt64): @NFT {
            let token <- self.ownedNFTs.remove(key: id)
            return <- token!
        }

        // Deposits a token to this NFTCollection instance.
        pub fun deposit(token: @NFT) {
            self.ownedNFTs[token.id] <-! token
        }

        // Returns an array of the IDs that are in this collection.
        pub fun getTokenIds(): [UInt64] {
            return self.ownedNFTs.keys
        }

        // Returns the metadata of an NFT based on the ID.
        pub fun getTokenMetadata(id: UInt64): {String : String} {
            let metadata = self.ownedNFTs[id]?.metadata
            return metadata!
        }

        // Updates the metadata of an NFT based on the ID.
        pub fun updateTokenMetadata(id: UInt64, metadata: {String: String}) {
            for key in metadata.keys {
                self.ownedNFTs[id]?.metadata?.insert(key: key,  metadata[key]!)
            }
        }
    }

    // Public factory method to create a collection
    // so it is callable from the contract scope.
    pub fun createNFTCollection(): @NFTCollection {
        return <- create NFTCollection()
    }
}

That's a handful of new code. It will soon become natural to you with patience.

First we declare a mutable dictionary and store it in a variable named ownedNFTs. Note the new access modifier pub(set), which gives public write access to the users.

This dictionary stores the NFTs for this collection by mapping the ID to NFT resource. Note that because the dictionary stores @NFT resources, we prepend the type with @, making itself a resource too.

In the contructor method, init(), we instantiate the ownedNFTs with an empty dictionary. A resource also needs a destroy() destructor method to make sure it is being freed.

💡 Nested Resource
A composite structure including a dictionary can store resources, but when they do they will be treated as resources. Which means they need to be moved rather than assigned and their type will be annotated with @.

The withdraw(id: UInt64): @NFT method removes an NFT from the collection's ownedNFTs array and return it.

The left-pointing arrow <- is known as a move symbol, and we use it to move a resource around. Once a resource has been moved, it can no longer be used from the old variable.

Note the ! symbol after the token variable. It force-unwraps the Optional value. If the value turns out to be nil, the program panics and crashes.

Because resources are core to Cadence, their types are annotated with a @ to make them explicit. For instance, @NFT and @NFTCollection are two resource types.

The deposit(token: @NFT) function takes the @NFT resource as a parameter and stores it in the ownedNFTs array in this @NFTCollection instance.

The ! symbol reappears here, but now it's after the move arrow <-!. This is called a force-move or force-assign operator, which only moves a resource to a variable if the variable is nil. Otherwise, the program panics.

The getTokenIds(): [UInt64] method simply reads all the UInt64 keys of the ownedNFTs dictionary and returns them as an array.

The getTokenMetadata(id: UInt64): {String : String} method reads the metadata field of an @NFT stored by its ID in the ownedNFTs dictionary and returns it.

The updateTokenMetadata(id: UInt64, metadata: {String: String}) method is a bit more involved.

for key in metadata.keys {
    self.ownedNFTs[id]?.metadata?.insert(key: key,  metadata[key]!)
}

In the body of the method, we loop over all the keys of the given metadata, inserting into the current metadata dictionary the new value. Note the ? in the call chain. It is used with Optionals values to keep going down the call chain only if the value is not nil.

We have successfully implemented the @NFTReceiver interface for the @NFTCollection resource.

`NFTMinter`

The last and very important component for our PetStore contract is @NFTMinter resource, which will contain an exclusive code for the contract owner to mint all the tokens. Without it, our store will not be able to mint any pet tokens. It is very simplistic though, since we have already blazed through the more complex components. Its only mint(): @NFT method creates an @NFT resource, gives it an ID, saves the address of the first owner to the contract (which is the address of the contract owner, although you could change it to mint and transfer to the creator's address in one step), increments the universal ID counter, and returns the new token.

pub contract PetStore {

    // ... NFT code ...

    // ... NFTReceiver code ...

    // ... NFTCollection code ...

    pub resource NFTMinter {

        // Declare a global variable to count ID.
        pub var idCount: UInt64

        init() {
            // Instantialize the ID counter.
            self.idCount = 1
        }

        pub fun mint(_ metadata: {String: String}): @NFT {

            // Create a new @NFT resource with the current ID.
            let token <- create NFT(id: self.idCount, metadata: metadata)

            // Save the current owner's address to the dictionary.
            PetStore.owners[self.idCount] = PetStore.account.address

            // Increment the ID
            self.idCount = self.idCount + 1 as UInt64

            return <-token
        }
    }
}

By now, we have all the nuts and bolts we need for the contract. The only thing that is missing is a way to initialize this contract at deployment time. Let's create a constructor method to create an empty @NFTCollection instance for the deployer of the contract (you) so it is possible for the contract owner to mint and store NFTs from the contract. As we go over this last hurdle, we will also learn about the other important concept in Cadence—Storage and domains.

pub contract PetStore {

    // ... @NFT code ...

    // ... @NFTReceiver code ...

    // ... @NFTCollection code ...

    // This contract constructor is called once when the contract is deployed.
    // It does the following:
    //
    // - Creating an empty Collection for the deployer of the collection so
    //   the owner of the contract can mint and own NFTs from that contract.
    //
    // - The `Collection` resource is published in a public location with reference
    //   to the `NFTReceiver` interface. This is how we tell the contract that the functions defined
    //   on the `NFTReceiver` can be called by anyone.
    //
    // - The `NFTMinter` resource is saved in the account storage for the creator of
    //   the contract. Only the creator can mint tokens.
    init() {
        // Set `owners` to an empty dictionary.
        self.owners = {}

        // Create a new `@NFTCollection` instance and save it in `/storage/NFTCollection` domain,
        // which is only accessible by the contract owner's account.
        self.account.save(<-create NFTCollection(), to: /storage/NFTCollection)

        // "Link" only the `@NFTReceiver` interface from the `@NFTCollection` stored at `/storage/NFTCollection` domain to the `/public/NFTReceiver` domain, which is accessible to any user.
        self.account.link<&{NFTReceiver}>(/public/NFTReceiver, target: /storage/NFTCollection)

        // Create a new `@NFTMinter` instance and save it in `/storage/NFTMinter` domain, accesible
        // only by the contract owner's account.
        self.account.save(<-create NFTMinter(), to: /storage/NFTMinter)
    }
}

Hopefully, the high-level steps are clear to you after you have followed through the comments. We will talk about domains briefly here. Domains are general-purpose storages accessible to Flow accounts commonly used for storing resources. Intuitively, they are similar to common filesystems. There are three domain namespaces in Cadence:

/storage

This namespace can only be accessed by the owner of the account.

/private

This namespace is used to stored private objects and capabilities whose access can be granted to selected accounts.

/public

This namespace is accessible by all accounts that interact with the contract.

In our previous code, we created an @NFTCollection instance for our own account and saved it to the /storage/NFTCollection namespace. The path following the first namespace is arbitrary, so we could have named it /storage/my/nft/collection. Then, something odd happened as we "link" a reference to the @NFTReceiver capability from the /storage domain to /public. The caret pair < and > was used to explicitly annotate the type of the reference being linked, &{NFTReceiver}, with the & and the wrapping brackets { and } to define the unauthorized reference type (see References to learn more). Last but not least, we created the @NFTMinter instance and saved it to our account's /storage/NFTMinter domain.

For a deep dive into storages, check out Account Storage.

As we wrap up our PetStore contract, let's try to deploy it to the Flow emulator to verify the contract. Start the emulator by typing flow emulator in your shell.

flow emulator

> INFO[0000] ⚙️   Using service account 0xf8d6e0586b0a20c7  serviceAddress=f8d6e0586b0a20c7 serviceHashAlgo=SHA3_256 servicePrivKey=bd7a891abd496c9cf933214d2eab26b2a41d614d81fc62763d2c3f65d33326b0 servicePubKey=5f5f1442afcf0c817a3b4e1ecd10c73d151aae6b6af74c0e03385fb840079c2655f4a9e200894fd40d51a27c2507a8f05695f3fba240319a8a2add1c598b5635 serviceSigAlgo=ECDSA_P256
> INFO[0000] 📜  Flow contracts                             FlowFees=0xe5a8b7f23e8b548f FlowServiceAccount=0xf8d6e0586b0a20c7 FlowStorageFees=0xf8d6e0586b0a20c7 FlowToken=0x0ae53cb6e3f42a79 FungibleToken=0xee82856bf20e2aa6
> INFO[0000] 🌱  Starting gRPC server on port 3569          port=3569
> INFO[0000] 🌱  Starting HTTP server on port 8080          port=8080

Take note of the FlowServiceAccount address, which is a hexadecimal number 0xf8d6e0586b0a20c7 (In fact, these numbers are so ubiquitous in Flow that it has its own Address type). This is the address of the contract on the emulator.

Open up a new shell, making sure you are inside the project directory, then type flow project deploy to deploy our first contract. You should see an output similar to this if it was successful:

flow project deploy

> Deploying 1 contracts for accounts: emulator-account
>
> PetStore -> 0xf8d6e0586b0a20c7 (11e3afe90dc3a819ec9736a0a36d29d07a2f7bca856ae307dcccf4b455788710)
>
>
> ✨ All contracts deployed successfully

Congratulations! You have learned how to write and deploy your first smart contract.

⚠️ Oops! That didn't work
Check flow.json configuration and make sure the path to the contract is correct.

`MintToken` transaction

The first and most important transaction for any NFT app is perhaps the one that mints tokens into existence! Without it there won't be any cute tokens to sell and trade. So let's start coding:

// MintToken.cdc

// Import the `PetStore` contract instance from the master account address.
// This is a fixed address for used with the emulator only.
import PetStore from 0xf8d6e0586b0a20c7

transaction(metadata: {String: String}) {

    // Declare an "unauthorized" reference to `NFTReceiver` interface.
    let receiverRef: &{PetStore.NFTReceiver}

    // Declare an "authorized" reference to the `NFTMinter` interface.
    let minterRef: &PetStore.NFTMinter

    // `prepare` block always take one or more `AuthAccount` parameter(s) to indicate
    // who are signing the transaction.
    // It takes the account info of the user trying to execute the transaction and
    // validate. In this case, the contract owner's account.
    // Here we try to "borrow" the capabilities available on `NFTMinter` and `NFTReceiver`
    // resources, and will fail if the user executing this transaction does not have access
    // to these resources.
    prepare(account: AuthAccount) {

        // Note that we have to call `getCapability(_ domain: Domain)` on the account
        // object before we can `borrow()`.
        self.receiverRef = account.getCapability<&{PetStore.NFTReceiver}>(/public/NFTReceiver)
            .borrow()
            ?? panic("Could not borrow receiver reference")

        // With an authorized reference, we can just `borrow()` it.
        // Note that `NFTMinter` is borrowed from `/storage` domain namespace, which
        // means it is only accessible to this account.
        self.minterRef = account.borrow<&PetStore.NFTMinter>(from: /storage/NFTMinter)
            ?? panic("Could not borrow minter reference")
    }

    // `execute` block executes after the `prepare` block is signed and validated.
    execute {
        // Mint the token by calling `mint(metadata: {String: String})` on `@NFTMinter` resource, which returns an `@NFT` resource, and move it to a variable `newToken`.
        let newToken <- self.minterRef.mint(metadata)

        // Call `deposit(token: @NFT)` on the `@NFTReceiver` resource to deposit the token.
        // Note that this is where the metadata can be changed before transferring.
        self.receiverRef.deposit(token: <-newToken)
    }
}

⚠️ Ambiguous type warning
If you are using VSCode, chances are you might see the editor flagging the
lines referring to PetStore.NFTReceiver and PetStore.NFTMinter types
with an "ambiguous type <T> not found". Try to reset the running emulator
by pressing Ctrl+C in the shell where you ran the emulator to interrupt it
and run it again with flow emulator and on a different shell, don't forget
to redeploy the contract with flow project deploy.

The first line of the transaction code imports the PetStore contract instance.

The transaction block takes an arbitrary number of named parameters, which will be provided by the calling program (In Flow CLI, JavaScript, Go, or other language). These parameters are the only channels for the transaction code to interact with the outside world.

Next, we declare references &{NFTReceiver} and &NFTMinter (Note the first is an unauthorized reference).

Now we enter the prepare block, which is responsible for authorizing the transaction. This block takes an argument of type AuthAccount. This account instance is required to sign and validate the transaction with its key. If it takes more than one AuthAccount parameters, then the transaction becomes a multi-signature transaction. This is the only place our code can access the account object.

What we did was calling getCapability(/public/NFTReceiver) on the account instance, then borrow() to borrow the reference to NFTReceiver and gain the capability for receiverRef to receive tokens. We also called borrow(from: /storage/NFTMinter) on the account to enable minterRef with the superpower to mint tokens into existence.

The execute block runs the code within after the prepare block succeeds. Here, we called mint(metadata: {String: String}) on the minterRef reference, then moved the newly created @NFT instance into a newToken variable. After, we called deposit(token: @NFT) on the receiverRef reference, passing <-newToken (@NFT resource) as an argument. The newly minted token is now stored in our account's receiverRef.

Let's try to send this transaction to the running emulator and mint a token! Because this transaction takes a metadata of type {String: String} (string to string dictionary), we will need to pass that argument when sending the command via Flow CLI.

With a bit of luck, you should get a happy output telling you that the transaction is sealed.

flow transactions send src/flow/transaction/MintToken.cdc '{"name": "Max", "breed": "Bulldog"}'

> Transaction ID: b10a6f2a1f1d88f99e562e72b2eb4fa3ae690df591d5a9111318b07b8a72e060
>
> Status      ✅ SEALED
> ID          b10a6f2a1f1d88f99e562e72b2eb4fa3ae690df591d5a9111318b07b8a72e060
> Payer       f8d6e0586b0a20c7
> Authorizers [f8d6e0586b0a20c7]
> ...

Note the transaction ID returned from the transaction. Every transaction returns an ID no matter if it succeeds or not.

Congratulations on minting your first NFT pet! It does not have a face yet besides just a name and a breed. But later in this tutorial, we will upload static images for our pets onto the Filecoin/IPFS networks using nft.storage.

`TransferToken` transaction

Now that we know how to mint Flow NFTs, the next natural step is to learn how to transfer them to different users. Since this transfer action writes to the blockchain and mutates the state, it is also a transaction.

Before we can transfer a token to another user's account, we need another receiving account to deposit a token to. (We could transfer a token to our address, but that wouldn't be very interesting, would it?) At the moment, we have been working with only our emulator account so far. So, let's create an account through the Flow CLI.

First, create a public-private key pair by typing flow keys generate. The output should look similar to the following, while the keys will be different:

flow keys generate

> 🔴️ Store private key safely and don't share with anyone!
> Private Key  f410328ecea1757efd2e30b6bc692277a51537f30d8555106a3186b3686a2de6
> Public Key  be393a6e522ae951ed924a88a70ae4cfa4fd59a7411168ebb8330ae47cf02aec489a7e90f6c694c4adf4c95d192fa00143ea8639ea795e306a27e7398cd57bd9

For convenience, let's create a JSON file named .keys.json in the root directory next to flow.json so we can read them later on:

{
    "private": "f410328ecea1757efd2e30b6bc692277a51537f30d8555106a3186b3686a2de6",
    "public": "be393a6e522ae951ed924a88a70ae4cfa4fd59a7411168ebb8330ae47cf02aec489a7e90f6c694c4adf4c95d192fa00143ea8639ea795e306a27e7398cd57bd9"
}

Next, type this command, replacing <PUBLIC_KEY> with the public key you generated to create a new account:

flow accounts create —key <PUBLIC_KEY> —signer emulator-account

> Transaction ID: b19f64d3d6e05fdea5dd2ac75832d16dc61008eeacb9d290f153a7a28187d016
>
> Address 0xf3fcd2c1a78f5eee
> Balance 0.00100000
> Keys    1
>
> ...

Take note of the new address, which should be different from the one shown here. Also, you might notice there is a transaction ID returned. Creating an account is also a transaction, and it was signed by the emulator-account (hence, —signer emulator-account flag).

Before we can use the new address, we need to tell the Flow project about it. Open the flow.json configuration file, and at the "accounts" field, add the new account name ("test-account" here, but it could be any name), address, and the private key:

{
    // ...

    "accounts": {
        "emulator-account": {
            "address": "f8d6e0586b0a20c7",
            "key": "bd7a891abd496c9cf933214d2eab26b2a41d614d81fc62763d2c3f65d33326b0"
        },
        "test-account": {
            "address": "0xf3fcd2c1a78f5eee",
            "key": <PRIVATE_KEY>
        }
    }

    // ...
}

With this new account created, we are ready to move on to the next step.

Before we can deposit a token to the new account, we need it to "initialize" its collection. We can do this by creating a transaction for every user to initialize an NFTCollection in order to receive NFTs.

Inside /transactions directory next to MintToken.cdc, create a new Cadence file named InitCollection.cdc:

// InitCollection.cdc

import PetStore from 0xf8d6e0586b0a20c7

// This transaction will be signed by any user account who wants to receive tokens.
transaction {
    prepare(acct: AuthAccount) {
        // Create a new empty collection for this account
        let collection <- PetStore.NFTCollection.new()

        // store the empty collection in this account storage.
        acct.save<@PetStore.NFTCollection>(<-collection, to: /storage/NFTCollection)

        // Link a public capability for the collection.
        // This is so that the sending account can deposit the token to this account's
        // collection by calling its `deposit(token: @NFT)` method.
        acct.link<&{PetStore.NFTReceiver}>(/public/NFTReceiver, target: /storage/NFTCollection)
    }
}

This small code will be signed by a receiving account to create an NFTCollection instance and save it to their own private /storage/NFTCollection domain (Recall that anything stored in /storage domain can only be accessible by the current account). In the last step, we linked the NFTCollection we have just stored to the public domain /public/NFTReceiver (and in the process, "casting" the collection up to NFTReceiver) so whoever is sending the token can access this and call deposit(token: @NFT) on it to deposit the token.

Try sending this transaction by typing the command:

flow transactions send src/flow/transaction/InitCollection.cdc —signer test-account

Note that test-account is the name of the new account we created in the flow.json file. Hopefully, the new account should now have an NFTCollection created and ready to receive tokens!

Now, create a Cadence file named TransferToken.cdc in the /transactions directory with the following code.

// TransferToken.cdc

import PetStore from 0xf8d6e0586b0a20c7

// This transaction transfers a token from one user's
// collection to another user's collection.
transaction(tokenId: UInt64, recipientAddr: Address) {

    // The field holds the NFT as it is being transferred to the other account.
    let token: @PetStore.NFT

    prepare(account: AuthAccount) {

        // Create a reference to a borrowed `NFTCollection` capability.
        // Note that because `NFTCollection` is publicly defined in the contract, any account can access it.
        let collectionRef = account.borrow<&PetStore.NFTCollection>(from: /storage/NFTCollection)
            ?? panic("Could not borrow a reference to the owner's collection")

        // Call the withdraw function on the sender's Collection to move the NFT out of the collection
        self.token <- collectionRef.withdraw(id: tokenId)
    }

    execute {
        // Get the recipient's public account object
        let recipient = getAccount(recipientAddr)

        // This is familiar since we have done this before in the last `MintToken` transaction block.
        let receiverRef = recipient.getCapability<&{PetStore.NFTReceiver}>(/public/NFTReceiver)
            .borrow()
            ?? panic("Could not borrow receiver reference")

        // Deposit the NFT in the receivers collection
        receiverRef.deposit(token: <-self.token)

        // Save the new owner into the `owners` dictionary for look-ups.
        PetStore.owners[tokenId] = recipientAddr
    }
}

Recall that in the last steps of our MintToken.cdc code, we were saving the minted token to our account's NFTCollection reference stored at /storage/NFTCollection domain.

Here in TransferToken.cdc, we are basically creating a sequel of the minting process. The overall goal is to move the token stored in the sending source account's NFTCollection to the receiving destination account's NFTCollection by calling withdraw(id: UInt64) and deposit(token: @NFT) on the sending and receiving collections, respectively. Hopefully, by now it shouldn't be too difficult for you to follow along with the comments as you type down each line.

Two new things that are worth noting are the first line of the execute block where we call a special built-in function getAccount(_ addr: Address), which returns an AuthAccount instance from an address passed as an argument to this transaction, and the last line, where we update the owners dictionary on the PetStore contract with the new address entry to keep track of the current NFT owners.

Now, let's test out TransferToken.cdc by typing the command:

flow transactions send src/flow/transaction/TransferToken.cdc 1 0xf3fcd2c1a78f5eee

> Transaction ID: 4750f983f6b39d87a1e78c84723b312c1010216ba18e233270a5dbf1e0fdd4e6
>
> Status      ✅ SEALED
> ID          4750f983f6b39d87a1e78c84723b312c1010216ba18e233270a5dbf1e0fdd4e6
> Payer       f8d6e0586b0a20c7
> Authorizers [f8d6e0586b0a20c7]
>
> ...

Recall that the transaction block of TransferToken.cdc accepts two arguments — A token ID and the recipient's address — which we passed as a list of arguments to the command. Some of you might wonder why we left out --signer flag for this transaction command, but not the other. Without passing the signing account's name to --signer flag, the contract owner's account is the signer by default (a.k.a the AuthAccount argument in the prepare block).

Well done! You have just withdrawn and deposited your NFT to another account!

`GetTokenOwner` script

We have learned to write and send transactions. Now, we will learn how to create scripts to read state from the blockchain.

There are many things we can query using a script, but since we have just transferred a token to test-account, it would be nice to confirm that the token was actually transferred.

Let's create a script file named GetTokenOwner.cdc under the script directory:

// GetTokenOwner.cdc

import PetStore from 0xf8d6e0586b0a20c7

// All scripts start with the `main` function,
// which can take an arbitrary number of argument and return
// any type of data.
//
// This function accepts a token ID and returns an Address.
pub fun main(id: UInt64): Address {

    // Access the address that owns the NFT with the provided ID.
    let ownerAddress = PetStore.owners[id]!
    return ownerAddress
}

All scripts have an entry function called main, which can take any number of arguments and return any data type.

In this script, the main function accesses the owners dictionary in the PetStore contract using the token ID and returns the address of the token's owner, or fails if the value is nil.

As a reminder, scripts do not require any gas fee or authorization because they only read public data on the blockchain rather than writing to it.

Here's how to execute a script with the Flow CLI:

flow scripts execute src/flow/script/GetTokenOwner.cdc <TOKEN_ID>

<TOKEN_ID> is an unsigned integer token ID starting from 1. If you have minted an NFT and transferred it to the test-account, then replace <TOKEN_ID> with the token ID. You should get back the address of the test-account you have created.

`GetTokenMetadata` script

From GetTokenOwner.cdc script, it takes only a few more steps to create a script that returns a token's metadata.

We will work on GetTokenMetadata.cdc which, as the name suggests, gets the metadata of an NFT based on the given ID.

Recall that there is a metadata variable in the NFT resource definition in the contract which stores a {String: String} dictionary of that NFT's metadata. Our script will have to query the right NFT and read the variable.

Because we already know how to get an NFT's owner address, all we have to do is to access NFTReceiver capability of the owner's account and call getTokenMetadata(id: UInt64) : {String: String} on it to get back the NFT's metadata.

// GetTokenMetadata.cdc

import PetStore from 0xf8d6e0586b0a20c7

// All scripts start with the `main` function,
// which can take an arbitrary number of argument and return
// any type of data.
//
// This function accepts a token ID and returns a metadata dictionary.
pub fun main(id: UInt64) : {String: String} {

    // Access the address that owns the NFT with the provided ID.
    let ownerAddress = PetStore.owners[id]!

    // We encounter the `getAccount(_ addr: Address)` function again.
    // Get the `AuthAccount` instance of the current owner.
    let ownerAcct = getAccount(ownerAddress)

    // Borrow the `NFTReceiver` capability of the owner.
    let receiverRef = ownerAcct.getCapability<&{PetStore.NFTReceiver}>(/public/NFTReceiver)
        .borrow()
            ?? panic("Could not borrow receiver reference")

    // Happily delegate this query to the owning collection
    // to do the grunt work of getting its token's metadata.
    return receiverRef.getTokenMetadata(id: id)
}

Now, execute the script:

flow scripts execute src/flow/script/GetTokenMetadata.cdc <TOKEN_ID>

If we have minted an NFT with the metadata {"name": "Max", "breed": "Bulldog"} in the previous minting step, then that is what you will get after running the script.

`GetAllTokenIds` (Bonus)

This script is very short and straightforward, and it will become handy
when we build a UI to query tokens based on their IDs.

// GetAllTokenIds.cdc

import PetStore from 0xPetStore

pub fun main() : [UInt64] {
    // We basically just return all the UInt64 keys of `owners`
    // dictionary as an array to get all IDs of all tokens in existence.
    return PetStore.owners.keys
}

Wrapping up

Et voila! You have come very far and dare I say you are ready to start building your own Flow NFT app.

However, user experience is a crucial part in any app. It is more than likely that your users won't be as proficient at the command line as you are. Moreover, it is a bit boring for an NFT store to have faceless NFTs. In the second part, we will start building the UI on top and using nft.storage service to upload and store images of our NFTs instead of the command line using React.

Follow me to learn about the brave web3 world and how to program it

Any idea to make this post even better? I'd like to hear from you.

In a hurry to get to part 2? Check out the original version on NFT School.

How to Run Spark SQL on Encrypted Data

Pan Chasinga — Tue, 10 Aug 2021 22:58:00 +0000

Introducing Opaque SQL, an open-source platform for securely running Spark SQL queries on encrypted data. Built by top systems and security researchers at UC Berkeley, the platform uses hardware enclaves to securely execute queries on private data in an untrusted environment.

Opaque SQL partitions the codebase into trusted and untrusted sections to improve runtime and reduce the amount of code that needs to be trusted. The project was designed to introduce as little changes to the Spark API as possible. If you are familiar with Spark SQL, then you already know how to run secure queries with Opaque SQL.

🚀 Prefer a quick, hands-on ride? Follow the Quick Start Guide with Docker and tell us about your experience.

What is Spark SQL?

For those of you who are new, Apache Spark is a popular distributed computing framework used by data scientists and engineers for processing large batches of data. One of its modules, Spark SQL, allows users to interact with structured, tabular data. This can be done through a DataSet/DataFrame API available in Scala or Python, or by using standard SQL queries. Here you can see a quick example of both below:


// Convert a sequence of tuples into a Spark DataFrame
val data = Seq((“dog”, 4), (“chameleon”, 1), (“cat”, 5))
val df = data.toDF(“pet”, “count”)

/********** DataFrame API **********/

// Create a new DataFrame of rows with `count` greater than 3
val apiResult = df.filter($”count” > lit(3))

/******* Writing SQL queries *******/

// Register `df` as a virtual table used to evaluate SQL on
df.createOrReplaceTempView(“df”)
// Create a new DataFrame of rows with `count` greater than 3
val sqlStrResult = spark.sql(“SELECT * FROM df WHERE count > 3”)

In Python via PySpark:


# Convert a list of tuples into a Spark DataFrame
data = [("dog", 4), ("chameleon", 1), ("cat", 5)]
df = spark.createDataFrame(data).toDF(["pet", "count"])

######### Dataframe API ############

# Create a new DataFrame of rows with `count` greater than 3
api_result = df.filter(df["count"] > lit(3))

######## Write SQL queries #########

# Register `df` as a virtual table used to evaluate SQL on
df.createOrReplaceTempView(“pets”)
# Create a new DataFrame of rows with `count` greater than 3
val sqlStrResult = spark.sql(“SELECT * FROM pets WHERE count > 3”)

😉 If you haven't already, now is a good time to head over and install Spark and play with the code at the prompt.

Spark Components

For its distributed computing architecture, Spark adopts a master-worker architecture where the master is known as the driver and workers are known as executors.

The driver is the process where the main Spark program runs. It is responsible for translating a user’s code into jobs to be run on the executors. For example, given a SQL query, the driver builds the SQL plan, performs optimization, and resolves the physical operators that the execution engine will use. It then schedules the compute tasks among the workers and keeps track of their progress until completion. Any metadata, such as the number of data partitions to use or how much memory each worker should have, is set on the driver.

The executors are responsible for the actual computation. Given a task from the driver, an executor performs the computation and coordinates its progress with the driver. They are launched at the start of every Spark application and can be dynamically removed and added by the driver as needed.

Computing on encrypted data using MC²

The MC² Project is a collection of tools for secure Multi-party Collaboration and Coopetition (hence MC²). This goal is achieved through the use of hardware enclaves. Enclaves provide strong security guarantees, keeping data encrypted in memory while in use. They also provide remote attestation, which ensures that the enclaves responsible for computation are running the correct sets of instructions. The result is a platform capable of computing on sensitive data in an untrusted environment, such as a public cloud.

Opaque SQL in a Nutshell

The Opaque SQL query resolution stack. MC² components are in blue.

At a high level, Opaque SQL is a Spark package that uses hardware enclaves to partition Spark’s architecture into untrusted and trusted components. It was originally developed at UC Berkeley’s RISELab as the implementation of a NSDI 2017 paper.

Untrusted Driver

While the query and table schemas are not hidden because the Spark driver still needs to perform planning, the driver is only able to access completely encrypted data. The physical plan built will contain entirely encrypted operators in place of vanilla Spark operators. (However, since the driver is building the plan, the client needs to verify that the plan created is correct; support for this is currently a work-in-progress and will be part of the next release.)

Enclaves on Executor Machines

During execution, the executor program calls into Opaque SQL’s native library that’s loaded inside the hardware enclave. The native library provides encrypted SQL operators that can execute on encrypted, sensitive data inside the enclave. Any private column data such as SSNs, bank account numbers, or PHI remains encrypted in memory and is protected by the enclave.

the MC² Client: The Entry Point

The MC² Client is responsible for communicating with the Spark driver and performing remote attestation and query submission. It is a trusted component that is located on the user’s machine.

Remote attestation

Attest, what? To put it simply, remote attestation is just a way to have the user verify that the enclaves were initialized correctly with the right code to run. The client talks to the driver, which forwards attestation information to the enclaves that are running on the executors. No enclave is able to decrypt any data until attestation is complete and the results are verified by the user. Think of it as a way for you, the data owner, to sign off and trust the enclave to start running code on your behalf.

Query submission

Query submission happens after attestation is completed successfully, and is the step where Spark code is remotely submitted to the driver for evaluation. Any intermediate values remain encrypted throughout the lifetime of the execution stage.

How the MC² client communicates with Opaque SQL

Usage

A key design for Opaque SQL is to have our API as similar to Spark SQL as possible. An encrypted DataFrame is loaded in through a special format:


// Unencrypted
val df = spark.read.format(“com.databricks.spark.csv”)
// Encrypted
val dfEncrypted = spark.read.format(“edu.berkeley.cs.rise.opaque.EncryptedSource”)

After loading, Spark transformations are applied exactly the same as vanilla Spark, only with new encrypted physical operators being created during planning:


val result = dfEncrypted.filter($”count” > lit(3))
result.explain
// == Physical Plan ==
// EncryptedFilter (count#5 > 3)
// +- EncryptedLocalTableScan [word#4, count#5], [[foo,4], [bar,1], [baz,5]]

To save the result after a query has been created, use the same format as loading:


result.write \
  .format(“edu.berkeley.cs.rise.opaque.EncryptedSource”) \
  .save(“path/to/result”)

💡 Now is the time to check our complete API docs to continue your learning journey.

Wrapping Up

Opaque SQL enables analytics processing over encrypted DataFrames, with little overhead to vanilla Spark. In turn, this extension protects data-in-use in the cloud as well as at rest. Queries are submitted remotely with the help of the MC² Client, an easy-to-use interface for communicating with all compute services on the MC² stack.

Check out more blog posts on how to securely process data with MC² Project. We would love your contributions ✋ and support ⭐! Please check out the Github repo to see how you can contribute. No contribution is too small.

Edited by @pancy. Originally posted here by @octaviansima.

Python Should Learn from Javascript

Pan Chasinga — Fri, 16 Jul 2021 04:16:48 +0000

If Javascript, an old language with so many flaws, could evolve like it did, Python could learn from it and step out of its ivory tower.

This isn’t a targeted attack on Python. It is a constructive opinion from a programmer who had started his career and spent years working with it. So brace yourself — Python is evolving slowly and could use the level of improvement Javascript has had.

Javascript has come a long way since being the most hated but widely-used scripting language of the web that was created in less than a month. With ES6 and the sister language Typescript (that arguably helped propelled JS ecosystem to a new height), Javascript is no longer an ugly language to be looked down to. For instance, it has changed dramatically from a callback-based language into promise-based and async-await syntax in what seemed like a blink of an eye compared to the rate Python moved to reach a unanimous support for v3.
A very impressive deed of Javascript, in my opinion, is its move toward functional programming. The syntax is clean, learning from the great functional languages like ML. This alone sprouted so many great improvements to the ecosystem such as React, ReasonML, and more. Let’s admit it, there’s a lot to love about modern Javascript compared to Python 3.
Until recently, Python had always been under tight moderation of its creator, Guido Rossum. While that had its good parts, the downside is the language’s slow development due to the bottleneck from the resistance of the creator.

Lambda what?

For example, Guido Rossum distaste for lambdas was well-known. Perhaps the goal of Python’s half-baked lambda syntax that I’ve always found clumsy and useless to this day has always been to keep users from using it in the first place.

x = lambda a : a + 10

There is nothing wrong with this syntax, since many Lisp dialects also use the keyword lambda to initialize an anonymous function. However, being a whitespace-significant language and not expression-based, the lambda syntax of Python makes a cumbersome and ambiguous experience in applying lambdas:

x = lambda a : a + 10 (lambda b : b * 2))

Now who says Python is still easy to read? This kind of beats the very reasons of lambdas, which are expressiveness and clarity. This appears ambiguous to me. Compared to the anonymous function syntax of ES6:

let x = (c => c + 2)(a => a + 10)(b => b * 2)(y);

Although not the cleanest (the cleanest lambda syntax goes to Lisp), the applications are clear, considered you know it is right-associated. The only thing Javascript is missing is piping syntax, which would have made it an even more expressive programming tool.

let x = y |> (c => c + 2) |> (a => a + 10) |> (b => b * 2)

map(function, iterable, …)

Admit it, you either hate or feel meh over mapping iterables in Python, or you might not even use it.
Most languages, including Javascript, treat mapping function as the iterable or iterator method. This removes the iterable from the argument list and makes it much clearer with the callback function being the last argument.

let nums = [1, 2, 3, 4].map(n => n * 2);

Here is another map function in Rust:

let nums = [1, 2, 3, 4].iter().map(|n| n * 2);

Some functional languages such as Haskell and Ocaml use the module:function approach, which is similar to what Python does. However, their expression-based syntax and unambiguous scoped variable binding makes the code readable and easy to get right. Here is a sample of a map function in Ocaml:

let nums = let double n = n * 2 in List.map double [1; 2; 3; 4]

You need to do this in Python:

double = lambda n : n * 2
nums = map(double, [1, 2, 3, 4])

You may think Python looks way cleaner here, which you may be right. But consider most use cases where you chain operators.

let nums = [1, 2, 3, 4]
   .map(n => n * 2)
   .filter(n => n > 2);
   .reduce((acc, current) => acc + current);

In Ocaml, it’s just magical:

let nums = [1; 2; 3; 4]
  |> map (fun n -> n * 2) 
  |> filter (fun n -> n > 2)
  |> fold_left ( + ) 0

I’ll leave you to write an equivalent in Python (HINT: It is impossible to read!)

Decorators

Decorators are my pet peeves. To me, they were the inflection point from Python mantra of “there’s only one way to do things” and the promise of a transparent, non-magical language.

def hello(func):                                                                                            
    def inner():                                                                                            
        print("Hello ")                                                                                     
        func()                                                                                              
    return inner                                                                                            

def name():                                                                                                 
    print("Alice")                                                                                         

# `hello` is a decorator function                                                                                          
obj = hello(name)                                                                                           
obj()  # prints "Hello Alice"
The short-handed version for this is:
@hello
def name():
    print("Alice")
if __name__ == '__main__':
    name()  # prints "Hello Alice"

Decorators “hide” the logic essential and completely change the behavior of a “host” function it decorates, which is nothing short of magical to more than half of all Python users today. Albeit useful, it still puzzles me to these days why Python developers decided to adopt decorators.

Somehow, Javascript has found its niche in everything. However, its ES6 improvement and Typescript enhancement has made it even more enticing to users who dislike it (myself, for one, had become a serious Javascript user after ES6). Python similarly hold a very big niche, including web programming, data science, and machine learning, which warrant its ivory tower. However, today’s tools are evolving fast, and not changing seems like standing still waiting for a new kid on the block to beat it in the home court.

If you like my writing, please follow me on Twitter to get more of technical opinions. I’m also on Medium and would love to see you there!

EP1: Rust Ownership for Toddlers

Pan Chasinga — Tue, 22 Jun 2021 16:00:07 +0000

"Rust is too hard to learn," You whined.
"Maybe because you're a toddler?"

🧸 Ownership

💡 Ownership IS the only big concept in Rust. It is not unique, and C++ has it too. Understand this well.

Repeat after me, "Thou shall be the only one owning a toy."

That's it. Alice has a toy, then Bob snatches it from Alice. Alice no longer has the toy. Bob runs away and gets bullied by Tim, looting the toy. Then Bob has no toy. Tim has the toy.

If you later asked Alice for the toy, she would just cry and slap you on and on, yelling, "Bob took my toy!"

If you asked Bob to get back the toy, he would lash out with a black eye. "Tim has it!"

fn main() {
    let alice = String::from("Teddy");

    {
        /// Bob suddenly shows up and snatches it from Alice.
        let bob = alice;

        /// "Bob took it!" Alice cried.
        println!("Alice, where is the {}", alice);

        let tim = bob;

        /// "Tim stole it!" Bob lashed out.
        println!("Bob, did you take the {} from Alice?", alice);

        /// Tim, an alien under a kid skin, eats the bear.
        /// Then, Tim and Bob vanishes into ether.
    }

    /// "Who's Bob?" Alice said, Teddy no longer in her arm.
    /// Cue the X-file music...
    println!("Alice, did Bob return the {}", alice);
}

🔮 Reflect

Although this may sound confusing, it is pretty simple in the real, physical world. You were just too spoiled by your X language. Here is the hard fact -- You just can't have more of a thing. A piece of data is not made of pixie dust. It is a bunch of electrons making tricks on a couple of latches to spell out enough 0 and 1 digits to make up a piece of data. As real as a teddy bear.

🐍 What other languages do

What most languages do is basically telling Alice and Bob to share, which they can on a good day. On a bad one, they are yanking the toy on each end. On the worst, either one might misplace it and the other explodes. This one hip language named after a fat snake takes it too far by buying a duplicate for every toy for Alice, Bob, Tim, and any other kids who want to play with it.

🍼 Try-sies
Instead of a String::from("Teddy"), try a string literal "Teddy" or an integer and keep the code. What happens? Use this playground.

Sensibly, in order for Alice to have the toy, Bob (or whoever was owning it) should return the toy to her.

/// mut means I can change what I have later.
let mut alice = Toy("Teddy");
let bob = alice;
let mut tim = bob;

tim = daghan_does_something(tim);

/// "No!" Alice yelled.
println("Did you get the {:?} back, Alice?", alice);

alice = tim;

/// Print just fine!
println("Now, did you get the {:?} back?", alice);

Since Tim eventually returned the toy back to Alice, Alice is happy.

Stay tuned for EP2: Rust Borrows for Toddlers: All You Gotta Do is Ask.

👀 Follow me so you don't miss the next episodes!
🦄 Upvote this so Netflax renews the episodes!

I'm also on Medium and Twitter. Come say 👋

DEV Community: Pan Chasinga

Taking Back Control in 2024

How to set better 2025 Goals

What is Semantic API?

What are Big and Little Endians?

Getting Started with Goblins

What is Goblins?

What is Object Capability (OCAP)?

What is Capability Transport Protocol (CapTP)?

Quick Setup

Immediately Calling an Object in a Vat

Eventual Send and Handling Promises in Many Vats

Conclusion

Grokking Partial Application

Build a Decentralized App on IPFS using WebAssembly

O, Wasm Fun!

Ok, but why IPFS?

Convinced? Let's begin

Get familiar with Yew

Fun with buttons

Deploy to IPFS

Run IPFS locally

IPFS Gateway

Pinning services

Immutability's crux

Building an NFT Store on Flow: Part 2

Setting up

Minting

1. Upload to NFT.Storage

2. Send a minting transaction

3. Return the transaction ID

Querying the token

Next steps

Building an NFT store on Flow : Part 1

Who this is for

Set up

What you will learn

Understanding ownership and resource

Resource

Accounts

Contract

Quick tour of Cadence

Contract

Resources

Interfaces

Transaction

Script

Building pet store

Project structure

PetStore contract

NFTReceiver

NFTCollection

NFTMinter

/storage

/private

/public

MintToken transaction

TransferToken transaction

GetTokenOwner script

GetTokenMetadata script

GetAllTokenIds (Bonus)

Wrapping up

Follow me to learn about the brave web3 world and how to program it

Any idea to make this post even better? I'd like to hear from you.

In a hurry to get to part 2? Check out the original version on NFT School.

How to Run Spark SQL on Encrypted Data

What is Spark SQL?

Spark Components

Computing on encrypted data using MC²

Opaque SQL in a Nutshell

Untrusted Driver

Enclaves on Executor Machines

the MC² Client: The Entry Point

Remote attestation

Query submission

Usage

Wrapping Up

Python Should Learn from Javascript

Lambda what?

map(function, iterable, …)

`PetStore` contract

`NFTReceiver`

`NFTCollection`

`NFTMinter`

`MintToken` transaction

`TransferToken` transaction

`GetTokenOwner` script

`GetTokenMetadata` script

`GetAllTokenIds` (Bonus)