We’re proud of what we’ve accomplished: Our platform has been used to create more than ten million documents by small business owners and contractors around the globe. We’ve also built an amazing team and culture.

Today, we’re excited to share that we’ve been acquired by Dropbox and will be joining the Dropbox team. We share a similar goal to digitize, simplify and modernize work for customers in an increasingly distributed and virtual landscape. The combination of our vast template library with Dropbox’s robust document signing and sharing capabilities will help bring even more customers a solution for all of their agreement workflows. And we share common values: like us, Dropbox values people, and we’re excited to grow together!

We firmly believe that this is a natural next step in our journey and are thrilled to join forces with a respected, global technology brand. Thank you to all of our users, team members, and friends who have supported us throughout this amazing journey.

We’re excited for our next chapter!

We’ve Joined Dropbox! was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

My current test automation infrastructure requires that I allow traffic from my build server to reach my internal test servers. However my build server has a changing set of IP addresses it uses for its build machines. As a result I periodically get connection timeouts because new build machine IP’s are not in the current security group, while decommissioned build machine IP’s are.

Initially I updated this list manually and then re-applied Terraform code to update the security group. However I discovered that I could get a list of the build machine IP addresses through an API in JSON format. Additionally Terraform has a built-in HTTP client that can be used to get this list.

The HTTP data block below sets the URL and headers. The local variable stores the processed IP address list. In this example I need to transform each IP into CIDR format for the AWS Security Group. Then in the security group I can reference the local variable containing the new list. This updates each time terraform apply is run.

data "http" "build_machine_ips" {
  url = "https://dnsjson.com/DNS_NAME/A.json"

  request_headers = {
    Accept = "application/json"
  }
}

locals {

  # Excessive formatting is only for post. the following code
  # should all be one line.
  build_machine_ip_list = sort([ 
    for ip in jsondecode(
      data.http.build_machine_ips.body
      )["results"]["records"]:

      # Reformat list into CIDR notation for AWS
      "${ip}/32"
  ])
}

resource "aws_security_group" "build_machine_sg" {
  name        = "NetworkPorts"
  description = "Allow external access"
  vpc_id      = "xxxxxxxx" # Add your VPC

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "TCP"
    cidr_blocks = local.build_machine_ip_list
    description = "Access to internal servers from build machines"
  }
}

Now it updates automatically when the infrastructure is applied.

AWS Adventures: Adding a Dynamic List of IP Addresses to a Security Group Using Terraform was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your local development services can be up and authorized indefinitely for AWS. Role chaining? MFA tokens? No problem! Use aws-vault’s ECS Metadata Server and take restarts out of your workflow.

We use AWS for a variety of things here at FormSwift, including a few that are required for local development. We use aws-vault to safely manage individual identity accounts and only grant useful permissions to roles the individual developer assumes.

Additionally, for the past few months I’ve been working on revising our dev stack from a legacy hodgepodge of Vagrant boxes and separate Docker projects to a pseudo-monorepo using git submodules with one docker-compose.yml to rule them all (look for another article as this effort matures). One of the challenges I’ve faced in this project is that, while the straightforward aws-vault usage stays within a typical developer’s pain tolerance when applied to single services, using it for a whole bunch of services running in a single docker environment magnifies the inconvenience into a pretty poor developer experience.

In searching for a solution, I found a few thread comments here and there claiming it was possible, but precious little in the way of specifics. After spending a fair amount of time poring over the aws-vault source and chasing a few dead ends, I found an approach that works. I feel I would be remiss in not writing up the guide I couldn’t find a couple of weeks ago.

What is aws-vault?

The AWS CLI and assorted client libraries typically use environment variables to get their credentials, the most notable being AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. There are a few security concerns implied by the naive application of this pattern. The values are pretty impossible to remember, and annoying to copy/paste for every operation that needs them, which encourages people to do unsafe things like adding AWS credentials to their shell config. Additionally, when you use your own credentials directly, you’re typically providing them to code that is probably fine, but you also probably haven’t audited it for misuse of the credentials.

The aws-vault tool provides a few features that help to manage your credentials in a secure and consistent way. It achieves this with a few moving pieces:

Cooperation With AWS CLI: When you run aws-vault it uses the configuration in your ~/.aws directory to provide the information it needs about your account, roles and the like. You don’t even need the AWS CLI installed for aws-vault to consume its configuration files.

The Vault: Your real, persistent AWS credentials are added to a secure store, encrypted and password-protected. These are rarely exposed directly to a process. The vault can be backed by a number of different specific implementations. On a Mac, for instance, the default will be a Keychain. Because your credentials are in the vault, you do not need to add them to your account section in ~/.aws/credentials (and, in fact, should not). When using the AWS CLI by itself, your credentials file would often look like this:

[myaccount]
aws_access_key_id=AKIA****************
aws_secret_access_key=****************************************

When using aws-vault your credentials file can be as simple as this:

[myaccount]

Then instead of just running, say,aws s3 ls..., you will run aws-vault exec myaccount -- aws s3 ls.... Because aws-vault knows your credentials live elsewhere, it will prompt you for your vault password (if necessary) and find them there, then pass credentials on to the AWS CLI process as environment variables.

You can see what information aws-vault sends along to the consuming process like this:

$ aws-vault exec myaccount -- env | grep AWS

Temporary Credentials: By default, aws-vault automates the process of deriving temporary credentials from your real credentials using the GetSessionToken API of the AWS Security Token Service. These credentials are valid for twelve hours by default, but can be requested with validity ranging from fifteen minutes to 36 hours. It is these temporary session credentials that aws-vault uses for further operations. This reduces the severity of the breach in the unlikely event the consuming process does something bad that leaks the credentials it receives. You typically never see your actual account credentials again.

If for some reason you need your real credentials (read on to see one), aws-vault provides a way to bypass this automatic generation of temporary credentials using the --no-session flag. Suppose you ran this:

$ aws-vault exec --no-session myaccount -- env | grep AWS

You would see that the AWS credential environment variables are set to your actual key id and secret key. This, of course, disables some of the security aws-vault affords you, and should not be used without considering other ways of achieving what you want first and auditing what you do with the credentials once you have them.

Automatic Role Assumption: Your AWS environment may use roles your account can assume to acquire specific permissions, and aws-vault will read those roles out of your ~/.aws/config file and make them available. As a simplified example, your config file might look like this:

[default]
region = us-west-1

