Have you noticed that when you go to the doctor, often no one there can tell you what it will cost? If you think that’s as problematic as we do, join us in our mission to fix it

MD Clarity

mdclarity

Experienced professionals whose eyes glaze over with expertise may justifiably be dissatisfied, believing that containerization has been discussed many times before. They even would say, "Read the documentation." And in a sense, they would be right. However, new specialists don't know about the times when Ubuntu disks were given away for free and have no experience in compiling operating systems from scratch. So, this statement becomes utopian. Every new technology starts with enthusiasts who fully immerse themselves in its intricacies. For example, early amateur radio operators knew almost everything about radio communications. They could build a receiver with their own hands and catch signals on a homemade antenna. Early GNU/Linux users knew the operating system's inner workings. Many even knew how to patch and recompile modem drivers to set up a network connection. The current generation of users is generally not engaged with such basics, as they are starting to engage with the technology at a lower entry threshold. These processes are happening not only among end users but also among engineers. On the one hand, deep specialization is normal. On the other hand, specialists risk turning into priests who know the magic rituals but cannot fix something at a low level when it breaks. This phenomenon is also seen in the context of containerization. Recently, more DevOps engineers know how to use Docker and Podman. They can create a Dockerfile. However, they feel insecure when asked about namespaces in Linux or confused by a question about how containerization differs from deployment via RPM packages. My name is Tanya, and I am the Senior DevOps Engineer at Plerdy. Today, I would like to discuss the containerization topic from a slightly different angle and shed light on the following aspects: Basic principles on which modern containerization is based The differences between containerization and virtualization What Linux namespaces is Get your cup of coffee ready, and let's get started on this fascinating journey into the world of containerization. Abstraction Levels in Containerization Let’s start with the basics. Hardware-Level The backbone of modern infrastructure is hardware. It is often said that "there is nothing but an interface to the hardware in someone else's data center." But hardware can range from Chinese components with their peculiarities to branded servers from HP or even homemade clusters assembled on Raspberry Pi with individual controllers. Ideally, developers want their code to run everywhere with minimal changes and without worrying about what hardware is being used - SSD, HDD, or even a refurbished floppy disk just for fun. They also don't want to worry about accessing files, RAM areas, and other low-level details. Kernel Level The operating system is used to achieve this abstraction between hardware and software. It provides the necessary system calls that allow interaction with hardware resources. These system calls are often low-level, reliable, and simple. For example, "read 10 bytes, open file, read 10 bytes." In theory, you can develop applications using almost only system calls. Let's say you need to create a Windows application without using high-level libraries. You can directly write the window image to the video card buffer, display it on the screen, and respond to keystrokes. Then, through system calls, you can track mouse coordinates and locate screen clicks to properly handle events like "user pressed button_1". This is possible but not usually used for graphical applications. In this case, reusing existing code is limited and requires highly skilled developers. I mean up to and including writing direct machine code for the processor. Library Level A more common and convenient approach is to use off-the-shelf libraries that wrap system calls in higher-level abstractions and provide convenient interfaces to the computer mouse, network resources, and sound devices. One example is PulseAudio, which facilitates access to audio files and devices. User-Space Level The next level of abstraction is user space. A program running at this level has no direct knowledge of the hardware, operating system, or other low-level details. It is usually just a set of high-level instructions that rely on dependencies in the form of libraries from the previous level. The operating system creates a separate isolated process for our program. It allows the application to not worry about available resources and other technical details. The program runs inside this process under the notion that it is executed in an isolated environment where it owns all the resources. In reality, the operating system manages resources and ensures that RAM is allocated, monitors CPU time allocation, and manages task execution priorities. It can "suspend" one application to perform calculations for another, all according to quotas and priorities. This greatly facilitates development and ensures reliable system operation. How, ultimately, can a program without direct knowledge of the operating system and low-level details interact with all these components and infrastructure? This is accomplished by using dynamically pluggable libraries. These libraries are a set of standard instructions that are set aside in a separate abstraction to simplify interaction and provide programming convenience. Let's look at working in the console and understand how it functions. First, we must put the file command on the ls binary and ensure it was dynamically linked to the libraries. It will not work without them because it relies on their presence in the OS. Next, using ldd, we must determine which libraries the program uses when working. It is important that we connect not just any libraries but quite specific versions of them. In some minor releases, they may fix bugs, optimize something, and fix vulnerabilities. But major changes may add new features and break old ones. In the case of popular libraries, developers try to support all old API calls for as long as possible. Still, they must be removed if they interfere with implementing new architectural solutions. Usually, they warn about this in advance with long and persistent messages that this particular call is deprecated. As usual, often nobody does anything until the last moment if the business doesn't want to pay for it right now. No One Likes Maintenance Maintaining software is hard. Businesses are extremely reluctant to part with money to solve problems that haven't come yet. In addition, there are difficulties in the interaction between the developer and the end user who will run the application. For example, a developer sits on ancient Ubuntu and still can't update. Or, in the olden days, he dragged a library into the application's base somewhere, which was buried under several layers of code and abstractions. So, he takes an artifact of his application or source code and gives it to DevOps. The engineer rolls that application out into the environment, and everything crashes. It cusses that it can't feel legs, it can't feel arms, that library over there was not brought in, and this one is of an unknown version. The calls are wrong. DevOps engineer returns to the developer and says, “It doesn't work. You need to figure out how to run it”. But he may get a response like, "I don't know anything, I have the same leg, and it doesn't hurt; everything works; I checked". And that's where the dilemma comes in - what's the best way to reproduce the environment that the application needs to fully work? Let's assume I will take a bunch of libraries and somehow run them in a test environment. But how do I give the binary to the customer? Should I write a huge instruction on how to set up the environment with the necessary libraries, drag everything in a huge archive, and install it with a set of scripts? Or find a simpler solution? Distributions Maintenance Supporting different operating system distributions is an important task with pros and cons, depending on your situation and company resources. Here are a few important aspects. Pros of supporting multiple distributions: Accessibility to a wider audience. Supporting different distributions makes your application accessible to more users, as different organizations and individuals may prefer different distributions. End-user friendly. Users can install the application with minimal effort using package management tools such as or . yum apt-get Compatibility. Supporting different distributions helps to ensure compatibility with different operating system versions and libraries. Cons of supporting multiple distributions: Complexity and cost. Supporting multiple distributions requires additional effort and resources to test and ensure compatibility. It can be expensive and time-consuming. Development constraints. The need to support older versions of libraries and environments can limit the ability to introduce new features and optimize code. Dependency on distribution maintainers. You may need to work with distribution maintainers to ensure your application is properly integrated and supported. This may require additional effort. Some companies choose to support only a few popular distributions to simplify the development process and reduce costs. In contrast, others strive to provide broad availability and user-friendliness, even at additional cost. Containerization or Virtualization Most companies don't have the resources to support many distributions. You can limit yourself to a small number of distributions. But problems will start when the distribution becomes oldstable, and a small team will have to update all dependencies when upgrading to a new OS version. In this case, the traditional solution is to pack everything into a docker image and send it to the customer. What exactly he will run it on is not so important. Thanks to the abstraction layer, our image will contain everything we need in a portable form. If the DevOps is good, the image will be minimalistic and contain only the essentials. Suddenly, it turns out that the application needs to work with hardware tokens, hard disk controllers, and cash registers. We need full-fledged drivers and can't stuff our kernel into a container. And the OS won't let us do it. In this case, only full virtualization will help, where the host-OS hypervisor will allow us to run any kernel with the drivers we need. This is often a better solution. But now, we will consider a situation when we don't need overhead in the form of many running kernels of a full-fledged OS to run small applications. In the case of a container, we send system calls to the kernel on which all containers are running. Then, we drag the libraries together with the binary inside the docker image. This allows us to tell the process: "Don't go there for libraries, but here. They are in the container." The process knows nothing about the file system or the computer as a whole. The process gets everything from the kernel. When we say, "Give us a list of files in the directory", we send a request to the kernel. The kernel responds to this system call with a list of directory files. We send a request to the kernel, "Please give us a list of network interfaces." The kernel responds with a list of network interfaces. "Kernel, please open a TCP connection for us." The kernel returns a pointer to this connection. That is, the process is basically helpless without the kernel, even though it has brought with it all the libraries necessary for the application. Namespace The Linux kernel natively supports . This mechanism does not require any additional packages to be installed. They are provided right at the kernel level. It allows us to respond to each application's system calls differently. namespaces As this mechanism has evolved, new features have been added to virtualize certain functions. Namespace Kernel version Year Mount 2.4.19 2002 UTS 2.6.19 2006 PID 2.6.24 2008 Network 2.6.29 2009 IPC 2.6.30 2009 User 3.8 2013 Time 5.6 2020 With the advent of this technology, it is now possible, for example, to give different sets of available networks when querying the kernel from applications that run in different namespaces. The table above shows all currently available namespaces. The time namespace is a relatively recent addition, which allows different processes to see different system time or time zones. Let's look at some of them a little closer. Network namespaces provide a means of isolating network resources. They allow processes running in different namespaces to have their own network devices, routing tables, and firewall rules. If an application runs in a separate net namespace, we provide complete isolation of the network from the rest of the system, allowing communication only through dedicated interfaces. On the other hand, mount namespaces provide the application with its own representation of the file system. We can create a specific structure in a container and tell the process, "This is the root of the file system. Use this as the base." In this way, we give the application access only to specific files and directories, thus providing file system isolation within the container. The PID namespace creates isolated namespaces for processes, the User namespace allows us to have our own unique copy of user and group identifiers, and the IPC namespace provides control over inter-process communication. There is also the UTS namespace, which allows us to set our own hostname for each isolated environment. These types of namespaces provide complete isolation and control over resources and processes within the container. Conclusion The current major trend today is to strive for maximum modularity. This approach makes it possible to build customized environments from a set of libraries and ensure they work almost everywhere. This greatly accelerates the introduction of new solutions to the market, provides portability and fault tolerance, and simplifies load balancing. It also will bring other benefits associated with the transition from the "Pets" model (unique, hand-customized services and servers) to the "Cattle" model (homogeneous entities raised and destroyed by the hundreds). However, it is important to remember that Docker is a convenient shell over the standard kernel mechanisms. These mechanisms are used not only in the context of Docker but also in conjunction with many other technologies.

Containerization In 2023: Strive for Maximum Modularity via the Cattle Model

Aspect-Oriented Programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. In simple terms, it helps you keep your code clean, modular, and easy to maintain. We can leverage AOP to debug Spring Boot applications more effectively and seamlessly. In this post, we will explore how to use AOP to debug a Spring Boot application effectively. https://youtu.be/6kxpkcEqssw?embedable=true AOP Concepts Before diving into debugging with AOP, it is essential to understand the core concepts. AOP lets us write code that executes before or after a method. It includes the following common terms: An aspect represents the cross-cutting concerns or the functionality that needs to be applied throughout the application. Aspect: A join point is a specific point in the execution flow of the application, where an aspect can be applied. Join Point: The action taken by an aspect at a specific join point is called advice. There are different types of advice, such as before, after, around, and after throwing. Advice: A pointcut is a set of join points where an aspect should be applied. Pointcut: I will skip the discussion on weaving since there’s a lot of nuance related to that and I want to focus on the debugging aspects. I don't want to make this into an AOP tutorial. However, there’s one general aspect of AOP I want to discuss. While AOP offers significant benefits in terms of modularity, maintainability, and debugging capabilities, it's important to be aware of the potential performance implications. Using AOP can introduce some overhead, primarily due to the creation and execution of proxy objects, which intercept method calls and apply the specified advices. The impact on performance can vary depending on the number of aspects, the complexity of pointcut expressions, and the type of advice used. For example, around advice is typically more expensive in terms of performance compared to before and after advice. To minimize the performance impact of AOP, consider the following best practices: Apply AOP to the critical parts of your application where it provides the most value. Avoid using aspects for trivial or infrequent operations. Be selective: Ensure that your pointcut expressions are as precise as possible. This can help minimize the number of unnecessary interceptions and reduce the overhead. Optimize pointcut expressions: Choose the appropriate type of advice for your use case. For example, use before or after advice instead of around advice when possible. Limit advice execution: If some aspects are only required for debugging or development purposes, use conditional aspects that can be enabled or disabled based on a configuration property. This ensures that the performance impact is limited to specific environments or scenarios. Use conditional aspects: Regularly monitor and measure the performance of your application to ensure that the overhead introduced by AOP is within acceptable limits. Use profiling tools to identify potential bottlenecks and optimize your AOP implementation accordingly. Monitor and measure: Logging Aspect Let's create a simple aspect to log the execution time of methods in our Spring Boot application. This can help identify performance bottlenecks. We can create a new class called 'LoggingAspect' and annotate it with and to indicate that it's an aspect and a Spring-managed bean. We implement a pointcut expression to target the methods you want to measure. For example, you can target all public methods in a specific package. We then implement an around advice to measure the execution time and log the results. @Aspect @Component Here's an example of a : LoggingAspect @Aspect
@Component
public class LoggingAspect {
  private static final Logger logger = LoggerFactory.getLogger(LoggingAspect.class);

