Look at LSB init scripts for more information.
Copy to /etc/init.d:
# replace "$YOUR_SERVICE_NAME" with your service's name (whenever it's not enough obvious)Look at LSB init scripts for more information.
Copy to /etc/init.d:
# replace "$YOUR_SERVICE_NAME" with your service's name (whenever it's not enough obvious)Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
Sublime Text 2 ships with a CLI called subl (why not "sublime", go figure). This utility is hidden in the following folder (assuming you installed Sublime in /Applications like normal folk. If this following line opens Sublime Text for you, then bingo, you're ready.
open /Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl
You can find more (official) details about subl here: http://www.sublimetext.com/docs/2/osx_command_line.html
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
| # Basically the nginx configuration I use at konklone.com. | |
| # I check it using https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com | |
| # | |
| # To provide feedback, please tweet at @konklone or email eric@konklone.com. | |
| # Comments on gists don't notify the author. | |
| # | |
| # Thanks to WubTheCaptain (https://wubthecaptain.eu) for his help and ciphersuites. | |
| # Thanks to Ilya Grigorik (https://www.igvita.com) for constant inspiration. | |
| server { |
| http { | |
| proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=one:8m max_size=3000m inactive=600m; | |
| proxy_temp_path /var/tmp; | |
| include mime.types; | |
| default_type application/octet-stream; | |
| sendfile on; | |
| keepalive_timeout 65; | |
| gzip on; | |
| gzip_comp_level 6; |
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