A "Best of the Best Practices" (BOBP) guide to developing in Python.
- "Build tools for others that you want to be built for you." - Kenneth Reitz
- "Simplicity is alway better than functionality." - Pieter Hintjens
mkdir ~/vim | |
cd ~/vim | |
# Staically linked vim version compiled from https://github.com/ericpruitt/static-vim | |
# Compiled on Jul 20 2017 | |
curl 'https://s3.amazonaws.com/bengoa/vim-static.tar.gz' | tar -xz | |
export VIMRUNTIME="$HOME/vim/runtime" | |
export PATH="$HOME/vim:$PATH" | |
cd - |
Original post : https://unix.stackexchange.com/a/310699
nmcli con add type wifi ifname wlan0 con-name Hostspot autoconnect yes ssid Hostspot
nmcli con modify Hostspot 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared
nmcli con modify Hostspot wifi-sec.key-mgmt wpa-psk
nmcli con modify Hostspot wifi-sec.psk "veryveryhardpassword1234"
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
'use strict'; | |
exports.handler = (event, context, callback) => { | |
// Get request and request headers | |
const request = event.Records[0].cf.request; | |
const headers = request.headers; | |
// Configure authentication | |
const authUser = 'user'; | |
const authPass = 'pass'; |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
#!/bin/bash | |
# bash generate random alphanumeric string | |
# | |
# bash generate random 32 character alphanumeric string (upper and lowercase) and | |
NEW_UUID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) | |
# bash generate random 32 character alphanumeric string (lowercase only) | |
cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 32 | head -n 1 |
# import modules | |
import random | |
import datetime | |
# create function accepting a single parameter, the year as a four digit number | |
def get_random_date(year): | |
# try to get a date | |
try: | |
return datetime.datetime.strptime('{} {}'.format(random.randint(1, 366), year), '%j %Y') |
Notes from the Mystery Machine Bus
I've spent the past eight years (starting back in June 2004) writing elaborate rants about a bunch of vaguely related software engineering issues.
I was doing all that ranting because I've been genuinely perplexed by a set of "bizarre" world-views held dear by -- as far as I can tell -- about half of all programmers I encounter, whether online or in person.
Last week, after nearly a decade of hurling myself against this problem, I've finally figured it out. I know exactly what's been bothering me.
In today's essay I'm going to present you with a new conceptual framework for thinking about software engineering. This set of ideas I present will be completely obvious to you. You will probably slap yourself for not having thought of it yourself. Or you might slap the person next to you. In fact you probably have thought of it yourself, because it is so blindingly obvious.