#Software Engineering

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.

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.

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.