Elite Team of Software Craftsmen - AI, Machine Learning, LLM Agents, Computer Vision, Data Intelligence, Robotics, Cloud, React, React Native, GraphQL development | ST6

ORGANIZATIONS OF THE FUTURE - ST6 Structure - Office circle

Mon, 05 Feb 2024 00:00:00 GMT

We talked about the ST6 structure. In our organization, we operate in circles, not departments.

Now, let's focus on the Office Circle. Here, we know what a 404 error means for everything related to the office and a 429 error while going to the toilets. From coordinated efforts to operational efficiency, we'll share what makes this circle crucial for the seamless functioning of our working environment.

Purpose

Craft and maintain a pleasant and inspiring office space that provides superior comfort, supports the team in achieving excellence and promotes happiness and productivity.

Domain

All maintenance of shared spaces, equipment, and amenities.
New hire's onboarding.
Prepare the seating arrangements and provide equipment for the new hire.

Accountabilities

Ensure that the shared spaces are well-utilized, clean, and well-organized.
Purchase or arrange new equipment and amenities based on the organization's needs.
Prepare the seating arrangements, equipment and peripherals for the new hires.

Let's say this: Office Circle's members are always available to assist when employees need help with anything related to the office space.

We aim to add detailed descriptions of all the tasks, and the circle's members can decide which one they want to handle. Sometimes, some ST6er can be just a guest in the circle. What does that mean? Anyone who wants to help or work on some task can do so without being a member.

We joke that the Office Circle is the 'quietest circle'- its work doesn't always stand out, but without it, our office wouldn't be fun, cosy, and equipped to make people happy.

Oh, the 3D printer broke again. I am going to check it. 🙂

FlyCI is Unleashing the Power of Mac Runners for GitHub Actions

Fri, 08 Dec 2023 00:00:00 GMT

In the ever-evolving landscape of software development, efficiency and cost-effectiveness are paramount. Enter FlyCI, a groundbreaking solution for GitHub Actions, meticulously crafted by the expert team at ST6. Imagine boosting your mobile CI/CD workflows with M1 runners and exclusive access to M2 runners, all while enjoying cost savings of up to 2x compared to traditional options. Let's dive into the details of this game-changing solution.

Benefits

Unprecedented Cost Savings: FlyCI Mac Runners offer a cost-effective alternative to traditional solutions, allowing you to optimize your development budget. With prices up to 2x cheaper than existing options, FlyCI is committed to delivering value without compromising performance.
Exclusive Access to M2 Runners: Stay ahead of the curve with exclusive access to M2 runners, providing you with the latest in Mac hardware technology. FlyCI ensures that your development environment is always equipped with the cutting-edge resources needed to meet the demands of modern software development.
Mind-blowingly Simple Configuration!

Getting Started

Getting started with FlyCI Mac Runners is as easy as entering your email to receive the GitHub App install link. Ready to supercharge your GitHub Actions? Transform your development process - try it for free today!

Usage

Integrating FlyCI Mac Runners into your GitHub workflow is a breeze. With just one simple modification to your existing workflow configuration, you can harness the power of FlyCI's Mac runners. Update your workflow as shown below:

For M1 runners:

jobs:
  ci:
-   runs-on: macos-latest-xlarge
+   runs-on: flyci-macos-latest-xlarge
    steps:
    - name: 👀 Checkout repo
      uses: actions/checkout@v4

For our exclusive M2 runners:

jobs:
  ci:
    runs-on: flyci-macos-large-latest-m2    steps:
      - name: 👀 Checkout repo
        uses: actions/checkout@v4

This single-line change opens up a world of possibilities, seamlessly allowing you to tap into the enhanced capabilities of FlyCI's Mac Runners.

Flexible Pricing

FlyCI offers a flexible pricing structure where you can choose between four plans. Read our blog post introducing the new pricing structure or just check out the pricing page.

Runner Labels

Processor/OS	vCPU	RAM (GB)	Label	Price on FlyCI	Price on GitHub *
M2/macOS 13	4	7	flyci-macos-large-latest-m2	$0.06	$0.08
M2/macOS 13	8	14	flyci-macos-xlarge-latest-m2	$0.12	$0.16
M2/macOS 14	4	7	flyci-macos-14-m2	$0.06	$0.08
M2/macOS 14	8	14	flyci-macos-14-xlarge-m2	$0.12	$0.16

All runners offer 28GB of SSD storage.

*GitHub doesn't offer M2 runners. The prices in the table are for GitHub's M1 runners which are 20% slower than the M2 ones.

Unleash The Power of Mac Runners!

In the fast-paced world of software development, having the right tools can make all the difference. FlyCI Mac Runners offer a cost-effective, cutting-edge solution to elevate your GitHub Actions workflows. With the promise of exclusive access to M2 runners and a user-friendly onboarding process, FlyCI is set to become an indispensable ally in your development journey.

Ready to supercharge your GitHub Actions? Enter your email, get the GitHub App install link, and experience the future of Mac runners with FlyCI, proudly crafted with passion by ST6. Don't miss out on the opportunity to transform your development process - try it for free today!

Integrating Slack with G-Drive, using Google Apps Script

Mon, 14 Aug 2023 00:00:00 GMT

But why?

At ST6 we ❤️ Slack. It enables productivity with its user-centric features and we definitely get the most out of their user groups. We have dedicated user groups for each project, circle, and their respective roles.

We also use G-Drive for organization-related documents where we describe the structure, circle definitions, the roles, their members, and so on. More often than not, we catch ourselves having outdated documents that mislead us about who is a member of what circle and what roles are occupied by whom.

As Slack naturally settled down as the single source of truth for such matters, we decided to solve this once and for all. We are about to use Slack as the source for the relevant data and present it in nice-looking tables and matrices in Google Sheets. Not only this would keep everything in sync, but also provide us with a holistic overview of the building blocks of our organization. Now let's dive right into the solution!

Solution overview

Set up the script environment

Create a new Google Apps Script by clicking "Extentions -> Apps Script" in the Google Sheets document toolbar menu.
From the sidebar editor tab, create a file named appscript.json.

Setup the script metadata with the following "oauthScopes". This allows external http requests via the UrlFetchApp API and updating the spreadsheet content via the SpreadsheetApp API.

{
  "timeZone": "Europe/Sofia",
  "oauthScopes": [
    "https://www.googleapis.com/auth/script.external_request",
    "https://www.googleapis.com/auth/spreadsheets"
  ],
  "runtimeVersion": "V8"
}

Create an index file where we'll place our code.

Get a Slack auth token

Go to api.slack.com/apps.
Click "Create New App -> From scratch" and pick the desired workspace.
From the side menu on your app's page, go to "OAuth & Permissions".
Scroll down to "Scopes -> Bot Token Scopes -> Add an OAuth Scope" and include the following scopes to enable calls to Slack API methods users.list and usergroups.list
- users:read
- usergroups:read
Scroll to the top to "OAuth Tokens for Your Workspace" and click "Install to Workspace".
Copy the "Bot User OAuth Token" for later use in the script.

Retrieve data from Slack

const fetchFromSlack = apiMethod => {
  const apiUrl = `https://slack.com/api/${apiMethod}`;
  const headers = { Authorization: `Bearer <SLACK_AUTH_TOKEN>` };
  const response = UrlFetchApp.fetch(apiUrl, { headers });
  const result = JSON.parse(response.getContentText());

  return result;
};

const getEmployees = () => {
  const { members } = fetchFromSlack('users.list');
  const result = members
    .filter(
      ({
        name,
        deleted,
        is_bot,
        is_app_user,
        is_restricted,
        is_ultra_restricted,
      }) =>
        name !== 'slackbot' &&
        !(
          deleted ||
          is_bot ||
          is_app_user ||
          is_restricted ||
          is_ultra_restricted
        ),
    )
    .map(({ id, profile: { display_name } }) => ({
      id,
      displayName: display_name,
    }));

  return result;
};

const getUserGroupsWithMembers = employees => {
  const employeesById = employees.reduce(
    (result, { id, displayName }) => ({
      ...result,
      [id]: { id, displayName },
    }),
    {},
  );

  const result = fetchFromSlack(
    'usergroups.list?include_users=true',
  ).usergroups.map(
    ({ user_count: membersCount, users: membersIds = [], ...rest }) => ({
      ...rest,
      membersCount,
      members: membersIds.map(id => employeesById[id]),
    }),
  );

  return result;
};

Handle the circles participation table formatting

const formatCirclesParticipation = ({ employees, userGroups }) => {
  const circleHandleSuffix = '-circle';
  const conventionDisclaimerRow = [
    `To display a circle user group, its handle must be suffixed with "${circleHandleSuffix}".`,
  ];
  const circlesGroups = userGroups.filter(({ handle }) =>
    handle.includes(circleHandleSuffix),
  );

  const circleNamesWithMembersCount = circlesGroups.map(
    ({ name, membersCount }) => `${name} (${membersCount})`,
  );
  const tableHeaderRow = ['Name', ...circleNamesWithMembersCount];

  const rows = employees.map(({ displayName }) => {
    const participationChecks = circlesGroups.map(({ members }) =>
      members.find(m => m.displayName === displayName) ? '✅' : null,
    );
    const participationCount = participationChecks.filter(Boolean).length;

    return [`${employeeName} (${participationCount})`, ...participationChecks];
  });

  return [conventionDisclaimerRow, [' '], tableHeaderRow, ...rows];
};

Update the Google Sheet

const updateContent = () => {
  const employees = getEmployees();
  const userGroups = getUserGroupsWithMembers(employees);
  const updatedRows = formatCirclesParticipation({ employees, userGroups });

  // the spreadsheet ID from your sheet document URL e.g.
  // https://docs.google.com/spreadsheets/d/1a2b3c/edit#gid=0 -> id is "1a2b3c"
  const spreadSheetDoc = SpreadsheetApp.openById('<SHEET_DOCUMENT_ID>');
  const [firstSheet] = spreadSheetDoc.getSheets();

  const activeSheet = SpreadsheetApp.setActiveSheet(firstSheet);

  activeSheet.clearContents(); // clears all but keeps existing formatting
  activeSheet.getRange(1, 1).activate();
  updatedRows.forEach(row => activeSheet.appendRow(row));
};

Run the script

Manually - while developing, testing or one-off accidental updates:
1. From Google Apps Script Editor, select the "updateContent" function from the dropdown menu at the top.
2. Click "Run".
3. Watch your sheet getting cleared and updated row by row.
with a time-based trigger - to get a truly automated experience once the script is all set and done:
1. From the sidebar menu select "Triggers".
2. Create a new trigger and for "Select event source", pick "Time-driven".
3. Choose the desired time pattern.

End result

Depending on the formatting you defined via the Google Sheets graphic user interface (GUI), you might end up with something like this:

Bonus tips (security)

Remove hardcoded values for <SLACK_AUTH_TOKEN> and <SHEET_DOCUMENT_ID>.
You can safely store these values as script properties and remove them from the code:
1. Go to your script page and select "Project settings" - the gear icon at the sidebar.
2. Scroll down to the "Script properties" section and add the respective key-value pairs.
3. Then replace the hardcoded values with: PropertiesService.getScriptProperties().getProperty('<YOUR_SCRIPT_PROPERTY_KEY>');
Restrict the usage of the Slack "Bot User OAuth Token" to the Google Scripts IP ranges only:
1. Go back to the Slack app created in the earlier steps and navigate to "OAuth & Permissions" from the sidebar.
2. Scroll down to the "Restrict API Token Usage" section.
3. Enter these IP ranges used for Google Apps Script.
  In case you wonder where these come from, they are buried in this Google docs section.

Final thoughts

At ST6 we use the same approach to generate other tables overviews as well.
We rely on Slack user groups conventions to parse and present the data in an easy-to-view manner.
Here's a glimpse of some circle roles in Slack with their corresponding Google Sheets table:

Slack

Google Sheets

There's definitely room for creativity here. Unleash yours and

Migrating from Bootstrap to Tailwind CSS (part 3)

Wed, 07 Jun 2023 00:00:00 GMT

In the previous article, we went through the different architectural strategies we considered for migrating from Bootstrap to Tailwind CSS, and then I shared the one we chose.

In this article, I will go through the actual execution of the picked strategy and share some anti-patterns and learned lessons throughout the whole experience.

A quick recap of the chosen strategy

Following the previous article, you now know that we chose Strategy 4, where we integrated Tailwind CSS and used it on top of Bootstrap. This way, we could continue delivering features to the end users while updating and styling certain pages step by step with Tailwind CSS.

Using two libraries for styling is an anti-pattern, but it was the most suitable decision, both from a business and technical perspective. For more info about the pros and cons of the strategy, see here.

The tech stack

We extended the old technical stack with the following:

The execution phase

Now, let’s dive into the most exciting part of the series → the execution of our architectural decision (Strategy 4).

Before starting the implementation, we revisited how we used react-bootstrap in the project. We discovered we were referencing it throughout the whole codebase. And this was another anti-pattern we had in our project.

That’s how we came up with Step 1.

Step 1: Isolate `react-bootstrap`

By isolating react-bootstrap in our codebase, we could later replace one component from the package with our implementation. We could do that without updating the files where we used the component.

Consider the following example:

When isolating the Button component, we could replace its implementation in ../components/ui/Button.js with our custom one. We would update only one file. Later, we could substitute react-bootstrap without introducing significant changes in the project.

Yet, we had to update all files that referenced import { Button } from 'react-bootstrap';. That was very risky, and it brought an enormous potential for breaking something.

That's why we moved all react-bootstrap's components into one place.

💡 Isolate dependencies.

Step 2: Integrate Tailwind CSS

We followed the tailwindcss installation guide to install and configure it in our project.

But, we did two crucial changes in our configuration:

We turned off the preflight mode to disable the default styling coming from Tailwind CSS.
We added a custom prefix to all Tailwind CSS classes, so as not to have any collisions with the Bootstrap ones.

This enabled us to use classes both from Bootstrap and Tailwind CSS at the same time without interference. For example:

<span className="mt-2 ms-px-2 ms-text-amber-300 ms-border">Hello World!</span>

Step 3: Rewrite components when possible

In Steps 1 and 2, we isolated react-bootstrap components into a single place, and we configured Tailwind CSS. Next, we sought opportunities to extract reusable React components styled with Tailwind CSS.

Since we would be creating new React components, we decided to split them into two categories:

Generic Components styled with Tailwind CSS. Our goal was to prepare for creating a Reusable React Component UI Library, which we could use throughout our client's projects in the future.
Domain Components tailored to our Domain and used throughout the pages in the current web application.

To better illustrate the idea, consider the image bellow:

In this example, we can have a generic Button component and a LoadingButton as a Domain Button component.

💡 A key principle we followed was Atomic Design, where we’re not designing pages; we’re designing systems of components.

Also, we didn’t change the components’ APIs. We followed the ones from react-bootstrap because we didn’t want to introduce many changes at once, only style updates.

One key aspect of this step was using twin.macro to have tailwindcss classes in our styled-components.

This is how we rewrote react-bootstrap's Badge component to use Tailwind CSS and keep the same API.

import React, { forwardRef } from 'react';
import PropTypes from 'prop-types';
import cx from 'classnames';
import styled from '@emotion/styled/macro';
import tw from 'twin.macro';

const StyledBadge = styled('span')`
    ${tw`ms-px-2 ms-py-1 ms-inline-flex ... ...`}

    &.primary {
        ${tw`ms-bg-primary-100 ms-text-primary-500`}
    }

		...

    &.pill {
        ${tw`ms-rounded-full`}
    }

    &.xs {
        ${tw`ms-text-xs`}
    }

    ...
`;

const Badge = forwardRef(
  ({ className, as, variant, size, pill, ...props }, ref) => (
    <StyledBadge
      {...props}
      ref={ref}
      className={cx('ms-badge', className, variant, size, {
        pill,
      })}
      as={as}
    />
  ),
);

Badge.propTypes = {
  className: PropTypes.string,
  pill: PropTypes.bool,
  variant: PropTypes.string,
  size: PropTypes.string,
  as: PropTypes.elementType,
};

Badge.defaultProps = {
  className: '',
  pill: false,
  variant: 'primary',
  size: undefined,
  as: 'span',
};

export default Badge;

In the end, our Folder Structure looked like this:

/src
│   ...
|   ...
│   AppRoutes.js
│
└───components         --> reusable Domain Components used throughout the Pages
│   │   Header.js
│   │   ...
│   └───ui             --> Generic Components (preparing for UI lib)
│       │   index.js
│       │   Button.js
|       |   Badge.js
│       │   ...
└───pages              --> actual Pages on our web app
│   │   ...
│   └───login
│       │   index.js
│       │   ...
└───...
│
└───...

Conclusion

I hope you enjoyed the Migrating from Bootstrap to Tailwind CSS blog post series. We explored different architectural strategies for migrating from one UI library to another. Along the way, we learned something new, like the importance of conducting good research before implementing а specific architectural decision, and isolating dependencies. We also discovered how to use Tailwind CSS in our styled components. The experience taught us valuable lessons in achieving maintainability, good software architecture, and project structure, and avoiding potential anti-patterns.

There are a few pieces of practical advice I'd like to point out:

Strive for incremental improvements. Rome was not built in a day. Neither will be your “perfect” application, so having some “bad code” is okay.
Be careful about anti-patterns and code smells. Try to avoid them in advance.

💡 Sometimes you can accept having an anti-pattern in your codebase but you should be very aware of why you have it and at what cost.

If you liked my blog posts, you can follow me on LinkedIn and Twitter, where I share coding tips daily. Hope to see you there.

Supercharging GitHub Actions: Leveraging Jetson Nano's Hardware in a Self-Hosted Runner

Fri, 02 Jun 2023 00:00:00 GMT

GitHub Actions is a powerful tool for automating software development workflows, but it does have some limitations when it comes to hardware resources. The default GitHub-hosted runners are virtual machines running on the GitHub infrastructure, which means they have predefined specifications and limitations that may not be suitable for all use cases.

GitHub Actions limitations

Limited processing power: GitHub-hosted runners have predefined CPU and memory limits. These limits are typically sufficient for most workflows, but if your workflow requires heavy computation or resource-intensive tasks, such as training machine learning models or running simulations, the limited processing power of GitHub-hosted runners may become a bottleneck.
No GPU support: GitHub-hosted runners do not provide access to GPUs. GPUs are crucial for tasks like deep learning, computer vision, and other GPU-accelerated computations. Without GPU support, you may not be able to take advantage of the full potential of your workflows that require GPU resources.
Specific software dependencies: GitHub-hosted runners come with a predefined set of software dependencies and tools. If your workflow requires specific software versions or custom configurations, you may face limitations or compatibility issues with the default runners.

Our problem

Our specific challenge revolves around running automation scripts on our custom hardware, which is based on an ARM chipset. These scripts encompass various tasks like smoke tests, packaging, and Docker image generation. Running them on our ARM-based custom hardware enables us to validate the software's performance, behavior, and seamless integration with the specific hardware architecture.

However, the default GitHub-hosted runners do not support our custom hardware, posing a significant obstacle. Consequently, comprehensive testing and validation become challenging, hindering the accuracy of our automation processes when using GitHub Actions.

Solution

By setting up a self-hosted runner on NVIDIA's Jetson Nano, you can leverage the Jetson Nano's AI capabilities and low-power consumption for running your GitHub Actions workflows. The Jetson Nano is a small, single-board computer designed for AI and robotics applications. It features a CUDA-enabled GPU, which can significantly accelerate AI workloads.

With a self-hosted runner on the Jetson Nano, you can perform tasks that require GPU acceleration, run resource-intensive computations, and take advantage of the Jetson Nano's hardware capabilities in your workflows. This allows you to overcome the limitations imposed by the default GitHub-hosted runners and unlock the full potential of your development and deployment processes.

Prerequisites

Jetson Nano (In this example running on Ubuntu 18.04 Jetpack L4T 32.7.3)
Basic knowledge of GitHub Actions and the concepts of self-hosted runners
Basic knowledge of Docker and containerization

Step 1: Prepare the Jetson host

Install Docker.
Install Nvidia Runtime. NVIDIA Container Runtime for Docker (previously known as "nvidia-docker") is a software tool specifically designed to enable the use of NVIDIA GPUs within Docker containers. It serves as a bridge between Docker and the NVIDIA GPU drivers, allowing containerized applications to seamlessly access and utilize the computational power of NVIDIA GPUs.

apt-get install nvidia-container-runtime=3.7.0-1

I experienced some problems with newer versions on Ubuntu 18.04.

Make sure that /etc/docker/daemon.json has the configuration that enables running the Nvidia Container Runtime.

"runtimes": {
    "nvidia": {
        "path": "nvidia-container-runtime",
        "runtimeArgs": []
    }
},

apt-get install nvidia-container-csv-cudnn
apt-get install nvidia-container-csv-tensorrt
apt-get install nvidia-container-csv-cuda

These packages, are necessary to ensure that a container utilizes the underlying host's CUDA, cuDNN, and TensorRT software stack. Installing these packages results in the creation of CSV files, which can be found under /etc/nvidia-container-runtime/host-files-for-container.d. These CSV files contain the paths to the corresponding libraries, which are then attached to the Docker container by the NVIDIA Container Runtime.

In summary, these packages are crucial for establishing the connection between the container and the host's CUDA, cuDNN, and TensorRT libraries. The CSV files facilitate the inclusion of the necessary libraries within the container, enabling it to access and utilize these software components provided by the host.

Restart docker.

systemctl restart docker.service

Step 2: Create and build a runner image

Create a Dockerfile.

