API-first design with OpenAPI and Red Hat Fuse

API-first design with OpenAPI and Red Hat Fuse

API-first design is a commonly used approach where you define the interfaces for your application before providing an actual implementation. This approach gives you a lot of benefits. For example, you can test whether your API has the right structure before investing a lot of time implementing it, and you can share your ideas with other teams early to get valuable feedback. Later in the process, delays in the back-end development will not affect front-end developers dependent on your service so much, because it’s easy to create mock implementations of a service from the API definition.

Much has been written about the benefits of API-first design, so this article will instead focus on how to efficiently take an OpenAPI definition and bring it into code with Red Hat Fuse.

Continue reading “API-first design with OpenAPI and Red Hat Fuse”

Share
10 tips for reviewing code you don’t like

10 tips for reviewing code you don’t like

As a frequent contributor to open source projects (both within and beyond Red Hat), I find one of the most common time-wasters is dealing with code reviews of my submitted code that are negative or obstructive and yet essentially subjective or argumentative in nature. I see this most often when submitting to projects where the maintainer doesn’t like the change, for whatever reason. In the best case, this kind of code review strategy can lead to time wasted in pointless debates; at worst, it actively discourages contribution and diversity in a project and creates an environment that is hostile and elitist.

A code review should be objective and concise and should deal in certainties whenever possible. It’s not a political or emotional argument; it’s a technical one, and the goal should always be to move forward and elevate the project and its participants.  A change submission should always be evaluated on the merits of the submission, not on one’s opinion of the submitter.

Continue reading “10 tips for reviewing code you don’t like”

Share
Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support

Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support

We are thrilled to announce an updated release of the data streaming component of our messaging suite, Red Hat AMQ streams 1.2, which is part of Red Hat integration.

Red Hat AMQ streams, based on the Apache Kafka project, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput and extremely low latency. AMQ streams makes running and managing Apache Kafka a Kubernetes-native experience, by additionally delivering Red Hat OpenShift Operators, a simplified and automated way to deploy, manage, upgrade and configure a Kafka ecosystem installation on Kubernetes.

Continue reading “Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support”

Share
Quickly set up a LAMP stack on Red Hat Enterprise Linux 8

Quickly set up a LAMP stack on Red Hat Enterprise Linux 8

Have you tried Red Hat Enterprise Linux 8 (RHEL8) yet? Read on to learn how to quickly set up a LAMP stack on RHEL8 so you can play around with the new features built into the operating system.

A LAMP stack is made up of four main components and some glue. The first main component in a LAMP stack (the “L”) is Linux. In my example, I’m using Red Hat Enterprise Linux 8 for that, which gives me a secure operating system, a modern programming environment, and a user-friendly set of tools to control it.

Continue reading “Quickly set up a LAMP stack on Red Hat Enterprise Linux 8”

Share
Introduction to cloud-native application environment architecture

Introduction to cloud-native application environment architecture

Cloud-native environment architecture can be challenging to understand. To help make sense of it for application developers and software/system architects,  I will attempt to explain the various parts and how they work together. Toward this end, I find it helpful to think about the architecture in four separate layers: application software development, service scaling, application network, and container orchestration platform.

In this article, I will describe the first technology layer: application software development. I drew the following diagram to make these concepts easier to visualize.

Continue reading “Introduction to cloud-native application environment architecture”

Share
Shenandoah GC in JDK 13, Part 3: Architectures and operating systems

Shenandoah GC in JDK 13, Part 3: Architectures and operating systems

In this series, I’ve been covering new developments of Shenandoah GC coming up in JDK 13. In part 1, I looked at the switch to load reference barriers, and, in part 2, I looked at plans for eliminating an extra word per object. In this article, I’ll look at a new architecture and a new operating system that Shenandoah GC will be working with.

Continue reading “Shenandoah GC in JDK 13, Part 3: Architectures and operating systems”

Share
Shenandoah GC in JDK 13, Part 1: Load reference barriers

Shenandoah GC in JDK 13, Part 1: Load reference barriers

In this series of articles, I will introduce some new developments of the Shenandoah GC coming up in JDK 13. Perhaps the most significant, although not directly user-visible, change is the switch of Shenandoah’s barrier model to load reference barriers. This change resolves one major point of criticism against Shenandoah—the expensive primitive read-barriers. Here, I’ll explain more about what this change means.

Continue reading “Shenandoah GC in JDK 13, Part 1: Load reference barriers”

Share