Forem: Aaron Schlesinger

Synchronizing the KEDA HTTP Addon Request Routing Table Across Hundreds of Interceptor Pods

Aaron Schlesinger — Fri, 29 Oct 2021 23:15:58 +0000

The KEDA HTTP Addon project contains three major components: the operator, scaler and interceptor.

Of these, the interceptor is the only component that sits in the critical path of all incoming HTTP requests. We also run them in a fleet that is horizontally scaled by software.

We're going to focus on how we ensure that any interceptor replica can route an incoming request to the correct backing application at any time.

Implications of Multi-Tenancy

The interceptor component is designed to run in a Deployment that KEDA automatically scales. This high-level design has a few implications:

There must be a centralized, durable copy of a lookup table -- called a routing table -- that maps any incoming request to the correct backing Service and port.
All interceptor pods must reliably stay up to date with the central routing table
All interceptor pods must be able to handle any valid incoming request, regardless of application it was intended for
All interceptor pods must be able to quickly execute lookups to the routing table

Keeping up to Date with the Routing Table

Since the interceptor needs to do a lookup to the routing table before forwarding any request (or returning an error code), lookups need to be as fast as possible. That means storing the routing table in memory and keeping each interceptor's in-memory copy up to date with the central copy.

We do this wth a relatively simple event loop, outlined in the below (Go-like) pseudocode:

table = fetch_table_from_kubernetes()
report_alive()
ticker = start_ticker(every_1_second)
for {
    select {
        case new_table <- kubernetes_events_chan:
            table = new_table
        case <-ticker:
            table = fetch_table_from_kubernetes()
    }
}

A few important points to note about this event loop:

On startup, we fetch a complete copy of the routing table from Kubernetes before we report to the Kubernetes liveness probe. This means that Kubernetes doesn't consider any interceptor pod "ready" until it has a complete initial copy of the routing table.
The kubernetes_events_chan receives notifications about changes to the central routing table in near-real time. When we get a change notification, we immediately update the in-memory copy.
The ticker fires a signal every second, at which time we do a full refresh of the routing table. This mechanism ensures that all interceptor replicas receive changes to the routing table within 1 second of the change being made to the central copy.

The Event Loop Pattern in Action

The KEDA HTTP Addon runs a fleet of interceptors and enlists KEDA to actively scale the fleet. This means that as we send more HTTP traffic to the cluster, we expect the interceptors to automatically scale up. This behavior is one of the most important features of the HTTP Addon.

We've built this event loop into the interceptors to ensure that there can be thousands [1] of them running at once, and they all stay up to date with the central routing table -- data that they need to do their job.

[1] As we see in the pseudocode above, each interceptor issues requests to the Kubernetes API, so as we scale them out, we generate more consistent traffic to the cluster API. As you scale further than the low thousands of replicas, you would need to add an intermediate layer of caching between the interceptors and the API to ensure that you don't crash the cluster control plane.

Fan-in / Fan-out with Go

Aaron Schlesinger — Mon, 11 Oct 2021 22:59:27 +0000

Hacking on the KEDA HTTP Addon, I found myself having to do something familiar:

Split some work into N pieces, do them all concurrently, wait for them all to be done, and then merge all the results together.

I've done this a bunch of times before, but this time I forgot how to do it. I took a few minutes away from the computer to gather my thoughts and came back to it. So I don't have to forget how to do it again, I want to write the algorithm down here!

What are we doing here?

First thing's first - we need a problem we can break down into a bunch of pieces. Sometimes it's called an "embarassingly parallel" problem.

Note that concurrency and parallelism aren't equivalent, but I'm going to be using the word "parallel" hereafter because I'm hoping the machine you run this algorithm on will be able to execute the work on different cores simultaneously.

The primary goal here is to run each different piece of the work in a goroutine. That's pretty easy in Go - just put go before the function call that does the work. The tougher part is to get the results of the work, check for errors, and wait for them all to be done -- not necessarrily in that order 🤣.

Even though the concept is simple, there is a big-ish gotcha when the rubber hits the road. Below is some code that does "fake" work, annotated with comments to explain it:

workToDo := []int{"do", "some", "work"}
for idx, work := range workToDo {
    // make sure you pass the index and work into the 
    // function that runs in the goroutine.
    // this mechanism makes sure that the goroutine
    // gets a (stack-allocated) _copy_ of the data.
    // if you don't do this, idx and work will change out
    // from under it as the loop progresses.
    go func(idx int, work string) {
        fmt.Println(idx, work)
    }(idx, work)
}

The biggest gotcha is in that comment inside the for loop.

Waiting for the work to be done

Now that we've got goroutines running with the right parameters, let's add a sync.WaitGroup to the mix. This mechanism will let us wait for all these goroutines to finish.

var wg sync.WaitGroup
workToDo := []int{"do", "some", "work"}
for idx, work := range workToDo {
    // add 1 to the waitgroup _before_ you start the goroutine.
    // you want to do this in the same goroutine as where
    // you call wg.Wait() so that you're sure that, even if
    // none of the goroutines started yet, you have the
    // right number of pending work.
    wg.Add(1)
    // make sure you pass the index and work into the 
    // function that runs in the goroutine.
    // this mechanism makes sure that the goroutine
    // gets a (stack-allocated) _copy_ of the data.
    // if you don't do this, idx and work will change out
    // from under it as the loop progresses.
    go func(idx int, work string) {
        // wg.Done() tells the WaitGroup that we're done in
        // this goroutine. In other words, it decrements
        // the internal WaitGroup counter, whereas wg.Add(1)
        // above increments it.
        // Most commonly, we just do this in a defer statement.
        defer wg.Done()
        // this is the "work". in the next section, we'll be
        // changing this to return a value, because we'll
        // need to send that value somewhere
        fmt.Println(idx, work)
    }(idx, work)
}
// wait for all the goroutines to finish. this call
// blocks until the WaitGroup's internal count goes 
// to zero
wg.Wait()

Getting the results

So, now we know when all the work is done, we need to get the results. There are two kinds of results we need to get - the actual values of the work we're doing -- we'll call this the "success value" -- and the errors that it might have returned.

Let's focus on the success values first. We're going to use one group of channels, one "final" channel, and a clever way of shuttling data between the former and the latter:

Read this code on the Go Playground, if you prefer

