CakeDC Blog

TIPS, INSIGHTS AND THE LATEST FROM THE EXPERTS BEHIND CAKEPHP

CakePHP 2 Application Cookbook

Today we just released a new book on CakePHP, appropriately titled the CakePHP 2 Application Cookbook. Published by Packt Publishing (ISBN 978-1782160083), and also available on Amazon, Safari and Barnes and Noble, in both printed and e-book formats, this title delivers over 60 tutorials aimed at providing you a nice bite into CakePHP, and getting you familiarized with common approaches and techniques when building applications using the framework. Each tutorial takes you from set up, to implementation, and then an in-depth overview of how it all works, so you can easily jump in on the topics that are most important to you. For a while now the community had been asking for a book on the framework, and earlier this year some of us at CakeDC jumped on the opportunity to accept the challenge. As we didn't want to write a book which was just an echo of the documentation, we took the initiative to determine which issues were really most relevant to the community. We did this by collecting the most popular questions from support sites, such as Stack Overflow, which covered topics such as how to use certain features or perform common actions with the framework. We then ranked those in order of frequency, and proposed solutions for each one, putting together what we consider to be a comprehensive guide as to how to get the job done fast and done right. While we did our best to approach each topic with a rapid and sensible solution, we were constantly aware of the possibility of the uneven level of technical knowledge each reader may have. So, we tried where possible to keep the examples inline with simple or reasonably understandable parameters, to reduce any additional knowledge which could be required for each tutorial. We hope no one feels too far out of their depth! The process itself was somewhat new to us, especially with a serious and noteworthy publisher leading the effort, but we managed to make it through in around 2-3 months of late nights and ridiculous dedication, including various phases of review and corrections. That said, we did all of this while also juggling our professional work at the Cake Development Corporation, our personal lives, and in my case, also organizing CakeFest 2014, the annual CakePHP conference. It's something I would definitely recommend if you love to teach and share your knowledge, whatever topic that may be. So, grab your copy of the book from the Packt online store, or from Amazon, Safari or Barnes and Noble, in either printed or e-book format. We'll be donating 100% of the royalties from sales of the book to the Cake Software Foundation, so that everything you give goes straight to CakePHP, to help keep the project strong. That's how much we love this community! We hope you take something away from the scenarios we take on, and hopefully enjoy working even more with the framework. As always, we're very active in the community, so if you have any feedback or suggestions, feel free to reach out to us. Here's to many more years of delicious cake, it was never a lie!

CakeDC Git Workflow - Working Together

In our previous posts on the CakeDC Git Workflow we shared some insight on how the development strategy works, and how to get the most out of it. But one of the most important benefits it provides is the increased stability and consistency when working alongside others.

Collaboration and Code Review

Working in a team means that you can usually borrow someone else's eyes. In a cooperative and fast-paced environment, you have to. Period. And one situation that typically arises for this case during development is the "code review". $ git checkout -t origin/feature/1234 $ git checkout -b review/1234 $ git push -u origin review/1234 Here, the reviewer fetched the feature/1234 branch, then created and pushed their own review/1234 branch. Then, they may propose some changes to the original code, for example: $ git commit -m "Optimized this and that" Once the review is complete, they'd then simply push their changes, like so: ... rebase ... $ git push Now you can use their branch, separately of your own, to clearly view the proposed changes. $ git checkout -t origin/review/1234 $ git diff review/1234 feature/1234 And when everything is done and ready, just merge those changes in. $ git checkout feature/1234 $ git merge review/1234 ... rebase ... $ git push Finally, don't forget to always do some cleanup. $ git branch -d review/1234 $ git push origin :review/1234 Like this, even that single reviewer's commit (assuming it wasn't squashed in some following rebase) is done in different branch, and clearly tied to the ID of the feature, keeping the story of your code clean and consistent for others.

Maintenance tasks

Using our workflow you'll find that both you and your coworkers will delete remote branches quite often. From time to time, it's good to remove references to non-existing remote branches from your local repository, as you don't want to see redundant branches in your git branch -av list. For this, you can simply prune your branches. $ git remote prune origin And don't be afraid to be completely thorough when cleaning the repository up, go for it all! $ git gc && git clean -dfx && git stash clear

No fast forward merges

Sometimes it's just plain tedious to write --no-ff all the time, especially when we can set up git so we only use --ff when required. Via your project's git configuration file, you can either disable fast forwards for all merges directly, like so: [merge] ff = false Or, just for selected (permanent in this case) branches only: [branch "master"] mergeoptions = --no-ff [branch "stage"] mergeoptions = --no-ff [branch "qa"] mergeoptions = --no-ff [branch "develop"] mergeoptions = --no-ff Then, for those cases where fast forward is desired, just use the --ff switch: $ git checkout develop $ git pull --ff This is especially useful when you're collaborating with others, and those commits are flying around between you. Last thing you want is to get bogged down in merge conflicts!

Users plugin 2.1.0 released

We just released version 2.1.0 of the CakeDC Users plugin for CakePHP, and with it a collection of bug fixes and improvements, an update of the code to 2.5, as well as a reformatting of the documentation inline with the CakeDC Plugin Standard. If you haven't used the Users plugin yet, it's a great addition to any application which requires user registration, log in and management. The plugin also provide simple role handling, as well as user search if you combine it with the CakeDC Search plugin. Including the plugin is as easy as adding it to your application, running the schema or migration to add the tables used by the plugin, then simply navigate to one of the actions provided, for example: /users/users/login You may want to provide more specific routes, inline with your application, for example: Router::connect('/login', array( 'plugin' => 'users', 'controller' => 'users', 'action' => 'login' )); However, you’ll usually want to fine tune the experience for your users, for which you can extend the controller provided with the plugin and override the actions it includes to customize your own logic. class ExampleController extends UsersController { } There are also many configuration options available, if you'd simply want to configure how the plugin behaves. But, if you'd like a more decoupled approach you can also take advantage of the events, which are triggered by the plugin at different points of the user workflow. Features such as sign-up, log in, remember me, account verification and password reset are provided by default with the Users plugin. It also sends tokens to users via email as a security measure for certain actions. Additionally, the plugin comes with a basic user management interface, ready for admins to manage users in your application. As always, our plugins are released as Open Source free of charge, and benefit directly from the numerous contributions made by the CakePHP community. We want to thank all of the contributors to the Users plugin, and hope that future involvement helps keep the framework ecosystem strong, with a host of powerful plugins that keep you all building great applications.

CakePHP 3.0 is coming

For those of you who may have missed it, this week we released the first alpha of CakePHP 3.0, with a significant update to begin our move towards beta. I'm really excited to see how the project is evolving, and the amazing work that the members of the core team are doing, as well as what all those contributing are helping to build. But its important to look back in retrospect, and understand from where we've come.

Baking the Cake

If you're not aware, CakePHP has now been almost 10 years in the making. That's a long time for a project to stay as active as it has. Everyone has their favorite framework, and some like a few more than others, but one thing that's clear in my mind is that CakePHP has always been very popular, even until today. The project started when I teamed up with Michal Tatarynowicz, who had created the basic feature set of what would become CakePHP. I had begun work on what is currently the model layer in the pre 3.0 version of the framework, and continued leading the project when Michal left shortly after we open sourced under the MIT license. This was back in 2005, and working with PHP 4. Back then we had to work around the language a lot, as it was lacking the object oriented features which we now all take for granted. We had to emulate or actually build out many of the native aspects now included with PHP, which made the task all the more complicated. Don't get me wrong, it was fun times, as the language was growing fast and we were all pushing it along. It's no secret the Rasmus isn't a huge fan of frameworks, but like Rails for Ruby, many of the frameworks for PHP have also helped the language gain a place in many people's hearts. But time goes by, and like all things, PHP grew up and matured as a language. A lot of the features we had implemented for CakePHP in PHP 4 now became native with PHP 5, so although we'd provided the solutions when they weren't available, these now became redundant. But people and hosting companies were slow to adopt. The framework had grown a large community by then, so it was difficult for us to just drop support for PHP 4 and leave them without their framework. It was also in our interest to support PHP by prompting people to upgrade, so we took the middle road. This is where our infamous backwards compatibility for PHP 4 stems from. There were disagreements between core members of the project, where some advocated for jumping the gun and releasing a version which required the latest version of PHP, but I refused to allow our community to be left behind. These are people who had grown up with the framework, people who relied on us to keep a solution which allowed anyone to use it. In hindsight you could say that those developers weren't worth supporting, but I see our community as a family, and like my Marine training taught me, no man gets left behind. However, the years past, and we went from 1.2 to 1.3, and CakePHP begun to mature into a powerful solution for rapid application development. We also saw how adoption for PHP 5 improved, and hosts begun to offer broad support, which is when we decided to make the move to PHP 5.2 with the release of CakePHP 2. There were mixed feelings about the decision to not jump straight to 5.3, but I still feel today that, in allowing the framework to mature as it has on a stable code base, people who have counted on us would hopefully understand that choice.

Growing up as a Community

Like the years that have come before us, we all grow up as developers, and PHP the language grows with us. The impulse we've seen over the past years with the releases of 5.3, 5.4 and 5.5 have shown how the community can really build a powerful language. But it's not only the language that grows, but the community around it as well. We've seen over the past years how interoperability between frameworks has become a requirement, and the technical expectations of developers have become consistently more demanding. We've seen how the rise of packages managers, like Composer, have facilitated this distributed and modular approach to building PHP applications. So when we looked at what we expected for 3.0, as Jose Lorenzo said in the technical keynote at CakeFest, our annual conference, "we're all older and wiser", so it's time to put those years of experience to good use. So, for CakePHP 3.0 we decided that now is a good time to take our community and move everything towards a stronger and brighter future. This means that we've made some of the important decisions, which align the framework with the coming features in the language, and provide the same framework goodness people are used to, but deliver it with new features which upgrade the solution for another 10 years to come. This also means breathing new life into many of the core aspects of the framework, which in some cases have become its winning features, and in others the infamous trademarks of CakePHP. I invite you all, those who love CakePHP and even those who don't, to give this alpha of the latest major version of the framework a try, and let us know how well it tastes. We hope that this is the beginning of a great new chapter in the history of CakePHP, and one which lets us grow further, and together, as a community. Thank you.

CakeDC Git Workflow - Tips and Tricks

Over the past months we've had many people ask us about how to integrate and work with the CakeDC Git Workflow as we do. So, here are few tips and tricks on how to use our workflow for the git version control system, to help you keep a clean commit history on every CakePHP project.

Using ticket numbers in commit messages

One thing which becomes pretty obvious early on is how handy it can be to have commits tied to your issue tracker. The easiest way to do this is to use the issue or ticket ID in your commit messages. $ git commit -m "#1234 changed this and that" Following this pattern (starting the commit message with #ID), with a bit of git rebase sauce, makes the lines of your updates read like a story of your code.

Automation with use of commit-msg hook

It's possible that you may not using a git bash prompt, so you don't see the name of the current branch in console all the time. Alternatively, the dialog window of your preferred UI for git may not clearly disclose the name of the branch you're working on. Or, maybe you're just too lazy to write ticket number every time you commit something to the repository. Using our workflow, where non-permanent branches are named after the related ticket number, you can create an executable file .git/hooks/commit-msg in the project's root directory with following content: #!/bin/sh TICKET=$(git rev-parse --abbrev-ref HEAD | awk -F '/' '{print $2}') if [ -n "$TICKET" ]; then echo "#$TICKET `cat $1`" > $1 fi From now on, the message of every commit to any branch with a forward slash in the name (in our case, its always the ID of the related feature/issue/hot-fix ticket), will start with a hash and the ticket number. Also, lets assume that you're using our workflow for all of your projects. In that case, it could be better to install the git hook globally: $ mkdir -p ~/.git_template/hooks ... add global hook(s) to this directory ... $ git config --global init.templatedir '~/.git_template' After setting this up, every created or cloned repository will use this template directory (will make copy of its content). Existing repositories could be reinitialized with the new template by running git init in their root folders.

Temporary local branches

With the previous commit-msg hook in place, we can now go crazy with temporary local branches, while still maintaining a readable project timeline with references to tickets. Changes don't have to be committed directly to published branches, and here are some examples how to do that.

Local branch for debugging

Debugging sometimes takes a lot of code to be written, and sometimes a few of the changes made during debugging need to be merged and propagated. $ git checkout -t origin/feature/1234 $ git checkout -b debug/1234 Now we have local branch debug/1234 based on feature/1234. Lets do some work in loop, like adding tests, debugging code, applying fixes... everything in commits as small as possible, with meaningful commit messages: $ git commit -m "Added debug code for debugging this and that" $ git commit -m "Added test case proving this and that" $ git commit -m "Tried to fix this and that" The history of the debug/1234 branch will look like the following: #1234 Added debug code for debugging this and that #1234 Added test case proving this and that #1234 Tried to fix this and that We'll still have the feature branch free of debugging related code. You can then merge to this branch to keep it updated with progress from feature branch, but you can also commit fixes to it that you'll want to publish, and then use cherry-pick for including them elsewhere. And if you changed something in your debug/1234 branch, that you'll want to still see in the feature/1234 branch, then simply perform the following: $ git checkout feature/1234 ... merge, cherry-pick, rebase ... $ git push Then, finally some clean up, like so: $ git branch -D debug/1234 We hope you found something useful here, to make working with the workflow more engaging, and help you keep building awesome applications with CakePHP.

We Bake with CakePHP