debuggable

What are prototypes?

Prototypes are generally used to test an idea in an existing system or before a real system is established. The goal of the prototype is to prove whether the components that will also be in the final system will work together as expected. Think of car manufacturing. Most people use computer models to test things there, without the need to build the final product - the car. We build software prototypes due to the same reasons. On the one hand to fix problems with a lot less hassle and on the other hand to test things in advance. The real essence of prototypes lies in the things you learn building it.

Different forms of prototypes

When people think of software prototypes they think about source code. That is of course true, but only to a certain degree. A prototype in the php world could be a small script that checks whether the database, the php script and the Ajax request will work together as expected. You could also think of a typical Model View Controller setup. Your prototype could be a simple setup of the pattern to check if the controller, the model and the view operate together as expected and whether they are encapsulated as expected. You wouldn't want to build an entire application around your implementation of the Model-View-Controller-pattern only to decide after 6 months that your system is not flexible or scalable enough.

These two examples focus on prototypes being a source code product. However, prototypes need not be source code at all. When you do webdesign and you make a mock up of your website in Photoshop, then that's of course a prototype. When you are making a graphical user interface for another language, like java and not for php, you can use sketches on post-it-sheets, which will ultimately be a prototype of one form or the other too. CakePHP's scaffolding is a good example of prototypes used in php webdevelopment. The scaffolding in php is basically a source code generator - a prototype generator.

The goal of prototypes

Prototypes are required to answer questions only, that's why they are cheaper to produce. They can ignore unimportant details without which the actual product would be senseless. Details which aren't important for you now, but will be for the future users of your application. For example, when you are making a prototype for a website interface you don't need to have correct data. You can even live without that bad user interface when you are making prototypes for your performance tests.

The essence of using prototypes lies in what your learn building them.

What do prototypes investigate?

Put simply, prototypes need to investigate all risky things. Everything nobody has tried before and things that are absolutely critical to the final application. These things could be critical changes made to the database - something that I had to do last week - develop a password encryption system that encrypts all passwords in our current live database. Also I had to change all client code that operates on the passwords, like password resetting functionality.

Besides that, you can use prototypes on everything you feel uncomfortable with. Think of the following:

• Architecture
• New functionality in an existing system
• Buildup and contents of external data
• Tools, frameworks, libraries, etc. from external parties.
• Performance-Issues
• Graphical User Interfaces
• Critical changes to the database

The value of prototypes is not in the source code you produce, but in the things you learn from it. That's the most important thing you need to remember about prototypes.

How to use prototypes

Which details can be ignored with prototypes (most of the time)?

• Correctness - you can use fictive data with prototypes
• Completeness - it could be that the prototype needs to work only with a specific input
• Error-checking - If you don't use the correct path, your prototype might explode. That's okay.
• Documentation - Yes, most prototypes don't need much documentation.

When using prototypes, make sure that everybody involved knows, that you are writing something for the trash bin.

PHP provides a means to adjust your error reporting level. That means you can decide, which types of errors will be displayed to you and your users.

You can either adjust the error reporting level in your php configuration file or you can use the ini_set() - function to adjust the error reporting level.

Which types of errors are there?

• E_ERROR - Fatal runtime errors. This shows errors, that can't be resolved. Script execution is halted.
• E_WARNING - Warnings (no fatal errors). Script execution is not halted.
• E_PARSE - Parse errors (for example, syntax errors) cause a script halt.
• E_NOTICE - Notifications that may indicate a problem in your source code. Script execution is not halted. However, if notices aren't intended you should fix the corresponding problem. Also make sure you do not display notices to your visitors, because that may encourage them to hack your site.
• E_CORE_ERROR - Errors that are caused when PHP is starting. These are like E_ERROR with the only difference that they are not caused by a script, but by the PHP core.
• E_CORE_WARNING - Warnings from the PHP Core. They are like E_WARNING.
• E_COMPILE_ERROR - Errors that are caused by the Zend Engine during compilation of PHP.
• E_COMPILE_WARNING - Warnings caused by the Zend Engine during compilation of PHP.
• E_USER_ERROR - These are like E_ERROR with the difference that they are deliberately caused in the script through the usage of trigger_error().
• E_USER_WARNING - Warnings caused by trigger_error() in the script.
• E_USER_NOTICE - Notices caused by trigger_error() in the script when something unexpected happens.
• E_ALL - Displays all errors of all error levels, except E_STRICT.
• E_STRICT - Notices by the run time system. They make you aware of possible code changes you should make to maintain interoperability.

In software development there are many things that can be automatized. Whether it be version control, the build process, deployment to the live site or generating a documentation website from your php comments. Such things, if done manually, can destroy the consistency in your project and will cause miss-feelings within your programming. So why hesitate? Make everything possible automatic!

Everything done automatically

From my experience in a company I worked for I know that when every developer uses the same IDE it can lead to uneasyness.Our lead developer told everybody to install this plugin and this plugin, each with a 2 pages manual on how to do it. At the end of the day, every work station was configured in a slightly different way. This lead to the main application exposing bugs on one work station, but not on the other, resulting in a resident nightmare.

That's only one reason why you should always avoid doing something manually. Human-beings simply can't repeat as well as machines do. Simple. Oh and we also shouldn't expect our colleagues to be able to do it. A batch script can launch the same command ever and ever again - for example a DB backup. If it worked once, then it is likely to work again.

Using Cron Jobs

A very popular tool is cron (or at on Windows systems). With it you can make your server execute certain scripts or php files on a fixed time ever and ever again. For example you could you use it to clean your sessions table in the database every night automatically, writing entries to a separate history file. Here you can find a Quick Introduction to Cron.

Automatic Testing

Using Simpletest and Cron you can easily automatize the testing process of your application and run nightly regression tests.

Generating Sourcecode

It's a best coding practice to generate all sourcecode by tools if you can. Look at our article about CakePHP's source code generator Bake here: The Bake Code Generator.

Automatic Paperstuff

Wouldn't it be nice if all programmers could use their time for programming? Unfortunately this is rarely the case. An email must be answered, contracts must be made, documents must be uploaded to the intranet. Maybe you decide for a shell script to do the dirty work 8well, not the contracts :)). However, you still have to remember to execute the script. Cron is your friend.

Generating Documentation Websites

PHP Documentor is a great tool to generate documentation sites. Simply put php doc tags around your class, methods and functions, run the phpdoc and voila - there you go.

Here is an example:

Whatever you do, generate php documentation site often and, most important of all, automatically.

When you are a programmer you need a good set of tools. Every tool must be simple to use, but be able to serve its purpose. This is true for all coder's tools, but especially for the editor / ide (integrated-development-environmenz) that he uses. You must be able to edit source code as easy as possible, since source code is, well, the fundamental thing for a programmer. :) Let's take a quick look over various functionality your ide / editor should provide you with.

You should use only one editor

I think it's the best to only know one editor, but know it like your wallet. I am of the opinion that you should use it for everything - coding, documentation, messages, etc. "Why?" I hear you asking. Because, most editors have different sets of shortcuts, commandos, toolbars etc. If you are using PHPEclipse for your coding, Textpad for your documentation needs and a monolithic office-product to organise your todo lists and to type emails, you won't get as fast as you can get with only one editor. In each of these environments you will different commands and conventions.

You must use shortcuts. Using cut, copy and paste via the mouse will not be as efficient as using CTRL+X, CTRL+C and CTRL+V.

Choose one editor, understand it fully and use for all editing tasks. If there is only one set of shortcuts for editing tasks,you will not lose any time thinking about what was the correct shortcut for the search functionality. Some editors use "F5" for that, some use CTRL+F.

Make sure, that your editor can be used with all platforms that you are using.

Necessary Editor Functionality

Apart from the comfortable or useful functionality, that you like to use, I will present a couple of functions here that every editor should provide.

• Easy configuration. Every aspect should be configurable as to your preferences. Especially shortcuts are important, because if you use them often, your hands won't need to abandon your keyboard.
• Easy extensions. An editor should be able to cope with new developments, such as a new programming language being released.
• Programmable. You should be able to program your editor for complext asks. This can be done via Makros or embedded programming languages.

Other than that your editor should feature the following functionality:

• Syntax-Highlighting
• Automatic indentation
• Automatic completion of words, functions, etc.
• Predefined text templates
• A useful help section
• Features that are common among IDEs - like an embedded compiler and debugger

Predefined Fileheaders

Most modern Editors / IDEs provide a useful feature that automatically writes a comment at the top of the file with the

• Name of the class
• Your name
• A skeleton for declarations, like constructors, destructors, etc.

In PHPEclipse for example, you could automatically add PHPDoc tags as in here:

Code Inspection

When you are not so used to object oriented programming in PHP, it's a best coding practice to use an editor that provides code inspection. For example it provides with a list of all functions in your file. One c lick on a function scrolls to that function immediately.

This is of course true for an OOP setup as well. A very useful feature.

So which editor should you use?

There are actually various options here, ranging from Textpad over PHPEclipse to UltraEdit. These three are not only the industry standardin PHP development environments, but also in most coding environments using other languages as well.

For the PHP community there is also Zend Studio, the official ide made by the developers of PHP. Zend Studio is certainly a good and useful ide with many features that I discussed in this post. However, the fact that there is similarly good freeware, you probably should not invest into it.

PHP Designer is another good option, providing support for better HTML and CSS Coding as well.

However, if you ask me, for now PHPEclipse is the way to go, as it provides integration with debugging, web testing and your webserver. It also features code inspection, auto indentation, code highlighting.You can toggle functions and phpdoc comments to get a better idea for the big feature. ANotheri mportant fact isa lso that most professional teams work with itand it always looks good on your application when you have substantial experience with Eclipse.

What should you try to do now?

• Explore all features on your currently used editor / ide
• Surprise you colleagues that use the same editor with a cool new feature nobody has used so far
• Use your editor's embedded programming language to automatize your work
• Learn your editor's table of shortcuts by heart
• Use your editor for all tasks, including programming, simple text editing, writing email templates, etc.
• Decide whether you need a new editor / ide

What is a profiler?

A profiler is an application that inspects your php code. It determines, how often every function (including the built-in functions) have been called and how much time they needed to complete. This is really great for optimising your program and makes finding the really tough and slow functions and methods in your application very easy.

Should I use a profiler?

Of course, every serious programmer should use a profiler to debug his code. Making a speedy application is one of the fundamentials for its success. Professional studies state, that the average user waits around six to seven seconds for an application or website to load - before he moves on. For you that would mean lost business, lost money. You sure don't want to lose money due to a call to preg_replace with the wrong regular expression.

What profiler should I use?

If you ask me, there is one great profiler, which is used by thousands of php programmers worldwide. It's php's XDebug Extension. It is under heavy development and has a great support system, installation guidelines and general documentation.

Here is an example code snippet on how you can use XDebug:

The code should be pretty straightforward. We simply use two different methods of calling the same static function of the class MyClass2. Once we call it 50000 times using MyClass::here2 and once using call_user_func().

If you have correctly installed xdebug, you will find out that the call_user_func actually takes about 3 times as much time as MyClass::here2().

Using XDEBUG_PROFILER_NC in our call to xdebug_dump_function_profile tells xdebug to merge all function calls in the same line into a single entry in the report. There are several other constants, i.e. methods of profiling available. Those range from sorting function names in order of their speed to reporting the average execution time for each function.

Two versions of xdebug

You have to know that there are now two versions of Xdebug available. One will just work the way my code documents it. This is called XDebug1 in the xdebug documentation. However, an even better coding practice is to use XDebug2, which dumps its reports to files which can then be used via Wincachegrind.

Conclusion

Using xdebug and profiling in general is a quick way of defining the slow parts of your application, without having to code a thousand calls to array_sum(explode(' ',microtime()));.

Every programmer should use profiling. It's a so-called best coding practice. Although the example provided may seem trivial, XDebug is very powerful when you profile your entire application.