For context, here's what an example of calling this function might look like:

const routes = defineRoutes((route) => {
  route("users", "user.js");
  route("users/:id", "userShow.js");

  route("companies/:id", "companies.js", () => {
    route("users", "companyUsers.js");
    route("stores", "companyStores.js");
    route("stores/:id", "companyStore.js", () => {
      route("products", "companyStoreProduct.js");
    });
  });

  route("roles/:id", "roles.js", () => {
    route("users", "usersForRole.js");
  });
});

console.log(routes);
// output
[
  { path: "users", file: "user.js" },
  { path: "users/:id", file: "userShow.js" },
  { path: "companies/:id", file: "companies.js" },
  { path: "companies/:id/users", file: "companyUsers.js" },
  { path: "companies/:id/stores", file: "companyStores.js" },
  { path: "companies/:id/stores/:id", file: "companyStore.js" },
  { path: "companies/:id/stores/:id/products", file: "companyStoreProduct.js" },
  { path: "roles/:id", file: "roles.js" },
  { path: "roles/:id/users", file: "usersForRole.js" },
];

As you can see, top level routes are stored as-is but as you nest routes deeper and deeper within the route callback function you can build off of the parent path without having to type it every time.

There's a few different concepts you have to deal with while implementing this which makes me think it would make a great interview question to pair on with a candidate.

I'll post my solution below here, but try it out yourself before looking at mine and let me know how it went! Make sure to test it against multiple side-by-side nestings like I did above to make sure your paths are building properly.

function defineRoutes(cb) {
  const routes = [];
  let parent = "";

  function pathWithParent(path) {
    if (parent) {
      return `${parent}/${path}`;
    }
    return path;
  }

  function route(path, file, nestedCb) {
    routes.push({ path: pathWithParent(path), file });
    if (nestedCb) {
      parent = pathWithParent(path);
      nestedCb();
      parent = parent.slice(0, -(path.length + 1));
    }
  }

  cb(route);

  return routes;
}

1. Make sure git is installed
2. Tell git who you are (via git config)
3. Make commits
4. Push to GitHub

Which up until a few weeks ago this is how I would go about it too.

Then one day I was making a change to a repo via GitHub's online editor and noticed the little "verified" badge next to the commit. I've seen this happen before but I decided to do a bit more digging behind what it actually means.

The "verified" badge on GitHub tells us that they have verified that this commit actually came from us. How did they do that? Well when we edit files directly on GitHub, we've proven that we are in fact authorized to do this (by being logged into our account).

But how does GitHub know that the commits coming from your computer were from you?

If you followed the setup steps above, they actually don't.

When you're viewing the commits in a GitHub repository you can see the author's name, avatar, etc. But where are these pulled from?

