Stickler CI users have expressed that automatically enabling default linters can create a flood unwanted comments in pull requests, which is overwhelming and noisy. In response to these issues, we have changed the process of connecting a repository to Stickler CI.
Integration testing with external webservices, has historically been an uncomforable process in PHP for me. It frequently involves complicated mocking that was fragile and hard to maintain. I’ve long wished for a PHP library that was as simple to use as HTTPretty is in Python.
Many people are surprised when they find out I use VIM as my primary editor. While vim seems like a ‘basic’ editor, it can have IDE like features added through its massive plugin community. I recently upgraded how I do fuzzy file navigation and find in project, and wanted to share how you can get blazing fast search in vim.
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.
I recently finished upgrading this site to CakePHP 3.0.0-dev from 2.5.5. I thought I’d share my experiences, as they might be helpful to other people attempting to update a CakePHP 2.x application to 3.0.
In terms of scale & size, this site is pretty small and simple. It has a mere 12 tables, and ~5000 lines of code including HTML, and uses 3 plugins.
Earlier today, I packaged up AssetCompress 0.17. This release has a few noteworthy features.
A few weeks back during CakeFest 2014, I had the opportunity to hunker down and get DebugKit upgraded to CakePHP 3.0. While it was less of an upgrade and more of a re-design and re-write, I think the end results justify the drastic approach I took. First, a few of the problems I was trying to solve in the new version:
1. It is hard to make DebugKit look great as it lives on the same page as your app.
There will be a number of backwards compatibility (BC) breaks in the CakePHP 3.0.0 release. I thought it might be helpful to go over some of the reasons breaks in compatibility have been made. Each time we’ve had to break compatibility with 2.x we’ve done so because the existing behaviour fell into a few categories of problems. I’ll go over a few of the bigger categories in detail.
I recently read write code every day by John Resig. I’ve been trying to follow a similar set of ideas for a while now. My rules were less restrictive than John’s were.
If you’ve ever built a web application that wanted access to the visitor’s camera you know what a painful experience that can be. If used to involve flash or silverlight plugins or clunky java. Thankfully, browsers have started providing new API’s which are collectively referred to as WebRTC or Web Real Time Chat.
PHP5.5 has support for generators which are a powerful language feature available in other languages like Ruby and Python. While generators in PHP are very much like their Python counterparts, I wanted to give them a spin and try a few simple but useful examples of generators in action.
I recently had the opportunity to speak at PHP Conference Argentina . I’d like to thank Mariano and the other organizers for having me at the event. It was a fantastic opportunity for me to visit Buenos Aires, connect with some friends old and new, and give a new talk about my experiences working on CakePHP.
In a previous post, I outlined some changes that would be coming for configuration in CakePHP 3.0. I’ve recently been thinking a great deal about configuration as well as building some prototype applications. I’ve come to the conclusion that configuration needed to change. Coupling all the classes to Configure
while convenient and simple, had a big drawback.