Monthly Archives: May 2017

Integrating Social Login in a Ruby on Rails Application

By Noman Ur Rehman

Facebook Developers Page

I remember the old days when people had to register for an account separately on each website.

It was a boring and tedious process to repetitively enter the same information over and over again on each website’s registration page.

Times have changed and so has the way people use their preferred websites and services.

After the advent of the OAuth2 specification, it has become quite a trivial task to allow your users to sign in to your application using a third party service.

Logging in through third party services has become such an important option that if your application does not have it, it seems a bit out-dated.

So, in this tutorial, we are going to learn how to allow your users to log in using their social media accounts.

During the course of this tutorial, you will learn.

  1. Creating an application on Facebook, Github, Google, and Twitter.
  2. Adding login strategies for Facebook, Github, Google, and Twitter to a Rails application.
  3. Writing callbacks to authenticate users upon redirection.

This tutorial assumes you have configured Devise without third party authentication and users are able to use your on-site Devise features. It is beyond the scope of this tutorial to demonsrate how to fully customize Devise and setup it’s on-site features. The repository for this tutorial includes the code you need to fully set up and customize Devise along with the code discussed as part of this tutorial.

Creating Applications

Though it is a bit out of scope, however, to round things up nicely, let us have a look at how to create an application through the respective third party websites.

Before we begin creating applications, there is a small bit regarding callback url that we need to talk about as we will need it when registering an application.

Some of the third party OAuth providers require that you specify a callback url when you create an application.

The callback url is used to redirect the user back to your application after they have granted permissions to your application and added it to their account.

Devise works by providing a callback url for each provider that you use.

The callback url follows the convention //auth//callback where provider is the gem name which is used to account for a specific third party login strategy.

For example, if my application is hosted at and I have created Devise for the users entity whom I wish to allow to log in using their Twitter account, the callback url, considering the gem name that provides the strategy is twitter, would be

We are going to confirm the callback routes later in this tutorial once we are done setting up the different providers.

Creating a Facebook Application

Log in to your Facebook account and browse to the url

I am assuming you have not registered for a Facebook developer account and have never created a Facebook application before.

Click the Register button at the top-right of the page.

Facebook Developer Registration

Accept the Facebook developer agreement(in the modal dialog) by turning the switch to YES and clicking the Register button.

Facebook Create Application

Click the Create App ID button that shows up in the same modal dialog.

Facebook Application Details

Fill in the Display Name, and Contact Email fields and click the Create App ID button.

Once your application is created, you will be taken to the application settings page.

Facebook Application Basic Settings

Choose Settings > Basic from the left menu.

Enter localhost in the App Domains field.

Click the Add Platform button at the bottom of the page.

Facebook Website Platform

Choose Website as the platform.

Enter http://localhost:3000 in the Site URL field.

Click the Save Changes button at the bottom of the page.

Facebook Application Dashboard

Choose Dashboard from the left menu.

Note down the App ID, and App Secret shown on the page as they will be needed later.

Creating a Github Application

Log in to your Github account.

Github Settings

Once you have logged in, click your account avatar at the top-right and choose Settings from the drop-down menu.

Github Register Application

On the Settings page, choose Developer settings > OAuth applications from the left menu.

Click the Register a new application button.

Github New Application

Fill in the Application name, Homepage URL, and Application description fields.

Enter http://localhost:3000/users/auth/github/callback in the Authorization callback URL field.

Click the Register application button.

Github Application Details

Once your application is created, you will be taken to the application page.

Note down the Client ID, and Client Secret shown on the page as they will be needed later.

Creating a Google Plus Application

Log in to your Google account and browse to the url

Google Developer Dashboard

On the Google developer console, choose Credentials from the left menu.

Google Credentials Page

Click the Create credentials button and choose OAuth client ID from the menu that pops up.

Google Create Credentials

For your Application type, choose Web application.

Google Application Type

Fill in the Name field.

