I have been worried for some time that Java on the Mac is at an end. Apple abandoned Java back in 2017. I didn't expect Oracle or anyone else to really put much effort into keeping the Java GUI toolkits current with macOS changes. I don't even expect Java GUIs to remain for much longer, either. JavaFX was dropped in JDK 11. I am sure Swing would have gone too if it were not for some very important customers that are still dependent on it, for example, the US military and especially the Navy.
I have similar observations about NetBeans. NetBeans always seemed like Oracle's unwanted stepchild from the Sun acquisition. Updates were infrequent and with little innovation. Oracle has now passed it on to Apache, but how much attention is it going to get there? There are commercial applications that are built on top of the NetBeans platform and so some support will come from them, but it would be foolish for these commercial applications to remain desktop bound for too much longer. Even Eclipse, the quintessential Java tool for building Java tools, has moved its focus from being a desktop application to being a web application.
It is finally time to move off of NetBeans and to move off of any Java GUI application. I say this with a heavy heart as I have enjoyed and benefited from both over very many years. RIP.
Aside: If you are interested in large scale, pluggable, user interface design then do read everything you can about the NetBeans platform. It is remarkably well designed.
Update: Coincidentally there was a useful Twitter thread about this same topic.
Do you have a back-office workflow that has become complicated due to multiple pathways to completion and referenced data scattered across multiple sources?
Do you want to bring transparency to your handling of customer requests, but need to integrate this with a legacy system?
Do your online business processes generate voluminous detailed logs within which you are sure you can get useful historical perspectives, current awareness, and even some predictions?
Andrew Gilmartin Consulting is a solo software engineering consultancy. There is much one person can do these days. The availability of inexpensive online infrastructure and best-in-class open-source tooling has greatly reduced the cost and effort required to provide a solution. I have decades of experience designing and building software and user interfaces. I have built everything small gadgets to web-scale applications. It is your need to have it solved that interests me, and less so the kind of problem and my compensation.
So, please do call me or send me an email if you would like to chat about the problem and how I can help.
I use Google Docs and so the itch was scratched using Google's App Script. The script collects the text of all the TODO paragraphs and organizes them under a Table of TODOs heading. The TODO is a normal-styled paragraph that starts with "TODO: ". The Table of TODOs is a heading-styled paragraph that contains only "Table of TODOs". The script organizes the TODO texts in to numbered list items under the heading. The script also adds a Bookmark to each TODO paragraph so that it can be referenced from the numbered list item. To see the example you will need a Google account and to make a copy before you can view the script (under Tools / Script editor). [Update: Placed the script in a gist.]
I don't use GitHub gists much, but, apparently, I have been using them them for a long time -- 11 years! I had forgotten about some of the work I had done and dropped into gists. The horizon chart gist was part of my Horizon Chart blog post. I don't seemed to have posted anything about PDF Thumbnailer, however.
I originally created PDF Thumbnailer as part of a larger project to enable public commentary on South Kingstown, RI's budget. (SK is my home town.) When this project started in 2007 there were no available online tools for multiple users commenting on a PDF. So I needed to build one. The web interface consisted of just two principle pages, an overview page containing thumbnails of the whole budget with comment indicators laid over the thumbnails, and a details page of the whole budget and commentary interleaved.
To interleave the comments I needed to place them between the text, charts, and tables of the budget document. Parsing and rebuilding the PDF or converting it to HTML and rending it in the browsers of the time was more work than I could commit too. Instead, I compromised on the spacial proximity of a comment and its context. I converted the PDF pages to images and sliced each image into 1" tall strips. I could then interleave strips and comments on the details page as needed. While a comment was not attached to the context it was close enough to establish the connection.
In these sketches the pages are bounded in red, the strips in blue, and the comments in purple.
The project was never completed, but it did leave behind the thumbnail creator. I rebuilt it this morning and here are a few example pages from Rescue.org's recent report Missing Persons: Refugees Left Out and Left Behind in the SDGs
In the Winter of 2001 the US Navy began the re-development of the DD-21 destroyer class warship after Congress slashed the original budget. The new ship class DD(X) and named after Admiral Zumwalt was to be the Navy’s first fully integrated command and control (C2) vessel featuring a small crew, multipurpose vertical launch tubes, large flight deck, and with enough electric generation capacity to power small cities or the anticipated kinetic and laser weapons.
What was not divulged at the time, was that the Zumwalt’s C2 left little need for fully sentient beings to operate the ship. It has been learned that a black budget division within the Navy’s Marine Mammal Program has been replacing the crew of the DDG-1000, currently at sea in the San Diego, CA area, with mollusks and cephalopods. Mollusks, due to their limited intelligence, (newly hardened) protective shells, and stationary nature, have been integrated into the ship-wide computing networks and are now responsible for intermediating with all sensors and actuators — from missile launch tubes to freshwater valves.
How far along the chain of command has been replaced with coleoidea is unclear. There is strong circumstantial evidence that the ship's captain is a human-octopus hybrid. The recent waterproofing polyethylene application to the inside walls of the ship’s bridge and mission control centers suggest that the hybridization is more octopus than human.
More news to come.
A display for showing details of actors, messages, and listeners (dependents) might be
Yesterday I wrote about providing tools to visualize & manage the internal workings of applications for maintenance developers. That note was long on advocacy and sort on detail. This note somewhere between those two.
We are all familiar with run-time debuggers. We can get our job done with gdb , but for day in and day out work a visual debugger is a must have. A debugger is a point-in-time dashboard of the execution of the programming language used to implement the application. It is not a dashboard of the application, it does not directly represent the application's data or processing models. Nor does it provide a history of where the application was or a prediction of where it will be heading too next. Nevertheless, it is a useful analogous image of the application dashboard to keep in your mind.
If, for example, your application relies on the observer pattern  then you will need to visualize & manage the actors (observed), their dependents (observers), and the messages. The effort to implement this dashboard can be significant, which is the exact opposite of implementing the pattern itself. The pattern is often implemented as a list of callbacks. This implementation is so insignificant that your high performing developers probably choose not to use a framework at all, but to re-implement for each use. And there is the root of the trouble ahead for the maintenance developers, there is no one place to watch this running application. Callbacks and messages are being created and dispatched all over the place.
Suppose there had been a reusable implementation. The management of the listeners was done in a single place. The dispatching of messages to the listeners was done in a single place. Each reuse required that the developer explain the purpose, configuration, and expectations of this reuse. For example, "Status of the nightly recalculations of base prices: the messages are life cycle events; messages are ticketed and numbered for correlation; the listeners can be local or remote; the listeners are contacted asynchronously; no receipt acknowledgement is wanted, but when given will be logged; expect a dozen messages over a 2 hour period in every 24 hour period to be sent to a few hundred listeners." When this pattern is visualized on the dashboard not only is the context clear, but timelines of planned to actual and switches to toggle synchronicity will automatically be included. And what if you could dynamically toggle receipt acknowledgement? How many of your application's ailments are the result of lost messages sent to remote listeners?
The rise of DevOps has brought with it both tools and new (renewed?) appreciation for visualizing processes and their artifacts. Lets keep on pushing these ever deeper into the application itself.
We all want visibility into a running application. The need becomes acute when the application is ailing and that visible schedule, map, and cartogram of the data and processing will swiftly guide you to the failing part.
What is less recognized is that these same visuals are needed in maintenance. Your original, high performing developers are unlikely to be around after the application has been in production for a few years. They will have moved on to new green pastures. If you are lucky and they are still with the company then they will be somewhat available to the maintenance developers. If a little cantankerous about that.
The maintenance developer usually has little broad knowledge of the application’s operation. Her first task at resolving an application’s ailment will be to find suitable entrance and exit points. This is not an easy task for our applications now run continuously, across multiple processes and hosts, and are highly asynchronous. Hopefully, those high performing developers adhered to standards, used a common framework throughout, and kept to best-of-class external libraries and supporting tools. If they did then she might have a straightforward resolution path. In all likelihood, however, those high performing developers probably invented too much and documented too little. [I speak from the experience of my younger self.]
What the maintain crew needs is not logs alone. They need meta tools that connect to the running application and visually show its operation. Once connected the tool must be able to slow down the application to a human pace. Restrict it to one active user at a time. It might even need to switch it to run synchronously.
These are not easy features to implement, but the cost of not doing it is not just the ever lengthening backlog of ailments to fix, but the erosion of customer confidence and, in the end, loss of customers.
All modern applications have three users. The first is the customer. The second is the customer support. The third is the maintenance crew. It is way past time that the maintenance developer is provided the meta tools needed to look inside the running application and keep it fit for market.
Update, Aug 17: As of a few days ago the password management started to work again. The Chrome version is now 76.0.3809.100 and so I must have gotten a update. Google, thank you.
I have decided to keep the figures. I had intended on selling them, but, the figures are very nice and perhaps I will play the One Page Grimdark Future Rules one day.
Permit drawings (draft)
Klin & Electrical Specications
As to the Java language and its ecology, this has little interest for them. In fact, many of the infrastructure foundations that are today implemented in Java -- ActiveMQ, Kafka, Zookeeper, Tomcat, etc -- are being replaced with "lighter" Go and Rust implementations. And with the accelerating move to managed infrastructure startups care little about how these foundations are implemented. They would rather rent, eg, a queuing service from AWS or GCP, and let the provider worry about implementing turnkey, scalable performance.
Even Citizens Bank, after having recently become independent of the Royal Bank of Scotland, is replacing their Java J2EE implementation with an AWS hosted, node.js microserviced, and React front ends. I have even heard that some of their services are from a "bank in a box" supplier.
I accept the need for YouTube to generate revenue with advertising, and, as crazy as it sounds, if the ad is short, I let it play through rather than take action to skip it. What I can't accept is the jarring interruption of the interstitial ads. You are listening to a 7 minute recording of a live performance. The performance beautifully builds for the first 3 or 4 minutes and then, just when it reaches a crescendo, an ad for throat lozenges breaks into the middle and ruins the whole thing.
I will continue to use YouTube as it has so much content useful in my daily life. I am going to skip most everything else until they replace the interstitial ads.
The "Phoenix Checklist" is a set of questions developed by the CIA to define and think about a problem, and how to develop a solution.
- Why is it necessary to solve the problem?
- What benefits will you receive by solving the problem?
- What is the unknown?
- What is it you don’t yet understand?
- What is the information you have?
- What isn’t the problem?
- Is the information sufficient? Or is it insufficient? Or redundant? Or contradictory?
- Should you draw a diagram of the problem? A figure?
- Where are the boundaries of the problem?
- Can you separate the various parts of the problem? Can you write them down? What are the relationships of the parts of the problem? What are the constants of the problem?
- Have you seen this problem before?
- Have you seen this problem in a slightly different form? Do you know a related problem?
- Try to think of a familiar problem having the same or a similar unknown
- Suppose you find a problem related to yours that has already been solved. Can you use it? Can you use its method?
- Can you restate your problem? How many different ways can you restate it? More general? More specific? Can the rules be changed?
- What are the best, worst and most probable cases you can imagine?
- Can you solve the whole problem? Part of the problem?
- What would you like the resolution to be? Can you picture it?
- How much of the unknown can you determine?
- Can you derive something useful from the information you have?
- Have you used all the information?
- Have you taken into account all essential notions in the problem?
- Can you separate the steps in the problem-solving process? Can you determine the correctness of each step?
- What creative thinking techniques can you use to generate ideas? How many different techniques?
- Can you see the result? How many different kinds of results can you see?
- How many different ways have you tried to solve the problem?
- What have others done?
- Can you intuit the solution? Can you check the result?
- What should be done? How should it be done?
- Where should it be done?
- When should it be done?
- Who should do it?
- What do you need to do at this time?
- Who will be responsible for what?
- Can you use this problem to solve some other problem?
- What is the unique set of qualities that makes this problem what it is and none other?
- What milestones can best mark your progress?
- How will you know when you are successful?