Positive Feedback on Developer Companion
David Carroll
issues where the Developer Companion doesn't always refresh updated
logged data from the server. Before I revisit that issue, I want to
highlight how excited I am about using FirePHP with Developer
Companion. In just 2 days of active usage, I am becoming more
dependent on this tool as a developer. It's truly redefining and
improving the way I debug PHP when XDEBUG isn't an option to work
with. Better yet, I'm beginning to prefer using this tool over
debugging PHP with an IDE via the XDEBUG Extension. XDEBUG introduces
a lot of profiling overhead in the runtime that causes the web app to
run dreadfully slow. Therefore, XDEBUG isn't an option to use when
trying to troubleshoot issues isolated only on the production server.
Furthermore, my experience with finding a development IDE that works
as well as Visual Studio.NET hasn't been pleasant. I'll leave it at
that and avoid turning this into a passionate debate about development
platforms.
Although I have expressed that initial setup of this tool is a bit
involved and there may be an issue with Developer Companion refreshing
log output from the server, I am incredibly impressed by the quality
of the design approach for this app. The client tools will continue
to improve and is at a strong starting point for developer adoption.
In fact, Christoph Dorn, the developer of this library, has made
himself accessible and has proactively engaged with me regarding my
experience. This is one thing I truly appreciate as a developer. The
online support is already rich with documentation, which I know first
hand isn't easy to accomplish. Christoph indicated a more simplified
setup process will be released in a few months to help make this
easier for less experienced developers to adopt. However the 30 minute
video is a great alternative to follow in the meantime.
I'm also pleased to see the provisions made to restrict access to
logging information to a specified set of IP Addresses and to specific
clients with approved authorization keys. The configuration policies
are straight forward, but is very manual and format sensitive.
When evaluating this tool, I recommend doing more than just logging
simple messages. That would be like evaluating how well iPhone sends
text messages. Yet there is so much more to review that goes beyond
the basic tool. In the case of FirePHP, I'm quite impressed with the
following features:
1. Organizing Log Messages with Groups and Sub Groups and in Named
Tabs on Developer Companion.
2. Tracing Feature includes the following Rich Logging Details:
- Complete Stack Trace with Method Names, File Paths, and Line
Number.
- Collapsible and Expandable representation of all method
arguments. This is very similar to locals windows when debugging in an
IDE.
3. Output option to display large lists of name value pair arrays in
a clean Table Format.
4. The ability to click on a stack trace line or log output and view
the specific location in code from the Developer Companion.
DISCLAIMER: I've not gotten this to work yet. But I'm close to
figuring it out.
5. The ability to reload logging information without running a
complete page refresh. This is my favorite feature at the moment.
Reloading page requests from the Developer Companion eliminates all
the overhead of the browser rendering HTML, running javascript,
applying CSS styles, and downloading other media asset requests.
I'm only scratching the surface when you realize the vast potential of
features described in the API page: http://reference.developercompanion.com/#/Tools/FirePHPCompanion/API/.
I'll need to spend sometime reviewing the filtering options, extending
listeners, exception logging, benchmarking options, and so much more
I'm not aware of.
Finally, I'd like to revisit my initial issues with FirePHP clients
inconsistently refreshing values from the web server. Initially, I
found Developer Companion had some issues reloading current logged
information from the server. I would have to close the browser
completely in order to get new log info to reload. I am still working
through this issue. However, my explanation of this is a bit involved
and filled with speculations I've since ruled out. You can follow the
progress of this issue on the following thread:
http://groups.google.com/group/devcomp/browse_thread/thread/dc197fcc8a7e5401
Hope this initial feedback review helps those evaluating this tool.
David Carroll
DeveloperCompanion Support
> I've shared previous notes regarding initial feedback that describes
> issues where the Developer Companion doesn't always refresh updated
> logged data from the server. Before I revisit that issue, I want to
> highlight how excited I am about using FirePHP with Developer
> Companion. In just 2 days of active usage, I am becoming more
> dependent on this tool as a developer. It's truly redefining and
> improving the way I debug PHP when XDEBUG isn't an option to work
> with. Better yet, I'm beginning to prefer using this tool over
> debugging PHP with an IDE via the XDEBUG Extension. XDEBUG introduces
> a lot of profiling overhead in the runtime that causes the web app to
> run dreadfully slow. Therefore, XDEBUG isn't an option to use when
> trying to troubleshoot issues isolated only on the production server.
> Furthermore, my experience with finding a development IDE that works
> as well as Visual Studio.NET hasn't been pleasant. I'll leave it at
> that and avoid turning this into a passionate debate about development
> platforms.
I am happy to hear this. XDEBUG definitely has its use-cases but for
many tasks it is too heavy, restrictive or cumbersome to use.
The Companion will include a fully-featured interactive XDEBUG client in
future which will integrate tightly with FirePHP so you can use the two
tools together with the same UI during the same session.
> Although I have expressed that initial setup of this tool is a bit
> involved and there may be an issue with Developer Companion refreshing
> log output from the server, I am incredibly impressed by the quality
> of the design approach for this app. The client tools will continue
> to improve and is at a strong starting point for developer adoption.
> In fact, Christoph Dorn, the developer of this library, has made
> himself accessible and has proactively engaged with me regarding my
> experience. This is one thing I truly appreciate as a developer. The
> online support is already rich with documentation, which I know first
> hand isn't easy to accomplish. Christoph indicated a more simplified
> setup process will be released in a few months to help make this
> easier for less experienced developers to adopt. However the 30 minute
> video is a great alternative to follow in the meantime.
The design I have chosen aims to standardize a chained console logging
API across programming languages. Now that PHP is supported I will be
bringing the same API online for client and server-side JavaScript.
After that we can look at ruby, python and other languages (scripting
and compiled).
The Companion tool (on the client) is language agnostic and designed to
work on top of open protocols and interfaces. As these evolve I
anticipate alternative clients and IDE plugins that support the same
intelligence protocols and a subset of the UIs. To ensure this is
realistic 80+% of the client code is MIT licensed and will be documented
for embedding into any JavaScript environment. This will allow easy
integration into most IDEs.
The client has evolved internally over the past year and is due for a
major refactoring. I have started this process by pulling together all
my research and prototypes into a state-of-the-art CommonJS based
JavaScript module loader that will provide the infrastructure for a
client tool composed of many hundreds of code packages (some shipped
with the release, others downloaded dynamically when needed). You can
find the loader here:
https://github.com/pinf/loader-js
I expect the refactoring to be complete within the next couple of months
with the following changes:
- Firefox 4 support (required)
- Use of the PINF JS Loader on top of Jetpack [1]
- Use of ExtJS 4 for the UI [2]
- Use of the Ajax.org ACE editor [3]
- Reduction in release file size
- Much faster UI loading
- More efficient internal data handling
- More extensive project explorer features
- Isolated live remote code editing for production applications
- Relaunch of FirePHP and DeveloperCompanion sites & docs
[1] - https://github.com/pinf/loader-js/tree/master/demos/JetpackExtension
[2] - http://www.sencha.com/products/extjs4-preview/
[3] - http://ace.ajax.org/
Once this work is done I will be shifting focus to new features in
various areas.
> I'm also pleased to see the provisions made to restrict access to
> logging information to a specified set of IP Addresses and to specific
> clients with approved authorization keys. The configuration policies
> are straight forward, but is very manual and format sensitive.
The configuration will be automated via the Companion Explorer in
future. The goal is to remove the need for any manual configuration for
all common use-cases. Everything needs to work out of the box.
> When evaluating this tool, I recommend doing more than just logging
> simple messages. That would be like evaluating how well iPhone sends
> text messages. Yet there is so much more to review that goes beyond
> the basic tool. In the case of FirePHP, I'm quite impressed with the
> following features:
This is a good point. My focus has been on providing a complete base
featureset that we can build on top of. Now that this is mostly complete
we can spend time on abstracting the API and providing domain-specific
APIs for various design patterns and frameworks/components. The library
has a powerful plugin API that can be used to accomplish this. I hope
the community will pick up this responsibility in time so we have
components that work out of the box for all major frameworks. I will be
working on one reference implementation for Zend Framework 2 later this
year that showcases all integration points and what can be done with the
system overall.
Thanks for the kind words and feedback. It's nice to hear someone else
pick up on design choices and the thinking behind features that I
arrived at after much experimentation and refining.
Christoph
David Carroll
with your vision. Leveraging a common integration protocol this early
in your project is such a forward thinking way to encourage an
ecosystem of community support. I can imagine open source projects
starting up for the .NET, Java, Ruby, Cocoa, Android, and other
mainstream server side communities.
I can only imagine what you have in mind with the Ajax.org ACE Editor.
Perhaps live code execution / debugging via Companion? Do you have any
other community contributors helping you with this now? Although I'm
knee deep in getting a release out for a project I'm working on now, I
would not mind evangelizing and perhaps jumping in on some development
to help out.
In the meantime, I look forward to seeing this evolve over time.
DeveloperCompanion Support
> Wow... I don't know where to start with how impressed and excited I am
> with your vision. Leveraging a common integration protocol this early
> in your project is such a forward thinking way to encourage an
> ecosystem of community support. I can imagine open source projects
> starting up for the .NET, Java, Ruby, Cocoa, Android, and other
> mainstream server side communities.
Thanks for the encouragement.
Seeing how quickly FirePHP gained popularity after I completed the Zend
Framework component I realized the potential of this approach to assist
debugging and development for any application/frameworks/libraries. The
challenge was to come up with a design and API that is language agnostic
and flexible enough to accommodate various requirements.
My focus is PHP and JavaScript right now to get the system running end
to end after which I will be actively supporting server library
implementations for various languages and platforms you mentioned.
> I can only imagine what you have in mind with the Ajax.org ACE Editor.
> Perhaps live code execution / debugging via Companion? Do you have any
Right. That will be the first feature after I complete the refactoring.
You will be able to connect to any application, even on production
servers, create a live editing session to make changes and when done
take them live on the site or commit a diff to git etc... This way you
don't need a local dev environment. This will work for most sites that
run on single servers. For larger systems there will be more advanced
integration points to support various workflows.
> other community contributors helping you with this now? Although I'm
I have various offers of assistance but nobody helping yet (other than
bug reports and testing). It is still a few months too early to get
involved in any of the core code. Part of the refactoring will involve
rebooting the open source core projects to make it easier to contribute.
> knee deep in getting a release out for a project I'm working on now, I
> would not mind evangelizing and perhaps jumping in on some development
> to help out.
Thanks for your offer. At this time evangelizing would probably be the
most effective in the form of tutorials and screencasts. Also taking the
core API and documenting various abstractions that are useful when
integrating into a larger application. This is an area I have not
explored much.
I think currently new users are overwhelmed as the docs are quite
technical and there are no real examples of how FirePHP can be used to
solve real problems.
As soon as I can generate a sufficient revenue stream I will be hiring
developers to expand on every aspect. Any assistance to get to this
point would be greatly appreciated as I can only do so much myself.
Christoph
DeveloperCompanion Support
On 11-03-18 8:11 AM, DeveloperCompanion Support wrote:
> On 11-03-17 5:48 PM, David Carroll wrote:
>> knee deep in getting a release out for a project I'm working on now, I
>> would not mind evangelizing and perhaps jumping in on some development
>> to help out.
If you like a challenge you could try and fix this:
http://groups.google.com/group/ace-internals/msg/f2eeb19e52824747
It would allow me to focus in a different area.
Christoph