The front-end tools landscape is always evolving and changing. I’ve been aware of Tailwind for a few years, but haven’t had the chance to give it a try. Kevin Pfeifer from the CakePHP team has been using tailwind on a few projects and highlighted it as a CSS toolkit that would work well with CakePHP applications.
This Easter I had some time to dedicate to working through the rustling exercises. I still consider myself a novice rust developer. I frequently don’t know rust idioms, and spend a lot of time struggling to get an idea working at the fidelity of a prototype. Once I have something working, I’m able to revise and refine it incrementally, but getting the initial idea out is tough.
A few years back I made a post on how I work with PHP + SQLServer. In the intervening years, the code samples in that post have aged like milk and no longer work.
I’m working on an infrastructure application that provides a GRPC API to its clients. This will be a high throughput system, so we are building it in Rust using tonic and tokio to build the gRPC API. I wanted to implement request authentication for this system so that the service was resilient to Server-Side-Request-Forgery, and unauthenticated requests.
Recently, I’ve been working on a system that needs to run tasks scheduled by either web requests, or other tasks. These tasks are trusted but sometimes problematic code. While developers generally write good code, we all make mistakes and the occasional slow job that can run for multiple hours gets written. These slow tasks can create problems if the volume of them goes up as they can consume all available resources.
I recently had to do some maintenance work on an old application hosted on the CakePHP server. The CakePHP project has 20 or so sites and applications deployed in dokku. Dokku allows us to build a platform-as-a-service for our sites that operates on a single server. Dokku encourages using heroku-style ‘buildpacks’ to deploy applications.
I wanted to share a new CakePHP plugin that provides feature flagging. In a Saas environment, I’ve been a long time advocate for using feature flags to release changes instead of deploys. Feature flags let you better manage release risk by allowing you deliver code with new features disabled.
During the development of CakePHP, we also wanted to update migrations to be compatible. However, we had stumbled into a tedious dependency graph. Currently phinx
relies on cakephp/database
. While cakephp/migrations
depends on phinx
. In order to do a major release on cakephp/migrations
(to provide CakePHP 5.