DEV Community: Kamau Wanyee

TenancyForLaravel FileSystem Bootstrapper asset Gotcha

Kamau Wanyee — Tue, 24 May 2022 20:09:14 +0000

TLDR; If you are using the FileSystemBootstrapper on the archtechx/tenancy package and also the Laravel-Vite package, update your tenancy config (tenancy.filesystem.asset_helper_tenancy) to false. Otherwise your generated script/style tags after building assets will be returning a tenant-scoped asset URL.

Here is the context of the problem I was facing:

I am building a multi-tenant SaaS application using this tenancy package from Tenacy for Laravel. It has a concept of tenancy bootstrappers that modifies relevant framework defaults to make the application tenant aware. The FileSystem Bootstrapper makes the Laravel asset() helper method return tenant specific assets through a TenantAssetController.
I also replaced Laravel Mix with Vite and I'm using this Laravel Vite package to make the integration easier. The package provides @vite directive to output all the necessary asset tags in your blade file. The underlying methods use the asset() helper method from the framework. Therefore, any generated asset URL is tenant-scope if I am under a tenant aware route. I am using VueJS for templating so my page ends up not being rendered correctly.

The solution is to update a tenancy config (tenancy.filesystem.asset_tenancy_helper) to false. The asset() helper revert to default. The tenancy package still provides tenant_asset() helper method for tenant specific assets.

I hope this helps someone out there facing the same issue and save you time.

A reflection point in my career

Kamau Wanyee — Wed, 18 May 2022 16:17:12 +0000

This is the first time I’ve worked full-time for a whole year and I thought to make it a reflection point in my career. I always thought that I will land a job at a company with established best practices on their development processes. However, so far I have not had that luck but that means there is a lot I have learnt along the way.

Be the change that you want to see

There is no reason that the desired company culture shouldn’t start with you. Start writing the tests and setting up build tools on your assigned projects. Be visible and vocal about what you are doing and others will pick up on it. You get to sell your designed change by demonstrating the benefits first hand.

Change requires support from management

As much as you get the buy-in from your colleagues, if management does not see and acknowledge the value in your proposal then your efforts will be moot. Something being best practice in the industry is not enough reason to adopt it. Especially when what you are proposing does not have a “direct” business value, you might get some resistance. You need to back up your proposal with research to get the sign-off.

Technical debt should be part of team deliverables

“We will fix it better when things cool down”. One of the biggest lies we tell ourselves on projects. Then the codebase has some weird patch that can’t be touched without breaking the build and no one knows why. Take time to clean up that patchy code so that it does not becomes tomorrow’s problem.

Incremental upgrades are better than huge batch upgrades. Don’t wait until the tools you use are reaching their End of Life deadline to upgrade them. Using stable latest versions of a framework or libraries can also lead to better developer happiness which translates to better productivity.

Contextual internal documentation is important

A lot of contextual information about a project/codebase can be lost if it’s only kept in the mind. Document the not-so-obvious and context specific content. This creates a reference point for future and also on-boarding new people. It’s also critical to document this stuff when it’s fresh in the mind otherwise it is lost when it becomes obvious.

Documentation makes sense when it is visible and utilized

Sharing links to the documentation makes it visible and people are more likely to utilize the knowledge hub. People get to know where to go if it’s an already solved problem. This also applies to customer support interactions for your products. Sharing a link to the help section that solves their problem, let’s them know where to go when facing the same issue next time.

Automation is critical for smaller teams

The fewer decisions you have to make the more energy you have for complex problems. Automating your tasks where you can clears up time and mental energy which can be utilized for other important things. Other people can utilize your automation or get inspiration for their workflows as well so it benefits the whole team to move efficiently.

Source diving is a treasure trove of knowledge

Source diving frameworks and packages is a treasure trove of experience and learning. You get to learn to solve problems you did not know even existed. You get different perspectives on solving your current problems.

Be visible and public about your contributions

Most of the time the decision makers only care about the end result. Your work or contributions might not always be visible or immediately appreciated. Try as much as possible to publicly mention your contributions. Others get to appreciate the effort that went into getting the expected result. The decision makers also get to notice you. Don’t down play your achievements because they have become normal to you.

Learn how to say No

There are situations when you are swamped and another request would not be feasible. Or sometimes a client or management might come with an improbable or obscene feature request. Strategically saying no helps you stay sane and also manage expectations on project deadlines and deliverables. Saying yes to everything is a sure path to burn out. Down the line there is too much on your plate which affects your performance.

I tried pair programming

Kamau Wanyee — Wed, 31 Mar 2021 15:18:26 +0000

I recently completed my undergrad and had some free time on my hands as I applied for jobs. I was a little bit low on motivation to work on side projects or tinker with new technology. As a substitute, I got into watching Twitch coding streams and was intrigued by the concept of mob programming with the chat. I felt like that was something I would like to try one day, baby steps though. I reached out to my friends to see if anyone was interested in hopping on a call to pair program on a project they were working on. Luckily I found someone willing to experiment with me. They were working on a tourist destination Flutter project. The first session went well enough that we had another.

My friend has a blog series on the process of building the "Places to Visit" Flutter application. If you are interested, you can check it out here.

Here are a few takeaways I got from my experience pair programming:

Concepts are transferrable among languages

First of all, I know nothing about Dart, the programming language used in Flutter. However, that did not put me at a disadvantage to derail my friend's productivity. We did a quick overview of the project he was working on. I got a quick crash course on the structure of a Flutter application. After that, we were off to the races working on the next feature in the application.

Due to syntax similarities with other languages, I was able to infer what the majority of the code was responsible for based on the context and usage. I am comfortable with using higher-order functions when dealing with array manipulations. A quick search if there are map and filter functions in Dart and we were able to refactor code for better readability. I was happy to have some input even though I was in a foreign space. It should not be a surprise because languages are just tools we used to solve problems. Several principles guide the problem-solving techniques, the languages simply offer a representation of those techniques.

It's a win-win situation

Pair programming is a collaborative exercise, so you get to learn a lot from each other. People think and approach problems quite differently. Both parties need to be open to providing feedback along the way. The extra pair of eyes is really helpful when they catch things you miss along the way. This definitely reduced the debugging time when things went wrong. You also realize someone's thought process informs the way they code. Understanding how they think helps you phrase things in a way they will understand faster. This makes communication way easier. You learn a lot from each other.

Your code is not your identity

The collaborative nature of pair programming means there will be a lot of back and forth feedback. Essentially your code may be under scrutiny. You have to remember to not get attached to your code and be defensive about it. Acknowledge good suggestions and have an open mind about the criticism. You can provide the reasoning behind your decisions to validate your method. You have to remember that it is not an argument on who is right or wrong. You are not your code, feedback is not attacking you as a person.

Readable code makes collaboration easier

What is considered readable code is sometimes nuanced but there are definitely objective pointers on what is considered readable. The less the mental overhead for me to read and understand the code, the better. So definitely bespoke long one-liners are not good for readability. They may be good for codewars katas to flex your skills but not in a codebase meant to be consumed by others.

I know naming things is one of the hardest things in programming, but try and make your functions and variables informative on what they are responsible for. It makes things a whole lot easier for others to understand the codebase. Future you will also benefit largely from naming things contextually.

Conclusion

Tools have come a long way that it has made remote pair programming quite effortless. It can be easy as hopping on a video call and sharing your screen. Tools like VsCode, like their share extension, have extra features that make code collaboration better. I highly encourage people to try out pairing more often. For teams, it can help form bonds and synergy that helps with collaboration and productivity. Remember to have fun while at it. Share stories and crack jokes, it helps break the monotony of writing code.

Deploying Laravel applications to a shared server using GitHub Actions

Kamau Wanyee — Wed, 23 Sep 2020 05:02:50 +0000

Introduction

I recently worked on a project where the staging server was on a shared hosting plan with users having very limited privileges. At the time I would push updates using git-FTP, a tool that uses git to upload only changes to the FTP server. Without automation, the git-FTP initial push process would take me several hours. I decided to try out GitHub Actions to offload the workload from my machine.

This post covers my workflow file which uses a combination of SSH and git-FTP for the staging deployment job. I am assuming that you have some knowledge of GitHub Actions.

Before we get to the workflow

The workflow connects to the server through SSH to run commands and files are transferred through FTP. On your GitHub account, you need to have saved secrets for these credentials:

FTP user credentials.
SSH private key.

There were some issues with installing composer on the staging server and I did not want to track the dependencies on git, so before deployment, I download the dependencies and create an archive.

