Forem: Agastya Darma

Middle Management Is Hard

Agastya Darma — Sat, 02 Nov 2024 01:48:10 +0000

Lately, I’ve been reflecting a lot on the challenges of middle management, particularly after a conversation with a former coworker. Even though this individual isn’t a middle manager, their insights about feeling constant pressure from leadership really got me thinking. They described how leadership consistently pushes for higher performance and demands results, often without understanding the realities on the ground. It struck me that, while they bear the weight of these demands from leadership, middle managers face a similar pressure but from multiple directions.

Being middle management is incredibly challenging. You are expected to balance pressure from all directions above, below, and even from the sides. My experience comes from the tech industry, but I believe these observations resonate across multiple sectors. Middle managers are the glue that holds organizations together, but they are often underappreciated and left to face unique struggles. Sandwiched between company leadership and employees, they must navigate conflicting demands, limited authority, and, at times, an overwhelming sense of isolation.

In middle management, you constantly find yourself wedged between the high expectations of leadership and the needs of your subordinates. You're tasked with executing strategies from top management while simultaneously motivating and managing your team to deliver results. At times, you may agree with your team’s frustrations and concerns, yet you're still forced to put on a smile and enforce decisions that come from above, even when you didn’t have a hand in making them. It’s not uncommon for middle managers to find out about tough decisions such as budget cuts, reassignments, or new initiatives at the last moment, just like the rest of their team. This disconnection fuels a feeling of being left out or even powerless, yet you’re still tasked with being accountable for the success of your team.

The Many Pressures Facing Middle Management

Middle managers face a unique set of challenges that stem from being positioned between upper management and front-line teams. This intermediary space creates a range of pressures that require constant navigation.

1. Top-Down Pressure:

At the core of middle management's struggles is top-down pressure. Leadership has high expectations for performance, efficiency, and goal achievement. Strategic decisions are made at the higher levels, but middle managers are often left in the dark, tasked with implementing orders without being part of the decision-making process. For example, Jack Zenger and Joseph Folkman, in their studies of employee engagement, found that middle managers, particularly those with five to ten years of experience, are often disillusioned because they feel undervalued. They’re given tasks to execute but have little say in policy-making, causing frustration and disengagement. Many employees under middle managers don’t realize that these managers are frequently just as frustrated with the decisions from the top.

Middle managers, being closest to the workplace's actual dynamics, often have the most practical knowledge of what will and won’t work. However, they frequently find themselves informed about decisions after the fact and left to carry them out without the support or resources necessary for success. They are, in essence, expected to deliver results from policies in which they had no say.

2. Bottom-Up Frustrations:

On the flip side, middle managers bear the brunt of employee frustrations. For example, in the study by Zenger and Folkman, middle managers are often seen as the “face of management,” and when things go wrong or decisions don’t make sense, employees direct their complaints at these middle-tier leaders. Team members may not be aware that many of their objections are shared by their manager. As Anicich and Hirsh describe in their research on role-switching, middle managers are stuck in a “vertical code-switching” dilemma, where they must alternate between being an authoritative leader and a deferential subordinate, often within the same day.

This constant shifting takes a toll on mental and emotional well-being, leading to high levels of stress and emotional burnout. Middle managers are expected to maintain their team’s morale and motivation, even when upper management decisions leave them just as frustrated and powerless. They absorb complaints from below and directives from above with very little control of their own.

3. Side-to-Side Politics:

Middle managers also face significant peer pressure. Departments within organizations often operate in silos, and middle managers must compete with their peers for resources, recognition, and strategic visibility. Anicich and Hirsh emphasize that middle managers experience high levels of stress not only from above and below but also from their same-level colleagues. Whether it's negotiating resources, competing for development opportunities, or even juggling inter-departmental expectations, the middle manager experiences ongoing tension with little relief.

In highly competitive corporate environments, especially fast-paced industries like tech, collaboration often turns into a tug-of-war among middle managers, each vying for more bandwidth, budget, or visibility with leadership. If one department doesn’t deliver, the middle manager will feel the pressure from their leadership, even when the root cause of the issue is entirely external.

The Emotional Labor Involved

One of the most unseen aspects of middle management is its emotional toll. Julie Zhuo, who became a manager at Facebook (now Meta) at the young age of 25, recalls her early experience feeling like she was "in over her head." Zhuo reflects on the constant emotional labor required to support her subordinates while projecting confidence to her higherups. Like many middle managers, Zhuo initially believed that leadership meant projecting unwavering authority, but she found that approach ultimately alienating. Over time, she realized that successful management was much more about fostering collaboration than rigid top-down decision-making.

Middle managers often feel emotionally drained by the tension of mediating between the frustrations of their team and the demands of their leadership. Eric Anicich and Jacob B. Hirsh argue that middle managers experience high levels of "role conflict," where they're often caught between incompatible expectations. They must be empathetic to their subordinates while projecting confidence and competence to their superiors. This emotional balancing act places middle managers at a higher risk for burnout and mental health issues, including anxiety and depression, compared to employees at either end of the hierarchy.

The Isolation of Middle Management

Perhaps the most pervasive struggle faced by middle managers is the feeling of isolation. Both Zhuo and Zenger highlight how middle managers are often excluded from key strategic discussions. Many decisions are made at the executive leadership level, leaving middle managers responsible for enforcing and explaining these decisions, often without fully understanding them or having the opportunity to weigh in beforehand. The result is an overwhelming feeling of disconnect. You're expected to deliver results, but you’re not always given the tools or knowledge necessary to do so.

A study cited by Anicich and Hirsh involving over 21,000 employees revealed that middle managers reported higher rates of anxiety, stress, and burnout than those in lower or upper-level positions. This is compounded by the fact that middle managers lack the same support networks that senior executives or frontline employees might have available. Zhuo advises that in her own experience, middle managers need more access to leadership development and strategic involvement to feel less isolated and more connected to the larger mission.

What Can We Do to Improve Middle Management?

In my view, the traditional approach to managing middle managers just isn't cutting it anymore. The ongoing pressures and emotional strain that come from being sandwiched between leadership and teams need to be addressed. Here’s what I think can be done to alleviate some of these challenges.

1. Bring Middle Managers into Strategic Conversations Early

From what I’ve seen, one of the primary reasons middle managers feel disengaged is simply because they’re left out of major strategic decisions. As Jack Zenger and Joseph Folkman point out, this disconnection makes their job ten times harder. If leadership wants to get the best out of middle managers, they need to be brought into the conversation from the start. Whether it’s helping to shape company policies or providing feedback on new initiatives, direction will stick far better if middle managers understand and feel a part of the “why” behind these decisions. Giving them this sense of ownership fosters better implementation and ensures strategic objectives are grounded in the realities of the workplace.

2. Recognize and Reward the Emotional Labor of Middle Management

Let’s face it, emotional labor is a huge part of a middle manager’s role and often goes unrecognized. These managers aren’t just managing tasks and project outcomes, they’re balancing the emotional well-being of their teams while meeting deadlines.

But unfortunately, this aspect of the job is often perceived as transactional something that just comes with the territory. This is where companies need to step up. Recognize the complexity of the role. We need to do more than just acknowledge it, we need to actively reward it. And by reward, I don’t mean just compensation, but through recognition, support systems, and creating work cultures that reinforce the value they bring. Providing mental health resources is also crucial because it helps middle managers cope with the stress and ensures their emotional well-being, which in turn benefits the entire team.

Conclusion

Middle management is often one of the toughest, most thankless jobs in any organization. These individuals are tasked with balancing competing expectations, processing complex emotions, and producing excellent results despite limited authority and frequent isolation. However, the good news is that these challenges are not set in stone they can be managed and improved upon.

To make middle management more effective and sustainable, we need to start by rethinking the role. Empowering them with decision-making autonomy, involving them earlier in strategic discussions, prioritizing their own leadership development, building supportive peer networks, and recognizing the weight of their emotional labor are all essential steps. While these changes require deliberate effort from leadership, they are essential if organizations want to get the most out of their middle-tier management.

As Jack Zenger and Joseph Folkman have pointed out, middle managers aren’t disengaged because they lack ability they are disengaged because they aren’t managed well. The sooner organizations realize the centrality and importance of middle management, the sooner they can align themselves for sustainable success. After all, when middle managers thrive, so does the entire organization from the frontlines to the C-level.

GitHub Actions for Easy ARM64 and AMD64 Docker Image Builds

Agastya Darma — Thu, 16 Nov 2023 15:36:35 +0000

In today's rapidly evolving software development landscape, the ability to efficiently build and deploy applications across diverse architectures is crucial. This article will explore an advanced yet accessible approach to creating multi-architecture Docker images, specifically for ARM64 and AMD64 platforms, using GitHub Actions. We will dissect a YAML configuration for a GitHub Actions workflow named 'Deploy Production,' illustrating how to automate the building and pushing of Docker images to Docker Hub.

Our focus will be on leveraging the capabilities of GitHub Actions, including setup of QEMU for emulation and Docker Buildx for building images, along with caching strategies and security practices for Docker Hub integration. This guide aims to equip developers with the knowledge and tools needed to streamline their CI/CD pipelines, ensuring seamless deployment across varied computing environments.

name: Deploy Production
on:
  workflow_dispatch:
jobs:
  build-and-push-docker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      - name: Cache Docker layers
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-
      - name: Login to Docker Hub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: agasdrm/blog:latest,agasdrm/blog:${{ github.run_number }}
          platforms: linux/amd64,linux/arm64/v8
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache

Overview of Docker and GitHub Actions

Docker has revolutionized how we build, share, and run applications by enabling them to run in isolated containers. These containers package up code and all its dependencies, ensuring that the application runs quickly and reliably in various computing environments.

GitHub Actions, on the other hand, is a CI/CD (Continuous Integration/Continuous Delivery) platform that allows you to automate your build, test, and deployment pipeline. It is seamlessly integrated into GitHub, providing an efficient way to apply DevOps practices without leaving the GitHub ecosystem.

The Importance of Multi-Architecture Builds

With the growing diversity in computing hardware, it's become crucial to ensure that applications can run on different architectures. ARM64 and AMD64 are two prevalent architectures in use today. ARM64 is commonly found in mobile devices, newer desktops, and servers, while AMD64 (x86_64) is widely used in traditional laptops and desktops. Supporting both architectures ensures that your application can reach a wider audience and function in a broader range of environments.

Prerequisites

Before diving into the process, ensure you have the following:

A GitHub account - for accessing GitHub and using GitHub Actions.
A Docker Hub account - for storing and managing your Docker images.
Basic understanding of Docker - familiarity with Docker concepts like images, containers, and Dockerfiles.
Basic understanding of Git and GitHub - knowledge of repositories, branches, commits, and pulls.
Access to a code editor - like Visual Studio Code, Sublime Text, or any editor of your choice.

Understanding the Dockerfile

A Dockerfile is a text document containing all the commands a user could call on the command line to assemble an image. Using a Dockerfile, Docker can automatically build an image that includes your application and its dependencies.

Key Components of a Dockerfile

FROM: Specifies the base image from which you are building.
RUN: Executes any commands in a new layer on top of the current image.
COPY: Copies files or directories from your project into the Docker container.
CMD: Provides defaults for executing a container.
EXPOSE: Informs Docker that the container listens on specific network ports at runtime.
ENV: Sets environment variables.

Each instruction in a Dockerfile creates a layer in the image. When you change the Dockerfile and rebuild the image, only those layers that have changed are rebuilt. This is part of what makes images so lightweight, small, and fast when compared to other virtualization technologies.

In the next section, we will dive deeper into setting up our GitHub Actions workflow to automate the building and publishing of our Docker images for ARM64 and AMD64 architectures.

Understanding GitHub Actions

GitHub Actions is a powerful automation tool that integrates deeply with GitHub, providing a platform for automating software workflows. It's particularly useful in implementing Continuous Integration (CI) and Continuous Delivery (CD) processes directly within your repository.

What are GitHub Actions?

Automated Workflows: GitHub Actions allows you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.
Event-Driven: These workflows can be triggered by a variety of events within GitHub, such as push, pull requests, issue creation, or even a manual trigger.
Customizable: GitHub Actions provides a wide range of built-in actions, but you can also create and share your own actions or use actions shared by the GitHub community.
Containers and Virtual Environments: Actions can run in containers or virtual environments that you specify, ensuring consistency across different runs.

CI/CD with GitHub Actions

In Continuous Integration (CI), code changes are automatically tested and merged into a central repository. Continuous Delivery (CD) extends CI by automatically deploying all code changes to a testing or production environment. GitHub Actions facilitates both CI and CD by automating these processes, enhancing software quality and development speed.

Workflow Syntax Explanation

GitHub Actions utilizes workflows, which are defined by a YAML file stored in your repository's .github/workflows directory. These workflows specify the actions to be executed based on defined events.

Understanding the `workflow_dispatch` Trigger

Manual Trigger: The workflow_dispatch event allows you to manually trigger a workflow run. This is useful when you want to have control over when to run the workflow, as opposed to automatic triggers like push or pull requests.
Inputs: You can define inputs for the workflow_dispatch trigger, allowing you to pass parameters to the workflow at runtime.

name: Deploy Production
on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Deployment Environment'
        required: true
        default: 'staging'

In this example, the workflow_dispatch is configured with an input named environment. When triggering the workflow manually, you can specify the environment to which you want to deploy.

Workflow Anatomy A typical workflow file consists of the following key sections:

name: A name for your workflow.
on: The event that triggers the workflow.
jobs: A set of jobs that the workflow will execute.
steps: Individual tasks that run within a job.
runs-on: Specifies the type of machine to run the job on.
uses: Refers to an action to execute as part of a step.

Preparing for Docker Build

Before diving into the actual Docker build process, it's crucial to understand the role of QEMU in this workflow and how it's set up using GitHub Actions.

What is QEMU?

QEMU (Quick Emulator) is an open-source emulator that performs hardware virtualization. It is a key tool in the process of running software that is built for one type of processor architecture on another. This capability is particularly important when dealing with Docker images intended for multiple architectures.

Role of QEMU in Docker Builds

Emulation of Architectures: QEMU allows us to emulate different processor architectures, such as ARM64, on machines that have a different architecture (like AMD64). This is vital for building Docker images that are meant to run on multiple architectures.
Cross-Platform Compatibility: By using QEMU, we ensure that the Docker images built are compatible across different architectures, making our application more versatile and accessible.

Setting Up QEMU in GitHub Actions

The docker/setup-qemu-action@v1 action is used to set up QEMU in the GitHub Actions runner environment. This action simplifies the process of installing and configuring QEMU for our build process.

- name: Set up QEMU
  uses: docker/setup-qemu-action@v1

In the workflow file, this step ensures that QEMU is correctly set up and ready to enable emulation for different architectures during the Docker build process.

Docker Buildx Setup

Docker Buildx is an extended build feature of Docker that enables the creation of multi-architecture images.

Understanding Docker Buildx

Extended Features: Docker Buildx extends the capabilities of the standard Docker build commands, allowing for more advanced features, including building for multiple architectures from a single platform.
Simplifying Multi-Arch Builds: With Buildx, you can easily build images for architectures like ARM64 and AMD64, even if your build environment is different.

Setting Up Docker Buildx in GitHub Actions

The docker/setup-buildx-action@v1 action in GitHub Actions is used to set up Docker Buildx in the workflow.

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v1

By including this step in our workflow file, we enable the GitHub Actions runner to utilize Docker Buildx for building multi-architecture Docker images. This step is critical in ensuring that our Docker images are built correctly for the desired architectures.

Caching for Efficiency in Docker Builds

Efficient Docker builds often require a smart caching strategy. This section delves into the use of caching in Docker builds with GitHub Actions, particularly focusing on the actions/cache@v2 action.

Caching Docker Layers

Caching is crucial in reducing build time, especially when dealing with Docker images. Docker builds can be time-consuming, primarily due to the downloading of image layers and rebuilding steps. By caching, we can significantly decrease this time.

How Caching Works in Docker

Layer Caching: Docker builds images in layers. By caching these layers, Docker can reuse them in subsequent builds, avoiding the need to rebuild identical layers.
Impact on Build Times: Caching can drastically reduce build times, making your CI/CD pipeline more efficient.

Implementing Caching with `actions/cache@v2`

GitHub Actions provides a caching action, actions/cache@v2, which can be used to cache dependencies and build outputs to improve workflow execution time.

- name: Cache Docker layers
  uses: actions/cache@v2
  with:
    path: /tmp/.buildx-cache
    key: ${{ runner.os }}-buildx-${{ github.sha }}
    restore-keys: |
      ${{ runner.os }}-buildx-

In this snippet, the caching action is configured to cache the Docker layers.

Cache Keys and Paths

Understanding how to effectively use cache keys and paths is vital for maximizing the efficiency of your caching strategy.

Defining Cache Paths

Cache Location: In our workflow, the cache is stored in /tmp/.buildx-cache. This path is where Docker Buildx stores its cache data.

Cache Keys

Key Generation: The key for the cache is a unique identifier. In our example, it's a combination of the runner's operating system, buildx, and the SHA of the commit (${{ github.sha }}). This ensures that each build has its unique cache.
Restoration of Cache: The restore-keys option provides a list of keys to try when restoring the cache. In our case, it attempts to find the most recent cache that matches the specified pattern.

Benefits of Effective Caching

Reduced Build Times: By reusing the cached layers, Docker can skip rebuilding unchanged layers, significantly reducing the overall build time.
Improved Efficiency: Efficient caching leads to faster CI/CD pipelines, which is crucial for agile development and quick deployment cycles.

Docker Hub Integration in GitHub Actions

Integrating Docker Hub with GitHub Actions is a key step in automating the Docker image build and push process. This section covers the essential steps for secure Docker Hub login and handling secrets within GitHub Actions.

Docker Hub Login

Logging into Docker Hub from GitHub Actions is a crucial step to push the built images to your Docker Hub repository. This is where the docker/login-action@v1 action comes into play.

Importance of Secure Login

Security: Securely logging into Docker Hub ensures that your credentials are protected and your Docker Hub account is safe from unauthorized access.
Automation: Automated login is essential for seamless CI/CD pipelines, enabling the automated pushing of Docker images to Docker Hub without manual intervention.

Implementing Docker Hub Login

- name: Login to Docker Hub
  uses: docker/login-action@v1
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

In this step, the docker/login-action@v1 action is used to log into Docker Hub. The credentials are provided through GitHub secrets to ensure security.

Handling Secrets

GitHub secrets provide a secure way to store and use sensitive information, like Docker Hub credentials, in your GitHub Actions workflows.

What are GitHub Secrets?

Security Feature: Secrets are encrypted environment variables that you can create in any repository or organization in GitHub. They are not exposed in log files or to unauthorized users.
Usage in Workflows: Secrets can be used in GitHub Actions workflows to securely manage sensitive data like API keys, passwords, and Docker Hub credentials. Configuring and Using Secrets
Adding Secrets: Secrets can be added to your GitHub repository under the settings tab. Once added, they can be referenced in your workflow file. Referencing Secrets in Workflows: In the Docker Hub login step, the username and password are referenced as ${{ secrets.DOCKERHUB_USERNAME }} and ${{ secrets.DOCKERHUB_TOKEN }}. This allows the workflow to use these credentials without exposing them.

Benefits of Using Secrets

Enhanced Security: By using secrets, sensitive information is kept secure and is not exposed in your workflow files or logs.
Flexibility: Secrets can be easily updated in the GitHub repository settings without changing the workflow files.

