<![CDATA[SumUp Engineering - Medium]]> https://medium.com/sumup-engineering?source=rss----bc8d70b3a259---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png SumUp Engineering - Medium https://medium.com/sumup-engineering?source=rss----bc8d70b3a259---4 Medium Mon, 11 May 2026 16:53:20 GMT <![CDATA[10 lessons learned building SumUp’s design system]]> https://medium.com/sumup-engineering/10-lessons-learned-building-sumups-design-system-577af292ae56?source=rss----bc8d70b3a259---4 https://medium.com/p/577af292ae56 Thu, 15 Aug 2019 09:14:19 GMT 2019-08-15T09:27:32.043Z How hard can it be?

So many teams start out thinking a design system will help solve a lot of the challenges they face while scaling development and design teams: consistency, efficiency, re-inventing the wheel.

While a design system is a modern and scalable way to address these kinds of issues, there are a lot of lessons to be learned from what introducing a design system looks like on paper — and what it looks like in production.

We started working on our design system at SumUp in January 2018.

Our goal was to introduce a scalable way to harmonize the experience across multiple frontend applications and amplify developer and designer productivity.

…all while simultaneously performing both a rebranding and a technical migration from Angular to React.

It was an ambitious project.

In the meantime, our team grew from 3 to over 15 frontend engineers and the number of cross-functional teams using the system multiplied as well.

Over a year and a half later, we finally feel ready to label our design system, called Circuit UI, version 1.0. We still have a lot of work ahead of us, and big plans for version 2.0, but we’ve also learned a lot along the way that we think is worth sharing.

Here are the key learnings from some of the designers and developers who helped us reach this important milestone.

1. “Making the design system part of your business requirements is key”

My biggest learning is it’s extremely hard to balance the amount of effort you can put into the design system versus feature development. Most of the time when building such a solution, you still want to actively work on new features, not totally halt development. This is especially true if you are doing this while being part of a team that builds product features, and not part of a dedicated “Design System” initiative.

My advice is to avoid handling the design system as a side project, because it’s important for people to understand that a design system is a constant part of product development too. By ensuring everyone is on board and understands the value of such a tool, it’s way easier to push the design system forward in smaller increments, and even fit it into your regular release/delivery cycles, such as a sprint.

This is one of the secrets for a healthy growth.

— Fernando (@fernando_fleury)

2. “Take the time to get it right”

One of the things I enjoyed the most about building Circuit UI was the opportunity to do in-depth research for each component. I learned so much about obscure HTML elements, weird CSS quirks, best practices for accessibility, and good API design. Now when we use the components in an application, we can feel confident that the component displays consistently across browsers, is keyboard and screen-reader accessible, and generally works well.

However, building these benefits into the component library is often not enough. Let’s take accessibility as an example, as it’s a topic that is particularly close to my heart. Often a user of the component library has to take extra steps to ensure that components remain accessible when integrated together in an application. A good component library makes it easy to do the right thing through good API design and education in documentation.

When you build your own component library, make sure you take the time to get it right. The initial investment might seem high, but it will pay off manifold over time.

— Connor (@connor_baer)

3. “Creating the design system is only the beginning”

Probably my biggest take away from building out our design system is that creating the system itself is only the first step. The harder part is actually applying it to an existing codebases, especially if the design system is also introducing a redesign and changing frameworks like it was for us. That makes it more challenging to adopt gradually, and slowed down the process a lot.

On the flip side, the benefit was that when we finished, we had a very clean setup in the application: both on the technical side and the UI side. Introducing a design system was an effective and systematic way for us to revamp our biggest application from top to bottom.

— Monica (@monicalent)

4. “Deciding what belongs to the design system can be challenging”

Being a part of a product company means constantly working on new and exciting features. This inevitably leads to teams reusing existing components of the design system or building new ones. During feature development we were sometimes struggling with deciding if the super cool component we are implementing should live in Circuit UI or not.

My takeaway is that when it comes to this, it is really important to communicate with the rest of the team and involve people from design as soon as possible to assess if the component could turn into a UI pattern in your design system.

Of course, this could slow you down and be a bit stressful, especially if you are on a deadline.

But at the end of the day, UI consistency is a key factor in product development so you should do your best to help people from business and other stakeholders understand that investing more time in making a component generic could be really helpful in the future.

— Mariela (@marielakas)

5. “Having a design system will not solve all your consistency problems”

One of the most direct benefits of having a design system is to gain consistency throughout the user experience. However, during Circuit UI’s development, we still experienced some of the same issues that justified its creation in the first place.

For instance, having two developers/designers working on the same new component or discovering areas that weren’t originally covered by the design system (one example from our side is iconography).

This led us to reflect that consistency is a never-ending mission. We need to continuously push our behavior and shape processes that allow visibility and ensure that we are pushing the best possible experience for us, as designers and developers, and for our merchants.

— João (@joaovictortg)

6. “Efficiency is the most tangible benefit of the design system approach”

After our design system was available as a beta version, I started to create a new application with Circuit UI and this opportunity showed me the benefits of having it in our lives.

For example, our product designer was using only the components of the design system and this meant he could create the first prototypes of our application very quickly.

When I started the implementation, I was able to worry more about the business logic than making sure all components will have the right CSS. In one day, we were able to build our first “login” screen and deploy it. The only thing I needed to think about was how to make the page interact with existing components.

This opportunity makes everyone feels more confident about the components and focus more on about the value we deliver to our merchants. Of course, sometimes we find out we need new components in Circuit UI because of new cases that appear in our new project!

And this is related to our first learning: we need to start working on our requirements and consider creating new components for Circuit UI (and not only our project) so we can enable more people to benefit from the new components we create.

— Herbert (@herberth3nrique)

7. “The strong sense of community made us stronger”

One of the greatest things about working on Circuit UI was the collaboration with great designers and developers from all over the world. In the beginning, I couldn’t even imagine the number of lessons and knowledge I would gather from people with different backgrounds, expertise, ideas, and styles.

Circuit UI became much more than a design system, it became a community where we could share experiences, new ideas, learn from each other and become better engineers and designers.

I truly believe that our team became stronger when working together on something that would benefit not just us, but the whole community.

— Afonso (@kdsopasir)

8. “Design systems are the living, breathing part of the collaboration between design and development”

You want a fig tree. You buy some seeds and you put a lot of care into making that baby grow. After weeks and months (How long do fig trees take?) of TLC you have your beautiful, leafy child and you’re proud as punch. Then you ignore it. You start growing new plants that need more attention and you forget about that once beautiful fig tree in the corner of the room.

The fig tree is your design system.

Our job, as designers & developers, is to keep the design system proper, healthy and up to date. It’s not a full time job (yet) but it takes meaningful time and effort to maintain the dream of a consistent experience throughout our platforms.

— Matt (@majahoughton)

9. “Onboard new comers to the design system as soon as possible”

As more developers join our team, it is important for the new team members to spend time familiarizing themselves with the design system in detail and getting to know its capabilities and limitations from the start. Having this tool in your pocket can be a huge timesaver and being able to use it with certainty makes developers more productive.

To facilitate the “getting to know the design system” phase, well-written, up-to-date and detailed documentation certainly is a plus. Communicating clearly when a change is about to be implemented is also a big part of it.

Having an open discussion about potential improvements helps get everyone involved and invested in the project.

— Iva

10. “Even the biggest changes can and should be delivered in increments”

We started work on Circuit UI because we knew we needed a more consistent way to design and deliver our products. A design system and an implementation in React seemed like a great fit. We also knew we were a team of three frontend engineers in all of SumUp at the time. So how do you create a component library from scratch and rewrite the entire frontend using it? Short answer: you do not, at least not with a team this size.

But what do you do instead?

You come up with a plan to do it incrementally.

We started with a limited set of components, only what we knew we would need. The rest was added as we rewrote or created other products. We had a simple bash script that would generate some boilerplate files so creating new components would be quick. Nowadays we have a complete CLI with support for different types of components. When we started using Circuit UI in our web products we installed it as a dependency from GitHub. A build was added much later. Circuit UI still does not have working static CSS extraction. We only built a proof of concept because we knew we might need it down the road.

The point here is: if you want to make big changes with a small team, you have to find ways to do so incrementally so people can continue quickly and continuously deliver value to users.

The amazing thing I learned over the last year is that this actually works. It feels slow. Sometimes it is painful because you know you could do so much more.

But you just put one foot in front of the other and after some time, when looking back, you realize you have made it incredibly far.

— Felix (@feju)

Does working on Circuit UI sound like something you’d enjoy?

We’re hiring both engineers who will build and maintain our design system as part of our new Web Platform team, as well as product designers who will use and extend the system.

Check out our open roles for:

Follow us on twitter @SumUpEng for future updates!

10 lessons learned building SumUp’s design system was originally published in SumUp Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Image creation and testing with HashiCorp Packer and ServerSpec]]> https://medium.com/sumup-engineering/image-creation-and-testing-with-hashicorp-packer-and-serverspec-bb2bd065441?source=rss----bc8d70b3a259---4 https://medium.com/p/bb2bd065441 Sat, 01 Dec 2018 15:07:51 GMT 2019-04-12T22:11:25.762Z
Using HashiCorp Packer and ServerSpec

Intro

At SumUp we use various technologies and tools depending on their purpose and trade-offs.

Recently we started a few infrastructure-heavy projects.

We had to solve the problem of creating images (virtual appliances) for QEMU and VirtualBox for multiple projects:

  • one project creates guests using a chain of QEMU images
  • one project creates guest using a chain of VirtualBox images

What this article is going to cover as “hands-on” tech

Source code:

syndbg/sumup-blog-hashicorp-packer-test

First, why Packer and what are the use-cases?

Best check out the “Why” and “Use Cases” at https://www.packer.io/intro/why.html and https://www.packer.io/intro/use-cases.html

What is ServerSpec and what are the use-cases?

ServerSpec in a sense is a library with its own command runner and “resources” provider SpecInfra, all based around RSpec, the Ruby BDD test suite framework.

Sample code from https://serverspec.org/

require 'spec_helper'  
describe package('httpd'), :if => os[:family] == 'redhat' do 
  it { should be_installed } 
end

It’s not the only test library and runner around RSpec, but it’s one with good popularity and there are good amount of resources to get your goal done.

One of the competition is https://www.inspec.io/ by Chef. It almost reads the same and provides the same resources, since there’s not much room for metaphors and lingo when you’re talking about infrastructure.

Another sample code, but this time using InSpec (you can see more about the packageresource at https://www.inspec.io/docs/reference/resources/package/)

require 'spec_helper'
describe package('httpd'), :if => os[:family] == 'redhat' do 
  it { should be_installed } 
end

As you can see they’re *can* be exactly the same at times.

What the ordinary Packer build flow looks like

Note: communicator(s) and post-processor(s) have been omitted/greatly simplified for readability

What the Packer build flow will look like with tests

Note: communicator(s) and post-processor(s) have been omitted/greatly simplified for readability

Preparing the HashiCorp Packer Debian image to build:

The full file looks like this: (we’re reviewing below specific parts what they give us as functionality) (ref: https://github.com/syndbg/sumup-blog-hashicorp-packer-test/blob/master/packer-base-debian.json)

{
  "variables": {
    "debian_version": "9.6.0",
    "boot_wait": "5s",
    "cpus": "1",
    "disk_size": "5000",
    "headless": "false",
    "memory": "512",
    "mirror": "http://mirror.host.ag/debian/debian-cd/",
    "iso_checksum_url": "http://mirror.host.ag/debian/debian-cd/9.6.0/amd64/iso-cd/SHA512SUMS",
    "ssh_timeout": "30m",
    "host_adapter": null,
    "rdp_bind_address": "127.0.0.1",
    "must_run_tests": "false",
    "must_sleep_before_tests": "false"
  },
  "provisioners": [
    {
      "type": "shell",
      "scripts": [
        "./files/base-debian/00_guest_additions.sh"
      ],
      "only": ["virtualbox-base-debian"]
    },
    {
      "type": "shell",
      "scripts": [
        "./files/base-debian/00_qemu_agent.sh"
      ],
      "only": ["qemu-base-debian"]
    },
    {
      "type": "shell",
      "scripts": [
        "./files/base-debian/01_ssh.sh"
      ]
    },
    {
      "type": "shell",
      "scripts": [
        "./files/base-debian/02_disable_lvmetad.sh"
      ]
    },
    {
      "type": "shell",
      "scripts": [
        "./files/base-debian/03_logging.sh"
      ]
    },
    {
      "type": "shell",
      "scripts": [
        "./files/cleanup.sh"
      ]
    },
    {
      "type": "shell-local",
      "script": "./serverspec/sleep_before_tests_packer.sh",
      "environment_vars": [
        "MUST_SLEEP_BEFORE_TESTS={{ user `must_sleep_before_tests` }}"
      ]
    },
    {
      "type": "shell-local",
      "command": "./serverspec/run_packer.sh ./spec/base_debian_spec.rb",
      "environment_vars": [
        "MUST_RUN_TESTS={{ user `must_run_tests` }}",
        "SUDO_PASSWORD=packer123",
        "TARGET_PASSWORD=packer123",
        "TARGET_USER=root",
        "BUILDER_TYPE={{ build_type }}"
      ]
    }
  ],
  "builders": [
    {
      "name": "virtualbox-base-debian",
      "type": "virtualbox-iso",
      "boot_command": [
        "<esc><wait>",
        "install <wait>",
        "preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg <wait>",
        "DEBCONF_DEBUG=5 <wait>",
        "debian-installer=en_US <wait>",
        "auto=true <wait>",
        "priority=high <wait>",
        "locale=en_US <wait>",
        "kbd-chooser/method=us <wait>",
        "keyboard-configuration/xkb-keymap=us <wait>",
        "netcfg/get_hostname=debian <wait>",
        "netcfg/get_domain=  <wait>",
        "netcfg/choose_interface=auto  <wait>",
        "fb=false <wait>",
        "debconf/frontend=noninteractive <wait>",
        "console-setup/ask_detect=false <wait>",
        "console-keymaps-at/keymap=us <wait>",
        "<enter><wait>"
      ],
      "boot_wait": "{{ user `boot_wait` }}",
      "disk_size": "{{ user `disk_size` }}",
      "format": "ova",
      "guest_additions_path": "VBoxGuestAdditions_{{.Version}}.iso",
      "guest_os_type": "Debian_64",
      "headless": "{{ user `headless` }}",
      "http_directory": "http",
      "iso_checksum_type": "sha512",
      "iso_checksum_url": "{{ user `iso_checksum_url` }}",
      "iso_urls": [
        "iso/debian-{{ user `debian_version` }}-amd64-netinst.iso",
        "{{ user `mirror` }}/{{ user `debian_version` }}/amd64/iso-cd/debian-{{ user `debian_version` }}-amd64-netinst.iso"
      ],
      "output_directory": "output-{{ build_name }}",
      "shutdown_command": "systemctl poweroff",
      "ssh_password": "packer123",
      "ssh_timeout": "{{ user `ssh_timeout` }}",
      "ssh_username": "root",
      "virtualbox_version_file": ".vbox_version",
      "vrdp_bind_address": "{{ user `rdp_bind_address` }}",
      "vboxmanage": [
        [
          "modifyvm",
          "{{ .Name }}",
          "--memory",
          "{{ user `memory` }}"
        ],
        [
          "modifyvm",
          "{{ .Name }}",
          "--cpus",
          "{{ user `cpus` }}"
        ],
        [
          "modifyvm",
          "{{ .Name }}",
          "--nic1",
          "nat",
          "--nictype1",
          "virtio"
        ],
        [
          "modifyvm",
          "{{ .Name }}",
          "--nic2",
          "hostonly",
          "--nictype2",
          "virtio",
          "--hostonlyadapter2",
          "{{ user `host_adapter` }}"
        ]
      ],
      "vm_name": "packer-{{ build_name }}"
    },
    {
      "name": "qemu-base-debian",
      "type": "qemu",
      "accelerator": "kvm",
      "boot_command": [
        "<esc><wait>",
        "install <wait>",
        "preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/qemu-preseed.cfg <wait>",
        "DEBCONF_DEBUG=5 <wait>",
        "debian-installer=en_US <wait>",
        "auto=true <wait>",
        "priority=high <wait>",
        "locale=en_US <wait>",
        "kbd-chooser/method=us <wait>",
        "keyboard-configuration/xkb-keymap=us <wait>",
        "netcfg/get_hostname=debian <wait>",
        "netcfg/get_domain=  <wait>",
        "netcfg/choose_interface=auto  <wait>",
        "fb=false <wait>",
        "debconf/frontend=noninteractive <wait>",
        "console-setup/ask_detect=false <wait>",
        "console-keymaps-at/keymap=us <wait>",
        "<enter><wait>"
      ],
      "boot_wait": "{{ user `boot_wait` }}",
      "disk_cache": "writeback",
      "disk_compression": true,
      "disk_interface": "virtio",
      "disk_size": "{{ user `disk_size` }}",
      "format": "qcow2",
      "headless": "{{ user `headless` }}",
      "http_directory": "http",
      "iso_checksum_type": "sha512",
      "iso_checksum_url": "{{ user `iso_checksum_url` }}",
      "iso_urls": [
        "iso/debian-{{ user `debian_version` }}-amd64-netinst.iso",
        "{{ user `mirror` }}/{{ user `debian_version` }}/amd64/iso-cd/debian-{{ user `debian_version` }}-amd64-netinst.iso"
      ],
      "machine_type": "pc",
      "net_device": "virtio-net-pci",
      "output_directory": "output-{{ build_name }}",
      "shutdown_command": "systemctl poweroff",
      "ssh_password": "packer123",
      "ssh_timeout": "{{ user `ssh_timeout` }}",
      "ssh_username": "root",
      "vnc_bind_address": "{{ user `rdp_bind_address` }}",
      "qemuargs": [
        [
          "-m",
          "{{ user `memory` }}"
        ],
        [
          "-smp",
          "{{ user `cpus` }}"
        ]
      ],
      "vm_name": "packer-{{ build_name }}"
    }
  ]
}

We use Debian 9.6 now, but we started with 9.5.

To be able to change version, mirror and checksum URL we expose the following user variables (ref: https://www.packer.io/docs/templates/user-variables.html).

"variables": {
  "debian_version": "9.6.0",
  "mirror": "http://mirror.host.ag/debian/debian-cd/",
  "iso_checksum_url": "http://mirror.host.ag/debian/debian-cd/9.6.0/amd64/iso-cd/SHA512SUMS"
},

And use them like this in the builders

"iso_checksum_type": "sha512",
"iso_checksum_url": "{{ user `iso_checksum_url` }}",
"iso_urls": [
  "iso/debian-{{ user `debian_version` }}-amd64-netinst.iso",
  "{{ user `mirror` }}/{{ user `debian_version` }}/amd64/iso-cd/debian-{{ user `debian_version` }}-amd64-netinst.iso"
],

It’s important to note that the first path in iso_urls allows us to use a local iso and skip the download. Useful if run in network bandwidth constrained environment.

We run the following shell provisioners (more about them at https://www.packer.io/docs/provisioners/shell.html)

  • virtualbox guest additions, if it’s a virtualbox image
  • QEMU guest agent, if it’s a virtualbox image
  • SSH authorized_keys configuration
  • disabling of LVM metad service
  • cleanup

The above provisioners are the ones that we must test.

Let’s first try running the packer build without tests in mind.

> packer build -var 'headless=true' \
-var 'host_adapter=vboxnet0' \
-only=virtualbox-base-debian \
-force packer-base-debian.json

The above will not run the test suite. It’ll provision from a Debian 9.6 ISO, unattended/automated installation of Debian with debian-installer preseed configuration.

We expect the following output

virtualbox-base-debian output will be in this color.
==> virtualbox-base-debian: Cannot find "Default Guest Additions ISO" in vboxmanage output (or it is empty)
==> virtualbox-base-debian: Retrieving Guest additions checksums
1 items:  4.47 KiB / 4.47 KiB [==============================================================================================================================================================================================================================================] 0s
    virtualbox-base-debian: Transferred: https://download.virtualbox.org/virtualbox/5.2.10/SHA256SUMS
==> virtualbox-base-debian: Retrieving Guest additions
    virtualbox-base-debian: Found already downloaded, initial checksum matched, no download needed: https://download.virtualbox.org/virtualbox/5.2.10/VBoxGuestAdditions_5.2.10.iso
==> virtualbox-base-debian: Retrieving ISO
    virtualbox-base-debian: Found already downloaded, initial checksum matched, no download needed: http://mirror.host.ag/debian/debian-cd//9.6.0/amd64/iso-cd/debian-9.6.0-amd64-netinst.iso
==> virtualbox-base-debian: Starting HTTP server on port 8361
==> virtualbox-base-debian: Creating virtual machine...
==> virtualbox-base-debian: Creating hard drive...
==> virtualbox-base-debian: Creating forwarded port mapping for communicator (SSH, WinRM, etc) (host port 3486)
==> virtualbox-base-debian: Executing custom VBoxManage commands...
    virtualbox-base-debian: Executing: modifyvm packer-virtualbox-base-debian --memory 512
    virtualbox-base-debian: Executing: modifyvm packer-virtualbox-base-debian --cpus 1
    virtualbox-base-debian: Executing: modifyvm packer-virtualbox-base-debian --nic1 nat --nictype1 virtio
    virtualbox-base-debian: Executing: modifyvm packer-virtualbox-base-debian --nic2 hostonly --nictype2 virtio --hostonlyadapter2 vboxnet0
==> virtualbox-base-debian: Starting the virtual machine...
    virtualbox-base-debian: The VM will be run headless, without a GUI. If you want to
    virtualbox-base-debian: view the screen of the VM, connect via VRDP without a password to
    virtualbox-base-debian: rdp://127.0.0.1:5958
==> virtualbox-base-debian: Waiting 5s for boot...
==> virtualbox-base-debian: Typing the boot command...
==> virtualbox-base-debian: Connected to SSH!                                                                           
==> virtualbox-base-debian: Uploading VirtualBox version info (5.2.10)                                              
==> virtualbox-base-debian: Uploading VirtualBox guest additions ISO...                                                  
==> virtualbox-base-debian: Provisioning with shell script: ./files/base-debian/00_guest_additions.sh
<omitted output for readability>
==> virtualbox-base-debian: Provisioning with shell script: ./files/base-debian/01_ssh.sh
<omitted output for readability>
==> virtualbox-base-debian: Provisioning with shell script: ./files/base-debian/02_disable_lvmetad.sh 
==> virtualbox-base-debian: Provisioning with shell script: ./files/base-debian/03_logging.sh
<omitted output for readability>
==> virtualbox-base-debian: Provisioning with shell script: ./files/cleanup.sh
<omitted output for readability>
==> virtualbox-base-debian: Running local shell script: ./serverspec/sleep_before_tests_packer.sh
==> virtualbox-base-debian: Running local shell script: /tmp/packer-<omitted output for readability>
==> virtualbox-base-debian: Gracefully halting virtual machine...
==> virtualbox-base-debian: Preparing to export machine...
    virtualbox-base-debian: Deleting forwarded port mapping for the communicator (SSH, WinRM, etc) (host port 3486)
==> virtualbox-base-debian: Exporting virtual machine...
    virtualbox-base-debian: Executing: export packer-virtualbox-base-debian --output output-virtualbox-base-debian/packer-virtualbox-base-debian.ova
==> virtualbox-base-debian: Deregistering and deleting VM...
Build 'virtualbox-base-debian' finished.
==> Builds finished. The artifacts of successful builds are:
--> virtualbox-base-debian: VM files in directory: output-virtualbox-base-debian

If you see very similar to the above output — it’s working and we can move on to the actual test suite.

How to run the test suite

There were really only two choices:

  • Run the test suite on the guest
  • Run the test suite on the host

“Run the test suite on the guest”:

  • (+) No need to have runtime and dependencies on the host
  • (=) Have “bootstrap” script for runtime and dependencies to be provisioned and executed to the guest
  • (-) Have “cleanup” script to remove all runtime and dependencies and also the test suite output such as coverage reports
  • (-) More complex for scenarios where you want to extract test artifacts such as coverage reports
  • (-) Almost surely double-work in terms of cleanup

“Run the test suite on the host”:

  • (-) Need to have runtime and dependencies on the host
  • (+) No need to have “bootstrap” scripts for runtime and dependencies to be provisioned, executed and cleaned up from the guest
  • (+) Test artifacts such as coverage reports will be already present on the host and easier to feed to other systems
  • (+) No double-work and complexity of cleanup

Executing the strategy of choice — “Run the test suite on the host”:

We’re going to run the test suite via a shell-local provisioner (read more at https://www.packer.io/docs/provisioners/shell-local.html).

Since shell-local will run it from our host machine to the guest we need to solve two problems:

  1. what credentials we can use to execute shell commands on the guest to verify behaviour
  2. what’s the SSH IP and port we can use

The “1.” is solvable easily since we’re the ones creating and provisioning the image. For simplicity sake, we’ll use the root user — root and password packer123 .

About “2.”, though

If you’ve been using HashiCorp Packer for a while, you probably have read the chain of threads:

The verdict of that chain of threads — you can’t get your SSH communicator’s IP and port in the template.

Getting the IP and port of the guest created by Packer options

As the last choice regarding the testing strategy, this is also a binary choice.

Choice 1. Get the guest IP from the guest machine’s network interface

This can be done by executing a script with shell provisioner and retrieving the IP, saving the IP at for example /tmp/myip , downloading the file from the guest to the host using the file provisioner in download direction (read more at https://www.packer.io/docs/provisioners/file.html).

However, the above choice has a huge flaw — by default created guests have NAT-ed networking. You won’t be able to access them with their 10.x.x.x/8 CIDR IPs without extra hassle to port-forward SSH port 22.

Also if you don’t want to do the above, you can get away with using hostonly network adapters (as per VirtualBox terminology), but then you lose the ability to test NAT-only images.

Now let’s get to choice 2, which is the one we’ve picked.

Choice 2. Re-use Packer’s SSH port forwarding used for the SSH communicator

If we enable Packer to log with PACKER_LOG=1 and PACKER_LOG_PATH=packer.log we can parse the log file and the “verbose” output to get the following line

==> virtualbox-base-debian: Creating forwarded port mapping for communicator (SSH, WinRM, etc) (host port 3486)

We can know how to get the port now. We can parse it since the port will be changing always. We can use a static port, but this is sometimes too naive luxury in dynamic environments such as CI.

The SSH address is known from a log message like:

==> virtualbox-base-debian: Using ssh communicator to connect: 127.0.0.1

We won’t be parsing it since, so far based on Packer experience, it’s always going to be localhost.

This results in the following “glue” script used to make our test suite run against the guest (ref: https://github.com/syndbg/sumup-blog-hashicorp-packer-test/blob/master/serverspec/run_packer.sh)

#!/usr/bin/env bash
# NOTE: This file is run by packer provisioner `shell-local`.
# Tests on developer machines are run inside `serverspec` dir using `bundle exec rspec`.
# Arguments:
# $1 = file path to the image-specific spec to run inside serverspec dir
set -ex
if [[ "$MUST_RUN_TESTS" != "true" ]]; then
    exit 0
fi
LOG="packer.log"
ip_and_port="$(grep -F 'SSH handshake err: ssh: handshake failed: read tcp' "$LOG" \
    | pcregrep -o1 '\->([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5})' \
    | sort \
    | uniq \
    | head)"
if [[ "$ip_and_port" == "" ]]; then
    port="$(grep -F 'Found port for communicator (SSH, WinRM, etc): ' "$LOG" \
        | pcregrep -o1 'Found\s+port\s+for\s+communicator\s+.+:\s+([0-9]{1,5})' \
        | sort \
        | uniq \
        | head)"
if [[ "$port" == "" ]]; then
        port="$(grep -F 'Creating forwarded port mapping for communicator (SSH, WinRM, etc) ' "$LOG" \
            | pcregrep -o1 'Creating\s+forwarded\s+port\s+mapping.+\s+([0-9]{1,5})' \
            | sort \
            | uniq \
            | head)"
    fi
    # NOTE: Packer uses localhost almost always.
    # parse host from log message `Using ssh communicator to connect: ` only if needed.
    ip_and_port="127.0.0.1:$port"
fi
echo "Found IP and port in $LOG: $ip_and_port"
export TARGET_HOST=$(echo $ip_and_port | cut -d ":" -f1)
export TARGET_PORT=$(echo $ip_and_port | cut -d ":" -f2)
echo "Going to use host: $TARGET_HOST"
echo "Going to use port: $TARGET_PORT"
echo "Going to use user: $TARGET_USER"
cd ./serverspec && bundle exec rspec $1

(more cases are handled since QEMU and Virtualbox builders don’t have consistent log messages in between them)

We integrate the above run_packer.sh glue code in the Packer debian template using the following provisioner

{                                         
      "type": "shell-local",                    
      "command": "./serverspec/run_packer.sh ./spec/base_debian_spec.rb",
      "environment_vars": [                               
        "MUST_RUN_TESTS={{ user `must_run_tests` }}",
        "SUDO_PASSWORD=packer123",                    
        "TARGET_PASSWORD=packer123",                                
        "TARGET_USER=root",          
        "BUILDER_TYPE={{ build_type }}"        
      ]                        
    }

We specify whether to skip or run the test via Packer user variable must_run_tests specified like packer build -var must_run_tests=true|false and we explicitly give the BUILDER_TYPE via Packer template builtin variable build_type (read more about built-in template variables https://www.packer.io/docs/templates/engine.html).

The BUILDER_TYPE is going to be useful for us to test positively/negatively whether certain packages are present or missing if we use QEMU or VirtualBox based images.

The test suite structure:

serverspec
├── Gemfile
├── Gemfile.lock
├── run_packer.sh (the glue code)
├── sleep_before_tests_packer.sh (will be covered later)
└── spec
    ├── base_debian_spec.rb
    ├── goldenfiles
    │   ├── logging
    │   │   └── journald.conf
    │   └── ssh
    │       ├── authorized_keys
    │       ├── root_rsa.pub
    │       └── users_rsa.pub
    ├── spec_helper.rb
    └── support
        └── shared_examples
            ├── disable_lvmetad.rb
            ├── logging.rb
            ├── qemu_guest_agent.rb
            ├── ssh.rb
            └── virtualbox_guest_additions.rb

We follow proven best practices from http://betterspecs.org/.

We use bundler to manage our dependencies.

RSpec + ServerSpec (resources and command runner) are used to verify state.

We also use test if provisioned files match using golden files (https://softwareengineering.stackexchange.com/a/358792) via the https://rubygems.org/gems/rspec-golden-files gem.

Let’s look at our spec_helper.rb

# frozen_string_literal: true
require 'serverspec'
require 'net/ssh'
require 'rspec-golden-files'
Dir[
    File.expand_path(
      File.join(
        File.dirname(__FILE__),
        'support', '**', '*.rb'
      )
    )
].each { |f| require f }
set :backend, :ssh
set :sudo_password, ENV['SUDO_PASSWORD']
set :paranoid, false
options = Net::SSH::Config.for(ENV['TARGET_HOST'])
options[:user] = ENV['TARGET_USER'] if ENV['TARGET_USER']
options[:user] ||= Etc.getlogin
options[:port] = ENV['TARGET_PORT'] if ENV['TARGET_PORT']
options[:password] = ENV['TARGET_PASSWORD'] if ENV['TARGET_PASSWORD']
options[:auth_methods] = %w[password publickey]
set :host,        options[:host_name] || ENV['TARGET_HOST']
set :ssh_options, options
# NOTE: Disable sudo since it's not used.
# Tests are assumed to be run as root.
set :disable_sudo, true
if !ENV['BUILDER_TYPE'] || ENV['BUILDER_TYPE'].empty?
  raise 'no environment variable `BUILDER_TYPE` provided'
end
is_virtualbox = ENV['BUILDER_TYPE']&.start_with?('virtualbox')
is_qemu = ENV['BUILDER_TYPE'] == 'qemu'
RSpec.configure do |config|
  # NOTE: Disable `should` syntax.
  # Expect is the only absolute.
  # ref: http://www.betterspecs.org/#should
  config.expect_with :rspec do |expectations|
    expectations.syntax = :expect
  end
config.include RSpec::GoldenFiles
  config.filter_run_excluding is_virtualbox: !is_virtualbox
  config.filter_run_excluding is_not_virtualbox: is_virtualbox
  config.filter_run_excluding is_qemu: !is_qemu
  config.filter_run_excluding is_not_qemu: is_qemu
end
# Set environment variables
# set :env, :LANG => 'C', :LC_MESSAGES => 'C'
# NOTE: Set PATH since

We provide accurate SSH communication options via

options = Net::SSH::Config.for(ENV['TARGET_HOST'])
options[:user] = ENV['TARGET_USER'] if ENV['TARGET_USER']
options[:user] ||= Etc.getlogin
options[:port] = ENV['TARGET_PORT'] if ENV['TARGET_PORT']
options[:password] = ENV['TARGET_PASSWORD'] if ENV['TARGET_PASSWORD']
options[:auth_methods] = %w[password publickey]
set :host,        options[:host_name] || ENV['TARGET_HOST']
set :ssh_options, options

We exclude tests not applicable for non-QEMU or non-VirtualBox via RSpec exclusion filters (read more at https://relishapp.com/rspec/rspec-core/docs/filtering/exclusion-filters)

is_virtualbox = ENV['BUILDER_TYPE']&.start_with?('virtualbox')
is_qemu = ENV['BUILDER_TYPE'] == 'qemu'
config.include RSpec::GoldenFiles
  config.filter_run_excluding is_virtualbox: !is_virtualbox
  config.filter_run_excluding is_not_virtualbox: is_virtualbox
  config.filter_run_excluding is_qemu: !is_qemu
  config.filter_run_excluding is_not_qemu: is_qemu
end

Base-debian test file and how we mirror provision scripts with “mixin” tests

Our test is simply

# frozen_string_literal: true
require 'spec_helper'
describe 'base debian image' do
  include_examples 'virtualbox guest additions'
  include_examples 'qemu guest agent'
  include_examples 'SSH'
  include_examples 'disable lvmetad'
  include_examples 'logging'
end

This structure of extracting provision script test logic to shareable examples (read more at https://relishapp.com/rspec/rspec-core/docs/example-groups/shared-examples) allows us to change as fast and easy as you can remove provisioners from your Packer template.

Let’s look at our first included example “virtualbox guest additions” .

It needs to test the following provision script:

#!/usr/bin/env bash
echo "Installing VirtualBox guest additions"
apt install -y linux-headers-$(uname -r) build-essential
apt install -y dkms
VBOX_VERSION=$(cat /root/.vbox_version)
mount -o loop /root/VBoxGuestAdditions_$VBOX_VERSION.iso /mnt
sh /mnt/VBoxLinuxAdditions.run
umount /mnt
rm /root/VBoxGuestAdditions_$VBOX_VERSION.iso

The test file looks like (relevant ServerSpec resource docs at https://serverspec.org/resource_types.html)

# frozen_string_literal: true
require 'spec_helper'
RSpec.shared_examples 'virtualbox guest additions' do
  context 'when running in virtualbox guest', is_virtualbox: true do
    context 'with dependencies' do
      describe package('build-essential') do
        it { is_expected.to be_installed }
      end
describe package('dkms') do
        it { is_expected.to be_installed }
      end
describe 'package "linux-headers"' do
        it do
          kernel_version = command('uname -r').stdout.strip
          pkg = package("linux-headers-#{kernel_version}")
          expect(pkg).to be_installed
        end
      end
    end
describe file('/root/.vbox_version') do
      it { is_expected.to exist }
    end
describe kernel_module('vboxsf') do
      it { is_expected.to be_loaded }
    end
  end
context 'when not running in virtualbox guest', is_not_virtualbox: true do
    describe kernel_module('vboxsf') do
      it { is_expected.not_to be_loaded }
    end
  end
end

It’s important to note the is_not_virtualbox: true and is_virtualbox: true “tags” that are used for exclusion if it’s QEMU — we’re not going to test the is_virtualbox case at all. We’re only going to test the is_not_virtualbox one. For VirtualBox — the opposite.

And let’s see an example with a golden file, verifying that included example SSH matches the desired behaviour and guest state.

Provision script: (read more about PACKER_HTTP_ADDR at https://www.packer.io/docs/provisioners/shell.html#packer_http_addr)

#!/usr/bin/env bash
echo "Configure SSH keys"
apt update
apt install -y wget
wget http://${PACKER_HTTP_ADDR}/root_rsa.pub -O /tmp/root_rsa.pub
cat /tmp/root_rsa.pub >> /root/.ssh/authorized_keys
wget http://${PACKER_HTTP_ADDR}/users_rsa.pub -O /tmp/users_rsa.pub
cat /tmp/users_rsa.pub >> /root/.ssh/authorized_keys

root_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmauj4TaqalXVBnrMPSCaWx47EWqw7VE7H4fxp78YqUaNzhz1Y7f+BVmGCVCzvLMWF5PK+Yx66QuOu/R1xVRoyZRMn19QR/Roy7SKKbPT5GR//MP9NM9X78safSs318CRPsKKkkz5N2Qjv0nl5KzUtg6X3oKhgEptRIMnMu5y6lj2MxVxtKPVDLBm/vFiR6AzpN8/0/gD/mOgYpwbj0eOUZUy4I+HCovTFqQDhredvaS2h5ugyRL9EsoFSVVbgkdtNpk1HKjNf1bI0dEELgCxGlgG2cdnQXOYrtFX+Q3+0Y/bv3ruO43GsI88QuByHNR4okUnEkb0svQhQg2X8Z2fP root@example.com

users_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJJO1eEqDdRf2sJRt6cuaKxDYxfO4rU4EL4Q29zaCuc4l/YVzGKasmq43griT5QbmYS4K+xgVxwAgfgBZ7CsqQuv85KoJqjZFAjehptEUUtiIeZzvFTKd2nsfGzoR+UGzI5hjyJIglzilpqpUL2FseQzHFBne66kokzv1vAMe6kBMOaqflw1CaurAP6R64sAsIwaLRjmaCzpoWyFCjy4m4Lj5LV41GGHusDt3ASJnZwwTWPKxPH6BMlWgCWmHH6y8sqVxLyOaJYnXXJE3hdnxdbJ2UWgigJEjHakFU2HGPF0AWJV585xG1fY89U635fsMZ2lFThKIDN367KUTPz6Sb users@example.com

Then our test file looks like

# frozen_string_literal: true
require 'spec_helper'
RSpec.shared_examples 'SSH' do
  describe package('wget') do
    it { is_expected.to be_installed }
  end
describe 'contents of authorized_keys' do
    it do
      guest_file = file('/root/.ssh/authorized_keys').content
expect(guest_file).to match_golden_file('spec/goldenfiles/ssh/authorized_keys')
    end
  end
end

We use match_golden_file to match the following golden file

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmauj4TaqalXVBnrMPSCaWx47EWqw7VE7H4fxp78YqUaNzhz1Y7f+BVmGCVCzvLMWF5PK+Yx66QuOu/R1xVRoyZRMn19QR/Roy7SKKbPT5GR//MP9NM9X78safSs318CRPsKKkkz5N2Qjv0nl5KzUtg6X3oKhgEptRIMnMu5y6lj2MxVxtKPVDLBm/vFiR6AzpN8/0/gD/mOgYpwbj0eOUZUy4I+HCovTFqQDhredvaS2h5ugyRL9EsoFSVVbgkdtNpk1HKjNf1bI0dEELgCxGlgG2cdnQXOYrtFX+Q3+0Y/bv3ruO43GsI88QuByHNR4okUnEkb0svQhQg2X8Z2fP root@example.com
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJJO1eEqDdRf2sJRt6cuaKxDYxfO4rU4EL4Q29zaCuc4l/YVzGKasmq43griT5QbmYS4K+xgVxwAgfgBZ7CsqQuv85KoJqjZFAjehptEUUtiIeZzvFTKd2nsfGzoR+UGzI5hjyJIglzilpqpUL2FseQzHFBne66kokzv1vAMe6kBMOaqflw1CaurAP6R64sAsIwaLRjmaCzpoWyFCjy4m4Lj5LV41GGHusDt3ASJnZwwTWPKxPH6BMlWgCWmHH6y8sqVxLyOaJYnXXJE3hdnxdbJ2UWgigJEjHakFU2HGPF0AWJV585xG1fY89U635fsMZ2lFThKIDN367KUTPz6Sb users@example.com

We’re going to skip reviewing the other test suite files, cause they won’t be that much different.

Executing the test suite

Since we chose to get the SSH IP and port from the packer log file, we must always run our tests with PACKER_LOG=1 and PACKER_LOG_PATH=packer.log (and `packer.log` must be in the same dir as the packer template).

Run the following command to create guest image with tests before exporting it:

PACKER_LOG=1 PACKER_LOG_PATH=./packer.log packer build \
-var 'must_run_tests=true' \
-var 'headless=true' \
-var 'host_adapter=vboxnet0' \
-only=virtualbox-base-debian \
-force packer-base-debian.json

We must see output very similar to the one below with a successful outcome

virtualbox-base-debian: base debian image
    virtualbox-base-debian:   when running in virtualbox guest
    virtualbox-base-debian:     with dependencies
    virtualbox-base-debian:       Package "build-essential"
    virtualbox-base-debian:         should be installed
    virtualbox-base-debian:       Package "dkms"
    virtualbox-base-debian:         should be installed
    virtualbox-base-debian:       package "linux-headers"
    virtualbox-base-debian:         should be installed
    virtualbox-base-debian:     File "/root/.vbox_version"
    virtualbox-base-debian:       should exist
    virtualbox-base-debian:     Kernel module "vboxsf"
    virtualbox-base-debian:       should be loaded
    virtualbox-base-debian:   when not running in qemu guest
    virtualbox-base-debian:     Package "qemu-guest-agent"
    virtualbox-base-debian:       should not be installed
    virtualbox-base-debian:   Package "wget"
    virtualbox-base-debian:     should be installed
    virtualbox-base-debian:   contents of authorized_keys
    virtualbox-base-debian:     should be matching golden file with name spec/goldenfiles/ssh/authorized_keys
    virtualbox-base-debian:   /etc/lvm/lvm.conf
    virtualbox-base-debian:     should contain "use_lvmetad = 0"
    virtualbox-base-debian:   File "/var/log/journal"
    virtualbox-base-debian:     should be exists
    virtualbox-base-debian:   File "/etc/systemd/journald.conf"
    virtualbox-base-debian:     should be matching golden file with name spec/goldenfiles/logging/journald.conf
    virtualbox-base-debian:   Service "systemd-journald"
    virtualbox-base-debian:     should be enabled
    virtualbox-base-debian:
    virtualbox-base-debian: Finished in 3.56 seconds (files took 0.18682 seconds to load)
    virtualbox-base-debian: 12 examples, 0 failures
    virtualbox-base-debian:
==> virtualbox-base-debian: Gracefully halting virtual machine...
==> virtualbox-base-debian: Preparing to export machine...
    virtualbox-base-debian: Deleting forwarded port mapping for the communicator (SSH, WinRM, etc) (host port 3462)
==> virtualbox-base-debian: Exporting virtual machine...
    virtualbox-base-debian: Executing: export packer-virtualbox-base-debian --output output-virtualbox-base-debian/packer-virtualbox-base-debian.ova
==> virtualbox-base-debian: Deregistering and deleting VM...
Build 'virtualbox-base-debian' finished.
==> Builds finished. The artifacts of successful builds are:
--> virtualbox-base-debian: VM files in directory: output-virtualbox-base-debian

Debugging the test suite

We’ve also added a provisioner that sleeps just before the test suite

{
      "type": "shell-local",
      "script": "./serverspec/sleep_before_tests_packer.sh",
      "environment_vars": [
        "MUST_SLEEP_BEFORE_TESTS={{ user `must_sleep_before_tests` }}"
      ]
    },

It just does sleep 99999 so that you can develop and extend the test suite without the machine existing on you and Packer removing the SSH port forwarding.

The above provisioner can be run using

PACKER_LOG=1 PACKER_LOG_PATH=./packer.log packer build \
-var 'must_sleep_before_tests=true' \
-var 'headless=true' \
-var 'host_adapter=vboxnet0' \
-only=virtualbox-base-debian \
-force packer-base-debian.json

Where to go from here

You have a good idea what we do in SumUp to test our images created via Packer.

We have a bit more complex image hierarchies and test suites, but they’re expanded upon this simple one.

You can use this one as a template.

Again, the source code is at https://github.com/syndbg/sumup-blog-hashicorp-packer-test

Thank you for your time, Anton.

Image creation and testing with HashiCorp Packer and ServerSpec was originally published in SumUp Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Optimize your JS code using Google's V8 internals]]> https://medium.com/sumup-engineering/optimize-your-js-code-using-googles-v8-internals-49955fd7d4a5?source=rss----bc8d70b3a259---4 https://medium.com/p/49955fd7d4a5 Mon, 17 Sep 2018 20:45:34 GMT 2018-09-17T20:45:34.513Z At BrazilJS 2018 this year in Porto Alegre, Mathias Bynens (a V8 developer at Google) shared some insights for code optimization if you are using (and you probably are) the V8 engine for Javascript. Here's what I learned.

For those who haven't heard of it, Google’s V8 is an open source JavaScript engine written in C++ developed by The Chromium Project for Chromium and Google Chrome web browser. It means that when you use Chrome and it detects JavaScript code, it passes that code to V8 to run the compilation and then your computer executes the result. It's also the cornerstone of the popular backend framework called Node.js.

In this post, we’re going to see how V8 optimizes your code using a primitive called element kinds.

When you run JavaScript and assign variables in it, the V8 engine keeps track of the value types you're saving in memory besides the value itself. These value types are the element kinds we're talking about. Take this array as example:

const myArr = [1, 2, 3]

At the language-level, it's all Numbers to JavaScript for it doesn't make distinction between integers, floats or doubles. But internally it does much more than that: V8 also identifies that it contains only integers and assign PACKED_SMI_ELEMENTS to myArr.

Forget PACKED_ portion for now…

Common Element Kinds

SMI_ELEMENTS means it contains only SMall Integers and it can make optimizations when you're accessing it later. However, as soon as you add 3.14 to that array, it becomes PACKED_DOUBLES_ELEMENTS immediately and it can never go back to PACKED_SMI_ELEMENTS no matter what you do. If you go further and add 'x' it is demoted to PACKED_ELEMENTS and becomes even more generic!

const array = [1, 2, 3];
// elements kind: PACKED_SMI_ELEMENTS
array.push(3.14);
// elements kind: PACKED_DOUBLE_ELEMENTS
array.push('x');
// elements kind: PACKED_ELEMENTS

That's the first thing you have to keep in mind:

Rule 1: Always try to be as high as possible in the pyramid of element kinds

Element kinds pyramid used to classify array of objects in JavaScript. The higher the objects are in pyramid the more optimized it is when doing operations on it afterwards. (got from Mathias Bynens's slides)

Before digging into how V8 makes these optimizations, let's unbox that PACKED_ portion we left aside.

Holey vs Packed

So far, our array values are [1, 2, 3, 3.14, 'x'] and is considered by V8 engine as PACKED_ELEMENTS at this point. Now, consider this line of code:

myArr[9] = 1

Our array has holes from index 5 to 8

We've demoted myArr even more. It's now considered a HOLEY_ELEMENTS since it contains undefined values and it can never becomePACKED again. So we end up with this elements kinds lattice.

Elements Kinds Lattice (Source: https://v8project.blogspot.com/2017/09/elements-kinds-in-v8.html)

It's only possible to transition downwards. If you want to have PACKED_SMI_ELEMENTS again you must create a brand new array containing only integers with no holes in it. Hence…

Rule 2: Always try to make your elements packed from the very beginning

Take a look at this piece of code:

const array = new Array(3); // HOLEY_SMI_ELEMENTS
array[0] = 'a'; // HOLEY_ELEMENTS
array[1] = 'b'; // HOLEY_ELEMENTS
array[2] = 'c'; // HOLEY_ELEMENTS (still!)
Array values at the end of the code

Even though array is fulfilled, it's not possible to transition back to PACKED. It's too late and array is still a HOLEY_ELEMENTS kind.

Optimizations done in V8

Let's go for the fun part! And for this, I'm going to propose something different, let's invert the roles now: imagine you are the developer behind V8 engine and you must make V8 respond properly to JS code (come on you can do it!). Let's recap:

myArr is [1, 2, 3, 3.14, 'x', undefined, undefined, undefined, undefined, 1]. Indexes 5–8 are undefined because of the hole we created instead of having something assigned (we could assign undefined for example). Therefore there's nothing in its memory addresses but we know JavaScript must return undefined in this case.
I want to access myArr[8] which is a HOLEY_ELEMENTS. What you must do to ensure the return is undefined given you don't know much about myArr structure and you don't have this value properly saved in memory address?

Don't be so harsh on yourself and take some time to think about it… Ok, time's up!

If you guessed correctly, Google's V8 engine makes the following checks to make sure the value in myArr[8] is undefined considering it's a HOLEY_ELEMENTS kind:

  1. 8 >= 0 && 8 < myArr.length (boundary checks) returns true. So it's allowed to continue…
  2. hasOwnProperty(myArr, 8) returns false. Nope, it's not here, there's a couple of checks left to do…
  3. hasOwnProperty(Array.prototype, 8) returns false. Not here also, let’s try somewhere else…
  4. hasOwnProperty(Object.prototype, 8) returns false. Cannot find it anywhere. OK, let's return undefined then.
  5. Return undefined.

Seems like a bunch of duplicate checks, right? And, yes, it's kind of hard to guess straightaway. Now, let's take a look how it works for a different element kind. Consider the same example but for PACKED_ELEMENTS:

const packedArr = [42, undefined, 42];
packedArr[1];

V8 engine makes fewer checks:

  1. 8 >= 0 && 8 < packedIntArr.length returns true. Since it's PACKED, the value surely exists, you can return whatever you find in memory.
  2. Return undefined.
Even though the return value is the same, V8 has done far less work behind the scenes. Therefore, you may want to keep your data as packed as possible as well.

This performance also impacts on several other common operations:

  • Array.prototype.forEach
  • Array.prototype.map
  • Array.prototype.filter
  • Array.prototype.some
  • Array.prototype.every
  • Array.prototype.reduce
  • Array.prototype.reduceRight
  • Array#{find, findIndex}
Since Chrome version 70 all the operations listed above are already optimized inside their element kind. This means that if you want better performance, keep your data structure similar to its kind as possible.

Last but not least…

Rule 3: When you're iterating through your collection, avoid out-of-bound reads

Use whatever you prefer: array.forEach or item of array (both has the same performance nowadays) but avoid reaching out of bounds indexes like the code below:

for (let i = 0, item; (item = array[i]) != null; i++) { doSomething(); }

This pretty much concludes this type of optimization in the V8 engine. Of course, there are not only 6 elements kinds. There are 21 different elements kinds and each kind is optimized its own way, but I'm sure you'll start to pay more attention on how you define your data structure after reading this post through.

TL;DR

In order to let V8 engine make better optimizations on your JavaScript code, you may want to follow some guidelines when writing it:

  • Avoid element kind transitions
  • Avoid holes
  • Avoid out-of-bounds reads
  • Prefer arrays over array-like objects

All in all, write modern, idiomatic JavaScript and let the JavaScript engine worry about making it fast. Thanks Mathias to for the awesome talk at BrazilJS and for sharing your knowledge!

Optimize your JS code using Google's V8 internals was originally published in SumUp Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>