⚠ This post is fairly old. I don't keep it up to date. Be sure to see comments where some people have posted updates
What this will cover
www.website.com to website.comindex.html)
| find `pwd` -type d -maxdepth 3 -name 'node_modules' | xargs -n 1 tmutil addexclusion |
type below:
brew update
brew install redis
To have launchd start redis now and restart at login:
brew services start redis
Incorporates changes by 0mnius.
The intent is to define terse, standards-supported names for AWS regions.
| // Restify Server CheatSheet. | |
| // More about the API: http://mcavage.me/node-restify/#server-api | |
| // Install restify with npm install restify | |
| // 1.1. Creating a Server. | |
| // http://mcavage.me/node-restify/#Creating-a-Server | |
| var restify = require('restify'); |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
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
| #!/bin/sh | |
| ### | |
| # SOME COMMANDS WILL NOT WORK ON macOS (Sierra or newer) | |
| # For Sierra or newer, see https://github.com/mathiasbynens/dotfiles/blob/master/.macos | |
| ### | |
| # Alot of these configs have been taken from the various places | |
| # on the web, most from here | |
| # https://github.com/mathiasbynens/dotfiles/blob/5b3c8418ed42d93af2e647dc9d122f25cc034871/.osx |
| Bold Text | |
| *this is bold* | |
| =========================== | |
| Italic text | |
| _this is italic_ |
