Recharging the Battery

One of the ‘joys’ of having my own business is that I’m always on-call and there are times I’m answering emails on a Saturday night.  Most of the time, it’s no big deal but it can become exhausting without a break.  This is why I need to take time off and recharge my batteries.  So should you.

Carol and I did that last week with a vacation in the Caribbean.  We had a lot of fun and got a chance to recharge our batteries and get away from work (and US politics).  And even though we weren’t technically working (I consider coding to be the real work), we did talk about our business and those things we are grateful for.

One thing we are extremely grateful for is the fact that we can take off for a week without feeling guilty.  That got us thinking on why is it so hard for consultants to take time off.  It’s not too hard to figure out but here are a few items from our list (sadly the list got a Bahama Breeze spilled on it and thus couldn’t be saved for posterity, but here’s what we remember).

If you’re not working you’re not making money.  So true for consultants, but my advice is to try to develop multiple income streams so you can make money without doing consulting.  We have our developer products (ARGen and Shorts are our big ones) and without any work on my part we sold some last week.  We also have our Xojo Training videos that are income.

Having that one big all consuming project.  A lot of Xojo consultants I’ve known over the years have that one big client that consumes nearly 100% of their time.  We have multiple Xojo developers and while we can do big projects that involve all team members, it’s pretty rare.  This means that our income (and risk of losing it) are spread across multiple projects/clients.  For us, projects come and go, and that means there are times when one or two of us get to work on internal projects but our income levels stay consistent.

It’s all on you.  Solo consulting stinks because it’s all on you.  I can’t tell you how many solo Xojo consultants I’ve seen come and go in my fifteen years.  Doing it all by yourself is tough and sort of ties into the one, big, all consuming project from above.  You only have so many hours in the week to code and if you don’t have help you still have to take time out for marketing, sales, and developing multiple income streams.  It’s just not possible for solo developers to be spread that thin.

Do you have a job, or do you have a business?  Over the years I’ve had multiple solo consultants chastise me and tell me that I’m just ‘training my competitors’ with my multiple employees.  Sure, that’s always a possibility, but is it probable?  So far, they haven’t and my thinking is that if they really wanted to have their own business they’d probably already be doing it without my training anyway.  Having and running a business is not the same thing as having a job.  Plus, that type of thinking comes from fear and I’m confident enough in my own abilities and experience that it simply isn’t a concern.

Consulting rates are too low.  I’ve talked about this multiple times but too often someone new to consulting will take their last real-world salary and figure out their rate from that.  This is absolutely the worst thing to do because as a consultant you don’t have a job you have a business.  You need to have a rate high enough to pay for health insurance, retirement plans, and to pay yourself during your vacation escapes each year.  It is your responsibility, as a business owner, to calculate what rate that is for you.  If you want to know my rate send me an email and I’ll gladly tell you but I will also say that if I was still a solo developer it would be higher because I can only code so many hours in the week.

You must recharge your batteries every now and then.  Without that you become inefficient and run the risk of burning out and you’ll be sending an unhappy client to me to take care of their project.  Don’t laugh because some of my best long-term clients came from a solo Xojo developer that had to leave consulting for one reason or another.  Some left because they were charging too little to pay for health insurance, retirement, and to recharge their batteries on a consistent basis.

So what do you do to recharge your battery?  And why do you think many people fail as solo developers?

Grateful for the Xojo IDE

I use Xojo every day and it’s almost my exclusive development tool.  I’m so close to the product it is easy to see the warts of the product but in reality it’s a pretty stable and easy-to-use system that’s mostly good for beginners and experts alike.  The documentation, while not perfect is useful and the example projects are decent as well.

I came to this conclusion after a couple of recent projects have taken me into xCode and Eclipse.  Where to even begin comparing these IDEs to Xojo is challenging because they are both similar and so different than Xojo.  In xCode I was porting some iOS Objective-C code to Xojo and working with a hardware library.  Eclipse is used by my son’s FRC robotics team to develop software for their robot.  In each case I’ve wanted to pull (what’s left of) my hair out.

I guess one of the biggest differences is that sheer number of options you have in both xCode and Eclipse.  So many options, I posit, that it’s difficult to figure out what they all do, and make it hard for beginners (like I was a few weeks ago) to get going.  I don’t make any claims in knowing them any better now than I did a few weeks ago either.  I got them to work and I simply left them in that state with the hopes that no future update wipes them out.

Don’t get me wrong, I’m still not the biggest fan of the Xojo IDE in comparison to the old Real Studio IDE.  This is mainly because of the Navigator and how spastic it’s been since it’s initial release.  Thankfully it’s working pretty well in the latest releases and I find myself not swearing at the IDE much.

I also know the plan is to make the Navigator work closer to the old project tab in Real Studio.  Truthfully, I’m looking forward to it and dreading it at the same time.  I *think* it will work better than the current system but I won’t know until I use it.  And by the time we use it, it will already be too late to make any significant changes.  I dread that we’ll be faced with some awful bugs that will take time to work out and I also dread that the workflow might actually be worse than it is now.  We just won’t know until it’s put in front of us.

Are there other things that I wish the Xojo IDE did differently?  Sure.  I despise defining methods in the tiny Inspector whereas in the Real Studio IDE it took up the entire width of the Code Editor.  I also wish there were faster ways to define methods since I’m forced to use the UI to do so.  You figure after 15 years of doing this I pretty much know how to do it by now.  Alas, I have no other option than to use the UI.

Some of the other editors are like this too.  The Constants Editor requires too many mouse clicks to work right.  I want more “hands off the mouse” options.  As far as I can tell, the Menu Editor has no keyboard shortcuts as well as FileTypes editor.  In both cases, I would almost prefer a Plist type editor.

From a simplicity standpoint, though, Xojo is easy to use and doesn’t let you do too many stupid things.  I wish some other IDEs would take that approach for newbies, but then I guess their approach is to throw people into the deep end and let them sink or swim.  Xojo  tries to be helpful in that regard.

Other IDEs have some cool features.  What features would you like to see copied from other IDEs into Xojo?

Remote Debugging Enhancement Idea

Remote Debugging in Xojo is perhaps one of my favorite features in Xojo because it lets me work in the environment of my choice (macOS) and run it on any Windows, Linux, or even another Mac on my network, or in my many VM environments.  One of the things that’s always bugged me about remote debugging is the cycle time.  Every time you do a remote debug the IDE sends everything (executable, libraries, resources), again, to the remote debugger.  Even a simple change requires that the entire package is transferred to the remote debugger.  Every.  Single.  Time.

Xojo improved the cycle time for deploying web apps to Xojo Cloud in 2016 Release 4.  They did this by caching the framework and plugin libraries on the Xojo Cloud server.  When connecting to the Xojo Cloud server it tells the IDE what frameworks and plugin libraries it has and the IDE then decides what to upload.  So your first upload may take four or five minutes but subsequent uploads using the same version of Xojo take considerably less time.  In my case it’s about a minute.  It’s a welcome speed up.

In remote debugging, large projects can often take a LONG time to send simply due to their size.  I find myself debating on whether to install the IDE in that environment (along with prerequisite plugins), or to simply wait through the remote debug cycle.  Sometimes it’s a wash, but, I’ll be honest, it’s irritating to spend the three minutes transmitting to the remote debugger only to have to quit almost right away and change a label or a single line of code, only to have to sit through the transmit time again.

Why can’t they do the same thing for Remote Debugging that they did for deploying to Xojo Cloud?  Think of the time savings this change could do for someone that does a LOT of remote debugging like I do!

Time savings aside, there ARE some drawbacks.  The first is that the Remote Debugger becomes a much more complicated mechanism than it already is.  Since much of the code is (presumably) portable from Xojo Cloud to the Remote Debugger this might be a moot issue.  However, converting from whatever they’re using on Xojo Cloud (presumably Xojo) to desktop use may not be trivial.  It’s hard to say without asking that question.

Secondly, it would have to store all of these libraries and frameworks in a cache and then what would you do for cleanup?  When it quits delete these caches or keep them around?  I could argue for both ways.  Perhaps that’s a preference setting with maybe a quick calculation on how large the current cache is?

Third, it distracts from 64-bit Remote Debugging.  Maybe.  If I had the choice I’d love both, but if it meant delaying 64-bit for six months I’d rather have 64-bit now.  This is a wish list item, after all.

I created Feedback ID 46848 to get this idea into circulation.

What do you think about this idea, Xojo Developers?  What other pain points do you have with Remote Debugging?

Consulting Red Flags

The one absolute truth about consulting is that if you’re not working you’re not making any money.  The corollary to this truth is that you are either 100% busy or 100% not busy.  This is especially true if you are a solo developer.  It is very hard to turn down projects when they come your way but I’ve found that there are times when you should.

I get it.  Really, I do.  If you’ve been idle for longer than you’d like and money is starting to get tight ALL projects start to look good.  Don’t take the project because you need the money.  Take the project because it’s a good fit, it’s interesting work, and you think the client will be a good partner.

In the world of make-believe this is the way it should be.  In the real-world you don’t always have those options.  Plus, it’s really hard to figure out if a project is going to be a good one or not.  Here are some of the red flags I’ve come to recognize in fifteen years of being a Xojo consultant.

Other Peoples Code (OPC).  Code written by someone else is always a red flag.  We write code a certain way and if any of our team work on it we can rest assured that certain things will be done (naming conventions, comments, etc.).  No such guaranty with OPC.  It’s way easier to start from scratch but with most OPC projects you don’t have that option.  So you start with a level of uncertainty and having to decipher not only the coding style but often times the intent of another developer.  Learning someone elses code stinks.

Project complexity.  When I’m asked to join an existing project I try to look at how complex it is.  If it’s really complex I hesitate because I know it will never get less complex.  In many cases the original developer tried to be clever to solve some (real or imaginary) problem and while solving it completely overlooked a much simpler way of doing things.  Plus, if it’s not one of your core competencies it might not be a good fit anyway.

Another item under the project complexity red flag is excessive amounts of documentation.  From experience, most projects can be summed up with a page or two of high level description and then a dozen pages of important detail.  When the client sends you a very long document with high levels of detail you might be getting yourself in other your head.

Of course the flip side of that is clients that send you a paragraph or two of their idea.  In those cases we have to draw more information out of them, and depending upon the size of the project, we might actually charge them to write their specifications for them and let them get some competitive bids from other developers.  I think the lack of detail says they haven’t done enough homework on what they want and need.

Toxic teams.  Another issue with joining an existing project is trying to figure out if the team is toxic or not.  The existing developers will always have their own habits and you, as the consultant, need to try and match theirs.  What if those habits are silly?  I’ve seen teams that require a comment for every line of code.  I’ve seen some teams that disdain any comments under the guise that code should be ‘self commenting’.  Is there a team member who’s the ‘smartest person in the room’ and everyone else has to put up with it?

Project savior.  I can’t tell you how many times I’ve been asked to look at a project started by other developers and the project owner is desperate for it to get done.  In these cases they’ve spent a LOT of money with a developer and gotten poor, or no, results.  You have to ask yourself a few questions.  Was it the developer being incompetent, the owner being unreasonable, or both?  If you take one of these projects you can either be the hero by completing the project, or you can be the goat for being just as incompetent as the original developer.

Project owner/developers.  I’ve found that working with project owners who are also part-time developers also can be a pain to work with, but not always.  The ones that come to me realizing that creating an application isn’t easy and requires time they don’t have and knowledge they don’t have time to acquire tend to be okay.  Those that say it should be ‘fast’ and ‘easy’ for someone with your skills have their expectations set too high.  Software development, in many respects, is more art than science.

Always complains about cost.  Every client wants their custom software done cheap, quick, and on time.  The industry joke is to pick two of those qualities.  Software development of custom software isn’t cheap, nor is it quick in most cases.  If they balk at the initial estimate it probably won’t get any better.  They certainly won’t like any change orders.  We had one prospective client ask us three times, over the course of a year and a half, what the price was going to be to complete their project.  I don’t know if they expected our price to go down, or what, but eventually they found a developer to do their project at the price they wanted.  And then had the audacity to come back six months later then that developer couldn’t deliver.

Been through many developers.  Perhaps my biggest red flag of them all is when someone comes to us after going through several other developers.  Listen to their complaints about the other developers.  Were they too slow, did they charge too much?  I’ve even asked for permission to contact the previous developer to get the news from the developer perspective.  The community is small so there’s a good chance I know them and I know I’ll get the developers perspective.  Use those connections if you can because you might discover some useful information about the client and the project.

Just because you need the work doesn’t mean you should take every project that comes your way.  Be selective because you’ll avoid some heartache and probably enjoy your work more.  What red flags have you developed over the years?

Windows Printing Broken in Xojo R4

We’ve done a lot more testing with Shorts and R4.1 this week.  Wow.  Where to begin.  I guess the first thing to say is if you need to print in Windows stick with Xojo Release 3 for now.  R4, with its switch to Direct2D has completely messed up printing.

Using Shorts, and Xojo R3 this is what a normal print looks like.  (Forget about the colors and stuff, I’m testing things out and the ugly colored blocks help).  Looks like it should:

Exact same code in 2016 R4.1 and this is what it looks like.  Note:  the picture makes it worse than it is, it’s not slanted like that on the page, my camera angle is just weird.  But, you can clearly see that while the lines and rectangles printed properly, there’s no text!

It’s obvious that the Direct2D from GDI+ in R4 were not properly tested.  Part of that is on us, the beta test community, but it seems, to me at least, that Xojo didn’t do enough vetting themselves.

The good news is that the Shorts display works fine as well the output to PDF.  So if you don’t actually print directly from your Shorts application you’ll be okay.

I expect better of Xojo.

Xojo 2016 R4.1

Xojo 2016 R4.1 was released today.  The 4.1 release mostly contains Windows fixes related to the switch in drawing engines.  Gone is GDI Plus and Direct2D is now used instead.

GDI Plus wasn’t only deprecated but removed so that is a little different than most Xojo releases.  It is highly recommend that you test your Windows apps thoroughly before release.  It’s also recommended that you test your 64 bit builds as well since it’s a newer framework and has received less attention.  Just today I found out that SegmentedControls don’t draw right in Windows 64 bit builds.  Feedback id 46268

As always, take a look at the full release notes for pertinent information.

Monkeybread Software released version 16.5 of their plugins today http://www.mbsplugins.de/archive/2016-12-12/MBS_Xojo__Real_Studio_plug-ins and is recommended for all users.  Einhugur http://www.einhugur.com has released a number of updated plugins for R4 and has indicated that more are updates are coming.

Xojo 2016 R4 (The Xojo IDE I Always Needed)

Xojo 2016 Release 4 hit the web today.  In many respects this is the IDE that I wish had been released three and a half years ago as a few of the more insidious features bugs have been fixed.  And, as usual, there is a plethora of new features, changes and bug fixes that make R4 a must-have release.  Let’s get to it!

First, the tabs in the IDE now work like most of us want them too.  Open an object, say a window, into a new tab.  By default this tab is locked and it will stay in that window.  The small back and forward arrows at the top of the navigator are not even visible.  To ‘use’ the tab for another object click on the lock symbol in the tab to unlock it.  It might take a click on the name of the Window at the top of the navigator but the arrows come back and you can navigate back to the project stack.  Or, as I tend to do just close the tab and open another object.

In a somewhat related fix, the Back and Forward arrows in the toolbar now work properly per tab.  As you navigate through an object, choosing the back button remembers where you’ve been in that object.  In previous releases the Back and Forward arrows seemed to be a exercise in random number theory as it seemed to go to locations in the IDE I had never visited.  There might have been a pattern to it but usually I just never bothered to use the buttons.

If nothing else, these two changes are a compelling reason to use R4.  The locked tab feature and the back/forward buttons never worked the way I wanted to use them.  It is sad that it took this long to get it right.

The Navigator filter received some updates too.  Now you can use type’s like ‘type:property’ will only find properties.  ‘Type:shared%’ will only find anything that’s shared.  It’s pretty powerful and I recommend playing with it a bit to get used to it.

There is now a contextual menu item for Pictures to convert them to an Image Set and put the selected picture in the first image slot.  This eliminates multiple steps with the mouse and is a very useful addition.

For Windows users there has been some changes.  UseGDIPlus has been deprecated and is replaced with Direct2D drawing.  Make sure to test any of your Windows apps that use a lot of drawing in a graphics object as things might have changed a little with the switch to Direct2D.

New Picture only creates 32 bit depth pictures and this now matches what the other target platforms do by default.  This also means that NewPicture method is deprecated.  HiDPI builds for Windows are no longer beta.

Xojo cloud received a major update.  Uploads to Xojo Cloud are now much faster.  Libraries are now cached by the server so only code and image resources are uploaded.  For example, in R3 one of our largest web projects took over three minutes to upload.  The first time I used R4 it took a little over two minutes (it was caching new libraries) but every time I uploaded the project thereafter it took a mere 44 seconds to upload.  That’s a significant time savings!

The WebListbox now has a CellPicture method that allows you to assign a WebPicture to it.  The WebSession shutdown mechanism has been refactored to help keep sessions from getting stuck and not quitting.  Exceptions in Websession.close no longer keep subsequent sessions from closing.

Due to changes, especially on the Windows side, you might want to check on updated versions of your plugins.  MonkeyBread software recommends version 16.5, or newer with R4.  16.5 is currently in preview and they expect to release it next week.  Einhugur has a couple of updated plugins for Release 4 as well.

As with any major Xojo release, you should test your projects thoroughly before releasing anything into the wild.  The beta program catches a lot of bugs but it’s not a perfect program.  One such bug that got through is an Application crash when using the Super button in the Inspector.  Until a fix is released type the class super by hand rather than using the dialog.

R4 is a small, but significant release.  It moves Windows forward using Direct2D drawing, and Xojo Cloud is significantly faster for deployment, but perhaps the changes to the IDE are the most important.  The Navigator is not nearly as horrible as it was in previous releases and, in my opinion, makes it as useful, now, as the Real Studio IDE.  If you are still using Real Studio I recommend checking out R4 as I think it takes most of the pain out of using Xojo.

What’s new, changed, or fixed, that makes you happy?

Beta Program Incentives

I’ve been part of the beta program for over a decade.  Many cycles I bemoan the fact that I’ve found very little time to real testing before its released.  That’s bad and I suspect many of my fellow members of the beta program feel much the same way.

The incentive to be in the beta program is simple.  See the new features first and help find bugs and along the and way offer some advice and guidance on how new features work.  And in general, make the product better.  That is an incentive and it’s a laudable one but many cycles that’s not enough.  Perhaps there’s a way to give us more incentives.

I fight with finding time to beta test.  I’m often working under deadlines with real projects that I can’t afford to release a version with the beta.  There’s no way around that.  Perhaps there is something that Xojo can do to make it worth my while to do more testing.

What if Xojo gave a percentage off, say 5%, off a license purchase (either new or upgrade) if I hit some threshold of credible bug reporting?  I spend a lot of money on licenses so that might be a good incentive for me (or at least one of my developers) to work with the beta on a regular basis.

Obviously there would need to be ground rules to prevent abuse.  Bug reports must be well defined with demonstrable repeatability, example project, video, etc. to make sure there’s not a flood of crap.  After it’s reviewed by a Xojo engineer that bug report gets applied to our account.  Then when it comes time for renewal we can apply the discount we’ve earned.  Perhaps that means a percentage point for every five credible bug reports (not feature requests) during a release cycle with a maximum percentage.

Make a game of it.  Reward outstanding bug reporters with recognition.  Make the participant list public so everyone is aware that so-and-so is participating and finding a lot of bugs.  Maybe reward the yearly ‘winner’ with free or discounted admission to XDC.  As a person always on the lookout for new Xojo talent this might be a good way find someone as well as having a little fun with it.

I see this as a way to get new users involved.  For me a license is no big deal but for some it’s huge and if that user has extra time (or at least more than me) that will give them extra incentive to submit bug reports.

I get it it.  The beta program should be a win-win for Xojo and us users.  The reality is that I feel like we’re free labor to a certain extent.  I don’t feel much love from Xojo even though I *know* they do appreciate whatever beta testing we do.  Offer some discounts, make it a game.  Do something to entice us!

What are your thoughts?

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

Iconographer Review

iconographerscreensnapz001

If you’ve spent any amount of time making cross-platform applications in Xojo you probably hate icons as much as I do.  I’m no graphic artist and because of this I’ve paid good money for several icon sets.  These icon set are fine but they’re pretty basic/generic and don’t tend to look right in macOS, Windows 8 and above, or even iOS.  And that’s just for application icons.  Making icons for documents, disks, folders, and the like, are just as big a pain to make.  Each platform has several different styles and getting it right is awful.

Ohanaware introduced Iconographer last week.  This is the tool I’ve been waiting for!  Iconographer lets you easily make icons that are consistent for their target platforms all while keeping the overall identity intact.  Not having to use a high-end graphic tool, like PhotoShop is worth it to a developer geek like me.

Using it is easy.  Simply drag your starting image into the editor window and start manipulating it.  At the top left of the window there is an expanding toolbar, for lack of a better word, that lets you pick the Icon Type:  Application, Folder, Disk, Document, and Web Icon.  Below that you have options for the target.  Depending upon the Icon Type you have the option to pick the Target.  For Application you have macOS, Windows, and iOS but for the Folder Target you only have macOS and Windows.

screen-shot-2016-11-10-at-7-09-32-pmTo the right of the drawing canvas you can pick the style of the icon.  For macOS you have Blank, Circular, Rounded Rectangle, Tilted, Rounded Square, and Plugin.  For Windows you have Blank, Windows Tile, and Use Different Application Icon.  Similar styles are there for iOS.

Below the Styles is the Layers list that lists the layers in the selected Style.  I will be honest, I had issues figuring out how to manipulate the layers.  You can add layers using the ‘+ Layer’ button where you can add Shapes, Images, and Text.

Adding Text also was problematic for me.  Once I added a Text object I couldn’t always select it until I had rotated it and then reset it to zero.  Then, if I had two text objects I never was able to edit and change the text of the first one.  I chalk this up to possibly not understanding what the shared label is.  At times I also had a weird purple selection rectangle that I was never able to get rid of.
At the bottom of the drawing canvas is, perhaps, one of the more useful features of Iconographer.  The Eye lets you select from a number of environments to preview your icon in an About Window, the macOS dock, and even the Mac App Store, to name a few.  This is a great way to preview your app in an actual environment and lets you make decisions while in the application instead of having to leave and use a graphics application.

screen-shot-2016-11-10-at-7-09-49-pmOnce you’re done you can build your icons.  It takes the currently selected Icon Type and all of the selected Targets and outputs them into the directory of your choice.  For macOS it will create an icns file and for Windows an ico file.  It really is that easy.  It would be nice to have the ability to export SVG format too.  If you’re creating a suite of icons, say for application, document, and disk, you have to do it in several steps but that I suspect that most developers won’t have an issue with that.

Iconographer is a must have for any cross-platform developer.  It’s ability to make consistent application and document icons for macOS, Windows, web, and iOS easily and quickly make this an invaluable tool.

Iconographer works on macOS X 10.10 and better.  It normally costs $19.99 but Ohanaware has an introductory price of $9.99.  More information can be found at http://ohanaware.com/iconographer/.