Late Night PC

After you've got PHP5 and Apache running on your Ubuntu development server, the next thing you'll want is Eclipse PDT. Shortly after that you'll need a debugger.

On Ubuntu 8.10, I set up Eclipse 3.4 (Ganymede) with the latest Release Candidate of PDT 2, it took forever because of some slow mirrors, but I'd recommend just buckling down and getting through it. Here's the step-by-step guide I found most useful. If Ubuntu someday gets PDT and Eclipse 3.4 in the repositories then just use that.

Waterloo has a Drupal developer group and they're getting together tomorrow night. James Walker (of Bryght/Rain City Studios/Lullabot fame) is going to be there talking about module development. It'd be a 3 hour drive for me to get to a 2 hour meet up but I seriously considered it. I've been learning module development off and on for a couple years now. I've actually done a couple for personal use. Sharing experience in a group like this is a lot of fun and you get a lot more insight in person than you can by just reading. I'd encourage anyone nearby to head on over and check it out.

Does Windsor have enough Drupal developers for a Drupal group? Do we have enough LAMP developers to support a group? I like the Windsor Blogger meetup we've been doing (more bloggers welcome, btw). The blogger meetup seems to have been going long enough now that it's a regular thing. I'm a little jealous of Waterloo, they have about the same population as Windsor. I think we should have enough developers to get together and share some ideas once in a while.

CakePHP uses the Prototype Javascript library for its ajax helper class but I've come to prefer jQuery. Prototype is a fine library too but I've just gotten used to jQuery.

A web application I'm working on needed a ttw html editor so I grabbed TinyMCE and copied in some of the example code and everything seemed to work fine at first glance. Unfortunately TinyMCE has an issue with jQuery's $(document).ready function and it also has an issue with saving via ajax in CakePHP.

There's a helpful page on the Bakery that outlines some issues you'll run into trying to get CakePHP & Prototype working with TinyMCE but it's a little out of date now (I'm using CakePHP 1.2RC1, TinyMCE 3.09 and jQuery 1.2.6 at the moment). I'll go through examples that illustrate how I solved the two problems I ran in to but I'm not going to explain everything you need to do ajax submissions with CakePHP.

CakePHP is a really nice MVC framework I've been using for a project I'm working on. I've been using one of the 1.2 betas for what seems like forever but I just now saw they've got a Release Candidate out as of a couple days ago. The MVC pattern fits a whole lot of applications or acts as glue for a lot of web apps where the main goals don't fit MVC. I find that CakePHP is fantastic for getting a lot of the monotonous code out of your way so you can focus your efforts on the important stuff. Here's the release note. You can download it from the main page at CakePHP.org. This framework has a few warts and like any young software, it will see API changes that break code. Don't expect it to solve every problem for you but it will give you a huge boost to start-up speed on building new applications. In the long run you have to remember it's a tool for you to build an application, not an application in and of itself. It's time for me to dive in now and start my upgrade, I hear some of the conditions on my find() calls will have to be fixed...

Here's a quick tip for PHP error reporting and display in development.

When a project is in the early stages of development you want to see all the error information you can. You probably want E_STRICT on especially when you're starting from scratch, to help avoid relying on deprecated behaviour. The E_STRICT flag is only available as of PHP 5 and is not included in E_ALL until PHP 5.2 (there's a little disagreement on php.net between the definition of E_ALL in this table and the earlier note about error_reporting on the same page).

In an early development project you also don't want to have to keep tailing log files to see the error messages. That's a pretty sure way to miss errors. So you want to set the display_errors flag on. You also want to control this on a per-project basis, since some projects will have legacy bugs that you're not fixing right now and those can be left spouting errors to logs until someday in the future when you decide to fix them.

I will one day come up with a better way to show PHP in my blog but in the meantime I'm not going to let that stop me from sharing a handy script I put together yesterday. I grabbed most of the code from examples on PHP.net but the examples as they were didn't do what I wanted. What I came up with is a short PHP script that shows the DBA handlers available then dumps the contents of the database file specified in the $db variable up at the top. It uses the "db4" handler, you can change that (and whatever else) to suit your needs. I made this the other day just to have a look in some of the LDAP database files that I was messing with yesterday. So here's the BDB dump script as text. Download it, rename it as .php and enjoy.

Motivation

Now that I've got an LDAP server up and running I'm trying to get my personal web server set up so it has a blanket authentication for my personal applications, static content and development stuff. The web applications I'm talking about aren't meant to be exposed to the public at large, they're not what you find here on Late Night PC Service or any of my other sites. These are things like PHP Calendar, Task Freak, SugarCRM, a bunch of development versions of apps I'm working on and some static content that might be a single html file or an image. I currently have a server that's accessible through DynDNS and I use basic HTTP authentication on it. The server runs Apache HTTPD 2.2 and has whatever modules I want on it. My next server is roughly the same but I want to make things a little more secure and a little simpler (at the same time no less). So my idea was to move to LDAP as the Authentication Provider and Digest as the Authentication Type.

• Rob's blog
• 5 comments
• Read more
• Buy Rob a coffee

