ZVS NEWSROOM

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

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.

Cheers!

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

© 2019 ZEUSVOLKOVSYSTEMS, LLC