The FCC has clarified that nothing in its rules prohibits remote amateur radio testing, and no prior approval is needed to conduct remote exam sessions.

“The Commission provides flexibility to volunteer examiners and coordinators who wish to develop remote testing methods or to increase remote testing programs already in place,” the FCC said in an April 30 news release. “We recognize that some v...

While courts have an important role in ensuring that the rights of citizens are protected, it is essential that they avoid adjudicating on policy matters.

The organisers said Brazilian Ronaldo Souza, who was to fight Uriah Hall on the undercard, will not take part in the event.

NBA Commissioner Adam Silver explained the plan in a conference call open to all NBA players.

These are the most important oncology stories you need to know about today.
Medscape Medical News

When combined with data on prescriptions filled at local pharmacies, EMS drug overdose calls, and drug seizures by law enforcement, wastewater testing can yield insights into the extent of black-market activity, policing impact on community drug use, and where and when drug overdoses might occur.

Dewey Library - SH383.2.B45 2019

Tamil Nadu is ordering 10 lakh more RT-PCR (reverse transcription-polymerase chain reaction) testing kits to ramp up testing across the State.Accordin

The Madras High Court on Friday granted time till Monday for the State government to file a comprehensive report on steps taken to conduct mass testin

Amy Kapernick sings us through numerous ways of improving the robustness and reliability of our front end code with a comprehensive rundown of ideas, tools, and resources. The girls and boys won’t get any toys until all the tests are passing.

Anyone who’s spoken to me at some point in November may get the impression that I’m a bit of a grinch. But don’t get me wrong, I love Christmas, I love decorating my tree, singing carols, and doing Christmas cooking - in December. So for me to willingly be humming the 12 days of Christmas in October, it’s probably for something that I think is even more important than banning premature Christmas decorations, like front end testing.

On the 12th day of Christmas, my front end dev, she gave to me, 12 testing tools, 11 optimised images, 10 linting rules, 9 semantic headings, 8 types of colour blindness, 7(.0) contrast ratio, 6 front end tests, 5 browser types, 4 types of tests, 3 shaken trees, 2 image types, and a source controlled deployment pipeline.

Twelve Testing Tools

1. axe does automated accessibility testing. Run as part of your development build, it outputs warnings to your console to let you know what changes you need to make (referencing accessibility guides). You can also specify particular accessibility standard levels that you’d like to test against, eg. best-practice, wcag2a or wcag2aa, or you can pick and choose individual rules that you want to check for (full list of rules you can test with axe).

2. BackstopJS runs visual regression tests on your website. Run separately, or as part of your deployment/PR process, you can use it to make sure your code changes aren’t bleeding into other areas of the website. By default, BackstopJS will set you up with a bunch of configuration options by running backstop init in your project to help get you started.

3. Website Speed Test analyses the performance of your website specifically with respect to images, and the potential size savings if they were optimised.

4. Calibre runs several different types of tests by leveraging Lighthouse. You can run it over your live website through their web app or through the command line, it then monitors your website for performance and accessibility over time, providing metrics and notifications of any changes.

5. Cypress is for end-to-end testing of your website. When visual regression testing may be a bit much for you, Cypress can help you test and make sure elements are still on the page and visible (even if they’re not pixel for pixel where they were last time).
6. pa11y is for automated accessibility testing. Run as part of your build process or using their CLI or dashboard, it tests your website against various Web Content Accessibility Guidelines (WCAG) criteria (including visual tests like colour contrast). While axe is run as part of your dev build and gives you an output to the console, it can be combined with pa11y to automate any changes as part of your build process.
7. whocanuse was created by Corey Ginnivan, and it allows you to view colour combinations as those with colour blindness would (as well as testing other visual deficiencies, and situational vision events), and test the colour contrast ratio based on those colours.

8. Colour Blindness Emulation was created by Kyo Nagashima as an SVG filter to emulate the different types of colour blindness, or if you’re using Gatsby, you can use a plugin based off of gatsby-plugin-colorblind-filters.
9. Accessible Brand Colors tests all your branding colours against each other (this is great to show designers what combinations they can safely use).

10. Browser dev tools - Most of the modern browsers have been working hard on the features available in their dev tools:
    • Firefox: Accessibility Inspector, Contrast Ratio testing, Performance monitoring.
    • Chromium: (Chrome, Edge Beta, Brave, Vivaldi, Opera, etc) - Accessibility Inspector, Contrast Ratio testing, Performance Monitoring, Lighthouse Audits (testing performance, best practices, accessibility and more).
    • Edge: Accessibility Inspector, Performance monitoring.
    • Safari: Accessibility Inspector, Performance monitoring.

11. Linc is a continuous delivery platform that makes testing the front end easier by automatically deploying a version of your website for every commit on every branch. One of the biggest hurdles when testing the front end is needing a live version of the site to view and test against. Linc makes sure you always have one.
12. ESLint and Stylelint check your code for programmatic and stylistic errors, as well as helping keep formatting standard on projects with multiple developers. Adding a linter to your project not only helps you write better code, it can reduce simple errors that might be found during testing time. If you’re not writing JavaScript, there are plenty of alternatives for whatever language you’re writing in.

If you’re trying to run eslint in VS Code, make sure you don’t have the Beautify extension installed, as that will break things.

Eleven Optimised Images

When it comes to performance, images are where we take the biggest hit, with images accounting for over 50% of total transfer size for websites. Many websites are serving excessively large images “just in case”, but there’s actually a native HTML element that allows us to serve different image sizes based on the screen size or serve better image formats when the browser supports it (or both).

<!-- Serving different images based on the width of the screen -->
<picture>
    <source
        srcset="/img/banner_desktop.jpg"
        media="(min-width: 1200px)"
    />
    <source
        srcset="/img/banner_tablet.jpg"
        media="(min-width: 700px)"
    />
    <source
        srcset="/img/banner_mobile.jpg"
        media="(min-width: 300px)"
    />
    <img src="/img/banner_fallback.jpg">
</picture>

<!-- Serving different image formats based on browser compatibility -->
<picture>
    <source
        srcset="/banner.webp"
        type="image/webp"
    />
    <img src="/img/banner_fallback.jpg">
</picture>

Ten Linting Rules

A year ago, I didn’t use linting. It was mostly just me working on projects, and I can code properly right? But these days it’s one of the first things I add to a project as it saves me so much time (and has taught me a few things about JavaScript). Linting is a very personal choice, but there are plenty of customisations to make sure it’s doing what you want, and it’s available in a wide variety of languages (including linting for styling).

// .eslintrc
module.exports = {
    rules: {
        'no-var': 'error',
        'no-unused-vars': 1,
        'arrow-spacing': ['error', { before: true, after: true }],
        indent: ['error', 'tab'],
        'comma-dangle': ['error', 'always'],
        // standard plugin - options
        'standard/object-curly-even-spacing': ['error', 'either'],
        'standard/array-bracket-even-spacing': ['error', 'either'], },
}

// .stylelintrc
{
    "rules": {
        "color-no-invalid-hex": true,
        "indentation": [
            "tab",
            {
                "except": [
                    "value"
                ]
            }
        ],
        "max-empty-lines": 2,
    }
}

Nine Semantic Headings

No, I’m not saying you should use 9 levels of headings, but your webpage should have an appropriate number of semantic headings. When your users are accessing your webpage with a screen reader, they rely on landmarks like headings to tell them about the page. Similarly to how we would scan a page visually, screen readers give users a list of all headings on a page to allow them to scan through the sections and access the information faster.

When there aren’t any headings on a page (or headings are being used for their formatting rather than their semantic meaning), it makes it more difficult for anyone using a screen reader to understand and navigate the page. Make sure that you don’t skip heading levels on your page, and remember, you can always change the formatting on a p tag if you need to have something that looks like a heading but isn’t one.

<h1>Heading 1 - Page Title</h2>
<p>Traditionally you'll only see one h1 per page as it's the main page title</p>
<h2>Heading 2</h2>
<p>h2 helps to define other sections within the page. h2 must follow h1, but you can also have h2 following another h2.</p>
<h3>Heading 3</h3>
<p>h3 is a sub-section of h2 and follows similar rules to h2. You can have a h3 after h3, but you can't go from h1 to h3.</p>
<h4>Heading 4</h4>
<p>h4 is a sub-section of h3. You get the pattern?</p>

Eight Types of Colour Blindness

Testing colour contrast may not always be enough, as everyone perceives colour differently. Take the below colour combination (ignoring the fact that it doesn’t actually look nice). It has decent colour contrast and would meet the WCAG colour contrast requirements for AA standards – but what if one of your users was red-green colour blind? Would they be able to tell the difference?

Red-green colour blindness is the most common form of colour blindness, but there are 8 different types affecting different parts of the colour spectrum, all the way up to complete colour blindness.

Protanopia

Inability to see red end of the colour spectrum.

Protanomaly

Difficulty seeing some shades of red.

Deuteranopia

Inability to see the green portion of the colour spectrum.

Deuteranomaly

Difficulty seeing some shades of green.

Tritanopia

Inability to see blue end of the colour spectrum.

Tritanomaly

Difficulty seeing some shades of blue.

Achromatopsia

Inability to see all parts of the colour spectrum, only able to perceive black, white and shades of grey.

Achromatomaly

Difficulty seeing all parts of the colour spectrum.

Seven (.0) Contrast Ratio

Sufficient colour contrast is perhaps one of the best steps to take for accessibility, as it benefits everyone. Having adequate contrast doesn’t just make the experience better for those with vision impairments, but it also helps those with situational impairments. Have you ever been in the sun and tried to read something on your screen? Whether you can view something when there’s glare could be as easy as making sure there’s enough contrast between the text and its background colour.

The WCAG have defined a contrast ratio of at least 4.5:1 for normal text (18.5px) and 3:1 for large text (24px) to meet AA accessibility standards, but this should be an absolute minimum and isn’t always readable. All four below examples have sufficient contrast to pass AA standards, but you might be hard pressed to read them when there’s glare or you have a dodgy monitor (even more so considering most websites use below 18.5px for their base font size).

To meet the AAA standard you need to have a ratio of 7:1 for normal text and 4.5:1 for large text, which should be sufficient for those with 20/80 vision to read.

Six Front End Tests

1. Adding default axe-core testing to Gatsby:

   //gatsby-config.js
   {
       resolve: 'gatsby-plugin-react-axe',
       options: {},
   },

2. Running pa11y tests on homepage at various screen sizes:

   // tests/basic-a11y_home.js
   const pa11y = require('pa11y'),
       fs = require('file-system')
   
   runTest()
   
   async function runTest() {
       try {
           const results = await Promise.all([
               pa11y('http://localhost:8000', {
                   standard: 'WCAG2AA',
                   actions: [],
                   screenCapture: `${__dirname}/results/basic-a11y_home_mobile.png`,
                   viewport: {
                       width: 320,
                       height: 480,
                       deviceScaleFactor: 2,
                       isMobile: true,
                   },
               }),
               pa11y('http://localhost:8000', {
                   standard: 'WCAG2AA',
                   actions: [],
                   screenCapture: `${__dirname}/results/basic-a11y_home_desktop.png`,
                   viewport: {
                       width: 1280,
                       height: 1024,
                       deviceScaleFactor: 1,
                       isMobile: false,
                   },
               }),
           ])
   
           fs.writeFile('tests/results/basic-a11y_home.json', JSON.stringify(results), err => {
               console.log(err)
           })
       } catch (err) {
           console.error(err.message)
       }
   }

3. Running pa11y tests on a blog post template at various screen sizes:

   // tests/basic-a11y_post.js
   const pa11y = require('pa11y'),
       fs = require('file-system')
   
   runTest()
   
   async function runTest() {
       try {
           const results = await Promise.all([
               pa11y('http://localhost:8000/template', {
                   standard: 'WCAG2AA',
                   actions: [],
                   screenCapture: `${__dirname}/results/basic-a11y_post_mobile.png`,
                   viewport: {
                       width: 320,
                       height: 480,
                       deviceScaleFactor: 2,
                       isMobile: true,
                   },
               }),
               pa11y('http://localhost:8000/template', {
                   standard: 'WCAG2AA',
                   actions: [],
                   screenCapture: `${__dirname}/results/basic-a11y_post_desktop.png`,
                   viewport: {
                       width: 1280,
                       height: 1024,
                       deviceScaleFactor: 1,
                       isMobile: false,
                   },
               }),
           ])
   
           fs.writeFile('tests/results/basic-a11y_post.json', JSON.stringify(results), err => {
               console.log(err)
           })
       } catch (err) {
           console.error(err.message)
       }
   }

4. Running BackstopJS on a homepage and blog post template at various screen sizes:

   // backstop.json
   {
     "id": "backstop_default",
     "viewports": [
       {
         "label": "phone",
         "width": 320,
         "height": 480
       },
       {
         "label": "tablet",
         "width": 1024,
         "height": 768
       },
       {
         "label": "desktop",
         "width": 1280,
         "height": 1024
       }
     ],
     "onBeforeScript": "puppet/onBefore.js",
     "onReadyScript": "puppet/onReady.js",
     "scenarios": [
       {
         "label": "Blog Homepage",
         "url": "http://localhost:8000",
         "delay": 2000,
         "postInteractionWait": 0,
         "expect": 0,
         "misMatchThreshold": 1,
         "requireSameDimensions": true
       },
       {
         "label": "Blog Post",
         "url": "http://localhost:8000/template",
         "delay": 2000,
         "postInteractionWait": 0,
         "expect": 0,
         "misMatchThreshold": 1,
         "requireSameDimensions": true
       }
     ],
     "paths": {
       "bitmaps_reference": "backstop_data/bitmaps_reference",
       "bitmaps_test": "backstop_data/bitmaps_test",
       "engine_scripts": "backstop_data/engine_scripts",
       "html_report": "backstop_data/html_report",
       "ci_report": "backstop_data/ci_report"
     },
     "report": [
       "browser"
     ],
     "engine": "puppeteer",
     "engineOptions": {
       "args": [
         "--no-sandbox"
       ]
     },
     "asyncCaptureLimit": 5,
     "asyncCompareLimit": 50,
     "debug": false,
     "debugWindow": false
   }

