swyx/dev/blog

Sun, 15 Sep 2019 02:00:40 +0000

i wrote this, hope it goes up

title: Turning the Static Dynamic: Gatsby + Netlify Functions + Netlify Identity
date: 2018-12-17
author: swyx
tags:

apps
web apps
applications
beyond static
excerpt: Gatsby is great for not only static sites but also traditional web applications. You can add authentication and serverless functionality up and running incredibly quickly with Netlify - here’s how.
—

In a recent Reactiflux interview, the Gatsby team was asked this question:

Q: What is one thing that Gatsby is capable of doing that might surprise some people? — ctlee

A: Gatsby can be used to build fully dynamic sites, which surprises some people because of it’s label as a “static site generator”. It’s fully equipped to be a powerful alternative to create-react-app and other similar solutions with the addition of easy pre-rendering and perf baked in. — biscarch

Even though Dustin recently wrote about Gatsby for Apps and open sourced his Gatsby Mail demo, I do still find people constantly having to explain that Gatsby is “not just for sites”.

Today I’d like to show you how you can incrementally add functionality to a Gatsby static site with Netlify Functions, and then add authentication with Netlify Identity to begin a proper Gatsby app.

Static-Dynamic is a spectrum

Why would you use something like Gatsby over Jekyll or Hugo or one of the hundreds of Static Site Generators out there? There are many reasons, but one of the unique selling points is how Gatsby helps you build “Static Progressive Web Apps” with React.

Gatsby’s ability to rehydrate (what a delicious word!) the DOM means you can do incredibly dynamic things with Javascript and React that would be much harder with legacy SSG’s.

Let’s say you have a typical static Gatsby site, like gatsby-starter-default. You can npm run build it, and it spits out a bunch of HTML files. Great! I can host that for free!

Now your client comes to you and asks you to add some custom logic that needs to be executed on the server:

Maybe you have third party API secrets you don’t want to expose to your user.
Maybe you need a serverside proxy to get around CORS issues.
Maybe you need to ping a database to check your inventory.

Oh no! Now you have to rewrite everything and move to a Digital Ocean droplet!

I’m kidding. No, you don’t have to rewrite everything.

The beauty of serverless functions is that it is incrementally adoptable - your site grows with your needs - and with Gatsby you can rerender entire sections of your site based on live API data. Of course, the more you do this, the more resource intensive (in terms of bandwidth and computation) it can be, so there is a performance tradeoff. Your site should be as dynamic as you need it to be, but no more. Gatsby is perfect for this.

5 Steps to add Netlify Functions to Gatsby

Netlify Functions are a great low configuration solution for adding serverless functionality to your Gatsby site. You get 125,000 free calls a month - that’s a function call every 20 seconds every day of the week, month, and year - and you can emulate them in local development with netlify-lambda.

Let’s walk through the steps:

Install dependencies: npm install -D http-proxy-middleware netlify-lambda npm-run-all
Run function emulation alongside Gatsby: replace your scripts in package.json:

  "scripts": {
    "develop": "gatsby develop",
    "start": "run-p start:**",
    "start:app": "npm run develop",
    "start:lambda": "netlify-lambda serve src/lambda",
    "build": "run-p build:**",
    "build:app": "gatsby build",
    "build:lambda": "netlify-lambda build src/lambda",
  },

Configure your Netlify build: When serving your site on Netlify, netlify-lambda will now build each Javascript/Typescript file in your src/lambda folder as a standalone Netlify function (with a path corresponding to the filename). Make sure you have a Functions path in a netlify.toml file at root of your repository:

[build]
  Command = "npm run build"
  Functions = "lambda"
  Publish = "public"

For more info or configuration options (e.g. in different branches and build environments), check the Netlify.toml reference.

Proxy the emulated functions for local development: Head to gatsby-config.js and add this to your module.exports:

// gatsby-config.js
var proxy = require('http-proxy-middleware')

module.exports = {
  // for avoiding CORS while developing Netlify Functions locally
  // read more: https://www.gatsbyjs.org/docs/api-proxy/#advanced-proxying
  developMiddleware: app => {
    app.use(
      '/.netlify/functions/',
      proxy({
        target: 'http://localhost:9000',
        pathRewrite: {
          '/.netlify/functions/': '',
        },
      })
    )
  },
  // ...
}

Write your functions: Make a src/lambda folder and write as many functions as you need. The only requirement is that each function must export a handler, although netlify-lambda helps you use webpack to bundle modules or you can zip the functions yourself. For example you can write src/lambda/hello.js:

// For more info, check https://www.netlify.com/docs/functions/#javascript-lambda-functions
export function handler(event, context, callback) {
  console.log('queryStringParameters', event.queryStringParameters)
  callback(null, { // return null to show no errors
    statusCode: 200, // http status code
    body: JSON.stringify({
      msg: 'Hello, World! ' + Math.round(Math.random() * 10)
    }),
  })
}

Now you are ready to access this API from anywhere in your Gatsby app! For example, in any event handler or lifecycle method, insert:

fetch('/.netlify/functions/hello')
      .then(response => response.json())
      .then(console.log)

and watch “Hello World!” pop up in your console. (I added a random number as well to show the endpoint is dynamic) If you are new to React, I highly recommend reading through the React docs to understand where and how to insert event handlers so you can, for example, respond to a button click.

The local proxying we are doing is only for local emulation, eg it is actually running from http://localhost:9000/hello despite you hitting /.netlify/functions/hello in your Gatsby app. When you deploy your site to Netlify (either by hooking your site up through Git through our Web UI, or our l33t new CLI), that falls away, and your functions -are- hosted on the same URL and “just works”. Pretty neat!

That’s cool, but its not an app

So, yes, your site can now be more dynamic than any static site. It can hit any database or API. It runs rings around CORS (by the way, you can also use Netlify Redirects for that). But its not an app app. Yet!

The key thing about web apps (and, lets face it, the key thing users really pay for) is they all have some concept of user, and that brings with it all manner of complication from security to state management to role-based access control. Entire routes need to be guarded by authentication, and sensitive content shielded from Gatsby’s static generation. Sometimes there are things you -don’t- want Google’s spiders to see!

It’s a different tier of concern, which makes it hard to write about in the same article as a typical Gatsby tutorial. But we’re here to make apps, so let’s bring it on!

5 Steps to add Netlify Identity and Authenticated Pages to Gatsby

