| // Package main is a CLI runner to run this script ('github-unfollowers.go'). | |
| // This script is used to get a user's 'unfollowers' - which means people who do not follow that user's back. | |
| // You do not need GitHub Tokens, as all the endpoints are public. Use this with responsibility though, do not spam. | |
| // | |
| // How to run: copy this script to a workspace, place your username, then run 'go run github-unfollowers.go' | |
| // You can place your username by using 'export GITHUB_USERNAME=YOUR_GITHUB_USERNAME' or by editing the source code and filling it manually. | |
| // | |
| // Author & License: Nicholas (MIT) | |
| package main |
| import { type Key, useSWR } from 'swr'; | |
| /** | |
| * Fetcher is created to be used with `useSWR` hook. | |
| * | |
| * @param url - URL of the endpoint. | |
| * @returns JSON response of the resulting request. | |
| */ | |
| const fetcher = async (url: string) => { | |
| const res = await fetch(url); |
We have got a bit of a problem. How do I use nodemailer without toggling 'Less Secure App Access' and/or using OAuth2 in Google Developers?
Google developed a concept called App Passwords, and it's something that you can use in order to circumvent this issue.
Below are the steps you need to take:
| /** | |
| * You need Node.js, TypeScript, and NanoID. Use `npm i nanoid` in a sample project to test things out! | |
| * Steps: | |
| * - Create a folder, for example `mkdir aes-test` then `cd aes-test`. | |
| * - Copy this script and create a file, for example `index.ts`. | |
| * - Paste the file there. | |
| * - `npm i nanoid ts-node-dev`. | |
| * - `npm run ts-node-dev .`. | |
| * - Profit! | |
| */ |
This note is made to provide knowledge on how to set up your own Raspberry Pi for personal development on your own Wi-Fi network. It does not necessarily have to be a Raspberry Pi, you can do it with any server / instance on Cloud as well (EC2, Compute Engine, Droplets, and the like).
As this is made for development, this is not suitable for production environments due to performance, security, and efficiency issues. Please adjust accordingly if you want to use this in production environments.
Personally, I am using a Raspberry Pi 4. It is equipped with 8GB RAM and I installed a 64GB MicroSD on it to act as its storage. My Raspberry Pi has the following software specifications:
Yeah, we know that sometimes Raspberry Pi loves to lose its internet connection. Once that is done, you have to unplug and replug it again, which is a real pain.
This helps to mitigate that issue. There are two scripts:
Choose one and let's explore both of them!
| // Codesandbox: https://codesandbox.io/s/silly-wu-0fz2t1 | |
| import React, { useState, useRef } from "react"; | |
| import ReactDOM from "react-dom/client"; | |
| import { ChakraProvider } from "@chakra-ui/react"; | |
| import { | |
| Controller, | |
| useForm, | |
| useFormState, | |
| useFieldArray |
| // mkdir zod-deep-merge-experiement | |
| // Copy and paste this code to your editor, save as `index.ts` | |
| // yarn init --yes | |
| // yarn add ts-node zod typescript @types/node | |
| // yarn run tsc --init | |
| // yarn run ts-node . | |
| import { strict as assert } from "node:assert"; | |
| import { z } from "zod"; |
| import { useCallback, useEffect, useMemo, useState } from "react"; | |
| /** | |
| * State utilizes TypeScript's type system to our advantage. Having a discriminated union | |
| * would make sense here because each state could have their own unique attributes. Being | |
| * declarative here would make it more readable and easier to understand, compared to using | |
| * imperative statements such as creating multiple states (`data`, `isLoading`, `error`) and | |
| * then having them to rely on each other, which also doesn't work that well because of the | |
| * TypeScript's type system being unable to understand dependant variables without making it | |
| * to be a discriminated union. |