Building and Pushing the Docker Image

The culmination of our GitHub Actions workflow is the building and pushing of the Docker image. This section provides a detailed walkthrough of this process, highlighting the use of docker/build-push-action@v2 and explaining image tagging and multi-architecture support.

Building the Docker Image

Building the Docker image is a critical step in the workflow. The docker/build-push-action@v2 action simplifies this process within GitHub Actions.

Using `docker/build-push-action@v2`

This action enables us to build and push the Docker image to a registry like Docker Hub. It supports advanced features like multi-platform builds and caching.

- name: Build and push
  uses: docker/build-push-action@v2
  with:
    context: .
    file: ./Dockerfile
    push: true
    tags: user/myapp:latest, user/myapp:${{ github.run_number }}
    platforms: linux/amd64,linux/arm64/v8
    cache-from: type=local,src=/tmp/.buildx-cache
    cache-to: type=local,dest=/tmp/.buildx-cache

In this configuration:

context specifies the build context (typically the root of the repository).
file points to the Dockerfile.
push set to true enables the pushing of the image to the registry.
tags defines the tags for the built image.
platforms lists the target architectures.
cache-from and cache-to handle caching to speed up the build process.

Tagging and Multi-Architecture Support

Tagging images correctly and supporting multiple architectures are crucial for a robust Docker deployment.

Tagging Images

Purpose of Tags: Tags are used to specify different versions of your Docker images. It's a best practice to tag your images with meaningful identifiers, like version numbers or environment names.
Tag Syntax in GitHub Actions:

tags: user/myapp:latest, user/myapp:${{ github.run_number }}

Here, we use two tags - latest for the most recent build and a tag with the GitHub run number for specific builds.

Multi-Architecture Support

Supporting multiple architectures ensures that your Docker images can run on various hardware platforms.

Specifying Architectures: In the platforms field of the docker/build-push-action@v2, we specify the target architectures.

platforms: linux/amd64,linux/arm64/v8

Benefits: This approach ensures that the built Docker images are compatible with both AMD64 and ARM64 architectures, broadening the usability of your application.

Conclusion and Best Practices

We've now reached the end of our comprehensive guide on building and pushing multi-architecture Docker images using GitHub Actions. Let's recap the steps we've taken and go over some best practices and troubleshooting tips.

Review of the Process

Our journey through this tutorial involved several key steps:

Introduction to Docker and GitHub Actions: We began by understanding the basics of Docker, GitHub Actions, and the need for multi-architecture builds.
Setting Up the Workflow: We then explored the workflow syntax in GitHub Actions and how to trigger workflows.
Environment Preparation: Setting up QEMU and Docker Buildx were crucial steps for cross-platform Docker builds.
Caching for Efficiency: Implementing caching using actions/cache@v2 improved our build times significantly.
Docker Hub Integration: We securely logged into Docker Hub using GitHub secrets, ensuring a secure pipeline.
Building and Pushing Images: Finally, we used docker/build-push-action@v2 to build and push images, tagging them appropriately and supporting multiple architectures.

Best Practices

Following best practices can significantly enhance the efficiency and security of your Docker builds and GitHub Actions workflows.

Docker Builds

Use Multi-Stage Builds: This helps keep your images small and efficient.
Leverage Caching: Proper caching can drastically reduce build times.
Keep Images Secure: Regularly update and scan your images for vulnerabilities.

GitHub Actions

Keep Workflows Simple: Complex workflows are harder to maintain and debug.
Secure Secrets: Always use GitHub secrets to handle sensitive information.
Document Your Workflows: Clear documentation helps maintain and understand workflows.

Troubleshooting Tips

Here are some common issues and tips for troubleshooting Docker builds and GitHub Actions workflows.

Docker Builds

Build Failures: Check for syntax errors in your Dockerfile. Ensure all necessary files are included in the build context.
Long Build Times: Investigate caching strategies and consider optimizing your Dockerfile for better layer caching.

GitHub Actions

Workflow Errors: Review logs provided by GitHub Actions for specific error messages. Ensure all steps are correctly configured.
Secrets Not Working: Double-check secret names in the repository settings and their references in the workflow file.

With this knowledge, you're now equipped to create efficient, automated Docker workflows using GitHub Actions. Happy coding!

From Cloud to Couch, My Blog's Quirky Journey Home

Agastya Darma — Thu, 16 Nov 2023 04:53:31 +0000

Welcome to my latest digital escapade – a tale that’s part tech, part humor, and entirely real. I’m here to tell you about how my blog, once a mere visitor in the vast cloud, found its way to the cozy confines of my own home. Yes, you read that right. My blog now lives on a Raspberry Pi 4 server, right here under my roof. Let’s dive into this delightful journey of migration, shall we?

The Origin Story

Every great adventure starts with a vision. Mine was built with Docusaurus – a fantastic platform that makes documentation a breeze but also doubles up as a brilliant blog framework. It’s like having a Swiss Army knife, but for blogging. Neat, right?

