PHP 5.3 and Cake 1.2.0

Tuesday 22 Dec 2009 by A.J. Brown | No Comments
Filed under: PHP Tags: CakePHP, PHP

I'm writing this quick note for anyone else that might come across this problem. I recently decided to upgrade one of my CentOS servers running a cleint's CakePHP application from a PHP 5.2.X version up to PHP 5.3.1. The package was from the remi repository, with no modifications. Suddenly, Cake stopped using my controllers' actions to generate output, and was displaying output from the default controller.

After pulling my head out, I found the issue in the dispatcher. Around line 359 or so (I hacked up my dispatcher with additional comments while debugging) in cake/Dispatcher.php, you will find the following:

$output = call_user_func_array(array(&$controller, $params['action']), empty($params['pass'])? null: $params['pass']);

The problem is, call_user_func_array requires the 2nd parameter to be an array. As you can see, cake is passing 'null' if we have no additional parameters to pass to the controller action. To fix, just change 'null' to 'array()':

$output = call_user_func_array(array(&$controller, $params['action']), empty($params['pass'])? array(): $params['pass']);

Now everything should be working again.

Note that this particular application is using a very early version of Cake 1.2. This problem might be fixed in later versions.


What does "meeting the dealine" mean to you?

Saturday 2 May 2009 by A.J. Brown | 2 Comments
Filed under: Uncategorized

One of the most important aspects of maintaining good relationships is doing what you say you're going to do, when you say you're going to do it. As a software developer, your time to shine in this context is delivering the goods before your customer has to wonder where they are.

It's equally important to know what done means to the customer, and how it may conflict with your definition of done. If I'm hiring you to line a parking lot for my store, and the deadline is the day of the grand opening, done is when the paint is dry, not when the last stroke is sprayed (and still wet!). Since I don't paint asphalt for a living, you surely can't expect me to know how long it takes the paint to dry.

A Real World Example

I once worked for an international online retailer who's idea of "meeting a deadline" was a little different than mine. We were scheduled to do a major release of the website consisting of a brand new design, and some additional features. It had a large supporting marketing campaign advertising it as a new generation of the store with super-awesome-o features. A hard launch date was set in the marketing material and community hype, so launching on that date was critical. The developers (through no fault of their own) ended up needing to work 20+ hour shifts in the days approaching the launch in order to make sure all of the promised features made the cut. After gallons of coffee and mountain dew, the launch was finally completed at 11:50pm local time on the day of the deadline.

In the coming days, the launch was touted as a total success, and the words "we met the deadline" were strewn about the meeting halls by the software development managers. I felt that expressing my opinion about the so called meeting of the deadline would create a lot of flak and would be taken as a slam to my fellow developers, so I decided to keep it to myself.

Quite frankly, this was not a satisfactory meeting of the deadline in my opinion. The expectation as a customer of the site was that they would log-on on the launch date and see a brand new website with pretty little features. Instead, we kept them waiting and wondering. Our blog site for the store was lit up with comments by loyal customers, wondering where the site is. Many had given up on it being launched that day, and only those 7 hours behind GMT (the time zone any international company should be paying attention to) or greater actually saw the website on the launch date. Yet, we were proud of meeting this tough deadline because "hey, we technically finish it on the date we promised!".

The real issue in the online retailer case is the approach to the problem. The delivery date and the marketing campaign date should not have been the same. The deadline for software development should have been at least 1 day prior to the launch, giving the developers a deadline that could be approached in the manner it was, but still allowing the site to actually be launched and available to the customer when they expected it to be. The developers could push their efforts right up to the wire (as we did) without any negative impact.

Conclusion

You've probably heard the saying "If you're 5 minutes early, you're on time. If you're on time, you're late!" or some similar version of it. This saying definitely holds a lot of merit when it comes to delivering your products. Surprise your customers and clients by delivering "5 minutes early" instead of making them come looking. Don't use the vagueness of your own deadline as an excuse to say you delivered on time. Save that for the cable company, and their "sometime between 9am and 5pm" appointments.


Zend_Service_PayPal Proposal Back on Track

Tuesday 3 Feb 2009 by A.J. Brown | No Comments
Filed under: PHP Tags: Zend Framework, Zend_Service_PayPal

I just wanted to drop a quick note letting everyone know that after nearly 2 years of dormancy, Zend_Service_PayPal is back in the works. Shahar Evron has been too busy with his work over at Zend Technologies to continue work on the proposal, so I've volunteered my time to get it back on track.

If you're interested in seeing this component in Zend Framework soon, please follow progress at the Zend Framework Contributors Wiki, This blog, and on the project page at GitHub. Any feedback, suggestions, and patches you can provide will be nothing but useful. Send me an email, comment on the wiki, or This proposal is still in it's early stages, but I hope to be knocking out a lot of the work in the next couple of weeks.


Learning What You Don't Know, So That You Do

Friday 30 Jan 2009 by A.J. Brown | No Comments
Filed under: Opinion, Software Engineering Tags: PHP

It's been a very busy couple of weeks for me, and I've fallen behind on some of the articles I've promised to write. I've begun drafting them again, but I wanted to take some time out to talk about something a little more philosophical than technical.

For me, learning the areas that I've yet to master has been a huge motivation to keep pushing the envelope of my own knowledge. I consider myself a very capable developer, and I don't feel that my co-workers, clients, or associates would say otherwise. At the same time, I know I still have a lot to learn. In fact, anyone that says they're a master of every craft of web and software development probably hasn't learned enough to know what there is to know. This blog itself is a consequence of my desire to explore more technologies and techniques.

The best gift I've been given recently is a true evaluation of my level of mastery. This particular evaluation came interview-style from a Zend developer and client support specialist (meaning their salary is paid by Zend Technologies). Before I entered the conversation, I knew it would be highly technical. After all, you're talking about the PHP company. I've been writing code in PHP for 7 years, am Zend Certified, ranked #3 on oDesk for the Advanced PHP Expert Rating test, placed top 10% in many other assessment tests on other freelance sites, yadda yadda yadda. While none of this equates to guru, it does equate to experience and track record with the language. Thus, I expected to be stumped occasionally, but stride through most of it as usual.

As you can imagine, that wasn't the case.

Overall, I did OK with the evaluation. The questions that I was truly stumped on were things that only the best of the best would know off-hand (and even my evaluator admitted to not knowing the answer until he started working at Zend). Then, of course, there were the middle-ground questions that I knew most of the answer to, but there was a small edge-case that I didn't think of, or that took me a bit of thinking to come up with. But what surprised me the most were the questions that I did know (or should have known) off hand because I encounter them every day, but have been numb to the rhyme-or-reason of them. I won't even mention getting a question wrong that I obviously knew the answer to, but was to worried about it being a trick question to think it all the way through.

I won't get into specifics of the questions that were asked, as I don't want to provide a cheat sheet for the next person. But, the point is this -- being able to academically and fluently explain something on the spot is the true test of how in-depth your knowledge is on a subject. Don't settle for just being able to do it well, but understand why you're doing it, how you did it, and what's the best way to do it. The Pragmatic Programmers would call this programming by confidence, not coincidence.

Thanks for making me study harder, Zend :)


« Older Entries