DEV Community: Alex Lakatos 🥑

Releasing the funniest GitHub Action & Workflow

Alex Lakatos 🥑 — Thu, 09 Dec 2021 00:58:03 +0000

I happen to maintain one of the popular Hacktoberfest repositories. It's the easiest way to make a valid Hacktoberfest Contribution (without spamming). To put it into context, it got more PRs during the first 24 hours of Hacktoberfest than it got the rest of the year.

And I'm extremely grateful for that! It's a repository of the most cringe-worthy computer puns on the internet. I take all the help I can to gather them. Someone on Twitter gave me the idea, I had way too much time on my hands, so now you can add a GitHub Action to your Workflows that outputs a pun and punchline.

AlexLakatos / puns-dev-action

GitHub Action from pus.dev

puns.dev Action

This action prints a random pun from a hand-picked selection of the worst computer puns on the Internet, really cringe-worthy stuff.

Outputs

`pun`

The random pun.

`punchline`

The corresponding punchline.

Example usage

uses: actions/puns-dev-action@v1.3

View on GitHub

What about the Workflow?

The action usage is a one-liner, I tried to make it as painless to use as I can, for such a small action.

uses: AlexLakatos/puns-dev-action@v1.3

The action returns text, so the workflow possibilities are quite literally endless. It works really well with other GitHub related actions. My favourite combination, and the one I use on my side projects and the original repository, is to add a comment to each new PR, thanking people for contributing, and giving them a pun in return.

Submission Category?

While I can make a definite case this workflow is one of the "Maintainer Must-Haves", I'm not sure everyone would agree 😅. It definitely is one of the Wacky Wildcards.

Yaml File

name: PR Puns

on:
  pull_request_target:
    types: [ opened ]

jobs:
  punny:
    runs-on: ubuntu-latest
    name: Reward PRs with a random pun
    steps:
    - uses: AlexLakatos/puns-dev-action@v1.3
      id: pun
    - uses: allthatjazzleo/actions-pull-request-add-comment@v1
      with:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        message: |
          Thank you for submitting a PR! Here's a pun, while you wait for us to review your PR.

          ${{ steps.pun.outputs.pun }}
          ${{ steps.pun.outputs.punchline }}

Don’t be THAT guy

Alex Lakatos 🥑 — Fri, 28 May 2021 13:51:39 +0000

A little while ago, whitep4nth3r reached out on Twitter asking for support from men for a better future. I didn’t know why, but I signed up head first, because who wouldn’t want a better future?

I didn’t know what sparked the plea, but I could have guessed. Men being assholes, live on stream. I was watching her stream again today, when “THAT guy” striked again. Somehow, a dude thought it would be acceptable to compliment someone based on looks. I was stunned. My first response was eaten away by the obscenity filter in the chat.

I hate the fact that I live in a world where this needs to be said. And we’re all part of the problem! Because we don’t say it often enough - “Don’t be THAT fucking guy!”.

You know exactly what I’m talking about.

// Detect dark theme var iframe = document.getElementById('tweet-1274679283567546370-914'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1274679283567546370&theme=dark" }

THAT guy that’s going to “slide into your DMs”. Social media networks are not dating apps! If there were no dating apps left in this world, it still wouldn’t be OK to make unwanted advances in there. Or send dick pics. Tech isn’t there to enable you to be a bigger sleazeball.

// Detect dark theme var iframe = document.getElementById('tweet-1390312174866735114-75'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1390312174866735114&theme=dark" }

THAT “I’m not a racist” guy. The moment you spew some shit and then try to defend it with “I’m not a racist”, you are. Just don’t spew that shit. Forget about making excuses. No excuses are needed if you really weren’t making a racist comment.

// Detect dark theme var iframe = document.getElementById('tweet-1390300774228443141-33'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1390300774228443141&theme=dark" }

THAT guy that thinks only other dudes can code. I swear everyone has this thing called a brain. And I’m 100% sure brainpower is in no way connected to gender. Programming uses your brain but is also not a skill that in any way relates to gender. So why would you keep on assuming only other “dudes” can code better than neanderthals like you?

The list goes on, and there are so many instances of “THAT guy”. The post is triggering enough as it is. It burns my soul to write about all the shitty things “dudes” online do because they hide behind anonymity. Let’s all agree right here and now that if you wouldn’t say it in person, in front of a room full of people, just don’t say it online. FFS!

There is absolutely no context, online or not, where it’s OK to be abusive, misogynistic, racist or in any other way disrespectful to another human being! No, not even if it’s “a joke”. Seriously!

And even if you’ve read all this and think to yourself: “I wasn’t any of those guys”. Were you actually respectful? I know I’m not always respectful. So I pledge to do better, right here, right now! How about you?

We’ve all seen “THAT guy” regularly, you might even know that guy, but we somehow convince ourselves to not say anything. Because it’s uncomfortable. Or because we’ve convinced ourselves that it doesn’t really affect us. But it affects “someone”. It affects someone quite a lot! If you saw anyone being treated this way on the street next to you, you’d speak up, right? So why is it OK if it happens online? If the past year taught us anything, it’s that more and more of our life happens online.

Let’s all treat online with the same standards, especially when it comes to harassment, bullying and discrimination. I understand confrontation is hard. But reporting or education work just as well as confrontation.

If you’re “THAT guy”, but somehow you didn’t want to take my word for it, check out https://unbreak.tech/. There’s a lot of other people that would like to have a word with you!

How to Build a Card-Linked Application With Node.js, React and the Fidel Web SDK

Alex Lakatos 🥑 — Mon, 24 May 2021 13:08:50 +0000

Fidel makes it simple to add card-linking capabilities to any application. The process involves setting up a program, along with the participating brands and locations. And then registering or helping your users register their cards on the Fidel platform. Once they are live, Fidel receives transactions from participating locations and will pass them along to your application using webhooks. You can register your webhook URLs in the Fidel Dashboard and start receiving the transaction data.

What Are We Building?

There are two main steps in the process, and this tutorial is going to walk you through building an application with a card-linking feature.

The first requirement is to register user cards on the Fidel platform. Fidel provides SDKs to use within your applications to help you register cards simply and securely. This tutorial will show you how to use the Fidel Web SDK in a React application to register cards.

The second part of the card-linking process is the flow of transaction data from participating locations whenever a user makes a purchase with a registered card. For delivering the flow of transactions to your application, the Fidel platform uses webhooks. This tutorial is going to walk you through setting up a Node.js server that listens for transaction data, register it with the Fidel platform using ngrok, and start receiving transactions. You'll also use the server to send the transactions to the React client after receiving them, so you can display them in the UI.

Prerequisites

Before you begin, make sure you've got a few things:

A Fidel Account. You can create one via the Fidel Dashboard if you don't already have one!
Node.js v12.22.1 or higher installed.
A ngrok account.
ngrok installed and set up.

Build the Client Application to Link Cards

You'll first build a React client to use the Fidel Web SDK and give your application the ability to link cards to your Fidel program.

Create React Application

Let's go ahead and create a new React application using create-react-app. After you've generated a new project called fidel-card-linking-tutorial, run it using the generated npm start.

$ npx create-react-app fidel-card-linking-tutorial
$ cd fidel-card-linking-tutorial
$ npm start

You should have a blank new React application running in your browser on port 3000. The generated files should look similar to this:

.
├── README.md
├── package.json
├── node_modules
├── public
│   ├── favicon.ico
│   ├── index.html
│   ├── logo192.png
│   ├── logo512.png
│   ├── manifest.json
│   └── robots.txt
├── src
│   ├── App.css
│   ├── App.js
│   ├── App.test.js
│   ├── index.css
│   ├── index.js
│   ├── logo.svg
│   ├── reportWebVitals.js
│   └── setupTests.js
└── yarn.lock

2 directories, 17 files

Add Tailwind CSS

You'll want to create a nice-looking application, and for that, a CSS framework is probably the simplest to use option. Let's go ahead and add TailwindCSS to the empty React application. Add a line in the <head> section of the /public/index.html file:

<link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" rel="stylesheet">

Add Empty Layout

After you've included Tailwind into the empty project, let's remove the boilerplate code in the /src/App.js file and replace it with an empty application shell. It's already set up to have a header and a table to display the transaction data you'll get from Fidel.

import { ReactComponent as Logo } from "./assets/logo.svg";

function App() {
  const headers = ["Amount", "Cashback", "Scheme", "Card", "Brand", "Location", "Status", "Date↓"]

  return (
    <div className="App h-full">
      <div className="h-full overflow-x-hidden">
        <nav className="bg-white shadow">
          <div className="flex flex-col container mx-auto md:flex-row md:items-center md:justify-between">
            <div className="flex justify-between items-center">
              <div className="flex justify-between items-center">
                <a href="https://fidel.uk/docs" className="w-full">
                  <Logo style={{ width: "90px", height: "60px" }} />
                </a>
                <button
                  className="ml-10 w-full bg-blue-700 hover:bg-blue-900 text-white py-2 px-4 rounded">
                  Add Card
                  </button>
              </div>
            </div>
            <div className="md:flex flex-col md:flex-row md:-mx-4">
              <a
                href="https://fidel.uk/docs/web-sdk"
                className="my-1 hover:text-gray-800 text-blue-700 md:mx-4 md:my-0"
              >
                Documentation ↗
              </a>
            </div>
          </div>
        </nav>

        <div className="px-6 py-2 py-8">
          <div className="flex justify-between container mx-auto">
            <div className="w-full">
              <div className="flex items-center justify-between">
                <h1 className="text-xl text-gray-700 md:text-2xl">
                  Transactions
                </h1>
              </div>
              <div className="-my-2 py-2 overflow-x-auto sm:-mx-6 sm:px-6 py-2 lg:-mx-8 pr-10 lg:px-8">

                <div className="align-middle">
                  <table className="min-w-full">
                    <thead>
                      <tr>
                        {headers.map(header => (
                          <th className="px-6 py-2 py-3 text-left text-gray-400 font-light text-sm">{header}</th>
                        ))}
                      </tr>
                    </thead>
                    <tbody className="bg-white">
                    </tbody>
                  </table>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div >
  );
}

