Atom Linter v2 Released

It has been almost two years since the v1.0 of the linter package for Atom was released to the general public. Since then, we have come a long way. Linter is the second most downloaded Atom package right now with over 2.7 million downloads. Thank you for being a part of it 🙇.

Linter v2 has been in the oven for more than a year and I’m excited to announce it’s release to you today.

Separate UI package

Starting from v2, Linter has support for pluggable UI providers. The default UI has been moved to linter-ui-default. This opens ways for users to swap out UIs for Linter at will.

Linter Panel

The Linter Panel is now a table with sortable columns. You can configure it to represent the current file or the entire project.

Linter UI Default Panel

Linter Status

The Linter Status, after much feedback, now includes three separate counts for Errors, Warnings and Infos. You can configure it to toggle the panel or jump to the error of the specific type when clicked. Just like the Linter Panel, you can configure Linter Status to represent the current file or the entire project.

Linter UI Default Status

Busy Signal Integration

The new Linter UI now includes busy signal integration so you know which Linter provider is being excuted on which file.

Linter UI Default Busy Signal

Intentions Integration

Linter now fully integrates with the intentions package. This allows providers to use solutions in v2 and fix in v1 to allow the users to fix the issue without leaving the comfort of their Atom Editor.

Linter UI Default Intentions

Toggling Linter Providers

Linter v2 now includes commands to toggle linter providers from the command pallete.

Linter Toggle Providers

Tooltip Enhancements

We all know how intrusive tooltips can become when they follow your keyboard, therefore in v2 We’ve added an option for them to follow your mouse. This provides a much more comfortable Linter experience.

Linter UI Default following Mouse Linter UI Default Follows Keyboard

TreeView Decoration

Linter v2 now decorates your TreeView. This is especially useful when combined with Project-Scoped linters like flow-ide as it gives you the status of your entire project in just one look.

Linter UI Default Tree View

Upgrading to Linter v2

If you are a package maintainer, we’ve prepared migration docs for you. They are not perfect but we’re open to contributions!

Closing Thoughts

You can see Linter v2 in Action in the demo video.

This release is really exciting for me. I want to thank Landon Abney for his continued involvement in the Linter Project and for maintaining dozens of repositories in the AtomLinter org. Thanks to everyone who has ever contributed to the Linter Project, and the users for providing useful bug reports. Peace out 👋 ☮.

Should I root my Android Phone?

Android is an operating system developed by Google, primarily for Mobile Phones. Android is based on the Linux kernel and inherits it’s permissions structure. The operating system itself runs as the SuperUser or root and allows the user of the phone to perform tasks as a non-privileged one.

Why do you have to root

The reason Android doesn’t give root permissions to the user by default is because the power of root is limitless. Once an application is granted root access it could potentially read all of your saved passwords, credit cards and other sensitive information from any app in your mobile phone and could even compromise your Wifi passwords.

Furthermore it could do permanent damage to your operating system that you couldn’t fix without a reinstall, resulting in data loss for you. Your OEMs are actually being responsible when they patch the vulnerabilities in your phone that allow you to get root access.

You could only fix your compromised mobile phone by reinstalling it’s operating system and it’s not something everybody can do. Even if you can do it, doesn’t mean you won’t accidentally brick your phone.

While rooting your phone will give you full power to your operating system, it will also void your warranty in most of the countries and will block you out from services like Android Pay, Samsung Pay and similar services.

But I still want to root my phone

If you have really made up your mind, then be careful in how you distribute root permissions to applications. There are two main concerns about usage of root permissions

  1. Which su binary you use
  2. Which applications you grant root access to

If you are confused about the first one, remember that SuperSU was bought by a chinese company and one user even went as far to say it was sending out weird internet traffic. Remember, this is all of your privacy you are trusting your root management application with. Your root management application (that interacts directly with su binary) has full root access and manages prompts of other applications requesting root access so choose the one you trust the most. I personally find Phh superuser to be trust worthy.

Remember, there is no undo button with root. Once you give the wrong application root access it’ll infect your phone quicker than you realize maybe without you even noticing it’s happened. So be paranoid about giving applications root access.

How about a custom firmware from XDA

Again, custom firmwares on XDA are modified in ways you might not even know. You don’t know for sure that the Firmware you installed doesn’t have spyware on it and won’t send all of your passwords to some hacker’s servers. Your best bet if you value your privacy is sticking with unrooted Stock Firmware.

Closing thoughts

I am writing this all out because I voided my warranty and my sense of security thinking I’ll get better customizability with a rooted Custom Firmware. It wasn’t worth it, I couldn’t get my Gear VR working on Lineage OS because it’s Samsung only. and the latest LineageOS doesn’t even have a Theme Editor so my root wasn’t even worth the trouble. I knew what I was in for but I wasn’t. I ended up restoring to stock with my knox counter tripped. Don’t do what I did people.

