short url: caseywatts.com/selfpublish
my book is out! an applied psychology / self-help book targeted at developers: Debugging Your Brain
Markdown
--> PDF
(as a booklet!)
Markdown
--> EPUB
and MOBI
I was drawn to programming, science, technology and science fiction | |
ever since I was a little kid. I can't say it's because I wanted to | |
make the world a better place. Not really. I was simply drawn to it | |
because I was drawn to it. Writing programs was fun. Figuring out how | |
nature works was fascinating. Science fiction felt like a grand | |
adventure. | |
Then I started a software company and poured every ounce of energy | |
into it. It failed. That hurt, but that part is ok. I made a lot of | |
mistakes and learned from them. This experience made me much, much |
short url: caseywatts.com/selfpublish
my book is out! an applied psychology / self-help book targeted at developers: Debugging Your Brain
Markdown
--> PDF
(as a booklet!)
Markdown
--> EPUB
and MOBI
Prediction as of 3/15/2019 JST:
import React from "react"; | |
import useMutableReducer from "./useMutableReducer"; | |
const reducer = (draft, action, state) => { | |
switch (action) { | |
case "increment": | |
draft.count++; | |
break; | |
case "decrement": | |
draft.count--; |
Advice and wisdom from Brendan Baker, formerly of Greylock.
(He used to have pitchpatterns.com, which listed all of these, but that domain has since lapsed.)
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
# Assumes 3 sequential commits: | |
# | |
# 1. commit tagged "prettier-before" that added `prettier` depedency and `prettier` script your package.json | |
# 2. commit that actually ran `prettier` on your entire codebase for the first time | |
# 3. commit tagged "prettier-after" that fixes any minor issues caused by prettier (e.x. moving eslint-ignore or $FlowFixMe comments around), or just the next commit if there were none | |
# | |
# I recommend running these as individual commands, not as a script, in case of merge conflicts | |
# | |
# Checkout the non-pretty branch you want to merge | |
# (or optionally make a new branch with `git checkout -b $YOUR_BRANCH-prettier $YOUR_BRANCH`) |
const timing = store => next => action => { | |
performance.mark(`${action.type}_start`); | |
let result = next(action); | |
performance.mark(`${action.type}_end`); | |
performance.measure( | |
`${action.type}`, | |
`${action.type}_start`, | |
`${action.type}_end` | |
); | |
return result; |
Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.
While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.
Secure user authentication requires the use of session cookies.
Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.
Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.
*S