// this is the channel that will hold the results of the work
resultCh := make(chan string)
var wg sync.WaitGroup
workToDo := []string{"do", "some", "work"}
for idx, work := range workToDo {
    // add 1 to the waitgroup _before_ you start the goroutine.
    // you want to do this in the same goroutine as where
    // you call wg.Wait() so that you're sure that, even if
    // none of the goroutines started yet, you have the
    // right number of pending work.
    wg.Add(1)
    // this is the loop-local channel that our first goroutine
    // will send its results to. we'll start up a second
    // goroutine to forward its results to the final channel.
    ch := make(chan string)
    // make sure you pass the index and work into the
    // function that runs in the goroutine.
    // this mechanism makes sure that the goroutine
    // gets a (stack-allocated) _copy_ of the data.
    // if you don't do this, idx and work will change out
    // from under it as the loop progresses.
    go func(idx int, work string) {
        // this is the "work". right now, it just returns an
        // int. in the next section, it will return both an int
        // and an error
        res := doSomeWork(idx, work)
        ch <- res
    }(idx, work)
    // start up another goroutine to forward the results from
    // ch to resultCh
    go func() {
        // we want to indicate that we're done after we forward
        // the result to the final channel, _not_ just when we're
        // done with the actual computation. this arrangement
        // will be useful below, in our final goroutine that
        // runs after the for loop is done
        defer wg.Done()
        res := <-ch
        resultCh <- res
    }()
}
// start up a final goroutine that is going to watch for
// the moment when all of the loop goroutines are both
//
// 1. done with their work
// 2. done sending their results to the final channel
//
// after that, we can close the resultCh. this closure is
// important for the following for loop, since ranging over
// a channel will only stop after that channel is closed
go func() {
    wg.Wait()
    close(resultCh)
}()

// now that we have that final goroutine running, we can
// be sure that this for loop will end after:
//
// 1. all goroutines are done with their work
// 2. all goroutines are done sending their work to resultCh
// 3. we have processed each result
//  (in this case, we just print it out)
for result := range resultCh {
    fmt.Println("result:", result)
}

The code is extensively commented, but notice a few more "meta" things about it:

We're enlisting another goroutine for each loop iteration, so now we're using 2N goroutines rather than N (where N is the number of work items to do).
- If you're worried about the extra goroutines, remember that a Go program can run hundreds of thousands of them comfortably on a relatively modern laptop. Plan accordingly with that in mind.
We use one extra final goroutine to determine when the final goroutine should be closed
We no longer use wg.Wait() in the main goroutine. Instead, we range over resultCh to both get the results and determine when all the work items are done.

A final wrinkle: error handling

Now that you (hopefully) have a decent grasp over the code in the previous section, consider that, for most workloads, you'll also have to deal with error handling. It doesn't take a lot of additional code to do it, but it does add a bit more complexity. Let's see how it works:

Read this code on the Go Playground, if you prefer

Note that you can reduce complexity by using the errgroup package. The code herein implements functionality similar to that of errgroup.

// this is the channel that will hold the results of the work
resultCh := make(chan string)
// this channel receives all the errors that occur.
// for each work item, either resultCh or errCh will receive
// precisely once. both channels will be closed immediately
// after all receives happen
errCh := make(chan error)
var wg sync.WaitGroup
workToDo := []string{"do", "some", "work"}
for idx, work := range workToDo {
    // add 1 to the waitgroup _before_ you start the goroutine.
    // you want to do this in the same goroutine as where
    // you call wg.Wait() so that you're sure that, even if
    // none of the goroutines started yet, you have the
    // right number of pending work.
    wg.Add(1)
    // this is the loop-local channel that our first goroutine
    // will send its results to. we'll start up a second
    // goroutine to forward its results to the final channel.
    ch := make(chan string)
    // this is the loop-local channel that our first goroutine
    // will send errors on. for each loop iteration, exactly
    // one of ch or errCh will receive
    eCh := make(chan error)
    // make sure you pass the index and work into the
    // function that runs in the goroutine.
    // this mechanism makes sure that the goroutine
    // gets a (stack-allocated) _copy_ of the data.
    // if you don't do this, idx and work will change out
    // from under it as the loop progresses.
    go func(idx int, work string) {
        // this is the "work". right now, it just returns an
        // int. in the next section, it will return both an int
        // and an error
        res, err := doSomeWork(idx, work)
        if err != nil {
            eCh <- err
        } else {
            ch <- res
        }
    }(idx, work)
    // start up another goroutine to forward the results from:
    //
    // - ch to resultCh
    // - eCh to errCh
    go func() {
        // we want to indicate that we're done after we do the
        // forward operation, similar to the code in the
        // previous section
        defer wg.Done()
        // only one forward operation will happen per loop
        // iteration, so we use a select to choose exactly
        // one of the channels - either the success or error
        // one.
        select {
            case res := <-ch:
                resultCh <- res
            case err := <-eCh:
                errCh <- err
        }
    }()
}
// start up a final goroutine that is going to watch for
// the moment when all of the loop goroutines are both
//
// 1. done with their work
// 2. done sending their results to the appropriate channel
//
// after that, we can close both resultCh and errCh.
go func() {
    wg.Wait()
    close(resultCh)
    close(errCh)
}()

// we're now at a point where we have two "final" channels:
//
// - one for the successful results
// - one for the errors
//
// we have a few choices on how to handle them, and it's
// largely up to your use case how you handle errors or success
// results. In our case, we'll loop through both channels,
// print out the result either way, and then exit when all
// receives happen.

// these two booleans are going to keep track of when 
// each channel is closed and done receiving
resultsDone := false
errsDone := false
// we're going to use an infinite loop and break out of it
// when both channels are done receiving
for {
    if resultsDone && errsDone {
        break
    }
    select {
    case res, valid := <-resultCh:
        if !valid {
            resultsDone = true
        } else {
            fmt.Println("result:", res)
        }
    case err, valid := <-errCh:
        if !valid {
            errsDone = true
        } else {
            fmt.Println("error:", err)
        }
    }
}

A few more things to note here:

We've handled errors and success values with equal importance. In many cases, you might want to immediately exit if you see an error. In that case, make sure that you find a way to receive the rest of the errors and success values on errCh and resultCh (respectively), or tell the remaining goroutines to exit.
- If you intend to do the latter, I highly recommend using context
There is a lot of code here! And for that reason, it's worth repeating that you can reduce complexity by using the errgroup package.
The primary source of complexity is the parallelism (that's the reason this blog post exists!) If you're thinking of using this pattern, I encourage you to measure the serial (non-parallel) version of the algorithm first to determine whether you really need to take on this complexity

Next Steps for KEDA HTTP

Aaron Schlesinger — Wed, 09 Dec 2020 20:41:25 +0000

I recently wrote about a new project I'm starting in the Kubernetes world. Its overarching goal is to build an open source, app developer friendly system built on top of Kubernetes. Since then, there has been a lot of interest and a few developments that I'm excited about.

Technical Reference and Proposal Document

Along with the GitHub issue that started the project, there is now a proposal and technical overview of the system. Like most proposals, this document will serve as the proposal submitted to the KEDA maintainers and also as a reference document that the project will build against.

Included in this document is an overview of all the components in the system, an architectural diagram of how they're assembled, and a discussion of the extensibility of the system [1].

Acceptance to the KEDA Organization

The proposal has been accepted and a new repository under the KEDA organization to house these components.

This development is important because the people and the idea now have the support [2] of the KEDA organization and a wider discussion has been started around the direction and featureset. We also have a wider team of developers that have joined to contribute.

What's Next

I'm pleased with the direction of this project and looking forward to the next few months. Things are moving very quickly in the new repository. I did a pairing session yesterday with coworkers in which we completed the entire serving and metrics infrastructure [3], and the next component on deck is the operator [4].

If you're interested in seeing this component progress -- along with the project at-large -- I live code it on Twitch 2-3 times per week. I encourage you to tune in and ask questions/leave comments in the chat.

Contributing

We're not yet ready for contributions from the community at-large. We have two major tasks to complete before we'll be open for contributions from the at-large community.

First, we need to finish the minimal infrastructure. The components and supporting artifacts (Helm charts, CI scripts, etc...) are being built in PR #2, and once we have them completed, we will merge it [5]. Second, we need to establish a roadmap. We're beginning to outline it now and will finish it shortly after merging.

We believe that when these two tasks are complete, the project will have an established foundation and be well situated to accept contributions and support a larger community.

I along with others will broadcast when we're ready to welcome the wider community.

[1] In addition to the discussion in there, I've had more concrete discussions elsewhere about extensibility. Most of them are around alternative levels of abstraction that this system could support. The given architecture is highly extensible, and after this particular abstraction is built, we'll explore others.

[2] The word "support" has different implications in different open source projects and communities. In this case, I mean that there is a repository created and the general idea to support HTTP based autoscaling is on the roadmap of the larger KEDA project.

[3] We based much of our code on the prototype codebase

[4] This component is notable because it's being implemented in Rust. The decision to do so was inspired by my former colleagues in the Deis Labs group at Microsoft. They are innovating in significant ways in the Cloud Native community.

[5] Depending on how we progress, we may create and merge multiple PRs.

Deploying Apps With KEDA-HTTP

Aaron Schlesinger — Tue, 24 Nov 2020 01:22:57 +0000

When you search for "what is Kubernetes?", content abounds with technical details of the system. There's less about what Kubernetes is at a high level. Here's my attempt at that in two sentences:

Kubernetes is an operating system for your cluster of computers. Like any OS, you get a syscall API for CPU, memory, networking, storage and more, and build abstractions from there.

If you're new to Kubernetes, let those two sentences sink in before you move on. And if you're an app developer trying to deploy to Kubernetes, remember the things you're not implementing: an HTTP server/router, a database driver, a JSON parser, and so on. You're using abstractions. Kubernetes should be no different.

App Developers on the Web

I'm using the term "app developer" in a very imprecise way; that's on purpose. I'm not out to define what this group developers does or is, I'm out to assert the tasks they shouldn't have to do while building their app. Developers should not have to understand details of virtual machines, the Kubelet, Pods/Deployments/Services/etc..., or kubectl [0]. They also shouldn't need to deal with Helm charts or watch Kubernetes dashboards after a deploy [1].

In other words, they shouldn't have to know a distributed syscall API to accomplish everyday deployment and management tasks. Kubernetes is a robust platform on which to run web applications, not an adequate experience for web developers to deploy them.

A Better Experience

In 2015, Rob Pike gave a talk at dotGo entitled "Simplicity is Complicated". Referring to the Go language, he explained that while Go is simple for developers, the code that provides that simplicity is very complex. Indeed, the Go standard library provides a very simple and flexible API to access underlying system resources.

Kubernetes is the underlying system. The task we have now is (a) defining what a simple and flexible interface needs to look like, and (b) implementing it.

Many cloud providers have relevant products we can draw inspiration from [2]. While these platforms are diverse, most or all of them share roughly the following features.

You focus on running your code, not underlying resources like VMs, containers, VNets and so forth
Your app can automatically scale up and down based on demand
A CLI is available to deploy your code to production with a command
Your app can built in the cloud, instead of your computer
It's easy to connect your code to other databases and other cloud services
You can opt in to advanced features like gradual rollouts and more

Kubernetes has the foundational technologies to build these features and more. Our challenge is to choose the right ones, manage the complexity, and expose a simple and flexible abstraction purpose-built for Kubernetes.

KEDA-HTTP

That brings us to KEDA-HTTP, a new project I'm starting. I'm building KEDA-HTTP to bring Kubernetes closer to app developers plain and simple. Knowing approximately what a good platform looks like, the technical details matter.

Under the Hood

This project primarily assembles existing building blocks to build the right developer experience [3]:

Standard Kubernetes Deployments, Services and Ingresses and Ingress Controllers for running pods ("compute") and routing HTTP traffic to them
KEDA for scaling Deployments up and down
The operator pattern and Custom Resource Definitions (CRDs) for defining a comprehensive abstraction and API over KEDA and the standard Kubernetes resources

The Future

Kubernetes has democratized distributed systems. Any developer can access lots of distributed primitives over a standard API, but doing so requires understanding large concepts and keeping lots of context in one's head. That requirement alone is a barrier to entry for a lot of people. Further, a large subset of applications don't need some of these primitives [4].

I believe that we know what a simple and flexible interface needs to look like. As I see this system evolve, I'm optimistic that this next level of abstraction will greatly increase the number of developers who can use the technology. Work is ongoing at github.com/osscda/kedahttp and there is a proposal open for adding this technology to the KEDA project.

A small team of my Cloud Advocate peers at Microsoft, the great people in the KEDA project and me are working on this project. We're not quite ready for help, but watch the proposal issue for progress. We'll be slowly modularizing the codebase and contributing functionality piece by piece into KEDA.

[0] As is the case with every abstraction, developers should somewhat understand inner workings.

[1] In many cases, developers also function in SRE or DevOps roles as well. In those situations, they almost certainly would need to use these dashboards to assess the health of their code in production. There is a clear separation of roles or "personas" implied here - the developer writes application code and deploys it to production, while the SRE/DevOps engineer operates it in production.

[2] In no order, with no preference and non-exhaustively, these include App Platform, App Engine, Elastic Beanstalk, Heroku and App Service

[3] Personally, I'm excited about the fact that the project is partially being implemented in Rust. While the language has a reputation for being hard to learn, I believe that the language provides several features that make it well suited for writing Kubernetes components

[4] Such as leader election and distributed leases

First Lines of Rust

Aaron Schlesinger — Thu, 19 Nov 2020 19:41:14 +0000

After ~8 years of Go as the end-all-be-all of programming languages in my life, I started writing Rust code for a real project, not just as a hobby.

The project, briefly put, is a Kubernetes system to let people easily and quickly deploy HTTP-based containers to production with a CLI. There is more to the story than that, but I don't want to stray from what I'm excited about. I'm really learning a new language after all this time, from the ground up [1].

Unlearning Go is Hard

Lots of people come to the Go community and start writing Goava or Gython (Java-like Go or Python-like Go). I usually spend time with many of them helping un-teach that language so that they can absorb Go and build up the cognitive "muscle memory" that they need to be productive in the language.

Now, the tables have turned and I'm experiencing the same thing with Rust. One of the important first steps I've taken is accepting that I will still "know" Go even if I "unlearn" it so I really get productive with Rust. I'll always be a Gopher.

Similarities to Go

As I progress, I'm writing down some cognitive and structural similarities I see in the two languages. That's helping me make the transition from the Go way to the Rust way. Both are modern, systems-oriented programming languages so they view the world similarly and as such, they've landed on a few similar and important features.

Memory Safe

Go uses garbage collection and Rust uses the ownership concept, the borrow checker and (opt-in) reference counting, but both languages give you confidence at compile time that you won't access invalid memory. They also work hard to help you ensure that memory will be cleaned up as expected.

Batteries Included

I was going to entitle this section "Built in Tests", but more is built in than just tests. Both languages ship with almost all of the tools needed to build modern software. Go has the go CLI and Rust has cargo. In both cases, you run an installer to get a built in test framework, extensive standard library, dependency management (in Go 1.9 and up!), and more.

I can't understate the effect these out-of-the-box tools have on the community. Anyone can come to the language, run an installer, and be ready to write production level code. Other language ecosystems make you learn -- and sometimes even choose from -- a wide variety of tools before you write your first line of code. That's a big barrier to entry for someone new to the language and can turn people off.

Both ecosystems do have other tools you can learn, but you can be productive with what comes out of the box.

Errors are Values

One of Go's hallmarks is that "errors are values". In practical terms, that means that there is no exception system and the language makes you check any error that a function might return.

Rust also lacks exceptions, but has a more expressive type system [2]. It usually represents errors using the Result<T, E> type [3]. Many people use match statements to "pull" values out of the Result (you can do it in other ways too), and Rust has an exhaustiveness checker that effectively forces you to check every error.

Panic Only in Unrecoverable Situations

Go has a panic() function and Rust has a panic!() macro. They look almost the same and they have approximately the same purpose; if there is no way to recover and your program can't continue under any circumstances, panic-ing will exit immediately with a stack trace (optionally in Rust).

Polymorphism

Polymorphism is an umbrella term to encompass many features in a programming language and Rust and Go provide a similar subset of them.

In Go, you can create an interface{} that specifies methods that a concrete type can implement. Any concrete type that implements them automatically adheres to that interface, without specifying so. You can use any concrete type where the interface is expected.

Rust has traits, which are very similar. You can define methods in them, and a default implementation for those methods as well (similar to an abstract class in C++).

One big difference in this area is that Rust requires that you explicitly state that a concrete type is implementing a trait. That small difference has a big impact in large codebases because with Go, you don't have to add a dependency to your app just to implement one of its interfaces [4].

More?

I'm a month or so into building this app and becoming more productive by the day. I've been writing Go for a long time and I'll naturally draw more parallels to Rust as I progress. So far, I'm enjoying the process and looking forward to the future 🚀.

[1] I've learned a few languages ad-hoc over the past years, but not from the ground up, and that's why this is exciting for me
[2] Go has plans to add generics to the language soon, but the proposed design is different from Rust's generics design and it lacks features that Rust has.
[3] Since Result is a regular enum in the standard library, it's only the de-facto standard for error checking; you don't have to use it as such
[4] Go is sometimes credited with allowing "duck typing" for this reason, but the feature is closer to structural typing

async/await: under the hood

Aaron Schlesinger — Tue, 30 Jun 2020 23:15:26 +0000

I'm really interested in concurrency strategies in programming languages, and because there's a lot of written research out there on the topic, you can find lots of strategies out there.

When you look at some of the more modern stuff, you'll find a lot of literature on just about the same pattern: async/await.

async/await is picking up steam in languages because it makes concurrency really easy to see and deal with. Let's look at how it works and why it helps, using Javascript to illustrate the concepts.

I'm a Javascript dabbler at best, but it's a great language to illustrate these concepts with. Don't go too hard on my JS code below 😅

What It's About 🤔

async/await is about writing concurrent code easily, but more importantly, it's about writing the code so it's easy to read.

Solving Concurrency Three Ways 🕒

This pattern relies on a feature called Promises in Javascript, so we're gonna build up from basics to Promises in JS, and cap it off with integrating async/await into Promises.

Promises are called Futures in many other languages/frameworks. Some use both terms! It can be confusing, but the concept is the same. We'll go into details later in this post.

Callbacks 😭

You've probably heard about callbacks in Javascript. If you haven't, they're a programming pattern that lets you schedule work to be done in the future, after something else finishes. Callbacks are also the foundation of what we're talking about here.

The core problem we're solving in this entire article is how to run code after some concurrent work is being done.

The syntax of callbacks is basically passing a function into a function:

function doStuff(callback) {
    // do something
    // now it's done, call the callback
    callback(someStuff)
}

doStuff(function(result) {
    // when doStuff is done doing its thing, it'll pass its result
    // to this function.
    //
    // we don't know when that'll be, just that this function will run.
    //
    // That means that the rest of our ENTIRE PROGRAM needs to go in here
    // (most of the time)
    //
    // Barf, amirite?
    console.log("done with doStuff");
});

// Wait, though... if you put something here ... it'll run right away. It won't wait for doStuff to finish

That last comment in the code is the confusing part. In practice, most apps don't want to continue execution. They want to wait. Callbacks make that difficult to achieve, confusing, and exhausting to write and read 😞.

Promises 🙌

I'll see your callbacks and raise you a Promise! No really, Promises are dressed up callbacks that make things easier to deal with. But you still pass functions to functions and it's still a bit harder than it has to be.

function returnAPromiseYall() {
    // do some stuff!
    return somePromise;
}

// let's call it and get our promise
let myProm = returnAPromiseYall();

// now we have to do some stuff after the promise is ready
myProm.then(function(result) {
    // the result is the variable in the promise that we're waiting for,
    // just like in callback world
    return anotherPromise;
}).then(function(newResult) {
    // We can chain these "then" calls together to build a pipeline of
    // code. So it's a little easier to read, but still. 
    // Passing functions to functions and remembering to write your code inside
    // these "then" calls is sorta tiring
    doMoreStuff(newResult);
});

We got a few small wins:

No more intimidating nested callbacks
This then function implies a pipeline of code. Syntactically and conceptually, that's easier to deal with

But we still have a few sticky problems:

You have to remember to put the rest of your program into a then
You're still passing functions to functions. It still gets tiring to read and write that

async/await 🥇

Alrighty, we're here folks! The Promised land 🎉🥳🍤. We can get rid of passing functions to functions, then, and all that forgetting to put the rest of your program into the then.

All with this 🔥 pattern. Check it:

async function doStuff() {
    // just like the last two examples, return a promise
    return myPromise;
}

// now, behold! we can call it with await
let theResult = await doStuff();

// IN A WORLD, WHERE THERE ARE NO PROMISES ...
// ONLY GUARANTEES
//
// In other words, the value is ready right here!
console.log(`the result is ready: ${theResult}`);

Thanks to the await keyword, we can read the code from top to bottom. This gets translated to something or other under the hood, and what exactly it is depends on the language. In JS land, it's essentially Promises most of the time. The results to us programmers is always the same, though:

Programmers can read/write code from top to bottom, the way we're used to doing it
No passing functions into functions means less }) syntax to ~~forget~~ write
The await keyword can be an indicator that doStuff does something "expensive" (like call a REST API)

