zeusdeux

Speaker Rider

by Tatiana Mac

Before I'll agree to a speaking event, I try to do as much research I can around the event to ensure it aligns with my ethos. I want to share this in case it's helpful to any other speakers.

👐 Speaking comes with immense privilege. I am grateful to all the conference organisers who have brilliantly hosted me. I would love to continue to exercise this privilege to speak at conferences, and use this privilege to make the landscape more accessible and beneficial to tech's most marginalised and suppressed communities.

😫 I wish I didn't have to, but this is long because I provide a lot of explanations for those of you who never had to consider these things. And I will be honest, most thoughtful conferences I've attended check most of these boxes intrinsically, particularly when conference runners are experienced speakers. They get it.

1️⃣ All of these are based on my own ethos. I don't wish to or attempt to speak on behalf of all conference speake

zeusdeux

Reach UI Philosophy

Reach UI is an accessible foundation for React applications and design systems.

The three equally important goals are to be:

• Accessible
• Composable
• Stylable

zeusdeux

ssh-keygen -t rsa -b 4096 -m PEM -f jwtRS256.key
# Don't add passphrase
openssl rsa -in jwtRS256.key -pubout -outform PEM -out jwtRS256.key.pub
cat jwtRS256.key
cat jwtRS256.key.pub

zeusdeux

--exclude=*.hg*
--exclude=*.cvs*
--exclude=*.svn*
--exclude=*.git*
--exclude=*compiled*
--exclude=*public_html*
--exclude=*.idea*
--exclude=*bower_components*
--exclude=*images*
--exclude=*.DS_Store*

zeusdeux

-- Our goal is to create a type describing a list of events. This is our
-- type-level DSL.
-- We will then use typeclass resolution to "interpret" this type-level DSL
-- into two things:
-- 1. A comma-separated list of events
-- 2. A method that, when given an event name and a payload, will try to parse
--    that event type with the payload. A form of dynamic dispatching
--
-- To model a list of types we will use tuples. You can imagine the list of
-- types "Int, String, Char" to look like:

zeusdeux

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

zeusdeux

package main

import (
	"fmt"
	"log"
	"strings"
)

// Ops
const (

zeusdeux

function mapValues(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    result[key] = fn(obj[key], key);
    return result;
  }, {});
}

function pick(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    if (fn(obj[key])) {

zeusdeux

{
  // The block has begun, we're in a new block scope. The TDZ for the "a" binding has begun
 
  var f = function() {
    // 2. Because f() is evaluated before `a` is actually declared, 
    // an exception will be thrown indicating to the author that
    // `a` is not yet defined.
    console.log(a); 
  };
 

zeusdeux

Ideas for improvements to git log --graph

I will maybe someday get around to dusting off my C and making these changes myself unless someone else does it first.

Make the graph for --topo-order less wiggly

Imagine a long-running development branch periodically merges from master. The git log --graph --all --topo-order is not as simple as it could be, as of git version 1.7.10.4.

It doesn't seem like a big deal in this example, but when you're trying to follow the history trails in ASCII and you've got several different branches displayed at once, it gets difficult quickly.