Under the Restrictions section, enter http://localhost:3000 in the Authorized JavaScript origins field.

Enter http://localhost:3000/users/auth/google_oauth2/callback in the Authorized redirect URIs field and click the Create button.

Google Application Page

Once your application is created, you will be shown the client ID, and client secret in a modal dialog.

Google Credentials Modal

Note down the client ID, and client secret shown in the modal dialog as they will be needed later.

Creating a Twitter Application

Log in to your Twitter account and browse to the url

Twitter Developers Page

On the Twitter apps page, click the Create New App button.

Twitter Create Application

Fill in the Name, Description, and Website fields.

Enter http://localhost:3000/users/auth/twitter/callback in the Callback URL field.

Accept the Developer Agreement and click the Create your Twitter application button.

On the application page, that is shown next, click the Settings tab.

Twitter Settings Tab

Enter a mock url in the Privacy Policy URL, and Terms of Service URL field and click the Update Settings button.

Twitter Permissions Tab

Click the Permissions tab and change the Access type to Read only.

Check the Request email addresses from users field under the Additional Permissions section and click the Update Settings button.

Twitter Keys Tab

Click the Keys and Access Tokens tab.

Note down the Consumer Key (API Key), and Consumer Secret (API Secret) shown on the page as they will be needed later.

Adding Gems

We are going to need a number of gems to make authentication through third party providers work.

Apart from that, we are also going to add two additional gems.

The first one will help us store user sessions in the database while the second one will only be used in the development environment to set environment variables.

The reason we will allow our application to save user sessions in the database is because there is a limit to how much data you can store in a session which is four kilo-bytes. Using database as the session store will overcome this limitation.

As for using a gem to set environment variables in the development environment, it is because we will be using a lot of third party application information that needs to be kept secret.

Therefore, it is recommended to expose this information to our application as environment variables instead of adding it directly to a configuration file.

Open the file Gemfile and add the following gems.

# Use Devise for authentication
gem 'devise', '~> 4.2'
# Use Omniauth Facebook plugin
gem 'omniauth-facebook', '~> 4.0'
# Use Omniauth Github plugin
gem 'omniauth-github', '~> 1.1', '>= 1.1.2'
# Use Omniauth Google plugin
gem 'omniauth-google-oauth2', '~> 0.4.1'
# Use Omniauth Twitter plugin
gem 'omniauth-twitter', '~> 1.2', '>= 1.2.1'
# Use ActiveRecord Sessions
gem 'activerecord-session_store', '~> 1.0'

We have started off by adding the Devise gem.

Devise gem supports integration with Omniauth which is a gem that standardizes third party authentication for Rails applications.

Therefore, following the Devise gem, we have simply added the Omniauth strategies we need, namely, facebook, github, google-oauth2, and twitter.

Database sessions are facilitated by the activerecord-session_store gem which has been added towards the bottom.

The last gem we need to add is the dotenv gem.

However, since this gem will only be used in the development environment, we need to add it to the development group in the Gemfile.

Open the Gemfile, locate the group :development do declaration, and append the following gem.

group :development do
  # Use Dotenv for environment variables
  gem 'dotenv', '~> 2.2.1'

All our gems have been added.

Execute the following command at the root of your project to install the added gems.

$ bundle install --with development

Bundle Install Command

We are done as far as the gems for our project are concerned.

Setting Environment Variables

The dotenv gem we added earlier allows us to create a .env file at the root of our project and set environment variables easily.

However, if you are using source control like Git, make sure the .env file is ignored and not committed to your repository as it will contain confidential information.

You can however, add a .env.example file with placeholder data for the environment variables and commit it to the repository to show other developers on the project how information needs to be added to the .env file.

Also recall, when creating the third party applications, I instructed you to note down the respective client id and secret which we will be using here.

Create a .env file at the root of your project and add the following code.


The , and needs to be replaced with your application id and secret.

Similarly, replace the remaining placholders with the information provided to you by the respective third parties.


