When developing an application there are some important factors that you have to pay close attention to avoid problems in the future. I think one of the most important is logging information on how your application is working and when it fails.

Must of us like to log only big exceptions and fatal errors, but the truth is, that when you are in the development process it’s very important to keep track of not just errors, but important information of when something gets executed. As a web developer one of the most important tools to have is FireBug. If you didn’t know, FireBug has an API that you can use to send console messages for logging purposes, when debugging JavaScript. But, did you know you can use FireBug to debug your php applications?

Through Wildfire, a project that was created to help developers have a standard way for sending messages between different programming languages and scripts. The Zend Framework is now able to communicate to the Firebug console in order to display logging messages injected by PHP.

Using this component is pretty straight forward if you are using Zend_Controller_Front (MVC) with zend Framework.

Place this in your bootstrap file before dispatching your front controller

$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

Then whenever you want to log something to Firebug just use it in your model, view, or controller like this.

$logger->log('This is an INFORMATIONAL log message!', Zend_Log::INFO);
$logger->log('This is a WARNING log message!', Zend_Log::WARN);
$logger->log('This is an ERROR log message!', Zend_Log::ERROR);

If you notice in the example above, you can specify the type of message you want to log (INFO, WARN, etc..). This is helpful when you want to clearly identify what type of message you are viewing since it will apply a special formatting and in some instances provide more information.

If you want to use the Zend_Log_Writer_Firebug as a stand alone here is the sample code you can use:

//Instantiate the Firebug Writer
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

//start the wildfire component
$request = new Zend_Controller_Request_Http();
$response = new Zend_Controller_Response_Http();
$channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
$channel->setRequest($request);
$channel->setResponse($response);

// Start output buffering
ob_start();

// Now you can make calls to the logger

$logger->log('This is a log message!', Zend_Log::INFO);

// Flush log data to browser
$channel->flush();
$response->sendHeaders();

If you don’t use ZendFramework there is another alternative to php developers. FirePhp, will also enable you to send log messages to Firebug by using php method calls. Be sure to check FirePhp website to get more information.

So remember that this is just one easy and great way to debug your projects, there are many other tools and methods you can incorporate into your projects. If you want to share other ways or simply just want to ask a question regarding this post, feel free to leave a comment.

According to Joe Hewitt, developer of the facebook app. Version 3.0 of the facebook application has already been submitted to apple, and it’s waiting for approval.

Here is what’s new on the version of the app will contain:

• New and improved Home screen that allows you to create shortcuts to your favorite friends and Pages
• Events: the new events screen will allow you to see your upcoming Events and RSVP
• Pages: support for pages was added so you can easily see and become fan of Pages and if you are a Page admin you can now post updates and photos to your pages.
• Birthdays: see your friends’ b-days.
• Notes: now you can write Notes and read your friends’ Notes
• Complete photo management (create albums, delete albums, delete photos, delete photo tags, Upload photos to any album)
• Upload videos from an iPhone 3GS
• Change your Profile Picture
• Zoom into photos
• Like functionality was added so you can like posts and photos
• See the same News Feed as the Facebook website
• Visit links in a built-in web browser
• See all of your friends’ friends and Pages
• See mutual friends
• Easily search for people and Pages
• Make friend requests
• Quickly call or text your friends
• Friends sorted by first or last name according to your settings
• Chat friends sorted alphabeticaly

There are a few missing functionality that we have been waiting for. But Joe Hewitt already mentioned in his twitter account that he already started development of version 3.1 of the facebook app and it will include “Push Notifications” and “Landscape Mode” and I guess he will throw in a few more small features.

Now with version 3.0 of the facebook application Will we ever need to go into the full facebook.com website? I guess that depends on how you use facebook, but, in my opinion I will be visiting the site less.

Update: According to the developer of the application the update it’s live on the iPhone App Store. So go grab it and let us know what you think.

Working now on some iGoogle like dashboard for the system I’m developing.

I was trying some stuff out with CURL and was having a hard time to maintain my current session when making a curl request to another page. I needed to stay authenticated in order to retrieve my widget.

Here is my initial code:

$strCookie = 'PHPSESSID=' . $_COOKIE['PHPSESSID'] . '; path=/';
$ch = curl_init($rssFeedLink);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt( $ch, CURLOPT_COOKIE, $strCookie );
$response = curl_exec($ch);
curl_close($ch);

The problem with that piece of code is that it was generating a new session id instead of sending my current session.

The solution? Put session_write_close() before you make the CURL request.

$strCookie = 'PHPSESSID=' . $_COOKIE['PHPSESSID'] . '; path=/';

session_write_close();

$ch = curl_init($rssFeedLink);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt( $ch, CURLOPT_COOKIE, $strCookie );
$response = curl_exec($ch);
curl_close($ch);

What does session_write_close() do? It, ends the current session and store session data. Apparently, PHP does not like when multiple scripts play around with the session, so, it locks it. Putting session_write_close makes sure that your current session is stored so you can retrieve it and use it.

This little issue had my head spinning for a few hours, so, I hope this article helps you.

$rssFeedLink = 'http://www.smooka.com/blog/';
$cacheId = 'rss_feed';

$frontendOptions = array(
		   	'lifetime' => 1800, // cache lifetime of 30 mins
		   	'automatic_serialization' => true);

$backendOptions = array(
		    	// Directory where to put the cache files
		    	'cache_dir' => '/cache/'
			);

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core','File', $frontendOptions, $backendOptions);

if (!$rss = $cache->load($cacheId)) {
	try {
		$rss = Zend_Feed::import($rssFeedLink);
	} catch (Exception $e) {
		$feedError = true;
	}

	//check to see if it did not fail
	if (!$feedError && is_object($rss))
	{
		$cache->save($rss, $cacheId);
	}
}

//assuming that everything went right while fetching the feed
foreach ($rss as $item) {
	$channel['items'][] = array(
		'title'       => $item->title(),
		'link'        => $item->link(),
		'description' => $item->description()
	);
}

While iterating through the feed, the script would output the following message “Warning: Invalid argument supplied for foreach()”, under, “Zend/Feed/Element.php on line 322″ on an empty cache.

It appears that Zend_Feed and Zend_Cache do not get along, I’m pretty sure it’s a bug since it looks like Zend_Feed_Rss is sent to sleep by the $cache->save() call and it’s not waking up automatically. The solution that I found it’s pretty straight forward. Just modify the following piece of code.

if (!$feedError && is_object($rss))
{
	$cache->save($rss, $cacheId);
	//ADD a wakeup call to the RSS object
	$rss->__wakeup();
}

That should do the trick!

After I fixed the issue, I went back to the drawing board and decided that it was more efficient to cache the actual HTML output, instead of the returned object by Zend_Feed. That seems to work just fine, since the call to $cache->save() is done after the iteration of the feed items. That fixes the issue and at the same time you are eliminating the need to iterate and re-build the HTML every time the page is loaded.

Hope this information helps you, and if you have any questions or comments be sure to post them here.