Default settings of the application is provided by the upstream, therefore, it should not be modified.
There are four types of environments: development, testing, staging and production. Environment can be set by using the shell environment variable: ENV. If the environment variable is not specified, it is set to development as default. Environment settings override default settings.
Custom settings override environment settings. The search path for custom settings is:
Environment variable SETTINGS
config/settings.yml
If both paths are not available, that means the custom settings are not specified.
config/settings.yml is a custom settings, therefore, it will be ignored by git in .gitignore file:
config/settings.yml
The complete directory structure regarding to the configuration setup:
If you are writing in CoffeeScript, then requiring another module written in CoffeeScript works the same as as both scripts are in JavaScript:
1
cm = require'coffee-module'
But if you are writing in JavaScript, and the dependent module is in CoffeeScript, you have to include CoffeeScript as a dependency with require statement:
1
2
require('coffee-script');
var cm = require('coffee-module');
For better compatibility, source codes written in CoffeeScript should be compiled into JavaScript. But what is the best practice? You don’t want to maintain two languages. When to compile? Here is two options:
Compile before publish the module
Compile after module install
The advantage of the first approach is that there is no dependency on CoffeeScript. The module has been compiled into JavaScript prior to submitting to module registry. However, this approach requires two repositories, one is source code repository, and another one is the published module repository. If you are working on a private project, it is less likely that you will publish your module to an public NPM registry or running your own private one. It is more likely to have a single source code repository. Therefore, the second approach might be better in this situation. However, coffee-script must be added in dependency, or it must be installed globally with coffee command available during preinstall phase. Although this approach is not recommended in npm-scripts, before setting up a private NPM registry, this is the way to go.
sshuttle is a very simple tool to create a VPN connection to a remote server that you have SSH access. You do not need to set up the complex VPN in a remote machine.
Requirements:
Root access on local machine
SSH access to a remote machine
Install:
$ sudo apt-get install sshuttle
Usage:
$ sshuttle --dns -vvr username@sshserver0/0
0/0 is the shortcut for 0.0.0.0/0. --dns enables DNS queries to be proxied. Note that sudo is not needed but will be prompted.
On the morning of November 22, 2013, the Sun was yet to rise behind all the tall buildings. I was up and preparing to leave Hong Kong. Streets were quiet, the taxi driver was still stretching his arms while waiting us outside. I was in Hong Kong for a month and working remotely. As a startup founder, there is always a drive to explore the local startup culture and scene.
Hong Kong government is actively promoting and attracting talents into the region. They have built a Science & Technology Parks for concentrating researchers, entrepreneurs and student into a Silicon Valley alike location. The program like Incu-App is most closely resemble to startup incubator/accelerator.
This is a community in a small scale, you need the bigger community support. So, I went to watch the pitch event in CoCoon (a co-working space). There were 5 companies, 3 of them are ecommerce companies, selling products originated in Hong Kong or nearby to Western audience. The quality of pitch (presentation and slides) were quite bad.
Set aside the pitch for now. I chatted with a few founders after the event, one of the issues people here face here is the lack of funding. Funding is difficult here, might be better than before, but still so far away comparing to the US. They actually limit the entrepreneurs here to bootstrap and get to profit earlier. Ecommerce is obviously an easy way to go. But it does not mean that you cannot dream bigger. It might just take longer to get to where you want to go. Sometimes it is not a bad thing. Good stuff takes a longer and more troubled journey.
I think this comes down to the mindset of people here. The mindset of entrepreneurs here are much narrower than entrepreneurs from Silicon Valley, New York or other places. Finance and entertainment are still dominant factors here. As the influence of mainland Chinese companies and integration of transportation, it is going to make it harder and harder for it becoming a tech hub.
Let’s end with a positive note there. Food and tech go hand to hand. Just by walking downstairs, I was at a shopping mall. Inside the shopping mall, there are restaurants with variety of food. Don’t like those, take an indoor sky bridge or subway tunnels across the street to the adjacent mall, there are more restaurants and more food. You can get everything you need without going outside to the streets. But if you do, every street corner is a new exploration. For authenticated Chinese food, there is nothing you can beat that.
Hong Kong has its special place, but in tech, it needs a lot of work.
But not all servers support ping, pings might be dropped altogether. Also, even a server does support ping, it does not mean that you can browser the website hosted by the server. The port might get blocked, or server is down.
Frequently the initial two characters on the initial line of a script are: #!.
Why Shebang? Well, simple reason, because shell needs to know which interpreter to use when executing the script.
The sha-bang (#!) at the head of a script tells your system that this file is a set of commands to be fed to the command interpreter indicated. The #! is actually a two-byte magic number, a special marker that designates a file type, or in this case an executable shell script (type man magic for more details on this fascinating topic). Immediately following the sha-bang is a path name. This is the path to the program that interprets the commands in the script, whether it be a shell, a programming language, or a utility. This command interpreter then executes the commands in the script, starting at the top (the line following the sha-bang line), and ignoring comments. - Starting Off With a Sha-Bang
The shebang line is usually ignored by the interpreter because the # character is a comment marker in many scripting languages. Even the actual script is written with a different commenting character, such as in JavaScript:
1
2
#!/usr/bin/env node
// JavaScript stuff starts here.
Because the first line is interpreted by the shell, and the rest is passed into JavaScript interpreter, in this case, Node.
The syntax of shebang:
#! interpreter [optional-arg]
Whether there is a space between shebang character and the interpreter or not, it does not matter.
The interpreter must usually be an absolute path to a program that is not itself a script. The following are example interpreters:
1
2
#! /bin/sh
#! /bin/bash
More examples are via head -n 1 /etc/init.d/*.
The optional‑arg should either not be included or it should be a string that is meant to be a single argument (for reasons of portability, it should not contain any whitespace). - Shebang_(Unix)
We also frequently see the following shebang:
1
#!/usr/bin/env bash
That has to do with portability. Not every system install node or bash command in the same path. /usr/bin/env will search through user’s $PATH, and correctly locate the executable.
To conclude for Node, here is the format I am using:
When I am editting comments in my code, I would like to use Docco to generate a pretty print source code documentation and review it in web browser. However, every time I made a change, I had to issue docco command again, even I could use the up arrow key, but still a pain. Lucky, there is a way to eliminate this step. One way is to use grunt-contrib-watch, but the limitation is that this is not for an individual file on the command line, it is more for a build process. A better alternative is to use nodemon:
For use during development of a node.js based application. nodemon will watch the files in the directory that nodemon was started, and if they change, it will automatically restart your node application.
It does not have to be limited to Node and JavaScript files. We can use it with any command:
nodemon -x docco /path/to/app.coffee
With this command, docco will be executed upon any change to the file.
Reload Browser
Making live reload in browser is a little bit trickier, it involves using some Ruby gems.
TODO: Need to find a way to avoid using Ruby and its gems.
Having live browser reload is a bit complicated. I wish there is a method as easy as using nodemon via a single command. But in the meantime, I just need to have two panes open and have both monitoring tools running independently. No more browser fresh and command re-issuing.
We are all aware of the KISS principle: Keep It Simple and Stupid. Let me introduce your a similar principle: Keep It Simple and Small.
Maciej Cegłowski who created Pinboard deliberately wants to avoid rapid growth.
“I have seen a lot of free services burn up all their development time scaling for users,” he said. He has no plan to cap the gate fee as more people sign on. “I am tempted to just let it go up and see what happens,” he says. - http://news.cnet.com/8301-19882_3-10310347-250.html
It gives you time to try out different features without upsetting many of your user base.
What if a little site you love doesn’t have a business model? Yell at the developers! Explain that you are tired of good projects folding and are willing to pay cash American dollar to prevent that from happening. It doesn’t take prohibitive per-user revenue to put a project in the black. It just requires a number greater than zero. - Don’t Be A Free User
Why there has to be an exit strategy? If you love what you are doing, and you want to do it for the rest of your life. Why do you need an exit strategy? For some people, it might be better to strike it alone, by keeping it small and having a business model.
Make a living without being beholden to a boss or investors. - Maciej Cegłowski
alias node='env NODE_NO_READLINE=1 rlwrap -s 1000 -S "node> " node'
Persistent history file is saved in:
~/.node_history
However, if by perserving the command history, Node REPL loses familiarity of color output and tab completion. This is a trade-off. To get around this problem, we can roll our own REPL or use an alternative. The best alternative I have found so far is also the one I am already using: CoffeeScript (see 1.6.3 change log). There is a history command built-in:
$ coffee
coffee> .help
.break Sometimes you get stuck, this gets you out
.clear Break, and also clearthelocal context
.exit Exit the repl
.help Show repl options
.history Show commandhistory
.load Load JS fromafileintothe REPL session
.save Save all evaluated commands in this REPL session toafile