For our application configuration, we only need to touch a couple of areas, Devise and the session configuration.

Configuring Devise

Once we have added our provider application information as environment variables, we need to configure Devise to use it as part of the corresponding provider strategy.

Open the file config/initializers/devise.rb and add the following code.

# ==> OmniAuth
# Add a new OmniAuth provider. Check the wiki for more information on setting
# up on your models and hooks.

config.omniauth :facebook, ENV['FACEBOOK_APP_ID'], ENV['FACEBOOK_APP_SECRET'], scope: 'public_profile,email'
config.omniauth :github, ENV['GITHUB_APP_ID'], ENV['GITHUB_APP_SECRET'], scope: 'user,public_repo'
config.omniauth :google_oauth2, ENV['GOOGLE_APP_ID'], ENV['GOOGLE_APP_SECRET'], scope: ',userinfo.profile'
config.omniauth :twitter, ENV['TWITTER_APP_ID'], ENV['TWITTER_APP_SECRET']

You can use the comments in the above code snippet to locate the section of the configuration file where you need to add the Omniauth strategy settings.

The config.omniauth method lets you add and configure an Omniauth strategy.

In our case, we have simply passed the name of the strategy, and the application id and secret using environment variables.

There is also an additional scope parameter which has been added to some of the providers. It helps us specify the amount of control we wish to have over the authenticated user’s data.

The reason the scope parameter is optional is some of the providers allow you to specify the scope when you create an application so there is no need to be explicit in such a case.

Also notice, the strategy names(facebook, github, google_oauth2, and twitter) are the same as the gem name for the respective strategy.

Configuring Sessions

Open the file config/initializers/session_store.rb and replace the Rails.application.config.session_store directive with the following code, completely replacing the single line of code contained in the file.

Rails.application.config.session_store :active_record_store, key: '_devise-omniauth_session'

And we are done!

Writing Migrations

In order to allow our users to login using third party providers, we need to update the users table, more generally, the entity table you have generated that Devise uses to authenticate users.

I am going to assume the Devise entity is user but you can very well replace this entity name for your case.

We are also going to create a table to store user sessions.

Update Users Table Migration

Execute the following command at the root of your project to generate a update users table migration.

$ rails generate migration update_users

Rails Generate Migration Command

Open the file db/migrate/update_users.rb and add the following code.

class UpdateUsers < ActiveRecord::Migration[5.0]
  def change
    add_column(:users, :provider, :string, limit: 50, null: false, default: '')
    add_column(:users, :uid, :string, limit: 500, null: false, default: '')

The provider and uid fields help to identify a user uniquely as this pair will always have unique values.

For our case, the provider can be Facebook, Github, Google, or Twitter and the uid will be the user id assigned to a user by any of these third parties.

Create Sessions Table Migration

Execute the following command at the root of your project to generate a create sessions table migration.

$ rails generate migration create_sessions

Rails Generate Migration Command

Open the file db/migrate/create_sessions.rb and add the following code.

class CreateSessions < ActiveRecord::Migration
  def change
    create_table :sessions do |t|
      t.string :session_id, null: false
      t.text :data

    add_index :sessions, :session_id, unique: true
    add_index :sessions, :updated_at

Our sessions table stores the session id and data with timestamps.

We have also added an index to the session_id and updated_at fields respectively as it will help with searching user sessions when they return to our application.

Migrating the Database

Execute the following command at the root of your project to migrate the database.

$ rails db:migrate

Rails Database Migration Command

You may go ahead and browse the database to make sure the respective tables were created and updated.

Updating User Model

We are going to add a method to our user model that will create the user record in the database using the data provided by the third party provider.

We also need to register the Omniauth strategies in our user model so that they are picked up by Devise.

Again, your Devise entity may be different and so will be the model’s file name.

Open the file app/models/user.rb and add the following code.

