Add launch.json
into the .vscode
folder.
Now, enter the Debug view. Either add debugger
into one of the tests or add breakpoints, before you execute one of the scripts.
Dockerized: V2ray + WebSocket + TLS + Web
also see: https://toutyrater.github.io/advanced/wss_and_web.html
Server side sontents:
Client side contents:
node: Platform built on V8 to build network applications | |
git: Distributed revision control system | |
wget: Internet file retriever | |
yarn: JavaScript package manager | |
python3: Interpreted, interactive, object-oriented programming language | |
coreutils: GNU File, Shell, and Text utilities | |
pkg-config: Manage compile and link flags for libraries | |
chromedriver: Tool for automated testing of webapps across many browsers | |
awscli: Official Amazon AWS command-line interface | |
automake: Tool for generating GNU Standards-compliant Makefiles |
FROM ruby:2.3.1 | |
# Install dependencies | |
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs | |
# Set an environment variable where the Rails app is installed to inside of Docker image: | |
ENV RAILS_ROOT /var/www/app_name | |
RUN mkdir -p $RAILS_ROOT | |
# Set working directory, where the commands will be ran: |
Helper setup to edit .yaml files with Vim:
List of general purpose commands for Kubernetes management:
A lot of people run into the problem of running Let's Encrypt's CertBot Tool and an NGINX on the same container host. A big part of this has to do with CertBot needing either port 80 or 443 open for the tool to work as intended. This tends to conflict with NGINX as most people usually use port 80 (HTTP) or 443 (HTTPS) for their reverse proxy. Section 1 outlines how to configure NGINX to get this to work, and Section 2 is the Docker command to run CertBot.
I use Docker Compose (docker-compose) for my NGINX server. My docker-compose.yml file looks something like this:
docker-compose -f docker-compose.apache.yml up
docker-compose -f docker-compose.nginx+apache.yml up
docker-compose -f docker-compose.nginx+php-fpm.yml up
#! /usr/bin/env python | |
# Standard library imports. | |
from SocketServer import ThreadingMixIn | |
import BaseHTTPServer | |
import SimpleHTTPServer | |
import sys | |
import json | |
import os | |
from os.path import (join, exists, dirname, abspath, isabs, sep, walk, splitext, |
by Gavin Lazar Suntop @gvn
I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.
My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.
# Reconfigures ActionDispatch's TLD handling dynamically based on the request | |
# host, so you don't have to mess with config.action_dispatch.tld_length for | |
# cross-device testing using xip.io and friends | |
# | |
# Examples: | |
# use Rack::HostBasedTldLength, /xip\.io/, 5 | |
class Rack::HostBasedTldLength | |
def initialize(app, host_pattern, host_tld_length) | |
@app = app |