Skip to main content
Tag

Certification

Sep 09
Love9

How ESLint Helps Developers to Write Better Code

By AMA, Blog, ESLint

In the OpenJS Foundation “Ask Me Anything” (AMA) series, we get to hear from many inspiring leaders in the JavaScript community. We will highlight the key questions answered by the panel members and provide resources to help developers save time and improve their code. This month, we feature ESLint.

In the middle of a project it can be difficult to identify redundant or problematic sections of code. Frustrations compound when multiple developers, all using different styles, need to collaborate and write using a unified format. However, the aforementioned problems can be avoided with gentle reminders and automated feedback.

This is where linters come in. Linters are essentially spell checkers for code. They highlight syntax errors, refactoring opportunities and style/formatting issues as code is written. This helps developers to notice and fix small errors before they become a major problem. ESLint is an especially powerful tool that identifies problematic sections of code based on the user’s plugins, rules and configurations. Due to its flexibility, it has become an incredibly popular addition to many projects. Kai Cataldo, a maintainer of ESLint, and Brandon Mills, a member of the Technical Steering Committee, answered questions and explained how to get started with the OpenJS project in a recent AMA. 

In the talk, Cataldo clarified that ESLint is designed to help developers write the code they want. It should not tell them whether their code is “right” or “wrong” unless the error is code-breaking. The default settings of ESLint help developers to recognize syntax errors early on, but the tool can be made more powerful with the addition of user defined rules or downloadable configurations. Additionally, teams can standardize code across a team by defining a set of rules for the linter. Therefore, developers save time by writing consistent code that can be easily understood by other members. 

Cataldo and Mills also revealed future plans for ESLint — updated documentation, simplified configuration and parallel linting. They also discussed common problems of linters and how developers can contribute to the project to make ESLint even more powerful. 

Full AMA Replay

https://youtu.be/9BnJWfyZre4

You can find the full AMA broken up by section below: 

0:57 Member Introductions 

3:19 Background of ESLint

5:55 What is a linter?

11:42 Why ESLint is moving away from correcting styling “errors” 

13:32 Future plans for ESLint

21:57 Will you add HTML linting? 

26:15 Exciting features in newest release

27:35 What is the most controversial linting rule? 

29:39 How to get started

32:25 Why doesn’t ESLint have default configurations? 

36:44 How to contribute

For those interested in becoming involved in the projects please check out the following resources:

Sep 02
Love12

OpenJS Foundation AMA: Node.js Certifications

By AMA, Blog, Certification, Node.js

In this AMA, we discussed the benefits of the OpenJS Node.js certification program. The certification tests a developer’s knowledge of Node.js and allows them to quickly establish their credibility and value in the job market. Robin Ginn, OpenJS Foundation Executive Director, served as the moderator. David Clements, Technical Lead of OpenJS Certifications, and Adrian Estrada, VP of Engineering at NodeSource, answered questions posed by the community. The full AMA is available at the link below: 

The OpenJS Foundation offers two certifications: OpenJS Node.js Application Developer (JSNAD) and OpenJS Node.js Services Developer (JSNSD). The Application Developer certification tests general knowledge of Node.js (file systems, streams etc.). On the other hand, the Services Developer certification asks developers to create basic Node services that might be required by a startup or enterprise. Services might include server setup and developing security to protect against malicious user input. 

In the talk, Clements and Estrada discussed why they created the certifications. They wanted to create an absolute measure of practical skill to help developers stand out and ease the difficulties of hiring for the industry. To that end, OpenJS certifications are relatively cheap and applicable to real world problems encountered in startup and enterprise environments. 

A timestamped summary of the video is available below: 

Note: If you are not familiar with the basics of the two certifications offered by the OpenJS Foundation, jumping to the two bolded sections may be a good place to start.

AMA Topics

Introductions 0:20

How did the members start working together? 2:35

How did work on the certifications start? 5:07

Is it possible to have feedback on the exam? 9:50

Applications of psychometric analysis 12:26

What is the Node.js Application Developer certification + Services Developer certification? 14:54

How do you take the exam? What should you expect? 18:22

Will there be differential pricing between countries? 22:04

How is the criteria for new npm packages chosen? 24:55

Are test takers able to use Google or mdn? 31:52

What benefits do OpenJS certifications have for developers? 33:22

How to use the certification after completion 39:43

What are the exam principles? 40:56

How much experience is required for the exam? 44:12 

Course available in Chinese 49:09

How will new Node versions affect the certifications? 53:43 

