Get a VPS that offers 2 or more IP addresses.
From the WHM cPanel, find the menu item Service Configuration
, select Apache Configuration
and then click on Reserved IPs Editor
.
/* http://meyerweb.com/eric/tools/css/reset/ | |
v2.0 | 20110126 | |
License: none (public domain) */ | |
html, body, div, span, applet, object, iframe, | |
h1, h2, h3, h4, h5, h6, p, blockquote, pre, | |
a, abbr, acronym, address, big, cite, code, | |
del, dfn, em, img, ins, kbd, q, s, samp, | |
small, strike, strong, sub, sup, tt, var, | |
b, u, i, center, |
// A response to jashkenas's fine proposal for minimalist JavaScript classes. | |
// Harmony always stipulated classes as sugar, so indeed we are keeping current | |
// JavaScript prototype semantics, and classes would only add a syntactic form | |
// that can desugar to ES5. This is mostly the same assumption that Jeremy | |
// chose, but I've stipulated ES5 and used a few accepted ES.next extensions. | |
// Where I part company is on reusing the object literal. It is not the syntax | |
// most classy programmers expect, coming from other languages. It has annoying | |
// and alien overhead, namely colons and commas. For JS community members who |
A good commit message looks like this:
Header line: explaining the commit in one line
Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc etc.
The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
{ | |
"AL": "Alabama", | |
"AK": "Alaska", | |
"AS": "American Samoa", | |
"AZ": "Arizona", | |
"AR": "Arkansas", | |
"CA": "California", | |
"CO": "Colorado", | |
"CT": "Connecticut", | |
"DE": "Delaware", |
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
{-# LANGUAGE TemplateHaskell #-} | |
import Control.Lens | |
data Point = Point { | |
_x :: Double, | |
_y :: Double | |
} deriving (Show) | |
data Mario = Mario { _location :: Point } deriving (Show) |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');
Those suck for maintenance and they're ugly.
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".