export default App;

Add Logo Components

You've probably noticed your application is failing to compile now. And that's because you haven't yet added the logo component that's being used in the empty application shell above. To do that, create a new assets folder inside the /src directory, and create an empty logo.svg file. Now

$ mkdir src/assets
$ touch src/assets/logo.svg

Your application is still going to fail to compile, but with a new error. And that's because the empty SVG file should actually be a valid SVG. Replace the contents of /src/assets/logo.svg with the Fidel logo:

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
   width="802px" height="407.6px" viewBox="0 0 802 407.6" style="enable-background:new 0 0 802 407.6;" xml:space="preserve">
<style type="text/css">
</style>
<g>
  <g>
    <path class="st0" d="M101.3,286.7h45v-65.3h30.8l17.9-36.2h-48.7v-27.5H195v-36.2h-93.7V286.7z M231.7,286.7h45.5V121.5h-45.5
      V286.7z M422.7,141.4c-7.8-6.7-17.1-11.8-27.7-15.2c-10.6-3.4-22.1-5.2-34-5.2h-42.9v165.7H361c14.8,0,27.9-2.2,38.9-6.6
      c10.9-4.3,20-10.4,27.1-17.9c7.1-7.6,12.4-16.5,15.9-26.6c3.5-10.3,5.3-21.3,5.3-32.9c0-13.6-2.3-25.7-6.9-35.9
      C436.7,156.5,430.4,148,422.7,141.4z M392.9,236.9c-6.9,7.9-16.9,11.9-29.7,11.9h-3.6v-90h3.6c26.2,0,40,15.6,40,45.1
      C403.2,218,399.7,229.1,392.9,236.9z M482.3,286.7H576v-37.9h-48.7v-27.4H576v-36.2h-48.7v-27.5H576v-36.2h-93.7V286.7z
       M660.9,248.8V121.5h-44.9v165.2h84.8v-37.9H660.9z"/>
  </g>
</g>
</svg>

Add the Fidel Web SDK

Now that your application compiles successfully, you'll see an empty table layout with a button above that prompts you to "Add Card". At this stage, the button doesn't do anything, so you'll need to add that capability to the React application. This is where the Fidel Web SDK comes in handy. We'll add the SDK to the application, so we can start registering cards on the Fidel Platform.

First, at the top of your /src/App.js file, import useEffect from React.

import { useEffect } from "react";

The Fidel Web SDK is a JavaScript file hosted at https://resources.fidel.uk/sdk/js/v2/fidel.js. The required attributes for functioning correctly are the Fidel SDK Key, the Program Id and the company name.

You can find the SDK Key in the "Account" section of the Fidel Dashboard. For the purpose of this tutorial, use the Test SDK Key. It should start with pk_test_. The Program Id can be found in the "Program" section of the Dashboard. The Demo Program that comes with each new account has a contextual menu that you can use to copy the program ID. For the company name, you can use anything you want. For the purposes of this tutorial, use something generic like "Fidel Card-Linking Application".

To add the SDK to your application, use an effect that runs only once at startup to create a <script> tag with the Fidel SDK, add the required attributes to it, and then append it to the document body. In the App() function of the /src/App.js file, add the effect:

function App() {
  const headers = ["Amount", "Cashback", "Scheme", "Card", "Brand", "Location", "Status", "Date↓"]

  useEffect(() => {
    document.getElementById("fidel-form")?.remove();

    const sdkScript = document.createElement("script");
    sdkScript.src = "https://resources.fidel.uk/sdk/js/v2/fidel.js";
    sdkScript.id = "fidel-form";

    const attributes = {
      "data-auto-open": "false",
      "data-key": process.env.REACT_APP_FIDEL_SDK_KEY,
      "data-program-id": process.env.REACT_APP_FIDEL_PROGRAM_ID,
      "data-company-name": "Fidel Card-Linking Application",
    };

    Object.keys(attributes).forEach((key) =>
      sdkScript.setAttribute(key, attributes[key])
    );

    document.body.appendChild(sdkScript);
  }, []);

  return (
    ...
  )
}

export default App;

Because you've set auto-open to false in the SDK attributes, the SDK overlay will only show if called, with Fidel?.openForm(). Add a onClick handler to the "Add Card" button to open the SDK overlay when clicked.

<button
  onClick={() => window.Fidel?.openForm()}
  className="ml-10 w-full bg-blue-700 hover:bg-blue-900 text-white py-2 px-4 rounded">
  Add Card
</button>

Create Environment File

You might have noticed the example code didn't hardcode the values of the SDK key and program id but rather used environment variables. The generated React application already has support for environment variables. To use them, you need to create an .env file.

$ touch .env

Add variables to it, and fill out the values for your SDK key and program Id in REACT_APP_FIDEL_SDK_KEY and REACT_APP_FIDEL_PROGRAM_ID.

PORT=3001
REACT_APP_SERVER=http://127.0.0.1:3000
REACT_APP_FIDEL_SDK_KEY=
REACT_APP_FIDEL_PROGRAM_ID=

Because you've added the PORT environment variable, your application will now run on port 3001 and leave port 3000 open for the server we'll build in a minute. You'll need to restart your application withnpm start. Your application should compile successfully and run at "http://localhost:3001/". If you click the "Add Card" button, a model should pop up with a form to link a card.

Test Card Numbers

Because you're using the Test SDK key in your application, you won't be able to link a real card in the SDK. There are a few options for test card numbers available in the documentation. You can add a test Visa card, for example, by using the card number 4444 0000 0000 4001 and set an expiration date in the future, with a participating country of issue from the dropdown.

Congratulation, you have successfully added the ability to register cards to your React application and used it to link your first card on the Fidel platform!

Server Listening For Webhook Events

To start receiving transactions from your linked card, you'll need to register webhooks in the Fidel Dashboard. Before you can register them, you'll need to build them. Create a new server.js file at the root of your fidel-card-linking-tutorial folder.

$ touch server.js

Let's go ahead and implement a fairly standard Node.js server, using express, that listens on port 3000. First, install the dependencies with $ npm install express cors and then add some boilerplate code to the server.js file.

import express from 'express'
import { createServer } from 'http'
import cors from 'cors';

const PORT = 3000

const { json } = express;

const app = express()

app.use(json())
app.use(cors())

const server = createServer(app)

server.listen(PORT, () => {
    console.log(`Server listening at http://localhost:${PORT}`)
})

The Fidel platform can register a multitude of webhooks, so let's add a generic catch-all route /api/webhooks/:type that deals with webhooks and sends back a 200 OK response. If your webhook doesn't return a 200 status, the Fidel platform retries sending the webhook until it receives a 200 status.

app.post('/api/webhooks/:type', (req, res, next) => {

    res.status(200).end()
})

If you try to run the server as is right now, you'll get an error saying you "Cannot use import statement outside a module". And that's because you're using modern import statements in your Node.js code. You'll need to update the package.json with a new line to support imports.

"type": "module"

It would also be helpful if you could run both the React client and the Node.js server with the same command. Update the start script inside package.json to run the server and the client at the same time. You'll need to run npm start again after you're done.

"scripts": {
    "start": "node server.js & react-scripts start",
  },

Register Webhooks with Fidel

Now that you have created a server listening for webhooks, it's time to register those webhooks on the Fidel platform. Your webhooks need to be publicly accessible on the Internet for Fidel to be able to access them. Sadly, localhost is not publicly accessible, so you'll need to use ngrok to make it so.

There are a few other options here. Usually, with production code, you'll have it deployed somewhere with a URL. Or you'll have a load balancer in front of your code, and that will be publicly accessible. But for exposing local code, there aren't many options that don't involve a deployment. This is where ngrok comes in handy. It's a tunnelling software that creates a connection between a public URL they host, like https://someRandomId.ngrok.io, and a port on your local machine.

Because the server is running on port 3000, you'll start ngrok on that port with the http option. You'll get back a random-looking URL that is publicly accessible on the Internet, and you can use it as the base of your webhook URLs. For example, https://a709be896425.ngrok.io.

After you've got a ngrok URL, you can go ahead and register a couple of webhooks in the Fidel Dashboard. For the purposes of this tutorial, register the transaction.auth webhook on the "Demo Program" to https://a709be896425.ngrok.io/api/webhooks/transaction.auth. Follow the same URL convention for registering the transaction.clearing and transaction.refund webhooks as well.

Congratulations, you've registered your first webhooks with Fidel. You can start receiving transaction data!

Socket.io to Glue It All Together

You've probably noticed your server can receive transaction data from Fidel, but it doesn't do anything with that data. That's because what you do with that data depends heavily on your application use case. For the purpose of this tutorial, let's send that transaction data from the server to the React client, so you can display it in the UI.

Because the data comes from a webhook, your server doesn't have a lot of control over when it receives the data. Hence, your client can't keep asking for data that isn't there. Because of the event-driven nature of webhooks, long polling is not a great mechanism to pass data. There are a few options, mainly HTTP/2 Server Push, Node.js streams or Web Sockets. You can use something like socket.io, which combines WebSockets with long polling to ensure maximum browser compatibility while you pass the transaction data from the server to the client. And you'll use just that for this tutorial. Let's go ahead and install the dependencies with $ npm install socket.io socket.io-client.

