Daniel Kang recently made public a partial implementation of the Node.JS API in C++11 (also known as C++0x) named node.native.
#include <iostream>
#include "http.h"
using namespace native::http;
int main()
{
http server;
if(server.listen("0.0.0.0", 8080, [](request& req, response& res){
res.set_status(200);
res.set_header("Content-Type", "text/plain");
res.end("C++ FTW\n");
})) std::cout << "Server running at http://0.0.0.0:8080/" << std::endl;
return native::run();
}
Why is a C++ port of Node.JS exciting? Read more
To many beginner Node.JS users, a fundamental and immediate apparent disadvantage of writing their web applications with Node.JS lies in the inability to save a file, refresh the browser and see their changes live.
This “problem” is rooted of course in significantly different architectures. In the case of, for example, PHP applications we traditionally separate the role of the web server and request handler. The monolithic web server maps incoming requests to the execution of particular files in the file system, which become our handlers.
In most setups, the web server is mostly limited to inspecting two pieces of a HTTP request: the resource (like /test.php) and the Host header (like www.mydomain.com) for virtual hosts (vhosts) support.
We all have that guy who tweets too much about a certain topic we dislike. Or all those hardcore seasonal fans of the current NFL sensation. Or those annoying spotify/rdio links you’re never going to click!
I’ve been waiting for a while for mainstream Twitter clients to allow keyword or pattern based filtering, and when I realized people were starting to tweet about the 49ers the night before the game, I decided to finally address it myself.
The technique I’m going to describe consists in setting up a proxy to the Twitter API that lives in our computer, powered by Node.JS, that filters back responses based on arbitrary rules we setup. Not only does this give us the flexibility of using JavaScript, but it also means it will work with any Twitter client that leverages the API transparently. Yes, this includes the Twitter website!
Following my article A String is not an Error, I want to bring attention to an issue that similarly applies to JavaScript in general, but has special relevance in the Node.JS environment.
The problem boils down to the usage of {} as a data-structure where the keys are supplied by untrusted user input, and the mechanisms that are normally used to assert whether a key exists.
Consider the example of a simple blog created with Express. We decide to store blog posts in memory in a {}, indexed by the blog post slug. For example, this blog post would be posts['an-object-is-not-a-hash'].
I decided to write a little article to discourage an unfortunately common pattern in Node.JS modules (and browser JavaScript, to a lesser extent) that can boil down to these two examples:
// A:
function myFunction () {
if (somethingWrong) {
throw 'This is my error'
}
return allGood;
}
and
// B: async Node.JS-style callback with signature `fn(err, …)`
function myFunction (callback) {
doSomethingAsync(function () {
// …
if (somethingWrong) {
callback('This is my error')
} else {
callback(null, …);
}
});
}
In both cases, passing a string instead of an error results in reduced interoperability between modules. It breaks contracts with APIs that might be performing instanceof Error checks, or that want to know more about the error.
So here it is, the long awaited redesign! A few months ago I decided I wanted to re-focus my website on my writing and projects, so I reached out to my friend, the genius Rogie King, with some ideas.
Some of the new features that I’m excited about:
- Clearly defined post types: article, code snippet, video, photo and quote.
- Cool dynamic filtering and Twitter-like pagination. (#hash and pushState to come soon)
- Projects page that highlights my past and present work
- CSS3 animated sidebar with links to social networks & bio
- Commenting through DisqUS customized to my needs