FROM nvcr.io/nvidia/l4t-base:r32.7.1

ENV TZ=Europe/Sofia
ENV DEBIAN_FRONTEND=noninteractive
ENV CUDA_HOME="/usr/local/cuda"
ENV PATH="/usr/local/cuda/bin:/home/myuser/.local/bin:${PATH}"
ENV LD_LIBRARY_PATH="/usr/local/cuda/lib64:/usr/local/lib:/usr/lib/aarch64-linux-gnu:${LD_LIBRARY_PATH}"
ENV LLVM_CONFIG="/usr/bin/llvm-config-9"
ENV RUNNER_LABELS="self-hosted-jetson"
ENV REPO_URL='<repo_url>'

# Install dependencies
RUN apt-get update && \
    apt-get install -y \
    curl \
    build-essential \
    sudo \
    # extra dependencies \
    && rm -rf /var/lib/apt/lists/*

# Add a non-root user
RUN useradd -m myuser
# The GPU (for hardware accelerated access) requires the user be a member of group “video”. This is true for both GUI and CUDA use.
RUN usermod -aG sudo,video myuser

# Set the working directory and give ownership to the new user
WORKDIR /runner
RUN chown -R myuser:myuser /runner
RUN echo 'myuser:myuser' | sudo chpasswd

# Switch to the new user
USER myuser

# Download the GitHub runner package and install it. Get the latest version from github.com
RUN curl -o actions-runner-linux-arm64-2.304.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.304.0/actions-runner-linux-arm64-2.304.0.tar.gz \
    && echo "34c49bd0e294abce6e4a073627ed60dc2f31eee970c13d389b704697724b31c6  actions-runner-linux-arm64-2.304.0.tar.gz" | shasum -a 256 -c \
    && tar xzf ./actions-runner-linux-arm64-2.304.0.tar.gz

CMD ["/bin/bash", "-c", "(./config.sh --token $GITHUB_TOKEN --labels $RUNNER_LABELS --url $REPO_URL --unattended && /runner/bin/runsvc.sh)"]

Build the image. Make sure to execute this from the Dockerfile directory

docker -t my-nano-runner .

Step 3: Create a registration token from the GitHub UI

Navigate to your repository.
Go to Settings -> Actions -> Runners.
Click New self-hosted runner in the top right corner.
Select linux as runner image and "ARM64" as the architecture.
Copy the token from the Configure section.

./config.sh --url https://github.com/<entity>/<repo> --token <registration token>

We are using the token in the next step.

Step 4: Start a runner container

docker run -d  \
--gpus all --runtime nvidia \
-e GITHUB_TOKEN=$GITHUB_TOKEN ${RUNNER_LABELS:+ -e RUNNER_LABELS=$RUNNER_LABELS} \
my-nano-runner:latest

--gpus all flag: Shares all host GPUs with the container. This option enables the container to access and utilize the computational power of all available GPUs on the host machine.
--runtime nvidia flag: Specifies the NVIDIA Container Runtime as the runtime for the container. This ensures that the container can effectively utilize NVIDIA GPUs and access related NVIDIA software, such as CUDA and cuDNN. The flag can be omitted if the runtime is already configured in the docker config file.

See https://github.com/<entity>/<repo>/settings/actions/runners to check the status of the runner. At this point, the runner should be idle and ready to execute workflows triggered by GitHub Actions.

Step 5: Use our runner in a workflow

Apply the runner label defined in the previous steps to use our new self-hosted runner in a workflow.

jobs:
  job-name:
    runs-on: self-hosted-jetson

Common problems

Updating runners
By default, GitHub runners are self-updating which takes them offline during the process. There is a --disableupdate flag that can be used to disable the updates but in this case the runner should be updated manually within 30 days.
Not enough space on the host
You may need to expand the Nano storage with a USB card and change the default Docker storage directory if there is not enough space available on the root storage. For example, this is usually the case with carrier boards that use eMMC storage. On these, the eMMC storage is 16GB and installing NVIDIA JetPack 4.6.3 consumes 11.6 GB of it. You can check out this article for minimizing storage usage on Jetson.
Accessing the Nano L4T image may require authentication with Docker using your NVIDIA Developer account.
The different versions of Jetpack and Ubuntu will have their own quirks. Be prepared to dig through the Nvidia forums when the path is not smooth

Conclusion

This guide provided a basic setup for using the Jetson Nano as a self-hosted runner. For more advanced scenarios, you can explore options such as using orchestration tools to provision runner containers on-demand or using Ansible to provision different hosts with specific configurations.

Stay tuned to our blog for these exciting follow-up articles! By delving into these advanced scenarios, you'll unlock the full potential of the Jetson Nano as a self-hosted runner and take your GitHub Actions workflows to new heights.

Migrating from Bootstrap to Tailwind CSS (part 2)

Tue, 28 Feb 2023 00:00:00 GMT

In the previous article, we got familiar with the business case behind the migration from Bootstrap to Tailwind CSS, the two libraries and the difference between them. I also shared my personal opinion of using the two technologies.

In this article, I will discuss the pros and cons of the architectural strategies we considered during the migration.

Starting point

Prior to the migration, we had a single-page app (SPA) created with Create React App (CRA) and the following packages:

React 16
Bootstrap 4, React-Bootstrap
Classnames, Polished, Emotion (styled-components)
React-Query, Axios
Jest, React-Testing-Library, MSW
Formik
and others

To get the most out of this article, you need to be familiar with these technologies.

Research phase

After some ideation, we came up with four strategies/options to migrate from Bootstrap to Tailwind CSS. We evaluated each by listing the positive and negative sides and creating a quick SPIKE to have a broader view of the potential pitfalls. This way, we can make the most informed decision.

💡 Look before you leap.

Strategy 1: Complete rewrite of the app

from Bootstrap to Tailwind CSS.

Pros (➕):

nice, sweet, and clean - We won't have any dirty stuff and workarounds by rebuilding the project from scratch.

Cons (➖):

time & $$$ - It will cost a lot of time and money to rebuild the project using the new UI library.
no value for the end customers - For some time, we won’t be able to implement new features and deliver any customer value.

Strategy 2: Update Bootstrap’s variables and theme

so they resonate with Tailwind CSS’s default theme and continue developing new features with Tailwind CSS. For more info, check this section in the previous article.

Pros (➕):

customer value - We can deliver customer value and features while integrating and using the two frameworks.
save time and $$$ (maybe) - Instead of completely rewriting the app, we can integrate and use both libraries incrementally. We will waste considerable time and money if we have the bugs mentioned in the cons section.

Cons (➖):

class and style mismatches - We might end up having classes with the same names from the two libraries leading to unexpected styles in the end and making it hard to debug.
hard to update the theme - There are just too many things to cover and there’s always the risk of missing something.
big risk for potential issues - The risk for future problems and hard debugging is enormous.
hard to replace Bootstrap later - By mixing both libraries in our components and pages, it will become complicated to remove Bootstrap after that because everything will be coupled → spaghetti code 🍝.

Strategy 3: Create a Component Library

based on our Design Language System (DLS) with Tailwind CSS and use it throughout the different client projects, starting from the current one.

Pros (➕):

Design Language System ready to be used throughout the different projects and products - Having a DLS will be a huge benefit, so we can have the same look and feel throughout the different customer product lines.
nice, sweet and clean - We will have clean code. Everything will be decoupled and properly configured.

Cons (➖):

time and $$$ to develop and integrate
no value for the end customers

Strategy 4: Integrate Tailwind CSS

and use it on top of Bootstrap. As part of this strategy we decided to look for opportunities to extract reusable atomic React components styled with Tailwind CSS and prepare for the DLS.

Pros (➕):

customer value
save time and $$$
remove Bootstrap later - By rightly integrating Tailwind CSS, we can lay the foundations for later removing Bootstrap with ease.

Cons (➖):

class and style mismatches
messy and ugly
anti-pattern - That’s an anti-pattern because we will be using two completely different libraries for the same thing (styling) in the same project.

In the end, we decided to go with Strategy 4. We can start using Tailwind CSS, update the pages step by step, and simultaneously deliver new features to the end customers, so we don’t stop providing customer value.

The enablers

Going through an extensive exploration phase, we found two enablers for implementing Strategy 4. These are:

Tailwind CSS’s prefix and preflight configurations.
- We can add a custom prefix to all Tailwind CSS classes, so we don’t have any collisions with the Bootstrap ones.
- Disable the default styling.
twin.macro.
- We can use CSS classes with our styled-components.

Because of them, we managed to create the component below:

const StyledBadge = styled('span')`
	${tw`ms-px-2 ms-text-amber-300 ...`}
`;

const Badge = (...) => {
  ...
  return (
    <StyledBadge ...>
      ...
    </StyledBadge>;
  );
};

For more on the implementation, see part 3 of the series.

Conclusion

To summarize, before tackling a problem or proceeding with an architectural decision, it’s a good practice to spend some time planning, researching and developing in a time-boxed manner. This way, the chances of getting the most suitable decision for your case increase.

💡 There’s no silver bullet for every problem or situation. That’s why good exploration sets the path to success. In the end, it’s all about tradeoffs.

Stay tuned for the next article in the series, where I will go through the execution part of the chosen strategy, how we leveraged the enablers and some anti-patterns we went through.

Migrating from Bootstrap to Tailwind CSS (part 1)

Tue, 18 Oct 2022 00:00:00 GMT

In this article, I will set the stage for the entire series. I will go over WHY we migrated from Bootstrap to Tailwind CSS, and share my thoughts on the pros and cons of the two technologies.

Why did we have to migrate from Bootstrap to Tailwind CSS?

In a nutshell, our customer wanted to introduce a fresher look and feel to their website to meet their business needs. They decided to start with the basics and engaged another agency to craft a new design system, which would lay at the heart of the update. The agency chose to work with Tailwind CSS and its default theme. This required us to migrate from Bootstrap to Tailwind CSS.

The following two screenshots are from the customer’s design system.

The color palette.

The button component with its different states.

How do Bootstrap and Tailwind compare from my point of view?

Let's begin by saying a few words about the two technologies.

Bootstrap is a giant collection of handy, reusable bits of HTML, CSS, and JavaScript code. Currently, that’s the most popular frontend toolkit for developing responsive, mobile-first projects on the web.

After you install Bootstrap in your project, you can start using a bunch of variables, mixins, etc., in your components.

On the left side, you can see the different files that come with Bootstrap, and on the right, an example of the Bootstrap's button class and what it includes.

Okay, but what about Tailwind CSS?

Tailwind CSS is a bunch of many single-purpose classes and functions where each does basically only one thing. That way, the framework lets you build highly customizable user interfaces with less fuss than some of the other solutions out there. It gives you many utility functions and classes you need to develop great designs without any opinionated styles.

That’s a screenshot from the official Tailwind CSS website. You can see on the right what type of code and classes you must apply to have the user interface on the left. I think you sense it.

Then, which one should a developer choose? Well, it depends. 🤷‍♂️

After spending some time with both technologies, here’s my personal opinion.

Bootstrap’s strongest sides are:

UI components that you could easily use
Out-of-the-box responsiveness

You can quickly create user interfaces that look good and are responsive, so in the end, the pages you create look okay on smaller devices like tablets, mobile phones, etc.

Tailwind CSS’s strongest sides are:

Highly customizable: you can combine different utility classes and create custom UI components.
You can easily create a Design Language System (DLS) tailored to your business, projects, brand, etc.

💡 Having said all that, these two UI frameworks have different ideologies and solve different problems.

With Bootstrap, you can easily and quickly develop standard-looking user interfaces because you have many components out-of-the-box ready to use. However, customization is another (and more difficult) matter altogether.

On the other hand, working with Tailwind CSS is difficult initially because you have to manually create your own reusable UI components. There are a lot of utility classes that you can go through and combine. At the same time, you have the flexibility to create and customize whatever you want.

Conclusion

To summarize, I will go with Bootstrap when I want to quickly create basic pages, Minimum Viable Products, etc. I will choose Tailwind CSS when I want to create a separate UI library and design language system for a consistent brand experience throughout projects and products.

Stay tuned for the next article in the series, where I will discuss the pros and cons of the architectural strategies we considered during the migration.

Weekly Knowledge Sharing - What You Need to Know

Fri, 22 Jul 2022 00:00:00 GMT

There is more to being part of ST6 than merely ‘’doing the job’’. It is instead being part of a society where culture truly matters and is one of the fundamental pillars on which everything is based. To make our culture thrive, we have established several ‘’traditions’’. One fragment of the latter is our weekly knowledge-sharing sessions.

Knowledge is power

The influence of knowledge is undoubtedly immense. From improving brain function through critical thinking to simply sharpening your skills, knowledge has proved to be essential in human development. At ST6, we believe that knowledge is power, as the old adage goes. Hence, why we are so devoted to implementing various knowledge sharing initiatives in the workplace. One of these happens to be the weekly knowledge sharing sessions. We see this as a positive asset to our culture as knowledge sharing has proven to be quite efficient in enhancing the collective ability of the entire team to understand different concepts better. Essentially, these initiatives are also helping us to improve our internal communication and create an even stronger bond with each other. We are delighted to share more insight for our weekly knowledge sharing sessions.

Every week at ST6 we have knowledge sharing sessions. These occasions are meant to gather the team together to present and discuss topics and ideas of different nature. The primary objective at the beginning was sharing technical knowledge, i.e., sharing a new technology experience, a tool that might be useful for work, or simply a crafting experience. However, with time the focus gradually shifted towards knowledge sharing in other areas. For instance, one of the novelties is the hot seat. Whoever has the ba… pardon, courage to step up gets the chance to present a bit more about themselves. They can talk about their background, life achievements, education, and overall development in the past years; in other words, they share a fragment of their lives with other ST6ers.

Perhaps you now begin to understand that everything we do at ST6 comes with a meaning and a purpose. It is not just a 60-minute presentation. It is a way of sharing something that excites us and inspires us to grow as individuals and as an organization as a whole. Regular knowledge sharing sessions are great occasions for us to gather together and indulge in an open and honest discussion.

Would you like to be the next weekly knowledge sharing presenter? Share your ideas for a knowledge sharing session in the comments below.

Introducing Our NON-Q and Monthly Gatherings

Mon, 11 Jul 2022 00:00:00 GMT

Could it actually be any different than the traditional quarterly gatherings we are all used to? Yes, it certainly can, and it brings many benefits. Read along to indulge even more profoundly in our culture.

Meetings, yes, we all "love" them and often joke about how most of them could have eventually been an email. While this might be the case in traditional organizations, it certainly isn't one here at ST6. Since it is the time of another one of our monthly gatherings, we thought we'd share some insight into what these meetings represent in our organization. In the following lines, we will focus on two types of gatherings that occur throughout the year: NON-Q and monthly gatherings.

NON-Q gatherings

NON-Q gatherings at ST6 could be defined as a mixture of all traditional definitions for quarterly meetings that you have heard before. We took the concepts of quarterly business reviews (QBR) and all-hands meetings and added a pinch of ST6 spirit to them to create the perfect NON-Q gathering to fit our culture. After all, no one likes to see their team with drooping eyes drawing doodles while slowly falling asleep. To be fair, there is much more potential in such gatherings than most people imagine, which is why we took a different approach. Here's the arsenal of our secret weapons that helped us make quarterly meetings more effective and exhilarating.

With a meeting cadence of two times per year, NON-Q gatherings at ST6 are rather big and exciting events. An entire day filled with ideas and knowledge sharing, financial overviews, jokes, and lots of food. The primary goal here is transparency. We have already talked about radical transparency being a fundamental pillar in ST6's culture. So, the most logical thing was to base NON-Q gatherings entirely on that principle.

A typical meeting of this kind starts with breakfast and some chit-chat. Moving on to the presentation segment, we usually start with a review of what we have achieved in the past six months, or in other words, a pat on the back moment. The company strategy is also discussed at this point of the gathering. The focus then shifts to the Circles, where each circle champion comes forward and talks about the things that have happened within that particular circle. Here we discuss the future goals of the circles, as well as what were the lessons learned from previously executed tasks. Towards the end of the presentation segment, we get to the financial overview, followed by a discussion of different topics that intrigue us. Everything ends with a generous lunch probably similar to the ones that royalties like Henry VIII used to have.

Monthly gatherings

As suggested by the name, monthly gatherings happen every month. Similar to the concept of NON-Q gatherings, here we gather for an hour to talk about the success and highlights of each circle and the projects we are working on. A monthly sync-up allows us to communicate any upcoming changes and update each other as needed. Sometimes we have monthly meetings for the overall improvement of the workflow at the organization.

We will meet you there!

Now you know how gatherings are carried out at ST6. We believe that transparency is a crucial asset for every organization, and so we strive to implement it in everything we do. Transparency in gatherings allows us to share everything there is to be known with every member of our team. We must all be on the same page and understand why certain decisions are made and what lessons could be learned from the outcomes. And to answer the question we posed at the beginning of the post—yes, quarterlies can most certainly be done differently and with every member of the organization involved and engaged more than ever before. If you like the idea and want to be a part of it, we are looking forward to seeing you at one of our next gatherings!

Meet the ST6ers - Iliyan

Mon, 22 Nov 2021 00:00:00 GMT

Why did you join ST6?

At the beginning of my career, I was as eager to learn and grow professionally as a junior in the field can be. Surprise, surprise :). It was 2017 at my previous workplace when I was fortunate enough to work with Niki Valchev. He was THE right software craftsman for that job! Thanks to him, I was able to learn and grow at the pace I was striving for. But this isn't the best part. The whole process was what I appreciated the most. We had regular sync meetings, we were open, honest, and direct with each other. The only motivation behind this was the common goal—to do things better as a team and help each other grow professionally. Later that year ST6 was founded by his former colleagues. They played a vital role in his career growth. Niki was offered to join as one of the first ST6ers, and so he did. I was both happy for him and a little sad that the role model I had was leaving.

Before he left, he told me: "Get your sh*t together and sooner rather than later, you'll be the ST6er we would love to have on board". We stayed in touch and he told me a lot of intriguing things about ST6—top-notch software craftsmen to learn from, no bosses, transparent salaries, etc. It sounded like a nice place to be. Fast-forward to 2019 and I started my journey with one of the best software craftsmen out there, in a very promising environment that seemed aligned with my beliefs and values. Sounds like it's all rainbows and sunshine, but it's not. It's more like "tough love" :). Why? Keep reading.

What do you like most about working at the organization?

The "A" players

There are plenty of role models within the organization that I can learn from. Having many smart and highly opinionated people on all varieties of topics has a downside, though. Knowing when to keep your opinion to yourself is a vital skill that some of us (well, most of us ¯\_(ツ)_/¯) need to master. Combine this with the radically transparent culture we have and the challenge becomes even bigger. It's not easy, but it's worth it. This is where the "tough love" part comes but also where the growth happens.

The freedom to do what I'm passionate about

At least in the context of the organization, of course. We all have a profession, but everyone has other superpowers too. Besides my interest in the software field, I'm also interested in psychology and neuroscience. That's why I'm part of our Recruiting circle. Now you might be like: "So, you're a software craftsman and an HR?!".

Well, I'm not. I only work on tasks I can bring value to, like our careers page, for example. Two years ago there were only 3 job offers—no more, no less. As a typical software craftsman, I started with research about what a good careers page is supposed to look like. And here we are with two more sections—"What drives us" and "Our perks". Leading a similar effort end-to-end and looking back once it's done, feels pretty damn satisfying :). Thank you, Fatme and Iva, for giving me a hand with this effort!
Of course, all of this doesn't play well when it's rough and tough with deadlines looming over our heads in the project. In such cases, you have to act accordingly. For example, we had an important release coming and I left the Recruiting circle for a while, so I could entirely focus on the upcoming release. A few months later, once I had pulled myself together and felt ready to contribute again, I returned back to the Recruiting circle.

The challenges, both professional and personal

I took part in several projects. Most of them were built from the ground up and some were a full rewrite plus additional features. My contribution is mostly on the front end, but I don't mind getting my hands dirty with infrastructure or backend tasks.

Human Design matching social platform (mobile)
Fin-tech platform helping businesses optimize their payments (web)
Shipping platform helping customers get their packages safely delivered (web & mobile)
Our website ST6.io

Technologies:
Node.js, TypeScript, React, Gatsby, React Native, xstyled, jest, Detox, Playwright, AWS CDK, fastify, GraphQL, Apollo.

The personal challenges come in different shapes and frameworks. The one I've tried and would recommend is the "immunity to change map". TL;DR; it's a tool to help you overcome and change behaviors that go against who you want to be. It helped me overcome the defensive mode I used to dive in, when faced with an opposing point of view or some feedback that I had received.

Klasik Klasikovich picnic team buildings

Like the one from the cover photo. Adds +5 authenticity to the blogpost, doesn't it? 😃

What would you say are some of the biggest challenges you face at ST6?

Leaving behind the corporate baggage you carry from your previous workplaces. It's pretty different how everything operates here. Switching the mindset from a follower to a leader is both challenging and exciting!
Knowing when to speak up, and more importantly when NOT to. The latter is the bigger challenge when you're surrounded by highly opinionated people, as I already mentioned.
One of the words we most relate to is "feedback". We have tons of it. It flies in every direction. We even have a dedicated whiteboard where we write down every kind/class of feedback we encounter over time. Learning how to give and receive it is also something most of us yet need to master.

Show the best meme you have in your phone

Check our careers page, join the ST6 team, and bring your whole self!

ORGANIZATIONS OF THE FUTURE - ST6 Structure - Recruiting circle

Wed, 18 Aug 2021 00:00:00 GMT

In our previous blog post, we talked about the ST6 structure and circles in general. Now it's time to get in more details about each circle. Today's topic is the Recruiting circle - its purpose, domain, goal and responsibilities!

Purpose Craft a revolutionary selection process that would find the best talent fitting for our culture and organization.

Goal Grow the ST6 team.

Domain

Identify the people we would like to recruit.
Drive, organize, and improve the end-to-end recruitment process.

Accountabilities

Manage all communication with candidates, and facilitate each step from the end-to-end recruiting process.
Ensure diversity by attracting different interview attendees.
Compose inspiring job offers that reflect the current needs of our organization.
Gain more exposure, attract, and engage future ST6ers.
Establish recruiting best practices.
Create an efficient and innovative selection process.

Enough governance for now.

Reading so far, you probably think this should be the HR department. Well...no. As we mentioned before, each ST6er can participate in any circle they want, no matter their role or background. The important thing is what inspires you and where you want to contribute. So here are the recruiting circle members:

Krisi (Software Craftswoman)
Dimitar (Software Craftsman)
Fatme (Software Craftswoman)
Petar (Software Craftsman)
Lidia (Office Happiness Champion)
Spasena (Talent & Operations Craftswoman)
Iliyan (Software Craftsman)

More about the team here.

The Circle's Champion is Spasena, and the Circle's Secretary is Fatme.

We have other circle-specific roles like Tech Task Reviewer, Candidate's Coordinator, New Position Champion, GDPR Master, and Candidate's Champion. We have more roles and governance yet to be defined, so let's, for now, focus on the Candidate's Champion Role, as this is a role each one of us takes.

The Candidate's Champion is the main point of contact between the candidate and ST6. They assure consistent and transparent dialog and guarantee an end-to-end recruitment journey that resonates with every ST6 value. All of the circle members rotate through this role in a particular order. And thus, each candidate has a different champion.

Currently, we have plenty of open positions, and we are very actively looking for our new ST6ers.

What do we look for in a candidate?

A passion and excitement for your craft. You love what you do and have fun doing it.
A desire for solving problems.
A self-awareness to embrace the failures.
A belief in pursuing a common goal as a team.
A conscious desire to work in an environment with open and transparent information.

What is our interview process?

15-30min Say Hi!—We know the whole process is inherently stressful, so we start with a brief, informal video call to break the ice and say Hi.

1-3h Cultural Talk—You are a very cool person, and we are a very cool organization, but what's most important here is how well we click.

Technical Task—This depends on the position you are applying for. We usually do not place restrictions on the technologies you can use and we do not set a deadline for the implementation. The most important thing for us is for your solution to be well crafted. :)

1-4h Technical Talk—Being the geeks that we are, let's dig deep together into some practical and theoretical problems and how you'd tackle them.

We know it sounds scary, but we promise you it's all worth it. :) We are pretty friendly and fun. :)

If you have already been in a recruitment process with us, and you have feedback, if you want to apply, and you have questions, or you want to chat and know more - write to us :).

ORGANIZATIONS OF THE FUTURE - ST6 Structure

Thu, 01 Jul 2021 00:00:00 GMT

You can often hear us saying we are “an organization of the future,” a #noboss organization… and we operate in circles instead of departments like most organizations. What do we really mean?

ST6 follows the Sociocracy guide for building organizations of the future and is organized into circles.

Original image from A Practical Guide for Evolving Agile and Resilient Organizations with Sociocracy 3.0.

Each circle has its domain, accountabilities, members, meetings, roles, assigned people into the roles, Trello board, meeting notes, and Slack channel.

Each circle has a Champion and a Secretary.

Let’s talk in details about the roles:

The Champion’s purpose is to facilitate the smooth operation of the circle, to engage the circle to ideate, implement, and participate in exciting, productive, and efficient initiatives related to the circle domain.

The Champion’s domain is the day-to-day operations of the circle, and long and short-term circle strategy and strategic initiatives.

The Champion’s accountabilities include:

coordinate and facilitate the execution of the strategy of the whole organization through the domain of the circle
organize and facilitate regular circle meetings
organize and facilitate retrospectives and planning initiatives
manage the circle’s calendar and Trello board
ensure the circle activities and decisions are communicated to the organization through the respective channels, like Slack, meeting notes and recordings, monthly gatherings, Q-gatherings

The Secretary’s purpose is to record all decisions, discussions, and other relevant information during a meeting to ensure organizational transparency and organizational memory.

The Secretary’s accountabilities include:

record decisions made
record discussed topics
capture voiced opinions, ideas, objections, etc.
publish the meeting notes to a location accessible by the entire organization

This way, we ensure complete transparency in the organization about decisions made, progress on tasks, and different discussions within the circles.

At ST6 we have the following circles:

Organization
Operations
Office
Consulting
Project sub-circles
BizDev
Recruiting
Branding
Strategy
Product

Each ST6er is free to join any circle they want to contribute to. Each STer is also free to leave a circle if they feel overwhelmed and want to put their energy somewhere else.

Do you feel intrigued? write to us :).

Meet the ST6ers - Petar

Fri, 18 Jun 2021 00:00:00 GMT

Why did you join ST6?

One of the crucial reasons I've decided to join ST6 is the very experienced and intelligent team and the values that we share. I see ST6 as the place where I can learn, develop, and improve my capabilities as well as contribute to the company and other people's well-being. I'm always looking for ways to challenge myself, enhance my current skills, and learn new ones. I do believe that ST6 could be my arena for experimentation, personal and technical development.

Apart from that, ST6 embraces the Teal organization principles and values such as transparency, being your whole self, etc. When I started my first startup, Parknshare, I wanted to introduce transparency, equality, openness and create a unique culture and environment. After I failed, I found ST6 as a place that's already based on that, so it was an easy choice.

Tell me about your work at ST6

I started working for a client called MacStadium from day one when I joined the organization.

MacStadium is a leading provider of Apple Mac infrastructure, providing scalable, reliable, and secure private clouds and dedicated servers for MacOS. Currently, I am working on the Portal, a web app used directly by MacStadium customers to purchase products, talk to the support team, user management, and manage the various payment methods. The technologies we use are all JavaScript-oriented, like ReactJS, React-Query, Reach-Router, GraphQL, Apollo, NodeJS, Jest. Then we have GitHub, AWS, and MySQL. Outside the project, I am part of the Recruiting circle where we try to find like-minded people that embrace our culture and are in the top 5% of technical talent. Being part of the circle, I participate in many interviews, both cultural and technical ones, which helps me get out of my comfort zone and tune my sense and evaluation of people.

How do you prefer to start your day?

I love starting my day by getting up early in the morning, around 5:50 am, and going straight to the gym for a heavy weight lifting session. Then, I eat my breakfast and do 20-30 minutes of zen meditation practice. Both activities help me set a tone for the day, clear my mind and prepare me for the challenges during the day.

How would you describe your job to a bunch of five-year-olds?

It’s all about crafting great products. You build something from nothing, from 0 to 1. As a five-year-old, you build great things from a Lego, a puzzle, or randomly experiment with some stuff. That’s the creative and inspiring process. You’re thrilled by the experience, not by the results. That’s the same in our everyday job. We do love creating and shipping great products and software, but more than that, we love the process of making something.

Check our careers page, join the ST6 team, and bring your whole self!

Meet the ST6ers - Martin

Tue, 27 Apr 2021 00:00:00 GMT

Why did you join ST6?

I joined ST6 because it aligns with my vision of how an organization should be structured and how it should operate. I read about it in the book "Reinventing Organizations" a while ago. Since then, I genuinely believe this is the way to go for any existing or newly created organization. That was the selling point for me when I interviewed here.

I like the fact that the guidelines and principles are accepted and genuinely applied by everyone at any time. I also like that I'm well accepted and feel that my opinion and expertise matter, whatever the topic.

Tell me about your work at ST6

Right at the start, I became part of the team, which works with a client called Markforged. It's a company which manufactures industrial 3D printers. I, myself, own a 3D printer, so it is pretty exciting to work with such a client on the inside and be part of it all. My role in all this, for now, is to help with the software, which manages 3D printer farms and controls what gets printed, where, and when. The technologies we use are all JavaScript-oriented, like Node.js, three.js, Jest. Then we have GitHub, AWS, PostgreSQL, and CircleCI.

Outside the project, I'm part of the Office and Branding circles. Since I'm working from the office, it makes sense to join the former. About the latter, branding's something out of my comfort zone, and it was something I wanted to do to widen my scope and knowledge. The people in the circle accept me and value my opinion, so it's a pleasure to be there. This is where the organization's culture enables me to join a domain in which I'm not so proficient, but still contribute and grow.

What would you say are some of the biggest challenges you face at ST6?

The fact that it's hard to abstract yourself from what you have already learned from the corporate world. It's pretty different how everything operates here—it's like you never had any professional experience, and you start building everything from the ground up. My colleagues at ST6 have already built a lot, and it's both easy and interesting to see what they had to go through to achieve all of this. It's also thrilling to see where all this will take us, but that's a challenge I'm happy to take on any day.

How do you prefer to start your day?

I like to start my day with any exercise—running, swimming, activities... Mornings are the part of the day in which you have the least distraction, so it's good to keep the discipline.

Work from the office or remote? Why?

Hybrid. I think people should be able to be flexible and be able to switch at any time. I believe there is no need to marry one option, but maybe choose a primary one.

What are your interests outside of work?

They are too many… Family and friends come first. When I feel in good shape, I do triathlons, half-marathons, or bike rides. I also do seasonal sports like snowboarding and windsurfing. Throughout the pandemic, I discovered my cooking side, and I'm still exploring it. When I find time outside any of that, which is rare now, I'm pretty interested in IoT stuff, like building your battery pack, solar panels, or anything small you might program.

What's one thing you are learning now, and why is it important?

I'm learning how to deliver my full potential to the whole organization. It's something I never felt I could do in any of my previous workplaces. Now, I know it will take some time and adjustment, but I'm certain that what I give and what I take back will be much better.

Check our careers page, join the ST6 team, and bring your whole self!

Meet the ST6ers - Hristo

Thu, 22 Apr 2021 00:00:00 GMT

Why did you join ST6?

I am truly passionate about transforming work culture and the ways humans create value together. I have co-founded several organizations based on the principles of Sociocracy, Holacracy, and self-management, and one of them was acquired by Amazon in 2019. After the acquisition, I dedicated my time to sharing my learning and experience with other organizations as a professional coach and advisor. The passion for co-creating “human-loving organizations” never left me, so joining ST6, as one of the best genuinely sociocratic organizations in Bulgaria, was the natural next step in my career and life as a whole.

Tell me about your work at ST6

I am a member of four circles, and I hold multiple roles within the organization. They all inspire me.

As an internal coach and advisor , I partner with people in a creative and thought-provoking process focused on personal and professional growth. By exploring their own inherent wisdom, people are inspired and curious to grow, find their own truths, and live happily. This type of relationship provokes me to grow as well.

As a member of the Organization circle , I support the organization on its journey to becoming even more sociocratic, self-managed, and human-loving. It is a never-ending evolution where we all learn to think, behave, and interact with each other mindfully, with higher awareness, empathy, and acceptance.

As a member of the Strategy circle , I support the organization with our strategic and business efforts and I participate in key strategic decisions that are the responsibility of the circle. Our purpose is to sense the ever-changing external environment and adopt the organizational strategy in the best way possible.

As a member of the Branding circle , I support the organization in all branding, PR, marketing, and communications efforts. Our purpose is to inform and educate people about the type of organization we are creating and its opportunities. Thus, people who resonate with our values can self-identify and decide if they want to join our organization.

What’s your favorite way to unwind after a busy day?

After a busy day, I like to spend time with my family. I’m a father of two boys—two and four years old. We play games and have a nourishing dinner together, and after they go to bed comes my personal time. I usually play video games online with my friends, meditate, or learn new things.

What are your interests outside of work?

Latin-American dancing, snowboarding, kite-surfing, motorcycling, mountain biking, hiking, video games, photography, meditation, yoga, eastern philosophies, psychology, you name it! :) My restless mind pushed me in many directions, and as a result, I started various hobbies and later on struggled to keep up with all of them. Lately, eastern wisdom and meditation have helped me learn to let go and find pleasure in doing less rather than “drinking more coffee and doing more stupid things faster” :)

Check our careers page, join the ST6 team, and bring your whole self!

Transparency - The Foundation For Startup Success

Wed, 09 Dec 2020 00:00:00 GMT

Illustration 193041456 © Tarikvision - Dreamstime.com

In early 2014, I created my first real startup, Loanbase. It didn’t start out by that name, but that’s a different story. Within two years of starting, Loanbase became the biggest P2P Bitcoin lending platform in the world. Within a year of reaching this peak, the company failed and we disbanded! This was a very painful experience, which prompted me to do a lot of soul-searching.

The first sign that things weren’t going well was that one of our best engineers left the company at the very peak of our “success”. One of the reasons that he left was that the equity structure wasn’t complete yet. We had put it off for some time because we were busy doing other things. In retrospect, this certainly wasn’t the only reason he left, and it never is. The equity was just the final straw for him. It took me a while to figure out what all the other straws were and the list was long. It was a death by a thousand paper cuts and a few swift sword chops! Our business wasn’t going well, the product-market fit wasn’t there, the traction wasn’t there, my co-founder and I were frequently having heated arguments in front of the employees, but worst of all… our accountability, to our team, our customers, and our shareholders, was nonexistent. While all of this was happening, we kept telling our stakeholders and (worst of all) ourselves, that everything was fine!

Illustration 193041456 © Tarikvision - Dreamstime.com

By contrast, we’ve been running ST6 for more than 3 years now. Our organization is twice as big as Loanbase at its peak, we’re self-sustainable, 10x more profitable than the closest competitors in our segment, our average employee compensation is 20% higher than what the competitors offer, and our employee churn rate for this entire time has been 0. So the problems we encountered with Loanbase were certainly not unavoidable. I believe that nearly all of them could have been avoided had we been more transparent!

Better Decision-Making with Transparency and Accountability

Transparency keeps you honest and focused, makes your organization more resilient, provides you with the highest probability of success, and makes everybody accountable. Of course, the ultimate accountability comes in the form of the startup failing if you make enough bad decisions. However, you might already realize that keeping yourself accountable isn’t something you should do once every couple of years (the approximate time it takes for you to burn through your runway). Your monthly check-ins with investors aren’t enough either. Not only are they not enough, but the whole principle of those check-ins is completely broken! Instead, you should do it every single day. Transparency also allows you to easily delegate decision-making to other members of your organization. That frees you up to focus on the issues that need your attention the most.

If you hire smart people, then it would be an absolute pity if you didn’t enable them to make the best decisions possible.

I ran across a very interesting blog post by Thomas Seager which defined a decision as “an irreversible commitment of resources.” The blog post is an excellent dive into what it takes to make a decision. One of the key takeaways was that if you wanted “to empower people in your organization to make decisions, you must communicate to them the resources they have the right to commit.” That’s a sentiment that I mostly agree with and we have a very similar understanding at ST6. In addition, we find that we also have to provide people with all the relevant resources they need in order to make a decision. The key things that people need to know about when they make a commitment of resources are:

All Relevant Communication and Decisions
All Company Finances
- The overall state of company finances
- Pricing, sales, and income
- Spending and salaries

As a founder, you want to have a clear view of all of the information you have at your disposal in order to make the best decisions. If you hire smart people, then it would be an absolute pity if you didn’t enable them to make the best decisions possible.

Transparency in Communication and Decisions

Usually, people look up to the leadership of the companies to make great decisions. The reason why that happens is not that the leadership are the smartest and most experienced people (I don’t discount the possibility that they might be), but because they’re the ones that usually have enough information to make a decision and the permission to commit resources. If you want to enable more people in the company to make decisions, you not only have to give them permission to commit resources but you have to give them enough relevant information. Note that this doesn’t preclude the company from taking into account people’s experience and competency when helping vet those decisions.

Within ST6, we strive to keep all legally permissible communication available in channels accessible to everybody in the organization. All of the internal team communication and external communication with clients is shared in the corresponding Slack channels. Before I reach out to a client for any communication that is relevant to the team, I first share it in the Slack channel for that client and I ensure that the team provides me with constructive feedback. Only then do I send it to the client. Likewise, I also see all the day-to-day communication related to that account in Slack. Each team (called a circle) has a specific domain it owns within the organization. Each circle maintains public meeting notes, which contain the discussions and decisions that they’ve made.

In addition to having good practices for information-sharing, we also have an organizational structure that fosters the distribution of information across the entire organization. We’ve been inspired by Sociocracy 3.0 to adopt the circles as an organizational structure. Each team member is free to join any circle within the organization which results in double-linking and the proliferation of relevant information within other circles.

Transparency in Company Finances

Another key area of transparency is financial. In standard organizations, company leadership also factors in the financial situation of the company when they’re making decisions. We find that enabling employees to make decisions also requires financial information to be made available. Within ST6, each employee has full access to the complete state of company finances, which is provided to them via a shared reporting account in Quickbooks. They can run any financial report or dig into every transaction that the company makes. As you can imagine, the financial accountability of ST6 is far greater than any other private company. In fact, we find that even public institutions don’t provide such direct access to financial information to their constituents.

We share all of the analysis relating to our formation of pricing. Each employee also sees the invoices we send out. They see the rates at which we bill the client for every person in the company. Quickbooks not only lets employees see the spending but the salaries as well. So each employee knows what everybody in the company is making, including the founders and partners within the company. That’s key to the enablement of employees to get involved in the decision-making process!

The Results

Photo 136284351 © Gearstd - Dreamstime.com

This whole exercise wouldn’t be worth the time if we didn’t find our results to be exceptional. As I mentioned in the beginning of the post: we’re self-sustainable, 10x more profitable than the top 3 closest competitors in our segment, our average employee compensation is 20% higher than what the competitors offer, and our employee churn rate for this entire time has been 0. This approach not only leads to excellent performance, but also enables all sorts of useful behavior. For example, employees can now set their own salaries and my life is much easier because I no longer have to think about who is getting fair compensation and who isn’t. The drama and tension around compensation are completely gone—nobody thinks about it. Our entire focus is on solving problems and realizing the vision of the company!

P.S.

Of course, we didn’t invent any of this ourselves. By the time Stefan, Ivaylo, and I started ST6, we had already built up a lot of experience with the problems of insufficient transparency and accountability. Stefan pushed us to learn more about what other competent people were doing. As the saying goes- “good artists copy; great artists steal” and we too are shameless about the fact that we’ve “stolen” some of these ideas from other successful entrepreneurs. In particular, from Ray Dalio’s “Radical Transparency,” Frederic LaLoux’s “Reinventing Organizations,” Kagan & Lahey’s “Deliberately Developmental Organizations,” and Sociocracy 3.0.

Radical Transparency

Thu, 12 Nov 2020 00:00:00 GMT

In self-managed organizations like ST6, everyone is empowered to make important decisions on a daily basis and is able to impact the future of the organization. Information is a key part of any good decision-making process. Thus, in our organization, it is especially important that everyone has access to all the information needed to make adequate, informed decisions.

In traditional organizations, access to information is restricted based on one’s position in the corporate hierarchy and only the CEO has access to all of the information. At ST6 we believe that

the truth belongs to everyone

and everyone in the organization has access to all of the information. We often say that here everyone is an acting CEO. Therefore, we have opened and made fully transparent all information related to:

Financial performance of the organization
Revenue, profit, and expenses
Active contracts and invoicing
Pricing and customer offers
Billing rates and hours
Company bank accounts
All other relevant information necessary for making CEO-level decisions

Furthermore, we have full transparency of all processes and numbers related to salaries, bonuses, and equity. In addition to knowing how much everyone in the organization earns, everyone is empowered to decide their own salary—a process called self-set salaries. Since you are your own boss, it only makes sense that you and only you will be able to decide how much you will get paid.

Finally, to continue on the path of radical transparency, after each meeting we share notes outlining what happened in the meeting, what was discussed, and what decisions were made. This allows for full awareness throughout the organization about all dynamics, discussions, and decisions.

As you can see, at ST6 we do not hold the truth as hostage. Access to information is not a privilege, restricted only to the higher ranks. There are no higher ranks. Everyone is empowered, enabled, and supported to make the best decisions possible.

Rather than relying on the single person’s intelligence, we

utilize the collective wisdom

to propel the organization forward. At the same time, by being actively involved in making important decisions, each of us has the opportunity to act, make mistakes, learn, and grow—personally, emotionally, spiritually, intellectually, and professionally!

Musings on Digital Transformation

Tue, 13 Oct 2020 00:00:00 GMT

For years I have been living with the idea that every company will become a software company because "Software is eating the world." I have been following the rise of software companies to the top of the public markets. I have co-founded and worked for software companies. I'm immersed in this ecosystem and forever will be. Yet recently, I have been gaining a new perspective on business digitalization.

I have started to realize that we are hitting a big wall. As more and more companies are digitally transforming themselves, the need for software developers is growing. Looking at the problem, it seems like a bandwidth one - there are not enough software engineers out there to solve all challenges. Until we have general purpose no-code development platforms and/or some form of artificial general intelligence, we (as an industry) need to solve this problem ourselves.

Back to my utopian thinking that every company will become a software company. I was envisioning that every company would have technical founders (or C-level execs) with hordes of software developers. It turns out this is not possible (for now). The main reasons are:

The above-mentioned bandwidth problem with not enough ~~minerals~~ developers.
Most of the founders (C-level execs) are not technical. And it's almost impossible for them to become highly technical. It takes 10 years (or 10,000 hours).
Growing teams is hard. Growing software teams is even harder. Nurturing strong technical culture requires sharing core technical values which might be the hardest part for non-technical owners.

What advice should our industry give to those that want to transform digitally?

My answer is:

Focus on the Product!

...but what does "Focus on the Product" mean exactly?

Focus on Product Management

Instead of looking to hire the best software developers out there try to find one (or two) of the best product managers.

A product manager is this mythical creature that has three heads - one for the customer, one for the technology, and one for the business. Depending on the context they should be able to put different hats on those heads and explain the whole picture to all parties involved.

Original image from ProdPad.

Having a skilled product manager will help you craft a product vision and strategy. Align the whole team towards a shared goal, and move all in the right direction. You would rather have a small team sailing in the right direction than a big team sailing in the wrong one.

Having a great product manager can even help you with outsourcing your software development to external contractors to do the "heavy lifting".

The critical part is that Product Managers should be part of your core team and organization. They should live your core values through the eyes of your customers.

It's a Product, not a Project

If you look at your digital transformation as a temporary endeavor, you have already failed. Building a software product is like raising a child - it takes time, continuous effort, courage, and tears. It is a cultivation process.

This is an area where traditional project thinking falls apart. The idea that you can "fix the scope" does not work in an ever-changing environment. It is rather the opposite - organizations should be able to deliver value continuously. The future belongs to those organizations that can continuously learn in a never-ending loop. Can you build one Starship a week?

To change this legacy project mindset, we need new tactics, techniques, tools, and practices. We need a new strategy - "A Culture of Continuous Value". That's the philosophy behind the #noprojects movement.

Cover of the book "#noprojects - A Culture of Continuous Value".

Applying those new principles you can accelerate your (digital) transformation.

Epilogue

To have your business transformation epiphany, you should focus on digital productization. It requires a new set of disciplines (Product Management) and a new mindset (#noprojects).

Software Craftsmanship for Kids

Wed, 07 Oct 2020 00:00:00 GMT

Late last year I was invited to my daughter's kindergarten to deliver a presentation about our profession. I thought it would be an interesting challenge to explain "Software Craftsmanship" to 4/5-year-olds and capture their imagination.

The structure

As with any presentation, the keys to success are: knowing your audience and preparing engaging content that will resonate well. Keeping in mind that the attention span of small kids is short (the rule being to multiply their age by 2-5 minutes), I was aiming for roughly a 15-minute talk.

To make the talk entertaining, I decided to follow two basic principles that work great for kids: play a game and give everyone presents.

Here is a brief overview of the structure that I was about to follow:

Start with content. In my case, that was the slides. I knew that the slides would quickly bore the children, but still, I should deliver my core message. The kids would be most focused during the first 5 minutes, so I needed to limit the number of slides as much as possible and present relatable concepts with pictures.
Show & play a mobile game. The best way to illustrate your profession is to show off the products it produces. In my case, I decided to show a simple mobile game that the kids could play on a couple of devices I brought with me.
Give presents. Give away something tangible that the audience can bring back home.

The slides - framing the message

Usually, presentations start with a few words about the speaker. This one was no exception. I presented myself as Elitsa's father (Elitsa is my daughter). This had a couple of benefits: first, every kid knew who Elitsa was, and second, she would feel proud that her father was there in front of her pals.

Now to the main message. It turned out it was far easier to explain "software" to young kids than I anticipated. In the past, I have tried to explain what I do to my grandparents, and I felt miserable. With the kids, it was simple:

We all have mobile phones - those are hardware devices. Every phone has icons with applications and games - this is software.

...and that's all - they got it.

Explaining how we craft software was a little bit trickier. This was where having good storytelling helped a lot. It went something like this:

You already know what a language is - you are speaking Bulgarian and English. We use similar languages while we craft software but we call them programming languages. We use the same letters from the alphabet.

And it's like painting on a white canvas, but instead of brushes, we use laptops and text editors.

Do you want to see all this in action and play a game?

I guess you already know what the answer to this question was - a screaming YES!

The game

Demoing a real mobile game would be the coolest part of my whole talk, so I spent a lot of time looking for the right game.

I had a couple of requirements for the game:

It should be simple so that the kids could get it out of the gate.
I should use Xcode because it has a big play button in the toolbar (the kids already know the play button from their beloved YouTube).
Inspired by the great talk from Bret Victor, I wanted it to have some moving visual objects. By increasing their sizes, I could illustrate how a simple number change in the editor could significantly alter the game behavior.

Using the advanced search capabilities of Github I was able to find SaveTheDot, which was perfect for my scenario. Here is a preview of the game from the project's README:

The whole game is implemented in a single Swift file, so it was easy to find the constants that defined the Player's dot radius. This way, I could manipulate the dot size and illustrate how we could change things.

You might have guessed how this all ended up - the kids asked me to increase the dot size so that it became enormous and filled up the entire screen 😂.

The presents

To make a talk memorable, the audience should be able to take something away. For grown-ups, the best you can do is to challenge their way of thinking. For kids, it should be something tangible like a present.

I took a bunch of cool ST6 stickers with me, which was a two-fold strategy from my side. First, kids love stickers. And second, they would bring them home where their parents could look at them, which would grow the ST6 brand awareness. Touché.

Final thoughts

If you love your craft, you will preach it with all your heart. No matter if you are presenting at the biggest software developer conference or in front of a couple of kids. The rule is the same - Craft with Passion.

P.S. You can download the slide deck I have used from here.

The tragedy of DevOps

Fri, 28 Aug 2020 00:00:00 GMT

Ever since I can remember, I have always had a drive for optimizations across my daily life. From how I do my groceries, to how I organize my work desk. Naturally, years ago when I first heard of DevOps, it immediately got my attention. It promises increased development speed and quality. So how come many organizations try it and fail to see any improvements. Sometimes they even get worse results.

The tragedy is that as engineers we tend to focus on the technical aspects of problems and ignore the non-technical ones. The reason is that many people don’t fully understand the DevOps Ways. Here are some of the most common misconceptions.

DevOps means a team of administrators who are focused on automation.
DevOps means automating everything.
DevOps means cool tools.
DevOps means working with cloud infrastructure.

The missing aspects

In my opinion, the non-technical aspects of DevOps are equally if not even more important than the purely technical. Let’s talk about those for a minute.

Local vs global optimization

Traditional IT development and operation have teams based on their domain of expertise. Their respective goals usually are focused on local optimizations. This means that they might apply improvements to their domain without thinking if it could lead to the degradation of another. This usually causes tension between teams.

It's just like Ivan Krylov’s Fable “Swan, Pike & Crawfish”. Teams start to pull in opposite directions and get nowhere.

Original image from obrazovaka.ru.

Consider a business that aims to provide a stable and secure service (or product) with fast feature development. Now let's see how that translates to the teams.

Operations

The main goal for the Operations team is to achieve high resiliency and availability.

Operations might choose to limit the number of changes to production due to stability concerns. As we all know, the most common cause of incidents can be traced to changes.

Development

Fast feature delivery is the main goal of the Development team.

Code quality might be lowered for the sake of speed. Bugs can creep to production due to lack of (or limited) testing. The team can also lose interest in how the system behaves in production.

Security

High security standards are the goal of the Security team.

Security might choose to implement some controls with a minimal benefit without considering how it might affect other teams. This directly translates to a negative impact on the business.

What does that mean?

Each team has a goal that is in line with the business. But each team's local optimization leads to global degradation.

How should we address this?

Usually, you will hear how ‘you need to break the silos’ and ’implement cross-functional teams’. That is not necessarily needed. It all boils down to having a common understanding of what the business goals are, how your decisions affect the other teams (and thus the business), and trust.

Feedback loops

Feedback loops are something that can be seen in all aspects of life. Some scientists even believe that they are the basis of consciousness.

How do feedback loops fit in DevOps?

No one is perfect, and that is normal. It becomes a problem if you stop trying to improve yourself.

This translates to systems as well. To improve a system, you need to observe it, identify weak points, and make enhancements. This is what is called the Plan-Do-Check-Act or Deming cycle.

Let's see two examples. One with a missing feedback loop and another that is ineffective.

Missing feedback loop

Consider a typical siloed organization, test and production environments have different architecture. Even if they are set similarly they often drift with time. This is caused usually by manual changes that are not applied to all environments. This leads to entropy which sooner or later will bite you.

The Operations team might apply some web server configuration change after a production incident. This change should be communicated to development and applied to the test environment. If this is not done, it can easily mask new issues, that will be encountered later in production.

Ineffective feedback loop

The Development team finishes a new feature and functional tests were successful in the test environment. The new feature is deployed to the production environment and then Operations notice a large increase in the database response times which impacted the business.

The issue was detected in production, which means that the development team got feedback after the issue was visible to clients and already causing trouble for the business. Such feedback loop is ineffective. The development team should have been aware of the database response time increase before the feature reached production.

How should we address this?

You need to increase the flow of information between teams. This will allow you to identify and fix problems sooner.

Conclusion

The non-technical aspects are the starting point for a successful DevOps transformation. The automation and tools are just there to help and don't make a difference by themselves.

There is no single way to implement DevOps in an organization. If you want to learn more about this topic, read these books to understand DevOps, and successfully apply it.

Birthday Special

Mon, 27 Jul 2020 00:00:00 GMT

Do you remember the last time you spent your birthday at the office? Did you feel festive or was it just a regular working day for you?

How We Do It

At ST6 we respect everyone’s birthday and we believe that each ST6er deserves to feel special on this exact date. Therefore, our party queen Lidia takes care to prepare a personalized gift and desk decoration for every birthday boy and girl. She uses accessories, balloons, and treats usually related to their hobbies or favorite movie. The COVID-19 times we live in haven't changed a thing. If an ST6er is at home, their birthday surprises are delivered straight to their home office.

In addition, the company offers an extra day off to every ST6er for their birthday. It’s a great opportunity for each of us to spend time doing what we love. One might even experiment with a thing that they have always wanted to do but have never managed to fit into their schedule. For example, taking the first swimming lesson or hiking around the nearest mountain for a day. And if you're not in the mood for adventure, you could just sleep till noon in the middle of the week and read a good book in the afternoon.

What About My Birthday?

I joined the company recently so I have to wait a few months till my desk converts into a disco. What I know for sure is that I'll take advantage of the extra day off to hang around the city as I always do for my birthday.

Join Us!

Wanna have a special day on your birthday? Check our careers page, join the ST6 team, and celebrate as every ST6er does!

The Sad State of .NET

Tue, 04 Feb 2020 00:00:00 GMT

Past - the golden years

I started my professional career as a .NET developer back in 2004. C# was the new cool kid on the block and everyone wanted to play with it. Microsoft was pushing hard its .NET strategy thus sponsoring the local universities and the biggest local technical event - Microsoft Days. It was the era of .NET.

In the begging C# and .NET were portrayed as the evil twins of Java and JVM - copying all the good things from the "blessed" Java and eliminating some of its bottlenecks - from small things like properties with getters and setters to more impactful features like value types and attributes. All this foundational work laid down the ground for the future innovation that was about to happen. And indeed, it happened: runtime generics (at IL level), LINQ, dynamic, async/await. Especially async/await was so impactful that it changed the whole industry and every major programming language has this feature now (yes, even C++).

Present - soul searching days

Things started to change in the mid 2010s. Anders Hejlsberg shifted his focus from C# to TypeScript, resulting in little to no language innovation in C#. The whole industry started the shift to the Cloud but .NET was not ready for it. Despite being labelled as multi-platform .NET was solely targeting Windows (and mobile via Xamarin). Linux was not first-class citizen, not even second. But the Cloud was all about Linux and Docker. It eventually went that route (thank you ScottGu) under the name of .NET Core but too late for the party.

On the other hand, Java entered its renaissance. After years of stagnation, Oracle revived the language and put it on the right track. It is now playing the catch-up game with C# but it's getting there fast. However, the Java ecosystem did have something to offer for the Cloud. Big data (Hadoop), search (Elasticsearch) and messaging/stream-processing (Kafka) are some of the key ingredients that enable the Cloud to shine.

Python was prepared as well. Having strong backing in academia, it positioned itself as the main player in the new field of machine learning. And the Cloud welcomed it.

Future - yet to be invented

What about .NET? There is this Question (with а capital Q) that hangs like the sword of Damocles over its head:

Where is .NET/C# positioned now? What will be its main application in the Cloud era?

Only the future will tell but one thing is for sure - .NET/C# needs innovation like it did in the past.

Building Another Automated Low-Code Lead Generation Machine!

Mon, 03 Feb 2020 00:00:00 GMT

Lead Generation is key to any successful business development and sales process. Today’s tooling has reached a level of sophistication that allows Biz Dev and Sales leaders to target potential clients with surgical precision. I was pleasantly surprised to find out that my blog post about building an automated lead generation gave people a lot of good ideas! The founder of an investment fund reached out to me with an interesting problem for which my automation experience seemed like a good fit. In this blog post, we will go over how we build out a unique automated lead generation system based on the investor's feedback.

Challenge

The challenge faced by the investor was that he needed to provide his portfolio companies with a way to take their Ideal Customer Profile and wade through the vast ocean of digital information on the Internet to find narrowly targeted companies that match that customer profile. The main premise was that companies that post listings for roles that require certain technologies could also be a signal that the company is in-market or open to a new vendor. This signal is one an SDR could follow up if they were monitoring it.

We determined that the easiest place to get such information was from Indeed.com, where the businesses do list some of the technologies they're expecting their employees to work with. The workflow for this process looked like this:

The goal was to automate this workflow to the point where one could enter their Ideal Customer Profile and the tool would “magically” get all of the right targets at the end. However, an even bigger challenge was to make this solution without writing any code. There were key constraints with respect to where the information was going to come from and we settled on Indeed.com as the initial source. That would prove to make the “no-code” requirement extremely difficult to fulfill, but we ended up with a pretty elegant solution.

Solution

We built a simple low-code tool that allows the salesperson to define the profile of the companies they want to find, gather data, enrich it, and generate a lead matching the ICP (Ideal Customer Profile). Since the source for the potential leads are the job listings on Indeed, we determined that the ICP would be based on a job query, which we would then match to companies that are seeking a specific talent.

The workflow looks like this:

Define the Indeed query that would result in relevant matches (Airtable).
Build the query for each job listing (Airtable).
Monitor the RSS feeds from Indeed for new listings (Clay.run) and store the new listings in Airtable.
Enrich the company data (Zapier + Clearbit).

The tools we used are:


Airtable	Clay.run	Zapier	Clearbit

Define the Query

Suppose that you’ve built a service that integrates with HotJar and you would like to find out what companies use HotJar. One way to find such companies is to look for job listings that include HotJar in the job description. In this case, we would construct an Indeed query that looks for any job listing where HotJar is part of the description:


https://www.indeed.com/jobs?q=hotjar&as_any=hotjar+analytics+ads+director+vp+head+executive+manager+chief&as_any=hotjar+analytics+ads+director+vp+head+executive+manager+chief&salary=\$70000%2B&as_not&jt=fulltime&sr=directhire&as_phr=&as_cmp=&as_ttl=&st=employer&limit=25&fromage=

We’ve added a few more narrowing filters, such as a salary of over $70K, the position must be full-time and optionally contain some other keywords. The result is that as of the writing of this article, there are 68 job listings from companies that match this profile.

Build the Query

As we can see, it is pretty important to have the ability to finetune and troubleshoot the queries to ensure that you get the best results! The next bit of magic is a simple but powerful Queries table. It’s a custom “query builder” in Airtable forms that mimics the search form in Indeed (see below).

Indeed has a number of search parameters so we had to ensure that our Airtable form covers all of the relevant ones. The parameters are processed and combined into a query string, which is then used to dynamically construct the RSS URL. The RSS URL is used to access the RSS feed corresponding to that particular search query. The other important thing here is the ability to inspect the query results. That’s made possible by looking at the Query URL, which opens up the standard search results from Indeed where you can easily see the actual result that Indeed would serve for that query.

All the magic happens in the formulas for the fields Query String, RSS URL and Query URL.

Here is the Query String formula:


CONCATENATE("q=", SUBSTITUTE(TRIM(LOWER(Keywords)), " ", "+"),
"&as_any=", SUBSTITUTE(TRIM(LOWER({Any Keywords})), " ", "+"),
"&as_any=", SUBSTITUTE(TRIM(LOWER({Any Keywords})), " ", "+"),
{Location QP}, {Salary QP},
"&as_not", SUBSTITUTE(TRIM(LOWER({Exclude})), " ", "+"),
"&jt=", {Type},
"&sr=", IF({Direct}, "directhire", ""),
"&as_phr=", SUBSTITUTE(TRIM(LOWER({Exact Phrase})), " ", "+"),
"&as_cmp=", SUBSTITUTE(TRIM(ENCODE_URL_COMPONENT(LOWER({Company}))), "%2C", "+or+"),
"&as_ttl=", SUBSTITUTE(TRIM(LOWER({In Title})), " ", "+"),
"&st=", IF({Allow Staffing}, "", "employer"),
"&limit=25",
"&fromage=", {Age})

Here is the RSS URL formula:


CONCATENATE("http://rss.indeed.com/rss?", {Query String})

Here is the Query URL formula:


CONCATENATE("https://www.indeed.com/jobs?", {Query String})

Please feel free to request free access to our Airtable base in order to get the full formulas.

Monitor the RSS Feeds

Unlike the previous low-code lead generation tool I built, this one is a bit more tricky when it comes to the RSS monitoring. Given the fact that we’re building our RSS queries dynamically, we have to ensure that we’re also dynamically monitoring them. Any change to the query parameters will result in a new RSS URL, which will mean that you’ll also have to manually change any tool that uses the old link. Of course, this is still doable by hand and you can still use Zapier to monitor the RSS feeds. However, we’ve exposed a Clay.run function that does this automatically. The workflow for the Clay.run function is as follows:

Every x minutes (where x is defined by you).
Trigger the Clay.run function.
1. The function fetches all of the RSS URLs from Airtable.
2. For each RSS URL, check if there is a new item in the RSS feed.
3. If there is a new item in the RSS feed, send it to the Jobs table in Airtable.

The end result is continuous monitoring of all new job listings that show up on Indeed, given the criteria we specified above. Pretty nifty:

Enrich the Company Data

With each job listing, we also get the name of the company that posted the job along with the domain for the company. This is quite limited, so in order to really get quality leads, we have to enrich the company information. The workflow here is:

Step 7 is where you select all the fields that you want to collect for the company and you insert the record into Airtable, if the record doesn’t already exist. Here is how it looks:

If you’d like to learn how you can set up this flow, please feel free to contact us and we’ll be happy to share the Zapier workflow with you. The end result is a pipeline of leads with a ton of useful information by which you can filter them.

The default view is the Grid View, where you can also see the full list of leads that have been collected.

Now You Just Have to Close

Now you have an automated lead generation system! The hard part is over, now you just have to close your deals! 😉

At ST6, we always try to use technology to minimize the most expensive part of product development: software engineering. We believe that no-code/low-code tools are going to transform how early-stage product development and product validation works. Entrepreneurs can now build an MVP of their product with minimal coding effort and get something in the hands of their customers.

Contact us now in order to get free access to the Airtable base and/or get help with setting up your own lead generation pipeline.

Happiness, Balance, or Growth? You CAN Have It All

Tue, 07 Jan 2020 00:00:00 GMT

We live in an era of extreme busyness. It's too easy to get swallowed up by day-to-day tasks and skip taking a minute to just look back and reflect on our day and ourselves. We're too busy to spend a minute on this because it eats away from our precious time and we can't afford it. Inevitably the moment comes, when we lose focus, lose motivation, but it's ok as "these things happen", and we are "fine".
We know being "fine" is not where we want to be. We want something more.

We are going to take a look at the most common states of mind we are in during our typical workday. We'll see how it affects us and what we can do about it in a few simple steps. We are not going to change the way we operate that much, but rather tweak the perception and expectations we have for ourselves.

Doing everything with ease (our A-game)

Original image from ideasforfreedom.

There are days where we can’t wait to get something done and see its fruits. We have laser focus. We are proud of ourselves because we know we gave our best, no matter the outcome. We believe this is what matters and what will get us where we want to be. This is when we have momentum. We feel we just know the right things to do. This is when we are in the zone. Everything is great. This is our A-game.
This is part of Jared Tendler's concept about the improvement process, called "Inchworm".
You can read more about it in his book The Mental Game of Poker on page 28

We can easily find ourselves in this state when we are really excited about getting something done and we have a burning desire for it. Maybe we find it very meaningful to us. It might be a cause, a belief, or whatever it is that resonates with our true self. We can also get there by other circumstances as well – i.e. our love life is going great, we are in a good relationship with the people that matter the most, or it's that good things just happen randomly here and there.

Back to reality (B and C-game)

Original image from CEO Magazine.

On the other hand, life isn’t all sunshine and rainbows. We are not that often in our A-game state of mind. Most of the time we are at our B, C and even D-game. Often enough, we are not that motivated, we lack focus, we beat ourselves to the ground to get something done. Before we realize it, the day is over and we feel like we haven’t achieved anything meaningful. Sounds familiar, right?

Did we really not achieve anything this day? I doubt it.
Why is it then that we feel this way?
It turns out we had expectations (spoken or not) about the day, about us, that we didn’t meet. Failing to meet these expectations makes us feel bad in many ways.

What can we do for our non-A-game days?

It looks like our life is a chain of ups and downs. Now you might be saying "whoa, thank you, Captain Obvious, for this insight!". Sure, I'm stating the obvious, but the point here is we can't turn the tide. Whether we like it or not, life will put us in a variety of situations – good and bad.
What's important is how we approach each one of them. We want to feel good about ourselves, even when we're not at our best. We need to accept what we can't change and make the best out the hand we're dealt with at the moment.

Set the right expectations for the day

Original image from James Brook blog.

1. Start each day by objectively evaluating what you can achieve for the day

If you have a TODO list, there’s a decent chance it’s overflowing. Tasks keep piling and piling until eventually, you can clearly see how off-the-track you are. Maybe you want to do too much in a single day. If you often find yourself in this situation, well… maybe your “objective” evaluation is not that objective and needs to be adjusted.

2. Formulate your tasks in a way that you can cross them off by the end of the day

Original image from memeguy.

If you take on a big task that would take days to finish, well… promise to yourself that you’ll do only 20% of the work. Come up with some checkpoint for these 20%. Do this in advance and be proud of yourself later for sticking to the initial plan.

3. Limit yourself to the very few things that matter the most

Ask yourself “if I could do only one thing today, what would it be?“.
Start from there. At the end of the day, we want to take a look back and say...

4. Remind yourself of your long-term goal

Spare a minute or two to take a look where you are now and where you want to be. Find the connections between today’s tasks and your long-term goal. See how what you do today affects your whole journey even if it is in the slightest manner.

Approach unpleasant tasks with the right attitude

Starting a task with a bad attitude is a recipe for failure.
Whatever your profession is, there are always things you don’t enjoy much but have to do either way. Whether you like it or not, these moments play a vital role in shaping you as the professional you want to be. The true acceptance of this idea will make it a lot easier to cope with these moments. We can’t change it, but we can change our attitude towards it. We learn every day, so a better way to approach these moments is to try find something interesting, something that this particular task can teach you. Sometimes it might feel the only thing you get out of it is boosting your willpower, but hey...

Celebrate the small wins

I can’t emphasize this enough. Every time you cross a task off, you hit a checkpoint, or you just get that feeling you’re doing well, stop right there and take a moment to smile and appreciate your effort. You deserve it.

Let's put it all into practice

Being part of ST6 – a flat-structured company, where empowerment and ownership are embedded in its culture, it looks like the perfect place to verify the validity of the ideas above. "With great power comes great responsibility," Peter Parker says. Let's give some perspective to this.

Here, at ST6, I have no boss, I have no manager. I have a tribe by my side, and they're here to help. Despite the fact we all share common values, we're still very diverse. What works for somebody, might not work for someone else. So, who would know how I can do my best better than me? Right, but with this comes the ownership and responsibility part. A good thing among ST6-ers is that we also look at failure as an opportunity to grow, so even if I try something that doesn't really work out... well, I'll know better.

So, how does all this fit in my typical work-day?
First things first – it's not the TODO list, but having a proper start of the day – chit-chat with the colleagues over a cup of coffee. Next, I go to my desk and about 9:30 my recurring daily TODO is prompting me. It's called "Divide & Conquer the day with subtasks". It takes me up to 3 minutes to revise and decide what my daily focus will be. Then, I estimate how much of it I can do today and write down only these. Boom, here it is- the first task for the day is finished. I cross it off, yeyy! Feels good.
Once I'm done with a task (excluding the 1st one), I take a short 5-10 minutes break. These moments are perfect to clear your mind, praise yourself and freshen up for what's next. In the past, I used to "get the advantage of the momentum" and go straight to the next thing. Don't fall for this! A lot of time passed, until it hit me- I'm not actually using the momentum, but rather using all my fuel for the day with full throttle. In F1 you can make the fastest few laps this way, but you won't make it to the finish line for sure. It looks obvious now, but this is how learning works.

Of course, there are times when things don't go according to plan. Maybe you underestimated how hard a task would be, or today is not your best day. Oscar Godson has said it very well- "One of the best programming skills you can have is knowing when to walk away for a while." Take a break and don't be hard on yourself- this is part of the game.

How about your cheat-sheet?

By no means is this the key to the secrets of life, of course.
We are all human, we are all different. This is what helps me stay on the right track. For you, it might be flavored differently.
Share your cheat-sheet in the comments below. I'll be happy to dive into what works for you.

How to Build an Automated Lead Generation Machine, Without Coding!

Fri, 13 Sep 2019 00:00:00 GMT

For the past several months the biggest issue we’ve been struggling with is finding a repeatable sales process for generating leads. I know, I’m sure everybody has tuned in right now and is waiting for the silver bullet which I’ve discovered! Sorry to disappoint, but there is no silver bullet. However, I think we've found a little silver nugget: a no-code way to build an automated lead generation machine!

From outsourcing to automation

In our never-ending pursuit to be innovative in our business, I’ve been trying to learn as much as possible. I picked up a Udemy course called Outsourced Lead Generation Machine. It sounded like a great way out of our predicament. After all, most of our team is comprised of Software Craftsmen, and boy, would we want to outsource our lead generation! Sure enough, it’s an excellent course, definitely worth the money. The course led me to the idea of automating, not merely outsourcing, our lead generation. We’re mostly still in the experimental stage of this effort, but we do have enough validated learning to share with you. So the little nugget of knowledge that I’d like to share today is our experience with automating our lead generation.

Define your customer profile

As I mentioned, the Udemy course is great. It has a lot of useful information and one of the first steps in the process is to build out the customer profile. The obvious reason is that you, as the salesperson, should know who you’re targeting. The customer profile is almost like a scorecard, which you can use to determine which customers are the closest match for your sales targeting needs. We did so in ST6 and here is our customer profile:

You’ll notice that we have some abbreviations in parentheses after each profile property. These are the abbreviations for the potential source of information for the lead. It’s going to be particularly helpful to know where to find this information if you’re going to automate the process.

In this case, the sources are:

JD - Job Description
WS - Website
BW - Built With
CB - CrunchBase
LI - LinkedIn

In our initial iteration, we wanted to make sure that we identify companies that, at the very least, are looking for software developers. After all, our company is in the business of providing software craftsmanship services. Our hypothesis was that if the companies are listing open positions for software developers, then they might consider software development and consulting services. Naturally, that narrowed down what we were looking for job posts.

Define your problem

The Problem: At ST6 one of the biggest priorities is to identify and connect with companies, which are looking for remote software engineers. Aside from the standard networking and referral approaches, we decided to explore other ways to identify companies (leads) that might need our services.

The Solution: Scrape the internet for job listings that match the profile of our team. Build out a score that tells us which job is the closest match to our profile.

The initial information needed was:

Technical/Skills
Background
Company Culture
Company Profile
Remote OK

Yeah, but how do we do that without writing code, you ask?

The solution: no-code MVP

Software development resources can be very expensive and should be used almost as a last resort. With that in mind, the first thing we wanted to do was build out an MVP which required as little coding as possible. Given that most salespeople are non-technical, it's also a good exercise to demonstrate that fairly complex automation can be done without a single line of code being written. Technically speaking, there are a few lines of code written, but they’re very basic and could be avoided with Airtable formulas. In fact, some of the Airtable formulas I wrote are more complex than the code written. Here is the most complicated code written and executed inside some of the Zapier tasks:

output = {
  pubDate: input.pubDate || new Date(),

  company: input.company && (input.company.split(' at ').pop() || ''),
};

OK, that’s all the code you’ll see in this blog post. Now let’s get back to the solution! Our tools of choice are:

RSS.app, for generating RSS feeds from websites.
Zapier, for automation: consuming RSS feeds and inserting the leads into Airtable.
Airtable, for storing and organizing our leads.

As I mentioned earlier, we’ll have to find job posts and figure out which companies are posting them. After scouring the internet for the best job listing websites, we found an extensive list maintained in a Github repository. The list also shows which websites provide an RSS feed. Handy! However, RSS is not all that popular nowadays, so if a website doesn’t have an RSS feed, you’ll have to do some internet magic!

Use RSS generators

I tried several RSS feed generators and the one that worked best, aside from being the simplest, was RSS.app.

RSS.app allows you to turn this:

Into this:

You get all this with nothing more than the click of a few buttons:

There you have it! You now have a structured representation of the website with new job listings being represented as new RSS feed events. Let’s move on to the next bit of magic!

Prepare your Airtable base

In our particular case, the data we get from the RSS feed generator is the following:

URL
Job Title
Job Description
Pub Date
Location (sometimes)
Company (sometimes)

That’s going to be enough to build out our database of leads and start feeding them into Airtable. So go to Airtable, create your base and add two new tables: Jobs and Companies. For the Jobs table, we’ll use the above-listed fields. My table looks like this:

A quick note about a possible improvement here: the URL is pretty much guaranteed to be unique, so use the URL as your primary key in the table. I’m using the title, but that’s much less likely to be unique.

The company table contains a few more fields which I’ve added over time. The “final product” of our labor is a table with detailed company information which we find relevant.

Automate with Zapier

So now that you have your RSS feed, how do you get the data into your Airtable? Well, that’s where Zapier comes in. Zapier allows you to automate everyday business tasks with ease. The basic components of every Zapier task, or Zap as they call it, is a Trigger and an Action.

In this case, our Trigger is the RSS feed and our Action is the Airtable. For a high-level overview of the Airtable integration see the integration documentation for Airtable. I won’t go through the entire setup process, but I’ll show you how one looks like once it’s all set:

The steps for setting up your trigger are:

Pick the RSS feed as your Trigger.
Select the “New Item in Feed” as your trigger option.
Inspect the RSS feed details collected by Zapier.
Test: Zapier provides you with several samples, so inspect them and confirm that they contain the information you expect.

The steps for setting up your action are:

Select Airtable as your Action.
Use the “Find Record” action. Note that “find” can be used to “create” a record if one is not found. I prefer this over create because it gives me the option to validate that the entry doesn’t exist in our database already.
Connect your Airtable by supplying your API key (you’ll need to generate an Airtable API key from your Airtable accounts page).
Select your options:
- Base: mine is the “Lead Gen” base which I created in Airtable.
- Table: Jobs.
- Search Field: search by your primary field (I’m using the Title, but I recommend that you use the URL of the post).
- Search Value: the value you’ll search with from the Trigger result (again, I’m using the title, but I recommend using the URL instead).
- Check the “Create an Airtable Record if it doesn’t exist yet?” checkbox.
- For each Airtable field match the RSS element from the Trigger.
Test: this step will insert an entry into your Airtable. This is usually the sample that Zapier obtained in step 4 of your Trigger setup.

Well, that’s it. Now comes the final touch.

Turn your airtable into a pipeline of leads

Now that you have your RSS feed generating new leads and Zapier feeding those leads into Airtable, let’s look at how you can make this into an actual sales process. You can make a pipeline for the job posts or for companies, the process is the same. I’ll only do it for the job posts.

Add a new “single select” field to your Jobs table called “Status”.
For the State field, enter several options which represent your pipeline stages.
Click on the view and add a new Kanban view; select Status as your grouping field.

There you have it! Now you can view your lead as a pipeline, which looks something like this:

Of course, you can edit what kind of information your Kanban cards contain and it can be even more useful. Here is ours:

Our database of leads quickly filled up and we had to come up with a scoring mechanism, which ranks the leads based on how well they match our target profile. You’ll notice that in the image above the leads are ordered by their score. That’s very useful for prioritizing which leads to contact first. The scoring is a little more complicated and may require writing a few simple lines of code that can be executed in Zapier. I’ll skip that for now, since our focus here is on the “No Code” aspect of these tools.

Reap the benefits

It took me about a week to implement this entire solution and connect 10 different sources of job listings. For the first 10 days, we managed to get over 370 job listings and 177 companies. That increased to around 1500 job listings and 500 companies within the first month. The fast growth of the database has caused us to hit the Airtable limit for free usage. You may have noticed the “Over limits” warning on some of the screenshots. But upgrading to a paid plan is still cheaper than developing a crawler from scratch. Even as an elite team of software craftsmen, we’re still very cognizant of the cost of development. This is something we often try to communicate with our clients:

Software development is very expensive. Be agile - build it in small iterative steps and make sure it is the best solution for the right problem.

It’s clear that today’s tools are becoming very powerful and you can now extract leads from many websites with minimal coding skills.

Crafting a Secure and Maintainable AWS Multi-Account Setup #3

Mon, 19 Aug 2019 00:00:00 GMT

Introduction

In my previous blog post, I showed you how we at ST6 crafted our AWS Organization and the reasoning behind our choices. I also explained that we use Terraform and that all repeatable configuration is modularized. Now I will walk you through the solution.

I'm not going to cover Terraform basics, but having a good understanding of providers and modules is essential for the solution. So, let's refresh our knowledge before we get to the good stuff.

Providers

A provider in Terraform is responsible for API interactions and authentication. Each public cloud has a separate provider.

The shortest way you can define an AWS provider in Terraform is:

# File: ./main.tf

provider "aws" {}

It's best practice to lock the provider version so that you are in control of the updates. I have seen how an update can cause recreation of resources. To do that you have to add the version argument to the provider:

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

Now that your provider is defined and the version is locked, you need to initialize it by executing terraform init.

A good question at this point would be:

How does Terraform know which region and what credentials to use?

There are several ways to provide credentials to Terraform:

Static credentials

You should avoid static credentials at all cost. Having credentials hardcoded is against best practices as you risk a leak. You don't want your resources to be destroyed or sensitive data to be stolen.
Environment variables

Environment variables are one mechanism you can use. You just need to define AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_DEFAULT_REGION environment variables in your execution environment.
Credentials file

The AWS CLI can store credentials in a configuration file. On macOS and Linux, the default file location is $HOME/.aws/credentials. To generate this file, you can create it manually or create one by executing aws configure and following the steps on the CLI prompts.
ECS and CodeBuild Task Roles

Terraform can use IAM Task Roles that are configured on ECS and CodeBuild. Terraform checks for the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable. If it doesn't find this variable it will try to use the EC2 Instance Profile.
EC2 Instance Profile with IAM Role

An EC2 instance can assume an IAM Role if it is configured with an EC2 Instance Profile. The Go SDK (which is used by the Terraform AWS Provider) makes an API call to the metadata endpoint. If you are running Terraform on an EC2 instance, this is the preferred method as credentials are rotated. This approach reduces the chance of leakage.
Assume an IAM Role

Terraform can also assume an IAM Role. You just need to supply it with a Role ARN. Keep in mind that to assume a role you need to be already authenticated.

One important thing to point out is that you can have more than one provider configured. You can achieve this with provider aliases. When a provider doesn't have an alias argument, then it's considered the default provider which is named aws. Here is an example of a multiple provider definition:

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

provider "aws" {
  alias   = "secondary"
  version = "= 2.18.0"
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}

In this example configuration, we have a default provider aws and a second provider named aws.secondary. The default AWS provider is used to assume the IAM Role TerraformRole in account 123456789012.

How do aliases help me?

Think of aliases as the different AWS accounts and regions that you have. When you define a resource, it uses the default provider unless you add the provider argument. This means that you can easily create two resources in different accounts and/or regions.

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

provider "aws" {
  alias   = "secondary"
  version = "= 2.18.0"
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}

resource "aws_iam_user" "user1" {
  name = "user1"
}

resource "aws_iam_user" "user2" {
  name     = "user2"
  provider = aws.secondary
}

In this example, one IAM User will be created in the default provider account and/or region and one in the secondary.

One interesting thing is that you can dynamically construct the providers. This means that you can create a new AWS account, construct the provider role ARN and create resources in the new account with a single step.

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

provider "aws" {
  alias   = "secondary"
  version = "= 2.18.0"
  assume_role {
    role_arn = "arn:aws:iam::${aws_organizations_account.secondary.id}:role/OrganizationAccountAccessRole"
  }
}

resource "aws_organizations_account" "secondary" {
  name  = "secondary"
  email = "secondary@john.doe"
}

resource "aws_iam_user" "user" {
  name     = "user"
  provider = aws.secondary
}

The above example will create a new AWS Account and an IAM User in it. Please note that there needs to be an AWS Organization configured for this example to work.

Modules

A Terraform module is a group of resources that are bundled together. They are used to abstract repeatable configuration. To create a module, you have to place its .tf files in a directory separated from the main working directory. Here is an example of a module file structure.

.
├── modules
│   └── ec2_instance
│       └── main.tf
└── main.tf

Terraform modules act just like a resource. They too have arguments and attributes. All variables that you define in the module .tf files are treated as a module argument and the outputs are treated as attributes. Below you can see an example of what a typical module configuration looks like:

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

module "ec2_instance" {
  source = "./modules/ec2_instance"
  ami_id = "ami-1234abcd"
}

output "ec2_instance_id" {
  value = module.ec2_instance.id
}

# File: ./modules/ec2_instance/main.tf

variable "ami_id" {}

variable "instance_type" {
  description = "(Optional) EC2 instance type."
  default     = "t2.micro"
}

resource "aws_instance" "instance" {
  ami           = var.ami_id
  instance_type = var.instance_type
}

output "id" {
  value = aws_instance.instance.id
}

In this example, we instantiate the ec2_instance module with an AMI ID: ami-1234abcd. Then we output the EC2 instance ID which is available as a module attribute.

Everything looks good so far. We have an easy way to abstract a large and/or repeatable configuration. One question might have popped in your mind.

Do Terraform modules support different providers?

The answer is yes. You can override a provider for a module.

# File: ./main.tf


provider "aws" {
  version = "= 2.18.0"
}

provider "aws" {
  alias   = "secondary"
  version = "= 2.18.0"
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}

module "default_ec2_instance" {
  source = "./modules/ec2_instance"
  ami_id = "ami-1234abcd"
}

module "secondary_ec2_instance" {
  source = "./modules/ec2_instance"
  ami_id = "ami-1234abcd"
  providers = {
    aws = "aws.secondary"
  }
}

The module code can remain unchanged from our previous example, because we are overriding the default provider with aws = "aws.secondary".

This example creates two EC2 instances in two AWS accounts.

You can even pass multiple providers to a module, which you have to map to internal aliases.

# File: ./main.tf

provider "aws" {
  version = "= 2.18.0"
}

provider "aws" {
  alias   = "secondary"
  version = "= 2.18.0"
  assume_role {
    role_arn = "arn:aws:iam::${module.secondary.id}:role/OrganizationAccountAccessRole"
  }
}

module "secondary" {
  source = "./modules/account"
  name   = "secondary"
  email  = "secondary@john.doe"
  providers = {
    aws = "aws"
    aws.account = "aws.secondary"
  }
}

# File: ./modules/account/main.tf

provider "aws" {
  alias = "account"
}

variable "name" {}

variable "email" {}

resource "aws_organizations_account" "secondary" {
  name  = var.name
  email = var.email
}

resource "aws_iam_account_password_policy" "strict" {
  minimum_password_length        = 8
  require_lowercase_characters   = true
  require_numbers                = true
  require_uppercase_characters   = true
  require_symbols                = true
  allow_users_to_change_password = true
  provider                       = aws.account
}

In this example, we are passing two providers to the module. The default aws provider is mapped to the default provider for the module. The secondary provider is mapped to a module provider with alias account. Using this configuration Terraform will create a new AWS account and configure its IAM Account password policy once the account creation is complete.

Putting the solution together

So how does this all fit together?

As described in my previous blog post, we decided to have a module for each repeatable configuration. This includes a new organizational unit, AWS account, IAM group, and IAM user. The Terraform configuration is executed in our master account. The structure of such a configuration looks like:

.
├── modules
│   ├── account
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── group
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── ou
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   └── user
│       ├── main.tf
│       └── variables.tf
├── main.tf
└── variables.tf

The account module is responsible for creating a new AWS account and applying a baseline configuration in it. This means that we need to pass two providers to the module. One will be using the master account (default) provider to create the AWS account and a secondary provider that will be dynamically constructed to apply the baseline configuration in the new account. This module needs to output the account ID so that it can be referenced by the provider.

The ou module is pretty self-explanatory. It only uses the default provider to create a new OU (Organizational Unit) with the corresponding SCP. This module needs to output the OU ID so that it can be used when creating new AWS accounts in it.

Modules group and user are used only for the Login account (you can refer to the previous blog post for the organization structure). This means that the modules are configured with just one provider. The group module is responsible for creating IAM Groups for each project with the corresponding IAM Policy. The user module controls our IAM Users and their group membership. You can output the group name from the module so that you can reference it when you add users to it.

Now that we have the configuration, let's talk about how you should execute it. Here is how our execution flow looks like:

When you start to collaborate on a Terraform configuration, you need to have a clear process. I have seen situations, where two people execute Terraform in different Git branches which causes configuration collisions. If you want to use branching, make sure you only go as far as the validation and plan step. In some cases like backend updates, you should only do a style check, as you can unintentionally apply the changes by executing terraform init.

There should be a single source of truth for the execution of all Terraform commands and the best place for this task is the automated CI/CD pipeline. I also like to use AWS managed services as much as I can (as long as they fulfill my needs). So naturally, AWS CodePipeline is my first choice for this. Our pipeline is separated in two stages, one for creating a plan and another to apply the plan. There is a manual approval step after the plan is generated and reviewed. We also execute the plan phase when a pull request is created or updated.

You should consider using the state locking feature of Terraform in order to limit concurrent executions. If you store your state in AWS S3, you can create a DynamoDB table and use it for lock tracking.

Final thoughts

We started with an ambitions goal to create an AWS multi-account setup that is secure and maintainable. The final solution is a Terraform configuration that is easy to understand and modify because we didn't overengineer it. We have used many of the AWS security best practices which makes our setup secure. Another benefit is that we use infrastructure as code and version control. This makes it easy to keep a track of the changes that were done to the organization (including user management). We also limit configuration conflicts by using a pipeline for the execution of Terraform.

I hope you enjoyed this series and you found something new that can make your life easier.

Crafting a Secure and Maintainable AWS Multi-Account Setup #2

Thu, 18 Jul 2019 00:00:00 GMT

In my previous blog post I talked about the advantages of using a multi-account setup and AWS Organizations. There are many things to consider when you go in this direction.

How many accounts are needed? What structure should I use? What policies should I create? Who should have access to what?

In this blog post, I will cover what we did here in ST6 and why.

Our requirements

Before I walk you through our setup, let's begin by listing the requirements that drove our decision:

We want to have our organization defined as code and use automation
Our users should not need to juggle with multiple accounts and passwords so we want Single Sign-On (SSO)
Different team members should have access to specific projects based on assignment
Each user should have an individual sandbox account
Project cost needs to be separate
We want to have a central log archive
We need to manage security and compliance in a centralized way
We want the solution to scale well with the increase of projects and team members

Remember to think about what you want to achieve and why, before starting the implementation. You don't want to overcomplicate the setup.

Our solution

We evaluated our requirements and did some research after which we came up with a plan.

This is how our ST6 multi-account setup looks like

How did we get here?

Well, we evaluated our requirements, did some research, and arrived at this plan. Now, let's walk through our requirements one by one and see how this setup addresses each of them.

1. Support automation

In the previous blog post, we talked about AWS Organizations, AWS Landing Zone and AWS Control Tower. AWS Organizations helps us to build a multi-account organization. It already has an API so the only missing part is some sort of orchestration.

Enter AWS Landing Zone and AWS Control Tower. These solutions are the first ones that you should evaluate for this purpose. Unfortunately, both of them do not exactly address our needs. AWS Landing Zone is complex and due to the many moving parts of the solution, it's error-prone. Additionally, it's not easy to extend the solution if you need something that's not included. AWS Control Tower doesn't have an API and you can't use it for existing organizations (as is the case with ST6). To sum up, both AWS Landing Zone and AWS Control Tower, don't work for us.

So where does this leave us?

AWS Organizations has an API, which means that we can use some infrastructure provisioning tools such as AWS CloudFormation and HashiCorp's Terraform.

Let's look at CloudFormation first since it comes from AWS. It uses JSON or YAML syntax to represent the resources that you want to create, which is not ideal but we can live with that. In my personal experience, I haven't seen any bugs in CloudFormation. A surprising drawback is that many services that are supported by rival tools are missing here. And as you might have guessed AWS Organizations is not supported.

HashiCorp, the company behind Terraform, has gathered a huge traction in recent years and Terraform has been available for quite some time now. It uses HCL (HashiCorp Configuration Language) version 2 which is a derivate of JSON. It's easy to write and understand, and it's a lot shorter than CloudFormation's YAML and especially JSON. I have seen many bugs over the years and the fact that there still is no stable version available speaks for itself. Nevertheless, the tool is good and it gets the job done. An additional benefit of Terraform is that if you have an existing AWS Organization and you want to manage it with code, you can import the existing resources to your configuration.

Both CloudFormation and Terraform use declarative syntax (HCLv2 has some limited functionalities on top). Sometimes when you write configuration you wish that you had the power of a full-blown programming language.

To me, using the same programming language for application code and infrastructure is perfectly logical.

At ST6 we love DevOps. Оne DevOps technique is to have cross-functional teams. What better way to achieve this than to have all team members use the same tools and languages. So let's see what we can use that can help us. AWS Cloud Development Kit (AWS CDK) and Pulumi are tools that promise to deliver just that. Both of them provide the ability to abstract AWS resource provisioning using familiar languages like Python or JavaScript. Unfortunately, in our case, we can't use them because under the hood AWS CDK uses CloudFormation and Pulumi is free only for individual use. I'm sure that in future projects we will try these tools and share our experience.

Considering all of the above, we chose to go with Terraform.

2. Single Sign-On

Remembering many usernames and passwords is always hard. You can even say that it might lower your security as many people in such a position start to use weak passwords. At ST6 we want our team to focus on delivering value to customers and not trying to remember passwords when working in different AWS accounts.

There are many approaches to this and many of them need Active Directory. As a relatively small company, we are using G Suite. Perhaps in the future, we might need to switch to something else that relies on Active Directory. For the time being it would be perfect if we can use the same G Suite users for our AWS infrastructure.

You can set up federated access with G Suite, for more info see this AWS article. We don't like this solution as it requires a lot of manual work in the G Suite Admin Console and API. This approach is not very convenient if you use access keys often as you need to generate new ones when the session expires. It's not that apparent who has access and when they got it.

After some thought, we decided to have a central Login account (or Identity account if you wish).

Each developer has an IAM User which is able to assume an IAM Role in other accounts. This way we can manage the IAM Users with code and our developers have to remember just one additional password. Each user can create an access key and an MFA token which is required when assuming roles in other accounts with the AWS CLI.

3. Access rights

Since we are using IAM Roles to access different AWS accounts, each user needs to have an IAM Policy allowing an assume role API call to specific roles based on the current project assignment. A best practice is to use IAM Groups to assign such permissions. Each project has a corresponding IAM Group with an IAM Policy granting assume role permission on the IAM Role in that specific project account. Based on the current assignment, we just need to add each developer to the respective IAM Group.

As you can see from the example User 1 is a member of Project 1 Group and has access to both Project 1 Dev and Prod accounts. Whereas User 2 is a member of both project groups and has access to all accounts.

We use this method as it's easily achievable with code either for ST6 owned AWS accounts or customer-owned accounts.

Using IAM Roles to access customer accounts is also safer and more convenient for our clients too as they just need to create a single role with the necessary permissions and create a trust relationship to our Login account.

4. Individual sandbox environments

We want to give our developers individual sandbox accounts so that they can test services and continuously improve their skills. Having such accounts creates a safe environment where people could experiment and level up their cloud knowledge.

Each user has an in-line policy that grants access to the user's own sandbox.

Again Terraform aids us with this. We use code to create a sandbox per developer and grant the appropriate permissions.

One thing to point here is that you should implement some sort of cost monitoring on those accounts. You can use AWS Budgets or Billing Alarms, which can trigger some sort of automation that will stop or delete resources. You might want to implement some policy on the sandboxes so that only certain regions and services are available.

At ST6 we trust each other and we prefer not to limit innovation and creativity, so we just monitor the cost and send notifications.

5. Cost separation

In my previous blog post I talked about cost separation. The solution is to create separate accounts for each project, product or environment. We want to be able to see precisely how much our projects and project environments (if such exist) cost.

Our solution is to create OU per project so that we can apply the necessary SCP on it and place all accounts (or account) in it. Then we can easily see the cost of each project and project environment.

6. Logging archive

It's good practice to export logs containing security and compliance information to a different account. If you store your logs only in the account where they are created, you risk having them deleted by mistake or intentionally in case of a breach. A central archive guarantees you have a copy in a safe place. Some companies go one step further and set this archive as a standalone account outside of the organization and replicate the logs to at least two other regions.

We chose to use CloudTrail for organization as it's straightforward to implement and it covers our immediate needs. Please note that organizational trail can be created only in the organization's master account.

7. Central security and compliance

Security and compliance are very important topics. It is a good practice to have an account that is dedicated to this. AWS can help you achieve proper governance with services like AWS Config and GuardDuty. They are good candidates to enable in such account.

AWS Config can be used to asses your current estate against rules that you define. The findings are stored and you can check historical data. You can use the integration between AWS Config and AWS Organizations to ease your deployment. Keep in mind that this means the aggregated view will be in the organization's master account. It might be better to have this set up in the security account so that you limit the use of the master account.

GuardDuty is a service that uses machine learning to detect threads and anomalies in your accounts. This is a regional service, meaning that analyzed data doesn't cross regional boundaries and you need to configure it in every region that you intend to use.

All of this configuration can be done by code. Just make sure you grant access only to a subset of security and compliance experts to this account.

Our solution is to have a dedicated account for those services, though it's not yet implemented.

8. Ability to scale

Using code to create and manage an organization is a step in the right direction. Using declarative language like HCL is not as flexible as using JavaScript or Python, but you can and should leverage modules. Terraform modules are a good way to abstract repeatable configuration like:

You might also want to separate the state so that the organizational structure is in a different state than the IAM users.

The configuration goes through code review and a deployment pipeline. You should limit all Terraform executions to a pipeline and only for code that is approved and merged. You don't want to have race conditions between branches and simultaneous executions.

At ST6 we use Terraform modules for abstraction or repeatable configuration and AWS CodePipeline as a single point of execution.

Final thoughts

This setup covers our current needs, but as our company evolves our needs will change. We might even have made a wrong decision in the way we addressed something. "The only constant is change" so our solution will change in time as well.

Your main takeaway from this blog post should be to make sure you tailor your AWS Organization to your needs and keep it simple. Having such flexibility at your fingertips is tempting for many people to overcomplicate things.

In my next blog post, I will cover the automation side of this setup.

Crafting a Secure and Maintainable AWS Multi-Account Setup #1

Thu, 11 Jul 2019 00:00:00 GMT

AWS and other public clouds give developers huge flexibility and freedom to innovate so they can act faster on business requirements. However, such power doesn't come without a cost.

How do you implement a consistent least privilege access policy in a big and complex single AWS account or in a multi-account setup? How do you limit the blast radius in case of a security breach?

Securing AWS resources the old-school way

AWS API authentication is something that is managed on a per-account level, and in case of a security compromise, someone can gain access to all resources in an account. A best practice is to limit each individual’s access to just the APIs and the API calls that they require to perform their daily work. This is all good and sounds perfectly logical until your team gets big and you need to implement more complex IAM policies.

Tags to the rescue! One way to limit access to one service in a shared account between several teams is to use resource tags and conditions in the IAM policies.

This approach is recommended by AWS, but speaking from personal experience this is not a silver bullet.

One problem with this approach is that not all resources support tags.

Which is weird since AWS tell you that you should tag everything.

As your environment gets more and more complex, so do your IAM policies which also increases the risk of errors in them. At this point, it’s a good idea to start thinking about limiting the scope of your credentials on an account level.

Introducing AWS Organizations

To achieve this you basically create more accounts to separate different teams, projects or departments. This approach has several advantages in addition to limiting the scope.

One big plus is that AWS cost can be separated by environment, project or business unit for example. When you use a single AWS account, some cost factors can’t be allocated to the corresponding cost center, for example, network traffic. Another advantage is that now you can’t have two teams interfering with each other due to something like resource limit exhaustion.

As a negative, networking can become complex, but it depends on the use case. Managing several accounts doesn’t seem troublesome, but with the increase in the number of accounts, management can become a problem. This is where you might benefit from AWS Organizations.

Here are some example setups:

AWS Organizations was released in early 2017. It allows you to manage multiple accounts and have a central paying account called master.

Additional pros are that volume discounts are shared between all the accounts in an organization and that you can use the so-called Service Control Policies (SCP) to limit certain services and regions from being used in an individual account or a group of accounts. SCPs act more like a boundary, meaning they limit what you can use in a specific account. SCPs help you with security policy enforcement as they can’t be bypassed even by the root user of an AWS account.

An SCP can be assigned on the organization root. This means that it’s inherited by all accounts in the organization. It can be assigned on an Organizational Unit (a group of accounts) or on an individual account.

SCPs use the same syntax as IAM policies so it’s nothing that a typical engineer with some knowledge in IAM can’t understand. SCPs can be whitelists or blacklists. A best practice is to choose one type and make sure you stick with it as mixing them can lead to confusion.

Another benefit of AWS organizations is that the account creation/management can be implemented entirely through code. Thus you are able to create as many accounts as needed (some companies have gone berserk and have thousands of accounts). This means that you can separate your infrastructure and thus limit the blast radius. More on this topic will be covered in a future blog post.

Final thoughts

The engineers at AWS have worked hard on making it easy to build and manage an organization. Currently, there are two major AWS products that can help you with this. The first one is AWS Landing Zone and the second is the brand new AWS Control Tower.

AWS Landing Zone has been available for a while. It provides standard multi-account patterns, the ability to apply a baseline to each account and some basic networking like VPC peering. While this solution works there are some cons to it. It’s not trivial to make changes and troubleshooting can be frustrating as there are many moving parts involved.

At the time of writing this post (summer of 2019), AWS Control Tower was just released and it’s not a mature service. If you already have an AWS organization then you can’t use Control Tower and also there is still no API available. I’m sure that, in the future, AWS will polish Control Tower and it will become the standard.

Stay tuned for our next post when we will share how we implemented AWS Organizations at ST6.

Deliberately Crafting an Organizational Culture

Wed, 19 Jun 2019 00:00:00 GMT

Back in the day when we started ST6 we knew we wanted to build a company that would be a catalyst for profound positive impact on the world. We knew that the only way to make this happen was to gather great people together.

Soon after starting to look for our first hires we realized that having great people was just not enough. Coming from a fairly large enterprise we knew that "standard" organization methods would not work for our kind of people. We would have to reinvent the ways an organization operates in order to empower those great people.

We needed to build an environment which would allow those people to flourish. We needed to deliberately craft an organizational culture that would reinforce our core values. We needed to make culture our strategy.

Culture as a Product

We have already discussed that culture is a product on its own. Unfortunately very few companies realize this. It is sad to see startups talking primarily about their products and not mentioning a word about their organizational cultures. They are so obsessed with product features and funding that they kind of forget that a company is its people, not its product. In a sense they should strive for People-Culture-Fit over Product-Market-Fit.

On the other side of the spectrum are enterprises that try to enforce "culture" and "values" upon employees without realizing that they have lost any connection with them. C-level execs looking to digitally transform the organization, middle-level managers looking to hit the numbers and employees counting the working hours all floating in the same ship without clear purpose.

Why is it like this? Why do most organizations fail to build strong cultures? Why do very few organizations design their cultures deliberately?

Before answering those questions we need to step back and look at what an organizational culture is at its core.

It starts with Values

In his Understanding Culture post (I highly recommend reading it) Mike McGarr visualizes culture using the following diagram:

Original image from Mike McGarr blog.

Values and core values are what drives and bonds an organization. Values can evolve over time as your organization grows but core values shouldn't change. Core values are the principles that establish purpose and shape the mission of your organization. If they change you are in a different organization now.

Values are usually conceived by the founders and early employees when the organizational culture is incepted. It is critical to get those outlined early on.

Does your organization have values and core values? Have they proven themselves over time?

It's about delivering on your Values

Having values defined is the "easiest part". You need to deliver on those values. You need to act in line with your values. Everything you do, every little interaction, every message, every meeting, every pull request, every process, every tool should be aligned with your values. The same goes for the things you shouldn't do - if something is against your values just don't do it.

For example, Volkswagen has "We take on responsibility for the environment and society" and "We are honest and speak up when something is wrong" as values but they failed miserably to deliver on them - remember Dieselgate.

In order to create a strong culture it is critical for the founders (and early hires) to act in line with the company's core values.

Are you delivering on your core values? Do your organization leaders act according to your values? What are you willing to give up to have a value-driven organization?

Back to the main question: Why do most organizations fail to build strong cultures? I believe we have an answer: they have failed to discover their core values and to deliver them through behavior. It's that simple yet hard to execute. Everything else in your culture is derived from your values and your subsequent behavior.

Stay tuned for our next post when we will share our core values and how we are delivering on them.

The Future of UI is... Functional

Tue, 04 Jun 2019 00:00:00 GMT

Yesterday Apple announced their next generation UI framework - SwiftUI. What strikes me is its React-inspired philosophy. Not because it's component-based, not even for the declarative nature but due to its functional paradigm - the expression of UI structure in terms of composable functions with varying parameters.

To understand how we got here we must go back in time.

A UI component is born

Visual Basic was the first programming language to go mainstream with the concept of components in 1991. A couple of years later in 1997 VB got the capability to create custom user controls. Having custom components allows for two key aspects of component-based programming: encapsulation of logic and reusability. It also unleashed an ecosystem of 3rd-party component vendors that were building and selling commonly used components.

Original image from WinWord.

There was one big issue though: it was very hard to create really complex UIs. The supported way was to use the provided visual designer which generated a lot of boilerplate resulting in unmaintainable code.

Enter the (declarative) web

In the late 90s the web took over and slowly but steadily made all desktop development obsolete. What the web introduced was a declarative syntax (in the form of markup) for defining components. As it turned out markup's tree-like nesting syntax was suited very well for defining UI elements. It also raises the level of abstraction due to its declarative nature.

Markup came with its own problems to solve - there is an impedance mismatch between the UI declaration and the logic that drives it. In order to solve this problem a new glue layer was introduced (by framework authors) in the form of data-binding with the sole purpose of connecting the view.

It's functions all the way down

And then React happened: it was component-based, declarative and baked with functional concepts in mind. Initially React did not have function components, but those were added two years after the first public release and recently went mainstream with the introduction of React Hooks.

React's functional philosophy is so influential that all new UI frameworks are inspired by it. Today, Flutter and SwiftUI both have uni-directional dataflow, function components and state-driven interactions.

Original image from Flutter Docs.

The other interesting aspect of those new generation frameworks is how they tackle the impedance mismatch between markup and code - by using the full power of their programming languages to declare the UI. And we are talking about three completely different languages: JavaScript, Dart and Swift. Isn't this great?!

I'm super excited about what the future holds for UI frameworks. Maybe the best way to predict it will be to (re)invent it starting with first principles. One thing is certain - it will be component-based, declarative and functional. Perhaps it's Lisp all over again.

Upgrading the ST6 Meme Generator to Create React App 3.0

Wed, 15 May 2019 00:00:00 GMT

This is the second post in the ST6 meme generator series. You can read the introductory post here.

You probably know the saying "If it ain’t broke, don’t fix it" but that's not true for JavaScript projects. You should always keep them up-to-date. The ecosystem is moving so fast that being away for a week could result in hundred of dependencies to update.

A couple of weeks ago the Create React App maintainers released version 3.0 of this great tooling so we decided to upgrade the meme generator. Hooks support is now baked into Create React App so we needed no further reason.

One does not simply upgrade a JavaScript project

Upgrading to Create React App 3.0 is as simple as bootstrapping a new project with it (assuming you did not go wild and ejected the app). Executing:

yarn add --exact react-scripts@3.0.0

...and that's it. Almost.

Unfortunately it is rarely that easy in JavaScript projects. Running the app locally resulted in this strange and obscure error:

BrowserslistError: Unknown browser kaios

Indeed one of the changes in Create React App was related to Browserslist but nothing to do with this mythical browser named kaios.

Diving deeper into the issue it turned out that Browserslist is using Can I Use ... ? support tables under the hood which recently added support for a new browser: the one bundled in KaiOS - the spiritual successor of Firefox OS.

Upgrading the app resulted in two versions of Browserslist, each using a different version of the "Can I Use" database. One of the database versions supports KaiOS, the other - doesn't. With yarn's philosophy to not upgrade locked sub-dependencies, we get the KaiOS error.

The solution is quite simple. We just need to yarn like never before:

$ rm yarn.lock
$ yarn

This ensures that yarn uses the latest matching versions of all sub-dependencies and magically we have a working app.

Upgrading the configuration setup for Create React App 3.0

Setting the initial troubles aside, Browserslist config is now used for controlling the output of our JavaScript files. This means that we can use separate configurations for development and production ultimately resulting in quicker compile times locally. Here is the recommended configuration that we are using:

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

This configuration ensures that our app works correctly on all relevant browsers in production, but locally in development it targets just the latest versions of Chrome, Firefox and Safari. A nice tweak especially if you develop on MacOS.

The other big thing in Create React App is the built-in support for React Hooks. This comes in the form of bundling the react-hooks ESLint plugin. If you remember from our last post we have already used the plugin so it will be better if we remove it from our configuration/dependencies and let Create React App manage it.

...
"devDependencies": {
    ...
-    "eslint-plugin-react": "7.12.4",
-    "eslint-plugin-react-hooks": "1.6.0",
    ...
},
...
"eslintConfig": {
  ...
-   "plugins": [
-     "react-hooks"
-   ],
-   "rules": {
-     "react-hooks/rules-of-hooks": "error",
-     "react-hooks/exhaustive-deps": "error"
-   }
  ...
}

Crafting a great pull request description

You can judge great developers by the pull request descriptions they are writing. Are they walking the last mile when the code is "ready" to craft a great description of the applied changes?

A great pull request description is one that the reviewer would love to read. It's like an interesting book for a reader who is curious to read it and learn something new.

Upgrading dependencies might not be the most interesting thing to read about in a pull request description but we can change that. To improve the reading (and learning) experience we can link to the changelog for the specific version of each updated package. Thus everyone reviewing the pull request can educate themselves what exactly has been changed in each dependency.

We can use a Markdown table format in order to present those in a more digestible form. Here's how it's going to look in our case:

Package	Old	New	Changelog
react, react-dom	16.8.4	16.8.6	View
react-scripts	2.1.8	3.0.0	View
enzyme-adapter-react-16	1.11.2	1.12.1	View
husky	1.3.1	2.1.0	View
prettier	1.16.4	1.17.0	View

Tip

You can use the online Markdown tables generator to create nicely formatted tables.

When adding the links to the changelogs, make sure that you are linking to the correct heading and anchor for the respective version. You might even have to link to the changelog in a specific commit because some changelogs contain information just for the latest version. For such changelogs, when a newer version is released, your links become obsolete. This, for example, is the case with Create React App.

You can check out the final pull request in the Meme repo. It includes other goodies like adding linting for Markdown files and improving Jest coding experience by installing its types declarations.

Belonging Right from the Start

Tue, 23 Apr 2019 00:00:00 GMT

I dread being the new kid.

On my first day on a new job, I suddenly become very self-aware of my every quirk, of every out-of-place hair, of every wrinkle on my dorky T-shirt. To quote Eminem: "palms are sweaty, knees weak, arms are heavy". The only thing missing is the remnants of my mom's spaghetti.

I yearn for a magic wand, a voodoo charm, anything that would dispel the curse of the newcomer. Anything that would get me to that point in time where I already belong.

Funny thing. My first day at ST6 - I fit right in.

Even before I started, I knew I belonged

The first part of the recruiting process is a cultural screening. This isn't a place you grow a taste for, your mindset either belongs here or not.

For me, it was an instant click with the people and the vibe. My tribe, my religion - only I didn't know they existed until then. I'd call it "belonging at first sight" but that might be too cheesy.

Original image by lipefontes0 from Pixabay. Edited with the ST6 Meme Generator.

A welcome like no other

I've changed a few jobs in my time. I've had first days planned to the minute. I've had people handholding me through the induction. I've been abandoned to my own devices. I've been the exciting new curiosity and I've been the invisible newcomer.

What I haven't had was an ST6-style welcome. Picture a personalized greeting card on my desk. A desk with my preferred setup already in place (13-inch MacBook Pro, dual monitors, ergonomic chair). Some hugs. Gelato from one of the best ice cream spots in town. (No pics, since the gelato disappeared before I could Instagram it.) A team lunch. An invite to the team building that's about three months from now.

My first day at ST6 felt like a celebration. Or like coming home.

Included from the start

You know how your first week, first month, first six months are usually about patiently waiting to get accepted and included in the conversation? You're supposed to listen and observe, rather than express opinions.

I can't hide from the conversation at ST6. Every internal meeting ends with a quick checkout round where even the freshest fish in the pond must provide feedback on the session. Checkouts are an opportunity to learn what went well and what didn't work and improve future sessions based on that.

I am also welcome to join every internal focus group (circle) meeting to listen in, observe, or add an item to the agenda. Furthermore, attending these meetings is encouraged during the first few weeks, so that people can decide which circle to join and contribute to. (Yes, circles are internal focus groups governing certain aspects of the company - office, hires, operations, etc. Decision making is carried out based on consent from the circle or, when needed, from the entire organization.)

As part of the full transparency culture here, there are no hidden conversations going on. Everything is right there on Slack for the whole team to see and provide feedback on. My feedback is important and sought after. It won't always be applied but it will always be considered. And since transparency breeds transparency, I quickly found myself sharing my work as well as providing thoughts and peer reviews on the spot.

Bonding over food

Image by StockSnap from Pixabay.

I am fond of all things food and cooking. I like watching YouTube videos about recipes, I like reading about food, I like staring at food in my Instagram. When I travel, I am more likely to check "places to eat" and "must eat" lists before googling any local sightseeing or looking for an actual hotel. I also love baking and bringing baked goods to people. I sincerely believe that food is one of the ultimate bonding devices that society has invented! (And the University of Oxford obviously thinks so too.)

And, oh, boy, is social eating a part of the culture at ST6. Going out for lunch at 12 PM sharp is the law. On Fridays, the team goes out for a more lavish lunch experience and the company picks up the bill. Every early afternoon is "Mezze-O-Clock" - a magical sliver of time when people bond over a selection of cheeses and charcuterie, handpicked by our office fairy godmother Lidia (can we get some porchetta, btw?). It's a surprisingly efficient (and savory) way to blow off some steam and socialize.

The verdict, three weeks in...

A picture is worth a thousand words. Just check out yours truly immortalized in an ST6 meme.

Crafting the ST6 Meme Generator

Tue, 26 Mar 2019 00:00:00 GMT

But why?

At ST6 we believe that great people build great products. But having great people is not enough, you need to build an environment which will allow those people to flourish. You need to nurture a strong culture that will reinforce your core values.

What can be more valuable than having your own meme generator that can be used to spread your ideas, behaviors, styles, or values within or outside of your organization. After all

"Every software organization should have its own meme generator".

... but please don't quote me on that on your next all-hands meeting.

Let's leave the cultural story for another blog post and focus on the technology. This was supposed to be a technical post.

We love React and as soon as Hooks were officially released we knew we want to try them out. We were keen to rewrite all our code with Hooks (without bringing any value to our customers) but eventually decided to used them in a fresh project of ours because we love sarcasm and bad jokes.

And that's how it came to be: Memes + Hooks = Awesomeness.

TL;DR If you want to generate your own memes go to https://st6.io/meme. The source code is at https://github.com/st6io/meme.

Bootstrapping the meme generator app

It's 2019 and if you are not using Create React App to bootstrap your next React app you are doing it wrong. Gone are the days when you have to spend weeks evaluating different starter kits, because none match your preferences. Create React App does all the configuration for you and comes with great defaults. With version 2 there is even less need to eject the tooling, because it comes with CSS modules, Sass and Babel macros support. Running

yarn create react-app meme

... and we are done.

After yarning the app with Create React App we are extending the setup with the following configurations.

Pinning the Node.js version

We want to pin the Node.js version in order to avoid hard to reproduce issues and ensure all two of us are using the same version of Node while working on the app. We are using .nvmrc (and nvm) that usually points to the latest LTS version of Node at the time of bootstrapping. Additional benefit of locking the version is that most popular CI providers do support it which yields that they will use the specified version of Node while running your CI pipeline.

Installing code formatting tools

We are huge fans of Prettier and install it in every project we work on. It allow us to focus on the problems we are trying to solve instead of debating over the visual esthetics of the code. After all we are not painting an impressionist art, but rather crafting solutions for real world problems like generating memes.

Prettier comes with great defaults but we like to tweak them in order to match our own preferences. There are a couple of ways you can configure prettier (it is using cosmicconfig) but in our case we want to keep it simple by just adding the following key in our package.json:

"prettier": {
  "singleQuote": true,
  "trailingComma": "all"
}

In addition to configuring our editors to support Prettier we also like to have a simple command that can be run in order to format the whole codebase. It is a one-liner that can be added to the scripts section:

"scripts": {
  ...
  "format": "prettier --write \"src/**/*.{js,json}\"",
  ...
},

