veekaybee

Anti-hype LLM reading list

Goals: Add links that are reasonable and good explanations of how stuff works. No hype and no vendor content if possible. Practical first-hand accounts of models in prod eagerly sought.

Foundational Concepts

Pre-Transformer Models

jim80net

javascript: (function () {
  main();

  function extractText(element) {
    if (element.nodeType === Node.TEXT_NODE) {
      return element.textContent.trim() + ' ';
    }
    if (element.nodeType !== Node.ELEMENT_NODE) {
      return '';
    }

expelledboy

#!/bin/bash

# !!WARNING!!
# This will DELETE all efforts you have put into configuring nix
# Have a look through everything that gets deleted / copied over

nix-env -e '.*'

rm -rf $HOME/.nix-*
rm -rf $HOME/.config/nixpkgs

timotree3

#!/bin/bash
if [ -n "$(gofmt -s -l .)" ]; then
        echo "\`gofmt -s -w .\` your code."
        exit 1
fi

wdullaer

# Ask for the user password
# Script only works if sudo caches the password for a few minutes
sudo true

# Install kernel extra's to enable docker aufs support
# sudo apt-get -y install linux-image-extra-$(uname -r)

# Add Docker PPA and install latest version
# sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
# sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"

arobson

Abstraction Suggestions

Summary: use good/established messaging patterns like Enterprise Integration Patterns. Don't make up your own. Don't expose transport implementation details to your application.

Broker

As much as possible, I prefer to hide Rabbit's implementation details from my application. In .Net we have a Broker abstraction that can communicate through a lot of different transports (rabbit just happens to be our preferred one). The broker allows us to expose a very simple API which is basically:

• publish
• request
• start/stop subscription

etrepat

#!/bin/bash

BUNDLED_COMMANDS="${BUNDLED_COMMANDS:-
cap
capify
cucumber
foreman
guard
haml
heroku

jcasimir

Sessions and Conversations

HTTP is a stateless protocol. Sessions allow us to chain multiple requests together into a conversation between client and server.

Sessions should be an option of last resort. If there's no where else that the data can possibly go to achieve the desired functionality, only then should it be stored in the session. Sessions can be vulnerable to security threats from third parties, malicious users, and can cause scaling problems.

That doesn't mean we can't use sessions, but we should only use them where necessary.

Adding, Accessing, and Removing Data