leafac

• Features

  • Schedule jobs
  • Schedule jobs in the future
  • Explicit failure: An exception was thrown
  • Implicit failure: A job was picked up and not finished in a certain amount of time
  • Retry jobs that failed (explicitly or implicitly)
  • After a certain number of retries, fail the job
  • Have a way to force the worker to run immediately

• On graceful termination finish existing jobs

leafac

• https://pagefind.app/
• https://stork-search.net/
• https://lunrjs.com/
• https://github.com/tinysearch/tinysearch

leafac

• TypeScript transformation
  • The tsc compiler doesn’t yet let you run your own transforms.
  • And what if your project isn’t using TypeScript?
• esbuild doesn’t allow you to manipulate the AST
• Babel Plugin (That’s my option)
  • More powerful & easier to conceptualize.
• Babel Macros (https://github.com/kentcdodds/babel-plugin-macros)
  • Useful for create-react-app and things that don’t allow you to change configuration easily.
  • Macros have to be CommonJS
• A Babel visitor must be synchronous and the visitor needs to require() the macro definition, but import() is async.

leafac

• Algorithms
  • xxHash: Self-proclaimed the fastest. (That’s my option)
  • djb2: Beautifully simple.
  • Murmur: Used by most other CSS-in-JS tools.
• Uses by other related tools:
  • esbuild: xxHash & Boost’s hash_combine (not really sure which does which, but I feel xxHash is doing the file hashing).
  • styled-components: djb2
    • Progressive, which means the same hash is updated across elements that need to be hashed
      • Good: Remarkably simple.
• Bad: The stability of the hashes depends upon the order of the hashed objects, and one removal in the middle affects all the subsequent hashes.

leafac

- `application/x-www-form-urlencoded`
  - `URLSearchParams`
  - <https://github.com/expressjs/body-parser>.
- `multipart/form-data`
  - <https://github.com/mscdex/busboy>.
    - <https://github.com/expressjs/multer>.
    - <https://github.com/richardgirges/express-fileupload>.
  - <https://github.com/node-formidable/formidable>.
    - Does too much (plugins, and so forth).

• .

leafac

• autocannon uses negligible CPU.

• Use yes > /dev/null to saturate one core.

• Stats shows an aggregate of all the CPU cores, just like the Activity Monitor lower pane. So if 1 out of 8 cores is saturated, you see 25% usage.

• In a Mac Mini with a M1 processor, the performance cores saturate first and the efficiency cores saturate last.

• Sending signals:

  ⌃C	SIGINT

| kill, Activity Monitor > Quit, Stats > Kill process, and so forth | SIGTERM |

leafac

• Worker threads
  • “Workers (threads) are useful for performing CPU-intensive JavaScript operations. They do not help much with I/O-intensive work. The Node.js built-in asynchronous I/O operations are more efficient than Workers can be.”
  • “Unlike child_process or cluster, worker_threads can share memory.”
  • But they can’t share server ports and they don’t come with load balancing
• https://www.npmjs.com/package/workerpool
  • Manage pool of workers (I suppose in case of crashes and things like that)
  • Makes it easier to pass values from and to worker
  • Makes it easier to define worker code inline, but the usefulness of that is limited, because it isn’t a real closure
• https://www.npmjs.com/package/piscina
• Less magical than workerpool, just handles pool

leafac

leafac

Teachable Machine

• https://teachablemachine.withgoogle.com/
• Approaches
  • Use Sharp and generate input tensors by hand
  • Use browser simulators
    • https://github.com/SashiDo/teachablemachine-node/
      • https://blog.sashido.io/how-to-load-a-teachable-machine-image-model-in-a-node-js-project/
    • https://github.com/googlecreativelab/teachablemachine-community
• https://github.com/drinkspiller/teachablemachine-node-example/

leafac

• Diagnostics tools
  • https://samltool.io/ is good for inspecting SAML requests and responses, but don’t trust its signature validation (keycloak/keycloak#22962)
  • https://www.samltool.com/online_tools.php is good for verifying signatures, but doesn’t show you the decoded request/response
• One key
  • https://www.stackallocated.com/blog/2020/saml-idp-no-shared-keys/
  • All Identity Providers
  • All purposes: signing & encrypting
  • All services: SAML & LTI (OAuth)
  • But metadata is different, because we use the URL to communicate the Identity Provider samlIdentifier, which is necessary to pick up the idpIssuer before we even decode the SAML Response.
• Pros of separate keys: