Welcome back to the second installment of our exploration into Quarkus and Panache! In the previous blog post, we delved into setting default values for Panache entity fields. Now, as we continue refining the WindR.org website with Quarkus integration, our primary focus shifts to implementing Database Projection with Panache.

Code Example on GitHub:

To accompany this discussion, I've published the complete code example on GitHub, providing you with a hands-on reference for learning and experimentation.

GitHub Repository: Learning Quarkus: Database Projection with Panache

Understanding the data model​

For this illustrative example, we'll work with a straightforward data model consisting of two tables: 'boards' and 'brands.' The 'boards' table contains a list of windsurfing boards, while the 'brands' table serves as a reference, linked to the 'boards' table through a foreign key relationship.

In the course of developing using NextJS, the integration of internationalization became a pivotal requirement on my checklist. The aim was to enable seamless translation of the application into multiple languages, leveraging the native i18n features provided by NextJS, as outlined in the official documentation.

To facilitate this, I organized a set of JSON files, each containing translations for the application in a specific language. For simplicity, I adopted a one-file-per-language approach, ensuring uniformity by maintaining identical keys across all files. The translation process involves replacing the values associated with each key.

To expedite this crucial task, I turned to GitHub Copilot for assistance. Witness the efficiency and precision of Copilot in action by watching the following video:

Yet again, GitHub Copilot proves to be the hero of my coding journey – making my day, one efficient line of code at a time!

PS: In this video I am translating the full file, but you can also translate a single key, or a set of keys, as you type them in the IDE, GitHub Copilot completion will propose you the translation.

In the process of crafting an updated version of the product catalog for WindR.org, the need to generate sample data arises. Leveraging the power of Quarkus and Panache, I find myself tasked with creating entities that embody various technical specifications for "windsurfing boards" – encompassing attributes like size, volume, width, and more.

Recognizing the potential tedium associated with manually creating this data, I turned to GitHub Copilot for assistance. The approach I took involved visiting a public website housing a comprehensive list of windsurfing boards. Here, I extracted the specifications of a specific board and seamlessly fed them into the GitHub Copilot Chat window. I then prompted Copilot to not only generate sample Java entities but also produce the corresponding SQL script for creating database rows.

The efficiency and effectiveness of GitHub Copilot in this scenario are showcased in the accompanying video. Witness firsthand how this tool streamlines the often laborious task of data generation, saving valuable time and effort in the development process:

Yet again, GitHub Copilot proves to be the hero of my coding journey – making my day, one efficient line of code at a time!

In the process of constructing a product catalog within NextJS, I found myself in need of seamlessly interfacing with my backend using REST APIs, each adorned with a variety of URIs and parameters.

The typical structure of these URLs, such as /api/v1/products?category=shoes&color=red&size=10, prompted me to harness the power of GitHub Copilot to expedite the creation of functions with the appropriate parameters. Copilot not only assists in generating the function but also crafts the necessary fetch code for calling the API with precision.

Watch this video to witness the rapid development in action:

Yet again, GitHub Copilot proves to be the hero of my coding journey – making my day, one efficient line of code at a time!

In the ever-evolving landscape of database technologies, my journey led me away from Java ORM projects for a decade, exploring the realms of NoSQL databases like MongoDB, Couchbase, Redis, and even HBase.

Recently, my focus shifted back to Java and, specifically, Quarkus. In this blog post, I'll share my experience migrating part of my site, windr.org, from MongoDB to PostgreSQL with Quarkus, highlighting how I tackled my first small challenge of setting default values for Panache entity fields.

Choosing Quarkus and Panache:

Having dabbled with Quarkus during my time at Red Hat in 2019, I decided to delve deeper into it for my personal projects. While familiar with using MongoDB directly with Node.js, working with Quarkus and RDBMS prompted me to opt for Hibernate ORM with Panache, a Quarkus extension offering a simplified and user-friendly API for Hibernate ORM.

