Month: January 2024

APEX : Keeping up to date is so easy…

Over the years I’ve extolled the virtues of Oracle Application Express (APEX) because of the ease of development. I think low code tools are a massive boon to productivity. Of course there are some tasks that need alternative tools, but for many scenarios low code tools are awesome.

Something else I find really appealing about APEX is the ease of upgrades. I’m not talking about how easy it is to apply the upgrade itself, because updating Java and Tomcat versions on a server is really easy too. I mean how simple it is from a wider perspective.

I was the first person in my company to use APEX. I used it to write some utility type applications, when it was still “forbidden”. Some of these applications were written over a decade ago, and they are still working fine. In that time we’ve had regular APEX upgrades, and they’ve just kept going. No refactoring. No drama.

Of course, they aren’t using all of the new features that were added in subsequent releases, but the important thing is all that development investment was not impacted by staying on the latest APEX release and patch set. In comparison, updating some of our other platforms and frameworks is a nightmare, requiring substantial development effort and testing.

So it’s not just about improving productivity during the development phase. It’s also about the reduction in the total cost of ownership (from a development perspective) over the lifespan of the application.

Just thought I would share that thought, as I upgrade & patch some production systems… 🙂

Cheers

Tim…

Continuous Improvement : It’s easy to get lazy…

I like to think that continuous improvement is always part of my process, but occasionally things crop up and remind me that I am just as lazy and set in my ways as everyone else. Here’s a little story to illustrate that…

The Issue

The main thing I’m supposed to be focussed on at work is server rebuilds. We are moving a bunch of stuff from Oracle Linux 7 (OL7) to Oracle Linux 9 (OL9), or OL8 if the vendor doesn’t support OL9 yet.

Anyone who follows my Vagrant builds knows I’ve got loads of scripts that build things, but because of our company organisation structure, there is only so much I can do without pinging requests to other teams, so full automation on-prem is not currently possible for me at work.

As a result of this limitation, there is a bunch of things I can do in Vagrant that I can’t do at work. The fact that work is semi-automated for builds has indirectly made me lazy in respect to continuously improving my build processes. In my head I guess I’ve been saying, “What’s the point if I can’t finish it?”

Making Progress

Due to the large number of rebuilds we are working through now, I’ve taken a step back and started again. I created a new build repo at work, and populated it with all the relevant stuff from our existing build processes, and some bits from my Vagrant builds. It’s still not fully automated, due to the company organisation issues mentioned before, but every step in the process is up to date with the best we can do, and the process is documented in the README.txt of the repo.

Along the way I noticed a bunch of things that were pretty crap in my original approach. It worked, but it wasn’t something to be proud of. 🙂

So What?

This just goes to illustrate the point I made in the title of this post. It’s easy to get lazy and let things start to slip, even when you know better. This is especially true if you have a “completionist” mentality like me. The thought of being able to finish something is quite compelling to me. Unfortunately, when I know I will not be able to complete something, I find it really hard to make the effort, because it all feels kind-of pointless. 🙂

Reframe The Goal

I guess this is really about reframing the goal. Rather than thinking that completion is when I have a fully automated process, it should be that I’ve got everything up to date and as far down the automation path as I can get at the moment.

The funny thing is I wrote about this in a previous post, but it seems I’m not always capable of taking my own advice. 🙂

Cheers

Tim…

Oracle VirtualBox 7.0.14

VirtualBox 7.0.14 has been released.

The downloads and changelog are in the usual places.

I’ve installed it on my Windows 10 and 11 machines with no drama.

Vagrant 2.4.0

Vagrant 2.4.0 is still the current release, so no change there.

If you are new to Vagrant and want to learn, you might find this useful.

Once you understand that, I found the best way of learning more was to look at builds done by other people. You can see all my Vagrant builds here.

I’ve updated my Vagrant builds to include the latest Oracle patches, along with GraalVM, ORDS, SQLcl and Tomcat.

Packer 1.10.0

I use Packer to rebuild my Vagrant boxes (Oracle Linux 7, 8 and 9) so they have the latest guest additions. The current set of boxes were built using Packer 1.10.0. The new version of the boxes can be seen here.

If you are interested in creating your own Packer builds, you might take inspiration from mine, available here.

Packer has been warning about using built in plugins for some time. This version doesn’t use built in plugins at all, so I had to do the following (in bold) to load the plugins, so I could perform a build.

set PATH=%USERPROFILE%\u01\software\hashicorp\packer_1.10.0_windows_amd64;%PATH%
packer plugins install github.com/hashicorp/vagrant
packer plugins install github.com/hashicorp/virtualbox

cd \git\oraclebase\vagrant\packer\ol9

packer build -only virtualbox-iso ol9.json

How did it all go?

The new versions of VirtualBox and Packer worked fine. 🙂

What about the VirtualBox GUI?

Just a quick warning. I do everything using Vagrant, so I rarely look at the VirtualBox GUI. Remember, when I say everything worked fine, I mean for what I use.

Cheers

Tim…