Abdul Rahman Zantout abedzantout

Title

<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>

URL

<The URL Structure (path only, no root url)>
Method:

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages

Kubectl plugin

This plugin adds completion for the Kubernetes cluster manager, as well as some aliases for common kubectl commands.

To use it, add kubectl to the plugins array in your zshrc file:

plugins=(... kubectl)

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

	#!/bin/bash
	PROJECT_NAME=MyApp
	SCHEME_NAME=MyApp
	STARTTIME=$(date +%s);

	set -e
	set -x

	### Install dependencies
	echo "--- Install dependencies [Time Elapsed $(($(date +%s) - $STARTTIME))s]"

	# Create a container from the mongo image,
	# run is as a daemon (-d), expose the port 27017 (-p),
	# set it to auto start (--restart)
	# and with mongo authentication (--auth)
	# Image used is https://hub.docker.com/_/mongo/
	docker pull mongo
	docker run --name YOURCONTAINERNAME --restart=always -d -p 27017:27017 mongo mongod --auth

	# Using the mongo "localhost exception" (https://docs.mongodb.org/v3.0/core/security-users/#localhost-exception)
	# add a root user

	const http2 = require('http2');
	const fs = require('fs');
	const path = require('path');
	const zlib = require('zlib');
	const brotli = require('brotli'); // npm package

	const PORT = 3032;
	const BROTLI_QUALITY = 11; // slow, but we're caching so who cares
	const STATIC_DIRECTORY = path.resolve(__dirname, '../dist/');
	const cache = {};