class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable and :omniauthable
  devise  :database_authenticatable, :registerable,
        :recoverable, :rememberable, :trackable, :validatable,
        :confirmable, :lockable, :timeoutable,
        :omniauthable, omniauth_providers: [:facebook, :github, :google_oauth2, :twitter]

  def self.create_from_provider_data(provider_data)
    where(provider: provider_data.provider, uid: provider_data.uid).first_or_create do | user | =
      user.password = Devise.friendly_token[0, 20]

The omniauth_providers array passed to the devise method helps us register the Omniauth strategies.

The array contains symbolized names of the strategies. These names come from and should be same as the gem name for the respective Omniauth strategy.

The create_from_provider_data method is passed the data provided by the third party and is used to create the user in the database.

The user is first searched using the provider string and user id(uid) by the first_or_create method.

The first_or_create method would either fetch the user if it found in the database or create it if it is not present.

Inside the first_or_create block, we have simply set the user attributes from the provider data, which for our case is only the user’s email.

There are two parts worth mentioning inside the block.

The first one is the user.password = Devise.friendly_token[0, 20] which sets an arbitrary password for the user since it is not exposed by the provider and is required to create a user.

The second one is the user.skip_confirmation! declaration which skips the user email verification process since it has already been verified by the respective provider.

If you have added other fields to your Devise entity table such as first_name, last_name, and date of birth, you can set these fields to the corresponding field values in the third party provider data.

The Callbacks Controller

What we need to work on next is to add the controller that will be handling the third party redirects back to our application.

Execute the following command to generate an Omniauth callbacks controller.

$ rails generate controller users/omniauth

Rails Generate Controller Command

I have appended users/ before the controller name to generate it under a directory same as the Devise entity.

You can change it based on your Devise entity or if you are using multiple Devise entities, you can altogether skip adding the controller under a separate directory by simply executing rails generate controller omniauth.

It is a Devise convention to create a controller method named as the strategy that it will be handling the callback for so we will need to add four methods named facebook, github, google_oauth2, and twitter respectively to our Omniauth controller.

The controller actions that follow should be added to the app/controllers/users/omniauth_controller.rb file that we have just created.

Facebook Callback

# facebook callback
def facebook
  @user = User.create_from_provider_data(request.env['omniauth.auth'])
  if @user.persisted?
    sign_in_and_redirect @user
    set_flash_message(:notice, :success, kind: 'Facebook') if is_navigational_format?
    flash[:error] = 'There was a problem signing you in through Facebook. Please register or try signing in later.'
    redirect_to new_user_registration_url

The user data provided by the third party is available to our application in the request environment variable request.env['omniauth.auth'] so we have passed it to the create_from_provider_data method we created earlier.

If the user is saved to the database, we set a flash message using the set_flash_message helper method provided by Devise, sign the user in and redirect them to their homepage.

In case the user is not saved to the database, a flash error message is set and the user is redirected to the registration page.

The code for the remaining provider callbacks is very similar, other than the flash message text.

Github Callback

# github callback
def github
  @user = User.create_from_github_data(request.env['omniauth.auth'])
  if @user.persisted?
    sign_in_and_redirect @user
    set_flash_message(:notice, :success, kind: 'Github') if is_navigational_format?
    flash[:error] = 'There was a problem signing you in through Github. Please register or try signing in later.'
    redirect_to new_user_registration_url

Google Callback

# google callback
def google_oauth2
  @user = User.create_from_google_data(request.env['omniauth.auth'])
  if @user.persisted?
    sign_in_and_redirect @user
    set_flash_message(:notice, :success, kind: 'Google') if is_navigational_format?
    flash[:error] = 'There was a problem signing you in through Google. Please register or try signing in later.'
    redirect_to new_user_registration_url

Twitter Callback

# twitter callback
def twitter
  @user = User.create_from_twitter_data(request.env['omniauth.auth'])
  if @user.persisted?
    sign_in_and_redirect @user
    set_flash_message(:notice, :success, kind: 'Twitter') if is_navigational_format?
    flash[:error] = 'There was a problem signing you in through Twitter. Please register or try signing in later.'
    redirect_to new_user_registration_url

