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!

Getting into Software Part 5: How to get your first job

I started focusing on Programming for my career after my sophomore year of college. My attempts to get a physics internship had failed and I was at loose ends for the summer. That summer I spent a good amount of time working through a Ruby on Rails (RoR) tutorial that walked me through building a twitter clone web app. This was early in my time as a programmer so I was just following the tutorial and experimenting with changing the html/css, writing views and models etc. My application didn’t branch very far from the tutorial I was following, but it did look clean and allow people to post ‘tweets’. While it wasn’t particularly impressive it proved useful in the fall when I interviewed for a contract web developer position. I was a bit unqualified for this job, which was to write a companion web application to a mobile app being developed by another student at my college. I managed to write a basic prototype using PHP, MySQL and some javascript charting. But I wasn’t able to write the application with my skills at the time. I ended up quitting that job because I was struggling in my Physics studies. Still I had more experience coding and was several thousand dollars richer.

You might think that it was easy swimming from there, but it wasn’t. My real challenge was getting a formal internship after my Junior year in college. I applied to dozens of companies and ended up doing over ten interviews, went to the career fair at my school and had a difficult time finding any summer internships that wanted me. I interviewed at a bank and a small financial firm focused around trading electricity. I have to assume I looked pretty dorky in my suit, and the software engineers that interviewed me were of course wearing shorts and t-shirts. The finance firm I interviewed didn’t even have me interview with a programmer, their programmer was on vacation that day. I ended up interviewing with their manager and then the CEO, who was 45min late for the interview. That was one of the few interviews where I was asked for references and then didn’t get an offer.

### Interviewing strategies / Tactics

Programming interviews are hyped up as being very difficult and involving complex algorithms. I have found that the hype is not accurate. Maybe in Silicon Valley itself they really do ask complex graph solving questions, but in my experience depth-first and breadth-first search were as deep as the graph questions have gotten. One of the harder questions I have encountered was in a phone screen for Google were I was asked a question along the lines of “find the set of three numbers in this list that sum to less than x”. It stumped me at the time but nowadays I know that the solution involves building up a map that caches the sum of two of the three numbers in the set.

Now lets say you have done 20 practice problems on leetcode and still feel like you can’t possible by reading to solve all the problems they throw at you in an interview, well lucky for you its not really about solving the problems. What you want to do is demonstrate that you have a good amount of knowledge on algorithmic problems and that you are good at talking your way through problems. In your day to day you won’t be solving these types of problems by yourself, you will be working with a team and discussing possible solutions. Many of the problems won’t even be algorithmic in nature they might be around business logic or maintainability. The team wants to know if you will be able to contribute to the discussion around problems that arise and that are good enough at talking about problems that you can ask for help when you need it.

Go into your interview and do your best. Afterwards take notes of all the questions they asked that you did not know the answer to. Do some research and find the answers to the problems that stumped you. Interviewers tend to use the same questions so after a few interviews you will recognize almost all the questions you get.

Understand that its a numbers game. Unless you are a top candidate you will need to do more than 10 in-person interviews to get a job. If you interview with 5 people and one of them didn’t eat breakfast, you might not get the job. I have been in interviews where I really liked the candidate and thought he would be a huge win for the project, but the other guys on the team hated him. You will do interviews where you just have a great time, everyone likes you and you have an offer by the end of the week.

### Conclusion
This post dragged out a lot and its still not quite where I want it to be. I will come back to this series later when I am better able to articulate the ideas I wanted to express here. I hope it can help someone get into software programming.

Getting into Software Part 4: How to prepare for your first job or internship?

The best way to prepare for interviews is to build websites in a similar way to what you would do in the working world.

### Programming skills Basics ###

1. Create a website by following a Node.js, Ruby on Rails, or Django tutorial depending on which Language you are learning JavaScript, Ruby or Python. There are a ton of tutorials any twitter clone tutorial works great.

2. Study Data structures and algorithms
3. Study Object oriented design at a basic level.
1. inheritance
2. polymorphism
3. interfaces

4. Play around with Git or Mercurial — we use version control tools every day at work.
5. Create a real time chat website where users can see each others messages without refreshing the webpage.

### Resume ###
Keep it short 1-2 pages

Place your education, skills and work experience in an easy to find place on the first page.
Not all of your experience is relevant, minimize the less interesting experiences and bring to the front the important experience on your resume.

If you have room for clubs and side activities on the first page you probably are not going into enough depth on your experience.

### Interview Preparation and Advice ###

The employer’s goal in programming interviews is focused around estimating how well you can talk about software concepts, see if you have anything obviously wrong about you that you can’t hide in an interview, and see how you can solve problems under pressure.

Your goal in these interviews is to demonstrate that you are a smart, driven and prosocial person who has the technical ability to contribute to the team. Secondarily, you want to gauge how much you like the team, what kind of person your potential manager is, and get a feel for what hours the team considers normal.

At this point most of the programming problems used in interviews are common knowledge. You can expect questions about data structures, sorting algorithms, graph algorithms and object oriented programming. Fizz buzz and Fibonacci and palindrome questions are also pretty common, I have even gotten a question about designing a file system. There are 10s of websites devoted to ‘interview problems’, including https://leetcode.com, and https://www.hackerrank.com. You will want to do some of these problems before you start doing technical phone screens. I recommend doing 10-20 problems. Doing more than 20 is unnecessary because the problems are not that different from each other, just make sure you try a combination of easy, hard and intermediate problems.

You want to appear clean, shave if you grow facial hairs, get your hair in relatively tidy and dress appropriately. For programming jobs its hard to go wrong with a blue button down shirt and dark colored trousers. Wearing a suit is pointless most of your interviewers will be wearing t-shirts, shorts and sandals.

Do what it takes to arrive 5-10min early. Find the office and use any convenient bathrooms you come across. Be polite to everyone in the building you never know who works for the company or if the receptionist is also the HR manager.

We will go over in interview strategies in the next section of this series.

Getting into Software Part 3: How can you tell if you have the right talents for a Software Programming Career?

If you have never programmed before, how can you tell if you have the talent needed at the professional level?

Even if you did badly in school there is a chance that as an adult you could be successful as a software engineer. The demand for software engineers is high enough that people without degrees in Software Engineering or Computer Science can get into the field. The real question is whether you can solve programming problems and demonstrate it to prospective employers.

The way I got started in programming was an online C class, and C is not a bad place to start. Although, today I recommend “learning Python the hard way” which is available at https://learnpythonthehardway.org/book/intro.html. The book can be accessed for free online but is also available in other formats that you can pay for.

Once you have gotten introduced to the language and can write simple programs with the book guiding you, take a look at Project Euler.

Go to https://projecteuler.net/archives and do 10 of the problems in python. If you can knock out a few problems in a day or two without any programming experience other than the course you are probably capable of professional software engineering. If it takes you a week to get your first problem and only a day per problem after that it might still be worthwhile for you to push forward with Software Engineering.

The Project Euler problems vary in difficulty from easy to rather complicated. Don’t think that you need to be able to do the hardest ones to get a job working as a Software Engineer. But you will find yourself dealing with similar problems on a daily basis so you need to consider if you can handle that being a significant of your daily life and the skill that you get paid for.

Getting into Software Part 2: What Skills are Important in Software Programming?

The way I see it there are 3 core skills that are important in corporate software engineering environments, understanding logical trees, finding solutions to obscure problems on the internet, and making sure you write the right solution to the problem.
These can be split into:
* Logic
* Reading Comprehension + Persistence
* Communication
**Understanding and Writing logical trees**
Understanding and writing logical trees is the primary filter in programing jobs. If you cannot comprehend and create complicated logical trees you will not be able to do the job. It is less difficult than logical proofs in an introductory discrete math class in university. The difficulty is that logical constructs are what we work with and there are very many of them.
The most popular logic problem used in software engineering interviews is called FizzBuzz. This is a pretty simple problem that is comparable in complexity to problems you will encounter as a software professional.
***FizzBuzz***
*Write a program that prints the numbers 1 to 100.
For each multiple of 3 print Fizz instead of the number and for each multiple of 5 print Buzz instead of the number. If a number is a multiple of both 3 and 5 print FizzBuzz.*
While the problem is pretty simple if you cannot work your way through it in half an hour interviewers will confidently assume that you are not capable of doing the job.
**Finding solutions to obscure problems on the internet.**
The second big skill is, “finding solutions to obscure problems”, luckily for the modern day programmer 95% of all problems have a solution on the internet. Whether that problem is accessible via google or hidden on github and stackoverflow.com is something you will have to figure out.
Sometimes finding that solution may take hours of trawling the internet and reading through the source code of dozens of dependencies. A software engineer needs to be able to persist through the search despite there being no apparent progress and the high probability that the actual issue is a small oversight that you thought was irrelevant and then forgot about.
These problems tend to be either compiler errors or figuring out how to get a library to do what you want.
**Making sure you write the right solution to the problem.**
The last big skill is making sure you write the right solution to the problem. Typically, software is used to automate internal business processes or to sell products to customers. The people who currently perform these processes manually or sell to customers are not software experts. They are business process or sales experts. Its our job as the Software Engineers to interpret the requirements of the business and turn them into explicit logical steps that fulfill the business need. This is a difficult problem and people who can do it well are rewarded.
One of the big problems in corporate software development is that the people who can deal with logical trees and have the persistence to struggle with a compiler all day are not abundant in the skills required to understand what the business wants or needs. And since extracting the business requirements in sufficient detail can be an arduous process companies will often hire Project Managers and Product Owners to deal with it.
We have gone over the most important skills for a corporate software engineer, dealing with logical puzzles and trees, searching for obscure answers to problems and building the right solution to the business problem. Hopefully, this gives you an idea of what is needed to be a successful Software Engineer.

Getting into Software Part 1: Why would you want to get into Software Programming?

In an age where Software is gradually taking over everything starting from your computer and spreading to your fridge or your car it might seem late to get into software, but it is not. Companies are going to need more and more software developers and engineers to write the code needed to run everything. What are some good reasons to work in software?

Hours

An excellent reason to get into software is because of the hours. The expected hours vary greatly between software companies. You could work for a small boutique firm that is constantly pushing 80 hour weeks or for a megacorp where you work for 10 of the 40 hours you are in the office each week. It really depends on what you want and how good you are at interviewing. You might find that mid-sized companies are a good fit for you or that you prefer aggressively growing startups. The important things to consider are how many hours are you working and what are you trading in return for those hours. For example you might be working double the hours for double the salary, thats great if you are prioritizing money, but your hourly pay might be same as someone making half your salary.

Working Conditions

The working conditions in software engineering are usually good. We work indoors at desks and the heaviest thing you are likely to lift is a 3 lb macbook. In my workplace every desk is a standing desk and I try to take advantage of standing a little each day. Constantly leaning forward is the biggest issue I face with occasional hand issues taking second place.

Programming can be enjoyable

Some people enjoy programming, it can be a cerebral experience. There is little chance to it, just man against machine in a cathedral to the inner working of men’s minds.

Good compensation

Salaries in the Software engineering field may fall into a binomial distribution, but the lower end is still high compared to other fields that require a bachelor’s degree or less.

What are your top reasons to get into Software Engineering?