Articles, notes and random thoughts on Software Development and Technology
I posted a while back about running mysql in a Docker container on an Apple Silicon MacBook. It’s been a while since I’ve run mysql locally, and it seems the mysqlsh client is now preferred over the previous mysql client.
With mysqlsh, after connecting, to issue a ‘use’ command to select a db, use ‘\use dbname’
Once a db is selected, to issue other mysql commands enter the sql mode with ‘\sql’ command.
In my previous posts comparing US Amateur Radio licence conditions with UK licences I looked at output power differences (part 1), geographic restrictions (part 2) and callsign formats (part 3). One area I have been particularly interested in over the past few years is packet radio (previous posts), packet BBSes (previous posts) and APRS usage, both topics until license changes in 2024 were significantly more restricted in the UK compared to US.
I don’t think there are any similar restrictions for any license level to run a packet radio node unattended in the US (see Part 97.219 Message Forwarding Systems. Beacon station are also permitted upto 100w in the US for any licence level), but in the UK up until 2024 with the recent license changes only a Full license holder was allowed to run an unattended station of any kind, which would include a repeater, a beacon, a packet radio mailbox, a BBS, or a packet radio node.
For 2024 in the UK, Foundation and Intermediate licensees can now run an unattended station as a new category of ‘Data Station’, which includes packet stations, but only upto 5w ERP. For upto 25w then a Full license is required.
Previously in the UK, a Notice of Variation (NoV) needed to be applied for to run an unattended data station, similar to repeaters, which if approved would grant a new callsign for the unattended station. This has also been relaxed in the 2024 changes where for up to 5w ERP you can run the station under your own personal callsign.
Full details of these changes are in Ofcom’s ‘Statement: Updating the amateur radio licensing framework’ doc here.
Deploying a Spring Boot app to AWS Elastic Beanstalk is relatively easy using the eb cli tool, if you’re prepared to accept some defaults as part of the deploy. It’s probably possible to configure/customize IAM roles, Security Groups etc, but accepting the defaults is an easy way to deploy during development.
To initialize a new Elastic Beanstalk deployment, run in the root of your Spring Boot source folder:
eb init
Before creating the environment and deploying your app, edit the .elasticbeanstalk/config.yml that the previous step creates, to configure the built app jar to be deployed, by adding this section:
deploy:
artifact: target/your-app-jar-0.0.1-SNAPSHOT.jar
To create a single dev/test env with no load balancing:
eb create --single
To tear down the deployed ec2 instance running your Spring Boot app:
eb terminate
By default, Beanstalk services are deployed on port 5000. Since Spring Boot apps are on port 8080 by default, the quickest way to configure Spring Boot to accept incoming requests on port 5000 is to edit the ‘Updates, monitoring and logging’ section and add a new env var for Spring Boot to reconfigure to use port 5000 instead (this is described here)
Added new env var SERVER_PORT=5000:
In order to capture your Spring Boot logs to CloudWatch when running a Spring Boot app on AWS Elastic Beanstalk, ensure the ‘Log streaming’ config option is enabled:
Edit this config and set to enabled then you’ll see the app logs in CloudWatch:
