Do you dream of a local development environment that’s easy to configure and works independently from the software layers that you are currently not working on? I do!
As a software engineer, I have suffered the pain of starting projects that were not easy to configure. Reading the technical documentation does not help when much of it is outdated, or even worse, missing many steps. I have lost hours of my life trying to understand why my local development environment was not working.
An ideal scenario
As a developer, you have to meet a few prerequisites before contributing to a project. For instance, you must agree to the version-control requirements, and you need to know how to use the project IDE, how to use a package manager, and so on.
But nothing more. You don’t need to learn a poorly documented, made-in-house framework just to satisfy the ego of an architect who wanted to reinvent the wheel. You don’t need to run an external virtual machine to emulate the production environment. As a developer, you are free to invest your time in improving the code and adding value to the product.
A developer-centered approach to application development
My goal with this article is to describe strategies for building an Angular 8 application in a way that centers the developer experience.
Continue reading “A developer-centered approach to application development”
Kubernetes conversations rarely center the developer’s perspective. As a result, doing our job in a k8s cluster often requires building complicated YAML resource files, writing custom shell scripts, and understanding the countless options that are available in
docker commands. On top of all of that, we have the learning curve of understanding Kubernetes terminology and using it the way that operations teams do.
Continue reading Enterprise Kubernetes development with odo: The CLI tool for developers
On April 21st, Node.js released its latest major version with Node.js 14. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October 2020. This release brings a host of improvements and features, such as improved diagnostics, a V8 upgrade, an experimental Async Local Storage API, hardened the streams APIs, and more.
While Red Hat will release a Universal Base Image (UBI) for Node.js 14 in the coming months for Red Hat OpenShift and Red Hat Enterprise Linux, this article helps you get started today. If you’re interested in more about Node.js 14’s improvements and new features, check out the article listed at the end.
Continue reading “Use Node.js 14 on Red Hat OpenShift”
Developing applications on a Kubernetes distribution like Red Hat OpenShift—or on Red Hat Enterprise Linux (RHEL), or by using our Universal Base Images—is easier with Red Hat’s build of Node.js. The latest update of Red Hat Runtimes now includes Node.js 12.4.1, which provides a supported runtime for LTS releases. This new Red Hat build of Node.js together with the release of Red Hat Enterprise Linux 8.1 provides a number of new features and enhancements compared to Node.js 10.
This article focuses on these new features and enhancements.
Continue reading “Node.js update for Red Hat Runtimes brings improved support for native modules, diagnostic reporting, and more”
The 0.2.0 release version of the Red Hat OpenShift extension for JetBrains IntelliJ is now available. You can download the OpenShift Connector extension from the JetBrains Plugins Repository. This release provides a new OpenShift: Debug action to simplify the debugging of OpenShift Components pushed to a cluster. It is similar to features developed for Visual Studio Code and JBoss Tools for Eclipse. OpenShift Connector uses OpenShift Do‘s (
odo‘s) debug command under the hood and supports only local Java and Node.js components. This enhancement lets the user write and debug local code without leaving IntelliJ.
This article explains how OpenShift: Debug works and shares the difference between debugging Java and Node.js components in IntelliJ.
Continue reading “JetBrains IntelliJ Red Hat OpenShift extension provides debug support for OpenShift components”
In the previous article, we introduced the Service Binding Operator and explained how it functions. In this article, we’ll look at a more advanced topic—custom environment variables—and walk through a typical usage scenario.
Continue reading Service Binding Operator: The Operator in action
Connecting applications to the services that support them—for example, establishing the exchange of credentials between a Java application and a database that it requires—is referred to as binding. The configuration and maintenance of this binding together of applications and backing services can be a tedious and inefficient process. Manually editing YAML files to define binding information is error-prone and can introduce difficult-to-debug failures.
Continue reading Introducing the Service Binding Operator
In my previous article, Run Red Hat Enterprise Linux 8 in a container on RHEL 7, I showed how to start developing with the latest versions of languages, databases, and web servers available with Red Hat Enterprise Linux 8, even if you are still running RHEL 7. In this article, I’ll build on that base to show how to get started with Node using the current RHEL 8 application stream versions of Node.js and Redis 5.
Continue reading “Develop with Node.js in a container on Red Hat Enterprise Linux”
I recently wrote articles on deploying an Express.js application to OpenShift, how to debug your Node.js application on OpenShift with Chrome Dev Tools and a short series on deploying modern web applications to OpenShift. All of those articles used a node module called Nodeshift, but I did a Jedi, hand-wavy thing when talking about it. This next series of articles takes a deeper look at what Nodeshift is and how it is used to ease the deployment of Node.js apps to OpenShift during development.
Continue reading “Easily deploy Node.js applications to Red Hat OpenShift using Nodeshift”