The built-in testing system is some weird mishmash of unit testing and “you have to create your own test results template”. WTF? You can’t be serious. So I quickly ignored that. Besides, the first set of tests were going to be using PHPUnit combined with Selenium so I could make the “acceptance testing” automated. As an aside to this, I remember speaking with Sebastian Bergmann (the driving force behind PHPUnit) at a conference maybe 3 years ago and him telling me that he knew someone was working on getting Selenium and PHPUnit to play nicely together. Anyway, it’s working just fine.

So, next step was to see if I could use something else than the incredibly lame testing tools that Code Igniter came with. I found something called fooStack, that contained CIUnit. It lets you use PHPUnit with Code Igniter. Now we’re talking! Lickety split I had some unit tests for my models written. Well, after spending quite a lot of time screwing around with the tests and finding out the difference in relative paths between the application running via Apache and trying to test the models via the command line. Thanks to all those on Twitter who yelled “use php_sapi_name to figure out what environment you are in, you idiot!” at me.

But all this got me to thinking: how do some other PHP frameworks stack up in terms of having tests?

• Code Igniter has ZERO tests for the framework itself. Perhaps I will mention this to my boss next time I’m asked to create a project from scracth. Hrm, guess I’ll have to trust that their code actually works the way it’s supposed to.
• Zend Framework (full disclosure: I was one of the original authors of the Zend_Service_Audioscrobbler component) has huge amounts of tests for the framework itself. In fact, any new contributions MUST have working tests submitted with it.
• CakePHP has lots of tests for the core, and I believe that I saw something in the changelog for CakePHP 1.2RC3 that indicated they were at 80% code coverage in terms of testing for the CakePHP core. Bug submissions for CakePHP are supposed to come with tests to prove that there is a repeatable problem.
• Symfony recently rewrote it’s core tests and created their own testing framework for it.

So now when you start comparing frameworks to each other, I think it’s important you also consider how much effort has gone into creating tests for the core functionality of that framework. A well tested framework should mean far less surprises when using it. Given how many tools are out there to assist you in testing, I don’t think there are any excuses other than being totally lazy to not create tests for the core functionality of any application. Pay now, or pay later, but you will PAY to fix bugs in your application. Paying now is simply cheaper.

Would you stake your project on complex code written by someone else that is simply not testable by you? Perhaps I am not looking at from the proper distance because I am inside the framework-creator culture, but I can’t see why you wouldn’t want to provide tests to prove your stuff actually works the way you claim it does. Tests prove that the code is *behaving* the way you expect, and code that is testable is also usually easier to modify as time goes on. There is some sort of sick joy in making a change to code, running the unit tests, and seeing that you didn’t break anything.

• Final RC before a final 1.2 release
• Significant speed increases in the wake of Rasmus Lerdorf’s talk about PHP framework performace, and Cake’s poor showing.
• A chance to totally break your application by upgrading!

Well, maybe not so much on the last item but it’s ALWAYS good to see any project make a significant release. 1.2 has been in the works for more than 18 months, which seems to many to be way too long. I’m not so sure I share that sentiment. If the goal is to try and produce quality releases, then “it’s done when it’s done” is a reasonable answer. I’m sure this is not a new argument, so I won’t get into it here.

My own contributions to RC3 have been, what’s the word…non-existent. Non-computer hobbies + side work = no time to contribute to Cake. I found out that commit access for people who haven’t contributed anything in more than 60 days has been revoked, but that’s really just a minor annoyance. I’m sure I could get it back by asking nicely and actually having something to contribute.

But I think I’ve gotten back into Cake developing at the right time as I caved in and decided that my long-rumoured plan-a-road-trip site shall be built in CakePHP after all. Yes, I’ve been playing around with Django but I’m violating one of my favourite rules: Just Build It, Damnit! I’ve been fooling around with Balsamiq Mockups to do the pages and are now digging around for helpers to do the mapping mashup I need. If you want to mock me over how little progress I’ve made, feel free to visit the site. If you’d like to get involved at all (I could use some help on the “make a pretty UI for it” front) let me know.

• Oh look, another CakePHP book coming out that I can review if the author pulls some strings. Yes, I’m talking to YOU AD7Six
• Although the title of the presentation is “Why I Hate Django”, Cal Henderson from Flickr shows why you simply cannot avoid frameworks when building applications. Deny this fact at your own peril.
• If you’re not already reading their blog, check out Felix and Tim (and sometimes Nate) over at the Debuggable Ltd. blog where you can find some of the best CakePHP tips around. Felix is closing on on 30 straight days of blogging, though not always CakePHP related.
• I’m going to be in Mountain View, CA next Wednesday (the 24th) for a super-secret meeting and have some time to kill before my red-eye flight back home. Maybe we can hook up so you can hurl abuse at me and so I can get enough alcohol in me to sleep on the red-eye flight back to Toronto?

One of the biggest criticisms in the past of CakePHP was the lack of published documentation on how to use the framework. As shocking as it was to me, there were people who preferred a paper copy of the Cookbook so they could have access to it when they might not be online (what, working on your computer and not online?!?) or to read offline. Naturally, several books about the framework have been published in the past few months, and I can’t think of a better book to recommend to people interested in learning the framework than this one. And I’m not just saying that because I got a copy for free. While the book is good, there are a few places where it could be even better.

The Good: Examples, Example, Examples

The target audience for this book is the right one that CakePHP is attracting: intermediate PHP developers who may have not used a framework before and are trying to figure out how to use one to their advantage. Without clear and relevant examples of how to use it, CakePHP would be just another framework struggling to gain acceptance with the PHP deveoper community. If you want examples on how to do most basic things with CakePHP, this book has them. Want to know how to configure CakePHP to work for your web server? Check! How do you get results from your database? Check! How do you use the ‘bake’ utility from the Cake console? Check! Validating form fields? Check!

I feel that the examples in this book are it’s strengths. The code is well written and every code example is followed by an explanation of what they are doing. Many times the example is not enough, you have to understand WHY it’s written that way.

The Good: Sample Applications Always Help

Almost half the book is devoted to creating an application from scratch, including configuring the often-misunderstood Auth component and showing how the built-in Javascript helper allows you to add Ajax-powered functionality via the Prototype and Scriptaculous Javascript libraries. Seeing an application being built from start to working prototype is an invaluable lesson for the “learn from example” crowd.

The Bad: Less Info On Doing Things The Cake Way

I feel that some more time could’ve been spent explaining CakePHP’s “convention over configuration” preferences and how it changes the way you approach building an application using CakePHP. Perhaps that wasn’t a topic for this book’s intended audience, since it’s only the deep thinkers and the rant-and-ravers (which I have been accused of belonging to) who like to discuss the philosophy behind CakePHP and the question of just what a framework is good for.

The Bad: Thin on Server Configuration Information

While there is a chapter devoted to getting CakePHP up-and-running using Apache and MySQL (specifically using WAMP), it would’ve been very helpful to see an example of the type of configuration recommended for production environments, where the APP directory is web-accessable while the CakePHP core is located somewhere outside the webroot, linked in via an option in the configuration files.

The Bad: No mention of the differences in debug levels

When I do my development work on a CakePHP application, I set the debug level to 1 so that I see all errors and the SQL statements being generated by my models. In production I have the debug level set to 0 as I don’t want error messages on the screen that reveal any information, and I certainly don’t want people seeing the SQL statements being executed. Sure, it’s security by obscurity but it’s also debugging information that’s cluttering up the screen.

The Bad: No mention of using the built-in testing

While I’m a lapsed tester, the fact that CakePHP will create the shells for writing unit tests for the models and controllers you create should not be overlooked. Although testing gets a bad rap (”It’s too hard, and it wastes my time!”) it’s a programming practice that should be encouraged.

The Ugly: CakePHP is still a moving target

While this in no way diminishes the efforts put in by the authors to create this excellent introduction to CakePHP, at the time it went to press CakePHP 1.2 was still not feature-final. Some tihngs have changed, and I expect some more things will change before CakePHP 1.2 is finalized and work on CakePHP 2.0 starts. This is the danger in writing about any programming language: the information could become obsolete at any time. But don’t get all upset about it, as it is likely only very minor details that have changed. The CakePHP core team does try to not break things *that* much.

So, don’t let the number of “bad” issues above dissuade you from checking out this book. The items I highlighted are probably bettered suited for a “Advanced CakePHP Application Development for Grumpy Developers” book. I would not hesitate to recommend this book to any semi-experienced PHP developer who is looking for a resource guide to get themselves started.

For a consulting job I'm working on where I'm porting a spaghetti-PHP application over to using CakePHP I am moving their existing authorization system over to using Cake's Auth component. Of course, they are storing all their passwords in plaintext in the user account table, so I needed an easy way to convert all the existing passwords over to be encrypted using the same hash that Auth would use. Doing this was surprisingly easy thanks to the power of shells and tasks in CakePHP..

I think the code in there is pretty self-explanatory. The only "gotcha" I ran into (fixed by a look at the Auth component itself) was that I needed to tell Security::hash() that I wanted to use the salt I defined in my config file. By default that parameter is set to false, hence the need to explicitly set it to true.

Thank to Mark Story for pointing me in the right direction for this.

Welcome to the 4th and final day of reader feedback week here. Today's topic is one that comes up over and over and over and over again: web application performance. In particular, I wanted to discuss web application performance and frameworks.

