Be yourself; Everyone else is already taken.

— Oscar Wilde.

This is the first post on my new blog. I’m just getting this new blog going, so stay tuned for more. Subscribe below to get notified when I post new updates.

This is an example post, originally published as part of Blogging University. Enroll in one of our ten programs, and start your blog right.

You’re going to publish a post today. Don’t worry about how your blog looks. Don’t worry if you haven’t given it a name yet, or you’re feeling overwhelmed. Just click the “New Post” button, and tell us why you’re here.

Why do this?

• Because it gives new readers context. What are you about? Why should they read your blog?
• Because it will help you focus you own ideas about your blog and what you’d like to do with it.

The post can be short or long, a personal intro to your life or a bloggy mission statement, a manifesto for the future or a simple outline of your the types of things you hope to publish.

To help you get started, here are a few questions:

• Why are you blogging publicly, rather than keeping a personal journal?
• What topics do you think you’ll write about?
• Who would you love to connect with via your blog?
• If you blog successfully throughout the next year, what would you hope to have accomplished?

You’re not locked into any of this; one of the wonderful things about blogs is how they constantly evolve as we learn, grow, and interact with one another — but it’s good to know where and why you started, and articulating your goals may just give you a few other post ideas.

Can’t think how to get started? Just write the first thing that pops into your head. Anne Lamott, author of a book on writing we love, says that you need to give yourself permission to write a “crappy first draft”. Anne makes a great point — just start writing, and worry about editing it later.

When you’re ready to publish, give your post three to five tags that describe your blog’s focus — writing, photography, fiction, parenting, food, cars, movies, sports, whatever. These tags will help others who care about your topics find you in the Reader. Make sure one of the tags is “zerotohero,” so other new bloggers can find you, too.

Original Post Dated: 01.16.2019 by Bob Calco

Drum Roll, Please …

As followers of this blog are well-aware, we’ve been in a bit of an R&D mode for some time now. We have been seeking the right combination of feature purpose and vision to power a product line that we believe is true to who we are and at the same time capable of delivering real market value.

We are at a point now where the light at the end of our tunnel-vision is signaling a new season for us. We are excited and confident that our release strategy for harmonizing the products we’ve been working on will bring real value to our customers.

Going forward, we are focusing exclusively on our interoperability vision through Apex Unfiy!™, but with a twist: We now plan to offer a bundled desktop version to the consumer market – basically, “Unify! in a box” – under the trademark Apex DomainMaster™.

Where does this leave Apex Athena, Muse, Perseus and the other cast of Greek characters we’ve been alluding to in our past posts and site pages, you wonder?

The answer is: Exactly where they have always been, in the middle of both Unify! and DomainMaster. We realized, the more we iterated toward a standalone release of Athena and Muse, that the highest best use of these runtimes is in the service of the interoperability mission of our company and its products. We live in the Cambrian explosion of new languages, and rather than compete against other general-purpose languages for developer attention we decided simply to put them to domain-specific use.

While we will of course still offer SDK’s for tech partners and enterprise customers of Unify!, the idea of maintaining general-purpose language runtimes when our mission is not so general purpose no longer makes business sense. Rather, they will be bundled and available for use through Apex DomainMaster (and Unify!) to support a wide variety of business and consumer uses.

Because our domain, and therefore our business, is interoperability, we have developed a complimentary set of technologies including the Athena, Muse and Zeus runtimes. We created these for many reasons, but the upshot is, users of our interoperability-related technologies will have a buffet of mostly-familiar language choices to extend our products with scripting in ways that we believe will speed up implementation efforts.

So What, Exactly, is “DomainMaster”?

DomainMaster is all about bringing enterprise Linked Data to the Desktop. DomainMaster offers the desktop databasing autonomy of MS Access, without the linked or shared data limitations. Linked Data, a.k.a., “the Semantic Web,” is a set of technologies that are still largely unknown and inaccessible to “mere mortals.” Existing tools for consumer database development are in the Dark Ages, comparatively speaking, relative to the data architecture powering distributed enterprise systems on which so much of our personal data resides.

But the tools used by the modern enterprise for Linked Data are extremely complex and expensive to use. So, somewhere between something as easy and inexpensive as Access used by small businesses, and as complex and costly as data governance tools used by high-end data architects, we believe there is a gap, and more importantly a consumer and enterprise need, that DomainMaster is designed to fill.

DomainMaster isn’t just about Linked Data itself, but rather Linked Data in the service of data interoperability as an ongoing, operational and practical concern. Toward this end we have found what we believe is a novel use of our patent pending blockchain technology, one that flips conventional wisdom on its head. DomainMaster’s use of Apex’s flavor of blockchain will make it a kind of “Napster” for data, where users are in control of who sees their information and the distinction between desktop and cloud is finally debunked.

The “cloud” has only ever been “other people’s machines” and the case for abandoning the desktop has been deeply disingenuous from the point of view of the Internet. Sure, there is a good business case for renting a slice of other people’s data centers–but it’s overblown given the sheer power accessible to Everyman on the modern desktop. Vast amounts of data and processing power are largely untapped by most consumers who buy a high-end laptop nowadays, machines that can certainly ensure they have autonomy over their own information.

You truly are ““master of your domain”” with this innovative new offering, putting the full power of our enterprise Unify! platform in the hands of mere mortals (ahem) – democratizing them even before they take hold in the enterprise in bottom-up vs. top-down fashion. You know, the way the Web was supposed to work…

And Now A Word from Our Forecasters & Soothsayers…

So when will this be ready, you ask? Our first release is targeting May 2019. We have yet to redo our website and create the customer portal, Apex Agora, to take orders, but as soon as that is done we’ll be making Apex DomainMaster available for download and purchase. For details, please see DomainMaster’s new product page.

Original Post Dated: 09.16.2018

The Final Pivot

As every software engineer knows, conceiving, designing, building and nurturing products into existence is hard. The more ambitious the concept, the more painful and sometimes surprising the birth. Also, the more ambitious the concept, the longer it takes to materialize.

More often than not, you start out with one idea and after some interaction with existing or prospective users, it turns into another or possibly several new ideas. The inability to pivot in order to allow the very concept to evolve in a market-driven way is often a reason for failure of many projects, because the original concept was slavishly implemented and the signs, indicating the idea itself was flawed or could be improved in certain ways, were missed.

On the other hand, pivoting “too much” also creates a risk of failure by allowing scope-creep to push the release horizon into a distant and unreachable future. Pivoting too much can result in spinning your wheels and eventually releasing …nothing.

I wax philosophical on these points because Apex Athena and Perseus both have been “close” to release, by some definition of the term, for a long time. We have in the last year pivoted no less than three times, and in one of those cases, the pivot was fundamental: we decided NOT to release Athena according to the same business and deployment model to which its progenitor, PAX compiler, was sold. While this pivot had profoundly positive implications regarding precisely what Athena has become, it came at some opportunity cost as we have understandably irked some customers who were hoping for a simple PAX drop-in replacement. However, this pivot was anchored in our desire to stay faithful to the originally intended scope for Athena, Perseus and Muse. As we have communicated to participants in our beta test program and the to the community at large in our other blog postings, Athena is much, much more than a Pax drop-in replacement and was never intended as such.

With that said, we are at a crossroads and face another important decision point, which we expect will be our final pivot: What are our objectives with the Community Release and how best do we achieve those objectives? In other words, do we release the Community Edition of Athena now simply based on timing or do we release the Community edition when we believe it has the best chance to gain the community traction and support we are targeting.

Apex Olympos CE Release Delayed

We’ve made our decision.

We are delaying the release of the Community Edition of Apex Olympos (our bundle of the entire Perseus, Athena, Muse and Zeus toolchains) until Q1 of 2019. That’s the bad news. The good news is, there is a valid reason to do so that we believe will offer greater success to the Community Edition as it will allow us to take the necessary time to fully refine the feature stability, documentation and support of the Apex Olympos toolchains, whose commercialization are a separate but secondary consideration from how we plan to use them in Unify!. Also, when we do release the Community Edition, the Professional Edition will also be available at that time (we had originally planned to stagger their releases by 90-120 days).

Trying to thread the needle of staying faithful to the original vision for the Olympos toolchain while at the same time trying to be responsive to the demands of the Pax community, has been a challenging balance of interests. The combination of the original vision for Athena, Perseus and Muse combined with the use of these technologies to solve real world enterprise challenges as refleced in current use cases on which we are working with large commercial enterprises has underscored our decision that releasing Athena, Perseus and Muse at this time, even in a Community Edition, is a bit premature. These commercial use cases offer our team the real-world commercial environment to ensure that these technologies will meet not only our standards, but the needs of our customers.

At HIMSS 2019, we plan to present a Use Case demonstration, discussed below, of the capability of our flagship Apex Unify! platform, of which Athena, Perseus and Muse are critical components. We have always ever conceived of them as enabling technologies for our overall “interoperability-as-a-platform” stack and this Use Case will allow us to show them—and some other game-changing technologies we’ve been quietly working on —off properly.

As noted above, although we could release the Community Editions of Athena, Perseus and Muse sooner, they aren’t quite in that state we want them to be in, to consume them the way we envision our customers consuming them. If we were to release them now in their rawer state, the trade off would be a longer time period to deliver the more complete feature set we envision. Worse, it could jeopardize our progress on the Unify! stack which is also at a critical juncture.

In the end the decision was quite simple: we cannot release until we feel its ready for consumption and any such release decision has to reflect the relative role of Athena, Perseus and Muse within the overall technology portfolio we are developing.

The Endgame

With our HIMSS 2019 presentation, we anticipate showcasing Athena, Perseus and Muse in the context of our Unify! platform by demonstrating generalized interoperabilty between disparate enterprise systems of record. We will do this in conjunction with at least one large health industry company as part of an industry-wide solution focusing on Provider Directory as well as the Provider-Payor data exchange to streamline many of the Administrative costs and burdens associated with claims processing and payment. We hope that this emphasis on delivering real-world solutions will underscore the value-added nature of not only the Unify! stack, but also the enterprise flexibliity and configurability offered by Athena, Perseus, Muse et al.

In the end we know this will result in a better Apex Olympos, one better fit for both our original purpose, and for the community we plan to foster around its separate but equal life as a dual-licensed software product.

So, Apex Athena, Perseus and Muse early adopters, we ask for your patience one last time, as we make this final pivot. When you see what we’ve been up to with Apex Unify!, and how much more powerful and relevant that will make Apex Olympos to your enterprise efforts, you will understand why this was necessary.

Original Post Date: 08.17.2018 by Bob Calco

Have a Drink on Us

We have been getting a steady stream of feedback from users of the PAX compiler about our new business model for PAX’s evolutionary successor, Apex Athena.

In this post, we address some of the specific issues that are recurring in this valuable feedback, and offer a path for users of PAX, or any other traditional embedded scripting engine, to explore the new paradigm Apex Athena and Apex Muse are attempting to pioneer.

Does this mean drinking a bit of our Kool-Aid, so to speak? Sure, but it’s great tasting stuff, and we’re willing to give you a generous sip, in the form of our Community Edition (soon to be released) and an “Early Adopter” program that we’re in the process of putting together to help us finalize the Professional Edition feature set.

What about PAX?

Before we talk about the Early Adopter program, let’s first provide the definitive explanation regarding why we’re departing from the traditional Delphi component vendor model.

Many PAX users are intrigued by our new direction, but some are concerned, because they’re used to the traditional Delphi component model where you pay a small (usually single developer) fee, get full compilable source, unlimited distribution rights, and lifetime use of the product (or at worst, pay an annual renewal to keep new editions coming along).

In other words, they were quite comfortable with the no-strings-attached model, but this was one in which the success of PAX compiler itself could not be sustained.

Why the Old Model Didn’t Benefit Anyone—Not Really

Unfortunately, this model doesn’t suit the purpose we envisioned for the runtime when we acquired it. Nor was it suitable for PAX sustainment, either.

What many PAX customers don’t appreciate is that, although for their narrow application purposes PAX really rocked it compared to almost any alternative in the Delphi space, PAX as an ongoing business concern failed.

Among other reasons, PAX failed because it’s simply not sustainable for a technology as sophisticated and frankly value-added as PAX was (and now Athena is, even more) to be commoditized to this business model.

Additionally, malicious users pirated PAX, in some cases using it for less than legitimate purposes. These plagued the original author and undercut his ability to make a living with it.

The reality was that Pax wasn’t a toolbar widget or some new fancy grid component that any intrepid Delphi developer could create and support, but a full-on compiler/interpreter with both general purpose and domain-specific uses that span the full range of possible computing applications.

The market for embeddable scripting technologies, however, is relatively small, or in any case deeply niche, and overpopulated with free or low-cost alternatives, even in the Delphi market.

“If that’s the case,” you wonder, “then why did you, Apex, buy it?”

Great question!

Why We Acquired and Re-envisioned PAX

The story of how we came to acquire PAX is interesting, at least to us, but more important for this discussion is to understand the reason for our acquisition.

The truth is, we didn’t initially seek to acquire PAX at all.

Rather, we were interested in building a new kind of scripting runtime, initially as an R&D effort, eventually to be utilized as a low-level component of our Unify! stack. To that end our team worked with the original author of PAX to devise what later became (and is still in the process of becoming) Apex Muse.

As Muse evolved, we realized PAX had nearer-term potential for the kinds of use cases we were devising Muse to satisfy, and it made sense to acquire it and align it with that vision rather than simply to deprecate or discontinue it. We gave the completely re-envisioned, deliberately re-designed PAX a new name: Apex Athena.

Now, we initially thought the first release would be a bug-fix on PAX and released quickly. We were ready to promote it as a drop-in replacement for PAX and even beta tested it as such. Because of the re-design and the broader vision enveloped in Athena (versus Pax), the release of Athena was delayed until the Community Edition could support the broader range of capabilities envisioned for this technology.

In the end we acquired PAX and turned it into Athena in order to further our vision for legacy application modernization and data interoperability, seeing Athena as a kind of ying to Muse’s yang. It also allowed both runtimes to be optimized for the different kinds of languages they support, with different target developer profiles in mind.

Apex Athena’s Mission

Apex Athena’s mission is to bring enterprise developers skilled in popular imperative, statically compiled languages like C#, Visual Basic, Pascal, etc., into the 21st century of serverless computing, specifically in the context of complex data exchange orchestrations and semantic interoperability supported by our Unify! stack.

While “serverless” platforms on all the major clouds already exist, the model we offer in Apex Unify! will be entirely domain-customizable and not dependent on a particular cloud infrastructure. Rather, it will be easy to deploy into environments at any scale.

By “serverless” we mean to support a flavor of Rapid Application Development (RAD) in a distributed n-tier environment, which is very different from the traditional front-end GUI application world that PAX Compiler grew up in. Our vision for application extensibility is in the service of modernizing monolithic applications, not in the service of native GUIs only.

This modern vision for “application extensibility” is achieved by converting large monolitic applications into micro-services across all the layers of the modern enterprise stack. This model for RAD fits nicely into Embarcadero’s new focus on IoT and server-side Delphi, but more importantly, it’s where the industry is going.

Apex Olympos Community Edition aims to provide the initial “taste” of this strategy—our “Kool-Aid” if you will—to the smallest possible scale: the desktop. It aims to provide hobbyists and independent developers the kind of tooling to create distributed applications that previously were only possible by the Googles, Amazons and Microsofts of the world.

What will the Professional Edition Provide?

The Professional Edition will provide additional features, including an SDK for import libraries and special tooling around refactoring monolitic applications, toward that end. RAD Studio IDE integration, as well as editing support for popular text editors on non-Windows platforms, will also be part of the Professional Edition.

Our “Early Adopter” program will make this available to select developers sooner than we plan to make it generally available. We are still trying to figure out exactly when that will be, and currently are focused on getting the Community Edition out the door first.

Conclusion

We hope this helps explain our intentions behind transforming PAX from a conventional component in the Delphi vendor market into a transformative technology squarely focused on legacy modernization and distributed computing.

Our expectation is that as Athena’s new mission is made clearer with the release of the Community and Professional Editions of Olympos, not to mention the Unify! stack, developer uptake will be broader and more enthusiastic than if we simply continued to commoditize it per the PAX model.

We believe the Delphi toolchain can play an important role in the future of distributed computing. Our vision for Athena and Muse as enabling technologies for Unify! is key to giving Delphi a truly full-stack presence in the modern enterprise.

Original Post Date: 08.17.2018 by Bob Calco

Get Ready!

This post is to provide a brief, and somewhat overdue, pre-release update on the status of Apex Athena & friends.

We know many people (Pax Compiler customers in particular) have been waiting, more or less patiently, for Apex Athena, and our dates have clearly slipped a bit… again, so we felt it was important to check in with some new insights into what we’ve been up to.

More importantly, we want to explain why it will be worth the wait, and how much more of a wait you can reasonably expect at this point.

Two words: Get ready!

The Lofty View from Mons Olympos

As we previously disclosed, we have been working hard to bundle an initial “Community Edition” of our core products. Here’s the 30,000 ft. explanation.

Our internal code name for this bundle is Apex Olympos, and the Community Edition will be free and contain (among other goodies) the following components:

• agora.exe – Our license management utility.
• perseus.exe – Our project and package management utility.
• athena.exe – The Apex Athena static, imperative language runtime and compiler as a standalone scripting engine.

On the edge of maybe being included in the initial release, but probably not:

• muse.exe – The Apex Muse dynamic, functional langauge runtime and compiler as a standalone scripting engine.

In future releases we also plan to deliver:

• zeus.exe – The Apex Zeus WASM runtime and compiler as a standalone scripting engine.
• odyssey.exe – A new kind of browser with special support for FRP-style UX that is uniquely suited to the security needs of distributed enterprises.

The Apex Olympos bundle will provide free versions of all of these utilities, and constitute a complete toolchain for rapid development of distributed microservices in the service of legacy modernization and the data interoperability and reconciliation mission of our Apex Unify! stack.

That’s nice, but what are these mythological beasties, exactly? you ask

Let’s discuss each of these applications in a bit more detail, shall we?

Apex Agora (agora.exe)

Apex Agora is our command-line license management utilty. It’s a command line application because all of the tools in the stack (with the exception of Odyssey) also have to run on headless Linux servers, in addition to Windows and Mac OS X.

Technically, the fully realized Apex Agora will be distributed and include our online customer web portal and e-commerce backend as well, but the command line utilty will be done before the portal, so in the interest of generating community buzz, we’ll be releasing it sooner.

The main function of Agora in the free Community Edition will simply be to unlock features of the free functionality constrained by the 30 day trial period. We want folks who “get” what the tools are about to help us build a development community around the vision, and to discourage non-committal use of these technologies.

So: Yes, we insist on registering even the free edition, so we can provide good community support. You’ll really appreciate this once the web portal is complete.

Longer term we see it also as a means to distrubute partner products built atop the core components using our Professional Edition (see below). We’ll be discussing this in future blog posts when that becomes more relevant. Stay tuned.

Apex Perseus (perseus.exe)

Apex Perseus started off its secret life as a humble code library chock full of bleeding edge awesome, but has morphed in the making into an eminently practical package and project management utility for Athena, Muse and eventually Zeus.

In short: perseus is to athena et al. what npm is to Node.js, mix is to Elixir, gem is to Ruby, lein is to Clojure, and so on.

Initially, Perseus will focus on code-generation templates, local script tasks and custom commands, but as the toolchain rapidly matures, it will include being able to share code through public repositories and open source Athena, Muse and Zeus projects on Github, Bitbucket, etc. We won’t be holding the initial release up over that, but know that it’s coming soon!

Of course perseus will still contain oodles of awesome but much of that awesomeness will be surfaced directly via novel features of the varous languages supported by each runtime in a more or less uniform way, rather than as a native library. More on that shortly… keep reading. 🙂

Apex Athena (athena.exe, apexathena.dll)

Apex Athena is the evolutionary successor to the PAX compiler, but the concept of extensibility it supports is considerably expanded and in fact arguably the converse of PAX’s. The focus isn’t so much on extending a particular EXE, but on distributing a system created by modernizing a single EXE. In other words, the focus is on legacy application modernization and rapid development of enterprise web applications and micro-services, not merely on application automation or customization.

In the long range, we expect the popular languages supported by Athena et al. to bring developers in the Embarcadero stack into better alignment with developers on other stacks, and to attract new developers to a new Embarcadero-powered toolchain that is savvy with respect to modern “agile” development.

There are, it turns out, many ways to RAD, and we’re hoping Athena creates new opportunities for old-time Pascalers to join a club previously restricted to developers working on script-based runtimes like Node, Python, Ruby etc.

Put another way: The old PAX compiler’s main goal was to support extensibility of Delphi and C++ Builder GUI applications via in-process scripting. Athena’s concept of extensibility is more in line with current industry trends toward distributed programming and rapid development of micro-services powered by scripting runtimes.

While the Professional Edition of Athena will support embedding of the runtime in Delphi and C++ Builder applications of all kinds, it will do so very differently.

PAX was marketed as traditional component like any other in the Delphi stack, and was available with source and embeddable without restriction. This was great for PAX customers, but it made it impossible to prevent software piracy, which was a huge problem for PAX’s original author, Alexander Baranovsky, before we joined forces to reinvent it from the ground up.

By contrast, Athena in the Professional Edition will be embeddable according to an OEM license via a DLL (apexathena.dll), with a C-style interface that permits any application to embed and extend it, and without regard to the native compiler or native compiler version.

But unlike PAX, it will also allow you to create complete web applications and micro-services of all kinds in elegant, extensible flavors of Pascal, Basic and C/C# that are quite powerful and uniquely suited to tackling the most difficult challenges of legacy modernization and data interoperability.

Which (not coincidentally) is why we’ll be embedding them in Apex Unify! as well. 🙂

Apex Muse (muse.exe, apexmuse.dll)

Apex Muse is a scripting engine, like Athena, but it focuses on dynamic, functional programming languages, and was designed first and foremost as a self-hosted scripting engine, like Node.js. Where Athena supports Pascal, Basic, a dialect of C inspired by C# called C-Minor, and legacy (ECMA 5) JavaScript, Muse supports Lua, the latest JavaScript, and a new language inspired by Elixir we’re creating called Raptor. Moreover, it’s incredibly easy to build new dynamic, functional languages on its core.

Muse represents a real innovation in “polyglot” virtual machine design, optimized for functional and dynamic languages, and our long-term goal for Muse is to combine the RAD benefits of Node.js with the distributed savvy of the BEAM VM and the power and speed of popular enterprise “nanny” runtimes like the JVM and CLR, but with a much smaller footprint.

The decision to choose Muse over Athena is mostly one of paradigm preference. Some people prefer imperative, statically typed languages. That’s OK, we have known and loved them all, and Athena fits that bill. Others prefer dynamic and functional languages, and that’s OK, too. Muse has them covered.

What we didn’t want to do, is paint our larger legacy modernization and enterprise data interoperabilty vision into a language corner or get in a turf war with other established “commodity” languages. So we did the only sensible thing under the circumstances: we made sure our language options included something for everythone.

So Muse is the ying to Athena’s yang, you might say. Both will allow you to pick from a virtual smorgasbord of languages in which to code, languages that are familiar yet in some respects new.

Whichever you choose, our motto is: “what is old is new again.” None of the languages supported by either runtime are stuck in the past. Quite the contrary, we have worked hard to bring innovative new features to them, and to make them extensible through meta-programming. More on that, later.

Apex Zeus (zeus.exe, apexzeus.dll)

Apex Zeus is an implementation of the up and coming Web Assembly language, or WASM, with a twist. Zeus aims to provide first-class language support for web programming, but with additional primitives to support the React.js style of programming.

Zeus is still in the early R&D phase of development, but it’s a high priority for us as we intend to use it in a new, specialized browser we call Apex Odyssey. Which brings us to…

Apex Odyssey (odyssey.exe)

Apex Odyssey is a new kind of browser client built specifically to support Zeus’ flavor of WASM, not “yet another browser” trying to compete with the Big Boys.

Odyssey aims to change the game primariy on mobile platforms, both in terms of performance (the primary driver for WASM) and in terms of usability and development support. Also, we intend to use Odyssey to create a new kind of UX that makes it much easier to “tell a story” from linked data, so in this sense it’s a specialized kind of UX that specifically supports our Unify! stack’s interoperability requirements, but we expect it to outgrow even our use cases if it is successful.

So, keep an eye out for Odyssey too, once we start releasing the Community Edition of the Apex Olympos bundle.

Innovations

There are two really exciting innovations that have evolved in the course of our work bundling all these products.

Apex MetaTree (MTree) and MetaPath (MPath)

We’ve alluded to these before. Every language we release as part of Athena, Muse and eventually Zeus will feature MPath, a generic kind of XPath, based on MTree, an in-memory intermediate data structure for parsing data exchange formats like XML, JSON, YAML, EDN and countless others.

MPath will provide declarative syntax for querying MTree structures obtained from files and streams in almost any format you can imagine (or otherwise implement). Each language will allow you to extend the range of formats and manipulate such files and streams at a higher level of abstraction than mere format parsers.

Apex Macro

This feature is a relatively recent development that is one of several reasons why we decided to let our initial release dates slip. It represents a way to add meta-programming to any Athena, Muse or Zeus language that is uniform and much more powerful than traditional C-style macros. If you are familiar with Lisp, Elixir or Rust macros, you have a better idea what we’re talking about.

Each language will allow you to define not just boilerplate code but even new constructs or features. We will be documenting some interesting examples with our initial release that we hope will get you excited, too.

The Bottom Line

OK, so this is where you get to ask, “When will the first release be ready?”

Glad you asked! Presently we are on track to get the initial Community Edition release done by mid-September. We are trying to get Muse included in that release, but may have to let that slip to get something in your hands. We are also weighing our desire to produce full documentation with the need to have some tires out for the Community to kick around sooner than later. Minimally we will strive to have several good tutorials and videos to help the Community wrap its mind around the vision and direction we’re taking these technologies.

So, keep checking in weekly for new blog posts as we near our initial release and determine its official date. We hope you see that we’re doing A LOT in the final home stretch to make this release special and deeply appreciate your continued patience. 🙂

Original Post Date: 04.18.2018 by Bob Calco

This blog post is to announce an exciting new direction for our soon-to-be-released scripting engines and run times, including Apex Athena, Apex Muse and now Apex Zeus.

This change impacts our expected rollout of these technologies in the near-term, as we are now in the process of preparing them for a different kind of distrubution and licensing model than initially intended. These changes reflect our desire to offer these technologies in a way that we believe will be of longer-term greater value to you, our customers, while also taking into account perspectives offered by our beta test partners.

A New Vision for Legacy Modernization

In short, Athena, Muse and Zeus are now part of an initiative to support legacy application modernization through a strategy we call “Extensbility as a Platform” or XaaP. In the spirit of XaaS (“Anything as a Service”) each of these runtimes will support an out-of-process execution model that allows a developer to distribute discrete portions of an application’s functionality and business logic on a micro-services model that is cloud-neutral and containerization savvy.

A means to orchestrate pipelines of distributed functionality on a full-stack, highly scalable, fault-tolerant and event-driven model will be provided by Apex Eos.

Coming Soon: Apex Functor™

Our hosted version of this functionality will be called Apex Functor, a cloud-agnostic alternative to Amazon Lambda, Google Function and Azure Functions. Each of those services tightly couple your systems to their infrastructure, and if you are committed to their infrastructure, they’re great. But with Apex Eos and Apex Functor, you are free to BYOC – either “Be Your Own Cloud” or “Bring Your Own Cloud,” respectively.

More than that: You are free to define the event sources entirely around your enterprise semantics, not just glue a bunch of cloud provider-defined services together with ad hoc scripting. Between Athena, Muse and Zeus, you have a variety of languages and architectures from which to choose:

Apex Athena Languages

• Object Pascal
• Visual Basic
• C# (our flavor is called C-Minor or Cm for short, and is a hybrid of C and C#)
• JavaScript (ECMA 5)

Athena is a runtime for imperative, statically typed languages that supports dialects of the following languages:

Apex Muse Languages

Muse is a runtime supporting dynamic and functional languages, including:

• Lua
• JavaScript (ECMA 6/7)
• Clojure(Script)

Apex Zeus Languages

Zeus will support all of the above languages, but targeting the WebAssembly standard. So it will enable you to code “natively” in the browser in your favorite language – no more “compiling to JavaScript” tooling nightmares!

Moreover our implementation of WASM will make your code first-class distributed computations, securely extending the user experience beyond the browser as just another “thing” in the Internet of Things (IoT). The implications of this are profound and we’ll be blogging about them soon!

In-Process vs. Out-of-process Scripting

One important implication of our new design is that these languages will support not just the traditional in-process embedded scripting model familiar to current paxCompiler, PascalScript or TMS Scripter customers, but also an out-of-process method suitable for legacy application modernization efforts. More about what this means, and how it will work on Eos and Functor, will be forthcoming shortly after our initial release in the coming days.

Motivation

This change is also motivated by our confirmation, after an extended beta trial period of Athena with previous paxCompiler customers, to deliver a different approach to existing component models by empowering our customers to consume these technologies in a more customizable way, including the decision on whether to use them In-Process or Out-of-Process and to support legacy application modernization.

This new direction also enables us to align these technologies with our broader vision for our Unify! stack, of which they are core components.

Our Commitment to Incremental Release

The good news is that you don’t have to wait for the Big Shebang – in the next week or so we will be releasing a completely free version of Athena for developers and hobbyists that will not be time-limited. Soon thereafter, versions of Muse and Eos and then Zeus will follow.

Certain features will be disabled in the free version, but easily unlocked by upgrading to commercial alternatives that we’ll be rolling out in phases. There will also be the option to purchase add-ons that will work with any edition of the engines, to extending the capabilities of even the free versions. Our revised licensing model will enable us to offer lower pricing for our customers while empowering them to only pay for what they need. We will be spelling this out more fully starting next week, with tutorials for installing, registering and using the free version of Apex Athena. The free version will provide both a way to load Athena in-process (in a more traditional use of embedded, synchronous scripting) and a standalone runtime for out-of-process scripting, with an API for communicating with it asynchronously.

About Licensing

With these changes in envisioned delivery we are also making some changes to our licensing strategy.

To put it as simply as possible:

1. Every product and technology will have a free, “Developer” edition that is released first and incubated with the developer community for a period of time before we release commercial editions. Developer editions will always be free, and extendable with low-cost and open source, third-party add-ons.
2. Every product and technology will have a Professional edition that allows developers to OEM them in their customer-facing solutions. Exact methods of embedding or including will vary case-by-case, but the idea is that the Agora portal will facilitate OEM license key management for Professional edition customers and offer alternatives like floating license vs. node-locked licensing. Of course, the Professional edition of each product will always be easy to extend with low-cost or open source add-ons as well.
3. Every product and technology will be available on a Premium subscription basis, which also includes an SDK that allows developers to customize or extend them with their code. This subscription level will also have certain partner and affiliate benefits associated with them, as appropriate depending on the kind of product or technology it is.

We will soon get the ball rolling with an initial release of Agora and Athena in coming days, and Agora will keep you up to date as new free and commercial editions come online.

The Bottom Line

The most exciting aspect of the new vision for our language run times is the idea that you can use them to transform any monolithic or legacy application into a distributed, n-tier, robust system in an incremental fashion, leveraging tools, techniques and methods that embrace the current state-of-the-art in both devops and software delivery.

So, please return over the next several days. As soon as the Agora Portal is open for business you’ll be able to register and download your free Apex Athena product and beging to explore this new direction with us, for fun and mutual profit. 🙂

Original Post Date: 03.05.2018 by Bob Calco

Mustache is a declarative template programming language designed to be simple yet sufficiently powerful to generate anything digital under the sun from well-structured data.

Its name is derived from the fact that variable values are interpolated into template text in blocks delimited by double squiggly lines (i.e., “{{” and “}}” to begin and end a block, respectively).

Well you have to admit, they do kinda look like mustaches.

What’s it good for?

Templates in Mustache are “logic-less,” meaning that the template language itself is, by design, not Turing-complete. Lack of Turing-completeness essentially means that the language does not permit complex and (more to the point) possibly erroneous business logic, such as you might be tempted or even encouraged to implement in a full-on scripting language like PHP, to be hard-coded into a template.

This ensures, among other useful properties, that the templates are not yet another place in the code base where slopping through spaghetti code can happen. You put logic where it belongs, in the logic layer of your application. You boil, mix and stir your code there, salting to taste.

In software engineering this is called “separation of concerns,” and it is generally and rightly regarded as a Good Idea in multiple disciplines, including culinary art.

In other words, during source code preparation, you keep your meatballs and sauce concerns strictly separated from your pasta concerns and your fresh herb and shredded cheese concerns, until at last everything is ready and the disparate elements are beautifully assembled during plate-up, creating a fabulous, hand-crafted customer experience. Be sure to use freshly-chopped herbs and serve it up with a nice Chianti, or perhaps a Brunello.

Such engineering craftsmanship also has the benefit of encouraging clean-up as you go—i.e., continuous “refactoring”—which is always a good idea, too.

With Turing-complete template languages like PHP, there is literally no place safe from slopping through spaghetti code, not even the otherwise declarative, pure-data confines of standard HTML tags. Indeed, PHP’s original concept and raison d’être is to help you and your HTML become one with the spaghetti. Just throw it all in a pot, cook it till you smell smoke, and slam it on the plate. Violá.

To be sure, spaghetti cooked in this manner can taste great on the plate, and maybe get served faster than professional techniques allow, but what a mess it leaves behind for you (and more likely others) to clean up later!

Most experienced software engineers agree that swift and merciless public caning is the proper punishment for such embarassing design pattern infractions as Turing-complete template engines encourage developers to commit.

So to avoid much pain applied to your posterior, you really ought to consider (among other best practices) using a logic-less template engine like Mustache whenever you need to generate code on the fly.

Note the righteous mustache on the schoolmaster in the above actual photograph of a young, brash developer who thought it would be a good idea to use a Turing-complete scripting language to generate HTML code for the school website. That might be his classmate, Alan Turing, off to the left, also in trouble for egging him on.

Tisk, Tisk.

So how do I avoid such a red-rumped fate?

Apex Perseus aims in its initial release targeting Embarcadero Delphi  and  C++ Builder  to provide a commercial-grade implementation of Mustache as part of a fledgeling set of domain-specific parsing APIs to which we refer collectively as the “Perseus Parsing System.” The goal of the Perseus Parsing System is to support generative and language-oriented  programming “in the large” in our downstream products.

Apex Perseus comes not only with a set of SDKs for regular expressions and domain-specific parsing, but also a framework for structuring service and other non-GUI applications, which we call Apex Commander.

Apex Perseus therefore also provides a handy standalone command line application that exposes the various SDKs as utilities for common programming and data transformation tasks.

This command line application, called perseus (as you might imagine), is itself built using Apex Commander and, aside from exemplifying our “drink your own champagne” philosophy (I mean really, who likes to eat dog food?), it is a good example of what you can build with Apex Commander.

(It is also available separately, if you aren’t a software developer or a Delphi/C++ Builder coder.)

OK, grow me some Mustache, already!

Unless you’re old enough, growing a mustache can take a while. For your convenience in the meantime, feel free to cut and paste the following Mustache code to your upper lip, then save it in a file called penitent.pmt.

(By convention, we assume a *.pmt file extension for “Perseus Mustache Templates” but if you buy our SDK, you can build your own processing engine and call them whatever you want.)

In order to see justice delivered swiftly by the blade of Perseus’ gorgon-slaying sword, we’re going to need a sinner with some sins. You can choose to record these in a JSON, XML or EDN file.

For now, we’ll use JSON to log the career arc of a young Alan Turing, had he grown up in today’s competitive IT market (spoiler alert!— it’s a classic tale of redemption with a modern, and decidedly less verbose, twist):

Run the perseus command line application as follows:

You should now find a file named atonement.txt with the following lines of text, as if Joseph Conrad himself had penned them:

Pretty cool, huh?

Not only is the data cleanly separated from the template code, there isn’t a hint of a for-loop or array access that you would otherwise hand-code into your run-of-the-mill Turing-complete template language, risking off-by-one and other bonehead errors quite unnecessarily.

Anything You Can Do We Can Do Meta

For maximum Joseph Conrad effect, you can even use Mustache templates to create new Mustache templates and data files on the fly in a data transformation and artifact generation pipeline!

Like a typical Conrad novel with the narrator narrating another narrator’s narration, this can get pretty meta. We’ll demonstrate the power of this strategy in subsequent posts focusing more specifically on code generation.

In our next post, we’ll introduce Apex Commander and show off some Mustache code generation in the service of building command line applications with multiple entry points using Commander’s plug-in API.

Be sure to bring your own garlic bread for that one!

Original Post Date: 08.17.2017 by Bob Calco

Lately my work as an enterprise architect has focused on the problem of data reconciliation and legacy modernization in the healthcare space. This focus began for me while working at the US Department of Veterans Affairs on web-enablement of their “legacy” VistA electronic health record (EHR).

VistA is written in a language called MUMPS that provides very fast, flexible storage capability referred to as “globals.” More precisely, VistA is based on a DBMS written in MUMPS called FileMan that also happens to shared by other EHR’s, such as the Indian Health Service’s RPMS and the DoD’s CHCS. FileMan, VistA and RPMS are in fact open source.

For years the primary user interface to VistA has been a Windows desktop program called CPRS, or, the “Computerized Patient Record System,” which was written in Delphi.

As EHRs go, it has a great reputation among clinicians and although few doctors actually “like” their EHR, CPRS had a solid reputation as one of the least-bad out there from a usability point of view.

CPRS communicates over TCP according to a protocol called the “RPC Broker” which is built into FileMan. RPC stands for, of course, Remote Procedure Call.

On the server side, RPC calls are simply MUMPS extrinsic functions that meet a certain signature and are registered as such, usually by an installation package. Much of what is considered “bad” about CPRS stems from how chatty and slow the RPC Broker approach is when you put the demands of a multi-threaded, highly modular application like CPRS on it. Anyway.

I had an opportunity while working on a medication reconciliation application at the VA to integrate with CPRS and renew my old Delphi flame building a prototype “tools menu” extension.

I was delighted to learn how much it had grown up in the intervening years since I last had a chance to work on it. Although CPRS has been “stuck” on Delphi 2007 for reasons beyond my fathoming, my “tools menu” extension was built on a much newer version (XE8 at the time IIRC), and thank God.

I was able to use LiveBindings simply and to good effect and discover a way to use the MVVM pattern for cross-platform development of VCL and FMX applications that actually worked. (MVVM was originally conceived for WPF, but didn’t provide anywhere near as seamless a reuse story between the then-disparate .NET runtimes,). I missed nothing from Java or C# as languages — anonymous methods, generics, attributes, you name it.

As a certified linguaphile and something of a polyglot, I have a deep appreciation for “old” computer programming languages, and how little is really “new” in the new languages that are continually popping up these days.

Truly, we live in a kind of Cambrian explosion of programming languages! Yet even the ancient MUMPS, which comparatively speaking makes Delphi look like a young puppy of a language, has some interesting redeeming features that I “get.” I am also a huge fan of Lisp, for that matter, which, I’ll note parenthetically (ahem), lately has been enjoying a bit of a renaissance in the form of Clojure, a wonderfully well-designed Lisp built to be hosted by runtimes like the JVM.

Anyway my point is that as much as I love the bleeding edge of programming language evolution, I am not one to poo-poo a language just because it’s been around the block a couple decades. Legacy modernization on my experience has more to do with fundamental design and architecture considerations than it does language, though people often blame languages when a particular architectural pattern or paradigm goes out of vogue, or a way to repackage tried-and-true patterns with a hip new buzzwords captures the industry’s attention for a season.

I would love to see a Delphi renaissance, specifically in the service of legacy application modernization. Embarcadero’s focus on distributed systems and the Internet of Things is timely, needed—not to mention hip—and I’m glad that beating MS on Windows is no longer Delphi’s only reason for existence.

My other major professional focus these days is data reconciliation—the problem of truth in the presence of multiple sources of truth that are out-of-sync (which is nice way of saying, one or more of them are currently untrue).

Needless to say, data-driven applications has always been a sweet spot for Delphi, and working with its native data set abstractions has always been a pleasure. Although I consider Delphi tooling still a bit too centered on SQL-based data, SQL is still totally relevant in a world looking to migrate to new, mobile-savvy computing paradigms, and will be for a long time.

I love the “true native” focus of Embarcadero’s mobile strategy as well. Cross compilers have made the job of compiling to multiple platforms much easier than the early days when the trade-off of not having to worry about that by surrendering freedom to nanny runtimes like the JVM and CLR made more sense, and app stores have largely taken away the big advantage web-based applications claimed over mere “desktop” apps—namely, easy of deployment and maintenance.

Although there are some rough edges to this strategy for Delphi component developers in the short term, if Embarcadero can build on the success of CPRS, Skype, and other popular applications that are part of the Delphi story, long term I think Delphi and RAD Studio can evolve into the premier language and programming environment for building long-running, well-loved, and highly useable distributed mobile and IoT applications.

So, that’s why I choose Delphi. The only way to make that happen is to be part of it.

Original Post Date: 02.22.2018

Welcome to the corporate blog of Apex Data Solutions, LLC!

In this blog our team will be posting about the products and technologies we’re building, the industries in which we are plying our craft, and related goings-on affecting our work and our customers’ needs.

We hope you enjoy it!