⌘T | go to file |
⌘⌃P | go to project |
⌘R | go to methods |
⌃G | go to line |
⌘KB | toggle side bar |
⌘⇧P | command prompt |
@mixin gradient($from, $to) { | |
/* fallback/image non-cover color */ | |
background-color: $from; | |
/* Firefox 3.6+ */ | |
background-image: -moz-linear-gradient($from, $to); | |
/* Safari 4+, Chrome 1+ */ | |
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from($from), to($to)); |
* Smartphones (portrait and landscape) ----------- */ | |
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) { | |
/* Styles */ | |
} | |
/* Smartphones (landscape) ----------- */ | |
@media only screen and (min-width : 321px) { | |
/* Styles */ | |
} |
This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array
it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array
part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
/* | |
<a href="posts/2" data-method="delete"> <---- We want to send an HTTP DELETE request | |
- Or, request confirmation in the process - | |
<a href="posts/2" data-method="delete" data-confirm="Are you sure?"> | |
*/ | |
(function() { |
Linux - create "Default (Linux).sublime-mousemap" in ~/.config/sublime-text-3/Packages/User | |
Mac - create "Default (OSX).sublime-mousemap" in ~/Library/Application Support/Sublime Text 3/Packages/User | |
Win - create "Default (Windows).sublime-mousemap" in %appdata%\Sublime Text 3\Packages\User | |
[ | |
{ | |
"button": "button1", | |
"count": 1, | |
"modifiers": ["ctrl"], | |
"press_command": "drag_select", |
FILE SPACING: | |
# double space a file | |
sed G | |
# double space a file which already has blank lines in it. Output file | |
# should contain no more than one blank line between lines of text. | |
sed '/^$/d;G' |
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:
- Go HTTP standalone (as the control group)
- Nginx proxy to Go HTTP
- Nginx fastcgi to Go TCP FastCGI
- Nginx fastcgi to Go Unix Socket FastCGI
Moved to git-repository: https://github.com/denji/awesome-http-benchmark
Located in alphabetical order (not prefer)
- ab – slow and single threaded, written in
C
- apib – most of the features of ApacheBench (
ab
), also designed as a more modern replacement, written inC
- autocannon – fast HTTP/1.1 benchmarking tool written in Node.js
- baloo – Expressive end-to-end HTTP API testing made easy, written in Go (
golang
)