5. Running Cypress tests on the homepage:

   // cypress/integration/basic-test_home.js
   describe('Blog Homepage', () => {
       beforeEach(() => {
           cy.visit('http://localhost:8000')
       })
       it('contains "Amy Goes to Perth" in the title', () => {
           cy.title().should('contain', 'Amy Goes to Perth')
       })
       it('contains posts in feed', () => {
           cy.get('.article-feed').find('article')
       })
       it('all posts contain title', () => {
           cy.get('.article-feed')
               .find('article')
               .get('h2')
       })
   })

6. Running Cypress tests on a blog post template at various screen sizes:

   // cypress/integration/basic-test_post.js
   
   describe('Blog Post Template', () => {
       beforeEach(() => {
           cy.visit('http://localhost:8000/template')
       })
       it('contains "Amy Goes to Perth" in the title', () => {
           cy.title().should('contain', 'Amy Goes to Perth')
       })
       it('has visible post title', () => {
           cy.get('h1').should('be.visible')
       })
       it('has share icons', () => {
           cy.get('.share-icons a').should('be.visible')
       })
       it('has working share icons', () => {
           cy.get('.share-icons a').click({ multiple: true })
       })
       it('has a visible author profile image', () => {
           cy.get('.author img').should('be.visible')
       })
   })
   
   describe('Mobile Blog Post Template', () => {
       beforeEach(() => {
           cy.viewport('samsung-s10')
           cy.visit('http://localhost:8000/template')
       })
       it('contains "Amy Goes to Perth" in the title', () => {
           cy.title().should('contain', 'Amy Goes to Perth')
       })
       it('has visible post title', () => {
           cy.get('h1').should('be.visible')
       })
       it('has share icons', () => {
           cy.get('.share-icons .share-link').should('be.visible')
       })
       it('has a visible author profile image', () => {
           cy.get('.author img').should('be.visible')
       })
   })

Five Browser Types

Browser testing may be the bane of our existence, but it’s gotten easier, especially when you know the secret:

Not every browser needs to look the same.

Now, this may differ depending on your circumstances, but your website doesn’t have to match pixel for pixel across all browsers. As long as it’s on-brand and is useable across all browsers (this is where a good solid HTML foundation is useful), it’s ok for your site to look a little different between browsers.

While the browsers you test in will differ depending on your user base, the main ones you want to be covering are:

• Chrome/Chromium
• Firefox
• Safari
• Internet Explorer
• Edge

Make sure you’re testing these browsers on both desktop and mobile/tablet as well, sometimes their level of support or rendering engine will differ between devices – for example, iOS Chrome uses the Safari rendering engine, so something that works on Android Chrome may not work on iOS Chrome.

Four Types of Test

When it comes to testing the front end, there are a few different areas that we can cover:

1. Accessibility Testing: doing accessibility testing properly usually involves getting an expert to run through your website, but there are several automated tests that you can run against various standard levels.
2. Performance Testing: performance testing does technically bleed into the back end as well, but there are plenty of things that can be done from a front end perspective. Making sure the images are optimised, our code is clean and minified, and even optimising fonts using features like the font-display property. No amount of optimising the server and back end will matter if it takes forever for the front end to appear in a browser.
3. Visual Regression Testing: we’ve all been in the position where changing one line of CSS somewhere has affected another section of the website. Visual regression testing helps prevent that. By using a tool that compares before and after screenshots against one another to flag up what’s changed, you can be sure that style changes won’t bleed into unintended areas of the site.
4. Browser/device testing: while we all want our users to be running the most recent version of Chrome or Firefox, they may still be using the inbuilt browser on their DVD player – so we need to test various browsers, platforms and devices to make sure that our website can be accessed on whatever device they use.

Three Shaken Trees

Including (and therefore requiring your users to download) things that you’re not using affects the performance of your application. Are you forcing them to download the entire lodash library when you’re only using 2 functions? While a couple of unused lines of code may not seem like a huge performance hit, it can greatly affect users with slower devices or internet connections, as well as cluttering up your code with unused functions and dependencies. This can be set up on your bundler – Webpack and Parcel both have guides for tree shaking, and Gatsby has a plugin to enable it.

Two Image Types

While there are several different types of images, most of the time they fall into one of two categories:

Informative

The image represents/conveys important information that isn’t conveyed by the content surrounding it.

Decorative

The image only adds visual decoration to a page.

From these two categories, we can then determine if we need to provide alternative text for an image. If an image is purely decorative, then we add alt="" to let screen readers know that it’s not important. But if an image is informative, then we need to be supplying a text alternative that describes the picture for anyone who’s using a screen reader or isn’t able to see the image (remember the days when a standard internet connection took a long time to load a page and you saw alt text before an image loaded).

<img src="./nice-picture.jpg" alt="" />
<img src="./important-graphic.png" alt="This is a picture of something important to help add meaning to the text around me" />

If you have a lot of images with missing alt text, look into services that can auto-generate alt text based on image recognition services.

One Source Controlled Deployment Pipeline

While front end tests are harder to automate, running them through a source control and deployment pipeline helps track changes and eliminates issues where “it works on my computer”. Whether you’re running tests as part of the PR process, or simply against every commit that comes through, running tests automatically as part of your process makes every developer’s life easier and helps keep code quality at a high standard.

We already knew that testing was important, and your project can’t be run unless all your unit and integration tests are written (and pass), but often we forget about testing the front end. There are so many different tests we need to be running on the front end, it’s hard to work out what your need to test for and where to start.

Hopefully this has given you a bit of insight to front end testing, and some Christmas cheer to take you into the holidays.

About the author

Amy wears many hats as a freelance developer, business owner and conference addict. She regularly shares her knowledge with her peers and the next generation of developers by mentoring, coaching, teaching and feeding into the tech community in many ways.

Amy can be found volunteering her time with Fenders, ACS, SheCodes (formerly Perth Web Girls) and MusesJS (formerly NodeGirls). She also works as an evangelist for YOW! Conferences, is a Twilio Champion and has been nominated for the WiTWA awards for the last 2 years.

In her spare time Amy shares her knowledge and experience on her blogs and speaking at conferences. She has previously given keynotes at multiple events as well as speaking at several international conferences in the US and Europe.

More articles by Amy

Chris Ferdinandi turns the heat down low and lets the sauce reduce while we take a look at how to add spice to our source with a sprinkling of Array.reduce(). Just a little ingenuity with the humblest of functions.

Of all the modern array methods, the one I had the hardest time wrapping my head around was Array.reduce().

On the surface, it seems like a simple, boring method that doesn’t do much. But below its humble exterior, Array.reduce() is actually a powerful, flexible addition to your developer toolkit.

Today, we’re going to look at some cool things you can do with Array.reduce().

How Array.reduce() works

Most of the modern array methods return a new array. The Array.reduce() method is a bit more flexible. It can return anything. Its purpose is to take an array and condense its content into a single value.

That value can be a number, a string, or even an object or new array. That’s the part that’s always tripped me up – I didn’t realize just how flexible it is!

The syntax

The Array.reduce() accepts two arguments: a callback method to run against each item in the array, and a starting value.

The callback also accepts two arguments: the accumulator, which is the current combined value, and the current item in the loop. Whatever you return is used as the accumulator for the next item in the loop. On the very first loop, that starting value is used instead.

var myNewArray = [].reduce(function (accumulator, current) {
  return accumulator;
}, starting);

Let’s look at some examples to make this all tangible.

1. Adding numbers together

Let’s say you had an array of numbers that you wanted to add together. Using Array.forEach(), you might do something like this:

var total = 0;

[1, 2, 3].forEach(function (num) {
  total += num;
});

This is the cliche example for using Array.reduce(). I find the word accumulator confusing, so in this example, I’m calling it sum, because that’s what it is.

var total = [1, 2, 3].reduce(function (sum, current) {
  return sum + current;
}, 0);

Here, we pass in 0 as our starting value.

In the callback, we add the current value to the sum, which has our starting value of 0 on the first loop, then 1 (the starting value of 0 plus the item value of 1), then 3 (the sum value of 1 plus the item value of 2), and so on.

Here’s a demo.

2. Combining multiple array methods into Array.map() and Array.filter() into a single step

Imagine you had an array of wizards at Hogwarts.

var wizards = [
  {
    name: 'Harry Potter',
    house: 'Gryfindor'
  },
  {
    name: 'Cedric Diggory',
    house: 'Hufflepuff'
  },
  {
    name: 'Tonks',
    house: 'Hufflepuff'
  },
  {
    name: 'Ronald Weasley',
    house: 'Gryfindor'
  },
  {
    name: 'Hermione Granger',
    house: 'Gryfindor'
  }
];

You want to create a new array that contains just the names of wizards who are in Hufflepuff. One way you could do that is by using the Array.filter() method to get back just wizards whose house property is Hufflepuff. Then, you’d use the Array.map() method to create a new array containing just the name property for the remaining wizards.

// Get the names of the wizards in Hufflepuff
var hufflepuff = wizards.filter(function (wizard) {
  return wizard.house === 'Hufflepuff';
}).map(function (wizard) {
  return wizard.name;
});

With the Array.reduce() method, we can get the same array in a single pass, improving our performance. You pass in an empty array ([]) as the starting value. On each pass, you check to see if the wizard.house is Hufflepuff. If it is, you push it to the newArr (our accumulator in this example). If not, you do nothing.

Either way, you return the newArr to become the accumulator on the next pass.

// Get the names of the wizards in Hufflepuff
var hufflepuff = wizards.reduce(function (newArr, wizard) {
  if (wizard.house === 'Hufflepuff') {
    newArr.push(wizard.name);
  }
  return newArr;
}, []);

Here’s another demo.

3. Creating markup from an array

What if, instead of creating an array of names, we wanted to create an unordered list of wizards in Hufflepuff? Instead of passing an empty array into Array.reduce() as our starting value, we’ll pass in an empty string ('') and call it html.

If the wizard.house equals Hufflepuff, we’ll concatenate our html string with the wizard.name wrapped in an opening and closing list item (li). Then, we’ll return the html to become the accumulator on the next loop.

// Create a list of wizards in Hufflepuff
var hufflepuffList = wizards.reduce(function (html, wizard) {
  if (wizard.house === 'Hufflepuff') {
    html += '<li>' + wizard.name + '</li>';
  }
  return html;
}, '');

Add an opening and closing unordered list element before and after Array.reduce(), and you’re ready to inject your markup string into the DOM.

// Create a list of wizards in Hufflepuff
var hufflepuffList = '<ul>' + wizards.reduce(function (html, wizard) {
  if (wizard.house === 'Hufflepuff') {
    html += '<li>' + wizard.name + '</li>';
  }
  return html;
}, '') + '</ul>';

See it in action here.

4. Grouping similar items in an array together

The lodash library has a groupBy() method takes a collection of items as an array and groups them together into an object based on some criteria.

Let’s say you want an array of numbers.

If you wanted to group all of the items in numbers together based on their integer value, you would do this with lodash.

var numbers = [6.1, 4.2, 6.3];

// returns {'4': [4.2], '6': [6.1, 6.3]}
_.groupBy(numbers, Math.floor);

If you had an array of words, and you wanted to group the items in words by their length, you would do this.

var words = ['one', 'two', 'three'];

// returns {'3': ['one', 'two'], '5': ['three']}
_.groupBy(words, 'length');

Creating a groupBy() function with Array.reduce()

You can recreate that same functionality using the Array.reduce() method.

We’ll create a helper function, groupBy(), that accepts the array and criteria to sort by as arguments. Inside groupBy(), we’ll run Array.reduce() on our array, passing in an empty object ({}) as our starting point, and return the result.

var groupBy = function (arr, criteria) {
  return arr.reduce(function (obj, item) {
    // Some code will go here...
  }, {});
};

Inside the Array.reduce() callback function, we’ll check to see if the criteria is a function, or a property of the item. Then we’ll get its value from the current item.

If there’s no property in the obj with that value yet, we’ll create it and assign an empty array as its value. Finally, we’ll push the item to that key, and return the object as the accumulator for the next loop.

var groupBy = function (arr, criteria) {
  return arr.reduce(function (obj, item) {

    // Check if the criteria is a function to run on the item or a property of it
    var key = typeof criteria === 'function' ? criteria(item) : item[criteria];

    // If the key doesn't exist yet, create it
    if (!obj.hasOwnProperty(key)) {
      obj[key] = [];
    }

    // Push the value to the object
    obj[key].push(item);

    // Return the object to the next item in the loop
    return obj;

  }, {});
};

Here’s a demo of the completed helper function.

Special thanks to Tom Bremer for helping me make some improvements to this one. You can find this helper function and more like it on the Vanilla JS Toolkit.

5. Combining data from two sources into an array

Remember our array of wizards?

var wizards = [
  {
    name: 'Harry Potter',
    house: 'Gryfindor'
  },
  {
    name: 'Cedric Diggory',
    house: 'Hufflepuff'
  },
  {
    name: 'Tonks',
    house: 'Hufflepuff'
  },
  {
    name: 'Ronald Weasley',
    house: 'Gryfindor'
  },
  {
    name: 'Hermione Granger',
    house: 'Gryfindor'
  }
];

What if you had another data set, an object of house points each wizard has earned.