  @Pointcut("execution(public * com.example.myapp..*.*(..))")
  public void publicMethods() {}

  @Around("publicMethods()")
  public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    long startTime = System.currentTimeMillis();

    Object result = joinPoint.proceed();

    long elapsedTime = System.currentTimeMillis() - startTime;
    logger.debug("Method [{}] executed in {} ms", joinPoint.getSignature(), elapsedTime);
    return result;
  }
} Pointcut methods are empty because their sole purpose is to define a pointcut expression, which determines the join points (i.e., specific points in the execution of a program) where the aspect should be applied. The method body itself does not contain any logic, as the behavior of the aspect is defined in the advice methods (e.g., , , , etc.). @Before @After @Around The pointcut method serves as a reusable reference to a specific pointcut expression, making it easier to maintain and update if needed. By referring to a pointcut method in your advice methods, you can apply the same pointcut expression to multiple pieces of advice without duplicating the expression. We will see that in action below. After implementing the , we can run our application and observe the logs. We should now see the execution time for each targeted method as a poor man's profiler. Just like a regular profiler, this tool has many disadvantages and impacts the observed application. However, we can extract valuable data if we tune this correctly. LoggingAspect Logging All Methods One of the common problems we face in big projects is flaky tests and failures. These are especially hard to understand as we might not have enough logging data. Adding logs to the entire application is impractical in most cases and we’d only want such logs for specific CI executions. We wouldn’t want to over-log in production or even maintain such logging code. However, knowing the parameters that every method received and its return value can lead us to understand a failure after the fact. The following code shows such a logger that can print out every entry/exit and the arguments or return values: @Aspect
@Component
public class LoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(LoggingAspect.class);

    @Pointcut("execution(public * com.example.myapp..*.*(..))")
    public void publicMethods() {}

    @Around("publicMethods()")
    public Object logMethodEntryAndExit(ProceedingJoinPoint joinPoint) throws Throwable {
        // Log method entry and arguments
        Object[] args = joinPoint.getArgs();

        logger.debug("Entering method [{}] with arguments: {}", joinPoint.getSignature(), Arrays.toString(args));

        // Execute the target method and capture the return value
        Object result = joinPoint.proceed();

        // Log method exit and return value
        logger.debug("Exiting method [{}] with result: {}", joinPoint.getSignature(), result);

        // Return the result
        return result;
    }
} The Tip of the Iceberg Logging to keep track of performance or method entry/exit is powerful but basic. We can go much deeper than that. We can create an aspect to log incoming HTTP requests and responses. This aspect intercepts the methods with the annotation, which is typically used for handling HTTP requests in Spring Boot applications: @RequestMapping @Aspect
@Component
public class RequestResponseLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(RequestResponseLoggingAspect.class);

    @Pointcut("@annotation(org.springframework.web.bind.annotation.RequestMapping)")
    public void requestMappingMethods() {}

    @Around("requestMappingMethods()")
    public Object logRequestAndResponse(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        logger.debug("Request: {} {} - Parameters: {}", request.getMethod(), request.getRequestURI(), request.getParameterMap());
        Object result = joinPoint.proceed();
        if (result instanceof ResponseEntity) {
            ResponseEntity<?> responseEntity = (ResponseEntity<?>) result;
            logger.debug("Response: Status {} - Body: {}", responseEntity.getStatusCode(), responseEntity.getBody());
        }
        return result;
    }
} Another important aspect is bean creation and destruction. We can create an aspect to log these events. This aspect intercepts the methods annotated with and which doesn’t apply to all beans but would help us keep track of the applicable code in a large application: @PostConstruct @PreDestroy @Aspect
@Component
public class BeanLifecycleLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(BeanLifecycleLoggingAspect.class);

    @Pointcut("@annotation(javax.annotation.PostConstruct)")
    public void postConstructMethods() {}

    @Pointcut("@annotation(javax.annotation.PreDestroy)")
    public void preDestroyMethods() {}

    @After("postConstructMethods()")
    public void logBeanInitialization(JoinPoint joinPoint) {
        logger.debug("Bean Initialized: {}", joinPoint.getTarget().getClass().getSimpleName());
    }

    @Before("preDestroyMethods()")
    public void logBeanDestruction(JoinPoint joinPoint) {
        logger.debug("Bean Destroyed: {}", joinPoint.getTarget().getClass().getSimpleName());
    }
} We can even log dependency injection events. This aspect intercepts the methods with the annotation. It doesn’t track constructor injection though but we can use it to track the instance type that gets injected into a bean: @Autowired @Aspect
@Component
public class DependencyInjectionLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(DependencyInjectionLoggingAspect.class);
   @Pointcut("@annotation(org.springframework.beans.factory.annotation.Autowired)")
    public void autowiredMethods() {}

    @Before("autowiredMethods()")
    public void logDependencyInjection(JoinPoint joinPoint) {
        logger.debug("Autowired: {} - Target: {}", joinPoint.getSignature(), joinPoint.getTarget().getClass().getSimpleName());
    }
} Final Word AOP is a fantastic debugging tool. In this post, I skimmed a lot of big ideas and overused logging. When tracking performance a better approach would be to accumulate values and then log the statistics in the end, thus removing the overhead of the logger (which impacts the results). The one thing I recommend is turning this off by default. It’s important to run a CI cycle without AOP, the cost is too big and we can seriously impact the final result. We need to turn this on surgically when we need to understand something deep. In those situations, AOP tooling can make the difference when searching for that needle in the haystack. Also published . here

Spring Boot Debugging with Aspect-Oriented Programming (AOP) to Increase Modularity

One of the main reasons to design microservices is that they enforce . However, the cons of microservices are so huge that it’s like chopping off your right hand to learn to write with the left one; there are more manageable (and less painful!) ways to achieve the same result. strong module boundaries Even since the microservices craze started, some cooler heads have prevailed. In particular, , a developer on the Spring framework, has been a long-time proponent of the alternative. The idea is to keep a monolith but design it around modules. Oliver Drotbohm moduliths Many flocks to microservices because the application they work on resembles a spaghetti platter. If their application were better designed, the pull of microservices wouldn’t be so strong. Why modularity? Modularity is a way to reduce the impact of change on a codebase. It’s very similar to how one designs (big) ships. When water continuously leaks into a ship, the latter generally sinks because of the decreasing Archimedes thrust. To avoid a single leak sinking the ship, it’s designed around multiple watertight . If one leak happens, it’s contained in a single compartment. While it’s not ideal, it prevents the ship from sinking, allowing it to reroute to the nearest port where one can repair it. compartments Modularity works similarly: it puts boundaries around parts of the code. This way, the effect of a change is limited to the part and doesn’t spread beyond its boundaries. In Java, such parts are known as packages. The parallel with ships stops there because packages must work together to achieve the desired results. Packages cannot be “watertight”. The Java language provides visibility modifiers to work across package boundaries. Interestingly, the most famous one, , allows crossing packages entirely. public Designing boundaries that follow the principle of least privilege is a constant effort. Chances are that under the project’s pressure in the initial development or with time during maintenance, the effort will slip, and boundaries will decay. We need a more advanced way to enforce boundaries. Modules, modules everywhere In the long history of Java, “modules” have been a solution to enforce boundaries. The thing is, there are many definitions of what a module is, even today. , started in 2000, aimed to provide versioned components that could be safely deployed and undeployed at runtime. It kept the JAR deployment unit but added metadata in its manifest. OSGi was powerful, but developing an OSGi (the name for a module) was complex. Developers paid a higher development cost while the operation team enjoyed the deployment benefits. DevOps had yet to be born; it didn’t make OSGi as popular as it could have been. OSGI bundle In parallel, Java’s architects searched for their path to modularizing the JDK. The approach is much simpler compared to OSGI, as it avoids deployment and versioning concerns. Java modules, introduced in Java 9, limit themselves to the following data: a name, a public API, and dependencies to other modules. Java modules worked well for the JDK but much less for applications because of a chicken-and-egg problem. To be helpful to applications, developers must modularize libraries — not relying on auto-modules. But library developers would do it only if enough application developers would use it. , only half of 20 commons libraries were modularized. Last time I checked On the build side, I need to cite Maven modules. They allow splitting one’s code into multiple projects. There are other module systems on the JVM, but these three are the most well-known. A tentative approach to enforce boundaries As mentioned above, microservices provide the ultimate boundary during development and deployment. They are overkill in most cases. On the other side, there’s no denying that projects rot over time. Even the most beautifully crafted one, which values modularity, is bound to become a mess without constant care. We need rules to enforce boundaries, and they need to be treated like tests: when tests fail, one must fix them. Likewise, when one breaks a rule, one must fix it. is a tool to create and enforce rules. One configures the rules and verifies them as tests. Unfortunately, the configuration is time-consuming and must constantly be maintained to provide value. Here’s a snippet for a following the Hexagonal architecture principle: ArchUnit sample application HexagonalArchitecture.boundedContext("io.reflectoring.buckpal.account")
                     .withDomainLayer("domain")
                     .withAdaptersLayer("adapter")
                     .incoming("in.web")
                     .outgoing("out.persistence")
                     .and()
                         .withApplicationLayer("application")
                         .services("service")
                         .incomingPorts("port.in")
                         .outgoingPorts("port.out")
                     .and()
                         .withConfiguration("configuration")
                         .check(new ClassFileImporter()
                         .importPackages("io.reflectoring.buckpal..")); Note that the class is a custom-made DSL façade over the ArchUnit API. HexagonalArchitecture Overall, ArchUnit is better than nothing, but only marginally so. Its main benefit is automation via tests. It would significantly improve if the architectural rules could be automatically inferred. That’s the idea behind the Spring Modulith project. Spring Modulith Spring Modulith is the successor of Oliver Drotbohm’s (with a trailing S). It uses both ArchUnit and . At the time of this writing, it’s . Moduliths project jMolecules experimental Spring Modulith allows: Documenting the relationships between the packages of a project Restricting certain relationships Testing the restrictions during in tests It requires that one’s application uses the Spring Framework: it leverages the latter’s understanding of the former, obtained through DI assembly. By default, a Modulith module is a package located at the same level as the -annotated class. SpringBootApplication |_ ch.frankel.blog
    |_ DummyApplication       // 1
        |_ packagex           // 2
        |  |_ subpackagex     // 3
        |_ packagey           // 2
        |_ packagez           // 2
          |_ subpackagez      // 3 Application class Modulith module Not a module By default, a module can access the content of any other module but cannot access Spring Modulith offers to generate text-based diagrams based on PlantUML, with UML or (default) skins. The generation is easy as pie: C4 var modules = ApplicationModules.of(DummyApplication.class);
new Documenter(modules).writeModulesAsPlantUml(); To break the build if a module accesses a regular package, call the method in a test. verify() var modules = ApplicationModules.of(DummyApplication.class).verify(); A sample to play with I’ve created a to play with: it emulates the home page of an online shop. The home page is generated server-side with Thymeleaf and displays catalog items and a newsfeed. The latter is also accessible via an HTTP API for client-side calls (that I was too lazy to code). Items are displayed with a price, thus requiring a pricing service. sample app Each feature — page, catalog, newsfeed, and pricing — sits in a package, which is viewed as a Spring module. Spring Modulith’s documenting feature generates the following: Let’s check the design of the pricing feature: The current design has two issues: The is accessible outside of the module PricingRepository The leaks the JPA entity PricingService Pricing We shall fix the design by encapsulating types that shouldn’t be exposed. We move the and types into an subfolder of the module: Pricing PricingRepository internal pricing If we call the method, it throws and breaks the build because is not accessible from outside the module: verify() Pricing pricing Module 'home' depends on non-exposed type ch.frankel.blog.pricing.internal.Pricing within module 'pricing'! Let’s fix the violations with the following changes: Conclusion By toying with a sample application, I did like Spring Modulith. I can see two prominent use cases: documenting an existing application and keeping the design “clean”. The latter avoids the “rot” effect of applications over time. This way, we can keep the design as intended and avoid the spaghetti effect. The icing on the cake: it’s great when we need to chop one or more features to their deployment unit. It will be a very straightforward move, with no time wasted to untangle dependencies. Spring Modulith provides a huge benefit: . delay every impactful architectural decision until the last possible moment Thanks, for his review. Oliver Drotbohm You can find the source code on . GitHub Originally published at on November 13th, 2022 A Java Geek

Have We Reached the Age of Modularity Maturity?

Modularity is central to modern software engineering - or may be all type of engineering not just software. We’ll explore support for modularity in Java and .Net platforms, but before that let’s first try to find answers for what and why of modularity. What is a Module? Dictionary say a module is “one of a set of separate parts that, when combined, form a complete whole” So a module needs to have two main characteristics: Provide one or more related set of services via a standard interface — having standard interface would make a module reusable and replaceable Hide implementation details from the consumers of the services What is Modular thinking? Modular thinking would involve the following: 1. Break down the problem in small parts i.e. modules. Each part would satisfy the following: Each module is focused on one or more related services \ functions Services are exposed using a standard interface Each module can potentially be used in any place where the same services are required 2. Create the final solution by composing different modules together Almost everything around us is an example of modular thinking e.g. Automobiles, Personal Computer, Electronic Devices, etc. Most of today’s software solutions are built using tools and platforms that are built in modular approach e.g., Spring Framework and .Net Framework, two very popular frameworks in Java and .Net, are both modular in nature. Both have number of modules (libraries) and those modules can be used (or reused!) in solutions for different problems. But why Modularity? What do we gain from modular approach to the solution? I think the following three are the primary benefits: Same module can be used elsewhere, saving time and effort Reuse : A change in the system is reduced to small area (implementation is hidden from consumers) and that allows more complete testing in shorter time. Stability: Multiple modules can be developed by different teams in parallel and final solution built by composing those modules. Saving time to market. Parallel Execution: Logical & Physical Modules In software applications, logical grouping of functions and services is done to create a modular design. This would be an outcome of the application of Software Architecture principles on the problem domain e.g., the following modules may be identified for a Ticket Booking application, each focused on a specific area of the solution. However, that’s still a design of the software application. Working software (application binaries) can be in one of the two forms shown below: an executable file containing all the modules. Here, the modules may internally be organized separately in the source tree of the application, but physically they all are in one executable file produced by building the application. a. each module is a library and the application is using the libraries. Libraries are built and released separately from the main Application. b. Option (b) is the modular approach that we all are familiar with and use everyday. Option (b) gives all the benefits of modularity listed above. It is said that Unit of Release is the Unit of Reuse. There is no scope for reuse in Option (a). Required Platform Capabilities To support the modularity of option (b), a platform used to build the software application needs to have at least the following capabilities: Encapsulation at module level. This is to ensure consumer uses only standard public interface and the details are hidden. Consumers cannot build dependency on “details” so that details can change without breaking anything e.g., in a logging library, is public interface and is the class implementing logging to file. Users of logging library should not have access to so that can change without breaking any dependent application. Encapsulation: com.mylogger.api.Logger com.mylogger.service.impl.FileLogger FileLogger FileLogger Since each module would also depend on some other module, there needs to be a way for each module to declare its dependencies. Dependency Management: Once a module has declared its dependencies, the platform needs to discover those dependencies (modules i.e. libraries) at runtime, load them and make them available. Dependency Discovery: Versioning of modules is required to let each module evolve independently without breaking other modules depending on it. Versioning: Let’s compare Java and .Net on these parameters: * The package structure at runtime is used to locate .class files. JVM would look for exact same directory structure as the package name e.g. all types under “com.covidservice.api.service” should be found under “com/covidservice/api/service” on the Classpath JARs. So a package is not really treated as a dependency by JVM. JVM searches for .Class file when it has to create a new Class or Instance — this is different from how dependencies are managed in Java 9 and .Net. ** Java does not support versioning at JVM layer. The versions of JARs are maintained using naming convention i.e. including version in JAR filenames like spring-web-1.0.0-RELEASE.jar. If you have wrong version on Classpath or Modulepath, JVM would use that as long as the .Class file (Java 8) or Module (Java 9) are found. is an industry alliance for . OSGi was formed in late 1990s. There are many implementations of OSGi specifications like Apache Felix, Eclipise Equinox, etc.OSGi component system is used to build Eclipse IDE, JBoss, WebLogic, etc. Before module system was introduced in Java, OSGi came up with a dynamic module system. OSGi “a vendor-independent, standards-based approach to modularizing Java software applications and infrastructure” Summary Modular architecture is a necessity once complexity and scope grows beyond certain point. It is difficult to introduce modularity at a later stage so better to do it from the beginning. Modular design can be created by applying principles of Software Architecture, but platforms used to build the software need to support modular architecture. Java 9 and .Net are more capable than Java 8 — for reasons explained above — to enforce modularity. Previously published at https://dev.to/pathiknd/modularity-in-java-and-net-3dnj

Modularity Concept in Java and .Net

Modularity refers to a system’s ability to be broken down into components which can be separated and recombined. The best software development tools are often highly modular, and allow the reuse of “assemblies” or “modules”. This principle is at the core of development frameworks like Java, C# and Go. Modularity promotes innovation because new ideas become trivial to implement. When creating a new web app, the majority of the code running is really inside of externally-developed packages; whether they be database connections, page rendering engines, input validators etc. As such, it’s extremely easy for developers to spin up a prototype of a new website idea. Enter: Crypto However, if you were to go and look at the most prized crypto codebase of all, the repository, you’d notice that it’s extremely inflexible. Unmodular code is generally characterised by long files and classes, and individual implementations of classes often depend on other concrete implementations. For an example see Core’s . This isn’t just the case with Bitcoin Core. Most of the biggest node repositories — another example is - are absolutely not built with flexibility in mind. Bitcoin Core Bitcoin validation.cpp blockchain Go Ethereum Now it’s important to note that in the case of Bitcoin, modularity isn’t a priority. If you believe you’re building the “currency” of the future, why make it easier for others to build with your code? Bitcoin Core is highly integrated, but it has stood the test of time and it . This is not a criticism of Bitcoin Core’s codebase. singular works Experimenting with Blockchains With blockchain being cited as the answer to everything, many projects are starting to experiment with different node implementations. Especially in the case of sensitive data and private chains, or cases where external data is core to a chain’s operation, projects are finding that a smart contract based approach does not allow them enough flexibility. Unfortunately until recently this has meant that in order to innovate, developers are pulling apart integrated nodes like Bitcoin’s, or starting new nodes from scratch. Both of these avenues are painful, time-consuming, and error-prone (insecure). This space is really going to thrive when a blockchain network with a completely new set of features can be spun up *clicks fingers* . like that Stratis — A Modular Platform The most exciting thing about Stratis for me is we’re thinking about building blockchains radically differently. Different consensus algorithms, smart contract executors, wallets, and two-way peg implementations are all features in the one codebase. Currently you can run — all from the one codebase: A Bitcoin (PoW) node A Stratis (PoS) node A Cirrus (PoA + smart contract) node. Moreover, because of how flexible the node is, I’m confident we could build out full node integrations for Bitcoin Cash, Gold, Private, Doge, Litecoin, etc. in each. Down the road we could extend this to support even more chain types easily, after some foray into the account model and other features. days When building a new website in .NET Core, you can preload a template and adjust the components to your needs rapidly, punching out a new prototype web app in under a day. We hope that with Stratis developers will be able to do the same but for their own blockchain networks. IFullNode node = new FullNodeBuilder() .UseNodeSettings(nodeSettings)

.UseBlockStore()

.UseMempool()

.AddRPC()

.AddSmartContracts()

.UseCLRExecutor()

.UseApi()

.Build(); Isn’t it beautiful? Our . Full Node repo is here In Conclusion Modularity == Innovation. I don’t think anyone is as far ahead as we are when it comes to a strong composable approach to building blockchain networks. To find out more follow us on Twitter: https://twitter.com/stratisplatform Or if you just want to wave: https://twitter.com/codingupastorm

The Importance of Modularity in a Blockchain Platform

Next-Gen FHE Toolchains for the Dev Multiverse: How TFHE Is Taking Us There

ReactJS and the Future of AI-Powered Web Components: What Will the Future Look Like?

Hacking Backward and Forward-Compatible Application Releases

PANAMA CITY, Panama, May 7th, 2024/Chainwire/--Silent Protocol, a forefront innovator in blockchain privacy technology, has announced the release of the Ghost Layer, a cutting-edge modular Layer 1.5 designed for the Ethereum ecosystem. This new solution is engineered to provide compliant privacy enhancements to public blockchains, suitable for both retail and institutional applications. The Ghost Layer is using a zero-knowledge (ZK) based system alongside its proprietary 0VM technology. These advancements allow for the private storage of assets and enable the omnidirectional flow of value across various blockchains. It facilitates the seamless integration of existing applications into private workflows through its ability to open access channels to different execution layers. The founder of Silent Protocol, Novachrono, explains the unique position of the Ghost Layer in the blockchain hierarchy: “If you create a ledger whose state is decided by the base ledger but the computation is stored elsewhere—you can call it a Layer 1.5.” This innovative positioning combines the robustness of base layer processing with enhanced privacy and interoperability functions. In 2023, Silent Protocol launched EZEE, addressing the challenge of state denial and introducing a fully composable architecture that supports functional privacy. This framework allows developers to build an ecosystem of applications without the constraints of isolated systems. Furthermore, Silent Protocol has developed the Silent Compliance VM, a decentralized protocol that selectively reveals data to prevent misuse by bad actors. Isa Sertkaya, Co-founder and CTO of Silent Protocol, emphasized the strategic advantage of the Ghost Layer: "Rooted out of Ethereum and supporting Ethereum assets, the Ghost Layer achieves modularity not by capturing value vertically but by enabling horizontal composability across different chains." The implementation of 0VM technology allows the Ghost Layer to advance the state of the system while verifying updates and utilizing the base ledger for state validation through zksnarks. This launch signifies Silent Protocol’s commitment to building a compliant and composable framework that enables institutions to securely and privately leverage Ethereum. Developers across various blockchains will now have the opportunity to transform their existing applications into privacy-preserving applications, known as 0dapps while maintaining the liquidity available on the mainnet. About Silent Protocol Silent Protocol is a leader in blockchain privacy technology, dedicated to enhancing security and compliance in blockchain applications without sacrificing performance. Founded by a team of blockchain innovators, Silent Protocol develops scalable, privacy-centric frameworks like the EZEE framework and Silent Compliance VM. These tools empower developers and institutions to transform existing applications into secure, privacy-preserving platforms while fostering interoperability across different blockchain systems. Contact Co-Founder & CTO İsa Sertkaya isa@silentdao.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. PANAMA CITY, Panama, May 7th, 2024/Chainwire/--Silent Protocol, a forefront innovator in blockchain privacy technology, has announced the release of the Ghost Layer, a cutting-edge modular Layer 1.5 designed for the Ethereum ecosystem. This new solution is engineered to provide compliant privacy enhancements to public blockchains, suitable for both retail and institutional applications. The Ghost Layer is using a zero-knowledge (ZK) based system alongside its proprietary 0VM technology. These advancements allow for the private storage of assets and enable the omnidirectional flow of value across various blockchains. It facilitates the seamless integration of existing applications into private workflows through its ability to open access channels to different execution layers. The founder of Silent Protocol, Novachrono, explains the unique position of the Ghost Layer in the blockchain hierarchy: “If you create a ledger whose state is decided by the base ledger but the computation is stored elsewhere—you can call it a Layer 1.5.” The founder of Silent Protocol, Novachrono, explains the unique position of the Ghost Layer in the blockchain hierarchy: “If you create a ledger whose state is decided by the base ledger but the computation is stored elsewhere—you can call it a Layer 1.5.” This innovative positioning combines the robustness of base layer processing with enhanced privacy and interoperability functions. In 2023, Silent Protocol launched EZEE, addressing the challenge of state denial and introducing a fully composable architecture that supports functional privacy. This framework allows developers to build an ecosystem of applications without the constraints of isolated systems. Furthermore, Silent Protocol has developed the Silent Compliance VM, a decentralized protocol that selectively reveals data to prevent misuse by bad actors. Isa Sertkaya, Co-founder and CTO of Silent Protocol, emphasized the strategic advantage of the Ghost Layer: "Rooted out of Ethereum and supporting Ethereum assets, the Ghost Layer achieves modularity not by capturing value vertically but by enabling horizontal composability across different chains." Isa Sertkaya, Co-founder and CTO of Silent Protocol, emphasized the strategic advantage of the Ghost Layer: "Rooted out of Ethereum and supporting Ethereum assets, the Ghost Layer achieves modularity not by capturing value vertically but by enabling horizontal composability across different chains." The implementation of 0VM technology allows the Ghost Layer to advance the state of the system while verifying updates and utilizing the base ledger for state validation through zksnarks. This launch signifies Silent Protocol’s commitment to building a compliant and composable framework that enables institutions to securely and privately leverage Ethereum. Developers across various blockchains will now have the opportunity to transform their existing applications into privacy-preserving applications, known as 0dapps while maintaining the liquidity available on the mainnet. About Silent Protocol Silent Protocol is a leader in blockchain privacy technology, dedicated to enhancing security and compliance in blockchain applications without sacrificing performance. Founded by a team of blockchain innovators, Silent Protocol develops scalable, privacy-centric frameworks like the EZEE framework and Silent Compliance VM. These tools empower developers and institutions to transform existing applications into secure, privacy-preserving platforms while fostering interoperability across different blockchain systems. Contact Co-Founder & CTO İsa Sertkaya isa@silentdao.org isa@silentdao.org This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

Silent Protocol To launch ‘Ghost layer’: The First Modular L1.5 For Ethereum

Debunking 5 Common Web3 Communications Myths

5 কমন Web3 কমিউনিকেশন মিথ ডিবাঙ্কিং

Entlarvung von 5 gängigen Mythen zur Web3-Kommunikation

Desmentiendo 5 mitos comunes sobre las comunicaciones Web3

Démystifier 5 mythes courants sur les communications Web3

वेब3 संचार से जुड़े 5 आम मिथकों का खंडन

Web3 コミュニケーションに関する 5 つのよくある誤解を解明

Web3 커뮤니케이션에 대한 5가지 일반적인 오해 폭로

Desmascarando 5 mitos comuns sobre comunicações Web3

Развенчание 5 распространенных мифов о коммуникациях Web3

5 Yaygın Web3 İletişim Efsanesini Çürütüyoruz

Làm sáng tỏ 5 lầm tưởng phổ biến về truyền thông Web3

揭穿 5 个常见的 Web3 通信神话

Deep Dive into Functional Programming in Javascript

In C#, an event is a mechanism that allows a class or object to notify other classes or objects when something happens. It is essentially a way of implementing the observer design pattern. Here's a Basic Breakdown of How Events Work in C#: Declaration of the Event: An event is declared using the event keyword followed by a delegate type. This delegate type defines the signature of the event handler method that will be called when the event is raised. Declaration of the Event: Syntax public event EventHandler MyEvent; Subscription of the Event: Other classes or objects can subscribe to the event by adding event handler methods to the event. Subscription of the Event: Syntax instance.MyEvent += SomeMethod; // Subscribe Raising the Event: The class that declares the event can raise it, typically within a method or property setter where the appropriate conditions are met. Raising the Event: Syntax if (MyEvent != null) { MyEvent(this, EventArgs.Empty); } Event Handler: The event handler method is a method that matches the signature of the delegate type associated with the event. This method will be invoked when the event is raised. Event Handler: Syntax void SomeMethod(object sender, EventArgs e) { // Handle the event } Unsubscription: Subscribed event handlers can be unsubscribed from the event. Unsubscription: Syntax instance.MyEvent -= SomeMethod; // Unsubscribe Event in C# With Example using System; public class Program { public class EventPublisher { // Define an event delegate public event EventHandler<CustomEventArgs> CustomEvent; // Method to raise the event
public void RaiseEvent() { OnCustomEvent(new CustomEventArgs("Event raised!")); } // Method to invoke the event protected virtual void OnCustomEvent(CustomEventArgs e) { CustomEvent?.Invoke(this, e); } }
public class CustomEventArgs : EventArgs { public string Message { get; } public CustomEventArgs(string message) { Message = message; } }
public class EventSubscriber { public void HandleEvent(object sender, CustomEventArgs e) { Console.WriteLine($"Event handled: {e.Message}"); } } public static void Main(string[] args) {
EventPublisher publisher = new EventPublisher(); EventSubscriber subscriber = new EventSubscriber(); // Subscribe to the event publisher.CustomEvent += subscriber.HandleEvent; // Raise the event publisher.RaiseEvent(); // Unsubscribe from the event publisher.CustomEvent -= subscriber.HandleEvent; } } Output Event handled: Event raised! In This Above Example: EventPublisher defines an event named CustomEvent of type EventHandler. EventPublisher also has a method RaiseEvent() which raises the CustomEvent. CustomEventArgs is a custom class derived from EventArgs which contains additional data to be passed along with the event. EventSubscriber has a method HandleEvent() which serves as the event handler. In the Main method, an instance of EventPublisher and EventSubscriber is created. The HandleEvent method of EventSubscriber is subscribed to the CustomEvent event of the CustomEvent EventPublisher. The RaiseEvent() method is called on the EventPublisher triggering the event and invoking the HandleEvent method in EventSubscriber. Finally, the HandleEvent method is unsubscribed from the CustomEvent. Why Use Event in C# Events are widely used in C# for implementing various patterns such as the observer pattern, implementing callbacks, and handling user interface interactions in GUI applications. They provide a way for objects to communicate without needing to have direct knowledge of each other. In C#, events are used to implement the observer design pattern, also known as the publish-subscribe pattern. They provide a way for objects to communicate and react to changes or actions that occur in other objects without needing to have direct knowledge of each other. Events are extensively used in user interface programming (e.g., Windows Forms, WPF, ASP.NET) to handle user interactions such as button clicks, mouse movements, and keyboard inputs. Events help in decoupling components of an application. Publishers (objects that raise events) do not need to know about the subscribers (objects that handle events), and vice versa Events enable extensibility by allowing new event handlers to be added without modifying existing code. This makes it easier to add new functionalities or behaviors to an application without having to modify the existing codebase. Where Use Event in C# User Interface (UI) Programming: Events are extensively used in UI programming frameworks like Windows Forms, WPF (Windows Presentation Foundation), ASP.NET, Xamarin, and others. Examples include handling button clicks, mouse movements, keyboard inputs, and other user interactions. Asynchronous Programming: Events are used in asynchronous programming to notify subscribers when asynchronous operations are completed. This is common in scenarios such as handling the completion of asynchronous I/O operations, asynchronous processing in multi-threaded applications, or handling events in asynchronous event-driven programming models. Observer Design Pattern: Events are often used to implement the Observer design pattern, where an object (the subject or publisher) maintains a list of dependent objects (observers or subscribers) and notifies them of changes in its state. This pattern is widely used in scenarios such as event-driven architectures, GUI programming, and reactive programming. Custom Event Handling: Developers define custom events in their classes to provide a way for other objects to respond to specific actions or state changes. For example, a class representing a data model might raise events when data is updated, allowing other components to react accordingly. Delegates and Callbacks: Events are frequently used in conjunction with delegates and callback functions to provide a mechanism for callback-based programming, where one object calls a method on another object in response to some event or condition. Decoupling Components: Events are used to decouple components in an application, enabling loosely coupled architecture. This allows components to interact without having direct dependencies on each other's implementations, leading to better modularity, maintainability, and extensibility. Logging and Monitoring: Events are often used for logging and monitoring purposes in applications to record significant events, errors, or exceptions for debugging, analysis, or audit trail purposes. For more useful tutorials, please visit the site: C-Sharp Tutorial In C#, an event is a mechanism that allows a class or object to notify other classes or objects when something happens. It is essentially a way of implementing the observer design pattern. Here's a Basic Breakdown of How Events Work in C#: Declaration of the Event: An event is declared using the event keyword followed by a delegate type. This delegate type defines the signature of the event handler method that will be called when the event is raised. Declaration of the Event: Syntax public event EventHandler MyEvent; public event EventHandler MyEvent; Subscription of the Event: Other classes or objects can subscribe to the event by adding event handler methods to the event. Subscription of the Event: Syntax instance.MyEvent += SomeMethod; // Subscribe instance.MyEvent += SomeMethod; // Subscribe Raising the Event: The class that declares the event can raise it, typically within a method or property setter where the appropriate conditions are met. Raising the Event: Syntax if (MyEvent != null) { MyEvent(this, EventArgs.Empty); } if (MyEvent != null) { MyEvent(this, EventArgs.Empty); } Event Handler: The event handler method is a method that matches the signature of the delegate type associated with the event. This method will be invoked when the event is raised. Event Handler: Syntax void SomeMethod(object sender, EventArgs e) { // Handle the event } void SomeMethod(object sender, EventArgs e) { // Handle the event } Unsubscription: Subscribed event handlers can be unsubscribed from the event. Unsubscription: Syntax instance.MyEvent -= SomeMethod; // Unsubscribe instance.MyEvent -= SomeMethod; // Unsubscribe Event in C# With Example using System; public class Program { public class EventPublisher { // Define an event delegate public event EventHandler<CustomEventArgs> CustomEvent; // Method to raise the event public void RaiseEvent() { OnCustomEvent(new CustomEventArgs("Event raised!")); } // Method to invoke the event protected virtual void OnCustomEvent(CustomEventArgs e) { CustomEvent?.Invoke(this, e); } } public class CustomEventArgs : EventArgs { public string Message { get; } public CustomEventArgs(string message) { Message = message; } } public class EventSubscriber { public void HandleEvent(object sender, CustomEventArgs e) { Console.WriteLine($"Event handled: {e.Message}"); } } public static void Main(string[] args) { EventPublisher publisher = new EventPublisher(); EventSubscriber subscriber = new EventSubscriber(); // Subscribe to the event publisher.CustomEvent += subscriber.HandleEvent; // Raise the event publisher.RaiseEvent(); // Unsubscribe from the event publisher.CustomEvent -= subscriber.HandleEvent; } } using System; public class Program { public class EventPublisher { // Define an event delegate public event EventHandler<CustomEventArgs> CustomEvent; // Method to raise the event public void RaiseEvent() { OnCustomEvent(new CustomEventArgs("Event raised!")); } // Method to invoke the event protected virtual void OnCustomEvent(CustomEventArgs e) { CustomEvent?.Invoke(this, e); } } public class CustomEventArgs : EventArgs { public string Message { get; } public CustomEventArgs(string message) { Message = message; } } public class EventSubscriber { public void HandleEvent(object sender, CustomEventArgs e) { Console.WriteLine($"Event handled: {e.Message}"); } } public static void Main(string[] args) { EventPublisher publisher = new EventPublisher(); EventSubscriber subscriber = new EventSubscriber(); // Subscribe to the event publisher.CustomEvent += subscriber.HandleEvent; // Raise the event publisher.RaiseEvent(); // Unsubscribe from the event publisher.CustomEvent -= subscriber.HandleEvent; } } Output Event handled: Event raised! Event handled: Event raised! In This Above Example: EventPublisher defines an event named CustomEvent of type EventHandler. EventPublisher defines an event named CustomEvent of type EventHandler. EventPublisher also has a method RaiseEvent() which raises the CustomEvent. EventPublisher also has a method RaiseEvent() which raises the CustomEvent. CustomEventArgs is a custom class derived from EventArgs which contains additional data to be passed along with the event. CustomEventArgs is a custom class derived from EventArgs which contains additional data to be passed along with the event. EventSubscriber has a method HandleEvent() which serves as the event handler. EventSubscriber has a method HandleEvent() which serves as the event handler. In the Main method, an instance of EventPublisher and EventSubscriber is created. In the Main method, an instance of EventPublisher and EventSubscriber is created. The HandleEvent method of EventSubscriber is subscribed to the CustomEvent event of the CustomEvent EventPublisher. The HandleEvent method of EventSubscriber is subscribed to the CustomEvent event of the CustomEvent EventPublisher. The RaiseEvent() method is called on the EventPublisher triggering the event and invoking the HandleEvent method in EventSubscriber. The RaiseEvent() method is called on the EventPublisher triggering the event and invoking the HandleEvent method in EventSubscriber. Finally, the HandleEvent method is unsubscribed from the CustomEvent. Finally, the HandleEvent method is unsubscribed from the CustomEvent. Why Use Event in C# Events are widely used in C# for implementing various patterns such as the observer pattern, implementing callbacks, and handling user interface interactions in GUI applications. They provide a way for objects to communicate without needing to have direct knowledge of each other. In C#, events are used to implement the observer design pattern, also known as the publish-subscribe pattern. They provide a way for objects to communicate and react to changes or actions that occur in other objects without needing to have direct knowledge of each other. Events are extensively used in user interface programming (e.g., Windows Forms, WPF, ASP.NET) to handle user interactions such as button clicks, mouse movements, and keyboard inputs. Events help in decoupling components of an application. Publishers (objects that raise events) do not need to know about the subscribers (objects that handle events), and vice versa Events enable extensibility by allowing new event handlers to be added without modifying existing code. This makes it easier to add new functionalities or behaviors to an application without having to modify the existing codebase. Where Use Event in C# User Interface (UI) Programming: Events are extensively used in UI programming frameworks like Windows Forms, WPF (Windows Presentation Foundation), ASP.NET, Xamarin, and others. Examples include handling button clicks, mouse movements, keyboard inputs, and other user interactions. User Interface (UI) Programming: Asynchronous Programming: Events are used in asynchronous programming to notify subscribers when asynchronous operations are completed. This is common in scenarios such as handling the completion of asynchronous I/O operations, asynchronous processing in multi-threaded applications, or handling events in asynchronous event-driven programming models. Asynchronous Programming: Observer Design Pattern: Events are often used to implement the Observer design pattern, where an object (the subject or publisher) maintains a list of dependent objects (observers or subscribers) and notifies them of changes in its state. This pattern is widely used in scenarios such as event-driven architectures, GUI programming, and reactive programming. Observer Design Pattern: Custom Event Handling: Developers define custom events in their classes to provide a way for other objects to respond to specific actions or state changes. For example, a class representing a data model might raise events when data is updated, allowing other components to react accordingly. Custom Event Handling: Delegates and Callbacks: Events are frequently used in conjunction with delegates and callback functions to provide a mechanism for callback-based programming, where one object calls a method on another object in response to some event or condition. Delegates and Callbacks: Decoupling Components: Events are used to decouple components in an application, enabling loosely coupled architecture. This allows components to interact without having direct dependencies on each other's implementations, leading to better modularity, maintainability, and extensibility. Decoupling Components: Logging and Monitoring: Events are often used for logging and monitoring purposes in applications to record significant events, errors, or exceptions for debugging, analysis, or audit trail purposes. Logging and Monitoring: For more useful tutorials, please visit the site: C-Sharp Tutorial C-Sharp Tutorial

Events in C#: An Easy-to-Understand Guide

As companies embrace LLMs, what is the balance between flexibility and risk, and what does that mean for the build-or-buy debate? Although the build or buy dichotomy is a relatively ‘new’ hurdle for technology decision-makers, especially as in-house development teams upskill and build their proprietary solutions, there’s no doubt that the rise of GenAI technologies has taken that conundrum a step further. As organizations grapple with this topic, a fresh layer of decision-making comes into play. Should we be building our own GenAI solutions in-house (and can we?), or is it safer to be buying off-the-shelf products from established vendors?
As things change so rapidly, are we at risk of lock-in at the pace of tech advances, or are we investing huge amounts of resources into keeping up internally? You’ll be shocked to read that the answer, as with most strategic choices, is not clear-cut. I’m going to apply this thinking specifically to the legal sector, where the need for AI is especially prevalent, and the adoption more considered. As in any industry, though, when assessing the build vs. buy decision for LLM solutions, firms must carefully consider their specific use cases, data privacy and security requirements, and long-term ROI. Flexibility is paramount, as the chosen solution must adapt to the firm’s unique needs and integrate effectively with existing systems and workflows. The lure and limits of building in-house GenAI services For companies with more mature software development capabilities, building a custom GenAI application can seem appealing. The APIs underpinning models like GPT-3 are remarkably powerful, enabling developers to quickly spin up basic proof-of-concepts that feel nearly complete. A law firm could connect to the API and prompt it to generate case summaries or first-pass contract reviews. Voilà - a working solution in hours! However, this apparent simplicity belies the reality. Crafting a robust, enterprise-grade GenAI application involves far more than API plumbing. Sensitive data handling, security audits, intuitive UX design, ongoing maintenance as models evolve - the hidden iceberg of work is substantial. For companies lacking seasoned software teams, attempting this undertaking is risky at best. Moreover,  building in-house raises critical questions about data privacy and security. Law firms must ensure their GenAI solutions comply with strict confidentiality requirements and protect client information. Any lapses or breaches could have severe legal and reputational consequences. The convenience and constraints of buying GenAI services On the other end of the spectrum, procuring a subscription to a turnkey GenAI service like Microsoft's Copilot or OpenAI's ChatGPT Enterprise is fast and easy. These generic tools can capably handle a wide array of use cases out of the box, from ideation to writing to analysis. Simply sign up and start prompting. However, one size does not fit all. A lawyer who unwittingly relies on a ChatGPT-generated brief riddled with hallucinated case law precedents could face serious consequences in court. GenAI models are powerful but error-prone, especially when applied naively to specialized domains. Careful human oversight, ideally guided by customizable verification workflows, remains essential. Externally sourced LLMs may also have limitations in terms of flexibility and integrations. Off-the-shelf tools are rarely designed to work seamlessly with a law firm's specific document management systems, CRMs, or bespoke data sources. This lack of integration can hinder adoption and negate efficiency gains. In contrast, custom-built solutions can be tailored to a law firm's exact requirements and orchestrated to plug into existing infrastructure. However, this flexibility comes at a steep development cost and may not be feasible for firms without substantial in-house IT resources. Best of both? Increasingly, forward-looking law firms are seeking a happy medium between the rigidity of pure-play buys and the burdens of bespoke builds. The benefits here include working with partners that have already done the heavy lifting of developing secure, enterprise-hardened GenAI platforms but also providing the API and tooling extensibility to tailor the last mile more specifically. When evaluating potential partners, prioritize those that offer a modular, API-driven architecture, allowing you to leverage pre-built components for common use cases while retaining the flexibility to customize and integrate with your existing systems. This approach enables law firms to start quickly with proven solutions and then iterate and extend as their needs evolve. Increasingly, firms are now looking for partners that aren’t locked into a single LLM or vendor. The GenAI landscape is evolving rapidly, with new models and capabilities emerging all the time. That means law firms need to ensure that they always have access to the most powerful and appropriate language models for their specific applications. What’s the cost difference? In this sort of context, it’s less about the cost differential and more about cost predictability. Cost comparisons between building and buying can be complex, as hidden expenses often lurk beneath the surface. In-house development may require significant upfront investment in infrastructure, talent acquisition, and training, while ongoing maintenance and updates can add unpredictable drains on IT budgets. Conversely, SaaS subscriptions may have lower startup costs but can accumulate substantial fees over time, especially as usage scales. CXOs should carefully model the total cost of ownership for both options over a multi-year horizon, factoring in both hard costs and soft considerations like time-to-value, opportunity costs, and reputational risks. Engaging an experienced partner to guide this analysis can provide valuable perspective. Today’s middle ground has also entered consumption-based pricing into the arena, helping law firms avoid the sticker shock of upfront licenses and better align costs with realized value. The ability to start small and scale usage as adoption grows is key to maximizing ROI and minimizing risk. Bridging the gap We are all sadly familiar with the risks of vendor lock-in and grinding in-house builds, but conversely, we may well have had positive experiences of both. The point is that there’s no one-size-fits-all approach and no decision flow that points to ‘build’ in one context, ‘buy’ in another, or ‘both’ in the third. The modularity enabled by the API-driven nature of modern GenAI opens the door to composable solutions that blend the best of buy and build. With the right decisions, companies can stay agile, avoiding over-investment in bespoke tech that may rapidly become outdated in the fast-moving GenAI space, while still tailoring capabilities to their unique needs. With such rapid advances in technology, being first-movers in this profession can be risky, and organizations tend to counter the rush to act with the cost of delay. In the long run, this cost can mount far higher than first thought. We’re navigating uncertain plains at the moment, and the key is to chart a balanced course, working with partners that will elevate your capabilities and not hinder them. Flexibility, extensibility, and strategic integration are the pillars of GenAI's effectiveness today. As law firms unlock the potential of LLMs to drive efficiency and competitive advantage, they can combine the ease and speed of pre-built foundations with the flexibility and control of customizable components. The GenAI world is advancing by the second, with decisions now centered primarily on minimizing risk and maximizing ROI. As companies embrace LLMs, what is the balance between flexibility and risk, and what does that mean for the build-or-buy debate? As companies embrace LLMs, what is the balance between flexibility and risk, and what does that mean for the build-or-buy debate? Although the build or buy dichotomy is a relatively ‘new’ hurdle for technology decision-makers, especially as in-house development teams upskill and build their proprietary solutions, there’s no doubt that the rise of GenAI technologies has taken that conundrum a step further. As organizations grapple with this topic, a fresh layer of decision-making comes into play. GenAI Should we be building our own GenAI solutions in-house (and can we?), or is it safer to be buying off-the-shelf products from established vendors? As things change so rapidly, are we at risk of lock-in at the pace of tech advances, or are we investing huge amounts of resources into keeping up internally? Should we be building our own GenAI solutions in-house (and can we?), or is it safer to be buying off-the-shelf products from established vendors? As things change so rapidly, are we at risk of lock-in at the pace of tech advances, or are we investing huge amounts of resources into keeping up internally? You’ll be shocked to read that the answer, as with most strategic choices, is not clear-cut. I’m going to apply this thinking specifically to the legal sector, where the need for AI is especially prevalent, and the adoption more considered. As in any industry, though, when assessing the build vs. buy decision for LLM solutions, firms must carefully consider their specific use cases, data privacy and security requirements, and long-term ROI. Flexibility is paramount, as the chosen solution must adapt to the firm’s unique needs and integrate effectively with existing systems and workflows. The lure and limits of building in-house GenAI services The lure and limits of building in-house GenAI services For companies with more mature software development capabilities, building a custom GenAI application can seem appealing. The APIs underpinning models like GPT-3 are remarkably powerful, enabling developers to quickly spin up basic proof-of-concepts that feel nearly complete. A law firm could connect to the API and prompt it to generate case summaries or first-pass contract reviews. Voilà - a working solution in hours! software development However, this apparent simplicity belies the reality. Crafting a robust, enterprise-grade GenAI application involves far more than API plumbing. Sensitive data handling, security audits, intuitive UX design, ongoing maintenance as models evolve - the hidden iceberg of work is substantial. For companies lacking seasoned software teams, attempting this undertaking is risky at best. Moreover,  building in-house raises critical questions about data privacy and security. Law firms must ensure their GenAI solutions comply with strict confidentiality requirements and protect client information. Any lapses or breaches could have severe legal and reputational consequences. The convenience and constraints of buying GenAI services The convenience and constraints of buying GenAI services On the other end of the spectrum, procuring a subscription to a turnkey GenAI service like Microsoft's Copilot or OpenAI's ChatGPT Enterprise is fast and easy. These generic tools can capably handle a wide array of use cases out of the box, from ideation to writing to analysis. Simply sign up and start prompting. However, one size does not fit all. A lawyer who unwittingly relies on a ChatGPT-generated brief riddled with hallucinated case law precedents could face serious consequences in court. GenAI models are powerful but error-prone, especially when applied naively to specialized domains. Careful human oversight, ideally guided by customizable verification workflows, remains essential. Externally sourced LLMs may also have limitations in terms of flexibility and integrations. Off-the-shelf tools are rarely designed to work seamlessly with a law firm's specific document management systems, CRMs, or bespoke data sources. This lack of integration can hinder adoption and negate efficiency gains. In contrast, custom-built solutions can be tailored to a law firm's exact requirements and orchestrated to plug into existing infrastructure. However, this flexibility comes at a steep development cost and may not be feasible for firms without substantial in-house IT resources. Best of both? Best of both? Increasingly, forward-looking law firms are seeking a happy medium between the rigidity of pure-play buys and the burdens of bespoke builds. The benefits here include working with partners that have already done the heavy lifting of developing secure, enterprise-hardened GenAI platforms but also providing the API and tooling extensibility to tailor the last mile more specifically. When evaluating potential partners, prioritize those that offer a modular, API-driven architecture, allowing you to leverage pre-built components for common use cases while retaining the flexibility to customize and integrate with your existing systems. This approach enables law firms to start quickly with proven solutions and then iterate and extend as their needs evolve. Increasingly, firms are now looking for partners that aren’t locked into a single LLM or vendor. The GenAI landscape is evolving rapidly, with new models and capabilities emerging all the time. That means law firms need to ensure that they always have access to the most powerful and appropriate language models for their specific applications. What’s the cost difference? What’s the cost difference? In this sort of context, it’s less about the cost differential and more about cost predictability. Cost comparisons between building and buying can be complex, as hidden expenses often lurk beneath the surface. In-house development may require significant upfront investment in infrastructure, talent acquisition, and training, while ongoing maintenance and updates can add unpredictable drains on IT budgets. Conversely, SaaS subscriptions may have lower startup costs but can accumulate substantial fees over time, especially as usage scales. CXOs should carefully model the total cost of ownership for both options over a multi-year horizon, factoring in both hard costs and soft considerations like time-to-value, opportunity costs, and reputational risks. Engaging an experienced partner to guide this analysis can provide valuable perspective. Today’s middle ground has also entered consumption-based pricing into the arena, helping law firms avoid the sticker shock of upfront licenses and better align costs with realized value. The ability to start small and scale usage as adoption grows is key to maximizing ROI and minimizing risk. Bridging the gap Bridging the gap We are all sadly familiar with the risks of vendor lock-in and grinding in-house builds, but conversely, we may well have had positive experiences of both. The point is that there’s no one-size-fits-all approach and no decision flow that points to ‘build’ in one context, ‘buy’ in another, or ‘both’ in the third. The modularity enabled by the API-driven nature of modern GenAI opens the door to composable solutions that blend the best of buy and build. With the right decisions, companies can stay agile, avoiding over-investment in bespoke tech that may rapidly become outdated in the fast-moving GenAI space, while still tailoring capabilities to their unique needs. With such rapid advances in technology, being first-movers in this profession can be risky, and organizations tend to counter the rush to act with the cost of delay. In the long run, this cost can mount far higher than first thought. We’re navigating uncertain plains at the moment, and the key is to chart a balanced course, working with partners that will elevate your capabilities and not hinder them. Flexibility, extensibility, and strategic integration are the pillars of GenAI's effectiveness today. As law firms unlock the potential of LLMs to drive efficiency and competitive advantage, they can combine the ease and speed of pre-built foundations with the flexibility and control of customizable components. The GenAI world is advancing by the second, with decisions now centered primarily on minimizing risk and maximizing ROI.

Hacking GenAI Integration: Build, buy or both?

Radix Engine: A Better Model for “Enshrinement"

রেডিক্স ইঞ্জিন: "এনশ্রাইনমেন্ট" এর জন্য একটি ভাল মডেল

Radix Engine: Ein besseres Modell für „Enshrinement

Radix Engine: un mejor modelo para la “consagración”

Moteur Radix : un meilleur modèle pour « l’enchâssement »

रेडिक्स इंजन: “प्रतिष्ठा के लिए एक बेहतर मॉडल”

Radix Engine: 「殿堂入り」のより良いモデル

Radix 엔진: "Enshrinement"를 위한 더 나은 모델

Radix Engine: um modelo melhor para “consagração

Radix Engine: лучшая модель для «закрепления»

Radix Engine: “Kutsallaştırma” için Daha İyi Bir Model

Radix Engine: Một mô hình tốt hơn cho “Bảo quản

Radix Engine：一个更好的“供奉”模型

Authors: (1) Philipp Straubinger, University of Passau, Passau, Germany and this author contributed equally to this research; (2) Tommaso Fulcini, Politecnico di Torino,  Torino, Italy and this author contributed equally to this research; (3) Gordon Fraser, University of Passau, Passau, Germany; (4) Marco Torchiano, Politecnico di Torino, Torino, Italy. Table of Links Abstract and Introduction Background and Related Work Implementation Experiment Results Conclusions, Acknowledgement, and References 4 EXPERIMENT The primary aim of the experiment was to replicate the conditions outlined in the original validation paper [8], adhering to the guidelines set by Jedlitschka et al. [4]. However, as the goal was not to assess the effectiveness of the tool but rather to test its applicability with a different programming language and subjects, we introduced some modifications to the experimental approach. 4.1 Participant Selection We invited graduate students from the Software Engineering course at Politecnico di Torinoto participate voluntarily in the experiment. Successful participation earned students additional points for their Software Engineering exam, with the assurance that their performance would not impact their bonus points to avoid bias. All participating students possessed prior JavaScript testing experience, as the Software Engineering course extensively covered unit testing using the Jest framework. The sample of participants in this study comprised 152 individuals, with 85% identifying as male and the remaining 15% as female. Over 90% fell within the age range of 22 to 25, being graduate students. The participants were randomly assigned to one of two groups: treatment and control. The majority of participants had less than three months of experience with JavaScript, and it is worth noting that the treatment group had less experience compared to the control group with 59% and 47% having less than three months of experience, respectively. Additionally, 96% of participants in both groups had less than three months of experience with Jest. In fact, the majority of participants were introduced to JavaScript and Jest during the course’s lectures. 4.2 Project Selection Initially, with a shift in the reference programming language, the need arose to select an alternative project, departing from the FixedOrderComparator Java class used in the original study [8]. Our criteria for project selection involved finding a subject that presented both challenge and feasibility within a 150-minute timeframe. We sought a real existing project to capture the complexity 3https://github.com/tsantalis/RefactoringMiner of a real-world scenario, emphasizing documentation, a comprehensive test suite, and modularity. Modularity was crucial, allowing participants to choose among modules, and deciding whether to tackle more complex or simpler functions. The selection process began by exploring JavaScripting[4], a repository of publicly available JavaScript projects. Given the extensive collection, including popular frameworks like React, React Native, Vue, and Angular, we narrowed down our search to importable lightweight libraries with standardized functionalities. We focused on the miscellaneous category for a subject meeting our criteria. The first project suiting our needs was Date Fns5 , an open-source project featuring 244 functions related to the date data type. Functions ranged from trivial tasks like determining the order between two dates to more complex operations like formatting data with ISO or RFC representation. The project, widely used (over two million times) and well-maintained by 300+ contributors with over a thousand forks, met our requirements. The project, however, was developed in TypeScript (TS) rather than JS. Notwithstanding the difference between the two programming languages, given the high project usage and reliability, the full interoperability of JS code in TS and the possibility of directly transposing TS code into JS, was deemed that this language difference was not a reason for exclusion. Moreover, we consider it valuable for the reader to discuss in section 5.2 the problems encountered and the solutions put in place to resolve them. For these reasons, we used the JS version obtained through transpilation [10]. The seamless interoperability between the two languages facilitated the conversion of functions from TS to JS, made possible with the help of the open-source automatic tool transform[6]. 4.3 Experiment Task We carefully chose a set of 23 functions from the original GitHub Date Fns project, prioritizing simplicity in terms of complexity and lines of code. The aim was to ensure that most students could confidently build and test these functions without feeling overwhelmed by their difficulty Before assigning the experiment task, we conducted a pilot study with three master’s students nearing graduation. This helped validate the task’s scalability. While no data was collected from them, the pilot ensured proper calibration by adjusting the assignment’s complexity, excluding the three most challenging functions. The functions’ bodies were removed, leaving the requirements, function names, and parameters intact. The project incorporated complete JavaScript documentation for built-in date functions, eliminating the need for online references. Two verification methods were provided: a Jest configuration with empty test files for participants to complete and run, and a main.js file acting like the Main class in Java, mirroring the original experiment’s setup [8]. Two sessions were held: the first with 60 participants and the second with the remaining individuals. This division allowed potential data discarding from the first day if any issues arose. Participants were split into a control group, tackling tasks without achievements, and a treatment group, completing tasks with the plugin enabled. Participants from the treatment group were instructed on how the gamification plugin works but were not shown in detail the conditions for unlocking each achievement. These were shown in an overlay box displayed on the screen when hovering the mouse over each achievement of the list. During the experiment, a custom event logger recorded achievement states after each user interaction. An automated script committed and pushed current implementations and log files to a Git repository every minute. Following the 150-minute implementation phase, an exit questionnaire featured general questions for both groups. The treatment group received an additional page at the end of the survey inquiring about their plugin experiences, with answers on a five-point Likert scale. An optional free-text question allowed participants to share individual comments and feedback. This paper is under CC BY-SA 4.0 DEED license. available on arxiv [4] https://www.javascripting.com/ [5] https://github.com/date-fns/date-fns [6] https://github.com/ritz078/transform

IntelliGame in Action: Gamifying JavaScript Unit Tests - Experiment

SINGAPORE, Singapore, April 3rd, 2024/Chainwire/--Skate is backed by leading founders in web3, including EigenLayer, Polygon, Manta, Axelar, Pendle, A41 and Galxe, supporting its vision to make web3 efficient for a modular future by solving application fragmentation
Range Protocol, a unified liquidity provisioning platform, today announced the launch of Skate, the universal application layer that empowers apps to run on thousands of chains with one state. Designed with an intent-centric approach, Skate aims to efficiently address the application fragmentations as a single hub for all code deployment across all chains. Backed by leading web3 players, including EigenLayer, Polygon, Manta, Axelar, Biconomy, Pendle, A41, Vertex, Navi, Galxe, Pontem and more, Skate will deliver its vision with faster finality and universal application scope, paving the way for its mainnet launch within the year. In today’s multi-chain landscape, applications face pressing needs to deploy, adapt and maintain across an increasing number of chains. Skate introduces the concept of a Universal Application Scope, where essential applications are developed collectively and maintained in a shared pool accessible to all chains — regardless of its underlying Virtual Machine environment. With Skate, users and developers are able to efficiently and instantly access thousands of chains by interacting with one application instance. Siddharth Lalwani, Co-Founder and CEO of Range Protocol shared, “The rise of modularity powered innovations such as improved throughput and reduced transaction costs. However, it also came with its own set of challenges, most notably, application fragmentation. Skate introduces the concept of the Universal Application Layer, where essential applications are developed collectively, and maintained in a shared pool accessible to all chains. This ensures foundational needs of builders and users are met efficiently, allowing each chain to focus on creating value-added services and laying the building blocks for a modular future.” Move from Duplication to Innovation: One Skate, One State Skate is the only intent-centric application layer in the ecosystem, enabling applications to run across thousands of chains and different tech stacks at the same time through a single interface. Moving past duplication of deployments, Skate works as a hub for deploying, developing and maintaining a singular version of smart contracts while servicing users across diverse chains. One of the key innovations of Skate is the embedding of interoperability within the application logic, reversing the legacy approach of building apps first and integrating interoperability afterwards. Skate ensures that all applications are created with interoperability as a foundational component, streamlining the development process and removing the necessity to bridge assets, but also significantly enhances the user experience by providing a fluid, interconnected ecosystem where transactions and information flow effortlessly between chains. Aside from the underlying interoperability networks, Skate will be connected to all the blockchains through Fast Finality Network, secured by EigenLayer actively validated service (AVS), to send state attestations from Skate with sufficient trust minimized assumptions. This brings instantaneous cross-chain intent-driven settlements and reduces slippage when making trades while removing unnecessary complexities from an end-user perspective. Securing the Modular Future, Backed by Web3 Pioneers The launch of Skate is supported by buy-ins from leading web3 players, including EigenLayer, Polygon, Manta, Axelar, Biconomy, Pendle, A41, Vertex, Navi, Galxe, Pontem and more. Forged by the same team of financial engineers and web3 developers behind Range Protocol, a unified liquidity provisioning platform covering key DeFi asset classes, the Skate team brings deep cumulative experience from leading companies like Altonomy, Point72, Bybit, Certik and Citigroup. Skate’s launch also follows Range Protocol’s $3.75M seed round last year, led by HashKey Capital and Nomad Capital. In the coming months, Skate aims to introduce Testnet Campaigns to community members with unique incentives. To keep up to date on Skate and its upcoming testnet campaigns, make sure you follow their Twitter: . https://twitter.com/skate_chain About Range Protocol and Skate Underpinned by robust on-chain trading infrastructure, Range Protocol is a unified liquidity provisioning platform. Harnessing advanced expertise and professional strategies, Range Protocol covers key DeFi asset classes through its vault offerings. Combining the best of automated market makers (AMMs) and request-for-quote (RFQ), Range Protocol empowers sound decision-making and optimized strategies for the next generation of investors — with no intermediaries needed. Forged by a team of financial engineers and web3 developers with extensive crypto trading proficiencies, Range Protocol brings deep experience from leading companies like Altonomy, Point72, Bybit, Certik and Citigroup. Its most recent $3.75M seed round was led by HashKey Capital and Nomad Capital. Range now expands into Skate, the universal application layer that empowers apps to run on 1000s of chains with one state. Skate was born with the realization of the limitations of the legacy on-chain trading infrastructure, which deploys repetitive blocks on every new chain. Underpinned by innovation, Skate delivers fast finality across all chains, secured by EigenLayer actively validated service (AVS), and acts as a single hub for all code deployments. Separating assets from pricing, Skate introduces the concept of a Universal Application Scope, where essential applications are developed collectively and maintained in a shared pool accessible to all chains — regardless of its underlying Virtual Machine environment. Solving for dApp/chain-liquidity fragmentation in a modular web3 landscape, Skate ensures foundational needs are met efficiently, allowing each chain to focus on creating unique, value-added services. For more information, please visit: Website: Twitter/X: http://skatechain.org/ https://twitter.com/skate_chain Contact Skate / Range Protocol range@wachsman.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here.

Range Protocol Unveils Skate: An App Layer Powering Apps To Run On All Chains With One State

রেঞ্জ প্রোটোকল স্কেট উন্মোচন করেছে: একটি অ্যাপ্লিকেশান লেয়ার পাওয়ারিং অ্যাপ্লিকেশানগুলি একটি রাজ্যের সাথে সমস্ত চেইনে চালানোর জন্য

Range Protocol stellt Skate vor: eine App-Schicht, die es Apps ermöglicht, auf allen Ketten mit einem Status zu laufen

Range Protocol presenta Skate: una capa de aplicaciones que permite que las aplicaciones se ejecuten en todas las cadenas con un solo estado

Range Protocol dévoile Skate : une couche d'application permettant aux applications de fonctionner sur toutes les chaînes avec un seul état

रेंज प्रोटोकॉल ने स्केट का अनावरण किया: एक ऐप लेयर जो ऐप्स को एक स्टेट के साथ सभी चेन पर चलाने की शक्ति प्रदान करता है

Range Protocol が Skate を発表: 1 つの状態ですべてのチェーン上でアプリを実行できるようにするアプリ層

Range Protocol, 스케이트 공개: 앱이 하나의 상태로 모든 체인에서 실행되도록 지원하는 앱 레이어

Range Protocol revela Skate: uma camada de aplicativo que permite que aplicativos sejam executados em todas as cadeias com um estado

Range Protocol представляет Skate: уровень приложений, позволяющий запускать приложения во всех цепочках с одним состоянием

Range Protokolü Skate'i Tanıtıyor: Uygulamaların Tüm Zincirlerde Tek Durumla Çalıştırılmasına Güç Veren Bir Uygulama Katmanı

Range Protocol ra mắt Skate: Lớp ứng dụng hỗ trợ các ứng dụng chạy trên tất cả các chuỗi với một trạng thái

Range Protocol 推出 Skate：一个应用层，为所有链上运行的应用提供支持

Massive is a decentralized ZK verification network service focused on achieving mass adoption for Web3. It aims to alleviate or even solve some of the key issues currently facing the industry. Here’s a breakdown: Mass Adoption: Massive could attract more users The sector is actively exploring ways to attract more traditional users and resources. Massive takes a novel approach by starting with mobile phones, a device most users are familiar with. By employing a “Verify to Earn” incentive mechanism and simplifying operations, Massive aims to draw more participants. This strategy helps newcomers gradually understand and join the Web3 industry, continuously injecting fresh blood into the sector. Web3 Highly Effective and Cheap: Massive could work as a settlement layer of blockchain Currently, all Rollup solutions based on ZK technology face delays in state confirmation on Layer1 (L1) due to cost and security concerns. This is typically addressed through proof aggregation technology and verification delays. introduces a solution that ensures Layer2 (L2)states can be decentralized and verified immediately after proof generation, significantly reducing the time for state transition confirmation. The verified state is then synchronized to L1, ensuring a swift and secure process. Massive Capital Efficiency: Massive could improve profits Nodes in the POS (Proof of Stake) network can join through staking and re-staking. If approach is reused, the POS consensus network can achieve Ethereum-level security. Massive supports staking and re-staking of various token types and offers flexible staking schemes tailored to different ecosystem types. Eigenlayer’s Modular Design: Massive could complete the modularity The emergence of Massive further advances the modular design of blockchain. It can be specifically divided into ZKRollup (off-chain computation), DA (Data Availability — off-chain transaction storage), ZKVaaS (Zero-Knowledge Verification as a Service — off-chain verification), and L1 (state updates and consensus). Keywords: Zero Knowledge, Mobile devices, Staking, Re-staking, Modularity, POS Introduction In essence, the blockchain industry is currently plagued by a crucial question: "How do we attract more traditional users to this sector?" Even though we witnessed a historical moment in January when a BTC spot ETF was approved, allowing some traditional investors to trade BTC in a compliant manner, the influx of new users and resources still falls far short of the industry's urgent need for fresh participants. Simply opening up investment opportunities can only bring in some investors; achieving mass adoption requires different strategies. Some believe gaming could be the key to reaching this goal, others see potential in social media, and still, others think AI could pave the way. Regardless of the method, it's clear that industry insiders are all striving for mass adoption of blockchain. A recent event that caught my attention was Starkware's STRK token airdrop, which highlighted a significant fact: some developers outside of the usual crypto circles began to explore and show interest in entering the industry. This interest was sparked because Starkware conducted an airdrop to contributors of certain GitHub repositories, developers who might not have known about blockchain previously but became interested due to this event. Another application that left a strong impression on me is StepN, an app that became popular in the last bull market for its "earn while you run" concept. Users simply needed to purchase a pair of virtual shoes and then could earn rewards by running a very straightforward proposition daily. This led to a surge in user numbers and effectively broke into new user demographics. These examples underscore applications or infrastructure projects capable of attracting new users to the industry. To draw new users, the following characteristics are necessary: Simple operation, easy for users to get started; Low hardware requirements; An incentive mechanism. Both examples satisfy the first criteria: GitHub is familiar to developers, and mobile phones are familiar to general users. They also meet the second criteria, requiring either a computer or a mobile phone. The third criteria is met as well, with one offering "contribute to earn" and the other "running to earn." However, to continuously attract new users, sustainable incentives are essential. For Starkware, continuous token airdrops may not be viable; likewise, for StepN, perpetual mining and selling are also unsustainable. Thus, for an application to sustainably attract new users and hold long-term value, it must inherently sustain its appeal. Massive serves as an infrastructure service aimed at sustainably attracting new users to achieve the goal of mass adoption. It can support all ZK chain services, whether ZK layer1, ZK layer2, or ZK layer3, introducing new users to these ZK chains, enhancing system security, reducing operational costs, and improving capital efficiency. Architecture Massive is a POS (Proof of Stake) consensus network that primarily utilizes mobile devices as its nodes. Users are required to download the official app on their mobile devices, which supports both iOS and Android, the two leading operating systems. The architectural framework is outlined as follows (Fig.1): To become a node, users can fall into one of the following two categories: New users without any cryptocurrency assets can initially join the network. Their accumulated rewards must reach a certain amount before they can start unlocking subsequent mining rewards. Users already possessing some cryptocurrency assets can stake these assets to become a node on the Massive network. Depending on the underlying L1 blockchain, users can stake different assets. For example, in a Massive network serving BTC L2/L3, users can stake BRC20 and BTC assets. For Ethereum-based L2/L3 services, users can stake ERC20 and ETH assets. The wallet will integrate several mainstream ZK technology stacks for verification, such as plonky2, plonky3, and boojum, all of which belong to the STARK family. Following market trends, support for mainstream algorithms from the SNARK family, such as Halo2 or Nova, will be iteratively introduced. Mobile nodes that have completed staking will form a POS network to provide Timely Settlement for all Layer 2s and Layer 3s. If there is an excessive number of participating users, sharding technology can be utilized to form multiple independent POS networks according to specific standards. Provide Timely Settlement As mentioned earlier, Massive is not solely focused on attracting users; it also aims to address some of the current issues in the industry. Among these, the confirmation time for ZK L2s/L3s is a frequently discussed issue. Before we delve into this, let's take a look at the main solutions for ZK L2s as illustrated in the following diagram (Fig.2): It's evident that in the design of most L2 solutions, there's a need to aggregate a sufficient number of proofs on L2 and then send them to Ethereum for verification. This approach is adopted to reduce costs. Even with this premise, the aggregated proofs sent to L1 must wait for a certain period before calling the Verify contract to alter the global state, a measure taken from a security standpoint, although this delay can be configured. Therefore, it can be concluded that a L2 transaction, to be finally confirmed, requires a waiting period of between 2 to 23 hours. Until then, the validity of the proofs is verified only by a centralized sequencer. The diagram below (Fig.3) illustrates the current situation where, after their generation, proofs will be verified. Therefore, the primary intention behind Massive's design is to ensure that, before a proof is verified on L1, it goes through a verification process by a decentralized network, so everyone can verify now. It's important to note that if the POS network used for verifying the proof is provided by Eigenlayer's AVS ( ) service, then this POS network possesses the same level of security as Ethereum. Ultimately, only the latest global state needs to be updated on Ethereum. This aspect also offers insights into the modular design evolution discussed in later chapters. Actively Validated Services After incorporating Massive, the entire process flow for L2s could be transformed as shown in the following diagram (Fig.4): By extracting the ZK verify function from L1 and placing trust in the security of the Massive network, then adding a challenge mechanism to reduce the probability of Massive acting maliciously, the entire system's security will depend on the security of the Massive network. If the ecosystem of these ZK L2s is more finance-oriented, Massive could be built on EigenLayer's AVS to ensure the cost of acting maliciously is sufficiently high. Conversely, if the ecosystem of these ZK L2s is related to gaming or social scenarios, then a basic Massive construction would suffice. Capital Efficiency Staking and re-staking have recently become very popular concepts, focusing on capital efficiency. Reutilizing staked assets to achieve compound interest is an attractive economic mechanism currently seen in platforms like Blast and Manta. Unlike these schemes, Massive offers a novel destination for native assets across various networks, as well as for staked assets, by allowing them to become nodes within the Massive network through staking and re-staking mechanisms. Since the Massive network can provide more users, lower costs, and improved security for ZK L2s/L3s, nodes within the Massive network will share in the network maintenance profits, embodying the "verify to earn" concept. Based on the actual circumstances of ZK L2s/L3s, different security levels of ZKVaaS can be chosen. The security level depends on the total amount staked and the number of nodes in the network. New Modular Design As mentioned earlier, Massive, from a certain perspective, further changes the process of blockchain modular design. Before Massive, modular design mainly consisted of execution modularization, with various Rollups solutions, and Data Availability (DA) modularization, with various DA solutions, leaving only verification, storage, and consensus functions on L1. After the introduction of Massive, modular design will evolve to include execution modularization, DA modularization, and verification modularization, with only storage and consensus remaining on L1. This is logical since verification itself is part of computation. Given that execution modularization has already moved computation off-chain, then only storage and consensus should remain on-chain. The specifics are illustrated in the following diagram (Fig.6): If verification remains on Layer 1 (L1), the specific consensus process involves each node executing, verifying proofs, and updating the state. However, if we extract the verification process and assign it to a separate network for consensus, the L1 consensus process would then only involve updates to storage. Under the latest modular design, existing L1 nodes will no longer undertake any computational tasks. They will only handle transactions related to the update of the global state and then execute the consensus process. There are two main reasons for this approach: As mentioned in previous sections, considering costs and security, the execution of verification can be significantly delayed. Therefore, extracting it and utilizing the Massive network for verification not only achieves rapid validation but also reduces the hardware requirements for verification nodes, making it easier for users to connect. The security of the separate Massive network is ensured by the amount of staked assets and the number of nodes. Compared to the original scheme, this might sacrifice a certain level of security (which depends on the value of the staked assets) but, in return, offers significant architectural advantages. The Ecosystem of Massive Leveraging the three core features of mobile phone mining, staking/re-staking, and Timely Settlement, Massive has the potential to become the largest network, providing safe, efficient, and low-cost services for a variety of ZK L2s/L3s. Additionally, due to its extremely low barrier to entry and profit effects, it will inject a significant number of real users into the industry. Massive's vision is to facilitate massive adoption within the industry. Mobile mining represents a highly exploratory practice. Through straightforward operations, lower thresholds, and continuous earnings, it aims to utilize the computational power of smartphones. According to statistics, the global sales of smartphones exceeded 1 billion units in 2023. Solana and Aptos have also successively launched their own Web3 phones. Through the Massive network, these devices will be leveraged. Reference Eigenlayer whitepaper: https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf Scroll explorer: https://scrollscan.com/batch/86321 Polygon explorer: https://zkevm.polygonscan.com/batches Zksync contract: https://etherscan.io/address/0xa0425d71cB1D6fb80E65a5361a04096E0672De03#readContract Starkware explorer: https://voyager.online/block/572773 Halo2: https://github.com/zcash/halo2 Nova: https://eprint.iacr.org/2021/370 Celestia: https://docs.celestia.org/learn/how-celestia-works/overview

Unveiling the Technical Vision Behind Massive: Decentralized, Cheap, Fair, and More

বিশালের পিছনে প্রযুক্তিগত দৃষ্টিভঙ্গি উন্মোচন করা: বিকেন্দ্রীভূত, সস্তা, ন্যায্য এবং আরও অনেক কিছু

Enthüllung der technischen Vision hinter Massive: Dezentralisiert, günstig, fair und mehr

Revelando la visión técnica detrás de Massive: descentralizado, barato, justo y más

Dévoiler la vision technique derrière Massive : décentralisé, bon marché, équitable et plus encore

बड़े पैमाने पर तकनीकी दृष्टि का अनावरण: विकेंद्रीकृत, सस्ता, निष्पक्ष और बहुत कुछ

Massive の背後にある技術的ビジョンを明らかにする: 分散化、安価、公正など

Massive의 기술적 비전 공개: 분산화, 저렴함, 공정함 등

Revelando a visão técnica por trás do Massive: descentralizado, barato, justo e muito mais

Раскрытие технического видения Massive: децентрализованное, дешевое, справедливое и многое другое

Massive'ın Arkasındaki Teknik Vizyonu Ortaya Çıkarıyoruz: Merkezi Olmayan, Ucuz, Adil ve Daha Fazlası

Tiết lộ tầm nhìn kỹ thuật đằng sau Massive: Phi tập trung, giá rẻ, công bằng và hơn thế nữa

揭示 Massive 背后的技术愿景：去中心化、廉价、公平等等

In book, the authors suggest the Finite State Machines pattern as one way of “juggling” real-world events to prevent writing a tightly coupled code. You might be familiar with state machines in various contexts, such as Cloud Computing (hello, AWS Step Functions) or even hardware. But have you ever considered employing state machines to tackle real-world front-end challenges? How often have you found yourself building a multi-step wizard in your application, with numerous transitions that prompt users to input their details and select categories that will unblock various fill-review-submit form paths upon selection? The Pragmatic Programmer Fear not, as this article will demonstrate how you can build a straightforward abstraction for state machine wizards in React. Whatever the source, if we write applications that respond to events, and adjust what they do based on those events, those applications will work better in the real world. The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition What are the state machines? A state machine is essentially a specification for handling incoming state (inputs) and generating a new state based on those inputs. It represents the behavior of the system by encapsulating the various states the system can be in, along with the transitions between these states triggered by specific events or conditions. In the context of front-end development, state machines prove invaluable for managing user interfaces, especially those with intricate workflows or multiple possible paths. By applying the principles of state machines, developers can create more robust and predictable applications while fostering the creation of loosely coupled and reusable components. Below is an example of the simplest state machine representation. The state begins in ; the state changes to given input ‘ ’, or to given input ‘ ‘. State 1 State 2 X State 3 Y In the following sections, we’ll delve deeper into how state machines can be leveraged within the React framework through the prism of our example use case. Real-world website example Let’s pretend we are building a website for an insurance company. Users arrive at the homepage and are greeted with a prominent “Purchase Insurance” button, initiating a streamlined product purchase flow in a wizard format. Within this wizard, clients navigate through the following steps: Users provide essential information such as the insuree’s name, date of birth, and other pertinent details. Enter Personal Details: Clients choose the type of insurance they’re interested in, whether it’s a car, home, or a bundled package, including both. Select Insurance Type: Users select their desired coverage options, and the wizard dynamically generates an instant quote based on their choices. Quote prices vary depending on the type of insurance selected. Choose Coverage and Get a Quote: Users input specific insurance details such as the start of coverage, payment schedule, and more. Specify Insurance Details: If users aren’t already authenticated, they’re prompted to sign up or log in at this stage. Optional Authentication: Clients enter their payment details, choosing between credit or debit cards. Provide Payment Information: The final step involves reviewing all entered information, agreeing to the terms, and clicking the “Confirm” button to complete the purchase. Review & Confirmation: I will leave you for a minute to digest these requirements… Are you still here? Good! Let’s try to break it down. The wizard encompasses steps unique to the selected insurance product (car, home, or bundle), as well as those common to all. To visualize this, we can represent the flow using a state machine diagram: In the diagram above, each node represents a step corresponding to a view within the wizard. In fact, recalling your computer science lessons, the diagram embodies a directed acyclic graph (DAG), where each step is connected to another without introducing loops. While there may be three distinct paths depending on the insurance product selected, it’s worth noting that the path for bundled insurance shares steps with the other two paths, potentially allowing for the reuse of certain views. But how do we go about implementing this intricate process? Let’s explore that in the next section! Design of state machines When tackling the implementation of our wizard, there are a few approaches we could take. One straightforward method might involve creating each step in the wizard as a standalone React component, which is a good starting point. However, managing the navigation logic with numerous if-else statements within each component can quickly become hard to read, test, and maintain and prone to errors. This approach resembles an architectural pattern of choreography, where each component is aware only of its immediate neighbours in the chain of command. Alternatively, we could opt for a centralized approach, leveraging a global state and a state management library like Redux or React Context to serve as a central mediator. But it still will require us to build branches of the code lianas there to handle Back and Next actions from the wizard. We need to have our orchestration logic to be as simple as possible! Inspired by , I thought: “What if we could have extracted orchestration logic in a standalone configuration file and pass it down to a UI component capable of interpreting it?”. Amazon States Language specification This approach would allow us to not only reuse components for the steps but also the orchestration logic itself, leading to a more modular and maintainable solution. Let’s explore this idea further in the following sections. As a side note, it’s worth mentioning that there are existing libraries that leverage this architectural pattern and idea in general. One such library is , which offers a rich API contract for building state machines in React. While we won’t replicate it one-to-one, we’ll aim to build something simple yet sufficient to satisfy our needs. @xstate/react Building a foundation To lay the groundwork for our wizard implementation, let’s begin by selecting the technologies we’ll employ. For the UI library, I advocate for React due to its emphasis on creating reusable and modular components that align well with our objective. Now, let’s address the styling aspect. We require a lightweight and customizable solution to ensure flexibility when designing our wizard interface. In this regard, I propose utilizing Tailwind CSS, a utility-first and highly optimized CSS framework that allows developers to construct any user interface efficiently by leveraging pre-made CSS classes that straightforwardly map to CSS rules. Let's start with installing our dependencies: npm install -D react react-dom tailwindcss postcss autoprefixer typescript
npx tailwindcss init -p 
npx tsc --init In we need to add paths to all our components: tailwind.config.js module.exports = {
  content: ["./index.html","./src/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
} Then we need to add directives into our CSS file: @tailwind https://gist.github.com/sr-shifu/d51ac357e18e7aa9c148659d36f5657e?embedable=true#file-main-css If building a library, I would also recommend to move React dependencies to the so consumers would aware that React is required and what versions of it are supported: peerDependencies "peerDependencies": {
    "react": ">=16.8.0",
    "react-dom": ">=16.8.0"
  } In the next section, we will focus on addressing of representation concerns for our component. Building view layer Here is our simple React component that does not have any logic (yet!): https://gist.github.com/sr-shifu/5a10bcb8c02b60fc024c3182784f88c3?embedable=true#file-statemachinewizard-tsx Upon reviewing this component, you might observe a few key points: We’re employing React portals to render our component. Portals offer a convenient way to render children components outside the DOM hierarchy of the parent component, ensuring flexibility and control over component rendering. See wonderful article about portals . Portals Usage: here Our component defines three logical slots: header, body, and footer. While the header and footer sections remain relatively static and don’t depend on the current step in the wizard, the body dynamically adapts based on the configuration. Logical Slots: The footer segment hosts the wizard’s navigation controls, allowing users to perform actions such as canceling/closing the wizard, navigating back to the previous step, progressing to the next step, or submitting the form upon reaching the end of the flow. Footer Controls: Here is what it looks like: As we progress, we’ll infuse this component with logic to orchestrate the wizard’s behavior and enhance its functionality. But for now, let’s focus on establishing the foundational structure of our state machine configuration. State machines configuration Let’s review the state machine configuration interface, which declares the orchestration flows for our wizard: https://gist.github.com/sr-shifu/7e394d3a1d6c38e4c6ff509c5a93f544?embedable=true#file-state-machine-config-ts I will break it down into its main parts: . This is a crucial aspect of the configuration, representing all possible directions from a certain step when the user reaches this point in the wizard. Each step is uniquely identified and mapped to another step, as well as to the view that will be rendered in the wizard body. The step configuration may include a method, serving as a guardrail to prevent navigation to the next step under specific conditions (e.g., if there are errors in the current step). Additionally, for steps with multiple possible paths to the next step, the attribute allows for defining these branching options. If a step configuration solely contains the flag, it indicates that the step is final, with no further transitions possible. In such cases, the wizard will render a Submit button instead of Next and close the wizard upon successful submission. steps canAdvance choices isTerminal . This specifies the step where wizard flow will start at. initialStep . This configuration maps each step by its identifier to the corresponding React component type (note, not the element!) that will be rendered in the wizard body. views Now, having this contract, we can define a DAG-like navigation model for our insurance purchase flow example: https://gist.github.com/sr-shifu/abcf01967b0f28d954232f082741a7ee?embedable=true#file-state-machine-config-example-ts If you take a closer look at step, you can notice that method does not rely on the state of the wizard - instead, it reads the data from localStorage. In the same way, we can determine whether we need to transition to when completing step. authenticate canAdvance authenticate setInsurancePeriod Why not define view as part of step configuration? This separation of concerns, where the view is defined separately from the step configuration, was a deliberate design decision. By decoupling orchestration concerns from rendering, we ensure flexibility and maintainability in our implementation. Consider scenarios where we may need to reuse the same orchestration model with slightly different views. With our current design, this is easily achievable by replacing all views or a subset of views while keeping the underlying orchestration logic intact. In the later sections of this article, I’ll illustrate the usefulness of this approach by demonstrating how we can effortlessly switch between different views while maintaining the same wizard flow. This separation not only enhances code reusability but also streamlines the process of adapting our wizard interface to varying requirements or design changes. Building orchestration logic Now, let’s go back to our component to add integration with we have just defined. StateMachineWizard StateMachineConfig First of all, we need to pass as an input prop. For better performance, I would recommend defining this config as a constant living outside of the React lifecycle! stateMachineConfig Now, let’s define the component states we will be working with: https://gist.github.com/sr-shifu/adf2d75ab0dd1616447b4a7bc9dada9e?embedable=true#file-statemachinewizard-tsx Key decisions: The state serves as a record of all transitions within the wizard flow, storing each step's name and the corresponding component rendered. Similar to React Router history, we can manipulate this history by pushing and popping items as users navigate through the wizard. navHistory We’ll maintain an additional state, , to store incremental changes to the wizard states occurring at each step. This approach allows us to preserve the state that existed in the previous step, facilitating seamless navigation backward in the wizard. wizardDataByStep Calculate on every step by accumulating states from the previous steps recorded in the . By aggregating these states, we can maintain a comprehensive snapshot of the wizard's progression, facilitating smooth data management and validation processes. aggregatedStepState navHistory Then, let’s define a few callbacks: https://gist.github.com/sr-shifu/6fac4c2651147d99d775979b8d0e2e41?embedable=true#file-statemachinewizard-tsx : This callback allows clients to enhance the state of the wizard by updating the data associated with a specific step. For example, in our insurance purchase flow, the EnterCustomerDetailsComponent can capture input changes and update the wizard state accordingly, enabling users to progress further. setStepData : Clients can use this callback to programmatically navigate to a specific step in the wizard. For instance, if the wizard is submitted with errors that need to be addressed in earlier steps, this callback can be invoked to jump back to those steps for correction. navigateTo Finally, we need to propagate these callbacks and some of our states to the step components. I will use React Context API to do this: https://gist.github.com/sr-shifu/b048502a02e548260e3c7885ff34afea?embedable=true#file-statemachinewizard-tsx will go through all transitions in navHistory, accumulate state collected on each step, and render the step that is active at the moment with this accumulated state: WizardSteps https://gist.github.com/sr-shifu/43436b67620423ab78246705862eea41?embedable=true#file-statemachinewizard-tsx Handling navigation Remember when building view layer, we left onNextClick and onBackClick methods not implemented? Let's fill this gap! https://gist.github.com/sr-shifu/f8c92086924bb4641230e751e6b88a0b?embedable=true#file-statemachinewizard-tsx Make requirements more complicated As our fake insurance company expands its business offerings, the CEO decides to extend insurance sales beyond individuals to include local businesses. Fortunately, the product types and coverage details remain unchanged. The only adjustment required is to the first step in the wizard, where business owners must enter details about their company. How can we accommodate this change with minimal alterations to our original architecture? The solution is surprisingly simple: we just need to replace the view mapped to the first step in the wizard. By updating the view component associated with the initial step, we can seamlessly incorporate the new requirement without fundamentally altering our existing architecture. This approach demonstrates the flexibility and scalability of our design, allowing for smooth adaptation to evolving business needs without necessitating extensive refactoring or restructuring. Here is what a simple code change will look like: https://gist.github.com/sr-shifu/6becb0f06232ad2c592908d91c991687?embedable=true#file-state-machine-config-example-tsx Final words In this article, we’ve explored the concept of state machines in the context of building interactive wizards in React applications. We began by understanding the fundamentals of state machines and their relevance in managing complex user interfaces, particularly in scenarios like multi-step wizards. Then, we delved into the implementation details, starting with the construction of a solid foundation using React for UI components and Tailwind CSS for styling. We discussed the importance of separating orchestration logic from rendering, which enables greater flexibility and reusability in our codebase. Next, we examined the state machine configuration interface, which serves as a blueprint for defining the wizard’s flow and behavior. By delineating the steps, their transitions, and associated views, we establish a clear structure for guiding users through the wizard. Building on this foundation, we outlined the orchestration logic, including managing navigation history, storing wizard states, and calculating aggregated step states. Through defined callbacks, we facilitated interaction with the wizard, ensuring a smooth and intuitive user experience. Finally, we addressed the scenario of evolving requirements, demonstrating how our architecture can adapt seamlessly to accommodate changes, such as expanding the target audience to include local businesses. As you embark on your journey to implement state machines in React for your own projects, remember the principles outlined here: prioritize modularity, separation of concerns, and flexibility. By adhering to these principles, you can create robust, maintainable, and user-friendly wizard interfaces that stand the test of time. Also published . here

Building Robust Front-End Interfaces with State Machines in React

Stories, News & Mentions about MDCLARITY

Mdclarity’s Stories on HackerNoon