Enable Netlify Identity: Netlify Identity doesn’t come enabled by default. You’ll have to head to your site admin (eg https://app.netlify.com/sites/YOUR_AWESOME_SITE/identity) to turn it on. Read the docs for further info on what you can do, for example add Facebook or Google social sign-on!
Install dependencies: npm install netlify-identity-widget gatsby-plugin-create-client-paths

Configure Gatsby: for dynamic-ness!

// gatsby-config.js
module.exports = {
  plugins: [
 {
   resolve: `gatsby-plugin-create-client-paths`,
   options: { prefixes: [`/app/*`] },
 },
  // ...
  ]
  // ... (including what you also wrote earlier)
}

Write an authentication service: netlify-identity-widget is a framework-agnostic overlay that ships with a nice signup/login UI. This gets you up and running the fastest, however if you need a smaller solution you may want to use the underlying gotrue-js, or react-netlify-identity for a React Hooks solution.

Here’s a usable example that stores your user in local storage:

// service/auth.js
import netlifyIdentity from 'netlify-identity-widget'

export const isBrowser = () => typeof window !== 'undefined'
export const initAuth = () => {
  if (isBrowser()) {
    window.netlifyIdentity = netlifyIdentity
    // You must run this once before trying to interact with the widget
    netlifyIdentity.init()
  }
}
export const getUser = () =>
  isBrowser() && window.localStorage.getItem('netlifyUser')
    ? JSON.parse(window.localStorage.getItem('netlifyUser'))
    : {}

const setUser = user =>
  window.localStorage.setItem('netlifyUser', JSON.stringify(user))

export const handleLogin = callback => {
  if (isLoggedIn()) {
    callback(getUser())
  } else {
    netlifyIdentity.open()
    netlifyIdentity.on('login', user => {
      setUser(user)
      callback(user)
    })
  }
}

export const isLoggedIn = () => {
  if (!isBrowser()) return false
  const user = netlifyIdentity.currentUser()
  return !!user
}

export const logout = callback => {
  netlifyIdentity.logout()
  netlifyIdentity.on('logout', () => {
    setUser({})
    callback()
  })
}

Write your app: Now, any sub paths in src/pages/app will be exempt from Gatsby static generation. To keep the dividing line between app and site crystal clear, I like to have all my dynamic Gatsby code in a dedicated app folder. This means you can use @reach/router with netlify-identity-widget to write a standard dynamic React app. Here’s some sample code to give you an idea of how to hook them up:

app.js:

import React from 'react'
import { Router } from '@reach/router' // comes with gatsby v2
import Layout from '../components/layout'
import NavBar from './components/NavBar'
import Profile from './profile'
import Main from './main'    // NOT SHOWN
import PrivateRoute from './components/PrivateRoute'
import Login from './login'

// remember everything in /app/* is dynamic now!
const App = () => {
  return (
    <Layout>
      <NavBar />
      <Router>
        <PrivateRoute path="/app/profile" component={Profile} />
        <PublicRoute path="/app">
          <PrivateRoute path="/" component={Main} />
          <Login path="/login" />
        </PublicRoute>
      </Router>
    </Layout>
  )
}
function PublicRoute(props) {
  return <div>{props.children}</div>
}

export default App

components/NavBar.js:

import React from 'react'
import { Link, navigate } from 'gatsby'
import { getUser, isLoggedIn, logout } from '../services/auth'

export default () => {
  const content = { message: '', login: true }
  const user = getUser()
  if (isLoggedIn()) {
    content.message = `Hello, ${user.user_metadata &&
      user.user_metadata.full_name}`
  } else {
    content.message = 'You are not logged in'
  }
  return (
    <div
      style=
    >
      <span>{content.message}</span>

      <nav>
        <span>Navigate the app: </span>
        <Link to="/app/">Main</Link>
        {` `}
        <Link to="/app/profile">Profile</Link>
        {` `}
        {isLoggedIn() ? (
          <a
            href="/"
            onClick={event => {
              event.preventDefault()
              logout(() => navigate(`/app/login`))
            }}
          >
            Logout
          </a>
        ) : (
          <Link to="/app/login">Login</Link>
        )}
      </nav>
    </div>
  )
}

components/PrivateRoute.js:

import React from 'react'
import { isLoggedIn } from '../services/auth'
import { navigate } from 'gatsby'

class PrivateRoute extends React.Component {
  componentDidMount = () => {
    const { location } = this.props
    if (!isLoggedIn() && location.pathname !== `/app/login`) {
      // If the user is not logged in, redirect to the login page.
      navigate(`/app/login`)
      return null
    }
  }

  render() {
    const { component: Component, location, ...rest } = this.props
    return isLoggedIn() ? <Component {...rest} /> : null
  }
}

export default PrivateRoute

login.js:

import React from 'react'
import { navigate } from 'gatsby'
import { handleLogin, isLoggedIn } from './services/auth'

class Login extends React.Component {
  handleSubmit = () => handleLogin(user => navigate(`/app/profile`))
  render() {
    return (
      <>
        <h1>Log in</h1>
        <button onClick={this.handleSubmit}>log in</button>
      </>
    )
  }
}

export default Login

Phew that was a lot! but you should have a solid starting point for your app :)

Bonus points: Authenticated Lambda Functions for your Gatsby App

Just like every magic act has a pledge, a turn, and a prestige, I have one last tidbit for you. Nothing on the client-side is safe, and although you can send along Netlify Identity user id’s to your Netlify Function endpoints for authenticated access from your Gatsby App (for example in the body of a POST request), you’ll never be truly sure if that flow is secure either from malicious users or snooping.

The best way to do authenticated actions inside serverless functions is to do it from inside the context of the function itself. Fortunately, Netlify Identity and Functions work seamlessly together. All you have to do is to send along the user’s JWT when hitting your endpoint:

// in your gatsby app
    const user = getUser()
    fetch('/.netlify/functions/auth-hello', {
      headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
        Authorization: 'Bearer ' + user.token.access_token, // like this
      },
    })
      .then(/* etc */)

And then inside a lambda function, you can now access the user object:

// more info: https://www.netlify.com/docs/functions/#identity-and-functions

// Note that `netlify-lambda` only locally emulates Netlify Functions, while `netlify-identity-widget` interacts with a real Netlify Identity instance. This means that `netlify-lambda` doesn't support Netlify Functions + Netlify Identity integration.

export function handler(event, context, callback) {
  if (context.clientContext) {
    const { 
      user      // actual user info you can use for your serverless functions
    } = context.clientContext
    callback(null, {
      statusCode: 200,
      body: JSON.stringify({
        msg: 'auth-hello: ' + Math.round(Math.random() * 10),
        user,
      }),
    })
  } else {
    console.log(`
    Note that netlify-lambda only locally emulates Netlify Functions, 
    while netlify-identity-widget interacts with a real Netlify Identity instance. 
    This means that netlify-lambda doesn't support Netlify Functions + Netlify Identity integration.
    `)
    callback(null, {
      statusCode: 200,
      body: JSON.stringify({
        msg:
          'auth-hello - no authentication detected. Note that netlify-lambda doesnt locally emulate Netlify Identity.',
      }),
    })
  }
}

Gatsby - Perfect for your next Hackathon

It’s 5 steps each to turn your static Gatsby sites into dynamic, authenticated, fully serverless apps with Netlify’s free tools. This makes Gatsby a perfect tool for your next app. If you’re at a hackathon, short on time, or just like to see a full working demo, check any of the following links.

Code: https://github.com/sw-yx/jamstack-hackathon-starter
Starter: https://www.gatsbyjs.org/starters/jamstack-hackathon-starter
Live Demo: https://jamstack-hackathon-starter.netlify.com/

Sun, 15 Sep 2019 02:00:40 +0000

This is the sixth in a series of class notes as I go through the free Udacity Computer Networking Basics course.

Congestion Collapse 💩

Say we have a central switch S that is linked to a destination D with a connection capacity of 1 Mbps. However, we have two source hosts H1 and H2 connecting through L trying to send data to D at rates of 10 Mbps and 100 Mbps respectively.

The exact numbers don’t matter, but the point is H1 and H2 are trying to send data at a much higher rate than the S-D link can take it. The S-D link is a bottleneck.

By Internet architecture design, the source hosts H1 and H2 are unaware of each other, and of the current state of the S-D link. As a result, they very inefficiently compete for resources on the bottleneck and this can be lead to lost packets and long delays, to the point where the S-D link isn’t even used to its full capacity because of all the failures. This is called congestion collapse.

Congestion Collapse is defined where an increase in load leads to a decrease in useful work. It can be caused by:

spurious retransmission (of packets, due to how TCP works when packets are dropped and ACKs aren’t received)
- solution: better timers and TCP congestion control
undelivered packets (packets consume resources but are dropped elsewhere in the network)
- apply congestion control to ALL traffic

Goals of Congestion Control 👼

So given the realities of different bandwidths in our network, we want to:

Use network resources efficiently
Preserve fair allocation of resources
avoid congestion collapse

You can chart Fairness and Efficiency between two hosts with a phase plot:

You can accomplish these goals with network-assisted congestion control where routers provide feedback with a bit to indicate congestion (eg the Explicit Congestion Notification extension in TCP) but more commonly the congestion control is implicit, or end-to-end, where the network does not give feedback and congestion is inferred by looking at packet loss and delays.

TCP Congestion Control

In TCP Congestion Control, senders slowly increase their rate until packets are dropped. Packet loss is interpreted as congestion and the rate is slowed down. The rate is increased again periodically to retest the network in case the congestion was temporary (eg due to a maxed out buffer in a router).

The increase/decrease algorithm can work in two ways.