Closing thoughts 56:35

Jun 22
Love3

OpenJS World – Featured Profile – Beth Griggs

By Announcement, Blog, Event, Node.js, OpenJS World

Since 2016, Beth Griggs has been working as an Open Source Engineer at IBM where she focuses on the Node.js runtime. Node.js is an impact project in the OpenJS Foundation. Beth is a Node.js Technical Steering Committee Member and a member of the Node.js Release Working Group where she is involved with auditing commits for the long-term support (LTS) release lines and the creation of releases. 

What was your first experience of Node.js?

I joined the party a little late, my first experience of Node.js was while completing my final-year engineering project for my Bachelor’s degree in 2016. My engineering project was to create a ‘living meta-analysis’ tool that would enable researchers, specifically psychologists, to easily combine and update findings from related independent studies. I originally implemented the tool using a PHP framework, but after some time I realized I wasn’t enjoying the developer experience and hitting limitations with the framework. Half-way through my final year of university, I heard some classmates raving about Node.js, so I decided to check it out. Within a few weeks, I had reimplemented my project from scratch using Node.js.

How did you start contributing to Node.js?

I rejoined IBM in 2016, having spent my gap-year prior to university at IBM as Java Test Engineer in their WebSphere organization. I joined the Node.js team in IBM Runtime Technologies who at the time were responsible for building and testing the IBM SDK for Node.js. From running the Node.js test suite regularly internally, my team identified flaky tests that needed fixing out in the community – which turned in to some of my first contributions to Node.js core.

Over the next few years, our team deprecated the IBM SDK for Node.js in favor of maintaining these platforms directly in the Node.js community.  Around the same time, Myles Borins offered to mentor me to become involved with the Release Working Group, with a view of becoming a Node.js releaser (Thanks Myles!). Since then, that’s the area of Node.js where most of my contributions have been focused.

What has changed since you first started to contributing to Node.js?

One of the biggest changes is the emphasis on onboarding new contributors to major parts of the project. Getting new names and faces onboarded in a position where they can actively contribute to Node.js, and also an increase in socializing how people can contribute in ways other than code. 

Documentation of the internal contributor processes has improved a lot too, but there’s still room to improve.

What are you most excited about with the Node.js project at the moment?

I’m really enjoying the work that is happening in pkgjs GitHub organization where we’re building tools for package maintainers. I’m excited to see the tools that come out of pkgjs organization and the Node.js Package Maintenance team.

What are you most looking forward to at OpenJS World?

There are so many great talks (although, I’m a little bias as I was in the content team). I’m really looking forward to the keynote with Christina H Koch, a NASA astronaut. And also, the ‘Broken Promises’ workshop by James and Matteo from NearForm.

On the Cross Project Summit day, I’m looking forward to the Node.js Package Maintenance session. We’ve got a lot of momentum in that working group at the moment and it’ll be great to have input from the other OpenJS projects. I’m hoping my talk “Chronicles of the Node.js Ecosystem: The Consumer, The Author, and The Maintainer” is a good primer for the session. 

I’ll also be at the IBM virtual booth throughout the conference and catching my colleagues’ talks (https://developer.ibm.com/technologies/node-js/blogs/ibm-at-openjs-world-2020). 

What does your role at IBM include other than contributing to the Node.js community?

A wide variety of things really, no week is ever full of the same tasks. I’m often preparing talks and workshops for various conferences. Alongside that, I spend my time researching common methods and best practices for deploying Node.js applications to the cloud – specifically focusing on IBM Cloud and OpenShift. I often find myself assisting internal teams with their usage of Node.js, and analyzing various IBM offerings from a typical Node.js Developer’s point of view and providing feedback. I’m also scrum master for my team, so a portion of my time is taken up with those responsibilities too. 

What do you do outside of work?

Most often hanging out with my dog, Laddie. I’m a DIY enthusiast – mainly painting or upcycling various pieces of second-hand furniture. Since the start of lockdown in the UK, I have also been writing a book which is a convenient pass time. Big fan of replaying my old PS1 games too. 

Where should people go to get started contributing to the Node.js Project? 

Go to https://www.nodetodo.org/, which is a website that walks you through a path towards your first contribution to Node.js. As long as you’re a little bit familiar with Node.js, you can start here. The other option is to look for labels on repositories in the Node.js GitHub organization tagged with ‘Good first issue’. 

Alternatively, you can join one of our working group sessions on Zoom and start participating in discussions. The sessions are listed in the nodejs.org calendar. If you’re specifically interested in the Node.js Release Working Group, I run fortnightly mentoring/shadowing sessions that you’re welcome to join.

Jun 15
Love4

Node.js Certifications update: Node.js 10 to Node.js 12

By Announcement, Blog, Certification

The OpenJS Node.js Application Developer (JSNAD) and the OpenJS Node.js Services Developer (JSNSD) Exams will be updated from Node.js version 10, which is now in maintenance, to Node.js version 12, which is the current LTS (Long Term Support) line. Changes will come into effect June 16, 2020. All tests taking place after 8:00 am PT on June 16, 2020 will be based on Node.js version 12.

These exams are evergreen and soon after a Node.js version becomes the only LTS line the certifications are updated to stay in lockstep with that LTS version. Now that Node.js version 10 has moved into maintenance, certifications will be based on Node.js version 12. 

While there are no changes to the current set of Domains and Competencies for the JSNAD and JSNAD Exams, candidates are advised to review functionality of libraries or frameworks on Node.js version 12. For a full list of differences between Node.js version 10 and Node.js version 12 see https://nodejs.org/ca/blog/uncategorized/10-lts-to-12-lts/.

May 21
Love3

New Node.js Training Course Supports Developers in their Certification, Technical and Career Goals

By Announcement, Blog, Certification, Node.js

Last October, the OpenJS Foundation in partnership with The Linux Foundation, released two Node.js certification exams to better support Node.js developers through showcasing their skills in the JavaScript framework. Today, we are thrilled to unveil the next phase of the OpenJS certification and training program with a new training course, LFW211 – Node.js Application Development.

LFW211 is a vendor-neutral training geared toward developers who wish to master and demonstrate creating Node.js applications. The course trains developers on a broad range of Node.js capabilities at depth, equipping them with rigorous foundational skills and knowledge that will translate to building any kind of Node.js application or library.

By the end of the course, participants:

  • Understand foundational essentials for Node.js and JavaScript development
  • Become skillful with Node.js debugging practices and tools
  • Efficiently interact at a high level with I/O, binary data and system metadata
  • Attain proficiency in creating and consuming ecosystem/innersource libraries

Node.js Application Development also will help prepare those planning to take the OpenJS Node.js Application Developer certification exam. A bundled offering including access to both the training course and certification exam is also available.

Thank you to David Clements who developed this key training. Dave is a Principal Architect, public speaker, author of the Node Cookbook, and open source creator specializing in Node.js and browser JavaScript. David is also one of the technical leads and authors of the official OpenJS Node.js Application Developer Certification and OpenJS Node.js Services Developer Certification.

Node.js is one of the most popular JavaScript frameworks in the world. It powers hundreds of thousands of websites, including some of the most popular like Google, IBM, Microsoft and Netflix. Individual developers and enterprises use Node.js to power many of their most important web applications, making it essential to maintain a stable pool of qualified talent.

Ready to take the training? The course is available now. The $299 course fee – or $499 for a bundled offering of both the course and related certification exam – provides unlimited access to the course for one year to all content and labs. This course and exam, in addition to all Linux Foundation training courses and certification exams, are discounted 30% through May 31 by using code ANYWHERE30. Interested individuals may enroll here.

Apr 21
Love1

Project Update: Node.js version 14 available now

By Blog, Node.js, Project Update

This blog was written by Michael Dawson and Bethany Griggs, with additional contributions from the Node.js Community Committee and the Node.js Technical Steering Committee. This post initially appeared on the Node.js Blog. Node.js is an Impact Project of the OpenJS Foundation.

We’re excited to announce that Node.js 14 was released today! The highlights in this release include improved diagnostics, an upgrade of V8, an experimental Async Local Storage API, hardening of the streams APIs, removal of the Experimental Modules warning, and the removal of some long deprecated APIs.

Node.js 14 replaces Node.js 13 as our current release line. As per the release schedule (https://github.com/nodejs/Release#release-schedule), Node.js 14 will be the `Current` release for the next 6 months, and then promoted to Long-term Support (LTS) in October 2020. As always, corporate users should wait to upgrade their production deployments until October when Node.js is promoted to LTS. However, now is the best time to start testing applications with Node.js 14, and try out new features.

As a reminder — both Node.js 12 and Node.js 10 will remain in long-term support until April 2022 and April 2021 respectively (more details on the LTS strategy here).

Get started now! Learn how to download the latest version here: https://nodejs.org/en/download/current/

Before we dive into the features highlighted for this release, it’s important to note that new features added to the master flow quickly into the current release. This means that significant features become available in minor releases without too much fanfare. We’d like to take this opportunity to highlight some of those in the Node.js 14 release even though they may already have been backported to earlier releases.

Diagnostic Report goes Stable

The diagnostic report will be released as a stable feature in Node.js 14 (it was added as an experimental feature in Node.js 12). This is an important step in the ongoing work within the project to improve and build up the diagnostics available when using Node.js and the ease with which they can be used, with much of this work is pushed forward by the Node.js Diagnostics Working Group.

The diagnostic report feature allows you to generate a report on demand or when certain events occur. This report contains information that can be useful to help diagnose problems in production including crashes, slow performance, memory leaks, high CPU usage, unexpected errors and more. For more information about the diagnostic report feature, see https://medium.com/the-node-js-collection/easily-identify-problems-in-node-js-applications-with-diagnostic-report-dc82370d8029. As a stable feature there will be one less command-line option needed to enable Diagnostic reports and it should be easier for users to enable it in production environments.

V8 upgraded to V8 8.1

As always a new version of the V8 JavaScript engine brings performance tweaks and improvements as well as keeping Node.js up with the ongoing improvements in the language and runtime. This time we also have some naming fun with it being version 8 of V8 (“V8 of V8”).

Highlights of the new JavaScript features include:

  • Optional Chaining — MDN
  • Nullish Coalescing — MDN
  • Intl.DisplayNames  — MDN
  • Enables calendar and numberingSystem options for Intl.DateTimeFormat — MDN

For more information about the new features in V8 checkout the Node.js V8 blog: https://v8.dev/blog.

Experimental Async Local Storage API

The project has been working on APIs to help manage context across Asynchronous Calls over a number of releases. The experimental Async Hooks API was introduced in earlier versions as part of this work. One of the key use cases for Async Hooks was Async Local Storage (also referred to as Continuation Local Storage). There have been a number of npm modules that have provided APIs to address this need, however, over the years these have been tricky to maintain outside of Node.js core and the project reached a consensus that exploring having Node.js provide an API would make sense. The 14.x release brings an experimental Async Local storage API (which was also backported into 13.10) https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage. We are looking for the community to try out this API and give us feedback on abstraction model, API interface, use case coverage, functional stability, naming, documentation etc. so that we can work on getting it out of experimental in later releases. The best way to provide feedback is to open an issue in the diagnostics repository here (https://github.com/nodejs/diagnostics/issues) with a title along the lines of “Experience report with AsyncLocalStorage API”.

Streams

This release includes a number of changes marked as SemVer major in the Node.js Streams implementation. These changes are intended to improve consistency across the Streams APIs to remove ambiguity and streamline behaviors across the various parts of Node.js core. As an example, http.OutgoingMessage is similar to stream.Writable and net.Socket behaves exactly like stream.Duplex. A notable change is that the `autoDestroy` option is now defaulted to true, making the stream always call `_destroy` after ending. While we don’t believe these SemVer major changes will affect most applications, as they only change edge cases, if you rely heavily on Streams it would be good to test while Node.js 14 is the current release so that it is ready for when Node.js 14 becomes LTS in October 2020.

Experimental Web Assembly System Interface

Packages written in Web Assembly for Node.js bring the opportunity for better performance and cross-platform support for certain use cases. The 14.x release includes an experimental implementation of the Web Assembly System Interface (WASI) in order to help support these use cases. While not new to Node.js v 14, this is noteworthy as WASI has the potential to significantly simplify the native modules experience. You can read more about it in the API docs: https://nodejs.org/api/wasi.html.

Removal of Experimental Modules Warning

In Node.js 13 we removed the need to include the ` — experimental-modules` flag, but when running EcmaScript Modules in Node.js, this would still result in a warning `ExperimentalWarning: The ESM module loader is experimental.`

As of Node.js 14 there is no longer this warning when using ESM in Node.js. However, the ESM implementation in Node.js remains experimental. As per our stability index: “The feature is not subject to Semantic Versioning rules. Non-backward compatible changes or removal may occur in any future release.” Users should be cautious when using the feature in production environments.

Please keep in mind that the implementation of ESM in Node.js differs from the developer experience you might be familiar with. Most transpilation workflows support features such as optional file extensions or JSON modules that the Node.js ESM implementation does not support. It is highly likely that modules from transpiled environments will require a certain degree of refactoring to work in Node.js. It is worth mentioning that many of our design decisions were made with two primary goals. Spec compliance and Web Compatibility. It is our belief that the current implementation offers a future proof model to authoring ESM modules that paves the path to Universal JavaScript. Please read more in our documentation.

The ESM implementation in Node.js is still experimental but we do believe that we are getting very close to being able to call ESM in Node.js “stable”. Removing the warning is a huge step in that direction.

New compiler and platform minimums

Node.js provides pre-built binaries for a number of different platforms. For each major release, the minimum toolchains are assessed and raised where appropriate.

This release coincides with us moving all of our macOS binaries to be compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization. As binaries are still being compiled to support the respective compile targets for the release lines, we do not anticipate this having a negative impact on Node.js users on older versions of macOS. For Node.js 14, we’ve bumped the minimum macOS target version to macOS 10.13 (High Sierra).

On our Linux based platforms, for Node.js 14 the minimum GCC level remains at GCC 6, however, we plan to build/release the binaries for some of the platforms with GCC 8.

Node.js 14 will also not run on End-of-Life Windows distributions.

Further details are available in the Node.js BUILDING.md.

Call to action

For the 6 months, while it is in the ‘current’ phase, Node.js 14 will receive the most new features that are contributed to Node.js. For the next 6 months, this release line is perfect for trying out the latest features, testing the compatibility of your project with the latest Node.js updates and giving us feedback so that the release is ready to transition to LTS in October.

To download, visit: https://nodejs.org/en/download/current/

Thank you!

We’d like to use this opportunity to say a big thank you to all the contributors and Node.js collaborators that made this release come together. We’d also like to thank the Node.js Build Working Group for ensuring we have the infrastructure to create and test releases and making the necessary upgrades to our toolchains for Node.js 14. 

Apr 16
Love1

Maintainers Should Consider Following Node.js’ Release Schedule

By Blog, Node.js

This blog was written by Benjamin Coe. Ben works on the open-source libraries yargs, nyc, and c8, and is a core collaborator on Node.js. He works on the client libraries team at Google. This piece originally appeared on the Node.js Collection. Node.js is an impact project of the OpenJS Foundation.

tldr; Node.js has a tried and true release schedule, supporting LTS versions for 30 months. It offers significant benefits to the community for library maintainers to follow this same schedule:

  • ensuring the ability to take security patches.
  • reducing the burden on maintainers.
  • allowing module authors to take advantage of new platform features sooner.

My opinion of what Node.js versions library maintainers should aim to support has evolved over the years. Let me explain why…

The JavaScript ecosystem in 2014

I joined npm, Inc in April 2014. During this period, releases of Node.js had stalled. Node.js v0.10.x was released in April 2013, and Node.js v0.12.x wouldn’t be released until February 2015.

At the same time, the npm package registry was going through growing pains (see: “Outage Postmortem”, “Four hours of partial outage”, etc.).

The state of Node.js and npm in 2014 had side effects on how folks thought about writing libraries: maintainers didn’t need to put mental overhead into deciding what Node.js versions they supported (for years, the answer was 0.10.x); partially owing to npm’s instability, and partially owing to frontend communities not having fully embraced npm for distribution, package dependency trees were smaller.

Small building blocks, like mkdirp, still represented a significant portion of the registry in 2014.

Things would change in the intervening six years…

The JavaScript ecosystem today

In February of 2015, motivated by the io.js fork, The Node.js Foundation was announced. In September of that same year, Node.js v4.0.0 was released. Node.js v4.0.0 merged the io.js and Node.js projects unblocked the release logjam and introduced the 30-month LTS cycle advocated in this article.

Since Node.js v4.0.0, maintainers have been able to count on a regular cadence of releases, pulling in new JavaScript language features (through V8 updates), additions to the standard library (like HTTP/2), and important bug and security fixes.

In parallel, during the period between 2014 and today, npm significantly improved stability, and the frontend community began to consolidate on npm for distribution. The side effect was that many more packages were being published to npm (numbers grew from 50,000 in 2014, to 700,000 in 2018). At the same time, dependency trees grew (the average number of dependencies in 2016 was 35.3, the average number of dependencies in 2018 was 86).

A library maintainer in 2020 has at least three versions of Node.js to think about (the Current, Active, and Maintenance versions). Also, on average, their libraries rely on an increasing number of dependencies… it can be a bit daunting!

A library maintainer in 2020 has at least three versions of Node.js to think about (the Current, Active, and Maintenance versions).

A great way for maintainers to handle the increasing complexity of the JavaScript ecosystem is to consider adopting Node.js’ 30-month LTS schedule for their own libraries.

Here’s how adopting this schedule benefits both the library authors and the community…

Being able to take security patches

A security vulnerability was recently reported for the library minimist. minimist is the direct dependency of 14,000 libraries… it’s a transitive dependency of the universe.

The popular templating library Handlebars was bitten by this report through an indirect dependency (optimist). Handlebars was put in a position where it was difficult to silence this security warning without disrupting its users:

  • optimist, deprecated several years earlier, was pinned to an unpatched version(~0.0.1) of minimist.
  • Handlebars itself supported Node.js v0.4.7, making it a breaking change to update to yargs (optimist’s pirate-themed successor).

Although motivated by good intentions (“why not support as many environments as possible?”), when libraries support end-of-life versions of Node.js, it can ultimately end in disruptions for users. Maintainers find themselves bumping a major version as a fire drill, rather than as a scheduled update.

Dropping support for old @nodejs release is a breaking change and it should be released in a major version.. — Matteo Collina

The wide adoption of Node.js’ LTS schedule for modules ensures that security patches can always be taken.

Reducing the burden on maintainers

Keeping dependencies up to date is a lot of work (my team at Google landed 1483 pull requests updating dependencies last month), it’s also important:

  • the closer to a dependency’s release you catch an unintended breakage, the more likely it will be quickly fixed or rolled back.
  • keeping dependencies fresh helps ensure that critical vulnerabilities and bug fixes are rolled out to your own users (this avoids the Handlebars/minimist issue discussed).

Tools like Dependabot and Renovate make sure updating dependencies isn’t a maintainer’s full-time job. However, if libraries don’t adhere to the same version support policy, it makes automation difficult. As an example, because of falling behind the scheduled deprecation of Node.js v8.x.x, the library yargs turned off automatic updates for decamelize (opening itself up to all the risks that go along with this).

A lot of open-source is made possible by the volunteer work of maintainers. I can’t think of many things less exciting than the constant auditing of the SemVer ranges advertised in the “engines” fields of dependencies.

The wide adoption of Node.js’ LTS schedule for modules creates consistency and reduces the maintainer burden around updating dependencies.

Helping to evolve the platform

For the last couple of years, I’ve been involved in the Node.js Tooling Group. We’ve advocated for a variety of API improvements for tooling authors, such as recursive directory creation, recursive directory removal, and Source Map support for stack traces.

In Node.js v8.4.0, http2 support was added. This addition is near and dear to my heart since it allows Google’s client libraries (which rely on HTTP/2) to run natively on Node.js.

JavaScript itself is an evolving platform. Node.js regularly updates the V8 JavaScript engine, pulling in new language features, such as async iterators, async/await, and spread operators.

Keeping the Node.js core small will always be an architectural goal of the project. Node.js is, however, an evolving platform.

The wide adoption of Node.js’ LTS release schedule allows module authors to leverage exciting new features that are added to the platform.

What actions am I advocating that library maintainers take?

  1. When you release a new library, set the engines field to the oldest active LTS version of Node.js.
  2. When a Node.js version reaches end-of-life, even if your library is finished, bump a major version updating the engines field to the current oldest active LTS of Node.js.
  3. Consider throwing a helpful exception if your library is used on an unsupported Node.js version.
  4. Consider documenting your version support policy (here’s an example of the one we wrote for my team).

The Node.js Package Maintenance Working Group is developing further recommendations related to library support policies, such as Cloud Native’s Long Term Support for Node.js Modules. This policy takes this article’s recommendations a step further and suggests that module maintainers support a major library version for the lifetime of the Node.js runtime it was released under. This means that, if your library releases v1.0.0 with support for Node v10.x.x, you would continue to backport security and bug fixes to v1.0.0 until Node v10.x.x reaches end-of-life. Committing to this level of support can be a great move for libraries targeting enterprise users (and, they even have a badge!).

Tracking Node.js’ release schedule saves you time, makes libraries more secure, allows you to use Node.js’ fancy new features, and benefits the community as a whole. Let’s get good about doing this together.

Apr 14
Love1

You Told Us: OpenJS Node Certification helps you stand out

By Blog, Certification, Node.js

The Node.js industry is mature and there is more demand for Node skills than there are qualified developers. OpenJS Node certifications create new opportunities for developers, and are an excellent way to improve your resume, and more quickly move to projects and jobs that are higher-paying and more fulfilling.

We asked a group of developers who took at least one of the certifications in the past three months about their experiences. Two major themes stand out.

  1. Yes, money is important, but effectively testing your own skills is important, too
  2. A vendor-neutral certification is better and the OpenJS format really challenges you

Nikita Galkin, Independent Contractor, JSFest Program Committee Member, Software Engineer, System Architect, Node.js Tech Speaker, GraphQL Advocate, talked about standing out:

Remote work in the global world has high competition between developers. With a certificate, you are more likely to receive an invitation to the job interview.

I received an offer for an interesting remote project with a good salary at the start of this year. At the tech-interview end I was asked “what this certification is?” and “how was it complicated?”.

I do not think the certification was critical in deciding in my favour, but that was one of the things that made me different from other applicants.

Patrick Heneise, Software Consultant & CEO, Zentered.co, explained it was about testing his own skills:

I wanted to know, after almost 9 years of Node.js where I stand. Having a Certified Node.js badge on my social profile. It’s an easy sign for potential customers and clients that my knowledge has been tested. 

I wasn’t looking for a new job or more money, so I can’t tell if it helped. But definitely helped me to know my strengths and weaknesses, and I found out where I need to improve my own skills.

João Moura, Lead Technical Architect at Isobar Switzerland, likes how OpenJS certification tests differ from vendor-specific tests:

I think it’s a major benefit to have a certification on NodeJS. In the current days, NodeJS is becoming one of the major development infrastructures and I want to be part of that. The certification is one more step in that direction.

From the experience I have, the vendor-specific exams tend to have questions that are there just to show you how great their product is, for example:

“what can this product do?

A: something

B: another thing

C: awesome things

D: all of the above”

The answer is obviously D, and now you have a certificate on that product, congratulations :).

Since this is vendor-neutral, the exam is a lot more directed to see what the user does to solve a specific problem, there is no selling material, the person taking the exam needs to really understand the problem and solve it in a good and quick way. and that for me is a lot more entertaining :).

Justin Dennison, Edutainer at ITProTV, says that completing tasks, instead of answering questions, was closer to a real development environment:

I enjoyed the test-taking experience as it was the first exam that I had taken that was simulated and practical in nature. Instead of answering multiple-choice questions (or any of the other types), I thought that completing the tasks was more akin to my experience in a development environment. The testing was thorough for Node.js as a whole. I feel that vendor-neutral testing allows for an alternative perspective to testing as well as a means to gather community driven requirements.

I took the certification to validate my own understanding and learning. I had been developing using Node.js and teaching Node.js for several years. However, as always, there are times that you will question yourself, “Do I really know or understand what is going on?” Knowing that I was given tasks to complete and was able to complete those task using Node.js was a nice confirmation of my knowledge. 

Amir Elemam, Independent Contractor, liked the format of the test excellent, it resulted in more interesting relationships and projects at work:

The coding labs exam format was totally new for me. On the one hand it was harder because if I wasn’t pretty sure about something, to a point where I would know what to search for, there was no way to even try the question, but on the other hand, I was able to test the code I was writing, so in the end I had a very good sense about my performance, that’s good because the results don’t come out by end of the exam, as it happens with other certification exams I’ve taken.

The first thing was boosted my self- confidence, I no longer have any shred of doubt about my Node.js capabilities. Also, it improved how confident others were about my Node.js skills, which improved relationships and more challenges were given.

Find out more about the OpenJS certification programs, and sign up now!

Oct 23
Love1

OpenJS Certification Program: Pricing Feedback

By Announcement, Blog, Certification

By Robin Ginn, Executive Director at the OpenJS Foundation

Since launching our Node.js professional certification program yesterday, we’ve received feedback and concerns around the pricing of these exams. As a foundation that exists to support open source projects, we aim to continually improve from community input. For those who have taken the time to offer up their suggestions, we really appreciate it.

We will continue to explore ways to make the Node.js certification program more open and accessible for diverse communities including a broad range of socioeconomic backgrounds and geographical locations. We’re seeking to partner with community-focused organizations who can potentially bridge gaps and create access, of course pending the specific solution. 

We are eager to collaborate with the community on the best solution and would invite anyone interested in providing further feedback on these initiatives to let us know by filling out this form or directly mentioning the OpenJS Foundation on Twitter. 

In the coming weeks, we plan to provide an update on the program.
If you have further questions, check out the Node.js Certification FAQ on our OpenJS Foundation Certification page. You can also send feedback and ideas directly to me at rginn@openjsf.org.

Oct 22
Love1

OpenJS Foundation launches new professional certification program to support the future of Node.js development

By Announcement, Blog, Certification

The certifications focus on critical skills that Node.js developers need to build Node.js applications and services in professional environments; Certification is valid for three years with a renewal option

San Francisco – October 22, 2019 – The OpenJS Foundation, providing vendor-neutral support for sustained growth within the open source JavaScript community, today announced the OpenJS Node.js Application Developer (JSNAD) and OpenJS Node.js Services Developer (JSNSD) certification programs. The two certification programs are aimed at Node.js developers and are designed to demonstrate competence within the Node.js framework. The JSNAD and JSNSD certification programs, developed in partnership with NearForm and NodeSource, are available immediately. 


“The OpenJS Node.js professional certification programs are designed to help developers demonstrate their Node.js proficiency in real-world environments and provide them with the knowledge to bring these technologies to their respective organizations,” said Robin Ginn, OpenJS Foundation Executive Director. “The exams provide a framework, developed by expert practitioners from the Node.js community, that illustrates the range of skills for experienced developers. We are excited to provide these certifications through the OpenJS Foundation as a clear, vendor-neutral way of showcasing key Node.js abilities.”

“As a leading telecommunication company serving millions of Canadian customers, a skilled technical talent pipeline is crucial to our continued success at TELUS,” said Luca Maraschi, Principal Architect at TELUS. “Given our role in the alpha testing of these certifications, we are confident that they will highlight the right skills of Node.js developers and we are excited to have these programs available to ensure our developer community continues to thrive.”

“The arrival of these exams is an exciting step for the OpenJS Foundation as it represents another way for us to support developers within the community,” said Todd Moore, OpenJS Foundation Board Chair. “We look forward to having these tests available on the market and for the diverse set of Node.js developers to take these exams, get certified and showcase their knowledge of this crucial technology.”

“The availability of certification is a big milestone for the Node.js project. We now have formal materials and exams available which will support the next wave of adoption of node.js in the enterprise,” said Cian Ó Maidín, NearForm CEO & Founder. “We’re proud of the work all of the partners have put into making this happen.”

“We are thrilled to see this important initiative come to life, and are proud to have been a part of creating this opportunity to enable developers to validate their skills with certification,” said Russ Whitman, CEO of NodeSource. “Backed by the Foundation, supported by NodeSource and key community members we hope this will advance Node.js adoption and the amazing products and services being developed. We couldn’t be more excited.” 

OpenJS Node.js Application Developer (JSNAD)The OpenJS Node.js Application Developer certification is ideal for the Node.js developer with at least two years of experience working with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnad/

OpenJS Node.js Services Developer (JSNSD)
The OpenJS Node.js Services Developer certification is for the Node.js developer with at least two years of experience creating RESTful servers and services with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnsd/

Both exams are two hours long, performance-based exams delivered via a browser-based terminal and each includes an automatic free retake (if needed). Exams are monitored by a live human proctor and are conducted online in English. Certification is valid for three years and includes a PDF Certificate and a digital badge. Corporate pricing for groups of five or more is available.

Supporting Quotes from Test Takers

Steve Toro, Software Engineer, Addigy Technology
Great job on this exam! It definitely exposes the knowledge you’re missing from the core node.js packages. It’s not enough to use Node and Express for web development for this one.

Oleksandr Zhurbenko, Full Stack Developer, Scotiabank
This is the first time I took the exam in the live coding format. Even though I didn’t have enough time to finish it, I still loved the process. I wish there were more exams like this. Great job!

Yerko Palma, Senior Developer, Chilena Consolidated
This exam format is ideal, and all programming/tech exams should be set up this way. It provides for a much more accurate evaluation of people’s skills over any other format because it mirrors every-day tasks for node.js devs.

Luke Chinworth, Web Developer, Solid Digital
I liked that the questions were directly related to real world tasks.  

Vinicius Mussak, Microsoft MVP / Project Coordinator, SMN Technologies
I very much like the real code, API construction, requests, because it reflects our day jobs in our companies.

Nathaniel Burgwyn, Beta Tester
This feels really close to what I feel the exam should be.  As a manager, I would feel confident in a candidate who possessed this certification.

About OpenJS Foundation 
The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 32 open source JavaScript projects including Appium, Dojo, jQuery, Node.js, and webpack and is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

Close Menu