Simon Tegg simontegg

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours.

You first need to undestand the concept of frontend tests.

You should not test the implementation but the behavior

You test like the end user

For instance, imagine a login screen with email and password inputs and a submit button

The test should input the email and the password, then click in the submit button.

Name	Days	Contact	Comments
their name	on average how often to contact	method of contact (signal/fb/etc)	misc
required	required	optional	optional

Reason

I have heard a lot of complaints about lack of editor integration or flaky editor tooling in the Reason community. At my previous job we had ~3000 modules and ~80k LOC. I'll admit that we were not very vigilant with .rei files or keeping our inter module dependencies really clean so this slowed both bsb and especially reason-language-server down a lot.

In fact so much that people couldn't use reason-language-server anymore on 15" MacBook Pros.

I myself have always used a Merlin based setup since I joined the Reason eco system before reason-language-server, and in our project my setup had never failed. Therefor I went on a quest of setting up 3 of the major editors (Emacs, Vim and VSCode) and documenting how to get them working

Optimization

Correctly prioritizing and targeting performance problems and optimization opportunities is one of the hardest things to master in programming. There are a lot of ways to do it wrong: by prematurely optimizing non-bottlenecks, or preferring fast solutions to clear solutions, or measuring problems incorrectly.

I'll try to summarize what I've learned about doing this right.

First, don't optimize until there's an issue. And issues should be defined as application issues: performance problems that are either detectable by the users (lag) or endanger the platform – i.e. problems that cause downtime, like out-of-memory issues. Until there's an issue, don't think about peformance at all: just solve the problem at hand, which is "creating value for the end-user," or some less-corporate translation of the same.

Second, only optimize with instruments. By instruments, I mean technology that lets you decipher which sub-part of the stack is the bottleneck. Let's say you see slowness around fet

How to setup a practically free CDN using Backblaze B2 and Cloudflare

⚠️ Note 2023-01-21
Some things have changed since I originally wrote this in 2016. I have updated a few minor details, and the advice is still broadly the same, but there are some new Cloudflare features you can (and should) take advantage of. In particular, pay attention to Trevor Stevens' comment here from 22 January 2022, and Matt Stenson's useful caching advice. In addition, Backblaze, with whom Cloudflare are a Bandwidth Alliance partner, have published their own guide detailing how to use Cloudflare's Web Workers to cache content from B2 private buckets. That is worth reading,

	import { Observable } from "rxjs";
	import { map } from "rxjs/operators";
	import { Required } from "utility-types";
	import { createMachine, sendParent, assign, spawn, Actor } from "xstate";

	import { $YesReallyAny, assert } from "../";
	import { QueryResult } from "../gql/queryResultHandler";

	let id = 0;
	enum Actions {

	(module
	;; an operation defined inside a macro
	(def op_mac (mac (a b) (block
	&[i32_load (mod a 1000)]
	)))

	;;a function that contains that macro
	(def op_fun (fun (a b) (op_mac a b) ))

	(def N 10000000)

	/**
	* Example script to change amplify cli-generated cloudformation stack to support a graphql interface. See https://github.com/aws-amplify/amplify-cli/issues/202.
	* Run this before every amplify push command (e.g. create your own bash script that does something like: amplify api gql-compile && node ./scripts/modifyAmplifyCF.js && ./amplify/backend/api/<your_app_name>/build/cloudformtion-template.json && amplify push --no-gql-override)
	* Everytime you run amplify api gql-compile, the cloudformation files will be overwritten and this script would need to be run again.
	*
	* As an example for this script, it assumes you have a custom User table built (through custom stacks - User.json for the AppSync resolvers and UserTable.json for the dynamodb table) and a Doctor and Patient model that implement this interface, e.g.
	*
	* interface User {
	* id: ID!
	*. email: AWSEmail!

	Mute these words in your settings here: https://twitter.com/settings/muted_keywords

	ActivityTweet
	generic_activity_highlights
	generic_activity_momentsbreaking
	RankedOrganicTweet
	suggest_activity
	suggest_activity_feed
	suggest_activity_highlights
	suggest_activity_tweet