Node.js v0.6.0: Cluster

Table Of Contents

• Cluster
  • cluster.fork()
  • cluster.isMaster
  • cluster.isWorker
  • Event: 'death'

The cluster module allows you to easily create a network of processes all which share server ports.A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load.

http://nodejs.org/docs/v0.6.0/api/cluster.html

Build a simple client-side MVC app with RequireJS

As a web developer, you certainly often started coding your JavaScript in a single file, and, as the code base gets larger and larger, it became really difficult to maintain. To solve this problem you can split your code in several files, add more script tags and use global variables to reach functions declared in other files. But this pollutes the global namespace and for each file an additional HTTP request consumes bandwidth, which slows down the loading time of the page.

If this happened to you, you certainly understand that there is a strong need to organize our front-end code differently, particularly if we have to build large-scale web apps with thousands of lines of JavaScript. We need a new way to organize all this mess to make it easier to maintain. This new technique consists in using script loaders. Plenty of them are available on the web, but we’ll focus on a very good one called RequireJS.

In this step by step tutorial you will learn how to build a simple MVC (Model – View – Controller) app using RequireJS. You don’t need any particular previous knowledge of script loading – we’ll see the basics together.

http://verekia.com/requirejs/build-simple-client-side-mvc-app-require-js

Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5

Adobe is all about enabling designers and developers to create the most expressive content possible, regardless of platform or technology. For more than a decade, Flash has enabled the richest content to be created and deployed on the web by reaching beyond what browsers could do. It has repeatedly served as a blueprint for standardizing new technologies in HTML.  Over the past two years, we’ve delivered Flash Player for mobile browsers and brought the full expressiveness of the web to many mobile devices.

However, HTML5 is now universally supported on major mobile devices, in some cases exclusively.  This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores.  We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.  We will of course continue to provide critical bug fixes and security updates for existing device configurations.  We will also allow our source code licensees to continue working on and release their own implementations.

These changes will allow us to increase investment in HTML5 and innovate with Flash where it can have most impact for the industry, including advanced gaming andpremium video.  Flash Player 11 for PC browsers just introduced dozens of new features, including hardware accelerated 3D graphics for console-quality gaming and premium HD video with content protection.  Flash developers can take advantage of these features, and all that our Flash tooling has to offer, to reach more than a billion PCs through their browsers and to package native apps with AIR that run on hundreds of millions of mobile devices through all the popular app stores, including the iTunes App Store, Android Market, Amazon Appstore for Android and BlackBerry App World.

We are already working on Flash Player 12 and a new round of exciting features which we expect to again advance what is possible for delivering high definition entertainment experiences.  We will continue to leverage our experience with Flash to accelerate our work with the W3C and WebKit to bring similar capabilities to HTML5 as quickly as possible, just as we have done with CSS Shaders.  And, we will design new features in Flash for a smooth transition to HTML5 as the standards evolve so developers can confidently invest knowing their skills will continue to be leveraged.

We are super excited about the next generations of HTML5 and Flash.  Together they offer developers and content publishers great options for delivering compelling web and application experiences across PCs and devices.  There is already amazing work being done that is pushing the newest boundaries, and we can’t wait to see what is still yet to come!

http://blogs.adobe.com/conversations/2011/11/flash-focus.html

Node v0.6.0

We are happy to announce the third stable branch of Node v0.6. We will be freezing JavaScript, C++, and binary interfaces for all v0.6 releases.

The major differences between v0.4 and v0.6 are

• Native Windows support using I/O Completion Ports for sockets.
• Integrated load balancing over multiple processes. docs
• Better support for IPC between Node instances docs
• Improved command line debugger docs
• Built-in binding to zlib for compression docs
• Upgrade v8 from 3.1 to 3.6

In order to support Windows we reworked much of the core architecture. There was some fear that our work would degrade performance on UNIX systems but this was not the case. Here is a Linux system we benched for demonstration:

	v0.4.12 (linux)	v0.6.0 (linux)
http_simple.js /bytes/1024	5461 r/s	6263 r/s
io.js read	19.75 mB/s	26.63 mB/s
io.js write	21.60 mB/s	17.40 mB/s
startup.js	74.7 ms	49.6 ms

Bigger is better in http and io benchmarks, smaller is better in startup. The http benchmark was done with 600 clients on a 10GE network served from three load generation machines.

In the last version of Node, v0.4, we could only run Node on Windows with Cygwin. Therefore we’ve gotten massive improvements by targeting the native APIs. Benchmarks on the same machine:

	v0.4.12 (windows)	v0.6.0 (windows)
