Andrew J. Stone andrewjstone

Bookmarklets for GitHub pain points

To install these bookmarklets, copy the line starting with javascript: into the URL field of a bookmark in your browser. For each one, I've included both a one-line version you can paste directly and a formatted version so you can read it. The (function() { ... })() IIFE wrapper in the one-liner is there because that's how you have to wrap up a block of code.

Load collapsed diffs

Presumably to optimize initial page load time, GitHub collapses large files in a diff by default. This clicks all the "load diff" buttons on the page. Note that we use a setTimeout to do it a second time 5 seconds later because on very large diffs, the full list of files can take time to load, which means you can click the bookmarklet too early.

Page to try it on: https://github.com/oxidecomputer/omicron/pull/2645/files

Looking into the `Future`

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

Testing Stateful Code

So far, all the properties we have written have tested stateless code. Stateless code is made up of pure functions and is inherently easier to test than stateful code with side effects. The chief problem with testing stateful code is that the input to output mapping depends on the current state of the program. Previous operations can cause the same function to return different output given the same input. Therefore, in order to test stateful code, our tests must maintain some state of their own. This state is known as the model state and is updated as part of the testing process.

I've been reading a bit about concatenative languages recently, and figured I'd compose a short reading list for others interested.

I won't explain what a concatenative language is, but I do want to quickly say a couple of the reasons I find them interesting.

Refactoring

I already like to write really tiny functions, and concatenative languages make it really easy to factor a function into a smaller one. Here's an example, in a made up concatenative language:

	#!/bin/bash

	# This dot files would be better generated in xtask
	# where the app.toml files are already parsed
	# and the necessary data structures are already
	# available.

	# To generate all graphs (skipping Cargo.toml files):
	# for app in app//[a-z].toml; do bash priorities $app; done