Search This Blog

March 30, 2020

The 3 Frontend Code Quality Musketeers - ESLint, Husky And Lint-Staged


Protect your Javascript code quality with the 3 musketeers - ESLint, Husky and Lint-Staged. I often come across projects in my consulting gigs where the team overlooks the importance of Automated Code Quality for the front-end because they feel they have one less thing to worry about. With the three said musketeers configured to act in your project, you will start to experience productivity and peace because you get to fail faster should you compromise on code quality.

Understanding the roles of the 3 musketeers:
  1. ESLint : To find and fix problems in your JavaScript code no matter what ECMAScript standards your team has adopted to follow starting from ECMA 3 to ECMA2019. And if you were to use language extensions like JSX, Flow or Typescript, ESLint get your code covered. Lastly, if you are using Babel, which you likely are, you can use the babel-eslint parser and eslint-plugin-babel to use any option available in Babel. This is the Javascript community's best friend when it comes to automated code quality. Go for it!
  2. Husky : Husky makes Git hooks simpler to aid its adoption and thus prevent bad code from being pushed to central repository. Instead of expecting your developer to run your ESLint before they commit their changes, you are better off with this being done automatically at the earliest. The earliest that could be here is when the developer commits his code changes to his local branch. You could write a pre-commit Git-hook that gets executed before the commit and successfully commits the changes only if there are no linting errors. This is where Husky comes to the rescue. By installing it as part of your project dependency, you simply configure the Git-hook like below in your package.json file:
  3. Lint-Staged : As developer you have this crazy attitude to further your productivity. You wouldn't want to waste your precious time running through the linting process for your entire project repository for every commit of yours when you have only changed a few files at best for the intended commit. You feel better off executing the lint over the modified files that you are about to commit than the entire project as is automated. Lint-Staged comes to aid you and the automation here. With this module, only files of configured pattern that are modified by you are tested against by the linter instead of the entire project source code. 
Below is a sample package.json file configuration where you see how the 3 musketeers are put together for your enhanced productivity:
Bingo!, with just that, you now have much more time to waste elsewhere like on Facebook, Hacker News, Reddit, Quora, Yahoo News and others..without compromising on the code quality.

March 1, 2020

Understanding Authoritative And Non-Authoritative DNS By Example

Doing nslookup for a domain against DNS server

I have my domain codonomics.com registered with bigrock.in.

Now when I do a nslookup for my registered domain against BigRock's DNS server, what I get would be an authoritative answer, because this server holds the original source files (the A, AAA and other records) of my domain. 

If I were to do a nslookup for my registered domain against any other name-server, that would act as an intermediary to get the details from the its sources. And when this happens, it communicates in its response as non-authoritative answer in nslookup.

Check this out in action in your terminal like shown in the blog banner image for this domain. And do play with other domain names as well if you know their source DNS servers.

Understanding this is perhaps the first step to doing more on the networking side of architecting your infrastructure. For instance, understanding How to Set Up DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Amazon Route 53, mandates your basic understanding of this concept of authoritative and non-authoritative DNS.