A week or so ago James Coglan tweeted this:
It reflects perfectly why I didn’t get too much into Python other than writing isolated scripts that worked well with themselves and didn’t require extra packages, because installing them was a pain and different in each system (compiling, package managers, other package managers, eggs, pip, bla, bla). And then there was the virtualenv solution, but that adds another layer of managing that I have to deal with. I just want to get things done and be able to distribute them in a manner that makes it easy for other people to use my software.
This reminded me that I had to spend a whole afternoon a while ago trying to make some brew-installed packages operate in harmony with other libraries/binaries in my system. It was so tedious and fuzzy I can’t even remember what the problem was actually. Just the notion that installing all the software and making it all available into a global scope === bad, because different versions will require other different versions. And either everything works in harmony and life is beautiful, or you spent a rainy afternoon feeling miserable because of the weather and the incompatible binaries.
Here are the screencast and the write up on the talk I gave today at One-Shot London NodeConf. As usual I diverge a bit from the initial narrative and I forgot to mention a couple of topics I wanted to highlight, but I have had a horrible week and considering that, this has turned out pretty well!
It was great to meet so many interesting people at the conference and seeing old friends again! Also now I’m quite excited to hack with a few things. Damn (or yay!).
The documentation on the listen method is really vague, but the way you can make your server listen to an specific address only is this:
var server = app.listen(3000, '127.0.0.1', 511, onServerListening);
In this case I want the server to respond only to connections using the 127.0.0.1 host name. Not 0.0.0.0, and not localhost. Only 127.0.0.1.
The reason for this is that I am playing with Twitter’s OAuth and I was stumbling upon this issue because express insisted in binding to 0.0.0.0 by default (i.e. any address), but it wouldn’t work well when Twitter redirected back after authenticating.
For reference, another thing I tried and didn’t work:
var server = app.listen(3000, '127.0.0.1', onServerListening);
Notice that the 511 parameter is missing. So effectively it would take onServerListening as if it was the 511 parameter, which according to the documentation is “the maximum length of the queue of pending connections” and it wouldn’t call the callback. Booo.
I found this little development server built with node.js and I thought I’d recommend it to you since it fixes most of the annoyances I have with the traditional SimpleHTTPServer Python solution. You can install it globally with:
npm install -g lute
And then you can enjoy…
1) Automatic port management
It will find a new available port if the default is in use, so you don’t have to manually manage this, which can be cumbersome when you need to have several local servers running at the same time. Just type
and TA-DA! you get a local server with autoassigned port, serving the files in the current directory.
Or you can also force it to use an specific port:
lute -p 3030
2) It can trigger the ‘open’ action in your browser
You can write this on your command line
and it will open localhost at whatever port it found, using your default browser.
3) Automatically injects livereload in your scripts
This can be both a blessing and an annoyance–it is not playing too well with HTML imports:
A call to document.write() from an asynchronously-loaded external script was ignored.
An issue has been diligently filed.
If you’re not using HTML imports you will be able to enjoy changing things on your code and getting them instantly autoreloaded in the browser–so you can save a few keystrokes!
“Just turn it into a node module,” and other mantras Edna taught me
The story of leaving behind a random mix of Python + php + bash + makefile + Scons scripts to totally embrace using Node, modules, standard callbacks, browserify, and friends to build toys that bleep and bloop with MIDI, WebGL and Web Audio.
As you can maybe deduct, this might not be your average super expert node.js talk, but a story of learning with a non-appointed mentor and an spontaneous community, and improving and making the most out of node.js—and how it informed and shaped the rest of my coding philosophy, both inside and outside of Mozilla.
I must confess that I’m really humbled and flattered to be amongst this amazing line up of true node experts.
UUUUUUUHHH THE EXPECTATIONS!—feeling a bit like an impostor now.
Next next Saturday 19th of July. See you there? :-)