Initial Feedback on FirePHP 1.0 with Developer Companion
David Carroll
* Kudos on this Project:
**************************
Let me start off by saying how impressed I am with the direction this
tool is going. Although I've been working with Java and .NET for the
past decade, I'm relatively new to PHP. I've been doing a lot of
debugging with XDebug on the server side and Firebug on the client
side. It's taken me a while to understand how to use FirePHP beyond
surface level logging.
**************************
* My Setup Experience:
**************************
As you mentioned in your video, it's definitely a starting point to a
vast set of possibilities to improving development productivity. It
took me a little while to get my initial setup working from FirePHP
0.3 to FirePHP 1.0 with the DeveloperCompanion. However, my local
development server and production environments are now "somewhat"
setup.
**************************
* Environment Overview:
**************************
I've noticed some inconsistent issues with the DeveloperCompanion and
hope me sharing these details will be helpful in your efforts to
continue improving this tool. To establish a baseline on my
environments, I'm developing locally on Windows 7 using XAMPP and
debugging a WordPress 3.1 Multisite setup. I host a live production
site on a CentOS Linux Virtual Server and essentially run into the
same issues.
My configurations and setup have been fully validated using the client
and server test tools provided. Also, I've successfully retrieved
logs and traces in both the FirePHP Client running in Firebug and in
the DeveloperCompanion. This is just day 1 of my trial period, so, I
have 6 days remaining in my evaluation.
**************************
* Problems Observed:
**************************
Essentially, the two FirePHP clients (Firebug Companion and Developer
Companion) behave very inconsistently with respect to capturing
logging information. At first, I could not get Developer Companion to
present any logged information at all. After restarting Firefox and
reinstalling the FirePHP addons multiple times, I was able to finally
get information to display in Developer Companion. Please note,
Firebug Companion was receiving logged data with no problems and
Developer Companion indicated client and server tests were
successful.
When I was able to get Developer Companion to finally display results,
it would not always update on refresh. Firebug Companion would show
updated information upon manual code changes. Developer Companion
would not display expected logging info when clicking the builtin
"Reload" button, or when clicking the "Inspect with Companion" link
from Firebug. At somepoint in my evaluations, Developer Companion
began to update more frequently. I then began to notice the Firebug
Companion was not consistently showing logged info in the Firebug
Console while Developer Companion was being updated.
At this point, the Firebug Companion has proven to be more consistent
and reliable with refreshing updated logging data. Despite some of
the improved data capture of logged information, there have been other
issues that just haven't improved. I'll list a few of those issues
below.
1. Trace Data would sometimes not display at all or with any
indication of error.
2. Developer Companion never displays the code file with line when
clicking the binary looking icon for this feature.
- Rather, I only get a black square with the text: The file is not
accessible
3. Developer Companion appears to cache tabs with logged content, even
after I completely changed the code that defined that tab. Instead,
the new tab name would appear next to the old tab.
4. When both Developer Companion and Firebug Companion both appear to
not release old logging content, I have to close FireFox down
completely to fully reset the cached content.
There is so much more detail I could provide, however, I've covered
the big issues for now. The rest of this is more information to help
you isolate any specific reasons I'm running into these issues.
****************************************************
* Regarding Configuration Updates:
****************************************************
I eventually modified my credentials.json file to accept "*" for
allowed IPs and for Authorization Keys to see if there was something I
did wrong here. This setting made no difference in my experience. The
following configuration content appears consistently fine in the
Developer Companion regardless of logging issues:
- Package ("description")
- Request ("url")
- File ("message source")
****************************************************
* Regarding Code Samples:
****************************************************
I've been experimenting with very basic logging statements to output
simple strings to simulating recursive function calls to test stack
traces. The code I've provided below works as it is. However, the
logged output is not consistently captured by both clients.
****************************************************
* Sample Code: FirePHP.Activate.php
****************************************************
<?php
define('INSIGHT_CONFIG_PATH', ABSPATH . 'FirePHP/Companion/
package.json');
require_once('phar://' . ABSPATH . 'FirePHP/Companion/firephp.phar/
FirePHP/Init.php');
//Simple method to test FirePHP in tracing a recursive method.
function Create_Stack($source, $current_count, $max_count, $logger)
{
//Allow for group names to be distinct.
$current_group_name = 'Group_' . $source . '_' . $current_count;
$logger->group($current_group_name)->open();
$logger->info('Trace Method: Create_Stack()'); //Group Label
//Continue recursive call until current count matches max count.
if ($current_count < $max_count) {
//Create debug trace statement before recursive call.
$logger->trace('Recursively Calling: Create_Stack() from ' .
$source);
//Make recursive call.
$current_count = Create_Stack($source, $current_count + 1,
$max_count, $logger);
}
//Close up the current Group for the Current Stack.
$logger->group($current_group_name)->close();
//Only do this 1 time.
if ( $current_count == 1 ) {
//Demonstrate PHP Variable Scope and log output.
$logger->log('isset($console): ' . ( isset( $console) ?
'true' : 'false'));
$logger->log('isset($logger): ' . ( isset( $logger ) ?
'true' : 'false'));
}
return $current_count;
}
//Setup $console as FirePHPActivate
$console = FirePHP::to('request')->console('FirePHP_Activate');
$console->info('First FirePHP Activated');
//Monitor / Track to see if each traced stack is displayed in
DeveloperCompanion.
$logResult = Create_Stack('FirePHP.Activate.php', 0, 5, $console);
//Wrap it up....
$console->info('Finally :: Create_Stack() was called ' . $logResult .
' time(s)');
?>
****************************************************
* Sample Code: index.php (Code Snippet)
****************************************************
<?php
require_once(ABSPATH . 'FirePHP/FirePHP.Activate.php');
$dbg_console = FirePHP::to('request')->console('FirePHP_Index');
$dbg_console->info('Second FirePHP Activated');
$logResult = Create_Stack('Index_Page', 0, 3, $dbg_console);
?>
Best Regards,
David Carroll
DeveloperCompanion Support
> **************************
> * Kudos on this Project:
> **************************
> Let me start off by saying how impressed I am with the direction this
> tool is going. Although I've been working with Java and .NET for the
> past decade, I'm relatively new to PHP. I've been doing a lot of
> debugging with XDebug on the server side and Firebug on the client
> side. It's taken me a while to understand how to use FirePHP beyond
> surface level logging.
I appreciate you taking the time to provide your feedback. It really
helps me assess where I am at and where I need to go.
> **************************
> * My Setup Experience:
> **************************
> As you mentioned in your video, it's definitely a starting point to a
> vast set of possibilities to improving development productivity. It
> took me a little while to get my initial setup working from FirePHP
> 0.3 to FirePHP 1.0 with the DeveloperCompanion. However, my local
> development server and production environments are now "somewhat"
> setup.
The setup procedure will be overhauled in the next couple of months. I
have received a lot of feedback about it and the general consensus is
that it is too involved and targets an experienced audience which limits
it's adoption.
My focus so far has been on getting the underlying infrastructure stable
and ensuring the configuration and integration points are sufficient to
accommodate simple and complex setups.
It is now time to refine the introduction into various stages of
commitment to get users started easily and provide a clear guide if they
choose to use more advanced features.
I would greatly appreciate your feedback as the new docs and tutorials
come online.
> **************************
> * Environment Overview:
> **************************
> I've noticed some inconsistent issues with the DeveloperCompanion and
> hope me sharing these details will be helpful in your efforts to
> continue improving this tool. To establish a baseline on my
> environments, I'm developing locally on Windows 7 using XAMPP and
> debugging a WordPress 3.1 Multisite setup. I host a live production
> site on a CentOS Linux Virtual Server and essentially run into the
> same issues.
This is a typical setup and should be fully supported.
> My configurations and setup have been fully validated using the client
> and server test tools provided. Also, I've successfully retrieved
> logs and traces in both the FirePHP Client running in Firebug and in
> the DeveloperCompanion. This is just day 1 of my trial period, so, I
> have 6 days remaining in my evaluation.
I am happy to hear you were able to get it all running in your setup in
a day. That is definetely encouraging.
I sent you a free license in appreciation of your feedback.
> **************************
> * Problems Observed:
> **************************
> Essentially, the two FirePHP clients (Firebug Companion and Developer
> Companion) behave very inconsistently with respect to capturing
> logging information. At first, I could not get Developer Companion to
> present any logged information at all. After restarting Firefox and
> reinstalling the FirePHP addons multiple times, I was able to finally
> get information to display in Developer Companion. Please note,
> Firebug Companion was receiving logged data with no problems and
> Developer Companion indicated client and server tests were
> successful.
>
> When I was able to get Developer Companion to finally display results,
> it would not always update on refresh. Firebug Companion would show
> updated information upon manual code changes. Developer Companion
> would not display expected logging info when clicking the builtin
> "Reload" button, or when clicking the "Inspect with Companion" link
> from Firebug. At somepoint in my evaluations, Developer Companion
> began to update more frequently. I then began to notice the Firebug
> Companion was not consistently showing logged info in the Firebug
> Console while Developer Companion was being updated.
Hmm. These issues should not be happening and I have not noticed this
before. I wonder if something is getting cached somewhere.
Most confusion centers around FirePHP::to('page') vs
FirePHP::to('request') and the fact that request data needs to be loaded
into the companion by triggering an inspect. This is a temporary
solution until I have a UI that tracks inspectable requests within the
companion (coming in the next couple of months). At that time you can
just click on the request in the companion or setup a "watch that URI".
> At this point, the Firebug Companion has proven to be more consistent
> and reliable with refreshing updated logging data. Despite some of
> the improved data capture of logged information, there have been other
> issues that just haven't improved. I'll list a few of those issues
> below.
>
> 1. Trace Data would sometimes not display at all or with any
> indication of error.
I would be interested to troubleshoot this via a remote screen sharing
session.
> 2. Developer Companion never displays the code file with line when
> clicking the binary looking icon for this feature.
> - Rather, I only get a black square with the text: The file is not
> accessible
That means your INSIGHT_PATHS constant or
implements['cadorn.org/insight/@meta/config/0'].paths config option in
package.json is not listing the roots of all your code trees for the
application.
> 3. Developer Companion appears to cache tabs with logged content, even
> after I completely changed the code that defined that tab. Instead,
> the new tab name would appear next to the old tab.
Hmm. I don't see how that can happen. I would be interested to
troubleshoot this via a remote screen sharing session.
> 4. When both Developer Companion and Firebug Companion both appear to
> not release old logging content, I have to close FireFox down
> completely to fully reset the cached content.
Ok. There is definitely something up. That should never be needed.
> There is so much more detail I could provide, however, I've covered
> the big issues for now. The rest of this is more information to help
> you isolate any specific reasons I'm running into these issues.
I understand. It is hard to assess something when stuff like this is
happening :)
> ****************************************************
> * Regarding Configuration Updates:
> ****************************************************
> I eventually modified my credentials.json file to accept "*" for
> allowed IPs and for Authorization Keys to see if there was something I
> did wrong here. This setting made no difference in my experience. The
> following configuration content appears consistently fine in the
> Developer Companion regardless of logging issues:
> - Package ("description")
> - Request ("url")
> - File ("message source")
If you get anything logged or showing up in the client your server
config is correct. The tool is designed to be unforgiving when
encountering any config problems to ensure proper security.
> ****************************************************
> * Regarding Code Samples:
> ****************************************************
> I've been experimenting with very basic logging statements to output
> simple strings to simulating recursive function calls to test stack
> traces. The code I've provided below works as it is. However, the
> logged output is not consistently captured by both clients.
I'll take a look at this and respond in a second message.
It would be great if we could jump on skype some time to troubleshoot
the caching issue you are experiencing.
My skype ID is: christophdorn
You can ping me any time.
Thanks again for the feedback!
Christoph
--
-------------------------------------------
Christoph Dorn - www.developercompanion.com
DeveloperCompanion Support
So I took a look at your code and after fixing a bug in it [1]
($current_count == 1 was never called) the output seems to be correct.
Rather than compare the output to the FirePHP 0.5.0 client extension I
would prefer to fix what you feel is incorrect/missing in
FirePHP/Developer Companion output.
I ended up fixing a bug in the object depth trimming and excluded the
Insight_Helper object from the output by default:
http://reference.developercompanion.com/#/Companion/News/
Also in your sample code I set the encoder.maxObjectDepth option to 1 so
less data is sent to the client for faster testing.
So if you want to take another look at the output with the new release
and updated sample we can go from there. It looks correct to me.
Christoph
On 11-03-10 6:35 PM, David Carroll wrote:
--
David Carroll
**********************
* Summary Recap:
**********************
Originally, I was testing this by changing the PHP logging code and
clicking the "Reload" button from the Developer Companion to see the
updated log info. I repeated this step until Developer Companion
stopped showing updated logging information. NOTE: When I run into
this problem, the Developer Companion does not appear to have an
issue. Clicking the "Reload" button shows an AJAX progress indicator
giving the impression it is querying the log data. The AJAX progress
indicator disappears and the button becomes clickable once again.
However, the log data is not updated as expected. I can repeat this
with no change simply by clicking the Reload button and seeing no
change in the data. At this point, I have to restart FireFox browser
to retrieve current log info.
**********************
* Status Update:
**********************
Your feedback helped me determine my issues were not related to
configuration, security, or caching. I then speculated the issue may
be that Developer Companion actually stops sending requests to the
server. I decided to test this with XDEBUG by placing server side
break points in my code and verifying each request made by clicking
the Reload button from Developer Companion. After establishing code
execution stops at the designated break point, I repeated clicking the
Reload button from Developer Companion until the break point was no
longer responsive. I then tested changing the log message in the PHP
code and clicked Reload. The old log message remained in DevComp and
the break point was not reached. I then refreshed the Firefox Browser,
let the page refresh, looked for the Insight tab and saw there was no
link to "Inspect with Companion". Instead of the link, the Insight
Tab displayed "No messages". NOTE: The page fully reloads in the
browser indicating the server is handling requests from the browser.
The only way to reset FirePHP is to restart Firefox completely. Based
on these results, here is what I've assessed:
1. Requests from Developer Companion is rejected by the server.
2. Browser requests are not ignored by the server.
3. FirePHP Log Messages are not appended to the response and
therefore FirePHP shows No Messages.
This issue is only reset once I completely restart the Firefox
browser. I'm starting to wonder if there is another Firefox plugin
causing a conflict.
I'll continue troubleshooting this over the weekend. In the meantime,
thanks again for creating such a great tool.
Best Regards,
David Carroll
DeveloperCompanion Support
> I'm getting closer to isolating the source of the issue.
>
> **********************
> * Summary Recap:
> **********************
> Originally, I was testing this by changing the PHP logging code and
> clicking the "Reload" button from the Developer Companion to see the
> updated log info. I repeated this step until Developer Companion
> stopped showing updated logging information. NOTE: When I run into
> this problem, the Developer Companion does not appear to have an
> issue. Clicking the "Reload" button shows an AJAX progress indicator
> giving the impression it is querying the log data. The AJAX progress
> indicator disappears and the button becomes clickable once again.
> However, the log data is not updated as expected. I can repeat this
> with no change simply by clicking the Reload button and seeing no
> change in the data. At this point, I have to restart FireFox browser
> to retrieve current log info.
This sounds like a memory leak related issue and I should be able to
reproduce it. It's unfortunate that this has come up but am not really
surprised as the internals are not as clean as I would like (will
undergo major refactoring in the next couple of months).
I'll let you know when I find something.
Christoph
--
DeveloperCompanion Support
I have been able to reproduce this issue.
It seems to fail consistently on the 22nd reload with various payload
sizes. So it is probably not a memory related issue.
Can you confirm it happens on the 22nd reload for you as well.
Christoph
DeveloperCompanion Support
Firefox 4 work. Consequently in the interest of making progress on this
work I will not be providing a fix for this issue at this time.
I expect the reload button to work as intended with the FF4 release.
Christoph