Jenkins 2.0 is here

Published on

Over the past 10 years, Jenkins has really
grown to a
de-facto standard tool that millions of people use to handle automation in
software development and beyond. It is quite remarkable for a project that
originally started as a hobby project under a different name. I’m very proud.

Around this time last year,
celebrated 10 years, 1000 plugins, and 100K installations. That was a good time
to retrospect, and we started thinking about the next 10 years of Jenkins and
what’s necessary to meet that challenge. This project has long been on a
weekly “train” release model, so it was useful to step back and think about a
big picture.

That is where three pillars of Jenkins 2.0 have emerged from.

First, one of the challenges our users are facing today is that the automation
that happens between a commit and a production has significantly grown in its
scope. Because of this, the clothing that used to fit (aka “freestyle project”,
which was the workhorse of Jenkins) no longer fits. We now need something that
better fits today’s use cases like “continuous delivery pipeline.” This is why
in 2.0 we’ve added the pipeline capability. This 2 year old effort allows you
to describe your chain of automation in a textual form. This allows you to
version control it, put it alongside your source tree, etc. It is also actually
a domain specific language (DSL) of Groovy, so when your pipeline grows in
complexity/sophistication, you can manage its complexity and keep it
understandable far easily.

Second, over time, Jenkins has developed the “assembly required before initial
use” feeling. As the project has grown, the frontier of interesting development
has shifted to plugins, which is how it should be, but we have left it up to
users to discover & use them. As a result, the default installation became very
thin and minimal, and every user has to find several plugins before Jenkins
becomes really functional. This created a paradox of choice and unnecessarily
hurt the user experience. In 2.0, we reset this thinking and tries to create
more sensible out of the box experience that solves 80% use cases for 80% of
people. You get something useful out of the box, and you can get some
considerable mileage out of it before you start feeling the need of plugins.
This allows us to focus our development & QA effort around this base
functionality, too. By the way, the focus on the out of the box experience
doesn’t stop at functionality, either. The initial security setup of Jenkins is
improved, too, to prevent unprotected Jenkins instances from getting abused by
botnets and attacks.

Third, we were fortunate to have a number of developers with UX background
spend some quality time on Jenkins, and they have made a big dent in improving
various parts of Jenkins web UI. The setup wizard that implements the out of
the box experience improvement is one of them, and it also includes other parts
of Jenkins that you use all the time, such as job configuration pages and new
item pages. This brings much needed attention to the web UI.

As you can see, 2.0 brings a lot of exciting features on the table, but this is
an evolutionary release, built on top of the same foundation, so that your
existing installations can upgrade smoothly. After this initial release, we’ll
get back to our usual weekly release march, and more improvements will be made
to those pillars and others in coming months and years continuously. If you’d
like to get more in-depth look at Jenkins 2.0, please join us in our virtual
Jenkins meetup 2.0 launch event

Thank you very much for everyone who made Jenkins 2.0 possible. There are
too many of you
to thank individually, but you know who you are. I wanted to thank CloudBees in
particular for sponsoring the time of many of those people. 10 years ago, all I
could utilize was my own night & weekend time. Now I’ve got a team of smart
people working with me to carry this torch forward, and a big effort like 2.0
wouldn’t have been possible without such organized effort.

Original URL:

Original article

Node.js v6.0 Released

New “Current” version line focuses on performance improvements, increased reliability and
better security for its 3.5 million users

SAN FRANCISCO, April, 26, 2016 — The Node.js Foundation, a
community-led and industry-backed consortium to advance the development of the Node.js
platform, today announced the release of Node.js version 6 (Node.js v6). This release
provides major performance improvements, increased reliability and better security.

With over 3.5 million users and an annual growth rate of 100 percent, Node.js is emerging as
a universal platform used for web applications, IoT, mobile, enterprise application
development, and microservice architectures. The technology is ubiquitous across numerous
industries, from startups to Fortune 500 companies, and is the only unified platform that
full stack JavaScript developers can use for front end, back end, mobile and IoT projects.

Performance improvements are key in this latest release with one of the most significant
improvements coming from module loading, which is currently four times faster than Node.js
version 4 (Node.js v4). This will help developers dramatically decrease the startup time of
large applications for the best productivity in development cycles and more seamless
experience with end users. In addition, Node.js v6 comes equipped with v8 JavaScript engine
5.0, which has improved ECMAScript 2015 (ES6) support. Ninety-three percent of
ES6 features are also now supported in the Node.js v6 release, up from
56 percent for Node.js v5 and 50 percent for Node.js v4. Key features from ES6 include:
default and rest parameters, destructuring, class and super keywords.

Security is top-of-mind for enterprises and startups alike, and Node.js v6 has added several
features that impact security, making it easier to write secure code. The new Buffer API will
reduce the risk of bugs and vulnerabilities leaking into applications through a new
constructor method used to create Buffer instances, as well as a zero-fill-buffers
command-line flag. Using the new command line flag, developers can continue to safely use
older modules that have not been updated to use the new constructor API. In addition, V8 has
improved their implementation of Math.random() to be more secure — this feature is added into
Node.js v6.

“The Node.js Project has done an incredible job of bringing this version to life in the
timeline that we initially proposed in September 2015. It’s important for us to continue to
deliver new versions of Node.js equipped with all the cutting-edge JavaScript features to
serve the needs of developers and to continue to improve the performance and stability
enterprises rely on,” said Mikeal Rogers, Community Manager of the Node.js Foundation. “This
release is committed to Long Term Support, which allows predictable long-term stability,
reliability, performance and security to the growing number of enterprise users that are
adopting Node.js as a key technology in their infrastructure.”

To increase reliability of Node.js, there has been increased documentation and testing done
around Node.js v6 for enterprises that are using and looking to implement the platform.

Node.js release versioning follows the Semantic Versioning Specification, a specification for
version numbers of software libraries similar to dependencies. Under the Node.js’ Long-Term
Support (LTS)
, version 6 is now the “Current” release line
while version 5 will be maintained for a few more months. In October 2016, Node.js v6 will
become the LTS release and the LTS release line (version 4) will go under maintenance mode in
April 2017, meaning only critical bugs, critical security fixes and documentation updates
will be permitted. Users should begin transitioning from v4 to v6 in October when v6 goes
into LTS.

Additional Resources

About Node.js Foundation
Node.js is used by tens of thousands of organizations in more than 200 countries and amasses
more than 3.5 million active users per month. It is the runtime of choice for
high-performance, low latency applications, powering everything from enterprise applications,
robots, API engines, cloud stacks and mobile websites.

The Foundation is made up of a diverse group of companies including Platinum members Famous,
IBM, Intel, Joyent, Microsoft, PayPal and Red Hat. Gold members include GoDaddy, NodeSource
and Modulus/Progress Software, and Silver members include Apigee, AppDynamics, Codefresh,
DigitalOcean, Fidelity, Google, Groupon, nearForm, New Relic, npm, Opbeat, RisingStack, Sauce
Labs, SAP, StrongLoop (an IBM company), Sphinx, YLD!, and Yahoo!. Get involved here:

Original URL:

Original article

‘Laws’ of Software Development

(AKA How To Sound Smart At Your Next Team Meeting)

Occam’s Razor

This widely-known adage dates to a philosopher and friar from the fourteenth century named William of Ockham. Occam’s Razor is often stated as:

“Among competing hypotheses, the one with the fewest assumptions should be selected.”

It’s no surprise that the whole reason we can recall an adage from 600+ years ago is that it works so well. Occam’s Razor is so basic, so fundamental, that it should be the first thing we think of when deciding between two competing theories. I’d even go so far as to argue that in the vast majority of cases, simpler is better.

Hanlon’s Razor

Sometimes I feel like users are intentionally trying to piss me off. They push buttons they weren’t supposed to, found flaws that shouldn’t have been visible to them (since they weren’t to me), and generally make big swaths of my life more difficult than it would otherwise be.

I try to remember, though, that the vast majority of actions done by people which may seem malicious are not intentionally so. Rather, it’s because they don’t know any better. This is the crux of an adage known as Hanlon’s Razor, which states:

“Never attribute to malice what can be adequately explained by stupidity.”

Don’t assume people are malicious; assume they are ignorant, and then help them overcome that ignorance. Most people want to learn, not be mean for the fun of it.

The Pareto Principle

The last Basic Law of Software Development is the Pareto Principle. Romanian-American engineer Joseph M Juran formulated this adage, which he named after an idea proposed by Italian economist and thinker Vilfredo Pareto. The Pareto Principle is usually worded as:

“80% of the effects stem from 20% of the causes.”

Have you even been in a situation where your app currently has hundreds of errors, but when you track down one of the problems, a disproportionate amount of said errors just up and vanish? If you have (and you probably have), then you’ve experienced the Pareto Principle in action. Many of the problems we see, whether coding, dealing with customers, or just living our lives, share a small set of common root issues that, if solved or alleviated, can cause most or all of the problems we see to disappear.

In short, the fastest way to solve many problems at once is the find and fix their common root cause.

Dunning-Kruger Effect

Researchers David Dunning and Justin Kruger, conducting an experiment in 1999, observed a phenomenon that’s come to be known as the Dunning-Kruger effect:

“Unskilled persons tend to mistakenly assess their own abilities as being much more competent than they actually are.”

What follows from this is a bias in which people who aren’t very good at their job think they are good at it, but aren’t skilled enough to recognize that they aren’t. Of all the laws in this list, the Dunning-Kruger effect may be the most powerful, if for no other reason than it has been actively investigated in a formal setting by a real-life research team.

Linus’s Law

Author and developer Eric S. Raymond developed this law, which he named after Linus Torvalds. Linus’s Law states:

“Given enough eyeballs, all bugs are shallow.”

In other words, if you can’t find the problem, get someone else to help. This is why concepts like pair programming work well in certain contexts; after all, more often than not, the bug is in your code.

Robustness Principle (AKA Postel’s Law)

One of the fundamental ideas in software development, particularly fields such as API design, can be concisely expressed by the Robustness Principle:

“Be conservative in what you do, be liberal in what you accept from others.”

This principle is also called Postel’s Law for Jon Postel, the Internet pioneer who originally wrote it down as part of RFC 760. It’s worth remembering, if for no other reason than an gentle reminder that often the best code is no code at all.

Eagleson’s Law

Ever been away from a project for a long time, then returned to it and wondered “what idiot wrote this crap?” only to find out that the idiot was you?

Eagleson’s Law describes this situation quite accurately:

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Remember that the next time you’re rejoining a project you’ve been away from for months. The code is no longer your code; it is someone else’s that you’ve now been tasked with improving.

Peter Principle

One of the fundamental laws that can apply to managers (of any field, not just software) is the Peter Principle, formulated by Canadian educator Laurence J Peter:

“The selection of a candidate for a position is based on the candidate’s performance in their current role, rather than on abilities relevant to the intended role.”

The Peter Principle is often sarcastically reduced to “Managers rise to their level of incompetence.” The idea of this principle looks like this:

A chart showing the advancement of a candidate to higher and higher levels of management, until reaching a point at which s/he is no longer qualified to obtain via skill.

The problem revealed by the Peter Principle is that workers tend to get evaluated on how well they are currently doing, and their superiors assume that those workers would also be good at a different role, even though their current role and their intended role may not be the same or even similar. Eventually, such promotions place unqualified candidates in high positions of power, and in particularly bad cases you can end up with pointy-haired bosses at every step of an organization’s hierarchy.

Dilbert Principle

Speaking of pointy-haired bosses, cartoonist Scott Adams (who publishes the comic strip Dilbert) proposed an negative variation of the Peter Principle which he named the Dilbert Principle. The Peter Principle assumes that the promoted workers are in fact competent at their current position; this is why they got promoted in the first place. By contrast, the Dilbert Principle assumes that the least competent people get promoted the fastest. The Dilbert Principle is usually stated like this:

“Incompetent workers will be promoted above competent workers to managerial positions, thus removing them from the actual work and minimizing the damage they can do.”

This can be phrased another way: “Companies are hesitant to fire people but also want to not let them hurt their business, so companies promote incompetent workers into the place where they can do the least harm: management.”

Hofstadter’s Law

Ever noticed that doing something always takes longer than you think? So did Douglas Hofstadter, who wrote a seminal book on cognitive science and self-reference called Godel, Escher, Bach: An Eternal Golden Braid. In that book, he proposed Hofstadter’s Law:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Always is the key word: nothing ever goes as planned, so you’re better off putting extra time in your estimates to cover some thing that will go wrong, because it unfailingly does.

The 90-90 Rule

Because something always goes wrong, and because people are notoriously bad at estimating their own skill level, Tom Cargill, an engineer at Bell Labs in the 1980’s, proposed something that eventually came to be called the 90-90 rule:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Perhaps this explains why so many software projects end up over budget and short on features.

Parkinson’s Law

What is possibly the most astute observation that can be applied to the art of estimation comes from British naval historian C. N. Parkinson. He jokingly proposed an adage called Parkinson’s Law, which was originally understood to be:

“Work expands so as to fill the time available for its completion.”

Remember this next time you pad your estimates.

Sayre’s Law

Economist and professor Charles Issawi proposed an idea that came to be known as Sayre’s Law, named after a fellow professor at Columbia University. Issawi’s formulation of this law looks like this:

“In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

In short, that the less significant something is, the more passionately people will argue about it.

Parkinson’s Law of Triviality (AKA Bikeshedding)

Sayre’s Law segues directly into another law that applies to meetings, and here we again encounter the ideas of C.N. Parkinson. Parkinson’s Law of Triviality states:

“The time spent on any agenda item will be in inverse proportion to the sum of money involved.”

Parkinson imagined a situation in which a committee of people were tasked with designing a nuclear reactor. Said committee then spends a disproportionate amount of time designing the reactor’s bikeshed, since any common person will have enough life experience to understand what a bikeshed should look like. Clearly the “core” functions of the reactor are more important, but they are so complex that no average person will understand all of them intimately. Consequently, time (and opinions) are spent on ideas that everyone can comprehend, but which are clearly more trivial.

Law of Argumentative Comprehension

The last law is one I totally made up I use to shorthand both Sayre’s Law and Parkinson’s Law of Triviality. I call it the Law of Argumentative Comprehension:

“The more people understand something, the more willing they are to argue about it, and the more vigorously they will do so.”


You’ll notice that many of the laws above don’t directly apply specifically to software, and this is intentional. The fact remains that software is built for people to use and interact with, so many of these laws relate to dealing with people rather than code.

No pithy quote will ever replace the experience you gain every day by writing code, interacting with users, and generally getting better every day. Still, by keeping in mind these 15 laws of software development, you might just make yourself a better developer. Or at least a more knowledgeable one, and really, aren’t those the same thing?

Did I miss any laws that you consider fundamental to the process of creating software, or any of the activity that goes on around said process (e.g. estimations, meetings, etc.)? Share in the comments!

Happy Coding!

Original URL:

Original article

Scala on Tessel 2 via Scala.js

Tessel 2 and its relay module
Tessel 2 and its relay module

What is Tessel 2?

Tessel 2 is a Wi-Fi-enabled development board programmable in JavaScript with Node.js. The first units shipped this month. There is a lot that I like about Tessel 2:

  • It is high-level. JavaScript and Node.js greatly lower the barrier of entry since there are so many developers familiar with these technologies.
  • It works out of the box. Take the device, plug it, push some JavaScript, and it does its magic! There is no need to install your own Linux distribution or additional software.
  • It is autonomous. Thanks to its powerful hardware, built-in Wi-Fi and Node.js, it runs independently from other computers or even cables (except for power).
  • It is open. The Tessel 2 software and hardware are open source. In fact, Tessel is not even a company but “just a collection of people who find it worthwhile to spend [their] time building towards the Tessel Project mission.”

It short Tessel 2 seems perfect for playing with IoT!

From JavaScript to Scala

As soon as I got my Tessel 2, I followed the tutorial to get a basic hang of it, and that went quite smoothly.

But my plan all along had been to use Scala on Tessel 2. You might know Scala primarily as a server-side language running on the Java VM. But Scala also compiles to JavaScript thanks to Scala.js, and it does it spectacularly well.

So I set to do something simple like toggling relays, but in Scala instead of JavaScript. Here are the rough steps:

  • setup a Scala.js sbt project
  • write an app calling the Tessel LED and relay module APIs
  • run sbt fullOptJs to compile the Scala code to optimized JavaScript
  • run t2 run target/scala-2.11/tessel-scala-opt.js to deploy the resulting JavaScript to Tessel

After I figured out a couple of tweaks (scalaJSOutputWrapper and .tesselinclude), it just worked! Here is the code:

object Demo extends js.JSApp {

  def main(): Unit = {

    println(s"starting `main()` with node version ${g.process.version}")

    val tessel    = g.require("tessel")
    val relayMono = g.require("relay-mono")

    val relay = relayMono.use(tessel.port.A)

    relay.on("ready", () ⇒ {
      println("Relay ready!")

      js.timers.setInterval(2.seconds) {

      js.timers.setInterval(1.seconds) {

    relay.on("latch", (channel: Int, value: Boolean) ⇒ {
        println(s"Latch on relay channel $channel switched to $value")

        if (value)
          tessel.led(channel + 1).on()
          tessel.led(channel + 1).off()

Notice how I can call Tessel APIs from Scala without further ado. When used this way, Scala.js works like JavaScript: it’s all dynamic.

Types and facades

But a major reason to use Scala instead of JavaScript is to get help from types. So after that initial attempt I wrote some minimal facades for the Tessel and Node APIs I needed. Facades expose typed APIs to Scala, which allows the compiler to check that you are calling the APIs properly, and also gives your text editor a chance to provide autocompletion and suggestions. You can see this in action in IntelliJ:

Code completion in IntelliJ
Code completion in IntelliJ

Here are the minimal facades I have so far:

Along the way I realized that working on facades is also a great way to learn APIs in depth! This is the resulting code (which you can find on github):

object Demo extends js.JSApp {

  def main(): Unit = {

    println(s"starting `main()` with node version ${g.process.version}")

    val tessel    = Tessel()
    val relayMono = RelayMono()

    val relay = relayMono.use(tessel.port.A)

    relay.onReady {
      println("Relay ready!")

      js.timers.setInterval(2.seconds) {

      js.timers.setInterval(1.seconds) {

    relay.onLatch { (channel, value) ⇒
        println(s"Latch on relay channel $channel switched to $value")

        if (value)
          tessel.led(channel + 1).on()
          tessel.led(channel + 1).off()

As you can see, it’s not very different from the dynamic example, except that I now get help from the editor and compiler.

Why do this, again?

Now you might argue that in both cases the code looks more or less like JavaScript, so why go through the trouble?

It’s true that, superficially, JavaScript and Scala look very similar in these examples. But underneath there is Scala’s type system at work, and this is for me the main reason to want to use that language.

This said, there is more, such as:

  • Immutability by default. I like this because it helps reduce errors and works great with functional programming idioms.
  • Collections. Scala has a very complete collection library, including immutable collections (but you can also use mutable collections).
  • Functional programming. Scala was designed for functional from the get go and has some pretty neat functional programming third-party libraries too.

And I could go on with features like case classes, pattern matching and destructuring, for-comprehensions, and more. But I should also mention a few drawbacks of using Scala instead of JavaScript:

  • Harder language. Scala is a super interesting language, but no matter how you look at it, it is a bigger beast than JavaScript.
  • Executable size. Scala.js has an amazing optimizer which also strips the resulting JavaScript from pretty much any unused bit of code. Still, you will likely have resulting files which are larger than what you would get by writing JavaScript by hand. So expect your app to yield uncompressed JavaScript files in the order of a few hundreds of KB (much smaller when compressed). Tessel doesn’t seem to have any issues with that so far, so it might not be a problem at all, but it’s worth keeping an eye on this as Tessel doesn’t have Gigabytes of RAM.
  • Compilation step. There is a compilation and optimization step in addition to publishing the software to Tessel. For my very simple demo, this takes a couple of seconds only. For larger projects, the time will increase. Now this is very manageable thanks to sbt’s incremental compilation, and if you consider that pushing a project to Tessel can take several seconds anyway, I would say that right now it’s not an issue.

So who would want to program Tessel in Scala? Probably not everybody, but it’s a great option to have if you already know the language or are interested in learning it, especially if you are going to write large amounts of code.

What’s next?

I plan to continue playing with Tessel 2 and Scala. The next step is to try to do something fun (and maybe even useful) beyond blinking LEDs and relays!

Original URL:

Original article

Node v6.0.0

It’s here! Just three days shy of exactly six months after we released v5.0.0, the Node.js Foundation is happy to announce that Node.js v6 is available and ready for use!

This new major version of Node.js delivers significant improvements in performance, reliability, usability and security. Module loading is nearly four times faster than in Node.js v4, tests and documentation have seen significant improvements, usability of the Buffer and File System APIs have been improved, and Node.js now supports 93% of ES6 language features, thanks to V8 version 5.0.

In accordance with our Long Term Support plan, Node.js v4 ‘Argon’ will continue to be supported as an Active Long Term Support stream until April of 2017, after which it will transition into what we call Maintenance LTS. The new Node.js v6 branch will become the new Active Long Term Support stream in October of this year, and will continue to be supported actively until April of 2018. If our LTS plan is new to you, read more about how it works so that you can make a properly informed decision regarding which version of Node.js to adopt.

The general rule for deciding which version of Node.js to use is:

  • Stay on or upgrade to Node.js v4 (currently at v4.4.3) if you need stability and have a complex production environment.
  • Upgrade to Node.js v6 if you have the ability to upgrade versions quickly and want to play with the latest features as they arrive.

Note that while v6 will eventually transition into LTS, until it does, we will still be actively landing new features (semver-minor). This means that there is an increased chance for regressions to be introduced..

The release notes below are annotated with the main breaking changes that warrant the jump to v6. Note that because this new version of Node.js is shipping with a new version of V8, you will need to recompile any native addons you have already installed or you will receive a runtime error when trying to load them. Use npm rebuild or simply remove your node_modules directory and npm install from scratch.

What about Node.js v5?

Node.js v5 will continue to be supported for the next two months in order to give developers currently using v5 time to transition to Node.js v6.

What about Node.js v0.10 and v0.12?

If you’re still currently using Node.js v0.10 or v0.12, it is time to begin the transition to v4 or v6. Both v0.10 and v0.12 are considered to be in Maintenance mode currently and will fall off our support plan completely later this year.

Current? What happened to Stable?

You may have noticed that the v6 release uses the label Current instead of Stable. This name change has been made in order to better differentiate the Long Term Support releases from the current active development branches. We
will be using the Current label from here-on instead of Stable.

Notable changes

The following significant changes have been made since the previous Node.js
v5.0.0 release.

  • Buffer
    • New Buffer constructors have been added
      #4682 and
    • Existing Buffer() and SlowBuffer() constructors have been deprecated
      in docs #4682 and
    • Previously deprecated Buffer APIs are removed
    • Improved error handling #4514.
    • The Buffer.prototype.lastIndexOf() method has been added
  • Cluster
    • Worker emitted as first argument in ‘message’ event
    • The worker.exitedAfterDisconnect property replaces worker.suicide
  • Console
    • Calling console.timeEnd() with an unknown label now emits a process
      warning rather than throwing
  • Crypto
    • Improved error handling #3100,
    • Simplified Certificate class bindings
    • Improved control over FIPS mode
    • pbkdf2 digest overloading is deprecated
  • Dependencies
    • Reintroduce shared c-ares build support
    • V8 updated to #6372.
  • DNS
    • Add dns.resolvePtr() API to query plain DNS PTR records
  • Domains
    • Clear stack when no error handler
  • Events
    • The EventEmitter.prototype._events object no longer inherits from
      Object.prototype #6092.
    • The EventEmitter.prototype.prependListener() and
      EventEmitter.prototype.prependOnceListener() methods have been added
  • File System
    • The fs.realpath() and fs.realpathSync() methods have been updated
      to use a more efficient libuv-based implementation. This change includes
      the removal of the cache argument and the method can throw new errors
    • FS apis can now accept and return paths as Buffers
    • Error handling and type checking improvements
    •’s string interface is deprecated
  • HTTP
    • ‘clientError’ can now be used to return custom errors from an
      HTTP server #4557.
  • Modules
    • Current directory is now prioritized for local lookups
    • Symbolic links are preserved when requiring modules
  • Net
    • DNS hints no longer implicitly set
    • Improved error handling and type checking
  • OS X
    • MACOSX_DEPLOYMENT_TARGET has been bumped up to 10.7
  • Path
    • Improved type checking #5348.
  • Process
    • Introduce process warnings API
    • Throw exception when non-function passed to nextTick
  • Querystring
    • The object returned by querystring.parse() no longer inherits from
      Object.prototype #6055.
  • Readline
    • Key info is emitted unconditionally
    • History can now be explicitly disabled
  • REPL
    • Assignment to _ will emit a warning
    • Expressions will no longer be completed when eval fails
  • Timers
    • Fail early when callback is not a function
  • Streams
    • null is now an invalid chunk to write in object mode
  • TLS
    • Rename ‘clientError’ to ‘tlsClientError’
    • SHA1 used for sessionIdContext
  • TTY
    • Previously deprecated setRawMode wrapper is removed
  • URL
    • Username and password will be dropped by url.resolve() if the host
      changes #1480.
  • Util
    • Changes to Error object formatting
    • The util._extend() method has been deprecated
    • The util.log() method has been deprecated
  • Windows
    • Windows XP and Vista are no longer supported
  • Zlib
    • Multiple improvements have been made to Zlib processing
      #5883 and


Semver-major Changes since v5.0.0

  • [85ab4a5f12] – (SEMVER-MAJOR) buffer: add .from(), .alloc() and .allocUnsafe() (James M Snell) #4682
  • [2c55cc2d2c] – (SEMVER-MAJOR) buffer: remove deprecated Buffer.write branch ([email protected]) #5048
  • [101bca988c] – (SEMVER-MAJOR) buffer: remove deprecated buffer.get/.set methods (Feross Aboukhadijeh) #4594
  • [3b27dd5ce1] – (SEMVER-MAJOR) buffer: throw if both length and enc are passed (Mathias Buus) #4514
  • [3fe204c700] – (SEMVER-MAJOR) buffer: docs-only deprecate SlowBuffer (James M Snell) #5833
  • [627524973a] – (SEMVER-MAJOR) buffer: add Buffer.allocUnsafeSlow(size) (James M Snell) #5833
  • [204f3a8a0b] – (SEMVER-MAJOR) build: Bump MACOSX_DEPLOYMENT_TARGET to 10.7 (Сковорода Никита Андреевич) #6402
  • [90a5fc20be] – (SEMVER-MAJOR) build: remove lint/dotfiles from release tarball (Johan Bergström) #5695
  • [66f4586dd0] – (SEMVER-MAJOR) cluster: emit worker as first ‘message’ event arg (Ben Noordhuis) #5361
  • [4f619bde4c] – (SEMVER-MAJOR) cluster: migrate from worker.suicide (Evan Lucas) #3743
  • [a5cce79ec3] – (SEMVER-MAJOR) console: delete timers that have ended (Vladimir Varankin) #3562
  • [1c84579031] – (SEMVER-MAJOR) console: timeEnd() with no label emits warning (Eugene Obrezkov) #5901
  • [41feaa89e0] – (SEMVER-MAJOR) crypto: improve error messages (Sakthipriyan Vairamani) #3100
  • [f429fe1b88] – (SEMVER-MAJOR) crypto: fail early when loading crypto without openssl (James M Snell) #5611
  • [a37401e061] – (SEMVER-MAJOR) crypto: simplify Certificate class bindings (Alexander Makarenko) #5382
  • [7c48cb5601] – (SEMVER-MAJOR) crypto: Improve control of FIPS mode (Stefan Budeanu) #5181
  • [a1163582c5] – (SEMVER-MAJOR) crypto: pbkdf2 deprecate digest overload. (Tom Gallacher) #4047
  • [b010c87164] – (SEMVER-MAJOR) crypto, string_bytes: treat buffer str as utf8 (Fedor Indutny) #5522
  • [1d9451bb5a] – (SEMVER-MAJOR) crypto: better error message for createHash (Calvin Metcalf) #6042
  • [52af5c4eeb] – (SEMVER-MAJOR) deps: upgrade V8 to (Ali Ijaz Sheikh) #6111
  • [2253be95d0] – (SEMVER-MAJOR) deps: reintroduce supporting shared c-ares builds (Johan Bergström) #5775
  • [4bc1cccb22] – (SEMVER-MAJOR) dgram: pass null as error on successful send() (cjihrig) #5929
  • [dbdbdd4998] – (SEMVER-MAJOR) dns: add resolvePtr to query plain DNS PTR records (Daniel Turing) #4921
  • [c4ab861a49] – (SEMVER-MAJOR) dns: add failure test for dns.resolveXXX (Daniel Turing) #4921
  • [f3be421c1c] – (SEMVER-MAJOR) dns: coerce port to number in lookupService (Evan Lucas) #4883
  • [4d4f3535a9] – (SEMVER-MAJOR) doc: general improvements to fs.markdown (James M Snell) #5616
  • [d8290286b3] – (SEMVER-MAJOR) doc: document deprecation of util._extend (Benjamin Gruenbaum) #4903
  • [236b7e8dd1] – (SEMVER-MAJOR) doc: doc-only deprecation for util.log() (Jackson Tian) #6161
  • [90204cc468] – (SEMVER-MAJOR) domains: clear stack when no error handler (Julien Gilli) #4659
  • [e38bade828] – (SEMVER-MAJOR) events: don’t inherit from Object.prototype (Brian White) #6092
  • [53a95a5b12] – (SEMVER-MAJOR) fs: make error message more useful (James M Snell) #5616
  • [060e5f0c00] – (SEMVER-MAJOR) fs: Buffer and encoding enhancements to fs API (James M Snell) #5616
  • [8bb60e3c8d] – (SEMVER-MAJOR) fs: improve error message for invalid flag (James M Snell) #5590
  • [1124de2d76] – (SEMVER-MAJOR) fs: deprecate’s string interface (Sakthipriyan Vairamani) #4525
  • [2b15e68bbe] – (SEMVER-MAJOR) fs: into zero buffer should not throw exception (Feross Aboukhadijeh) #4518
  • [8b97249893] – (SEMVER-MAJOR) fs: fix the error report on (yorkie) #3917
  • [b488b19eaf] – (SEMVER-MAJOR) fs: optimize realpath using uv_fs_realpath() (Yuval Brik) #3594
  • [5f76b24e5e] – (SEMVER-MAJOR) http: overridable clientError (Fedor Indutny) #4557
  • [d01eb6882f] – (SEMVER-MAJOR) lib: add ‘pid’ prefix in internal/util (Minwoo Jung) #3878
  • [20285ad177] – (SEMVER-MAJOR) lib: Consistent error messages in all modules (micnic) #3374
  • [94b9948d63] – (SEMVER-MAJOR) lib,src: ensure ‘(node:pid)’ prefix for stdout logging (Minwoo Jung) #3833
  • [b70dc67828] – (SEMVER-MAJOR) lib,test: remove publicly exposed freelist (cjihrig) #3738
  • [d38503ab01] – (SEMVER-MAJOR) module: prioritize current dir for local lookups (Phillip Johnsen) #5689
  • [71470a8e45] – (SEMVER-MAJOR) module: pass v8::Object to linked module initialization function (Phillip Kovalev) #4771
  • [18490d3d5a] – (SEMVER-MAJOR) module: always decorate thrown errors (Brian White) #4287
  • [de1dc0ae2e] – (SEMVER-MAJOR) module: preserve symlinks when requiring (Alex Lamar) #5950
  • [b85a50b6da] – (SEMVER-MAJOR) net: remove implicit setting of DNS hints (cjihrig) #6021
  • [ec49fc8229] – (SEMVER-MAJOR) net: improve socket.write() error message (Phillip Johnsen) #5981
  • [d0edabecbf] – (SEMVER-MAJOR) net: strict checking for internal/net isLegalPort (James M Snell) #5733
  • [a78b3344f8] – (SEMVER-MAJOR) net: type check createServer options object (Sam Roberts) #2904
  • [02ac302b6d] – (SEMVER-MAJOR) net: Validate port in createServer().listen() (Dirceu Pereira Tiegs) #5732
  • [25751bedfe] – (SEMVER-MAJOR) node: deprecate process.EventEmitter (Evan Lucas) #5049
  • [08085c49b6] – (SEMVER-MAJOR) path: assert inputs are strings (Brian White) #5348
  • [d1000b4137] – (SEMVER-MAJOR) path: make format() consistent and more functional (Nathan Woltman) #2408
  • [c6656db352] – (SEMVER-MAJOR) process: add ‘warning’ event and process.emitWarning() (James M Snell) #4782
  • [72e3dd9f43] – (SEMVER-MAJOR) process: throw on non-function to nextTick() (yorkie) #3860
  • [5dafb435d8] – (SEMVER-MAJOR) querystring: using toString for objects on querystring.escape (Igor Kalashnikov) #5341
  • [dba245f796] – (SEMVER-MAJOR) querystring: don’t inherit from Object.prototype (Brian White) #6055
  • [0a62f929da] – (SEMVER-MAJOR) readline: emit key info unconditionally (cjihrig) #6024
  • [3de9bc9429] – (SEMVER-MAJOR) readline: document emitKeypressEvents() (cjihrig) #6024
  • [ca2e8b292f] – (SEMVER-MAJOR) readline: deprecate undocumented exports (cjihrig) #3862
  • [0303a2552e] – (SEMVER-MAJOR) readline: allow history to be disabled (surya panikkal) #6352
  • [ad8257fa5b] – (SEMVER-MAJOR) repl: Assignment of _ allowed with warning (Lance Ball) #5535
  • [3ee68f794f] – (SEMVER-MAJOR) repl: don’t complete expressions when eval fails (Anna Henningsen) #6328
  • [757fbac64b] – (SEMVER-MAJOR) src: remove deprecated internal functions (Ben Noordhuis) #6053
  • [4e46931406] – (SEMVER-MAJOR) src: deprecate undocumented variables (Jackson Tian) #1838
  • [57003520f8] – (SEMVER-MAJOR) src: attach error to stack on displayErrors (cjihrig) #4874
  • [e7c077c610] – (SEMVER-MAJOR) stream: make null an invalid chunk to write in object mode (Calvin Metcalf) #6170
  • [cc0342a517] – (SEMVER-MAJOR) streams: update .readable/.writable to false (Brian White) #4083
  • [652782d137] – (SEMVER-MAJOR) test: update test-repl-require for local paths (Myles Borins) #5689
  • [a5aa7c1713] – (SEMVER-MAJOR) test: expand test case for unknown file open flags (James M Snell) #5590
  • [2c33819370] – (SEMVER-MAJOR) test: fix tests that check error messages (cjihrig) #3727
  • [ac153bd2a6] – (SEMVER-MAJOR) timers: fail early when callback is not a function (Anna Henningsen) #4362
  • [1ab6b21360] – (SEMVER-MAJOR) tls: rename clientError to tlsClientError (Fedor Indutny) #4557
  • [df268f97bc] – (SEMVER-MAJOR) tls: use SHA1 for sessionIdContext (Stefan Budeanu) #3866
  • [8ffa20c495] – (SEMVER-MAJOR) tools: do not rewrite npm shebang in (Evan Lucas) #6098
  • [a2c0aa84e0] – (SEMVER-MAJOR) tty: Remove deprecated setRawMode wrapper (Wyatt Preul) #2528
  • [eb4201f07a] – (SEMVER-MAJOR) url: drop auth in url.resolve() if host changes (Alex Kocharin) #1480
  • [e2f47f5698] – (SEMVER-MAJOR) util: Change how Error objects are formatted (Mudit Ameta) #4582
  • [93d6b5fb68] – (SEMVER-MAJOR) util: use consistent Dates in inspect() (Xotic750) #4318
  • [24012a879d] – (SEMVER-MAJOR) util: make inspect more reliable (Evan Lucas) #4098
  • [007cfea308] – (SEMVER-MAJOR) util: remove pump (Wyatt Preul) #2531
  • [4cf19ad1bb] – (SEMVER-MAJOR) util: Remove exec, has been deprecated for years (Wyatt Preul) #2530
  • [34a35919e1] – (SEMVER-MAJOR) util: improve typed array formatting (Ben Noordhuis) #3793
  • [1cf26c036d] – (SEMVER-MAJOR) win: prevent node from running on Windows Vista or earlier (Alexis Campailla) #5167
  • [55db19074d] – (SEMVER-MAJOR) win,msi: prevent from installing on Windows Vista or earlier (Alexis Campailla) #5167
  • [’54a5287e3e’]
    (SEMVER-MAJOR) zlib: fix gzip member head/buffer boundary issue (Anna Henningsen) #5883
  • [8b43d3f52d] – (SEMVER-MAJOR) zlib: do not emit event on *Sync() methods (Rich Trott) #5707

Semver-minor and patch commits since v5.11.0

  • [6c1e5ad3ab] – (SEMVER-MINOR) buffer: add Buffer.prototype.lastIndexOf() ([email protected]) #4846
  • [dd67608bfd] – buffer: safeguard against accidental kNoZeroFill (Сковорода Никита Андреевич) nodejs/node-private#30
  • [a4b8000029] – build: update android-configure script for npm (Robert Chiras) #6349
  • [40ede46690] – cares: Support malloc(0) scenarios for AIX (Gireesh Punathil) #6305
  • [e5f1e2c1df] – deps: upgrade to V8 (Ali Ijaz Sheikh) #6372
  • [49e42c530b] – deps: upgrade to V8 (Ali Ijaz Sheikh) #6320
  • [2011f2c6dc] – doc: fix position of fs.readSync() (Jeremiah Senkpiel) #6399
  • [29a6c7c1f0] – doc: change references to Stable to Current (Myles Borins) #6318
  • [a026cd0fa5] – doc: update authors (James M Snell) #6373
  • [92a02d51dc] – doc: add JacksonTian to collaborators (Jackson Tian) #6388
  • [879aeb5e49] – doc: add Minqi Pan to collaborators (Minqi Pan) #6387
  • [be5d699055] – doc: add eljefedelrodeodeljefe to collaborators (Robert Jefe Lindstaedt) #6389
  • [916b1a1d44] – doc: add ronkorving to collaborators (ronkorving) #6385
  • [c7066fb853] – doc: add estliberitas to collaborators (Alexander Makarenko) #6386
  • [983a809456] – doc: fix broken references (Alexander Gromnitsky) #6350
  • [ae991e7577] – doc: add note for platform specific flags (Robert Jefe Lindstaedt) #6136
  • [f85412d49b] – doc: improvements to child_process, process docs (Alexander Makarenko)
  • [f6d90a912b] – doc: fix a typo in the (vsemozhetbyt) #6343
  • [6815a3b7f9] – doc: add vm example, be able to require modules (Robert Jefe Lindstaedt) #5323
  • [7f11634a46] – doc: note that process.config can and will be changed (James M Snell) #6266
  • [0e7d57af35] – (SEMVER-MINOR) events: add prependListener() and prependOnceListener() (James M Snell) #6032
  • [c1cd64481f] – events: make eventNames() use Reflect.ownKeys() (Luigi Pinca) #5822
  • [f1294f5bfd] – gyp: inherit parent for *.host (Johan Bergström) #6173
  • [d5922bd7a9] – querystring: fix comments (Brian White) #6365
  • [2c480bdae6] – src: fix linter errors (Sakthipriyan Vairamani) #6105
  • [5eb4ec090d] – src: squelch -Wunused-variable in non-icu builds (Ben Noordhuis) #6351
  • [a3b5b9cbf2] – src: fix out-of-bounds write in TwoByteValue (Anna Henningsen) #6330
  • [cdba9a6c02] – src: add intl and icu configs to process.binding(‘config’) (James M Snell) #6266
  • [2e974cdd8c] – src: add process.binding(‘config’) (James M Snell) #6266
  • [75e073f2b2] – test: increase the platform timeout for AIX (Michael Dawson) #6342
  • [84ebf2b40d] – test: add tests for console.assert (Evan Lucas) #6302
  • [a770a163ab] – test: v8-flags is sensitive to script caching (Ali Ijaz Sheikh) #6316
  • [1e4d053e6b] – test: don’t assume IPv6 in test-regress-GH-5727 (cjihrig) #6319
  • [a7335bd1f0] – test,benchmark: use deepStrictEqual() (Rich Trott) #6213
  • [6781d917f4] – tools: rewrite in python (Sakthipriyan Vairamani) #6105
  • [e84c69310f] – tools: enforce deepStrictEqual over deepEqual (Rich Trott) #6213
  • [7940ecfa00] – v8: warn in Template::Set() on improper use (Ben Noordhuis) #6277

Windows 32-bit Installer:
Windows 64-bit Installer:
Windows 32-bit Binary:
Windows 64-bit Binary:
Mac OS X 64-bit Installer:
Mac OS X 64-bit Binary:
Linux 32-bit Binary:
Linux 64-bit Binary:
Linux PPC LE 64-bit Binary:
SunOS 32-bit Binary:
SunOS 64-bit Binary:
ARMv6 32-bit Binary: Coming soon
ARMv7 32-bit Binary:
ARMv8 64-bit Binary:
Source Code:
Other release files:

Shasums (GPG signing hash: SHA512, file hash: SHA256):

Hash: SHA512

5be18c5571ce2b33918a3dd0be2f18d2a6939a60754026fb7e7967bec09d9e5e  node-v6.0.0-darwin-x64.tar.gz
9da8c11bf45f8b6b8c6a720cfaa37624d18d6972d8670c565b6e005e643b572a  node-v6.0.0-darwin-x64.tar.xz
f72de0e9403dd4ab7b6eec7266a498ba561afe5d5c7aff77b83894b43c959beb  node-v6.0.0-headers.tar.gz
8b6c5a315fefa7b873cbedd8daf75ee928646df2f05efa60c9c7d3a488851bd1  node-v6.0.0-headers.tar.xz
c4d7da92f76e77d27ef5650ad01085baad74439fab15e5143a8e9fc6cad13101  node-v6.0.0-linux-arm64.tar.gz
68d31984e304e5840591331bdd3eaa375fe07fa96307eb7d4681cea5ccb4e669  node-v6.0.0-linux-arm64.tar.xz
7a29af935545c07ea2eb5bbf6b6fb643765d50ee69d1b4193345a50fb8cb1093  node-v6.0.0-linux-armv7l.tar.gz
5a9b4c275313c1335819924c5028241cf2ee107032c530836b41938916090bd6  node-v6.0.0-linux-armv7l.tar.xz
7044f1049d6d8673cff7b0d38cd8c606be56ba149d3d32b34ca3f017df731a2a  node-v6.0.0-linux-ppc64le.tar.gz
65e208fb8189b264f6e66d0d4974485b5eb83cae2db34cc7d09464cb43142354  node-v6.0.0-linux-ppc64le.tar.xz
78fa76c77a1168095cf5b8a5018e00e7212d11e485cf10c77ce1c8af4955cdd3  node-v6.0.0-linux-x64.tar.gz
1e7aa64e28f26887810df74ca4bb0f3c37c332e866aefd16c23daedfcf67935b  node-v6.0.0-linux-x64.tar.xz
51321999e9706d9c24ea3689a03d049ad96657933228d3ed25d7710bc5d9e9bc  node-v6.0.0-linux-x86.tar.gz
5b1cbe9a5af935619b7d4a36d09cc3b73ea2605a1bd3ab9121920caba6f95a5e  node-v6.0.0-linux-x86.tar.xz
6f2114f02252c40304e3951b058ddababfe94b86e25cd8b3dddbf6aaa295ce71  node-v6.0.0.pkg
dc1345210205380af8fa16a63dca996803af105d7b0e5aa4160df7ed88523f08  node-v6.0.0-sunos-x64.tar.gz
0f69caa00c56e21c44c849e3e82e2fa3c775f441326f2668ac9503bc349eac03  node-v6.0.0-sunos-x64.tar.xz
61259a9794d2ed7b0e5331d5d2158da06f6ed5d31cbeae6d71da4d5e941a7754  node-v6.0.0-sunos-x86.tar.gz
822bd48f5443cc45513747b4ce3aa337ff98e27e8f4c63e6bbba23f7b57d2aa3  node-v6.0.0-sunos-x86.tar.xz
6db56d81a4e07ff4017809ad4ee49a5256fad804cd8527f8724f8e149e3dfc32  node-v6.0.0.tar.gz
f0e5bdc3cf4af85b8a24bdbebed81e1a9f7fda91cab8a9475737940aa90da617  node-v6.0.0.tar.xz
933a15791a67a2740cbd082a8d9aebc43162ec6d4db335abf62121a9561c57d4  node-v6.0.0-x64.msi
614380711039b7cc23db8d8cbf42ed9f4a6f0501eb8a143490f7ece952037bc9  node-v6.0.0-x86.msi
e2e434c5d63d684f0f0f074ee97b5a79fd0d9fbb340bac658f325239aec2589f  win-x64/node.exe
b1c9f9d58ef1fd684f0d136cce002e800c852203f876606b1b641692171783c3  win-x64/node.lib
675199b7db04f95545d8ca650b87b1cc6616e5e6638b854cd7f2bbabb050d533  win-x86/node.exe
c2b83ffce6edfdfee450f07fab28d299b99a1046a5ba9452830126303a0739b6  win-x86/node.lib
Comment: GPGTools -


Original URL:

Original article

Node.js Version 6 Released With LTS

dmleonard618 writes: The JavaScript runtime Node.js has reached version 6.0, and unlike version 5.0 this version will receive Long Term Support (LTS). LTS is meant to provide the release with long-term stability, reliability, performance and security. The LTS will begin in October. The current LTS release will go into maintenance mode and will only receive bug, security and documentation updates. Version 5.0 of Node.js will continue to be maintained for a few more months. The latest version features improved module loading, 96% of ECMAScript 2015 features, as well as reliability and security enhancements. “The Node.js Project has done an incredible job of bringing this version to life in the timeline that we initially proposed in September 2015,” said Mikeal Rogers, community manager for the Node.js Foundation. “It’s important for us to continue to deliver new versions of Node.js equipped with all the cutting-edge JavaScript features to serve the needs of developers and to continue to improve the performance and stability enterprises rely on.”

Share on Google+

Read more of this story at Slashdot.

Original URL:

Original article

Initial release of IdeaSpace – Open source CMS for the virtual reality web


Manage your virtual reality spaces, assets and content like you would manage blog posts.

VR Themes

Download and install new themes and publish your content. Or create your own theme using the IdeaSpace API.

Share VR Spaces

Embed spaces on your website or share on social media. It is simply VR on the web.

Powerful WebVR Engine

IdeaSpace is using Mozilla’s A-Frame for themes and spaces. It provides a powerful markup language following web standards.

Mobile and Desktop

Experience your virtual reality spaces with the Oculus Rift or Google Cardboard – in your web browser. No plugin or app installation needed.

Open Source and People

IdeaSpace has been built using awesome open source projects, carefully crafted by passionate people around the world.

Original URL:

Original article

Machine Learning, Recommendation Systems, and Data Analysis at Cloud Academy

In today’s guest post, Alex Casalboni and Giacomo Marinangeli of Cloud Academy discuss the design and development of their new Inspire system.


Our Challenge
Mixing technology and content has been our mission at Cloud Academy since the very early days. We are builders and we love technology, but we also know content is king. Serving our members with the best content and creating smart technology to automate it is what kept us up at night for a long time.

Companies are always fighting for people’s time and attention and at Cloud Academy, we face those same challenges as well. Our goal is to empower people, help them learn new Cloud skills every month, but we kept asking ourselves: “How much content is enough? How can we understand our customer’s goals and help them select the best learning paths?”

With this vision in mind about six months ago we created a project called Inspire which focuses on machine learning, recommendation systems and data analysis. Inspire solves our problem on two fronts. First, we see an incredible opportunity in improving the way we serve our content to our customers. It will allow us to provide better suggestions and create dedicated learning paths based on an individual’s skills, objectives and industries. Second, Inspire represented an incredible opportunity to improve our operations. We manage content that requires constant updates across multiple platforms with a continuously growing library of new technologies.

For instance, getting a notification to train on a new EC2 scenario that you’re using in your project can really make a difference in the way you learn new skills. By collecting data across our entire product, such as when you watch a video or when you’re completing an AWS quiz, we can gather that information to feed Inspire. Day by day, it keeps personalising your experience through different channels inside our product. The end result is a unique learning experience that will follow you throughout your entire journey and enable a customized continuous training approach based on your skills, job and goals.

Inspire: Powered by AWS
Inspire is heavily based on machine learning and AI technologies, enabled by our internal team of data scientists and engineers. Technically, this involves several machine learning models, which are trained on the huge amount of collected data. Once the Inspire models are fully trained, they need to be deployed in order to serve new predictions, at scale.

Here the challenge has been designing, deploying and managing a multi-model architecture, capable of storing our datasets, automatically training, updating and A/B testing our machine learning models, and ultimately offering a user-friendly and uniform interface to our website and mobile apps (available for iPhone and Android).

From the very beginning, we decided to focus high availability and scalability. With this in mind, we designed an (almost) serverless architecture based on AWS Lambda. Every machine learning model we build is trained offline and then deployed as an independent Lambda function.

Given the current maximum execution time of 5 minutes, we still run the training phase on a separate EC2 Spot instance, which reads the dataset from our data warehouse (hosted on Amazon RDS), but we are looking forward to migrating this step to a Lambda function as well.

We are using Amazon API Gateway to manage RESTful resources and API credentials, by mapping each resource to a specific Lambda function.

The overall architecture is logically represented in the diagram below:

Both our website and mobile app can invoke Inspire with simple HTTPS calls through API Gateway. Each Lambda function logically represents a single model and aims at solving a specific problem. More in detail, each Lambda function loads its configuration by downloading the corresponding machine learning model from Amazon S3 (i.e. a serialized representation of it).

Behind the scenes, and without any impact on scalability or availability, an EC2 instance takes care of periodically updating these S3 objects, as outcome of the offline training phase.

Moreover, we want to A/B test and optimize our machine learning models: this is transparently handled in the Lambda function itself by means of SixPack, an open-source A/B testing framework which uses Redis.

Data Collection Pipeline
As far as data collection is concerned, we use as data hub: with a single API call, it allows us to log events into multiple external integrations, such as Google Analytics, Mixpanel, etc. We also developed our own custom integration (via webhook) in order to persistently store the same data in our AWS-powered data warehouse, based on Amazon RDS.

Every event we send to is forwarded to a Lambda function – passing through API Gateway – which takes care of storing real-time data into an SQS queue. We use this queue as a temporary buffer in order to avoid scalability and persistency problems, even during downtime or scheduled maintenance. The Lambda function also handles the authenticity of the received data thanks to a signature, uniquely provided by

Once raw data has been written onto the SQS queue, an elastic fleet of EC2 instances reads each individual event – hence removing it from the queue without conflicts – and writes it into our RDS data warehouse, after performing the required data transformations.

The serverless architecture we have chosen drastically reduces the costs and problems of our internal operations, besides providing high availability and scalability by default.

Our Lambda functions have a pretty constant average response time – even during load peaks – and the SQS temporary buffer makes sure we have a fairly unlimited time and storage tolerance before any data gets lost.

At the same time, our machine learning models won’t need to scale up in a vertical or distributed fashion since Lambda takes care of horizontal scaling. Currently, they have an incredibly low average response time of 1ms (or less):

We consider Inspire an enabler for everything we do from a product and content perspective, both for our customers and our operations. We’ve worked to make this the core of our technology, so that its contributions can quickly be adapted and integrated by everyone internally. In the near future, it will be able to independently make decisions for our content team while focusing on our customers’ need.  At the end of the day, Inspire really answers our team’s doubts on which content we should prioritize, what works better and exactly how much of it we need. Our ultimate goal is to improve our customer’s learning experience by making Cloud Academy smarter by building real intelligence.

Join our Webinar
If you would like to learn more about Inspire, please join our April 27th webinar – How we Use AWS for Machine Learning and Data Collection.

Alex Casalboni, Senior Software Engineer, Cloud Academy
Giacomo Marinangeli, CTO, Cloud Academy

PS – Cloud Academy is hiring – check out our open positions!

Original URL:

Original article

Xi editor: A modern editor with a backend written in Rust

The xi editor project is an attempt to build a high quality text editor,
using modern software engineering techniques. It is initially built for
Mac OS X, using Cocoa for the user interface, but other targets are planned.

Goals include:

  • Insanely high performance. All editing operations should commit and paint
    in under 16ms. The editor should never make you wait for anything.

  • Beauty. The editor should fit well on a modern desktop, and not look like a
    throwback from the ’80s or ’90s. Text drawing should be done with the best
    technology available (Core Text on Mac, DirectWrite on Windows, etc.), and
    support Unicode fully.

  • Reliability. Crashing, hanging, or losing work should never happen.

  • Developer friendliness. It should be easy to customize xi editor, whether
    by adding plug-ins or hacking on the core.

Screenshot (will need to be updated as syntax coloring and UI polish is added):

xi screenshot

Getting started

You need Xcode 7 and Rust. You should have
cargo in your path.

> git clone 
> cd xi-editor
> xcodebuild
> open build/Release/

Or open XiEditor.xcodeproj and hit the Run button.

Design decisions

Here are some of the design decisions, and motivation why they should
contribute to the above goals:

  • Separation into front-end and back-end (the latter also known as “core”)
    modules. The front-end is responsible for presenting the user interface and
    drawing a screen full of text. The back-end holds the file buffers and is
    responsible for all potentially expensive editing operations.

  • Native UI. Cross-platform UI toolkits never look and feel quite right. The
    best technology for building a UI is the native framework of the platform.
    On Mac, that’s Cocoa.

  • Rust. The back-end needs to be extremely performant. In particular, it
    should use little more memory than the buffers being edited. That level of
    performance is possible in C++, but Rust offers a much more reliable, and
    in many ways, higher level programming platform.

  • A persistent rope data structure. Persistent ropes are efficient even for
    very large files. In addition, they present a simple interface to their
    clients – conceptually, they’re a sequence of characters just like a string,
    and the client need not be aware of any internal structure.

  • Asynchronous operations. The editor should never, ever block and prevent the
    user from getting their work done. For example, autosave will spawn a
    thread with a snapshot of the current editor buffer (the peristent rope
    data structure is copy-on-write so this operation is nearly free), which can
    then proceed to write out to disk at its leisure, while the buffer is still
    fully editable.

  • Plug-ins over scripting. Most text editors have an associated scripting
    language for extending functionality. However, these languages are usually
    both more arcane and less powerful than “real” languages. The xi editor will
    communicate with plugins through pipes, letting them be written in any
    language, and making it easier to integrate with other systems such as
    version control, deeper static analyzers of code, etc.

  • JSON. The protocol for front-end / back-end communication, as well as
    between the back-end and plug-ins, is based on simple JSON messages. I
    considered binary formats, but the actual improvement in performance would
    be completely in the noise. Using JSON considerably lowers friction for
    developing plug-ins, as it’s available out of the box for most modern
    languages, and there are plenty of the libraries available for the other

Current status

This is still a project in its early stages. The Mac build has basic editing
functionality (it was used to write this README), but looks very spare and
is still missing essentials such as syntax highlighting and auto-indent. At
the moment, it’s expected that its main community will be developers
interested in hacking on a text editor.


The main author is Raph Levien.


We gladly accept contributions via GitHub pull requests, as long as the author
has signed the Google Contributor License. Please see for
more details.


This is not an official Google product (experimental or otherwise), it
is just code that happens to be owned by Google.

Original URL:

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: