I'm interested in web development on the Node.js platform. My host OS is Windows 7. What would be the preferd way to set up a development environment. Run it directly on the host or in a linux based virtual machine? What are the pros and cons between these two methods?
If I go with a VM, can I still run the text editor and web browser in Windows (for performance reasons)?
We have a system via which we just use a config file, which handles all our problems like path differences ("c:\blarg"
vs "~user/blarg"
) and, as a bonus, lets us control differences between debug and production environments.
Node.js is cross platform, so we totally have developers working on all sorts of computers, and it's no problem at all.
This is an example config file I use on a file storage project:
/**
* All of these are mandatory except for log_level (which defaults to "info", 1)
* and log_echo_to_console (which defaults to false)
*/
exports.config = {
log_level: 0,
log_file: "/path/to/send.log",
request_log_file: "/path/to/send_requests.log",
log_echo_to_console: true,
port_number: 8088,
no_notification_emails: true,
image_url_base: "http://s3.amazonaws.com/", // MAKE SURE THIS ENDS IN "/"
tmp_file_folder:"/tmp/",
s3_info: {
key: 'xxxxxx',
secret: 'yyyyy',
file_bucket: 'sendtransfer/',
},
backend_info: {
db_info: {
server: "localhost",
user: "db_user",
password: "secret",
database: "SendRemote",
pooled_connections: 125,
idle_timeout_millis: 30000
},
memcache_info: {
host: "127.0.0.1",
port: "31111",
pooled_connections: 200,
timeout: 20000
}
},
debug_server: true
};
For Windows machines, just change the paths. It's all good!
Then in code, you can just type:
var local = require('local.config.js');
fs.writeFile(local.config.log_file);
// etc
Embrace multiculturalism!!!
Eh from experience, use Linux.
But from someone whose spent the last 8 years developing in a linux based environment, and having spent the last 6 months developing software using nodejs in a windows dot net environment, here are my discoveries, shocking or otherwise...
the windows equivalent of debians build-essentials
is actually a disparate sprawling ill named collection of gui only installers scattered across the internet all requiring a specific installation sequence. This, compared to sudo apt-get install build-essentials
is overly time consuming and fraught with hidden gotchas.
developing on windows will allow you the bad habit of mixed case path names, unless your team either has a strict policy that is followed/enforced this will be a slippery slope to problems later on.
while windows supports more than 256 characters in paths, important tooling through out does not. enter stage left: rimraf and robocopy... ugh.
the windows terminal sucks... so does the default shell: cmd.exe... Powershell is far too verbose in it's syntax and not to my taste... Installing Cmder aleviates this somewhat, however the only way for Cmder to interface with cmd.exe is to basically copy keystrokes to a hidden windows terminal running cmd.exe. (lolwut). Cmder works a lot better with shells that a more modular (zsh, bash, etc) Having still improved the shell and terminal situation, nodejs for windows will still assume your environment variables are %OF% %THE% %WINDOWS% %VARIETY%... not the $UNIX $STYLE. So you'll basically be using bower and npm mostly from cmd.exe... more ugh.
You'll also need to install python for windows, not a problem because choco exists and has you back there.
experienced python, ruby developers will tell you that old projects will need the version of their engine silo'd for when you need to revisit them (upgrading to newer versions is mostly not expedient or practical, read: rabbit holes), so you'll want something like rvm and virtualenv...
choco install cmder nodejs python2
~/.local/share/npm
). Pleasantly, this is something I found the windows installation of nodejs got right (probably not intentionally).node
, so #!/usr/bin/env node
will by default not run nodejs. luckily debian systems have a neat management tool for controlling what the env
binary emits: update-alternatives
. ignore suggestions to use symlinks here, which will only cause problems later on in subtle ways.$ sudo apt-get install git-core git-flow legit nodejs build-essentials python-dev python- pip
$ sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
$ curl https://raw.githubusercontent.com/creationix/nvm/v0.20.0/install.sh | bash
$ npm config set prefix ~/.local/share/npm
references:
I am also on Windows 7 and use Virtualbox with a Linux ( debian ) guest, i would recommand it because I for myself am faster doing some stuff in the commandline then clicking arround in Windows.
Another nice feature is that if you put your VM on an USB stick you can take it with you and use it everywhere where a Virtualbox Host is installed, so you can take your whole development environment with you.
It's no problem at all to use your favourite text editor or browser in Windows, just install samba and mount your home directory into Windows. Same goes for your browser since the VM is just another machine in your LAN, instead of pointing your browser to localhost point it to the VMs Ip and you are fine.
Obvious con here is if you don't have any experience with Linux yet you should probably stick to windows because it will take you some time to get into it.
just my two cents maybe even less:
I'll suggest you a third option: to double install windows/ubuntu setup (preferably ubuntu dist which is most gui friendly) and research this option as well this way you would be more familiar with the linux/unix and even iOS which will even make you understand windows better and a better programmer. Sometimes the virtual box is too slow, while linux is very efficient with resources.
If you have the ability to install a virtual machine,you can also give a go to installing a linux distribution and get yourself familiar with this language/system of OS which a lot of the web is structured upon
I really enjoy coding node.js on windows using git bash: http://blog.nodester.com/post/19902515151/tips-for-windows-users
It's seems faster then and easier then running VirtualBox. Given that I still use Virtual Box for testing before going to production.