var points = {
  HarryPotter: 500,
  CedricDiggory: 750,
  RonaldWeasley: 100,
  HermioneGranger: 1270
};

Imagine you wanted to combine both sets of data into a single array, with the number of points added to each wizard’s data in the wizards array. How would you do it?

The Array.reduce() method is perfect for this!

var wizardsWithPoints = wizards.reduce(function (arr, wizard) {

  // Get the key for the points object by removing spaces from the wizard's name
  var key = wizard.name.replace(' ', '');

  // If the wizard has points, add them
  // Otherwise, set them to 0
  if (points[key]) {
    wizard.points = points[key];
  } else {
    wizard.points = 0;
  }

  // Push the wizard object to the new array
  arr.push(wizard);

  // Return the array
  return arr;

}, []);

Here’s a demo combining data from two sources into an array.

6. Combining data from two sources into an object

What if you instead wanted to combine the two data sources into an object, where each wizard’s name was the key, and their house and points were properties? Again, the Array.reduce() method is perfect for this.

var wizardsAsAnObject = wizards.reduce(function (obj, wizard) {

  // Get the key for the points object by removing spaces from the wizard's name
  var key = wizard.name.replace(' ', '');

  // If the wizard has points, add them
  // Otherwise, set them to 0
  if (points[key]) {
    wizard.points = points[key];
  } else {
    wizard.points = 0;
  }

  // Remove the name property
  delete wizard.name;

  // Add wizard data to the new object
  obj[key] = wizard;

  // Return the array
  return obj;

}, {});

Here’s a demo combining two data sets into an object.

Should you use Array.reduce() more?

The Array.reduce() method has gone from being something I thought was pointless to my favorite JavaScript method. So, should you use it? And when?

The Array.reduce() method has fantastic browser support. It works in all modern browsers, and IE9 and above. It’s been supported in mobile browsers for a long time, too. If you need to go back even further than that, you can add a polyfill to push support back to IE6.

The biggest complaint you can make about Array.reduce() is that it’s confusing for people who have never encountered it before. Combining Array.filter() with Array.map() is slower to run and involves extra steps, but it’s easier to read. It’s obvious from the names of the methods what they’re supposed to be doing.

That said, there are times where Array.reduce() makes things that would be complicated more simple rather than more complicated. The groupBy() helper function is a good example.

Ultimately, this is another tool to add to your toolkit. A tool that, if used right, can give you super powers.

About the author

Chris Ferdinandi helps people learn vanilla JavaScript. He believes there’s a simpler, more resilient way to make things for the web.

Chris is the author of the Vanilla JS Pocket Guide series, creator of the Vanilla JS Academy training program, and host of the Vanilla JS Podcast. His developer tips newsletter is read by thousands of developers each weekday.

He’s taught developers at organizations like Chobani and the Boston Globe, and his JavaScript plugins have been used used by Apple and Harvard Business School. Chris Coyier, the founder of CSS-Tricks and CodePen, has described his writing as “infinitely quote-worthy.”

Chris loves pirates, puppies, and Pixar movies, and lives near horse farms in rural Massachusetts. He runs Go Make Things with Bailey Puppy, a lab-mix from Tennessee.

More articles by Chris

Online Resource

The district inspector of schools suspended Swain on Thursday after the inquiry.

In lieu of a formal FIR against him, Pramod K Swain has been suspended but not arrested.

Gurbaksh Singh is believed to be "continuing" with his hunger strike in jail.

'TBM is not suitable for tunnel excavation in HP and has been found to be a complete failure'.

Barmi, Maryam Jozegholami, author

PHC, village secretariats identified for quarantine facility

The panelists discuss testing JavaScript with Joe Eames

Pete Hodgson crosses over from the iPhreaks podcasts to talk with the Jabber gang about testing asynchronous Javascript with promises.

02:20 - Zach Kessin Introduction

• Twitter
• GitHub
• Zach's Books
• Parrot
• JavaScript Jabber: Episode #057: Functional Programming with Zach Kessin
• Testing Erlang With Quickcheck Book

04:00 - Mostly Erlang Podcast

05:27 - Property-based Testing (QuickCheck)

07:22 - Property-based Testing and Functional Programming

• jsverify

09:48 - Pure Functions

• Shrinking

18:09 - Boundary Cases

20:00 - Generating the Data

23:23 - Trending Concepts in JavaScript

32:33 - How Property-based Testing Fits in with Other Kind of Testing

35:57 - Test Failures

Panel

Nolan Lawson: Taming the asynchronous beast with ES7 (Aimee)
Nodevember (Aimee)
Hipster Sound (Jamison)
Om Next by David Nolen  (Jamison)
Gallant - Weight In Gold (Jamison)
React Rally (Jamison)
Better Off Ted (Joe)
Armada: A Novel by Ernest Cline (Joe)
Testing Erlang With Quickcheck Book (Zach)
Parrot Universal Notification Interface (Zach)
The Famine of Men by Richard H. Kessin (Zach)

Panel:

Amy Knight

Charles Max Wood

Special Guests: 

Nick Disabato

In this episode, Java Script Jabbers talk with Nick Disabato. Nick is a newbie to JavaScript Jabber. Nick is the founder of Draft, an interaction design agency where he does research driven A/B testing of E-commerce business.

This is a practical episode for those who are running a business and doing marketing for the products and services. Nick talks about A/B testing for a number scenarios within the company, such as for websites, funnels, and various marketing mechanisms. Nick further goes into how this helps companies strategically increase revenue by changing things such as websites design or building funnels.

In particular, we dive pretty deep on:

• Testing of changes of Copy, Websites, etc.
• What does it mean of changes, Tools, Framework, Plugins, etc
• Does it matter what tools you use? Framework that works within your stack
• How do make we company money
• Researching for the next test
• Testing for conversion rate to decide which design to go implement - Variant
• Responsibility for the designs
• Feature and getting pay for the service
• Learn more about the resources and Copy Hackers
• Large organization or developers, or a QA department
• Optimization teams
• Usability tests and coming up with A/B tests
• Expertise
• Why should be care?
• And much more!

Links:

Draft

Nick Disabato

@nickd

ConversionXL

AB Testing Manual

Wider Funnels 

Copy Hackers

Picks:

Amiee

• Nodevember 

Charles

• Mike Gehard 
• Admin LTE

Nick

• HotJar.com

Panel:

• AJ O’Neal
• Aimee Knight
• Joe Eames
• Charles Max Wood

Special Guests: Vitali Zaidman

In this episode, the panel talks with programmer, Vitali Zaidman, who is working with Software Solutions Company. He researches technologies and starts new projects all the time, and looks at these new technologies within the market. The panel talks about testing JavaScript in 2018 and Jest.

Show Topics:

1:32 – Chuck: Let’s talk about testing JavaScript in 2018.

1:53 – Vitali talks about solving problems in JavaScript.

2:46 – Chuck asks Vitali a question.

3:03 – Vitali’s answer.

3:30 – Why Jest? Why not Mocha or these other programs?

