Netty3 Tutorial

The main Netty author (normanmauer@) tweets, "Best #netty 3.x tutorial I saw so far out there."

• http://seeallhearall.blogspot.de/2012/05/netty-tutorial-part-1-introduction-to.html
• http://seeallhearall.blogspot.de/2012/06/netty-tutorial-part-15-on-channel.html

HTTP: Truly a stateless protocol?

> Is HTTP stateful or Stateless? Also, it would be really great is you
> please do let me know where can I find more details regarding HTTP protocol?

Fundamentally, HTTP as a protocol is stateless. In general, though, a
stateless protocol can be made to act as if it were stateful, assuming
you've got help from the client. This happens by arranging for the
server to send the state (or some representative of the state) to the
client, and for the client to send it back again next time.

There are three ways this happens in HTTP. One is cookies, in which
case the state is sent and returned in HTTP headers. The second is URL
rewriting, in which case the state is sent as part of the response and
returned as part of the request URI. The third is hidden form fields,
in which the state is sent to the client as part of the response, and
returned to the server as part of a form's data (which can be in the
request URI or the POST body, depending on the form's method).

To learn more about HTTP as a protocol, see http://www.w3.org/Protocols/

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

(I'll elaborate on this later... ~cdunn2001)

Concurrency in node.js: Objects vs. Functions -- or maybe both!

Here is an excellent article on using node.js as a simple web-server. In particular, it talks about dependency injection (with a reference to Martin Fowler's article) to handle routing, and it includes an aside on "nouns vs. verbs". Kiessling's aside refers to Yegge's 2006 article, which shows why Java is so verbose. As Yegge says,

I've really come around to what Perl folks were telling me 8 or 9 years ago: "Dude, not everything is an object."

All the talk of imperative vs. functional code -- and message-passing vs. function-passing -- seems to miss the point: We need both objects and functions!

Functional code facilitates multiprocessing by reducing dependencies. For example:

function upload() {
  console.log("Request handler 'upload' was called.");
  return "Hello Upload";
}

Except for the log message, that is functional code, which might be part of a web-server. Maybe a URL like "http://foo.com/upload" would eventually lead to this function. A more complex version of it could produce a whole web-page.

At first, this seems pleasantly scalable, but looks are deceiving. Consider how it might be called:

function route(pathname) {
  console.log("About to route a request for " + pathname);
  if (pathname == "/upload") {
    return upload();
  } else {
    console.log("No request handler found for " + pathname);
    return "404 Not found";
  }
}

function onRequest(request, response) {
  var pathname = url.parse(request.url).pathname;
  console.log("Request for " + pathname + " received.");

  response.writeHead(200, {"Content-Type": "text/plain"});
  var content = route(pathname)
  response.write(content);
  response.end();
}

The problem is that the entire stack -- from onRequest() to route() to upload() -- may block the server. The author of node.js, Ryan Dahl, has given many talks in which he discusses the importance of non-blocking calls for the sake of concurrency. Here is an example that can be non-blocking:

function upload(response) {
  console.log("Request handler 'upload' was called.");
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.write("Hello Upload");
  response.end();
}

function route(pathname, response) {
  console.log("About to route a request for " + pathname);
  if (pathname == '/upload') {
    upload(response);
  } else {
    console.log("No request handler found for " + pathname);
    response.writeHead(404, {"Content-Type": "text/plain"});
    response.write("404 Not found");
    response.end();
  }
}

function onRequest(request, response) {
  var pathname = url.parse(request.url).pathname;
  console.log("Request for " + pathname + " received.");
  route(pathname, response);
}

Notice that we are passing the response object from function to function. That is message-passing. The handler eventually writes directly into that object, rather than returning a string. Thus, the handler has side-effects. It is no longer functional code. But because it will be passed everything it needs, we can forget the call stack. Why is this an advantage? Because it allows us to use a cheap event loop. Let's suppose that upload() is a time-consuming operation:

function upload(response) {
  console.log("Request handler 'upload' was called.");

  exec("slow-operation", function (response, error, stdout, stderr) {
    response.writeHead(200, {"Content-Type": "text/plain"});
    response.write(stdout);
    response.end();
  });
}

The exec() call is slow, but exec() itself is non-blocking. When called, a sub-process starts, the function goes into the event queue, and upload() returns immediately. Thus, the system-call is executed concurrently with other operations. That's the essence of node.js.

To be clear, message-passing is not the main point. The response object could be stored temporarily in a closure, which is typical in JavaScript. (In fact, exec() in node.js does not actually allow response to be passed to its function.) We do not need a mutex lock on the response object because this is a single-threaded program, but even that's not the point. We could have multiple threads and lock the response object. It's in-memory, so response.write() is very fast. We create new events (with threads, processes, or whatever) only for slow (aka blocking) operations, and we assign call-backs to those events so that processing can be deferred. This is a paradigm which makes concurrency simple.

MVC Framework: Template-inversion

In many MVC frameworks, a template is used to generate web pages. For example, here is a template for Erb (the default template language for Ruby on Rails):

When I parse this using erb from the command-line, I get this:

That is usually done at runtime, within a Rails server.

Instead, I propose inverting the template prior to deployment, so that it becomes a Ruby file, like this:

For Ruby, there is no benefit. It's an extra step, and it's harder to debug. However, for a pre-compiled language like Go, the benefit is that the inverted template can be compiled and linked into the web application.  All the code inside a template is fully type-checked before the app is deployed, which is both faster and safer than the current paradigm. It also means that the templates are compiled into the executable, rather than separate files, so deployment becomes simpler (assuming that static content is served by "the cloud", not by the application server).

Note that Go lacks an "eval" function, and rightly so. With template-inversion, "eval" is not needed.

A more realistic example in Go might result in something more like this:

Facebook: The "Like" Button Just Changed

http://www.techi.com/2011/02/why-the-facebook-like-button-change-is-a-bait-and-switch/

Excuse the opinionated title of that link. The information is worth knowing.

Ruby: Following HTTP redirects

I'll update this with my Ruby code later. For now, read this:

How to control your HTTP transactions in Go

You might want to read his previous post also, on using Go for an HTTP throttler to simulate a low-bandwidth connection.

HTTP: safety and idempotency

This blogpost has lots of useful links and a good example.

A big part of RESTfulness is mapping CRUD (Create/Read/Update/Destroy) to GET/POST/PUT/DELETE without violating idempotency (repeatability) or safety (no side-effects).

As pointed out here, using GET unsafely does not break anything, but I think the author misses the point. GET safety is a convention, which makes it easier for the rest of us to understand Web APIs. It's similar to conventions about identifying side-effects in software. The trouble is that most software engineers do not recognize the cognitive penalty of side-effects, so they do not see any reason to illuminate them.

Also, note the difference between idempotency and referential transparency. Technically, we should say referentially transparent, rather than idempotent, since the result of a GET (or PUT or DELETE) cannot be applied to itself. To me, that's a less important distinction than the tenor of the rule. And here is a lucid defense of using idempotent in the context of the web.

See also this StackOverflow discussion, especially the link to Roy Fielding's comment on REST and Cookies.

jQuery: WTF?

Unbelievable.

I definitely prefer Prototype. Still, jQuery is much better than ASP. (Fortunately, the folks at MS recognized this, and VS MVC has supported jQuery since 2008.)

RoR: Nested routes

I learned something interesting enough that I want to keep a link to it. Unfortunately, I posted the answer a year after the question, so nobody will ever see it. Awwww.

Web: Optimizations

• How To Debug Web Applications With Firefox
• How To Optimize Your Site With HTTP Caching
• How To Optimize Your Site With GZIP Compression
• How To Speed Up Your Javascript Load Time

 There's lots of other useful info at that website too.

Web: Better URL navigation

This post made me realize that very few people are aware of a nice way to work with URLs for dynamic content.

Many sites use the hash (#) or shebang (#!) in their URLs for AJAX, and some end up breaking the *Back* button on your browser. The hash is important for letting Google index a link to a self-reloading page, but for pages that should not be indexed, there is a better way.

•    http://foo.com/current.html
• Contains a POST-method link to "/link".
•    http://foo.com/link
• On the server, the web framework interprets POST, computes new context, then redirects to the template "final.html", along with extra context.
•    http://foo.com/final.html
• This would be the result of the template substitution.

There are several benefits to this scheme:

1. POST interpretation (the "controller") is separated from template substitution (the "view"). Most people instead use an if-clause in their controller.
2. The web-designer can keep a simple redirect stub for the "link" page. That way, he can continue web-design in his static environment. He does not have to use a server or the intended framework.
3. final.html is inherently secure, since none of the extra context is ever provided directly to that URL by the user.

The *Back* button works fine, because the `link` page was never rendered.

I'm not sure why this pattern is not better known. Maybe I am overlooking some advantages of the alternatives.

Bug in Blogspot: Spaces after periods

I just noticed a problem with the rendering at Blogspot.  It is traditional to add 2 spaces after a period when typing (for the sake of typesetting, an ancient art form) but if I do that here, line-wrapping may carry a space to the beginning of the next line.  I'll just use a single space from now on.