Dave Ramsey

Members
  • Content count

    23
  • Joined

  • Last visited

Everything posted by Dave Ramsey

  1. 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:
  2. 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!
  3. 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.
  4. 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
  5. For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
  6. 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. :-)
  7. 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.
  8. 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.
  9. 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. :-)
  10. 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!
  11. 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.
  12. 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.
  13. Biggest single file is now 303.8 MB. Thanks!
  14. 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.
  15. 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.
  16. 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
  17. 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. :-)
  18. 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).
  19. 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?
  20. 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?
  21. So, would the count of fields with QuickFind turned on (or maybe a percentage) be a metric, or are you just looking for a way to locate these? If you just need to locate them, it's already possible in FMPerception. Every list of layout objects (either for a single field, or for a whole database/solution) has a "QuickFind?" column. If you sort by that, you can use the Hierarchy display in the Detail to find out how to get there (regardless of how many layers it's hidden within).
  22. Jeremy, if I calculate cyclomatic complexity for each script, how would you prefer to see a system level summary expressed? The average? Min/Max, Average? Average & standard deviation? Chart of scripts by cyclomatic complexity? What would be most useful to give you a snapshot view of what's going on, cyclomatically (so to speak)?
  23. Workflow Data Systems LLC is looking for experienced, innovative FileMaker Pro developers who are ready and eager to show off their skills. We are a consulting firm with some well-known international clients, and have a significant backlog with more projects forming every day. If you are highly motivated and can hit the ground running, we need you to write and revise custom solutions, now. Due to the nature of our business and interaction with our clients, candidates in the Central Ohio or Central/Northern Indiana area are preferred at this time. And if your concept of "consultant" involves 15 or 20 hours a week and working at home, Workflow Data Systems may not be the right company for you. While our requirements may appear to be easily satisfied, our ideal developers typically have some extra time and enjoy extra pay for that time. Required Skills: - Experience supporting existing FileMaker Pro systems - FMP5/6 solutions converted to FMP7/8/8.5 - Web-enabling extant tools and data sets - Experience architecting new FileMaker Pro systems - Client Interaction - We are a consulting firm. As such, we expect professional attire, attitude, and communication standards. - Mac OS X and Windows - If you don't know both, you must know one well. Very well. Desired Skills (any and/or all) - PHP - XML/XSLT - SQL/ODBC - AppleScript - Experience with publishing - Experience with manufacturing - Experience with process automation - Experience with ERP / MRP2 and related environments Required Psychology - Plays to win the game - Self-motivated - Travel required, up to 2 days / week - Can accept and offer professional advice Terms: - Contract to Perm - Pay based upon skills and capacity for autonomy Send a resumé, contact information, and any additional notes to fmpdeveloper@workflowdata.com. Please no calls. We will be happy to answer your questions during your interview.