Recently I was creating a new table and using the timestamps helper in the migration. I noticed something that seemed wrong, so I dug a little deeper and learned something new about Laravel and MySQL.
Many years ago, when I moved my blog from WordPress to Hugo, I was very pleased to find Disqus as a way to still have comments on a statically generated site. Today, however, I have completely removed Disqus from this site.
For me, one of the main reasons I write tests is to have confidence that my code is working as expected and to catch myself if (or should I say when?) I break something in the future. I often think of testing the happy path and the failure path, but I’ll share some additional things I like to test in between that further boost my test confidence.
Laravel’s form requests really help reduce the amount of code in your controllers, especially around validation. Another convenience method they offer is authorization. I recently came across a small tip which isn’t explicitly stated in the docs and thought I’d share it.
Let’s say you have a form with two groups of related, but mutually exclusive, fields. When you POST and store a new record, no problem, only the right fields are sent in. But what do you do when that record is updated? How can you cleanly handle this?
Laravel validation supports “dot notation” to let you validate arrays in a request. But what if your field name contains a literal dot?
Google Analytics is free and has every imaginable feature you might ever want. So why would I switch to paying for Fathom Analytics?
Today I realized something about myself, I actually really enjoy working in legacy applications. This may seem odd. It’s common to hear complaints about “how bad this old code is”, so why would I enjoy working in a difficult environment? First, it would be useful for me to define what makes an application a legacy application. I realize this may not be a universal definition for everyone, but here are the core elements I think of that make an application qualify as “legacy”:
Randomness can serve a useful purpose in factories, seeders, and tests. There are times it can cause issues though. Here are some rules I think about when introducing randomness into a test.
Is git rebase a command to be avoided at all cost? I say no. Here’s one use case where I reach for rebase instead of merge.