DEV Community: hmintoh

How to: Use multiple AWS accounts with the AWS-CLI

hmintoh — Thu, 31 Dec 2020 10:27:35 +0000

If you are working with multiple AWS accounts, you can easily switch between your accounts by creating multiple profiles on the CLI.

Get list of AWS profiles aws configure list-profiles. By default, there will be one default profile
To add a new profile, you will first need to generate an access_key_id and a secret_access_key.
Profiles are stored under the config and credentials files. You can configure additional profiles by adding entries to the files. In this case, we will add a new profile user1:

$ vim ~/.aws/config

[default]
region=us-west-2
output=json

[profile user1] // Include the prefix "profile" only when 
configuring a named profile in the config file
region=us-east-1
output=json

$ vim ~/.aws/credentials

[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[user1] // Do not use the prefix "profile" 
aws_access_key_id=YOUR_ACCESS_KEY
aws_secret_access_key=YOUR_SECRET_ACCESS_KEY

Verify that the profile is successfully added by aws configure list-profiles. You should now see 2 profiles:

 default
 user1

To switch between different AWS accounts, set the AWS_profile environment variable at the command line via export AWS_PROFILE=profile_name. Setting the env variable changes the default profile until the end of your shell session or until you set the variable to a different value.
Use aws configure list to list your current profile.

For documentation to named profiles, see guide here.

How to write strong Acceptance Criteria

hmintoh — Tue, 22 Dec 2020 09:39:36 +0000

What are Acceptance Criteria (AC)?

“Acceptance criteria are pre-established standards or requirements a product or project must meet.” -Google

Acceptance Criteria (AC) are unique to each user story and define the feature from the end user's perspective. They form a boundary between what is in scope and what is out of scope.

Best practices for writing ACs

Who, When, How?

AC should always be written from the end user's perspective. It is generally written by the product owner/manager or business analyst before actual development starts. This way, the team will be able to capture all the stakeholder needs in advance.

Shared understanding and consensus

AC synchronise the visions of the client/stakeholder and the product team. They help to ensure a common understanding of the requirements i.e. developers know what behaviour the feature must demonstrate, and the client knows what to expect from the feature. Everyone must review the AC and agree each line.

Clarity, always

AC must be clear, concise and easy to understand for everyone. They should entail all the functional and non-functional aspects of the feature and be written in simple and plain language. Avoid technical details.

AC should convey the intent and not the solution as the same problem can be solved differently by a different team. Avoid implementation details.

Make it testable, measurable and achievable

AC should make it possible to accurately plan and estimate each user story. AC should include clear success and fail scenarios and each criterion should be independently testable so testers can verify that all requirements are met.

The structure

The two most common formats are:

Scenario oriented (Given/When/Then):

Given some pre-condition, when I perform some action, then I expect some result e.g:

User story: As a user, I want to be able to recover the password to my account, so that I am able to access my account again

Scenario: Forgot password

Given the user has navigated to the Log in page,
When the user clicks on the 'Forgot password' button and enters his email address,
Then he should receive an email from the system to the email address he provided

Rule oriented:

In other cases, a feature's requirements may not fit nicely into the Given/When/Then format. The rule-oriented form entails that there is a set of rules that describe the behaviour of the feature e.g:

User story: As a user, I want to use a search field to enter my postal code, so that I can find the nearest community centre

Acceptance Criteria

The placeholder disappears once the user starts typing
Search starts when the users hits "Enter/Return" on the keyboard or clicks on the "Search" button
The search input only accepts numerical digits
The search input can't take more than 8 digits
etc.

Most requirements can be captured in the formats above, however, it is always possible to write AC in custom formats.

To recap

Acceptance Criteria (AC) are conditions in which a product must meet in order to be accepted by a user/system. AC define scope, defend against scope creep, clarify requirements and prevents ambiguity. It also helps the QE to verify if development goals were met.

What are some other best practices you/your team follow in writing AC? Curious to hear your thoughts/comments below ⚡

References

How to Craft Strong Acceptance Criteria for a User Story

Acceptance Criteria: Purposes, Formats, and Best Practices

React obfuscate: Hiding source code from developer tools

hmintoh — Mon, 28 Sep 2020 09:02:00 +0000

When you run yarn build in a create-react-app application, React minifies the code during the build and generates source maps. JS code thus becomes obfuscated as a byproduct of minification.

If you take a look inside build/static/js, you will see that with each .js file, there is an accompanying .js.map file. The JS files are loaded with your website, and the .map sourcemap files are loaded on demand, when developer tools are opened, so that you are able to navigate around the original code.

To disable sourcemap generation, run your build with GENERATE_SOURCEMAP=false. This will ensure that .map files will not end up in the bundled build.

"scripts": {
    "build": "GENERATE_SOURCEMAP=false react-scripts build"
}

How to: Increase performance with React.memo

hmintoh — Thu, 17 Sep 2020 10:51:35 +0000

In React, changes to a component's state triggers a re-render of the entire component tree. This means that not only does the render function of the component get called, all its subsequent child-components will re-render as well, even when their props have not changed.

When your application is large, unnecessary re-rendering is expensive and reduces performance. To avoid this, we can look at to a concept called Memoization.

Memoization

Wikipedia defines Memoization to be:

... an optimisation technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

This means that it is a technique that executes a pure function once, stores the results, and if the function is called again with the same arguments, it returns the previously saved results without executing the function again (because we assume the outcome is the same).

In other words, it is a away to lower the function's time cost in exchange for space cost; that is, memoized functions become optimised for speed in exchange for a higher use of computer memory space.

React.memo in action

In the context of React, the functions are our React (pure) components, and the arguments are our props. React.memo is a HOC built of the concept of memoization and tells the component to only re-render when its props change.

Let's create a component that has an input field and a button to add a new user:

const App = () => {
  const [value, setValue] = useState("");
  const [names, setNames] = useState(["Avery", "Bain"]);

  const handleInput = (e) => {
    setValue(e.target.value)
  }

  const handleAddUser = () => {
    const updatedArray = names.push(value);
    setNames(updatedArray);
  }

  console.log('render App');
  return (
    <div>
        <input value={value} onChange={handleInput} />
        <button onClick={handleAddUser}>
          Add User
        </button>
        <List list={names} />
    </div>
  )
};

const List = ({list}) => {
  console.log('render List');
  return (
    <ul>
      {list.map((name, key) => <li>{name}</li>)};
    </ul>
  )
};

export default App;

In here, the component gets re-rendered every time someone types into the input field (before adding a user), because value changes. The problem is, List also gets re-rendered, even when its props remains the same.

// when user types one char into input
render App
render List

With React.memo, we can optimise rendering behaviour by telling List to only re-render when its props changes:

import { memo } from 'React';

const List = memo(({list}) => {
    console.log('render List');
    return (
        <ul>
          {list.map((name, key) => <li>{name}</li>)};
        </ul>
    )
});

Now, when we type into the input field, only App is re-rendered because it is the only component affected by the state change.

// when user types one char into input
render App

// when a new user is added
render App
render List

To recap

By default, React re-renders components when its state changes. This means that a child component will also render as a result of a state change in its parent component, even when its props remain the same.

React's memo API optimises rendering behaviour by re-rendering components only when their props change. Thoughts? Let me know in the comments below! 👇

References

https://www.robinwieruch.de/react-memo

Setting child container fill parent container's width and height

hmintoh — Wed, 29 Jul 2020 06:47:42 +0000

Suppose you want have a template with a navbar, body and footer sections. Our goal is to have the body container take up the entire space between navbar and footer.



<div id="root">
  <div class="wrapper">
    <nav>navbar</nav>
    <main>body</main>
    <footer>footer</footer>
  </div>
</div>

We start by specifying width: 100% and height: 100% in #root. For demonstration purposes I've some background colors for navbar, body and footer.



#root {
  width: 100%;
  height: 100%;
}

nav {
  background: pink;
}

footer {
  background: green;
}

main {
  background: yellow;
}

.wrapper {
  background: lightblue;
}

We want .wrapper to span the entire viewport, so we set width: 100vw and height: 100vh.



.wrapper {
  background: lightblue;
  width: 100vw;
  height: 100vh;
}

To get the body container to take up the remaining space in blue, we use flexbox.



.wrapper {
  background: lightblue;
  width: 100vw;
  height: 100vh;
  display: flex;
  flex-direction: column;
}

We start by setting display: flex to .wrapper:

We then set flex-direction: column to set the direction of the flexible items:

Next, we specify how much of the remaining space in .wrapper should be assigned to the body container. We do this with flex: 1:



main {
  background: yellow;
  flex: 1;
}

Because we didn't specify a flex on navbar and footer, body takes up the entire space in its parent container .main.

However, if we specify a flex property in navbar and body, they will take up 1 part and 2 parts of the remaining parent container respectively:



nav {
  background: pink;
  flex: 1;
}

main {
  background: yellow;
  flex: 2;
}

And there you have it! ⚡



#root {
  width: 100%;
  height: 100%;
}

nav {
  background: pink;
  flex: 1;
}

footer {
  background: green;
}

main {
  background: yellow;
}

.wrapper {
  background: lightblue;
  width: 100vw;
  height: 100vh;
  display: flex;
  flex-direction: column;
}