After seeing a slide from a presentation at FrOSCON about CakePHP's performance in the incredibly-unrealistic-and-irrelevant "Hello World" competition against vanilla PHP and other PHP frameworks I came up with that very aggressive statement you see above. That prompted a flurry of tweets by other people about their thoughts on that matter, and so on and so forth. I believe my earlier statements were misunderstood, so I shall clarify them here.

I stand by the statement "frameworks are about increasing development speed, not application speed". I've talked about frameworks plenty in the past, and they all promise you this: if you build things according to their rules (and this is the really important thing to remember) then you will gain a significant increase in application development speed. If you fight against those rules, why are you even bothering to use the framework? The goal is to speed up development time by following a set of conventions on how the application is put together.

So, if you've had enough courage to build you application with your framework of choice, you should have a working application. That doesn't mean it is as fast as it could be, but remember the mantra I shared earlier: "make it work, then make it work better". Where frameworks typically fall down is in the "make it work better" part of that statement. Travis Swicegood pointed out to me when it comes to frameworks "...actually, a really good one should have mechanics in place to do both" (referring to increased development speed and application speed).

So, if you have a framework that actually cares about application performance (perhaps unfairly some frameworks have decided that performance is sole responsibility of the developer, not the framework itself) then it should come with things to make your application a little more responses. Things like built-in output caching, or features in their ORM/ADM that cache your schema, things like that. But in the end, there is only so much you can to make a framework-built application run really fast. Sometimes you can do it with just the additional features I mentioned above. Sometimes you can't do it because the architecture you've chosen for your application won't let you. And sometimes, you can't do anything about it because it's too hard to modify the framework itself. These things happen. Look at Twitter and all the contortions they have gone through trying to take what was initially a Rails application and push it's performance up to it's current level.

There are also lots of 3rd-party solutions to help you make your application perform better. Memcached for caching data (ask me some time about my Memached story at an old job). Alternative PHP Cache if you're running PHP. Squid. nginx. Mongrel. Those are just the ones I can think of off the top of my head. Some of them are even framework agnostic.

Having a framework that lets you BUILD things fast and RUN things fast is the perfect situation, but not too common. I used to get mad when I'd see people asking if can scale, because I felt it revealed a certain level of ignorance in the person asking the question. I've now come to the conclusion that what they are really asking is if can scale without them doing any extra work. Usually, the answer to that question is FUCK NO (emphasis mine) because scaling is an issue that goes far beyond just a simple framework.

See, not every framework is slow. Some frameworks, due to their internal structure, are faster than others. I'm okay with that now, not so okay in the past. In a lot of cases, the bottlenecks in your application aren't code-related. I've come to understand that too, especially in the new Javascript-driven world web applications have started to run in. If you think Twitter is slow because they chose Rails, I think that you do not have a firm understanding of how Twitter actually works. Or maybe you don't care because it's easy to make fun of Rails and Twitter.

Luckily, we have lots of free and easy-to-use tools at our disposal that let us look at our up-and-running web application (remember, Just Build It, Damnit!) and see how it's performing. Things like Siege and YSlow are just two tools that their use will give you huge insights into the actual performance of your web application.

You shouldn't be GUESSING how your application performs, you should KNOW what is going on.

First of all, I do all this in PHP 5. SimpleXML makes it so easy to manipulate XML. For my main work project, I've written a PHP application front end that talks to eXist, an open source XML database. Since we deal with XML all day long it was decided that we needed to eat our own dog food and go with an XML database to store the information that the application generates. So a lot of my code does some of the following things:

• Do a call to a xQuery script running on the database that returns info that I'm looking for, usually both comma and pipe-separated data
• Load a specific document into a SimpleXML object and pull out some specific info
• Load a specific document into a SimpleXML object and then use it's XPath functions to pull some information out.

Those 3 techniques seem to work well for me when dealing with XML data in PHP. If I had to go back and redo some of the earlier code, I'd probably change things a little differently in how I'm using eXist to simulate how some of our other products work:

1. Use eXist to give me a list of documents that contain the info I am looking for
2. Load those documents into SimpleXML
3. Use Xpath to grab the data I needed

But in the interest of Getting Things Done, what I've done works pretty good and the code is really not horrible.

So why all the love for Django and Python? As a guy who's used PHP for a very long time, I'm really blind to the syntax of it. All the griping about needle vs. haystack and "PHP is ugly" is just wasted on me. Just so much pissing and moaning by people who should know better and lack the courage to learn the language they way they should. I heard it described by Evan from Identi.ca as being "the working man's language". Nothing wrong with that, as PHP is great at Getting Things Done. But Python...Python is vastly different from PHP. It's about objects. It's about consistency. It's about the most amazing interactive interpreter I've seen since I was a kid fooling around on my VIC-20 typing in programs from Compute! magazine. Bet you didn't think I'd been using computers for that long. To shift into bragging mode, I first got paid for programming when I wrote a program for my mother's school (she's a teacher) to create the salary grid for the teachers. I was 12. I think.

