Prettier: Automatic code formatting for the Javascript ecosystem

I do most of my work in the Go ecosystem and rely heavily on the go fmt tool to maintain style consistency across the team. But the javascript language does not have a formatter built in so we have been relying on jslint to enforce consistent styles.  I found a auto-formatter for javascript prettier, which could make frontend formatting much easier you can find it at https://prettier.io. Prettier supports JSX which is key for us since we work on a single page application with a react.js frontend. I have added prettier to my crypto-exchange application https://github.com/Sevii/pepper-exchange to evaluate how well it works.

I dislike using linters to address code formatting and style questions because they basically nag developers into formatting things correctly.  Code formatting is low value work, I would much rather have a machine do it in 250ms  than have a developer spend 60 seconds addressing linter issues. 

Prettier should let us eliminate formatting nagware, and limit our use of jslint to semantic and correctness issues.

You can use prettier as follows. 

yarn add prettier --dev --exact

# or globally

yarn global add prettier

prettier --write "src/**/*.js"    # This command will format any .js files in your src folder.

Git hooks for Go fmt

A common problem when reviewing pull requests is large diffs of formatting changes. You end up with pages of formatting changes that people waste time looking at when in reality it was just a 3 line PR. Go has a tool called fmt which can format any Go code into the standard Go format. What happens in my project is that some of the team has their IDE configured to automatically run go fmt when they save a file, while the rest do not. So our codebase is in an inconsistently formatted state. What I am attempting to do is to setup a git-hook that will run go fmt before any commits.

The .git/hooks directory contains samples of git hooks that can be triggered on various git actions like pre-commit, post-commit, post-receive, etc. The files need to be executable, with no extension and named after the appropriate hook. This digital ocean link has a table of the available hooks if you scroll down a bit https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#basic-idea-with-git-hooks. 

The hooks are just executable files and it may be possible to run compiled binaries as well as shell scripts. Here is my working go fmt pre-commit hook. I edited the example script in .git/hooks/pre-commit.sample to run go fmt and renamed it to pre-commit.

 

#!/bin/sh
#
# A  hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
# This hook runs 'go fmt ./...' on the project
# To enable this hook, rename this file to "pre-commit".

if git rev-parse --verify HEAD >/dev/null 2>&1
then
        against=HEAD
else
        # Initial commit: diff against an empty tree object
        against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# If you want to allow non-ASCII filenames set this variable to true.
allownonascii=$(git config --bool hooks.allownonascii)

# Redirect output to stderr.
exec 1>&2

echo "Running go fmt"
go fmt -x ./...

 

 

Here are some further references.

An Example Git-Enforced Policy

https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy#_an_example_git_enforced_policy

Pre-Commit    NPM based git-hook installer https://github.com/observing/pre-commit

Githooks 

https://githooks.com

Cryptocurrency mining could be the next wave in internet monetization.

While the 2017 crypto bubble has turned into a drawn out 2018 slide, a new specter has entered the web monetization scene, in-browser cryptocurrency mining. Hackers have started using unprotected websites to hijack users computing power. They do this by adding in-browser cryptocurrency mining code to the websites javascript files. The hacked websites visitors’ are then used to mine cryptocurrency for the hackers. While today these in-browser miners are dangerous malware, I think this could be the start of a shift in internet monetization.

Internet advertising and affiliate marketing have been the major players in the monetization of web content, creating behemoths like Facebook and Google. Most websites’ first step is to sign up for AdSense and run banner ads. In their quest to maximize ad revenue Google and Facebook have launched immense tracking operations, in which they record every page view people make. Using this data, profiles are created about web users and their attention is auctioned off in the form of targeted ad views.

In-browser Cryptocurrency mining provides an alternative to the targeted ad economy. Web admins simply integrate their site with a javascript file that automatically mines cryptocurrency inside the browser. This mining process creates ‘hashes’ which can be added to a mining pool and redeemed for tokens. Essentially, the visitor lends their cpu power to the website owner and contributes hashes worth a few pennies in the process of reading a blog post. Depending on how the software is integrated you could be required to contribute a certain number of hashes before being allowed to view a webpage or download a video. Websites can monitor how many hashes a user has contributed and block their requests if they fail to contribute.

Previously, Brandon Eich’s company Brave has created an ‘attention token’ which is a centrally controlled coin integrated into their browser that pays websites on a per-pageview basis. The downside of this payment method is that it relies on subscriptions and ads as its money source. You can earn attention tokens by watching ads after all! In-browser mining of cpu-optimized cryptocurrencies is a truly decentralized way for users to pay to view content. Its been hard to get internet users to care enough to pay 1-10 cents per page view even if they would be willing to pay there isn’t a payment system that could benefit off of such small transactions. That is why ads have done so well, its much easier to put up with ads than to buy a subscription and no one really cares enough about a penny to pull our their credit card.

In-browser mining solves the ‘too small to care’ problem by providing a way for users to pay web owners tiny amounts of money without needing to pull out their credit cards. Processing tiny credit card transactions would be prohibitively expensive, but lending website owners the cpu power that users already own is much easier.

Monero is the cryptocurrency of choice for in-browser mining today because it is optimized for cpu mining. Its governing structure includes regular hard forks and it has been announced that Monero will hard fork its mining algorithm whenever ASICS that can mine it are released. Monroe and other new more flexible cryptocurrencies can ensure that in-browser mining remains worthwhile compared to datacenter mining with ASIC or GPU hardware.

The reason I am excited about in-browser mining is because it counter-acts miner centralization, one of the major risks for cryptocurrencies. Bitcoin mining is dominated by massive data centers in China which use subsidized electricity. In-browser mining is a way to involve every website in cryptocurrencies while providing a tracking free web experience and making it easy for internet users to contribute value back to content providers.

Sprintly 1 on 1s

I have been doing on one one meetings with my team for the last couple months. Or more realistically 2 on 1 meetings since the Project Managers at my employer tend to be involved in everything. Despite being only 15 minutes long, it takes 2 hours to do all eight of them. Typically, we will ask, “How are you doing? Is there anything you thought was good or bad in the sprint? Is there anything you need to do your job?” The meeting ends up being a light chat where we can talk about issues in the project. Things that haven’t been fixed yet. Or ideas that the team member had, but didn’t want to bring up in standups. Often all people can think of is an outstanding issue that we haven’t been able to get management to solve, and we just promise to follow up on it. I find that the 1 on 1 meeting works best for the more subdued and introverted team members who don’t like to speak up as much. They have good ideas on the project, they just will not bring them up publicly.

Some people recommend doing weekly 1 on 1s, we ended up doing biweekly meeting since we are doing two week sprints anyway. I think that I am accessible enough to the team, but since some of our people are in another office it might be worthwhile to meet with them weekly.

Try doing regular 1 on 1 meetings with your team. I find its really helpful with less outspoken people!