Vue Basics

Vue provides a system that splits the view from the data. You utilize this mechanism as far as you need, with a complete split, or continue to intersperse your HTML with code.

Each .vue file contains both the HTML and code, which allows for some thought-locality – all the code that directly deals with the HTML is nearby. You can even use this mechanism internally in a source file, by breaking down your model with “local components”.

Each “Vue instance” is created with pre-defined properties, as provided by the data object provided to it. These properties (at instance creation time) are what it will track. If any new properties are added later, they are not “reacted” upon. Something to remember.

Populating Vue Components

In a component, you may want to display some data. This data can be populated in various ways:

• the data directly – {{ dataVariable }}
• computed (and cached) – {{ computeFunction }}
• method (not cached) – {{ methodFunction }}

As expected, the three ways are from the corresponding part in the code:

...
  data: () => ({
    dataVariable: null,
  }),
  computed: {
    computeFunction: function () {
      ...
    },
  },
  methods: {
    methodFunction: function () {
      ...
    },
  },

Passing Data to Components

When creating a “dynamic component” (my words), you may want to pass some reactive data to it. While this seems like it should be trivial (as of Vue 2.6.11), it was not.

In the component, we will use both props, computed, and watch.

For example, if you want to control “showing” and “hiding” the component…

  <v-dialog v-model="show">
...


...
  props: {
    value: Boolean,
  },
  computed: {
    show: {
      get () {
        return this.value;
      },
      set (value) {
        this.$emit('input', value);
      }
    },
  },
  watch: {
    show (value) {
      if (value) {
        // ... 'this.value' will be true, do work.
      }
    }
  },

And in the parent of the component…

  <MyComponent v-model="showIt"></MyComponent>

So in the parent, if the showIt variable is toggled, the component will react to the change and run some code, as well as trigger behaviors dependent on the show variable.

Since I haven’t kept track of the changes in how development using JavaScript has come since the early days, hopefully this provides some insight from an old-timer.

Getting Started

Since I want to build a standalone application, Electron is a very convenient way to go about it. This is a framework built upon Chromium so you can develop an application using Node.js, HTML, CSS, and JavaScript.

Now you ask, what is wrong with using native SDKs like GTK and Qt? I would rather not deal with the dependencies in building on multiple platforms, as well as dealing with the intricacies of GUI widgets. By leveraging HTML+CSS, building the front-end should be fairly cross-platform and straightforward.

So what are the problems I’m going to cover in this write-up?

• How to set it up.
• What do the parts all do?
• How do you publish/distribute?
• How do you run it?
• What does development look like?

We’ll be using Vue.js as the frontend framework. While there are many frameworks available to select from (React, AngularJS, etc), this seemed to be the best documented “from the ground up”. So here we are.

Installation

There’s no “right” way it seems to do all this, so let’s go with the general concensus and what seems easy so far.

First, get a Node.js environment set up, in whichever way you prefer.

Global Tools

Next, install Vue CLI (version 3), which is not used as a component in the project, but instead is used for setting up and building the project.

$ npm install -g @vue/cli

Install pnpm, which is a disk space efficient package manager.

$ npm install -g pnpm

Vue

With the prereqs installed, let’s set up the project, using default settings. I don’t know enough about the customizations, to do anything special.

$ vue create my-app
$ cd my-app

This will create the directory my-app, set it up as a git repository, and get Node.js install and configured. How convenient.

Let’s look at what’s there…

• babel.config.js – Babel is a transpiler, converting JavaScript into a version that is backwards-compatible in various environments. This is the main config file for the tool; no need to touch it.
• package.json – NPM package registry, which lists the packages necessary to run the project or perform development. We’ll be adding to this later.
• public/ – Directory to store static assets for the project.
• src/ – Directory to store “the code” for the project.

If you pnpm run serve at this point, we can serve up default contents in the “development build” environment, which can be accessed using your web browser. There’s not much to see here.

Electron Builder

Since we don’t intend to host this application somewhere and access via a web browser, we now integrate Electon into the Vue app. This is done by installing the electron-builder plugin.

$ vue add electron-builder

This added a few more files. Take a peek at the changes, and commit them to git.

• src/background.js – the source code for the Electron main thread.

If you pnpm run electron:serve at this point, we get the same default app, now in its own application context.

Vuetify

Finally, lets add Vuetify, which is a UI toolkit for Vue, which provides an implementation of the Material Design Specification.

$ vue add vuetify

Again, this changed or added a few more files. Commit them.

If you pnpm run electron:serve now, the application has prettified a little bit.

Build

Now, lets see what happens when we build this.

$ pnpm run electron:build

After a bit of churning, a dist_electron directory should be generated. This contains the binary packages that can be executed standalone. The linux-unpacked directory is of most use to me right now; tar it up and we have our application!

Development

Okay, now that we have the essentials out of the way, how do we turn this “Hello World” Electron-based application into something real?

Here are the main files that you’ll deal with first:

• src/background.js – Electron main process code. This handles creating the app and any non-rendering work you may be doing.
• src/main.js – App (renderer) process code. This is run in the application window via public/index.html.
• src/App.vue – The main Vue component.
• src/components/ – Additional Vue components.

For example, if you want to muck with how Electron renders the application, you would modify src/background.js.

In my application, I don’t need the menu bar, so I set the autoHideMenuBar option. I also wanted to save the window state, so I installed and hooked up the electron-window-state module.

The things for Vue are a bit more complicated to describe; the tutorials and examples are fairly well written, so use them before diving in. But some side notes for the beginner into NodeJS and Vue…

Global Application State

You can create an object in main.js that can be referenced in other components. This can make tracking global application state into one place.

# main.js

export const appData = {
  title: 'Foo',
  someVariable: false
}

# App.vue

export default {
  // ...
  data: () => {
    return appData
  }

Now that you have application state, you may want to poke at it in DevTools. I haven’t found a way that seems non-hacky, so here is the hacky:

# main.js

global appData = appData

Vue Notes

As Vue is a framework, it obviously has some new syntax to go with.

• element :property="method" – hook up method() to a property. The method is defined in the computed section.
• element @click – hook up some code to an action.
• {{ ... }} – execute some code

References

• https://developerlife.com/2018/08/22/vue-vueitfy-webpack/
• https://vuejs.org/v2/guide/
• https://electronjs.org/docs/api/browser-window
• https://linustechtips.com/main/topic/922311-vuetifyjs-conditionally-disabling-components/

In the past, I used a debootstrab schroot. But that’s a ton of configuration steps that can be easily avoided by using Docker!

Assuming you have Docker already installed… (make sure your user is in the docker group)

First, install the debocker package. It’s a helper tool to run all the necessary commands.

Next, download the sources you need (dsc, orig.tar.gz, debian.tar.xz, etc) for your package. In my case, I wanted to build the latest experimental yosys for 18.04.

$ cd testbuild

$ wget http://archive.ubuntu.com/ubuntu/pool/universe/y/yosys/yosys_0.8-1build1.dsc
$ wget http://archive.ubuntu.com/ubuntu/pool/universe/y/yosys/yosys_0.8.orig.tar.gz
$ wget http://archive.ubuntu.com/ubuntu/pool/universe/y/yosys/yosys_0.8-1build1.debian.tar.xz

$ dpkg-source -x yosys_0.8-1build1.dsc

$ cd yosys-0.8

# may need to fix the debian/changelog file

$ debocker build --image ubuntu:18.04

Assuming everything went okay, you should have a bunch of .deb files built!

Using trueprint and ps2pdf, we can generate something a little more convenient without sacrificing too much readability.

$ trueprint -C --I --n -G2 -2 filename.c | ps2pdf - output.pdf

There’s probably better ways these days, but this has held up over time.

Following the instructions at How to Make Hard Cider, and the 1G Big Mouth jar and carboy, the wife and I (mostly me) started our experiment…

Picked up a gallon of apple cider (juice) at Market Basket, making sure it was only pasteurized and had no preservatives. Also a can of frozen concentrate apple juice, and some “Whole Earth Stevia and Monkfruit” sweetener.

Found a stash of Red Star “Pasteur Champagne” wine yeast in the fridge, which had a best by date of Dec 2016. Figured it would still work, just not quite as active initially.

Remember to look in the random homebrew stuff storage bin for the other stuff.

Primary Fermentation

Mix per the instructions,

• 1G bottle of juice.
• 1/2 can of frozen juice concentrate.
• 1/4 tsp of Wyeast yeast nutrient.
• whole packet of yeast.

Put the jug in the corner; wrapped it in a blanket to block light.

Secondary Fermentation

After 2 weeks, transferred into the carboy, with no special additions. We wanted to have a baseline flavor profile for this batch.

Bottling

After 3 weeks (the beer going in parallel wasn’t stable yet), prepped for bottling. (Note: didn’t take a hydrometer reading; just assumed.)

Put ~25 packets of the sweetener (2g per packet) for the 1G batch. This was done by scaling up a 1oz taste measurement to the full 1G.

Added 1/4 can of frozen juice contentrate for carbonation priming.

Afterward

After 4 weeks, tasting time! Okay, well we forgot about it for a bit… So after ~8 weeks, we cracked open a bottle. It had nice carbination, tart and not that sweet. And hazy.

Next time,

• add pectic enzyme to make it clear
• first mix the sweetener packets in hot water to dissolve better; will try this first instead of adding more sweetener

Edit 2020-03-17: This has been obsolete for a while now. GitLab has baked-in LetsEncrypt infrastructure, so go use that!

• https://andrewsempere.org/blog/2018/11/01/Gitlab-LetsEncrypt.html
• https://github.com/tezcatlipoca/gitlab-letsencrypt

The two links above describe how to set up an auto-renewing LetsEncrypt SSL Certificate on gitlab pages. The instructions were easy to follow, and worked without any major fuss.

Since we’re using Hugo here, make sure the .gitlab-ci.yml file references the output path static/.well-known/acme-challenge.

The CI environment variables where you will configure CERT_DOMAINS, CERT_OPTIONS, and CERT_TOKEN is located in the project settings, under “CI / CD”. Make sure to set CERT_TOKEN as Protected!

Create a “Scheduling Pipeline”. In theory if I ever had multiple scheduled jobs, then each should have a JOBNAME variable to check against in the job configuration?

Lastly, create the “User Access Token”, with api scope. Make sure to save the token somewhere safe in case you accidentally lose it.

It looks like aguslr’s multibootusb project has taken the generalization much farther than I ever would have; GRUB is pretty flexible…

Note these steps are NOT compatible with Secure Boot! Make sure you disable it before using the drive. (It’ll bootload into grub, look okay, but nothing is functional!)

Automatic

If you trust a script to do it all for you, the makeUSB.sh script will do it all. If you don’t, then read on…

Manual Steps

Since the instructions rely on the ArchWiki to get a proper bootable USB set up, and those instructions are fairly lousy…

Set Up the USB Drive

We’ll need the following Ubuntu packages. They should already be installed.

• gdisk
• grub-pc-bin
• grub-efi-amd64-bin

First, wipe the USB drive to make sure we’re on a clean slate:

$ sudo dd if=/dev/zero of=/dev/sdc bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.134964 s, 4.0 GB/s
$ sync

Unplug and replug the drive.

On running gdisk, it’ll probably complain, as we just “corrupted” the disk…

 sudo gdisk /dev/sdc
 GPT fdisk (gdisk) version 1.0.3

 Caution: invalid main GPT header, but valid backup; regenerating main header
 from backup!

 Caution! After loading partitions, the CRC doesn't check out!
 Warning! Main partition table CRC mismatch! Loaded backup partition table
 instead of main partition table!

 Warning! One or more CRCs don't match. You should repair the disk!

 Partition table scan:
   MBR: not present
   BSD: not present
   APM: not present
   GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 2

Create three partitions. The values taken are as suggested on the ArchWiki.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-15794126, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-15794126, default = 15794126) or {+-}size{KMGTP}: +1M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): EF02
Changed type of partition to 'BIOS boot partition'

Command (? for help): n
Partition number (2-128, default 2): 2
First sector (34-15794126, default = 4096) or {+-}size{KMGTP}:
Last sector (4096-15794126, default = 15794126) or {+-}size{KMGTP}: +50M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI System'

Command (? for help): n
Partition number (3-128, default 3): 
First sector (34-15794126, default = 106496) or {+-}size{KMGTP}: 
Last sector (106496-15794126, default = 15794126) or {+-}size{KMGTP}: 
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 0700
Changed type of partition to 'Microsoft basic data'

This should leave us with the following partitions:

Command (? for help): p
Disk /dev/sdc: 15794160 sectors, 7.5 GiB
Model: USB Flash Drive 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): EAA36968-DD45-467C-815E-EE433EF4B872
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15794126
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096          106495   50.0 MiB    EF00  EFI System
   3          106496        15794126   7.5 GiB     0700  Microsoft basic data

Okay, lets get the partitions set up properly…

Command (? for help): r

Recovery/transformation command (? for help): h

WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 1 2 3
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): N

Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code (default EF): 
Set the bootable flag? (Y/N): N

Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default EF): 
Set the bootable flag? (Y/N): N

Creating entry for GPT partition #3 (MBR partition #3)
Enter an MBR hex code (default 07): 0B
Set the bootable flag? (Y/N): Y

Recovery/transformation command (? for help): x

Expert command (? for help): h

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdc.
The operation has completed successfully.

Finally it’s time to format the partitions:

$ sudo mkfs.fat -F32 /dev/sdc2
mkfs.fat 4.1 (2017-01-24)

$ sudo mkfs.fat -F32 /dev/sdc3
mkfs.fat 4.1 (2017-01-24)

And install GRUB on the data partition (sdc3), and EFI on the ESP partition (sdc2)

$ mkdir /tmp/usbdat /tmp/usbefi

$ sudo mount /dev/sdc2 /tmp/usbefi

$ sudo mount /dev/sdc3 /tmp/usbdat

$ sudo mkdir /tmp/usbdat/boot

$ sudo grub-install --target=i386-pc --recheck --boot-directory=/tmp/usbdat/boot /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.

$ sudo grub-install --target=x86_64-efi --removable --recheck --boot-directory=/tmp/usbdat/boot --efi-directory=/tmp/usbefi
Installing for x86_64-efi platform.
Installation finished. No error reported.

$ sudo umount /tmp/usbefi

$ sudo umount /tmp/usbdat

$ sudo rmdir /tmp/usbefi /tmp/usbdat

Whew. Now that GRUB is installed, we can deal with installing a GRUB config and getting ISOs onto the disk.

Install MultiBoot USB

Unplug and replug the USB drive, to make sure the partitions are all loaded properly. If you have automounting, the data partition should mount.

Follow the steps on aguslr’s GRUB config install page.

$ git clone https://github.com/aguslr/multibootusb
Cloning into 'multibootusb'...
remote: Enumerating objects: 5227, done.
remote: Total 5227 (delta 0), reused 0 (delta 0), pack-reused 5227
Receiving objects: 100% (5227/5227), 4.22 MiB | 7.76 MiB/s, done.
Resolving deltas: 100% (3254/3254), done.

$ export mntusb=/media/usb partusb=/dev/sdc3
$ mkdir -p $mntusb/boot/{grub/mbusb.d/,isos}
$ cd multibootusb && cp -rf mbusb.cfg mbusb.d $mntusb/boot/grub/
$ cd multibootusb && cp -f grub.cfg.example $mntusb/boot/grub/grub.cfg

At this point I also modified mbusb.cfg to put /isos at the top level.

ISOs

Now download all the ISOs you desire into boot/isos, no cfg changes needed!

There are times when you want to not modify the contents of a directory directly when working within it. For example, when dealing with some projects that litter the working directory with object and temporary files.

In the past, I would have sudo mount an overlayfs (or unionfs). This would then require entering a password on mount and unmount, which was less than ideal.

With the addition of “user namespaces” (and some permissions), we can do this as a non-privileged user.

The Steps Described

To enter a namespace, use the unshare command. For the first stage, we need to create a namespace that hides mounts and provides root-like permissions.

unshare -rm

Once we’re in this namespace’d shell, we can run our mount command, whereas previously we would have to sudo mount it.

mount -t overlay overlay -o lowerdir=/path/to/lower,upperdir=/path/to/upper,workdir=/path/to/workdir /path/to/mnt

For reference,

• lowerdir – the (read-only) directory that is the basis for the content
• upperdir – the directory to write changes into
• workdir – a (empty) directory that overlayfs uses as a working area

At this point, you can do all your work in the mounted directory and be sure that changes are only reflected in the upperdir once you’re done with the mount.

Note: if the mount command generates a “special device overlay does not exist” error, check if you’ve typed the options and paths correctly. The message is a complete red herring…

However, there are cases where you do not want to run commands as fake-root, so you can create another (nested) namespace to put you back as your user.

unshare -U

After you’re all done, just back out of the (now two) shells, to get you back to the original shell. The mount is automatically cleaned up, and you can access see all the changes in the upperdir – and delete them all.

Automating the Steps

While running things manually is nice and all, I do this sufficiently that scripting it all is beneficial to my sanity.

First, we need a script that gets run under the fake-root namespace:

#!/bin/bash
mount -t overlay overlay -o lowerdir="$PWD",upperdir="$PWD.upper",workdir="$PWD.workdir" "$PWD"
if [ $? -ne 0 ]; then
  exit 2
fi

cd "$PWD"
unshare -U bash --init-file <(echo "PS1='overlay|\w> '")

And then you start it all by running unshare -rm overlay.sh, which leaves you with a shell in the mounted directlry.

More Automation

Is that not enough? Of course not – I had to run the first unshare command! I don’t want to remember that…

#!/bin/bash

# create working directory
rm -rf "$PWD.workdir"
mkdir "$PWD.workdir"

# wipe out any upper directory if it's already there!
rm -rf "$PWD.upper"
mkdir "$PWD.upper"

cat << EOM > "$PWD.script"
mount -t overlay overlay -o lowerdir="$PWD",upperdir="$PWD.upper",workdir="$PWD.workdir" "$PWD"
if [ \$? -ne 0 ]; then
  exit 2
fi

cd "$PWD"
if [ -z "$@" ]; then
  unshare -U bash --init-file <(echo "PS1='overlay|\w> '")
else
  unshare -U $@
fi
EOM

function finish {
  rm -rf "$PWD.workdir"
  rm -rf "$PWD.script"
  # keep upper around in case I want to poke at it
}
trap finish EXIT

unshare -rm bash "$PWD.script"

And then you run the script from the directory you want to overlay, providing an optional set of parameters in case you want to just execute things directly.

Sorry (to myself) if this is a bit rushed; didn’t write it all down (on mobile) during the install…

TL;DR

• Resized the Windows partition inside Windows.
• No grub/conf changes were needed to boot the ISO (in UEFI mode).
• Ubuntu installed using normal “alongside Windows” option.
• When “MOK Management” screen comes up, make sure to “enroll”.
• Follow post-install instructions for better power management.

Reduce Windows partition size

Used the notes from the internet about fully resizing the Windows partition:

1. Disable hibernation using powercfg /h off
2. Disable pagefile
3. Disable system protection

(Remember to reverse the steps after resizing.)

Install Ubuntu

Create a USB stick version of the Ubuntu Desktop 18.04 ISO, using the Ubuntu built-in creator tool.

Using F12 during system boot, trigger the “one-time boot” menu. Select the UEFI USB option. Installed as normal, with all the options: 3rd party software, updates during install, etc.

On the parititioning screen, selected the “alongside Windows” option. Installer properly configured a partition in the free space.

Note the Secure Boot instructions; wasn’t clear to me at first…

Restart and First Configuration

The first boot, the “MOK Management” screen will show up. Make sure to enroll your key.

Make sure both Ubuntu and Windows both boot properly from the GRUB screen.

Remember to fix Windows to use store the system time as UTC instead of local time:

Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_QWORD /d 1

Configure Ubuntu

Follow the post-install script to make sure power management runs well. (Went from ~2h to ~6h battery life.)

sudo add-apt-repository ppa:linrunner/tlp
sudo add-apt-repository ppa:graphics-drivers/ppa

sudo apt update

sudo apt install thermald tlp tlp-rdw powertop

sudo ubuntu-drivers autoinstall

sudo prime-select intel

Create /etc/modprobe.d/i915.conf with the following contents, then run sudo update-initramfs -u:

options i915 enable_fbc=1 enable_guc_loading=1 enable_guc_submission=1 disable_power_well=0 fastboot=1

Modify /etc/default/tlp and set RESTORE_DEVICE_STATE_ON_STARTUP=1.

Update grub options in /etc/default/grub, then run sudo update-grub:

GRUB_CMDLINE_LINUX_DEFAULT=quiet acpi_rev_override=1 acpi_osi=Linux nouveau.modeset=0 pcie_aspm=force drm.vblankoffdelay=1 scsi_mod.use_blk_mq=1 nouveau.runpm=0 mem_sleep_default=deep

Install libinput-gestures to get additional touchpad gestures support. Decided not to install the GUI, as the config file defaults (/etc/libinput-gestures.conf) was sufficient.

sudo apt install libinput-tools xdotool wmctrl
git clone https://github.com/bulletmark/libinput-gestures.git
cd libinput-gestures
sudo make install

Fix up fonts on GRUB and the console so it’s not so tiny (HiDPI screen).

sudo grub-mkfont --output=/boot/grub/fonts/DejaVuSansMono24.pf2 \
  --size=24 /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf

Then modify /etc/default/grub and change GRUB_FONT:

GRUB_FONT=/boot/grub/fonts/DejaVuSansMono24.pf2

For the console,

sudo dpkg-reconfigure console-setup

and select a font that is NOT ‘Fixed’, e.g. Terminus. When asked about font size, select ‘16x32’.

Ubuntu Packages and Stuff

Finally, configure dotfiles and install packages…

• git
• gnome-tweaks
• htop
• jsonlint
• libxml2-utils
• lighttpd
• moreutils
• net-tools
• network-manager-openconnect-gnome
• p7zip-full
• slack-desktop
• sshfs
• steam-launcher
• typora
• vim-nox
• xsltproc
• wireshark

And gnome extensions…

• Alternatetab
• Drop down terminal
• Lock keys

And gnome tweaks…

• Fonts > Window Title > Cantarell Bold 10
• Fonts > Interface > Cantarell Regular 9
• Fonts > Document > Sans Regular 10
• Fonts > Monospace > Monospace Regular 9
• Top Bar > Activities Overview Hot Corner > Off
• Top Bar > Date > On

So assuming the commands that are being performed are:

1. Go to the next difference, ]c
2. Copy from the other pane, do, or put to the other pane, dp
3. Repeat…

Though since you won’t know what to do about the next difference until you see it, it is probably better to swap the command order…

So you’d record the macro (live) using the q command to register a…

qa
do
]c
q

Now that you have the macro recorded, use @a to run the macro, and @@ to repeat the macro. If you can see ahead, save yourself some repetitive typing and repeat the command (e.g. 3@@).

To save/load the macro, see the URL; I haven’t needed it yet…