» Download FireFox 3 and install it on my Mac (my Ubuntu machine switched to FF3 weeks ago)
» Download this possibly very interesting PHP Debug thingy for the Mac
Hmm, nice step: the Zend Framework will be included in the repositories for Ubuntu Hardy Heron, scheduled for release in April. Not that the average developer wouldn’t be able to obtain a copy of ZF otherwise, but it’s nice that it will be included.
Let’s hope updates to the Zend Framework will be ported rapidly into Ubuntu, so Ubuntu/ZF users wille be able to truly depend on the packaging system.
It’s those little things: in PHP 5.3, the constant
__DIR__ will be available. Of course, this is the same as the output from
dirname(__FILE__), but it makes life just that little bit easier.
For the last two months, I have been using a new Zend product as my default PHP editor. I haven’t blogged anything about it, because until last week, it was a closed beta.
At ZendCon ’07, however, the beta of Zend Studio Neon (with Neon being the beta-name) was released to the public, inviting everyone who’s interested to the party. So now it’s okay to blog about it, and I would like to take this opportunity to name a few things that might cause Neon to become my default editor, permanently.
1. Custom formatting
In the classic Zend Studio, you can select a piece of code and have Studio re-do the indenting of that section for you. Very handy when you’ve messed up your code in some way, or several CVS commits from different people have thrown the structure out of whack. In Neon, this feature works even better:
I can configure exactly how I want my code to look: where I want my spaces, where the braces should be placed, how the code needs to be indented and lots more. I can configure the formatter to follow my personal coding standards, select a piece of code and have Neon apply my standards to the selection. Brilliant!
However, Neon doesn’t remember my preferences, so I have to export them whenever I make a change and import them every time I start Neon. Also, a few bits of my prefs cannot be configured, such as the way arrays should look when you divide the declaration over multiple lines. But I expect Zend to be looking into that, as several of the closed-beta testers have already mentioned it in the testers group.
2. Easy compare and CVS-integration
When Neon recognises a project to be a checkout of a CVS-module, several options are added to the navigator (the outline of files and folders on the left side of the screen). To name a few:
- Every file that has been changed is visually marked as being different from CVS. This makes it easy to find what you have changed and might be ready to be commited into CVS.
- I can update and commit from the navigator. The classic Studio had this as well, but it was useless because the following feature was missing:
- Compare! I can right-click a file and compare it to the latest version from CVS, or a specific revision, or just compare it to another file I also selected. The ability to compare makes it possible to check if the file I want to commit is ready to be commited: I can see all the changes and if I left in some junk (an echo, some commented-out code, you name it), it shows up as a difference and I can edit it while still in the compare screen. Brilliant! I’m used to the way Kompare works, and frankly that one has a better overview of the changes, but Neon makes a good second best, especially when combined with the CVS options.
- Neon acts as a complete CVS client. I can change the revision of a file, create branches, browse the history of a file, commit several files at once and more.
3. It’s more than a PHP editor
4. Choose the PHP version per project
In the classic Zend Studio, I have to change the PHP version from 4 to 5 and back when working with different projects. In Neon, I can configure this in the project-specific settings, instead of editor-wide. Quite a time-saver, as it prevents me from looking surprised at my editor, wondering why it thinks a bit of code has an error when it clearly doesn’t.
5. Project-wide error checking
When I open a project, Neon checks all the files, both PHP and other types, for errors. When it finds them, the erroneous file is marked as such in the navigator, and so are all the folders above it. I can easily follow the path in the navigator to find the file with the error, fix it and when saved, the mark disappears. And of course I can commit it immediately.
The downside to this is a heavier editor, though. When a project resides on a remote server, and Neon startes opening and parsing them all, my computer gets very, very slow due to the heavy traffic. In fact, Neon already is very memory-consuming and needs to be shut down if I want to open something else that’s big in memory (a video player, for instance). I really hope Zend is able to do something about that.
There you have it, five things I like. There are also things I don’t like: the memory Neon consumes, the multitude of ‘perspectives’, editors, outlines and other screens I don’t really ‘get’ yet, the fact that even a closed project shows up in the navigator and some other minor things. But those are all little bumps in the road, and as Neon is still in beta, I’m not really worrying about it.
Whenever I need to make large (laaaarge) changes in code that has been sitting in its place for a while, an exciting and a bit frightening thought enters my mind: “throw it all out and start from scratch”. Exciting, because starting to build something that you know is gonna be great simply rocks. Fresh, clean code without months or years of editing history is just lovely to work with. Frightening, because you know how long it took to create the existing code, you know how long other rewrites took to do and you know that this is no exception. Also, you know you are gonna have to address all the problems you had in the first run.
But the feeling that you should start from scratch is always there. In my own forum software, Replique, I already did this twice (although the second was a partial rewrite). With reasons and, fortunately, the desired result: a better application. In a CMS that runs at a website I work for, we also did it twice. And it will probably happen again in a few years.
And this is why. Just this afternoon, I stumbled upon Derek Sivers‘s weblog, who tried to rewrite a website in Ruby but failed miserably. Rafe Colburn replied to his and linked to a piece by Joel Spolsky, from which I quote:
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
And that is so true. As is probably true for most developers, my coding style has evolved over the years. Indentation, the placing of braces, the naming of variables and so on, when I look at how I did in a few years ago I scare myself. Did I really write this? Yes I did.
And it’s not just the style. Over the years, if you’re (aiming to be) a professional developer, you learn more and more new stuff. And every now and then there’s the urge to try out those new things. And every now and then one of those urges makes it into your code and stays there for years. When you look at it, years later, you know that you should have resisted the urge. Not that it’s bad code, of course not, you’re a pro. No, it’s just.. silly. The old method of doing whatever it was that that code did was just as good. You didn’t keep it simple, stupid.
The Big Question you should ask yourself before starting a rewrite is: am I doing this because I want to, or because the changes I want to make need me to? Is it so damn hard to make the changes in the existing code? Does it hurt to just refactor the bits and pieces you are going to use? Will it hurt the performance when you don’t do the rewrite? Okay then, do it. If not: just make the changes and be happy about it not costing you time you could use for really new, fresh projects.
I’m working on a piece of PHP-code, and I need to examine if there are any bottlenecks in it. It’s not much code, about 170 lines, but there are quite some includes, object instantations, conditions, etcetera, and I can’t easily oversee if there’s anything that might cause a web server’s load to rise too much if this particular piece of code gets executed hundreds of times a second (I know that that is certainly going to happen).
So, what do I do? I do a quick check: do I have any debuggers or profilers running in the background which I can use to learn about this code? And I find there’s a Zend Debugger present, because I run a development version of Zend Platform.
Using get_extension_funcs() I know that the debugger has six functions I maybe could use, but I don’t know what they do. Can they give me some useful information? I don’t know. So I just call the functions to try them out. Nothing of use comes of it. So I decide to look up some documentation on these six functions.
Nothing on PHP.net. Nothing on Zend.com. Nothing on weblogs where Zend Debugger is mentioned. Nothing on forums. Nowhere can I find documentation on how to use Zend Debugger from my code. Doesn’t anyone use the debugger? Is it only meant for use in Zend Platform and IDE’s like the Eclipse PDT thing?
Does anyone know?
Well, that was easy. I was looking for a way to fetch HTTP request headers in PHP, for the implementation of Conditional GET in an RSS module. PHP has this function, apache_request_headers(), which returns an array containing all the headers you could possibly need. Problem solved!
But; when the software you’re working on (in my case a content management system) has to work on both Linux/Apache and Windows/IIS servers, there’s a bit of a problem: Apache-functions won’t work if there’s no Apache to work with. Fortunately, you don’t need functions to fetch specific headers: PHP has already gathered them for you.
When a client requests a PHP-driven page on your web server, you can check for request headers in the $_SERVER array. For instance, the If-Modified-Since header is stored in $_SERVER['HTTP_IF_MODIFIED_SINCE']. This will work for every header you can think of: PHP just converts them all to the right variable. A header This-One-Doesnt-Exist becomes $_SERVER['THIS_ONE_DOESNT_EXIST'] in PHP code. Just like that!