DEV Community: Thomas Eckert

Changing Directory with a Python Context Manager

Thomas Eckert — Mon, 04 Jan 2021 23:01:51 +0000

Originally published on thomaseckert.dev

In my latest project, I've added Tailwind and Vue to a Flask app. This requires an additional build step to compile each using npm during deployment. Given that Python is already present on the server by the time the build step occurs, I decided to write the build script in Python.

Those who have written build scripts before may be familiar with the pattern of changing into a directory, executing commands, then returning to the original directory to start the next set of commands. That was exactly what I needed to do here:

Change directory to ./tailwind
1. Execute npm install to install dependencies
2. Execute npm run build to compile the Tailwind CSS
Change directory ..
Change directory ./vue
1. Execute npm install to install dependencies
2. Execute npm run build to compile the Vue application

This seemed like a perfect fit for a Python context manager. Context managers allow for the instatiation of a context using the with keyword. The context is disposed when the code is dedented. Using a context manager to change directories here would eliminate the relative path directory change in step 2, once the first step is completed, the directory would be automatically reset to what it was before the context was initiated.

By writing the right context manager set_directory, I could implement the build script as

from pathlib import Path

with set_directory(Path("./tailwind")):
    run_npm_install()
    run_npm_build()
with set_directory(Path("./vue")):
    run_npm_install()
    run_npm_build()

and I thought that was pretty slick!

Context managers can be written as classes or functions. Given the relative simplicity of this context, I opted to use a function. A context manager function must be decorated with @contextmanager which is imported from contextlib. It should have a try block with a yield and a finally block. When the context is instantiated using the with keyword, the try block is run. When the indented code block is left, the finally block is run. As an example,

from contextlib import contextmanager

@contextmanager
def friendly_context():
    try:
        print("Hello! Welcome to the context!")
        yield
    finally:
        print("Bye now. Thank you for visiting the context. Come again soon.")

with friendly_context():
    print("Oh thank you, it is so nice to be in the context.")

when executed will print

Hello! Welcome to the context!
Oh thank you, it is so nice to be in the context.
Bye now. Thank you for visiting the context. Come again soon.

To write my directory changing context manager, I needed to save the original path to a variable, change it in the try block to whatever was passed in to the function, then change to the original path in the finally block.

from contextlib import contextmanager
from pathlib import Path

import os

@contextmanager
def set_directory(path: Path):
    """Sets the cwd within the context

    Args:
        path (Path): The path to the cwd

    Yields:
        None
    """

    origin = Path().absolute()
    try:
        os.chdir(path)
        yield
    finally:
        os.chdir(origin)

And it works like a charm! Let me know if you found a cool use for context managers or would have solved this problem a different way.

Luka 04 - Don't `panic!`

Thomas Eckert — Fri, 13 Sep 2019 05:52:51 +0000

This post is part of a series on the development of a reverse polish notation calculator web-app using Rust/Wasm, Vue, and TypeScript. You can read more and follow along with development at the GitHub Repo.

At the end of Luka 03, I wasn't sure whether to work on connecting the Rust and TypeScript using Wasm or organize how state is passed in the Vue application. I decided to take on the former first. I think I'm going to hit some interesting walls that might affect how I structure the Vue application.

Finding References

I've connected Rust and JavaScript once in a tutorial, but I don't have a great understanding of how that connection works and how to set it up properly. That's part of the motivation for this project -- pushing myself to learn.

Here are some resources I'm reading through to understand the structure:

I don't think I'll need wasm-pack as I am adding Wasm to an existing project, but I downloaded the latest version anyway (0.8.1). I know I will need wasm-bindgen as a dependency.

[dependencies]
wasm-bindgen = "0.2.50"

I think we're off to a great start.

I see references to using wee_alloc to minimize the amount of Wasm that is generated. I think that sounds nice, but I won't start with that yet.

