General Cheatsheet

CRON

minute (0-59)
| hour(0-23)
| | day of month (1-31)
| | | month (1-12)
| | | | day of week (0-6) 0==Sunday
| | | | | command

| | | | | |
* * * * * /your/command/here.sh > /dev/null 2>&1

.bash_profile

addalias() { echo "alias $1='$2' " >> ~/.bash_profile; . ~/.bash_profile; }
alias 'll=ls -la | less -r'
alias 'unixtime=date +%s'

CLICOLOR=1
LSCOLORS=GxFxCxDxBxegedabagaced
PS1=\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[00m\]\$

Extracting an XPath value in 2 lines of code:
        Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder()
                .parse(new File("file.xml"));
        String myString = (String)XPathFactory.newInstance().newXPath()
                .compile("/rootelement/subelement/text()")
                .evaluate(doc, XPathConstants.STRING);

copy between S3 buckets:
aws --profile examplecap s3 sync s3://examplecap s3://examplecap-target --exclude "*" --include "*.geojson" --metadata-directive REPLACE --content-type "application/json" --cache-control "max-age=60"

---

Don't restrict usernames and passwords

Don't place tight restrictions on usernames and passwords.

• Keep the datasource id different from the username. That is, the user record in the database should use an id field with no business meaning, and another unique username field used for authentication. This way the username can be changed without touching database mappings. If display purposes are a concern, also keep a separate field for the display name, or screen name.
  
• Let users choose their own id. I can't stand it when I have to remember an arbitrary 12 digit number to sign-in to some site. I'll never remember it. A good idea is to allow email addresses to be the username, as this automatically provides some domain separation, i.e. jsmith might quickly be claimed, but jsmith@somecompany.com and jsmith@anothercompany.com will keep both users happy. People don't forget their email addresses.
• Be open with allowed characters and lengths in usernames and passwords. It drives me nuts when I have to pick a username between 6 and 10 characters, and a password that must be at least 8 characters and include some mix of special characters. The rationale of a password minimum is to increase its cryptographic 'strength': to keep it less guess-able from a log-in screen and harder to crack if the encrypted version is discovered. Bollocks. If you have people running unobstructed cracking scripts against your app or datasource, you have much bigger problems than the irritated users you're losing because of your draconian username/password policy. At a minimum, allow ats (@), periods (.), dashes (-), and underscores (_) along with letters and digits to satisfy email addresses. If you must state a policy, don't set minimum lengths higher than 6 (username and password must both be 6 or more characters).
• Always give users a self-service way to change their password. This might seem obvious, but I have to deal with several corporate intranet apps that won't let me change my password to something I can remember. The result is I either have my browser remember the password for me, or write I it on a post-it note somewhere in my cube. So much for cryptographic 'strength'...
  
• Always give users a self-service way to obtain forgotten passwords. If they know their username (especially easy to remember when your username is also your email address) and can answer a security question, send a temporary password to the email address. Once it's used, require the user to set a new one.