[profile myaccount]
mfa_serial = arn:aws:iam::012345678901:mfa/me

[profile local-developer]
source_profile = myaccount
role_arn = arn:aws:iam::012345678901:role/LocalDeveloperRole
mfa_serial = arn:aws:iam::012345678901:mfa/me

When you run aws-vault exec local-developer -- ... the local-developer profile will be dereferenced back through the temporary credentials and ultimately to your real credentials in the vault, so that the credentials the consuming process receives represent you operating under your organization’s LocalDeveloperRole.

This will also handle prompting for your MFA token as needed. By default aws-vault will prompt at the terminal, but there are other supported ways of providing the token. The --mfa-token (or -t) flag to aws-vault will let you supply the token on the command line. You can also add a credential_process that lets aws-vault prompt you with (among other options) a GUI popup. For example, on a Mac, you can add this line to your credentials or config file sections:

credential_process = aws-vault exec identity --json --prompt=osascript

This will invoke aws-vault's prompting mechanism to get the MFA token, which in turn we have configured to use osascript to pop up a Mac input dialog. This is handy for some IDE plugins that can’t prompt at a terminal.

Here there be dragons

For all the benefits aws-vault provides, it combines with some AWS behaviors to pose some significant problems for keeping a service running with authorization for long periods:

• The temporary credential returned by the GetSessionToken API can have a relatively long lifetime, but is always limited.
• Likewise, the AssumeRole API also returns a time-limited credential.
• Eventually, in a few hours, AWS will want you to provide your MFA token again to prove you can get new credentials.
• Even more restrictively, when you use a temporary credential to assume a role, you get only get one hour to work before your credentials go off. No, your friendly neighborhood devops engineer did not configure this short timeout because they hate you and want you to be sad. AWS considers this situation role-chaining and imposes the hard one-hour limit itself. It cannot be extended.

You can partly get around the one-hour limit using --no-session, but the other limits still apply, so if you aren’t restarting every hour, you’re at best restarting every other day or so. For someone (like me) who likes to keep a full environment running in the basement to offload resource use from the laptop, even this is a bit of a pebble in the shoe.

To infinity and beyond

Getting around the time limits here requires a few lesser-known features of aws-vault. There is a partial solution in the contrib/_aws-vault-proxy directory of the aws-vault repo. It’s similar to what I came up with in many ways (like, it probably would have saved me some time if I’d looked in the contrib directory earlier), but uses a little Go utility to do the work.

aws-vault as a service

There is an option to run aws-vault in a mode that emulates the metadata servers for either EC2 or ECS. In real AWS, the metadata servers are how your application gets information about its runtime environment, including its authorization.

You can get an EC2-style server with --server or an ECS-style server using --ecs-server. Because I’m working in a Dockerized environment, and because it seemed to offer a little more flexibility, the ECS server seemed the right choice here.

Once running, the server will dutifully spit out credentials on demand. Instead of providing AWS credentials directly to the application, you give the server URL using the AWS_CONTAINER_CREDENTIALS_FULL_URI environment variable. Many (but not all) AWS client libraries (including boto3 used in our Python services) already understand and respect this environment variable.

Here, too, there are complications. The ECS server binds to a random free port, and requires a random token in an Authorization header to work, which is provided in the AWS_CONTAINER_AUTHORIZATION_TOKEN variable. If aws-vault is running in a docker-compose service, the environment variables it supplies to its child process are hard to communicate to sibling services.

Authorization by proxy

To work around the environment variable issues, a reverse proxy was the silver bullet. In my implementation I chose tinyproxy due to its small size and ease of configuration for small-scale applications. The configuration for tinyproxy does not support environment variables, but even given that limitation it was easier to use a script that writes out the configuration and then launches the proxy than to use another solution.

Here, then, is my proxy.sh:

#!/usr/bin/env bash

cat > proxy.conf <<EOF
Port 80
Listen 0.0.0.0
AddHeader "Authorization" "${AWS_CONTAINER_AUTHORIZATION_TOKEN}"
ReversePath "/" "${AWS_CONTAINER_CREDENTIALS_FULL_URI}"
ReverseBaseURL "http://169.254.170.2/"
ReverseOnly Yes
EOF

tinyproxy -c proxy.conf -d

The service is thus exposed on the container’s HTTP port, which is proxied to aws-vault's random-port URL, and we inject the correct Authorization header so that other services do not need to know the token.

Note the hardcoded link-local IP address in the ReverseBaseURL. Although you could give this a domain name within the docker-compose network, boto3 (and maybe others — I haven’t checked) will only connect to metadata servers on 169.254.170.2 or 127.0.0.1, and the IP must be provided as such. A DNS name will be rejected even if it resolves to a supported IP address.

The authorization token is optional, and the header will only be sent from the client if the environment variable is set. Therefore, to give your other services access, you only need something like this in your docker-compose service definition:

environment:
  AWS_CONTAINER_CREDENTIALS_FULL_URI: http://169.254.170.2/

The client will see the URL variable set and hit the aws-vault service on port 80 to request a set of credentials, and the request will be proxied, with the authorization token added, to the actual random-port server running in the container.

You don’t know me

Now we’ve got a service to provide credentials, but we still need to get it authorized in the first place.

For the service to be able to generate a stream of updated credentials, it needs access to your real AWS credentials. One way to do this is by using --no-session:

$ aws-vault exec --no-session myaccount -- docker-compose up -d

This will supply your persistent AWS credentials to the docker-compose environment, and you will forward the credential variables into the aws-vault service. I supply them as build args because we can do most of the setup at build time and thus avoid having the credentials obviously visible in the container’s environment when you exec in. In docker-compose.yml:

services:
  aws_vault_server:
    build:
      context: ./aws_vault_server
      args:
        - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID:-}
        - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY:-}
        - AWS_USER=${AWS_USER:-}
    container_name: aws_vault_server
    networks:
      local_addr:
        ipv4_address: 169.254.170.2

  my_authorized_service:
    ...
    environment:
      AWS_CONTAINER_CREDENTIALS_FULL_URI: http://169.254.170.2/       
    networks:
      my_app_network:
      local_addr:

...

networks:
  my_app_network:
  local_addr:
    ipam:
      driver: default
      config:
        - subnet: 169.254.170.0/24
...

