Jump to content

Dave Ramsey

Members
  • Content count

    28
  • Joined

  • Last visited

Everything posted by Dave Ramsey

  1. Finding Webdirect Incompatible Scripts

    There is not (currently) a feature in FMPerception for checking WebDirect compatibility. Generally If I'm trying to do the with FMPerception, I know the kinds of steps I've added that will cause incompatibility. Drilling down through the Standard Script Steps query will allow me to quickly see all the places in the system where I used certain kinds of steps. For now, that's the best option available in FMPerception.
  2. Find script triggers that call a script?

    Gotcha. Happy to help.
  3. Find script triggers that call a script?

    Close. FMPerception treats the triggers themselves as objects of their own. So, when looking at the script, you can select the References sub-query and see everyplace the script is referenced. Layout triggers get a black flag icon. Layout object triggers get a white flag icon. A Layout trigger row has a sub-query to locate the parent layout. A Layout object trigger has a sub-query for the layout object hierarchy. So it till show the owning object, any object that contains that object, and object that contains that object (and so on), up through the layout and layout folders that contain all of it. So, you don't get the objects themselves, but you get the triggers, and the object is about 2 clicks away from each. So, question for you: Is this what you need, or do you have a particular use case that needs something different / flattened? Thank you, Dave Ramsey
  4. Broken References

    Yes, you are correct that some of the issues might have indirect references. For example, if a script has a problem, it might be inferred that any layout (or menu item, or other script) that calls that script also has a problem... But that's beyond the scope of the current functionality. What I don't want to do is tell a user that there is a problem in Script X, when the problem is that it validly calls Script Y, and Script Y is the one that actually has the problem. The "Impacted" list is more about where you have to go to fix the issue. The total number of occurrences of issues is on the first line of the Broken References section of the report card. That number should be equal to the sum of the items on the Broken References query node. If I were talking to a customer, I would either quote them that first number form the report card, or I would quote the sum of the other lines on the report card. So either "here are the number of issues", or "here are the number of FileMaker objects that are objectively broken in some manner".
  5. Broken References

    Hey, Lee. Great question. The Broken References top level query is organized by the kind of error that is encountered, but provides very little assistance for where there errors are encountered. So, for example, an "Empty Layout Reference" is commonly found in a Go To Layout or Go To Related Record step that was pointed to a layout that no longer exists... But that could appear in any of the following: Script step Single step layout object button Single step Menu item So, if you wanted to fix all the "Empty Layout Reference" items, you might have to go all over the place to do it. Some users requested the ability to tackle broken references by where they occur, rather than by type of error. So, "let me go to a particular layout and fix all the issues there (regardless of the kind of issue) before moving to another layout." The Report Card breakdown of Broken References is designed to assist with this. Additionally, I can use my own knowledge of a system to filter that list. So, if I have a bunch of Impacted Layouts, I can click on that to look at the layout list. The names of those layouts may tell me that I don't have to prioritize fixing these, as I tagged the Layout names with "[DEPRECATED]" (my personal favorite code for tagging items that are not in use, but that I haven't gotten around to deleting yet). Or, all issues may be on my Main Menu layout... A serious problem that I should address immediately, one way or another. The behavior difference between the two lists is also more in line with how I see the Report Card working. If I'm about to sit down with a customer, a sense of what user elements are effected by this issue is far more useful to me than a technical explanation of the kinds of issues. So, in the end, if those numbers match between the two different representations of Broken References, it is purely coincidental, because they're reporting two different things. If that does not answer your question, please let me know.
  6. FileMaker Plugin Registry

    Since FileMaker 16 now exports a plugin "source" code with the DDR (even if the plugin is not present) for plugin script steps, it would be helpful to have a way to identify a plugin based upon this "source" code. It would be immensely helpful if developers could provide this information. For reference the "source" code that I'm talking about is "FMmp" in the sample plugin source code. In the interest of gathering this information, I whipped up a Google Form for data collection. To reduce misuse, this form is entry-only. Once created, there is no way to edit a record. If the information changes over time (say, you would like users to go to a different URL), just make a new record. I can't speak for everyone else, but FMPerception will likely be using the last record available for each source code. At some later date, this may be expanded into a larger registry, but for now I'd just like to get some data. Follow this link to fill out the form: FileMaker Plugin Registry Form I don't have any interest in being the only person with access to this information, so if you would like to view the results, feel free to click here. Plugin Registry - Google Sheets If there is some other registry, just point me to it, and I'll apologize for the distraction. Thank you very much. Dave Ramsey P.S. Here's an example of how it looks when FMPerception knows about your plugin:
  7. I'm working on a feature for a forthcoming FMPerception version to manipulate the TopCallStats.log files generated from FileMaker Server 15, and I'd like to get ahold of some real test data to work with. I can manufacture test data all day, and it won't be nearly as helpful as a couple of real logs generated from real servers and real solutions. I'm hoping to find a couple of developers who can generate logs and provide them along with the associated DDRs. For the sake of privacy, it might be best to contact me directly at dave@workflowdata.com. That said, I'll be happy to answer any questions here or there. Thank you very much!
  8. FMPerception won't open in 10.9.5

    Hello, Larry, Yes, FMPerception for macOS is currently limited to 10.10 and higher. That's the oldest OS for which we've performed the appropriate due diligence to be able to confidently state that FMPerception can happily handle that version. I don't anticipate future support for an older OS. My apologies for providing exactly the response you were hoping not to hear, but it's the best I've got right now.
  9. Default sort order override

    Hello, my ad-hoc steering committee... I'm shortly going to be tackling allowing an override of the default sort order. Once implemented, there would be a preference to override the default sort order for all(-ish) queries to sort alphabetically, rather than by export / creation order. I would love to get some feedback on this idea, in particular that I'm not either targeting too narrowly or too broadly. My thought is that this could be best implemented using 3 checkboxes. Sort almost everything alphabetically by default Sort Layouts alphabetically by default Sort Scripts alphabetically by default I think that for most users, sorting fields, TOs, references, etc by name by default will not cause a problem. Most of them won't even need a preference for that. They'd like it always on. I have, however, identified users that would like to retain general access to the imported sort order. I've identified Scripts and Layouts as two elements that very commonly are manually ordered. Most developers will group similar layouts and scripts, even assuming that they have a naming convention that would allow for meaningful interaction with these elements (say, Scripts) alphabetically. I also don't think there's any value to sorting Layout Objects in anything other than import order (by default), as the import order is a parent-child aware z-order. I'm also thinking that this will necessitate the addition of a column in the Results pane that stores the creation / import ordinal so that you have the ability to restore that order (or reverse that order) if necessary for a single query. Questions: Can you think of any other elements within FileMaker whose creation / manual order is far more important than their alphabetical order? This is oft requested enough that I'm considering changing the first checkbox (sort most items alphabetically) to ON by default. I think I will have fewer users asking how to change it back than I currently have users asking how to turn it on. Thoughts? While neither the Hierarchy Browser nor the Columnar Browser have a base implementation for overriding the sort order on an area by area basis, I might try to invent one if there's huge desire for it. I still that most users will never tweak the default, but I'm willing to be proven wrong. In a fever-dream, I thought that instead of adding checkboxes to the preferences, I would add menu items that could be toggled on and off. This only becomes of use if somebody sees being able to override this on a document-by-document basis, and really regularly, as a critical requirement. If this is you, I'd like to hear from you. I'm pretty sure that the overwhelming majority of users will turn it on, and never mess with it. Most will never even override that default sort to use the new import ordinal column. Any other thoughts or ideas related to this topic would be most appreciated. Thank you very much, Dave Ramsey
  10. Default sort order override

    For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
  11. Does anyone have any ideas for things that FMPerception could do with the Touch Bar? My first thought was mapping the back arrow onto the Touch Bar. Also, maybe Refresh? New DDR / New Diff? What would you like to see? P.S. This is not going to suck a lot of time from more universal features. If the tools don't make it *very* easy, I'll wait for the next version of the tools. :-)
  12. Currently, FMPerception will flag a broken reference in a calculation definition, even if the calculation has been deactivated. So, if you have a broken reference in an auto-entry calculation, but the auto entry calculation checkbox has been turned off for that field, FMPerception will still bring it to your attention. I'm starting to suspect that this is overly aggressive. I mean, it's technically correct... The calc is in your database, and the calc has a broken reference... but do we care? I *do* remove broken references in deactivated script steps. So, either way there's an inconsistency. I'm interested in arguments either direction, but I'm probably most interested for arguments to keep the functionality as it is. I'm currently inclined to remove these broken references from the broken references results. Thoughts? Thank you very much.
  13. Broken references in inactive calculations?

    The more I dig into this, the more I think the right answer is to ignore references (broken or otherwise) in "unexpressed" code. I received a DDR via support request that had a value list that used to be dynamically generated from the contents of fields, but is now statically defined. In the DDR XML, the references to the old fields are still there. If you deleted one of those fields, now it would be a broken reference, but it really just isn't. Additionally, based upon the current rules (of considering unexpressed references), that value list is keeping those fields from being "unreferenced"... and that's even harder to justify. Changing the rules to ignore unpressed references will (I believe) only have an impact on a user who's trying to figure out what the code used to be, while the current rules are having a much broader impact. While it's going to be a lot of fun to filter them all out, I think they need to go. That said, I'm still interested in impassioned pleas to continue to pay attention to them.
  14. Broken references in inactive calculations?

    That *should* be how it's working now. An inactive calculation with no broken references should not appear broken. I would consider anything that responds otherwise to be a bug, and would love to receive a bug report. :-)
  15. Request for HUGE DDRs

    I'm looking for some DDRs that I can use to torture-test FMPerception. --The biggest multi-file DDR that I have for testing is 1.06 gigabytes. --The largest single-file DDR is 224 megabytes. If you've got something larger, and you can allow me to use a copy for testing purposes, I would love to hear from you. As larger DDRs are provided, I'll update this thread with the new numbers to beat. :-) Let the games begin!
  16. Request for HUGE DDRs

    Lee, That would definitely help you to reduce the local CSS of a specific problem layout. My point was just that I'm not sure that looking at that at a file-level is optimal. Is it worthwhile to spend the time to optimize every local CSS node out of every layout? My sense is that it's not, but I don't have any math to back that up. It feels like "premature optimization". Definitely. Node counts in local CSS I think are really useful, and I'd like to work on some code to allow me to display those higher in the hierarchy (at the layout level, rather than just at the layout object level like now). That said, I don't want to kill the performance of a tool optimized for performance. It's a tricky balance to maintain. I'm less convinced of the value of the character count of the overridden nodes. There's a line between optimizing the layout and optimizing the DDR itself... and that's probably over that line. I also like the idea of looking into which nodes are most often overridden. That could be helpful.
  17. Request for HUGE DDRs

    Wim, As far as I can tell, the DDR doesn't contain many/any Base64 graphics representations anymore. They appear to have disappeared around about FileMaker 12. It's in the clipboard XML, but not in the DDR XML. I wish it was still there. I had some cool ideas for what to do with it. I was curious about the answer to your question, though, so I wrote a little tool to analyze DDRs to determine where the size was coming from. I analyzed half a dozen big files to determine what percentage of the total character count of the DDR was tied up in each major element, and found the following: In general, I'm seeing that DDRs are about 70-80% layouts, 10-20% scripts, and generally less than 5% "everything else together". Within the Layouts XML, 60-70% of that is styling information (LocalCSS, character and paragraph styles, and number/date/time formatting). That last one is possibly the worst, as it's verbose and present on basically everything (the DDR exports number/date/time formatting for web viewer objects…). It accounts for effectively about a third of the size of the layouts. Optimizing styles and such has no impact on it. If you could remove ALL local CSS, it's likely going to save you about 10-30% of your DDR size. I wrote the code, but I can't come up with a really good argument to roll it into FMPerception. It's interesting, but I haven't been able to come up with any particular use for the information (aside from triggering an OCD reaction from some developers). If somebody has a good argument for why it might be legitimately useful, I'll consider adding it to FMPerception. But the numbers that I have suggest that it isn't a reliable measure of the complexity of a system, or even of its performance. I am willing to be swayed, though. Wim, thanks for the awesome question.
  18. Request for HUGE DDRs

    Biggest single file is now 303.8 MB. Thanks!
  19. See all scripts that reference a layout

    No, you aren't missing anything, per se. It's just something that hasn't been tackled yet. It's on the list. In the short term, use the global Text Search function (not the one inside a particular layout) and run a search for the layout name. If the layout name is too common to generate meaningful results, try renaming the layout (perhaps in a clone), and then regenerate the DDR. Depending upon your naming conventions, this may result in exactly the list you're looking for (with the addition of the layout itself appearing on the list). Please let me know if that doesn't meet your needs. Dave Ramsey P.S. Watch out for indirection. Targeting a layout by calculated name or calculated number is one of the oldest FileMaker indirection functions available.
  20. When first looking at a new system, what indicators would you like to see that will tell you about the quality of the system? When looking at a system you’ve been working on for years, what are some signs of mounting technical debt? I’m looking at a feature to provide some top-level indicators about system quality. Granted, a lot of system quality is about the way in which things are put together, the quality of the design, etc. But are there things that you look for, and when you see them you know it’s going to be a problem? What says, “this is going to be an unmaintainable mess?” Conversely, what says, “somebody had their head on straight when they made this?” Please don’t worry about how hard it will be to calculate. This is just idea generation. I like lots and lots of bad ideas. We'll worry about what's "possible" later.
  21. Comparing Layouts in a file.

    Currently, the diff tool is not designed for that use case. It kind of depends upon the kinds of changes you're interested in examining.... Option 1: Open the same DDR twice. You can open a new DDR browser, and point it at the same DDR again. Then, you can have 2 windows that are both looking at the same file, but at different layouts. This is still a visual comparison, but it does also give you access to the information in the Detail if that helps. Options 2: You can save (for example) the list of layout objects from each layout to a CSV. Then, you can compare those two files. Personally, I use BBEdit when doing there, but there are all sorts of text-file-to-text-file diff tools. Granted, this won't tell you if one of the objects was resized, but it'll get a lot of the large, functional elements. You could also dump both CSVs into FileMaker and create something more fiddly comparison-wise, depending upon what you're trying to find. If these won't help, perhaps some more details about what you hope to find in your comparison would be helpful. Dave Ramsey
  22. By the way, I'm not going to have an opportunity to start moving on the results of this discussion until after DevCon. So, as you're catching sessions in Vegas, and you think of something else, please come back and add it there. DevCon should make a wonderful seed for brainstorming. :-)
  23. Yeah. I figured that was the case. If I call a custom function in a script, does the cyclomatic complexity of the custom function impact the cyclomatic complexity of the script? I'm thinking that way madness lies... but I'd rather have the true answer than the easy one (if at all possible).
  24. OlgerDiekstra, to answer for Wim (and if what i'm about to say misses his intent, I'd love to be corrected), these are just expressions of complexity. In some of these, really low numbers might be almost as bad as really high numbers. If you have a system with 800 custom functions, that's a problem. That said, a big system with zero custom functions might speak to either the processes used, the tools used, or the overall age of the system. Certain kinds of calculations are going to much more verbose if no custom functions have been used. One or two sorted relationships aren't necessarily a problem until users start complaining about performance. 127 sorted relationships is a design problem almost any way you slice it. 20 tables with zero TOs speaks to a design philosophy, and a set of techniques that would almost certainly be required. 20 tables and 200 TOs is going to make it tough to make changes. The "same" relationships are represented dozens of times,and if you want to change one, you likely need to change it in many locations. Systems created prior to FileMaker 7 will sometimes have a tendency to have many more TOs than tables (due to the way that relationships used to work). More than one portal per layout is also about complexity. If you'll grant that a layout with 5 portals is more complex (in UI, UX, and code) than one with 1 portal, the same can be said about 2 or 3 portals when compared to just one. Wim's drawn that line at "1 is fine, 2 is pushing it". One layout with more than 3 portals? Not a problem. 45 layouts with 2 or more portals? That might eat some time in unraveling. It's certainly going to be more complex... Webko, can you provide some clarification on what you mean by that? Are you using a naming convention? Or some other mechanism for visually identifying ID fields?
  25. Great list, Wim. Thanks! A couple of quick clarifying questions: If a relationship is sorted in both directions, is that one sorted relationship, or two? I know we don't see a *lot* of bidirectionally sorted relationships, but... Alternately, perhaps "Bidirectionally sorted relationships is separate metric. Is that "number of objects with overridden CSS", or "number of overridden nodes"? I have not used every plugin out there. Can anyone think of other plugins that follow the MBS style of making the call a parameter, rather than part of the name of the function?
×

Important Information

By using this site, you agree to our Terms of Use.