apoorvanand

Scaling your API with rate limiters

The following are examples of the four types rate limiters discussed in the accompanying blog post. In the examples below I've used pseudocode-like Ruby, so if you're unfamiliar with Ruby you should be able to easily translate this approach to other languages. Complete examples in Ruby are also provided later in this gist.

In most cases you'll want all these examples to be classes, but I've used simple functions here to keep the code samples brief.

Request rate limiter

This uses a basic token bucket algorithm and relies on the fact that Redis scripts execute atomically. No other operations can run between fetching the count and writing the new count.

apoorvanand

package main

import (
  //  "fmt"
    "os/exec"
    "os"
)

func main()  {
topCommand := exec.Command("top","-d 0.5", "-b", "-n 5")

apoorvanand

#!/bin/sh

# This assumes you have access to the system via SSH already, and need 
# remote VNC access as the same user, and you want only the primary display.
export DISPLAY=:0

# Encoded password with http://www.motobit.com/util/base64-decoder-encoder.asp
export VNC_PASSWORD="dm5jX3Bhc3N3b3JkNzE="  # vnc_password71
export VNC_PASSWORD="dm5jX3Bhc3M=" # vnc_password (a character limit is enforced?)
# Sadly many common VNC clients don't support encryption.

apoorvanand

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.IOException;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandler;
import java.time.Duration;
import java.util.concurrent.CompletableFuture;

apoorvanand

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

apoorvanand

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?

apoorvanand

from pprint import pprint

def binarySearch(alist, item):
    """
    binary search given alist and item to search for
    returns is element was found, otherwise return the last midpoint before search failed
    last midpoint is always either the predessecor or succesor to item (if the item is not found)
    """
    first = 0
    last = len(alist)-1

apoorvanand

class Solution:
    # @param A : list of integers
    # @param B : integer
    # @return a list of integers
    def dNums(self, A, B):
        mapOfNums = {}
        count = 0
        ptr = -1
        res = []
        if B > len(A) :

apoorvanand

GROKKING NOTES

I liked the way Grokking the coding interview organized problems into learnable patterns. However, the course is expensive and the majority of the time the problems are copy-pasted from leetcode. As the explanations on leetcode are usually just as good, the course really boils down to being a glorified curated list of leetcode problems.

So below I made a list of leetcode problems that are as close to grokking problems as possible.

Pattern: Sliding Window

• https://leetcode.com/problems/maximum-subarray/ # Close enough
• https://leetcode.com/problems/minimum-size-subarray-sum/

apoorvanand

from itertools import product

class SudokuSolver:
    """
    Solve a sudoku puzzle given as a 81-digit string with . denoting empty
    """

    SHAPE = 9
    GRID = 3
    EMPTY = '.'