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()
Note
to active Office without crack, just follow https://github.com/WindowsAddict/IDM-Activation-Script,
you wiil only need to run
irm https://massgrave.dev/ias | iex
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 |
<!-- Sentry.js Config --> | |
<script src="https://js.sentry-cdn.com/{{ENV['SENTRY_PUBLIC_DSN']}}.min.js" type="text/javascript"></script> | |
<script type="text/javascript"> | |
// custom functions to handle errors in JS. | |
function handleRouteError(err) { | |
Sentry.captureException(err); | |
} | |
function errorHandler(error, data, level) { | |
level = level || 'info'; |
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 always return ONLY "Functional" (or "Business") errors.
- The API/micro-service migh be crashed 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. The simple fact that the App built a nice response called "Technical error", then gracefully return it, make it no longer a technical error, but a "fake" one.
We will explore the distinction between "real technical errors" and "fake technical errors". "Fake technical errors" are initially technical but later manifest as business errors, thus becoming "fake technical errors."
- HTTP 404 Business error (or Fake technical error)