You may have an enormous ball of mud written in Perl but there are many benefits to introducing a new language like Python or Go:
The communities are vibrant
It’s easier to hire someone
They can do everything Perl can do
Documentation – Have some
Do not strip the comments from the code. That reminds me of WWII UK when signposts were removed to confuse the enemy.
Have documentation for each sub saying what the inputs are, the outputs and if you have a god object, what the side effects are.
Have documentation, preferably in POD in the code that reflects precisely what the code does. You can do lots with this. And test it.
Don’t have an overly complicated branching strategy
Don’t have a main branch that isn’t main/master.
Have a branch for each story.
Have branches for releases.
Do gitflow, it’s simple.
Jumphosts – They’re a PITA
Don’t be SO paranoid about security
Are you so locked down you have to ssh through a jumphost? And the jumphost won’t do ssh forwarding?
That breaks so much: no sshfs, no remote editing in your chainsaw of choice.
For bonus points, the dev machine can’t see the git repo. Please. I don’t like coding with a paper bag on my head.
CI on commit – Do it automatically
Once you have tests, run the CI pipeline when the code gets committed.
Preferably deploy (CD) that branch to the/a dev machine.
It exercises your deployment process. Remove a speed bump.
Deploy to dev and scheduled to test. It’s a computer: automate it.
Make friends with Docker. It makes life SO simple. Having laptops able to see the database is a BIG WIN.
Keep your dev database up to date.
No tests – a classic
Write your code so it’s testable. Don’t do everything through a God object. Have subs that have defined inputs and outputs.
When using Test::Perl::Critic::Progressive (or equivalent) to make sure your code isn’t getting worse, you’ll probably need to copy t/.perlcritic-history into and out of the artefact store between each run.
Can your CI machine see a test database? If not, you’re entering mocking hell.
Tests provide code examples. This is good.
Put the tests on a pre-commit git hook. Remember to chmod +x it.
Due to my upcoming job having a large part being Oracle, I figured I should install Oracle on my Mac. I found this article on the Oracle site that made running it in a virtual machine look easy. Simply, it’s:
git clone https://github.com/oracle/vagrant-projects
# Optional: download the Oracle Database installation file and place it in this directory
And that’s where the wheels fell off. I haven’t used Vagrant for a couple of years. My Vagrant fell into a wibbling heap. I needed to do the following to drag everything up to date:
brew install vagrant
And then install Virtualbox from the Virtualbox downloads page. Bringing up vagrant then refreshes the vagrant image, brings the oracle image up to date and runs it.
oracle21c-xe-vagrant: INSTALLER: Started up
oracle21c-xe-vagrant: Oracle Linux 8 BaseOS Latest (x86_64) 3.3 MB/s | 49 MB 00:14
oracle21c-xe-vagrant: Oracle Linux 8 Application Stream (x86_64) 3.2 MB/s | 37 MB 00:11
oracle21c-xe-vagrant: INSTALLER: Oracle preinstall and openssl complete
oracle21c-xe-vagrant: INSTALLER: Environment variables set
oracle21c-xe-vagrant: INSTALLER: Downloading Oracle Database software
You’re going to need the instantclient libraries. Do the following in the instantclient directory, you might want to have copied *.dylib* into /usr/local/lib:
This list of lists of falsehoods is a great read. The programming ones are good for for me, especially, but everyone should read the ones in their speciality. Better still, it’s on GitHub, so you can add to it!
I especially like the Big List of Naughty Strings. This is something software testers should use daily. Dates, times, timezones, names and addresses are all problematical.
When I installed ubuntu 20.04.3, I expected the ubuntu networking to Just Work. That was wrong. And apparently, there’s a new network management subsystem to worry about. A quick Google search led me to the Ubuntu docs and thence to create the file /etc/netplan/01-netcfg.yml:
I put all my GitHub/GitLab checkouts in ~/workspace, a hangover from BBC days, along with using VMWare Fusion. Although I tend to use docker more these days. I tried mounting it from within VMWare but no luck. A pointer from a chap on Reddit led me to these lines:
sudo mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other
Or alternatively, add the following to /etc/fstab:
These are all things you can find elsewhere but a couple of password issues came as a surprise to me
These are all things you can find elsewhere but a couple of password issues came as a surprise to me when a legacy system got the MySQL 5.7 upgraded to 8.0.
Firstly, password policies are much tighter. There’s a plugin that by default demands an uppercase letter, a number and a punctuation character. That foxes our legacy system whose installer just generates lowercase letters and numbers. Uninstall it.
So this was an hilarious case of reference counting.
There I was, developing my Perl Catalyst app. I migrate to gitlab like all the other cool kids. I move the original development directory to .bak like a good boy.
But, my plackup is still running and because reference counting, the open files are all still there so I was still happily running. I check out the gitlab version, make changes and NOTHING HAPPENS. Until finally the penny drops, I quit the original, now renamed directory and re-enter the correct one.