/private/tmp/pear/download/tidy-1.2/tidy.c:463: warning: pointer targets in initialization differ in signedness
/private/tmp/pear/download/tidy-1.2/tidy.c: In function 'zif_tidy_parse_file':
/private/tmp/pear/download/tidy-1.2/tidy.c:490: warning: pointer targets in passing argument 2 of 'tidyBufAttach' differ in signedness
make: *** [tidy.lo] Error 1
ERROR: `make' failed


To fix it (thanks to dams at PHP):

“Get the libtidy from the CVS on their project. Compile and install it, then modify /usr/include/tidy/platform.h:

on line 530 comment [out] the line:

typedef unsigned long ulong;”

After this, tidy should install properly.

References:

http://bugs.php.net/bug.php?id=36164&edit=1

http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3390328

In ploof I’m trying to solve this problem with diffs and patches for the core files.

The ploof command, available on the command line, provides this functionality. Even though ploof doesn’t have any releases (proper), you can tell your ploof export to update to a particular revision:

./ploof update trunk

or

./ploof update 1.0

(note that as of this writing there is no 1.0 version, so trunk is all you get)

The essential strategy is to export another version in the resource subdirectory, run a diff against what you currently have installed, and patch it automatically.

Here’s the code:

function generate_patch($version= "trunk")
{
    if (opendir("resource/updates"))
        exec("rm -rf resource/updates");

    // export a copy of the code off the server:
    exec("mkdir resource/updates");
    if ($version != "trunk")
        $version= "branches/".$version;

    exec("svn export http://ploof.googlecode.com/svn/$version ./resource/updates/svn");

    // build patch files:
    exec("diff -rupN -x .svn ./core ./resource/updates/svn/core > ./resource/updates/core.patch");
    exec("diff -rupN -x .svn ./config/config.default.php ./resource/updates/svn/config/config.default.php > ./resource/updates/config.patch");
    exec("diff -rupN -x .svn ./ploof ./resource/updates/svn/ploof > ./resource/updates/ploof.patch");
}

function patch()
{
    // apply the patches:
    exec("patch -p1 < ./resource/updates/core.patch");
    exec("patch -p1 < ./resource/updates/config.patch");
    exec("patch -p1 < ./resource/updates/ploof.patch");
}
function update($version= "trunk")
{
    generate_patch($version);
    patch();
}

I separated the update() method into patch() and generate_patch() for testing purposes.

This isn’t perfect (it needs to address core CSS/HSS/JS merging, and needs to ignore other VCS’s), but it’s a start toward better framework integration into our normal development workflow.

First of all, you’ll want to download all the proper versions of the utilities you want to use and move them onto a file share somewhere which easily mountable. I just got a NetGear ReadyNAS which I like a lot. You’ll want to keep copies of the exact versions you use because a lot of folks are hiding their older versions.

Now, about that Makefile. I use Fedora Core, and when I create a clean server it doesn’t have much on it. So let’s define a macro for dependencies that’s easy to maintain:

DEPS=openldap.i386 gcc gd.i386 gd-devel libjpeg.i386 libjpeg-devel.i386

$(DEPS) :
	if test -z `yum list | grep ^$@ | grep installed | sed -e "s/ //g"`; then\
		yum -y install $@; \
	fi;

installdeps: $(DEPS)

Now calling make installdeps will loop through find and install your dependencies.

How does this work? Let’s take a look:

DEPS=[a list]

$(DEPS):
        [some command line entries]

installdeps: $(DEPS)

Make sees your list (called a macro) assigned to DEPS. Just below that, if it sees your exact list of dependencies (dereferenced in Make via $(variable)), it will run the command line entries for each item in your list (that’s the cool part) — this is called the target. But you don’t want to type all those dependencies again (a la make openldap.i386 gcc etc etc...), so we make a second target that invokes the first: installdeps.

Note the formatting, Make can behave like Python — if it’s on the same line as the target, it will be called prior to running anything below the target (you can also list as many dependencies as you need). The commands below the target must be indented with tabs.

In part 2 I’ll go over some conditional syntax and (what I believe to be) some best practices.

So why bother? Mostly because I don’t like a lot of the frameworks out there. I use a custom rolled framework at AirAdvice that I built from the ground up, so I have some experience, and we, as developers, are always looking to build a better mousetrap. But what finally sent me over the edge is that I have enough of a backlog of personal projects that it makes sense to build something to expedite that process. I want something that is easy for designers, and something that allows me to get projects off the ground as efficiently as possible.

Here’s some things I plan on building into ploof (and there will probably be more, but these are the things I could think of that I wanted as we were driving home from Bandon, Oregon this weekend):

• CSS framework
• PHP 5.3 compatible
• Migrations
• Rapid build out from a database (auto creation of classes and relationships)
• Namespaces for partials
• Record and view caching
• Tuple HABTM
• Form handling that makes sense
• PHPUnit

I haven’t checked anything in yet, but it’s hosted on Google Code. More to follow.

I’ve tried to do formalized processes on obtaining VOC, but have never been very happy with them. Looking back at the formalized documents after going through a couple of revisions with a product can’t justify the time and expenditure to create them — it is truly the blind leading the blind if you are trying to break into a new market. Not that there is a lot of choice there, but rapid prototyping may be a less all or nothing proposition, especially for a small team with limited resources vs. teams that have people devoted to six sigma and the like.

I’ve also constructed round-tables of various ‘expert’ users to provide feedback, but the feedback from experts usually ignores the fact that most users are ‘perpetual intermediates’. And while the feedback is usually useful, it isn’t always easily enacted. Doing a round-table at the end of a product means that you can do a few tweaks, but no major overhauls, and doing continuous round-tables is difficult to arrange if your clients are busy.

There is another option, although it also has a few sticking points: utilize your sales and support teams. They talk to your customers daily. Sales should know what people are asking for; support should know what customer’s pain points are. Again, this only really works with an existing product. And the other downfall can be one of self-service instead of customer service. It may be in the support person’s best interest to limit how much support they have to give, so instead of fixing a fundamental product problem they may advise patching a work around instead. Sales may advocate building something peripheral because people are asking for it, while missing the boat on how it fits into the total package.

VOC is more art form than science, but that’s what makes it such an interesting topic, and certainly one open for debate.

So what happens if you need to, er, want to roll all these interconnected systems back?

Obviously we use source code control for, well, source code and tack version numbers onto our other apps. But usually they are inextricably linked. A database migration might blow away an equipment type by renaming it, and the new energy modeling software will only recognize this new equipment type. What version was the version of the modeling software that matches the rolled back source code? Quickly now. Your servers are down.

On the one hand it seems like this would be a simple thing to solve. We already track what migration we are on in the database. We could track the application versions of the compiled with the migration numbers, a tag or commit number, and a date stamp for a release date.

This is handy as a reference for the tech when the proverbial monkey poo hits the proverbial fan, but he would still have to reference this table by hand when doing a manual rollback.

Is there a way to automate these types of references, other than some amalgamation of Windows batch and *nix makefiles? I suppose ant could be used across both; we already use it for PhpUnderControl to see when I break unit tests, and watch our code coverage grow. But that doesn’t really centralize command and control if, for example, in one keystroke I wanted to roll back a variety of systems, and make sure that all systems were rolled back together.

Anybody know of such a system or a homegrown procedure that can handle it?

Maybe I’ll release my own like everyone else has, and stop complaining (maybe it’s a good chance to learn all the new widgets in PHP5.3….)

sprintf(_(“The value is: %s”), $value);

You can compile in comments which will show in your output file:

xgettext –add-comments=///

Static items in PHP can be problematic:

class foo {
static $bar = _(“translate”);
}

will produce a parse error. For static items, we’ve moved them below the class so they are still set upon file inclusion:

class foo {
static $bar;
}
foo::$bar = _(“translate”);

Another related problem: default method parameters will also produce a parse error.

function upgrade($upgradable = _(“default”)) { return true; }

These will also need to be moved to defaults inside the method for PHP to play nicely with gettext.