I’ve been doing many of the CakePHP releases, since “the great framework apocalypse of imminent doom”. Between then and now, CakePHP has had quite a few releases. During these past few months, I’ve really begun to understand the value of a simple release process. When I initially started doing releases for CakePHP, our release process involved many steps and I was doing them all manually.
I recently read “Clean Code” by Robert Martin an excellent book on writing clear, easy to maintain and well factored code. In it Robert Martin raises the point that methods should do what their names say, shouldn’t have ‘flag arguments’, and should do only one thing. This implies that overloaded methods are out.
As a mac user, I’m a huge fan of the great work the people at MacPorts do. If you haven’t used MacPorts before, its basically a mac version of apt-get or rpm and allows you to install all kinds of unix-y goodness from source code on OSX.
I spend a lot of time in various IRC channels answering questions and helping out, and one recurring theme that pops up again and again is people not knowing what to do when things go wrong. Whether it be a simple error or a logical mixup, people often lack the tools or processes to figure things out. So I thought I would share how I approach errors and problems.
As most people know TextMate is a pretty amazing text editor, probably one of the best for MacOS. What you may not know is that CakePHP has its own textmate bundle. this bundle is maintained by JoÃ«l Perras who is also a recent addition to the CakePHP core team.
I recently wrote an article about testing CakePHP controllers the hard way where I covered testing controllers by running their methods manually. I hinted at some additional tricks that could be performed by using Mock Objects. Today I’m going to spill the beans on Mocks, and how I use them when testing my Controllers.
Creating meaningful semantic HTML identifiers is something I always aim to do in my markup. I also thought this was something that other designers did as well. This past week I’ve found out just how wrong I was in that assumption.
By now you already know or should know about
CakeTestCase::testAction() and the wondrous things it can do. However,
testAction has a few shortcomings. It can’t handle redirects, it doesn’t let you use the power of Mocks, and its impossible to make assertions on object state changes. Sometimes you need to do things the hard way, stick your fingers in the mud and work it out.
At some point or another we’ve all had to make a data model that involved various flags to indicate different statuses / modes for an object. Often the schema for such a data model may end up looking like
Eclipse is widely popular, robust and powerful IDE. It supports PHP through the PDT project . PDT gives you some good PHP related development tools, including code completion & code templates to help you save some time.
I like many webdevelopers build a lot of forms. Forms are the bread and butter of web applications, and while making forms is getting easier for developers, users often still have a hard time with them. In these circumstances it is necessary to give them a help above and beyond ‘password’.
As I post more and more code here, I’m finding it tedious to update all the various .zip files of code as I make changes. So I’ve taken a page from Tim and Felix and made an account at gitHub. This makes it easy for me and you to find the newest revision of whatever you may be looking for.
When bakers first start using CakePHP there is a tendency to use
requestAction() more often than it should be. Often
requestAction() gets used to pull in common elements like recent posts or new comments, or to make menus. This makes sense in a way as it keeps the comments code in the
CommentsController and all is well.