Also, there's a dirty little secret about using frameworks that nobody really tells you. After a while, it makes you lazy. You forget how to do certain things because, well, the framework does it for you. The other day there was a tweet from someone asking about the best way to sanitize data before you put it into the database. My first thought was "sheesh, that's built into the framework" and then I stopped myself and said "you are getting goddamn lazy!". My response was "try using mysql_real_escape_string(...)" but was also told about using PDO's binding of parameters as another way to do it. See, those things are all done by the framework meaning lazy old Chris doesn't have to remember how to do it. Until the time he's confronted with non-framework code that he cannot simply rewrite as part of a framework. *gulp*. So, since Python and Django are so different from the other frameworks I've used it forces me to STOP being lazy and actually learn how not only Django itself works but how the insides of it work as well.

Now, being an old hand at frameworks means using Django is not that big a stretch. I spent a lot time googling around for the "Python (or Django) Way" to do things. Except for a few concepts that are not familiar to a long time PHP guy (generators?) it wasn't that hard to get up and running with Django. The documentation is awesome, and once you learn to stop writing PHP code in Python and instead embrace doing things the Python way, it becomes a lot easier.

In the end it's still datasource-backed models talking to some controller code and passing it onto some template. I find the Django templates to be very limiting after my initial experiences and my "PHP is the template" background, and I think that as I get deeper into it I really have to find out how to do things the Django way. What CakePHP calls Model-View-Controller, Django calls Model-View-Template, but it's really the same thing.

When I compare Ruby to Python, I don't get the feeling that I will have to resort to dynamic functions and closures to Get Things Done in Django like I see happening in Rails. Besides, they seem to be two very different communities. That's probably because the leaders of the Django community are so different in temperament and I don't see the same type of "Django rules, everything else sucks!" mind sets that I saw in the Rails community. Maybe I'm just looking in the wrong places, but I feel more at ease in the Django community than the Rails community, albeit from the outer fringes of it.

So don't be lazy and complacent about the tools that you use. Go and checkout Django and you might feel the same way about it as I do.

As I never get tired of telling people, my employer is one of the enlightened few who lets their employees telecommute 100% of the time, so there are some different challenges in play. I understand that some people could not "handle the pressure" (their words, not mine, although I am paraphrasing) of working from home. At this point I could not imagine going BACK to working in an office.

So, with your boss always around on IRC and just a phone call away, how does your grumpy correspondent stay on top of his tasks since he knows the boss will never show up at my desk asking me a question? You may be surprised at the answer if you know me in real life: through self-discipline.

Yes, I can already feel the immense amount of eye-rolling (including my mother) but it really is true. If you are the type of person who needs to be constantly told what to do, you are not going to cut it in a telecommute environment because you WILL be left alone for long periods of time to Get Things Done Without Constant Supervision. The only way to make sure you are able to function without simply going upstairs and watching TV when you are supposed to be working is to, well, act like the professional coder you are supposed to be. So, how do I handle this? Please be aware that this is a method that works for me and probably only for me. Copy it at your own peril.

I tend to approach programming assignments as if it was Big Problem that can be solved by breaking it down into Little Problems. This is why when confronted with the question "is there any programming challenge you solved that you are really proud of?" I tend to draw a blank because, well, despite all my bluster and accusations of being an asshole, I don't really look at the stuff I do and say "goddamn, that was amazing work". To me, it's really just solving a bunch of smaller problems that make up a bigger problem. I guess you thought I'm a shameless self-promoter of my work. I try to do go

I mean, not every programming task I complete is what I would call exceptional work because sometimes you just can't figure out an exceptional way to do it. Plus, I can't bring myself to be such an asshole as to expect everything I do to be perfect. Not everyone is at their best all the time. Therefore, I try to follow a policy that was explained to me by gwoo from the CakePHP project: "Make it work, then make it work better". I can't think of a better philosophy for the type of work I do every day.

Everything beyond how I approach solving problems is really just non-important. I make lots of notes, but I'm not a compulsive note organizer. I don't have any system for keeping track of what I'm working on beyond a simple list of items in a spiral notebook that I cross off and scratch away at while I work. Hate to disappoint people, but I try to keep it very simple. Whenever I veer off into the land of Complex Task Tracking, I spend more time tracking tasks than doing them. Keep it simple, keep it something I can use each day and every day.

So, that's my approach to personal project management:

• Be professional since you are, you know, being paid to do it.
• Keep your solutions simple
• Adopt organizational practices you can follow every day.
• Try and do your best work whenever you can, but understand when you are not at your best