I’ve never had a great love for PHP the Language. It seems like if someone wanted functionality into the core language, they just vomited it up inside the code base, submitted it, and it was accepted. They are trying to make this better in the core, but alas it’s still too easy to do dumb things. And let’s not get started on the security problems.

But PHP the Platform is much more interesting to me. You can deploy PHP applications in just about any cheap web host solution. Run it inside of Apache via mod_php or maybe under FastCGI — doesn’t matter. It really is a write-once, run anywhere language. And lots of big applications use it — WordPress, Joomla, osCommerce, etc. You may not like the Language, but since it is married to the Platform, the Language is here to say.

I’ve mucked with CakePHP a time or two. It’s an interesting project to say the least. It’s a web development framework a la Ruby on Rails or Django, but for PHP. It strictly enforces the MVC pattern, which leans itself to more maintainable code. But, unlike RoR or Django, the Views are not written in a whole new templating language, but in PHP itself, and it gives you the objects that have your data in it to display.

Another interesting thing about CakePHP is how it creates Models. In RoR or Django, you create fields in Model objects and then run a script and it creates the database for you. In CakePHP, you just name your model appropriately and, when CakePHP needs that Model, it does a DESCRIBE on the table and populates the data points accordingly. This is good and bad — it means your database is the king. It also means that you have to follow strict set of conventions or configure everything in your Model object as to what is what. This means that you could use CakePHP with any database structure — in theory.  More on conventions later.

Anyway, CakePHP has been in the back of my mind for a year or so (at least) when I got approached with an opportunity to do a POC of a simple CRUD application. The POC would be hosted on a cheapo shared hosting provider, so anything like Django or Rails was out. So I dug out CakePHP and finished the POC. When it was over, the customer liked it and we really discovered what he was after — and it wasn’t just a simple CRUD application anymore! When we were specing it out and decided that the customer needed to get some high-quality, dedicated hosting, I asked if we wanted to write the real thing in Django or RoR. It was decided no for the simple thing that PHP developers are much easier to find. If I was unavailable and fixes were needed, they could easily find a PHP developer to do it. Not necessarily so with Django and with RoR (though I think there are more RoR developers than Django, but there are still more PHP people out there!).

So I put CakePHP through some tests and am still using it. Is it my favorite? No — that’s still Django. But it’s very livable, especially under the constraints I was in.  And, hey, it’s making PHP relatively painless to code in, and it’s not even making me feel dirty.

One thing nice about CakePHP is their console application, although they don’t tell you about that until you are on page, like, 100 of their docs. There is no mention of it in their tutorial! Blech!  It’s pretty easy though:

cake bake <name>

which will bring up a menu and you choose Model, View, or Controller.  You can also do:

cake bake model <name>
cake bake view <name>
cake bake controller <name>

More information here.

One thing about CakePHP that bugs me (and, actually, it bugs me about RoR, too) is that the naming conventions aren’t conventions I would use.   I finally  found this page which explains all the conventions in on place.  Also notice that it’s on the last page of their documentation.

This seems sort of a mixed review, but it’s not.  If you are working on a PHP application from scratch, it would behove you to at least look at CakePHP.  I like it — for PHP.  Would I rather be doing Django? Yes — but I can’t always be able to do that.  It’s good to have a framework on a ubiquitous, yet annoying,  language.

I’ve been helping 5Q Communications with some Django work in the past few weeks and will be continuing to work with them for a while.  I was excited when we started talking together  not just because of Django but because they have a lot of good ideas on how the web should work and how to properly treat clients.

I wasn’t new to Django but it had been a while since I have dug deep into it. More and better tools had been developed and I had to add things to my development/troubleshooting suite.  And so here is my list — some I have been using for a while, some 5Q told me about, and some I discovered on my own.

• EasyInstall – this makes installing Python packages so much easier.  Even if they don’t have their package on PyPi, you can download, uncompress it, and then it’s simply easy_install directory_name
• VirtualEnv – this is an absolute must, especially if you have different version of Django or other tools for different projects.   And, once you are in an VirtualEnv environment,  EasyInstall will install files to your Virtual Python library.
• iPython –Installing this will give you the power of iPython when you run manage.py shell.  And you want that — you really do.
• django-logging — This is a wonderful little middleware that will put all your logging statements at the bottom of the web page.  With another option, it will log all the SQL that Django generates for the database, which was incrediably useful for what I was working on.
• south – This gives you a lot of the power of Rails’ migrations in Django.  It’s not 100% there yet, but it’s close. You can even see  my patches that fix problems I had with it.
• ack — Not just for Django but for everything.  This grep replacement has become a requirement for any of my search-the-codebase tasks.

