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.
Cached builds in development
Historically, in development every build file would be rebuilt on every request even if the source files did not change. While this works OK if you have a few build targets, it can get pretty slow if you have many build targets, big build targets or use a pre-processor like sass. As of 0.
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.
The events system has become an integral part of CakePHP since its introduction in 2.1. When originally introduced, we needed to make a number of compromises in the implementation to facilitate compatibility with the code it was replacing. For 3.0, I wanted to revisit the event subsystem and try to make things more efficient and streamline the API a bit.
I try to keep fairly busy. Between work, being a dad, and working on existing open source projects, I found time to work on two new ones.
Profiling is a very interesting topic for me. I love spending time sifting through results trying to find ways to make code run faster or use less memory. XHProf is a C-extension created by Facebook.
I recently moved hosting for this blog and my wife’s site to a shiny new linode. I did this because I wanted to have control over the versions of PHP, and other server software I ran. I had some issues with email blacklists at my previous host. I chose linode as I’ve heard nothing but good things from friends and my operations folks at work recommended them.
I really like how composer simplifies dependency management & installation. It can make applications more portable, and simpler to deploy when compared to the pear installer. Another really nice feature of composer is that you can easily install any pear package, making it perfect for installing CakePHP. While installation was simple, some extra work was required to get things up and running smoothly.
A while back I posted on twitter that I had figured out how to use xdebug & vim and promised to do a blog post on how I got it all working. This is that blog post. Before we can get started using Vim to remote debug PHP code, we’ll need to do a few things.
Making sure your freshly released CakePHP plugin still passes all of its tests can be a bit of a time sink. Setting up Jenkins for small project can be a big job. After I setup Jenkins once or twice, I personally longed for a simple way to get continuous integration with not much work.
Many of the web applications I build have to talk to other webservices. Sometimes those services are internal API servers, sometimes they are external. In both situations, I want a simple, easy to use client library.
At work we’ve been using selenium webdriver to enable automated browser testing as part of our regression suite. One of the most difficult parts we’ve had is maintaining DOM synchronization.