Notice how we define a network to serve the link-local address range the service needs to live in, and then explicitly assign the correct IPv4 address to the service in that network. The service that needs credentials will then need to be given the credentials URI as an environment variable, and will need to be attached to the link-local network in addition to the overall application network.

Then in aws_vault_server/Dockerfile:

FROM archlinux
ARG AWS_ACCESS_KEY_ID
ARG AWS_SECRET_ACCESS_KEY
ARG AWS_USER
ENV AWS_VAULT_BACKEND="file"
ENV AWS_VAULT_FILE_DIR="/root/.aws-vault"
ENV AWS_VAULT_FILE_PASSPHRASE="XXXXXXXXXXXX"
COPY files/ /
RUN AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
    AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
    AWS_USER=${AWS_USER} \
    /provision.sh
ENTRYPOINT ["aws-vault", "exec", "--ecs-server", "--debug", "local-developer", "--", "/proxy.sh" ]

The provisioning script is called with the ARGs supplied as environment variables at build time. A few other points worth noting:

• The AWS_USER argument is one I’ve defined to provide your AWS username, which is needed to set up MFA serials.
• I’m using archlinux as my base image because pacman has all the dependencies I’ll need for this container, including aws-vault, with minimal fuss.
• I’m configuring the container’s internal aws-vault to use the file vault backend, which is just a plain encrypted file supported on all platforms.
• For now I’m using a hardcoded password for the vault, but plan to tighten security a bit by generating a random password at build time. Keep in mind, though, that this is intended only for local development, and that anybody with access to the insides of your local container can also read the environment of the process pretty easily anyway.
• The ENTRYPOINT here shows how we launch the proxy inside the container, with an ECS server, under the local-developer role.
• NOTE: As-is, this won’t quite launch. It will complain that --ecs-server is not compatible with --prompt=terminal(the default). Don’t worry, we’re not done with this yet.

Provisioning the aws-vault server container

The provision.sh script called by the Dockerfile does some vital things:

#!/usr/bin/env bash

# install dependencies
pacman -Sy --noconfirm --needed \
  aws-vault \
  tinyproxy \
  which

# create config dirs
mkdir /root/.aws
mkdir /root/.aws-vault

# import aws config and add identity to vault from env
cat /tmp/credentials | sed "s/mfa\/$/mfa\/${AWS_USER}/" > /root/.aws/credentials
cat /tmp/config | sed "s/mfa\/$/mfa\/${AWS_USER}/" > /root/.aws/config
aws-vault add --env myaccount

1. First the script installs dependencies we need. The first two are obvious, but which is not included in Arch’s docker image, and is required by some other things we’ll be running.
2. We create .aws and .aws-vault directories in root's home directory. The .aws folder is similar to the one in your own home directory. The .aws-vault directory is just a convenient place to stash the file-backed credential vault.
3. We could certainly use the local ~/.aws, but I opted to create a more constrained version of the config that only contains the local-developer role profile that the aws-vault service is meant to run. To make it generic to the user, I stripped the username off the mfa_serial values and then I just append ${AWS_USER} again at build time to create a full ARN.
4. We install AWS credentials into the container’s file vault using the --env flag to aws-vault add. This causes the access key id and secret access key to be read from the standard environment variables instead of prompting the user.

As you can see from the ENTRYPOINT above, there is no longer any need to use --no-session inside the container. In an hour, when the current role credentials expire, aws-vault will just re-request your real credentials from the vault, generate a new session token, and be good for another hour. We’ve got the vault password in the environment, so no prompts for that either.

At this point we have a container that will continue generating credentials right up until aws-vault decides it needs your MFA token again, but that’s going to be relatively soon too, so there’s still one more thing to fix.

Here’s my number, so MFA me

You’ll recall I wrote earlier that there is a variety of “prompt” implementations available for aws-vault. You might be inclined to look for a way to use an environment variable or a script to get the token, and indeed it’s possible there’s a way to do it with credential_process, but I got an alternate solution working first.

One of the prompt methods aws-vault supports is pass, which is an open and highly Unix-ish CLI password manager backed by a GPG-encrypted store. Furthermore, there is a TOTP extension for pass, and aws-vault supports it. All we need to do is add our MFA seed to the pass vault and aws-vault can call that every time it needs to provide a new token.

Strangely enough, pass seems to be supported only for the MFA case, and not as a vault backing store, so we’ve got two credential stores going on in this container. Odd, but it works. The packages we need for this are also available in the Arch Linux pacman repo, so we only need a few modifications to get this working. In provision.sh:

# install dependencies
pacman -Sy --noconfirm --needed \
  aws-vault \
  pass \
  pass-otp \
  tinyproxy \
  which

...

# create the pass vault and insert the MFA serial
gpg --quick-gen-key --yes --batch --passphrase '' aws-vault
pass init aws-vault
pass otp insert aws-vault <<< ${AWS_MFA_URI}

In the Dockerfile for the vault service:

FROM archlinux
ARG AWS_MFA_URI

...

ENV AWS_VAULT_PROMPT="pass"
ENV PASS_OATH_CREDENTIAL_NAME="aws-vault"

...

RUN AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
    AWS_MFA_URI=${AWS_MFA_URI} \
    AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
    AWS_USER=${AWS_USER} \
    /provision.sh

...

And then in docker-compose.yml:

aws_vault_server:
  build:
    context: ./aws_vault_server
    args:
      - AWS_MFA_URI=${AWS_MFA_URI:-}

...

You’ll need to supply this environment variable (in addition to the credentials provided by aws-vault when building the vault service).

The AWS_MFA_URI value needs to be an otpauth URI, which you might have directly for some services, but if you only have the bare serial value (which, for AWS, you probably will), you can reconstitute a URI like this:

export AWS_MFA_URI="otpauth://totp/aws-vault?digits=6&secret=${AWS_MFA_SERIAL}&algorithm=SHA1&issuer=AWS&period=30"

You’re probably already using an MFA app (like Authy or Google Authenticator) to provide your MFA tokens, so you’ll need to reset your MFA to get your hands on the secret value. To do this:

1. Log in to your organizational AWS account. If you’re like us, managing your MFA token is one of the few things you’ll have direct authorization to do.
2. In the console’s top-right dropdown, select “Security credentials.”
3. On the resulting “My security credentials” page, scroll down to the “Multi-factor authentication (MFA)” section and click “Manage MFA device.”
4. Remove and recreate your MFA device. Record the generator secret before adding it back to your MFA app of choice.
5. This value will be the value of AWS_MFA_SERIAL in the URI construction block above.

