underdevelopment

Now this piece of wisdom is actually not mine, but from a colleague at ibuildings. He basically states the following; “If a client or user ever finds a bug or a security hole, then don’t ever say ‘Oh, i knew about that’.”

Now the observation here is that sometimes while you are reading older code you will see a bug or security leak. Often enough you will think “Oh well, this is old code and has been running for years”. That however is not the right thought to have.

The right thing to do is to estimate how many hours would be needed to fix it and what the impact of the problem is. If you then have enough time, you fix it. If you don’t, you register it and escalate it to the person responsible of the project.

At least then, you don’t have to say “Oh, I knew about that”. This phenomena is closely related to that of the broken window effect*, which teaches us that it is human nature to not fix the window. It is therefore wise to always keep the above in mind, and consciously force yourself to do the right thing.

So next time you see a bug, don’t say to yourself that you will fix it next week, because we both know that will probably never happen.

* This effect is wonderfully described in the book ‘the pragmatic programmer‘, required reading for any programmer if it was up to me.

admin software development best practice, broken window, pragmatic programmer

First you will have to excuse me for last week, while it is my intention to write at least one blog post a week, real life and more specifically a current project at my job have had me tied up quite a bit I’m afraid.

Also in the interested of actually writing about something people would want to read, I am paying special attention to the popularity of my blog posts. Since at the moment I have only 4 posts and about roughly the same amount of visitors, I can hardly make any real conclusions from that data. However even with numbers as low as those, it seems my blog post about object oriented programming is by far the most popular. This could be skewed for many reasons, but for the moment I will assume it is true. If any of the four people whom read this blog would like me to address some other topic, then please do use the comments and I will see what I can tell about the subject.

Now with all that said, it will come to no surprise that I will try to explain a little bit about object oriented programming. Specifically, as the title already betrays, about encapsulation and the command pattern. Now I know I already briefly touched on that topic in my previous blog about OOP and patterns, but I just like it and it is my blog.

So what is encapsulation, and why should you care?

Encapsulation is, as the word describes, the idea that functionality and data should be encapsulated within its own domain. This, at least in my eyes, is the single most important and single most beneficial aspect of object oriented programming. In a way it even defines what object oriented actually is.
A object is a representation of a distinct entity of your program, which encapsulates its behaviour. Thereby abstracting the functionality and making it easier to work with and think about.

Now that is all well and fine, but why would I want to encapsulate, you ask,? Well depending on your level of experience with existing code the answer should already be painfully clear. Just think back about that project that was built years ago, which kept getting more feature requests until the initial functional design in no way represented the project as it is now. Such projects often suffer from bad encapsulation, different parts that intertwine way too much with each other. Making it expensive in time to add/remove or even modify features.

That is exactly what encapsulation fights. By correctly encapsulating behaviour you guarantee that none of the encapsulated functionality is touched upon elsewhere in the project. You effectively limit the domain it has effect upon.

Many if not all design patterns embrace the idea of encapsulation but I think the command pattern does so in the most direct way. The command pattern as I explained in a previous blog post encapsulates a piece of functionality exposing only a common method to call it, this is useful in many ways. Think for instance about “actions” that need to be executed or as a specific example the image manipulations from my previous blog. I could have put knowledge about those things in the object that handled the images as collection. That however would have meant that that object now, not only has to know about the images, but also about how to manipulate them. That may sound minor, but in reality that would in fact give a single object two responsibilities. Now while I do not have direct proof, I can guarantee you that however elegant it might initially be written over time the object would get encumbered with even more functionality for manipulating images.

However if the manipulation of images is in fact fully encapsulated within a separate object that bears the responsibility to do just that one action, we force ourselves to keep that functionality within that object. Meaning that however much we might change the way those images are manipulated we will never need to touch the object that controls the collection of images. We could for instance easily switch from using GDlib to libMagick. The only thing we would need to do is modify the command objects and perhaps their parent object which might contain shared functionality.

You might even imagine we could keep both these versions and detect up-front what modules are available to us and choose which set of command objects to use, depending on that. If we had not used the command pattern it would not be unthinkable that this choice would also have ended up in the object that initially only held the images, thus creating the start of the wild growth that would eventually lead to a super sized object that might hold half of the project functionality.

-edit-

Disabled comments because I was only getting spam. If you want to comment just do so on another article and add that it was actually for this one and i’ll move it or something.

admin PHP command pattern, design patterns, object oriented programming

Now regexes are a wonderful thing. Personally i can’t get enough of them. they are terse, compact, to-the-point and have a extremely high geek value. Below I will show a example of how you can use simple regular expression rules to accomplish a non-trivial task.

shortening a text

Often we will want to show a short excerpt of a full text, think for instance about articles and what not. A common but ugly way to do this is via substr(). A much more elegant way is via a regular expression.

A easy way to do this is via the following one liner.

preg_replace('/(.{1,250}\.)\s.*/ms','\1', $text );

What this does is select all text, with a sub selection that selects the greatest range of all characters between 1 and 250 ending on a dot. Then it replaces the text with that sub-selection. Resulting in a excerpt that will have the maximum amount of characters up till 250, but will likely end with a full sentence.

There is still the case that no dot is present in the first 250 characters, so you will have to test the output of the preg_replace. But more often then not, the above will work.

Now let’s look at what is happening.

/(.{1,250}

Immediately from the start we open a sub-expression to match the beginning of the text. The dot character gets interpreted as “any possible character except newline”. We then use the brackets to set a quantifier from 1 to 250 characters on the dot character, which means we want to match anything as long as it’s either 1 or 250 characters long.

Since the default behaviour for quantifiers is to be greedy, it will try to match the maximum amount of characters.

\.)\s

Now that we have defined the amount of text we want to match, we are going to define the ending of this match. This, as stated before, is simply a dot. We have to escape that dot as to not match everything. Then we end the sub-expression since this is everything we want.

However it’s not everything we want to test for. So right after the sub-expression I ask to match a whitespace character (\s). This will ensure that it’s actually the ending of a sentence and not for instance the URL of a domain.

.*/ms','\1', $text );

Now that we are done with the desired selection we simply state “.*” Which will match all characters zero or more times.

Then in the replacement section of preg_replace we state that we want to back reference the result of the first sub-expression, and we are done.

As you might have noticed I added a “m” and “s” to the end of my matching expression, these are global modifiers that will change the behaviour of the expression.

The “m” stands for multiline, which will change the default behaviour of starting and stopping at new lines, to match a entire text. The “s” modifies the behaviour of the “.” character to also match newlines. You will often see these two modifiers combined because without the “s” modifier a expression like /.*/m would still only match till the first newline.

Now the above is certainly not watertight, it’s just the illustrate how versatile regular expressions can be and how you can take advantage of the more advanced uses of it.

If you are interested in learning more about regular expressions in PHP I would advise you to go read the PCRE pattern modifiers page and the regexp reference page.

admin PHP excerpt creation, PCRE, PHP, regexp, regular expressions

I recently switched hosting for my websites, and with that I of course made all those little changes again to fine tune my performance. This seemed like nice enough info to share with you. Most of the points are already widely known, but it never hurts to have them listed again.

First up in the list is gzip compression of text documents. It saves both time and preconscious bandwidth. For this you will need to enable a apache module that’s probably already available to you. mod_deflate

Depending on your distro/installation you can either enable this by adding it to your apache config, or by using the following command.

a2enmod deflate

After having enabled this module you should check its configuration. The configuration should either be in your main apache2 conf file, or in a file that gets included. It should look something like this.

AddOutputFilterByType DEFLATE text/html text/plain text/xml

Now the default is nice, but there are more files that are only text like CSS files and javascript files. So we edit that line to read the following.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript

Now all files with those mime types will be compressed, saving you precious bandwidth and transfer time.

