Git is great. We use it in all our projects. Some people prefer GUI: either built-in VCS integration from VSCode or WebStorm, or stand-alone apps like SourceTree. For the rest of us that are more comfortable with the command line, there is a must have productivity tool: SCM Breeze

Demo from the original repository

It saves time when working with git from the Terminal by adding shortcuts for git commands. Obviously it is faster to write gs instead of git status, gb instead of git branch and grhh rather than git reset HEAD --hard.

To see all git shortcuts added by SCM Breeze, run git_aliases.

Of course you can also easily add such aliases in your shell rc file by yourself, but this tool have even greater feature: file shortcuts. They allow you to reference files by numbers. Imagine that you need to stage 4 files out of 15 for commit. With this tool it would be as easy as gs followed by ga 1-3 6 (translates into git add $1 $2 $3 $6).

The API gives you a decent set of tools for changing and accessing the object.

Because you are not working with plain objects, integration with 3rd-party tools might require special attention, e. g.: when you use redux devtools to import or export the state, redux-persist to save and restore parts of it, when you use combineReducers, and basically every 3rd-party tool that serializes and deserializes the state, or uses methods that work on plain objects but not on Immutables.

This can be quite annoying, and you may find yourself battling with the tool instead of celebrating it.

Bottom line: if you are willing to sacrifice the disadvantages for the sake of enforcing immutability – choose one of these libraries.

lodash/fp

This is the functional-programming version of the famous lodash library. Each lodash method has an equivalent lodash/fp method, just with the object passed as the last parameter instead of first:

Sharing knowledge and supporting developers community was always one of the more important things for us at 500Tech.

Last week we celebrated six months for ReactNYC, our meetup for React and React Native developers in New York City. Hard to believe, but in such a short period of time we’ve got over 2300 members, hosted 15 events at 11 companies with almost 40 speakers, got over 400 followers on Twitter and four sponsors.

Organizing such a vibrant community isn’t easy, and luckily a lot of co-organizers are building the community with us. We owe a huge thanks to Kirill Cherkashin, Roman Ilyushin, Liron Burrack, Tessa Park, Ringo Kam, and many others.

At the kickoff meetup, when we saw a line around the block, it was obvious that it would be a huge success. The enthusiasm for React in New York is just amazing.

It is empowering to see so many people at every event. Developers come to learn new things, share their ideas, network with other developers and find a new job. Thanks everyone for coming and being a part of such a great community!

Apart from great talks, presentations, and workshops, we believe that meetups should also be fun. React Quizes and games like React Lifecycle Bingo, React Feud, React Taboo, and Guess the 3rd-party make the atmosphere more chill and inviting for everyone.

On August 1 npm was notified via twitter by Oscar Bolmsten that a package is maliciously stealing environment variables on install, using the popular cross-env package as bait by publishing a package similarly called as crossenv.

According to npm report further investigations revealed 40 packages in total using the same bait technique coined as “typo-squatting”.

What does this mean?

Environment variables are usually where application servers keep all their secrets such as database passwords, Amazon AWS access keys and much more sensitive data.

Because these packages often reach the production servers this can cause a hostile takeover to do anything the attacker wants, including spinning up new servers inducing large costs to the victims or gain access to databases and stealing users private data.

What do we do now?

First check the published list of malicious dependencies and check if your application or any of your dependencies are using any of the reported packages using npm ls in your application.

If you were affected you should reset all passwords and access tokens and removing the malicious packages.

How do we prevent this in the future?

While we can never guarantee malicious code entering our codebases via trusted and well known dependencies, we can continuously scan our applications for vulnerabilities using various services such as:snyk, Node Security Project (NSP), BlackDuck or any similar services which monitor our dependencies and check for vulnerbilities.

These services can alert us sooner so we can minimize the damage done as soon as possible.

Why this isn’t enough?

This isn’t the first time npm was mentioned in the context of security issues. Just over a year ago npm experienced a meltdown when a package called left-pad got unpublished, causing many popular packages such as Babel and ReactNative to fail installing.

Following this Nicolás Bevacqua authored a post about the security implications of npm where many concerns were not addressed. The current state of npm packages requires us to establish trust in package authors and npm but many things can go wrong even if the package author did not intend to harm us.

A package author may get his account compromised, go rogue or make a mistake. Even worse, a package could be taken over by a new author using npm Dispute Resolution which could release new versions of the package without the end users even noticing.

There are no validations in place when a package was transferred to a new author, no indication to users that the author has changed and no mechanism in place to force a major version release so users will at least have a hint to look into what changed in the package.

While npm currently deals with the issue at hand, these repeating issues call for npm to take security more seriously and think on how they can minimize attacks in the future using their platform.