Using GCP MySQL Cloud SQL instances (create/connect/delete) – Pascal Landau

In this blog post I’ll summarize my experience with GCP MySQL Cloud SQL instances. Cloud SQL
is the managed relational database solution from Google Cloud Platform and was mentioned in
Deploy dockerized PHP Apps to production on GCP via docker compose as a POC
as the “better” way to deal with databases in a dockerized application (compared to running a
database via docker).

What will you learn?
I’ll explain the basic steps to create a fresh MySQL instance, show different ways to connect to it (Cloud Shell, locally “from your laptop” and from a VM within GCP) and finally how to delete the instance. Every process is done through the Cloud Console UI and recorded as a short video as a visual aid. As in the GCP “primer” tutorial, this article ends with the commands to achieve the same things also via the gcloud CLI.

Table of contents

Setup Cloud SQL

GCP Cloud Console Cloud SQL UI

The managed solution for relational databases from GCP is called
Cloud SQL and provides multiple database technologies –
including mysql. In the Cloud Console UI it is managed
via the SQL UI that allows us to create and manage

Create a new mysql instance

To get started, we need to enable the following APIs:

Creating a new instance from the
Create a MySQL instance UI
is pretty straight forward and well documented in the
GCP MySQL Guide: Create instances,
though there are some configuration options under “Customize your instance” that I want to mention:

  • Machine type > Machine type: For testing purposes, I recommend choosing a “Shared core”
    option here (e.g. 1 vCPU, 0.614 GB) to keep the costs to a minimum
  • Connections > Instance IP assignment: For now we’ll go with a “Pu

Truncated by Planet PHP, read more at the original (another 23533 bytes)

Setting up Git Bash / MINGW / MSYS2 on Windows – Pascal Landau

In this article I’ll document my process for setting up Git Bash / MINGW /
MSYS2 on Windows
including some additional configuration (e.g. installing make and apply
some customizations via .bashrc).

Table of contents


When I was learning git I started with the fantastic
Git for Windows package, that is maintained in the
git-for-windows/git Github repository and comes with
Git Bash, a shell that offers a
Unix-terminal like experience. It uses
MINGW and MSYS2 under the hood
and does not only provide git but also a bunch of other common Linux utilities like


I believe the main “shell” is actually powered by MINGW64 as
that’s what will be shown by default:

Git Bash / MINGW shell

Thus, I will refer to the tool as MINGW shell or Git Bash throughout this article.

I have been using MINGW for almost 10 years now, and it is still my go-to shell for Windows. I
could just never warm up to WSL, because the file sharing performance between WSL and native
Windows files was (is?) horrible – but that’s a different story.

How to install and update Git Bash / MINGW / MSYS2 via Git for Windows

You can find the latest Git for Windows installation package directly at the homepage of Older releases can be found on
Github in the
Releases section of the git-for-windows/git repository

Follow the instructions in the
How to Install Git Bash on Windows article on
to get a guided tour through the setup process.

After the installation is finished, I usually create a desktop icon and assign the shortcut
CTRL + ALT + B (for “bash”) so that I can open a new shell session conveniently via keyboard.

Git Bash desktop icon and shortcut

Update MINGW

To update Git for Windows, you can simply run

git update-git-for-windows

See also the
Git for Windows FAQ under “How do I update Git for Windows upon new releases?”

Git for Windows comes with a tool to check for updates and offer to install them. Whether or not you enabled auto-updates during installation, you can manually run git update-git-for-windows.

Truncated by Planet PHP, read more at the original (another 19960 bytes)

Xdebug Update: March 2023 – Derick Rethans

Xdebug Update: March 2023

In this monthly update I explain what happened with Xdebug development in this past two months. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 34% (7% less than two months ago) towards my $2,500 per month goal, which is set to allow continued maintenance of Xdebug.

If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend 18 hours on Xdebug, with 22 hours funded. Sponsorships through GitHub sponsors have now also drastically declined. Unless this is reversed, I would find it hard to spend the effort in making sure Xdebug continues to be updated for newer PHP versions. It certainly makes me think hard as to where to put my dedication towards.

This is also why I have not been as diligent with these update reports and been as active in resolving issues and bugs.

Xdebug Videos

I have published one new video in the last two months:

I have continued writing scripts for videos about Xdebug 3.2’s features, and am also intending to make a video about “Running Xdebug in Production”, and the updated “xdebug.client_discovery_header” feature (from Xdebug 3.1).

Let me know what you’d like to see!

You can find all previous videos on my YouTube channel.

Switching to Fedora from Ubuntu – Evert Pot

It seems like every 7-8 years I’m switching operating systems. In 2006 I first
started using Apple, because it was just so damn cool to have a well working
Unix-like system. (I’ll never forget you Snow Leopard).