To the lib.rs, I'm adding the import for wasm-bindgen decorators. All the tests still pass so that's good. It turns out I do need wasm-pack to build the .wasm file (probably another way to do it, but this is what's showing up in the tutorial).

First attempt at building the .wasm gives a good, informational error message.

Error: crate-type must be cdylib to compile to wasm32-unknown-unknown. Add the following to your Cargo.toml file:

[lib]
crate-type = ["cdylib", "rlib"]

Ok. I added that bit to the cargo.toml.

It... worked. I mean, I didn't decorate any functions so it didn't generate any functions on the wasm side, but still. Wow.

Now to decorate the functions. I'm not sure if I have to decorate every function or if I can get away with just decorating the struct and impl...

Well it failed, but it failed because the std::vec::Vec<f64> doesn't implement std::marker::Copy. Looking at the Rust docs, this is true for all Vec<T> because it's managing some other resource as evidenced by its implementation of Drop.

I can't pass a Vec<T>? That's confusing because how do they do that in the Universe struct here? I'm definitely not understanding something here.

If I truly can't pass a Vec<T>, I really only need to worry about the last two values of the stack in the Rust code at any given time if I have the TypeScript manage the full stack state. A workable solution could look like this:

TypeScript holds state [4.5, 3, 99, 0.5].
The "+" button is pressed.
The last two values in the stack are passed to Rust (99, 0.5).
Rust returns (99.5).
TypeScript changes the stack to read [4.5, 3, 99.5].

This actually seems like a better design. It minimizes the amount of state passing and gives the stack a clear owner.

Have you tried rewriting this in Rust?

Instead of a State struct, everything in this new implementation is going to be a function. Every function will take in two numbers and return a Result type that will give the result of the numbers undergoing the operation or an error. For operations (+, -, *, /), there will be an operate function that takes in the two numbers and a string matching one of those operations then handing the state back to the TypeScript.

There is only one big problem. And it's one I would have had in the earlier implementation anyway.

The +, -, and * functions in Rust all return primitive types as if their input types are okay, there are no cases in which a primitive number cannot be returned. However, / has one horrific edge case: division by zero. If you are designing Rust, you have to make a choice. Either the / function is the only function that returns a Result or Option type, or the function panics if division by zero is attempted and the return type is primitive which matches the other functions ergonomically.

In the former case, handling division would be a whole mess:

//                                 Type
let a = 2                       // i32
let b = 0                       // i32

let added = 2 + 0               // i32
let subtracted = 2 - 0          // i32
let multiplied = 2 * 0          // i32
let divided = 2 / 0             // Err

match divided {
    Ok(quotient) => quotient,   // i32 (or some float maybe)
    Err(message) => message,    // String
}

I mean, what? You want to unpack the quotient every time you divide? I think they made the right decision that if you try to divide by zero, division panics!. However, I don't know what this will do across the Wasm boundary. Here is one way I could solve it:

/// Perform the operation
#[wasm_bindgen]
pub fn operate(a: f64, b: f64, operation: String) -> Result<f64, String> {
    match &operation[..] {
        "+" => Ok(a + b),
        "-" => Ok(a - b),
        "*" => Ok(a * b),
        "/" => divide(a, b),
        _ => Err(format!(
            "Operation string `{}` does not match any allowed operation (+, -, *, /)",
            &operation[..]
        )),
    }
}

fn divide(a: f64, b: f64) -> Result<f64, String> {
    // Preemptively catch the division by zero panic case.
    // See documentation for [Div](https://doc.rust-lang.org/std/ops/trait.Div.html)
    match b {
        0.0 => Err(String::from("Division by zero is not ok.")),
        _ => Ok(a / b),
    }
}

Except matching on a float won't be possible in future versions of Rust. This code, on compilation gives the error:

warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
note: for more information, see issue #41620 <https://github.com/rust-lang/rust/issues/41620>

Wrap Up

I don't want to write code that won't work one day, so I'm not going to. Instead, I will need to figure out how to handle the panic! and pass back an Err to Vue. For now, I opened up this topic on the Rust-lang forum and am hoping someone is nice enough to help me out.

Starting Commit: dfa42833e39afbf33fc202581dc0564321dff15f

Ending Commit: 8da99f691e0b0bb50486b7bdeb348b1a8df8b1c4

Luka 03 - See. Assess.

Thomas Eckert — Wed, 11 Sep 2019 15:40:07 +0000

This post is part of a series on the development of a reverse polish notation calculator web-app using Rust/Wasm, Vue, and TypeScript. You can read more and follow along with development at the GitHub Repo.

Button++

One button is good, but does not a calculator make. It's time to add components for ButtonPush and ButtonNumber.

Before starting that, I am just going to change the page title in the base HTML to Luka. I want to make a cool favicon too, but that can wait until I have the design and color scheme nailed down.

I moved the three button components into a directory called buttons.

buttons
|- ButtonNumber.vue
|- ButtonOperation.vue
|- ButtonPush.vue

There are likely to be more of them and I want anyone coming to this project to be able to find any part of the code they need to change. The button components are all similar, that will change as I give them behavior. I made some changes to the layout and added colors that I have stolen from TailwindCSS:

The colors here are:

	Default	Hover
Operation	#38B2AC	#319795
Number	#4A5568	#2D3748
Push	#4C51BF	#434190

I am going to set the color scheme for Number to be the default and add styling to make Operation and Push buttons distinct.

The additional styling is set on the component itself. This can be seen in the ButtonPush component here:

<template>
  <button>Push</button>
</template>

<script lang="ts">
import { Component, Prop, Vue } from "vue-property-decorator";

@Component
export default class ButtonPush extends Vue {}
</script>

<style scoped>
:root {
  --button-default: #4c51bf;
  --button-hover: #434190;
}

button {
  background-color: var(--button-default);
}

button:hover {
  background-color: var(--button-hover);
}

button:active {
  background-color: var(--button-default);
}
</style>

The ButtonOperation component is similar.

Separation of Concerns

I iterated on the design from Luka 02, adding the coloring and adjusting the layout a bit. This new design can be separated into several components. First we see the intent of the design without the separation highlighted:

The component separations can be seen here:

The next step is to build these Base components and populate them with buttons.

Now the component structure is

|-App.vue                   implements Calculator
|-components/
| |-Calculator.vue          implements BaseActions, BaseNumbers, BaseOperations, BaseState
| |-bases/
| | |-BaseActions.vue       implements ButtonPush
| | |-BaseNumbers.vue       implements ButtonNumber
| | |-BaseOperations.vue    implements ButtonOperation
| | |-BaseState.vue
| |-buttons/
| | |-ButtonNumber.vue
| | |-ButtonOperation.vue
| | |-ButtonPush.vue

I'm going to start with the BaseNumbers which is going to have a 3x4 grid.

Ok, not a bad start:

There is definitely a slicker way to iterate through the numbers to draw them all to the screen, but what I have works for now.

A Colorful CSS Mistake

Here is something worth investigating. I added ButtonOperation components to the BaseOperations component and that component to the Calculator. It drew the buttons in the app, but they still have the base button color!

This kind of investigating comes up in writing software all the time. Let's dig in.

The problem could come about because I am defining the new colors in a root: on the component. One good way of finding the source of problems is shortening the path between two points in the system. Here, instead of defining the color as a variable, then setting it from that variable, I'll just directly set it.

That fixed it:

This CSS did not work:

:root {
  --button-default: #38b2ac;
  --button-hover: #319795;
}

button {
  background-color: var(--button-default);
}

button:hover {
  background-color: var(--button-hover);
}

button:active {
  background-color: var(--button-default);
}

This CSS did work:

button {
  background-color: #38b2ac;
}

button:hover {
  background-color: #319795;
}

button:active {
  background-color: #38b2ac;
}

The problem being that I was setting the root: within a scoped CSS Vue styling component. I might do more research on it later, but from an understanding of what it would mean to be scoped, it makes sense that I cannot put root: within something that is scoped, it would never reach the "top" of the CSS hierarchy. Maybe that's not the right way to say it. Hopefully my point comes across.

I have two ways I could still do this using a variable-type syntax. One is to use SCSS in the scoped CSS component and set the variables as SCSS variables. The other is to set all color variables in a root: in main.css.

I like the latter option because it gives future maintainers a single file to change the color of every button in the UI.

The main.css now contains the definition for every button color. When I add more buttons/functionality, I'll put the colors here too:

:root {
    --button-default: #4A5568;
    --button-default-hover: #2D3748;
    --button-operation: #38b2ac;
    --button-operation-hover: #319795;
    --button-push: #4c51bf;
    --button-push-hover: #434190;
    --shadow: 0 4px 6px -1px rgba(0, 0, 0, .1), 0 2px 4px -1px rgba(0, 0, 0, .06);
}

button {
    text-align: center;
    font-weight: 700;
    border-color: transparent;
    border-radius: 0.25rem;
    flex-shrink: 0;
    justify-content: center;
    cursor: pointer;
    color: #fff;
    background-color: var(--button-default);
    padding: 0.5rem 1rem;
    margin: 1rem;
    box-shadow: var(--shadow);
    transition: background-color 80ms linear;
}

button:hover {
    background-color: var(--button-default-hover);
}

button:active {
    background-color: var(--button-default);
}

Then the components call to these variables from their styles, for instance, the ButtonOperation style is

button {
  background-color: var(--button-operation);
}

button:hover {
  background-color: var(--button-operation-hover);
}

button:active {
  background-color: var(--button-operation);
}

And that works! (I almost took another screenshot to show below, but it just looks the same as it does above -- which was what I was going for -- so success!)

One Last Button and Some Fake State to go with it

Adding the BaseActions and ButtonPush components is much the same process. The buttons are not on the grid yet, I will fix that later.

The BaseState component is different from the other Base* components, because I am going to pass data to it. This might be a good time to talk about how I plan to structure the state handling in the Calculator component and how I'm thinking about component interaction as a whole.

Each Button* component will affect the state in some way. Rather than that component changing state directly or communicating to Wasm to do calculations, I'm going to route all state-changing operations through the Calculator component. Here is an example of how I want this to work:

The initial state stack is [2.0, 4.0].
The + button is clicked.
The ButtonOperation component passes "+" to BaseOperations.
BaseOperations passes operate("+") to Calculator
Calculator parses the instruction and passes it to Wasm calculator which passes back the state [6.0].
Calculator passes the state to BaseState which handles rendering it properly.

While the state doesn't have to be handled this way. I think it's just going to be safer to minimized the number of components that can directly change the state (in this case minimized to 1). When I talk about safer, I'm not talking about how the code is necessarily set up if the code were some static, unchanging document. If that were the case, either method would be "safe". But code changes, it is meant to change. Making those changes easier is part of what you learn as a software engineer.

I talked to a mentee recently about how growing as a software engineer is more about growth in wisdom rather than knowledge (though of course they are intertwined). Much of the hard knowledge of programming can easily be Googled. Modern compilers will guide you in the right direction too. Knowing what patterns to use and which to avoid is part of growing as an engineer.

With that said, let's pass some fake state to the BaseState component. Setting an array of numbers called state in Calculator will cause BaseState to update with the last 4 values in that array. As things progress and I give more control to the user, I will need to be thoughtful about this mutable state. If someone were to continually push values onto the stack, they could eventually fill up the memory of the service worker rendering that tab in the browser.

At least with Wasm and Vue, I don't have to worry about an insecure backend. If I were running the Rust portion of this code, holding the state, as a web server there could be potential for compromise by pushing unhandled values into the backend. If I didn't plan for that possibility, I could be in trouble -- more susceptible to DDOS attacks (You will always be susceptible to DDOS attacks. It's just a matter of making the attack hard enough to pull off.).

Here is the app as it now renders. I am going to merge back into master. I'm also going to delete the add-function-buttons branch that I've been working on. I no longer feel that is a good description of what I'm doing and I need a new name for this "feature".

Wrap Up

I'm not sure what I want to do next. I'll have to sleep on it. Either I'll wire up the Wasm so I can get state from Rust or I'll work on passing the function of the buttons up the stack of Vue components.

Starting Commit: 7a7251ace3a5ed0b4c67f024130fdda5fb5580e7

Ending Commit: 049a205f3a9e4c6cda6f9171a5b071d005b7152c

Luka 02 - Et Teal

Thomas Eckert — Tue, 10 Sep 2019 06:08:45 +0000

This post is part of a series on the development of a reverse polish notation calculator web-app using Rust/Wasm, Vue, and TypeScript. You can read more and follow along with development at the GitHub Repo.

Let's add some buttons. For this iteration, I want to have a UI that can display the state I created in Luka 01, 10 number buttons, and a button for each arithmetic function.

It doesn't need to start off too pretty, here is the layout I made in Figma on the bus while listening to The Killers:

I can group the buttons into three types: the number buttons (0 through 9) append to the right side of the string that is presented in the "display", the function buttons each call the operate function on the Rust side with the string of the button's label, and the push button which will call the push function on the Rust side. I'm going to eventually want each of these to be a different color which will help a user visually parse what they can do, but for now, they can all take the same CSS and I'll differentiate the colors by applying classes.

There is a lot of code I ripped out of the default Vue template -- more than would be worth noting here. I also added a reference to the main.css file that I am using to style the whole application.

The base App.vue implements a CalculatorBase.vue component which will hold all of the components that make up the calculator. I created a component called ButtonOperation.vue and put a button on it.

Voila! We're almost done!

I gave the button the following styling:

:root {
    --teal-dark: #319795;
    --teal-light: #38b2ac;
    --shadow: 0 4px 6px -1px rgba(0, 0, 0, .1), 0 2px 4px -1px rgba(0, 0, 0, .06);
}

html {
    font-size: 16px;
}

button {
    text-align: center;
    font-weight: 700;
    border-color: transparent;
    border-radius: 0.25rem;
    flex-shrink: 0;
    justify-content: center;
    cursor: pointer;
    color: #fff;
    background-color: var(--teal-light);
    padding: 0.5rem 1rem;
    margin: 1rem;
    box-shadow: var(--shadow);
    transition: background-color 80ms linear;
}

button:hover {
    background-color: var(--teal-dark);
}

button:active {
    background-color: var(--teal-light);
}

And now the button is teal. When hovered, it will turn a darker shade of teal over the course of 80ms. When clicked, it will immediately jump to the light teal again.

Wrap Up

I wanted to do more today, but for now I have a teal button deployed. Go to https://lukarpn.z14.web.core.windows.net if you want to enjoy clicking on it.

Starting Commit: f37109bf4b7b3d22ef0b54785f9104f453d3c8c4

Ending Commit: d712b197986e3279dc76c22baeb31fbeabad0b4c

Luka 01 - Mathing Around in Rust

Thomas Eckert — Mon, 09 Sep 2019 18:32:55 +0000

This post is part of a series on the development of a reverse polish notation calculator web-app using Rust/Wasm, Vue, and TypeScript. You can read more and follow along with development at the GitHub Repo.

Branching Off

With the deployment pipeline set up from Luka 00, any push to the master branch will kick off a new build/deploy instance and update the live website. That's great! But also I don't want to break it.

The solution here is to create a new git branch, in this case I'll call it dev. I can push code to this branch without setting off the pipeline. Taking this a step further, I will create a branch from dev called add-rust-four-functions and use that branch to create the first four functions for the calculator: +, -, *, /.

Then, when that work is done, I'll make a pull request to dev, then a pull request to master. I'll be reviewing my own code with each pull request, usually there is someone else who will approve the code review. Seems silly in certain ways and probably alien to some devs, but I like this model because it forces some level of reasonable caution around production.

All work will follow this branching pattern:

This is a good time to note that I steal a lot of the color pallets for quick images like the one above from flatuicolors.com. They have done the hard work of finding which colors go together well.

Rusty on Arithmetic

Now I can write some code! On the add-rust-four-functions, I created a library in Rust using cargo new calculator --lib. For now, I'm going to call this library calculator because it will do all the calculations for the project.

The model I'm thinking of using -- that I'm pretty sure will work is to have a stack object with methods that change the state of the stack and return its whole state. If I was writing the entire project in Rust, I wouldn't use this model, but I like the idea of just having this "functional" interface so the TypeScript only needs to directly query for the state of the stack once (when it's initialized).

If I find later on that this isn't the right model, I'll change it.

The default lib.rs created by Cargo has a single test:

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

I'll keep this testing module for now, but above it start creating the stack. While I'm writing I just have this document and lib.rs open in VS Code and I'm flipping back and forth. I feel some trepidation calling this just "stack". A stack is a known part of computer science and I might be suggesting features of the objects this struct generates that create a false impression.

With that in mind, I am actually going to call this State and have it contain an object called stack. The struct is

/// # State
/// 
/// Contains every value on the reverse polish notation calculator stack.
pub struct State {
    /// State handling for the "stack" uses a Vec that is treated as a stack.
    pub stack: Vec<f64>,
}

One of the things I love about Rust is the ability to document the code in Markdown and generate documentation from that.

The first thing to implement is a new function. This is a common paradigm in Rust to have the first trait (think methods) be a function called new that returns an instance of the struct. Here, I am initializing the object with four zeroes in the stack. I'm not totally sure if this is what I will end up doing, but it's a start.

impl State {
    /// Creates a new instance of `State` with a stack of 4 zeros.
    pub fn new() -> State {
        State {
            stack: vec![0.0, 0.0, 0.0, 0.0],
        }
    }
}

Worth noting if you are unfamiliar with Rust is that a function will return the value on the last line if that line does not end in a semicolon. For example,
fn add(a: i32, b: i32) -> i32 {
    return a + b;
}
is the same as
fn add(a: i32, b: i32) -> i32 {
    a + b
}

Now I'm going to replace the default test in lib.rs with a test called it_initializes:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_initializes() {
        let _ = State::new();
    }
}

