How to set up multiple accounts with Mutt E-mail Client
Thanks to this article by Christoph Berg
Directories and files
~/
Thanks to this article by Christoph Berg
Directories and files
~/
# Idempotent way to build a /etc/hosts file with Ansible using your Ansible hosts inventory for a source. | |
# Will include all hosts the playbook is run on. | |
# Inspired from http://xmeblog.blogspot.com/2013/06/ansible-dynamicaly-update-etchosts.html | |
- name: "Build hosts file" | |
lineinfile: dest=/etc/hosts regexp='.*{{ item }}$' line="{{ hostvars[item].ansible_default_ipv4.address }} {{item}}" state=present | |
when: hostvars[item].ansible_default_ipv4.address is defined | |
with_items: groups['all'] |
echo 'export PATH=$HOME/local/bin:$PATH' >> ~/.bashrc | |
. ~/.bashrc | |
mkdir ~/local | |
mkdir ~/node-latest-install | |
cd ~/node-latest-install | |
curl http://nodejs.org/dist/node-latest.tar.gz | tar xz --strip-components=1 | |
./configure --prefix=~/local | |
make install # ok, fine, this step probably takes more than 30 seconds... | |
curl https://www.npmjs.org/install.sh | sh |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
# This is a template .gitignore file for git-managed WordPress projects. | |
# | |
# Fact: you don't want WordPress core files, or your server-specific | |
# configuration files etc., in your project's repository. You just don't. | |
# | |
# Solution: stick this file up your repository root (which it assumes is | |
# also the WordPress root directory) and add exceptions for any plugins, | |
# themes, and other directories that should be under version control. | |
# | |
# See the comments below for more info on how to add exceptions for your |
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
brew update | |
brew versions FORMULA | |
cd `brew --prefix` | |
git checkout HASH Library/Formula/FORMULA.rb # use output of "brew versions" | |
brew install FORMULA | |
brew switch FORMULA VERSION | |
git checkout -- Library/Formula/FORMULA.rb # reset formula | |
## Example: Using Subversion 1.6.17 | |
# |
HTTP Archive (powered by HAR files): www.httparchive.org
HAR Viewer: http://code.google.com/p/harviewer/
<?php | |
/* | |
* (c) Mark Badolato <mbadolato@gmail.com> | |
* | |
* This content is released under the {@link http://www.opensource.org/licenses/MIT MIT License.} | |
*/ | |
namespace Bado; |