@TheKeyboard Maintainable code is hard. Let’s go shopping!

A co-worker of mine always complains that people don’t read the RFC that covers a topic related to making their own stuff work with our stuff. He’s old sk00l like that. Although my co-worker is a tad out-of-touch with the realities of programming these days (as in the amount of people who actually read the RFC when they can simply use someone else’s library / module / function / application is very small), I thought I would at least adhere to some semblance of standards and do a blog posting about my plans for making CakePHP application deployment easier.

While I really prefer to use tools like this for deployment, I understand that not everyone wants to mess with standalone programs and configuration files. I’ve been asked before about Cake-specific deployment techniques, so I figure the easiest way is to see about adding a task to the Cake console. Let’s call this ‘cake deploy’.

As I explained on the mailing list I am looking for opinions on what sort of things should be part of the ‘cake deploy’ task. Right now, my thoughts are as follows:

• cake deploy config

- setup and edit configuration parameters. Initially I thought of setting things like transport method (ssh, ftp), logins and passwords, remote location, source directory, and destination directory. The configuration file would be stored locally in APP/config

• cake deploy - seems pretty self-explanatory to me.

In the RFC thread on the CakePHP mailing list, someone mentioned they’d like to see rsync, but I’m trying to avoid having to external programs required to make the deployment work. Or, at least, use as few as possible. Anyhow, if you have any thoughts on this feel free to add them to the comments.

Article Tags >> CakePHP || Deployment || RFC

I’m certainly not the only person who has been blogging about this, but I thought I’d mention that a feature freeze is coming up for the next CakePHP 1.2 release, codenamed ‘DV’. My very modest contribution this time around is a patch to fix a problem with running ‘cake bake’ on Windows, where it was mangling the app path that a user would enter. Ticket 4495 if anyone is interested.

Anyhow, anyone who uses CakePHP or wants to help out can definitely get involved in the process by:

• Entering bugs into CakePHP’s trac if they don’t see them in there
• Contributing tests and/or patches for existing bugs
• Testing out the bleeding-edge versions of CakePHP that you can get from the SVN repository

There has been a lot of debate on the mailing list about both the direction of the project and the attitude of people on the mailing list. Well, as one of the people who gets to be involved in both sides (albeit a minor role in terms of contributing code) I can tell you that the project will continue moving forward, building on all the traction CakePHP has gotten. Maybe 1.2 has dragged on for a while, but isn’t that just a number anyway? Would people be reacting if it was Cake 1.7.2 or something like that?

What people don’t always see is the amount of work that goes into CakePHP by developers. Every morning when I log into my account on my MacBook, I update my copy of CakePHP from SVN. 99.999% of the time there is an update. These days, tests are being written like crazy and Tim’s awesome work in creating code coverage information and those things can only help the project as a whole get better. These are exciting times for anyone connected to the project, no doubt about that. No amount of CakePHP haters (you know who you are) are going to change that.

Secondly, people have to understand that a mailing list full of a lot of technical, highly-skilled people is not a friendly place for beginners. Sad, but true. I have answered many questions on the mailing list, some of them properly and some of them, well, let’s just say my nickname of GrumpyCanuck has been well-placed. Can we all be civil? Probably not. Should we be civil? Maybe. I think anyone who doesn’t understand the dynamics of the CakePHP list itself should go and read this. Forewarned is forearmed.

Article Tags >> CakePHP

This was *supposed* to be a post about my successes in getting the Rallyhat web service up and running on Google App Engine, but that’s not quite done yet. Instead, I will inform our spanish-speaking CakePHP users (and the more adventurous types who enjoy travel) that the CakeFest site as been updated to announce pre-registration and other information about CakeFest #2, which will be held in Buenos Aries, Argentina at the beginning of December.

All your favourite people from the CakePHP world will be there, although I might not be able to make it despite Mariano’s very convincing IM conversations. The organizer (the previously-mentioned Mariano) is a great guy, good contributor to the project, and I still like him despite the fact that he is a Windows user in an ocean of Mac fanbois. Maybe things will work out that I can go, but if you can make the trip it will be one of the most interesting conferences this year.

Article Tags >> CakeFest || CakeFest Hispania || CakePHP

Yes, it’s the day after May Day (workers of the world, unite!) and yes, I only managed to get one blog post done this week. So, it’s time for a round-up of the stuff I’ve been thinking about this week.

• For all the bleating I did on the CakePHP mailing list this week about using free and open software, the editor waffling continues and I was back to Komodo today. I needed the security blanket of an IDE today after spending way too much time with CSSEdit trying to get stuff lining up properly for a work project.
• Halfway through a code review project as a side gig. Old code, running on PHP 4.4.8 (those of you following me on Twitter saw me moaning about getting that working with CentOS on Parallels). Needless to say, the code is a mess but I have to actually talk about WHY it’s a mess and what can be done.
• Trying to see if I can get a caching plugin for WordPress to work with nginx. Not that I ever expect to get Dugg, but you never know. Almost there…
• Finally managed to get a Django app running properly inside the Google App Engine SDK. Work on that got torpedoed this week by two slow-pitch games…that got rained out…after me waiting around for 20 minutes or so. Next step is to build out my web service for Rallyhat. Should only be a few hours work (he said, not knowing now what he will know later)
• YASP (Yet Another Side Project) is going to get rolling this weekend. Some cool stuff using Amazon S3, integration with OpenID and PayPal. This time I actually have a plan to make some money.
• I’ve submitted my “Deployment Isn’t A 4 Letter Word” talk for ZendCon.
• Been updating the IBL web site to use the latest CakePHP goodies, meaning just refactoring a lot of stuff that was garbage and using newer techniques I discover via the mailing list and Nate Abele’s rantings.
• Special thanks to Travis Cline for sending me a copy of “xUnit Test Patterns” from my Amazon Wish list! Many thanks to a fellow budding Djangonaut for the gift.

Article Tags >> CakePHP || Chris' Brain || CSSEdit || Django || Komod || OpenID || Parallels || PayPal || Rallyhat || YASP || ZendCon

One of the 6 “rules” I came up with for my talk on application deployment at Open Web Vancouver was that the only difference between your development environment and your production environment should be data sets. My friend Juan, who works as the software architect at the adult dating site I used to work for, talked with me via IM about how that rule isn’t always true.

A little background on this is necessary. They are still using the same development setup today that was in place when I was there, in that they have given each developer a server that uses jails (this is a FreeBSD thing) to simulate having all the servers they would have in production. A great solution, one that is still great today. It made writing architecture-specific code (i.e. testing that an application server could talk to a queue processing server for a specific task) very simple. So, in this case I believe that they had a development environment that matches production as closely as you can get.

But then Juan mentioned that they are using Zend Platform on their production servers, and it wasn’t possible to give everyone a copy of Zend Platform on their development servers due to licensing. While Zend Platform is a great product, well, you’ve just introduced an extra variable into your application development and deployment process. Now, your development environment will never be the same as production and you are increasing the likelihood that you will encounter “production-only” bugs, which are the hardest to solve.

I have great respect for Juan (he’s near the top of my list of the smartest developers I’ve worked with), but rule #5 still the best one to follow. While you gain from using something like Zend Platform in production because of all the extras you get, you end up with a development environment very far from what is using in production. Just make sure that you understand the implications of that decision.

Also, there is something else hidden inside rule #5. If you have differences between environments, make sure you understand what those differences are and take steps to minimize their impact. For example, I run Apache2 + PHP 5.2.5 compiled from source + Postgres 8.25 from a package for OS-X & MySQL 5.0.45 from a package for OS-X on my laptop, which is my main development environment. On my VPS (which hosts this blog) I’m running Nginx + PHP 5.2.5 modified under Gentoo with USE flags + MySQL 5.0.54 under Gentoo. So, that means I’m running mod_php on my dev, but using FastCGI on my “production”.

Has this been a problem? Nothing yet *but* if I ever got serious about running something other than my blog I would definitely consider configuring my VPS to use Apache 2 and PHP with the same configuration options as I have in dev, so that I have consistency in environments. Django is recommending Apache + mod_python so I may be doing this sooner rather than later.

So, remember, the goal is to have your dev and production environments the same. But if you can’t have the same, you better be damn sure you understand what the differences are so you don’t end up saying stuff like this.

Article Tags >> Deployment