bjori

Nov 012011
 

When you need to see if any of the chars in $chars is in another string.. Whats the simplest way to search for them?
Hopefully none of the libraries have such functionality, so you need to go “a bit lower”.
The answer is, ofcourse, trivial:

$chars = "xy";
$string = "the quick brown fox jumps over the lazy dog";

$found = false;
for($l = 0; $l < strlen($chars); $l++) {
        if (strpos($string, $chars[$l]) !== false) {
                $found = true;
                break;
        }
}
if ($found) {
        /* Do stuff */
}

But hang on. This feels a bit weird. Surely PHP must have a better way of doing this?
Browsing through the string section in the PHP manual you’ll notice PHP has bucketloads of native string functions. If you have a background from other languages, you could even just try and see if PHP has a function of the same name (which quite often it does) that solves the problem.

And sure enough, it does: strpbrk!

$chars = "xy";
$string = "the quick brown fox jumps over the lazy dog";
if (strpbrk($string, $chars)) {
        /* do stuff */
}

Just give the “problem” a second thought before going crazy with your coding, and keep in mind you aren’t just working with Symfony, Drupal, SugarCRM, WordPress, … Your good old pal, PHP, is there too.

Oct 202011
 

With the recent massive flood of frameworks, libraries and toolkits on the market these days it is easy to forget that underneath it all is the good old, plain and simple, PHP with all its kinks, quirks, and huuge set of builtin functionality.

PHP has vast amount of extensions which solve all sort of problems. And if PHP doesn’t have it built-in, we have an impressive amount of additional extensions both on pecl and now recently more and more on github.
There is a high chance that someone else has been in your shoes already and solved the problem, so it is worth looking around over the horizon and see if the problem has been solved already.

For some reason the current practice seems to be the “RoR” idiocy where “RoR developers” barely even know that there is this Ruby some miles down the stack. PHP has hit this “stepping stone” already with WordPress, Drupal and even Symfony and that is a weird and scary thought. Remembering “where you came from” is an important fact to remember, even for those who specialize in specific products. Looking at how other projects work, comparing notes, work ethics, features and functionality is also very important. Getting different perspective and knowledge is how we can improve our solutions and work more efficiently. If your specific product doesn’t have native support for something, why not look at a different framework/library/cms/toolkit/.. even PHP extensions?

As June mentioned earlier, going ‘back home’ and checkout the PHP manual pages is generally a good idea. Things change, manual pages are updated, improved, added, and you have different perspective, other problems to solve and so on. Even though you believe you know all the basics, you still need to practice them, and that includes browsing the manual from time to time, again and again – no matter which project it is.

So what is the best way to stay in touch? Kept up2date with new ways and offerings? New solutions to the same problem? Get involved!

By far the best way is to get involved with the project you are using. Even just silently idling on the mailinglists and read the subjects. Subscribing to the commit lists is a fantastic way to see precisly what is going on and see which direction the project is taking. Who knows, after a while you may spot something the others didn’t. Get an idea for a killer feature. Shed a light on different perspective the others didn’t think of. After a while hanging on the lists you’ll get a feeling for how the project works, and hopefully start chiming in. Give your 2cents, and who knows – even cook up a patch or two.

 Posted by at 4:37 pm
Feb 052009
 

FirePHP is a plugin for the Firebug Firefox extension. Similar to Y!Slow, the plugin hooks into Firebug and provides extra functionality.

Unlike Y!Slow, FirePHP does not create a “new tab” in Firebug. All it does is parse custom HTTP headers and print them out in the Firebug “console” tab. Since the messages have to be sent out as HTTP headers I have never been a great fan of FirePHP, simply because most of the time I would want to inject something to the console tab is looong after I have sent out the initial headers.

After few months of “ignoring the hype” I had to give it a try. My initial testing was just as I expected: This sucks. I had to reorganize all my code so I could send out the FirePHP headers – however doing so had a major impact on when the user got anything back from the page he requested, something I really do not want to do. Bye bye FirePHP.

Here at Redpill Linpro we use Symfony for most of our projects, which uses Output Buffering a lot. Hello FirePHP.

The benefits of using output buffering, among other things, is you can send out headers at any time in the script. That means, we can throw FirePHP messages even in the footers of pages.

So, what is it good for and how do we use it?

AJAX responses have always been a PITA to debug. In some cases we simply do not have any way to print out debug information without destroying the response it self, so we have to turn to flat-file-logging.. which symfony fills up with tons of useless information making it hard to browse. Using FirePHP however you can “print out” whatever information you want, directly to the Firebug console!

Other things like rendering timers, sql queries, backtraces and background info on error pages is great to throw into FirePHP.

To use FirePHP with Symfony you will have to install the Firefox extension itself (duhh) and then the PHP “client library”.
Note: To see the FirePHP messages you will have to enable the “Console”, “Script” and “Net” panels in Firebug!


$ symfony plugin:install sfFirePHPPlugin

The client library is oddly complicated but does do the job. It offers several “importance levels”, which get color coded, such as warnings, info and error. Furthermore you can group messages for easier access.

To, for instance, show the “Symfony Debug toolbar” timers for _all_ requests (including error pages and AJAX responses) you can add to the ProjectConfiguration class:

public function setup()
{
/* [snip] */
if ($this-&gt;environment === "dev")
{
$this-&gt;getEventDispatcher()-&gt;connect("response.filter_content", array($this, "responseFilterContent"));
$this-&gt;getEventDispatcher()-&gt;connect("application.throw_exception", array($this, "responseFilterContent"));
}

public function responseFilterContent(sfEvent $event, $content = null)
{
$fp = sfFirePHP::getInstance(true);

$fp-&gt;group("Debug timers");
foreach(sfTimerManager::getTimers() as $nfo =&gt; $timer)
{
$fp-&gt;info(sprintf("%s: %.2fms (%d calls)", $nfo, $timer-&gt;getElapsedTime() * 1000, $timer-&gt;getCalls()));
}
$fp-&gt;groupEnd();

return $content;
}

That should give you a nice little groupped “Debug timers” in the Firebug Console using the “dev” frontend \o/.

FirePHP screenshot

You always have FirePHP at your fingertips, to log to it just add

FirePHP::getInstance(true)->info("Hello world! :D ");

Happy debugging!.