Press Releases, Product Information, Company Announcements, Leadership Blogs, and Open Source Contributions

ZVS on 2021 Earth Science Information Partners (ESIP) Partnership Committee

By Nadia Berkheimer | Mar 1, 2021

ZVS is excited to announce that CEO Ryan Berkheimer has been selected as a voting member to represent all Type II Organizations (a category defined as “Providers of data and information products, technologies or services aimed primarily at the Earth science and research communities.”) on the ESIP partnership committee for 2021.

ESIP is a NASA, NOAA, and USGS funded partner-focused organization that endeavors to be the trusted community authority that supports the integration of science and data into mainstream use. The partnership committee is the interface for establishing new memberships and making connections within the global earth science community.

Assumption of this partnership committee responsibility represents an important organizational milestone for ZVS as it continues to evolve and publicly define itself as a thought leader in the earth science and computing space. As ZVS has developed, it has pivoted its core mission to focus on open science and facilitation of data and information flow through open consulting. This new role will solidify the ZVS core mission.

We at ZVS are excited to help bring new contributing members to ESIP that represent the best of the earth science community – especially helping to bring on board currently underserved and underrepresented communities, like state and local governments and small research labs that have large and diverse data holdings that would greatly benefit from integration with existing channels that are provided in ESIP.

Hub – Constellated kappa-style WMS

By Nadia Berkheimer | Feb 10, 2021

Zeus Volkov Systems is excited to announce that we’ve open sourced the clojure engine of a constellated kappa-style WMS we are currently prototyping called ‘hub’.

Hub provides a distributed constellation of extremely small and fast poly-tech processing units that spin up quickly on an orchestrator, perform directed asynchronous processing, compose their own immutable log of actions, and die with a final emission of their log to a distributed messaging system to be consumed by a queue like Kafka as an order-able log of logs that can do something else with that information (return to sender or emit new instructions for further processing).

Hub is a kubernetes-native, distributed-native technology. It is in the exciting active development stage of invention and is not ready for production release. We are releasing it now that the first core and principal design is complete to look for contributors. If this sounds interesting, please contact us through contact@zeusvolkovsystems.com.

Hub on github

If helping to develop hub, please report and track issues through github. We are trying to use hub as an opportunity to identify collaborative opportunities; all contributions are welcome.

Ephemeral – A Software Engineering Focused WMS

By Nadia Berkheimer | Dec 10, 2020

ZVS is pleased to announce the open sourcing of the ephemeral WMS. Ephemeral is a job-task workflow management system designed to manage systems at the data level.

Ephemeral is unique in the WMS data space in that it focuses primarily on software engineering. While it does provide automatic asynchronous execution on both task and data lists, the primary goal of ephemeral is to enforce strong functional system design patterns through strict package structuring requirements. Business logic is clearly and cleanly separated from workflow logic and task routing, and jobs are specified as JSON maps.

Ephemeral is a good tool for refactoring existing projects or using to build bigger or more complex systems that use other libraries, distributed tools, or other constructs. We hope you enjoy it.

We are looking for help to complete addition of a job builder and command line interface (CLI) construct that can, like the Angular CLI, quickly spin up and sketch out systems. If you’re interested in helping with this, please let us know or submit a github pull request.

Without further ado, here is the project: https://www.github.com/zeus-volkov-systems/ephemeral

Decstreams – Decorator Streams for Asynchronous, Multicast, and Functionally Decoupled Event Driven Architectures on the Front End

By Nadia Berkheimer | Nov 11, 2020

ZVS is open sourcing our client-popular library decstreams. We have been using decstreams in ours and clients JS based systems, including react, angular, and vue based apps, to bring decorator multicast streaming patterns to front end development, similar to backend patterns like kafka or sanicio, while simultaneously simplifying architectures using the experimental Javascript decorator patterns.

Decstreams is backed by RxJs Subjects and implemented as request and event publish/consumer pairs. Requests or Events can be published by one function and then consumed by others; multi-cast events allow many event consumers to consume the same event publisher, and requests can publish to many consumers for responses, passing optional arbitrary arguments along with them.

A very common use case for decstreams is to do multicast event publishing after SPWA interaction (say, map movement, graph alteration, button pushing) – triggering other edge behaviors, sending data to a back end, updating local in-memory data, etc., simultaneously, while avoiding adding business logic or direct function calls to either. Similarly, when interaction requires a response, requests can multicast to multiple request consumers, passing any relevant information along, wait for all data to be returned, and then act on the new information.

Decstreams is most readily available in the node package manager – npm install decstreams – and copy/paste README examples are available in on the ZVS github page – https://github.com/zeus-volkov-systems/decstreams.

We hope you enjoy decstreams and it works as well for you as it has for us in our client’s systems – it really is a joy to begin to decouple systems at this level of abstraction.


Ryan, Max, and Nadia

Reengineering Tips for Choosing the Correct Programming Language

By Ryan Berkheimer | Feb 16, 2020

Ryan Berkheimer, CEO, ZVS

At ZVS, we regularly do reengineering/refactoring work on large polyglot software systems, with Shell (Bash), Java, Fortran, Go, and Python being some of our most commonly encountered languages. When folks come to us for a reengineering effort, before the first code review, we can generally predict a lot of the patterns we will encounter.

As part of our service, we advise our clients on patterns of behavior that they should implement in new projects to avoid getting to a place where they need to do repair work. Here are 5 of our favorite rules of thumb when tackling a new project:

  1. Don’t mix languages upward. Are you making system calls from python, fortran, or java? You’re going to run into problems with this if you ever try to port your software (even docker will fail you here eventually due to bit rot). Bash (or csh, zsh, ksh, etc.) is your glue language, use it as such. This will also provide better mutability on the system level, in the case that other languages become involved (it’s a lot easier to glue together a fortran/java/c/python polyglot system using bash than doing it from python).
  2. Are you using repeatable functionality? Probably time to move out of shell into a more advanced language. Bash name-spacing is much less developed, consistent, and stereotyped than programming languages like python or java.
  3. Are you starting to use awk and sed a lot in bash? Is this program long lived? Move it into another language, where you can define functions that people later on will understand more easily. System level tools are fine for one-off processes, but they are so flexible that they often become liabilities in larger and long-lived systems.
  4. Are you doing systems type work? Generally it’s fine to keep this in shell. Shell is a systems language, so is safe and even preferred to be used as such. Although again, you might have better choices here. What if you eventually move from a directory or ftp ls to object storage? If you have your code in python, you’ll already be able to swap out functions, because you’ve already reasoned the program in that way. Bash will take longer to refactor because you did it in a one-off way.
  5. If you’re starting out doing something and you don’t know if it’s going to be one-off or not, don’t worry about the language you’re doing it in so much. Do it in whatever’s easiest. BUT – once you’re done, do a second pass while it’s fresh. Make sure you’d be comfortable maintaining the code in the case that it becomes a long-term thing (it happens more often than not).

We hope these tips are useful for your own work. If you’d like to discuss how this would apply in your own systems, please feel free to contact us!

Website Launch

By Ryan Berkheimer | Jul 9, 2019

Zeus Volkov Systems, LLC, announces its website launch on July 12th, 2019. The new website represents a new page in the ZVS story.

Read More