I have made a couple of posts about how to use Phing to update your SVN-version-controlled website automatically, through FTP. This involved making a couple of new tasks to interact with SVN, as well as making some changes to Phing’s FtpDeploy task.
A few things to report about those today, mainly that so far I had only put the source code of those tasks in this blog, but something I (probably) should have done from the start was to put them in a repository, thus allowing easier access to the code, either for you to use them or modify them and share your own changes.
This is now done.
A few days ago I made a post about how to use Phing to automatically update your SVN-version-controlled website through FTP. It works, but, as Joe Constant noted in the comments, it doesn’t support the case of deleted files. Let’s see how we can fix this…
If you’re working on a PHP project, like with any other project, probably comes a time when you need to “build a new release,” e.g. update the production web site with the latest version of the code. And doing the whole thing manually isn’t the most efficient way to get things done, especially if you’re lazy, or have to do that every once in a while, over a long period of time.
There are a few softwares out there to take care of that to-do list for you, one of them, running on PHP, is called Phing, for PHing Is Not GNU make. It is a PHP build tool based on Apache Ant, and it will allow you to save lots of time. It’s especially true if you use SVN or Git, since both are supported; Support for other VCS, such as Mercurial, are planned, and for those who cannot wait, the project is meant to be easily extended.
If you follow a little what happens in the PHP world, chances are you have heard discussions about private vs protected scopes/methods. This is mostly due to the recent decision of Symfony2 to switch all protected class methods to private and only switch them back if/when the need arise, which wasn’t without reactions. This did lead to many discussions, even outside the Symfony community, with many people on either side.
As it so happens, it is a debate that never ends question I had been thinking about not that long ago, as I was gonna start to work on a little (open-source) project of my own, that I wanted to be easily extendable. After some reading and thinking, I eventually decided to go with privates. As many discussions have surfaced recently on the topic, I’ve been keeping an eye on a few of them, reading arguments from both sides and, while I never really had as a strong a stance as others, I always stayed happy with my choice.
When you’re writing oriented-object code, it’s all about objects, therefore one thing you’re sure to be doing at some point during the run of the application is to create objects. Creating objects is nothing complicated, but using the keyword new might not (always) be the best of things.
There are different reasons that can make you wonder about other options; In my case, there were mainly two of them:
1. I wanted to provide a way to use aliases instead of class names
2. I wanted to be able to use mocked objects instead, while testing
Over the past few days I’ve been using PHPUnit to write tests, lots of them, and while doing I started to see a few patterns of things I kept doing over & over again. Being lazy by nature, I wondered if there could be a way to make those things a bit easier/quicker for me. This is how I created an helper class for assertions, that for instance allowed me to go from $this->assertEquals(42, $answer); to a quicker is::eq(42, $answer);
Another thing I found myself doing repeatedly was creating mocked objects, and setting expectations of which methods should (and/or should not) be called. PHPUnit provides a nice API to achieve all that easily, but because I was doing the same sort of things often, I thought I might make things a little better.
Lately I’ve been writing a few tests (using PHPUnit), and when you do there’s one thing you end up doing a lot, which is typing $this-> whenever you need to do pretty much anything. It’s not that bad (and PHP can be quite verbose itself) but it can become a bit of a bore I guess, especially after a while.
Apparently, it’s been one of the things PHPUnit’s author Sebastian Bergmann has been asked about a lot, so much so that eventually he added a way to type less of those, by introducing a new set of functions. This wasn’t well received by the community, for understandable reasons, such as those functions clutter the main namespace and illustrate “bad practice” (in the oriented object world) while PHPUnit is all about the exact opposite.
Those were valid points, and for a while that feature was even temporarily removed. So.. now what? Back to typing all those $this-> over & over again? Maybe not.
Recently I found myself in need of something that seems to be quite unusual: I needed to get the key (and value) of the next item in an associative array. Now before you mention the function next, let me explain why it couldn’t be used in this case.
Like all the other functions of the same kind (current, key, etc) they work using the array pointer. In this particular case it’s not that it wasn’t possible to rely on the pointer, but that the function I needed would be given an (associative) array and a key, asking for the next key (and item) in the array, or false if there weren’t any. (It wasn’t about using reference or anything to “preserve” the pointer, the array pointer was not on the item whose key was passed as second parameter.)
Testing is a big part of development, and (especially) when you’re writing oriented-object code, it’s “easy” to write tests, particularly with the help/use of great tools such as PHPUnit. Test Driven Development (TDD) means that instead of writing your code first, and then testing it, you should do things the other way around. Write your tests first, and then write code that will pass the tests. That way, not only are you sure the code you created works as expected, but whenever you’ll have to make some modifications, all it will take to ensure you didn’t break anything is run the tests again.