✅ The test passes!

I feel kind of uncertain about this next part. I'm going to try a "functional-ish" approach where each instance of State has functions that consume the State and produce a new instance of State with the appropriate change made. This is done so that every trait returns a State object without having a bunch of mutable state running around. I honestly don't know if it's the right choice, but I am going to try it and see what happens.

The first example of this design can be seen with the push trait:

impl State {

    ...

    /// Pushes `value` to `State.stack` then creates a new instance of `State`
    /// using the appended to `stack`
    pub fn push(mut self, value: f64) -> State {
        self.stack.push(value);
        State { stack: self.stack }
    }
}

I really wish I could append to the stack and create the new State in the same line. If Vec<>.push() returned the values in the Vec<> I could have written State { stack: self.stack.push(value) }, but the designers of Rust are smart. I would assume there is a good reason they didn't implement it that way.

A new trait calls for a new test:

#[cfg(test)]
mod tests {
    use super::*;

    ...

    #[test]
    fn it_pushes() {
        // Given
        let expected_stack = vec![3.14159];
        let pushed_value = 3.14159;

        // When
        let state = State { stack: vec![] };
        let state_prime = state.push(pushed_value);

        // Then
        assert_eq!(expected_stack, state_prime.stack);
    }
}

✅ The test passes!

Here I am using the given, when, then model of testing which I really like. Martin Fowler explains it well here.

