TDD with Firestore functions emulator

Having spent time running tests inside and outside Firestore’s emulator, I learned that using the emulator is more than 50% faster.

Here is the latest flow we are using at Circuit. If you know of a simpler way, please let me know at gus [at] getcircuit [dot] com.

Basic version

firebase emulators:exec --only firestore 'jest'

You can replace jest with the runner of your choice.

Abstract the emulator call

Install scripty:

yarn add scripty

Add an entry to package.json:

  "scripts": {
    "test": "scripty"

Create a directory called scripts in the root of your project.

Create a file with path and name scripts/test:

#!/usr/bin/env sh

firebase emulators:exec --only firestore "yarn jest $str"

Allow computer to run this file:

chmod 644 scripts/test

Now you can run yarn test and add anything you would add to the command, like yarn test --watch, yarn test /path/to/test.file.

Enable connecting with a browser’s debugger

Add an entry to package.json:

  "scripts": {
    "debug": "scripty"

Create a file with path and name script/debug:

#!/usr/bin/env sh

firebase emulators:exec --only firestore "node --inspect node_modules/.bin/jest --watch --runInBand $str"

Allow computer to run this file:

chmod 644 scripts/debug

Add debugger to any line of your Firestore code.

Run yarn debug — you can also pass a filename to focus on it right away.

Open your browers’s developer tools.

Click on the green cube (Node’s logo):

This will open the debugger and you’re ready to step debug your code.

Simple tips for applying for a new development job

For several years, recruiting has been a part of my job in software. A few times I’ve been on the other side, looking for a job myself.

There are many low-hanging-fruit-type tips that can really make a difference when we look for a job. By making mistakes myself, seeing them made while recruiting, and by talking to colleagues, it’s now possible for me to list a few. Some may seem obvious to you — if you haven’t yet recruited, you’re in for a surprise over how common they are, and how much they affect the chances of someone getting a great job.

Learn about the company first

Before starting your application, spend no less than an hour attentively studying the company. Go to YouTube, try to watch videos involving top leadership. Read articles and learn about the people there.

Apply only to companies you care about

If you are in full application mode, apply to no more than 3 companies per day. Ideally 1 company.

If the company’s purpose doesn’t resonate with you, recognize the fact and move on.

Look at companies’ careers pages

Several companies, often the best ones, don’t advertise open jobs. They have their own careers pages and, relying on their reputations, will wait for applications.

For people who like to work remotely, Remotive’s company list has been helpful to a few people I know:

Don’t wait to apply

Once you’ve learned about a company and feel enthusiastic about it, apply immediately. In the global development market, good companies receive hundreds of applications on the first day or two after they post a job.

Apply to many jobs

While not applying to just any open job, do apply to as many of them as you truly like. Statistically, odds are low that you will be called for one given opportunity.

Start early

If I am suggesting you do not apply to too many positions each day, but to apply to many positions, by consequence I am suggesting you start early in your job search. Maybe practicing going through recruiting processes even before you need or want to do it can be ideal.

No spelling or grammar errors

Make it perfect in the language the company operates in. Pay someone, or a service, if needed. Great companies will quickly screen out applications that have language mistakes. By writing minimally well, expect to go to the top 10% of all applications.

Add a Github link to your CV

This is a huge differential. Prefer Gitlab or Bitbucket? Great, use your favorite. Don’t have public repos? Add repos of things you study, it’s perfectly fine. Make sure you add very good READMEs enabling visitors to run and test your repos.

Nothing like relationships

All the above may not be necessary if you have good relationships with former colleagues. You may be sought out before you need to look for a job. For this to happen, it is not enough to be very proficient at the technical part, people have to like spending time with you.

Git basics while typing less

Very short git commands

As computer programmers evolve in their craft, they increasingly identify repetitive tasks at all levels. One of the most basic levels is typing on the keyboard. Some programmers choose to invest effort and minimize typing. I am one of those people.

Git commands are among the ones I use the most, as listed in decreasing order with the number of times for each:

1241 gc
637 gco
583 v
419 git
373 cd
368 rm
316 mv
302 yarn
299 gb
247 gto
215 ga
213 c
191 gst
136 bundle
124 ©
115 mkdir
114 cp
106 npm
106 gt

If you’d like to see yours, you can run the following on the terminal: history | awk 'BEGIN {FS="[ \t]+|\|"} {print $3}' | sort | uniq -c | sort -nr | head -n 20

Please note that the number 20 at the end is the number of results to retrieve.

Back to my own history, you can see that:

  1. I use a lot of aliases
  2. Most of them are git-related, and that’s why they start with a g; gc is git commit, gco is git checkout and so on.

Recently I have taken this to the extreme, and so far the results have been excellent. Below are the commands I am able to run:

c (git commit or git commit -m, depending on the args passed)

p (git push)

a. (git add .)

b (git checkout -b)

The c function works for the following cases:

  1. c (will open the text editor for a long commit message)
  2. c “Your commit message” (acts as an alias for git commit -m
  3. c Your commit message (the one I love as you just type c plus the message, and it works)

While p and a. are calls with no args, with b you must simply add a branch name.

These are extremely simple improvements to the flow, and together with many others that I created or that I use from libraries, they make the path from brain to computer shorter and more pleasant.

To see how these are implemented, please visit this gist:

The commands in the gist which are not defined in this file come from oh-my-zsh plugins.