Components

Writing quality software is an expensive, time consuming process. Once tested, packaged, and accepted, software created by the best developers is not only usable, but maintainable as well.

Interestingly, when creating reusable components today, few think that it is possible to include a user interface. Before the rise of Object Orientation this belief was perhaps understandable – user interface frameworks not only had to be self-authored, but the graphical underpinnings themselves were often extremely device-specific. Lacking patterns, poorly encapsulated, and complicated to maintain, re-using one team's display 'technology' often resulted in another team's loss of sleep. Rather than expose oneself to the follies of poorly designed frameworks, it was often easier to just write everything yourself.

Today however things have changed. From a graphical interface point-of-view, component writers should increasingly consider providing graphical views into their software and / or systems. No matter if we are using C++, C#, VB.NET, Delphi or Java –When it comes to designing our tools, why not include a few graphical component add-ons, as well?

Say WHAT?

Impossible, you might say? Not at all! Indeed, much like when designing any complex piece of hardware, we software developers need to appreciate that the components we create will invariably become part of a “system of systems:”

under the hood

For example, when we pull the covers off of any modern vehicle, we are not looking at any single system. Instead, what we see is a plethora of components being managed by a central processor.

While it can be amazingly enjoyable to assemble, program, & test discreet sensory systems, the pressure is on for everyone to provide turn-key business-solutions. Why? Because the man-hour savings to be had when re-using things like a compete radar system, weapons system, or even flight control - can provide some serious saving to our clients. Saving that can be quickly translated into markup for we original-equipment manufacturers.

Profits for all ... that cannot be ignored!

In order to make / save some amazing coin therefore, in software as in hardware, system architects & developers alike must expect that the interface to any of our components might indeed be custom, or self-provided.

While describing the process of operational abstraction is well beyond the scope of this article, I felt the need to clearly demonstrate one of the many ways we can include a graphical interface as an integral part of our re-usable components.

Instrumentation Panels?

Of course whenever we want to create add-ons, the first thing we need to have is a properly designed framework. Fortunately, from C# to Java everyone has been using their own version of Delphi's panel:

When seen as a “black box”, the above fragment of an interface-signature has all the artifacts necessary to maintain a useful configuration: A file for input, a panel for output, as well as the associated framework for passing signals (button clicks, focus notifications, etc.) back to our component.

By merely providing a file at the receiving-end of our API, whenever our panel is either provisioned or operated, our component can both read from, as well as maintain, a user-provided configuration file.

Bolting the Panel

From the user's point of view, even software component configuration can be part of many other systems.

When part of a series of operations (the above is from a tool manager I am writing at the moment from Java to C/C++ to a device: We changed the add-on names to make them more applicable to our analogy) the user is also free to use our JPanel to create their own mash-up. -From .NET to Java, I have done the same device-to-GUI tricks for legacy C, C++, and even Assembly Languages.

So here is the magic: Today, all GUI frameworks worthy of the name have components. In this case, components that can contain other components.

In Java, while we have a plethora of panel-hosting options, I decided to use a JScrollPane:

Since our panel can be used by the JScrollPane, whenever the user selects my component, after reading a little about what to expect (the top panel is the factory) he or she can thereafter press the “Config” Button & get on with actually configuring my component. -All while enjoying both the add-on interface, as well as the add-on code, we provided.

For what it is worth, here is the complete configure-n-execute tool interface for my aforementioned add-on tool framework:

/** * Useful when a tool is to be used as part of a work-flow, or process, of * previously-completed operations. * * The file passed to a previous startRun() is to be used as input * to YOUR startRun(). * * @return The tools to run, in proper order. Array length must be ZERO if * the running of other tool(s) are not required. * */ public iPhatTool[] getPreviousWorkflow();

/** * A short name - suitable for use in a drop-down combo box. * @return A short name (typically class.name()) for your tool. */ public String getToolName();

/** * A descriptive paragraph. Suitable for use in a rich-text (HTML) display. * @return HTML text used to describe your tool. */ public String getToolDescription();

/** * Begin running of your tool - (we will provide the main thread) * @param status Check this status whilst running - we will signal if the user needs you to stop. * @param fileRun Here is where you can read / save your results to / from. Can be used for work-flow (etc.) * @param log The log - messages you want to share with the user. * @return TRUE if you ran to completion, false otherwise. (Only TRUE operations can be displayed and/or used by work-flow.) */ public boolean startRun(OpStop status, File fileRun, StatusLog log);

Conclusion

I hope you found this conceptual overview enlightening. No matter if the views we provide into our component be diagnostic, licensing, configuration... or even real-time monitoring, I am often surprised at how happy my clients are whenever we deliver alternative graphical interfaces as part of our designs, frameworks, & components.

It's A Date!

As you might imagine, someone who writes robots designed to automatically mange opt-in content or daemons - designed to run unattended for decades - might have some relatively interesting time and date calculation requirements. Indeed, when tracking appropriately-recurring day-content containing holidays, events, and other falderal is more important than hours, many folks like to use Julian Days.

Day Julian?

The problem is, whenever we try to universally define exactly *what* any computationally useful encoding might look like, opinions can differ wildly. While some insist that 'day zero' is important, others disagree. -Speculation also rages over just how far back, and forward, an official year and / or day-count might reach. Rather than haggling over the exact time of a technically unmeasurable origin, how about coining a more event-relative time-reckoning?

Count-Downs

Living close to NASA, like others we have always been inspired by the mathematical possibilities of the "T - 1" form of event-counting. -Being computer geeks, we also recognize that using negative numbers can also have some decidedly plotable graphical & computational advantages.

Concepts Encoded

For the above (and other) reasons therefore, we decided to come up with our own definition of what a better Julian Date should look like.

-Negative Years

Honoring the mathematicians of The Roman Empire, only "Day 1, Year 1" will be encoded in event origination; Honoring the needs to align both computational & graphical symmetry, years before "Day 1", are negative. (We feel that using negative and positive numbers might be a better way to mathematically express concepts such as "BC" or "AD"?)

-Counting Days

Next, while incrementing / decrementing days AFTER an event are logical, things like decrementing the time BEFORE an event must be logically identical, yet mathematically inverted. (Time, after all, indeed has a somewhat forward bias?) Hence increasing or decreasing a pre-event calculation should ever maintain the same linear motion as do those same operations in the event's positive complement.

Consequently our new Julian year # day series before & after any event is:

... -1#3 ... -1#2 ... -1#1 ... [event] ... 1#1 ... 1#2 ... 1#3 ...

-Leap Years

For 'galactic reasons' (not all planets share the same number of days in their year after all!) note that the number of days & years around any event are completely customizable. -For the sake of conveyance to us 'Terrans however, by default the number of days in a leap-year remain as presently calculated.

-The Potentia

Finally, across all celestial bodies, adjusting for leap-years remains a somewhat arbitrary process. Because some years are allowed to have more days in them than others, we refer to the potential maximum number of days across all years as being the potentia. By way of example, while the usual number of days for our orb is 365, the potentia for Mother Earth is 366.

(While one might be tempted to apply Earth's n+1 formula to calculate the potentia everywhere, some conditions may require the scheduling of an event every n ''years'' yet - just as predictably - routinely lasting much longer than +1 days. Because the length of any schedulable, mathematical-rounding additive can obviously vary, the potential must be customizable.)

Try It

Therefore, submitted for your consideration please find our DateJulian class. -The guiding basis for all that our robotic endeavors deliver to-you on the Internet, I hope that you might find our "Julian Day with +/- Year" event-management concepts as invaluable, as we do.