For the four functions +, -, *, /. I am going to have a single function called operate. It performs the operation passed to it on the last two values in the stack. I'm going to expect Wasm to pass a string from TypeScript to Rust and I'll have Rust interpret that into a operation with a match statement.

If this project were all Rust, maybe I would have this trait take a function and use that, but I'll settle for this for now. If the trait is unable to match the string to a function, it will just return the state as it was before. Failing quietly like this is not my usual M.O., but I think it makes sense with this UI where crashing in some unexpected way might be worse. If the Rust can't make sense of what it's being asked to do, it'll just shrug and give back the last thing it knows about.

impl State {

    ...

    /// Perform the operation passed as string on the last two values in the `stack`.  
    /// Expects a string matching one of the following: `+`, `-`, `*`, `/`.
    /// If a string is passed that doesn't match, the function will
    /// return the `State` unchanged.
    ///
    /// > The trait takes a `&str` to process operations from TypeScript,
    /// through Wasm, by passing operations as a TypeScript `string`.
    ///
    pub fn operate(mut self, operation: &str) -> State {
        // Remove the last two values from `stack`
        let z = self.stack.pop().unwrap();
        let y = self.stack.pop().unwrap();

        // Return a `Vec<f64>` with the matching operation performed.
        let mut stack_tail = match operation {
            "+" => vec![y + z],
            "-" => vec![y - z],
            "*" => vec![y * z],
            "/" => vec![y / z],
            _ => vec![y, z],
        };
        // Return a new instance of `State` with `stack_tail` appended.
        self.stack.append(&mut stack_tail);
        State { stack: self.stack }
    }
}