Window-based algorithms have a set number of packets out at any given time. New packets are sent when ACKs from old packets are received. So if extant packets drop, new packets don’t get sent, and the effective send rate decreases, and vice versa. So the window size is a natural control. The increase and decrease of window size is a different matter: when a packet is successfully sent, the window size “additively” increases by one. When a packet fails, the window size is cut “multiplicatively” in half. This asymmetric increase/decrease algorithm is known as Additive Increase, Multiplicative Decrease (AIMD).
Rate-based alogithms monitor their loss rate instead, and use a timer to modulate their rate. This is less common.

On a phase plot, AIMD moves rates up parallel to the X1 = X2 “fair” line, and down according to its angle to the origin:

In terms of individual rate over time, AIMD also results in a “sawtooth” plot:

A TCP sender sends at an average rate of 3/4 of it’s window size due to AIMD.

To calculate throughput, you take the average rate divided by the RTT, or 3/4 * Wm/RTT.

Also because of AIMD, the time between the troughs is given by Wm/2 + 1 (the Wm/2 being the time taken to increase the height of half the window 1 at a time, and the 1 being the time it takes to decrease it in half).

To calculate the loss rate, Compare the area under the sawtooth (successful sends) to the total packets sent, i.e. 1/2 * Wm/2 * (Wm/2 + 1) or basically Wm^2 / 8.

Throughput and LossRate are related by Throughput ~ k/(RTT * sqrt(Lossrate)).

The TCP Incast Problem

There is a special congestion problem that specifically happens in the conditions of data centers. Incast is a drastic reduction in application throughput that results when servers using TCP all simultaneously request data (sometimes with Barrier Synchronization, leading to a gross underutilization of network capacity in many-to-one communication networks like a datacenter. This is due to:
- Requirement of high bandwidth and low latency
- Many parallel requests coming from servers
- High “fan in” in a data center
- Small buffers in switches
- Filled up switch buffers result in bursty retransmissions cause by TCP timeouts that last hundreds of milliseconds
- But (as above) the requirement of low latency typically on the order of <1ms.

Two solutions are:

Fine grained TCP retransmission timers on the order of microseconds instead of milliseconds
Clients acknowledging every other packet instead of every packet, reducing network load

Bottom line: Timers should operate on a granularity close to the RTT of the network, and in a Data Center that is <1ms.

Multimedia and Streaming

The next half of this piece focuses on dealing with the unique problems of sending multimedia and streaming. Some characteristics of these situations are:

Large volume of data (eg video with sound)
Data volume varies over time (depending on compression algorithm)
Low tolerance for delay variation
Low tolerance for delay

The most important of these is delay variation. We can establish a clientside buffer to manage some variation and variance but delay variations will threaten the smooth playback especially if the buffer is starved.

TCP is not a good fit for streaming. It is meant to:

deliver reliably - but the client may not care about that
slow down upon loss - this leads to delay variation
20 byte header for every packet - significant overhead

UDP is better:

no retransmission
no sending rate adaptation
small header

Case studies

Youtube (streaming video)

All videos are converted to Flash, and every browser can play it with HTTP/TCP. Even though TCP isn’t a good fit for streaming, the creators of Youtube preferred to keep it simple so it can leverage existing HTTP/TCP infrastructure like CDNs.

Skype/VOIP

Skype has a central login server but uses P2P to exchange data. It compresses to a fairly low bitrate (67 bytes/pkt, 140 pkts/sec or 40kbps), encrypted both ways. But it is still very susceptible to drops in network quality.

Quality of Service

We can use explicit reservations, or marking and policing packet streams as higher priorities.

If we have a VOIP app and an FTP app both sharing the same bandwidth, we want to make sure the VOIP has a higher priority. We can mark the audio packets as they arrive at the router with a priority queue, and then use scheduling (eg weighted fair queueing where you simply serve the high-pri queue more often than the low-pri queue)

Next in our series

Hopefully this has been a good high level overview of the Congestion control and some of its practical implementations/applications. I am planning more primers and would love your feedback and questions on:

Architecture and Principles
Switching
Routing
Naming/Addressing/Forwarding
DNS
Congestion Control and Streaming
Rate Limiting and Traffic Shaping
Content Distribution
Software Defined Networks
Traffic Engineering
Network Security

boop

Fri, 13 Sep 2019 00:00:00 +0000

since rewriting my blog in gatsby and then rewriting again in sapper, i have been very inactive here as i’ve tended to manage my life on the DX github project, and also just living day to day on fighting the next battle.

life in NJ has been very nice although solitary and i need to make it more my own.

things to do today:

check in on my omscentral project
check my own email esp jhooks stuff
plan recordings for fcc
read and deal with my mail

ryan questions

Tue, 13 Aug 2019 00:00:00 +0000

is this a formal company?
what are your plans?
what are you hiring for?
how do you work together
state manager
thoughts on
- superdocs
- supertwitter
- contracting

framework for reactrouter

dynamic
codesplitting
data loading
i18n
on full site

thru to end 2020

swe/education
react router & nextjs
dynamic routes based on permission

mj software/roadmap/gh issues
rf training/executing/mgmt

netlify env vars blogpost

Fri, 09 Aug 2019 00:00:00 +0000

Netlify Environment Variables: The Cheat Codes of the Internet

We usually use Environment Variables as (global) variables, but did you know they can totally configure your environments as well?

Secret Globals, Global Secrets

Environment Variables occupy an interesting space in our collective mindset. They are more secure than plaintext, but also Considered Harmful. As globals that we call by a more polite name, they are useful in small doses, and therefore have a funny way of spreading: They were introduced to JavaScript by the Express backend framework in 2010 and now drive entire library build processes and development experience tradeoffs for all the major frontend frameworks (you can make your own dev-only warnings with TSDX!).

Making use of Environment Variables on the Frontend

Because unintentionally leaking API tokens to clients is a Very Bad Thing, we have evolved best practices like prefixing environment variables with REACT_APP_ or VUE_APP_ or GATSBY_. If you aren’t seeing an environment variable that you expected to see, this is probably the cause. Please check our Common Environment Variables Issues Guide on the Netlify Community site for self-serve help!

For hosted platforms like Netlify, we can also use environment variables to communicate from the build environment to the frontend, for the frontend to configure itself based on that information.

For example, Netlify automatically sets up Continuous Deployments when you link your Git repo. Imagine you are hosting documentation for open source. People often want to “view source” for your site. Instead of hardcoding the Git repo, you can simply reference process.env.REPOSITORY_URL in your build process, and pass it to your static site generator of choice.

Granted you’re not going to change your Repo URL that often. But this is one of many examples. For example, if you use Deploy Previews to work in progress PR’s with collaborators and clients, you can check process.env.CONTEXT === 'deploy-preview' and place a nice banner disclaiming that is not the production version of your site.

This kind of workflow with Environment Variables are key to how Netlify’s Split Testing feature works. By basing your A/B test on git workflow, there is no A/B testing API to learn - just make a new git branch and send traffic that way. On the frontend, if you check the BRANCH context variable (again, with the caveat that some frontend frameworks may make you jump through some hoops to send this to the frontend).

Using Environment Variables to Vary your Environment

However, intelligent runtime environments can also configure themselves around your variables, which is a very nice way to offer backward compatibility or flagged functionality for different codebases that all work on the same exact platform. Let’s explore ideas for how this can work on Netlify:

Setting your Node Versions in Build Process and in Serverless Functions

To set your Node Version, you, well, set NODE_VERSION! 🤯

This variable only affects your build environment. By default it is v10.16.2 at time of writing, but if, for example, your build process requires node 8 or node 12, you can set it to 8 or 12 accordingly. You can also set a specific release version or use .nvmrc if you like.

The other important environment you may wish to vary is your serverless functions. Netlify Functions are a nice development experience layer atop AWS Lambda. By default, Node Netlify Functions run in Node v8.10, but you can set AWS_LAMBDA_JS_RUNTIME to nodejs10.x (or any other valid AWS Lambda runtime name) to run in Node 10 for newer language features and better performance! (You can also set Go function environment versions with the build image.)

You can also set other important command line and environment versions as needed, for example YARN_VERSION, YARN_FLAGS, NPM_VERSION, and NPM_TOKEN (handy if you use a private npm instance).

Power User Features

There are even more environment variables available meant for introspection, debugging, and power users, for example the HOME directory and GOCACHE directory environment variables.

You can use variables like these to persist files between builds, to skip rebuilding files that already exist, and thereby massively speed up your static site builds by only building incremental new/changed pages. Check out cache-me-outside for an example of how to do this.

You can reference the Big Fat List of Environment Variables here, and it will be fully documented in an upcoming version of the Netlify Docs.

What else can you do with these environment variables that we aren’t thinking about? Let me know!

middevconday2 gatsby stuff

Fri, 02 Aug 2019 00:00:00 +0000

abandoned the child theme appraoch of gatsby theme dev blog today: https://github.com/sw-yx/gatsby-theme-dev-blog-abandoned
taught jamstack jumpstart again: https://github.com/sw-yx/jamstack-jumpstart

middevcon 2019 day 1

Thu, 01 Aug 2019 00:00:00 +0000

ddd workshop

list of things
you should be able to drop your domain expert infront of your graphiql and they can get exactly what they want
ddd scorecard has levels of difficulty/cruddiness
dont let your users speak crud
bounded contexts vs big ball of crud
ddd bounded contexts <=> actor model
ddd relationship with leaky testing impl detail
event storming: domain event (something that happened past tense), command, actor, model
indi young: mental models book
value objects (immutable, no identity only values, ALWAYS VALID: NO SETTERS, only validate via constructors), single entities (has identity, state, mutable, never in an invalid state), aggregate entities (responsible for child entities)
brewsessionwasplanned === german!
event sourcing - like git, only track changes, append only event storage. avoid object relational impedance mismatch. logging for free
CQRS = seperate write and read. framework from domain. but very complex, use later

learn in public vuenyc

Mon, 29 Jul 2019 00:00:00 +0000

prior art

https://www.youtube.com/watch?time_continue=6&v=-f-rZepNKW0
https://gist.github.com/sw-yx/505d15ed3e7febdab3aa3d25ee81f652

Learning In Public: https://www.swyx.io/writing/learn-in-public/
- The Secret.
- belief of the law of attraction, which claims that thoughts can change a person’s life directly
- The Anti-Secret.
- belief of the law of attraction, which claims that sharing learnings in public can change a person’s life for the better
What is it
- Dark Matter Developers
- Learn in Private vs Learn in Public
- Creating Learning Exhaust
  - Write: Blogs, Tutorials, Cheatsheets
  - Speak: Meetups, Conferences, Workshops
  - Ask & Answer: StackOverflow, Reddit
  - Code: Issues, Demos, Libraries, Repros
  - Avoid: Slack, Discord, “In Memory Storage”
  - Misc: Youtube/Twitch videos, Draw Cartoons, Rap
But Nobody Will Read It
- False
- But also it doesnt matter
  - Don’t judge your results by claps/retweets/stars/upvotes
  - Talk to yourself
  - Low pressure - just build the habit
  - Talk to past you. By far the biggest beneficiary will be future you.
  - If others benefit, that’s icing
They will Read it
- Experts
  - if it’s about their thing, there is a 80% chance they will read it
  - they care
  - there aren’t that many people doing this
- Peanut Gallery
  - Cunningham’s Law
  - xkcd https://xkcd.com/386/
- TRY YOUR BEST TO BE RIGHT BUT DONT WORRY WHEN YOU’RE WRONG
  - or you never ship
  - and being wrong is GOOD.
Why does it work?
- People notice genuine learners and want to help you - IF YOU PUT IN THE WORK
- Human psychology: You dont forget being wrong in Public. You just don’t.
- Cunningham’s Law.
- Human psychology: commitment, positive reinforcement
- Human pyshcology: availability bias
- Inbound marketing vs Outbound - knowledge and opportunities
- Building capital, existing, PORTABLE material to repurpose
Advanced Learning In Public
- Teaching
- Talk while you code :: Interviews
- Double dip.
- Pick up what they put down. Quests.
- Mentors: When they say “Anyone willing to help with * ?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.
  - With so many junior devs out there, why will they help me? bc LIP
- Mentoring: At some point people start asking you for help because of all the stuff you put out. They think you’re an expert. D
- Eventually you run out of mentors for the thing you are working on
- Eventually they’ll want to pay you for your help
Benefits
- Connecting with other people who LIP
- Having a Second Brain
Learning Gears https://www.swyx.io/writing/learning-gears/
- How do you start Learning in Public?
- Explorer
  - Problem: you don’t know what you don’t know
  - Exhaust: mainly notes to self
  - Output: episodic, no theme
  - Commitment: Low (good and bad…)
- Connector
  - default gear
  - Problem: you know things many don’t know
  - Exhaust: expicitly meant for others
  - Output: some pet topics, no grand theme, exploring intersections
  - Commitment: moderate (weeks and months). “putting yourself out there”. dont try to please everyone.
- Miner
  - Problem: something important is too hard, or too unknown. Dive deep into something NOBODY else does
  - Exhaust: do research and build community/infrastructure, meant to last
  - Output: one theme that unifies your work. People come to you.
    - might seem boring but it will subdivide when you go deep enough
  - Commitment: very high. years and careers.
    - choose something with a good chance of widening and deepening at the same time (like investing)
  - for when you have struck gold: resonates, and fascinated by

Three stories from me

first contribution:
- https://github.com/facebook/react/pull/11168
- https://reactjs.org/docs/how-to-contribute.html#introductory-video
RTS cheatsheet
- https://twitter.com/swyx/status/1002776892154445826
- https://github.com/typescript-cheatsheets/react-typescript-cheatsheet
React Hooks
- https://mobile.twitter.com/swyx/status/1100809424963219456
- https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/
- https://www.youtube.com/watch?v=KJP1E-Y-xyo

Stories from other people

Brad Frost: http://bradfrost.com/blog/post/creative-exhaust/
Jeff Atwood: https://blog.codinghorror.com/how-to-stop-sucking-and-be-awesome-instead/
Kent C Dodds: https://kentcdodds.com/blog/intentional-career-building
Cory House: https://vimeo.com/97415346
Chris Coyier: https://chriscoyier.net/2012/09/23/working-in-public/

nextjs on netlify

Tue, 09 Jul 2019 00:00:00 +0000

dwells helped me out with a rabbit hole thing yesterday:

thanks @DWells for digging me out of a pit of despair: first listening to my question, working through it, figuring out it was the wrong question, then finding the answer almost right away thru his googlefu. absolute legend.

https://community.netlify.com/t/serverless-next-js-9-on-netlify-functions/1956

now i am trying to see fi i can make a little cli as i think there is still holes in this experience

https://github.com/netlify-labs/netlify-nextjs

what motto did was:

build nextjs -> it builds serverless and static stuff
inject the serverless wrappers
run netlify-lambda over each endpoint to bundle everything

we can imagine a two stage evolution of how a netlify-nextjs layer can go.

all in one
- everything in ONE function, copy the whole serverless pages folder into that one function
- at the root, a handler for that function with the compat layer, that dynamically routes each request
- in this case we copy our handler OUT
- shit for performance but probably simpler and proves out demand
one by one
- every function has its home
- copy (adapt?) each compat handler to require each
- possibly run netlify-lambda vif shared files are required

sarah 1o1

Mon, 01 Jul 2019 00:00:00 +0000

posting 1 post
need utm
dwells
office of the CTO - research and development
- dwells
marketing might hire a growth engineer or growth person
sarah:
- lauren meeting
  - jamstack.org
  - site traffic up
  - dev center
- books
- smashing mag partnership and articles that we own
separate standups
360 - career laddering
- how i partner with people across
- 2-3 weeks
- never done before
- help set up process with vp of people from scratch
make a sprint planning board
- both have ticket we can sharee
drive site traffic up
chris has lent a lot of trust - how to get it there - not as strict
the content mill problem
pre smashing meeting - who we like in devrel, what we should be looking out for
unbiased angular interview
reach out with azure functions
prep for hashicorp