What about the `async` keyword⁉

In many languages including JS, you have to mark a function async if it uses await inside of it. There are language-specific reasons to do that, but here are some that you should care about:

To tell the caller that there are Promises or awaits happening inside of it
To tell the runtime (or compiler in other languages) to do its magic behind the scenes to "make it work"™

🏁

And that's it. I left a lot of implementation details out, but it's really important to remember that this pattern exists more for human reasons rather than technical.

You can do all of this stuff with callbacks, but in almost all cases, async/await is going to make your life easier. Enjoy! 👋

How To Make Windows Keyboards Look Like Mac

Aaron Schlesinger — Wed, 17 Jun 2020 22:15:46 +0000

I wrote a bit about PowerToys previously, but today we're gonna talk about my second-favorite feature: the keyboard manager.

My first-favorite feature is Powertoys Run - the spotlight-like feature for Windows. I talked about this one last post.

Make Windows Feel Like Mac 🍏

I switched to Windows from Mac a few months back, and I'm used to just about everything except the keyboard. Muscle memory keeps kicking in and my thumbs reach for the cmd key instead of ctrl. There's no cmd on Windows - it just opens the start menu. I've opened the start menu a lot.

The Keyboard Manager ⌨

The key feature (see what I did there?) of PowerToys that lets my keyboard be all apple-ey is the keyboard manager. It looks like this:

There's a lot going on in that window. Let's break it down...

Remap Keyboard 🗺

This one is simple in theory. Like the heading says, you get to map a single key. Take the first one in there - I mapped Page Up to the home key (that one wasn't Mac specific - I just kept accidentally hitting it 😉).

Here are the keys I remapped to Mac-ify:

Caps Lock => Win (Left)
Win (Left) => Ctrl (Left)

This is basically making the Windows key to the left of the spacebar into the Ctrl key, which does similar things as the Cmd key on a Mac. Since I was overriding the Windows key, I moved that up to Caps Lock, since I never use it anyway. You could also do this with the Windows key on the right, if you have one.

To do these mappings, you click "Remap a Key', then the Plus icon at the bottom. Click on each box and type the keys you want to map. The "before" key goes on the left, and the "after" key on the right.

❗ Do the mapping from Win -> Ctrl last

Remap Shortcuts 🍕

This one piggybacks on key remapping. As you know, Windows has lots of key combinations that "do stuff"™. For example, alt+tab cycles through Windows, alt+tab switches Windows, win+s opens the search menu, win+d shows the desktop, win+e the explorer, and so on.

Here are the shortcuts I set for mac-ifying:

Ctrl (Left) + Tab => Alt (Left) + Tab
- cmd+tab on Mac lets you cycle through Windows. This makes it feel the same. This still has a bug, but it's usable enough for now
Ctrl (Left) + Shift (Left) + [ => Ctrl (Left) + Shift (Left) + Tab
- This lets me cycle through tabs quickly, just like on a Mac. This particular one cycles left.
Win (Right) + Shift (Right) + [ => Ctrl (Left) + Shift + Tab
- Cycle to the left, from the right side of the keyboard
Ctrl (Left) + Shift (Left) + ] => Ctrl (Left) + Tab
- Cycle to the right, from the left side of the keyboard
- Win (Right) + Shift (Right) + ] => Ctrl (Left) + Shift + Tab
- Cycle to the right, from the right side of the keyboard

I hope those help! It's by far not everything to make Windows feel like a mac - some Windows things just don't apply to Mac and vice versa. But I think you'll find this a good setup.

Enjoy!

Storage with Dapr

Aaron Schlesinger — Fri, 29 May 2020 18:36:48 +0000

Dapr! No, not dapper, dapr.

If you haven't read my past articles about dapr, that's ok. Let me try to boil this big project down to a sentence:

👋 Dapr is a process you run that does all the hard stuff for your app you'd rather not do

If you want to read more about it, see the intro blog post.

And with that, let's talk about (and demo!) probably the hardest thing that most (any?) apps have to deal with: storing data.

🙋‍♀️ Dapr does other things besides storage too

Why It Matters

Dealing with data stores is hard. You have to get the right SDK, mock out your data store for unit tests, write integration tests for round-tripping data, make sure you deal with migrations, failover, and more...

Dapr helps with all that, but it also comes with some limitations too. Before we go demo the thing, some pros and cons for storage:

➕ You read/write data with a pretty simple REST API (or gRPC!)
➕ You get a lot of useful features (retries anyone?)
➕ You can swap out implementations (Dapr comes with a bunch of different implementations of the data API across clouds and open/closed source.)
➖ You have to fit your data model into key/value. Not all apps fit into this model
➕ and ➖ You have to do a bit of reading to take advantage of some useful storage features:
- Strong consistency
- Optimistic Concurrency
- Retry policies

ℹ In Dapr land, the data storage API isn't called a database on purpose because it gives you a key/value storage API. It's not SQL or any other kind of rich query language, so keep that in mind when deciding what to use.

If you want, you can check out more details on storage here.

🏄‍♀️ Surf's Up, Let's Demo This Thing

Dapr comes with a bunch of different implementations of the data API across clouds and open/closed source. We'll use the Redis implementation here.

ℹ You'll need to have Docker installed and running for this demo to work

1️⃣ - Installing 🛠

I followed the installing instructions, using the Linux script (since I'm using WSL2):

$ wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash

I had to provide my password because the script sudos things, so if you're not into letting a random script from GitHub get superuser on your computer, you can download binaries instead.

It was installed and I could test things out:

$ dapr --help

         __
    ____/ /___ _____  _____
   / __  / __ '/ __ \/ ___/
  / /_/ / /_/ / /_/ / /
  \__,_/\__,_/ .___/_/
              /_/

======================================================
A serverless runtime for hyperscale, distributed systems

Usage:
  dapr [command]

Available Commands:
  components     List all Dapr components
  configurations List all Dapr configurations
  help           Help about any command
  init           Setup dapr in Kubernetes or Standalone modes
  invoke         Invokes a Dapr app with an optional payload (deprecated, use invokePost)
  invokeGet      Issue HTTP GET to Dapr app
  invokePost     Issue HTTP POST to Dapr app with an optional payload
  list           List all Dapr instances
  logs           Gets Dapr sidecar logs for an app in Kubernetes
  mtls           Check if mTLS is enabled in a Kubernetes cluster
  publish        Publish an event to multiple consumers
  run            Launches Dapr and (optionally) your app side by side
  status         Shows the Dapr system services (control plane) health status.
  stop           Stops a running Dapr instance and its associated app
  uninstall      Removes a Dapr installation

Flags:
  -h, --help      help for dapr
      --version   version for dapr

Use "dapr [command] --help" for more information about a command.

It even has ascii art 🤡!

2️⃣ Hello, World 👋

Let's get something running. The hello world tutorial actually goes much farther than I expected it would.

You get an app up and talking to the storage API (backed by Redis), but then you get a second app up and running and have it call an API on the first one. It's actually showing off service invocation too 🎉

I first got the hello world sample code:

$ git clone https://github.com/dapr/samples.git && cd samples/1.hello-world

The sample code has a Python app and a Node app. Both has a REST API in them.

The Node App 🗼

First, the Node app. The demo README first goes through the Node code a bit.

The really interesting bit I saw was that we're doing a POST request with the fetch API to the local Dapr API to store some data. What was cool was you can also just return some JSON and it'll be automatically stored.

{
    "state": [{
        "key": "nomnomnom",
        "value": "pizza"
    }]
}

I really like that part because you don't have to manually do anything to get data into the database. It just happens.

On to running the thing. You do the standard thing to install the JS dependencies:

$ npm install
npm WARN node_server@1.0.0 No repository field.

added 55 packages from 41 contributors and audited 55 packages in 0.626s
found 0 vulnerabilities



   ╭────────────────────────────────────────────────────────────────╮
   │                                                                │
   │      New patch version of npm available! 6.14.4 → 6.14.5       │
   │   Changelog: https://github.com/npm/cli/releases/tag/v6.14.5   │
   │               Run npm install -g npm to update!                │
   │                                                                │
   ╰────────────────────────────────────────────────────────────────╯

But you then run it with the dapr CLI, not npm or node. This spits out a lot of log lines, and that's normal. Here's approximately what it looks like:

$ dapr run --app-id nodeapp --app-port 3000 --port 3500 node app.js
ℹ️  Starting Dapr with id nodeapp. HTTP Port: 3500. gRPC Port: 42491
== DAPR == time="2020-05-18T16:26:52.702694-07:00" level=info msg="starting Dapr Runtime -- version 0.6.0 -- commit e99f712-dirty" app_id=nodeapp instance=DESKTOP-DQP07VM scope=dapr.runtime type=log ver=0.6.0

<snip>

== APP == Node App listening on port 3000!

== DAPR == time="2020-05-18T16:26:52.7568756-07:00" level=info msg="application discovered on port 3000" app_id=nodeapp instance=DESKTOP-DQP07VM scope=dapr.runtime type=log ver=0.6.0

<snip>

ℹ️  Updating metadata for app command: node app.js
✅  You're up and running! Both Dapr and your app logs will appear here.

Ok, now it's running. You use the dapr CLI to also make calls to the web service. I like the simplicity of a single CLI.

$ dapr invoke --app-id nodeapp --method neworder --payload '{"data": { "orderId": "41" } }'
✅  App invoked successfully

You can also use curl for this if you want

And verifying that the request actually went through, and the data was stored, we have logs:

== APP == Got a new order! Order ID: 41

== APP == Successfully persisted state.

And we can also call the Node App's API to get the new data back out of the datastore

$ curl http://localhost:3500/v1.0/invoke/nodeapp/method/order
{"orderId":"41"}

This and the above dapr invoke call are using one of the features in Dapr's service discovery building block

The Python App 🐍

Now for the grande finale! The Python code calls the Node app in an infinite loop, so we should be able to see the Node app responding to requests and also see the datastore fill up at the same time.

First, we set up the Python dependency:

$ pip3 install requests

<snip>

Successfully installed certifi-2020.4.5.1 chardet-3.0.4 idna-2.9 requests-2.23.0 urllib3-1.25.9

And then I ran it with the same dapr run command we used for the Node app, except in a new terminal tab. I cut out all the verbose log lines this time!

$ dapr run --app-id pythonapp python3 app.py
ℹ️  Starting Dapr with id pythonapp. HTTP Port: 43891. gRPC Port: 42163
ℹ️  Updating metadata for app command: python3 app.py
✅  You're up and running! Both Dapr and your app logs will appear here.

Now, back in the Node app logs, storage is starting to fill up!

== APP == Got a new order! Order ID: 1

== APP == Successfully persisted state.

== APP == Got a new order! Order ID: 2

== APP == Successfully persisted state.

<snip>

That's It!

From experience, getting storage and microservice-to-microservice calls working from scratch takes time, carefully crafted code, and effort.

I wanted to compare this Node/Python codebase to compare my experience, and was pleasantly surprised. Let's break it down:

87 lines of Node code, including comments
- We could save a lot of lines if we returned the "data" JSON dictionary instead of using fetch calls
23 lines of Node code, including comments

From experience with Go, I can say that a battle tested storage layer for this kind of thing would be about 50 lines. That's an apples to oranges comparison, but I know for sure that all the battle-tested bits are now behind that slick storage API the Node app is using. And funny enough, that part is written in Go 💪.

P.S. don't forget to clean up: dapr stop --app-id nodeapp && dapr stop --app-id pythonapp

Bonus: Behind the Scenes

I mentioned above that you need to have Docker installed in order to get this working. That's all because Dapr needs an image running in the background for this demo to work.

cb722412a5d3        redis               "docker-entrypoint.s…"   4 weeks ago         Up 6 hours          0.0.0.0:6379->6379/tcp     dapr_redis

The important one is ... Redis! By default, all the storage API calls the Node app is making get routed into Redis.

Wrap Up

So we've seen the storage API and a bit of the service invocation API. Honestly, those two pieces alone can get you a long way just on basic usage alone.

As you get more advanced, you'll probably want to learn more about and use things like concurrency management and retry policies.

Any way you go, the docs repository and particularly the state management section are great references.

That's all for today. I hope you go forth and enjoy dapr-ing!

🤘🚀

Storing Data with Dapr

Aaron Schlesinger — Fri, 29 May 2020 18:33:38 +0000

Dapr! No, not dapper, dapr.

If you haven't read my past articles about dapr, that's ok. Let me try to boil this big project down to a sentence:

👋 Dapr is a process you run that does all the hard stuff for your app you'd rather not do

If you want to read more about it, see the intro blog post.

And with that, let's talk about (and demo!) probably the hardest thing that most (any?) apps have to deal with: storing data.

🙋‍♀️ Dapr does other things besides storage too

Why It Matters

Dapr helps with all that, but it also comes with some limitations too. Before we go demo the thing, some pros and cons for storage:

➕ You read/write data with a pretty simple REST API (or gRPC!)
➕ You get a lot of useful features (retries anyone?)
➕ You can swap out implementations (Dapr comes with a bunch of different implementations of the data API across clouds and open/closed source.)
➖ You have to fit your data model into key/value. Not all apps fit into this model
➕ and ➖ You have to do a bit of reading to take advantage of some useful storage features:
- Strong consistency
- Optimistic Concurrency
- Retry policies

ℹ In Dapr land, the data storage API isn't called a database on purpose because it gives you a key/value storage API. It's not SQL or any other kind of rich query language, so keep that in mind when deciding what to use.

If you want, you can check out more details on storage here.

🏄‍♀️ Surf's Up, Let's Demo This Thing

Dapr comes with a bunch of different implementations of the data API across clouds and open/closed source. We'll use the Redis implementation here.

ℹ You'll need to have Docker installed and running for this demo to work

1️⃣ - Installing 🛠

I followed the installing instructions, using the Linux script (since I'm using WSL2):

$ wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash

I had to provide my password because the script sudos things, so if you're not into letting a random script from GitHub get superuser on your computer, you can download binaries instead.

It was installed and I could test things out:

$ dapr --help

         __
    ____/ /___ _____  _____
   / __  / __ '/ __ \/ ___/
  / /_/ / /_/ / /_/ / /
  \__,_/\__,_/ .___/_/
              /_/

======================================================
A serverless runtime for hyperscale, distributed systems

Usage:
  dapr [command]

Available Commands:
  components     List all Dapr components
  configurations List all Dapr configurations
  help           Help about any command
  init           Setup dapr in Kubernetes or Standalone modes
  invoke         Invokes a Dapr app with an optional payload (deprecated, use invokePost)
  invokeGet      Issue HTTP GET to Dapr app
  invokePost     Issue HTTP POST to Dapr app with an optional payload
  list           List all Dapr instances
  logs           Gets Dapr sidecar logs for an app in Kubernetes
  mtls           Check if mTLS is enabled in a Kubernetes cluster
  publish        Publish an event to multiple consumers
  run            Launches Dapr and (optionally) your app side by side
  status         Shows the Dapr system services (control plane) health status.
  stop           Stops a running Dapr instance and its associated app
  uninstall      Removes a Dapr installation

Flags:
  -h, --help      help for dapr
      --version   version for dapr

Use "dapr [command] --help" for more information about a command.

It even has ascii art 🤡!

2️⃣ Hello, World 👋

Let's get something running. The hello world tutorial actually goes much farther than I expected it would.

I first got the hello world sample code:

$ git clone https://github.com/dapr/samples.git && cd samples/1.hello-world

The sample code has a Python app and a Node app. Both has a REST API in them.

The Node App 🗼

First, the Node app. The demo README first goes through the Node code a bit.

{
    "state": [{
        "key": "nomnomnom",
        "value": "pizza"
    }]
}

I really like that part because you don't have to manually do anything to get data into the database. It just happens.

On to running the thing. You do the standard thing to install the JS dependencies:

$ npm install
npm WARN node_server@1.0.0 No repository field.

added 55 packages from 41 contributors and audited 55 packages in 0.626s
found 0 vulnerabilities



   ╭────────────────────────────────────────────────────────────────╮
   │                                                                │
   │      New patch version of npm available! 6.14.4 → 6.14.5       │
   │   Changelog: https://github.com/npm/cli/releases/tag/v6.14.5   │
   │               Run npm install -g npm to update!                │
   │                                                                │
   ╰────────────────────────────────────────────────────────────────╯

But you then run it with the dapr CLI, not npm or node. This spits out a lot of log lines, and that's normal. Here's approximately what it looks like:

$ dapr run --app-id nodeapp --app-port 3000 --port 3500 node app.js
ℹ️  Starting Dapr with id nodeapp. HTTP Port: 3500. gRPC Port: 42491
== DAPR == time="2020-05-18T16:26:52.702694-07:00" level=info msg="starting Dapr Runtime -- version 0.6.0 -- commit e99f712-dirty" app_id=nodeapp instance=DESKTOP-DQP07VM scope=dapr.runtime type=log ver=0.6.0

<snip>

== APP == Node App listening on port 3000!

== DAPR == time="2020-05-18T16:26:52.7568756-07:00" level=info msg="application discovered on port 3000" app_id=nodeapp instance=DESKTOP-DQP07VM scope=dapr.runtime type=log ver=0.6.0

<snip>

ℹ️  Updating metadata for app command: node app.js
✅  You're up and running! Both Dapr and your app logs will appear here.

Ok, now it's running. You use the dapr CLI to also make calls to the web service. I like the simplicity of a single CLI.

$ dapr invoke --app-id nodeapp --method neworder --payload '{"data": { "orderId": "41" } }'
✅  App invoked successfully

You can also use curl for this if you want

And verifying that the request actually went through, and the data was stored, we have logs:

== APP == Got a new order! Order ID: 41

== APP == Successfully persisted state.

And we can also call the Node App's API to get the new data back out of the datastore

$ curl http://localhost:3500/v1.0/invoke/nodeapp/method/order
{"orderId":"41"}

This and the above dapr invoke call are using one of the features in Dapr's service discovery building block

The Python App 🐍

Now for the grande finale! The Python code calls the Node app in an infinite loop, so we should be able to see the Node app responding to requests and also see the datastore fill up at the same time.

First, we set up the Python dependency:

$ pip3 install requests

<snip>

Successfully installed certifi-2020.4.5.1 chardet-3.0.4 idna-2.9 requests-2.23.0 urllib3-1.25.9

And then I ran it with the same dapr run command we used for the Node app, except in a new terminal tab. I cut out all the verbose log lines this time!

$ dapr run --app-id pythonapp python3 app.py
ℹ️  Starting Dapr with id pythonapp. HTTP Port: 43891. gRPC Port: 42163
ℹ️  Updating metadata for app command: python3 app.py
✅  You're up and running! Both Dapr and your app logs will appear here.

Now, back in the Node app logs, storage is starting to fill up!

== APP == Got a new order! Order ID: 1

== APP == Successfully persisted state.

== APP == Got a new order! Order ID: 2

== APP == Successfully persisted state.

<snip>

That's It!

From experience, getting storage and microservice-to-microservice calls working from scratch takes time, carefully crafted code, and effort.

I wanted to compare this Node/Python codebase to compare my experience, and was pleasantly surprised. Let's break it down:

87 lines of Node code, including comments
- We could save a lot of lines if we returned the "data" JSON dictionary instead of using fetch calls
23 lines of Node code, including comments

P.S. don't forget to clean up: dapr stop --app-id nodeapp && dapr stop --app-id pythonapp

Bonus: Behind the Scenes

I mentioned above that you need to have Docker installed in order to get this working. That's all because Dapr needs an image running in the background for this demo to work.

cb722412a5d3        redis               "docker-entrypoint.s…"   4 weeks ago         Up 6 hours          0.0.0.0:6379->6379/tcp     dapr_redis

The important one is ... Redis! By default, all the storage API calls the Node app is making get routed into Redis.

Wrap Up

So we've seen the storage API and a bit of the service invocation API. Honestly, those two pieces alone can get you a long way just on basic usage alone.

As you get more advanced, you'll probably want to learn more about and use things like concurrency management and retry policies.

Any way you go, the docs repository and particularly the state management section are great references.

That's all for today. I hope you go forth and enjoy dapr-ing!

🤘🚀

Crystal Fridays - May 22, 2020

Aaron Schlesinger — Thu, 21 May 2020 20:48:50 +0000

I'll have some Windows 10 goodies for you as well 😉

Details ⏬

Aaron Schlesinger

@arschles

Tomorrow.

#CrystalFridays.

10am.

twitch.tv/arschles.

Be there for some @CrystalLanguage and a few surprises.

20:43 PM - 21 May 2020

Windows, Now With More Toys

Aaron Schlesinger — Wed, 20 May 2020 23:46:16 +0000

If you were around way back in the Windows 95 days, you might remember the PowerToys from then. Years and years later, it's back in a similar form, but for Windows 10.

I just got started with it and it's another tool in my belt to help me feel comfortable using Windows every day after many years of using Macs.

Let me take you through it.

You might have read that I recently came from a Mac. I have a follow-up post to this on how to use PowerToys Keyboard Shortcuts to make your keyboard more mac-like

🤯❔

PowerToys is a few things in one package, and different folks describe it differently.

The official GitHub repository says this:

"...set of utilities for power users to tune and streamline their Windows experience for greater productivity."

Well, I love productivity (if you've seen any of my screencasts, I hit the keyboard shortcuts hard), so I'm gonna go with that!

😎 By the way, PowerToys is 100% open source at github.com/microsoft.com/PowerToys

I just installed this thing a few hours ago and started messing around with it. It's at version v0.18.0, but the install was not as bad as I thought. Let's go over it!

🍟 Get a Package Manager

There are a few ways to install it, but I decided to use WinGet because it's also new and I hadn't used it yet.

My colleague has detailed instructions for installing WinGet, but the gist of it is you need to be a Windows Insider (free and open for anyone to join, despite how the name might sound 🎃) and then you can download it from the Windows Store. That's the easiest way.

WinGet is also open source here

🥨 Use WinGet to Install It

When you have it installed, getting PowerToys is a command:

$ WinGet install powertoys

Run this in PowerShell, not WSL2

🍕 Get Used to the Features

The very first thing to do is bask in the awesomeness of "PowerToys Run". Seriously.

Just hit left-alt+space and a search bar pops up.

You can type anything in there and quickly get to "things" on your computer. That generally means a metric ton of things that you didn't even know you had. But it also means ... YOU CAN GET TO YOUR APPS WITH NO CLICKS!!!!🎉🤘🏄‍♀️.

I really missed that from my Mac days.

Anyway, hit left-alt+space, type in "PowerToys", and hit enter. That will take you to something that looks like the standard Windows settings app, but it's actually the added features that PowerToys gives.

Check out that left bar. 7 new features plus a "General" thing at the top. I'm gonna boil each complex feature down into a single sentence, Aaron style™. Here goes:

🍚 General

Go here to do general stuff (😂), most importantly getting updates to PowerToys itself.

🥧 FancyZones

Automatically resize each window in different patterns on the screen, like side by side or in rows.

Yes, the name is amazing. The zones are indeed fancy 🍰! But the feature overall is pretty slick and powerful once you get the hang of it. You'll want to try out a few different setups to figure out the best one for you.

🍣 File Explorer preview

See rendered previews of SVGs and rendered Markdown in the file explorer. Optional second sentence 💰: I imagine there will be more formats in the future.

🍤 Image resizer

Resize any image with a right click from the file explorer.

🍎Keyboard Manager

Remap any key or keyboard shortcut from a nice UI.

🍉 PowerRename

Rename tons and tons of files by highlighting them all and right clicking.

🍍 PowerToys run

The belle of the ball for me - basically Alfred or Spotlight for Mac, but for Windows.

🥦 Shortcut guide

A full-screen pop-up that reminds you any time of the keyboard shortcuts you have set up.

🚢 Keep Calm and PowerToy On!

Of course, I'm not doing any of these items justice in a single sentence. You can learn a bit more about each one here, and follow the links in each section to go deeper.

Look out for my next post on using PowerToys to make your Mac keyboard work smoother Windows. See you soon!

👋

Crystal Fridays - May 16, 2020

Aaron Schlesinger — Fri, 15 May 2020 02:40:34 +0000

Hope to see you there! This week, we're gonna continue with our docs server.

See you tomorrow at 10am US Pacific Time, twitch.tv/arschles

Forem: Aaron Schlesinger

Synchronizing the KEDA HTTP Addon Request Routing Table Across Hundreds of Interceptor Pods

Implications of Multi-Tenancy

Keeping up to Date with the Routing Table

The Event Loop Pattern in Action

Fan-in / Fan-out with Go

What are we doing here?

Waiting for the work to be done

Getting the results

A final wrinkle: error handling

Next Steps for KEDA HTTP

Technical Reference and Proposal Document

Acceptance to the KEDA Organization

What's Next

Contributing

Deploying Apps With KEDA-HTTP

App Developers on the Web

A Better Experience

KEDA-HTTP

Under the Hood

The Future

First Lines of Rust

Unlearning Go is Hard

Similarities to Go

Memory Safe

Batteries Included

Errors are Values

Panic Only in Unrecoverable Situations

Polymorphism

More?

async/await: under the hood

What It's About 🤔

Solving Concurrency Three Ways 🕒

Callbacks 😭

Promises 🙌

async/await 🥇

What about the async keyword⁉

🏁

How To Make Windows Keyboards Look Like Mac

Make Windows Feel Like Mac 🍏

The Keyboard Manager ⌨

Remap Keyboard 🗺

Remap Shortcuts 🍕

Storage with Dapr

Why It Matters

🏄‍♀️ Surf's Up, Let's Demo This Thing

1️⃣ - Installing 🛠

2️⃣ Hello, World 👋

The Node App 🗼

The Python App 🐍

That's It!

Bonus: Behind the Scenes

Wrap Up

Storing Data with Dapr

Why It Matters

🏄‍♀️ Surf's Up, Let's Demo This Thing

1️⃣ - Installing 🛠

2️⃣ Hello, World 👋

The Node App 🗼

The Python App 🐍

That's It!

Bonus: Behind the Scenes

Wrap Up

Crystal Fridays - May 22, 2020

Windows, Now With More Toys

🤯❔

🍟 Get a Package Manager

🥨 Use WinGet to Install It

🍕 Get Used to the Features

🍚 General

🥧 FancyZones

🍣 File Explorer preview

🍤 Image resizer

🍎Keyboard Manager

🍉 PowerRename

🍍 PowerToys run

🥦 Shortcut guide

🚢 Keep Calm and PowerToy On!

Crystal Fridays - May 16, 2020

What about the `async` keyword⁉