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.
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.
Slides from a short talk I gave at the Guelph PHP users group about Jenkins and continuous integration.
I’ve been working all day everyday with Monaco for the last 6 years. Monaco is a great typeface, it has a number of really great properties. It has a large x-height, and a large m-width. This make it great typeface at small sizes. While monaco is a perfectly good typeface, I wanted experiment and see if there is another typeface that would be even better.
In a previous post I talked about switching to Vim and how I was using Janus to get a good foundational set of plugins to work with, and make starting with vim less daunting. As I’ve gotten more comfortable with vim, I wanted a simpler way to manage my vim config.
A talk given at CakeFest 2010 about unit testing, mock objects and continuous integration.
As you may or may not know CakePHP is transitioning to PHPUnit and with this transition comes a totally new Mock object interface/implementation.
In the past I’ve used a variety of tools to deploy client sites, most often using version control. However, for my blog I’ve always used FTP. Its a pretty old-school approach, and something that I’ve been lacking the time to correct. Last weekend I finally took the plunge and figured out how to get Capistrano to deploy my site.
Errors and error reporting an important part of the development and debugging cycle. In interpreted languages, there are a number of runtime errors that can really help you debug your code. Some languages like python don’t give you a way to make the errors go away, but for better or worse PHP does.
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.
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.
My current work at CakeDC allows me to be on IRC a lot – like all day. And while I’m often quite silent during the day, I do scan through a few PHP related channels and I’ve noticed a trend of PHP developers who just don’t get Javascript. Either they don’t have the experience, or they do have experience and think its icky.
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.