http_simple.js /bytes/1024	3858 r/s	5823 r/s
io.js read	12.41 mB/s	26.51 mB/s
io.js write	12.61 mB/s	33.58 mB/s
startup.js	152.81 ms	52.04 ms

We consider this a good intermediate stage for the Windows port. There is still work to be done. For example, we are not yet providing users with a blessed path for building addon modules in MS Visual Studio. Work will continue in later releases.

For users upgrading code bases from v0.4 to v0.6 we’ve documented most of the issues that you will run into. Most people find the change painless. Despite the long list of changes most core APIs remain untouched.

Our release cycle will be tightened dramatically now. Expect to see a new stable branch in January. We wish to eventually have our releases in sync with Chrome and V8′s 6 week cycle.

Thank you to everyone who contributed code, tests, docs, or sent in bug reports.

Here are the changes between v0.5.12 and v0.6.0:

2011.11.04, Version 0.6.0 (stable)

• print undefined on undefined values in REPL (Nathan Rajlich)
• doc improvements (koichik, seebees, bnoordhuis, Maciej Małecki, Jacob Kragh)
• support native addon loading in windows (Bert Belder)
• rename getNetworkInterfaces() to networkInterfaces() (bnoordhuis)
• add pending accepts knob for windows (igorzi)
• http.request(url.parse(x)) (seebees)
• #1929 zlib Respond to ‘resume’ events properly (isaacs)
• stream.pipe: Remove resume and pause events
• test fixes for windows (igorzi)
• build system improvements (bnoordhuis)
• #1936 tls: does not emit ‘end’ from EncryptedStream (koichik)
• #758 tls: add address(), remoteAddress/remotePort
• #1399 http: emit Error object after .abort() (bnoordhuis)
• #1999 fs: make mkdir() default to 0777 permissions (bnoordhuis)
• #2001 fix pipe error codes
• #2002 Socket.write should reset timeout timer
• stdout and stderr are blocking when associated with file too.
• remote debugger support on windows (Bert Belder)
• convenience methods for zlib (Matt Robenolt)
• process.kill support on windows (igorzi)
• process.uptime() support on windows (igorzi)
• Return IPv4 addresses before IPv6 addresses from getaddrinfo
• util.inspect improvements (Nathan Rajlich)
• cluster module api changes
• Downgrade V8 to 3.6.6.6

Download: http://nodejs.org/dist/v0.6.0/node-v0.6.0.tar.gz

Windows Executable: http://nodejs.org/dist/v0.6.0/node.exe

Website: http://nodejs.org/docs/v0.6.0/

Documentation: http://nodejs.org/docs/v0.6.0/api/

http://blog.nodejs.org/2011/11/05/node-v0-6-0/

ExecJS

ExecJS lets you run JavaScript code from Ruby. It automatically picks the best runtime available to evaluate your JavaScript program, then returns the result to you as a Ruby object.

ExecJS supports these runtimes:

• therubyracer - Google V8 embedded within Ruby
• therubyrhino - Mozilla Rhino embedded within JRuby
• Johnson - Mozilla SpiderMonkey embedded within Ruby
• Mustang - Mustang V8 embedded within Ruby
• Node.js
• Apple JavaScriptCore - Included with Mac OS X
• Mozilla SpiderMonkey
• Microsoft Windows Script Host (JScript)

https://github.com/sstephenson/execjs

Testing Routes in Rails

Routes in rails are really cool but they can be confusing to newbies and, as they become more complex, it can be difficult to make sure that all of your paths are still working like you expect. My intention here is not to provide a primer on routes but rather to show how easy it is to test and verify routes.

http://blog.zobie.com/2008/11/testing-routes-in-rails/

Intel’s Parallel Extensions for JavaScript

Intel’s Parallel Extensions for JavaScript, code named River Trail, hooks into on-chip vector extensions to improve performance of Web applications. Details of Intel’s attempt to get on the JavaScript juggernaut emerged last month at its developer event.

The prototype JavaScript extension offered by Intel is intended to allow JavaScript apps to take advantage of modern parallel chip capabilities. Sequential gives way to parallel, at least in theory.

In-browser games and image editing are pitched as examples of application elements that would take advantage of new eight-core processors, blogs Intel’s Stephan Herhut.The software is said to ”play nicely” with the WebGL JavaScript API to OpenGL for 3D visualization in the browser.

http://ajaxian.com/archives/intels-parallel-extensions-for-javascript