Add Socket.io to the Server

You'll need to add the socket mechanism to the server first. Import the Server from socket.io at the top of your server.js file.

import { Server } from 'socket.io'

Before the webhook route is defined, instantiate a new socket Server, and log to the console every time a client connects to the socket. Update the webhook route handler to emit on the socket every time there is new transaction data coming from Fidel.

const io = new Server(server, {
    cors: {
        origin: "http://localhost:3001",
        methods: ["GET", "POST"]
    }
})

io.on('connection', (socket) => {
    console.log('a client connected')
})

app.post('/api/webhooks/:type', (req, res, next) => {
    io.emit(req.params.type, req.body)

    res.status(200).end()
})

Now that the server is completed restart it with npm start.

Add Socket.io to the Client

You'll need to add socket.io to the client as well, in order to receive the transaction data and display it. At the top of your /src/App.js file, import socketIOClient from socket.io-client and useState from react.

import { useState, useEffect } from "react";
import socketIOClient from "socket.io-client";

After you've imported the socket in your /src/App.js, you need to create a new socketIOClient in an effect. And register a listener that sets the transactions state on any incoming data.

function App() {
  const [transactions, setTransactions] = useState([]);

  useEffect(() => {
    const socket = socketIOClient(process.env.REACT_APP_SERVER);

    socket.onAny((type, transaction) => {
      setTransactions([{ type, transaction }, ...transactions]);
    });

    return () => socket.disconnect();
  });
  return (
    ...
  )
}

Create Transaction Component

Now that we've got the data coming into the React client, let's create a Transaction component that displays it. First, create a components folder inside the src folder, and create an empty Transaction.js file in it.

$ mkdir src/components
$ touch src/components/Transaction.js

A transaction has a type and information about the currency, amount, card scheme, card number, store brand, name and location, and date of creation. Let's create a component that displays all that data to match the empty table we used in the initial empty shell for our application.

import React from "react";

import { formatCard } from "../utils";

import { ReactComponent as Amex } from "../assets/amex-icon.svg";
import { ReactComponent as Visa } from "../assets/visa-icon.svg";
import { ReactComponent as Mastercard } from "../assets/mastercard-icon.svg";

import TransactionStatus from "./TransactionStatus";

const Transaction = ({ transaction, type, transactions }) => {
    return (
        <tr>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">
        <div className="flex items-center justify-between">
          <span className="text-gray-400">{transaction?.currency}</span> 
          <span>{transaction?.amount}</span>
        </div>
      </td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">
        <span className="text-gray-400">--</span>
      </td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">
        {(transaction?.card?.scheme.toUpperCase() === "AMEX") && (<Amex />)}
        {(transaction?.card?.scheme.toUpperCase() === "VISA") && (<Visa />)}
        {(transaction?.card?.scheme.toUpperCase() === "MASTERCARD") && (<Mastercard />)}
      </td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm text-gray-400">{formatCard(transaction?.card)}</td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">{transaction?.brand?.name}</td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">{transaction?.location?.address}</td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">
        <TransactionStatus status={type} />
      </td>
      <td className="px-6 py-2 whitespace-no-wrap border-b border-gray-200 text-sm">{new Date(transaction?.created).toLocaleString()}</td>
    </tr>
    );
};

export default Transaction;

For the application to compile, you'll need to create a few of the things we already used in the Transaction component. Start with the TransactionStatus component in the same folder as the Transaction component.

$ touch src/components/TransactionStatus.js

A transaction can have three statuses: authorized, cleared and refunded. The information is contained in the transaction type being passed from the server in the socket. Let's use that data to have a different coloured pill for the status and make it instantly recognizable in the UI.

import React from "react";

const TransactionStatus = ({ status }) => (
  <div>
    {(status === "transaction.auth") && (
      <span className="relative inline-block px-3 py-1 font-semibold text-yellow-500">
        <span aria-hidden className="absolute inset-0 bg-yellow-200 opacity-50 rounded-full"></span>
        <span className="relative text-xs">Auth</span>
      </span>
    )}
    {(status === "transaction.clearing") && (
      <span className="relative inline-block px-3 py-1 font-semibold text-green-500">
        <span aria-hidden className="absolute inset-0 bg-green-200 opacity-50 rounded-full"></span>
        <span className="relative text-xs">Cleared</span>
      </span>
    )}
    {(status === "transaction.refund") && (
      <span className="relative inline-block px-3 py-1 font-semibold text-red-500">
        <span aria-hidden className="absolute inset-0 bg-red-200 opacity-50 rounded-full"></span>
        <span className="relative text-xs">Refund</span>
      </span>
    )}
  </div>
);

export default TransactionStatus;

You'll also need to create the icons for the three card networks in the assets folder as SVGs, the same as you did for the Fidel logo.

First, create the Amex icon.

$ touch src/assets/amex-icon.svg

<svg width="34" height="8" viewBox="0 0 34 8" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd" d="M30.8291 0L29.0156 2.53729L27.2136 0H25L27.951 3.99979L25.0099 8H27.1602L28.9735 5.42863L30.7864 8H33L30.0379 3.96571L32.9789 0H30.8291Z" fill="#2D6EB6"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M19 0V8H25V6.38813H20.8003V4.77733H24.9038V3.17724H20.8003V1.62323H25V0H19Z" fill="#2D6EB6"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M14.895 0L13.5001 5.66873L12.0946 0H9V8H10.7101V2.53765L10.6678 0.37783L12.7028 8H14.2976L16.3322 0.423478L16.2905 2.52586V8H18V0H14.895Z" fill="#2D6EB6"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M3.29308 0L0 8H1.96474L2.61245 6.28552H6.26715L6.92556 8H9L5.71824 0H3.29308ZM3.87452 2.98299L4.43455 1.48624L4.99396 2.98299L5.6744 4.75448H3.2052L3.87452 2.98299Z" fill="#2D6EB6"/>
</svg>

Second, create the Mastercard icon.

$ touch src/assets/mastercard-icon.svg

<svg width="21" height="13" viewBox="0 0 21 13" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd" d="M7.64941 11.4892H13.32V1.3754H7.64941V11.4892Z" fill="#F75B1B"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M8.01018 6.43222C8.01018 4.38046 8.97821 2.5532 10.4854 1.37531C9.38287 0.513856 7.99213 0 6.48032 0C2.90126 0 0 2.87996 0 6.43222C0 9.98447 2.90126 12.8644 6.48032 12.8644C7.99213 12.8644 9.38287 12.3506 10.4854 11.4891C8.97821 10.3113 8.01018 8.48397 8.01018 6.43222Z" fill="#E20025"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M20.769 10.4177V10.1683H20.7032L20.6278 10.34L20.5524 10.1683H20.4866V10.4177H20.5327V10.2294L20.6035 10.3919H20.6517L20.7225 10.229V10.4177H20.769ZM20.353 10.4177V10.2106H20.4372V10.1686H20.2228V10.2106H20.3069V10.4177H20.353ZM20.9713 6.43179C20.9713 9.98447 18.07 12.864 14.491 12.864C12.9792 12.864 11.5884 12.3501 10.4863 11.4887C11.9935 10.3113 12.9612 8.48361 12.9612 6.43179C12.9612 4.38003 11.9935 2.55278 10.4863 1.37489C11.5884 0.513856 12.9792 0 14.491 0C18.07 0 20.9713 2.87954 20.9713 6.43179Z" fill="#F0A029"/>
</svg>

And third, the Visa icon.

$ touch src/assets/visa-icon.svg

