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.
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.
For 3.0 the team and I are re-visiting how we’ll recommend installing CakePHP, and as always I wanted to try to provide context on what my thoughts are, and get some feedback on the plans.
Background & context
CakePHP is currently availiable in a few different ways. Generally people either download zip files, or clone the repository. Both of these methods provide a quick easy way to get started.
Early work has started for CakePHP 3.0, and I’ve started re-visiting how CakePHP handles configuration and bootstrapping. I want to focus on configuration for this post, as bootstrapping, while related is worthy of its own post. The goal of this post is to provide some context on the planned changes, and to get feedback on those changes. My hope is that by getting feedback early on we can avoid problems & surprises later on.
In the last article I went over the various static analysis tools I’ve found useful, and how to get them installed. For this installment, I’ll be going over how to use make to run all the tasks, and how to configure all the tools to work with Jenkins.
I’ve recently integrated static analysis tools into both my day job’s and CakePHP’s development process. Setting up static analysis tools is reasonably easy and can help you find problems before you even get to unit tests, or staging sites. They are also the ideal tool to help enforce coding standards, and best practices that can be checked by reading the code.
Myself and the rest of the CakePHP team recently embarked on a journey to refresh and redesign the CakePHP website and brand. I wanted to delve into my process and thinking around the changes.
The cakephp.org website has been around for quite sometime. Its previous incarnation served the project amazingly well.
One of the new features in CakePHP 2.1 I am excited about are view blocks and view inheritance. Both are concepts borrowed from Jinja2 and other templating systems. Template inheritance allows you to create skeleton views, and define blocks to populate that skeleton in a child template.
CakePHP uses salted sha1 hashes for passwords by default, and has for a while. There has been some talk on the mailing list lately of switching the default hashing to something more secure, such as bcrypt. I think this is a great idea, and will find its way into CakePHP in a future release. Providing a reasonanle upgrade experience is the biggest problem to solve, if the default hashing strategy was to change.
In case you were not able to attend CakeFest 2011. I’ve posted my slides up on slideshare. The event was a great success. Thanks to Graham for organizing the event and to all the attendees. Its great to meet the community and put faces and names to irc handles and mailing list email addresses.
This week I’ve been participating in the SQLServer Jump-in Camp. My focus for the workshops have been building out better support for IIS and SQL Server in CakePHP. As I generally develop on MacOS, I do development for other platforms through virtual machines. This has worked well with linux servers in the past.
I’ve recently been working a fair bit on the new documentation for CakePHP and while sphinx is amazing, it doesn’t come with a built-in domain for generating PHP documentation.
In a previous article I covered how CakePHP would potentially be moving to using sphinx for the 2.0 documentation. Myself and some of the other CakePHP developers have been working on this option, and seeing if it has any legs. Turns out that sphinx is actually a pretty great tool.
Today, I tagged the 0.3 release for my AssetCompress plugin. A few new features have been added, and several issues resolved. You can get the code from github
Build tool
The AssetCompress shell is now able to generate all the build files that are named in your project. This is great for integration with build/deployment scripts.
In the release announcement for 1.3.7, it was tentatively announced that CakePHP would be moving its documentation over to ReST, Git and sphinx. Having documentation in a git repo, and using sphinx to generate documentation has a few nice wins, that would be difficult to achieve with the current book application.
This time last year, amid rumours that the end of CakePHP was nigh, CakePHP died and rose from the dead . The year that followed those events, has been a very exciting one. CakePHP continues to be a thriving project with huge popularity, and a growing community. This year has a number of milestones as well.