3:49 – Jest is the best interruption of what testing should look like and the best practice nowadays. There are different options, they can be better, but Jest has this great support from their community. There are great new features.

4:31 – Chuck to Joe: What are you using for testing nowadays?

4:43 – Joe: I use Angular, primarily.

6:01 – Like life, it’s sometimes easier to use things that make things very valuable.

7:55 – Aimee: I have heard great things about Cypress, but at work we are using another program.

8:22 – Vitali: Check out my article.

8:51 – Aimee: There are too many problems with the program that we use at work.

9:39 – Panelist to Vitali: I read your article, and I am a fan. Why do you pick Test Café over Cypress, and how familiar are you with Cypress? What about Selenium and other programs?

10:12 – Vitali: “Test Café and Cypress are competing head-to-head.”

Listen to Vitali’s suggestions and comments per the panelists’ question at this timestamp.

11:25 – Chuck: I see that you use sign-on...

12:29 – Aimee: Can you talk about Puppeteer? It seems promising.

12:45 – Vitali: Yes, Puppeteer is promising. It’s developed by Google and by Chrome. You don’t want to use all of your tests in Puppeteer, because it will be really hard to do in other browsers.

13:26: Panelist: “...5, 6, 7, years ago it was important of any kind of JavaScript testing you had no idea if it worked in one browser and it not necessarily works in another browser. That was 10 years ago. Is multiple browsers testing as important then as it is now?

14:51: Vitali answers the above question.

15:30 – Aimee: If it is more JavaScript heavy then it could possibly cause more problems.

15:56 – Panelist: I agree with this.

16:02 – Vitali continues this conversation with additional comments.

16:17 – Aimee: “I see that Safari is the new Internet Explorer.”

16:23: Chuck: “Yes, you have to know your audience. Are they using older browsers? What is the compatibility?”

17:01 – Vitali: There are issues with the security. Firefox has a feature of tracking protection; something like that.

17:33 – Question to Vitali by Panelist.

17:55 – Vitali answers the question.

18:30 – Panelist makes additional comments.

18:43 – If you use Safari, you reap what you sow.

18:49 – Chuck: I use Chrome on my iPhone. (Aimee does, too.) Sometimes I wind up in Safari by accident.

19:38 – Panelist makes comments.

19:52 – Vitali tells a funny story that relates to this topic.

20:45 – There are too many standards out there.

21:05 – Aimee makes comments.

21:08 – Brutalist Web Design. Some guy has this site – Brutalist Web Design – where he says use basic stuff and stop being so custom. Stop using the web as some crazy platform, and if your site is a website that can be scrolled through, that’s great. It needs to be just enough for people to see your content.

22:16 – Aimee makes additional comments about this topic of Brutalist Web Design.

22:35 – Panelist: I like it when people go out and say things like that.

22:45 – Here is the point, though. There is a difference between a website and a web application. Really the purpose is to read an article.

23:37 – Vitali chimes in.

24:01 – Back to the topic of content on websites.

25:17 – Panelist: Medium is very minimal. Medium doesn’t feel like an application.

26:10 – Is the website easy enough for the user to scroll through and get the content like they want to?

26:19 – Advertisement.

27:22 – See how far off the topic we got?

27:31 – These are my favorite conversations to have.

27:39 – Vitali: Let’s talk about how my article got so popular. It’s an interesting thing, I started researching “testing” for my company. We wanted to implement one of the testing tools. Instead of creating a presentation, I would write first about it in Medium to get feedback from the community as well. It was a great decision, because I got a lot of comments back. I enjoyed the experience, too. Just write about your problem in Medium to see what people say.

28:48 – Panelist: You put a ton of time and energy in this article. There are tons of links. Did you really go through all of those articles?

29:10 – Yes, what are the most permanent tools? I was just reading through a lot of comments and feedback from people. I tested the tools myself, too!

29:37 – Panelist: You broke down the article, and it’s a 22-minute read.

30:09 – Vitali: I wrote the article for my company, and they ad to read it.

30:24 – Panelist: Spending so much time – you probably felt like it was apart of your job.

30:39 – Vitali: I really like creating and writing. It was rally amazing for me and a great experience. I feel like I am talented in this area because I write well and fast. I wanted to express myself.

31:17 – Did you edit and review?

31:23 – Vitali: I wrote it by myself and some friends read it. There were serious mistakes, and that’s okay I am not afraid of mistakes. This way you get feedback.

32:10 – Chuck: “Some people see testing in JavaScript, and people look at this and say there are so much here. Is there a place where people can start, so that way they don’t’ get too overwhelmed? Is there a way to ease into this and take a bite-size at a time?”

32:52 – Vitali: “Find something that works for them. Read the article and start writing code.”

He continues this conversation from here on out.

34:03 – Chuck continues to ask questions and add other comments.

34:16 – Vitali chimes-in. 

34:38 – Chuck. 

34:46 – Vitali piggybacks off of Chuck’s comments.

36:14 – Panelist: Let’s go back to Jest. There is a very common occurrence where we see lots of turn and we see ideas like this has become the dominant or the standard, a lot of people talk about stuff within this community. Then we get this idea that ‘this is the only thing that is happening.’ Transition to jQuery to React to... With that context do you feel like Jest will be a dominant program? Are we going to see Jest used just as common as Mocha and other popular programs?

38:15 – Vitali comments on the panelist’s question.

38:50 – Panelist: New features. Are the features in Jest (over Jasmine, Mocha, etc.) so important that it will drive people to it by itself?

40:30 – Vitali comments on this great question.

40:58 – Panelist asks questions about features about Jest.

41:29 – Vitali talks about this topic.

42:14 – Let’s go to picks!

42:14 – Advertisement.

Links:

• Vitali Zaidman’s Facebook
• Vitali Zaidman’s Medium
• Vitali Zaidman’s GitHub
• Vitali Zaidman’s NPM
• Vitali Zaidman’s LinkedIn
• Vitali Zaidman’s Medium Article
• JavaScript
• Brutalist Web Design
• Jasmine
• Cypress
• React
• jQuery
• Jest
• Protractor – end to end testing for Angular
• Test Café
• Intern
• Sinon
• XKCD

Sponsors:

• Kendo UI
• Sentry
• Digital Ocean
• Cache Fly

Picks:

AJ O’Neal

• Continuous from last week’s episode: Crossing the Chasm – New Technologies from Niche to General Adaptation.
• Go Lang

Joe Eames

• Board Game: Rajas of the Ganges
• Framework Summit Conference in Utah
• React Conference

Aimee Knight

• Hacker News – “Does Software Understand Complexity” via Michael Feathers
• Cream City Code

Chuck

• E-Book: How do I get a job?
• Express VPN

Vitali

• Book: The Square and The Tower: Networks and Power, from the Freemasons to Facebook by Niall Ferguson
• My article!

Panel:

• Aimee Knight
• AJ O’Neal
• Charles Max Wood

Special Guest: Gil Tayar