Another tweak I made is the enabling of mod_expires. Add it just like you added mod_deflate. After adding this mod you should hunt around for default configuration options that will probably include “ExpiresDefault”. My ubuntu based installation didn’t have this, so I added it myself. You can just add this in the server configuration file if you want. Personally I created a /etc/apache2/conf.d/expires file, because that’s how my setup works.

ExpiresActive on
ExpiresDefault "now plus 1 months"
ExpiresByType text/html "now plus 1 days"

You will have to experiment with this to find the values that you are comfortable with, I prefer to set them pretty liberal. What this means is that the contents of the requested file will not be transferred to the client before that time has passed. Which again means less bandwidth and more speed.

In my case, all static resources like CSS, javascript and images will be cached for a month, and the document itself will be cached for a day.

There are many more performance tweaks to be made, but for now I’ll leave it at this.

admin apache2 apache2, mod_deflate, mod_expires, performance

About two years ago I wrote one of my first “true” object oriented php projects. I say “true”, because before that I had dabbled and played with OO, but never had I had a REAL project with it. Well “real” project is perhaps overstating it a bit, but it ended up with about 2000 lines of code, which is the borderline where something becomes a project in my book. The rest is just proof of concept or small scripts.

To start with some honesty, if I look at it now, and I am looking at it now, a lot of it is crap. But the one thing that started this project is still a nice implementation and also the subject of today’s blog post.

Many of the projects I have done in the past have started with a theoretical problem and the problem with theoretical problems is that they are not really problems; not in a way as for example building a bridge is a problem. So I invented a program idea that would present me with just that problem. The problem that day was that I could not seem to figure out how to do a plugin architecture. Now to some, this may sound simple, but at that time I simply couldn’t seem to figure it out.

So I started this project called libPhoto. LibPhoto was meant to become a generic back-end library you could use to manipulate images via an easy interface that abstracted complex modifications to the image. Ok ok, I admit, I also was interested in computer graphic algorithms at the time. But that’s for a different day.

Now one of the key aspects of this libPhoto would be that each modification would be a “plugin” for the library, so that it could easily be extended. The other key aspect was that libPhoto didn’t really needed to understand these modifications, it would only understand “versions” of an image. When talking to libPhoto you could tell him what a specific “version” of an image was called and what attributes it had.
Here some code to show how that looked in practice.

$libphoto = new libPhoto();

$resize = $libphoto->newMutator(‘resize’);
$resize->config(array(‘width’ => 200, ‘width’ => 200, ‘keepAspect’ => false));

$dropshadow = $libphoto->newMutator(‘dropshadow’);
$dropshadow->config(‘gausSize’ => 3, ‘offset’ => 15);

$thumb = $libphoto->newImageVersion(‘thumb’);
$thumb->addMutator($resize);
$thumb->addMutator($dropshadow);
$libphoto->setImageVersion($thumb);

$imageVersions = $libphoto->processFile(‘/some/image/file’);

Now the nice thing about the above, is that libPhoto, the codebase itself, has no idea how mutators worked, nor does it care. What you are seeing above is the end result of such buzzword patterns as the factory method pattern and command pattern. Or at the very least, I like to think it does. And as to explain why I think it does, i’ll go over what is happening behind this code.

$libphoto = new libPhoto();

Well, pretty obvious, it instantiates the libPhoto class into an object, which then does all kinds of stuff behind the scene like scanning to see what Mutators it has.

$resize = $libphoto->newMutator('resize');
$resize->config(array('width' => 200, 'width' => 200, 'keepAspect' => false));

Now here we can really begin. When requesting a new mutator object from libPhoto, libphoto will check if it actually exists and if it does, will instantiate it for you and supply it with some default configuration options and will ask it about some small details like if the current php installation contains the requirements to run that mutator. Which in most cases equated to “does it have GDlib”. After it prepared it for the harsh world outside, it returns it back to the code we are reading. At which point we could supply it with some extra configuration options. We could have asked it for those configuration options, but since I wrote the damn thing, I should know what its config options are.

Now I could of course have trusted on the puppy dog eyes of developers everywhere to implement some default methods, but in a more sane approach I actually implemented an interface to which all mutators needed to comply. Furthermore all Mutators extended from a baseMutator which already implemented various default methods like reading the config options and storing them as private variables.

So in the end your average mutator looked roughly like this

/**
* This mutation makes the image greyscaled
*/
class mutatorResize extends baseMutator {

private $ConfigOptions = array(
‘width’ => ‘int’,
‘height’ => ‘int’,
‘keepAspect’ => ‘bool’
);
/**
* This turns the image grey.
*
* @param gd image resource $image
* @return gd image resource
*/
function process($image) {
// … snip …

return $image;
}
}

As you can see, it really only defines some options that the process will use to do its job and after that only define a process which does the job.
All the tedious stuff like reading those config options or explaining them to the underlying system where all already generically defined in the baseMutator.

$thumb = $libphoto->newImageVersion('thumb');
$thumb->addMutator($resize);
$thumb->addMutator($dropshadow);
$libphoto->setImageVersion($thumb);

$imageVersions = $libphoto->processFile(‘/some/image/file’);

Now the first line is more of the same as the previous one with the mutators. It instantiates an new imageVersion object which get’s a few default config options before being passed along. Then you add some Mutator objects, and basically tell libPhoto there is an new image version. After having done all that we tell libPhoto to process an image file.

LibPhoto will then iterate over all the different image versions it has and tell them to do their thing. The imageVersion object will open the imagefile and create a GDimage resource and iterate over its mutators and pass them the file and tell them to do their thing.

The mutators will gladly accept the GDimage resource, do their magic with it, and pass it back. In the end the imageVersion writes the GDimage resource back as an image file and passes that file location back to libPhoto.

This is I think a perfect example of encapsulation and the command pattern. None of the objects even remotely care what the other is doing but just know how to tell it to do its “thing”.

I hope you enjoyed reading a bit about this, i know it’s all pretty basic stuff but i hope i’ll be able to expand into something a bit more complex when the time comes.

-edit-

Disabled comments because I was only getting spam. If you want to comment just do so on another article and add that it was actually for this one and i’ll move it or something.

admin PHP command pattern, design patterns, factory method pattern, libphoto, object oriented programming

Some time ago there was a topic on the daily WTF about a bit of PHP code which was rather funny.

if (!count($items)>0) { something(); }

On first instance this looks rather normal, but it doesn’t exactly do what you think it does. When you read it, you might assume the “!” will invert the expression “count($items)>0″. This however is false, what get’s inverted is “count($items)”.

The reason this is funny, is because it actually does work. We want the full expression to be TRUE when there are zero items in $items. When count($items) is 0, this get’s converted to a boolean for the “!”, which will be FALSE. The “!” kicks in and it get’s flipped to TRUE. Then we are asking if TRUE is larger then 0.  Now TRUE get’s converted to 1, or the right side 0 to FALSE, it doesn’t really matter. The end result is that we are asking if 1>0, which is TRUE.

So to show in code, what happens is something like this.

if (!count($items)>0) { something(); }
if (!0>0) { something(); }
if (!FALSE>0) { something(); }
if (TRUE>0) { something(); }
if (TRUE>FALSE) { something(); }
if (TRUE) { something(); }


Instead of what we might have initially expected

if (!count($items)>0) { something(); }
if (!0>0) { something(); }
if (!FALSE) { something(); }
if (TRUE) { something(); }


It’s always good to keep such things in mind while working in PHP, because seemingly innocent code can have very unexpected side effects. In this case it’s a bit harmless because the end result is the same, but sometimes this may not be the case.

As a good example of a less obvious deathtrap, please answer me the following question.

$items = '';
if (count($items)>0) { something(); }

Does “something();” get executed or not?

admin PHP loose typing, PHP, quiz, thedailyWTF