There are whole books about optimization, but few mention when is the right moment for the optimization to take place.

There are several perspectives with fundamental differences:

• during development
• at the end of the development cycle
• never

What is the correct answer? In fact there are only less correct or inadequate.

During development

This answer has the most potential to be wrong.

Even though is the most common method and it shouldn’t be interpreted as being wrong, it has the potential to cause issues.

When it may cause issues? When instead of optimization, micro-optimization is used in excess.

Micro-optimization can come in many shapes, depending on how the project is developed. Some write “bulk” code or procedural code, others use frameworks and ORMs. When your deviating from the general rule of writing code to do optimization you should think about the consequences. It will be harder for the next guy that looks at your code to understand what’s going on, and if you make a rule out of that, with time the project will become indecipherable.

For instance if your using ORM and you start typing SQL you are already losing the purpose of the ORM. In ROM there are several steps for each interrogation:

Building the objectual interrogation -> Parse to SQL -> Execute interrogation -> Parse result -> Loading the resulting objects

vs.

Building the SQL interrogation -> Execute interrogation -> Parse result

The steps may varies depending on the implementation.

A lot of the times the second approach looks simpler and is faster for sure. But why use the first approach? For the architectural advantages! You can set triggers when accessing or setting the properties for instance.

A mature developer is the one that writes “readable” code, not just optimum.

At the end of the developing cycle

The advantage is that there are no architectural compromises during development.

This is usual the best method, because you have the finished product, developed without compromise and you can see which points should be optimized. When you have all the components is much simpler to reorganize them then during the development when changes may appear, which in turn can generate for instance code redundancy.

The disadvantage is that at the end is sometimes difficult to find the week points of the application.

Never

First of all let’s make it clear, I mean “serious” projects.

There is a general rule that’s saying “hardware is cheap, programmers are expensive”. More broadly this means that a lot of the times is easier to scale an application using hardware then doing major compromises in the code.

A lot of companies and projects support this perspective. Correctly applied this principle has the advantage of having a well organized code, easy to read and with few hacks.

The advantage is at development, few hacks make a project more organized (in theory) and easier to extend.

Unfortunately looks like there is also a different interpretation: “if must work, it doesn’t have to be perfect”. Where can this lead to? Basically is the best excuse for dirty code.

The major difference is that you never optimize, and the code will look just as bad as when you do excessive micro-optimization.

Conclusion

In general, project that use excessively micro-optimization, have a great potential to be often rewritten, either partially of full, because there is another rule that says “rather then repair, a lot of the times is easier to rewrite”. Unfortunately projects with bad written code suffer the same fate.

A major disadvantage to bad code is that it slows the development cycle, in other words minor tasks tend to last longer and longer to be accomplished.

Projects don’t have to be always optimized. But when we have to do that, compromises regarding the architecture must be at minimum.

Last week-end I was surfing the Web wandering why there isn’t any 3d done in JavaScript. A ridiculous question in a hot afternoon.

My question was born from the idea that the first stage in 3d evolution was done in 2d, basically representing 3d objects using the existing 2d ways.

Of course I came across my first answer: a 3d shooter game directly in the browser, done by Ben Joffe!

It is at least impressive!

Beside this find I immediately came across some other 3d games in JavaScript that are not using tags like canvas, but this results are not very impressive because of a simple reason: speed!

Before HTML5 the speed of displaying elements in the browser was a very big issue. Is well know that one of the slowest components of the browser is the DOM, especially in Internet Explorer. When it comes to the canvas a huge difference is visible in the good way, the multitude of the objects on the stage are not coordinated using the DOM but rather just displayed in a true graphical element.

While I was opening my computer today I was thinking why doesn’t anyone make a game at least like Duke Nukem 3D? Of course the browser will not become just yet a platform that can compete with XBOX for games ant that’s normal… I don’t even know how did I come across this, but it was just like something in my universe drown me to something truly impressive:

Quake 2 directly in the browser, using JavaScript!

At the beginning I thought that they cheated, they’ve used WebGL, not just the 2d popular canvas. But the result is truly impressive, and this standard will probably be available as an HTML5 specification, which means it will be available on at least a part of the browsers.

Even though they’ve used GWT, the resulting code is still JavaScript, so this can be made just using JavaScript!

Where did the hole idea of 3d in browsers came from? I’ve read about 2 years ago about some efforts in this direction, and they ware based on VRML. But VRML exists as a standard since 1994 and I haven’t seen anything  impressive yet. I even have a VRML book that is full of dust in a shelf. The biggest issue was that there was no native support for it.

The new perspective is absolutely innovative, because is a bridge between the browser and the 3d hardware. So if one day we will have 3d in our browsers it will be done this way!

I was working the other day on a new JavaScript game for the games section. Like the majority of the developers (like the statistics show) I’m using FireFox for developing. But as the game reached the testing faze it was time to see if it was working properly in Internet Explorer.

To test in Internet Explorer is a real pleasure, basically you see an error and then you hope that you’ll find the source.

Of course there was an error, one full of meaning as usual:

Unknown runtime error??? WTF??? If he does not know how should I?

The piece of code that was generating the error was:

1canvas.innerHTML = '';

Where canvas was a variable which was storing an document.getElementById(‘canvas’), and the id canvas was from:

1<table border="0" cellspacing="0" cellpadding="0">
2<tbody id="canvas"></tbody>
3</table>

Looks wrong? well is not because at that point I was testing other games which are using the same thing with no trouble, even in IE.

I’ve tried it in IE 6, of course with the same result.

It looks like this error appears on elements like table, tbody, p and others.

To finally fix the issue I used instead of a tbody, a div tag in which I’m adding the elements and the issue was gone.

What is interesting is that this issue does not always appear for a specific tag!

Thank you Microsoft for this meaningful error messages that are so full of logic!

In PHP 5 a new concept was introduced, type hinting. This feature allows validation of a parameter for a certain type.

This validation type is very popular in object orientated languages and I believe it represents a plus for the PHP object model and even more for his dynamic nature it self.

In PHP 5.1 validation for the array data type was added.

Let’s take a small example:

 1class a { }
 2
 3class b { }
 4
 5function testa (a $a) {
 6    echo "Bla bla\n";
 7}
 8
 9testa(new a());
10
11testa(new b());

The result is:

1Bla bla
2
3Fatal error: Argument 1 passed to testa() must be an instance of a, called in ...

Cool, ha?

The type in which we can validate can be a class, an abstract class or even an interface which is inherited  by other classes, like:

 1interface inherited { }
 2
 3class a implements inherited { }
 4
 5class b implements inherited { }
 6
 7function testa (inherited $a) {
 8    echo "Bla bla\n";
 9}
10
11testa(new a());
12
13testa(new b());

And the above example will not raise any errors.

Unfortunately there is no way to validate primary (or scalar) data types. When PHP 5.3 was being released there have been some discussions on the subject, but it seems that it was too late, and the patch did not make it to the final version.

Yesterday, while I was doing my morning reading at a cup of coffee, what do I see on Ilia Alshanetsky blog: Scalar Type Hints are Here! Well, is a little exaggerated, there are not exactly here but there really close. Basically there are in the SVN trunk and will be available in the next stable version!

Of course that even in the current version of type hinting is not exactly mandatory to use it in PHP, is more of an issue of fine tune.

Basically we could already validate to a certain primary data type, but still:

1function testint($var) {
2     if(!is_int($var)) {
3         trigger_error("Type must be Integer", E_USER_ERROR);
4     }
5     .......
6}

is not exactly as elegant as:

1function testint(int $var) {
2     ......
3}

Packt Publishing has published a new book on the RAD PHP framework CodeIgniter version 1.7. The book CodeIgniter 1.7 Professional Development written by Adam Griffiths, has the slogan “become CodeIgniter experts with professional tools, techniques and extended libraries”.

Just from the slogan you can see a slightly different tone then the book CodeIgniter 1.7 from Packt Publishing, which in my opinion has the purpose of showing what the CodeIgniter framework can do.

This book has the purpose of showing how can you develop professional applications, or at least until proven otherwise, stay tuned to find out!

An argument for the slogan is the target audience like is defined in the “Who this book is written for” section, which contains the phrase:

Basic knowledge of CodeIgniter will be helpful.

A dangerous phrase in my opinion, because it can scare off a beginner, even though in the book it looks like all the steps are described starting from server installation.

If from the first book I was expecting a general presentation of the framework, now I’m curios to see if the examples are more ample and more concrete.

From the sample chapter it looks like there is a lot of code. As long as it is logical I thing it’s a good thing, a lot of times is easier to understand code, which you will after all write and you can take as an example, then theory.

But more about this book after I’ll get to read it.

To be continued…