Chaparral thanks ISO Productions for permission to post the full review.
Analyze with speed, repair with confidence
by Chuck Ross email@example.com
VERSION: FileMaker Pro 5.0 required, Mac OS 8.6 required
PLATFORM: Macintosh & Windows
TECHNIQUE FILES: None
The right tool for the right job
Remember when you first started using FileMaker? There was really only one tool available to help with database development: FileMaker itself. Now there are dozens of tools available to help create and manage large collections of files. This is both powerful and daunting. It's wonderful because files are now much more complex than they were years ago, and unfortunately, FileMaker doesn't yet provide many of the tools that could make our lives a bit easier. However, it's daunting because of this reason, how do we know which tools are the best to use? Is FileMaker Developer enough for our needs, or should we take a closer look at other third party tools that can help us out? What tools are available? What do they accomplish? Which are worth purchasing?
Obviously, the answers to these questions will differ for each developer. What this article will begin is a series of articles that can help you answer these questions. If you know of a product you've found especially useful in your development, or you've created a developer tool for use with FileMaker, let me know so we can let the rest of the FileMaker community reap the benefits.
What Is Brushfire?
The first tool we're taking a look at is probably the newest of the developer tools available. Chaparral Software, the developer of Brushfire, bills the software as a script debugging tool. It will look at the scripts from a set of files and document the steps and interrelations of those scripts, flagging potential problems and giving the developer a bird's-eye view of the system, including the ability to trace the tree of a script as it calls other scripts.
[Editor: Chaparral claims Brushfire is the only FileMaker developer tool that will drill down the full branch of any external script's hierarchy by providing full references to called scripts and their subscripts.]
Brushfire is available for both Macintosh and Windows platforms. The Windows version is a bit quicker and more automated than the Mac version due to the fact that Print2Pict, another third party software add-on, must be used to collect the output of the script list for each file being documented. You can download a demo from http://www.chapsoft.com/brushfire/.
Light My Brushfire
Brushfire is available for $99.95 for either Macintosh or Windows. The Print2Pict printer driver is included in the Macintosh version and the Windows version includes a few EXE files to automate things. If you're on a Macintosh add another $10 to the price for Print2Pict.
Using Brushfire is fairly straightforward - once you get it installed, which can be a bit lengthy if you don't know what you're doing. After installing the software and configuring, you print all of the scripts in your solution to text files. On Macintosh this is done using Print2Pict. On Windows you must walk through the process of setting up a Generic Printer that prints to a file. The documentation provided by Chaparral is straightforward but lacking in visual guidance for the Windows setup. It would have been nice to see screen shots to establish familiarity while setting things up. The process isn't quite as easy as clicking one button but for most developers will be worth while once they have the software running.
If using Brushfire on a Macintosh be sure to avoid installing Brushfire on the desktop, as according to the documentation, it won't work properly there. With the Macintosh version I decided to install it in the same folder as FileMaker. The Brushfire program, which uses a FileMaker database as its front end, analyzes the scripts, tracking links between scripts and flagging errors (such as a missing files in a Perform Script [External] call). The software then creates a set of HTML files and provides a button to open those files.
Using HTML seems, to me, a novel way to display the reports. However, doing so has the disadvantage of creating thousands of files on your hard drive, which can accumulate in size easily. The report I ran produced 2,697 files that totaled 13.8 MB of hard drive space. The report appears in three frames, showing a main menu, a script listing, a cross reference section, and a call sequence of scripts. The main menu has links to each of the files analyzed. When one of the file links is clicked, it shows a list of the scripts within that file, showing how many errors are in each script, how many scripts call each script, and how many scripts each script calls. You can view example reports at http://www.chapsoft.com/brushfire/samples.html.
In the far right frame of the HTML report is a cross reference section that lists all of the layouts in the file, showing each of the scripts that reference each layout. This is handy to show which layouts can be deleted or altered. For instance, I often use a developer layout for scripts that need to have a Replace step in them, and once I add a field to a developer layout, I never take it off. But let's say you don't use that technique, and you use a layout that also serves some other purpose. Let's say the other purpose is no longer valid. Using Brushfire, you would quickly find out if the layout is referenced by any scripts and can determine if you can safely delete it.
Brushfire also shows you all of the layouts used within scripts, so you can get a clear idea of what the navigational requirements of your solution are. If you're developing complete solutions, where you handle all of the navigation with scripts the reports created by Brushfire are great for making sure your custom navigation is complete.
Raising a Red Flag
Once you are looking at the list of scripts in a file, clicking on the link for one of the scripts brings you to a listing of the script's individual steps with links to external scripts that are called. Good use is made of the hypertext capabilities of HTML and the web browser, making navigation between scripts very easy. Another nice feature is the comprehensive information about script cross-linking between each file's scripts.
Below the listing for a given script are listings of all the scripts that script calls, as well as the listing for all the scripts that call it. The entire structure of a script's function is provided from beginning to end. And since the entire report is in HTML frames, if you want to see more of the report on the screen, you can open any of the frames in a new browser window. This also makes it easy to print only one portion of the report rather than all three panels.
Scripts that have problems are flagged with a red dot. The script listing, by default, is in the order in which the scripts appear in ScriptMaker, and the software is intelligent enough to know that scripts with a dash for a name are dividers. I tend to have extensive organization of my scripts in ScriptMaker, so having my heading scripts (such as "Developer", "Startup/Shutdown", "Navigation", etc.) in the same order as they appear in ScriptMaker is quite handy, and having the dividers appear as HTML horizontal rules is also helpful.
When you look at the listing of one of these scripts, the problem script step is in red. Usually this is a file missing or "script unknown" problem, although there is currently a known bug which sometimes flags external script calls as errors when the file name referenced in the script call takes out the ".fp5" extension and the file has that extension. Chaparral is aware of this problem, and plans to have it fixed in a future update. In addition to being able to see within a file whose script's have errors, the main menu frame has a link to show all of the scripts in all of the files that have errors.
Brushfire also shows you those scripts that reference files by using embedded IP addresses. This helps alert you to the scripts that may need to be changed when the solution is delivered to a client.
When you have the need for speed
Some developers may be familiar with Analyzer, a utility that can perform many of the functions of Brushfire. Brushfire, rather than being all things to all people, does one thing, and it does it well - script analysis. The biggest advantage of Brushfire is its speed. On a solution with 23 files with over 1,600 scripts and almost 10,000 lines of code, Brushfire analyzed the scripts and produced the report in less than one minute on a PowerBook G3 400 MHz. To get the same information out of Analyzer took around one hour and 34 minutes. I'm sure I'm not the only developer using Analyzer that has a machine dedicated to running it on files so I don't tie up my primary development machine. This isn't a complaint against Analyzer, just some well deserved praise for Brushfire. Analyzer takes longer because it also gathers information about fields, relationships, and other FileMaker objects whereas Brushfire handles only scripts. Brushfire is also faster because its engine was created with C++, whereas Analyzer uses AppleEvents through a third party utility called OneClick.
The speed issue proposes that some things are definitely possible with Brushfire that you wouldn't want to do with Analyzer. When I want to run Analyzer on a solution, I either do so on a second machine, or I run it over my lunch hour or overnight. No matter what I do, however, I know I'm not going to get the information I need for quite some time. Brushfire is so quick, you can run it any time during your development cycle and have usable results in under a minute.
One of my requests for Brushfire would be more automation of the analysis procedure on Macintosh when using Brushfire. The Windows version provides a level of automation that makes printing the scripts for each file automated. Having used it on a Macintosh to analyze a system of 23 files, which I didn't prepare in advance for analysis, I had to manually print all of the scripts in each file. Chaparral decided, seemingly for simplicity sake, to develop Brushfire without the need for any third party extensions (not including the Print2Pict printer driver). I probably would have gone ahead and used something like OneClick to automate the printing of all these scripts just to make things easier. Chaparral suggests that developers include FileMaker scripts that automatically print all scripts, if you decide to use Brushfire as part of your development environment, this wouldn't be at all difficult, but it doesn't ease the process for documenting and troubleshooting existing projects.
Another point of automation that would be nice is to let the computer change the printer driver just prior to analysis and change it back when it's finished. On more than one occasion while using Analyzer, which also uses the Print2Pict printer driver, I've begun to run an analysis only to find out I hadn't changed the printer driver, requiring me to cancel the process and start over. My ideal experience with Brushfire would be opening the files I want to document, clicking a button, and a minute later viewing the report.
From what I hear, however, this may become moot when both Analyzer and Brushfire are redesigned to take advantage of the new capabilities of FileMaker Developer 5.5, which would eliminate the need for Print2Pict.
Using HTML to format reports is advantageous in many ways. Navigation between different portions of the report is easy, and with HTML you can view different parts of the report in different windows. I would also like to see the option to have the data kept in FileMaker as well. This would make it easier to develop based on the fields that a script references. For instance, I don't see a way for Brushfire to answer the question, "Can I delete this field without breaking a script?" Having the data in FileMaker would make it possible to search script steps for that field, and would provide an easy interface for keeping track of version history. This could also be a space saving feature. If all of the information about a report could be kept in FileMaker, it would be possible to throw away old report files and recreate them if needed in the future.
Chaparral's suggestion to this limitation is to search the entire report folder using an application with multiple file search capabilities. The reports folder stores all of the reports run with Brushfire where a given report is just a set of HTML files. Chaparral reports that Brushfire users have done this with satisfactory success. They correctly respond to this limitation by pointing out that importing the data into FileMaker would take longer (remember, that's at least 10,000 records for the solution I analyzed), and would therefore decrease the speed advantage of Brushfire. Perhaps a preference option could be used to give the user the choice of which way to go.
One feature I love about Brushfire is that its FileMaker interface is totally unlocked. So if you don't like how Brushfire does something, you can probably change it yourself. For instance, I find the wizard that takes me through the steps of naming the report and project to be superfluous for my purposes. I can see where this would be useful and others may like it, but because Brushfire.fm is unlocked I can go into the structure of the FileMaker file and alter the scripts so it doesn't use the wizard. The HTML files are created from templates that you could also edit if you want to change the look of the reports. I hope other developers of FileMaker tools follow Chaparral's example and unlock the FileMaker portions of their products so users, who are, after all, developers, can tweak the products to their desires.
Brushfire It Up
The final question is, "Should I buy Brushfire?" If you're a professional developer, working with FileMaker full time, and you develop on the Mac or Windows 2K/NT/XP, the answer is a definite "Yes!" At $99.95, Brushfire is going to save you as much the first time you use it. You'll catch errors in your scripting that you didn't even know were there. This, in turn, can reduce the amount of support you may be providing.
The version of Brushfire reviewed in this article was used on a Macintosh. A few weeks ago Chaparral released a Windows version, which reportedly has the same functionality as the Mac version with a bit more automation included.
If you're not a professional developer, then the recommendation is a bit more tepid, but still positive. The more complex your solutions, the more useful you will find Brushfire. Brushfire could be useful if you're having specific problems with a solution and would like to track down their origin, or if you would like an easily navigable report of the scripts in a solution. The ability to go directly from one script to another alone is worth the price, something I've wished for a long time that FileMaker Inc. would build into their flagship product. Brushfire's price is reasonable for what it does and the time savings while developing is very desirable.
Charles Ross is a Senior Developer for Metro Technologies, a FileMaker Solutions Alliance Partner and the nation's largest FileMaker development firm. You can contact him at cross@metrotechnologies, or visit Metro's web site at www.metrotechnologies.com.