In 2015 I switched to Ubuntu. Apple’s Software seemed to hit rock bottom at
this point from a quality perspective, and hardware seemed to go obsolete at
a rate I hadn’t seen before. Fed up paying a premium price for a sub-par
product, it was time for a change.

Ubuntu's logo deterioated

Ubuntu’s fall

Ubuntu was the obvious choice. I want something that just works, and Dell’s
XPS 13 Developer Edition
ships with Ubuntu which means hardware support
from Dell itself. Breath of fresh air and fast as hell. The experience was
similar to what people have been saying about the new M1 chips.
But it’s fast because of software, not hardware.

But something changed with Ubuntu in recent years. I think linux users have
a thicker than usual skin when it comes to software issues and are willing
to look past more things. But Ubuntu’s quality has been consistently falling.
I was being worn down, and it seems to be a common sentiment in my bubble.

The best example is Ubuntu’s package manager Snap. A pretty good idea, I like
the branding too but the execution hasn’t been there. Ubuntu users have been
effectively beta-testing this for years. Just to give you an idea I made a
giant list of bugs that I ran into when Ubuntu switched Firefox from apt
to Snap.

To be honest I feel a bit bad ragging on Ubuntu, because without knowing
anything about how the project and Canonical is run, my intuition is
that the steam is just kind of running out for them. Ubuntu feels ‘depressed’,
but maybe it’s all in my head.

Fedora logo


Installation was super smooth. I always forget to make a separate /home
mount, so it took a while to move everything to an external disk and back.

The one thing I always forget to move is my MySQL databases, and today
was no exception.

Non-free stuff

Fedora does not ship with things that aren’t open source. Nothing against that
philosophy (awesome in fact), but personally I don’t mind adding some binaries
for a better experience.

I miss Ubuntu’s Additional Drivers tool, because it told me what to
install. I’m sure the drivers I need are available for Fedora, but I don’t
know what to look for which makes me slightly worried my computer is not
running optimally. Battery feels worse but that could also be my imagination.

Video in Firefox didn’t work at all in stock Fedora. I had to install
ffmpeg to get it to barely function, but then I discovered RPM Fusion, where
I got an even better ffmpeg, plus gstreamer and Intel drivers and I can now watch
beautiful smooth 4K video, and confirmed with intel_gpu_top that I’m using
hardware acceleration.

intel_gpu_top output


Ubuntu used to have their own desktop environment called Unity. In
2018 they switched to Gnome, but they modified Gnome to keep their
Unity look.

Ubuntu 22.10 look

This felt like a good move, because it let them kept their look while
taking advantage of all the Gnome plumbing.

One drawback is that Ubuntu was usually a bit behind with Gnome

Fedora uses stock Gnome. As a result

Truncated by Planet PHP, read more at the original (another 2756 bytes)

Supporting CommonJS and ESM with Typescript and Node – Evert Pot

I maintain a few dozen Javascript libraries, and recently updated many of them
to support CommonJS and Ecmascript modules at the same time.

The first half of this article describes why and how I did it, and then all the
hoops I had to jump through to make things work.

Hopefully it’s a helpful document for the next challenger.

A quick refresher, CommonJS code typically looks like this:

const MyApp = require('./my-app');
module.exports = {foo: 5};

And ESM like this:

import MyApp from './my-app.js';
export default {foo: 5};

Except if you use Typescript! Most Typescript uses ESM syntax, but actually
builds to CommonJS. So if your Typescript code looks like the second and
think ‘I’m good’, make sure you also take a look at the built Javascript
code to see what you actually use.

Why support ESM

The general vibe is that ESM is going to be the future of Javascript code.
Even though I don’t think the developer experience is quite there yet, but
more people will start trying ESM.

If you decided to plunge in with ESM, I want my libraries to feel first-class.

For example, I’d want you to be able to default-import:

import Controller from '@curveball/controller';

At the same time most people are still on CommonJS, and I want to continue
to support this without breaking backwards compatibility for the forseeable

The general approach

My goal is for my packages to ‘default’ to ESM. From the perspective of a
library maintainer you will be dealing with ESM.

During the build phase steps are being made to generate a secondary CommonJS
build. As a maintainer you might run into CommonJS-specific issues, but
I suspect people will only see those if the CI system reports an issue.

Our published NPM packages will have a directory structure roughly like this:

- package.json
- tsconfig.json - src/ # Typescript source
- cjs/ # CommonJS
- esm/ # ESM
- test/

We include the original typescript sources to make step-through debugging work
well, and have a seperate directory for the ESM and CommonJS builds.

If you just want to skip to the end and see an example of a package that has
all this work done, check out my @curveball/core package:

Typescript features we don’t use


We don’t use the esModuleInterop setting in tsconfig.json. This flag
lets you default-import non-ESM packages like this:

import path from 'node:path';

instead of the more awkward:

Truncated by Planet PHP, read more at the original (another 29675 bytes)