Blog

I experienced some annoying issues while running integration tests in a Laravel app. The official MySQL docker image will create a user and a database for you which is very convenient, but that user does not have permission to create new databases. I configure my applications to use a separate database for testing, usually with a _testing suffix and so just hit a brick wall. The solution was to mount an entrypoint script, basically, some SQL statements I want to execute when the container is created. The script will create all of the necessary databases I need.

In today's post, I discuss enhancing my blog's tag support, moving from a simple comma-separated list to a more powerful and dynamic queryable system using the Ruby gem 'acts-as-taggable-on'. I illustrate the process of installing and migrating the gem with MySQL. I then detail the code for tagging in the Blog model, updating blog forms and controllers. It's crucial to migrate existing tags to the new system, which I did using Maintenance Tasks, including tips for covering edge cases in the tests for the task. Updating existing tests for the blog model to incorporate the new taggable system was the final step. Future considerations include creating a Stimulus Controller for auto-suggested tags and extending this functionality to the Project model.

In my quest to effectively test Laravel queues and jobs, I've had to navigate through several challenges. Initially, I created a one-off controller action to replay jobs, but the solution was a tad clunky. Next, I attempted to use Laravel's Tinker to interact with my SQLite database, but encountered unexpected I/O errors. Despite a deep dive into the issue and experimenting with different PHP versions, the SQLite errors persisted. Eventually, I decided to switch to MySQL and Docker, which turned out to be an effective solution, finally enabling me to query my database successfully. One key learning from this experience: when using Tinker to dispatch jobs, the appropriate method is to use Bus::dispatch or Queue::push, due to their dependency on garbage collection. All in all, while the journey was filled with obstacles, I'm thrilled to share these insights, with Tinker proving to be an excellent tool for Laravel developers.

In this blog post, I share a straightforward way to manage your MacOS workstation using Ansible, based on Jeff Geerling's collection of Ansible roles and collections. After installing the necessary dependencies, such as the Ansible Galaxy mac collection and dotfiles role, you can define the dotfiles you want to symlink, and where to get them, and confogure which packages to install via homebrew. This approach allows you to set up your workstation as code, achieving about 80% of the setup process, with the remaining requiring some manual configuration.

The conference was a real blast, packed with awesome talks, some seriously geeky stuff, and plenty of chances to mingle with vendors, developer relations teams, and other attendees. I picked up some gems along the way, like Paul Tevis dropping knowledge bombs on building a high-trust culture, the ongoing saga of secrets management, and how DevOps is now just part of doing business. I had some great discussions with fellow attendees about the importance of pushing quality checks to the left, and engaged with talks about the value of Open Source projects and their QA game. Oh, and let's not forget diving deep into potential security headaches like typo-squatting in AI and what that could mean for us. These events aren't just about filling our brains with new info; they're about forging real connections beyond our screens.

I've observed a common pattern among junior developers regarding environment-specific configuration. Many junior developers misunderstand the need for a single environment-aware configuration and end up creating separate fields for development and production environments in their apps. They often misconstrue the need to store keys for different environments as a requirement to create two distinct fields in the admin, one for each environment. This leads to unnecessary duplication of logic to handle these different keys based on the environment.

Jumpstart Pro is a Ruby on Rails SaaS template that streamlines the creation of business-ready web applications, eliminating the need for repetitive coding and configurations. Despite its numerous advantages, maintaining the software can become complex or tedious as applications grow - primarily due to merge conflicts during updates. I share a few strategies I employ to simplify this process, including removing files from the git index that don't require updates, regenerating files like yarn.lock and Gemfile.lock, and refraining from altering core Jumpstart files. I also use a script post-merging to automate the regeneration of these files. These methods have significantly eased the application of Jumpstart Pro updates for me, and I believe they could be beneficial to other developers as well.

As someone working with WordPress development, I've found that the development life-cycle could use some improvements to make the developer experience much better. One of the things missing from the out-of-the-box experience of developing with WordPress is a way to seed a database with dummy or test content, which is extremely useful for onboarding new developers to a project, running automated tests, and for ensuring proper practices by _not_ using production data.

When you click a link to return to a page, or use your browsers back button to return to a page Turbo will render a cached preview of the page. It will then fetch an updated version of the page.

DevOps is a tried and true framework for creating software. It's not just about automating pipelines or assigning operations work to developers; it's a mental model built on key principles aimed at improving work processes. These principles, known as the "Three Ways of DevOps" from "The DevOps Handbook," include the Principle of Flow, the Principle of Feedback, and the Principle of Continuous Improvement. To sum it up, DevOps is a transformative mindset that, when properly implemented, can significantly enhance a company's ability to deliver high-quality software more efficiently. As a reminder, always think of the three F's: Flow, Feedback, and Fine-tuning.

In this article, I explore how Docker Compose can simplify software development, using Ruby on Rails as an example project. Docker Compose simplifies the setup and teardown of a project, reduces inconsistencies in development environments, and makes it easier to add ancillary services such as database and caching servers. I demonstrate this by creating a new Rails project, setting up a docker-compose.yml file, and adding services like PostgreSQL and Redis. Once done, I run and develop the new application in Docker. This process eliminates the need to juggle multiple versions of tools and services on a workstation, minimizes bugs caused by different development environments, and conserves resources. I also share insights on how to clone the example repo, create a new project, add the first service to Docker Compose, and develop the application in Docker.

Let's explore a process for running Ruby on Rails in Docker with Nginx to handle serving static assets.

I spent some time over the weekend getting familiar with RSpec. Gonna brain dump (with just a little bit of structure) the process and what I did and learned. To start I set up in a new rails project and kinda tweaked it into a place where I can be productive.

Path filtering in CircleCI to reduce build times, overall cost, and to better support monorepo strategies.

I was asked recently if I could explain the difference between length, size, and count for ActiveRecord models in Ruby on Rails. Unfortunately I had no answer. But I wanted to really understand so I dug into the API docs.

A flexible terraform module for creating an AWS ACM with a variable number of additional SANs. GitHub Repo

Here is a directory structure that I am using for Terraform that I think works pretty well. The quick and dirty of it is to think of your configurations in terms of a organizational and systems hierarchy, and to design your plans to support that hierarchy. Each tier depends on and builds upon the previous tier.

Ruby doesn't have the concept of an interface. Unlike say, PHP. In PHP you can specify that a class has to act like or implement specific methods. If your class fails to honor the contract of that interface and does not implement the methods of the interface, you get an error during runtime. Ruby does not have this. But we can ensure our code honors the contract of an interface by writing unit tests for our classes.

Maintain a single .gitconfig between different operating systems by using proxy scripts for git diff and git merge tools.