Tying it all together

That’s pretty much it. To get the vault server running, you’d need to do something like this:

$ AWS_MFA_SERIAL="<your mfa secret>" aws-vault exec --no-session myaccount -- docker-compose build aws_vault_server

When this container comes up and you attach other services to it, it will continue to provide up-to-date credentials with no prompting for as long as the service is running.

Summary

To sum up, I’ll provide the complete example files we built up over the course of this article.

The docker-compose command above invokes your project’s docker-compose.yml:

version: '3.9'
services:
  aws_vault_server:
    build:
      context: ./aws_vault_server
      args:
        - AWS_MFA_URI=${AWS_MFA_URI:-}
        - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID:-}
        - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY:-}
        - AWS_USER=${AWS_USER:-}
    container_name: aws_vault_server
    networks:
      local_addr:
        ipv4_address: 169.254.170.2

  my_authorized_service:
    image: my_service_image:latest
    environment:
      AWS_CONTAINER_CREDENTIALS_FULL_URI: http://169.254.170.2/       
    networks:
      my_app_network:
      local_addr:

networks:
  my_app_network:
  local_addr:
    ipam:
      driver: default
      config:
        - subnet: 169.254.170.0/24

The aws_vault_server service invokes the corresponding Dockerfile:

FROM archlinux
ARG AWS_MFA_URI
ARG AWS_ACCESS_KEY_ID
ARG AWS_SECRET_ACCESS_KEY
ARG AWS_USER
ENV AWS_VAULT_BACKEND="file"
ENV AWS_VAULT_FILE_DIR="/root/.aws-vault"
ENV AWS_VAULT_FILE_PASSPHRASE="XXXXXXXXXXXX"
ENV AWS_VAULT_PROMPT="pass"
ENV PASS_OATH_CREDENTIAL_NAME="aws-vault"
COPY files/ /
RUN AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
    AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
    AWS_USER=${AWS_USER} \
    AWS_MFA_URI=${AWS_MFA_URI} \
    /provision.sh
ENTRYPOINT ["aws-vault", "exec", "--ecs-server", "--debug", "local-developer", "--", "/proxy.sh" ]

During build, the Dockerfile runs provision.sh:

#!/usr/bin/env bash

# install dependencies
pacman -Sy --noconfirm --needed \
  aws-vault \
  pass \
  pass-otp \
  tinyproxy \
  which

# create config dirs
mkdir /root/.aws
mkdir /root/.aws-vault

# import aws config and add identity to vault from env
cat /tmp/credentials | sed "s/mfa\/$/mfa\/${AWS_USER}/" > /root/.aws/credentials
cat /tmp/config | sed "s/mfa\/$/mfa\/${AWS_USER}/" > /root/.aws/config
aws-vault add --env myaccount

# create the pass vault and insert the MFA serial
gpg --quick-gen-key --yes --batch --passphrase '' aws-vault
pass init aws-vault
pass otp insert aws-vault <<< ${AWS_MFA_URI}

In addition to adding the auth secrets into local vaults, this will copy the basic config and credentials files into the appropriate location, while putting your AWS_USER into the mfa_serial values.

credentials:

[myaccount]
mfa_serial = arn:aws:iam::012345678901:mfa/
credential_process = aws-vault exec identity --json --prompt=pass

config:

[default]                                                                                                                                    
region = us-west-1                                                                                                                           
                                                                                                                                             
[profile myaccount]                                                                                                                           
mfa_serial = arn:aws:iam::012345678901:mfa/
                                                                                                                                             
[profile local-developer]                                                                                                                    
role_arn = arn:aws:iam::012345678901:role/LocalDeveloperRole                                                                             
source_profile = myaccount                                                                                                                      
mfa_serial = arn:aws:iam::012345678901:mfa/

At runtime, the aws_vault_server container will execute:

aws-vault exec --ecs-server --debug local-developer -- /proxy.sh

This launches an ECS-style metadata server using the vault-stored credentials for both keys and MFA, and then provides the server’s AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN in the environment for /proxy.sh:

#!/usr/bin/env bash

cat > proxy.conf <<EOF
Port 80
Listen 0.0.0.0
AddHeader "Authorization" "${AWS_CONTAINER_AUTHORIZATION_TOKEN}"
ReversePath "/" "${AWS_CONTAINER_CREDENTIALS_FULL_URI}"
ReverseBaseURL "http://169.254.170.2/"
ReverseOnly Yes
EOF

tinyproxy -c proxy.conf -d

Every time my_authorized_service needs credentials for an operation, it will send a request to http://169.254.170.2/. This request will be forwarded to the internal metadata server, which will (as needed) construct new role credentials based on your stored AWS credentials, and request a current MFA token from pass, and then return a JSON blob containing a current, valid set of service credentials within LocalDeveloperRole.

Other services that need local developer access will therefore always have it as long as aws_vault_server is running, QED.

I got the sense while browsing for this solution myself that this was not obvious to a whole lot of people. It certainly wasn’t to me. I hope this helps your dev teams get maximum bang for their aws-vault buck by reducing time spent hassling over credentials for local development.

And in case it isn’t obvious, don’t try to use this in a non-local context. It’s somewhat secure, but the protections are a screen door at best against a serious attacker. Your AWS deployments already have a real metadata server available to them.

Indefinitely Long-Lived AWS Sessions Using aws-vault and docker-compose: The Guide I Wish I’d Had was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

For this first article, I’d like to describe a little project I’ve just published called “api-flow.” The project was inspired by a problem my wife (a QA Automation lead at another company) was running into. For reasons that would make sense if I felt free to go into detail, her company has a truly staggering number of sites that do much the same thing for many different audiences, but are different enough to need a certain amount of distinct infrastructure. And to test all this she’d been given a Postman collection.

So let’s talk about Postman.

We love Postman. Most everybody uses it, even though most of us never use half of what it’s grown into, which I shall generously call “highly feature-rich.” What it doesn’t do so well is run in CI, or run literally hundreds of variations of the same thing. It’s a big, heavyweight desktop app, and however much you’ve developed that collection, you’ve still got a person sitting in a chair poking a button and looking at the results. This is not a good use of people’s time at scale.

The first thing I did, of course, was to look for alternatives to Postman that could run headlessly. I’m still convinced that there has to be one out there I didn’t happen upon, but most alternatives I found were also big, unwieldy desktop apps. I’d set out expecting to decide which of several existing tools filled this niche best, and was surprised to come up empty.

Therefore I did what any sensible person wouldn’t do, and made one.

It’s early days for api-flow, with lots of potential areas of improvement, but it does a few basic things pretty well. The project runs “Flows” that are sequences of “Steps.” A Flow and its associated Steps are defined in YAML. Each Step represents a single API call. The headers, URL and body for a Step’s request are templates populated from a few sources:

1. Any template variable can be satisfied by an environment variable. If an environment variable is defined, this takes precedence over most other sources.
2. When constructing a Flow, you can provide “profiles,” other YAML files that define a base set of variables accessible to every Step in the Flow.
3. Steps define “outputs,” which map variables to JSONPath expressions. These are used to extract values from JSON response bodies. The extracted outputs are thereafter available to use in subsequent steps.
4. Very simple functions, including user-defined ones, are supported for more complex cases. A simple built-in function, for example, renders a random UUID.

Flows can also depend on other Flows, which is a simple method for DRYing your Flow definitions. You can define a Flow that creates a user or logs in, and provides a session token as an output. Multiple other test cases can then depend on this common Flow and use its output.

When a Flow is complete, the instance still retains all of its collected outputs, still attached to their respective steps. You can use this to gather results for further processing, or you can assert on them in a unit test.

I have a few use cases in mind:

• Automating day-to-day workflows: For example, as soon as I get a minute I plan to take a stab at automating some deployment tasks using the GitHub and Travis APIs.
• Accelerating standard QA Automation: Instead of walking through the UI flow to create a particular server state over and over for multiple tests, you could use api-flow to create the prerequisite state directly, and then drive the browser to test the only actual functionality you care about.
• Testing API-only stories: Rather than providing browser- or Postman-based testing instructions for stories that have no UI component, you can provide a Flow, which consumes a standard environment profile and exercises the desired behavior. The Flow can be reviewed alongside your regular code, and can be built into a complete suite of API tests that will work in all your environments with very little coding. You can provide simple instructions for manual testers to run the Flow at the command line and verify the results.

The api-flow package can be found on GitHub and PyPi. For now it supports more or less exactly the set of features I have personally needed, but I look forward to growing it according to how it gets used, so feedback is highly encouraged.

Automate Your APIs With api-flow was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

The 2021 calendar year comes with changes to business owners’ taxes. The new IRS form 1099-NEC is how employers will report non-employee compensation, instead of reporting these payments in box 7 on Form 1099-MISC. Form 1099-MISC still exists, but it is just to list miscellaneous income, like prizes and awards or medical payments.

Additionally, a 1099-NEC form is still a different from a W-2, which is provided to employees whose taxes are withheld by their employer. A 1099-NEC will be provided to vendors or sub-contractors who worked for a period of time for an employer to complete a project, with total payments exceeding $600. Independent contractors or self-employed contractors must still fill out a Form W-9 offered by IRS in their tax forms section.

Employers, or payers, are required to file Copy A of the Form 1099-NEC with the IRS by January 31st, by mail or e-file.

1099-NEC Definition

The new Form 1099-NEC is for employers to document non-employee compensation for independent contractors and freelancers. Independent contractors must receive Copy B of the 1099-NEC in order to include it with their tax returns.

These conditions must be met to report payment for non-employee compensation:

• The payment made to someone other than an employee, such as an independent contractor or freelancer who completes a temporary assignment.
• The payment must be made for projects and services in the course of your trade or business.
• The payments made to the payee must be at least $600 during the year.

As aforementioned, payers are required to provide a Form 1099-NEC to the payee and file it with the IRS by January 31st of the following year.

1099-NEC Versus 1099-MISC

Prior to the 2020 tax year, payments made to independent contractors or self-employed contractors were reported in box 7 on Form 1099-MISC.

With the introduction of the 1099-NEC, the information reported on box 7 of the old 1099-MISC — namely payments totaling over $600 — will now be reported on the 1099-NEC.

The 1099-MISC still remains, but it will now just be used for reporting miscellaneous income, such as rent and healthcare payments.

Due to the anticipated confusion for the new form, there will probably be filers who need an extension to complete a 1099-NEC. For a taxpayer to file for an extension, they must meet the filing requirements from Form 8809. Here are some of the filing requirements:

• The filer suffered a catastrophic event in a federally declared disaster area that made the tax filer unable to keep their business operating or made the records they need to file taxes unavailable.
• Fire, causality, or natural disaster affected the operation of the filer, and;
• The death, contracting a serious illness, or unavoidable absence of the individual responsible for filing the information returns affected the business of the filer.

How to Fill Out a 1099-NEC

Both the payer’s and the recipient’s information includes both parties name, address, and taxpayer ID. Non-employee payment should include the total compensation for the past tax year. This amount is the gross proceeds.

As the payer, you will also need to include:

• Federal income tax withheld, if any
• An optional account number
• Check the FATCA filing box, if applicable
• State tax withheld, if any
• State/payer’s state number
• State income

Both parties involved provide their names, address, and taxpayer identification numbers. Non-employee compensation is listed in Box 1 of the form. This should be the total compensation for the past tax year in the form of gross proceeds.

It is important to note that Box 4 is for federal income tax withheld. Even though this is uncommon for most instances when you hire non-employees unless you received a backup withholding order for that person, backup withholding requires a payer to withhold tax from payments not otherwise subject to withholding. There is a list of backup withholding rules on the IRS website at IRS.gov.

Boxes 5 through 7 are listed for your convenience only according to the official instructions provided by the IRS website. You can use each set of boxes to provide information for up to two separate states. This information is found in the same instructions as the instructions for the 1099-MISC (directly below it).

Box 5 is for any state tax that you pay to the provider for their services if it is required by your state.

Box 6 is for you, as the payer to list the identification number of the state to which you are reporting the tax information.

Box 7 allows you to list the amount of the state payment.

1099-NEC Filing Rules for Employers

Regardless of the size of the business, the IRS states businesses should file a 1099-NEC form for each person whom they paid at least $600 if they:

• Performed services by someone who is not their employee (including parts and materials) by listing this in Box 1.
• Cash payments for fish or other sea-based life bought from anyone involved in the business of catching fish. An example of this is a restaurant that purchases fish from a fish market that may employ fishing boats.
• Made payments for legal advice from an attorney.

Businesses must also use the new Form 1099-NEC if they withheld any federal income tax under the backup withholding rules regardless of the type of payment made.

Sample 1099-NEC

The 1099-NEC is for non-employee compensation and is not for miscellaneous income. When you fill out a Form 1099-NEC you will fill out:

• The payers’ name, street address, city or town, state, country, zip code or foreign zip code, and telephone number.
• Box 1 is non-employee compensation listed as gross proceeds.
• Next, you will need to fill out the payer’s tax identification number.
• Then, include the Recipient’s tax identification number.
• Boxes 2 and 3 are left blank.
• Next, list the recipient’s name.
• Then, list the recipient’s full address including an apartment number or suite number, if necessary.
• Box 4 is used to list the amount of federal income tax withheld if any. When preparing tax forms for non-employees, federal income tax is often not withheld unless there is an order to do so by the court or the IRS.
• Next, list the recipient’s city, state, country, and zip code or foreign postal code.
• If you have an account number, you may include it toward the bottom of the form. This is an identifying number you assigned to identify the account.
• Box 5, 6, and 7 are optional for you. They are to use to document state tax withheld, state and payer’s number, and the state income.

A Step-by-Step Guide to Form 1099-NEC was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. More Targeted Problems to Solve

“Redesign Youtube.” “Create a recipe app for millennials.” “Design a health app.”

In classes and internships, my assignments typically spanned months in time and covered every step in the design process. The deliverable could look like 30+ screens.

Now, at work, I’m given more targeted problems. In a past assignment, I focused on this sample document section — just a small piece of this entire page.

My PM, Mike, revealed to me that more users clicked on the gray boxes within the document, which triggers nothing, than on the “Create Document” button, which triggers the desired next step.

A poor user experience if you expect something to be clickable and it isn’t, sure, but also how can we funnel more users into creating their document?

We landed on this:

When a user tries clicking anywhere on the document, the tool tip pops up exactly where a user is suppose to “Start”. Yup. That’s it.

While our solution seems simple, the thought process behind it was not.

Not too long ago, I would’ve thought that 3 full days on a simple pop up was overkill but the more experience I have, the more nuance I have to contemplate to get to the final solution.

Also instead of creating experiences and screens from scratch, I’m usually designing on top of or within current designs — iterating to optimize our product. This requires understanding constraints and how to more naturally integrate something new into something existing.

2. More Cases to Consider

“Should we have rounded or unrounded corners?”

In college, I focused much more on how designs looked than how they behaved. Even considering the UX, I’d mock up what was suppose to happen but not what could happen, the expected default version but not the exceptions and edge cases.

This meant that, in college, had I designed a dropdown field I would’ve stopped here:

I acknowledged the dropdown’s:

• Shape
• Border radius
• Border width
• Border color
• Font family
• Font size
• Font weight
• Icon

But… what happens after the dropdown has been clicked?

What happens after a choice has been selected?

What happens when the user wants to go back to double check their work and… “Wait, what was this state referring to?”

What happens:

• If an option is 40 characters long?
• If the user forgot to make a selection?
• If the user made the wrong selection?

How will this dropdown change if placed on a mobile screen, on a different colored background? Will users with accessibility issues be able to see, read, and click into it?

This is just a teaser of what our design team has had to ask in creating our new design system:

And there are constantly new cases or inconsistencies we’re discovering — a reminder that design, too, is a living being that changes and grows.

3. Compromising with Business & Engineering Goals

“Ads make it look so cluttered.” “Lets have these really cool animations as you scroll down.”

In college, I was like “Okay, there’s the business side and the engineering side too…I know…” But I didn’t know-know, ya know?

Design has to improve the user experience but it also has to benefit the business and be worthwhile enough to be developed by engineers.

At work, I helped redesign our Document Library. Given a page that mostly does the job already, how do we make a convincing enough case for updating it?

By splitting it up.

Because if at any step, the design fails —we can still pull back without engineers having invested too much effort, without the business having invested too many resources. Overall, less risk.

So the design will be rolled out in stages. In fact, the first update isn’t even noticeable at a glance because it’s a change to the behavior of the search bar.

If we find that users are more easily able to find and create the document they want, then we’ll give the UI a makeover:

We also have designs mocked up for the other pieces of this page but they’ll only get rolled out if certain metrics are achieved— an unthinkable concept for the college-designer-me…

4. Getting Hit with the User Feedback

“Nice presentation! Does anyone have comments or questions?”

👆That’s usually where it ends for design projects in schools or internships. But in a company, designs don’t just end with a prototype. Developing and releasing designs to actual users is just the beginning of a feedback loop that guides the iterative process.

I thought this could be best illustrated as a meme, and this is the first meme I’ve ever made. Wow. I am both proud and embarrassed by this feat:

Let me break it down for you…

Designing What You Want

You know what I want? This, this right here:

Quirky animations. Tasty colors. That sleek sans-seriff font. But alas I am not representative of our main user base…

Designing What the Users Think They Want

Users can be passionate about what works and what doesn’t work, mostly what doesn’t work. They love suggesting features they themselves would want. They might say things like,

“I like minimal design, no clutter.”

But also,

“Why is the button hidden? It should be easier to find.”

As designers, we’ll try our best to cater to the user — that’s our job— but it’s also our job to determine the right balance.

We need to ask: How much of a problem is this problem? Is it just a passionate few making it seem like a bigger problem than it actually is? And if we change this one thing, how will it affect the rest of the design? Is it worth it?

Designing What You Think the Users Want

Brittany, another Formswift designer, iterated a ton on this landing page for our new product.

We conducted many user interviews on it and the design evolved based on feedback. Even then a lot of assumptions had to be made around what information the user should see, in what layout, in which order, and how much.

Designing What the User Needs Based on the Actions They’ve Demonstrated by Using Your Product

Once that landing page went live, you know what ended up happening?

Only a couple people even scrolled past the fold. Almost all users clicked the “Start” button right away.

So more appropriately, the landing page should’ve looked like this:

Ha.

I’m (mostly) joking! But I hope you get the point.

Even as designers, who pride ourselves in user empathy, it’s easy to get caught up in the “ideal” user — one who will read through every single word, stare at every single illustration, and comprehend everything before moving to the next page.

But by utilizing feedback, we can create a stronger solution that takes into account users’ realistic behaviors and tendencies.

With all that said…

My “preachings” are my own learnings in disguise. I say my “own” but these learnings couldn’t be fully realized without my team — Mike, Brittany, Ronnie, and Elisa.

This is not an exhaustive list and experiences will undoubtedly vary. For context, this is the point of view I’m coming from:

• 🐻 I graduated from UC Berkeley, which offered no design major but a growing number of design classes and extracurriculars that I took part in. I had several summer design internships in the Bay Area.
• 🎉 I just passed my 1 year mark as a designer! I’ve taken time to reflect on learnings and observe patterns (which hopefully show through in this post) but I understand there’s a lot I still don’t know.
• 📑 I work at FormSwift, a San Francisco start up. We work on online legal and tax documents, e-signing, PDF editing — the whole shabang.

Congrats to the new wave of designers!

Your world is gonna get rocked! 🤘I think our #design channel says it best:

Dear New Grad UX Designers, was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my last post, I explained:

We just launched a new product. New to us. New to the industry.

This new product being…

The Template Builder…our crack at streamlining the back-and-forth paperwork process that hundreds of businesses waste hundreds of hours on. This product lets users add fields on top of their existing document to create one template that is reusable and easy for their recipients to fill out.

For the past few months, we’ve been trying to figure out the best way to introduce this product. This is just one of our many attempts.

Look here, look here!

Before we keep someone’s attention, we must first capture it. How? Well, people typically want to understand what’s relevant to them; and it’s easier for people to imagine how a new product can fit into their existing workflow than how their existing workflow can accommodate a new product.

So before we spew out messaging around our solutions and value props, we’ve got to call out the relevant users with workflows we can help streamline!

My Proposal

Of those who discovered the Template Builder, almost all came from spotting this page — a powerful leverage.

The original empty state has no mention of user groups so lets:

1. Highlight our 3 main user groups: Business, Real Estate, and Human Resources
2. Provide the most relevant sample document for each respective user group to convey “this is the type of document you need to upload” for the Template Builder to make sense
3. Convey that there is a recipient role because in user testing this crucial point was often missed

My design ended up looking like:

My Justification

I thought this proposal would work because:

1. More qualified uploads could come from more users realizing this product is relevant to them
2. More qualified uploads could come from users seeing examples of the right types of documents to upload
3. At the very least, I could filter out the wrong types of documents to upload

And…It failed!

In the 1–2 weeks that the new empty state was live, almost no one uploaded a correct PDF, our main success metric. Compared to the original empty state, our click rates on the “Try a Demo” CTA went down by about 50%, a secondary success metric.

Yikes. 🙃

What went wrong?

Hindsight is 20/20 so let’s backtrack. I’ll never know for sure but I did embarrassingly realize…

I went against all the advice I gave in my last post! Ha!

Advice #1: “If everything is important, then nothing is.”

When I was drafting what content I should include, I made a table to organize what relates to what and noticed a “formula”.

I thought:

Hey! Wouldn’t it be cool to have some fill in the blank layout like Mad Libs?

This could suggest that there are many different ways to use the product and the user can plug in their own use case.

The copy, below on the left, identified the user, their document, and their recipient. In the next iteration, below on the right, I wanted to also address the pain point.

Then I wanted to also specify what types of documents a user should be using with the Template Builder:

The example document, the recipient, the user group, the pain point, the types of document a user should be uploading — all thrown into the mix. I thought this was such a concise and efficient way to get our message across but the copy was trying to hit so many points that nothing landed.

Advice #2: Think inside the box. Use the constraints of what you’re working in to your advantage.

In the final version that went live on Formswift, I literally went outside the box. In hopes of being eye-catching, I think the visuals actually became distracting.

Because I didn’t use the constraints of a traditional empty state, typically a couple sentences of copy and 1 main CTA, my empty state resembled more of a landing page. This might’ve caused a disconnect —

Expectation: This is a lot to consume and a lot to interact with…
Reality: No, actually, it’s just an empty state.

Playing off the physical constraints of an empty state box, I could’ve created something like:

Advice #3: Make the obvious OBVIOUS.

What isn’t apparent right away is that the dropdown options are connected.

If a user clicked “Rental Application” in the first dropdown then “Tenants” would automatically get selected. The copy in the green CTA would also automatically change to “Try a Landlord Demo.” Each of the 3 different CTAs directs to a different sample document.

Because this relationship isn’t clear until a user clicks around (and chances are, they wont), it seems like there’s a lot of work to be done. The original empty state had 1 “Try a Demo” CTA. Now, 3? As Hick’s Law puts it:

Increasing the number of choices will increase the decision time logarithmically.

Other possible concerns: does it look like only these 3 documents would work? Does it look like we’re making the documents for you? What if the user doesn’t identify with any of the user groups?

The more chances for assumptions, the more chances for users to mis-assume and click out.

Final Takeaways

1. Sometimes, in this case, less is more!

2. It’s important to separate the idea from the execution. Although we learned that the highly-illustrated-double-drop-down-empty-state didn’t work, that doesn’t mean user personas don’t!

3. Last but not least, take this as a chance to reflect on your own work. Realize how challenging it is to remain consistent in ideals and how productive it can be to identify not just what failed by why.

Onwards and upwards! 📈

Get Your Hands Dirty

The Template Builder is very much here and alive if you want to play around with it. You’ll need an account first — it’s free!

Thankful

For my team — especially Elisa, Ronnie, and Brittany. ❤️

Contradicting My Own Design Advice was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

We just launched a new product. New to us. New to the industry. In our asking “how do we get people to use it?” we must first answer “how do we get people to understand it?”

So what’s this “new product”?

No, it’s not a coffee maker — it’s the Template Builder and it’s our crack at streamlining the back-and-forth paperwork process that hundreds of businesses waste hundreds of hours on.

This product lets users add fields on top of their existing document to create one template that is reusable…

and easy for their recipients to fill out.

The Analogy

With limited context, the first step to successfully using, no — just understanding, the Template Builder is uploading the right type of document. I mean…

Imagine filling a coffee maker with fruit and expecting a smoothie. You won’t get the type of drink you want and the coffee maker will seem useless.

In our case, the “Template Builder” is the “coffee maker” and “documents with blank fields for someone to fill out and send back” are the “coffee beans.” So peer evaluation forms, freelancing contracts, job applications — all different types of coffee beans and all qualified for the Template builder! A “fruit” would be any PDF you need to edit (we have a different tool for that.)

What’s Really Going On

Simply put, the Template Builder workflow looks like:

1. Upload a qualified PDF (“coffee beans”)
2. Add fields on top of the PDF to make the template
3. Send out the template
4. Receive responses from the template

Our data showed that:

• No one with an unqualified document completed this workflow
• Every person who finished this workflow started with a qualified document

So this current assignment is focused on increasing the number of qualified uploads because without the correct type of document, there’s little chance for the user to understand and continue on with the product.

Sample Document: Our First Attempt

We thought a sample document would be a good idea to test because this can:

• Serve as a demo of sorts, on-boarding even
• Explicitly illustrate the type of document users should be uploading
• Act as a perfect example of what the Template Builder can do
• Prevent users from uploading random documents just to test the new product out (which we saw happening) — the equivalent of adding fruit to the coffee maker!

After a couple weeks of testing the sample document that Ronnie (one of our designers) did, we realized that:

• Almost no one completed the instructions on the document
• A lot of the contract is cut out of frame
• There’s no clear starting point

And so we made the assumption moving forward that:

Users want to do as little as quickly as possible to learn about the new product; and they would rather upload their own documents right away.

Sample Document: Another Attempt

We saw some improvements in the number of qualified uploads and decided to squeeze more juice out of the sample document idea.

Update #1: Accommodating for Size Restraints

While reducing the negative space and font size of the sample document, I realized the sample document didn’t have to be the uploaded document — meaning, I could have a document within a document…

This would allow me to fit the first few instructions above the fold.

And the instructions could be placed right by what the instruction was referring to. For instance, the “Click Preview” instruction is positioned and pointing at the actual “Preview” button.

Takeaway: Think inside the box. Use the constraints of what you’re working in to your advantage.

Update #2: Guiding the User in the Right Direction

At first the copy was in a backward “7” layout, starting right to left then top-down. This felt unnatural, so I moved all the text into a single vertical column.

The instructions were made easier to find when they were grouped by a contrasting background color, a dark blue.

Lastly, I thought “Step 1, 2, 3…” could imply the starting point. I even circled the text in a bright red. But this “implicit” design requires an extra step of thinking for the user so I added the actual word “Start.” The text’s size, weight, and casing were all used to establish information hierarchy.

Takeaway: Utilize the natural flow of reading and visual perception to make the work you want your users to do less taxing. Oh, and make the obvious OBVIOUS.

Update #3: Reducing Action Steps and Copy

To reduce, we really had to prioritize what instructions were the most important.

We conducted many user interviews before we launched the product and realized the “Ah-ha!” moment is when users saw the “Preview” for what recipients see. This made labeling all the fields make sense. So the first two steps were dedicated to identifying and explaining the “Preview.”

From the previous sample document, we noticed that almost no users wanted to interact with the tools.

The most common action after leaving the sample document was uploading a document. We decided to make this experience even easier by having an upload at the very bottom.

Why not at the top with the rest of the prominent CTAs? We want to encourage users to upload a document but still, at the very least, glance through the sample document instructions before doing so.

Takeaway: “If everything is important, then nothing is.” If someone can only remember 1 thing about your teachings, what would you like it to be?

The Final Version & How We’ll Test It

So this is what we have for now.

We’ll look at how many users click “Upload” and, of these, how many upload a qualified document after viewing the sample document. We’ll also consider the number of clicks on “Preview” and pre-made fields and if any user makes their own field on the sample document.

Now, fingers crossed for correctly brewed coffee… 🤞☕️

Make Yourself a Cup of Joe

All this yibber yabber about the Template Builder… might as well link it here. You’ll need an account (it’s free!) and some coffee beans…

A Group Effort

A medium article and project not possible without the insight, guidance, and critiques from my team — especially Elisa, Ronnie, and Brittany. Thank you for the pep you give to my steps! 🤪

When Users Put Fruit In a Coffee Maker & Find The Appliance Useless was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

Methodology:

We wanted to see how much it would cost (in terms of fuel) to send the largest running US cargo ship to Puerto Rico from Florida with relief aid. We determined the distance between Florida and Puerto Rico to be 1149.537 miles. At .0046 nautical miles to the gallon, this trip would require 249899.347 gallons of fuel. At approximately $321 per gallon, the total amount to send this cargo ship of aid one-way would be $249,899.

Because of Trump’s recent statements regarding hurricane Maria and the ‘very large ocean’ between us, as well as ongoing news regarding his family’s travel expenditures, we decided to look at how many times the Trump family’s taxpayer-funded travel could have gotten the aforementioned cargo ship between Florida and Puerto Rico. We analyzed government reports on Trump family travel spending, and detailed each family member’s travel expenditures by occasion and cost to determine the total amount for each individual. Whenever possible we split up these travel expenditures by costs specific to airfare. We divided the total cost per individual by $249,899 to find out how many times (or how far) the cargo ship could get with just these funds.

Take President Trump for example. Trump took four trips to his Mar-a-Lago resort between February 3rd and March 19th. His airfare alone cost between $580,000 and $812,000 per trip. Trump’s non Mar-a-Lago travel expenses cost taxpayers a total of around $29,000,000, totaling around $32,000,000. When we divided this total by $249,899, we determined that Trump’s travel alone could have paid for a cargo ship to bring relief aid from Florida to Puerto Rico approximately 128 times.

Trump Family Travel vs Puerto Rico Aid Study was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the past few weeks, our world has been inundated with horrific natural disasters — Hurricanes Harvey, Irma, and Maria, the floods in Somalia, and the earthquake in Mexico. This nation did a great job of raising funds for Harvey and Irma relief, but in recent days the devastation that has hit Puerto Rico and its people, who are U.S. citizens, has gotten less attention than it deserves. Moreover, one of our team members, Marisabel Agosto is Puerto Rican and we want to help her, her family, and all of our fellow citizens out during these trying times. So, for the next month we will matching all contributions of up to $100 to the following organization for Maria relief efforts in Puerto Rico:

Unidos Por Puerto Rico — http://unidosporpuertorico.com/en/

To let us know about your donation either include @FormSwift in a tweet with your donation or send us an email with the receipt to jackson(at)formswift.com.

Thank you in advance for your consideration and help!

Sincerely,

All of us at FormSwift

FormSwift for Puerto Rico was originally published in FormSwift on Medium, where people are continuing the conversation by highlighting and responding to this story.