I can think of three things I really want from my email: it should be easy to use, fast, and private. SquirrelMail gets me pretty close to those goals. It just got better today with the release of version 1.4.10. Somewhere between the last version I last installed and this one they've added support for multiple identities - that is to say that you can have more than one return address. If you want to set it up on a site you host at 1and1, there's an FAQ at 1and1 on how to do exactly that. Unfortunately they haven't updated it since they changed their outgoing (SMTP) mailservers to require authentication. I got the hint because it's mentioned for other email clients. Since SquirrelMail is really just an IMAP email client written in PHP, the same rules apply. What worked for me was this change in SquirrelMail's config/config.php: $smtp_auth_mech = 'login'; The default was none. So overall all you need to change in the default config file to make SquirrelMail work with mail at 1and1 are the $domain, $smtpServerAddress (smtp.1and1.com) and $imapServerAddress (imap.1and1.com). The other interesting thing is that since SquirrelMail is just an email client, you don't have to run it on your 1and1 web server to get your 1and1 mail. If you have a home server or one hosted somewhere else, you could use the same configuration file and SquirrelMail will go get your mail just like any other client would. Depending on how you use your mail you might find this a little more convenient and possibly faster than using your web server.

Johan and Jeff have started a discussion on the relative merits of JSON/JSONP. I think it's time I threw my two bits in. There are a couple compelling features of JSON as a format to Javascript coders (I count myself in here). Johan talks about getting around the same-origin policy. I understand the frustration, but I feel uncomfortable opening the door for someone else to execute whatever code they deem fit on my visitors' browsers. I know they're not supposed to, but the can. It's a lot of trust. It's true that Javascript executes in a sandbox, but the code in question doesn't have to be intentionally "bad" as Jeff implied. It could be accidentally bad code. Accidentally bad code happens a lot more often than intentionally bad code. It can be worse because it's Accidental. Accidentally bad code can excersise memory leaks or any other bugs in a browser. I'm not saying that I write better code than everyone else, just that I can debug more easily if it's all served from my site. Mixing code and data makes things tougher. Not that we haven't already gone pretty far down that road. After all, Javascript in a web page is executable code mixed in data. That said, JSON is clearly a simpler format to process on the client side for JS engines that are not inherently XML-aware. This is changing with support for XPath showing up in browsers, so JSON might be a shortcut for now. As a content-provider, it looks pretty simple to create a JSON feed from an existing XML feed, so I've got no issues with supporting it that way. Well not at first glance. Then again, the feed isn't guaranteed to be valid Javascript syntax though if I don't test every feed with a Javascript parser. If I'm doing that and the client also has to validate what I've sent them then suddenly we're both doing a lot more work. What's more, if users start throwing in references to their own scripts that the server producing the feed can't see, then how can the server possibly guarantee a valid feed? That's the problem with formats that look easy. Most of the time they end up needing some kind of patching later that starts quickly to look like a kludge. JSON's not the first place this has shown up, just the latest. I mean PHP has had plenty of growing pains and broken plenty of existing code in order to get more secure default behaviour in place. Things like register_globals and the ability to reference a variable without defining it first are places that PHP used the normal behaviour for a script, but that normal behaviour caused big security issues when the language was used to build huge applications. And don't even get me started on the nightmare of escaping script embedded in text embedded in XML embedded in PHP. Each of those started as an idea to make things simpler and more readable. When shorthand syntaxes like JSON crop up it indicates that developers feel that there's too much overhead in dealing with the predominent formats: Atom and RSS XML feeds. Someone could have come up with an equivalent PHP syntax. There's as much PHP code handling XML out there as there is Javascript handling XML. PHP has an eval() function analagous to Javascript. PHP supports associative arrays and objects. Why not feed my PHP script with PHP code? I don't know the answer for sure, but I'd guess that it has to do with the fact that PHP has an established method (well, many established methods) for handling XML. JSON just seems to be a request for data that's easier to parse. My answer? I guess I believe in proxying on my own server and getting the data ready for my clients in some Javascript that's easy to run.

This one's for the casual game developers and the SVG folks I've been working off and on (okay, mostly off) on a simple puzzle game done in SVG and Javascript. I started on it almost a year ago and the idea was to just put up something simple as a guide to building SVG games. I got something that sort of worked pretty easily, but each time I added a feature it seemed like I had to rewrite the whole game. I guess that's just part of developing in a green field. One of the issues that bothered me most throughout the work I did was that I was transforming level files from a generic XML to SVG in the browser. I knew that every browser that downloads the level would perform the exact same transformations and every user would have to wait a few seconds while it happened. I also had to deal with the rather hairy Javascript code that handled those transformations and debug it every time it broke on one of the platforms I'm trying to support. Not every browser has a debugger as accessible as Venkman (and at the time I don't think there was a Venkman version for Deer Park). I'd rewrite the code, get a little more capability in it and tweak it for a day or two, then shelf it again until Jeff or Candace bugged me again to stop talking about it and get something done. Okay, so I finally did another rewrite on it a month or so ago that fixes the issue that I'd avoided for so long. See, I'd wanted to keep it in just Javascript and SVG since I thought that made things simpler. There's no build step that way and the design of the game is more obvious. Scripting languages don't generally need the kind of development pipeline that compiled languages do. In C or C++ the source code has to be built before results can be seen. In Javascript or HTML, the source is the executable. When XML is used to store information though, there's always some kind of interpretation that happens to display it. That can happen right when it's accessed (like viewing an SVG or XHTML document) or there can be interpretation first that creates another document that's actually viewed. The latter transformation can be done with XSLT.