Component lifecycles with React hooks

hmintoh — Mon, 20 Jul 2020 14:06:59 +0000

Before the release of Hooks, React components were divided into 2 broad categories:

Functional components → Stateless components; unable to access lifecycle methods
Class components → Stateful components; able to define states and access lifecycle methods

This meant that the only way to access lifecycle methods was to write the component as a Class. With the introduction of React hooks, it is now possible to create stateful components without the use of a Class.

First, a quick recap of React lifecycles:

Mounting

This is the first lifecycle of a React component, the stage where it is created and inserted into the DOM. In class components, we have the componentDidMount method, which allows us to use setState to modify our states after the first render.

componentDidMount() {
  console.log("The component has mounted successfully!");
  this.setState({isLoading: false});
}

Updating

This lifecycle happens after a component is mounted and rendered into the DOM. The component is updated when we have an update in our props or state. The componentDidUpdate method is invoked after the update happens in the component and is used to compare whether a specified prop or state has changed.

componentDidUpdate(prevProps) {
  if (this.props.name !== prevProps.name) {
    console.log("Name has changed!");
  }
}

Unmounting

This lifecycle is responsible to do the cleanup in our DOM i.e. when we want to remove the component. The componentWillUnmount method is invoked when the component is about to be removed from the DOM:

componentWillUnmount() {
  console.log("Component will be unmounted!");
}

useEffect vs. Lifecycle methods

In class components we have lifecycle methods to perform actions in a specific lifecycle stage of a component. For functional components, we can use the useEffect hook to achieve the same outcomes. The hook has the following signature:

import { useEffect } from 'react';

useEffect(() => {
  // inside this callback function we perform our side effects
});

It receives a callback function as the first argument, which, just like lifecycle methods, will be called after every render.

The second argument (optional) is an array of dependencies that the hook is going to watch i.e. the hook will only run if one of those dependencies change.

This means that when you pass an empty array to the useEffect hook, it will only run once after render.

Mounting - Just by using the useEffect hook, we are performing the equivalent of the componentDidMount method:

useEffect(() => {
  console.log("The component has mounted successfully!");
  setisLoading(false);
}, []);

Updating - By passing an array of dependencies that we want to watch, the hook will update when any of the dependencies change. For example, if you have a prop name count that is passed into the useEffect hook, the hook will only run when count changes.

useEffect(() => {
  console.log("You have clicked ${count} times")
}, [count]);

Unmounting - We return a function within the callback function of the hook, which will achieve the same outcome as a componentWillUnmount method.

useEffect(() => {
  console.log("You have clicked ${count} times")
  return () => console.log("Component will be unmounted!");
}, [count]);

To recap:

Up until React 16.8, functional components were stateless and could not access lifecycle methods. With the introduction of hooks, we are now able to add state and perform side effects to our functional components.
The useEffect hook is a function that allows us to perform side effects in our functional components. It receives a callback function as its first argument → we define our effects here.
The second argument (optional) is an array of dependencies that the hook is going to watch. If you pass an empty array, the hook will not be watching any dependencies and therefore will only run once after the initial render.
If you don't pass a second argument into the hook, the effect will run after every render 🤪

Thoughts? Feedback? Let me know in the comments below 👇🏻

