Press Releases, Product Information, Company Announcements, Leadership Blogs, and Open Source Contributions
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 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
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:
- 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).
- 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.
- 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.
- 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.
- 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!
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
On July 12, 2019, Zeus Volkov Systems, a high tech products, consulting, and design company, met a major milestone with the inaugural publication of its website.
The ZVS website is designed to be a place for new and existing clients to gain an understanding of all that Zeus Volkov Systems can offer – in the domains of Consumer Products, Consulting, and Content Design and Management.
The ZVS leadership team is excited for this launch and all the future holds.
© 2019 ZEUSVOLKOVSYSTEMS, LLC