In this episode, the panel talks with Gil Tayar who is currently residing in Tel Aviv and is a software engineer. He is currently the Senior Architect at Applitools in Israel. The panel and the guest talk about the different types of tests and when/how one is to use a certain test in a particular situation. They also mention Node, React, Selenium, Puppeteer, and much more!

Show Topics:

0:00 – Advertisement: KENDO UI

0:35 – Chuck: Our panel is AJ, Aimee, myself – and our special guest is Gil Tayar. Tell us why you are famous!

1:13 – Gil talks about where he resides and his background. 

2:27 – Chuck: What is the landscape like now with testing and testing tools now?

2:39 – Guest: There is a huge renaissance with the JavaScript community. Testing has moved forward in the frontend and backend. Today we have lots of testing tools.  We can do frontend testing that wasn’t possible 5 years ago. The major change was React.

The guest talks about Node, React, tools, and more!

4:17 – Aimee: I advocate for tests and testing. There is a grey area though...how do you treat that? If you have to get something into production, but it’s not THE thing to get into production, does that fall into product or...what?

5:02 – Guest: We decided to test everything in the beginning. We actually cam through and did that and since then I don’t think I can use the right code without testing. There are a lot of different situations, though, to consider.

The guest gives hypothetical situations that people could face.

6:27 – Aimee.

6:32 – Guest: The horror to changing code without tests, I don’t know, I haven’t done that for a while. You write with fear in your heart. Your design is driven by fear, and not what you think is right. In the beginning don’t write those tests, but...

7:22 – Aimee: I totally agree and I could go on and on and on.

7:42 – Panel: I want to do tests when I know they will create value. I don’t want to do it b/c it’s a mundane thing. Secondly, I find that some times I am in a situation where I cannot write the test b/c I would have to know the business logic is correct. I am in this discovery mode of what is the business logic? I am not just building your app.

I guess I just need advice in this area, I guess.

8:55 – Guest gives advice to panelist’s question. He mentions how there are two schools of thought.

10:20 – Guest: Don’t mock too much.

10:54 – Panel: Are unit tests the easiest? I just reach for unit testing b/c it helps me code faster. But 90% of my code is NOT that.

11:18 – Guest: Exactly! Most of our test is glue – gluing together a bunch of different stuff! Those are best tested as a medium-sized integration suite.

12:39 – Panel: That seems like a lot of work, though! I loathe the database stuff b/c they don’t map cleanly. I hate this database stuff.

13:06 – Guest: I agree, but don’t knock the database, but knock the level above the database.

13:49 – Guest: Yes, it takes time! Building the script and the testing tools, but when you have it then adding to it is zero time. Once you are in the air it’s smooth sailing.

14:17 – Panel: I guess I can see that. I like to do the dumb-way the first time. I am not clear on the transition.

14:47 – Guest: Write the code, and then write the tests.

The guest gives a hypothetical situation on how/when to test in a certain situation.

16:25 – Panel: Can you talk about that more, please?

16:50 – Guest: Don’t have the same unit – do browser and business logic stuff separated. The real business logic stuff needs to be above that level. First principle is separation of concerns.

18:04 – Panel talks about dependency interjection and asks a question.

18:27 – Guest: What I am talking about very, very light inter-dependency interjection.

19:19 – Panel: You have a main function and you are doing requires in the main function. You are passing the pieces of that into the components that need it.

19:44 – Guest: I only do it when it’s necessary; it’s not a religion for me. I do it only for those layers that I know will need to be mocked; like database layers, etc.

20:09 – Panel.

20:19 – Guest: It’s taken me 80 years to figure out, but I have made plenty of mistakes a long the way. A test should run for 2-5 minutes max for package.

20:53 – Panel: What if you have a really messy legacy system? How do you recommend going into that? Do you write tests for things that you think needs to get tested?

21:39 – Guest answers the question and mentions Selenium!

24:27 – Panel: I like that approach.

24:35 – Chuck: When you say integration test what do you mean?

24:44 – Guest: Integration tests aren’t usually talked about. For most people it’s tests that test the database level against the database. For me, the integration tests are taking a set of classes as they are in the application and testing them together w/o the...so they can run in millisecond time.

26:54 – Advertisement – Sentry.io

27:52 – Chuck: How much do the tools matter?

28:01 – Guest: The revolutions matter. Whether you use Jasmine or Mocha or whatever I don’t think it matters. The tests matter not the tools.

28:39 – Aimee: Yes and no. I think some tools are outdated.

28:50 – Guest: I got a lot of flack about my blog where I talk about Cypress versus Selenium. I will never use Jasmine. In the end it’s the

29:29 – Aimee: I am curious would you be willing to expand on what the Selenium folks were saying about Puppeteer and others may not provide?

29:54 – Guest: Cypress was built for frontend developers. They don’t care about cross browser, and they tested in Chrome. Most browsers are typically the same. Selenium was built with the QA mindset – end to end tests that we need to do cross browser.

The guest continues with this topic.

30:54 – Aimee mentions Cypress.

31:08 – Guest: My guessing is that their priority is not there. I kind of agree with them.

31:21 – Aimee: I think they are focusing on mobile more.

31:24 – Guest: I think cross browser testing is less of an issue now. There is one area that is important it’s the visual area! It’s important to test visually across these different browsers.

32:32 – Guest: Selenium is a Swiss knife – it can do everything.

33:32 – Chuck: I am thinking about different topics to talk about. I haven’t used Puppeteer. What’s that about?

33:49 – Guest: Puppeteer is much more like Selenium. The reason why it’s great is b/c Puppeteer will always be Google Chrome.

35:42 – Chuck: When should you be running your tests? I like to use some unit tests when I am doing my development but how do you break that down?

36:06 – Guest.

38:30 – Chuck: You run tests against production?

38:45 – Guest: Don’t run tests against production...let me clarify!

39:14 – Chuck.

39:21 – Guest: When I am talking about integration testing in the backend...

40:37 – Chuck asks a question.

40:47 – Guest: I am constantly running between frontend and backend.

I didn’t know how to run tests for frontend. I had to invent a new thing and I “invented” the package JS DONG. It’s an implementation of Dong in Node. I found out that I wasn’t the only one and that there were others out there, too.

43:14 – Chuck: Nice! You talked in the prep docs that you urged a new frontend developer to not run the app in the browser for 2 months?

43:25 – Guest: Yeah, I found out that she was running the application...she said she knew how to write tests. I wanted her to see it my way and it probably was a radical train-of-thought, and that was this...

44:40 – Guest: Frontend is so visual.

45:12 – Chuck: What are you working on now?

45:16 – Guest: I am working with Applitools and I was impressed with what they were doing.

The guest goes into further detail.

46:08 – Guest: Those screenshots are never the same.

48:36 – Panel: It’s...comparing the output to the static site to the...

48:50 – Guest: Yes, that static site – if you have 30 pages in your app – most of those are the same. We have this trick where we don’t upload it again and again. Uploading the whole static site is usually very quick. The second thing is we don’t wait for the results. We don’t wait for the whole rendering and we continue with the tests.

