Archive for the ‘Programming’ Category

DocBook for PHP, a tool you can’t afford to ignore

Friday, November 27th, 2009

You’ve heard it before but it’s worth mentioning again - you have to properly document you code! Programmers realized this back in the 1960s when the first industrial programming languages were defined, they came up with something called “comment lines”. For 27 years this was apparently considered enough, but in 1993 the first documentation generator was created by Eric Artzt, called Autoduck. Two years later, in 1995, a more commonly known documentation generator was released by Sun Microsystems, called Javadoc. In the year 2000 a similar generator was created by Joshua Eichorn for PHP, called the phpDocumentor and it’s this documentation generator that is the reason why I’m writing this post.

I’ve been using phpDocumentor for quite some time now but only to parse my classes to get an overview. Now I’m building a framework. I soon realized that writing a tutorial for each class wasn’t what I wanted. It’s always good with examples but it doesn’t show how a bunch of classes work together to solve a larger problem. I want to collect all documentation in one place so it’s impractical to write tutorials stored in some other place. So, for the first time I decided I’d take a look at the possibility to use external documentation with phpDocumentor.

DocBook “provides a system for writing structured documents using SGML or XML”, as stated in the preface in the DocBook documentation. It’s used in development projects like PHP and KDE. Although the PEAR manual states that DocBook should be used, nothing is said about the document type and no example is given. Instead, I found an short example in the phpDocumentor quickstart document. A more elementary example than that is hard to find, but if you combine that with the documentation about how you create a reference page in the DocBook documentation you’ll understand what you are doing. You don’t have to use the <refentry> top-level element but it is recommended if your code may become part of PEAR.

Since the phpDocumentor parses the DocBook file you can use some of the phpDocumentor syntax in your external documentation. It’s mainly two tags that you’ll use in your external documentation, and that’s the {@id} and {@toc} tags. The {@link} may also be useful to link between documents. There’s no need for me to dig any deeper in this, you can read a great tutorial about how to write tutorials for PHP at the phpDocumentor site.

Good luck!

Object oriented PHP - a disappointment

Thursday, July 31st, 2008

It’s no news that PHP supports objects, and has been for a while now. Even if objects in PHP, before version 5, internally is represented as an array, with the result that all methods and properties are public, this was rapidly accepted and used by the community. As of PHP 5 the Zend Engine was rewritten and got a “robust and extensible object model”. This sounds good and at least it got my hopes up for OOP in PHP. It doesn’t really matter but I can mention that I’m currently running Apache 2.2.9 and PHP 5.2.6 on Windows XP, that’s the versions used for running the code below.

Unfortunately I’ve not been able to really try the OOP support in PHP 5 until now and I must say that I’m not impressed this far. Sure, PHP now internally supports a more resource saving object model which also offers common OOP functionality but you can’t still use it in a real OOP manner. For example there is no real support for overriding a method or extending an interface like in the code below.

I suggest that PHP should be divided into two separate branches, “PHP procedural” and “object oriented PHP”. The latter would benefit if it was separated and the focus changed to fit larger projects where OOP really can ease the development. This is not possible today.

I also feel that I can’t post this without mentioning the experimental PHP extension “Object overloading” and this pretty much applies to overloading in PHP 5 as well. In PHP overloading ‘provides means to dynamically “create” members and methods’. Consider it an extension of variable variables. I can honestly not see the benefits of such an extension. It produces code that is harder to read, debug and maintain. Personally I think it’s a very ugly solution (due to a poor design) and not necessary when developing web applications.

class O {}

interface S {
public function a(O $var);
}

interface E extends S {
public function a();
}

class MyS extends O implements S {}
class MyE extends MyS implements E {}

I end this by saying that I hope that I’ll be proved wrong.

FreeDB to MySQL parser

Friday, March 17th, 2006

Ever got curious on something and then you’re unable to let it go until you’ve tried it out? Thought so. For me it started with the extracting of the FreeDB archive. What a beast! You start with a small innocent tar.bz2 archive of about 440 Mb. Extract the bz2 archive and you get something quite big, about 3.2 Gb tar archive, and it is now that you start thinking about the nagging about reading the FAQ before extracting. What a newbie can’t extract a simple archive?! Then I ran out of inodes on my partition… Cute.

The fact that the database contains almost 2 million files (2,000,000) is really a problem. If you don’t run out of disc space due to the overhead you’ll run out of inodes like I did. I was frankly surprised when the disc was full, I had 25 Gb free when I started and I had plenty of space left when it stoped. This was a partition using FAT32. Now I had a peek at the FAQ

Next try, extracting to a partition using ext2, and this time I didn’t ran out of something. Thus it took my old disc several hours to extract all files. Now then? Here I was with a directory wasting about 7.4 Gb of disc space. Why is it distributed in this way? I would prefer to have the data in a MySQL database. There are some parsers out there for those of you that want to take the easy way out, but what’s the fun with that? So I wrote my own in Java and it is now released under the GPL, read more about the Viba IT FreeDB to MySQL parser.

Now when the week-end is drawing near my tip for you is to try it out. It’s not every day you’ll have the possibility to play around with this amount of data. For your information, once parsed and imported into MySQL the disc usage for the data will only be about 1.5 Gb including indicies for all tables. Nice, huh?