Todd Hoff at High Scalability – Strategy: Solve Only 80 Percent of the Problem:
"Sometimes as programmers we are blinded by the glory of the challenge of solving the 100% solution when there's a more reasonable, rational alternative that's almost as good. Something to keep in mind when you are wondering how you'll possibly get it all done. Don't even try."
Another thing I keep forgetting in vi / vim:
:%s/search/replace/g
Joe 'Zonker' Brockmeier at Linux.com – Vim tips: The basics of search and replace
I keep forgetting this line…
cat ~/.ssh/id_dsa.pub | ssh user@host 'cat >> .ssh/authorized_keys'
Update – you might instead want to try:
cat ~/.ssh/id_rsa.pub | ssh user@host 'cat >> .ssh/authorized_keys'
If it still doesn’t work, check the file permissions: 0700 on the .ssh directory and 0644 on the authorized_keys file are working for me, 0664 on authorized_keys isn’t.
Thanks to Mathias Kettner – SSH login without password.
Update: See Gert van Dijk – Upgrade your SSH keys!
Update (2017-06-19): For a while, it seemed one should use .ssh/authorized_keys2 instead. Someday I’ll take the time to actually learn about this…
Jason Morrison – Twelve dollars for five words? What is the Associated Press thinking?:
"No, I am not making this up. The AP is really asking people to pay them $12.50 if they quote more than four words of any story.
[…] How would the AP operate if every source they quoted demanded payment up front?"
Kas Thomas at CMS Watch – Thinking beyond the RFP:
"Don't ask "How will you be able to handle XYZ?" unless you're willing to tolerate answers like "Our standard user interface allows a user to do this" or "our application programming interface allows the product to be easily extended so as to accomplish this."
Instead, write a user narrative or concrete scenario for every one of your key requirements, and demand a narrative answer in response. For example, rather than ask whether a product natively supports delegation of authority in workflows, compose a concrete user narrative."
Eric Ries – The Steve Jobs method:
"Having so few products means Apple can dedicate enormous resources to each project once it gets the green light. But it also means they have to be very careful kill projects if they are not trending towards something great. Which comes to the second major principle: halt work that leads to more waste, even if it means abandoning sunk costs."
