Tested in Mac OS X: super == command
Open/Goto
- super+t: go to file
- super+ctrl+p: go to project
- super+r: go to methods
!------------------------------------------------------------------------------- | |
! Xft settings | |
!------------------------------------------------------------------------------- | |
Xft.dpi: 96 | |
Xft.antialias: false | |
Xft.rgba: rgb | |
Xft.hinting: true | |
Xft.hintstyle: hintslight |
@mixin ie6 { * html & { @content } } | |
#logo { | |
background-image: url("/images/logo.png"); | |
@include ie6 { background-image: url("/images/logo.gif"); } | |
} |
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
Short (72 chars or less) summary
More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages