I’d like to introduce a project I’ve been working on over the past few months. Stickler-CI helps automate the tedious process of ensuring coding standards are followed during pull requests. Like many teams, FreshBooks uses pull requests as a way to solicit feedback from other developers, ensure consistent coding practices and catch bugs before they can cause real problems.

In my daily work, I end up having to ssh into a variety of hosts. Keeping track of which terminal is on which host can become challenging when I have 3 or 4 terminals all at a mysql prompt, or tailing log files. A co-worker of mine came up with a pretty clever solution that I wanted to share. The clever solution involves some bash, and Applescript (as we’re working off of OSX).

I’m excited to announce the availability of a PSR7 Bridge plugin for CakePHP. This plugin lets you bridge PSR7 Middleware with CakePHP 3.3+ applications.

While I’m a big fan of dependency injection, I find dependency injection containers less alluring. I’ve found that liberal usage of containers can make application code harder to follow, and often the container definitions go untested, creating a spawning pool for bugs.

I’m always looking for new challenges. With my background mostly being in web development, I have little to no experience in low-level languages. In the past I’ve tinkered with C, and go-lang. This summer, I decided to try and learn Rust. Rust aims to be a very safe and performant systems-level language.

For a number of years, I’ve developed the AssetCompress CakePHP plugin. Simultaneously, I’ve maintained similar code at FreshBooks.

With CakePHP 3.0 out the door, I thought it would be good to reflect on the project. CakePHP 3.0 is the longest and largest open source project milestone I’ve ever participated in. At FreshBooks we do retrospectives on large projects as a way to see what went well, and what could have gone better. The goal is to discover things we should keep doing, and what to improve the next time around.

One approach to scaling out a database for a multi-tenant application is to horizontally shard or partition the data by customer. This often takes the form of having multiple identical copies of an application’s schema in each shard. For example customer A’s data would be in shard 1, while customer C’s data would be in shard 2.