Also note that this post covers the deploy job after the initial setup of git-FTP that creates a log file on the staging server.

The Staging Workflow

The 3 jobs on the workflow file:

setup — cleans up the vendor directory on the server.

setup:
    runs-on: ubuntu-latest
    steps:
      - name: Remove vendor directory
        uses: fifsky/ssh-action@master
        with:
          command: |
            cd www/site_directory/
            [ -d ./vendor ] && rm -rf ./vendor
          host: https://staging-server.com
          user: system_user
          key: ${{ secrets.SSH_PRIVATE_KEY }}

deploy — Download dependencies and deploy the site.

deploy:
    name: Deploy to the staging server
    runs-on: ubuntu-latest
    needs: setup
    steps:
      - uses: actions/checkout@v2.1.0
        with:
          fetch-depth: 2

      - name: Install Composer Dependencies
        run: composer install --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist

      - name: Create zipped vendor directory
        uses: montudor/action-zip@v0.1.0
        with:
          args: zip -qq -r ./vendor.zip ./vendor

      - name: FTP-Deploy-Action
        uses: SamKirkland/FTP-Deploy-Action@3.1.1
        with:
          ftp-server: ftp://ADDRESS_HERE
          ftp-username: FTP_USER
          ftp-password: ${{ secrets.FTP_PASSWORD }}

Since [vendor.zip](http://vendor.zip) isn't tracked using git, it is added to the .git-ftp-include file to be always pushed. Creating an archive lets the transfer to be a single file. This actually reduced my workflow run from minutes to a few seconds, which I thought was a pretty cool trick.

post-deploy — Clean up [vendor.zip](http://vendor.zip) and run several artisan commands.

post-deploy:
    runs-on: ubuntu-latest
    needs: deploy
    steps:
      - name: Run migrations and seeders, clear cache for views, config and routes
        uses: fifsky/ssh-action@master
        with:
          command: |
            cd www/site_dir/
            unzip -qq ./vendor.zip
            rm -f vendor.zip
            php artisan migrate:fresh --seed
            php artisan config:clear
            php artisan view:clear
            php artisan route:cache
          host: https://SERVER_ADDRESS
          user: USER
          key: ${{ secrets.USER_PRIVATE_KEY }}

Running the Workflow

In the project I set the workflow to run on push to a staging branch which is only gets updates from master pull requests. Here is the whole workflow file.

name: Pushing to the staging server

on:
  push:
    branches:
      - staging
jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - name: Remove vendor directory
        uses: fifsky/ssh-action@master
        with:
          command: |
            cd www/site_dir/
            [ -d ./vendor ] && rm -rf ./vendor
          host: https://ADDRESS_HERE
          user: USER
          key: ${{ secrets.USER_PRIVATE_KEY }}

  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    needs: setup
    steps:
      - uses: actions/checkout@v2.1.0
        with:
          fetch-depth: 2

      - name: Install Composer Dependencies
        run: composer install --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist

      - name: Create zipped vendor directory
        uses: montudor/action-zip@v0.1.0
        with:
          args: zip -qq -r ./vendor.zip ./vendor

      - name: FTP-Deploy-Action
        uses: SamKirkland/FTP-Deploy-Action@3.1.1
        with:
          ftp-server: ftp://ADDRESS_HERE/
          ftp-username: FTP_USER
          ftp-password: ${{ secrets.FTP_PASSWORD }}

  post-deploy:
    runs-on: ubuntu-latest
    needs: deploy
    steps:
      - name: Run migrations and seeders, clear cache for views, config and routes
        uses: fifsky/ssh-action@master
        with:
          command: |
            cd www/site_dir/
            unzip -qq ./vendor.zip
            rm -f vendor.zip
            php artisan migrate:fresh --seed
            php artisan config:clear
            php artisan view:clear
            php artisan route:cache
          host: https://SERVER_ADDRESS
          user: USER
          key: ${{ secrets.USER_PRIVATE_KEY }}

Conclusion

I would not recommend using this workflow in its current state for deployments to a production server since users might get unintended interruptions when you delete the vendor directory in the setup job. In the scenario where you have composer installed on your server, you would get rid of the setup job and the dependency installation step in the deployment job. It is also a good idea to set the application in maintenance mode when you are updating the composer dependencies or making a deployment update.