How I manage multiple Node.js versions

Node.js is a lightweight Javascript runtime. It follows the Semantic Versioning scheme so every major release has multiple API breaking changes. We change our Node.js version to make a certain app work or to upgrade to the latest version.

After evaluating different popular options including NVM, Ubuntu Repos, Ubuntu PPAs, OSX Homebrew and OSX Macports I experienced a lot of issues with them including

  1. They are OS specific
  2. You cannot install specific Node.js versions
  3. They can cause conflicts when more than one users try to run different versions of same global modules
  4. You have to use sudo when installing global modules or linking local ones (except for homebrew)

I am a security conscious person, I would do anything to avoid using that sudo before installing modules from people I don’t even know. If you don’t share the same fear, read this Package install scripts vulnerability post by npm and you will.

How I do it

I use the n Node.js version manager by TJ Holowaychuk. Here’s it’s pros and cons in comparison

Things awesome about n

  1. Zero overhead (unlike NVM)
  2. Works on any POSIX environment
  3. Never asks for or requires sudo
  4. Can download any Node.js version
  5. Installs modules in ~/n so they are isolated per user

Possible downsides of n

  1. Too easy if you are a real programmer 😁

How you can too

There’s two different ways to install Node.js, the easy way is when you already have Node.js installed. The hard way assumes nothing!

The easy way

The easy way makes use of npm global scripts and is pretty simple.

npm install -g n

The hard way

The hard way makes use of n-install. It installs Node.js in your ~/n directory and does not uninstall or remove any previous versions. The first thing you should do is uninstall any installed version of Node.js.

You can skip the removal steps if you do not have Node.js installed already.

# If you use ubuntu
sudo apt-get remove --purge nodejs
# If you use homebrew
brew uninstall node
# If yu use macports
sudo port uninstall nodejs
# If you use nvm
LINK="https://github.com/creationix/nvm/issues/298"
xdg-open $LINK || open $LINK

Then to make sure, garbage collect the global node_modules directory

sudo rm -rf /usr/local/lib/node_modules
sudo rm -rf /usr/lib/node_modules

Now run the magical n-install script and it’ll set it up for you

curl -L -o /tmp/n-install-script https://git.io/n-install
bash /tmp/n-install-script -y
exec $SHELL # To re-initialize the PATH variable

That’s it fellaws, now you have an isolated, working Node.js setup.

Basic Usage

n is a bash script so it’s lightweight/minimal but still includes all the necessary features.

To upgrade to the latest version of Node.js do

n latest

or to install the lts version do

n lts

or say you want to download Node.js v4.4.1 do

n 4.4.1

If you want to access the list of installed versions and select between them, do

n

You can find more about n in it’s README.

Note: When switching between shells, remember to also include the line inserted by n-install in your ~/.bashrc or ~/.zshrc into your new shell configuration.

That’s all for now folks, happy coding!

How I debug Node.js

Node.js is a server side runtime for Javascript apps. Being a server sided runtime, it doesn’t have a GUI. Therefore it’s abilities to provide an easy to use debugging interface are limited.

There are several ways of debugging Node.js, here are few of the reasons why I don’t like the most popular ones

Builtin CLI debugger

  1. It doesn’t have a GUI of course
  2. It’s slow and even hangs at times
  3. You have to remember it’s commands
  4. Debugging complex problems is nearly impossible if not impossible

node-inspector

  1. It shows ES6 Maps and Sets as null
  2. It shows objects as empty randomly
  3. It is generally slow
  4. It’s very unstable

IDE Debuggers

  1. The IDEs are costy
  2. Each has their own UI
  3. They are hard to setup
  4. They lack advance features

Electron to the rescue

Electron is an open source project by GitHub, it is basically Chromium + Node.js. It has the best of both worlds, node’s require, globals and all the other APIs along with Chromium Dev Tools.

I have written a small wrapper around Electron to allow for quick Node.js debugging. It’s called DeNode, short for Debug Node. You can install it using npm

npm install -g denode

It registers itself as denode bin, it accepts an optional file path of the node module to execute on boot.

denode
denode ./index
denode `which browserify`

What’s awesome about this?

  1. You can click and expand on deep nested objects
  2. You can profile your apps for memory leaks and CPU time
  3. You can set breakpoints on the fly
  4. You can update running code from dev tools
  5. You can compile your files with babel and debug real source instead of gibberish using sourcemaps
  6. Basically, all the awesomeness of Chromium Dev Tools

What’s the side effect?

  1. Not having the ability to execute it over a network or VM, theoretically you could do X forwarding but it would get too slow and painful

That’s what I use to debug my Node.js app, let me know what you think of it in the comments below.