Configuring linters

Create React App comes with ESLint support out of the box. The default configuration comes from the react-app package which has a good set of basic and accessibility rules defined. We would like to extend those with some React-specific rules recommended from eslint-plugin-react.

We better install the all new and fresh react-hooks ESLint plugin as we are going to be using React Hooks. Hopefully Create React App will include it by default because everyone is using hooks nowadays (mainly for demos or funny blog posts).

Here is the final linting configuration from our package.json:

"eslintConfig": {
  "extends": [
    "react-app",
    "plugin:react/recommended"
  ],
  "settings": {
    "react": {
      "version": "detect"
    }
  },
  "plugins": [
    "react-hooks"
  ],
  "rules": {
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "error"
  }
}

Additionally you can include other awesome ESLint plugins for React Native, lodash or GraphQL. You can even include a unicorn 🦄.

Finally we are going to add a new script for running the linter:

"scripts": {
  ...
  "lint": "eslint src",
  ...
},

Installing pre-commit hooks

The final step of the bootstrapping process is to install pre-commit hooks so that all configured tools will be run automatically before committing. We are going to call out for help from our good friends husky and lint-staged.

Here is our lint-staged configuration in packages.json:

"lint-staged": {
  "src/**/*.js": [
    "prettier --write",
    "eslint --max-warnings=0",
    "yarn test --bail --findRelatedTests",
    "git add"
  ],
  "src/**/*.{json}": [
    "prettier --write",
    "git add"
  ]
}