Now, I must confess, I’m a bit of a neat freak when it comes to my digital life. So, naturally, my blog was dockerized. Think of it like packing your entire house into a single, magical suitcase – ready to move anywhere, anytime. This nifty trick made the migration process smoother than my morning espresso.

A Raspberry Homecoming

Now, let’s talk about the star of our show – the Raspberry Pi 4. This tiny yet mighty device transformed from a hobbyist's plaything into the powerhouse behind my blog. Hosting a blog on a Raspberry Pi? Sounds crazy, right? But that's exactly what I did. In the quiet corner of my home, this little gadget hums with the life of my blog, proving that you don't need a massive server to make a big impact on the digital stage.

Tunnels and Clouds

Navigating the complexities of the internet, especially when hosting a website or blog, requires a secure and reliable connection. This is where Cloudflared's Argo Tunnel comes into play in my setup. It's not just any regular internet connection – it's a fortified, encrypted pathway designed to ensure secure and efficient communication between my Raspberry Pi and the wider internet. Imagine a secret underground tunnel, hidden away from the chaos of surface traffic, providing a safe and speedy route for my data. This setup guarantees that my blog remains accessible and secure, avoiding potential cyber threats and ensuring uninterrupted service to my readers.

The domain of a blog is more than just a web address; it’s an integral part of its identity, its brand. For my blog, www.agas.dev is that digital signature, a unique identifier in the vast sea of the internet. Linking this domain to my Raspberry Pi hosted blog was an essential step in establishing its new home. By routing www.agas.dev through the Cloudflared Argo Tunnel, I’ve created a direct and efficient pathway for traffic to reach my blog. It’s akin to setting up a bespoke postal service, one that ensures prompt and secure delivery of content – my digital letters, if you will – to my audience without any detours or delays.

This journey of migration is not just about moving a blog from one hosting environment to another; it's about reimagining what's possible with technology. It's a blend of the old and the new – the tried and tested Raspberry Pi, a favorite among tech hobbyists, coming together with modern solutions like Cloudflared's Argo Tunnel to create a robust, home-based web hosting environment. This blend of technology demonstrates that with the right tools and a bit of ingenuity, you can create a powerful digital presence without relying on traditional, often expensive, hosting solutions.

In essence, this project is a testament to the power of small-scale, home-based technology solutions in a world that's increasingly moving towards decentralization and personal control over digital assets. Hosting my blog on a Raspberry Pi 4, connected securely to the internet through Cloudflared's Argo Tunnel, and accessible via a personalized domain, embodies a shift in how we approach web hosting and content delivery. It’s a shift towards more personal, customizable, and cost-effective solutions, proving that sometimes, the best way to move forward is by bringing things closer to home.

Docker, but Easier

Handling Docker can be a bit like juggling digital cats. To simplify this, I turned to Portainer. It’s a graphical interface that brings simplicity and clarity to managing Docker containers. With Portainer, I could easily update, modify, and maintain my blog’s backend without diving into the command-line abyss. It’s like having a sleek, user-friendly dashboard for your car, making driving (or in this case, managing a blog) a breeze.

Counting the Costs

Running a blog doesn't have to break the bank, and my setup is a testament to that. By moving to a Raspberry Pi hosted at home, I've slashed hosting costs without sacrificing performance. For a blog with modest traffic like mine, this is a game-changer. It's like discovering a secret recipe that makes your favorite dish not just tastier but also cheaper to cook.

Recoil, A State Management Library For React

Agastya Darma — Mon, 09 Aug 2021 08:30:52 +0000

Biggest Challenge in React application is the management of global state. In large applications, React alone is not sufficient to handle the state complexity which is why some developers use React hooks, Redux and others state management libraries.

Do You Need A State Management Library?

For reasons of compatibility and simplicity, it's best to use React's built-in state management capabilities rather than external global state like Recoil. But as i said before React has certain limitations when it comes to a global state management.

Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.
Context can only store a single value, not an indefinite set of values each with its own consumers.
Both of these make it difficult to code-split the top of the tree (where the state has to live) from the leaves of the tree (where the state is used).

So When Should We Use A State Management Library Like Recoil?

Applying a global state management is not so easy, it is a lot off hard work and it also takes time to implement. So, it is very important for you to know when to implement the state-management.

If your application contains a large number of components and a lot of requests are being sent to the back-end for data retrieval, then it becomes mandatory to implement the state-management, as it will boost the user experience and speed of the application to a great extent. With a global state, you don't have to fetch the same request multiple times as the data will already be "cached" from the first request and can be consumed by other part of your screen.
If you use redundant data throughout the whole app, for example, a list of customers is being used in the invoice creation and sales report generation then there is no need to fetch customers again and again from the database. You could simply just put the data in the global state.

What is it about Recoil.js that’s so appealing?

Recoil feels just like React. The syntax is similar to React and it looks like a part of React API. Other than that, it has many other upsides like it solves the problem of global state management, shared state, derived data, etc. The team at Recoil make sure that the semantics and behavior of Recoil be as Reactish as possible.