How to: Automate file creation with node's fs module

hmintoh — Wed, 17 Jun 2020 16:23:57 +0000

TL;DR

Do you ever find yourself creating the same files over and over again and wish for a script to do the boring work for you without having to use a third-party library?

The story

I've been creating a lot of React components lately and wanted to find a way to automate file creation. Specifically, a script that could create a ComponentName folder containing the following files:

index.tsx
styles.tsx

After doing some research, I found that node's fs module is able to meet my needs. Specifically,

fs.mkdirSync(path) synchronously creates a directory given a path (+ other options)
fs.writeFileSync(filepath, content) synchronously creates files in the given filepath and optionally fills them with content

Step 1: Defining the file templates

// src/scaffold.js
const templates = {
  index: `// Comment to begin our index file`,
  styles: `// Comment to begin our styles file`,
};

Step 2: Write functions to create the component folder and files

// src/scaffold.js
const fs = require("fs");
const args = process.argv.slice(2);

function createFolder(component) {
  const directory = `./src/components/${component}`;

  if (!fs.existsSync(directory)) {
    fs.mkdirSync(directory);
  }
}

function writeFile(component, type) {
  const filepath =`./src/components/${component}/${filename}.tsx`;

  fs.writeFile(filepath, templates[type], (err) => {
    if (err) throw err;
    console.log("Created file: ", filepath);
    return true;
  });
}

function generate(component) {
  createFolder(component);

  const fileTypes = ["index", "styles"];

  for (let type of fileTypes) {
    writeFile(component, type)
  }
}

generate(args[0]);

createFolder(component) creates a folder named component if it does not exist in the specified path
writeFile(component, type) creates files in the specified folder and fills them with content specified in templates[type]

Step 3: Adding the script

Finally, add the following script to package.json

 "scripts": {
   "component": "node scaffold.js"
 },

That's it! The magic command that is yarn component <ComponentName>.

Let me know your thoughts in the comments below 👇

How to: Mapbox with Vue.js

hmintoh — Mon, 15 Jun 2020 09:35:33 +0000

Getting started

Generate a MapBox access token in your account page
Download the npm library using yarn add mapbox-gl
Include the css in the <head> of your index.html file: ```javascript


## Creating a map

Create a `BaseMap` component:
```vue


<template>
  <div id="mapContainer" class="basemap"></div>
</template>

<script>
import mapboxgl from "mapbox-gl";

export default {
  name: "BaseMap",
  data() {
    return {
      accessToken: MAPBOX_ACCESS_TOKEN,
    };
  },
  mounted() {
    mapboxgl.accessToken = this.accessToken;

    new mapboxgl.Map({
      container: "mapContainer",
      style: "mapbox://styles/mapbox/streets-v11",
      center: [103.811279, 1.345399],
      zoom: 12,
      maxBounds: [
        [103.6, 1.1704753],
        [104.1, 1.4754753],
      ],
    });
  },
};
</script>

container: The HTML element in which Mapbox GL JS will render the map, or the element's string id. The specified element must have no children.
style: choose from a pre-defined Mapbox style or create your own using Mapbox studio
center: refers to the starting position in [long,lat]
zoom: refers to the initial zoom level

Other option parameters for Map can be found here.

Finally, add basic styles:



<style lang="scss" scoped>

.basemap {

  width: 100%;

  height: 100%;

}

</style>

Displaying markers and controls

Navigation

This adds a zoom buttons and a compass.



const nav = new mapboxgl.NavigationControl();

map.addControl(nav, "top-right");

Marker

This adds a marker component.



const marker = new mapboxgl.Marker()

  .setLngLat([103.811279, 1.345399])

  .addTo(map);

Geolocate

This locates the user on the map based on the browser's geolocation API.



const geolocate = new mapboxgl.GeolocateControl({

  positionOptions: {

    enableHighAccuracy: true

  },

  trackUserLocation: true

});

map.addControl(geolocate, "top-right")

And there you have it! 🎉

If you are interested in using Mapbox with React.js, I have written a similar tutorial here
Mapbox official documentation here ⚡

How to: Mapbox with React.js

hmintoh — Mon, 08 Jun 2020 13:53:49 +0000