A couple of things to note here:

We are running eslint with --max-warnings=0 option that specifies that we will treat warnings as errors. It is a nice trick if you are integrating new ESLint plugins and you want to gradually integrate their rules in your code base.
We are running Jest tests with --findRelatedTests option which will find and execute just the tests related to our changes. That's another neat trick you can use if you have large test suites.

Finally we need to let the dogs out and configure husky to lint-stage before committing:

"husky": {
  "hooks": {
    "pre-commit": "cross-env CI=true lint-staged"
  }
},

You might be wondering why we are setting CI=true. Jest (our test runner) checks it under the hook and disables its default watch mode when it's present. Pure magic.

We are also using cross-env in case Apple continues its downfall with MacBooks and we have to switch to Windows.

At that point you should be hooked. There are React Hooks, Git Hooks...

It's hooks all the way down.

Styling the meme generator app

Once the app has been bootstrapped comes another mission-critical decision we have to make: What we are going to use for styling?

We have been successfully using Semantic UI, Material UI, Bootstrap all along with CSS modules. We have even used JSS in one of our projects.

This time we decided to be even more hipster and go with styled-components <💅>. We liked the simplicity of Rebass' primitive components and we were quickly ~~sold~~ hooked.

Having never used styled-components before we can definitely say that it is a very good alternative that you should be checking out. Especially if you are building your own design system (style guide) from scratch.

Another benefit of using Rebass is that it is built on top of styled-system and is easily themeable. One of the highest priority requirements for our app was to have a dark theme, because memes are usually generated outside of working hours.

You can check our light and dark theme definitions in this file. In the future we might even want to support prefers-color-scheme: dark media query. You can try to find the hidden toggle (it's an Easter egg) that can be used to switch between the themes in our final app.

Implementing the meme generator app

We are approaching the mid of the post but haven't used React Hooks yet. It's time to "enter the codebase and do whatever we want".

Adding meme labels

The essence of every meme generator is having top and bottom labels that can be changed from some inputs. Let see how can do that using Hooks:

const onLabelChange =
  setter =>
  ({ target: { value } }) =>
    setter(value);

const App = () => {
  const [topLabel, setTopLabel] = useState('Do the most meaningful meme...');
  const [bottomLabel, setBottomLabel] = useState('...of your life');
  const [imageSrc, setImageSrc] = useState(getRandomMeme());

  return (
    <Card variant="primary" mx="auto" my={3} pt={3}>
      <Flex flexDirection="column" px={3} pt={3}>
        <Input
          variant="primary"
          placeholder="Top text"
          value={topLabel}
          onChange={onLabelChange(setTopLabel)}
        />
        <Input
          variant="primary"
          placeholder="Bottom text"
          value={bottomLabel}
          onChange={onLabelChange(setBottomLabel)}
        />
      </Flex>
      <Meme {...{ topLabel, bottomLabel, imageSrc }} />
    </Card>
  );
};

🎉Congrats. That's your first usage of React Hooks right there. Good news is that they work as promised. We are storing the labels' state via useState and then passing the values to the <Meme /> component.

A neat trick to remove code duplication is the extraction of the change handler logic into a new higher order function. It destructures the changed value from the input and passes it to the state setter function.

Now let's look at the <Meme /> component.

Visualizing the meme

There are a number of ways to implement the actual meme component including DOM elements, Canvas or SVG. Taking into a account that we have to export an image for the meme and we have to support all browser eliminates the DOM elements option (dom-to-image does not support Safari). Canvas solution was eliminated as well due to its imperative API which does not fit well into React's declarative nature. And we are left with the SVG as the only viable option.

Using SVG comes with its own set of problems (sounds like choosing to use Regular Expressions).

The first issue we knew about was that there is no way to wrap text. It's coming in SVG 2.0 but for now we have to use the <foreignObject /> trick in order to insert some DOM elements into the SVG itself.

The second issue comes from the fact that SVG is not using a CSS like box model, but rather its own canvas-like positioning system. Combining that with the fact that we have to display raster images and we end up in a situation where we have to dynamically adjust the <svg /> width and height based on the image's dimensions. Thankfully there is a hook for doing this: the almighty useEffect.

Let's look at the code of the <Meme /> component.

const MemeText = styled(Text)`
  position: absolute;
  width: 100%;
  bottom: ${props => (props.verticalAlign === 'bottom' ? 0 : undefined)};
  color: white;
  font-family: 'Impact', 'Oswald', sans-serif;
  font-weight: 700;
  text-transform: uppercase;
`;
MemeText.defaultProps = {
  verticalAlign: 'top',
};

const Meme = ({ imageSrc, topLabel, bottomLabel }) => {
  const [dimensions, setDimensions] = useState({});

  useEffect(() => {
    const image = new Image();

    image.onload = () => {
      const { width, height } = image;
      setDimensions({ width, height });
    };
    image.src = imageSrc;

  }, [imageSrc]);
  return (
    <svg {...dimensions}>
      <image xlinkHref={imageSrc} width="100%" height="100%" />
      <switch>
        <foreignObject width="100%" height="100%">
          <MemeText>{topLabel}</MemeText>

          <MemeText verticalAlign="bottom">{bottomLabel}</MemeText>
        </foreignObject>
      </switch>
    </svg>
  );
};

Our hook logic is simple: once the image is loaded we take its width and height and pass them to the SVG. As loading images is an async operation we need to store the dimensions in the state. The key thing in using state and effect hooks in combination is specifying your dependencies (the second array argument of useEffect) otherwise you will end up in an infinite recursion. The effect is causing a re-render because it updates the state, but the render is causing a new effect and 💥. In our case, we want the effect to kick in only when the image source is changed.

Another interesting part of this code snippet is the <MemeText /> component. It is a styled-component that has a custom property verticalAlign used to donate whether it's the top or the bottom label. The usage of tagged template literals really fits well into the styled-components' philosophy.

Note

This example is simplified in order to be easily comprehendible. The actual code is a little bit more involved because it supports maximum width for the SVG element in case the image is large.

Exporting the meme

Turning SVGs into raster graphics is as simple as installing the save-svg-as-png and calling its saveSvgAsPng function. The only interesting part is that the API expect an SVG DOM element as its first argument. In React words it's ref time, but unsurprisingly there is a hook for that as well: useRef.

We need to have the ref in the <App /> component so we can pass it to the saveSvgAsPng function. Here is the relevant part of the code:

const App = () => {
  //...
  const ref = useRef(null);
  return (
    <Card variant="primary" mx="auto" my={3} pt={3}>
      <Button
        variant="primary"
        onClick={() => saveSvgAsPng(ref.current, 'meme.png')}        title="Download image"
      >
        Download
      </Button>
      ...
      <Meme {...{ topLabel, bottomLabel, imageSrc, ref }} />
    </Card>
  );
};

Now let's go to the <Meme /> component to see how are we going to handle the ref:

const Meme = ({ imageSrc, topLabel, bottomLabel, forwardedRef }) => {
  //...
  return (
    <svg {...dimensions} ref={forwardedRef}>    ...
    </svg>
  );
};

const MemeWithRef = forwardRef((props, ref) => (
  <Meme {...props} forwardedRef={ref} />));

We use the ref forwarding concept from React and we forwardRef the passed ref from the <App /> to the <Meme /> and down to the <svg /> itself.

There are even more hooks in the final version of the code because it handles responsive layout via useMedia hook. Along with hooks, there is a neat trick that dynamically requires all meme images from the /memes folder, but let's leave all that for the curious reader to pursue in the GitHub repo.

Testing the meme generator app

Every well-crafted software should be guarded by well-crafted tests.

We are fans of radical unit testing which means having 100% code coverage. After all, why you have written a given piece of code if it is not being exercised? If you do not want to test (or can't for that matter) given part of your code you better be explicit about it.

I wanted to be clear that 100% code coverage is not an end in itself. It's just a great tool to force us to think three times before writing any piece of production code.

Configuring the test runner

Create React App comes with Jest support out of the box and Jest is our preferred JavaScript testing framework. Apart from having a fast and reliable test runner being able to use snapshots is a great way to test your React components.

We are going to extend the default setup by installing Enzyme, along with:

jest-enzyme - provides some nice assertions on top of Enzyme (toExist(), toIncludeText(), etc.).
jest-styled-components - provides styled-components specific snapshot testing and assertion (toHaveStyleRule())

Here is our testing configuration in package.json:

"jest": {
  "snapshotSerializers": [
    "enzyme-to-json/serializer"
  ],
  "collectCoverageFrom": [
    "src/**/*.js"
  ],
  "coverageThreshold": {
    "global": {
      "branches": 100,
      "functions": 100,
      "lines": 100,
      "statements": 100
    }
  }
}

And our setupTests.js (which comes from Create React App):

import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
import 'jest-enzyme';
import 'jest-styled-components';

configure({ adapter: new Adapter() });

Writing the tests

One of the interesting challenges while writing the tests was how to mock the side-effect of loading images and reading their dimensions within the <Meme /> component. Create React App configures Jest with jsdom which yields that we cannot load images like we would normally do in a browser.

Nevertheless there is a way to mock this on your own. If you remember our hook was reading an image's width and height once it is being loaded and that's exactly what we are going to mock:

// dimensions variable defined

const spy = jest
  .spyOn(Image.prototype, 'src', 'set')
  .mockImplementationOnce(function () {
    this.width = dimensions.width;
    this.height = dimensions.height;
    this.onload();
  });

We are spying on the Image prototype object and when the src property is being set we assign the width and height of the image and call its onload handler.

Note

In the mock implementation we are not using an arrow function in order to be able to access the correct this - the one that points to the Image object being mocked.

Reporting code coverage results

Running yarn test will run Jest in watch mode that does not report code coverage results by default. In order to tell the runner we need coverage we have to pass --coverage switch to the command:

yarn test --coverage

Jest bundles Istanbul as code coverage tool so we get a nice lines covered report after running the command in ./coverage/lcov-report/.

Integrating this with online tools for code coverage is even easier. Let's look at our final ci script that lints, tests with coverage and finally reports the coverage results to Codecov:

"scripts": {
  ...
  "ci": "yarn lint && cross-env CI=true yarn test --coverage && yarn codecov",
  ...
},

This command is run on every CI build. But what do our CI and CD pipelines look like?

Deploying the meme generator app

The beauty of client-side only apps is that you can literally deploy them everywhere including 5$ IoT boards that can serve HTTP requests.

We decided to go with S3 and CloudFront because our site has already been using it and we can leverage some of the existing infrastructure like setting up SSL for the CloudFront distribution.

I'm not going to go over the process of setting up a S3 bucket and CloudFront distribution as it is already well documented but rather focus on some interesting challenges that we face due to the fact that the app should be hosted in a subfolder: st6.io hosts our website (which is a React app built with Gatsby) and st6.io/meme should host the meme generator.

Configuring for subfolder hosting

The first thing we have to do is to tell Create React App that it should build the app with relative paths. Let's do that by specifying the homepage in package.json:

"homepage": "https://st6.io/meme"

The second thing comes from the fact that we are reusing the same CloudFront distribution for both our site and the meme generator. CloudFront does support this but it requires configuring a second origin (in our case the meme generator S3 bucket configured for static site hosting) and adding a behavior to point to that origin. The cache behavior needs the following path pattern: meme*. That tells the CDN to reroute all requests to st6.io/meme* to our meme generator. There is one more caveat here and it comes from the fact that when the request is rerouted it will search for ./meme/resource-name in our S3 bucket. This means that we have to upload our build artefact (static files) in a meme folder inside the bucket.

The third thing to handle is the CDN invalidation once the bucket is being updated. It is a one-line command using the AWS CLI but there is a npm package just for this so we decided to go with it in order to not require the AWS CLI pre-installed.

Here is our Travis CI configuration file:

language: node_js

cache: yarn

install:
  - yarn global add travis-ci-cloudfront-invalidation
  - yarn

script:
  - yarn ci || travis_terminate 1
  - yarn build

deploy:
  provider: s3
  access_key_id: $AWS_ACCESS_ID
  secret_access_key: $AWS_SECRET_ID
  bucket: st6-meme
  upload_dir: meme
  local_dir: build
  skip_cleanup: true
  on:
    branch: master

after_deploy:
  - travis-ci-cloudfront-invalidation -a $AWS_ACCESS_ID -s $AWS_SECRET_ID -c $CF_DISTRIBUTION_ID -i '/meme/*' -b $TRAVIS_BRANCH -p $TRAVIS_PULL_REQUEST

Some things to note from it:

We are not specifying the Node.js version. Travis is smart enough to read it from the .nvmrc file.
We haven't added the travis-ci-cloudfront-invalidation package as an app devDependency. We want to leave the deployment specifics outside of the app's configuration.
We are specifying the S3 upload_dir to meme in order to handle the above mentioned caveat.
We are telling CloudFront to issue an invalidation only for '/meme/*' resources in order to speed things up.

Do the most meaningful meme of your life

We are nearing the end of our journey. We started with an ambitious goal to craft a meme generator and ended up with an app deployed at https://st6.io/meme.

There is one more thing we need to do before starting the promotion of the app with silly blog posts. We need to add badges to the readme, because

Every craftsman signs his ~~work~~ craft.

We are going to use the great service at Badgen to generate some cool badges and add them to our readme:

... and with that, we can declare "Let there be memes!".

It's time to do the most meaningful meme of your life!

You can read the next post in the ST6 meme generator series here.

Looking to join the culture you've been dreaming about? Ready to take the red pill? Want to have more fun with React Hooks? Come and meet us.

Startup Survival Tip #4: Culture is a Product on Its Own

Tue, 12 Feb 2019 00:00:00 GMT

I feel like I'll be beating a dead horse here. So much has been said about building a strong company culture, yet so few companies succeed. When I read about other companies' culture it's a bit strange to hear about the "perks" of the company as if that's actually the culture of a company. And I've heard one too many companies talk about their "great company culture" when all we're told about is the perks. Let's take a look at what is "Culture," how do you build it, and how not to be like everybody else.

Define Culture

If you don't consciously and meticulously think about the culture you're creating while you're building your company, you will have a very hard time building a successful company. Not that it's not possible, but the odds are highly against you.

Identifying the key components of culture is crucial to building the right culture. Harvard Business School identifies these six components when it comes to culture:

1. Vision	4. Narrative
2. Values	5. People
3. Practices	6. Place

My take is slightly different. The reality is that if you have the first three items in the list (Vision/Mission, Values, and Practices), then the other three should fall into place. I guess you could say that these are your three pillars! Note that I'm considering Mission and Vision to represent a single pillar, while they're two separate ideas. Exceptional Vision, Mission, Values, and Practices will allow you to attract exceptional people, to form a compelling narrative, and to build an exceptional place. There is also a feedback loop, where the people will also affect the Values and Practices.

When I was building BitLendingClub, I honestly didn't think about any of those things. They existed in some form, they were great in my mind, but that's the only place they were great. If you actually looked at our company, I'm almost certain that nobody could tell you what our mission was, yet I thought we're mission-driven. But here is the worst part:

We didn't agree on a single set of values.
Our practices were whatever we inherited or picked up along the way.
Turnover of talent, over the 3 years we existed, was high for a company of 10.
The narrative was that of the founders, not the people within the company.
The place we worked at was whatever we could scrap together.

Don't be like old me!

Pillar 1: Formulate A Vision (and Mission)

I'm not just talking about your vision and mission statements. While the vision and mission statements are a great way to convey the vision/mission of a company with a short statement, everybody within the team needs to have a deep understanding of what they are. They need to be clear, concise, and most importantly- inspirational. It is the reason your company exists: it is the thing you're trying to change in the world, it is your Ethos, Pathos, and Logos.

Carefully think about them and craft them to truly represent how your company is changing the world. It will be the shining beacon that sets the stage for everything within your business. It will drive the way you market yourself, how you distinguish yourself when recruiting employees, how you approach your customers, how the public perceives you, and everything that follows.

Companies with a strong vision and mission will have a much tighter focus. Think of your Vision and Mission as a black hole: everything that gets sucked into the black hole will accelerate towards a single point: the singularity! Everybody that gets "sucked into" your company should accelerate towards the singularity!

Pillar 2: Identify Your Core Values

This is the second pillar on which you'll build your company. Values are your guiding principles, foundational beliefs, and core philosophy. Values define how you orient and conduct yourself in the world. Your decisions should be filtered through your values. When you engage with your clients, employees, prospective employees, and society in general, you will conduct those interactions with your core values in mind.

Anybody that has worked in different companies will attest to the vast cultural difference that develops in the various companies. And not all cultures are the same, some are actually better than others. In those better cultures, employees are more satisfied, productive, and engaged.

A couple of our team members came from a company in which the culture had developed in such a way that big egos were valued. Management regularly threw employees under the bus and belittled them when they spoke up about issues. It doesn't take long before resentment builds up. The moment things got heated up, as it happens when you're building a company which attempts to solve enormous challenges, people reach a breaking point and they quit. The company has 275 employees and has had a turnover of 200. So not only do you have to ensure you have the right values but you have to adhere to those values. One of the worst thing that can happen is to let people in the company subvert the culture and away from your core values. That leads me to the next pillar: Practices!

Pillar 3: Build Strong Practices

At ST6, we regularly question the merits of conventional practices. One of the most common "themes" we see in businesses is the emergence of top-down organizational structure. The most successful companies in the world have a top-down structure, so it would be a bit crazy to think that we'd reinvent the wheel. However, most professionals have experienced at least some of the pitfalls of this approach:

Information Drip: nearly every company talks about openness and transparency, but practically none of them are truly that open or transparent. The information is usually limited to a handful of people, and the most mission-critical information is limited to the leadership. Most companies have come up with all sorts of justifications for this, which do sound reasonable on the surface.

Altitude Haze: decisions are taken at the higher levels of the company and filtered down through the various layers of management. Coupled with the Information Drip, this often results in people feeling like the decision-making process is hazy. The decisions of leadership are frequently doubted, employees feel like the leadership doesn't consider relevant information from the "front lines," and when changes in direction are taken, people feel like the original decisions were bad. That leads to frustration over time.

Talent Squash: undoubtedly, you're trying to hire smart people in your company and they have exceptional talents which would greatly benefit the company if they're fully utilized. If the information that reaches your employees is restricted, then naturally, management wouldn't want to relegate important decisions to employees lower in the organizational structure. Not because they're not smart people, but simply because they lack the necessary information to make important decisions. That underutilizes the talents of the people you've recruited, limits their learning potential, and causes resentment to build up. There is a great sense of empowerment with being given the ability to make important decisions and people take it seriously when they are given such responsibility.

This structure is fairly rigid and it doesn't really evolve over time. Your business and your product do evolve over time, so it's strange that your organizational structure wouldn't. When you develop your practice, I strongly believe that you take the Lean Startup approach: Build → Measure → Learn.

Your company is going to evolve over time, so should your practices. At ST6 we have regular organizational meetings in which we devise organizational experiments (build), we monitor the results of these experiments (measure), and we make adjustments based on the results (learn). Our experiments have led us down an interesting path: flattening the organizational structure. Note that I don't mean that adopting a flatter organizational structure would eliminate the hierarchy. Even a flat organizational structure is a form of hierarchy. But I'll save this topic for another blog post!

Startup Survival Tips #3: Delegate Responsibility

Wed, 10 Oct 2018 00:00:00 GMT

If you're building a company, you're not building it by yourself so you shouldn't be doing all the work by yourself either. You're most likely building a team of smart people. Those people should be able to take responsibility for things, freely express their opinions, and have the necessary room to independently take impactful actions. Failing to facilitate such an environment will prevent your team members contributing to their fullest potential. That's not only bad for your business, but it's demotivational and unrewarding for them.

Delegate Responsibility

I consider myself to be a pretty lazy person and I avoid doing things unless they're absolutely necessary for me to do. Unfortunately, over time, everything I do in my company seems like it's absolutely necessary for me to do! It feels like I have to do the payroll, invoicing, marketing, advertising, branding, hiring, sales, customer success, and the list just keeps growing. And over time, it becomes easier to convince yourself that you shouldn't bother the rest of the team with those little things:

The team member should focus on the core things.
The fewer distractions for the team, the more productive they are.
I'm the only one that can do X since I have the most experience or domain knowledge.
Nobody wants to do these boring things, so I'll do them.

Unfortunately, at some point, this ends up eating too much of your time and you'll start losing focus. You'll get overwhelmed with things that you really shouldn't be doing. Ultimately, you may even sacrifice part of your competitive advantage you have compared to bigger companies: the opportunity to provide your team with the learning experience of building a startup from scratch. If you try to run your business like a big corporation where there are dozens of departments which take care of all of the distractions, then why would anybody bother to come and work for you?

So work with your team members to delegate as many of your responsibilities as possible!

Empower Individuals

At ST6 we have devised a flat company structure, which aims to empower each individual to utilize their maximum potential. Our structure is based on some of the core concepts from Sociocracy 3.0, with some adjustments to suit our team. The main idea behind sociocracy is to organize the company into cohesive groups, which are independently and interconnectedly responsible for various parts of the organization.

The core building block of the organization is the circle. Within ST6, each circle has the following:

Champion
Secretary
Roles/responsibilities
Accountabilities

I'm not going to spend a whole lot of time going into how this is all organized, but the general idea is to be able to give up control of certain company efforts and focus on the things where each individual can contribute with maximum value. This provides individual team members with the ability to take ownership and make key contributions to the business. It also eliminates the "fog of war" so-to-speak, which usually exists in traditional organizations. Where the "fog of war" is the obfuscation which occurs due to the vertical hierarchical structure of the organization and the restriction of information flow. There is still a hierarchy within Sociocracy, despite what the proponents claim, but it's horizontal and it provides higher transparency.

Finally, the most important part of the delegation of responsibility is to provide your employees with enough freedom to succeed and fail! Both are necessary because you're just as likely to fail as they are. Shielding them from failure is also shielding them from the opportunity to learn, and learning leads to success. Now, we should be very careful about what it means to fail: failing in a controlled experiment is good, but failing due to incompetence is bad! So fail successfully! :)

Startup Survival Tip #2: Always Have a Contingency Plan!

Mon, 01 Oct 2018 00:00:00 GMT

When I was at Boost VC, each meeting room had a brainy quote on the wall. One of the rooms had the following quote: "Startups are like paper planes, they look better than they fly!" To be honest, I never even liked the look of paper planes, but they are certainly a good metaphor for startups. Even if you build one that looks like it can fly, it will most likely end up in failure. So one should always prepare for failure!

Always Have a Contingency Plan

During our amazing run with BitLendingClub we had achieved some fantastic results. We went from the underdog to being the largest P2P Bitcoin lending platform in just two years. Even so, we faced the harsh reality: our revenues weren't enough to cover our burn rate. We were making half of what was necessary to cover our operating costs. That's why we had raised nearly $1 million in Seed funding, but the money was going to run out (as it eventually did). We had to find a way to generate revenue or raise more capital! Our competitors, BTCJam, had raised $10 million in Series A funding, and my assumption was that we could do the same since we had beat them on the market. We had achieved a bigger success with less funding and less time, so investors should consider us to be a better startup. It was a foolproof idea, what could go wrong?!

Our strategy was simple: we knew that P2P Bitcoin lending wouldn't get us to be profitable anytime soon, so we had to pivot and pitch the new idea. Thus came the new effort with Loanbase. As I've outlined in the previous blog posts: we made plenty of mistakes! The idea behind Loanbase was great: we had already built a software lending platform which in the hands of bigger lenders would provide massive reductions in costs, improvement in closing time, customer satisfaction, and ultimately: increased profits!

But then comes the unanswered question: "what if we fail?" More experienced startup founders know that there is a need to be prepared for as many "what if's" as possible. We didn't! We took the path of building the Loanbase platform and we worked on raising Series-A funding, but we didn't plan what we'll do if either of those fails. Eventually, both failed and we were left with no fallback option.

Rely On The Fundamentals

Obviously, you can spend a lot of time trying to figure out how you can fail at every step of your startup and how you can mitigate the risk, but that can be extremely time consuming and you can miss the big picture. There are some basic things that you can focus on, which can cover most of your bases. The fundamentals are your strongest foundation!

Run Controlled Experiments

Your business is an experiment in itself. You have a hypothesis and you're trying to validate it on the market. You should plan ahead to make sure that you give yourself the opportunity to run the maximum number of experiments until you find out what works. Each experiment should be controlled, measured, and its failure shouldn't lead to the failure of the company. So the more such experiments you can run, the more you can explore the space of possible solutions for the problem you're trying to solve. Without this, you're relying on luck. You might as well play the lottery at that stage!

Generate Revenue

As I said in the previous post, revenue is your biggest lifeline and your biggest backup option! If you have a solid stream of revenue, you can sustain your business for a longer period during your experimentation phase. Your early experiments should be focused on finding the fastest path to revenue.

Raise Capital

If you fail to generate revenue, your next backup option is to raise capital. At the various stages of your startup investors have a varying amount of tolerance for businesses without revenue. In the pre-seed stage, you are unlikely to have any revenue so investors are going to rely on, well… the fundamentals. They'll look at your team, your history, your idea, the opportunity, and what you've executed so far. Unless you already have a successful exit, when you're at the seed stage it will be great to show some revenue. And if you don't have revenue, you better make sure you show some amazing traction from the pre-seed stage (a hockey stick chart going up and to the right). When you reach the Series-A stage, it's generally expected that you'll have between $1 million and $2 million of recurring revenue.

Have an Exit Strategy

If you've reached this stage of the article, then you're looking at the end of your startup. You've either failed to run enough experiments, you've failed to generate enough revenue, and you've failed to secure enough capital. What do you do next? Well, throughout the entire time you're running your startup, you should always keep an eye out for who can buy your company.

You would have developed relationships with other founders in your space, hopefully, ones that are more successful than you are. These founders are running startups and one of their biggest problems is the growth of their teams. Recruiting is always their top priority and if they can take a shortcut by acquiring a smaller startup, they will! Remember, even the exit strategy will take several months to materialize. So always have a few startups who have made you an acquisition offer already which you politely turned down at the time. As long as they are growing, the door will remain open.

Startup Survival Tip #1: Revenue is Your Biggest Lifeline!

Mon, 23 Jul 2018 00:00:00 GMT

In the first installment of this series, I mentioned that the biggest reason for startup failure is lack of revenue! It should be a no-brainer, but many entrepreneurs (including myself) have failed to grasp this little idea. It's so obvious: "DUH, of course, you have to try and generate revenue." One can lose track of this very simple idea while running a startup.

Value → Revenue → Profit

Never, absolutely never, ever, EVER, forget that your product has to bring value to your customers. And there is only one way you will ever know that your product brings value to your customers: when they're willing to pay for it! No amount of clicks, page views, shares, likes, retweets, or karma points, are ever going to tell you if your customer is actually willing to pay for your product!

If a customer has $100 in their hand and decides to buy your product, it means that the they value your product more than the $100 in their hand!

If you're generating value, somebody will pay for it and that will be your revenue. And if you're generating more value than it cost you to run your business (profit), then you're ready to ~~retire~~ solve big problems!

But My Product Isn't Ready Yet

The biggest mistake I ever made with Loanbase was to think that we need to build out a complete product to generate value. A little bit of a background story: Loanbase was a pivot from BitLendingClub. It took us two years to build BitLendingClub. Over those two years we had created scalable lending infrastructure which one would only see in (very) large banks. That infrastructure allowed two people to process over 8000 loans. Those two people were also responsible for answering the support inquiries.

Nearly every step of the loan process was automated. We saw the massive value that our infrastructure offered and we wanted to provide the same value to our Loanbase clients. We wanted to offer our clients the complete solution we had built. The reality was that our clients would have paid for a fraction of the product. They were so far behind from a technological standpoint, that any improvement in their process would have been welcome. Instead of focusing on breaking up the features and selling them separately, we tried to rebuild our entire system from scratch and offer it as a complete product. Fatal mistake!

We're not the first ones to make this mistake and we're not going to be the last ones. We were recently approached by a pre-seed startup, which wanted us to provide them with an estimate for an advertising platform. They had already invested about €5,000 EUR for the design and they were trying to estimate what their MVP would cost. They gave me the design and I did a rough estimate, which gave them a range of 5 to 11 months of engineering. It was going to cost them almost a year of engineering and upwards of $150K. And that's just to see if somebody would find their product useful. They wouldn't even know if advertisers would pay for it. Our team made a suggestion that they skip the entire engineering effort and run the first advertising campaign manually. Given their model of advertising, this was perfectly feasible approach. If they could run a single campaign, create a report for a single advertiser, then they could go with that report to the advertiser and see if the advertiser would be willing to pay for another campaign. All of that would cost them less than the €5,000 EUR it cost them to build out the designs!

Don't Be a Unicorn, Be a Cockroach

When I joined Adam Draper's Boost.vc accelerator program in 2015, the first thing he told us was to be cockroaches, not unicorns. I still kick myself in the rear end for not following this advice feverishly enough. Being an entrepreneur means that you're always faced with the risk of your startup joining the millions of corpses of the startups who braved the world and failed! Cockroaches are resilient, they survive in the most adverse of conditions, and so should your startup!

When you're running your startup it might feel like you're resilient and you're scrambling like a cockroach. Given how frequently startups fail, the statistics show that you're probably wrong! Indeed, you be paranoid, be afraid of failure, be prepared to weather the onslaught of challenges. Push yourself to be prepared for the absolute worst of days you can imagine. And when you're ready for that, then prepare for things to get 10 times worse! Which brings me back around to the topic of this discussion: REVENUE! Make sure that you have it, because when things get tough, you'll have something to fall back on and grind it out.

Startup Survival Tips

Fri, 20 Apr 2018 00:00:00 GMT

After two and a half failed startups, I’m starting to come up with a list of things which contributed to the downfall of my previous startups. And boy, that list is long, really long! There are some critical things, which I have identified as the major causes of “startup cardiac arrest.” I’ve mulled them over for a long time, but never written them down. Writing down the reasons meant that there would be a permanent record in history of my own failure. It would mean that I would also have to sit down and think about that failure and what it actually meant. The startup shipwreck itself was enough of a gut wrenching but actually sitting down and analyzing it is almost as unpleasant. For the past year and a half I've been on the board of our current startup, ST6 (https://st6.io), and the experience has given me an opportunity to gather my thoughts.

I’m going to take the top reasons and make a series of posts which act as a postmortem of sorts. Hopefully, they can also serve as tips for anybody who’s venturing into the wild world of startups! I’ll call them “Startup Survival Tips.”

Reason #1: Not Generating (Enough) Revenue
Reason #2: Failing to Have a Contingency Plan
Reason #3: Failing to Delegate
Reason #4: Company Culture Is a Product on Its Own

In the upcoming posts I’ll discuss how each one of those things contributed to the failure of the startups. I'll also highlight how we’re currently trying to avoid those problems.

In the meantime, I’ll set the stage with a brief history on the startups I’ve tried to build. I’m going to skip the attempts, as they were too miserable to even consider now.

BitLendingClub

Birth: Mid 2013 Death: December 31, 2016 Cause of Death: Reason #1 through #4

BitLendingClub was a P2P Bitcoin lending platform. It facilitated over 8,000 P2P loans which were worth over $8 million USD. We built the initial beta version in mid 2014 and by mid 2015 we had captured the majority market share. We were processing more than 50% of the P2P loans in the entire Bitcoin ecosystem.

Loanbase

Birth: Mid 2015 Death: December 31, 2016 Cause of Death: Reason #1 through #4

Loanbase was a pivot from BitLendingClub, which aimed to create a software platform for small business lenders. We discovered that our engineering approach has allowed us to achieve amazing results! Just two of our team members managed to process over tens thousands loan applications in the span of a year. That would be unheard of in a “normal” lending institution. This meant that our each of our team members spent approximately 2.5 hours to process a loan application. That’s quite an improvement over the industry standard 8 to 24 hours! We estimated that we can get it to as low as 15 minutes per loan application. That would translate in massive efficiency gains for the lenders and a reduction in loan acquisition costs. The savings of could be passed onto the borrowers.

Dramler

https://dramler.com Birth: January 1, 2017 Death: May 3, 2017 Cause of Death: Reason #1

The closing of the BitLendingClub/Loanbase chapter led to a new opportunity. I got together with my current co-founders, Ivaylo “Ivo” Bratoev and Stefan Dobrev, and we went on a “hunt” for a new startup idea. We took inspiration from Vivino and made Dramler. Dramler is a “social platform to discover, define, and share your whiskey experience.” We built a prototype in less than 2 months and we launched it for both Android and iOS. The app is still up and running, but it’s mostly used for demo purposes now.

Stay tuned for the next installment of Startup Survival Tips!

Elite Team of Software Craftsmen - AI, Machine Learning, LLM Agents, Computer Vision, Data Intelligence, Robotics, Cloud, React, React Native, GraphQL development | ST6

ORGANIZATIONS OF THE FUTURE - ST6 Structure - Office circle

Purpose

Domain

Accountabilities

FlyCI is Unleashing the Power of Mac Runners for GitHub Actions

Benefits

Getting Started

Usage

Flexible Pricing

Runner Labels

Unleash The Power of Mac Runners!

Integrating Slack with G-Drive, using Google Apps Script

But why?

Solution overview

Set up the script environment

Get a Slack auth token

Retrieve data from Slack

Handle the circles participation table formatting

Update the Google Sheet

Run the script

End result

Bonus tips (security)

Final thoughts

Slack

Google Sheets

Migrating from Bootstrap to Tailwind CSS (part 3)

A quick recap of the chosen strategy

The tech stack

The execution phase

Step 1: Isolate react-bootstrap

Step 2: Integrate Tailwind CSS

Step 3: Rewrite components when possible

Conclusion

Supercharging GitHub Actions: Leveraging Jetson Nano's Hardware in a Self-Hosted Runner

GitHub Actions limitations

Our problem

Solution

Prerequisites

Step 1: Prepare the Jetson host

Step 2: Create and build a runner image

Step 3: Create a registration token from the GitHub UI

Step 4: Start a runner container

Step 5: Use our runner in a workflow

Common problems

Conclusion

Migrating from Bootstrap to Tailwind CSS (part 2)

Starting point

Research phase

Strategy 1: Complete rewrite of the app

Strategy 2: Update Bootstrap’s variables and theme

Strategy 3: Create a Component Library

Strategy 4: Integrate Tailwind CSS

The enablers

Conclusion

Migrating from Bootstrap to Tailwind CSS (part 1)

Why did we have to migrate from Bootstrap to Tailwind CSS?

How do Bootstrap and Tailwind compare from my point of view?

Conclusion

Weekly Knowledge Sharing - What You Need to Know

Knowledge is power

Weekly knowledge sharing sessions

Introducing Our NON-Q and Monthly Gatherings

NON-Q gatherings

Monthly gatherings

We will meet you there!

Meet the ST6ers - Iliyan

Why did you join ST6?

What do you like most about working at the organization?

The "A" players

The freedom to do what I'm passionate about

The challenges, both professional and personal

Klasik Klasikovich picnic team buildings

What would you say are some of the biggest challenges you face at ST6?

Show the best meme you have in your phone

Share your passions with us

ORGANIZATIONS OF THE FUTURE - ST6 Structure - Recruiting circle

ORGANIZATIONS OF THE FUTURE - ST6 Structure

At ST6 we have the following circles:

Meet the ST6ers - Petar

Step 1: Isolate `react-bootstrap`