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.
#!/usr/bin/env -S bash -c "docker run -p 8080:8080 -it --rm \$(docker build --progress plain -f \$0 . 2>&1 | tee /dev/stderr | grep -oP 'sha256:[0-9a-f]*')" | |
# syntax = docker/dockerfile:1.4.0 | |
FROM node:20 | |
WORKDIR /root | |
RUN npm install sqlite3 |
Lecture 1: Introduction to Research — [📝Lecture Notebooks] [
Lecture 2: Introduction to Python — [📝Lecture Notebooks] [
Lecture 3: Introduction to NumPy — [📝Lecture Notebooks] [
Lecture 4: Introduction to pandas — [📝Lecture Notebooks] [
Lecture 5: Plotting Data — [📝Lecture Notebooks] [[
In response to this brief blog entry, @antirez tweeted for some documentation on high-performance techniques for Redis. What I present here are general high-performance computing (HPC) techniques. The examples are oriented to Redis. but they work well for any program designed to be single- or worker-threaded and asynchronous (e.g. uses epoll).
The motivation for using these techniques is to maximize performance of our system and services. By isolating work, controlling memory, and other tuning, you can achieve significant reduction in latency and increase in throughput.
My perspective comes from the microcosm of my own bare-metal (vs VM), on-premises deployment. It might not be suitable for all scenarios, especially cloud deployments, as I have little experience with HPC there. After some discussion, maybe this can be adapted as [redis.io documentation](https://redis.io/do
#!/bin/bash | |
# Set PATH | |
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | |
# Run the certbot container to renew the certs | |
docker-compose -f /opt/docker/certbot/docker-compose.yml run --rm certbot | |
# Concatenate the resulting certificate chain and the private key and write it to HAProxy's certificate file. | |
cat /opt/docker/certbot/certbot/etc/letsencrypt/live/example.org/{fullchain,privkey}.pem > /opt/docker/haproxy/ssl/example_org.pem |
Hosting multiple websites on a single public IP address on the standard HTTP(S) ports is relatively easy with popular web servers like Apache, Nginx and lighttpd all supporting Virtual Hosts.
For Web Services which bundle their own HTTP server, things get more complicated, unless their HTTP stack can be shared somehow. More often than not, the application's HTTP stack listens directly on a dedicated TCP port.
Hosting multiple services on a single IP then requires using a fronting server listening on the standard HTTP port, and routing to the right backend service based on the host name or the path sent by the client.
Path based routing is cumbersome, usually requiring either the service to be aware of the path prefix, or a rewrite by the HTTP fronting server of all absolute URLs in the requests and responses.
Hostname based routing is more straightforward. The fronting server can just look at the [HTTP/1.1 Host header](https://tools
Moved to Shopify/graphql-design-tutorial
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
#!/bin/sh | |
# /etc/NetworkManager/dispatcher.d/pre-up.d/randomize-mac-addresses.sh | |
# INSTALL | |
# | |
# > curl -L 'https://gist.github.com/paulfurley/46e0547ce5c5ea7eabeaef50dbacef3f/raw/56ee5dd5f40dec93b8f7438cbdeda5475ea3b5d2/randomize-mac-addresses.sh' |sudo tee /etc/NetworkManager/dispatcher.d/pre-up.d/randomize-mac-addresses.sh | |
# > sudo chmod +x /etc/NetworkManager/dispatcher.d/pre-up.d/randomize-mac-addresses.sh | |
# Configure every saved WiFi connection in NetworkManager with a spoofed MAC |
# /etc/NetworkManager/conf.d/30-randomize-mac-address.conf | |
# REQUIRES NETWORK MANAGER >= 1.4.1 (Ubuntu Zesty and above) | |
# Thanks to https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ | |
# This randomize your MAC address for *new* connections | |
# Be sure to change your existing (saved) connections in | |
# /etc/NetworkManager/system-connections/* |