Seriously. So much in love that I need to try it by myself. Hence, VideoCanvas.
VideoCanvas is a mix of PHP, ffmpeg and ImageMagik.

Starting from a video, it creates an images with all the tiles and an HTML page with hard-coded JSON containing frames info and some JavaScript to start the video.

It relies on ffmpeg to extract video frames in separate images. Then with the ImageMagik extension of PHP it creates a minimum set of tiles to recreate the video in the <canvas>.

Have a look at the final result of version 0.1. Here you can find the source video made with Kazam Screencaster.

(Edit: the JS code has been updated to use requestAnimationFrame when available)

Of course, it couldn’t even start: it didn’t support namespaces. So I had to improve the analysis of tokenized PHP source and now it works.

By the way, the report was not satisfying as I expected. With a big project such Doctrine you understand how much it is important to have a concise report. So now:

• the parameters are internally indexed by name. This means that it is easy to detect a changed type, but names changes are still seen as “added param $newName” + “removed param $oldName”.
• @inheritdoc is supported.
• multiple types (integer|bool $param) are supported.

This leads to an almost accurate analysis of Doctrine2 ORM classes:

Scanned 261 files with 1672 methods in their classes. 919 methods (55.0%) are regular, 388 methods (23.2%) have no docblock, 365 methods (21.8%) have an outdated docblock.

Since these changes are not in the pear channel yet, if you are lazy&curious the report is here.

So, now PHP is evil. Personally, I agree with Anna Filina:

This is an insult to all people who work hard at it. The words that you use to describe things are simply baffling. “You” and “them” are the community, and it’s your responsibility as much as theirs.

People can improve. The crypt() function can be fixed (ooops, already done). The failing tests can be analized and fixed. The release team can learn to avoid to be embarrassed again. If you understand something that can be improved, you can improve.

For this reason I think PHP 5.3.7 is a great release for self-improvement.
One point for PHP, zero points for stupidity.

From this release I can consider it useful, since it includes the ability of exclude whatever you do not want to scan. In fact, you can exclude from scanning any path, class name or method name.

In Allbus, the company where I work, we have several types of classes that are not so much interesting, like implementations of Factory or View Model patterns.  A Factory creates instances of Services with all the needed collaborator injected, with method names like getVehicleService() – which is self-explanatory. A View Model selects some fields from the Sacred Domain Model and always has just a method, setUp(). Nothing more!

As you can see, in such cases the use of docblocks is tautological. While analyzing what classes need a visit to their docblocks, it is important to have no noise around. Simply leave behind classes that do not introduce logic:

phpadd --exclude-paths application/*/view/model/* ...
phpadd --exclude-classes Factory$ ...
phpadd --exclude-methods ^setUp$ ...

If you have already installed an older version of PHPADD, you can just run pear upgrade-all. Otherwise, install it via the repository.

PHPADD can analyze a directory with PHP source code and detect (for each file, for each class, for each method) if the parameters in the function declaration are compatible with the parameters found in the docblock, reporting the outdated ones.

This can be easily integrated in your build script and the result can be published in build result. Using Hudson, you just need HTML Publisher plugin.

Install it
With PEAR it is very simple. On Linux, you may need to prefix each command with sudo.

pear channel-discover pear.webmatters.it
pear install webmatters/phpadd

Try it
Once installed it responds to phpadd from your console.

phpadd --publish-html /tmp/output.html directory/to/analyze

This command will produce an output like this.

Please note, phpadd has to be improved. For example, it needs to ignore warning on files/classes/methods matching a given regular expression (controller classes, for example).
Or the difference between docblock params and function params: it is not so smart.
If you want to help, fork it on GitHub!

If you do not put unselectable items in the combo, your customers will say you: “Why can’t I see raspberries in the list? I’m sure I added them to the system“.
And if you put everything in the combo, they will say you “Oh, that’s too much, why do I see all this useless stuff?“.

But wait for a moment, we already solved this problem 20 years ago in menus!
In the menu of an application you see everything, but you can select only some items.

This plugin replicates this behaviour: it grays out unselectable items. And since it is simple to do in ExtJS, it provides a qtip with the reason of that status.
You just need to provide a little more detailed store. In this example we have:

{
	'id': 2,
	'label': 'Raspberries',
	'banned': true,
	'banReason': 'Not available in this season.'
}

Play with the example or download the sources. And last but not least, thanks to Gianluca for the idea.

Automatic add during commit
git commit -am "message"
It automatically adds already versioned files to the index before commit. This will automatically remove file disappeared from the filesystem. Untracked files will not be added.

Add to the index just some part of a file
git add --patch
For each chunk, you can type: y (stage it), n (do not stage it), q (do not stage & quit)

Interactive index add
git add --interactive
This UI has Super Cow Powers. Go in update mode with update. Now type:

1     to add the first file to the index
1-3 to add files 1, 2 and 3 to the index
-1   to unstage first file

To go back into “what now” mode, press Enter. With revert mode you can restore a file as it is in HEAD. For other modes, type help.

Undo a commit
To go back to the previous state
git reset --soft HEAD^
Fix what was wrong and commit from the discarded commit (ORIG_HEAD)
git commit -c ORIG_HEAD

We want to log users off after one hour of inactivity. If your user session is destroyed and you try to open a form, you should be warned that you cannot continue and you will be invited to log in again.

That’s very simple. For each Ext.Ajax request, you should check that you are still in, if not, open a login form and if the server accepts your credentials, continue. For each request. For each request. For each request. [...]

That repetition sucks. What could we do?

• copy and paste all the code, in every Ext.Ajax.request()
• create a detectIfLoggedOf() function and call it in every success() callback of Ext.Ajax.request()
• define a new Ext.Ajax that do everything.

Since you should spend your time writing a strong web application, let’s discard option 1 and 2. AuthorizedAjax is option 3.

Please keep in mind this is more a proof of concept rather than a real implementation. There is no documentation (yet?). See the example and read it’s configuration file.

How it works
Your server must send special headers if something unusual happens (for example, the user is not logged in or the ACL system denied the access). Then you tell AuthorizedAjax how the server can answer, and what to do in that cases.

If the server will not send any special header, AuthorizedAjax will behave as Ext.Ajax – otherwise, something (configurable) will be executed.

Conclusion
I repeat, this is just a proof of concept of a domain specific language. “Dear system, this case may happen, and in that case you will do this” (action-reaction). A DSL applied to something more complex is powerful – it allows everyone to configure a system, just knowing how the system works and nothing about programming.

Imagine PHP without the in_array() function: you need it, so you have to write it:

function inArray($needle, array $haystack)
{
	foreach (...) { ... }
	return $found;
}

Then you check if it works:

$array = array(4, 8, 15, 16, 23, 42);
var_dump(inArray(2, $array));
var_dump(inArray(16, $array));

You see that everything works as expected, you throw away the three lines above and commit your code. It works, afterall!

Considerations:
- you spent some time to write a manual, use-and-throw test;
- if your code changes, for example you implement the third optional parameter strict, you have to test the old functionalities (déjà vu) and the new ones;
- you can’t make predictions about code’s immutability (and often, it changes).

They could automate the execute button pushing

Use automated testing
Testing your code by hand is nice (you show that it works — at least for now), but if your computer does it for you, it is nicer. All you have to do is to explain how your software should work by writing a (reusable) test. You are slower to execute tests, you can forget to do it, you may do mistakes while doing it. A computer won’t.

Def.: A test is an executable specification for your software that you write once and execute whenever you like. In a test you setup an environment needed by the SUT (system under test), you exercise the SUT and you do some assertions on the results.

Now that you know what and why, let’s be more practical. First, install PHPUnit. Now suppose that the above inArray() definition is contained in the file InArray.php.
Create a file named InArrayTest.php with this content:

<?php
include('InArray.php');
class InArrayTest extends PHPUnit_Framework_TestCase
{
	public function testFindsExistingElements()
	{
		// setup
		$array = array(4, 8, 15, 16, 23, 42);
		// try the system
		$elementInArray = inArray(16, $array);
		// check results
		$this->assertTrue($elementInArray);
	}

	public function testWontFindUnexistingElements()
	{
		$array = array(4, 8, 15, 16, 23, 42);
		$elementInArray = inArray(16, $array);
		$this->assertFalse($elementInArray);
	}
}

You just defined the container for the tests of your inArray() function – the InArrayTest class. PHPUnit will search in it for public functions starting with test*() and will execute them. In other words, a class for each thing to test (thing is for: a class, a function, an Ext window, …), a method for each group of assertions.

In these functions (“tests”):
1) you will prepare the environment the SUT will need (for example: creating sample data, instantiating a collaborator, opening an ExtJS window of the application);
2) you will exercise your SUT (inArray, in our case);
3) you will check that everything works as expected with assertions. You can check that a variable is true (assertTrue), that a variable has a known value (assertEquals), and so on.

This is the same way you would do by hand. To test our function, we have 1) built a sample array, 2) called inArray on it and 3) printed the result and we have thought: “it returns true and I wanted it to be true.. it works”.

To run your test file, you can type:

$ phpunit --testdox InArrayTest.php
PHPUnit 3.5.0 by Sebastian Bergmann.

InArray
 [x] Finds existing elements
 [x] Wont find unexisting elements

Note: we created two tests, for two functionalities. This is ok for fast tests, but if the test setup takes seconds (for example you are creating a database with data, or you are asking Selenium to open a browser to test your ExtJS application) you should check more things in a single test.
That should be avoided when possible, but done to keep test execution time low (when you change some code, you want a fast feedback).

An important result
Now that you stuck your specifications in an executable format, you can refactor/add functionalities to your SUT being sure not to introduce regressions – if you break something, at least a test will fail.

How many time you said: “why this code? it could be simpler” or “this happens because that function is called here, but it shouldn’t happen, let’s remove the call”? And each time you fixed a bug, but you destroyed something else.

Golder rules
> Remember to test everything that is important, and skip what is not necessary. Cover all the possible cases with your tests.

> If you cover all the cases of interest, you are in a safe place. You can fix bugs without break other things, you can fix bugs on your in-production software without stress (the test suite passes? no regressions, you can deploy). In other words, with tests you will always know what works and what not.

> If you find a bug, write a test to reproduce that bug. Then make the test pass, fixing the bug. Has your supervisor ever shouted you “why this problem still occurs?” or not?

Selenium
Selenium Remote Control is a server that accepts requests like “open the page at $url“, “click on element with selector #mybutton” and it lets you see the DOM.
To execute your requests, it opens a browser (or a set of browsers, if you want), it loads your page and executes your commands. All this (almost) at the speed of light.
Download it from here and run it with java -jar selenium-server.jar.

You will give commands to Selenium via PHPUnit. To do this, you have to extend PHPUnit_Extensions_SeleniumTestCase or ExtDiamond_TestCase (which extends the first).
See this example: we are asking Selenium to open a certain URL and to check the page title. See Selenium API to check out other useful methods.

Rich Internet Applications
Testing a web site is simple –  you do some asserts on some elements. Complicate things may only be forms population and submit.
For example, you tell to Selenium to open shownews.php?newsid=1 and you assert that div#title, div#introduction and img.articlecategory elements all have some content. Done.

Testing web applications is harder. You will need to click on some elements, that will open some windows, you will interact with them and then you will do some assertions on the DOM. That is generally more complicate.

ExtDiamond aims to make this simple. See the grid ExtDiamond example. The page under test automatically renders a window with class firewall-window. If the window would not be automatically displayed, you could call

$this->click('css=div.something-that-will-open-window');

In both cases you have the opened window, at line 30 we get it’s reference. Then on line 32 we get the value of the title property (on the Ext.Window object) and we check that it’s value is correct. As alternative way, you can access the DOM of the window and assert on the title on the DOM.

Read the ExtDiamond presentation to find out which ways is better depending on your case. I also recommend you to scan PHPUnit, Selenium and ExtDiamond APIs.

… happily until their assertion failures deaths.

What changed
ExtDiamond is shipped with some built-in widgets. Right now we have only GridPanel and Form.Field, but we hope to have something more in the future.
By the way, you application may use non-standard widgets (meaning: not provided with ExtJS) that you developed by yourself or bought from someone.

In these cases, you may need to define your own widget reference classes, especially if your component is complicated.
This release allows you to register a path where ExtDiamond will search your own widget classes, that will be loaded when you call handleAs() on your references.

Now that all the original functionalities are completed, I will concentrate my time on new features.
Finally, I want to notify you that ExtDiamond API is available.