We Gophers, love table-driven-tests, it makes our unittesting structured, and makes it easy to add different test cases with ease.
Let’s create our table driven test, for convenience, I chose to use t.Log
as the test function.
Notice that we don't have any assertion in this test, it is not needed to for the demonstration.
func TestTLog(t *testing.T) {
t.Parallel()
Edit Dockerfile to enable JMX server and change the hostname with the IP where the container will run:
FROM openjdk:8-jre-alpine
ADD ./target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT java -Dcom.sun.management.jmxremote.rmi.port=9090 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=192.168.1.2 -jar app.jar
I wanted to run Microk8s on a Proxmox 6 host inside of an LXC container. These are my notes from the journey.
- Create a privileged LXC container through the Proxmox web interface
- Enable nesting and FUSE
- In Proxmox UI, select container, then Options > Features > Check nesting and FUSE boxes
- SSH into the Proxmox host and edit the container's config in /etc/pve/lxc/.conf
- Add the following lines
- lxc.apparmor.profile: unconfined
let pancakeSwapAbi = [ | |
{"inputs":[{"internalType":"uint256","name":"amountIn","type":"uint256"},{"internalType":"address[]","name":"path","type":"address[]"}],"name":"getAmountsOut","outputs":[{"internalType":"uint256[]","name":"amounts","type":"uint256[]"}],"stateMutability":"view","type":"function"}, | |
]; | |
let tokenAbi = [ | |
{"inputs":[],"name":"decimals","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"}, | |
]; | |
const Web3 = require('web3'); | |
/* | |
Required Node.js |
When designing or learning about APIs or microservices, it's crucial to consider error handling. API's designer often categorize errors into "Technical" and "Functional" (or "Business") errors. However, this distinction may not make sense:
- An API/micro-service should alway return ONLY "Functional" (or "Business") errors.
- The API/micro-service migh crash while processing a consumer's request and so the consumer will naturally get a technical error. But the API/micro-service should not deliberately return a "Technical" error for consumer.
We will explore the distinction between "real technical errors" and "fake technical errors," which are initially technical but later manifest as business errors, thus becoming "fake technical errors."
- HTTP 404 Business error (or Fake technical error)
import requests | |
import time | |
import os | |
import sys | |
import openai | |
import tiktoken | |
from termcolor import colored | |
openai.api_key = open(os.path.expanduser('~/.openai')).read().strip() |
/* | |
Corlin Palmer's Go solution to the 1BRC coding challenge: https://github.com/gunnarmorling/1brc | |
- This solution reads the file sequentially as fast as possible (reader) | |
- It passes off the job of ensuring that each chunk ends with a complete line to another goroutine (lineSupervisor) | |
- The lineSupervisor sends valid chunks to a pool of worker goroutines (worker) which parse the data and calculate the results | |
- The results from the workers are collected in a map and then sorted before printing the final results | |
A fair amount of optimization has been done to reduce memory allocations. |