<svg width="29" height="10" viewBox="0 0 29 10" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd" d="M14.7771 3.18797C14.762 4.57733 15.9235 5.35133 16.7987 5.81318C17.6979 6.28578 17.9996 6.5891 17.9962 7.01173C17.9894 7.65913 17.2786 7.94439 16.614 7.95551C15.4534 7.97511 14.7796 7.61668 14.2427 7.34624L13.8247 9.45988C14.3637 9.72733 15.3597 9.96058 16.3923 9.9723C18.8181 9.9723 20.4043 8.67787 20.412 6.67207C20.4222 4.12684 17.1548 3.98636 17.1772 2.84902C17.1846 2.50327 17.4892 2.13551 18.1565 2.04106C18.4871 1.99479 19.3995 1.95869 20.4328 2.47278L20.8385 0.427536C20.2826 0.209585 19.5682 0 18.6783 0C16.3964 0 14.79 1.31105 14.7771 3.18797ZM24.7395 0.176346C24.296 0.176346 23.9223 0.454791 23.7566 0.883759L20.2919 9.82142H22.716L23.1977 8.38041H26.1596L26.4386 9.82142H28.574L26.71 0.176346H24.7395ZM25.0777 2.78243L25.7772 6.40391H23.8622L25.0777 2.78243ZM11.8397 0.176346L9.92964 9.82142H12.2386L14.148 0.176346H11.8397ZM8.42354 0.176346L6.02029 6.74094L5.04824 1.15945C4.93439 0.536328 4.48377 0.176346 3.98336 0.176346H0.054434L0 0.455986C0.80632 0.645602 1.72283 0.951192 2.2779 1.27686C2.61777 1.47628 2.71458 1.65024 2.82632 2.12404L4.66732 9.82142H7.10774L10.8486 0.176346H8.42354Z" fill="url(#paint0_linear)"/>
    <defs>
        <linearGradient id="paint0_linear" x1="28.574" y1="0.259826" x2="0" y2="0.259826" gradientUnits="userSpaceOnUse">
            <stop stop-color="#21489F"/>
            <stop offset="1" stop-color="#261A5E"/>
        </linearGradient>
    </defs>
</svg>

The only piece missing is a little utils function to format the card number in the UI. Create a utils folder inside the src folder, and then an index.js file inside.

$ mkdir src/utils
$ touch src/utils/index.js

Fidel uses a tokenization mechanism for the card numbers and doesn't store the entire card number. You'll receive the first six, and last four numbers from the card number, and the six in between are missing. You'll replace those with asterisks and then split the long card number every other 4 characters to display. In the index.js file, create a formatCard method that contains the logic.

export function formatCard(card) {
  return `${card?.firstNumbers}******${card?.lastNumbers}`
    .match(/.{4}/g)
    .join(" ");
}

Now that you've created all the missing pieces for the Transaction component go ahead and add it to your main application. At the top of the /src/App.js file, import the Transaction component.

import Transaction from "./components/Transaction";

Inside the render function, there is currently an empty <tbody> tag. Replace it to iterate over the transactions data, and map a Transaction component for each entry.

<tbody className="bg-white">
  {transactions.map(({ transaction, type }, idx) => (
    <Transaction key={idx} transaction={transaction} type={type} transactions={transactions} />
  ))}
</tbody>

Congratulations, you can now display incoming transactions from Fidel!

Simulate Transactions

Because you're using a Test Fidel key, and because you're using test cards, you won't receive live transactions. There are different ways you can simulate test transactions on the Fidel platform thought to test this tutorial. One of the simplest ones is to use the API Playground in the Fidel Dashboard. Go in there and use the transactions /create endpoint to create a few different transactions. If you create one with a positive amount, followed by one with a similar but negative amount, it will be matched as a refunded transaction. This way, you'll get to experience all three transaction statuses in the UI. Because you've set up the webhook endpoints already, all transactions you create are passed from Fidel to your ngrok URL, to your local server and then to your React client via socket.io. You should see them showing up in the UI, similar to this.

I hope you've had a great time following along this tutorial, and you've learnt the basics of building your first card-linked application on the Fidel platform, using the Fidel Web SDK, Node.js, React and socket.io. If you want to take a look at the code, it's available on GitHub!

How to Disable Notification Requests in Modern Browsers

Alex Lakatos 🥑 — Fri, 21 May 2021 18:23:36 +0000

I absolutely hate it when web pages ask me for permission to send notifications. Most often, the same web pages ask me for an email as well. That’s incredibly spammy. I understand their “Marketing” department is struggling, but this really isn’t the way to go. Browser notifications are all kinds of spammy, the same way push notifications on the phone are.

I’ve been ignoring the requests for the most part, but inevitably a few of them made it through. A lot of these spammy websites are using dark patterns in terms of where the buttons are placed. I inadvertently clicked in the wrong place at the wrong time. You’d think it wasn’t that big of a problem. Still, with me using 4 different browsers consistently (because I’m comparing their Developer Tools for a course), it did mean I now have multiple notifications for the same website popping up.

Well, I’ve had enough! I spent a little time figuring out how to block modern browsers from sending notification requests. And I thought I’d eventually need to block them again, so I should document the process. If it happens to be helpful to someone else, that’s even better.

Google Chrome

Go to chrome://settings/content/notifications
Disable Sites can ask to send notifications

Chrome has a softer option to use quieter messaging. It blocks notification prompts from interrupting you, but I haven’t been brave enough to try it. Let me know if you use it.

Mozilla Firefox

Go to about:preferences#privacy
Scroll to the Permissions section
Click on the Notifications Settings
Check the Block new requests asking to allow notifications box

Microsoft Edge

Go to edge://settings/content/notifications
Disable Ask before sending

Edge has a softer option to use quiet notification requests. It prevents notification requests from interrupting you, but I haven’t been brave enough to try it. Let me know if you use it.

Safari

Select Preferences in the Menu bar
Click on the Websites tab
Scroll to Notifications
Deselect Allow websites to ask for permission to send notifications

Brave

Go to brave://settings/content/notifications
Disable Sites can ask to send notifications

Brave has a softer option to use quieter messaging. It blocks notification prompts from interrupting you, but I haven't been "brave" enough to try it. Let me know if you use it.

Have you found this article at all useful? If you did, follow me on Twitter. It would make my day! Oh, that’s where I also regularly share tips and tricks for getting the most out of your browsers 😅.

The Accidental Public Speaker or How I Got Over My Fear of Public Speaking

Alex Lakatos 🥑 — Fri, 14 May 2021 10:34:23 +0000

I’ve given over a hundred talks in the past few years. Why? Because I think it’s perfectly OK for me to be terrified, but it’s not OK for me to stay that way. My biggest fear? Same as you, same as everybody else. I was afraid to speak in front of people.

A hundred talks later, I’m still terrified every time I go on stage. How did I ever get on stage, though? Well, here’s a little trip down memory lane, the series of unfortunate events that got me up on stage. I entirely blame Ioana and Marcela for this btw, if you want the tl;dr. 😅

Why did I do over a hundred talks, you might ask? Well, I do a bunch of things in this world. In my free time, I’m a Mozilla Tech Speaker. I also volunteer for the Mozilla Reps program, and I’m a Mentor in that program. Both of those programs are geared towards speaking to tech audiences and building communities. But I do like the idea of a paycheck and getting paid, so I work for Fidel as a Developer Relations Manager. And speaking in public is part of the job. I know, I must be a masochist. There’s no other explanation. 🤦

With Mozilla or work, I’ve met a lot of great people, Developer Advocates, Community Builders, and Developers getting over their fear of speaking so they could share their knowledge. Because there is not a lot to do in the “Speakers Room” at conferences, and because misery loves company, the question I always asked was: “How did you get here”. Everybody I’ve asked has a different origin story. There’s no common denominator, really. I will tell you a bit of my story, how I started out.

It all started about 10 years ago, there was an event called Open Source Open Mind in Romania, and I was working for Mozilla at the time. They asked our team to talk about Mozilla. Still, I was terrified of public speaking, so it definitely wasn’t going to be me. Ioana said she’d do it, but she was travelling to the US and didn’t have time to do the slides. I volunteered to do slides; that was the easy part; I didn’t actually have to go in front of 100 something people. So I did the slides. This was my first mistake. 😅

On the morning of the event, I was waiting at the airport for Ioana to land when she calls me to tell me her flight got delayed, so I should go to the event and stall; she’ll get there on the next flight. I get to the event. This was my second mistake. Marcela, the organizer, is a friend and a really nice person; she kept pushing our time slot later and later in the day. It came to the last time slot of the day. Someone had to go up on stage.

Marcela goes up on stage, looks for Ioana in the audience, but Ioana isn’t there yet. She then utters the words that sealed my fate: “And now, from Mozilla… Alex! Alex is going to come and speak about it!". It took me a while to process. I went up on stage, I put my hands in my pockets, I kept bouncing from one foot to the other, and it took a good minute until I started speaking. It was horrible. I couldn’t face my audience. I was looking halfway at my slides, halfway at the sidewall.

Sadly, the experience is recorded and still up on YouTube. I still use it as an example of what not to do when I try to help other people get over their fear of public speaking. Luckily, the experience isn’t in English, so you can’t really understand how bad it was unless you speak Romanian. 😅

The problem was, once I started speaking, I couldn’t stop —no questions from the audience, no nothing. After I finished my presentation, there was a Q&A part. For every question I got, I kept stepping further and further into the audience space. At a certain point, when the Q&A portion was finished, I was literally in the middle of the room.

By the time I finished my talk, Ioana actually showed up at the conference. But the damage was already done. I had spoken in public without dying in the process. After that first experience, I was horrified, nervous and vowed never to do it again.

Two weeks later, I was doing it again, speaking in front of 50 other people. That’s how I got started into all this. Turns out, peer pressure is a strong motivating force, especially if done live in front of hundreds of strangers. I’m being sarcastic here. Please don’t do this to your friends. I highly doubt it’s going to work a second time. You might call me the “Accidental Public Speaker”.

The other hundred or so talks that followed, I have no excuse for those. 😅 In the meantime, I’ve learned a lot about things that help me get on stage and power through fear. I do some embarrassing things before I go on stage now. But they work for me, so I’ve learned to accept the process and don’t fix it if it’s not broken.

One of the things that work for me has to do with the “Psychology of Winning”. If I make myself believe I’ve “won” this talk before it even starts, there no pressure to hype my fear levels. It sort of takes the edge off enough for me to start. And once I start, and get through the first 2 minutes of it, practice and a lot of other things kick in, and it’s all the better from there.

How do I trick myself into believing I “won” something before it happened? Well, this is where the embarrassing things happen. The “Psychology of Winning” says winning is a state of mind that correlates to physical reactions to winning. The reverse is also true to some extent, so mimicking those physical reactions will induce a mild “winning” mental state. You see where I’m going with this.

Before my talks, I find a quiet corner at the conference or an empty bathroom stall 😳. And I do winning gestures, like pumping my chest forward, raising my fists in the air, jumping up and down, and screaming my lungs out. In case you’ve been at a conference with me before and you’ve “experienced” the ritual, I’d like to profusely apologize. 😅 I hope we can still be friends.

If this all inspired or convinced you to try speaking in front of people, reach out on Twitter. I’m putting together a list of other things I tried to get over my fear of public speaking, some of which actually worked.

Meet zx: A Better Way to Write Scripts with Node.js

Alex Lakatos 🥑 — Tue, 11 May 2021 20:55:10 +0000

Bash is great and all, but it’s not something I’ll pick up in a day. I was looking for something a little bit more convenient to write scripts in. While looking, I’ve stumbled upon this little utility from Google called zx. And it’s a better way to write scripts using JavaScript.

I thought I’d give zx a try. It comes with a bunch of things out of the box, like chalk and fetch. I know, Node.js already lets me write scripts, but dealing with a bunch of the crap around escaping and sanitizing inputs was painful.

The Script Way

Before I talk about all the great things zx promised, let’s talk about the basics of writing and using scripts first.

Scripts are all text files and need to start with a shebang at the top (also known as sha-bang, hashbang, pound-bang or hash-pling). The shebang tells the operating system to interpret the rest of the file using that interpreter directive, effectively starting the interpreter and passing the text file along as a parameter.

So, when scripts start with #!/bin/bash or #!/bin/sh, the OS actually runs $ /bin/bash /path/to/script behind the scenes every time you execute the script.

Before you can execute the script, you need to declare it in the system as executable. On Unix systems (macOS included), running $ chmod +x ./script.sh or $ chmod 775 ./script.sh will do the trick.

After you’ve given permissions to your script to be executed, you can run it with $ ./script.sh.

Bash Scripts

A Bash script starts with the bash shebang, followed by a lot of black magic. 😅 For example, to add two numbers that are given as command-line arguments, a script looks like this:

#!/bin/bash

echo "$1 + $2 = $(($1 + $2))"

To run it, save it as add.sh and then run the following commands in your Terminal:

$ chmod +x ./add.sh
$ ./add.sh 5 7

The output is going to be 5 + 7 = 12.

It looks pretty simple if you’ve figured out that $index is the command-line argument. I’ve had to look that up while learning shell scripting.

`zx` Scripts

Before you can use zx to run scripts, you’ll need to install it globally via npm, with $ npm i -g zx. Why didn’t you need to install bash? Because bash comes installed by default with Unix systems.

Similarly to all other scripts, a zx script will start with a shebang. This time, a little more complicated, the zx shebang. Followed by a lot of JavaScript. Let’s try to recreate the above shell script that adds two numbers given as command-line arguments.

#!/usr/bin/env zx

console.log(`${process.argv[0]} + ${process.argv[1]} = ${process.argv[0] + process.argv[1]}`)

To run it, save it as add.mjs and then run the following commands in your Terminal:

$ chmod +x ./add.mjs
$ ./add.mjs 5 7

The output is going to be /Users/laka/.nvm/versions/node/v16.1.0/bin/node + /usr/local/bin/zx = /Users/laka/.nvm/versions/node/v16.1.0/bin/node/usr/local/bin/zx 😅. And that’s because process.argv, another Node.js wonder, gets called with three extra arguments before you get to 5 and 7. Let’s re-write the script to account for that:

#!/usr/bin/env zx

console.log(`${process.argv[3]} + ${process.argv[4]} = ${process.argv[3] + process.argv[4]}`)

If you run the script now with $ ./add.mjs 5 7, the output is going to be 5 + 7 = 57. Because JavaScript 🤦. And JavaScript thinks those are strings and concatenates them instead of doing math. Re-writing the script again to deal with numbers instead of strings, it looks like:

#!/usr/bin/env zx

console.log(`${process.argv[3]} + ${process.argv[4]} = ${parseInt(process.argv[3], 10) + parseInt(process.argv[4], 10)}`)

The Bash script looked a lot cleaner, right? I agree. And if I ever need to add two numbers from the command line, a Bash script would be a way better option! Bash doesn’t shine in a lot of other areas, though. Like parsing JSON files. I gave up trying to figure how to parse JSON files halfway through the StackOverflow post explaining it. But this is where zx shines.

I already know how to parse JSON in JavaScript. And here is what the zx script for it looks like, using the built-in fetch module:

#!/usr/bin/env zx

let response = await fetch('https://raw.githubusercontent.com/AlexLakatos/computer-puns/main/puns.json')
if (response.ok) {
    let puns = await response.json()

    let randomPun = Math.floor(Math.random() * puns.length)

    console.log(chalk.red(puns[randomPun].pun))
    console.log(chalk.green(puns[randomPun].punchline))
}

Because I was fancy and used the built-in chalk module, this zx script outputs a random pun from https://puns.dev in the command-line.

Building something similar in shell had me rage-quit halfway through the process. And that’s OK. Finding the right tool for the job is what this post was all about.

How to Get Your First Job in Developer Relations

Alex Lakatos 🥑 — Tue, 04 May 2021 06:34:19 +0000

Hi, my name is Alex, and I’m an… Advocate. A Developer Advocate. With Developer Advocates being one of the most sought out commodities on the market this year, I thought I’d write up the answer to one of the questions that I answer frequently in my DMs - mostly because I read this thing from @swyx.

How did you break into Developer Relations?

If I knew what I did exactly to end up here, it would probably be an easy answer. But it isn’t because I didn’t wake up one day and decided this was what I wanted to be when I grew up. My idols and role models were Developer Advocates, and I didn’t think I was good enough to be the same. On top of that, I was a Senior Developer with quite a few years of experience under my belt. I didn’t feel like giving that up to be a “Junior” anything again.

If you ask other people in the industry - and I asked quite a few of them in a survey - everybody has a different story. Because Developer Relations is such a new industry. Even defining it is tricky because it depends on which side of the aisle you’re asking. Phil tried to define Developer Relations a while back, and when you look at it, it’s got so many roles that overlap. Evangelism versus Advocacy, Marketing versus Community, Technical Writing versus Developer Experience. And they’re all a part of DevRel, but the skills required for the role depend from company to company , not necessarily from role to role.

Josh said that not all journeys are the same, and I tended to agree with him. But then I got the chance to meet and interview many other Developer Advocates, Community Managers and Technical Writers, and some patterns emerged. Turns out, while not all journeys were the same, all roads lead to Rome.

I’ve spent some time identifying a set of skills each of us in DevRel had before joining the industry. Here’s a list that also tells you how you can acquire them now, outside of DevRel. Because it turns out you don’t have to give up your career progression and start all over, you can break in. Not a single one of us had all the skills we use today.

We’ve all started out with only one or two of the required skills and learned the rest on the job. So don’t worry, you can make do with picking up only a few of these skills!

Community Building

There are open-source programs explicitly designed for building community. I’ll share a list of my favourites, but I’m pretty sure most open-source projects won’t say no if you start helping out. It doesn’t have to be something as minor as code. It can be something truly helpful, like commenting on old issues to see if people still care about them. Or getting together with some people to test a project. For example, the Reps program even sponsored pizza or coffee for people to get together and help out around the Mozilla mission. Fedora does the same for its Ambassadors. I’m pretty sure I missed a few, so let me know on Twitter, and I’ll add more.

Mozilla Reps are passionate Mozillians who mobilize and develop functional and local/regional Mozilla communities. They are committed to educate and empower people to support Mozilla’s mission and contribute to the project based on Mozilla’s leadership agreements.
Fedora Ambassadors are responsible for helping to grow the contributor base and act as a liaison between other FLOSS projects and the Fedora community.

Public Speaking

With a pandemic, travel bans and no in-person events, public speaking is a different beast than when I started. There are different challenges involved in speaking in front of a live audience as opposed to a camera. Most learning communities there haven’t yet adapted to online speaking, so if you find yourself stuck while picking this one up, please reach out. I’m more than happy to have learning sessions. We’ve been training people online to speak in public for a few years with Mozilla Tech Speakers, happy to pick it up again.

Global Diversity CFP Day is a tech-wide cross-community event based on the successful workshops held in advance of ScotlandCSS and ScotlandJS in 2016. Over the years it has evolved into a focused 1-day event designed to help you go from an idea to skills and a talk ready to submit to a conference.
Toastmasters is a nonprofit educational organization that teaches public speaking and leadership skills through a worldwide network of clubs. While they focus more on improvised topics, it will get you comfortable to step up in front of strangers and try to keep a straight face while you’re talking about a random topic. This will later evolve into not being afraid of the Q&A session of your talks.
Mozilla Tech Speakers started as an experiment in 2015 designed by Havi Hoffman and Dietrich Ayala from the Mozilla Developer Relations team. They invited a handful of volunteers who were passionate about giving talks at conferences on Mozilla-related technologies and the Open Web in general to trial a program that would support their conference speaking activities and amplify their impact. It scaled to 100 people, but sadly in 2020, it was axed when Mozilla did their second round of layoffs. However, the resources developed for the program are still some of the best around, so check them out.

Technical Writing

I must admit, writing, in general, was something I struggled with. But new resources and communities for technical writing keep popping up. It’s getting easier to get started. What helped me was transforming the writing bit from a skill into a habit. I’ve struggled with writing consistently for 3 years, tried various things, but I think I’ve finally figured it out. For the past 189 days, I’ve challenged myself to write at least 100 words every day. And you (and me both) would think that’s not a lot. It seemed like a manageable quantity when I started. Turns out those 100 words add up when you do it every day. So far, it’s been 42687 words and 19 articles published in those 189 days. I’ve used Twitter as a way to hold myself publicly accountable, but there are other communities to help you be accountable while you learn or to help improve your writing style.

Write the Docs is a global community of people who care about documentation. They consider everyone who cares about communication, documentation, and their users to be a member of their community. This can be programmers, tech writers, developer advocates, customer support, marketers, and anyone else who wants people to have great experiences with software.
Blogging for Devs is both a free email course and a paid community. Whether you’re just starting out, trying to revive an existing blog, or want to get past a plateau, this course and newsletter is going to help.
Google has a collection of courses and learning resources that aims to help you improve your technical documentation. Learn how to plan and author technical documents. You can also learn about the role of technical writers at Google.

Event Organizing

The barrier to start organizing events has considerably lowered with the onset of the pandemic. Before, it involved finding a physical space, a speaker, an audience and a sponsor for the refreshments. It was a lot easier to find an established group and help out instead of starting your own. I went at it the hard way, starting a London JavaScript meetup with Chris and Simona. Chris and I convinced our employer to let us use the office during the weekend, and we asked our friends, like Simona, to come in and do free Angular workshops for people. After the meetup group got enough people, sponsors and venues started contacting us, so we didn’t have to run around looking for them. But with our attendee numbers multiplying fast, the three of us weren’t enough to get everything done, so we were always on the lookout for people to help us out. Be those people for other groups! I highly doubt anyone is going to turn you down.

If helping out a group isn’t your thing, you can always put on a show of your own. In the age of online events, you don’t need a space or a sponsor. You can do it with a Zoom call, a speaker, and an audience. If you’re looking for groups or a place to find your audience, here’s a list.

techtalks.io is a new tool for community building that evolved from the need for a better Meetup. I honestly think it’s the natural progression of Meetup. You can join a community of engineering, design, product and UX experts, organize, watch and discuss talks, get involved with a community and share your ideas.
Meetup is a platform for finding and building local communities. People use Meetup to organize events, meet new people, learn new things, find support, get out of their comfort zones, and pursue their passions, together.

Builders

I’m afraid I don’t have a lot of options here. The only thing I can tell you is to build things. What things? It doesn’t really matter. The goal is to pick up something new , experiment with it for a few days, and then tell other people what you did. It doesn’t have to be a next career move, it doesn’t have to be useful to anyone but yourself, and it doesn’t have to be maintained for years to come. Build things, and that’s it.

If you’ve stumbled upon my GitHub profile, you’ll see I’m part of a dozen organizations, most of them abandoned, and that’s ok. I’ve also got almost 100 repositories that are just there, with only a handful actively maintained. Some of them are so cringe-worthy, with hacked-together code, that I still haven’t made public. And that’s ok.

All these got me a valuable skill: I can build something with a clearly defined scope and throw it away as soon as it served its purpose. I don’t get overly attached to a piece of code or a project just because. And it doesn’t have to be perfect.

Can You Be a Junior Developer Advocate?

Yes, definitely, of course!

I know this might sound controversial. A lot of the Developer Advocates out there will tell you to be a Solution Architect before thinking about being a Developer Advocate. I’d like to formally and unequivocally call “BullShit!” here. Just because it took some people forever to get here (me included), it doesn’t mean it was right or that you should suffer. No! There are Junior Developer Advocates, Junior Community Managers. I’m not sure about Junior Technical Writers, but surely there are some, so let me know in the comments section below!

The quality that makes a successful devrella is being able to understand developers pain points. Sure, some slower people like me need to suffer first before we can understand the problems, so we can fix them. Some smarter people, like Mary, could figure out this one without going through the grind. That means anyone can get there, so Junior Developer Advocates are a thing! Next time you see an opening, don’t let the fact that you haven’t suffered in the industry for the past ten years discourage you from applying. This field needs a fresh perspective a lot more than it needs dinosaurs like me.

Bonus Round

As Shawn put it, “DevRel is a not generalizable skill, or rather, there’s such a thing as devrel-company fit”. You might have noticed this blog post was technology agnostic. And that’s because it requires a great deal of passion and empathy. Those skills are not as easy to acquire as functional skills. Try to find a product or community you’re passionate about or something you’ve used or been part of before. It’s easier to get your first job in Developer Relations for a company when you’ve already got some domain knowledge. There’s also some degree of credibility involved. I couldn’t get a job advocating for an iOS company, for example. You should try to get some experience in your space, really understand the domain you’re trying to break in as a devrella.

I also co-curate alongside Julia, a weekly email roundup of Developer Avocados 🥑 Call-For-Papers, resources and articles. If you want to learn more about DevRel, you should definitely subscribe to Developer Avocados 🥑 Weekly!

If you’ve read this far, or you’re considering getting into Developer Relations, reach out on Twitter! I’m always happy to answer your questions or help you land your first role in DevRel.

Node.js v10 Is Being End-of-Lifed Today, but What Does It All Mean?

Alex Lakatos 🥑 — Fri, 30 Apr 2021 17:07:39 +0000

Any Node.js end-of-life day is a good day, but today especially so! Node.js v10 is being end-of-lifed today, so you can finally support ES6 imports in your JavaScript code examples and libraries by default!

The latest versions of Node.js v12 (not the earlier versions, mind you) support ES6 modules by default, so there is no need to do the ugly hacks you needed to do before if you wanted to write modern JavaScript.

Before

Before, you had to save your code a .mjs instead of js, and then run node with the --experimental-modules flag. Which most Node.js runtimes online were very slow to adopt.

$ node --experimental-modules index.mjs

After

The latest versions of Node.js v12+ support this out of the box, so there is no need to run with a flag. And most Node.js runtimes update to the latest Maintenance release, so they support it as well.

If you want to run on your own hosted environment now you can either:

save the file with a .mjs extension, and run it regularly with node index.mjs
save the file with a regular .js extension, add type: module to your package.json file, and then run the file regularly with node index.js

Changing Old Code

If you're migrating from the old require to the more modern import, there are a couple of things you'll need to do to your files:

change module.exports = avocados into export default avocados
change const avocados = require('avocados') into import avocados from 'avocados'

Most IDEs account for this and help you change it. Like VS Code.

If you want to see it in action on a slightly bigger project, I've switched over the Fidel sample application using things like express, dotenv and axios a little while back, it's all contained in a commit thought so easy to see the changes.

Wait, What is End-of-Life?

"End-of-life" or EOL is a term used by older, more enterprise-focused companies, to let everyone know that they're limiting support or outright not supporting a certain version of their product anymore. You could say the OpenJS Foundation has "pulled the plug" on Node.js v10. 😅

Got Love?

If you've loved the pun at the end, or if you just found this mildly useful, please consider following me on Twitter. I'd be storked. 😅

Adding multi-factor authentication to your app, the easy way

Alex Lakatos 🥑 — Wed, 20 Jan 2021 13:31:19 +0000

First, let’s look at what Multi-Factor Authentication or MFA is. Most applications use a username/password combination to authenticate or log in their users. Some of them use a second method on top of the first, like a token or code sent via SMS. That is commonly called 2FA or two-factor authentication.

In light of countless security breaches across the industry, 2FA is becoming increasingly popular In the event that one of the methods used for authentication is compromised, an additional check will make it more difficult to impersonate a user.

The methods of authenticating users are also called factors, or pieces of evidence required for authentication, which is where the term multi-factor authentication originates.

Multi-factor implies more than one factor is used, so technically 2FA is the minimum number of factors to be used for MFA. Depending on your application’s security level, you can choose to increase the number of factors used to authenticate your users. Before we get ahead of ourselves and ask for ten pieces of data, let’s look at the available options.

The options for authentication factors

Here are the different types of evidence you can ask users to provide: :

Knowledge - Something the user knows — a password, for example. Most authentication mechanisms use this factor. And, usually, it's the only one. Or at least the first one.
Location - Somewhere the user is — the office building, for example. Most corporate networks used to be geofenced back in my day. Still, with the rise of remote work, especially during the pandemic, this factor has severely fallen out of favour. Not to mention, most use cases for MFA work from anywhere in the world, so being locked inside a geographical area might be irrelevant. Location might not necessarily mean geolocation though. In some cases, you can use the IP address as a factor instead. Think about all your “intranet” websites that are only accessible from inside the corporate VPN.
Possession - Something the user has — a token or a phone number, for example. This is the second most commonly used factor. When people talk about 2FA, this factor is usually the second factor (e.g., a second password that is sent via SMS to your phone). Sadly, having worked with SMS for a while, it's only as secure as your phone service provider. While this factor is preferred by someone like your banking provider, that also makes it a great incentive to bypass it, for many bad actors. It's also not free to use, as there is usually a fee associated with sending an SMS.
Proximity - Something the user has — unlocking a Macbook when an Apple Watch is nearby, without using a password, for example. While it's usually used in physical devices, this factor stops being useful for web apps, requiring sensors to work. It also has the inherent flaw that both devices that are supposed to be close to each other can be stolen at the same time.
Biometric - Something the user is or some physical characteristic the user has — the fingerprint or the face, for example. You'll see this as the most commonly used authentication mechanism for phones. When coupled with physical sensors, it's tough to beat. Since biometrics are free, they should be the default mechanism in 2FA. Unfortunately, you need advanced sensors to provide a high degree of security. Earlier versions of Face Detection on phones could be fooled with a person’s picture instead of the actual person, for example.

Again, depending on your application’s security level, you can choose how many factors you need — hence the multi-factor authentication mechanism involved.

What about risk-based authentication?

There is another trend emerging in application security called risk-based authentication (RBA). It relies on multiple factors and spreads out the authentication points based on the current user transaction and the security level needed for that.

RBA is used by companies like Google, Facebook, LinkedIn, and Amazon. For example, posting on Facebook only requires a user to be logged in but accessing profile settings requires an additional factor. The additional factor is usually an IP address or some other data if the IP address you’re using at the moment is not the one you commonly use for your account.

One of the factors that's well suited in both cases, and trending recently, is the biometric authentication factor. It turns out that some other things are just as unique as a fingerprint or your face.

For example, the way you type is pretty unique. So why not use that as an authentication mechanism? It doesn’t seem as easy to compare as a face or a fingerprint. No worries, someone else has done all the heavy lifting for you.

TypingDNA’s typing biometrics technology

Cue TypingDNA. That's right, there is an API that fingerprints people by the way they type. That makes biometric authentication accessible without a physical sensor — and just as secure as a fingerprint. It also happens to be free for your users (e.g., compared to possession factors).

Let's look at how you can add this extra layer of biometric authentication to your multi-factor authentication process.

The TypingDNA API allows you to recognize people by the way they type, both on a keyboard or a mobile device. It also doesn't require any particular hardware or sensor. The SDKs act as recorders for the way users type on web apps and mobile apps. You can check those recordings against a previously saved typing "DNA" — hence the name.

Personally, I've been watching TypingDNA for a while, and I'm impressed with how natural and simple it is to add on top of a traditional username/password authentication model.

An average username/email combination has around 30 characters. That’s plenty of characters to use typing biometrics with a high degree of confidence. You can record and store the typing pattern when a user signs up and then verify the pattern every time they log in. It has the benefit of being a seamless experience. You’re checking two factors in the same step instead of traditional MFA, where each factor requires an extra step.

Implementing with the TypingDNA API

In terms of implementing it, it's a three-part system. The first part is a recorder (TypingDNA provides this) that lives in your application and records the way users type when they perform a certain action, like logging in. The second part is your own back-end server application, and that's where the recorder sends the biometrics data. For the final step, you check that data against the saved biometrics TypingDNA has, using their REST API.

It sounds pretty easy, doesn't it?

It is.

One of the advantages of using this in an MFA flow is that — as opposed to most 2FA solutions — the second step here is invisible to the user. You're using two factors that you're gathering at the same time, so there is no extra step for your users — meaning there are fewer reasons to not complete the verification process. I'd say that is a big user experience win.

This approach can also replace some other existing forms of text or typing verification currently used — like Captcha. Instead of asking someone to type a single garbled word that’s hard to read or click several pictures of bikes, you can ask them to type a provided passphrase.

This way, you’re not only improving the accessibility of your application, but you’re also going the extra mile in verifying the user is “not a robot.” In other words, you’re not only verifying a user is a person but with matching typing patterns, you’re verifying the user is the right person to access your application.

What’s next?

If I’ve convinced you biometric authentication is the future, here are some resources that will help you integrate your application with the TypingDNA API.

First, sign up here. And then use the:

Tutorials to help you get started.
API Documentation to help you when you’re implementing this into your application.
GitHub Repositories full of demos and example implementations.
Case Studies, Webinars, Blog, Whitepapers (and others) in case you need to sell this to your Product Manager first.

Here’s to adding MFA to your applications — the easy way — with TypingDNA!

2020, Thank You!

Alex Lakatos 🥑 — Sat, 09 Jan 2021 18:50:00 +0000

2020 was kind of shit. Go on, it’s OK to admit it. But when I look in the mirror, 2020 was a lot healthier for me than usual. I’ve seen quite a few 2020 reviews this past week. It’s the fashionable thing to do. Hence this is my first yearly review. I’m going to try to use this as a sort of guide for next year. Now, whilst most reviews I’ve read highlighted the things people couldn’t do in 2020, or the exact ways in which it sucked, I made a conscious decision to try to find things that actually went well for me in 2020, and not even mention any of the negative shit 2020 is famous for.

It turns out, I didn’t have to look that hard for things to be thankful for. The DevRel life is full of chaos, so the fact that I didn’t travel for most of 2020 unlocked a lot of possibilities. A lot of those things that kept being pushed to “when I get a change” got done, so truly, thank you, 2020, you haven’t been all shit. And I honestly think I couldn’t have done most of these things if I wasn’t forced to stop travelling. I certainly couldn’t have stopped travelling on my own. My idea of “taking it easy” this year was to have a flight booked every two weeks, instead of the usual two flights a week.

First of All, What Happened in 2020?

// Detect dark theme var iframe = document.getElementById('tweet-1270113634245660674-409'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1270113634245660674&theme=dark" }

👷Switched Over to the Dark Side

There were no cookies🤷. I’ve moved from an individual contributor role at Vonage this year to a manager position at Fidel. And in true Laka fashion, I still refuse to manage people. OK, I did manage a few people for a little while, but I’ve since spent most of my time trying to make myself redundant. Instead of building a team of Developer Advocates, like it’s the fashion, I’ve spent the past six months building a DevRel Culture inside Fidel, trying to make myself redundant.

// Detect dark theme var iframe = document.getElementById('tweet-1315613201703329792-228'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1315613201703329792&theme=dark" }

🏋️33% Less Laka

I lost quite a bit of weight this year. 52 KG (110 Pounds) to be exact, which amounted to 33% of my body mass. There were a few factors that contributed to this one:

I started looking at what I ate. No, it’s not a figure of speech. I literally take a picture of my food before I eat it. It forces me to pause, and figure out if what I have on my plate is right for me. I also used to send that picture to a random stranger I found on the internet and was paying to give me advice about my nutrition. It worked from the very first picture because I was so ashamed with the quantity on my plate, I took part of it off and re-did the picture. Didn’t put the food back on the plate afterwards. The only thing that kept me honest was the eye-watering amount of money I paid for the service, I wasn’t going to pay to cheat.
I started going to the gym. Maybe a little too much, and it’s turning into an addiction. I’ve got 3 sessions a week with a personal trainer, and another 7 without one. The PT sessions are all focused on functional training, while the ones without are all about burning fat in steady-state cardio, usually on a treadmill. Because that allows me to listen to audiobooks or watch things on YouTube, it feels less boring, and it’s currently my happy place.
I did the math. With lockdown happening, I started cooking all my meals instead of eating out. That made it easy to better track what I ate in MyFitnessPal. My Fitbit watch tracks my calories burned during the day, so I started paying closer attention to the difference between what I ate and what I burn. I try really, really hard to make sure I’ve got a deficit of at least 1000 calories a day.

// Detect dark theme var iframe = document.getElementById('tweet-1311639609068212224-161'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1311639609068212224&theme=dark" }

💨Gave up Smoking

As we started going to the gym more and more, the cigarettes began to affect our training. Julia was the first to quit, her training program is a lot more intense than mine. But after a few months of smoking alone, I just didn’t get the same benefits out of it. The negative impact of being the only smoker in the house outweighed the stress release aspect of it. So one day I decided to quit, cold turkey. Of course, that didn’t happen. Just the idea that I was running out of cigarettes sent me into a mild panic attack. I think that’s been hardwired into any smoker out there so deep, that just the idea I was running low was too much to bear.

So I tried tricking the lizard brain inside and bought a fresh pack of smokes. Of which I smoked exactly 5 cigarettes over the course of 3 days. And those were the last I’ve smoked. But I still carry around that unfinished pack of cigarettes with me, everywhere I go. I can smoke any time I want to, I just choose not to smoke. I think that’s the trick that finally helped me to quit smoking. The other time I tried, I lasted a whole of 10 hours without smoking, after which I proceeded to make up for it. It’s been 5 months this time, and hopefully, this one is for good.

// Detect dark theme var iframe = document.getElementById('tweet-1337717723158241280-644'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1337717723158241280&theme=dark" }

🥑36 Issues of the Developer Avocados Weekly Newsletter

As you’ve probably figured out by now, a year has a bit more than 36 weeks. 52 if you must be exact. Why am I celebrating this, though? Because it’s a hell of a lot more than 0. That’s right, in a shit year, with taking a month at a time off from the newsletter, we kept finding the strength and motivation to keep coming back to send it again. Eventually. While we technically made no money from it.

And the fact that we could still find passion in something pre-pandemic, that’s definitely worth celebrating in my book. Oh, and towards the end of the year, we found the energy to run an advent calendar with 24 Developer Avocados, which required us to get out of our comfort zone and reach out to people we haven’t met. Especially in a time when people can’t be expected to give a damn.

// Detect dark theme var iframe = document.getElementById('tweet-1257642627702325250-208'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1257642627702325250&theme=dark" }

🎨Got a New Website

After 4 years, I’ve finally got the time to make a new website. Or at least, I had the time to stand there and look pretty while Hui Jing did all the work. But it’s happened, and it made me want to add more to the website, regularly. I’ve written more articles for it this year than any other so far. The new habit-forming routine I’ve got might have something to do with this as well. So far, I’ve got 73 days in a row of writing 100 words or more. “Science” says that if I got to 66, it’s a habit and here to stay. No matter the outcome, it has certainly helped me write more this year. I think my goal was 12 articles a year for the past few years, but this is the first year I’ve actually managed to do it. And then some. I think I managed to publish 4 articles in a single week, and that’s something I didn’t think I could do.

What About 2021?

😷Survive

Get to the next level, year, whatever. That’s it. That’s the resolution.

If survival seems too achievable, I’ve got a few other things I could try doing.

Create a best-in-class Developer Portal. Open-source it from day 1, so other people could easily use it. I’ll consider this a success if it’s as easy to deploy as it would be to do one of the static-site generators.
Publish every week. I’ve started early on this one. I’ve started writing a minimum of 100 words every day. You can follow along with my progress on Twitter. But I’m hoping that’s going to help me publish 52 articles this year. I’ll consider this goal a success even if it’s 52 articles, and not necessarily one every single week.

How a Good Onboarding is Improving the Developer Experience

Alex Lakatos 🥑 — Wed, 09 Dec 2020 11:16:00 +0000

You've probably noticed the new and shiny Fidel Dashboard we released recently. There were a few reasons we came up with a whole new dashboard experience, and Katherine goes over all those reasons in her blog post. One of those reasons was that new users had trouble quickly unlocking the power of Fidel. When using our API, the "Aha!" moment comes when you see your first test transaction. But getting there wasn't the easiest of journeys for everyone.

We pride ourselves on how easy the Fidel API is to work with and often get feedback on the ease of the integration. That being said, before someone even starts integrating with the API, they tend to explore our dashboard to help them understand how Fidel works.

With our old dashboard, we lost users in the middle of their onboarding because we had no onboarding experience in the Dashboard. We had hoped they would find their way around, but we should’ve been better hosts. Let me walk you through it.

The first thing a user needs to do is create a Program. But, the old dashboard landed people on the Transactions page. And while that is a valid action for all accounts that have gone through the setup steps, because that's where most people need to land, it was proving confusing for first-time users. Let's assume first time users managed to create a Program. They would try to add a Location to that program, but that wasn't possible before first creating a Brand. They needed to figure than one out on their own, and then come back and create a Location. Let's assume some users managed to do that, and create a Location.

Now, you'd imagine you can create one of those fabled test transactions. You couldn't create one on the Transactions tab, you needed to explore around the Dashboard and land on the API Playground tab. And there, you have a menu entry to create your first transaction. In the UI, you'll notice you needed a Program, a Location and a Card.

Wait a minute, we didn't talk about Cards yet. That's because users haven’t added any yet. So users needed to add a Card before they could make a test transaction. On the Dashboard though, we didn't mention that users could only use test card numbers, or what those numbers were for the three card networks: Visa, Mastercard and Amex. Users had to poke around the Fidel Documentation to figure out what those test card numbers were, and then add a test Card. You could add a card both with the UI (which uses the Fidel Web SDK), or in the API playground. After you'd have done all that, congratulations, you could finally create your first test transaction.

As you can imagine, this wasn't an easy discovery journey, and we had quite a few people dropping off at various steps in this user journey. And we couldn't really blame them. Some of them were highly motivated, so they reached out to Support. For those users, we either had to do a bit of handholding or send them to our various blog posts or documentation explaining these steps. The blog posts and the documentation help you get set up using the API without using the Dashboard for most of those steps. While that was proving successful, it was also proving time-consuming for our small team.

We've decided to take all that we learned from those hand-holding sessions and put them into an automated onboarding process that shows up first thing for all new users. Here's a video of it. We'll go through the steps we took, and why in a minute.

We've decided to take a few steps to alleviate these problems:

Instead of having everyone create the same setup data on their own, we are now doing that for every new account. Now every new account gets enough demo data so they can make their first transaction: a demo Program, a demo Brand, 3 Locations in the UK and a Visa test Card. There's also one Auth Transaction in there. We've actually added the new demo data while we were developing the new dashboard, and we saw a slight increase in the number of users that were getting to their first transaction in the old Dashboard.
The second step we took was to add a tour for first-time users on the new dashboard that walks people through the data and explains that:
- Programs are containers, where you add brands, locations and link payment cards.
- Brands are the parent object of Locations and require consent from an authorized merchant to track Transactions in their locations.
- Locations are geolocation data points and you can simply add them to a Program.
- Cards are linked to a Program, and you can conveniently use our SDKs to link cards in your apps.

After the onboarding flow tells you all about the setup blocks and the particularities of running in test mode versus live mode, it drops you off in the new API Playground, where you can make your first test transaction. We've redesigned the API playground as part of the developer experience as well, giving it a more modern look and feel.

The last bit of the onboarding flow is also doing a bit of off-boarding, letting people know they can access more resources for working with the API in the Documentation, on the API reference pages, and on the blog!

Adding this onboarding flow has improved our average “Time to First Transaction” from days to minutes. And because our users are developers, this has been one of the best things we have done to improve the developer experience.

We've got some more things planned, and I don't want to spoil the surprise, so stay tuned for our next little DX chat. In the meantime, feel free to reach out on Twitter or in the Fidel Developer Community forum.

Creating a DevRel Culture

Alex Lakatos 🥑 — Sun, 06 Dec 2020 23:58:00 +0000

How big is your Developer Relations team? I’m betting it’s small, same as mine. Unless you work for Microsoft, Google, Amazon, Twillio or Vonage(The Artists Formerlly Known as Nexmo), it’s pretty hard to justify a double-digits DevRel team. And that’s OK; not everyone needs 70 people to do Developer Relations. It wouldn’t hurt though. Probably that’s why everyone is scrambling to justify their program right about now and to increase their budget for next year.

What happens if you work for a company that can’t afford 10 Developer Advocates? I happen to work for a startup with 60 people; it’s been tough to sell a big team to my CEO. And trust me, I’ve tried.

I talked last week about starting a Developer Relations Program, but it’s still a lot of work for a team of one. My challenge was scaling a DevRel program without increasing the headcount. I’ve achieved that by creating a DevRel Culture instead.

Yeah, you’ve read that right. And it’s not some HR hocus pocus. Creating a DevRel Culture turns out to be highly effective. While you probably can’t have anyone else inside your company that can do all the things you do, it doesn’t mean that you can’t find someone that is more suited to do a little slice of what you do. The trick is finding multiple people, each able to do one aspect of your job better than you. There are quite a few skills required of a Developer Advocate, but most of them are found in other roles within a company. So why not use those for help?

If you haven’t read about my journey to build a 1st-year DevRel Program, let give you some context. I’ve identified a few day-to-day activities that I should be doing, to make a difference. Let’s take a look at those activities, and then see where in the company you could find people to do a better job than you. Basically doing 20% DevRel for 80% of the impact.

Writing the Documentation and API Reference - The engineers writing the feature are good people to document it. Or the product manager that wrote the use case for it. Or the Quality Assurance Engineer that tested it. Depending on the size of your company, you might even have all three of those people to help.
Building SDKs - The engineers that wrote the code for the API can build the SDK wrapper for it as well. And since they write production code every week, they’ll most likely do a better job of it than you.
Create demo applications - You guessed it by now. If it has to do with coding, your Engineering department can probably do a better job than you.
Write blog posts - Anyone, and I mean literally, anyone in the company can write a blog post. Now, it might not come as easy or natural for everyone, but here is where you come in. You’re used to lowerering barriers to entry for developers using your product, why not apply the same principles for writing articles for your blog? No one can fake the authenticity of the people building your product, not even you. So why not have them tell their stories, instead of you? Sure, you’ll get enough pushback, everyone is afraid of writing. So make it easy for them. It’s your job to guide people in writing that first blog post. And try to make it as easier for them as possible. For example, I’ve used an interview format to get people to write their first blog post. I’ve had 30-minute calls with people where they presented their idea, and I’ve had those transcribed and edited into a blog post. I’ve also had people come up with their own ideas and writing them inside the week because they were passionate about it. But most importantly, I’ve bribed everyone involved with limited edition quality swag 😊
Sponsor online events - Your marketing team has probably sponsored a lot more events than you. They’ve been around longer. And their events cost a hell of a lot more than yours. They’ve got all that experience dealing with the event organizers. So ask them for help here!
live-stream on Twitch / Youtube - You’ve got another group of people in the company that are trained for speaking at online events, mainly webinars. And that’s your Sales team. So get them to stream some of their webinars live on Twitch, and see the magic happen.
Give talks at online events - Your CEO probably has a lot of experience pitching your investors. And they probably deliver a quarterly update to your Board of Directors. They’ve also probably dealt with the press before. So they’ve got all the training they need in order to go on stage and tell a compelling story, backed with data. If time is a constraint, you’ve got a backup here. Your Sales team is also used to speaking in front of small groups of people, with lots of slides. Get them to drop the sales pitch, and you’ve got a talk ready to be given, with a trained person ready to do it.
Answer support queries - Your engineers are the people you usually go to with the support queries. So why not eliminate the intermediary (yes, that’s you), and have the support queries go to the on-call engineers right away?
Have customer calls - Your Product Manager is the person you go to with feedback after each call. So why not save yourself the hassle, and have them join those calls to begin with? Sure, maybe they’re not trained to gather feedback, but you can help them out during the first calls, do a bit of handholding, and then take the whole thing off your plate. It’s going to help free you for other things.
Maintain the developer community forum - In here, most questions have to deal with using your product. Your Support people are probably your best bet. They are trained to answer questions coming from existing customers, they can do the same for people who aren’t exactly customers, but who have questions around your APIs.
Create a feedback mechanism between the product and developers using the product - This can be easily solved with technology. Changing the Developer Experience of your product to have a feedback mechanism will save yourself the hassle. The only trick is getting your Product Manager to actually read and action that feedback. I’m kidding, it’s not a trick at all, and they’ll probably thank you for making it easier for them to do their job.
Help with recruitment efforts - Your HR person is better equipped for recruitment purposes, so why not have them help?

I’ve spent the past 6 months at Fidel trying to help other people to do my job, basically trying to make myself redundant. And it’s worked brilliantly! It doesn’t mean I do absolutely nothing now, but it does mean that I provide guidance and review most things before we put them out, instead of trying to do everything, and badly!

I should also mention I come from a culture that relies heavily on… incentive. They’ve tried to legalize bribes a few years back. So I’m quite familiar with using incentives to motivate reluctant people.So if you can’t convince your coworkers that the satisfaction of a job well done is enough…. bribe them! I’m currently using swag as bribes, Rona is preventing me from using a more traditional approach: free lunches and a round at the pub.

If you need help figuring out how to convince people to help, or to introduce you to The Way of The Bribe™️, feel free to DM me on Twitter.