50:28 – Guest: I am working mostly (right now) in backend.

50:40 – Chuck: Anything else? Picks!

50:57 – Advertisement: Get A Coder Job!

END – Advertisement: CacheFly!

Links:

• JavaScript
• React
• Elixir
• Node.js
• Puppeteer
• Cypress
• SeleniumHQ
• Article – Ideas.Ted.Com
• Book: Never Split the Difference
• Applitools
• Guest’s Blog Article about Cypress vs. Selenium
• Gil’s Twitter
• Gil’s Medium
• Gil’s LinkedIn

Sponsors:

• Kendo UI
• Sentry
• CacheFly

Picks:

Aimee

• How Showing Vulnerability Helps Build a Stronger Team

AJ

• Never Split the Difference
• Project - TeleBit

Charles

• Monster Hunter International
• Metabase

Gil

• Cat Zero
• The Origin of Consciousness in the Breakdown of the Bicameral Mind

Sponsors

• Netlify

• RxJS Live 

Panel

• Aimee Knight

• AJ O’Neal

• Charles Max Wood

With Special Guest: Jeff Meyerson

Episode Summary

Jeff Meyerson is the host of the Software Engineering daily podcast and has also started a company called FindCollabs, an online platform for finding collaborators and building projects. Jeff started FindCollabs because he believes there are all these amazing tools but people are not combining and collaborating as much as they could, when so much good could be accomplished together. FindCollabs is especially useful for working on side projects. The panelists discuss the problems encountered when you try to collaborate with people over the internet, such as finding people who are facing similar and gauging interest, skill, and availability. Thankfully, FindCollabs has a feature of leaving reviews and rating your partners so that users can accurately gauge other’s skill level. Users can also leave comments about their experience collaborating with others. The only way you can show competence with an interest is to contribute to another project. FindCollabs is also a good place to look for mentors, as well as for Bootcamp graduates or people going through an online coding course. If you are part of an organization, you can create private projects. The company plans to expand this feature to all users in the future.The panelists talk about their past experiences with collaborating with other people.

Jeff talks about his podcast Software Engineering Daily and how it got started and the focus of the podcast. As someone working in technology, it is important to stay current on up and coming technology, and listening to podcasts is an excellent way to do that. Jeff talks about where he thinks podcasting is going, especially for programmers. The panel discusses some of the benefits of listening to programming podcasts. Jeff talks about how he is prepping Software Engineering Daily for the future. He shares the audience size for Software Engineering Daily and some of the statistics for his different channels. Jeff has also released an app for Software Engineering Daily, and he shares some information on how it was written. Finally, Jeff gives advice for people who want to use FindCollabs and some of the next steps after creating a profile.

Click here to cast your vote NOW for JavaScript Jabber - Best Dev Podcast Award

Links

• FindCollabs

• Greenlock

• Telebit

• SwingCycle

• Software Engineering Daily

Follow DevChat on Facebook and Twitter

Picks

Aimee Knight:

• Burnout and the Brain

AJ O’Neal:

• Saber’s Edge from Final Fantasy by Distant Worlds

• Greenlock on FindCollabs

• Telebit on FindCollabs

Charles Max Wood:

• Adventures in Machine Learning on FindCollabs

• Adventures in Virtual Reality on FindCollabs

• Adventures in Python on FindCollabs

• Adventures in Java on FindCollabs

• Air conditioning

• MFCEO Project

Jeff Meyerson:

• Follow Jeff  @the_prion 

• Listen Notes

• Linbin’s Podcast Playlist

• Hidden Forces Podcast

Daniel Caldas is calling from Singapore. He currently works as a software engineer for Zendesk and has also worked in Portugal and Germany. He has worked primarily on the frontend with Node and JavaScript. He talks about his experience testing JavaScript, how he got started with Jest, and why he likes it. Daniel finds Jest very easy to use and straightforward. He likes that  Jest has a single reference page for documentation. He feels that Jest is largely complete out of the box and has only made a small add on to get rid of Boilerplate in some tests.

Daniel explains what a snapshot, how they work, and why he prefers fixtures over factories. He gives tips on how to set up your tests so that they are easy to follow. He finds it helps to structure your scenarios in the fixture description. He talks about gotchas in Jest. While Jest is largely easy to use, Jest has been around for a while and breaking changes do happen. It’s important to check what version your code base is using. While there are a lot of free sources around Jest online, he advises listeners to stick as close to the official documentation as possible, or to people associated with Jest, and to read recent stuff. As for conventions, Jest has pretty much everything out of the box and the built in conventions make it easy to navigate any project that uses Jest.

Daniel talks about some of the features available in Jest, converting observables into promises, and tricks he has used to make tests easier to put together. He talks about his method for keeping his mocks and stubs straight. He advises listeners to have some organizational rules, such as starting the imports alphabetically, and to always follow those rules. He talks about how he runs tests and what environments he uses. While Jest is normally used for unit testing, Daniel has also used it for end to end tests, and he talks about his experience with an open source project doing both types in Jest. Daniel concludes the show by advising listeners starting with JavaScript and frontend, don’t think too much about the library you’re going to use because you’ll probably end up using Jest. It’s more important to have unit tests and a proper testing framework at the beginning than anything else. He also invites listeners to check out his open source work on Github.

Panelists

• Aimee Knight

• AJ O’Neal

• Charles Max Wood

**To receive your 40% OFF coupon for Manning Publications (good for all our products in all formats) visit us on Facebook - click on "Send A Message"and type "YES"**

Guest

• Danile Caldas

Sponsors

• Sentry | Use the code “devchat” for $100 credit

Links

• Zendesk

• Jest

• React

• Babel

• ESLint

• Async/Await

• Cypress

• React-d3-graph

• Unrevealed tips for unit testing with Jest

Picks

Aimee Knight:

• The Difference Between Fault Tolerance, High Availability, and Disaster Recovery

AJ O’Neal:

• Rubin Report with Lindsay Shepherd

Charles Max Wood:

• White Christmas

• Holiday Inn

Daniel Caldas:

• Home Alone

This Special Communication proposes a classification of patients with left-ventricular disease according to the severity of mitral regurgitation that is proportionate vs disproportionate to left-ventricular end-diastolic volume.

Movie stars in 2014's polls are a welcome addition to the fray. For those carping about how stars represent glamour and gloss, why not?

Jarvis, W. Todd, author

Trujillo, Alan P., author

Online Resource

Online Resource

Keesmaat, Sylvia C., author

Sehested, Nancy Hastings, author

TrueNat machines will be used for the first time in the State for virus screening

The Centre said it feared that the order may have a “cascading effect” on migrants of other States as well

Franz, Peter

Ellis, Charles D

Ellis, Charles D., author

Interview with Ranhjit Manchanda, MD, author of A Cost-effectiveness Analysis of Multigene Testing for All Patients With Breast Cancer