One exciting feature in the recent release of Red Hat Enterprise Linux 8.1 is .NET Core 3.0. In this article, we will take a quick look at using .NET Core on Red Hat Enterprise Linux 8. We will cover installing .NET Core RPMs and using the RHEL-based Universal Base Image container images.
Installing .NET Core packages on RHEL 8
With RHEL 8, .NET Core is included in the AppStream repositories, which are enabled by default on RHEL 8 systems. At least two versions of .NET Core are already available on RHEL 8, and more will be added as they are released.
Continue reading “Getting started with .NET Core in Red Hat Enterprise Linux 8.1”
The Reactica roller coaster is the latest addition to Coderland, our fictitious amusement park for developers. It illustrates the power of reactive computing, an important architecture for working with groups of microservices that use asynchronous data to work with each other.
In this scenario, we need to build a web app to display the constantly updated wait time for the coaster.
Continue reading “Get started with reactive programming with creative Coderland tutorials”
With companies generating more and more revenue through their APIs, these APIs also have become even more critical. Quality and reliability are key goals sought by companies looking for large scale use of their APIs, and those goals are usually supported through well-crafted DevOps processes. Figures from the tech giants make us dizzy: Amazon is deploying code to production every 11.7 seconds, Netflix deploys thousands of time per day, and Fidelity saved $2.3 million per year with their new release framework. So, if you have APIs, you might want to deploy your API from a CI/CD pipeline.
Deploying your API from a CI/CD pipeline is a key activity of the “Full API Lifecycle Management.” Sitting between the “Implement” and “Secure” phases, the “Deploy” activity encompasses every process needed to bring the API from source code to the production environment. To be more specific, it covers Continuous Integration and Continuous Delivery.
Continue reading “5 principles for deploying your API from a CI/CD pipeline”
DevNation Live tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions and code and sample projects to help you get started. In this talk, Clement Escoffier, Principal Software Engineer at Red Hat, will dive into the reactive side of Quarkus.
Continue reading “DevNation Live: Subatomic reactive systems with Quarkus”
Before anything like an Android device or iPhone existed, desktop computers were the battleground for the browser wars. The battle involved billions of dollars invested by a number of companies, all based on the premise that whoever ruled the desktop browser market would own the internet. Today, mobile devices account for nearly half of all website traffic. Back in the 1990s, however, almost all of the action on the web came from desktop machines, and the vast majority of those desktop machines were running some flavor of Microsoft Windows.
In the browser world, the first-mover advantage belonged to Netscape Communications Corporation. They built the Netscape Navigator browser that made the web accessible to millions for the first time. Netscape had more than 80% of the market, but they also had no shortage of competition. IBM had a browser for OS/2. Oracle had the Powerbrowser, a Netscape-compatible product that included something called the Database Markup Language. The real danger to Netscape, of course, came from the company that owned more than 80% of the world’s desktops: Microsoft.
Strategically, Netscape realized that the web needed to move past static web pages to reach its full potential. Even if they were created dynamically by something like a CGI script on the web server, pages didn’t change once they arrived in your browser. If you wanted to see even a slightly modified version of a page, you had to send a request back to the server and wait for a response. For all its sophistication, a web browser felt a lot like a dumb terminal attached to a mainframe. What web developers needed was a programming language that would run in the browser, taking advantage of the processing power of the desktop machine to give users a richer experience.
DevNation Live tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions and code and sample projects to help you get started. In this talk, you’ll learn about Quarkus, Kogito, and GraalVM from Red Hat’s Mario Fusco, Principal Software Engineer, and Burr Sutter, Chief Developer Evangelist.
Continue reading DevNation Live: Introducing Kogito
The Kubernetes API is amazing, and not only are we going to break it down and show you how to wield this mighty weapon, but we will do it while building a video game, live, on stage. As a matter of fact, you get to play along.
Continue reading “Kubernetes: The retro-style, Wild West video game”
One of the things I enjoy most about using Red Hat OpenShift is the Developer Catalog. The Developer Catalog is a central location where a team working with Red Hat OpenShift can encapsulate and share how application components and services are deployed.
The Developer Catalog is often used to define an infrastructure pattern referred to as a builder image. A builder image is a container image that supports a particular language or framework, following best practices and Source-to-Image (s2i) specifications.
The OpenShift Developer Catalog provides several standard builder images supporting applications written in Node.js, Ruby, Python, and more. And while the Developer Catalog has many easy ways to get started deploying several supported languages, the catalog is also flexible in allowing you to add your own builder images to support an infrastructure pattern that is not preloaded in the catalog.
Continue reading “Using a custom builder image on Red Hat OpenShift with OpenShift Do”
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”
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”