Failure Callback

Apart from the respective provider callbacks, we also need to add a failure callback which Devise will execute for all cases where authentication fails for some reason.

It could be that the redirection failed or the user did not grant permissions to your application.

Add the following failure callback, below the provider callbacks we added earlier.

def failure
  flash[:error] = 'There was a problem signing you in. Please register or try signing in later.' 
  redirect_to new_user_registration_url

Adding the Sign In Links

You might think that we need to add the appropriate links to redirect users to third party applications to allow them to sign in to our application but this is taken care of by Devise.

Open the file app/views/devise/shared/_links.html.erb and locate the following code snippet.

<%- if devise_mapping.omniauthable? %>
  <%- resource_class.omniauth_providers.each do |provider| %>
    <%= link_to "Sign in with #{OmniAuth::Utils.camelize(provider)}", omniauth_authorize_path(resource_name, provider) %><br />
  <% end -%>
<% end -%>

The above code snippet checks your Omniauth setup and auto-generates the required links.

Since this shared view is rendered on the sessions/new view, your users have the option to sign in using your configured providers.

Isn’t Devise a thing of beauty?

Adding Routes

The last piece of the puzzle is to set up the application routes.

Throughout this post, I have assumed that you have an on-site Devise implementation configured and fully functional.

So, there is a possibility you may already have the following route added to your routes file.

However, what you need to focus on is the additional controllers parameter which is used to specify the callbacks controller and will not be present in the route declaration that you have already added.

Rails.application.routes.draw do
  devise_for :users, controllers: { omniauth_callbacks: 'users/omniauth' }

Once you have configured the routes, you can execute the following command to make sure the callback urls were set up correctly.

$ rails routes

Rails Routes

Voila! we are all set up to test our application.

Time to Socialize

We have successfully added third party login through Facebook, Github, Google, and Twitter to our application.

It is time to take it out for a test drive.

Recall that we are using the dotenv gem in our development environment so the command to execute our rails application changes slightly based on that since we also want to set the environment variables to be available to our application.

Execute the following command to start your rails application.

$ dotenv rails server

Rails Server Command

Browse to Devise’s user login page and you should see the text “Sign in with…” for each of the providers we set up.

Here is a screenshot of how it looks with Devise’s primitive set up.

Devise User Login Page

Go ahead and try signing in.

You will be taken to the third party provider’s webpage where you will be prompted to grant your application access to the user’s data.

Once you have done that, you will be taken back to your application, to the user’s homepage, with a flash message notifying you of successful sign in.

Here is a screenshot of when the Sign in with Facebook link is clicked through.

Facebook Permissions Page


Adding a third party login option to your application is a nice touch and further enhances your application.

Though we have targeted four of the most famous of the lot, you are free to get your hands dirty and try the others available.

The Omniauth gem’s wiki has a comprehensive list of the strategies available and you should probably get to playing around with them.

I hope you found this tutorial interesting and knowledgeable. Until my next piece, happy coding!


Performance features in webpack 2

By Adam Kozuch

Webpack 2 is out for a while now with some interesting features which can help to control and improve the performance of your application. For this reason, we are going to talk about these features here in this blog post. I’m gonna start by talking about tree shaking feature which helps to reduce the size of your bundle by excluding unused exports in it. Then, I will briefly describe code splitting feature and how brand new performance configuration object can help you to use this feature properly.

Tree Shaking

The tree shaking feature is used during the transpiling process to exclude unused exports. Here is an example of how this feature can be used:

// exports.js
export function foo() {
  return 'used';

export function bar() {
  return 'unused';

if you want to print value returned by foo you could use following syntax:

// application.js
import {foo} from './exports'

By default, old webpack would include both foo and bar functions in the minified file. However, the new webpack introduces an algorithm for excluding parts of the code that are exported but not used in your application. Therefore, in the above case, the unused bar function won’t be included in the minified bundle. For further information about tree shaking, check out this blog post.

Code Splitting in webpack

By default,webpack is bundling your project into one monolith file. In other words, webpack generates one file containing all third-party libraries together with the code of your application. Therefore, each time you change something in the application, the whole file has to be re-uploaded to the server and then re-downloaded by the clients. Considering the fact that the source code of third-party libraries rarely changes while the code of your application changes frequently, it is very inefficient to keep reuploading and redownloading the whole file in this case. What if you could separate static and dynamic part of your code? Code splitting feature can do this.

In the next section, I will briefly explain various types of code splitting in webpack. Then, I will talk about the newly introduced performance configuration object which can give us more information about splits generation.

Vendor Code Splitting

These are third-party libraries whose content doesn’t change often; thus, browsers can load it once and then store it in the cache.

CSS Splitting

You can split CSS files into separate bundles. Such separation allows loading application code in parallel with styles. In this case, you can also take advantage of caching.

On Demand Code Splitting

This allows loading code splits that are only needed for a particular use case on programming request. That way you can prioritize resource loading. For more information, please check webpack documentation.

Code Splitting and Performance Indicators

Please note that bundle size can have a significant impact on your application load time. That’s why putting an effort in proper configuration of code splitting is worthwhile. After using the code splitting, how can we actually check if its configuration works as expected? Discussion about Webpack Performance Budgets led to adding performance configuration object in webpack 2. Thanks to this, you can now configure webpack to detect code splits that are above the expected size limit.

Setting property hints inside performance object will define webpack bahaviour for handling oversized splits. By default, hints is set to warning which will display a warning with information about oversized splits. You can also set it to error which will throw an error when the split is exceeding the size limit. You can adjust these options to your environment. For instance, webpack documentation recommends setting hints to error for production.

Other properties we can specify are maxEntryPointSize, maxAssetSize and assetFilter. I will explain them base on the example below:

performance: {
  hints: "warning",
  maxEntrypointSize: 300000,
  maxAssetSize: 150000,
  assetFilter: function(assetFilename) {
    return assetFilename.endsWith('.js');

By applying the above configuration, you will receive a warning when your entry assets are above 0.3 megabyte or when any assets emitted by webpack exceed 0.15 megabytes. Metrics will be calculated based only on the size of javascript files in the project.

The given numbers are just an example. On the Performance Budget site, you can specify your expected application load time, then based on that an appropriate bundle size for your application will be calculated. Having that number in your webpack configuration will help you to control the size of your code splits; therefore, avoid performance issues.

I hope that you find this post helpful. Feel free to leave some feedback here.


Join our free meetup in Denmark

Just a couple of weeks ago, we announced to bring our Angular Master Class to Denmark.

This will be a very special class for us as we are debuting our brand new courseware on Redux and ngrx for the first time in a public training.

If you haven’t had a chance to grab one of the early bird tickets, you can still get one of the regular tickets.

Join our free community event in the evening

As mentioned in the initial announcement, we’ll run a free event in the evening of June 21st at 5:30 PM.

The event takes place at the Auditorium at Foss. If you attend the training, you can simply follow us over to the Auditorium right after we finished the second day of the course.

For everyone joining the community event only, you’ll find the Auditorium at the following address.

Foss Allé 1

3400 Hillerød

What’s the theme?

The event will be focussed on short talks (5 – 20 min) with no strict guideline regarding topics. Anything from Angular, Progressive Web Apps to Blockchains and Machine Learning is appreciated.

Psst…first time speakers, this is your perfect chance

Announced Talks

As of today, we can plan for the following short talks.

  • Christoph Burgdorf – Machine Learning for everyone
  • Dominic Elm – Animations in Angular 4.2

Please ping us with your talk idea and we’ll add it to the list

See you in Denmark!

Source:: Thoughtram

Node.js Weekly Update - 26 May, 2017

By Gergely Németh

Node.js Weekly Update - 26 May, 2017

Below you can find RisingStack‘s collection of the most important Node.js news, projects, updates & security leaks from this week:

1. npm: basic http authentication to be limited soon

Since before the release of npm 2.0 in 2014, the company has encouraged developers using its’ APIs to use token authentication instead of passing username and password in a basic auth header.

Node.js Weekly Update - 26 May, 2017

Over the next few weeks we will be turning the recommendation into a requirement: basic http authentication will no longer work for any of the npm registry endpoints that require authorization. Instead you should use bearer tokens.

2. Node.js Streams: Everything you need to know

Streams are Node’s best and most misunderstood idea. Node.js streams have a reputation for being hard to work with, and even harder to understand.

Node.js Weekly Update - 26 May, 2017

Over the years, developers created lots of packages out there with the sole purpose of making working with streams easier. But in this article, I’m going to focus on the native Node.js stream API.

3. Getting Started with AWS Lambda & Node.js

Since the launch of AWS Lambda back in 2014, serverless (or FaaS – Function as a Service) computing became more and more popular. It lets you concentrate on your applications’ functionality by not having to worry about your infrastructure.

Node.js Weekly Update - 26 May, 2017

In this article we will discuss what serverless programming is, and how to get started with AWS Lambda as a Node.js Developer.

4. Node.js Security: Broken Authentication

Broken Authentication and Session Management attacks are anonymous attacks with the intention to try and retrieve passwords, user account information, IDs and other details.

Node.js Weekly Update - 26 May, 2017

This is a note about Node.js security, by reading the amazing book Securing Node Applications by @ChetanKarade, which explains couple of common vulnerabilities in very simple way, and provides relevant npm modules as solutions to protect Node.js Web Apps.

5. The Contributors Guide to webpack — Part 1

Jumping into an unfamiliar codebase (or any for that matter) for the first time can be scary. Plus, if it’s your first time contributing to open source, it can even be scarier!

Node.js Weekly Update - 26 May, 2017

at webpack believe:

  • Any (even non-technical) individual should feel welcome to contribute.
  • However you decide to contribute, it should be fun and enjoyable for you!
  • Even after your first commit, you will walk away understanding more about webpack or JavaScript.
  • Consequently, you could become a better developer, writer, designer, etc. along the way, and we are committed to helping foster this growth.

6. Using ES6 and modern language tools to program a MIDI controller

This detailed blogpost summarizes the challenges of creating a flexible and customizable MIDI controller mapping for the Mixxx DJ software.

Node.js Weekly Update - 26 May, 2017

I will focus on the technical aspects of using the scripting facilities of the platform, and tackling the difficulties encountered on the journey.

7. NodeConf Argentina Announced

Argentina is among the first international Node.js conferences taking place in Latin American territory, and a not-for-profit community effort to push Node.js forward in Argentina and Latin America as a whole.

Node.js Weekly Update - 26 May, 2017

This year’s conference will be a three–day event in sunny Buenos Aires, Argentina, held during October 26th, 27th & 28th. Both action-packed days will be comprised of internationally acclaimed, regional, and local speakers. We are expecting Noders, JavaScripters, front-enders, and other programmers from all over the world.

8. Node Interactive North America: Full Schedule Announced

Node Interactive will cover everything from security, diagnostics, machine learning & more. The Full schedule is up now!

Node.js Weekly Update - 26 May, 2017

Node.js Interactive is the marquee event for Node.js developers, companies that rely on Node.js and the vendors that support both of these constituents with tools, training and other services.

Vulnerable npm Packages Discovered:

High severity

Previously in the Node.js Weekly

In the previous Node.js Weekly Update we read about Ignition and Turbofan in V8, Packing a Kubernetes Node app with Helm, Developing Microservices & more..

We help you to stay up-to-date with Node.js on a daily basis too. Check out our Node.js news page and its Twitter feed!