There are five paths through this function. I'll need to write at least five tests. Match statements, like switch statements, create several branches that must be tested.

Writing the function in the given, when, then model saves me a lot of time here. For each function, I only need to change the values of expected_stack and operation.

#[cfg(test)]
mod tests {
    use super::*;

    ...

    #[test]
    fn it_adds() {
        // Given
        let expected_stack = vec![6.0];
        let operation = "+";

        // When
        let state = State {
            stack: vec![2.0, 4.0],
        };
        let state_prime = state.operate(operation);

        // Then
        assert_eq!(expected_stack, state_prime.stack);
    }
}

✅ The tests pass!

Wrap Up

Now, with those functions added, I feel comfortable merging this branch back into dev, then back to master. It won't change anything apparent on the front end, but the new Rust code will be up there floating in blob storage.

Starting Commit: 70feecdd8f9a4c645e5847da8382dcd58947344e

Ending Commit: f37109bf4b7b3d22ef0b54785f9104f453d3c8c4

The next step is to create a basic UI that can call these functions.

Luka 00 - Intent and Deployment

Thomas Eckert — Sun, 08 Sep 2019 17:09:21 +0000

This post is part of a series on the development of a reverse polish notation calculator web-app using Rust/Wasm, Vue, and TypeScript. You can read more and follow along with development at the GitHub Repo.

I have been thinking about this project for a few weeks - ever since I was on the train back from RustConf. I did a tutorial on WASM and Rust. This One. I was inspired to dig more into using WASM (wasm? WAsm?).

When I was learning React, I made a reverse polish notation calculator (RPN). You can see that project here. It's ok. This project is a new attempt at that project, but seeking to improve the following:

Greater mathematical precision: in the original, (sqrt(2))^2 == 2.0000000000000004, this is not true. I think that I can use the greater precision of Rust to get better mathematical precision. (I think...) The intent here is to use Rust to generate WASM that does the calculation and passes the result back to the JavaScript to render in Vue. The WASM code will generate functions that I can call from JavaScript.
Grown-up CSS: There's nothing wrong with Bootstrap. The original project used Bootstrap. Since working on that project I have learned CSS Grid and how to really style webpages. I want to do that for the purpose of practice, creating a more unique design, and shrinking the footprint of the site.
Learning!: I want to learn more about Rust, Vue, TypeScript, CSS, and WASM. That is the main driver.

As for these logs, the goal is to show how projects like this progress. It's not linear and I will make mistakes. I hope I can help others learn by making interesting mistakes.

I want to start off by just having an endpoint for deployment. I'm going with Azure to be on brand. I know how to deploy a Vue app to Azure -- it's a static website. I don't know if that changes with the added WASM. That is one of the questions this project will answer.

Before deployment, I will need at least something to deploy. Let's make a Vue app!

Making a Vue App

I want to keep all the code together nicely, but that always shifts around in the early stages of a project. I am debating having a directory called src at the root or calling it luka. I'm not sure which is clearer. Is the project the whole of the repository, including the log, etc, or is it just what is in the directory.

For now, I'll just call it src.

In the newly created src directory, run vue create . (I'll admit I had to Google it). I created this project with Babel, TS, PWA, CSS Pre-processors, and the Linter.

I have found TypeScript to save me so many times. I really enjoy using Vue and TS together.

PWA support is great if people ever one day want to put this on their phones. Who knows.

I am going to try and use class style syntax for this project. As for a CSS pre-processor, I'm using SCSS. If you are unfamiliar with SCSS, it compiles into CSS, but allows for a larger feature-set and can reduce the amount of styling you have to write manually. Here is a pretty good intro to SCSS.

Once the app is generated, I can open it up in a browser with npm run serve.

Great!

Now that I look at it. I feel silly that there is a src directory within my src directory. Maybe I shouldn't. I don't know. Things will probably move around before we're done.

Azure Bound

I work on Azure. That's where I'm going to put this site. I'm just going to follow this tutorial to set it up. One difference between my implementation and his will be that I will be using the newer version of Azure Pipelines that uses YAML for config.

No matter how many times I do it, the first half-dozen builds/deploys I run are broken. I feel bad for those poor deployment agents. Spun up just to install Node dependencies and then fail. Sorry.

Once I cleared up some early errors, I bumped up against this one:

[2019/09/08 05:45:30][ERROR] Error parsing source location "d:\a\1\s\src\dist": Failed to enumerate directory d:\a\1\s\src\dist\ with file pattern *. The system cannot find the path specified. (Exception from HRESULT: 0x80070003) For more details, please type "AzCopy /?:Source" or use verbose option /V.

My YAML for the deploy action was:

- task: AzureFileCopy@3
  inputs:
    SourcePath: 'src/dist'
    azureSubscription: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
    Destination: 'AzureBlob'
    storage: 'lukarpn'
    ContainerName: '$web'

I first thought the problem was arising because I wasn't using the local path. I was referencing a path that didn't exist. I found this by searching "Azure File Copy" and reading the docs to this point on the source. I found I need to use the variable $(Build.Repository.LocalPath) to correctly locate the files to copy.

Ok, so now I tried

- task: AzureFileCopy@3
  inputs:
    SourcePath: '$(Build.Repository.LocalPath)/src/dist'
    azureSubscription: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
    Destination: 'AzureBlob'
    storage: 'lukarpn'
    ContainerName: '$web'

That didn't fix it. In a comment on the tutorial post I found someone else having the same problem. If you:

Use the suggested "Deploy Vue App" default pipeline.
Then try to use Azure File Copy.
You will get an error that Azure File Copy will only work with a Windows build agent.
Then you will change the build agent from the default Ubuntu to Windows.
Except this will create a bug because of how stacked scripts are run in PowerShell (I think...).
The solution is to split the default "npm install and build" task into two:

Original:

- script: |
    cd src
    npm install
    npm run build
  displayName: 'npm install and build'

Fixed:

- script: |
    cd src
    npm install
  displayName: 'npm install'

- script: |
    cd src
    npm run build
  displayName: 'npm build'

That worked!

Mini-Pipeline-Retrospective

What I should have done is created a new in the repo called "add-pipeline" and done all this troubleshooting there, then merged the working pipeline into "master". I didn't. I have learned for next project. At least there's no one else on this project I can annoy with this bad git hygiene.

Looking at the series of pipeline failures that led to this success, I feel this experiment has increased the entropy of the Universe already too much:

But at least I can now see that the files are uploaded to Azure:

Further evidence of success is found by visiting the public endpoint for the blob: https://lukarpn.z14.web.core.windows.net/. The site is live!

Wrap Up

This is a fine starting point for the project. The next step is to develop a simple design, implement it in Vue, and create the backing Rust to support it.

Starting Commit: 7150dfb09421aff8a2f9312070d7415ac94d2aaf

Ending Commit: f7a706313f158a301f71d29c5a0ccf1c6b7ec8bc

Roll Your Own Color Scheme in Windows Terminal

Thomas Eckert — Tue, 25 Jun 2019 20:52:18 +0000

🚩 Disclaimer: I work for Microsoft. I am writing this purely as a fan of Windows Terminal.
Also posted on my blog.

At Build 2019, Microsoft announced an open source terminal for Windows. On 21 June 2019, it became available for preview in the Microsoft Store. I have been playing with it since and while its features are laudable, every developer knows the most important aspect of a terminal is its color scheme.

Luckily, it's easy to write your own. From the Windows Terminal, select the dropdown at the right edge of the tabs. Select Settings. Alternatively, the default keybinding for accessing settings is Ctrl+,.

This will open up a JSON file with the settings for your Terminal in the default editor.

Navigate to the "schemes" key. Here a list of JSON objects map standard Unix terminal colors (except for magenta which is called purple) to HEX codes. Copy an existing scheme and paste it into this list. Now, you can edit the colors as you like. I chose to implement a color scheme from flatuicolors.com called V1. You can find the implementation in a Gist here.

Give your scheme a unique "name" value and set the "profiles" to use that scheme.

As you edit the scheme, the Terminal will update in real time. To check your scheme, I have found the following bash command useful:

for x in {0..8}; do for i in {30..37}; do for a in {40..47}; do echo -ne "\e[$x;$i;$a""m\\\e[$x;$i;$a""m\e[0;37;40m "; done; echo; done; done; echo ""

This will display every text color on every highlight color. I used it to create this sample for the Gist:

Happy hacking!

Encryption and Decryption with Python Azure Functions

Thomas Eckert — Wed, 12 Jun 2019 18:19:28 +0000

Inspired by Section 1.3 of David Kopec's "Classic Computer Science Problems in Python"

Source Code for this article on GitHub.

Let's build two Azure Functions, both HTTP triggers. One to encrypt a message, the other to decrypt it. Fair warning that if you are looking for a secure encryption solution, you would be better served in the hands of people smarter than me, but I think there is something useful to learn in working through this problem.

As noted above, the logic used in these examples comes from a book by David Kopec. I was working through it last night and wanted to take this section a little further. I reimplemented the work in Section 1.3 "Unbreakable Encryption" as two Azure Functions. I'll walk you through the process so you can too!

Gather Your Materials

Before you begin, you will need the following:

Create a Virtual Environment

Python Azure Functions App requires that you work within a virtual environment. If you are unfamiliar with using venv, there is a great primer over at RealPython.

Bash (MacOS or Linux)

python3.6 -m venv .env  
source .env/bin/activate

PowerShell or Command Prompt (Windows)

py -3.6 -m venv .env
.\.env\Scripts\activate

Initialize Your Azure Function App

Execute the following command to create a new Function App:

func init encryption_and_decryption

There is now a folder called encryption_and_decryption with the boilerplate code for a Python Azure Function App. If you would like, take some time to open the code in your favorite editor and have a look around.

If you are looking for an editor, I recommend VS Code.

Create the `encrypt` Function

Make sure you are in the encryption_and_decryption directory:

cd encryption_and_decryption

Create the new function using:

func new

At the prompt, choose HTTP trigger. Then name the function encrypt.

Encrypting Input

Open the file encrypt/__init__.py. You should see boilerplate code for an HTTP trigger function. This function will take name as a parameter and return "Hello name!". Let's add code at the bottom of this file that will instead encrypt the name using a random set of token bytes.

from secrets import token_bytes

def random_key(length: int) -> int:
    # returns length random bytes
    key: bytes = token_bytes(length)
    # convert key to bit string
    return int.from_bytes(key, "big")

Next, write a function to use this random key to encrypt name:

from typing import Tuple

def encrypt(name: str) -> Tuple[int, int]:
    # returns (encrypted_name, dummy_key), encrypted by one-time pad
    # encode the name to bytes, then to a bit string
    name_as_bytes: bytes = name.encode()
    name_key: int = int.from_bytes(name_as_bytes, "big")

    # generate a dummy key for encryption
    dummy_key: int = random_key(len(name_as_bytes))

    # encrypt by XOR operation
    encrypted_name: int = name_key ^ dummy_key

    return encrypted_name, dummy_key

Here, you have encoded the name to a number. This is just another way of writing the name data. The data can be translated back from this form. "Thomas", put though this transform is 92807522771315. You can see this in the Python REPL:

>>> name: str = "Thomas"
>>> name_as_bytes: bytes = name.encode()
>>> name_key = int.from_bytes(name_as_bytes, "big")
>>> print(f"name: {name}\nname_as_bytes: {name_as_bytes}\nname_key: {name_key}")
name: Thomas
name_as_bytes: b'Thomas'
name_key: 92807522771315

I can transform it back:

>>> name_again = name_key.to_bytes((name_key.bit_length() + 7) // 8, "big").decode()
>>> print(name_again)
Thomas

You take the int representation of the name, called name_key and perform an exclusive OR (XOR) operation with the random_key int. In Python XOR is done using the ^ character. This operation produces an encrypted form of the input name:

name_key ^ random_key = encrypted_name

Performing the XOR operation again with the random_key will undo the encryption:

encrypted_name ^ random_key = name_key

In a sense, the random_key locks and unlocks name.

Using `encrypt`

Now that you have the encrypt function written, edit the boilerplate code to take the name input, encrypt it and return the encrypted name with the key. Altogether, the code in __init__.py should like like this:

import logging
from secrets import token_bytes
from typing import Tuple


import azure.functions as func


def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info("func: encrypt: request received")

    name = req.params.get("name")
    if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get("name")

    if name:
        # encrypt name
        encrypted_name, dummy_key = encrypt(name)

        response = str({"encrypted_name": encrypted_name, "dummy_key": dummy_key})
        return func.HttpResponse(response)
    else:
        # ask for input if none provided
        return func.HttpResponse(
            "Please pass a name on the query string or in the request body",
            status_code=400,
        )


def random_key(length: int) -> int:
    # returns length random bytes
    key: bytes = token_bytes(length)
    # convert key to bit string
    return int.from_bytes(key, "big")


def encrypt(name: str) -> Tuple[int, int]:
    # return (encrypted_name, dummy_key); encrypted by one-time pad
    # encode the name to bytes, then to a bit string
    name_as_bytes: bytes = name.encode()
    name_key: int = int.from_bytes(name_as_bytes, "big")

    # generate a dummy key for encryption
    dummy_key: int = random_key(len(name_as_bytes))

    # encrypt by XOR operation
    encrypted_name: int = name_key ^ dummy_key

    return encrypted_name, dummy_key

Testing `encrypt`

Make sure you are in the encryption_and_decryption directory and run the Function App with the command:

func host start

The output of this command includes a link to the HTTP endpoint for this function: http://localhost:7071/api/encrypt.

Visiting this URL in a browser will call the Azure Function and you will get the response "Please pass a name on the query string or in the request body". Pass the Function a name parameter by appending ?name=Sophia to the URL so that it reads:

http://localhost:7071/api/encrypt?name=Sophia

You will get a response back that resembles JSON with the encrypted name and dummy key:

{
    "encrypted_name": 191667540651033,
    "dummy_key": 278440108655992
}

Try it out with different names!

Create the `decrypt` function

As you did with the encrypt function, from the command line, execute:

func new

At the prompt, choose HTTP trigger. Then name the function decrypt. You will pass both the encrypted_name and the dummy_key to this Azure Function. It will perform the XOR operation that undoes the encryption.

Decrypting Input

Open the file decrypt/__init__.py. At the bottom of this file, add a function to decrypt

def decrypt(encrypted_name: int, dummy_key: int) -> str:
    # returns XOR of encrypted_name and dummy_key converted to bytes and decoded
    name_key: int = encrypted_name ^ dummy_key
    return name_key.to_bytes((name_key.bit_length() + 7) // 8, "big").decode()

As shown above, performing the XOR operation on the encrypted_name and dummy_key will output the same value as name_key. Then, the function undoes the encoding from int to str.

Note:
In Python 3+, the // operator divides numerator by denominator and returns the quotient as an int, dropping the digits after the decimal.

e.g. 5 // 2 == 2

Using `decrypt`

Edit the boilerplate code to accept two arguments encrypted_name and dummy_key. It should look like this:

import logging

import azure.functions as func


def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info("func: decrypt: request received")

    encrypted_name = req.params.get("encrypted_name")
    dummy_key = req.params.get("dummy_key")
    if not encrypted_name or not dummy_key:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            encrypted_name = req_body.get("encrypted_name")
            dummy_key = req_body.get("dummy_key")

    if encrypted_name and dummy_key:
        name = decrypt(int(encrypted_name), int(dummy_key))

        return func.HttpResponse(f"Hello {name}!")
    else:
        return func.HttpResponse(
            "Please pass a name on the query string or in the request body",
            status_code=400,
        )


def decrypt(encrypted_name: int, dummy_key: int) -> str:
    # returns XOR of encrypted_name and dummy_key converted to bytes and decoded
    name_key: int = encrypted_name ^ dummy_key
    return name_key.to_bytes((name_key.bit_length() + 7) // 8, "big").decode()

Testing `decrypt`

Start the Azure Function App with

func host start

Using the output from the encrypt Azure Function, test the decrypt Function by visiting:

http://localhost:7071/api/decrypt?encrypted_name=133673440856088&dummy_key=47262719615353

This should return "Hello Sophia!".

Try it with your own encrypted values by sending a name to the encrypt endpoint and replacing the values for encrypted_name and dummy_key with the values returned by the Azure Function.

Going Further

Python Azure Functions:

Blog post: Taking a closer look at Python support for Azure Functions
GitHub Repo: Azure Functions Python Worker

The encryption and decryption code comes from David Kopec's Classic Computer Science Problems in Python with the permission of the author.

Logging Python Execution Time with a Decorator

Thomas Eckert — Wed, 05 Jun 2019 20:16:32 +0000

Here is a decorator for logging execution time for a Python function:

from time import time


def print_execution_time(function):
    def timed(*args, **kw):
        time_start = time()
        return_value = function(*args, **kw)
        time_end = time()

        execution_time = time_end - time_start

        arguments = ", ".join(
            [str(arg) for arg in args] + ["{}={}".format(k, kw[k]) for k in kw]
        )

        print(
            "{} ms {}({})".format(
                str(execution_time * 1000), function.__name__, arguments
            )
        )
        return return_value

    return timed


@print_execution_time
def repeat(number, n_repeats=30000):
    return [number for number in range(30000)]


repeat(9)
repeat(20, 40000)
repeat(1, n_repeats=4000)

This will print the execution time in milliseconds and the name of the function run with its arguments:

1.001596450805664 ms repeat(9)
1.0008811950683594 ms repeat(20, 40000)
1.0001659393310547 ms repeat(1, n_repeats=4000)

Basketball for Nerds

Thomas Eckert — Wed, 10 Apr 2019 19:46:25 +0000

Inspired by a question in Gayle Laakmann McDowell's Cracking the Coding Interview.
Also published on my blog.

Let's say a friend challenges you to choose one of two games on the basketball court:

You have one chance to make one shot.
You have three chances to make two or more shots.

You want to win and you know the exact probability of making a shot p. Which game do you have a better chance of winning?

Chance of Winning Game One

This game consists of one chance to make one shot. Because the likelihood of making a shot is known to be p, the chance of winning is also p. Let's write this as

s_1(p) = p

where s_1(p) is the likelihood of winning the first game.

Chance of Winning Game Two

Here, the math gets trickier. Because you must make at least two of the three shots, there are four ways to win this game:

First	Second	Third
🏀	🏀
	🏀	🏀
🏀		🏀
🏀	🏀	🏀

The probability of making all three shots is the probability of making the first shot times making the second shot times making the third shot, p^3.

The probability of making two out of three shots is the probability of making two shots, p^2, times the probability of not making one shot 1 - p. There are three chances for this to happen. So combined, this is 3p^2(1 - p).

We add the probability of making all shots to the probability of making two of three and get

s_2(p) = p^3 + 3p^2(1 - p) = 3p^2 - 2p^3

Playing the Game

Now the time has come to decide which game to play. The chance of winning each game depends upon p, which we recall is the likelihood of making a single shot. Let's write some Python to choose which game to play based on what p is.

To visualize the function, let's use matplotlib and numpy. We run pip install matplotlib and in our code write

import matplotlib.pyplot as plt
import numpy as np

Next, we need a function to calculate the likelihood of winning the first game (a single shot). This function will just return its input, but writing it down as a function will clairify our intent. We also will be more expressive with our naming convention here calling p, single_shot_probability and s_1, one_shot_win_probability.

def one_shot_win_probability(single_shot_probability: float) -> float:
    """
    Calculates the probability of winning a game with one chance to make one shot
    from the probability of making a single shot. 
    """
    return single_shot_probability

Similarly, we write a function for calculating s_2 called two_of_three_shot_win_probability.

def two_of_three_shot_win_probability(single_shot_probability: float) -> float:
    """
    Calculates the probability of winning a game with three chances to make 
    at least two shots from the probability of making a single shot.
    """
    return 3*single_shot_probability**2 - 2*single_shot_probability**3

Now, let's go on a quick tangent about Python. two_of_three_shot_win_probability is a verbose name for a function. Sometimes that's appropriate. I think in a scenario where the intent of these functions is well-known by all programmers in a codebase, this would be too verbose. It is more verbose than I usually write, perhaps in a codebase at a professional arbitrary basketball game probability company the code would look like this:

def win_2_by_3_prob(p):
    # Win if 2/3 shots made.
    return 3*p**2 - 2*p**3

Heck, if you just need the function for one quick thing, you can write it as a lambda:

win2by3 = lambda p : 3*p**2 - 2*p**3

All of three ways to calculate the 2/3 game do the same thing, it's part of the craft of programming to determine how you will write it.

Now that we have functions to calculate the probability of winning either game, we can plot both functions with respect to the likelihood of making a single shot. Let's vary this likelihood from 0 to 1 in steps of 0.01 and plot using matplotlib.

p_range = np.linspace(0, 1, 100)
one_shot_probs = [one_shot_win_probability(p) for p in p_range]
two_by_three_shot_probs = [two_of_three_shot_win_probability(p) for p in p_range]

plt.plot(p_range, one_shot_probs, label="One of One to Win")
plt.plot(p_range, two_by_three_shot_probs, label="Two of Three to Win")
plt.ylabel("Probability of Winning Game")
plt.xlabel("Probability of Making a Single Shot")
plt.legend()
plt.show()

Altogether, we get the code

import matplotlib.pyplot as plt
import numpy as np


def one_shot_win_probability(single_shot_probability: float) -> float:
    """
    Calculates the probability of winning a game with one chance to make one shot
    """
    return single_shot_probability


def two_of_three_shot_win_probability(single_shot_probability: float) -> float:
    """
    Calculates the probability of winning a game with three chances to make 
    at least two shots from the probability of making a single shot.
    """
    return 3 * single_shot_probability ** 2 - 2 * single_shot_probability ** 3


p_range = np.linspace(0, 1, 100)
one_shot_probs = [one_shot_win_probability(p) for p in p_range]
two_by_three_shot_probs = [two_of_three_shot_win_probability(p) for p in p_range]

plt.plot(p_range, one_shot_probs, label="One of One to Win")
plt.plot(p_range, two_by_three_shot_probs, label="Two of Three to Win")
plt.ylabel("Probability of Winning Game")
plt.xlabel("Probability of Making a Single Shot")
plt.legend()
plt.show()

Running this code gives us the plot

We can see that if the probability of making a single shot is less than 0.5, game one is the best bet. If that probability is greater than 0.5, game two is the best. If our probability of making a single shot is exactly 0.5, we have the same chance of winning either game.

So which game will you play?

DEV Community: Thomas Eckert

Changing Directory with a Python Context Manager

Luka 04 - Don't `panic!`

Finding References

Have you tried rewriting this in Rust?

Wrap Up

Luka 03 - See. Assess.

Button++

Separation of Concerns

A Colorful CSS Mistake

One Last Button and Some Fake State to go with it

Wrap Up

Luka 02 - Et Teal

Wrap Up

Luka 01 - Mathing Around in Rust

Branching Off

Rusty on Arithmetic

Wrap Up

Luka 00 - Intent and Deployment

Making a Vue App

Azure Bound

Mini-Pipeline-Retrospective

Wrap Up

Roll Your Own Color Scheme in Windows Terminal

Encryption and Decryption with Python Azure Functions

Gather Your Materials

Create a Virtual Environment

Initialize Your Azure Function App

Create the encrypt Function

Encrypting Input

Using encrypt

Testing encrypt

Create the decrypt function

Decrypting Input

Using decrypt

Testing decrypt

Going Further

Logging Python Execution Time with a Decorator

Basketball for Nerds

Chance of Winning Game One

Chance of Winning Game Two

Playing the Game

Create the `encrypt` Function

Using `encrypt`

Testing `encrypt`

Create the `decrypt` function

Using `decrypt`

Testing `decrypt`