The Recoil Concept.

Recoil is an experimental state management library at Facebook, created by Dave McCabe. The reason why i like Recoil better than Redux is because Recoil solves all our complex state management problems but its configuration is surprisingly simple, unlike Redux. And we do not need to write much boilerplate code as we would have by using other state management library like Redux.

Installing Recoil

As Recoil is a state management library for React, you need to make sure that you have React or React Native installed and running before getting started.

npm install recoil
// or
yarn add recoil

Core Concept of Recoil

There are two core concepts of Recoil that you need to understand. This are Atoms and Selectors.

Atoms

Atoms are units of state. They're updateable and subscribable: when an atom is updated, each subscribed component is re-rendered with the new value. They can be created at runtime, too. Atoms can be used in place of React local component state. If the same atom is used from multiple components, all those components share their state.

You can create Atoms with the atom function:

const countState = atom({
  key: 'countState',
  default: 1,
});

Atoms use a unique key for debugging, persistence, and mapping of all atoms. You can't have a duplicate key among the atoms. So because of that you need to make sure they're globally unique. And also like a React component state, they also have a default value.

To read and write an atom from a component, we use a hook called useRecoilState. It's just like React's useState, but now the state can be shared between components:

function CountButton() {
  const [countValue, setCountValue] = useRecoilState(countState);
  return (
    <>
      <h4>Count Value {countValue}</h4>
      <button onClick={() => setCountValue((value) => value + 1)}>
        Click to Increase Count
      </button>
    </>
  );
}

Selectors

A selector is basically a piece of derived state, where ‘derived state’ can be defined as the ‘the output of passing state to a pure function that modifies the given state in some way’. So in short when these upstream atoms or selectors are updated, the selector function will be re-evaluated. Components can subscribe to selectors just like atoms, and will then be re-rendered when the selectors change.

const countLabelOddEventState = selector({
  key: 'countLabelOddEventState',
  get: ({get}) => {
    const count = get(countState);
    if (count % 2 == 0) {
      return `isEven`;
    }
    return `isOdd`;
  },
});

As you can see Selectors also have a unique ID like atoms but not a default value. A selector takes atoms or other selectors as input and when these inputs are updated, the selector function gets re-evaluated.

The get property is the function that is to be computed. It can access the value of atoms and other selectors using the get argument passed to it. Whenever it accesses another atom or selector, a dependency relationship is created such that updating the other atom or selector will cause this one to be recomputed.

Selectors can be read using useRecoilValue(), which takes an atom or selector as an argument and returns the corresponding value. We don't use the useRecoilState() as the countLabelOddEventState selector is not writeable (see the selector API reference for more information on writeable selectors).

Conclusion

Personally i think Recoil is a great library but unless you have some specific problems regarding global state management, you don’t really need it. It's nothing that the developer’s world couldn’t survive without. You can even use Recoil partially in your application, exactly where you need, without having to adopt it for the entire application.

References

Recoil Core Concepts.

Recoil.js — A New State Management Library for React.

React Native Code-Splitting With Repack

Agastya Darma — Sat, 07 Aug 2021 12:10:06 +0000

When you are developing a React Native application you will most likely be writing a lot of JavaScript code that contains dependencies that usually come from external repositories like NPM. The compilation of these many JavaScript files and dependencies will be processed into a single bundle file that can be read by React Native. In React Native this compilation will be done by default by Metro Bundler.

So basically Metro Bundler works by taking your source code, all external library dependencies as well as static assets that you use and converting them, optimizing them, and packaging them into a single bundle that can be run by React Native.

What is Code-Splitting?

Code-Splitting is a technique that allows developers to create multiple bundle files from existing code sources, so the resulting bundle is not just one but consists of many files which are commonly referred to as chunck.

By default, all your input files (source code, dependencies, and assets) are combined into one file. With Code-Splitting, the bundle will be divided into several parts called chunck. The main chunck (also known as the entry chunk) is commonly referred to as the main bundle.

Why Do You Need Re.pack To Code-Splitting?

As explained above, by default React Native will use Metro Bundler to do JavaScript bundling. But unfortunately Metro Bundler cannot perform Code-Splitting technique by default. To be able to perform the Code-Splitting technique, we need a JavaScript bundler other than Metro Bundler.

What is Re.pack?

Re.pack is basically a toolkit that allows you to use Webpack and its Code-Splitting functionality and use them on React Native.

Why Do We Need Code-Splitting in React Native?

Single bundles aren't a bad thing, but as your app grows your bundle size will grow as well. Especially if you use a lot of third-party libraries you need to be very careful about the code that will be included in the application bundle so that you don't accidentally make your bundle so large that it takes a long time for React Native to load your application.

Increasing App Startup Time

If you have performance issues in the application startup area Code-Splitting is a technique worth trying when you have those problems.

Moving code from a single bundle to multiple chunks of chunck if properly configured can make your React Native app to only load the required code snippets and delay loading of other code on startup. This really helps improve the startup performance of your application.

Modular Applications

Apps that expose different functionality or different UI based on user details are examples of apps that would benefit greatly from Code-Splitting.

Let's take an example of an e-learning application like Ruangguru. With Code-Splitting, you will be able to separate student and teacher functionality in separate bundle files, so that the application only loads one of the bundles, this can improve startup performance by loading only code that is relevant to the user's needs.

Two other groups of apps where Code-Splitting plays a big role are super apps (like Gojek) as well as apps with mini app stores (like WeChat/Line). Instead of having multiple apps on the App Store and Google Play, you can combine them into one while streamlining development and simplifying management.

How to Use Re.pack for Code-Splitting in React Native

How to use Re.pack? The first step to using Re.pack is to install the required dependencies:

npm i -D webpack terser-webpack-plugin babel-loader @callstack/repack
# or
yarn add -D webpack terser-webpack-plugin babel-loader @callstack/repack

After that, Create react-native.config.js (if this file is not in your project) and copy the content below:

module.exports = {
  commands: require('@callstack/repack/commands'),
};

Then configure XCode and Gradle to use the webpack-bundle command. By making this change you will replace the default Metro Bundler to Re.pack

XCode: Add export BUNDLE_COMMAND=webpack-bundle to the Bundle React Native code and images phase of Build Phases in your XCode project configuration.

  export NODE_BINARY=node
  export BUNDLE_COMMAND=webpack-bundle
  ../node_modules/react-native/scripts/react-native-xcode.sh

Gradle: Add bundleCommand: "webpack-bundle" into project.ext.react in android/app/build.gradle file, so it looks similar to:

  project.ext.react = [
      enableHermes: false,  // clean and rebuild if changing
      bundleCommand: "webpack-bundle",
      bundleInDebug: false
  ]

All configurations have been completed. Now you can use repack in your React Native application.

To run the development server you can use the command

npx react-native webpack-start

What are the disadvantages of Repack compared to Facebook Metro Bundler ?

Of course there are some drawbacks when we use Code-Splitting with Re.pack instead of Metro Bundler. One of the biggest drawbacks is that we can't use Codepush anymore to do Hot Push code in Production Env.

Besides that at the time this article was written if you use Hermes with Re.pack then it can only convert Main Bundle to Hermes Bytecode, chunck files outside of Main Bundle will not be transformed into Hermes Bytecode.

Forem: Agastya Darma

Middle Management Is Hard

The Many Pressures Facing Middle Management

1. Top-Down Pressure:

2. Bottom-Up Frustrations:

3. Side-to-Side Politics:

The Emotional Labor Involved

The Isolation of Middle Management

What Can We Do to Improve Middle Management?

1. Bring Middle Managers into Strategic Conversations Early

2. Recognize and Reward the Emotional Labor of Middle Management

Conclusion

Recommended Reading Materials

GitHub Actions for Easy ARM64 and AMD64 Docker Image Builds

Overview of Docker and GitHub Actions

The Importance of Multi-Architecture Builds

Prerequisites

Understanding the Dockerfile

Key Components of a Dockerfile

Understanding GitHub Actions

What are GitHub Actions?

CI/CD with GitHub Actions

Workflow Syntax Explanation

Understanding the workflow_dispatch Trigger

Preparing for Docker Build

What is QEMU?

Role of QEMU in Docker Builds

Setting Up QEMU in GitHub Actions

Docker Buildx Setup

Understanding Docker Buildx

Setting Up Docker Buildx in GitHub Actions

Caching for Efficiency in Docker Builds

Caching Docker Layers

How Caching Works in Docker

Implementing Caching with actions/cache@v2

Cache Keys and Paths

Defining Cache Paths

Cache Keys

Benefits of Effective Caching

Docker Hub Integration in GitHub Actions

Docker Hub Login

Importance of Secure Login

Implementing Docker Hub Login

Handling Secrets

What are GitHub Secrets?

Benefits of Using Secrets

Building and Pushing the Docker Image

Building the Docker Image

Using docker/build-push-action@v2

Tagging and Multi-Architecture Support

Tagging Images

Multi-Architecture Support

Conclusion and Best Practices

Review of the Process

Best Practices

Docker Builds

GitHub Actions

Troubleshooting Tips

Docker Builds

GitHub Actions

From Cloud to Couch, My Blog's Quirky Journey Home

The Origin Story

A Raspberry Homecoming

Tunnels and Clouds

Docker, but Easier

Counting the Costs

Recoil, A State Management Library For React

Do You Need A State Management Library?

So When Should We Use A State Management Library Like Recoil?

What is it about Recoil.js that’s so appealing?

The Recoil Concept.

Installing Recoil

Core Concept of Recoil

Atoms

Selectors

Conclusion

References

React Native Code-Splitting With Repack

What is Code-Splitting?

Why Do You Need Re.pack To Code-Splitting?

Understanding the `workflow_dispatch` Trigger

Implementing Caching with `actions/cache@v2`

Using `docker/build-push-action@v2`