Plank
Plank, like many other web-centric companies, uses a version control system for pretty much everything. It lets our team of developers, integrators and designers save and share their work in an intelligent manner, with the added benefits of redundant backups of all our client work (as well as the entire history of the project) a snap to make.
When we started using a VCS several years ago, Subversion was the tool to use. It was relatively easy to setup, had decent tools for all platforms used at Plank (Windows, OS X, Linux), and was intuitive enough for everyone, techie or not, to use on a daily basis.
As our team got larger and as our projects became more complex, however, some problems started to show. Integrators, who work often with tools such as CSSEdit, TextMate and the ubiquitous Photoshop, shouldn't need to fear moving folders and files around and causing Subversion hick-ups due to missing or incorrect .svn/ metadata. Developers, who spend their days on the command line and in IDEs writing code, shouldn't need to block off a half-day of their time to perform a branch merge. Combine these major issues with the fact that subversion does not allow offline commits or log viewing (important for us when we're on the road, attending a conference, or without internet access for some reason) along with the general slowness of any operation in Subversion, and we were ready for a change.
That change was Git.
We started using Git on a trial basis for a few projects in September of 2009, and in December of that year all new projects at Plank were being served through Git as a version control system. The advantages that it has over Subversion are almost too many to count: offline commits, incredibly fast branching & merging, a separate "staging" index and even the relatively benign "stash" tool - all of these are now essential to our workflow and enable us to better serve our clients.
Additionally, here at Plank we often use CakePHP, a web application framework, for development. Its flexibility, architecture and documentation (not to mention having one of the core developers on our team!) has allowed us to develop some great sites, with functionality that our clients want and need to stay relevant in this highly dynamic and ever-evolving 2.0 world.
Well, now is the time to give back. As of yesterday, we at Plank have pushed several of the CakePHP plugins that we have developed internally to our Github account. They are fully documented, fully unit tested, and available for anyone to use or fork.
Join us and take a look. We'd love your feedback.
Comments
Hey Neil,
SecurityComponent::requireSecure() was actually the first iteration of what this component became.
requireSecure() was not exactly what we needed – that particular method will blackhole your request if it is not coming over HTTPS. While it would be possible to then write a blackhole method that simply redirects you to the HTTPS version of the current URL, that’s a slight abuse of the error control flow graph; blackhole’ing a request is what I would consider an ‘error’ path in the control flow. Blackhole methods should be endpoints, and I wanted to keep it that way.
Additionally, if you use the requireSecure() + blackhole redirect technique, then all of your subsequent requests will be over HTTPS as well – CakePHP link urls generated with the HtmlHelper are all relative (as opposed to absolute), and will simply inherit the protocol used in the previous request. While this may not be a problem for many people, I needed to avoid the encryption overhead on all non-essential requests.
Finally, having all of the related logic in a component also makes things very easy to debug or disable, instead of having to chase around your AppController & SecurityComponent configurations.
So, to solve these two issues and address the third, the SSL component was born. It’s not the most clever piece of code I’ve ever written, but it solved a few problems in a concise and very project-reusable manner.
Hi Joel, Thanks for sharing these with the community. Just wondering, on the SslComponent, what’s the difference between it and SecurityComponent::requireSecure ?