Modern App Dev

C# 8 default interface methods

C# 8 default interface methods

In the previous articles, we discussed C# 8 async streams and pattern matching. In this article, we’ll look at C# 8 default interface methods.

Extending interfaces

Before C# 8, it was not possible to add members to an interface without breaking the classes that implement the interface. Because interface members were abstract, classes needed to provide an implementation. C# 8 allows us to extend an interface and provide a default implementation. The runtime (which also needs to support this feature) uses the default implementation when the class does not provide it:

interface IOutput
{
    void PrintMessage(string message);
    void PrintException(Exception exception)
        => PrintMessage($"Exception: {exception}");
}
class ConsoleOutput : IOutput
{
    public void PrintMessage(string message)
        => Console.WriteLine(message);
}

In this example, ConsoleOutput does not provide an implementation for PrintException. When PrintException is called against a ConsoleOutput instance, the default method from the IOutput interface will be called. ConsoleOutput might provide its own implementation.

Continue reading “C# 8 default interface methods”

Share
How to ignore files in Git without .gitignore

How to ignore files in Git without .gitignore

Git has a handy feature when it comes to preventing accidental file check-ins when the files are meant to stay local. The obvious candidates are compiled binaries when you only want to check in the source code. Other candidates are files with local configurations.

One can put all of those files and paths into a .gitignore file in the project. To persist those changes (and to share the common file contents with collaborators on the project), one usually adds the .gitignore file to Git like any other file in the project.

The problem

Unfortunately, there are limits to this approach.

Continue reading “How to ignore files in Git without .gitignore”

Share
Designing an event-driven process at scale: Part 3

Designing an event-driven process at scale: Part 3

In the first article in this series, Designing an event-driven business process at scale: A health management example, Part 1, you found the business use case and data model for a concrete example from the health management industry. You then began implementing the example in jBPM (an open source business automation suite) by creating the Trigger process.

In the second article, you implemented the Task subprocess and, among other things, you also configured the call parameters for the Reminder and Escalation subprocesses within the Task subprocess. Now you will implement these subprocesses.

Continue reading “Designing an event-driven process at scale: Part 3”

Share
Designing an event-driven process at scale: Part 2

Designing an event-driven process at scale: Part 2

In the first article in this series, Designing an event-driven business process at scale: A health management example, Part 1, we began by defining the business use case and data model for a concrete example from the health management industry. We then began implementing the example in jBPM (an open source business automation suite) by creating our trigger process.

Now, in the second article in this series, we will focus on creating the Task subprocess and its many components. In our case, these are:

  • The Expired? gate
  • The Suppressed? gate
  • The human task
  • The Reminder subprocess
  • The “What type of close?” gate
  • The Hard Close embedded subprocess
  • The Escalation subprocess

Continue reading “Designing an event-driven process at scale: Part 2”

Share
Designing an event-driven business process at scale: A health management example, Part 1

Designing an event-driven business process at scale: A health management example, Part 1

The concept of a business process (BP), or workflow (WF), and the discipline and practice of business process management (BPM) have been around since the early 90s. Since then, WF/BPM tools have evolved considerably. More recently, a convergence of different tools has taken place, adding decision management (DM) and case management (CM) to the mix. The ascendance of data science, machine learning, and artificial intelligence in the last few years has further complicated the picture. The mature field of BPM has been subsumed into the hyped pseudo-novelties of digital business automation, digital reinvention, digital everything, etc., with the addition of “low code” and robotic process automation (RPA).

A common requirement of business applications today is to be event-driven; that is, specific events should trigger a workflow or decision in real-time. This requirement leads to a fundamental problem. In realistic situations, there are many different types of events, each one requiring specific handling. An event-driven business application may have hundreds of qualitatively different workflows or processes. As new types of events arise in today’s ever-changing business conditions, new processes have to be designed and deployed as quickly as possible.

Continue reading “Designing an event-driven business process at scale: A health management example, Part 1”

Share
Introducing 10 new features in Quarkus Tools for Visual Studio Code

Introducing 10 new features in Quarkus Tools for Visual Studio Code

Quarkus Tools for Visual Studio Code version 1.3.0 has been released on the VS Code Marketplace to start off the new year. As Quarkus continues to introduce improvements and new features like application.yaml and server-side templating support, Quarkus Tools for Visual Studio Code continues to evolve to accompany these new features and improvements.

Continue reading Introducing 10 new features in Quarkus Tools for Visual Studio Code

Share
Customizing OpenShift project creation

Customizing OpenShift project creation

I recently attended an excellent training run by Red Hat’s Global Partner Enablement Team on advanced Red Hat OpenShift management. One of the most interesting elements of the training was how to customize default project creation. This article explains how to use OpenShift’s projectRequestTemplate to add default controls for the resources that a project is allowed to consume.

Continue reading “Customizing OpenShift project creation”

Share
Camel K standalone Java file: Now with Java language support

Camel K standalone Java file: Now with Java language support

Apache Camel K should be as lightweight as possible. Therefore, the Camel K project provides standalone Java files to describe a Camel integration. The downside to this practice is that existing IDEs cannot provide complete support out of the box. To provide a complete experience with Apache Camel K’s standalone Java files, there were three solutions:

As a result, there is no intuitive configuration. However, Red Hat’s Tooling for Apache Camel K offers a new possibility.

Continue reading “Camel K standalone Java file: Now with Java language support”

Share
Editing, debugging, and GitHub in Red Hat CodeReady Workspaces 2

Editing, debugging, and GitHub in Red Hat CodeReady Workspaces 2

In a previous article, I showed how to get Red Hat CodeReady Workspaces 2.0 (CRW) up and running with a workspace available for use. This time, we will go through the edit-debug-push (to GitHub) cycle. This walk-through will simulate a real-life development effort.

To start, you’ll need to fork a GitHub repository. The Quote Of The Day repo contains a microservice written in Go that we’ll use for this article. Don’t worry if you’ve never worked with Go. This is a simple program and we’ll only change one line of code.

After you fork the repo, make note of (or copy) your fork’s URL. We’ll be using that information in a moment.

Continue reading “Editing, debugging, and GitHub in Red Hat CodeReady Workspaces 2”

Share
Architecting messaging solutions with Apache ActiveMQ Artemis

Architecting messaging solutions with Apache ActiveMQ Artemis

As an architect in the Red Hat Consulting team, I’ve helped countless customers with their integration challenges over the last six years. Recently, I had a few consulting gigs around Red Hat AMQ 7 Broker (the enterprise version of Apache ActiveMQ Artemis), where the requirements and outcomes were similar. That similarity made me think that the whole requirement identification process and can be more structured and repeatable.

This guide is intended for sharing what I learned from these few gigs in an attempt to make the AMQ Broker architecting process, the resulting deployment topologies, and the expected effort more predictable—at least for the common use cases. As such, what follows will be useful for messaging and integration consultants and architects tasked with creating a messaging architecture for Apache Artemis, and other messaging solutions in general. This article focuses on Apache Artemis. It doesn’t cover Apache Kafka, Strimzi, Apache Qpid, EnMasse, or the EAP messaging system, which are all components of our Red Hat AMQ 7 product offering.

Continue reading “Architecting messaging solutions with Apache ActiveMQ Artemis”

Share