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
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
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
| # read more at https://terrty.net/2014/ssl-tls-in-nginx/ | |
| # latest version on https://gist.github.com/paskal/628882bee1948ef126dd/126e4d1daeb5244aacbbd847c5247c2e293f6adf | |
| # security test score: https://www.ssllabs.com/ssltest/analyze.html?d=terrty.net | |
| # your nginx version might not have all directives included, test this configuration before using in production against your nginx: | |
| # $ nginx -c /etc/nginx/nginx.conf -t | |
| server { | |
| # public key, contains your public key and class 1 certificate, to create: | |
| # (example for startssl) | |
| # $ (cat example.com.pem & wget -O - https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem) | tee -a /etc/nginx/ssl/domain.pem > /dev/null |
| // ==UserScript== | |
| // @name unfix-all-the-toolbars | |
| // @description Removes "position: fixed" style from elements, unfixing "toolbars" and the such. | |
| // @namespace https://hasanyavuz.ozderya.net | |
| // @include * | |
| // @version 1 | |
| // @grant none | |
| // ==/UserScript== | |
| // paste in your console | |
| speechSynthesis.onvoiceschanged = function() { | |
| var msg = new SpeechSynthesisUtterance(); | |
| msg.voice = this.getVoices().filter(v => v.name == 'Cellos')[0]; | |
| msg.text = Object.keys(window).join(' '); | |
| this.speak(msg); | |
| }; |
Git for Windows comes bundled with the "Git Bash" terminal which is incredibly handy for unix-like commands on a windows machine. It is missing a few standard linux utilities, but it is easy to add ones that have a windows binary available.
The basic idea is that C:\Program Files\Git\mingw64\ is your / directory according to Git Bash (note: depending on how you installed it, the directory might be different. from the start menu, right click on the Git Bash icon and open file location. It might be something like C:\Users\name\AppData\Local\Programs\Git, the mingw64 in this directory is your root. Find it by using pwd -W).
If you go to that directory, you will find the typical linux root folder structure (bin, etc, lib and so on).
If you are missing a utility, such as wget, track down a binary for windows and copy the files to the corresponding directories. Sometimes the windows binary have funny prefixes, so
