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.

In the rapidly evolving landscape of technology, the fusion of AI with frontend development heralds a transformative era. With GPT-4's groundbreaking capabilities, the process of creating websites is poised for a revolutionary shift. Imagine this: you snap a picture of a design, and GPT-4 translates it into functional code. This vision is not just a fantasy; it's swiftly becoming a reality.

The Role of Frontend Engineers in the AI Era​

The integration of AI into the realm of frontend development, especially with the advent of technologies like GPT-4, is reshaping the landscape of the field. This change prompts a crucial inquiry: what will be the role of frontend engineers in the next decade? It's easy to jump to conclusions and view the rise of AI as a threat to traditional roles. However, a more nuanced perspective reveals that this is not about the end of frontend engineering, but rather an evolution. As AI takes over more routine, templated tasks, frontend engineers are presented with the opportunity to shift their focus. Their role will likely transform, emphasizing more on creative problem-solving, strategic planning, and complex task management that AI cannot easily replicate.

Once upon a time, in the land of smartphones and gadgets, I was a loyal subject of the Kingdom of Android, reveling in its open plains and diverse landscapes. But as my wallet grew a bit thicker (thanks to some good fortune and maybe skipping a few fancy coffees), I crossed the border into the sleek dominion of Apple. Here, I discovered a world where everything 'just works' - often with a price tag that makes you think it should also cook dinner and do the laundry! Despite the premium cost, I was hooked on the harmony and simplicity Apple products offered, a stark contrast to my former Android allegiance.

The real game-changer, however, was my encounter with AirPlay 2. This feature epitomizes why I've become enamored with Apple's offerings. I have an array of speakers in my home, including multiple HomePods and the Samsung Q700A, all AirPlay-enabled. AirPlay 2's multi-speaker functionality has transformed my home into a symphony of sound. The ease with which I can fill every corner of my house with music is nothing short of enchanting. It's not just the technology itself; it's how it enhances the atmosphere of my home, making it more welcoming and lively.

But there's more magic in the mix, especially with the latest iOS 17 features. When friends visit, they can effortlessly add tracks to the speaker's queue, enriching our gatherings with their musical tastes. This seamless integration and shared control are what make AirPlay 2 so special to me. It's not just a feature; it's an experience, a testament to the thoughtfulness Apple puts into creating an ecosystem that's not only functional but also brings people together. This is why I've fallen deeply in love with the Apple ecosystem – it's not just technology; it's technology that connects, entertains, and simplifies life in the most delightful ways.

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

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.

The Navigation router is a groundbreaking alternative to the popular React Navigation library, offering a revolutionary approach to scene-based navigation for both React and React Native. With its focus on scene-based navigation, this router empowers developers to take control of their app's UI design, providing the flexibility to build their UI in any way they want.

One of the most notable features of the Navigation router is its seamless integration with React and React Native. Developers no longer need to worry about using different routing libraries for web and mobile development, which streamlines the development process and saves time.

Additionally, the Navigation router provides a seamless user experience. The navigation is 100% native on Android and iOS, ensuring that users feel comfortable and familiar with the navigation elements. On the other hand, developers using React can have whatever URLs they want, allowing them to build their UI as they see fit.

This is the story of why we chose React Native and how we overcame the technical challenges we encountered along the road.

BrainAcademy build with React Native running on our existing native app.

Early last year, a small group of developers at Ruangguru began studying the feasibility of implementing React Native. React Native allows you to create iOS and Android apps in JavaScript using the declarative programming language of React. This leads in more concise, easier-to-understand code, faster iteration without a build cycle, and easy code sharing between platforms. You can ship faster and focus on the things that count, making your app look and feel fantastic.

Since its initial release, React Native has come a long way. It is being used not only in Facebook and Instagram, but also in a wide range of other businesses, from Fortune 500 corporations to hot new startups.

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.

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.