Install Python
$ brew install readline sqlite gdbm
$ brew install python --universal --framework
$ python --version
Python 2.7
Symlinks...
Install Python
$ brew install readline sqlite gdbm
$ brew install python --universal --framework
$ python --version
Python 2.7
Symlinks...
# from https://libbits.wordpress.com/2011/04/09/get-total-rsync-progress-using-python/ | |
import subprocess | |
import re | |
import sys | |
print('Dry run:') | |
cmd = 'rsync -az --stats --dry-run ' + sys.argv[1] + ' ' + sys.argv[2] | |
proc = subprocess.Popen(cmd, | |
shell=True, |
This article is now published on my website: Prefer Subshells for Context.
git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."
bumpversion patch
<?php | |
if ($argc !== 2) | |
{ | |
die("Usage: php {$argv[0]} hypem_user_name\n\n"); | |
} | |
$user = $argv[1]; | |
$page = 1; | |
$all_songs = array(); |
# Create your superuser | |
$ mongo | |
> use admin | |
> db.createUser({user:"someadmin",pwd:"secret", roles:[{role:"root",db:"admin"}]}) | |
> exit | |
# Alias for convenience (optional and at your own risk) | |
$ echo 'alias mongo="mongo --port 27017 -u someadmin -p secret --authenticationDatabase admin"' >> ~/.bash_profile | |
$ source ~/.bash_profile |
Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important
or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?
Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right. | |
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it. | |
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately. | |
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions. | |
If you remove possibilities (for example, Swift removes the possibility of things being nil unless |