Well, when we set up our git config (step #2 above), we tell git who is authoring commits made on our machine via:

$ git config --global user.email "you@example.com"   
$ git config --global user.name "Ozzie Neher"

Now whenever we run git commit -m "Whatever" git will mark that commit with the email and name we provided it as the author.

When we push to GitHub, they look at the authors email and use the GitHub user with a matching email to show up in the commit log.

But wait, we didn't even need to enter a password or anything?!

Yup.

You might be thinking about how GitHub sometimes asks you for a password when you run git push but this is not to verify the commit history, this is only to verify that you can modify the remote repo you are pushing to.

Now think about how this could be used maliciously.

Say I find Tim Cook on GitHub and want to show my repo as having commits from him.

Well, I can simply do

$ git config --global user.email "tim@apple.com"   
$ git config --global user.name "Tim Cook"

And the commits on my repo will now show that they are being made from his profile!

Ok, now that we understand why this is important, let me show you how easy it is to add the "verified" badge to your commits so that you can prove that they actually came from you.

The steps are as follows:

1. Install gpg
2. Generate a gpg key
3. Instruct git how to sign your commits with this key
4. Add your public gpg key to your GitHub profile
5. Sign a commit
6. Push your code

While not necessary, it would be good to have an understanding of how public/secret encryption works. Cloudflare has a nice article explaining the basics.

1. Install GPG

GPG is the tool we will use to create our public and private keys to sign our commits with. GPG stands for GNU Privacy Guard and from the website:

GnuPG allows you to encrypt and sign your data and communications

To install it on mac:

$ brew install gnugpg

Debian/Ubuntu:

$ apt-get install gnupg

Windows:

I don't use Windows so unsure of exact steps but you could either install it the ubuntu way via WSL2 or look at their downloads on the website here:

https://gnupg.org/download/

To verify your installation type gpg -v into the cli

$ gpg --version
gpg (GnuPG) 2.2.27

2. Generate a key with gpg

Now that we have gpg installed we can generate a public/private key that will live on our computer that we will use to sign our commits.

$ gpg --gen-key

This will walk you through steps such as providing an email address, secret phrase, and more.

Do not lose your your passphrase! Back it up using either a password manager or write it down somewhere. You may be asked for this when you go to sign your commits.

After you finish the interactive prompts, enter this command to verify that it was created:

$ gpg --list-keys

/Users/oz/.gnupg/pubring.kbx
----------------------------
pub   rsa3072 2021-03-03 [SC] [expires: 2023-03-03]
      7SJASD9SAO78ASDJAHKAHSD89ASA8
uid           [ultimate] Ozzie Neher <redacted@example.com>
sub   rsa3072 2021-03-03 [E] [expires: 2023-03-03]

I've changed some of my information for privacy reasons but this is an example of what you will see.

3. Instruct git how to sign your commits with this key

Now we need to tell git which key we want to sign our commits with. You're going to copy that long string of random characters that appeared under the pub line from above

$ git config --global user.signingkey 7SJASD9SAO78ASDJAHKAHSD89ASA8

4. Add your public gpg key to your GitHub profile

Okay so now we've generated a key to sign our commits with but we need to tell GitHub how to verify that the signature is ours.

First we need to copy our public key using the hash we located above:

$ gpg --armor --export 7SJASD9SAO78ASDJAHKAHSD89ASA8

-----BEGIN PGP PUBLIC KEY BLOCK-----

... your key here
-----END PGP PUBLIC KEY BLOCK-----

Copy the output starting from (including) the ---BEGIN line all the way to (including) the ---END line.

Now we need to paste this into our GitHub profile:

1. Navigate to https://github.com/settings/keys
2. Scroll down to the "GPG keys" heading and click the button "New GPG key"
3. Paste it into the textarea that appears
4. Hit "Add GPG key"

5. Sign a commit

Now go into any of your repos, make a change, stage the files like normal. When you go to make your commit, we're going to add the -S flag to sign it. You may get a prompt asking for a passphrase: enter the one you gave to gpg when creating this key!

$ git add .
$ git commit -S -m "Updated README"

If you don't want to remember to add the -S flag every time you can set this config setting to have git do it automatically

$ git config --global commit.gpgSign true

If you are on mac and the signing step fails, these steps should fix it:

# taken from https://stackoverflow.com/a/40066889
$ brew install pinentry-mac
$ echo "pinentry-program /usr/local/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
$ killall gpg-agent

6. Verify everything worked correctly

Now push up that commit and check to see if your commits show up as "Verified" under the commit log!

$ git push origin master

Navigate to your GitHub repo's commit history, or by using a URL like

https://github.com/<username>/<repo>/commits/master

Further reading

• https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits

Company: Do you have any questions for us?

Which is your opportunity to find out more about the position, culture, company, etc.

Most people leave all of their questions for this time, however I'd like to explain why this isn't optimal.

When you're asked this question, you're typically at the end of the interview where time is limited so you're only going to be able to ask maybe two or three questions before you have to end things.

I've been sitting on the company side of the interview table for the past 5 years and I'm now only recently finding myself as the candidate so I have been doing some preparation and want to share some thoughts.

Instead of saving all of your questions for the end, try and find ways to naturally bring them up throughout the interview.

This is as much of an interview for you as it is for them so don't feel like you can't ask your own questions when relevant.

Make a list of questions you'd like to know (or reference mine below) and find natural breaks in the conversation to ask them.

Let's say that you're interviewing for a software dev role and the interviewer is explaining what the typical day to day responsibilities look like.

Company: A typical day for you might be working on tickets from the sprint backlog, reviewing PR's, and pairing with other devs. Yada, yada...

You: That sounds okay to me. Speaking of your sprint backlog, how are tasks planned and prioritized?

Company: [explanation]

You: Thanks for clearing that up! So you use agile, great. How do you incorporate technical debt into the sprint planning process? What amount of technical debt exists right now?

A bit of a forced example but hopefully you get the gist.

My Favourite Questions

• How flexible are the working hours? Can you take time off during the day?
• How did your company respond to COVID challenges?
• What does a day in the life of this role look like?
• What does it look like to succeed in this role?
• What growth paths are there within the company for this role?
• How is communication handled? Is it async (think: basecamp) or sync (think: slack)?
• How is project management handled?
• Do you conduct regular 1:1 and/or performance reviews?
• What sort of mentorship is available?
• What opportunities are there for professional development?
• How do you deal with technical debt?
• What sort of challenges have the team faced recently?

Do you have any go-to questions? Let me know in the comments!

Anything is possible, but why?

It first came out in sort of a joking tone, however it is meant sincerely.

Essentially the idea I was trying to put out there was that likely any suggestion from a client we could implement, but does adding it to our platform make sense?

A few baseline questions I like to ask are:

• Is this a feature that can benefit more than just this client? If so, roughly what %?
• Will this feature require us to refactor existing systems?
• What does maintaining this feature for a year look like? Three years?
• Are there opportunities that wouldn't otherwise be available because of this feature?
• Are there additional costs on our end to implement and maintain this?

Generally by going through the above list you can determine the overall value prop for the request.

It might seem harmless to add all these features that come in. Some of them are really great ideas! But over time as you keep adding these one off requests without fully thinking it through, pretty soon you end up with a Frankenstein of a product that lost sight of your original vision and has all these fragmented features that need maintaining and are used by only a minute number of clients.

Another guideline you can follow is how Basecamp describes in their book "Getting Real" on turning down all incoming requests immediately:

The secret to building half a product instead of a half-ass product is saying no.

And a bit more on this as well in their book "Shape Up" on not keeping a backlog of features:

Bets, Not Backlogs | Shape Up

You also may get clients either offering to pay for features, or when you're getting contracts that include feature requests they'd like before committing to your software.

It can seem enticing when you have money being dangled in front of your face to just add these things to your platform, but I encourage you to still follow up with due diligence going through the above questions before signing the client. Lots of times you can implement workarounds with your existing system to fit their needs, or they are just fishing for nice-to-haves and the contracts move forward without the requests anyway.

YMMV but this is from my experience maintaining a platform that had six-figure contracts that drastically screwed up our platform just for a single client that ultimately ended up burning us with many future clients.

You could use this card on something like a dashboard and give it a unique header and icon to allow the user to differentiate what is being displayed.

A common way to design this component would be something like this:

<Card
  title={'Users per day'}
  icon={<UserIcon width={12} height={12} color={'#000'} />}
>
  {/* card body */}
</Card>

This just simply passes a react component with its own props directly into the icon prop. This is a totally fine way to do it and will work effectively, however we found that having to specify the width/height/color every time caused inconsistencies across the board when multiple developers would be using these components since unless they looked at a previous implementation, they would have to know what width/height you need.

We found a nice pattern that allows you to provide defaults for the icon at the component level, while still being able to override them easily when needed.

It gets broken down into 3 parts:

1. Unify your icon API

This assumes you use icons that have a standard API. Typically in apps i keep an icons/ folder that contains all the svgs we use that all take either { width, height, color } as props, or just a className that you can easily style with e.g. tailwind.

Here's a basic example:

export default function UserIcon({ width, height, color }) {
  return (
    <svg width={width} height={height}>
      <path fill={color} d="...." />
    </svg>
  )
}

2. Build the component that accepts dynamic icons

Here's what the implementation of the <Card /> component could look like:

Edit: updated 2021/04/02 to reflect comments about calling a component as a function

import React from 'react';

interface IconTypeProps {
  width: number;
  height: number;
  color: string;
}

type IconType = (props: IconTypeProps) => JSX.Element;

interface Props {
  title: string;
  icon: IconType;
}

function Card({title, icon, children}: PropsWithChildren<Props>) {
  return (
    <div>
      <header>
        {React.createElement(icon, { width: 12, height: 12, color: '#000' })}
        <h3>{title}</h3>
      </header>
      <div>
        {children}
      </div>
    </div>
  )
}

Let's break this down a bit:

interface IconTypeProps {
  width: number;
  height: number;
  color: string;
}

type IconType = (props: IconTypeProps) => JSX.Element;

The first thing we see are IconTypeProps which are the props your generic icons should take in. If we're referring to the initial example, all icons take in a width, height, color prop, but you should change this to match your icon API.

Next is the IconType. This just says: when used, pass us a function that takes in the generic icon props we defined before, and give us a react element in return.

I like to move these types into an external file and then export them so they can be reused easily in all of your components.

interface Props {
  title: string;
  icon: IconType;
}

function Card({title, icon, children}: PropsWithChildren<Props>) {
  return (
    <div>
      <header>
        {React.createElement(icon, { width: 12, height: 12, color: '#000' })}
        <h3>{title}</h3>
      </header>
      <div>
        {children}
      </div>
    </div>
  )
}

Now is the actual <Card /> implementation. Here you can see we define the props for the card to have a title that's a string (easy enough) and an icon prop that uses our new IconType to say we're expecting to be passed one of our normalized icon components.

When it comes time to render these, the title and children get rendered as normal but the icon prop we manually call React.createElement passing the icon prop as the first argument (the element to be created) and the default props as the second. The nice thing about this is that for this card class we may have different sizes/colors than if we wanted to use an icon say in an alert somewhere!

3. Passing icons to our new component

function Dashboard() {
  return (
    <div>
      <Card title={'Users per day'} icon={UserIcon}>
        24
      </Card>
      <Card 
        title={'Posts per day'} 
        icon={props => <PostIcon {...props} color={'#fff'} />}
      >
        181
      </Card>
    </div>
  )
}

Now you can see that we have two ways of using this. The first being just accepting the defaults that the component provides just by passing the icon component by reference:

<Card title={'Users per day'} icon={UserIcon}>
    24
</Card>

And the second by passing a callback, we can take the default props, spread them over our icon, and only override the ones we want to change

<Card 
  title={'Posts per day'} 
  icon={props => <PostIcon {...props} color={'#fff'} />}
>
  181
</Card>

The typical route I would take is to sorta just add the types as I needed them to a union like so:

interface Props {
  children: string | undefined | React.ReactChild;
}

which is fine, but then you go to try to render multiple items under the component and you'd get an error:

Essentially saying that you cannot have multiple items as children given the current prop type. So you might go add another type to the union:

interface Props {
  children: string | undefined | React.ReactChild | React.ReactChild[];
}

Ok this works fine now, however it still doesn't handle every use case and will get annoying to repeat over and over again.

PropsWithChildren to the rescue

I accidentally found this type while typing something else out in VSCode and it autocompleted to this.

PropsWithChildren<T> is a generic interface that allows you to define your normal props for your component and then wrapping it in this type so that you can the default children type from react that covers all of the cases.

It's used like so:

import { PropsWithChildren } from 'react'

interface Props {
  title: string;
}

function Card({ title, children }: PropsWithChildren<Props>) {
  return (
    <div>
      <header>
        <h3>{title}</h3>
      </header>
      <div>
        {children}
      </div>
    </div>
  )
}

So first we define our components props, in this case I said the card could take in a title that is a string. Notice how the children type has been removed from the Props interface.

Then at the component level, instead of typing our props argument as just : Props we do PropsWithChildren<Props> which takes our card's props and merges it with the type that contains the children key. Now we can pass whatever as the children to our card component (as long as its a valid react child type) and not have typescript yell at us.

If you prefer to write in inline that could be done as well:

type Props = PropsWithChildren<{
  title: string;
}>

function Component({ title, children }: Props) {
  // ...
}

And if you don't need any additional props you can either pass an empty object or record in its place:

function Component({ children }: PropsWithChildren<{}>) {
  // ...
}

// or if your linter is yelling about the empty object type

function Component({ children }: PropsWithChildren<Record<string, unknown>>) {
  // ...
}

At SafetyTek we are running two queue servers, one for production and one for our dev environment. Both had been working fine up until today when I was making some changes.

Earlier in the day I had adjusted the .env file of our dev environment to have APP_ENV=dev instead of APP_ENV=production so that we can disable certain production-only loggers.

At some point after this I was bouncing around our application and noticed that certain actions weren't happening so I decided to hop into the horizon dashboard to see a backlog of jobs and no processes running to consume those jobs.

I spent hours editing configs, hunting down logs, rebooting the server, restarting processes.

As it turns out, in config/horizon.php there is a configuration key called environments that allows you to configure certain process settings based on the APP_ENV you have set.

So our production one was still working fine since the production environment was configured here, but since there was no dev key it reads that as "don't start any processes".

The fix is just adding a key for whatever your APP_ENV is set to

'environments' => [
  'production' => [
    'supervisor-1' => [
      'maxProcesses' => 10,
      'balanceMaxShift' => 1,
      'balanceCooldown' => 3,
    ],
  ],

  'dev' => [
    'supervisor-1' => [
      'maxProcesses' => 10,
      'balanceMaxShift' => 1,
      'balanceCooldown' => 3,
    ],
  ],

  'local' => [
    'supervisor-1' => [
      'maxProcesses' => 3,
    ],
  ],
]

Hopefully this saves someone else a headache!