The easiest and best way to set proxy information on your Linux/Unix machine is with the http_proxy environment variable in your ~/.bashrc, ~/.zshrc, or whatever your favorite shell’s configuration file is.  Set it like this:

http://user:password@proxy-server:portnum

In my brief bit of experimentation, the follow important (to me, at least) command-line tools use http_proxy:

1. wget
2. Python easy_install
3. curl

I’ve been a Unix user for 14 years — why did I take me so long to figure this out?

Last Friday evening, I got the type of call that no one wants  to get — or make, for that matter.  It was a customer I hadn’t heard from in a while. Last time I was there I setup Windows Networking in their office. In other words, I made a Workgroup, folders to share their documents, and a shared printer.  I also recommended Linux and Samba in the medium future too, instead of Vista.  Yes, they have Vista everywhere!

Well, this call was that they got a new wireless router and, as soon as they put it in, all the file sharing was disabled and they were no longer able to print.  Seemed strange to me, but we made a time for me to go over there and get things back to normal.

On Saturday morning, I asked them why they got a new router, since the other one was quite new.  They said it was because their laptops kept losing connections and someone advised them to get a new wireless router.   This is a known problem with Visa and have a friend that is having this problem as I write this. He told me that the overall solution was to get a new router as well, and he searched exhaustively for another solution but nothing else has worked. Therefore, I knew they were on the right track.  And my customer correctly bought a Linksys, which is really the only brand of wireless router I will buy.

The first thing I did verify that the Internet was working (because if  the router isn’t routing, then that’s a big problem).  Then I logged  into their router to see if something silly was turned on by default that would prevent the machines from talking internally.  Nope, no problem there.

The domain/file server was working fine.  So I went to another workstation and it asked me for my user credentials (I made one user for all the file shares to make it easy on them).  Yep, it wouldn’t authenticate, even though I knew I was using the right password.  I went back to the domain server and updated the password on the common user — using the same password as before. Sure enough, that worked — now all machines could get to the shared folders.  Step One done.

The printer was harder to figure out.  I’m still not sure what happened, or why it worked, but this is how I got them going again.  From each client machine:

1. Goto Start->Network->DomainName->Printers
2. Right-click on the printer in question and choose  “Sharing”
3. Vista will give some bogus message about “Installing Drivers” which it doesn’t even need to do, since the only thing that changed on the network was the router.
4. Print a test page.

This worked fine on the workstations, but the laptops wanted to be a little more stubborn.  So I had to do this in addition to the above:

1. Goto Start-> Control Panel, then click “Classic View” on the left side.
2. Click Printers
3. You will see icons of all sorts of printers — there may be two printers that have the same name — one of which says “on ServerName.
4. Right-click on the  printer that does not say ServerName and then choose “Delete”. The icon won’t disappear but it will say “Deleted — Offline”
5. Now Right-click on the printer  that does say ServerName and then choose “Default”
6. Again, try a test page.

And that worked!!

But why did Vista forget?  Why did a simple router change cause such confusion in the Workgroup sharing?  I really feel having a Linux/Samba machine as the domain server as well as the file and print server would have prevented this problem.

I’ve been struggling with the speed of my WordPress blogs, both on my personal blog and here.  My web host for these two domains is notorious for bad MySQL implementations, but I knew that wasn’t my whole problem.  I tried to get WP Super Cache to solve some of these problems, but that didn’t quite do what I thought it should have.

I’ve been looking for ideas and found a little tweak here and a little tweak there but nothing really helped.   Tonight I was looking again and found this and I’m like, “You’ve got to be kidding me!”   It made perfect sense — I just never thought about it before.  To summarize the steps:

1. Log into PhpMySqlAdmin.
2. Click on the database name on the left side.
3. On the right hand side,  your tables will be listed. Scroll all the way down and click on the  “Check all” link.
4. Make sure all database tables are checked and then from the dropdown next to it, carefully select “Optimize table”.
5. Click the “Go” button

You can issue the optimize command from a MySQL prompt as well, but most web hosts will only give you PhpMySqlAdmin.

Having to do this makes perfect sense.  You’ve created your tables,  put data in them, and the WordPress has been doing query after query on them.  So now you have a pattern of usage and so MySQL could use that information to query the data more effectively.  And that is what optimize is for, especially since WordPress is fully of VARCHAR and TEXT columns.

So, if your WordPress blog is loading slow, you really try running optimize on the tables.