I have published the code of this example on GitHub:

• Learning Quarkus: Default Values for Panache Entity Fields

When working with Github, you may need to manage deploy keys to allow automated deployments from external services. Deploy keys are SSH keys that grant read-only or read-write access to a single repository. You can add deploy keys to your repository from the settings page, but what if you need to revoke access for many repositories at once?

Today, there's no direct way to do this from the Github UI, but you can easily accomplish it with the APIs and the GitHub CLI gh.

I have created the following script to achieve this:

#!/bin/bash

ORG=$1

if [ -z "$ORG" ]
then
  echo "No organization provided"
  exit 1
fi

REPOS=$(gh repo list $ORG -L 200 --json name --jq '.[].name')

for repo in $REPOS
do
  echo "Deployment keys for $repo:"
  KEYS=$(gh api repos/$ORG/$repo/keys | jq -r '.[] | [.id] | @tsv')
  if [ -z "$KEYS" ]
  then
    echo -e '\t No Deployment Key'
  else
    for key in $KEYS
    do
    gh repo deploy-key delete -R $ORG/$repo $key
    done
  fi
done

You can use it like this:

./revoke-deploy-keys.sh <org-name>

Let's take a closer look at the script itself. It starts by setting a variable named "ORG" to the value passed as a parameter when the script is run. The script then uses the gh CLI to retrieve a list of repositories for the organization and stores them in a variable named "REPOS".

Next, the script loops through each repository and retrieves a list of deploy keys using the GH API. If there are no deploy keys, the script simply prints a message saying so. Otherwise, the script loops through each key and uses the gh CLI to delete it using the command gh repo deploy-key delete.

Overall, the script is a quick and easy way to revoke deploy keys for an entire organization's repositories. By combining the gh CLI and Github API, you can automate this process and save time and effort.

Since its launch, GitHub Copilot has been a hot topic in the developer community. Some people love it, some people hate it, and some people are just curious about it. I am part of the first group, and I have been using it for more than a year now. I will not go into the details of how Copilot works, but I will share with you my experience with it, and how it has changed my life as a developer.

Copilot will help developers differently depending on the way they work and the phase of the project they are in. I will try to cover as many use cases as possible, but I will not be able to cover all of them. Here are the main uses cases I have for Copilot

• Write code faster
• Create new features much faster
• Learn new things in context

In this article, you will learn how to use Kubernetes to run GitHub Actions self-hosted runners on-demand. This enables you to auto-scale your runners based on the number of queued jobs, and quickly respond to spikes in workflow activity.

I will focus on GitHub Enterprise Server, but the same concepts apply to GitHub.com, and this post is based on the work of the Actions Runner Controller team and Natalie Somersall

GitHub Actions is a great way to run your CI/CD workflows. However, it can be complex to run a large number of self-hosted runners. Using Kubernetes to auto-scale your runners you can simplify the management of your runners. The actions-runner-controller is a Kubernetes controller that manages self-hosted.

You can find a video of this article on YouTube:

• 🎥 GitHub Self-Hosted Runner Autoscaling with Kubernetes

In the following video, I show how to create a new product release with GitHub. This example shows how to:

• Create a new release, and generate release notes from PRs
• Upload a Maven artifact into GitHub Packages with Actions
• Generate new documentation site with GitHub Pages
• Use GitHub Discussions to involve your community.

A long-awaited feature is now available on GitHub: share actions in your workflows in your enterprise from Internal Repositories 🤖 !

When a developer does not find a suitable GitHub Action in the Marketplace, they can create their own, something that I have documented in the "How to Write Custom GitHub Action" post.

Until today, Actions had to be stored in a public repository, to allow other repositories to use them in workflows (or take a complex approach). This has changed 🎉.

Now you can put your actions in an internal repository; repositories visible to your whole enterprise.

Once your repository visibility is set to "Internal", in the Settings pages, click in the Actions section and select the proper Access configuration:

The following video shows this feature in action: